Research Paper

sinister670

research_paper.zip

Home >Computer Science homework help >Research Paper

Research Paper/.DS_Store

__MACOSX/Research Paper/._.DS_Store

Research Paper/Chapter 14.pdf

14 Current Trends in System Development

Chapter Outline ▪ Trends in System Development Methodologies

▪ Trends in Technology Infrastructure

▪ Trends in Application Software Availability

▪ The Web as an Application Platform

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

▪ Describe the elements of the Unified Process (UP)

▪ Compare and contrast the features of Extreme Programming and Scrum development

▪ Describe the major trends in connectivity, Internet, and telephone technologies

▪ List and describe the various methods of deploying application software

▪ List and describe the various elements that enhance Web applications

▪ Describe the various approaches to developing Rich Internet Applications

OPENING CASE : Valley Regional Hospital: Measuring a Project's Progress Claire Haskell, the vice president of technology at Valley Regional Hospital (VRH), listened quietly to Henry Williams's progress report on the new patient records system. Henry was the project leader for the team that was developing the system. Also in the meeting were the pro ject's sponsor, Charlie Montgomery, who was the director of patient information and records, and Jason Smith, the director of software development. Months before, Jason and Henry had asked Claire to try a new development approach called Extreme Programming (XP) for this recently approved project. They had already spoken with Charlie, and he had agreed to try the XP development method. Claire approved the project and their request to try the new approach even though she knew very little about it.

During his presentation, Henry kept talking about how wonderfully the team was working together and how much fun they were having. Although she was glad that the team was functioning well, Claire wanted more specifics. She wanted to know whether the new system was on schedule and within budget. After about 20 minutes of listening patiently, she couldn't wait any longer.

“I need to see a schedule,” she told Henry, “and I need a report on the team's progress.”

Henry projected a schedule on the screen, but that did little to help; it had no familiar milestones, such as analysis, design, and programming. Instead, she saw other terms: iteration, user stories, and refactoring.

At this point, Claire became worried. She turned to Charlie and said pointedly: “Exactly how is the project progressing from your viewpoint?”

His answer surprised her.

“The records administrators and I are extremely pleased with the demos we are seeing,” he said. “We are also satisfied with the quality of the system we saw during our acceptance testing. From what we have seen so far, the system seems to be exactly what we need. But as far as the schedule is concerned, I'm not certain whether the entire

443

443 444

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

satisfied with the quality of the system we saw during our acceptance testing. From what we have seen so far, the system seems to be exactly what we need. But as far as the schedule is concerned, I'm not certain whether the entire system will be delivered on time. I think it will, but I'm not involved in the day-to-day development.”

Claire felt a little better. At least the system was doing what it needed to do. But she still wanted reassurance from the project leader. “Henry, are we going to hit the completion date?” she asked. “The system needs to be ready on time.”

“We are progressing on schedule so far and everything looks fine,” Henry responded. “No, I can't show you a traditional schedule—one with major milestones. But here is a short-term schedule for the next two months of work.”

Claire wasn't satisfied. She asked Henry to stay and talk with her privately after the meeting ended, at which point she became agitated.

“Henry, we need more accountability for this project,” she said. “The only solution I see is to meet with you frequently to monitor its progress. I want a rough schedule for the rest of the project on my desk on Monday morning. That gives you three days to develop one. Then, I want you to meet with me every Monday from here on out so we can be sure we are on track and hit the delivery date.”

Although he wasn't pleased with Claire's suggestion, Henry reluctantly agreed.

Overview So far, this book has focused on teaching you the processes and skills associated with a system development project. You have learned the “soft” skills associated with managing projects, interacting in teams, gathering information, and making presentations. You have also learned the “hard” skills—those associated with problem solving, building requirements models, and designing new systems. You have learned many important concepts about projects, iterative development, and the SDLC. In short, you have developed a solid working knowledge of system development and obtained a bag of tools to get you started developing information systems for businesses and other organizations.

The approach presented in this textbook isn't the only method for developing systems. As you move forward with your career in information systems, you will find that the industry is wide and varied. There are companies using methodologies and techniques that have been around for 30 years or longer. There are other groups that are trying various approaches in an attempt to improve the speed and efficiency of the development process as well as the quality of the end result. Many organizations have a mix of older, well-established methods for some projects and newer techniques and methods for other projects. No matter which type of organization you work for, the methods and techniques you have learned from this textbook are fundamental and will serve you well.

We begin this chapter with a review of three of the more current development methodologies, along with their associated practices and techniques. These are the Unified Process (UP), Scrum, and Extreme Programming (XP). As indicated earlier in this text, most new approaches, including these three, are based on the Agile philosophy and an iterative life cycle. In this chapter, you will learn about the details of each of these three approaches.

Following the discussion of these three methodologies, we will look at some of the new technology trends in the technology and software application industry. These trends are a major driving force in requiring a more agile and iterative approach to application software development. Software development is very different today than it was even a few years ago, and there are two major reasons for this. One is our ability to connect and network with other like- minded developers throughout the world thanks to the Internet. The other is the proliferation of so many types of devices that support computer applications.

We will look at three trends that are currently impacting the world of software development.

The first trend is the extremely wide variety of consumer devices that have computing capabilities: cameras, ebook readers, smartphones, automobile GPS devices, gaming equipment, tablet and laptop computers, and even household appliances. Although the operating system software and communication software for these devices isn't a focus of information system development, many of these devices support custom applications and browser applications, and those are within the realm of information systems. We will briefly look at the proliferation of computing devices.

444 445

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

those are within the realm of information systems. We will briefly look at the proliferation of computing devices.

A second trend is the approach to the distribution of application software, especially consumer applications. For example, the open-source movement has provided a plethora of components, tools, and applications that can be used by developers and end users. We will look at two major movements in this arena: software as a service (SAAS) and open source.

The third trend is the movement toward Web-based applications. With the widespread availability of Internet access and the incredible amount of information and services provided through the Web, browser-based applications have become the largest source of new application development in the world. Although this is true for business applications and consumer-oriented applications, the most dramatic growth by far is in the development of new services for the consumer. We will review some of the more important aspects of application software development for the Web.

Trends in System Development Methodologies In Chapter 8, you were introduced to Agile development. The Agile philosophy has proven to be an effective way to approach software development in today's fast-paced, continually changing landscape of computer applications. However, the Agile philosophy only proposes principles; it isn't meant to be a complete methodology, with practices and action steps. In this section, we present three methodologies that incorporate Agile principles but are also complete methodologies, with specific techniques and practices.

These three methodologies—UP, XP, and Scrum—are among the most popular approaches to application software development, but they aren't always found in their purest forms. Frequently, organizations either mix and match techniques from the three or only adopt a specific set of practices. However, adoption of these methodologies continues to expand throughout all types of organizations that develop software applications.

The Unified Process The Unified Process (UP) is an object-oriented system development methodology originally offered by Rational Software, which is now part of IBM. Developed by Grady Booch, James Rumbaugh, and Ivar Jacobson—the three pioneers behind the success of the Unified Modeling Language (UML)—the UP defines a complete methodology that uses UML for system models and describes a new, adaptive system development life cycle. In the UP, the term development process is synonymous with development methodology.

The UP is now widely recognized as a highly influential innovation in software development methodologies for object-oriented development using an adap tive approach. The original version of UP defined an elaborate set of activities and deliverables for every step of the development process. More recent versions are streamlined, with fewer activities and deliverables, simplifying the methodology. The methodology used in this textbook is an adaptation of UP principles.

As discussed previously, adaptive methodologies—including the UP—are all based on an iterative approach to development. You learned in Chapter 1 that each iteration is like a mini-project, in which requirements are defined based on analysis tasks, system components are designed, and those components are then implemented—at least partially—through programming and testing. However, one of the big questions in adaptive development is what the focus of each iteration should be. In other words, do iterations early in the project have the same objectives and focus as those done later? The UP answers this question by dividing a project into four major phases.

UP Phases A phase in the UP can be thought of as a goal or major emphasis for a particular portion of the project. The four phases of the UP life cycle are: inception, elaboration, construction, and transition, as shown in Figure 14-1.

Each phase of the UP life cycle describes the emphasis or objectives of the project team members and their activities at that point in time. Thus, the four phases provide a general framework for planning and tracking the project over time. Within each phase, several iterations are planned to give the team enough flexibility to adjust to problems or changing conditions. The emphases or objectives of the project team in each of the four phases are described briefly in Figure 14-2.

445 446

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

described briefly in Figure 14-2.

FIGURE 14-1 The Unified Process system development life cycle

FIGURE 14-2 UP phases and objectives

Inception Phase As in any project-planning phase, the inception phase consists of the project manager developing and refining a vision for the new system in order to show how it will improve operations and solve existing problems. Essentially, the project manager makes the business case for the new system, proving that the new system's benefits will outweigh the cost of development. The scope of the system must also be defined so it is clear what the project will accomplish. Defining the scope includes identifying many of the key requirements for the system.

The inception phase is usually completed in one iteration, and as with any iteration, parts of the actual system may be designed, implemented, and tested. As software is developed, team members must confirm that the system vision still matches user expectations or that the technology will work as planned. Sometimes, prototypes are discarded after proving that point.

Elaboration Phase The elaboration phase usually involves several iterations, and early iterations typically complete the identification and definition of all the system requirements. Because the UP is an adaptive approach to development, the requirements are expected to evolve and change after work starts on the project.

The elaboration phase's iterations also complete the analysis, design, and implementation of the system's core architecture. Usually, the aspects of the system that pose the greatest risk are identified and implemented first. Until developers know exactly how the highest-risk aspects of the project will work out, they can't determine the amount of effort required to complete the project. By the end of the elaboration phase, the project manager should have more realistic estimates for the project's cost and schedule, and the business case for the project can be confirmed. Remember that the design, implementation, and testing of key parts of the system are completed during the elaboration phase. One other major objective of the elaboration phase is to do the necessary research and fact- finding so all the user requirements are identified. During the elaboration phase, a high percentage of time is spent on understanding and analysis.

446 447

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

on understanding and analysis.

Construction Phase The construction phase involves several iterations that continue the design and implementation of the system. The core architecture and highest-risk aspects of the system are already complete. Now the focus of the work turns to the routine and predictable parts of the system—for example, detailing the system controls, such as data validation, fine-tuning the user interface design, finishing routine data maintenance functions, and completing the help and user preference functions. The team also begins to plan for deployment of the system.

Transition Phase During the transition phase, one or more final iterations involve the final user acceptance and beta tests, and the system is made ready for operation. After the system is in operation, it will need to be supported and maintained.

UP Disciplines

UP discipline a set of functionally related activities that combine to enable the development process in a UP project

As we mentioned earlier, the four UP phases define the project sequentially by indicating the emphasis of the project team at any point in time. To make iterative development manageable, the UP defines disciplines to use within each iteration. A UP discipline is a set of functionally related activities that contributes to one aspect of the development project. UP disciplines include business modeling, requirements, design, implementation, testing, deployment, configuration and change management, project management, and environment. Each iteration usually involves activities from all disciplines.

FIGURE 14-3 UP disciplines used in varying amounts in each iteration

447 448

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

Figure 14-3 shows how the UP disciplines are involved in each iteration, which is typically planned to last four weeks. The size of the shaded area under the curve for each discipline indicates the relative amount of work included from each discipline during the iteration. The amount and nature of the work differs from iteration to iteration. For example, in iteration 2, much of the effort focuses on business modeling and requirements definition, with much less effort focused on implementation and deployment. In iteration 5, very little effort is focused on modeling and requirements and much more effort focused on implementation, testing, and deployment. But most iterations involve some work in all disciplines.

Figure 14-4 shows the entire UP life cycle: phases, iterations, and disciplines. It includes all the key UP life cycle features and is useful for understanding how a typical information system development project is managed.

The previous figures illustrate how the phases include activities from each discipline. But what about the detailed activities that occur within each discipline? The disciplines can be divided into two main categories: system development activities and project management activities. The six main UP development disciplines are:

▪ Business modeling

▪ Requirements

▪ Design

▪ Implementation

▪ Testing

▪ Deployment

For each iteration, the project team must understand the business environment (business modeling), define the requirements that that portion of the system must satisfy (requirements), design a solution for that portion of the system that satisfies the requirements (design), write and integrate the computer code that makes that portion of the system work (implementation), thoroughly test that portion of the system (testing), and then, in some cases, put the part of the system that is completed and tested into operation for users (deployment).

FIGURE 14-4 UP life cycle with phases, iterations, and disciplines

448 449

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

Three additional support disciplines are necessary for planning and controlling the project:

▪ Configuration and change management

▪ Project management

▪ Environment

Configuration and change management involves setting up processes to support the coding activities. This includes such guidelines as when and how to release code as well as when and how to manage releases and versions. Project management refers to the tasks that were discussed in Chapter 9, such as planning the iterations, assigning work, and verifying that work has been completed. The environment discipline involves those tasks required to establish the working environment, including the tools to be used by the team. It also includes those guidelines about how to work together in an iterative Agile project.

All nine UP disciplines are employed throughout the lifetime of a project but to different degrees. For example, in the inception phase, there is one iteration. During the inception phase iteration, the project manager might complete a model showing some aspect of the system environment (the business modeling discipline). The scope of the system is delineated by defining many of the key system requirements and listing use cases (the requirements discipline). To prove technological feasibility, some technical aspect of the system might be designed (the design discipline), programmed (the implementation discipline), and tested to make sure it will work as planned (the testing discipline). In addition, the project manager makes plans for handling changes to the project (the configuration and change management discipline), working on a schedule and cost/benefit analysis (the project management discipline), and tailoring the UP phases, iterations, deliverables, and tools to match the needs of the project (the environment discipline).

The elaboration phase includes several iterations. In the first iteration, the team works on the details of the domain classes and use cases addressed in the iteration (the business modeling and requirements disciplines). At the same time, it might complete the description of all use cases to finalize the scope (the requirements discipline). The use cases addressed in the iteration are designed by creating design class diagrams and interaction diagrams (the design discipline), programmed using Java or Visual Basic .NET (the implementation disci pline), and fully tested (the testing discipline). The project manager works on the plan for the next iteration and continues to refine the schedule and feasibility assessments (the project management discipline), and all team members continue to receive training on the UP activities they are completing and the system development tools they are using (the environment discipline).

By the time the project progresses to the construction phase, most of the use cases have been designed and implemented in their initial form. The focus of the project turns to satisfying other technical, performance, and reliability requirements for each use case, finalizing the design, and implementing the design. These requirements are usually routine and lower risk, but they are key to the success of the system. The effort focuses on designing system controls and security and on implementing and testing these aspects.

As a system development methodology, the Unified Process must be tailored to the development team and the specific project. Choices must be made about which deliverables to produce and the level of formality, or ceremony, to be used. Sometimes, a project requires formal reporting and controls. Other times, it can be less formal. The UP should always be tailored to the project, although the UP does tend toward more ceremony than the next two methodologies.

Extreme Programming Extreme Programming (XP) is an adaptive, agile development methodology that was created in the mid-1990s. The word extreme sometimes makes people think that this methodology is completely new and that developers who embrace XP are radicals. However, XP is really an attempt to take the best practices of software development and extend them “to the extreme.” Extreme programming has these characteristics:

▪ Takes proven industry best practices and focuses on them intensely

449 450

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

▪ Takes proven industry best practices and focuses on them intensely

▪ Combines those best practices (in their most intense forms) in a new way to produce a result that is greater than the sum of the parts

Figure 14-5 lists the core values and practices of XP. In the following sections, we first present the four core values of XP and then we explain its 12 primary practices. Finally, we describe the basic structure of an XP project and the way XP is used to develop software.

FIGURE 14-5 XP core values and practices

XP Core Values The four core values of XP—communication, simplicity, feedback, and courage— drive its practices and project activities. You will recognize the first three as best practices for any development project. You will also notice that the fourth is a desired value for any project, even though it might not be stated explicitly. Here are brief descriptions of the four core values of XP:

▪ Communication—One of the major causes of project failure is a lack of open communication among the right players at the right time and at the right level. Effective communication involves not only documentation but also verbal discussion. The practices and methods of XP are designed to ensure that open, frequent communication occurs.

▪ Simplicity—Even though developers have always advocated keeping solutions simple, they don't always follow their own advice. XP includes techniques to reinforce this principle and make it a standard way of developing systems.

▪ Feedback—As with simplicity, getting frequent, meaningful feedback is recognized as a best practice of software development. Feedback on functionality and requirements should come from the users, feedback on designs and code should come from other developers, and feedback on satisfying a business need should come from the client. XP integrates feedback into every aspect of development.

▪ Courage—Developers always need courage to face the harsh choice of doing things right or throwing away bad code and starting over. But all too frequently, they haven't had the courage to stand up to a too-tight schedule, resulting in bad mistakes. XP practices are designed to give developers the courage to “do it right.”

450 451

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

right.”

XP Practices XP's 12 practices embody the basic values just presented. These practices are consistent with the Agile principles explained earlier in this chapter.

Planning Some people describe XP as glorified hacking or as the old “code and fix” methodology that was used in the 1960s. That isn't true; XP does include planning. However, as an adaptive technique, it recognizes that you can't know everything at the start. As indicated earlier, XP embraces change. XP planning focuses on making a rough plan quickly and then refining it as things become clearer. This reflects the Agile development philosophical dictum that change is more important than detailed plans. It is also consistent with the idea that individuals—and their abilities—are more important than an elaborate process.

The basis of an XP plan is a set of stories that users develop. A story describes what the system needs to do. XP doesn't use the term use case, but a user story and a use case express a similar idea. Planning involves two aspects: business issues and technical issues. In XP, the business issues are decided by the users and clients, whereas technical issues are decided by the development team. The plan, especially in the early stages of the project, consists of the list of stories (from the users) and the estimates of effort, risk, and work dependencies for each story (from the development team). As in Agile development, the idea is to heavily involve the users in the project rather than have them to simply sign off on specifications.

Testing Every new piece of software requires testing, and every methodology includes testing. XP intensifies testing by requiring that the tests for each story be written first—before the solution is programmed. There are two major types of tests: unit tests, which test the correctness of a small piece of code, and acceptance tests, which test the business function. The developers write the unit tests, and the users write the acceptance tests. Before any code can be integrated into the library of the growing system, it must pass the tests. By having the tests written first, XP automates their use and executes them frequently. Over time, a library of required tests is created, so when requirements change and the code needs to be updated, the tests can be rerun quickly and automatically.

pair programming XP practice in which two programmers work together on designing, coding, and testing software

Pair Programming More than any other, this practice is one for which XP is famous. Instead of simply requiring one programmer to watch another's work, pair programming divides up the coding work. First, one programmer might focus more on design and double-checking the algorithms while the other writes the code. Then, they switch roles; thus, over time, they both think about design, coding, and testing. XP relies on comprehensive and continual code reviews. Interestingly, research has shown that pair programming is more efficient than programming alone. It takes longer to write the initial code, but the long-term quality is higher. Errors are caught quickly and early, two people become familiar with every part of the system, all design decisions are developed by two brains, and fewer “quick and dirty” shortcuts are taken. The quality of the code is always higher in a pair-programming environment.

Simple Designs Opponents say that XP neglects design, but that isn't true. XP conforms to the principles of Agile Modeling, as described in Chapter 8, by avoiding the “Big Design Up Front” approach. Instead, it views design as so important that it should be done continually, although in small chunks. As with everything else, the design must be verified immediately by reviewing it along with coding and testing.

So, what is a simple design? It is one that accomplishes the desired result with as few classes and methods as possible and that doesn't duplicate code. Accomplishing all that is often a major challenge.

refactoring revising, reorganizing, and rebuilding part of a system so it is of higher quality

Refactoring the Code Refactoring is the technique of improving the code with out changing what it does. XP programmers continually refactor their code. Before and after adding any new functions, XP programmers review their code to see whether there is a simpler design or a simpler method of achieving the same result. Refactoring

451 452

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

programmers continually refactor their code. Before and after adding any new functions, XP programmers review their code to see whether there is a simpler design or a simpler method of achieving the same result. Refactoring produces high-quality, robust code.

Owning the Code Collectively In XP, everyone is responsible for the code. No one person can say “This is my code.” Someone can say “I wrote it,” but everyone owns it. Collective ownership allows anyone to modify any piece of code. However, because unit tests are run before and after every change, if programmers see something that needs fixing, they can run the unit tests to make sure the change didn't break something. This practice embodies the team concept that developers are building a system together.

Continuous Integration This practice embodies XP's idea of “growing” the software. Small pieces of code— which have passed the unit tests—are integrated into the system daily or even more often. Continuous integration highlights errors rapidly and keeps the project moving ahead. The traditional approach of integrating large chunks of code late in the project often resulted in tremendous amounts of rework and time lost while developers tried to determine just what went wrong. XP's practice of continuous integration prevents that.

On-Site Customer As with all adaptive approaches, XP projects require continual involvement of users who can make business decisions about functionality and scope. Based on the core value of communication, this practice keeps the project moving ahead rapidly. If the customer isn't ready to commit resources to the project, the project won't be very successful. 452

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

major types of tests: unit tests, which test the correctness of a small piece of code, and acceptance tests, which test the business function. The developers write the unit tests, and the users write the acceptance tests. Before any code can be integrated into the library of the growing system, it must pass the tests. By having the tests written first, XP automates their use and executes them frequently. Over time, a library of required tests is created, so when requirements change and the code needs to be updated, the tests can be rerun quickly and automatically.

pair programming XP practice in which two programmers work together on designing, coding, and testing software

refactoring revising, reorganizing, and rebuilding part of a system so it is of higher quality

System Metaphor This practice is XP's unique and interesting approach to defining an architectural vision. It answers the questions “How does the system work?” and “What are its major components?” And it does it by having the developers identify a metaphor for the system. For example, Big Three automaker Chrysler's payroll system was built as a production-line metaphor, with its system components using production-line terms. Everyone at Chrysler under stood a production line, so a payroll transaction was treated the same way; developers started with a basic transaction and then applied various processes to complete it. Of course, a system metaphor should be easily understood or well known to the members of the development team. It can guide members toward a vision

452

452 453

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

with a basic transaction and then applied various processes to complete it. Of course, a system metaphor should be easily understood or well known to the members of the development team. It can guide members toward a vision and help them understand the system.

Small Releases A release is a point at which the new system can be turned over to users for acceptance testing and even for productive use. Consistent with the entire philosophy of growing the software, small and frequent releases provide upgraded solutions to the users and keep them involved in the project. Frequent releases also facilitate other practices, such as immediate feedback and continual integration.

Forty-Hour Week and Coding Standards These final two practices set the tone for how the developers should work. The exact number of hours a developer works isn't the issue. The issue is that the project shouldn't be a death march that burns out every member of the team. Neither should the project be a haphazard coding exercise. Developers should follow standards for coding and documentation. XP uses just the engineering principles that are appropriate for an adaptive process based on empirical controls.

XP Project Activities Figure 14-6 shows an overview of the XP system development approach. It is divided into three levels: system (the outer ring), release (the middle ring), and iteration (the inner ring). System-level activities occur once during each development project. A system is delivered to users in multiple stages called releases. Each release is a fully functional system that performs a subset of the full system requirements. A release is developed and tested within a period of no more than a few weeks or months. The activities in the middle ring cycle multiple times— once for each release. Releases are divided into multiple iterations. During each iteration, developers code and test a specific functional subset of a release. Iterations are coded and tested in a few days or weeks. There are multiple iterations within each release, so the iteration ring (inner) cycles multiple times.

FIGURE 14-6 XP development approach

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

The first XP development activity is creating user stories, which are similar to use cases in object-oriented analysis. A team of developers and users quickly documents all the user stories the system will support. Developers then create a class diagram to represent objects of interest within the user stories.

Developers and users then create a set of acceptance tests for each user story. Releases that pass the acceptance tests are considered finished. The final system-level activity is to create a development plan for a series of releases. The first release supports a subset of the user stories, and subsequent releases add support for additional stories. Each release is delivered to users and performs real work, thus providing an additional level of testing and feedback.

The first release-level activity is planning a series of iterations. Each iteration focuses on a small (possibly just one) system function or user story. The iterations' small size allows developers to code and test them within a few days. A typical release is developed by using from a few to a few dozen iterations.

After the iteration plan is complete, work begins on the first iteration-level activity. Code units are divided among multiple programming teams, and each team develops and tests its own code. XP recommends a test-first approach to coding. Test code is written before system code. As code modules pass unit testing, they are combined into larger units for integration testing. When an iteration passes integration testing, work begins on the next iteration.

When all iterations of a release have been completed, the release undergoes acceptance testing. If a release fails acceptance testing, the team returns it to the iteration level for repair. Releases that pass acceptance testing are delivered to end users, and work begins on the next release. When acceptance testing of the final release is completed, the development project is finished.

Scrum Those of you who are familiar with rugby are aware that when a team gets possession of the ball, it attempts to go the entire distance in one continuous play— from point of possession to the score. The team works together, passing the ball back and forth; even when tackled, it can maintain possession and keep the ball in play. Originally, this “rugby” approach was applied to product development.

One interesting element in rugby is a scrum, which is used to get a ball back into play after a penalty. The defining characteristics of a scrum are that it begins quickly, is a very intense effort, involves the entire team, and usually only lasts for a short duration.

Combining some of these principles of rugby with the Agile philosophy gave rise to a methodology—the objective of which is to be quick, agile and intense and to go the entire distance. This methodology is referred to as the Scrum approach. Over time, the techniques have been refined to fit into a powerful adaptive software development methodology. Figure 14-7 illustrates an overview of the Scrum approach. There are three important Scrum areas to understand: the philosophy, the organization, and the practices.

Scrum Philosophy The Scrum philosophy is based on the Agile Development principles described earlier. Scrum is responsive to a highly changing, dynamic environment in which users might not know exactly what is needed and might also change priorities frequently. In this type of environment, changes are so numerous that projects can bog down and never reach completion. Scrum excels in this type of situation.

FIGURE 14-7 Scrum software development process

453 454

454 455

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

Scrum focuses primarily on the team level. It is a type of social engineering that emphasizes individuals more than processes and describes how teams of developers can work together to build software in a series of short mini projects. Key to this philosophy is the complete control a team exerts over its own organization and its work processes. Software is developed incrementally, and controls are imposed empirically—by focusing on things that can be accomplished.

product backlog a prioritized list of user requirements used to choose work to be done in a Scrum project

The basic control mechanism for a Scrum project is a list of all the things the system should include and address. This list—called the product backlog— includes user functions (such as use cases), features (such as security), and technology (such as platforms). The product backlog list is continually being prioritized, and only a few of the high- priority items are worked on at a time, according to the current needs of the project and its sponsor.

Scrum Organization

product owner the client stakeholder for whom the system is being built

Scrum master the person in charge of a Scrum project—similar to a project manager

The three main organizational elements that affect a Scrum project are the product owner, the Scrum master, and the Scrum team or teams.

The product owner is the client, but he or she has additional responsibilities. Remember that in Agile development, the user and client are closely involved in the project. In Scrum, the product owner maintains the product backlog list. For any function to be included in the final system, it must first be placed on the product backlog. Because the product owner maintains that list, any request must first be approved and agreed to by the product owner. In traditional development projects, the project team initiates the interviews and other activities to identify and define requirements. In a Scrum project, the primary client controls the requirements. This forces the client and user to be intimately involved in the project. Nothing can be accomplished until the product owner creates the backlog.

The Scrum master enforces Scrum practices and helps the team complete its work. A Scrum master is comparable to a project manager in other approaches. However, because the team is self-organizing and no overall project schedule exists, the Scrum master's duties are slightly different. He or she is the focal point for communication and progress reporting—just as in a traditional project. But the Scrum master doesn't set the schedule or assign tasks. The team does. One of the primary duties of the Scrum master is to remove impediments so the team can do its work. In other words, the Scrum master is a facilitator.

The Scrum team is a small group of developers—typically five to nine people—who work together to produce the software. For projects that are very large, the work should be partitioned and delegated to smaller teams. If necessary, the Scrum masters from all the teams can coordinate multiple team activities.

The Scrum team sets its own goal for what it can accomplish in a specific period of time. It then organizes itself and parcels out the work to members. In a small team, it is much easier to sit around a table, decide what needs to be done, and have members of the team volunteer or accept pieces of work.

Scrum Practices

sprint a time-controlled mini-project that implements a specific portion of a system

455 456

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

The Scrum practices are the mechanics of how a project progresses. Of course, the practices are based on the Scrum philosophy and organization. The basic work process is called a sprint, and all other practices are focused on supporting a sprint.

A Scrum sprint is a firm 30-day period called a time box, with a specific goal or deliverable. At the beginning of a sprint, the team gathers for a one-day planning session. In this session, the team decides on the major goal for the sprint. The goal draws from several items on the prioritized product backlog list. The team decides how many of the highest-priority items it can accomplish within the 30-day sprint. Sometimes, lower-priority items can be included for very little additional effort and can be added to the deliverables for the sprint.

After the team has agreed on a goal and has selected items from the backlog list, it begins work. The scope of that sprint is then frozen, and no one can change it—neither the product owner nor any other users. If users do find new functions they want to add, they put them on the product backlog list for the next sprint. If team members determine that they can't accomplish everything in their goal, they can reduce the scope for that sprint. However, the 30-day period is kept constant.

Every day during the sprint, the Scrum master holds a daily Scrum, which is a meeting of all members of the team. The objective is to report progress. The meeting is limited to 15 minutes or some other short time period. Members of the team answer only three questions:

▪ What have you done since the last daily Scrum (during the last 24 hours)?

▪ What will you do by the next daily Scrum?

▪ What kept you or is keeping you from completing your work?

The purpose of this meeting is simply to report issues, not to solve them. Individual team members collaborate and resolve problems after the meeting as part of the normal workday. One of the major responsibilities of the Scrum master is to note the impediments and see that they are removed. A good Scrum master clears impediments rapidly. The Scrum master also protects the team from any intrusions. The team members are then free to accomplish their work. Team members do talk with users to obtain requirements, and users are involved in the sprint's work. However, users can't change the items being worked on from the backlog list or change the intended scope of any item without putting it on the backlog list.

At the end of each sprint, the agreed-on deliverable is produced. A final half-day review meeting is scheduled to recap progress and identify changes that need to be made for the following sprints. By time-boxing these activities —the planning, the sprint, the daily Scrum, and the Scrum review—the process becomes a well-defined template to which the team easily conforms, which contributes to the success of Scrum projects.

Trends in Technology Infrastructure The technology infrastructure refers to the computing devices along with the operating system and communication software that allow those devices to function. The rapid pace of change in microprocessors for the past 30 years has allowed manufacturers to bring a continual stream of faster, more powerful computing devices to market. At first, there was the tremendous growth in the speed and computing capabilities of personal computers. The same increased capacity also occurred in reasonably priced server computers. No longer were large, expensive mainframe computers necessary to support high-speed and high-capacity computers. More recently, as the increase in capacity of personal and server computers has become more moderate, the most rapid changes are occurring in such handheld mobile devices as tablets and smartphones.

It is always difficult to predict where the next area of rapid growth will occur, and we won't try to do so in this book. However, these advances in equipment have led to more advanced and sophisticated application software. And not only have the software applications become more complex, but they also have had to be developed more rapidly to keep pace. Developers must be quick and agile just to keep up. This trend will continue in the future and will undoubtedly open up new opportunities for providing software applications in many different forms and on many different devices.

456 457

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

open up new opportunities for providing software applications in many different forms and on many different devices.

We will discuss the technology infrastructure in the following three areas: client and end-user devices, Internet and telephone communications, and back end computing infrastructure for hosting applications.

Client Computing Devices This is a broad category of devices that users interact with to communicate, play games, retrieve information, and perform everyday tasks. The most common devices are desktop, laptop, and notebook computers. However, the rapid rise of small portable devices, such as tablets and ebook readers, has broadened the utility of screen-based user computing. The exponential growth of Web technol ogy has made these devices even more useful—for businesses and for individuals. And not only has Web technology and availability expanded exponentially (with wired and wireless LANs), it has been coupled with wireless telephone communications and is now available everywhere and anytime. The combination of these elements—portable, mobile devices and the wide availability of the Internet—has opened up a whole new world of opportunity and challenge for today's developers.

The capabilities of these devices continues to expand. Cross-capability also continues to drive new devices with expanded functions. For example, smart phones are no longer just telephone devices; they can also be used to play games, take pictures, take video, send and receive e-mail (with graphic attachments), browse the Internet, and watch TV. In the United States, the number of smartphones surpasses the number of PCs. Similarly, today's automobiles provide not just transportation but maps and directions; they also take pictures and videos of the view in front of and behind the vehicle. And book-reading devices no longer just provide downloaded books; they can now be used to review and purchase online books, music, and video as well as watch movies and TV. Many of these new devices are telephone and Wi-Fi enabled; thus, connectivity is always available by utilizing the most rapid methods. This trend toward wider connectivity, enhanced functionality, and increased mobility will continue into the foreseeable future. Figure 14-8 shows the iPhone and several of the applications that are available for it.

Software for mobile devices is also changing. Three types of applications are currently found on stationary and mobile devices. The first type is a stand-alone application—for example, a word-processing application or an image- editing application—that executes on a single computer without requiring connectivity to any other device. We refer to this type as a device-top application. The second type is a device-top application that is freestanding. Free- standing Internet applications are indeed device-top applications, but they access the Internet for certain functions —for example, iTunes. iTunes allows you to create playlists and to play music stored on your computer. However, when the computer has access to the Internet, iTunes also connects to Apple's iTunes site to provide broader and richer multimedia capabilities. The third type of applica tion is browser-based software. A browser-based application is an Internet application that must have a browser, such as Internet Explorer or Firefox, to execute.

FIGURE 14-8 iPhone with several applications

457 458

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

device-top application a computer application that is built to execute on a local computer (such as a desktop) without requiring a client/server connection

free-standing Internet application a client/server application that is self-contained and doesn't require the use of a Web browser

browser-based application a client/ server application that executes locally within the control of a Web browser

Before 2010, stand-alone device-top applications for mobile devices dominated the software market. Since then, new free-standing or browser-based Internet applications have outpaced stand-alone applications. Later sections of this chapter will further discuss software specifics for Internet-enabled applications.

These new devices produce all types of challenges for software developers— operating system developers and information system developers. For example, many of these devices require 24/7 availability and sometimes even 24/7 connectivity. They require high-definition multimedia capabilities, with user interfaces that are rich, engaging, and intuitive. The small screen size of many of these devices brings extra challenges regarding how to best present information that is elaborate and readable. Users now expect almost instant availability and access to information.

Although the news media focuses primarily on consumer devices for the general public, organizations and businesses continue to move rapidly toward the adoption of these new technologies. Product-based industries continue to seek new ways to handle, store, and distribute their products more efficiently and effectively. Service- based industries utilize stationary and mobile devices to provide enhanced levels of information and service for their clients. Opportunities abound for new applications to be developed and deployed on these devices.

Internet and Telephone Communications

Internet backbone the primary data routes between large, strategically interconnected networks and routers on the Internet

The Internet is an incredibly complex system of interconnected computers and smaller networks. Sometimes, it is called the network of networks because it consists of millions of private, public, business, academic, and government net works. What ties all these individual computers and networks together is the Internet backbone, which consists of the primary data paths from large, strategically located networks and routers.

The communication infrastructure also continues to change rapidly. Historically, the technologies of the Internet, the telephone, and television have grown up separately. Recently, we have seen the migration and merging of these three technologies' capabilities—from Internet to telephony, from telephony to Internet, from broadcast TV to Internet TV, and so forth. One can use the Internet not only to have audio and video communication sessions but to also place telephone calls. One can also access the Internet through wireless telephone connections. And one can watch TV and movies on either Internetenabled or telephone-enabled devices.

Long-distance telephone communication and long-distance Internet communication have very similar requirements and capability. Because of that, some of the largest voice carriers are also the owners of the largest Internet backbone. In fact, Verizon become the world's most connected Internet backbone in 2010. Verizon is also the first company with plans to increase backbone speeds to 100 Gbits per second. In recent years, the growth of purely Internet traffic has moderated slightly. However, this has been more than offset by increases in telephone traffic, which includes synchronous phone calls, text, messaging, and multimedia.

last mile the final leg that delivers connectivity from the Internet network to the customer

458 459

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

The last mile has typically been and continues to be the most challenging element in telephone communications and Internet access. The term refers to that part of the communication link from the last backbone node to the local user. There are various methods used to implement this final link. Most common is by using telephone lines or cable TV (CATV) lines (either copper or optical fiber). Telephone lines have always been bidirectional. Now CATV has added bidirectional communication capability. More recently, due to the rapid growth of mobile devices, wireless solutions are becoming more prevalent. With the advent of 4G networks, the communication speeds and bandwidth are increasing dramatically. The advent of 4G networks will accelerate the penetration of mobile devices, including smartphones.

Back-End Computing Back-end computing refers to the server computers that provide the content— dynamic and static—for all applications that access servers through the Internet. These applications include Internet-enabled free-standing applications as well as browser-based applications. Obviously, any type of client-server application requires server support. As more and more client computers try to access a particular application, the workloads on the servers becomes incredibly heavy. In Chapter 6, we discussed the elements of designing the network, including some of the alternatives: cloud computing, colocation, virtual servers, and virtual private networks. Those alternatives are only available because of the expansion of back-end computing capabilities.

Several factors are driving the need for large back-end computing services. The trend toward continuous connectivity to the Internet is one of them.

Another is the type of applications that are now desired by businesses and consumers. Today, many applications in the world of commerce keep a history of all the transactions that occur. For example, your phone company keeps track of every call made on your phone, with a tremendous amount of detail: date, time, to whom, how long, and so forth. The amount of data storage needed to maintain this amount of data is tremendous. Whether good or bad, organizations are keeping records of all types of activities, including purchases, credit card transactions, phone calls, Web sites visited, and even mouse clicks. Massive amounts of data storage are required to maintain this history (and then data mining it).

Another interesting trend is the consolidation of processing in central locations. When desktop and laptop computers first became relatively inexpensive, many applications and much business processing were done either on client computers or on localized networks. However, as larger and larger amounts of data are being captured, analyzed, and shared, it is more productive to use centralized servers, maintaining a single centralized copy and distributing only the results of data mining or data processing. Examples of the centralized processing and storage include such things as Google apps, Office 365, and Apple's cloud for consumers. (You can archive your music on Apple's “cloud” and not have to store it locally.)

All these factors have provided the impetus for organizations to consolidate computers in colocation facilities and server farms or purchase hosting services from companies that provide virtual servers or cloud computing. The two biggest activities on the Web today are searching and social networking. Companies—such as Google, Yahoo!, Microsoft, Facebook, and Twitter—that provide those services have tremendous server farms consisting of tens of thousands of server computers. Other large companies that sell hosting services also have server farms in the thousands of computers. Figure 14-9 shows a typical server farm within a data center.

Content delivery networks (CDN) are also a rapidly increasing component of back-end computing. Because the Internet allows worldwide connectivity to any Web site, if the Web site is hosted at one location, many clients would have long transmission distances, with corresponding delays. To ameliorate this problem, many Web sites distribute their hosts at several locations around the world.

459 460

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

their hosts at several locations around the world.

FIGURE 14-9 Server farm within a data center

CDN providers, such as Akamai, Limelight, and EdgeCast, are companies that host and deliver this content from locations that are physically located closer to large markets of clients. CDN works especially well for such static content as images, audio, and video.

Trends in Application Software Availability Partly due to the changes in the technology infrastructure described earlier, people and organizations are finding new ways to deploy and provide applications. Historically, when a large or small organization needed a software application to support some organizational procedure, it either developed that software itself or, if the problem was general enough, purchased software and modified it to fit the in-house procedure. One of the major trends in today's information systems environment is that new methods are available for obtaining software functionality. Let us discuss several of the more prevalent ones.

Software as a Service (SAAS) A service is something that we purchase that does something for us. For exam ple, we consider our utilities to be services. We don't have to have our own power generator to get electricity. We just buy what we need as we need it. Another example is service on our vehicles. When something breaks on our cars, we go to auto mechanics and ask them to fix it. We don't need to have our own repair shop. We purchase only the service.

software as a service (SAAS) a software delivery model similar to a utility, in which the application and its associated data are accessed via the Internet without locally installed programs

on-demand software another term for SAAS

460 461

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

Software as a service (SAAS) follows that same basic idea. If an organization requires some services—for example, bookkeeping and accounting functions—it can either build or buy an accounting software system. Alternatively, it could find a firm that provides accounting services and buy only the accounting services it needs. As with any other utility type of service, it would purchase and pay only for those services it requires. It doesn't have to purchase—or install or maintain—the software system. Sometimes, this is referred to as on-demand software.

Although the impetus for SAAS originally involved business software, more general-purpose consumer functions are also being provided as a service—for example, the editing and manipulation of photos and other graphics. You can purchase iPhoto or Adobe Photoshop and install it on your personal computer if you want to manipulate your own photos. Alternatively, there are now many Web-based photo services that provide many of these same functions. In many of those instances, not only does the user not have to buy the application software, but the service is also financed by advertising and is provided free to users.

SAAS software is usually hosted on a server farm, and the functionality is distributed over the Internet or a VPN. SAAS can be divided into two categories: client-data-oriented services and tools services. Each of these can also be further divided into business or organizational services and end-user services.

Client-data-oriented services are those services that maintain information about and data for each client. Each client has an account and requires authentication before it can use the service. If there are multiple employees that use the system, each must have access to a log-on capability. Common business oriented SAAS services include accounting, customer relationship management (CRM), human resource management (HRM), content management (CM), supply chain management (SCM), and enterprise resource planning (ERP). Common end-user SAAS services include blog hosting, content management hosting, and photograph hosting. In all these cases, the client allows the SAAS provider to host and maintain the client's data. Depending on the sensitivity and importance of the data, this can require a high level of trust on the part of the client toward the SAAS provider. 461

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

level of trust on the part of the client toward the SAAS provider.

FIGURE 14-10 Comparison of owning software versus SAAS

The major impetus for using an SAAS provider is the reduced cost of the service. For many end-user services, the cost is funded by advertising; therefore, the service is free to the user. For businesses, the cost is reduced substantially because none of the overhead of owning the software is required. Figure 14-10 itemizes the primary differences between SAAS and owning one's own software. Although the figure doesn't specify dollar amounts, it should be evident that, overall, using SAAS is less costly—in the number of costs and the amount of each one.

SAAS tools often don't save the user's data. They just provide computer tool capability. Examples of SAAS that are tools include computer-aided design (CAD) tools and semiconductor design tools for businesses. There are also Web sites that generate such things as passwords, md5 encryption, or public key and private key combinations. In these instances, the users save their own data back on their local workstation. There is no need for extensive data storage capability by the service provider.

Application software that will be used in an SAAS environment must be developed with that end use in mind. Business functions must be developed to be able to handle all the varieties that occur across different companies. The software must be option-driven so a given business or user can configure the system to perform the functions as needed. Developing SAAS applications is much more complex; in fact, the software is often adjusted over time as new users require new functionality.

Other critically important issues with SAAS applications have to do with the security of the data. First, each client's data must be secure from outside intrusion. The data center where the equipment is maintained must also be physically secure, with adequate backup and recovery processes in place. Second, there must be clear and robust isolation of client data among the multiple client databases. Each client's data must be secure and incapable of being viewed by any other client. Just like providers of cloud computing and colocation services, SAAS providers must maintain high levels of security.

461 462

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

maintain high levels of security.

Open-Source Software

open-source software a method of developing, delivering, and licensing software that makes the application source code freely available to any interested developer or client

Open-source software (OSS) is one of the truly remarkable phenomena in the recent growth of the software industry. In the very earliest days of computer programming, application software was developed for a specific business or organization in order to satisfy a specific need. These software applications were at first developed internally. However, because of the commonality of business needs within specific industries, software development companies soon became prevalent. A software firm that specialized in a specific industry could consolidate its knowledge, expertise, and central pool of program source code to provide application software more efficiently and effectively. This phenomenon started in such narrow industry markets as life insurance, health insurance, and banking. (These early systems were often priced in the millions of dollars due to the limited customer base for these specific products.) The next step was the formation of software companies that developed applications for the general market. Because the market for these products is so large, these applications are usually sold for reasonable prices—the $30 to $1,000 range—even though they cost millions of dollars to develop. Such products include Microsoft Office, Adobe Photoshop, Intuit QuickBooks, and TurboTax.

At some point, developers began using a different model to provide applications—methods with various names, such as shareware, freeware, and free software. In 1998, the term open-source software came into existence with the formation of the Open Source Initiative (OSI), which is the organization that currently defines the terms and conditions of open-source definitions. The definition of open-source software includes a method for distributing application software and a method for licensing the software. Open-source software is distributed in source code form. It may also be distributed as a binary executable, but “open” means the source code is freely distributed. An open-source license gives the licensee the right to copy, modify, and redistribute the source code. Redistribution can usually be as a modified application or part of a larger, more elaborate application. Usually, credit must be given to the creator of the original source code.

The OSI has set specific requirements that have become the industry standard for the definition and use of open- source software. According to the OSI, simply giving away the source code doesn't make an application open source. It must conform to several criteria, including such items as:

▪ Source code—The source code must be open for distribution.

▪ Freely redistributable—Recipients of the source code may also distribute it.

▪ Derived works—The source code can be modified and distributed in its modified form.

▪ Distribution of license—The open license should apply to all derived or modified software.

▪ No discrimination—The license can't restrict who can receive or use the software.

▪ No related restrictions—The license can't restrict other software that may be distributed in conjunction with the open-source software.

It is estimated that the value of open-source applications distributed each year approximates $60 billion. There are over 180,000 open-source projects in the world today. There are also over 1,400 different unique versions of open source licenses. Obviously, this has become a major part of the software application industry, and it must be an important consideration in the development and use of application software within any organization or even for an individual developer. Many businesses and organizations use open-source software as part of their normal business operations and as internal business tools. Specifically, considerable software development is done by using open- source software development tools. Figure 14-11 illustrates a few of the many types of open-source software.

The business model for open-source software is also an interesting phenomenon. Because the software isn't sold or licensed for a fee, there has to be some other method for generating revenue. There are all types of organizations that develop open-source software—from individual programmers to large foundations or organizations. The methods for

462 463

463

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

licensed for a fee, there has to be some other method for generating revenue. There are all types of organizations that develop open-source software—from individual programmers to large foundations or organizations. The methods for funding these organizations also vary widely. The most obvious method, of course, is to request donations— either from individuals or other businesses. The developing organization will often have additional products or services that are sold for a price. Such things as installation services, code modification services, training, or technical support can also provide revenue. Another option is to have multitier or proprietary add-ons to the source code. Often, a base system is free, but a professional version with additional capabilities is sold for a price or for a subscription fee. Finally, some organizations have internal open-source groups that are funded by the organization itself. Universities have often begun research projects that became well-accepted open-source applications or system software. In addition to universities, some businesses believe that participation in the open-source community makes good business sense and will fund projects and applications for open-source distribution.

FIGURE 14-11 Several open-source software applications

464

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

Perhaps the most interesting aspect of open-source software is how the development work gets done. For small open-source projects, an individual often develops the system based on his or her own knowledge and skills. Similarly, some projects have two or three developers who have worked together on other projects and who pool their skills and resources to develop the system. However, for large projects—for example, Apache, PostgreSQL, or WordPress—a large group of developers is involved. Endeavors such as these usually have several ongoing projects and function much like a major organization. One major difference is that the organization that develops the system may not have an office or central location. Meetings and communication are often done entirely through online tools and online documentation. Figure 14-12 lists some of the groups that may be involved in a large open source project. Remember that for most large projects, the participants reside in locations throughout the world. Communication and coordination are done entirely through e-mail, online meetings, conversations, bulletin boards, discussion groups, and tracking logs.

FIGURE 14-12 Open-source software types of stakeholders

The Web as an Application Platform As the use of the Internet in mobile and computing devices becomes more widespread, a fundamental shift in our society—the way we work and the way we interact—is occurring. For many people—either at work or at home—the Web browser is the computer program they use the most; in fact, for some people, it is the only application they use. For many others, Web-based applications are used in almost all aspects of their employment. This trend toward immediate connectivity has also caused a fundamental shift in software development and deployment. The Web has become the primary environment for the deployment of new software applications and systems. The majority of new applications are being written for the Internet—either as browser-based applications or as freestanding Internet applications.

Development of this type follows the same pattern that has been discussed throughout this book. In this section, we focus on browser-based applications as a new type of development platform for application software.

464 465

465

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

focus on browser-based applications as a new type of development platform for application software.

FIGURE 14-13 Evolution of the types of Web pages

Three major types of Web applications can be identified, as shown in Figure 14-13. The first type—Web pages— became prevalent in the mid- to late 1990s. These pages weren't really applications. They were information documents with static text, static images, and hyperlinks to navigate from page to page throughout the site. Their intent was to provide information and content via a hypertext type of document. Forms were also supported to enter information to be sent back to the site and captured by a program running on the server.

The second type of Web site began to appear early in the 2000s. These sites were more interactive, with animated graphics and plug-in modules that allowed richer content, and the functionality began to approach desktop applications. During this period, many new tools were invented to make Web sites much more dynamic, including such things as Java applets, Active X controls, and JavaScript scripting language. Other browser plug-ins—such as Flash, QuickTime, and Shockwave—allowed Web pages to function as rich applications that delivered all types of multimedia. The addition of efficient back-end databases permitted more dynamic information to be added to these pages. This was the era of attractive and engaging Web sites.

Web 2.0 a loosely defined, nonstandard term used to refer to Web sites that permit user-generated content and user interaction, such as social networking sites

Most recently, we have seen the rapid growth of Web sites that are not only dynamic but are also truly interactive— much like desktop applications. In 2004, the term Web 2.0 was first used to characterize this Web trend. It hasn't been precisely defined, but it generally refers to these highly interactive Web sites. Another term for this type of Web site, which we will discuss later in this section, is Rich Internet Application (RIA). The tools that allow these types of Web sites include more advanced JavaScript capabilities, such as Ajax, Java applets, widgets, plug-ins, and other components that execute within a browser on the user's Internet device. These not only allow interaction with the Web site via

465 466

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

sites include more advanced JavaScript capabilities, such as Ajax, Java applets, widgets, plug-ins, and other components that execute within a browser on the user's Internet device. These not only allow interaction with the Web site via hotlinks, but they also support interaction and processing on the Web page itself. Thus, these pages function like a desktop software application.

In addition to interactivity, a major element of this recent phase is the ability to communicate and collaborate by using Web technology within the browsers. Such things as chatting, conferencing, sharing documents, and sharing photos and other personal relics have added a social collaboration element to Web sites. Increasingly, the users themselves are using these tools to set up their own Web sites as blogs, wikis, or accounts on such sites as Facebook and Twitter. In fact, today the largest use of the Internet is for social networking. Thus, whereas most Web sites 10 years ago were created by existing organizations and businesses, there are many more Web sites today created by indivi duals for personal reasons or to start a small business. Anyone can learn the opinions of others, express their own opinions, set up a blog, or even begin an online service or business. Web-based tools are available for all types of users to do almost anything on the Web.

The Internet is so all-encompassing today that it is next to impossible to categorize all the tools, techniques, methods, approaches, and capabilities that are found there. And, of course, it is an evolving landscape. Some of the tools and techniques that are popular today will continue to grow; others will fade away. In the following sections, we discuss three areas of Web application development. However, it should be recognized that these three topics aren't generalized classifications and especially not mutually exclusive topics.

Add-ons and Application Program Interfaces (APIs) APIs are a powerful technique in the growth of capabilities for Web-based systems. In Chapter 10, an API was defined as the set of public methods that are exposed to external systems. In other words, they are the method names that any external component utilizes to plug into the system. Most OSS applications are also distributed with API documentation. However, many proprietary systems also publish an API so other developers can provide additional tools for users of these systems. Let us define a few of these terms and look at some examples.

Types of Web Software Components

plug-ins a software component that adds specific capabilities to a larger software application

Plug-ins are software components that add specific capabilities to a larger software application. They are found at many different levels of Web applications. Some work directly with the browser—for example, ones that allow browsers to play video, scan for malware, or add developer tools. In addition, many Web applications have plug-ins —for example, the OSS application WordPress. WordPress is a blogging software application that users can download and host on a server. It has many third-party functions (i.e., written by non-WordPress employees) that can be downloaded and installed. These allow WordPress to do such things as caching, keeping statistics, adding more menus, and locking pages. Plug-ins can be written by third parties because WordPress was built with specific access points and has a well-defined API that developers can use to integrate their plug-ins with the system. Figure 14-14 lists a few popular plug-ins for Wordpress blogging software out of the hundreds that are available.

widget a type of plug-in that focuses on enhancing the user interface with additional capability

gadget another term for a widget—often used for widgets that reside on a desktop

A widget is a type of plug-in, but it usually has a user interface component. In other words, it is a plug-in that can be placed on a Web page and is visible to the user. There are two kinds of widgets: browser widgets and application widgets. An example of a browser widget would be a time-and-temperature widget or a stock market widget that is displayed in one corner of the browser. It is always there—no matter what Web page is being viewed at the time. An example of an application widget would be something that enables the user to write blogs by using rich text formatting. A different application widget might maintain and display statistics about the blog, such as user comments or visits to the page. A gadget is another term that is used to describe a widget. Gadgets are most frequently used on a desktop, although some Web sites refer to their widgets as gadgets. Figure 14-15 illustrates

466 467

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

comments or visits to the page. A gadget is another term that is used to describe a widget. Gadgets are most frequently used on a desktop, although some Web sites refer to their widgets as gadgets. Figure 14-15 illustrates some Google gadgets that are available for Web pages for Google accounts.

theme a type of add-on to an application that allows the look and feel, such as colors and layout, to be changed

A theme is a type of add-on that focuses on the look and feel of either the browser or the Web application. The development and use of a theme depends on the availability of an API that defines how to integrate CSS files and images into the application. Themes are a powerful technique that can drastically change the entire layout and look of a Web page. An example that shows dramatic differences of exactly the same content but with different themes is found at www.csszens.arden.com.

FIGURE 14-14 Sample plug-ins available on a WordPress blog

FIGURE 14-15 Sample Google Web page gadgets

467 468

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

toolbar a type of add-on usually comprised of iconic menu items that access the capabilities of the application or plug-ins in a user friendly fashion

A toolbar is a type of add-on that can provide multiple capabilities to the browser. It functions a little like a menu in that it provides a selection of functions or hotlinks for the user. Browser toolbars can be supplied by the browser provider; third-party toolbars are also available. These often consist of links that go to specific services provided by the third party. Toolbars may also be added to specific pages as part of the installation of a plug-in. If the plug-in has various functions that it can perform, it can add a menu or a toolbar to allow the user to access those functions.

Web mini-app a software application that provides a complete set of functions but that must be executed within the confines of another application

Web mini-apps—sometimes referred to as Web apps—come in many varieties. Some of them are stand-alone applications that don't require a browser— for example, those that are available for such smartphones as iPhone and Android. (This is probably the largest number of apps available today.) Many of these function as desktop or device-top applications and don't require a browser to execute. Others are complete Web sites and execute their code within the browser. Still other mini-apps are plug-ins that are attached to a parent Web site and can only be accessed through the parent. Perhaps the most common example of these are Facebook apps. Facebook provides an extensive API definition that allows third-party developers to create many different types of games, personal apps, and even commercial apps.

Development Historically, most software was developed by organizations—either regular businesses for their internal use or software development firms. However, open source software, Web mini-apps, and add-ons are being developed by entrepreneurial independent programmers. Literally tens of thousands of programmers have joined the ranks of independent entrepreneurs. The locus of software development has moved out of business and industry and into the consumer arena. Everyone wants “cool stuff” for their phones, tablets, and gaming devices, which has nothing to do with such business applications as accounting or inventory management.

Another reason a cottage industry has developed is the ease of entry into software development. In the past, software development required large mainframes or large servers that cost hundreds of thousands if not millions of dollars. Only those corporate employees with access to these expensive resources could be programmers or developers. Today, anyone with a laptop and access to the Internet can obtain open-source software and begin developing applications.

In earlier chapters, we discussed the various stakeholders in the development of a software system. These include the client, the user, the architect, the analyst, the designer, and the programmer. When an entrepreneur develops software, he or she plays all these roles. Problems can occur if the developer's view of the problem to be solved is too limited. However, in some situations, the scope of the application is often small enough that even that isn't a major problem.

Mashup Applications

mashup a type of Web site that combines the functionality of several other Web sites through the use of predefined APIs

The open-source perspective also permeates the development and use of Web applications. Today, thousands of Web sites provide APIs to access the various services provided on the Web site. Through the use of these open APIs, the services on one Web site can be added to the total presentation of a different Web site. The idea of a mashup is to “mash” the services of two or more Web sites together to provide a new service or new way of viewing information.

468 469

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

services on one Web site can be added to the total presentation of a different Web site. The idea of a mashup is to “mash” the services of two or more Web sites together to provide a new service or new way of viewing information. Mashups are an important trend in software, particularly social software and Web 2.0.

Obviously, the key to mashups is the availability of open APIs provided by various Web services. You will remember that an API is defined as a set of method calls to a class or a component. For Web-based APIs, those calls are expressed as particular URLs, which return to the originating source Web site. In other words, a mashup is a combination of data or services from multiple, physically separated Web sites.

One way to categorize these APIs is by whether they provide data or a service through this URL access.

Data-type APIs often provide indexes of documents, images, videos, or items for sale. Another example of a data- type API is a news aggregator for news feeds or podcasts. Service-type APIs do such things as convert data from one form to another—for example, a language translator or a URL shortener. Another example of a service-type API is a security Web site that performs authentication or encryption. Communication services, such as instant messaging or e-mail, can also be embedded within a parent Web site through a service type API. Of course, some APIs provide both. For example, the Google Maps API not only provides the raw geolocator information but will render it in a user-friendly viewer.

The more popular open APIs used in mashups include Google Maps API, YouTube API, Twitter API, Flickr API, Facebook API, eBay API, and Google Search API. Figure 14-16 is a snapshot of a mashup that lets you build your own dashboard page. It uses APIs from many Web sites.

FIGURE 14-16 Mashup of several APIs to create a dashboard page

469 470

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

FIGURE 14-17 Comparison of results from Google and Yahoo! search engines

From a developer's viewpoint, open APIs are a simple yet powerful tool to enhance and extend a Web site. In fact, some APIs are so simple that the end users are able to add functionality to their Web site themselves. It isn't uncommon to have personal blogs or Web sites with search boxes, maps, or videos embedded in the Web site. This trend will probably continue as more open APIs are made available. Figure 14-17 shows a Web site that compares the capability of Google and Yahoo!'s search engines. In this case, two simple APIs are used and then the results are displayed in an interesting graphical format.

Rich Internet Applications (RIA)

Rich Internet Applications (RIAs) a type of Web site that provides active user interaction as well as delivers rich multimedia

Another very powerful trend in the use of the Web as an application platform is the development of Rich Internet Applications (RIAs). An RIA is a Web application that is built to have the same rich functionality and responsiveness as a desktop application. Because it is Internet connected, it also frequently delivers rich multimedia. Desktop applications can be very versatile and extremely responsive—their functions constructed to do exactly what the user requires— with a very efficient and rapid response. In addition, the layout and presentation of the desktop can be tailored for optimal user friendliness.

Historically, Web applications have had more limited capabilities. As explained previously, the early vision of the Web (and hence the development of Web browsers) was as a means of presenting information. Recently, however, as more tools have become available, Web applications have permitted a much richer user experience, with many

470 471

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

Web (and hence the development of Web browsers) was as a means of presenting information. Recently, however, as more tools have become available, Web applications have permitted a much richer user experience, with many services and capabilities. Today, Web applications are approaching desktop applications in versatility and usability.

471 472

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

The key to the development of RIAs is the addition of computing on the local client computer—within the browser itself. The delay going to and from the server prohibited a rapid and rich user experience in purely URL-driven Web sites. RIAs require enhanced computing capability locally and limited round trips to the server. We will now describe five of the major approaches to developing RIAs. As is frequently the case, there are open-source solutions, proprietary solutions, and standard specifications for new browser capabilities. It will continue to be an interesting world for developers and users as these various platforms compete and migrate to new levels. It is difficult to illustrate in a single image all the power and capability of an RIA Web site. Figures 14-18 and 14-19 illustrate two Web sites that include interesting animation and allow dynamic user interaction.

JavaScript and Ajax Libraries JavaScript has become the de facto standard for adding desktop-like computing within browsers. It is a powerful, object-based scripting language that can detect and trigger actions based on keystrokes within browsers. It is also used to access and manipulate all the components on the Web page as part of the document object model (DOM). (This is a hierarchical tree dynamically built by the browser of every element on a given Web page.) Detecting keystrokes and manipulating the DOM are two critical factors that allow JavaScript to support almost any type of desktop-like behavior that is limited to the local client.

In the late-1990s, Microsoft developed a set of JavaScript methods and techniques to allow data access to the server in order to dynamically update and manipulate the Web page without having to refresh the entire Web page. This set of methods and techniques, termed Ajax (an acronym for Asynchronous JavaScript with XML), allows the Web application to communicate with the server in the background (asynchronously) to request data, wait for it, and then process it when it arrives. This added capability permitted JavaScript to extend its desktop-manipulation capabilities to include dynamic data updating.

FIGURE 14-18 RIA from Nike Plus

472

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

FIGURE 14-19 RIA from Mini Cooper

The ability of JavaScript to support rich Web apps has been enhanced by the proliferation of libraries of JavaScript tools. The most popular libraries include Dojo, jQuery, MooTools, and YUI (Yahoo! User Interface). With the use of one of these libraries, Web site developers have a whole set of functions—such as user interaction, grids, graphs, Ajax, widgets, forms, and pop-ups—that add the richness of a desktop application to a Web page.

ICEFaces and JavaFX ICEFaces is an open-source framework that provides Java language APIs to build and deploy server-based RIAs. The underlying framework that enables ICEFaces is Ajax; hence, it depends on the JavaScript language but doesn't require programmers to interact with JavaScript. ICEFaces applications are JavaServer Faces (JSF) applications and are included in the Java Enterprise Edition toolset. The purpose of ICEFaces is to enable Java developers to utilize their skill set with the Java EE development model and to protect them from doing low-level JavaScript and Ajax programming.

Another, more recent Java-based toolset is JavaFX, which was introduced in 2007. As a relatively new language and platform, it is in the early stages of providing comprehensive support for RIAs. However, JavaFX consists entirely of Java constructs, and it executes as part of the Java Virtual Machine (JVM) runtime environment. Because it runs under the Java Runtime Environment (JRE), it can be used to build RIAs for most devices that can run the JRE. For JavaFX 1.3, this includes desktops, browsers, and mobile phones. Another advantage of using the JRE to produce RIAs with JavaFX is that there is more consistency across browsers and platforms than with languages, such as JavaScript, that depend on the implementation provided by each browser.

472 473

473 474

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

languages, such as JavaScript, that depend on the implementation provided by each browser.

Adobe Flash Platform The Adobe Flash platform was introduced in 1996 and is best known as a multimedia platform for adding animation and interactivity to Web pages. Flash's power is in its ability to animate many elements on a Web page. It can capture user input from all computer components, including a mouse, a keyboard, a microphone, or a camera. It also supports bidirectional streaming of audio and video. The Adobe Flash player is available on desktops, within browsers, and on some mobile phones (but not the iPhone). With this rich history and background, Adobe has extended the Flash platform to enable the development and deployment of RIAs. One major advantage of Flash is that the Flash player has a 95-99 percent penetration rate on computers. It also has a very rich set of multimedia functions that are supported by a deep set of development tools. However, Flash is a proprietary product owned and licensed by Adobe and hence must be licensed from Adobe, although some components have been released as open-source products.

Microsoft Silverlight Microsoft Silverlight is an application framework, similar to Adobe Flash, that is part of Microsoft's Windows Communication Foundation (WCF) .NET RIA Services to support the development and deployment of RIAs. Silverlight was introduced in 2007 and went through several rapid iterations before reaching a rich set of components to enhance the user experience with Silverlight 5, which was released in the fall of 2011. Silverlight requires a plug-in to execute, and plug-ins for all the major browsers are available for download. As of 2011, it had a penetration rate of approximately 75 percent; thus, it has grown very rapidly, although not as rapidly as JavaScript or Adobe.

A Silverlight application is developed as part of a Web Services application within the WCF .NET RIA services. The Web Services app provides the functionality on the server side, and the Silverlight app provides the functionality on the client side. User interfaces are defined by using Extensible Application Markup Language (XAML), which can be used to define graphics and animations that execute within the browser plug-in. Data access is also done asynchronously; thus, pages can dynamically send and retrieve data to and from the server without reloading pages.

HTML5

HTML5 the new HTML specification that standardizes RIA specifications for built-in browser delivery

The World Wide Web Consortium (W3C) is the body that defines standards for HTML and XHTML. As these standards are defined and agreed upon, all Web browsers are expected to conform to them. Of course, in the real world, standards aren't always conformed to, and even when a standard is agreed upon, differences in implementation frequently produce different results. The Web Hypertext Application Technology Working Group (WHATWG), a working group of the W3C, began developing HTML5 in 2004, and in 2008, it published the first working draft of the specification. As of 2011, the specification is still in the Last Call stage of the Working Draft, with a target date for Recommendation of 2014. Even though it appears that the specification won't be fully completed for years to come, in reality, many of RIA capabilities identified in the specification have already been implemented in today's browsers. In fact, some proponents of HTML5 see it as the wave of the future, replacing other RIA approaches.

The advantage of the HTML5 specifications for RIA Web pages is that rich presentation of audio, video, graphics, and animation is built into the browsers, without the need for specialized plug-ins or languages. For example, the new HTML5 has such tags as <video>, <audio>, and <canvas> as well as other vector graphics manipulation tags to provide rich display of data and images. The specification also includes APIs that can be used for manipulating elements on a Web page. Such APIs as drag-and-drop, file handling, geolocation, and SQL database access are included in the specification.

474 475

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

database access are included in the specification.

Chapter Summary One of the most active trends in software development is adaptive development methodologies. The world is changing in many ways, with new consumer devices, new services, and new technology. To keep pace with these changes, the way software is developed has also changed.

The most formal adaptive process is the Unified Process (UP). It was one of the first methodologies to be formalized, with specific definitions for iterations and processes. Other more radical adaptive methodologies are now being promoted and used. Two of the more popular ones are Extreme Programming and Scrum.

Extreme Programming (XP) and Scrum are methodologies that embody Agile principles. Two core elements of XP are that system tests are written first and that programmers work in pairs to design, code, and test the software. Thus, when a function is completed, it has not only been designed and coded, it has been reviewed and tested.

The Scrum approach defines a specific goal that can be completed within four weeks. During that four-week sprint, the project team is protected from all outside distractions so it can complete the defined goal. A product backlog of all outstanding requests is maintained by the client, and changes to the work the team is doing are only allowed between sprints.

Major trends in technology, mobile computing devices, software availability, and Web access are the driving forces behind the need to develop application software more rapidly.

Client computing devices include all those devices that allow users to communicate, play games, retrieve information, and perform other life-related tasks. The most common client computing devices are desktop, laptop, and notebook computers. However, the number of computers will soon be surpassed by the number of mobile devices, such as smartphones and tablet computing devices. These devices have become so pervasive because of the expanded availability of Internet access through wireless and telephone connections. Finally, the availability of so many connected computing devices has necessitated the growth of large-scale data centers with very large server farms. These server farms, which sometimes consist of thousands of computers, are needed to support the Internet activity of popular Web sites and applications.

Historically, most software was developed within large organizations and was private to that organization. However, there is a trend toward sharing software applications among many users and organizations. One such method is called Software as a Service (SAAS), in which third-party companies have software that can be used by many companies. Instead of delivering and installing the applications to the purchasing organization, only the use of the software is sold. The idea is to sell a service, such as accounting, the same way a utility is sold to individual households.

Another trend is providing software applications free of charge as open-source software. Open-source software is usually developed by individuals and teams of people that are distributed throughout the world and work together on an application in a loosely configured project. The business model for this type of development is to not generate revenue from the basic application but sell addon services and capabilities.

A final—and extremely important—trend is the use of the Web as an application platform. The largest percentage of new application software being developed is for Web applications. Coupled with the open-source software trend, many Web-based software applications provide APIs so Web-based applications can share functionality and even be combined to provide new uses of Web-based software. Most Web sites are also including sophisticated local computing capabilities to provide a Rich Internet Application (RIA). RIAs allow a Web based application to function much like a desktop application, with multimedia and active user interactions.

Key Terms browser-based application 458

device-top application 458

free-standing Internet applications 458

475 476

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

free-standing Internet applications 458

gadget 467

HTML5 474

Internet backbone 459

last mile 459

mashup 469

on-demand software 461

open-source software 462

pair programming 452

plug-ins 467

product backlog 455

product owner 455

refactoring 452

Rich Internet Applications (RIAs) 471

Scrum master 455

software as a service (SAAS) 461

sprint 456

theme 467

toolbar 469

UP discipline 447

Web 2.0 466

Web mini-apps 469

widget 467

Review Questions 1. What are the four UP phases, and what is the objective of each?

2. What are the six UP development disciplines?

3. What are the three UP support disciplines?

4. List the basic principles of Agile Modeling.

5. Why is the word extreme included as part of Extreme Programming?

6. List the core values of XP.

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

6. List the core values of XP.

7. List the XP practices.

8. What is the product backlog used for in a Scrum project?

9. Explain how a Scrum sprint works.

10. Explain the difference between device-top applications, free-standing applications, and browser-based applications.

11. What is the “last mile” problem?

12. Explain what SAAS is and why it is an economically attractive alternative.

13. What are the six licensing criteria that are usually associated with open-source software?

14. List eight or 10 popular open-source applications. You may include some not mentioned in the text.

15. Explain the evolution of Web pages.

16. Explain how an API works.

17. What is the difference between widgets and plug-ins and themes?

18. What is meant by Web 2.0?

19. What is a mashup and why is it an important contribution to Web 2.0?

20. What is an RIA and why is it an important contribution to Web 2.0?

21. What is the difference between JavaScript and JavaFX?

22. What is HTML5?

Problems and Exercises 1. The Unified Process (UP) was first developed by a company called Rational, which is now owned by IBM. On

the IBM Web site, find any information about UP tools available through IBM/Rational. Briefly describe the suite of tools available. Also, look on the IBM Web site and other Web sites (such as the Agile Modeling Web site) for opinions on the relationships and commonality between the UP and Agile Modeling. Report your findings.

2. Consider XP's team-based programming approach in general and its principle of allowing any programmer to modify any code at any time in particular. No other development approach or programming management technique follows this particular principle. Why not? In other words, what are the possible negative implications of this principle? How does XP minimize these negative implications?

3. Visit the Web sites of the Agile Alliance (www.agilealliance.org) and Agile Modeling (www.agilemodeling.com). Find some articles on project management in an Agile environment. Summarize key points that you think make project management more difficult in this environment than in a traditional, predictive project. Do the same for key points that make project management easier for an Agile project.

4. Visit the Web site of the World Wide Web Consortium (www.w3.org) and review recent developments related to the HTML5 standard. What are some of the basic components of the standard? What are the major additions to HTML4?

5. Find a company in your community that uses Scrum or XP (or variations thereof) as its development methodology. Learn how the company has applied the methodology and how it applies the principles and practices. Also, research what development tools it uses and how well the methodology is supported.

476 477

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

practices. Also, research what development tools it uses and how well the methodology is supported.

6. Find someone in your community who is working on a software development project that is using Agile principles. How was the team trained to use Agile Development? How was this approach adopted in the organization? What is the general feeling about its success? What aspects does this developer like? Which aspects does he or she find frustrating or difficult to use?

Case Study

Midwestern Power Services Midwestern Power Services (MPS) provides natural gas and electricity to customers in four Midwestern states. Like most power utilities, MPS has seen significant changes in federal and state regulations in the last several years. Federal deregulation opened the floodgates of change, but there was little guidance from the federal government on how that would shape the industry's future. State legislatures also significantly changed their laws and regulations. The industry went through tremendous upheaval, with significant problems created by power shortages at several California power companies. Today, regulations such as the Sarbanes-Oxley Act are changing the landscape again. These new regulations seriously affect all areas of business, including accounting, record keeping, power purchases, distribution agreements, and customer consumption and billing.

New and proposed regulations seek to increase controls and expand competition for electricity and natural gas. The final form these regulations will take is unknown, and the exact details will probably vary from state to state.

MPS needed to rapidly prepare its systems for these new regulations. Three systems are most directly affected: one for purchasing wholesale natural gas, one for purchasing wholesale electricity, and one for billing customers for combined gas and electric services. The billing system isn't currently structured to separate supply and distribution charges, and it has no direct ties to the natural gas and electricity purchasing systems. MPS's general ledger accounting system is also affected because it is used to account for MPS's own electricity generating operations.

MPS plans to restructure its accounting, purchasing, and billing systems in the following ways:

▪ Customer billing statements will clearly distinguish between charges for supply and distribution of gas and electricity. The wholesale suppliers of each power commodity will determine prices for supply. Revenues will be allocated to appropriate companies—for example, distribution charges to MPS and supply charges to wholesale providers.

▪ MPS will create a new payment system for wholesale suppliers to capture per-customer revenues and to generate payments from MPS to wholesale suppliers. Daily payments will be made electronically based on actual payments by customers.

▪ MPS will restructure its own electricity-generating operations into a separate profit center—similar to other wholesale power providers. Revenues from customers who choose MPS as their electricity supplier will be matched to generation costs.

MPS's current systems were developed internally many years ago. The general ledger accounting and natural gas purchasing systems are mainframe based. They were developed in the mid-1990s, and incremental changes have been made ever since. All the programs are written in Visual Basic; DB2 (a relational DBMS) is used for data storage and management. There are approximately 50,000 lines of Visual Basic code.

The billing system was rewritten from the ground up in the mid-1990s and has been slightly modified since that time. The system runs on a cluster of servers that use the UNIX operating system. The latest version of

Oracle (a relational DBMS) Is used for data storage and management. Most of the programs are written in C++, although some are written in C and others use Oracle Forms. There are approximately 80,000 lines of C and C++ code.

477 478

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

code.

MPS has a network that is used primarily to support terminal-to-host communications, Internet access, and printer and file sharing for personal computers. The billing system relies on the network for communication among servers in the cluster. The servers that support the accounting and purchasing systems are connected to the network, although that connection is primarily used to back up data files and software to a remote location.

MPS is currently in the early stages of planning the system upgrades. It hasn't yet committed to specific technologies or development approaches. It also hasn't yet decided whether to upgrade individual systems or replace them entirely. The target date for completing all system modifications is three years from now, but the company is actively seeking ways to shorten that schedule.

1. What would you recommend as an approach to upgrading the three listed applications—a single total project or three individual projects? Explain your decision.

2. Describe the pros and cons of the UP approach versus XP and Scrum development approaches to upgrading the existing systems or developing new ones. Do the pros and cons change if the systems are replaced instead of upgraded? Do the pros and cons vary by system? If so, should different development approaches be used for each system?

3. Assume that MPS has had very little experience with developing projects by using adaptive techniques. Do you think it would be viable for them to attempt an adaptive approach for these three systems? What would be your recommendation for each? Which method would you recommend and why?

4. Assuming MPS decided to use one of the three methodologies discussed in the chapter, make a list of potential problems and the steps they should take to avoid those problems. List any activities they should consider to ensure success.

5. Assuming that MPS decided to develop and deploy each system individually, what would you recommend for a development approach? Would you recommend any SAAS solutions? Would you recommend using MS Visual Studio and IIS or a Unix environment by using some open-source applications? Explain your decision.

RUNNING CASE STUDIES

Community Board of Realtors The Community Board of Realtors Multiple Listing Service is a small system with limited requirements. In Chapter 9, you identified a complete list of use cases and divided the system into two subsystems. Using the results from your earlier work, please do the following:

1. Based on Figure 14-6—the XP methodology— divide your use cases into releases and iterations within each release. Develop a project iteration plan that includes the necessary activities at each level (system, release, iteration) for integration testing and acceptance testing. Compare your answer to this question to the project iteration plan you developed for Chapter 9.

2. Discuss the requirements of this system for mobility devices. What use cases would be best utilized on a mobile device? What use cases would be best with a desktop user interface?

3. Would this application be suited as an SAAS application? What would be critical factors for a company to consider if it wanted to offer an SAAS version of this application?

4. Can you identify any use cases that would best be implemented as a mashup Web application? Discuss which ones might fit this requirement and why?

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

which ones might fit this requirement and why?

The Spring Breaks 'R' Us Travel Service Recall from Chapter 2 that SBRU's initial system included four major subsystems: resort relations, student booking, accounting and finance, and social networking.

In Chapter 9, you developed a comprehensive list of use cases for each of the four subsystems. You also developed a project plan by using the adaptive SDLC and other principles that you learned in this textbook. For this chapter, you will develop a project plan by using XP. The approach for ordering the use cases will be based on user interface issues.

1. For each subsystem, build a table with the following columns:

a. Use case name—as defined in Chapter 9

b. Primary use device—whether this use case will be used primarily on a mobile device or a desktop device or equally prevalent on each

c. Development platform—whether this use case best fits as a desktop app, a free-standing Internet app, or a browser-based app

d. RIA—whether this use case should be an RIA (for browser-based applications)

2. Based on your table from question 1, organize the use cases by using two criteria:

a. The logical ordering based on functional similarity (i.e., as you did in Chapter 9)

b. Group them together as much as possible based on primary use device, development platform, and RIA characteristics. In other words, you are trying to help the team so everyone is building similar types of use cases together.

3. Assuming two separate XP programmer teams, build a project iteration plan as you did in Chapter 9.

On the Spot Courier Services As you read this chapter, you probably noted that the development methodology used in this textbook has many things in common with the Unified Process, Scrum, and Extreme Programming. In fact, our objective in this textbook is to teach you the principles common to all these methodologies without forcing you to accept only one.

Given these four methodologies—Satzinger Jackson-Bird (SJB), UP, Scrum, XP—and what you now know about Agile and iterative development, do the following for the development of the On the Spot system:

1. Choose a single methodology. Why did you choose that one?

2. Mix and match practices from each methodology. Discuss which ideas you like from each methodology.

Given the trends in new technology, software availability, and the Web as an application platform, answer these questions:

1. What kind of equipment would be best and most stable for the truck drivers to use?

2. What would you recommend as the development approach and platform: a custom application using Visual Studio and .NET, a custom application using Java or similar language, a Web application using ASP.NET, a Web application using PHP and JavaScript, or some other combination. Discuss your recommendation.

478 479

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

recommendation.

Sandia Medical Devices Based on the discussion of hardware, Internet, and software technology trends in this chapter, it should be clear to you that the Real-Time Glucose Monitoring (RTGM) system is an interesting combination of older and newer technology. Except for the interface to software and data on mobile phones, the server-side portions of the system are a relatively traditional business-oriented application that can be implemented by using old-fashioned technology. What makes the RTGM system “new” are its clientside functions, including the automated collection of glucose levels, the regular transmission of that data to servers, the integration of communication between patients and health-care providers, and the integration of those functions within software installed on a portable device that can be carried in a user's pocket. With that in mind, answer the following questions. You may need to do some additional research to fully address them.

1. The chapter classified apps on portable devices as device-top, free-standing Internet, and browser based. Which type is most appropriate for the client-side portions of the RTGM system? Be sure to consider such issues as client-server communication requirements and frequency, user interface quality, and portability across devices and operation systems.

2. Which (if any) social networking capabilities might make a useful addition to the RTGM system? Be sure to consider the HIPAA requirements described for this case at the end of Chapter 6.

3. When recorded glucose levels generate high priority alerts, physicians or other health-care providers initiate direct contact with the patient. An ordinary phone call over the cellular phone network is one way to support direct contact. Because any client-side device used with the RTGM system must be fully Internet-capable, an Internet telephony application, such as Skype, is another possible way of supporting synchronous voice or video communication with the patient. Should Skype or a similar Internet telephony application be used with the RTGM system? Why or why not? If such an application is used, should it support video? Why or why not? Data mining is an increasingly important technique for medical research. The ability to scan medical records of large numbers of patients over extended time periods enables researchers to better evaluate the effectiveness of drugs and therapies, more accurately connect disease risk levels to specific patient characteristics, and identify patterns of transmission or occurrence, progression, and treatment response for rare diseases and conditions. What types of medical research might be enabled or better supported by the data collected by the RTGM system? Would your answer change if the database were extended to include additional information that might be gathered from the patient's mobile phone (e.g., location information when each glucose level was captured, size and content of the patient's contact list, call history, and the volume of text messages and Internet browsing activity)?

Further Resources Agile Alliance, www.agilealliance.org.

Scott W. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. John Wiley and Sons, 2002.

Scott Ambler, John Nalbone, and Michael J. Vizdos, The Enterprise Unified Process: Extending the Rational Unified Process, Prentice Hall, 2005.

Ken Auer and Roy Miller, Extreme Programming Applied: Playing to Win. Addison-Wesley, 2002.

Kent Beck, Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.

Mike Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley, 2010.

Philippe Kruchten, The Rational Unified Process: An Introduction. Addison-Wesley, 2004.

Craig Larman, Agile and Iterative Development: A Manager's Guide. Addison-Wesley, 2004.

479 480

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

Craig Larman, Agile and Iterative Development: A Manager's Guide. Addison-Wesley, 2004.

“Manifesto for Agile Software Development,” Agile Alliance, www.agilemanifesto.org.

Pete McBreen, Questioning Extreme Programming.

Addison-Wesley, 2003. Andrew Pham and Phuong-Van Pham, Scrum in

Action, Course Technology, 2011.

Ken Schwaber and Mike Beedle, Agile

Software Development with Scrum. Prentice Hall, 2002.