Software development is no longer an enterprise where the traditional waterfall method of system construction is acceptable. Information technology is changing at a pace that requires complete system development and fielding in less than 18 months. This is due in part to faster technology insertion, and in part by increased user expectations. Both reasons provide justification for changing the way software is built and fielded. Increased user expectations require that we involve the user more in the requirements engineering process, and deliver the software to the user much more quickly. Faster technology insertion requires that we incorporate new technology into existing products much faster and with less rework.
A new software evolution paradigm is needed to accomplish these goals, along with the automated tools to realize the benefits. Computer-Aided Prototyping is one such method that incorporates the goals and opinions of the user from the beginning of the software evolution process, throughout the lifecycle, and into retirement. Automated tools, like the Computer-Aided Prototyping System (CAPS)[1], assist the software developer in building executable prototypes of a software system very quickly, involving the user in an iterative build-execute-modify loop until the user is satisfied with the demonstration of the prototype. The prototype is then used to build the final version of the software through the use of the architecture included in the prototype, as well as the validated set of requirements constructed during the prototyping process. The resulting final version is delivered relatively quickly, hopefully before the user's requirements have an opportunity to change.
This is often not sufficient to satisfy some users. If the demonstration of a prototype to a customer results in the validation of the requirements for that system, the user may want to take the prototype as is. Since most prototypes are not industrial strength, this may not be possible. The need outlined here is for a system, like CAPS, that will result in a version of the system that can be delivered to the customer immediately upon validation. The system could be used as it is until it no longer satisfies the user's requirements. When the user's requirements do change, new requirements can be incorporated into a next version of the system by using the same iterative process where the fielded version of the system provides the base version of the process. This incremental evolution process can proceed throughout the life of the system.
Professors Luqi and Berzins of the Naval Postgraduate School , along with a myriad of graduate students and visiting researchers, have spent many years developing CAPS [1]. Their efforts have resulted in a system that can be used to build executable prototypes of embedded real-time systems. These prototypes are useful for validating requirements through demonstrations to customers, but are not practical for providing the kind of deliverable version of a software system discussed in this article.
CAPS relies on external support for building graphical user interfaces, and manual translation of requirements into prototypes. This manual translation is problematic. The possibility of misinterpretation by the designer could lead to wasted effort in the prototype building process. Prototypes generated using CAPS generally lack robustness and portability. It is easy to build prototypes that do precisely as expected as long as the proper inputs are made, and use follows the designer's expectations. If improper inputs are made, and the designer has not built sufficient error handling into the prototype, it is possible that execution can halt unexpectedly. Robustness can be built into CAPS prototypes, but automated methods for testing these qualities are not included. Manual methods are possible, but would severely increase development time.
Portability is a different matter. Current versions of CAPS run on SunOS and Solaris, but most software in use by the military runs on PCs. This means that prototypes built using CAPS could be demonstrated to the customer on UNIX machines, but would have to be translated into something that would run on PCs. Although this is not a severe limitation, it does make it difficult to deliver the prototype to the customer immediately upon validation.
Current software development methods and tools are insufficient to produce usable code in a reasonable amount of time. Rapid prototyping methods approach the needed capability, but are not yet up to the task. An incremental software development methodology, modelled after the rapid prototyping paradigm used in a system like CAPS, is needed to reduce development time and put something usable in the hands of the customer quickly.
About the AuthorMajor David A. Dampier is a professor at the National Defense University in the Information Resources Management College. Major David A. Dampier Ph.D.National Defense University Building 62, 300 5th Avenue Fort Lesley J. McNair, Washington, D.C. 20319 |
www.ndu.edu/
|
1. Luqi and Ketabchi, M., "A Computer-Aided Prototyping System" IEEE Software, March 1988.