Measures a module’s scope and processing characteristics.

CHAPTER 11 Managing Systems Implementation

Chapter 11 describes the systems implementation phase of the SDLC. This chapter describes application development, installation, and evaluation.

OBJECTIVES

When you finish this chapter, you will be able to :

· Explain the importance of software quality assurance and software engineering

· Describe application development using structured, object-oriented, and agile methods

· Draw a structure chart showing top-down design, modular design, cohesion, and coupling

· Explain the coding process

· Explain unit, integration, and system testing

· Differentiate between program, system, operations, and user documentation

· List the main steps in system installation and evaluation

· Develop training plans for various user groups, compare in-house and vendor training options, and describe effective training techniques

· Describe data conversion and changeover methods

· Explain post-implementation evaluation and the final report to management

INTRODUCTION

Managing systems implementation involves application development, testing, documentation, training, data conversion, system changeover, and post-implementation evaluation of the results.

During systems implementation, the system design specification serves as a blueprint for constructing the new system. The initial task is application development, which requires systems analysts and programmers to work together to construct the necessary programs and code modules. Before a changeover, the system must be tested and documented carefully, users must be trained, and existing data must be converted. After the new system is operational, a formal evaluation of the results takes place as part of a final report to management.

If you have MIS CourseMate, you can view a Video Learning Session that explains how to use a structure chart to show program modules and their relationships.

PREVIEW CASE: Mountain View College Bookstore

Background: Wendy Lee, manager of college services at Mountain View College, wants a new information system that will improve efficiency and customer service at the three college bookstores.

In this part of the case, Tina Allen (systems analyst) and David Conroe (student intern) are talking about implementation tasks for the new system.

Participants:

Wendy, Tina, and David

Location:

Wendy Lee’s office, Monday morning, February 10,2014

Project status:

The system design specification was approved, and Tina and David are ready to implement the new bookstore information system.

Discussion topics:

Implementation tasks, including quality assurance, structure charts, testing, training, data conversion process, system changeover, and post-implementation evaluation

Tina:

Good morning, Wendy, We’re ready to start the implementation process, and I’d like to go over our plans, David will be assisting me, so I asked him to join us.

Wendy:

I’m glad you did. I met David during the interviews several months ago.

David:

Hi, Wendy, good to see you again. What’s next?

Tina:

Let’s talk about quality assurance, We’ll also discuss various implementation options, including agile methods, but we’ll continue with a structured approach for now.

Wendy:

Sounds good. What are the major tasks on your list?

Tina:

Well, the biggest task is to translate the design into program code and produce a functioning system. We’ll develop structure charts that the programmers can use as blueprints, and David will help me coordinate with the programmers.

David:

It will be great to see all the design work finally turn into a functioning system.

Tina:

It sure will. Anyway, we’ll proceed to do several types of testing, and we’ll document everything we do When we’re ready, we’ll put the new system into what’s called a test environment until we’re ready to go online with the operational environment.

Wendy:

What about training?

Tina:

We’ll consider several kinds of training — from vendors, or we might do our own.

Wendy:

Then what?

Tina:

The final steps will be data conversion and system changeover. After the new system is up and running, we’ll schedule a formal evaluation and submit a final report. Here’s a task list to get us started:

FIGURE 11-1 Typical systems implementation task list.

© Cengage Learning 2014

SOFTWARE QUALITY ASSURANCE

In today’s competitive business environment, companies are intensely concerned with the quality of their products and services. A successful organization must improve quality in every area, including its information systems. Top management must provide the leadership, encouragement, and support needed for high-quality IT resources

No matter how carefully a system is designed and implemented, problems can occur. Rigorous testing can detect errors during implementation, but it is much less expensive to correct mistakes earlier in the development process. The main objective of quality assurance is to avoid problems or to identify them as soon as possible. Poor quality can result from inaccurate requirements, design problems, coding errors, faulty documentation, and ineffective testing.

To improve the finished product, software systems developers should consider software engineering and internationally recognized quality standards.

Software Engineering

Because quality is so important, you can use an approach called software engineering to manage and improve the quality of the finished system. Software engineering is a software development process that stresses solid design, accurate documentation, and careful testing.

FIGURE 11-2 The Software Engineering Institute represents the cutting edge of software design and development technology.

© 2012 Carnegie Mellon University

The Web site for the Software Engineering Institute (SEI) at Carnegie Mellon University is shown in Figure 11-2. SEI is a leader in software engineering and provides quality standards and suggested procedures for software developers and systems analysts. SEI’s primary objective is to find better, faster, and less-expensive methods of software development. To achieve that goal, SEI designed a set of software development standards called the Capability Maturity Model (CMM)® , which has been used successfully by thousands of organizations around the globe. The purpose of the model was to improve software quality, reduce development time, and cut costs. More recently, SEI established a new model, called Capability Maturity Model Integration (CMMI®) , that integrates software and systems development into a much larger framework called process improvement . The CMMI® regards software as part of a larger quality improvement process, rather than as an end in itself. The CMMI® tracks an organization’s processes, using five maturity levels, from Level 1, which is referred to as unpredictable, poorly controlled, and reactive, to Level 5, in which the optimal result is process improvement. The five maturity levels are shown in Figure 11-3.

International Organization for Standardization (ISO)

What do cars, tools, water, and toys have in common? Along with thousands of other products and services, they are all covered by ISO standards.

You learned in Chapter 9 that the International Organization for Standardization (ISO) is a worldwide body that establishes quality standards for products and services, as shown in Figure 11-4. ISO standards include everything from internationally recognized symbols, such as those shown in Figure 11-5, to the ISBN numbering system that identifies this textbook. In addition, ISO seeks to offer a global consensus of what constitutes good management practices — practices that can help firms deliver consistently high-quality products and services.

FIGURE 11-3 The CMMI® includes five maturity levels, from Level I, which is referred to as unpredictable, poorly controlled, and reactive, to Level 5, in which the optimal result is process improvement.

© 2012 TutorialsPoint.COM

FIGURE 11-4 The International Organization for Standardization (ISO) is an international body that establishes standards for many products and services, including software development. ISO states that standards, which provide product quality, compatibility, and safety, often are taken for granted, and noticed only when they are absent.

© ISO.org

Because software is so important to a company’s success, many firms seek assurance that software systems, either purchased or developed in-house, will meet rigid quality standards. In 2004, ISO updated a set of guidelines called ISO 9000-3:2004, which provided a quality assurance framework for developing and maintaining software. According to ISO, a revision of this standard will be released in 2013.

A company can specify ISO standards when it purchases software from a supplier or use ISO guidelines for in-house software development to ensure that the final result measures up to ISO standards. ISO requires a specific development plan, which outlines a step-by-step process for transforming user requirements into a finished product. ISO standards can be quite detailed. For example, ISO requires that a software supplier document all testing and maintain records of test results. If problems are found, they must be resolved, and any modules affected must be retested. Additionally, software and hardware specifications of all test equipment must be documented and included in the test records.

FIGURE 11-5 ISO standards include internationally recognized symbols.

© bytedust/Shutterstock.com

OVERVIEW OF APPLICATION DEVELOPMENT

Application development is the process of constructing the programs and code modules that serve as the building blocks of the information system. In Chapter 1, you learned that structured analysis, object-oriented (O-O) analysis, and agile methods are three popular development options. Regardless of the method, the objective is to translate the design into program and code modules that will function properly. Because systems implementation usually is very labor-intensive, developers often use project management tools and techniques to control schedules and budgets.

Review the System Design

At this point, it might be helpful to review the tasks involved in the creation of the system design.

· In Chapter 4, you learned about requirements modeling and how to use functional decomposition diagrams (FDDs) to break complex business operations down into smaller units, or functions.

· In Chapter 5, you learned about structured data and process modeling, and you created data flow diagrams (DFDs). You also developed process descriptions for functional primitive processes that documented the business logic and processing requirements.

· In Chapter 6, you developed an object-oriented model of the new system that included use case diagrams, class diagrams, sequence diagrams, state transition diagrams, and activity diagrams.

· In Chapter 7, you selected a development strategy.

· In Chapter 8, you designed the user interface.

· In Chapter 9, you worked with data design issues, analyzed relationships between system entities, and constructed entity-relationship diagrams (ERDs).

· In Chapter 10, you considered an overall system architecture.

Taken together, this set of tasks produced an overall design and a plan for physical implementation.

Application Development Tasks

If you used traditional structured or object-oriented (O-O) methods, you now are ready to translate the design into a functioning application. If you selected an agile development method, you will plan the project, lay the groundwork, assemble the team, and prepare to interact with the customers.

TRADITIONAL METHODS Building a new system requires careful planning. After an overall strategy is established, individual modules must be designed, coded, tested, and documented. A module consists of related program code organized into small units that are easy to understand and maintain. After the modules are developed and tested individually, more testing takes place, along with thorough documentation of the entire system, as shown in Figure 11-6.

When you create program modules using structured or object-oriented methods, you start by reviewing documentation from prior SDLC phases and creating a set of program designs. If you built a documentation file early in the development process and updated it regularly, you now have a valuable repository of information. The centerpiece of your documentation is the system design specification, accompanied by diagrams, source documents, screen layouts, report designs, data dictionary entries, and user comments. If you used a CASE tool during the systems analysis and design process, your job will be much easier. At this point, coding and testing tasks begin. Although programmers typically perform the actual coding, IT managers usually assign systems analysts to work with them as a team.

AGILE METHODS If you decided to use an agile approach, intense communication and collaboration will now begin between the IT team and the users or customers. The objective is to create the system through an iterative process of planning, designing, coding, and testing. Agile projects use various models, including the spiral model, or the Extreme Programming (XP) example shown in Figure 11-7 on the next page. Agile development and XP are discussed in detail later in this chapter.

FIGURE 11-6 The main steps in application development.

© Cengage Learning 2014

FIGURE 11-7 Simplified model of an Extreme Programming (XP) project. Note the emphasis on iteration and testing.

© Cengage Learning 2014

Systems Development Tools

Each systems development approach has its own set of tools that has worked well for that method. For example, structured development relies heavily on DFDs and structure charts; object-oriented methods use a variety of diagrams, including use case, class, sequence, and transition state diagrams; and agile methods tend to use spiral or other iterative models such as the example in Figure 11-7.

System developers also can use multipurpose tools to help them translate the system logic into properly functioning program modules. These generic tools include entity-relationship diagrams, flowcharts, pseudocode, decision tables, and decision trees.

ENTITY-RELATIONSHIP DIAGRAMS During data design, in Chapter 9, you learned how to use entity-relationship diagrams to show the interaction among system entities and objects. An ERD is a useful tool regardless of which methodology you are using, because the various relationships (one-to-one, one-to-many, and many-to-many) must be understood and implemented in the application development process.

FLOWCHARTS As you learned in Chapter 5, flowcharts can be used to describe program logic, and are very useful in visualizing a modular design. A flowchart represents logical rules and interaction graphically, using a series of symbols connected by arrows. Using flowcharts, programmers can break large systems into subsystems and modules that are easier to understand and code.

PSEUDOCODE Pseudocode is a technique for representing program logic. Pseudocode is similar to structured English, which was explained in Chapter 5. Pseudocode is not language-specific, so you can use it to describe a software module in plain English without requiring strict syntax rules. Using pseudocode, a systems analyst or a programmer can describe program actions that can be implemented in any programming language. Figure 11-8 illustrates an example of pseudocode that documents a sales promotion policy.

FIGURE 11-8 Sample of a sales promotion policy with logical rules, and a pseudocode version of the policy. Notice the alignment and indentation of the logic statements.

© Cengage Learning 2014

DECISION TABLES AND DECISION TREES As you learned in Chapter 5, decision tables and decision trees can be used to model business logic for an information system. In addition to being used as modeling tools, analysts and programmers can use decision tables and decision trees during system development, as they develop code modules that implement the logical rules. Figure 11-9 shows an example of a decision tree that documents the sales promotion policy shown in Figure 11-8. Notice that the decision tree accurately reflects the sales promotion policy, which has three separate conditions, and four possible outcomes.

Project Management

Regardless of whether structured analysis, object-oriented design, or agile methods are used, even a modest-sized project might have hundreds or even thousands of modules. For this reason, application development can become quite complex and difficult to manage. At this stage, project management is especially important. Users and managers are looking forward to the new system, and it is very important to set realistic schedules, meet project deadlines, control costs, and maintain quality. To achieve these goals, the systems analyst or project manager should use project management tools and techniques similar to those described in Chapter 3 to monitor and control the development effort.

FIGURE 11-9 Sample decision tree that reflects the sales promotion policy in Figure 11-8. Like a decision table, a decision tree shows the action to be taken based on certain conditions.

© Cengage Learning 2014

The following sections describe the application development process. Structured development techniques and tools are discussed first, followed by object-oriented and agile development methods.

Video Learning Session Structure Charts

© craftvision/iStockphoto

If you have an MIS CourseMate access code, you can launch interactive Video Learning Sessions to help you understand systems development concepts and practice your skills. You can watch the sessions on your computer or mobile device, and pause, rewind, or replay a video at any time. To log on to the MIS CourseMate site at www.cengagebrain.com , you must create a student account and then register this book.

This session is about structure charts. You’ll learn what a structure chart is and how you can use a structure chart to show program modules and their relationships.

STRUCTURED APPLICATION DEVELOPMENT

Structured application development usually involves a top-down approach , which proceeds from a general design to a detailed structure. After a systems analyst documents the system’s requirements, he or she breaks the system down into subsystems and modules in a process called partitioning . This approach also is called modular design and is similar to constructing a leveled set of DFDs. By assigning modules to different programmers, several development areas can proceed at the same time. As explained in Chapter 3, you can use project management software to monitor work on each module, forecast overall development time, estimate required human and technical resources, and calculate a critical path for the project.

Because all the modules must work together properly, an analyst must proceed carefully, with constant input from programmers and IT management to achieve a sound, well-integrated structure. The analyst also must ensure that integration capability is built into each design and thoroughly tested.

Structure Charts

Structure charts show the program modules and the relationships among them. A structure chart consists of rectangles that represent the program modules, with arrows and other symbols that provide additional information. Typically, a higher-level module, called a control module , directs lower-level modules, called subordinate modules . In a structure chart, symbols represent various actions or conditions. Structure chart symbols represent modules, data couples, control couples, conditions, and loops.

MODULE A rectangle represents a module, as shown in Figure 11-10. Vertical lines at the edges of a rectangle indicate that module 1.3 is a library module. A library module is reusable code and can be invoked from more than one point in the chart.

DATA COUPLE An arrow with an empty circle represents a data couple. A data couple shows data that one module passes to another. In the data couple example shown in Figure 11-11, the LOOK UP CUSTOMER NAME module exchanges data with the MAINTAIN CUSTOMER DATA module.

FIGURE 11-10 An example of structure chart modules.

© Cengage Learning 2014

FIGURE 11-11 An example of a structure chart data.

© Cengage Learning 2014

CONTROL COUPLE An arrow with a filled circle represents a control couple. A control couple shows a message, also called a status flag , which one module sends to another. In the example shown in Figure 11-12, the UPDATE CUSTOMER FILE module sends an ACCOUNT OVERDUE flag back to the MAINTAIN CUSTOMER DATA module. A module uses a flag to signal a specific condition or action to another module.

CONDITION A line with a diamond on one end represents a condition. A condition line indicates that a control module determines which subordinate modules will be invoked, depending on a specific condition. In the example shown in Figure 11-13, SORT INVENTORY PARTS is a control module with a condition line that triggers one of the three subordinate modules.

LOOP A curved arrow represents a loop. A loop indicates that one or more modules are repeated. In the example shown in Figure 11-14 on the next page, the GET STUDENT GRADES and CALCULATE GPA modules are repeated.

FIGURE 11-12 An example of a structure chart control couple.

© Cengage Learning 2014

FIGURE 11-13 The diagram shows a control module that triggers three subordinate modules.

© Cengage Learning 2014

Cohesion and Coupling

Cohesion and coupling are important tools for evaluating the overall design. As explained in the following sections, it is desirable to have modules that are highly cohesive and loosely coupled.

Cohesion measures a module’s scope and processing characteristics. A module that performs a single function or task has a high degree of cohesion, which is desirable. Because it focuses on a single task, a cohesive module is much easier to code and reuse. For example, a module named VERIFY CUSTOMER NUMBER is more cohesive than a module named CALCULATE AND PRINT STATEMENTS. If you notice the word and in a module name, you know that more than one task is involved.

FIGURE 11-14 The diagram shows a structure chart loop with two repeating modules.

© Cengage Learning 2014

If a module must perform multiple tasks, more complex coding is required and the module will be more difficult to create and maintain. If you need to make a module more cohesive, you can split it into separate units, each with a single function. For example, by splitting the module CHECK CUSTOMER NUMBER and CREDIT LIMIT in Figure 11-15 into two separate modules, CHECK CUSTOMER NUMBER and CHECK CUSTOMER CREDIT LIMIT, cohesion is greatly improved.

Coupling describes the degree of interdependence among modules. Modules that are independent are loosely coupled , which is desirable. Loosely coupled modules are easier to maintain and modify, because the logic in one module does not affect other modules. If a programmer needs to update a loosely coupled module, he or she can accomplish the task in a single location. If modules are tightly coupled , one module is linked to internal logic contained in another module. For example, Module A might refer to an internal variable contained in Module B. In that case, a logic error in the Module B will affect the processing in Module A. For that reason, passing a status flag down as a message from a control module is generally regarded as poor design. It is better to have subordinate modules handle processing tasks as independently as possible, to avoid a cascade effect of logic errors in the control module.

In Figure 11-16, the tightly coupled example on the left shows that the subordinate module CALCULATE CURRENT CHARGES depends on a status flag sent down from the control module UPDATE CUSTOMER BALANCE. It would be preferable to have the modules loosely coupled and logically independent. In the example on the right, a status flag is not needed because the subordinate module APPLY DISCOUNT handles discount processing independently. Any logic errors are confined to a single location: the APPLY DISCOUNT module.

FIGURE 11-15 Two examples of cohesion. Notice that the single module on the left is less cohesive than the two modules on the right.

© Cengage Learning 2014

FIGURE 11-16 An example of tightly coupled and loosely coupled structure charts.

© Cengage Learning 2014

Drawing a Structure Chart

If you used a structured analysis method, your structure charts will be based on the DFDs you created during data and process modeling.

Typically, you follow four steps when you create a structure chart. You review DFDs to identify the processes and methods, identify the program modules and determine control-subordinate relationships, add symbols for couples and loops, and analyze the structure chart to ensure that it is consistent with your system documentation.

STEP 1: REVIEWTHE DFDS Your first step is to review all DFDs for accuracy and completeness, especially if changes have occurred since the systems analysis phase. If object models also were developed, you should analyze them to identify the objects, the methods that each object must perform, and the relationships among the objects. A method is similar to a functional primitive, and requires code to implement the necessary actions.

STEP 2: IDENTIFY MODULES AND RELATIONSHIPS Working from the logical model, you transform functional primitives or object methods into program modules. When analyzing a set of DFDs, remember that each DFD level represents a processing level. If you are using DFDs, you would work your way down from the context diagram to the lower-level diagrams, identifying control modules and subordinate modules, until you reach functional primitives. If more cohesion is desired, you can divide processes into smaller modules that handle a single task. Figure 11-17 on the next page shows a structure chart based on the order system shown in Figures 5-16, 5-17, and 5-18 on pages 196–198. Notice how the three-level structure chart relates to the three DFD levels.

STEP 3: ADD COUPLES, LOOPS, AND CONDITIONS Next, you add couples, loops, and conditions to the structure chart. If you are working with DFDs, you can review the data flows and the data dictionary to identify the data elements that pass from one module to another. In addition to adding the data couples, you add control couples where a module is sending a control parameter, or flag, to another module. You also add loops and condition lines that indicate repetitive or alternative processing steps, as shown in Figure 11-17. If you also developed an object model, you can review the class diagrams and object relationship diagrams to be sure that you understand the interaction among the objects.

FIGURE 11-17 A structure chart based on the order system DFDs on pages 196–198.The three-level structure chart relates to the three DFD levels.

© Cengage Learning 2014

STEP 4: ANALYZE THE STRUCTURE CHART AND THE DATA DICTIONARY At this point, the structure chart is ready for careful analysis. You should check each process, data element, or object method to ensure that the chart reflects all previous documentation and that the logic is correct. You also should determine that modules are strongly cohesive and loosely coupled. Often, you must draw several versions of the chart. Some CASE tools can help you analyze the chart and identify problem areas.

OBJECT-ORIENTED APPLICATION DEVELOPMENT

When you studied the object-oriented methods described in Chapter 6, you learned that O-O analysis makes it easier to translate an object model directly into an object-oriented programming language. This process is called object-oriented development , or OOD . Although many structured design concepts also apply to object-oriented methodology, there are some differences.

Characteristics of Object-Oriented Application Development

When implementing a structured design, a structure chart is used to describe the interaction between program modules, as explained earlier. In contrast, when implementing an object-oriented design, relationships between objects already exist. Because object interaction is defined during the O-O analysis process, the application’s structure is represented by the object model itself.

As Chapter 6 explains, objects contain both data and program logic, called methods. Individual object instances belong to classes of objects with similar characteristics. The relationship and interaction among classes are described using a class diagram, such as the one shown in Figure 11-18. A class diagram includes the class attributes , which describe the characteristics of objects in the class, and methods , which represent program logic. For example, the CUSTOMER class describes customer objects. CUSTOMER attributes include NUMBER, NAME, ADDRESS, and so on. Methods for the CUSTOMER class include PLACE ORDER, MODIFY ORDER, and PAY INVOICE, among others. The CUSTOMER class can exchange messages with the ORDER class.

In addition to class diagrams, programmers get an overview of object interaction by using object relationship diagrams that were developed during the O-O analysis process. For example, Figure 11-19 shows an object relationship diagram for a fitness center. Notice that the model shows the objects and how they interact to perform business functions and transactions.

FIGURE 11-18 A simplified class diagram for a customer order processing system.

© Cengage Learning 2014

FIGURE 11-19 An object-relationship diagram for a fitness center.

© Cengage Learning 2014

Properly implemented, object-oriented development can speed up projects, reduce costs, and improve overall quality. However, these results are not always achieved. Organizations sometimes have unrealistic expectations, and do not spend enough time learning about, preparing for, and implementing the OOD process. For example, no one would build a bridge without a analysis of needs, supporting data, and a detailed blueprint — and the bridge would not be opened for traffic until it had been carefully inspected and checked to ensure that all specifications were met. O-O software developers sometimes forget that the basic rules of architecture also apply to their projects.

In summary, to secure the potential benefits of object-oriented development, systems analysts must carefully analyze, design, implement, test, and document their O-O projects.

Implementation of Object-Oriented Designs

When a programmer translates an object-oriented design into an application, he or she analyzes the classes, attributes, methods, and messages that are documented in the object model. During this process, the programmer makes necessary revisions and updates to class diagrams, sequence diagrams, state transition diagrams, and activity diagrams.

The programmer’s main objective is to translate object methods into program code modules and determine what event or message will trigger the execution of each module. To accomplish the task, the programmer analyzes sequence diagrams and state transition diagrams that show the events and messages that trigger changes to an object. O-O applications are called event-driven, because each event, transaction, or message triggers a corresponding action. The programmer can represent the program steps in pseudocode initially, or use CASE tools and code generators to create object-oriented code directly from the object model.

Object-Oriented Cohesion and Coupling

The principles of cohesion and coupling also apply to object-oriented application development. Classes should be as loosely coupled (independent of other classes) as possible. In addition, an object’s methods also should be loosely coupled (independent of other methods) and highly cohesive (perform closely related actions). By following these principles, classes and objects are easier to understand and edit. O-O programmers who ignore cohesion and coupling concepts may end up creating a web of code that is difficult to maintain. When code is scattered in various places, editing becomes complicated and expensive.

AGILE APPLICATION DEVELOPMENT

As you learned in Chapter 1, agile development is a distinctly different systems development method. It shares many of the steps found in traditional development, but uses a highly iterative process. The development team is in constant communication with the primary user, who is called the customer , shaping and forming the system to match the customer’s specifications. Agile development is aptly named because it is based on a quick and nimble development process that easily adapts to change. Agile development focuses on small teams, intense communication, and rapid development iterations.

As agile methods become more popular, many software firms are offering packages that teams can use to manage and document the agile process. For example, Serena is a leader in agile development solutions. On its Web site, shown in Figure 11-20, a video uses an automobile analogy to describe the firm’s four-step approach to agile development.

FIGURE 11-20 Serena’s video clip uses an automobile analogy to describe the firm’s four-step approach to agile development, which it calls Orchestrated Agility.

© 2012 Serena Software Inc.

You also learned in Chapter 1 about Extreme Programming (XP), which is one of the newest agile methods. XP is an iterative approach, as shown in Figure 11-21 on the next page, where a team of users and developers immerse themselves in systems development. XP supporters emphasize values such as simplicity, communication, feedback, respect, and courage. Success requires strong commitment to the process, corporate support, and dedicated team members. The following section describes a typical XP project.

An Extreme Programming (XP) Example

Suppose that a customer has requested a sales tracking system. The first step in the XP process, like any other development method, would be to define the system requirements. The customer begins by meeting with programmers and providing user stories. A user story is a short, simple requirements definition. Programmers review user stories to determine the project’s requirements, priorities, and scope. Here are three user story examples:

· As the sales manager, I want to identify fast or slow moving items so I can manage our inventory more effectively.

· As a store manager, I need enough lead time to replenish my stock so I don’t run out of hot items.

· As a sales representative, I want to offer the best selection of fast selling items and clear out the old stock that is not moving.

FIGURE 11-21 Extreme programming relies on the core values shown here. Notice that users are invited to start with these values, and add their own.

© 2009 Don Wells

User stories do not deal with technical details and are so short that they are often written on index cards. Each user story is given a priority by the customer, so the requirements can be ranked. In addition, programmers assign a score to each user story that indicates the estimated difficulty of implementation. This information helps the team form a plan and assign its resources. Projects are often composed of many user stories, from which programmers can estimate the scope, time requirements, and difficulty of the project. In addition to the user stories, frequent face-to-face meetings with customers provide a higher level of detail as the project progresses.

The team must also develop a release plan , which specifies when user stories will be implemented and the timing of the releases. Releases are relatively frequent, and each system release is like a prototype that can be tested and modified as needed.

User stories are implemented in a series of iteration cycles. An iteration cycle includes planning, designing, coding, and testing of one or more features based on user stories. At the beginning of each iteration cycle, which is often two weeks long, the team holds an iteration planning meeting to break down the user stories into specific tasks that are assigned to team members. As new user stories or features are added, the team reviews and modifies the release plan.

As with any development process, success is determined by the customer’s approval. The programming team regularly meets with the customer, who tests prototype releases as they become available. This process usually results in additional user stories, and changes are implemented in the next iteration cycle. As the project’s code changes during each iteration, obsolete code is removed and remaining code is restructured to keep the system up to date. The iteration cycles continue until all user stories have been implemented, tested, and accepted.

Extreme Programming uses an interesting concept called parallel programming. In parallel