目录
某互联网项目软件过程改进实践
1. 项目概述
2. 项目组织结构
3. 软件过程现状分析
3.1. 项目过程描述
3.2. 软件需求管理
3.3. 项目管理计划
3.4. 项目跟踪与监控
3.5. 软件配置管理
3.6. 软件质量保证
3.7. 培训大纲
3.8. 软件控制管理(软件测试)
3.9. 软件评审
3.10. 沟通协调管理
3.11. 风险管理
3.12. 分析总结
4. 软件过程改进计划
4.1. 在初始阶段
4.2. 细化阶段
4.3. 构建阶段
4.4. 交付阶段
4.5. 评审
5. 实施过程改进
6. 评估过程改进
6.1. 对商业目标的影响
6.2. 风险因素
6.3. CMMI中的定位
6.4. 对改进方案进行排序
6.5. 估计实施的进度表
6.6. 获得管理层的承诺
7. 参考文献
本公司主要运营互联网产品。每次均以项目的方式开发、升级产品。项目周期短。
项目名称：某互联网娱乐平台
软件开发方法：采用RUP进行迭代开发。本系统是B/S结构。并采用了MVC模式进行WEB开发。
软件开发技术及工具：
技术：Struts+Spring+Hibernate
工具：Eclipse3.2
数据库：ORACLE 10G
组织结构：弱矩阵
项目成员的角色：
角色 | 人数（名） | 部门 |
项目经理 | １ | 技术部 |
技术经理 | １ | 技术部研发组 |
测试经理 | 1 | 技术部测试组 |
系统架构师 | 1 | 技术部研发组 |
高级软件工程师 | ２ | 技术部研发组 |
软件工程师 | ２ | 技术部研发组 |
测试工程师 | ２ | 技术部测试组 |
项目助理 | １ | 技术部 |
美工 | 4 | 技术部UI组 |
需求工程师 | 2 | 产品部需求组 |
表1 项目角色表
软件开发流程：项目分6个迭代，每４周1个迭代。
1） 第1个迭代是项目初始阶段。开项目启动会议，确定项目章程、划定项目范围。进行项目的WBS计划、风险列表、项目管理计划、项目的里程碑并根据需求进行项目的系统设计工作。获得客户需求，画出用例图等。并选择2个风险较大的核心用例进行开发测试。
2） 第2个迭代进行项目的细化阶段。在完善第次1迭代制品的基础上。完成大部分用例的设计。并选择3个风险大用例进行开发、测试。
3） 第3~5个迭代进行项目构造阶段，根据剩余用例和系统设计对系统进行研发、测试。并发布BATE版到公网进行公测。
4） 第6个迭代进行项目的收尾移交阶段。编写项目的系统使用手册和培训文档等制品。
为确保项目交付物在提交时间内按质按量完成。在开发的过程中使用了SVN作为版本控制服务器。确保产品的版本一致性、减小风险。并作为绩效考核的依据之一。
每周一上午9:00开项目例会，对开发的实际情况进行跟踪并对项目管理计划进行监控、调整和工作的沟通协调。按计划交付里程碑规定的相应制品。单元测试始终伴随着开发进行。每个迭代代码研发阶段完成后。提交给测试组按照测试计划和测试用例进行集成测试。在测试结束后进行测试评估。并根据测试报告进行评审再将BUG反馈给研发组进行修改。在修改后测试组进行回归测试，确保项目的质量。在项目开发完成后，将产品移交给运营部进行维护。
公司发现在产品的第一版项目研发的过程中没有建立整套的软件工程体系。在软件工程的实践中基本上是以部门为单位进行管理和控制的，在统计的过程中，依据软件过程的主要过程以及所属部门进行分类和汇总。
在调查过程中，发现问题分属于10个不同的过程（域），他们分别是：软件需求、项目计划、项目跟踪与监控、软件配置管理、软件质量保证、培训大纲、软件控制管理(软件测试)、软件评审、沟通管理、风险管理。
从问题的分布结构，可以发现公司基本的软件过程还没有得到完善的建立，主要的问题集中在软件工程活动较基础的几个环节：
该过程主要考察软件项目的需求管理，包括产品需求的获取、系统需求的获取、软件需求的确定、软件需求的控制和变更等。
主要的问题：
1. 没有建立较全的需求管理过程。
2. 需求的变更没有进行管理、评估和跟踪测量。
3. 项目的研发组和其他软件相关组（如产品组（产生产品需求）、测试组）的成员缺乏实施需求管理活动的培训。
因需求导致影响较大的技术部的研发组、测试组和产品组。
结论：
需求不够完整，没有组织级的统一管理，在对需求的理解层次上还有所欠缺。
3.3. 项目管理计划
软件项目管理计划的目的是完成软件工程和管理软件项目制定合理的计划。依据项目初步范围说明书、项目管理各个过程、事业环境因素、组织过程资产通过项目管理方法系以及专家判断和项目管理信息系统将确定、协调与综合所有部分计划所需要的行动形成文件，使其成为项目管理计划。它确定了执行、监控、和结束项目的方式和方法。
软件项目管理计划包括：
项目范围管理计划、进度管理计划、费用管理计划、质量管理计划、过程改进计划、人员配备管理计划、沟通管理计划、风险管理计划、采购管理计划、里程碑清单、资源日历、进度基准、费用基准、质量基准、风险登记手册等。
主要问题：
1. 没有根据规范制定项目计划，项目中仅对项目进度管理计划、资源日历进行了详细的制定。其它均比较模糊。
2. 软件质量保证组没有进行评审和（或）审核软件项目计划和产品。
3. 历史数据的收集、比较、管理做的比较差。
项目管理计划没有统一的规范，各部门依据自己的规范制定各部门的工作计划，计划没有经过质量保证组及相关人员的评审。软件项目管理计划中的项目范围管理计划、费用管理计划、质量管理计划、过程改进计划、沟通管理计划、风险管理计划、采购管理计划、费用基准、质量基准、风险登记手册等比较粗糙。其制定主要根据计划编制人的经验。
结论：
项目缺乏有效的控制，项目经理对项目的控制依靠个人的能力。
3.4. 项目跟踪与监控软件项目的跟踪与监控的目的是建立对实施进展的适当的可视性，使管理者能在软件项目性能明显偏离软件计划时采取有效措施。
主要问题：
因为项目中没有对软件产品的范围、成本以及风险进行量化，而工作量的安排没有细致到合理的粒度，所以项目进度的跟踪没有足够的量化的依据。
没有组织级的跟踪和控制项目机制，当前周报的机制不能对项目起到合适的监控作用。
没有统计和汇报项目实际情况并与项目计划的偏差比较。
项目的跟踪与监控，很大程度取决于项目计划编写的科学性，公司目前项目进度没有书面的跟踪与监控机制，当前实施的有员工周志制度，该制度效果较差，另外部分项目组或部门有周例会制度。
结论：
项目级的跟踪机制只能依靠各层管理人员的人为管理、干预。
软件配置管理的目的是建立和维护在项目的整个软件生命周期中软件项目产品的完整性。软件配置管理包括标识在给定时间点上的软件配置（即选定的软件工作产品及其描述），系统地控制对配置的更改，并维护整个生命周期内配置的完整性和可可跟踪性。
主要问题：
1. 配置项的识别和描述（以代码为主）不规范，没有建立基�
