need help

CHAPTER 2 (APPLIES TO WEEK 1)

Chapter Objectives

After studying this chapter, you should be able to:

· Explain outsourcing.

· Describe six different sources of software.

· Discuss how to evaluate off-the-shelf software.

· Explain reuse and its role in software development.

Chapter Preview . . .

Software is a big part of any business application system. Although most software was once written in-house by a company’s own systems analysts and programmers, this practice is certainly not the case today. In today’s thriving software industry, you can purchase software for just about any business situation imaginable. However, every business is unique, and no existing software fits a given firm and its needs exactly. Software must be modified to fit a company’s specific needs. Many times, a business application is actually a combination of many different bits and pieces of software, purchased or otherwise acquired from many different vendors and integrated by a firm’s internal information technology staff. But where does the IT staff find all the software it needs? Here you will learn about the many sources of software available to today’s system analyst.

Introduction

Many different sources of software are available, and many of you reading this will end up working for firms that produce software rather than working in the information systems department of a corporation. But for those of you who go on to work in a corporate information systems department, the focus is no longer exclusively on in-house development. Instead, the focus will be on where to obtain the many pieces and components that you will combine into the application system you have been asked to create. You and your peers will still write code, mainly to make all the different pieces work together, but more and more of your application software will be written by someone else. Even though you will not write the code, you will still use the basic structure and processes of the systems development life cycle (SDLC) to build the application systems your organization demands. The organizational process of systems development remains the focus, but first you need to know more about where software originates in today’s development environment.

Here, you will learn about the various sources of software for organizations. The first source considered is outsourcing, in which all or part of an organization’s information systems, their development, and their maintenance are given over to another organization. You will then read about six different sources of software: (1) information technology services firms, (2) packaged software providers, (3) vendors of enterprise solutions software, (4) cloud computing, (5) open-source software, and (6) the organization itself when it develops software in-house. You will learn of criteria to evaluate software from these different sources. The discussion closes with a look at reuse and its impact on software development.

Systems Acquisition

Despite some debate about when and where the first administrative information system was developed, it is generally agreed that the first such system in the United Kingdom was developed at J. Lyons & Sons. In the United States, the first administrative information system was the General Electric (GE) payroll system, which was developed in 1954. At that time, and for many years afterwards, obtaining an information system meant one thing only: in-house development. The software industry itself did not even come into existence until a decade after GE’s payroll system was implemented.

Since GE’s payroll system was built, in-house development has become a progressively smaller piece of all the systems development work that takes place in and for organizations. Internal corporate information systems departments now spend a smaller and smaller proportion of their time and effort on developing systems from scratch. Corporate information systems groups reported spending less time and money on traditional software development and maintenance than they used to. Instead, they increased work on packaged applications by a factor of three, and they increased outsourcing by 42 percent.

Organizations today have many choices when seeking an information system. We will start with a discussion of outsourcing development and operation and then present the six categories of software sources mentioned earlier. These various sources represent points along a continuum of options, along with many hybrid combinations as well.

Outsourcing

If another organization develops or runs a computer application for your organization, that practice is called outsourcing. Outsourcing includes a spectrum of working arrangements. At one extreme is having a firm develop and run your application on its computers—you only supply input and take output. A common example is a company that runs payroll applications for clients so that clients don’t have to develop an independent in-house payroll system. Instead they simply provide employee payroll information to the company and, for a fee, the company returns completed paychecks, payroll accounting reports, and tax and other statements for employees. For many organizations, the most cost-effective way to manage payroll operations is through outsourcing. In another example of outsourcing arrangements, you hire a company to run your applications at your site on your computers. In some cases, an organization employing such an arrangement will dissolve some or all of its information systems unit and transfer most or all of its information systems employees to the company brought in to run the organization’s computing.

Outsourcing

The practice of turning over responsibility for some or all of an organization’s information systems applications and operations to an outside firm.

Why would an organization outsource its information systems operations? As we saw in the payroll example, outsourcing may be cost effective. If a company specializes in running payroll for other companies, it can leverage the economies of scale it achieves from running one stable computer application for many organizations into low prices. But why would an organization dissolve its entire information processing unit and bring in an outside firm to manage its computer applications? One reason may be to overcome operating problems the organization faces in its information systems unit. For example, the city government of Grand Rapids, Michigan, hired an outside firm to run its computing center forty years ago in order to manage its computing center employees better. Union contracts and civil service constraints, then in force, made it difficult to fire people, so the city brought in a facilities management organization to run its computing operations, and it was able to get rid of problem employees at the same time. Another reason for total outsourcing is that an organization’s management may feel its core mission does not involve managing an information systems unit and that it might achieve more effective computing by turning over all of its operations to a more experienced, computer-oriented company. Kodak decided in the late 1980s that it was not in the computer applications business and turned over management of its mainframes to IBM and management of its personal computers to Businessland.

Outsourcing is big business. Some organizations outsource the IT development and many of their IT functions, at a cost of billions of dollars. The global business process and information technology outsourcing market is projected to be worth $1.2 billion (USD) by 2017. Individual outsourcing vendors sign large contracts for their services. IBM and HP are two of the biggest, best-known global outsourcing firms. Both companies have multiple outsourcing contracts in place with many different firms.

Outsourcing is an alternative that analysts definitely need to be aware of. When generating alternative system development strategies for a system, you as an analyst should consult organizations in your area that provide outsourcing services. It may well be that at least one such organization has already been developed and is running an application similar to what your users are asking for. Perhaps outsourcing the replacement system should be one of your alternatives. Knowing what your system requirements are before you consider outsourcing means that you can carefully assess how well the suppliers of outsourcing services can respond to your needs. However, should you decide not to outsource, you need to consider whether some software components of your replacement system should be purchased and not built.

Sources of Software

We can group organizations that produce software into six major categories: (1) information technology services firms, (2) packaged software providers, (3) vendors of enterprise solutions software, (4) cloud computing, (5) open-source software, and (6) in-house development ( Figure 2-1 ).

Information Technology Services Firms

If a company needs an information system but does not have the expertise or the personnel to develop the system in-house and a suitable off-the-shelf system is not available, the company will likely consult an information technology (IT) services firm. IT services firms help companies develop custom information systems for internal use; they develop, host, and run applications for customers, or they provide other services. Note Table 2-1 lists many of the top global software firms; these well-known companies specialize in services, including custom systems development. These firms employ people with expertise in the development of information systems. Their consultants may also have expertise in a given business area. For example, consultants who work with banks understand financial institutions as well as information systems. Consultants use many of the same methodologies, techniques, and tools that companies use to develop systems in-house.

FIGURE 2-1

Sources of application software.

It may surprise you to find out that IBM is the world’s top software producer. You may think of IBM as a hardware company primarily. Yet IBM has been moving away from a reliance on hardware development for many years. The purchase of the IT consulting arm of PricewaterhouseCoopers by IBM in 2002 solidified its move into services and consulting. IBM is also well known for its development of Web server and middleware software. Other leading IT services firms include traditional consulting firms such as Accenture. The list also includes HP, another company formerly focused on hardware that has made the transition to an IT services firm.

Packaged Software Producers

The growth of the software industry has been phenomenal since its beginnings in the mid-1960s. Now, some of the largest computer companies in the world are companies that produce software exclusively (see Table 2-1 ). Software companies develop what are sometimes called prepackaged or off-the-shelf systems. Microsoft’s Project and Intuit’s Quicken, QuickPay, and QuickBooks are popular examples of such software. The packaged software development industry serves many market segments. Its software offerings range from general, broad-based packages, such as general ledger, to more narrow, niche packages, such as software to help manage a day-care center. Software companies develop software to run on many different computer platforms, from microcomputers to large mainframes. The companies range in size from just a few people to thousands of employees. Software companies consult with system users after the initial software design has been completed and after an early version of the system has been built. The systems are then tested in actual organizations to reveal any problems or determine any improvements that can be made. Until testing is completed, the system is not offered for sale to the public.

TABLE 2-1:

Leading Software Firms and Their Development Specializations

Specialization	Example Firms or Websites
IT Services	Accenture Capgemini Sogenti Computer Sciences Corporation (CSC) IBM HP
Packaged Software Providers	Microsoft Intuit Oracle Symantec Adobe
Enterprise Software Solutions	Oracle SAP AG
Cloud Computing	Amazon.com Google Microsoft Salesforce.com
Open Source	SourceForge.net

Some off-the-shelf software systems cannot be modified to meet the specific, individual needs of a particular organization. Such application systems are sometimes called turnkey systems. The producer of a turnkey system will make changes to the software only when a substantial number of users ask for a specific change. Other off-the-shelf application software can be modified or extended, however, by the producer or the user to fit the needs of the organization more closely. Even though many organizations perform similar functions, no two organizations do the same thing in quite the same way. A turnkey system may be good enough for a certain level of performance, but it will never perfectly match the way a given organization does business. A reasonable estimate is that off-the-shelf software can at best meet 70 percent of an organization’s needs. Thus, even in the best case, 30 percent of the software systems used don’t perfectly match the organization’s specifications.

Enterprise Solutions Software

As mentioned earlier, more and more organizations are choosing complete software solutions, called enterprise solutions or enterprise resource planning (ERP) systems , to support their operations and business processes. These ERP software solutions consist of a series of integrated modules. Each module supports an individual traditional business function, such as accounting, distribution, manufacturing, or human resources. The difference between the modules and traditional approaches is that the modules are integrated to focus on business processes rather than on business functional areas. For example, a series of modules will support the entire order-entry process, from receiving an order to adjusting inventory to shipping to billing to after-the-sale service. The traditional approach would use different systems in different functional areas of the business, such as a billing system in accounting and an inventory system in the warehouse. Using ERP systems, a firm can integrate all parts of a business process in a unified information system. All aspects of a single transaction occur seamlessly within a single information system, rather than in a series of disjointed, separate systems focused on business functional areas.

Enterprise resource planning (ERP) system

A system that integrates individual traditional business functions into a series of modules so that a single transaction occurs seamlessly within a single information system rather than several separate systems.

The benefits of the enterprise solutions approach include a single repository of data for all aspects of a business process and the flexibility of the modules. A single repository ensures more consistent and accurate data, as well as less maintenance. The modules are flexible because additional modules can be added as needed once the basic system is in place. Added modules are immediately integrated into the existing system.

Enterprise solutions software also involves some disadvantages. The systems are complex, so implementation can take a long time to complete. Organizations typically do not have the necessary expertise in-house to implement the systems, so they must rely on consultants or employees of the software vendor, which can be expensive. In some cases, organizations must change how they do business in order to benefit from a shift toward enterprise solutions.

Several major vendors offer enterprise solutions software. The best-known vendor is probably SAP AG, a German firm, known for its flagship product R/3. SAP AG was founded in 1972, but most of its growth has occurred since 1992. The other major vendor of enterprise solutions is Oracle Corp., a U.S.-based firm, perhaps better known for its database software. At the end of 2004, Oracle acquired PeopleSoft, Inc., a U.S. firm founded in 1987. PeopleSoft began with enterprise solutions that focused on human resources management and expanded to cover financials, materials management, distribution, and manufacturing before Oracle acquired it. Just before being purchased by Oracle, PeopleSoft had boosted its corporate strength in 2003 through acquiring another ERP vendor, J.D. Edwards. Together, SAP and Oracle control about 42 percent of the ERP market. As the higher end of the market has become saturated with ERP systems, most ERP vendors are looking to medium and small businesses for growth.

Cloud Computing

Another method for organizations to obtain applications is to rent them or license them from third-party providers who run the applications at remote sites. Users have access to the applications through the Internet or through virtual private networks (VPNs). The application provider buys, installs, maintains, and upgrades the applications. Users pay on a per-use basis or they license the software, typically month to month. Although this practice has been known by many different names over the years, today it is called cloud computing . Cloud computing refers to the provision of applications over the Internet, where customers do not have to invest in the hardware and software resources needed to run and maintain the applications. You may have seen the Internet referred to as a cloud in other contexts, which comes from how the Internet is depicted on computer network diagrams. A well-known example of cloud computing is Google Apps, which provides common personal productivity tools online, while the software runs on Google’s servers. Another well-known example is Salesforce.com, which provides customer relationship management (CRM) software online. Cloud computing includes many areas of technology, including software as a service (often referred to as SaaS), which includes Google Apps and Salesforce.com, and hardware as a service, which allows companies to order server capacity and storage on demand.

Cloud computing

The provision of computing resources, including applications, over the Internet, so customers do not have to invest in the computing infrastructure needed to run and maintain the resources.

Microsoft and IDC predicted that cloud computing will create 14 million new jobs by 2015 and that the total global market for cloud computing will reach $1.1 trillion (USD) that year (McDougall, 2012) . The companies that are most likely to profit immediately are those that can quickly adjust their product lines to meet the needs of cloud computing. These include such well-known names as IBM, which has built several cloud computing centers worldwide; Microsoft, which in 2008 announced its Azure platform to support the development and operation of business applications and consumer services on its own servers; and Amazon.com, which provides storage and capacity from its own servers to customers.

As these growth forecasts indicate, taking the cloud-computing route has its advantages. The top three reasons for choosing to go with cloud computing, all of which result in benefits for the company, are: (1) freeing internal IT staff, (2) gaining access to applications faster than via internal development, and (3) achieving lower-cost access to corporate-quality applications. Especially appealing to companies is the ability to gain access to large and complex systems without having to go through the expensive and time-consuming process of implementing the systems themselves in-house. Getting your computing through a cloud also makes it easier to walk away from an unsatisfactory systems solution. IT managers do have some concerns, however. The primary concern is reliability, but other concerns include security and compliance with government regulations such as Sarbanes-Oxley.

Open-Source Software

Open-source software is unlike the other types of software you have read about so far. Open-source software is different because it is freely available—not just the final product, but the source code itself. It is also different because it is developed by a community of interested people instead of by employees of a particular company. Open-source software performs the same functions as commercial software, such as operating systems, e-mail, database systems, and Web browsers. Some of the most well-known and popular open-source software names are Linux (an operating system), mySQL (a database system), and Firefox (a Web browser). Open source also applies to software components and objects. Open source is developed and maintained by communities of people. These communities can sometimes be quite large. Developers often use common Web resources, such as SourceForge.net, to organize their activities. In February 2014, SourceForge.net hosted more than 430,000 projects and had over 3.7 million registered users. Without question, the open-source movement would not be having the success it enjoys without the availability of the Internet for providing access and organizing development activities.

If the software is free, you might wonder how anybody makes any money by developing open-source software. Companies and individuals can make money with open source by (1) providing maintenance and other services, or (2) providing one version of the software for free and selling a more fully featured version. Some open-source solutions have more of an impact on the software industry than others. Linux, for example, has been very successful in the server market, where it is estimated to have 23 percent of the market share. Other open-source software products, such as mySQL, have also been successful, and open source’s share of the software industry seems destined to continue growing.

In-House Development

We have talked about several different types of external organizations that serve as sources of software, but in-house development remains an option. Of course, in-house development need not entail development of all of the software that will compose the total system. Hybrid solutions involving some purchased and some in-house software components are common. Some in-house software components are reused. Table 2-2 compares the six different software sources.

Choosing Off-the-Shelf Software

Once you have decided to purchase off-the-shelf software rather than write some or all of the software for your new system, how do you decide what to buy? Several criteria need consideration, and special ones may arise with each potential software purchase. For each standard, an explicit comparison should be made between the software package and the process of developing the same application in-house. The most common criteria, highlighted in Figure 2-2 , are as follows:

TABLE 2-2:

Comparison of Six Different Sources of Software Components

Producers	When to Go to This Type of Organization for Software	Internal Staffing Requirements
IT services firms	When task requires custom support and system can’t be built internally or system needs to be sourced	Internal staff may be needed, depending on application
Packaged software producers	When supported task is generic	Some IS and user staff to define requirements and evaluate packages
Enterprise solutions vendors	For complete systems that cross functional boundaries	Some internal staff necessary but mostly need consultants
Cloud computing	For instant access to an application; when supported task is generic	Few; frees up staff for other IT work
Open-source software	When supported task is generic but cost is an issue	Some IS and user staff to define requirements and evaluate packages
In-house developers	When resources and staff are available and system can be built from scratch	Internal staff necessary but staff size may vary

FIGURE 2-2

Common criteria for choosing off-the-shelf software.

· Cost

· Functionality

· Vendor support

· Viability of vendor

· Flexibility

· Documentation

· Response time

· Ease of installation

The relative importance of these standards will vary from project to project and from organization to organization. If you had to choose two criteria that would always be among the most important, those two would probably be vendor support and vendor viability. You don’t want to license software from a vendor that has a reputation for poor support. Similarly, you don’t want to get involved with a vendor that might not be in business tomorrow. How you rank the importance of the remaining criteria depends primarily on your specific situation.

Cost involves comparing the cost of developing the same system in-house to the cost of purchasing or licensing the software package. Be sure to include a comparison of the cost of purchasing vendor upgrades or annual license fees with the costs you would incur to maintain your own software. Costs for purchasing and developing in-house can be compared based on the economic feasibility measures. Functionality refers to the tasks the software can perform and the mandatory, essential, and desired system features. Can the software package perform all, or just some, of the tasks your users need? If some, can it perform the necessary core tasks? Note that meeting user requirements occurs at the end of the analysis phase because you cannot evaluate packaged software until user requirements have been gathered and structured. Purchasing application software is not a substitute for conducting the systems analysis phase.

As we said earlier, vendor support refers to whether the vendor can provide support, and how much. Support includes assistance to install the software, to train user and systems staff on the software, and to provide help as problems arise after installation. Recently, many software companies have significantly reduced the amount of free support they provide customers, so the cost to use telephone, on-site fax, or computer bulletin board support facilities should be considered. Related to support is the vendor’s viability. This latter point should not be minimized. The software industry is quite dynamic, and innovative application software is created by entrepreneurs working from home offices—the classic cottage industry. Such organizations, even with outstanding software, often do not have the resources or business management ability to stay in business long. Further, competitive moves by major software firms can render the products of smaller firms outdated or incompatible with operating systems. One software firm we talked to while developing this book was struggling to survive by working to make its software operate on any Windows, Mac OS, or mobile platform. Keeping up with hardware and system software changes may be more than a small firm can handle, and good off-the-shelf application software is lost.

Flexibility refers to how easy it is for you, or the vendor, to customize the software. If the software is not sufficiently flexible, your users may have to adapt the way they work to fit the software. Are they likely to adapt in this manner? Purchased software can be modified in several ways. Sometimes, the vendor will make custom changes for you if you are willing to pay for the redesign and programming. Some vendors design the software for customization. For example, the software may include several different ways of processing data and, at installation time, the customer chooses which to initiate. Also, displays and reports may be easily redesigned if these modules are written in a fourth-generation language. Reports, forms, and displays may be easily customized using a process whereby your company name and chosen titles for reports, displays, forms, and column headings are selected from a table of parameters you provide. You may want to employ some of these same customization techniques for in-house-developed systems so that the software can be easily adapted for different business units, product lines, or departments.

Documentation includes the user’s manual as well as technical documentation. How understandable and up to date is the documentation? What is the cost for multiple copies, if required? Response time refers to how long it takes the software package to respond to the user’s requests in an interactive session. Another measure of time would be how long it takes the software to complete running a job. Finally, ease of installation is a measure of the difficulty of loading the software and making it operational.

Validating Purchased Software Information

One way to get all of the information you want about a software package is to collect it from the vendor. Some of this information may be contained in the software documentation and technical marketing literature. Other information can be provided upon request. For example, you can send prospective vendors a questionnaire asking specific questions about their packages. This questionnaire may be part of a request for proposal (RFP) or request for quote (RFQ) process your organization requires when major purchases are made.

Request for proposal (RFP)

A document provided to vendors to ask them to propose hardware and system software that will meet the requirements of a new system.

If you decide that new hardware or system software is a strong possibility, you may want to issue a request for proposal (RFP) to vendors. The RFP will ask the vendors to propose hardware and system software that will meet the requirements of your new system. Issuing an RFP gives you the opportunity to have vendors conduct the research you need in order to decide among various options. You can request that each bid submitted by a vendor contain certain information essential for you to decide on what best fits your needs. For example, you can ask for performance information related to speed and number of operations per second. You can ask about machine reliability and service availability and whether an installation is located nearby that you can visit for more information. You can ask to take part in a demonstration of the hardware. The bid will also include information on cost.

Of course, actually using the software yourself and running it through a series of tests based on the criteria for selecting software may provide the best route for evaluation. Remember to test not only the software, but also the documentation, the training materials, and even the technical support facilities. One requirement you can place on prospective software vendors as part of the bidding process is that they install (free or at an agreed-upon cost) their software for a limited amount of time on your computers. This way you can determine how their software works in your environment, not in some optimized environment they have created.

One of the most reliable and insightful sources of feedback is other users of the software. Vendors will usually provide a list of customers (remember, they will naturally tell you about satisfied customers, so you may have to probe for a cross section of customers) and people who are willing to be contacted by prospective customers. Here is where your personal network of contacts, developed through professional groups, college friends, trade associations, or local business clubs, can be a resource; do not hesitate to find some contacts on your own. Such current or former customers can provide a depth of insight on the use of a package at their organizations.

To gain a range of opinions about possible packages, you can use independent software testing services that periodically evaluate software and collect user opinions. Such surveys are available for a fee either as subscription services or on demand. Occasionally, unbiased surveys appear in trade publications. Often, however, articles in trade publications, even software reviews, are actually seeded by the software manufacturer and are not unbiased.

If you are comparing several software packages, you can assign scores for each package on each criterion and compare the scores using the quantitative method (see Chapter 7 ) for comparing alternative system design strategies.

Reuse

Reuse is the use of previously written software resources in new applications. Because so many bits and pieces of applications are relatively generic across applications, it seems intuitive that great savings can be achieved in many areas if those generic bits and pieces do not have to be written anew each time they are needed. Reuse should increase programmer productivity, because being able to use existing software for some functions means they can perform more work in the same amount of time. Reuse should also decrease development time, minimizing schedule overruns. Because existing pieces of software have already been tested, reusing them tends to result in higher-quality software with lower defect rates, decreasing maintenance costs.

Reuse

The use of previously written software resources, especially objects and components, in new applications.

Although reuse can conceivably apply to many different aspects of software, typically it is most commonly applied to two different development technologies: object-oriented and component-based development. For example, consider an object class created to model an employee. The object class Employee would contain both the data about employees and the instructions necessary for calculating payroll for a variety of job types. The object class could be used in any application that dealt with employees, but if changes had to be made in calculating payroll for different types of employees, the changes would only have to be made to the object class and not to the various applications that used it. By definition, using the Employee object class in more than one application constitutes reuse.

Component-based development is similar to object-oriented development in that the focus is on creating general-purpose pieces of software that can be used interchangeably in many different programs. Components can be as small as objects or as large as pieces of software that handle single business functions, such as currency conversion. The idea behind component-based development is the assembly of an application from many different components at many different levels of complexity and size. Many vendors are working on developing libraries of components that can be retrieved and assembled as needed into desired applications.

Some evidence suggests that reuse can be effective, especially for object classes. For example, one laboratory study found that reuse of object class libraries resulted in increased productivity, reduced defect density, and reduced rework. For HP, a reuse program resulted in cutting time to market for certain products by a factor of three or more, from eighteen months to less than five months. However, for reuse to work in an organizational setting, many different issues must be addressed. Technical issues include the current lack of a methodology for creating and clearly defining and labeling reusable components for placement in a library and the small number of reusable and reliable software resources currently available. Key organizational issues include the lack of commitment to reuse, as well as the lack of proper training and rewards needed to promote it, the lack of organizational support for institutionalizing reuse, and the difficulty in measuring the economic gains from reuse. Because of the considerable costs of developing a reusable component, most organizations cannot compete economically with established commercial organizations that focus on selling components as their main line of business. Success depends on being able to leverage the cost of components across a large user and project base ( Figure 2-3 ). Key legal and contractual issues concerning the reuse of object classes and components originally used in other applications must also be addressed.

When an organization’s management decides to pursue reuse as a strategy, it is important for the organization to match its approach to reuse with its strategic business goals. The benefits of reuse grow as more corporate experience is gained from it, but so do the costs and the amount of resources necessary for reuse to work well. Software reuse has three basic steps: abstraction, storage, and recontextualization. Abstraction involves the design of a reusable piece of software, starting from existing software assets or from scratch. Storage involves making software assets available for others to use. Although it sounds like a simple problem, storage can actually be very challenging. The problem is not simply putting software assets on a shelf; the problem is correctly labeling and cataloging assets so that others can find the ones they want to use. Once an asset has been found, recontextualization—or making the reusable asset understandable to developers who want to use it in their systems—becomes important. Software is complex, and a software asset developed for a particular system under system-specific circumstances may not at all be the asset it appears to be. What seems to be a generic asset called “Customer” may actually be something quite different, depending on the context in which it was developed. It may often appear to be easier to simply build your own assets rather than invest the time and energy it takes to establish a good understanding of software someone else has developed. A key part of a reuse strategy, as mentioned previously, is establishing rewards, incentives, and organizational support for reuse to help make it more worthwhile than developing your own assets.

FIGURE 2-3

Investments necessary to achieve reusable components.

Source: Royce, W . Software Project Management: A Unified Framework. Boston, MA: Addison-Wesley, 1998. Used by permission.

An organization can take one of four approaches to reuse (see Table 2-3 ). The ad hoc reuse approach is not really an approach at all, at least from an official organizational perspective. With this approach, individuals are free to find or develop reusable assets on their own, but few, if any, organizational rewards are offered for reusing assets. Storage is not an issue, because individuals keep track of and distribute their own software assets. For such an ad hoc, individually driven approach, it is difficult to measure any potential benefits to the company.

Another approach to reuse is facilitated reuse. With this approach, developers are not required to practice reuse, but they are encouraged to do so. The organization makes available some tools and techniques that enable the development and sharing of reusable assets, and one or more employees may be assigned the role of evangelist to publicize and promote the program. Little is done to track the quality and use of reusable assets; however, the overall corporate investment is small.

Managed reuse is a more structured, and more expensive, mode of managing software reuse. With managed reuse, the development, sharing, and adoption of reusable assets is mandated. The organization establishes processes and policies for ensuring that reuse is practiced and that the results are measured. The organization also establishes policies and procedures for ensuring the quality of its reusable assets. The focus is on identifying existing assets that can be potentially reused from various sources, including from utility asset libraries that come with operating systems, from companies that sell assets, from the open-source community, from internal repositories, from scouring existing legacy code, and so on.

The most expensive and extensive approach to reuse is designed reuse. In addition to mandating reuse and measuring its effectiveness, the designed reuse approach takes the extra step of mandating that assets be designed for reuse as they are being designed for specific applications. The focus is more on developing reusable assets than on finding existing assets that might be candidates for reuse. A corporate reuse office may be established to monitor and manage the overall methodology. Under such an approach, as much as 90 percent of software assets may be reused across different applications.

TABLE 2-3:

Approaches to Reuse

Approach	Reuse Level	Cost	Policies & Procedures
Ad hoc	None to low	Low	None
Facilitated	Low	Low	Developers are encouraged to reuse but are not required to do so.
Managed	Moderate	Moderate	Development, sharing, and adoption of reusable assets are mandated; organizational policies are established for documentation, packaging, and certification.
Designed	High	High	Reuse is mandated; policies are put in place so that reuse effectiveness can be measured; code must be designed for reuse during initial development, regardless of the application it is originally designed for; there may be a corporate office for reuse.

Source: Based on Griss, 2003.

Each approach to reuse has its advantages and disadvantages. No single approach is a silver bullet that will solve the reuse puzzle for all organizations and for all situations. Successful reuse requires an understanding of how reuse fits within larger organizational goals and strategies as well as an understanding of the social and technical world into which the reusable assets must fit.

Even though reuse is valuable to many organizations, it turns out it is not as valuable to all developers in any given organization. Novice developers are more likely to reuse code and components than are more experienced developers. Novice developers are more risk averse and do not want to make mistakes, so they tend to reuse an existing code that has already been tested and verified. More experienced developers tend to trust their own coding skills more than they trust the skills of others, so they prefer to write and test their own code. Differences in reuse across different types of development teams are also common. Transient project teams, which will only exist for a short time, are more likely to reuse than are established, more permanent project teams.

Key Points Review

1. Explain outsourcing.

Outsourcing is the practice of turning over to another organization all or part of the responsibility for your information systems’ development, operation, and maintenance. Outsourcing can be done through many different organizational arrangements, all of which are governed through contractual agreements. Outsourcing is big business, with large computer firms such as IBM and HP each handling several contracts worth billions of dollars per year. As an analyst, you need to consider outsourcing seriously as an alternative way to get things done.

2. Describe six different sources of software.

As a systems analyst, you must be aware of where you can obtain software that meets some or all of an organization’s needs. You can obtain application (and system) software from information technology services firms, packaged software providers, vendors of enterprise solutions software, cloud computing, and open-source software providers, as well as from internal systems development resources, including the reuse of existing software components.

3. Discuss how to evaluate off-the-shelf software.

You must also know the criteria to use when choosing among off-the-shelf software products. These criteria include cost, functionality, vendor support, vendor viability, flexibility, documentation, response time, and ease of installation. Requests for proposals are one way you can collect more information about system software, its performance, and its costs.

4. Explain reuse and its role in software development.

Reuse is the use of previously written software resources in new applications. Reuse should increase programmer productivity, decrease development time, and result in higher-quality software with lower defect rates, decreasing maintenance costs. Some evidence suggests that reuse can be effective, especially for object classes. However, when an organization pursues reuse as a strategy, its reuse strategy should match its strategic business goals.