形形色色的软件生命周期模型(4)——MSF、实用型
摘要:
读大学时,我们曾经学习过不少
本图来由MSF官方资料整理出来
第一个图反应了MSF生命周期模型的概貌,多版本的连续开发,每个版本实现部分功能,最后实现全部的功能。
第二个图详细说明了每一个版本(即每一次螺旋)的阶段划分及里程碑:
阶段:远景(Envisioning)
里程碑:远景/范围被批准(Vision/Scope Approved)
阶段:计划(Planning)
里程碑:计划被批准(Project Plans Approved)
阶段:开发(Developiing)
里程碑:范围完成(Scope Complete)
阶段:稳定(Stabilizing)
里程碑:发布被批准(Release Readiness Approved)
阶段:部署(Deploying)
里程碑:部署完成(Deployment Complete)
如果某软件开发时间的工作比较类似,我们往往可以将该时期定为某某阶段,阶段是某个时间段上的概念。而里程碑不是时间段上的概念,而是指某个时间点上发生的标志性事件。MSF的每个阶段都以相应的里程碑标记,阶段必须达致里程碑才算结束。如第一个阶段远景,必须有书面的经过审批的远景相关文档才算结束。
MSF的生命周期模型是螺旋型模型的进一步优化,既保持了软件开发的灵活性,同时在每一次螺旋中均有里程碑的要求,增强了软件开发的严谨性。
实用软件生命周期模型
我个人觉得MSF和RUP的软件生命周期模型和我们实际工作比较贴切,不过当然不是100%都可以执行了,但以下几个重要思想是可以贯彻的:
1.整个项目应该通过多版本推进。我们公司项目不算很大,每个版本周期在一个月内,甚至只有两到三周。
2.各类文档和代码应该持续更新。这些文档包括:需求、设计、测试、实施方面的文档,也包括计划方面的文档。
3.需求、计划、设计、测试等重要文档均需通过评审,并用通过评审的文档来指导工作。
4.通过评审后的文档应该因应变化而及时调整,不要走两个极端:任何修改都需要重型的变更审查;文档写了就算不根据实际情况作任何调整。
但MSF、RUP等软件生命周期模型,都没有考虑到中国项目的一些重要的特点:
1.签订了需求不明确的合同。
2.合同的价钱是死的。
3.合同要求的项目完成时间是死的。
这些特点决定了我们无法完全采用以上任何软件生命周期模型,我们的软件开发难以“敏捷”,我们很多IT从业员天天在为项目而“煎熬”。我们需要提出一种能适应中国特色的、能针对性解决实际问题的实用软件生命周期模型。
我觉得这种实用软件生命周期模型应该有这样的特点:
1.需求应当在项目初期至少明确80%以上。
2.采用多版本方式逐步满足需求,让已确定需求尽快稳定,并尽快搞清楚未确定的需求。
3.需求、设计、编码、测试、实施等工作应一步一脚印做好,文档应及时评审并要及时更新。
我定义了一种软件生命周期模型:多线程多版本式软件生命周期模型,如下图:
有人常常问我:你们公司的项目是怎样的生命周期模型?
我往往不知道怎样回答,招无定式,我们的模型往往是“混合型”的!
全文完,谢谢!
作者:张传波
创新工场创业课堂讲师
软件研发管理资深顾问
《火球——UML大战需求分析》作者
www.umlonline.org 创办人