Publisher Summary

This chapter discusses the need of a development process based on the inherent complexity of even small software products. The development of software products is an inherently complex task. The complexity manifests itself in the understanding of detailed customer requirements, and specific analysis, design, and programming techniques that are necessary to produce a high quality software product. A software product is approached with completely different viewpoints by its ultimate users and the software developers. The developers look at a software product regarding design and programming techniques, and how efficient the product can be in terms of execution time and the amount of storage required. Software products can be created by programming directly from loosely formulated requirements specifications. This is referred to as hacking and rarely results in high quality software that can form the basis for a product line with reusable components. Each phase of the development process of producing software includes a number of intermediate analysis and design products that ease the communication barrier between users and developers, and among various development teams working on different portions of a large system. The intermediate products include important analysis and design documentation that is used in design reviews.

1.1 WHY DO WE NEED A DEVELOPMENT PROCESS?

The code segment shown in Figure 1-1 is a portion of a final software product. But what does it represent, and where did it come from? The code segment is a C++ implementation of an abstraction of a “window” entity [DIL92], and can be used in various Microsoft Windows applications. It is highly unlikely that even the brightest programmer could create this code segment in isolation without the benefit of prior analysis and design. A sequence of development steps necessarily preceded the programming task for this code segment. This sequence represents a development process.

The development of software products is an inherently complex task. The complexity manifests itself in the understanding of detailed customer requirements, as well as specific analysis, design, and programming techniques that are necessary to produce a high quality software product.

A software product is approached with completely different viewpoints by its ultimate users and the software developers. The users are interested in desired features and how easy the product will be to use. The developers look at a software product with regard to design and programming techniques, and how efficient the product will be in terms of execution time and the amount of storage required.

Because of the limited capabilities of humans (even the most gifted!) to comprehend a large number of new and complex concepts, an immediate problem arises at the communication level between users and developers. Neither of these two groups fully understands the domain of the other, and some means of communication has to be created to bridge the gap of understanding.

Every software product is created to satisfy the needs of actual or perceived customers. These needs are specified in a system requirements document if a real customer is contracting to have the work done. This document represents the requirements for the new product. If a new software product line is being planned, there are a number of perceived customers who are the potential buyers of the product. In this case, the requirements may be less formally stated, but they exist nevertheless, and should be documented in a system requirements specification just as for a real customer.

Software products can be created by programming directly from loosely formulated requirements specifications. This is referred to as “hacking,” and rarely results in high quality software that can form the basis for a product line with reusable components. An extensive analysis of the system requirements and a subsequent design effort should be performed prior to the start of the actual programming effort. The analysis effort will ensure that the product we are about to create will satisfy our customers’ needs. The design effort will help in the construction of reusable software entities.

The discussion above implies that any software development effort should consist of at least three steps: analysis, design, and implementation. These three steps represent a development process. This does not imply that the steps are necessarily performed in a strict sequential order. For a large system, there are usually parallel activities happening simultaneously for several smaller portions of the system. The different development teams are dependent on the work produced by the other teams from other phases of the development.

We will note in later chapters that the three suggested steps of analysis, design, and implementation are not sufficient, and other steps that can improve the process will be added, in particular, a domain analysis step (see Chapter 2).

To summarize the discussion above, we need a development process to manage the inherent complexity of producing software. This process is repeatable (i.e., reusable!) and scales up to large projects. Some of the steps included for large systems may be omitted for small and medium systems.

Each phase of the process includes a number of intermediate analysis and design products that ease the communication barrier between users and developers, and between various development teams working on different portions of a large system. The intermediate products include important analysis and design documentation that is used in design reviews.

The steps in the process are also used in tracking the progress and achievement of intermediate goals for large projects.

1.2 WHY SWITCH TO OBJECT-ORIENTED TECHNIQUES?

It used to be that “modular” and “structured” design (we will lump this into “structured techniques” henceforth) and programming techniques were considered “good” and necessary for developing a high quality software product. Over the last few years, however, the term “object-oriented” is being associated with “good” software products, and is used profusely about anything remotely connected to software development. The structured techniques are becoming associated with old-fashioned and less quality-oriented approaches. Many software vendors are marketing their products with the object-oriented label attached, and methods and tools vendors are fiercely competing for our attention with CASE tools supporting specific object-oriented methods.

Many of the claims made for object-oriented products do not satisfy the paradigms and concepts defined in the later chapters. The old cliché of buyer beware still prevails: Even if a product sounds like “object-oriented,” it may very well not live up to these claims.

Why is it that so much attention has been focused on object-oriented techniques in the last few years? Are there definite advantages to using these new techniques over the older, well-proven structured approaches? Any time we move to new development techniques there are significant initial costs associated with training, acquisition and licensing of new development tools, and potential organizational changes. These costs must be offset by future benefits of using the new techniques and tools. We would also like to have some measure of the risks associated with the switch regarding potential higher costs and longer schedules.

Some of the benefits of using object-oriented techniques can be summarized as follows:

It should be understood at the outset that the...