敏捷建模与统一过程（二）

Case Study: Wayne Enterprises
案例：韦恩企业
In early 2001 I was involved with a development project at Wayne Enterprises, the name has been changed to protect the innocent, a medium-sized financial institution. They had adopted the RUP and wanted to tailor it with Enterprise Management discipline concepts from the EUP, in particular they wanted to ensure that the Inception phase (Ambler & Constantine, 2000a) and Elaboration phase (Ambler & Constantine, 2000b) efforts of individual projects were supported by enterprise-level requirements, architecture, and reuse efforts. They also wanted to ensure that their modeling processes were effective, they weren’t convinced that the UML was sufficient for their needs (it wasn’t) and they wanted to ensure that legacy integration modeling was reflected in their tailoring of the RUP. I was eager to apply AM on a RUP project and they liked the basic concept of the methodology and were willing to give it a try.
2001年初，我加入了韦恩企业的一个开发项目，名称已经变成一个中型财务系统。他们采用了RUP，并想用EUP中的企业管理律条概念来剪裁它，尤其是他们想确保让企业级需求、架构和重用去支持单个项目中Inception阶段(Ambler & Constantine, 2000a)和Elaboration阶段(Ambler & Constantine, 2000b)的工作。他们想让建模过程变得有效，因为他们不相信UML已经足够应付他们的需要。另外，他们还想使遗留集成模型反映到RUP的剪裁中。我要在RUP项目中应用AM，而他们也喜欢方法学中的基本概念并愿意尝试。
The culture of Wayne Enterprises was conducive to change, which was a huge benefit. Management was open minded and willing to try new techniques, hence the RUP. As you would expect the developers were also eager to try new techniques and work with new technologies, although nowhere near as enamored with the RUP as management was. Our approach was to pilot the RUP on a small project，there was seven developers, one manager, one senior manager and four users，over a period of seven months. The project was of mid-level importance, it would be noticeable if we failed but it wouldn’t put the company at risk. It was their first real project J2EE project, and the team was fairly typical: there was two mid-level Java developers; a senior consultant experienced in EJB; another senior developer with a C++, OMT, and UML background; a experienced business analyst that was new to use cases and object-oriented development; a DB2 database administrator (DBA) learning Oracle; and a good QA/tester person with some Java testing background.
韦恩企业的文化有益于变更，这是一个巨大的好处。管理是开明的并愿意尝试新技术,因此RUP得以实施。正如你期望的那样，开发者也希望尝试新的技术并在工作中使用，尽管远不及管理者对RUP那么推崇。我们的方法是在一个小项目中使用RUP，其中有若干开发者、一个经理、一个副经理和四个用户，时间超过7个月。该项目是重要性为中级，如果我们失败，它是可见的，但不会给公司带来风险。这是他们第一个实在的J2EE项目，且团队相当的典型：有两个中级Java开发者、一个有EJB经验的高级顾问、一个有C++、OMT和UML背景的高级开发者、一个在用况和面向对象开发上是新手的经验丰富的业务分析师、一个正学习Oracle的DB2数据库管理员(DBA)以及一个有Java测试背景的QA/测试人员。
At the beginning go the project we tailored the RUP with the practices of AM and a portion of the EUP’s Enterprise Management discipline, the end result of which was the creation of something the RUP calls a development case. This effort took several days, I had all the raw material that we needed to add, and everyone recognized that there was little value in spending much more time than that everybody wanted to get to work on the project. My involvement with the project was to help them with the initial creation of the development case and initial overview training to the development team. I also periodically reviewed the effort, both from an architectural point of view and from a software process point of view ， their first goal was to develop a good system and their second goal was to ensure that they were learning how to do so effectively.
在项目开始的时候，我们用AM实践和一部分EUP的企业管理律条剪裁RUP，最后的结果是，我们创建出在RUP中称为开发案例的东西。这项工作耗时几天，我拥有我们需要添加的所有源材料，而且每个人都认识到，在这件事情上花费比项目工作多得多的的时间是几乎没有价值的。我在项目中就是要帮助他们创建开发案例并对开发团队进行一般培训。我还周期性地从架构的观点以及从软件工程的观点复查工作。他们的首要目的是开发一个好的系统，次要目的是保证他们能学到如何有效地开发。
During the Inception phase the team produced a high-level requirements model, about 20 use cases and a 15-page supplementary specification that the business analyst evolved throughout the project. A lot of this documentation was initially written by the user representatives, after breaking out of requirements modeling sessions led by the business analyst and attended by one or two developers at a time. The Elaboration phase was mostly white boarding performed by the entire team and some coding and testing of an end-to-end prototype to prove the architecture. The kept the models as simple as they possibly can, some of this was motivated by the realization that they weren’t familiar with the technology and therefore it was futile to over model things, and part of it was because they were eager to code EJBs, servlets, and JSPs. This phase went a little slower than usual due to the team?s inexperience with setting up EJB, developing EJBs, and deploying them [3]. The Elaboration phase was a good learning experience for the team because it gave them experience in the technology and in following their tailored process.
在Inception阶段，团队开发了一个高层需求模型，包括业务分析人员在整个项目中使用的大约20个用况和15页辅助说明书。这些文档中很多最初是由用户代表写的，然后由业务分析人员和一两个开发人员一次性完成需求建模会谈。Elaboration阶段主要是由整个团队从零开始实施，并用一个端到端的原型代码与测试来验证架构。他们所持的模型要尽可能简单。有的模型用他们不熟悉的技术实现，因此过分建模是没有效果的。而有一部分是因为他们想学习编EJB、servlet和JSP。这个阶段通常比正常情况要慢，因为团队对设置、开发和部署EJB没有经验。Elaboration阶段是团队学习的好时期，因为它在技术和接下来的剪裁过程方面能给予他们经验。
It also helped to dampen the DBA’s argument that the data architecture was the primary concern, granted the legacy data issues were challenging, and was an important stepping stone towards building a common understanding of how to work together as a team. During the Construction phase the use of Together/J and the data modeling tool very common, although white boarding was still used for high-level thinking and discussions. From what I could gather the architecture models stayed up on the white boards, the critical ones were a layered deployment diagram and a high-level sketch of the structure of the object schema. The DBA maintained and evolved the data model maintained by the DBA, outputting it regularly to their plotter and tacked to the wall. The organization already made it a practice to Display Models Publicly long before they adopted RUP and AM. The team had five four-week iterations in the Construction phase, implementing between two and five use cases at a time. The Transition phase was fairly standard, from an AM point of view the most important effort was a documentation clean up at the end.
它还能帮助减少DBA的意见。因为他认为数据架构是首要的，遗留数据问题是具有挑战性的而且是建立如何与团队协同工作的观念的重要一步。在Construction阶段，使用Together/J和数据建模工具非常普遍，尽管白色书写板仍然用来高层思想和讨论。从我在白色书写板上获得的架构模型中，我发现关键的是分层部署图和对象模式结构的高层草案。DBA维护并演化数据模型，定期向他们的同伴输出它并最终定夺。该组织在采用RUP和AM之前，就已经采用就公开展示模型的实践。团队在Construction阶段进行了五次四周迭代，一次实现两到五个用况。Transition阶段相当标准，从AM的观点，最重要的工作是在最后进行文档清理。

原文转自：http://www.ltesting.net