软件项目管理第4章需求开发和需求管理.ppt

4.1 从一幅幽默画看到的需求问题　　软件危机不是危言耸听，在软件开发过程中会发生各种各样的问题，甚至是挺荒唐的事，所以才有了如图4.1所示的这张经典的幽默画。该画讽刺了软件工程的低水平开发和管理。　　图4.1表明了软件组织中各种角色对软件要实现的功能特性有不同的理解，经过各个环节，误差被不断放大，最终产生令人啼笑皆非的结果。分析其原因，有以下几条：　　·客户没有把自己的需求描述清楚，一开始就有问题。　　·项目经理没有认真倾听客户的需求，客户的需求打了折扣。 　　·分析人员进一步误解了客户的需求，设计的内容可能到了不可理喻的地步。　　·程序员写的代码也是漏洞百出，使原来就很糟糕的功能设计雪上加霜。　　·业务咨询师却将软件功能吹嘘得天花乱坠。　　·项目过程中忽视文档，几乎是一片空白。　　·软件在安装之后，某些功能不能正常工作，或几乎不可用。　　·还是照样按照高科技产品收取客户的费用。　　·技术支持人员可能将问题弄得更糟糕…… 　　 图4.1 讽刺软件工程危机的著名幽默画(不同的角色对软件的理解不同， 而且经过各环节放大后，误差被不断放大) 4.1.1 每个项目都有需求　　Frederick Brooks在他1987年的经典文章《No Silver Bullet: Essence and Accidents of Software Engineering》中充分说明了需求过程在软件项目中扮演的重要角色：　　开发软件系统最困难的部分就是准确说明要开发什么。最困难的概念性工作便是编写详细技术需求，包括所有面向用户、面向机器和其他软件系统的接口。该工作一旦做错，最终会给系统带来极大损害，而且以后再对它修改也极为困难。 　　每个软件产品都是为了使用户能以某种方式改善其工作和生活，因此，花在了解用户需求上的时间便是项目成功的高层投资。对商业的最终用户应用程序，企业信息系统和软件作为一个大系统的某一部分的产品是显而易见的。但是，对开发人员来说，并没有编写客户认可的需求文档，又怎么知道项目何时结束呢？如果不知道什么对客户来说很重要，又怎么能使客户感到满意呢？　　而且，即便非商业目的的软件需求也是必需的，例如软件库、组件和工具等供开发小组内部使用的软件，当然也可能偶尔不需文档说明就与其他人意见接近一致，但是，更常见的是出现重复返工这种不可避免的后果。无论怎样，重新编制代码的代价远远超过重写一份需求文档的代价。 4.1.2 需求是软件项目成败的关键　　解决问题的第一步是理解问题。Standish Group公司在调查中让被调查人员确定项目的重要因素，项目分为“成功”、“遇到困难”(推迟且没有达到预期)以及“损坏”(被取消)。调查数据表明，与软件开发有关的、最常见、最严重的问题都与需求有关。Standish Group公司(1994)研究特别指出了三种最经常提到的使项目“遇到困难”的因素：　　·缺乏用户输入：占所有项目的13%；　　·不完整的需求和规格说明：占所有项目的12%；　　·不断改变的需求和规格说明：占所有项目的12%。 　　当然，项目失败的原因还有很多，可能是不合理的进度或时间安排(4%)、人力和资源不足(6%)或技术技能不够(7%)，以及其他诸多原因。Standish的数据在业界具有代表性，研究表明至少三分之一的软件项目是因为与需求获取、需求文档和需求管理有关的原因而陷入困境的。　　很多项目都有进度的推迟或预算的超支，如果没有取消的话，Standish Group发现大公司9%的项目是按时在预算内交付的；小公司16%的项目是成功的。那么，项目最主要的“成功因素”是什么？根据Standish Group的研究，三个最重要的因素是： 　　·用户介入：占所有成功项目的16%；　　·高层管理支持：占所有成功项目的14%；　　·需求陈述清晰：占所有成功项目的12%。　　根据IDC(International Data Corporation)的统计，80%失败的IT项目是由于需求分析做得不好，没有真正反映用户的需求。根据Standish Group的分析，项目失败最重要的8个原因中的5个都与需求有关：　　·不完整的需求；　　·缺少用户参与；　　·不实际的客户期望；　　·需求和规范的变更；　　·提供不再需要的能力。 　　此外，CHAOS大学工作人员Sanjiv指出：“如果没有搞定需求，则项目一定会失败；如果搞定需求，则项目一定会交付。”1995年，ESPITI(European Software Process Improvement Training Initiative)调查了3800人以确定在产业中相对重要的软件问题，调查也印证了Standish Group公司的调查结果。相对而言，