过程塑造(小型软件团队过程改进方法)

1、.：.；过程塑造小型软件团队过程改良方法一、从方法到编码这是一篇偏重于引见方法学特别是Agile方法实际的文章。其读者对象是那些希望在本人的软件团体中引入某个过程方法，但又不知从何入手的开发人员、工程经理们。本文中所提到的内容更适宜于运用在小型的软件团队中。对于较大规模的软件团队，本文中的部分内容也适用。 本系列包括： HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力、 HYPERLINK www-128.ibm/develope

2、rworks/cn/linux/software_engineering/Methodology/method2code/index3.html 代码是最终目、 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性的思索、 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index5.html 活泼和混乱

3、、严谨和死板、 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index6.html 短期利益和长期利益的权衡。软件管理和软件开发是截然区分的吗？ 对于工程经理来说，其职责是软件工程的管理，而对于架构师、编码人员来说，其职责是软件设计和开发。虽然在一些小型的团队中，这两种职责有时候是同一个人担任的，但两种角色的区分是必要的。从事过软件开发的人都能或多或少的感遭到软件管理和软件开发之间客观存在的沟壑。 我经常听到两个方面的声音。一边埋怨说设计师、编程人员阳奉阴违

4、，难以管束，导致已订立的软件过程形同虚设。另一边埋怨软件过程存在诸多不恰当的地方，变成了软件开发的绊脚石。 现代的方法学实际以及相应的过程实际为我们奠定了软件开发科学管理的根底，个中的翘楚包括RUP和XP，纵观这些方法、过程，都非常强调过程的流畅、生命周期的延续。而在实践的运用中，我们却经常可以看见对它们的不恰当的了解，不正确的运用。尤其是那些希望在本人的软件团体中引入新型的方法过程新手们。对于他们来说，最容易犯的一个错误就是忽视了如何利用一个软件过程来发明一个胜利的软件。关于如何建立一个软件过程的资料很多，但是这些资料并没有把为什么需求过程，过程的目的是什么之类的问题说清楚。而这些资料的读者

5、们，往往需求破费大量的时间，亲身进展实际之后，才干获得这些问题的答案，而付出的代价是教训和波折。同样的，我和我的同伴们也阅历了这样一个过程。因此，我希望把我在过程运用、过程改造中涉及到的问题例举出来采用过程方式的方式。假设大家可以利用到这些阅历哪怕是一些，那本文的目的也就到达了。因此，本文并不是一篇专门讨论如何建立过程的文章，也没有涉及建模、设计、编码等方面的内容。但是本文中所讨论的内容都可以对以上的活动起到部分的指点作用。矫捷？矫捷！ 从开场研讨软件工程，我就对矫捷过程的概念情有独衷，但是随着学习的深化所犯错误的增多，我发现矫捷是无处不在的，她是一种尺度，一种处于混乱和死板之间的平衡艺术。有

6、句俏皮话说的是一放就乱，一管就死，这句话很好的点出了软件过程的一种无法性。假设没有严厉的规定，软件开发就堕入一种混乱、无序的形状，但是假设制定了过于严厉的规定，软件人员的思绪又遭到极大的约束，管理本钱也随之上升。矫捷正是一种处于两个极端之间微妙平衡的艺术。这种艺术难以完全表述，但是可以经过一些指点，来协助 大家到达这种境界。 因此，我们可以推想的到，矫捷是见仁见智的。每一个软件团体都有本身的特性，其矫捷过程必然都不尽一样。如何设计出胜利的矫捷过程，来保证软件团体的胜利呢？本文经过一些过程方式的讨论，揭开了问题的一角。关于过程设计的完好的讨论，大家可以参考矫捷软件开发Alistair Cockb

7、urn一书该书近来将有中文版面世，该书详细的描画了过程设计的来龙去脉，以及如何根据组织的特点来选择适当的过程。 因此，虽然本文中并没有特别提到矫捷的字眼，但是所讨论的内容无不在矫捷思想的范围之内。 MDA推进软件可重用框架的建立 我有一个梦想，希望有一天可以不用在诸多的平台之间摇来摆去。虽说Java言语的口号就是跨平台。但现实上，我们还是无法完全摆脱平台的束缚。 在UML2.0的规范中，提到了一个MDAModel Driven Architecture的概念。在众多的软件平台中不知该如何选择，曾经演化为当今软件开发的主要难题。MDA的存在目的就是为理处理这个问题。经过MDA技术，一个UML的模

8、型可以是平台无关的，称为PIMPlatform-Independent Model，也可以是和特定平台相关的，称为PSMPlatform-Specific Model。利用平台技术的软件商，可以专注于本人的领域，集中描画业务功能，业务规那么，而无须思索特定的技术，构建出一个PIM，然后，经过支持MDA的工具，将PIM转换经过不同Profile进展映射为一个或多个PSM。这时候的模型依然是UML的。但是，这个转换过程虽然有工具的辅助，但依然需求外力的介入。接下来，开发工具将会从PSM中产生可执行代码。这就是MDA的思绪，它把以往以程序为中心的开发方式转变为以设计为中心的开发方式。 以往的重用，往

9、往是基于代码的，例如算法的重用、界面组件的重用，却往往没有将重用提升到设计的层次上。MDA为我们建立可重用的框架提供了一个很好的指点。留意上面的这副图，最外面的两层就表达了MDA可以用于设计重用的根本理念。倒数第二层的含义是利用MDA来进展通用软件例如事务、目录效力的模型设计，倒数第一层那么表示MDA可以用于特定业务领域的设计建模。可以想象，今后软件公司中的最有价值的资产，就是这些设计模型。 本文并不计划详细讨论MDA，除了简单的引见MDA的思绪之外，更重要的一点是企业可重用框架的建立。软件企业的中心在于知识，如何有效的将人脑中的知识存储起来，并不断的运用和开展，是软件企业胜利的关键。本文提到

10、的可重用框架，指的就是将软件开发相关知识存储起来的框架。这个思绪是本文的一个中心思绪。在本文看来，可重用框架不但包括了设计模型，还包括了过程和方法。软件开发是在这个框架之内运作的，同时反过来影响着框架的完善和改良。 过程塑造方式言语下述的方式都是从软件开发过程中，围绕着可重用框架的建立整理出来的一些阅历，之所以整理为方式的方式，是由于这种方式有利于类似情况的鉴别和对其进展必要的扩展。在软件开发中会遇到各种各样的问题，以上方式中讨论到的问题都是我们在实际中，或是和其他开发团队沟通中反复遇到的。因此坚决了我们将之整理为方式的自信心。目前我们得到的方式并不多，但是随着阅历的添加，我们会得到更多的积累

11、。 本文引见的方式都比较注重权衡的艺术。我们以为这是矫捷思想的必然结果。世界上并没有什么绝对的事情，尤其是目前多变的社会中，昨天的规范并不适宜于今天的环境。因此，我们的平衡点也在不断的变化。 传统、经典、学术的瀑布模型为我们建立了软件开发的根本过程，虽然有各种新的生命周期模型的提出，但是根本的过程并没有太大的变化。例如，加强性的瀑布过程是在瀑布模型的根底上添加了回溯到上一个阶段的才干；迭代式过程的每一次迭代都是一次微小的瀑布生命周期。在这个生命周期模型中，信息在初始需求搜集阶段生成，并经过分析、设计、编码、部署等阶段转化为用户最终需求的软件。在这样一个延续性极强的周期中，我们如何保证信息可以得

12、到正确的传送呢？我们用什么方法来防止信息传送的失真呢？我们如何在这样一个过程中处置人与人之间的交互呢？在正确传送信息的情况下，我们又如何保证投入的最小化呢？这些问题正是 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力方式所重点关注的。 我不只一次的见过为过程而关注过程的情况。产生这种结果的一种缘由是“过程麻木症。过程一旦定型，就不再改动，即使当初制定过程的环境曾经发生了变化也是如此。过程的制定一定是针对特定的目的的，这个目的就是

13、开发出胜利的软件，假设不可以效力于这个目的，遵照过程又有什么意义呢？另一种缘由是过程被分割为彼此独立的片断，每个开发人员只关注本人的职责，而忽略了最终的软件。过程的 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index3.html 代码是最终目的，开发过程中的一切活动都围绕着这一目的而展开。假设没有最后的用于交付的代码，软件就无法成为软件。因此，必需保证过程可以产出代码，而且是优秀的代码。 HYPERLINK www-128.ibm/developerwo

14、rks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性原那么是软件开发中重要原那么，也是最令人困惑的原那么。做到完全的一致性将会导致高昂的本钱，而不一致又会导致工程出现各种各样的问题。可以想到，这又是一个需求权衡的问题。软件工程中的一致性大致可以分为两种，一种是不同工件之间的一致性例如设计模型中的类称号和实践代码中的类称号的一致性，一种是工件和软件过程的一致性类称号需求满足命名规范。我们如何思索这两种情况下的一致性呢？ 人们说管理既是科学也是艺术，这句话用来描画软件工程再适宜不过了。假设说这里有什么不够

15、恰当的地方的话，我倒觉得是软件工程的这个提法有些许的欠妥。软件工程的思绪源自于人们盼望软件开发可以像土木工程那样成熟。但是几十年的阅历下来，大家可以一定，软件开发和土木工程有着太多的不同：开发人员和建筑工人也有着截然不同的差别，知识的组装和钢筋混凝土更是天差万别。但为了保证延续性，我们在本文中依然延续软件工程的提法。因此，软件工程需求在科学和艺术之间求得权衡，科学的一面包括了软件开发规范、准那么、实际、过程、方法；而艺术的一面那么囊括了人员的鼓励、协调，组织的设计等要素。因此我们需求审视我们的规那么、过程、方法，它们能否可以发扬出人的创新性？或是它能否足以约束人的行为？这就是 HYPERLIN

16、K www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index5.html 活泼和混乱、严谨和死板方式所要通知我们的。 应该说，本文中所讨论的方式更适宜于运用面向对象技术的开发团队。尤其是 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index6.html 短期利益和长期利益的权衡方式。和大多数人一样，我们最早也是过程式编程阵营的一员。在经过长时

17、间的学习和不断的犯错之后，我们终于转向了面向对象。面向对象最大的益处包括了以下几个方面： 将实现和接口分别，即把如何做隐藏起来，而把做什么展现给客户。 承继和多态使得我们可以在一个笼统的层次上基类和接口思索问题，并可以根据现实的需求进展灵敏的调整子类和实现。 经过设计方式和设计技巧的运用，可以有效的降低系统的不同部分之间的耦合度。尤其是简化客户端的代码。 在运用和比较过几种开发言语和开发环境之后，我们发现，其实最关键的并不是运用什么样的面向对象言语或环境，关键的是他运用面向对象思想的才干，或者说对现实世界的了解、笼统、映射的才干。这种才干决议了他的开发程度的高低，而言语和环境只是一种重要的实现

18、手段和工具而已。而这种思想才干，虽然可以经过例子和讨论来进展引见，但更关键的还是在实际中进展练习。在本文讨论的方式中，我们会夹带的对这些内容进展讨论。由于我们以为，开发思想和开发过程是无法区分的，否那么，他的开发过程就没有灵魂。这也是我们的主题所要强调的：从方法到编码，铸造起一个矫捷的、流畅的过程，才可以保证开发过程的胜利，开发软件的胜利。 此外，本篇是总论性文章，在撰写此文时，该篇其实是最后完工的，因此，建议大家在看过全文之后，假设还有耐心，可以重看此篇，置信会有另外一番收获。 如今请大家进入我们的方式之旅。 HYPERLINK www-128.ibm/developerworks/cn/l

19、inux/software_engineering/Methodology/method2code/index2.html 二、知识接力 在软件过程中，我们如何保证信息可以得到正确的传送呢？我们用什么方法来防止信息传送的失真呢？我们如何在这样一个过程中处置人与人之间的交互呢？在正确传送信息的情况下，我们又如何保证投入的最小化呢？意图软件开发过程是知识传送、知识转换的过程。注重知识转换中的完好性，保证知识经过各个阶段和活动，顺利的转换为软件是极为重要的。2、例如 元朗公司是国内某银行的下属企业。从年初开场，公司就投入了大量的人力为银行开发新版本的国际收支系统。思索到这是一个非常庞大的系统，因此公

20、司把原先的软件开发团队扩展了一倍，补充的人员有些于其它的工程组，有些人员别的公司。为了保证开发的顺利进展，工程经理引入了软件过程。但是从一开场，费事的事情就出现了。工程组中的技术人员和银行的领域专家之间不断出现意见相左的情况。主要的问题是后参与的员工对目的领域不熟习，难以配合领域专家的任务。最糟糕的是，某些领域专家身处异地，因此在需求分析的中期，开发团队约请这些异地的领域专家来到开发所在地，进展了为期两天的讨论会。结果并不理想，讨论会上充溢了对原先已定稿的需求的反对性意见，技术专家、领域专家吵成一团。需求分析阶段不得不在原先的根底上延伸了50%的时间。在进入设计和编码阶段之后，问题少了许多。但

21、在设计到编码的过程中仍是出了一些费事，缘由是新参与的人员不熟习开发团队的设计风格。经过一番周折，问题根本处理了。可等到工程进入到测试阶段，矛盾一下子就凸现出来了。测试报告指出，软件中存在着大量的问题，大部分的问题都被定性为无法满足需求的严重错误。经过对错误的复审，排除了其中17%的严重错误。经过分析，发现其中70%的错误都是发生在后参与人员担任的模块中。而产生大量错误的一个主要缘由是在编码阶段，由于银行启用了新的会计制度，导致大量模块被修正，由于时间紧迫，因此没有进展正规的需求调研。如今看来，领域专家和技术专家对同一个问题的了解并不一样。最后，工程的开发周期延伸了40%。分析软件过程每阅历一个

22、阶段，就会发生一次知识转换的情况。这种转换是由人来完成的，这就是像是接力一样，一个人把脑中的知识以某种方式传送给另一个人，再有另一个人传送下去，直至编码人员把这些知识固化在最终的软件中。在软件成型之前，知识的主要载体是文档和模型。我们称它们为工件Artifact。例如，需求阶段时，领域专家在技术专家的协助 下，将本人脑中对领域的认识传送给技术人员，并最终构成需求规格书或是用例模型。而在分析设计阶段，技术专家借助需求规格书，把脑中对软件的初始认识进一步转换为分析模型、设计模型、数据模型等工件。最后，在编码阶段，编码人员把这些工件中隐藏的知识转化为软件的方式。经过测试和部署，软件将会交付到用户手中

23、。这是非常典型的软件开发过程，再简单的软件开发也需求阅历上述的这些阶段。可以看到，在上述的软件开发过程中，知识方式发生了两次的重要转换，知识所属角色也改动了两次。知识完成第一次的方式转换之后，将成为需求规格书或同类工件的方式，知识从领域专家的脑中转换到技术专家的脑中。然后，知识开场了第二次的方式转换，构成设计模型以及同类工件。随着知识从技术专家转移到编码人员，知识转换为其最终的软件方式。在这些转换的过程中，最容易出现信息脱漏、信息失真的情况。保证转换过程中知识的完好性和正确性，对软件开发具有重要的意义。4、问题假设保证转换时知识的完好性和正确性？5、方法 知识转换的主体是人，因此我们主要的对策

24、也是针对人来展开的。我们知道，软件过程的特点就是：越早埋下祸根对工程的杀伤力越大。所以我们首先需求重点防备的对象应该是在初始需求分析阶段。需求分析阶段涉及的知识非常的多，大家假设有兴趣可以参看我的文章需求的实际。但这里我们重点的义务是找出需求分析阶段中发生知识转移的关键点。领域专家和技术专家是需求阶段中最重要的两种人，不论他的工程和团队规模属于哪一种层次，一定都包含这两种角色。假设他的团队中领域专家和技术专家是同一种人，那么祝贺他，他可以不用阅读这一段的内容了。惋惜在强调分工协作和软件规模不断扩展的今天，这种人曾经非常难找了。领域专家是知识的最初持有者，其职责是为工程提供准确的、完好的需求信息

25、。技术专家的职责那么是协助 领域专家完成这一项任务。所以，首先请保证领域专家和技术专家是可以沟通的，例如中的工程的第一个问题就是团队的新成员和领域专家之间存在沟通壁垒。在我们的阅历中，就发生过一位优秀的技术人员和一位资深的领域专家争吵的事情。分析缘由之后，我们发现，最主要的缘由是他们两个人都太优秀了，技术人员有一定的领域阅历，领域专家有一定的开发阅历，这导致了双方在讨论中的强硬立场。因此，假设遇到类似的情况，请对他的组织进展岗位调整。但在执行这项任务之前，请小心他的说辞，不要损伤到任何一个人。我们的某个小组有费事，那边非常需求他的阅历和才干会是一句不错的说辞。其次，技术专家不应该提出任何能够影

26、响领域专家的问题。只需领域专家才可以提出需求，技术专家起到的只是辅助作用。因此请杜绝这种情况。再次，假设他的领域专家不只一个人，那么他需求思索领域专家之间能够出现的不一致。为领域团队指定一位指点者是一种不错的做法。在我们的一个工程中，就曾约请对方公司的财务总监担任这一角色。理由有二：1、财务总监具有权威性；2、财务总监了解公司的全部运作。此外，假设领域专家分布在不同地点的话，他需求在该阶段的某个时期，安排需求讨论会，并思索一种可以沟通的方式，以便随时可以了解身处异地的领域专家的意见。这种情况对于那些拥有分公司的公司例如银行、证券、保险、销售公司等等而言非常的普遍。因此，我们在需求分析阶段，首先

27、要处置好领域专家和技术专家之间的关系。应该说，这里提到的内容不仅仅适用于需求阶段，在整个的开发过程中都有用途。需求不是实现。需求表示的是有什么What，并不关怀如何做How。假设在需求分析阶段把精神分散到了如何实现需求上，那么需求分析的效果就会遭到影响。这表达在需求的完好性和正确性两个方面。领域专家和技术专家都能够犯类似的错误。领域专家往往只可以针对本人的任务来描画需求，而他会很容易的把本人对于需务虚现看法参杂到需求描画中。从工程的整体范围来看，这种需求描画有时候是有问题的。假设他开发的是一个定制运用，那问题还不大，假设他开发的是一个产品，那么问题就很严重了。领域专家描画的需求一定是他需求的内

28、容吗？例如，他计划开发一个配送的管理运用，但是领域专家把大量的精神花在了他在原先的公司中如何实现配送的流程上，这个过程能够适宜于他的公司，但是对于产品而言，能够就不适宜，由于并非一切的配送公司都运用这种流程的。好吧，他想要的内容和他不想要的内容混合在一同，这使得他不得不破费精神对需求进展进一步的整理。因此，好的做法是，一开场就明确领域专家应该提供什么，而且，尽能够的提供需求，而不是需务虚现。多问一些诸如假设环境发生变化，他该如何做之类的问题，否那么他会发现，用户的需求变化将会对他的软件呵斥很大的影响。再说技术专家，技术专家经常犯的缺陷是把分析参杂到需求调研中来，从需求描画中精练出一些业务虚体或

29、进展CRC讨论是可以的，但是过早的思索实现方式将会限制他的思想。因此，请确保需求只是需求，这样才可以尽能够保证需求的完好性和正确性。需求复审是非常重要的检查点。请确保他正确的运用它。需求复审需求领域专家和技术专家、以及管理者的参与。需求复审是保证需求完好性和正确性的最后一道防线。在很多的文章包括我的需求的实际一文、过程都对需求复审进展了论述，我们这里就不赘述了。在实际过程中，我们发现，需求复审还有一个好的方式，为了可以经过需求复审，需求分析人员包括领域专家和技术专家会非常努力的找出需求中的问题。所以，在他的过程中参与这个检查点是非常有必要的。好的，假设这一切都进展顺利的话，最后的需求规格书应该

30、是比较完美的，而技术专家也曾经从领域专家那里了解到了足够的信息，可以开场下一阶段的开发了。这里，我们再花一些笔墨来讨论迭代过程中，我们如何处置需求。实际中，我们以为迭代次数并不是越多越好，应该根据工程规模和团队特点进展区分，每一次的迭代都能够有本人的目的。例如初次迭代的周期能够比较短，其主要的目的定为提供软件原型、验证主要设计思绪等。第二次的迭代的周期可以长一些，目的可以定位为实现主要功能。假设软件规模比较大，也可以为每次迭代设定需求范围或主要场景，这样就可以防止需求分散的情况。这曾经超出了本文的范围，因此我们这里只是简单的提一下。分析阶段是发生职责转换的重要阶段。该阶段的成败对软件开发至关重

31、要。对于面向对象开发而言，这个过程最主要的义务是对领域进展建模。比较好的方式是运用UML来描画领域知识，例如，我比较经常运用类图来建立分析模型，运用顺序图来描画动态流程。请确保技术团队中最出色的分析建模人员参与这个初始分析建模的过程。他的职责包括指点建模和对模型进展审查。假设在一个迭代过程中，这个模型是不断演进的，这可以减少一些风险。在这个过程中，建模人员可以吸收领域知识，这对于后续阶段中指点其他开发人员是很重要的，对公司的长久目的也具有重要意义参见 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Metho

32、dology/method2code/index6.html 短期利益和长期利益的权衡方式。假设建模人员短少面向对象开发的阅历，他会很容易把对象变成一个数据容器。这种方式并不是不好，但它把数据和行为区分开来，无法站在一个笼统的高度上对领域进展分析。 很难严厉的区分分析阶段和设计阶段，至少我是这么觉得的。他们的差别仅仅是在分析的详细程度上有点类似于以往的概要设计和详细设计。在实际中，我们发现，并没有必要严厉的区分它们，但是他需求保证模型曾经完好的描画了需求。这里可以设置检查点来验证，也可以在设计模型出来之后再进展检查，这取决于详细的工程。因此，我们在分析阶段和设计阶段终了之前需求进展设计复审。从

33、Martin Fowler提出分析方式的概念之后如今他的第二本分析方式正在写作中，它就成为分析建模的有利助手之一对领域概念进展分析和建模，并描画它们之间的关系我在点空间上的一篇读书笔记反响了需求和分析之间的关系。但是请千万留意，不要误用和滥用分析方式。由于任何分析方式的提出，都是基于某个上下文环境中的需求的，假设上下文环境不同，那么方式就需求改良或改造。因此，分析方式是一个好的开场，但需求他针对实践需求详细分析。在运用方式方面，Frank Buschmann的Applying Patterns是一篇不错的参考文章，其中文版发布在点空间上。请按照逐渐精化迭代的方式来完善、改良他的分析模型。优秀的

34、设计一定不会过于复杂。假设他的分析模型出现过于复杂的情况，四处充斥着复杂的关系网。那么，他需求对他的设计进展构造上的改良。例如，采用分层参见 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/part9/index.html 矫捷架构设计一文中的分层方式、组件技术、或是运用单向联络。坚持这一过程，他会发现最后的设计是简约的、完美的。 在设计阶段，要留意的事项和分析阶段相差不多，例如不要误用和滥用设计方式。但是有一点是需求额外强调的。当分析模型曾经可以完好、正确的描画需求之后，我们就需求在

35、设计模型中添加设计资料。例如对包、组件、类、方法的描画。这时候，需求的信息曾经被打散到软件的各个部分中了。而设计模型在被实现时，设计模型中的信息又将进入到代码中。因此，坚持这些信息的一致性就显得非常的关键。而由于设计模型处在中间地带，它的重要性又是不言而喻的。根本的处置思绪分为两步：在需求发生改动时，请同步更改设计模型以及设计模型中的信息。再由设计模型驱动代码的修正。第一个步骤是需求手动实现的，但是第二个步骤可以由计算机辅助实现，即坚持设计模型和代码信息的一致性将在 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineeri

36、ng/Methodology/method2code/index4.html 一致性的思索方式中讨论。目前有很多的建模工具都可以做到这一点，甚至可以实现产生最终的API文档。善用这项功能，它能令他事半功倍。 在软件过程中设立反响活动，可以有效的减少工程的偏向。就像我们骑自行车，很少可以走一条直线，普通我们是根据对目的的偏向进展忽左忽右的调整。这就是反响的机理。原型法是一种不错的反响机制，根据我们的阅历，视觉刺激对用户是最为关键的，因此不论他的需求文档做的如何的优秀，依然比不上一个可以看得见的软件原型有效。这一实际很多的软件工程资料中都有表达，我们就不深化了解了。另一种反响机制是渐进交付。把软件

37、产品分为多个迭代周期，每个周期交付一个可运转的软件，在获得用户的反响意见之后，在下一个迭代周期进展改良，最后一个迭代周期交付的就是完好的软件了。6、对可重用框架的改良 在找到了适宜软件企业本身的知识接力方法之后，该当将其作为规范或指点意见，参与到现有的软件过程中。例如，在需求分析完成之后强迫要求进展需求评审。参与到过程中的方法，小心不要流于方式。这样，既付出了本钱，又收不到运用的效果。运用工具也是坚持知识顺利交接的重要方法。例如，采用自动产生源代码的工具，模型设计工具、协助 产生工具、对象-关系映射工具等等。假设这些工具对他的过程起到了光滑的作用，请规范和普及工具的运用。7、小结请确保领域专家

38、和技术专家之间的顺畅沟通。 完好、准确的描画需求。 进展需求复审和设计复审。 保证分析模型设计模型可以完好的描画需求。 坚持需求信息到设计信息到代码注释的一致。 运用反响机制。 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index3.html 三、代码是最终目 过程的最终目的是代码，开发过程中的一切活动都围绕着这一目的而展开。假设没有最后的用于交付的代码，软件就无法成为软件。因此，必需保证过程可以产出代码，而且是优秀的代码。1、意图 无论哪一种过程，其最终

39、目的都是为了产生出可执行、并且可用的软件。因此软件过程中的各种活动应该围绕着快速、准确的实现这一目的而展开的。 2、例如 维力亚软件公司是一家合资公司，由于有外资背景，公司内部很早就引入了软件工程，并严厉的对人员角色进展分工。包括领域建模人员、架构设计师、高级程序员、程序员、界面设计师等等多种角色。每个人各司其职，充分发扬出了分工的特点。但是随着公司开发工程的逐渐增多，这种方式也显显露其弊端来。每个人的主要目的都是为了经过评审，而有时候，就算是经过评审的工件，依然能够存在问题。但这时候扯皮就出现了。工程中存在的一些中空地带。以及交错地带，经常发生无人问津的情况。开发过程的效率开场下降，开发本钱

40、开场上升。问题虽然不是一下子出现的，但是曾经逐渐变得严重起来了。 3、分析 我们在进展过程设计，或引入一个过程实际的时候，有没有思索过该过程的每一个阶段、每一个活动的目的是什么，它们对生成最后的软件有什么样的协助 ，这些协助 对于我们所在的组织有意义吗。很多情况下，我们并没有这么做，或者随着软件过程的定型，就不再思索这类的问题。一开场并没有什么了不起的，但是当软件过程演化成了一种政治体系的时候，那么问题就会渐渐严重起来。 4、问题如何让过程围绕着产出软件的中心目的而不断演进？ 5、方法 从上一篇引见的内容中，我们知道软件过程的每一个阶段都是知识转换的过程，知识转换的终点就是软件。问题在于，我们

41、如何保证这种转换的效率呢？ 现代软件的开展的趋势是重用。我们开发一个软件曾经很少会从最底层开场编写了。我们运用各种各样的技术和平台。包括数据库、分布式体系、UI机制、业务元素等等。因此如今的软件编写往往都是站在巨人的肩膀上开场的。不同的软件组织，肩膀的高低也不一样。比如有的软件组织运用J2EE平台，有的软件组织那么运用.NET平台。但是可以一定的一点是，每个软件组织都或多或少的拥有本人的平台体系开发阅历。这些阅历的表现方式也不尽一样，能够是保管在某些高级技术人员的脑中，也能够是保管为文档、模型或代码的方式。对于单个的工程而言，其过程一定是从需求开场，以部署以及后续维护为终结的。但是对于长时间存

42、在的软件组织而言，更重要的是工程阅历、技术阅历、管理阅历的积累。这样说能够过于笼统，我们举一个详细的例子。在完成了一个库存管理工程之后，我们把库存管理的领域知识制造为商业组件的方式，而把工程中学习到的一些编码的技巧整理为方式的方式，并把工程过程中积累的过程方法添加到现有的软件过程中。这些阅历的堆积就是在一开场我们提出的可重用框架。对一个软件团队的来说，它的一切软件工程都应该是围绕着这一个可重用框架而展开的。 迄今为止，我们见过的大多数的可重用框架表现方式都可以总结为：以开发平台为根底，积累本人的商业组件，并以此为中心订立开发活动。这种方式是不是最好并没有定论，但我们是抱着学习的态度来研讨它的。

43、 以开发平台为根底的意思是软件组织必需有本人所熟习的开发平台，其大部分的工程都是在此根底上进展的。目前最流行的两种软件开发平台是J2EE和.NET，但是就算是同一个平台，不同的软件组织对平台内部的偏重也是不同的同样对于J2EE技术，有的软件组织能够把JSP和Servlet作为中心选择，而另一些软件组织那么把重点放在EJB上。选择一种广泛运用的、具有生命力的平台技术是非常重要的。由于他的框架将会以此为根底进展，而框架的转移本钱是非常之高的。虽然我们在一开场引见的MDA思绪为我们绘制了一副平台无关设计的愉快愿景，但是在目前阶段，我们依然要面对不同软件平台呵斥的严重隔阂。 必需指出的是，我们上面提到

44、的开发平台指的是在操作系统这个层次之上的平台，也就是俗称的中间件平台。但是从中间件到最终的产品之间有没有过渡的平台呢。其实可重用框架就扮演了这一角色。软件市场上曾经出现了商业化的可重用框架了。IBM的SanFrancisco框架就是这种概念的代表。 平台技术仅仅只是提供了一个技术，而软件组织要生存和开展，还需求积累和开展本人的商业组件。并将商业组件开展成为可重用框架。商业组件的好坏，直接和软件组织的才干、阅历，以及平台技术相关。商业组件能够直接表现为代码的方式Bean、类、COM组件等，也能够只是描画性的记录文档。商业组件是阅历积累而成的。请留意，商业组件的设计并不完全等同于面向对象开发，由于

45、面向对象只是一种技术手段，但是商业组件设计的优劣，更重要的是对业务的了解程度。举一个最粗浅的例子，一个知晓面向对象开发、面向组件开发的设计师，让他介入他完全不了解的行业组件设计，他的表现将会大打折扣。 到目前为之，大家所认识的框架依然是技术型的框架。但现实并非如此，框架还包括了外延的一系列软件活动。这才是一个完好的框架。结合之前我们讨论的软件交付为开发目的。我们把这种开发方式称为以可重用框架为中心，以交付为目的的软件开发。这其实并不是什么了不起的概念，大部分的软件组织都曾经这么做了，只是没有认识到本人的方式而已。了解这一点，可以协助 软件组织有效的改良本身的构架。 平台技术和组件开发并不是本文

46、的重点，因此我们在一定了两者的重要性之后，把精神转移到软件活动上。 在拥有一个框架中心平台和商业组件之后，框架需求包含这样的活动或活动集：搜集工程需求，并将需求映射到中心构架上来。这其实就是需求阶段到设计阶段要做的事情。但是由于我们的活动是以软件交付为目的的，因此我们需求明确的指出活动中的本卷须知。 为映射任务设计需求描画规格。需求并不是一件容易的事。最难的莫过于尺度的把握了，例如需求要多详细。运用现成的技术来定义需求描画规格，并根据中心框架的特点进展必要的扩展。例如，我们运用成熟的用例技术来描画需求，同时我们要求需求按照不同类的商业组件进展分类索引。用例技术的引荐读物是Alistair Co

47、ckburn的Writing Effective Use Cases一书，该书目前已有英文影印版。 保证需求规格可以被工程成员所了解。这里的工程成员包括客户、领域专家、需求调研者、分析模型设计师。只需他们了解需求，才可以保证信息的正确的传送。参见 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力方式。 为实现需求制定分析设计规那么和指南 。这是把需求映射到中心构架上的重要步骤。制定规那么是必要的，但要小心，不要让规那么限制住开发人

48、员的发明力参见 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index5.html 活泼和混乱、严谨和死板方式。规那么的方式能够是设计规范、分析方式、类库、组件重用等等。在指南中提供例如，描画如何将需求转换为设计模型是一种不错的做法。同样好的做法还包括了方式指南。 确保测试贯穿了需求模型和设计模型。我们终于提到了测试。测试在软件过程中扮演着重要的角色。但遗憾的是在本文中直接提到的时机并不多，从某个角度上看。 HYPERLINK www-128.ibm/dev

49、eloperworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力方式中提到的复审其实也算是一种测试。测试的信息都包含在需求模型和设计模型之中，例如前置条件和后置条件。在完成需求模型和设计模型时同步完成测试用例是一种非常好的做法我们的团队正是采用这种做法，但是需求小心文档一致性参见 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性的思索

50、方式的所需求付出的额外本钱。 好像在 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力方式中提到的那样，让领域专家、架构师和高级开发人员对需求模型和设计模型进展复审。 原型方法可以有效的协助 最终软件的胜利。所谓原型方法，就是选取系统的某个部分最直接或风险最高的部分，通常是界面原型， 实现并呈现给用户，以获得反响，为后续的活动提供指点。原型方法最大的益处是可以协助 用户认识软件，消除用户的疑虑，并开掘潜藏的需求。围绕着能否丢弃原型

51、这一根本问题，原型方法可以分为渐进原型方法和舍弃型原型方法。前者是在一个软件原型的根底上不断的演进，并最终开展为可用的软件，后者那么是在开发出原型之后就将它舍弃。渐进原型方法充分利用了原型，但是由于缺乏前期设计，能够会导致最终产品存在性能或设计问题。舍弃型原型抑制了这个问题，但是它浪费了原型开发的那段时间。不论采用何种方法，最重要的是在工程一开场就决议采用哪一种原型方法。模棱两可的运用两种方法是兵家大忌。最终他无法利用任何一种方法的优点，而一切的缺陷都将降临到他身上。相较而言，渐进型原型方法更适宜于运用在小型工程上，由于工程并不复杂的话，设计的改良比较容易。对于一个拥有构架的团队而言，把原型方

52、法纳入构架之中是很有意义的。假设构架足够成数，迅速开发出一个原型并不是什么很困难的事情。这样就可以在投入最小化的情况下获得原型方法的优势。假设情况是这样的话，舍弃型原型方法似乎更适宜一些。 在 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力方式中，我们简要的提到了设计模型信息和代码信息的转换问题。运用建模工具动从设计模型抽取信息，并生成工程的代码。这种方法可以大幅度的提高软件开发效率，并对软件的最终交付有很大的协助 。同样，将代

53、码中的信息转回到设计模型中属于反向工程的一部分也是有意义的。假设短少这样的工具，那么请人为的保证信息的同步，当然，并没有必要坚持实时的同步参见 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性的思索方式。 软件的胜利和测试活动是无法区分的。我们前面简单的讨论过测试信息是来源于需求的。测试信息随着需求模型的生成而生成，并经过设计模型进展转换，在软件过程进入到实现阶段时，测试信息最终被转变为单元测试用例的方式。单元测试用例能够是针对单个

54、方法的单个用例，也能够是针对某个开发包的几组用例。我们需求留意两点，首先是在软件过程中保证这个流程的顺畅和正确。就像在 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力方式中讨论的那样，正确、完好的信息传送保证了最终软件的胜利出产，测试信息的胜利传送保证了最终软件的可用性。测试是软件的保证。因此，我们需求几个活动来保证测试信息的胜利： 从需求模型中生成接受测试。该活动把需求映射到测试上。在这个活动中，不但要留意功能性需求如完成的功

55、能，还需求留意非功能性需求性能要求。同样的，接受测试也需求接受复审。可以按照需求的组织方式来组织接受测试。 设计模型完成之后，接受测试曾经细化到模型的各个元素上了例如包、类。该项活动和将需求映射到设计的活动是同步进展的。由于它们处置的信息是非常类似的。和接受测试一样，这两个活动都需求由团队来保证。 在进入编码阶段之后，开发人员根据接受测试和设计模型，将会为本人担任的部分设计编写单元测试。单元测试的编写顺序能否优先于编码，这取决于各人的看法。关于这方面的讨论，可以参看XP的单元测试实际。从我个人的阅历来看，先写单元测试，再写代码不失为一个很好的方法，另一种做法是，让两个严密协作的开发人员相互为对

56、方编写单元测试。 其次，我们需求保证测试的最小单元单元测试的胜利。所谓皮之不存，毛将焉附。单元测试没有组织好，最后的软件是不会胜利的： 需求留意单元测试的覆盖率。这里的覆盖率指的是能否可以完全检测出错误所在。比如边境条件的测试等。开发团队中的架构师之类的角色需求为此担任，假设无法检查一切的单元测试，那么可以进展抽查和代码复审会议的方式。后者是一种很优秀的做法。从代码中抽取出一段，开发人员一同分析单元测试存在哪些问题，会使得大家编写单元测试的功力不断的增长。 单元测试一定要是自动化的。Junit就是一个不错的自动化测试框架。保证单元测试的自动化，并且防止单元测试和特定环境相关，这样就可以顺利的进

57、展回归测试。这对于迭代式的软件开发是非常必要的。同时，我们也应该认识到，单元测试的稳定性取决于设计的稳定性。我们可以想象，假设测试的类方法的参数、命名都发生改动，那么测试是一定需求重新组织的。所以，面向对象的笼统思想对于现代软件开发而言是费产重要的。为了做到测试的自动化，尽量防止将逻辑硬编码在界面中，并小心的处置数据库。可以尝试着建立测试数据库。 假设测试的内容需求并入中心构架，那么这部分的测试任务需求添加，并对构架能够的修正进展测试。因此，学习开源软件的做法，将构架的稳定版本和开发版本相区分是比较保险的。 让测试活动随着软件开发的进展而进展，让测试活动贯穿整个开发周期。这有点类似于全面质量管

58、理的思想。由于软件开发过程的失败并不是忽然而至的，而是在平常的不经意间一点一点的积累起来的。运用测试活动来消除这种微小的不稳定性，可以大幅度的提高最终软件的质量。但是，在一个团队中引入正规的。频繁的测试活动是需求耐心的。可以先从单元测试着手，渐渐的普及这种做法。 测试活动可以衍生为日创建和冒烟测试。对于有复数的开发人员参与的软件工程，就无法防止正视集成测试的局面。有过类似阅历的人都可以想象的到这种集成测试的难度。专门有一句话是描画这种局面的：我们曾经花了90%的时间来完成90%的软件，但我们还需求90%的时间来完成剩下的10%。现代的软件往往都包括成百上千的文件，这些文件的编译链接的过程是很复

59、杂的。而日创建的思想就是每天进展一次这样的过程，构成一个可执行文件。但这只是日创建第一部分内容。日创建还需求对软件进展冒烟测试，测试的主要内容就是单元测试中所编写的内容，保证软件可以经过一切的测试。 日创建需求留下一些调试的时间，尤其是在软件开发初期，不同开发人员的代码整合在一同出现问题的能够性极大。随着对这项实际的熟习程度，问题会逐渐减少。日创建可以很明显的提高产质量量，以及提升团队的士气。虽然日创建活动需求付出额外的一些本钱，但是相对于集成测试的不可控，这些本钱还是值得的。 6、小结投资于框架可以保证软件开发的胜利。 运用有效的实际活动来完善框架。 将需求映射到中心框架上来。 运用原型法。

60、 留意测试活动。 假设能够，运用日创建，并进展冒烟测试。 规那么不同于指南。规那么是目的受众所必需遵守的，而指南是建议目的受众遵守的。 HYPERLINK www-128.ibm/developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 四、一致性的思索 一致性原那么是软件开发中重要原那么，也是最令人困惑的原那么。做到完全的一致性将会导致高昂的本钱，而不一致又会导致工程出现各种各样的问题。可以想到，这又是一个需求权衡的问题。1、意图 软件过程中的大部分工件都需求坚持其相互之间的一致性。可是，