2011-2-22 来源:网络

 

一、 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项就可以了。

 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

文档及实施等

交付

 

 

 

版权声明:本文为Lostman原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/Lostman/archive/2011/03/15/1984465.htmlAndroid