软件工程 第12章 软件项目计划与管理.ppt

《软件工程 第12章 软件项目计划与管理.ppt》由会员分享，可在线阅读，更多相关《软件工程 第12章 软件项目计划与管理.ppt（85页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第十二章 软件项目计划与管理第十二章第十二章 软件项目计划与管理软件项目计划与管理【本章重点】软件项目的计划与组织软件成本估算及控制方法软件工程标准与软件文档【学习目标】掌握软件项目计划与组织方法理解软件成本估算及控制方法了解软件工程标准与软件文档12.1 软件项目的计划与组织12.2 软件成本估算及控制12.3 软件工程标准与软件文档12.4 小结12.5 习题【教学内容】12.1 软件项目的计划与组织12.1.1 软件开发的进度计划12.1.2 软件开发的组织机构12.1.3 软件人员配备12.1.1 软件开发的进度计划 不论从事何种技术性项目，实际情况都是在实现一个大目标之前往往必须完成

2、数以百计的小任务（也成为作业）。这些任务中有一些是处于“关键路径”之外的，其完成时间如果没有严重拖后，则不会影响整个项目的完成时间；其他任务则处于关键路径之中，如果这些“关键任务”的进度拖后，则整个项目的完成日期就会拖后。没有一个普遍适用于所有软件项目的任务集合，因此，一个有效的软件过程应该定义一组适合于所从事的项目的“任务集合”。一个任务集合包括一组软件工程工作任务、里程碑和可交付的产品。为一个项目所定义的任务集合，必须包括为最终获得高质量的软件产品而应该完成的所有工作，但是同时又不能让项目组负担不必要的工作。软件项目的进度安排是一项活动，它通过把工作量分配给特定的软件工程任务，并规定完成各

3、项任务的起、止日期，从而将估算的工作量分布于计划好的项目持续期内。1 1交付日期的确定交付日期的确定 交付日期的确定对软件开发项目的进度安排至关重要。一般有以下两种考虑方式：系统最终交付使用的日期已经确定。只确定了大致的期限，最后交付使用的日期由软件开发 机构根据具体情况确定。这种方式能够对软件开发任务进行细微的分析，并能够最好地利用资源和合理地分配工作量。在实际工作中，多为第一种情况。而这种情况大多是由软件开发机构以外的某些人决定，并强加给软件开发机构的项目开发者和管理者。在软件行业中，这种过于不现实的项目完成期限已司空见惯。有时决策者还认为这样的交付日期是十分合理的。但是，常识告诉我们合理

4、与否必须由完成工作的人们来判断。12.1.1 软件开发的进度计划2 2进度安排的基本原则进度安排的基本原则 对软件工程项目的进度安排，上面已经讨论过，可以从两个不同的视角来观察。一个是基于计算机系统的最终发布日期已经确定，而且不能改变。软件开发机构在这个约束下把工作量分布在预先确定的时间框架内；另一个是，假定大致的时间界限已经讨论过，但是最终的发布日期由软件开发机构来设定。通常第一种情况发生的频率远远高于第二种情况。与软件工程的其他领域一样，有如下一些基本原则可以指导软件项目的进度安排：划分 必须把项目划分成若干个可以管理的活动和任务，这些活动和任务 由所采用软件过程模型定义。为了完成项目划分

5、，对产品和过程都需要 进行分解。相互依赖性 必须确定划分出的各个活动或任务之间的相互依赖性。某些任务必 须顺序完成，而其他的任务可以并发进行。有些活动只有在其他活动产生的工作产品完成之后才能够开始，而其他的活动可以独立地进行。12.1.1 软件开发的进度计划时间分配 必须给每个任务都分配一定数量的工作单位（例如，若干人天的工作量）。此外，必须为每个任务都指定开始日期和结束日期，在确定这些日期时既要考虑各个任务之间的相互依赖性，又要考虑开发人员每日工作时间的长短（全职还是兼职）。工作量确认 每个项目都是指定数量的人员参与工作。在制定进度计划时，项目管理者必须确保在任意时段中分配给任务的人员数量，

6、不超过项目组中的人员数量。例如，为一个项目分配了3名人员（即每天可分配的工作量伟3人/天），如果在某一天中需要完成7项并发任务，每个任务需要0.5人/天的工作量，则在这种情况下所分配的工作量就大于可供分配的工作量。定义责任 每个任务都应该指定具体的责任人。定义结果 每个任务都应该有一个定义好的输出结果。对于软件项目而言，输出通常是一个工作产品（例如，一个模块的设计结果）或工作产品的一部分。通常把多个工作产品组合成一个“可交付产品”。定义里程碑 应该为每个任务或每组任务指定一个项目里程碑。当一个或多个工作产品经过质量评审且得到确认时，就标志着一个里程碑的完成。12.1.1 软件开发的进度计划3

7、3工作量分配工作量分配 估算出总的工作量以后，就需要一个进行各个阶段工作量模型。R.S.Pressman提出了一种称做40/20/40的工作量分配规则，即前期工作（计划、需求分析、总体设计和详细设计阶段）和后期工作（测试阶段）各占40%，编码阶段占20%。这里强调要重视前期和后期工作。前期工作容易被忽视，主要原因是：管理人员认为不开始编码工作就算没有进行，他们不了解前期工作的重要性；技术人员往往也急于编码，认为写出代码任务就算完成了。后期工作也容易被忽视，认为编码出来就完事了，对测试工作要占这么大的工作量没有思想准备。所以要制定好进度计划，就要研究软件工作的规律，前期基础工作没做好，将会给后期

8、工作带来很大困难，往往使工程进度一拖再拖，难以坚持，有的不得不中途夭折。12.1.1 软件开发的进度计划 这种工作量分配规则只能作为一般的指导原则，每个项目的具体工作量分配，要由各个项目的特点来决定。大量的统计数据表明：用于项目计划的工作量很少超过2%3%，除非提交给开发机构的项目计划费用极大，并具有高风险。需求分析占项目工作量的10%25%，用于分析或原型开发的工作量应与项目的规模和复杂性成正比例地增长。通常有20%25%的工作量用于软件设计。用于设计评审和其后选代的工作量也必须考虑在内。由于软件设计已投入了不少的工作量，其后的编码工作一般困难很少，有15%20%的工作量就能够完成。测试和随

9、后的纠错要占用软件开发工作量的3040%。软件的重要性决定了所需的测试工作量。如果软件的质量非常重要，且人命关天，其工作量一般要占用更大的百分比。12.1.1 软件开发的进度计划4 4进度安排进度安排 软件项目的进度安排与其他任何多任务工作的进度安排几乎没有什么不同。所以，一般的项目安排技术和工具不需做大的修改就可用于软件项目的进度安排。Pressman在2001年出版的实践者的研究方法一书中提出：程序评价与评审技术（Program Evaluation and Review Technique,PERT）和关键路径方法（Critical Path Method，CPM）是两种用于软件开发项目

10、进度安排的方法。这两种方法都由早期的项目计划活动中已经差生的信息来驱动的。这些信息包括对工作量的估算。产品功能的分解。恰当的过程模型和任务集合选择。任务的分解。12.1.1 软件开发的进度计划 任务间的相互依赖性可以使用任务网络来定义。任务有时也称为项目工作分解结构（Work Breakdown Structure，WBS），其定义可以是产品的整体，也可以是单个功能。PERT和CPM方法都为软件计划者提供定量工具，其中包括：确定关键路径，决定项目持续时间的任务链。通过使用静态模型为单个任务进行最有可能的时间估算。为特定的任务定义一个时间“窗口”计算其边界时间 在软件项目进度安排中，边界时间计算

11、很有用。例如，一个功能设计推迟，可能进一步使其他功能设计延迟。12.1.1 软件开发的进度计划 Rigge描述了一些可以从PERT或CPM网络中得到的边界时间：一个任务的最早开始时间是在其所有的前置任务在最短可能的时间完成时。一个任务的最晚开始时间是不延期项目的最小完成时间。最早结束时间为最早开始时间与任务持续时间之和。最晚结束时间为最晚开始时间与任务持续时间之和。总浮动量是在任务保证进度的前提下，安排任务时所允许的富余时间的总和。这是网络关键路径在进度安排中的运用。边界时间计算导致关键路径的确定，并为管理者提供任务完成时评价进展的量化方法。PERT和CPM方法已经在个人计算机的自动工具中实现

12、。这样的工具使用容易。12.1.1 软件开发的进度计划5时间表和项目表 当建立软件项目进度时间表时，计划者可从一组任务（工作分解结构）开始。如果使用自动工具，可以用任务网络或任务大纲输入工作分解结构。然后，为一个任务输入工作量、持续时间和开始时间。另外，每一个项目都可以分配给特定的个人。作为这些输入的结果，产生一个时间表（timeline chart），也叫甘特图（Gantt chart）。可以为整个项目开发一个时间表，也可以为各个项目功能或各个项目工作者分别开发时间表。表12-1给出了时间表的格式。该图部分地描述了一个新的字处理软件产品中强调概念范围任务的软件项目进度安排。所有项目任务概念范

13、围都列在左边任务栏中，水平条说明了每个任务的持续时间。当多个时间条在同一个时间段出现时，则蕴含着任务之间存在并发。菱形表示里程碑。一旦输入了为生成时间表所需的信息，大多数的软件项目进度安排工具都会生成项目表（project chart）（见表12-2）。项目管理者如果要跟踪项目进度，可同时使用时间表和项目表。12.1.1 软件开发的进度计划表12-1 一个时间表的例子表12-2 一个项目表的例子12.1.1 软件开发的进度计划12.1.2 软件开发的组织机构 软件项目成功的关键是具有高素质的软件开发人员。然而大多数软件产品规模都很大，以至单个软件开发人员无法在给定期限内完成开发工作，因此，必须

14、把多名软件开发人员组织起来，使他们分工协作共同完成开发工作。如何组织参加软件项目的人员，使他们发挥最大的工作效率，对成功地完成软件项目至关重要。开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参与人员的素质有关。人的因素是不容忽视的参数。对于国情、体制、人员的工作习惯等都应作具体分析。了解并参考国外的做法是必要的，但无论如何不应简单地搬用。12.1.2 软件开发的组织机构n1组织原则n在建立项目组织时应注意到以下原则：尽早落实责任：在软件项目工作的开始，要尽早指定专人负责。使他有权进行管理，并对任务的完成负全责。减少接口：在开发过程中，人与人之间的联系是必不可少的，存在着通信路径。一

15、个组织的生产率是和完成任务中存在的通信路径数目是互相矛盾的。因此，要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。责权均衡：软件经理人员所负的责任不应比委任给他的权力还大。12.1.2 软件开发的组织机构n2组织结构的模式n通常有三种组织结构的模式可供选择：按课题划分的模式（Project Format）n把软件人员按课题组成小组，小组成员自始至终参加所承担课题的各项任务。他们应负责完成软件产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。按职能划分的模式（Functional Format）n把参加开发项目的软件人员按任务的工作阶段划分成若干个专

16、业小组。要开发的软件产品在每个专业小组完成阶段加工（即工序）以后，沿工序流水线向下传递。例如，分别建立计划组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等。各种文档资料按工序在各组之间传递。这种模式在小组之间的联系形成的接口较多，但便于软件人员熟悉小组的工作，进而变成这方面的专家。12.1.2 软件开发的组织机构矩阵行模式（Matrix Format）这种模式实际上是以上两种模式的复合。一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组等；另一方面，每一个项目又有它的经理人员负责管理。每个软件人员属于某一个专门组，又参加某一项目的工作。例如，属于测试组的一个成员，他参

17、加了某一项目的研制工作，因此他要接受双重领导（一是测试组，一是该软件项目的经理）。如图12-1所示。矩阵形结构组织的优点是：参加专门组的成员可在组内交流在各项目中取得的经验，这更有利于发挥专业人员的作用。而且各个项目有专人负责，有利于软件项目的完成。12.1.2 软件开发的组织机构3程序设计小组的组织形式 通常任为程序设计工作是按独立方式进行的，程序人员独立地完成任务。但这并不意味着互相之间没有联系。人员之间联系的多少和联系的方式与生产率直接相关。程序设计小组内人数少，如23人，则人员之间的联系比较简单。但在增加人员数目时，相互之间的联系复杂起来，并且不是按线性关系增长。并且，已经进行中的软件

18、项目在任务紧张，延误了进度的情况下，不鼓励增加新的人员给予协助。除非分配给新成员的工作是比较独立的任务，并不需要对原任务有更细致的了解，也没有技术细节的牵连。有人认为，在已经延误进度的软件项目中增加新的人员，只会使任务进一步拖延。12.1.2 软件开发的组织机构n 小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。主程序员制小组（Chief Programmer Team）n 小组的核心由1位主程序员（高级工程师）、2至5位技术员、1位后援工程师组成。这程序员负责小组全部技术活动的计划、协调与审查工作，还负责设计和实现项目中的关键部分。技术员负责项目的具体分析与开发，以及文档资料的

19、编写工作。后援工程师协助和支持主程序员的工作，为主程序员提供咨询，也做部分分析、设计和实现的工作。并在必要时能代替主程序员工作，以便使项目能继续进行。主程序员制小组还可以聘请一些专家（例如通信专家或数据库设计专家）、辅助人员（例如，打字机和秘书）、软件资料员协助工作。资料员可同时为多个小组服务，并完成下列工作：保存和管理所有软件配置元素。即文档资料、源程序清单、数据和磁介质资料等；协助收集和整理软件生产率数据；对可复用的模块进行分类及编写索引；协助小组进行调查、评价和准备文档等。资料员起着一个管理员、协调员的作用，此外他还潜在地起着软件配置评价者的作用。参看图12-2。12.1.2 软件开发的

20、组织机构图12-1 软件开发组织的矩阵形式图12-2 主程序员小组的成员12.1.2 软件开发的组织机构 主程序员制的开发小组突出了主程序员的领导。强调主程序员与其他技术人员的直接联系。总的来说简化了人际通信，参看图12-3(a)。这种集中领导的组织形式能否取得好的效果，很大程度上取决于主程序员的技术水平和管理才能。美国的软件产业中大多数是主程序员制的工作方式。图12-3 三种不同的小组结构（上排的三种为结构形式，下排的三种为通信路径）12.1.2 软件开发的组织机构民主制小组（Democratic Team）在民主制小组中，遇到问题，组成成员之间可以平等地交换意见，参见图12-3(b)。工作

21、目标的制定及做出决定都由全体成员参加。虽然也有一位成员当组长，但工作的讨论、成果的检验都公开进行。这种组织形式强调发挥小组每个成员的积极性，要求每个成员充分发挥主动精神和协作精神。在讨论时尊重每个成员，充分听取他们的意见，并要求大家互相学习，在组内形成一个良好合作的工作氛围。但有时也会因此削弱了个人的责任心和必要的权威作用。有人认为这种组织形式适合于研制时间长、开发难度大的项目。日本在发展计算机事业中，组织软件开发大多采用这种形式的开发小组，取得了很好的效果。他们强调发挥每位小组成员的积极性，要求每个成员充分发挥主动精神和协作精神，也创造了一个尊重每个成员的良好工作环境。由于小组成员在工作上能

22、够很好地配合，因而做到了较长时间稳定的人员合作关系。这样的小组形式避免了美国因软件人员频繁流动对工作造成的严重干扰。12.1.2 软件开发的组织机构层次式小组（Hierarchical Team）在层次式小组中，组内人员分为三级：组长（项目负责人）1人负责全组工作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动。他直接领导2至3名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。这种组织结构只允许必要的人际通信。比较适用于项目就是层次式结构的课题。参看图12-3(c)。这种组织结构比较适合项目本身就是层次结构状的课题。因为这样可以把项目按功能划分成若干个子项目，把子项目分配给基

23、层小组，有基层小组完成。例如，具有三个子项目的课题由具有三个基层小组的层次式小组完成。基层小组的领导与项目负责人直接联系。通常基层小组的人数不超过10人。因而，一个大型项目需要划分成若干层。这种组织方式比较适合于大型软件项目的开发。以上三种组织形式可以根据实际情况，组合起来灵活运用。例如，较大的软件项目也许是把主程序员小组组织成层次式结构；也许基层小组的领导又是一个民主制小组的成员。总之，软件开发小组的主要目的是发挥集体的力量进行软件研制。因此，小组培养从“全局”的观点出发进行程序设计，消除软件的“个人”性质，并促进更充分的复审，小组提倡在共同工作中互相学习从而改善软件的质量。12.1.3 软

24、件人员配备 如何合理地配备人员，也是成功地完成软件项目的切实保证。所谓合理地分配人员应包括：按不同阶段适时任用人员，恰当掌握用人标准。1项目开发各阶段所需人员一个软件项目完成的快慢，取决于参与开发人员的多少。在开发的整个过程中，多数软件项目是以恒定人力配备的。如图12-4所示。图12-4 软件项目的恒定人力配备12.1.3 软件人员配备 图12-6中的人力需求曲线就是Rayleigh-Norden工作量分布曲线。该曲线表示需求定义结束后的软件生存期（包括运行和维护）内的工作量分布情况，它也是投入人力与开发时间关系曲线。按此曲线，需要的人力随开发的进展逐渐增加，在编码与单元测试阶段达到高峰，以后

25、又逐渐减少。如果恒定地配备人力，在开发的初期，将会有部分人力资源用不上而浪费掉。在开发的中期（编码与单元测试），需要的人力又不够，造成进度的延误。这样在开发的后期就需要增加人力以赶进度。因此，恒定地配备人力，对人力资源是比较大的浪费。为合理地安排人力，可利用Rayleigh-Norden曲线计算开发时间t所需要的人力资源：12.1.3 软件人员配备 其中，Y为在达到时刻t以前需要投入的全部人力数（人年），K为整个生存期内需要投入的总人力数（人年）：为开发时刻的最大值，根据以往的开发经验，td大约与软件开发的收尾期相重合。由上式可以推导出 其中的K（总工作量）和td（开发时间）可以由下面的软件方

26、程得到：其中，L是前面介绍的开发规模（LOC），Ck是技术状态常数。12.1.3 软件人员配备n2配备人员的原则n 配备软件人员时，应注意以下三个主要原则：要质量：软件项目是技术性很强的工作，任用少量有实践经验、有能力的人员去完成关键性的任务，常常要比使用较多的经验不足的人员更有效。重培训：花力气培养所需的技术人员和管理人员是有效解决人员问题 的好方法。双阶梯提升：人员的提升应分别按技术职务和管理职务进行，不能混在一起。12.1.3 软件人员配备n3对项目经理人员的要求n 软件经理人员是工作的组织者，他的管理能力的强弱是项目成败的关键。除去一般的管理要求外，他应具有以下能力：把用户提出的非技术

27、性要求加以整理提炼，以技术说明书形式转告给分析员和测试员。能说服客户放弃一些不切实际的要求，以便保证合理的要求得以满足。能够把表面上似乎无关的要求集中在一起，归结为“需要什么”，“要解决什么问题”。这是一种综合问题的能力。要懂得心理学，能说服上级领导和用户，让他们理解什么是不合理的要求。但又要使他们毫不勉强，乐于接受，并受到启发。12.1.3 软件人员配备n4评价人员条件n 软件项目中人的因素越来越受到重视。在评价和任用软件人员时，必须掌握一定的标准。人员素质的优劣常常影响到项目的成败。能否达到以下这些条件是不应忽视的。牢固掌握计算机软件的基本知识和技能。善于分析和综合问题，具有严密的逻辑思维

28、能力。工作踏实、细致，不靠碰运气，遵循标准和规范，具有严格的科学作风。工作中表现出有耐心、有毅力、有责任心。善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系。具有良好的书面和口头表达能力。12.2 软件成本估算及控制 为了保证软件开发项目能在规定的时间内完成且不超过预算，这里成本估算（costing）和管理控制是关键。在计算机发展的早期，软件成本控制在整个计算机系统成本中仅占很小的百分比。但随着计算机及其应用的发展，特别是在今天，在大多数计算机系统中，软件已成为开销最大的部分。如果成本估算误差很大，开发费用成倍或呈数量级地增加，会造成灾难性的后果。软件产品的开发成本不同于其他物理

29、产品的成本，它不包括材料和能源的消耗、众多设备的折旧，主要是人的劳动消耗。另一个不同的是，软件产品不存在重复制造的过程。所以，软件产品的开发成本是以一次性软件开发过程中所付出的工作量（劳动量）代价进行计算的。12.2 软件成本估算及控制 软件成本估算永远不会是一门精确的科学。因为影响成本估算的因素太多（如人员、技术、环境、策略、甚至政治等），它们都会影响最终成本的估算。国外已有的技术只能作为我们的借鉴。1软件开发成本估算办法 有两种基本的估算方法（estimation）：自顶向下和自底向上。自顶向下的方法是对整个项目的总的开发时间和总的工作量作出估算，然后把它们按阶段、步骤和工作单元进行分配。

30、自底向上的方法则正好相反，分别估算各个工作单元所需的工作量和开发时间，然后相加，就得出总的工作量和总的开发时间。12.2 软件成本估算及控制n 两种方法都要求采用某种方法做出估算。有许多现成的方法可以利用，大致可分为：专家估算法、类推估算法和算式估算法。专家估算法 这种方法依靠一个或多个专家，对要求的项目做出估计，其精确性主要取决于两点，即专家对估算项目的定性参数的了解和他们的经验。后者类似于类推估算法。类推估算法 自顶向下的方法中，类推估算法是将估算项目的总体参数与类似项目进行直接比较得到结果。自底向上的方法中，类推是在两个具有相似条件的工作单元之间进行。算式估算法 专家估算法和类推估算法的

31、缺点在于，他们依靠带有一定盲目性的和主观的猜测对项目进行估算。算式估算法则力求避免主观因素的影响。用于估算的算式有两种基本类型：由理论导出，或由经验得出。12.2 软件成本估算及控制 理论导出的算法通常与Halstead软件科学理论有关，这种模型与经验得出的算法比较仍处于不成熟阶段，并且仍然存在争论。第二类经验算法与许多变量的定量估算有关，从一个模型到另一个模型之间，使用的变量有变化，但对于软件成本估算，这些变量（也称成本因素）一般从表12-3中选出估算的数量和成本因素之间的关系，由经验数据和项目过程记录确定。当然使用算式估算法仍需估算成本因素的值，同时仍要用到专家估算法和类推估算法。几乎所有

32、的算式估算法都使用项目中产生的指令数L或一些相近的相关量作为成本因素之一。通过一种算式可直接得到人力M M=L/P式中，P是一个常量，单位为指令数/人-日。这个常量用于对照原有数据校正模型，并且可以作为项目生产率的量度。实际上，P值很可能决定于L（大项目的进度比小项目慢），所以该方程是粗略的，但却很有用。12.2 软件成本估算及控制n 使用上述算式时，遇到的问题仍是估算指令数L，必须用专家估算法或类推估算法。自顶向下的方法中必须应用整个系统开发使用的指令总数和平均值P；而自底向上的方法则分别估算出各个系统成分的指令数和不同类型成分的P值。例如，用汇编语言编写的设备驱动程序的P值，不同于永COB

33、OL语言编写的报表生成程序的P值。这就促使我们去考虑算式估算法的潜在危险，即由于项目的非精确定义引起的偏差。对算式M=L/P，我们就可以提出下述问题：指令数是指原指令数还是目标指令数？是否包括注释和数据定义？是否包括未交付的指令？开发生存期哪一阶段的M可由给定的P值进行计算？需求定义阶段是否包括在内？是否还包含质量保证和项目管理？M中考虑了周末、假期和病假吗?12.2 软件成本估算及控制 假如不能回答这些问题，M=L/P将毫无用处。换句话说，在采用算式估算法时，必须明确地定义算式的适用性、成本因素和所得的估算值。尽管M=L/P很简单，但大量的研究发现，对该算式稍作修改，就能生成一个新算式，它与

34、观察到的数据有非常好的一致性。此算式称作幂定律算法，其公式为 ED=rSc式中，ED为总的开发工作量（到交付为止），单位为人-月；S为源指令数（不包括注释，但包括数据说明、公式或类似的语句）；常数r和c为校正因子。若S的单位为103,ED的单位为人-月，则r的取值范围一般在15，c的取值在0.91.5。在研究中，给定的各种定义（或非定义）项r和c的变化很小，并且覆盖面很广。12.2 软件成本估算及控制表12-3 可能影响成本模型结果的各种成本因素12.2 软件成本估算及控制2软件开发成本估算的经验模型 软件开发成本估算的依据是开发成本估算模型。开发成本估算模型通常采用经验公式来预测软件项目计划

35、所需要的成本、工作量和进度。用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的。因此，还没有一种估算模型能够使用所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用。这里简单介绍几种成本估算模型。12.2 软件成本估算及控制IBM模型 1977年，Walston和Felix总结了IBM联合系统分部（FSD）负责的60个项目的数据。其中源代码从400到467000行，工作量从12到11 758人-月，共使用29种不同语言和66种计算机。用最小二乘法拟合，可以得到与ED=rSc形式相同的估算公式（又称为静态变量模型）E=5.2L0.91D=4.1L0.36=2.47E0.35S=

36、0.54E0.6DOC=49L1.0112.2 软件成本估算及控制 上式中，E为工作量（单位为人-月）；项目持续时间D（单位为月）和工作人员要求S（单位为人），可以根据导出或估算的工作量来估算。文档页数DOC是为所估算的源代码行数L的函数而建立的模型。E=5.2L0.91近似于M=L/P的线性关系。考虑到这个最佳拟合偏差，模型使用了生产率指标I，它由下述方程，从29个成本因素中得到：上式中，Xi取值为-1,0或+1，它取决于第i个因素对项目的影响情况（即影响低、中或高）。加权值Wi由下式给出 上式中，PCi是生产率的比值，它与第i项成本因素（由经验数据决定）从低到高成比例变化；每天可交付的代码

37、行的实际生产率与I成线性关系。12.2 软件成本估算及控制SLIM模型 1979年前后，Putnam在美国计算机系统指挥中心资助下，对50个较大规模的软件系统花费估算进行研究，他在软件开发生存期雷利（Rayleigh）曲线模型的基础上提出SLIM商业化的成本估算模型，SLIM基本估算方程（又称为动态变量模型）式中，L和td分别表示可交付的源指令数和开发时间（单位为年）；K是整个生存期内人的工作量（单位为人-年），可从总的开发工作量ED=0.4K求得；Ck是根据经验数据确定的常数，表示开发技术的先进性级别。如果软件开发环境较差（没有一定的开发方法，缺少文档、评审或批处理方式），取Ck=6500；

38、正常的开发环境（有适当的开发方法，较好的文档和评审，以及交互式的执行方式），Ck=1000；而一个极好的开发环境（自动工具和技术），则取Ck=12 500。12.2 软件成本估算及控制 变换上式，可得开发工作量方程 用户可从美国或英国买到SLIM计算程序，它除了提供开发时间和成本估算外，还提供风险、可行性、估算CPU时间需求及项目计划中其他有关信息。COCOMO 模型 TRW开发的结构性成本模型COCOMO（Constructive Cost MOdel），是最精确、最易于使用的成本估算方法之一，1981年Boehm在他的著作中进行了详细的描述。Boehm定义了“基本的”、“中间的”和“详细的

39、”三种形式的COCOMO模型，其核心是方程ED=rSc和TD=a(ED)b给定的幂定律关系定义，其中TD为开发时间，经验常数r、c、a和b取决于项目的总体类型（结构型（organic）、半独立型（semidetached）或嵌入型（embedded）,见表12-4和表12-5。12.2 软件成本估算及控制表12-4 项目总体类型表12-5 工作量和进度的基本COCOMO方程12.2 软件成本估算及控制 通过引入与15个成本因素有关的r作用系数将中间模型进一步细化，这15个成本因素见表12-6。根据各种成本因素将得到不同的系数，虽然中间COCOMO方程与基本COCOMO方程相同，但系数不同，由此

40、得出中间COCOMO估算方程，见表12-7。对基本和中间模型，可根据经验数据和项目的类型及规模来安排项目各阶段的工作量和进度。这两种估算方程可应用到整个系统中，并以自顶向下的方式分配各种开发活动的工作量。详细的COCOMO模型应用自底向上的方式，首先把系统分为系统、子系统和模块多个层次，然后先在模块层应用估算方法得到它们的工作量，再估算子系统层，最后算出系统层。详细的COCOMO对于生存期的各个阶段使用不同的工作量系数。COCOMO模型已经用63个TRW项目数据库进行过标定，它们列于1981年Boehm的著作中，从书中可以了解使用数据库对该模型进行标定的详细方法。12.2 软件成本估算及控制表

41、12-6 影响r值的15个成本因素表12-7 中间COCOMO工作量估算方法12.2 软件成本估算及控制n3基于代码行（LOC）的成本估算方法n 这是一种自底向上的估算方法，即从模块开始进行估算，步骤如下：确定功能。首先将功能反复分解，直到可以对为实现该功能所要求的源代码行数能做出可靠的估算为止，对各个子功能，根据经验数据或实践经验，可以给出极好、正常和较差三种情况下的源代码估算行数期望值，分别用a、m、b表示。求期望值Le和偏差Ldn 上式中，Le为源代码行数据的期望值，如果其概率遵从 分布，并假设实际的源代码行数处于a、m、b以外的概率极小，则估算的偏差Ld取标准形式：n 上式中，n表示软

42、件功能数量。12.2 软件成本估算及控制根据经验数据，确定各个子功能的代码行成本。计算各个子功能的成本和工作量，并计算任务的总成本（美元）和总工作量（人-月）。计算开发时间。对结果进行分析比较。下面请看某个CAD（计算机辅助设计）软件包的开发成本估算。这是一个与各种图形外部设备（如显示终端、数字化仪和绘图仪等）接口的微机系统，其主要功能见表12-8。第1步，要列出开发成本表。表中的源代码行数是开发前的估算数据。观察表的前三列数值可以看出：外部设备控制功能所要求的极好与较差的估算值仅相差450行，而三维几何图形分析功能相差达4000行，这说明前者的估算把握性比较大。12.2 软件成本估算及控制

43、第2步，求期望值Le和偏差值Ld，计算结果列于表的第4列和第5列。整个CAD系统的源代码行数的期望值为33360行，偏差为1100。假设把极好与较差的两种估算结果作为各软件功能源代码行数的上、下限，其概率为0.99，根据标准方差的含义，可以假设CAD软件需要3200034500行源代码的概率为0.63，需要2600041000行源代码的概率为0.99。可以应用这些数据得到成本和工作量的变化范围，或者表明估算的冒险程度。但是应当注意这种情况下，概率包含的准确意义。第3步和第4步，对各个功能使用不同的生产率数据，即美元/行、行/（人-月），也可以使用平均值或经调整的平均值。这样就可求得各个功能的成

44、本和工作量。表中的最后两项数据是根据源代码行数的期望值求出的结果。计算得到总的任务成本估算值为657000美元，总工作量为145人-月。12.2 软件成本估算及控制 第5步，使用表中的有关数据求出开发时间。假设此软件处于“正常”开发环境，即Ck=10000，并将 人-年，代入方程则开发时间为 （年）第6步，分析CAD软件的估算结果。这里要强调存在标准方差1100行，根据表中的源代码行估算数据，可以得到成本和开发时间偏差（见表12-9），它表示由于期望值之间的偏差所带来的风险。有表12-9可知：源代码行数在26000到41000之间变化（准确性概率保持在0.99之内），成本在5122008077

45、00美元之间变化。同时如果工作量为常数，则开发时间为1.11.5。这些数值得变化范围表明了与项目有关的风险等级。由此，软件管理人员能够在早期了解风险情况，并建立对付偶然事件的计划。最后还必须通过其他方法来交叉检验这种估算方法的正确性。12.2 软件成本估算及控制n4基于过程的成本估算方法n 也就是说，将过程分解为相对较小的任务集合，再估算完成每个任务所需要的工作量。下面仍以CAD软件包为例，估算步骤如下：确定任务 即每个功能都必须经过需求分析、设计、编码和测试工作，见表12-10。确定每项任务的工作量 对每项任务要估算它们所需要的人-月数。找出与各项任务的对应的劳务费数据 即每个单位工作量成本

46、（美元/人-月）。因为各阶段的劳务费用不同，需求分析和总体设计阶段需要较多的高级技术人员；而详细设计、编码和早期测试则要求较多的初级技术人员，而他们的工资是不相同的。12.2 软件成本估算及控制表12-8 代码行的成本估算表12-9 成本和开发时间偏差表12-10 每项任务工作量的成本估算12.2 软件成本估算及控制计算 计算各项工作各个阶段的成本和工作量，然后计算总成本和总工作量。分析比较 在整个开发工作量中，需求分析和设计用去了75.5人-月，约占全部任务工作量的50%，说明了这项工作的重要性。劳务费反映了劳动者的成本，其中包括管理费。需求分析劳务费（5200美元/人-月）比设计、编码和单

47、元测试都高，这也说明了这项工作的重要性。CAD软件成本和工作量总计为708075美元和152.5人-月。将这些数据与代码行的成本估算比较，成本相差7%，工作量相差5%，结果非常接近。若相差较大，应该分析原因，很多情况下是由于估算人员对任务没有完全理解或有误解，或使用的劳务费数据不够恰当。计划人员必须找出原因后再重新估算，结果应基本一致。12.2 软件成本估算及控制5软件项目的追踪和控制 众所周知，软件项目管理的一项重要工作就是在项目实施过程中进行追踪和控制。可以用不同的方式进行追踪：定期举行项目状态会议。在会上，每一位项目成员报告他的进展和遇到的问题。评价在软件工程过程中所产生的所有评审的结果

48、。确定由项目的计划进度所安排的可能选择的正式的里程碑。比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价。实际上有经验的项目管理人员已经使用了所有这些追踪技术。软件项目管理人员还利用“控制”来管理项目资源、覆盖问题、及指导项目工作人员。如果事情进行得顺利（即项目按进度安排要求且在预算内实施，各种评审表明进展正常且正在逐步达到里程碑），控制可以放松一些。但当问题出现的时候，项目管理人员必须实施控制以尽可能快地排解它们。在诊断出问题之后，在问题领域可能需要一些追加资源；人员可能要重新部署，或者项目进度要重新调整

49、。12.3 软件工程标准与软件文档n12.3.1 软件工程标准n12.3.2 软件文档12.3.1 软件工程标准1什么是软件工程标准 人要和计算机打交道，需要程序设计语言，这种语言不仅应让计算机理解，而且还应让别人看懂，使其成为人际交往的工具。程序设计语言的标准化最早提到日程上来。随着人们对计算机软件的认识逐步深入，软件的工作范围从只是实用程序设计语言编写程序，扩展到整个软件生存期。如软件概念的形成、需求分析、设计、实现、测试、安装和检验。运行和维护，直到软件淘汰（为新的软件所取代）。同时还有许多技术管理工作（如过程管理、产品管理、资源管理）以及确认与验证工作（如评审和审计、产品分析、测试等）

50、常常是跨越软件生存期各个阶段的专门工作。所有这些方面都应该逐步建立起标准或规范来。另一方面，软件工程标准的类型也是多方面的。它可能包括过程标准（如方法、技术、度量等）、产品标准（如需求、设计、部件、描述、计划、报告等）、专业标准（如职别、道德准则、认证、特许、课程等），以及记法标准（如术语、表示法、语言等）。下面根据中国国家标准GB/T 15538-1995软件工程标准分类法给出软件工程标准的分类。12.3.1 软件工程标准n 软件工程的标准可用一张二维的表格来表示。表12-11(a)和表12-11(b)给出了这个二维表的大致格式。(b)表是(a)表的继续。表中为举例填入了三个标准（请注意它们