CS 446  Fall Quarter 1995-1996  Notes 9  Gio Wiederhold

Experimental Seminar on Large Scale Software Construction.

Ron Burback.

Creative Chaos combins 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.

-----------------------------------------------------------------------------------
Notes for Monday, Nov. 7th.

Visual programming:
Visual programming is an approach where objects are put together by maipulating them on a screen.  
Positive examples: Visual basic in Microsoft. The NASA space flight dynamics library. Database transaction models. Others?

What are the prerequisites for this approach to work?
Syntax has to match.  
Can it be done for mutiple programming languages?
Data formats have to match.
Can it work for complex structures? More than piped characterstrings or 
database relations?
Procedure invocations have to match.
Will objectified methods be adequate?  Can all the code be placed in objects?
Semantics have to match.
Can programming semantics be captured?
Will documented ontologies help: lists of terms, with definitions, annotations by the author and others (?), placed into networks (often hierarchies) with relationships that denote the intended meaning.
What is the tradeoff between richness of meaning and manipulability, specifically algebraic manipulatability?  Penguin example.
---------------------- o -------------------------------- o ------------------------