Article Preview
TopThe Iid Approach
The IID approach is not designed by a single source. Rather it has come “independently from countless unnamed projects and the contributions of thousands” (Larman and Basili, 2003). At the simplest level, the IID approach refers to a way of developing information systems that emphasizes a number of techniques including user participation, incremental evolution and time-boxed iteration. The approach is shared by a number of ISD methodologies, including Rapid Application Development (RAD, see Eva, 2001; Martin, 1991), Dynamic systems development methodology (DSDM, see Stapleton, 1997), SCRUM (Schwaber, 1995), Rational Unified Process (Kruchten, 2000), eXtreme Programming (Beck, 2000) and various other “agile” methodologies (Highsmith, 2000; Lin & Shao, 2000) . IID has been construed as the way to overcome the weaknesses of the “Waterfall Model”, or “the sequential process” (Kruchten, 2000). The IID approach recognizes that requirements cannot be “frozen”. It thus dispels the misconception about the need for complete requirements before design and development. IID also acknowledges the inseparability of design and development. At a theoretical level, IID advocates a flexible, social constructive approach to product management, unlike the traditional planning-based approach (Koskela & Howell, 2002b). Koskela and Howell (2002a) examine SCRUM in particular and concluded that it is based on “alternative theories of planning, execution and control”.
While the IID-based methodologies may represent a step forward in the thinking of information system development, they have not always been successful in resolving ISD project challenges. Despite the proclaimed intention of the IID proponents to address system development failures, the rate of failures has remained high (see e.g. Charette, 2005; Goulielmos, 2004). There could be multiple explanations to account for this lack of success. One is that “effective” methods are not applied (see Humphrey, 1998 for such a discussion in the context of software engineers’ practices) or applied incorrectly (see Highsmith, 2002 for an example of incorrect use of timeboxing). Another possibility is that there might be fundamental weaknesses with the IID approach itself. Many publications and training courses have been made available to practitioners based on the first explanation (Humphrey, 1998). This article, however, critically examines the possible weaknesses of the IID approach itself. Three key techniques are identified that are common to IID-based ISD methodologies, namely user participation, evolutionary prototyping, and timeboxing, each is briefly outlined below.