【文档说明】软件工程导论13软件项目管理课件.ppt，共(45)页，377.592 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-44990.html

以下为本文档部分文字说明：

软件工程导论13软件项目管理软件项目管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算经

理管什么？计划预算组织进度标准组织计划预算内容13.1估算软件规模13.2开发工作量估算13.3进度计划13.4人员组织13.5质量保证13.6软件配置管理13.7能力成熟度模型13.1估算软件规模代码行技术这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功

能所需要的源程序行数，把实现每个功能所需要的源程序行数累加起来每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m),分别算出这3种规模的平均值a,b,c之后，再用下式计算程序规模的估计值单位：代码行数(LOC)，千行代码数

(KLOC)优点：代码是所有软件开发项目都有的“产品”，容易计算代码行数缺点：①源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理②用不同语言实现同一个软件所需要的代码行数并不相同这种方6bm4aL

13.1估算软件规模功能点技术：功能点技术依赖对软件信息域特性和软件复杂性的评估结果，估算软件规模。信息域特性①输入项数(Inp)：用户向软件输入的项数，这些输入给软件提供面向应用的数据。②输出项数(Out)：软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和

出错信息等。报表内的数据项不单独计数。③查询数(Inq)：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。④主文件数(Maf)：逻辑主文件(即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件)的数目。⑤外部接口数(In

f)：机器可读的全部接口(例如，磁盘或磁带上的数据文件)的数量，用这些接口把信息传送给另一个系统。13.1估算软件规模功能点技术步骤①计算未调整的功能点数UFP–把lnp、Out、lnq、Maf和Inf分为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数。–计算未调整

的功能点数UFP：UFP=a1lnp+a2Out+a3Inq+a4Maf+a5Inf②计算技术复杂性因子TCF③计算功能点数FP复杂级别特性系数简单平均复杂输入系数a1346输出系数a2457查询系数a3346文件系数a471015接口系

数a5571013.1估算软件规模功能点技术步骤①计算未调整的功能点数UFP②计算技术复杂性因子TCF–这一步度量14种技术因素对软件规模的影响程度；这些因素包括高处理率、性能标准(例如，响应时间)、联机更新等，在表13．2

中列出了全部技术因素，并用Fi，(1i14)代表这些因素。根据软件的特点，为每个因素分配一个从0到5的值–计算技术因素对软件规模的综合影响程度DI：DI=Fi;DI的值在0-70之间–计算技术复杂因子TCF：TCF=0.65+0.01ID；TCF

的值在0.65-1.35之间③计算功能点数FP13.1估算软件规模功能点技术序号Fi技术因数序号Fi技术因数1F1数据通信8F8联机更新2F2分布式数据处理9F9复杂的计算3F3性能标准10F10可重用性4F4高负荷的硬件11F11安装方便5F5高处理率

12F12操作方便6F6联机数据输入13F13可移植性7F7终端用户效率14F14可维护性13.1估算软件规模功能点技术步骤①计算未调整的功能点数UFP②计算技术复杂性因子TCF③计算功能点数FP：FP＝UFP×TCF–功能点数与所用的编程浯言无关–在判断信息

域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。13.2开发工作量估算软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月(pm）大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的没有一个估算模型可以

适用于所有类型的软件和开发环境13.2开发工作量估算静态单变量模型总体结构形式E=A+B(ev)cA、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量(KLOC或FP)动

态多变量模型动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下：E=(LOCB0.333/P)3(1/t)413.2开发工作量

估算静态单变量模型总体结构形式E=A+B(ev)c面向KLOC的估算模型①(1)Walston_Felix模型E=5.2(KLOC)0.91②(2)BaileyBasili模型E=5.5+0.73(KLOC)1.16③(3)Boehm简单模型E=3.2(K

LOC)1.05④(4)Doty模型(在KLOC>9时适用)E=5.288(KLOC)1.0472面向FP的估算模型①(1)Albrecht&Gaffney模型E＝-13.39+0.0545FP②(2)Maston，Barnett和Mellichamp模型E＝585.7+15.12FP

对于相同的KLOC或FP值，用不同模型估算将得出不同的结果。主要原因是①这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限②必须根据当前项目的特点选择适用的估算模型，并且根据需要

适当地调整(例如，修改模型常数)估算模型。13.2开发工作量估算动态多变量模型该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下：E=(LOCB0.333/P)3(1/t)4①E是以人月

或人年为单位的工作量，②t是以月或年为单位的项目持续时间；③B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序(KLOC＝5-15)，B＝0.16，对于超过70KLOC的程序，B=0.39；④P是生产率参数，它反映了下述因素

对工作量的影响：–总体过程成熟度及管理水平–使用良好的软件工程实践的程度–使用的程序设计语言的级别–软件环境的状态–软件项目组的技术及经验–应用系统的复杂程度⑤开发实时嵌入式软件时，P的典型值为200

0；开发电信系统和系统软件时，P=10000；对于商业应用系统来说．P=28000。可以从历史数据导出适用于当前项目的生产率参数值。13.2开发工作量估算COCOMO2模型COCOMO是构造性成本模型(constructivecostmodel)的缩写）COCOMO2给出了3个层次

的开发工作量估算模型①应用系统组成模型：这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。②早期设计模型：这个模型适用于体系结构设计阶段。③后体系结构模型：这个模型适用于完成体系结构设计之后的软件开发阶段。13.2

开发工作量估算COCOMO2模型COCOMO2模型把软件开发工作量表示成代码行数（KLOC）的非线性函数：17E=aKLOCbfii=1E是开发工作量（以人月为单位）a是模型系数KLOC是估计的源代码行数

（以千行为单位）b是模型指数：这个模型使用5个分级因素Wi，(1≤i≤5)；其中每个因素都划分成从甚低(Wi=5)到特高(Wi＝0)的6个级别。然后用下式计算b的数值：b=1.01+0.01Wi，见教材P311fi（i＝1-17）是成本因素：产品因素、平台因素、人员

因素和项目因素等4类（见表13.3）13.3进度计划13.3.1估算开发时间13.3.2Gantt图13.3.3工程网络13.3.4估算工程进度13.3.5关键路径13.36机动时间13.3进度计划例:重新油漆一座矩形木板房，具体工作

可分为三步完成。首先刮掉旧漆，然后刷上新漆，最后清理溅在窗户上的油漆。15名工人去完成这项工作，规定有：5把刮漆用的刮板；5把刷漆用的刷子；5把清除溅在窗户上油漆用的小刮刀。板房的第2、4两面墙的长度为第1、3两面墙的长度的2倍。2134工序时间

墙壁刮旧漆刷新漆清理1(3)2(4)3(6)1(2)2(4)4(8)6(12)2(4)13.3进度计划13.3.2Gantt图解决方案顺序执行：首先刮掉四面墙壁上的旧漆，然后给每面墙都刷上新漆，最后清除溅在每个窗户上的油漆；因为15名工人中由于工具的限制，所安排的工作在任何时候都有

10名工人闲着没活干，完成全部工程需要36小时。流水线：另一种做法是采用“流水作业法”，即先由5名工人用刮板刮掉第一面墙上的旧漆(另外10名工人休息)，当第一面墙刮净后，另外5名工人立即用刷子给这面墙刷新漆(与此同时拿刮板的5名工人转去刮第二面墙上的旧漆)，一旦刮旧漆的工人转到第三面墙而且刷新

漆的工人转到第二面墙以后，余下的5名工人立即拿起刮刀去清除溅在第一面墙窗户上的油漆。这种安排每个工人都有活干，可在22小时结束全部工程。13.3进度计划13.3.2Gantt图246810121416182022刮旧漆刷

新漆清理时间作业旧木板房刷漆工程的Gantt图13.3进度计划13.3.3工程网络工程网络是判定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间。它还显式地描绘各个作业彼此间的依关

系。①在工程网络图中，用箭头表示作业②用圆圈表示事件(一项作业开始或结束)③事件仅仅是可以明确定义的时间点，它并不消耗时间和资源。作业通常既消耗资源又需要持续一定的时间13.3进度计划13.3.3工程网络个人成果，妥善保存，请勿传播1235810114679刮旧漆刷新漆清理个人成果，妥

善保存，请勿传播GanttCharttw12345678ABCD当前进度优点：简单，能动态地反映开发进展。缺点：难以反映多个任务间的逻辑关系。Gantt图个人成果，妥善保存，请勿传播持续时间LastingTime机动时间SlackTime编号EarliestStartTimeLatest

StartTime012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)686678886975(1)标出LastingTime(2)标出EST:=从起点始，所有进入事件的EST+L

T中最大的(3)标出LST:=从终点(EST=LST)始，所有离开事件的LSTLT中最小的(4)标出ST:=终点LST起点ESTLT(5)标出CriticalPath:即EST=LST的所有事件组成的路

径工程网络图13.4人员组织自学13.5质量保证软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。影响软件质量的主要因素这些因素是从管理角度对软件质量的度量分为：产品运行，产品修改和产品转移。图13.9描绘了软件质量因素和上述3种倾向(或产品活动)之间的关

系表13.7列出了软件质量因素的简明定义13.5质量保证个人成果，妥善保存，请勿传播产品运行Operation产品修改Revision产品转移Transition可理解性（我能理解它吗？）可维修性（我能修复它吗？）灵活性（我能改变它吗？）可测试性（我能测

试它吗？）可移植性（我能在另一台机器上使用它吗？）可再用性（我能再用它的某些部分吗？）互运行性（我能把它和另一个系统结合吗？）正确性（它按我的需要工作吗？）健壮性（对意外环境它能适当地响应吗？）效率（完成预定

功能时它需要的资源多吗？）完整性（它是安全的吗？）可用性（我能使用它吗？）风险（能按预定计划完成它吗？）软件质量因素与产活动的关系13.5质量保证软件质量保证措施基于非执行的测试（也称为复审或评审）：主

要用来保证在编码之前各阶段产生的文档的质量；基于执行的测试（即以前讲过的软件测试）：需要在程序编写出来之后进行，它是保证软件质量的最后一道防线；程序正确性证明:使用数学方法严格验证程序是否与对它的说明完全一致。13.5质量保证软件质量保

证人员软件工程师通过采用先进的技术方法和度量，进行正式的技术复审以及完成计划周密的软件测试来保证软件质量。SQA小组的职责，是辅助软件工程师以获得高质量的软件产品。①其从事的软件质量保证活动主要是：计划，监督，记录，分析和报告。②简而言之．SQA小组的作用是，

通过确保软件过程的质量来保证软件产品的质量．13.6软件配置管理任何软件开发都是迭代过程，在设计过程会发现需求说明书中的问题，在实现过程又会暴露出设计中的错误……。随着时间推移客户的需求也会或多或少发生变化，在开发软件的过程中，变化(或称为变动)既是必要的，又是不可避免的。软件配置管理是在

软件的整个生命期内管理变化的一组活动。具体地说，这组活动用来：①标识变化；②控制变化；③确保适当地实现了变化；④向需要知道这类信息的人报告变化。13.6软件配置管理软件配置项软件过程的输出信息可以分为3类:计算机程序(源代码

和可执行程序);描述计算机程序的文档(供技术人员或用户使用)；数据(程序内包含的或在程序外的)。我们把它们统称为软件配置，而这些项就是软件配置项。软件配置管理看作是应用于整个软件过程的软件质量保证活动，是专门用于管理变化的软

件质量保证活动。13.6软件配置管理2．基线基线是一个软件配置管理概念，它有助于我们在不严重妨碍合理变化的前提下来控制变化。IEEE把基线定义为：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。基线就是通过了正式复审的软件配置项

。①在软件配置项变成基线之前，可以迅速而非正式地修改它。一旦建立了基线之后，虽然仍然可以实现变化，但是，必须应用特定的、正式的过程(称为规程)来评估、实现和验证每个变化。13.6软件配置管理软件配置管理过程软件配置

管理是软件质量保证的重要一环，它的主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告具体来说，软件配置管理主要有5项任务：标识、版本控制、变化控制、

配置审计和报告。13.6软件配置管理1．标识软件配置中的对象为了控制和管理软件配置项，必须单独命名每个配置项，然后用面向对象方法组织它们可以标识出两类对象：基本对象和聚集对象(可以把聚集对象作为代表

软件配置完整版本的一种机制)。①基本对象是软件工程师在分析、设计、编码或测试过程中创建出来的“文本单元”，例如，需求规格说明的一个段落、一个模块的源程序清单或—组测试用例。②聚集对象是基本对象和其他聚集对象的集合。每个对象都有一组能惟一地标识它的特征：名字、描述、资源表和“实现”。对象名是无二义

性地标识该对象的一个字符串。13.6软件配置管理演化图13.6软件配置管理2．版本控制版本控制联合使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制技术，用户能够通过选择适当的版本来指

定软件系统的配置。实现这个目标的方法是，把属性和软件的每个版本关联起来，然后通过描述一组所期望的属性来指定和构造所需要的配置。“属性”，既可以简单到仅是赋给每个配置对象的具体版本号，也可以复杂到是一个布尔变量串，其指明了施加到系统上的功能变化的具体类型。13.6软件配置管理版本和

变体13.6软件配置管理3．变化控制典型的变化控制过程如下：首先评估该变化在技术方面的得失、可能产生的副作用、对其他配置对象和系统功能的整体影响以及估算出的修改成本。评估的结果形成“变化报告”，该报告供“变

化控制审批者”审阅。对变化的状态和优先级做最终决策。把要修改的对象从项目数据库中“提取(checkout)”出来，进行修改并应用适当的SQA活动。把修改后的对象“提交(checkin)”进数据库．并用适当的版本控制机制创建该软件的下一个版本。13.6

软件配置管理访问和同步控制13.6软件配置管理4．配置审计为了确保适当地实现了所需要的变化，通常从下述两方面采取措施：①正式的技术复审；②软件配置审计。正式的技术复审关注被修改后的配置对象的技术正确性。复审者审查该对象以确定它与其他软件配置项的一致性，并检查是否有遗漏或副作用．

软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征(例如，修改时是否遵循了软件工程标准，是否在该配置项中显著地标明了所做的修改，是否注明了修改日期和修改者，是否适当地更新了所有相关的软件配置项，是否遵循

了标注变化、记录变化和报告变化的规程)，而成为对正式技术复审的补充。13.6软件配置管理5．状态报告配置状态报告回答下述问题：①发生了什么事?②谁做的这件事?③这件事是什么时候发生的?④它将影

响哪些其他事物?配置状态变化对大型软件开发项目的成功有重大影响。当大量人员在一起工作时，可能一个人并不知道另一个人在做什么。两名开发人员可能试图按照相互冲突的想法去修改同一个软件配置项；软件工程队伍可能耗费几个人月的工作量根据过时的硬件规格

说明开发软件，察觉到所建议的修改有严重副作用的人可能还不知道该项修改正在进行。配置状态报告通过改善所有相关人员之间的通信，帮助消除这些问题。13.7能力成熟度模型美国卡内基梅隆大学软件工程研究所在美国国防部资助下于20世纪80年代末建立的用于评价软件机构的软件过程能力成熟度的模型。最

初，建立此模型的目的主要是，为大型软件项目的招投标活动提供一种全面而客观的评审依据，后来此模型又同时被应用于许多软件机构内部的过程改进活动中。13.7能力成熟度模型能力成熟度模型的基本思想是由于问题是由我们管理软件过程的方

法不当引起的，所以新软件技术的运用并不会自动提高软件的生产率和质量。能力成熟度模型有助于软件开发机构建立一个有规律的、成熟的软件过程。改进后的软件过程将开发出质量更好的软件，使更多的软件项目免受时间和费用超支之

苦。软件过程包括各种活动、技术和工具，它实际上既包括了软件开发的技术方面又包括了管理方面。CMM的策略是，力图改进对软件过程的管理，而在技术方面的改进是其必然的结果。13.7能力成熟度模型能力成熟度的5个等级从低到高依次是初始级(又称为1

级)，可重复级（又称为2级）已定义级(又称为3级)，已管理级(又称为4级)优化级(又称为5级)。一些统计数字表明，提高一个完整的成熟度等级大约需要花18个月到3年的时间但是从第1级上升到第2级有时要花3年甚至5年时间这说明要向一个迄今仍处于混乱的和被动的行动方式的软件机构灌输系统化的

方式，将多么困难。