项目与项目管理

软件与软件项目

项目管理

项目管理知识体系

软件项目管理知识体系

敏捷项目管理

项目确立

项目评估

项目立项

立项流程

项目招投标

项目授权

生存期模型

生存期概述

预测期生存模型

瀑布模型 Waterfall

要求所有的活动严格按照顺序自上而下的执行，上一个活动的输出作为下一个活动的输入。

适合的项目：

• 在项目开始之前，项目的需求很明确

• 在项目开始之前，项目的解决方案也很明确

如：财务系统，库存管理系统、短期项目

V模型

适用于：

• 在项目开始前，项目的需求很明确

• 在项目开始前，项目的解决方案很明确

• 对系统的性能安全很严格的项目

迭代型生存期模型

快速原型模型

从最核心的方面开始，向用户展示完成的部分，然后根据用户反馈信息继续开发原型，并重复这一过程。

直到开发者和用户都认为原型已经足够好了，在此基础上开发客户满意的软件产品。

适合于：

• 在项目开始前，项目的需求不明确

• 需要减少项目需求的不确定性

如：第一次开发的项目，验证可行性；确定显示界面

增量型生存期模型

增量式模型

适合于：

• 项目开始时，明确了需求的大部分，但是需求可能会发生变化。

• 对于市场用户把握不是很准，需要逐步了解

• 对于有庞大和复杂功能的系统进行功能改进，就需要一步一步实施的

螺旋式模型

螺旋模型沿着螺线旋转，四个象限分别表达了四个方面的活动：制定计划、风险分析、实施工程、客户评估

适合：

• 风险是主要的制约因素

• 不确定性和风险制约了项目进度

• 用户对自己的需求也不是很明确

• 需要对一些基本的概念进行验证

• 可能发生一些重大的变更

• 项目规模很大

• 项目中使用了新技术

渐进式阶段模型——最常用

可以将大的项目划分成几个小项目来做，将周期长的项目划分成几个明确的阶段。  “化繁为简，各个击破”是解决复杂问题的一个方法。

综合了增量式模型和螺旋模型的一个实用模型

• 渐进式前进

• 阶段式提交

特点：

阶段式提交一个可运行的产品，每个阶段提交的产品都是一个独立的系统    

关键的功能更早出现，可以提高开发人员和客户的信心

早期预警问题，避免软件缺陷不知不觉的增长

阶段式提交产品说明进展，减少报告负担    

阶段性完成可以降低估计失误

阶段性完成均衡了弹性和效率

适用于：从本质上讲，渐进式阶段模型可以适用于任何规模的项目；考虑到需要不断提交新的版本，因此渐进式阶段模型主要适用于中型或大型项目，是目前软件开发中常釆用的模型；采用这个模型可以随时看到项目的未来

敏捷型生存期模型

需求管理

软件需求定义

软件需求三个层次

业务需求：反映了组织或者客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定，他 们在项目视图与范围文档中予以说明。

用户需求：用户通过使用本产品必须要完成的任务。可以在用例或者场景中说明。

功能需求：定义了开发人员必须实现的软件功能，使得用户可以通过使用此软件能完成他们的任务，从而满足业务需求。

约束：对开发人员在软件产品设计和构造上的限制

软件需求管理过程

需求工程的研究内容

软件需求管理的过程

需求开发和管理的界限

需求开发 - 2. 需求分析

需求分析也叫需求建模

需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述，并尽可能多地捕获现实世界的语义

需求分析模型：

与需求获取的区别： 使用模型描述，以获取用户更明确的需求

需求分析需要进行的活动：

• 以图形表示的方式描述系统的整体结构，包括系统的边界与接口

• 通过原型，页面流或其他方式提供可视化界面，用户可以对需求做出自己的评价

• 以模型描述系统的功能项、数据实体、外部实体、实体之间的关系及实体之间的状态转换

基本策略：头脑风暴、专家评审、焦点会议组等方式进行具体的流程细化、数据项的确认

传统需求分析方法

基于数据流的结构化方法   

结构化方法是：

• 面向数据流的方法

• 自顶向下逐步求精的分析方法

• 根据软件内部数据传递、变换的关系进行分析的

数据流图 (DFD) 、数据字典 (DD) 、实体联系图 (ERD) 、 系统流程图等都是数据流分析技术

数据流图DFD，是一种描述软件系统逻辑模型的图形符号，使用4种基本元素来描述系统的行为，即过程、实体、数据流和数据存储

数据字典由数据项、数据流和数据文件组成

基于UML需求建模方法      

一种面向对象的场景分析方法

一个用例 ( use case ) 就是系统向用户提供的一个有价值的结果的某项功能。用例捕获的是功能性需求。

所有用例结合起来就构成了用例模型，描述系统的全部功能

该方法主要通过UML的用例视图、顺序视图、活动视图等表达需求模型

一个系统往往可以从不同的角度进行观察，从一个角度观察到的系统，就构成系统的一个视图

敏捷项目需求分析

项目范围管理—WBS

任务分解定义

任务分解方法

任务分解的基本步骤

敏捷项目任务分解

成本计划

成本估算概述

成本估算方法

功能点估算法

面向功能点（FP,Function Point）的度量

功能点估算是对程序规模的一个综合量度，经常用于项目早期阶段，从需求说明书确定功能点比确定代码行容易。

功能点估计法要评估产品所需要的内部基本功能和外部功能，然后根据技术复杂度因子（权）对它们进行量化，产生产品规模的最终结果。

功能点计算步骤：

1）确定应用程序必须包含的功能

2）对于每个功能，通过4类外部行为或者事务的数目，以及一类内部逻辑文件的数目来估算由一组需求所表达的功能点数目

这五类功能计数项分别是：

1. 外部输入EI：外部输入给软件提供面向应用的数据项（如屏幕、表单、对话框、控件、文件等）

2. 外部输出EO：向用户提供(经过处理的)面向应用的信息，例如，报表和出错信息等。

3. 外部查询EQ：一个输入引出一个即时的简单输出

4. 内部逻辑文件ILF：数据完全存在于应用的外部，并且由另一个应用维护。

5. 外部接口文件EIF

3）对五类功能计数项中的每一类按照其复杂度不同分为简单、一般和复杂。所有功能计数项加权的总和，就形成了该产品的未调整功能点计数（UFC）。

4）计算项目中14个技术复杂度因子（TCF）

技术复杂度因子TCF计算公式如下：

5）调整所计算的功能点（FP）

FP: 功能点

UFC: 未调整功能点计数

TCF: 技术复杂度因子

---

功能点可以按照一定的条件转换为软件代码行LOC。

AVC：指该语言在实现一个功能点时所要用的平均代码行（查表）

用例点估算法

计算步骤：

1）计算未调整的角色的权值UAW(Unadjusted Actor Weight)

C={simple, average, complex}

aCardinality(c)是参与的角色数目

2）计算未调整的用例的权值UUCW(Unadjusted User Case Weight)

C={simple, average, complex}

uCardinality(c)是参与的用例数目

3）计算未调整的用例点UUCP(Unadjusted User Case Point)

4）计算技术复杂度因子TCF - 13个 + 环境因子ECF - 8个

5）计算调整的用例点UCP(User Case Point)

6）计算工作量

PF是Productivity Factor，是项目生产率，其默认值为20

类比 (自顶向下)估算法

是一种自上而下的估算形式，通常在项目初期或者信息不足时采用此方法。

简单易行，花费少，但是具有一定的局限性，准确性差。

类比估算中，需要评价不同项目间的相似程度。

相似度计算非常麻烦，所以基本上使用主观推测，很少计算。

优点：

• 直观

• 能够基于过去实际的项目经验来确定与新的类似项目的具体差异以及可能对成本产生的影响

缺点：

• 不能适用于早期规模等数据都不确定的情况；

• 应用一般集中于已有经验的狭窄领域，不能跨领域应用；

• 难以适应新 的项目中约束条件、技术、人员等发生重大变化的情况。

参数估算法

参数模型也称为算法模型或经验导出模型，是一种使用项目特性参数建立数学模型来估算成本的方法，是通过大量的项目数据进行数学分析导出的模型，是一种统计技术。

找到软件工作量的各种成本影响因子，并判定它对工作量所产生影响的程度是可加的、乘数的还是指数的，以期得到最佳的模型算法表达形式。

当某个因子只影响局部，那么他是可加的

如果某个因子有全局性的影响，那么它是乘数的或者指数的

使用条件：

• 具有良好的项目数据为基础

• 存在成熟的项目估算模型

特点：

• 比较简单，也比较准确

• 如果模型选择不当或者数据不准，也会导致偏差

参数模型估计——IBM（Walston-Felix）模型

面向LOC驱动的静态单变量模型

 

COCOMO

将开发所需要的工作量表示为KLOC软件规模和一系列成本因子的函数,基本估算公式：

PM是工作量，通常表示为人月

A可以校准的常量;

S为KLOC软件规模;

E为规模的指数,说明不同规模软件具有的相对规模经济和不经济性;

EM为工作量乘数,反映某个项目特征对完成项目开发所需工作量的影响程度;

n为描述软件项目特征的成本驱动因子的个数。

 

COCOMO 81

Effort 表示工作量，即开发软件所需的人力(人月，PM

项目的模式：

有机/组织（Organic）：规模较小的、简单的软件项目；各类应用程序

嵌入式（Embedded）：规模和复杂性处于中等程度的软件项目；系统程序

半有机/半分离（Semidetached）：指必须要求在一组紧密联系的硬件、软件及操作约束下开发的软件项目；各类实用程序，介于上述两种软件之间，例如编译器（程序）

有3个等级的模型，级别越高，模型的参数约束越多：

① 基本COCOMO 【相关信息极少情况下】

静态单变量模型，它用一个以已估算出来的源代码行数为自变量的函数来计算软件开发工作量。

a和b的数值可以通过查表获得

② 中等COCOMO 【需求确定之后使用】

在LOC为自变量函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算

表示15个成本驱动因子的取值，他们被按照影响分成了多个等级。

③ 高级COCOMO 【设计完成后使用】

包括中级COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对项目过程中分析、设计等各步骤的影响

工作量及进度估算公式与中级COCOMO模型一致

COCOMO II

给出了3个等级的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节的考虑逐级增加：

① 应用组装模型---规划阶段

主要适用于原型构造项目或者通过已有构件组合进行的软件项目的工作量估算

② 早期设计模型---设计阶段

适用于体系结构设计阶段。这个阶段设计了基本的软件结构，基于功能点或可用代码行。有5个规模指数因子、7个工作量乘数因子

A是常数，2000年定为2. 94；

S是规模；

E是指数比例因子， , B可以校准，目前设定B=0.91, SF是指数驱动因子，指数比例因子的效果是对于规模较大的项目，预计的工作量将增加，也就是说，考虑了规模的不经济性；

EM是工作量系数。

③ 后体系结构模型---开发阶段

适用于完成体系结构设计之后的软件开发阶段

该模型与早期设计模型基本是一致的，不同之处在于工作量系数不同，将后体系结构模型中的工作量系数（即成本因素）划分成产品因素、平台因素、人员因 素和项目因素4类，共17个属性。

成本预算

成本基线 cost baseline

成本基线是每个时间阶段内的成本，是项目管理者度量或监控项目的依据

进度计划

进度管理基本概念

进度管理图示——网络图

网络图是活动排序的一个输出，展示项目中各个活动以及活动之间的逻辑关系。 分为PDM和ADM（就是任务在点上还是边上的区别）

PDM中节点表示活动，箭头表示活动之间的关系。  PDM也叫优先图法、节点法。

ADM中节点表示前一个活动的结束，后一个活动的开始，箭头表示任务。

虚活动：为了定义活动，表示逻辑关系，不消耗资源

进度管理图示——甘特图

特点：

显示基本的任务信息

可以查看任务的工期、开始时间和结束时间以及资源的信息

只有时标，没有活动的逻辑关系

进度管理图示——资源图

资源图用来显示项目进展过程中资源的分配情况，资源包括人力资源、设备资源等。

进度管理图示——燃尽图/燃起图

燃尽图：是在项目完成之前，对需要完成的工作的一种可视化表示；表示剩余的工作量随时间的变化，可用于表示开发速度。

燃起图：显示已完成的工作；表示完成的工作量随时间的变化。

任务资源估计

任务历时估算

PERT（工程评估评审技术）（计算题重要）

基于对某项任务的乐观、悲观、最可能的概率时间估计。

PERT历时是对三种估计加权平均。

O:最小估算值：乐观  

P：最大估算值：悲观

m：最可能估算值。

注意是对每项任务都可以计算出来一个PERT历时。 然后将所有历时估算加和求出项目总历时。

对于每个任务也可以求方差和标准差。

Jones的一阶估算准则

基于估算项目功能点，从幂次表中选择合适的幂次将功能点升幂。

进度计划编排

进度编制的基本方法——时间压缩法

时间压缩法是在不改变项目范围的前提下缩短项目工期的方法，是一种数学分析方法。 分为：

应急法——赶工（Crash）：时间成本平衡方法、进度压缩因子方法

时间成本平衡方法（进度压缩单位成本方法）是一种线性关系方法，进度压缩与成本的增长是成比例的。

时间成本平衡基于以下假设提出：

• 每个任务存在一个正常进度和可压缩进度、一个正常成本和可压缩成本。

• 通过增加资源，每个任务的历时可以从正常进度压缩到可压缩进度。

• 每个任务无法在低于可压缩进度内完成。

• 有足够需要的资源可以利用。

• 在“正常”与“可压缩”之间，进度压缩与成本的增长是成正比的。

压缩进度因子方法

例：初始进度估算是12月，初始工作量估算是78人月，如果进度压缩到10月，进度压缩因子= 10/12=0.83，则进度压缩后的工作量是：78/ 0.83=94人月。

总结：进度缩短17%，增加21%的工作量

平行作业法——快速跟进（Fast Tracking）

又称为快速跟进法，是平行地做活动

应急法不改变活动间的逻辑关系。应急(赶工)法是一种通过增加资源，以最小的成本代价来压缩进度工期的技术。赶工只适用于那些通过增加资源就能缩短持续时间的且位于关键路径上的活动。但赶工并非总是切实可行的，因它可能导致风险或成本的增加。

平行作业法则可改变活动间的逻辑关系，并行开展某些活动。平行作业法(快速跟进)将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展的。平行作业法常导致返工和增加风险。使用提前量通常会增加相关活动之间的协调工作，并增加质量风险，快速跟进还有可能增加项目成本。

进度编制的基本方法——资源优化

资源优化用于调整活动的开始日期和完成日期，以调整计划使用的资源，使其等于或少于可用的资源。

根据资源供需情况来调整进度模型。

资源平衡和资源平滑都属于资源优化方法。

资源平衡方法是为了在资源需求与资源供给之间取得平衡，通过调整任务的时间来协调资源的冲突，根据资源制约因素对开始日期和完成日期进行调整的一种技术。

主要的目的是形成平稳连续的资源需求，最有效地利用资源，使资源闲置的时间最小化，同时尽量避免超出资源能力。

如果共享资源或关键资源只在特定时间可用，数量有限，或被过度分配，如一个资源在同一时段内被分配至两个或多个活动，就需要进行资源平衡。

资源平衡往往导致关键路径改变。关键路径法通常可以产生一个初始进度计划，而实施这个计划需要的资源可能比实际拥有的多。

在项目编排中进行资源的优化配置，可保证资源最优化、最有效。

利用资源平衡法可在资源有约束的条件下制定一个进度计划。

资源平滑方法是对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。

相对于资源平衡而言，资源平滑不会改变项目关键路径，完工日期也不会延迟。

活动只在其自由和总浮动时间内延迟，但资源平滑技术可能无法实现所有资源的优化。