- Email: [email protected]
Prototyping as a system development methodology: Opportunities and pitfalls
applications Prototyping as a system development methodology: opportunities and pitfalls by JANE E TOZER
Abstract. It is common these days to build protoO,pe systems befi~re delivering an expensive system. However, there can be much conflict between developer and user about timescales, adjustments and a deliverable end result. One UK st~[tware house shows how conflicts can be avoided through clearly d¢fined project roles and adoption ~ff a workable methodology. Keywords. prq/ect management, system methodologies,
prototyping. here has been much discussion recently over the benefits of prototyping as a development approach, but tying the theory down to simple and pragmatic practice can be difficult at best, confusing and counter-productive at worst. Part of the difficulty is that prototyping means different things to different people, and misunderstandings can easily arise as people talk, unaware of their different starting points, at cross purposes. This paper gives one view, based on a UK software house's experience, of how prototyping can be built into a methodology which delivers systems in typically one third of the traditionally required time. The author does not claim it is the only way to prototype and develop systems productively, it may not even be the best way, but it has worked for Softwright Systems in nearly four years of developing distributed systems for corporate clients. These include A D P Financial, Bank of England, H F C Trust and Savings, IBM, Orion Royal Bank, Safeway Inc, and many others. The company does not develop systems any other way, prototyping is not an option, it is the fundamental foundation of its approach which it believes delivers better systems, faster, to the client's users.
T
Soflwright Systems Lid, Sheer House, Station Approach, West Byfleet, Surrey KTI4 6NL, LJK.
vol 29 no 5 june 1987
The methodology described below is what the author calls a fourth-generation methodology (4GM). Note that this is not the same as a fourth-generation language (4GL), many people just plug 4GLs into the coding stage of the traditional third generation methodology, and as a result achieve only a fraction of the potential productivity savings opened up by these new 4 G L tools. A true 4GM is based on prototyping, and may or may not be based on a 4 G L as a development tool. Softwright Systems uses Micro Focus' Sourcewriter as a 4GL, and the particular factors relating to this choice are covered later in the paper.
Prototype First, what is meant by a prototype? Some people call mere screen and report mock-ups a prototype. Others mean a simulation, where data can be put in and fed back to the users but without actual file accesses and processing taking place. These mock-ups and simulations can be valuable, for the user interface is one of the most important aspects of interactive systems design, and they give a much better indication of that interface than paper layout charts ever can. But they miss out on the full potential benefits ofprototyping. Softwright Systems uses the word prototype in the same way as the car industry does, you can climb into a prototype, switch it on, and drive it off. It is not the clay mock-up, or the scale model you put in the wind tunnel, it is real and can give invaluable feedback on those aspects of the system that you need or choose to examine. What goes into a prototype, and how does it differ from a full operational system? This is a matter of experience and mutual agreement with the client. The user interface is always a vital element, but depending on the application in mind it may be equally important to put in the full data model and/or real validation and processing of the
0950-5849/87/050265-05503.00 ,~' 1987 Butlerworth & Co (Publishers) Ltd.
265
transactions. Only then can one use the prototype to draw conclusions about system performance, operability, feasibility (e.g. on data sizing) etc. What is missing? If it has real data, real processing, and real screens and reports, is it not the full system? Typically Softwright Systems builds only 20% of the full requirement into the prototype, reflecting the 80/20 rule that 80% of the operational need will be met by 20% of the system. It prototypes the 'prime business path', and by mutual agreement with the client will focus on, say, only a selection of the required reports, or only the daily as opposed to month end processing. Lessons learnt about screen and report presentation can usually easily be extended to the whole system. Equally, having checked out the processing details fully in the prime business path usually leads naturally to tidying up of any loose ends on the exception routines.
User communication and understanding Having developed the prototype, what next? The D P fear is that users will get carried away, constantly changing and rechanging their minds, opening up the spectre of an endless, uncontrolled development. The user reaction can be one of puzzlement: if so much can be achieved so quickly, then why have developments taken so long in the past, and why can't the prototype be put into immediate productive use? Neither of these problem situations need arise if prototyping is handled effectively. Taking the user reaction first, this comes down to setting the right expectations. The prototype can, amongst its many roles, be a superbly effective channel of communication between technical and user staff. Providing the 80/20 split (or whatever is the actual split in each case) has been explained to the user, so that they realise how much is missing and the value of the missing parts, then the close interaction between user and technical staff that takes place during prototype development can be used to communicate a much deeper understanding of the challenges and details of systems development than has been achieved in the past. The communication is two way, D P staff also learn a tremendous amount about the real user requirement, but the communication from D P staff to users is often overlooked, and can be a vital part of building a better working relationship. In practice it is not found that prototyping creates over demanding users with unrealistic expectations of full system development timescales, in fact quite the reverse. The D P fear of never-ending prototyping also does not occur in real life. The reason for this is simple: as a software house endless prototyping would translate very directly into endless money. Commercial constraints rapidly take over, and it is found that in all but a very few cases it is apparent to both users and system builders that
266
enough has been learnt from the first prototype to make more interactions unnecessary and economically unjustifiable. A second prototype has been built in exceptional circumstances if, for example, the first one has helped uncover fundamental misunderstandings and mistakes in the proposed system design. But provided the underlying functionality and data model have not changed drastically, a second prototype is usually not needed. Internal D P departments may not have this simple commercial way of avoiding the endless prototyping spectre, but increasingly DP departments arc charging commercial rates to user departments for their services. Perhaps this is just one more reason why such charging makes good business sense.
Prototype review The next stage, then, is the formal review of the prototype and documentation of the lessons learned. This stage must not be skimped. It is easy to just demonstrate the prototype, very impressively, but to do so is a one-way process and the most vital element in the whole prototyping methodology is obtaining and exploiting user.l'eedhack. The prototype review must be two way, with structured documentation taken by the DP staff, and must be in depth with regard to all of the system functions and all of the types of staff affected by the system. Thus clerical, supervisory, management, and even board level staff should review the system. Only then can the full benefit be obtained, in detailed feedback on system intricacies, and in inspired feedback on better ways of doing the job. We all know the value of getting such feedback in time to be able to use it and build systems reflecting it, rather than (as traditionally) getting the feedback when the final system is installed - - when it is too late and too expensive to do anything as a result. It is therefore very important that users recognize the need, and plan, for enough time to review the prototype properly. Every hour skimped here can mean weeks or months lost later, or compromise on an unnecessarily inadequate system. 'It is only a prototype' as an attitude results in an operational system that is still only a prototype! The prototype review process needs to be highly organized, and can become a major logistical exercise. Representatives from all of the staffwho will be affected by the system need to be present, so that all aspects of the system can be reviewed and feedback obtained. Softwright Systems uses its own set of structured review documentation, produced from the application dictionary that the development process is based upon. With other development tools a similar set of documentation would be necessary, and should similarly be derived from any good application dictionary.
information and software technology
applications Rebuilding The transition from prototype to operational system can be handled in two fundamentally different ways. Softwright Systems throws away the prototype, keeping the system dictionary wherein lies the real investment of the previous few weeks effort. This means rebuilding and delivering, the cleanest and most maintainable system possible without the temptation to compromise the requirements for the sake of keeping or only slightly changing what was done in the prototype. An attitude of mind that says we are starting afresh leads to better systems that are exactly what is required, rather than bungled efforts. Others modify and extend the prototype, evolving it towards the final system. This can lead to design compromises, as covered above, but it can have more fundamental drawbacks as well. For corporate systems, evolutionary development can mean never quite knowing what the final system will do, when it will be ready, or what it will cost. This is usually unacceptable commercially to clients, and is also unacceptable to audit departments who need to sign off design specifications (especially for financial systems). The only alternative is then to review and sign off each prototype stage as it evolves towards the final system. This can be very expensive and may not be justified. Evolutionary prototyping can be entirely appropriate for personal ad hoc systems, such as decision support or enquiry systems which are not updating the database, but corporate operational systems need the discipline of an agreed functional specification and timescale, and professional change control procedures for changes to that specification. In this case the 'revolutionary' approach offers the best value for money, where one or two prototypes are used as a highly productive and effective way of producing a functional specification which users really understand. This is a key difference with prototyping: users sign offa specification that they understamt, having seen it in operation. Such a specification is words backing up a picture, rather than words attempting to describe an unseen picture as has been the case with the third generation methodology, and we all know how much more effective pictures are for communication compared with "a thousand words'.
Different skills The methodology described briefly above needs, of course, the right people to apply it and the right tools to support them. It should not be surprising that a new development methodology requires different skills from the traditional third-generation approach. The difference
vol 29 no 5 june 1987
is that between the production line specialization of the third generation methodology, and total systems responsibility with the fourth-generation methodology. When developments take months or years there is little choice but to specialize, with expensive and experienced staff concentrating on the initial feasibility, design, and specification stages, and technical specialists concentrating on the coding and testing. Each person takes a particular position on the system development 'production line', and carries out just that part of the development that is needed at that stage. This requires rigorously defined handover documentation and protocols. Each specialist will only do their bit, whether it is putting the wheels on or fitting the interior trim, if all the previous stages have been completed and proved so with appropriate documentation. These regulations have their place, especially on very large projects where division of labour is necessary, but if modern productivity aids can enable us to develop systems with smaller teams, then the overheads and bureaucracy of this approach can be counter-productive and demotivating. Swedish automobile manufacturers Volvo have learnt this lesson, their small teams with responsibility for the whole car production process produce better quality cars with greater job satisfaction and reduced staff turnover. Prototyping and 4GL based full system development can produce the same benefits in software development. Soflwright Systems uses small teams of four or five at most and have no specialization within the team (there is seniority, and grades of responsibility, but that is a different issue). The staffare not analysts or programmers or even analyst/programmers, they are system builders expected to develop all the skills of building the system from start to finish. The company therefore recruits staff with skills or potential in coding, analysis (business and technical), and effective communication with users. Small teams of such system builders take the whole project through from initial briefing to final system. This increases job satisfaction and, vitally important, minimizes the risk of misunderstandings arising from multistage communication down the production line.
Practical tools The fourth-generation methodology described above must be supported with practical tools for the system builder to use. In theory, it could even be applied with third-generation languages (3GLs). In practice, however, prototyping is only economically viable if the prototype can be developed in a few weeks, say eight weeks at the very most. Typically it takes three to six weeks, lfit takes longer than that to develop a meaningful subset of the proposed system, users will generally not want to wait and will prefer to plunge straight into conventional systems
267
development's analysis phase. This is why, even though the attractions of prototyping became evident in the late 1970s, the technique did not get widely picked up until just a year or two ago. Softwright Systems started nearly four years ago, and mostly use Micro Focus' Sourcewriter and COBOL Workbench as their development tool set. COBOL! how can COBOL be used in a fourth generation methodology? The answer is quite simple: Micro Focus' COBOL can provide good performance and a portable base for distributed systems, running on over 160 types of hardware including PCs, 6150s, NCR Tower, AT&T 3Bs, etc. What is wrong with COBOL is that writing it the hard way is boring, error prone, and unproductive. Sourcewriter gives the best of both worlds. It is a productive and sophisticated dictionary driven application generator which meets typically 80 % of the application requirement. No 4GL meets 100% of the requirements for building systems such as complex corporate systems which may have to fit in with existing mainframe systems. Since Sourcewriter generates readable and structured COBOL, Softwright Systems can add the extra functionality its clients need with hand coded subroutines. This is analogous to the continued need for Assembler language as the second generation 'escape route' when third-generation languages can not meet the need. The fact that Assembler is still sometimes needed does not invalidate the productivity advantages of moving up to the third generation. Similarly, the use of the COBOL 3GL 'escape route' simply enhances the range of applications we can tackle with the productivity of Sourcewriter as a 4GL. Systems developed in this way benefit from compiled code performance and very low runtime system costs (compared with 4GL licence costs often needed even on the target systems with other 4GLs). This can be particularly important in distributed systems, where the same application may be implemented in many sites, even hundreds or thousands of branch offices or store locations. Compiled code is also very secure in such environments against modification whether by accident or design. Report generators like Co-writer can give local ad hoc reporting ability, without the risk of compromising the basic system integrity and auditability. -
-
Practical results What are the practical results of this new approach to systems development? The following examples pick up on a few of the messages that Softwright Systems has learnt in the past four years of applying and refining its prototyping methodology. One client specified a system to meet the needs of one
268
department, and only after the prototype was presented for review did it become apparent that a second department would be affected by the system as well. At this stage the proposed system had to be drastically modified to fit in with the second departments operation. At first this looked like a defeat, the team felt it had failed in delivering a prototype that was clearly wrong. Only later was it realised it was a triumph for the prototyping approach. With the traditional approach the whole system may have been built and delivered before the oversight was discovered. Instead it was spotted and acted on after only a few weeks of prototyping effort. A second prototype was developed to cover the major new functions and changes required, and then the full system was built to the satisfaction of both sets of users. A second example concerns a major chain of retail stores which wanted two complex store level systems to help both with local operations and the effective collection of accurate corporate data. After one month's prototyping, the reviews were set up to allow 70 client staff, from all levels, to review the prototypes fully over a two-week period. The review staff included store clerks, supervisors, managers, together with divisional clerks and managers and head office corporate people. This was a major logistical exercise to enable so many types of people, with their own individual objectives and perspective on the systems, to see the prototypes and interact with them enough to provide indepth feedback. The effort was worth it though since without that scale of effort the chances of sucessfully rolling out sophisticated applications into hundreds of store locations are vanishing. A third example concerns a financial services company which commissioned a prototype system of a proposed new service, specifically to offer the prototype to their clients to get feedback on the proposed service before committing the time and the money to its development. This approach can give a company the best possible market reaction (and encourage prospective clients) before major investments are made in new product development. The fourth example concerns a U K government department. It used a prototype system not only for the usual reason of getting early feedback to improve the final system, but also to then proceed with a major user training exercise in parallel with the full system development. This really does require a 'real' prototype, rather than the mock-ups or simulations mentioned earlier, because of the risk of setting false expectations. Try training users with a mock-up and you may end up with extremely disappointed users when they find that real processing and file accesses take real time. No amount of
information and software technology
applications explaining this point in theory will overcome the expectations set, often unconsciously, by extensive use of a mere shell system. Finally, a major financial corporation specifically set out to demonstrate system security and auditability to their audit department by building a prototype. This was probably a much more efficient way of discussing audit
vol 29 no 5 june 1987
requirements than paper discussions. The resultant security design did then have to be thoroughly documented and rigorously implemented. This demonstrates that prototyping can add effectively to DP controls and standards, it need not be an abandonment of those standards for 'slap happy' and uncontrolled developments. []
269
Abstract. It is common these days to build protoO,pe systems befi~re delivering an expensive system. However, there can be much conflict between developer and user about timescales, adjustments and a deliverable end result. One UK st~[tware house shows how conflicts can be avoided through clearly d¢fined project roles and adoption ~ff a workable methodology. Keywords. prq/ect management, system methodologies,
prototyping. here has been much discussion recently over the benefits of prototyping as a development approach, but tying the theory down to simple and pragmatic practice can be difficult at best, confusing and counter-productive at worst. Part of the difficulty is that prototyping means different things to different people, and misunderstandings can easily arise as people talk, unaware of their different starting points, at cross purposes. This paper gives one view, based on a UK software house's experience, of how prototyping can be built into a methodology which delivers systems in typically one third of the traditionally required time. The author does not claim it is the only way to prototype and develop systems productively, it may not even be the best way, but it has worked for Softwright Systems in nearly four years of developing distributed systems for corporate clients. These include A D P Financial, Bank of England, H F C Trust and Savings, IBM, Orion Royal Bank, Safeway Inc, and many others. The company does not develop systems any other way, prototyping is not an option, it is the fundamental foundation of its approach which it believes delivers better systems, faster, to the client's users.
T
Soflwright Systems Lid, Sheer House, Station Approach, West Byfleet, Surrey KTI4 6NL, LJK.
vol 29 no 5 june 1987
The methodology described below is what the author calls a fourth-generation methodology (4GM). Note that this is not the same as a fourth-generation language (4GL), many people just plug 4GLs into the coding stage of the traditional third generation methodology, and as a result achieve only a fraction of the potential productivity savings opened up by these new 4 G L tools. A true 4GM is based on prototyping, and may or may not be based on a 4 G L as a development tool. Softwright Systems uses Micro Focus' Sourcewriter as a 4GL, and the particular factors relating to this choice are covered later in the paper.
Prototype First, what is meant by a prototype? Some people call mere screen and report mock-ups a prototype. Others mean a simulation, where data can be put in and fed back to the users but without actual file accesses and processing taking place. These mock-ups and simulations can be valuable, for the user interface is one of the most important aspects of interactive systems design, and they give a much better indication of that interface than paper layout charts ever can. But they miss out on the full potential benefits ofprototyping. Softwright Systems uses the word prototype in the same way as the car industry does, you can climb into a prototype, switch it on, and drive it off. It is not the clay mock-up, or the scale model you put in the wind tunnel, it is real and can give invaluable feedback on those aspects of the system that you need or choose to examine. What goes into a prototype, and how does it differ from a full operational system? This is a matter of experience and mutual agreement with the client. The user interface is always a vital element, but depending on the application in mind it may be equally important to put in the full data model and/or real validation and processing of the
0950-5849/87/050265-05503.00 ,~' 1987 Butlerworth & Co (Publishers) Ltd.
265
transactions. Only then can one use the prototype to draw conclusions about system performance, operability, feasibility (e.g. on data sizing) etc. What is missing? If it has real data, real processing, and real screens and reports, is it not the full system? Typically Softwright Systems builds only 20% of the full requirement into the prototype, reflecting the 80/20 rule that 80% of the operational need will be met by 20% of the system. It prototypes the 'prime business path', and by mutual agreement with the client will focus on, say, only a selection of the required reports, or only the daily as opposed to month end processing. Lessons learnt about screen and report presentation can usually easily be extended to the whole system. Equally, having checked out the processing details fully in the prime business path usually leads naturally to tidying up of any loose ends on the exception routines.
User communication and understanding Having developed the prototype, what next? The D P fear is that users will get carried away, constantly changing and rechanging their minds, opening up the spectre of an endless, uncontrolled development. The user reaction can be one of puzzlement: if so much can be achieved so quickly, then why have developments taken so long in the past, and why can't the prototype be put into immediate productive use? Neither of these problem situations need arise if prototyping is handled effectively. Taking the user reaction first, this comes down to setting the right expectations. The prototype can, amongst its many roles, be a superbly effective channel of communication between technical and user staff. Providing the 80/20 split (or whatever is the actual split in each case) has been explained to the user, so that they realise how much is missing and the value of the missing parts, then the close interaction between user and technical staff that takes place during prototype development can be used to communicate a much deeper understanding of the challenges and details of systems development than has been achieved in the past. The communication is two way, D P staff also learn a tremendous amount about the real user requirement, but the communication from D P staff to users is often overlooked, and can be a vital part of building a better working relationship. In practice it is not found that prototyping creates over demanding users with unrealistic expectations of full system development timescales, in fact quite the reverse. The D P fear of never-ending prototyping also does not occur in real life. The reason for this is simple: as a software house endless prototyping would translate very directly into endless money. Commercial constraints rapidly take over, and it is found that in all but a very few cases it is apparent to both users and system builders that
266
enough has been learnt from the first prototype to make more interactions unnecessary and economically unjustifiable. A second prototype has been built in exceptional circumstances if, for example, the first one has helped uncover fundamental misunderstandings and mistakes in the proposed system design. But provided the underlying functionality and data model have not changed drastically, a second prototype is usually not needed. Internal D P departments may not have this simple commercial way of avoiding the endless prototyping spectre, but increasingly DP departments arc charging commercial rates to user departments for their services. Perhaps this is just one more reason why such charging makes good business sense.
Prototype review The next stage, then, is the formal review of the prototype and documentation of the lessons learned. This stage must not be skimped. It is easy to just demonstrate the prototype, very impressively, but to do so is a one-way process and the most vital element in the whole prototyping methodology is obtaining and exploiting user.l'eedhack. The prototype review must be two way, with structured documentation taken by the DP staff, and must be in depth with regard to all of the system functions and all of the types of staff affected by the system. Thus clerical, supervisory, management, and even board level staff should review the system. Only then can the full benefit be obtained, in detailed feedback on system intricacies, and in inspired feedback on better ways of doing the job. We all know the value of getting such feedback in time to be able to use it and build systems reflecting it, rather than (as traditionally) getting the feedback when the final system is installed - - when it is too late and too expensive to do anything as a result. It is therefore very important that users recognize the need, and plan, for enough time to review the prototype properly. Every hour skimped here can mean weeks or months lost later, or compromise on an unnecessarily inadequate system. 'It is only a prototype' as an attitude results in an operational system that is still only a prototype! The prototype review process needs to be highly organized, and can become a major logistical exercise. Representatives from all of the staffwho will be affected by the system need to be present, so that all aspects of the system can be reviewed and feedback obtained. Softwright Systems uses its own set of structured review documentation, produced from the application dictionary that the development process is based upon. With other development tools a similar set of documentation would be necessary, and should similarly be derived from any good application dictionary.
information and software technology
applications Rebuilding The transition from prototype to operational system can be handled in two fundamentally different ways. Softwright Systems throws away the prototype, keeping the system dictionary wherein lies the real investment of the previous few weeks effort. This means rebuilding and delivering, the cleanest and most maintainable system possible without the temptation to compromise the requirements for the sake of keeping or only slightly changing what was done in the prototype. An attitude of mind that says we are starting afresh leads to better systems that are exactly what is required, rather than bungled efforts. Others modify and extend the prototype, evolving it towards the final system. This can lead to design compromises, as covered above, but it can have more fundamental drawbacks as well. For corporate systems, evolutionary development can mean never quite knowing what the final system will do, when it will be ready, or what it will cost. This is usually unacceptable commercially to clients, and is also unacceptable to audit departments who need to sign off design specifications (especially for financial systems). The only alternative is then to review and sign off each prototype stage as it evolves towards the final system. This can be very expensive and may not be justified. Evolutionary prototyping can be entirely appropriate for personal ad hoc systems, such as decision support or enquiry systems which are not updating the database, but corporate operational systems need the discipline of an agreed functional specification and timescale, and professional change control procedures for changes to that specification. In this case the 'revolutionary' approach offers the best value for money, where one or two prototypes are used as a highly productive and effective way of producing a functional specification which users really understand. This is a key difference with prototyping: users sign offa specification that they understamt, having seen it in operation. Such a specification is words backing up a picture, rather than words attempting to describe an unseen picture as has been the case with the third generation methodology, and we all know how much more effective pictures are for communication compared with "a thousand words'.
Different skills The methodology described briefly above needs, of course, the right people to apply it and the right tools to support them. It should not be surprising that a new development methodology requires different skills from the traditional third-generation approach. The difference
vol 29 no 5 june 1987
is that between the production line specialization of the third generation methodology, and total systems responsibility with the fourth-generation methodology. When developments take months or years there is little choice but to specialize, with expensive and experienced staff concentrating on the initial feasibility, design, and specification stages, and technical specialists concentrating on the coding and testing. Each person takes a particular position on the system development 'production line', and carries out just that part of the development that is needed at that stage. This requires rigorously defined handover documentation and protocols. Each specialist will only do their bit, whether it is putting the wheels on or fitting the interior trim, if all the previous stages have been completed and proved so with appropriate documentation. These regulations have their place, especially on very large projects where division of labour is necessary, but if modern productivity aids can enable us to develop systems with smaller teams, then the overheads and bureaucracy of this approach can be counter-productive and demotivating. Swedish automobile manufacturers Volvo have learnt this lesson, their small teams with responsibility for the whole car production process produce better quality cars with greater job satisfaction and reduced staff turnover. Prototyping and 4GL based full system development can produce the same benefits in software development. Soflwright Systems uses small teams of four or five at most and have no specialization within the team (there is seniority, and grades of responsibility, but that is a different issue). The staffare not analysts or programmers or even analyst/programmers, they are system builders expected to develop all the skills of building the system from start to finish. The company therefore recruits staff with skills or potential in coding, analysis (business and technical), and effective communication with users. Small teams of such system builders take the whole project through from initial briefing to final system. This increases job satisfaction and, vitally important, minimizes the risk of misunderstandings arising from multistage communication down the production line.
Practical tools The fourth-generation methodology described above must be supported with practical tools for the system builder to use. In theory, it could even be applied with third-generation languages (3GLs). In practice, however, prototyping is only economically viable if the prototype can be developed in a few weeks, say eight weeks at the very most. Typically it takes three to six weeks, lfit takes longer than that to develop a meaningful subset of the proposed system, users will generally not want to wait and will prefer to plunge straight into conventional systems
267
development's analysis phase. This is why, even though the attractions of prototyping became evident in the late 1970s, the technique did not get widely picked up until just a year or two ago. Softwright Systems started nearly four years ago, and mostly use Micro Focus' Sourcewriter and COBOL Workbench as their development tool set. COBOL! how can COBOL be used in a fourth generation methodology? The answer is quite simple: Micro Focus' COBOL can provide good performance and a portable base for distributed systems, running on over 160 types of hardware including PCs, 6150s, NCR Tower, AT&T 3Bs, etc. What is wrong with COBOL is that writing it the hard way is boring, error prone, and unproductive. Sourcewriter gives the best of both worlds. It is a productive and sophisticated dictionary driven application generator which meets typically 80 % of the application requirement. No 4GL meets 100% of the requirements for building systems such as complex corporate systems which may have to fit in with existing mainframe systems. Since Sourcewriter generates readable and structured COBOL, Softwright Systems can add the extra functionality its clients need with hand coded subroutines. This is analogous to the continued need for Assembler language as the second generation 'escape route' when third-generation languages can not meet the need. The fact that Assembler is still sometimes needed does not invalidate the productivity advantages of moving up to the third generation. Similarly, the use of the COBOL 3GL 'escape route' simply enhances the range of applications we can tackle with the productivity of Sourcewriter as a 4GL. Systems developed in this way benefit from compiled code performance and very low runtime system costs (compared with 4GL licence costs often needed even on the target systems with other 4GLs). This can be particularly important in distributed systems, where the same application may be implemented in many sites, even hundreds or thousands of branch offices or store locations. Compiled code is also very secure in such environments against modification whether by accident or design. Report generators like Co-writer can give local ad hoc reporting ability, without the risk of compromising the basic system integrity and auditability. -
-
Practical results What are the practical results of this new approach to systems development? The following examples pick up on a few of the messages that Softwright Systems has learnt in the past four years of applying and refining its prototyping methodology. One client specified a system to meet the needs of one
268
department, and only after the prototype was presented for review did it become apparent that a second department would be affected by the system as well. At this stage the proposed system had to be drastically modified to fit in with the second departments operation. At first this looked like a defeat, the team felt it had failed in delivering a prototype that was clearly wrong. Only later was it realised it was a triumph for the prototyping approach. With the traditional approach the whole system may have been built and delivered before the oversight was discovered. Instead it was spotted and acted on after only a few weeks of prototyping effort. A second prototype was developed to cover the major new functions and changes required, and then the full system was built to the satisfaction of both sets of users. A second example concerns a major chain of retail stores which wanted two complex store level systems to help both with local operations and the effective collection of accurate corporate data. After one month's prototyping, the reviews were set up to allow 70 client staff, from all levels, to review the prototypes fully over a two-week period. The review staff included store clerks, supervisors, managers, together with divisional clerks and managers and head office corporate people. This was a major logistical exercise to enable so many types of people, with their own individual objectives and perspective on the systems, to see the prototypes and interact with them enough to provide indepth feedback. The effort was worth it though since without that scale of effort the chances of sucessfully rolling out sophisticated applications into hundreds of store locations are vanishing. A third example concerns a financial services company which commissioned a prototype system of a proposed new service, specifically to offer the prototype to their clients to get feedback on the proposed service before committing the time and the money to its development. This approach can give a company the best possible market reaction (and encourage prospective clients) before major investments are made in new product development. The fourth example concerns a U K government department. It used a prototype system not only for the usual reason of getting early feedback to improve the final system, but also to then proceed with a major user training exercise in parallel with the full system development. This really does require a 'real' prototype, rather than the mock-ups or simulations mentioned earlier, because of the risk of setting false expectations. Try training users with a mock-up and you may end up with extremely disappointed users when they find that real processing and file accesses take real time. No amount of
information and software technology
applications explaining this point in theory will overcome the expectations set, often unconsciously, by extensive use of a mere shell system. Finally, a major financial corporation specifically set out to demonstrate system security and auditability to their audit department by building a prototype. This was probably a much more efficient way of discussing audit
vol 29 no 5 june 1987
requirements than paper discussions. The resultant security design did then have to be thoroughly documented and rigorously implemented. This demonstrates that prototyping can add effectively to DP controls and standards, it need not be an abandonment of those standards for 'slap happy' and uncontrolled developments. []
269