• 进度管理

1. 进度管理就是采用科学的方法，确定进度目标，编制进度计划和资源供应计划，进行进度控制，在与质量、成本目标协调的基础上，实现工期目标。
2. 具体来说，包含以下过程：
   1. 活动定义：确定完成项目各项可交付成果而需要开展的具体活动。
   2. 活动排序：识别和记录各项活动之间的先后关系和逻辑关系。
   3. 活动资源估算：估算完成各项活动所需要的资源类型和效益。
   4. 活动历时估算：估算完成各项活动所需要的具体时间。
   5. 进度计划编制：分析活动顺序、活动持续时间、资源要求和进度制约因素，制定项目进度计划。
   6. 进度控制：根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。
3. 进度安排的常用图形描述方法有Gantt图（甘特图）和项目计划评审技术（PERT）图。

1. 关键路径法

1. 关键路径：最短工期，但却是从开始到结束时间最长的路径
2. 最早开始时间ES:某项活动能够开始的最早时间
3. 最早结束时间EF：某项活动能够完成的最早时间，EF=ES+工期
4. 最迟结束时间LF：某项活动必须完成的最迟时间
5. 最迟开始时间LS：为了使项目按时完成，某项目活动必须开始的最迟时间 LS=LF-工期

1. 　　总浮动时间：在不延误项目完成时间且不违反进度制约因素的前提下，活动可以从最早开始是金推迟或拖延的时间量，就是该活动的进度灵活性，正常情况下，关键活动的总浮动时间为0
2. 　　总浮动时间：最迟开始LS-最早开始ES 或 最迟完成LF-最早完成EF 或关键路径-非关键路径时长
3. 　　自由浮动时间：在指不延误任何最紧活动的最早开始时间且不违反进度制约的前提下，活动可以从最早开始时间推迟或拖延的时间量
4. 　　自由浮动时间=紧后活动最早开始时间的最小值-本活动的最早完成时间

• 软件配置管理

1. 配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。
2. 在GB/T1457-2006中将“配置管理”正式定义为“应用技术和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”
3. 配置管理包括6个主要活动：制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
4. 配置项：GB/T11457-2006对配置项的定义为“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待”。
5. 以下内容都可以作为配置项进行管理：外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。
6. 典型配置项包括项目计划书、需求文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。
7. 每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。
8. 配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。
9. 所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
10. 配置项的状态可分为“草稿”、“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕后重新通过评审时，其状态又变为“正式”。如图所示：

1. 配置项版本号

1. 处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01~99.随着草稿的修改，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
2. 处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1~9.Y为次版本号，取值范围为0~9.

配置项第一次成为“正式”文件时，版本号为1.0。

如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1……。当附件的变动积累到一定程度时，配置项的Y值可适当增加，Y值增加一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增加x值。

1. 处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。参加上述规则（2）。

1. 配置项版本管理：在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地找到配置项的任何版本。

• 质量管理

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

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

• 风险管理

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

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

1. 在信息系统项目中，从宏观上来看，风险可以分为项目风险、技术风险和商业风险。
   1. 项目风险是指潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，以及它们对项目的影响。项目复杂性、规模和结构的不确定性也构成项目的（估算）风险因素。项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。
   2. 技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素。技术风险威胁到待开发系统的质量和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。
   3. 商业风险威胁到待开发系统的生存能力，主要有以下5种不同的商业风险：

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