|
|
|
软件项目管理的对象是软件项目。为了使软件项目开发获得成功，必须对软件开发项目的工作范围、可能遇到的风险、需要的资源（人、硬／软件）、要实现的任务、经历的里程碑、花费的工作量（成本）以及进度的安排等做到心中有数。而软件项目管理可以提供这些信息。这种管理的范围覆盖了整个软件工程过程，即开始于技术工作开始之前，在软件从概念到实现的过程中持续进行，最后终止于软件工程过程结束。
|
|
|
|
|
|
由于软件具有可见性差、定量化难等特殊性，因此很难在项目完成前准确地估算出开发软件所需的工作量和费用。通常可以根据以往开发类似软件的经验（也可以是别人的经验）来进行成本估算。也可以将软件项目划分成若干个子系统或按照软件生存周期的各个阶段分别估算其成本，然后汇总出整个软件的成本。此外，还可以使用经验公式和成本估算模型来进行估算。
|
|
|
|
|
|
（1）自顶向下估算方法。该方法是估算人员参照以前完成的项目所耗费的总成本（或总工作量），来推算将要开发的软件的总成本（或总工作量），然后把它们按阶段、步骤和工作单元进行分配。这种方法的优点是对系统级工作的重视，所以估算中不会遗漏诸如集成、配置管理之类的系统级事务的成本估算，且估算工作量小、速度快。它的缺点是往往不清楚低级别上的技术性困难问题，而这些困难将会使成本上升。
|
|
|
|
（2）自底向上估算方法。该方法是将待开发的软件细分，分别估算每一个子任务所需要的开发工作量，然后将它们加起来，得到软件的总开发量。这种方法的优点是对每一部分的估算工作交给负责该部分工作的人来做，所以估算较为准确。其缺点是其估算往往缺少各项子任务之间相互联系所需要的工作量和与软件开发有关的系统级工作量，所以估算往往偏低。
|
|
|
|
（3）差别估算方法。该方法是将待开发项目与一个或多个已完成的类似项目进行比较，找出与某个相类似项目的若干不同之处，并估算每个不同之处对成本的影响，导出待开发项目的总成本。该方法的优点是可以提高估算的准确度，缺点是不容易明确“差别”的界限。
|
|
|
|
（4）其他估算方法。主要有专家估算法、类推估算法和算式估算法等。
|
|
|
|
.专家估算法：依靠一个或多个专家对要求的项目做出估算，其精确性取决于专家对估算项目的定性参数的了解和他们的经验。
|
|
|
|
.类推估算法：在自顶向下的方法中，类推估算法将估算项目的总体参数与类似项目进行直接比较得到结果；在自底向上方法中，类推估算法是在两个具有相似条件的工作单元之间进行。
|
|
|
|
.算式估算法：专家估算法和类推估算法的缺点在于它们依靠带有一定盲目性和主观性的猜测对项目进行估算。算式估算法则是企图避免主观因素的影响。用于估算的方法有两种基本类型：由理论导出和由经验导出。
|
|
|
|
|
|
常用的软件成本估算模型有Putnam模型和COCOMO模型。Putnam模型是一种动态多变量模型，它是假设在软件开发的整个生存期中工作量有特定的分布。COCOMO模型是最精确、最易于使用的成本估算模型之一。COCOMO模型可以分为如下3种：
|
|
|
|
（1）基本COCOMO模型：是一个静态单变量模型，它是对整个软件系统进行估算。
|
|
|
|
（2）中级COCOMO模型：是一个静态多变量模型，它将软件系统模型分为系统和部件两个层次，系统由部件构成，它把软件开发所需人力（成本）看作是程序大小和一系列“成本驱动属性”的函数。
|
|
|
|
（3）详细COCOMO模型：它将软件系统模型分为系统、子系统和模块三个层次，它除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响。
|
|
|
|
|
|
当在软件工程环境中考虑风险时，主要是基于关心未来、关心变化、关心选择这三个概念提出的。在进行软件工程分析时，项目管理人员要进行4种风险评估活动，包括建立表示风险概念的尺度，描述风险引起的后果，估计风险影响的大小，确定风险估计的正确性。
|
|
|
|
风险分析实际上是4个不同的活动：风险识别，风险预测，风险评估和风险控制。
|
|
|
|
|
|
风险识别是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。风险识别的一种方法是建立风险条目检查表。该检查表可以用于识别风险，并使得人们集中来识别下列常见的已知的及可预测的风险：
|
|
|
|
（1）产品规模。与要建造或要修改的软件的总体规模相关的风险。
|
|
|
|
（2）商业影响。与管理或市场所加诸的约束相关的风险。
|
|
|
|
（3）客户特性。与客户的素质以及开发者和客户定期通信的能力相关的风险。
|
|
|
|
（4）过程定义。与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。
|
|
|
|
（5）开发环境。与用以构建产品的工具的可用性及质量相关的风险。
|
|
|
|
（6）构建的技术。与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。
|
|
|
|
（7）人员数目及经验。与参与工作的软件工程师的总体技术水平及项目经验相关的风险。
|
|
|
|
|
|
风险预测，又称风险估算，它从两个方面评估一个风险：风险发生的可能性或概率，以及如果风险发生了，所产生的后果。通常，项目计划人员与管理人员、技术人员一起进行如下所述的4种风险预测活动：
|
|
|
|
（1）建立一个尺度或标准，以反映风险发生的可能性。
|
|
|
|
|
|
|
|
|
|
|
|
一种对风险评估很有用的技术就是定义风险参照水准。对于大多数软件项目来说，成本、进度和性能就是三种典型的风险参照水准。也就是说，对于成本超支、进度延期、性能降低（或它们的某种组合），有一个表明导致项目终止的水准。
|
|
|
|
在进行风险评估时，需要建立（ri，li，xi）形式的三元组。其中，ri表示风险，li表示风险发生的概率，xi则表示风险产生的影响。在风险评估过程中，需要执行以下4个步骤：
|
|
|
|
|
|
（2）建立每一组（ri，li，xi）与每一个参考水平值之间的关系。
|
|
|
|
（3）预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域所界定。
|
|
|
|
|
|
|
|
这一步的所有风险分析活动只有一个目的——辅助项目组建立处理风险的策略。一个有效的策略必须考虑风险避免、风险监控、风险管理及意外事件计划方面的问题。
|
|
|
|
如果软件项目组对于风险采用主动的方法，则避免永远是最好的策略。这可以通过建立一个风险缓解计划来达到。
|
|
|
|
风险管理策略可以包含在软件项目计划中，或者风险管理步骤也可以组织成一个独立的风险缓解、监控和管理计划（RMMM计划）。RMMM计划将所有风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分来使用。
|
|
|
|
|
|
进度的合理安排是如期完成软件项目的重要保证，也是合理分配资源的重要依据，因此进度安排是管理工作的一个重要组成部分。软件开发项目的进度安排有如下两种方式：
|
|
|
|
（1）系统最终交付日期已经确定，软件开发部门必须在规定期限内完成。
|
|
|
|
（2）系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定。
|
|
|
|
进度安排的常用图形描述方法有Gantt图（甘特图）和项目计划评审技术（Program Evaluation&Review Technique，PERT）图。
|
|
|
|
|
|
Gantt图是一种简单的水平条形图，它以日历为基准描述项目任务。水平轴表示日历时间线（如时、天、周、月和年等），每个条形表示一个任务，任务名称垂直地列在左边的列中，图中水平条的起点和终点对应水平轴上的时间，分别表示该任务的开始时间和结束时间，水平条的长度表示完成该任务所持续的时间。当日历中同一时段存在多个水平条时，表示任务之间的并发。下图所示的Gantt图描述了三个任务的进度安排。任务1首先开始，完成它需要6个月时间；任务2在1个月后开始，完成它需要9个月时间；任务3在6个月后开始，完成它需要5个月时间。
|
|
|
|
Gantt图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。但是其缺点是不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。
|
|
|
|
|
|
|
|
|
|
PERT图是一个有向图，图中的箭头表示任务，它可以标上完成该任务所需的时间；图中的节点表示流入节点的任务的结束，并开始流出节点的任务，这里把节点称为事件。只有当流入该节点的所有任务都结束时，节点所表示的事件才出现，流出节点的任务才可以开始。事件本身不消耗时间和资源，它仅表示某个时间点。一个事件有一个事件号和出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始；最迟时刻表示从该事件出发的任务必须在此时刻之前开始，否则整个工程就不能如期完成。每个任务还可以有一个松弛时间（slack time），表示在不影响整个工期的前提下，完成该任务有多少机动余地。为了表示任务间的关系，图中还可以加入一些空任务（用虚线箭头表示），完成空任务的时间为0。下图是PERT图的一个实例。不难看出，下图中的松弛时间为0的这些任务是完成整个工程的关键路径，其事件流为1→2→3→4→6→8→10→11。
|
|
|
|
|
|
|
|
PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，即哪些任务完成后才能开始另外一些任务，以及如期完成整个工程的关键路径。图中的松弛时间则反映了完成某些任务时可以推迟其开始时间或延长其完成所需的时间。但是，PERT图不能反映任务之间的并行关系。
|
|
|
|
|
|
合理地组织好参加软件项目的人员，有利于发挥每个人的作用，有利于软件项目的成功开发。在人员组织时，应考虑软件项目的特点、软件人员的素质等多方面的因素。
|
|
|
|
可以按软件项目对软件人员进行分组，如需求分析组、设计组、编码组、测试组和维护组等，为了控制软件的质量，还可以有质量保证组。
|
|
|
|
程序设计小组的组织形式也可以有多种，如主程序员组、无主程序员组和层次式程序员组等。
|
|
|
|
（1）主程序员组。主程序员组由一名主程序员、一名后备程序员（back up programmer）、一名资料员和若干名程序员组成。主程序员由经验丰富、能力强的高级程序员担任，他是该组织的技术领导和项目负责人，全面负责软件项目的开发。后备程序员是主程序员的助手，协助主程序员工作，必要时能代替主程序员工作。资料员负责保存和管理所有的软件配置元素，如文档资料、程序清单和存储介质等，还编译和链接代码、对提交的所有模块进行初步的测试。程序员则集中精力负责完成主程序员分配给他的最擅长的任务——编程。这种组织形式便于集中领导，步调统一，容易按规范办事，但不利于发挥个人的积极性。
|
|
|
|
（2）无主程序员组。无主程序员组中的成员之间相互平等，工作目标和决策都由全体成员民主讨论，根据需要也可以轮流坐庄。这种组民主气氛比较足，依赖个人的成分少，有利于发挥每个人的积极性。但这种组中交流量大，往往职责不明确，出了问题谁也不负责，而且不利于与外界的联系。
|
|
|
|
（3）层次式程序员组。层次式组中有一位组长，组长负责全面的工作，他领导若干名高级程序员，每个高级程序员又领导若干名程序员。这种组适合于具有层次结构特点的更大型的软件项目，该项目可分成若干个子项目，每个高级程序员负责一个子项目，然后再对子项目分解，并分配给程序员。
|
|
|
