Iteration, Increments, and Parallelism

“Iterate:1: the action or a process of iterating or repeating: asa: a pro- http://www.m-w.com

cedure in which repetition of a sequence of operations yields results successively closer to a desired result”

“Increment: 1 : the action or process of increasing especially in quan-tity or value”

“Parallel: 3 a: similar, analogous, or interdependent in tendency or development”

There is a product and a process perspective to “iteration” in system development:

if development is iterative, the product is reworked from a product perspective and the process used to create one rework of the product is redone for the next rework.

When working “incrementally”, the product is gradually extended to become more complete. In this sense, experimental system development is always iterative and most often incremental. The system of concern is iteratively developed through a series of activities and a number of increments of a prototype. Models of problem domains are part of this iterative and incremental process: as activities contribute to a more satisfactory understanding of the system to be developed and the context in which it is to be implemented, models need to be iteratively and incrementally refined in order to fit this understanding. And these processes are often carried out in parallel.

The Dragon and the COT Project provide examples of this on different scales:

3.2.3.1 Activities and Concerns in the Dragon Project: Iteration, Increments, and Parallelism in the Large

Figure 3.6 shows some of the activities of the Dragon Project schematically. Time is shown horizontally and each column on the vertical axis represents development between two reviews. Each box represents an increment and iteration on the func-tionality connected to a particular area of concern: The booking component, e.g., went through seven increments and iterations from paper sketch to a highly vertical prototype while being extended in functionality. The overlaps on the vertical axis show parallel work: the fourth increment and iteration on the booking functional-ity was, e.g., done in parallel with work on six other functional components in the same iteration. The first phase (left) was mostly incremental and the second phase was mostly iterative seen from a product perspective.

Customers

Figure 3.6: Activities in the Dragon Project

Each of the increments and iterations on a component involved input from ethnography and participatory design, and later an object-oriented implementation of a revised design was involved. Furthermore, evaluations in the form of work-shops, demonstrations, or formal use evaluations were performed in connection to each review. This means that modelling, as well, had to be done iteratively, in-crementally, and in parallel. As the knowledge of the part of the problem domain pertaining to each concern developed, new areas were modelled and old areas were revised. Reviews were used as synchronization points to keep development on track.

3.2.3.2 Modelling in COT: Iteration, Increments, and Parallelism in the Small The development group in the COT Project was small and homogeneous in contrast to the development group of the Dragon Project. Furthermore, development was done in short, intensive iterations with longer breaks in-between. Nevertheless, iteration, increments, and parallelism were prevalent in this project as well.

During an iteration, the work product of each day would be a small report comprising a model in a Computer-Aided Software Engineering (CASE) tool and (digital) “whiteboard snapshots” of the results of modelling sessions. Later, this would be complemented with a running system and a listing of the code of that system. Incrementally, these products would converge to the final prototype of the system. Moreover, during the course of a day, subgroups would work on different parts of the system: one subgroup would, e.g., implement a design from a model by inputting the contents of a whiteboard into a CASE tool and subsequently write code, while another subgroup would continue modelling by working on a new part of the problem domain or discussing refinements of a previously modelled part.

The work of both of these subgroups hadimplications for the complete model and had to be synchronized.

3.2.4 Heterogeneity

“Heterogeneous: consisting of dissimilar or diverse ingredients or con- http://www.m-w.com

stituents”

Models are represented in heterogeneous ways and sources of models are hetero-geneous: models may, e.g., be shown graphically in the form of UML diagrams on whiteboards, they may be embedded in code, or they may be communicated ver-bally as shared understanding between developers. Models may, e.g., be created using observations, interviews, work artefacts, or previous systems as sources.

3.2.4.1 Heterogeneous Material as Input to Modelling

In the Dragon Project, a diversity of sources to modelling were available: users co-located with the development team were available for discussions and for giv-ingverbal or graphical accountsof customer service work. Horizontal prototypes

designed with users showed a rich source of concepts and relationships that had to be covered by object-oriented models. Various types ofdocuments also pro-vided input: timetables, “bills of lading”, and schedules, e.g., propro-vided a basis for modelling the routing component of the system, and diagrams created during the previous BPI effort provided an initial source of concepts and scenarios to be covered by models. Previous systems were studied particularly in connection to current use to give input to an understanding of how work should — or should not

— be supported by the future system. Ethnographic analyses provided critical, systematic input from actual work.

The starting point of the COT project was an earlier system that the partic-ipating engineers had built. This system, in combination with its specifications, provided a functional “checklist” for modelling. The engineers and the object-orientation experts provided different input for validation and verification of the constructed models: simplistically, the engineers, with problem domain expertise, could validate whether the models covered problem domain areas in sufficient de-tail and precision, and the object-orientation experts could verify the semantic cor-rectness of the models with respect to object-oriented modelling practices in gen-eral and the UML in particular.

3.2.4.2 Heterogeneous Material as Output from Modelling

In both the COT Project and the Dragon Project, the prototypes were the single most important output from modelling. In-between this persistent executable em-bodiment and the informal and transient sketches drawn on whiteboards, a contin-uum of model representation was used.

Typically, CASE tools were used to draw with and to store models after these models had been drawn on whiteboards or paper or discussed verbally. Figure 3.2 shows an example from the Dragon Project of a UML model decorated with non-UML constructs (labels and drawings) that represent the semantic context to the model.

The model was tightly integrated with the code through the CASE tool used (Christensen and Sandvad, 1996), but simplified versions of the model were con-tinuously created for presentations and workshops. Other views created included abstracted relationships between objects in the system in the form of architectural diagrams.

The object-oriented model and the user interface had a dual relationship, par-ticularly in the Dragon Project: the user interface design was, as discussed above, used as input to modelling but modelling sessions also provided input to user inter-face design. In fact, a subsequent analysis showed a close correspondence between objects from the object-oriented solution domain model and graphical user inter-face widgets from the graphical user interinter-face (Damm et al., 1997).