David Anderson Headshot
Ask a question!
Voice an opinion!
Join
Agile Management
Yahoo! Group
 
 
 
 
 
 
BlogEntry
Friday, August 06, 2004
 

Spiral Model Revisited

 

I feel that more and more what I and others are doing with agile comes back to Boehm's Spiral Model first postulated in 1986 [1] and refined in 1988 [2]. Boehm described Spiral as evolutionary rather than incremental. The purpose was risk management and the enabler was the ability to analyze the whole system but only in the briefest of detail to identify the highest priority features for an initial iteration. On delivery of the iteration, customer feedback would be used to prioritize the next set of features and make refinements and add detail to the initial analysis. It was this feedback and refinement which separated it from merely incremental development - presumably the assumption in 1986 was that incremental meant, big analysis up-front, divide system into set of iterations, perform each iteration in open loop without accepting changes.

I've been reflecting on a big FDD project I was involved in during the first half of the year which started its discovery phase in the Q4 last year. Without realizing it was significant, I now reflect on the fact that we did two passes of modeling - this is not part of the standard FDD prescription. The domain was so new that no one really knew what they wanted or what the system should do. We did a first pass domain modeling session with all the marketing and project management folks as well as architects and chief programmers. This initial pass was very thin - it was this way because we knew so little about the domain. However, this served its purpose to flush out areas for further discussion and as an enabler to allow the marketing folks to define their requirements. This first pass modeling session gave us a scope, a list of business processes and an outline of the subject areas in the domain. It was enough for us to identify rough outlines for 6 iterations.

The second pass of modeling - in greater detail, but no greater than a typical FDD project - then happened on each iteration and typically took 4 to 5 days. For a 7 week iteration, this is a lot more time spent modeling than Jeff De Luca or Peter Coad would typically recommend (1 week for every 3 months), but the domain was new and uncertain which probably explains the extra effort required. A Feature List would then be written and the iteration scoped in detail. The Design-By-Feature, Build-by-Feature cycle would then start and each Feature would be designed with a UML sequence diagram. Hence, there were three passes at modeling and on each pass more information was obtained. This is one more than a typical FDD project and it begins to sound more and more like Boehm's Spiral Model.

When I first heard about Spiral Model, I was dismissive. The key to it is an ability to examine a problem in only enough detail to move around the loop. It's been widely identified that over-modeling, or drilling deep is a common problem with developers. The natural tendency is towards "big design up-front." What makes the Spiral Model hard to achieve in practice is that discipline or craft tool which enables a wide but not deep pass of entire scope in order to manage risk and prioritize deliverables. At the time, I didn't believe that a suitable technique - a suitable enabler - existed to make Spiral Model real in practice. However, I am now wondering whether Coad's domain modeling in color archetypes is such a tool and an enabler of a true spiral approach to software engineering.

I ask myself would I do it again - domain model in two passes for a multi-iteration project? The answer is definitely, "Yes!" Do I think that developers can be taught to model just wide enough, to embrace uncertainty and to understand when they have just enough information to move forward? The answer to this is also "Yes!" but there is a caveat. This skill - of knowing when to stop - is learned through experience. Hence, the skill can only be passed from individual to individual through real world work experience and direct observation. It truly is a craft. Could we (the experts in domain modeling in color) codify that experience so that it might be taught in a classroom? I don't have an answer for that yet...

References
[1] Barry Boehm, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, August 1986.
[2] Barry Boehm "A Spiral Model of Software Development and Enhancement", IEEE Computer, vol.21, #5, May 1988, pp 61-72.

     
 
           
hosted by likk.net
Weblog Commenting by HaloScan.com