I posted last year about a project where we got Jeff DeLuca in where we were doing Colour Modelling and FDD. Well Episode 83 of Software Engineering Radion is with Jeff DeLuca the creator of Feature Driven development. A real good synopsis of what FDD is and just as importantly what it isn’t. Something Jeff emphasised several time is that FDD and all agile methodologies for that matter focus on the people aspect which is something I picked up when I worked with FDD.
Posts Tagged ‘FDD’
Over the last couple of weeks I have learnt to Colour Model, which introduces some interesting concepts to modelling that you don’t get from Black and White UML. Peter Coad and specifically his book on Color Modelling created the concept. On Peter Coad’s web site the first chapter of his book is available as a download which introduces it well.
At the core of Colour Modelling are four archetypes that allow classes to be categorised. The four archetypes types are:
Moment Interval (Pink) – It represents something that one needs to work with and track for business or legal reasons, something that occurs at a moment in time or over an interval of time.
Role (Yellow) – a role is a way of participation by a party (person or organization), place, or thing.
Description (Blue) – it is a catalog-entry-like description e.g. a lookup table.
Party,Place,or Thing (Green) – A party, place, or thing is some-one or something who plays different roles.
By categorising your classes in this way you have to ask some interesting questions about the business process (pinks), who (yellow) is involved in the processes and what role (yellow) do they perform. Then there are the descriptions (blue) of all of the above.
Out of this came the Archetypal Domain Shape which firstly show how these shapes generally hang together but also the type of attributes and behaviors you would expect them to have. It provides a good way to figure out what things are and secondly pick up attributes or behaviours that may have been missed.
In the book Java Modeling In Color With UML Peter then goes into typical shapes that you would expect to see for different problem spaces. A good example of this is the parent-child type pattern you would expect to see with some thing like an order and order-details type relationship.
I read the book but it wasn’t until I got into modelling a system that I got to appreciate the beauty that is colour modelling. Colour modelling when we did our modelling exercise with the business on our project was a great communication tool allowing a clear and concise definition of the scope of the project.
Disclaimer: I am from Australia so Colour is spelt with a ‘u’.
I have just spent two weeks locked away with two domain experts (users) and a team of ‘L’ plate modelers (myself included), modelling an application that we are about to start building. We got in Jeff De Luca of Feature Driven Development fame to teach and guide us in a process called colour modelling. We started with a two day training course in colour modelling and then we were into it. For two whole weeks building up our understanding of the system and capturing it in models using colours that represent the various archetypes.
The team went through all the highs and lows that characterise the development of a team, so coming out of this we ended up with a strong team of people. The team also now owned the resulting model of the application that had been built up, there is now a history there, blood had almost spilt over names of things and it had all been redrawn a couple of times, changing what was there wouldn’t be done without a fight.
The exercise of building the model revolved around the users walking us through small areas of the process that we then produced a model for. Requirements and use-case documents that had been written were there for reference but the user was the primary source of truth.
One thing I hate about any requirements document is that there is always interpretation involved when designing the system that will meet these requirements. It kills me when the users come back and point to a line in the requirements and explain how this means you should have actually built something completely different to what you had assumed. When we were modelling because of the way we are capturing the requirements in the model, things are very explicit, so there is only one interpretation. On more than one occasion the users would make a comment that contradicted something we had previously modeled and we knew at that point that they had changed the requirements and could seek clarification from them there and then.
Getting so much of the users time (2 weeks) seemed like a tall order before we started this but we ended up with almost 100% of their time during this two weeks which was great. Having the users there was vital as previous understanding that were captured in the requirements document got tested as part of each walk-through. The users as much as the modelers were challenged because there was nowhere to hide and in the early stages there was some rethinking that had to go on but they quickly realised what was required of them, so came prepared.
Out of this two weeks we have a model, yes but we have so much more than that. Agile promotes “Business people and developers must work together…” which for one reason or another is easier said than done but this process of modelling gave us that understanding between the technology team and the business. The team that built the model has an intimate understanding of the domain from a business perspective and from an implementation perspective. Best of all we have a core group who are a performing team!
The next question is how do we repeat this process for other projects, Jeff brought so much to the team, it just won’t be as simple as following the process.