Prototyping
This was a very successful experiment tried for the first time on this project. The original idea was to build a strategic program to test out high level design strategies such as screen and data base interfaces. It was also hoped that this program would give the users early visibility of the system. It was assumed that some of the code written would be used in the final system.
In fact, the strategic program fulfilled all these aims, but was completely discarded. The experience of writing this program showed that the strictly third normal formfile design was impractical (too slow) and also that the original page-mode screen design was inflexible, slow, not user friendly and produced a complex program. Completion of the prototype was timed to coincide with the visit of one of the Comalco personnel. The experience of watching a future user experiment with the prototype was extremely valuable. The revised file design and improved screen handling techniques resulting from this experiment have made a vast difference to the finished product. In short, this technique is highly recommended. The cost of the "throw-away" code is negligible compared with its benefits.
Another "prototype" which was discarded was unintentional, but still significant. From the first attempts at analysis, it was apparent that the production scheduling micro-system was a "grey" area. Considerable effort was expended to produce a high level and a detailed design, but when this was completed (including all process descriptions, screen layouts and structure charts), the result was considered to be unsatisfactory both from a functional point of view and from considerations of speed.
Eventually, the decision was made to go right back, involve the whole team, and completely re-do both the high level and detailed design. Two "brainstorm" sessions involving the whole team followed by detailed design by a team of two, produced a vastly superior solution. Again, this discarding of the original work involved a "loss" of at least four weeks, but the improved result was
|
ample compensation, and was coded in record time.
Structured Systems Development
According to Rob Thomsett's recent article in the Australian Computer Bulletin, June 1982, these techniques have a low level of implementation in Australia, and many companies claiming to use such techniques are not, or are only implementing part of the method. This is somewhat surprising, considering the widespread knowledge of their existence and their use by some very large and successful companies in the U.S. A brief resume of the methodology as we use it follows:
• Structured Analysis — The chief tool of structured analysis is the data flow diagram. This "model" of the system provides a good working tool for the analysis process, a product which is easily comprehended and verified by the users, a project control "deliverable" and the input to the next phase. The DFDs are accompanied by an overview for each level and short process descriptions for each bubble.
• Data Analysis — This is done in conjunction with the structured analysis and again produces a "model" of the data for review and is a "deliverable". We have found a combination of the data structure diagram and abbreviated data dictionary in one large diagram provides a better picture than the two individual documents. A documentedschema listing provides the complete data dictionary.
• Structured Design — During this phase, data flow diagrams are modified and process descriptions expanded. Processes are packaged and all the infrastructure of the system is designed: data base and screen interfaces, back-up and recovery procedures locking strategies, emergency operations. At this point, the design is handed over to the person who will eventually produce the code. Full structure charts, screen or report layouts and test plans are then produced for each module. Again, each of these outputs are project "deliverables".
|
