软件开发过程学习总结CMM、RUP、XP1

>
>
>
软件开发过程学习总结
目的：初步理解CMM、RUP、XP分别是怎样的过程，弄懂其关键步骤，分析其优劣及适应情况。最后综各家之长，给出一个可能较实用可行的软件开发过程体系X Process，以用在项目(或产品)开发中。
By Robin Zhang.http://robinzhang.cnblogs.com/MSN:Robinsz@hotmail.com
一、       CMM
1. 综述
CMM2－CMM3，可以看作是一个严谨的，传统瀑布式的开发体系。
CMM并未提供具体的过程体系，它只是一个评价标准(“软件能力成熟度”)。
但它提供了一个目标：一个可重复赋值成功经验的开发体系应该是怎样的。
知识点：
1).通常应该从CMM2开始实现，一般做到CMM3的已经难得了。
2).CMM2是一套已定义的项目管理过程，CMM3是总结不同项目的经验，最终形成组织（公司）的一套过程标准。
3).可以考虑交叉引用，即上CMM2及CMM3的培训、同行评审。
4).CMM与CMMI的区别：前者仅限于软件工程,后者还包括其他学科的CMM，如系统工程等；前者一般意味着瀑布过程，后者支持迭代方法。
参考：
CMM2:“定义了项目管理过程，将项目划分成几个明确定义的阶段，每个阶段结束都是控制点，增加了软件开发过程的透明度和可控性。项目执行中好的经验可以在别的项目中重复，软件开发有了一定的保证。”
CMM3: “是对CMM 2 项目管理的全面整合和提高，综合公司所有类型项目的过程经验，制定公司统一的最佳过程，增加了对项目每个阶段的内部过程规定和检查点，使得软件开发工程更加透明和可控。”
2. 关键过程
包括：
CMM2：项目计划、需求管理、配置管理、质量管理、项目过程控制。
CMM3：同行评审(需求、设计、代码评审)、培训计划、体系规范
注：能做到上面8项就可以了。
CMM等级
关键域 KPA
对应产出、流程操作
相关产出、过程(参考)
CMM2
需求管理
需求基线
项目建议书,概要需求,需求评审,需求规格书
软件项目计划
建立一个合理有效的软件项目计划
软件项目立项书、风险分析控制报告等
软件项目跟踪和监督
项目管理,过程管理
任务分解、下达，每日耗费，每周例会，单元测试报告，里程碑等
软件配置管理
标识软件配置项，建立产品基线库，对配置项的修改加以系统的控制
配置管理计划,VSS代码库,版本,代码同步,演示帐套
软件质量管理
单元测试、功能测试、继承测试等
质量保证计划,测试计划,测试用例,产品质量报告,单元测试、功能测试、继承测试等
子合同管理
外包管理
CMM3
同行评审
需求评审,设计评审,代码评审
培训计划
知识共享,内部培训,VSS共享,创新奖等
组织级过程焦点，组织级过程定义，集成软件管理，软件产品工程，组间协调，
1.各种规范：需求、分析设计、编码、
数据库规范。
2.体系规定文档
3. 适用情况
1).中大型软件企业，同时进行多个项目、产品的研发（必须有一套体系以便管理、控制）。
2).需求比较明确，并已经定义冻结的情况，如产品项目。
3)适合用瀑布式过程开发的项目。
4. 优劣
优点：体系严谨，提高了软件开发过程的透明度和可控性，令项目成功经验可以重复复制。
缺点：因瀑布过程需要，要求需求冻结，导致需求过程要求非常高。而在项目中，需求变更是不可避免的。
5. 其他
企业上到一定规模，偏重产品开发时，可以考虑上CMM。中小软件企业可借鉴并精简地实现它的关键过程，如项目计划、需求管理、配置管理、质量管理、项目过程控制、同行评审、培训计划。
二、      RUP
1．    综述
RUP是一个由用例驱动、以架构为中心的、迭代增量的开发过程框架。
2．    关键过程
迭代开发过程及产出：见：《UML和设计模式》第一页。
流程
工件
初始
精化
构造
交付
项目管理
软件开发计划等
S:1)定义项目目的，范围、约束。
2)第一个迭代计划
1）  分析需求用例，确定迭代计划(任务时间表)。
2）  确定编码等规范
3）  需求基线
1）按迭代计划进行开发
2）每个迭代都实现一个用例集，包含一个设计编码测试过程。
客户测试评估
上线运行
业务建模
领域模型
S 细化建模
需求
用例模型、需求规格说明书、补充需求文档
S:1)确定Actor及其需要。2)确定最重要的用例
R 1)编写详细用例需求规格书 2)确定更多用户需要、产品特性、用例集合并确定其优先级重要性风险。需求初步基线。
r迭代过程中允许需求变更，但必须受控，分析对目前需求的影响，再决定是否在下一个迭代基线进去。
设计
设计模型、软件架构文档
R挑选部分重要用例，开始建设计模型
R对迭代内的用例进行更详细的设计
实现
实现代码
S 1）实现部分重要且风险大的用例，以验证并确定架构设计。
R 全力编码，按时完成迭代内的用例实现。
测试
测试用例
S根据用例编写测试用例
测试已实现迭代功能，编写新迭代的测试用例
文档等
使用文档等
s
产品文档，用户培训
产出
项目计划书(前景文档)、高层用例模型、最重要用例规格说明书、(概要设计说明书？)、开发环境(总体软件架构、开发规范)
80%详细需求规格书(用例集及补充说明书)、用例模型、领域模型及设计模型，部分详细设计文档，部分测试用例，产生一个可执行的原型(实现部分重要用例)
内部发版，可用于测试的完整产品。详细设计说明书
产出2
项目计划、概要需求列表、初步架构说明、重要用例需求规格书、编码规范
需求规格说明书(80%)，概要设计文档(?)、项目迭代计划、重要用例的设计及实现,
设计模型，详细设计说明书，代码实现，测试用例（迭代）
产品、说明文档，用户培训
s开始，r精化提炼
3．    适用情况
4．    优劣
5．    其他
参考：
三、       XP
Xp注重人的因数，提倡尽量敏捷轻量级的过程。
重要过程：测试驱动、迭代开发、持续集成构建、客户现场参与(确定迭代内的功能集，提供业务逻辑的确认，验证程序等)、只在必要时做简单设计
一)、Xp的缺点：
1.       要求客户现场参与。通常国内项目都是前期作需求确认，无法提供整个开发过程的需求确认支持。除非是分段来确认（如迭代结束时）。
2.       测试驱动开发。目前还很难做到，因为编写测试脚本需要花费不少精力，一般项目无法做到。由此也无法作重构，无法保证能有灵活的设计来支持因前期不明确的需求而导致的变更。
3.       缺少文档、设计支持。Xp只在必要时才写文档及设计，这样可能导致xp新手缺乏良好的设计指引，项目开发过程透明度不够，可能会失控。
二）、xp可借鉴的地方
1.       对整个开发过程：迭代开发、持续集成
2.       对特定迭代：编码规范、保持设计灵活(允许需求改动)
3.       设计编码过程：测试驱动、重构(用在编码过程中，以客户端来“测试驱动”业务逻辑层、以重构减少重复代码)
参考：
四、实用过程X Process：RUP+XP，并达到CMM2-3
考虑目前国内项目现况：需求调研先行，但需求不明确导致需求变更。中小公司缺乏过程规范指导，基本在CMM1即混乱状态。
X Process ＝ CMM的体系+RUP的过程+XP的最佳实践
参考文档：xp_vs_cmm.pdf, RUPvsXP.pdf, RUP and XP.pdf,dX Process
1.       过程：取RUP的过程
过程还是取项目启动、细化、构建、交付四个过程。
启动阶段：
定义项目计划、风险分析、项目前景、范围、约束；确定Actor、涉众及收益；确定概要需求；作一个原型，实现关键用例。
细化阶段：
确定用户需要、产品特性并确认优先级、风险；确定80%需求，编写需求规格书。制定迭代计划，需求基线；完成重要用例的设计及实现，由此确定系统架构及第三方组件。已制定迭代计划。同时编写对应用例的测试用例。
构建阶段：
按计划迭代开发。在每个迭代里采用小瀑布的方式，应用部分XP的最佳实践(见下2)，每个迭代为一个里程碑，提交给客户确认，由此得到需求变更，分析后调整迭代计划。
交付阶段：
提交客户测试，作小的修改。编写产品说明，用户培训，上线运行。项目总结、关闭报告。
2.       迭代内的步骤：取xp的最佳实践
合并细化的后期+构造期，为“设计编程期”，在这期间，启用“保持设计灵活”、编码规范、代码审核(结队编程)、持续集成、测试驱动、重构的最佳实践。
3.       使用CMM的关键域的规范流程，，以达到CMM2-3的效果
在RUP的四个阶段中，应用CMM的关键域，来保证各种产出的质量。如下：
先启阶段：项目计划、项目过程控制、配置管理、培训计划(设计、编码规范)
细化阶段：体系规范、同行评审(需求、设计、代码评审)、需求管理、质量管理
构建阶段：编码规范、设计、代码评审、需求变更管理
交付阶段：体系规范
三者的关系如下：
1.       RUP：是由用例驱动、迭代增量开发的过程，主要定义了各个阶段应该做什么，做到什么程度。
2.       CMM：是一套评估标准，提供了一些关键实现域(需求管理等)，对每一个产出提出了质量要求。
3.       XP：主要关注编码阶段的一些最佳实践。是一个提倡敏捷的轻量级软件开发方法。强调“交流；简单；反馈；实事求是”。强调客户参与，简单设计(灵活设计)、允许需求变更等。
4.       下面是按传统瀑布式的过程，来考察三种过程方法在各个阶段的活动及产出。
过程
RUP
CMM
XP
项目启动
先启
项目计划、风险列表、过程控制、配置计划、概要需求列表等
客户尽可能参与
需求调研
先启、精化(用例模型)
需求管理、需求评审、需求基线
客户尽可能参与
分析设计
精化、构建(领域模型、设计模型)
设计评审、软件配置、培训计划
灵活设计、需求变更
编码实现
构建、启动、精华(代码)
代码评审、需求变更控制
测试驱动开发、重构、编码规范、日构建、小版本发布、简单实现
测试
构建、精化
质量管理
Unit Test
文档及实施等
交付