设计与编码过程文件(TS)

AsiaInfo项目管理文档技术解决方案过程文件编写李梅编写时间2004-8-23审批刘丰（研发部总经理）审批时间2005-8-18文档版本V2.0科技（中国）有限公司版权所有文档中的全部内容属XXX科技（中国）有限公司所有，未经允许，不可全部或部分发表、复制、使用于任何目的。亚信科技（中国）有限公司版权所有文档中的全部内容属亚信科技（中国）有限公司所有，未经允许，不可全部或部分发表、复制、使用于任何目的。文档修订摘要日期修订号描述著者审阅者日期2004-8-161建立文档总体结构和基本内容李梅2004-8-312加入DAR在选择产品组件和Make-Or-Buy中的启动应用李梅2004-9-213根据第一次评审的结果进行修改李梅2004-9-224将各种技术评审的结果直接记录在AIQCS系统，不再要求单独出评审报告。李梅2004-10-155增加《数据库设计规范》、《用户界面设计规范》的使用环节。李梅2005-08-056去掉单元测试和产品集成的内容刘炜2005-08-157修改流程图，和引用文档名称刘炜2005-08-178根据OSSP定义修改文档格式刘炜2005-8-189增加文档引用链接刘炜2005-11-1110修改文档中的链接；对于关键模块的详细设计要求进行正式评审，非关键模块的详细设计不做要求。李梅2005-11-1911修改3.2.4中有关单元测试说明：1．增加单元测试流程参见《V&V&PI过程文档》的说明；2．将输出产品的“单元测试Case”去掉，放到《V&V&PI过程文档》中单元测试的输出中张云霞2006-3-3012更新流程图李梅2006-4-113在3.2.1.2增加JSP前台开发选型中，必须把APPFrame平台作为首选方案吴晓洁ii目录第1章引言···········································································································11.1文档用途········································································································11.2适用范围········································································································11.3阅读对象········································································································11.4名词术语········································································································11.4.1产品········································································································11.4.2产品组件··································································································11.4.3技术数据包·······························································································11.4.4可操作性概念····························································································21.4.5可操作性场景····························································································21.4.6配置项·····································································································2第2章角色和职责.....................................................................................................................1第3章技术解决方案·······························································································23.1流程图···········································································································23.2过程描述········································································································33.2.1选择产品组件····························································································33.2.2产品总体设计····························································································33.2.3产品详细设计····························································································43.2.4编码和单元测试·························································································51第1章引言1.1文档用途本文档为技术解决方案过程文档。它指导项目组成员完成产品的总体设计、详细设计、编码、单元测试和集成工作。1.2适用范围本过程适用于XXX研发部门产品开发工作。1.3阅读对象过程改进小组EPG成员项目经理总工程师产品设计工程师产品开发工程师组织高级经理1.4名词术语1.4.1产品Product，产品是一个过程的输出结果，并把它发布给用户或最终使用者。1.4.2产品组件ProductComponent，产品组件是产品低层次的组成部分。产品组件集成为产品。可能有多层次的产品组件。产品组件是一种被工程化的、用来达到产品用途的、最后发布给客户的产品。1.4.3技术数据包TechnicalDataPackage，技术数据包是一些元素的集合，这些元素和一种类型的产品或产品组件相2关。例如：产品总体结构描述确定的需求产品组件描述产品相关生命周期过程描述（如果没有在独立的产品组件中描述）关键产品特性必须的物理特性和约束关系接口需求保证需求被满足的验收条件可操作性场景1.4.4可操作性概念OperationalConcept，可操作性概念是一个实体如何被使用或被操作的通用性描述。1.4.5可操作性场景OperationalScenario，可操作性场景是一组事件设想发生顺序的描述。它包括产品与环境、与使用者以及与产品组件之间的相互关系。可操作性场景常常被用作评估需求、系统设计和验证、确认系统上。1.4.6配置项ConfigurationItem，配置项是配置管理中所有工作产品的集合。它在配置管理过程域中被当作一个独立的实体对待。1第2章角色和职责在技术解决方案中，涉及的角色有项目经理、总工程师、产品设计工程师、产品开发工程师、高级经理。他们的主要职责如下：角色职责项目经理1.负责组织项目组成员完成技术解决方案设计工作2.负责组织对技术解决方案的评审总工程师负责技术解决方案的评审工作产品设计工程师1.负责产品总体设计工作2.负责指导开发工程师完成产品详细设计工作产品开发工程师负责产品详细设计、编码、单元测试和集成工作高级经理选择参与技术解决方案的评审2第3章技术解决方案3.1流程图需求开发与管理流程图PPQA开发工程师总工程师项目组设计工程师组织结束产品总体设计是否通过评审？选择产品组件技术解决方案组织方针产品详细设计是编码和单元测试DAR过程选择否参与33.2过程描述3.2.1选择产品组件3.2.1.1概述项目组需要遵循统一的选择原则，在各种备选方案中确定最终用于本项目开发的产品组件，同时给出这些产品组件之间的关系和它们与外部的接口关系。3.2.1.2主要活动1.产品设计工程师确定项目中要使用的产品组件的各种可备选方案和选择标准。选择标准通常考虑如下因素：成本（如，开发、购买、支持费用等资金成本）技术性能指标、技术局限性产品组件的复杂度产品可扩展性最终用户或使用者的能力风险（如，成本风险、工期风险、技术风险）2.设计产品组件的可操作性概念和可操作型场景，即该产品组件今后会在什么情景下被使用。（如，UseCase）3.启动《DAR规程》中定义的流程，从各种备选方案中进行选择，形成该项目《产品总体设计规格说明书》中的“基础结构”部分。4.在开发CRM系统的JSP前台应用程序时，需要使用APPFrame平台工具。如果不选择此工具，需要有DAR分析报告说明选择其它方案的原因。3.2.1.3输入、输出入口准则《软件需求规格说明书》已获取出口准则用于项目开发的产品组件已选择并文档化输入工作产品《软件需求规格说明书》《DAR过程》输出工作产品《产品总体设计规格说明书》中的“基础结构”部分《决策分析与制定报告》3.2.2产品总体设计3.2.2.1概述产品设计工程师按照《软件需求规格说明书》设计系统的体系结构，定义每个模块的主要功能和模4块之间的联系，并确定系统的数据体系结构，然后再对设计结果进行评审确认。3.2.2.2主要活动1.产品设计工程师对《软件需求规格说明书》进行分析和了解。依据《产品总体设计规格说明书－模板》（规范），进行产品总体设计，形成《产品总体设计规格说明书》。包括：系统体系结构设计（包含的模块和功能）系统数据结构设计系统接口设计产品基础平台的选择2.项目经理参照《评审规程》，负责产品总体设计评审的组织工作。组成评审委员会PPQA参加评审工作形成产品总体设计评审报告，记录在AIQCS系统中3.将产品总体设计活动的相关内容参考《CM过程文档》要求，放入配置库中进行管理。3.2.2.3输入、输出入口准则《软件需求规格说明书》及相关模型经过评审并进入项目的配置管理库；用于项目开发的产品组件已选择并文档化出口准则产品总体设计完成，通过评审。输入工作产品《软件需求规格说明书》《项目愿景和范围》《产品总体设计规格说明书－模板》（规范）《评审规程》《产品总体设计评审检查表》输出工作产品《产品总体设计规格说明书》AIQCS系统评审记录3.2.3产品详细设计3.2.3.1概述产品详细设计是开发人员根据《产品总体设计规格说明书》进行模块设计，将产品总体设计所获得的模块按照单元、程序、过程的顺序逐步细化，详细定义各个单元的数据结构、程序的实现算