- Email: [email protected]
Use of structured design and development in the validation of application software
ISA TRANSACTIONS ®
ELSEVIER
ISA Transactions 33 (1994) 125-131
Use of structured design and development in the validation of application software Megan Klein Gruber Honeywell, Inc., 1100 l,qrginia Drive, Fort Washington, PA 19034, USA
Abstract
The structured design and testing of application software is an important element of GMP compliance. Because application software is custom-developed, one cannot rely on 'market hardness' as an indicator of software quality. Structured design provides a means for understanding complex problems and evaluating system requirements. Communication among users, designers and implementers is facilitated. Valuable and usable documentation is produced. There are many existing CASE tools which can assist in the structured design approach. The many benefits of structured programming toward the end of validation are discussed within this paper. Key words: Structured design; Software; Validation; Testing
1. Introduction
A working definition of validation was given by the Food and Drug Administration in their May 1987 document entitled "Guideline on the general principles of process validation" [1], as follows: Validation Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes. The Food and Drug Administration (FDA) requires that Pharmaceutical and Biotechnological manufacturing facilities validate their processes before goods produced can be distributed for consumption. Many Pharmaceutical and
Biotechnological facilities are installing computers to run their processes. As a result of doing this, the complexity of the validation increases dramatically. Guidelines on performing computer validations, from both the F D A and industry experts, are being updated constantly. The complete validation of a computer-based manufacturing process is a long and involved process. The validation master plan usually consists of: design qualification, installation qualification, operation qualification and performance qualification. To provide ' d o c u m e n t e d evidence', all tasks toward designing, implementing and testing the system must be adequately recorded. Validation of the computer system is only a portion of the entire job. The purpose of this article is to simplify a portion of the task of validation by discussing the
0019-0578/94/$07.00 © 1994 Elsevier Science B.V. All rights reserved SSDI 0019-0578(94)00016-F
126
M.K. Gruber / ISA Transactions 33 (1994) 125-131
role of structured programming in the design, development, documentation and testing of application software.
Concept Phase • Create Validation Protocol • Plan Vendor Audits Requirements Phase • Create Functional Requirements Document • Create Performance Qualification Protocol
2. Overview
The validation of an automated system used in Pharmaceutical or Biotechnological manufacturing involves many areas which need to be qualified individually and as an integrated system. Fig. 1 describes the basic building blocks of an automated system. Application software is one of these blocks. Process validation is a process, itself, which should commence during" the concept phase of the project and continue through the requirements phase, design phase, implementation phase and test phase. (See Fig. 2.) The application software for an average project consists of many programs performing many tasks. Some of the tasks are the same or similar to those in other projects, while other tasks are unique. Most projects involve many engineers and programmers. The tasks of design and implementation are dispensed differently from organization to organization and from project to project. Quite often a change of personnel forces a change in the project responsibilities. The challenge in any organization is to set up a project so that tasks are well-defined and personnel can be easily added or removed as the need arises. Using a structured approach can assist in this goal. With a structured approach to producing software, a large complicated task is reduced to smaller, simpler building blocks. These building blocks, or modules, are easier to design, imple-
NON-COMPUTER HARDWARE
OPERATING PROCEDURES
EQUIPMENT
Fig. 1. The automated system.
Design Phase • Create Loop Drawings and Graphics Hierarchy Conduct Application Software Design Analysis Create Installation Qualification Protocol and Procedures • Create Operation Qualification Protocol and Procedures Implementation Phase • Write Application Software Based Upon Design Analysis Define Test Cases for Application Software Write Standard Operating Procedures and User Manuals Test Phase • Execute and Report: Installation Qualification Execute and Report: Operation Qualification • Execute and Report: Performance Qualification Ongoing Phase - Revalidate System as Required Imlolement Calibration SchedulP. Fig. 2. Key steps in process validation.
ment and test. These modules must be well-defined: function, inputs and outputs. The flow of data to and from each module is essential since these modules do not stand alone. If these design criteria can be achieved, then work assignments can be parcelled out to programmers in an effective manner. Work assignments can be easily changed. Programmer interaction with the designers and other programmers is reduced and simplified. The time to introduce a programmer to the project and get him or her up to speed is reduced. The ability to communicate with the end user is facilitated. There are many other benefits to a structured approach; they will be discussed throughout this paper. However, there is a catch: the approach or methodology used must be adopted by the entire group, department or business unit. There are many published methods of software engineering; Gane and Sarson, Ward and Mellor, and Y o u r d o n / D e M a r c o are among the most well known. Systems-Modeling methods provide a graphical representation of the software design, including the data flow from module to module. These methods step through from the top of the design structure through the interme-
M.K. Gruber / ISA Transactions 33 (1994) 125-131
diate levels of software to the detailed functional level of each module while maintaining a consistent framework. Systems-Modeling helps the designer, implementer and purchaser or end user understand the entire software product and the interactions that must take place to meet the software requirements. Each project team must not be allowed to choose their own software engineering method. If this is done or if team members are forced to learn as they go, the purpose is being defeated. One method must be selected and all programmers, engineers and, perhaps, support staff must be trained in its use. The benefits derived from a structured approach come from understanding. Understanding can only be achieved through training and experience. The greater the understanding, the greater the benefits.
3.
D e s i g n
According to I E E E [2], software design is 'the process of defining the software architecture, components, modules, interfaces, test approach, and test data for a software system according to system requirements'. From this definition, we can surmise that the design phase is where most of the labor for the entire project lies. If the design is done properly, this is true. Software must be designed so that it does what it is supposed to do, no less and no more. Breaking down the function of the task into workable modules requires planning, cross-checking and excellent documentation. A hierarchy of modules is created, each of which must have its function, inputs and outputs completely specified. The modules should not have overlaps or gaps. The outputs of one module must be in the format that is required by the module to which it is an input. Imagine sections of railroad tracks built by two construction crews which not only do not meet but also have a different size of the tracks. The railroad workers needed a sound design and they needed to follow it. Computer Aided Software Engineering (CASE) tools [3-6] were not created for railroad design but can greatly assist software developers in their endeavors.
127
Just as there are many software design or systems-modeling methods, there are also many CASE tools. Most tools support several software design methods. It was mentioned previously that training is the key to successful use of a design methodology. The same is true for a CASE tool. Now the method selection and training are twofold: a method must be selected and employees must be trained in this method and a CASE tool must be selected and the same employees must be trained in the use of the CASE tool for the methodology selected. It is easy to decipher the disadvantages of using a CASE tool: (1) Learning a CASE tool is time-consuming and might be difficult, especially for those unaccustomed to using structured methods. (2) Increased productivity from using the CASE tool may not be realized for months or even years. (3) Enforcement of the use of the CASE tool might be a problem. If structured programming habits are not in place, there might be resistance to the 'new' approach. (4) Most (but not all) CASE tools are expensive and must be purchased per workstation. (5) The end user, which for software houses would be the customer, must be able to understand the documentation produced. If they have no training in the tool, they may not want it used. Many of the aforementioned disadvantages are also disadvantages of using a complex software design methodology. The advantages may not outweigh the disadvantages in every situation. In order to visualize the advantages of CASE tools, we list the diagram types supported: - data flow diagrams, transformation schema (real-time data flow diagrams), entity relationship diagrams, - flow charts, state transition diagrams, structure charts, data model diagrams, data structure diagrams. (Remember: there are many tools and each may not support all the diagram types listed.) -
-
-
128
M.K. Gruber / ISA Transactions 33 (1994) 125-131
The data diagrams or charts provide a layered roadmap to the entire design, showing the relationships among all system elements. Data dictionaries can be produced which textually define the modules. Data dictionaries contain: process definitions, external definitions, data store definitions, and data flow definitions. Reports can provide information based upon a search of set criteria. (Fig. 3, compiled by Leonard Hermens and Paul Oman for their article [4] lists standard reports which can be generated from the CASE tool, System Architect.) The advantages of CASE tools are numerous. The software designer is lifted from his stone tablet and chisel into the computer age. Following are listed some of the CASE tools' advantages: (1) Design entry or diagramming is simplified (once the tool is comprehended). (2) Modifications and additions can be easily integrated. (3) Modules are completely defined. Test scenarios can come directly from these definitions. (4) Customized help text can be configured. STANDARD SYSTEMARCHITECT REPORTS ALL BLANKDEFINITIONDESCRIPTIONS ALL DEFINITIONS AUDIT TRAILBY AUDITID AUDITTRAILBY DATE AUDITTRkJLBY TYPE CHANGE-REQUESTDERNITIONS CHANG6REQUEST/SYMBOLCROSS-REFERENCED CHANGE REQUESTSNOT USED COMMENTSOF SYMBOLS CONTROLFLAGDEFINITIONS CROSSqREFERENCEDATA/EXPRESSION CROSS-REFERENCEI~L~GRAM/SYMEOL CROSS*REFERENCEEXPRESSION/DATA CROSS-REFERENCESYMBOUDIAGRAM CURRENTDIAGRAM DAT/~ELEMENTDEFINITIONS DATA-ELEMENT/EXPRESSIONUSE -REFERENCE DATA ELEMENTSNOT USED DATA ELEMENTSUSED BY DEFINITIONS DATAELEMENTSUSED BY DIAGRAM DATA-EXPRESSIONVALIDATION DATA-FLAGDEFINITIONS DATAFLOWBALANCING:DIAGRAMS DATAFLOWBALANCING : SYM8OLS DATAFLOW-DIAGR~ RULESCHECK CATAELOW-OIAGRAMSYMBOLLIST DATA-STOREDERNITIONS DATA-STRUCTUREDEFINITIONS DATASTRUCTURESNOT USED DATAUSEDBY DIAGRAM(CURRENT) DATABASEDEFINITIONS DEFINITIONL/STiNGBY NAME DEFINITIONLISTINGBY TYPE DEFINITION/ELEMENT CEFINITIONAELEMENT.DEPTH0 DEFINITIONSNOT USED DESCRIPTIONDERNITIONS DESCRIPTIONMETRICS DIAGRAM CONTAINSSYMBOLS DIAGRAMiNPUT DIAGRAMINPUT/OUTPUTLISTS DIAGRAMLEVELNUMBERS
DIAGRAMLISTINGSY TYPE DIAGRAMOUTPUT DIAGRAMS-USECOMPONENTS ELEMENTLIST ENTITYDERNITIONS EXPRESSIONCHECKINGBY SYMBOL EXTERNALDEFINITIONS GLOSSARYDERNITIONS LEVELREFERENCEDIAGRAM/SYMBGL LEVELREFERENCESYMBOL/DIAGRAM MATRIX:A,E,C, EVERYTHINGBY A,B,C, EVERYTHING MATRIX: DATAUSEDBY DEFINITIONS MATRIX: DATAUSEDBY DIAGRAMS MATRIXDERNITION USE DATA MATRIX: DIAGRAMSBY SYMBOLCOUNT MATRIX: REQUIREMENTSVS. DIAGRAMS MATRIX: REQUIREMENTSVS. SYMBOLS MODULEDERNITIONS NAMEUSTING PROCESSDERNITIONS PROCESSINPUT PROCESSINPUT/OUTPUTLISTS PROCESSOUTPUT REQUIREMENTSDEFINITIONS REQUIREMENT/SYMBOLCROSS-REFERENCE REQUIREMENTSNOT USED STATE DERNITIONS STRUCTURE-CHARTRULESCHECK STRtJCTURE~IART SYMI~OLUST SYMBOLUSTINGBY TYPE SYMBOLUSTINGBY NAME SYMBQUCHANGEREQUESTCROSS-REFERENCED SYMBOL~REMENT CROSS-REFERENCED SYMBOL/TEST-PLANCROSS-REFERENCED SYMBOLS-USSDATA(CURRENT) TEST-RAN DERNtTIONS TEST-Pt.AN/SYMBOLCROSS-REFERENCED TEST PLANSNOT USED TRANSITIONDERNITIONS UPDATEALL EXPFtJESSIONS UPDATESYMBOUDERN/TIONRELATIONSHIPS
Fig. 3. Standard system architect reports.
(5) Charts can be searched; this is especially useful to find all places an element is used or a module called in case of modifications. (6) Analysis capabilities can check for errors: labelling, cross-referencing, record and element definitions. Charts can be checked against layout and methodology specific rules for diagram accuracy. (7) Reports can be printed to a printer, screen or file. (8) An audit trail is provided. When changes were made and who made them can be tracked. This is especially useful for validated systems. (9) Quality documentation is produced. The documentation can be printed but also exists in software files which can be searched more readily, allowing the user to 'click' on symbols for definitions or to move around the chart. (Once again note that tool capabilities will vary.) Most of the advantages listed above are documentable or actual reports. This is the key to validation. The second and third words of the F D A definition of validation are 'documented evidence'. CASE tools not only provide utilities to error check design but facilitate the documentation of the results. H o w many times is design documentation for software produced after the fact? Most of us remember doing that in school. The use of CASE tools precludes the need to write documentation as a clean up effort. As with a modeling methodology, the maxim u m benefit from the use of CASE tools can only be realized if every engineer and programmer (and support staff, as applicable) is trained in use of the same tool. Word processors are a good example of this. If each typist used a different word processor, he or she would have no problem doing h i s / h e r own work but would have difficulty finishing a document for s o m e o n e else. One can be proficient in more that one word processor and one can be proficient in more that one CASE tool. However, with the time it takes to learn the tool and the experience level needed to become proficient, there are no apparent advantages to learning multiple tools (for concurrent usage). The more demands there are on the project team, the greater the desire for the members to stick
M.K. Gruber /ISA Transactions 33 (1994) 125-131
with what they know best; if this is not the CASE tool of choice, confusion and frustration may ensue. CASE tools have many advantages but disadvantages were listed, also. Large software projects would reap more benefits from CASE tools than small projects. A software house would more likely find greater benefits from the knowledge and use of a CASE tool than a small in-house programming team. A CASE tool is not necessary to have a successful structured-design approach. Structured programming was being taught long before CASE tools came out on the market. However, a standard methodology is necessary to have a successful structured-design approach. For a large project, one person does not usually do all the design work. Several engineers working on the software design must produce end products with the same structure and format. These engineers must be able to communicate with each other in the same terms while doing the design. The programmers implementing the design must understand it completely. Design documents are critical to implementation. If the program works as designed but the design does not meet the functional requirements, it cannot do the job. It might be possible to have a sound design without good documentation. This puts an added burden on the programmers to interpret the design, but if this team has worked together before, it is also possible to produce quality modules and programs from the poor design documentation. Note that there were a lot of 'if's' and 'maybe's' in the previous scenario. For intelligent managers who make long range plans, this could never be the strategy of choice.
4. Implementation The output of the design phase is clear, concise documentation which describes the modules, the hierarchy of the modules and the data flow from module to module. The exact documentation depends upon the method used. The software assignments can now be dispensed among the programming team. Each programmer should
129
now have all the information h e / s h e needs to proceed with h i s / h e r task(s). Because of the modularity, each task is simplified and reduced down to a manageable size. The level of documentation reduces the time it takes to become familiar with the task at hand and reduces team meetings and individual assistance needed. However, if assistance is needed, the senior e n g i n e e r / p r o g r a m m e r can also reduce h i s / h e r familiarization time. This also holds true for software reviews. If no one understands the module, they can hardly comment upon its implementation. Without a clear definition of each module, engineers/programmers would have to take more time out of their schedule to learn other modules before attending a software review or attend but not be able to contribute. Software reviews are one more way to ensure that programmers with related modules are passing the appropriate data.
5. Test Another benefit of the structured approach to software design is that the documentation can be used as source for test plans and procedures. Software undergoing validation must have written test plans, procedures and scripts [7]. With the function of each module and its I / O explicitly defined, a test procedure can be readily developed. An integrated test plan for all the software can be devised from knowing the interaction and data flow between modules. As noted by IEEE, the test approach and data should have been defined in the design phase. The test phase is executing this plan. The author concurs but preferred to describe the creation of the test plans in this section. A structured test methodology calls for a Test Plan, Test Procedure(s), and Test Scripts. A Test Plan is an encompassing and general document which describes the what, how, when, where, and with whom. The Test Plan is concerned with listing what software is to be tested and how, e.g., structural and functional testing of each module then integration testing with groups of modules, then testing all modules together. It specifies
130
M.K. Gruber / I S A Transactions 33 (1994) 125-131
what equipment is used, target system or test hardware. The test bed is described: use of a simulator or hardwired signals. Where the test will take place. The test might be performed in stages: in a computer lab, at a test (staging) facility and at the customer site. Finally, the test plan specifies who will perform the test; this will probably be specified by organization and job title/description, not by name. The Test Procedure is a lower level document; it describes more of the actual testing. Structural testing (also called white box testing) proves the module itself. Structural tests should examine all the paths (not in every combination) and execute every statement at least once, ensuring that there is no 'dead code'. This is done by using test cases with normal values and limits and introducing errors. Functional test (black box test) should be designed to prove that the code is following the specifications. Boundary value analysis would likely be performed during functional test. As mentioned earlier, the module descriptions produced during design are now instrumental in writing the Test Procedures, both for structural and functional test cases. The acceptance criteria is specified. For most software projects which require validation, Test Scripts are created. Test Scripts detail the inputs provided to the test and the outputs expected. The Test Scripts provide a checkoff list as proof of the test and its outcome. In this way the tests are structured so that testing is complete and the end documentation is a byproduct of the test. Once again, the module descriptions should have been written with such detail that the test scripts could be written directly from them. (Note: this author believes that test scripts are necessary for validation but is aware of validation projects where they were not used.) The modular, or structured, method of testing has many advantages. A great deal of the testing can be performed by lower level persons, albeit a design engineer should supervise or verify the results. The test scripts provide most of the documentation; only check marks and signatures to show the tests were performed are needed. Most of the test can take place in a controlled environ-
ment. Although, testing will always need to be done on the target system in its final installed location. Performance Qualification is required by validation; Performance Qualification is composed of actual test runs making product on the installed system. There are those in the industry who believe that all software Operation Qualification testing can be done in the controlled environment leaving only Performance Qualification to be done at site. This is a controversial opinion and not the one of the author of this paper. However, complete structured testing can reduce the amount of (re)testing required at the manufacturing site. Integration testing is still required at site in case there are any design problems, either on the side of the programming firm or equipment manufacturers. The original specifications could be unsound.
6. On-going The design documentation provides a roadmap to the functional pieces of software which also proves useful for future maintenance and possible expansions and enhancements. The end users have a complete set of design documentation. They can easily pinpoint the source of questions or find where to link a new module without searching through thousands of lines of code. If they also have the CASE tool which was used, they can easily do searches and prepare reports. One of the great advantages of structured design is that once a module is designed, written and tested, it is possible to use it again. Many routines are general and can be used in varying applications. However, most firms which write custom application software do specialize in particular industries. A library of completed modules can be kept on file for future projects. Not only are these modules already written but so are their test programs. Again, I must caution the reader that there are documented approaches to validation which would call these modules 'validated modules' and not retest them but provide previous test cases. This is controversial and an F D A inspector might find it objectionable. This author believes that you can count your blessings that
M.K. Gruber /ISA Transactions 33 (1994) 125-131 t h e test scripts a r e w r i t t e n a n d s h o u l d r e t e s t in t h e new e n v i r o n m e n t .
7. Conclusion
S t r u c t u r e d d e s i g n p r o v i d e s t h e simplification of complex problems, producing well-defined software solutions. U s i n g the s t r u c t u r e d a p p r o a c h to t h e design, i m p l e m e n t a t i o n a n d test o f software, quality d o c u m e n t a t i o n is p r o d u c e d . This d o c u m e n t a t i o n is a necessity for the v a l i d a t i o n o f a c o m p u t e r system. T h e b e n e f i t s of using a s t r u c t u r e d d e s i g n app r o a c h a r e s u m m a r i z e d as follows: - p r o v i d e s a m e a n s for u n d e r s t a n d i n g c o m p l e x systems, - p r o v i d e s for c o m m u n i c a t i o n b e t w e e n d e v e l o p ers a n d users, - p r o v i d e s a c l e a r basis for g e n e r a t i o n o f software,
131
- p r o v i d e s source d o c u m e n t s for test p l a n s a n d procedures, -provides b a s e l i n e d o c u m e n t a t i o n for f u t u r e maintenance, - p r o v i d e s built-in quality.
References
[1] Food and Drug Administration, Guideline on the general principles of process validation, May 1987. [2] The Institute of Electrical and Electronics Engineers, "ANSI/IEEE Std 610. 12-1990", IEEE Standard Glossary of Software Engineering Terminology, 1984. [3] T. Parker, "A CASE trio", Computer Language (January 1991). [4] L. Hermens and P. Oman, "Powerful front-end CASE and SQL, too", 1EEE Software (1990). [5] System Architect Language Reference Guides, Popkin Software and Systems Incorporated, 1992. [6] R. Barton et al., CASESU, Barton Group, Inc. [7] C. Hertz, "Case study of a validation of an automated system", ISPE/FDA Conference (16 March 1993) presented.
ELSEVIER
ISA Transactions 33 (1994) 125-131
Use of structured design and development in the validation of application software Megan Klein Gruber Honeywell, Inc., 1100 l,qrginia Drive, Fort Washington, PA 19034, USA
Abstract
The structured design and testing of application software is an important element of GMP compliance. Because application software is custom-developed, one cannot rely on 'market hardness' as an indicator of software quality. Structured design provides a means for understanding complex problems and evaluating system requirements. Communication among users, designers and implementers is facilitated. Valuable and usable documentation is produced. There are many existing CASE tools which can assist in the structured design approach. The many benefits of structured programming toward the end of validation are discussed within this paper. Key words: Structured design; Software; Validation; Testing
1. Introduction
A working definition of validation was given by the Food and Drug Administration in their May 1987 document entitled "Guideline on the general principles of process validation" [1], as follows: Validation Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes. The Food and Drug Administration (FDA) requires that Pharmaceutical and Biotechnological manufacturing facilities validate their processes before goods produced can be distributed for consumption. Many Pharmaceutical and
Biotechnological facilities are installing computers to run their processes. As a result of doing this, the complexity of the validation increases dramatically. Guidelines on performing computer validations, from both the F D A and industry experts, are being updated constantly. The complete validation of a computer-based manufacturing process is a long and involved process. The validation master plan usually consists of: design qualification, installation qualification, operation qualification and performance qualification. To provide ' d o c u m e n t e d evidence', all tasks toward designing, implementing and testing the system must be adequately recorded. Validation of the computer system is only a portion of the entire job. The purpose of this article is to simplify a portion of the task of validation by discussing the
0019-0578/94/$07.00 © 1994 Elsevier Science B.V. All rights reserved SSDI 0019-0578(94)00016-F
126
M.K. Gruber / ISA Transactions 33 (1994) 125-131
role of structured programming in the design, development, documentation and testing of application software.
Concept Phase • Create Validation Protocol • Plan Vendor Audits Requirements Phase • Create Functional Requirements Document • Create Performance Qualification Protocol
2. Overview
The validation of an automated system used in Pharmaceutical or Biotechnological manufacturing involves many areas which need to be qualified individually and as an integrated system. Fig. 1 describes the basic building blocks of an automated system. Application software is one of these blocks. Process validation is a process, itself, which should commence during" the concept phase of the project and continue through the requirements phase, design phase, implementation phase and test phase. (See Fig. 2.) The application software for an average project consists of many programs performing many tasks. Some of the tasks are the same or similar to those in other projects, while other tasks are unique. Most projects involve many engineers and programmers. The tasks of design and implementation are dispensed differently from organization to organization and from project to project. Quite often a change of personnel forces a change in the project responsibilities. The challenge in any organization is to set up a project so that tasks are well-defined and personnel can be easily added or removed as the need arises. Using a structured approach can assist in this goal. With a structured approach to producing software, a large complicated task is reduced to smaller, simpler building blocks. These building blocks, or modules, are easier to design, imple-
NON-COMPUTER HARDWARE
OPERATING PROCEDURES
EQUIPMENT
Fig. 1. The automated system.
Design Phase • Create Loop Drawings and Graphics Hierarchy Conduct Application Software Design Analysis Create Installation Qualification Protocol and Procedures • Create Operation Qualification Protocol and Procedures Implementation Phase • Write Application Software Based Upon Design Analysis Define Test Cases for Application Software Write Standard Operating Procedures and User Manuals Test Phase • Execute and Report: Installation Qualification Execute and Report: Operation Qualification • Execute and Report: Performance Qualification Ongoing Phase - Revalidate System as Required Imlolement Calibration SchedulP. Fig. 2. Key steps in process validation.
ment and test. These modules must be well-defined: function, inputs and outputs. The flow of data to and from each module is essential since these modules do not stand alone. If these design criteria can be achieved, then work assignments can be parcelled out to programmers in an effective manner. Work assignments can be easily changed. Programmer interaction with the designers and other programmers is reduced and simplified. The time to introduce a programmer to the project and get him or her up to speed is reduced. The ability to communicate with the end user is facilitated. There are many other benefits to a structured approach; they will be discussed throughout this paper. However, there is a catch: the approach or methodology used must be adopted by the entire group, department or business unit. There are many published methods of software engineering; Gane and Sarson, Ward and Mellor, and Y o u r d o n / D e M a r c o are among the most well known. Systems-Modeling methods provide a graphical representation of the software design, including the data flow from module to module. These methods step through from the top of the design structure through the interme-
M.K. Gruber / ISA Transactions 33 (1994) 125-131
diate levels of software to the detailed functional level of each module while maintaining a consistent framework. Systems-Modeling helps the designer, implementer and purchaser or end user understand the entire software product and the interactions that must take place to meet the software requirements. Each project team must not be allowed to choose their own software engineering method. If this is done or if team members are forced to learn as they go, the purpose is being defeated. One method must be selected and all programmers, engineers and, perhaps, support staff must be trained in its use. The benefits derived from a structured approach come from understanding. Understanding can only be achieved through training and experience. The greater the understanding, the greater the benefits.
3.
D e s i g n
According to I E E E [2], software design is 'the process of defining the software architecture, components, modules, interfaces, test approach, and test data for a software system according to system requirements'. From this definition, we can surmise that the design phase is where most of the labor for the entire project lies. If the design is done properly, this is true. Software must be designed so that it does what it is supposed to do, no less and no more. Breaking down the function of the task into workable modules requires planning, cross-checking and excellent documentation. A hierarchy of modules is created, each of which must have its function, inputs and outputs completely specified. The modules should not have overlaps or gaps. The outputs of one module must be in the format that is required by the module to which it is an input. Imagine sections of railroad tracks built by two construction crews which not only do not meet but also have a different size of the tracks. The railroad workers needed a sound design and they needed to follow it. Computer Aided Software Engineering (CASE) tools [3-6] were not created for railroad design but can greatly assist software developers in their endeavors.
127
Just as there are many software design or systems-modeling methods, there are also many CASE tools. Most tools support several software design methods. It was mentioned previously that training is the key to successful use of a design methodology. The same is true for a CASE tool. Now the method selection and training are twofold: a method must be selected and employees must be trained in this method and a CASE tool must be selected and the same employees must be trained in the use of the CASE tool for the methodology selected. It is easy to decipher the disadvantages of using a CASE tool: (1) Learning a CASE tool is time-consuming and might be difficult, especially for those unaccustomed to using structured methods. (2) Increased productivity from using the CASE tool may not be realized for months or even years. (3) Enforcement of the use of the CASE tool might be a problem. If structured programming habits are not in place, there might be resistance to the 'new' approach. (4) Most (but not all) CASE tools are expensive and must be purchased per workstation. (5) The end user, which for software houses would be the customer, must be able to understand the documentation produced. If they have no training in the tool, they may not want it used. Many of the aforementioned disadvantages are also disadvantages of using a complex software design methodology. The advantages may not outweigh the disadvantages in every situation. In order to visualize the advantages of CASE tools, we list the diagram types supported: - data flow diagrams, transformation schema (real-time data flow diagrams), entity relationship diagrams, - flow charts, state transition diagrams, structure charts, data model diagrams, data structure diagrams. (Remember: there are many tools and each may not support all the diagram types listed.) -
-
-
128
M.K. Gruber / ISA Transactions 33 (1994) 125-131
The data diagrams or charts provide a layered roadmap to the entire design, showing the relationships among all system elements. Data dictionaries can be produced which textually define the modules. Data dictionaries contain: process definitions, external definitions, data store definitions, and data flow definitions. Reports can provide information based upon a search of set criteria. (Fig. 3, compiled by Leonard Hermens and Paul Oman for their article [4] lists standard reports which can be generated from the CASE tool, System Architect.) The advantages of CASE tools are numerous. The software designer is lifted from his stone tablet and chisel into the computer age. Following are listed some of the CASE tools' advantages: (1) Design entry or diagramming is simplified (once the tool is comprehended). (2) Modifications and additions can be easily integrated. (3) Modules are completely defined. Test scenarios can come directly from these definitions. (4) Customized help text can be configured. STANDARD SYSTEMARCHITECT REPORTS ALL BLANKDEFINITIONDESCRIPTIONS ALL DEFINITIONS AUDIT TRAILBY AUDITID AUDITTRAILBY DATE AUDITTRkJLBY TYPE CHANGE-REQUESTDERNITIONS CHANG6REQUEST/SYMBOLCROSS-REFERENCED CHANGE REQUESTSNOT USED COMMENTSOF SYMBOLS CONTROLFLAGDEFINITIONS CROSSqREFERENCEDATA/EXPRESSION CROSS-REFERENCEI~L~GRAM/SYMEOL CROSS*REFERENCEEXPRESSION/DATA CROSS-REFERENCESYMBOUDIAGRAM CURRENTDIAGRAM DAT/~ELEMENTDEFINITIONS DATA-ELEMENT/EXPRESSIONUSE -REFERENCE DATA ELEMENTSNOT USED DATA ELEMENTSUSED BY DEFINITIONS DATAELEMENTSUSED BY DIAGRAM DATA-EXPRESSIONVALIDATION DATA-FLAGDEFINITIONS DATAFLOWBALANCING:DIAGRAMS DATAFLOWBALANCING : SYM8OLS DATAFLOW-DIAGR~ RULESCHECK CATAELOW-OIAGRAMSYMBOLLIST DATA-STOREDERNITIONS DATA-STRUCTUREDEFINITIONS DATASTRUCTURESNOT USED DATAUSEDBY DIAGRAM(CURRENT) DATABASEDEFINITIONS DEFINITIONL/STiNGBY NAME DEFINITIONLISTINGBY TYPE DEFINITION/ELEMENT CEFINITIONAELEMENT.DEPTH0 DEFINITIONSNOT USED DESCRIPTIONDERNITIONS DESCRIPTIONMETRICS DIAGRAM CONTAINSSYMBOLS DIAGRAMiNPUT DIAGRAMINPUT/OUTPUTLISTS DIAGRAMLEVELNUMBERS
DIAGRAMLISTINGSY TYPE DIAGRAMOUTPUT DIAGRAMS-USECOMPONENTS ELEMENTLIST ENTITYDERNITIONS EXPRESSIONCHECKINGBY SYMBOL EXTERNALDEFINITIONS GLOSSARYDERNITIONS LEVELREFERENCEDIAGRAM/SYMBGL LEVELREFERENCESYMBOL/DIAGRAM MATRIX:A,E,C, EVERYTHINGBY A,B,C, EVERYTHING MATRIX: DATAUSEDBY DEFINITIONS MATRIX: DATAUSEDBY DIAGRAMS MATRIXDERNITION USE DATA MATRIX: DIAGRAMSBY SYMBOLCOUNT MATRIX: REQUIREMENTSVS. DIAGRAMS MATRIX: REQUIREMENTSVS. SYMBOLS MODULEDERNITIONS NAMEUSTING PROCESSDERNITIONS PROCESSINPUT PROCESSINPUT/OUTPUTLISTS PROCESSOUTPUT REQUIREMENTSDEFINITIONS REQUIREMENT/SYMBOLCROSS-REFERENCE REQUIREMENTSNOT USED STATE DERNITIONS STRUCTURE-CHARTRULESCHECK STRtJCTURE~IART SYMI~OLUST SYMBOLUSTINGBY TYPE SYMBOLUSTINGBY NAME SYMBQUCHANGEREQUESTCROSS-REFERENCED SYMBOL~REMENT CROSS-REFERENCED SYMBOL/TEST-PLANCROSS-REFERENCED SYMBOLS-USSDATA(CURRENT) TEST-RAN DERNtTIONS TEST-Pt.AN/SYMBOLCROSS-REFERENCED TEST PLANSNOT USED TRANSITIONDERNITIONS UPDATEALL EXPFtJESSIONS UPDATESYMBOUDERN/TIONRELATIONSHIPS
Fig. 3. Standard system architect reports.
(5) Charts can be searched; this is especially useful to find all places an element is used or a module called in case of modifications. (6) Analysis capabilities can check for errors: labelling, cross-referencing, record and element definitions. Charts can be checked against layout and methodology specific rules for diagram accuracy. (7) Reports can be printed to a printer, screen or file. (8) An audit trail is provided. When changes were made and who made them can be tracked. This is especially useful for validated systems. (9) Quality documentation is produced. The documentation can be printed but also exists in software files which can be searched more readily, allowing the user to 'click' on symbols for definitions or to move around the chart. (Once again note that tool capabilities will vary.) Most of the advantages listed above are documentable or actual reports. This is the key to validation. The second and third words of the F D A definition of validation are 'documented evidence'. CASE tools not only provide utilities to error check design but facilitate the documentation of the results. H o w many times is design documentation for software produced after the fact? Most of us remember doing that in school. The use of CASE tools precludes the need to write documentation as a clean up effort. As with a modeling methodology, the maxim u m benefit from the use of CASE tools can only be realized if every engineer and programmer (and support staff, as applicable) is trained in use of the same tool. Word processors are a good example of this. If each typist used a different word processor, he or she would have no problem doing h i s / h e r own work but would have difficulty finishing a document for s o m e o n e else. One can be proficient in more that one word processor and one can be proficient in more that one CASE tool. However, with the time it takes to learn the tool and the experience level needed to become proficient, there are no apparent advantages to learning multiple tools (for concurrent usage). The more demands there are on the project team, the greater the desire for the members to stick
M.K. Gruber /ISA Transactions 33 (1994) 125-131
with what they know best; if this is not the CASE tool of choice, confusion and frustration may ensue. CASE tools have many advantages but disadvantages were listed, also. Large software projects would reap more benefits from CASE tools than small projects. A software house would more likely find greater benefits from the knowledge and use of a CASE tool than a small in-house programming team. A CASE tool is not necessary to have a successful structured-design approach. Structured programming was being taught long before CASE tools came out on the market. However, a standard methodology is necessary to have a successful structured-design approach. For a large project, one person does not usually do all the design work. Several engineers working on the software design must produce end products with the same structure and format. These engineers must be able to communicate with each other in the same terms while doing the design. The programmers implementing the design must understand it completely. Design documents are critical to implementation. If the program works as designed but the design does not meet the functional requirements, it cannot do the job. It might be possible to have a sound design without good documentation. This puts an added burden on the programmers to interpret the design, but if this team has worked together before, it is also possible to produce quality modules and programs from the poor design documentation. Note that there were a lot of 'if's' and 'maybe's' in the previous scenario. For intelligent managers who make long range plans, this could never be the strategy of choice.
4. Implementation The output of the design phase is clear, concise documentation which describes the modules, the hierarchy of the modules and the data flow from module to module. The exact documentation depends upon the method used. The software assignments can now be dispensed among the programming team. Each programmer should
129
now have all the information h e / s h e needs to proceed with h i s / h e r task(s). Because of the modularity, each task is simplified and reduced down to a manageable size. The level of documentation reduces the time it takes to become familiar with the task at hand and reduces team meetings and individual assistance needed. However, if assistance is needed, the senior e n g i n e e r / p r o g r a m m e r can also reduce h i s / h e r familiarization time. This also holds true for software reviews. If no one understands the module, they can hardly comment upon its implementation. Without a clear definition of each module, engineers/programmers would have to take more time out of their schedule to learn other modules before attending a software review or attend but not be able to contribute. Software reviews are one more way to ensure that programmers with related modules are passing the appropriate data.
5. Test Another benefit of the structured approach to software design is that the documentation can be used as source for test plans and procedures. Software undergoing validation must have written test plans, procedures and scripts [7]. With the function of each module and its I / O explicitly defined, a test procedure can be readily developed. An integrated test plan for all the software can be devised from knowing the interaction and data flow between modules. As noted by IEEE, the test approach and data should have been defined in the design phase. The test phase is executing this plan. The author concurs but preferred to describe the creation of the test plans in this section. A structured test methodology calls for a Test Plan, Test Procedure(s), and Test Scripts. A Test Plan is an encompassing and general document which describes the what, how, when, where, and with whom. The Test Plan is concerned with listing what software is to be tested and how, e.g., structural and functional testing of each module then integration testing with groups of modules, then testing all modules together. It specifies
130
M.K. Gruber / I S A Transactions 33 (1994) 125-131
what equipment is used, target system or test hardware. The test bed is described: use of a simulator or hardwired signals. Where the test will take place. The test might be performed in stages: in a computer lab, at a test (staging) facility and at the customer site. Finally, the test plan specifies who will perform the test; this will probably be specified by organization and job title/description, not by name. The Test Procedure is a lower level document; it describes more of the actual testing. Structural testing (also called white box testing) proves the module itself. Structural tests should examine all the paths (not in every combination) and execute every statement at least once, ensuring that there is no 'dead code'. This is done by using test cases with normal values and limits and introducing errors. Functional test (black box test) should be designed to prove that the code is following the specifications. Boundary value analysis would likely be performed during functional test. As mentioned earlier, the module descriptions produced during design are now instrumental in writing the Test Procedures, both for structural and functional test cases. The acceptance criteria is specified. For most software projects which require validation, Test Scripts are created. Test Scripts detail the inputs provided to the test and the outputs expected. The Test Scripts provide a checkoff list as proof of the test and its outcome. In this way the tests are structured so that testing is complete and the end documentation is a byproduct of the test. Once again, the module descriptions should have been written with such detail that the test scripts could be written directly from them. (Note: this author believes that test scripts are necessary for validation but is aware of validation projects where they were not used.) The modular, or structured, method of testing has many advantages. A great deal of the testing can be performed by lower level persons, albeit a design engineer should supervise or verify the results. The test scripts provide most of the documentation; only check marks and signatures to show the tests were performed are needed. Most of the test can take place in a controlled environ-
ment. Although, testing will always need to be done on the target system in its final installed location. Performance Qualification is required by validation; Performance Qualification is composed of actual test runs making product on the installed system. There are those in the industry who believe that all software Operation Qualification testing can be done in the controlled environment leaving only Performance Qualification to be done at site. This is a controversial opinion and not the one of the author of this paper. However, complete structured testing can reduce the amount of (re)testing required at the manufacturing site. Integration testing is still required at site in case there are any design problems, either on the side of the programming firm or equipment manufacturers. The original specifications could be unsound.
6. On-going The design documentation provides a roadmap to the functional pieces of software which also proves useful for future maintenance and possible expansions and enhancements. The end users have a complete set of design documentation. They can easily pinpoint the source of questions or find where to link a new module without searching through thousands of lines of code. If they also have the CASE tool which was used, they can easily do searches and prepare reports. One of the great advantages of structured design is that once a module is designed, written and tested, it is possible to use it again. Many routines are general and can be used in varying applications. However, most firms which write custom application software do specialize in particular industries. A library of completed modules can be kept on file for future projects. Not only are these modules already written but so are their test programs. Again, I must caution the reader that there are documented approaches to validation which would call these modules 'validated modules' and not retest them but provide previous test cases. This is controversial and an F D A inspector might find it objectionable. This author believes that you can count your blessings that
M.K. Gruber /ISA Transactions 33 (1994) 125-131 t h e test scripts a r e w r i t t e n a n d s h o u l d r e t e s t in t h e new e n v i r o n m e n t .
7. Conclusion
S t r u c t u r e d d e s i g n p r o v i d e s t h e simplification of complex problems, producing well-defined software solutions. U s i n g the s t r u c t u r e d a p p r o a c h to t h e design, i m p l e m e n t a t i o n a n d test o f software, quality d o c u m e n t a t i o n is p r o d u c e d . This d o c u m e n t a t i o n is a necessity for the v a l i d a t i o n o f a c o m p u t e r system. T h e b e n e f i t s of using a s t r u c t u r e d d e s i g n app r o a c h a r e s u m m a r i z e d as follows: - p r o v i d e s a m e a n s for u n d e r s t a n d i n g c o m p l e x systems, - p r o v i d e s for c o m m u n i c a t i o n b e t w e e n d e v e l o p ers a n d users, - p r o v i d e s a c l e a r basis for g e n e r a t i o n o f software,
131
- p r o v i d e s source d o c u m e n t s for test p l a n s a n d procedures, -provides b a s e l i n e d o c u m e n t a t i o n for f u t u r e maintenance, - p r o v i d e s built-in quality.
References
[1] Food and Drug Administration, Guideline on the general principles of process validation, May 1987. [2] The Institute of Electrical and Electronics Engineers, "ANSI/IEEE Std 610. 12-1990", IEEE Standard Glossary of Software Engineering Terminology, 1984. [3] T. Parker, "A CASE trio", Computer Language (January 1991). [4] L. Hermens and P. Oman, "Powerful front-end CASE and SQL, too", 1EEE Software (1990). [5] System Architect Language Reference Guides, Popkin Software and Systems Incorporated, 1992. [6] R. Barton et al., CASESU, Barton Group, Inc. [7] C. Hertz, "Case study of a validation of an automated system", ISPE/FDA Conference (16 March 1993) presented.