设计过程.doc

设计过程Version 1.1Document Lending Record Name of Document：Signature of Borrower：Date of lending：Instructions of Principal of Document:Date:Date of Repayment：Signature of Document controller:设计过程Version 1.1文档名称：设计过程修订历史记录日期版本号修改说明修改人核准人目录1目的42范围43术语、缩写词44职责45过程概述45.1简要说明45.2流程图55.3规程清单56过程规范56.1概要设计56.2详细设计77输出结果和记录98裁剪指南99附录9设计过程1 目的设计是根据软件需求规格说明书中所描述的需求模型，得到系统设计模型，对系统如何实现进行描述。设计过程是需求与编码之间的桥梁，是系统开发中非常重要的一个环节。本文件的目的是描述设计应该遵循的过程规范，以确保系统的设计工作按规范进行。2 范围设计过程包括概要设计、详细设计两个阶段。本文档对这两个阶段进行说明。3 术语、缩写词概要设计分析各种解决方案，定义软件体系结构的过程。详细设计对概要设计的结果进行详细规格化的过程。4 职责系统设计员负责对系统进行设计。系统分析员负责向系统分析员解释与需求相关的一些问题。项目经理负责安排设计给相关的系统设计员；负责安排设计文档的评审。软件开发人员负责如果设计中采用原型方法，开发人员可能负责编写原型。软件测试人员负责根据设计文档开发集成测试用例。5 过程概述5.1 简要说明在需求开发工作完成之后，项目经理分配设计任务给系统设计员，系统设计员根据需求开发阶段产生的各文档进行设计。系统设计员要确定设计目标，选择设计的方法学，进行概要设计、详细设计。设计的结果要生成设计说明书，经过评审后进行配置管理。5.2 流程图5.3 规程清单设计过程包括2个主要的规程：概要设计，详细设计。1. 概要设计 ： 收集相关资料，确定设计目标，完成系统的架构设计。2. 详细设计 ： 在概要设计基础上，确定接口的详细规格说明。6 过程规范6.1 概要设计目的：收集相关资料，确定设计目标，完成系统的架构设计。Entry Criteria1已经成功地结束了需求开发过程，或者软件需求规格说明书已经可以稳定地支持设计工作。2项目经理指定系统设计员进行设计工作。Inputs1软件需求规格说明书2需求追踪矩阵3需求阶段其他文档4如果是增强型系统，需要已开发系统的相关文档:n 以前的SRSn 以前的概要设计说明书n 以前的用户手册n 缺陷列表n 等等Steps1PM和SA把需求阶段相关资料移交给SD。2SD研究资料并就有疑问的地方与PM、SA等人进行探讨。3SD根据项目特点，非功能性需求，综合各方面情况，确定项目的设计目标。后面的设计都将遵循此处所确定的设计目标。4SD确定在概要设计时是否采用原型的方式辅助设计过程的进行。要考虑的主要因素是:n 合同中是否有此种规定。n 本项目是否来自于一个新的领域，大家都没有该领域的经验。利用原型可以加深理解或者有助于达成一致，有利于设计决策的制定。如果选定利用原型的方式进行辅助，必须确定原型为抛弃型还是增量使用型。原型的开发可以是SD，也可以是软件开发人员。5SD根据得到的资料，依据设计目标开始设计工作。工作的主要方面有：n 选择设计方法学：比如使用面向对象设计方式或者结构化设计方式，并且有一个成熟的方法论作为指导。n 子系统分解：对系统进行分层、分区等处理，得到组成系统的子系统，降低系统复杂度。n 确定子系统的服务：定义子系统提供的服务，以及对其他子系统服务的使用情况。此处的服务不需要对接口做详细地规格说明。n 设计对象模型：对需求分析中产生的对象模型进行整理，添加解决域实体，根据一些设计模式或者解决问题的需要，对系统中的实体以及它们之间的关系进行整理。n 确定系统的构件模型：比如有哪些动态库，哪些COM组件等；确定哪些类或者文件属于这些构件；确定构件之间的依赖关系。n 确定系统硬件分布情况：比如是客户机/服务器，还是分布式系统，并且用模型建立它们的关系。n 确定软件和硬件的映射关系：哪些构件放到哪些机器上。n 确定系统的数据管理策略：确定对实体的管理是利用内存对象、文件还是数据库方式，并进行建模。n 设计在系统的边界处理：比如初始化、退出、异常处理等情况下系统行为规则。n 等等以上的步骤，要在实际中根据实际情况进行组合，不断迭代，最终完成概要设计工作。6SD撰写 概要设计说明书：n SD对系统的概要设计基本完成后，进入概要设计说明书的编写阶段。n 选择说明书的模板。n 根据模板规格，对设计结果进行记录。7概要设计说明书 评审：n SD完成了概要设计说明书。n PM负责安排评审委员会人员和评审时间，评审参加人员参见评审人员组成指南。n 按照 同行评审过程 进行概要设计说明书的评审。n 如果评审不通过，SD回到第5或第6步，继续进行概要设计工作。n SD对评审中确认的问题进行修正。8PM安排相关人员更新需求追踪矩阵，组织设计人员，分析人员对需求追踪矩阵进行评审。9配置管理员将概要设计说明书、需求追踪矩阵纳入配置管理库，形成概要设计基线。Outputs1概要设计说明书2概要设计说明书评审记录3系统原型（如果创建了原型）4更新的需求追踪矩阵Exit Criteria1概要设计说明书通过评审。2需求追踪矩阵通过评审。6.2 详细设计目的：在概要设计基础上，确定接口的详细规格说明，缩小与编码的差距。Entry Criteria1概要设计阶段已经成功完成Inputs1概要设计说明书2需求追踪矩阵3系统原型（如果已经创建）4如果是增强型系统，需要：n 现存系统的详细设计文档n 现存系统的代码n 现存系统的其他文档Steps1SD进行详细设计准备：n SD收集概要设计阶段的各相关文档，进行整理。n 收集 编码规范 等与详细设计有关的规范。2SD根据情况决定是否进行界面设计：n 根据项目情况，SD决定是否要进行用户界面设计。n 如果需要进行用户界面设计，SD组成相关人员对系统界面的组成、风格、公共资源等进行设计。3SD开始进行模块与数据库的详细设计：n 对概要设计中的子系统服务进行规格化，完成接口的规格说明，包括函数名称、参数、返回值等。对面向对象系统，还要设置成员函数的可见性（piblic、private、protected）等。n 如果在需求分析与概要设计中，实体关系有一对一、一对多，多对多等的描述，要具体到编程语言支持的粒度。比如2个类是一对一的关系，就要在2个类中各添加一个指针指向对方，并且添加成员函数保证这种关系被正确实现。n 对一些影响性能的问题做出最后的决策，比如是使用数组还是使用链表，或者是具体算法的选择。n 对一些比较重要的接口做出比较详细的定义，比如定义函数的调用约束，说明其调用的条件，产生的影响，限制条件等。n 如果采用面向对象的设计，建议使用CASE工具，比如Rose来进行详细设计。CASE工具一般支持正向工程与逆向工程，可以很编码阶段的工作很好结合，并且模型易于维护。n 如果系统中利用了数据库来保存数据，SD将对数据库中进行详细设计。这包括确定数据的类型、精度、约束等细节问题，考虑数据库的优化问题，权限实施问题等方面，完成对数据库的设计工作。在进行数据库设计的时候，强烈建议使用CASE工具，比如Visio或者Rose，利用工具生成设计模型。工具一般都可以直接生成DDL代码，并且模型清晰易读。可以将设计的模型作为模块设计说明书的附件。如果是增强型系统：n 在详细设计的时候，要关注对现有系统将做哪些更改，并维护与现有系统的风格一致，考虑现有系统更改后的可维护与可读性等问题。4SD发现并修改概要设计中的问题：n 概要设计于详细设计做为一个大的阶段，在详细设计中可能会比较多地根改概要设计阶段的模型。n 如果是采用CASE工具，那么可能详细设计模型是概要设计模型的不断细化。n 详细设计人员与概要设计人员要密切合作，对于更改，他们之间达成一致即可，原则上不需要进行正规的评审。5软件测试人员开发集成测试文档：n 如果详细设计已经足够稳定，PM安排软件测试人员进行集成测试文档的编写。n 集成测试文档包括集成测试计划与集成测试用例。n 软件测试人员根据各模块的划分，模块之间的接口，设计集成测试用例，对各模块之间的接口进行测试。n 测试用例的编写根据实际情况进行安排，有可能会持续比较长的时间，甚至超过设计阶段。n 在编写集成测试期间，测试人员如果发现设计中的问题，要及时汇报给项目经理或者设计人员。6SD记录详细设计结果。n 对于面向对象的详细设计，可以把设计结果直接记录在所用的CASE工具的模型中，比如rose的文件中。n 对于其他的设计方式，模块设计可以使用模块设计说明书模板进行整理，用户界面设计可以使用用户界面设计说明书进行整理。7详细设计结果评审:n SD完成了详细设计相关说明书或者模型的编写。n PM负责安排评审人员和评审时间，评审参加人员参见评审人员组成指南。n 评审人员按照 同行评审过程 进行详细设计文档和修改过的概要设计文档的评审。n 如果评审不通过，则SD回到第2或者第3步，直至评审通过。n SD对评审中确认的问题进行修正。8配置管理员将已经确认的概要设计文档和详细设计文档纳入配置管理，并建立软件设计基线。9测试文档评审：n 测试人员完成了测试文档的编写。n PM负责安排评审人员和评审时间，评审参加人员参见评审人员组成指南。n 评审人员按照 同行评审过程 进行测试文档设计文档的评审。n 如果评审不通过，测试人员继续进行测试文档的修改，直至评审通过。n 测试人员对评审中发现的问题进行修正。10配置管理员将已经确认的测试文档纳入配置管理库。11PM安排相关人员根据详细设计与集成测试文档中的内容更新需求追踪矩阵。组织设计与测试人员对跟踪矩阵进行评审。12配置管理员将确认的需求追踪矩阵纳入配置管理库。Outputs1详细设计相关文档2详细设计文档评审记录3修改后的概要设计文档4集成测试计划5集成测试用例6集成测试文档评审记录7更新了的需求追踪矩阵Exit Criteria1详细设计文档通过评审。2集成测试计划与用例通过评审。3需求追踪矩阵通过评审。7 输出结果和记录概要设计说明书项目实施期间由项目经理保管，项目结束后由业务部门保管。模块设计说明书项目实施期间由项目经理保管，项目结束后由业务部门保管。用户界面设计说明书项目实施期间由项目经理保管，项目结束后由业务部门保管。设计模型项目实施期间由项目经理保管，项目结束后由业务部门保管。概要设计评审记录项目实施期间由项目经理保管，项目结束后由业务部门保管。详细设计评审记录项目实施期间由项目经理保管，项目结束后由业务部门保管。系统原型项目实施期间由开发组进行开发与维护，正式实施后或者抛弃或者变为正式产品。集成测试计划项目实施期间由项目经理保管，项目结束后由业务部门保管。集成测试用例项目实施期间由项目经理保管，项目结束后由业务部门保管。集成测试文档评审记录项目实施期间由项目经理保管，项目结束后由业务部门保管。需求追踪矩阵项目实施期间由项目经理保管，项目结束后由业务部门保管。8 裁剪指南1对于一些开发工作量较小或者较成熟的项目，根据所选择的生命周期，可以合并概要设计与详细设计为一个阶段，即设计阶段，并可以对所用到的文档与模板进行选择与裁剪。另外，概要设计阶段的文档是否作为基线，也可以根据所选择的生命周期进行决策。2根据选择的生命周期与项目实际情况，在详细设计文档通过评审之后，项目经理可以决定是直接进入下一个阶段还是等到测试文档与需求追踪矩阵评审后再进入下一个阶段。3是否要生成模块设计说明书以及用户界面设计说明书可以根据项目选择的生命周期以及项目组实际情况进行确定。4集成测试计划，集成测试用例，集成测试评审记录等可以根据所选择的生命周期进行裁剪。5设计过程中用到的各种等文档的模板，应尽量从公司规定的模板中选取。项目组可以根据项目实际情况，对模板