Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!pesnta!hplabs!hao!seismo!rochester!ritcv!cci632!ccird1!rb From: rb@ccird1.UUCP Newsgroups: net.lang.c Subject: Re: Analysis and DEsign Message-ID: <441@ccird1.UUCP> Date: Wed, 4-Jun-86 19:27:35 EDT Article-I.D.: ccird1.441 Posted: Wed Jun 4 19:27:35 1986 Date-Received: Sat, 7-Jun-86 08:22:50 EDT References: <993@brl-smoke.ARPA> Reply-To: rb@ccird1.UUCP (Rex Ballard) Organization: CCI Rochester Development, Rochester NY Lines: 82 Summary: Production In article <993@brl-smoke.ARPA> 3GTLJHW%CALSTATE.BITNET@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.