Rapid application development

In large companies, we need to move faster and faster to provide users with the tools they vitally need. Similarly, it is no longer conceivable to put into production an application developed "between IT specialists": the risks of users simply rejecting the application produced are too great. We need to find a way of developing applications using a methodology that meets these crucial needs for the company: we need to move fast (a market is won more easily when the company is present in it quickly and efficiently); we need to produce software that corresponds exactly to users' needs; and we need to guarantee a high level of responsiveness to changes in competitive markets.

It's essential to rethink the methods used to produce the company's software. The "old" methods, too linear and often "badly" applied, which lead to the production of voluminous, redundant, never up-to-date documentation that "nobody really reads" anyway, don't meet these new needs. So it's tempting to look for new solutions. As is often the case, these are born on the other side of the Atlantic. Rapid Application Development (RAD) is one possible answer. Invented by the American James Martin, this method offers significant advantages:

• the strong involvement of future users of the application ensures that the needs expressed are matched by the software produced;

• the economic logic it implies prohibits the development of "useless" functions;

• the judicious use of available IT tools leads to the production of the necessary and sufficient documentation;

• strict adherence to budgets and deadlines enables an effective strategic vision.

The fundamental principle of RAD is as follows: right from the start of the project, a time/money envelope must be set within which the project must fit. As the project is built entirely with the users, it is up to them, with the help of a RAD facilitator, to ensure that the project fits within the defined budget. All phases of the project are covered by RAD and carried out with the system's future users: from the database design phase to the fine-tuning of the screens and reports produced, through successive iterations of prototyping. The result is the obligation to develop only "useful" functionalities, eliminating special developments that do not meet with general approval. Users often request multiple versions of a report (whether printable or screen-readable): in a RAD project, the aim is to produce a single report, bringing together all the information and winning the approval of all project participants.

ARD is not suitable for projects with a heavy forecasted workload (more than...