第4章 A 软件项目质量管理改进方案
4.1 A 软件项目质量管理改进基本方案
软件开发项目在采用 CMM 时，需要按照企业自身的特点和需要进行挑选或修改关键过程域，把 CMM 作为一个参考模型，而不能完全照搬照抄其标准。本章针对软件项目开发周期各阶段的质量控制进行分析研究，对 CMM 软件成熟度模型关键过程域进行了针对性的挑选和修改，针对 H 公司存在的问题，提出以下管理改进的方案。
4.1.1 A 软件项目管理改进方案的提出
通过对瀑布模型的分析，我们将 A 软件项目开发活动分为四个主要工作阶段，分别为立项阶段、设计阶段、实现阶段及收尾阶段，每一个阶段又包含了不同的多个子过程。如下图 4-1 所示则为本文提出的改进软件项目生命周期的模型。
结合 A 软件项目的实际情况，本文选取 CMM2 级（可重复级）中的需求管理、软件项目计划、软件质量保证、软件配置管理以及 CMM3 级（已定义级）中的培训程序和组间协调过程域进行分析。基于 A 软件项目质量管理过程中的实际情况和需求，加入了软件项目风险管理和软件项目技术方案两个非 CMM 关键过程域来进行研究。具体如下表 4-1 所示：
4.1.2 A 软件项目质量管理组织结构优化
企业组织架构好比是企业骨髓，组织架构是否适应企业经营管理的要求，对企业的生存和发展有着非常大的影响。过程管理制度化也需要以合理的组织架构为基础，只有存在合理有效的组织架构，企业才能明确定义每个岗位的职责与义务，形成公司自己的规范和制度，从而有效地组织和控制过程实施。同时，组织文化也是规范和约束企业健康发展的无形动力，以公司自身的产品特点和业务流程为基础，改善和建立适应于不断过程改进的、以提高质量管理水平为目的的组织架构，并建立以质量为生命的企业文化，将奖惩机制与员工的工作绩效挂钩，能促使员工重视软件产品的质量，从而确保软件的质量管理制度能够顺利地执行。因此，要改进 A 软件项目的开发过程，从企业组织架构的合理设计切入最为合适。
H 公司的规模大，员工人数多，但本地开发人员较少，组织架构相对比较简单。通常由总裁和管理层的成员共同决策，协调各个项目组的运作，同时负责人力资源部、财务部、市场营销部、商务部、软件开发中心、技术支持部、质量测试部等部门的管理。普通员工通常以项目划分，为了充分利用资源，同一成员可能参与到多个项目中，做到资源的合理充分运用。
CMM 模型在组织架构方面体现的是三权分立思想，而强矩阵式的组织架构是最适合实施CMM 模型的组织架构，做到下达或回报工作时，尽可能减少管理层次，因为管理层次越多，信息失真率就越高，而且效率也很低。同时，在设立组织架构时，要做到尽量避免交叉管理和减少管理层次。为此，我梳理并建立了如图 4-2 所示的 H 公司与软件开发过程有关的主要组织架构，第一级为总裁（CEO）；第二级各职能部门的部门总监（CXO），包括项目管理部、人力资源部、财务部、市场营销部、软件开发中心、技术支持部以及独立于各部门的工程过程组（EPG）、软件质量保证组（QA）和软件配置管理组（CM）。在该组织架构中，EPG、QA、PM 三足鼎立，形成一个相互监督、客观评价的过程监控和改进体系。在项目执行的各个阶段，需求分析师、需求变更委员会、估算评审组和培训组都会起到各自的作用。
4.2 需求管理
需求管理对于化工行业的软件项目特别重要。如需求未满足，可能导致化工厂在调试或正常生产时发生安全事故，影响公众安全。
4.2.1 需求开发
需求开发包括需求调研、需求分析和需求定义。
需求调研的目的是为了获取需求。需求获取包括以下方法和技能：
（1） 项目范围确定
需求开发前期，应该获取用户的业务需求，定义好项目的范围，使得所有的涉众对项目有一个共同的理解。
（2） 用户确定
确定用户群和分类，对用户组进行详细描述，包括使用产品频率，所使用的功能、优先级别、熟练程度等。对每一个用户组确定用户代表；对于大型项目，需要先确定中心客户组，中心客户组的需求具有高级别的优先级，需要先实现的核心功能。
（3） 获取方法
召开需求讨论会议，观察用户的工作过程，采用问答式对话，采用诱发式需求诱导等。
4.2.2 需求分析
需求分析在用户需求描述和软件设计之间建立桥梁，也就是描述客户有什么需求，一为软件的设计和开发奠定基础。对软件完成后可以被确认的需求进行细致的定义，将需求分析作为软件项目验收的内容之一。需求分析的流程如下图 4-3 所示：
4.2.3 需求跟踪
需求跟踪分为需求确认和需求变更控制。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出的书面承诺，使需求文档具有商业合同效果。
需求变更控制是指依据变更申请、审批、更改、重新确认的流程处理需求的变更，防止需求变更失去控制而导致项目的混乱。在 CMM 需求管理过程域的活动中明确指出，当需求需要更改时，要评估它对现有外部和内部工作的影响，合适时协商更改。对更改造成的对软件计划、工作产品必要更改，要加以识别、评价、风险评估、文档化、规划、传达和跟踪。这部分的工作由变更控制委员会（CCB）来控制。
4.2.4 需求评审
在需求分析师编写完需求规格说明书之后，需要进行同行评审，对于 A 项目，其同行评审结果如表 4-2 所示：
正式评审结束前需要给出评审结果，如果评审组认为需求分析不通过，需要作重大修改和完善后进行重新评审，则需要 QA 人员把问题记录到问题跟踪表以便跟踪，项目经理根据具体情况制定重新评审计划，同时更新项目计划。
4.3 软件项目计划
软件项目计划就是在项目定义和项目启动之后，对 A 软件开发项目进行具体的规划，过程域的步骤包括估计软件工作产品规模及所需的资源，制定时间表，鉴别和评估软件风险和协商约定。
项目定义阶段：进行 A 软件项目问题的定义、分析项目的可行性、进行项目的研究与可行性的论证工作，最终以可行性分析报告和问题定义为基础确定是否立项。
项目启动阶段：在项目可行性研究确定立项之后，即进入到了项目启动阶段。A 软件项目启动阶段包括的工作主要有：制定项目计划、项目的招标投标、确定与控制系统的开发环境和运行环境、确定项目经理、组建项目团队、签订各种项目有关的合同等一系列软件项目开发前的准备工作和软件开发的基础性工作。
（1） 项目估算
项目估算是项目计划的核心，目的是为项目建立合理的预算和进度表，确定合适水平的成员，为项目承诺提供文档化的参照，并识别和确定软件生命周期。该 CMM 过程域的活动也要求软件工程组参与项目估算组做出建议。
软件项目规模的估算方法有：类比法、Delphi 法、代码行估算法等。我们选择 Delphi估算法。Delphi 估算法可以对软件规模、工作量、费用等进行估计。
其估算步骤如下所示：
第一步：项目经理选择 3 到 6 名有经验的工程师组成软件工程组评审，每位工程师应对该项目有所了解；第二步：项目经理发给每位工程师一份评估表格，并进行估计；第三步：每位工程师对该项目提出三个规模的估计值，即：
Mi-该项目可能的最小规模；Ii-该项目最可能的规模；Ni-该项目可能的最大规模。
第四步：项目经理召开会议，讨论各工程师估计值不同之处，并依照讨论结果对估计值重新估计。
第五步：每位工程师再次进行项目估算。
第三步到第五步可重复多次，获得一个多数工程师达成共识的项目规模估计值，以此作为项目的最终估算结果。
根据项目的估算规模、成本、工时等信息，推算出该项目的成本估计值。
下面使用 Delphi 估算方法对该项目进行估算，估算情况如表 4-3 所示（限于篇幅，只对项目计划阶段和分析阶段的估算列表作阐述）：
（2） 项目计划的制定
当项目规模、工作量、成本等参数基本确定后，计算项目的总进度，同时根据项目的人力资源分配情况，制定出各主要里程碑的进度计划。进度计划制定步骤为：活动定义、活动排序、估算资源、估算工作量和制定进度表。
在制定进度表的过程中，项目经理需要根据实际情况，与项目组成员协商确定是否要制定额外的软件配置管理计划、软件质量保证计划、培训计划、测试计划和项目跟踪计划等附属计划。最终的进度表需要 QA 组的评审。
对于计划的风险管理，CMM 过程域的活动也指出，项目计划要求获得项目成员的承诺，必要时需要通过公司的正式评审。评审过程中根据人员的参与情况作出适当的调整；如果发现项目范围有遗漏之处，那么都会要求再次确定项目范围，重新调整计划。只有获得项目组成员承诺和 QA 组评审之后才能确定项目计划是可行的。A 软件项目的部分项目计划如表 4-4 所示：
（3） 制定质量目标
质量目标如表 4-5 所示：在软件立项中应该根据公司的质量方针进行软件质量计划的制定，这几涉及到从项目立项开始到项目结束全过程各个阶段的质量保证活动，制定出细致的、全面的、可行的质量保证计划，使每软件项目开发的每一个阶段、每一个任务都有相应的质量保证措施。因而，在项目立项阶段质量保证小组的工作必须保证做到位。否则会对整个项目开发过程产生影响。如上表所示，在需求评审阶段中出现缺陷的密度参考标准值上线为 0.7、下限为 0.2,但是，A 软件项目在具体开发实践中，其评审缺陷密度上限为 0.8,下限为 0.4,其优先解决次序为高级。
