软件开发生命周期选择指南.docx
《软件开发生命周期选择指南.docx》由会员分享，可在线阅读，更多相关《软件开发生命周期选择指南.docx（11页珍藏版）》请在冰点文库上搜索。
软件开发生命周期选择指南
本资料仅供内部使用!
软件开发生命周期选择指南
XXXXXXXX滋司
20XX年XX月XX日
修改记录
制定日期
生效日期
制定/修订内容摘要
页数
版本
拟稿
审查
批准
1目的1
2软件开发生命周期选择指南1
2.1项目特征：
1
1目的
软件开发生命周期选择指南的目的：
就是指导项目组初步选择适用本项目的软件开发生命周期模型，以便根据软件项目自身特点裁剪公司标准软件开发生命周期过程，用于定义软件项目过程PDSP。
2软件开发生命周期选择指南
这一节描述了项目的特性，这些特性被用来作为选择合适的LC模型的标准。
共有11种特性。
每一种规则都有一个对它是如何影响对模型的选择和它使用指导的描述。
在XXXX-TOSSP的项目中，总共有7种推荐的模型。
两张表格详细描述了7种模型以及规则
的合适值。
表格1按照正规性递减的顺序提供了基本的瀑布模型-标准V瀑布，4阶段V瀑布和3
阶段V瀑布。
表格2包括了大部。
表格3提供了标准软件开发生命周期模型的项目特性的总结。
在表格4中列出了一个真实项目对生命周期选择的例子来说明对表格3的使用。
使用这节为你的项目选择和简短列出合适的生命周期模型。
使用项目的特征和给出的值来
作为指导。
项目的适应性矩阵或记录计划（POR）可以影响对合适LC的最终选择。
同其
他在PDSP中规定的选择模型的规则一起，捕获你的项目的特征以及生命周期的选择。
在XXXX-TOSSP中，这个数据被周期性地用来对特征作重新校准。
利用下一节所详细描述的模型，有适应或裁剪地最终选出最合适的模型。
2.1项目特征
工作量：
这指示了完成项目所估计的规模/单位工作量。
一般来说，高工作量需要更严格和正规的LC模
型。
大：
工作量
>30工程月（EM）
中：
工作量
在15-30EM之间
小：
工作量
在6-15EM之间
非常小：
工作量
<6EM
代码规模/交付的源文件说明：
这指示了开发的软件的规模。
对此的实际指导是从对不同类型的项目使用的正式的规模估计技术发展而来。
利用了复杂度和工作量来替换。
团队规模:
这指示了依据人员数量的团队规模。
一般来说，越是大的团队要使用越是严格和正规的LC模
型，以便通过增加互相依赖和沟通来应付风险。
>30
中：
10到30
小：
3至U10
非常小：
<3
周转时间：
这指示了项目从开始到结束的时间。
应用更正规的模型在相对少的周转时间上是不可行的。
多：
>12月
中：
6-12月
少：
3-6月
非常少：
<3月
以下对项目特征的分类为高、中和低。
对这些特征的定量测量应该随时间而变化。
复杂度：
指示了开发项目的复杂程度。
复杂度同规模、功能和接口数有关。
对高复杂度的项目推荐使用更正规的模型，因为他们提供了更好的控制机制。
危险程度（关键度）：
指示了开发项目的危险程度，例，如金融交易系统软件是否是一个非常安全的系统等。
对于安全/任务关键软件，推荐采用经过裁剪的瀑布模型。
不建议采用低正规化的3阶段或4阶段的V模型。
需求清晰度：
指示了项目组和顾客对需求理解的程度。
越高的清晰度意味着越少的中间改动，这样
就降低了中间修改的风险。
如果需求不好理解，选择一个进化或迭代的模型来帮助在不断的迭代中理解需求。
需求稳定性：
指示了期待需求的稳定程度。
对于低稳定的需求使用组合模型，如交叠的瀑布或迭代
模型，这样在每个周期中都可以有稳定的范围。
技术/架构获得度：
指示了在技术使用上团队的专业程度。
当加强一个存在的软件时，由存在软件的
可用专业程度来衡量。
生成可重用软件：
指示了团队是否可以生成高度可重用的软件。
如果这对项目是一个需求，应用更正规的模型。
重用已有软件：
只是软件是否从已有的软件中构建，这些软件可以是商业软件（COTS）或其它软件。
2.2表格1：
基本瀑布模型
LC二
生命周期能力
特征n
标准V瀑布（SVW）,V关键（VC）
4-阶段瀑布（V4）
3-阶段瀑布（V3）
项目特征
工作量
中到高
小到中
小到中
代码规模
中到高
小到中
小到中
团队规模
中到高
中
小
周转时间
中到高
中
小到中
复杂度
高
中
小
危险程度
中，高
低到中
低
需求清晰度
高
中
高
需求稳定度
高
中
中
技术/架构获得度
高
中
高
生成可重用软件
高
中
低
重用已有软件
高
中
高
优势
管理层普通可视
相对稳定时间表
低周转时间
管理层普通可视
更好的时间表稳定度，中等开
销
风险管理更容易
中间修改相对简单
低周转时间
低开销
相对稳定时间表风险管理更容易中间修改更简单
注意
对顾客可视度差高周转时间咼开销
中间修改难风险控制不易
对顾客可视度差
对管理层和顾客可视度差
缺乏分析和设计的风险
2.3表格2:
组合或推论模型
LC二
生命周期能力
特征u
编码和修正
（c&F）
阶段发布（SD）
进化开发（EVO）
交叠瀑布
（OVW）
项目特征
工作量
小
中到高
中到高
小到中
代码规模
小
中到高
中到高
小到中
团队规模
小
中到高
中到高
小
周转时间
小
中到高
中到高
低到中
复杂度
低
中到高
中到高
低到中
危险程度
低
中到高
低
低
需求清晰度
低
高
低
低
需求稳定度
低
低到中
低
低到中
技术/架构获得度
高
高
低到中
低
生成可重用软件
低
高
中
低
重用已有软件
低
高
高
低
优势
最低周转时
间
低开销
中间修改相
对简单
中周转时间
对顾客和管理层咼可见性
容易的风险管理中间修改相对简单
时间表稳定性中等
可由于扩展的和可靠的系统
中周转时间
高到中对顾客和管理层可见性中间修改简单风险管理容易
中等开销
中等时间表稳定性
可在工作中培训中周转时间中间修改相对简单低开销
风险管理相对简单
汪意
管理层低可
见性
实践稳定性
不可预测
没有风险管
理
完成前对顾客不可见
需要有经验的和成熟的管理
需要有经验的管
理
可能不能用于扩展的和可靠的系统
对顾客和管理层低可见度
时间表稳定度-
低到中
强烈依赖于团队和管理层之间的非正规沟通
2.4表格3:
生命周期模型的项目特征
项目
特征
关键性，如果
SVW
VC
V4
V3
C&F
STG
EVO
OVW
工作量
高
E
E
F
P
P
E
E
F
复杂度
高
E
E
E
F
P
E
E
F
团队规模
高
E
E
F
F
P
E
E
F
周转时间
低
P
P
F
E
E
P
P
F
危险程度
高
F
E
P
P
P
☆
☆
P
需求清晰度
低
P
P
F
F
P
F
E
E
需求稳定度
低
P
P
F
F
E
F
E
E
技术/架构获得度
低
P
P
P
P
P
F
E
E
必须生成可重用软件
高
E
E
F
P
P
E
☆
P
必须使用已有软件
高
E
E
F
F
P
E
☆
F
时间表可靠性需求
高
E
E
F
F
P
E
☆
P
最小化开销需求
高
P
P
F
F
E
P
P
F
顾客可见性需求
高
P
P
P
P
P
F
E
P
管理层可见性需求
高
E
E
F
F
P
E
E
P
☆值依赖于每个迭代所使用的生命周期
在表格3的第一列列出的一个或多个特征对项目而言可能是关键的。
第二列指示项目特征是否
是关键的，是否是高或低。
每个生命模型处理关键特征地能力用E来表示极好，F表示一般，P
表示差。
2.5表格4:
利用项目特征来选择生命周期的例子
项目特征
实际值
SVW
VC
V4
V3
C&F
STG
EVO
OVW
工作量
NA
0
0
0
0
0
0
0
0
复杂度
NA
0
0
0
0
0
0
0
0
团队规模
NA
0
0
0
0
0
0
0
0
周转时间
NA
0
0
0
0
0
0
0
0
危险程度
NA
0
0
0
0
0
0
0
0
需求清晰度
低
1
1
2
2
1
2
3
3
需求稳定度
NA
0
0
0
0
0
0
0
0
技术/架构获得度
低
1
1
1
1
1
2
3
3
必须生成可重用软件
高
3
3
2
1
1
3
2
1
必须使用已有软件
NA
0
0
0
0
0
0
0
0
时间表可靠性需求
高
3
3
2
2
1
3
3
1
最小化开销需求
NA
0
0
0
0
0
0
0
0
顾客可见性需求
高
1
1
1
1
1
2
3
1
管理层可见性需求
高
3
3
2
2
1
3
3
1
模型得分
12
12
10
9
6
15
17
10
表格3被使用来对示例项目决定生命周期。
对这个真实的项目，根据相应的特征填入值高和低，
同时NA表示保留特征。
每一个生命周期的能力都被定量的表示，对每一个特征通过用3代表极好,
用2代表一般，用1代表差，0代表NA。
最高的得分代表了最适合项目所展现的选择的特征。
最高得分的生命周期不一定是为项目选择的实际生命周期。
然而，最终选择的规则必须归档。
示例项目实施上用了两阶段的进化开发模型。
升级会员 