CS 446 Notes 6 for 16 Oct 1995

CS 446 Fall Quarter Notes 6 Gio Wiederhold
Experimental Seminar on Large Scale Software Construction.

Ron Burback.
Creative Chaos combines the Watefall model and the Spiral model.
The waterfall model is broken into three phases:
A: Requirements Specification,
D: Architecture, Design,
I: Implementation, Code.
Installation and maintenance are ignored.
Problems with Waterfall is Discontinuity of clean-hands requirements between specifiers (say: accountants), designers (system analysts), implementers (programmers).
as well as the long delay before a user gets to see things, and often the world has changed by that time. Claivoyance is hard. Good specs as Hoyle for card games are rare.
The spiral model: {think a little, design a little (if at all), implemnt a liitle, loop} may not converge
Using the Chaos model some overlap is planned for the three stages. As in other models there is a need to freeze changes beteen phases: change order control.
1. A-> D-> I: In the specification phase design of crucial tasks is performed as well, to provide rapid feedback. Code for algorithms that are uncertian and risky is written as well. Any code generated then coould be thrown away.
2. D -> I: In the design phase any specification changes are accepted rarely, and only after thorough analysis. Since critical design steps have been developed earlier, there shold be no need to change specifications because of design problems.
3. I: In the coding phase design and specification changes are constrained. Again, since crucial code has been prototyped, no changes should emanate here that change design or specifications.

Some large SW has been written that way, and has been faultless. One of the SW samples mentioned did have the characteristic that it was fully specifiable -- the SW for the Manna and Waldinger theory book. An other example is the physician notes module for a hospital system, first tested in a hospice.

Without following this approach programmers tend to write the easy code first, making apparently rapid progress, but saving all the problems for the end. And those problems often lead to design or specification changes. No tools exist now to support this process, its execution depends on intensive and personal management.

How is the insight obtained that identifies design problems and code problems early? A small (<7+-2?), well-led group can probably identify most problems to be expected early on, by talking through the design in the specification phase. Managing such productive groups is very hard work, and few people want to do it for more than say 5 or 10 years. Both Ron and, 20 years earlier, Gio have given up somewhat on that tack, even though they were successful at it. Lttle recognition ensues from successful SW management. By moving into teaching one can spread the work, but without a formalizble background it is hard to disseminate the results of the experience.

Testing should be done by the implementors, and is helped by the
linkage from I -> D -> A. Testing by independent testers seems to have beneifits, but have not worked well. The A's become testers in phase 2 and 3, and the D's in phase 3? (the full IDA employment act) In phase 3 the I's also participate, for internal testig.

What is an architect? Users are not good at designing.

Collecting logs (screen independent for testing is useful, can be repalyed, and multiplied. An alternative is to design a virus for stress testing.

Teams should not be larger than 6? What if 6 people cannot have enough knowledge?.

MacCarthy's levels of knowledge reflect what's needed in documentation.
1. True facts
2. False facts
3. Knowing what you know.
Some of these principles are grounded in traditional science (aristotle, next there needs to be new paradigm.