time 
设为首页】【收藏本站
当前位置: 主页 > 软件工程 > 分析与建模 > 改变构建软件的方式

改变构建软件的方式

时间:2009-12-01 20:27 点击:483次 字体:[ ]




    数十年来,软件业已打造出多个软件系统来满足其客户的需要。即使拥有所有这些开发经验,软件质量和生产力却未能随之快速提高。根据 Standish Group 所进行的一项年度调查,我们发现我们现今的生产力水平与 10 年前几乎没有什么分别。目前,在所有软件开发项目中,有 54% 的项目在超出预算的情况下交付,66% 的项目未得到其客户认可,90% 的项目无法按时交付!但该调查所揭示的最令人烦忧的一点是,这些数字在过去的十年里一直都没有多少改观。

  召集一组开发人员或项目经理,当面问他们,是否觉得自己如今在构建软件领域做得比较成功。多数人在这时往往是置之一笑,同时承认他们也是这种结果的牺牲者。令人遗憾的是,我们往往认为,由于构建软件是一个极具创造性的过程,因此我们必须要容忍糟糕的交付项目。

目前构建软件的方式

  产力低下通常是由于未能正确了解需求或未能全面了解需求而造成。不止是构建不适合的系统会导致生产力严重下降,当项目范围在逐渐扩大,导致其超出最初的功能量时也会导致生产力严重下降。我们还发现,要达到令人满意的测试水平以确保预期的质量水平是很困难的。不成功的维护和升级发布通常与无法预见到代码更改对产品质量的影响有关。我们该如何确保对系统某一部分的更改不会破坏另一部分呢?

  由于我们很少从曾经完成的项目中吸取教训,因此导致这类问题频繁出现。当问到开发团队他们是否从自己的错误中吸取了教训时,明显会看到几乎没有人会主动积极地去总结教训,并将其应用到以后的项目中。很少有团队会习惯性地重新使用过去创建的解决方案,或者对成功和失败的案例进行记录。结果是,没有充足的知识和信息在各项目之间传递,各开发人员所了解的知识和信息依旧停滞在自己的脑海里。新的开发人员需要重蹈覆辙才能获得以前的开发人员本来已经吸取的经验和教训。开发人员发现很难以脱离现有的项目,因为他们对这些项目太熟悉了,并且发现加入新项目也很难,因为没有留下什么记录可供参考。

  由于多数项目都无法按时交付且会超出预算,因此我们意识到,我们还要面对一个可预见性问题。当问到项目经理是如何制定计划和日程表时,可以更明显地看到,许多人都在恪守着旧习惯,他们往往会这样说:“我向我最出色的程序员询问了此功能估计要花费多少时间,然后我会将该估计结果增加一倍;我的程序员往往都比较乐观。”通常,这种“预算”之后就会被缩减,或者是为了交出一份有竞争力的投标条件,使这些数字带来好结果,或者是为了满足预期要求。这些旧习惯是很难以改变的。

  但老实说,项目经理几乎要注定依赖专业人员来推测,因为他们没有可靠的量度来代替使用。他们需要能够以一种可靠的方式从软件开发项目收集量度,例如,通过数据仓库。从这些量度中,他们可以了解到其开发团队的运作情况,并利用了解的知识和信息来构想出更准确的估计数据。利用历史数据来对组织或项目绩效进行标准化可以提高估计数据的准确度,但多数估计数据并不是这样得出的。

  如果没有良好的可预见性,是很难以掌控项目的。在项目经理进行决策时,如何才能了解这个决策将对其日程表和成本带来什么影响?您不能只是用粗略的估计数据来预测所做决策的影响。这与蒙着双眼射击又希望射中目标并无两异。

  这些问题就是我们花费大量时间却生产出很少软件的原因。我们交付的软件质量拙劣且难以控制。要使开发过程尽在掌握之中,我们面临着重重困难。对于实践者来说,很难以对项目进行变更。超出预算的每个小时都会产生额外成本,在测试中(甚至更严重的是在生产中)发现的每个缺陷还要花费更多成本,这与整个过程中做出的每个错误决策的结果是一样的。如今构建软件的代价是非常昂贵的。

  使用软件工厂

  我们能改善这种情况吗?答案是肯定的。我们能够在构建软件时保证其准时交付、不超出预算并且质量达标。不过,首先各组织必须先意识到当前构建软件的方式是非常低效的。如果意识不到问题的存在,也不会有改进的动力。要在保证可预知性的前提下开始构建软件系统,我们必须进行一次文化变革。我们必须使实践者更容易地了解要执行任务的内容、执行时间、执行原因以及执行方式,并且必须将其工作中更多的机械和/或琐碎的方面实现自动化。可通过将开发流程中选出的各方面进行形式化来达到这些目标。这些方面有哪些?我们该如何将它们形式化而又不失灵活性?

  创造性和形式性

  关键是将那些创建和修改工作产品的精细活动进行形式化,而不是设法形式化整个开发流程。粗放式工作流随后可根据项目要求和情况来逐渐演化,前提是要一直保持固定流程以确保结果有效。例如,您可以同时着手编写多个类,根据需要在它们之间进行切换,只要在您编译时它们之间的所有依存关系都得以满足。这种机动性即保持了灵活性又防止了围绕单个活动排队的情况。如果将精细活动形式化,而不是试图将整个开发流程形式化,则可以在保证质量、可预见性和生产力的同时而又不失灵活性。您会认识到哪里需要形式化,哪里不需要形式化,从而更容易在灵活性与形式性之间取得适当的平衡。通过仅在需要形式化的环节和时间实施形式化,可以使开发流程随着经验的积累以一种非常系统的自下向上的方式演化。此方法还使收集知识及信息并在各项目和实践者之间传递这些知识及信息变得更加容易,本文稍后会对此进行阐述。

  解决问题时需要创造性,但执行机械和/或琐碎的活动时不需要创造性。遗憾的是,典型开发人员的日常工作中有很大一部分是由机械和/或琐碎的活动组成,但这也许不会让人感到意外。保证生产力和可预见性而又不失灵活性的关键是,在需要创造性的方面激发并支持创造性,在不需要创造性的方面则进行形式化。我们对模式、惯例和工具的形式化范围越大,从流程中剔除的不必要的变更就越多。剔除不必要的变更可以更容易地度量软件开发项目,从中吸取经验教训,并使用这些度量值来改进未来的项目。将机械和/或琐碎的活动形式化减少了在不需要创造性的活动上花费的时间和精力,从而激发了更大的创造性。

[1]  [2]  [3]  



本文地址 : http://www.fengfly.com/plus/view-158707-1.html
标签: 构建 项目 软件 改变 方式
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码: