软件开发生命周期模型(阶段模型检查点评审生命周期)

文章目录 [+]

每一幅图都指出了运用于该模型的阶段和阶段评审检查点。
用粗体和斜体表示的阶段评审检查点推荐要有高层经理参加。
所有的阶段评审检查点都要由项目经理签字。

主要阶段:

项目售前/定义(PD)

（图片来自网络侵删）

项目立项/启动 (PI)

需求分析和计划 (RA&P)

概要设计 (HLD)

详细设计 (DD)

编码和单元测试 (CUT)

集成测试 (IT)

系统测试 (ST)

发布/上线 (REL)

关闭 (CLS)

阶段评审检查点

顾客签字 (CUSTSO)

开始(KO)

需求签字 (RSO)

架构签字 (ASO)

设计签字 (DSO)

编码签字 (CSO)

功能完成 (FC)

系统完成 (SC)

发布完成 (RC)

利用这节提供的细节来最终选择软件开发生命周期的模型。
对大多数的项目，从前面的部分表格来看可能有不止一种适合的模型。
利用本节所详细描述的模型，有适应或裁剪地最终选出最合适的模型。

标准V-瀑布生命周期(SVW)

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

何时使用:

需求很好地被理解了并且期望是相对稳定的。
解决方案的技术和架构被很好地理解。
高可维护的和可支持的解决方案的需要。
可视性和可靠性，根据对所有中间交付物受控的基线。

优势:

对管理层提供实施可视性。
时间表稳定度很高, 由于需求稳定度

注意:

在不清晰的不稳定的需求和技术条件下不能很好工作由于在一个阶段结束时要做很多文档并要所有的利益相关人签字，有很大的开销。
所有的利益相关人都要在每一个阶段结束时进行说明或签字根据工作量和时间分析，由于项目范围的改变而导致的中途更正是花很大代价的。

裁剪指导:

根据活动的范围，项目可以选择在进入或离开任何一个阶段。
这在必要的RA&P 阶段决定，例如项目组可以在DD开始活动在IT后结束。
在那种情况下，前面阶段的必需的交付物– SRS 和HLD – 必须可用。
计划文档，即 PP, PDSP, QP 和SCMP必须在相应的阶段完成。
模块测试计划和集成测试计划可以组合在一个文档中。
这个模型中的阶段和阶段评审检查点都不能做变更。
在V模型需要测试计划同他所测试的开发一同被评审和基线化时，一个项目可以在每个测试计划被评审和基线化时裁剪和阶段评审检查点。
然而测试计划活动一定要在阶段所指示的地方启动，如ST计划一定要在RA&P阶段启动。
V-瀑布生命周期为关键产品(VC)

从图中可以看出，这是一个SVW经裁剪的模型。
推荐在中等复杂度和规模的项目中使用，在这些项目中解决方案可以用两层来表示。
系统由多于一个模块组成，同时每个模块又是由一个或多个单元组成。
这种模块在软件危险程度要求很可靠测试时被选择，所以需要除开发者以外的人来做测试（如，医疗系统或汽车控制软件、金融交易软件系统或关键任务系统）。
对这个生命周期单元测试是必要的。

何时使用:

安全/任务关键软件开发整个开发过程中的可跟踪性和透明性的需求控制开发的需求（成本、范围和时间表）

优势:

正规化保证了高度测试的和可靠的系统

注意:

不成熟的离开一个阶段会导致文档的延迟和成本增加。
在开发过程中，最终用户不可视。
在测试计划评审中包括顾客。

裁剪指导:

这个模型中的阶段和阶段评审检查点都不能做变更。
根据活动的范围，项目可以选择在进入或离开任何一个阶段。
这在必要的RA&P 阶段决定，例如项目组可以在DD开始活动在IT后结束。
在那种情况下，前面阶段的必需的交付物– SRS 和HLD – 必须可用。
计划文档，即 PP, PDSP, QP 和SCMP必须在相应的阶段完成。
阶段V-瀑布生命周期 (V4)

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

何时使用:

项目的工作量, 周转时间中等产品复杂度和团队规模中等需求和技术比较好地被理解比V瀑布在周转时间的性能上要更好。

优势:

对时间表有中等的控制中等的开销对交付的解决方案有合理控制

注意:

在开发过程中，最终用户不可视。
对很复杂的项目不建议使用，因为它只提供了一层设计。

裁剪指导:

所有的图中的阶段和阶段评审检查点在选择了进入点后都是必需的。
这个模型中的DD阶段是由SVW中的HLD和DD阶段组合而成的。
只有一层设计和测试的文档是必需的。

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

阶段 V-瀑布生命周期 (V3)

这个模型推荐给小到中规模的项目。
系统的复杂度和软件的规模一定要小，因为这个模型不提供单独的需求分析和设计阶段。
这也可以被用来对已有软件的增强性升级。

调查阶段是在DSO阶段评审检查点之前的所有阶段的合并。
调查、分析、计划和设计活动都在这个阶段进行。
在调查阶段结束时，调查报告中包含了需求和设计的合适细节。
在这个生命周期中单元测试是必要的。

何时使用:

规模和工作量要求低团队规模小系统复杂度低, 排除了单独的设计阶段。
需求和技术被很好地理解产品的结构是稳定的

优势:

提供了对时间表的中等控制减少了开销

注意:

在开发过程中，最终用户不可视。
由于因为没有单独的分析和设计阶段而产生的风险。

裁剪指导:

所有的图中的阶段和阶段评审检查点在选择了进入点后都是必需的。
可以建立单独的SRS和设计文档可以引入附加的测试计划和测试层在V模型需要测试计划同他所测试IR一同被评审和基线化时，一个项目可以选择在ST阶段之前来进行基线化。
然而测试计划活动一定要在INV阶段所指示的地方启动，如ST计划一定要在RA&P阶段启动。

编码和修正生命周期 (C&F)

这个模型仅适用于丢弃的原型、短期的演示、很小的工具、BUG的修正或对开发概念的证明。
如果在原型之后要产品化，就要对这个开发的软件进行仔细评估。

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

何时使用:

很小范围和团队规模 – 可能1或2人的团队低开发开销，高周转时间不能提供训练有素的经历和开发者项目失败影响低

优势:

很低 (可能最低) 开销中途修正是容易和便宜的

注意

不可靠的时间表产品不可靠或没有扩展项对管理层和顾客几乎都是不可见的

裁剪指导:

根据产品的需要在发布阶段的交付物要在整个SVW交付集中选择。
要建立这些交付物一致的基线。

阶段交付模型

阶段发布模型被推荐使用在规模大、特征有优先级、在一段时间内超过一个阶段发布的情况中。
这个模型用标准的V瀑布模型来表示。

有一种变化就是在多个子项目模型中，阶段是同步发生的。
如果子项目没有重叠

技术的要求就可以被使用；测试和发布同步在这个模型里很关键。

何时使用:

中到大项目，可靠性要求很高最终用户可视性重要同顾客团队合作开发对需求、技术和架构有很好的理解最终产品要有很好的扩展性

优势:

对管理层和顾客有很高的可视性风险管理和中途更正较简单可以导出一个高可靠、可重用和可扩展的系统，因为HLD在早期就被固定

注意:

需要复杂的和有经验的管理由于在HLD阶段不完整的概念化设计，增加新的需求

裁剪指导:

这种模式可以基于VC生命周期模式所有的阶段都不需要特别的阶段。
然而，阶段需要从基本的生命模型中导出

交叠瀑布模型

交叠瀑布模型(OVW)使项目可以在未对早期阶段的产品基线化时就开始新的阶段活动。
这个模型适用于领域或技术训练或蔓延机制，在这些情况下项目的总体危险程度是低. 可基于SVW, VC, V4 或V3.

当一个阶段评审检查点最终被签订后（由团队决定时间），所有先前的交付物一定要准备好并同当前的状态同步。
如，如果DSO在ST阶段被实施，RSO和DSO所有的交付物就一定要准备好，文档和代码（在实时CUT中产生）必须要同测试计划同步。
另外，正在进行的工作一定要进行评估并且下一个阶段评审检查点的时间安排一定要计划好。

何时使用:

小到中型产品开发组小，周转时间不能很长需求清晰度低，需要进一步的调查技术和架构知识低不指望产生高扩展性和可重用软件

优势:

由于团队不需要每个步骤都等待利益相关人，所以开销很低通过非正式的沟通，风险管理简单同没有交叠得同样的生命周期来说，在周转时间上有更好的表现如果同团队或利益相关人沟通良好，中途修改就简单了

注意:

对顾客和管理层的可视程度低返工风险时间表稳定性不好

裁剪指导:

每个阶段评审检查点的位置可以由项目组决定可以在未对早期阶段的产品基线化时就开始新的阶段活动在任何阶段在计划中都要指明下一个阶段评审检查点