软件项目计划与管理.pptVIP

上述定义强调了下述三个要点： （1）软件需求是度量软件质量的基础，软件与对它的需求不一致就是质量不高。 （2）指定的标准定义了一组指导软件开发的准则，如果没有严格遵守这些准则，几乎肯定会导致质量不高。 （3）通常，有一组没有显式描述的隐含需求（例如，软件应该易学、易用、易维护）。如果软件虽然满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。 图9.9 现代程序员组 由于程序员组的人数不宜过多，当软件项目规模较大时，应该把程序员分成若干个小组，采用图9.10所示的组织结构。该图描绘的是技术管理组织的结构，非技术管理组织的结构与此类似。由图可以看出，产品作为一个整体其开发工作是在项目经理的指导下进行的，程序员向他们的组长汇报工作，而组长向项目经理汇报工作。当产品规模更大时，可以再增加中间管理层次。 图9.10 大型项目的技术管理组织结构 把民主制程序员组和主程序员组的优点结合起来的另一种方法，是在合适的地方采用分散做决定的方法，如图7.10所示。这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关。这种组织方式对于适合采用民主方法的那类问题（例如，研究性项目或遇到技术难题需要用集体智慧攻关）非常有效。尽管这种组织方式适当地发扬了民主，但是上下级之间的箭头（即管理关系）仍然是向下的，也就是说，是在集中指导下发扬民主。显然，如果程序员可以指挥项目经理，则只会引起混乱。 图9.11 包含分散决策的组织方式 9.5 质 量 保 证 质量是产品的生命，不论生产何种产品，质量都是极其重要的。软件产品开发周期长，耗费巨大的人力和物力，更必须特别注意保证质量。 软件质量的定义 概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应该具有的隐含特征相符合的程度。 估算开发时间 通常，成本估计模型也同时为我们提供估算开发时间T的方程。与工作量方程不同，各种模型估算开发时间的方程非常类似，如下所示： （1）Walston-Felix模型 T＝2.5E 0.35 （2）原始COCOMO模型 T＝2.5E 0.38 （3）COCOMO 2模型 T＝3.0E 0.33＋0.2×(b－1.01) （4）Putnam模型 T＝2.4E1／3 E为开发工作量（以人月为单位）， T为开发时间（以月为单位）。 用上列方程计算出的T值，代表正常开发时间。客户往往希望缩短软件的开发时间，显然，为了缩短开发时间应该增加从事开发工作的人数。 但是，经验告诉我们，随着开发小组规模增大，个人的生产率将下降。出现这种现象主要有下述两个原因： ● 当小组变得更大时，每个人需要用更多时间与组内其他成员讨论问题、协调工作，因此，通信开销增加了。 ● 如果在开发过程中增加小组人员，则最初一段时间内项目组总生产率不仅不会提高反而会下降。这是因为开始时新成员还不是生产力，而且在他们学习期间还需要花费小组其他成员的时间。 综合上述两个原因，存在被称为Brooks规律的下述现象：向一个已经延期的项目增加人力，只会使得它更加延期。 事实上，做任何事情都需要时间。我们不可能用“人力换时间”的办法无限制地缩短一个软件项目的开发时间。Boehm根据经验指出，软件项目开发时间最多可以减少至正常开发时间的75%。如果试图把开发时间压缩得太短，则成功的概率几乎为0。 甘特（Gantt）图 估算出完成软件项目所需要的开发时间之后，就可以着手制定进度计划了。Gantt图是历史悠久、应用广泛的进度计划工具，下面通过一个非常简单的例子介绍这种工具。 假设有一座陈旧的矩形木板房需要重新油漆。这项工作必须分三步完成：首先刮掉旧漆，然后刷上新漆，最后清除溅在窗户上的油漆。假设一共分配了15名工人去完成这项工作，然而工具却很有限：只有5把刮旧漆用的刮板，5把刷漆用的刷子，5把清除溅在窗户上的油漆用的小刮刀。怎样安排才能使工作进行得更有效呢? 一种做法是首先刮掉四面墙壁上的旧漆，然后给每面墙壁都刷上新漆，最后清除溅在每个窗户上的油漆。显然这是效率最低的做法，因为总共有15名工人，然而每种工具却只有5件，这样安排工作在任何时候都有10名工人闲着没活干。 表9.5 各道工序估计需用的时间（小时）