Analysis Design and Architecture Document



[pic]

Ministry/Agency Name

To see instructions select Tools/Options Print tab, and make sure that “Hidden Text” is checked. Delete red instructions when filling in the template or select Tools/Options Print tab, and make sure that “Hidden Text” is not checked.

Project Name

Project #: [###]

Analysis Design and Architecture Document

Prepared by: Author's Name

Prepared for: [Company Name]

Date Submitted: [Date]

Project Sponsor: Project Sponsor's Name

Client Acceptor: [if different than Sponsor]

Project Manager: [Project Manager’s Name]

Document Number: 6450-20/[Project Number]/ADA

Security Classification: Low

Version: 1.1

Last Updated: July 19, 2005

Creation Date: [Date]

About this template: This template outlines the minimal set of information that is required for small, shorter-term projects. This template consolidates the core information contained in four standard Application Development Environment (ADE) deliverable templates.

Table of Contents

Table of Contents 2

1. Introduction 3

1.1. Purpose 3

1.2. Assumptions 3

2. Functional Design 5

3. Data Design 6

3.1. Data Details 6

3.2. Data Security 6

4. System Design 7

4.1. Hardware/Software Foundation 7

5. User Interface Design 8

6. Implementation Plan 9

6.1. Test Plan 9

6.2. Audit/Logging 9

6.3. Concurrent Use Estimate 9

7. Source Code Management 10

7.1. Delivery 10

7.2. Configuration Management Approach 10

7.3. Deployment 10

8. Operations Support 11

8.1. Roles and Responsibilities 11

8.2. Application Startup and Shutdown Requirements 11

8.3. Operational Dependencies 11

9. APMS Update 12

Revision Log 13

Appendices 14

Approval 15

Introduction

This Analysis Design and Architecture (ADA) document template consolidates the documentation requirements for short-term "low risk" category of applications. Typically these types of applications have easily definable goals that can be described in terms of how the system will be used and do not require more than 2 iterative design/development cycles

Each section in this document is mandatory. The section outlining data access and data usage are particularly important to enable an assessment of the applications impact from an enterprise perspective.

This document represents a consolidated view of key technical and architectural features associated with an application. An emphasis has been placed on detailing information processing capabilities (functional specifications) and maintenance support requirements.

Two submission/acceptance points are associated with the delivery of this document. The first submission occurs at the end of the design phase and the final "as built" revision occurs towards the end of the project.

Insert content here.

1 Purpose

The ADA document consolidates the core documentation requirements represented by the following standard Application Development Environment (ADE) deliverables:

• Technical Architecture Document;

• Application Architecture Document;

• Implementation Plan; and

• Operations and Support Guide;

The purpose of this document is to ensure a minimum level of information is delivered for projects with a scope and duration that do not warrant submitting each of the standard ADE templates listed above.

Note: An example of this template has also been provided to assist in establishing content scope. The example illustrates a Java centric technological approach but alternative Ministry endorsed technologies (ADE technology roadmaps) such as Forms Services or mod PL/SQL can also be used.

Insert content here.

2 Assumptions

A work plan, including Project Initiation Document (PID) has been completed and is mandatory.

Example project assumptions regarding the characteristics of projects that may be candidates to use this template include:

• A low data security concern;

• Analysis requirements for the project are very well understood and can be detailed completely within two or three pages;

• Not complex or large in terms of data scope, structures and/or processing;

• No more than two test iteration deliveries are expected prior to code acceptance/release to production;

• The Project utilizes a technology foundation that is already established at the Ministry;

• Oracle RDMS use is limited to read-only access to existing tables (No new tables are being created);

• Open VMS RDB (RDMS) data tier read/write access to existing business data. (Creation of new tables is limited to enhancing views of existing data, if new data tables are required consider utilizing the Oracle RDMS data tier.);

• A confirmation from the business perspective that the project is low risk and fills an immediate need that will ultimately be superseded by larger projects/initiatives; and

• A simple architecture with minimal distributed architectural dependencies.

Projects identified, as candidate applications for the use of this template are not expected to be creating new data tables in Oracle and hence are not required to use Oracle Designer.

Insert content here.

Functional Design

Using terms that are meaningful to the business area, specify/outline what the system must be able to do and how the system will be used.

At a minimum core system functions should be described. A function model can be included in this section or as an appendix to this document.

Note: The system function and data usage documentation approach should be discussed and agreed to during the creation of the PID.

Insert content here.

Data Design

Provide an introduction of the data usage associated with the project.

The criteria for establishing whether an abridged version (not utilizing Oracle Designer) of a data model can be produced for an application is based on the project characteristics outlined in the assumptions section.

At a minimum, schema location, table definitions and associated table usage descriptions should be provided in this section.

Insert content here.

1 Data Details

Describe:

• Data scope; offer an overview of what data is needed and why;

• Data location, Oracle, RDB or non-structured data (files);

• Output format of data;

• Capabilities for audit/logging of data access; and

• Outline use of data views and/or alternative data access paths.

Insert content here.

2 Data Security

Confirm need (or not) for a Privacy Impact Assessment (PIA) to be done.

PIA reference site:



Outline security assumptions, and any requirements for user role maintenance. Is access to the data controlled at the application (function/activity) level only or can data be acquired through direct access or other application(s).

Insert content here.

System Design

Describe the underlying architecture of the application. Outline core design features to help confirm the appropriateness of the solution to support the business requirements and gain approval for the design/development approach.

Insert content here.

1 Hardware/Software Foundation

An example of this information has been provided in the example template. Changes to hardware and software supported infrastructure will be expressed during project initiation and the information required to fill out this section will be supplied by the Ministry.

This section contains key features/versions of the applications component architecture (Software and Hardware Foundation). Include, list of J2EE API’s, and or libraries being used as well as supporting infrastructure needs i.e. JDK/JRE, RDMS, OC4J, Jinitiator etc.

Insert content here.

User Interface Design (Screens)

Reference existing guidelines/standards (i.e. E-services guidelines) being followed or identify how the proposed solution varies from accepted practice/standard. Business representatives must be consulted and sign off on the agreed User Interface (UI) format.

Insert content here.

Implementation Plan

The Implementation plan describes in detail the sequence of steps to perform for any successful first-time installation of the application system, and also highlights any configuration changes required to move a release between development, test and production landscapes.

Insert content here.

1 Test Plan

Describe the testing phase/process associated with implementation plan.

Insert content here.

2 Audit/Logging

Identify where log files are being produced to support system auditing. For Java applications this functionality supported through the log4j API, and the standard log directory oc4j_log located on the application server deployment area.

Insert content here.

3 Concurrent Use Estimate

Provide and estimate for the total number of users to have access to the application and an estimate of the peak usage numbers.

Insert content here.

Source Code Management

1 Delivery

Source code delivery occurs via the Ministry terminal server.

Refer to RDS documentation located on under Remote Delivery Guidelines.

Insert content here.

2 Configuration Management Approach

Configuration management for Java source code occurs via the Project Support Office (PSO) and is associated with a “formal” delivery. A middle tier service request for delivery of the application from DEV to TST initiates the versioning of delivered source code. Refer to RDS documentation



Insert content here.

3 Deployment

For Java based applications, deployment of J2EE 1.3 compatible code into the development middle tier environment can be accomplished through accessing Ministry terminal server. Refer to the following URL:



Insert content here.

Operations Support

Provide contact information for both online application help and Ministry support.

Non-Emergency Services Email:

1 Roles and Responsibilities

The table below identifies the roles and responsibilities involved in ensuring proper application operation, maintenance and support. Typically help desk is the initial contact for emergency services.

|Role |Responsibility |Contact Number and Email |Service Level |

| | |Help Desk (Initial Contact) | |

|Operations |Middle Tier |helpest@gov.bc.ca |9-5 |

| | |250-386-9500 | |

| | |Help Desk (Initial Contact) | |

|Operations |Data Tier |helpest@gov.bc.ca |9-5 |

| | |250-386-9500 | |

| | |Help Desk (Initial Contact) | |

|Operations |Web Tier |helpest@gov.bc.ca |9-5 |

| | |250-386-9500 | |

| | | | |

|Application support|Business Support |applicationSupportContact@.email.ca |9-5 |

| | | | |

2 Application Startup and Shutdown Requirements

Provide description of operational start-up and shutdown requirements.

Insert content here.

3 Operational Dependencies

Provide a description of any known application dependencies that can cause a service disruption. SQL*Net bridge or other network, database or email server connectivity requirements are typical examples.

Insert content here.

APMS Update

APMS updates are the responsibility of Ministry resources unless otherwise specified.

APMS update required? Yes No

APMS updated/to be updated on (date):

Comments:

Revision Log

Use data format “yyyy-mm-dd”. Versions are numbered. Draft versions begin with the number zero; e.g. the first draft is version 0.1, second draft, 0.2. The first approved draft is 1.0.

|Date |Version |Change Reference |Author |Reviewed by |

|[yyyy-mm-dd] |0.1 | | | |

| | | | | |

| | | | | |

| | | | | |

| | | | | |

| | | | | |

Appendices

Each Appendix must have:

• A separate header, numbered A-Z, with an appropriate descriptive title. Use the Heading TOC Style for each Appendix Header. This style will automatically insert a page break.

This document has been approved as the official Analysis Design and Architecture (ADA) Document for the Project Name project.

Following approval of this document, changes will be governed by the project’s change management process, including impact analysis, appropriate reviews and approvals, under the general control of the Master Project Plan and according to Project Support Office policy.

|Prepared by |Signature |Date |

|Author's Name | | |

|[Title] | | |

|[Organization] | | |

|Accepted by |Signature |Date |

|[Client Acceptor’s Name] | | |

|[Title] | | |

|[Organization] | | |

|Approved by |Signature |Date |

|[Client Approver’s Name] | | |

|[Title] | | |

|[Organization] | | |

|[Client Approver’s Name] | | |

|[Title] | | |

|[Organization] | | |

|[Project Manager’s Name] | | |

|[Title] | | |

|[Organization] | | |

|[IMG Approver’s Name] | | |

|[Title] | | |

|[Organization] | | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download