软件工程课件：第十三章 软件项目管理

软件工程

第十三章软件项目管理第十三章软件项目管理13.1估算软件规模13.2工作量估算13.3进度计划13.4人员组织13.5质量保证13.6软件配置管理13.7能力成熟度模型2

什么是软件项目管理？为了使软件项目能够按照预定的成本、进度、质量顺利完成，通过合理地组织和利用一切可以利用的资源，按照计划的成本和进度，完成计划的目标。它包括对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。3

项目管理过程(1)①启动软件项目。确定项目的目标和范围。②度量。帮助开发人员了解开发技术、过程和产品。③估算。对软件开发中的人力、项目持续时间、成本作出估算。规模估算：代码行技术、功能点技术工作量估算：静态单变量模型、动态多变量模型、COCOMO模型开发时间估算：进度估算：Gantt图、工程网络4

项目管理过程（2)④风险分析。由风险识别、风险估计、风险评价和风险驾驭四个活动组成。⑤进度安排。包括识别项目任务，建立任务间的联系，估算各任务的工作量，分配人力和其他资源，制定进度时序。⑥追踪和控制。项目管理人员负责追踪在进度安排中标明的每一个任务，还可以对资源重新定向，对任务重新安排或者可以修改交付日期以调整已经暴露的问题。5

定量分析是重要的工程化的软件开发需要定量、科学的描述(实施前、实施过程中、实施完成后)定量、科学的描述有助于获取软件项目以及所开发的软件的某种可视性，促进软件项目的管理定量的信息描述必须在软件项目开发过程中采集6

软件度量的方法面向规模的度量(代码行技术)面向功能的度量(功能点技术)工作量估算项目成本估算软件质量度量7

1.面向规模的度量(1/3)

用软件代码行数目来表示软件项目规模生产率:PM=L/E,L表示代码总量(单位：KLOC)，E表示软件工作量(单位：人月)每千行代码的平均成本：CKL=S/L，S为软件项目总开销文档与代码比:Dl=Pd/L，Pd表示文档页数代码出错率:EQRl=Ne/L，Ne表示代码出错的数目8

1.面向规模的度量(2/3)9

1.面向规模的度量(3/3)优点简单易行，自然直观缺点依赖于程序设计语言的表达能力和功能软件开发初期很难估算出最终软件的代码行数对精巧的软件项目不合适只适合于过程式程序设计语言10

2.面向功能的度量(1/7)用软件的功能表示软件的规模“功能”不能直接度量，需要依靠其他度量结果导出功能点度量涉及多种因素项目开发初期就可估算出功能点计算目前主要基于经验公式11

2面向功能的度量(2/7)功能点计算方法FP=(0.65+0.01×Fi)×CTCT:5个信息量的“加权和”Fi:14个因素的“复杂性调节值”(i=1..14)0.65,0.01都是经验常数12

2面向功能的度量(3/7)CT的计算方法用户输入数×加权因子(简单=3,平均=4,复杂=5)用户输出数×加权因子(简单=3,平均=4,复杂=5)用户查询数×加权因子(简单=3,平均=4,复杂=5)文件数×加权因子(简单=3,平均=4,复杂=5)外部界面数×加权因子(简单=3,平均=4,复杂=5)CT＝上述计算值的总和13

2面向功能的度量(4/7)Fi的取值(0,1,2,3,4,5):0-没有影响，1-偶有影响，2-轻微影响，3-平均影响，4-较大影响，5-严重影响系统需要可靠的备份和复原码？系统需要数据通信吗？系统有分布处理功能吗？性能是临界状态吗？系统是否在一个实用的操作系统下运行？系统需要联机数据项吗？联机数据项是否在多屏幕或多操作之间进行切换？14

2面向功能的度量(5/7)需要联机更新主文件吗？输入、输出、查询和文件很复杂吗？内部处理复杂吗？代码需要被设计成可重用吗？设计中需要包括转换和安装吗？系统的设计支持不同组织的多次安装吗？应用的设计方便用户修改和使用吗？15

2面向功能的度量(6/7)优点与程序设计语言无关,在开发前就可以估算出软件项目的规模(事前)不足没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；功能点计算主要靠经验公式，主观因素比较多数据不好采集16

2面向功能的度量(7/7)代码行度量和功能点度量间的关系17

3成本和工作量估算(1/2)软件项目成本和工作量估算极为重要计算机系统中软件成本占总成本的比例很大用户和项目管理人员对软件成本和工作量估算都很重视软件项目成本估算比较困难软件是逻辑产品，软件开发是一个逻辑思维的过程涉及多方面因素18

3成本和工作量估算(2/2)软件项目成本和工作量估算常用方法参照和依据已完成项目的历史数据将大项目分解为小项目将项目按照软件生命周期分解根据经验估算公式上述方法可以同时、单独或者组合使用19

13.1估算软件规模软件项目规模影响软件项目成本和工作量软件项目代码行和功能点估算是成本和工作量的基础.估算出FP或者LOC期望值e=(a+4m+b)/6

其中:a=乐观值;b=悲观值;m=一般值20

案例:代码行和功能点估算(1/8)软件描述(CAD软件)CAD图形软件可接受来自用户的二维和三维几何数据，用户通过界面与CAD软件进行交互，并控制它，该软件具有良好的人机界面设计的特征。所有的几何数据及其支持信息存放在数据库中。开发设计分析模块，以产生所需的输出，这些输出将显示在各种不同的图形化设备上。软件在设计中要考虑与外设进行交互并控制它们，包括鼠标、数字化仪、打印机等等。21

案例:代码行和功能点估算(2/8)软件子系统划分图形用户界面及其控制机制二维几何分析三维几何分析数据库管理图形显示外设控制(与打印机、数字化仪、扫描仪的接口)设计分析子系统22

案例:代码行和功能点估算(3/8)估算出各个子系统的代码行，例如三维几何分析功能的代码行估算范围为：乐观值：4600可能值：6900悲观值：8600估算值：e=(a+4m+b)/6=680023

案例:代码行和功能点估算(4/8)24

案例:代码行和功能点估算(5/8)历史数据平均生产率Pf:620LOC/PM(620行代码/人月)每个人月的成本C=8000￥估算项目成本和工作量估算工作量=总代码行/PM=33200/620=54人月估算成本=估算工作量×每个人月的成本=54人月×8000=432000￥25

案例:代码行和功能点估算(6/8)基于功能点估算：26

Step1:计算CT值案例:代码行和功能点估算(7/8)Step2:计算复杂度调整因子27

案例:代码行和功能点估算(8/8)计算出FP的估算值FP=(0.65+0.01×Fi)×CT=372历史数据平均生产率6.5FP/PM每个人月的成本C=8000￥(平均月薪)估算成本和工作量工作量58人月成本457000￥28

13.2工作量估算经验估算模型：CoCoMo模型？COCoMo是指ConstructiveCostModel，构造性成本模型，Boehm于1981年提出，用于对软件开发项目的规模、成本、进度等方面进行估算CoCoMo模型是一个综合经验模型，模型中的参数取值来至于经验值，并且综合了诸多的因素、比较全面的估算模型比较实用、可操作，在欧盟国家应用较为广泛29

经验估算模型(2/7)CoCoMo模型的层次－支持不同的阶段基本COCoMo模型（应用系统组成模型）系统开发的初期，估算整个系统的工作量(包括维护)和软件开发和维护所需的时间中间COCoMo模型（早期设计模型）估算各个子系统的工作量和开发时间详细COCoMo模型（后体系结构模型）估算独立的软构件，如各个子系统的各个模块的工作量和开发时间30

经验估算模型(3/7)基本CoCoMo模型E=a

(kLOC)b;E是工作量(人月)，a和b是经验常数D=c

Ed;D是开发时间(月)，c和d是经验常数其中，a,b,c,d为经验常数，其取值见下表31

经验估算模型(4/7)中间CoCoMo模型E=a

(kLOC)b

EAF

其中，E表示工作量(人月)，EAF表示工作量调节因子，a,b为经验常数，其取值见下表32

经验估算模型(5/7)EAF的取值(考虑15个因素)软件产品属性(3)：软件可靠性，软件复杂性，数据库的规模计算机属性(4)：程序执行时间，程序占用内存大小，软件开发环境的变化，软件开发环境的响应速度人员属性(5)：分析员能力，程序员能力，领域经验，开发环境的经验，程序设计语言的经验项目属性(3)：软件开发方法的能力，软件工具的数量和质量，软件开发的进度要求33

经验估算模型(6/7)EAF的取值(范围)很低、低、正常、高、很高、极高Boehm建议取值范围[0.70-1.66]EAF的计算＝

Fi(i=1..15)调节因子及其取值由统计结果和经验决定，不同的软件开发组织在不同的时期可能会有不同的取值34

经验估算模型(7/7)案例分析：用基本CoCoMo模型估算项目的工作量、开发时间和参加项目开发的人数CAD软件：目标代码行33.2kLOC，属于中等规模，半独立型，因而a=3.0,b=1.12,c=2.5,d=0.35E=3.0*(33.2)1.12=152PMD=2.5*(152)0.35=14.5(月)参加项目人数N=E/D=152/14.5=11(人)35

13.3进度计划包括估算开发时间和估算工程进度级36

估算活动的周期(1/4)细分活动活动的粒度越小，估算的准确度就会越高借鉴历史数据积累历史数据使用估算模型例如，CoCoMo模型;Putnam模型考虑缓冲时间缓冲时间保证项目按照计划有足够的时间来完成活动37

估算活动的周期(2/4)缓冲时间意外事件的缓冲意外事件可能会发生(如全企业的培训)例如，需求分析计划从8.1开始共需20个工作日，应该8.29日完成，但中间公司要开展2天的全员培训，因此8.31结束节假日时间的缓冲例如，编码计划从9.31开始，工作量为10个工作日，因为国庆放假1周，因此，应该计划在10.21日完成不要在计划中考虑加班时间，加班是不可避免得，但是考虑了加班，可能会发生更多的加班38

估算活动的周期(3/4)综合考虑其他因素考虑节假日以工作日(而不是星期)规定活动周期考虑参与活动团队的教育、培训、经验和技能水平考虑教育和培训需要考虑评审所化的时间考虑传播时间考虑团队中成员的其他工作考虑硬件、工具和人员的效率考虑活动的迭代和重复活动之间有一定的缓冲……39

估算活动的周期(4/4)工作量的分布40

分析和设计40%-50%测试和调试30%-40%编码10%-20%进度安排软件开发项目的进度安排有两种方式：（1）系统最终交付日期已经确定，软件开发部门必须在规定期限内完成；（2）系统最终交付日期只确定了大致的年限，最後交付日期由软件开发部门确定。41

进度安排落空，会导致市场机会的丧失，使用户不满意，而且也会导致成本的增加。因此，在考虑进度安排时，要把工作量与花费时间联系起来，合理分配工作量,利用进度安排的有效分析方法严密监控软件开发的进展情况，使软件开发进度不致拖延。42

人数与软件生产率的关系当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。通信需花费时间和代价，会引起软件错误增加，降低软件生产率。43

若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个软件开发小组有n

个人，每两人之间都需要通信，则总的通信路径有n(n-1)/2(条)。44

设一个人单独开发软件，生产率是5000行／人年。若

4个人组成一个小组共同开发这个软件，则需要6条通信路径。若在每条通信路径上耗费的工作量是250行／人年。则小组中每个人的软件生产率降低为

5000－6×250／4＝

=5000－375＝

=4625行／人年。45

从上述分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件项目，一个人单独开发，时间太长。因此软件开发小组是必要的。但是，开发小组不宜太大，成员之间避免太多的通信路径。在开发进程中，切忌中途加人，避免太多的生产率损失。46

描述项目进度计划甘特图(Gantt)网络图47

48

在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是以必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。49

13.3.2甘特图（GanttChart）(1/3)甘特图(2/3)Gantt图常用水平线段来描述把任务分解成子任务，以及每个子任务的进度按排，该图表示方法简单易懂，一目了然，动态反映软件开发进度情况。甘特图是一个图形化的任务表示方式，分为二个部分来显示任务计划左部的工作表，以文字方式显示任务信息，如任务名称，开始和结束日期等右边的图表，以条形图方式显示任务信息50

Gantt图:进程计划时间表51

13.3.3工程网络图当把一个工程项目分解成许多子任务，它们彼此间的依赖关系又比较复杂时，仅用Gantt图作为安排进度的工具是不够的，因为他难于做出既节省资源又保证进度的计划，而且容易发生差错。工程网络图也是一个图形化的任务表示方式,同样能描绘任务分解情况以及每项作业的开始时间和结束时间。52

工程网络图工程网络图是一种有向图，该图中用圆表示事件，有向弧或箭头表示子任务的进行，箭头上的数字称为权，该权表示此子任务的持续时间，箭头下面括号中的数字表示该任务的机动时间，图中的圆表示与某个子任务开始或结束事件的时间点。53

54

(EET)(LET)甘特图和网络图的区别甘特图和网络图是等价的，可以相互转换甘特图的特点更能直观的显示任务的进程网络图的特点更能展示任务之间的相关性55

13.3.5关键路径关键路径上的事件（关键事件）必须准时发生，组成关键路径的作业（关键作业）的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。56

13.3.5关键路径(1/3)57

什么是关键路径？是指从起始任务开始，到结束任务为止的、具有最长长度的路径关键路径1：A-D-H;关键路径2：A-E-F-G-H关键路径(2/3)为什么要考虑关键路径？关键路径上活动的进度直接影响到整个项目的进度如果关键路径上活动的进度受到影响，那么整个项目的进度肯定会受到影响要缩短项目的开发周期，必须加快关键路径上活动的开发进度58

13.4人员组织59

3.程序设计小组的组织形式小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。（1）主程序员制小组小组的核心由一位主程序员(高级工程师)、二至五位技术员、一位后援工程师组成。主程序员负责小组全部技术活动的计划、协调与审查，设计和实现项目中的关键部分。60

技术员负责项目的具体分析与开发，文档资料的编写工作。后援工程师支持主程序员的工作，为主程序员提供咨询，也做部分分析、设计和实现的工作。并在必要时能代替主程序员工作。主程序员制小组还可以由一些专家(如通信专家或数据库设计专家)、辅助人员(如打字员和秘书)、软件资料员协助工作。61

（2）民主制小组在民主制小组中，遇到问题，组内成员之间可以平等地交换意见。工作目标的制定及做出决定都由全体成员参加。虽然也有一位成员当组长，但工作的讨论、成果的检验都公开进行。这种组织形式强调发挥小组每个成员的积极性。有人认为这种组织形式适合于研制时间长、开发难度大的项目。62

（3）层次式小组(现代程序员组)在层次式小组中，组内人员分为三级：组长（项目负责人）一人负责全组工作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动。他直接领导二至三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。63

这种组织结构只允许必要的人际通信。比较适用于项目本身就是层次结构的课题。因为这样可以把项目按功能划分成若干个子项目，把子项目分配给基层小组，由基层小组完成。这种组织方式比较适合于大型软件项目的开发。64

65

人员配备如何合理地配备人员，也是成功地完成软件项目的切实保证。所谓合理地配备人员应包括：

按不同阶段适时任用人员恰当掌握用人标准。66

1.项目开发各阶段所需人员一个软件项目完成的快慢，取决于参与开发人员的多少。在开发的整个过程中，多数软件项目是以恒定人力配备的。实际人力需求与开发进度的关系如下图中的曲线所示。67

68

按此曲线，需要的人力随开发进展逐渐增加，在编码与单元测试阶段达到高峰，以后又逐渐减少。如果恒定地配备人力，在开发初期将会有部分人力资源用不上而浪费掉。在开发中期，需要人力不够，造成进度的延误。在开发后期就需要增加人力以赶进度。恒定地配备人力将浪费人力资源。69

13.5质量保证13.5.1软件质量是“软件与明确声明的功能和性能需求、文档中明确描述的开发标准、以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度”。IEEE：与软件产品满足规定和隐含需求的能力有关的特征或特征的全体软件与明确地和隐含地定义的需求相一致的程度。70

软件质量强调以下三个要点：软件需求是“质量”度量的基础，不符合需求就是质量不高。软件开发中，应遵照规范化标准定义的开发准则，否则，极有可能导致质量不高。重视隐含需求，如软件的可维护性等，否则，软件的质量也难以保证。71

软件质量模型通常用“软件质量模型”来描述影响软件质量的特性。比较有影响力的软件质量模型有：①McCall质量模型②ISO的质量摸型(不要求)72

McCall质量模型73

McCall质量因素的定义74

13.5.2软件质量保证措施软件质量保证是为了保证软件产品和服务充分满足消费者要求的质量而进行的所有有计划、有组织的活动，从而有效地控制所有影响软件质量的因素。参加软件质量保证工作的人员可分为：软件工程师，进行技术复审和软件测试

SQA小组，辅助软件工程师提高质量见教材P32675

1.技术复审：能较早发现软件错误，防止错误被传播到后续阶段。2.走查:标记错误不改正错误3.审查：审查的范围比走查广泛，步骤也较多。是检测软件错误的一种好方法，能在软件过程早期阶段发现并改正错误。4.程序正确性证明测试只能证明程序有错误，不能证明程序中没有错误。其基本思想是证明程序能完成预定的功能。76

13.6软件配置管理软件配置管理是在软件的整个生命期内管理变化的一组活动。这组活动用来：l）标识变化；2）控制变化；3）确保适当地实现变化；4）向需要知道这类信息的人报告变化这组活动使得因为“变更”而引起的混乱减到最小，最有效地提高生产率。77

软件配置管理不同于软件维护，维护是在软件交付给用户使用后才发生的而配置管理是在软件项目启动时就开始，并一直持续到软件退役才终止的一组跟踪和控制活动。目标：使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。78

13.6.1软件配置1、软件配置项软件过程的输出信息。包括3类：①计算机程序（源代码和可执行程序）;②描述计算机程序的文档（供技术人员或用户使用）;③数据（程序内包含的或在程序外的