- Email: [email protected]
Engineer to Software Engineer - A Practical Retraining Approach
Copyright (Cl IFAC T raining for Tomorrow Leiden , The Netherlands, 1983
ENGINEER TO SOFTWARE ENGINEER A PRACTICAL RETRAINING APPROACH M. J. Wells Faculty of Techno logy, Chelmer-Essex Institute, Chelmsford, Essex, UK
Abstract_ The increas i ng availability of in - house mini - computer power encouraged a local manufacturing company to consider the use of such equipment to aid their engineering processes, retaining the link to the remote parent company's computer installation for its data processing requirements. The introduction of such equipment immediately provided a resource which if managed carefully could result in some very va l uable software be i ng produced for the company , but if mi smanaged could produce many virtua l ly useless, very labour intensive , one- off programs which were on l y of benefit to the programmer . Since none of the engineers had been trained in software it was decided to undertake a rigorous train ing programme in conjunction with Chelmer- Essex Institute. This paper describes the case study outlined above p l ac i ng emphasis on the training design process and the general strategies and models used to effect this training programme _ Keywords_ Computer software ; ing languages ; training.
teaching ;
software engineering;
FUNCTIQ'\JAL SPECIFICATION V$ TEM
SYSTEM
REF M:OUL£ REF
lCENTlFlER tvODULE IDENTIFIER
SI-IEET
OCSlGNER
'NPUTs/OJTF\JTS
ICENTIFlER
REF
I!\fUT
OJ TF\iT
FHCM
TO
TYPE
DE SCRIPl"I(:N
I
Fig.1
Sample documentation sheet
263
CF
programm-
264
M.J. Wells INTRODUCTION
A local company faced with the increasing availability of in-house mini-computer power decided to arrange a training programme for its graduate engineers, in conjunction with Chelmer-Essex Institute. The programme was intended to enable the engineers to develop software to be used as aids to their engineering work. The far-sighted computer manager of this company, aware of the 'software crisis' in other branches of programming requested that the aim of the training programme should be to ensure that all software produced by the engineers should be reliable, maintainable and reasonably efficient. This would result in the software being usable by other engineers so that the labour intensive activity of software development did not result in one-off, once-used programs. TRAINING PHILOSOPHY Increasingly, engineers are faced with new tools and new technology to assist them with their work. The usual approach taken to introduce such aids is to offer retraining courses which introduce and demonstrate the use of the new tool in specific application areas.
involved in the life cycle of a product and the use of documentation and standards throughout these stages. The training programme builds on this knowledge by introducing the properties of a new material, i.e. software, that is to be engineered into a tool, and the use of documentation and standards to be used when working with this particular material. The stages in a product life cycle are identified as follows: Problem Analysis Specification Design Implementation Testing Debugging Operation Maintenance Modification. The strategy behind the training programme is to introduce the engineers to the particular properties, documentation and standards relating to software at each of the above stages. Examples of these are given in the following section. TRAINING METHOD
The increasing availability of computing power within industry would suggest that computers can be added to an engineer's toolkit. However, the potential versatility and power of a computer cannot be realised simply by provision of the hardware. Nor can a usual retraining course demonstrate the range of applications of computing power. Instead it is essential for the engineer to realise that the computer's power cannot Be harnessed unless software is either purchased or developed by him. The computer therefore provides a means of obtaining an aid or tool but is not a tool per se. The acquisition of software or its production by an engineer provides a tool that can be used within the engineering process. Once such a tool has been developed it would be possible to adopt the usual retraining approach to introduce other engineers to the use of such a tool. However, the first step in introducing computing to engineers is to develop their skills so that they are able to produce a software product with a view to it being used as a tool in the engineering process. Therefore, the philosophy behind the devised training programme is to train engineers to be able to engineer software products that can then be used by them and others as tools. TRAINING DESIGN STRATEGY As with all training programmes the best approach is to attempt to build upon the existing knowledge of the students. In this particular case study the 'students' all have considerable hardware engineering experience and are therefore aware of the stages
The training programme is executed by a three-day intensive course at Chelmer-Essex Institute. The course involves approximately 50% practical work using identical computing facilities to those available in-plant. Here engineers are introduced to the properties of software and a set of documentation and implementation standards for each of the stages in the product life cycle. The standards and guidelines are all based on sound software engineering principles and follow closely the top down design methodology described by Rzevski, Trafford and Wells (1981). An elementary computer-assisted learning package (Wells,Rzevski 1981)based on this methodology has been devebped and evaluated by students with no engineering or software experience. At the specification stage the form in Fig.1 is employed to describe the functions and the details of the inputs and outputs to the software. At the implementation stage specific standards are given for producing program code in FORTRAN IV from the design documentation. These standards include conventions about allocation of line numbers, inclusion of comments and use of GOTOs. At the operation stage the engineer is provided with a checklist for the contents of the User Documentation Manual. This is seen to be an essential part of the process to enable other engineers to use the developed software aid.
En g in ee r
t o So f twa r e En g i nee r
All exer c i ses with i n the co urse a re r e lated t o e n g i neeri ng app li c atio ns and a r e d e signe d to g i ve p r ac t ice in a ll the s o ftwar e e n g i neering stage s descr i bed a bove. Before test i ng of the imp l eme nta ti on is permitte d using the computing equipment t he co urs e de l egat es are required t o submit t he documentat i on r e l evant t o t h e earlier eng i nee ring stage s f or chec k i n g by a c o urse lecture r. This appr oach p l a c es emphasis o n thoroughness in the design and p l a nni ng stages rather than i n the testing and debugging stages , as is so o f ten the case with software products .
265
REFERENCES Rz evski, G., D. Tr a f fo r d and M. We ll s (1982) The Evaluatio n a r y Design Me t hodo l ogy app lie d t o I nformatio n Syst ems . I n W. T. Olle (Ed. ) , Info r ma t ion Systems Design Me t hodo l o gies: A Compar a tive Re view . Nor t h Ho lla nd Pub li sh i ng Co. , Amster dam. We ll s , M. and G. Rzevski (198 1 ). Compute ra ide d Learnin g of Software Design Compute r Educ a tion , 39 , 20 - 23 .
CONCLUS I ONS AND FURTHER WORK The company concerned with th i s t r a i ning programme has adopted the methodology and the associated documentation a nd imple mentation standards as a company stand ard . All use r s of the company ' s mini-computer system are now issued with a ' Code of Practice for Software Engineering ' and attend the three - day intensive course to provide them with the skills to become practising software engineers using FORTRAN IV. The technical software expertise of the engineers after a three - day course must necessarily be somewhat l imited . I t is therefore anticipated that a fut u re trai nin g programme will be devi sed to upgrade technical expertise particul ar l y i n imp l e mentation using FORTRAN I V and possib l y BASIC . In addition the use of tools available on the computer system for the softwar e engineering process such as the debugger will be i ntroduced in fu ture courses . The training programme described therefore represents an attempt to train engineers to produce software tools for their j ob rather than just to use too l s. The pro duct i on of such tools i nvolves the acquisition of knowledge about the properties of software and the use of documentation and implementation standards as are used in any engineering discip l ine . A further extension of this tra ini ng pro gramme will include an increase i n the awareness of the properties of software , i . e . implementation details in specific languages , and the use of tools to aid the production of the software too l s for the engineering process .
DISCUSSION SUMMARY The course was limited to thre e days as this was the maximum time senior engineers would be released. Follow-up courses are being planned. The introduction of FORTRAN as a pro g ramming language only occurred after th e disciplined approach to software engineering had been introduced. It was therefore seen as a very different activity from programming a microcomputer using BASIC. The eng ineers utilized rehearsal in the same way as for their previously acquired skills.
ENGINEER TO SOFTWARE ENGINEER A PRACTICAL RETRAINING APPROACH M. J. Wells Faculty of Techno logy, Chelmer-Essex Institute, Chelmsford, Essex, UK
Abstract_ The increas i ng availability of in - house mini - computer power encouraged a local manufacturing company to consider the use of such equipment to aid their engineering processes, retaining the link to the remote parent company's computer installation for its data processing requirements. The introduction of such equipment immediately provided a resource which if managed carefully could result in some very va l uable software be i ng produced for the company , but if mi smanaged could produce many virtua l ly useless, very labour intensive , one- off programs which were on l y of benefit to the programmer . Since none of the engineers had been trained in software it was decided to undertake a rigorous train ing programme in conjunction with Chelmer- Essex Institute. This paper describes the case study outlined above p l ac i ng emphasis on the training design process and the general strategies and models used to effect this training programme _ Keywords_ Computer software ; ing languages ; training.
teaching ;
software engineering;
FUNCTIQ'\JAL SPECIFICATION V$ TEM
SYSTEM
REF M:OUL£ REF
lCENTlFlER tvODULE IDENTIFIER
SI-IEET
OCSlGNER
'NPUTs/OJTF\JTS
ICENTIFlER
REF
I!\fUT
OJ TF\iT
FHCM
TO
TYPE
DE SCRIPl"I(:N
I
Fig.1
Sample documentation sheet
263
CF
programm-
264
M.J. Wells INTRODUCTION
A local company faced with the increasing availability of in-house mini-computer power decided to arrange a training programme for its graduate engineers, in conjunction with Chelmer-Essex Institute. The programme was intended to enable the engineers to develop software to be used as aids to their engineering work. The far-sighted computer manager of this company, aware of the 'software crisis' in other branches of programming requested that the aim of the training programme should be to ensure that all software produced by the engineers should be reliable, maintainable and reasonably efficient. This would result in the software being usable by other engineers so that the labour intensive activity of software development did not result in one-off, once-used programs. TRAINING PHILOSOPHY Increasingly, engineers are faced with new tools and new technology to assist them with their work. The usual approach taken to introduce such aids is to offer retraining courses which introduce and demonstrate the use of the new tool in specific application areas.
involved in the life cycle of a product and the use of documentation and standards throughout these stages. The training programme builds on this knowledge by introducing the properties of a new material, i.e. software, that is to be engineered into a tool, and the use of documentation and standards to be used when working with this particular material. The stages in a product life cycle are identified as follows: Problem Analysis Specification Design Implementation Testing Debugging Operation Maintenance Modification. The strategy behind the training programme is to introduce the engineers to the particular properties, documentation and standards relating to software at each of the above stages. Examples of these are given in the following section. TRAINING METHOD
The increasing availability of computing power within industry would suggest that computers can be added to an engineer's toolkit. However, the potential versatility and power of a computer cannot be realised simply by provision of the hardware. Nor can a usual retraining course demonstrate the range of applications of computing power. Instead it is essential for the engineer to realise that the computer's power cannot Be harnessed unless software is either purchased or developed by him. The computer therefore provides a means of obtaining an aid or tool but is not a tool per se. The acquisition of software or its production by an engineer provides a tool that can be used within the engineering process. Once such a tool has been developed it would be possible to adopt the usual retraining approach to introduce other engineers to the use of such a tool. However, the first step in introducing computing to engineers is to develop their skills so that they are able to produce a software product with a view to it being used as a tool in the engineering process. Therefore, the philosophy behind the devised training programme is to train engineers to be able to engineer software products that can then be used by them and others as tools. TRAINING DESIGN STRATEGY As with all training programmes the best approach is to attempt to build upon the existing knowledge of the students. In this particular case study the 'students' all have considerable hardware engineering experience and are therefore aware of the stages
The training programme is executed by a three-day intensive course at Chelmer-Essex Institute. The course involves approximately 50% practical work using identical computing facilities to those available in-plant. Here engineers are introduced to the properties of software and a set of documentation and implementation standards for each of the stages in the product life cycle. The standards and guidelines are all based on sound software engineering principles and follow closely the top down design methodology described by Rzevski, Trafford and Wells (1981). An elementary computer-assisted learning package (Wells,Rzevski 1981)based on this methodology has been devebped and evaluated by students with no engineering or software experience. At the specification stage the form in Fig.1 is employed to describe the functions and the details of the inputs and outputs to the software. At the implementation stage specific standards are given for producing program code in FORTRAN IV from the design documentation. These standards include conventions about allocation of line numbers, inclusion of comments and use of GOTOs. At the operation stage the engineer is provided with a checklist for the contents of the User Documentation Manual. This is seen to be an essential part of the process to enable other engineers to use the developed software aid.
En g in ee r
t o So f twa r e En g i nee r
All exer c i ses with i n the co urse a re r e lated t o e n g i neeri ng app li c atio ns and a r e d e signe d to g i ve p r ac t ice in a ll the s o ftwar e e n g i neering stage s descr i bed a bove. Before test i ng of the imp l eme nta ti on is permitte d using the computing equipment t he co urs e de l egat es are required t o submit t he documentat i on r e l evant t o t h e earlier eng i nee ring stage s f or chec k i n g by a c o urse lecture r. This appr oach p l a c es emphasis o n thoroughness in the design and p l a nni ng stages rather than i n the testing and debugging stages , as is so o f ten the case with software products .
265
REFERENCES Rz evski, G., D. Tr a f fo r d and M. We ll s (1982) The Evaluatio n a r y Design Me t hodo l ogy app lie d t o I nformatio n Syst ems . I n W. T. Olle (Ed. ) , Info r ma t ion Systems Design Me t hodo l o gies: A Compar a tive Re view . Nor t h Ho lla nd Pub li sh i ng Co. , Amster dam. We ll s , M. and G. Rzevski (198 1 ). Compute ra ide d Learnin g of Software Design Compute r Educ a tion , 39 , 20 - 23 .
CONCLUS I ONS AND FURTHER WORK The company concerned with th i s t r a i ning programme has adopted the methodology and the associated documentation a nd imple mentation standards as a company stand ard . All use r s of the company ' s mini-computer system are now issued with a ' Code of Practice for Software Engineering ' and attend the three - day intensive course to provide them with the skills to become practising software engineers using FORTRAN IV. The technical software expertise of the engineers after a three - day course must necessarily be somewhat l imited . I t is therefore anticipated that a fut u re trai nin g programme will be devi sed to upgrade technical expertise particul ar l y i n imp l e mentation using FORTRAN I V and possib l y BASIC . In addition the use of tools available on the computer system for the softwar e engineering process such as the debugger will be i ntroduced in fu ture courses . The training programme described therefore represents an attempt to train engineers to produce software tools for their j ob rather than just to use too l s. The pro duct i on of such tools i nvolves the acquisition of knowledge about the properties of software and the use of documentation and implementation standards as are used in any engineering discip l ine . A further extension of this tra ini ng pro gramme will include an increase i n the awareness of the properties of software , i . e . implementation details in specific languages , and the use of tools to aid the production of the software too l s for the engineering process .
DISCUSSION SUMMARY The course was limited to thre e days as this was the maximum time senior engineers would be released. Follow-up courses are being planned. The introduction of FORTRAN as a pro g ramming language only occurred after th e disciplined approach to software engineering had been introduced. It was therefore seen as a very different activity from programming a microcomputer using BASIC. The eng ineers utilized rehearsal in the same way as for their previously acquired skills.