6ed-Solutions-Chap13.doc

Systems Analysis and Design in a Changing World, sixth edition

13-1

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

Systems Analysis and Design in a Changing World, sixth edition

13-2

performed by programmers or members of a separate quality assurance group. 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 before hand. 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 hasn’t 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 hasn’t 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.

Systems Analysis and Design in a Changing World, sixth edition

13-3

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

Systems Analysis and Design in a Changing World, sixth edition

13-4

the greatest risk of interrupted service. 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.

Systems Analysis and Design in a Changing World, sixth edition

13-5

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. 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.

Systems Analysis and Design in a Changing World, sixth edition

13-6

2. Assume that you and three of your classmates are charged with developing the first prototype to implement the RMO use case Create/update customer account. Create a development and testing plan to write and test the classes and methods. Assume that you have two weeks to complete all tasks. Answers will vary. (It is not necessary to do it in MS Project, but we show an MS Project solution.) Since this is a prototype, or a first version of only a single use case, it is assumed that only Implementation Activities (ii. e. Core Process 5 Figure 13-1) will be required. Deployment will occur later with other use cases and production versions. This plan will include unit testing and integration testing as much as possible. Start with a WBS. (P1, P2, P3, P4 are persons in the team) Task ID

Description

Effort

Resources

Predecessor

1

Manage environment, code control, documentation

2 days

P1

0

2

Layout, program, and review input screens

3 days

P1

0

3

Unit test input screen

1 day

P1

2

4

Verify fields and build database schema (4 tables)

1 day

P2

0

5

Program methods of 4 classes

5 days

P3, P4

0

6

Unit test 4 methods of 4 classes

2 days

P3, P4

5

7

Identify build test cases for add and update

3 days

P2

4

8

Write support programs to verify database updates

2 days

P2

7

9

Perform integration testing of all components view, logic, data layers.

2 days

P1, P2, P3, P4

1,3,6,8

Systems Analysis and Design in a Changing World, sixth edition

13-7

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. 4. Consider the issue of documenting a system by using only electronic models developed with an integrated development tool, such as Microsoft Visual Studio or Oracle J Developer. The advantages are obvious (e.g., the analyst modifies the models to reflect new requirements and automatically generates an updated system). Are there any disadvantages? (Hint: The system might be maintained for a decade or more.) The system owner is effectively locked into the CASE tool for the life of the system, unless he or she is willing to spend the considerable amount of money required to re-implement the system without the CASE tool. The situation is similar to the problem of extracting data from old sources (for example, data stored in a dBase II file on a 5.25 inch floppy disk). You must maintain appropriate software and hardware to be able to access the data. Without the CASE tool, developers would have to rely on printed output (which may be incomplete or unavailable) and source code stored in ordinary files (if it was ever stored that way). While this may appear acceptable in theory, it is extremely difficult in practice. Source code generated by CASE tools is not intended to be read by the human eye (and there’s considerable incentive for the CASE tool vendor to make it unreadable). Modifying such code is technically but not economically feasible. 5. Talk with an end user at your school or work about the documentation and training provided with a recently installed or distributed business application. What types of training and documentation were provided? Did the user consider the training to be sufficient? Does the user consider the documentation to be useful and complete? Answers will vary. 6. Assume you are in charge of implementation and deployment of a new system that is replacing a critical existing system that is used 24 hours a day. To minimize risk, you plan to phase in deployment of new subsystems over a period of six weeks and operate both systems in parallel for at least three weeks beyond the last new subsystem deployment. Because there aren’t enough personnel to operate both systems, you plan to hire up to 30 temporary workers during the parallel operation period. How should you use the temporary workers? In answering that question be sure to consider these issues: i. Some current personnel will be trained before subsystem deployments, and those employees will train other employees. ii. Employees newly trained on the system will probably not reach their former levels of efficiency for many weeks. Answers will vary, and there are many correct answers. Here are some considerations.

Systems Analysis and Design in a Changing World, sixth edition

13-8

Operating both systems in parallel requires that every transaction, or business process be completed two times – once for the old system and once for the new system. Issues that will affect the approach. 1. Data conversion. It is assumed that there will be a data conversion at the beginning of the parallel. Question: Will there also be a reconversion of the data at the end of the parallel period?  Yes – Then all transactions must be completely done for the old system, and it is less important if there are missed transactions on the new system.  No – Then transactions on the old system can gradually be reduced. The transactions that are processing correctly on the new system can be discontinued on the old. 2. Anticipated error load: Question: Will there be a high number of errors or low error rates?  High – The old system must maintain a complete set of transactions from the work activity.  Low – The old system can gradually be phased out as the new system assumes the work. 3. Employee attrition: Questions: Will there be a substantial number of employees who will not be able to adjust to the new automated system?  Yes – Keep those employees on the old system. Look for temporary staff that may be desirous to hire on.  No – Move employees to the new system as rapidly as possible. Objectives of the parallel testing: 1. The new system should be thoroughly tested with all data at the end of the test period. 2. The company must keep current with the work load. 3. Train as many current employees as possible on the new system. Move them over as rapidly as possible. Approach: 1. Load as many as possible of the temporary people on the old system. Even if it requires 2 or 3 temporary persons to do the job of one full time employee. Leave sufficient current employees to ensure that the work is done with few errors. 2. Move as many people as possible to the new system. This avoids training temporaries on the new system. This uses training time on the new system to train current employees. 3. Move over more current employees as the temporary staff becomes more efficient on the old system.

Systems Analysis and Design in a Changing World, sixth edition

13-9

Solutions to End-of-Chapter Cases Case Study: HudsonBanc Billing System Upgrade Two regional banks with similar geographic territories merged to form HudsonBanc. Both banks had credit card operations and operated billing systems that had been internally developed and upgraded over three decades. The systems performed similar functions, and both operated primarily in batch mode on mainframe computers. Merging the two billing systems was identified as a high-priority cost-saving measure. HudsonBanc initiated a project to investigate how to merge the two billing systems. Upgrading either system was quickly ruled out because the existing technology was considered old and the costs of upgrading the system were estimated to be too high. HudsonBanc decided that a new component-based, Web-oriented system should be built or purchased. Management preferred the purchase option because it was assumed that a purchased system could be brought online more quickly and cheaply. An RFP (request for proposal) was prepared, many responses were received, and after months of business modeling and requirements activities, a vendor was chosen. Hardware for the new system was installed in early January. Software was installed the following week, and a random sample of 10 percent of the customer accounts was copied to the new system. The new system was operated in parallel with the old systems for two months. To save costs involved with complete duplication, the new system computed but didn’t actually print billing statements. Payments were entered into both systems and used to update parallel customer account databases. Duplicate account records were checked manually to ensure that they were the same. After the second test billing cycle, the new system was declared ready for operation. All customer accounts were migrated to the new system in mid-April. The old systems were turned off on May 1, and the new system took over operation. Problems occurred almost immediately. The system was unable to handle the greatly increased volume of transactions. Data entry and customer Web access slowed to a crawl, and payments were soon backed up by several weeks. The system wasn’t handling certain types of transactions correctly (e.g., charge corrections and credits for overpayment). Manual inspection of the recently migrated account records showed errors in approximately 50,000 accounts. It took almost six weeks to adjust the incorrect accounts and update functions to handle all transaction types correctly. On June 20, the company attempted to print billing statements for the 50,000 corrected customer accounts. The system refused to print any information for transactions more than 30 days old. A panicked consultation with the vendor concluded that fixing the 30-day restriction would require more than a month of work and testing. It was also concluded that manual entry of account adjustments followed by billing within 30 days was the fastest and least risky way to solve the immediate problem. Clearing the backlog took two months. During that time, many incorrect bills were

Systems Analysis and Design in a Changing World, sixth edition

13-10

mailed. Customer support telephone lines were continually overloaded. Twenty-five people were reassigned from other operational areas, and additional phone lines were added to provide sufficient customer support capacity. System development personnel were reassigned to IS operations for up to three months to assist in clearing the billing backlog. Federal and state regulatory authorities stepped in to investigate the problems. HudsonBanc agreed to allow customers to spread payments for late bills over three months without interest charges. Setting up the payment arrangements further aggravated the backlog and staffing problems. 1. What type of installation did HudsonBanc use for its new system? Was it an appropriate choice? HudsonBanc used a modified type of parallel deployment of two months. It was a parallel deployment because it supposedly paralleled activity on both systems. However, it was modified because it only did a parallel on 10% of the accounts. The choice was appropriate, but needed to be implemented differently. A direct cut over would not have worked. A phased deployment would probably not have worked well because a billing system is usually a tightly integrated unit. Perhaps some type limited things, such as billing, could have been done in a phased fashion.

2. How could the operational problems have been avoided? Answers will vary. The following steps could possibly have avoided the problems: 1. After the two month 10% parallel, run a complete parallel of all customer accounts for an additional period. 2. Extend the parallel testing time period. Two months was too short. Probably a six month parallel period would be more appropriate. 3. Manual checking of customer accounts is limited. It probably only checks one type of record, and it is subject to manual errors. A programmatic verification of all database records, including customer accounts and transactions should be done. 4. Testing should have been against the existing system, as well as against predicted values. 5. Paralleling the entire customer database would have indicated scaling problems.

Systems Analysis and Design in a Changing World, sixth edition

13-11

Running Cases: Community Board of Realtors Assume that the Multiple Listing Service that is under development will replace an existing system developed many years ago. The database requirements and design for the old and new systems are very similar. Unfortunately, the existing system stores its data in a Microsoft Access database, which provides little support for simultaneous access and updates by multiple users. An important reason for replacing the current system is to upgrade to a DBMS that can easily support many simultaneous accesses. The current plan is to use Microsoft SQL Server as the new DBMS and to migrate all data from the existing Microsoft Access database immediately prior to full deployment. Perform these tasks to prepare for this migration: 1. Investigate data migration from Microsoft Access to SQL Server. What tools are available to assist in or perform the migration? If there are multiple possible tools, which should you use and why? Answers will vary. Microsoft Access Upsizing Wizard Microsoft SQL Server Migration Assistant (SSMA) for various databases ESF Database Migration Toolkit (ESF = EasyFrom) Redevelop the SQL Server from scratch MS Access database systems usually contain both Access Jet Engine database schema and data, as well as Access Front End code for user input forms and output reports. Hence a migration plan will need to include at least the following: 1. Convert database schema 2. Convert database data 3. Convert the macros and code modules (Upsize Wizard does not do this) 4. Convert input forms, output reports, and front end code (Wizard does not do this) 2. Develop plans to test the migration tools/strategy in advance of full deployment. When should the test be performed, and how will you determine whether the test has been “passed”? Answers will vary. Items to include in a test plan: 1. Test the schema conversion – manually review each table and each field type and definition. Also review keys and indexes. 2. Test the the data conversion – programmatically read the data from both databases and do a comparison of data values. The data reads should include simple queries as well as complex joins and read by index values. 3. Compare the insertion of new data records in both databases to ensure that it works the same in both. 4. Test the store procedures (macros and modules) that work within the confines of the database. 5. After the database is converted successfully, then test the interaction between the

Systems Analysis and Design in a Changing World, sixth edition

13-12

database and the applications that use it. Test all applications, test all functions, test all business operations. This is like an extensive systems test. 6. Finally conduct an independent Acceptance Test of all user activity. To know if the migration is successful, the first step is comparing database values between old and new systems. In other words, a parallel type of test. The final success, is the acceptance test that it is performing business operations and processes successfully.

Systems Analysis and Design in a Changing World, sixth edition

13-13

Running Cases: The Spring Breaks 'R' Us Travel Service Review the case-related questions and tasks as well as your responses from Chapters 8 and 9. As described in previous chapters, assume the new system will upgrade an existing system and add new social networking functions to it. Specifically, review your answer to question 2 in Chapter 9 in light of the more detailed understanding of the risks, costs, and benefits of various implementation orders and deployment approaches that you gained by reading this chapter. 1. For each subsystem—Resort relations, Student booking, Accounting and finance, and Social networking— specify which other subsystem(s) it depends on for input data? From Chapter 8 we get the classes in each subsystem. We enhance to show where the original data comes from. In other words, which system has Create and Update responsibility for that class. Subsystems

Classes and subsystem which have Create and Update responsibility.

Resort relations

Resort ← Resort relations Accommodation ← Resort relations Facility ← Resort relations Activity ← Resort relations Traveler ← Student booking TravelerInRoom ← Resort relations Comment (read) ← Social networking

Student booking

Reservation ← Student booking Traveler ← Student booking PersonAccount ← Student booking Group ← Student booking Resort (read) ← Resort relations PaymentTxn ← Account and Finance

Accounting and finance

PaymentTxn ← Accounting PersonAccount (read) ← Student booking Traveler (read) ← Student booking Resort (payments to resorts) ← Resort relations

Social networking

Traveler (read) ← Student booking Group (read) ← Student booking Interest** ← Social networking Comment ← Social networking Resort (read) ← Resort relations TravelerInRoom (read) ← Resort relations Accommodation (read) ← Resort relations Facility (read) ← Resort relations Activity (read) ← Resort relations MultimediaInfo** ← Social networking

Systems Analysis and Design in a Changing World, sixth edition

2. Can the four subsystems be developed and deployed independently? If so, in which order should they be developed and deployed? If not, explain why not and describe how you would develop and deploy the system. Answers will vary. There is a lot of interdependence among the four subsystems. Answers will be some variation of Chapter 8 solution.

13-14

Systems Analysis and Design in a Changing World, sixth edition

13-15

Running Cases: On the Spot Courier Services In Chapter 8, we identified these four subsystems:  Customer account subsystem (such as customer account)  Pickup request subsystem (such as sales)  Package delivery subsystem (such as order fulfillment)  Routing and scheduling subsystem In Chapter 8, you also decided on a development order for these four subsystems, assuming a single two person team. In Chapter 9, you created individual subsystem iteration schedules and a combined project schedule. In Chapter 6, you identified equipment that would be needed for the system. Your assignment for this chapter is to develop a test plan for each subsystem and for the overall project as well as to develop a conversion/deployment schedule. 1. For your test plan, do the following: a. Develop an iteration test plan (i.e., one that applies to and can be used within a subsystem iteration mini-project). Discuss which types of testing (as identified in this chapter) you would include and why. Estimate how much time will be needed for each type of test. Discuss what types of testing might be combined or scheduled with an overlap. Answers will vary. Here are some considerations. From Chapter 9 there are 7 basic iterations defined. We add additional iterations as needed to do final system and performance testing. Let's assume that the approach to building the system is an “organic” approach so that as each new piece is completed, that it is integrated into an every expanding and more comprehensive total system. We can do this, even though we may not begin to deploy the system until the end of the project. The length of the first iteration was defined as 17 days, but with minimal testing defined. Let's assume that iterations normally require 20 days (4 weeks) to 30 days (6 weeks). Within each iteration there will need to be unit tests, usability tests, and integration tests. We will also begin system tests (particularly build and smoke tests) as the project progresses. In other words, as the system grows, we will begin doing early stage system test. Given the testing approach as outlined above, each iteration will require the following tests.  Unit test – Each programmer will test his/her own work. If the programmers are working in pairs, then it is often productive to have the programmer who did NOT write a particular piece of code to test it. Programming teams should attempt to test the code with good data (expected to work), and with bad data (expected to not work). Bad data should be caught and handled correctly. Test cases for these tests is normally very simple transaction input tested with drivers and stubs as explained in the chapter. Each use case should have an extensive unit test. Programmers should test the output (result) from the test. They should also test the intermediate results, including database values and internal data items.  Integration testing – The first iteration should produce a core system with a basic

Systems Analysis and Design in a Changing World, sixth edition

13-16

database schema. This will serve as the starting point for integration testing. During each iteration, as each use case completes its unit test, it should then be integrated into the system. Integration testing is a growing process because the system itself is growing. Test cases for integration testing are more complex because they must include previous components that are already integrated and new components that are just being added. A test bank of test cases should be built and expanded as the system grows. The integration test should verify that existing results, both database values and internal data items, have not be inadvertently modified by the newly integrated code. Integration testing will require more and more effort as the project progresses. Responsibility for integration testing is shared between the programmer who wrote the code, and a team member who is in charge of integration tests. Each iteration should include integration testing for each new use case which is added to the system.  Usability testing – As each new use case is added to the system, and after a successful integration test, a brief usability test is conducted. A small group of users will test specific use cases to see if (1) the business function is supported correctly and accurately, and (2) if the system is user friendly and easy to understand and use. Users who understand the process of system development and testing should be involved in this test. Again, it is done on a use case by use case basis.  Build and Smoke testing – This is a system test of the whole system. It is the first type of system test, and is a direct outgrowth of integration testing. As new components are added, the total system is recompiled (if necessary), and all previous data is tested again. For every iteration a complete build and smoke test will be conducted before the iteration is considered complete. b. Develop a total project test plan to integrate all the subsystems. Discuss which types of testing you would include and why. (Don’t put them on a schedule yet.) As mentioned in part (a), the system will grow with each iteration. Hence integration testing will be done as part of each iteration. Preliminary system testing will be done within each iteration as part of the build and smoke testing that is conducted. However, comprehensive system testing will be done as part of a separate system and acceptance test activity. Given that integration testing and build and smoke testing is done during each iteration, then at the end of the project a testing iteration will be defined to finalize system testing. During this final iteration the following will occur.  System testing – System testing is performed in a test environment on test computers. The total system, including the database, is compiled and linked together. System testing requires that the system be tested with initial transactions that create and initialize data, update transactions that modify and change the data, with delete transactions that remove or deactivate data. Also end-of-period transactions and activity must also be tested to ensure that balances are carried forward, reports are generated, and that the database maintains its integrity and accuracy. Usually several test periods

Systems Analysis and Design in a Changing World, sixth edition

13-17

are defined that simulate day, week, month, and yearly activity. Test cases for system test can be obtained from the integration tests as well as from acceptance test cases. Sometimes test data can be obtained from sampling live data from existing processes.  Acceptance testing – Acceptance testing can be begun within the context of the test environment. However, final acceptance test should be done on the production environment. Primary responsibility for acceptance testing belongs to the users, however, developers can help set up and monitor the tests. Test cases for acceptance test should be derived from live data and it should mirror the actual business processes as much as possible. Acceptance test should also have many of the same characteristics of system test, in that it must cover complete business processes (request, pickup, delivery, payment, etc.) and multiple time periods. Adequate time should be scheduled for acceptance testing. Deployment of systems before they are completely tested is a major cause of headache and pain for the organization.  Stress and performance testing – Performance testing should be done within the context of the production environment. For this system – On the Spot – there does not appear to be the need for extremely high volumes. Package delivery and routing are not frequently occurring activities. Even customer requests for pickup are not high volume for a single metropolitan area or even state. However, issues may arise with the connectivity and telecommunications requirements. Hence performance tests in these areas should be conducted. Again using the production equipment and environment. 2. Develop a conversion/deployment plan. Discuss these: a. Data conversion:Which parts of the data must be saved from the old spreadsheet/manual system? Which parts of the data can just be discarded (i.e., not moved to the new system)? Discuss specific tables that you identified in Chapter 12. The following table identifies database tables that will be required for the new system. It is based on the class diagram developed in Chapter 4. (Chapter 12 case problems did not require a database schema. ) Database table

Conversion requirements

Customer

Yes. Must retrieve from existing customer data

CustomerAccount

Yes. Must retrieve from existing customer data

IndividualCust

Yes. Must retrieve from existing customer data

BusinessCust

Yes. Must retrieve from existing customer data

PickupRequest

No. Old data must be processed, but does not need to go to new system.

Package

No. Old data must be processed, but does not need to go to new system.

RouteTrip

No. Old data must be processed, but does not need to go to new system.

Employee

Probably not in old system. Must create new data.

Systems Analysis and Design in a Changing World, sixth edition

MovementEvent

13-18

No. Old data must be processed, but does not need to go to new system.

Payment Yes. Want to keep records of customer payments. Note: Some data will not be needed in the new system, however, old records should be saved to do statistical and financial analysis. This would include Package and RouteTrip data. b. Deployment: Based on your decisions about which subsystems should be deployed first (Chapter 8 & 9), your overall testing plan, and your data conversion decisions, develop an overall schedule for testing and deployment of the new system. How would you characterize your solution: direct, parallel, or phased conversion? Support your answer by discussing the logic behind your decisions. Answers will vary. Some students may want to do a phased implementation and some may do a parallel implementation. A direct cut over is too risky, even for this small company. A phased implementation might be something like the following (from Chapter 9) Iteration

Subsystem/ Description

No. of Use Cases

Time

Test/Conversion Activities

#1

Customer account

3

4 weeks

Iteration tests

#2

Customer account

2

3 weeks

Iteration tests

#3

Pickup request

5

5 weeks

Iteration tests (including integration)

#4

Package delivery/ Routing

4

4 weeks

Iteration tests (including integration)

New

Data conversion

0

1 week

Data conversion tests

New

System tests

0

2 weeks

New

Acceptance tests

0

2 weeks

Acceptance tests

New

Begin Phased/ Parallel Deployment

0

2 weeks

Parallel comparisons

#5

Routing and scheduling 5

5 weeks

Iteration tests (including integration)

New

System test Routing and 0 Scheduling

1 week

Data creation

New

Acceptance test and phased deployment

0

2 weeks

#6

Administration

4

4 weeks

Iteration tests (including integration)

#7

Administration

4

4 weeks

Iteration tests (including integration)

New

Total system test

0

1 week

New

Total Acceptance test

0

2 weeks

New

Total Parallel

0

2 weeks

Systems Analysis and Design in a Changing World, sixth edition

New

Final deployment

0

13-19

2 weeks

Total time

46 weeks

A parallel conversion might look like the following: Iteration

Subsystem/ Description

No. of Use Cases

Time

Test/Conversion Activities

#1

Customer account

3

4 weeks

Iteration tests

#2

Customer account

2

3 weeks

Iteration tests

#3

Pickup request

5

5 weeks

Iteration tests (including integration)

#4

Package delivery/ Routing

4

4 weeks

Iteration tests (including integration)

#5

Routing and scheduling 5

5 weeks

Iteration tests (including integration)

#6

Administration

4

4 weeks

Iteration tests (including integration)

#7

Administration

4

4 weeks

Iteration tests (including integration)

New

Data Conversion

0

2 weeks

Verify Data conversion

New

System/ performance test

0

4 weeks

Verify all components of the system

New

Acceptance test

0

4 weeks

Verify all functions

New

Begin Parallel operation 0

4 weeks

Verify all operations

Total time

43 weeks

Note: The phased parallel has three disadvantages: First, It will take 3 weeks longer, which is a normal condition. Second, it will require more resources (and expenses) over a longer period of time because more parallel activities are going on. Third, since there is more parallel overlap, more coordination and synchronization will be required to keep the two systems up-to-date. However, it also has two advantages. First, the system is in use earlier, so the organization begins to get the benefits of the new system. Second, the system is tested over a longer period of time, so there also less risk. 3. Revisit your solution in Chapter 6 regarding the types of equipment that will be needed. Include in your discussion your current recommendation for hosting the system. Add to your deployment schedule the activities to purchase equipment and set up the hosting environment. For the phased parallel deployment approach, a separate activity will need to be integrated into the project at about 12 weeks into the project. This activity will purchase and install the necessary equipment (as identified in Chapter 6). For the non-phases, parallel deployment approach a separate activity will need to be integrated

Systems Analysis and Design in a Changing World, sixth edition

13-20

into the project at about 24 or 25 weeks into the project. This activity will purchase and install the necessary equipment (as identified in Chapter 6).

Systems Analysis and Design in a Changing World, sixth edition

13-21

Running Cases: Sandia Medical Devices Refer to the case information provided at the end of Chapters 8 and 9 and the domain class diagram at the end of Chapter 11. Review and update your results from performing the tasks at the end of Chapter 9 based on the information provided in this chapter. Then, answer these questions: 1. What integration and system tests are required, and when should they be incorporated into the iteration schedule? Answers will vary depending on student's plan from Chapter 9. Integration tests should be conducted as part of the iteration test activity. This system has many individual components which send data to other components. In other words, the integration is primarily through sending data as opposed to having program or function calls. Interfaces through APIs and direct program to program communication is not extensive. However, since this system is a life-critical system, it must be thoroughly tested and evaluated to ensure accurate, reliable results. The system must be robust with 100% uptime. System testing options will depend on the deployment method. The following plan does not do any phase deployment. The deployment is essentially a direct deployment since no existing systems are being replaced. The system test is extended (lengthened from the answer in Chapter 9), due to the life-critical nature of the system to ensure that the system works well prior to user acceptance testing. The acceptance test period is lengthy to ensure accuracy and reliability. Iteration

Subsystem

No of use cases

Time

Activities

#1

Patient alert

1

3 weeks

#2

Patient alert

1

2 weeks

begin integration testing

#3

Patient alert

1

2 weeks

unit and integration tests

#4

Patient alert

2

3 weeks

unit and integration tests

#5

Physician alert

3

4 weeks

unit and integration tests

#6

Physician message 2

3 weeks

unit and integration tests

#7

Patient message

3 weeks

unit and integration tests

#8

Integration/ system test

8 weeks

#9

Acceptance test

12 weeks

Total

2

40 weeks

Systems Analysis and Design in a Changing World, sixth edition

13-22

2. What are the documentation and user training requirements for the system, and when should they be incorporated into the iteration schedule? Answers will vary. There are many approaches that will work for this system. Documentation: Since this system requires both hardware and software to be deployed, documentation will need to cover both aspects of the system. How to use the hardware, and how to use the applications. Separate documentation will be required for patients and medical staff.  User (Patient) Documentation: Documentation should be provided on how to attach and initialize the monitoring device, including any buttons, displays, etc. If there are messages that display on the monitoring device, they should be explained. Additional documentation should be provided on the phone application - including how to install it, how to initialize it and how to use it.  User (Medical Staff) Documentation: Documentation should indicate how to install the application on the medical staff computers. Also instructions on how to use the software, including all of the options.  Technical Documentation (Equipment): Both how to initialize and how to check out the equipment. Often equipment will have verification processes to make sure that it is operating correctly. This should be well documented.  Technical Documentation (Applications): How to install and maintain the various software applications on all the equipment. Training should be conducted during the final stages of system test or at the beginning of acceptance test. The medical staff must be trained in the operation and use of the system, including all medical equipment and software. Medical staff must be trained to be able to train patients when they begin to use the devices. The documentation and training material should be created during the integration and system test period. As much as possible the application should be created with user friendly, intuitive menu items and online instructions in order to minimize the need for extra documentation. Obviously, the usability of the system should be an integral part of the design and development of the system.

Systems Analysis and Design in a Changing World, sixth edition

13-23

3. Assume that after deployment and a three-month testing and evaluation period, updates to the first Android-based system (client and server) will be implemented and another client-side version will be implemented for the iPhone. Develop an iteration plan for implementing and deploying the second version of the system. This second project will have two major components. Each will be a different version of the system. 1. Develop and integrate updates and modifications to the Android system. (Version Android-1.2) 2. Develop and integrate the iPhone version. (Version iPhone-1.0) Note: Updating the Andriod system will require new systems analysis to define the new requirements. Developing the iPhone version will be more design and implementation activities and will use the same requirements as previously defined for the Android system. Note: The project to update an existing system can be done either with a “predictive” approach or an “adaptive” approach. Since the updates will tend to be smaller, and will be integrated into an existing and known system, a predictive approach works well. In a predictive approach, the first step is a complete analysis phase to precisely define all the changes across all subsystems. A modified waterfall approach with analysis, design, implementation, and deployment is an acceptable approach.

Systems Analysis and Design in a Changing World, sixth edition

13-24

This plan is for a predictive approach. Predictive Modified Waterfall approach Phase

Activity

Estimated Time

Description

#1

Define new requirements

3 weeks

Analysis activities to determine and document all update requirements. Initial ideas have probably been collected during acceptance test and productive use. This activity refines the requirements into specifications.

#2

Android System Design

2 weeks

Define precisely the changes that need to be made to the Android system

#3

Programming, unit test, and integration testing of new Android version

4 weeks

Make the changes to the new Android version

#4

Deploy Android for Acceptance test

4 weeks

#5

Design iPhone system

2 weeks

This activity can overlap with #3 and #4. If separate developers, e.g. those with Apple programming skills are used for the iPhone system, then #5 can run concurrently with #3. If the same programmers are used, then #5 can run concurrently with #4.

#6

Programming, unit test, and integration testing of iPhone system

4 weeks

The iPhone system is the patient system only, and will interface with the same back-end server and physician system. Using the same data protocols, modifications to the back end should be minimal.

#7

Deploy iPhone for Acceptance test

4 weeks

Testing integration and patient system.

Systems Analysis and Design in a Changing World, sixth edition

13-25

This is a plan for an adaptive approach. Adaptive Iterative approach Iteration Activity

Estimated Time

Description

#1

Patient Alert and messaging modifications for Android

4 weeks

Analysis, design and programming for updates to the Patient alert system.

#2

Physician Alert and messaging modifications for Android

4 weeks

Analysis, design, and programming for updates to Physician alert system.

#3

Android system test

1 weeks

#4

Android Acceptance test

4 weeks

#5

iPhone Patient Alert and messaging system – design and build

4 weeks

#6

iPhone System test

2 weeks

#7

iPhone Acceptance test

4 weeks

Design and implement of iPhone based on same requirements as Android new version. This activity can possibly overlap with #3 and #4. Testing integration and patient system.