软件项目管理
目录
一、范围管理
二、时间/进度管理
(1).前导图法(单代号网络图，PDM)
(2).关键路径法 (PERT图)
(3).甘特图(Gantt图)
三、成本管理
(1).挣值分析法
四、质量管理
(1)质量保证与质量控制
(2).软件评审
(3).软件过程改进——能力成熟度模型CMMI
五、软件配置管理
(1).配置项
(2).配置库
(3).软件配置工具
(4).软件变更控制
(5).版本控制
六、风险管理
一、范围管理
确定项目边界，即哪些工作是项目该做的，哪些工作是不应该包括在项目的工作内容中。在接到一个项目需求时，甲方肯定希望做的东西越多越好。而作为乙方则需要把兴奋需求控制住，在完成必要需求的基础上，其他不必要的功能越少越好。
范围管理首先需要制定好范围计划，有了计划之后再去根据《需求规格说明书》定义产品范围，确认出的产品需要做的工作，这就是确认工作范围。光有工作范围粒度还是不够，需要创建WBS(工作分解结构) ，将每一个工作进行细化。最后再制定的内容进行确认，并再后续实施过程中去控制好范围。
二、时间/进度管理
时间管理又称为进度管理。进度管理并不是说盯着别人干活。如何去科学地管理项目进度呢？
首先时活动定义，它延续了WBS方法，把要做的工作拆解成细小的工作包，再把工作包拆分就成为了活动，拆分的粒度越小。活动的完成时间越好评估。并且可以将一些活动进行排序，分清楚哪些事情可以先做，哪些事情是可以后做;定义好活动之后需要对每个活动投入的人力资源、财务资源、硬件资源等进行估算。估算方式有多种
- 专家判断法：让有经验的人进行资源估算，利用经验判断类似的活动需要投入多少资源。
- 三点估算法：和专家法类似，也是让有经验的人进行资源估算。只不过估算结果要估算当活动水平低、水平正常、水平高时的三种资源需求。给三种资源需求加上权重再求平均。此方法比专家判断法更加严谨。通常情况三种资源需求分别是A、B、C。得到最终资源(A+4B+C)/6。
- ...
活动资源估算完成后，对活动的执行时间进行大致估算，从而制定进度计划，比如用关键路径法识别关键活动，识别最晚开始时间等。后续对项目进度进行把控，跟进各个活动的状态，根据实际执行情况，调整资源、调整计划或者汇报风险。
(1).前导图法(单代号网络图，PDM)
每个节点都是活动，活动中标记了最早开始时间，活动完成时长，最早结束时间，最晚开始时间，空闲时间，最晚结束时间等。
其中，最后一个节点的最晚结束时间等于最早结束时间。松弛时间等于最晚开始时间减去最早开始时间。松弛时间为0的活动连成线就是关键路径。
- 松弛时间：又称总时差，在不影响总工期前提下的，活动机动时间
- 自由时差：在不影响后继节点的最早开始时间前提下的，活动机动时间
(2).关键路径法 (PERT图)
和前导图的画法有点不一样，关键路径法是双代号网络图。不仅节点标有代号，而边也有。再关键路径法中，活动是实线边，活动挂钩了对应的执行时间。虚线代表虚活动，虚活动即不占时间也不占资源，即执行时间为0的活动，但是它又要遵守活动间的依赖关系。
和前导图法一样计算关键路径。注意，虚活动也可能出现在关键路径上
(3).甘特图(Gantt图)
甘特图在进度跟进上的表现力要比上述方法要强些。细线代表计划，粗线代表实际值。
甘特图便于理解、容易制作。可以很清晰地标识出每一项任务的起始与结束时间。一般适用于比较简单的小型项目。可用于WBS的任何层次、进度控制，资源优化、编制资源和费用计划
但是甘特图无法系统地表达一个项目所包含工作之间复杂关系，难以进行定量的计算和分析，以及计划的优化等。
三、成本管理
在整个项目实施过程中，为确保项目在批准的预算条件下尽可能保质按期完成，而对所需的各个过程进行管理与控制。
在成本管理过程中，就是估算可能需要花费的财务资源。成本预算是指打算花费的财务资源。在成本控制中可以采用挣值分析方法。
(1).挣值分析法
此方法中首先要识别几个重要的参数
AC:已完成工作量的实际成本，就是在已经完成工作量中，实际所花费的资源。
EV:已完成工作量的预算成本，就是在已经完成工作量中，原本计划所花费的资源
PV:按照当前进度，原本计划所需要花费的预算。
例如，在上述案例中，项目进行到了第五天，总体10天的预算是1000元，那么PV就是500元；实际消耗了400元，那么AC就是400元；完成了3个函数的编写，原本计划每个函数花费100元，因此EV就是300元。从而得到
进度偏差SV=EV-PV = -200 ， 成本偏差 CV=EV-AC=-100元
进度绩效指数SPI = EV/PV =0.6 , 成本绩效指数 CPI = EV/AC= 0.75
剩余工作成本 在不偏差的情况下,ETC= BAC -EV =700元 ，
如果按照之前偏差的情况下,ETC= （BAC -EV）/CPI≈933.33元
完工估算 EAC =AC +ETC ，如果不偏差的情况下为1100元，有偏差下约为1333元。
从上述进度估算来看，进度偏差值、成本偏差为负数，说明进度和成本管理不太理想。绩效指数表明了实际与计划的比值。
四、质量管理
(1)质量保证与质量控制
质量控制是通过实施监控项目的具体结果，来判断它们是否符合相关质量标准，制定有效方案解决产生质量问题的原因。比如交付前，先自行运行，观察测试结果是否准确，发现Bug及时消除，以提高交付质量。
然而这种只关心结果的方式并不可取，因为结果对了，过程质量未必好。而过程质量好，那么结果的问题就可以减少许多。而质量保证就是看重过程，利用质量审计和过程分析，每隔一定时间进行来保证项目质量。
一定时间内质量控制的结果也是质量保证的质量审计对象。质量保证的成果又可以指导下一阶段的质量工作，包括质量控制和质量改进。
(2).软件评审
软件评审是质量保证的手段之一。其基本思想是，每个环节的工作都要进行评审，分析活有没有干好，干好了就继续往后做，没干好就推倒重来。在评审环节，涉及到需求和验收的工作需要客户参与进来。
软件评审分为技术评审和管理评审。在评审的过程中，不应以测试代替评审；评审人员应关注产品而不是评论开发人员；评审人员应关注实质性问题；评审会议不应变为问题解决方案讨论会；评审应被安排进入项目计划；评审参与者应了解整个评审过程；评审人员事先应对评审材料充分了解；应重视评审的组织工作。
(3).软件过程改进——能力成熟度模型CMMI
- 初始级，杂乱无章，个人英雄主义、没有明确定义的步骤
- 可重复级，建立了基本的项目管理过程和时间来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功,强调项目级管理
- 已定义级，管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目采用根据实际情况修改后的得到的标准软件过程来开发和维护软件，强调组织级管理
- 已管理级，制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制，强调指标要不断的量化
- 优化级，加强了定量分析，通过过程质量的反馈和来自新观念、新技术的反馈使过程能不断持续的改进，强调过程要不断的优化
五、软件配置管理
(1).配置项
配置就是一个产品的组成部分，对于软件来说，软件就是由一个个构建、模块文档组成的。这就是配置项。然而对于这些配置项也需要合适的管理。配置项主要分为基线配置项和非基线配置项。基线配置项指的就是产品组成部分的工作成果，比如需求文档、设计文档、源代码和测试用例等，这些是过程中必选的配置项。除此之外还有一些可选的配置项，比如工作计划、项目质量报告、项目跟踪报告等，这些虽然不是产品的必要组成部分，但是也值得保存管理的。（注意：设备清单，非自身产品的操作手册不属于配置项）
(2).配置库
配置库用来保存配置项的，类似于一个仓库。配置库包含开发库、受控库、产品库。开发库管理得最松，产品库管的最严。开发库分为动态库、程序员库、工作库,主要管理代码，可以随意修改。受控库分为主库和系统库，用于管理基线，需要走流程才可以变更。产品库分为备份库和静态库，是不可修改的。如果产品出了问题，那么要重新打回到受控库中才可以变更，变更好了再回归成产品。
类似的，开发库包含开发环境的源代码，可以随时pull和push，而受控库是上生产前的一个较为稳定的基线。这种基线通常是能够满足业务要求并且测试充分的。而产品库指的就是生产环境中的产品。
(3).软件配置工具
软件配置工具按照软件过程活动可分为三种
- 软件开发工具：需求分析工具、设计工具、编码于排错工具。
- 软件维护工具：版本控制工具(VSS、CVS、SCCS、SVN)、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
- 软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择；
(4).软件变更控制
对于受控库来讲，有时变更无法避免，但并不是说变就变，而是需要走流程。变更流程主要分为变更申请、对变更的必要性、科学性进行评估、讨论如何变更，之后是实施确认的变更内容，实施完成后重新验证，并留存。
(5).版本控制
版本控制内容主要涉及版本号的定义。通常在初次上线之前，处于草稿状态的软件版本号的前缀通常是0，也是主版本号，副版本号通常两位，前一位是升级版本位，第二位是修改本版位，随着更新，副版本号不断增加。软件正式发布的主版本号通常从1开始。副版本号变成1位。小修小改增加副版本号，软件大变动增加主版本号同时副版本号从头开始。
六、风险管理
风险具有随机性和相对性的基本属性 。所谓随机性就是风险可能发生，可能不发生，具有不确定性。而相对性就是对于我来说是重大风险，但是对于其他人看来可能不算风险.。风险的存在还具有客观性和普遍性。某一具体风险发生具有偶然性和大量风险发生的必然性。风险还具有可变性、多样性和多层次性。
风险主要分为项目风险，技术风险，商业风险。项目风险注重项目组内部的问题隐患，商业风险主要注重项目外部的风险因素。技术风险，主要关注软件过程中遇到的问题。
| 项目风险 | 潜在的预算、进度、人员和组织、资源、用户和需求问题 |
| 项目复杂性、规模和结构的不确定性 | |
| 技术风险 | 潜在的涉及、实现、接口、测试和维护方面的问题 |
| 规格说明的多义性、技术上的不确定性、技术陈旧、最新技术(不成熟) | |
| 商业风险 | 市场风险:系统虽然很优秀但不是市场真正所想要的 |
| 策略风险:系统不再符合企业的信息系统战略 | |
| 销售风险:开发了销售部门不清楚如何推销的系统 | |
| 管理风险:由于重点转移或人员变动而失去上级支持 | |
| 预算风险:开发过程没有得到预算或人员的保证 |