生命周期选择的手册

1、目 录 TOC o 1-3 h z HYPERLINK l _Toc2606219 1. 目的 PAGEREF _Toc2606219 h 2 HYPERLINK l _Toc2606220 2. 范围 PAGEREF _Toc2606220 h 2 HYPERLINK l _Toc2606221 3. 职责 PAGEREF _Toc2606221 h 2 HYPERLINK l _Toc2606222 4.工作程序 PAGEREF _Toc2606222 h 2 HYPERLINK l _Toc2606223 41公司定义的软件生存周期模型 PAGEREF _Toc2606223 h 2 H

2、YPERLINK l _Toc2606224 42 软件生存周期模型的选择准则 PAGEREF _Toc2606224 h 2 HYPERLINK l _Toc2606225 4.2.1 瀑布模型选择准则 PAGEREF _Toc2606225 h 2 HYPERLINK l _Toc2606226 4.2.2增量模型选择准则 PAGEREF _Toc2606226 h 2 HYPERLINK l _Toc2606227 4.2.3快速原型选择准则 PAGEREF _Toc2606227 h 3 HYPERLINK l _Toc2606228 4. 3 软件生存周期模型 PAGEREF _To

3、c2606228 h 3 HYPERLINK l _Toc2606229 4.3.1 瀑布模型 PAGEREF _Toc2606229 h 3 HYPERLINK l _Toc2606230 4.3.2增量模型 PAGEREF _Toc2606230 h 4 HYPERLINK l _Toc2606231 4.3.3快速原型模型 PAGEREF _Toc2606231 h 4 HYPERLINK l _Toc2606232 4.4 各时期的任务、活动、工作产品和质量操纵 PAGEREF _Toc2606232 h 6 HYPERLINK l _Toc2606233 4.4.1 标准型 PAGE

4、REF _Toc2606233 h 6 HYPERLINK l _Toc2606234 4.5软件生存周期裁剪指南 PAGEREF _Toc2606234 h 8 HYPERLINK l _Toc2606235 4.5.1裁剪指南 PAGEREF _Toc2606235 h 8 HYPERLINK l _Toc2606236 5.参考资料 PAGEREF _Toc2606236 h 91. 目的指导项目组在制定项目开发打算时期，选择适合项目特点的生存周期，并能按照软件生存周期定义的工作流程进行工作。2. 范围本过程适用于新开发的软件项目。3. 职责 软件项目经理负责依照项目的特点选择合适的生存

5、周期。4.工作程序41公司定义的软件生存周期模型软件生存周期定义可视软件项目特性识不和所选软件开发模型而异，公司拟推举采纳的软件生存周期模型有 1、瀑布模型 2、增量模型 3、快速原型模型42 软件生存周期模型的选择准则 定义一个适用的软件生存周期是软件项目策划的基点，也是用以规范项目治理的重要手段。为此，对项目定义软件生存周期时，应首先依照各项目的特性和选择准则从本规范中选取一个合用的软件生存周期模型，随后再通过裁剪给出适用于本项目的软件生存周期定义。4.2.1 瀑布模型选择准则1、用户开始就给出明确的需求，且在开发过程中需求没有或专门少变化； 2、分析设计人员对应用领域专门熟悉； 3、低风

6、险项目（对目标、开发环境专门熟悉）；4、用户应用环境稳定；5、用户除提出需求以外，专门少参与开发工作；6、用户同意在项目的开发晚期才能得到程序的运行版本。4.2.2增量模型选择准则用户需求在整个项目开发过程中可能发生变化；客户同意分时期交付; 3、分析设计人员对应用领域不熟悉或难以全面把握; 4、中等或高风险项目（对工期过紧且可分时期提交的项目或对系统目标、开发环境不熟悉的项目）; 5、用户需要参与整个软件开发过程; 6、使用面向对象的语言或第四代语言。快速原型选择准则用户定义了软件的一般性目标，但不能标识出详细的输入、处理和输出需求开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式

7、；分析设计人员对应用领域不熟悉； 4、高风险项目;4. 3 软件生存周期模型软件生存周期按时期划分可分为需求时期、策划时期、设计时期、实现时期、测试时期、交付时期。4.3.1 瀑布模型瀑布模型规定了各项关键软件工程活动时期是自上而下、相互衔接、逐级下落如同瀑布的固定次序。当某时期发觉上游缺陷时可通过追溯予以消除或改进。S1需求 S2策划S4 实现S3 设计S5 测试S6交付 增量模型增量模型是遵循递增方式来进行软件开发的，融合了瀑布模型的差不多成分和原型模型的迭代特征。软件产品是被作为一组增量实现的，每一个线性序列产生一个可公布的增量，每一个增量均公布一个可操作的产品。 增量循环（2、3n）S

8、1需求S2策划 S3 设计S4 实现S5 测试S6交付 快速原型模型原型模型从需求收集开始，开发者和用户一起定义软件的总体目标，标识出已知的需求后，进行快速设计，导致原型的建立（原型不可作为正式的产品进行公布、交付），再进一步精化待开发软件的需求，通过逐步调整原型使其满足客户的要求，整个过程是迭代的。快速原型S1 需求S2 策划S4 实现S3 设计S5 测试快速分析，确定初步规格讲明构造原型运行/评价原型原型完成否要细部讲明否严格讲明细部效果中意否整理原型提供文档构造新原型修正与改进原型S6 交付 4.4 各时期的任务、活动、工作产品和质量操纵4.4.1 标准型序号时期任务与活动开始结束条件工

9、作产品S1需求时期T11同行、用户的需求收集、定义T12 编制特性需求讲明书T13对需求进行分析、定义需求讲明书T14需求变更T15制定软件验收打算T16对各种需求基线的审批Q11需求、软件验收打算评审Q12对需求的变更及实现情况检查、跟踪软件项目任务书需求、验收打算评审通过P11 特性需求讲明书P12软件需求讲明书*P13软件验收打算*R11需求、验收打算的评审记录R12软件需求与软件需求变更跟踪表R13培训记录R14软件需求治理检查表R15需求变更记录R16项目里程碑报告R17项目进展报告S2策划时期T21进行项目估算T22进行项目策划(含质量保证、配置治理策划)T23编制测试打算T24打

10、算的修订Q21打算评审T25策划培训T26分析设计时期工作预备(人员、培训、工具、设备)T27打算跟踪Q22对项目策划情况进行检查需求被签字认可后/项目打算书评审通过P21项目估算表*P22软件项目开发打算（含质量保证、配置治理打算） *P23软件测试打算P24风险治理打算 R21打算评审记录R22 打算修订记录R23 培训记录R24项目策划过程检查表R25软件项目跟踪与监督表R26项目进展和里程碑报告 S3设计时期T31项目设计(含软件构架、数据库、界面设计、系统功能例表)Q31设计评审T32 测试规程、用例预备T33项目打算的跟踪和修订T34实现时期预备 (人员、培训、可用件、模板、规范、

11、工具、实现环境建立)开发打算被确认设计文档评审通过P31概要设计 *P32详细设计P33测试规程、用例 *R31设计评审记录R32 项目打算修订记录R33打算跟踪情况检查表R34软件项目跟踪与监督表R35项目进展和里程碑报告S4实现时期T41构造软件(编码、自测)Q41单元测试Q42集成测试T42测试时期预备 (人员、培训、规范、工具、测试环境建立)T43编写用户使用手册T44制作安装盘T45对项目打算的情况进行跟踪设计文档批准后源程序测试通过P41源程序* P42测试用例数据 R41测试记录R42集成测试报告 P43用户使用手册 (电子版)* R43打算跟踪情况检查表R44软件项目跟踪与监督

12、表R45项目进展和里程碑报告P44安装盘S5测试时期Q51系统测试T51 BUG修订T52对项目打算的情况进行跟踪上游产品提交系统测试完成R51系统测试记录、报告 P51安装母盘 P52用户使用手册 (电子版)* R52打算跟踪情况检查表R53软件项目跟踪与监督表R54项目进展和里程碑报告S6交付时期T61编写实施打算T62编写培训大纲T63用户培训T64系统安装和数据预备T65系统试运行和系统切换Q61用户验收T66项目总结T67对项目打算的情况进行跟踪系统测试通过验收通过、项目总结提交P61实施打算P62培训大纲Q61 项目实施记录 P63 软件产品*Q62软件验收报告*P64项目总结报告

13、 *R61打算跟踪情况检查表R62软件项目跟踪与监督表R63项目进展和里程碑报告讲明：* 代表受控和必选项，当一个文档在某时期受控后，在以后的时期中它均受控。S 代表时期T 代表任务Q 代表质量保证活动P 代表需产生的工作产品R 代表需产生的工作记录4.5软件生存周期裁剪指南本文档中所推举的软件生存周期的三种模型是针对公司近几年所出现或将会出现的软件项目类型而定义的，但事实上，没有两个完全相同的软件项目，在诸多的因素中，组织的方针、规程、商务目标、猎取方法和策略、项目的规模和复杂性、系统需求、所采纳的开发方法、技术和开发环境以及项目组等诸多因素均会阻碍系统猎取、开发、操作和维护。因此，各项目在

14、使用本标准时，需依照本项目的特性加以裁剪。但在裁剪过程中必须遵循以下原则：时期衔接原则：所裁剪的生存周期各时期间应是相互衔接的。一个时期的里程碑工作是下一时期的输入。切忌从需求时期，跃过分析设计时期直接进入编码实现时期。合理性原则：每个生存周期时期中所列的各个活动、工作和质量操纵点，可视项目大小能够合理的增加或合拼。如某些大项目，可增加一些对子项目、子工作产品或子活动的质量操纵点；小项目或增补少量功能点的项目可将一些质量操纵点加以适当合拼，但在打算中必须对合拼的理由做出讲明。可视化原则： 生存周期各时期中必须明确列出任务、活动、工作产品与质量操纵点。 具体裁剪步骤见4.5.1 裁剪指南。4.5

15、.1裁剪指南 裁剪最好针对特定项目或合同进行。 4.5.1.1生存周期时期的截取 在生存周期模型被选定后，可视项目、生存周期模型、源输入和最终输出的特性，截取相邻的一个或多个相邻接的时期，例如，所选的是瀑布模型，对非交付类软件项目能够截取需求定义、策划、设计、实现、测试五个邻接的时期。4.5.1.2 生存周期时期合并和细分 对所截取的两个相邻时期，对有些小项目来讲，可把两个相邻时期合并成一个时期，例如，把瀑布模型中的设计和实现两个时期合并一个时期。相反，对大项目来讲，又可把一个时期拆分成两个时期，例如把瀑布模型中的设计时期拆为概要设计和详细设计两个时期。但对合并时期应讲明理由。 4.5.1.3 任务的裁剪 在本标准的生存周期每个时期中均列有推举的任务(活动)，有些是必选(带*)的，有些是可选的。关于必选项，如不选时，应讲明理由。如需要，也可增加某些本标准中未列出的任务，例如培训、外包、外购软件、现场安装、数据预备等。4.5.1.4工作产品的裁剪 在本标准的生存周期每个时期中均列出了若干推举的工作产品和记录。有些是必选(带*)的，有些是可选的。关于