CPPS Case Study

13 Making the System Operational

Chapter Outline ▪ Testing

▪ Deployment Activities

▪ Planning and Managing Implementation, Testing, and Deployment

▪ Putting It All Together—RMO Revisited

Learning Objectives After reading this chapter, you should be able to:

▪ Describe implementation and deployment activities

▪ Describe various types of software tests and explain how and why each is used

▪ Explain the importance of configuration management, change management, and source code control to the implementation, testing, and deployment of a system

▪ List various approaches to data conversion and system deployment and describe the advantages and disadvantages of each

▪ Describe training and user support requirements for new and operational systems

OPENING CASE : Tri-State Heating Oil: Juggling Priorities to Begin Operation

It was 8:30 on Monday morning, and Maria Grasso, Kim Song, Dave Williams, and Rajiv Gupta were about to begin the weekly project status meeting. Tri-State Heating Oil had started developing a new scheduling system for customer orders and service calls five months earlier. The target completion date was 10 weeks away, but the project was behind schedule. Early project iterations had accomplished far less than anticipated because key users had disagreed on what new system requirements to include and the system scope was larger than expected.

Maria began the meeting. “We've gained a day or two since our last meeting due to better-than-expected unit testing results,” she said. “All the methods developed last week sailed through unit testing, so we won't need any time this week to fix errors in that code.”

Kim frowned. “I wouldn't get too cocky just yet,” she said. “All the nasty surprises in my last project came during integration testing. We're completing the user interface classes this week, so we should be able to start integration testing with the business classes sometime next week.”

Nodding enthusiastically, Dave said, “That's good! We have to finish testing those user-interface classes as quickly as possible because we're scheduled to start user training in three weeks. I need that time to develop the documentation and training materials and work out the final training schedule with the users.”

Rajiv looked doubtful. “I'm not sure that we should be trying to meet our original training schedule with so much of the system still under development,” he said. “What if integration testing shows major bugs that require more time to fix? And what about the unfinished business and database classes? Can we realistically start training with a system that's little more than a user interface with half a system behind it?”

409

409 410

Systems Analysis and Design in a Changing World, 6th Edition Page 1 of 11

that's little more than a user interface with half a system behind it?”

“But we have to start training in three weeks,” Dave replied. “We contracted for a dozen temporary workers so we could train our staff on the new system. Half of them are scheduled to start in two weeks, and the rest two weeks after that. It's too late to renegotiate their starting dates. We can extend the time they'll be here, but delaying their starting date means we'll be paying for people we aren't using.”

Maria spoke up. “I think that Rajiv's concerns are valid,” she said. “It's not realistic to start training in three weeks with so little of the system completed and tested. We're at least five weeks behind schedule, and there's no way we'll recapture more than four or five days of that during the next few weeks. I've already looked into rearranging some of the remaining coding to give priority to the work most critical to user training. There are a few batch processes that can be back-burnered for a while. Kim, can you rearrange your testing plans to handle all the interactive applications first?”

“I'll have to go back to my office and take another look at the dependencies among those programs,” Kim replied. “Offhand, I'd say yes, but I need a few hours to make sure.”

“Okay,” Maria said. “Let's proceed under the assumption that we can rearrange coding and testing to complete a usable system for training in five weeks. I'll confirm that by e-mail later today, as soon as Kim gets back to me. I'll also schedule a meeting with the CIO to deliver the bad news about temporary staffing costs.”

After a few moments of silence, Rajiv asked, “So, what else do we need to be thinking about?”

Well, let's see, “ Maria replied.” “There's hardware delivery and setup, operating system and DBMS installation, importing data from the old database, the network upgrade, and stress testing for the distributed database accesses.”

Rajiv smiled and said to Maria, “You must have been a juggler in your youth, which would have been good practice for keeping all these project pieces up in the air. Does management pay you by the ball?”

Maria chuckled. “I do think of myself as a juggler sometimes. And if management paid me by the ball, I could retire as soon as this project is finished!”

Overview Developing any complex system is inherently difficult. For example, consider the complexity of manufacturing automobiles. Tens of thousands of parts must be fabricated or purchased. Laborers and machines must assemble those parts into small subcomponents, such as dashboard instruments, wiring harnesses, and brake assemblies, which are in turn assembled into larger subcomponents, such as instrument clusters, engines, and transmissions, which in turn must be constructed, tested, and passed on to subsequent assembly steps. The effort, timeliness, cost, and output quality of each step depend on all the preceding steps.

Implementing and deploying an information system is similar in many ways; it is a complex production and assembly process that must use resources efficiently, minimize construction time, and maximize product quality. But unlike automobile manufacturing, it isn't done once and then used to build thousands of similar units. Instead, implementation and deployment are unique to each project and must match that project's characteristics.

FIGURE 13-1 Activities of the implementation and deployment SDLC core processes

410 411

Systems Analysis and Design in a Changing World, 6th Edition Page 2 of 11

We have spent many chapters detailing the first four core processes of the system development life cycle (SDLC). Those core processes are the primary focus of this text, but additional processes and activities are needed to complete a system and put it to regular use. The core processes and activities covered in this chapter are summarized in Figure 13-1

The fact that we are covering two core processes in a single chapter doesn't mean that they are simple or unimportant. Rather, they are complex processes that you will learn about in detail by completing other courses and reading other books as well as through on-the-job training and experience. Our purpose in covering them in this chapter is to round out our discussion of the SDLC and to show how all the core processes and activities relate to one another.

As you can see from Figure 13-1, program and testing are the primary implementation activities. You will learn about programming in other courses and from other textbooks, so we won't discuss how software components are constructed in this textbook. However, we will discuss testing activities in detail because they are such an integral part of multiple core processes, including project planning and monitoring, design, implementation, and deployment.

Testing Testing activities are a key part of implementation and deployment activities, although different kinds of tests are used in each core process. Testing is the process of examining a component, subsystem, or system to determine its opera tional characteristics and whether it contains any defects. To conduct a test, developers must have well-defined standards for functional and nonfunctional requirements. From the requirements, test developers develop precise definitions of expected operational characteristics and what constitutes a defect. The developers can test software by reviewing its construction and composition or by designing and building the software, exercising its function, and examining the results. If the results indicate a shortcoming or defect, developers cycle back through earlier implementation or deployment activities until the shortcoming is remedied or the defect is eliminated.

Test types, their related core processes, and the defects they detect and operational characteristics they measure are summarized in Figure 13-2 Each type of testing is described in detail later in this section.

FIGURE 13-2 Test types and corresponding operational characteristics and defects

411 412

Systems Analysis and Design in a Changing World, 6th Edition Page 3 of 11

test case a formal description of a starting state, one or more events to which the software must respond, and the expected response or ending state

test data a set of starting states and events used to test a module, group of modules, or entire system

unit test test of an individual method, class, or component before it is integrated with other software

An important part of developing tests is specifying test cases and data. A test case is a formal description of the following:

▪ A starting state

▪ One or more events to which the software must respond

▪ The expected response or ending state

The starting and ending states and the events are represented by a set of test data. For example, the starting state of a system may represent a particular set of data, such as the existence of a particular customer and order for that customer. The event may be represented by a set of input data items, such as a customer account number and order number used to query order status. The expected response may be a described behavior, such as the display of certain information, or a specific state of stored data, such as a canceled order.

Preparing test cases and data is a tedious and time-consuming process. At the component and method levels, every instruction must be executed at least once. Ensuring that all instructions are executed during testing is a complex problem. Fortunately, automated tools based on proven mathematical techniques are available to generate a complete set of test cases. Many test cases repre senting normal and exceptional processing situations should be prepared for each scenario.

Unit Testing Unit testing is the process of testing individual methods, classes, or components before they are integrated with other software. The goal of unit testing is to identify and fix as many errors as possible before modules are combined into larger software units, such as programs, classes, and subsystems. Errors become much more difficult and expensive to locate and fix when many units are combined.

Few units are designed to operate in isolation. Instead, groups of units are designed to execute as an integrated whole. If a method is considered a unit, that method may be called by messages sent from methods in one or more classes and may, in turn, send messages to other methods in its own or other classes. These relationships are easily seen in a sequence diagram, such as in Figure 13-3, which duplicates Figure 11-13. For example, when the class CartItem receives a createCartItem() message, it performs internal processing and sends messages to six other methods—findPromo(), getPrice(), findProdItem(), getDescription(), findlnvItem(), and updateQty()—in three other classes: PromoOffering, ProductItem, and InventoryItem. 412

Systems Analysis and Design in a Changing World, 6th Edition Page 4 of 11

classes: PromoOffering, ProductItem, and InventoryItem.

FIGURE 13-3 Sequence diagram for Create new order

driver a method or class developed for unit testing that simulates the behavior of a method that sends a message to the method being tested

If the createCartItem() method of CartItem is being tested in isolation, then two types of testing methods are required. The first method type is called a driver. A driver simulates the behavior of a method that sends a message to the method being tested—in this example, the call by an OnlineCart object to createCartItem(). A driver module implements these functions:

412 413

413

Systems Analysis and Design in a Changing World, 6th Edition Page 5 of 11

implements these functions:

FIGURE 13-4 Driver module to test createCartItem()

▪ Sets the value of input parameters

▪ Calls the tested unit, passing it the input parameters

▪ Accepts return parameters from the tested unit and prints them, displays them, or tests their values against expected results and then prints or displays the results

Figure 13-4 shows a simple driver module for testing createCartItem(). A more complex driver module might use test data consisting of hundreds or thousands of test inputs and correct outputs stored in a file or database. The driver would loop through the test inputs and repeatedly call createCartItem(), check the return parameter against the expected value, and print or display warnings of any discrepancy. Using a driver allows a subordinate method to be tested before methods that call it have been written.

stub a method or class developed for unit testing that simulates the behavior of a method that hasn't yet been written

integration test test of the behavior of a group of methods, classes, or components

The second type of testing method used to perform unit tests is called a stub. A stub simulates the behavior of a method that hasn't yet been written. A unit test of createCartItem() would require three stub methods: getPrice(), getDescription(), and updateQty(). Stubs are relatively simple methods that usually have only a few executable statements. Each of the stubs used to test createCartItem() can be implemented as a statement that simply returns a

413 414

Systems Analysis and Design in a Changing World, 6th Edition Page 6 of 11

getDescription(), and updateQty(). Stubs are relatively simple methods that usually have only a few executable statements. Each of the stubs used to test createCartItem() can be implemented as a statement that simply returns a constant, regardless of the parameters passed as input. Figure 13-5 shows sample code for each of the three stub modules.

Integration Testing An integration test evaluates the behavior of a group of methods, classes, or components. The purpose of an integration test is to identify errors that weren't or couldn't be detected by unit testing. Such errors may result from a number of problems, including:

▪ Interface incompatibility—For example, one method passes a parameter of the wrong data type to another method.

FIGURE 13-5 Stub modules used by createCartItem()

▪ Parameter values—A method is passed or returns a value that was unexpected, such as a negative number for a price.

▪ Run-time exceptions—A method generates an error, such as “out of mem ory” or “file already in use,” due to conflicting resource needs.

▪ Unexpected state interactions—The states of two or more objects interact to cause complex failures, as when an OnlineCart class method operates correctly for all possible Customer object states except one.

These four problems are some of the most common integration testing errors, but there are many other possible errors and causes.

Once an integration error has been detected, the responsibility for incorrect behavior must be traced to specific method(s). The person responsible for performing the integration test is generally also responsible for identifying the cause of the error. Once the error has been traced to a particular method, the programmer who wrote the method is

414 415

Systems Analysis and Design in a Changing World, 6th Edition Page 7 of 11

method(s). The person responsible for performing the integration test is generally also responsible for identifying the cause of the error. Once the error has been traced to a particular method, the programmer who wrote the method is asked to rewrite it to correct the error.

Integration testing of object-oriented software is very complex. Because an object-oriented program consists of a set of interacting objects that can be created or destroyed during execution, there is no clear hierarchical structure. As a result, object interactions and control flow are dynamic and complex.

Additional factors that complicate object-oriented integration testing include:

▪ Methods can be (and usually are) called by many other methods, and the calling methods may be distributed across many classes.

▪ Classes may inherit methods and state variables from other classes.

▪ The specific method to be called is dynamically determined at run time based on the number and type of message parameters.

▪ Objects can retain internal variable values (i.e., the object state) between calls. The response to two identical calls may be different due to state changes that result from the first call or occur between calls.

This combination of factors makes it difficult to determine an optimal testing order and to predict the behavior of a group of interacting methods and objects. Thus, developing and executing an integration testing plan for object- oriented software is an extremely complex process. Specific methods and techniques for dealing with that complexity are well beyond the scope of this textbook. See the Further Resources section at the end of this chapter for object- oriented software testing references.

Usability Testing

usability test a test to determine whether a method, class, subsystem, or system meets user requirements

system test an integration test of an entire system or independent subsystem

build and smoke test a system test that is performed daily or several times a week

performance test or stress test an integration and usability test that determines whether a system or subsystem can meet time-based performance criteria

response time the desired or maximum allowable time limit for software response to a query or update

throughput the desired or minimum number of queries and transactions that must be processed per minute or hour

A usability test is a test to determine whether a method, class, subsystem, or system meets user requirements. Because there are many types of requirements— functional and nonfunctional—many types of usability tests are performed at many different times.

The most common type of usability test evaluates functional requirements and the quality of a user interface. Users interact with a portion of the system to determine whether it functions as expected and whether the user interface is easy to use. Such tests are conducted frequently, as user interfaces are developed to provide rapid feedback to developers for improving the interface and correcting any errors in the underlying software components.

System, Performance, and Stress Testing A system test is an integration test of the behavior of an entire system or independent subsystem. Integration testing is normally associated with the implementation core process, and system testing is normally associated with the deployment core process. The line separating integration testing from system testing is fuzzy, as is the line between implementation and deployment activities. The important differences are scope and timing. Integration tests are

415 416

Systems Analysis and Design in a Changing World, 6th Edition Page 8 of 11

deployment core process. The line separating integration testing from system testing is fuzzy, as is the line between implementation and deployment activities. The important differences are scope and timing. Integration tests are performed more frequently and on smaller component groups. System tests are performed less frequently on entire systems or subsystems.

For a system developed by using a traditional waterfall SDLC, system testing is concentrated near the end of the project. In a typical iterative project, some deployment activities, including system testing activities, are usually performed at the end of each iteration. In essence, the system is implemented and deployed incrementally.

System testing may also be performed more frequently. A build and smoke test is a system test that is typically performed daily or several times per week. The system is completely compiled and linked (built), and a battery of tests is executed to see whether anything malfunctions in an obvious way (”smokes”).

Build and smoke tests are valuable because they provide rapid feedback on significant integration problems. Any problem that occurs during a build and smoke test must result from software modified or added since the previous test. Daily testing ensures that errors are found quickly and that they can be easily tracked to their sources. Less frequent testing provides rapidly diminishing benefits because more software has changed and errors are more difficult to track to their sources.

A performance test, also called a stress test, determines whether a system or subsystem can meet such time-based performance criteria as response time or throughput. Response time requirements specify desired or maximum allowable time limits for software responses to queries and updates. Throughput requirements specify the desired or minimum number of queries and transactions that must be processed per minute or hour.

Performance tests are complex because they can involve multiple programs, subsystems, computer systems, and network infrastructure. They require a large suite of test data to simulate system operation under normal or maximum load. Diagnosing and correcting performance test failures are also complex. Bottlenecks and underperforming components must first be identified. Corrective actions may include any combination of the following:

▪ Application software tuning or reimplementation

▪ Hardware, system software, or network reconfiguration

▪ Upgrade or replacement of underperforming components

User Acceptance Testing

user acceptance test a system test performed to determine whether the system fulfills user requirements

A user acceptance test is a system test to determine whether the system fulfills user requirements. Acceptance testing may be performed near the end of the project or it may be broken down into a series of tests conducted at the end of each iteration. Acceptance testing is a very formal activity in most development projects. Details of acceptance tests are sometimes included in the request for proposal (RFP) and procurement contract when a new system is built by or purchased from an external party. Customer payments to the developers are often tied to passing specific usability tests.

Deployment Activities Once a new system has been developed and tested, it must be placed into operation. Deployment activities (see Figure 13-6) involve many conflicting constraints, including cost, the need to maintain positive customer relations, the need to support employees, logistical complexity, and overall risk to the organization. User acceptance and other test types were described in the previous section. Multiple types of tests are often performed concurrently because later project iterations typically include implementation and deployment activities. The following sections provide additional details about deployment activities other than testing.

416 417

Systems Analysis and Design in a Changing World, 6th Edition Page 9 of 11

about deployment activities other than testing.

Converting and Initializing Data An operational system requires a fully populated database to support ongoing processing. For example, online order- entry and management functions of the RMO CSMS rely on stored information about products, promotions, customers, and previous orders. Developers must ensure that such information is present in the database at the moment the subsystem becomes operational.

Data needed at system startup can be obtained from these sources:

▪ Files or databases of a system being replaced

▪ Manual records

▪ Files or databases from other systems in the organization

▪ User feedback during normal system operation

Reusing Existing Databases Most new information systems replace or augment an existing manual or automated system. In the simplest form of data conversion, the old system's database is used directly by the new system with little or no change to the database structure. Reusing an existing database is fairly common because of the difficulty and expense of creating new databases from scratch, especially when a single database often supports multiple information systems, as in today's enterprise resource planning (ERP) systems.

FIGURE 13-6 SDLC deployment activities

Although old databases are commonly reused in new or upgraded systems, some changes to database content are usually required. Typical changes include adding new tables, adding new attributes, and modifying existing tables or attributes. Modern database management systems (DBMSs) usually allow database administrators to modify the structure of a fully populated database. Such simple changes as adding new attributes or changing attribute types can be performed entirely by the DBMS.

Reloading Databases More complex changes to database structure may require creating an entirely new database and copying and converting data from the old database to the new database. Whenever possible, utility programs supplied with the DBMS are used to copy and convert the data. In more complex conversions, implementation staff must develop programs to perform the conversion and transfer some or all of the data. The upper portion of Figure 13-7 shows both approaches. In either case, the old database can be discarded once the conversion and transfer process is

417 418

Systems Analysis and Design in a Changing World, 6th Edition Page 10 of 11

programs to perform the conversion and transfer some or all of the data. The upper portion of Figure 13-7 shows both approaches. In either case, the old database can be discarded once the conversion and transfer process is complete.

The middle of Figure 13-7 shows a more complex approach that uses an export utility, an import utility, and a temporary data store. This approach might be employed when the source and target databases employ different database technologies; no utility exists that can directly translate from one to the other, but a “neutral” format exists that can serve as a bridge.

Data from paper records can be entered by using the same programs being developed for the operational system. In that case, data-entry programs are usually developed and tested as early as possible. Initial data entry can be structured as a user training exercise. For greater efficiency, data from paper records can also be scanned into an optical character recognition program and then entered into the database by using custom-developed conversion programs or a DBMS import utility.

FIGURE 13-7 Complex data-conversion example

418

Systems Analysis and Design in a Changing World, 6th Edition Page 11 of 11

In some cases, it may be possible to begin system operation with a partially or completely empty database. For example, a customer order-entry system need not have existing customer information loaded into the database. Customer information could be added the first time a customer places an order, based on a dialog between a telephone order-entry clerk and the customer. Adding data as they are encountered reduces the complexity of data conversion but at the expense of slower processing of initial transactions.

Training Users Training two classes of users—end users and system operators—is an essential part of any system deployment project. End users are people who use the system from day to day to achieve the system's business purpose. System operators are people who perform administrative functions and routine maintenance to keep the system operating. Figure 13-8 shows representative activities for each role. In smaller systems, a single person may fill both roles.

The nature of training varies with the target audience. Training for end users must emphasize hands-on use for specific business processes or functions, such as order entry, inventory control, or accounting. If the users aren't already familiar with those procedures, training must include them. Widely varying skill and experience levels call for at least some hands-on training, including practice exercises, questions and answers, and one-on-one tutorials. Self- paced training materials can fill some of this need, but complex systems also require some face-to-face training. If there is a large number of end users, group training sessions can be used, and a subset of well-qualified end users can be trained and then pass their knowledge on to other users.

System operator training can be much less formal when the operators aren't end users. Experienced computer operators and administrators can learn most or all they need to know by self-study. Thus, formal training sessions may not be required. Also, the relatively small number of system operators makes one on-one training feasible, if it is necessary.

Determining the best time to begin formal training can be difficult. On one hand, users can be trained as parts of the system are developed and tested, which ensures that they hit the ground running. On the other hand, starting early can be frustrating to users and trainers because the system may not be stable or complete. End users can quickly become frustrated when using a buggy, crash-prone system with features and interfaces that are constantly changing.

In an ideal world, training doesn't begin until the interfaces are finalized and a test version has been installed and fully debugged. But the typical end-of-project crunch makes that approach a luxury that is often sacrificed. Instead, training materials are normally developed as soon as the interfaces are reasonably stable, and end-user training begins as soon as possible thereafter. It is much easier to provide training if system interfaces are completed in early project iterations.

FIGURE 13-8 Typical activities of end users and system operators

418 419

419

Systems Analysis and Design in a Changing World, 6th Edition Page 1 of 11

Documentation and other training materials are usually developed before formal user training begins. Documentation can be loosely classified into two types:

system documentation descriptions of system requirements, architecture, and construction details, as used by maintenance personnel and future developers

user documentation descriptions of how to interact with and use the system, as used by end users and system operators

▪ System documentation—descriptions of system requirements, architecture, and construction details

▪ User documentation—descriptions of how to interact with and use the system

Each documentation type is targeted to a different purpose and audience. The purpose of system documentation is to support development activities now and in the future. User documentation is created during implementation. The development team can't create user documentation earlier because many details of the user interface and system operation either haven't yet been determined or may change during development.

System Documentation System documentation serves one primary purpose: providing information to developers and other technical personnel who will build, maintain, and upgrade the system. System documentation is generated throughout the SDLC by each core process and many development activities. System documentation developed during early project iterations guides activities in later iterations, and documen tation developed throughout the SDLC guides future system maintenance and upgrades.

A system deployed for a customer is a collection of computing and network hardware, system software, and application software. Once the system has been developed, separate descriptions of it, such as written text and graphical models, are redundant with the system itself. In the early days of computing, there were few automated tools to support development of analysis and design models and even less support for automating the process of generating application software from those models. Developers in that era faced a recurring dilemma: how to minimize the duplicate effort of updating models and application software while ensuring that the system documentation was always “in sync” with the actual system. In the rush to complete and deploy systems and to maintain and upgrade them over time, system documentation updates were often neglected and documentation was frequently lost. As a result, systems were often scrapped “before their time” because it was cheaper to build a new system than to fix or upgrade a poorly documented existing system.

Modern application development tools and methods have largely solved the system documentation dilemma of earlier times. A modern integrated development environment provides automated tools to support all SDLC core processes. Requirements and design models, such as use case descriptions, class diagrams, and sequence diagrams, are developed by using the development tool and stored in a project library (see Figure 13-9). Changes to one model are automatically synchronized with related models. Application software is often generated in part or in its entirety directly from design models. When application software is altered at a later date, the development tools can “reverse engineer” appropriate changes to the models. Due to these capabilities, system documentation is always complete and in sync with the deployed system, thus simplifying future maintenance and upgrades.

User Documentation User documentation provides ongoing support for end users of the system. It primarily describes routine operation of the system, including such functions as data entry, output generation, and periodic maintenance. Topics typically covered include:

419 420

420

Systems Analysis and Design in a Changing World, 6th Edition Page 2 of 11

covered include:

FIGURE 13-9 System documentation stored within Microsoft Visual Studio

▪ Software startup and shutdown

▪ Keystroke, mouse, or command sequences required to perform specific functions

▪ Program functions required to implement specific business procedures (e.g., the steps followed to enter a new customer order)

▪ Common errors and ways to correct them

For ease of use, user documentation typically includes a table of contents, a general description of the purpose and function of the program or system, a glossary, and an index.

User documentation for modern systems is almost always electronic and is usually an integral part of the application. Most modern operating systems pro vide standard facilities to support embedded documentation. Figure 13-10 shows electronic user documentation of a typical Windows application. The table of contents can be displayed by clicking the book-shaped icon in the top toolbar, and the user can search for specific words or phrases by using the search tool. The center portion of the display shows individual pages of user documentation. The sample page includes embedded glossary definition hyperlinks (in green) and hyperlinks to other documentation pages (in blue).

Knowledge of how to use a system is as important an asset as the system itself. After initial training is completed, that practical knowledge is stored in the minds of end users. But experience such as that is difficult to maintain or effectively transfer to other users. Employee turnover, reassignment, and other factors make direct person-to- person transfer of operational knowledge difficult and uncertain. In contrast, written or electronic documentation is easier to access and far more permanent.

Developing good user documentation requires special skills and considerable time and resources. Writing clearly and concisely, developing effective presentation graphics, organizing information for easy learning and access, and communicating effectively with a nontechnical audience are skills for which there is high demand and limited supply. Development takes time, and high-quality results are achieved only with thorough review and testing. Unfortunately, preparing user documentation is often left to technicians lacking in one or more necessary skills. Also, preparation time, review, and testing are often shortchanged because of schedule overruns and the last-minute

420 421

Systems Analysis and Design in a Changing World, 6th Edition Page 3 of 11

Unfortunately, preparing user documentation is often left to technicians lacking in one or more necessary skills. Also, preparation time, review, and testing are often shortchanged because of schedule overruns and the last-minute rush to tie up all the loose ends of implementation.

FIGURE 13-10 Sample Windows Help and Support display

Configuring the Production Environment Modern applications are built from software components based on interaction standards, such as Common Object Request Broker Architecture (CORBA), Simple Object Access Protocol (SOAP), and Java Platform Enterprise Edition (Java EE). Each standard defines specific ways in which components locate and communicate with one another. Each standard also defines a set of supporting system software to provide needed services, such as maintaining component directories, enforcing security requirements, and encoding and decoding messages across networks and other transport protocols. The exact system software, its hardware, and its configuration requirements vary substantially among the component interaction standards.

Figure 13-11 shows a typical support infrastructure for an application deployed using Microsoft .NET, a variant of SOAP. Application software components written in such programming languages as Visual Basic and C# are stored on one or more application servers. Other required services include a Web server for browser-based interfaces, a database server to manage the database, an Active Directory server to authenticate users and authorize access to information and software resources, a router and firewall, and a server to operate such low-level Internet services as domain naming (DNS) and Internet address allocation (DHCP).

421 422

422

Systems Analysis and Design in a Changing World, 6th Edition Page 4 of 11

domain naming (DNS) and Internet address allocation (DHCP).

FIGURE 13-11 Infrastructure and clients of a typical .NET application

Unless it already exists, all this hardware and system software infrastructure must be acquired, installed, and configured before application software can be installed and tested. In most cases, some or all of the infrastructure will already exist—to support existing information systems. In that case, developers work closely with personnel who administer the existing infrastructure to plan the support for the new system. In either case, this deployment activity typically starts early in the project so software components can be developed, tested, and deployed as they are developed in later project iterations.

Planning and Managing Implementation, Testing, and Deployment The previous sections have discussed the implementation, testing, and deployment activities in isolation. In this section, we concentrate on issues that impact all those activities as well as other core processes, including project planning and monitoring, analysis, and design. In an iterative development project, activities from all core processes are integrated into each iteration and the system is analyzed, designed, implemented, and deployed incrementally. But how does the project manager decide which portions of the system will be worked on in early iterations and which in later iterations? And how does he or she manage the complexity of so many models, components, and tests?

Some of these issues were partly addressed in earlier chapters. But now that you understand implementation, testing, and deployment activities in depth, you can see that there are many interdependencies that must be accounted for. These interdependencies must be fully identified and considered when developing a workable iteration plan. Furthermore, automated tools must be utilized to manage each part of the development project and to ensure maximal coordination across iterations, core processes, and activities.

422 423

423 424

Systems Analysis and Design in a Changing World, 6th Edition Page 5 of 11

across iterations, core processes, and activities.

Development Order One of the most basic decisions to be made about developing a system is the order in which software components will be built or acquired, tested, and deployed. Choosing which portions of the system to implement in which iterations is difficult, and developers must consider many factors, only some of which arise from the software requirements. Some of the other factors discussed in earlier chapters include the need to validate requirements and design decisions and the need to minimize project risk by resolving technical and other risks as early as possible.

A development order can be based directly on the structure of the system itself and its related issues, such as use cases, testing, and efficient use of development staff. Several orders are possible, including:

▪ Input, process, output

▪ Top-down

▪ Bottom-up

Each project must adapt one or a combination of these approaches to specific project requirements and constraints.

Input, Process, Output Development Order

input, process, output (IPO) development order a development order that implements input modules first, process modules next, and output modules last

The input, process, output (IPO) development order is based on data flow through a system or program. Programs or modules that obtain external input are developed first. Programs or modules that process the input (i.e., transform it into output) are developed next. Programs or modules that produce output are developed last. The key issue to analyze is dependency—that is, which classes and methods capture or generate data that are needed by other classes or methods? Dependency information is documented in package diagrams and may also be documented in a class diagram. Thus, either or both diagram types can guide implementation order decisions.

For example, the package diagram in Figure 13-12 shows that the Customer account and Marketing subsystems don't depend on any of the other subsystems. The Sales subsystem depends on the Customer account and Marketing subsystems, and the Order fulfillment and Reporting subsystems depend on the Sales subsystem.

Data dependency among the packages (subsystems) implies data dependency among their embedded classes. Thus, the classes CustomerHandler, Customer, Address, Account, FamilyLink, Message, Suggestion, CustPartnerCredit, PromoPartner, Promotion, PromoOffering, ProductItem, and InventoryItem have no data dependency on the remaining RMO classes. Under the IPO development order, those three classes are implemented first.

The chief advantage of the IPO development order is that it simplifies testing. Because input programs and modules are developed first, they can be used to enter test data for process and output programs and modules. The IPO development order is also advantageous because important user interfaces (e.g., data entry routines) are developed early. User interfaces are more likely to require change during development than during other portions of the system, so early development allows for early testing and user evaluation. If changes are needed, there is still plenty of time to make them. Early development of user interfaces also provides a head start for related activities, such as training users and writing documentation.

A disadvantage of the IPO development order is the late implementation of outputs. Output programs are useful for testing process-oriented modules and programs; analysts can find errors in processing by carefully examining printed reports or displayed outputs. IPO development defers such testing until late in the development phase. However, analysts can usually generate alternate test outputs by using the query-processing or report-writing capabilities of a database management system (DBMS). 424

Systems Analysis and Design in a Changing World, 6th Edition Page 6 of 11

capabilities of a database management system (DBMS).

FIGURE 13-12 Package diagram for the four RMO subsystems

Top-Down and Bottom-Up Development Order

top-down development a development order that implements top-level modules first

bottom-up development a develop ment order that implements low-level detailed modules first

The terms top-down and bottom-up have their roots in traditional structured design and structured programming. A traditional structured design decomposes software into a series of modules or functions, which are hierarchically related to one another. As a visual analogy, consider a typical organization chart with the president or CEO at the top. In structured design, a single module (the president or CEO) controls the entire software program. Modules at the bottom perform low-level specialized tasks when directed to do so by a module at the next higher level. Top- down development begins with the CEO and works downward. Bottom-up development begins with the detailed modules at the lowest level and works upward to the CEO.

Top-down and bottom-up program development can also be applied to object-oriented designs and programs, although a visual analogy isn't obvious with object-oriented diagrams. The key issue is method dependency—that is, which methods call which other methods. Within an object-oriented subsystem or class, method dependency can be examined in terms of navigation visibility, as discussed in Chapters 10 and 11.

424 425

425

Systems Analysis and Design in a Changing World, 6th Edition Page 7 of 11

be examined in terms of navigation visibility, as discussed in Chapters 10 and 11.

FIGURE 13-13 Package diagram for a three-layer object-oriented design

For example, consider the three-layer design of part of the RMO Order entry subsystem shown in Figure 13-13. The arrows connecting packages and classes show navigation visibility requirements. Methods in the view (user interface) layer call methods in the domain layer, which in turn call methods in the data access layer. Top-down implementation would implement the view layer classes and methods first, the domain layer classes and methods next, and the data access layer classes and methods last. Bottom-up implementation would reverse the top-down implementation order.

425 426

Systems Analysis and Design in a Changing World, 6th Edition Page 8 of 11

implementation order.

Method dependency is also documented in a sequence diagram. For example, in Figure 13-3, method dependency is documented in the left-to-right flow of messages among objects. Rotating the figure 90 degrees clockwise creates a top-down and bottom-up visual analogy similar to an organizational chart. Top-down development would proceed through CartHandler, Customer, CustomerDA, OnlineCart, OnlineCartDA, CartItem, CartItemDA, and the set of classes: PromoOffering, PromoOfferingDA, ProductItem, ProductItemDA, InventoryItem, and InventoryItemDA. Bottom-up development would reverse this order, starting with InventoryItem and InventoryItemDA and ending with CartHandler.

The primary advantage of top-down development is that there is always a working version of a program. For example, top-down development in Figure 13-3 would begin with a partial or complete version of the CartHandler class and dummy (or stub) versions of the Customer and OnlineCart classes. This set of classes forms a complete program that can be built, deployed, and executed, although at this point, it wouldn't do very much when executed. As each method or class is implemented, stubs for the methods or classes on the next lower level are added. At every stage of development, the program can be executed and tested, and its behavior becomes more complex and realistic as development proceeds.

The primary disadvantage of top-down development order is that it doesn't use programming personnel very efficiently at the beginning of software development. Development has to proceed through two or three levels before a significant number of classes and methods can be developed simultaneously. In contrast, bottom-up development enables many programmers to be put to work immediately on classes that support a wide variety of use cases. Unfortunately, bottom-up development also requires writing a large number of driver methods to test bottom-level classes and methods, which adds additional complexity to the implementation and testing process. Also, the entire system isn't assembled until the topmost classes are written. Thus, testing for individual use cases and integration testing are delayed.

Other Development Order Considerations IPO, top-down, and bottom-up development are only starting points for creating implementation and iteration plans. Other factors that must be considered include use case-driven development, user feedback, training, documentation, and testing. Use cases deserve special attention in determining development order because they are one of the primary bases for dividing a development project into iterations.

In most projects, developers choose a set of related use cases for a single iteration and complete analysis, design, implementation, and deployment activities. Developers choose which use cases to focus on first based on such factors as minimizing project risk, efficiently using nontechnical staff, or deploying some parts of the system earlier than others. For example, use cases with uncertain requirements or high technical risks are typically addressed in early iterations. Addressing uncertain requirements requires usability and other testing by nontechnical development staff, and those staff members may only be available at certain times in the project.

User feedback, training, and documentation all depend heavily on the user interfaces of the system. Early implementation of user interfaces enables user training and the development of user documentation to begin early in the development process. It also gathers early feedback on the quality and usability of the interface. Note the important role that this issue played in the opening case of this chapter.

Testing is also an important consideration when determining development order. As individual software components are constructed, they must be tested. Programmers must find and correct errors as soon as possible because they become much harder to find and more expensive to fix as components are integrated into larger units. It is important to identify portions of the software that are susceptible to errors and to identify portions of the software where errors can pose serious problems that affect the system as a whole. These portions of the software must be built and tested early, regardless of where they fit within the basic approaches of IPO, top-down, or bottom-up development.

426 427

Systems Analysis and Design in a Changing World, 6th Edition Page 9 of 11

bottom-up development.

Source Code Control

source code control system (SCCS) an automated tool for tracking source code files and controlling changes to those files

Development teams need tools to help coordinate their programming tasks. A source code control system (SCCS) is an automated tool for tracking source code files and controlling changes to those files. An SCCS stores project source code files in a repository, and it acts the way a librarian would—that is, implements check-in and checkout procedures, tracks which programmer has which files, and ensures that only authorized users have access to the repository.

FIGURE 13-14 Project files managed by a source code control system

A programmer checks out a file in read-only mode when he or she wants to examine the code without making changes (e.g., to examine a module's interfaces to other modules). When a programmer needs to make changes to a file, he or she checks out the file in read/write mode. The SCCS allows only one pro grammer to check out a file in read/write mode. The file must be checked back in before another programmer can check it out in read/write mode.

Figure 13-14 shows the source code control display of Microsoft Visual Studio. Various source code files from the RMO CSS are shown in the display. Some files are currently checked out by programmers. For each file checked out in read/write mode, the program lists the programmer who checked it out, the date and time of checkout, and whether the copy currently stored in the central repository is the most current (latest) version.

427 428

Systems Analysis and Design in a Changing World, 6th Edition Page 10 of 11

the copy currently stored in the central repository is the most current (latest) version.

An SCCS prevents multiple programmers from updating the same file at the same time, thus preventing inconsistent changes to the source code. Source code control is an absolute necessity when programs are developed by multiple programmers. It prevents inconsistent changes and automates coordination among programmers and teams. The repository also serves as a common facility for backup and recovery operations.

Packaging, Installing, and Deploying Components As with the other disciplines discussed in this chapter, deployment activities are highly interdependent with activities of the other disciplines. In short, a system or subsystem can't be deployed until it has been implemented and tested. If a system or subsystem is large and complex, it is typically deployed in multiple stages or versions, thus necessitating some formal method of configuration and change management. 428

Systems Analysis and Design in a Changing World, 6th Edition Page 11 of 11

some formal method of configuration and change management.

Important issues to consider when planning deployment include:

▪ Incurring costs of operating both systems in parallel

▪ Detecting and correcting errors in the new system

▪ Potentially disrupting the company and its IS operations

▪ Training personnel and familiarizing customers with new procedures

Different approaches to deployment represent different trade-offs among cost, complexity, and risk. The most commonly used deployment approaches are:

▪ Direct deployment

▪ Parallel deployment

▪ Phased deployment

Each approach has different strengths and weaknesses, and no one approach is best for all systems. Each approach is discussed in detail here.

Direct Deployment

direct deployment or immediate cutover a deployment method that installs a new system, quickly makes it operational, and immediately turns off any overlapping systems

In a direct deployment, the new system is installed and quickly made operational, and any overlapping systems are then turned off. Direct deployment is also sometimes called immediate cutover. Both systems are concurrently operated for only a brief time (typically a few days or weeks) while the new system is being installed and tested. Figure 13-15 shows a timeline for direct deployment.

The primary advantage of direct deployment is its simplicity. Because the old and new systems aren't operated in parallel, there are fewer logistical issues to manage and fewer resources required. The primary disadvantage of direct deployment is its risk. Because older systems aren't operated in parallel, there is no backup in the event that the new system fails. The magnitude of the risk depends on the nature of the system, the cost of workarounds in the event of a system failure, and the cost of system unavailability or less-than-optimal system function.

Parallel Deployment

parallel deployment a deployment method that operates the old and the new systems for an extended time period

In a parallel deployment, the old and new systems are operated for an extended period of time (typically weeks or months). Figure 13-16 illustrates the timeline for parallel deployment. Ideally, the old system continues to operate until the new system has been thoroughly tested and determined to be error-free and ready to operate independently. As a practical matter, the time allocated for parallel operation is often determined in advance and limited to minimize the cost of dual operation.

The primary advantage of parallel deployment is relatively low operational risk. If both systems are operated completely (i.e., using all data and exercising all functions), the old system functions as a backup for the new system. Any failure in the new system can be mitigated by relying on the old system.

428 429

Systems Analysis and Design in a Changing World, 6th Edition Page 1 of 12

system. Any failure in the new system can be mitigated by relying on the old system.

FIGURE 13-15 Direct deployment and cutover

FIGURE 13-16 Parallel deployment and operation

The primary disadvantage of parallel deployment is cost. During the period of parallel operation, the organization pays to operate both systems. Extra costs associated with operating two systems in parallel include:

▪ Hiring temporary personnel or temporarily reassigning existing personnel

▪ Acquiring additional computing and network capacity

429 430

Systems Analysis and Design in a Changing World, 6th Edition Page 2 of 12

▪ Acquiring additional computing and network capacity

▪ Increasing managerial and logistical complexity

Parallel operation is generally best when the consequences of a system failure are severe. Parallel operation substantially reduces the risk of a system failure through redundant operation. The risk reduction is especially important for such “mission critical” applications as customer service, production control, basic accounting functions, and most forms of online transaction processing.

Full parallel operation may be impractical for any number of reasons, including:

▪ Inputs to one system may be unusable by the other, and it may not be possible to use both types of inputs.

▪ The new system may use the same equipment as the old system (e.g., com puters, I/O devices, and networks), and capacity may be insufficient to operate both systems.

▪ Staffing levels may be insufficient to operate or manage both systems at the same time.

When full parallel operation isn't possible or feasible, a partial parallel operation may be employed instead. Possible modes of partial parallel operation include:

▪ Processing only a subset of input data in one of the two systems. The subset could be determined by transaction type, geography, or sampling (e.g., every 10th transaction).

▪ Performing only a subset of processing functions (e.g., updating account history but not printing monthly bills)

▪ Performing a combination of data and processing function subsets

Partial parallel operation always entails the risk that significant errors or problems will go undetected. For example, parallel operation with partial input increases the risk that errors associated with untested inputs won't be discovered.

Phased Deployment

phased deployment a deployment method that installs a new system and makes It operational in a series of steps or phases

In a phased deployment, the system is deployed in a series of steps or phases. Each phase adds components or functions to the operational system. During each phase, the system is tested to ensure that it is ready for the next phase. Phased deployment can be combined with parallel deployment, particularly when the new system will take over the operation of multiple existing systems.

FIGURE 13-17 Phased deployment with direct cutover and parallel operation

430 431

Systems Analysis and Design in a Changing World, 6th Edition Page 3 of 12

Figure 13-17 shows a phased deployment with direct and parallel deployment of individual phases. The new system replaces two existing systems. The deployment is divided into three phases. The first phase is a direct replacement of one of the existing systems. The second and third phases are different parts of a parallel deployment that replace the other existing system.

The primary advantage of phased deployment is reduced risk because fail ure of a single phase is less problematic than failure of an entire system. The primary disadvantage of phased deployment is increased complexity. Dividing the deployment into phases creates more activities and milestones, thus making the entire process more complex. However, each phase contains a smaller and more manageable set of activities. If the entire system is simply too big or complex to install at one time, the reduced risks of phased deployment outweigh the increased complexity inherent in managing and coordinating multiple phases.

Change and Version Control Though not formal activities of the implementation or deployment core processes, change and version control are key parts of managing software development, testing, and deployment. Medium- and large-scale systems are complex and constantly changing. Changes occur rapidly during implementation and more slowly during deployment and after the system is in use. System complexity and rapid change create a host of management problems, particularly for testing and postdeployment support.

Change and version control tools and processes handle the complexity associated with testing and supporting a system through multiple versions. Tools and processes are typically incorporated into implementation activities from the beginning and continue throughout the life of a system. Most organizations use a common set of tools and procedures for all their systems.

Versioning Complex systems are developed, installed, and maintained in a series of versions to simplify testing, deployment, and support. It isn't unusual to have multiple versions of a system deployed to end users and yet more versions in different stages of development. A system version created during development is called a test version. A test version contains a well-defined set of features and represents a concrete step toward final completion of the system. Test versions provide a static system snapshot and a checkpoint to evaluate the project's progress.

alpha version a test version that is incomplete but ready for some level of rigorous integration or usability testing

An alpha version is a test version that is incomplete but ready for some level of rigorous integration or usability testing. Multiple alpha versions may be built depending on the size and complexity of the system. The lifetime of an alpha version is typically short—days or weeks.

beta version a test version that is stable enough to be tested by end users over an extended period of time

A beta version is a test version that is stable enough to be tested by end users over an extended period of time. A beta version is produced after one or more alpha versions have been tested and known problems have been corrected. End users test beta versions by using them to do real work. Thus, beta versions must be more complete and less prone to disastrous failures than alpha versions. Beta versions are typically tested over a period of weeks or months.

production release, release version, or production release a system version that is formally distributed to users or made operational for long-term use

431 432

Systems Analysis and Design in a Changing World, 6th Edition Page 4 of 12

users or made operational for long-term use

maintenance release a system update that provides bug fixes and small changes to existing features

A system version created for long-term release to users is called a production version, release version, or production release. A production version is considered a final product, although software systems are rarely “finished” in the usual sense of that term. Minor production releases (sometimes called maintenance releases) provide bug fixes and small changes to existing features. Major production releases add significant new functionality and may be the result of rewriting an older release from the ground up.

Keeping track of versions is complex. Each version needs to be uniquely identified for developers, testers, and users. In applications designed to run under Windows, users typically view the version information by choosing the About item from the standard Help menu (see Figure 13-18). Users seeking support or reporting errors in a beta or production version use this feature to report the system version to testers or support personnel.

FIGURE 13-18 About box of a typical Windows application

Controlling multiple versions of the same system requires sophisticated version control software, which is often built into development tools or can be obtained through a separate source code and version control system, as described later in this chapter. Programmers and support personnel can extract the current version or any previous version for execution, testing, or modification. Modifications are saved under a new version number to protect the accuracy of the historical snapshot.

Beta and production versions must be stored as long as they are installed on any servers or user machines. Stored versions are used to evaluate future bug reports. For example, when a user reports a bug in version 1.0, support personnel extract that release from the archive and attempt to replicate the user's error. Feedback provided to the user is specific to version 1.0, even if the most recent production release is a higher-numbered version.

Submitting Error Reports and Change Requests To manage the risks associated with change, most organizations adopt formal control procedures for all systems under development and in operation. Formal controls are designed to ensure that potential changes are adequately described, considered, and planned before being implemented and deployed. Typical change control procedures

432 433

Systems Analysis and Design in a Changing World, 6th Edition Page 5 of 12

under development and in operation. Formal controls are designed to ensure that potential changes are adequately described, considered, and planned before being implemented and deployed. Typical change control procedures include these:

▪ Standard reporting methods

▪ Review of requests by a project manager or change control committee

▪ For operational systems, extensive planning for design and implementation

Figure 13-19 shows a sample error (bug) report that has been completed by a tester or system developer. In this case, error reporting is integrated into the application development tool and source code control system, which enables the project manager to centrally manage all reports, assign reports to specific developers, and track each report to its resolution.

FIGURE 13-19 Sample error report in Microsoft Visual Studio

Similar tools can be used to report and manage errors and requests for new features in operational systems. In the case of new features, the request is usually submitted to a change control committee that reviews the change request to assess the impact on existing computer hardware and software, system performance and availability, security, and operating budget. Approved changes are added to the list of pending changes for budgeting, scheduling, planning, and implementation.

433 434

Systems Analysis and Design in a Changing World, 6th Edition Page 6 of 12

scheduling, planning, and implementation.

Implementing a Change Change implementation follows a miniature version of the SDLC. Most of the SDLC activities are performed, although they may be reduced in scope or some times completely eliminated. In essence, a change for a maintenance release is an incremental development project in which the user and technical requirements are fully known in advance. Analysis activities are typically skimmed or skipped, design activities are substantially reduced in scope, and the entire project is typically completed in one or two short iterations.

Planning for a change includes these activities:

▪ Identify what parts of the system must be changed.

▪ Secure resources (such as personnel) to implement the change.

▪ Schedule design and implementation activities.

▪ Develop test criteria and a testing plan for the changed system.

production system the version of the system used from day to day

test system a copy of the production system that is modified to test changes

Whenever possible, changes are implemented and tested on a copy of the operational system. The production system is the version of the system used day to day. The test system is a copy of the production system that is modified to test changes. The test system may be developed and tested on separate hardware or on a redundant system. The test system becomes the operational system only after complete and successful testing.

Putting It All Together—RMO Revisited In a medium-sized or large-scale development project, managers usually feel overwhelmed by the sheer number of activities to be performed, their interde pendencies, and the risks involved. In this section, we give you a glimpse of the interplay among those issues by showing how Barbara Halifax's team developed an iteration plan for RMO's Customer Support System (CSS). But keep in mind that no single example can adequately prepare you to tackle iteration planning for a complex project. That is why iteration planning and other project planning tasks are typically performed by developers with years of experience.

Before reading the rest of this section, you may want to review earlier descriptions of the RMO case in Chapters 2, 3, 4, 6, and 9. Some basic parameters for the project are already described, including subsystem boundaries, project length, and number of iterations.

Chapter 9 describes Barbara's early planning decisions. In this section, she expands on those decisions, makes some changes to her earlier decisions, makes additional key decisions, and develops the revised iteration plan shown in Figure 13-20. The sections that follow describe key issues and decisions that underlie that plan.

Upgrade or Replace? Upgrading the current CSS “in place” was ruled out early in project planning for these reasons:

▪ The current infrastructure is near capacity.

▪ RMO expects to save money by having an external vendor host the CSMS. 434

Systems Analysis and Design in a Changing World, 6th Edition Page 7 of 12

▪ RMO expects to save money by having an external vendor host the CSMS.

FIGURE 13-20 Revised CSMS iteration plan

▪ Existing CSS programs and Web interfaces are a hodgepodge developed over 15 years.

▪ Current system software is several versions out of date.

▪ Infrastructure that supports the current CSS can be repurposed to expand SCM capacity.

In short, it would be too complex to upgrade the current CSS without disrupting operations, and the risks of upgrading old infrastructure and application software are simply too great. By building and deploying an entirely new system, RMO will make a clean break from the existing CSS and its supporting infrastructure. A new hosted

434 435

435

Systems Analysis and Design in a Changing World, 6th Edition Page 8 of 12

upgrading old infrastructure and application software are simply too great. By building and deploying an entirely new system, RMO will make a clean break from the existing CSS and its supporting infrastructure. A new hosted infrastructure will be developed for the CSMS. After the first deployment phase, the existing CSS infrastructure will be updated to match the hosted environment and serve as a test environment for later development and deployment activities.

Phased Deployment to Minimize Risk The schedule described in Chapter 9 didn't call for phased deployment, but neither did it directly consider such deployment issues as database development, data migration, and training. To minimize deployment risks, the CSMS will be deployed in two versions. Version 1.0 will reimplement most of the existing CSS use cases with minimal changes. Version 2.0 will incorporate bug fixes and incremental improvements to version 1.0 and will add additional functionality not present in the CSS, including social networking, feedback/recommendations, business partners, and Mountain Bucks.

The two-phase deployment minimizes project risk by dividing a single large deployment into two smaller deployments. Another key risk mitigation feature is maintaining the current CSS and its database as a backup for at least one iteration after version 1.0 deployment. If a serious problem arises with version 1.0, RMO can revert to the current CSS simply by redirecting Web site accesses back to its internal servers.

Database Development and Data Conversion Many of the classes in the CSMS class diagram are already represented in the existing CSS database. However, there are some new classes and associations and some changes to existing classes. Thus, there is some degree of compatibility between the old and new databases but not enough to enable an upgraded version of the current database to directly interface with both systems. Thus, a new CSMS database will need to be built, and data will need to be migrated from the CSS database prior to deploying version 1.0.

Database development and migration prior to version 1.0 deployment will occur over multiple iterations. The iteration plan calls for creating a copy of the CSS database early in the project and making incremental changes to it. All data in the production CSS database will be migrated to the CSMS database near the end of the fourth iteration. If problems are encountered, they will be resolved and the migration will be repeated as early as possible during the fifth iteration. Migrating much of the data during the fourth iteration will enable fifth-iteration testing of user interfaces with real data from real customers and products and system and stress testing with a “production sized” database.

At the end of the fifth iteration, all CSS database changes since the last full migration will be copied to the CSMS database. Copying only the changes will enable migration within a matter of hours. The CSS system will be offline during the migration. Cutover to the CSMS will occur as soon as the migration is completed. To minimize risk, additional data conversion routines will copy new data from the CSMS database back to the CSS database twice per day during the fifth iteration. If disaster strikes, the CSS can be restarted with a current and complete database. If CSMS version 1.0 passes all user acceptance tests during the fifth iteration, the CSS will be turned off and data migration will cease.

Development Order The IPO development order is the primary basis for the development plan. By starting with a copy of the CSS database, a set of test data will exist from the first iteration, thus enabling the highest risk use cases to be tackled first. These involve the entire Sales subsystem and customer-facing portions of the Order fulfillment subsystem. The risks arise from new technology, uncertainty about requirements, and the operational importance of sales and order fulfillment to RMO. By tackling those use cases first, Barbara allowed her development staff plenty of time to resolve uncertainties and test related software. Note that significant testing of these functions began in iteration 2 and continued through most of the project.

436

436 437

Systems Analysis and Design in a Changing World, 6th Edition Page 9 of 12

continued through most of the project.

Documentation and Training Training activities were spread throughout later project iterations for both production versions. Initial training exercises covered the highest-risk portion of the system prior to deployment. They also enabled developers to do integration and performance testing on the sales-related use cases long before deployment. Additional training continued as new functions were added to the system, providing a gradual ramping up of user skills and developer workload.

Chapter Summary Implementation and deployment are complex processes because they consist of so many interdependent activities. Testing is a key activity of implementation and deployment. Software components must be constructed in an order that minimizes the use of development resources and maximizes the ability to test the system and correct errors. Unfortunately, those two goals often conflict. Thus, a program development plan is a trade-off among available resources, available time, and the desire to detect and correct errors prior to system deployment.

Configuration and change management activities track changes to models and software through multiple system versions, which enables developers to test and deploy a system in stages. Versioning also improves postdeployment support by enabling developers to track problem support to specific system versions. Source code control systems enable development teams to coordinate their work.

Key Terms alpha version 432

beta version 432

bottom-up development 425

build and smoke test 416

direct deployment 429

driver 413

immediate cutover 429

input, process, output (IPO) development order 424

integration test 414

maintenance release 432

parallel deployment 429

performance test 416

phased deployment 430

production system 434

production version, release version, or production release 432

response time 416

source code control system (SCCS) 427

Systems Analysis and Design in a Changing World, 6th Edition Page 10 of 12

source code control system (SCCS) 427

stub 414

system documentation 420

system test 416

test case 412

test data 412

test system 434

throughput 416

top-down development 425

unit testing 412

usability test 416

user acceptance test 417

user documentation 420

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.

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?

3. What is a test case? What are the characteristics of a good test case?

4. What is a driver? What is a stub? With what type of test is each most closely associated?

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.

6. How do user documentation and training activities differ between end users and system operators?

7. List and briefly describe the three basic approaches to program development order. What are the advantages and disadvantages of each?

8. How can the concepts of top-down and bottom-up development order be applied to object-oriented software?

9. What is a source code control system? Why is such a system necessary when multiple programmers build a program or system?

10. Briefly describe direct, parallel, and phased deployments. What are the advantages and disadvantages of each deployment approach?

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?

437 438

Systems Analysis and Design in a Changing World, 6th Edition Page 11 of 12

when an alpha version becomes a beta version or a beta version becomes a production version?

Problems and Exercises 1. Describe the process of testing software developed with the IPO (input, process, output), top-down, and bottom-

up development orders. Which development order results in the fewest resources required for test ing? 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?

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.

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?

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

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?

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

Systems Analysis and Design in a Changing World, 6th Edition Page 12 of 12

weeks.

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 ran dom 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 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?

2. How could the operational problems have been avoided?

RUNNING CASE STUDIES

438 439

Systems Analysis and Design in a Changing World, 6th Edition Page 1 of 4

RUNNING CASE STUDIES

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?

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”?

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 net working —specify which other subsystem(s) it depends on for input data?

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.

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

439 440

Systems Analysis and Design in a Changing World, 6th Edition Page 2 of 4

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.

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

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.

b. Deployment: Based on your decisions about which subsystems should be deployed first (Chapter 8), 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.

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.

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?

2. What are the documentation and user training requirements for the system, and when should they be incorporated into the iteration schedule?

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.

Further Resources Robert V. Binder, Testing Object-Oriented Systems: Models, Patterns, and Tools. Addison-Wesley, 2000.

Mark Fewster and Dorothy Graham, Software Test Automation. Addison-Wesley, 1999.

Jerry Gao, H.-S. Jacob Tsao, and Ye Wu, Testing and Quality Assurance for Component-Based Software, Artech House Publishers, 2003.

William Horton, Designing and Writing Online Documentation: Hypermedia for Self-Supporting Products (2nd edition). John Wiley & Sons, 1994.

William Horton, Designing Web-Based Training: How to Teach Anyone Anything Anywhere Anytime. John Wiley & Sons, 2000.

William Horton, e-Learning by Design. Pfeiffer,

International Association of Information 2011.

440 441

Systems Analysis and Design in a Changing World, 6th Edition Page 3 of 4

International Association of Information 2011.

Technology Trainers (ITrain) Web site, http://itrain.org.

David Yardley, Successful IT Project Delivery. Addison-Wesley, 2002.

Systems Analysis and Design in a Changing World, 6th Edition Page 4 of 4

__MACOSX/Integration and Systems Test/._Chapter 13.pdf