Software Design 2e - DIM

nnnthere may be a need to demonstrate that an idea is feasible;it may be necessary or even essential, for business purposes, to establish a marketposition as rapidly as possible;the ‘customer’ may wish to establish whether a market exists for a product beforecommitting to large-scale investment.Underlying all of these is the concept of risk, whether it be a risk that a given solutionis not feasible; one of missing out on a market opportunity; or that no real market mayactually exist. Risk is also an important element in Boehm’s spiral model (Boehm,1988) that was shown in Figure 3.2, and in which risk evaluation forms a key activitywhich needs to be performed at each step of development. Incremental developmentprocesses 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 befavoured in those situations where an organization needs to maintain its positionin volatile and rapidly-changing markets, and where minimizing time-to-market is aparticularly important constraint. (This applies whether the software is itself beingmarketed or whether, as is more likely, it is being used to market an organization’s servicesor products.) Such organizations are sometimes characterized as being emergentin nature. An emergent organization can be defined as one that is ‘in a state of continualprocess change, never arriving, always in transition’ (Truex et al., 1999), andhence is one where continual change is regarded as being a ‘normal’ state of the businesscontext. While the internet-centred ‘dot com’ organizations are often seen asbeing of this form and, indeed, many may be so, a more extensive domain of this formis probably that of those organizations dealing in financial markets of any type, wherenew services may need to be introduced rapidly in order to meet legislative or otherchanges. If the organization is continually re-shaping itself to meet new businessopportunities, then any software used to support the business will need to evolve inparallel with the business itself.From the designer’s point of view, we can identify two major technical reasonswhy an incremental design approach might be adopted.243Black box to white box in stages1. To develop the ‘black box’ model for the system, in a situation where the purposeof the eventual system may need to be explored with the customer. (This is lesslikely to be a situation where the customer doesn’t know what they want, than onewhere they don’t know what is really feasible, especially if there are severe timeconstraints on implementation.) Such a role corresponds roughly to the idea ofexploratory prototyping that was discussed in Section 3.3, where this was describedas ‘enhancing the information that is provided from the requirements analysis andfunctional specification activities’, with the distinction that here we are to someextent 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 newdevelopments are concerned, an organization may be unwilling to invest heavily interms of staff effort until convinced of the likely benefits. Here, the key need may