全国计算机四级考试复习纲要-第五章(4)

　　(3)PRICE-S模型Freiman在1979年提出了另一个商业化的成本估算模型RCA PRICE-S。PRICE-S计算程序以一个未发表的启发式算法为基础，将若干成本因素作为输入，关键是生成源代码或目标代码指令的数量，然后输出成本和进度估算，以及其它可供选择的项目管理数据。另一个程序PRICE-SL可用于估算系统维护成本，根据若干个用户提供的参数，如软件的期望寿命、发展和使用率等，PRICE-SL运行时以PRICE-S的输出作为它的输入。

　　(4)COCOMO模型TRW开发的结构性成本模型COCOMO(Constructive Cost Model)是最精确、最易于使用的成本估算方法之一，1981年Boehm在他的著作中进行了详尽的描述。

　　(5)Belley-Basili元模型这种模型提供了最适用于在给定的开发环境中，工作量估算方程的开发方法。结果类似于IBM和COCOMO模型。

　　(6)Schneider模型上述所有模型完全是经验性的，1978年Schneider根据1977年Halstead的软件科学理论推导出几种估算方程，得到的工作量方程与幂定律算式形式相同。

　　3.代码行的成本估算方法

　　这是一种自底向上的估算方法，即从模块开始进行估算，步骤如下:

　　(1)确定功能首先将功能反复分解，直到可以对为实现该功能所要求的源代码行数做出可靠性的估算为止。对各子功能，根据经验数据或实践经验，可以给出极好、正常和较差三种情况下的源代码估算行数的期望值，分别用a、m、b表示。

　　(2)根据经验数据，确定各子功能的代码行成本

　　(3)计算各子功能的成本和工作量，并计算任务的总成本(元)和总工作量(人-月)

　　(4)计算开发时间

　　(5)对结果进行分析比较4.每项任务工作量的成本估算方法开发过程中，最常用的是每项任务工作量的成本估算方法。工作量可以用人-日、人-月或人-年的数量来表示。知道单位工作量的成本，就可得到估算成本。

　　下面仍以上节中的CAD软件包为例，估算步骤如下:

　　(1)确定任务 即每个功能都必须经过需求分析、设计、编码和测试工作

　　(2)确定每项任务的工作量，对每项任务要估算它们所需要的人-月数。

　　(3)找出与各项任务的对应的劳务费数据 即每个单位工作量成本(元/人-月)。因为各阶段的劳务费用不同，需求分析和概要设计阶段需要较多的高级技术人员;而详细设计、编码和早期测试则要求较多的初级技术人员。而他们的工资是不相同的。

　　(4)计算 计算各个工作各个阶段的成本和工作量，然后计算总成本和总工作量。

　　(5)分析比较 在整个开发工作量中，需求分析和设计用去了75人-月，约占全部分任务工作量的50%，说明了这项工作的重要性。劳务费反映了劳动者的成本，其中包括管理费。需求分析的劳务费(5200元/人-月)比设计、编码和单元测试都高，这也说明了这项工作的重要性。

　　(三) 进度安排

　　软件开发项目的进度安排可以有两种考虑方式。第一种，系统最终交付使用的日期已经确定，软件开发机构必须在合同规定的时间内安排;第二种，只确定了大致的年限，最后交付使用的日期由软件开发机构根据具体情况确定。后一种考虑能够对软件开发任务进行细致的分析;能够最好地利用资源，合理地分配工作量，但实际工作中常常遇到第一种情况，问题是软件管理人员如何在规定的期限内分配人力和安排进度。进度安排的好坏往往影响整个项目的按期完成和用户的使用，如不能按期完成，用户就会不满，而且需向用户赔偿损失。如作为商品，将会失去市场竞争力。进度安排的精确性有时比成本估算更重要。在商品生产的社会中，某种商品的损失往往还可以通过其他商品或分期偿还来承担。而进度拖延的损失是无法弥补的。下面就软件开发项目进度安排中的几个问题进行讨论。

　　1.软件工作的特殊性

　　制定软件进度与其他工程没有很大的区别，因此使用一般的通用技术和工具即可。但重点要强调的是软件产品是逻辑产品，这与其他工程不同。因此当几个人共同完成某项任务时，人与人之间就有一个思想交流问题，称之为通信关系。通信是要付出代价的，不只是要花时间，同时由于通信中的疏忽常常会使错误增加。如一个组有4个软件工程师，两两之间进行通信联系，通信路径有6条;对6个软件工程师，则通信路径增加至14条。因此所付的代价就必然会增加，所以工作组的人员不宜太多，一般3—5人为好，目前国外一般采用主程序员组的制度。另一点要强调的是软件工作切忌中间临时加人，必须在安排进度时就考虑周到。

　　2.各阶段工作量的分配

　　估算出总的工作量以后，就需要一个可以进行各阶段工作量分配的模型。某一阶段工作量所占的百分比必须根据经验数据确定。这里要再一次强调，在开发过程中保存的记录将增加经验数据库存，而且将改善今后估算的准确性。R.S.Pressman提出一种称作40-20-40的工作量分配规则，即前期工作(计划、需求分析、概要设计和详细设计阶段)和后期工作(测试阶段)各占40%，编码阶段占20%。应该强调要重视前期和后期工作。前期工作容易被忽视，主要原因是:管理人员认为不开始编码工作就算没有进行，他们不了解前期工作的重要性;技术人员往往也急于编码，认为写出代码任务就算完成了。后期工作也容易被忽视，认为编码出来就完事了，对测试工作要占这么大的工作量没有思想准备。所以要制定好进度计划，就要研究软件工作的规律，前期基础工作没做好，将会给后期工作带来很大困难，往往使工程进度一拖再拖，难以坚持，有的不得不中途夭折。

　　3.制定开发进度

　　需要涉及的下一个未知量是开发进度。进度安排是软件计划工作中一项最困难的任务，计划人员要把可用资源与项目工作量协调好;要考虑各项任务之间的相互依赖关系，并且尽可能地平行进行;预见可能出现问题和项目的“细脖子”，并提出处理意见;以及规定进度，评审和应交付的文档。

　　假设用作变量的开发时间TD按线性变化，而且已经得到了总的开发工作量估算值ED，要求在规定的时间TD内完成，在项目中最好有参加工作的人员平均值M，即M=ED/TD，这将是一个非常有用的数据。遗憾的是在上述算式中，项目的工作量和开发时间不能作为独立的变量。Brooks定律描述了这种现象的最极端情况:为误期的软件项目增加人员将会使其进度更慢。

　　(四) 软件开发组织

　　有多少个软件开发机构，几乎也就有多少人员的组织机构。不管这些组织机构是好或坏，一般是不可能轻易改变的。尽管组织机构的改变不属于软件计划人员的职责范围内的事。不过，在一个新的软件项目中直接涉及人员的组织问题却是可以，也应该在软件计划阶段加以认真考虑的。对于一个需要n个人工作k年的软件项目，如何使用人员资源，可能有以下几种选择:

　　(1)把m项不同功能的软件分配给n个人去完成，他们之间无需多少合作，主要协调的任务由一位软件主管人员来负责。这样，软件主管可能同时需要管理多个不同项目;

　　(2)把m项不同功能的软件分配给n个人去完成(m≤n)，这样可能就要建立一些非正式的小组，并指定小组负责人，而小组之间的协调工作则由软件主管负责;

　　(3)n个人被组成k个小组，每个小组分配一个或多个功能，并有具体组织，协调工作由小组和软件主管共同进行。虽然对上述每一种方案都可能说出赞成或反对的理由。然而，有越来越多的证据表明，第三种方案，即正式的小组是最好最有效的。正式的小组的方案来源于“主程序员小组”的概念。它是由Harlan Mills首先提出，并由Baker进一步阐述的。小组的核心由一位高级工程师(主程序员)、2至5位技术人员和一位后备工程师组成。主程序员负责小组的所有技术活动的计划、协调和评审工作;技术人员负责项目的具体分析和开发;后备工程师则支持主程序员工作，必要时能代替主程序员工作，以便使项目能继续进行，而使损失最小。主程序员小组有一名或多名专家(如数据库设计或通信方面专家)、数名辅助人员(如秘书和打字员)和一名资料员参加工作。资料员同时为多个小组工作，具体完成下列工作:

　　(1)保存和管理所有软件配置(包括各种文档、源程序清单、数据和各种磁介质资料);

　　(2)协助收集和整理软件生产率数据;

　　(3)对可修改的模块分类及编写索引;

　　(4)协助小组进行调查、评价和准备文档等。主程序员小组的主要目标是发挥集体力量。因引，小组要培养从“全局”观点出发进行程序设计，把“我的”程序变为“我们的”程序;帮助消除软件的个人属性，小组可以鼓励更加彻底的评审，并在共同的工作中增加学习，从而改善软件质量。在本章的第3节中，我们曾讨论过人们在工作中有一个需要交流的问题。当采用主程序员小组这种形式时，必须会增加交换意见所需的工作量，这似乎不利于提高软件开发的生产率。然而，不管怎样组织，在软件整个开发过程的总工作量的相当一部分总是要花费在交换意见方面(如计划、分析和评审等)。虽然，小组的形式增加了内部交换意见的工作量，但是这是有组织的评审，必将减少在设计和编码中引入的错误。结果是测试工作量减少了，从而使小组有更高的生产率。当然，小组中技术人员的数量不宜过多，一般建议2～5人为好。

　　(五) 软件计划

　　软件开发过程的每一步都要生产出可交付的文档，这些文档可以用来进行评审和作为下一步工作的基础。软件计划是一份比较简短精炼的文件。它应该发给有关部门，其中包括:

　　(1)把该项目所确定的工作范围和所需的资源告诉软件主管部门、技术人员和该项目的需求者;

　　(2)有关该项目的成本估算和进度安排，应告诉软件主管部门，以便他们进行评审;

　　(3)还要发给与该项目开发有关的所有人员，给他们提供有关该项目开发的总办法。软件计划应包含以下内容:

　　1.工作范围

　　(1)项目目标(2)主要功能(3)其他特性(4)开发情况

　　2.资源

　　(1)人员资源(2)硬件资源(3)软件资源(4)可利用的窗口

　　3.成本估算

　　4.进度安排

　　六、软件开发工具与环境

　　目前，软件开发工具种类繁多，按功能可将软件开发工具分为8类:

　　(1)业务系统规划工具

　　通过将企业的策略性信息需求模型化，这类工具提供一个可导出特定信息系统的“原模型”，这样可使业务信息运行于企业的各个部门。

　　(2)项目管理工具

　　借助这类工具，项目管理者可以有效地估算软件项目所需的工作量、成本和研制周期等，可以定义一个功能分解结构WBS，并制定可行的项目开发计划;基于需求跟踪项目的开发情况;可采集度量数据，以此评价软件开发效率和产品质量。由此可见，这类工具又可详细分为项目计划工具、需求跟踪工具及度量和管理工具等。

　　(3)支持工具

　　这类工具用于支持软件工程过程，具体包括文档编制工具、系统软件工具、质量保证工具、数据库管理工具和软件配置管理工具等。

　　(4)分析和设计工具

　　这类工具是用于建立待开发系统的模型，并评价模型的质量，通过对模型进行一致性和有效性检查，保证分析与设计的完整性。它除包括支持某种开发方法的工具外，还包括基于规则体系的分析与设计机，这种分析与设计机是90年代的期望产品，它可使工具适用于各种分析和设计方法。

　　(5)编程工具

　　这类工具包括用于支持大多数传统编程语言的编译器、编辑器和调试器等，从工具输出来看，4GL也属于这一类。

　　(6)测试与分析工具 常用的测试与分析工具包括静态分析工具和动态测试工具。

　　(7)原型工具 作为除瀑布式开发模式以外的另一主要开发模式是原型开发模式，因其运用的灵活性和用户需求反应的快捷性

　　愈来愈受到重视，特别是随着软件构件重用研究的深入，更增强了这种开发模式的实用价值。但原型的构造离不开经验信息，所以支持原型开发模式的原型工具的发展日趋专用化，诸如用于用户界面设计的原型工具可利用图形包快速构造出应用系统的界面，供用户评价，以确定最终产品的界面形式。

　　(8)维护工具

　　用于协助维护活动的完成，包括当运行发现问题时，定位到相应的软件开发基线;软件配置不完备时由源程序到分析与设计模型的逆转换工具等。软件开发环境的分类方法很多。这里介绍三种:

　　(1)按解决的问题分类;

　　(2)按现有的软件开发环境的演变趋向分类;

　　(3)按集成化程度分类。

　　(一) 按解决的问题分类

　　软件开发中遇到的问题主要出现在三个级别上:程序设计级、系统合成级和项目管理级。软件开发环境也应该在这三个级别上给予支持。

　　1.程序设计环境

　　程序设计环境主要解决一个相对他人独立工作的程序员如何把规范说明转变成可工作的程序的问题，即属于局部编程(programming-in-the-small)的范畴。这个过程包括两个重要部分:方法和工具。其中方法(例如“结构化编码技术”)可能是更重要的部分，因为对于设计和编码很差的程序而言，再好的工具也不会是灵丹妙药。但作为软件开发环境而言，我们将把重点放在工具上。

　　2.系统合成环境

　　系统合成环境主要考虑把很多子系统集成为一个大系统的问题，即属于全局编程(proˉgramming-in-the-large)的范畴(已有文章把更大规模的系统编程称为programming-in-the-garantuan)。所有的大型软件系统都有两个基本特点:第一，它们是由一些较小的、较易理解的子系统组成的;第二，它们是不断改变的。这两个特点使软件在开发过程中产生大量的分支。因此，需要有一个系统合成环境来辅助人们控制子系统及其向大系统的集成。没有适当的支持，就不能在软件中准确地进行修改(改正错误或者改进功能)，因为人的智力将难于招架如此之大的规模和随之产生的高度复杂性。系统合成的两个基本问题是接口控制和版本控制。接口控制要考虑对模块相连和资源共享问题的描述和制约。版本控制则要考虑对系统的各个版本的生成和管理。

　　3.项目管理环境

　　大型软件系统的开发和维护必然会有多个人员在一段时间内协同工作。对人与人之间的交流和合作缺乏管理就会造成比程序设计更多、更严重的问题。另外，项目生存期越长，参与的人越多，就有越多的管理问题产生。项目管理环境的责任就是解决由于软件产品的规模大、生存期长、人们的交往多而造成的问题，即属于多方编程(programming-in-the-many)的范畴。项目管理环境必须对付的三个问题是误解、缺乏信息和利益冲突。项目管理环境可由两部分组成:记录和维护系统开发的状态信息以及集成和分发文档。

　　(二) 按现有的软件开发环境的演变趋向分类

　　按现有软件开发环境的演变趋向，软件开发环境可分成四类，它们对软件开发环境的发展(在工具、用户接口和体系结构方面)有着重要的影响。

　　1.以语言为中心的环境(language-centered environments)

　　它们是围绕一种语言而构成的，可以提供一套适合于这种语言的工具集。这类环境是高度交互式的，通常对系统合成的支持是有限的，也不支持项目管理。换句话说，它基本上属于程序设计环境。在现有的环境中，60年代末期出现的Lisp环境、70年代中期的以Mesa/Cedar语言为中心的Cedar环境、以Smalltalk语言为中心的Smalltalk环境及80年代早期形成的以Ada语言为中心的Rational环境等属于以语言为中心的环境。

　　2.面向结构的环境(structure-oriented environments)

　　这种环境所采用的技术允许用户直接操作结构。初始的动机是给用户一个借于语言的结构来输入程序的交互式工具，即语法制导编辑器(syntax-directed editor)。这种能力后来扩展到提供一个单用户程序设计环境，它还支持交互式语义分析、程序执行和调试。编辑器是这种环境的中心组成部分。最重要的是这种形式化地描述一种语言的语法和静态语义的能力，由此可以生成一个结构编辑器的实例(instance)。也就是说，这种与语言无关的技术引出了环境生成器的概念，在支持局部编程、全局编程、历史记载和存取控制表方面继续所作的努力，使术语“语法制导”逐渐被“面向结构”所取代了。在现有的环境中，80年代初期出现的Aloe编辑器就属于面向结构的环境，它是著名的Gendalf项目中的一个组成部分，它只允许用户在结构化元素上进行操作，也就是说，用户只看到抽象语法树，而看不到熟悉的源语言文本，不过它不会允许用户构造语法不正确的程序;稍后出现的Cornell程序合成器也属于面向结构的环境，它采用文本表示方式，以克服用户在输入和修改语言表示方面的困难。另外一些系统采用混合方式，用户可自由选择在哪种表示方式(文本或结构)上进行操作，系统内部保留两种形式，并始终使它们处于一致状态。

　　3.工具箱环境(toolkit environments)

　　工具箱环境由一套工具组成，用于支持软件开发和编码阶段。它从操作系统开始，加入一些诸如编辑程序、编译程序、汇编程序、连接程序和调试程序等编码工具。此外，也有一些支持大型软件开发任务的工具，如版本控制和配置管理。它采用简单的数据模型来提高工具的可扩充性和可移植性。这样的环境允许高度的剪裁，但对工具集的使用几乎不提供任何环境定义、管理或控制的技术。当代工具箱环境是使用相当成熟的技术。商业化的环境设计者正在把高级接口放在普通操作系统的用户命令接口之上，即扩充操作系统。商业化工具箱系统的例子是:UNIX程序员工作台UNIX/PWB和DEC VMS/VAX set等，它们都是在80年代中期推出的。对全局编程提供的工具分别是源代码控制系统(Source Code Control System-SCCS)和代码管理系统(Code Management System—CMS)，它们都是起版本控制的作用，并用独立于具体的程序设计语言的。稍后开发的著名的工具箱环境的例子是:可移植的公用工具环境(Portable Common Tool Environrment—PCTE)和公用APSE接口集(Comˉmon APSE Interface Set—CAIS)。其中APSE是Ada程序设计支持环境的英文缩写。

　　4.基于方法的环境(method-based environments)

　　这种环境支持一种特定的软件开发方法。这些方法可分为两类:

　　(1)支持软件开发周期特定阶段的;

　　(2)管理开发过程的。前者包括规格说明、设计、确认、验证和重用。方法不同，形式化的程序有很大不同，从非形式化到准形式化到形式化。后者又可细分为两个部分:支持产品管理与支持开发和维护产品的过程管理。产品管理包括版本、配置和投放管理。开发过程的管理包括项目计划和控制、任务管理、通信管理及加工过程建模。这类环境的例子有:Anna———一种用于Ada的规格说明语言;VDM———用于软件开发的形式化方法，也是一种规格说明语言;SREM———分布式计算的设计系统;PSL/PSA———问题描述语言/问题描述分析程序，这是为信息处理系统的结构化文档编制和分析设计的。支持管理开发过程的典型环境有ISTAR———一个集成式项目管理系统;PMA———一个知识型软件环境中的项目管理部分。

　　(三) 按集成化程序分类

　　环境的形成与发展主要体现在各工具的集成化的程度上，当前国外软件工程界把软件开发环境分成三代，各代之间的主要区别及特征如下:

　　1.第一代

　　(1)建立在操作系统之上(如VMS和UNIX等);

　　(2)工具间通过一个公用框架集成;

　　(3)只有工具使用的文件修改即可加入，由调用过程来使用这些工具;

　　(4)工具所使用的文件结构不变，而且成为环境文件库的一部分;

　　(5)从人机界面来看，这类环境主要采用单色、低分辨率的文字终端，图形能力较差，多数使用菜单技术。例如，70年代中期的UNIX环境以文件库为集成核心，管道命令实施控制功能，SHELL语言表达的程序显示用户工作界面。

　　2.第二代

　　(1)具有真正的数据库(如INGRES)，而不是文件库，有时称为信息库，多数采用E-R模式或E-R-A模式;

　　(2)工具集成在更低的层次上，工具和文件都作为实体保存在数据库中，而不是简单地看作一种独立的成分;(3)现有的工具不能随意放入，要作适当修改或定制;

　　(4)人机界面采用高分辨率、点阵式工作站，具有多窗口、图形符等功能，采用鼠标装置。例如，Ada程序设计支持环境(APSE)，以数据库为集成核心，有可移植性的工作界面。

　　3.第三代

　　(1)建立在知识库系统上;

　　(2)顺序调用独立工具的概念完全被集成化的工具集所替化，用户不再需要在任务之间来回切换不同的工具;

　　(3)采用形式化方法，软件重用等新技术;

　　(4)由多个工具控制的多窗口技术被单个工具操纵的多窗口技术所替代;显然，第三代软件开发环境中工具间的集成度最高，利用这些工具，人们逐渐从繁重的手工开发软件的活动中解放出来，从而实现软件开发和维护的自动化，提高软件开发和维护的质量和生产率，缩短软件开发周期并降低成本。为集中研究并解决这样一系列的问题，80年代提出了CASE思想，目前的研究重点集中于CASE的集成化方面。

　　全国计算机四级考试经验分享

　　坚定的信心自学计算机是需要一定的条件的，现在回想起来，我当时的条件不算好：第一，没有基础。大专学的是中文，而且完全没有接触过电脑，对计算机没有一点感性认识，甚至不知道学电脑要学些什么……第二，环境很闭塞。毕业后在一个偏僻的小镇教书，身边没有人懂电脑，有了疑问没有人能帮自己解决;第三，缺少硬件条件。开始的半年我没有电脑，只能纸上编程;一边工作一边学习，而且总感觉时间不够。尽管困难重重，但我确信一条：计算机知识是一门技术学科，不是一门艺术;可能有人终其一生，也不能成为一名艺术家，但每个人通过努力，都是可以掌握好一门技术的。正是因为有这样坚定的信心，我才能够在三年的时间里，克服了常人难以想像的困难，终于达到了自己的目标。

　　选好教材没人指导自己学习，选一些好的教材就显得非常重要了。开始我也不知道什么书好，见什么买什么。后来发现一些大学教材内容很系统，而且也有一定的权威性。我后来选的就是清华大学计算机系的教材。学完教材后，我开始研究三本软件水平考试的统编教材，如果一开始就看统编教材，会觉得书里结论大多没有详细的阐述，很难理解和记忆，但先系统学完教材后，你会发现统编教材起了一个很好的综合作用。

　　学会“不求甚解”我这里说的“不求甚解”并不是指不认真学习。自学电脑最怕钻牛角尖：看书时一个问题不明白，就在那里卡住，非解决它不可——这样的方法我是不赞成的。首先，它会严重打击你的自信心，使你丧失继续学习下去的兴趣;其次，这样浪费了许多时间。因此学习时要给自己留一些“不懂”的余地。例如第一遍读书时要允许自己似懂非懂，用规定的时间(例如两个星期)把它看完，然后开始第二遍学习。开始时许多不明白的东西，这次就容易理解多了。