项目管理案例库.docVIP

附件 《软件项目管理》课程教学案例库的构建 项目案例 软件开发过程定义出现的问题--组织内没有定义和文档化且易于理解的软件开发过程 许多软件开发组织，没有完全包含一个已定义的、可重复的、可预测的软件开发过程。这样的结果通常极大地增加了项目在预测和控制进度、成本、功能与质量等主要因素上的风险。 一．项目案例 在软件开发项目中富有经验的大多数人都对遵循定义完善的、文档化的软件开发过程的重要性有良好的意识。他们能回想起所经历问题的许多例子，这些例子都是第一手材料，是由于项目所遵循的过程定义很差，或者忽视了以前项目中得到的教训而导致的。 下面关于软件项目的小案例中具有全部“正当”的意图，但在定义和文档化软件开发过程时都忽视了某些重要的问题。当你读完这个案例时，问问自己是否在你过去的项目中预见到这些问题了？而且，这些问题中的许多部分，你在当前从事的项目中是否已经把它们作为与过程相关的问题沉痛警示了呢？ 开发组织已运作7年了，在7年中，开发了大量的产品，并交付给用户使用。在组织内洞察力敏锐的人认识到所有的项目都超期并超出了预算，一些项目只是超出了一点，但大多数项目都严重超支或超期。而且，所有的项目都经历了数量级比必要或预想都大得多的质量问题。然而，尽管进度、预算和质量问题经常困扰着项目，但整个组织仍继续发展壮大，即使产品不像期望的那样好，但产品仍继续销售。 在给定时间内，几个项目都在开发中。应注意到组织内没有定义和文档化易于理解的软件开发过程。每个项目或者从零开始定义自己的软件过程，或者部分遵循最近开发的软件项目所使用的过程。让我们仔细研究其中的一个项目，看看它能揭示出什么问题。让我们随意选出一个项目TKO来进行研究。 《例1》 Mark Tyson被选去领导项目TKO。由于没有易于理解的软件开发过程作为制定项目软件过程的参照点，他花费了比预想更多的时间去定义项目的软件过程。之后他立即忙于反复修改几个活动的性能，时间很紧迫，只能定义一个项目过程框架。他定义的软件开发过程列出了所有在项目中必须执行的活动。遗憾的是，Tyson没有时间文档化所有活动的含义。例如，只有他知道他实际期望的产品规格包含哪些内容，或者在高层和低层设计间有哪些差别，或单元测试意味着什么等等。Tyson没有太考虑缺乏文档化过程的结果，他觉得自己能在恰当的时间通过口头或简单的注释把这些信息传递给他的小组。 如预想的一样，Tyson在让项目组成员接受他定义的过程时没有遇到任何麻烦。为什么？因为没有人真正理解每个活动所意味的范围。因此，每个人都感到与其说凭借他们个人想法来理解这些活动，还不如说被授权以一种方式解释这些活动。当制定估算进度表和成本预算时，这种自我解释导致的冲突第一次发生了。为了执行这个计划，所有项目成员必须解释他们认为的Tyson定义的每个活动和计划的范围含义，而不是真正的含义。坦率地说，许多成员对Tyson意图上指示的每个活动的范围意义不太感兴趣，他们对自己认为的每个活动范围应该是什么更感兴趣。因此，造成了在解释每个活动范围上的不一致。 当Tyson定义过程时，他注重于列出所有要执行的活动，但没有对每个活动代表的所有范围文档化，并且他忽略了对活动开始或者完成前所要满足的入口和出口条件进行文档化。因此，在TKO项目进展过程中，Tyson开始看到活动在它们预定的时间段前“完成”了。 例如，与过程相关的重大问题在产品规格说明书被批准时就变成了轻微的问题。Tyson本想如果适当的话，完成所有的高层设计，并且在检查高层设计时发现所有的问题，纠正它们并将它们反映到规格说明书中。遗憾的是，规格说明书的负责人认为即使是高层设计没有完成或说明书已经做了适当修改，这些规格说明书也可以被认为是完成了的。而且，Tyson本来期望所有的用户界面，例如屏幕界面、提示信息都在规格说明书中有所反映，然而实际却没有。产品功能只以叙述的方式描述，而不是以用户期望的方式描述。当Tyson发现产品说明书中的这些问题时，他命令要修改规格说明书并且重新审批。作为项目领导，他可以强制这样做，但付出了进度延期、增加项目成本以及使一些项目成员不高兴的代价。 与过程相关的问题不断发生。例如，许多项目成员没有计划要检查他们负责的高层或低层设计及代码。因此，当Tyson意识到人们没有执行相应的检查就宣称他们的设计和编码已经完成时，他坚持让这些人回去执行相应的检查。由于许多项目成员最初没有为检查做计划，因此，他们随后的活动就落后于计划。最终，Tyson取消了他的命令，允许一些设计和代码没有检查就进入测试。这个决定导致了低质量的代码进入测试阶段。 《例2》 出现许多与过程相关的问题的另一个例子是：Tyson本期望功能测试、构件测试和系统测试的计划能包含一个详