Essentials of Systems Analysis and Design, 6th edition by Joseph S Valacich Solution Manual

Type:

Solution Manual

Essentials of Systems Analysis Resource: and Design Edition:

6th Edition

Author(s):

Joseph S. Valacich Joey George Jeffrey Hoffer

Chapter 1

The Systems Development Environment

1

Chapter 1

The Systems Development Environment Chapter Overview Chapter 1 is a foundation chapter, introducing students to basic, core systems analysis and design concepts. These basic concepts include a definition of information systems analysis and design, an overview of systems analysis and design core concepts, a discussion of a system and its parts, an introduction to the modern approach to systems analysis and design, an overview of the systems analyst’s role in systems development, and a review of the types of information systems and systems development. The chapter concludes with an introduction to the systems development life cycle, its four phases, and alternative approaches to development.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Define information systems analysis and design.

2. Define and discuss the modern approach to systems analysis and design.

3. Illustrate how systems development extends to different types of information systems and not just transaction processing systems.

4. Introduce the traditional information systems development life cycle, which serves as the basis for the organization of the material in this book.

5. Show students that the life cycle is a flexible basis for systems analysis and design and that it can support many different tools and techniques, such as prototyping and JAD. 6. Discuss the importance and role of CASE in systems development.

7. Discuss information systems development options, including IT services firms, packaged software producers, enterprise-wide solutions, open-source software, and in-house developers.

8. Discuss the different approaches to systems development, including prototyping, CASE tools, joint application development, rapid application development, participatory design, and Agile Methodologies.

.

Chapter 1

The Systems Development Environment

2

Classroom Ideas 1. Emphasize the differences between methodologies, techniques, and tools. Such differences are not obvious to students; often they think of methodologies as just a set of techniques and that techniques and tools are synonymous.

2. Give concrete examples during class discussion of the following types of IS: transaction processing systems, management information systems, and decision support systems. Ask students to talk about the information systems with which they are familiar.

3. When discussing different types of information systems, discuss the differences between systems that support back room operations, such as basic accounting functions, and systems that directly affect the bottom line. If students are aware of such systems, they usually are not aware of how these systems provide a competitive advantage. Discussing different types of systems provides a chance to talk about the differences between these two categories of systems.

4. When introducing the life cycle model in the text, you may want to introduce other life cycle models from other textbook authors or in other forms. This shows students that there is no one standard life cycle model and that the model they will rely on when they begin work as a systems analyst will likely differ from the life cycle model in the text. The point is to show them they can use the life cycle as an archetype to understand other models, and they should understand there is no one “correct” life cycle model. The life cycle represents activities that must be done, and the phases are a way to introduce, in an organized way, the methods, techniques, tools, and skills necessary for successful systems analysis and design.

5. Give a brief overview of the activities and outputs from each of the four life cycle phases, based on your own experience or from your reading of the rest of the book.

Table 1–1 identifies the products of the four SDLC phases.

6. Although prototyping and joint application design are covered in more depth later in the book, you can provide a more in-depth introduction to these techniques than discussed in Chapter 1. Figure 1–13 is a good point of departure for a discussion of prototyping and what it adds to structured development techniques.

7. Participatory Design is briefly introduced in this chapter but can be discussed in more depth. A brief overview of the Participatory Design concept is available at http://www.cpsr.org/issues/pd/index_html. Several books are available on this topic, as well as numerous Web sites. You can also ask your students to find recent articles about this topic.

8. Spend a few minutes discussing the importance of analytical, technical, managerial, and interpersonal skills for a systems analyst. Ask students to identify which of the skills categories they think is the most important and why.

9. Figure 1–2 is an excellent tool for illustrating the basic system components.

10. Use Table 1–1 to summarize the products, outputs and deliverables of the phases of the SDLC.

.

Chapter 1

The Systems Development Environment

3

11. Compare and contrast Agile Methodologies with the traditional SDLC.

Lecture Notes What Is Information Systems Analysis and Design?

All organizations have information systems, and use them for operational, tactical, and strategic advantage. For information systems to remain effective, these systems must efficiently capture, store, process, and distribute information according to business objectives. To properly maintain these systems, systems analysts will perform information systems analysis and design. Information systems analysis and design is based on an understanding of the organization’s objectives, structure, and processes, as well as the analyst’s knowledge of how to exploit information technology for competitive advantage.

Systems Analysis and Design: Core Concepts Improving organizational information systems is the major goal of systems analysis and design. Figure 1–1 illustrates the four systems development life cycle phases. Although a systems analyst’s primary role is application software development, an analysis of the other computer-based information systems components is warranted. As Figure 1– 2 shows, these components include hardware, controls, specific job roles, users of the system, system software, and documentation and training manuals. As shown in Figure 1–3, methodologies, techniques, and tools are central to the software engineering process.

Systems This section introduces students to the definition of a system, its parts, and other important system concepts. The textbook defines a system as a group of interrelated procedures used for a business function, with an identifiable boundary, working together for some purpose. A system has nine characteristics. Figure 1–4 shows seven of the nine characteristics. The nine characteristics are: components, interrelated components, boundary, purpose, environment, interfaces, input, output, and constraints. Figure 1–5 describes a university as a system. A systems analyst should also be familiar with decomposition, modularity, coupling, and cohesion system concepts. Figure 1–6 illustrates decomposition.

A Modern Approach to Systems Analysis and Design Systems integration and enterprise-wide systems are two alternatives for company systems. The client/server model, illustrated in Figure 1–7, stresses the importance of systems integration, which is the focus of today’s systems development efforts.

Organizations may also purchase an enterprise-wide system from companies like SAP or Oracle.

.

Chapter 1

The Systems Development Environment

4

The systems analyst is the person primarily responsible for performing systems analysis and design within an organization. A job advertisement for a systems analyst position is provided in Figure 1–8. As this job advertisement indicates, a systems analyst’s skills set should include analytical, technical, managerial, and interpersonal skills.

Developing Information Systems and the Systems Development Life Cycle Organizations use a systems development methodology to develop and support their information systems. A systems development life cycle (SDLC) is a common methodology for systems development, and each organization will use a slightly different version. The life cycle presented in the textbook has four phases: (1) systems planning and selection; (2) systems analysis; (3) systems design; and (4) systems implementation and operation. Figure 1–9 illustrates these phases. Figure 1–10 illustrates the circular nature of the systems development life cycle.

Systems planning and selection has two primary activities: (1) identifying a potential project and (2) investigating the system and determining the proposed system’s scope.

Systems analysis consists of three subphases: requirements determination, requirements structuring, and alternative generation and selection. Systems design, the third life cycle phase, has two primary activities: logical design and physical design.

Figure 1–11 illustrates the differences between logical and physical design. The final phase, systems implementation and operation, involves implementing and operating the system. Table 1–1 summarizes the products of each SDLC phase.

Approaches to Development This chapter discusses six approaches to systems development. These approaches are: prototyping, computer-aided software engineering (CASE) tools, joint application design (JAD), rapid application development (RAD), participatory design (PD), and the use of Agile Methodologies. Prototyping is the process of building a scaled-down version of the desired information system. Figure 1–12 illustrates the prototyping method. Computer-aided Software Engineering (CASE) tools provide automated support for some portion of the systems development process. Computer-aided Software Engineering tools use a repository. Joint Application Design (JAD) brings users, managers, and analysts together for several days in a series of intensive meetings to specify or review system requirements. Rapid Application Development (RAD) radically decreases the time necessary to design and implement information systems. Figure 1–13 compares the RAD systems development life cycle with the standard systems development life cycle. Participatory Design (PD), developed in northern Europe, has as its central focus users and the improvement of their work lives.

Agile Methodologies focus on adaptive methodologies, people instead of roles, and a self-adaptive process.

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

.

Chapter 1

The Systems Development Environment

5

1.

systems planning and selection (28)

16.

Interface (12)

2.

information systems analysis and design (11)

17.

constraints (7)

3.

participatory design (PD) (16)

18.

systems implementation and operation (27)

4.

application software (2)

19.

systems development methodology (26)

5.

systems analyst (23)

20.

systems development life cycle (SDLC) (25)

6.

Joint Application Design (JAD) (14)

21.

decomposition (9)

7.

prototyping (17)

22.

modularity (15)

8.

system (21)

23.

coupling (8)

9.

component (5)

24.

cohesion (4)

10.

interrelated components (13)

25.

Computer-Aided Software Engineering (CASE) (6)

11.

boundary (3)

26.

repository (20)

12.

purpose (18)

27.

Rapid Application Development (RAD) (19)

13.

systems design (24)

28.

Agile Methodologies (1)

14.

systems analysis (22)

15.

environment (10)

Review Questions Solutions 1-1. What is information systems analysis and design?

Information systems analysis and design is the process of developing and maintaining an information system.

1-2. What is systems thinking? How is it useful for thinking about computerbased information systems?

Systems thinking involves identifying something as a system, visualizing the system and translating it into abstract terms, and thinking about the characteristics of the specific situation. Systems thinking is useful for thinking about computerbased information systems because information systems can be seen as subsystems in larger organizational systems, taking input from, and returning output to, their organizational environments.

1-3. What is decomposition? Coupling? Cohesion?

Decomposition is the process of breaking down a system into its component parts. Coupling is the extent to which subsystems are dependent on each other.

Cohesion is the extent to which a system or a subsystem performs a single function.

.

Chapter 1

The Systems Development Environment

6

1-4. In what way are organizations systems?

Organizations are systems because they are made up of interrelated components working together for a purpose. They take input from and return output to their environments. Organizations can be redesigned through a systems analysis and design process by which system components are replaced while preserving interconnections between components.

1-5. List and explain the different phases in the systems development life cycle.

A systems development life cycle is a set of phases that mark the development of an information system. The systems development life cycle in the textbook consists of four phases: (1) systems planning and selection; During planning and selection, an organization’s total information systems needs are analyzed and prioritized, a potential information systems project is identified, and an argument for continuing or not continuing with the project is made.

(2) systems analysis; During the analysis phase, the current system is studied, and new requirements are determined and structured according to their interrelationships. After requirements determination, alternative design strategies are generated.

(3) systems design; and During design, the chosen alternative design strategy is converted into logical and physical design specifications.

(4) systems implementation and operation.

During implementation and operation, the information system is coded, tested, and installed in the organization. Once the system is put into production, the system is systematically repaired and improved.

1-6. What is prototyping?

Prototyping is an iterative process of systems development by which requirements are converted to a working system, which is continually revised through close work between an analyst and users.

1-7. What are CASE tools? What is a CASE repository and how is it used?

CASE tools provide automated support for some portion of the systems development life cycle. CASE tools include diagramming tools, computer display and report generators, analysis tools, a central repository, documentation generators, and code generators. CASE tools are built around a repository that contains all of the metadata (such as data names, format, uses, and location) for data elements as well as the system specifications. CASE tools automate the repository for easier updating. CASE tools automate routine tasks to help programmers and analysts do their jobs better.

.

Chapter 1

The Systems Development Environment

7

1-8. What is JAD? What is Participatory Design?

Joint Application Design (JAD) is a group process involving users and systems development staff in which all parties discuss the needs for an information system and reach a shared understanding. Participatory Design (PD) is a systems development approach that originated in northern Europe in which users and the improvement in their work lives is the central focus.

1-9. What is RAD? How does it compare to the typical SDLC? Rapid application development (RAD) is a systems development methodology created to decrease the time needed to design and implement an information system. One of the hallmarks of RAD is extensive user involvement through traditional JAD sessions as well as evaluation of prototypes. RAD also includes integrated CASE tools and code generators.

1-10. What are Agile Methodologies?

Agile Methodologies promote a self-adaptive software development process.

While other methodologies focus on roles that individuals play in a project team, Agile Methodologies focus more on the individual. As software is developed, the process used to develop it is refined and improved through a review process done by the development team. Agile Methodologies differ from traditional system development methodologies in that there is less focus on process and more focus on the people involved in the project.

Problems and Exercises Solutions 1-11. Why is it important to use systems analysis and design methodologies when building a system? Why not just build the system in whatever way seems to be “quick and easy”? What value is provided by using an “engineering” approach?

Methodologies, techniques, and tools help ensure the quality and appropriateness of the system being built. Following a systems methodology, applying techniques, and using appropriate tools provides structure to the systems development process, since they have been tested and perfected by others. The quick and easy approach to building systems may be easier, cheaper, and quicker in the short run, but it almost always results in a poorly developed system, meaning that the system will be less than optimal and require extra work to maintain. In the long run, a poorly developed system requires more time and money to make right.

Following an engineering-type approach ensures that systems analysis and design is rigorous, structured, and systematic.

.

Chapter 1

The Systems Development Environment

8

1-12. Describe your university or college as a system. What is the input? The output? The boundary? The components? Their interrelationships? The constraints? The purpose? The interfaces? The environment? Draw a diagram of this system.

Students will identify a variety of inputs and outputs for the selected university or college. Possible inputs include high school transcripts, applications, tuition payments, and state and federal regulations. Outputs include diplomas, transcripts, billing statements, and inventions. A university’s boundary is more difficult to define. Does the physical boundary of the campus serve as the logical boundary for the organization? What if the school delivers outreach education in the community, state, or region? What if the school delivers technology-based distance education across the globe? How would you classify a universitysponsored high-tech start-up business that is not located on campus?

It should be easy for students to list the components of a university. They typically have “business” functions, such as procurement, facilities management, and accounting. In addition, they have academic colleges and departments, and they have academic functions such as registration and advising. Universities are usually organized along a functional hierarchy much like traditional business organizations, with vertical reporting relationships and interdisciplinary committees and task forces for horizontal coordination. Nearly all universities are faced with constraints on funding.

Many universities are also constrained by their state-granted mission. For example, they may be defined by state law as being an exclusively teaching or research institution. Alternatively, state law may mandate from where and what types of students may be admitted. The mission of most universities includes providing education, conducting research, and/or serving their communities.

Universities interact with other universities, community colleges, high schools, business organizations, professional organizations, alumni, and many other external entities. The interfaces with these external entities are sometimes formal and sometimes informal. Some examples of formal interfaces include research collaborations between professors and researchers in business or “shadowing” programs where business faculty or students go into the field and learn from a business executive.

1-13. A car is a system with several subsystems, including the braking subsystem, the electrical subsystem, the engine, the fuel subsystem, the climate-control subsystem, and the passenger subsystem. Draw a diagram of a car as a system and label all of its system characteristics.

The purpose of this question is to encourage your students to begin viewing various entities as systems, and decompose these systems into their components. A simple diagram, showing examples of the car system’s characteristics, is provided below. The car’s purpose is to provide safe transportation to wherever the driver needs to go. A constraint is the number of passengers that can ride in the vehicle.

.

Chapter 1

The Systems Development Environment

9

E nvironment

Input Interface

Fuel Subsystem

E lectrical Subsystem

Braking Subsystem

Input

E ngine

Climate-Control Subsystem Passenger Subsystem

Interface Interrelationship

Output Boundary

Interface

1-14. Your personal computer is a system. Draw and label a personal computer as a system as you did for a car in Problem and Exercise 3.

Student answers for this question will vary. However, a suggested answer, showing examples of a personal computer system’s characteristics, is provided below. The purpose of the computer is to perform operations for the user. A constraint for the system is its processing speed.

.

Chapter 1

The Systems Development Environment

10

1-15. Choose a business transaction you undertake regularly, such as using an ATM machine, buying groceries at the supermarket, or buying a ticket for a university’s basketball game. For this transaction, define the data, draw the data-flow diagram, and describe processing logic.

For an ATM transaction, the data include customer name, customer account number, customer personal identification number, customer account balance, transaction type, and transaction amount. At this point, the student should not be expected to know the structure or nomenclature of a data-flow diagram or of processing logic. For the ATM example, they should be able to explain that a customer’s name is read from the account identification number on his/her ATM card. Customers input their personal identification number by hand and, if this number is matched with their account identification number, they are granted access to begin an ATM transaction. They will either request to inquire into the status of their account, withdraw money, or deposit money. If, for example, they request to withdraw money, their request will be matched with their available funds and the allowable daily limit for that ATM machine. If acceptable, the cash will be dispensed, their account will be debited, and a receipt will be provided. Do not worry whether or not the student knows the technique or nomenclature at this point. It is more important that the student can analyze the transaction, break it down into its component parts and pieces of data, and understand the process.

1-16. How is the Joint Application Design (JAD) approach different from the Participatory Design (PD) approach developed in northern Europe? (You may have to do some digging at the library to answer this question adequately.) What are the benefits in using approaches like this in building information systems? What are the barriers?

Both Joint Application Design and Participatory Design are development processes designed to help build better systems by engaging the direct participation of users. The primary difference between them lies in the locus of control for systems development. With the JAD approach, control of systems development typically still rests with the systems staff. Indeed, the outputs from JAD sessions are commonly summarized and handled by the systems staff after users have a chance to review the transcripts. With the PD approach, control of systems development is either shared by systems personnel and users or rests solely with the users and their managers. With the movement toward end-user development in the United States, we are moving more toward shared control of systems and systems development. The benefits to the JAD and PD approaches are that they are likely to result in better systems and higher user commitment to the systems than would be the case if these techniques were not used. Some of the barriers to these approaches are that they require extra systems analyst skills and knowledge; in the short run they add more time and expense to the systems development process, and they require more time and effort from already busy users and user managers.

1-17. How would you organize a project team of students to work with a small business client? How would you organize a project team if you were working for a professional consulting organization? How might these two methods of organization differ? Why?

.

Chapter 1

The Systems Development Environment

11

The student project team should be of a size that is adequate for the task at hand.

The team members should also possess the necessary set of skills and experience for the task at hand. It is important that there be diversity of skills and abilities across team members, but it is also helpful if the team members have some common interests and values on which to build collegiality and trust. It is not necessary that there be a clearly defined “leader” for the team (leadership can rotate by time or phase), but there should be clearly defined roles and responsibilities for each of the team members. There should also be a reward structure (for example, a grade) that promotes shared responsibility and accountability. Finally, because their project is for a small business client, the team members must act professionally and deliver a quality product on time.

Surprisingly, these steps do not necessarily change much for organizing a project team within a professional consulting organization. One difference might be that, because you would be concerned more with the long-term professional growth of the team members, you might make team member selections and project assignments that take into account the long-term career development of each of the team members.

1-18. How might prototyping be used as part of the SDLC? Prototyping is useful for requirements determination, helping to clarify and communicate user requirements. Also, a prototype can serve as the basis for the final system. Imagine that an analyst is helping to develop a system that will enable a sales representative to access information about inventory levels in real time rather than having to phone someone in production who then physically checks inventory levels and calls the sales representative back. The analyst might begin by asking the sales representative what kinds of information about inventory he/she needs, including when and where he/she needs to access this information. The analyst might then use a graphical, object-oriented development tool, such as Microsoft’s VB.Net, to quickly build some sample interface displays that meet the sales representative’s needs. The analyst would then have the sales representative review these displays and give the analyst feedback. The analyst could then modify the displays and, again, solicit feedback from the sales representative. Given the ease-of-use of VB.Net, the analyst could even build the sample interface “on-the-fly” with the sales representative present and helping to build the displays. The sample interface could then be used to build the actual system, either in VB.Net or in some other development environment.

1-19. Describe the difference in the role of a systems analyst in the SDLC versus prototyping?

The role of the systems analyst in the SDLC is essentially the same as that in prototyping. The primary difference is that in prototyping, the analyst is simultaneously performing tasks from the analysis, logical design, and physical design phases of the SDLC. In cases where all or part of the prototype will be used for the actual system, the analyst is also performing tasks from the implementation phase of the SDLC. In cases where the analyst builds the prototype with the direct, real-time assistance of the users, the analyst and users are collaboratively completing several steps of the SDLC in one step.

1-20. Compare Figures 1–9 and 1–10. What similarities and differences do you see?

.

Chapter 1

The Systems Development Environment

12

Figure 1–10 illustrates an evolutionary model of the SDLC, and Figure 1–9 illustrates the circular nature of the systems development life cycle. While both figures convey the iterative nature of systems analysis and design, Figure 1–11 implies that we cycle through the systems development life cycle at varying levels of detail.

Discussion Question Solutions 1-21. If someone at a party asked you what a systems analyst was and why anyone would want to be one, what would you say? Support your answer with evidence from this chapter.

A good starting point for answering this question is to discuss the importance of an organization’s information systems and the systems analyst’s role in the systems development process. A systems analyst is a problem solver. The challenge of tackling a problem or opportunity, designing a solution, and implementing a viable, valuable, and improved information system has much appeal. Additionally, the results of the analyst’s work directly impact how the organization operates and whether or not the organization can achieve and maintain a competitive advantage. In addition, the analyst is paid quite well.

1-22. Explain how a computer-based information system designed to process payroll is a specific example of a system. Be sure to account for all nine components of any system in your explanation.

A payroll system can be thought of as a system because it is composed of interrelated subsystems that work together to accomplish a purpose. A payroll system has many components, including components that generate paychecks, make direct deposits, generate various internal reports, process time cards, and process various forms and tax returns. Many of these subsystems or components are related. For instance, the reporting component interacts with the tax, paycheck, and direct deposit components. A direct deposit made to an employee’s bank account is an example of an interface. The payroll system’s boundary encompasses all of the payroll system’s activities. Employees, banks, and the local, state, and federal governments are part of the payroll system’s environment. Hours worked, number of dependents, and number of sick days are examples of input to the payroll system. The various reports, paychecks, and tax forms are types of output. Federal and state tax regulations are examples of system constraints.

.

Chapter 1

The Systems Development Environment

13

1-23. How does the Internet, and more specifically the World Wide Web, fit into the picture of systems analysis and systems development drawn in this chapter?

The Internet has opened up a new frontier for organizations, enabling them to compete on a global basis. This new frontier of electronic commerce is having a tremendous impact on the way that organizations are conducting business.

Companies are using the World Wide Web to conduct business with their customers and suppliers, as well as facilitate internal operations. Companies need to reengineer their information systems to take advantage of the World Wide Web and all that it offers. Systems analysis and design is at the heart of this required change.

1-24. What do you think systems analysis and design will look like in the next decade? As you saw earlier in the chapter, changes in systems development have been pretty dramatic in the past. A computer programmer suddenly transported from the 1950s to the 2000s would have trouble recognizing the computing environment that had evolved just 50 years later. What dramatic changes might occur in the next ten years?

As the textbook suggests, much of today’s systems development work focuses on systems integration, which is likely to continue in the coming years. Companies are recognizing the tremendous benefits of electronic commerce and the World Wide Web, so we can expect a continued movement in that area. Over the past 50 years, we have seen much improvement in the methodologies, techniques, and tools that are used for systems development work. This trend should continue. You should encourage students to find articles about the future of systems analysis and design. Many articles are available on the Web. These articles will serve as a launching pad for class discussion.

Case Problem Solutions 1-25. Pine Valley Furniture Case Exercises a. How did Pine Valley Furniture go about developing its information systems?

Why do you think the company chose this option? What other options were available?

As mentioned in the scenario, Pine Valley Furniture developed its applications inhouse. Many reasons are plausible for why the company chose this option. The company may have had unique processing needs that required the system to be built in-house, as opposed to purchasing a prepackaged system. The company may also have viewed its information systems as helping it achieve a competitive advantage. Pine Valley Furniture had several options, including purchasing a system off-the-shelf, implementing an enterprise-wide system, or hiring an information technology services firm to develop its information systems.

.

Chapter 1

b.

The Systems Development Environment

14

One option available to Pine Valley Furniture was an enterprise-wide system. What features does an enterprise-wide system, such as SAP, provide? What is the primary advantage of an enterprise-wide system?

To answer this question, encourage your students to visit a Web site devoted to enterprise-wide systems. Information about SAP can be found at its Web site: http://www.sap.com. You may wish to have your students compare enterprisewide systems, such as SAP and PeopleSoft. Information about PeopleSoft can be obtained at http://www.oracle.com/applications/peoplesoft-enterprise.html.

Enterprise-wide systems enable companies of all sizes to better manage their financial, human resources, sales, production, and distribution processes. The primary advantage of an enterprise-wide system is its ability to integrate information across the organization.

c. Pine Valley Furniture will be hiring two systems analysts next month. Your task is to develop a job advertisement for these positions. Locate several Web sites and/or newspapers that have job advertisements for systems analysts. What skills are required?

Encourage your students to classify the required skills into four categories: analytical, technical, management, and interpersonal. A good place to start looking on the Web is at http://www.monster.com. Students should be able to find numerous systems analysts job advertisements at this Web site. d. What types of information systems are currently utilized at Pine Valley Furniture? Provide an example of each.

Pine Valley Furniture is currently using transaction processing systems, management information systems, and decision support systems. Although not specified in the case scenario, students should be able to quickly identify order processing, management reporting, and forecasting as examples of the different types of information systems.

1-26. Hoosier Burger Case Exercises a. Apply the SDLC approach to Hoosier Burger.

The systems development life cycle can be used to analyze, develop, and support Hoosier Burger’s information systems. During systems planning and selection, Bob, Thelma, and the analyst, recognize the need for improvement in the existing Hoosier Burger systems. This need will translate itself into several projects, such as new order-taking, inventory control, and management reporting systems. Also, needs are prioritized, a scope is identified, and feasibility is assessed.

During systems analysis, the analyst examines Hoosier Burger to determine system requirements, structure these requirements, and generate alternative design strategies. During systems design, both logical and physical designs are prepared. During logical design, the analyst concentrates on the business aspects of Hoosier Burger. During physical design, Hoosier Burger’s logical design is translated into physical design specifications. During systems implementation and operation, the design specifications for the new Hoosier

.

Chapter 1

The Systems Development Environment

15

Burger system become a working system, and modifications to the new information system are made when warranted. b. Using the Hoosier Burger scenario, identify an example of each system characteristic.

The ordering system is an example of a component; the order and inventory systems are interrelated components. The boundary encompasses the ordering system, inventory system, and management reporting system. Hoosier Burger’s purpose is to make a profit for its owners and to provide quality products and services to its customers. Customers, suppliers, funding agencies, and regulatory agencies exist in Hoosier Burger’s environment. An interface exists between the customer and the counter. An order serves as input; a sales receipt serves as output. Constraints would include health regulations. c. Decompose Hoosier Burger into its major subsystems.

Hoosier Burger has four major subsystems. These systems are order-taking, food preparation, inventory, and management reporting. Students may classify these subsystems differently; however, the goal is for students to decompose the Hoosier Burger system into its primary subsystems. d. Briefly summarize the approaches to systems development discussed in this chapter. Which approach do you feel should be used by Hoosier Burger?

The textbook discusses several approaches, including systems development life cycle (SDLC), prototyping, computer-aided software engineering (CASE), joint application design (JAD), rapid application development (RAD), participatory design (PD), and Agile Methodologies. The SDLC is a series of steps used to mark the phases of development for an information system. Prototyping involves iteratively designing and building a scaled-down working model of a desired system. CASE tools provide automated support for the systems development process. Joint Application Design is a structured process that brings together end users, managers, and analysts in an effort to identify system requirements and review system designs. Rapid Application Development quickly builds systems through user involvement, JAD sessions, prototyping, integrated CASE tools, and code generators. Participatory design is a systems development approach that originated in northern Europe in which users and the improvement in their worklives is the central focus. Agile Methodologies focus on adaptive methodologies, people, and a self-adaptive process. Systems development at Hoosier Burger will probably use the traditional SDLC. However, prototyping can be used to build working models of the system.

1-27. Natural Best Health Food Stores Case Exercises a. Identify the different types of information systems used at Natural Best Health Food Stores. Provide an example of each. Is an expert system currently used? If not, how could Natural Best benefit from the use of such a system?

From the description provided above, students should recognize the existence of .

Chapter 1

The Systems Development Environment

16

a transaction processing system, a management information system, and a decision support system. The transaction processing system is responsible for taking customer orders, scheduling deliveries, and updating inventory. The management information system is responsible for generating several management reports, including sales summary, delivery, and low-in-stock reports for each store location. Mr. Davis uses an Excel worksheet for decision support.

The case scenario does not specifically mention an expert system. However, students should identify several potential uses of an expert system, including using the expert system to make product recommendations for customers. b. Figure 1–4 identifies seven characteristics of a system. Using the Natural Best Health Food Stores scenario, provide an example of each system characteristic.

Inventory management and sales are two system components. Inventory management and sales are interrelated, because a product cannot be sold unless it is in stock or placed on back order. On a physical level, the boundary is defined by each store building. On a systems level, the boundary can be defined by the NBDS system activities, such as transaction processing, management reporting, and facilitating decision making. The purpose of Natural Best Health Food Stores is to provide healthy, quality products to its customers at an affordable price. The environment includes customers, suppliers, banks, and regulatory agencies.

Interfaces include order taking, product deliveries, management reports, and lowin-stock notifications. Inputs include the order information, packing slips, and customer profiles. Outputs include sales receipts, delivery slips, and management reports. Constraints include the number of deliveries that can be made on a given day, lack of data exchange between stores, and the inability to deliver prepackaged meals at the present time. c. What type of computing environment does Natural Health Food Best Stores have?

Natural Best Health Food Stores currently has a client/server environment. The clients are responsible for capturing the sales data. Data are then transmitted to a central server, which is responsible for processing this data and updating the central database.

.

Chapter 2

The Sources of Software

1

Chapter 2

The Sources of Software Chapter Overview Systems Analysis and Development involves developing software, but also involves purchasing or in other ways obtaining various types of software to accomplish various SDLC activities. Chapter 2 discusses where software can be obtained, advantages and disadvantages of various sources, and how the systems analyst decides on a vendor and manages software procurement decisions.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter.

From an instructor’s point of view, the objectives of this chapter are to: 1. Identify and discuss information systems development options, including IT services firms, packaged software producers, enterprise-wide solutions, application service providers, open-source software, and in-house developers.

2. Define and understand outsourcing and its implications.

3. Discuss choosing off-the-shelf software.

4. Make comparisons between off-the-shelf solutions and in-house solutions and validate purchased software.

5. Understand how and why reusing software can be a useful option.

Classroom Ideas 1. This is a relatively short chapter. It may be easier to use the end of chapter elements for lectures. The review questions and problems and exercises provide targeted topics for discussion in terms of discussing the many sources of software.

2. Emphasize how many sources of software are available. Students should understand that being a systems analyst does not necessarily mean building code from scratch. Illustrate that, while a systems analyst might need a unique solution for their particular organization, there are many sources where the analyst can acquire already existing pieces that can be brought together to build their unique solution.

3. It can be useful to discuss the history of systems acquisition and show how changes in technology and availability have influenced where software can now be acquired.

.

Chapter 2

The Sources of Software

2

4. If possible, try to obtain off-the-shelf validation documents (RFP or RFQ) from an actual organization to illustrate what these documents contain.

5. In lecturing about this chapter, you might want to use the tables and figures in the chapter to point out to students the major issues at stake in sourcing software.

Lecture Notes Introduction Software is available from many sources. Some firms still do in-house programming, but many others acquire software from a variety of sources. This chapter discusses the various sources of software, from outsourcing to open source and off-the-shelf options.

This chapter illustrates how systems analysts can make decisions about choosing from the many sources, and also discusses reusing software from previous sources.

Systems Acquisition Considering how important information systems are to organizations, when did they begin to be used, and where did they come from? GE produced an in-house payroll option in 1954. Since then, in-house development has become a smaller component of many organizations’ systems development budgets as other sources of software have become available and more strategically advantageous than developing software inhouse.

Outsourcing Outsourcing is a practice where another organization develops or runs a computer application for your organization. Outsourcing can be very cost effective, and many organizations choose to outsource much, if not all, of their IT functions. This has resulted in a very large market for outsourcing—$930 billion in 2006. Considering the availability and cost-effectiveness of outsourcing, analysts should be aware of the option and carefully consider it as a potential alternative.

Sources of Software Methods of acquiring software can be grouped into 6 major categories—(1) information technology services firms, (2) packaged software providers, (3) vendors of enterprise solution software, (4) application service providers and managed service providers, (5) open-source software, and (6) in-house development. Each of these sources are presented in Figure 2–1 and Table 2–2 provides a comparison of the 6 sources of software.

Choosing Off-The-Shelf Software If an analyst chooses to purchase software, s/he should understand what criteria they should evaluate before making a decision, and how to compare the options available to them. The most common criteria for evaluating off-the-shelf software relative to in-house

.

Chapter 2

The Sources of Software

3

development are shown in Figure 2–2. Each of the criteria may be more important than the others depending on various aspects of the project.

Another important consideration when evaluating off-the-shelf options is validating the software information. This can be done by asking the vendor, but can also be carried out by issuing a Request for Proposal (RFP), where vendors can propose hardware and software that will meet the requirements of your new system. Other users of the software are also good sources for feedback and validation.

Reuse In addition to the sources of software already identified, some organizations may be able to Reuse software, or various components from already developed software. Reuse may apply to many pieces of previously developed software, but most often applies to object-oriented and component-based technologies. Reuse requires the organization to be able to leverage the cost of components across many users and projects. Figure 2– 3 shows a graph illustrating this concept. If an organization makes the decision to reuse, there are four approaches to reuse, which are presented in Table 2–3.

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

Outsourcing (3)

4.

Reuse (5)

2.

Enterprise resource planning (ERP) systems (2)

5.

Cloud Computing (1)

3.

Request for proposal (RFP) (4)

Review Questions Solutions 2-1. Describe and compare the six sources of software.

The six sources of software identified in the textbook are: (1) information technology services firms, (2) packaged software providers, (3) vendors of enterprise solution software, (4) application service providers and managed service providers, (5) open-source software, and (6) in-house development. 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. An IT services firm may be chosen if the system can’t be developed internally or requires customer support. Packaged software providers are companies that produce software exclusively, like Microsoft or Intuit, and are preferable if the task needing the system is generic. Vendors of enterprise solution software create a system that is composed of a series of integrated modules. Each module supports a business function, such as accounting, or human resources. ERP systems may be appropriate if a complete system is required that can cross functional boundaries. A more intense option for larger,

.

Chapter 2

The Sources of Software

4

more customizable solutions are Managed service providers who can provide more services than application service providers. ASPs and MSPs may be appropriate when instant access to an application is desired, and in the case of ASPs, when the task is generic. Open-source software is a type of software that is developed by a community of interested people and it is freely available. Opensource software is preferable when the task is generic and cost is an issue.

Finally, in-house development is still an option. In-house development refers to the organization developing software with its own IT assets, rather than purchasing software elsewhere. In-house development may be appropriate when a system must be built from scratch and as long as the personnel and resources are available to the organization.

2-2. How can you decide among various off-the-shelf software options? What criteria do you use?

To decide what off-the-shelf software to buy, compare products and vendors. Use the following criteria (among others that may be more situation-specific): cost, functionality, vendor support, viability of vendor, flexibility, documentation, response time, and ease of installation.

2-3. What is an RFP and how do analysts use one to gather information on hardware and system software?

An RFP is a formal document that provides detailed specifications about a target information system and asks vendors for information on how they would develop the system. Analysts use RFPs as a way to get vendors to perform the necessary research into specific design strategies and the hardware and system software vendors believe are necessary for developing the new system.

2-4. What methods can a systems analyst employ to verify vendor claims about a software package?

To verify vendor claims about a software package, an analyst can ask for a software demonstration, use the software (and its documentation and training materials), personally talk with other users of the software, ask specific questions via a questionnaire, and consult independent software testing and abstracting services.

2-5. What are ERP systems? What are the benefits and disadvantages of such systems as a design strategy?

ERP is a system that is composed of a series of integrated modules. Each module supports a business function, such as accounting, or human resources.

An advantage of ERP systems is that the modules are integrated across business functional areas, so that, for instance, all aspects of a single transaction can occur seamlessly within one information system, where it would have had to have been processed multiple times across several systems in a more traditional environment focused on functional areas. Other benefits include having a single repository of data for all aspects of a business process and the flexibility of the modules; other modules can be added as needed and are immediately integrated into the existing system. Disadvantages include complexity, lack of knowledge

.

Chapter 2

The Sources of Software

5

among organization’s personnel and reliance on consultants, and expense. In some cases, an organization may be required to change how it does business to more efficiently utilize ERP systems.

2-6. Explain reuse and its advantages and disadvantages.

Reuse refers to using previously written software resources, especially objects and components, in new applications. It can be more efficient to reuse objects or components, and research has shown that it can increase productivity, reduce defects, and reduce the amount of rework needed. Disadvantages include organizational lack of commitment, lack of proper training and rewards needed to promote reuse, and it is difficult to measure the economic gains from reuse.

2-7. Compare and contrast the four approaches to reuse.

“Ad Hoc” reuse refers to individuals finding ways to reuse objects and components on their own. Facilitated reuse refers to reuse that is encouraged by the organization, but with limited resources, infrastructure, and policies that would make reuse easier. Managed reuse refers to reuse that occurs because the organization enforces reuse through resources, infrastructure, policies, and people. Designed reuse refers to an organization carefully designing assets for reuse.

2-8. Why would a company rely on cloud computing for its software needs?

Cloud computing frees a company’s internal IT from developing application which results in a lower cost application as well as faster development time. In addition, since cloud computing in general is a pay as you go type service, applications can be quickly scaled up or down depending upon the needs of the company.

Problems and Exercises Solutions 2-9. Research how to prepare a request for proposal.

The request for proposal (RFP) is used when the organization wants to solicit proposals from several competing vendors. RFPs usually first give some background information on the company and the business units involved in the request, an explanation of the information system needs, a description of what is wanted from the vendors (i.e., what information they must provide or other actions they must take), and an explanation of any rules or procedures for the RFP and system development process. The bulk of the document then describes the mandatory, essential, and desirable requirements in the areas of need (e.g., functionality, hardware, software, and service).

2-10. 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-the-shelf software in the real world.

.

Chapter 2

The Sources of Software

6

For each new criterion, explain how its use might be functional (i.e., it is useful to use this criterion), dysfunctional, or both.

In addition to cost, functionality, vendor support, viability of vendor, flexibility, documentation, response time, and ease of installation, there are a number of other real world criteria that might be included. People often choose application packages, such as word processors and spreadsheets, based solely on their familiarity with the packages and/or their bias toward one hardware platform or operating system over another. To a certain extent this can be functional.

However, this could also be dysfunctional. For example, it would be useful to consider the current staff’s familiarity with the new application software and the resulting need for retraining. However, it would be dysfunctional if a company did not ever choose new software because of the employees’ lack of familiarity with it.

Eventually, software will evolve and the market will change, and the employees (and the company) will be left behind using antiquated technology.

Some other criteria include compatibility with currently used application software (so, for example, data can be shared), compatibility with existing hardware and system software, ability to support a range from novice to experienced (or power) users, and appeal of the user interface (ease of use).

2-11. In the section on choosing off-the-shelf software, eight criteria are proposed for evaluating alternative packages. Suppose the choice was 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.

The list for evaluating alternative custom software developers would be very similar to that for selecting off-the-shelf application software or for computer hardware and system software. In addition to cost, functionality, vendor support, viability of vendor, flexibility, documentation, response time, and ease of installation, we might include the current staff’s familiarity with the software, need for retraining, compatibility and connectivity with current systems, and the track record of the vendor in successfully implementing similar software in other organizations. Such vendors should have an established track record of developing similar software in other organizations. Their references should be checked thoroughly, including visits to these other sites. If the developer’s role will end after the application is accepted, then the reputation of the vendor for handling this transition from external development to internal maintenance is important. From a legal point of view, you may want to select a custom developer based on the willingness to sign a non-disclosure agreement, so that they are not allowed to develop a similar system for one of your competitors, at least for some amount of time.

2-12. How might the project team recommending an ERP strategy justify its recommendation as compared with other types of design strategies?

The project team would need to justify an ERP strategy by highlighting the strategic advantage to reengineering business processes to integrate with ERP modules. Doing so will provide a single repository for data, which can streamline all IT within the organization and ensure that data is consistent and accurate.

.

Chapter 2

The Sources of Software

7

Furthermore, if expansion is required in the future, additional modules are able to be integrated immediately. Finally, considering the regulatory climate, the ERP vendor (and consultants) will likely be better at ensuring the organization’s compliance with regulations, such as Sarbanes-Oxley, HIPAA, etc.

Petrie’s Electronics Case Questions Solutions 2-16.How do information systems projects get started in organizations?

The two primary ways in which information systems projects get started in organizations are, simply put, top-down or bottom-up. Top-down projects start with management, where managers determine that a new system is needed or an existing system needs to be updated or replaced. Bottom-up projects start with lower-level employees, who determine that systems they use are inadequate and either need to be replaced or updated.

2-17. How are organizational information systems related to company strategy?

How does strategy affect the information systems a company develops and uses?

A company’s strategy should drive what it does and the goals the company should pursue. A company’s strategy is implemented through many tactical decisions, each of which relies on tools and technologies to fulfill. Information systems are some of the tools and technologies companies use to fulfill decisions and hence implement strategy.

2-18. Research customer loyalty programs in retail firms. How common are they?

What are their primary features?

Customer loyalty programs are very common in retail firms. Most students probably belong to several such programs. The most primary feature involves awarding points for purchases, points which can later be redeemed for discounts or prizes.

Research into these programs will generate lists of other features, and students may also find numbers on how many such programs actually exist.

2-19. What do you think Jim’s next step would be? Why? This answer will differ with each student, but looking ahead in the systems development life cycle, the next step should involve some preliminary data gathering and analysis, especially in terms of feasibility analysis. Jim and his team need to determine if the proposed system makes sense for the company, from a variety of perspectives, before proceeding.

2-20. Why would a systems analyst new to a company be a good choice to lead an important systems development effort?

An analyst new to the company would not have any preconceptions about the system and how it might fit into the company’s strategy. Having a fresh perspective might allow for new insights and a new approach that could lead to a better and more creative system than would otherwise result.

.

Chapter 3

Managing the Information Systems Project

1

Chapter 3

Managing the Information Systems Project

Chapter Overview The purpose of this chapter is to introduce students to the process of managing an information systems project. Specifically, this chapter focuses on the systems analyst’s role in managing information systems projects through the four phases in the life of all projects: initiation, planning, execution, and close down. You (and your students) should think of this chapter as a valuable reference throughout the systems development course and use the material in this chapter to assist in guiding and evaluating ongoing project activities. You may want to emphasize that the skills and knowledge gained from this chapter are a critical foundation to the effective management of, not only information systems projects, but also, all types of projects and activities.

Chapter 3 introduces students to Pine Valley Furniture and Broadway Entertainment Company, Inc., the textbook’s two running cases. These two fictional companies are used in the chapters to illustrate key systems analysis and design concepts. When either of these companies is referenced in the textbook, an icon appears next to the material, making it easier for the reader to locate the references to the particular company. Pine Valley Furniture is a fictitious manufacturing company that manufactures high-quality wood furniture. Pine Valley Furniture provides a concrete example of a systems development project, reinforcing the analysis and design concepts presented throughout the textbook. Broadway Entertainment Company, Inc. is a fictitious international company involved in the video, music, and game rental and sales business.

The Broadway Entertainment Company, Inc. case demonstrates the concepts presented in the chapters and provides students the opportunity to apply their newly acquired knowledge to a realistic case.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Explain the process of managing an information systems project.

2. Describe the skills required to be an effective project manager.

3. List and describe the skills and activities of a project manager during project initiation, project planning, project execution, and project close down.

4. Explain what is meant by critical path scheduling and describe the process of creating Gantt charts and Network diagrams.

5. Explain how commercial project management software packages can be used to assist in representing and managing project schedules.

.

Chapter 3

Managing the Information Systems Project

2

Classroom Ideas 1. This chapter introduces many concepts and terms that are central to the management of information systems projects. It is important that your students become familiar with the key terms listed at the end of the chapter. To reinforce students’ understanding of these key terms, you can use the matching questions as an in-class assignment, quiz, or out-of-class assignment.

2. You may choose not to lecture from this chapter. Your students can read the chapter much as they might read a supplemental background reading (this is especially true if your students have already been exposed to project management concepts in another course). When reading the chapter this way, you may want to ask each student to apply the concepts of this chapter to a non-information systems activity, such as going on a date, vacation, etc. For this activity, ask students to describe initiation, planning, execution, and close-down activities. Ask them to create a work breakdown structure that includes precedence relationships and time durations for each activity. Additionally, ask them to construct Gantt charts and Network diagrams for these activities. You can have students do this as either an outside class activity or have them do this during your class time. In class, you can call on students to describe their project and phases. Alternatively, you could make this a written assignment to be graded or reviewed.

3. If you lecture from this chapter, you might want to use the tables and figures in the chapter to point out to the students the major project management activities.

4. An alternative to lecturing on the main part of this chapter is to lecture from the Review Questions, Problems and Exercises, and Discussion Questions at the end of the chapter. Selected questions can be posed to students to help focus a discussion on project management concepts and techniques.

5. You should make sure that the students have the ability to construct Gantt charts and Network diagrams. Working through the problems presented in the text or in Problems and Exercises 3-7, 3-8, 3-12, and 3-13 in class will be helpful to many students.

6. Another effective, in-class exercise for teaching this chapter is to ask students who have been on systems development teams to compare their experiences to the concepts presented in Chapter 3. This discussion can be a good way to elaborate on alternative ways for managing systems development projects, especially if systems were constructed using different methodologies. Use this discussion to explore if these student projects followed the discrete phases outlined in the chapter. Ask them to describe the activities of the project manager. What was the same? What was different?

7. If you have access to project management software, it is often engaging for students to see a demonstration of how a systems development project can be represented. Such a demonstration will not only teach students project management techniques, but it also gives them greater confidence to try project management software for themselves.

.

Chapter 3

Managing the Information Systems Project

3

8. If you have access to a practicing systems development project manager, a useful activity is to invite them to your class to discuss how they manage projects. Make sure that you ask this person about how to manage all four phases of a project (even if this is not the terminology he uses). Also, what tools are used? How do project members communicate?

9. If you can obtain a copy of the project management guidelines for a local systems development firm or consulting organization, show students how extensive project management guidelines typically are. If you have students working in systems development organizations, you might ask several of them to bring their firm’s guidelines to class. If possible, reproduce the table of contents of these manuals for all students and have them compare the various guidelines to see what each organization emphasizes.

Lecture Notes This chapter introduces students to the project manager’s role in the systems development process. The project manager is responsible for initiating, planning, executing, and closing down the project. Figure 3–1 illustrates these project management activities. Students are also introduced to techniques for reporting project plans, as well as project management software.

Pine Valley Furniture Company Background Pine Valley Furniture manufactures a variety of high-quality wood furniture items. Since its beginnings in the early 1980s, the company’s information systems have changed from manual-based information systems to application-oriented systems to a recently implemented database approach. Figure 3–2 illustrates the application-oriented approach that Pine Valley Furniture used. Pine Valley Furniture’s new centralized database was developed in-house.

Managing the Information Systems Project A project is a planned undertaking of related activities to reach an objective that has a beginning and an end. A project manager assures that a systems development project meets customer expectations and is delivered within budget and time constraints.

Additionally, he/she is responsible for initiating, planning, executing, and closing down a project. To successfully perform these tasks, a project manager must have a diverse skills set, including management, leadership, technical, conflict management, and customer relations skills.

Systems development projects are often undertaken for two primary reasons: to take advantage of business opportunities and to solve business problems. The Pine Valley Furniture’s Purchasing Fulfillment System is presented as an example of how a project is undertaken to solve a problem. Juanita Lopez works in the order department, and Chris Martin is a systems analyst. After contacting Chris about problems with the ordering process, Chris and Juanita produced a Systems Service Request. Figure 3–3

.

Chapter 3

Managing the Information Systems Project

4

shows this deliverable. Once Pine Valley Furniture’s Systems Priority Board approved the Systems Service Request, a feasibility study was conducted. Figure 3–4 outlines the steps followed during the project initiation stage of the Purchasing Fulfillment System project.

Once a project has been identified, the size, scope, resource requirements, and probability for successful completion are determined. To manage a project and bring it to a successful conclusion, the project manager juggles many activities; Figure 3–5 illustrates this juggling process. Table 3–1 lists the common activities and skills required of a project manager. As mentioned previously, the project manager is responsible for project management, which consists of four phases: (1) initiating the project; (2) planning the project; (3) executing the project; and (4) closing down the project.

Project initiation is the first phase of the project management process in which activities are performed to assess the size, scope, and complexity of the project and to establish procedures to support later project activities. Figure 3–6 lists the following project initiation activities: (1) establishing the project initiation team; (2) establishing a relationship with the customer; (3) establishing the project initiation plan; (4) establishing management procedures; (5) establishing the project management environment and project workbook; and (6) developing the project charter.

Establishing the project team organizes an initial core of project team members to carry out the project initiation activities. The second activity, establishing a relationship with the customer, encourages a strong working relationship between the analyst and the users. Often management will assign a specific IS individual to work as a liaison between the IS group and the business unit, thus fostering working relationships between the IS group and various business units. Establishing the project initiation plan identifies those activities required to organize the initiation team while it works to define the project’s scope. Activities include defining an individual’s role, establishing communication plans, identifying required deliverables and project steps, and establishing deadlines. When establishing management procedures, the project manager is concerned with how the team will communicate, establishing reporting procedures, job assignments and roles, project change procedures, and how to handle project funding and billing. Establishing the project management environment and project workbook involves collecting and organizing the tools that will be used while managing the project and starting a project workbook. The project workbook can exist in manual and/or electronic form. The project workbook is often made available via the Web. Figure 3–7 illustrates Pine Valley Furniture’s project workbook. A project charter is a short, high-level document prepared for both internal and external stakeholders to formally announce the establishment of the project and to briefly describe the objectives, key assumptions, and stakeholders. Figure 3–8 shows an example project charter for a proposed systems development project.

Project planning is the second phase of the project management process, which focuses on defining clear activities and the work needed to complete each activity within a single project. As Figure 3–9 suggests, plans in the short term can be more detailed and specific, while longer-term plans will often not be as detailed. As illustrated in Figure 3–10, the project planning phase involves ten activities: (1) describing project scope, alternatives, and feasibility; (2) dividing the project into manageable tasks; (3) estimating resources and creating a resource plan; (4) developing a preliminary schedule; (5) developing a communication plan; (6) determining project standards and

.

Chapter 3

Managing the Information Systems Project

5

procedures; (7) identifying and assessing risk; (8) creating a preliminary budget; (9) developing a project scope statement; and (10) setting a Baseline Project Plan.

During the first activity, the initiation team seeks to understand the content and complexity of the project. It is important that the team members define the scope, identify possible alternative solutions, and assess feasibility. When dividing the project into manageable tasks, the entire project is broken into smaller, more manageable tasks.

These tasks are then ordered. A work breakdown structure is a product of this activity. Figure 3–11 uses a Gantt chart to illustrate how activities can be broken down into summary tasks and specific tasks. During the estimating resources and creating a resource plan activity, resource requirements for each project activity are estimated.

Figure 3–12 shows an example of the COCOMO method of estimating project size and cost. This information is used to create a project resource plan. It is important to keep in mind that the individuals assigned to specific tasks influence the resource requirements. When making task assignments, the project manager can use specialized, generalized, or middle-ground approaches. Figure 3–13 shows the tradeoff between quality and time depending upon who is given a particular programming assignment.

When developing a preliminary schedule, the time and resource availability information is used to assign time estimates to each activity appearing in the work breakdown structure. Gantt charts and Network diagrams can represent a project’s schedule.

Figure 3–14 shows a Network diagram. The activity of developing a communication plan outlines the communication procedures among management, project team members, and customers. Figure 3–15 show a project communication matrix that provides a high level summary of the communication plan. Determining project standards and procedures specifies how various deliverables are produced and tested by the project team. It is important for the project manager to identify and assess sources of project risk. The identification of a project’s risk and its scope are related and often concurrently discussed. A preliminary budget will also be created; the preliminary budget outlines expected revenues and expenses. Figure 3–16 shows a sample costbenefit analysis for a systems development project. A Project Scope Statement is developed near the end of the project planning phase; the purpose of this document is to ensure that everyone has a clear understanding of the intended project size, duration, and outcomes. The final project planning activity involves setting a Baseline Project Plan; the Baseline Project Plan estimates the project’s task and resource requirements and guides project execution.

Project execution is the third phase of the project management process and is when the plans created in prior phases are put into action. Figure 3–17 lists the five project execution activities: (1) executing the Baseline Project Plan; (2) monitoring project progress against the Baseline Project Plan; (3) managing changes to the Baseline Project Plan; (4) maintaining the project workbook; and (5) communicating the project status. Executing the Baseline Project Plan involves initiating the execution of project activities, acquiring and assigning resources, orienting and training new team members, keeping the project on schedule, and assuring the quality of project deliverables. Figure 3–18 shows how complete and incomplete activities can be represented on a Gantt chart. While monitoring the project progress against the Baseline Project Plan, the project manager may need to adjust resources, activities, and budgets. Gantt and Network diagrams are beneficial tools for this activity. Managing changes to the Baseline Project Plan involves managing formal change requests and changes occurring

.

Chapter 3

Managing the Information Systems Project

6

outside the project manager’s control. When events occur that impact the project, the project manager must devise a way to get back on track or revise the Baseline Project Plan. During project execution, it is important that the project workbook is maintained and that the project’s status is communicated to all interested parties. Table 3–2 identifies several project team communication methods.

Project closedown brings the project to an end. A project can have a natural or unnatural termination. When a project terminates, several activities are performed including: (1) closing down the project; (2) conducting post-project reviews; and (3) closing the customer contract. Figure 3–19 summarizes the project closedown activities. When closing down the project, the project manager may assess each team member, provide career advice to team members, handle negative personnel issues, notify all interested parties that the project is completed, finalize documentation and financial records, and celebrate the accomplishments of the team. When conducting post-project reviews, the objective is to determine the strengths and weaknesses of project deliverables, the processes used to create them, and the project management process. Closing the customer contract ensures that all contractual terms have been met.

A project manager has a variety of graphical and textual documents available for documenting the project plans. Network diagrams and Gantt charts are two such tools.

Figure 3–20A illustrates a Gantt chart and a Network diagram. While Gantt charts show when a task should begin or end, Network diagrams show the sequencing of activities.

Project management software enables the project manager to easily alter the project plan. Network diagrams are a critical path scheduling technique used for controlling resources. Network diagrams are more often used than Gantt charts for information systems projects because Network diagrams can represent how completion times vary for various tasks. Figure 3–20B illustrates a Network diagram. PERT is a technique that uses optimistic, pessimistic, and realistic time to calculate the expected time for a particular task. A critical path is the shortest time in which a project can be completed.

Slack time is the amount of time that an activity can be delayed without delaying the project.

Pine Valley Furniture’s Sales Promotion Tracking System (SPTS) is an example of how to represent a project plan. Jim Woo, the project’s manager, followed four steps to represent the project plan. The steps are: (1) identify each activity to be completed in the project; (2) determine time estimates and calculate the expected completion time for each activity; (3) determine the sequence of the activities and precedence relationships among all activities by constructing a Gantt chart and network diagram; and (4) determine the critical path. Figures 3–21 through 3–28 reinforce these steps.

Using Project Management Software A wide variety of project management tools are available. These tools allow the project manager to define and order tasks, assign resources to tasks, and modify tasks and resources. Project management tools run on a variety of platforms and range in price.

Figures 3–29 through 3–32 can be used to discuss project management software.

.

Chapter 3

Managing the Information Systems Project

7

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

project workbook (17)

11.

project closedown (11)

2.

deliverable (4)

12.

Gantt chart (6)

3.

feasibility study (5)

13.

resources (18)

4.

project management (14)

14.

critical path scheduling (3)

5.

project execution (12)

15.

project manager (15)

6.

project initiation (13)

16.

project planning (16)

7.

Network diagram (7)

17.

critical path (2)

8.

project (9)

18.

PERT (8)

9.

slack time (19)

19.

Project charter (10)

10.

work breakdown structure (20)

20.

COCOMO (1)

Review Questions Solutions 3-1. Discuss the reasons why organizations undertake information system projects.

Information system projects are undertaken for two primary reasons: to take advantage of business opportunities and to solve business problems. Providing an innovative service to customers through the creation of a new system is an example of an opportunity. Modifying the way in which an existing system processes data so that more accurate or timely information is provided to users is an example of solving a business problem.

3-2. List and describe the common skills and activities of a project manager.

Which skill do you think is most important? Why? Table 3–1 highlights the common skills and activities of a project manager.

Although a case could be made for virtually all project management skills listed in the table, one skill—being an effective oral and written communicator—is likely the most fundamental skill for a project manager to master. Without effective communication skills, the ability to successfully complete activities is curtailed.

3-3. Describe the activities performed by the project manager during project initiation.

Project initiation has six major activities: (1) establishing the project initiation team; (2) establishing a relationship with the customer; (3) establishing a project initiation plan; (4) establishing management procedures; (5) establishing the project management environment and project workbook; and (6) developing the

.

Chapter 3

Managing the Information Systems Project

8

project charter. When establishing the project initiation team, the project manager organizes an initial core of project team members to assist in accomplishing the project initiation activities. Establishing a relationship with the customer builds a cooperative and trusting partnership with the customer. The project initiation plan defines the necessary activities required to organize the initiation team while they are working to define the scope of the project. Management procedures establish team communication and reporting procedures, job assignments and roles, project change procedures, and determine how project funding and billing will be handled. Establishing the project management environment and project workbook creates the repository for all project correspondence, inputs, outputs, deliverables, procedures, and standards of the project team. The project charter is a short, high-level document prepared for both internal and external stakeholders; this document ensures that the analyst and customer have a common understanding of the project.

3-4. Describe the activities performed by the project manager during project planning.

The activities performed by the project manager during project planning include: (1) describing project scope, alternatives, and feasibility; (2) dividing the project into manageable tasks; (3) estimating resources and creating a resource plan; (4) developing a preliminary schedule; (5) developing a communication plan; (6) determining project standards and procedures; (7) identifying and assessing risk; (8) creating a preliminary budget; (9) developing a Project Scope Statement; and (10) setting a Baseline Project Plan.

Describing project scope, alternatives, and feasibility develops an understanding of the content and complexity of the project by gaining answers to and agreement on the following types of questions: • What problem or opportunity does the project address?

• What are the quantifiable results to be achieved?

• What needs to be done?

• How will success be measured?

• How will we know when we are finished?

After defining the scope of the project, the next objective is to identify and document general solutions for the current business problem or opportunity and to assess each solution for feasibility so that a choice can be made as to which to consider during subsequent SDLC phases.

Dividing the project into manageable tasks identifies specific tasks and then logically orders them to ensure a smooth evolution between tasks.

.

Chapter 3

Managing the Information Systems Project

9

Estimating resources and creating a resource plan approximates resource requirements for each project activity and uses this information to create a project resource plan.

A preliminary schedule is developed using information regarding tasks and resource availability to assign time estimates to each activity in the work breakdown structure. This assignment will allow for the creation of target starting and ending dates for the project.

The communication plan outlines the communication procedures between management, project team members, and the customer.

Project standards and procedures specify how various deliverables are produced and tested.

The activity of identifying and assessing risk examines sources of project risk and estimates the consequences of those risks. Risks might arise from the use of new technology, resistance to change, availability of critical resources, competitive and regulatory actions, and team member inexperience with technology or the business area.

Creating a preliminary budget is the process of outlining the planned expenses and revenues associated with the project.

The focus of developing a Project Scope Statement is to create a document that outlines all work that will be done and makes clear what the project will deliver.

The purpose of setting a Baseline Project Plan is to develop an initial plan that reflects the best estimate of the project’s tasks and resource requirements and is used to guide the next project phase, execution.

3-5. Describe the activities performed by the project manager during project execution.

Project execution activities include: (1) executing the Baseline Project Plan; (2) monitoring project progress against the Baseline Project Plan; (3) managing changes to the Baseline Project Plan; (4) maintaining the project workbook; and (5) communicating the project status.

The execution of the Baseline Project Plan puts the Baseline Project Plan (e.g., the execution of project activities, acquire and assign resources, orient and train new team members, keep the project on schedule, and assure the quality of project deliverables) into action.

The purpose of monitoring project progress against the Baseline Project Plan is to compare the actual progress of the project to the Baseline Project Plan. If the project gets ahead of (or behind) schedule, adjustments to resources, activities, and budgets can be made.

.

Chapter 3

Managing the Information Systems Project

10

When managing changes to the Baseline Project Plan, alterations to the Baseline Project Plan are made as events (e.g., a slipped completion date of an activity) occur.

The project workbook is maintained through routine updating of project-related information documented within the workbook.

The project status is communicated to inform all interested parties—systems developers, managers, and customers—about how the project is progressing.

3-6. List various project team communication methods, and describe an example of the type of information that might be shared among team members using each method.

Table 3–2 summarizes project team communication methods. The table rates each method in terms of formality and use—for informing, for resolving issues, or for keeping permanent records. The following table lists these communication methods and provides an example of the type of information that might be shared among team members using each method.

Team Communication Methods and Corresponding Examples

3-7. Describe the activities performed by the project manager during project closedown.

The activities performed by the project manager during project closedown are: (1) closing down the project, (2) conducting postproject reviews, and (3) closing the customer contract. The focus of closing down the project is to conclude the project. The objective of conducting post-project reviews is to assess the strengths and weaknesses of project deliverables, the processes used to create them, and the project management process. The purpose of closing the customer contract is to ensure that all contractual terms of the project have been met.

.

Chapter 3

Managing the Information Systems Project

11

3-8. What characteristics must a project have in order for critical path scheduling to be applicable?

Critical path scheduling is a scheduling technique where the order and duration of the sequence of project activities directly affect the completion date of a project.

Applicable project characteristics include: (1) well-defined activities that have a clear beginning and end point; (2) activities that can be worked on independently of other activities; (3) activities that are ordered (or can be ordered); and (4) activities that when completed serve the purpose of the project.

3-9. Describe the steps involved in making a Gantt chart.

The steps involved in making a Gantt chart are: (1) identify each activity to be completed in the project; (2) determine time estimates and calculate the expected completion time for each activity; (3) determine the sequence of the activities and precedence relationships among all activities; and (4) construct the Gantt chart.

3-10. Describe the steps involved in making a Network diagram.

The steps involved in making a Network diagram are: (1) identify each activity to be completed in the project; (2) determine time estimates and calculate the expected completion time for each activity; (3) determine the sequence of the activities and precedence relationships among all activities; and (4) construct the Network diagram.

NOTE: The steps involved in making Gantt charts and Network diagrams are identical. However, they differ in the way the information is presented. A Gantt chart is presented with bars that represent the tasks, whereas a Network diagram is presented with a rectangle to represent the tasks, with task information included in the rectangle. See the answers below in numbers 3-20 and 3-21 in the Problems and Exercises Solutions.

3-11. In which phase of the systems development life cycle does project planning typically occur? In which phase does project management occur?

Project planning typically occurs during the planning and analysis phases of the SDLC. Project management occurs during all phases of the SDLC; yet, different project management activities occur during different SDLC phases.

3-12. What are some reasons why one activity may have to precede another activity before the second activity can begin? In other words, what causes precedence relationships between project activities?

Task sequence will depend on which tasks produce deliverables needed in other tasks, when critical resources are available, constraints placed on the project by the client, and the process outlined in the SDLC.

.

Chapter 3

Managing the Information Systems Project

12

Problems and Exercises Solutions 3-13. Which of the four phases of the project management process do you feel is most challenging? Why? Each of the four phases of project management has its unique challenges, therefore, students’ choices of which are most challenging should vary. Project initiation, the first phase, involves team building, building relationships with customers, defining the problem and project, and other challenging tasks. Some students may (appropriately) argue that this first phase is most important. If the first phase is conducted poorly, the project is likely to be doomed to failure.

Project planning, the second phase, is also important because it can make or break the success of the project work that follows. In addition, resource planning, scheduling, crafting a budget, and other planning tasks are difficult. Good planning is also a challenge because there is nearly always pressure to truncate or do away with planning altogether. Many students are likely to choose project execution, the third phase. This involves actually building the system, which is the primary responsibility and often is the longest phase of project management.

Closing down the project, the fourth phase, is not likely to be chosen by students as much as are other project phases. However, this phase is equally challenging.

The break up of the team is a difficult, often overlooked aspect of project management. In addition, there may be assignment changes for team members and there are likely to be performance appraisals of team member performance.

These are difficult and important personnel tasks that must be completed.

3-14. What are some sources of risk in a systems analysis and design project, and how does a project manager cope with risk during the stages of project management?

Sources of risk include difficulties in constructing the system (due to unfamiliarity with the business area or new technologies), necessary systems personnel leaving before the system is completed, competitor’s response to the successful implementation of the system, failures of vendors to supply promised technology, uncooperative users, and so on. It is important that a manager identify the potential sources of risks, describe the possible negative outcomes, determine the probabilities of occurrence, and prepare contingency plans for those significant outcomes with a high probability of occurrence.

.

Chapter 3

Managing the Information Systems Project

13

3-15. Search the web for recent reviews of project management software. Which packages seem to be most popular? What are the relative strengths and weaknesses of each packaged software? What advice would you give to someone intending to buy project management software for his or her PC? Why? There are several good project management software packages available for the personal computer. Microsoft Project for Windows and Primavera are two that are widely used. Information about project management software can be obtained from a variety of sources, including the World Wide Web, trade magazines, the library, marketing packets, and testing services. The World Wide Web is an excellent source of information. As part of your class activities or as a homework assignment, students can search the Web for relevant information about project management software. If time permits, ask students to investigate public domain and shareware products. How do these products compare with Microsoft Project?

The advice to give to prospective buyers of project management software is much like that of buyers of general software. For example, it is probably a good idea to advise someone to first determine what they need and why they need it, and then see what packages best meet their needs at an acceptable price. Obtaining the opinions of those who have used similar software is also advisable. Chapter 7 provides additional information on evaluating vendors and software.

3-16.Suppose that you have been contracted by a jewelry store to manage a project to create a new inventory tracking system. Describe your initial approach to the project. What should your first activity be? What information would you need? To whom might you need to speak?

Following the project initiation stage of the project management process, it would be important to establish the initiation team, establish contact with the customer, and work together to establish the initiation plan. Then management procedures should be established, and the tools used to manage the project (environment and project workbook) should be selected and initialized. Finally, a project charter should be created to outline the key deliverable(s) of the project and a high-level plan of how those deliverables will be produced.

3-17. Can a project have two critical paths? Why or Why not? Give a brief example to illustrate your point.

Yes. A critical path is, by definition, the shortest time in which a project can be completed. If a project has two sub-paths that take the same amount of time, then both are on a critical path. The example is illustrated below.

.

Chapter 3

Managing the Information Systems Project

14

Both sub-paths (through C & E, and through D & F) have identical total duration, and thus both satisfy the critical path criterion.

Activity A B C D E F G

Time (weeks ) 1 1 2 3 3 2 1

Immediate Predecess ors A B B C D E,F

This PERT Chart shows that there are 2 critical paths.

3-18. Calculate the expected time for the following tasks. (Note: The tasks and optimistic, most likely, and pessimistic times are provided in the textbook.)

A suggested answer is provided below.

Task

Expected Time

A

7

B

9

C

3

D

5

E

6

F

5

G

4

H

4

I

5

J

6.83

.

Chapter 3

Managing the Information Systems Project

3-19. A project has been defined to contain the following list of activities along with their required times for completion.

Time Immediate Activity (weeks Predecess No. Activity ) ors 1 Collect requirements 3 2 Analyze processes 2 1 3 Analyze data 2 2 4 Design processes 6 2 5 Design data 3 3 6 Design screens 2 3,4 7 Design reports 4 4,5 8 Program 5 6,7 9 Test and Document 7 7 10 Install 2 8,9 a. Draw a Network diagram for the activities.

b. Calculate the earliest expected completion time.

24 weeks. c. Show the critical path

d. What would happen if activity 6 were revised to take 6 weeks instead of 2 weeks?

The critical path would change to include activity 6 instead of activity 7, and the overall duration of the project would increase by 2 weeks.

.

15

Chapter 3

Managing the Information Systems Project

16

3-20. Construct a Gantt chart for the project defined in Problem and Exercise 319.

The following Gantt chart was created with Microsoft Project. The students may use project management software, a graphics package, or draw by hand to produce their chart. The Gantt chart for problem 3-20 is taken from Microsoft Project.

3-21. Look again at the activities outlined in Problem and Exercise 3-19. Assume that your team is in its first week of the project and has discovered that each of the activity duration estimates is wrong. Activity 2 will take only two weeks to complete. Activities 4 and 7 will each take three times longer than anticipated. All other activities will take twice as long to complete as previously estimated. In addition, a new activity, number 11, has been added. It will take 1 week to complete and its immediate predecessors are activities 10 and 9. Adjust the Network diagram and recalculate the earliest expected completion times.

The following Network diagram was created using Microsoft Visio The new time estimates have pushed the earliest expected completion time to 63 weeks. The activities boxes with a red bold border are on the critical path. These include collect requirements, analyze processes, design processes, design reports, test and document, install, and feedback.

.

Chapter 3

Managing the Information Systems Project

50 42

6 weeks

17

8 weeks

58

48 Activity 8

Activity 3

48

2 weeks

50 42

6

36

12

6

6

21 weeks

27

6

6

8

50

Activity 6 58 27

0

4 weeks

4

4

4

4

Activity 1

2 weeks Activity 2

21

0

0

58

Activity 4 0

15 weeks

42

42

42

42

Activity 7

12 weeks

16 weeks

0

62

58

27

27 15

62

Activity 10

27 0

4 weeks

29

0

Activity 9 0

58

62

1 week

63

27 Activity 11

Activity 5 62 6

9

18

Legend

Late Start Duration

Late Finish

Task Name Early Start

Slack

Early Finish

The following table provides the early finish, late finish, slack, and critical path information for each activity.

Activity

Time

Immediate Predecessors

Early Finish

Late Finish

Slack

Critical Path?

1

4

--

4

4

0

Yes

2

2

1

6

6

0

Yes

3

6

2

12

48

36

No

4

21

2

27

27

0

Yes

5

12

2

18

27

9

No

6

2

3, 4

29

50

21

No

7

15

4, 5

42

42

0

Yes

8

8

6, 7

50

58

8

No

9

16

7

58

58

0

Yes

10

4

8, 9

62

62

0

Yes

11

1

9,10

63

63

0

Yes

.

0

63

Chapter 3

Managing the Information Systems Project

18

3-22. Construct a Gantt chart and a Network diagram for a project you are or will be involved in. Choose a project of sufficient depth either at work, home, or school. Identify the activities to be completed, determine the sequence of the activities, and construct a diagram reflecting the starting, ending, duration, and precedence (Network diagram only) relationships among all activities. For your Network diagram, use the procedure in this chapter to determine time estimates for each activity and calculate the expected time for each activity. Now determine the critical path and the early and late starting and finishing times for each activity. Which activities have slack time?

Be sure that students choose projects of sufficient complexity to make it worthwhile to create their Gantt charts and Network diagrams. Encourage students to use project management software to create their charts and diagrams.

Have students compare their charts and diagrams and, if possible, compare the charts and diagrams created using different software projects. Have students discuss the comparative strengths and weaknesses of these packages.

Alternatively, compare charts and diagrams drawn using software with those drawn by hand. Have the students discuss the comparative advantages and disadvantages. Emphasize the typical power of any computer tool, which is the efficiency of making changes to the data as compared to manual methods.

3-23. For the project you described in Problem and Exercise 3-22, assume that the worst has happened. A key team member has dropped out of the project and has been assigned to another project in another part of the country. The remaining team members are having personality clashes. Key deliverables for the project are now due much earlier than expected. In addition, you have just determined that a key phase in the early life of the project will now take much longer than you had originally expected. To make matters worse, your boss absolutely will not accept that this project cannot be completed by this new deadline. What will you do to account for these project changes and problems? Begin by reconstructing your Gantt chart and Network diagram and determining a strategy for dealing with the specific changes and problems described above. If new resources are needed to meet the new deadline, outline the rationale that you will use to convince your boss that these additional resources are critical to the success of the project.

Some of the difficulties are easier to deal with than others. For example, to change the project plan to account for the delays, the students will simply adjust their Gantt charts and Network diagrams accordingly. Other difficulties, however, will be much more problematic. For example, dealing with the boss is potentially much more difficult. Frequent communication, accurate and full assessments of the situation, requests for reasonable means to deal with problems, and a history of being a good project manager are necessary to gain compliance from the boss.

There are basically four problems. The reassigned team member and the changes in due dates are beyond the control of the project manager. However, the personality clashes among team members and the mistaken estimate for the key phase are within the control of the project manager, or at least these two problems, if unsolved, may reflect poorly on the project manager. One prudent

.

Chapter 3

Managing the Information Systems Project

19

alternative would be to go to the boss and explain to him/her the situation. The project manager should also explain to the boss what he/she is doing to solve the two problems that are within his/her control. If the boss absolutely cannot accept the project past the original deadline, then additional resources will be needed to complete the project on time. If additional resources will solve the problem, and they are available, the project manager will have to provide a fairly strong, convincing rationale for why these new resources should be allocated to this project. The project manager might show, for example, that the project cannot be completed on time unless the boss doubles the programmers available for this project or takes some much needed experts off other projects and assigns them to this project.

3-24. Assume you have a project with seven activities labeled A–G (following).

Derive the earliest completion time (or early finish–EF), latest completion time (or late finish–LF), and slack for each of the following tasks (begin at time = 0). Which tasks are on the critical path? Draw a Gantt chart for these tasks. (Note: The tasks, preceding events, and the expected durations are provided in the textbook.)

A suggested answer is provided below.

Activity

Time

Immediate Predecessors

Early Finish

Late Finish

Slack

Critical Path?

A

5

--

5

5

0

Yes

B

3

A

8

12

4

No

C

4

A

9

9

0

Yes

D

6

C

15

15

0

Yes

E

4

B, C

13

16

3

No

F

1

D

16

16

0

Yes

G

5

D, E, F

21

21

0

Yes

Below is a suggested Gantt chart from Microsoft Project with the starting date set at March 2, 2011.

.

Chapter 3

Managing the Information Systems Project

20

3-25. Draw a Network diagram for the tasks shown in Problem and Exercise 3-24.

Highlight the critical path.

A suggested Network diagram, generated by Microsoft Project, for the tasks in Problem3-26s provided below. The activities in the boxes with a red border are on the critical path.

3-26. Assume you have a project with ten activities labeled A–J. Derive the earliest completion time (or early finish–EF), latest completion time (or late finish–LF), and slack for each of the following tasks (begin at time = 0).

Which tasks are on the critical path? Highlight the critical path on your Network diagram. (Note: The tasks, preceding events, and the expected durations are provided in the textbook.)

Suggested answers are provided below. The activities in the boxes with a red border are on the critical path.

0

4

4

26

Activity A 0

0

5

31

Activity B 4

4

11

22

9

6

17

17

Activity C 4

4

5

22

22

Activity F

7

10

17

7

11

18

Activity D

4

26

Activity I

0

22

4

22

22

0

26

Activity G 26

4

0

11

17

1

5

31

21 Activity J 26

11

6

17

23

17

17

Activity E 11

0

Duration

Early Finish

Task Name Late Start

Slack

26

Activity H

Legend Early Start

3

Late Finish

.

6

20

0

31

Chapter 3

Managing the Information Systems Project

21

Activity

Time

Immediate Predecessors

Early Finish

Late Finish

Slack

Critical Path?

A

4

--

4

4

0

Yes

B

5

A

9

31

22

No

C

6

A

10

17

7

No

D

7

A

11

11

0

Yes

E

6

A, D

17

17

0

Yes

F

5

C, E

22

22

0

Yes

G

4

D, E

21

22

1

No

H

3

E

20

26

6

No

I

4

F, G

26

26

0

Yes

J

5

H, I

31

31

0

Yes

3-27. Draw a Gantt chart for the tasks shown in Problem and Exercise 3-26.

A suggested Gantt chart, generated by Microsoft Project, is provided below. The starting date was set at March 2, 2011.

.

Chapter 3

Managing the Information Systems Project

22

3-28. Assume you have a project with 10 activities labeled A-J. Derive the earliest completion time (or early finish—EF), latest completion time (or late finish—LF), and slack for each of the following tasks (begin at time = 0). Which tasks are on the critical path? Draw both Gantt chart and Network diagram for these tasks, and make sure you highlight the critical path on your Network diagram.

Activity A B C D E F G H I J

Preceding Event — A A B,C C D E,F F,G G,H I

Expected Duration 3 1 2 5 3 2 3 5 5 2

Activity A B C D E F G H I J

Preceding Event — A A B,C C D E,F F,G G,H I

Expected Duration 3 1 2 5 1 2 3 5 5 2

EF

LF

Slack

Critical Path?

EF 3 4 5 10 6 12 15 20 25 27

LF 3 5 5 10 12 12 15 20 25 27

Slack 0 1 0 0 6 0 0 0 0 0

Critical Path?

Yes No Yes Yes No Yes Yes Yes Yes Yes

3-29. Make a list of the tasks that you performed when designing your schedule of classes for this term. Develop a table showing each task, its duration, preceding event(s), and expected duration. Develop a Network diagram for these tasks. Highlight the critical path on your Network diagram.

Student answers will vary. However, students will likely mention reviewing degree requirements, visiting with advisors, comparing schedules with friends (making sure they are in the same class), reviewing work schedules, and course schedules. Encourage students to use a project management software package to create their Network diagram. Ask them to discuss the advantages of using

.

Chapter 3

Managing the Information Systems Project

23

project management software over constructing the charts by hand.

3-30. Fully decompose a project you’ve done in another course (e.g., a semester project or term paper). Discuss the level of detail where you stopped decomposing and explain why.

Student answers will vary. Students should identify that the level of detail at which they stopped still fit with the characteristics of a task (see page 59 in the text).

3-31. Create a Work Breakdown Structure based on the decomposition you carried out for the previous question.

Student answers will vary.

3-32. Working in a small group, pick a project (it could be anything, such as planning a party, writing a group term paper, developing a database application, etc.) and then write the various tasks that need to be done to accomplish the project on Post-Its (one task per Post-It). Then, use the PostIts to create a work breakdown structure for the project. Was it complete?

Add missing tasks if necessary. Were some tasks at a lower level in the WBS than others? What was the most difficult part of doing this exercise?

Student answers will vary.

Discussion Questions Solutions 3-33. You interview for a job and the employer asks you if the project management process for systems development should be a structured, formal process. What will your answer be?

Following a formal project management process greatly increases the likelihood that a successful project will result. Scheduling resources, especially the human aspect, is a crucial component of project management. It is imperative that resources be scheduled and available when needed. Utilizing a formal project management process enables the project manager to identify which tasks need to be carried out, identify what resources are necessary, identify when these resources are necessary, monitor the project’s progress, and manage the project more carefully.

3-34 Do you agree that breaking projects down into small, manageable tasks is an important part of managing a project? What are the pros and cons of doing this?

Breaking a project into activities and related tasks makes the project easier to manage, enables team members to concurrently work on independent tasks, and ensures that all tasks are completed. Because a project is broken into smaller tasks, it is important that the tasks be coordinated and completed in a timely fashion.

.

Chapter 3

Managing the Information Systems Project

24

3-35. Microsoft Project is powerful but expensive. Assume you are in charge of researching and purchasing a project management application. Would you select Microsoft Project? Why or why not? If you were to select Microsoft Project, how would you justify its cost to your manager?

Answers will vary. Most should include concepts such as Microsoft Project’s ubiquity, its integration with other commonly-used Microsoft applications, etc. The cost of the software is justifiable because effectively managing projects is a crucial factor in project success, and having the ability to systematically manage and update the project’s plan and status is an important part of managing projects.

3-36. When completing a project some tasks are independent of others whereas others are interdependent on others. What does this mean in regard to slack? How are slack and the critical path related?

Slack time is the amount of time that an activity can be delayed without delaying the project. If an activity is delayed, the start times for its succeeding nodes are pushed back. If the succeeding nodes have slack time, then this slack time builds flexibility into when an activity can be started and still be completed on time.

However, if the succeeding node(s) do not have slack time, then you run the risk of delaying the entire project. Activities located on the critical path do not have slack time. Therefore, delaying an activity on the critical path will delay the project, unless the project manager can devise a way to get back on track.

Case Problems Solutions 3-37. Pine Valley Furniture Case Exercises Solutions a. While eating lunch one day, Juanita asked Chris about the benefits of becoming a project management professional. Briefly make a case for becoming a project management professional.

PMP certification is widely recognized and highly valued by employers and colleagues. It signifies the recipient’s knowledge and work in the area of project management. b. What are the project management professional eligibility criteria for Chris?

What documentation must he provide?

As published on the Project Management Institute’s Web site, Chris must hold a university degree, have a minimum of 4,500 hours of project management experience within designated areas, have three years of project management experience obtained within the past six years, and have 35 contact hours of project management education. Chris must provide documentation regarding his educational background, experience, and contact hours for his project management education. As a side note, a second qualification process is available for individuals not holding a degree. Information about this process is also available at the Project Management Institute’s Web site.

.

Chapter 3

Managing the Information Systems Project

25

c. Assume Chris has obtained his certification. What are PDUs, and how many must Chris acquire over a 3-year period?

The answer for this question can be found at the Project Management Institute’s Web site. Once certification is obtained, the Professional Development Program requires professionals to obtain a minimum of 60 PDUs over the course of three years. A PDU, or Professional Development Unit, is a measuring unit by which various educational and professional services are measured. d. Several activity categories are listed as qualifying for PDUs on the Project Management Institute’s Web site. Identify these categories. In which categories would you place Chris’s experience?

According to information published on the Project Management Institute’s Web site, five categories are identified. These categories include a formal academic education, self-directed learning and professional activities, PMI registered education provider, other providers, and volunteer service to professional or community organizations. Chris has taken several graduate-level courses. For the sake of argument, we can assume that at least one of these courses dealt with project management. Chris has also attended several seminars; attendance at these seminars would possibly qualify him in Category 3. Chris’s involvement with a charitable organization possibly fits in Category 5, thus earning him additional PDU points.

3-38. Hoosier Burger Case Exercises Solutions a. In an effort to learn more about project management, you decide to research this topic over the weekend. Locate an article(s) that discusses project management. Summarize your findings.

Many project management articles are available on the Web. If you have the class time, have your students discuss their articles in class. Students can also visit the Project Management Institute’s Web site to learn more about project management. The Web site is currently located at http://www.pmi.org/info/default.asp. b. At your meeting on Monday, Mr. Rodriquez asks you to prepare a Gantt chart for the Hoosier Burger project. Using the following information, prepare a Gantt chart.

Activity No.

Activity

Time (weeks)

Immediate Predecessors

1

Requirements collection

1

—

2

Requirements structuring

2

1

3

Alternative generation

1

2

4

Logical design

2

3

5

Physical design

3

4

6

Implementation

2

5

.

Chapter 3

Managing the Information Systems Project

26

A suggested Gantt chart is provided below; Microsoft Project was used to prepare this chart.

c. Using the information provided in part b, prepare a Network diagram.

A suggested Network diagram is provided below. All activities are on the critical path.

0

1

1

Requirements Collection 0

0

1

1

2

3

Requirements Structuring 1

0

3

3

1

4

4

Alternative Generation 3

0

2

6

6

6

6

Logical Design

4

4

0

3

9

9

Physical Design 0

9

2 Implementation

9

0

Legend Early Start

Duration

Early Finish

Task Name Late Start

d.

Slack

Late Finish

After reviewing the Gantt chart and Network diagram, Mr. Rodriquez feels that alternative generation should take only one-half week and that implementation may take 3 weeks. Modify your charts to reflect these changes.

The revised Gantt chart and Network diagram are provided below.

.

11

11

Chapter 3

0

1

Managing the Information Systems Project

1

Requirements Collection 0

0

1

1

2

3

Requirements Structuring 1

0

3

3

.5

3.5

3.5

Alternative Generation 3

0

2

5.5

27

5.5

Logical Design

3.5

3.5

0

3

8.5

8.5

Physical Design 5.5

5.5

0

3

11.5

Implementation

8.5

8.5

0

11.5

Legend Early Start

Duration

Early Finish

Task Name Late Start

Slack

Late Finish

3-39. Lilly Langley’s Baking Goods Company Case Exercises Solutions a. Lorraine Banderez, the project manager, has asked you to investigate how other companies have used project management software, particularly Microsoft Project. Investigate two companies and provide a brief summary of how each has used project management software.

Numerous case studies are available at http://www.microsoft.com/resources/casestudies/. b. Part of your responsibility is to assist in the preparation of the planning documents. Using the following information, prepare a Gantt chart.

Activity No.

Activity

Time (weeks)

Immediate Predecessors

1

Requirements collection

3

None

2

Requirements structuring

4

1

3

Process analysis

3

2

4

Data analysis

3

2

5

Logical design

5

3,4

6

Physical design

5

5

7

Implementation

6

6

A suggested Gantt chart is provided below. Microsoft Project was used to prepare this answer.

c.

Using the information from part b, prepare a Network diagram. Identify the critical path.

.

Chapter 3

Managing the Information Systems Project

28

A suggested Network diagram is provided below. Microsoft Visio was used to prepare this answer.

7

3

10

Data Analysis 7 0

3

3

3

Requirements Collection 0

0

4

0

10

7

10

Requirements Structuring

3

3

0

5

15

15

15

15

Logical Design

7

10 7

3

0

5

20

20

20

20

Physical Design 0

6 Implementation

10

Process Analysis 7

0

10

Legend

Late Start Duration

Late Finish

Task Name Early Start

Slack

Early Finish

d. After reviewing your planning documents, Lorraine decides to modify several of the activity times. Revise both your Gantt chart and Network diagram to reflect these modifications.

Time (weeks)

Activity Requirements collection

4

Requirements structuring

3

Process analysis

4

Data analysis

4.5

Logical design

5

Physical design

5.5

Implementation

7

A suggested Gantt chart is provided below. Microsoft Project was used to prepare this answer.

A suggested Network diagram is provided below. Microsoft Visio was used to prepare this answer.

.

26

0

26

Chapter 3

Managing the Information Systems Project

7.5

4

29

11.5

Data Analysis 7 0

4

4

4

Requirements Collection 0

0

3

0

11

7

11.5

Requirements Structuring

4

4

0

5

16.5

16.5

16.5

16.5

Logical Design

7

11.5 7

4.5

0

5.5

22

22

22

22

Physical Design 0

7

29

Implementation 0

29

11.5

Process Analysis 7

.5

11.5

Legend

Late Start Duration

Late Finish

Task Name Early Start

Slack

Early Finish

Petrie’s Electronics Case Question Solutions 3-40. What qualities might Jim possess that would make him a successful project manager?

To be an effective project manager, Jim will need to have time management, leadership, and conflict management skills. He will also need to have sufficient technical knowledge, and a good ability to interface with customers.

3-41. How do you think Jim should respond to Ella’s implied pressure about the importance of the project to her?

Answers will vary. Most should include attention to points such as proactive management of the project, consistent communication, honesty and transparency about the progress of the project and/or obstacle encountered, etc.

3-42. What strategies might Jim employ to deal with a very busy team member such as Juanita Lopez?

Answers will vary. Most should include attention to points such as getting a sure commitment from Juanita, clearly communicating your expectations to her, etc.

3-43. What should Jim do next to complete the project initiation?

Following the project initiation stage of the project management process in the chapter, it would be important to finish establishing the initiation team, establish full contact with the customer (operations), and work together to establish the initiation plan. Then management procedures should be established, and the tools used to manage the project (environment and project workbook) should be selected and initialized. Finally, a project charter should be created to outline the key deliverable(s) of the project and a high-level plan of how those deliverables will be produced.

.

Chapter 3

Managing the Information Systems Project

3-44. List five team communication methods that Jim might use throughout this project. What are some pros and cons of each?

Answers will vary. Answers should be drawn from Table 3-2 in the chapter.

.

30

Chapter 4

Systems Planning and Selection

1

Chapter 4

Systems Planning and Selection Chapter Overview This chapter introduces students to the first phase of the systems development life cycle and illustrates how organizations can benefit from following a formal process for identifying and selecting projects. Chapter 4 discusses how projects are identified and selected, initiated and planned, and assessed for feasibility. Systems planning and selection, the first phase of the systems development life cycle, consists of two primary activities: project identification and selection and project initiation and planning. During project identification and selection, potential projects are evaluated; these projects are classified and ranked; and then development projects are chosen.

The objective of the project planning activity is the development of a Baseline Project Plan (BPP) and a Statement of Work (SOW). The BPP becomes the foundation for the remainder of the development project. The SOW produced by the team clearly outlines the objectives and constraints of the project. As with the project initiation process, the size, scope, and complexity of a project will dictate the comprehensiveness of the project planning process and resulting documents. An important aspect of the project initiation and planning process centers on the assessment of a project’s feasibility and risk. This chapter describes several types of feasibility, including economic, technical, operational, schedule, legal and contractual, and political factors.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Illustrate the project identification and selection process.

2. Illustrate the steps in the project initiation and planning process.

3. Explain the need for and describe the contents of a Project Charter and Baseline Project Plan.

4. Provide a comprehensive overview of the various methods for assessing project feasibility.

5. Explain the differences between tangible and intangible benefits and costs and between one-time and recurring benefits and costs.

6. Illustrate how to perform cost-benefit analysis and describe what is meant by the time value of money, present value, discount rate, net present value, return on investment, and break-even analysis.

7. Describe how to evaluate the technical risks associated with a systems development project.

.

Chapter 4

Systems Planning and Selection

2

8. Explain the activities and participant roles within a structured walkthrough.

9. Prepare your students to develop a plan for conducting a term project involving several phases of systems development using the SDLC or other methodologies.

10. Describe the systems planning and selection process for an Internet electronic commerce application.

Classroom Ideas 1. An alternative to lecturing on the contents of the chapter is to lecture from the Review Questions, Problems and Exercises, and Discussion Questions from the end of the chapter. Selected questions can be posed to students to help focus a discussion on specific concepts. Problems and Exercises 4-13, 4-14, 4-15 and 4-16 can be done in class.

2. Another very effective in-class exercise is to ask students who have been on systems development teams to compare their experiences to the concepts presented in Chapter 4. This discussion is a good way to elaborate on alternative ways for identifying and selecting information systems projects. Some organizations are very informal, compared to what is described in the book. Usually you can start a good debate on how formal project identification and selection should be, and who should control this process. Stress the tradeoffs of formal versus informal processes: consistency, awareness, budget and investment controls, long-term focus, etc. versus rapid action, commitment, current business needs, etc.

3. If you have access to a practicing systems analyst, an insightful activity is to invite him into your class to discuss how he identifies and selects projects in his organization. Consistency with organizational procedures, history of performance of the IS unit, management style, competitiveness of industry, and many other factors can affect how an organization chooses to undertake these processes. Have your guest explain why the process is more bottom-up or top-down. Be sure that this person addresses the interaction between business plans, IS plans, and project selection.

4. A role-play is also an effective way for students to gain an understanding of the project identification and selection process. In such an exercise, have some students play different roles for selecting new system or hardware projects within your university, school, or department. Have some students play the role of the steering committee and have others suggest projects. Jointly agree to the mission, objectives, and strategy. Now, let the steering committee try to prioritize a list of projects. Keep asking them how each project serves the mission or which objectives satisfy the project.

5. This chapter introduces many different concepts and terms that are central to understanding the project initiation and planning process. Be sure that you ask your students to review the key terms listed at the end of the chapter.

.

Chapter 4

Systems Planning and Selection

3

6. During a lecture, you might want to use the tables and figures in this chapter.

Linking the processes described in this chapter to a specific example (e.g., the Pine Valley Furniture example in the chapter) is often a very good way for students to understand more abstract concepts. As part of a lecture, ask students to suggest costs and benefits that might arise with specific systems. Additionally, you can describe a systems development project with which you have been involved and ask the students to list the possible costs, benefits, and risks that would be part of a feasibility assessment of that system.

7. If you have access to a practicing systems analyst, an insightful activity is to invite him to your class to discuss how he initiates and plans projects in his organization.

Ask him to provide such documentation as: the Table of Contents for the equivalent of the Baseline Project Plan and Statement of Work, project schedules and work descriptions, feasibility tables or spreadsheets, and team organizations. Some organizations have formal documents called business cases that must accompany any project request; if possible, have your guest outline what his organization considers to be the ideal format for a business case.

8. An interesting class discussion is the viability of economic feasibility assessments.

How accurate and helpful are classical cost-benefit analyses of information systems? What measures of economic worth should be applied to systems projects? Should information systems be treated as investments, necessary costs, enablers of change, or otherwise? Remind your students that even when classical economic feasibility is assessed at this stage of a project, often only costs and benefits, not actual dollar values, can be fixed at this point. The incremental commitment and frequent review nature of systems projects means that the economic feasibility (as well as other feasibilities) can be reassessed at each project review point, with a decision to continue, redirect, or terminate the project.

Lecture Notes Chapter 4 introduces students to the first phase of the systems development life cycle and illustrates how organizations can benefit from following a formal process for identifying and selecting projects. Systems planning and selection, the first phase of the systems development life cycle, consists of two primary activities, project identification and selection and project initiation and planning. Figure 4–1 highlights these primary activities.

Identifying and Selecting Projects Systems planning and selection is the first SDLC phase and can be broken into two primary activities: (1) project identification and selection and (2) project initiation and planning. During the first phase, all possible systems development projects are identified and assessed by senior management, a business group, IS management, or a steering committee. The actual methods used to identify and select a project for development vary by organization; the selection process can be very formal or very informal. As illustrated in Figure 4–2, requests for information systems development come from three primary sources:

.

Chapter 4

Systems Planning and Selection

4

(1) managers and business units; (2) information systems managers; and (3) formal planning groups.

During the project identification and selection activity, three key tasks are performed; these are: (1) identifying potential development projects; (2) classifying and ranking IS development projects; and (3) selecting IS development projects.

First, projects can be identified by a key member of top management, a steering committee, user departments, or the development group. Each of these identification methods has its own strengths and weaknesses. Table 4–1 highlights the common characteristics of each selection method. Top management and steering committees are often thought of as top-down sources, since these selection methods choose projects that reflect the broader needs of the organization. In contrast, managers, business units, and the development group are considered to be bottom-up sources for projects, since these selection methods focus on a particular business need.

Second, since funds are often limited, organizations need a method of classifying and ranking potential development projects. The classification and ranking of potential projects can be performed by top management, a steering committee, business units, or the IS development group.

Third, the selection methods use a variety of criteria; these criteria are summarized in Table 4–2. When selecting IS development projects, many factors must be considered, including the perceived needs of the organization, the existing systems and ongoing projects, resource availability, evaluation criteria, current business conditions, and decision maker perspectives. These factors are highlighted in Figure 4–3. Although only those projects most likely to achieve business objectives are considered, the relative importance of these projects will change as business conditions change. The primary deliverable from the project identification and selection activity is a schedule of specific IS development projects; this schedule results from both top-down and bottomup initiatives. Figure 4–4 summarizes the project identification and selection activity.

The principle of incremental commitment should be applied to each development project.

Initiating and Planning Systems Development Projects Many of the initiation and planning activities overlap the analysis phase. However, spending an appropriate amount of time on these activities can reduce the amount of time required for later phases. The amount of time that is spent on this activity will vary based on the organization’s experience with building this type of system, the analysts’ experiences, the customers’ awareness of their needs, and/or the size and complexity of the project. A rule of thumb is that between 10 and 20 percent of the entire development effort should be spent on project initiation and planning. As Figure 4–5 illustrates, the purpose of project initiation and planning is to turn a vague systems request into a project description.

.

Chapter 4

Systems Planning and Selection

5

Project initiation and project planning are the two major activities of the project initiation and planning phase. As summarized in Table 4–3, project initiation consists of five activities. As summarized in Table 4–4, project planning consists of ten activities. A Baseline Project Plan and a Project Charter are the primary deliverables for the project planning activity. A project’s size, scope, and complexity influence the project planning process. During the project planning activity, a business case is made for the project; this business case highlights the economic benefits and costs, technical feasibility, and organizational feasibility for the new system. A Baseline Project Plan (BPP) contains an estimate of the project’s scope, benefits, costs, risks, and resource requirements; provides detailed project activities for the systems analysis phase; and is used by the project selection committee to determine whether the project should be continued, redirected, or cancelled. The BPP is an internal document and is not shared with customers. The BPP is updated as the project progresses through the systems development life cycle. A Project Charter is prepared for internal and external stakeholders and provides a high-level overview of the project.

Assessing Project Feasibility A project is often evaluated on its economic, operational, technical, schedule, legal and contractual, and political feasibility. The results of this analysis form the business case that justifies the resource expenditures on the project. The Pine Valley Furniture’s Customer Tracking System example illustrates the feasibility assessment process.

Figure 4–6 is the System Service Request (SSR) submitted to Pine Valley Furniture’s Systems Priority Board.

Economic feasibility, sometimes called cost-benefit analysis, identifies the financial benefits and costs associated with a development project. Several worksheets and techniques are presented in the chapter that can be used after each SDLC phase to help determine whether a project should continue, be redirected, or be cancelled. When assessing economic feasibility, the analyst identifies both tangible and intangible benefits. Tangible benefits can be measured in dollars and with certainty. In contrast, intangible benefits cannot be measured in dollars or with certainty. Initially, tangible benefits may need to be categorized as intangible benefits. In later stages, when more information is available, the intangible benefits can often be categorized as tangible benefits. Figure 4–7 is a worksheet summarizing tangible benefits. Both the tangible and intangible costs of an information system should also be identified. Systems development costs can also be categorized as one-time or recurring costs. As Figures 4–8 and 4–9 illustrate, worksheets are used to summarize these costs.

When preparing an economic feasibility analysis, the time value of money should be considered. The time value of money is a process of comparing present cash outlays to future expected returns. The discount rate is used to compute the present value of future cash flows, and the present value is the current value of a future cash flow. The formula for calculating the present value of a cash flow is: PVn=Y*[1/(1+i)n]. A summary worksheet can be created that summarizes a project’s economic analysis; Figure 4–10 shows Pine Valley Furniture’s summary worksheet; this worksheet reflects the present value calculations of all benefits and costs associated with the Customer Tracking System.

The summary worksheet also shows the break-even analysis and return on investment calculations. Figure 4–11 graphically illustrates the Customer Tracking System’s break-

.

Chapter 4

Systems Planning and Selection

6

even point. Table 4–5 describes three commonly used economic cost-benefit analysis techniques: net present value (NPV), return on investment (ROI), and break-even analysis (BEA). An economic analysis conducted during project initiation and planning may indicate that the project will not break even and/or have a high return on investment. However, not all benefits and costs have been quantified at this point in the project, and a long list of intangibles can help justify the continuation of the project.

Another option is to run pessimistic, realistic, and optimistic benefit and cost estimates; these views can help strengthen the business case.

When building the business case, other feasibility criteria should be examined. For instance, operational feasibility is an assessment of the degree to which a proposed system solves the business problems or takes advantage of the business opportunities outlined in the System Service Request or project identification study. Technical feasibility is the assessment of the organization’s ability to construct the proposed system. Schedule feasibility is an assessment of the degree to which the potential time frame and completion dates for all major activities within a project meet organizational deadlines and constraints for affecting change. Legal and contractual feasibility is an assessment of the potential legal and contractual ramifications due to the construction of a system. Political feasibility is an evaluation of how key stakeholders within the organization view the proposed system.

Information collected during project initiation and planning is organized into the Baseline Project Plan. A BPP contains four sections; introduction, system description, feasibility assessment, and management issues; an outline is shown in Figure 4–12. Figure 4–13 shows a project scope statement; Figure 4–14 shows a context-level data flow diagram. The management issues section of the BPP outlines concerns that management has about the project. Included in the management issues section are two matrixes that help project stakeholders understand who is responsible for what, and who the user can contact for specific information. Figure 4-15 shows the Task-Responsibility Matrix and Figure 4-16 shows the Project Communication Matrix.

Reviewing the Baseline Project Plan Once a Baseline Project Plan is prepared, management, users, and the development team will review the document. A walkthrough is a common method of review.

Individuals participating in a walkthrough assume one of several roles including; coordinator, presenter, user, secretary, standards bearer, or maintenance oracle. The walkthrough coordinator may prepare a Walkthrough Review Form, similar to Figure 4– 17. Figure 4–18 shows a Walkthrough Action List on which changes to a Baseline Project Plan are recommended. Walkthroughs are generally conducted with presentations. These types of presentations need to be conducted well and designing a high-quality presentation is relatively simple. Table 4-6 presents guidelines for making an effective presentation.

PVF WebStore: Systems Planning and Selection Internet-based electronic commerce is becoming a viable, attractive option for many businesses. While the systems planning and selection process for Internet-based electronic commerce applications does not differ from the process used for other

.

Chapter 4

Systems Planning and Selection

7

applications, it does warrant special consideration. Students should be aware of certain terminology, like the Internet, electronic commerce (EC), intranet, extranet, and electronic data interchange (EDI). Electronic commerce refers to Internet-based communication supporting day-to-day business activities. Figure 4-19 shows the three possible modes of electronic commerce. While an intranet is Internet-based communication supporting business activities within a single organization, an extranet is Internet-based communication supporting business-to-business activities. When developing intranets and extranets, the developers know who the users are, the applications being used, network connection speed, and the types of communication devices. In contrast, when developing Internet-based electronic commerce applications, several “unknowns” must be dealt with; these include the user, connection speed, and access method. Table 4–7 lists these unknowns.

At the end of this chapter, as well as at the end of the remaining chapters, you will find a section relating Internet development issues to the topics presented in the chapter. The authors use the Pine Valley Furniture WebStore to illustrate how an electronic commerce application is developed. In this chapter the authors overview the initiation and planning of Pine Valley Furniture’s e-commerce system and the WebStore project walkthrough. Table 4–8 summarizes the Web-based systems costs; Table 4–9 summarizes the WebStore project’s benefits and costs; Table 4–10 highlights feasibility concerns. Figure 4–20 is a Gantt chart showing the schedule for the WebStore.

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

political feasibility (13)

13.

technical feasibility (20)

2.

Project Scope Statement (15)

14.

one-time cost (11)

3.

business case (3)

15.

present value (14)

4.

economic feasibility (5)

16.

tangible benefit (19)

5.

incremental commitment (8)

17.

legal and contractual feasibility (10)

6.

recurring cost (16)

18..

intangible cost (9)

7.

discount rate (4)

19.

Baseline Project Plan (BPP) (1)

8.

intangible benefit (8)

20.

operational feasibility (12)

9..

schedule feasibility (17)

24.

break-even analysis (2)

12.

walkthrough (22)

Review Questions Solutions 4-1. Describe the project identification and selection process.

.

Chapter 4

Systems Planning and Selection

8

Organizations vary as to how they identify projects—some projects are identified by top-down initiatives while others are identified by bottom-up initiatives—and all methods of identification have been found to have strengths and weaknesses.

Research has found, for example, that projects identified by top management more often have a strategic organizational focus. Because limited resources preclude the development of all proposed systems, most organizations have some process of classifying and ranking the merit of each project. Those projects deemed to be inconsistent with overall organizational objectives, redundant in functionality to some existing system, or unnecessary are removed from consideration. Classifying and ranking projects, the second major activity, focuses on assessing the relative merit of potential projects. Different organizations may follow different processes for this activity. Project selection, the third activity, is a process of considering both short- and long-term projects and selecting those most likely to achieve business objectives. Additionally, as business conditions change over time, the importance of any single project may substantially change.

4-2. Describe several project evaluation criteria.

Table 4–2 describes several project evaluation criteria, including value chain analysis, strategic alignment, potential benefits, resource availability, project size/duration, and technical difficulty/risks.

4-3. List and describe the steps in the project initiation and planning process.

Project initiation focuses on activities designed to assist in organizing a team to conduct project planning. The types of activities performed during project initiation are listed in Table 4–3. Project planning is the process of defining clear, discrete activities and the work needed to complete each activity within a single project.

The objective of the project planning process is the development of a Baseline Project Plan (BPP) and a Statement of Work (SOW). The range of activities performed during project planning is shown in Table 4–4.

4-4. What is contained in a Baseline Project Plan? Are the content and format of all baseline plans the same? Why or why not?

The Baseline Project Plan (BPP) contains all information collected and analyzed during project initiation and planning. The plan reflects the best estimate of the project’s scope, benefits, costs, risks, and resource requirements given the current understanding of the project. The BPP specifies detailed project activities for the next life cycle phase, analysis, and less detail for subsequent project phases (these depend on the results of the analysis phase). The content and format of a BPP depends on the size, complexity, and standards of an organization.

4-5. Describe three commonly used methods for performing economic costbenefit analysis.

Three methods for performing economic cost–benefit analysis are net present value (NPV), return on investment (ROI), and break–even analysis (BEA) and are listed and described in Table 4–5.

.

Chapter 4

Systems Planning and Selection

9

4-6. List and discuss the different types of project feasibility factors. Is any factor most important? Why or why not?

The types of project feasibility factors are economic, technical, operational, schedule, legal and contractual, and political.

Economic feasibility is the process of identifying the financial benefits and costs associated with a development project.

Technical feasibility is the process of assessing the development organization’s ability to construct a proposed system.

Operational feasibility is the process of assessing the degree to which a proposed system solves business problems or takes advantage of business opportunities.

Schedule feasibility is the process of assessing the degree to which the potential time frame and completion dates for all major activities within a project meet organizational deadlines and constraints for affecting change.

Legal and contractual feasibility is the process of assessing potential legal and contractual ramifications due to the construction of a system.

Political feasibility is the process of evaluating how key stakeholders within the organization view the proposed system.

No factor is “most” important; one factor may be more important in some situations, while another may be “most” important in others.

4-7. What are the potential consequences of not assessing the technical risks associated with an information systems development project?

The potential consequences of not assessing and managing risks can include failure to attain expected benefits from the project, inaccurate project cost estimates, inaccurate project duration estimates, failure to achieve adequate system performance levels, and failure to adequately integrate the new system with existing hardware, software, or organizational procedures.

4-8. What are the types or categories of benefits from an IS project?

There are two primary categories of benefits from an IS project: tangible benefits and intangible benefits. Tangible benefits are those derived from the creation of an information system that can be measured in dollars and with certainty.

Intangible benefits are those derived from the creation of an information system that cannot be easily measured in dollars or with certainty.

.

Chapter 4

Systems Planning and Selection

10

4-9. What intangible benefits might an organization obtain from the development of an IS? Intangible benefits are derived from the creation of an information system and cannot be easily measured in dollars or with certainty. Potential intangible benefits include competitive necessity, more timely information, improved organizational planning, and increased organizational flexibility. Additional intangible benefits are identified in Table 4-9 on page 112 of the textbook.

4-10. Describe the concept of the time value of money. How does the discount rate affect the value of $1 today versus one year from today?

The time value of money (TVM) refers to the concept of comparing present cash outlays to future expected returns. A dollar today is worth more than a dollar one year from today because money can be invested. The rate at which money can be borrowed or invested is called the cost of capital and is called the discount rate for TVM calculations.

4-11. Describe the structured walkthrough process. What roles need to be performed during a walkthrough?

A structured walkthrough occurs when a peer group systematically reviews a product created during the systems development process. The objective of this review is to assure that the product conforms to organizational standards and that all relevant parties understand and agree with the information contained in the product (e.g., a Baseline Project Plan). Most walkthroughs are not rigidly formal or exceedingly long in duration. It is important, however, that a specific agenda be established for the walkthrough so that all attendees understand what is to be covered and the expected completion time.

At walkthrough meetings, there is a need to have individuals play specific roles. A coordinator plans the meeting and facilitates a smooth meeting process. This person may be the project leader or a lead analyst responsible for the current life cycle step. The presenter describes the work product to the group. The presenter is usually an analyst who has done all or some of the work being presented. A user (or group) assures that the work product meets the needs of the project’s customers. This user would usually be someone not on the project team. A secretary takes notes and records decisions or recommendations made by the group. This may be a clerk assigned to the project team, or it may be one of the analysts on the team. The standards bearer assures that the work product adheres to organizational technical standards. Many larger organizations have staff groups within the unit responsible for establishing standard procedures, methods, and documentation formats. These standards bearers validate the work so that it can be used by others in the development organization. A maintenance oracle reviews the work product in terms of future maintenance activities. The goal is to make the system and its documentation easy to maintain.

.

Chapter 4

Systems Planning and Selection

11

Problems and Exercises Solutions 4-12. The economic analysis carried out during project identification and selection is rather superficial. Why is this? Consequently, what factors do you think tend to be most important for a potential project to survive this first phase of the life cycle?

At this early stage the most important criteria is the extent to which the project under consideration supports the organization’s mission. At this point, economic concerns are secondary. Economic concerns will become more important during the next project phase, after a preliminary analysis of the project request shows the evidence for a business case.

4-13. Consider your use of a PC at either home or work and list tangible benefits from an information system. Based on this list, does your use of a PC seem to be beneficial? Why or why not?

Use of a PC at work can provide a number of tangible benefits. For one, it can help reduce labor costs. For example, documents can be prepared, edited, and copied faster with a PC and word processing software than without this equipment. The use of a word processor and a spreadsheet can help reduce errors in spelling and in calculation. If the right software is used, spreadsheet and graphics can be embedded within word processing documents, allowing greater flexibility in creating and integrating documents. File and network management software can allow greater control over work quality and workflow. Use of project management software can help improve resource control and project outcome quality. For example, spreadsheet analysis can help shorten and strengthen the decision-making process. Given these sample tangible benefits, the use of a PC seems to be beneficial.

4-14. Assume you are put in charge of launching a new website for a local nonprofit organization. What costs would you need to account for? Make a list of expected costs and benefits for the project. You don’t need to list values, just sources of expense. Consider both one-time and recurring costs.

One-time Costs: server purchase, internet service setup, initial website development, etc.

Recurring Costs: internet connectivity fees, hardware upgrades, website maintenance, etc.

Recurring Benefits: reduced administrative costs, etc.

.

Chapter 4

Systems Planning and Selection

4-15. Consider the situation you addressed in problem 3. Create numeric cost estimates for each of the costs you listed. Calculate the net present value and return on investment. Include a break-even analysis. Assume a 10 percent discount rate and a five year time horizon.

.

12

Chapter 4

Systems Planning and Selection

13

4-16. Consider the situation you addressed in problem 4. Create a sample project scope statement, following the structure shown in Figure 4-13.

Nonprofit Co Prepared by: John Smith Project Scope Statement Date: November 29, 2010 General Project Information Project Name: New Website Development Sponsor: Shane White, Product Manager Project Manager: Ryan Jacobs Problem/Opportunity Statement: The organization has grown enough that awareness needs to be generated on the web.

Our organization needs a professional and attractive website to draw attention, as well as to act as an information portal to our customers.

Project Objectives: Acquire necessary hardware and contract development for a professional website to represent our organization. A focus will be to obtain a quality, attractive website, but one that is reasonable for an organization of our size and age.

Project Description: A new server will be purchased and installed, along with necessary internet connectivity, to allow us to host our own website. The website itself will be developed by hired contractors. It will act as an information portal to our customers, providing an online presence and promoting our services and values.

Business Benefits Reduced phone and mail inquiries for our staff Increased presence via the Internet Project Deliverables Fully operational website Documentation regarding website maintenance Estimated Project Duration 6 months

.

Chapter 4

Systems Planning and Selection

14

4-17. Assuming monetary benefits of an information system at $85,000 per year, one-time costs of $75,000, recurring costs of $35,000 per year, a discount rate of 12 percent, and a 5-year time horizon, calculate the net present value of these costs and benefits of an information system. Also calculate the overall return on investment of the project and then present a break-even analysis. At what point does break-even occur?

The following spreadsheet summarizes the economic analysis requested in this question.

Problem and Exercise #4 Year of Project Year 0 Net Economic Benefit Discount Rate (.12)

0.12

PV of Benefits NPV of all Benefits One-Time Costs

Year 2

Year 3

Year 4

Year 5

$0

$85,000

$85,000

$85,000

$85,000

$85,000

1.0000

0.892857

0.797194

0.711780

0.635518

0.567427

$0

$75,893

$67,761

$60,501

$54,019

$48,231

$0

$75,893

$143,654

$204,156

$258,175

$306,406

($35,000)

Totals

$306,406

($75,000)

Recurring Costs Discount Rate (.12) PV of Recurring Costs

Year 1

0.12

NPV of all Costs

$0

($35,000)

($35,000)

($35,000)

($35,000)

1.0000

0.8929

0.7972

0.7118

0.6355

0.5674

$0

(31,252)

($27,902)

($24,912)

($22,243)

($19,860)

($75,000)

($106,252.00)

($134,154)

($159,066)

($181,309)

($201,169)

($201,169)

Overall NPV

$105,237

Overall ROI

0.52

Break-even Analysis Yearly NPV Cash Flow

($75,000)

$44,641

$39,860

$35,589

$31,776

$28,371

Overall NPV Cash Flow

($75,000)

($30,359)

$9,501

$45,090

$76,865

$105,237

Project Break-even occurs between years 1 and 2 Use first year of positive cash flow to calculate break-even fraction: .762 Actual Break-even occurs at: 1.76 years

4-18 Use the outline for the Baseline Project Plan provided in Figure 4-12 to present the system specifications for the information system you chose for Problems and Exercises 3 and 5.

Student answers for this question will vary. For class discussion purposes, assume the following generic system specifications. There will be nine 3GHz P4s, each with 512MB of RAM, 80GB hard drive, built-in network card, and a 17-inch flat panel monitor. There will be one 3.06GHz Intel processor, with 4GB of RAM, four 80GB hard drives, and a 21-inch flat panel monitor. Each PC will come with Windows XP.

.

Chapter 4

Systems Planning and Selection

15

4-19. Change the discount rate for Problem and Exercise 6 to 10 percent and redo the analysis.

The following spreadsheet summarizes the economic analysis requested in this question.

Problem and Exercise #7 Year of Project Year 0

Year 1

Year 2

Year 3

Year 4

Year 5

Net Economic Benefit

$0

$85,000

$85,000

$85,000

$85,000

$85,000

Discount Rate (.10)

1.0000

0.909091

0.826446

0.751315

0.683013

0.620921

$0

$77,273

$70,248

$63,862

$58,056

$52,778

$0

$77,273

$147,521

$211,382

$269,439

$322,217

($35,000)

PV of Benefits NPV of all Benefits One-Time Costs Recurring Costs Discount Rate (.10) PV of Recurring Costs NPV of all Costs

Totals

$322,217

($75,000) $0

($35,000)

($35,000)

($35,000)

($35,000)

1.0000

0.9091

0.8264

0.7513

0.6830

0.6209

$0

(31,252)

($28,926)

($26,296)

($23,905)

($21,732)

($75,000)

($106,252)

($135,178)

($161,474)

($185,379)

($207,111)

($207,111)

Overall NPV

$115,106

Overall ROI

0.56

Break-even Analysis Yearly NPV Cash Flow

($75,000)

$46,021

$41,322

$37,566

$34,151

$31,046

Overall NPV Cash Flow

($75,000)

($28,979)

$12,343

$49,909

$84,059

$115,106

Project Break-even occurs between years 1 and 2 Use first year of positive cash flow to calculate break-even fraction: .0701.

Actual Break-even occurs at 1.7 years.

.

Chapter 4

Systems Planning and Selection

16

4-20. Change the recurring costs in Problem and Exercise 6 to $40,000 and redo the analysis.

The following spreadsheet summarizes the economic analysis requested in this question.

Problem and Exercise #8 Year of Project Year 0

Year 1

Year 2

Year 3

Year 4

Year 5

Net Economic Benefit

$0

$85,000

$85,000

$85,000

$85,000

$85,000

Discount Rate (.12)

1.0000

0.892857

0.797194

0.711780

0.635518

0.567427

$0

$75,893

$67,761

$60,501

$54,019

$48,231

$0

$75,893

$143,654

$204,156

$258,175

$306,406

$40,000

PV of Benefits NPV of all Benefits One-Time Costs Recurring Costs Discount Rate (.12) PV of Recurring Costs NPV of all Costs

Totals

$306,406

$75,000 $0

$40,000

$40,000

$40,000

$40,000

1.0000

0.8929

0.7972

0.7118

0.6355

0.5674

$0

$35,714

$31,888

$28,471

$25,421

$22,697

$75,000

$110,714.29

$142,602

$171,073

$196,494

$219,191

$219,191

Overall NPV

$87,215

Overall ROI

0.40

Break-even Analysis Yearly NPV Cash Flow

($75,000)

$40,179

$35,874

$32,030

$28,598

$25,534

Overall NPV Cash Flow

($75,000)

($34,821)

$1,052

$33,082

$61,681

$87,215

Project Break-even occurs between years 1 and 2.

Use first year of positive cash flow to calculate break-even fraction .971.

Actual break-even occurs at 1.97 years.

.

Chapter 4

Systems Planning and Selection

17

4-21. Change the time horizon in Problem and Exercise 6 to three years and redo the analysis.

The following spreadsheet summarizes the economic analysis requested in this question.

Problem and Exercise #9 Year of Project Year 0

Year 1

Year 2

Year 3

Net Economic Benefit

$0

$85,000

$85,000

$85,000

Discount Rate (.12)

1.0000

0.892857

0.797194

0.711780

$0

$75,893

$67,761

$60,501

$0

$75,893

$143,654

$204,156

$35,000

PV of Benefits NPV of all Benefits One-Time Costs Recurring Costs Discount Rate (.12) PV of Recurring Costs NPV of all Costs

Totals

$204,156

$75,000 $0

$35,000

$35,000

1.0000

0.8929

0.7972

0.7118

$0

$31,250

$27,902

$24,912

$75,000

$106,250.00

$134,152

$159,064

$159,064

Overall NPV

$45,092

Overall ROI

0.28

Break-even Analysis Yearly NPV Cash Flow

($75,000)

$44,643

$39,860

$35,589

Overall NPV Cash Flow

($75,000)

($30,357)

$9,503

$45,092

Project Break-even occurs between years 1 and 2.

Use first year of positive cash flow to calculate break-even fraction: .762.

Actual Break-even occurs at 1.76 years.

.

Chapter 4

Systems Planning and Selection

18

4-22. Assume monetary benefits of an information system of $40,000 the first year and increasing benefits of $10,000 a year for the next four years (year 1 = $50,000, year 2 = $60,000, year 3 = $70,000, year 4 = $80,000, year 5 = $90,000). One-time development costs were $80,000 and recurring costs were $45,000 over the duration of the system’s life. The discount rate for the company was 11 percent. Using a five-year horizon, calculate the net present value of these costs and benefits. Also calculate the overall return on investment and then present a break-even analysis. At what point does break-even occur?

.

Chapter 4

Systems Planning and Selection

19

4-23. Change the discount rate for Problem and Exercise 11 to 12 percent and redo the analysis.

The following spreadsheet summarizes the economic analysis requested in this question. Since the overall NPV is negative, the ROI is not useful in this situation.

According to the following spreadsheet, this project does not break-even.

Problem and Exercise #11 Year of Project Year 0

Year 1

Year 2

Year 3

Year 4

Year 5

Net Economic Benefit

$0

$50,000

$55,000

$60,000

$65,000

$70,000

Discount Rate (.12)

1.0000

0.892857

0.797194

0.711780

0.635518

0.567427

$0

$44,643

$43,846

$42,707

$41,309

$39,720

$0

$44,643

$88,489

$131,195

$172,504

$212,224

$40,000

PV of Benefits NPV of all Benefits One-Time Costs Recurring Costs Discount Rate (.12) PV of Recurring Costs NPV of all Costs

Totals

$212,224

$90,000 $0

$40,000

$40,000

$40,000

$40,000

1.0000

0.8929

0.7972

0.7118

0.6355

0.5674

$0

35,714

$31,888

$28,471

$25,421

$22,697

$90,000

$125,714

$157,602

$186,073

$211,494

$234,191

$234,191

Overall NPV

($21,967)

Overall ROI

-0.09

Break-even Analysis Yearly NPV Cash Flow

($90,000)

$8,929

$11,958

$14,236

$15,888

$17,023

Overall NPV Cash Flow

($90,000)

($81,071)

($69,114)

($54,878)

($38,990)

($21,967)

Project Break-even will not occur during the life of this system.

.

Chapter 4

Systems Planning and Selection

20

4-24. Change the recurring costs in Problem and Exercise 11 to $40,000 and redo the analysis.

4-25. For the system you selected for Problems and Exercises 3, complete section 1.0.A, the project overview, of the Baseline Project Plan report. How important is it that this initial section of the Baseline Project Plan report is done well? What could go wrong if this section is incomplete or incorrect?

Students should submit an answer that is somewhat like the following: These group members need a way to share documents and peripheral devices such as laser printers. Their work requires them to collaborate and share documents, yet they have had no efficient way to do so. It was determined that it would be more efficient for them to use a network to share files than to continually share physical documents or exchange diskettes. In addition, using a network would enable them to buy and easily share one laser printer rather than having to buy several laser printers or share one laser printer that is not networked. The system is to include replacement PCs for each of the nine group members, plus one more expensive PC to serve as a repository for data and unique software applications. There are many other such LANs throughout the organization, each connected to the organization’s network. At this point there are no foreseeable constraints to implementing the system. This is one of the last offices to be given a LAN.

.

Chapter 4

Systems Planning and Selection

21

It is important that this initial section of the Baseline Project Plan be complete, accurate, and understood by all. Otherwise, there might be disagreements later about what this system will entail, and an inadequate or unwanted system might be implemented.

4-26. For the system you chose for Problems and Exercises 4-14, complete section 2.0.A, the alternatives, of the Baseline Project Plan report. Without conducting a full-blown feasibility analysis, what is your gut feeling as to the feasibility of this system?

For the system described above, alternative configurations use different LAN operating systems. In addition, students may choose not to replace the workgroup’s existing PCs, or they may choose to replace their PCs with another type of PC. For example, they may choose to upgrade all of the PCs with IBMcompatible PCs, or they may replace the PCs with another hardware platform.

Another configuration is to use a wireless LAN or even use an existing mainframe or departmental minicomputer as the server for the LAN. Other configurations involve choices on the implementation schedule, such as phasing-in the equipment. Alternatives might be based on different assumptions, such as the number of concurrent users, server space allotted for each user, the type of applications to be run on the network, or budget limitations. At first glance, this system seems to be highly feasible.

4-27. For the system you chose for Problems and Exercises 4-14, complete section 3.0.A–F, the feasibility analysis, of the Baseline Project Plan report.

How does this feasibility analysis compare with your gut feeling from the previous question? What might go wrong if you rely on your gut feeling in determining system feasibility?

This system seems to be feasible from an economic perspective. The initial costs are significant, but they are far outweighed by the tangible and intangible benefits that this system will provide. This system is relatively easy to implement, and the technology it uses is very stable, so the system is technically feasible. The skills required among personnel may be new, so there may be some risk of the technical staff having difficulties understanding multi-user operating systems. The system solves the business problem well and will not change day-to-day activities adversely. Thus, the system is operationally feasible. As long as software is used legally and is not copied illegally, the system should present no legal or contractual problems.

The group members within this office will be required to use technology that is new to them. If they are resistant to the change, this may present problems.

Given the relative simplicity of this system and the stability of the technology, the project seems feasible from a schedule, timeline, and resource perspective.

.

Chapter 4

Systems Planning and Selection

22

4-28. For the system you chose for Problems and Exercises 4-14, complete section 4.0.A–C, management issues, of the Baseline Project Plan report.

Why might people sometimes feel that these additional steps in the project plan are a waste of time? What could you say to convince them that these steps are important?

Assume there are four members on this team. The team consists of a team leader, who is a senior systems analyst, a junior analyst, the office supervisor, and an office worker. The two analysts will work primarily with the two office personnel team members. The other office personnel will communicate about the system through the two office personnel who are on the team. All involved have agreed that the system will have to meet the approval of the two office personnel assigned to the team. In addition, the office personnel are in the middle of a large, important project. Thus, the two analysts have agreed to meet about this project when it is convenient for the office personnel, and not to work in such a way that disrupts the other office personnel. The team leader is designated the official spokesperson for the project so that a consistent message is presented.

The team also agrees to follow the systems development guidelines established by the organization and to use hardware and software supported by the company, when possible.

People sometimes feel that these project management steps are a waste of time because they do not contribute directly to the completion of the project. However, setting these ground rules for who will work on the project and how they will work together is very important. Without this agreement there are likely to be conflicts later, which may adversely affect the success and timely completion of the project.

Such agreements manage everyone’s expectations and lead to greater satisfaction with the project.

Discussion Questions Solutions 4-29. Imagine that you are the chief information officer (CIO) of a company and are responsible for making all technology investment decisions. Would you ever agree to build an information system that had a negative net present value? If so, why? If not, why not? How would you justify your decision?

During project identification and planning, it may be difficult to determine all of a project’s benefits and costs. A project that has an initial negative net present value may have a positive one later. As the textbook mentions, a project may have many intangible benefits. Additionally, a project may have strategic benefits that necessitate its development.

4-30. Imagine that you are interviewing for a job when the interviewer asks you which cost-benefit analysis technique is best for assessing a project’s economic feasibility. What would your response be?

Each technique provides the manager with important information about the viability of the project. The NPV technique enables the manager to compare the present values of future benefits and cash outlays. The return on investment technique enables the manager to make comparisons between projects on an

.

Chapter 4

Systems Planning and Selection

23

economic basis, and break-even analysis gives the manager an indication about the length of time it will take the organization to recoup its initial investment.

4-31. Imagine you are a member of the project approval committee. An ambitious young manager in the marketing department is well-connected with the top management team in your company. He catches you in the hall and mentions that he is frustrated with how long it takes to get a simple system enhancement through the “bureaucratic” approval process. He wonders whether you could sign off on a small enhancement request for his team’s reporting application. With a wink, he promises to “owe you one.” What would you say to him and why?

Answers will vary. Most should include a discussion of the necessity of project planning and selection in the context of all the potential projects in an organization. Giving preferential treatment to one project will weaken any project approval process. All projects should be considered by the approval committee and subjected to the same review and approval process.

4-32. Of the six methods for assessing project feasibility, which is the most important? In which situation is each method more or less important?

The specifics of the project will determine which feasibility criterion is most important. Also, each method helps identify potential benefits and risks associated with the project.

Case Problem Solutions 4-33. Pine Valley Furniture Case Exercises Solutions a. How were Pine Valley Furniture’s projects initiated? What is the focus for each of the new systems?

Jackie Judson, PVF’s vice president of Marketing, submitted a System Service Request, requesting the development of a Customer Tracking System. The Customer Tracking System’s focus is primarily tactical. PVF’s board of directors initiated the WebStore project. The WebStore has more of a strategic focus. b. Modify the Customer Tracking System’s economic feasibility analysis to reflect the modifications mentioned in this case problem. Use a discount rate of 10 percent. After the changes are made, what are the new overall NPV, ROI, and BEP? A suggested answer is provided below.

.

Chapter 4

Systems Planning and Selection

24

PVF Customer Tracking System Part b Year of Project Year 0

Year 1

Year 2

Year 3

Year 4

Year 5

Net Economic Benefit

$0

$50,000

$50,000

$50,000

$50,000

$50,000

Discount Rate (10%)

1.0000

0.909091

0.826446

0.751315

0.683013

0.620921

PV of Benefits

$0

$45,455

$41,322

$37,566

$34,151

$31,046

NPV of all Benefits

$0

$45,455

$86,777

$124,343

$158,493

$189,539

$32,000

One-Time Costs

NPV of all Costs

$189,539

$47,500

Recurring Costs Discount Rate (10%) PV of Recurring Costs

Totals

$0

$32,000

$32,000

$32,000

$32,000

1.0000

0.9091

0.8264

0.7513

0.6830

0.6209

$0

$29,091

$26,446

$24,042

$21,856

$19,869

$47,500

$76,590.91

$103,037

$127,079

$148,936

$168,805

$168,805

Overall NPV

$20,734

Overall ROI

0.12

Break-even Analysis Yearly NPV Cash Flow

$47,500

$16,364

$14,876

$13,524

$12,294

$11,177

Overall NPV Cash Flow

($47,500)

($31,136)

($16,260)

($2,737)

$9,558

$20,734

Project Break-even occurs between years 1 and 2.

Use first year of positive cash flow to calculate break-even fraction: .223.

Actual Break-even occurs at 3.223 years.

c. Modify the worksheet created in part b using discount rates of 12 and 14 percent. What impact do these values have on the overall NPV, ROI, and BEP? Suggested answers are provided below.

.

Chapter 4

Systems Planning and Selection

25

PVF Customer Tracking System Part c 14 Percent Year of Project Year 0

Year 1

Year 2

Year 3

Year 4

Year 5

Net Economic Benefit

$0

$50,000

$50,000

$50,000

$50,000

$50,000

Discount Rate (14%)

1.0000

0.877193

0.769468

0.674972

0.592080

0.519369

PV of Benefits

$0

$43,860

$38,473

$33,749

$29,604

$25,968

NPV of all Benefits

$0

$43,860

$82,333

$116,082

$145,686

$171,654

$32,000

One-Time Costs Recurring Costs Discount Rate (14%) PV of Recurring Costs NPV of all Costs

Totals

$171,654

$47,500 $0

$32,000

$32,000

$32,000

$32,000

1.0000

0.8772

0.7695

0.6750

0.5921

0.5194

$0

$28,070

$24,623

$21,599

$18,947

$16,620

$47,500

$75,570.18

$100,193

$121,792

$140,739

$157,359

$157,359

Overall NPV

$14,295

Overall ROI

0.09

Break-even Analysis Yearly NPV Cash Flow

$47,500

$15,789

$13,850

$12,149

$10,657

$9,349

Overall NPV Cash Flow

($47,500)

($31,711)

($17,860)

($5,711)

$4,947

$14,295

Project Break-even occurs between years 1 and 2.

Use first year of positive cash flow to calculate break-even fraction: .536.

Actual Break-even occurs at 3.536.

d. Jim Woo would like to investigate how other online stores are targeting the business furniture market. Identify and evaluate two online stores that sell business furniture. Briefly summarize your findings.

Student answers for this question will vary. Using a search engine, such as Yahoo!, your students should locate many online business furniture stores. Two such stores are Staples (http://www.staples.com) and Officefurniture.com (http://www.officefurniture.com).

4-34. Hoosier Burger Case Exercises Solutions a. How was the Hoosier Burger project identified and selected? What focus will the new system have?

Bob and Thelma Mellankamp realized that Hoosier Burger’s inventory control, customer ordering, and management reporting systems required improvement.

As a result, Hoosier Burger hired Build a Better System to design a new system.

The new system’s primary focus is strategic in nature, although it will also have a cross-functional focus.

.

Chapter 4

Systems Planning and Selection

26

b. Identify the Hoosier Burger project’s scope.

As mentioned in the textbook, several alternatives exist for defining a system’s scope. Figure 4–13 can be used as a guide. A suggested answer is provided below. Also, you can ask your students to develop a context-level data-flow diagram, similar to Figure 4–14.

Hoosier Burger Statement of Project Scope General Project Information: Project Name: Sponsor: Project Manager:

Prepared by: Student Name Date: March 25, 2011

Hoosier Burger System Bob and Thelma Mellankamp Student Name

Problem/Opportunity Statement: Demand for Hoosier Burger food is at an all time high, resulting in problems for Hoosier Burger staff, creating stock-out problems, and impacting sales. An improved, integrated system is necessary to reach Hoosier Burger’s objectives.

Project Objectives: To enable Hoosier Burger’s staff to facilitate food preparation through better inventory management, improve customer service by reducing order-taking time, and improve daily management activities by increasing access to Hoosier Burger sales data. A secondary objective is to improve Hoosier Burger’s marketing activities.

Project Description: A new information system will be developed to support Hoosier Burger’s inventory management, order-taking, and food preparation activities. This new system will collect all ordering information; this information will then be used to monitor inventory usage and place orders for low in-stock inventory items. Additionally, the new system will facilitate customer order taking, thus reducing customer wait time. Data housed in the Hoosier Burger database will facilitate daily management activities and enhance marketing decisions.

Business Benefits: Improved management decision making Improved inventory management Improved customer service Improved sales Project Deliverables: Hoosier Burger analysis and design Hoosier Burger system programs Hoosier Burger new system documentation Training procedures Estimated Project Duration: 4 months

.

Chapter 4

Systems Planning and Selection

27

c. Using the six feasibility factors presented in the chapter, assess the Hoosier Burger project’s feasibility.

Hoosier Burger will realize many tangible and intangible benefits from the new system. From an economic standpoint, Hoosier Burger should realize cost reduction and avoidance, error reduction, increased flexibility, increased order taking, and improved management planning and control. While exact dollar figures were not presented in the case scenario, students should recognize that tangible benefits will occur.

The restaurant will also receive several intangible benefits. These include improved employee morale, easier access to information, and more timely information. In terms of tangible costs, Hoosier Burger will incur systems development costs, new hardware and software purchases, site renovations, data and system conversion, supplies, software and hardware maintenance, incremental data storage expense, and incremental communications costs.

In terms of operational feasibility, the new Hoosier Burger system should solve the restaurant’s current information flow problems and should provide business opportunities for the restaurant. This new system will not only improve the ordertaking process, but will also enable Bob and Thelma to use the order data to better manage Hoosier Burger’s operations.

Technical, scheduling, and legal and contractual feasibility are of minimal concern.

Bob and Thelma hired Build a Better System to design their system. Build a Better System is well-known in the community, has been in business for several years, and has a proven track record for developing systems for local and regional businesses. From Build a Better System’s perspective, this system is relatively small, is of limited complexity, and its development group has prior development experience with similar systems. While Bob and Thelma want the system implemented within a 4-month time frame, this date is somewhat flexible. In later chapters, reference is made to an existing POS system. One way to approach the legal and contractual issue is to assume that Build a Better System’s legal staff have evaluated the legal aspects associated with the project and do not foresee any legal ramifications. From a political standpoint, the key stakeholders, as well as Hoosier Burger’s employees, are very excited and accepting of the new system. d. Using Figure 4–13 as a guide, develop a Project Scope Statement for the Hoosier Burger project.

Student answers for this question will vary. However, you should encourage your students to use Figure 4–13 as a guide for developing Hoosier Burger’s Project Scope Statement.

.

Chapter 4

Systems Planning and Selection

28

4-35. American Labs Case Exercises Solutions a. Identify several benefits and costs associated with implementing this new system.

Inventory management will likely be more efficient, with fewer mistakes made and less administrative bookkeeping. Customer service will also be improved, with technicians able to provide more up-to-date information and more accurate turnaround estimates to customers when requested. The system will require initial one-time costs in hardware, development, and training costs. Maintenance and other recurring costs will also need to be accounted for. b. Using Figure 4-10 as a guide, prepare an economic feasibility analysis worksheet for American Labs. Using a discount rate of 10 percent, what are the overall NPV and ROI? When will break-even occur?

.

Chapter 4

Systems Planning and Selection

c. Modify the spreadsheet developed for question c to reflect discount rates of 11 and 14 percent. What impact will these new rates have on the economic analysis?

11 percent

.

29

Chapter 4

Systems Planning and Selection

14 percent

.

30

Chapter 4

Systems Planning and Selection

31

Petrie’s Electronics Case Question Solutions 4-36. Look over the scope statement (Figure 4-1). If you were an employee at Petrie’s Electronics, would you want to work on this project? Why or why not?

Answers will vary. Most should be willing to work on the project as a result of the clear scope statement in Figure 4-1.

4-37. If you were part of the management team at Petrie’s Electronics, would you approve the project outlined in the scope statement in Figure 4-1? What changes, if any, need to be made to the document?

Answers will vary. Project deliverables should probably be added to the scope statement.

4-38. Identify a preliminary set of tangible and intangible costs you think would occur for this project and the system it describes. What intangible benefits do you anticipate for the system?

Answers will vary. Tangible costs should include things like system development, new hardware costs, outsourcing fees, user training, system maintenance, etc.

Intangible costs might include things like possible inefficiencies due to the learning curve for new or current employees associated with the new system, etc. Intangible benefits should include things like increased customer goodwill, increased competitiveness with other similar stores in the market, etc.

4-39. What do you consider to be the risks of the project as you currently understand it? Is this a low-, medium-, or high-risk project? Justify your answer. Assuming you were part of Jim’s team, would you have any particular risks?

Answers will vary. Risks associated with the project include organizational risks (whether the organization can support such a system effectively), vendor risk (risk associated with outsourcing the development), financial risks (risk associated with investing a large sum of money in a large project like this), etc.

The project is likely a high-risk project, since it’s new, uncharted territory for the company. It’s a rather large financial investment, and Jim is a new, untested project manager in the company. Team members on Jim’s team run the risk of investing their time and resources into this project instead of others that they could be working on.

4-40. If you were assigned to help Jim with this project, how would you utilize the concept of incremental commitment in the design of the Baseline Project Plan?

The principle of incremental commitment refers to the continuous review strategy described on p. 108. After each stage in the SDLC, the project is reviewed for business need, as well as accuracy of cost, benefit, and risk estimations.

.

Chapter 4

Systems Planning and Selection

32

4-41. If you were assigned to Jim’s team for this project, when in the project schedule (in what phase or after which activities are completed) do you think you could develop an economic analysis of the proposed system? What economic feasibility factors do you think would be relevant?

An economic analysis can occur in the planning phase of the SDLC, after the scope and general feasibility have been established. With a relatively clear idea of initial costs, project duration, physical (hardware) costs, and a rough estimation of the probable benefits of the system, an initial economic feasibility analysis of the system can be produced.

4-42. If you were assigned to Jim’s team for this project, what activities would you conduct in order to prepare the details for the Baseline Project Plan?

Explain the purpose of each activity and show a timeline or schedule for these activities.

Details for the baseline project plan (BPP) can be prepared after project planning has occurred and clear, discrete tasks and work estimates for each task have been formulated.

4-43. In Case Question 4, you analyzed the risks associated with this project.

Once deployed, what are the potential operational risks of the proposed system? How do you factor operation risks into a systems development plan?

Operational risks associated with the project center around whether the system will actually perform the function it was meant to perform. The risk here is that the CRM system will be ineffective in increasing customer service and customer retention. Operation risks are factored in during operational feasibility analysis, and should be carefully considered prior to project approval.

.

Chapter 5

Determining System Requirements

1

Chapter 5 Determining System Requirements Chapter Overview This chapter acquaints students with how systems analysts collect information about information system requirements. The chapter begins with a discussion of the traditional requirements gathering techniques, such as interviews, observations, and obtaining information from organizational documents. The latter part of the chapter is devoted to more recently developed techniques and tools, such as Joint Application Design (JAD) and prototyping. This chapter concludes with discussions of business process reengineering and system requirements determination for an electronic commerce application.

From this chapter, students will learn about the different types of information requirements that analysts collect and the different methods they use to collect these requirements. However, reading and discussing how analysts collect requirements is no substitute for direct hands-on experience. Most of the classroom suggestions provided below involve some type of hands-on experience for students. You probably will not have time to try all of these ideas in class, but even one or two of these exercises will give students insight into the requirements collection process.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Provide insight into using interviewing to determine system requirements, including the preparation of an interview plan.

2. Discuss the system requirements determination process for Internet-based electronic commerce applications.

3. Discuss the advantages and pitfalls of observing workers to determine system requirements.

4. Demonstrate how the analysis of business documents provides system requirements information.

5. Illustrate how Joint Application Design promotes efficient and quick system requirements determination.

6. Show how prototyping can be used for requirements determination.

7. Show that BPR involves more than just tweaking or automating processes.

8. Illustrate how disruptive technologies enable the breaking of long-held business rules.

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

2

Classroom Ideas 1. Point out that, while requirements determination tools and techniques are very valuable in the analysis phase, analysts can benefit from their use in other phases of the life cycle. Demonstrate this with examples from other phases. For example, JAD is also useful in the early phases of design, such as where input forms and output formats are designed. Also, observation can be useful during system implementation to verify that the new system is being used as expected.

2. Use Figure 5–2 to show how to construct an interview plan. Construct a plan with students during class and have them generate similar plans for homework.

3. Take an activity with which students are familiar, such as enrollment. Have the students reengineer this activity. Encourage students to be innovative.

4. Figures 5–3, 5–4, and 5–5 can serve as the basis for a discussion of documents and how system requirements can be determined from them. Bring in other documents to add to the discussion or have students collect various documents they have, such as bills and order forms. Show how you can analyze such documents to discover business rules as well as content requirements. For example, a shipping form will show whether the firm recognizes ship to, order from, and bill to addresses; a class registration form may indicate the maximum length for student names. These same forms can also be used with Chapter 8, Designing the Human Interface.

5. Using a business case, run a mock JAD in class, with some students assigned roles as analysts, others as managers, and others as users. As with a real JAD, the person chosen as facilitator is crucial to the exercise’s success. The mock JAD should be preceded by the type of careful planning that precedes actual JADs, as outlined in the text.

6. Use a CASE tool to support the mock JAD outlined in Classroom Idea #5.

7. Conduct a prototyping session in class, using a 4GL, a prototyping tool, or a CASE tool with a prototyping component. If such software is available to your students, have them create prototypes based on system requirements found in a business case or in materials you provide.

Lecture Notes Chapter 5 is the first of four chapters devoted to the analysis phase of the systems development life cycle. As Figure 5–1 illustrates, the analysis phase includes requirements determination, requirements structuring, and alternative generation and selection activities. This chapter first discusses traditional methods for requirements collection, including interviews, observations, and document analysis. Because JAD and prototyping rely on computers for support, these methods are referred to as modern requirements determination approaches and are discussed towards the end of the chapter.

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

3

Performing Requirements Determination Although three primary activities are performed during analysis, these three activities are, to a degree, parallel and repetitive in nature. As part of the requirements determination process, information about the new system’s requirements is gathered from a variety of sources; these sources include system users, reports, forms, and procedures. Requirements determination requires an analyst to have several characteristics, which include impertinence, impartiality, relaxing constraints, attention to details, and reframing. The requirements determination process generates much information, taking the form of interview transcripts, observation notes, document analysis, forms, reports, job descriptions, and computer-generated output. Table 5–1 summarizes the deliverables for requirements determination. As part of requirements determination, the analyst should understand the business objectives; information people need to do their jobs; data handled in the organization; when, how, and by whom or what data are moved, transformed, and stored; the sequence and other dependencies among different data-handling activities; rules governing how data are handled and processed; business policies and guidelines; and key events affecting data values and when these events occur.

Traditional Methods for Determining Requirements The analyst gathers information from users who directly or indirectly use the system.

From these individuals, the analyst will collect information about the current system and the new system’s requirements. The analyst may use several of the traditional methods mentioned in Table 5–2. Analysts use interviews to gather information about how people conduct their work, how individuals use information, the types of information processing that might supplement the user’s work, the organizational direction, organizational policies, and managerial expectations. During the interview, the analyst can observe the interviewee’s behavior, and the analyst can use the interview process to gather facts, opinions, and speculation. Table 5–3 presents five interview guidelines. These guidelines include planning the interview, being neutral, listening and taking notes, reviewing interview notes, and seeking diverse views. Figure 5-2 presents a typical interview guide.

When preparing for the interview, the analyst must select the appropriate mix of openended and closed-ended questions. Open-ended questions are beneficial for probing, when the interviewer does not know the precise question to ask, and when the interviewer cannot anticipate the interviewee’s responses. Advantages of open-ended questions include putting the interviewee at ease, enabling previously unknown information to surface, and providing the interviewee with a sense of control during the interview process. Two primary disadvantages of open-ended questions are their length of time and the difficulty in summarizing a respondent’s answers. Closed-ended questions are beneficial when the major answers to the questions are known, do not require a large time commitment, and are an easy way to begin an interview. A major disadvantage of closed-ended questions is that an interviewee may try to “fit” his answer to the list of possible answers, as opposed to providing a more accurate response.

When interviewing, the analyst should phrase the question appropriately, listen carefully, type his/her notes within 48 hours, try not to set expectations for the new system, and seek a variety of perspectives.

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

4

Often the direct observation of users provides a more realistic picture of what they do.

However, if an end user is aware that he/she is being observed, they may alter their performance or work faster or slower than normal. The analyst only receives a snapshot image of the work in question, and he observes for a limited amount of time, a limited number of people, and a limited number of sites.

An analyst should examine existing system and organizational documentation. This type of documentation provides valuable information about the current system and the organization. Important documents to review include organizational mission statements, business plans, organization charts, business policy manuals, job descriptions, internal and external correspondence, and prior organizational study reports. Document analysis can provide information about existing problems, opportunities, organizational direction, the identity of key individuals, values of the organization or individuals, special information processing circumstances, why current systems are designed the way they are, and data and the rules for processing data.

The textbook discusses the importance of reviewing work procedures, business forms, reports, and existing system documentation. Figure 5–3 provides an example of a written work procedure for an invention disclosure. While work procedures are useful documents to review, these documents may reveal duplication of effort, missing procedures, out-of-date procedures, and contradictory information. Resolution of these problems is up to the manager, not the analyst. The analyst should understand both the formal and informal systems, since each provides valuable information about the current system and how to convert from the existing system to the new system.

Business forms indicate what data flow in and out of a system and are most useful when they contain data. Figure 5–4 is an example of a business form. Reports are useful, since they enable the analyst to work backwards and identify the data and processing requirements necessary to create them. Figure 5–5 is an example of a report. Existing system documentation provides information about how the current system was designed and how it works. Observations, interviews, and document analysis are common methods for collecting system requirements. Table 5–4 compares observations with document analysis.

Modern Methods for Determining System Requirements Joint Application Design and prototyping are two modern methods for requirements determination. JAD is an intense, structured, and highly effective process. JAD sessions enable analysts to simultaneously collect system requirements from the key users of the system. JAD sessions are generally conducted away from the workplace, are held in special-purpose rooms, may last several hours or an entire week, employ thousands of dollars, and generally do not benefit much from computer support. JAD participants include a JAD session leader, users, managers, a sponsor, systems analysts, a scribe, and IS staff. Figure 5–6 illustrates the typical layout for a JAD session. A JAD results in a description of the working system and the features of the replacement system.

Prototyping is an iterative process and replaces or augments the systems development life cycle. Building a prototype allows the user to view a model of his verbal description.

Revisions to this model can then be made. This process continues until an acceptable product is designed. Prototyping is useful for requirements determination when user

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

5

requirements are not clearly or well understood, one or a few stakeholders are involved with the system, possible designs are complex and require concrete form to evaluate fully, communication problems have existed in the past between users and analysts, and tools and data are readily available. Prototyping is not as beneficial when there is a tendency to avoid creating formal system documentation, prototypes are idiosyncratic to the initial user, and checks in the SDLC are bypassed.

Radical Methods for Determining System Requirements Business process reengineering (BPR) is the search for, and implementation of, radical change in business processes to achieve breakthrough improvements in products and services. Conducting BPR requires understanding which processes need to change; this requires understanding and identifying the organization’s key business processes. Key business processes focus on some type of organizational outcome and on the customer. Both traditional and modern requirements determination methods can be used to understand key business processes. Once the key business processes are identified, activities that are candidates for radical change are identified. To identify these activities, Michael Hammer and James Champy recommend asking three questions: (1) How important is the activity to delivering an outcome? (2) How feasible is changing the activity? (3) How dysfunctional is the activity? Information technologies can be used to radically improve business processes. Several of these disruptive technologies are described in Table 5–5.

PVF WebStore: Determining System Requirements When developing Internet-based electronic commerce applications, both traditional and modern requirements determination methods are used. The Pine Valley Furniture’s WebStore example illustrates how requirements are determined for an electronic commerce application. Tables 5–6– 5–9 reinforce this discussion.

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

business process reengineering (BPR) (1)

6.

key business processes (7)

2.

scribe (9)

7.

closed-ended questions (2)

3.

disruptive technologies (3)

8.

open-ended questions (8)

4.

informal system (5)

9.

JAD session leader (6)

5.

formal system (4)

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

6

Review Questions Solutions 5-1. Describe systems analysis and the major activities that occur during this phase of the systems development life cycle.

During systems analysis, you determine how the current information system functions and assess what users would like to see in a new system.

Requirements determination, requirements structuring, and alternative generation and selection are the three primary systems analysis activities.

5-2. What are some useful character traits for an analyst involved in requirements determination?

Requirements determination is a crucial part of the systems development life cycle; therefore impertinence, impartiality, relaxing constraints, attention to details, and reframing are important characteristics.

5-3. Describe three traditional techniques for collecting information during analysis. When might one be better than another?

Traditional techniques for collecting requirements include interviewing and listening, observing users, and analyzing procedures and other documents.

Interviewing and listening involve talking with users individually or as a group to discover their views about the current and target systems; it also involves carefully preparing an interview outline and guide before conducting the interview.

Interviews are best done when only a few people are involved, when you need open-ended questions or the questions vary from individual to individual, or when a more personal method is needed.

Directly observing users involves watching how people work in order to uncover information users may not be consciously aware of. Direct observation is best when detailed or complicated procedures must be documented, when you do not want people to know they are giving you information you need, when only a few people are involved, and when observational data are representative of all situations. Analyzing procedures and other documents involves identifying and collecting written procedures, forms, reports, and other relevant documents in order to better identify data and processes that would be part of the current and target systems. Analyzing documents is the best technique when documents are complete and unbiased, when other forms of requirements determination are too obtrusive, and when history must be studied and people do not have first-hand data about history.

5-4. What are the general guidelines for conducting interviews?

The general guidelines for conducting interviews are summarized in Table 5-3.

These guidelines include planning the interview, being neutral, listening and taking notes, reviewing these notes within 48 hours, and seeking diverse views.

5-5. What are the general guidelines for collecting data through observing workers?

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

7

When observing workers, it is important that the analyst select typical and atypical people and sites; he/she should also observe during normal and abnormal conditions.

5-6. What are the general guidelines for collecting data through analyzing documents?

Document analysis is an effective way to learn about the current system and future system’s requirements. It is important for the analyst to collect and review as many documents as he/she can. He/she should collect organizational mission statements, business plans, organization charts, business policy manuals, job descriptions, internal and external correspondence, and reports from prior organizational studies. Specifically, he/she should review business forms, reports, written work procedures, and existing system documentation.

5-7. Compare collecting information through observation and through document analysis. Describe a hypothetical situation in which each of these methods would be an effective way to collect information system requirements.

Table 5–4 provides a comparison of the observation and document analysis methods. The observation method is high in information richness; requires significant time, can be expensive, and provides the chance for follow-up and probing. The observee is known to the analyst and the potential audience is small. In contrast, the information richness of document analysis is low and old; the time required is low to moderate; its expense is low to moderate, and the chance for follow-up is limited. The confidentiality of the document depends on the nature of the document; there is no clear commitment on the subject’s part, and there is potentially bias by which documents were retained.

5-8. What is JAD? How is it better than traditional information-gathering techniques? What are its weaknesses?

JAD is a structured process in which users, managers, and analysts work together for several days in a series of intensive meetings to specify or review system requirements. It is better than traditional techniques because you have key personnel in one place at one time, saving everyone time and resulting in high levels of system ownership as more people have more of a role in the development process. Weaknesses include the level of commitment necessary to make the JAD work, the high degree of required planning, and the typical lack of computer support.

5-9. How has computing been used to support requirements determination?

Computing supports requirements determination in the form of CASE tools, the administration of questionnaires, group support systems, and prototyping. CASE tools, especially upper CASE tools, can be of assistance during JAD and prototyping.

5-10. Describe how prototyping can be used during requirements determination.

How is it better or worse than traditional methods?

Prototyping can be used during requirements determination to collect user requirements and present them in the form of a working system prototype. Users

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

8

can look at, play with, and compare the prototype to their system requirements.

Analysts can then adjust the prototype to better fit what the users have in mind.

Prototyping is better than traditional methods where system requirements are not well understood, where few users that are stakeholders are involved, where designs may be complex, where there have been past communication problems, and where the necessary tools are readily available. Prototyping may be worse than traditional methods where formal requirements are not documented, where prototypes become idiosyncratic to the initial user, where issues of data sharing and integration with other systems are ignored, and where SDLC checks are bypassed.

5-11. When conducting a business process reengineering study, what should you look for when trying to identify business processes to change? Why? As part of the BPR effort, key business processes and important, changeable, or dysfunctional activities are identified. Key business processes are the structured, measured set of activities designed to produce a specific output for a particular customer or market. Benefits of BPR include radical improvements in speed, quality, and customer satisfaction.

5-12. What are disruptive technologies and how do they enable organizations to change their business processes radically?

Disruptive technologies enable the breaking of long-held business rules that inhibit organizations from making radical business changes. Disruptive technologies enable companies to apply information technology innovatively. As a point of discussion, ask students to discuss the concept of a virtual university. Is this an acceptable application of a disruptive technology?

Problems and Exercises Solutions 5-13. One of the potential problems mentioned in the chapter with gathering information requirements by observing potential system users is that people may change their behavior when observed. What could you do to overcome this potential confounding factor in accurately determining information requirements?

The analyst could conduct the observations unobtrusively, so that the effect on the users’ behavior is minimized. This could be done using a confederate or by a hidden camera. The analyst could also brief the users on the observation so that the users will relax and behave naturally. For example, you can make it clear to users that they are not being evaluated and that the observations collected will not be associated with anyone individually. In addition, the analysts could perform multiple observations over time. This would tend to minimize the effects of aberrant behaviors. Alternatively, the analysts could supplement their requirements determination with additional data collection methods.

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

9

5-14. Summarize the problems with the reliability and usefulness of analyzing business documents as a method for gathering information requirements.

How could you cope with these problems to use business documents effectively as a source of insights on system requirements?

One of the primary problems with analyzing business documents is that they do not give the full picture of how work is done and why. First, business documents are often incomplete, since people have selectively retained documentation.

Second, business documents often describe the formal system as opposed to the informal system, which is more often the way the work is actually completed.

Whether the business documents are accurate or not, they provide useful information. If the business documents are accurate, then much of the work of gathering information requirements is nearly finished. If the business documents are inaccurate, then the analyst can use these to understand how the work processes ought to be done, or are thought to be done, or, perhaps, should not be done. In any event, analyzing business documents should be done in conjunction with other, supplemental data collection methods. In addition, the analyst should speak to multiple people to gather their perceptions and uses of the documents.

5-15. Suppose you were asked to lead a JAD session. List ten guidelines you would follow in playing the proper role of a JAD session leader.

Students might suggest the following for the JAD leader: conduct the JAD sessions off-site, invite the proper people to the JAD sessions, establish clear ground rules for the sessions, set and follow a clear agenda, distribute the agenda to all participants before the sessions, remain neutral on issues, make sure that everyone has the opportunity to participate, encourage people to be creative and break free of traditional ways of doing things, manage time effectively, and followup with meeting notes.

5-16. Prepare a plan, similar to Figure 5–2, for an interview with your academic adviser to determine which courses you should take to develop the skills you need to be hired as a programmer/analyst.

The plan might include introductions, background, discussion of the courses already taken, discussion of course requirements not yet met, discussion of additional courses to take for preparation, plotting course schedules for successive semesters, summary of major points, questions from the advisor, and closing. A meeting like this can last anywhere from 30 to 60 minutes, depending on the level of familiarity that the advisor has with the student’s case.

5-17. Figure 5–2 shows part of a guide for an interview. How might an interview guide differ when a group interview is to be conducted?

Because the group interview might be more difficult to conduct and more time consuming, the analyst might add to the interview guide “time certain” events or “time stamped” agenda items. For example, if the meeting begins at 8:00 a.m., and the manager of the users will come in to the meeting to give a brief talk, this event might be scheduled for 8:15 a.m. until 8:30 a.m. Other processes in the meeting will be postponed during this event. With time stamping, the analyst writes definitive start times next to each of the agenda items and then uses this to keep the group on track. Alternatively, the analyst might write specific questions that should be asked of specific members of the interview group. If several

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

10

analysts are involved in the group interview, the group could be broken into parallel sessions, each with its own agenda. Finally, agenda activities should be allotted for discussion and interchange between the interviewees, so that consensus and synergy can occur.

5-18. JADs are very powerful ways to collect system requirements, but special problems arise during group requirements collection sessions. Summarize these special interviewing and group problems, and suggest ways that you, as a group facilitator, might deal with them.

Some of the problems include difficulty in scheduling, enabling all group members to participate during the meeting, some people being afraid or not willing to speak in front of certain other people, conflicts existing among group members, keeping the group on track during the meeting, and accurately collecting all the information as multiple people speak at once. Some of the ways to deal with these problems include training in team building, group dynamics, and managing conflict; having multiple interviewers work together; and using a technological aid such as CASE or GSS. 5-19. Suppose you are a systems analyst charged with gathering information requirements. You decide that you want to use prototyping to gather these requirements. It provides benefits beyond interviews and observations, but also presents unique challenges. Discuss the challenges you expect to face and what processes you will put in place to prevent them from harming your information system.

This question has several possible answers.

Some challenges that can be expected are: 1. Analysts may feel that properly documenting the requirements is redundant.

This could be addressed by requiring careful notes to be taken when soliciting feedback from users or by not allowing any changes to the prototype without justification in the requirements.

2. Initial users that participate in the prototyping process may have heavier influence on the resulting system. This could be mitigated by rotating the early prototype responses among various users to ensure a more comprehensive set of perspectives.

3. The prototype is non-functional and does not interoperate with other data sources. The system may perform differently when more data is involved or different data sources are accessed. Effort should be made to load the system with enough data to allow the users to see a more realistic view of the system.

5-20. Questionnaires can be administered both on paper and via the Internet.

Online questionnaires allow for the use of complex analysis tools and realtime results. However, online questionnaires have idiosyncratic challenges.

Three such challenges can be computer access concerns, getting users to participate, and employee concerns for privacy of results. Discuss when each concern is likely to impact the online questionnaire and how you would address each challenge.

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

11

This question asks students to discuss solutions to three problems with Internetbased questionnaires. These concerns and possible solutions are: 1. Computer access concerns – not all workers will have roles that provide access to computers, such as factory line workers and nurses in hospitals. However, their input can be critical to the successful creation of an information system to meet their needs. For questionnaires administered online, workers should be given some way to provide their input while at work. Either providing access to a computer or providing a paper-based form may address this issue.

2. User participation – getting workers to participate can be more difficult with online questionnaires because it requires taking time on a computer to complete, whereas paper-based questionnaires can be filled out on-the-spot. This can be addressed by providing time set aside just for the questionnaire, sending followup reminders to complete the questionnaire, or by providing incentives for the completion of the questionnaire.

3. Privacy concerns – employees may be concerned that their responses will not be kept confidential. This may be more of an issue when the employee has opinions which are different than those of their superiors (formal or informal). Employees should be reassured that the responses will not be linked to the individual respondents. An easy way to enhance privacy is to not collect any personal information and to have a single link to the instrument that all respondents will type in.

Discussion Questions Solutions 5-21. The methods of data collection discussed in this chapter take a lot of time.

What are some ways analysts can still collect the information they need for systems analysis but also save time? What methods can you think of that would improve upon both traditional and newer techniques?

Although requirement determination methods take time, it is important to stress that this is time well spent. Spending the necessary time to understand the current system and correctly identify a new system’s requirements will save much time down the road. Perhaps the best way that an analyst can save time is by being prepared, organized, and knowledgeable.

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

12

5-22. Some of the key problems with information systems that show up later in the systems development life cycle can be traced back to inadequate work during requirements determination. How might this be avoided?

It is imperative that the analyst gathers as much information about the current and new system’s requirements as she can. During requirements determination, impertinence, impartiality, relaxing constraints, attention to details, and reframing are good characteristics for an analyst to exhibit. These characteristics will help the analyst better understand the existing system and the new system’s requirements. Additionally following the effective guidelines for conducting interviews, performing observations, and analyzing documents are important. It is important that the analyst not hurry through this step; he/she must take his/her time and gather all the necessary information.

5-23. Survey the literature on JAD in the academic and popular press and determine the “state of the art.” How is JAD being used to help determine system requirements? Is using JAD for this process beneficial? Why or why not? Present your analysis to the IS manager at your work or at your university. Does your analysis of JAD fit with his or her perception? Why or why not? Is he or she currently using JAD, or a JAD-like method for determining system requirements? Why or why not?

Information about JAD is readily available. The textbook provides several JAD references, and your students may also find articles in IS journals, IS magazines, and on the Web. Your students may also find information about JAD in the proceedings for the annual International Conference on Information Systems and the Hawaii International Conference on Systems Sciences.

5-24. Is business process reengineering a business fad or is there more to it?

Explain and justify your answer.

Business process reengineering enables companies to radically redesign existing processes, achieving breakthrough gains in performance. Usage of disruptive technologies is key to this process. As long as companies, like Ford Motor Company, are receiving tremendous payoffs by using this process, we will continue to see it used for the redesign of key business processes. As a point of discussion, encourage your students to locate case studies of companies that have reengineered their key business processes.

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

13

Case Problems Solutions 5-25. Pine Valley Case Exercises Solutions a. Because Pete Polovich is organizing a JAD session for the first time, he would like to locate additional information about organizing and conducting a JAD session. Visit one of the Web sites recommended in the textbook or locate a site on your own. After visiting this site, provide Pete with several recommendations for conducting and organizing a JAD session.

Your students should easily locate Web sites that provide information on JAD. Several sources include Bluebird Enterprises, Inc. (http://www.bee.net/bluebird/jaddoc.htm), Hathaway and Associates, Inc. (http://www.thehathaway.com/JSA.html), Creative Data, Inc. (http://www.credata.com/research/methodology.html), and Carolla Development, Inc. (http://www.carolla.com/wp-jad.htm). The Carolla white paper discusses general JAD principles, identifies several JAD tasks, and provides additional references. b. When conducting your interviews, what guidelines should you follow?

Table 5–3 lists the interviewing guidelines. These guidelines include planning the interview, being neutral, seeking diverse views, listening and taking notes, and reviewing these notes. c. As part of the requirements determination process, what business documents should be reviewed?

The analyst should try to obtain access to a variety of business documents.

Types of documents include Pine Valley’s mission statement, business plans, an organization chart, business policy manuals, job descriptions, and internal and external correspondence. Because the Customer Tracking System is a new system, reports from a prior organizational study may not be available. d. Is prototyping an appropriate requirements determination method for this project?

Prototyping is an appropriate requirements determination method. When designing the new system’s forms and reports, prototyping will be of definite benefit.

5-26. Hoosier Burger Case Exercises Solutions a. Assume you are preparing the customer satisfaction questionnaire. What types of questions would you include? Prepare five questions that you would ask.

Students will identify a variety of questions to ask. Questions will address visit frequency, food quality, the order-taking process, delivery speed, potential new services, and overall customer satisfaction. Because the questionnaire will be distributed to a large customer base, most of the questions on the questionnaire should be closed-ended, although the questionnaire should enable the customer

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

14

to provide additional comments. Since Hoosier Burger attracts a wide range of customers (student, business, and family), a stratified sample is a possibility. b. What types of questions would you ask the waiters? What types of questions would you ask the cooks? Prepare five questions that you would ask each group.

Although the waiters could be interviewed individually, this situation may lend itself to a group interview. Asking open-ended questions in a group interview setting would enable the analyst to explore and discover new system requirements. The downside to this approach is the length of time the interview session could take.

The types of questions should address the order-taking process, delivery of the food to the customers, current information requirements, needed information not currently provided by the system, and suggested areas for improvement.

The cooks could also be asked open-ended questions in a group interview setting.

During the group interview, questions about the order-taking process, how the order is communicated to the cooks, information needed for food preparation, and areas for improvement should be asked. c. What types of documents are you likely to obtain for further study? What types of documents will most likely not be available? Why? Management reports, supplier invoices, and cash register tapes are readily available. Because Hoosier Burger has an automated food ordering system (mentioned in Chapter 5), current system documentation probably exists. It is unlikely that Bob and Thelma have a written, formal mission statement, organization chart, business policy manual, or job descriptions. However, Bob and Thelma may have a business plan. The currency of this plan should be determined. d. What modern requirements determination methods are appropriate for this project?

Of the two modern methods discussed in the chapter, prototyping is the most likely method that will be used. Prototyping forms and reports will aid in the design of the new system. For this project, a JAD session is cost prohibitive.

5-27. Clothing Shack Case Exercises Solutions a. Whom would you interview? Why? The new marketing system will likely impact most, if not all, of the Clothing Shack’s functional areas. Representatives from each of the functional areas should be asked to provide input. Within the marketing area, Ms. O’Neil, ordertakers, and middle and lower management should provide input. Customers should also be contacted and asked for input. Another valuable resource would be the order pickers.

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

15

b. What requirements determinations methods are appropriate for this project?

This system is of definite importance to the company and will provide a strategic advantage. It is important that each functional area have input into the development of the system. A variety of fact-finding methods is appropriate. The fact-finding methods include interviews, questionnaires, JAD sessions, prototyping, document analysis, and observations. c. Based on the answers provided for part b, which requirements determination methods are appropriate for the individuals identified in part a?

A JAD session consisting of management representatives and potential end users should be conducted. Interviewing Ms. O’Neil will provide insight into the system’s overall objectives. Representatives from the various functional areas should be asked to provide input via questionnaires, group interviews, or individual interviews. Customer samples can be gathered through questionnaires.

Additionally, since customers are at the heart of this new system, perhaps arrangements can be made to observe or interview customers about the new system. d. Identify the requirements determination deliverables that will likely result from this project.

The types of deliverables include information collected from conversations with end users, existing documents and files, and computer-based information. Table 5–1 provides a list of specific deliverables that may result from this project.

Petrie’s Electronics Case Questions Solutions 5-28. What do you think are the sources of the information Jim and his team collected? How do you think they collected all of that information?

It says in the case that Jim and the team collected information through interviews.

These interviews would have been with key stakeholders in the company. It also says they collected information from loyal customers identified by the marketing department. Finally, Jim and his team collected information about existing systems.

5-29. Examine Table 5-1. Are there any requirements or constraints that you can think of that were overlooked? List them.

This answer will vary with students. For example, another requirement might be that the overall program would be highly attractive and motivating to customers. Another requirement might be that the client version of the system runs easily on a mobile phone. Constraints might include needs for storage of transactions (millions of customers would generate millions of transactions over a few months) and the need to avoid complexity in both the program and the system. Students might want to look at the requirements for the program separately from the requirements for the system.

. Publishing as Prentice Hall

Chapter 5

Determining System Requirements

16

5-30. If you were looking for alternative approaches for Petrie’s customer loyalty program, where would you look for information? Where would you start? How would you know when you were done?

They could have gotten that information from several sources, including vendor brochures, sales information, industry trade publications, and company websites, as well as from current customers of such systems. Students would probably start with a Google search. They would know when they were done when they couldn’t come up with any new information about loyalty systems.

5-31.Using the web, find three customizable customer loyalty program systems being sold by vendors. Create a table like Table 5-2 that compares them.

This answer will vary with the student and with the three systems they identify.

5-32.Why shouldn’t Petrie’s staff build their own unique system in-house?

They could build their own system from scratch, but the cost would be high, and it would take a long time to design, build, and implement the system. About the only reason such an approach would make sense would be if the company planned on licensing their system to other companies, helping to recoup the costs of building a system from scratch.

. Publishing as Prentice Hall

Chapter 6

Structuring System Requirements: Process Modeling

1

Chapter 6 Structuring System Requirements: Process Modeling Chapter Overview This chapter continues the discussion of systems analysis, introducing students to requirements structuring. Specifically, students are introduced to process modeling and logic modeling. Although there are several methods and techniques available for process modeling, this chapter focuses on Data-flow Diagrams (DFDs) because they have been popular for many years, especially in the structured analysis and design literature. Also, many CASE tools have incorporated DFDs into their sets of system development tools and techniques.

Structured English and decision tables are the two logic models presented in this chapter. The chapter discusses how Structured English statements are used to represent the basic constructs in structured programming: sequence, choice, and repetition. Decision tables are discussed in reference to how they can represent more complicated processing logic than simple Structured English statements.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Show how data-flow diagrams can logically model processes.

2. Teach students data-flow diagram symbols and the mechanical rules necessary for them to create accurate and well-structured process models.

3. Show students how to decompose data-flow diagrams into lower-level diagrams.

4. Illustrate the concept of balanced DFDs. 5. Explain and demonstrate the differences among the four types of DFDs: current physical, current logical, new physical, and new logical.

6. Illustrate how data-flow diagrams can be used as tools to support systems analysis.

7. Show how Structured English can be used to model process logic.

8. Demonstrate how decision tables can be used to represent the logic of choice in conditional statements.

9. Explain that process modeling for Internet-based electronic commerce applications is no different than the process used for other applications.

.

Chapter 6

Structuring System Requirements: Process Modeling

2

Classroom Ideas 1. Use Figures 6–2 and 6–6 to illustrate the basic DFD symbols and the correct and incorrect ways to draw the diagrams. Use Figure 6–3 to demonstrate the problem with trying to include sources/sinks inside the system being modeled.

2. Once you have taught the basics of drawing DFDs, have students complete Problems and Exercises 1 through 3 and 8 as in-class exercises that you can then go over in class.

3. Figures 6–4, 6–5, 6–7, 6–8, 6-9 and 6-10 can be used in class to teach decomposition. These can be followed with students completing Problems and Exercises 6-18 and 6-24 in-class.

4. Use Figure 6–11 to illustrate unbalanced DFDs. 5. Supplement the material in this chapter on DFD mechanics, decomposition, and balancing with your own examples, which you can work through together in class.

A good source of such examples is written organizational procedure statements.

Modified procedure statements also make good homework problems. See Problems and Exercises 6-24 and 6-25 for examples. It is probably best to devote at least one complete class period to working through examples. Students can prepare these diagrams outside of class or try for the first time in class. Many issues arise that are best handled from examples, such as the following difficulties that students often encounter: •

•

•

•

identifying when to show a direct data flow between processes and when to decouple these with a data store (emphasize that data stores allow different processes to work at different rates and at different times). deciding what activities to encompass with each process (emphasize the principle of cohesion and the goal of each process being of roughly equal size and complexity). distinguishing processes from sinks and sources (emphasize factors such as audience and the ability to change or control in making such distinctions). logical inconsistencies or ambiguities in narrative descriptions (emphasize that this is the power of DFDs and the typical interaction between requirements structuring and requirements determination necessary to resolve such ambiguities).

6. Use a CASE tool in class to demonstrate other ways to model processes other than DFDs. Have students compare and contrast these alternative methods with DFDs. 7. Using a CASE tool that supports DFDs, show in class how the tool provides for decomposition and balancing and how DFDs are linked to the CASE repository.

Later, when teaching Chapter 6, you can show how the repository links DFDs and entity-relationship diagrams.

.

Chapter 6

Structuring System Requirements: Process Modeling

3

8. Use a CASE tool in class to show how the tool checks for completeness, consistency, and other elements of analysis as discussed in the chapter.

10. Work through both decision table examples contained in the text, using Figures 6– 15 and 6–16, then work through Figures 6–17 and 6–18.

Lecture Notes As illustrated in Figure 6–1, requirements structuring is the second of the three primary analysis phases. This chapter introduces students to two methods useful for structuring requirements: process modeling and logic modeling,

Process Modeling Process modeling graphically represents the processes that capture, manipulate, store, and distribute data between a system and its environment and among components within a system. The data-flow diagram (DFD) is the type of process model discussed in Chapter 6. During requirements determination, information is collected about the current and new systems. The project team will structure this information into meaningful representations of the current and new systems. The requirements structuring process results in several deliverables, including a context data-flow diagram, DFDs of the current system, DFDs of the new system, and a thorough description of each DFD component. The process modeling deliverables are listed in Table 6–1.

CASE tools facilitate the preparation of these diagrams.

Data-Flow Diagramming Mechanics Four symbols are used on data-flow diagrams; these symbols represent data flows, data stores, processes, and source/sinks. The Gane and Sarson symbol set is illustrated in Figure 6–3 and is the symbol set used in this textbook. A data flow represents data that are in motion and moving as a unit. A data flow is represented by an arrow on the dataflow diagram. A database query, sales report, or order are examples of data flows. In contrast to a data flow, a data store represents data at rest. On a data-flow diagram, a data store is represented as a rectangle with its right vertical line missing. A notebook, file folder, or customer database are examples of data stores. A process, represented as a rectangle with rounded corners, represents the works or actions performed on data.

Sources/sinks are the origin and/or destination of data and are represented on the data-flow diagram as squares or rectangles. Suppliers, customers, and a bank are examples. As it relates to sources/sinks, we are not interested in the interactions that occur between sources and sinks, what a source or sink does with information or how it operates, how to control or redesign a source or sink, and how to provide sources and sinks with direct access to stored data. Figure 6–4 contrasts an incorrectly drawn DFD (a process is shown as a sink) with one that is correctly prepared.

The Hoosier Burger case illustrates the DFD development process. The boundary or scope of Hoosier Burger’s food-ordering system is represented by a context diagram; this diagram, illustrated in Figure 6–5, also shows the system’s interactions with its

.

Chapter 6

Structuring System Requirements: Process Modeling

4

environment. The context diagram contains only one process labeled “0” and no data stores. After the context diagram is prepared, a level-0 diagram is drawn. The foodordering system’s level-0 diagram is shown in Figure 6–6. The level-0 diagram represents a system’s major processes, data flows, and data stores at a high level of detail.

The preparation of data-flow diagrams (DFDs) is governed by a set of rules; these rules are summarized in Table 6–2. Two additional DFD diagramming rules are that the inputs to a process are different from the outputs of that process and DFD objects have unique names. Figure 6–7 shows the incorrect and correct ways to draw data-flow diagrams. The context diagram is functionally decomposed into finer and finer detail, resulting in the preparation of several levels of diagrams. A level-n diagram is a DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram. Functional decomposition will continue until a subprocess cannot be exploded into more detail. Primitive DFDs are the lowest level DFDs. The level-1 diagram appearing in Figure 6–8 is a decomposition of Process 1.0 on the level-0 diagram. Figure 6–9 shows a level 1 diagram. Figure 6–10 shows a level-2 diagram.

DFDs should be balanced, meaning that the inputs and outputs to a process are conserved at the next level of decomposition. Figure 6–11 shows a set of unbalanced DFDs. Figure 6–12 provides an example of a data-flow splitting. Table 6–3 summarizes four advanced diagramming rules. These rules address splitting composite data flows into component data flows at the next level, the conservation principle, an exception to balancing, and minimizing clutter on the DFD.

Using Data-Flow Diagramming in the Analysis Process Completeness, consistency, timing considerations, the iterative nature of drawing DFDs, and drawing primitive DFDs are five additional data-flow diagramming guidelines. DFD completeness is the extent to which all necessary components on a data-flow diagram have been included and fully described. CASE tools can help identify areas where the diagrams are incomplete. It is important that each DFD element be described in the CASE repository. DFD consistency is the extent to which information contained on one level of a set of nested data-flow diagrams is also included on other levels. Again, CASE tools can be used to detect inconsistencies among diagrams. DFDs do not represent time, thus they do not reflect how often a processing activity occurs. Because diagrams are generally not perfect on the first try, these diagrams are modified, resulting in iterative development.

As mentioned previously, primitive DFDs are the lowest level of diagramming. The analyst has probably reached the primitive level when she has reduced each process to a single decision or calculation; each data store represents data about a single entity; the system user does not care to see any more detail; every data flow does not need to be split further to show that different data are handled in various ways; each business form or transaction, computer online display, and report has been shown as a single data flow; and there is a separate process for each choice on all lowest-level menu options.

Data-flow diagrams are useful for performing gap analysis and for identifying system inefficiencies. Gap analysis is the process of discovering discrepancies between two or

.

Chapter 6

Structuring System Requirements: Process Modeling

5

more sets of data-flow diagrams or discrepancies within a single DFD. Gap analysis helps identify redundant data flows, data that are captured and not used by the system, and data that are updated identically in more than one location. CASE tools aid in this analysis.

The IBM Credit Corporation is used as an example of how DFDs are useful during business process reengineering. As Figures 6–13 and 6–14 illustrate, data-flow diagrams made visualizing and analyzing the financing process much easier.

Logic Modeling Because data-flow diagrams do not show the inner workings of processes, logic models are useful for showing this internal logic. Decision tables are a popular method for modeling system logic. In many instances, decision logic is quite complex, and often, decision tables are best suited for these situations. A decision table is a matrix representation of the logic of a decision, which specifies the possible conditions for the decision and resulting actions. A decision table consists of three parts: condition stubs, action stubs, and rules. A decision table can be simplified by removing indifferent conditions. Figure 6–15 shows a complex decision table; Figure 6–16 shows the simplified version. The basic procedures for decision table construction are: (1) name the conditions and the values each condition can assume; (2) name all possible actions that can occur; (3) list all possible rules; (4) define the actions for each rule; and (5) simplify the decision table. Figure 6–17 shows a decision table for the Hoosier Burger’s inventory reordering system; Figure 6–18 shows the simplified table.

PVF WebStore: Process Modeling The authors use Pine Valley’s WebStore to illustrate process modeling for an electronic commerce application. This example shows that process modeling for electronic commerce applications is the same as for more traditional application development projects. Table 6–4 outlines the WebStore’s system structure and corresponding Level0 processes. Figure 6–19 is a Level-0 DFD for the WebStore.

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

data-flow diagram (5)

11.

DFD consistency (9)

2.

balancing (2)

12.

level-n diagram (13)

3.

condition stubs (3)

13.

process (15)

4.

level-0 diagram (12)

14.

rules (17)

5.

source/sink (18)

15.

data store (6)

6.

indifferent condition (11)

16.

process modeling (16)

.

Chapter 6

Structuring System Requirements: Process Modeling

7.

context diagram (4)

17.

gap analysis (10)

8.

primitive DFD (14)

18.

action stubs (1)

9.

DFD completeness (8)

10.

decision table (7)

6

Review Questions Solutions 6-1. What is a data-flow diagram? Why do systems analysts use data-flow diagrams?

A data-flow diagram is a picture of the movement of data between external entities and the processes and data stores within a system. Systems analysts use dataflow diagrams to help them model the processes internal to an information system as well as how data from the system’s environment enter the system, are used by the system, and are returned to the environment. DFDs help analysts understand how the organization handles information and what its information needs are or might be. Analysts also use DFDs to study alternative information handling procedures during the process of designing new information services.

6-2. Explain the rules for drawing good data-flow diagrams.

The rules for DFDs are listed in Table 6–2 and illustrated in Figure 6–6.

Processes cannot have only outputs, cannot have only inputs, and must have a verb phrase label. Data can move to a data store from only a process, not from another data store or an outside source. Similarly, data can be moved to only an outside sink or to another data store by a process. Data to and from external sources and sinks can be moved by only processes. Data flows move in one direction only. Both branches of a forked or a joined data flow must represent the same data. A data flow cannot return to the process from which it originated.

6-3. What is decomposition? What is balancing? How can you determine if DFDs are not balanced?

Decomposition is the iterative process by which a system description is broken down into finer and finer detail, creating a set of diagrams in which one process on a given diagram is explained in greater detail on a lower–level diagram.

Balancing is the conservation of inputs and outputs to a data-flow diagram process when that process is decomposed to a lower level. You can determine if a set of DFDs are balanced or not by observing whether or not a process that appears in a level-n diagram has the same inputs and outputs when decomposed for a lower-level diagram.

6-4. Explain the convention for naming different levels of data-flow diagrams.

The highest level DFD is called a context diagram. It represents the system as a single process, with all the related entities and the data flows in and out of the system. The next level diagram, called a level-0, decomposes the one process from the context diagram into between two to nine high-level processes. Each process in a level-0 diagram can be decomposed, if necessary. Each resulting diagram is called a level-1. Should processes in a level-1 diagram be

.

Chapter 6

Structuring System Requirements: Process Modeling

7

decomposed, each resulting diagram would be called a level-2 diagram. Each of these processes would be decomposed on a level-3 diagram, and so on.

6-5. How can data-flow diagrams be used as analysis tools?

DFDs can be used as analysis tools to help determine the completeness of a system model and a model’s internal consistency, as a way to determine when system events occur through analyzing timeliness, and, through iterative use, to develop and check models. Analysts can study DFDs to find excessive information handling, thus identifying areas for possible efficiencies.

6-6. Explain the guidelines for deciding when to stop decomposing DFDs. You can stop decomposing a DFD when the following six conditions are satisfied: (1) each process is a single decision or calculation or a single database operation, such as retrieve, update, create, delete, or read; (2) each data store represents data about a single entity, such as a customer, employee, product, or order; (3) the system user does not care to see any more detail, or when you and other analysts have documented sufficient detail to do subsequent systems development tasks; (4) every data flow does not need to be split further to show that different data are handled in different ways; (5) you believe that you have shown each business form or transaction, computer screen, and report as a single data flow; and (6) you believe there is a separate process for each choice on all lowest–level menu options for the system.

6-7. How do you decide if a system component should be represented as a source/sink or as a process?

Sources and sinks are always outside of the system being considered. They are of interest to the system being considered only because they represent sources of data coming into the system and destinations for data leaving the system. If any data processing occurs inside a source or sink, it should be of no interest to the system being modeled. If the processing is of interest, however, or if the identified source/sink has several inputs and outputs to and from the rest of the system, it may be better considered as an internal process.

6-8. What unique rules apply to drawing context diagrams?

Context diagrams have only one process that represents the entire system being modeled and shows only the data flows into and out of the system. The diagram also includes sources and sinks, which represent the system’s environmental boundaries. There are usually no data stores in a context diagram.

6-9. Explain what the term DFD consistency means and provide an example.

DFD consistency is the extent to which information contained on one level of a set of nested data-flow diagrams is also included on other levels. Balancing errors are one type of consistency violation mentioned in the textbook. For instance, a

.

Chapter 6

Structuring System Requirements: Process Modeling

8

payment data flow that appears on a level-1 diagram, but not on the level-0 diagram, is a consistency violation.

6-10. Explain what the term DFD completeness means and provide an example.

DFD completeness is the extent to which all necessary components of a data-flow diagram have been included and fully described. A data store that does not have any data flows coming into or out of it is a completeness violation.

6-11. How well do DFDs illustrate timing considerations for systems? Explain your answer.

Timing considerations are not noted on DFDs. For instance indications of whether a process occurs hourly, daily, weekly, monthly, or yearly are not made.

6-12. How can data-flow diagrams be used in business process redesign?

DFDs can graphically illustrate, at varying levels of detail, how a process or processes work. Analysts can study DFDs of the current system and identify areas of inefficiency. Analysts can prepare DFDs for the new system, identifying changes for the new system.

6-13. What are the steps in creating a decision table? How do you reduce the size and complexity of a decision table?

The steps for creating a decision table are: (1) name the conditions and the values each condition can assume; (2) name all possible actions that can occur; (3) list all possible rules; (4) define the actions for each rule; and (5) simplify the decision table.

To reduce the size and complexity of a decision table, use separate, linked decision tables, or use numbers that indicate sequence rather than Xs where rules and action stubs intersect. Also, the analyst should identify indifferent conditions and simplify the decision table.

6-14. What formula is used to calculate the number of rules a decision table must cover?

To determine the number of rules a decision table must cover, simply determine the number of values each condition may have and multiply the number of values for each condition by the number of values for every other condition.

Problems and Exercises Solutions 6-15. Using the example of an online cell phone apps store, list relevant data flows, data stores, processes, and sources/sinks. Draw a context diagram and a level-0 diagram that represent the app store. Explain why you chose certain elements as processes versus sources/sinks.

A suggested context diagram and level-0 diagram are provided below.

.

Chapter 6

Structuring System Requirements: Process Modeling

9

Context Diagram:

CUSTOMER

Customer Order

Receipt Report of Purchase

0 Apps Store

APPS DEVELOPER

Payment Information

Confirmation of Payment

PAYMENT PROCESSOR

Level-0 Diagram:

CUSTOMER

Customer Order Receipt

1.0 Receive and Process Customer Order

Confirmation of Payment

PAYMENT PROCESSOR

Payment Information

App Sale Data

D1: App Sales History

Formatted Sale Data

Monthly Sales Data

2.0 Update App Sales History

3.0 Generate App Sales Data Report

Report of Purchase

APPS DEVELOPER

6-16. Using the example of checking out a book from your university or college library, draw a context diagram and a level-0 diagram. A suggested context diagram and a level-0 diagram are provided below.

Context Diagram:

.

Chapter 6

Structuring System Requirements: Process Modeling

PATRON

Book Checkout Request Book Loan Information

0 LIBRARY CHECK-OUT SYSTEM

Book Availability Information

10

LIBRARY WEB CATALOG

Level-0 Diagram:

PATRON

Book Checkout Request

1.0 Receive Checkout Request

LIBRARY WEB CATALOG

Information on Book Requested

Book Availability Information

Information on Patron Requesting Book

2.0 Determine Patron Eligibility

3.0 Determine Book Disposition

Patron Eligibility Information

Book Loan Information

Book Disposition Information

4.0 Process Request

5.0 Update Library Web Catalog

Changes in Checkout Status

Book Information Book Checkout Status

D1: Library Catalog

6-17. Evaluate your level-0 DFD from Problem and Exercise 6-16 using the rules for drawing DFDs in this chapter. Edit your DFD so that it does not break any of these rules.

Students should go through the rules discussed in this chapter (and presented in Table 6–2 and Figure 6–7) one at a time and check each of their data-flow diagrams. Alternatively, if the students are using a CASE tool to create their dataflow diagrams, the CASE tool may be used to automatically check for errors in the diagrams. There are no rule violations in the example DFDs, but we cannot verify that there are no logical problems until we decompose the diagrams to a primitive level. One obvious missing system capability is how to handle invalid orders; typically, processes to handle abnormal conditions, like invalid orders, are shown on primitive or at least low-level diagrams.

6-18. Choose an example like that in Problem and Exercise 6-16, and draw a context diagram. Decompose this diagram until it doesn’t make sense to continue. Be sure that your diagrams are balanced, as discussed in this chapter.

.

Chapter 6

Structuring System Requirements: Process Modeling

11

Students may choose a variety of situations to use for the nth level data-flow diagrams for this answer. Basically, students should continue the process of decomposition until they have reached the point where no subprocess can logically be broken down further (i.e., each process meets the definition of a primitive process). See the level-1 data-flow diagram for this exercise, which shows a sample decomposition of the process titled Finalize Order from the level0 data-flow diagram provided for Problem and Exercise 6-16. The (italicized) labels for processes and sources/sinks without borders represent the origin or destination of flows that pass between this subsystem and other system components. Note that the Goods Sold File is a potential black hole or should possibly be treated as a sink.

Problem and Exercise #4 Level-1 Diagram Level-1 Diagram Cap & Gown Company

Validate Order

Cap and Gown Order

2.1 Generate Receipt

Valid Order Information

Receipt

2.2 Log Goods Sold Data

Receipt

Goods Sold Data

Goods Sold File

2.3 Generate Information For Shipping

Inventory Data

Update Inventory File

Validate Order

6-19. Refer to Figure 6-21, which contains a draft of a context and a level-0 DFD for a university class registration system. Identify and explain potential violations of rules and guidelines on these diagrams.

Some errors and peculiarities in these diagrams include: • In the level–0 diagram, the data store, Class Roster, does not have the data flow, Scheduled Classes, flowing into it. Rather, this data flow connects processes 2 and 3; thus, these DFDs are not balanced.

.

Chapter 6

Structuring System Requirements: Process Modeling

12

• Process 1 appears to accomplish nothing since its inflow and outflow are identical; such processes are uninteresting and probably unnecessary; it is possible that this process will become interesting when it is decomposed, where validation and error handling processes might appear.

• Process 2 does not appear to need Course Request as input in order to perform its function, as implied by its name.

• Some students may also wonder if process 3 has input sufficient to produce its output; for example, where are prior class registrations kept so that process 3 can determine when a course is full?

6-20. What is the benefit of creating multiple levels of DFDs? Consider the concept of DFD consistency, as described on page 181. Why is consistency important to take advantage of the multiple levels of DFDs that may be created?

Creating multiple levels of DFDs assists in ensuring that sufficient levels of detail can be understood when structuring requirements. By creating multiple levels, those with a need for a broad overview can focus on context and level-0 diagrams. Those with need for more detail can use the more fully decomposed diagrams. These diagrams need to remain consistent as missing sources, sinks, or data flows can cause inconsistency between those referring to higher and lower level diagrams.

6-21. Why do you think analysts have different types of diagrams and other documentation to depict different views (e.g., process, logic, and data) of an information system?

The various views (e.g., process, logic, data) of an information system each have their own unique characteristics and provide the most relevant information to different information system specialists. This variety is best understood, expressed, and managed by using diagrams and documentation that are specifically tailored for each view of the system. For example, data-flow diagrams are useful for capturing the flow of data through business processes, but they are not useful for describing the forms and relationships among data. As information systems become larger and more complex, it becomes even more important to use the right tool and technique to develop each component of an information system. One technique that captured all aspects of an information system model on one diagram or in one notation would likely be too complex for systems professionals to handle.

6-22. Consider the DFD in Figure 6–22. List three errors (rule violations) on this DFD. Three major errors in Figure 6–22 are: • Process 1.0 (P2) has only inputs, making it a “black hole”.

• Data flow DF5 should not move directly from source E1 to data store DS1 without first going through a process.

.

Chapter 6

Structuring System Requirements: Process Modeling

13

• Data flow DF1 should not move directly from source E1 to sink E2 without first going through a process.

• Other peculiarities (such as Process 1.0 has label P2 and the data store has only a label, not a number) are only that, not errors.

6-23. Consider the three DFDs in Figure 6–23. List three errors (rule violations) on these DFDs. These diagrams show the decomposition of process P1 on the level-0 diagram.

Three particular logical errors in Figure 6–23 are: • The data store DS1, not DS2, should be represented on the level-1 diagram.

• DF6 is an inflow to sub process 1.2 on the level-1 but is an outflow on the context diagram. The arrow is in reverse.

• Data flow DF3 should be an outflow on the level-1 diagram, and data flow DF6 should not be on the level-1 diagram.

• Process P1.4.2 has no inputs and is thus a “miracle.”

6-24.Starting with a context diagram, draw as many nested DFDs as you

consider necessary to represent all of the details of the patient flow management system described in the following narrative. You must draw at least a context diagram and a level-0 diagram. In drawing these diagrams, if you discover that the narrative is incomplete, make up reasonable explanations to complete the story. Provide these extra explanations along with the diagrams.

Dr. Frank’s walk-in clinic has decided to go paperless and will use an information system to help move patient through the clinic as efficiently as possible. Patients enter the system at the front desk by providing demographic information to the personnel. If this is the first time the patient has been seen, insurance and basic demographic information is collected from the patient. If the patient has been seen previously, the patient is asked to verify the information pulled from the patient registry.

The front desk person then updates the patient registry and ensures that the patient has a chart in the electronic medical records system; if not, a new medical record is started by placing formatted demographics into a blank medical record. The front desk person then enters the medical record ID into the system. Next, a medical technician collects the patient’s health history, weight, height, temperature, blood pressure, and other medical information, and combines this information with any information from the patient’s medical record, summarizing the information into a health trend. A doctor then sees the patient, prescribes medication or treatment where appropriate based on the medical trend, and sends the patient to checkout. The employee at checkout updates the patient’s electronic medical record and provides prescriptions for medications or treatments and a printed record of the health services received.

CONTEXT DIAGRAM:

.

Chapter 6

Structuring System Requirements: Process Modeling

Health Information Treatment Plan Record of Services

0 Patient Flow Management System

Demographic Information

PATIENT

Demographic Information

PATIENT

14

Level-0 Diagram: Treatment Plan Record of Services

1.0 Process Demographic Information

Updated Demographics

Electronic Medical Record ID Existing Patient Demographics

2.0 Process Health Information

Health Information

Health Trend Information

3.0 Create Treatment Plan

4.0 Finalize Visit

Diagnoses and Prescriptions

D1: Patient Registry Prior Health Information

D2: Electronic Medical Record

Formatted Demographics

Updated Health Information

6-25. a. Starting with a context diagram, draw as many nested DFDs as you consider necessary to represent all of the details of the engineering document management system described in the following narrative. You must draw at least a context diagram and a level-0 diagram. In drawing these diagrams, if you discover that the narrative is incomplete, make up reasonable explanations to complete the story. Provide these extra explanations along with the diagrams.

Projects, Inc. is an engineering firm with approximately 500 engineers that provide mechanical engineering assistance to organizations, which requires managing many documents. Projects, Inc. is known for its strong emphasis on change management and quality assurance procedures. The customer provides detailed information when requesting a document through a web portal. An engineer is assigned to write the first draft of the requested document. Upon completion, two peer engineers review the document to ensure that it is correct and meets the requirements. These reviewers may require changes or may approve the document as-is. The document is updated until the reviewers are satisfied with the quality of the document.

The document is then sent to the customer for approval. The customer can require changes or accept the document. When the customer requires changes, an engineer is assigned to make the changes to the document.

When those changes are made, two other engineers must review those

.

Chapter 6

Structuring System Requirements: Process Modeling

15

changes. When those reviewers are satisfied with the changes, the document is sent back to the customer. This may happen through several iterations until the customer is satisfied with the document.

Context: 0 Document Management System

Document Request

CUSTOMER

Document Draft Acceptance Decision

Document Requirements Document Draft Document To Review

ENGINEERS

Document Review Result

Level-0: 1.0 Process Document Request

Document Request

CUSTOMER

Document Draft

4.0 Approve Draft

Acceptance Decision

Requirements for Document Document Draft

Document Requirements

ENGINEERS

Customer Required Changes Review Required Changes

2.0 Complete Draft

Reviewed Document Draft

Unreviewed Document Draft Document To Review

3.0 Review Draft

Document Review Result

b. Analyze the DFDs you created in Part a. What recommendations for improvements can you make based on this analysis? Draw new logical DFDs that represent the requirements you would suggest for an improved document management system. Remember, these are to be logical DFDs, so consider improvements independent of technology that can be used to support the management of these documents.

The DFDs show an inherent weakness in the processes used for the data to flow. The document may go through several revisions before the customer has seen any information from the document, thereby wasting a massive amount of effort. A better process would seek customer input on the requirements that are used as input into the 2.0 Complete Draft process. This could be done by extending the process using this as the Level-1 diagram. Note that this is not balanced with the context diagram above.

Level-1:

.

Chapter 6

Structuring System Requirements: Process Modeling

Preliminary Document Requirements

1.2 Approve Document Requirements

16

1.1 Receive Document Request

Document Request

Requirements for Approval

CUSTOMER

Document Draft

Req Approval Decision

4.0 Approve Draft

Acceptance Decision

1.3 Update Document Requirements Approved Requirements for Document Document Draft

Document Requirements

ENGINEERS

Customer Required Changes Review Required Changes

2.0 Complete Draft

Reviewed Document Draft

Unreviewed Document Draft Document To Review

3.0 Review Draft

Document Review Result

6-26. A company has various rules for how payments to suppliers are to be authorized. Some payments are in response to an approved purchase order.

For approved purchase orders under $5,000, the accounting clerk can immediately issue a check against that purchase order and sign the check.

For approved purchase orders between $5,000 and $10,000, the accounting clerk can immediately issue a check but must additionally obtain a second signature. Payments for approved purchase orders over $10,000 always require the approval of the accounting manager to issue the check as well as the signature of two accounting clerks. Payments that are not covered by a purchase order that are under $5,000 must be approved by the accounting manager and a departmental manager that will absorb the cost of the payment into that department’s budget. Such checks can be signed by a single accounting clerk. Payments that are not covered by a purchase order that are between $5,000 and $10,000 must be approved by the accounting manager and a departmental manager, and the check must have two signatures. Finally, payments that are not covered by a purchase order that exceed $10,000 must be approved by a department manager, the accounting manager, and the Chief Financial Officer. Such checks require two signatures. Use a decision table to represent the logic in this process. Write down any assumptions you have to make.

.

Chapter 6

Structuring System Requirements: Process Modeling

Approved Purchase Order Purchase Amount Two Signatures Accounting Manager Approval Department Manager Approval CFO Approval Purchase Amount: S = < $5,000 M = $5,000 - $10,000 L = > $10,000

17

Rules 1 2 3 4 5 6 Y Y Y N N N S M L S M L X X X X X X X X X X X X

6-27. A relatively small company that sells eyeglasses to the public wants to incentivize its sales staff to upsell customers on higher-quality frames, lenses, and options. To do this, the company has decided to pay the sales representatives based on a percentage of the profit earned on the glasses.

All sales representatives will earn 15% of the profit on the eyeglasses.

However, the owners are concerned that the sales staff will fear earning less than they do now. Therefore, those who were already working at the company are grandfathered into an arrangement where the workers are guaranteed to earn at least their base salary. Newly hired employees, however, are guaranteed only minimum wage based on the hours worked.

To ensure only productive employees are retained, employees who are underperforming for 3 months in a row are automatically terminated. For those employees who are grandfathered in, any month where the representative earns only the salary is considered underperforming. For newer employees, the bottom quarter of the employees based on profit earned per hour worked are considered underperforming. Use a decision table to represent the logic in this process. Write down any assumptions you have to make.

Before reducing, we can have a table like this:

.

Chapter 6

Structuring System Requirements: Process Modeling

18

Rules 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Grandfathered in with Salary Y Y Y Y Y Y Y Y N N N N N N N N Less Commission than Salary Y Y Y Y N N N N Y Y Y Y N N N N Less Commission than Minimum Wage Y Y N N Y Y N N Y Y N N Y Y N N Underperforming for last 2 months Y N Y N Y N Y N Y N Y N Y N Y N Pay Salary Pay Minimum Wage Pay Commission Amount Mark as Underperforming Terminate Employment

X X X X X X X X X X X X X X X X

X X X X

X X X

X X X X X

After reducing, we have a decision table like this: Rules 1 2 3 4 5 6 Grandfathered in with Salary Y Y Y N N N Less Commission than Salary Y Y N - - Less Commission than Minimum Wage - - - Y Y N Underperforming for last 2 months Y N - Y N -

Pay Salary Pay Minimum Wage Pay Commission Amount Mark as Underperforming Terminate Employment

X X X X X X X X

X X X X

6-28. A large technology company receives thousands of applications per day from software engineers who hope to work for that company. To help manage the constant flow of applications, a process has been created to streamline identifying applicants for specific openings as they occur. Those applications that are not in an approved file format are discarded and not processed in any way. All applications are first fact-checked automatically by detecting any inconsistencies with the application and the resume, as well as other resume sites available online. For any applications with more than one inconsistency, the application is automatically rejected as untruthful. Next, the application is checked against the database of other applications already in the system. If such an application exists, the older application is purged and the new application continues processing. Any applications that do not contain at least 15 of the top 200 keywords that the company is looking for are rejected. Next, the phone numbers of references are checked to ensure they are a valid, working phone number. These applicants are then retained in a searchable database. When managers send a hiring request, the fifty best applications that most closely match the desired attributes are sent to the manager. That manager selects the top 10

.

Chapter 6

Structuring System Requirements: Process Modeling

19

applications, which are then screened for bad credit, with credit scores below 500 eliminated from the hiring process. If there are at least 5 remaining candidates, they are all invited to participate in phone interviews.

If there are fewer than 5 remaining candidates, the next 10 best matches are added to the pool and screened for poor credit, and any remaining candidates are invited to participate in phone interviews. Present this logic in a decision table. Write down any assumptions you have to make.

Rules 1 2 3 4 5 6 7 8 9 10 11 12 Valid Format N Y Y Y Y Y Y Y Y Y Y Y More than one inconsistency - Y N N N N N N N N N N Another application exists - - Y Y Y Y Y N N N N N Contains top key words - - Y Y Y Y N Y Y Y Y N Phone numbers invalid - - Y N N N - Y N N N Among top 10 matches - - - Y Y N - - Y Y N Low credit score - - - Y N - - - Y N - Reject Application Purge Old Application Retain Application Phone Interview

X X X X X X X X X X X X X X X X X X

.

Chapter 6

Structuring System Requirements: Process Modeling

20

6-29. A huge retail store must carefully manage its inventory levels. Stock-outs (where there is none of an item on a shelf) can cause missed sales, while too much inventory costs the company money in storage, ties up capital, and carries the risk of the products losing value. To balance these requirements, the store has chosen to use just-in-time ordering. To accomplish this, reorders are automatically generated by an information system (called the reorder system). Each item has a floor value, which is the fewest units of an item that should be in the store at all time, as well as a ceiling value, which is the maximum number of units that can be stored on the allocated shelf space. Vendors are required to commit to delivering product in either two days or one week. For vendors of the two day plan, the reorder system calculates the amount of product purchased by customers in the past week, doubles the quantity, and then adds the inventory floor.

The quantity on-hand is then subtracted. This is the desired order quantity.

If this quantity added to the current inventory is greater than the ceiling, then the order quantity is reduced to the ceiling value less on-hand quantity.

If the desired order quantity is greater than the sales for the previous month, a special report is generated and provided to management and the order must be approved before being sent to the vendor. All other orders are automatically placed with the vendor. However, if a product experiences a stock-out, an emergency order is automatically generated for the ceiling amount or the quantity sold in the last month, whichever is less. For vendors on the one week plan, the reorder system calculates the amount of inventory sold in the last two weeks, doubles the quantity, and then adds the floor to create the desired stock level. If this level is greater than the ceiling, the desired stock level is lowered to the ceiling and a report is generated for management to determine if more space should be allocated.

The on-hand stock is subtracted from the desired stock level, yielding the desired order level. If the desired order level is greater than the number of units sold in the last two months, a special report is generated and provided to management and the order must be approved before being sent to the vendor. All other orders are automatically placed with the vendor. However, if a product experiences a stock-out, an emergency order is automatically generated for the ceiling amount or the quantity sold in the last month, whichever is less. Present this logic in a decision table. Write down any assumptions you have to make.

.

Chapter 6

Structuring System Requirements: Process Modeling

Stock-Out Delivery Agreement Desired Order Level Exceeds Ceiling Desired Order Exceeds Previous Month Sales Desired Order Exceeds Previous 2 Months Sales Order lesser of ceiling or last month's sales Generate report and hold for approval Generate report to look at allocated space Lower desired order quantity to ceiling Automatically place order with vendor

21

Rules 1 2 3 4 5 6 7 8 9 N N N N N N N N Y D D D D W W W W Y Y N N Y Y N N Y N Y N - - - - - - - - N Y Y N -

X X X X

X

X X X X X X X X X X X

Discussion Questions Solutions 6-30. Discuss the importance of diagramming tools for process modeling.

Without such tools, what would an analyst do to model diagrams?

Diagramming tools speed the development of DFDs. Most importantly, CASE tools can aid in the analysis of these diagrams, helping to determine their completeness and consistency. One alternative that analysts have is to generate the diagrams by hand. This, however, is a very inefficient, error-prone alternative.

6-31. Think and write about how data-flow diagrams might be modified to allow for time considerations to be adequately incorporated.

Students should identify several creative, innovative methods. One suggestion is to make notations on the data flows and in the processes to indicate their timing.

You might also encourage students to contrast data-flow diagrams with state diagrams (presented in Appendix A).

6-32. How would you answer someone who told you that data-flow diagrams were too simple and took too long to draw to be of much use? What if they also said that keeping data-flow diagrams up-to-date took too much effort, compared to the potential benefits?

The simplicity of DFDs is part of their appeal. The information contained in the DFDs is very useful, understandable, and valuable. DFDs can serve as a communication tool between analysts and end users, with the end users easily interpreting the information conveyed in these diagrams. Also, DFDs are very beneficial for performing gap analysis. A strong argument can be made for the use of CASE tools and the ability of these tools to speed DFD development, as well as systems development, and the ease with which CASE tools can update DFDs.

.

Chapter 6

Structuring System Requirements: Process Modeling

22

6-33. Find another example of where data-flow diagrams were successfully used to support business process reengineering. Write a report, complete with DFDs, about what you found.

Encourage students to locate case studies of companies that have recently undergone a reengineering process. Case studies are available in trade journals, in the library, and on the Web.

Case Problems Solutions 6-34. Pine Valley Case Exercises Solutions a. Construct a context data-flow diagram, illustrating the Customer Tracking System’s scope.

A suggested context diagram is provided below.

Pine Valley Furniture, Part a Context Diagram

Part a Context Diagram Follow-Up Sales Promotion

Existing Online Customer Id

WebStore

New Online Customer ID and Profile Request

Customer

Customer’s Purchase Existing Online Customer Profile New Customer ID Online Customer’s Purchase

0 Customer Tracking System

Existing Customer ID New Customer ID and Profile

Trend Analysis Existing Customer Information

New Customer ID and Profile Request

Query

Management

b.

Purchasing Fulfillment

Query-Based Report

Construct a level-0 diagram for the Customer Tracking System.

While student interpretations will vary, a suggested answer is provided below.

.

Chapter 6

Structuring System Requirements: Process Modeling

23

Pine Valley Furniture, Part b

Diagram Diagram Part bLevel-0 Level-0 New Customer ID and Profile Query-Based Report New Customer ID and Profile Request Purchasing Fulfillment

Query

Management

s le Sa

5 Generate Management Report

Existing Customer Information

rm fo In at

Trend Analysis

Sales

Inventory Information

Customer Profile

New Customer ID and Profile

New Customer ID

Existing Online Customer Profile

Web Store

New Online Customer ID and Profile Request

1 Verify Customer Account

Matching Customer Profile

Existing Online Customer ID

n io

Existing Customer ID

Sales Trends

3 Analyze Customer Purchasing Activity

r’s me s to Cu

e as rch Pu

Inventory

Cu s to me

2 Collect Customer Purchasing Activity

r’s

Re

ce

nt Pu rc

ha s

eA

c ti vit

Reserved Inventory

Online Customer’s Purchase

Updated Customer Purchase History

Inventory Status Customer

y 4 Generate Follow-Up Sales Promotion

Purchasing Fulfillment

Foll ow-U p

Sale s

Pro m

otio n Customer

c. Using the level-0 diagram that you constructed above, select one of the level-0 processes, and prepare a level-1 diagram.

While student interpretations will vary, a suggested answer is provided below.

.

Chapter 6

Structuring System Requirements: Process Modeling

24

Pine Valley Furniture, Level-1 DiagramPart c Level-1 Diagram

Existing Customer Information New Customer ID and Profile Purchasing Fulfillment New Customer ID and Profile Request

Existing Customer ID

New Customer ID Existing Online Customer ID

1.1 Verify Current Customer Status

1.3 Match Existing Customer ID with Profile

New Customer ID and Profile

Existing Online Customer Profile

Available Customer ID

WebStore

New Customer ID and Profile

Valid Existing Customer ID

New Online Customer ID and Profile Request

1.2 Create New Customer ID and Profile

Valid New Customer ID and Profile Request

Customer

Matching Customer Profile

Existing Customer Profile

d. Exchange your diagrams with another class member. Ask your class member to review your diagrams for completeness and consistency. What errors did he or she find? Correct these errors.

Encourage students to review the data-flow diagramming rules presented in Table 6-2. Using these rules as a guide, students should then evaluate their classmates’ diagrams.

6-35. Hoosier Burger Case Exercises Solutions a. Modify the Hoosier Burger context-level data-flow diagram (Figure 6–4) to reflect the changes mentioned in the case.

Student interpretations may vary; a suggested answer follows.

.

Chapter 6

Structuring System Requirements: Process Modeling

25

Hoosier Burger, Part a Context-Level Diagram Context-Level Diagram

Delivery Order Receipt

Food Order

Delivery Order Request

Customer

Kitchen

Cus

to m

er O

rd e

De

r

O rd

Receipt Delivery Payment/Order Ticket

ry liv e

er

Fo

ke T ic

od

tA

O rd

cco

er

mp

any

in

e gD

liv e

ry

O rd

er

0 Food Ordering System

Management Reports Restaurant Manager Reconciled Delivery Order Report

.

Chapter 6

Structuring System Requirements: Process Modeling

26

b. Modify Hoosier Burger’s level-0 diagram (Figure 6–5) to reflect the changes mentioned in the case.

Although student answers will vary, a suggested answer is provided below.

Hoosier Burger, Part b Level-0 Diagram Level-0 Diagram Customer Order

Food Order

Customer

Inventory Data

3 Update Inventory File

Goods Sold

d a te at at D rm ry Fo nto e v In

2 Update Goods Sold File

Formatted Goods Sold Data Goods Sold File

Daily Goods Sold Amount

t en m ge orts a an p M Re

ver

yG

ood

sS

o ld

A d ju

s tm

e n ts

Updated Inventory Data Reflecting Delivery Deletions

Daily Inventory Depletion Amounts Inventory File

Daily Delivery Orders

O Delivery Orders

Restaurant Manager

nd Pe et ic k e r y r T l iv rd e D e

i ng

5 Review/Fill Delivery Order

Delivery Order Receipt

er rd O t y er es liv equ y De R er t/ liv en et De ym ick T Pa er rd O

4 Produce Management Reports

Delivered Order Tickets

Inventory File D e li

Delivery Food Order

1 Receive and Transform Customer Food Order

Delivered Order Ticket

Receipt

Order Ticket Accompanying Delivery Order

Kitchen

Daily Delivery Orders Customer

Reconciled Delivery Order Report

.

Chapter 6

Structuring System Requirements: Process Modeling

27

c. Prepare level-1 diagrams to reflect the changes mentioned in the case.

Student answers will vary; to facilitate discussion, a level-1 diagram is provided below.

Hoosier Burger, Part c Level-1 Diagram

Level-1 Diagram Delivery Food Order Delivery Order Request Kitchen

Customer

Order Ticket Accompanying Delivery Order

Order Ticket Pending Delivery 5.1 Receive Delivery Order

Delivered Order Ticket

Daily Delivery Order Details Delivered Order Receipts

Delivered Order Receipts

Delivery Orders

Daily Delivery Orders

Delivery Goods Sold Adjustments

5.4 Reconcile Delivery Orders with Payments

Goods Sold File

5.3 Update Goods Sold File and Inventory File Updated Inventory Data Reflecting Delivery Deletions

Inventory File

De

liv e

ry

Pa y

me

De

liv e

ry

nt/ Or de r

Or de r

Tic k

et

Re

ce

ipt

5.2 Deliver Order

Customer Reconciled Delivery Orders Report

To Process 4

d. Exchange your diagrams with those of another class member. Ask your classmate to review your diagrams for completeness and consistency.

What errors did he or she find? Correct these errors.

Encourage students to review the data-flow diagramming rules presented in Table 6–2. Using these rules as a guide, students should then evaluate their classmate’s diagrams.

.

Chapter 6

Structuring System Requirements: Process Modeling

6-36. Evergreen Nurseries Case Exercises Solutions a. Construct a context data-flow diagram, illustrating Evergreen Nurseries’ wholesale system.

Student interpretations will vary. A suggested answer follows.

Context-Level Evergreen Nurseries, PartDiagram a Context Level Diagram

Product Availability Report

Wholesale Order

Customer

Pa ym en tO

n

Order Cost and Applicable Discounts

Ac co un t

Product Availability Response

Packing Slip

Order Status Response 0 Evergreen Nurseries

Credit Approved/ Disapproved Response

Customer Order Status Request

Repo

rt

Monthly Statement

Query

Manager

.

28

Chapter 6

Structuring System Requirements: Process Modeling

29

Construct a level-0 diagram for Evergreen Nurseries’ wholesale system.

b.

Student interpretations will vary; a suggested answer follows.

Evergreen Nurseries, Part b

Level-0 Diagram Level-0 Diagram Wholesale Order Order Status Response Order Status Request Product Availability Response

Placed Wholesale Order 1 Receive Order

Product Availability Request

Inventory Status Request

3 Adjust Inventory

Item On Reserve

Backorder

Inventory

Orders

Outstanding Orders

Item Availability

Up da te Ac d C co us un to t me r

Customer’s Current Standing

Customer Credit Check Request

Placed Wholesale Order

Customer Information

Monthly Statement

Payment on Account

Credit Approved/Disapproved Response

Customers

4 Generate Reports

2 Verify and Update Customer Accounts

Customer

Packing Slip

Backorder Request

Inventory Information

Order Cost and Applicable Discounts

Customer’s Updated Balance

Customer

Report Manager Query

.

Chapter 6

Structuring System Requirements: Process Modeling

30

c.

Using the level-0 diagram that you constructed in part b, select one of the level-0 processes, and prepare a level-1 diagram.

A suggested answer is provided below.

Evergreen Nurseries, Part c Level-1 Diagram

Level-1 Diagram Order Status Response

Order Status Request Product Availability Request

Order Costs and Applicable Discounts Wholesale Order

To Process 3

Backorder Request Placed Wholesale Order Customer Credit Check Request

Appropriate Discount

To Process 2

Inventory Status Request

Order Status

To Process 3 To Process 3

1.3 Check Order Status

1.1 Process Order

1.2 Determine Discount

Customers

Orders

Cu sto me rC od e

Customer

Available Discounts

Discounts

d. Exchange your diagrams with those of another class member. Ask your classmate to review your diagrams for completeness and consistency.

What errors did he or she find? Correct these errors.

Encourage your students to review the data-flow diagramming rules presented in Table 6–2. Using these rules as a guide, your students should then evaluate their classmates’ diagrams.

.

Chapter 6

Structuring System Requirements: Process Modeling

31

Petrie’s Electronics Case Questions Solutions 6-37. Are the DFDs in Figures 6-1 and 6-2 balanced? Show that they are, or are not. If they are not balanced, how can they be fixed?

They are balanced. On both the Context Diagram and the Level-0 there are 2 inflows to the system from the source customer (purchases and coupons) and three outflows (reports, tailored promotions and coupons) from the system to the sink Customer.

6-38. Decompose each of the core processes in Figure 6-2 and draw a new DFD for each core process.

There will be four parts to this answer, one for each of the core processes in Figure 6-2. The answers will vary with each student. What’s important in each decomposition diagram is that it contains the same inputs and outputs for the diagram as are shown as inputs and outputs to the process in Figure 6-2. For example, for the first process, “Record customer activities,” there will be two inputs coming from outside, coupons and purchases, and one output to the outside, transactions. There may be two or more sub-processes on each decomposition diagram. For example, for the process “Record customer activities,” there may be one sub-process for purchases and another for coupons. If the core process cannot e decomposed, there is no need for decomposition.

PE Figure 6-3: Level-1.1 Record Customer Activities

.

Chapter 6

Structuring System Requirements: Process Modeling

PE Figure 6-4: Level-2.1 Send Promotions

PE Figure 6-5: Level-3.1 Generate Point Redemption Coupons

PE Figure 6-7: Level-4.1 Generate Customer Reports

.

32

Chapter 6

Structuring System Requirements: Process Modeling

33

6-39. Has the team overlooked any core processes in the system that should be in Table 6-1 and Figure 6-2? What would they be? Add them to Table 6-1 and Figure 6-2.

The answer will vary with the student. The question is intended to generate some creativity on the part of the student. They may also come up with some additional functions (core processes) from further research on loyalty programs and their operations.

6-40. Redesign Figures 6-1 and 6-2 so that they are clearer and more efficient and more comprehensive.

Again, the answer will vary with the student.

6-41. Why is it important for the team to create DFDs if they are not going to write the actual system code themselves?

Creating DFDs force analysts (and students) to think about the core processes in a system, the data they use, the sources of that data, the information the processes generate, and where the information goes. All of this information is essential in design and building of a system, even if all of its components are purchased off-theshelf.

.

Chapter 6

Structuring System Requirements: Process Modeling

.

34

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

1

Chapter 7 Structuring System Requirements: Conceptual Data Modeling Chapter Overview Chapter 7 presents the techniques used to structure the data requirements for an information system application. This chapter emphasizes entity-relationship (E-R) diagramming; the most common notation used by practicing systems and data analysts.

This chapter explains how E-R diagramming is used along with process and logic modeling techniques to develop a thorough, unambiguous description of system requirements. In addition to the standard constructs of the E-R model (entities, attributes, and relationships), the data-oriented questions that should be raised during requirements determination are presented.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Emphasize the importance of understanding organizational data and convince students that unless they can represent the data requirements of an application unambiguously in logical terms, they cannot implement a system that will effectively serve the needs of management.

2. Present the E-R model as a conceptual data model that can be used to capture the structure and much (although not all) of the semantics (or meaning) of data in several front-end stages of the systems development process.

3. Show students how data, process, and logic models all represent data requirements, but that conceptual data models (such as E-R diagrams (ERD)) provide a more thorough and stable representation of data than do other types of system structures.

4. Show students, via an example from Hoosier Burger, how to match data requirements from data and process system models. This example emphasizes the differences between data stores and data entities, yet shows how to reconcile process and data models to be sure each model covers all data requirements.

5. Explain to students that conceptual data modeling for an Internet-based electronic commerce application is no different than the processes followed for other applications.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

2

Classroom Ideas 1. This chapter covers a topic addressed in most database management courses.

Depending on your curriculum, this chapter may review previously covered material or may be covered (in more depth) in a subsequent course. We believe that conceptual data modeling is not strictly a database topic, but is essential for thorough systems analysis, thus it is an activity that should not be assigned to only specialists (database analysts). Although you are strongly encouraged to cover this chapter in your systems analysis and design course, it would be good to coordinate how you address this topic with those who teach database courses. This chapter is carefully written for the systems analysis and design student. First, data modeling is presented as a step of the larger systems development process. Second, questions to ask users and to investigate via other requirements determination techniques are introduced, again placing data modeling within the whole systems development effort. Finally, the wording is less technical, and the breadth and depth of coverage has been reduced to make the material more accessible to those who do not have an extensive database background. This chapter is an excellent refresher for those who have already studied E-R modeling and will provide a solid introduction to E–R modeling for those students who will study this topic later in a database course.

2. This is a very detailed chapter, and there are many concepts as well as notations to cover. It is recommended that you devote at least two lecture periods to this chapter, and if possible, schedule a third session that is devoted entirely to working sample exercises with students.

3. It is important to review with students how central a role data modeling and data design play in systems development. Discuss Figure 7–2 with your students and show examples of the types of data models, designs, and code developed in each phase of the systems development process. Discuss who in the organization is most involved in each of these phases and how end users may best participate in the process.

4. Introduce the notation that is used in the chapter for E-R diagrams (Figure 7–5).

Give an example (and then have students give examples) for each of the constructs shown in the figure.

5. Contrast the terms “entity type” and “entity instance.” Discuss other examples, such as STUDENT (with each student in the classroom as an instance). Warn students that the term “entity” is often used either way, with the meaning intended to come from the context in which it is used.

6. Discuss the representation of multivalued attributes and repeating groups in E-R diagrams and give some examples. If students are familiar with programming languages that support arrays and other data structures of repeating data, use this understanding to emphasize the need to separate conceptual from physical data modeling.

7. Discuss relationships and their different degrees (Figure 7–6). Have students develop additional examples.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

3

8. Introduce the concept and notation of cardinalities in relationships. Again, have your students develop additional examples.

9. As a general suggestion, show (develop step-by-step) many examples of small (two to three entities) and larger (eight to ten entities) E-R diagrams in class. Develop these from your own personal experience. Three approaches work well and mixing these is best. One approach is to give students descriptions of an organization and have them identify entities, attributes, and relationships (with degrees and cardinalities). You can do this as a group exercise, asking for volunteers or calling on students in class. The second approach is to show E-R diagrams and ask factual and interpretive questions about the business depicted in the diagram (such as, how many faculty advisors might a student have, or would all universities have only one department associated with each course and why). Yet a third approach is to pair students and have one student in the pair develop an E-R diagram for an exercise you give them, and then have the other student in the pair read the diagram to see if it agrees with the description. Once each pair of students develops a diagram both are satisfied with, have several teams present their diagrams to the class and discuss differences. You can also have students bring in copies of computer system forms and reports and develop E-R models for each.

Some of the Problems and Exercises at the end of the chapter can be used for such in-class practice problems.

10. Unary and ternary relationships can be especially difficult for some students.

Present several examples of each (for unary, for example, a hierarchical organization structure or the relationships between geographical areas or governmental territories; for ternary, for example, a faculty member advising students about majors, or a customer buying products through different sales channels).

11. If you have the time, an exciting way for students to better appreciate conceptual data modeling is to listen to a guest speaker who has developed an enterprise data model for a local organization. Students are usually amazed by how many entities and relationships exist in any reasonably-sized organization (several dozen entities and relationships are common, and models with a hundred entities exist). Such a guest can usually discuss: the difficulties in developing this data model; misunderstandings people had or controversies that existed before the data model was developed; how the data model is being used to guide the development of many new or redesigned systems; and the administrative effort necessary to maintain such a data model (as well as many other topics).

12. We have discovered that students who study process modeling before data modeling often have some difficulties with this chapter. First, students may try to include entities for the sources and sinks for the process model. You must emphasize that data entities have to be described by attributes, and each instance must have a primary key. Further, there will usually be multiple instances. For example, in a data model for a retail store, a student might include the store or the store’s manager as a data entity. Such concepts do not satisfy the definition of a data entity.

Second, students may try to use relationships to represent data flows rather than structural associations between entities. This often occurs when students try to

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

4

model system outputs as entities. For example, some students will create an entity for a major system report (say a monthly sales summary report), and then show a relationship between the customer entity and the report. Emphasize that although copies of the report may be kept on file, system outputs are derived from other data; these data are used to produce any of the system outputs, and hence the outputs are redundant.

Lecture Notes Chapter 7 introduces students to data modeling concepts. Data models show the definition, structure, and relationships within data. Figure 7–1 shows that data modeling is performed during systems analysis. Data modeling is important because: (1) the characteristics of data captured during data modeling are crucial in the design of databases, programs, computer screens, and printed reports; (2) data rather than processes are the most complex aspects of many modern information systems; (3) the characteristics about data are permanent; and (4) structural information about data is essential to generate programs automatically.

Conceptual Data Modeling A conceptual data model is a detailed model that shows the overall structure of organizational data while being independent of any database management system or other implementation considerations. Conceptual modeling is performed during systems analysis, generally at the same time as other requirements analysis and structuring steps. An entity-relationship diagram (E-R) is a commonly used data model, showing how data are organized within an information system. Interviews, questionnaires, and JAD sessions are common techniques used to gather information for conceptual modeling.

A conceptual model is usually built for the existing system, then another conceptual model is prepared for the new system. As Figure 7–2 shows, different kinds of data models and database design occur during the systems development life cycle. For instance, during systems design a logical data model is prepared and physical file and database design is performed; during systems implementation and operation, database and file definitions are prepared, and the data model is evolved. A project repository links the data models and database design.

As Figure 7–3 shows, the entity-relationship diagram is the primary deliverable of conceptual modeling. Conceptual modeling results in as many as four diagrams, including: (1) an E-R diagram that covers just the data needed in the project’s application; (2) an E-R diagram for the application system being replaced; (3) an E-R diagram for the whole database from which the new application’s data are extracted; and (4) an E-R diagram for the whole database from which data for the application being replaced is drawn. Conceptual modeling also produces a set of entries about data objects; these entries are stored in the project repository.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

5

Gathering Information for Conceptual Data Modeling When performing requirements structuring, the analyst must formulate questions and the investigation to include a data focus. These questions identify the rules and policies governing how work is performed. Table 7–1 identifies categories of questions to ask.

Data modeling is performed using both top-down and bottom-up approaches. As Figure 7–4 shows, an analyst uses specific documents to gain a bottom-up perspective of the data.

Introduction to Entity-Relationship Modeling On an E-R diagram, three main constructs are used: data entities, relationships, and their associated attributes. This textbook uses the crow’s foot modeling notation. Figure 7–5 shows the basic E-R diagram notations. An entity is a person, place, object, event, or concept in the user environment about which the organization wishes to maintain data. An entity type is a collection of entities that share common properties, and an entity instance is a single occurrence of an entity. An attribute is a characteristic of an entity.

While a candidate key uniquely identifies each instance of an entity, an identifier is a candidate key that has been chosen as the unique, identifying characteristic for an entity type. When selecting an identifier, apply the following rules: (1) choose a candidate key that will not change its value over the life of each instance of the entity type; (2) choose a candidate key such that, for each instance of the entity, the attribute is guaranteed to have valid values and not be null; (3) avoid the use of intelligent keys; and (4) consider substituting single-attribute surrogate keys for larger composite keys.

The analyst represents a multivalued attribute using a weak entity. an association between instances of one or more entity types.

A relationship is

Conceptual Data Modeling and the E-R Model One of conceptual modeling’s primary goals is to capture as much of the meaning of data as possible. The more information gathered and modeled about these business rules, the better the conceptual design.

The degree of a relationship indicates the number of entity types that participate in a relationship. Figure 7–6 shows three common relationships: unary, binary, and ternary. The cardinality of a relationship is noted on an E-R diagram; both minimum and maximum cardinalities are noted. An associative entity is an entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances. Figures 7–7 and 7–8 provide examples of how to model associative entities.

An Example of Conceptual Data Modeling at Hoosier Burger The Hoosier Burger’s food ordering system example illustrates how to prepare a conceptual data model. Figure 7–9 is the level-0 data flow diagram for Hoosier Burger’s

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

6

new logical inventory control system; Figure 7–10 is the preliminary E-R diagram for Hoosier Burger’s inventory control system; Figure 7–11 is the final E-R diagram for Hoosier Burger’s inventory control system.

Electronic Commerce Application: Conceptual Data Modeling Conceptual data model preparation for an electronic commerce application follows the same approach used for more traditional applications. The authors use Pine Valley’s WebStore as an Internet-based application example for conceptual modeling. Table 7– 2 lists the customer and inventory information for the WebStore; Figure 7–12 shows the level-0 data flow diagram for the WebStore. Tables 7–3 identifies the data flows within each data category; Table 7–4 identifies the unique data flows within each data category. Figure 7–13 shows the WebStore’s E-R diagram.

Matching Questions Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

entity-relationship diagram (11)

10.

identifier (13)

2.

entity instance (10)

11.

relationship (15)

3.

multivalued attribute (14)

12.

candidate key (4)

4.

ternary relationship (17)

13.

degree (7)

5.

entity type (12)

14.

unary relationship (18)

6.

binary relationship (3)

15.

conceptual data model (6)

7.

associative entity (1)

16.

repeating group (16)

8.

attribute (2)

17.

entity (9)

9.

cardinality (5)

18.

design strategy (8)

Review Questions Solutions 7-1. What characteristics of data are represented in an E-R diagram?

An E-R diagram shows many characteristics of data, including the definition, structure, and relationships within data. Additionally, this diagram shows cardinalities, relationship degrees, and business rules.

7-2. What elements of a data flow diagram should be analyzed as part of data modeling?

Data stores, data flows, and even processes all provide information for data modeling. A data store often represents one or more data entities and their associated attributes. All data in data flows must either be stored in some entity, be computed from data in entities, or in rare circumstances pass through the

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

7

system. The description of a process can shed light on business rules that must be represented in the data model.

7-3. Explain why a ternary relationship is not the same as three binary relationships.

A ternary relationship represents the simultaneous association of three entities (such as a selling relationship links a customer with a product and salesperson), not three binary relationships (between a sale entity/associative entity and customer, sale and product, and sale and salesperson).

7-4. When must a many-to-many relationship be modeled as an associative entity?

A many-to-many relationship must be modeled as an associative entity when there are attributes associated with the relationship.

7-5. Which of the following types of relationships can have attributes associated with them: one-to-one, one-to-many, many-to-many?

One-to-one and many-to-many relationships (associative entities) may have attributes. For example, a one-to-one unary relationship between employees, Married to, may have a Date Married attribute, and a many-to-many binary relationship between students and courses, Takes, may have a Grade attribute.

7-6. What is the degree of a relationship? Give an example of each of the relationship degrees illustrated in this chapter.

The degree of a relationship indicates the number of entity types participating in a relationship. The three most common relationships are unary, binary, and ternary.

An employee working for a department is an example of a binary relationship. A part composed of other parts is an example of a unary relationship. A customer placing an order with a salesperson is an example of a ternary relationship.

7-7. Give an example of a ternary relationship (different from any example in this chapter.)

An example of a ternary relationship might be that of a car service. A particular driver and car might be assigned to a particular client.

7-8. List the deliverables from conceptual data modeling.

The primary deliverable for the conceptual modeling part of analysis is an E-R diagram, showing the major categories of data and the business relationships between them. A full set of entries about data objects to be stored in the project repository is also produced.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

8

7-9. Explain the relationship between minimum cardinality and optional and mandatory participation.

Minimum cardinality refers to the minimum number of instances of entity B that can be associated with entity A. If the minimum cardinality of B is one, then entity B is a mandatory participant in the relationship. However, if the minimum cardinality for entity B can be zero, then entity B can be thought of as an optional participant in the relationship.

7-10. List the ideal characteristics of an entity identifier attribute.

An identifier that meets the criteria set forth in the chapter would be an ideal choice. The criteria include: (1) choosing an attribute that will not change its value over the life of each entity type; (2) choosing an attribute that for each instance of the entity will have valid values and will not be null; (3) avoiding intelligent key usage; and (4) substituting surrogate keys for large composite keys.

7-11. List the four types of E-R diagrams produced and analyzed during conceptual data modeling.

E-R diagrams are produced: (1) to cover just the data needed in the project’s application; (2) for the application system being replaced; (3) to document the entire database from which the new application’s data are extracted; and (4) for the whole database from which data for the application being replaced are drawn.

7-12. What notation is used on an E-R diagram to show a lower-bound or upperbound limit on the "many" side of a one-to-many relationship?

A fixed number, such as the number 6, is placed above or below the crow’s foot notation next to the entity.

7-13. Explain the difference between a candidate key and the identifier of an entity type.

A candidate key is an attribute(s) that uniquely identifies each instance of an entity type. An identifier is a candidate key that has been chosen as the unique, identifying characteristic for that entity type.

7-14. What distinguishes a repeating group from a simple multivalued attribute?

A multivalued attribute is a single attribute that may legitimately assume more than one value for each entity instance. A repeating group is a set of two or more multivalued attributes that are logically related.

7-15. How do analysts generate alternative solutions to information systems problems?

Analysts consider many issues in developing alternative solutions to information system problems. Of particular interest are the system owner’s and users’ prioritized system objectives and system (and development) constraints. Analysts consider which design strategies would minimally satisfy objectives and not violate constraints, on the one hand, as well as which design strategies would meet or exceed objectives with minimal violation of constraints on the other hand. There are many possible design strategies between these two extreme positions.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

9

7-16. How do managers decide which alternative design strategy to develop?

While alternative design strategies may be compared in many different objective ways, the actual design strategy chosen by management will depend on what management’s true objectives are for a particular development project.

Management may ignore constraints, or alternatively, choose the least expensive system to develop, regardless of which design strategy appeared to be the best in the objective comparison.

Problems and Exercises Solutions 7-17. Assume that at Pine Valley Furniture each product (described by Product No., Description, and Cost) is comprised of at least three components (described by Component No., Description, and Unit of Measure) and components are used to make one or many products (i.e., must be used in at least one product). In addition, assume that components are used to make other components and that raw materials are also considered to be components. In both cases of components being used to make other components, we need to keep track of how many components go into making something else. Draw an E-R diagram for this situation and place minimum and maximum cardinalities on the diagram.

This is a version of a bill-of-materials structure in which components are different entities from products, but raw materials are considered components. The exercise also indicates a minimum cardinality of three for the number of components composing a product, but no such restriction is placed on components as part of other components. Microsoft Visio was used to prepare this answer.

PE # 1 Product PK

Component

Product No

PK

Cost P_Description

ComponentNo C_Description UnitOfMeasure

Comprised Of

3

PK,FK2,I2 PK,FK1,I1

GoesInto

Product No Component No

PK,FK1,I1 PK

C_Quantity

ComponentNo SubComponentNo Quantity

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

10

7-18. A performance venue hosts many concert series a year. Performers have a name and perform several times in a concert series (each constituting a performance with a different date). Concert series have one or more performers and have a name and a specified seating arrangement. A concert series is held in one (and only one) of several concert halls, each of which has a room number. Represent this situation of concerts and performers with an E-R diagram.

Performer Performer_ID Name

Performance Performer_ID Series_ID Date

Concert_Series Series_ID Name Seat_Setup

Concert_Hall Concert_Hall_ID Room#

7-19. A restaurant chain has several store locations in a city (with a name and zipcode stored for each), and each is managed by one manager. Managers manage only one store. Each restaurant location has its own unique set of menus. Most have more than one menu (e.g., lunch and dinner menus).

Each menu has many menu items, and items can appear on multiple menus, and with different prices on different menus. Represent this situation of restaurants with an E-R diagram.

Restaurant Restaurant_ID Name zipcode

Manager Manager_ID Name

Menu Menu_ID Type

Menu_Menu_Item Menu_ID Menu_Item_ID Price

Menu_Item Menu_Item_ID Name

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

11

7-20. Consider the E-R diagram in Figure 7-7. a. What is the identifier for the CERTIFICATE associative entity? b. Now, assume that the same employee may take the same course multiple times, on different dates. Does this change your answer to part a? Why or why not? c. Now, assume we do know the instructor who issues each certificate to each employee for each course. Include this new entity in Figure 7-7 and relate it to the other entities. How did you choose to relate INSTRUCTOR to CERTIFICATE and why?

The identifier is a combination of Employee_ID and Course_Name. If an employee is permitted to take the course multiple times, then the identifier is no longer unique. Therefore, another identifier will need to be specified. The new identifier could be a combination of Employee_ID, Course_Name, and Date.

Students will also specify other identifiers for this situation. The inclusion of the INSTRUCTOR entity would make this a ternary relationship. The INSTRUCTOR entity would have a mandatory one cardinality. The identifier for the CERTIFICATE associative entity would be a combination of Employee_ID, Course_Name, InstructorID, and possibly Date.

7-21. Consider the E-R diagram of Figure 7–20. Based on this E-R diagram, answer the following questions: a. How many PROJECTs can an employee work on?

This is a many-to-many relationship, so any number of employees can work on a project. b. What is the degree of Used_on relationship?

Two (Binary). c. Do any associative entities appear in this diagram? If so, name them.

No. d. How else could the attribute Skill be modeled?

This attribute could be modeled as a separate entity, to which task would be related. e. Is it possible to attach any attributes to the Works_on relationship?

Attributes such as begin_date, end_date, or performance_rating would be appropriate attributes. f.

Could TOOL be modeled as an associative entity?

No. Tool is in a one-to-many relationship, and associative relationships only occur in many-to-many relationships.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

12

7-22. A car rental is an association between a customer, sales agent, and a car.

Select a few pertinent attributes for each of these entity types and represent a rental in an E-R diagram.

Sales_Agent Agent_ID Name Salary

Customer Customer_ID Name Phone#

Car Car_ID Make Model Year

Rental Begin_date End_date

7-23. Consider the E-R diagram in Figure 7–21. Are all three relationships— Holds, Goes_on, and Transports—necessary (i.e., can one of these be deduced from the other two)? What, if any, reasonable assumptions make all three relationships necessary?

A vessel holds potentially many consignments, and a consignment is on at most one vessel, which probably means that Holds tracks the consignments currently held on a vessel (and the vessel, if any, which currently holds a consignment).

A vessel goes on potentially many voyages, but a voyage involves only one vessel. The Transports relationship says that a consignment is transported on zero to many voyages (which may involve the same or different vessels), and a voyage transports zero to many consignments.

Given that a consignment might be on many voyages, and even though each voyage involves exactly one vessel, we do not know from just Transports and Goes_on which vessel a consignment is currently on (there are no attributes from which to infer this).

Thus, it would appear that we need all three relationships.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

13

7-24. Draw an E-R diagram to represent the sample customer order in Figure 7-4.

A suggested answer is provided below. The following E-R diagram was created with Microsoft Visio.

7-25. A company database contains an entity called EMPLOYEE. Among other information, the company records information about any degrees each employee has earned, along with the graduation date for the degree. a. Represent the EMPLOYEE entity and its degree attributes using the notation for multivalued attributes.

Employee Emp_ID Name {Degree, Date_earned}

b. Represent the EMPLOYEE entity and its degree attributes using two entity types.

Employee Emp_ID Name

Degree Deg_ID Name Date_earned

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

14

c. Finally, assume the company decides to also keep data about the institution from which the employees’ degrees were earned, including name of institution, city, and state where the institution is located.

Augment you answer to part b to accommodate this new entity type.

Employee Emp_ID Name

Degree Deg_ID Name Date_earned

Institution Institution_ID Name City State

7-26. Consider the Is_married_to unary relationship in Figure 7-6. a. Draw minimum and maximum cardinalities for each end of this relationship. b. Assume we wanted to know the date on which a marriage occurred.

Augment this E-R diagram to include a Date_married attribute. c. Because persons sometimes remarry after the death of a spouse or divorce, redraw this E-R diagram to show the whole history of marriages (not just the current marriage) for persons. Show the Date_married attribute on this diagram.

Suggested answers are provided below. Microsoft Visio was used to prepare the following answers.

For 7-26a and b: Person

Wedding

Is Married to / PK

Married /

.

Date Married

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

For 7-26c: Person

Wedding

Is Married to / PK

Date Married

Married /

7-27. Draw an E-R diagram for each of the following situations. (The scenarios are provided in the textbook.)

Suggested answers are provided below. The ERDs were prepared using Microsoft Visio.

.

15

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

16

Problem and Exercise #11, Part b

Course PK

Section

Course_ID

PK PK PK

Course_Name Units

Course_ID Section_No Semester_ID

7-28. Re-create the spreadsheet in Figure 7–19 in your spreadsheet package.

Change the weights and compare the outcome to Figure 7–19. Change the rankings. Add criteria. What additional information does this “what if” analysis provide for you as a decision maker? What insight do you gain into the decision-making process involved in choosing the best alternative system design?

In the first accompanying spreadsheet, the weights have been changed to reflect a weighting that represents systems development projects in governmental agencies. In these settings, a great deal of weight is given to the costs and time frame of the system being proposed. As often happens in governmental agencies, by weighting costs and timing more heavily in this example the outcome has changed. Alternative A and Alternative C have traded places; Alternative A now has the highest score. By changing the weighting, we may have just traded the more technically proficient solution for the more cost-effective solution (at least in terms of “short term” costs).

The second accompanying spreadsheet reflects changes in the ratings of Alternative B. With slight improvements in the ratings for this alternative, it now has the highest score. This shows how important the ratings can be and how subtle changes and/or biases in ratings can have significant impacts on the final outcome.

The third spreadsheet has the additional criteria of “references” and “in use”.

“References” are written references from other organizations currently using the vendor’s systems. “In use” means that the technology proposed must have been in use by a paying customer for six months. These are very common criteria for organizations that value stability of the vendor, technology over performance, and having state-of-the-art technology. These additional criteria change the outcomes; Alternative B now has the highest score. These changes appear to have caused the more stable vendor (i.e., the vendor with the better references and the track record for using the technology it has proposed) to be chosen over the vendor who scored higher on other performance indicators.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

17

7-29. The method for evaluating alternatives used in Figure 7–19 is called weighting and scoring. This method implies that the total utility of an alternative is the product of the weights of each criterion times the weight of the criterion for the alternative. What assumptions are characteristic of this

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

18

method for evaluating alternatives? That is, what conditions must be true for this to be a valid method of evaluation alternatives?

For this method of evaluation to be valid, one assumes that all relevant criteria are known and included and that the weights and ratings are accurate. More important, this method assumes that the alternatives and criteria lend themselves to a quantitative analysis. Some people argue that some parts of the analysis inherently cannot be quantified. For example, it is difficult to truly rate and weight the amount of trust that you can place in a vendor and your belief that they will indeed follow through on their claims. Further, this method assumes that the criteria are independent of each other, and thus scores are additive.

7-30. Weighting and scoring (see Problem and Exercise 7-29) is only one method for comparing alternative solutions to a problem. Go to the library, find a book or articles on qualitative and quantitative decision making and voting methods, and outline two other methods for evaluating alternative solutions to a problem. What are the pros and cons of these methods compared to the weighting and scoring method? Under weighting and scoring and the other alternatives you find, how would you incorporate the opinions of multiple decision makers?

One other quantitative method for choosing between alternative systems is to choose almost exclusively based on cost. This may seem far-fetched, but in most state and federal agencies information systems are chosen this way. People in these agencies are often forced by law to choose the least expensive system that meets some minimum level of adequacy for the relevant information system needs. Indeed, many states and parts of the federal government are attempting to change this method of awarding governmental contracts. One other more qualitative method often used is to choose the vendor that not only supplies the necessary system but also provides the best value-added services and components. For example, many companies will choose a vendor that, in addition to the basic system, is willing to supply additional training, free components, less expensive maintenance, or has offered to enter into a strategic partnership that is of mutual benefit to both companies.

When multiple decision makers collaborate and make the decision together, there are several methods for incorporating their interactive input. For example, for a quantitative analysis such as that presented in Figure 7–8, each decision maker first enters her ratings for each alternative across each criterion. The data are then summarized using a spreadsheet, and the average and/or summary rating across all decision makers is used to choose a vendor. In addition, group support systems can tally the individual, anonymous ideas, comments, and/or votes of multiple, collaborating decision makers. Because there are many multi-criteria decision-making methods (e.g., another popular one uses pairwise comparisons), students may come up with many alternatives for this question.

7-31. Prepare an agenda for a meeting at which you would present the findings of the analysis phase of the SDLC to Bob Mellankamp concerning his request for a new inventory control system. Use information provided in Chapters 5 through 7 as background in preparing this agenda. Concentrate on which topics to cover, not the content of each topic.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

19

Basically, students should include in the meeting the deliverables from the three major subphases of analysis: requirements determination, requirements structuring, and alternative generation and selection. Some other key issues that must be decided are who else to invite to the meeting, the level of detail to present to Bob Mellankamp, and, subsequently, how long the meeting should last.

The meeting should not only summarize the findings from analysis but also validate these findings by outlining the process followed. An updated BPP should be covered. Without more information, it may be difficult for the students to decide on these other key issues. Have them identify the information that would be needed to decide on these issues. For example, they may want to know more about Mellenkamp’s personality and preferences before deciding.

7-32. The owner of two pizza parlors located in adjacent towns wants to computerize and integrate sales transactions and inventory management within and between both stores. The point-of-sale component must be very easy to use and flexible enough to accommodate a variety of pricing strategies and coupons. The inventory management, which will be linked to the point-of-sale component, must also be easy to use and fast. The systems at each store need to be linked so that sales and inventory levels can be determined instantly for each store and for both stores combined.

The owner can allocate $40,000 for hardware and $20,000 for software and must have the new system operational in three months. Training must be very short and easy. Briefly describe three alternative systems for this situation and explain how each would meet the requirements and constraints. Are the requirements and constraints realistic? Why or why not?

Some basic system alternatives include: (1) build the system in-house using a programming language such as C or Microsoft Visual Basic; (2) purchase off-the-shelf packages, such as Microsoft Excel and Access, along with the necessary computer and telecommunications equipment, and use these to build the necessary systems in-house; (3) purchase custom software and a turn-key system from either a generic information systems consulting firm or from a specialized systems provider for the food retail or pizza retail industry; and (4) outsource the systems to an outside firm.

Each of these alternatives has unique advantages and disadvantages. Given that the system needs to be stable, easy to use, and built relatively quickly, and given that this organization probably has little or no in-house systems personnel, the third and fourth alternatives are most realistic.

7-33. Compare the alternative systems from Problem and Exercise 7-32 using the weighted approach demonstrated in Figure 7–19. Which system would you recommend? Why? Was the approach taken in this and Problem and Exercise 7-32 useful even for this relatively small system? Why or why not?

It will be useful for students to create a spreadsheet like the one presented in Figure 7–19. They should list in the criteria category each of the requirements and constraints described in the problem, plus any others that they believe are relevant. As best they can, have them weigh each of these criteria and use them to rank each of the four alternatives presented in the previous answer. They may have to make some assumptions to complete each of the ratings. This method of

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

20

analysis should be useful even for this relatively small system. The method will force the decision maker to flesh out relevant criteria and weighting and be as objective as possible in rating each alternative on each criterion.

7-34. Suppose that an analysis team did not generate alternative design strategies for consideration by a project steering committee or client. What might the consequences be of having only one design strategy? What might happen during the oral presentation of project progress if only one design strategy is offered?

Having only one design strategy can be problematic in several ways. First, there will be no guarantee that the best, the correct, or even an adequate system for the situation is being developed or purchased. This is not obvious because it is unclear if other alternatives were considered, and if they were, those present cannot see why the one choice won out. Second, if the one strategy is because only one vendor is used, there are no benefits from having multiple vendors compete for an RFP. For example, the vendor has no incentive to keep its price as low as possible. Third, without the detailed, public systems specifications that are part of a competitive bid process, there is not likely to be much in the way of written documentation to refer back to if the vendor does not fulfill its promises. If the analysts present only one design strategy during the oral presentation to the project steering committee or client, the recommendations are likely to be (at worst) rejected, or (at best) accepted with great skepticism. It is also possible that those present at the meeting will start to generate alternatives, each representing that person’s position. The meeting will likely quickly deteriorate since a fair assessment of ad hoc alternatives cannot be done within the limits of a meeting.

In any event, this is not a good way to begin the development of an information system (or to build a career).

7-35. Assume you are designing a database for a local used car dealership.

Attributes for a car include the vehicle identification number, stock number, make, model, year, and trim. What would you use for the primary key in this entity? What attributes are likely to be foreign keys associated with other entities?

Either the stock number or vehicle identification number could be used as the primary key. Make, model, and trim are likely to be foreign keys associated with other entities.

Discussion Questions Solutions 7-36. Discuss why some systems developers believe that a data model is one of the most important parts of the statement of information system requirements.

Four reasons were provided in the textbook: (1) the characteristics of data captured during data modeling are crucial in the design of databases, programs, computer screens, and printed reports; (2) data rather than processes are the most complex aspects of many modern information systems; (3) the

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

21

characteristics about data are permanent; and (4) structural information about data is essential to generate programs automatically.

7-37. Using Table 7–1 as a guide, develop a script of at least ten questions you would ask during an interview of the customer order processing department manager at Pine Valley Furniture. Assume the focus is on analyzing the requirements for a new order entry system. The purpose of the interview is to develop a preliminary E-R diagram for this system.

Students should identify numerous questions to ask Pine Valley Furniture’s manager. Students should design their questions to collect information about data entities, candidate keys, attributes and secondary keys, security controls, cardinalities and time dimensions of data, relationships, and integrity rules.

Possible questions include: (1) What data are maintained by the customer ordering system? (2) How do you distinguish each customer record from every other customer record? (3) What information do you collect about each customer? (4) Does this information differ if the customer is new, as opposed to a repeat customer? (5) What information do you keep about each order? (6) Who has access to customer records? (6) Is there a limit to the number of outstanding orders a customer can have at any one time? (7) How long do you keep customer information? (8) What are the return policies for products? (9) What types of reports do you use? (10) Who can modify the customer, order, and/or product data?

7-38. If possible, contact a systems analyst in a local organization. Discuss with this systems analyst the role of conceptual data modeling in the overall systems analysis and design of information systems at his or her company.

How, and by whom, is conceptual data modeling performed? What training in this technique is given? At what point(s) is this done in the development process? Why? The answer to this question depends on the organization that the student chooses to contact. Encourage students to investigate how the systems analyst’s conceptual modeling role in a small organization will vary as opposed to his role in a much larger organization.

7-39. Talk to MIS professionals at a variety of organizations and determine the extent to which CASE tools are used in the creation and editing of entityrelationship diagrams. Try to determine whether or not they use CASE tools for this purpose; which CASE tools are used; and why, when, and how they are used. In companies that do not use CASE tools for this purpose, determine why not and what would have to change in order to use them.

The answer to this question is dependent to a degree on the organization contacted. The systems analysts who use CASE tools for conceptual modeling will probably mention the ease with which CASE tools facilitate the preparation of the model and modifications that are made to the model as it evolves. Also, the ability to link the data objects stored in the project repository is of significant benefit.

7-40. Ask a systems analyst to give you a copy of the standard notation he or she uses to draw E-R diagrams. In what ways is this notation different from

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

22

notation in this text? Which notation do you prefer and why? What is the meaning of any additional notation?

Many articles discussing various data modeling notations are available on the Web. As an alternative to contacting a systems analyst, you can ask students to locate one or more of these standard notations and then compare and contrast these notations. If time permits, you may even have students present their findings to the class.

7-41 .Consider the purchase of a new PC to be used by you at your work (or by you at a job that you would like to have). Describe in detail three alternatives for this new PC that represent the low, middle, and high points of a continuum of potential solutions. Be sure that the low-end PC meets at least your minimum requirements and the high-end PC is at least within a reasonable budget. At this point, without quantitative analysis, which alternative would you choose?

Because pricing and capabilities change rapidly, ask students to visit the Web sites of several vendors, including Compaq, IBM, Gateway, and Dell. For discussion purposes, three alternatives are presented below; however, please note that the information provided in this answer will need to be updated each semester.

Low-end alternative: 2.4GHz Intel Celeron processor, 256MB of RAM, 40GB hard drive, 17" monitor, Microsoft Windows XP Home Edition, Microsoft Office 2003 Standard Edition. Cost is about $800.

Mid-range alternative: 2.8GHz Intel Pentium 4 processor, 256MB of RAM, 60GB hard drive, 17" flat panel monitor, Microsoft Windows XP Home Edition, Microsoft Office 2003 Professional Edition. Cost is about $1,200.

High-end alternative: 3.2GHz Intel Pentium 4 processor, 512MB of RAM, 160GB hard drive, 21" flat panel, Microsoft Windows XP Professional, Microsoft Office 2003 Small Business Edition. Cost is about $2,600.

7-42. For the new PC described, develop ranked lists of your requirements and constraints as displayed in Figure 7–19. Display the requirements and constraints, along with the three alternatives, as done in Figure 7–19, and note how each alternative is rated on each requirement and constraint.

Calculate scores for each alternative on each criterion and compute total scores. Which alternative has the highest score? Why? Does this choice fit with your selection in the previous question? Why or why not?

The spreadsheet below presents the quantitative analysis for the three alternatives described in the previous answer. Speed, storage, ease of use, reliability, costs, and time to operation were the criteria used. The mid-range alternative has the highest score because it has acceptable rankings for the performance-oriented criteria and scores well on the highly weighted criteria of costs. As is often the case, people often buy more technology than they really need. The counter argument is that, for PCs, one should buy as much power as they can reasonably afford so the technological life of their equipment is longer, and they will be better able to take advantage of new software as it becomes

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

23

available.

PC Comparison Weighted Approach Spreadsheet Weight Requirements

2.4GHz Intel Celeron

2.8GHz Intel Pentium 4

Rating Score

Rating

3.2GHz Intel Pentium 4

Score

Rating

Score

Speed

15

3

45

4

60

5

75

Storage

15

3

45

4

60

5

75

Ease of Use

15

4

60

5

75

5

75

Reliability

15

4

60

5

75

5

Total

60

Constraints Costs

25

5

125

4

100

2

15

5

75

5

75

5

Time to Operation

210

270

75 300 50 75

Total

40

200

175

125

Weighted Score

100

410

445

425

Case Problems Solutions 7-43. Pine Valley Case Exercises Solutions a. What entities are identified in the above scenario? Can you think of additional entities? What interrelationships exist between the entities?

Customers, orders (purchases), and inventory (items) are mentioned in the scenario. Closely associated to purchase activity are sales promotions. A customer may respond to zero or more promotions; a promotion is associated with one or more products; an inventory item (product) is contained on zero or more orders; a customer may have zero or more outstanding orders. b. For each entity, identify its set of associated attributes. Specify identifiers for each entity.

Several suggested attributes for each entity are provided below. Mention that this information will be normalized at some point during analysis, resulting in the creation of new entities and the identification of new attributes.

CUSTOMER_PROFILE(CustomerID, Name, Primary Address, Alternative Address, Phone, Fax, BuyerName, E-mail Address, School Affiliation, DOB, Gender, FirstPurchaseDate, AnnualIncome, CustomerType, MaritalStatus, Occupation, Dependents, InitialContact) INVENTORY(SKU, ProductName, Description, Material, Color, Price, Lead Time) ORDER(OrderNumber, OrderDate, CustomerID, ShipDate) PROMOTION(PromotionNumber, PromotionDescription, BeginningDate, EndingDate)

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

24

c. Based on the case scenario and your answers to parts a and b, prepare an entity relationship diagram. Be sure to specify the cardinalities for each relationship.

A suggested answer is provided below. The following diagram was prepared using Microsoft Visio. The suggested answer includes three additional entities (SelectedPromotion, PromotedItem, and OrderDetails). Discuss why these additional entities might be necessary with your students. d. How does this conceptual model differ from the WebStore’s conceptual model?

Both systems share data about customers, orders, and inventory. However, these systems also require unique data (attributes) about each entity.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

25

Pine Valley Furniture, Part c

Customer Profile PK,I1

Name Primary Address Alternative Address Phone Fax BuyerName EmailAddress SchoolAffiliation DOB Gender FirstPurchaseDate AnnualIncome CustomerType MaritalStatus Occupation Dependents InitialContact

Promotion PK

PromotionNumber PromotionDescription BeginningDate EndingDate

SelectedPromotion PK,FK1,I2,I1 PK,FK2,I3,I4

CustomerID

CustomerID PromotionID Inventory Order PK PK,FK1,I1

OrderNumber CustomerID OrderDate ShipDate

OrderDetails PK,FK2,I2,I3 PK,FK2 PK,FK1,I1

OrderID CustomerID SKU Quantity

PromotedItem PK,FK2,I2 PK,FK1,I1

PromotionNumber SKU

.

PK

SKU ProductName Description Material Color Price LeadTime

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

26

7-44. Hoosier Burger Case Exercises Solutions a. Based on the information provided in the case scenario, what entities will Hoosier Burger need to store information about?

As illustrated in Figure 7–10, Hoosier Burger currently stores information about its sales, item sales, products, recipes, inventory items, invoice items, and invoices.

The new delivery system will require information about charges, delivery customers, and order histories. b. For the entities identified in part a, identify a set of attributes for each entity.

A suggested answer is provided below.

SALE(ReceiptNumber, SaleDate, Delivery) ITEMSALE(ProductID, ReceiptNumber, QuanitySold) PRODUCT(ProductID, ProductDescription) RECIPE(ItemNumber, ProductID, QuantityUsed) INVENTORYITEM(ItemNumber, ItemDescription, QuantityinStock, TypeofItem, MinimumOrderQuantity) INVOICE_ITEM(ItemNumber, VendorID, InvoiceNo, QuantityAdded) INVOICE(VendorID, InvoiceNo, InvoiceDate, Paid?)

CHARGE(ReceiptNumber, CustomerID, Amount, Date) CUSTOMER(CustomerID, BillingAddress, DeliveryAddress, PhoneNumber, FaxNumber) ORDER_HISTORY(CustomerID, ReceiptNumber) c. Specify an identifier for each entity. What rules did you apply when selecting the identifier?

The identifiers are noted in the previous answer. Four rules were mentioned in the chapter; these include: (1) choosing a candidate key that will not change its value over the life of each instance of the entity type; (2) choosing a candidate key such that, for each instance of the entity, the attribute is guaranteed to have valid values and not be null; (3) avoiding the use of intelligent keys; and (4) considering the substitution of single-attribute surrogate keys for larger composite keys. d. Modify Figure 7–10 to reflect the addition of these new entities. Be sure to specify the cardinalities for each relationship.

A suggested answer is provided below. Microsoft Visio was used to prepare the E-R diagram.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

27

Hoosier Burger, Part d

Product PK,I1

ProductID ProductDescription

Sale PK

ReceiptNumber SaleDate Delivery?

Customer PK,I1

CustomerID BillingAddress DeliveryAddress PhoneNumber FaxNumber

ItemSale PK,FK1,I1 PK,FK2,I2

ProductID ReceiptNumber QuantitySold

OrderHistory PK,FK1,I2,I1 PK

CustomerID ReceiptNumber

Charge PK,FK2,I3 PK,FK1,I2,I1

ReceiptNumber CustomerID

Recipe PK,FK1,I1 PK,FK2,I2

Amount ChargeDate

QuantityUsed

InventoryItem PK

Item_Number Item_Description Quantity_In_Stock Type_of_Item Minimum_Order_Quantity

InvoiceItem PK,FK1,I1 PK,FK2,I2 PK,FK2

ItemNumber VendorID InvoiceNo Quantity

.

ItemNumber ProductID

Invoice PK,I2 PK,I1

VendorID InvoiceNo InvoiceDate Paid?

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

28

7-45. Corporate Technology Centers Case Exercises Solutions a. What entities are identified in the above scenario? Can you identify additional entities?

The primary entities are course, staff, location, and student. Reinforce to students that these entities will be normalized in a later chapter. b. For each entity identified in part a, specify a set of associated attributes.

A suggested answer is provided below.

COURSE(CourseID, CourseName, CourseDescription) STAFF(StaffID, FirstName, LastName, EmploymentDate, HomePhone, StreetAddress, City, State, Zip, OfficeExtension) LOCATION(LocationID, StreetAddress, City, State, Zip, BuildingNo, RoomNo, Comments) STUDENT(SID, CorporateAffiliation, FirstName, LastName, Phone, StreetAddress, City, State, Zip) PREREQUISITECOURSE(CourseID, PrereqCourseID) CURRENTCOURSE(CourseID, SID, LocationID, StaffID, BeginningDate, EndingDate, StartTime, EndTime, Comments) QUALIFIEDCOURSES(StaffID, QualifiedCourseID, Comments, TaughtClassBefore?) c. Select an identifier for each entity. What rules did you apply when selecting the identifier?

The identifiers are noted in the previous answer. The rules discussed in the chapter are: (1) choosing a candidate key that will not change its value over the life of each instance of the entity type; (2) choosing a candidate key such that, for each instance of the entity, the attribute is guaranteed to have valid values and not be null; (3) avoiding the use of intelligent keys; (4) considering the substitution of single-attribute surrogate keys for larger composite keys. d. Based on the case scenario and your answers to a, b, and c, prepare an entity relationship diagram. Be sure to specify the cardinalities for each relationship.

Several students may identify a higher degree relationship for location, course, and staff. Although students will need to make several assumptions, a simple, suggested entity relationship diagram is provided below. Microsoft Visio was used to prepare the following E-R diagram.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

29

Corporate Technology Centers, Part d

Course PK,U1

CourseID CourseName CourseDescription

Staff Student PK,I1

PK,I1

PrerequisiteCourse

StaffID

SID FirstName LastName EmploymentDate HomePhone StreetAddress City State Zip OfficeExtension

CorporateAffiliation FirstName LastName Phone StreetAddress City State Zip

CurrentCourse PK,FK1,I1,I2 PK,FK4,I5,I8 PK,FK2,I4,I3 PK,FK3,I6,I7

Location

PK,FK1,I2,I1

CourseID

LocationID

I3

PrereqCourseID

PK,I1

StreetAddress City State Zip BuildingNo RoomNo Comments

QualifiedCourses

CourseID SID LocationID StaffID

PK,FK1,I2,I1 PK,U1

StaffID QualifiedCourseID Comments TaughtClassBefore?

BeginningDate EndingDate StartTime EndTime Comments

7-46. Pine Valley Furniture Case Exercises Solutions a. Generally speaking, what alternative design strategies were available to Pine Valley Furniture?

Table 7–5 identifies requirements, constraints, and three alternatives for the new system, but does not specify how the alternatives are sourced. However, the case does suggest that in-house development is the best option.

Pine Valley Furniture has six potential sources of software; these include hardware manufacturers, packaged software producers, custom software producers, enterprise-wide solutions, application service providers, and in-house development. The most likely candidates are custom software producers and inhouse development. Because of the marketing group’s unique information needs, the most likely alternative design strategy will probably involve in-house development and be designed to work with the company's existing platform. If you have the class time, encourage your students to research different, specific design strategies that might be beneficial for Pine Valley. Then ask your students to update the information provided in Tables 7–5 and 7–6. b. Of the alternative design strategies available to Pine Valley Furniture, which were the most viable? Why?

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

30

As mentioned above, the most likely candidates are custom software producers and in-house development. The marketing group’s unique information needs require custom software development, requirements unlikely provided by hardware manufacturers, packaged software developers, application service providers, or enterprise-wide solutions. Additionally, the competitive nature of this new system may necessitate in-house development. It appears from the weighted approach (prepared in Part c), that Alternative C is the best choice. c. Using the information provided in Table 7–6, calculate the scores for each alternative.

A suggested answer is provided below.

d. Based on the information provided in Tables 7–5 and 7–6, which alternative do you recommend?

Based on the weighted factor approach, Alternative C appears to be the best choice. However, this alternative requires $350,000 to develop, incurs $100,000 in hardware costs, and requires 9 months to operation. Alternative B has a slightly lower rating, but requires only $200,000 to develop, incurs $80,000 in hardware costs, and requires 7 months to operation.

7-47. Hoosier Burger Case Exercises Solutions a. Generally speaking, what alternative design strategies are available to Hoosier Burger?

Table 7–7 identifies the new requirements, constraints and three alternatives for Hoosier Burger. As part of its design strategy, Hoosier Burger will likely acquire a new hardware platform and system software. Also, Hoosier Burger has six potential sources of software; these include hardware manufacturers, packaged

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

31

software producers, custom software producers, application service providers, enterprise-wide solutions, and in-house development. However, the most likely candidates are custom software producers or packaged software producers. If you have the class time, encourage your students to research different, specific design strategies that might be beneficial for Hoosier Burger. Then ask your students to update the information provided in Tables 7–7 and 7–8 to reflect their findings. b. Is an enterprise resource planning system a viable option for Hoosier Burger? Why or why not?

Due to Hoosier Burger’s size and its cost, an enterprise resource planning system is not the best choice for Hoosier Burger. c. Modify Figure 7–19 to incorporate the criteria mandated by the new delivery system. Which alternative should be chosen?

Based on the analysis provided in the following spreadsheet, it appears that Alternative B should be chosen.

d. Assuming that Alternative C is still chosen, update Hoosier Burger's economic feasibility analysis to reflect the changes mentioned in this scenario.

Although Alternative C has the lowest score, it may still be chosen because of its many benefits. The students will need to make several assumptions, because the case does not specify how much of the development costs are already reflected in the one-time costs currently shown in Figure 7–19.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

32

PETRIE’S ELECTRONICS Case Question Solutions 7-48. Review the data-flow diagrams you developed for questions in the Petrie’s Electronics case at the end of Chapter 6 (or diagrams given to you by your instructor). Study the data flows and data stored on these diagrams and decided whether you agree with the team’s conclusion that the only 6 entity types needed are listed in the case and in Figure 7-1. If you disagree, define additional entity types, explain why they are necessary, and modify Figure 7-1 accordingly.

Answer will vary. Any additional entities should be properly modeled in an E-R diagram similar to Figure 7-1.

7-49. Again, review the DFDs you developed for the Petrie’s Electronics case (or those given to you by your instructor). Use these DFDs to identify the attributes of each of the six entities listed in this case plus any additional entities identified in your answer to Question 1. Write an unambiguous definition for each attribute.

Then, redraw Figure 7-1 by placing the six (and additional) entities in this case on the diagram along with their associated attributes.

Answers will vary, according to the answer to Question 7-48.

7-50. Using your answer to Case Question 7-49, designate which attribute or attributes form the identifier for each entity type. Explain why you chose each identifier.

Answers will vary, according to the answer to Question 7-48.

7-51. Using your answer to Case Question 7-50, draw the relationships between entity types needed by the system. Remember, a relationship is needed only if the system wants data about associated entity instances. Give a meaningful name to each relationship. Specify cardinalities for each relationship and explain how you decided on each minimum and maximum cardinality on each end of each relationship. State any assumptions you made if the Petrie’s Electronics cases you have read so far and the answers to questions in these cases do not provide the evidence to justify the cardinalities you choose. Redraw your final E-R diagram in Microsoft Visio.

Answers will vary, according to the answer to Question 7-48.

7-52. Now that have developed in your answer to Case Question 7-51 a complete E-R diagram for the Petrie’s Electronics database, what are the consequences of not having an employee entity type in this diagram? Assuming only the attributes you show on the E-R diagram, would any attribute be moved from the entity it is currently associated with to an employee entity type if it were in the diagram?

Why or why not?

Answers will vary. Not having an employee entity in the diagram means that employee activity while interacting with the system cannot be tracked.

.

Chapter 7

Structuring System Requirements: Conceptual Data Modeling

33

7-53. Write project dictionary entries (using standards given to you by your instructor) for all the entities, attributes, and relationships shown in the E-R diagram in your answer to Case Question 7-51. How detailed are these entries at this point? What other details still must be filled in? Are any of the entities on the E-R diagram in your answer to Case Question 7-51 weak entities? Why? In particular, is the SERVICE entity type a weak entity? If so, why? If not, why not?

Answers will vary, according to the answer to Question 7-48.

7-54. What date-related attributes did you identify in each of the entity types in your answer to Case Question 7-51? Why are each of these needed? Can you make some general observations about why date attributes must be kept in a database based on your analysis of this database?

Answers will vary. Date objects are needed anytime the date or time of the creation or update of the object are needed (especially in recording transactions and the like).

.

Chapter 8

Designing the Human Interface

1

Chapter 8 Designing the Human Interface Chapter Overview Designing the human interface is an important systems design activity. This chapter introduces students to form and report design, interface and dialogue design, and dialogue diagramming. Form and report design is a key ingredient for successful systems because users often equate the quality of a system to the quality of its input and output methods. Because of this, students need to understand the role of active user involvement in the form and report design process. A key to designing usable forms and reports is consistency. Students can gain the skills needed to design consistent, usable forms and reports by learning the guidelines of formatting information, using color, highlighting, and avoiding the biasing of information. This chapter also introduces students to the process of designing interfaces and dialogues. The guidelines for designing forms and reports also apply to the design of human–computer interfaces.

Additionally, form and report design and interface and dialogue design have similar processes and deliverables.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Illustrate the process of designing forms and reports, and the deliverables for their creation.

2. Describe how to apply the general guidelines for formatting forms and reports.

3. Illustrate how color can be used to improve the usability of information.

4. Illustrate how to format text, tables, and lists effectively.

5. Explain how the formatting of information can bias users’ understanding.

6. Describe how to assess usability and illustrate how variations in users, tasks, technology, and environmental characteristics influence the usability of forms and reports.

7. Explain the process of designing interfaces and dialogues and the deliverables for their creation.

8. Illustrate how to apply the general guidelines for designing interfaces and specific guidelines for layout design, structuring data entry fields, providing feedback, and system help.

9. Illustrate how to design human-computer dialogues, including the use of dialogue diagramming.

.

Chapter 8

Designing the Human Interface

2

10. Discuss the importance of human interface design as it relates to Internet-based electronic commerce applications.

Classroom Ideas 1. During a lecture, an effective way to teach the various information formatting concepts is to use the tables and figures in the chapter to contrast proper and improper designs.

2. An alternative to lecturing on the chapter’s contents is to lecture from the Review Questions, Problems and Exercises, and Discussion Questions at the end of the chapter. Selected questions can be posed to students to help focus a discussion on specific concepts.

3. Another very effective in-class exercise is to ask students who have been on systems development teams to compare their experiences to the concepts presented in this chapter. This discussion is a good way to elaborate on alternative ways for designing forms and reports. Since some organizations have standards for form and report design, ask students to bring these standards and example forms or reports to class. If standards do not exist, have students bring examples of forms and reports from the same or different systems, showing inconsistencies that can result from not having standards.

4. If you have access to practicing systems analysts, an insightful activity is to invite them into your class to discuss how they design forms and reports in their organization (e.g., processes, types of development and prototyping tools, etc.). As with item 3 above, have your guest(s) discuss any standards the organization has for form and report design. Also, ask your guest(s) to discuss how form and report designs are reviewed or approved, especially if there is a human factors review involved.

5. If you have access to a CASE tool or a visual development tool (e.g., Visual Basic), it is often fun and informative for you to rapidly construct several forms or reports interactively with the class. Alternatively, if you can hold your class in a computer classroom where every student has their own PC and development software, have your students create designs for some fictitious system. Even though you provide students with the same specifications, it is a very interesting exercise to have students share their designs with the other class members. After performing this exercise, discuss why some of the designs were different, but still conform to the design guidelines from the chapter and the specifications that you gave them. Next, discuss how this all relates to usability, consistency in design, and so on.

6. Ask students to bring to class (better yet, give a copy to you in advance so you can make transparencies from them) example forms and reports. Students receive and use invoices, order forms, class registration documents, ride share cards, airline tickets, and a host of other computer input and output. Using the guidelines presented in this chapter, critique these forms and reports. Ask your students to redesign these documents to better satisfy the chapter’s guidelines.

.

Chapter 8

Designing the Human Interface

3

7. Your lectures and exercises should stress the similarity of form and report design and interface and dialogue design, to emphasize the importance of the right information, in the right amount of detail, at the right time.

Lecture Notes Figure 8–1 highlights two important design phase activities: human interface design and database design. This chapter introduces students to several guidelines for designing forms and reports and interfaces and dialogues. Also, students are introduced to human-computer design issues relating to Internet-based applications.

Designing Forms and Reports Form and report prototypes are produced at the end of the analysis phase. Forms and reports are related to the DFD and E-R diagrams produced during requirements structuring. Forms and reports are associated with data flows on data-flow diagrams; the data on these forms and reports also correspond to the entities’ data elements.

Form interaction is a standard method for gathering and displaying information on the Internet.

When designing forms and reports, a prototyping approach is generally used. During this process, the analyst gains an understanding of the intended user and task objectives, structures and refines the information into a prototype; and reviews and modifies the prototype with the end users. Table 8–1 lists several questions to ask when designing forms and reports. Figures 8–2 and 8–3 show two different methods of designing a form.

Design specifications are the human interface design activity’s major deliverables.

Narrative overview, sample design, and testing and usability assessment are the design specification’s three major sections. Figure 8–4 illustrates a design specification.

Table 8–2 summarizes the guidelines for designing forms and reports. Useful guidelines include using meaningful titles, including meaningful information, balancing the layout, and designing an easy navigation system. Figure 8–5 contrasts a poorly-designed and well-designed form.

Table 8–3 lists several commonly used highlighting methods. While highlighting should be used sparingly, it can be used to notify users of errors, provide warnings, and draw attention to keywords, commands, high-priority messages, and data that have gone outside normal ranges. Blinking and audible tones are used to highlight critical information, and highlighting methods should be consistently selected and applied.

Figure 8–6 illustrates several types of highlighting.

Table 8–4 presents several guidelines for displaying text; these guidelines concern the case, spacing, justification, hyphenation, and abbreviation of text. Figure 8–7 contrasts a poorly-designed help screen with its improved design.

.

Chapter 8

Designing the Human Interface

4

Table 8–5 presents the general guidelines for displaying tables and lists, including using meaningful labels; formatting columns, rows, and text; and formatting numeric, textual, and alphanumeric data. Figure 8–8 contrasts a poorly designed form and an improved form design. When choosing between tables and graphs, tables are best when the user needs to locate a single data value; graphs are generally best when analyzing data over time. Figures 8–9 and 8–10 illustrate this point.

Designing Interfaces and Dialogues Interface and dialogue design defines the manner in which humans and computers exchange information. When designing interfaces and dialogues, a prototyping methodology is generally used. A design specification is the primary deliverable from the system interface and design activity. Figure 8–11 shows a design specification outline; subsection 2b is a new addition to the design specification, requiring the development of dialogue sequence diagrams.

Figure 8–12 shows a paper-based form; Figure 8–13 shows a computer-based form.

When designing computer-based forms, their design should be similar to their paperbased equivalent form, standard screen navigation should flow from left-to-right and topto-bottom, data fields should be grouped into logical categories with labels describing each category, and flexibility and consistency should be built into the form. Figure 8–14 contrasts a poorly designed navigation flow with a more appropriate flow. Table 8–6 provides a checklist for validating the usability of user interface designs.

Table 8–7 presents the guidelines for structuring data entry fields. These guidelines govern entries, defaults, units, replacements, captioning, formatting, justification, and help. Table 8–8 illustrates display design options for entering text.

As data are entered, several types of errors may occur. Providing an audit trail can help make identification of such errors easier. Table 8–9 describes several of these errors, including appending, truncating, transcription, and transposition. An objective of interface design is to reduce these errors. Table 8–10 lists several techniques that are used to detect data errors before saving or transmission; these tests include class or composition, combinations, expected values, missing data, pictures/templates, range, reasonableness, self-checking digits, size, and values. Figure 8–15 illustrates how a check digit is calculated.

System interfaces should provide feedback; types of system feedback include status information, prompting cues, and error and warning messages. Table 8–11 provides examples of poor and improved error messages. The design of a help system is an important interface design issue. Table 8–12 provides the SOS guidelines for designing system help; these guidelines are simplify, organize, and show. When designing the help feature, help is provided at the system, form, or field level. Providing field-level help is also called “context-sensitive” help. Figure 8–16 contrasts a poorly designed help screen with an improved design. Table 8–13 identifies several types of help, and Figure 8–17 shows a hyper-based help system from Microsoft Internet Explorer.

A dialogue is the sequence of interactions between a user and a system. Dialogue design consists of designing the dialogue sequence, building a prototype, and assessing usability. Consistency is the primary dialogue design guideline; dialogues should be

.

Chapter 8

Designing the Human Interface

5

consistent in sequence of actions, keystrokes, and terminology. Table 8–14 presents the guidelines for the design of human-computer dialogues. These guidelines govern consistency, shortcuts and sequence, feedback, closure, error handling, reversal, control, and ease of use.

Figure 8–18 illustrates a dialogue diagram; dialogue diagramming is a formal method for designing and representing human-computer dialogues using box and line diagrams.

Only one symbol appears on a dialogue diagram, a box with three sections. Each box corresponds to one display. A dialogue diagram can represent sequence, selection, and iteration; Figure 8–19 illustrates these three concepts. Building prototypes and assessing usability are often optional activities. Graphical development environments speed prototype development.

PVF WebStore: Designing the Human Interface Designing the human interface for an Internet-based electronic commerce application is a crucial and critical design activity. A prototyping process works well when designing the human interface for an Internet electronic commerce system. Although human interface design guidelines for Internet-based applications are still evolving, several guidelines are presented in the textbook. These guidelines include using cookie crumbs, lightweight graphics, form and data integrity rules, and template-based HTML. Table 8–15 identifies common errors that occur when designing the interface and dialogues of Web sites. Table 8–16 identifies common errors that occur when designing the layout of Web pages.

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

template-based HTML (8)

5.

dialogue (3)

2.

dialogue diagramming (4)

6.

form (5)

3.

report (7)

7.

audit trail (1)

4.

cookie crumbs (2)

8.

lightweight graphics (6)

Review Questions Solutions 8-1. Describe the prototyping process of designing forms and reports. What deliverables are produced from this process? Are these deliverables the same for all types of system projects? Why or why not?

Designing forms and reports is a user-focused activity that typically follows a prototyping approach. First, you must gain an understanding of the intended user and task objectives by collecting initial requirements during requirements determination. After collecting the initial requirements, you structure and refine this information into an initial prototype. Structuring and refining the requirements

.

Chapter 8

Designing the Human Interface

6

are completed independent from the users, although you may need to occasionally contact users to clarify some issue overlooked during analysis.

Finally, you ask users to review and evaluate the prototype. After reviewing the prototype, users may accept the design or request that changes be made. If changes are needed, you will repeat the construction-evaluate-refinement cycle until the design is accepted. Usually, several iterations of this cycle occur during the design of a single form or report. The major deliverables produced from the process of designing forms and reports are the creation of design specifications.

A design specification includes a narrative overview, a sample design, and a testing and usability assessment section.

Some specification information may be irrelevant when designing some forms and reports. For example, the design of a simple “Yes/No” selection form may be so straightforward that no usability assessment would be needed. Also, much of the narrative overview may be unneeded, unless it was used to highlight some exception that must be considered during implementation.

8-2. To which initial questions must the analyst gain answers to in order to build an initial prototype of a system output?

The initial questions are listed in Table 8–1; these questions include: (1) who will use this form or report; (2) what is the purpose of the form or report; (3) when is the form or report needed and used; (4) where does the form or report need to be delivered and used; and (5) how many people need to use or view the form or report?

8-3. How should textual information be formatted on a help screen?

The guidelines for formatting a help screen are based on the general guidelines for formatting text. The general guidelines for formatting text are presented in Table 8–4; these guidelines govern case, spacing, justification, hyphenation, and abbreviations.

8-4. What type of labeling can you use in a table or list to improve its usability?

The following labeling guidelines can improve the usability of a table or list: (1) all columns and rows should have meaningful labels; (2) labels should be separated from other information by using highlighting; and (3) redisplay labels when the data extends beyond a single screen or page.

8-5. What column, row, and text formatting issues are important when designing tables and lists?

The guidelines for formatting columns, rows, and text in a table or list include: (1) sorting in a meaningful order (e.g., ascending, descending, or alphabetic); (2) placing a blank line between every five rows in long columns; (3) sorting vertically similar information displayed in multiple columns (that is, read from top to bottom, not left to right); (4) placing at least two spaces between columns; (5) allowing white space on printed reports for the user to write notes; (6) using a single typeface, except for emphasis; (7) using the same family of typefaces within and across displays and reports; and (8) avoiding overly fancy fonts.

.

Chapter 8

Designing the Human Interface

7

8-6. Describe how numeric, textual, and alphanumeric data should be formatted in a table or list.

The guidelines for formatting numeric, textual, and alphanumeric data in a table or list include: (1) right justifying numeric data and aligning columns by decimal points or some other delimiter; (2) left justifying textual data and using a short line length, usually 30–40 characters per line (this is what newspapers use, and it is easier to speed read); and (3) breaking long sequences of alphanumeric data into small groups of three to four characters each.

8-7. Provide some examples where variations in user, task, system, and environmental characteristics might impact the design of system forms and reports.

User-related concerns include experience, skills, motivation, education, and personality. Task-related concerns include time pressure, cost of errors, and work duration. The system platform is a system-related concern, and lighting, sound, and task interruptions are environment-related concerns.

8-8. Describe the process of designing interfaces and dialogues. What deliverables are produced from this process? Are these deliverables the same for all types of system projects? Why or why not?

The design process is a user-focused activity that typically follows a prototyping approach. First, you must gain an understanding of the intended user and task objectives by collecting initial requirements during requirements determination.

After collecting the initial requirements, you structure and refine this information into an initial prototype. Structuring and refining the requirements are completed independent from the users, although you may need to occasionally contact users to clarify some issue overlooked during analysis. Finally, you ask users to review and evaluate the prototype. After reviewing the prototype, users either accept the design or request changes. If changes are needed, you will repeat the construction-evaluate-refinement cycle until the design is accepted. Usually, several iterations of this cycle occur during the design of a single interface or dialogue. Design specifications are the primary deliverables; these documents include a narrative overview, sample design, testing and usability assessment, and dialogue sequence outline.

8-9. List and describe the functional capabilities needed in an interface for effective entry and navigation. Which capabilities are most important?

Why? Will this be the same for all systems? Why or why not?

The functional capabilities include cursor control capabilities, editing capabilities, exit capabilities, and help capabilities; Table 8–6 summarizes these capabilities.

When designing the navigation procedures within your system, flexibility and consistency are primary concerns. Users should be able to freely move forward and backward or to any desired data entry fields. Consistency extends to the selection of keys and commands. Each key or command should have only one function, and this function should be consistent throughout the entire system and across systems if possible. The most important capabilities will vary from system to system. For a given system, consistency is the most important capability.

System capabilities will, unfortunately, vary from system to system.

.

Chapter 8

Designing the Human Interface

8

8-10. Describe the general guidelines for structuring data-entry fields. Can you think of any instances when it would be appropriate to violate these guidelines?

Table 8–7 summarizes the guidelines for structuring data entry fields. Some of the design guidelines may be violated in certain circumstances. For example, a help system might be omitted from a very simple system or a system designed to be used by a single user or small group.

8-11. Describe four types of data errors.

Sources of data errors include appending, truncating, transcripting, and transposing. Appending adds additional characters to a field; truncating loses characters from a field; transcripting errors enter invalid data into a field; transposing reverses the sequence of one or more characters in a field.

8-12. Describe the types of system feedback. Is any form of feedback more important than the others? Why or why not?

Three types of system feedback are discussed in the chapter; these include status information, prompting cues, and error or warning messages. No single method can be deemed “most” important because each is critical to an effective design.

8-13. Describe the general guidelines for designing usable help. Can you think of any instances when it would be appropriate to violate these guidelines?

Table 8–12 presents the general guidelines for designing usable help. Some of the design guidelines may be violated in certain circumstances. For example, a help system might be omitted from a very simple system or a system designed to be used by a single user or small group.

8-14. What steps do you need to follow when designing a dialogue? Of the guidelines for designing a dialogue, which is most important? Why? The three major steps in dialogue design are: (1) design the dialogue sequence; (2) build a prototype; and (3) assess usability. A case could be made for the importance of all steps. Yet, designing the dialogue (with the input of the user) is likely the most important step because this is where you collect and structure the users' requirements.

8-15. Describe what is meant by a cookie crumb. How do these help prevent users from getting lost?

A cookie crumb is a technique for showing users where they are in a Web site; a series of tabs are placed on a Web page showing the users where they are and where they have been. By showing users where they are in a Web site, cookie crumbs keep users from getting lost; users can just click on a hyperlink to return home.

8-16. Describe why you might want to use lightweight graphics on some Web pages and large detailed graphics on others.

Often users do not want to wait for large, color images to download, especially if they have a slow modem. If the time is excessive, the users will often leave the

.

Chapter 8

Designing the Human Interface

9

site. Lightweight graphics download much faster and give the user a thumbnail sketch of the product. If the user wishes to view a larger image, she can click on the thumbnail sketch to see a larger graphic.

8-17. Why is it especially important to eliminate data-entry errors on an electronic commerce Web site?

If data errors are caught quickly, this helps keep erroneous data from being permanently stored in the company’s database.

8-18. How can style sheet- based HTML help to make a large electronic commerce site more maintainable?

Style sheet-based HTML processes and displays common attributes of higherlevel, more abstract items. When a common attribute changes, this change requires updating only the style sheet, as opposed to making many changes. For instance, if your company manufactures handbags, the styles of these handbags will differ but the available colors are probably the same. If a new color, suppose chocolate, is added then only the available colors require updating.

Problems and Exercises Solutions 8-19. Imagine that you are to design a budget report for a colleague at work using a spreadsheet package. Following the prototyping discussed in the chapter (see also Figure 1–17), describe the steps you would take to design a prototype of this report.

The students should describe a process as outlined in Figure 1–17 (Chapter 1).

Essentially, they should begin by eliciting from their colleague a definition of the problem and the basic requirements for the budget report. These requirements would include the content, how they want to use the data (e.g., what comparison or decisions they will make from the data), and any other expectations they have about the style of the report. They should then develop an initial, working prototype using the spreadsheet package. Next, they should use this spreadsheet prototype to revise and enhance the system iteratively with their colleagues. When ready, the prototype can then be converted to the operational system.

8-20. Consider a system that produces inventory reports at a local retailer.

Alternatively, consider a system that produces student academic records for the records office at a university. For whichever system you choose, answer the following design questions: Who will use the output? What is the purpose of the output? When is the output needed, and when is the information that will be used within the output available? Where does the output need to be delivered? How many people need to view the output?

Inventory reports are used by managers and stocking employees, and perhaps store owners, depending on how large the retailer is. The output’s purpose is to give an accurate picture of the levels of various inventory items, for purchasing or other decisions. The output would likely be needed at regular intervals (e.g.,

.

Chapter 8

Designing the Human Interface

10

weekly), but would only be available after ordering and sales information is updated (so that updated inventory levels would display). Assuming this is a smaller retailer, the output would only be needed either on the computer screen, or perhaps as a printed report for reconciliation purposes. In a smaller retailer, the information is really only applicable to managers and a few employees in charge of stocking shelves.

8-21. Imagine the worst possible reports from a system. What is wrong with them? List as many problems as you can. What are the consequences of such reports? What could go wrong as a result? How does the prototyping process help guard against each problem?

The worst possible reports come so late that the information is be useless, the reports contain information that the user does not need, and they do not contain the information that the user really needs. The information presented has errors and is inconsistent from page to page and from report to report. The layout is difficult to read and understand, and the reports are inflexible, prohibiting the user from changing the information to his liking. As farfetched as this sounds, these types of problems happen frequently with poorly designed reports.

The consequences are that the users of these reports will not be able to use the reports in any meaningful way. They ultimately become frustrated with the reports and, eventually, stop looking at them. If they are unable to find the information they need in some other way, their decision making and performance suffers.

Ultimately, the organization’s performance suffers. The prototyping process helps guard against these problems because users and system personnel can work together to ensure that the reports are useful; they present useful information in an effective format, and they are delivered in a timely manner.

8-22. Given the guidelines presented in this chapter, identify flaws in the design of the Report of Employees shown. What assumptions about users and tasks did you make in order to assess this design? Redesign this report to correct these flaws.

Report of Employees-1-2-08 Em_ID Name, Title 0124543 John Smith, VP Marketing 2345645 Jared Wright, Project Manager 2342456 Jennifer Chang, Systems Analyst 4564234 Mark Walters, Software Engineer 7875468 Nick Shelley, BI Analyst 4446789 Kim Eagar, HR Manager 4678899 Emily Graham, Receptionist

.

Chapter 8

Designing the Human Interface

4452378

11

Matt Hoffman, Network Operations Specialist

The report lacks a clear title, meaningful column labels consistent spacing of rows, logical sequence of information, proper segregation of column data, and left-justification of alphabetic text. The long ID numbers are hard to read. The data is also ambiguous (it could be M-D-YY or D-M-YY).

Employee Report

Jan 02, 2008

Employee ID

Last Name

First Name

Title

0-124-543 2-345-645 2-342-456 4-564-234 7-875-468 4-446-789 4-678-899 4-452-378

Chang Eagar Graham Hoffman Shelley Smith Walters Wright

Jennifer Kim Emily Matt Nick John Mark Jared

VP Marketing Project Manager Systems Analyst Software Engineer BI Analyst HR Manager Receptionist Network Operations Engineer

8-23. Consider the design of a registration system for a hotel. Following design specification items in Figure 8–11, briefly describe the relevant users, tasks, and displays involved in such a system.

The users for a hotel registration system include the hotel employees working at the front desk and, perhaps, the people working at the concierge desk and the guests, depending on how the system was designed. The system’s primary purpose is to assist in quickly and effectively registering guests to the hotel. The people at the concierge desk use the system to register guests when the front desk has an overload. They might also use the system to check on or change a guest’s information. The hotel might even let prospective guests use the system directly to either register or check on their registration. Such a system might display information on room availability and rates, places for the user to enter guest information, and a map to show the guest how to get to his/her room and where to park his/her car.

8-24. Obtain a report of some information, either from your employer (e.g., a budget or project report) or from your school (e.g., your student academic record). Evaluate the design of the report using the general guidelines in Table 8-2.

Answers will vary. Evaluations should be based on the guidelines in Table 8-2.

.

Chapter 8

Designing the Human Interface

12

8-25. Design one sample data-entry screen for a hotel registration system using the data entry guidelines provided in this chapter (see Table 8–7). Support your design with arguments for each of the design choices you made.

It should be fairly easy for students to design a simple display for hotel registration data-entry. Such a display would basically require the user to input the prospective guest’s name, address, telephone number, method of payment, information about payment (e.g., credit card number or check number), whether or not they have a car and, if so, the license plate of the car and the state in which the car is licensed, length of stay, whether the guest wants a smoking or non-smoking room, and so on. It is not important that the students capture all the necessary information on their sample displays; rather, it is important that their displays conform to the guidelines outlined in Table 8–7 and that they can argue logically for the design choices they have made.

8-26. Describe some typical dialogue scenarios between users and a hotel registration system. For hints, reread the section in this chapter that provides sample dialogue between users and the Customer Information System at Pine Valley Furniture.

One potential dialogue scenario for a hotel registration system might be: a request to view room availability and relevant rates, select a room and rate, input guest information, input and verify payment information, select printing of receipt, leave the system.

8-27. Represent the dialogues from the previous question through the use of dialogue diagrams.

There are a number of ways that students can design their dialogue diagrams for their sample hotel registration data entry system. It will probably be helpful for them to use as a guide the dialogue diagram in Figure 8–20, which is for the Customer Information System at Pine Valley Furniture. The students may wish to place the data entry display within the broader information system at the hotel, much like in the chapter the request to view year-to-date customer information was placed within the dialogue diagram of the overall Customer Information System. It is not important that all the pieces of the students’ system are included, nor is it necessarily important how they choose to diagram the interaction; rather, it is important that the students’ diagrams show logical, simple navigation and the appropriate components (i.e., top, middle, and bottom) of each box representing screens.

8-28. Think of an online retailer you’ve recently used or considered using for a purchase. Why is good design of that retailer’s interface important for the retailer? Visit the online retailer and evaluate the interface, highlighting several good things and several bad things.

Good design of an online retailer’s interface is crucial to their success because the interface is the only interaction an online consumer gets with the company. The interface needs to be usable and signal secure processes and other credibilityrelated attributes in order for users to confidently transact. Answers regarding the specific retailer evaluated will vary.

.

Chapter 8

Designing the Human Interface

13

Discussion Questions Solutions 8-29. Discuss the differences between a form and a report. What characteristics make a form or report good (bad) and effective (ineffective)?

A form is a business document that contains some predefined data and may include some areas where additional data are to be filled in. In contrast, a report is a business document that contains only predefined data. A properly designed form or report conforms to the guidelines presented in Table 8–2, meaning the form or report uses meaningful titles, includes meaningful information, balances the layout, and is easy to navigate. In contrast, a poorly designed form or report violates one or more of these guidelines.

8-30. Discuss the various ways that information can be highlighted on a computer display. Which methods are most effective? Are some methods better than others? If so, why and when?

Methods of highlighting include blinking and audible tones, color differences, intensity differences, size differences, font differences, reverse video, boxing, underlining, all capital letters, and offsetting the position of nonstandard information. When to use a particular highlighting technique is dependent on the situation. For instance, boxes are used to separate and distinguish different categories of data; capital letters and different fonts help distinguish labels from the actual data. An audible tone can be used to signal an illegal operation, and intensity differences can be used to identify summary data, such as totals.

8-31. What problems can occur if a system fails to provide clear feedback and error messages to users?

A lack of feedback may cause a user to become frustrated and confused. An additional problem is the collection of erroneous data and the storage of this data in the company’s database.

8-32. Use a search engine to find recommendations for good design of web interfaces. How are these recommendations similar to those discussed in this chapter? How do they differ?

Answers will vary. Most recommendations found online will coincide with those found in this chapter, though many recommendations will center almost fully on web interface design.

Case Problems Solutions 8-33. Pine Valley Case Exercises Solutions a. What data will the Customer Profile Form need to collect? Using the guidelines presented in the chapter, design the Customer Profile Form.

Pine Valley Furniture has several types of customers, including corporate, student, home office, and family. Profile forms should be developed for each of

.

Chapter 8

Designing the Human Interface

14

these customer types. A basic, suggested profile form for a family customer is provided below. This form collects basic information about the customer, such as location, family data, and purchasing history. This information can be used to build special promotions, such as targeting parents with children graduating from high school. The state, occupation, monthly income, media channel, first purchase date, and monthly store visits fields can be implemented as drop down lists, enabling the store representative to select from a list or a range of possible answers. Also, the married, children, and first time customer fields can be implemented as Y/N fields.

Pine Valley Furniture Customer Profile Form Current Date: ____________

Customer Profile Customer ID: ___________

Last Name: ______________

First Name: _______________

Address: _______________

City: ___________________

State:

Monthly Income: ___________

____ Zip: __________

Family Profile Birth Date:

____________

Occupation: ______________

Married:

Y/N

Spouse’s Name: _________

Children:

Y/N

Child’s Gender: ___________

Child’s Birth Date: ___________

Purchasing/Media Profile First Time Customer? Y/N

No. of Visits before Purchasing: ____________

How did you hear about PVF? _________________

First Purchase Date: _____________________

Average Yearly Amount Spent at PVF? _________

No. of Monthly Store Visits: _______________

b. Using the guidelines presented in the chapter, design the Products by Demographics Summary Report.

A suggested report is provided below.

.

Chapter 8

Designing the Human Interface

15

Pine Valley Furniture Products By Demographics Summary Report (Current Date)

Furniture Category Business

Sales

By Region

Region

Average Customer Age

Midwest Northeast Northwest Southeast Southwest West Coast Total Regional Sales:

Average Age:

Dining Room ........ ........

Grand Total:

Average Age:

.

Chapter 8

Designing the Human Interface

16

c. Using the guidelines presented in the chapter, design the Customer Purchasing Frequency Report.

A suggested report is provided below.

Pine Valley Furniture Customer Purchasing Frequency Report (Current Date) Monthly Frequencies Customer Type

1–4

5–8

9–12

12 or More

Purchase Average

Business Family Student Web-Based

Overall Averages:

d. Modify the dialogue diagram presented in Figure 8–20 to reflect the addition of the Customer Profile Form, Products by Demographics Summary Report, and the Customer Purchasing Frequency Report.

The dialogue diagram requires several minor modifications. First, the analyst should insert a Create Customer Profile dialogue box; this dialogue can be a menu option on the Individual Customer Information screen; its page number is 2.2. From the Customer Profile display, the user should be able to reference the main menu (page number 1) and the Individual Customer Information (page number 2). From the Reports display (page number 5), the user should be able to access the Products By Demographics Report (page number 5.1) and the Customer Purchasing Frequency Report (page number 5.2). Each of these displays should provide the user with access to the Report display (page number 5) and the Main Menu (page number 1).

.

Chapter 8

Designing the Human Interface

17

8-34. Hoosier Burger Case Exercises Solutions a. What data will the Delivery Customer Order Form need to collect? Using the design guidelines presented in the chapter, design the Delivery Customer Order Form.

The Delivery Customer Order Form should collect at a minimum, the customer’s name, delivery address, and information about the order. A suggested form is provided below.

Hoosier Burger

Delivery Customer Order Form Delivery No: _____________

Current Date: ______________

Customer Information Customer ID: ______________ Last Name: __________

First Name: ___________

Delivery Address: __________

Charge?:

City: _______________

___________

Delivery Information Item No.

Item Description

Quantity

Price

_______

_________________________

_______

_____

_______

_________________________

_______

_____

_______

_________________________

_______

_____

_______

_________________________

_______

_____

Total Sale:

_____

Special Instructions _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________

.

Chapter 8

Designing the Human Interface

18

b. What data will the Customer Account Balance Form need to show? Using the design guidelines presented in the chapter, design the Customer Account Balance Form.

At a minimum the Customer Account Balance Form should show the customer’s account activity for the most recent period. It would be a good idea to show the delivery numbers, whether or not the delivery order was paid for at the time the delivery was made, the customer’s current account balance, and any payments made to the account. Also, the form should provide the Hoosier Burger employee with the customer’s basic information so that he/she can verify that the proper customer’s account is being viewed.

A suggested answer is provided below. Since students are very creative, they will identify several innovative ideas for the customer form. Your students may suggest including several buttons on the form, one of which can provide access to detailed delivery information. Although not shown on this form, the students may recommend that the Customer Account Balance Form reflect whether or not the customer’s account is past due, as well as when the next payment is due.

Hoosier Burger

Customer Account Balance Form (Current Date) Customer No: __________ (Customer’s Last Name), (Customer’s First Name) (Mailing Address) (City), (State), (Zip Code) Date

Delivery No.

Charge

Payment

Current Balance

....

...........

........

........

...............

....

...........

........

........

...............

.

Chapter 8

c.

Designing the Human Interface

19

Using the design guidelines presented in the chapter, design the Daily Delivery Summary Report.

A suggested answer is provided below.

Hoosier Burger

Daily Delivery Summary Report (Current Date)

Menu Item No.

Menu Item Description

Quantity

Dollar Sales

.....

..........

......

....

.....

..........

......

....

.....

..........

......

....

Total Sales

....

d. Using the design guidelines presented in this chapter, design the Low-inStock Report.

A suggested answer is provided below.

Hoosier Burger

Low-In-Stock Report (Current Date) Menu Item No.

..... ..... .....

Menu Item Description

Quantity On Hand

Reorder Level

Reorder Amount

.......... .......... ..........

........ ........ ........

...... ...... ......

........ ........ ........

.

Chapter 8

Designing the Human Interface

20

8-35. Pet Nanny Case Exercises Solutions a. What data should the Pet Enrollment Form collect? Using the guidelines provided in the chapter, design the Pet Enrollment Form.

A suggested answer is provided below. The basic form should collect information about the pet, its owner, its veterinarian, and special care instructions.

Pet Enrollment Form Pet No:

_____________________

Current Date: ____________________

Contact Information Owner’s Last Name: ___________________

Owner’s First Name:

Home Address: ________________ City: ______________________ State: ______________________

Phone Number: _________________ Alt. Phone Number: ______________ Zip: __________________________

___________________

General Pet Information Pet’s Name: ___________ Species: _________ Vet Name: _______________________________

Special Care Instructions

.

Birth date: ________________ Vet’s Phone No. __________

Chapter 8

b.

Designing the Human Interface

21

What data should the Pet Service Form collect? Using the guidelines provided in the chapter, design the Pet Service Form.

A suggested answer is provided below.

Pet Service Form Pet No: __________

Current Date: __________

Service No.

Service Date Requested

Service Description

Time Requested

c. Using the guidelines provided in the chapter, design the Pick Up and Delivery Schedule Report.

A suggested answer is provided below.

Pickup and Delivery Schedule Report (Current Date) Pickup Times

Pet’s Name

Pickup Address

.

Delivery Address

Chapter 8

Designing the Human Interface

22

d. Using the guidelines provided in the chapter, design the Daily Boarding Report.

A suggested answer is provided below.

Daily Boarding Report (Current Date)

Pet No. Pet Name

Check-In Date

Check-Out Date

.

Length Of Stay

Special Care Instructions

Chapter 8

Designing the Human Interface

23

Petrie’s Electronics Case Question Solutions 8-36. Using the guidelines from this chapter and other sources, evaluate the usability of the page design depicted in Figure 8-1.

Answers will vary. Analysis should include mention of meaningful titles and information, a balanced layout, navigation functions. Since this is a web interface, the analysis could also include discussion of items from Table 8-16 regarding layout of web pages.

8-37. Chapter 8 encourages the design of a help system early in the design of the human interface. How would you incorporate help into the interface as shown in Figure 8-1?

Answers will vary. Suggestions might include an explanatory link near the progress bar, or a prominent link for “Help” in the navigation bar along the top.

8-38. Describe how cookie crumbs could be used in this system. Are cookie crumbs a desirable navigation aid for this system? Why or why not?

Cookie crumbs could be included along the top of the main content area. They are a desirable navigation aid for the system because they aid in navigability, showing users where they are in the structure of the system.

8-39. The page design depicted in Figure 8-1 links to an Order History page.

Sketch a similar layout for the Order History page, following guidelines from Chapter 8.

Answers will vary. A suggested layout should be similar in every way (consistent along the top and the side bar) except for the main content area. In the main content area, the order history data should be displayed in a clearly-organized table, according to guidelines in the chapter.

8-40. Describe how the use of template-based HTML might be leveraged in the design of the ‘No Customer Escapes’ system.

Answers will vary. HTML templates could be used to standardize the presentation (and editing) of the top navigation bar, the sidebar, and the (supposed) footer of each page.

.

Chapter 9

Designing Databases

1

Chapter 9 Designing Databases Chapter Overview The purpose of this chapter is to present a detailed description of the concepts and techniques used to translate a conceptual data model into a form necessary for database design. This chapter introduces the relational data model—the most common notation used for representing detailed data requirements necessary for database design. Concepts of the relational data model, normalization principles for creating relational models with desirable properties, a process for combining different relational data models into a consolidated one, and how to translate an entity-relationship data model into a relational data model are presented. This chapter provides a transition from typical systems analysis to data analysis methodologies, often discussed in a database course. You should coordinate the teaching of this chapter with the faculty member(s) teaching database-related courses so that purposeful redundancy occurs and important topics are not missed across the courses in your curriculum.

Instructional Objectives Specific student learning objectives are included in the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Show the relationship between systems analysis and design and logical database design. The philosophy of this textbook is that logical database design is a topic of joint interest to both systems analysts and database specialists. In most cases, there is considerable interaction between conceptual and logical database design, which combines the top-down approach of conceptual data modeling with a bottomup approach using logical data modeling tools. Application area knowledge as well as enterprise database knowledge (often found in a data administration group) are necessary to converge to a viable logical design for an application’s database.

Remember, an application’s logical database design does not imply a separate physical database for that application, but rather only a separate view of data, which may be part of a more comprehensive physical database.

2. Present the relational data model as a logical data model that can be used to capture the structure of data in a very fundamental, stable form and that suggests some ways to organize data during physical database design that will result in desirable data maintenance properties (which avoid certain data anomalies).

3. Show students how a conceptual data model can obscure some of the details about data requirements that must be better understood to do physical database design.

4. Show students, using an example from Hoosier Burger, how to translate a conceptual data model into a logical data model and how to incorporate the data requirements of specific system outputs into the process of forming a logical data model.

.

Chapter 9

Designing Databases

2

Classroom Ideas 1. This chapter should be read following the discussion on the design of the human interface (Chapter 8), because some logical database design activities, (specifically view integration and merging normalized views of individual system inputs and outputs) build on the designs of system interfaces. Since an entity-relationship diagram is often modified once specific system inputs and outputs have been studied and a more precise understanding of attributes, entities, and relationships is reached, logical database design will begin with a possibly incomplete view of data if done before the design of system inputs and outputs.

2. This chapter, like Chapter 6, covers a topic also addressed in most database management courses. Depending on your curriculum, this chapter may review previously covered material or may be covered (in more depth) in a subsequent course. We believe that logical data modeling is not strictly a database topic, but is essential for thorough systems analysis, thus it is an activity that should not be assigned to only specialists (database analysts). Although we strongly encourage you to cover this chapter in your systems analysis and design course, you should coordinate how you address this topic with those who teach database courses.

Even though this chapter has considerable similarity with the chapter on logical data modeling in the companion text Modern Database Management by Hoffer, Prescott, and McFadden, Chapter 9 is carefully written for the systems analysis and design student. We believe that this chapter is an excellent refresher for those who have already studied the relational data model and normalization, and will provide a solid introduction to these topics for those students who will address this topic later in a database course.

3. You should emphasize with your students that logical data modeling is still technology independent. A logical data model is not necessarily mapped on a oneto-one basis into a physical database design. The purpose of logical data modeling is to prepare the description of stored data requirements into a format that makes it easier for physical database design decisions to be made. Students may want to go directly from conceptual data modeling to physical database design, so spend some time motivating logical data modeling.

4. Be sure to review for your students the key steps of logical data modeling outlined in the section “The Process of Database Design” and discussed throughout the chapter. It is important that novice data modelers understand that all four steps are necessary to produce a thorough, logical data model as input to physical database design.

5. Understanding the relational data model is critical for doing logical data modeling.

The relational data model is fairly simple, and since some students will have had experience with a PC database management system, this model will be rather intuitive for them. Emphasize the five properties of relations and the concept of anomalies. Use figures in the chapter to illustrate anomalies.

6. A discussion of anomalies naturally leads to normalization and functional dependencies. You can introduce normalization to your students from two perspectives. One approach is to introduce first, second, and third normal forms and teach your students to transform unnormalized data into third normal form by

.

Chapter 9

Designing Databases

3

stepping through each normal form in sequence. Another approach is to emphasize functional dependencies and determinants (see Problem and Exercise 6). Use whichever approach is most comfortable to you; the chapter supports either approach.

7. We suggest spending a large portion of your class periods (allocated to Chapter 9) working problems to translate between E-R and relational data models. Table 9–1 is a compact summary of how to map E-R constructs into relational constructs.

Your students should become competent with translating in either direction.

Problems and Exercises 9-18, 9-19, 9-20,9-21 and 9-22 are suitable for in-class exercises, but you may want to create many other examples. Work a few examples for your students, and then have them work (either individually or in small teams) on some problems in class and then share their answers. Practice is absolutely the best teacher of both normalization and translating between relational and E-R models.

8. Emphasize with your students that most E-R models developed during analysis are incomplete since system inputs and outputs are not designed in detail until the logical design phase. Use this to motivate the need for view integration. Be sure to discuss the potential pitfalls (view integration problems) that make view integration more than a mechanical process. Again, use many examples; Problem and Exercise 9-20 is a fairly simple one that students could work on inside or outside of class. Ask your students why view integration problems arise; for example, sample problems include independent analysts or project teams of different subsystems with slightly different data semantics, the integration of multiple independentlydeveloped applications coming together to create an enterprise data model, and imprecision or lack of naming standards by analysts.

9. You may want to review in class the Hoosier Burger example presented in the chapter. This example illustrates how to deal with both translating an E-R model into 3NF relations as well as integrating specific system requirements into the data model during logical database design.

Lecture Notes As Figure 9–1 shows, designing databases is one of the primary design phase activities.

The five purposes of logical and physical database design are to: (1) structure the data in stable structures that are not likely to change over time and that have minimal redundancy; (2) develop a logical database design that reflects the actual data requirements that exist in the forms and reports of an information system; (3) develop a logical database design from which we can do physical database design; (4) translate a relational database model into a technical file and database design; and (5) choose data-storage technologies that will efficiently, accurately, and securely process database activities.

Database Design Logical design and physical design are the two primary file and database design steps.

Although database modeling and design activities are present in all SDLC phases, this

.

Chapter 9

Designing Databases

4

chapter focuses primarily on the logical data model, physical file, and database design.

Figure 9–2 associates the various database models with their corresponding SDLC phases. The four steps in logical database modeling and design are: (1) develop a logical data model for each known user interface for the application using normalization principles; (2) combine normalized data requirements from all user interfaces into one consolidated logical database model; (3) translate the conceptual E-R data model for the application into normalized data requirements; and (4) compare the consolidated logical database design with the translated E-R model and produce one final logical database model for the application. Important physical database design decisions include: (1) choosing the data type for each attribute from the logical database model; (2) grouping attributes from the logical database model into physical records; (3) arranging related records in secondary memory so that individual and groups of records can be stored, retrieved, and update rapidly; and (4) selecting media and structures for storing data to make access more efficient. A primary key is an attribute whose value is unique across all occurrences of a relation.

Figure 9–3 provides an example of logical data modeling. The primary deliverable from logical database design is a set of normalized relations. During physical database design, the normalized relations are translated into computer file specifications. Coding the database definitions is performed during implementation; Figure 9–4 shows a table in design view.

Relational Database Model The relational database model represents data as a set of related tables or relations.

Figure 9–5 shows an example of a relation. A shorthand notation is often used to represent the relation’s structure. A relation has several properties which include: (1) entries in cells are simple; (2) entries in columns are from the same set of values; (3) each row is unique; (4) the sequence of columns can be interchanged without changing the meaning or use of the relation; and (5) the rows may be interchanged or stored in any sequence. A well-structured relation contains a minimum amount of redundancy and allows users to insert, modify, and delete the rows without errors or inconsistencies.

Figure 9–6 shows a relation with redundancy. Normalizing the relation in Figure 9–6 results in two relations; these relations are shown in Figure 9–5 and Figure 9–7.

Normalization Normalization converts complex data structures into simple, stable data structures.

The process of normalizing relations requires the relations to be placed in first, second, and third normal forms. Normalization results in every nonprimary key attribute depending on the whole primary key and not on other nonkey attributes.

Normalization analyzes the functional dependencies existing among attributes. A functional dependency is noted by using an arrow, such as A→B. If an attribute is functionally dependent on two attributes, the notation is A,B→C. Figure 9–8 can be used to illustrate the presence or nonpresence of functional dependencies.

A relation is in second normal form (2NF) when the nonkey attributes are functionally dependent on the entire primary key, not just part of it. A relation is in second normal

.

Chapter 9

Designing Databases

5

form when: (1) the primary key consists of only one attribute; (2) no nonprimary key attributes exist in the relation, and (3) every nonprimary key attribute is functionally dependent on the full set of primary key attributes. Converting a relation to second normal form requires decomposing the relation into new relations and using the determinants as the primary keys for the new relations.

A relation is in third normal form (3NF) if it is in second normal form and does not have transitive dependencies. Figure 9–9 illustrates the removal of transitive dependencies from a relation. A foreign key is an attribute that appears as a nonprimary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation. Referential integrity is an integrity constraint specifying that the value of an attribute in one relation depends on the value of the same attribute in another relation.

Transforming E-R Diagrams Into Relations Transforming the conceptual E-R diagram into normalized relations requires four steps; (1) representing entities; (2) representing relationships; (3) normalizing the relations; and (4) merging the relations. Each regular entity in an E-R diagram becomes a relation; the entity type’s identifier becomes the primary key for the new relation; the entity type’s nonkey attributes become nonkey attributes of the relation. The new primary key must uniquely identify every row in the relation and be nonredundant. Figure 9–10 shows how to transform an entity type to a relation.

Relationship representation depends on the degree of the relationship and the cardinalities of the relationship. A binary 1:N relationship requires adding the primary key attribute of the entity on the one side of the relationship as a foreign key in the relation on the many side of the relationship. Figure 9–11 illustrates this rule. A binary or unary 1:1 relationship is represented by: (1) adding the primary key of A as a foreign key of B; (2) adding the primary key of B as a foreign key of A; or (3) doing both of the above. For binary and higher-degree M:N relationships, a separate relation is created, using as its primary key a composite of the primary keys of the entities participating in the relationship. Figure 9–12 shows how to represent an M:N relationship. Figure 9– 13 provides two examples of unary relationships. To represent a unary 1:N relationship, use a recursive foreign key. For a unary M:N relationship, a separate relation represents the relationship. Table 9–1 summarizes the rules for transforming E-R diagrams into equivalent relations.

Merging Relations View integration is the last step in logical database design. View integration involves merging relations that describe the same entity type. View integration problems include synonyms, homonyms, and dependencies between nonkeys.

Logical Database Design for Hoosier Burger Hoosier Burger is used to illustrate logical database design. Figures 9–14 to 9–16 support this example.

.

Chapter 9

Designing Databases

6

Physical File and Database Design Designing physical files and databases requires information about: (1) normalized relations, including volume estimates; (2) definitions of each attribute; (3) descriptions of where and when data are used; (4) expectations or requirements for response time and data integrity; and (5) descriptions of the technologies used for implementing the files and database.

Designing Fields A field is the smallest unit of named application data recognized by system software; an attribute is represented by one or more fields. Basic decisions address data type and data integrity controls. Table 9–2 identifies several Microsoft Access data types. When selecting a data type, the analyst must balance four objectives: (1) minimizing storage space; (2) representing all possible values of the field; (3) improving data integrity for the field; and (4) supporting all data manipulations desired on the field. A calculated field is a field that can be derived from other database fields. Coding and compression techniques can reduce storage space and increase data integrity. Five popular data integrity control methods are default value, input mask, range control, referential integrity, and null value control. Figure 9–17 provides examples of referential integrity field controls. A default value is a value a field will assume unless an explicit value is entered for that field. An input mask is a pattern of codes that restricts the width and possible values for each position of a field. A null value is a special field value, distinct from 0, blank, or any other value, that indicates that the value for the field is missing or otherwise unknown.

Designing Physical Tables While a relation contains attributes describing some unifying business concept, a physical table is a named set of rows and columns that specifies the fields in each row of a table. A physical table may or may not correspond to one relation. The efficient use of secondary storage space and data processing speed are the two goals of physical table design. Physical table design may require the denormalization of relations.

Figure 9–18 illustrates the denormalization process. An analyst may choose to denormalize data when there are two entities with a one-to-one relationship, is a manyto-many relationship with nonkey attributes, and is reference data.

Denormalization results in one or more physical files. Figure 9–19 shows possible denormalization situations. A file organization is a technique for physically arranging the records of a file. When selecting a file organization, the choice is based on fast data retrieval, high throughput for processing transactions, efficient use of storage space, protection from failures or data loss, minimizing need for reorganization, accommodating growth, and security from unauthorized use. Many file organizations use a pointer, a field of data that can be used to locate a related field or row of data. Three file organizations are discussed in the chapter; these are sequential, indexed, and hashed. Figure 9–20 compares these three file organizations. Table 9–3 summarizes the comparative features of the sequential, indexed, and hashed file organization

.

Chapter 9

Designing Databases

7

methods. When specifying indexes for a relational database, the analyst should specify a unique index for the primary key of each table, an index for foreign keys, and an index for nonkey fields that are referenced in qualification, sorting, and grouping commands for the purpose of retrieving data. A secondary key refers to one or a combination of fields for which more than one row may have the same combination of values.

Physical Database Design for Hoosier Burger The authors use Hoosier Burger to illustrate how to translate a logical database design into a physical database design. References are made to several figures that appeared earlier in the chapter. Tables 9–4 — 9–6 support this discussion.

PVF WebStore: Designing Databases Important database design concepts are illustrated through Valley Furniture’s WebStore.

As suggested in the chapter, database design for an Internet-based electronic commerce application is similar to the process followed for other types of applications.

Key Term Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

relation (22)

16.

input mask (13)

2.

well-structured relation (or table) (29)

17.

null value (15)

3.

normalization (14)

18.

physical table (17)

4.

functional dependency (8)

19.

denormalization (4)

5.

second normal form (2NF) (25)

20.

physical file (16)

6.

third normal form (3NF) (28)

21.

file organization (6)

7.

foreign key (7)

22.

pointer (18)

8.

referential integrity (21)

23.

sequential file organization (26)

9.

recursive foreign key (20)

24.

indexed file organization (12)

10.

synonyms (27)

25.

index (11)

11.

homonym (10)

26.

secondary key (24)

12.

field (5)

27.

hashed file organization (9)

13.

data type (2)

28.

primary key (19)

14.

calculated (or computed or derived) field (1)

29.

relational database model (23)

15.

default value (3)

Review Questions Solutions

.

Chapter 9

Designing Databases

8

9-1. What is the purpose of normalization?

The purpose of normalization is to rid relations of anomalies. The goal is to form well-structured relations that are simple and stable when data values change or data are added or deleted.

9-2. List five properties of relations.

The five properties of relations are: (1) entries in cells are simple, (2) entries in columns are from the same set of values, (3) each row is unique, (4) the sequence of columns is insignificant, and (5) the sequence of rows is insignificant.

9-3. What problems can arise during view integration or merging relations?

Synonyms, homonyms, and dependencies between nonkeys can arise during view integration. Synonyms occur when two or more different names are used for the same attribute from different user views. Homonyms occur when two or more attributes from different user views have the same name. Functional dependencies between nonkey attributes arise when functionally dependent nonkeys come from different user views.

9-4. How are relationships between entities represented in the relational data model?

Relationships between entities are represented in several ways in the relational data model. A binary 1:M relationship is represented by placing a foreign key (the primary key of the entity on the one-side of the relationship) in the relation for the entity on the many-side of the relationship. In a binary 1:1 relationship, a foreign key is placed in the relation on either side of the relationship or on both sides. For a binary and higher degree M:N relationship, a relation is created with a primary key which is the concatenation of the primary keys from the related entities. In a unary relationship, a recursive foreign key is added to the relation.

9-5. What is the relationship between the primary key of a relation and the functional dependencies among all attributes within that relation?

The fundamental rule of normalization is that each non-key attribute must be a fully functionally dependent on the whole primary key attribute (a nonkey is dependent on the whole key and nothing but the key). Thus, there can be no functional dependencies between nonkeys.

9-6. How is a foreign key represented in relational notation?

A foreign key is identified by using a dashed underline.

9-7. Can instances of a relation (sample data) prove the existence of a functional dependency? Why or why not?

Instances in a relation cannot prove that a functional dependency exists; however, you can use sample data to demonstrate that a functional dependency does not exist. The sample data does not show you every possible instance, only a sampling. Knowledge of the problem domain is a reliable method for identifying functional dependencies.

.

Chapter 9

Designing Databases

9

9-8. In what way does the choice of a data type for a field help to control the integrity of that field?

The choice of data type often limits the possible values that may be stored for a field. For example, a numeric data type forbids alphabetic characters. Some data types have an assumed length, which places an implicit range control on values.

Data type may also limit the kinds of data manipulations possible, thus further controlling the integrity of the data or results from manipulating the data. For example, a DATE data type causes addition and subtraction to be limited by rules about dates.

9-9. Contrast the differences between range control and referential integrity when controlling data integrity.

Range controls identify a set of permissible values, such as college ranking (senior, junior, sophomore, and freshman). Referential integrity requires a foreign key to match a primary key in another relation. Alternatively, referential integrity would require a recursive foreign key to match the primary key of that same relation. A referential integrity control requires that the data management software access other data records to determine if the value is permitted, whereas a range control is checked by looking up values outside the files and database, in a repository or other source of metadata.

9-10. What is the purpose of denormalization? Why might you not want to create one physical table or file for each relation in a logical data model?

Denormalization provides for more efficient data processing. Denormalization enables data to be stored in physical tables based on affinity of use; this feature reduces the number of I/O operations.

9-11. What factors influence the decision to create an index on a field?

The factors that influence the decision to create an index are the data retrieval, insertion, deletion, and updating costs with and without the index. Indexes allow for rapid random retrieval and sorting of data, but indexes create additional storage and maintenance costs. The guidelines presented in the chapter offer suggestions for when to use an index; these guidelines include specifying a unique index for the primary key of each table; specifying an index for foreign keys, and specifying an index for nonkey fields that are referenced in qualification, sorting, and grouping commands for the purpose of retrieving data.

9-12. Explain the purpose of data compression techniques.

Coding and compression techniques reduce storage space and can increase data integrity. Data compression techniques are pattern matching and other methods that replace repeating strings of characters with codes of shorter lengths, thus reducing data storage requirements.

9-13. What are the goals of designing physical tables?

The two goals mentioned in the chapter are efficient use of secondary storage space and data processing speed.

9-14. What are the seven factors that should be considered in selecting a file

.

Chapter 9

Designing Databases

10

organization?

When selecting a file organization, the analyst should consider fast data retrieval, high throughput for processing transactions, efficient use of storage space, protection from failures or data loss, minimizing need for reorganization, accommodating growth, and security from unauthorized use.

9-15. What are the four steps in logical database modeling and design?

The four steps in logical database modeling and design are: (1) develop a logical data model for each known user interface for the application using normalization principles; (2) combine normalized data requirements from all user interfaces into one consolidated logical database model; (3) translate the conceptual E-R data model for the application into normalized data requirements, and (4) compare the consolidated logical database design with the translated E-R model and produce one final logical database model for the application.

9-16. What are the four steps in transforming an E-R diagram into normalized relations?

The four steps are (1) represent entities; (2) represent relationships; (3) normalize relations; and (4) merge the relations.

Problems and Exercises Solutions 9-17. Assume that at Pine Valley Furniture products are comprised of components, products are assigned to salespersons, and components are produced by vendors. Also assume that in the relation PRODUCT(Prodname, Salesperson, Compname, Vendor) Vendor is functionally dependent on Compname, and Compname is functionally dependent on Prodname. Eliminate the transitive dependency in this relation and form 3NF relations.

The wording in the problem clarifies some of the relationships and associated cardinalities. Since VENDOR is functionally dependent on COMPNAME, there can be at most one vendor for each component (and we will assume that there may be no vendor for a given component). Also, since COMPNAME is functionally dependent on PRODNAME, there can be at most one component per product (a rather odd situation, but that is what the wording says; we will assume that some products have no components). Although not clarified in the problem, we will assume that a product is assigned to exactly one salesperson, while a salesperson can be assigned to one-to-many products. Given these clarifications, the 3NF relations are (foreign keys are shown with a dashed underline): PRODUCT (Prodname, Salesperson, Compname) SALESPERSON (Salesperson) COMPONENT (Compname, Vendor) VENDOR (Vendor)

.

Chapter 9

Designing Databases

11

9-18. Transform the E-R Diagram of Figure 7-20 into a set of 3NF relations. Make up a primary key and one or more nonkeys for each entity that does not already have them listed.

Listed below are 3NF relations for the E–R diagram. Foreign keys are shown with a dashed underline. The SHOPPING_CART entity is called a weak or attributive entity, since its existence depends on instances of all three entities CUSTOMER, ORDER and INVENTORY; however, the SHOPPING_CART entity has its own primary key.

The 3NF relations are: CUSTOMER (Cust_ID, Name, Address) ORDER (Order_ID, Date) INVENTORY (Inv_ID, Item_name, Weight) SHOPPING_CART (Cart_ID Cust_ID, Order ID, INV ID, Qty) 9-19. Transform the E-R diagram of Figure 9–21 into a set of 3NF relations.

Listed below are 3NF relations for the E–R diagram. Foreign keys are shown with a dashed underline. QUOTE QUANTITY is not sufficient as the primary key of the PRICEQUOTE relation, but this attribute along with the primary keys of the two associated entities is a sufficient concatenated (or composite) primary key for this associative entity. The PART RECEIPT entity is called a weak or attributive entity, since its existence depends on a PRICE QUOTE entity instance. In this case, however, the PART RECEIPT entity has its own primary key, ORDER NO. The 3NF relations are: VENDOR (Vendor No, Address) PRICEQUOTE (Vendor No, Item No, Quote Quantity, Price) PART (Item No, Desc) PART RECEIPT (Order No, Vendor No, Item No, Quote Quantity, Date, Order_Quantity) 9-20. Consider the list of individual 3NF relations that follow. These relations were developed from several separate normalization activities.

PATIENT(Patient_ID, Room_Number, Admit_Date, Address) ROOM(Room_Number, Phone, Daily_Rate) PATIENT(Patient_Number, Treatment_Description, Address) TREATMENT(Treatment_ID, Description, Cost) PHYSICIAN(Physician_ID, Name, Department) PHYSICIAN(Physician_ID, Name, Supervisor_ID)

.

Chapter 9

Designing Databases

12

a. Merge these relations into a consolidated set of 3NF relations. Make and state whatever assumptions you consider necessary to resolve any potential problems you identify in the merging process. b. Draw an E-R diagram for your answer to part a.

Listed below are merged 3NF relations for this hospital example. This is an interesting exercise because it points out how semantically lacking the relational data model is, since questions arise about functional dependencies across separately developed relations. One observation is clear: The second 3NF PATIENT relation in the exercise has only one value of TREATMENT DESCRIPTION, so each patient must be associated with only one treatment, otherwise this relation would not be in 3NF. But, we must also assume that each department has only one supervisor and each supervisor can supervise only one department. This last assumption means that we could create only a supervisor or a department relation, but not both. This is sufficient because, if the original set of six 3NF relations is comprehensive, there are no nonkey attributes dependent on either DEPARTMENT or SUPERVISOR ID. We, however, create both supervisor and department relations, with a one-to-one relationship between them, to allow for some evolution of the data model. One additional assumption about supervisors: SUPERVISOR is a separate entity from PHYSICIAN. We also assume that the attribute ADDRESS means the same address in both PATIENT relations, and further there are no other synonyms or homonyms across the relations. Interestingly, there is no relationship between patient and physician implied in the original 3NF relations, and we assume none exists. With these assumptions, the merged relations are (foreign keys are shown with a dashed underline): PATIENT (Patient Number, Address, Room No, Admit Date, Treatment ID) ROOM (Room No, Phone, Daily Rate) PHYSICIAN (Physician ID, Name, Department ID) TREATMENT (Treatment ID, Description, Cost) SUPERVISOR (Supervisor ID, Department ID) DEPARTMENT (Department ID, Supervisor ID) To create the E-R diagram from these 3NF relations, we have to make additional assumptions about minimum cardinalities. We assume that every patient is assigned a room, but a room may be empty; not all treatments have to be associated with a patient, but a patient has to have a treatment; and that each department has one supervisor and each supervisor has one department. We show relationships from both a department and a supervisor to a physician, but only one is necessary; we also assume that a physician must be associated with both a department and a supervisor. This is an interesting E-R diagram since it contains two, disconnected parts. This is possible, although rare in actual organizations.

The following is an E-R diagram, including attributes, for this situation. Microsoft Visio was used to create the E-R diagram.

.

Chapter 9

Designing Databases

13

Problem Exercise # 9-20 Problem and and Exercise #4 Room PK

RoomNumber Phone DailyRate

Treatment PK,I1

TreamentID Department

Description Cost

PK,I1

DepartmentID

I2

SupervisorID

Patient PK PatientNumber PK,FK1,I3,I2 TreatmentID Address AdmitDate RoomNumber

Physician PK,I3 PhysicianID PK,FK1,I2,I1 DepartmentID

Supervisor PK,I3 PK,FK1,I2,I1

SupervisorID DepartmentID

Name SupervisorId

9-21. Consider the following 3NF relations about a sorority or fraternity: MEMBER(Member_ID, Name, Address, Dues_Owed) OFFICE(Office_Name, Officer_ID, Term_Start_Date, Budget) EXPENSE(Ledger_Number, Office_Name, Expense_Date, Amt_Owed) PAYMENT(Check_Number, Expense_Ledger_Number, Amt_Paid) RECEIPT(Member_ID, Receipt_Date, Dues_Received) COMMITTEE(Committee_ID, Officer_in_Charge) WORKERS(Committee_ID, Member_ID) a. Foreign keys are not indicated in these relations. Decide which attributes are foreign keys and justify your decisions. b. Draw an E-R diagram for these relations, using your answer to part a. c. Explain the assumptions you made about cardinalities in your answer to part b. Explain why it is said that the E-R data model is more expressive or more semantically rich than the relational data model.

There are several foreign keys in these relations. OFFICER_ID is a foreign key in OFFICE referencing MEMBER_ID from the MEMBER relation. OFFICE_NAME is a foreign key in EXPENSE referencing OFFICE_NAME in the OFFICE relation.

OFFICER_IN_CHARGE is a foreign key in COMMITTEE referring to

.

Chapter 9

Designing Databases

14

OFFICER_ID or OFFICE_NAME (which is not clear from simply the relations) in the OFFICE relation. EXPENSE_LEDGER_NUMBER is a foreign key in PAYMENT referencing LEDGER_NUMBER in the EXPENSE relation.

MEMBER_ID in both RECEIPT and WORKERS cross references MEMBER_ID in the MEMBER relation. COMMITTEE_ID in WORKERS cross references COMMITTEE_ID in COMMITTEE. It is inferred that a member sometimes has many receipts, but a receipt must have a member. An expense sometimes has multiple payments, but each payment must have an expense. Each office sometimes has multiple expenses, but each expense must have an office. Each office may have a member as an officer–in– charge, and each member sometimes holds many offices. An office sometimes is responsible for many committees, and each committee must have an office in charge (although that office may not have a member assigned as officer).

Committees sometimes have many workers, and each worker sometimes works on many committees. The E-R diagram is more expressive in that it displays explicitly the minimum cardinalities of relationships and shows exactly which entities are related.

A suggested E-R diagram is provided below. Microsoft Visio was used to prepare this diagram.

.

Chapter 9

Designing Databases

15

Problem and Exercise #9-21 Problem and Exercise 5

Member PK,I1

MemberID Name Address Dues_Owed Receipt PK PK,FK1,I1

Dues_Received

Office PK

PK,FK1,I2

OfficeName Officer_ID Term_Start_Date Budget

Workers

ReceiptDate MemberID

MemberNo

Expense PK PK,FK1

Ledger_Number Office_Name Expense_Date Amt_Owed

Committee_ID

Committee PK PK

CommitteeID Officer_In_Charge

Payment PK

Check_Number Amt_Paid Expense_Ledger_Number

9-22. Consider the following functional dependencies: Applicant_ID →Applicant_Name Applicant_ID →Applicant_Address Position_ID →Position_Title Position_ID →Date_Position_Opens Position_ID →Department Applicant_ID + Position_ID→Date_Applied Applicant_ID + Position_ID + Date_Interviewed → a. Represent these attributes with 3NF relations. Provide meaningful relation names. b. Represent these attributes using an E-R diagram. Provide meaningful entity and relationship names.

Since there are four determinants among the functional dependencies, there will be four relations. The last functional dependency, the one with only a three-key composite determinant, signifies all the dates on which a particular applicant interviewed for a particular position. This functional dependency does not signify a many-to-many relationship, like many composite keys do, since date interviewed

.

Chapter 9

Designing Databases

16

is itself not a determinant. It signifies an entity with a three-component composite key. The four 3NF relations are: APPLICANT (Applicant ID, Applicant Name, Applicant Address) POSITION (Position ID, Position Title, Date Position Opens, Department) APPLICATION (Applicant ID, Position ID, Date Applied) INTERVIEW (Applicant ID, Position ID, Date Interviewed) See the accompanying E-R diagram corresponding to these four relations.

Microsoft Visio was used to prepare the following E-R diagram.

9-23. Suppose you were designing a file of student records for your university's placement office. One of the fields that would likely be in this file is the student's major. Develop a coding scheme for this field that achieves the objectives outlined in this chapter for field coding.

The objectives of a good coding scheme are to minimize storage space and to increase data integrity. Student major is a classical example of a sparse field that could benefit from being codified for storage and data entry. For online data entry, we would probably provide a list of possible majors from which the data entry person must choose; this legal list of codes will need to be updated, but this can probably be done separately from data entry of student data. A fundamental coding choice is whether to use codes that are as dense as possible or to try to use reasonably dense codes that have some meaning to most users (e.g., MIS vs.

31 for a Management Information Systems major). Short character string codes (e.g., three alphabetic characters) may take as little storage as a two digit numeric code, so a short character string may achieve both objectives. An interesting way to approach this question is to have your students identify how their university and at least two other universities represent a student’s major. Have your students

.

Chapter 9

Designing Databases

17

compare and contrast these coding schemes. It is likely that they will locate universities where the code is numeric, alphabetic, or alphanumeric.

9-24. In Problem and Exercise 9-19 you developed integrated normalized relations. Choose primary keys for the files that would hold the data for these relations. Did you use attributes from the relations for primary keys or did you design new fields? Why or why not?

Suggestions for the primary keys are underlined in the following relations. Foreign keys are shown with dashed underlines.

VENDOR(Vendor No, Address) PRICEQUOTE(Vendor No, Item No, Quote Quantity, Price) PART(Item No, Desc) PART RECEIPT(Order No, Vendor No, Item No, Quote Quantity, Date, Order Quantity) If Vendor No, Item No, and Order No are numeric values assigned without any relationship to the associated entities, then these numbers would not change as the real world changes, and they would be acceptable as primary keys or components of composite primary keys. Quote Quantity, on the other hand, is very likely to be volatile, and is not suitable as part of the primary key for the PRICEQUOTE table. We need to create a nonintelligent primary key for the PRICEQUOTE table. Also, we still may need individual secondary index keys on Vendor No and Item No attributes from this relation to facilitate joining the PRICEQUOTE table with the VENDOR and PART tables, respectively.

9. Suppose you created a file for each relation in your answer to Problem and Exercise 9-19. If the following queries represented the complete set of accesses to this database, suggest and justify what primary and secondary key indexes you would build. a. For each PART in Item_Number order list in Vendor_ID, sequence all the vendors and their associated prices for that part. b. List all PART RECEIPTs, including related PART fields for all the parts received on a particular day. c. For a particular VENDOR, list all the PARTs and their associated prices that VENDOR can supply.

The guidelines for identifying keys for indexing suggest that attributes used for selection, sorting, grouping, and joining are potential candidates. We are asked to consider the three queries as the only accesses to the database, so we do not implicitly need primary key indexes. We do not know the frequency of the three queries compared to update operations, so it is impossible to make precise, optimal decisions on the most economical indexes. Space does not seem to be an issue since, as we will see, none of the qualifying fields are very long. So, we indicate all possible indexes that might speed query processing.

.

Chapter 9

Designing Databases

18

The first query, Query A, appears to need to access the PART and PRICEQUOTE tables, but actually the PRICEQUOTE table is sufficient. The E-R diagram indicates that every part has at least one vendor, so every part has at least one price quote. Thus, all parts appear at least once in the PRICEQUOTE table. The data to be reported in Query A (Item No, Vendor No, Quote Quantity, and Price) can all be found in the PRICEQUOTE table. The query asks for the results to be sorted by Item No and by Vendor No (but not by quote quantity). A composite index on these two attributes would be the most efficient way to directly produce this sorted output, thus avoiding the need to do a sort of the data once it is retrieved. This assumes that the DBMS or file system can utilize a composite index when it sees the compound sorting condition. Thus, for Query A, a secondary composite index on first Item No and then Vendor No would be ideal.

The second query, Query B, asks to display all the attributes from the PART RECEIPT and PART tables; since ITEM NO is an attribute in the PART RECEIPT relation, we do not need the PRICEQUOTE relation to link the PART RECEIPT and PART tables. No sorting is done, but the query wants data for only a specified part receipt date. Assuming that many days of part receipt data are kept, then we would want to create a secondary key index on DATE and a secondary key index on ITEM NO in the PART RECEIPT table and a primary key index on ITEM NO in the PART table to efficiently support the selection and joining needed for Query B. The third query, Query C, involves selection of a particular vendor and display of attributes from all associated PRICEQUOTE rows for that vendor; thus, all the data needed for this query can be found in the PRICEQUOTE table. No sorting is mentioned. Thus, for Query C, only a secondary key index on Vendor No in the PRICEQUOTE table would support efficient processing.

9-26. Suppose you were designing a default value for the marriage status field in a student record at your university. What possible values would you consider and why? How would the default value change depending on other factors, such as type of student (undergraduate, graduate, professional)?

You might set the default value to Single for undergrad student (maybe even grad students). Perhaps if your university has an executive or professional program (such as an executive MBA), the default marital status might change.

9-27. Consider Figure 9–19(B). Explain a query that would likely be processed more quickly using the denormalized relations rather than the normalized relations.

One suggested answer is a situation where an employee needs to know a contact name for a vendor, a quoted price for a particular item, and a description for the item. Since the tables are denormalized, this query would require the joining of only two tables; however, if we are using normalized relations, this query would require the joining of all three relations.

.

Chapter 9

Designing Databases

19

9-28. Consider your answers to parts a and b of Problem and Exercise 7-27 in Chapter 7. a. Transform the E-R diagram you developed in part a into a set of 3NF relations. Clearly identify primary and foreign keys. Explain how you determined the primary key for any many-to-many relationships or associative entities. b. Transform the E-R diagram you developed in part b into a set of 3NF relations. Clearly identify primary and foreign keys. Explain how you determined the primary key for any many-to-many relationships or associative entities.

Suggested answers are provided below. Primary keys and foreign keys were identified using the guidelines provided in the chapter. The ASSIGNMENT relation includes Project_ID and Employee_ID as foreign keys. These attributes enable relationships to be established between the PROJECT and CHEMIST relations. For the ASSIGNMENT relation, Assignment_No is used as the primary key, guaranteeing a unique value for each record.

CHEMIST(Employee_ID, Name, Phone_No) PROJECT(Project_ID, Start_Date) EQUIPMENT(Serial_No, Cost) ASSIGNMENT(Assignment_No, Project_ID,Employee_ID, Serial_No, Assign_Date) For the college course, Course_ID serves as the primary key for the COURSE relation. For the SECTION relation, COURSE_ID, Section_No., and Semester_ID serve as the composite key.

COURSE(Course_ID, Course_Name, Units) SECTION(Course_ID, Section_No, Semester_ID) 9-29. Model a set of typical family relationships—spouse, father, and mother— in a single 3NF relation. Also include nonkey attributes name and birth date.

Assume that each person has only one spouse, one father, and one mother.

Show foreign keys with dotted underlining.

Person (Person_ID, Name, Birth_date, Spouse_ID, Father_ID, Mother_ID)

Discussion Questions Solutions 9-30. Many database management systems offer the ability to enforce referential integrity. Why would using such a feature be a good idea? Are there any situations in which referential integrity might not be important?

If the DBMS offers this ability, it should always be used. The possibility that referential integrity will never be violated as engineers interact with a database is very low, and having the system enforce the principle will reduce human error.

There should be no situations in which referential integrity is not important.

.

Chapter 9

Designing Databases

20

9-31. Assume you are part of the systems development team at a medium-sized organization. You have just completed the database design portion of the systems design phase, and the project sponsor would like a status update.

Assuming the project sponsor is a VP in the marketing department, with only a high-level understanding of technical subjects, how would you go about presenting the database design you have just completed? How would your presentation approach change if the project sponsor were the manager of the database team?

Answers will vary. Presenting to a non-technical manager should be much more high-level, with few if any technical details. The focus should be on how the database design will benefit the business (for example, with faster report generation). Presenting to a technical manager would be focused much more on the technical aspects of the database, with less of a focus on the business benefits of the design.

9-32. Discuss what additional information should be collected during requirements analysis that is needed for file and database design and that is not very useful for earlier phases of systems development.

Students should identify several types of information that are most useful for file and database design. Information as it relates to primary keys, secondary keys, data types, business rules, relationships, data integrity control methods, volume, present and future required data storage space, and file organization should be collected.

9-33. Find out what database management systems are available at your university for student use. Investigate which data types these DBMSs support. Compare these DBMSs based upon data types supported and suggest which types of applications each DBMS is best suited for based on this comparison.

There are probably several DBMSs available at the student’s university. For example, the student’s PC laboratory is likely to have at least one DBMS available; perhaps Microsoft Access for Windows is available. A client-server or object-oriented DBMS might be available as well. In addition, the university’s administrative database applications are probably run on a mainframe or minicomputer. A DBMS such as IBM’s DB2 or the Oracle DBMS are probably being used. The data types supported by these DBMSs will provide important criteria for determining what types of applications each of these DBMSs is best suited. PC DBMSs tend to have fewer physical file and database design options than do mini- or mainframe computer-based DBMSs. In addition, students may also have to consider the number of records and physical file organizations that the DBMS allows, the available storage space on physical storage mediums, the record locking and other security features that the DBMS provides, the availability of a CASE tool, and other factors.

.

Chapter 9

Designing Databases

21

9-34. Find out what database management systems are available at your university for student use. Investigate what physical file and database design decisions need to be made. Compare this list of decisions to those discussed in this chapter. For physical database and design decisions (or options) not discussed in the chapter, investigate what choices you have and how you should choose among these choices. Submit a report to your instructor with your findings.

Your students should find that many of the physical file and database design issues presented in the chapter are dealt with at their university as well. For instance, storage space, file organizations, and data types are issues that must be addressed.

Case Problems Solutions 9-35. Pine Valley Case Exercises Solutions a. Develop logical data models for the form and two reports mentioned in the case scenario.

Students should use the Customer Profile Form, Products By Demographics Summary Report, and the Customer Purchasing Frequency Report that they created in the previous chapter. Therefore, the answers to this question are dependent on the data collected on the form and shown on the two reports. For discussion purposes, you can use the following entities.

For the Customer Profile Form, the following relations are identified. Also note that only one profile relation is identified. However, separate profile relations could be created based on the type of customer. For clarification purposes, the ChildNo references the birth order of the customer’s children and is unique for each customer; however, this attribute’s value is not unique within the DEPENDENTS relation.

CUSTOMER(CustID, FirstName, LastName, StreetAddress, City, State, Zip, TypeNo) CUSTOMERTYPE(TypeNo, TypeDescription) DEPENDENTS(CustID, ChildNo, ChildBirthDate, ChildGender) PROFILE(CustID, PurchaseVisits, FirstPurchaseDate, MonthlyStoreVisits, BirthDate, Occupation, Income, Married?, SpouseName, Children?, Dollars?, FirstTimeCustomer, RegionNo) ADVERTISING(PromotionNo, ProDescription)

.

Chapter 9

Designing Databases

For the Customer Purchasing Frequency Report, the following relations are identified.

CUSTOMER(CustID, MonthlyStoreVisits, TypeNo) CUSTOMERTYPE(TypeNo, TypeDescription) For the Products By Demographics Summary Report, the following relations are identified.

CATEGORY(CategoryNo, CategoryDescription) CUSTOMER(CustID, BirthDate) REGION(RegionNo, RegionDescription) PURCHASE(PurchaseNo, ProductNo, PurchaseDate, CustID) PRODUCT(ProductNo, ProductDescription, Price, CategoryNo) b. Perform view integration on the logical models developed for part a.

A suggested answer is provided below.

CUSTOMER(CustID, FirstName, LastName, StreetAddress, City, State, Zip, TypeNo) CUSTOMERTYPE(TypeNo, TypeDescription) DEPENDENTS(CustID, ChildNo, ChildBirthDate, ChildGender) PROFILE(CustID, PurchaseVisits, FirstPurchaseDate, MonthlyStoreVisits, BirthDate, Occupation, Income, Married?, SpouseName, Children?, Dollars?, FirstTimeCustomer, RegionNo) ADVERTISING(PromotionNo, ProDescription) PURCHASE(PurchaseNo, ProductNo, PurchaseDate, CustID) PRODUCT(ProductNo, ProductDescription, Price, CategoryNo) CATEGORY(CategoryNo, CategoryDescription) REGION(RegionNo, RegionDescription) c. What view integration problems, if any, exist? How should you correct these problems?

Student answers for this question will vary. However, your students should identify several occurrences of synonyms, homonyms, and dependencies between nonkeys. Students could easily use the attribute name ‘description’ within the CUSTOMERTYPE, REGION, ADVERTISING, and CATEGORY relations, thus creating a homonym. The attribute ‘address’ may also exist as a homonym. The customer identification number can be represented in several ways, such as CID, CustNo, and Cust#.

.

22

Chapter 9

Designing Databases

23

d. Have a fellow classmate critique your logical data model. Make any necessary corrections.

Student answers for this question will vary. However, this exercise provides a valuable learning experience for your students. Fellow students may recognize synonyms, homonyms, and data dependencies between nonkeys that were overlooked by their designers. If this is the case, ask your students why they think this happened.

9-36. Hoosier Burger Case Exercises Solutions a. Develop logical models for each of the interfaces mentioned in the case scenario.

Students should use the Hoosier Burger forms and reports that they created in the last chapter. Therefore, their answers for this question will vary. However, to facilitate discussion a suggested answer is provided below. Also, attributes whose values are derived are not indicated in the following relations.

For the Delivery Customer Order Form, the following relations were identified.

DELIVERY(DeliveryNo, DeliveryDate, CustID, Charge?, SpecialInstructions, DeliveryAddress, City, State, Zip) CUSTOMER(CustID, FirstName, LastName) ITEM(ItemNo, ItemDescription, ItemPrice) DELIVEREDITEM(DeliveryNo, ItemNo, Quantity) For the Customer Account Balance Form, the following relations were identified.

CUSTOMER(CustID, LastName, FirstName, BillingAddress, City, State, Zip) DELIVERY(DeliveryNo, DeliveryDate, CustID, Charge?)

CUSTOMERACCOUNT(TransactionNo, TransactionDate, DeliveryNo, CustID, ChargeAmount, Payment) For the Daily Delivery Summary Report, the following relations were identified.

ITEM(ItemNo, ItemDescription, ItemPrice) DELIVEREDITEM(DeliveryNo, ItemNo, Quantity) For the Low-In-Stock Report, the following relation was identified. Since the amount to reorder is calculated, its attribute is not shown in the following relation.

ITEM(ItemNo, ItemDescription, Quantity, ReorderLevel)

.

Chapter 9

Designing Databases

24

b. Integrate the logical models prepared for part a into a consolidated logical model.

DELIVERY(DeliveryNo, DeliveryDate, CustID, Charge?, SpecialInstructions, DeliveryAddress, City, State, Zip) CUSTOMER(CustID, FirstName, LastName, BillingAddress, City, State, Zip) ITEM(ItemNo, ItemDescription, ItemPrice, Quantity, ReorderLevel) DELIVEREDITEM(DeliveryNo, ItemNo, Quantity) CUSTOMERACCOUNT(TransactionNo, TransactionDate, DeliveryNo, CustID, ChargeAmount, Payment) c. What types of problems can arise from view integration? Did you encounter any of these problems when preparing the consolidated logical model?

View integration can create several problems, including synonyms, homonyms, and dependencies between nonkey attributes. Students may recognize date as a homonym; they may also recognize several synonyms for the customer’s identification number. One area of concern is how to treat the Customer’s account information. Students will probably identify alternative ways for modeling this data. d. Using your newly constructed logical model, determine which fields should be indexed. Which fields should be designated as calculated fields?

Student recommendations will vary. However, the chapter's guidelines suggest specifying a unique index for the primary key of each table, foreign keys, and nonkey fields that are referenced in qualification, sorting, and grouping commands for the purpose of retrieving data. At a minimum indexes should be established for the primary keys and foreign keys. The current balance, dollar sales, and reorder amount fields are calculated fields.

9-37. PlowMasters Case Exercises Solutions a. What are the four steps in logical database modeling and design?

(See items 1-4 under “The Process of Database Design” in the first section of the chapter.) b. Several relations have been identified for this project, including removal technician, customer, service provided, equipment inventory, and services offered. What relationships exist among these relations? How should these relationships be represented?

Service provided would be related to one or more removal technicians, to one (and only one) customer, one or more pieces of equipment, and to one or more services offered. Services offered might also be related to one or more pieces of equipment.

.

Chapter 9

Designing Databases

25

c. Think of the attributes that would most likely be associated with the relations identified in the part b. For each data integrity control method discussed in the chapter, provide a specific example.

Default value: service provided would have a date attribute, and the default value should logically be the current date.

Input mask: the customer phone number field in the customer relation would have an input mask, forcing all numbers to follow a certain format for uniformity.

Range control: the date attribute in the service provided relation should be controlled such that dates in the future are not permitted.

Referential integrity: since a service provided must be related to a customer, the attribute referencing the customer (e.g., customer_id) should be constrained the set of customer_id values from the customer relation.

Null value control: some null values would be disallowed (like the customer_id field from the previous example). Others might make sense, like a fuel type attribute in the equipment relation. Not all pieces of equipment will take fuel (e.g., a shovel), so leaving the fuel type attribute as null would be acceptable. d. What are the guidelines for choosing indexes? Identify several fields that should be indexed.

For guidelines for choosing indexes, see the three steps in the “Indexed File Organizations” subsection in the “Arranging Table Rows” section.

There should be an index for the each of the primary keys. There should be an index for the foreign keys. And if other data fields are used often, an index can be specified to aid in the retrieval of that information. For example, if there is a frequent need to know the date on which a service was provided for a given customer name, then indexes for the date attribute in service provided, and the name attribute in customer should be created.

Petrie’s Electronics Case Question Solutions 9-38. In the questions associated with the Petrie’s Electronics case at the end of Chapter 7, you were asked to modify the E-R diagram given in Figure 7-1 to include any other entities and the attributes you identified from the Petrie’s cases. Review your answers to these questions, and add any additional needed relations to the document in Figure 9-1.

Answers will vary, according to previous answers in the case at the end of Chapter 7.

9-39. Verify that the relations you say represent the Petrie’s Electronics database are in third normal form. If they are, explain why. If they are not, change them so that they are.

Answers will vary, according to previous answers in the case at the end of Chapter 7.

.

Chapter 9

Designing Databases

26

9-40. The E-R diagram you developed in questions in the Petrie’s Electronics case at the end of Chapter 7 should have shown minimum cardinalities on both ends of each relationship. Are minimum cardinalities represented in some way in the relations in your answer to Question 9-39? If not, how are minimum cardinalities enforced in the database?

Answers will vary, according to previous answers in the case at the end of Chapter 7.

9-41. Using your answer to Case Question 9-39, select data types, formats, and lengths for each attribute of each relation. Use the data types and formats supported by Microsoft Access. What data type should be used for nonintelligent primary keys?

Answers will vary, according to previous answers in the case at the end of Chapter 7. Nonintelligent primary keys should be numeric data types.

9-42. Complete all table and field definitions for the Petrie’s Electronics case database using Microsoft Access. Besides the decisions you have made in answers to the preceding questions, fill in all other field definition parameters for each field of each table.

Answers will vary.

9-43. The one decision for a relational database that usually influences efficiency the most is index definition. What indexes do you recommend for this database? Justify your selection of each index.

Answers will vary, according to previous answers in the case at the end of Chapter 7.

9-44. Using Microsoft Visio, develop an E-R diagram with all the supporting database properties for decisions you made in Case Questions 9-38 to 9-43.

Can all the database design decisions you made be documented in Visio?

Finally, use Visio to generate Microsoft Access table definitions. Did the table generation create the table definitions you would create manually?

Answers will vary, according to previous answers in the case at the end of Chapter 7.

.

Chapter 10

Systems Implementation and Operation

1

Chapter 10 Systems Implementation and Operation Chapter Overview Chapter 10 introduces students to many of the activities carried out during implementation and operation, including coding, testing, installation, documentation, user training, support, and maintenance. This chapter demonstrates that implementation is neither simple nor mechanical. Systems development is a change process, and for many users, the most obvious evidence of change comes during implementation.

Once a new system has been coded, tested, and installed, the systems development team does not simply walk away. The organization members left with the new system, the users, will need a solid understanding of how the new system fits into their work lives and how the system can support them in their day-to-day work activities. User documentation, training, and continuing support are all parts of providing this solid understanding. In some organizations, other specialists in the IS department, such as technical communicators, trainers, local experts, and help desk employees, will be available to help the analyst complete this part of the implementation process. In other organizations, the analyst may have to do most of this work alone. In the latter case, the importance of user documentation, training, and support should not be overlooked. The success of a system implementation effort depends on what the users think of the system and their inclination to use it well. The training and support effort will have a definite effect on user attitudes and inclinations.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor's point of view, the objectives of this chapter are to: 1. Discuss with students the subprocesses that make up system implementation.

2. Teach students about the many different types of testing that occur in implementation and when each one is appropriate.

3. Show students how to prepare a test plan for an information system.

4. Have students distinguish among four installation strategies: direct, parallel, single location, and phased installation and know when to use each one.

5. Explain the difference between system and user documentation, emphasizing that system documentation has been occurring throughout the SDLC. 6. Demonstrate the many different modes available for training users, including tutorials, courses, self-training, electronic performance support systems, and other types of embedded training.

.

Chapter 10

Systems Implementation and Operation

2

7. Show students how to prepare a training plan for an information system.

8. Explain to students the issues associated with user support, whether internal or external to the organization.

9. Explain and contrast four types of maintenance.

10. Describe several factors that influence the cost of maintaining an information system and apply these factors to the design of maintainable systems.

11. Illustrate the role of CASE when maintaining information systems.

Classroom Ideas 1. Most students will have completed programming courses and will be familiar with both coding and testing. Ask them to think about coding and testing in the context of what they have learned about systems development. What methods can they suggest that would help manage coding and testing in an on-going systems development project, as opposed to a series of isolated programming class projects?

2. Have students generate a test plan for one or more of the various systems development projects presented in the text; for example, Hoosier Burger’s foodordering system or its inventory control system. Alternatively, have students develop a testing plan (at a general level) for a major packaged software release, such as a new version of a popular DBMS (e.g. Microsoft Access or Oracle’s DBMS) or a major application system, such as SAP. 3. Present a series of information system implementation scenarios. Have students determine which strategy should work for each scenario and why.

4. Many students have not seen very sophisticated program and system testing environments. It is likely that they have used some form of debugger, but they probably have not seen or used more thorough testing systems. Have your students locate articles about commercial testing software. If possible, you might contact these firms to get documentation or demonstration software and videos to use in class.

5. Encourage your students to think about being a user, not a developer or IS specialist, in which one’s focus is on doing the job, not using the software. You might bring in a “user’s manual” for a common product (e.g., a TV, VCR, microwave oven) and have the students analyze the features of this manual that make it a good or bad manual.

6. Have students bring in examples of documentation. Some students will have access to documentation prepared for customized applications developed for a variety of purposes and computer platforms. Have students present their documentation to the class. They should show at least the table of contents and samples from different sections of the documentation.

.

Chapter 10

Systems Implementation and Operation

3

7. Use Table 10–5 as the starting point for a discussion of the various training modes.

Prepare an example that utilizes several modes, so students can see how training varies by mode. For example, how would training for an order processing system operator look if the training were a tutorial? If it were a formal course? If it were provided by a local expert (e.g., the operator at the next station)? If it were embedded in the order processing software?

8. Have students include a detailed training plan in the user documentation they turn in as part of their semester projects. Have at least one group/student present their training plan in class for discussion.

9. Have students compare and contrast the different types of user support discussed in the chapter. For a particular system or job, which types of support would they, as users, prefer and why? Use this in-class discussion to develop recommendations on when to use the different forms of user support.

10. Ask an IS professional at a local organization to come in and discuss how his or her organization manages user documentation, training, and support. Ask this guest to discuss such topics as: • How is documentation tested?

• Who manages updates and distribution of updated documentation?

• How is updating documentation coordinated with updating the software?

• What training methods do they employ?

• Who does training and how are trainers trained?

• How much does the organization spend on information systems training as a percentage of the total IS budget or IS development budgets?

• How much does the organization spend on information systems support as a percentage of the total IS budget?

• How have the help desk and information center functions changed over time?

• What is their experience with EPSS? 11. Another very effective in-class exercise is to ask students who have maintained an information system to compare their experiences to the concepts presented in Chapter 10. This discussion can be a good way to elaborate on key system maintenance issues (e.g., role of CASE, how quality was measured, where change requests came from, etc.).

12. If you have access to practicing systems analysts, an insightful activity is to invite them into your class to discuss how they manage maintenance in their organization.

Lecture Notes Systems implementation and operation is the last phase of the systems development life cycle. As Figure 10–1 shows, this phase consists of coding, testing, installation, documentation, training, support, and maintenance. Specifically, this chapter identifies where coding and testing fits in the overall scheme of implementation, stresses the view of implementation as an organizational change process, discusses the importance and

.

Chapter 10

Systems Implementation and Operation

4

types of documentation and training, overviews the types of testing, and introduces four types of installation.

Systems Implementation and Operation The seven major activities of systems implementation and operation are: coding, testing, installation, documentation, training, support, and maintenance. During this phase, analysts are responsible for many activities, including the activities leading up to an operational system, activities that are necessary for successful system operation, and activities that are ongoing and needed to keep the system working and up-to-date.

Although actual testing is performed during system implementation, test planning begins during the analysis phase. Once coding has begun, testing begins and proceeds in parallel with the coding activity. Installation replaces the current system with the new system.

The coding, testing, and installation processes result in several deliverables; Table 10–1 identifies these deliverables. Code documentation is crucial to the continual and smooth operation of the system. Additionally, program and system testing results, a user’s guide, a user training plan, an installation and conversion plan, a hardware and software installation schedule, a data conversion plan, and a site and facility remodeling plan are important deliverables.

Documentation receives formal attention during the implementation and operation phase. Documentation is prepared for two audiences: (1) the information systems personnel who will maintain the system throughout its productive life and (2) the people who will use the system as part of their daily lives.

Table 10–2 lists the deliverables from documenting the system, training users, and supporting users. These deliverables address documentation, a user training plan, user training modules, and a user support plan.

Maintaining an information system involves returning to the beginning of the SDLC and repeating development steps. Maintenance has four major steps; these include obtaining maintenance requests, transforming requests into changes, designing changes, and implementing changes. Figure 10–2 shows the maintenance activities in relation to the SDLC phases.

The deliverables and outcomes of the maintenance process are the development of a new version of the software and new versions of all design documents developed or modified during the maintenance process. Main differences between new development and maintenance include: (1) maintenance reuses most existing system modules in producing the new system version, (2) a new system is developed when there is a change in the hardware or software platform, and (3) a new system is developed if the fundamental assumptions and properties of the data, logic, or process models change.

Software Application Testing

.

Chapter 10

Systems Implementation and Operation

5

Although the actual testing activities are performed during implementation, testing begins earlier in the SDLC. During analysis an overall test plan is prepared; a unit test plan, an integration test plan, and a system test plan are prepared during system design.

Table 10–3 identifies several different types of tests, including inspections, walkthroughs, desk checking, syntax checking, unit testing, integration testing, system testing, and stub testing. Figure 10–3 presents the guidelines for conducting a code walkthrough.

Important issues to keep in mind about testing are that the purpose of testing is to confirm that the system satisfies requirements and that testing must be planned. As part of test planning, a set of test cases is developed. Figure 10–4 shows a test case description and summary form. A test case is a specific scenario of transactions, queries, or navigation paths that represent a typical, critical, or abnormal use of the system. A test case should be repeatable; and it needs to determine whether the new software works with other existing software. Figure 10–5 presents a testing harness called AppPerfect for analyzing Java source code.

Upon completion of system testing, acceptance testing is performed. Acceptance testing determines if the new system meets user requirements and varies with the organization and the system in question. Acceptance testing includes both alpha testing, beta testing, and a system audit. Alpha testing includes recovery testing, security testing, stress testing, and performance testing.

Installation Installation is the organizational process of changing over from the current information system to a new one. Direct, parallel, single location, and phased are four approaches to installation. Figure 10–6 and Table 10–4 compare these four installation approaches.

Implementing the chosen installation strategy involves converting software, data, hardware, documentation, work methods, job descriptions, offices and other facilities, training materials, business forms, and other aspects of the system. Installation also involves choosing an appropriate time to install the system and being aware of the business cycle.

Documenting the System Each system requires both system documentation and user documentation. System documentation provides detailed information about a system’s design specifications, its internal workings, and its functionality. Internal and external documentation are two types of system documentation.

User documentation is written or other visual information about how an application system works and how to use it. Figure 10–7 shows an example of online user documentation for Microsoft Visio. Types of user documentation include reference guides, quick reference guides, user guides, release descriptions, system administrator’s guides, and acceptance sign-offs. Figure 10–8 illustrates the structure of an online

.

Chapter 10

Systems Implementation and Operation

6

reference user’s guide. Although user-oriented documentation is often supplied by the information systems department, vendors and the end users are now sources of useroriented documentation.

Training and Supporting Users Support provides ongoing educational and problem-solving assistance to information system users. Although training varies by system type and the user’s expertise, potential training topics include system use, general computing concepts, information system concepts, organizational concepts, system management, and system installation. Training delivery occurs in several ways. Table 10–5 summarizes these methods, including resident expert, computer-aided instruction, formal courses, software help components, tutorials, interactive training manuals, and external sources. Newer types of training include videos, interactive television, multimedia training, online tutorials, and electronic performance support systems (EPSS).

Support is often automated through online support forums, bulletin board systems, ondemand fax, and voice-response systems. Additionally, organizations provide internal support by using automated issue tracking, automating support, and they may provide support through a help desk. Figure 10–9 shows an example of an automated issue tracking system and Table 10–6 identifies typical information that is collected in an issue tracking system. An organization may use a help desk, a single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department. Support includes providing recovery and backup, disaster recovery, and PC maintenance; writing newsletters and offering other types of proactive information sharing; and setting up user groups.

Why Implementation Sometimes Fails The two conditions necessary for a successful implementation effort are management support of the system under development and the involvement of users in the development process. Factors influencing implementation success or failure include risk, commitment to the project, commitment to change, extent of project definition and planning, and realistic user expectations. The extent to which a system is used and the user’s satisfaction of a system determines implementation success. Whether a user will use the new system is determined by the relevancy of the system to the user’s work, the ease of use and reliability of the system, user demographics, system uses, and user satisfaction.

Project Closedown Project close down involves closing down the project, conducting postproject reviews, and closing the customer contract. After a system is in operation, a system audit is often conducted.

.

Chapter 10

Systems Implementation and Operation

7

Conducting Systems Maintenance Maintenance refers to changes made to a system to fix or enhance its functionality.

Table 10–7 summarizes the types of maintenance. The types of maintenance include corrective, adaptive, perfective, and preventive.

Some organizations allocate as much as 80 percent of their information systems budget to maintenance activities. Several factors influence a system’s maintainability; these include latent defects, number of customers for a given system, quality of system documentation, maintenance personnel, tools, and well-structured programs.

The number of failures, time between each failure and the type of failure are measures of maintenance effectiveness. The mean time between failures is a measurement of error occurrences that can be tracked over time to indicate the quality of a system.

Managing maintenance requests is an important maintenance activity. Figure 10–10 is a flowchart showing how to control maintenance requests.

Configuration management assures that only authorized changes are made to a system. A system librarian monitors the baseline modules and keeps copies of the build routines.

When maintaining Web sites, special issues and procedures may arise. These issues include 24 x 7 x 365, checking for broken links, re-registration, and future editions.

Maintaining an Information System at Pine Valley Furniture In this chapter, Pine Valley Furniture’s Purchasing Fulfillment System is used to illustrate information systems maintenance.

PVF WebStore: Systems Implementation and Operation Using Pine Valley Furniture’s WebStore as an example shows that systems implementation and operation is no different than the processes used for other types of applications. Table 10–8 identifies several tests that were performed for Pine Valley Furniture’s WebStore.

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

inspections (14)

17.

perfective maintenance (22)

2.

desk checking (9)

18.

stub testing (26)

3.

electronic performance support system (EPSS) (11) user documentation (33)

19.

baseline modules (4)

20.

system librarian (29)

4.

.

Chapter 10

Systems Implementation and Operation

5.

direct installation (10)

21.

phased installation (23)

6.

adaptive maintenance (2)

22.

configuration management (7)

7.

unit testing (32)

23.

system testing (30)

8.

installation (15)

24.

maintenance (19)

9.

mean time between failures (MTBF) (20)

25.

internal documentation (17)

10.

external documentation (12)

26.

support (27)

11.

acceptance testing (1)

27.

beta testing (5)

12.

build routines (6)

28.

corrective maintenance (8)

13.

preventive maintenance (24)

29.

single location installation (25)

14.

system documentation (28)

30.

alpha testing (3)

15.

parallel installation (21)

31.

help desk (13)

16.

integration testing (16)

32.

testing harness (31)

33.

issue tracking software (18)

8

Review Questions Solutions 10-1. What are the deliverables from coding, testing, and installation?

The deliverables from coding, testing, and installation are: (1) from coding, code and program documentation; (2) from testing, test scenarios and test data and the results of program and system testing; and (3) from installation, user guides, user training plans, and installation plans.

10-2. Explain the testing process for code.

The testing process involves testing code for errors and functionality. The testing process, guided by a detailed testing plan, can begin as soon as modules are coded and proceeds in parallel with the rest of the coding process. Modules are tested individually and then as parts of larger programs and parts of larger systems.

.

Chapter 10

Systems Implementation and Operation

9

10-3. What are the four approaches to installation? Which is the most expensive? Which is the most risky? How does an organization decide which approach to use?

The four approaches to installation are direct, parallel, single location, and phased. With the direct approach, the old system is turned off, and the new one is turned on. In the parallel approach, both systems are run until management decides the old system can be turned off. In single location, the system is tried out in a pilot project at one location and then implemented elsewhere if the pilot is successful. With the phased approach, the new system is brought online gradually, usually function by function. Parallel is usually the most expensive due to the redundant costs, and direct is usually the most risky due to the potential hazards if the new system fails. An organization decides which approach to use depending on the scope and complexity of the change and the organization’s risk aversion.

10-4. List and define the factors that are important to successful implementation efforts.

Several factors are important to the successful implementation of a system, including management support, the involvement of users, and user expectations.

Additionally, commitment to the project, commitment to change, and extent of project definition and planning are important. Commitment to the project refers to managing the project so that the problem being solved is well understood and the target system actually solves the problem. Commitment to change means being willing to change behaviors and procedures. The premise of project definition and planning is that more extensive planning is more effective than less extensive planning.

10-5. What is the difference between system documentation and user documentation?

System documentation is the detailed information about a system’s design specifications, its internal workings, and its functionality, whereas user documentation consists of written or other visual information about an application system, how it works, and how to use it.

10-6. List and define the various methods of user training.

Methods of training include resident experts, computer-aided instruction, formal courses, software help components, tutorials, interactive training manuals, and external sources. Descriptions of these methods are provided in the chapter.

10-7. Describe the delivery methods many vendors employ for providing support.

Vendors provide support through the following mechanisms: automated support, such as online support forums; bulletin board systems; on-demand fax; voiceresponse systems; help desk support; and technical support 800 telephone units, all or some of which can be either external or internal to the user organization.

.

Chapter 10

Systems Implementation and Operation

10

10-8. List the steps in the maintenance process and contrast them with the phases of the systems development life cycle.

Four major activities occur within maintenance; these are obtaining maintenance requests, transforming requests into changes, designing changes, and implementing changes. The first phase of the SDLC, systems planning and selection, is analogous to the maintenance process of obtaining a maintenance request. The systems analysis phase is analogous to the maintenance process of transforming requests into a specific system change. Systems design is similar to the designing changes process. Finally, the systems implementation and operations phase is similar to implementing changes. This similarity between the maintenance process and the SDLC is no accident. The concepts and techniques used to initially develop a system are also used to maintain it.

10-9. What are the different types of maintenance and how do they differ?

Corrective, adaptive, perfective, and preventive are the four types of maintenance.

Corrective maintenance is concerned with repairing design and programming errors; adaptive maintenance modifies the system to reflect environmental changes; perfective maintenance evolves the system to solve new problems or take advantage of new opportunities; preventive maintenance safeguards the system from future problems.

10-10.Describe the factors that influence the cost of maintenance. Are any factors more important? Why? Latent defects, number of customers for a given system, quality of system documentation, maintenance personnel, tools, and well-structured programs are factors that influence the cost of maintenance. Of these factors, three were described as being very important: defects, customers, and documentation. The number of latent defects refers to the number of unknown errors existing in the system after it is installed. Because corrective maintenance accounts for most maintenance activity, the number of latent defects in a system influences most of the costs associated with maintaining a system. If there are no errors in the system after it is installed, then maintenance costs will be relatively low. If there are a large number of defects in the system when it is installed, maintenance costs will likely be high. A second factor influencing maintenance costs is the number of customers for a given system. In general, the greater the number of customers, the greater the maintenance costs. A third major contributing factor to maintenance costs is the quality of system documentation. Without quality documentation, maintenance efforts can increase exponentially.

10-11. What types of measurements must be taken to gain an understanding of the effectiveness of maintenance? Why is tracking mean time between failures an important measurement?

To measure effectiveness, you must measure the number of failures, time between each failure, and type of failure. Measuring the number and time between failures will provide you with the basis to calculate a widely used measure of system quality. This metric is referred to as the mean time between failures (MTBF). As its name implies, the MTBF measure shows the average length of time between the identification of one system failure to the next. Over time, you should expect the MTBF value to rapidly increase after a few months of

.

Chapter 10

Systems Implementation and Operation

11

use (and corrective maintenance) of the system. If the MTBF does not rapidly increase over time, it will be a signal to management that major problems exist within the system that are not being adequately resolved through the maintenance process.

10-12. Describe the process for controlling maintenance requests. Should all requests be handled in the same way or are there situations when you should be able to circumvent the process? If so, when and why?

The chapter presents a flowchart that suggests one possible method for dealing with maintenance change requests. This chart suggests that you must determine the type of request. If, for example, the request is an error—that is, a corrective maintenance request—then the flowchart shows that a question must be asked related to the error's severity. If the error is “very” severe, then the request has top priority and is placed at the top of a queue of tasks waiting to be performed on the system. If, however, the error is considered not very severe, then the change request can be categorized and prioritized based upon its type and relative importance. If the change request does not concern an error, then you must determine if the request is to adapt the system to technology changes and/or business requirements or to enhance the system so it will provide new business functionality. For adaptation requests, they too will need to be evaluated, categorized, prioritized, and placed in the queue. For enhancement type requests, they must first be evaluated to see if they are aligned with future business and information systems plans. If not, the request will be rejected and the requester will be informed. If the enhancement appears to align with business and information systems plans, it is then prioritized and placed into the queue of future tasks.

The method for reviewing maintenance requests strongly suggests that all requests should not be handled in the same way. The process also suggests what should be done with different types of requests. In situations where there is a catastrophic failure of the system, time may be of the essence, and a formal review of a request will take too long. In such a situation, the formal evaluation process is circumvented.

10-13.What is meant by configuration management? Why do you think organizations have adopted the approach of using a systems librarian?

Configuration management is the process of assuring that only authorized changes are made to a system. A system librarian controls the baseline source code modules. If maintenance personnel are assigned to make changes to a system, they must first check-out a copy of the baseline system modules because no one can directly modify the baseline modules. This ensures that only those modules that have been checked-out and then formally checked-in can reside in the library. Organizations have adopted this approach so that before any code can be checked back into the librarian, they must pass the quality control procedures, testing, and documentation standards established by the organization.

.

Chapter 10

Systems Implementation and Operation

12

Problems and Exercises Solutions 10-14.Consider the reasons implementations fail. For at least three of these reasons, explain why this happens, if there is one (or more) type of implementation likely to minimize the occurrence, and if there is one (or more) type of installation more likely to induce failure for this reason.

•

•

•

•

•

There are several reasons for failed implementation, some of which can be exacerbated by the methods chosen for installation. Some of the reasons include: Lack of commitment to the project – Management and employee commitment are important to the successful implementation of an information system. Parallel installation can signal a lack of commitment by management. Direct installation, on the other hand, shows a complete confidence in making the system a success. Phased and single location installations can demonstrate successes, increasing commitment to the project so that the benefits of the new information system can be extended, either across all locations (in a single location installation) or across all functions (in a phased installation).

Lack of commitment to change – Much like commitment to the project, users must also be willing to change how they accomplish their work to include the new information system. Parallel implementation is more likely to leave users wishing to use the old system which could eventually lead to a failed implementation.

Direct installation makes it more difficult to choose not to change, as restoring the old system can be difficult, time-consuming, and costly. Single location installation and phased installation can increase commitment by showing early successes with the system as a motivation for change in the other users.

Poorly conceptualized system – Systems may fail because they were not properly conceptualized or developed. This indicates a serious lack of planning and project definition. The form of installation would not be likely to impact this cause for failure.

Unrealistic user expectations – Users may not completely understand what the information system can and cannot do. When the users form unrealistic expectations, they are guaranteed to be disappointed by the system. Both direct and parallel installations are likely to enhance these feelings of disappointment; parallel installations let users see how the new system doesn’t solve all of the problems of the old system while direct installation may lead users to a feeling of nostalgia for the old system. Phased and pilot installations can be used to educate users as to what the new system will (and will not) do.

Users refuse to use the system – Users may simply refuse to use the system.

This however usually happens for one of the other reasons listed. It can also happen because of characteristics of the users themselves. For instance, workers who have done their job the same way for 20 years may be resistant to the change irrespective of the information system involved. The installation method is not likely to influence these user-centric characteristics.

.

Chapter 10

Systems Implementation and Operation

13

Additionally, characteristics of the information system may make use of the system unpalatable. Cumbersome interfaces and error-riddled software can lead to low satisfaction. Direct installation is more likely to cause problems as phased, parallel, and pilot installations are more likely to discover issues before the product is rolled out to all users or when there is a backup readily at-hand (in the case of parallel).

•

Political reasons – Implementation may fail because of the misalignment of personal goals of politically powerful people. In such cases, the method of installation is unlikely to impact the outcome.

10-15.Two members of your project development team are disagreeing about the relative importance of training and documentation. Sam strongly believes that training is far more important because it will ensure the successful implementation of the information system and that the early usage is a positive experience. Pat counters that the user documentation is far more important because its impact can help not only the current users, but also future users. Which do you think is right, and why?

Training and documentation are both critical to the success of the system.

Students should choose one and justify their position. Some answers they may include are: Training: • Training users on the systems can increase productivity • Training can help users accept the need for change and prepare mentally for that process • Training can improve the perception of the system as they will know better how to use it • Training is more often customized to the particular functions the employee must do User documentation: • Documentation will remain available even after trainers have left • Documentation can answer questions not thought of until the system is in use • Users are more motivated to learn when they need to know, how to do an actual task, leading to “just-in-time knowledge” • User documentation can provide graphical representations of processes whereas training often just describes them in words

.

Chapter 10

Systems Implementation and Operation

14

10-16.Why is it important to keep a history of test cases and the results of those test cases even after a system has been revised several times?

It is important to keep a history of test cases and results for a number of reasons.

First, it is a good idea for the systems personnel to keep a clear record of what testing was done so that, if problems with the system occur later on, the systems personnel can show that they did, in fact, conduct tests. Second, if problems do occur even after a series of tests, the track record of testing will help the systems personnel to rule out pieces of the system that were tested as potential sources of these new system problems. Third, particularly for a situation where there have been several revisions of a system, there may be a need to retrace the steps of the system development back through the test history to diagnose problems or, worse, to make a decision to revert back to a former version of the system.

Fourth, the history of test cases provides at least a baseline of test cases for future versions and results from prior tests to which results from current tests can be compared when possible.

10-17.What is the purpose of electronic performance support systems? How would you design one to support a word processing package? A database package?

The purpose of an EPSS is to provide convenient online help embedded directly within the software package. The user never has to leave the application in order to gain the benefits of training. Users can learn a new system on their own time, on their own machines, without having to lose work time to remote group training sessions. Many application packages now incorporate “intelligent” features that assist the user when necessary.

10-18.Due to advances in technology and widespread computer literacy, many organizations use e-learning extensively to train employees. If you were managing a system implementation and had to train on a limited budget, you may find yourself choosing between e-learning or conducting face-toface training with a subset of users who would then train their departments (called train-the-trainers). Which would you choose and why?

Each method has benefits and challenges. Students should choose a method and support their answer with the benefits, including: Benefits of train-the-trainers: 1. Face-to-face interaction can ensure that the users understand the material presented. If there are misunderstandings, the trainer can clarify immediately.

2. By having end-users become the trainers, the knowledge they gain from training should be more customized to the processes and culture of their organization.

3. Face-to-face training can help users form personal relationships with the trainers. As such, when problems arise, they may feel more comfortable contacting that trainer directly.

.

Chapter 10

Systems Implementation and Operation

15

Benefits of e-learning: 1. All of the users can receive training from the trainers; as such, one person’s misconceptions will be less likely to impact a large number of people.

2. The training can be presented when and where it is most convenient.

3. Training sessions can be recorded and re-presented periodically to enhance the ongoing training.

10-19.Is it good or bad for corporations to rely on vendors for computing support? List arguments both for and against reliance on vendors as part of your answer.

The arguments for and against relying on outside vendors for support are similar to the arguments for and against outsourcing in general. For a variety of reasons, outsourcing of nearly all aspects of information systems is becoming more and more popular. There are many reasons for relying on vendors for support. This can be a less expensive means for support. For example, the organization does not have to maintain its own in-house staff for this function, independent of demand. In addition, the organization can have state-of-the-art, professional support, and they do not have to worry as much about technological and methodological changes in support. Some of the reasons against relying on vendors for support include: (1) vendor support can be more expensive if not negotiated and/or planned well; (2) vendor’s employees might not be familiar with this specific technology and/or situation; (3) vendor’s employees might not be committed to the customer organization’s mission, goals, and objectives; and (4) there is a potential that trade secrets may be compromised.

10-20.Suppose you were responsible for establishing a training program for users of Hoosier Burger's inventory control system (described in previous chapters). Which forms of training would you use? Why? The students are likely to come up with a variety of ideas for training the users of Hoosier Burger’s inventory control system. What they propose to do is not as important as the soundness of the arguments they use to support their proposed methods. Given that the organization and user base are relatively small, one sound strategy would be to offer a short course for the few people that would be using the system. This course could be offered by someone from within the organization or could be outsourced to an external vendor. In addition, some software help components should be built into the system with the help of the users. A crucial element of the training program would be how to handle employee turnover, to the extent that people other than Bob and Thelma will use the system. Possibly a video tape or online tutorial, to be used as part of the overall orientation program for new employees, would be a good approach.

10-21.Suppose you work in a senior management position for a large corporation. A member of your team has suggested that your company outsource the helpdesk functions. Would you support a plan to outsource your helpdesk? Support your answer.

The helpdesk is a point of contact for all users to call when they have a problem.

Several organizations have outsourced this service. Students should choose an answer and support it with pros and cons, some of which are listed below:

.

Chapter 10

Systems Implementation and Operation

16

Pros: • Helpdesk personnel are difficult to find, train, and retain. Outsourcing may provide access to the human resources that are difficult to find.

• Helpdesk support often deals with basic problems that can be answered by any technologically savvy person. In those cases, and outsourced helpdesk will be capable of responding to problems without added delay or hassle.

• Outsourcing helpdesk functions may allow IT groups to focus on valuegenerating processes such as systems development.

Cons: • Outsourced helpdesks are unlikely to be able to provide detailed information for idiosyncratic systems.

• Assistance which requires in-house knowledge will likely take longer than if the helpdesk were kept in-house.

• Helpdesk operation is critical to an organization’s ability to support the end users but outsourcing partners may not provide the level of service needed to support those end users.

• Language barriers and different meanings for similar technical terms can cause problems if the outsourcing occurs across borders or industries.

• Users are more likely to turn to in-house experts than to rely on outside sources.

10-22.If you were an analyst on a project team developing a new information system and you were given the task of organizing the user documentation, you would probably not be able to create all of the content by yourself from memory. List three sources you would tap for the documentation and explain how you would have to modify it for end-users.

Many sources can be used to generate user documentation. They can include: 1. System documentation – This documentation describes the inner workings of the system. Such documentation can sometimes suggest how the functionality operates, leading to an understanding of what the user may need to know. However, such documentation would require a change in focus from the designers, implementers, and administrators to the end users. In addition, technical jargon may need to be replaced with language the intended user is likely to understand.

2. Internal documentation – This documentation can be found within the source code itself or generated automatically from the code. These are typically highly technical but may specifically describe how aspects of the information system are designed to work. As such, use of internal documentation is likely to require a similar change of focus and language as system documentation.

3. External documentation – This documentation includes the diagrams and other outputs from the system design process. As such, the intended uses

.

Chapter 10

Systems Implementation and Operation

17

of the software should be described. Use of such documents as the basis for user documentation is likely to require the analyst to interpret the experiences a user will face when actually interacting with the information system.

4. Other systems analysts – Systems analysts should have a very good understanding of what the users need, what the system is designed to do, and how it will be used. Collecting the knowledge from the various systems analysts may help in generating useful user documentation. Such contributions will probably require very little modification.

5. Programmers – Often programmers can give valuable insight into what the system will do and how users will need to do it. This is because the programmers will be intimately aware of the assumptions and choices made during development. Their input will likely need to be summarized and contextualized for the user documentation.

6. Users themselves – Some user documentation is generated by the users themselves. If a phased implementation has been used, then users may have created documentation for their own use or to help others. Collecting such documentation may help in crafting user documentation. It is most likely to be customized to how the work is done; however, it should be carefully checked for accuracy.

10-23.In what ways is a request to change an information system handled differently from a request for a new information system?

For the most part, a request to change an information system is handled much like a request for a new information system. For a new system request, the systems personnel must estimate the duration and scope of the project and assess its risk and feasibility. However, a change request is handled somewhat differently. For instance, the systems personnel must determine how the requested change will affect the current system. Also, change requests are often batched together into a maintenance project to gain some economies of scale and to minimize the frequency of change for users. Thus, change requests interact with one another, and may be modified to meet conflicting and complementary needs of different requests. One could argue that for a new information system the parallel would be that systems personnel must determine how the new information system will affect and interact with other current information systems and business processes.

10-24.What can a systems analyst do to reduce the frequency of corrective maintenance, the most common form of maintenance?

To reduce corrective maintenance the answer is clear: do a better job in analyzing, designing, coding, and implementing (including testing) new information systems. There is no better way to reduce the number of repairs to an information system than to do an effective, thorough job in the development process. Usually the most expensive errors to correct are those that fix incorrect requirements, so doing a thorough job in analysis (both requirements determination and structuring) not only reduces the need for corrective maintenance, but also provides the extensive documentation that can reduce

.

Chapter 10

Systems Implementation and Operation

18

maintenance time. Also, building systems using common tools and languages makes it easier for a variety of highly-trained maintenance personnel to quickly do their job. However, there are some problems requiring corrective maintenance that cannot be avoided or even foreseen. For example, some components purchased and installed from a third party as part of a new information system may later be found to be defective. A “Murphy’s Law” approach would be to do as good a job as possible in designing, coding, and implementing the system, and then be prepared for when the inevitable problems occur.

10-25.What other information should be collected on a System Service Request for maintenance as opposed to a System Service Request for a new system?

The intent of an SSR is to briefly state the business problem or opportunity, along with general ideas of how to address the problem or opportunity. Pine Valley’s SSR does provide this information. However, the SSR could be modified to indicate the type of request (maintenance or new system development) being requested. Students will provide additional recommendations.

10-26.What can a systems analyst do to facilitate future maintenance?

All forms of maintenance require developers to update the information system, usually by modifying the source code. As such, proper documentation is critical for future maintenance work. However, careful documentation is often not provided by the programmers, as they assume that nobody else will need to read the code, or that the purpose of the code is obvious. A system analyst can ensure that every module of code contains comments (a form of internal documentation), as well as to retain the external documentation from which the information system was built.

In addition, changes to the system through the development process should be reflected in external documentation. Finally, systems analysts can ensure that the documents are available to the maintenance team.

10-27. Suppose an information system were developed following a rapid application development approach like prototyping. How might maintenance be different than if the system had been developed following the traditional life cycle? Why? RAD follows the same SDLC processes; however, these phases are combined and shortened. The problems of the RAD approach are indicative of some of the maintenance problems that might arise. For instance, RAD shortens the planning and design phases and often develops systems in isolation. A system may require rework because all of its requirements were not adequately identified or it now needs to better integrate with other systems.

10-28.This chapter contains a warning that maintenance activities could lead to further corrective maintenance work if not carefully designed and implemented. What processes or procedures can organizations use to reduce the likelihood of this occurring?

The likelihood of a corrective maintenance request after maintenance activities is increased when proper development techniques are not followed in carrying out the maintenance activity. The same procedures used in the software development process should be used during maintenance such as planning, testing, and

.

Chapter 10

Systems Implementation and Operation

19

installation. Corrected versions of software must be installed much as a new information system would be.

Discussion Questions Solutions 10-29. If possible, ask a systems analyst you know or have access to about implementation. Ask what the analyst believes is necessary for a successful implementation. Compare what the analyst believes are the factors that influence successful implementation to the factors discussed in this chapter.

It will be useful for students to compare their answers to this question. This way they can learn about the perceptions of a variety of systems professionals.

Students should keep in mind, however, that the perceptions of a handful of professionals in the field are not necessarily generalizable to all system implementations. These bits of anecdotal evidence should be integrated with research on system implementation in order to gain a more complete, accurate, generalizable understanding of system implementation.

10-30. Talk with people you know who use computers in their work. Ask them to get copies of the user documentation they rely on for the systems they use.

Analyze the documentation. Would you consider it good or bad? Support your answer. Whether good or bad, how might you improve it?

If the students find people that use best-selling packaged software, and if these people have available the user documentation that came with this software, then the students are likely to find that this documentation is relatively good and conforms to the guidelines discussed in this chapter. If these users do not have the necessary user documentation for this software, or if these users are using other types of software (e.g., internally developed application systems), then the students are likely to find a variety of quality in the documentation. In some cases, there might not be any documentation at all. For internally-developed systems, the students might inquire about how the documentation is tested and updated as the software evolves. One advantage of packaged software is that given the large number of users, vendors can invest (and need to invest for marketing purposes) in high-quality documentation. Individual organizations, under pressure to reduce the systems development backlog, often compromise on the scope and quality of user documentation.

10-31. Volunteer to work for a shift at a help desk at your school's computer center. Keep a journal of your experiences. What kind of users did you have to deal with? What kinds of questions did you get? Do you think help desk work is easy or hard? What skills are needed by someone in this position?

At a typical help desk at a university (or monitor in a student computing lab), students are likely to encounter users that are students, faculty, staff, administrators, and even people from the community. Users ask a variety of questions, including: “What are the hours of the computer lab?”; “How do I customize a header in my word processor?”; “Can you help me develop an e-mail distribution list for my class?”; “How do I download files from the Internet?”; “Can someone come over and help us with the new student records database?”; “How

.

Chapter 10

Systems Implementation and Operation

20

much does a new laser printer cost?” People might think that this kind of work is relatively easy, but it is not. Solving problems and dealing with people all day long is challenging, sometimes intense work. The diversity of questions is great, and customers are almost always in a hurry with an immediate need for answers. This type of work requires special communication skills, problem solving skills, and love for this kind of work.

10-32. Let's say your professor has asked you to help him or her train a new secretary on how to prepare class notes for electronic distribution to class members. Your professor uses word processing software and an e-mail package to prepare and distribute the notes. Assume the secretary knows nothing about either package. Prepare a user task guide that shows the secretary how to complete this task.

The students’ guides should describe the task completely, in addition to any error messages that the user may see if a problem arises. Given that no word processing package or e-mail system was specified, it is not important that the students describe each step in detail. The students should at least present an outline of their user task guide. Alternatively, if the students know of a way to perform this task using a specific word processor and e-mail system, they should describe how it is done.

10-33. Study an information systems department with which you are familiar or to which you have access. How does this department measure the effectiveness of systems maintenance? What specific metrics are used, and how are these metrics used to effect changes in maintenance practices? If there is a history of measurements over several years, how can changes in the measurements be explained?

Students are likely to find that their organization of choice is using the classical maintenance organizational structure; that is, the maintenance group is separate from the development group. However, many organizations are trying other structures for organizing this function (especially those that locate development and maintenance staff closer to users), so the students may find other forms being used. Students should find that the managers cite advantages to their particular maintenance organizational structure that are similar to those discussed in the chapter. Have the students compare their answers. If there are differences, have the students discuss why these different structures are being used in these different organizational settings. Similarly, if different reasons for using the same structure are cited across different organizations, have the students explore why different reasons were given.

.

Chapter 10

Systems Implementation and Operation

21

Case Problems Solutions 10-34. Pine Valley Case Exercises Solutions a. Locate a technical writing article on the Web. Briefly summarize this article.

Your students will easily locate numerous technical writing articles. Technical writing Web sites are plentiful and provide much information. If time permits, you can ask your students to present their findings to their classmates. You can also ask your students what was the most useful information that they found. b. Which installation options are available for the Customer Tracking System?

Which would you recommend?

Pine Valley has several installation options, and each installation option has its merits and related problems. The most likely options are the direct and phased approaches. The direct installation is the riskiest alternative; phased installation limits the potential harm and costs PVF might incur. c. How can you determine if implementation has been successful?

There are many ways for Pine Valley to determine if implementation has been successful. However, as the chapter suggests, the two most common ways are the extent to which the Customer Tracking System is used and the user’s satisfaction with this new system. d. What conditions are necessary for a successful implementation effort?

The conditions most influential to a successful implementation effort are management support and the end user’s involvement.

10-35. Hoosier Burger Case Exercises Solutions a. What types of training will Hoosier Burger’s end users need?

For the wait staff and cooks, user training is needed. Bob and Thelma can benefit from training in several areas; these areas include system use, general computing concepts, information system concepts, system management, and system installation. b. What types of documentation would you recommend for Hoosier Burger’s end users?

Since Hoosier Burger’s new system should be easy to use, the delivery personnel, wait staff, and cooks may benefit from a reference guide, quick reference guide, and user’s guide. Since Bob and Thelma are involved with the system on different levels, they will benefit from several types of documentation. In particular, they will need a system administrator’s guide, a release description, and acceptance sign-off.

.

Chapter 10

Systems Implementation and Operation

22

c. Which installation strategy would you recommend pursuing?

Hoosier Burger has several options. Since the new system is small and the risks associated with the system are small to moderate, the direct installation approach is an attractive alternative. d. What support issues should be considered?

At a minimum, types of support include recovery and backup, disaster recovery, appropriate documentation, and PC maintenance.

10-37. Kitchen Plus Case Exercise Solutions a. Identify the tasks involved in project closedown.

As mentioned in Chapter 2 and again in this chapter, project closedown involves closing down the project, conducting postproject reviews, and closing the customer contract. b. How would you evaluate Joe’s performance?

Joe’s performance will promote much discussion among the students. You should ask them what type of punishment (if any) Joe should receive. Several students will recommend termination; others will recommend a severe reprimand. c. What types of maintenance problems can you expect from this information system?

This system is like many other systems. The maintenance personnel can expect corrective, adaptive, perfective, and preventive maintenance issues to arise. d. What factors will influence the maintainability of this system?

Latent defects, number of customers for a given system, quality of system documentation, maintenance personnel, tools, and well-structured programs are factors that influence a system’s maintainability.

Petrie’s Electronics Case Question Solutions 10-37.Why don’t information systems projects work out as planned? What causes the differences between the plan and reality?

Information systems projects often do not work out as planned for the same reason most projects don’t work out as planned – requirements change, resources change (increase or decrease), managers change (new managers might have different priorities and other plans), or it becomes evident the problem was not well understood initially so that the original solution is not feasible.

10-38. Why is it important to document change requests? What happens if a development team doesn’t?

.

Chapter 10

Systems Implementation and Operation

23

Requests to change the system go against the original plan, so they add work, cost, and time, and they change functionality. They replace or augment parts of the original plan, so they have to be documented as such. If change requests are not documents, then the actual functionality of the system is not documented, so no one will know what the system will actually do or how different components might interact. Further, management analyses will not take into account the added work, cost and time.

10-39.When a project is late, do you think that adding more people to do the work helps or not? Justify your answer.

This question was answered by Brooks in the Mythical Man Month many years ago. While it is intuitive to think that adding people should help make a late project get back on time, adding people actually makes things worse. More people means more coordination between people and actually slows the project down even more.

10-40. What is the role of a pilot project in information systems analysis? Why do you think the Petrie’s team decided to do a pilot project before rolling out the customer loyalty system for everyone?

Pilots give a project team the opportunity to observe the system in operation, so they can see what works and what doesn’t before deploying the system more widely. Problems can be identified and addressed, affecting few employees or customers. When the problems have been corrected, the system can then be rolled out to the rest of the company. This is the basic logic behind Jim and his team’s decision to have a pilot project.

10-41.Information systems development projects are said to fail if they are late, go over budget, or do not contain all of the functionality they were designed to have. Is the customer loyalty program a failure? Justify your answer. If not, how can failure be prevented? Is it important to avert failure? Why or why not?

While it appears that the system has the designed functionality, it will be both late and over budget. By those measures, the system is a failure. However, calling the system a failure may be a little premature, as a pilot has not even been run yet. Once the pilot has been run, Jim will be in a better position to judge the system’s status. (On the other hand, some students may see the system as a failure now and be able to justify that view.) If the system has all the functionality it was designed to have and works as promised, and the cost and time overruns are relatively small, management may judge the system to be a success after all, especially if customers like it and use it and the system is associated with increased sales. Large cost and time overruns might diminish the success of the system, though, even if the functionality is delivered and customers are happy with the final result. Is it important to avert failure? Generally, yes, as success makes stakeholders happy and can lead to new and bigger projects for people like Jim down the road. No one likes failure. (Some students might have a different view, which could lead to some interesting class discussions.)

.

Appendix A

Object-Oriented Analysis and Design

1

Appendix A Object-Oriented Analysis and Design Chapter Overview Appendix A introduces students to object-oriented analysis and design. OOAD’s increasing popularity is brought about in part because of its ability to represent complex relationships, as well as data and data processing, with a consistent notation. Students are introduced to several techniques that systems analysts can use to perform objectoriented analysis and design. The techniques and notations presented in this chapter include use cases, class diagrams, object diagrams, state diagrams, and sequence diagrams. The Unified Modeling Language (UML) is used to present these techniques and notations.

The object-oriented development life cycle consists of three primary phases: analysis, design, and implementation. An object representation develops more detail as it moves through each of these phases. After a brief introduction to UML, students are shown how to prepare use cases, class diagrams, object diagrams, state diagrams, and sequence diagrams. A component diagram is reviewed at the end of the chapter.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor's point of view, the objectives of this chapter are to: 1. Discuss the similarities and differences between the object-oriented development life cycle and the more traditional systems development life cycle.

2. Show the similarities and differences between object-oriented analysis and design (OOAD) and more traditional, structured systems analysis and design notations and methods.

3. Reinforce the terminology utilized in this chapter.

4. Discuss when each of the modeling techniques would be utilized in the objectoriented development life cycle.

5. Show students how to construct each of the models presented in the chapter.

6. Show and discuss how the models are related to each other.

Classroom Ideas 1. An object-oriented specification can become very extensive since all aspects are integrated into one model, so you will need to use simple examples. After briefly reviewing OOAD terminology and notation, it is recommended that you teach from .

Appendix A

Object-Oriented Analysis and Design

2

examples for the rest of the class. Problem and Exercise 3 is a good example to work in class. The greatest discussion will probably center around what methods should exist and where they should be located (that is, with what object).

2. It is essential that students have a sound understanding of the core concepts of OOAD: object, class, encapsulation, and inheritance. Be sure students can distinguish an object from a data entity instance and a class from an entity type.

Emphasize the ramifications of encapsulation for systems development, which deal primarily with decoupling system components.

3. Compare and contrast the OOAD phases with the traditional SDLC phases. Stress to the students that in the beginning the model is abstract, showing more detail as it moves through the OOAD phases.

4. If you have access to practicing systems analysts, invite them to your class to discuss their usage of OOAD. 5. Stress the benefits of OOAD, especially the increased consistency among the models developed during object-oriented analysis and design.

6. For some students this may be their first exposure to object-oriented analysis and design. One way to approach the presentation of this material is to make heavy use of the figures and illustrations utilized in the chapter. Use these figures and illustrations to reinforce the terminology and diagramming rules presented in the chapter.

Lecture Notes The Object-Oriented Modeling Approach Appendix A introduces students to the techniques and graphical diagrams that systems analysts use for object-oriented analysis and design. The deliverables from project activities using object-oriented modeling include data-flow diagrams, entity-relationship diagrams, and repository descriptions. Benefits associated with the object-oriented modeling approach include: (1) the ability to tackle more challenging problem domains; (2) improved communication among users, analysts, designers, and programmers; (3) reusability of analysis, design, and programming results; and (4) increased consistency among the models developed during object-oriented analysis, design, and programming.

The object-oriented systems development life cycle progressively develops a representation of an object, with the model becoming more detailed as it evolves.

During the analysis phase, a model of the real-world application is prepared. During the design phase, this model is refined and adapted to suit the target implementation environment. During the implementation phase, the design is implemented using a programming language and/or database management system. The Unified Modeling Language is a notation that allows the modeler to specify, visualize, and construct the artifacts of software systems, as well as business models. The UML includes the following techniques and notations: use cases, class diagrams, state diagrams, and sequence diagrams. Using the UML, an analyst represents several views of the system.

.

Appendix A

Object-Oriented Analysis and Design

3

Use-Case Modeling During the analysis phase, analysts perform use-case modeling to help them understand the functional requirements of the system. A use-case model depicts actors and use cases. Figure A–1 shows a use-case diagram for a university registration system. Use cases are initiated by an actor, represent the complete functionality of the system, participate in relationships with other use cases, and may use other use cases. A use case may participate in “extends” or “include” relationships. Figure A–2 shows a usecase diagram for the Hoosier Burger system.

Object Modeling: Class Diagrams The object-oriented approach models the world as objects; an object has a state and exhibits behavior. An object class is a set of objects that share a common structure and a common behavior. Object models include class diagrams and object diagrams.

A class diagram shows the static structure of an object-oriented model; an object diagram is a graph of instances that are compatible with a given class diagram. Figure A–3 shows UML class and object diagrams. On a class diagram, a class is represented as a rectangle with three compartments separated by horizontal lines. On an object diagram, an object is represented as a rectangle with two compartments. An operation is a function or a service that is provided by all the instances of a class. Encapsulation is the technique of hiding the internal implementation details of an object from its external view.

An association is a relationship between object classes. The degree of an association may be unary, binary, ternary, or n-ary. Figure A–4 provides examples of these different degrees. A solid line depicts an association between the participating classes.

An association role is the end of an association where it connects to a class.

Multiplicity is an indication of how many objects participate in a relationship. Figure A– 5 shows binary association relationships.

Representing Generalization Generalization abstracts the common features among multiple classes, as well as their relationships, into a more general class. Generalization generalizes subclasses into superclasses. The basis of generalization is noted by placing a discriminator next to the path. A subclass inherits features from its superclass. Figure A–6 provides examples of generalization, inheritance, and constraints. An abstract class does not have direct instances, but its descendants may have direct instances. In contrast, a concrete class can have direct instances.

Representing Aggregation Aggregation is a part-of relationship between a component object and an aggregate object; it is represented by a hollow diamond at the aggregate end. Figure A–7 provides an example of aggregation.

.

Appendix A

Object-Oriented Analysis and Design

4

Dynamic Modeling: State Diagrams State diagrams model the dynamic aspects of a system. State transitions are the changes in the attributes of an object or in the links an object has with other objects.

State transitions are triggered by events. Figure A–8 shows a state diagram.

Dynamic Modeling: Sequence Diagrams Interaction diagrams show the pattern of interactions among objects for a particular use case. There are two types of interaction diagrams: sequence and collaboration. A sequence diagram is a depiction of the interactions among objects during a certain period of time. Figure A–9 illustrates a sequence diagram. On a sequence diagram, an object is shown as a vertical dashed line. Objects send each other either synchronous messages or simple messages. Collaboration diagrams are not discussed in the chapter.

Designing a Use Case with a Sequence Diagram In this section, the authors show students how to draw a sequence diagram for an instance of the Class registration use case. Students can reference Figure A–9.

Moving to Design Design begins with an existing set of analysis models and adds technical details. Figure A–10 shows an example of UML packages and dependencies. During design, component diagrams are prepared. Figure A–11 shows a component diagram for a class registration system.

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

use-case diagram (25)

14.

aggregation (4)

2.

event (12)

15.

multiplicity (13)

3.

activation (2)

16.

encapsulation (11)

4.

object class (15)

17.

operation (17)

5.

Unified Modeling Language (UML) (23)

18.

state (20)

6.

synchronous message (22)

19.

behavior (7)

7.

association role (6)

20.

class diagram (8)

8.

object diagram (16)

21.

association (5)

9.

state transition (21)

22.

abstract class (1)

Copyright © 2015 Pearson Education, Inc.

Appendix A

Object-Oriented Analysis and Design

10.

object (14)

23.

concrete class (10)

11.

component diagram (9)

24.

sequence diagram (18)

12.

actor (3)

25.

simple message (19)

13.

use case (24)

5

Review Questions Solutions A-1. Compare and contrast the object-oriented analysis and design models with structured analysis and design models.

The biggest difference between the models is that the object-oriented models build on each other and are consistent. Models developed during structured analysis and design are weakly connected and lack a common representation.

A-2. Give an example of an abstract use case. Your example should involve at least two other use cases and show how they are related to the abstract use case.

In Figure A–2, the Track Sales and Inventory Data use case is an example of an abstract use case.

A-3. Explain the use of association role for an association on a class diagram.

The association role is the end of an association where it connects to a class.

The role can be explicitly named, indicating the role played by the class attached to the end at which the name appears. A role will have multiplicity; multiplicity gives an indication of how many objects participate in the relationship.

Copyright © 2015 Pearson Education, Inc.

Appendix A

Object-Oriented Analysis and Design

6

A-4. Give an example of generalization. Your example should include at least one superclass and three subclasses, and a minimum of one attribute and one operation for each of the classes. Indicate the discriminator and specify the semantic constraints among the subclasses.

A suggested answer is provided below

A-5. Give an example of aggregation. Your example should include at least one aggregate object and three component objects. Specify the multiplicities at each end of all the aggregation relationships.

One example of aggregation is a vehicle. A car will have front and side air bags, an air conditioner, an engine, and other components. A suggested diagram is provided below.

Problem and Exercise #5 Vehicle

0..1

1..2 Front Airbags

1..* Side Airbags

1 Air Conditioning

Copyright © 2015 Pearson Education, Inc.

1 Engine

Appendix A

Object-Oriented Analysis and Design

A-6. Give an example of state transition. Your example should show how the state of the object undergoes a transition based on some event.

A suggested answer is provided below.

Problems and Exercises Solutions A-7. The use-case diagram shown in Figure A-1 captures the Student billing function but does not contain any function for accepting tuition payment from students. Revise the diagram to capture this functionality. Also, express some common behavior among two use cases in the revised diagram by using “include” relationships.

A suggested answer is provided below.

Copyright © 2015 Pearson Education, Inc.

7

Appendix A

Object-Oriented Analysis and Design

8

A-8. Suppose that the employees of the university are not billed for tuition.

Their spouses do not get a full-tuition waiver, but pay for only 25 percent of the total tuition. Extend the use-case diagram of Figure A-1 to capture these situations.

A suggested answer is provided below.

Copyright © 2015 Pearson Education, Inc.

Appendix A

Object-Oriented Analysis and Design

9

A-9. Draw a class diagram, showing the relevant classes, attributes, operations, and relationships for the following situation (if you believe that you need to make additional assumptions, clearly state them for each situation). (Note: The scenario is provided on pages 386 and 387 in the textbook.)

A suggested answer is provided below.

Copyright © 2015 Pearson Education, Inc.

Appendix A

Object-Oriented Analysis and Design

10

A-10.

An organization has been entrusted with developing a Registration and Title system that maintains information about all vehicles registered in a particular state. For each vehicle that is registered with the office, the system has to store the name, address, telephone number of the owner, the start date and end date of the registration, plate information (issuer, year, type, and number), sticker (year, type, and number), and registration fee. In addition, the following information is maintained about the vehicles themselves: the number, year, make, model, body style, gross weight, number of passengers, diesel powered (yes/no), color, cost, and mileage. If the vehicle is a trailer, diesel powered and number of passengers are not relevant. For travel trailers, the body number and length must be known.

The system needs to maintain information on the luggage capacity for a car, maximum cargo capacity and maximum towing capacity for a truck, and horsepower for a motorcycle. The system issues registration notices to owners of vehicles whose registrations are due to expire after two months.

When the owner reviews the registration, the system updates the registration information on the vehicle. a. Develop a static object model by drawing a class diagram that shows all the object classes, attributes, operations, relationships, and multiplicities.

For each operation, show its argument list. b. Draw a state diagram that captures all the possible states of a Vehicle object, right from the time the vehicle was manufactured until it goes to the junkyard. In drawing the diagram, you may make any necessary assumptions, as long as they are realistic. c. Select any state or event from the high-level state diagram that you have drawn and show its fine structure (substates and their transitions) in a lower-level diagram. d. One of the use cases for this application is "Issue registration renewal notice,” which is performed once every day. Draw a sequence diagram, in generic form, showing all possible object interactions for this use case.

Suggested answers for parts a, b, c, and d are provided below.

Copyright © 2015 Pearson Education, Inc.

Appendix A

Object-Oriented Analysis and Design

Part a

Part b

Copyright © 2015 Pearson Education, Inc.

11

Appendix A

Object-Oriented Analysis and Design

Part c

Part d For part d, your students can use Figure A–9 as a guide for preparing their sequence diagrams. At a minimum, the sequence diagrams should show the interactions among the registration window, registration entry, customer, vehicle, and title objects.

Copyright © 2015 Pearson Education, Inc.

12

Appendix A

Object-Oriented Analysis and Design

Copyright © 2015 Pearson Education, Inc.

13

Appendix B

Agile Methodologies

1

Appendix B Agile Methodologies Chapter Overview Appendix B introduces students to Agile Methodologies with a focus on eXtreme Programming. Agile Methodologies are compared and contrasted with traditional engineering-based approaches, describing when Agile Methodologies are preferred over the traditional engineering-based approaches. eXtreme Programming, a popular Agile Methodology, is discussed along with its key principles. The end of the appendix discusses how requirements determination, design specifications, and implementation are carried out when using an Agile Methodology.

Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor's point of view, the objectives of this chapter are to: 1. Explain the benefits and usage of Agile Methodologies.

2. Differentiate between Agile Methodologies and engineering-based approaches to systems development.

3. Reinforce the concepts and terminology presented in this chapter.

4. Explain the Agile Methodologies approach to system requirements determination, design specifications, and implementation.

5. Compare and contrast Agile Methodology design activities with the engineeringbased methods.

6. Stress the three key principles of Agile Methodologies and show how these principles help differentiate the Agile Methodologies from the engineering-based approaches.

Classroom Ideas 1. For some students this may be their first exposure to Agile Methodologies. One way to approach the presentation of this material is to make heavy use of the figures and illustrations presented in this appendix.

2. Ask your students to identify and research a specific Agile Methodology, such as Scrum, the Crystal Families, or Feature Driven Development. Ask your students to present their findings to the class.

.

Appendix B

Agile Methodologies

2

3. If you have the class time, assign your students to groups. Ask your students to prepare answers to Problem and Exercise 5. Ask your students to then present their answers to the class.

4. If you have access to practicing systems analysts, invite them to your class to discuss their usage of Agile Methodologies.

Lecture Notes The Trend to Agile Methodologies Systems analysis and design has gone through three distinct phases. These phases include developer-as-artist, developer-as-engineer, and Agile Methodologies. The developer-as-artist phase was marked by a lack of documentation and development tools; developers were seen as more geniuses and artists, and there was a high degree of dependence on the developer for the continued operation of the system. The developer-as-engineer phase brought discipline to the systems analysis and design area. The convergence of the Internet economy and object-oriented approach led to the latest approach, Agile Methodologies. Agile Methodologies favor close cooperation between developers and clients, combine numerous life cycle phases into few phases, and have multiple releases of software.

Agile Methodologies Agile Methodologies is an umbrella term referring to several alternative approaches to systems analysis and design. These alternative approaches include the Crystal Family, Adaptive Software Development, Scrum, Feature Driven Development, and eXtreme Programming, as well as several other approaches. Agile Methodology proponents agree that the Agile Methodologies share three key principles; these principles are: (1) a focus on adaptive rather than predictive methodologies; (2) a focus on people rather than roles; and (3) a self-adaptive process. Figure B–1 shows the Agile Manifesto.

The Agile Manifesto outlines the values and principles agreed to by the seventeen anarchists.

An organization needs different approaches to systems development. An Agile process is recommended when your project involves: (1) unpredictable or dynamic requirements; (2) responsible and motivated developers; and (3) customers who understand and will get involved.

In contrast, an engineer-based approach is recommended when the development team exceeds 100 people and the project has a fixed-price or fixed-scope contract. Table B– 1 summarizes five critical factors that distinguish Agile and traditional approaches to

.

Appendix B

Agile Methodologies

3

systems development. Agile approaches and traditional approaches can be distinguished on size, criticality, dynamism, personnel, and culture.

eXtreme Programming eXtreme Programming is presented as a popular Agile Methodologies example. eXtreme Programming has short development cycles, uses an incremental planning approach, focuses on automated tests written by programmers and customers to monitor the process of development, and relies on an evolutionary approach to development. eXtreme Programming is characterized by two-person programming teams and having a customer on-site during development; it fuses planning, analysis, design, and construction together into a single phase, and uses a unique approach to capturing and presenting system requirements and design specifications. With eXtreme Programming, programmers both write and test the code; only things that can go wrong are tested; code is integrated into the system soon after it has been written; and pair programming is utilized.

The Heart of the Systems Development Process Agile Methodologies combine analysis, design, and implementation activities into a single phase. Figure B–2 illustrates the analysis-design-code-test loop. Agile Methodologies view analysis, design, and implementation as the heart of systems development. Figure B–3 illustrates this point. The iteration between analysis and design is at the core of development agility.

This appendix introduces students to three requirements determination techniques, including continual user involvement, Agile Usage-Centered Design, and the Planning Game. The Continual User Involvement technique encourages constant involvement of users in the analysis and design process. Users provide input about their requirements and then observe and evaluate as the requirements are designed, coded, and tested.

Agile Usage-Centered Design focuses on user roles, user goals, and necessary tasks to accomplish goals. Table B–2 identifies the Agile Usage-Centered Design steps. Of particular interest are the uses of venting sessions and 3 x 5 cards. eXtreme Programming utilizes a Planning Game and an Iteration Planning Game. The Planning Game encourages interaction between Business and Development. Business refers to the customers, and Development refers to the individuals responsible for developing and constructing the system. The Planning Game includes exploration, commitment, and steering phases. Figure B–4 illustrates the Planning Game. During the exploration phase, Story Cards are created. During the commitment phase, Business sorts the Story Cards based on feature priorities. During the steering phase, Business evaluates how development is progressing.

The Iteration Planning Game also has exploration, commitment, and steering phases.

Only programmers play the Iteration Planning Game. During exploration, Story Cards are converted to Task Cards. During commitment, responsibility for tasks is assigned.

During steering, the programmers code, test, and integrate the features into the product.

Agile Methodologies capture the design specifications as part of the design process.

The code serves as the design specifications. eXtreme Programming uses simple

.

Appendix B

Agile Methodologies

4

design and refactoring to improve the design quality. Simple design refers to creating uncomplicated software and software components that work to solve the current problem rather than creating complicated software designed for a future that may not come.

Refactoring makes a program simpler after adding a new feature. According to Beck (2000), eXtreme Programming’s simplest design has four constraints; these include (1) the system must communicate everything you want it to communicate; (2) the system must contain no duplicate code; (3) the system should have the fewest possible classes, and (4) the system should have the fewest possible methods. Forms of refactoring include simplifying complex statements, abstracting solutions from reusable code, and removing duplicate code.

With Agile Methodologies, coding and testing are tightly linked. The same programmers write and test the code. Code is tested and then, if it passes the test, it is implemented into the system.

Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list.

1.

Refactoring (2)

2.

Simple Design (3)

3.

Agile Methodologies (1)

Review Questions Solutions B-1. What are Agile Methodologies?

Agile Methodologies is an umbrella term referring to a group of development approaches that rely on an object-orientation and the need for speed. This group of agile approaches shares three key principles, including a focus on adaptive rather than predictive methodologies, a focus on people rather than roles, and a self-adaptive process.

B-2. Describe the three stages that information systems development has passed through.

Developer-as-artist, developer-as-engineer, and Agile Methodologies are the three stages mentioned in Appendix B. Developer-as-artist is described by a lack of documentation and development tools and a high degree of dependence on the developer. The developer-as-engineer stage saw the introduction of discipline and theory to systems development. Factoring, decomposition, prototyping, documentation, rigorous testing, structure tools and techniques, and computerbased tools are associated with this stage. The object-oriented approach and the Internet economy can be seen as the enabler for the Agile Methodologies. The Agile Methodologies rely on an object-orientation and the need for speed. The Agile Methodologies are characterized by their focus on adaptive rather than predictive methodologies, focus on people rather than roles, and focus on a selfadaptive process.

.

Appendix B

Agile Methodologies

5

B-3. What is at the heart of the systems development process? How does it fit within the larger SDLC framework?

Analysis, design, and implementation are at the heart of the systems development process. The textbook identified four major SDLC phases: (1) planning and selection, (2) analysis, (3) design, and (4) implementation and operation. During systems planning and selection, possible projects are identified, prioritized, and selected for development. During analysis, requirements are identified, documented, and alternative design strategies are generated. During systems design, system specifications are produced. During implementation and operation, coding and testing are done, as well as other operations activities.

B-4. Explain eXtreme Programming. eXtreme Programming is a popular Agile methodology. eXtreme Programming employs short development cycles, an incremental planning approach and automated tests written by programmers. eXtreme Programming actively involves customers in the development process by having the customer onsite during development, uses two-person programming teams (pair programming) and fuses planning, analysis, design, and construction into a single phase. eXtreme Programming uses the Planning Game and Iteration Planning Game techniques.

Both techniques have exploration, commitment and steering phases. The Planning Game involves customers (Business) and the individuals designing and constructing the system (Development). During the Planning Game’s exploration phase, Business prepares Story Cards. Story Cards capture the new system’s requirements. During the commitment phase, Business sorts the Story Cards based on the new system’s mandatory, essential, and desirable features.

Development sorts the cards based on risk. Business selects the cards that will be included in the next product release. During the steering phase, Business monitors the progress and works with Development to make any necessary adjustments.

During the Iteration Planning Game’s exploration phase, Story Cards are converted into one or more Task Cards. During the Iteration Planning Game’s commitment phase, programmers assume responsibility for tasks and balance workloads. During the Iteration Planning Game’s steering phase, programmers write, test, and integrate the code into the system.

B-5. What is continual user involvement?

Continual user involvement is a requirements determination technique that works well with small, dedicated development teams. Continual user involvement encourages the continual involvement of the user during the analysis and design process. Continual user involvement answers one of the criticisms of the traditional, engineering-based approaches. The traditional approaches to systems development are often criticized because of the user’s limited involvement in the development process.

.

Appendix B

Agile Methodologies

6

B-6. What is Agile Usage-Centered Design? How is it used for requirements determination?

Agile Usage-Centered Design is a requirements determination technique for involving users in the requirements determination process. The Agile UsageCentered Design technique has nine steps, eight of which are outlined in Table B– 2. Agile Usage-Centered Design brings together analysts, users, programmers, and testing staff. Everyone is given a chance to “vent” about the current system and identify requirements for the new system. Important user roles are identified and recorded on 3 x 5 cards. These cards are then sorted based on similarity.

This process is called role model. Next, the tasks for the user roles are identified and recorded on 3 x 5 cards. These tasks are ordered by importance and then by frequency. Cards are then sorted based on task similarity. This process is called task model. Tasks cards are clumped together based on similarity and then grabbed; this process is called interaction context. For each task, a description of the task is recorded on the task card and steps required to complete the task are listed on the card. Each set of cards (clump) is treated as a set of tasks to be supported by the user interface. Finally, a user role is assumed and each task is stepped through.

B-7. What is the Planning Game, and what is it used for?

The Planning Game is a requirements determination technique used by eXtreme Programming. The Planning Game encourages active interaction between the individuals who will use the system and those that will develop the system.

B-8. How are design specifications handled in the Agile Methodologies?

Design specifications are captured as part of the design process and continue to evolve with each analysis-design-code-test iteration. For example, a project utilizing Agile Methodologies captures the design specifications as part of the code and does not produce detailed design specifications.

B-9. What is simple design? What is refactoring?

Simple design creates uncomplicated software and software components that work to solve the current problem rather than creating complicated software designed for a future that may not come. Refactoring makes a program simpler after adding a new feature.

B-10. Explain how testing differs in the Agile Methodologies and in traditional approaches.

With Agile Methodologies, coding and testing are intimate parts of the same process. Programmers who write the code also test it, and code is often tested and integrated into the system soon after it is written.

.

Appendix B

Agile Methodologies

7

B-11. What have we learned about Agile development methods in practice?

There are three primary critical success factors Agile development: 1) Continuous delivery (delivery Strategy) of working software in short time scales.

2) Managers and programmers must continually focus on technical excellence and simple Design by following Agile software engineering practices.

3) Projects should be built around motivated individuals (Team Capability).

After implementation Agile methods can lead to several positive outcomes: 1) Improved job satisfaction.

2) Improved programmer productivity.

3) Increased customer satisfaction.

Agile methods work best for Small projects.

Additional lessons learned from Agile Methods in practice are discussed on page 3.89.

Problems and Exercises Solutions B-12. When should you use an Agile method, and when should you use an engineering-based method for developing a system? Support your answer.

An Agile method is recommended if the project has unpredictable or dynamic requirements, responsible and motivated developers, and customers who understand and will get involved. An engineering-based method is recommended when the project operates under a fixed-price or fixed-scope contract. Table B-1 identifies five critical factors that also distinguish Agile and traditional approaches.

These critical factors include size, criticality, dynamism, personnel, and culture.

While Agile methods are well suited for small products and teams, traditional methods are better for large projects and safety-critical systems. Agile methods work better for systems operating in volatile and fluid environments. In contrast, traditional methods work best for projects that will operate in stable environments.

Agile methods may need a critical mass of agility experts and seem to work best in a culture where people are empowered by freedom. In contrast, engineeringbased methods seem to work best where people are more comfortable having their roles defined for them.

B-13. Find books and articles on some of the other Agile Methodologies, such as Scrum and Feature Driven Development. Compare what you find to what you have read in this appendix about eXtreme Programming. Write a report that illustrates the similarities and differences in these approaches.

Martin Fowler has written a nice, informative article on Agile Methodologies.

Currently, the URL is http://www.martinfowler.com/articles/newMethodology.html.

This is a good starting point for students interested in learning more about Agile Methodologies. The article provides an overview of several Agile Methodologies, including Scrum and Feature Driven Development.

.

Appendix B

Agile Methodologies

8

B-14. How widespread are the Agile Methodologies in the information technology industry? Research this question and write a report that explains what you find.

Students will find many articles and Web sites attesting to the growing popularity of Agile Methodologies. For instance, an Agile Business Conference is held in the United Kingdom. More information can be obtained at http://www.agileconference.org/organisation.asp.

B-15. Using the World Wide Web, find a company or firm near you where Agile Methodologies are in use. Interview developers to find out what their approach to development looks like. Prepare a report based on your findings.

Students should easily locate companies that are currently using Agile Methodologies. Ask your students to compare their interview findings to information from the appendix, as well as any articles that they read in preparation for the interview.

B-16. Assume you have been given the task of leading a team developing an online order-entry system. What would your project look like using the structured techniques featured in this book? What would your project look like using an Agile method? Compare and contrast these two different approaches to developing this system. Be sure to include important considerations such as project duration, personnel issues, and the quantity and quality of involvement of the client.

This is an interesting activity for your students to complete. One approach to this question is to divide your students into two or more groups. Have half the groups prepare a project plan for the online order-entry system utilizing a traditional approach. In contrast, have the remaining half prepare project plans for an Agile method. If you have the class time, ask your students to present their findings to the class.

As indicated in the chapter, your students will find that the Agile methods have an adaptive, people-oriented focus. The Agile methods have a strong focus on iterative development, as well as a close relationship between coding and testing.

Students should find that the Agile methods require a more active involvement with the end user, numerous iterations, and less required documentation.

.