《软件生命周期详解全套.docx》由会员分享，可在线阅读，更多相关《软件生命周期详解全套.docx（22页珍藏版）》请在三一办公上搜索。
1、软件生命周期详解1.模型介绍1.1前言制定软件生命周期(SoftwareLiftCycle,SLC)的目的是确定项目应该采用的软件生命周期模型，统筹规划项目的整体开发流程。软件生命周期是组织软件标准过程模型的重要组成部分。本文档阐述了周期模型选择的规程,该规程的目标、角色与职责、启动准则、输入、主要步骤、输出、结束准则和度量在CMMl相关文档中均已定义。1.2说明软件生命周期是指从设想软件产品开始到软件不再供使用为止的时间间隔。对生命周期细分阶段进行管理称为周期模型，典型的几种生命周期模型包括瀑布模型、瀑布迭代模型、原型迭代模型、XP模型等。项目组应在软件项目启动阶段认真考虑项目的特征和目标的
2、基础上参考原有模型和组织软件标准过程，运用过程裁减指南为项目开发裁减出一个软件生命周期模型。无论选择何种模型，都要包括下列一般软件工程过程必须包含的内容：1.需求2.设计3编码4.集成5测试2.软件生命周期定义2.1目标本规程的制定是为了在项目实施过程中能够有一个统一的方法来分析项目需求预先识别项目特征并提供可供项目选择的软件生命周期模型，使其可以和OSSP结合在一起使用。2.2角色与职责角色职责说明项目经1）归纳软件项目实施需求理2）根据类似项目的开发经验，识别项目特征3）提出项目实施参考模型4）与项目成员一起讨论裁剪模型项目成1）总结类似项目的开发经验，识别项目特员征2）裁剪项目实施参考模
3、型2.3启动准则从项目启动阶段开始2.4输入需求规格说明书2.5主要步骤软件生命周期模型一般都是在原有的软件生命周期模型基础上根据客户的需求范围和目标实现来判断项目的特征，进而进行模型裁剪后产生。一般包括四个步骤：需求识别分析、原型参考、裁剪定义和模型实施。2.5.1需求识别分析从需求被识别，并且明确了需求目标开始，就进入项目启动阶段，这个时候项目组开始组建，同时开始收集需求，项目经理策划，安排有经验的人员进入项目组,迅速对需求进行初步分析,概括项目的特征。此部分的需求分析还应该包括对历史项目的回顾，总结成功实施经验吸取失败教训，并归档备案作为组织的知识库。2.5.2原型参考当项目需求目标确定
4、，同时识别出项目特征，从常用软件生命周期模型中挑选出一个模型以供参考,该周期原型必须在很大程度上适合项目的具体特征以及能够结合组织标准软件过程一起使用。项目一开始，挑选后的软件生命周期模型仅作参考，下一步还必须结合实际的越来越丰富的需求进行裁剪以形成最终的项目指导模型。最终的项目指导模型可以归档成为下一个类似项目的原始参考模型。原型的描述主要包括软件生命周期模型的原理、优缺点、选用规则。2.5.3裁剪定义0裁剪基于项目特征项目特征是裁剪工作的出发点,包括项目规模（如大、中、小等）、项目类型（如新开发、外包、升级等），以及技术难易度、产品类型、项目的时间和质量要求等要素。0明确可裁剪的对象可裁剪
5、对象确定了裁剪的内容范围，可裁剪对象不仅仅限于过程元素和活动，还包括参照标准、方法和工具、输出成果物及模板等。0确定裁剪所考虑的要素裁剪要素界定了裁剪的方向和尺度。例如，对于某个裁剪对象,其范围、频度等都是裁剪要素。对于有开发经验的小项目，可以适当减少对于技术方面的评审的频度。0裁剪的决定要基于风险进行考虑基于风险可检验裁剪的适当性。对过程或活动的调整或放弃需要通过分析其所带来的风险和影响再做决定。2.5.4模型实施裁剪后的新周期模型，是个适应项目特征的项目标准软件过程，该过程包含软件生命周期模型的原理、优缺点等描述，能够帮助软件开发人员更好地理解和运用此生命周期进行项目开发。新周期模型对于项
6、目开发具有指导意义，必须将该模型下达通知到项目组所有成员，项目经理必须监督保证此模型的实施与推广，实现项目可控，质量可靠的最终目标。2.5.5输出项目已定义过程（PDP）2.6结束准则项目结项。2.7度量度量的目的是统计用裁减后的软件生命周期模型指导项目过程进展后，此项目产生的所有工作量。同样的软件项目，实施不同的周期模型，项目的总的工作量也是不同的，好的周期模型不仅能够大大缩减工作量，同时也保证代码的质量。不合理的周期模型则会因为保证质量的需要引入重复的各类阶段审查，进而产生更多、更冗长的无法跟踪维护的文档导致项目失败，或者忽略关键性的阶段审查而带来需求的不明确及代码的重复返工，同样也导致了
7、项目失败。软件生命周期模型的引入，将对项目过程划分成几个不同的阶段，规模较大的项目则阶段内还分更多小的阶段，每个阶段都将对本阶段内产生的成果物进行审查。因此，如何估算审查的工作量也必须包含在此度量活动中。3.常用软件生命周期模型软件项目生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。软件项目生命周期一般包括售前阶段、需求阶段、设计阶段、实现阶段、测试阶段、部署上线阶段、运行和维护阶段等。由于软件实施组织是为不同的商业客户生产软件，所以传统的软件项目生命周期不可能适用于公司所有软件项目的实施情况,为此EPG在软件工程学科的传统生命周期的基础上，综合了组织所有项目的特征，定义出了一个大
8、而全的生命周期模型。每个软件项目可以在可选择软件周期参考模型的过程中，结合组织标准软件过程，运用过程裁减标准进行裁减，从而成为项目的实施标准过程。3.1产品或定制型项目生命周期模型标准瀑布生命周期模型3.1.1标准瀑布生命周期模型（V）标准瀑布生命周期模型适用于公司内部研发项目、为客户开发系统的项目、二次开发和推广移植的项目。模型用图形的方式来描述，显示了它们应用的阶段及其输入/输出。描述了在何种条件下使用该模型，需要注意风险和应用裁剪的指导。当开发的系统规模和复杂度较高，达到需要采用多层设计时,推荐使用标准的生命周期。最终的系统被分解为多于一个的子系统。每个子系统由一个或多个模块组成。每个模
9、块由一个或多个单元。一个单元是最小的可独立测试的单位。用于集成测试的模块测试计划和集成测试计划中的模块就是从单元而来，子系统从模块而来。使用指南：0需求很好地被理解了且期望是相对稳定的。0解决方案的技术和架构被很好地理解。0高可维护的和可支持的解决方案的需要。0所有中间交付物受控的基线具有良好的可视性和可靠性。优点：0对管理层提供实施可视性。0由于需求相对稳定度较高，其时间表具有很好的稳定度。注意事项:0在不清晰、不稳定的需求和技术条件下不能很好工作。0由于在一个阶段结束时要做很多文档并要所有的干系人签字,有很大的开销。0所有的干系人都要在每一个阶段结束时进行说明或签字。0根据工作量和时间分析
10、，由于项目范围的改变而导致的中途更正是花很大代价的。裁剪指南：0模块测试计划和集成测试计划可以组合在一个文档中。0这个模型中的阶囹口检查点都不能做变更。3.1.2V-瀑布生命周期为关键产品(VC)瀑布生命周期为关键产品该模型是经过裁剪的模型。推荐在中等复杂度和规模的项目中使用，在这些项目中解决方案可以用两层来表示。系统由多于一个模块组成，同时每个模块又是由一个或多个单元组成。这种模型在软件可靠性要求很高是被选择,要求除开发者以外的人来进行测试。对这个生命周期来说，单元测试是必要的。使用指南：0安全/任务关键软件开发0整个开发过程中的可跟踪性和透明性的需求0控制开发的需求(成本、范围和时间表)优
11、点：0正规化保证了经过高度测试后形成可靠的系统注意事项：0在开发过程中，最终用户不可视。0在测试计划评审中包括顾客。裁剪指导：0这个模型中的阶段和检查点都不能做变更。3.1.3阶段V-瀑布生命周期(V4)阶段V-瀑布生命周期该模型适合于对正规化程度低的小到中型项目。系统的规模和复杂度低，可以用一层设计来表示。最终的系统可以用一个或多个单元来构成。在这个生命周期中单元测试是必要的。使用指南:0项目的工作量，周转时间中等0产品复杂度和团队规模中等0需求和技术比较好地被理解0比V瀑布在周转时间的性能上要更好。优点：0对时间表有中等的控制0中等的开销0对交付的解决方案有合理控制注意事项：0在开发过程中
12、，最终用户不可视。0对很复杂的项目不建议使用，因为它只提供了一层设计。裁剪指导：0这个模型中的设计阶段是由VC模型中的概要设计和详细设计组合而成的。只有一层设计和测试的文档是必需的。0在V模型需要测试计划同所测试的开发一同被评审和基线化时,T项目可以在每个测试计划被评审和基线化时裁剪和设置检杳点。然而测试计划活动一定要在阶段指示的地方启动，如ST计划一定要在RA&P阶段启动。3.1.4演示生命周期(D)演示生命周期这个模型仅适合用于一个演示的系统开发，最终其将会被丢弃,它形成的成果将是对开发概念的证明。如果在其原型出来之后需要对此项目进行产品化，需要对这个开发的软件进行详细评估。调查阶段是在S
13、C检查点之前的所有阶段的合并。调查、分析、计划和设计活动都在这个阶段进行。使用指南：0很小范围和团队规模-可能1或2人的团队。0低开发成本，高周转时间。0不能提供训练有素的经历和开发者。0项目失败影响低。优点:0很彳氐(可能最低)成本。0中途修正是容易和便宜的。注意事项0不可靠的时间表。0产品不可靠或没有扩展项。0对管理层和顾客几乎都是不可见的。裁剪指导：0根据产品的需要在发布阶段的交付物要在整个SVW交付集中选择。要建立这些交付物一致的基线。3.1.5进化开发模型（EVO）:进化开发模型进化开发模型（EVO）是一种迭代的模型，可用来降低大项目的风险。风险可以有很多种类，这个模型的每一个迭代或
14、发布都针对了特定的风险集合。风险可以是对需求理解不清楚、新技术的使用、架构的可行性、潜在的性能问题等。每Y迭代都有不同的模型作为基础。使用指南：0中到大项目，可靠性和最终用户的可视性很重要。0需求、架构和技术都没有很好地理解。0最终产品要有好的扩展性。优点：0对管理层和顾客有很高的可视性。0风险管理容易。0中等的成本，至少提供了相对稳定的时间表。注意：0需要有很有经验的和成熟的管理。0对每个周期的管理和文档都有成本。0中途修改要明确定义，包括对原型周期。0在迭代过程中发生巨大的变化会导致成本花费和缺乏可靠性及扩展性。裁剪指导：0每一个迭代都有不同的模型作为基础，这些模型是从前面几种基本瀑布模型
15、选出的，遵循它们的裁剪指导。在每个迭代中可以使用不同的模型。3.1.6生命周期模型裁剪说明裁剪项类型（活动或_1_作产品）裁减要素（增加、删除、修改）裁减条件标准瀑布生工作产品删除模块测试计划与集命周期模型成测试计划可合并模块测试计曲-个文档中。划进化开发模活动修改每一个迭代可使用型不同的基本瀑布模型，并遵循其裁剪指导。3.1.7生命周期模型使用指南汇总生命周期模型使用指南优点注意事项标准瀑布生命周期模型L安全/任务关键软件开正规化保证了经过高度1在开发过程中，最终用户不可发测试后形成视。2整个开发过程中的可跟踪性和透明性的需求3.控制开发的需求（成本、范围和时间表）可靠的系统2.在测试计划评
16、审中包括顾客。V瀑布模型L安全/任务正规化保证1在开发过程中，为关键产品关键软件开了经过高度最终用户不HJ(VC)发测试后形成视。2.整个开发过程中的可跟踪性和透明性的需求3展制开发的需求（成本、范围和时间表）可靠的系统2.在测试计划评审中包括顾客。阶段V-瀑布L项目的工作L对时间表L在开发过程中，生命周期量，周转时间有中等的控最终用户不可(V4)中等制视。2.产品复杂度2.中等的开2.对很复杂的项和团队规模销目不建议使用，中等3.对交付的因为它只提供了3.需求和技术解决方案有一层设计.比较好地被合理控制理解4.比V瀑布在周转时间的性能上要更好。演75生命周L很小范围和L很低（可L不可靠的时间
17、期(D)团队规模-能最低）成表。可能1或2人本。2.产品不口靠或的团队。2.中途修正没有扩展项。2,低开发成是容易和便3.对管理层和顾本，高周转时宜的。客儿乎都是不可间。见的。3.不能提供训练有素的经历和开发者。4.项目失败影响低。进化开发模L中到大项L对管理层L需要有很有经型(EVO)目，可靠性和和顾客有很验的和成熟的管最终用户的高的可视理。可视性很重性。2.对每个周期的耍。2.风险管理管理和文档都有2.需求、架构容易。成本。和技术都没3.中等的成3.中途修改要明有很好地理本，至少提确定义，包括对解。供了相对稳原型周期。3.最终产品要定的时间4.在迭代过程中有好的扩展性。表。发生巨大的变化会
18、导致成本花费和缺乏可靠性及扩展性。3.2升级维护型项目生命周期模型本模型描述了修补一个缺陷开展的活动。当缺陷修补活动需要作为一个独立的项目时，建议采用本项目生命周期模型。缺陷分类分析修补测试补丁/修补版本单个缺陷的活动遵循缺陷管理的过程，该过程根据缺陷跟踪机制/工具的不同而改变。本活动的指南和在本生命周期可能的裁剪在脚注中提供。表1缺陷修补项目生命周期模型注：表格中对应的数字标号，请参考表格后的裁减指南；阶段分类分析修补测试补丁/修补版本输入服务要求/变更要求市场评审区分优先次序的CR充足的信息展开分析调试工具源代码数据库分析阶段输出依赖信息修补阶段输出测试用例组分支代码的顶部构造环境测试用例
19、组补J，具任初步调查并模编制回归测构造项目务分析拟缺陷修补试回归/整初步调试代码代码由提交合/系统测估计设计测试单元者验证试区分用例测试（如果可准备补丁优先次更新CR修补行）评审补丁序的CR(三)代码登记已文档更新修改的补丁/修补更新回归代码版本CR测试更新CR更新用例CR(三)同行评审更新CR输分类缺陷隔离包含测试结测试结果出并更新和用户推荐修补果补丁评审的CR的分析完成的代测试后日志（如果更新CR码的代码可行）单元基线补丁测试补丁样板/后的检查列表代码（如果可行）.测试更新CR用例组同行评审日志更新的CR注：任务/活动指南和裁剪指南：1.该模型也可以用于小的功能增强型项目（小于1个月的工作
20、量）。2.初步分析用于判断缺陷的相关信息。比如，缺陷是否属于另-个项目/部件，是否和已经存在的缺陷重复，是否由一个操作者的失误引起或是一个增加要求，或者需要被作为技术攻关项目来处理。3.初步估计用于初步评估修复缺陷需修改规模、工作量、成本等。4.为缺陷指定修复的优先级。5.缺陷修补过程中需要适当地更新CR状态。同样，在生命周期的每个阶段需要更新相关CR信息。6.根据CR优先级进行缺陷修补问题的分析。7作为分析阶段的第一步，缺陷需要在开发环境或客户的测试环境里再次形成。这可能需要提交缺陷者提供更多的信息。在这个阶段，如果缺陷被确认为不可重新形成的，同样的缺陷可能被关闭或者分析可能使用跟踪和核心等,他们可能被用来引起一个缺陷。依赖于业务影响，有些缺陷可以在不能被重新构造的情况下修补。8.如果缺陷被成功地复制，那么单元测试也相应地将被增进。然后测试缺陷的用例将组合到回归测试中，如果存在，和测试计划一致。9.每一个缺陷修补可能不会导致一个补丁。通常一个补丁用来修补一段时间内积累的多个缺陷。但是有时（一个热点修补）一个补丁可能只修补一个缺陷。当一个修补被捆绑到一个完成的产品版本后，项目管理生命周期的版本发布阶段应随之开始。
