ntotheideaofausecase,sincetheconceptisn'tdiscardedafteranalysisanddesign,butinsteaditisafundamentaluntilofdevelopmentthroughoutthesoftware-buildingprocess.
Youstopiteratingwhenyouachievetargetfunctionalityoranexternaldeadlinearrivesandthecustomercanbesatisfiedwiththecurrentversion.(Remember,softwareisasubscriptionbusiness.)Becausetheprocessisiterative,youhavemanyopportunitiestoshipaproductinsteadofasingleendpoint;open-sourceprojectsworkexclusivelyinaniterative,high-feedbackenvironment,whichispreciselywhatmakesthemsuccessful.
Aniterativedevelopmentprocessisvaluableformanyreasons.Youcanrevealandresolvecriticalrisksearly,thecustomershaveampleopportunitytochangetheirminds,programmersatisfactionishigher,andtheprojectcanbesteeredwithmoreprecision.Butanadditionalimportantbenefitisthefeedbacktothestakeholders,whocanseebythecurrentstateoftheproductexactlywhereeverythinglies.Thismayreduceoreliminatetheneedformind-numbingstatusmeetingsandincreasetheconfidenceandsupportfromthestakeholders.
Phase5:Evolution
Thisisthepointinthedevelopmentcyclethathastraditionallybeencalled"maintenance,"acatch-alltermthatcanmeaneverythingfrom"gettingittoworkthewayitwasreallysupposedtointhefirstplace"to"addingfeaturesthatthecustomerforgottomention"tothemoretraditional"fixingthebugsthatshowup"and"addingnewfeaturesastheneedarises."Somanymisconceptionshavebeenappliedtotheterm"maintenance"thatithastakenonaslightlydeceivingquality,partlybecauseitsuggeststhatyou'veactuallybuildapristineprogramandallyouneedtodoischangeparts,oilit,andkeepitfromrusting.Perhapsthere'sabettertermtodescribewhat'sgoingon.
I'llusethetermevolution.Thatis,"Youwon'tgetitrightthefirsttime,sogiveyourselfthelatitudetolearnandtogobackandmakechanges."Youmightneedtomakealotofchangesasyoulearnandunderstandtheproblemmoredeeply.Theeleganceyou'llproduceifyouevolveuntilyougetitrightwill
payoff,bothintheshortandthelongterm.Evolutioniswhereyourprogramgoesfromgoodtogreat,andwherethoseissuesthatyoudidn'treallyunderstandinthefirstpassbecomeclear.It'salsowhereyourclassescanevolvefromsingle-projectusagetoreusableresources.
Whatisitmeansto"getitright"isn'tjustthattheprogramworksaccordingtotherequirementsandtheusecases.Italsomeansthattheinternalstructureofthecodemakessensetoyou,andfeelslikeitfitstogetherwell,withnoawkwardsyntax,oversizedobjects,orungainlyexposedbitsofcode.Inaddition,youmusthavesomesensethattheprogramstructurewillsurvivethechangesthatitwillinevitablygothroughduringitslifetime,andthatthosechangescanbemadeeasilyandcleanly.Thisisnosmallfeat.Youmustnotonlyunderstandwhatyou'rebuilding,butalsohowtheprogramwillevolve(whatIcallthevectorofchange).Fortunately,object-orientedprogramminglanguagesareparticularlyadaptatsupportingthiskindofcontinuingmodification-theboundariescreatedbytheobjectsarewhattendtokeepthestructurefrombreakingdown.Theyalsoallowyoutomakechanges-onesthatwouldseemdrasticinaproceduralprogram-withoutcausingearthquakesthroughoutyourcode.Infact,supportforevolutionmightbethemostimportantbenefitofOOP.
英文文献译文
整个开发过程时,最重要的问题是:不要迷路。这是很容易做到的。大部分的分析和设计方法都是为了解决最大的一些问题。记住,大多数的项目都不适合这一点,因此我们通常可以用一个相对较小的子集成功地进行分析和设计。但是采用某种过程,不论它怎么有局限,总比一开始就直接编码好得多。
在开发过程中很容易受阻,陷入到"分析瘫痪状态",这种状态往往是由没有弄清当前阶段的所有细节而感到不能继续了。记住,不论做了多少分析,总有系统的一些问题直到设计时才暴露出来,并且更多的问题是到编程或是直到程序完成运行适才出现。因此,迅速进行分析和设计并对提出的系统进行测试是很重要的。
这个问题值得强调。因为我们在面向过程型语言上的历史经验,一个项目组希望进入和实现之前认真处理和理解每个细节,这是值得赞赏的。的确,在构造DBMS时,需要彻底理解用户的需要。但是DBMS属于能很好表达和充分理解的一类问题。在许多这种程序中,数据库结构就是主要问题之所在。本章讨论的编程问题属于所谓的"不定(willcard)"(本人的术语)类型,这种问题的解决方法不是将众所周知的解决方案简单地重组,而是包含一个或多个"不定因素"-先前没有较了解的解决方案的要素,为此,需要研究。由于在分析阶段没有充分的信息去解决这一类问题,所以在设计和执行之前试图彻底地分析"不定型"问题会造成分析瘫痪。解决"不定型"问题需要在整个循环中反复,且需要冒风险(这是很有意义的,由于是在试图完成一些新颖的且潜在回报很高的事情)。看来似乎有风险是由于"匆忙"进入初步实现而引起的,但是这样反而可以降低风险,因为我们正在较早地确定一个特定的方法对这个问题是不是可行的。产品开发也是一种风险管理。
经常有人提到"建立一个然后丢掉"。在OOP中,我们仍然可以把一部分丢掉,然而由于代码被封装成类,在第一次的迭代中我们必将生成一些有用的类设计,并且一些不必抛弃的关于系统设计的有价值的思想。因此,在问题的第一次快速遍历中不仅要为下一遍分析、设计及实现产生关键的信息,还为下一遍建立代码基础。
也就是说,如果我们正在考虑的是一个包含丰富细节且需要许多步骤和文档的方法学,将很难判断什么时候停止。应当牢记我们正努力寻找的是什么:
1.什么是对象?(如何将项目分成多个组成部分?)
2.它们的接口是什么?(需要向每个对象发送什么信息?)
只要我们知道了对象和接口,就可以编写程序了。由于各种的原因我们可能需要比这些更多的描述和文档,但我们需要的信息不能比这些更少。
整个过程可以分5个阶段完成,阶段0只是使用一些结构的初始约定。
阶段0:制定计划
我们必须首先决定在此过程中应有那些步骤。这听起来很简单(事实上,所有听起来都是挺简单的),但是人们常常在开始编码之前没有考虑这一问题。如果计划是"让我们一开始就编码",那很好(有时,当我们对问题充分理解时,这是合适的)。至少,我们承认这是一个计划。
在这个阶段,我们可能还要决定一些另外的过程结构,但不是全部。可以理解,有些程序员喜欢用"休假方式"工作,也就是在开展他们的工作过程中,没有强制性的结构。"想做的时候就做"。这也许在短时间内是吸引人的,但是我发现,在进程中设立一些里程碑可以帮助集中我们的注意力,激发我们的热情,而不是只注意"完成项目"这个单一的目标。另外,里程碑将项目分成更细的阶段使得风险更小(此外里程碑还提供更多庆祝的机会)。
当我开始研究小说结构时(有一天我也要写小说),我最初是反对结构思想的,我觉得自己在写作时,直接下笔千言就行了
上一篇:
vb电表管理系统vb+access源代码+可执行程序+论文(论文和程序)
下一篇:
大学生汉语写作水平与英语水平相关性研究