原创

形形色色的软件生命周期模型(4)——MSF、实用型

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://fireball.blog.csdn.net/article/details/12191047

摘要:
读大学时,我们曾经学习过不少软件生命周期模型,当时还不是很懂软件开发,你可能会觉得这些东西很新奇。在实际工作中,你会发现这些模型其实很难应用,与此同时你会接触到RUP、MSF等权威软件公司的生命周期模型。本文将向你介绍各种常见的软件生命周期模型及它们的优缺点,文章最后还会介绍吸取了各种模型优点的实用生命周期模型。


大纲:
1.瀑布型
2.增量型
3.进化型
4.原型
5.螺旋型
6.RUP的软件生命周期模型
7.MSF的软件生命周期模型
8.实用软件生命周期模型

本系列文章将为分四次为你分享,每次分享两种模型。


MSF的软件生命周期模型

MSF,全称是Microsoft Solution Framework,微软解决方案框架,是微软进行研发活动的方法论。
关于MSF,大家可以参考此文《解开MSF团队管理的秘密》

《项目团队模型》一文中,我们介绍了MSF的团队模型,这里介绍MSF的软件生命周期模型。

MSF的软件生命周期模型与螺旋型很相似,同样也是多版本螺旋前进,只是每次螺旋(每个版本)阶段划分不太一样,而且每次螺旋都会有至少5个大里程碑,如下图:

MSF1.png

本图来自互联网



MSF2.png

本图来由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.需求、设计、编码、测试、实施等工作应一步一脚印做好,文档应及时评审并要及时更新。

我定义了一种软件生命周期模型:多线程多版本式软件生命周期模型,如下图:

多线程多版本软件生命周期模型.png


此图与RUP的图很类似,主要区别有:
1.横向以多版本来划分。实际项目中每个版本的周期一般也只有1-2个月,而我们公司往往少于1个月,故每个版本我就不再划分阶段。
2.工作分类不太一样,我以中国人更容易理解的角度来划分,并且补充了RUP没有的活动。
商务:指跟客户商定合同、谈判、验收、收款等与钱直接相关的工作。
工作环境:为保障项目组顺利运作而准备的软硬件环境,保障项目组的工作、沟通能顺利进行。
技能管理:完成项目需要满足一定的技能要求,在整个项目过程中要针对性地安排培训、自学、研究等工作,保证项目组整体具备完成工作所需的技能。
3.计划、需求、设计、编码、测试、实施这些红色字的活动,尽管在整个项目周期中是持续进行的,但需要及时安排工作产品评审,并要及时更新文档。
以计划为例,往往我们在项目初期只能定出近期的详细计划以及远期的大致计划,随着项目开展应随时更新近期计划和明确远期计划,计划应不断细化。同样道理。需求、设计、测试、实施等文档也是需要不断细化的。

其实软件开发情况千变万化,没有一种模型能应对全部情况。下面我列举几种典型的项目情况,每种情况的软件生命周期模型都不尽相同。
1.从新开始做一个项目。
2.在一期的基础上开发二期项目。
3.在产品的基础上做项目。
4.公司独立自主研发产品。
5.互联网开发。
6.维护型项目。
以上每种情况都不尽相同,每种情况都可以有自己独特的软件生命周期。

实用软件生命周期模型并不存在固定的模式,我们需要理解上述各种模型的特点,在实际工作中不断体会项目管理的奥妙,灵活应用上述模型。


有人常常问我:你们公司的项目是怎样的生命周期模型?
我往往不知道怎样回答,招无定式,我们的模型往往是“混合型”的!


全文完,谢谢!




作者:张传波

创新工场创业课堂讲师

软件研发管理资深顾问

《火球——UML大战需求分析》作者

www.umlonline.org 创办人


文章最后发布于: 2013-09-30 12:10:53
展开阅读全文
0 个人打赏

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览