3.3 人员配置
A 项目的组织架构确定后，就需要对项目各岗位的具体职责进行详细的界定和划分，保证每项任务落实到每个人，做到精细化管理，职责界定和划分如下所示：
3.3.1 公司管理高层
高层管理者的支持是软件过程改进得以顺利实施的基本前提。高层管理者是实施 CMM的原动力，其对 CMM 的认识、决心以及推动都是至关重要的。如果高层管理者的重视只停留在口头上，没有做到身体力行，那将会许多实际问题难以解决。因为过程管理不仅涉及某些工作岗位、某些项目和部门，而且涉及资源和组织架构的调整，涉及到公司的方针、过程、规程的制定，任何一个项目经理或部门总监的权力都无法达到整个组织的所有范围。
因此，高层管理者对过程管理的推动力度是组织内部任何人都无法代替的。高层管理者需要明确地认识到软件质量的重要性，推广和监督质量管理活动，参与制定质量保证规范，将质量活动安排到位，在公司内部树立起全面质量管理（TQM）的意识，并形成企业文化。
3.3.2 质量保证（QA）组
QA 部门的主要职责是计划和实施项目的质量保证活动，保证软件过程和产品的开发步骤及标准得到遵守和执行。质量保证组独立于项目组，并有直接向高层经理汇报的权力。
其具体职责如下：
（1） 制定并维护质量保证计划
QA 人员根据项目计划制定质量保证计划，并在项目计划更改时更新质量保证计划。
（2） 过程评审
QA 人员对项目已定义过程进行检查，若发现不符合项，则与项目经理或相关开发人员讨论发现的问题，并记录到问题跟踪表中进行跟踪，直到问题解决为止。
（3） 产品评审
QA 人员对软件项目或产品进行检查，若发现不符合项，则与项目经理或相关开发人员讨论发现的问题，并记录到问题跟踪表中进行跟踪，直到问题解决为止。
（4） 参与同行评审
QA 人员需要参与同行评审，并对同行评审过程和评审的项目或产品进行检查。
（5） 汇报评审情况
在项目或产品评审结束后，QA 人员需要对评审结果进行复查、整理，形成评审报告，然后给项目组汇报项目或产品评审情况，包括符合和不符合项的情况汇总等信息。如果存在与项目组达不成一致意见，或者项目组对发现的问题没有在规定的时间内解决的，QA 人员可以直接向高层管理者汇报情况。QA 人员可以针对发现的问题，对其进行原因分析，然后直接汇报给高层领导。
由此可见，QA 工作在软件过程管理过程中起到了举足轻重的作用，过程管理的成败与否与 QA 的工作正常与否有着直接的关系。因此，QA 人员需要有较高的专业素质，包括熟悉软件工程、熟悉软件质量体系和其它专业知识（如质量控制技术、统计学知识等），以及具有良好的沟通和协调能力。
3.3.3 工程过程组（EPG）
工程过程组专门负责一个组织中软件过程改进方面的组织协调工作，推进组织所采用的软件过程的定义、维护和改进工作；支持但不直接负责软件开发和维护工作。这个小组的成员可以由全职和兼职人员组成。具体职责如下所示：
（1） 定义和维护标准过程工程过程组根据公司的业务流程定义出公司的标准过程，并定期地对标准过程进行维护。
（2） 识别公司存在的不足
定期对公司的过程和项目进行评审，找出存在的问题。
（3） 制定过程改进计划
制定年度过程改进计划，该计划的内容需要包括定期发现公司的不足之处、QA 人员检查发现的问题、项目实施过程中发现的问题、项目的经验总结等。
（4） 建立并维护公司的财富库和度量库。
（5） 向高层领导汇报过程改进情况。
3.3.4 项目经理（PM）
项目经理负责项目的策划，参与需求调研和需求分析，组织人员进行系统的架构设计、概要设计和详细设计，在项目的实施过程中对项目进行监督和控制，以保证项目按计划开展。对项目而言，项目经理的主要职责是对整个项目的总体业务负责，指导、控制、管理整个项目的开发过程；对客户而言，是公司的接口人，负责与客户需求变更的确定、项目验收、合同的签订等工作。同时，项目经理需要定期向高层管理者汇报项目状态和进展情况。因此，项目经理应该具备如下素质：
（1） 基本项目管理知识和技术能力，熟悉项目管理 9 大知识领域；（2） 组织协调能力；（3） 领导能力；（4） 指挥能力；（5） 人际交往能力；（6） 激励能力。
3.3.5 各相关组人员配置
3.3.5.1 配置管理（CM）组
配置管理组主要负责策划、协调和实施公司、部门和项目的配置管理活动，对公司的资料、数据等各种文档进行配置管理。主要职责有：
（1） 制定并维护配置管理计划配置管理组人员根据项目计划制定相应的配置管理计划，并在项目计划变更时更新配置管理计划。
（2） 定期汇报配置管理状态。
（3） 进行软件的版本控制在软件开发过程中，需要对程序代码进行版本控制。对每次完成的回归测试进行一次版本升级，需要配置管理员（CMO）对相应版本代码进行复制或同步处理；在该版本发布时，需要把该版本的最新代码同步到主干的代码目录中，形成发布版本。这部分工作相当重要。否则，由于代码不同步引起的程序不一致，会导致功能缺失或错漏的情况，直接影响系统的正常运行。
（4） 进行配置审计
对准备检入配置库的文档进行物理检查，逐一检查文档是否存在，文档的命名是否规范以及路径是否一致。这样，就保证了配置项的完整性和一致性。
3.3.5.2 评审组
评审组的成员一般是临时性小组，通常由来自各部门的业务专家或技术资深的人员组成。评审组人员负责对各个阶段的评审进行业务或技术把关，每个阶段通常要进行同行的预评审和正式的会议评审。比如，开发计划、需求分析、概要设计、详细设计、测试用例等都要进行评审。可见，评审组对软件质量的保证起到了非常重要的把关作用。
3.3.5.3 系统分析组
系统分析组人员通常被称为系统分析师，其主要职责有：
（1） 参与项目的需求调研，进行需求分析，编写技术方案；（2） 负责项目的概要设计，包括功能子系统划分、模型设计、数据库结构设计等；（3） 核心、关键模块的算法设计，指导详细设计和开发；（4） 关键、核心的算法或功能编码实现；（5） 修正设计、编码发现的错误直至系统能正确、正常运行；（6） 参与项目的质量把关及验收工作。
3.3.5.4 软件开发组
软件开发组成员是指软件工程师，通常根据计算机开发语言对软件工程师进行划分。如，DCS 软件工程师、ifix 软件工程师、PLC 软件工程师等。其主要职责是根据项目经理分配的工作任务，进行程序代码的编写、单元测试、程序调优等工作。
3.3.5.5 软件测试组
测试并不仅仅是为了找出错误，通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进。软件测试组人员的主要职责有：
（1） 根据项目文档制定测试计划与测试方案；（2） 准备测试数据，搭建测试环境，进行项目测试工作；（3） 编写测试用例，及时总结和汇报测试中发现的问题，提交测试报告。
软件测试人员通过集成测试、系统测试、回归测试、压力测试、性能测试等测试方法发现程序问题，保证软件系统在交付给客户使用前出错率降到最低限度。
3.4 A 项目软件开发存在的问题
H 公司的软件项目开发过程按照 CMM 软件成熟度模型关键过程域的测量、评估标准来看，属于 2 级可重复级往 3 级已定义级的过渡阶段。根据 CMM 关键过程域的测量、分析和验证等量化指标，H 公司的软件项目在开发过程中，体现了有纪律组织过程，基本项目管理过程进行成本、进度和功能跟踪，过程域基本涵盖了 CMM 模型 2 级关键过程域中的需求管理、软件项目计划、软件项目跟踪与监控、软件质量保证和软件配置管理。同时，开发过程在管理和工程方面趋于标准化，过程域涉及到组织过程定义、组件协调、同行评审。然而，开发过程中存在的问题也不少。
3.4.1 用户需求和变更管理不完善
在任何一个软件开发过程中，都要充分地强调需求管理的重要性。因此，在项目初期，相对花比较多的时间做需求的搜集和跟踪，完善业务人员和技术人员的沟通机制是很重要的。这会减少大量的由于曲解需求导致软件不符合用户需求从而返工造成的人力和物力的浪费。但是，A 软件项目开发管理过程中，却还存在着用户需求和变更管理不完善，导致开发出来的软件与用户的需求不匹配的情况存在。这主要表现在三个方面的问题：
（1） 从项目的需求搜集开始，业务专家搜集和提出基于整个业务的需求体系。但是，在从初始的需求转化为软件特性和功能的过程中，由于业务专家和技术人员的沟通不充分或者需求描述不完善，导致技术人员对需求的理解产生曲解，从而影响该软件完成后，存在部分不符合用户提出的真实需求。
（2） 从初始的业务需求转化为软件特性的过程中，缺乏有效的跟踪和管理，导致软件功能特性与用户需求脱节。
（3） 在项目过程中，用户提出改进的需求或者增加软件功能和特性。项目组在了解需求后，对软件架构进行调整或者重构。但是，如此频繁的重复下来，需求来源不清楚，软件规格书未及时反应需求变化，或者接受需求但未调整项目的整体进度，导致一些混乱情况的发生。
CMM 等级 2 中的需求管理，要求在顾客和将处理顾客需求的软件项目之间通过约定、活动和定量验证，来建立对顾客诉求的共同理解。每当改变分配给软件系统的需求是，都要调整受到影响的软件计划，工作产品和活动，使其与更新后的需求保持一致。而 H 公司在常规软件开发过程中，由于上述情况，没有满足需求管理的要求。同时，CMM 等级 5 中的技术变更管理可以识别出新技术（即工具、方法和过程），并以有序的方式将其引进到组织中。当 H 公司的软件开始过程认证等级相对提高时，技术变更管理这个过程域对解决此类问题更有效果。
3.4.2 软件配置管理问题
软件配置管理占据了越来越重要的角色，对文档、图形、代码和各种项目数据进行分类管理，并对不同的人拥有的权限进行控制，方便技术人员对其负责的配置项进行创建，提交和修改，提高项目整体的运作效率。但是，在软件配置管理中也存在着一些问题：
首先，没有制定好文档、图形、代码应放的位置，配置项命名比较随意，无权限控制，造成各配置项存放混乱，寻找不易。在大型项目中，由于各种文档，代码等非常多，如果不能进行正确的配置管理，很有可能被弄得一团糟。因此，在项目启动后，经过技术人员之间的讨论，在配置项的命名规定，目录结构，存放位置等达成共识，因为这些在具体使用上还和开发工具，开发语言等是密切相关的，在讨论的时候也应充分考虑这些因素，给技术人员在使用它们的时候提供最大的便利。当然，为了安全起见，大型项目中，权限的控制也是很重要的。另外，在一些情况下，如果没有权限控制，项目成员可以随意修改其它文件，这样可能会导致一些混乱情况的发生。
其次，培训和支持不充分，对配置管理工具的用法不了解。目前配置管理工具很多，比如大家常用的 Microsoft Project、AutoCAD、Visio、Access 等，可能相对比较熟悉一些。但是诸如 iFix、ActivePerl 和 DOORs 等工具，由于软件功能非常复杂，并且对国内用户来说易用性比较差，虽然功能强大，但是没有真正派上用场。
CMM 等级 2 中的软件配置管理要求建立和维护在项目的整个软件生存周期中软件项目产品的完整性。可以通过建立一个软件基线库，当软件基线形成时就将它们纳入该库，并通过更改控制和配置审计，来系统地控制基线的更改和相关产品的发布。这点在 H 公司在常规软件开发过程中没有体现。另外，CMM 等级 3 中的培训程序，也可以避免因对配置管理工具的用法不了解，导致的软件项目质量问题。
3.4.3 缺陷管理问题
一般缺陷的生命周期必然要经历“提交、打开、解决、关闭”这四个阶段。但问题是，H 公司对诸如 Clear Quest 的缺陷管理工具，进行了一些定制和二次开发，制定了一套严格的流程，缺陷的生命周期变得更加复杂化了。但是，在执行的时候，开发人员往往仅在缺陷提交后，匆匆修正了缺陷，然后，置为解决状态，等待测试人员来关闭它。因此，这些情况下，缺陷状态的很多阶段都显得有些多余。但是，有人认为，在缺陷生命周期阶段多的情况下，可以让关注该缺陷的人员，更准确地了解该缺陷目前的状态。怎样化解矛盾呢？
事实上，给缺陷定义过多的生命周期阶段是不必要的。开发人员不愿意在解决缺陷的过程中，不断地更新该缺陷的状态，另外，有些缺陷实际上很快就能解决的。过多的步骤反而降低效率，浪费时间。因此，从统计和了解缺陷数量和状态，这样的做法是好的。但是，从现实的角度来看，在实施的过程中缺乏可操作性。
此类问题在 CMM 模型不同等级的关键过程域中都有体现。在等级 2 中的软件项目跟踪和监督就要求建立对项目实际进展的可视性，以便管理者在软件项目明显偏离软件计划是采取有效措施。在软件质量保证中则通过评审和审计软件产品和活动，来验证他们是否符合适用的规程和标准。在等级 5 优化级中，缺陷预防过程域更可以鉴别缺陷的原因并防止它们再出现。
3.4.4 文档管理问题
（1） 文档问题
国内进行软件开发从最初的完全不重视文档，到后来吸取无数的经验教训后，对文档的重视又被提高到前所未有的地步。但是，不少公司对应该写多少文档，怎么写文档不能把握好。因为，技术人员往往对文档方面的任务是抵触的，认为不如多抽点时间专注在技术方面，写文档纯粹是浪费时间。H 公司在文档管理方面要求一向严格，技术人员仍有抵触情绪，认为过多的文档是不必要的。
但是，文档却是必不可少的。应该怎样处理好这种矛盾呢？ 事实上，这种矛盾天生就是难以化解的。因为，技术人员对技术和相关情况最了解，其它人很难撰写这些文档。项目经理所需要做的是，通过斟密的项目进度安排，给技术人员留出一些时间来书写文档（在工作时间而不是在加班时间里完成，否则难免会有怨言的），并在规定的进度下进行评审。
（2） 周报和月报问题
H 公司要求开发人员填写周报和月报，以便在项目周会，月总结上了解每个人任务的进展情况和对人员进行考核。但是，技术人员总是对此类工作不胜其烦，往往敷衍了事，填几个比较大的任务（如开发 XX 系统等），而且一连几周都是如此，这样对了解项目进展和对人员考核的参考作用就失去了意义。虽然，技术人员比较反感写这类东西，但是，周报月报还是必须要写的。应该怎样化解此类矛盾呢？实际上，这类任务主要是人的因素在发挥作用。要想达到有效性的目的，对项目成员进行一定程度的指导和培训是必要的。文档的有效管理涉及到 CMM 等级 2 中的软件质量保证，并且等级 3 中的培训程序也可以对解决此类问题起到积极的作用。
3.4.5 工作包一致性问题
在软件开发过程中，不断有新的工作包产生，而且有些工作包随着一些变更的发生，就需要进行更新，但工作包数量太多，一则维护更新不容易，另外有些工作包只是项目结束后参考性的资源，立即更新也不必要，求大求全则会一定程度上占用项目资源，耽误进度。
因此，一个建设性的建议就是，对必要的工作包，如需求规格书，产品定义书，概要设计书，详细设计书等，是一定要根据项目和评审情况立即进行修订和更新的。但是，对另外一些衍生的工作包，如用户指南等，虽然在开发流程中，可能是在每个阶段都必要写的，但是却可以在评审进行前，集中进行更新一些，避免频繁修订造成的资源占用和进度延迟。
此类问题涉及多个 CMM 关键过程域，其中尤其突出的是等级 2 中的软件项目计划、软件项目跟踪与监控和等级 3 中的组间协调。组间协调的目的是建立软件工程组和其它工程组一起积极参与的方式，使得项目更能有效地沟通协作来满足顾客的需求。
