3GTLJHW%CALSTATE.BITNET@WISCVM.WISC.EDU (Joerg Hallbauer) (05/19/86)
>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@CALSTATE ArpaNet: 3GTLJHW%CALSTATE@WISCVM.EDU Phone: (213) 852 - 5087 [ The usual disclaimers apply of course ]
rb@ccird1.UUCP (06/05/86)
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.
henry@utzoo.UUCP (Henry Spencer) (06/06/86)
> ...The whole point is doing a > careful job of program/system design is so that you WILL understand the > problem fully. How, when not even the user himself really knows what he will like best? > ... 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... And what the user *guesses* he will like in the way of a user interface. Finding out that he wants his tax calculations to follow a specific formula is one thing; finding out how he wants the result displayed is another. The former is readily possible, but not the latter. The imagination of the typical user is not up to the demands placed on it by this process. He really doesn't know whether he will like alternative A or B better, since he has no experience with either. It's notorious that even expert intuition is an unreliable guide in such matters. How much *less* reliable a guide is intuition by untrained customers! > ... The presence of the software only changes the user task's if this > has not been discussed with the user. This is simply wrong. I'm not talking about changes due to the software not fitting the user's routine, I'm talking about changes in how the user works that arise LATER because his tools have changed. Do you really believe that the nature of the tool doesn't influence how it is used? > 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. Note we are again back to guesswork as to how the user will react to the software. Educated guesswork, perhaps, but guesswork. > ... Discovering what the users needs are > is not done in front of a computer terminal writting code, it's done TALKING > to the user!... Wrong twice, it's done by observing what the user does, both before the advent of the first prototype software AND AFTER. The user himself often does not appreciate the implications of the way he does things... certainly not well enough to guess the implications of changes. > ... you certainly don't want to run out and > write the entire system and THEN ask the user what he/she thinks. Agreed that you don't just charge in with no idea what the customer wants. But in another sense, YOU WILL END UP GOING THROUGH THIS CYCLE REGARDLESS. The only question is whether the first version is explicitly an experimental prototype, or is claimed to be the "first production version". Better you should plan for this and try to arrange that it happens early. -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
franka@mmintl.UUCP (Frank Adams) (06/17/86)
In article <441@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >In my own experience, [...] 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". Personally, I believe in doing "top-down" and "bottom-up" design simultaneously. You design down from the algorithm, and up from the data structures; the results meet somewhere in the middle. A design which deals only with top-level tasks is inadequate (except possibly in the case where a single person implements the entire design). Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108