该项目没有遵循正确的立项流程，没有由项目发起人正式发布项目章程

依题意，项目经理小郭目前所面对的困境，其关键原因之一是该项目没有遵循正确的立项流程，没有由项目发起人发布项目章程。叶总为了赶该项目的进度，只是简单地“将小郭引见给客户方王总”，跳过项目启动环节，直接指令小郭进入项目实施阶段，从而导致项目刚起步就麻烦不断。正所谓“好的开始是成功的一半”。做项目启动是为了形成一个良好的沟通体系，让所有与项目相关的人都理解项目的重要性，同时形成一个由双方领导人、项目负责人和项目组成员构成的三级沟通体系，确保项目管理的畅通。

(1)制定项目章程    (2)制定初步的项目范围说明书

项目启动过程组是由正式批准开始一个新项目(或一个新的项目阶段)所必需的一些过程组成的。在该项目期间，项目干系人的参与通常有助于进一步明确客户的需求。启动过程组的结果是启动了一个项目，同时其输出物也定义了项目的用途，明确了目标，并授权项目经理开始实施这一项目。
   通常，启动过程组包括以下内容：
   (1)制订项目章程。这一过程批准项目的开始或项目阶段的开始。它是论证客户的业务要求，以及预期满足这些要求的新产品或服务时所必需的过程。制订项目章程可以将项目与组织的日常工作连接起来并使项目获得批准。制订项目章程和批准项目是由项目外的更高一级组织(或大型项目管理，或项目组合管理)部门负责的。
   (2)制订初步的项目范围说明书。这一过程用于依据项目章程和启动过程的其他依据来确定初步的项目定义。该过程确定了项目需求、项目的边界、接收的方法和高层次范围控制的方式，
   并将其记入初步的项目范围说明书。

①没有制定单独的质量管理计划，也没有安排质量管理人员(或没有分配质量管理职责)
   ②没有实施质量保证工作，只进行了质量控制工作(或没有对项目过程进行质量检查工作)
   ③相关干系人或客户没有参加需求评审会，可能导致最终对需求的理解不能达成一致
   ④在项目重大里程碑处没有相关干系人对阶段成果进行评审，无法确保结果和预期目标一致
   ⑤评审会召开时间过长，也没有起到质量控制的作用
   ⑥技术评审会没有关注于发现问题，没有达到预期的会议目的
   ⑦项目经理个人决定进入项目下一重要阶段，而不是经过评审后决定
   ⑧设计文件未经过正式评审，可能导致设计文件中有较多的错误

通读整个案例，该项目在质量管理过程中存在的主要问题有(但不限于)：
   (1)由题干关键信息“需求分析完成后，项目组编写了《需求分析报告》，项目经理小郭召集部分骨干人员召开评审会，对需求文件进行了评审”可知，该需求评审会没有邀请客户等重要项目干系人参加，最终可能导致相关干系人对需求的理解不能达成一致。根据软件工程知识，《需求分析报告》是系统分析阶段的重要标志性文档，在这个项目重大里程碑处需由相关干系人(如客户等)对此阶段性成果进行评审，以确保结果和客户的预期目标(期望)一致。
   (2)由题干关键信息“为了尽快进入下一阶段工作，评审会从早上8点一直开到晚上21点，终于把全部的文件都审完了”可知，该需求评审会控制不好。需求评审属于技术评审，评审会召开时间过长，容易因与会人员过度疲劳(或心理压力)而起不到质量保证、质量控制的作用(或评审会连续时间过长会导致效率低下)。
   (3)由题干关键信息“评审组找到了几处小问题，并当场进行了修改，项目经理小郭宣布可以进入设计阶段了”说明：①技术评审会的会议目的不明确而没有达到预期效果，因为技术评审会是为了发现问题的，而不是以“修改问题”为目的；②能否进入项目下一个重要阶段(即从系统分析阶段进入系统设计阶段)应该进行评审后才能决定，而不是由项目经理个人来决定的。
   (4)结合软件工程知识可知，《设计说明书》是系统设计阶段的标志性文档，在这个项目重大里程碑处需由相关干系人(如客户、项目团队等)对此阶段性成果进行评审。例如，以需求规格说明书为输入对需求进行验证，是为了更好地保证系统设计工作满足用户的真实需求，以使目标管理系统能够被正确地开发出来。由题干关键信息“设计人员根据需求文件编写了《设计说明书》，并提交给小郭，小郭对设计文件仔细审阅后，便安排程序员开始编程”可知，该设计文件没有经过正式评审与确认，最终可能导致设计文件中存在较多不能真正满足用户需求的设计(或存在较多的错误)。
   (5)纵观整个案例，项目经理小郭仅制定了项目的整体计划，而没有制定单独的质量管理计划，也没有安排质量管理人员(或没有分配质量管理职责)；仅应用了评审、检查等工具、方法和技术进行质量控制工作，没有应用质量审计、过程分析等工具/方法和技术实施质量保证工作(或没有对项目过程进行质量检查工作)。

(1)质量保证计划    (2)项目组或项目团队
   (3)质量审计或质量保证    (4)统计分析

项目质量管理是为了保证项目最终能够达到预期的质量目标而进行的一系列的管理过程。通常包括制定质量方针和质量目标，以及质量策划、质量控制、质量保证和质量改进等。软件项目的质量管理工作应重点完成的工作包括(但不限于)：①要制定出切实可行、科学的质量保证计划(如合理制定质量检查的周期，根据当前项目的特点选用合适的工具、方法和技术等)；②应安排独立于项目组、拥有较丰富质量保证经验和行业经验的质量保证(QA)人员负责QA工作；③对软件开发的过程实施质量审计(或质量保证)；④加强技术评审工作，注重对需求、设计等开发过程文档的技术评审工作；⑤注重测试阶段的工作，并安排相对独立的测试人员负责完成；⑥对发现的缺陷进行统计分析，确保最终的软件产品质量；⑦提出科学、合理的质量整改措施(如建议的纠正措施、变更请求等)；⑧督促及监控各子阶段项目文档的及时完成，定期给项目干系人分发质量报告等文档；⑨为项目组成员提供质量管理要求方面的培训或指导等。

Ⅰ——C    Ⅱ——A
   Ⅲ——D    Ⅳ——B

通常，配置管理系统的配置库可以分为动态库(或开发库)、受控库(或主库)、静态库(或产品库)和备份库4种类型，详见表7-9。

表7-9 配置库的类型 类型 说明 动态库 也称为开发库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态库通常包 括新模块、文档、数据元素或进行修改的已有元素。动态库是软件工程师的工作区，由开发者控 制。动态库中的配置项处于版本控制之下 受控库 也称为主库或系统库，是用于管理当前基线和控制对基线的变更。受控库包括配置单元和被提升 并集成到配置项中的组件。软件工程师和其他人员可以自由地复制受控库中的单元或组件，但必 须有适当的权限授权变更。受控库中的单元或组件是用于创建集成、系统和验收测试或对用户发 布的构件。主库中的配置项被置于完：全的配置管理之下 静态库 也称为软件仓库或软件产品库，用于存档各种广泛使用的已发布的基线。静态库用于控制、保存 和检索主媒介，被置于完全的配置管理之下 备份库 包括制作软件和相关构架、数据和文档的不同版本的复制品。在各点的及时备份，可以每天、每 周或每月执行备份

   结合表7-9可知，图7-10中各类配置库及其主要功能的对应关系如下：Ⅰ——C，Ⅱ——A，Ⅲ——D，Ⅳ——B。

E、G、B、C、F、A、D

通常，识别配置项的主要步骤是：①识别配置项；②为每个配置项指定唯一的标识号；③确定每个配置项的重要特征：④确定配置项进入配置管理的时间；⑤确定每个配置项的拥有者的责任：⑥填写．《配置项管理表》⑦审批《配置项管理表》等。

(2)变更评估    (3)变更验证与确认
   (4)变更发布    (5)基线

在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的在于：防止配置项被随意修改而导致混乱。通常，配置管理遵循的变更控制流程是：①变更申请；②变更评估；③变更实施；④变更验证与确认；⑤变更的发布。
   为了在不严重阻碍合理变更的情况下来控制变更，软件配置管理引入了“基线”这一概念。它是指由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改(例如，跟踪和控制变更)。