representative. He was available as a resource throughout the project and from December 1980 was working full time with Fenwick Software. He rapidly became conversant with structured analysis techniques, particularly the use of data flow diagrams, and provided continued input on analysis and design problems throughout the development process. He provided report and screen mock-ups, wrote the user manual, and did a substantial amount of program and system testing as well as the formal acceptance tests.
He provided liaison with the steering committee and with other users of the IMPAC system. All queries on how the system should operate were directed to him and were passed on to the appropriate person if he did not feel competent to answer them directly.
Another aspect of the user involvement with the system were visits by prospective users of IMPAC to Fenwick Software's offices before these personnel took up their new positions in Boyne Island. These included the warehouse supervisor, a casting foreman, and a metal co-ordinator. As well as trying out those parts of the system which had been built and providing useful feedback, they also gave the team an incentive to complete certain sections each time a visit was imminent. The third area of user involvement was the addition of a trainee programmer to the team for the last 12 months. We provided some training for this person (he had no experience in the language used) but mostly provided him with the opportunity to learn about the system "on the spot". He is now the maintenance programmer.
Depth of Analysis
Our official breakdown of the development was approximately one-third on each of analysis, design, and coding and testing (click here to see Figure 1 — pie chart). This bears out the claim that structured systems development leads to increased effort in the analysis and design phases, compared with traditional methods. With a new and unique problem to solve, this emphasis on getting the analysis right seemed most appropriate.
|
A major problem with software metrics is determining the changeover between activities. (Tom de Marco once suggested that analysis stops when the analysis budget is exhausted.) Even using structured techniques, analysis often continues during phases labelled design or coding. "Freezing" a specification has never seemed to produce optimal solutions. We had a continual flow of information from the users during the life of the project and this, together with our own increasing knowledge of the problem, meant that minor analysis changes were absorbed throughout the later development phases. On average, the detailed data flow graphs were redrawn once a month.
If this overlap is taken into account, our experience comes closer to figures collected in the U.S. where analysis takes up 60-70%, design 20% and coding and testing 10%.
A major contribution to the quality of the analysis was the commitment of top-level people from Comalco. This included paying for the entire team to visit a working smelter at Bell Bay, an experience which was vital to our understanding of the system.
Reliable, Dedicated Hardware
Another significant contribution to IMPAC meeting its deadlines was the fact that the chosen hardware was installed in Fenwick Software's office for the entire development period, and that the HP hardware and software was very reliable. In the life of the project, the machine had serious problems on only two occasions and the total downtime was 19.5 hours (less than 1%). The system software was also extremely reliable, especially considering the fact that IMPAC was using new versions of the COBOL compiler and V/3000, and that a new version of the operating system was installed in November 1981. The only blot on HP's record was that queries about the few software problems which were encountered tended to be ignored unless they were repeated. However, none of these was serious enough to delay development.
|
