Analysis and DEsign

[Joerg Hallbauer]

>All too often, one sees programmers writing detailed design specifications
>before writing any code.  This is probably because design specs make it
>appear that the problem is fully understood, and give the impression to
>management that the rest of the process of implementation will be entirely
>mechanical and hence will be on budget and on schedule.  Ho ho.  Then one
>gets to draw up a new budget and schedule for "maintenance", which is the
>process of modifying the program so that it really meets the customer's
>needs, instead of merely meeting the specification.

  Sorry, but *I* can't let that one go by.  The whole point is doing a
careful job of program/system design is so that you WILL understand the
problem fully.


>The alternative is to recognize that (a) the user probably does not have
>a complete and coherent idea of what he needs, and hence cannot write a
>spec or meaningfully assess one you write, and (b) in any case, the presence
>of the software itself will change the user's tasks and therefore his needs.

   You are absolutely right, few users have a meaningful or coherent idea
of what it is they want.  Again this is an good arguement for why you SHOULD
do a good job of systems analysis. One of the main tasks that a good analyst
does is to help the user make decisions!  He guides the user and in that
process gets a clear view of exactly what it is the user is trying to do and
what the user will expect as a result.  This is important not only so that
the system will meet the users need when it is delivered, but is also needed
in order for the system to be tested properly.  The presence of the software
only changes the user task's if this has not been discussed with the user.
Again a good analyst will expain to the user how the software will impact
his working enviroment, and together than can plan with this in mind.

>Given recognition of this situation, it is not even theoretically possible
>to avoid a trial-and-error process of software development.  Hence you
>should aim to make your inevitable mistakes as early as possible.  Which
>uts a heavy premium on getting initial prototype software into the hands
>of the customers right away, so that you can learn what's wrong with it.
>One progresses by iteratively enhancing (and perhaps sometimes re-doing)
>the prototype, with regular user feedback.

   That's the whole point to systems analysis.  Place the interative process
at the front of the systems life cycle, NOT at the end!  Currently maintenence
is the single largest cost in DP today.  One of the major reasons that so
much time is currently being spent "enhancing" existing software is that
when that software was written the people writing it did not have a good
understanding of that the user wanted.  Discovering what the users needs are
is not done in front of a computer terminal writting code, it's done TALKING
to the user!  Sure in order to full expain some things to the user you may
want to do some prototyping, but you certainly don't want to run out and
write the entire system and THEN ask the user what he/she thinks.


>This is not to say that the design-it-first method doesn't have its uses,
>and its advantages, when the problem is understood well enough.  But a very
>large class of problems -- almost anything to do with user interaction, for
>example -- simply don't meet that criterion.


  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
                                 Professional Services Division
                                    Control Data Corporation

                                     Technical Support Group
                                  California State Universities

                            BitNet: 3GTLJHW at CALSTATE
                           ArpaNet: 3GTLJHW%CALSTATE at WISCVM.EDU

                             Phone: (213) 852 - 5087


[ The usual disclaimers apply of course ]