【新版】系统架构设计师 - 项目管理
个人总结，仅供参考，欢迎加好友一起讨论
文章目录
- 架构 - 项目管理
- 考点摘要
- 进度管理
-
- 工作分解结构（WBS）
- 关键路径法及几个概念
- 箭线图法（双代号网络图，ADM）
- 前导图法（单代号网络图，PDM）
- 总时差与自由时差
- 甘特图（Gantt）
- 软件质量管理
-
- 质量保证与质量控制
- 软件配置管理SCM
-
- 配置项与配置库
- 版本控制
- 变更控制
- 软件工具
- 风险管理
- 软件能力成熟度模型
架构 - 项目管理
考点摘要
- 进度管理（★★★）
- 软件质量管理（★★）
- 软件配置管理（★★）
- 风险管理（★）
第二版架构新教材里对应第5.7节，但是描述很少，也只有进度、配置、质量、风险四个管理，每个管理都只介绍了基本定义，像老早会考到的范围、需求都给删了，也没有配置风险具体内容，更没有进度关键路径计算那些了，架构考试中大概率也涉及不会太多，所以第二版新教材本章节做了大量删减，如果需要可以参考：系分 - 项目管理
进度管理
进度管理，也叫时间管理，就是采用科学的方法，确定进度目标，编制进度计划和资源供应计划，进行进度控制，在与质量、成本目标协调的基础上，实现工期目标。
- 活动定义：确定完成项目各项可交付成果而需要开展的具体活动。
- 活动排序：识别和记录各项活动之间的先后关系和逻辑关系。
- 活动资源估算：估算完成各项活动所需要的资源类型和效益。
- 活动历时估算：估算完成各项活动所需要的具体时间。
- 进度计划编制：分析活动顺序、活动持续时间、资源要求和进度制约因素，制订项目进度计划。
- 进度控制：根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。
工作分解结构（WBS）
WBS分解的基本要求：
- WBS的工作包是可控和可管理的，不能过于复杂。
- 任务分解也不能过细，一般原则WBS的树形结构不超过6层。
- 每个工作包要有一个交付成果。
- 每个任务必须有明确定义的完成标准。
- WBS必须有利于责任分配。
关键路径法及几个概念
关键路径法是在制订进度计划时使用的一种进度网络分析技术。关键路线法沿着项目进度网络路线进行正向与反向分析，从而计算出所有计划活动理论上的最早开始与完成日期、最迟开始与完成日期，不考虑任何资源限制。
-
总时差（松弛时间）：在不延误总工期的前提下，该活动的机动时间。活动的总时差等于该活动最迟完成时间与最早完成时间之差，或该活动最迟开始时间与最早开始时间之差。
-
自由时差：在不影响紧后活动的最早开始时间前提下，该活动的机动时间。
对于有紧后活动的活动，其自由时差等于所有紧后活动最早开始时间减本活动最早完成时间所
得之差的最小值。对于没有紧后活动的活动，也就是以网络计划终点节点为完成节点的活动，其自由时差等于计划工期与本活动最早完成时间之差。
-
对于网络计划中以终点节点为完成节点的活动，其自由时差与总时差相等。此外，由于活动的自由时差是其总时差的构成部分，所以，当活动的总时差为零时，其自由时差必然为零，可不必进行专门计算。
-
关键路径可能会有多条。
箭线图法（双代号网络图，ADM）
- 双代号： 节点上的代号（如1、2、3、4…）和箭线上的代号（如A、B、C、D…）。
前导图法（单代号网络图，PDM）
- 单代号：指的是像A、B、C、D、E、F、G、H这种编号就表示单个代号。
- 一般情况下，单代号的图使用较多。
- 像A、B、C、D、E、F、G、H种编号代表的是某个活动。
- 根据各个活动前后关系，展现活动依赖图。
- 根据上图中的右下图例，一般情况下，活动编号和持续时间（编号上方的数据）会被告知（单位一般是天）。
- 其他的数据需要算出。
上图描述（正向推导ES与EF）：
- 通常最早的开始时间是ES肯定为0，按照上图活动A为第一个活动节点，最早开始时间ES=0。又因为活动A的持续时间为5天，那么活动A的最早完成时间EF = 0 + 5 = 5天。
- 活动B和活动C通过上图描述看出，都是要求活动A结束才可以开始，也就是活动B和活动C的最早开始时间ES等于活动A的最早完成时间EF。所以，活动B和活动C最早开始时间ES都是5天。又因为活动B的持续时间为2天，那么活动B的最早完成时间EF = 5 + 2 = 7天。又因为活动C的持续时间为8天，那么活动B的最早完成时间EF = 5 + 8 = 13天。
- 按照这种推导状态，综合上图描述，整个项目最后一个活动H的最早完成时间为48天，那就代表这项目的最短周期为48天。
- 需要注意的是，类似活动D需要在活动B和C两个一起完成的情况下才开始的，那么需要选择活动B和C中最大的最早完成时间才可以，故活动D最早开始时间ES应该是活动C的最早完成时间13天。假设动D最早开始时间ES选择活动B的最早完成时间7天，此时活动C还没结束，活动D不能开始。所以，正向推导情况下，某个活动的最早开始时间ES取决于其前置活动的最早完成时间的最大值。
- 同理，活动G最早开始时间ES也是取决于活动D和E的最早完成时间的最大值。
- 为什么从第0天开始，从计算机角度上认为其就是第1天，有时候题目也会按照1开始计算，计算方式大同小异。其实从0天开始计算，更符合时间逻辑。
上图描述（反向推导LS与LF）：
- 通常，整个项目最后一个活动点的最早完成时间EF等于最迟完成时间LF。所以，最后一个活动H的最迟完成时间LF是48天。
- 又因为活动H的持续时间为10，那么活动H的最迟开始时间LS = 48 - 10 = 38天。
- 反推活动H的前置活动F和G，所以活动F和G的最迟完成时间LF等于活动H的最迟开始时间38天。
- 活动F的持续时间是10，那么活动F的最迟开始时间LS = 38 - 10 = 28天。同样，活动G的持续时间是15，那么活动G的最迟开始时间LS = 38 - 15 = 23天。
- 需要注意的是，反向推导情况下，类似活动D的最迟完成时间取决于活动F和G，这种情况下，对于活动D需要取其后置任务中最迟开始时间的最小值。故活动D的最迟完成时间LF应该取活动G的最迟开始时间LS是23天。
- 这时候我们可以按照正向思维推导一下验证是否合理。比如活动D的最迟完成时间LF是23天，又因为活动F和G需要在活动D结束之后才能开始，活动D的最迟完成时间LF是23天，活动F和G的最迟开始时间LS分别是28天和23天，这种情况下是没有任何问题。假设如果活动D的最迟完成时间LF是28天，活动F和G的最迟开始时间LS分别是28天和23天，那这种情况影响到了活动G的最迟开始时间LS，所以不合理。
- 所以，反向推导情况下，某个活动的最迟完成时间LF取决于其所有后置活动的最迟开始时间的最小值。
- 同理，活动C的最迟完成时间LF取决于活动D和E的最迟开始时间的最小值，故应该是13天。
最后描述：
- 正向推导和反向推导结束之后，我们就可以计算“总时差”了。
- 活动的每个活动节点的“总时差”是用最迟开始时间LS最早开始时间ES，或者是最迟完成时间LF减最早完成时间EF。总时差是影响总工期也就是关键路径的主要因素，也就是活动的总时差的改变，可能会改变整个项目的关键路径。
- 根据这总计算方式，求得，上述图中：活动A、C、D、G、H的总时差均都是0，所以A→C→D→G→H是整个项目的关键路径。
- 所以项目的关键路径对应项目的最短总工期，并且关键路径是最长路径。此时的最短总工期代表的不是时间最小值，是代表所有的活动节点都必须完成的情况下的用时最短的总工期，此时所有活动工期最大之和是最长路径。
- 所以，这种题目，如果只需要求关键路径，只需要找出所有活动节点工期总和最大的路径即可。
- 双代号网络图的推导方式大同小异，如下所示：
- 双代号网络图中，需要注意的是“虚线“路径。“虚线“路径表示为虚活动，既不占时间，也不占资源，但不能去除。但是虚活动有可能在关键路径中。
- 某种意义上，双代号网络图不是很好理解，只需要注意箭线上的活动节点和活动时间即可。其推导如单代号网络图一样套路。
总时差与自由时差
- 总时差计算，是用最迟开始时间LS减最早开始时间ES，或者是最迟完成时间LF减最早完成时间EF。
- 总时差是影响总工期也就是关键路径的主要因素，也就是活动的总时差的改变，可能会改变整个项目的关键路径。
- 自由时差计算，是和“最早”时间有关系，也就是后面活动的最早开始时间减去前面活动的最早完成时间。
- 例如上图模块A1到单元测试A，其自由时差是单元测试A的最早开始时间减去模块A1的最早完成时间，也就是5 - 3 = 2天。
- 自由时差的意义就是，前置活动延误自由时差天数，并不会影响后置任务的开始。假设模块A1延误2天结束，延误2天并没有超过总时差3天，也没有超过自由时差2天，不影响总工期，也不会影响到单元测试A的开始。假设模块A1延误3天，延误3天并没有超过模块A1的总时差，也不影响总工期，但是它延误了后置任务单元测试A的最早开始时间。因为单元测试A这时需要从第6天开始，持续4天完成后第10天结束，原本它有1天的总时差，可以有1天的“摸鱼时间”，但是由于延误单元测试A的总时差1天“摸鱼时间”被“剥夺”了，这样不行。
- 自由时差判断意义是，前置任务是否延误后置的最早开始时间。
- 总时差的判断意义是，任务的延误时间是否超过总时差，是否影响到后置任务的最迟开始时间。
- 特别情况下，对于没有紧后活动的活动，也就是终点节点，其自由时差等于计划工期与本活动最早完成时间之差。对于有紧后活动的活动（2个或者多个），其自由时差等于所有紧后活动最早开始时间减本活动最早完成时间所得之差的最小值。
甘特图（Gantt）
描述：
- 甘特图中，细线代表计划值，粗细代表实际值。
- 优点：甘特图直观、简单、容易制作，便于理解，能很清晰地标识出每一项任务的起始与结束时间，一般适用比较简单的小型项目，可用于WBS的任何层次、进度控制、资源优化、编制资源和费用计划。
- 缺点：不能系统地表达一个项目所包含的各项工作之间的复杂关系，难以进行定量的计算和分析，以及计划的优化等。
软件质量管理
质量是软件产品特性的综合，表示软件产品满足明确（基本需求）或隐含（期望需求）要求的能力。质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动。
质量保证与质量控制
- 质量保证一般是每隔一定时间（例如，每个阶段末)进行的，主要通过系统的质量审计和过程分析来保证项目的质量。独特工具包括：质量审计和过程分析。
- 质量控制是实时监控项目的具体结果，以判断它们是否符合相关质量标准，制订有效方案,以消除产生质量问题的原因。
- 一定时间内质量控制的结果也是质量保证的质量审计对象。质量保证的成果又可以指导下一阶段的质量工作,包括质量控制和质量改进。
质量保证的主要目标：
- 【事前预防】工作。
- 尽量在刚刚引入缺陷时即将其捕获，而不是让缺陷扩散到下一个阶段。
- 作用于【过程】而【不是最终产品】。
- 贯穿于【所有的活动之中】，而不是只集中于一点。
软件配置管理SCM
配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。
配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
产品配置是指一个产品在其生命周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、计算机程序、部件及数据的集合。
配置项与配置库
配置项：
- 基线配置项（可交付成果）：需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需数据等，它们经评审和检查通过后进入软件配置管理（SCM）
- 非基线配置项：各类计划（如项目管理计划,进度管理计划）、各类报告
配置库：
- 开发库（动态库、程序员库、工作库；动态系统、开发者系统、开发系统、工作空间）：保存正在开发的配置实体。
- 受控库（主库、系统库；主系统、受控系统）：管理基线。
- 产品库（静态库、产品库、软件仓库；静态系统）：最终产品。
版本控制
- 处于草稿状态的配置项的版本号格式为：0.YZ，其中YZ数字范围为01～99。随着草稿的不断完善，YZ的取值应递增。YZ的初值和增幅由开发者自己把握。
- 处于正式发布状态的配置项的版本号格式为：X.Y。其中X为主版本号，取值范围为1～9；Y为次版本号，取值范围为1 ~ 9。配置项第—次正式发布时，版本号为1.0。
- 如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。
- 处于正在修改状态的配置项的版本号格式为：X.YZ。在修改配置项时，一般只增大Z值，X.Y值保持不变。
变更控制
软件工具
按软件过程活动将软件工具分为：
- 软件开发工具：需求分析工具、设计工具、编码与排错工具。
- 软件维护工具：版本控制工具（VSS、CVS、SCCS、SVN、GIT）、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
- 软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
风险管理
风险管理就是要对项目风险进行认真的分析和科学的管理，这样，是能够避开不利条件、少受损失、取得预期的结果并实现项目目标的，能够争取避免风险的发生或尽量减小风险发生后的影响。但是，完全避开或消除风险，或者只享受权益而不承担风险是不可能的。
风险管理计划编制：如何安排与实施项目的风险管理，制定下列各步的计划。
风险识别：识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险，形成一个风险列表。
风险定性分析：对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风险类型。
风险定量分析：进一步了解风险发生的可能性具体由多大，后果具体由多严重。包括灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟。
风险应对计划编制：对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风险应对计划。包括消极风险（避免策略、转移策略、减轻策略);积极风险（开拓、分享、强大）。
风险监控：监控风险计划的执行，检测残余风险，识别新的风险，保证风险计划的执行，并评价这些计划对减少风险的有效性。
在信息系统项目中，从宏观上来看，风险可以分为项目风险、技术风险和商业风险。
项目风险是指潜在的预算、进度、个人（包括人员和组织)、资源、用户和需求方面的问题，以及它们对项目的影响。项目复杂性、规模和结构的不确定性也构成项目的（估算）风险因素。项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。
技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素。技术风险威胁到待开发系统的质量和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。
商业风险威胁到待开发系统的生存能力，主要有以下5种不同的商业风险：
- 市场风险。开发的系统虽然很优秀但不是市场真正所想要的。
- 策略风险。开发的系统不再符合企业的信息系统战略。
- 销售风险。开发了销售部门不清楚如何推销的系统。
- 管理风险。由于重点转移或人员变动而失去上级管理部门的支持。
- 预算风险。开发过程没有得到预算或人员的保证。
软件能力成熟度模型
软件能力成熟度模型（Capability Maturity Model for Software，CMM）
| 初始级 |
|---|
| 特点： 软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。 |
| 可重复级 |
| 特点： 建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。 过程域： 软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪与监督、软件项目策划、软件需求管理 |
| 已定义级 |
| 特点： 管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来发和维护软件。 过程域： 同行评审、组间协调、软件产品工程、集成软件管理、培训大纲、组织过程定义、组织过程集点 |
| 已管理级 |
| 特点： 制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量有定量的理解和控制。 过程域： 软件质量管理和定量过程管理 |
| 优化级 |
| 特点： 加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。 过程域： 过程更改管理、技术改革管理和缺陷预防 |
软件能力成熟度模型集成（Capability Maturity Model Integration for Software，CMMI）
CMMI是在CMM的基础上发展而来的。
| 初始级 |
|---|
| 特点： 过程不可预测且缺乏控制 |
| 已管理级 |
| 特点： 过程为项目服务 过程域： 需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证 |
| 已定义级 |
| 特点： 过程为组织服务 过程域： 需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境 |
| 定量管理 |
| 特点： 过程已度量和控制 过程域： 组织过程性能、定量项目管理 |
| 优化级 |
| 特点： 集中于过程改进和优化 过程域： 组织级改革与实施、因果分析和解决方案 |