Life-Cycle Approaches
By Edward V. Berard
The Object Agency
PROLOGUE
Sometimes, to an outside observer, it appears that software is developed in a process that resembles "Brownian motion." Unfortunately, it is true that many software "engineering" efforts are little more than "organized chaos." This may be due to ignorance, poor management, lack of training, or any one of a number of other reasons.
A professional is someone who makes his or her task look easy. From a virtual infinity of choices, a professional seems to always choose the most appropriate next step in the process at hand. There is very little wasted motion. Even "trial and error" efforts appear to progress deliberately towards an effective resolution.
Unlike the "new thinkers" in George Orwell's 1984, professionals do not believe that "ignorance is strength." A professional knows that knowledge, methods, and discipline are not a "strait jacket," but instead amplify his or her creative capabilities.
Before we take a detailed look at object-oriented design or object-oriented requirements analysis, it might be a good idea to look at life-cycle approaches in general. If we understand how people have tackled software engineering projects in the past, we will be better able to discuss and understand the object-oriented life-cycle.
METHODOLOGIES AND LIFE-CYCLE APPROACHES ARE NOT ALWAYS NECESSARY
There are times when an ad hoc software creation/development process is justifiable. In fact, in some circumstances a (semi-)rigorous methodology may be worse than no methodology at all. The trick is to know when and where to consider using a methodology.
If your project is small, or non-critical, or both, a methodology may not be important. Let's look at "small" first.
A number of factors can effect the "size" of an effort. If we are only talking about less than 2,000 lines of code in just about any programming language, that may be considered small. However, if we get much above this limit, things change. In 1976, F. DeRemer and H. H. Kron published an article ([DeRemer and Kron, 1976]) which gave a name to an important concept: "programming in the large."
People had long suspected that a 100,000 lines of code project was not simply 10 times the effort of a 10,000 lines of code project. As it turns out the effort required to produce the larger project may be 50-75 times the effort required to produce the smaller project, _not_ merely 10 times the effort. (See, for example, the productivity studies in [Jones, 1986a] and [Jones, 1986b].) The factors which contribute to this massive, and "unexpected" increase in effort include:
- error density increases with overall size, i.e., the rate of errors per unit of code increases with the total amount of code written. As it turns out, this problem can be mitigated by reusing software, and, thus, reducing the total amount of new code that has to be written. [Yes, software resuability has a positive impact on reliability.]
- as the number of people assigned to a project grows, so do the number of communication paths. (The total number of communication paths is n*(n-1)/2, where n is the number of people involved in a project.) While communication is necessary, the more communication paths you have:
- typically the longer it takes to get anything done, and
- the greater is the chance that something will become corrupted in the communication process.
- the probability and frequency of the "ripple effect" increases with overall systems size. (The "ripple effect" is the introduction of new errors as a result of "fixing" old errors, or "enhancing" the product.)
Size can also be impacted by the choice of programming language. What may have been a good sized project in assembly language (Do people still use this stuff? ;-)), may be a small to medium project in Smalltalk.
Be forewarned, however, even "small" software can be critical software. Gerald Weinberg ([Weinberg, 1983]) documents an error that cost a company US $1,600,000,000, and was the result of changing a single character in a line of code. Remember "small" is not the same thing as "non-critical."
Software is being used increasingly in applications where reliability and safety are essential. Software is important, and software errors can have serious results (see, e.g., [Neuman, 1988]).
Other factors can make the use of a methodology ill-advised, including:
- poor, or non-existent training in the methodology
- the wrong methodology for the type of project, e.g., using classic structured technology on an object-oriented project
- lack of professional guidance - a poorly-defined methodology
- lack of management commitment to the use of the methodology
We can conclude with these observations:
1. The need for a methodology increases with both the size and critical nature of the software.
2. A given methodology must _decrease_ the overall complexity of the software engineering effort -- thus increasing the chances of a good quality product. Improper introduction of a methodology, or the use of an inappropriate methodology, can have a negative impact on a project.
GENERAL LIFE-CYCLE APPROACHES
There are three general life-cycle approaches:
- Sequential
- Iterative
- RecursiveIn a sequential approach, once one has completed a step, one never returns to that step, or to any step previous to that step. This is only practical with powerful tools (e.g., fourth generation languages) or on very small, non-critical projects.
In an iterative approach, if there is sufficient reason to do so, one may return to a previously completed step, introduce a change, and then propagate the effects of that change forward in the life-cycle. Most of the life-cycle approaches you are probably familiar with are iterative.
A recursive approach is one where the entire approach may be re-applied to the end products of the approach. All recursive life-cycle approaches are iterative, but not all iterative approaches are recursive.
SOME EXAMPLES OF LIFE-CYCLE APPROACHES
H.A. Kinslow in [Naur and Randell, 1969] (page 32), describes the "Flowchart Model":
1. Flowchart until you think you understand the problem ...
2. Write code until you realize that you don't ...
3. Go back and re-do the flowchart ...
4. Write some more code and iterate to what you _feel_ is the correct solution.
This approach is still in use today, except that people seldom draw flowcharts.
The "Sequential Waterfall" or "Stagewise Model" ([Benington, 1956] and [Boehm, 1986]) assumes that "everything is right the first time." Each step must be "signed off" and it is against the rules to go back or jump ahead.
The most common life-cycle approach today. at least in places where they attempt "formal" life-cycles, is the "Iterative Waterfall" or "Cascade" life-cycle. This approach requires that you complete and entire step, verify the results of the step, and then continue on to the next step. You may, however, at any time, return to some previously completed step, introduce a change, and then propagate the effects of that change.
The Waterfall life-cycle also usually implies that _all_ requirements analysis is completed before going on to design, and that _all_ design is completed before coding starts. In effect, once a phase is completed, the only time you return to it is _if_ you wish to introduce a change.
[The waterfall life-cycle came into existence because of the grossly disorganized attempts at software development that seemed all too common. You know the story: software is late, buggy, much too expensive, and ill-suited to the user's needs. Programmers would "get and idea of what the client wanted," and then proceed to write a bunch of code. Once the coding was done, the paperwork (e.g., design) was attempted -- but only until the next project started.]
Birrell and Ould ([Birrell and Ould, 1985], page 4) describe the "b-Model." The b-Model recognizes that the maintenance phase of the software life-cycle is seldom just fixing errors. If a software product exists for any period of time, "maintenance" almost always involves enhancements. After a while, the "maintenance phase" of a software product looks very much like the "development phase."
Barry Boehm has popularized the "Spiral" life-cycle ([Belz, 1986], [Boehm, 1986], [Boehm et al, 1984], [Boehm and Belz, 1986]). According to [Boehm, 1986], a "typical cycle of the spiral":
1. Begins with the identification of:
a. the objectives of the product
b. the alternative means of implementing this portion of the product
c. the constraints imposed on the application of the alternatives
2. The alternatives are evaluated. The evaluation may involve "prototyping, simulation, administering user questionaires, analytic modeling, or combination of these and other risk-resolution techniques."
3. The next step may involve "a minimal effort to specify the overall nature of the product, a plan for the next level of prototyping , and a development of a much more detailed prototype ..." The next step may, however, "follow the basic waterfall approach, modified as appropriate to incorporate incremental development."
4. Each cycle is completed by a review, with go/no-go plans made for the next cycle,
As the Spiral life-cycle progresses, the overall cost of the product is determined by the radius of the spiral, and the progress is determined by "angular displacement." The "spiral" moves outward from the center.
We can make two additional observations about the spiral life-cycle:
- The Spiral life-cycle presents an organized approach to prototyping.
- The Spiral approach is most useful in a _research_ project, i.e., a project where many options, requirements, and constraints are unknown at the beginning. If the effort is a _development_ effort, i.e., a project where the product, options, requirements, and constraints are fairly well-understood, then the Spiral life-cycle is not as appropriate as some other life-cycle approaches.
A SUGGESTION FOR THE OBJECT-ORIENTED LIFE-CYCLE: THE "RECURSIVE/PARALLEL MODEL"
The approach to object-oriented life-cycles which seems to have the most success is the "Recursive/Parallel Model." Grady Booch, and others, have described this approach as:
- Analyze a little
- Design a little
- Implement a little
- Test a little.
Instead of doing "all of the analysis," followed by "all of the design," the recursive/parallel model suggests that one does analysis where it is appropriate, design where it is appropriate, etc.
The recursive/parallel approach was not something which was derived theoretically. It evolved from real people attempting to apply object-oriented thinking to real projects. Anyone who has worked on a project of significant size knows that requirements are not all at the same level of abstraction. Some are broad and high-level, others are very detailed. This means that, once the entirety of the requirements are examined, some requirements may be deferred until a later time.
Likewise, some design, implementation, and testing concerns can be deferred until later. However, to make the recursive/parallel process work, several criteria have to be met:
- The entirety of the information available for a project must be examined to carefully determine which decisions can safely be left until later. Please note, that this is the recommended practice even for traditional life-cycle approaches.
- The interfaces of the system components (i.e., objects, classes, and systems of objects) must be well-defined, and kept fairly constant. (Remember: Walking on water and developing software from a specification are easy if both are frozen.)
- The components of the system must be losely coupled and highly cohesive. (Sound familiar? ;-))
- Verification and software quality assurance _must_ be part of the overall process.
There are quite a number of issues which must be addressed for the recursive/parallel life-cycle. For example, since this model gives management and the client so much more control over the software development process, how is that handled effectively?
One other observation I should make, and it will confirm a lot of suspicions, is that the differences between analysis and design in an object-oriented project, are far less than in a structured project. Said another way:
Structured methods:
Good News: Analysis and design use vastly different techniques, graphics, and evaluation criteria. It is fairly easy to tell when you are doing analysis, and when you are doing design.
Bad News: The gap between analysis and design is very wide. For example, although there are systematic ways to convert low-level data flow diagrams into structure charts (e.g., transform analysis and transaction analysis), few people seem comfortable with these techniques.
Object-Oriented methods:
Good News: The chasm between analysis and design is very narrow. Overall, object-oriented thinking is much more uniform than structured thinking.
Bad News: It is more difficult to separate "analysis concerns" from "design concerns." The thinking, tools, techniques, and guidelines have much more in common, than they have differences.
Although we will still have life-cycles, and as much rigor (including mathematics) as necessary, in object-oriented life-cycles, we will have to change the way we view the software life-cycle. The good news is that a lot of people have already given this a great deal of thought. Further, the ideas have been tried on a good number of projects, for a few years. (Let the "war stories" begin. 8-))
BIBLIOGRAPHY
[Belz, 1986]. F.C. Belz, "Appling the Spiral Model: Observations on Developing System Software in Ada," Proceedings of the 1986 Annual Conference on Ada Technology, Atlanta, Georgia, 1986, pp. 57 - 66.
[Benington, 1956]. H.D. Benington, "Production of Large Computer Programs," Proceedings of the ONR Symposium on Advanced Program Methods for Digital Computers, June 1956, pp. 15 - 27. Also available in Annals of the History of Computing, October 1983, pp. 350 - 361.
[Birrell and Ould, 1985]. N.D. Birrell and M.A. Ould, A Practical Handbook for Software Development, Cambridge University Press, Cambridge, United Kingdom, 1985.
[Boehm et al, 1984]. B.W. Boehm, T.L. Gray, and T. Seewaldt, "Prototyping Versus Specifying: A Multiproject Experiment," IEEE Transactions on Software Engineering, Vol. SE-10, No. 3, May 1984, pp. 290 - 302.
[Boehm, 1986]. B. W. Boehm, "A Spiral Model of Development and Enhancement," Software Engineering Notes, Vol. 11, No. 4, August, 1986.
[Boehm and Belz, 1988]. B.W. Boehm and F.C. Belz, "Applying Programming to the Spiral Model," Proceedings of the 4th International Software Process Workshop, May 1988, Special Issue of the ACM SIGSoft Software Engineering Notes, Vol. 14, No. 4, June 1989, pp. 46 - 56.
[DeRemer and Kron, 1976]. F. DeRemer and H. H. Kron, "Programming-in-the-Large versus Programming-in-the-Small," IEEE Transactions on Software Engineering, Vol. SE-2, No. 2, June 1976, pp. 80 - 86. Reprinted in [Freeman and Wasserman, 1983], pp. 321 - 327.
[Freeman and Wasserman, 1983]. P. Freeman and A. I. Wasserman, Editors, Tutorial on Software Design Techniques, Forth Edition, IEEE Catalog No. EHO205-5, IEEE Computer Society Press, Silver Spring, Maryland, 1983.
[Jones, 1986a]. C. Jones, Programming Productivity, McGraw-Hill, New York, New York, 1986.
[Jones, 1986b]. C. Jones, Editor, Tutorial Programming Productivity: Issues for The Eighties, Second Edition, IEEE Catalog No. EHO239-4, IEEE Computer Society Press, Washington, DC, 1986.
[Mills, 1971]. H.D. Mills, "Top-Down Programming in Large Systems," in Debugging Techniques in Large Systems, R. Ruskin, Editor, Prentice-Hall, Englewood Cliffs, New Jersey, 1971, pp. 41 - 55.
[Naur and Randell, 1969]. P. Naur and B. Randell, Editors, Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, Garmisch, Germany, October 7-11, 1968.
[Neuman, 1988]. P. G. Neuman, "Letter from the Editor: Are Risks in Computer Systems Different from Those in Other Technologies," Software Engineering Notes, Vol. 13, No. 2, April 1988, pp. 2 - 4.
[Royce, 1970]. W.W. Royce, "Managing the Development of Large Software Systems: Concepts and Techniques," Proceedings of WESCON, August 1970.
[Weinberg, 1983]. G. M. Weinberg, "Kill That Code," Infosystems, August 1983, p. 49.
Used by Permission.