Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-adm!brl-smoke!smoke!3GTLJHW%CALSTATE.BITNET@WISCVM.WISC.EDU From: 3GTLJHW%CALSTATE.BITNET@WISCVM.WISC.EDU (Joerg Hallbauer) Newsgroups: net.lang.c Subject: Analysis and DEsign Message-ID: <993@brl-smoke.ARPA> Date: Mon, 19-May-86 13:51:03 EDT Article-I.D.: brl-smok.993 Posted: Mon May 19 13:51:03 1986 Date-Received: Sun, 25-May-86 11:50:14 EDT Sender: news@brl-smoke.ARPA Lines: 82 >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 ]