Modern RAD
By The Butler Group
Application development methods, like client/server itself, are evolving. The failings of spaghetti code based on fag packet design became evident long ago. Initial attempts to bring the design rigour of engineering to software took the form of a waterfall approach. Discrete stages were performed sequentially, with each ideally signed off as agreed and complete before the next began. However, it became increasingly apparent that such a method placed too many constraints on the development lifecycle and did not suit concurrent working.
Over the last five years, we have witnessed the emergence of RAD (Rapid Application Development). Early RAD offered a two dimensional cyclic approach; it involved developing a prototype (a dynamic model), getting feedback from users, changing the prototype, and repeating the process until users were satisfied. This approach has turned out to have limitations of its own. Butler Group believes that organisations are now ready for the next generation of RAD. Modern RAD uses what could be called a three dimensional approach. In addition to the iterative prototyping lifecycle, all the underlying infrastructure issues essential for the RAD process to work efficiently and effectively are addressed by guidelines. This amounts to an approach which is comprehensive in its scope but, at the same time, inherently flexible.
Waterfall (1st Generation)
The first generation approach is one dimensional, in that it represents a strict linear progression with milestones along the way.
Discrete teams of specialists are involved at each stage of the process. A team of analysts produces a specification, a design team then engineers the system, a team of programmers builds it, and specialist testing and implementation teams may complete the process. Teams with discrete skills and individual areas of expertise working consecutively conforms to the paradigm of the pre-BPR organisation. No single person is responsible for a complete process but is merely a link in the chain of procedures. One set of experts must complete a process before the next can take over.
Waterfall teams have the following characteristics:
Teams are managed by task
Individual reward is sought
Individuals compete
Work is to an agreed specification
Developers are technically focused
Problems are addressed by the allocation of blame
Work is isolated from the users
The specification includes doubtful function
Developers react to emergencies
Quality is improved by spending money
Quality is measured against specification.
Iterative Prototyping (2nd Generation)
Instead of starting from a functional specification document, best of breed modelling techniques can be used to set the scope of the problem domain at a very high (logical) level. The resulting business study is an unambiguous statement of the application’s business objectives.
The physical specification is achieved by developing a dynamic model of the application. Developers and users work together to produce a functional prototype which models the look and feel of the application.
Prototypes are reviewed by project teams consisting of developers and end users. The functional prototypes are refined by continuous review until the look and feel is exactly what the end users require, and are then used to model the business processes. This iterative refinement is then called the design prototype, where the business rules are investigated, refined and consolidated. It is important to note that with RAD many different types of activity are taking place concurrently.
The cyclic process comprises quadrants for identifying, agreeing, creating and reviewing the prototype. Each iteration will move the prototype from investigation through refinement on to consolidation.
As part of the RAD process, early implementation of key functionality is encouraged.
Modern RAD (3rd Generation)
The RAD iterative prototyping lifecycle is fundamentally people-oriented and as such requires skilled management of concurrent activities and good interpersonal skills on the part of both the end users and IT developers involved. It should not be assumed that ‘users’ will inevitably be business-focused and have a well-articulated understanding of their role, whilst IT people are bound to be over-technical.
The more dynamic and intense a prototyping cycle, the more essential to its success the underlying issues. These include: Project Management; Project Team Structure; Change Control; Configuration Control; Testing, Quality; and Software Procurement.
Effective project management is essential for the RAD process to work. Modern RAD recognises that traditional waterfall project management skills are not sufficient to fully equip the RAD project manager. Management of RAD teams is by motivation towards achieving the optimum business solution.
RAD developers must accept that all changes are reversible, and backtracking is an accepted practice. That’s why configuration control is an essential component of any application development tool used in a true RAD environment. Whenever a change is reversed, the previous version of choice must be easily accessed and (re)implemented. Change control is an essential discipline in RAD.
User-involvement throughout the complete project lifecycle has become commonplace. This involvement must be constant and consistent. In other words, it is important that the right level of input is provided by the right people and, as far as possible, the same people from the start to the finish of the project. This doesn’t mean that users have to be seconded full time. However, it is desirable for IT and user team members be in the same location. This is likely to be the users’ normal workplace in order that disruption to the business is minimised.
Development teams comprising of IT staff and users must be empowered to make decisions about functionality. The focus is on delivering the optimum business solution. Decisions and trade-offs have to be made between new functionality elicited through the iterative prototyping process and less important original functionality which may have to be excluded because of time constraints. Iterative development within a time window (‘timeboxing’) is a very powerful way of developing the minimum acceptable best fit business solution rapidly.
The focus on business functionality may be to the detriment of the system’s engineering, which takes second place. It is important to build the right system first before it is engineered (optimised) for performance.
RAD testing is not a separate activity as in the waterfall approach. Testing is integrated, incremental and undertaken by developers and end users alike. A successful RAD test is one which elicits information about, or a better understanding of, the business domain.
Because of timeboxing and the fact that the RAD philosophy requires a high degree of business focus, estimates, based on logical business functions, should be tight. If a deadline is protracted, the development team is at risk of losing business focus and concentrating on less important technical issues. The risk of a RAD project failing is, therefore, measured against its ability to deliver business benefit rather than its technical architecture.
Modern RAD teams have the following characteristics:
Teams are managed by business objectives
The focus is on team contribution
Individuals co-operate
The task is to deliver the best business solution
The focus is on solutions
Work is alongside users
Doubtful business function is excluded
Developers take steps to prevent emergencies
Money is saved by improving quality
Quality is measured against business benefit.
So, if you intend to use RAD and are also choosing your client/server development environment, it is essential that you take heed of all of the above infrastructure requirements. Whether you opt for a single vendor or best-of-breed tools, you must be able to accommodate frantic concurrent development in a controlled environment. Tools should be self-documenting and have built in configuration control. All application metadata should be held within a repository supporting secure, multi-user access. Modern RAD won’t succeed without the right supporting technology; with it, the rapid development of software which meets business needs is achievable.
Copyright © 1997 The Butler Group
Used by Permission.