面向对象软件开发教程02-2.docVIP

2.1.5 增加项目成功机会 开发人员不能准时向用户提交可以承担得起的并能达到用户要求的系统，这都已经形成一种传统了。作为软件专家，我们需要找到能够以一种快速廉价的方式开发出高质量系统的方法：面向对象就是一个解决方案。我认为一个项目如果按时、按预算并且达到了用户要求，那它就算成功了。不幸的是，在这样的定义下，几乎每个系统开发项目都失败了。尽管初看时我的定义显得过于苛刻，但它实际上却是非常公平的。为了让你相信该定义的合理性，考虑下面这样的场景： 你和你的爱人鼓足勇气决定定制一套住宅，你找到住宅开发商，谈了自己的要求和预算，并且告诉他要制定出一个计划。在下一次你们会面时，开发商会给你看叫做原型（样板）的东西，原型是用纸板按比例做成的。因为它并不是你想要的东西，所以你告诉开发商需要做一小点儿改动。在几次会面之后，但你终于有了你喜欢的住宅设计。开发商制定了建筑计划，在下次见面时就与你签订了契约。但你并不是建筑师，因此你并不理解那些制图，它们看上去很复杂，这使你觉得它们应该是正确的。你和开发商经过商榷，最终定价200 000美元，6月14日左右完成（现在是3月2号）。 时间一点点过去了，每两周你都会收到来自开发商的一个进度报表。尽管他不断地告诉你一切都进行的非常顺利，你开始怀疑一些地方出了问题。在5月份的最后一个星期，你接到开发商的一个电话：“哎呀，看上去进度得推迟一点儿了，因为事先无法预料的情况，我们必须拆掉重建房屋的一部分，因此可能要到7月30日才能完工。”你站在那里有些不相信自己的耳朵，你的住宅将推迟7周才能完成，比预期浮动了50％。那你住在哪里呢？更糟糕的是，开发商告诉你：“顺便说一句，我们的预算可能有些超支。既然实际上我们已经开始建房了，那就给我们一个更合理的价钱——400 000美元。”你努力使自己保持在清醒的状态，你开始意识到400 000美元相当于预算的两倍。虽然非常不高兴，但你已经投了一笔钱，因此决定让开发商继续进行下去。 8月14号过去了，你终于可以搬进新家（又推迟了两周）。你并不十分介意所有这一切，因为最后支票是385 000美元。你走进前厅，准备开灯，发现那里并没有安装电灯的开关。你找到开发商询问他应该怎样开灯。“你房间里需要电灯吗，你事前并没有给我说呀。”你非常生气，回敬到：“我当然需要电灯了。嘿，墙上插座在那儿？难道这房子里没有电吗？” 开发商说：“建筑计划或原型里并没有提及任何电气配线，难道你没注意到吗？你在上面确实也签过字了。这就是你要的房子，你最好先适应一下。” 你不敢相信所有这一切，大声喊叫：“这并不正确！你这个无能的家伙！你再也无法在本镇工作了！从我家里滚开！”开发商马上退出门去，走向他的卡车，小声屏气说：“这是他们自己的问题，他们并不知道自己想要什么，我没法理解他们的意图，他们就会指责是我的错。这些家伙像小孩子一样愚蠢。” 用户是业务专家，他们是惟一能够告诉你需求是什么的人。 是不是听上去很熟悉？如果这些事情真的发生在你们身上，你们还会高兴吗？考虑一下当系统延期、超预算、没有达到用户需求时用户的感受？在上面这个场景中，住宅开发商没有从客户那里得到正确的规范说明。原型对于理解客户的需求的的确确是一种非常有效的技巧，但它们没有提供给用户足够的房屋设计细节信息。当然了，忘记铺设电线看上去还应该算是一个非常明显的问题。然而系统开发人员却经常忘记一些对于用户来说很基本而明显的功能。开发人员忘记这些功能的原因不在于他们没有能力，而是因为我们对业务并不十分了解，不能提出正确的问题。 你需要能够传达所需信息并且是用户可以理解的模型。 住宅开发商给客户看了他们无法理解但还必须接受的制图（模型）。这里最为基本的问题是找不到一种合适的方法有效地和客户沟通设计思想。客户需要的是一种易于理解的模型，但仍要给出足够的关于房屋设计的细节。开发商的原型很简单，但缺乏足够多的细节，而建筑计划又过于复杂了。就像住宅开发商一样，作为系统开发商你必须以一种用户可以理解的方式和他们一起交流你的设计思想。 开发商离开后交付了一套不能满足用户要求的住宅。如果购买住宅的人在房屋建设过程中更多地参与了建设活动，他可能会发现房屋里需要布置电线。这是使用结构化技术开发系统中常见的一种错误。尽管我们知道，如果用户更多地参与开发过程，项目成功的可能性将会变大，但用户通常只参与分析以及用户接受测试，而并不参与设计和开发过程。你应该找到一种方法以增加用户参与开发的程度（在第3章和第4章中你将会学习这种技术）。 你需要与用户一起紧密工作。 定 义 项目成功（project success） 此外，开发商交付住宅时拖延了预期期限并且预算也已超支。产生这种问题的主要原因是他并不知道成本有多大，工期有多长。假如说他制定出了一个比较好的设计计划的话，就不会浪费