Incremental Design

Incremental Design

·        Black box to white box

·        Prototyping in stages

·        An example – DSDM

In a book such as this, where software design activities form the principal object of study, it is easy to develop a rather compartmentalized view of design activities and of the context within which they are performed.

This chapter considers how design activities are organized within a more dynamic context, where they need to be interleaved with other developmental tasks, and where they may be constrained by having only limited time available for completion. In such a context, the control of design activities becomes of paramount importance. Indeed, when we examine an example of a design method that supports this style of development, we find that its main elements are those concerned with the organization of the processes involved. Incremental design

Black box to white box in stages:

In some ways, this chapter can be considered as representing something of an ‗aside‘ when it is viewed from the context of the design practices that form the dominant theme of the preceding and following chapters. Yet it deals with an important issue and, indeed, highlights some of the underlying assumptions adopted in many of our approaches to the task of designing software. The title of this section (which, as we will demonstrate, is probably not very accurate) emphasizes the key tenet of incremental development through the term ‗in stages‘.

Implicit in almost all procedural approaches to software design is the idea that we begin with some form of ‗requirements specification‘ that is agreed with the customer and which then forms the basis for developing a black box model, and eventually from this a white box model that conforms to that specification.

In practice, it is widely recognized that this is a rather unrealistic situation, although it is one that is often necessitated by contractual or other factors. There are situations where a very comprehensive and inclusive requirements specification can be provided at the start of development, but these are relatively uncommon. In addition, over the period needed for the development of any sizeable software system, the requirements may evolve or even change dramatically, for both technical and organizational reasons. So, the development of any design solution is very likely to involve some degree of interaction with the customer throughout the design process. The difference this then highlights is between conventional procedural design approaches, which try to minimize the perturbations that this creates for the design solution, and incremental approaches, which seek to incorporate this interaction as a fully-fledged element of the design process and so control and manage its effects. Incremental development is often termed Rapid Application Development, or

RAD, and the approaches used for RAD are sometimes termed Agile Methods, with the development practices of Extreme Programming, or XP, representing the ‗outer limits‘ of such approaches

(Boehm, 2002). In terms of the philosophy that underpins Agile Methods, Boehm suggests that they favour:

·        individuals and interactions over processes and tools;

·          working software over comprehensive documentation;

·        customer collaboration over contract negotiation;

·          responding to change over following a plan.

Of course, taken to the extreme, both Agile Methods and procedural development practices can be abused and misused. The agile approach can degenerate into unstructured ‗hacking‘ of code, while the procedural approach can become bureaucratic and document-bound. However, an awareness of the strengths and limitations of both

forms should be a part of any software developer‘s knowledge-set, along with an appreciation of how they are best (and least-suitably) deployed. In Chapter 3 we identified some reasons why an incremental development process might be adopted, which included situations where:

·          there may be a need to demonstrate that an idea is feasible;

·        it may be necessary or even essential, for business purposes, to establish a market position as rapidly as possible;

·          the ‗customer‘ may wish to establish whether a market exists for a product before committing

to large-scale investment.

Underlying all of these is the concept of risk, whether it be a risk that a given solution is not feasible; one of missing out on a market opportunity; or that no real market may actually exist.

Risk is also an important element in Boehm‘s spiral model processes effectively assume a lifecycle model of this form, rather than the more linear ‗waterfall‘ forms that tend to be implicitly embodied in procedural design methods. The adoption of an incremental development process is therefore likely to be favored in those situations where an organization needs to maintain its position in volatile and rapidly-changing markets, and where minimizing time-to-market is a particularly important constraint. (This applies whether the software is itself being marketed or whether, as is more likely, it is being used to market an organization‘s services or products.) Such organizations are sometimes characterized as being emergent in nature. An emergent organization can be defined as one that is ‗in a state of continual

1. To develop the ‗black box‘ model for the system, in a situation where the purpose of the eventual system may need to be explored with the customer. (This is less likely to be a situation where the customer doesn‘t know what they want, than one where they don‘t know what is really feasible, especially if there are severe time constraints on implementation.) Such a role corresponds roughly to the idea of exploratory prototyping that was

‗enhancing the information that is provided from the requirements analysis and functional specification activities‘, with the distinction that here we are to some extent undertaking the second of these tasks.

2. To develop a working solution (white box) within a set of resource constraints. Time is probably the most likely form of resource constraint although, where new developments are concerned, an organization may be unwilling to invest heavily in terms of staff effort until convinced of the likely benefits. Here, the key need may

well be to deliver a solution on time, even with some elements of functionality missing or curtailed.

For the rest of this chapter we are largely concerned with the second of these roles for incremental development, since this is more in keeping with our emphasis upon studying design activities. It is also more in keeping with the notion of the emergent organization, where there is no real likelihood or expectation of ever creating a ‗final‘ system, since such organizations are characterized by a ‗continuous redevelopment perspective‘ incremental design approach is not closely tied to any particular design strategy or architectural style. This is not to say that architectural style is not important. Achieving the goal of ‗continuous change‘ requires an overall framework which enables extensive use of ‗plug-and-play‘ extensions to a system. Indeed, an important technical factor is to recognize that a system is being designed for change, and to facilitate this as far as possible. Maintaining the ‗separation of concerns‘ needed for plug-and-play is more a matter of attention to detailed design, rather than one that is affected by the choice of a specific architectural style. Where the use of an incremental approach to design does affect the act of designing is in the way that the design process needs to be organized in order to provide the degree of control necessary to meet the constraints. when deciding whether to adopt such an approach. Incremental design is an approach that is less commonly encountered in conventional forms of engineering design. As a technique it is unlikely to find much favor with civil engineers

(‗after we have built the central span of the bridge, we‘ll work out how to construct the approaches‘), any more than with their chemical or electrical counterparts. This is not to argue that it is not a valid engineering approach, given adequate planning and control, but rather that it is an approach which only makes sense when used with a medium such as software, and within the type of dynamically changing context often met in software-based business use and in the emergent organizations that such software makes possible.

One issue that can easily become blurred where incremental development is employed is the distinction between design and implementation.