120 Computer A nalysts frequently describe troubled projects with the tar pit metaphor used so effectively in Fred Brooks’s The Mythical Man-Month (2nd ed., Addison- Wesley, Reading, Mass., 1995). We have found a similarly effective metaphor: Think of a troubled software project as an insect caught in a spiderweb of sticky constraints, trying desperately to break free before the spider arrives to feed. MODEL CLASHES Our experience and studies of soft- ware-model clashes confirm that every software project is unavoidably con- fronted by a spiderweb of potential model clashes derived from the success models of the project’s key stakeholders. These stakeholders usually include the software system’s users, acquirers, devel- opers, and maintainers. Additional key stakeholders can include venture capi- talists, marketers, proprietors of mutu- ally developed interoperating systems, and the general public when issues such as safety and privacy arise. A model clash reflects an inconsistency among the assumptions of the various process, product, property, and success models your project uses to guide its progress. Developers use a myriad of process models to create software. Among the most popular, the waterfall model demands the sequential determination of the system’s requirements, design, and code, while the evolutionary development model defers the full definition of future increments in favor of developing an ini- tial core capability. Other models include incremental development, spiral develop- ment, rapid-application development, adaptive development, and many others. Product models include various ways of specifying operational concepts, re- quirements, architectures, designs, and code, along with their interrelationships. Property models define the desired or acceptable level and permissible trade-offs for project factors such as cost, schedule, performance, reliability, security, porta- bility, evolvability, and reusability. Success models include correctness, stakeholder win-win, business-case, or other ap- proaches such as IKIWISI (I’ll know it when I see it). Users frequently choose this last model when developers ask them to specify their user-interface requirements. The underlying assumptions of these various models often conflict. For exam- ple, let’s look at the key assumptions underlying the sequential requirements- first waterfall model: 1. Participants can determine all re- quirements in advance of implemen- tation. 2. Requirements have no unresolved, high-risk implications—such as risks associated with commercial-off-the- shelf software choices or the effects of cost, schedule, performance, secu- rity, user interface, and organiza- tional issues. 3. Participants well understand the right architecture for implementing the requirements. 4. Requirements match the expecta- tions of all the system’s key stake- holders. 5. The requirements’ nature will change little during development and evolu- tion. 6. Deadlines allow enough calendar time to proceed sequentially. When one of these assumptions proves false or contradicts another assumption, a project using the waterfall model will likely run into serious trouble. For ex- ample, assumption 1 stipulates that par- ticipants can determine requirements in advance of implementation. A project staff that believes this—or that collects progress payments by delivering a com- plete requirements specification under a waterfall-model contract—will formal- ize user-interface formats and behaviors as ironclad requirements specifications, then build the system to those specifica- tions. This approach frequently results in a delivered system with a user interface that fails the user’s IKIWISI success- model test. Inevitably, the client either rejects the system or demands a major rework effort that is both expensive and time-consuming. Assumptions 2, 3, and 4 frequently conflict with property-model assump- tions if a software acquisition hastily locks the project into unrealizable prop- erty-level contract requirements. Avoiding the Software Model- Clash Spiderweb Barry Boehm, Dan Port, and Mohammed Al-Said University of Southern California SOFTWARE MANAGEMENT The authors offer two techniques for avoiding the conflicting assumptions that often snare software projects in a costly and time-consuming spiderweb.