- 行業(yè)新聞
-
上海翻譯公司業(yè)務技術(shù)手冊英文翻譯
發(fā)布時間：2018-02-04 17:21 點擊：
上海翻譯公司業(yè)務技術(shù)手冊英文翻譯
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 IntroductionThis documentation is intended to capture architecture and design specification for <project name>.2 Architectural Goals and ConstraintsTo be completed during Requirements Stage2.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 & AlignmentTo be completed during Requirements Stage3.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 ViewTo be completed during Design Stage4.1 Architecturally Relevant Use Case RealizationsTable 1 - Architecture impact of key use casesUse Case ID Use Case Name Architecture ImpactNone4.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 & sequencingo Message format and semanticso Supported technology channelso 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 ViewIf 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 ViewTo be completed during Design Stage6.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 ViewTo be completed during Design Stage7.1 <Component Name><Insert description of data structure>7.2 <Component Name><Insert description of data structure>8 Size and Performance8.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 Guidelines9 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 Description11 File Naming ConventionsDesign Item Naming Convention Description12 Development TechnologiesApplication Tool, System, Database,Platform, Etc. CommentsApplication DevelopmentBrowserBusiness RulesClient Server ArchitectureDatabaseDatabase AccessDatabase OS PlatformSecuritySoftware Version Control13 Database DesignEnter 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 DesignSource Databases:Source Elements:Validation Rules:Processing Rules:Conversion Component:Conversion Contingency Arrangements:Reporting Controls:Data Security:15 System Interface Design15.1.1 Interface Technical RequirementsInterface Technical Requirements<Technical Requirements ID> <Provide a list of technical requirement statements covering the interfaces for the system.>Hardware InterfacesHardware Devices <List the actual hardware devices your application will interact with and control.>Supporting Devices <List the devices which are supported.>Software InterfacesName <List the name of the software product.>Specification Number <List the specification number.>Version Number <List the version number.>Communications InterfacesProtocols <List the network protocols to directly interact with.>Data InterfacesData processing <List the support functions for data processing.>Back up and Recovery <List the operation for backup and recovery.>16 Time Zone SpecificationsWhat 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 Components18.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 ProcessingFile 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 ReferencesList 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 instructionsRecord Number Reference Title21 Revision HistoryVersion Author Date Revisions22 AppendicesEnter Appendices in the following index and follow with appendices.Appendix Appendix NameAppendix A Potential SolutionsAppendix A—Potential SolutionsList 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 SolutionsThere 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 EvaluationStrategic Emerging Solutions which could be reconsidered in 12-18 months• • • •Architecture Council PrinciplesManagement VendorRisk Enabl. Comp. Adv Future needs Strat. Open Well Est. DirectLow/Med/High Low/Med/High Low/Med/High Low/Med/High Yes/No Yes/No Yes/No Yes/No世聯(lián)翻譯-讓世界自由溝通！專業(yè)的全球語言翻譯供應商，上海翻譯公司專業(yè)品牌。絲路沿線56種語言一站式翻譯與技術(shù)解決方案，專業(yè)英語翻譯、日語翻譯等文檔翻譯、同傳口譯、視頻翻譯、出國外派服務，加速您的全球交付。 世聯(lián)翻譯公司在北京、上海、深圳等國際交往城市設(shè)有翻譯基地，業(yè)務覆蓋全國城市。每天有近百萬字節(jié)的信息和貿(mào)易通過世聯(lián)走向全球！積累了大量政商用戶數(shù)據(jù)，翻譯人才庫數(shù)據(jù)，多語種語料庫大數(shù)據(jù)。世聯(lián)品牌和服務品質(zhì)已得到政務防務和國際組織、跨國公司和大中型企業(yè)等近萬用戶的認可。
