| By Pak-Tjun Chin,
on 03-11-2008 06:41
|
Views : 21658  |
Favoured : 430 |
The Begining
Sometime in 2007, I was approached to initiate a project using an Agile Methodology. I decided on Feature Driven Development (FDD) as some of the developers within the organization that I worked in had prior experience working with FDD. It was also deemed to be the most 'non-agile' of the Agile Methodology which made the methodology more 'acceptable' to other parts of the bank.
Within FDD, there are essentially a couple of phases, a one-time startup phase and an iterative contruction phase.
Diagram 1: Phases of FDD
One of the key plus points of FDD being adpoted as an Agile Methodology by bigger organizations, that are more predictive rather than adaptive in nature, is its ability to allow for a lot of the planning to be done up front during the startup phase. Due to this, a project would be able to request for seed money to determine project viability up until the completion of the 'Plan by Feature' process. At the end of this process, the project would be able to present its findings to the estimation committee in determining the time and budget required to design and construct the project. This takes a lot of 'guesstimation' work out of a project as compared to other Agile Methodology like eXtreme Programming, that just goes on and on and on, like one of those Energizer battery advertisements.
The focus of this article is on the first process of FDD, which is the development of an Overall Model for the project.
Color UML Modelling
Before we can explore what exactly constitutes the development of an Overall Model process, (which I personally feel is a requirements gathering cum high level design phase) we need to understand a bit of color UML modelling, which is the tool in which drives this process. Of course, one may argue, that we can use a variety of other methods to achieve this like use cases, traditional business/functional requirements specification, etc. It really all boils down to what works best for your project and the kinds of skill-set that the project members have. There is really no right or wrong approach.. The project stakeholders need to have consensus on the approach and then commit to it. Personally, I feel that you can use any approach, or a combination of approaches if it results in the same outcome, which is to adequately define the problem domain of the software system.
However, as the recommended approach for this process in FDD is Color UML Modelling, I am going to stick to it and then see where that takes me.
Color UML modelling was introduced by Peter Coad in 1997 with four colors of Post-itTM Notes: pink-yellow-green-blue.
Color
|
RGB |
HEX |
| Pink |
250,190,190 |
#ffbebe |
| Yellow |
250,240,180 |
#faf0b4 |
| Green |
180,230,180 |
#b4e6b4 |
| Blue |
180,200,210 |
#b4c8d2 |
Table 1: Hex and RGB codes for Color UML Modelling
The Hex and RGB codes in Table 1 were provided by Jeff De Luca during his engagement to the FDD project that I worked on.
Now, what do these 4 colors represent? These colors represent 4 interconnected archetypes that form a domain neutral component (DNC). An archetype, as derived from Webster75 and Haykawa68, represents 'a model in which all things of the same kind more or less follow'. The 4 archetypes are:
- The pink moment-interval archetype.
- The yellow role archetype.
- The blue catalog-entry-like description archetype.
- The green party-place-thing archetype.
Diagram 2: The four interconnected archetypes and their colors.
Each of these four colors corresponds to an archetype's characteristics, the attributes, links, methods, plug-in points, and interactions that corresponding classes follow, more or less.
Thus, if given a class, how do we determine what archetype and color it represents? Well, just follow these 4 easy steps:
- Does the class represent a moment in time or interval of time? If so, it's a pink moment-interval.
- Otherwise, does the class represent a role? If so, it's a yellowrole.
- Otherwise, does the class represent a catalog-like description? If so, it's a blue description.
- Otherwise, the class is a greenparty-place-thing.
Building the Problem Domain
Now that we've got a bit of backgound on Color UML Modelling, lets get right into understanding a bit more about the first phase of FDD, 'Develop an Overall Model'.
This process is absolutely critical towards the success (or failure) of a FDD project. The outcome of the process is a UML diagram and a list of features. UML diagram(s) define the problem domain of the software system. If properly implemented, it covers all the relevant areas of business and allows to easily adding features for subsequent releases. The list of features becomes the baseline for the project timelines. In this respect, FDD depends on user requirements as much as waterfall does. The key point here is not the 'What' but the 'How' in terms of requirements gathering. FDD, through color modelling, brings together the project and business teams in flushing out requirements. The close interaction between business stakeholders and developers forges a healthy engagement by all parties.
The modeling starts with a short introduction to UML for domain experts. by the chief modeller. My project was very fortunate to have Jeff De Luca play this role. While the expectation was not to have every project member become UML gurus overnight, it was agreed that the introductory session was very helpful in setting the stage for the actual domain modelling sessions to follow.
Diagram 3: Domain Walkthrough by a Business Domain Expert
The modeling sessions themselves are split into iterations. Each iteration commences with a domain expert (business stakeholder with subject matter expertise) detailing a a small fragment of business. This constitutes the user 'story' that is to be captured and elaborated. It should take no more that 15 minutes per user 'story'.
Diagram 4: Domain Walkthrough by a Business Domain Expert Modelling Group Comprising of Domain Experts and Developers
The team then splits into several modeling groups; each of them includes developers and domain experts. Each group creates UML model(s) that reflects the story. The teams then present and discuss the models. At the end of iteration the best one is chosen/merged. The modelling sessions continue until the overall domain model that satisfies all the stories is created.
Diagram 5: Modelling Group Presenting their Model to the Project Team
The good overall domain model covers all of the business stakeholder's requirements. It supposed to be stable, that is, user requirements for the application may change, while the business stays relatively the same. In addition to creating object-oriented model of business, this process indirectly indicates the duration of construction phase. FDD rule of thumb says that the development team will spend approximately 6 months of development for each 2 weeks of modeling.
Diagram 6: The Overall Domain Model
Domain Modelling By Example
Let us now go though a practical example of a domain model creation. I have picked one of the domain models ofr the project that I was working on which details the domain of the application user.
Domain Walkthrough
At the start of the session, the domain expert detailed the requirements of a end-user interacting with the application. The following notes (just a sample of what was actually noted) were taken during and shortly after the walkthrough:
- A user can change their default BUID to any other BUID in the system. They can only belong to a single BUID at any point in time.
- The BUID list held by the system is used for the creation of submissions, and for their transfer between BUIDs.
- When created, a pricing submission is assigned the default BUID of the creating user.
- As the default view, the application will show all pricing submissions for the current default BUID of the logged in user.
- A user can list pricing submissions that they have created.
- The list of pricing submissions must be sorted by the pricing submission status, then by last modified date (descending).
Domain Model
Diagram 7: Domain Model of DPC User
From the domain walkthough, it was noted that there were 2 parties involved in this application, an 'Employee' (represented by the 'Employee' class) and an 'Organization' (represented by the 'BUID' class). We had just a single 'role' represented by the 'DPCUser' class.We also identified 3 'description' entries and a couple of 'moment-interval' entries.
Some of the business rules captured during the domain walkthough included the ability of the DPC User to list all its Pricing Submissions. This is represented by the 1-Many relationship between 'DPCUser' and 'PricingSubmission'. There is also the method 'listCreatedPricingSubmissions' associated with this requirement.
A pricing submission could only have one DPC User as its creator, which is represented by the Many-1 association.
In summary, the domain model paints a complete picture of the business requirements for the DPC User domain. Eventually, all the domain models would be merged into the overall domain model.
Domain Model Merge
Diagram 8: Overall Domain Model
Towards the end of each week, all the domain models would be merged into a overall domain model. This is to ensure that the overall domain is consistent in its structure and behaviour.
Conclusion
The Good
- Provided the opportunity for business and technology teams to work in close face-to-face collaboration. This is pure gold as the level of engagement with business stakeholders shoots up the roof, which is something that is rarely achieved in an outsorcing model. This intangible benefit has been noted as one of the key proponents against technology outsourcing.
- Provided the developers with immediate first hand answers to their questions rather than having to go through a 3rd party like a business analyst or the project manager, which may take a couple of weeks to close off.
- Allowed for team dynamics to go through its normal course of forming, storming, norming and performing much quicker than a waterfall project. During the domain modelling sessions of my project, the storming happened quick, thick and fast. This really helped the project team to normalize and perform further on in the project lifecycle.
- Allowed business stakeholders to visualize where their money is going to early on. Color models were easily understood by business stakeholders.
The Bad
- The cost of having a big team engagement this early on in the project lifecycle may not be viable as compared to a waterfall approach, whereby it is normal that only a business analyst and solution designer need to be engaged.
- The availability of good object-oriented developers. The project had a lot of difficulty trying to round up even 5 in-house developers whom were strong in OOAD. Eventually, we had to procure external contractors to establish a strong development team.
- It can also be said that doing so much design up front goes against the spirit of Agile.
In conclusion, I must admit that the 3-week domain modelling session that I went through was pretty intense and at times chaotic. However, the goodness that came out of it far out-weighted the negatives. Would I do it again? Yes, with the right team and project mindset.
Last update: 05-11-2008 12:47
|
