'Growing' software - a metaphor for incremental software development

Software Magazine, April, 1990 by Glen G. Schmidt

"GROWING" SOFTWARE

Developers are the key to successful software. To succeed, they must continue striving for correct approaches, better tools and greater understanding of the software development task.

The most difficult task in arriving at a software solution is identifying a clear and precise specification. Understanding and specifying what is to be accomplished is critical to success. User requirements, data definitions and project scope contribute to the "what" of the task. That must be understood before the "how" is accomplished.

Good software developers have an inherent ability to grasp the "what," conceptualize the "how" and iterate until a successful solution evolves.

The basic concept of software processes--data structures algorithms = programs--has not changed. Yet, unlike computer hardware technology, there has been no order-of-magnitude improvement in software productivity, simplicity or reliability.

Software engineering is inherently complex. The steps involved--user requirements analysis, specification, designation, construction and quality control--are difficult by nature.

Frederick P. Brooks, Jr., Kenan professor of computer science at the University of North Carolina, Chapel Hill, and author of "No Silver Bullet" [Computer Magazine, April 1987], identified several properties of software systems that characterize this difficulty: complexity, conformity, changeability and invisibility.

Standards and integrated components abound in other engineering disciplines, primarily because the number of possible states are controllable. The software entity offers no such simplification. It is the possible states, driven by differing user requirements (data and processes), that contribute to inherent complexity.

As environments become more complex, so do the data definitions and process definitions. Consequently, the software controlling the data and processes increases in complexity.

Increased communication requirements heighten the chance for misunderstanding, which leads to defects in all phases of software evolution. These defects may be well-hidden because of the number of possible states the software entity offers.

Software conformity is imposed by the enterprise, department or user. It is often arbitrary and unreasonable. Conformity to these environmental requests are then confounded by having to interface to existing constraints, or possibly packaged, commercial software. Conformity to a variety of interfaces contributes significantly to software complexity.

Dealing with change is intrinsic to the software life cycle. The "final cut of the system," the "last bug," the "complete documentation," are myths. There are only current states of the evolutionary process. Some view software as infinitely malleable.

Yet, software is designed to be malleable only within certain identifiable parameters. To make software infinitely "customizable" would take infinite resources.

Successful software will meet the demands of our evolving industry--new input and output devices, user interface requirements, data element relationships and government-imposed policies.

Difficult to specify and even more difficult to grasp once specification is attempted (the maintenance problem), software has an essence of invisibility. Despite attempts to visualize the software entity--state diagrams, flow of control charts, data flow charts, entity relationships, dependency charts, span of control tables--it remains beyond vision because the charts and diagrams must be multidimensional to represent the software's behavior.

Case tools attempt to address inherent software difficulties by providing structured-specification methodologies, a repository for data and process definition, automatic code generation facilities, project management and prototyping facilities.

One of the fundamental components of a Case product is the repository. Allowing computers to maintain details of field definitions, field relationships, program definitions and other system-related details lets the developer concentrate on specification rather than construction.

The on-screen, structured design methodologies supported by Case products impart some rigor and discipline to the design phase. This can be a significant assistance but is often conceptually restrictive.

For example, a normal computer screen does not provide enough real estate for a sufficient number of visible components.

PROTOTYPING

Probably the most significant Case tool is the prototyping facility. The developer must have an opportunity to sit down with clients and discuss user requirements. Developers also need a facility to rapidly construct a reproduction of the user interface, and essential working functions so clients can see what they asked for. Most clients do not know what they want, or how to answer the ranging queries posed by the developer.

After seeing a prototype that meets the original specifications, clients will inevitably make changes. It is not hard to understand why this happens, because the developer is imposing new methods and strategies, changing work habits and interface patterns, and perhaps imposing a whole new environment on the client. Without seeing this new interface, the client is at a significant disadvantage to clearly specify what is needed.