「干货」软件生命周期详解

「干货」软件生命周期详解

　　美发会员管理软件,刷优酷会员软件,指纹会员软件制定软件生命周期（Software Lift Cycle, SLC）的目的是确定项目应该采用的软件生命周期模型，统筹规划项目的整体开发流程。

　　软件生命周期是组织软件标准过程模型的重要组成部分。本文档阐述了周期模型选择的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“结束准则”和“度量”在CMMI相关文档中均已定义。

　　软件生命周期是指从设想软件产品开始到软件不再供使用为止的时间间隔。对生命周期细分阶段进行管理称为周期模型，典型的几种生命周期模型包括瀑布模型、瀑布迭代模型、原型迭代模型、XP模型等。项目组应在软件项目启动阶段认真考虑项目的特征和目标的基础上参考原有模型和组织软件标准过程，运用《过程裁减指南》为项目开发裁减出一个软件生命周期模型。

　　本规程的制定是为了在项目实施过程中能够有一个统一的方法来分析项目需求预先识别项目特征并提供可供项目选择的软件生命周期模型，使其可以和OSSP结合在一起使用。

　　软件生命周期模型一般都是在原有的软件生命周期模型基础上根据客户的需求范围和目标实现来判断项目的特征，进而进行模型裁剪后产生。一般包括四个步骤：需求识别分析、原型参考、裁剪定义和模型实施。

　　从需求被识别，并且明确了需求目标开始，就进入项目启动阶段，这个时候项目组开始组建，同时开始收集需求，项目经理应积极配合业务代表或者商务经理一起参与需求研讨和项目的策划，安排有经验的人员进入项目组，迅速对需求进行初步分析，概括项目的特征。

　　此部分的需求分析还应该包括对历史项目的回顾，总结成功实施经验和吸取失败教训，并归档备案作为组织的知识库。

　　当项目需求目标确定，同时识别出项目特征，从常用软件生命周期模型中挑选出一个模型以供参考，该周期原型必须在很大程度上适合项目的具体特征以及能够结合组织标准软件过程一起使用。

　　项目一开始，挑选后的软件生命周期模型仅作参考，下一步还必须结合实际的越来越丰富的需求进行裁剪以形成最终的项目指导模型。最终的项目指导模型可以归档成为下一个类似项目的原始参考模型。

　　项目特征是裁剪工作的出发点，包括项目规模（如大、中、小等）、项目类型（如新开发、外包、升级等），以及技术难易度、产品类型、项目的时间和质量要求等要素。

　　可裁剪对象确定了裁剪的内容范围，可裁剪对象不仅仅限于过程元素和活动，还包括参照标准、方法和工具、输出成果物及模板等。

　　裁剪要素界定了裁剪的方向和尺度。例如，对于某个裁剪对象，其范围、频度等都是裁剪要素。对于有开发经验的小项目，可以适当减少对于技术方面的评审的频度。

　　基于风险可检验裁剪的适当性。对过程或活动的调整或放弃需要通过分析其所带来的风险和影响再做决定。

　　裁剪后的新周期模型，是个适应项目特征的项目标准软件过程，该过程包含软件生命周期模型的原理、优缺点等描述，能够帮助软件开发人员更好地理解和运用此生命周期进行项目开发。

　　新周期模型对于项目开发具有指导意义，必须将该模型下达通知到项目组所有成员，项目经理必须监督保证此模型的实施与推广，实现“项目可控，质量可靠”的最终目标。

　　度量的目的是统计用裁减后的软件生命周期模型指导项目过程进展后，此项目产生的所有工作量。

　　同样的软件项目，实施不同的周期模型，项目的总的工作量也是不同的，好的周期模型不仅能够大大缩减工作量，同时也保证代码的质量。不合理的周期模型则会因为保证质量的需要引入重复的各类阶段审查，进而产生更多、更冗长的无法跟踪维护的文档导致项目失败，或者忽略关键性的阶段审查而带来需求的不明确及代码的重复返工，同样也导致了项目失败。

　　软件生命周期模型的引入，将对项目过程划分成几个不同的阶段，规模较大的项目则阶段内还分更多小的阶段，每个阶段都将对本阶段内产生的成果物进行审查。因此，如何估算审查的工作量也必须包含在此度量活动中。

　　软件项目生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。软件项目生命周期一般包括售前阶段、需求阶段、设计阶段、实现阶段、测试阶段、部署上线阶段、运行和维护阶段等。由于软件实施组织是为不同的商业客户生产软件，所以传统的软件项目生命周期不可能适用于公司所有软件项目的实施情况，为此EPG在软件工程学科的传统生命周期的基础上，综合了组织所有项目的特征，定义出了一个大而全的生命周期模型。每个软件项目可以在可选择软件周期参考模型的过程中，结合组织标准软件过程，运用过程裁减标准进行裁减，从而成为项目的实施标准过程。

　　标准瀑布生命周期模型适用于公司内部研发项目、为客户开发系统的项目、二次开发和推广移植的项目。模型用图形的方式来描述，显示了它们应用的阶段及其输入/输出。描述了在何种条件下使用该模型，需要注意风险和应用裁剪的指导。

　　当开发的系统规模和复杂度较高，达到需要采用多层设计时，推荐使用标准的生命周期。最终的系统被分解为多于一个的子系统。每个子系统由一个或多个模块组成。每个模块由一个或多个单元。一个单元是最小的可独立测试的单位。用于集成测试的模块测试计划和集成测试计划中的模块就是从单元而来，子系统从模块而来。

　　? 由于在一个阶段结束时要做很多文档并要所有的干系人签字，有很大的开销。

　　? 根据工作量和时间分析，由于项目范围的改变而导致的中途更正是花很大代价的。

　　该模型是经过裁剪的模型。推荐在中等复杂度和规模的项目中使用，在这些项目中解决方案可以用两层来表示。系统由多于一个模块组成，同时每个模块又是由一个或多个单元组成。这种模型在软件可靠性要求很高是被选择，要求除开发者以外的人来进行测试。对这个生命周期来说，单元测试是必要的 。

　　该模型适合于对正规化程度低的小到中型项目。系统的规模和复杂度低，可以用一层设计来表示。最终的系统可以用一个或多个单元来构成。在这个生命周期中单元测试是必要的。

　　? 这个模型中的设计阶段是由VC模型中的概要设计和详细设计组合而成的。只有一层设计和测试的文档是必需的。

　　? 在V模型需要测试计划同所测试的开发一同被评审和基线化时，一个项目可以在每个测试计划被评审和基线化时裁剪和设置检查点。然而测试计划活动一定要在阶段指示的地方启动，如ST计划一定要在RA&P阶段启动。

　　这个模型仅适合用于一个演示的系统开发，最终其将会被丢弃，它形成的成果将是对开发概念的证明。如果在其原型出来之后需要对此项目进行产品化，需要对这个开发的软件进行详细评估。

　　调查阶段是在SC检查点之前的所有阶段的合并。调查、分析、计划和设计活动都在这个阶段进行。

　　? 根据产品的需要在发布阶段的交付物要在整个SVW交付集中选择。要建立这些交付物一致的基线 进化开发模型（EVO）:

　　进化开发模型 (EVO)是一种迭代的模型，可用来降低大项目的风险。 风险可以有很多种类，这个模型的每一个迭代或发布都针对了特定的风险集合。风险可以是对需求理解不清楚、新技术的使用、架构的可行性、潜在的性能问题等。每一个迭代都有不同的模型作为基础。

　　? 每一个迭代都有不同的模型作为基础，这些模型是从前面几种基本瀑布模型选出的，遵循它们的裁剪指导。在每个迭代中可以使用不同的模型。

　　本模型描述了修补一个缺陷开展的活动。当缺陷修补活动需要作为一个独立的项目时，建议采用本项目生命周期模型。

　　单个缺陷的活动遵循缺陷管理的过程，该过程根据缺陷跟踪机制/工具的不同而改变。

　　2. 初步分析用于判断缺陷的相关信息。比如，缺陷是否属于另一个项目/部件，是否和已经存在的缺陷重复，是否由一个操作者的失误引起或是一个增加要求，或者需要被作为技术攻关项目来处理。

　　5. 缺陷修补过程中需要适当地更新CR状态。同样，在生命周期的每个阶段需要更新相关CR信息。

　　7. 作为分析阶段的第一步，缺陷需要在开发环境或客户的测试环境里再次形成。这可能需要提交缺陷者提供更多的信息。在这个阶段，如果缺陷被确认为不可重新形成的，同样的缺陷可能被关闭或者分析可能使用跟踪和核心等，他们可能被用来引起一个缺陷。依赖于业务影响，有些缺陷可以在不能被重新构造的情况下修补。

　　8. 如果缺陷被成功地复制，那么单元测试也相应地将被增进。然后测试缺陷的用例将组合到回归测试中，如果存在，和测试计划一致。

　　9. 每一个缺陷修补可能不会导致一个补丁。通常一个补丁用来修补一段时间内积累的多个缺陷。但是有时 (一个热点修补)一个补丁可能只修补一个缺陷。当一个修补被捆绑到一个完成的产品版本后，项目管理生命周期的版本发布阶段应随之开始。