小型软件团队过程改进方法

1、过程塑造（小型软件团队过程改进方法）一、从方法到编码这是一篇偏重于介绍方法学（特不是Agile方法）实践的文章。其读者对象是那些希望在自己的软件团体中引入某个过程方法，但又不知从何入手的开发人员、项目经理们。本文中所提到的内容更适合于应用在小型的软件团队中。关于较大规模的软件团队，本文中的部分内容也适用。 本系列包括： HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力、 HYPERLINK /developerworks/cn/linux/softwa

2、re_engineering/Methodology/method2code/index3.html 代码是最终目、 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性的考虑、 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index5.html 活跃和混乱、严谨和死板、 HYPERLINK /developerworks/cn/linux/s

3、oftware_engineering/Methodology/method2code/index6.html 短期利益和长期利益的权衡。软件治理和软件开发是截然区分的吗？ 关于项目经理来讲，其职责是软件项目的治理，而关于架构师、编码人员来讲，其职责是软件设计和开发。尽管在一些小型的团队中，这两种职责有时候是同一个人担任的，但两种角色的区分是必要的。从事过软件开发的人都能或多或少的感受到软件治理和软件开发之间客观存在的沟壑。 我常常听到来自两个方面的声音。一边抱怨讲设计师、编程人员阳奉阴违，难以管束，导致已订立的软件过程形同虚设。另一边抱怨软件过程存在诸多不恰当的地点，变成了软件开发的绊脚石。

4、 现代的方法学理论以及相应的过程实践为我们奠定了软件开发科学治理的基础，个中的翘楚包括RUP和XP，纵观这些方法、过程，都特不强调过程的流畅、生命周期的连续。而在实际的应用中，我们却常常能够看见对它们的不恰当的理解，不正确的使用。尤其是那些希望在自己的软件团体中引入新型的方法过程新手们。关于他们来讲，最容易犯的一个错误确实是忽视了如何利用一个软件过程来制造一个成功的软件。关于如何建立一个软件过程的资料专门多，然而这些资料并没有把什么缘故需要过程，过程的目的是什么之类的问题讲清晰。而这些资料的读者们，往往需要花费大量的时刻，亲自进行实践之后，才能获得这些问题的答案，而付出的代价是教训和挫折。同样

5、的，我和我的伙伴们也经历了如此一个过程。因此，我希望把我在过程应用、过程改造中涉及到的问题例举出来（采纳过程模式的方式）。假如大伙儿能够利用到这些经验（哪怕是一些），那本文的目的也就达到了。因此，本文并不是一篇专门讨论如何建立过程的文章，也没有涉及建模、设计、编码等方面的内容。然而本文中所讨论的内容都能够对以上的活动起到部分的指导作用。敏捷？敏捷！ 从开始研究软件工程，我就对敏捷过程的概念情有独衷，然而随着学习的深入（所犯错误的增多），我发觉敏捷是无处不在的，她是一种尺度，一种处于混乱和死板之间的平衡艺术。有句俏皮话讲的是一放就乱，一管就死，这句话专门好的点出了软件过程的一种无奈性。假如没有严

6、格的规定，软件开发就陷入一种混乱、无序的状态，然而假如制定了过于严格的规定，软件人员的思路又受到极大的约束，治理成本也随之上升。敏捷正是一种处于两个极端之间微妙平衡的艺术。这种艺术难以完全表述，然而能够通过一些指导，来关心大伙儿达到这种境地。 因此，我们能够推想的到，敏捷是见仁见智的。每一个软件团体都有自身的特性，其敏捷过程必定都不尽相同。如何设计出成功的敏捷过程，来保证软件团体的成功呢？本文通过一些过程模式的讨论，揭开了问题的一角。关于过程设计的完整的讨论，大伙儿能够参考敏捷软件开发Alistair Cockburn一书（该书近来将有中文版面世），该书详细的描述了过程设计的来龙去脉，以及如何

7、依照组织的特点来选择适当的过程。 因此，尽管本文中并没有特不提到敏捷的字眼，然而所讨论的内容无不在敏捷思维的范围之内。 MDA推动软件可重用框架的建立 我有一个梦想，希望有一天能够不用在诸多的平台之间摇来摆去。虽讲Java语言的口号确实是跨平台。但事实上，我们依旧无法完全摆脱平台的束缚。 在UML2.0的规范中，提到了一个MDA（Model Driven Architecture）的概念。在众多的软件平台中不知该如何选择，差不多演变为当今软件开发的要紧难题。MDA的存在目的确实是为了解决那个问题。通过MDA技术，一个UML的模型能够是平台无关的，称为PIM（Platform-Independe

8、nt Model），也能够是和特定平台相关的，称为PSM（Platform-Specific Model）。利用平台技术的软件商，能够专注于自己的领域，集中描述业务功能，业务规则，而无须考虑特定的技术，构建出一个PIM，然后，通过支持MDA的工具，将PIM转换（通过不同Profile进行映射）为一个或多个PSM。这时候的模型仍然是UML的。然而，那个转换过程尽管有工具的辅助，但仍然需要外力的介入。接下来，开发工具将会从PSM中产生可执行代码。这确实是MDA的思路，它把以往以程序为中心的开发模式转变为以设计为中心的开发模式。 以往的重用，往往是基于代码的，例如算法的重用、界面组件的重用，却往往没

9、有将重用提升到设计的层次上。MDA为我们建立可重用的框架提供了一个专门好的指导。注意上面的这副图，最不处的两层就表达了MDA能够用于设计重用的差不多理念。倒数第二层的含义是利用MDA来进行通用软件（例如事务、目录服务）的模型设计，倒数第一层则表示MDA能够用于特定业务领域的设计建模。能够想象，今后软件公司中的最有价值的资产，确实是这些设计模型。 本文并不打算详细讨论MDA，除了简单的介绍MDA的思路之外，更重要的一点是企业可重用框架的建立。软件企业的核心在于知识，如何有效的将人脑中的知识存储起来，并不断的使用和进展，是软件企业成功的关键。本文提到的可重用框架，指的确实是将软件开发相关知识存储起

10、来的框架。那个思路是本文的一个核心思路。在本文看来，可重用框架不但包括了设计模型，还包括了过程和方法。软件开发是在那个框架之内运作的，同时反过来阻碍着框架的完善和改进。 过程塑造模式语言下述的模式差不多上从软件开发过程中，围绕着可重用框架的建立整理出来的一些经验，之因此整理为模式的形式，是因为这种方式有利于类似情况的鉴不和对其进行必要的扩展。在软件开发中会遇到各种各样的问题，以上模式中讨论到的问题差不多上我们在实践中，或是和其他开发团队沟通中反复遇到的。因此坚决了我们将之整理为模式的信心。目前我们得到的模式并不多，然而随着经验的增加，我们会得到更多的积存。 本文介绍的模式都比较注重权衡的艺术。

11、我们认为这是敏捷思维的必定结果。世界上并没有什么绝对的情况，尤其是目前多变的社会中，昨天的标准并不适合于今天的环境。因此，我们的平衡点也在不断的变化。 传统、经典、学术的瀑布模型为我们建立了软件开发的差不多过程，尽管有各种新的生命周期模型的提出，然而差不多的过程并没有太大的变化。例如，增强性的瀑布过程是在瀑布模型的基础上增加了回溯到上一个时期的能力；迭代式过程的每一次迭代差不多上一次微小的瀑布生命周期。在那个生命周期模型中，信息在初始需求收集时期生成，并通过分析、设计、编码、部署等时期转化为用户最终需要的软件。在如此一个连续性极强的周期中，我们如何保证信息能够得到正确的传递呢？我们用什么方法来

12、幸免信息传递的失真呢？我们如何在如此一个过程中处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保证投入的最小化呢？这些问题正是 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力模式所重点关注的。 我不只一次的见过为过程而关注过程的情况。产生这种结果的一种缘故是“过程麻痹症”。过程一旦定型，就不再改变，即便当初制定过程的环境差不多发生了变化也是如此。过程的制定一定是针对特定的目标的，那个目标确实是开发出成功的软件，假如不能够服务于那个目标，遵循

13、过程又有什么意义呢？另一种缘故是过程被分割为彼此独立的片断，每个开发人员只关注自己的职责，而忽略了最终的软件。过程的 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index3.html 代码是最终目的，开发过程中的所有活动都围绕着这一目的而展开。假如没有最后的用于交付的代码，软件就无法成为软件。因此，必须保证过程能够产出代码，而且是优秀的代码。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/

14、method2code/index4.html 一致性原则是软件开发中重要原则，也是最令人困惑的原则。做到完全的一致性将会导致高昂的成本，而不一致又会导致项目出现各种各样的问题。能够想到，这又是一个需要权衡的问题。软件项目中的一致性大致能够分为两种，一种是不同工件之间的一致性（例如设计模型中的类名称和实际代码中的类名称的一致性），一种是工件和软件过程的一致性（类名称需要满足命名标准）。我们如何考虑这两种情况下的一致性呢？ 人们讲治理既是科学也是艺术，这句话用来形容软件工程再适合只是了。假如讲那个地点有什么不够恰当的地点的话，我倒觉得是软件工程的那个提法有些许的欠妥。软件工程的思路源自于人们渴望

15、软件开发能够像土木工程那样成熟。然而几十年的经验下来，大伙儿能够确信，软件开发和土木工程有着太多的不同：开发人员和建筑工人也有着截然不同的差异，知识的组装和钢筋混凝土更是天差万不。（但为了保证连续性，我们在本文中仍然连续软件工程的提法。）因此，软件工程需要在科学和艺术之间求得权衡，科学的一面包括了软件开发规范、准则、实践、过程、方法；而艺术的一面则囊括了人员的激励、协调，组织的设计等因素。因此我们需要审视我们的规则、过程、方法，它们是否能够发挥出人的创新性？或是它是否足以约束人的行为？这确实是 HYPERLINK /developerworks/cn/linux/software_engine

16、ering/Methodology/method2code/index5.html 活跃和混乱、严谨和死板模式所要告诉我们的。 应该讲，本文中所讨论的模式更适合于使用面向对象技术的开发团队。尤其是 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index6.html 短期利益和长期利益的权衡模式。和大多数人一样，我们最早也是过程式编程阵营的一员。在通过长时刻的学习和不断的犯错之后，我们终于转向了面向对象。面向对象最大的好处包括了以下几个方面： 将实现和接口分离，即把如何做隐藏起来，

17、而把做什么展示给客户。 继承和多态使得我们能够在一个抽象的层次上（基类和接口）考虑问题，并能够依照现实的需求进行灵活的调整（子类和实现）。 通过设计模式和设计技巧的应用，能够有效的降低系统的不同部分之间的耦合度。尤其是简化客户端的代码。 在使用和比较过几种开发语言和开发环境之后，我们发觉，事实上最关键的并不是使用什么样的面向对象语言（或环境），关键的是你运用面向对象思维的能力，或者讲对现实世界的理解、抽象、映射的能力。这种能力决定了你的开发水平的高低，而语言和环境只是一种重要的实现手段和工具而已。而这种思维能力，尽管能够通过例子和讨论来进行介绍，但更关键的依旧在实践中进行练习。在本文讨论的模式

18、中，我们会夹带的对这些内容进行讨论。因为我们认为，开发思想和开发过程是无法区分的，否则，你的开发过程就没有灵魂。这也是我们的主题所要强调的：从方法到编码，铸造起一个敏捷的、流畅的过程，才能够保证开发过程的成功，开发软件的成功。 此外，本篇是总论性文章，在撰写此文时，该篇事实上是最后完工的，因此，建议大伙儿在看过全文之后，假如还有耐心，能够重看此篇，相信会有另外一番收获。 现在请大伙儿进入我们的模式之旅。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 二、知识

19、接力 在软件过程中，我们如何保证信息能够得到正确的传递呢？我们用什么方法来幸免信息传递的失真呢？我们如何在如此一个过程中处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保证投入的最小化呢？意图软件开发过程是知识传递、知识转换的过程。注重知识转换中的完整性，保证知识通过各个时期和活动，顺利的转换为软件是极为重要的。2、示例 元朗公司是国内某银行的下属企业。从年初开始，公司就投入了大量的人力为银行开发新版本的国际收支系统。考虑到这是一个特不庞大的系统，因此公司把原先的软件开发团队扩大了一倍，补充的人员有些来自于其它的项目组，有些人员来自不的公司。为了保证开发的顺利进行，项目经理引入了软件

20、过程。然而从一开始，苦恼的情况就出现了。项目组中的技术人员和银行的领域专家之间不断出现意见相左的情况。要紧的问题是后加入的职员对目标领域不熟悉，难以配合领域专家的工作。最糟糕的是，某些领域专家身处异地，因此在需求分析的中期，开发团队邀请这些异地的领域专家来到开发所在地，进行了为期两天的讨论会。结果并不理想，讨论会上充满了对原先已定稿的需求的反对性意见，技术专家、领域专家吵成一团。需求分析时期不得不在原先的基础上延长了50%的时刻。在进入设计和编码时期之后，问题少了许多。但在设计到编码的过程中仍是出了一些苦恼，缘故是新加入的人员不熟悉开发团队的设计风格。通过一番周折，问题差不多解决了。可等到项目

21、进入到测试时期，矛盾一下子就凸现出来了。测试报告指出，软件中存在着大量的问题，大部分的问题都被定性为无法满足需求的严峻错误。通过对错误的复审，排除了其中17%的严峻错误。通过分析，发觉其中70%的错误差不多上发生在后加入人员负责的模块中。而产生大量错误的一个要紧缘故是在编码时期，由于银行启用了新的会计制度，导致大量模块被修改，由于时刻紧迫，因此没有进行正规的需求调研。现在看来，领域专家和技术专家对同一个问题的理解并不相同。最后，项目的开发周期延长了40%。分析软件过程每经历一个时期，就会发生一次知识转换的情况。这种转换是由人来完成的，这确实是像是接力一样，一个人把脑中的知识以某种方式传递给另一

22、个人，再有另一个人传递下去，直至编码人员把这些知识固化在最终的软件中。在软件成型之前，知识的要紧载体是文档和模型。我们称它们为工件（Artifact）。例如，需求时期时，领域专家在技术专家的关心下，将自己脑中对领域的认识传递给技术人员，并最终形成需求规格书或是用例模型。而在分析设计时期，技术专家借助需求规格书，把脑中对软件的初始认识进一步转换为分析模型、设计模型、数据模型等工件。最后，在编码时期，编码人员把这些工件中隐藏的知识转化为软件的形式。通过测试和部署，软件将会交付到用户手中。这是特不典型的软件开发过程，再简单的软件开发也需要经历上述的这些时期。能够看到，在上述的软件开发过程中，知识形式

23、发生了两次的重要转换，知识所属角色也改变了两次。知识完成第一次的形式转换之后，将成为需求规格书（或同类工件）的形式，知识从领域专家的脑中转换到技术专家的脑中。然后，知识开始了第二次的形式转换，形成设计模型（以及同类工件）。随着知识从技术专家转移到编码人员，知识转换为其最终的软件形式。在这些转换的过程中，最容易出现信息遗漏、信息失确实情况。保证转换过程中知识的完整性和正确性，对软件开发具有重要的意义。4、问题假如保证转换时知识的完整性和正确性？5、方法 知识转换的主体是人，因此我们要紧的对策也是针对人来展开的。我们明白，软件过程的特点确实是：越早埋下祸根对项目的杀伤力越大。因此我们首先需要重点防

24、范的对象应该是在初始需求分析时期。需求分析时期涉及的知识特不的多，大伙儿假如有兴趣能够参看我的文章需求的实践。但那个地点我们重点的任务是找出需求分析时期中发生知识转移的关键点。领域专家和技术专家是需求时期中最重要的两种人，不论你的项目和团队规模属于哪一种层次，一定都包含这两种角色。假如你的团队中领域专家和技术专家是同一种人，那么恭喜你，你能够不用阅读这一段的内容了。惋惜在强调分工协作和软件规模不断扩大的今天，这种人差不多特不难找了。领域专家是知识的最初持有者，其职责是为项目提供准确的、完整的需求信息。技术专家的职责则是关心领域专家完成这一项工作。因此，首先请保证领域专家和技术专家是能够沟通的，

25、示例中的项目的第一个问题确实是团队的新成员和领域专家之间存在沟通壁垒。在我们的经验中，就发生过一位优秀的技术人员和一位资深的领域专家争吵的情况。剖析缘故之后，我们发觉，最要紧的缘故是他们两个人都太优秀了，技术人员有一定的领域经验，领域专家有一定的开发经验，这导致了双方在讨论中的强硬立场。因此，假如遇到类似的情况，请对你的组织进行岗位调整。但在执行这项工作之前，请小心你的讲辞，不要损害到任何一个人。我们的某个小组有苦恼，那边特不需要你的经验和能力会是一句不错的讲辞。其次，技术专家不应该提出任何可能阻碍领域专家的问题。只有领域专家才能够提出需求，技术专家起到的只是辅助作用。因此请杜绝这种情况。再次

26、，假如你的领域专家不只一个人，那么你需要考虑领域专家之间可能出现的不一致。为领域团队指定一位领导者是一种不错的做法。在我们的一个项目中，就曾邀请对方公司的财务总监担任这一角色。理由有二：1、财务总监具有权威性；2、财务总监了解公司的全部运作。此外，假如领域专家分布在不同地点的话，你需要在该时期的某个时期，安排需求讨论会，并考虑一种能够沟通的方式，以便随时能够了解身处异地的领域专家的意见。这种情况关于那些拥有分公司的公司（例如银行、证券、保险、销售公司等等）而言特不的普遍。因此，我们在需求分析时期，首先要处理好领域专家和技术专家之间的关系。应该讲，那个地点提到的内容不仅仅适用于需求时期，在整个的

27、开发过程中都有用处。需求不是实现。需求表示的是有什么（What），并不关怀如何做（How）。假如在需求分析时期把精力分散到了如何实现需求上，那么需求分析的效果就会受到阻碍。这体现在需求的完整性和正确性两个方面。领域专家和技术专家都可能犯类似的错误。领域专家往往只能够针对自己的工作来描述需求，而他会专门容易的把自己关于需求实现看法参杂到需求描述中。从项目的整体范围来看，这种需求描述有时候是有问题的。假如你开发的是一个定制应用，那问题还不大，假如你开发的是一个产品，那么问题就专门严峻了。领域专家描述的需求一定是你需要的内容吗？例如，你打算开发一个配送的治理应用，然而领域专家把大量的精力花在了他在原

28、先的公司中如何实现配送的流程上，那个过程可能适合于他的公司，然而关于产品而言，可能就不合适，因为并非所有的配送公司都使用这种流程的。好吧，你想要的内容和你不想要的内容混合在一起，这使得你不得不花费精力对需求进行进一步的整理。因此，好的做法是，一开始就明确领域专家应该提供什么，而且，尽可能的提供需求，而不是需求实现。多问一些诸如假如环境发生变化，你该如何做之类的问题，否则你会发觉，用户的需求变化将会对你的软件造成专门大的阻碍。再讲技术专家，技术专家常常犯的毛病是把分析参杂到需求调研中来，从需求描述中精练出一些业务实体（或进行CRC讨论）是能够的，然而过早的考虑实现方式将会限制你的思维。因此，请确

29、保需求只是需求，如此才能够尽可能保证需求的完整性和正确性。需求复审是特不重要的检查点。请确保你正确的使用它。需求复审需要领域专家和技术专家、以及治理者的参与。需求复审是保证需求完整性和正确性的最后一道防线。在专门多的文章（包括我的需求的实践一文）、过程都对需求复审进行了论述，我们那个地点就不赘述了。在实践过程中，我们发觉，需求复审还有一个好的方式，为了能够通过需求复审，需求分析人员（包括领域专家和技术专家）会特不努力的找出需求中的问题。因此，在你的过程中加入那个检查点是特不有必要的。好的，假如这一切都进行顺利的话，最后的需求规格书应该是比较完美的，而技术专家也差不多从领域专家那儿了解到了足够的

30、信息，能够开始下一时期的开发了。那个地点，我们再花一些笔墨来讨论迭代过程中，我们如何处理需求。实践中，我们认为迭代次数并不是越多越好，应该依照项目规模和团队特点进行区分，每一次的迭代都可能有自己的目标。例如首次迭代的周期可能比较短，其要紧的目标定为提供软件原型、验证要紧设计思路等。第二次的迭代的周期能够长一些，目标能够定位为实现要紧功能。假如软件规模比较大，也能够为每次迭代设定需求范围（或要紧场景），如此就能够防止需求扩散的情况。这差不多超出了本文的范围，因此我们那个地点只是简单的提一下。分析时期是发生职责转换的重要时期。该时期的成败对软件开发至关重要。关于面向对象开发而言，那个过程最要紧的任

31、务是对领域进行建模。比较好的方式是使用UML来描述领域知识，例如，我比较经常使用类图来建立分析模型，使用顺序图来描述动态流程。请确保技术团队中最出色的分析建模人员参与那个初始分析建模的过程。他的职责包括指导建模和对模型进行审查。假如在一个迭代过程中，那个模型是不断演进的，这能够减少一些风险。在那个过程中，建模人员能够汲取领域知识，这关于后续时期中指导其他开发人员是专门重要的，对公司的长远目标也具有重要意义（参见 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index6.html

32、短期利益和长期利益的权衡模式）。假如建模人员缺少面向对象开发的经验，他会专门容易把对象变成一个数据容器。这种方式并不是不行，但它把数据和行为区分开来，无法站在一个抽象的高度上对领域进行分析。 专门难严格的区分分析时期和设计时期，至少我是这么觉得的。他们的差不仅仅是在分析的详细程度上（有点类似于以往的概要设计和详细设计）。在实践中，我们发觉，并没有必要严格的区分它们，然而你需要保证模型差不多完整的描述了需求。那个地点能够设置检查点来验证，也能够在设计模型出来之后再进行检查，这取决于具体的项目。因此，我们在分析时期和设计时期结束之前需要进行设计复审。从Martin Fowler提出分析模式的概念之

33、后（现在他的第二本分析模式正在写作中），它就成为分析建模的有利助手之一对领域概念进行分析和建模，并描述它们之间的关系（我在点空间上的一篇读书笔记反应了需求和分析之间的关系）。然而请千万注意，不要误用和滥用分析模式。因为任何分析模式的提出，差不多上基于某个上下文环境中的需求的，假如上下文环境不同，那么模式就需要改进或改造。因此，分析模式是一个好的开始，但需要你针对实际需求具体分析。在应用模式方面，Frank Buschmann的Applying Patterns是一篇不错的参考文章，其中文版公布在点空间上。请按照逐步精化（迭代）的方式来完善、改进你的分析模型。优秀的设计一定可不能过于复杂。假如你

34、的分析模型出现过于复杂的情况，到处充斥着复杂的关系网。那么，你需要对你的设计进行结构上的改进。例如，采纳分层（参见 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/part9/index.html 敏捷架构设计一文中的分层模式）、组件技术、或是使用单向联系。坚持这一过程，你会发觉最后的设计是简洁的、完美的。 在设计时期，要注意的事项和分析时期相差不多，例如不要误用和滥用设计模式。然而有一点是需要额外强调的。当分析模型差不多能够完整、正确的描述需求之后，我们就需要在设计模型中添加设计资料。例如对包、组件、类、

35、方法的描述。这时候，需求的信息差不多被打散到软件的各个部分中了。而设计模型在被实现时，设计模型中的信息又将进入到代码中。因此，保持这些信息的一致性就显得特不的关键。而由于设计模型处在中间地带，它的重要性又是不言而喻的。差不多的处理思路分为两步：在需求发生改变时，请同步更改设计模型以及设计模型中的信息。再由设计模型驱动代码的修改。第一个步骤是需要手动实现的，然而第二个步骤能够由计算机辅助实现，即保持设计模型和代码信息的一致性（将在 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/ind

36、ex4.html 一致性的考虑模式中讨论）。目前有专门多的建模工具都能够做到这一点，甚至能够实现产生最终的API文档。善用这项功能，它能令你事半功倍。 在软件过程中设立反馈活动，能够有效的减少项目的偏差。就像我们骑自行车，专门少能够走一条直线，一般我们是依照对目标的偏差进行忽左忽右的调整。这确实是反馈的机理。原型法是一种不错的反馈机制，依照我们的经验，视觉刺激对用户是最为关键的，因此不论你的需求文档做的如何的优秀，仍然比不上一个能够看得见的软件原型有效。这一实践专门多的软件工程资料中都有叙述，我们就不深入了解了。另一种反馈机制是渐进交付。把软件产品分为多个迭代周期，每个周期交付一个可运行的软件

37、，在获得用户的反馈意见之后，在下一个迭代周期进行改进，最后一个迭代周期交付的确实是完整的软件了。6、对可重用框架的改进 在找到了适合软件企业自身的知识接力方法之后，应当将其作为规范或指导意见，加入到现有的软件过程中。例如，在需求分析完成之后强制要求进行需求评审。加入到过程中的方法，小心不要流于形式。如此，既付出了成本，又收不到应用的效果。使用工具也是保持知识顺利交接的重要方法。例如，采纳自动产生源代码的工具，模型设计工具、关心产生工具、对象-关系映射工具等等。假如这些工具对你的过程起到了润滑的作用，请规范和普及工具的使用。7、小结请确保领域专家和技术专家之间的顺畅沟通。 完整、准确的描述需求。

38、 进行需求复审和设计复审。 保证分析模型（设计模型）能够完整的描述需求。 保持需求信息到设计信息到代码注释的一致。 使用反馈机制。 HYPERLINK /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 C

47、ockburn的Writing Effective Use Cases一书，该书目前已有英文影印版。 保证需求规格能够被项目成员所理解。那个地点的项目成员包括客户、领域专家、需求调研者、分析模型设计师。只有他们了解需求，才能够保证信息的正确的传递。（参见 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力模式）。 为实现需求制定分析（设计）规则和指南 。这是把需求映射到核心构架上的重要步骤。制定规则是必要的，但要小心，不要让规则限制住开发人员的制造力（参

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

49、e_engineering/Methodology/method2code/index2.html 知识接力模式中提到的复审事实上也确实是一种测试。测试的信息都包含在需求模型和设计模型之中，例如前置条件和后置条件。在完成需求模型和设计模型时同步完成测试用例是一种特不行的做法（我们的团队正是采纳这种做法），然而需要小心文档一致性（参见 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性的考虑模式）的所需要付出的额外成本。 如同在 HYPERLINK /dev

50、eloperworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力模式中提到的那样，让领域专家、架构师和高级开发人员对需求模型和设计模型进行复审。 原型方法能够有效的关心最终软件的成功。所谓原型方法，确实是选取系统的某个部分（最直接或风险最高的部分，通常是界面原型）， 实现并呈现给用户，以获得反馈，为后续的活动提供指导。原型方法最大的好处是能够关心用户认识软件，消除用户的疑虑，并发掘潜藏的需求。围绕着是否抛弃原型这一全然问题，原型方法能够分为渐进原型方法和舍弃型原型方法。前者是在一个软件原型的基础

51、上不断的演进，并最终进展为可用的软件，后者则是在开发出原型之后就将它舍弃。渐进原型方法充分利用了原型，然而由于缺乏前期设计，可能会导致最终产品存在性能或设计问题。舍弃型原型克服了那个问题，然而它白费了原型开发的那段时刻。不论采纳何种方法，最重要的是在项目一开始就决定采纳哪一种原型方法。模棱两可的使用两种方法是兵家大忌。最终你无法利用任何一种方法的优点，而所有的缺点都将降临到你身上。相较而言，渐进型原型方法更适合于应用在小型项目上，因为项目并不复杂的话，设计的改进比较容易。关于一个拥有构架的团队而言，把原型方法纳入构架之中是专门有意义的。假如构架足够成数，迅速开发出一个原型并不是什么专门困难的情

52、况。如此就能够在投入最小化的情况下获得原型方法的优势。假如情况是如此的话，舍弃型原型方法大概更适合一些。 在 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力模式中，我们简要的提到了设计模型信息和代码信息的转换问题。使用建模工具来自动从设计模型抽取信息，并生成项目的代码。这种方法能够大幅度的提高软件开发效率，并对软件的最终交付有专门大的关心。同样，将代码中的信息转回到设计模型中（属于反向工程的一部分）也是有意义的。假如缺少如此的工具，那么请人为的保证信

53、息的同步，因此，并没有必要保持实时的同步（参见 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性的考虑模式）。 软件的成功和测试活动是无法区分的。我们前面简单的讨论过测试信息是来源于需求的。测试信息随着需求模型的生成而生成，并通过设计模型进行转换，在软件过程进入到实现时期时，测试信息最终被转变为单元测试用例的形式。单元测试用例可能是针对单个方法的单个用例，也可能是针对某个开发包的几组用例。我们需要注意两点，首先是在软件过程中保证那个流程的顺畅和正确。就像

54、在 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知识接力模式中讨论的那样，正确、完整的信息传递保证了最终软件的成功出产，测试信息的成功传递保证了最终软件的可用性。测试是软件的保证。因此，我们需要几个活动来保证测试信息的成功： 从需求模型中生成同意测试。该活动把需求映射到测试上。在那个活动中，不但要注意功能性需求（如完成的功能），还需要注意非功能性需求（性能要求）。同样的，同意测试也需要同意复审。能够按照需求的组织方式来组织同意测试。 设计模型完成之后，同意

55、测试差不多细化到模型的各个元素上了（例如包、类）。该项活动和将需求映射到设计的活动是同步进行的。因为它们处理的信息是特不类似的。和同意测试一样，这两个活动都需要由团队来保证。 在进入编码时期之后，开发人员依照同意测试和设计模型，将会为自己负责的部分设计编写单元测试。单元测试的编写顺序是否优先于编码，这取决于各人的看法。关于这方面的讨论，能够参看XP的单元测试实践。从我个人的经验来看，先写单元测试，再写代码不失为一个专门好的方法，另一种做法是，让两个紧密合作的开发人员相互为对方编写单元测试。 其次，我们需要保证测试的最小单元单元测试的成功。所谓皮之不存，毛将焉附。单元测试没有组织好，最后的软件是

56、可不能成功的： 需要注意单元测试的覆盖率。那个地点的覆盖率指的是是否能够完全检测出错误所在。比如边界条件的测试等。开发团队中的架构师之类的角色需要为此负责，假如无法检查所有的单元测试，那么能够进行抽查和代码复审会议的形式。后者是一种专门优秀的做法。从代码中抽取出一段，开发人员一起分析单元测试存在哪些问题，会使得大伙儿编写单元测试的功力不断的增长。 单元测试一定要是自动化的。Junit确实是一个不错的自动化测试框架。保证单元测试的自动化，同时幸免单元测试和特定环境相关，如此就能够顺利的进行回归测试。这关于迭代式的软件开发是特不必要的。同时，我们也应该认识到，单元测试的稳定性取决于设计的稳定性。我

57、们能够想象，假如测试的类方法的参数、命名都发生改变，那么测试是确信需要重新组织的。因此，面向对象的抽象思维关于现代软件开发而言是费产重要的。为了做到测试的自动化，尽量幸免将逻辑硬编码在界面中，并小心的处理数据库。能够尝试着建立测试数据库。 假如测试的内容需要并入核心构架，那么这部分的测试工作需要增加，并对构架可能的修改进行测试。因此，学习开源软件的做法，将构架的稳定版本和开发版本相区分是比较保险的。 让测试活动随着软件开发的进行而进行，让测试活动贯穿整个开发周期。这有点类似于全面质量治理的思想。因为软件开发过程的失败并不是突然而至的，而是在平常的不经意间一点一点的积存起来的。使用测试活动来消除

58、这种微小的不稳定性，能够大幅度的提高最终软件的质量。然而，在一个团队中引入正规的。频繁的测试活动是需要耐心的。能够先从单元测试着手，慢慢的普及这种做法。 测试活动能够衍生为日创建和冒烟测试。关于有复数的开发人员参与的软件项目，就无法幸免正视集成测试的局面。有过类似经验的人都能够想象的到这种集成测试的难度。专门有一句话是描述这种局面的：我们差不多花了90%的时刻来完成90%的软件，但我们还需要90%的时刻来完成剩下的10%。现代的软件往往都包括成百上千的文件，这些文件的编译链接的过程是专门复杂的。而日创建的思想确实是每天进行一次如此的过程，形成一个可执行文件。但这只是日创建第一部分内容。日创建还

59、需要对软件进行冒烟测试，测试的要紧内容确实是单元测试中所编写的内容，保证软件能够通过所有的测试。 日创建需要留下一些调试的时刻，尤其是在软件开发初期，不同开发人员的代码整合在一起出现问题的可能性极大。随着对这项实践的熟悉程度，问题会逐渐减少。日创建能够专门明显的提高产品质量，以及提升团队的士气。尽管日创建活动需要付出额外的一些成本，然而相关于集成测试的不可控，这些成本依旧值得的。 6、小结投资于框架能够保证软件开发的成功。 应用有效的实践活动来完善框架。 将需求映射到核心框架上来。 使用原型法。 注意测试活动。 假如可能，使用日创建，并进行冒烟测试。 规则不同于指南。规则是目标受众所必须遵守的

60、，而指南是建议目标受众遵守的。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 四、一致性的考虑 一致性原则是软件开发中重要原则，也是最令人困惑的原则。做到完全的一致性将会导致高昂的成本，而不一致又会导致项目出现各种各样的问题。能够想到，这又是一个需要权衡的问题。1、意图 软件过程中的大部分工件都需要保持其相互之间的一致性。但是，工件越多，保持一致性的开销也就越大。我们需要在一致性和成本之间保持平衡。2、示例 天利软件公司的项目经理正在为开发过程中出现的大量的