软件过程课程总结

大三下学期已经接近尾声，《软件过程》课程也行将结束，回首这一路的学习历程，在此做一个小小的总结，比较一下各种软件过程模型的差别。

        首先说说瀑布模型，作为最早出现的软件开发过程模型，它在软件工程界具有重要的地位，它向我们提供了软件开发最基本的框架：制定计划、需求分析、软件设计、代码编写、软件测试、软件发布、运行维护。作为最先提出来的软件过程，它为项目提供了按阶段划分的检查点，当项目的前一阶段完成之后，我们只需要去关注后续的阶段。瀑布模型对很多类型的项目依然是有效的，如果正确使用，可以节省大量的时间和金钱，对于我们的项目而言，是否使用瀑布模型主要取决于用户需求在项目进程中的变化程度，变化越多，瀑布模型的缺点就会曝露在我们的面前：1)项目各个阶段中极少有反馈；2)只有在项目生命周期的后期才能看到结果。于是，我们就需要改进这种软件过程模型，V模型、W模型、等各种迭代开发模型就应运而生。

        接下来谈谈RUP（Rational Unified Process），RUP基础是迭代开发和风险驱动

，它在瀑布模型的基础上做了大的改进，核心工作流包括商业建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境。RUP的核心思想包括：1) 尽早并且持续的化解重大风险；2) 确保满足客户需求；3) 把注意力放在可执行软件上；4) 尽早在项目中适应变化；5) 在早期确定一个可执行的构架。RUP是一个二维的软件开发模型，横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，RUP中的软件生命周期在时间上被分解为四个顺序阶段：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段；而纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构。RUP的应用能够提高团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。但同时RUP也只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；此外，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端，但并不完美，在实际的应用中可以根据需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。

       再来讲讲CMMI--能力成熟度模型集成，CMMI 的提出主要是为了解决在项目开发中需要用到多个 CMM 模型的问题，它主要结合了SW-CMM（用于软件的能力成熟度模型）、SECM（系统工程能力模型）、IPD-CMM（集成产品开发能力成熟度模型），将它们融合到一个统一的改进框架内，为组织提供了在企业范围内的进行过程改进的模型。CMMI 有阶段式和连续式两种表示方法，以满足不同用户的需要，尽管表示方法不同，但最终目标是一致的。对于阶段式来说的话，总共可以分为五个阶段：完成级、管理级、定义级、量化管理级、优化级。这几个过程是一个逐步渐进的过程，但并不是说达到越高等级越好，对于不同的企业，要使用不同的适合于自己的级别才能使得企业往有益的方向发展。现在有些企业为了追求CMMI的等级，盲目的要求员工在开发的过程中使用高等级的方式，实际上是会给员工增加很多的繁琐工作，最后导致项目适得其反。

         再谈谈PSP（个人软件过程），它应该是基于CMMI而产生的，CMMI虽然提供了一个有力的软件过程改进框架，却只告诉我们“应该做什么”，而没有告诉我们“应该怎样做”，并未提供有关实现关键过程域所需要的具体知识和技能。而PSP就是在这个基础上产生的，实施PSP的一个重要目标就是学会在开发软件的早期实际地、客观地处理由于人们的疏忽所造成的程序缺陷问题。它是一种可用于控制、管理和改进个人工作方式的自我持续改进过程，是一个包括软件开发表格、指南和规程的结构化框架。PSP能够说明个体软件过程的原则，能够帮助软件工程师做出准确的计划，能够确定软件工程师为改善产品质量要采取的步骤，能够建立度量个体软件过程改善的基准，能够确定过程的改变对软件工程师能力的影响。PSP的应用和TSP是分不开的，两者良性的结合才能发挥出PSP的最大威力。

        下面再来说说敏捷开发中的Scrum，它是一种迭代式增量软件开发过程，它的一个显著特点就是能够尽快的响应变化，Scrum的基本假设是：开发软件就像开发新产品，无法从一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。Scrum应该算是一种返璞归真的软件过程，它摒弃了现如今软件开发中的繁琐的文档工作，专注于软件开发，但是作为一种软件过程也肯定是有弊端的，比如Scrum是一个项目管理框架，在技术方面没给任何建议，比如其对产品的backlog说明太少，再比如Scrum和通用的敏捷方法都很少谈及怎样扩展，虽然很多实践者有一些想法，但是还没有达成广泛的一致。

       不同的软件过程适用于不同的地方，随着软件工程的发展，新的、更适合于那时软件工程的软件过程也肯定不断的涌现出来，学海无涯，我们要做的就是以不变应万变，不断的总结，不断的更新脑海的知识，应用最适合于项目的软件过程。