软件开发过程模型比较

来自微软高级开发管理峰会2003
 

讲师：黄晓凌

时间：12月5日15:45-16:45
地点：教室一

我讲最后一个课题，软件开发过程模型比较。这个题目是仁者见仁、智者见智的的题目，我会讲一些我的认识和看法，希望对大家有一些帮助。

软件工程大学里都要学的，今天我也要讲讲软件工程。我们来看图：该图分为4个层次：1）质量层：做软件质量焦点是我们关注的，我们花少的钱把事情做好，提高软件的质量，不仅是微软，哪家公司都是关注质量的。质量焦点是问题，为什么要工程化，质量问题是关键问题。2）过程。在这个质量基础之上，我们为了保证质量，就会有过程。很多在关注质量和保证质量上提高过程，搞CMM的要知道CMM在整个软件工程中处于一个什么样的地位。CMM是属于过程类的，CMM是18个KPA，都是过程，这个过程是为了保证我们的质量的。3）过程之上还有方法。方法相当于我们各种模型，还有一些建模活动。一类是把我的过程组织起来，一个阶段一个阶段的，这是方法。还有一些建模的活动，建模也有一些模型的方法。4）方法上面是工具。软件工程其实是一个层次化的技术。但是落脚点在质量上，象修路一样建软件，象建房子一样建软件，关注质量。有很多过程，这个过程用很多方法组织起来，CMM告诉你很多要做什么，怎么做。有一些方法，比如需求阶段做哪些，设计阶段做哪些，每个公司不一样的，在这上面还有很多工具。

    软件过程。大家都很关心CMM，CMM五级就是公共过程框架，把每个KPA就是一个过程框架，有很多框架的活动。上面有很多任务集合，工作任务、里程碑等等，要做过程肯定有这些东西。所以大家说质量，质量SQV，质量保证是过程中要做的。有一些不是KPA的东西是辅助过程。这张图总共18个KPA，二级当中会有六个，二级当中需求管理又分好几类，执行的活动等等。

    软件过程模型。把这些过程组合起来就是一个过程模型，讲到过程不得不提这个过程瀑布模型，瀑布模型太经典了。有很多说法，瀑布模型是线性的，按照以前做工程的经验做软件。模型那个好，那个不好是没有定论的。有几点可以分析，第一瀑布模型是非常经典的，从把工程概念引入到软件的起点，另外瀑布模型是一个以文档驱动的。第二个瀑布模型阶段划的很清楚，做项目管理的话很好管。瀑布模型可能带来一些不好，到最后测试和最后运行不知道最后会有什么错误。我做这些事情的时候其他人会闲着没事干，瀑布模型的时候，我们测试人员开始系统需求的时候，没有太多的事情去做。后来瀑布模型做了一些改进，都有一些反馈回去。

    进化模型。一般我们在做开发的时候是这么做的，瀑布模型是怎么驱动的，是以文档驱动的。进化模型是需求驱动的，做这个进化模型客户最开心。因为做进化模型的时候，很难把它作为一个项目管理。因为做落做去做项目的阶段不清晰，需求没有很明显的阶段做的话，很难弄。项目管理的时候带来一点难度，但是客户很开心。获取需求的时候我们用它，或者结合起来用。

    螺旋模型。第一个是文档驱动，第二个是需求驱动，第三个是风险驱动。这里其实把瀑布模型和螺旋模型综合，有风险分析。第一个版本开发不好，第二个时候重新进行分析以后，看看是不是可以，不可以再去分析。有一个特点，螺旋模型是全生命周期的，全生命周期都适用的，对搞企业软件运营和维护的人都好用。我们的模型总结来总结去，什么模型都是这三种变出来的，这三个是最起码的。我们公司在运用的时候，能不能嫁接一下，变成适合你公司特色的模型，这个是可以发明的，你怎么做可以自己去发明。但是我分析一下就这三个，瀑布模型、进化模型和螺旋模型。

RUP我也跟很多学员交流过，很多学员也用过。学软件工程RUP是不错的东西，提出六个最佳实践，还有九个核心工作流。九个核心工作流，RUP是把过程和方法统一的东西，过程就是九个。六个是核心工作流，三个是核心支持工作流，过程和方法很好的结合，所以大家学习的时候觉得非常不错，能够学到很多东西。我们搞CMM的时候，所以每家公司还得制定一个方法。CMM当中，有一个二级SQA，四级有一个质量管理，质量保证和质量管理是不一样的，只要涉及到质量管理肯定是量化的，SQA只是一些定性的保障，质量管理一定要有量化的。

如果你是做项目管理的，我阐述几个观点。项目管理在整个软件开发当中是一个必要条件，有之无必然，无之必不然，有了项目管理不能替代需求分析。有的人说我是PMP了我就能把项目做的很好，不是这样的。你是项目管理专家，但是并不会做需求分析，所以我们考PMP的可以学习一下用这些东西做软件。搞PMP的学建筑是怎么做的，可以考建筑师。PMP是一个什么都能用的东西。我们一定要注意项目管理不能替代所有的东西。我想通过这张图分析的很清楚，把质量、过程、方法、工具分清楚，这张图把项目管理和其他东西分清楚。

    高层示图，分为子个阶段，初始、细化、构造和移交。一个产品一个生命周期，产品可以分为若干个，每次都要经过这么一个阶段，这个阶段的时候又分为四步，构建阶段又分为若干个叠带。做这个的时候有一个问题，你在做RUP的时候，小的项目象XP，大的项目像IOP，也是一个重量的学习方法。如果把迭代画的太小了，画不好，自己没有很多经验，自己控制不好的话，很容易变成不断的修代码，从头到尾全部修一遍，很折腾的。理论上是很完善的，操作起来有点麻烦。你把理论搞清楚，对你是有用的。公司不要套用这个东西，否则花费是很大的。

微软的PCM模型。今天会讲两个模型，一个模型是PCM模型，一个是做产品的，做产品开发的看这个，微软做产品开发的，我觉得做的很好。我在国内做过一些事情我跟大家的思维可能是一样的，如果没有做过的话，也很难给大家讲的很清楚。共四个阶段：规划、开发、测试、发布。它是一个螺旋形结合的，但是在这个时候会有一些小技巧，表面上很简单，但是内部有很多东西。刚刚开始的时候会提出一个产品的Vision，我建议每家公司产品都提一个Vision，这个很有用。当年肯尼迪总统登月计划的时候，他的Vision，他说我要让我的飞船安全的登上月球再安全的返回来。这就是他们做所有事情的指导思想，总统制定的，这个飞机飞上月球，再飞回来。建议各位你回去把你的产品都设一个Vision。在国内做中间键，你是说我是做最安全的中间键，速度慢我无所谓，只要我安全就可以了。但是如果做最快的安全键，安全键差一点可以买别的产品。只要做出这样的东西你的产品会有卖点，否则的话什么都做什么都做不好，卖不出去。所以微软每个产品都有一个前景。还有一个Function Spec讲了很多了。

最难开发的阶段在M1阶段开发，逐渐增加功能。做了以后发现有一些变更再变，有很多阶段的。有的产品划了八个阶段，有的产品可能是三个阶段，根据需要，这个阶段划多少没有比例，也有人问我，我曾经去给他们讲过，这四个阶段时间比例是怎样的，我是没有答案，你想怎么做就怎么做，你先做了，自己去总结，做行业应用也好，你做你的产品有你的特点，关键是掌握他的方法就可以了，自己灵活应用。产品开发也是，做项目实施也是，只要客户满意就很好了。

    你可以去学习一下微软MSF，这个解决方案不一定是微软的产品，你用所有公司的产品可以用解决方案来做，是做应用的，看看这个模型有什么特点。做这个应用客户满意是第一的，并且要抓住整个企业要实现的价值和你要提供的功能结合起来。这时候经常产生一个问题，我们很多时候太关注于技术如何先进，忽略了这家企业本身的业务流程应该怎么去做。我们现在很多公司做企业流程重组，企业流程重组完了以后再上这报系统。我们经常帮助企业做他们流程的重造，但这套系统背后蕴含的管理价值我们忽略了。所以这个阶段一定要注意把我们要做的功能和价值结合起来，仅仅考虑技术没有用的。

    第二个是计划阶段。这个阶段包含了目前国内做的详细设计、需求分析都在这个阶段完成了。这个计划阶段微软做三个设计，概念设计、逻辑设计、物理设计。比如说做概念设计主要是从客户的需求，如果要做逻辑设计从团队这个角度考虑问题，需要考虑测试、开发问题，如果做物理设计，是从开发人员角度考虑的。做ERP系统可以适当的参考。开发测试阶段，不要测试单独作为一个阶段的。然后是稳定阶段，做两个事情，第一部分是有一些性能测试和压力测试。第二个要做试运行。微软的方法是不错的，怎么挑拣，怎么试运行有很多步骤。试运行以后我们会Deploying，做两个事情，一个真正部署出去，第二个过渡到运营。做这种解决方案有两个阶段，一个阶段是把事情做正确，但是最后一个阶段一定要过渡到Deploying。如果做一个企业IT管理人员，建议学一下MOF，MOF的来源是ITIL。ITIL是英国商务部搞出来的东西，现在已经成为全球标准。微软在ITIL的基础之上写了一个MOF，这是给你企业运营的，你作为公司的IT人员想把这个系统做好，我们公司负责做系统，做好以后还要维护系统，怎么维护有一套跟系统一样的规则，所以MOF一定要重视。我们可以关注一下MOF。大家如果作为一个公司IT领导，IT总监或者项目经理，或者更高层次的人，要把项目管理学一下。做产品开发也要学一下，应用开发也要学，做企业运营也要学。企业IT运营学会对你大有裨益。做Deploying，也有很多的技巧，比如说服务器怎么部署、客户端怎么部署，中间有很多技巧和方法。你可以自己去找一些资料看一下。

    里程碑，第一个阶段有Vision/Scope Approved，第二个阶段是Project Plans Approved，第三个阶段是Scope Complete，第四个阶段是Release Readiness Approved，第五个阶段是Deployment Complete。

    微软解决方案框架过程模型，也是分阶段的，可以通过做这个东西捕获需求。

    MSF两个模型，三个知识领域。大家做CMM也好，TSP也好，TSP里面提到五个角色，但是没有告诉团队怎么建设，也没有提到很好的过程。你要做好一个项目这两个东西不能少，微软通过自己的实践总结出来的东西我觉得是有道理的，做事情要有一个正确的模型，还有一个过程要总结好。然后要有一个项目管理，这就是PMP，PMP是做好项目的一个内容。还有风险管理，微软风险管理和项目管理一样重要，我从前不会做风险管理，我这个项目可能会有什么问题，我列一个清单，这个事情可能会有，没有采取任何措施，也不知道怎么办。投标的时候我们风险是这样的，措施是这样的，列出来，没有做任何事情。

    讲到团队模型这块，不要把团队模型和公司的组织架构混了。模型跟组织架构没有关系的，公司组织架构中很多做IT人着急试图改变公司的组织架构，我说不要去改变，公司的组织架构是公司董事会定的，你作为技术角度考虑肯定不全面。但是团队怎么建设，你可是要操心的，公司不管什么组织架构，只要把人找里，就可以建设这么一个团队。但是这个团队里就这么分工，跟公司组织架构关系不大，但是会受一些影响，尽可能做成一个团队，该怎么划分角色就怎么划分，不要受公司部门的影响。在PM当中也谈到三种，那个是组织架构，可以知道在这种组织架构之下对项目会有什么优、缺点，但是不要受它左右。