上海翻译公司业务技术手册英文翻译

Instruction for using sections 2-9 of this template is available in WTJA-0090 ELC Architecture Design Guidelines; instruction for using sections 10 on is available in WTJA-0026 ELC Design Guidelines.

1 Introduction

This documentation is intended to capture architecture and design specification for <project name>.

2 Architectural Goals and Constraints

To be completed during Requirements Stage

2.1 Capability Roadmap and Technology Strategies

<Identify the capability roadmap and technology strategies that direct the overall architecture approach.>

2.2 Architecture Constraints

<Identify special constraints that may apply to the design of this solution, including design and implementation strategies, team structure, etc.>

2.3 Architectural Trade-offs and Decisions

<Describe the architecturally significant decisions and trade-offs made.  This section applies to both custom development and COTS development.>

3 Architecture Quality & Alignment

To be completed during Requirements Stage

3.1 Repeatable Patterns

<Provide an overview of how this project adopts technology standards, reference architectures and repeatable solution patterns as part of the solution.>

3.2 SOA Services

<Provide an overview of how this project adopts SOA services as a key technology strategy.>

3.3 Master Data Management

<Provide an overview of how this project adopts SOA services as a key technology strategy.>

3.4 Architecture Exceptions

 <List all of the architecture exceptions that have been identified for this solution. Each exception should be identified by the entry in the Enterprise Issue and Risk Management log. Reference the EA Guide on Issues and Risk Management for more information about exceptions.>

ID Exception Resolution

<Identifier for Enterprise Issue & Risk Management Log> <Brief description of exception including architecture domain/shared service impacted> <Date of resolution & determination>

 

 

4 Logical View 

To be completed during Design Stage

4.1 Architecturally Relevant Use Case Realizations

Table 1  - Architecture impact of key use cases

Use Case ID Use Case Name Architecture Impact

None

 

4.2 Architecturally Significant Design Packages

<Document each design package.>

4.3  Architecturally Significant Collaboration

<Document relevant collaborations.>

4.3.1 Key Objects

<Insert Description of Object>

4.3.2 Key Messages

<Insert Description of Message.  Specification of messages is particularly important to service oriented systems.  A message specification identifies how to move data across service boundaries.  Therefore, a message specification should include at least following aspects:

o Anticipated message exchange & sequencing

o Message format and semantics

o Supported technology channels

o Potential error conditions>

4.3.3 Key Policies

<Insert Description of Key Policies.  Policies define the qualitative requirements, constraints, and capabilities of the component/service>

5 Deployment View 

If a decision is made to land the solution outside of a strategic data center, the team must contact Global Network Services (gNS) to perform a network analysis of the proposed infrastructure.

 

To be completed during Design Stage

 

<At a minimum for each configuration indicate the physical nodes (computers, CPUs) that execute the software and their interconnections (bus, LAN, point-to-point, and so on).>

5.1 <Infrastructure Component Name>

<Insert description of infrastructure component>

5.2 <Infrastructure Component Name>

<Insert description of infrastructure component>

6 Implementation View 

To be completed during Design Stage

6.1 Overview

<Name and define the various layers and their contents, the rules that govern the inclusion to a given layer, and the boundaries between layers. Include a component diagram that shows the relations between layers.>

6.2 Layers

<For each layer, include a subsection with its name, an enumeration of the subsystems located in the layer, and a component diagram.>

6.2.1 Client Tier

<Subsystem – for each subsystem, provide a description of its functionality and interaction with other subsystems and layers>

6.2.2 Presentation Layer

<Subsystem – for each subsystem, provide a description of its functionality and interaction with other subsystems and layers>

6.2.3 Control Layer

<Subsystem – for each subsystem, provide a description of its functionality and interaction with other subsystems and layers>

6.2.4 Business Logic Layer

<Subsystem – for each subsystem, provide a description of its functionality and interaction with other subsystems and layers>

6.2.5 Data Access Layer

<Subsystem – for each subsystem, provide a description of its functionality and interaction with other subsystems and layers>

6.2.6 Enterprise Information Layer

<Subsystem – for each subsystem, provide a description of its functionality and interaction with other subsystems and layers>

 

7 Data Flow View

To be completed during Design Stage

7.1 <Component Name>

<Insert description of data structure>

7.2 <Component Name>

<Insert description of data structure>

 

8 Size and Performance 

8.1 Execution Qualities

<Provide information and architectural assessment of the following areas, where applicable: Performance, Scalability, Availability, Reliability, Adaptability Interoperability, Portability, Configurability, Maintainability, Usability, Security>

8.2 Development Qualities

<Provide information and architectural assessment of the following areas, where applicable: Reusability, Modifiability, Localization, Testability>

8.3 COTS/Tool Assessment

<If vendor solutions are being used as part of the architecture, please provide an overview of how it’s being used, and a brief architectural assessment>

 

<Provide any reference to “RFI/RFP Architecture Assessment and Report” related to this project, with an explanation on how it relates to the overall solution.>

 

 

Instruction for using sections 10-19 is available in WTJA-0026 ELC Design Guidelines

9 System Design

<Enter design and a map to the contents and location of the source code.>

10 Directory Structure

<Provide a reference to the source code repository (e.g., repository name, project ID) or directory structure.  For COTS software, identify the location of installation files and/or media.>

 

The files for the <application name> are located on <server name and number>.  The following table represents all subsequent sub-directories associated with this application.

Sub-directory Directory Description

 

 

11 File Naming Conventions

Design Item Naming Convention Description

 

 

12 Development Technologies

Application Tool, System, Database,

Platform, Etc. Comments

Application Development

Browser

Business Rules

Client Server Architecture

Database

Database Access

Database OS Platform

Security

Software Version Control

 

13 Database Design

Enter the information below or reference a separate document or appendix containing the information.

• Physical Constraints:

• Physical Structure: 

• Logical Structure: 

• Data Model:

 

Table Name Keys Indexes Access Control Volume Expected

 

 

 

• Transaction Design Access Path:

• Volumes: 

• Security and Control:

• Optimization:

• Data Dictionary:  When prepared as a separate project deliverable, use the ELC Data Dictionaries Template and provide reference information to the project deliverable here.

• Character Set

• Record Locking:

• Database Technical Requirements:

Database Requirements

 

<TR id>

<Provide a list of technical requirement statements covering details of the database specifications.>

Database ID <Identify the names or labels by which the database may be uniquely identified.  Specify the code name, tag, or label by which each database table or file may be uniquely identified.>

Database Relationships <Indicate whether the database will supersede or interface with other databases, and specify which one(s).>

Schema Information <Depict overall structure in the schema or other global definition of the database.>

Design <Graphically depict the physical design of the database.>

Database Structure <Depict in a graphic representation the physical structure (partitions, files, indexes, pointers) and the logical components of the database.>

Data Dictionary <Reference the data dictionary.>

Database Software Utilities <List and reference the documentation of any DBMS utility software available to support the use or maintenance of the database.>

14 Conversion Design

Source Databases: 

Source Elements:

Validation Rules: 

Processing Rules:

Conversion Component:

Conversion Contingency Arrangements:

Reporting Controls:

Data Security:

15 System Interface Design

15.1.1 Interface Technical Requirements

Interface Technical Requirements

<Technical Requirements ID> <Provide a list of technical requirement statements covering the interfaces for the system.>

Hardware Interfaces

Hardware Devices <List the actual hardware devices your application will interact with and control.>

Supporting Devices <List the devices which are supported.>

Software Interfaces

Name <List the name of the software product.>

Specification Number <List the specification number.>

Version Number <List the version number.>

Communications Interfaces

Protocols <List the network protocols to directly interact with.>

Data Interfaces

Data processing <List the support functions for data processing.>

Back up and Recovery <List the operation for backup and recovery.>

16 Time Zone Specifications

What time zone will be displayed to the user?

What date/time zone will be used when recording audit trails?

Will there be any time zone conversions? If so provide documentation of conversions.

If the system is global, what time will the user see and which time zone will be captured?

17 Security Design

<Define the overall security features of the proposed solution, including the Authentication and Authorization method.>

18 System Components

18.1 <Technical Subsystem Component #1>

18.1.1 Overview

<Enter overview of subsystem’s functional requirements and graphic overview of associated software scripts>

18.1.2 Minimum Configuration Requirements

<Enter specific minimum configuration requirements associated with this technical subsystem component.>  

18.1.3 Processing

 

File Name Functional Description Location Inputs/Outputs

<Include the name of the actual source file of this algorithm / script.> <Include a description of what system functionality this algorithm/script addresses.> <Include the sub-directory in which this file can be located.> <Provide a summary description of inputs and outputs (optional).>

18.1.4 Outputs

<Provide information on the outputs generated from this technical subsystem component.>

18.1.5 Implications for Business Process/Operations

<List implications for user processes and operations generated from this technical subsystem component.>

18.2 <Technical Subsystem Component #2>

Repeat above for all subsystems.

19 Source Code Compiling and Linking

<Provide sufficient information so that a developer can compile and link the completed source code changes.  Include ‘make’ files as applicable.>

20 Supporting References

List supporting information for this project deliverable.  References made within the body of this deliverable should be listed.  Also reference any other documentation that is useful.  Examples are:

• Published controlled documentation (Do not list draft unpublished documentation)

• Governing Policy documentation

• Operating Procedures, Work Instructions and supporting documentation

• Supporting documentation which is not controlled documentation

• References to vendor, external and other manuals and instructions

 

Record Number Reference Title

 

21 Revision History

Version Author Date Revisions

 

22 Appendices

Enter Appendices in the following index and follow with appendices. 

Appendix Appendix Name

Appendix A Potential Solutions

Appendix A—Potential Solutions

List the technical solutions that were evaluated and how the service measured up against the project requirements and any evaluation/Proof-Of-Concept projects.  Include: 

• < Background >

 

• < Technical Details >

 

• < Product Comparisons >

 

• < Fit to Architecture Strategy >

Evaluate Different Solutions

There are a number of different ways of evaluating the criteria that are used to compare the different solutions.  Here are a few examples: 

Evaluation Description / Example

< Yes/No >  < Either the criteria are met or they are not.  For example: >

• < Criteria: The data must be virus-protected >

• < Measure: Yes or No >

< Ranking > < Rank the solutions in terms of their ability to meet the criteria specified.  For example: > 

• < Criteria: Weight must be less than 1.6Kg >

• < Measure: Rank those solutions which are less than 1.6Kg >

< Low / Medium / High > < Where the importance of the criteria is being considered.  This is sometimes a perceptive measure.  For example: >

< Criteria: What level of competitive advantage does the solution give us >

< Measure: Low/medium/high depending on the perceived advantage gained >

Technical Criteria Based on Evaluation

Strategic Emerging Solutions which could be reconsidered in 12-18 months

• • • •

Architecture Council Principles

Management Vendor

Risk Enabl. Comp. Adv Future needs Strat. Open Well Est. Direct

Low/Med/High Low/Med/High Low/Med/High Low/Med/High Yes/No Yes/No Yes/No Yes/No