《GIS工程讲义第八讲GIS工程计划与管理》由会员分享，可在线阅读，更多相关《GIS工程讲义第八讲GIS工程计划与管理（158页珍藏版）》请在金锄头文库上搜索。
1、第八讲 GIS工程计划与管理1 项目管理过程lGIS项目管理的对象是GIS工程项目。它所涉及的范围覆盖了整个工程过程。l为使项目开发获得成功，必须对开发项目的工作范围、可能遇到的风险、需要的资源(人、硬软件)、要实现的任务、经历的里程碑、花费的工作量(成本)，以及进度的安排等等做到心中有数：而项目管理可以提供这些信息。这种管理开始于技术工作开始之前，在从概念到实现的过程中持续进行，最后终止于工程过程结束。(1)启动一个项目l设计人员和用户是在系统工程阶段确定项目的目标和范围。目标标明了项目的目的，但不涉及如何去达到这些目的。范围标明了要实现的基本功能，并尽量以定量的方式界定这些功能。当明确了项
2、目的目标和范围后，就应考虑可能的解决方案，标明技术和管理上的要求。虽然涉及方案细节不多，但有了方案，管理人员和技术人员就能够据此选择一种“好的”方法，确定合理、精确的成本估算，实际可行的任务分解以及可管理的进度安排。(2) 度量l进行度量工作，是为了帮助工程人员了解产品开发的技术过程和产品。对开发过程进行度量的目的是为了改进开发过程，而对产品进行度量的目的是为了提高产品质量。l度量的作用是为了有效地定量地进行管理。度量的目的是为了把握软件工程过程的实际情况和它所生产的产品质量。在对过去未度量过的事项进行度量时，需要解决的问题是：哪些度量适合于过程和产品?如何使用收集到的数据?用于比较个人、过程
3、或产品的度量是否合理?(3) 估算 -l在软件项目管理过程中一个关键的活动是制定项目计划。在做计划时，必须就需要的人力、项目持续时间、成本作出估算。这种估算大多是参考以前的花费作出的。如果新项目与以前的一个项目在大小上和功能上十分类似，则新项目所需要的工作量、开发时间、成本大致与那个老项目相同。但对于背景完全生疏的项目，只凭过去的经验作出估算可能就不够了。现在已有了许多用于开发的估算技术。虽然各有其优缺点，但以下几方面是共同的：事先建立工作范围；以度量(以往的度量)为基础作出估算；把项目分解为可单独进行估算的小块。管理人员可使用各种估算技术，并可用一种估算技术作为另一种估算技术的交叉检查。(4
4、)风险分析l风险分析对于软件项目管理是决定性的，然而现在还是有许多项目不考虑风险就着手进行。TomGilb在他的有关软件工程管理的书中写道：“如果谁不主动地攻击(项目和技术)风险，它们就会主动地攻击谁”。风险分析实际上就是贯穿在软件工程过程中的一系列风险管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监督，它能让人们去主动“攻击”风险。(5)进度安排l每一个软件项目都要求制定一个进度安排，但不是所有的进度都得一样安排。对于进度安排，需要考虑的是：预先对进度如何计划?工作怎样就位?如何识别定义好的任务?管理人员对结束时间如何掌握，如何识别和监控关键路径以确保结束?对进展如何度量
5、?以及如何建立分隔任务的里程碑。软件项目的进度安排与任何一个工程项目的进度安排没有实质上的不同。l首先识别一组项目任务，再建立任务之间的相互关联，然后估算各个任务的工作量，分配人力和其他资源，制定进度时序。(6)追踪和控制l一旦建立了开发进度安排，就可以开始着手追踪和控制活动。由项目管理人员负责追踪在进度安排中标明的每一个任务。如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。此外，还可对资源重新定向，对任务重新安排，或者(作为最坏的结果)可以修改交付日期以调整已经暴露的问题。用这种方式可以较好地控制系统的开发。2
6、生产率和质量的度量l对于任何一个工程项目来说度量都是最基本的工作，GIS工程也不例外。LordKelvin曾说过：“如果谁能够度量他所说的事物并能用数字来表示它时，则说明他了解了它；但当他不能度量它，也不能用数字表示出来时，则说明他对那种事物的知识还比较贫乏、不足；这也可能是了解的开始，但在他的思想中很难达到科学的境地”。21 软件度量l软件度量涉及范围较广。在软件项目管理范围内，应主要关心生产率与质量的度量，即根据投入工作量，对软件开发活动和开发成果的质量作出度量。从计划和估算的目的出发，必须弄清历史情况；在以往的项目中，软件开发生产率如何?生产出的软件产品的质量又怎样?通过以往的生产率数据
7、和质量数据如何来推断现在的生产率和质量?如何利用这些数据来进行更精确的计划和估算? 对软件进行度量的目的是：表明软件产品的质量、弄清软件开发的生产率、给出使用了新的软件工程方法和工具所得到的(在生产率和质量两方面)的效益、建立项目估算的“基线”、帮助调整对新的工具和附加培训的要求。 l在物理世界中的度量有两种方式。一种是直接度量(如度量一个螺栓的长度)；一种是间接度量(如用次品率来度量生产出的螺栓质量)。软件度量也同样分为两类。工程过程的直接度量包括所投入的成本和工作量。软件产品的直接度量包括产生的代码行数(LOC)、执行速度、存储量大小、在某种时间周期中所报告的错误数。而产品的间接度量则包括
8、功能性、复杂性、效率、可靠性、可维护性和许多其他的质量特性。只要事先建立特定的度量规则，很容易做到直接度量开发软件所需要的成本和工作量、产生的代码行数等。但是，软件的功能性、效率、可进一步将软件度量范围如图1所示那样进行分类。从图中可知，软件生产率度量主要集中在软件工程过程的输出；软件质量度量可指明软件能够在多大程度上满足明确和不明确的用户要求(软件使用合理性)；而技术度量则主要集中在软件的一些特性(如逻辑复杂性、模块化程度)上而不是软件开发的全过程。22 面向规模的度量l面向规模的度量是对软件和软件开发过程的直接度量。软件开发组织可以建立一个如图2所示的面向规模的数据表格来记录项目的某些信息
9、。该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。如项目aaa01的开发规模为121kLOC(千代码行)，工作量用了24个人月，成本为168000元。需要注意的是，在表格中记载的工作量和成本属于整个软件工程的活动(分析、设计、编码和测试)，而不仅仅是编码活动。进一步地，关于项目aaa01的信息还表明开发出的文档有365页，在交付用户使用后第一年内发现了29个错误，有3个人参加了项目aaa01的软件开发工作。 l对于每一个项目，可以根据表格中列出的基本数据进行一些简单的面向规模的生产率和质量的度量。例如，可以根据图2对所有的项目计算出平均值：l生产率kLOCPM
10、(人月)l质量错误数kLOCl此外，也可以计算出其他令人感兴趣的度量：l成本：元LOCl文档文档页数kLOC l对面向规模的度量一直是有争议的，还没有一种为人们普遍接受的度量软件开发过程的方法。争议主要集中在是否使用代码行数(LOC)作为度量准则。lLOC度量的支持者们认为LOC是所有软件开发项目的必然产物，它能够很容易地被计算出来，许多现存的软件估算模型都是使用LOC或者kLOC作为关键输入的，而且大量以LOC为根据的文献和数据已经存在。而反对者们则认为LOC度量与程序设计语言有关，它们不适用于设计很好且较短的程序，也不适合于非过程型语言。若在估算中使用，很难达到要求的精度(计划人员必须在分
11、析和设计远未完成之前就要估算出需要生产的LOC)。23 面向功能的度量l面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量的注意力集中于程序的“功能性”和“实用性”，而不是对LOC计数。该度量是由Albrecht首先提出来的。他提出了一种叫做功能点方法的生产率度量法，该方法利用有关软件数据域的一些计数度量和软件复杂性估计的经验关系式，导出功能点FPs(FunctionPoints)。l功能点通过填写图3所示的表格来计算。首先要确定五个数据域的特征，并在表格中相应位置给出计数。数据域的值以如下方式定义： l一旦收集到上述数据，就可以计算出与每一个计数相关的加权复杂性值。使用功能点方
12、法的单位要自行拟定一些准则，用以确定一个特定项是简单的、平均的还是复杂的。尽管如此，复杂性的确定多少还是带点主观因素的。计算功能点，使用如下的关系式：lFP总计数X(065十001Xsum(F)(131)l其中，总计数是由图133所得到的所有加权复杂性值的和；Fi(i1到14)是复杂性校正值，它们应通过逐一回答图4所提问题来确定。sum(Fi)是求和函数。上述等式中的常数和应用于数据域计数的加权因数可经验地确定。24 软件质量的度量l质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。在软件交付之前得到的度量提供了一个定量的根据，以作出设计和测试质量好坏的判断。这一类度量包括程序复杂性、
13、有效的模块性和总的程序规模。在软件交付之后的度量则把注意力集中于残存的差错数和系统的可维护性方面。特别要强调的是，运行期间的软件质量度量可向管理者和技术人员表明软件工程过程的有效性达到什么程度。 l(1)影响软件质量的因素lMcCall和Cavano定义了一组质量因素。这些因素从三个不同的方面来评估软件质量，即产品的运行(使用)、产品的修正(变更)及产品的转移(为使其在不同的环境中工作而作出修改，即移植)。他们在自己的论文中介绍了这些质量因素之间的关系(叫做框架)和软件工程过程的其他方面。参看前讲。(2)质量的度量l已经有许多软件质量度量方法，使用得最广泛的是事后度量或验收度量。它包括正确性、
14、可维护性、完整性和可使用性。Gilb提出了它们的定义和度量。25 协调不同的度量方法l代码行数和功能点之间的关系与实现软件的程序设计语言和设计质量有关。有一些研究试图找出FP度量和LOC度量间的关连。Albrech和Faffney认为：“应用提供的功能数，可以其于这个应用所使用或产生的数据来作出估算。而且，功能的估算应与要开发的LOC数和所需要的开发工作量相关”。 l表131给出使用各种程序设计语言建立一个功能点所需要的平均代码行数的粗略估算表中的数据表明，个Ada的LOC比个FORTRAN的“)C提供了几乎L4倍的“功能性”。而一个4GI的LOC比一个传统的程序设计语言的LOC提供了35倍的
15、“功能性”，在FP和LOC之间的关系方面，Jones给出了更精确的数据，可用来根据LOC数计算功能点数。 lBasili和Zelkowitz确定了五种影响软件生产率的重要因素：l(1)人的因素：软件开发组织的规模和专长；l(2)问题因素：问题的复杂性和对设计限制，l以及需求的变更次数；l(3)过程因素：使用的分析与设计技术、语言l和CASE工具的有效性，及评审技术；l(4)产品因素：计算机系统的可靠性和性能；l(5)资源因素：CASE工具、硬件和软件资源l的有效性。 lWalston和felix对以上因素及其他因素所产生的影响做了具体说明。对于一个给定的项目，上述的某一因素的取值高于平均值(条
16、件非常有利)，那么与那些同一因素的取值低于平均值(条件不利)的项目比，它的软件开发生产率较高。对于上述的五个因素，从高度有利到不利条件的改变将以如表2所示的方式影响生产率。3 在工程过程中使用度量l通过对生产率度量和质量度量提出要求和评价，管理部门能够建立改进工程过程的目标。如果软件开发过程能够得到改进，对整个机构的工作将产生直接影响。而要建立改进目标，就必须了解软件开发的当前状态因此，可使用度量来建立过程的基线，根据此基线来评估改进。31 建立基线l建立实用的项目估算、生产高质量的软件、按期提交产品，这是软件项目管理人员必然会遇到的一些最基本的也是最重要的问题。通过使用度量建立项目基线，就能
17、对这些问题进行管理。此外，质量度量数据一旦收集到，软件开发组织就可以根据它们来调整其软件工程项目，以消除那些对软件开发有重大影响的错误产生的根源。 l基线由从以往的软件开发项目中收集到的数据构成，可以像图2所示的表格那样简单，也可以像图7所给出的那样复杂。为了帮助计划、成本和工作量估算，基线的数据应当具有下列属性：l(1)数据必须是合理的、精确的，应当避免单纯根据以往项目进行“盲目估算”；l(2)应当从尽可能多的项目中收集数据；l(3)对于所有成为数据收集对象的项目，对代码行的解释都应是一致的；l(4)基线数据的应用必须与要做估算的工作类似。如果把一个适用于批处理系统工作的基线用于估算一个实时
18、微处理器的应用就没有什么意义。32 度量数据的收集、计算和评价l建立一个基线的过程如图5所示。理想情况下，建立基线所需要的数据应在开发的过程中进行收集。然而这很难做到。因此，数据收集要求对以往的项目做历史调查，并根据调查结果来构造所需要的数据。一旦收集到数据，就可以做度量计算。最后，应当对计算出来的数据进行评价，并把它们用到估算中去。数据评价的焦点应集中于所得结果的合理性上：计算出来的中间值是否适合手头的项目?是否存在某些被掩盖的情况会导致估算中用到的某些数据无效?等等。必须对这些问题进行分析以免盲目地使用度量数据。 l图7给出了一张表格模型，可使用它对历史软件基线数据进行收集和计算。这种模型
19、包括了成本数据、面向规模的数据、面向功能的数据，可以计算面向源代码行数I-OC的度量和面向FP的度量。应当注意的是，要想收集到这个模型所要求的所有数据不总是可能的。如果使用这个模型对以往的许多项目进行收集和计算，就能建立起软件度量基线。4 软件项目估算l在做软件项目估算时往往存在某些不确定性，使得软件项目管理人员无法正常进行管理l而导致产品迟迟不能完成。现在已使用的实用技术是时间和工作量估算。因为估算是所有其他项目计划活动的基石，且项目计划又为软件工程过程提供了工作方向，所以不能没有计划就开始着手开发，否则将会陷入盲目性。41 针对估算的考虑l估算资源、成本和进度时需要经验、有用的历史信息、足
20、够的定量数据。估算有风险。增加风险的因素如图8所示。图中的轴线表示所估算项目的特征。l项目的规模对于软件估算的精确性影响也比较大。因为随着软件规模的扩大，软件了元素之间的相互依赖、相互影响程度也迅速增加，因而估算的一个重要方法问题分解也会变得更加困难。由此可知，项目的规模越大，开发工作量越大，估算的风险越高。 l项目的结构化程度也影响项目估算的风险。结构性是指功能分解的简便性和处理信息的层次性。图8表明随着结构化程度的提高，精确估算的能力也能提高，而风险将减少。l历史信息的有效性也影响估算的风险。回顾过去，就能够仿效做过的事，且改进出现问题的地方。在对过去的项目进行综合的软件度量之后。就可以借
21、用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。42 项目计划的目标l项目计划的目标是提供一个能使项目管理人员对资源、成本和进度做出合理估算的框架。这些估算应当在软件项目开始时的一个时间段内作出，并随着项目的进展定期更新。l如上所述，在不断发现导致合理估算的信息的过程中，逐步达到计划的目标。下面将讨论与项目计划有关的各项活动。43 系统的范围l项目计划的第一项活动是确定系统的范围。44 开发中的资源l项目计划的第二个任务是对完成该项目所需的资源进行估算。图9把系统开发所需的资源画成一个金字塔，在塔的底部必须有现成的用以支持软件开发的工具硬件工具及软件工具，在塔的高层是
22、最基本的资源人。通常，对每种资源，应说明以下四个特性：资源的描述、资源的有效性说明、资源在何时开始需要、使用资源的持续时间。最后两个特性统称为时间窗口。对每一个特定的时间窗口，在开始使用它之前就应说明它的有效性。45软件项目估算l在计算技术发展的早期，软件的成本在基于计算机的系统的总成本中只占一个很小的百分比。在软件成本的估算上，出现一个数量级的误差，其影响相对还是比较小的。但现在软件在大多数基于计算机的系统中已成为最昂贵的部分。如果软件成本估算的误差很大，就会使盈利变成亏损。对于开发者来说，成本超支可能是灾难性的。 l软件成本和工作量的估算从来都没有成为一门精确的科学。因为变化的东西太多，人
23、、技术、环境、政治，都会影响软件的最终成本和开发的工作量。但是，软件项目的估算还是能够通过一系列系统化的步骤，在可接受的风险范围内提供估算结果。46 分解技术l当一个待解决的问题过于复杂时，可以把它进一步分解，直到分解后的子问题变得容易解决为止。然后，分别解决每一个子问题，并将这些子问题的解答综合起来，从而得到原问题的解答。l软件项目估算是一种解决问题的形式，在多数情况下，要解决的问题(对于软件项目来说，就是成本和工作量的估算)非常复杂，想一次性整体解决比较困难。因此，对问题进行分解，把其分解成一组较小的接近于最终解决的可控的子问题，再定义它们的特性。 l(1)LOC和FP估算l前面已经介绍了
24、代码行(LOC)和功能点(FP)，并使用它们作为基本数据来计算生产率度量。在软件项目估算中，在两个方面使用了LOC和FP数据：l当做一个估算变量，用于量度软件每一个元素的大小。l联合使用从过去项目中收集到的基线数据和其他估算变量，进行成本和工作量估算。 lLOC和FP是两个不同的估算技术。但两者有许多共同特性。项目计划人员首先给出一个有界的软件范围的叙述，再由此尝试着把软件分解成一些小的可分别独立进行估算的子功能。然后对每一个子功能估算其LOC或FP(11p估算变量)。接着，把基线生产率度量(如，LOCPM或FPPM)用做特定的估算变量，导出子功能的成本或工作量。将子功能的估算进行综合后就能得
25、到整个项目的总估算。 l作为LOC和FP估算技术的一个实例，考察一个为计算机辅助设计(CAD)应用而开发的软件包。系统定义评审指明，软件是在一个工作站上运行，其接口必须使用各种计算机图形设备，包括鼠标、数字化仪、高分辩率彩色显示器和激光打印机。在这个实例中，使用LOC作为估算变量。当然，FP也可使用，但这时需要进行在前节所说的数据域取值的估算。 l根据系统定义，软件范围的初步叙述如下；“软件将通过操作员接收2维或3维几何数据。操作员通过用户界面与CAD系统交互并控制它，这种用户界面将表现出很好的人机接口设计特性。所有的几何数据和其他支持信息保存在一个CAD数据库内。要开发一些设计分析模块以产生
26、在各种图形设备上显示的输出。软件要设计得能控制并能与各种外部设备，包括鼠标、数字化仪、激光打印机和绘图仪交互”。 l现在假定进一步的细化已做过，并且已识别出该软件包具有以下主要的软件功能：用户界面和控制功能、二维几何分析、三维几何分析、数据库管理、计算机图形显示功能、外设控制、设计分析模块。通过下述的分解技术，可得到如表3所示的估算表。表中给出了LOC的估算范围。 l从表中的前三列可以看出，计划人员对外设控制功能所需要的LOC是相当清楚的，其最佳估算值和悲观估算值之间仅相差450代码行。另一方面，对三维几何分析功能相对来说不很熟悉，在最佳估算值和悲观估算值之间相差达4000LOC。计算出的各功
27、能的期望值放入表中的第4列。然后对该列垂直求和，得到该CAD系统的LOC估算值33360。 l从历史的基线数据求出生产率度量，即行PM和元行。在这种情况中，计划人员需要根据复杂性程度的不同，对各功能使用不同的生产率度量值。在表中的成本和工作量这两列的值分别用LOC的期望值E与元行相乘，及用LOC的期望值E与行PM相除得到。因此可得，该项目总成本的估算值为657000元，总工作量的估算值为145人月(PM)。(2)工作量估算l工作量估算是估算任何工程开发项目成本的最普遍使用的技术。每一项目任务的解决都需要花费若干人日、人月或人年。每一个工作量单位都对应于一定的货币成本，从而可以由此作出成本估算。
28、 l类似于LOC或FP技术，工作量估算首先从软件项目范围抽出软件功能。接着给出为实现每一软件功能所必须执行的一系列软件工程任务，包括需求分析、设计、编码和测试。表4给出了解各个软件功能和相关的软件工程任务。 l计划人员针对每一软件功能，估算完成各个软件工程任务所需的工作量(如人月)，并记在表4的中心部分。高级技术人员主要投入到需求分析和早期的设计任务中，而初级技术人员则进行后期设计任务、编码和早期测试工作，他们所需成本比较低。 l最后一个步骤就是计算每一个功能及软件工程任务的工作量和成本，横向和纵向的总计给出所需要的工作量。如果工作量估算是不依赖lOC或FP估算而实现的，那么就可得到两组能进行
29、比较和调和的成本与工作量估算。如果这两组估算值合理地一致，则估算值是可靠的。如果估算的结果不一致，就有必要做进一步的检查与分析。在表中，“前期”的开发任务(需求分析和设计)，花费了75个人月，说明这些工作相当重要。 l与每个软件工程任务相关的劳动费用率记入表中费用率(元)这一行，这些数据反映了“负担”的劳动成本，即包括公司开销在内的劳动成本。在此例中，需求分析的劳动成本为5200元PM，比编码和单元测试的劳动成本高出22。 lCAD软件总成本和总工作量的估算分别为708000元和153人月(PM)。若与使用LOC技术导出的数据相比，成本相差7，而工作量相差5，所得到的结果非常接近一致。l如果两
30、种估算方法所得结果之间的一致性很差，就必须重新确定估算所使用的信息。如果要追寻产生差距的原因，不外乎以下两个原因之一，l计划人员没有充分了解或误解了项目的范围；l用于LOC估算的生产率数据不适合于本项目，过时了(即使用这些数据不能正确反映软件开发机构的情况)，或者是误用了。计划人员必须确定产生差距的原因再来协调估算结果。 5 软件开发成本估算l这一节讨论软件开发成本，主要是指软件开发过程中所花费的工作量及相应的代价，不包括原材料和能源的消耗，主要是人的劳动的消耗。此外，软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此软件开发成本的估算，应是从软件计划、需求分
31、析、设计、编码、单元测试、组装测试到确认测试，整个软件开发全过程所花费的人工代价作为依据的。51 软件开发成本估算方法l对于一个大型的软件项目，由于项目的复杂性，开发成本的估算不是一件简单的事，要进行一系列的估算处理。主要靠分解和类推的手段进行。基本估算方法分为三类。(1)自顶向下的估算方法l这种方法的想法是从项目的整体出发，进行类推。即估算人员根据以前已完成项目所耗费的总成本(或总工作量)，推算将要开发的软件的总成本(或总工作量)，然后按比例将它分配到各开发任务中去，再检验它是否能满足要求。Boehm给出一个参考例子，参看表5。l这种方法的优点是估算工作量小，速度快。缺点是对项目中的特殊困难
32、估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。 l(2)自底向上的估计法l这种方法的想法是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。这是一种常见的估算方法。它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量(配置管理、质量管理、项目管理)。所以往往估算值偏低，必须用其他方法进行检验和校正。 l(3)差别估计法l这种方法综合了上述两种方法的优点，其想法是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和
33、不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。这种方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似”的界限。l52 专家判定技术l专家判定技术就是由多位专家进行成本估算。由于单独一位专家可能会有种种偏见。因此，最好由多位专家进行估算，取得多个估算值。有多种方法把这些估算值合成一个估算值。例如，一种方法是简单地求各估算值的中值或平均值。其优点是简便。缺点是可能会由于受一、二个极端估算值的影响而产生严重的偏差。另一种方法是召开小组会，使各位专家们统一于或至少同意某一个估算值。优点是可以摈弃蒙昧无知的估算值，缺点是一些组员可能会受权威或政治因素的影响。为了避免
34、上述不足，Rand公司提出了Deiphi技术，作为统一专家意见的方法。用Deiphi技术可得到极为准确的估算值。 l(1)组织者发给每位专家一份软件系统的规格说明书(略去名称和单位)和一张记录估算值的表格，请他们进行估算。l(2)专家详细研究软件规格说明书的内容。然后组织者召集小组会议，在会上，专家们与组织者一起对估算问题进行讨论。 l(3)各位专家对该软件提出三个规模的估算值，即：ldi该软件可能的最小规模(最少源代码行数)；lmi一一该软件最可能的规模(最可能的源代码行数)；lbi一一该软件可能的最大规模(最多源代码行数)。l无记名地填写表格，并说明做此估算的理由。 l(4)组织者对各位专
35、家在表中填写的估算值进行综合和分类，做以下事情：l1)计算各位专家(序号为i，I=1，2，n)的估算期望值且和估算值的期望中值正：l2)对专家的估算结果进行分类摘要。l l(5)组织者召集会议，请专家们对其估算值有很大变动之处进行讨论。专家对此估算值，做一次估算。l(6)在综合专家估算结果的基础上，组织专家再次无记名地填写表格。l从(4)到(6)适当重复几次。最终可获得一个得到多数专家共识的软件规模(源代码数）：l最后，通过与历史资料进行类比，根据过去完成项目的规模和成本等信息，推算出该软件每行源代码所需成本。然后再乘以该软件源代码行数的估算值，得到该软件的成本估算值，53 软件开发成本估算的
36、经验模型l软件开发成本估算的依据是开发成本估算模型。开发成本估算模型通常采用经验公式中预测软件项目计划所需要的成本、工作量和进度。用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的。因此，还没有一种估算模型能够适用于所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用。 l(1)IBM模型l1977年，Walston和Felix总结了IBM联合系统分部(FSD)负责的60个项目的数据。中各项目的源代码行数从400行到467000行，开发工作量从12PM到11758PM，共使用20种不同语言和66种计算机。利用最小二乘法拟合，得到如下估算公式：lE52L0.91D=4.1L0.
37、36=13.47E0.35lS：054E0.6DOC=49L1.01l其中，L是源代码行数(以KLOC计)，E是工作量(以PM计)，D是项目持续时间，S是人员需要量(以人计)，DOC是文档数量(以页计)。 l例如，一个软件的开发工作量如表7所示。该软件共有源代码2900行，其中，500行用于测试，2400行是执行程序的源代码。则劳动生产率是：l(2900500)10240(LOCPM)lIBM模型是一个静态单变量模型，但不是一个通用公式。在应用中有时要根据具体实际l情况，对公式中的参数进行修改。6 风险分析l风险分析实际上是4个不同的活动：风险识别，风险估计，风险评价和风险驾驭。61 风险识别
38、l可用不同的方法对风险进行分类。从宏观上来看，可将风险分为项目风险、技术风险和商业风险。 l项目风险识别潜在的预算、进度、个人(包括人员和组织)、资源、用户和需求方面的问题，以及它们对软件项目的影响。如项目复杂性、规模和结构等都可构成风险因素。 l技术风险识别潜在的设计、实现、接口、检验和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术(不成熟)也是风险因素。技术风险之所以出现是由于问题的解决比所预想的要复杂。 l商业风险有以下5种：(1)建立的软件虽然很优秀但不是真正所想要的(市场风险)；(2)建立的软件不适合整个软件产品战略；(3)销售部门不清楚如何推销这种软件
39、；(4)由于课题改变或人员改变而失去上级管理部门的支持；(5)失去预算或人员的承诺(预算风险)。62 风险估计l风险估计使用两种方法来估价每一种风险。l1.估计一个风险发生的可能性。l2.估计那些与风险有关的问题可能产生的结果。 l项目计划人员与管理人员、技术人员一起，进行4种风险估计活动：l(1)建立一个尺度或标准来表示一个风险的可能性；l(2)描述风险的结果；l(3)估计风险对项目和产品的影响，l(4)确定风险估计的正确性。63 风险评价l在风险分析过程中进行风险评价的时候，应当建立一个三元组：lRi,Li,Xil其中，ri是风险，li是风险出现的可能性(概率)，而xi是风险的影响。在做风
40、险评价时，应当进一步检验在风险估计时所得到的估计的准确性，尝试对已暴露的风险进行优先排队，并着手考虑控制和(或)消除可能出现风险的方法。 l一个对风险评价很有用的技术就是定义风险参照水准。对于大多数软件项目来说，成本、进度和性能就是三种典型的风险参照水准。即就是说，对于成本超支、进度延期、性能降低(或它们的某种组合)，有一个表明导致项目终止的水准。 l果风险的某种组合造成了一些问题，从而超出了一个或多个参照水准，就要中止工作。在做软件风险分析的环境中，一个风险参照水准就有一个单独的点，叫做参照点或崩溃点。在这个点上，要公正地给出可接受的判断，看是继续执行项目工作，还是终止它们(出的问题太大)。
41、因此，可能需要利用性能分析、成本模型、任务网络分析、质量因素分析等做判断。 l图13用图示来表示这种情况。如果因为风险的一个组合引出造成项目成本和进度超出的问题，将有一个水准(在图中用曲线表示)，当超出时，将导致项目终止(黑色阴影区域)。在参照点上，要对作出是继续进行还是终止的判断公正地加权。 l在做风险评价时，按以下步骤执行：l(1)为项目定义风险参照水准；l(2)尝试找出在每个ri，li，xi和每个参照水准之间的关系；l(3)预测参照点组以定义一个终止区域，用一条曲线或一些易变动区域来界定；l(4)努力预测复合的风险组合将如何形成一个参照水准。64 风险驾驭和监控l风险驾驭是指利用某些技术
42、，如原型化、软件自动化、软件心理学、可靠性工程学以及某些项目管理方法等设法避开或转移风险。 l风险驾驭与监控活动的图解说明如图14所示。与每一风险相关的三元组(风险描述，风险可能性、风险影响)是建立风险驾驭(风险消除)步骤的基础。例如，假如人员的频繁流动是一项风险ri，基于过去的历史和管理经验，频繁流动可能性的估算值li为o.70(70%相当高)，而影响xi的估计值是：项目开发时间增加15，总成本增加12 l给出了这些数据之后，建议可使用以下风险驾驭步骤：l(1)与现在在职的人员协商，确定人员流动的原因(如，工作条件差，收入低，人才市场竞争等)；l(2)在项目开始前，把缓解这些原因(避开风险)
43、的工作列入已拟定的驾驭计划中。l(3)当项目启动时，做好人员流动会出现的准备。采取一些办法以确保人员一旦离开时项l目仍能继续(削弱风险)；l(4)建立项目组，以使大家都了解有关开发活动的信息；l(5)制定文档标准，并建立一种机制以保证文档能够及时产生；l(6)对所有工作组织细致的评审(以使更多的人能够按计划进度完成自己的工作)；l(7)对每一个关键性的技术人员，要培养后备人员。 l看图14，风险驾驭步骤要写进风险驾驭与监控计划RMMP(RiskManageandMonitoringPlan)。RMMP记叙了风险分析的全部工作，并且作为整个项目计划的部外为项目管理人员所使用。RMMP的概要在图1
44、5中列出。l一旦制定出RMMP，且项目已开始执行，风险监控就开始了 l风险监控是一种项目追踪活动，它有三个主要目标：l(1)做里程碑事件跟踪和主要风险因素跟踪，判断一个预测的风险事实上是否发生了；l(2)进行风险再估计，确保针对某个风险而制定的风险消除步骤正在合理地使用；l(3)收集可用于将来的风险分析的信息。7 进度安排l软件开发项目的进度安排有两种考虑方式：l(1)系统最终交付日期已经确定，软件开发部门必须在规定期限内完成；l(2)系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定。71 软件开发小组人数与软件生产率l对于一个小型的软件开发项目，一个人就可以完成需求分析、设
45、计、编码和测试工作。但是，随着软件开发项目规模的增大，就会有更多的人共同参与同一软件项目的工作。例如10个人1年可以完成的项目，若让1个人干10年是不行的。因此，需要多人组成开发小组共同参加个项目的开发。当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即通信问题。通信需花费时间和代价，会引起软件错误增加，降低软件生产率。 l若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个软件开发小组有n个人，每两人之间都需要通信，则总的通信路径有n(n一1)2(条) l假设一个人单独开发软件，生产率是5000行人年。若4个人组成一个小组共同
46、开发这个软件，则需要6条通信路径，如图1316(a)所示。若在每条通信路径上耗费的工作量是250行人年。则小组中每个人的软件生产率降低为500062504=5000375=4625行人年如果小组有6名成员，通信路径增加到15条，如图1316(b)所示。每条通信路径消耗的工作量不变，则小组中每个成员的软件生产率降低为l5000152506=50006254375行人年。72 任务的确定与并行性l当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。图17表示了一个典型的由多人参加的软件工程项目的任务图。 l在图17中可以看到，软件开发进程中设置了许多里程碑。里程碑为管理人员提供了
47、指示项目进度的可靠依据。当一个软件工程任务成功地通过了评审并产生了文档之后，就完成了一个里程碑。73 制定开发进度计划l在133节讨论的每一项软件估算技术都能得出完成软件开发任务所需人月(或人年)数的估算值。有一种常用来估计在整个定义与开发阶段工作量分配的建议方案，称为40一20一40规则。它指出在整个软件开发过程中，编码的工作量仅占20，编码前的工作量占40，编码后的工作量占40。事实上，这个规则相当粗糙，只能用来作为一个指南。实际的工作量分配比例必须按照每个项目的特点来决定。74 进度安排的图形方法l软件项目的进度安排与任何一个多重任务工作的进度安排基本差不多，因此，只要稍加修改，就可以把
48、用于一般开发项目的进度安排的技术和工具应用于软件项目。(1)甘特图(GanttChart)l甘特图用水平线段表示任务的工作阶段；线段的起点和终点分别对应着任务的开工时间和完成时间；线段的长度表示完成任务所需的时间。l图18给出一个具有5个任务的甘特图(任务名分别为A、B、C、D、E)。如果这5条线段分别代表完成任务的计划时间，则在横坐标方向附加一条可向右移动的纵线。它可随着项目的进展，表明已完成的任务(纵线扫过的)和有待完成的任务(纵线尚未扫过的)。从甘特图上可以很清楚地看出各子任务在时间上的对比关系。 l在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是必须交付应交付的文
49、档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。甘特图的优点是标明了各任务的计划进度和当前进度，能动态地反映软件开发进展情况。l缺点是难以反映多个任务之间存在的复杂的逻辑关系。(2)PERT技术和CPM方法lPERT技 术 叫 做 计 划 评 审 技 术 (Porgram EvaluationReview Technique)， CPM方 法 叫 做 关 键 路 径 法(CriticalPathMethod)，它们都是安排开发进度，制定软件开发计划最常用的方法。它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图的形式表示出来。
50、通常用两张图来定义网络图。一张图给出某一特定软件项目的所有任务(也称为任务分解结构WorkBreakdownStructure)，另一张图给出应按照什么次序来完成这些任务，给出各个任务之间的衔接(有时称为限制表RestrictionList)。 lPERT技术和CPM方法都为项目计划人员提供了一些定量的工具，以：l1)确定关键路径，即决定项目开发时间的任务链。l2)应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值。l3)计算边界时间，为具体的任务定义时间窗口。 l重要的边界时间有：任务可以开始的最早时间；在保证项目不被延迟的情况下任务的最迟开始时间；任务的最早完成时间；任务的最
51、迟完成时间；以及在安排进度计划时，为保证网络上关键路径能按进度要求执行而允许的时间余量。边界时间的计算使得计划人员能够确定关键路径，为管理人员提供一种定量的方法，用以在某些任务完成的时候评估项目的进展情况。 l下面举例说明。假定某一开发项目在进入编码阶段之后，考虑如何安排三个模块A、B、C的开发工作。其中，模块A是公用模块，模块B与C的测试有赖于模块A调试的完成。模块C是利用现成已有的模块，但对它要在理解之后做部分修改。最后直到A、B和C做组装测试为止。这些工作步骤按图19来安排。在此图中，各边表示要完成的任务，边上均标注任务的名字，如“A编码”表示模块A的编码工作。边上的数字表示完成该任务的
52、持续时间。图中有数字编号的结点是任务的起点和终点，在图中，o号结点是整个任务网络的起点，8号结点是终点。图中足够明确地表明了各项任务的计划时间，以及各项任务之间的依赖关系。 l在组织较为复杂的项目任务时，或是需要对特定的任务进一步做更为详细的计划时，可以使用分层的任务网络图。图20表明，在父图No0上的任务P和Q均已分解出对应的两个子图：No1和No2。 l了有效地使用PERT技术或CPM方法，来控制进度安排的实施，可以把网络图及相关的表格存入计算机，并配以相应的软件支持，使它成为强有力的进度计划工具。目前在计算机上已实 现 的 相 应 自 动 计 划 调 度 工 具 有 AppleMacin
53、tosh上 的 MacProject， 486上 的 Microsoft Project等，对于较大规模或较为复杂的软件项目，这类工具能起到一定的辅助和指导作用。 l最后，在软件工程项目中必须处理好进度与质量之间的关系。在软件开发实践中常常会遇到这样的事情，当任务未能按计划完成时，只好设法加快进度赶上去。但事实说明，在进度压力下赶任务，其成果往往是以牺牲产品的质量为代价的。还应当注意到，产品的质量与生产率有着密切的关系。日本人有个说法：在价格和质量上折衷是不可能的，但软件工程过程的高质量给生产者带来了成本的下降这一事实是可以理解的。在日本的一些公司中，如日立、富士通公司中，项目组(Projec
54、tTe9m)对未能圆满完成的产品的交付具有否决权，尽管顾客声称“我愿降低标准验收”。75 项目的追踪和控制l项目管理的一项重要工作就是在项目实施过程中进行追踪和控制。 可以用不同的方式进行追踪：定期举行项目状态会议。在会上，每一位项目成员报告他的进展和遇到的问题。评价在软件工程过程中所产生的所有评审的结果。确定由项目的计划进度所安排的可能选择的正式的里程碑。比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价。实际上有经验的项目管理人员已经使用了所有这些追踪技术。 l软件项目管理人员还利用“控制”来管理项目资
55、源、覆盖问题、及指导项目工作人员。如果事情进行得顺利(即项目按进度安排要求且在预算内实施，各种评审表明进展正常且正在逐步达到里程碑)，控制可以放松一些。但当问题出现的时候，项目管理人员必须实行控制以尽可能快地排解它们。在诊断出问题之后，在问题领域可能需要一些追加资源；人员可能要重新部署，或者项目进度要重新调整。8 项目的组织与计划l81 GIS项目管理的特点lGIS项目管理的解决，涉及到系统工程学、统计学、心理学、社会学、经济学，乃至法律等方面的问题。需要用到多方面的综合知识，特别是要涉及到社会的因素、精神的因素、人的因素，比技术问题复杂得多。仅靠技术、工程或科研项目的效率、质量、成本和进度等
56、问题很难得到较好的解决。必须结合工作条件、人员和社会环境等多种因素。 l因此，简单地照搬国外的管理技术往往不一定奏效。此外，管理技术的基础是实践，为取得管理技术的成果必须反复实践。很显然，管理能够带来效率，能够赢得时间，最终将在技术前进的道路上取得领先地位。在知识爆炸、高技术迅速发展的今天，必须在战略级上对待技术管理问题。(1)GIS项目的特点lGIS产品与其他任何产业的产品不同，它是难以理解，难于架驭。但它确实是把思想、概念、算法、流程、组织、效率、优化等融合在一起了。因此，要开发这样的产品，在许多情况下，用户一开始给不出明确的想法，提不出确切的要求。他说不清究竟他需要的是什么。在开发的过程
57、中，程序与其相关的文档常常需要修改。在修改的过程中又可能产生新的问题，并且这些问题很可能在过了相当长的时间以后才会发现。文档编制的工作量在整个项目研制过程中占有很大的比重。但从实践中看出，人们对它不感兴趣、认为是不得不做的苦差事，不愿认真地去做。因而直接影响了软件的质量。软件开发工作技术性很强，要求参加工作的人员具有一定的技术水平和实际工作的经验。但事实上，人员的流动对工作的影响很大。离去的人员不但带走了重要的信息，还带走了工作经验。(2)GIS项目管理的困难l1)智力密集，可见性差：工程过程充满了大量高强度的脑力劳动。软件产品的质量难以用简单的尺度加以度量。对于不深入掌握GIS软件知识或缺乏
58、软件开发实践经验的人员，是不可能领导做好管理工作的。软件开发任务完成得好也看不见，完成得不好有时也能制造假象，欺骗外行的领导。 l2)单件生产：在特定机型上，利用特定硬件配置，由特定的系统软件或支撑软件的支持，形成了特定的开发环境。再加上项目特定的目标，采用特定的开发方法、工具和语言，使得软件具有独一无二的特色，几乎找不到与之完全相同的产品。这种建立在内容、形式各异的基础上的研制或生产方式，与其他领域中大规模现代化生产有着很大的差别，也自然会给管理工作造成许多实际困难。 l3)劳动密集，自动化程度低：GIS项目经历的各个阶段都渗透了大量的手工劳动，这些劳动十分细致、复杂和容易出错。尽管近年来开
59、展了软件工具和CASE的研究，但总体来说，仍远未达到自动化的程度。GIS产业所处的这一状态，加上软件的复杂性，使得软件的开发和维护难以避免出错，软件的正确性难于保证，软件产品质量的提高自然受到了很大的影响。 l4)使用方法繁琐，维护困难：用户使用软件需要掌握计算机的基本知识，或者接受专门的培训，否则面对多种使用手册、说明和繁琐的操作步骤，学会使用要花费很大力气。另一方面，如果遇到软件运行出了问题，且没有配备专职维护人员，又得不到开发部门及时的售后服务，软件的使用者更是徒唤奈何。 l5)GIS工作渗透了人的因素：为高质量地完成项目，充分发掘人员的智力才能和创造精神，不仅要求软件人员具有一定的技术
60、水平和工作经验，而且还要求他们具有良好的心理素质。GIS人员的情绪和他们的工作环境，对他们工作有很大的影响。与其他行业相比，它的这一特点十分突出，必须给予足够的重视。 (3)造成失误的原因l在总结和分析足够数量失误的GIS项目之后，看出其原因大多与管理工作有关。l在项目开始执行时，遇到的问题往往是可供利用的资料太少、项目负责人的责任不明确、项目的定义模糊、没有计划或计划过分粗糙、资源要求未按时作出安排而落空、没有明确规定子项目完成的标准、缺乏使用工具的知识、项目已有更动，但预算未随之改变。 l在项目执行的过程中可能会发生的问题是项目审查只注意琐事而走过场、人员变动造成对工作的干扰、项目进行情况
61、未能定期汇报、对阶段评审和评审中发现的问题如何处置未作出明确规定、资源要求并不像原来预计的那样大、未能做到严格遵循需求说明书、项目管理人员不足。 l项目进行到最后阶段可能会发生的问题是未做质量评价、取得的知识和经验很少交流、未对人员工作情况做出评定、未做严格的移交、扩充性建议未写入文档资料。l总之，问题涉及到GIS项目研制中的计划制定、进度估计、资源使用、人员配备、组织机构和管理方法等管理的许多侧面。(4)GIS项目管理的主要职能l管理的主要职能包括：l1)制定计划：规定待完成的任务、要求、资源、人力和进度等。l2)建立组织：为实施计划，保证任务的完成，需要建立分工明确的责任制机构。l3)配备
62、人员：任用各种层次的技术人员和管理人员。l4)指导：鼓励和动员软件人员完成所分配的工作。l5)检验：对照计划或标准，监督和检查实施的情况。l以下将针对项目管理的主要问题进行讨论。82 制定计划l开发项目的计划涉及到实施项目的各个环节，带有全局的性质。计划的合理性和准确性往往关系着项目的成败。据美国联邦政府调查，因计划不当而造成项目失败占失败总数的一半以上。计划应力求完备。要考虑到一些未知因素和不确定因素，考虑到可能的修改。计划应力求准确。尽可能提高所依据数据的可靠程度。(1)制定计划的目的和进行风险分析l为了使软件项目取得成功，在正式开始之前，做好计划工作的必要性是显而易见的。制定计划的目的就
63、是要回答：这个软件项目的范围是什么?需要哪些资源?花费多少工作量?要用的成本有多少?以及进度如何安排等等一系列问题。(2）GIS计划的类型l针对不同的工作目标，计划的可以有以下多种类型：l1)项目实施计划(或称为开发计划)：这是开发的综合性计划，通常应包括任务、进度、人力、环境、资源、组织等多个方面。l2)质量保证计划：把软件开发的质量要求具体规定为在每个开发阶段中可以检查的质量保证活动。l3)软件测试计划：规定测试活动的任务、测试方法、进度、资源、人员职责等。l4)文档编制计划：规定所开发项目应编制的文档种类、内容、进度、人员职责等。l5)用户培训计划：规定对用户进行培训的目标、要求、进度、
64、人员职责等。l6)综合支持计划：规定开发过程中所需要的支持，以及如何获取和利用这些支持。l7)软件分发计划：软件开发项目完成后，如何提供给用户。(3)项目实施计划中任务的划分llGIS项目的实施，进行工作的划分是实施计划首先应解决的问题。常用的计划结构有：l1)按 阶 段 进 行 项 目 的 计 划 工 作 (Phased ProjectPlanning)l按生存期，把全部项目开发工作划分为若干阶段(究竟分为几个阶段，由管理部门具体规定)，对每个阶段的工作做出阶段计划。再把每个阶段工作进一步分解为若干个任务，做出任务计划。还要把任务细分为若干步骤，做出步骤计划。这样三层次的计划成为整个项目计划
65、的依据。显然，过细地做好分层计划，可以提高计划的精确度，减少或及早地发现问题。 l2)任务分解结构(WorkBreakdownStructure)l按项目的实际情况进行自顶向下的结构化分解，形成树形任务结构，如图21所示。l进一步把工作内容、所需的工作量、预计完成的期限也规定下来。这样可以把划分后的工作落实到人，做到责任明确，便于监督检查。3)任务责任矩阵(Task Responsibility Matrix)在任务分解的基础上，把工作分配给相关的人员，用一个矩阵形表格表示任务的分工和责任。例如，把图2l已分解的任务分配给五位软件开发人员，图22表明了利用任务责任矩阵表达的分工情况。从图中可以
66、看出，工作的责任和任务的层次关系都是非常明确的。83 项目组织的建立l如何组织参加软件项目的人员，使他们发挥最大的工作效率，对成功地完成软件项目至关重要。开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参与人员的素质有关。l人的因素是不容忽视的参数。对于国情、体制、人员的工作习惯等都应作具体分析。了解并参考国外的做法是必要的，但无论如何不应简单地搬用。（1）组织原则l在建立项目组织时应注意到以下原则：l1)尽早落实责任：在软件项目工作的开始，要尽早指定专人负责。使他有权进行管理，并对任务的完成负全责。l2)减少接口：在开发过程中，人与人之间的联系是必不可少的，存在着通信路径。从前面可
67、知，一个组织的生产率是和完成任务中存在的通信路径数目是互相矛盾的。因此，要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。l3)责权均衡：经理人员所负的责任不应比委任给他的权力还大。(2)组织结构的模式l通常有三种组织结构的模式可供选择：l1)按课题划分的模式(ProjectFormat)l把人员按课题组成小组，小组成员自始至终参加所承担课题的各项任务。他们应负责完成产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。l2)按职能划分的模式(FunctionalFormat)l把参加开发项目的软件人员按任务的工作阶段划分成若干个专业小组。 l在每个专业
68、小组完成阶段加工(即工序)以后，沿工序流水线向下传递。例如，分别建立计划组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等。各种文档资料按工序在各组之间传递。这种模式在小组之间的联系形成的接口较多，但便于软件人员熟悉小组的工作，进而变成这方面的专家。3)矩阵形模式(Matrix Format)l这种模式实际上是以上两种模式的复合。一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组等；另一方面，每一个项目又有它的经理人员负责管理。每个软件人员属于某一个专门组，又参加某一项目的工作。例如，属于测试组的一个成员，他参加了某一项目的研制工作，因此他要接受双重领导（一是测试组，一
69、是该软件项目的经理）。如图23所示。l矩阵形结构组织的优点是：参加专门组的成员可在组内交流在各项目中取得的经验，这更有利于发挥专业人员的作用。而且各个项目有专人负责，有利于项目的完成。84 人员配备l如何合理地配备人员，也是成功地完成软件项目的切实保证。所谓合理地配备人员应包括：按不同阶段适时任用人员，恰当掌握用人标准。l项目经理、软件工程师、硬件工程师、l数据工程师(2)配备人员的原则l配备人员时，应注意以下三个主要原则：l1)重质量：GIS项目是技术性很强的工作，任用少量有实践经验、有能力的人员去完成关键性的任务，常常要比使用较多的经验不足的人员更有效。l2)重培训：花力气培养所需的技术人
70、员和管理人员是有效解决人员问题的好方法。l3)双阶梯提升：人员的提升应分别按技术职务和管理职务进行，不能混在一起。(3)对项目经理人员的要求l软件经理人员是工作的组织者，他的管理能力的强弱是项目成败的关键。除去一般的管理要求外，他应具有以下能力：l1)把用户提出的非技术性要求加以整理提炼，以技术说明书形式转告给分析员和测试员。l2)能说服用户放弃一些不切实际的要求，以便保证合理的要求得以满足。l3)能够把表面上似乎无关的要求集中在一起，归结为“需要什么”，“要解决什么问题”、这是一种综合问题的能力。l4)要懂得心理学，能说服上级领导和用户，让他们理解什么是不合理的要求。但又要使他们毫不勉强，乐
71、于接受，并受到启发。(4)评价人员的条件lGIS项目中人的因素越来越受到重视。在评价和任用人员时，必须掌握一定的标准人员素质的优劣常常影响到项目的成败。能否达到以下这些条件是不应忽视的。l1)牢固掌握GIS的基本知识和技能。l2)善于分析和综合问题，具有严密的逻辑思维能力。l3)工作踏实、细致，不靠碰运气，遵循标准和规范，具有严格的利学作风。l4)工作中表现出有耐心、有毅力、有责任心。l5)善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系。l6)具有良好的书面和口头表达能力。85指导与检验l指导的目的是在软件项目的过程中，动员和促进工作人员积极完成所分配的任务。实际上，指导也是属
72、于人员管理的范围，是组织好GIS项目不可缺少的工作。l检验是GIS项目管理的最后一个方面。它是对照计划检查执行情况的过程，同时也是对照软件工程标准检查实施情况的过程。在发现项目的实施与计划或标准有较大的偏离时，应采取措施加以解决。(3)检验管理的工作范围l检验管理在软件项目中可能涉及到以下几个方面。l1)质量管理：包括明确度量质量的因素和准则，决定质量管理的方法和工具，以及实施质量管理的组织形式。l2)进度管理：检验进度计划执行的情况。l3)成本管理：度量并控制项目的开销。l4)文档管理：检验文档编写是否符合要求。l5)配置管理：检验软件配置。(4)开发人员的办公环境l有许多因素影响着软件工作的效率。DeMarco曾于1984年到1986年在62个公司的600名软件人员中进行编码和测试的竞赛活动，并对竞赛结果进行统计分析。结果表明，除了对语言的熟悉程度、工作年限、工资收入等因素以外，环境因素因素着很大的作用。良好的办公环境可保证软件人员高质量地完成任务。这里所说的办公环境是指每个软件人员的办公室工作面积、办公环境安静程度、专用程度、电话干扰程度、工作时间内外面来访人员次数等。DeMarco说，对于一名项目管理人员，如果为软件人员安排了任务，提供了工作条件，而对工作环境所带来的影响估计不足，那么，这位管理人员还是应该承担责任。9、项目分解与管理l
