please answer all 4 questions
migzs
chapter_14_outline.docxChapter 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 project’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 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.
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.
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 adaptive 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.
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.
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
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.
UP discipline a set of functionally related activities that combine to enable the development process in a UP project
FIGURE 14-3 UP disciplines used in varying amounts in each iteration
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
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 discipline), 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
· 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.”
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 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.
pair programming XP practice in which two programmers work together on designing, coding, and testing software
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 the Code Refactoring is the technique of improving the code without 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 produces high-quality, robust code.
refactoring revising, reorganizing, and rebuilding part of a system so it is of higher quality
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.
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 understood 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 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
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
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.
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.
product backlog a prioritized list of user requirements used to choose work to be done in a Scrum project
Scrum Organization
The three main organizational elements that affect a Scrum project are the product owner, the Scrum master, and the Scrum team or teams.
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 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
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.
sprint a time-controlled mini-project that implements a specific portion of a system
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.
We will discuss the technology infrastructure in the following three areas: client and end-user devices, Internet and telephone communications, and backend 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 technology 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 application 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.
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
FIGURE 14-8 iPhone with several applications
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
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 networks. 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.
Internet backbone the primary data routes between large, strategically interconnected networks and routers on the Internet
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 Internet-enabled 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.
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.
last mile the final leg that delivers connectivity from the Internet network to the customer
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. 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.
FIGURE 14-9 Server farm within a data center
Eimantas www.Buzas/Shutterstock.com
Trends in Application Software Availability
