软件开发过程学习总结
目的：初步理解CMM、RUP、XP分别是怎样的过程，弄懂其关键步骤，分析其优劣及适应情况。最后综各家之长，给出一个可能较实用可行的软件开发过程体系X Process，以用在项目(或产品)开发中。
By Robin Zhang. robinzhangblogs/ MSN:Robinsz@hotmail
一、 CMM
xp提交更改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%需求，编写需求规格书。制定迭代计划，需求基线；完成重要用例的设计及实现，由此确定系统架构及第三方组件。已制定迭代计划。同时编写对应用例的测试用例。
构建阶段：
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论