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.
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 levelsof 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. 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.
Foundations for Systems Development
TABLE 2-3: Approaches to Reuse
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. 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 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 a short time, are more likely to reuse than are established, more permanent project teams.
Key Points Reviewe
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.
Key Terms Checkpoint
Here are the key terms from the chapter. The page where each term is first explained is in parentheses after the term.
1. Cloud computing (p. 32)
2. Enterprise resource planning (ERP) system (p. 31)
3. Outsourcing (p. 28)
4. Request for proposal (RFP) (p. 35)
5. Reuse (p. 36)
Match each of the key terms above with the definition that best fits it.
-----1. The practice of turning over responsibility of some or all of an organization’s information systems applications and operations to an outside firm.
-----2. 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.
-----3. A document provided to vendors to ask them to propose hardware and system software that will meet the requirements of your new system.
-----4. The use of previously written software resources, especially objects and components, in new applications.
-----5. The provision of computing resources over the Internet, so customers do not have to invest in the computing infrastructure needed to run and maintain the resources.
Foundations for Systems Development
1. Describe and compare the six sources of software.
2. How can you decide among various off-theshelf software options? What criteria should you use?
3. What is an RFP, and how do analysts use one to gather information about hardware and system software?
4. What methods can a systems analyst employ to verify vendor claims about a software package?
5. What are ERP systems? What are the benefits and disadvantages of such systems as a design strategy?
6. Explain reuse and its advantages and disadvantages.
7. Compare and contrast the four approaches to reuse.
8. Why would a company rely on cloud computing for its software needs?
Problems and Exercises
1. Research how to prepare an RFP.
2. Review the criteria for selecting off-the-shelf software presented in this chapter. Use your experience and imagination and describe other criteria that are or might be used to select off-theshelf software in the “real world.” For each new criterion, explain how use of this criterion might be functional (i.e., it is useful to use this criterion), dysfunctional, or both.
3. In the section on choosing off-the-shelf software, eight criteria are proposed for evaluating alternative packages. Suppose the choice is between alternative custom software developers rather than prewritten packages. What criteria would be appropriate to select and compare among competing bidders for custom development of an application? Define each of these criteria.
4. How might the project team recommending an ERP design strategy justify its recommendation as compared with other types of design strategies?
1. Interview businesspeople who participate in the purchase of off-the-shelf software in their organizations. Review with them the criteria for selecting off-the-shelf software presented in this chapter. Have them prioritize the list of criteria as they are used in their organization and provide an explanation of the rationale for each criterion’s ranking. Ask them to list and describe any other criteria that are used in their organization.
2. Obtain copies of actual RFPs used for information systems developments or purchases. If possible, obtain RFPs from public and private organizations. Find out how they are used. What are the major components of these proposals? Do these proposals seem to be useful? Why or why not? How and why do RFPs from public and private organizations differ?
3. Contact an organization that has or is implementing an integrated ERP application. Why did it choose this design strategy? How has it managed this development project differently from prior large projects? What organizational changes have occurred due to this design strategy? How long did the implementation last and why?
CASE: PETRIE’S ELECTRONICS
The Sources of Software?
Jim Watanabe looked around his new office. He couldn’t believe that he was the assistant director of information technology at Petrie’s Electronics, his favorite consumer electronics retail store. He always bought his new DVDs and video games for his Xbox 360 at Petrie’s. In fact, he had bought his Blu-ray player and his Xbox 360 at Petrie’s, along with his surround sound system and his 40" flat-screen HD LED TV. And now he worked there too. The employee discount was a nice perk1 of his new job, but he was also glad that his technical and people skills were finally recognized by the people at Petrie’s. He had worked for five years at Broadway Entertainment Company as a senior systems analyst, and it was clear that he was not going to be promoted there.
He was really glad he had put his résumé up on Monster.com and that now he had a bigger salary and a great job with more responsibility at Petrie’s. Petrie’s Electronics had started as a single electronics store in 1984 in San Diego, California. The store was started by Jacob Rosenstein in a strip mall. It was named after Rob Petrie, the TV writer played by Dick Van Dyke in the TV show named after himself. Rosenstein always liked that show. When he had grown the store to a chain of thirteen stores in the Southern California area, it was too much for Rosenstein to handle. He sold out in 1992, for a handsome profit, to the Matsutoya Corporation, a huge Japanese conglomerate that saw the chain of stores as a place to sell its many consumer electronics goods in the U.S. Matsutoya aggressively expanded the chain to 218 stores nationwide by the time they sold the chain in 2002, for a handsome profit, to Sam and Harry’s, a maker and seller of ice cream. Sam and Harry’s was looking for a way to diversify and invest the considerable cash they had made creating and selling ice cream, with flavors named after actors and actresses, like their best selling Lime Neeson and Jim Carrey-mel.
Sam and Harry’s brought in professional management to run the chain, and since they bought it, they added fifteen more stores, including one in Mexico and three in Canada. Even though they originally wanted to move the headquarters to their home state of Delaware, Sam and Harry decided to keep Petrie’s headquartered in San Diego. The company had made some smart moves and had done well, Jim knew, but he also knew that competition was fierce. Petrie’s competitors included big electronics retail chains like Best Buy. In California, Fry’s was a ferocious competitor. Other major players in the arena included the electronics departments of huge chains like Wal-Mart and Target and online vendors like Amazon.com. Jim knew that part of his job in IT was to help the company grow and prosper and beat the competition—or at least survive. Just then, as Jim was trying to decide if he needed a bigger TV, Ella Whinston, the chief operations officer at Petrie’s, walked into his office.
“How’s it going, Jim? Joe keeping you busy?” Joe was Joe Swanson, Jim’s boss, the director of IT. Joe was away for the week, at a meeting in Pullman, Washington. Jim quickly pulled his feet off his desk. “Hi, Ella. Oh, yeah, Joe keeps me busy. I’ve got to get through the entire corporate strategic IT plan before he gets back—he’s going to quiz me—and then there’s the new help-desk training we are going to start next week.” “I didn’t know we had a strategic IT plan,” Ella teased. “Anyway, what I came in here for is to give you some good news. I have decided to make you the project manager for a project that is crucial to our corporate survival.” “Me?” Jim said. “But I just got here.” “Who better than you? You have a different perspective, new ideas. You aren’t chained down by the past and by the Petrie’s way of doing things, like the rest of us. Not that it matters, since you don’t have a choice. Joe and I both agree that you are the best person for the job.”
“So,” Jim asked, “what’s the project about?” “Well,” Ella began, “the executive team has decided that the number one priority we have right now is to not only survive but to thrive and to prosper, and the way to do that is to develop closer relationships with our customers. The other person on the executive team, who is even more excited about this than me, is John [John Smith, the head of marketing]. We want to attract new customers, like all of our competitors. But also like our competitors, we want to keep our customers for life, kind of like a frequent flier program, but better. Better for us and for our loyal customers. And we want to reward most, the customers who spend the most. We are calling the project ‘No Customer Escapes.’” “I hope that’s only an internal name,” Jim joked. “Seriously, I can see how something like this would be good for Petrie’s, and I can see how IT would play an important, no, crucial role in making something like this happen. OK, then, let’s get started.”
1. How do information systems projects get started in organizations?
2. How are organizational information systems related to company strategy? How does strategy affect the information systems a company develops and uses?
3. Research customer loyalty programs in retail firms. How common are they? What are their primary features?
4. What do you think Jim’s next step would be? Why? 5. Why would a systems analyst new to a company be a good choice to lead an important systems development effort?