Acquiring Information Systems and Applications

CHAPTER OUTLINE LEARNING OBJECTIVES

13.1 Planning for and Justifying IT Applications 13.1 Discuss the different cost–benefit analyses that companies

must take into account when formulating an IT strategic plan.

13.2 Strategies for Acquiring IT Applications 13.2 Discuss the four business decisions that companies must make

when they acquire new applications.

13.3 Traditional Systems Development Life 13.3 Enumerate the primary tasks and the importance of each of the Cycle six processes involved in the systems development life cycle.

 

13.4 Alternative Methods and Tools for Systems 13.4 Describe alternative development methods and the tools that Development augment these methods.

 

 

 

 

 

 

 

 

Opening Case

CHAPTER 13

 

Peoples State Bank Transforms Its Information Technology

The Business Problem

With 15 full-service retail and commercial locations, Peoples State Bank (PSB; www.bankpeoples.com ) has provided cen­ tral and northern Wisconsin residents and locally owned businesses with traditional retail and commercial banking products since 1914. Businesses this old often have information systems that have become outdated and no longer meet their needs. These systems, referred to as legacy systems, often hinder modern business operations. This was the case with PSB.

MIS MKT

 

PSB’s strategic goals are to provide its customers with a superb experience and its employees with the best possible tools and re­ sources. Unfortunately, the bank’s legacy systems were impeding its ability to accomplish those goals.

Legacy systems in banking provided the core processing neces­ sary to handle simple account transactions such as deposits, with­ drawals, and payments. These systems were expensive to build,

 

 

 

because they required on-premise hardware, software, and network­ ing technologies. (We discuss on-premise computing in Technology Guide 3.) In general, legacy systems at banks were developed to sup­ port hard copy, paper-based transactions. These legacy systems be­ came ineffective over the years because they did not support different ways for customers to interact with the bank (e.g., online from comput­ ers, tablets, and smartphones).

Banks were very slow to respond to online business models be­ cause their business processes were built on legacy systems that were not designed to engage customers online. Specifically, PSB employed an excessive number of legacy systems, which did not effectively work together. Also, the bank’s information technology platform did not provide the capabilities required for a PSB customer to access account information through a web browser or mobile app.

To offer superb customer experiences and modern banking tools, PSB needed a new IT infrastructure that was designed to han­ dle web and mobile banking and near-real-time customer updates. The challenge was that the bank’s in-house IT expertise was able to maintain the legacy systems, but it lacked the capability to design

 

 

369

 

 

 

370 CHAPTER 13 Acquiring Information Systems and Applications

 

 

Planning for and Justifying IT Applications 371

 

 

or build new systems. For PSB to move forward with their strategic goals, it had to acquire an IT infrastructure that would include the necessary tools to operate in a modern banking environment. Today, when businesses decide to update their systems, they can consider several options.

The Solution

Leif Christianson, PSB’s chief operating officer, spearheaded a com­ plete technology overhaul that moved the bank away from their legacy systems. One option was on-premise computing, in which PSB would develop, own, and operate all parts of its IT function. Alternatively, the bank could outsource the entire system. Both models have their ad­ vantages. Ultimately, PSB determined that providing outstanding cus­ tomer service in banking was its core competency but IT was not. The bank therefore decided that outsourcing would enable it to scale its operations for growth more quickly than if it owned and operated the IT infrastructure. To implement this plan, PSB entered into a service agreement with Jack Henry & Associates (JHA; www.jackhenry.com ) to gain access to the tools and technology it needed without having to develop the expertise within their organization.

JHA, founded in 1976, is a leading provider of computer systems and ATM/debit card/ACH transaction processing services for financial services organizations. (ACH payments are electronic payments that are created when the customer gives an originating institution the au­ thorization to debit directly from the customer’s checking or savings account for the purpose of bill payment.) JHA’s technology solutions serve more than 11,000 customers nationwide. PSB transferred all of their banking information system operations to JHA.

The Results

The conversion from PSB’s legacy system to the JHA solution was a success. This transition brought new core capabilities to the bank. With JHA, PSB is able to offer online banking, mobile banking, customer payment solutions, and other services that were not available with the legacy systems. As a result, PSB’s assets grew from $621 million before the 2010 conversion to more than $828 million in 2016. By outsourcing the capital expense and maintenance of on-premise information tech­ nology, PSB was able to focus on other priorities such as cross-training

employees to help customers in areas where they previously were not able to provide service.

Managing change of this size is often difficult for organizations because employees are frequently resistant. However, PSB convinced its employees of the benefits of the new system. As a result, the bank received quick employee buy-in and cooperation. Employees appre­ ciated the fact that they could now deliver services in the ways their customers wanted.

Today, PSB customers are able to check account information, pay bills and transfer funds, view a detailed transaction history, download statements, deposit checks, and perform other activities through their mobile banking experience. These tools have enabled PSB to compete with much larger banks.

In June 2016, Peoples State Bank announced that it was ranked for the seventh consecutive year in the American Banker magazine’s “Top 200 Community Banks” list.

Sources: Compiled from M. Gardner, “The Biggest Threat to Banks? Legacy Systems, Not Fintech,” The Globe and Mail, November 22, 2016; J. Pilcher, “Core Banking Systems: The Industry’s Achilles Heel,” The Financial Brand, May 11, 2016;

A. Hemon-Laurens, “Banks Don’t Have to Kill Legacy Systems to Be More Agile,” American Banker, April 21, 2016; G. Boskovich, “An Improved Legacy System Is Still a Legacy System,” American Banker, January 11, 2016; D. Verman, “Banks Face Major Pressure to Transform Legacy Payment Systems,” PaymentsSource

.com , July 27, 2015; K. Flinders, “The Obstacles to Software-as-a-Service Adoption in Banking,” ComputerWeekly.com , July 15, 2015; P. Schaus, “Legacy Systems Prevent Banks from Delivering on Digital Promises,” BankInnovation.net , June

1, 2015; K. Burger, “Outsourcing Helps Peoples State Bank Execute Growth Strategy,” Information Week, December 3, 2014; J. Lankenau, “The Benefits of SaaS,” banktech.com , October 9, 2014; K. Flinders, “Big Banks’ Legacy IT Systems Could Kill Them,” ComputerWeekly.com , January 2014; www.bankpeoples.com, peoplesfinancial.com, jackhenry.com, accessed October 29, 2016.

Questions

1. Discuss the problems with PSB’s legacy systems that led to the information technology conversion.

2. Why did PSB decide to outsource their IT rather than developing new systems in-house as they had in the past?

3. What are the potential disadvantages that PSB might encounter from outsourcing its IT function?

 

 

 

 

 

 

Introduction

Competitive organizations move as quickly as they can to acquire new information technolo­ gies or modify existing ones when they need to improve efficiencies and gain strategic advan­ tage. As you learned from the chapter opening case, problems and pitfalls can arise from the acquisition process.

Today, acquisition goes beyond building new systems in-house, and IT resources involve far more than software and hardware. As you saw in the chapter opening case, the old model in which firms built their own systems is being replaced with a broader perspective of IT resource acquisition that provides companies with a number of options. Thus, companies now must decide which IT tasks will remain in-house, and even whether the entire IT resource should be provided and managed by outside organizations. Regardless of which approach an organiza­ tion chooses, however, it must be able to manage IT projects adeptly.

In this chapter, you will learn about the process of acquiring IT resources from a manage­ rial perspective. This means from your perspective, because you will be closely involved in all aspects of acquiring information systems and applications in your organization. In fact, when

 

 

we mention “users” in this chapter, we are talking about you. You will also study the available options for acquiring IT resources and how to evaluate those options. Finally, you will learn how organizations plan and justify the acquisition of new information systems.

 

 

Planning for and Justifying IT Applications

13.1

Organizations must analyze the need for applications and then justify each purchase in regard to costs and benefits. The need for information systems is usually related to organizational planning and to the analysis of its performance vis-à-vis its competitors. The cost–benefit justi­ fication must consider the wisdom of investing in a specific IT application versus spending the funds on alternative projects. This chapter focuses on the formal processes of large organiza­ tions. Smaller organizations employ less formal processes, or no processes at all. It is important to note, however, that even if a small organization does not have a formal process for planning and justifying IT applications, the steps of a formal process exist for a reason, and they have value. At the very least, decision makers in small organizations should consider each step when they are planning changes in their information systems.

When a company examines its needs and performance, it generates a prioritized list of both existing and potential IT applications, called the application portfolio. These are the applications that have to be added, or modified if they already exist.

 

IT Planning

The planning process for new IT applications begins with an analysis of the organizational stra­ tegic plan, which is illustrated in Figure 13.1. The organization’s strategic plan identifies the firm’s overall mission, the goals that follow from that mission, and the broad steps required to reach these goals. The strategic planning process modifies the organization’s objectives and resources to match its changing markets and opportunities.

The organizational strategic plan and the existing IT architecture provide the inputs in de­ veloping the IT strategic plan. The IT architecture delineates the way an organization should

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 FIGURE 13.1 The information systems planning process.

 

 

utilize its information resources to accomplish its mission. It encompasses both the technical and the managerial aspects of information resources. The technical aspects include hardware and operating systems, networking, data management systems, and applications software. The managerial aspects specify how the IT department will be managed, how the functional area managers will be involved, and how IT decisions will be made.

The IT strategic plan is a set of long-range goals that describe the IT infrastructure and identify the major IT initiatives needed to achieve the organization’s goals. The IT strategic plan must meet three objectives:

1. It must be aligned with the organization’s strategic plan. This alignment is critical because the organization’s information systems must support the organization’s strategies. (Recall the discussion of organizational strategies and information systems in Chapter 2.)

Consider the example of Nordstrom versus Walmart. An application that improves customer service at a small cost would be considered favorably at Nordstrom, but it would be rejected at Walmart. The reason is that the application would fit in favorably (i.e., align) with Nordstrom’s service-at-any-cost strategy. However, it would not fit in well with Walmart’s low-cost strategy. You see two department stores, same application, same cost and benefits—but different answers to the question “Should we develop the application?”

2. It must provide for an IT architecture that seamlessly networks users, applications, and databases.

3. It must efficiently allocate IS development resources among competing projects so that the projects can be completed on time and within budget and still have the required functionality.

The existing IT architecture is a necessary input into the IT strategic plan because it acts as a constraint on future development efforts. It is not an absolute constraint, however, because the organization can change to a new IT architecture. Companies prefer to avoid this strategy, however, because it is expensive and time consuming.

Consider this example. You have a Mac (Apple) system, and you need a new software ap­ plication. You search and find several such packages for both Mac and MS Windows. Unfortu­ nately, the best package runs only on Windows. How much better would this package have to be for you to justify switching from Mac to Windows?

One critical component in developing and implementing the IT strategic plan is the IT steering committee. This committee, comprised of a group of managers and staff who rep­ resent the various organizational units, is created to establish IT priorities and to ensure that the MIS function is meeting the organization’s needs. The committee’s major tasks are to link corporate strategy with IT strategy, to approve the allocation of resources for the MIS function, and to establish performance measures for the MIS function and ensure they are met. The IT steering committee is important to you because it ensures that you get the information sys­ tems and applications that you need to do your job.

After a company has agreed on an IT strategic plan, it next develops the IS operational plan. This plan consists of a clear set of projects that the IS department and the functional area managers will execute in support of the IT strategic plan. A typical IS operational plan contains the following elements:

· Mission: The mission of the IS function (derived from the IT strategy).

· IS environment: A summary of the information needs of the individual functional areas and of the organization as a whole.

· Objectives of the IS function: The best current estimate of the goals of the IS function.

· Constraints on the IS function: Technological, financial, personnel, and other resource lim­ itations on the IS function.

· The application portfolio: A prioritized inventory of present applications and a detailed plan of projects to be developed or continued during the current year.

· Resource allocation and project management: A listing of who is going to do what, how, and when.

 

 

Evaluating and Justifying IT Investment: Benefits, Costs, and Issues

Developing an IT plan is the first step in the acquisition process. Because all companies have limited resources, they must justify investing resources in some areas, including IT, rather than in others. Essentially, justifying IT investment involves calculating the costs, assessing the ben­ efits (values), and comparing the two. This comparison is frequently referred to as cost–benefit analysis. Cost–benefit analysis is not a simple task.

 

Assessing the Costs. Calculating the dollar value of IT investments is not as simple as it may seem. One of the major challenges that companies face is to allocate fixed costs among different IT projects. Fixed costs are those costs that remain the same regardless of any change in the company’s activity level. Fixed IT costs include infrastructure costs and the costs associ­ ated with IT services and IT management. For example, the salary of the IT director is fixed, and adding one more application will not change it.

Another complication is that the costs of a system do not end when the system is installed. Rather, costs for maintaining, debugging, and improving the system can accumulate over many years. This is a critical point because organizations sometimes fail to anticipate these costs when they make the investment.

A dramatic example of unanticipated expenses was the Year 2000 (Y2K) reprogramming projects, which cost organizations worldwide billions of dollars. In the 1960s, computer mem­ ory was very expensive. To save money, programmers coded the “year” in the date field 19_ _, instead of _ _ _ _. With the “1” and the “9” hard-coded in the computer program, only the last two digits varied, so computer programs needed less memory. However, this process meant that when the year 2000 rolled around, computers would display the year as 1900. This pro­ gramming technique could have caused serious problems with financial applications, insur­ ance applications, and countless other apps.

The Y2K example illustrates the point that database design choices tend to affect the orga­ nization for a long time. As the twenty-first century approached, no one still used hardware or software from the 1960s (other than a few legacy applications). Database design choices made in the 1960s, however, were often still in effect decades after the companies implemented them.

 

Assessing the Benefits. Evaluating the benefits of IT projects is typically even more complex than calculating their costs. Benefits may be more difficult to quantify, especially be­ cause many of them are intangible (for example, improved customer or partner relations and improved decision making). As an employee, you will probably be asked for input about the intangible benefits that an IS provides for you.

The fact that organizations use IT for multiple purposes further complicates benefit anal­ ysis. To obtain a return from an IT investment, the company must also implement the technol­ ogy successfully. In reality, many systems are not implemented on time, within budget, or with all of the features originally envisioned for them. Also, the proposed system may be “cutting edge.” In these cases, there may be no precedent for identifying the types of financial payback the company can expect.

 

Conducting the Cost-Benefit Analysis. After a company has assessed the costs and benefits of IT investments, it must compare them. You have studied, or will study, cost– benefit analyses in more detail in your finance courses. The point is that real-world business problems do not come in neatly wrapped packages labeled “this is a finance problem” or “this is an IS problem.” Rather, business problems span multiple functional areas.

There is no uniform strategy for conducting a cost–benefit analysis. Rather, an organization can perform this task in several ways. Here you see four common approaches: (1) net present value, (2) return on investment, (3) break-even analysis, and (4) the business case approach:

1. Analysts use the net present value (NPV) method to convert future values of benefits to their present-value equivalent by “discounting” them at the organization’s cost of funds. They

 

 

can then compare the present value of the future benefits with the cost required to achieve those benefits to determine whether the benefits exceed the costs.

2. Return on investment (ROI) measures management’s effectiveness in generating profits with its available assets. ROI is calculated by dividing the net income generated by a proj­ ect by the average assets invested in the project. ROI is a percentage, and the higher the percentage return, the better.

3. Break-even analysis determines the point at which the cumulative dollar value of the ben­ efits from a project equals the investment made in the project.

4. In the business case approach, system developers write a business case to justify funding one or more specific applications or projects. IS professionals will be a major source of input when business cases are developed because these cases describe what you do, how you do it, and how a new system could better support you.

 

Before you go on. . .

 

1. What are some problems associated with assessing the costs of IT?

2. Why are the intangible benefits from IT so difficult to evaluate?

3. Describe the NPV, ROI, break-even analysis, and business case approaches.

 

 

Strategies for Acquiring IT Applications

13.2

After a company has justified an IT investment, it must then decide how to pursue it. As with cost–benefit analyses, there are several options for acquiring IT applications. To select the best option, companies must make a series of business decisions. The fundamental decisions are the following:

· How much computer code does the company want to write? A company can choose to use a totally prewritten application (write no computer code), to customize a prewritten appli­ cation (write some computer code), or to custom-write an entire application (write all new computer code).

· How will the company pay for the application? Once the company has decided how much computer code to write, it must decide how to pay for it. With prewritten applications or customized prewritten applications, companies can buy them or lease them. With totally custom applications, companies use internal funding.

· Where will the application run? The next decision is whether to run the application on the company’s platform or on someone else’s platform. In other words, the company can em­ ploy either a software-as-a-service vendor or an application service provider. (You will ex­ amine these options later in this chapter.)

· Where will the application originate? Prewritten applications can be open-source software or they can come from a vendor. The company may choose to customize prewritten open- source applications or prewritten proprietary applications from vendors. Furthermore, it may customize applications in-house, or it can outsource the customization. Finally, it can write totally custom applications in-house, or it can outsource this process.

In the following sections, you will find more details on the variety of options that compa­ nies looking to acquire applications can select from. A good rule of thumb is that an organiza­ tion should consider all feasible acquisition methods in light of its business requirements. You will learn about the following acquisition methods:

· Purchase a prewritten application.

· Customize a prewritten application.

 

 

· Lease the application.

· Use application service providers and software-as-a-service vendors.

· Use open-source software.

· Use outsourcing.

· Employ continuous development.

· Employ custom development.

 

Purchase a Prewritten Application

Many commercial software packages contain the standard features required by IT applications. Therefore, purchasing an existing package can be a cost-effective and time-saving strategy compared with custom-developing the application in-house. Nevertheless, a company should carefully consider and plan the buy option to ensure that the selected package contains all of the features necessary to address the company’s current and future needs. Otherwise, these packages can quickly become obsolete. Before a company can perform this process, it must decide which features a suitable package must include.

In reality, a single software package can rarely satisfy all of an organization’s needs. For this reason, a company must sometimes purchase multiple packages to fulfill different needs. It then must integrate these packages with one another as well as with its existing software. Table 13.1 summarizes the advantages and limitations of the buy option.

 

Customize a Prewritten Application

Customizing existing software is an especially attractive option if the software vendor al­ lows the company to modify the application to meet its needs. However, this option may not be attractive in cases when customization is the only method of providing the neces­ sary flexibility to address the company’s needs. It is also not the best strategy when the software is either very expensive or likely to become obsolete in a short time. Furthermore, customizing a prewritten application can be extremely difficult, particularly for large, com­ plex applications.

 

 

 

TABLE 13.1	Advantages and Limitations of the Buy Option
Advantages
Many different types of off-the-shelf software are available. The company can try out the software before purchasing it. The company can save much time by buying rather than building. The company can know what it is getting before it invests in the product. Purchased software may eliminate the need to hire personnel specifically dedicated to a project.
Disadvantages
Software may not exactly meet the company’s needs. Software may be difficult or impossible to modify, or it may require huge business process changes to implement. The company will not have control over software improvements and new versions. Purchased software can be difficult to integrate with existing systems. Vendors may discontinue a product or go out of business. Software is controlled by another company with its own priorities and business considerations. The purchasing company lacks intimate knowledge about how and why the software functions as it does.

 

 

376 CHAPTER 13 Acquiring Information Systems and Applications

 

 

Strategies for Acquiring IT Applications 375

 

 

 

Lease the Application

Compared with the buy option and the option to develop applications in-house, the lease option can save a company both time and money. Of course, leased packages (like pur­ chased packages) may not exactly fit the company’s application requirements. However, as noted, vendor software generally includes the features that are most commonly needed by organizations in a given industry. Again, the company will decide which features are necessary.

Interested companies commonly apply the 80/20 rule when they evaluate vendor soft­ ware. Put simply, if the software meets 80 percent of the company’s needs, then the company should seriously consider modifying its business processes so that it can use the remaining 20 percent. Many times this is a better long-term solution than modifying the vendor software. Otherwise, the company will have to customize the software every time the vendor releases an updated version.

Leasing can be especially attractive to small and medium-sized enterprises (SMEs) that cannot afford major investments in IT software. Large companies may also prefer to lease pack­ ages to test potential IT solutions before committing to major investments. A company that does not employ sufficient IT personnel with the appropriate skills for developing custom IT applications may also choose to lease instead of develop the software it needs in-house. Even those companies that employ in-house experts may not be able to afford the long wait for stra­ tegic applications to be developed in-house. Therefore, they lease (or buy) applications from external resources to establish a quicker presence in the market.

Leasing can be executed in one of three ways. The first way is to lease the application from a software developer, install it, and run it on the company’s platform. The vendor can assist with the installation and will frequently offer to contract for the support and maintenance of the system. Many conventional applications are leased this way.

The other two options involve leasing an application and running it on the vendor’s plat­ form. Organizations can accomplish this process by using an application service provider or a software-as-a-service vendor.

 

 

Application Service Providers and Software-as-a-Service Vendors

An application service provider (ASP) is an agent or a vendor who assembles the software needed by enterprises and then packages it with services such as development, operations, and maintenance. The customer then accesses these applications through the Internet. Fig­ ure 13.2 illustrates the operation of an ASP. Note that the ASP hosts

both an application and a database for each customer.

Software-as-a-service (SaaS) is a method of delivering soft­ ware in which a vendor hosts the applications and provides them as a service to customers over a network, typically the Internet. Customers do not own the software. Rather, they pay for using it. SaaS eliminates the need for customers to install and run the application on their own computers. Therefore, SaaS customers save the expense (money, time, IT staff) of buying, operating, and maintaining the software. For example, Salesforce ( www.salesforce

.com ), a well-known SaaS provider for customer relationship man­ agement (CRM) software solutions, provides these advantages for its customers. Figure 13.3 displays the operation of a SaaS vendor. Note that the vendor hosts an application that multiple customers can use. The vendor also hosts a database that is partitioned for each customer to protect the privacy and security of each custom-

FIGURE 13.2 Operation of an application service provider. er’s data.

 

 

 

Both ASP and SaaS deliver software packages without requiring an installation on the end user’s hardware. How­ ever, the method in which they provide the backend might change drastically in the near future. Containers are a method of developing applications that run independently of the base operating system of the server. Containers allow ap­ plication providers to develop, test, and deploy technology that will always run in practice exactly like it does in testing. This would allow software to be developed more rapidly. See IT’s About Business 13.1 for more on this new technology.

At this point, companies have made the first three deci­ sions and must now decide where to obtain the application. Recall that in general, for prewritten applications, compa­ nies can use open-source software or obtain the software from a vendor. For customized prewritten applications, they can customize open-source software or customize vendor software. For totally customized applications, they can write the software in-house, or they can outsource the process.

 

 

 

IT’s About Business 13.1

Containers

MIS

Application developers have always been plagued with platform chal­ lenges. (A platform is an underlying computer system on which applica­ tion programs can run. On personal computers, Windows and macOS Sierra are examples of platforms.) As one example, if a developer built an application in a Windows environment, then it might not run prop­ erly if it were deployed after a Windows update. It would probably not work in a Linux environment, either. Furthermore, multiple versions of an application need to be developed to run on different environments, and they have to be continuously tested on platform updates.

One solution for this problem is to build and test applications on a virtual machine and then implement them on an identical vir­ tual machine for customers. A virtual machine is a self-contained operating environment that behaves as if it were a separate phys­ ical computer. Building and testing on a virtual machine ensures that an application developed on one platform will run on a dif­ ferent platform. But what if you could develop an application that included its own environment and would run as it was developed regardless of the operating system on which it was deployed? That is exactly the idea behind a container.

Containers are not new; in fact, they have been tested since 2005. However, they were not widely embraced by mainstream IT leaders until 2014. The increased popularity of containers is largely due to Docker, an open-source project by Docker, Inc. ( https:// www.docker.com/ ). Docker is a Linux-based product that enables applications to be developed and deployed in a container. Docker- created apps will run on any platform.

By late 2015, there were several open-source projects pro­ viding this type of container technology available. Also, in August 2015, Microsoft launched Windows Server 2016 Technical Pre­ view 3, which supports containers.

 

FIGURE 13.3 Operation of a software-as-a-service vendor.

 

 

 

 

In response to security concerns, in November 2015, Docker launched an updated set of tools that proactively scan for secu­ rity weaknesses of more than 90 percent of the official Docker re­ positories on a regular basis. Also, CoreOS ( https://coreos.com ), an open-source competitor of Docker, Twistlock ( https://www

.twistlock.com ), a startup tech company that focuses on container security, and Microsoft are all contributing to the development of secure container technology.

Containers are another step in the development of virtual technology. They might, for example, enable SaaS and ASP ven­ dors to deliver products to their clients much more quickly and efficiently.

Sources: Compiled from M. Russinovich, “Microsoft Brings Container Inno­ vation to the Enterprise at DockerCon 2016,” Microsoft Azure, June 21, 2016;

S. Legulalp, “Docker, Twistlock, CoreOS, and the State of Container Securi­ ty,” InfoWorld Tech Watch, December 7, 2015; C. Babcock, “Containers March into Mainstream with Security, Management Updates,” InformationWeek, November 20, 2015; F. Lardinois, “Docker Puts Focus on Container Securi­ ty,” TechCrunch.com , November 16, 2015; A. Froehlich, “Containers 101: 10 Terms to Know,” InformationWeek, September 2, 2015; M. Schutz, “What’s New in Windows Server 2016 and System Center 2016 Technical Preview 3,” blogs.technet.com , August 19, 2015; S. Vaughan-Nichols, “Docker 1.8 Adds Serious Container Security,” ZDNet.com , August 13, 2015; P. Rubens, “What Are Containers and Why Do You Need Them?” CIO.com, May 20, 2015; P. Yared, “Goodbye SaaS—Hello Containers-as-a-Service,” Venturebeat, May

9, 2015; C. Babcock, “Docker, CoreOS Push Containers to Center Stage,”

InformationWeek, December 29, 2014; www.docker.com, www.coreos.com,

www.twistlock.com, accessed December 14, 2016.

 

Questions

1. What does the container technology offer developers that traditional deployment methodologies do not?

2. What role do you think large companies like Microsoft and Docker, Inc. play in streamlining application development?

 

 

Use Open-Source Software

Organizations obtain a license to implement an open-source software product and either use it as is, customize it, or develop applications with it. Unless the company is one of the few that want to tinker with their source code, open-source applications are, basically, the same as a proprietary application except for licensing, payment, and support. Open-source software is really an alternative source of applications rather than a conceptually different development option. (We discuss open-source software in Technology Guide 2.)

 

Outsourcing

Acquiring IT applications from outside contractors or external organizations is called out­ sourcing. Companies can use outsourcing in many situations. For example, they might want to experiment with new IT technologies without making a substantial up-front investment. They also might use outsourcing to obtain access to outside experts. One disadvantage of outsourc­ ing is that companies frequently must place their valuable corporate data under the control of the outsourcing vendor.

Several types of vendors offer services for creating and operating IT systems, including e-commerce applications. Many software companies, from IBM to Oracle, offer a range of out­ sourcing services for developing, operating, and maintaining IT applications. IT outsourcers, such as EDS, offer a variety of services. Also, the large CPA companies and management consul­ tants—for example, Accenture—offer outsourcing services.

For example, Philip Morris International (the non-U.S. operation of Philip Morris) out­ sourced its IT infrastructure management to Indian services firm Wipro. The companies con­ cluded a five-year contract in which Wipro manages the tobacco company’s applications and IT using Wipro’s cloud-based management platform. (We discuss cloud computing in Technology Guide 3.) The contract is reported to be worth some $35 million U.S.

Some companies outsource offshore, particularly in India and China. Offshoring can save money, but it includes risks as well. The risks depend on which services are being offshored. If a company is offshoring application development, then the major risk is poor communication between users and developers. In response to these risks, some companies are bringing out­ sourced jobs back in-house, a process called reverse outsourcing, or insourcing, as you see in IT’s About Business 13.2.

 

Continuous Development

Continuous application development automates and improves the process of software deliv­ ery. In essence, a software development project is not viewed as having a defined product, with development stopped when the product is implemented. Rather, a software development project is viewed as constantly changing in response to changing business conditions and in response to user acceptance.

Continuous application development is the process of steadily adding new computer code to a software project when the new computer code is written and tested. Each develop­ ment team member submits new code when it is finished. Automated testing is performed on the code to ensure that it functions within the software project. Continuous code submission provides developers with immediate feedback from users and status updates for the software on which they are working.

 

Employ Custom Development

Another option is to custom-build an application. Companies can either perform this operation in-house or outsource the process. Although custom development is usually more time con­ suming and costly than buying or leasing, it often produces a better fit with the organization’s specific requirements.

 

 

 

IT’s About Business 13.2

Capital One Brings IT Home

MIS

Today, when an organization’s strategy calls for a technology ac­ quisition, there are several ownership options to consider. The company can build it, buy it, outsource it, or enter into a service agreement with a third party. Each option offers different strate­ gic advantages to the organization. One measure that executives use in decision making is return on investment (ROI). ROI is an accounting measure that helps organizations determine how ef­ ficiently their investments will return a financial benefit to the organization.

For technology-related upgrades or purchases, the nature of the improvements often makes it is difficult to calculate an accu­ rate ROI. For example, how do you measure improved employee productivity from a $1,500 investment in a faster desktop com­ puter? Or, how do you measure the ROI for a $15 million invest­ ment in mobile banking? For many organizations, the unknown ROI, coupled with the unknown costs of ownership of information systems—continued development, maintenance, and future im­ plementations—lead them to outsource their IT operation either in whole or in part.

Such was the case with Capital One (CO: www.capitalone

.com ), a major U.S. bank. In fact, at one point the company had outsourced almost three-quarters of their IT operation. With this arrangement, all service-related tasks—software development, requested changes or upgrades, and so on—had to go through the vendor(s). CO was actually limited because they did not have ownership of their IT. The nature of the market had changed, so the former advantage was now a business problem. CO wanted to give its clients a similar online experience to shopping with Amazon or Apple. However, the bank lacked the capability to achieve this goal. In 2011, CIO Rob Alexander decided it was time for a change.

CO needed more control over the IT—both hardware and software— that was crucial to its business processes. They would achieve that only by reversing the outsourcing, a process known as insourcing.

To insource the 70 percent of IT that was currently out­ sourced, Capital One had to purchase several technology compa­ nies and invest heavily in human and physical capital. The goal with insourcing was to make enhancements in three major areas: finding developers to create software in-house, fostering a culture of agile development, and purchasing a $150 million data center to quickly test and implement the applications they would be creating.

The first step was to bring software development in-house. Insourcing software development was tricky because CO lacked talent. CO did acquire the employees of the technology companies it purchased. However, the bank still had to compete with well- known technology firms for the best developers available. To ad­ dress this problem, CO partnered with several colleges to recruit their graduates. Their objective was to build a new reputation as a technology company and not just a banking company. CO under­ stood that without the best developers, it would never be a top IT company.

 

 

Next, CO’s in-house development process began to use ag­ ile development methodologies in which self-organizing, cross- functional teams analyzed workflow; proposed solutions; and then built, tested, modified, improved, and ultimately deployed tech­ nology solutions. Because most of Capital One’s newly acquired talent came from other organizations, the company implemented a two-year training program that helped nurture the rapid agile de­ velopment culture.

Finally, CO bought and operated a data center to support its new development methodologies. Had CO relied on outsourced solutions, it would have taken too long to deploy their solutions to their customers.

CO has been hard at work developing and improving their new culture. The company has improved their product testing time from 18 days before the insourcing began to fewer than 5 days. Their ultimate aim is to develop an idea and then test the product that same day. Naturally, customers aren’t focused on how fast a company can develop software. Their only concern is that the soft­ ware works when they need it to work.

When the insourcing project began, only 1 percent of CO’s software development was conducted in-house and used agile methodologies. Four years later, CO had trained more than 3,000 software developers and business analysts to work together in the cross-functional environment necessary to implement the agile development method. By that time, 85 percent of new software was developed in-house using agile development. This develop­ ment process was producing more than 400 new product releases a month, including application updates, website improvements, and new features that have taken less than six months to develop. Also, virtually all of these products passed muster on the first go. These are significant improvements in CO’s software development process. In just over three years, CO successfully transitioned from outsourced IT to insourced IT to better support the firm’s strategic goals.

Sources: Compiled from “Special Report on Outsourcing and Insourcing,” Pensions and Investments, June 13, 2016; S. Overby, “10 Outsourcing Trends to Watch in 2016,” CIO, December 29, 2015; J. Buvat and KVJ Subrah­ manyam, “Doing Business the Digital Way: How Capital One Fundamentally Disrupted the Financial Services Industry,” capgemini.com , accessed No­ vember 7, 2015; S. Overby, “Why Companies Opt to Insource for IT Innova­ tion,” CIO, March 16, 2015; C. Murphy, “Capital One IT Overhaul Powers Dig­ ital Strategy,” InformationWeek, April 2, 2014; G. MacSweeney, “Capital One Delivers 85% of Software Through Agile,” InformationWeek, April 1, 2014;

S. Staples, “Outsourcing vs. Insourcing: You Need Both,” InformationWeek, September 19, 2013; K. Burger, “CIO Rob Alexander Helps Execute Capital One’s Growth Strategy,” InformationWeek, September 29, 2011; K. Waters, “What Is Agile? (10 Key Principles of Agile),” allaboutagile.com, February 10, 2007; www.capitalone.com, accessed December 10, 2016.

 

Questions

1. What were the key factors that drove CO to insource?

2. In what ways did the three major changes discussed in the case complement each other? Would these changes have been successful if Capital One had not changed all of them at the same time?

 

 

The development process starts when the IT steering committee (discussed previously in this chapter), having received suggestions for a new system, decides it is worth exploring. These suggestions come from users (who will be you in the near future). Understanding this process will help you obtain the systems that you need. Conversely, not understanding this process will reduce your chances, because other people who understand it better will make suggestions that use up available resources.

As the company goes through the development process, its mind-set changes. In systems investigation (the first stage of the traditional systems development life cycle), the organi­ zation is trying to decide whether to build something. Everyone knows it may or may not be built. In the later stages of the development process, the organization is committed to building the application. Although a project can be canceled at any time, this change in attitude is still important.

The basic, backbone methodology for custom development is the systems development life cycle (SDLC), which you will read about in the next section. Section 13.4 examines the methodologies that complement the SDLC: prototyping, joint application development, in­ tegrated computer-assisted systems development tools, and rapid application development. You will also consider four other methodologies: agile development, end-user development, component-based development, and object-oriented development.

 

 

 

Before you go on. . .

 

1. Describe the four fundamental business decisions that organizations must make when acquiring in­ formation systems.

2. Discuss each of the seven development methods in this section with regard to the four business deci­ sions that organizations must make.

 

 

 

Traditional Systems Development Life Cycle

13.3

The systems development life cycle is the traditional systems development method that or­ ganizations use for large-scale IT projects. The SDLC is a structured framework that consists of sequential processes by which information systems are developed. For our purposes (see Figure 13.4), we identify six processes, each of which consists of clearly defined tasks:

1. Systems investigation

2. Systems analysis

3. Systems design

4. Programming and testing

5. Implementation

6. Operation and maintenance

Alternative SDLC models contain more or fewer stages. The flow of tasks, however, remains largely the same. When problems occur in any phase of the SDLC, developers often must go back to previous phases.

Systems development projects produce desired results through team efforts. Develop­ ment teams typically include users, systems analysts, programmers, and technical specialists. Users are employees from all functional areas and levels of the organization who interact with the system, either directly or indirectly. Systems analysts are IS professionals who specialize

 

380 CHAPTER 13 Acquiring Information Systems and Applications

 

 

Traditional Systems Development Life Cycle 381

 

 

 

FIGURE 13.4 A six-stage systems development life cycle with supporting tools.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 FIGURE 13.5 Comparison of user and developer involvement over the SDLC.

 

 

in analyzing and designing information systems. Programmers are IS professionals who ei­ ther modify existing computer programs or write new programs to satisfy user requirements. Technical specialists are experts on a certain type of technology, such as databases or tele­ communications. The systems stakeholders include everyone who is affected by changes in a company’s information systems—for example, users and managers. All stakeholders are typi­ cally involved in systems development at various times and in varying degrees.

Figure 13.5 indicates that users have high involvement in the early stages of the SDLC, lower involvement in the programming and testing stage, and higher involvement in the later stages. Table 13.2 discusses the advantages and disadvantages of the SDLC.

 

 

Systems Investigation

The initial stage in a traditional SDLC is systems investigation. Systems development profes­ sionals agree that the more time they invest in (1) understanding the business problem to be solved, (2) specifying the technical options for the systems, and (3) anticipating the problems they are likely to encounter during development, the greater the chances of success. For these reasons, systems investigation addresses the business problem (or business opportunity) by means of the feasibility study.

 

 

TABLE 13.2	Advantages and Disadvantages of System Acquisition Methods
Traditional Systems Development (SDLC)
Advantages · Forces staff to systematically go through every step in a structured process. · Enforces quality by maintaining standards. · Has lower probability of missing important issues in collecting user requirements.	Disadvantages · May produce excessive documentation. · Users may be unwilling or unable to study the approved specifications. · Takes too long to progress from the original ideas to a working system. · Users have trouble describing requirements for a proposed system.
Prototyping
Advantages · Helps clarify user requirements. · Helps verify the feasibility of the design. · Promotes genuine user participation. · Promotes close working relationship between systems developers and users. · Works well for ill-defined problems. · May produce part of the final system.	Disadvantages · May encourage inadequate problem analysis. · Is not practical with large number of users. · User may not want to give up the prototype when the system is completed. · May generate confusion about whether the system is complete and maintainable. · System may be built quickly, which can result in lower quality.
Joint Application Design
Advantages · Involves many users in the development process. · Saves time. · Generates greater user support for the new system. · Improves the quality of the new system. · The new system is easier to implement. · The new system has lower training costs.	Disadvantages · It is difficult to get all users to attend the JAD meeting. · The JAD approach is subject to all of the problems associated with any group meeting.
Integrated Computer-Assisted Software Engineering
Advantages · Can produce systems with a longer effective operational life. · Can produce systems that closely meet user requirements. · Can speed up the development process. · Can produce systems that are more flexible and adaptable to changing business conditions. · Can produce excellent documentation.	Disadvantages · Systems are often more expensive to build and maintain. · The process requires more extensive and accurate definition of user requirements. · It is difficult to customize the end product.
Rapid Application Development
Advantages · Can speed up systems development. · Users are intensively involved from the start. · Improves the process of rewriting legacy applications.	Disadvantages · Produces functional components of final systems, but not the final systems themselves.
End-User Development
Advantages · Bypasses the IS department and avoids delays. · User controls the application and can change it as needed. · Directly meets user requirements. · Promotes increased user acceptance of new system. · Frees up IT resources.	Disadvantages · May eventually require maintenance from IS department. · Documentation may be inadequate. · Leads to poor quality control. · System may not have adequate interfaces to existing systems. · May create lower-quality systems.

 

 

382 CHAPTER 13 Acquiring Information Systems and Applications

 

 

Traditional Systems Development Life Cycle 383

 

 

 

TABLE 13.2	Advantages and Disadvantages of System Acquisition Methods (continued)
Object-Oriented Development Advantages Disadvantages · Objects model real-world entities. • Works best with systems of more limited scope (i.e., with systems · New systems may be able to reuse some computer code. that do not have huge numbers of objects).

 

 

 

 

The primary task in the systems investigation stage is the feasibility study. Organi­ zations have three basic solutions to any business problem relating to an information system: (1) do nothing and continue to use the existing system unchanged, (2) modify or enhance the existing system, and (3) develop a new system. The feasibility study ana­ lyzes which of these three solutions best fits the particular business problem. It also pro­ vides a rough assessment of the project’s technical, economic, and behavioral feasibility, as explained next:

· Technical feasibility determines whether the company can develop or otherwise acquire the hardware, software, and communications components needed to solve the business problem. Technical feasibility also determines whether the organization can use its exist­ ing technology to achieve the project’s performance objectives.

· Economic feasibility determines whether the project is an acceptable financial risk and, if so, whether the organization has the necessary time and money to successfully complete the project. You have already learned about the commonly used methods to determine economic feasibility: NPV, ROI, break-even analysis, and the business case approach.

· Behavioral feasibility addresses the human issues of the systems development project. You will be heavily involved in this aspect of the feasibility study.

After the feasibility analysis is completed, a “go/no-go” decision is reached by the steering committee, if there is one, or by top management in the absence of a committee. The go/no-go decision does not depend solely on the feasibility analysis. Organizations often have more fea­ sible projects than they can fund. Therefore, the firm must prioritize the feasible projects and pursue those with the highest priority. Unfunded feasible projects may not be presented to the IT department at all. These projects therefore contribute to the hidden backlog, which are projects that the IT department is not aware of.

If the decision is no-go, then the project is either put on the shelf until conditions are more favorable or it is discarded. If the decision is go, then the project proceeds, and the systems analysis phase begins.

 

Systems Analysis

Once a development project has the necessary approvals from all participants, the systems analysis stage begins. Systems analysis is the process whereby systems analysts examine the business problem that the organization plans to solve with an information system.

The primary purpose of the systems analysis stage is to gather information about the ex­ isting system to determine the requirements for an enhanced system or a new system. The end product of this stage, known as the deliverable, is a set of system requirements.

Arguably, the most difficult task in systems analysis is to identify the specific requirements that the system must satisfy. These requirements are often called user requirements, because users (meaning you) provide them. When the systems developers have accumulated the user requirements for the new system, they proceed to the systems design stage.

 

 

Systems Design

Systems design describes how the system will resolve the business problem. The deliverable of the systems design phase is the set of technical system specifications, which specify the following:

· System outputs, inputs, and user interfaces

· Hardware, software, databases, telecommunications, personnel, and procedures

· A blueprint of how these components are integrated

When the system specifications are approved by all participants, they are “frozen.” That is, they should not be changed. Adding functions after the project has been initiated causes scope creep, in which the time frame and expenses associated with the project expand beyond the agreed-upon limits. Scope creep endangers both the project’s budget and its schedule. Because scope creep is expensive, successful project managers place controls on changes requested by users. These controls help to prevent runaway projects.

 

Programming and Testing

If the organization decides to construct the software in-house, then programming begins. Pro­ gramming involves translating the design specifications into computer code. This process can be lengthy and time consuming, because writing computer code is as much an art as it is a sci­ ence. Large-scale systems development projects can involve hundreds of computer program­ mers who are charged with creating hundreds of thousands of lines of computer code. These projects employ programming teams. The teams often include functional area users, who help the programmers focus on the business problem.

Thorough and continuous testing occurs throughout the programming stage. Testing is the process that assesses whether the computer code will produce the expected and desired results. It is also intended to detect errors, or bugs, in the computer code.

 

Implementation

Implementation (or deployment) is the process of converting from an old computer system to a new one. The conversion process involves organizational change. Only end users can manage organizational change, not the MIS department. The MIS department typically does not have enough credibility with the business users to manage the change process. Organizations use three major conversion strategies: direct, pilot, and phased.

In a direct conversion, the old system is cut off, and the new system is turned on at a certain point in time. This type of conversion is the least expensive. It is also the most risky because, if the new system does not work as planned, there is no support from the old system. Because of these risks, few systems are implemented using direct conversion.

A pilot conversion introduces the new system in one part of the organization, such as in one plant or one functional area. The new system runs for a period of time and is then as­ sessed. If the assessment confirms that the system is working properly, then the system is im­ plemented in other parts of the organization.

A phased conversion introduces components of the new system, such as individual mod­ ules, in stages. Each module is assessed. If it works properly, then other modules are introduced until the entire new system is operational. Large organizations commonly combine the pilot and phased approaches. That is, they execute a phased conversion using a pilot group for each phase. A fourth strategy is parallel conversion, in which the old and new systems operate simul­ taneously for a time. This strategy is seldom used today. One reason is that parallel conversion is totally impractical when both the old and new systems are online. Imagine that you are com­ pleting an order on Amazon, only to be told, “Before your order can be entered here, you must provide all the same information again, in a different form, and on a different set of screens.” The results would be disastrous for Amazon. Regardless of the type of implementation process

 

 

that an organization uses, the new system may not work as advertised. In fact, the new system may cause more problems than the old system that it replaced.

 

Operation and Maintenance

After the new system is implemented, it will operate for a period of time, until (like the old system it replaced) it no longer meets its objectives. Once the new system’s operations are stabilized, the company performs audits to assess the system’s capabilities and to determine if it is being used correctly.

Systems require several types of maintenance. The first type is debugging the program, a process that continues throughout the life of the system. The second type is updating the system to accommodate changes in business conditions. An example is adjusting to new gov­ ernmental regulations, such as changes in tax rates. These corrections and upgrades usually do not add any new functions. Instead, they simply help the system continue to achieve its objectives. In contrast, the third type of maintenance adds new functions to the existing system without disturbing its operation.

 

 

Before you go on. . .

 

1. Describe the feasibility study.

2. What is the difference between systems analysis and systems design?

3. Describe structured programming.

4. What are the four conversion methods?

 

 

 

Alternative Methods and Tools for Systems Development

13.4

Alternative methods for systems development include joint application design, rapid applica­ tion development, agile development, and end-user development.

 

Joint Application Design

Joint application design (JAD) is a group-based tool for collecting user requirements and creating system designs. It is most often used within the systems analysis and systems design stages of the SDLC. JAD involves a group meeting attended by the analysts and all of the us­ ers that can be conducted either in person or through the computer. During this meeting, all users jointly define and agree on the systems requirements. This process saves a tremendous amount of time. Table 13.2 lists the advantages and disadvantages of the JAD process.

 

Rapid Application Development

Rapid application development (RAD) is a systems development method that can combine JAD, prototyping, and integrated computer-assisted software engineering (ICASE) tools (dis­ cussed later in this section) to rapidly produce a high-quality system. In the first RAD stage, developers use JAD sessions to collect system requirements. This strategy ensures that users are intensively involved early on. The development process in RAD is iterative; that is, require­ ments, designs, and the system itself are developed and then undergo a series, or sequence,

 

386 CHAPTER 13 Acquiring Information Systems and Applications

 

 

Alternative Methods and Tools for Systems Development 385

 

 

 

FIGURE 13.6 A rapid prototyping development process versus SDLC.

datawarehousetraining.com/Methodologies/ rapidapplication-development

 

 

 

of improvements. RAD uses ICASE tools to quickly structure requirements and develop proto­ types. As the prototypes are developed and refined, users review them in additional JAD ses­ sions. RAD produces the functional components of a final system rather than prototypes. To understand how RAD functions and how it differs from SDLC, see Figure 13.6. Table 13.2 high­ lights the advantages and disadvantages of the RAD process.

 

 

Agile Development

Agile development is a software development methodology that delivers functionality in rapid iterations, which are usually measured in weeks. To be successful, this methodology requires frequent communication, development, testing, and delivery. Agile development focuses on rapid development and frequent user contact to create software that addresses the needs of business users. This software does not have to include every possible feature the user will re­ quire. Rather, it must meet only the user’s more important and immediate needs. It can be up­ dated later to introduce additional functions as they become necessary. The core tenet of agile development is to do only what you have to do to be successful right now.

One type of agile development uses the scrum approach. A key principle of scrum is that during a project, users can change their minds about what they want and need. Scrum ac­ knowledges that a development problem cannot be fully understood or defined from the start. Therefore, scrum focuses on maximizing the development team’s ability to deliver iterations quickly and to respond effectively to additional user requirements as they emerge.

Scrum contains sets of practices and predefined roles. The primary roles are:

· The Scrum Master: Maintains the processes (typically replaces a project manager).

· The Product Owner: Represents the business users and any other stakeholders in the project.

· The Team: A cross-functional group of about seven people who perform the actual analy­ sis, design, coding, implementation, testing, and so on.

Scrum works this way: During each sprint—typically a two- to four-week period—the team creates a potentially shippable product increment, such as working and tested software. The set of features that goes into each sprint comes from the product backlog, which is a prioritized set of high-level work requirements to be completed.

The sprint planning meeting determines which backlog items will be addressed during a sprint. During this meeting, the product owner informs the team of the items in the product backlog that he or she wants to be completed. The team members then determine how many of these projects they can commit to during the next sprint, and they record this information in the sprint backlog.

During a sprint, no one is allowed to change the sprint backlog, which means that the re­ quirements are frozen for the sprint. Each sprint must end on time. If the requirements are not

 

 

completed for any reason, then they are left out and returned to the product backlog. After each sprint is completed, the team demonstrates how to use the software.

IT’s About Business 13.3 addresses an interesting type of agile development. This method­ ology is called minimum viable product (MVP) development. Applications developed using MVP methodology have just the required amount of functionality to operate successfully. On the other hand, MVP applications do not have so much functionality (i.e., too many features) that the development process took too long and cost too much.

 

 

End-User Development

End-user development is an approach in which the organization’s end users develop their own applications with little or no formal assistance from the IT department. Table 13.2 lists the advantages and disadvantages of end-user development. Sometimes this form of IT devel­ opment or acquisition is called Shadow IT (also known as Stealth IT or Rogue IT). While the end-users bypass of the IT Department might make it easier for them to adopt the tools that they want to work with, it also bypasses the security measures that the IT Department is trying to enforce. These shadow IT systems can open systems to vulnerabilities and create avenues for criminals to access private company and customer data. As an employee, it is important to carefully consider adopting something that has not been approved by your organization. If your Shadow IT creates a vulnerability that allows a breach, you will probably lose your job!

 

 

 

IT’s About Business 13.3

SDLC versus Minimum Viable Product development process, he noticed that several of his competitors

 

Development

had already gained loyal customers. This situation made it difficult for Wilson’s game to gain traction in the marketplace, even though

 

MIS his fantasy environment was more feature-rich than his competitors’

As previously discussed, the SDLC is a traditional approach environments. Ultimately, Wilson lost roughly $1 million on his proj­ to software development that aims to produce full-function, ect. In the process, he learned the importance of rapid development. feature-rich, user-driven software. The major problem with the Today, development teams at 352 can bring a minimum via- SDLC has always been that the time between developing the ble product to customers in three months or less. The company’s list of user needs and the actual implementation of the soft- teams are experts at working with clients to fully develop product ware is too long. The time-consuming nature of the SDLC of- features. Wilson recommends that developers continuously listen ten means that it cannot keep up with the fast-paced business to their user community, remain focused on the long-term goals of environment. the product, and maintain an open mind regarding change.

In 1999, Geoff Wilson founded 352 ( http://www.352inc.com ), MVP development won’t work for every business in every situ- a successful web design company based in Gainesville, Florida. His ation. Nevertheless, it is definitely a concept to keep in mind in rela­ company’s mission was to bring products to market more quickly tion to the SDLC, because it attempts to create a perfect, complete for his customers. He did not want to use a lengthy development product in one attempt.

process such as the SDLC. Sources: Compiled from A. Klubnikin, “5 Great Examples of Minimum Via-

Today, 352 provides custom web projects for customers ble Product in App Development,” Business2Community, February 28, 2016;

within weeks using agile development and a minimum viable prod- L. Calhoun, “The One Million Dollar Startup Rule Startups Should Never

 

uct (MVP) approach. MVP focuses on developing the basic functions needed to bring a project to completion. After these functions are developed, the client is brought on board, and the product basi­

Break,” Inc., December 11, 2015; G. Wilson, “Moving Beyond MVP: Feedback, Features, and Pricing,” www.agilealliance.org, accessed September 30, 2015; J. Oakhurst, “4 Biggest Custom Software Buying Mistakes,” Informa­ tionWeek, February 18, 2014; www.clubpenguin.com/, http://leanstack

 

cally designs itself through a series of iterations. .com/minimum-viable-product/, https://www.linkedin.com/in/geoffwilson,

Wilson learned about MVP the hard way. As he was creating accessed December 14, 2016.

352, he observed several companies developing fantasy games for Questions

children. Specifically, Disney’s purchase of Club Penguin ( http://

 

games.disney.com/club-penguin-app ) sparked his interest. Wil­ son set out to build a fantasy game for children himself.

1. What lessons did Wilson learn in his attempt to develop a virtual world for children?

 

When Wilson undertook this project, there were only a few 2. Compare and contrast the development styles of the SDLC

competitors in this space. However, after completing an 18-month and the agile MVP approach that Wilson promotes.

 

 

Tools for Systems Development

Several tools can be used with various systems development methods. These tools include prototyping, integrated computer-assisted software engineering, component-based develop­ ment, and object-oriented development.

 

Prototyping. The prototyping approach defines an initial list of user requirements, builds a model of the system, and then refines the system in several iterations based on users’ feedback. Developers do not try to obtain a complete set of user specifications for the system at the outset, and they do not plan to develop the system all at once. Instead, they quickly de­ velop a smaller version of the system known as a prototype. A prototype can take two forms. In some cases, it contains only the components of the new system that are of most interest to the users. In other cases, it is a small-scale working model of the entire system.

Users make suggestions for improving the prototype, based on their experiences with it. The developers then review the prototype with the users and use their suggestions to refine it. This process continues through several iterations until the users approve the system or it becomes apparent that the system cannot meet the users’ needs. If the system is viable, then the developers can use the prototype to build the full system. One typical use of prototyping is to develop screens that a user will see and interact with. Table 13.2 describes the advantages and disadvantages of the prototyping approach.

A practical problem with prototyping is that a prototype usually looks more complete than it actually is. That is, it may not use the real database, it usually does not have the nec­ essary error checking, and it almost never includes the necessary security features. Users who review a prototype that resembles the finished system may not recognize these problems. Con­ sequently, they might have unrealistic expectations about how close the actual system is to completion.

 

Integrated Computer-Assisted Software Engineering Tools. Computer- aided software engineering (CASE) refers to a group of tools that automate many of the tasks in the SDLC. The tools that are used to automate the early stages of the SDLC (systems investigation, analysis, and design) are called upper CASE tools. The tools used to automate later stages in the SDLC (programming, testing, operation, and maintenance) are called lower CASE tools. CASE tools that provide links between upper CASE and lower CASE tools are called integrated CASE (ICASE) tools. Table 13.2 lists the advantages and disadvantages of ICASE tools.

 

Component-Based Development. Component-based development uses stan­ dard components to build applications. Components are reusable applications that generally have one specific function, such as a shopping cart, user authentication, or a catalog. Com­ pared with other approaches, component-based development generally involves less pro­ gramming and more assembly. Component-based development is closely linked with the idea of web services and service-oriented architectures, which you will study in Technology Guide 3. Many startup companies are pursuing the idea of component-based application develop­ ment. One example is Ning ( www.ning.com ), which allows organizations to create, customize,

and share their own social network.

 

Object-Oriented Development. Object-oriented development is based on a dif­ ferent view of computer systems than the perception that characterizes traditional develop­ ment approaches. Traditional approaches can produce a system that performs the original task but may not be suited for handling other tasks. This limitation applies even when these other tasks involve the same real-world entities. For example, a billing system will handle billing, but it probably cannot be adapted to handle mailings for the marketing department or to gen­ erate leads for the sales force. This is true even though the billing, marketing, and sales func­ tions all use similar data, including customer names, addresses, and purchases. In contrast, an object-oriented (OO) system begins not with the task to be performed, but with the aspects of

 

 

the real world that must be modeled to perform that task. Therefore, in our example, if the firm has a good model of its customers and its interactions with them, then it can use this model equally well for billings, mailings, and sales leads.

The development process for an object-oriented system begins with a feasibility study and an analysis of the existing system. Systems developers identify the objects in the new system— the fundamental elements in OO analysis and design. Each object represents a tangible, real- world entity such as a customer, bank account, student, or course. Objects have properties, or data values. For example, a customer has an identification number, a name, an address, an account number(s), and so on. Objects also contain the operations that can be performed on their properties. For example, operations that can be performed on the customer object may include obtain-account-balance, open-account, withdraw-funds, and so on. Operations are also referred to as behaviors.

This approach enables OO analysts to define all the relevant objects needed for the new system, including their properties and operations. The analysts then model how the objects interact to meet the objectives of the new system. In some cases, analysts can reuse existing objects from other applications (or from a library of objects) in the new system. This process saves the analysts the time they otherwise would spend coding these objects. In most cases, however, even with object reuse, some coding will be necessary to customize the objects and their interactions for the new system.

You have studied many methods that can be used to acquire new systems. Table 13.2

provides an overview of the advantages and disadvantages of each of these methods.

 

 

Before you go on. . .

 

1. Describe the tools that augment the traditional SDLC.

2. Describe the alternate methods that can be used for systems development other than the SDLC.

 

 

 

 

What’s in IT for me?

 

ACCT For The Accounting Major

Accounting personnel help perform the cost–benefit analyses on proposed projects. They may also monitor ongoing project costs to keep them within budget. Accounting personnel undoubtedly will find themselves involved with systems development at various points throughout their careers.

 

FIN For the Finance Major

Finance personnel are frequently involved with the financial is­ sues that accompany any large-scale systems development proj­ ect (e.g., budgeting). They also are involved in cost–benefit and risk analyses. To perform these tasks, they need to stay abreast of the emerging techniques used to determine project costs and ROI. Finally, because they must manage vast amounts of information, finance departments are also common recipients of new systems.

 

MKT For the Marketing Major

In most organizations, marketing, like finance, involves massive amounts of data and information. Like finance, then, marketing is also a hotbed of systems development. Marketing personnel will

 

 

 

increasingly find themselves participating in systems development teams. Such involvement increasingly means helping to develop systems, especially web-based systems that reach out directly from the organization to its customers.

POM For the Production/Operations Management Major

Participation in development teams is also a common role for pro­ duction/operations people. Manufacturing is becoming increas­ ingly computerized and integrated with other allied systems, from design to logistics to customer support. Production systems in­ terface frequently with marketing, finance, and human resources. They may also be part of a larger enterprisewide system. Also, many end users in POM either develop their own systems or collab­ orate with IT personnel on specific applications.

 

HRM For the Human Resources Management Major

The human resources department is closely involved with several aspects of the systems acquisitions process. Acquiring new systems may require hiring new employees, changing job descriptions, or

 

 

 

390 CHAPTER 13 Acquiring Information Systems and Applications

 

 

terminating employees. Human resources staff performs all of these tasks. Furthermore, if the organization hires consultants for the development project, or outsources it, the human resources department may handle the contracts with these suppliers.

MIS For the MIS Major

Regardless of the approach that the organization adopts for ac­ quiring new systems, the MIS department spearheads it. If the

organization chooses either to buy or to lease the application, the MIS department leads in examining the offerings of the var­ ious vendors and in negotiating with the vendors. If the orga­ nization chooses to develop the application in-house, then the process falls to the MIS department. MIS analysts work closely with users to develop their information requirements. MIS pro­ grammers then write the computer code, test it, and implement the new system.

 

 

 

 

 

 

 

Summary

1. Discuss the different cost–benefit analyses that companies must take into account when formulating an IT strategic plan.

 

 

The four common approaches to cost–benefit analysis are the following:

1. The net present value method converts future values of benefits to their present-value equivalent by discounting them at the organi­ zation’s cost of funds. They can then compare the present value of the future benefits with the cost required to achieve those ben­ efits to determine whether the benefits exceed the costs.

2. Return on investment measures management’s effectiveness in generating profits with its available assets. ROI is calculated by dividing net income attributable to a project by the average as­ sets invested in the project. ROI is a percentage, and the higher the percentage return, the better.

3. Break-even analysis determines the point at which the cumulative dollar value of the benefits from a project equals the investment made in the project.

4. In the business case approach, system developers write a busi­ ness case to justify funding one or more specific applications or projects.

 

2. Discuss the four business decisions that companies must make when they acquire new applications.

 

 

· How much computer code does the company want to write? A com­ pany can choose to use a totally prewritten application (to write no computer code), to customize a prewritten application (to write some computer code), or to customize an entire application (write all new computer code).

· How will the company pay for the application? Once the compa­ ny has decided how much computer code to write, it must de­ cide how to pay for it. With prewritten applications or custom­ ized prewritten applications, companies can buy them or lease them. With totally custom applications, companies use internal funding.

 

 

 

· Where will the application originate? Prewritten applications can be open-source software or come from a vendor. Companies may choose to customize prewritten open-source applications or pre- written proprietary applications from vendors. Companies may customize applications in-house or outsource the customization. They also can write totally custom applications in-house or out­ source this process.

 

3. Enumerate the primary tasks and importance of each of the six processes involved in the systems development life cycle.

 

 

The six processes are the following:

1. Systems investigation: Addresses the business problem (or busi­ ness opportunity) by means of the feasibility study. The main task in the systems investigation stage is the feasibility study.

2. Systems analysis: Examines the business problem that the organi­ zation plans to solve with an information system. Its main purpose is to gather information about the existing system to determine the requirements for the new system. The end product of this stage, known as the “deliverable, “ is a set of system requirements.

3. Systems design: Describes how the system will resolve the busi­ ness problem. The deliverable is the set of technical system specifications.

4. Programming and testing: Programming translates the design specifications into computer code; testing checks to see whether the computer code will produce the expected and desired results and detects errors, or bugs, in the computer code. A deliverable is the new application.

5. Implementation: The process of converting from the old system to the new system through three major conversion strategies: direct, pilot, and phased. A deliverable is a properly working application.

6. Operation and maintenance: Types of maintenance include de­ bugging, updating, and adding new functions when needed.

 

4. Describe alternative development methods and tools that augment development methods.

 

· Where will the application run? Companies must now decide

 

where to run the application. The company may run the applica­ tion on its own platform or run the application on someone else’s platform (use either a software-as-a-service vendor or an applica­ tion service provider).

These are the alternative methods:

· Joint application design is a group-based tool for collecting user requirements and creating system designs.

 

Chapter Glossary 391

 

 

 

· Rapid application development is a systems development meth­ od that can combine JAD, prototyping, and ICASE tools to rapidly produce a high-quality system.

· Agile development is a software development methodology that delivers functionality in rapid iterations, which are usually mea­ sured in weeks.

· End-user development refers to an organization’s end users devel­ oping their own applications with little or no formal assistance from the IT department.

These are the tools:

· The prototyping approach defines an initial list of user require­ ments, builds a model of the system, and then improves the sys­ tem in several iterations based on users’ feedback.

· Integrated computer-aided software engineering combines upper CASE tools (automate systems investigation, analysis, and de­

sign) and lower CASE tools (programming, testing, operation, and maintenance).

· Component-based development uses standard components to build applications. Components are reusable applications that generally have one specific function, such as a shopping cart, user authentication, or a catalog.

· Object-oriented development begins with the aspects of the real world that must be modeled to perform that task. Systems de­ velopers identify the objects in the new system. Each object rep­ resents a tangible, real-world entity such as a customer, bank account, student, or course. Objects have properties, or data val­ ues. Objects also contain the operations that can be performed on their properties.

Table 13.2 shows advantages and disadvantages of alternative methods and tools.

 

 

 

 

 

 

 

Chapter Glossary

agile development A software development methodology that delivers functionality in rapid iterations, measured in weeks, requiring fre­ quent communication, development, testing, and delivery.

application portfolio The set of recom­ mended applications resulting from the plan­ ning and justification process in application development.

application service provider (ASP) An agent or vendor who assembles the software needed by enterprises and packages them with out­ sourced development, operations, mainte­ nance, and other services.

component-based development A software development methodology that uses standard components to build applications.

computer-aided software engineering (CASE) Development approach that uses specialized tools to automate many of the tasks in the SDLC. Upper CASE tools automate the early stages of the SDLC and lower CASE tools automate the later stages.

containers A method of developing applica­ tions that run independently of the base oper­ ating system of the server.

continuous application development The process of steadily adding new computer code to a software project when the new computer code is written and tested.

direct conversion Implementation process in which the old system is cut off and the new sys­ tem is turned on at a certain point in time.

end-user development Approach in which the organization’s end users develop their own applications with little or no formal assistance from the IT department.

 

 

 

feasibility study Investigation that gauges the probability of success of a proposed project and provides a rough assessment of the project’s feasibility.

implementation The process of converting from an old computer system to a new one.

integrated CASE (ICASE) tools CASE tools that provide links between upper CASE and lower CASE tools.

IS operational plan Consists of a clear set of projects that the IS department and the func­ tional area managers will execute in support of the IT strategic plan.

IT steering committee A committee, com­ posed of a group of managers and staff rep­ resenting various organizational units, set up to establish IT priorities and to ensure that the MIS function is meeting the needs of the enterprise.

IT strategic plan A set of long-range goals that describe the IT infrastructure and major IT initiatives needed to achieve the goals of the organization.

joint application design (JAD) A group- based tool for collecting user requirements and creating system designs.

lower CASE tools Tools used to automate later stages in the SDLC (programming, testing, operation, and maintenance).

object-oriented development A systems de­ velopment methodology that begins with as­ pects of the real world that must be modeled to perform a task.

outsourcing Use of outside contractors or ex­ ternal organizations to acquire IT services.

 

 

 

phased conversion Implementation process that introduces components of the new sys­ tem in stages, until the entire new system is operational.

pilot conversion Implementation process that introduces the new system in one part of the organization on a trial basis. When the new system is working properly, it is introduced in other parts of the organization.

programmers IS professionals who modify existing computer programs or write new com­ puter programs to satisfy user requirements.

programming The translation of a system’s design specifications into computer code.

prototype A small-scale working model of an entire system or a model that contains only the components of the new system that are of most interest to the users.

prototyping An approach that defines an ini­ tial list of user requirements, builds a prototype system, and then improves the system in several iterations based on users’ feedback.

rapid application development (RAD) A development method that uses special tools and an iterative approach to rapidly produce a high-quality system.

request for proposal (RFP) Document that is sent to potential vendors inviting them to sub­ mit a proposal describing their software package and how it would meet the company’s needs.

scope creep Adding functions to an informa­ tion system after the project has begun.

service-level agreements (SLAs) Formal agreements regarding the division of work be­ tween a company and its vendors.

 

 

 

392 CHAPTER 13 Acquiring Information Systems and Applications

 

 

software-as-a-service (SaaS) A method of delivering software in which a vendor hosts the applications and provides them as a service to customers over a network, typically the Internet.

systems analysis The examination of the business problem that the organization plans to solve with an information system.

systems analysts IS professionals who spe­ cialize in analyzing and designing information systems.

systems design Describes how the new sys­ tem will resolve the business problem.

systems development life cycle (SDLC) Tra­ ditional structured framework, used for large IT projects, that consists of sequential processes by which information systems are developed.

systems investigation The initial stage in the traditional SDLC that addresses the business problem (or business opportunity) by means of the feasibility study.

systems stakeholders All people who are af­ fected by changes in information systems.

technical specialists Experts on a certain type of technology, such as databases or telecommunications.

upper CASE tools Tools that are used to au­ tomate the early stages of the SDLC (systems investigation, analysis, and design).

 

 

 

 

 

 

Discussion Questions

1. Discuss the advantages of a lease option over a buy option.

2. Why is it important for all business managers to understand the is­ sues of IT resource acquisition?

3. Why is it important for everyone in business organizations to have a basic understanding of the systems development process?

4. Should prototyping be used on every systems development pro­ ject? Why or why not?

 

 

 

Problem-Solving Activities

1. Access www.ecommerce-guide.com . Find the product review area. Read reviews of three software payment solutions. Assess them as possible components.

2. Use an Internet search engine to obtain information on CASE and ICASE tools. Select several vendors and compare and contrast their offerings.

3. Access www.ning.com . Observe how the site provides compo­ nents for you to use to build applications. Build a small application at the site.

4. Enter www.01.ibm.com/software . Find its WebSphere product. Read recent customers’ success stories. What makes this software so popular?

5. Enter the websites of the Gartner ( www.gartner.com ), 451 Re­ search ( https://451research.com ), and CIO ( www.cio.com ). Search

 

 

 

Closing Case

The Federal Aviation Administration’s Next Generation Air Transportation System

POM

The Problem

Aviation contributes $1.3 trillion to the United States economy, which is 5.2 percent of the national gross domestic product. Furthermore, aviation provides more than 10 million jobs with earnings of more than

$400 billion.

 

 

 

5. Discuss the various types of feasibility studies. Why are they all needed?

6. Discuss the issue of assessing intangible benefits and the proposed solutions.

7. Discuss the reasons why end-user-developed information sys­ tems can be of poor quality. What can be done to improve this situation?

 

 

 

 

 

 

for recent material about ASPs and outsourcing, and prepare a report on your findings.

6. StoreFront ( www.storefront.net ) is a vendor of e-business soft­ ware. At its site, the company provides demonstrations illustrating the types of storefronts that it can create for shoppers. The site also pro­ vides demonstrations of how the company’s software is used to create a store.

a. Run the StoreFront demonstration to see how this is done.

b. What features does StoreFront provide?

c. Does StoreFront support smaller or larger stores?

d. What other products does StoreFront offer for creating online stores? What types of stores do these products support?

 

 

 

 

 

 

 

The U.S. air traffic system has achieved an impressive safety record. Nevertheless, many of the network’s features are so antiquated that ex­ perts blame them for delays and other inefficiencies that cost billions of dollars each year. The Federal Aviation Administration (FAA; www.faa.gov ) estimates that if the increasing congestion in the U.S. air transportation system is not addressed, it will cost the nation’s economy $22 billion an­ nually in lost economic activity by 2022. Perhaps more seriously, it will also cause increasing safety issues, potentially endangering the flying public.

 

Closing Case 393

 

 

 

The Solution

To resolve these problems, the FAA began to develop the Next Gener­ ation Air Transportation System (NextGen; www.faa.gov/nextgen ) in 2004. (Development and deployment were still ongoing in late 2016.) The purpose of NextGen is to transform America’s air traffic control sys­ tem from a ground-based system to a satellite-based system. NextGen uses global positioning system (GPS) technologies to shorten routes, save time and fuel, reduce traffic delays, increase the number of planes in the air traffic system, and permit controllers to monitor and manage aircraft with greater safety. Planes will be able to fly closer together, take more direct routes, and avoid delays caused when planes remain in holding patterns while they wait for an open runway. To implement NextGen, the FAA will have to transform the nation’s entire air trans­ portation system.

The FAA planned for a 20-year, $40 billion project, to be deployed across the United States in stages between 2012 and 2025. NextGen includes upgraded information systems and radar, a new communi­ cations network to replace radios, and a satellite-based surveillance system that indicates the locations of nearby planes without relying on air traffic controllers. The goal is to manage planes more precisely and automatically, thereby enabling them to fly closer together and with greater safety.

In 2016, the FAA estimated that further improvements in Next- Gen would cost the FAA some $14 billion and cost the U.S. National Airspace System (NAS) users approximately $15 billion. (NAS users are, for example, the airlines.)

The FAA states that it had measured $1.6 billion in benefits to airlines and the traveling public from NextGen capabilities already in place in 2016. Going forward, the FAA estimates that by 2030, NextGen will generate $133 billion in benefits to NAS users and the flying public. These savings come from reduced aviation fuel consumption, reduced carbon emissions, and more precise routes that save billions of dollars in costs. Each mile in the air costs an airline about $0.10 to $0.15 per seat in operating expenses such as flight crew and fuel.

Problems with NextGen’s Implementation

Uneven progress, budget overruns, and conflicts among regulators and airlines demonstrate how extremely challenging the task of mod­ ernizing the world’s most complex air traffic management network re­ ally is. The slow pace of NextGen’s implementation has drawn harsh criticism.

There were early problems with NextGen. The FAA initially de­ signed new flight paths without much industry input. Airlines, which are responsible for at least $7 billion of NextGen’s total cost, have al­ ready invested in sophisticated computers and other cockpit equip­ ment to enable pilots to fly more precise paths. Furthermore, various interests have collided frequently. As just one example, simply rework­ ing air routes to and from airports can take years, partly as a result of environmental assessments to address local noise concerns.

Difficulties in NextGen implementation have occurred nearly everywhere, from new landing procedures that were impossible for some planes to execute to aircraft tracking software that misidentified planes. Key initiatives are experiencing delays and are at risk of cost overruns. These problems, however, are being overcome.

The Results Through 2016

NextGen is yielding results.

· The foundational infrastructure for NextGen is complete. The infrastructure includes the satellite-based system—called the Automatic Dependent Surveillance Broadcast—that is replacing

radars as the primary means by which air traffic controllers track and manage aircraft.

· En Route Automation Modernization (ERAM) is fully deployed at the 20 en route centers across the United States where controllers handle high-altitude traffic. ERAM processes flight and radar data, enables communications, and generates the data for controllers’ screens. As a result of ERAM, aircraft are now flying more pre­ cise, satellite-based procedures than traditional ground-based procedures.

· New Performance-Based Navigation procedures use satellite- based precision to enable planes to fly more direct routes, sav­ ing fuel and time, increasing traffic flow, and resulting in lower carbon emissions.

· Equivalent Lateral Spacing Operations are allowing more aircraft to take off on different flight paths from the same runway during the same time period.

Let’s examine some examples of the benefits of NextGen:

· Atlanta-Hartsfield Jackson Airport reported a 20 percent boost in capacity when they implemented NextGen’s updated ar­ rival and departure procedures. These new procedures allow for less separation between aircraft based on new research into wake turbulence. Aircraft can now safely take off and land closer to one another with the help of NextGen. Also, for fiscal year 2015, Atlanta-Hartsfield reported savings of $6.3 million in fuel, 2.2 million gallons of fuel, and 18.8 thousand metric tons of carbon.

· Phoenix Sky Harbor International Airport has implemented a computer-based “point-and-click” method of tracking aircraft to replace the paper strips it had used for years. Although the paper strips functioned well for many years, they also created a level of distraction because air traffic controllers had to physically walk around the tower to gather data and keep the strips updated. In contrast, the current system enables users to share information electronically, remain in one place, and focus their attention on the safety of the aircraft they are responsible for monitoring.

· According to the FAA, the implementation of a surface manage­ ment (taxi) initiative in Boston saved more than 5,000 gallons of aviation fuel and reduced carbon dioxide emissions by 50 tons during one period of heavy congestion.

· A shared surface surveillance system combined with aircraft monitoring techniques reduced taxi-out time by 7,000 hours per year at New York’s JFK airport and by 5,000 hours in Memphis, Tennessee.

· NextGen has also been tested in Memphis with Delta Air Lines and FedEx ( www.fedex.com ).

· The National Air Traffic Controllers Association conducted a demonstration at Dallas/Fort Worth International Airport of a new surveillance display called the Tower Flight Data Manager system. This system presented surveillance, flight data, weather, airport configuration, and other information critical to controllers.

· Specialized Optimized Profile Descents, also known as Initial Tai­ lored Arrivals, are in operation at airports in San Francisco, Los Angeles, Miami, and Denver.

Through cooperation with the NextGen project, the FAA has in­ itiated a new system called Aviation Safety Information Analysis and Sharing (ASIAS) that leverages data from 185 sources across industry and government, including 45 commercial air carriers and 10 corporate

 

 

 

394 CHAPTER 13 Acquiring Information Systems and Applications

 

 

operators. These data include internal FAA datasets, proprietary airline safety data, public data, aircraft manufacturers’ data, and more. ASIAS enables users to create a more complete profile for each flight, espe­ cially those involved in some type of accident or incident. An accident is defined as anything that happens between the times when a person enters the aircraft and when all persons have exited. In contrast, in­ cidents occur at other times such as when an aircraft is being moved around an airport.

The FAA uses the ASIAS profiles to share information with other aircraft manufacturers and operators to help ensure the safety of the public. The agency has broken these profiles into three categories: airplane life cycle, threat categories, and common themes. The FAA has also used this information to develop more than 7,000 performance- based navigation (PBN) procedures that help pilots descend into busy airports using a tighter navigation path in a safer and more efficient manner.

Sources: Compiled from “NextGen Update,” FAA.gov, April 7, 2016; E. Pianin, “Congress Enraged by the FAA’s $40B White Elephant,” Fiscal Times, November 19, 2014; C. Howard, “NextGen GA Fund Selects Banks to Help Finance General Aviation NextGen Installations, Accelerate FAA’s NextGen Implementation,” Avionics Intelligence, March 14, 2014; W. Bellamy, “NextGen Among Top US Transportation Issues for 2014,” Avionics Today, December 17, 2013; J. Lowy,

“The FAA’s Next Big Issue Is Acting on Its NextGen Air Traffic Control Dreams,” Associated Press, November 1, 2013; J. Lowy, “Air Traffic Control Modernization Hits Turbulence,” Associated Press, October 31, 2013; S. Carey, “The FAA’s $40 Billion Adventure,” Wall Street Journal, August 19, 2013; W. Jackson, “What’s Keeping FAA’s NextGen Air Traffic Control on the Runway?” GCN.com , July 22, 2013; J. Mouawad, “Alaska Airlines, Flying Above an Industry’s Troubles,”

New York Times, March 2, 2013; J. Hoover, “Problems Plague FAA’s NextGen Air Traffic Control Upgrade,” InformationWeek, October 5, 2011; “Fact Sheet—Next Generation Air Transportation System,” FAA News, May 27, 2010; www.faa.gov/ nextgen, www.faa.gov, accessed December 14, 2016.

 

 

Questions

1. Describe the many problems that have caused problems with im­ plementing NextGen.

2. In Technology Guide 1, you will learn that hardware capabilities double roughly every 18 months (Moore’s law). What impact will increases in hardware processing power, with accompanying decreases in size, have on the NextGen system? Support your answer.

3. See the discussion of cloud computing in Technology Guide 3. What impact might a cloud computing solution have on the future of the NextGen system? Support your answer.