Wouldn't it be nice if you were to take the initial requirements document for a project and be able to accurately estimate the design and development effort? This article tells you how to transform a Unified Modeling Language (UML) model created in IBM® Rational® Software Architect into a dynamic estimation and feedback engine. Thanks to the tremendous growth in Model-Driven Architecture (MDA) and design, static nondescript images, models, and diagrams are now close to the point they can be executed. Rational Software Architect and IBM® Rational® Software Modeler are key proponents of Java Emitter Templates (JET) and UML modeling. This article attempts to go beyond the traditional code generation to more useful systems, such as estimation.
The JET projects in this article describe these tasks:
- Estimating at the requirements and analysis stage
- Comparing estimations as the model matures, at the design stage
- Generating feedback to the model
Models provide vivid insight into how business problems can be expressed through notational UML. A typical requirements gathering includes these components:
- Requirements and business behaviors expressed through use cases and interactions
- Processes and goal modeling illustrated by activity diagrams
- Messaging expressed through structural models, such as Class and Component models
Models evolve and mature over time. A typical model that started as just requirements may also include structural classifier models that express interactions. A use case model is a perfect place to start the estimation process.
The Eclipse Modeling Framework (EMF), which is an integral part of Rational Software Architect (and Rational Software Modeler, contains powerful tools for generating source code and documents. One of them is JET (Java Emitter Templates). With JET, you can use a syntax that is somewhat like JavaServer™ Pages (JSP) to write templates and run them against models.
The article is intended for readers who have a reasonable working knowledge of Rational Software Architect. It is also based on the assumption that the reader understands XML, Java™ technology, and XPATH scripting syntax and semantics.
First transformation: project estimation from use cases
A portion of this article is based on the findings that Capers Jones describes in Chapter 7 of his book, Estimating Software Costs: Bringing Realism to Estimating, Second Edition (see Resources). See Chapter 7, "Manual Estimating Methods Derived from Agile Projects and New Environments." He states that a use case represents an average of roughly 35 function points, although it can vary between 15 and 75 function points. A typical application of 1500 function points (roughly 75,000 Java statements), would require about 42 use case diagrams. A single use case roughly defines the usage pattern of about 1785 Java statements.
Use case estimation was baselined in 1998-2001. Much of thought leadership came from Schneider and Winters in1998 and Alistair Cockburn in 2001 (see Resources). This article assumes that a project team that wants to estimate with use case points writes their use cases at goal levels. Each use case therefore has a goal. The goal of a user goal-level use case is analogous to a unit of business value.
Use case points are an accumulation of total numbers of actors, relationships, and other aspects of use case methodology that indicate a value for the project being estimated, thus forming the basis for the JET2 estimation engine. After the size in use case points is determined, effort and schedule algorithms can then be applied.
Complexity of actors and use cases
Each use case represents an average of 35 function points. Figure 1 shows a simple project as outlined and created in Rational Software Architect.
Figure 1. Use case example
You can use Table 1 to determine unadjusted weighted values of use cases and actors.
Download here:
http://www.ibm.com/developerworks/rational/library/10/modeldrivenarchitectureusingjet2inrsaorrsm/index.html?S_TACT=105AGX15
0 comments:
Post a Comment