软件工程导论(第13章).ppt
《软件工程导论(第13章).ppt》由会员分享，可在线阅读，更多相关《软件工程导论(第13章).ppt（70页珍藏版）》请在冰点文库上搜索。
第13章软件项目管理,2,大型软件工程项目的失败-才使人们逐渐认识到软件项目管理的重要性和特殊性。
失败的原因-不是软发工程师无能，而主要是管理不善。
所谓管理-就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。
软件项目管理-先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。
软件项目管理-从一组项目计划活动开始，其基础是工作量估算和完成期限估算。
3,13.1估算软件规模,13.1.1代码行技术代码行技术是比较简单的定量估算软件规模的方法。
为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。
每个人都估计程序的最小规模（a）、最大规模（b）和最可能的规模（m），分别算出这3种规模的平均值，再用下式计算程序规模的估计值L=单位是代码行数（LOC），或是千行代码数（KLOC）,4,代码行技术的主要优点：
代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。
代码行技术的缺点：
源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。
为了克服代码行技术的缺点，人们又提出了功能点技术。
5,13.1.2功能点技术功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。
这种方法用功能点（FP）为单位度量软件规模。
1.信息域特性功能点技术定义了信息域的5个特性：
（1）输入项数（Inp）：
用户向软件输入的项数，这些输入给软件提供面向应用的数据。
输入不同于查询，后者单独计数，不计入输入项数中。
（2）输出项数（Out）：
软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。
报表内的数据项不单独计数。
（3）查询数（Inq）：
查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。
（4）主文件数（Maf）：
逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。
（5）外部接口数（Inf）：
机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。
6,2.估算功能点的步骤
（1）计算未调整的功能点数UFP首先，把产品信息域的每个特性（即Inp、Out、Inq、Maf和Inf）都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。
然后，用下式计算未调整的功能点数UFP：
UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf其中，ai（1i5）是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1（见书307页）所示。
7,
（2）计算技术复杂性因子TCF这一步骤度量14种技术因素对软件规模的影响程度。
这些因素包括高处理率、性能标准（例如，响应时间）、联机更新等，在表13.2（见书307页）中列出了全部技术因素，并用Fi（1i14）代表这些因素。
根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。
然后，用下式计算技术因素对软件规模的综合影响程度DI：
DI=技术复杂性因子TCF由下式计算：
TCF=0.65+0.01DI因为DI的值在070之间，所以TCF的值在0.651.35之间。
8,（3）计算功能点数FP用下式计算功能点数FP：
FP=UFPTCF功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。
但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。
9,13.2工作量估算软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（pm）。
支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。
10,13.2.1静态单变量模型这类模型的总体结构形式如下：
E=A+B（ev）C其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量（KLOC或FP）。
下面给出几个典型的静态单变量模型。
1.面向KLOC的估算模型
（1）Walston_Felix模型:
E=5.2（KLOC）0.91
（2）Bailey_Basili模型:
E=5.5+0.73（KLOC）1.16（3）Boehm简单模型:
E=3.2（KLOC）1.05（4）Doty模型（在KLOC9时适用）:
E=5.288（KLOC）1.047,11,2.面向FP的估算模型
（1）Albrecht&Gaffney模型E=-13.39+0.0545FP
（2）Maston,Barnett和Mellichamp模型E=585.7+15.12FP从上面列出的模型可以看出，对于相同的KLOC或FP值，用不同模型估算将得出不同的结果。
主要原因是，这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限。
因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（例如，修改模型常数）估算模型。
12,13.2.2动态多变量模型动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收集的生产率数据推导出来的。
该模型把工作量看作是软件规模和开发时间这两个变量的函数。
动态多变量估算模型的形式如下：
E=（LOCB0.333/P）3（1/t）4（13.2）其中，E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=515），B=0.16,对于超过70KLOC的程序，B=0.39;,P是生产率参数，它反映了下述因素对工作量的影响：
总体过程成熟度及管理水平；使用良好的软件工程实践的程度；使用的程序设计语言的级别；软件环境的状态；软件项目组的技术及经验；应用系统的复杂程度。
开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。
可以从历史数据导出适用于当前项目的生产率参数值。
从（13.2）式可以看出，开发同一个软件（即LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。
13,13.2.3COCOMO2模型,COCOMO是构造性成本模型（constructivecostmodel）的英文缩写。
1981年Boehm在软件工程经济学中首次提出了COCOMO模型。
1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。
COCOMO2给出了3个层次的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。
这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。
这3个层次的估算模型分别是
（1）应用系统组成模型。
这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。
（2）早期设计模型。
这个模型适用于体系结构设计阶段。
（3）后体系结构模型。
这个模型适用于完成体系结构设计之后的软件开发阶段。
14,下面以后体系结构模型为例，介绍COCOMO2模型。
该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数：
E=（13.3）其中:
E是开发工作量（以人月为单位），A是模型系数，KLOC是估计的源代码行数（以千行为单位），B是模型指数，fi（i=117）是成本因素。
每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。
这些成本因素对任何一个项目的开发工作量都有影响，即使不使用COCOMO2模型估算工作量，也应该重视这些因素。
Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。
表13.3（见书310页）列出了COCOMO2模型使用的成本因素及与之相联系的工作量系数。
15,13.3进度计划,项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。
为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。
软件项目的进度安排是通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。
进度计划将随着时间的流逝而不断演化。
在项目计划的早期，首先制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。
随着项目的进展，把宏观进度表中的每个条目都精化成一个详细进度表，从而标识出完成一个活动所必须实现的一组特定任务，并安排好了实现这些任务的进度。
13.3.1估算开发时间,Brooks规律：
向一个已经延期的项目增加人力，只会使得它更加延期。
随着开发小组规模的扩大，个人生产率将下降，以至开发时间与从事开发工作的人数并不成反比关系。
出现这种现象主要有下述两个原因：
当小组变得更大时，每个人需要用更多的时间与组内其他成员讨论问题、协调工作，因此增加了通信开销。
如果在开发过程中增加小组人员，则最初一段时间内项目组总生产率不仅不会提高反而会下降。
这是因为新成员在开始时不仅不是生产力，而且在他们学习期间还需要花费小组其他成员的时间。
16,项目组规模与项目组总生产率的关系,当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。
通信需花费时间和代价，会引起软件错误增加，降低软件生产率。
若两个人之间需要通信，则称在这两个人之间存在一条通信路径。
如果一个软件开发小组有n个人，每两人之间都需要通信，则总的通信路径有n（n-1）/2（条）。
17,设一个人单独开发软件，生产率是5000行人年。
若4个人组成一个小组共同开发这个软件，则需要6条通信路径。
若在每条通信路径上耗费的工作量是250行人年。
则小组中每个人的软件生产率降低为500062504=5000375=4625行人年。
从上述分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件项目，一个人单独开发，时间太长。
因此软件开发小组是必要的。
但是，开发小组不宜太大，成员之间避免太多的通信路径。
在开发进程中，切忌中途加人，避免太多的生产率损失。
18,任务的确定与并行性,当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。
软件开发进程中设置许多里程碑。
里程碑为管理人员提供了指示项目进度的可靠依据。
软件工程项目的并行性提出了一系列的进度要求。
因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。
项目负责人应注意构成关键路径的任务，即若要保证整个项目能按进度要求完成，就必须保证这些任务要按进度要求完成。
19,20,13.3.2Gantt图Gantt图（甘特图）是历史悠久、应用广泛的进度计划工具，下面通过一个非常简单的例子介绍这种工具。
第一种方法，前面工序全部完成，再进入下一道工序。
36小时第二种方法，流水作业，1、2、3、4。
23小时第三种方法，流水作业，1、3、2、4。
22小时。
图13.1旧木板房刷漆工程的Gantt图,为了醒目地表示里程碑，可以在Gantt图中加上菱形标记，一个菱形代表一个里程碑，如图8.2所示。
图2标有里程碑的Gantt图,13.3.3工程网络当把一个工程项目分解成许多子任务，并且它们彼此间的依赖关系又比较复杂时，仅仅用Gantt图作为安排进度的工具是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。
工程网络是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间，此外，它还显式地描绘各个作业彼此间的依赖关系。
因此，工程网络是系统分析和系统设计的强有力的工具。
在工程网络中用箭头表示作业（例如，刮旧漆，刷新漆，清理等），用圆圈表示事件（一项作业开始或结束）。
注意，事件仅仅是可以明确定义的时间点，它并不消耗时间和资源。
作业通常既消耗资源又需要持续一定时间。
图13.2是旧木板房刷漆工程的工程网络。
图中表示刮第1面墙上旧漆的作业开始于事件1，结束于事件2。
用开始事件和结束事件的编号标识一个作业，因此“刮第1面墙上旧漆”是作业12。
图13.2旧木板房刷漆工程的工程网络图中：
12刮第1面墙上的旧漆；23刮第2面墙上的旧漆；24给第1面墙刷新漆；35刮第3面墙上旧漆；46给第2面墙刷新漆；47清理第1面墙窗户；58刮第4面墙上旧漆；68给第3面墙刷新漆；79清理第2面墙窗户；810给第4面墙刷新漆；910清理第3面墙窗户；1011清理第4面墙窗户；虚拟作业：
34；56；67；89。
在工程网络中的一个事件，如果既有箭头进入又有箭头离开，则它既是某些作业的结束又是另一些作业的开始。
例如，图13.2中事件2既是作业12（刮第1面墙上的旧漆）的结束，又是作业23（刮第2面墙上旧漆）和作业24（给第1面墙刷新漆）的开始。
也就是说，只有第1面墙上的旧漆刮完之后，才能开始刮第2面墙上旧漆和给第1面墙刷新漆这两个作业。
因此，工程网络显式地表示了作业之间的依赖关系。
在图13.2中还有一些虚线箭头，它们表示虚拟作业，也就是事实上并不存在的作业。
引入虚拟作业是为了显式地表示作业之间的依赖关系。
例如，事件4既是给第1面墙刷新漆结束，又是给第2面墙刷新漆开始（作业46）。
但是，在开始给第2面墙刷新漆之前，不仅必须已经给第1面墙刷完了新漆，而且第2面墙上的旧漆也必须已经刮净（事件3）。
也就是说，在事件3和事件4之间有依赖关系，或者说在作业23（刮第2面墙上旧漆）和作业46（给第2面墙刷新漆）之间有依赖关系，虚拟作业34明确地表示了这种依赖关系。
注意，虚拟作业既不消耗资源也不需要时间。
13.3.4估算进度画出类似图13.2那样的工程网络之后，系统分析员就可以借助它的帮助估算工程进度了。
为此需要在工程网络上增加一些必要的信息。
首先，把每个作业估计需要使用的时间写在表示该项作业的箭头上方。
注意，箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系，它上方的数字才表示作业的持续时间。
其次，为每个事件计算下述两个统计数字：
最早时刻EET和最迟时刻LET。
这两个数字将分别写在表示事件的圆圈的右上角和右下角，如图13.3左下角的符号所示。
图13.3旧木板房刷漆工程的完整的工程网络（粗线箭头是关键路径）,12刮第1面墙上的旧漆；23刮第2面墙上的旧漆；24给第1面墙刷新漆；35刮第3面墙上旧漆；46给第2面墙刷新漆；47清理第1面墙窗户；58刮第4面墙上旧漆；68给第3面墙刷新漆；79清理第2面墙窗户；810给第4面墙刷新漆；910清理第3面墙窗户；1011清理第4面墙窗户；虚拟作业：
34；56；67；89。
事件的最早时刻是该事件可以发生的最早时间。
通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。
计算最早时刻EET使用下述三条简单规则：
考虑进入该事件的所有作业；对于每个作业都计算它的持续时间与起始事件的EET之和；选取上述和数中的最大值作为该事件的最早时刻EET。
事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。
按惯例，最后一个事件（工程结束）的最迟时刻就是它的最早时刻。
其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。
计算最迟时刻LET使用下述三条规则：
考虑离开该事件的所有作业；从每个作业的结束事件的最迟时刻中减去该作业的持续时间；选取上述差数中的最小值做为该事件的最迟时刻LET。
13.3.5关键路径图13.3中有几个事件的最早时刻和最迟时刻相同，这些事件定义了关键路径，在图中关键路径用粗线箭头表示。
关键路径上的事件（关键事件）必须准时发生，组成关键路径的作业（关键作业）的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。
13.3.6机动时间不在关键路径上的作业有一定程度的机动余地实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预计的持续时间长一些，而并不影响工程的结束时间。
一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这个作业的持续时间：
机动时间=（LET）结束-（EET）开始-持续时间对于前述油漆旧木板房的例子，计算得到的非关键作业的机动时间列在表13.6中。
在工程网络中每个作业的机动时间写在代表该项作业的箭头下面的括弧里（参看图13.4）。
在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源又不影响最终竣工时间的进度表。
图13.4旧木板房刷漆工程改进的Gantt图之一,项目进度安排,PERT技术PERT（ProgramEvaluationandReviewTechnique）技术，即计划评审技术1、建立PERT图2、找出关键路径（CriticalPath）3、标出最迟开始时间4、使用PERT图,项目进度安排,项目进度安排,圆框代表一项目开发活动圆框数据代表完成开发活动所需的时间（如月、周等）箭头表示开发活动的顺序上标代表开发活动的起止日期下标代表开发活动的最迟起止日期PERT图的使用：
确保关键路径上的各项活动按时完成。
一项延期，全部延期通过缩短关键路径上的各项活动的时间，缩短整个项目的开发时间对于不在关键路径上的各项活动，可根据需要或调整其起止日期，或延缓进度,13.4.1民主制程序员组,特点成员之间关系平等根据每个人的能力和经验适当分配通过全体人员协商决定项目工作优点同等项目参与权，可以激发大家的创造力，利于攻克难关适用于小规模、能力强、有共同工作经历的团队缺点缺少权威人士，在意见分歧的情况下很难解决,13.4人员组织,13.4.2主程序员组,13.4.3现代程序员组,现代程序员组优缺点,优点将“主程序员”的职责专一化缺点“技术组长”与“行政组长”的职责划分不清不能适应大规模的项目,现代程序员组-组织结构2,能否达到“集思广益”的效果？
改进方案,13.5质量保证,13.5.1软件质量软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。
更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。
48,软件质量因素与产品活动的关系,49,13.5.2软件质量保证措施软件质量保证（softwarequalityassuranceSQA）的措施主要有：
基于非执行的测试（也称为复审或评审），主要用来保证在编码之前各阶段产生的文档的质量；基于执行的测试（即以前讲过的软件测试）,需要在程序编写出来之后进行，它是保证软件质量的最后一道防线；程序正确性证明，使用数学方法严格验证程序是否与对它的说明完全一致。
50,参加软件质量保证工作的人员，可以划分成下述两类：
软件工程师通过采用先进的技术方法和度量，进行正式的技术复审以及完成计划周密的软件测试来保证软件质量。
SQA小组的职责，是辅助软件工程师以获得高质量的软件产品。
其从事的软件质量保证活动主要是：
计划，监督，记录，分析和报告。
简而言之，SQA小组的作用是，通过确保软件过程的质量来保证软件产品的质量。
51,软件质量保证具体措施走查审查测试证明,52,13.6软件配置管理（SCM）SoftwareConfigurationManagement,在开发软件的过程中，变化（或称为变动）既是必要的，又是不可避免的。
但是，变化也很容易失去控制，如果不能适当地控制和管理变化，势必造成混乱并产生许多严重的错误。
软件配置管理是在软件的整个生命期内管理变化的一组活动标识变化；控制变化；确保适当地实现了变化；向需要知道这类信息的人报告变化。
配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。
软件配置管理的目标是，使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。
53,13.6.1软件配置,1.软件配置项计算机程序（源代码和可执行程序）；描述计算机程序的文档（供技术人员或用户使用）；数据（程序内包含的或在程序外的）。
为了开发出高质量的软件产品，软件开发人员不仅要努力保证每个软件配置项正确，而且必须保证一个软件的所有配置项是完全一致的。
54,2.基线IEEE把基线定义为：
已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。
基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。
基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。
基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。
基线的主要属性有：
名称、标识符、版本、日期等。
通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。
55,13.6.2软件配置管理过程,1、标识2、版本控制3、变化控制4、配置设计5、状态报告配置控制是核心：
存取控制（开发库、基线库、产品库）版本控制变更控制产品发布控制,56,13.6.3常用配置管理工具,1、SourceSafeSourceSafe是Microsoft公司推出的配置管理工具，是VisualStudio的套件之一。
SourceSafe是国内最流行的配置管理工具，用户量绝对是第一位。
SourceSafe的优点可以用8个字来概括“简单易用，一学就会”，这个优点是Microsoft继承下来的。
虽然SourceSafe并不是免费的，但是在国内人们以接近于零的成本得到它，网上到处可以下载啊。
当然Microsoft也不在乎这个小不点的软件，它属于“买大件送小件”的角色。
如果你合法地得到VisualStudio，你就得到了免费的SourceSafe。
SourceSafe的主要局限性：
只能在Windows下运行，不能在Unix,Linux下运行。
SourceSafe不支持异构环境下的配置管理，对用户而言是个麻烦事。
这不是技术问题，是微软公司产品战略决定的。
适合于局域网内的用户群，不适合于通过Internet连接的用户群，因为SourceSafe是通过“共享目录”方式存储文件的。
57,2、CVSCVS是ConcurrentVersionSystem（并行版本系统）的缩写，它是著名的开放源代码的配置管理工具。
CVS的官方网站是http:
/www.cvshome.org/。
官方提供的是CVS服务器和命令行程序，但是官方并不提供交互式的客户端软件。
许多软件机构根据CVS官方提供的编程接口开发了各色各样的CVS客户端软件，最有名的当推Windows环境的CVS客户端软件WinCVS。
WinCVS是免费的，但是并不开放源代码。
与SourceSafe相比，CVS的主要优点是：
SourceSafe有的功能CVS全都有，CVS支持并发的版本管理，SourceSafe没有并发功能。
CVS服务器的功能和性能都比SourceSafe高出一筹。
CVS服务器是用Java编写的，可以在任何操作系统和网络环境下运行。
CVS深受Unix和Linux的用户喜爱。
Borland公司的JBuilder提供了CVS的插件，Java程序员可以在JBuilder集成环境中使用CVS进行版本控制。
CVS服务器有自己专用的数据库，文件存储并不采用SourceSafe的“共享目录”方式，所以不受限于局域网，信息安全性很好。
CVS的主要缺点在于客户端软件，真可谓五花八门、良莠不齐。
Unix和Linux的软件高手可
升级会员 