一、 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新手缺乏良好的设计指引，项目开发过程透明度不够，可能会失控。
&nb