某互联网项目软件过程改进实践
目录
1. 项目概述
本公司主要运营互联网产品。每次均以项目的方式开发、升级产品。项目周期短。
项目名称：某互联网娱乐平台
软件开发方法：采用RUP进行迭代开发。本系统是B/S结构。并采用了MVC模式进行WEB开发。
软件开发技术及工具：
技术：Struts+Spring+Hibernate
工具：Eclipse3.2
数据库：ORACLE 10G
2. 项目组织结构
组织结构：弱矩阵
项目成员的角色：
| 角色 | 人数（名） | 部门 |
| 项目经理 | １ | 技术部 |
| 技术经理 | １ | 技术部研发组 |
| 测试经理 | 1 | 技术部测试组 |
| 系统架构师 | 1 | 技术部研发组 |
| 高级软件工程师 | ２ | 技术部研发组 |
| 软件工程师 | ２ | 技术部研发组 |
| 测试工程师 | ２ | 技术部测试组 |
| 项目助理 | １ | 技术部 |
| 美工 | 4 | 技术部UI组 |
| 需求工程师 | 2 | 产品部需求组 |
表1 项目角色表
3. 软件过程现状分析[1]
3.1. 项目过程描述
软件开发流程：项目分6个迭代，每４周1个迭代。
1） 第1个迭代是项目初始阶段。开项目启动会议，确定项目章程、划定项目范围。进行项目的WBS计划、风险列表、项目管理计划、项目的里程碑并根据需求进行项目的系统设计工作。获得客户需求，画出用例图等。并选择2个风险较大的核心用例进行开发测试。
2） 第2个迭代进行项目的细化阶段。在完善第次1迭代制品的基础上。完成大部分用例的设计。并选择3个风险大用例进行开发、测试。
3） 第3~5个迭代进行项目构造阶段，根据剩余用例和系统设计对系统进行研发、测试。并发布BATE版到公网进行公测。
4） 第6个迭代进行项目的收尾移交阶段。编写项目的系统使用手册和培训文档等制品。
为确保项目交付物在提交时间内按质按量完成。在开发的过程中使用了SVN作为版本控制服务器。确保产品的版本一致性、减小风险。并作为绩效考核的依据之一。
每周一上午9:00开项目例会，对开发的实际情况进行跟踪并对项目管理计划进行监控、调整和工作的沟通协调。按计划交付里程碑规定的相应制品。单元测试始终伴随着开发进行。每个迭代代码研发阶段完成后。提交给测试组按照测试计划和测试用例进行集成测试。在测试结束后进行测试评估。并根据测试报告进行评审再将BUG反馈给研发组进行修改。在修改后测试组进行回归测试，确保项目的质量。在项目开发完成后，将产品移交给运营部进行维护。
公司发现在产品的第一版项目研发的过程中没有建立整套的软件工程体系。在软件工程的实践中基本上是以部门为单位进行管理和控制的，在统计的过程中，依据软件过程的主要过程以及所属部门进行分类和汇总。
在调查过程中，发现问题分属于10个不同的过程（域），他们分别是：软件需求、项目计划、项目跟踪与监控、软件配置管理、软件质量保证、培训大纲、软件控制管理(软件测试)、软件评审、沟通管理、风险管理。
从问题的分布结构，可以发现公司基本的软件过程还没有得到完善的建立，主要的问题集中在软件工程活动较基础的几个环节：
3.2. 软件需求管理
该过程主要考察软件项目的需求管理，包括产品需求的获取、系统需求的获取、软件需求的确定、软件需求的控制和变更等。
主要的问题：
1. 没有建立较全的需求管理过程。
2. 需求的变更没有进行管理、评估和跟踪测量。
3. 项目的研发组和其他软件相关组（如产品组（产生产品需求）、测试组）的成员缺乏实施需求管理活动的培训。
因需求导致影响较大的技术部的研发组、测试组和产品组。
结论：
需求不够完整，没有组织级的统一管理，在对需求的理解层次上还有所欠缺。
3.3. 项目管理计划
软件项目管理计划的目的是完成软件工程和管理软件项目制定合理的计划。依据项目初步范围说明书、项目管理各个过程、事业环境因素、组织过程资产通过项目管理方法系以及专家判断和项目管理信息系统将确定、协调与综合所有部分计划所需要的行动形成文件，使其成为项目管理计划。它确定了执行、监控、和结束项目的方式和方法。
软件项目管理计划包括：
项目范围管理计划、进度管理计划、费用管理计划、质量管理计划、过程改进计划、人员配备管理计划、沟通管理计划、风险管理计划、采购管理计划、里程碑清单、资源日历、进度基准、费用基准、质量基准、风险登记手册等。
主要问题：
1. 没有根据规范制定项目计划，项目中仅对项目进度管理计划、资源日历进行了详细的制定。其它均比较模糊。
2. 软件质量保证组没有进行评审和（或）审核软件项目计划和产品。
3. 历史数据的收集、比较、管理做的比较差。
项目管理计划没有统一的规范，各部门依据自己的规范制定各部门的工作计划，计划没有经过质量保证组及相关人员的评审。软件项目管理计划中的项目范围管理计划、费用管理计划、质量管理计划、过程改进计划、沟通管理计划、风险管理计划、采购管理计划、费用基准、质量基准、风险登记手册等比较粗糙。其制定主要根据计划编制人的经验。
结论：
项目缺乏有效的控制，项目经理对项目的控制依靠个人的能力。
3.4. 项目跟踪与监控软件项目的跟踪与监控的目的是建立对实施进展的适当的可视性，使管理者能在软件项目性能明显偏离软件计划时采取有效措施。
主要问题：
因为项目中没有对软件产品的范围、成本以及风险进行量化，而工作量的安排没有细致到合理的粒度，所以项目进度的跟踪没有足够的量化的依据。
没有组织级的跟踪和控制项目机制，当前周报的机制不能对项目起到合适的监控作用。
没有统计和汇报项目实际情况并与项目计划的偏差比较。
项目的跟踪与监控，很大程度取决于项目计划编写的科学性，公司目前项目进度没有书面的跟踪与监控机制，当前实施的有员工周志制度，该制度效果较差，另外部分项目组或部门有周例会制度。
结论：
项目级的跟踪机制只能依靠各层管理人员的人为管理、干预。
3.5. 软件配置管理
软件配置管理的目的是建立和维护在项目的整个软件生命周期中软件项目产品的完整性。软件配置管理包括标识在给定时间点上的软件配置（即选定的软件工作产品及其描述），系统地控制对配置的更改，并维护整个生命周期内配置的完整性和可可跟踪性。
主要问题：
1. 配置项的识别和描述（以代码为主）不规范，没有建立基线。
2. 配置管理的过程不规范，软件配置管理的控制和更改不完善。
项目有建立软件配置管理库（SVN），有相应的简单过程（没有完全实施），配置管理的程度靠配置管理人员的能力，配置管理的人力方面存在安全风险。
结论：
配置管理的范围只在初级的代码和技术文档的配置控制，配置库有安全的风险。
3.6. 软件质量保证
软件质量保证（QA）的目的是向管理者提供适当的对软件项目正使用的过程和正构造产品的可视性。软件质量保证包括评审和审计软件产品和活动以验证它们符合适用的规程和标准，给项目和其它相关的经理这些评审和审计的结果。
主要问题：
1. 没有机构管理策略来实施软件质量保证。
2. 软件工程活动没有进行一致的验证，对软件质量保证的认识程度仅限于软件测试阶段。
3. 没有归档、处理和跟踪软件活动和软件工作产品中的偏差。
有一部分的软件质量保证的工作在项目组中进行，另有一部分在企业战略策划组，因为没有相关的规程，以及受到自身角色的限制，所以质量保证活动基本上属于失控状态。
结论：
组织中缺少质量保证的人员和资源，质量保证活动系统的展开和管理，高层管理人员的监控和支持不够。
3.7. 培训大纲
培训大纲的目标是提高个人的知识和技能，使其有效地履行职责。
主要问题：
1. 公司没有负责实施培训的小组，没有书面的培训管理策略。
2. 没有对培训需求的识别和管理，缺乏对培训活动的控制和实施。
3. 公司因为缺乏对项目的了解，特别是技术方面的了解，导致在软件需求方面不稳定。另外员工普遍缺乏对项目管理和软件工程方面的培训。
结论：
公司没有系统的培训规划，缺少足够的资源，高层管理人员重视不够，员工缺乏产品开发技术以及项目管理、软件工程等方面的培训。
3.8. 软件控制管理(软件测试)
软件控制管理（软件测试）的目的是为了始终如一的执行严格定义的项目过程。软件工程任务包括分配到软件上的系统需求、软件需求开发、软件架构开发、软件设计、软件代码实现、软件元素集成以及软件测试以验证其是否满足具体要求（即分配到软件上的系统需求和软件需求）。
主要问题：
1. 软件测试过程没有覆盖到足够的层次。
2. 各个阶段测试准备都就绪准备没有建立。
3. 各个层的软件测试活动的规程没有。测试计划、测试用例不完善，或者没有进行评审。
4. 公司的单元测试、集成测试、部分回归测试是项目组进行的，相应的测试规程不完善。对于项目组内的测试能力依靠测试者的个人能力，单元测试没有很好的进行管理和控制。测试负责进行产品的验收测试或者系统测试，测试组与其它部门接口不够明确。
结论：
公司有软件产品测试管理体系，但软件产品测试范围不能覆盖到足够的层次。
3.9. 软件评审
软件评审的目的是尽早有效地排除软件工作产品中存在的问题。软件评审包括对软件工作产品进行系统检查，以发现问题和需要修改的范围。要进行软件评审的具体产品在项目的被定义软件过程中被标识，并且作为软件项目策划活动的组成部分被列入进度。
主要问题：
1. 没有对需要进行评审的工作产品的识别、以及实施评审的规程。
2. 公司没有严格定义上的评审，但一些关于代码审查（走查），以及一些技术文档的评审是以评审的形式进行的。评审的工作产品与规程没有组织级的定义，在各个部门或项目的规程中有部分定义，但是实施没有受控。
结论：
评审已经在项目中应用，但没有组织级统一的过程定义和监督。
3.10. 沟通协调管理
沟通管理包括软件工程组对其它工作组工作的参与，以适应系统级的需求、目标和问题。需求组、技术组和测试组参与建立系统级的需求、目标和计划。这些需求、目标和计划成为所有工程活动的基础。组间的技术工作接口和相互配合形成计划并被管理，以确保整个系统的质量和完整性。
主要问题：
1. 制定需求时，相关组的协调不完善。
2. 没有确定、协调和跟踪项目组之间的关键依赖关系的书面规程。
3. 没有以书面计划方式约定小组的工作。
在调查中，因沟通协调而出现的工作问题比较直接，而且比较严重，沟通协调容易出现问题的一般是跨部门。一般影响工作产品的质量的程度都比较严重，如项目超期，需求更改等等。
结论：
沟通协调工作不够，各小组间以及部门间的接口不够明晰，没有公司级的统一沟通管理机制。
3.11. 风险管理
风险是一种不能确定的事件或情况，一旦发生，会对至少一个项目目标如：时间、费用、范围或质量产生积极或消极的影响。风险管理就是对项目进行规划、识别、分析、应对和监控的过程。它的目标是增加积极事件的概率和影响，降低项目消极事件的概率和影响。
主要问题：
1、 风险管理规划、风险登记表、风险分析、风险应对规划以及对风险的监测与控制重视程度不够、过程不规范。
2、 风险的应对大部分根据个人的能力。遇到突发风险，没有预选的风险应急计划。
总结
系统在实施的过程中有很多不可预知的风险。为此项目团队借鉴了一些以往风险列表中的风险，并将其放在风险计划上来预防风险的发生并解决已发生的风险。在项目结项时，将所发生的风险总结到风险列表中，以便以后的项目借鉴。
3.12. 分析总结
优点：
较好的过程存在与软件设计实现和测试过程。
技术能力是强项，包括设计和编码方面做的比较好。同时也反映出了公司在推行软件工程的过程中还有许多不足之处。可以保证需求被管理。过程得到计划、执行、衡量和控制。有助于保证现有的过程即使在处于压力下也能够执行。在执行过程中，项目按预定的计划进行管理。
缺点：
其主要问题体现在需求的制定（获取）、理解和变更控制。
沟通协调和测试过程中发生的问题，很多都源于软件需求不明确和更改没有受控，而需求过程的主要问题，并不只是因为过程以及过程定义的问题，更多的问题是偏于技术能力方面的，所以在技术培训方面的过程中有所欠缺。
4. 软件过程改进计划[2]
过程改进的要素是：
文档化、培训、实践、强制、可提高、可裁剪。
4.
过程改进的总体计划通常包括：介绍、制定计划时所使用的方法、对评审结果和推荐措施的总结，主要内容是各个改进项目的方案和策划活动的结果。
4.1. 在初始阶段
在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。在这个阶段中所关注的是整个项目的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段可能很短。
（1） 明确项目规模
建立项目的软件规模和边界条件，包括验收标准；了解环境及重要的需求和约束，识别系统的关键用例(Use Case)。
（2）评估项目风险
软件过程主要关心的是软件开发的已知方面，只能准确描述、计划、分配和评审那些已经知道将要完成的事情。风险管理则主要关心未知方面。在基于RUP的迭代式软件过程中，很多决策要受风险决定。要达到这个目的，开发者需要详细了解项目所面临的风险，并对如何降低或处理风险有明确的策略。
（3）制订项目计划
估计整个项目的总体成本、进度和人员配备。综合考虑备选体系结构，评估设计和自制、外购、重用方面的方案，从而估算出成本、进度和资源。在这个过程中，要通过对一些概念的证实来证明可行性，该证明可采用可模拟需求的模型形式或用于探索高风险区的初始原型。初始阶段的原型设计工作应该限制在确信解决方案可行就可以了，具体实现留到细化阶段和构建阶段。
（4）阶段技术评审
初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，并决定继续进行项目还是取消项目。在评审过程中，需要考虑项目的规模定义、成本和进度估算是否适中，估算根据是否可靠，是否已经确定所有风险，并且有针对每个风险的规避策略等问题。
4.2. 细化阶段
细化阶段的任务是分析问题领域，建立健全的体系结构基础，淘汰项目中最高风险的元素。在细化阶段，必须在理解整个系统的基础上，对体系结构做出决策，包括其范围、主要功能和诸如性能等非功能需求，同时为项目建立支持环境。
（1） 确定体系结构
确保体系结构、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定开发所需的成本和开发进度。通过处理体系结构方面重要的场景(Scene)，建立一个已确定基线的体系结构。证明已建立基线的体系结构将在适当时间、以合理的成本支持系统需求。
（2） 制订构建阶段计划
为构建阶段制订详细的过程计划并为其建立基线。
（3） 建立支持环境
建立支持环境，包括开发环境、开发流程、支持构建团队所需的工具和自动化/半自动化支持。
（4） 选择构件
评估现有的(构件库)和潜在构件，充分了解自制、外购、重用决策，以便有把握地确定构建阶段的成本和进度。集成所选构件，并按主要场景进行评估。
（5） 阶段技术评审
评审时，需要检验详细的系统目标和范围、体系结构的选择以及主要风险的解决方案。在技术评审中，需要考虑的问题有：
（1）产品需求是否稳定，体系结构是否是稳定的。
（2）可执行原型是否表明已经找到了主要的风险元素，并且得到妥善解决。
（3）构建阶段的迭代计划是否足够详细和真实，是否有可靠的估算支持，可以保证工作继续进行。
（4）所有与项目有关的人员是否一致认为，如果在当前体系结构环境中执行当前计划来开发完整的系统，则当前的需求可以实现。
（5）实际的资源耗费与计划的耗费相比是否有偏差，该偏差是否可以接受。
在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制操作，以优化成本、进度和质量。
4.3. 构建阶段
构建阶段的主要任务是通过优化资源和避免不必要的报废和返工，使开发成本降到最低；完成所有所需功能的分析、开发和测试，快速完成可用的版本；确定软件、场地和用户是否已经为部署软件作好准备。
在构件阶段，开发团队的工作可以实现某种程度的并行。即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各团队之间实现并行开发。这种并行性在较大幅度地加速开发进度的同时，也增加了资源管理和工作流程同步的复杂程度。
构建阶段结束时也要进行技术评审，评审产品是否可以在β测试环境中进行安装和运行。在评审中，需要考虑的问题有:
（1）该产品发布版是否足够稳定和成熟，可安装和运行在实际环境中。
（2）所有与项目有关的人员是否已准备好将产品发布。
（3）实际的资源耗费与计划的耗费相比是否有偏差，该偏差是否可以接受。
当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。交付阶段的重点是确保软件对最终用户是可用的。
4.4. 交付阶段
交付阶段的主要任务是进行β测试，制作产品发布版本；对最终用户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品，如进行调试、性能或可用性的增强等。
交付阶段结束时也要进行技术评审，评审目标是否实现，是否应该开始进化过程，用户对交付的产品是否满意等。
4.5. 评审
在每个阶段结束时都要进行一次技术评审，以确定在完成该阶段的最终迭代后是否应该让项目进入下一阶段。技术评审要考虑的主要问题应该主要与项目管理有关，因为主要的技术问题应该已经在该阶段的最终迭代以及随后的活动中得到解决。
（1） 安排评审会议日程
技术评审会议的参加者必须包括项目的管理团队（项目经理以及项目团队各功能区域的团队负责人）和项目评审委员会。与会者一旦确定，就应安排会议的召开日期和时间，以便为与会者留出充足的准备时间，让他们能够评审有关材料。
（2） 分发会议材料
在会议召开之前，应当将技术评审材料分发给评审人员。要在会议召开之前及早地将这些材料分发出去，让评审人员有充足的时间对其进行审阅。
（3） 召开评审会议
在会议期间，评审人员主要关注状态评估。在会议结束时，评审人员应作出是否批准的决定。技术评审会议可能会得到以下结果之一：
（Ⅰ）阶段被接受：评审委员会认为项目实现了该阶段的预期目标，可以进入下一阶段。
（Ⅱ）有条件接受：评审委员会同意项目可以进入下一阶段，但必须先完成指定的纠正操作。如果发现的问题很少并且不是很重要，则客户可能决定在项目团队执行某些纠正操作的同时有条件地接受该产品。在这种情况下，项目经理需要根据问题的重要性，或选择开始新的迭代，以处理所出现的问题，或只是通过延长最终迭代来处理问题，二者的差异在于所需的计划工作量。
（Ⅲ）阶段不被接受：项目没有实现该阶段的预期目标，项目经理就可能必须开始另一次迭代，甚至项目经理无法决定对问题的解决方案，而需要由有关人员根据合同重新确定项目规模或终止项目。
（4） 记录会议决定
在会议结束时应完成评审记录，其中包括重要的讨论或活动以及评审的结果。如果结果是"阶段不被接受"，则应暂时安排一次后续复审。
5. 实施过程改进
在项目的第二版版本时，公司加强了软件过程的管理并依据过程改进计划实施过程改进：
在项目的初始阶段，主要建立项目的软件规模和边界条件，明确用户的需求，形成规格说明书，作为验收标准。同时，估计了整个项目的总体成本和进度，评估了潜在的风险，作出了具有20%资源预留的项目计划。选择了Rational Rose 2003作为分析和建模工具、Project 2003作为项目管理工具。系统开发工具采用Eclipse3.2，后台数据库管理系统采用Oracle 10G。
在项目的细化阶段，我们根据实际需求，选择了B/S软件体系结构。攻关一些关键性的算法，制作了页面的原型。并在此基础上，为构建阶段制订了详细的迭代计划。在构件的选择方面，决定主要采用已有构件，对构件库中没有的构件，则重新开发。
在项目的构建阶段，主要任务是完成新构件的开发和测试，集成所有构件，进行集成测试。
在项目的交付阶段，把经过集成测试的软件发布到公网服务器上，接受实际环境的公测。然后对客服、维护人员以及有关用户进行培训和指导。在公测结束后，系统正式上线。
在以上各阶段结束时，都进行了阶段技术评审。
由于全面采用了基于RUP的软件过程，规范了管理和开发流程，有效地控制了资源，该项目使用部分预留资源。在系统运行期间，根据市场的导向和公司的商业战略，运营部对该软件进行优化，最终由软件项目过渡到一个产品。现在，该软件产品已经在互联网上使用，用户反映良好。
6. 评估过程改进[3]
6.1. 对商业目标的影响对商业目标的影响是指某项改进工作对总体的战略目标的影响。首先，策划小组要和主管的高层经理进行讨论，明确公司商业目标、并分析确定决定商业目标能否实现的5-7个关键成功因素（CSFs）。明确成文的商业目标，并且形成了文档，策划小组的核心工作就是分析关键成功因素并每个关键成功因素确定权重。接下来，要对每项改进活动进行分析，按其对每个关键成功因素的贡献进行评分，然后将结果进行加权平均，作为最后比较的一个依据。
6.2. 风险因素
通常，风险的来源主要有三个方面：项目的规模、结构的问题和技术。项目规模风险，是指实施的人工成本，一般人工成本越低风险越小。
结构方面的风险，主要有以下因素：参与该项目开发的功能组的数量 。项目的复杂程度。制定解决方案的人员在该过程域的经验是否丰富。对改进中带来变更，预期存在抵触行为 。
技术风险，主要包括以下方面：需要改进的软件工程过程的成熟程度 。能否获得充分的新技术方法的培训 。工具和其他支持条件的成熟程度 。
6.3. CMMI中的定位
是指某一改进活动对达到更高能力成熟度等级的贡献。权重是按照KPA所属的能力成熟度等级来确定，比较简单。初步确定：目前所处等级的下一个能力成熟度等级的KPA权重最大且相等，其后按顺序递减。各改进点的分值按 其对个KPA的影响确定，有些改进点可能影响多个KPA；另外需要注意，各个改进点对某一个KPA的影响总值不能超过100%。接下来，我们还可以根据评审结果将下一个成熟度等级的KPA进行划分，看看哪些更重要。评审中，大家达成共识认为对组织影响最大的问题所对应的KPA应该获得较高的权重。
6.4. 对改进方案进行排序
进行了以上分析之后，按照分值对各个改进方案进行排序，总分的计算方法如下：
总分=(权重1)(对商业目标的影响)+(权重2)(风险)+ (权重3)(在CMMI中的定位)
公式中的得分是按上面介绍的步骤进行处理得出的，权重主要是根据策划小组成员的共识确定的，有些公司认为三方面的因素同样重要因此赋予相同权重，也有些公司认为对商业目标的影响的重要性是在CMMI中定位的三倍，而风险因素是在CMMI中定位的两倍。这样，基本建立了各个改进项目的优先级，分数最高的优先级最高。
6.5. 估计实施的进度表
排序完成后，我们就要考虑各个改进点的依赖关系，根据优先级顺序和依赖关系进行总体战略策划，并制定进度表。
6.6. 获得管理层的承诺
完成正式的计划、提交管理层获得认同和承诺。高层管理人员的参与确定关键成功因素是非常必要的，因为他们要负责批准战略计划、授权启动改进项目并且不断重申对于过程改进的承诺。
7. 参考文献
《软件过程改进》 中科永联高级技术培训中心
《PMPBOK2004》 (美)项目管理协会
《RUP2003》 IBM
960
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
