Analysis and DEsign

[rb at ccird1.UUCP]

In article <993 at brl-smoke.ARPA> 3GTLJHW%CALSTATE.BITNET at WISCVM.WISC.EDU (Joerg Hallbauer) writes:
>>All too often, one sees programmers writing detailed design specifications
>>before writing any code.

>  You have it exactly backwards!  Structured Systems Analysis and design
>are MOST efective when they are used on large projects that have a great
>deal of user interaction involved with them.  Sudies have shown conclusively
>that 40+% of the time bugeted for a project whould be spent in analysis and
>design with the rest divided between coding and testing (with documentation
>though really having been done as part of the analysis and design taking a
>couple of percent here too).
>
>                                        Joerg Hallbauer
>                                        Systems Analyst

One of the more interesting studies (probably the same ones Joerg used)
indicated that, in many techinical fields, 40% of the time (and 60%
of the budget) was spent planning what you were going to do, another
40% of the time (and 35% of the budget) was spent describing what you
had done, or trying to figure out what someone else did.  Which leaves 
20% of the time (and 5% of the budget) for actually producing the 
product.  Guess what, most of that is overtime!  The planners work
8-5 and plan over an hour lunch.  The production (coding) staff empties
the vending machines, and haven't seen the sun in two years :-).

In my own experience, I have ended up pouring over 500 page specs and
discovered that there were flaws, errors, and "critical windows" that
meant the design could not be implemented.  In addition, only top-level
DFDs and S-charts were provided and top-level tasks were assigned to
different people with no "bottom level unification effort".  The result,
20 different flavors of "convert structure A to structure B".

I've started using CAD-CAM techniques to get a complete design before
even beginning coding.  It's real useful for finding "loose wires".
This has actually REDUCED the overall developement time.

One of the "Open Issues" of the Yourdon system is whether it is better
to implement "Bottom Up" or "Top Down".  If the system is implemented
"Bottom Up", it forces the Analyst/Designer to consider the details
of the implementation, much the same way an Archetect must consider
the AWG of the wiring, the diameter and pressure of the plumbing,
and the spacing of the studs.

Another thing I find interesting is that the Systems Analyst usually
"hands the programmer the spec".  Upper management understands it,
the analyst understands it, but the programmer not only doesn't
understand it, but has no input into negotiations until the failure
reports start coming in.

OK, Now that I've NAPALMED the Systems Analyst, let's look at what
can be done.  The SA should work with the customer AND the programmer.
The programmer and the SA should be able to communicate in the same
language (DFD's, S-charts, or Pseudo Code).  The programmer should be
Implementing models at each stage beyond the top level diagram.  Monitoring,
in the form of debug, profiling, metering, etc. should be part of the design,
rather than "Ad-Hoc" tools that get "stripped to the front panal".  The same
is true with maintenence.  Think of this as the same as the archetect including
thermostats in each unit or room of a large hotel.  Would you want to stay
in a place where the temperature was 30F in the summer and 180F in the winter?

As to the "Programmer", he should be able to speak the common language
as well.  Actually, the programmer should be an engineer or designer.
The engineer should be an active participant in the process, but not
necessarily directly involved with the customer.  The designer should
be building the various parts and testing them as the design progresses.
If data structures must be transformed, or their members accessed, the
required code to do this should be done while the design is still in
formation, this way, if a structure requires 5 member accesses to determine
its length, information hiding members ("Packing" in OOD terms) can be added
before it is discovered that system response time is too slow.

Another important point is that, especially when the "New and Improved"
version is being designed, maintenence programmers who are able to separate
the principles from the implementation should be heavily consulted.  Often,
they are already aware of major flaws that have plagued the original design.

The bottom line is that production should be part of the design process, not
a middle step in well defined sequence of events.  Certainly not the current
"Squeeze it in before ship date" event that seems to be suggested by Joerg.

Disclaimer:  Opinions and observations do not reflect opinions or practices
of my employer.