Iterative Application Development

Material on this chapter is based predominantly on CAP-Gemini Sogeti’s manual on IAD. Any quotations or references that are derived from other materials are going to be referred to accordingly.

IAD has been dubbed the modern information systems methodology that is going to ensure the success of new projects and succeed where the traditional approaches failed.

Is iterative application development that new as the proponents of the IAD approach want us to believe?

In 1986, Janis Bubenko, [Bubenko, J., 1986], giving his perspective on methodologies wrote the following: "the general view of a systems development process as a "waterfall" with several stages (performed more or less iteratively) is still, after more than 20 years, the dominating development paradigm.

Today, 10 years after Bubenko’s observation, I found the following caption on the internet: "... many organisations still use traditional "waterfall" life cycle development methodologies which take a linear approach to systems development ..." [ Infoman, 1996].

Infoman, [Infoman, 1996], gives three reasons why traditional waterfall methodologies do not yield tangible results:

10 years ago, Bubenko, [Bubenko, J., 1986], gave the following assumptions about applications and information systems:

Applications were seen as having definite life cycles.

Revelation, [Revelation, 1996], discusses four primary forces shaping the business application development debate. The forces are said to be interrelated, but each has a decided impact on how a business automates its operations through its applications. These forces are:

1. the rapid evolution of technology
2. the changing nature of the business organisation
3. the emerging global enterprise and
4. the increasing importance and complexity of applications.

These four driving forces have converged in the 1990s to shift the focus of application development discussion from features to implementation. The dialogue no longer revolve around GUIs (Graphic User Interfaces) and gateways. The focus is now on applying these tools to improve developer and end-user productivity, increase business application reliability, reduce cost and shorten the time to market.

What is IAD?

This is a new development approach designed around an Iterative Application Development (IAD) life cycle, and makes the best of new development tools. It also provides a managerial approach to reuse, and comprises a set of training modules (aimed at management, sales and delivery staff). IAD is a method (by means of a life cycle ) which provides an approach to structuring a project. This approach provides an advised structure and a series of the most likely phases, tasks and activities required to create the intermidiate products expected from the development process (deliverables, prototypes etc.), and so to obtain the final product, [CAP - Gemini Sogeti, 1994].

IAD is described as not being a systematic and prescriptive method, but rather a creative process that involves a high degree of communication within an interactive environment. It therefore requires the commitment of both users and developers to operate within this contest.

The main objectives of IAD is to obtain better client satisfaction by :

The basic concepts of IAD are founded on the failures of the traditional development approaches. One could therefore say that IAD has surfaced as a response to the problems of the conventional approaches. IAD is said not to be revolutionary, but can perhaps be described as a synthesis of successful project principles and new technology applied in a suitable way to produce a faster and more relevant approach to the development of IT systems. IAD is based on two broad concepts:

IADs fundamental concepts are based on its management concepts which are also techniques for the management of an IAD project. These concepts and techniques, diagramatically shown in figure 3.2 are based on the following:

The iterative life cycle is based on a small number of phases that are executed in an iterative way. There are three main options available, the choice of option depends on criteria such as complexity or stability of the requirements or the need for the fast implementation of a core system, which is by definition incomplete. The three options are:

In each case, a pilot is delivered (and possibly implemented) at the end of each iteration, with an objective of meeting a jointly agreed subset of requirements. Experience acquired from previous pilots will influence the development of subsequent pilots.

In this strategy, all three phases are included within each iteration. This strategy reflects the main concept underlying an iterative development, which can be summarised as analyse a little, design a little, code test a little, implement a little, then repeat the process.

In this approach, all the requirements are fully specified from the start, and iteration is used to build and deliver the system incrementally, by focusing primarily on the requirements which will provide the client with the most immediate benefits.

The iteration in this approach is applied to the first two phases of the life cycle only. This means that the development process will benefit from the experience gained on the successive pilots, but nothing will be installed operationally within the organisation before the complete system is ready.

Joint Application Development as a concept of IAD is obviously deduced from the well known Joint Application Design (JAD) methodology. The question though is the difference in the choice of terms; design and development. Though the choice of term might be insignificant, I will look a bit more closely at these two terminologies in relation to the context they have been applied in the last chapter.

"Joint Application Design (JAD) is a methodology that accelerates the design of computer applications. Guided by a session leader, users and information systems professionals design systems together in structured group sessions. JAD harnesses the creativity and team work of social dynamics to define the user’s view of the system, from the system objectives and scope through screen and report design. JAD results in more usable systems, completed faster" [Judy August, 1991].

Joint Application Development as a concept is the technique where users and developers jointly reach consensus on requirements and specifications through workshops. Workshops lead to faster development cycle, realistic specifications, fewer milestone deliverables and less formal validation activities. Different types of workshops are used throughout the IAD life cycle, in order to encourage team-working and facilitate real-time decision making through:

It is important to have the most effective participants during workshops, it is also important to establish an effective environment supported by a repository.

A-Teams

An A-team comprises responsible and skilled developers with a high degree of synergy, who between them have the necessary portfolio of skills required to analyse, design, build and implement the system. Depending on the size of the project, there may be several A-teams working in parallel, each team having the communication skills to work very closely with the user team.

Time-Boxing

Time-boxing is the response to the need for fast system development whereby a delivery date may be chosen, and as much of the system built in that time as is possible using highly skilled A-teams. Time-boxing can also be applied within the development process, to complete specific parts of the system within a given time-frame. It is important that the users’ expectations are clearly set for each time-box. They must appreciate that the delivery of the system quickly and in stages means limited functionality in interim releases.

Technical concepts are based on the notion of optimising the utilisation of modern sophisticated systems development technologies. The technical concepts are also classified as the development techniques of IAD and are going to be treated as such in this sub-section and throughout the chapter for that matter.

The following are the technical concepts of IAD:

Prototyping

The term prototyping can be applied to any system which is rapidly developed and exposed to the user for interactive development based on the users experience of the system. The system is rigorously tested in the operational environment and refined by experience and use. The prototype is modified in light of experience and the revised system is released to the user for further use and to allow evaluation of the modifications [John Hopkinson, 1986]. In IAD, prototyping tools are used extensively to build different kinds of prototypes during workshops and development tasks.

Some of these prototypes might model the external behaviour of the system, as well as the internal architecture. The most comprehensive prototypes integrate the results of these other prototypes, and ultimately evolve into the release production system. Prototypes are classified as exploratory, evolutionary or operational.

An exploratory prototype is an experiment which exists solely to test the feasibility of doing something, the correctness of an assumption, or to explore one of a number of possibilities. It enables rapid validation of certain aspects of a pilot. Typically, such a prototype will be discarded once it has fulfilled its purpose. It will not be integrated into the pilot under development. An exploratory prototype may even be built using a different language or development system.

Contrastingly, an evolutionary prototype is a pre-release of the pilot being developed, meant to generate feedback during the development phase. It is an intermediate product which will integrate the results of any exploratory prototypes, and which will evolve into the pilot with only a limited amount of design and coding within each iteration.

Finally, an operational prototype is a very specific prototype which extends an already implemented pilot, in order to investigate new requirements related to a subsequent pilot. This activity will involve members of the development team at the end-user’s site. Figure 3.6 depicts the various prototypes and the resultant evolutionary pilot development.

The pilot strategy embedded into the IAD life cycle promotes the building of evolutionary prototypes (called pilots) which:

Architecture Design

In the past, architectures have been driven by major vendors, and clients had to choose the best from few options, which often constrained them to the use of proprietary systems. Today, multi-vendor solutions have multiplied the architecture options, and offer clients the opportunity to select a far more effective fit to their needs.

M. J. Earl, [Earl, 1989], sees information systems architecture as having a strategic role in systems development. He gives three interesting aspects of information systems architecture:

The IAD life cycle promotes an open structured system (and software) architecture as being the main basis for systems development. Such an architecture provides flexibility, which is a "must" in an evolving environment. This flexibility will be obtained through:

The architecture should be flexible enough to allow for any computing paradigm to be used, such as distributed systems or client/server applications (possibly integrating graphical user interfaces and object-orientation). These are examples where a poor architecture design can be an impediment to providing real benefit.

A well-defined architecture will also provide a base for reuse and maintenance, in cases where the ability to address or anticipate change is a necessary feature.

Graphical User Interfaces (GUI), are very common, but their design is still a relatively "unknown" activity. A clear textual specification of a complex dialogue is often difficult to make, and it is of very little use when communicating with users. Furthermore, the event-driven approach to building a GUI dialogue is very different from that applied when building traditional user interfaces.

Effective GUI design is not cosmetic, but real usability engineering, tightly connected with the architecture design of the system. By considering it in this way, it will provide:

Within the IAD life cycle, GUI design and prototyping tools are used during workshops to specify and validate user interaction.

Object Orientation

The IAD life cycle can be applied using object-oriented development techniques as an option. Object-orientation closely matches human concepts, by representing the structure, dynamics and semantics of the real world through high level abstract entities. It also facilitates the management of complexity and change, and encourages reuse.

The primary unit of an object-oriented system is the class, which represents the structure and behaviour common to a logical group of objects. Any object-oriented system can then be viewed as a collection of objects, fulfilling certain responsibilities through active collaboration with other objects, in order to achieve the desired functionality. The main objective of object-oriented structuring is to address the complexity of the system by organising classes of objects into inheritance hierarchies, so as to exploit their commonality while at the same time clearly separating their areas of responsibility.

Other object-oriented vital concepts are the following:

Encapsulation; the intimate association of an object’s data with the procedures that manipulate them (and the hiding of the underlying implementation).

Polymorphism; the ability of a procedure to accept arguments of different types and respond appropriately.

Message passing; the ability of an object to communicate with other objects (both sending and receiving requests).

Dynamic binding; the ability to leave the receiver of a message undetermined until execution time.

According to the advocates of IAD, the above principles make object-oriented techniques very suitable for iterative development, by simplifying problem decomposition, facilitating architecture design and finally improving productivity.

Reuse

Reuse is often considered as the key to productivity (by delivering systems with less effort and fewer errors, and by compressing testing), although there is universal agreement that it requires strong management. Any part of a solution should be re-usable, including expertise.

Biggerstaff and Perlis, [T. J. Biggerstaff and A. J. Perlis, 1989], define software reuse as the re-application of knowledge about one system to another similar system in order to reduce the effort of development and maintenance of that other system. This reused knowledge includes artefacts such as domain knowledge, development experience, design decisions, architectural structures, requirements, designs, code, documentation, and so forth.

In the short-term reuse can also improve:

Reuse requires a common culture, and the ability to build on the work of other people, this encourages team working, which is a vital aspect of IAD.

In summary, reuse is one way to tackle evermore complex and ambitious projects, by:

Phases of IAD

One of the main aims of IAD is to rapidly develop an application through multiple iterations of the following three phases:

Each main iteration will deliver a version of the system that is immediately usable in practice. Each version is called a Pilot, see Fig 3.11. Feedback on the implemented pilot is used as input to the next life cycle iteration. It will have an influence on the specification and development of subsequent pilots.

As a consequence, a complete iteration of the life cycle should be shorter. A turn-around time of 2 to 3 months is typical, even though the first pilot may require a longer period of time (up to 6 moths).

In this phase, the pilot (which is a step towards an evolving solution) is accepted and implemented in the organisation. If the pilot is ‘final’, in the sense that no more iterations are planned, it is referred to as the system. During the Pilot/System implementation phase, feedback is collected to serve as input to subsequent life cycle iterations. These phases and iterations are shown in figure 3.11.

The benefits of IAD are based on its basic principles, which means optimising resources and tools through the concepts of IAD. The main principles of IAD are summarised as follows:

According to advocates, IAD can be a very strong market discriminator by providing the following advantages:

By recognising the creative nature of IT without compromising proven project practices, and by supporting the demands of new technologies, IAD enables the understanding of many different IT opportunities and the response to them in a pragmatic and sensible way.

As with any new approach, great attention has to be paid to IAD implementation, so as not to jeopardise the whole approach. The main issues to the success of IAD are:

Each of these must be addressed taking into account the specific context of each project and the availability of resources.

 Back                                       Next