发表于:2008-02-03来源:作者:点击数: 标签:敏捷建模
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 an

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.
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.
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.
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.