Chapter 13 Making the System Operational

Solutions to End-of-Chapter Problems

Review Questions
1. List and briefly describe each activity of the SDLC core processes Build, test, and integrate system components and Complete system tests and deploy solution. Build, test, and integrate Program the software the programmers write the code Unit test the software the programmers test the code they have programmed Identify and build test cases this requires both project staff and end users. There are often test cases to be used for integration and system test. Additional end user test cases, which uses or simulates live data, are usually more complex. Integrate and test components as components successfully pass unit test, they are integrated into a growing overall system and tested as part of the integrated system. Complete system tests and deploy solution Perform system and stress tests after the components are integrated successfully, then the entire system is tested to test cross functions, cross time periods, and high volumes. Convert existing data if the new system replaces an existing system valid data, such as customer accounts, must be converted to the new database format. Build training materials and conduct training often end user training and perhaps system training is require to ensure that the deployed system runs successfully and that the users can do their work. Deploy the solution install the system on the production servers with the production database and begin using it. 2. Define the terms unit test, integration test, system test, and user acceptance test. During which SDLC activity (or activities) is each test type performed? A unit test is a test of an individual module or method before it is integrated with other modules or methods. An integration test is a test of the behavior of a group of modules or methods. A system test is a test of the behavior of an entire system or independent subsystem. An acceptance test is a system test that determines whether the system fulfills user requirements. An acceptance test is normally performed by or under the direction of users. The programmer or his or her testing buddy usually performs unit testing. Integration and system tests may be performed by programmers or members of a separate quality assurance group.

Chapter 13 Making the System Operational

3. What is a test case? What are the characteristics of a good test case? A test case is a predefined set of data to test a particular function or set of functions. Both the input data and the expected results are normally defined beforehand. Test cases must ensure that all instructions in a program are executed, preferably many times, with a variety of data inputs. 4. What is a driver? What is a stub? With what type of test is each most closely associated? A driver is a module that simulates the calling behavior of a module that hasnt yet been developed. Drivers are most closely associated with unit testing. A stub is a module that simulates the execution or behavior of a module that hasnt yet been developed. Stubs are most closely associated with unit testing. 5. List possible sources of data used to initialize a new system database. Briefly describe the tools and methods used to load initial data into the database. Possible data sources include manual (paper) records, files or databases of a system being replaced, files or databases of other systems in the organization, and manual data entry during training or normal system operation. Tools for initializing database content include normal data entry programs, optical character recognition software, custom-developed data conversion programs, and DBMS import and export utilities. 6. How do user documentation and training activities differ between end users and system operators? Operator documentation and training covers topics, such as system startup and shutdown, backup and recovery, and software installation and upgrade, that are not typically covered in end user documentation. System operators are usually more highly trained than end users, so their documentation often has fewer bells and whistles. System operator training generally omits the business context. The relatively small number of operators usually precludes classroom-based approaches. Relatively high skill and experience levels allow greater use of self-study as a training method. End user training emphasizes hands-on system use to achieve specific business objectives. Training in the business context is as important as training in system specifics. Relatively large numbers of end users allow one-to-many (classroom) training sessions and train-the-trainer approaches. Variation in skills and experience levels necessitate several training methods and materials. End user documentation and training focus on the functions and procedures of the new system. This would include such things as the screens, shortcut keys, sequences of screens, output reports and screens, and menus or navigation paths to access the system functions.

Chapter 13 Making the System Operational

7. List and briefly describe the three basic approaches to program development order. What are the advantages and disadvantages of each? Input-process-output development order Develop the input screens and reports, then the business logic, and finally the output reports and screens. The advantage of this is that testing is easier, because the inputs accept data, which is available when testing the business logic. The disadvantage is that this IPO order may not be the most logical order for integration or use of the system. Since outputs are done last, sometimes it is hard to know if the system is processing the data correctly. Top-down development order This approach develops the controlling modules or controlling methods first. The advantage of this is that the overall program structure is developed first, so that there is a skeleton to add new functions to. This would be an example of a walking skeleton approach. The disadvantage is that it is hard to see what the results of a test are without the detailed workhorse methods coded. It also may not use programmer time effectively since there will only be a few high-level functions that need to be done first. Bottom-up development order This approach develops the detailed workhorse functions and methods first. The advantage is that these methods are tested over and over again as the system is built. However, the disadvantage is that driver methods need to be written to test them. In other words, it is not efficient since so much additional work is required to have a test structure for these low-level methods.

8. How can the concepts of top-down and bottom-up development order be applied to objectoriented software? As implied in the previous question, top-down and bottom-up can be applied to OO because of method dependency. Those methods that call other methods are considered top-level methods. Those methods that do the basic calculations without calling other methods are considered lowlevel methods. 9. What is a source code control system? Why is such a system necessary when multiple programmers build a program or system? A source code control system (SCCS) is an automated tool for tracking source code files and controlling changes to those files. An SCCS prevents multiple programmers from making inconsistent or conflicting changes to source files. An SCCS ensures that a source code file cannot be modified by more than one programmer at a time. 10. Briefly describe direct, parallel, and phased deployments. What are the advantages and disadvantages of each deployment approach? Direct installation installs a new system, quickly makes it operational, and immediately turns off any overlapping systems. Direct installation is the simplest to plan and execute, but it runs the greatest risk of interrupted service.

Chapter 13 Making the System Operational

Parallel installation operates both the old and new systems for an extended period of time. Parallel installation is relatively complex to plan and implement, but it reduces the risk of interrupted service. Phased installation installs a new system and makes it operational in a series of steps or phases. Phased installation breaks up the complexity of planning and execution into manageable pieces, but the total planning and execution effort is greater than with the other methods. 11. Define the terms alpha version, beta version, and production version. Are there well-defined criteria for deciding when an alpha version becomes a beta version or a beta version becomes a production version? An alpha version is a system that is incomplete but ready for some level of rigorous testing. A beta version is a system that is stable enough to be tested by end users. A production version is a system that is formally distributed to users or made operational. Because users test beta versions by using them to do real work, an alpha version must meet the following criteria to become a beta version: the software must be nearly complete, and it must not be susceptible to severe crashes or other productivity-thwarting behaviors. A beta version usually becomes a production version after successful acceptance testing.

Problems and Exercises

1. Describe the process of testing software developed with the IPO (input, process, output), topdown, and bottom-up development orders. Which development order results in the fewest resources required for testing? What types of errors are likely to be discovered earliest under each development order? Which development order is best, as measured by the combination of required testing resources and ability to capture important errors early in the testing process? Software testing under top-down development order starts with an implementation of the topmost module and stubs for each of the second-level modules. One by one, each stub is replaced with a fully implemented module, which is then tested. As each stub is replaced, new stubs must be created for any subordinate modules. The process continues until all of the modules have been fully implemented and tested. Bottom-up development order starts with a driver for one related set of bottom-level modules and the initial implementation of one of the bottom-level modules. After that module is tested, another bottom-level module is created, and the driver is modified to call it (or a new driver is created). After all bottom-level modules in a calling group have been implemented, the driver is replaced with a new module, and a new driver is written to call the new module. Implementation and testing moves up the structure chart in this fashion until all program modules have been implemented and tested.

Chapter 13 Making the System Operational

Under top-down development order, a stub is written once for every module. Under bottom-up development order, a smaller set of drivers is written, but each driver must be updated several times as subordinate modules below it are implemented. In addition, driver modules are generally more complex than stub modules (for example, compare the driver in Figure 15-16 to the stubs in Figure 15-17). Thus, bottom-up development order tends to consume more resources because more effort is expended writing and modifying modules that will be discarded after testing. Top-down development order finds errors in upper-level modules first. These modules typically contain the business logic of the system and integrate the activities of the lower- level modules. Thus, logic and integration errors are found sooner with top-down development order. Bottom-up development order finds errors in the lower-level modules first. These modules typically contain detailed procedural code including data access, I/O formatting, and computations. Thus, errors in those modules are found sooner with bottom-up development. Neither implementation order completely dominates the other when required resources and early error detection are considered. If errors are assumed to be evenly distributed through the structure chart and if they are assumed to be equally fixable regardless of structure chart location, then top-down development order is better due to its lower resource consumption. But many systems have complex procedural, I/O, or data access modules, and discovering errors in those modules early in the development process can save time and testing resources. 3. Talk with a computer center or IS manager about the testing process used with a recently deployed system or subsystem. What types of tests were performed? How were test cases and test data generated? What types of teams developed and implemented the tests? Answers will vary.