软件项目管理说明

第2章软件项目管理中山大学计算机科学系衣杨目录2.1软件度量2.2软件项目估算2.3软件质量度量2.4软件复杂性度量2.5软件可靠性度量2.6软件开发过程的管理2.7软件过程及软件成熟度模型CMM2.8软件项目管理的CASE工具

软件项目管理概述项目管理过程启动一个项目成本估算风险分析进度安排追踪和控制目录2.1软件度量2.2软件项目估算2.3软件质量度量2.4软件复杂性度量2.5软件可靠性度量2.6软件开发过程的管理2.7软件过程及软件成熟度模型CMM2.8软件项目管理的CASE工具2.1软件度量度量（metrics）:对软件产品、软件开发过程或资源简单属性的定量描述，如：程序规模、操作符个数、程序中的错误的个数等。p29测量（measure）：度量的函数。用于事后或实时，涉及测量的方法、过程、工具和数值结果；p29估算（estimation）:度量的函数。是预测，用于签定合同，立项、制定工作计划。过程（process）:与软件有关的活动，如：设计开发计划、开发活动、管理活动等。软件开发资源(resource):软件开发过程中需要的各种支持，如人力、经费、软硬件。2.1软件度量软件属性：*外部属性：体现了产品、过程、资源与环境的关系，如成本，效益，程序员的生产率，软件产品的可靠性，可用性，可维护性…..,是面向管理者和用户的属性。内部属性：软件产品、过程和资源本身的属性，如软件产品的结构、模块化程度，复杂性、程序长度。软件外部属性在软件开发过程中很难测量和控制，通过研究软件的内部属性度量解决软件外部属性的度量问题，进而逐步建立软件工程的度量体系。2.1软件度量1.面向规模的度量用代码行(LOC)数表示软件项目的规模，利用它不仅可以测量软件规模，还可以度量软件开发的生产率，计算每行代码的平均成本，计算文档与代码的比例管理，每千行代码存在的软件错误个数。2.1软件度量1.面向规模的度量--生产率pl=L/EL:代码行数，用千行代码kLOC(1KLOC=103LOC)度量E:软件项目的工作量，用人月(PM)度量。pl：软件项目的生产率，用每人每月完成的代码行数（LOC/PM）度量。2.1软件度量1.面向规模的度量--每行代码的成本Cl=S/LS:软件项目的总开销，用人民币或美圆表示；Cl

：软件项目每行代码的平均成本，用人民币元（美元）/代码行度量2.1软件度量1.面向规模的度量--文档与代码比Dl=Pd/LPd

：软件项目的文档页数Dl：每千行代码的平均文档页数2.1软件度量1.面向规模的度量--代码出错率EQRl=Ne/L

Ne：软件项目的代码错误数

EQRl

：每千行代码的平均错误数。2.1软件度量1.面向规模的度量—优缺点用软件代码行估算软件规模的优点：简单易行。用软件代码行估算软件规模的缺点：依赖于程序设计语言的表达能力；会对设计精巧的软件项目产生不利的影响；在项目开发前或初期很难作到；适用于过程式的程序语言。2.1软件度量2.面向功能的度量

Albrecht1979年提出,目前在欧共体很普遍，只涉及多种因素的间接度量方式。它根据事物信息处理程序的基本功能定义，因此在软件系统涉及初期就能够估算出软件项目的规模。2.1软件度量2.面向功能的度量--功能点FP用5个信息量的“加权和”CT和14个因素的“复杂性调节值”Fi

计算功能点FP。p322.1软件度量

Fi=0noeffect

Fi={0,1,2,3,4,5}表示起作用的程度。

=5时最大。与用代码行定义软件项目的开发效率、成本等度量一样，用功能点也可以定义相应的概念：2.面向功能的度量--生产率Pf=FP/EPf:每人每月完成的功能点数2.1软件度量2.面向功能的度量--平均成本Cf=S/FPCl:每功能点的平均成本（REM,USD）2.1软件度量2.面向功能的度量--文档与功能点比Df=Pd/FPDf:每功能点平均具有的文档页数2.1软件度量2.面向功能的度量--代码出错率EQRf=Ne/FP

EQRf:表示每个功能点的平均错误个数。2.1软件度量2.面向功能的度量的应用分析软件规模的功能点度量没有直接设计软件系统本身的算法复杂性，因此它适合算法比较简单的事物系统的软件规模度量。对比较复杂的软件系统，如实时系统、大型嵌入式系统软件、过程控制软件不适用。2.1软件度量面向功能度量的发展1986年Jones推广了功能点的概念，把软件项目中的算法复杂性因素因入到功能点中来。为了避免混淆，Albrecht定义的功能点称为简单功能点，用FPs

表示，Jones推广的功能点称为功能点，FP。推广的功能点包括计算机程序中用于各类问题求解的算法因素，如求解线性代数方程组，求解遍历二叉树各结点，处理中断，等等。对一般工程计算或事物处理软件，用两种方法计算出来的值应该基本相同，但对于复杂问题，FP>FPs

20%~35%.2.1软件度量功能点度量的优缺点优点与程序设计语言无关，适用于过程式和非过程式语言。适用于软件项目的开发初期。缺点涉及主观因素较多信息领域某些值不易采集FP的值没有直观的物理意义。2.1软件度量代码行度量与功能点度量的比较代码行依赖于程序设计语言，功能点不依赖程序设计语言。Albert和Jones统计出不同程序设计语言每个功能点与代码行的关系，用LOC/FP表示.表明，Fortran/Ada=1.4,4GL/traditionallanguage=3~52.1软件度量目录2.1软件度量2.2软件项目估算2.3软件质量度量2.4软件复杂性度量2.5软件可靠性度量2.6软件开发过程的管理2.7软件过程及软件成熟度模型CMM2.8软件项目管理的CASE工具2.2软件项目估算意义

软件开发成本占总成本的比例很大，客户和项目管理人员都十分重视软件项目的成本估算。然而，软件是逻辑产品，涉及人、技术、环境、政策等多因素，在项目完成之前很难估准确算出项目的开销。参照已经完成的类似项目；将大项目分成若干小项目，再汇总；将软件项目按生存周期分解，分别估算出软件项目成本和在开发各个阶段的工作量和成本，再汇总；根据实验或历史数据给出软件项目工作量或成本的经验估算公式。常用的四种估算方法：2.2软件项目估算代码行、功能点和工作量估算采用上述四种估算的方法可以估算出LOC或FP的乐观值a,悲观值b,一般值m。根据

e=(a+4m+b)/6得出期望值。希望LOC,FP落在[a,b]之外的概率极小。Ex:软件项目规模FP=310;生产率pf

=5.5FP/PM,则工作量估算

E=310/5.5=56.2.2软件项目估算经验估算模型一：CoCoMo模型从以前的项目的实际数据导出，“从前的”，“局部的”，有一定的参考价值。1981年Boehm提出了“构造性成本模型”（ConstructiveCostModel,CoCoMo）.在静态、单变量模型基础上构造出来的。2.2软件项目估算基本CoCoMo：用于系统开发的初期，估算整个系统的工作量（包括维护）和软件开发所需要的时间；中间CoCoMo：用于估算各个子系统的工作量和开发时间；详细CoCoMo：用于估算独立的软部件，如系统内部的各个模块。2.2软件项目估算基本CoCoMo模型(1)静态、单变量模型，具有如下形式：E=a(KLOC)bD=cEdE:工作量，单位人月（PM）D:开发时间，单位是月KLOC：项目的代码行估计值，单位是千行代码a,b,c,d,是常数（齐治昌《软件工程》P31fig2.9）2.2软件项目估算基本CoCoMo模型(2)模型给出了代码行数、工作量、工作量与开发时间之间的函数关系，Boehm将软件划分为组织型、半独立型、和嵌入型三类，选取相应的a,b,c,d.2.2软件项目估算中间CoCoMo模型以基本CoCoMo模型为基础，在工作量估计公式中乘以工作量调节因子EAF。E=a(LOC)b

EAFLOC：项目的代码行数a,b

：常数,见P38fig2.10工作量调节因子与软件产品属性、计算机属性、人员属性、项目属性有关。2.2软件项目估算软件产品属性：软件可靠性、软件复杂性、数据库规模计算机属性：程序执行时间、程序占用内存的大小、软件开发环境的变化、软件开发环境的响应速度。人员属性：分析员的能力、程序员的能力、有关应用领域的经验、开发环境的经验、程序设计语言的经验。项目属性：软件开发方法的能力，软件工具的质量和数量、软件开发的进度要求。中间CoCoMo模型

—同工作量调节因子相关的属性(1)2.2软件项目估算

上述属性共15各要素，每个要素调节因子Fi

(I=1,2,~15):很低、低、正常、高、很高、极高六种，正常时Fi

＝1，Fi

=1,0.7~1.66,{0.70,0.85,1.00,1.15,1.30,1.65}.中间CoCoMo模型

—同工作量调节因子相关的属性(2)2.2软件项目估算中间CoCoMo模型

—同工作量调节因子相关的属性(3)调节因子集的定义和调节因子定值是由统计结果和经验决定的。不同的开发组织在不同历史时期，随着环境的变化，数据会变化。中间CoCoMo不仅可以估算开发软件产品的工作量，还可以比较各种开发方案对工作连的影响。2.2软件项目估算经验估算模型二：Putnam模型1978，Putnam提出了大型软件项目（>30persons）估算模型。该模型是动态、多变量的，适用于软件开发的各个阶段，以实测数据为基础，导出p40fig2.3的工作量分布曲线。你从中可以看出什么信息？与著名的Rayleigh-Norden曲线形状相似，描述了开发工作量、开发时间和软件代码行数之间的关系。2.2软件项目估算Putnam模型－－方程式（1）L:源程序代码行数；td:开发时间；Ck:技术状态常数，（2000：比较差的软件开发环境:没有方法学的支持，缺乏对文档的评审，用批处理方式；8000：一般的软件开发环境:有方法学的支持，有适宜的文档和评审，采用交互处理方式；11000比较好的软件开发环境：采用CASE环境）。Putnam模型－－方程式（2）E:工作量2.2软件项目估算

td:对应于R-N的最大值，表示软件交付时的工作量最大，参与的人最多。当工作量估算出后，利用每人每年的开销，估算成本。2.2软件项目估算工作量与时间的关系工作量与时间不是线性关系，可以在不同阶段改变人数。工作量与交货时间4次方成反比，提前10%，增加52%的工作量，降低了软件开发的生产率。2.2软件项目估算

Putnam模型揭示了软件项目的工作量、开发时间和程序代码长度的关系，但没有反映软件产品属性、软件项目属性、软件开发人员的属性、计算机硬件资源属性，等。所以此模型是对软件项目成本的粗糙估算。2.2软件项目估算目录2.1软件度量2.2软件项目估算2.3软件质量度量2.4软件复杂性度量2.5软件可靠性度量2.6软件开发过程的管理2.7软件过程及软件成熟度模型CMM2.8软件项目管理的CASE工具软件质量概述－定义软件质量（ANSI标准定义）是软件产品或服务的特性和特征的整体，它取决于满足给定需要的能力产品的价值取决于产品的质量，软件质量的特性是多方面的。

2.3软件质量度量软件质量标准具备满足给定需求的特性及特征的总体能力软件拥有所期望的各种属性组合程度用户认为软件满足他们综合期望的程度软件组合特性可以满足用户期望需求的程度

2.3软件质量度量软件质量概述－－特征与明确确定的功能和性能需求的一致性。即软件需求是质量度量的基础，缺少与需求的一致性就无质量可言。与明确成文的开发标准的一致性。不遵循专门的开发标准，将导致软件质量低劣。与所有专业开发的软件所期望的隐含的特性的一致性。忽视软件隐含的需求，软件质量将不可信。

2.3软件质量度量软件质量概述－－软件质量模型软件质量的度量模型1976年，Boehm第一次提出了软件质量度量的层次模型。1978年，Walters和McCall等人提出了从软件质量要素、准则到度量的三个层次式的模型。p421985年，ISO建议软件质量模型由三层组成：高层：软件质量需求评价准则（SQRC）中层：软件质量设计评价准则（SQDC）低层：软件质量度量评价准则（SQMC）

2.3软件质量度量McCall软件质量模型McCall质量度量模型框架面向管理的产品质量决定产品质量的软件属性定量化度量软件属性使用单位自行制定SQDC可跟踪性完备性一致性准确性容错性简单性模块独立性通用性可扩充性自检(工具)性自描述性执行效率存储效率存取控制存取审查操作性可训练性通信性软件系统独立性机器独立性通信共享性数据共用性简明性SQRC正确性可靠性效率可维护性SQRC安全性可使用性灵活性互连性ISO软件质量度量模型SQMC在软件的众多质量特性之间，质量特性与质量子特性之间存在着有利的影响和不利的影响。表12-3给出了软件的各种质量特性之间的关系。包括有利和不利的影响关系。表12-4给出了软件质量特性同质量子特性之间的关系。包括有利和不利的影响关系。软件质量特性之间的竞争

2.3软件质量度量A质量特性与质量子特性之间的关系p44质量特性之间有利和不利的影响目录2.1软件度量2.2软件项目估算2.3软件质量度量2.4软件复杂性度量2.5软件可靠性度量2.6软件开发过程的管理2.7软件过程及软件成熟度模型CMM2.8软件项目管理的CASE工具McCabe复杂性度量法由McCabe于1976年提出Halstead的软件科学由Halstead于1977年提出软件质量的度量和评价－－两种传统的软件复杂度度量方法2.4软件复杂性度量程序的复杂性很大程度上取决于程序控制流的复杂性。单一的顺序程序结构最简单，循环和选择所构成的环路越多，程序就越复杂。McCabe复杂性度量法TJ.McCabe，1976，提出了基于程序拓扑结构的软件复杂性度量模型。2.4软件复杂性度量1.画出程序图

McCabe度量法步骤（1）afbihegcd(a)程序流程图abchgifed(b)程序图2.4软件复杂性度量McCabe度量法步骤（2）1.计算线性无关闭环数V(G)=e-n+1*其中e是结构图中弧的条数，n是结构图的节点数。abchgifed(b)程序图V(G)=11-9+1=32.4软件复杂性度量McCabe度量法的原理和结论

v(G)等于结构图中有界或无界的封闭区域的个数。当程序中的分支结构数和循环结构数增加时，程序结构将复杂，v(G)增大。v(G)的值不要大于10，否则模块内部结构就会变得复杂，给编码带来困难。在结构化程序中，力争控制流从高层指向低层，反之，否则会增加封闭区域的个数。2.4软件复杂性度量

Halstead复杂性度量法20世纪70年代初，M.Halstead从统计学和心理学的角度研究软件复杂性问题。该方法的基本思路是根据程序中可执行代码行的操作符和操作数的数目来计算程序的复杂性，一般来说，操作符和操作数的数目越大程序就越复杂。2.4软件复杂性度量目录2.1软件度量2.2软件项目估算2.3软件质量度量2.4软件复杂性度量2.5软件可靠性度量2.6软件开发过程的管理2.7软件过程及软件成熟度模型CMM2.8软件项目管理的CASE工具2.5软件可靠性度量可靠性评估（Softwarereliabilityassessment，r（t））：根据软件系统可靠性结构（单元与系统间可靠性关系）、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。软件的可靠性关系到整个系统的成败软件定义：系统连续运行某段时间的概率软件修复排除软件代码中的错误。包括：发现错误、纠正错误、测试和系统重新启动。可以降低程序故障率，提高软件可靠性。2.5软件可靠性度量不可修复系统：不允许停止程序运行的系统，如空管系统，反之为可修复系统。软件修复时间：随机变量，在可靠性分析中，使用平均修复时间的概念。2.5软件可靠性度量

A（t）,系统在t时刻正常运行的概率。

A（250）=0.95.与R(250)=0,95.的区别。通常A（t）≥R（t）。对于不可修复系统，A（t）=R（t）系统有效性2.5软件可靠性度量测量软件有效性的方法（1）

（1）n台相同的计算机硬件系统处理若干组相同或不同的输入数据，如果发现故障，停机检修，修复后重新启动，t时刻如果有m(t)台机器出现故障。M(0)=0.2.5软件可靠性度量（2）系统在稳态运行过程中，仔细记录一个程序运行的有效时间tuj和失效时间tdi，则程序在稳态运行的有效性：测量软件有效性的方法（2）

（3）当系统处于稳态时，程序正常运行时间的平均值也是程序平均故障间隔tu时间(MTBF),程序平均停机时间td也是程序平均修复时间，于是系统稳态时的程序有效性：A=MTBF/(MTBF+MTTR)测量软件有效性的方法（3）

第一种方法便于理解有效性的概念，但多数场合不能用；第二种方法可以度量已经投入运行的程序系统的有效性。第三种方法可以用在软件开发阶段。测量软件有效性方法的使用目录2.1软件度量2.2软件项目估算2.3软件质量度量2.4软件复杂性度量2.5软件可靠性度量2.6软件开发过程的管理2.7软件过程及软件成熟度模型CMM2.8软件项目管理的CASE工具2.6软件开发过程的管理

--风险分析有风险、甚至是灾难性的。涉及思想、概念、行为、地点、时间等诸多因素。什么风险可以导致项目的彻底失败？顾客需求、环境、时间、成本会对项目产生什么影响？采取什么措施可以减少风险？

风险分析软件工程中的风险分析包括：风险标识风险估算风险评价风险管理A)风险标识系统地确定对项目计划（估算、进度、资源分配）的威胁通过识别一直的或可预测的风险，就能避开或驾驭风险。

风险分析风险的分类从宏观上，风险分为项目风险：潜在的预选、进度、组织、资源、用户和需求方面的问题，复杂性、规模的不确定性和结构的不确定性也构成项目的风险。技术风险：质量、交付期、设计、实现、接口、检验和维护；此外，规格说明书的多义性、技术的不确定性、技术陈旧。原因：问题的解决比预想的要复杂得多。商业风险：市场不需要、不符合公司的软件产品战略、销售部门不知道如何推销、失去上级部门的支持、预算风险。识别风险最好的方法是提出一组问题帮助项目计划人员了解项目和技术方面有那些风险。Boehm“风险项目检测表”肯定—0，反之—5，中间2，3，4。值大风险大。识别风险

风险分析B)风险估算从两个方面估价每种风险：估计风险发生的可能性与风险相关的问题出现后会产生的结果。

风险分析项目计划人员、管理人员、技术人员在一起，进行4种估计活动：建立一个尺度来表明风险发生的可能性；描述风险的后果估计风险对项目和产品的影响；指明风险估计的正确性以便消除误解；风险评估活动c)风险评价使用三元组[Ri,li,xi]Ri是风险,li是风险出现的可能性,xi是风险的影响。一个对风险评价很有用的技术就是定义风险参照水准。对于大多数软件项目来说，成本、进度和性能就是三种典型的风险参照标准。

风险分析D)风险管理为了执行风险驾驭和监控，必须考虑与每个风险相关的三员组[风险描述、风险发生概率、风险影响]，它们构成管理奉贤步骤的基础。

风险分析2.6软件开发过程的管理

--进度安排比成本估算更重要，可能造成市场的流失。软件开发项目的进度安排有两种考虑方式：系统交付期已经确定，软件必须在规定期限内完成。经常遇到，如不能按时完成用户会不满意，甚至要求赔偿经济损失，所以必须在规定期限内合理分配人力和安排进度。系统交付期大致确定，开发部门自己确定软件交付期。可以很好合理利用资源。任务分配、人力资源分配、时间分配要与工期进度协调：成立软件开发小组，人数2~8。任务的分解和并行化.工作量分布：分析和设计40%~50%；编码15%~20%；测试和调试30%~40%。工程进度安排：40-20-40规则可以作为一个指南fig2-13.2.6软件开发过程的管理

--进度安排

软件项目的人员组织大型软件工程时间长，为了提高工作效率、保证质量，必须进行人员组织分工。软件开发人员的个人素质与能力差异很大；软件是智力产品，不易理解，不易维护；参加人员组织起来，发挥最大的工作效率。2.6软件开发过程的管理

--进度安排按树形结构组织软件开发人员主程序员制民主制层次制主程序员制小组核心是一位主程序员、2~5位技术员，1位后援工程师组成。主程序员：小组全部技术活动的计划、协调、审查工作，还负责设计和实现项目的关键部分；技术员：负责项目的具体设计和开发，文档资料的编写。后援工