www.stsc.hill.af.mil 23 I his keynote address at the 1996 International Conference on Software Engineering, Tom De Marco summarized the work of the great military analyst Karl Von Clausewitz on the interplay of armor and mobility in military conflict. De Marco said Clausewitz proposed that at times, armor would dominate mobility, as with heavily armed medieval knights dominating lightly armed peasantry. But if over-optimized, one strategy will lose to advances in the other, as the ponderous French knights found in their inability to dominate the lightly armed and mobile English longbowmen in their watershed loss to the English at Crecy in 1346. De Marco then drew a parallel between armor-intensive software strategies such as the software Capability Maturity Model® (CMM®) and the mobility-intensive lightweight processes that were emerging at the time. He was inferring that the software CMM was too ponderous to cope with the need for rapid development and rapid change characteristic of such sectors as electronic commerce and Web-based systems. In the ensuing discussion, software CMM advocates cited the high mortality rates of lightweight process organizations, and their frequent inability to cope with success when they need to scale up their process and architectures to deal with more complex services and heavier workloads. Underlying this point/counterpoint is a key software-engineering question: How much discipline is enough, and how much flexibility is enough? In Understanding the Spiral Model as a Tool for Evolutionary Acquisition [1], we showed that the risk exposure considerations used as spiral model decision criteria could be used to address how-much-isenough questions. There, we showed how a how-much-testing-is-enough question could be addressed by balancing the risks of doing too little testing (alienating your users) and the risks of doing too much testing (unavailable combat capability, missed market windows). In this article, we show how the spiral model and its recent extension, ModelBased (system) Architecting and Software Engineering (MBASE), can be used to tailor a project’s balance of discipline and flexibility via risk considerations. We also describe and rationalize the major MBASE extensions to the spiral model (model clash avoidance, stakeholder win-win), and elaborate on the use of these extensions and risk considerations in the anchor-point milestones used in MBASE and the spiral model. In subsequent articles, we will present an attractive special case of MBASE, the Schedule as an Independent Variable (SAIV) process model, and present an integration of the MBASE project approach with the University of Maryland’s Experience Factory approach, which facilitates an organization’s transition to the Capability Maturity ModelIntegrated (CMMI).
[1]
Barry W. Boehm,et al.
Anchoring the Software Process
,
1996,
IEEE Softw..
[2]
John J. Marciniak,et al.
Encyclopedia of Software Engineering
,
1994,
Encyclopedia of Software Engineering.
[3]
H. D. Rombach,et al.
THE EXPERIENCE FACTORY
,
1999
.
[4]
Barry Boehm,et al.
The Spiral Model as a Tool for Evolutionary Acquisition
,
2001
.
[5]
David Garlan,et al.
Architectural Mismatch: Why Reuse Is So Hard
,
1995,
IEEE Softw..
[6]
Barry W. Boehm,et al.
Developing Groupware for Requirements Negotiation: Lessons Learned
,
2001,
IEEE Softw..
[7]
Walker Royce,et al.
Software Project Management: A Unified Framework
,
1998
.
[8]
Barry W. Boehm,et al.
Using the WinWin Spiral Model: A Case Study
,
1998,
Computer.
[9]
Barry W. Boehm,et al.
Escaping the software tar pit: model clashes and how to avoid them
,
1999,
SOEN.
[10]
Barry Boehm,et al.
Avoiding the Software Model-Clash Spiderweb
,
2000,
Computer.