【系统架构设计师】九、软件工程(项目管理|进度管理|软件配置管理|软件质量管理|软件风险管理 )

十四、项目管理

14.1 软件进度管理

14.1.1 工作分解结构

14.1.2 Gantt 图和 PERT 图

14.1.3 关键路径法

14.1.4 浮动时间

14.2 软件配置管理

14.3 软件质量管理

14.4 软件风险管理

十四、项目管理

软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。为使软件项目开发获得成功，关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件/软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等进行预先计划和执行。这种管理在技术工作开始之前就应开始，在软件从概念到实，的过程中继续进行，当软件工程过程最后结束时才终止。

14.1 软件进度管理

进度管理就是采用科学的方法，确定进度目标，编制进度计划和资源供应计划，进行进度控制，在与质量、成本目标协调的基础上，实现工期目标。

        具体来说，包括以下 6 个过程：
        (1)活动定义：确定完成项目各项可交付成果而需要开展的具体活动。
        (2)活动排序：识别和记录各项活动之间的先后关系和逻辑关系。
        (3)活动资源估算：估算完成各项活动所需要的资源类型和效益。
        (4)活动历时估算：估算完成各项活动所需要的具体时间。
        (5)进度计划编制：分析活动顺序、活动持续时间、资源要求和进度制约因素制订项目进度计划。
        (6)进度控制：根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。

14.1.1 工作分解结构

软件项目往往是比较大而复杂的，往往需要进行层层分解，将大的任务分解成一个个的单
一小任务进行处理。工作分解结构 (Work Breakdown Structure,WBS)如图所示，就是把一
个项目，按一定的原则分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人
的日常活动中，直到分解不下去为止。即：项目→任务→工作→日常活动。

14.1.2 Gantt 图和 PERT 图

进度安排的常用图形描述方法有Gantt 图(甘特图)和项目计划评审技术(Program Evaluation& Review Technique，PERT)图。

14.1.3 关键路径法

关键路径：是项目的最短工期，但却是从开始到结束时间最长的路径。进度网络图中可能有多条关键路径，因为活动会变化，因此关键路径也在不断变化中关键活动：关键路径上的活动，最早开始时间=最晚开始时间。

通常，每个节点的活动会有如下几个时间：

        (1)最早开始时间(ES)：某项活动能够开始的最早时间。
        (2)最早结束时间(EF)：某项活动能够完成的最早时间。EF=ES+工期
        (3)最迟结束时间(LF)：为了使项目按时完成，某项活动必须完成的最迟时间。
        (4)最迟开始时间(LS)：为了使项目按时完成，某项活动必须开始的最迟时间。LS=LF-工期。

14.1.4 浮动时间

总浮动时间：在不延误项目完工时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量，就是该活动的进度灵活性。正常情况下，关键活动的总浮动时间为零

总浮动时间=最迟开始LS-最早开始ES 或最迟完成LF-最早完成EF 或 关键路径-非关键路径时长。

自由浮动时间：是指在不延误任何紧后活动的最早开始时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量。

自由浮动时间=最后活动最早开始时间的最小值-本活动的最早完成时间。

14.2 软件配置管理

软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。SCM 的目的是使错误降为最小并最有效地提高生产效率。SCM 的核心内容包括版本控制和变更控制。

版本控制（Version Control）是指对软件开发过程中各种文件变更的管理，最主要的功能就是追踪和记录文件的变更、并行开发。软件开发往往是多人协同作业，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。

          变更控制（Change Control）是指对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。项目中引起变更的因素有两个：
                一是来自外部的变更要求，如客户要求修改工作范围和需求等；
                二是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，因为 IT 项目需求变更的概率大，引发的工作量也大(特别是到项目的后期)。

14.3 软件质量管理

质量是软件产品特性的综合，表示软件产品满足明确(基本需求)或隐含(期望需求)要求的能力。质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动。

从管理角度出发，可以将影响软件质量的因素划分为3组，分别反映用户在使用软件产品
时的3种不同倾向和观点。这3组分别是：产品运行、产品修改和产品转移。

质量管理主要包括以下过程：

        (1)质量规划：识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。
        (2)质量保证：一般是每隔一定时间(例如，每个阶段末)进行的，主要通过SQA 审计与评审、SQA 报告、处理不符合问题来保证项目的质量。
        (3)质量控制：实时监控项目的具体结果以判断它们是否符合相关质量标准制订有效方案，以消除产生质量问题的原因。

软件质量认证，国内软件企业主要采用的是 ISO 9001 和 CMM

配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。

14.4 软件风险管理

风险管理就是要对项目风险进行认真的分析和科学的管理，这样，是能够避开不利条件、少受损失、取得预期的结果并实现项目目标的，能够争取避免风险的发生或尽量减小风险发生后的影响。但是，完全避开或消除风险，或者只享受权益而不承担风险是不可能的。

        风险管理计划编制：如何安排与实施项目的风险管理，制定下列各步的计划。
        风险识别：识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险，形成一个风险列表。
        风险定性分析：对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风险类型。
        风险定量分析：进一步了解风险发生的可能性具体由多大，后果具体由多严重。包括灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟。
        风险应对计划编制：对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风险应对计划。包括消极风险(避免策略、转移策略、减轻策略)；积极风险(开拓、分享、强大)
        风险监控：监控风险计划的执行，检测残余风险，识别新的风险，保证风险计划的执行，并评价这些计划对减少风险的有效性。

在信息系统项目中，从宏观上来看，风险可以分为项目风险、技术风险和商业风险。

项目风险是指潜在的预算、进度、个人(包括人员和组织)、资源、用户和需求方面的问题，以及它们对项目的影响。项目复杂性、规模和结构的不确定性也构成项目的(估算)风险因素。项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。

技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术(不成熟)也是风险因素。技术风险威胁到待开发系统的质量和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。

商业风险威胁到待开发系统的生存能力，主要有以下5 种不同的商业风险：

        (1)市场风险。开发的系统虽然很优秀但不是市场真正所想要的。
        (2)策略风险。开发的系统不再符合企业的信息系统战略。
        (3)销售风险。开发了销售部门不清楚如何推销的系统。
        (4)管理风险。由于重点转移或人员变动而失去上级管理部门的支持。
        (5)预算风险。开发过程没有得到预算或人员的保证。