Chp-01 - Introduction to Systems Analysis and Design PDF

CHAPTER 1 INTRODUCTION TO SYSTEMS ANALYSIS AND DESIGN C hapter 1 introduces the systems development life cycle (SDLC), the fundamental four- phase model (planning, analysis, design, and implementation) common to all informat...

CHAPTER 1 INTRODUCTION TO SYSTEMS ANALYSIS AND DESIGN C hapter 1 introduces the systems development life cycle (SDLC), the fundamental four- phase model (planning, analysis, design, and implementation) common to all information systems development projects. It describes the evolution of system development method- ologies and discusses the roles and skills required of a systems analyst. The chapter then overviews the basic characteristics of object-oriented systems and the fundamentals of object-oriented systems analysis and design and closes with a description of the Unified Process and its extensions and the Unified Modeling Language. OBJECTIVES Understand the fundamental systems development life cycle and its four phases Understand the evolution of systems development methodologies Be familiar with the different roles played by and the skills of a systems analyst Be familiar with the basic characteristics of object-oriented systems Be familiar with the fundamental principles of object-oriented systems analysis and design Be familiar with the Unified Process, its extensions, and the Unified Modeling Language CHAPTER OUTLINE Introduction Change Management Analyst The Systems Development Life Cycle Project Manager Planning Basic Characteristics of Object-Oriented Analysis Systems Design Classes and Objects Implementation Methods and Messages Systems Development Methodologies Encapsulation and Information Hiding Structured Design Inheritance Rapid Application Development (RAD) Polymorphism and Dynamic Binding Agile Development Object-Oriented Systems Analysis and Selecting the Appropriate Development Design (OOSAD) Methodology Use-Case Driven Typical Systems Analyst Roles and Skills Architecture-Centric Business Analyst Iterative and Incremental Systems Analyst Benefits of Object-Oriented Systems Infrastructure Analyst Analysis and Design 1 2 C h a p t e r 1 Introduction to Systems Analysis and Design The Unified Process The Unified Modeling Language Phases Applying the Concepts at CD Selections Workflows Summary Extensions to the Unified Process INTRODUCTION The systems development life cycle (SDLC) is the process of understanding how an infor- mation system (IS) can support business needs by designing a system, building it, and delivering it to users. If you have taken a programming class or have programmed on your own, this probably sounds pretty simple. Unfortunately, it is not. A 1996 survey by the Standish Group found that 42 percent of all corporate IS projects were abandoned before completion. A similar study done in 1996 by the General Accounting Office found 53 percent of all U.S. government IS projects were abandoned. Unfortunately, many of the systems that are not abandoned are delivered to the users significantly late, cost far more than planned, and have fewer features than originally planned. Most of us would like to think that these problems only happen to “other” people or “other” organizations, but they happen in most companies. Even Microsoft has a history of failures and overdue projects (e.g., Windows 1.0, Windows 95).1 Although we would like to promote this book as a silver bul- let that will keep you from IS failures, we readily admit that a silver bullet that guarantees IS development success simply does not exist. Instead, this book provides you with several fundamental concepts and many practical techniques that you can use to improve the probability of success. The key person in the SDLC is the systems analyst, who analyzes the business situation, identifies opportunities for improvements, and designs an information system to imple- ment them. Being a systems analyst is one of the most interesting, exciting, and challeng- ing jobs around. Systems analysts work with a variety of people and learn how they conduct business. Specifically, they work with a team of systems analysts, programmers, and others on a common mission. Systems analysts feel the satisfaction of seeing systems that they designed and developed make a significant business impact, knowing that they contributed unique skills to make that happen. However, the primary objective of a systems analyst is not to create a wonderful sys- tem; instead, it is to create value for the organization, which for most companies means increasing profits (government agencies and not-for-profit organizations measure value differently). Many failed systems have been abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would fit with an orga- nization’s goals, current business processes, and other information systems to provide value. An investment in an information system is like any other investment, such as a new machine tool. The goal is not to acquire the tool, because the tool is simply a means to an end; the goal is to enable the organization to perform work better so it can earn greater profits or serve its constituents more effectively. This book introduces the fundamental skills a systems analyst needs. This pragmatic book discusses best practices in systems development; it does not present a general survey of systems development that covers everything about the topic. By definition, systems analysts do things and challenge the current way that organizations work. To get the most 1 For more information on the problem, see Capers Jones, Patterns of Software System Failure and Success (London: International Thompson Computer Press, 1996); Capers Jones, Assessment and Control of Software Project Risks (Englewood Cliffs, NJ: Yourdon Press, 1994); Julia King, “IS Reins in Runaway Projects,” Computer world (February 24, 1997).  The Systems Development Life Cycle 3 out of this book, you will need to actively apply to your own systems development project the ideas and concepts in the examples and in the “Your Turn” exercises that are presented throughout. This book guides you through all the steps for delivering a successful informa- tion system. Also, it illustrates how one organization (called CD Selections) applies the steps in one project (developing a Web-based CD sales system). By the time you finish the book, you won’t be an expert analyst, but you will be ready to start building systems for real. This chapter first introduces the basic SDLC that IS projects follow. This life cycle is common to all projects, although the focus and approach to each phase of the life cycle may differ. The next section describes three fundamentally different types of systems development methodologies: structured design, rapid application development, and agile development. The third section describes the roles played by and the skills necessary for a systems analyst. The final four sections introduce the fundamental characteristics of object-oriented systems, object-oriented systems analysis and design, a specific object-oriented systems development methodology (the Unified Process), and a specific object-oriented systems development graphical notation (the Unified Modeling Language). CONCEPTS 1–A An Expensive False Start IN ACTION A real-estate group in the federal government cospon- took a year. Three weeks before technical delivery, the IT sored a data warehouse with the information technology director canceled the project. This failed endeavor cost the (IT) department. In the formal proposal written by IT, costs organization and taxpayers $2.5 million. were estimated at $800,000, the project’s duration was Source: Hugh J. Watson et al., “Data Warehousing Failure: Case Studies estimated to be eight months, and the responsibility for and Findings,” The Journal of Data Warehousing 4, (no. 1) (1999): 44–54. funding was defined as the business unit’s. The IT depart- ment proceeded with the project before it even knew if Questions the project had been accepted. The project actually lasted two years because require- 1. Why did this system fail? ments gathering took nine months instead of one and a 2. Why would a company spend money and time on a half, the planned user base grew from 200 to 2,500, and project and then cancel it? the approval process to buy technology for the project 3. What could have been done to prevent this? THE SYSTEMS DEVELOPMENT LIFE CYCLE In many ways, building an information system is similar to building a house. First, the house (or the information system) starts with a basic idea. Second, this idea is transformed into a simple drawing that is shown to the customer and refined (often through several drawings, each improving on the last) until the customer agrees that the picture depicts what he or she wants. Third, a set of blueprints is designed that presents much more detailed information about the house (e.g., the type of water faucets, where the telephone jacks will be placed). Finally, the house is built following the blueprints, often with some changes directed by the customer as the house is erected. The SDLC has a similar set of four fundamental phases: planning, analysis, design, and implementation. Different projects might emphasize different parts of the SDLC or approach the SDLC phases in different ways, but all projects have elements of these four phases. Each phase is itself composed of a series of steps, which rely upon techniques that produce deliverables (specific documents and files that provide understanding about the project). 4 Chapter 1 Introduction to Systems Analysis and Design For example, in applying for admission to a university, all students go through the same phases: information gathering, applying, and accepting. Each of these phases has steps; for example, information gathering includes steps such as searching for schools, requesting information, and reading brochures. Students then use techniques (e.g., Internet searching) that can be applied to steps (e.g., requesting information) to create deliverables (e.g., evaluations of different aspects of universities). In many projects, the SDLC phases and steps proceed in a logical path from start to finish. In other projects, the project teams move through the steps consecutively, incre- mentally, iteratively, or in other patterns. In this section, we describe the phases, the actions, and some of the techniques that are used to accomplish the steps at a very high level. Not all organizations follow the SDLC in exactly the same way. As we shall shortly see, there are many variations on the overall SDLC. For now, there are two important points to understand about the SDLC. First, you should get a general sense of the phases and steps through which IS projects move and some of the techniques that produce certain deliverables. Second, it is important to under- stand that the SDLC is a process of gradual refinement. The deliverables produced in the analysis phase provide a general idea of the shape of the new system. These deliverables are used as input to the design phase, which then refines them to produce a set of deliverables that describes in much more detailed terms exactly how the system will be built. These deliverables, in turn, are used in the implementation phase to produce the actual system. Each phase refines and elaborates on the work done previously. Planning The planning phase is the fundamental process of understanding why an information system should be built and determining how the project team will go about building it. It has two steps: 1. During project initiation, the system’s business value to the organization is identified: How will it lower costs or increase revenues? Most ideas for new systems come from outside the IS area (e.g., from the marketing department, accounting department) in the form of a system request. A system request presents a brief summary of a business need, and it explains how a system that supports the need will create business value. The IS department works together with the person or department that generated the request (called the project sponsor) to conduct a feasibility analysis. The feasibility analysis examines key aspects of the proposed project: The idea’s technical feasibility (Can we build it?) The economic feasibility (Will it provide business value?) The organizational feasibility (If we build it, will it be used?) The system request and feasibility analysis are presented to an information systems approval committee (sometimes called a steering committee), which decides whether the project should be undertaken. 2. Once the project is approved, it enters project management. During project man- agement, the project manager creates a workplan, staffs the project, and puts tech- niques in place to help the project team control and direct the project through the entire SDLC. The deliverable for project management is a project plan, which describes how the project team will go about developing the system. Analysis The analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used. During this phase, the project team investigates any current system(s), identifies opportunities for improvement, and develops a concept for the new system.  The Systems Development Life Cycle 5 This phase has three steps: 1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy usually includes an analysis of the current system (called the as-is system) and its problems and then ways to design a new system (called the to-be system). 2. The next step is requirements gathering (e.g., through interviews or question- naires). The analysis of this information—in conjunction with input from the project sponsor and many other people—leads to the development of a concept for a new system. The system concept is then used as a basis to develop a set of business analysis models, which describe how the business will operate if the new system is developed. The set of models typically includes models that represent the data and processes necessary to support the underlying business process. 3. The analyses, system concept, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key deci- sion makers (e.g., members of the approval committee) who decide whether the project should continue to move forward. The system proposal is the initial deliverable that describes what business requirements the new system should meet. Because it is really the first step in the design of the new system, some experts argue that it is inappropriate to use the term “analysis” as the name for this phase; some argue a better name would be “analysis and initial design.” Most organizations continue to use the name analysis for this phase, however, so we use it in this book as well. Just keep in mind that the deliverable from the analysis phase is both an analysis and a high-level initial design for the new system. Design The design phase decides how the system will operate, in terms of the hardware, software, and network infrastructure; the user interface, forms and reports; and the specific pro- grams, databases, and files that will be needed. Although most of the strategic decisions about the system were made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate. The design phase has four steps: 1. The design strategy is first developed. It clarifies whether the system will be devel- oped by the company’s own programmers, whether the system will be outsourced to another firm (usually a consulting firm), or whether the company will buy an existing software package. 2. This leads to the development of the basic architecture design for the system, which describes the hardware, software, and network infrastructure to be used. In most cases, the system will add or change the infrastructure that already exists in the organization. The interface design specifies how the users will move through the system (e.g., navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use. 3. The database and file specifications are developed. These define exactly what data will be stored and where they will be stored. 4. The analyst team develops the program design, which defines the programs that need to be written and exactly what each program will do. This collection of deliverables (architecture design, interface design, database and file spec- ifications, and program design) is the system specification that is handed to the programming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue. 6 Chapter 1 Introduction to Systems Analysis and Design Implementation The final phase in the SDLC is the implementation phase, during which the system is actu- ally built (or purchased, in the case of a packaged software design). This is the phase that usually gets the most attention, because for most systems it is the longest and most expen- sive single part of the development process. This phase has three steps: 1. System construction is the first step. The system is built and tested to ensure it per- forms as designed. Because the cost of bugs can be immense, testing is one of the most critical steps in implementation. Most organizations give more time and attention to testing than to writing the programs in the first place. 2. The system is installed. Installation is the process by which the old system is turned off and the new one is turned on. It may include a direct cutover approach (in which the new system immediately replaces the old system), a parallel conversion approach (in which both the old and new systems are operated for a month or two until it is clear that there are no bugs in the new system), or a phased conversion strategy (in which the new system is installed in one part of the organization as an initial trial and then gradually installed in others). One of the most important aspects of conversion is the development of a training plan to teach users how to use the new system and help manage the changes caused by the new system. 3. The analyst team establishes a support plan for the system. This plan usually includes a formal or informal post-implementation review as well as a systematic way for identifying major and minor changes needed for the system. CONCEPTS 1–B Keeping Up with Consumer Electronics IN ACTION Consumer electronics is a very competitive business. Questions What might be the success story of the year one year is a forgotten item two years later. Rapid product commoditi- 1. What external data analysis should a consumer zation makes the consumer electronics marketplace very electronics company use to determine marketplace competitive. Getting the right products to market at the needs and its abilities to compete effectively in a right time with the right components is an ongoing chal- marketplace? lenge for telecommunications and consumer electronics 2. Staying one step ahead of competitors requires a goods companies. corporate strategy and the support of information systems. How can information systems and systems analysts contribute to an aggressive corporate strategy? SYSTEMS DEVELOPMENT METHODOLOGIES A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and deliverables). There are many different systems development methodologies, and each one is unique, based on the order and focus it places on each SDLC phase. Some method- ologies are formal standards used by government agencies, whereas others have been developed by consulting firms to sell to clients. Many organizations have internal method- ologies that have been honed over the years, and they explain exactly how each phase of the SDLC is to be performed in that company. There are many ways to categorize methodologies. One way is by looking at whether they focus on business processes or the data that support the business. A process-centered  Systems Development Methodologies 7 aParent aRefrigerator aCupboard aSandwich aLunch aLunchBag GetJelly GetPeanutButter GetBread CreateSandwich GetMilk GetCookies CreateLunch GetLunchBag PutLunchInBag FIGURE 1-1 A Simple Behavioral Model for Making a Simple Lunch methodology emphasizes process models as the core of the system concept. In Figure 1-1, for example, process-centered methodologies would focus first on defining the processes (e.g., assemble sandwich ingredients). Data-centered methodologies emphasize data mod- els as the core of the system concept. In Figure 1-1, data-centered methodologies would focus first on defining the contents of the storage areas (e.g., refrigerator) and how the con- tents were organized.2 By contrast, object-oriented methodologies attempt to balance the focus between process and data by incorporating both into one model. In Figure 1-1, these 2 The classic modern process-centered methodology is that by Edward Yourdon, Modern Structured Analysis (Englewood Cliffs, NJ: Yourdon Press, 1989). An example of a data-centered methodology is information engi- neering; see James Martin, Information Engineering, vols. 1–3 (Englewood Cliffs, NJ: Prentice Hall, 1989). A widely accepted standardized non–object-oriented methodology that balances processes and data is IDEF; see FIPS 183, Integration Definition for Function Modeling, Federal Information Processing Standards Publications, U.S. Department of Commerce, 1993. 8 Chapter 1 Introduction to Systems Analysis and Design methodologies would focus first on defining the major elements of the system (e.g., sand- wiches, lunches) and look at the processes and data involved with each element. Another important factor in categorizing methodologies is the sequencing of the SDLC phases and the amount of time and effort devoted to each.3 In the early days of com- puting, programmers did not understand the need for formal and well-planned life-cycle methodologies. They tended to move directly from a very simple planning phase right into the construction step of the implementation phase—in other words, from a very fuzzy, not-well-thought-out system request into writing code. This is the same approach that you sometimes use when writing programs for a programming class. It can work for small pro- grams that require only one programmer, but if the requirements are complex or unclear, you might miss important aspects of the problem and have to start all over again, throw- ing away part of the program (and the time and effort spent writing it). This approach also makes teamwork difficult because members have little idea about what needs to be accom- plished and how to work together to produce a final product. In this section, we describe three different classes of system development methodologies: structured design, rapid application development, and agile development. Structured Design The first category of systems development methodologies is called structured design. These methodologies became dominant in the 1980s, replacing the previous ad hoc and undisci- plined approach. Structured design methodologies adopt a formal step-by-step approach to the SDLC that moves logically from one phase to the next. Numerous process-centered and data-centered methodologies follow the basic approach of the two structured design categories outlined next. Waterfall Development The original structured design methodology (still used today) is waterfall development. With waterfall development–based methodologies, the analysts and users proceed in sequence from one phase to the next (see Figure 1-2). The key deliv- erables for each phase are typically very long (often hundreds of pages in length) and are presented to the project sponsor for approval as the project moves from phase to phase. Once the sponsor approves the work that was conducted for a phase, the phase ends and the next one begins. This methodology is referred to as waterfall development because it moves forward from phase to phase in the same manner as a waterfall. Although it is pos- sible to go backward in the SDLC (e.g., from design back to analysis), it is extremely diffi- cult (imagine yourself as a salmon trying to swim upstream against a waterfall, as shown in Figure 1-2). Structured design also introduced the use of formal modeling or diagramming tech- niques to describe the basic business processes and the data that support them. Traditional structured design uses one set of diagrams to represent the processes and a separate set of diagrams to represent data. Because two sets of diagrams are used, the systems analyst must decide which set to develop first and use as the core of the system: process-model diagrams or data-model diagrams. There is much debate over which should come first, the processes or the data, because both are important to the system. As a result, several different struc- tured design methodologies have evolved that follow the basic steps of the waterfall model but use different modeling approaches at different times. Those that attempt to emphasize process-model diagrams as the core of the system are process centered, whereas those that emphasize data-model diagrams as the core of the system concept are data centered. 3 A good reference for comparing systems development methodologies is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996).  Systems Development Methodologies 9 FIGURE 1-2 Planning A Waterfall Development–based Methodology Analysis Design Implementation System The two key advantages of the structured design waterfall approach are that it identifies system requirements long before programming begins and it minimizes changes to the requirements as the project proceeds. The two key disadvantages are that the design must be completely specified before programming begins and that a long time elapses between the completion of the system proposal in the analysis phase and the delivery of the system (usually many months or years). Lengthy deliverables often result in poor communication; the result is that important requirements can be overlooked in the voluminous documenta- tion. Users are rarely prepared for their introduction to the new system, which occurs long after the initial idea for the system was introduced. If the project team misses important requirements, expensive post-implementation programming may be needed (imagine your- self trying to design a car on paper; how likely would you be to remember interior lights that come on when the doors open or to specify the right number of valves on the engine?). A system can also require significant rework because the business environment has changed from the time that the analysis phase occurred. When changes do occur, it means going back to the initial phases and following the change through each of the subsequent phases in turn. Parallel Development Parallel development methodology attempts to address the prob- lem of long delays between the analysis phase and the delivery of the system. Instead of doing design and implementation in sequence, it performs a general design for the whole system and then divides the project into a series of distinct subprojects that can be designed and implemented in parallel. Once all subprojects are complete, the separate pieces are integrated and the system is delivered (see Figure 1-3). The primary advantage of this methodology is that it can reduce the time to deliver a system; thus, there is less chance of changes in the business environment causing rework. However, the approach still suffers from problems caused by paper documents. It also adds a new problem: Sometimes the subprojects are not completely independent; design decisions made in one subproject can affect another, and the end of the project can require significant integration efforts. 10 C h a p t e r 1 Introduction to Systems Analysis and Design Planning Analysis Design Design Implementation Subproject 1 Design Subproject 2 Implementation Design Integration Implementation Subproject 3 System FIGURE 1-3 A Parallel Development-based Methodology Rapid Application Development (RAD) A second category of methodologies includes rapid application development (RAD)-based methodologies. These are a newer class of systems development methodologies that emerged in the 1990s. RAD-based methodologies attempt to address both weaknesses of structured design methodologies by adjusting the SDLC phases to get some part of the system developed quickly and into the hands of the users. In this way, the users can better understand the system and suggest revisions that bring the system closer to what is needed.4 Most RAD-based methodologies recommend that analysts use special techniques and computer tools to speed up the analysis, design, and implementation phases, such as com- puter-aided software engineering (CASE) tools, joint application design (JAD) sessions, fourth-generation or visual programming languages that simplify and speed up program- ming (e.g., Visual Basic), and code generators that automatically produce programs from design specifications. The combination of the changed SDLC phases and the use of these tools and techniques improves the speed and quality of systems development. However, there is one possible subtle problem with RAD-based methodologies: managing user expec- tations. Owing to the use of the tools and techniques that can improve the speed and quality of systems development, user expectations of what is possible can change dramatically. As a 4 One of the best RAD books is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996).  Systems Development Methodologies 11 Planning Analysis Design Analysis Implementation Analysis Design System version 1 Implementation Analysis Design System version 2 Implementation System version 3 FIGURE 1-4 A Phased Development-based Methodology user better understands the information technology (IT), the systems requirements tend to expand. This was less of a problem when using methodologies that spent a lot of time thor- oughly documenting requirements. Process-centered, data-centered, and object-oriented methodologies that follow the basic approaches of the three RAD categories are described in the following sections. Phased Development A phased development-based methodology breaks an overall system into a series of versions that are developed sequentially. The analysis phase identifies the overall system concept, and the project team, users, and system sponsor then categorize the requirements into a series of versions. The most important and fundamental requirements are bundled into the first version of the system. The analysis phase then leads into design and implementation—but only with the set of requirements identified for version 1 (see Figure 1-4). Once version 1 is implemented, work begins on version 2. Additional analysis is per- formed based on the previously identified requirements and combined with new ideas and 12 Chapter 1 Introduction to Systems Analysis and Design issues that arose from the users’ experience with version 1. Version 2 then is designed and implemented, and work immediately begins on the next version. This process continues until the system is complete or is no longer in use. Phased development–based methodologies have the advantage of quickly getting a useful system into the hands of the users. Although the system does not perform all the functions the users need at first, it does begin to provide business value sooner than if the system were delivered after completion, as is the case with the waterfall and parallel methodologies. Likewise, because users begin to work with the system sooner, they are more likely to identify important additional requirements sooner than with structured design situations. The major drawback to phased development is that users begin to work with systems that are intentionally incomplete. It is critical to identify the most important and useful features and include them in the first version and to manage users’ expectations along the way. Prototyping A prototyping-based methodology performs the analysis, design, and imple- mentation phases concurrently, and all three phases are performed repeatedly in a cycle until the system is completed. With these methodologies, the basics of analysis and design are performed, and work immediately begins on a system prototype, a quick-and-dirty pro- gram that provides a minimal amount of features. The first prototype is usually the first part of the system that is used. This is shown to the users and the project sponsor, who provide comments. These comments are used to reanalyze, redesign, and re-implement a second prototype, which provides a few more features. This process continues in a cycle until the analysts, users, and sponsor agree that the prototype provides enough functionality to be installed and used in the organization. After the prototype (now called the “system”) is installed, refinement occurs until it is accepted as the new system (see Figure 1-5). The key advantage of a prototyping-based methodology is that it very quickly provides a system with which the users can interact, even if it is not ready for widespread organiza- tional use at first. Prototyping reassures the users that the project team is working on the system (there are no long delays in which the users see little progress), and prototyping helps to more quickly refine real requirements. Rather than attempting to understand a sys- tem specification on paper, the users can interact with the prototype to better understand what it can and cannot do. The major problem with prototyping is that its fast-paced system releases challenge attempts to conduct careful, methodical analysis. Often the prototype undergoes such significant changes that many initial design decisions become poor ones. This can cause FIGURE 1-5 Planning A Prototyping-based Methodology Analysis System Design prototype Implementation Implementation System  Systems Development Methodologies 13 problems in the development of complex systems because fundamental issues and prob- lems are not recognized until well into the development process. Imagine building a car and discovering late in the prototyping process that you have to take the whole engine out to change the oil (because no one thought about the need to change the oil until after it had been driven 10,000 miles). Throwaway Prototyping Throwaway prototyping-based methodologies are similar to prototyping-based methodologies in that they include the development of prototypes; however, throwaway prototypes are done at a different point in the SDLC. These prototypes are used for a very different purpose than those previously discussed, and they have a very different appearance (see Figure 1-6). The throwaway prototyping–based methodologies have a relatively thorough analysis phase that is used to gather information and to develop ideas for the system concept. How- ever, users might not completely understand many of the features they suggest, and there may be challenging technical issues to be solved. Each of these issues is examined by ana- lyzing, designing, and building a design prototype. A design prototype is not a working system; it is a product that represents a part of the system that needs additional refinement, and it contains only enough detail to enable users to understand the issues under consid- eration. For example, suppose users are not completely clear on how an order-entry system should work. The analyst team might build a series of HTML pages viewed using a Web browser to help the users visualize such a system. In this case, a series of mock-up screens appear to be a system, but they really do nothing. Or suppose that the project team needs to develop a sophisticated graphics program in Java. The team could write a portion of the program with pretend data to ensure that they could do a full-blown program successfully. A system developed using this type of methodology probably relies on several design prototypes during the analysis and design phases. Each of the prototypes is used to mini- mize the risk associated with the system by confirming that important issues are under- stood before the real system is built. Once the issues are resolved, the project moves into design and implementation. At this point, the design prototypes are thrown away, which is an important difference between these methodologies and prototyping methodologies, in which the prototypes evolve into the final system. Planning Analysis Design Analysis Design Design prototype Implementation Implementation System FIGURE 1-6 A Throwaway Prototyping–based Methodology 14 C h a p t e r 1 Introduction to Systems Analysis and Design Throwaway prototyping-based methodologies balance the benefits of well-thought- out analysis and design phases with the advantages of using prototypes to refine key issues before a system is built. It can take longer to deliver the final system as compared to proto- typing-based methodologies (because the prototypes do not become the final system), but this type of methodology usually produces more stable and reliable systems. Agile Development5 A third category of systems development methodologies is still emerging today: agile devel- opment. All agile development methodologies are based on the agile manifesto and a set of twelve principles. The emphasis of the manifesto is to focus the developers on the working conditions of the developers, the working software, the customers, and addressing chang- ing requirements instead of focusing on detailed systems development processes, tools, all- inclusive documentation, legal contracts, and detailed plans. These programming-centric methodologies have few rules and practices, all of which are fairly easy to follow. These methodologies are typically based only on the twelve principles of agile software. These principles include the following: Software is delivered early and continuously through the development process, satisfying the customer. Changing requirements are embraced regardless of when they occur in the devel- opment process. Working software is delivered frequently to the customer. Customers and developers work together to solve the business problem. Motivated individuals create solutions; provide them the tools and environment they need and trust them to deliver. Face-to-face communication within the development team is the most efficient and effective method of gathering requirements. The primary measure of progress is working, executing software. Both customers and developers should work at a pace that is sustainable. That is, the level of work could be maintained indefinitely without any worker burnout. Agility is heightened through attention to both technical excellence and good design. Simplicity, the avoidance of unnecessary work, is essential. Self-organizing teams develop the best architectures, requirements, and designs. Development teams regularly reflect on how to improve their development processes. Based on these principles, agile methodologies focus on streamlining the system-development process by eliminating much of the modeling and documentation overhead and the time spent on those tasks. Instead, projects emphasize simple, iterative application development.6 All agile development methodologies follow a simple cycle through the traditional phases of the systems development process (see Figure 1-7). Virtually all agile methodologies are used in conjunction with object-oriented technologies. However, agile methodologies do have critics. One of the major criticisms deals with today’s business environment, where much of the actual information systems development 5 Three good sources of information on agile development and object-oriented systems are S. W. Ambler, Agile Modeling: Effective Practices for Extreme Programming and The Unified Process (New York: Wiley, 2002); C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004); and R. C. Martin, Agile Software Development: Principles, Patterns, and Practices (Upper Saddle River, NJ: Prentice Hall, 2003). 6 See www.agilealliance.com.  Systems Development Methodologies 15 FIGURE 1-7 Typical Agile Development Planning Methodology Analysis System Design Implementation is offshored, outsourced, and/or subcontracted. Given agile development methodologies requiring co-location of the development team, this seems to be a very unrealistic assump- tion. A second major criticism is that if agile development is not carefully managed, and by definition it is not, the development process can devolve into a prototyping approach that essentially becomes a “programmers gone wild” environment where programmers attempt to hack together solutions. A third major criticism, based on the lack of actual documen- tation created during the development of the software, raises issues regarding the auditability of the systems being created. Without sufficient documentation, neither the system nor the systems-development process can be assured. A fourth major criticism is based on whether agile approaches can deliver large mission-critical systems. Even with these criticisms, given the potential for agile approaches to address the application backlog and to provide timely solutions to many business problems, agile approaches should be considered in some circumstances. Furthermore, many of the techniques encouraged by attending to the underlying purpose of the agile mani- festo and the set of twelve agile principles are very useful in object-oriented systems development. Two of the more popular examples of agile development methodologies are extreme programming (XP) and Scrum. We describe both of these methodologies in the next two sections. Extreme Programming7 Extreme programming (XP) is founded on four core values: communication, simplicity, feedback, and courage. These four values provide a foundation that XP developers use to create any system. First, the developers must provide rapid feed- back to the end users on a continuous basis. Second, XP requires developers to follow the KISS principle.8 Third, developers must make incremental changes to grow the system, and they must not only accept change, they must embrace change. Fourth, developers must have a quality-first mentality. XP also supports team members in developing their own skills. Three of the key principles that XP uses to create successful systems are continuous testing, simple coding performed by pairs of developers, and close interactions with end users to build systems very quickly. Testing and efficient coding practices are the core of XP. Code is tested each day and is placed into an integrative testing environment. If bugs exist, the code is backed out until 7 For more information, see K. Beck, eXtreme Programming Explained: Embrace Change (Reading, MA: Addison- Wesley, 2000), C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004), M. Lippert, S. Roock, and H. Wolf, eXtreme Programming in Action: Practical Experiences from Real World Projects (New York: Wiley, 2002), or www.extremeprogramming.com. 8 Keep it simple, stupid. 16 Chapter 1 Introduction to Systems Analysis and Design it is completely free of errors. XP relies heavily on refactoring, which is a disciplined way to restructure code to keep it simple. An XP project begins with user stories that describe what the system needs to do. Then, programmers code in small, simple modules and test to meet those needs. Users are required to be available to clear up questions and issues as they arise. Standards are very important to minimize confusion, so XP teams use a common set of names, descriptions, and coding practices. XP projects deliver results sooner than even the RAD approaches, and they rarely get bogged down in gathering requirements for the system. XP adherents claim many strengths associated with developing software using XP. Programmers work closely with all stakeholders, and communication among all stake- holders is improved. Continuous testing of the evolving system is encouraged. The system is developed in an evolutionary and incremental manner, which allows the requirements to evolve as the stakeholders understand the potential that the technology has in provid- ing a solution to their problem. Estimation is task driven and is performed by the pro- grammer who will implement the solution for the task under consideration. Because all programming is done in pairs, a shared responsibility for each software component devel- ops among the programmers. Finally, the quality of the final product increases during each iteration. For small projects with highly motivated, cohesive, stable, and experienced teams, XP should work just fine. However, if the project is not small or the teams aren’t jelled,9 the success of an XP development effort is doubtful. This tends to throw into doubt the whole idea of bringing outside contractors into an existing team environment using XP.10 The chance of outsiders jelling with insiders might simply be too optimistic. XP requires a great deal of discipline; otherwise projects will become unfocused and chaotic. XP it is recom- mended only for small groups of developers—no more than ten developers—and it is not advised for large mission-critical applications. Owing to the lack of analysis and design documentation, there is only code documentation associated with XP, so maintaining large systems built with XP may be impossible. And because mission-critical business informa- tion systems tend to exist for a long time, the utility of XP as a business information sys- tem development methodology is in doubt. Finally, the methodology needs a lot of on-site user input, something to which many business units cannot commit.11 However, some of the techniques associated with XP are useful in object-oriented systems development. For example, user stories, pair programming, and continuous testing are invaluable tools from which object-oriented systems development could benefit. Scrum12 Scrum is a term that is well known to rugby fans. In rugby, a scrum is used to restart a game (see Figure 1-8). In a nutshell, the creators of the Scrum method believe that no matter how much you plan, as soon as the software begins to be developed, chaos breaks 9 A jelled team is one that has low turnover, a strong sense of identity, a sense of eliteness, a feeling that they jointly own the product being developed, and enjoyment in working together. For more information regarding jelled teams, see T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams (New York: Dorset/House, 1987). 10 Considering the tendency for offshore outsourcing, this is a major obstacle for XP to overcome. For more infor- mation on offshore outsourcing, see P. Thibodeau, “ITAA Panel Debates Outsourcing Pros, Cons,” Computerworld Morning Update (September 25, 2003), and S. W. Ambler, “Chicken Little Was Right,” Software Development (October 2003). 11 Many of the observations on the utility of XP as a development approach were based on conversations with Brian Henderson-Sellers. 12 For more information see C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison- Wesley, 2004), K. Schwaber and M. Beedle, Agile Software Development with Scrum (Upper Saddle River, NJ: Prentice Hall, 2001), and R. Wysocki, Effective Project Management: Traditional, Agile, Extreme, 5th Ed. (Indianapolis, IN: Wiley Publishing, 2009).  Systems Development Methodologies 17 FIGURE 1-8 Rugby Scrum (Rugby Game) (Source: Alan Brooke/Image Source) out and the plans go out the window.13 The best you can do is to react to where the prover- bial rugby ball squirts out. You then sprint with the ball until the next scrum. In the case of the Scrum methodology, a sprint lasts thirty working days. At the end of the sprint, a system is delivered to the customer. Of all systems development approaches, on the surface, Scrum is the most chaotic. To control some of the innate chaos, Scrum development focuses on a few key practices. Teams are self-organized and self-directed. Unlike other approaches, Scrum teams do not have a designated team leader. Instead, teams organize themselves in a symbiotic manner and set their own goals for each sprint (iteration). Once a sprint has begun, Scrum teams do not consider any additional requirements. Any new requirements that are uncovered are placed on a backlog of requirements that still need to be addressed. At the beginning of every work- day, a Scrum meeting takes place. At the end of each sprint, the team demonstrates the soft- ware to the client. Based on the results of the sprint, a new plan is begun for the next sprint. Scrum meetings are one of the most interesting aspects of the Scrum development process. The team members attend the meetings, but anyone can attend. However, with very few exceptions, only team members may speak. One prominent exception is manage- ment providing feedback on the business relevance of the work being performed by the specific team. In this meeting, all team members stand in a circle and report on what they accomplished during the previous day, state what they plan to do today, and describe any- thing that blocked progress the previous day. To enable continuous progress, any block identified is dealt with within one hour. From a Scrum point of view, it is better to make a “bad” decision about a block at this point in development than to not make a decision. Because the meetings take place each day, a bad decision can easily be undone. Larman14 suggests that each team member should report any additional requirements that have been uncovered during the sprint and anything that the team member learned that could be use- ful for other team members to know. 13 Scrum developers are not the first to question the use of plans. One of President Eisenhower’s favorite maxims was, “In preparing for battle I have always found that plans are useless, but planning is indispensable.” M. Dobson, Streetwise Project Management: How to Manage People, Processes, and Time to Achieve the Results You Need (Avon, MA: F!W Publications, 2003) p. 43. 14 C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004). 18 Chapter 1 Introduction to Systems Analysis and Design Structured Agile Methodologies RAD Methodologies Methodologies Ability to Develop Throwaway Systems Waterfall Parallel Phased Prototyping Prototyping XP SCRUM With Unclear User Requirements Poor Poor Good Excellent Excellent Excellent Excellent With Unfamiliar Technology Poor Poor Good Poor Excellent Good Good That Are Complex Good Good Good Poor Excellent Good Good That Are Reliable Good Good Good Poor Excellent Excellent Excellent With a Short Time Schedule Poor Good Excellent Excellent Good Excellent Excellent With Schedule Visibility Poor Poor Excellent Excellent Good Excellent Excellent FIGURE 1-9 Criteria for Selecting a Methodology One of the major criticisms of Scrum, as with all agile methodologies, is that it is ques- tionable whether Scrum can scale up to develop very large, mission-critical systems. A typ- ical Scrum team size is no more than seven members. The only organizing principle put forth by Scrum followers to address this criticism is to organize a scrum of scrums. Each team meets every day, and after the team meeting takes place, a representative (not leader) of each team attends a scrum-of-scrums meeting. This continues until the progress of entire system has been determined. Depending on the number of teams involved, this approach to managing a large project is doubtful. However, as in XP and other agile devel- opment approaches, many of the ideas and techniques associated with Scrum development are useful in object-oriented systems development, such as the focus of a Scrum meeting, the evolutionary and incremental approach to identifying requirements, and the incre- mental and iterative approach to the development of the system. Selecting the Appropriate Development Methodology Because there are many methodologies, the first challenge faced by analysts is selecting which methodology to use. Choosing a methodology is not simple, because no one methodology is always best. (If it were, we’d simply use it everywhere!) Many organizations have standards and policies to guide the choice of methodology. You will find that organi- zations range from having one “approved” methodology to having several methodology options to having no formal policies at all. Figure 1-9 summarizes some important criteria for selecting a methodology. One important item not discussed in this figure is the degree of experience of the analyst team. Many of the RAD-based methodologies require the use of new tools and techniques that have a significant learning curve. Often these tools and techniques increase the complexity of the project and require extra time for learning. However, once they are adopted and the team becomes experienced, the tools and techniques can significantly increase the speed at which the methodology can deliver a final system. Clarity of User Requirements When the user requirements for a system are unclear, it is difficult to understand them by talking about them and explaining them with written reports. Users normally need to interact with technology to really understand what a new system can do and how to best apply it to their needs. RAD and agile methodologies are usually more appropriate when user requirements are unclear.  Systems Development Methodologies 19 Familiarity with Technology When the system will use new technology with which the analysts and programmers are not familiar (e.g., the first Web development project with Java), early application of the new technology in the methodology will improve the chance of success. If the system is designed without some familiarity with the base technology, risks increase because the tools might not be capable of doing what is needed. Throwaway prototyping–based methodologies are particularly appropriate if users lack familiarity with technology because they explicitly encourage the developers to develop design prototypes for areas with high risks. Phased development–based methodologies are good as well, because they create opportunities to investigate the technology in some depth before the design is complete. Also, owing to the programming-centric nature of agile methodologies, both XP and Scrum are appropriate. Although you might think prototyping-based methodologies are also appropriate, they are much less so because the early prototypes that are built usually only scratch the surface of the new technology. It is generally only after several prototypes and sev- eral months that the developers discover weaknesses or problems in the new technology. System Complexity Complex systems require careful and detailed analysis and design. Throwaway prototyping–based methodologies are particularly well suited to such detailed analysis and design, but prototyping-based methodologies are not. The traditional struc- tured design–based methodologies can handle complex systems, but without the ability to get the system or prototypes into the users’ hands early on, some key issues may be over- looked. Although phased development–based methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these tend to devote less attention to the analysis of the complete problem domain than they might using other methodologies. Finally, agile methodologies are a mixed bag when it comes to system complexity. If the system is going to be a large one, then, owing to the lack of formal project management techniques used, agile methodologies will perform poorly. However, if the system is small to medium size, then agile approaches will be excellent. We rate them good on these criteria. System Reliability System reliability is usually an important factor in system develop- ment; after all, who wants an unreliable system? However, reliability is just one factor among several. For some applications, reliability is truly critical (e.g., medical equipment, missile-control systems), whereas for other applications (e.g., games, Internet video) it is merely important. Because throwaway prototyping methodologies combine detailed analysis and design phases with the ability for the project team to test many different approaches through design prototypes before completing the design, they are appropriate when system reliability is a high priority. Prototyping methodologies are generally not a good choice when reliability is critical because it lacks the careful analysis and design phases that are essential for dependable systems. However, owing to the heavy focus on testing, evolution- ary and incremental identification of requirements, and iterative and incremental develop- ment, agile methods may be the best overall approach. Short Time Schedules Projects that have short time schedules are well suited for RAD- based and agile methodologies because these methodologies are designed to increase the speed of development. RAD-based and agile methodologies are excellent choices when timelines are short because they best enable the project team to adjust the functionality in the system based on a specific delivery date, and if the project schedule starts to slip, it can be readjusted by removing functionality from the version or prototype under development. Waterfall-based methodologies are the worst choice when time is at a premium because they do not allow easy schedule changes. 20 C h a p t e r 1 Introduction to Systems Analysis and Design Schedule Visibility One of the greatest challenges in systems development is determin- ing whether a project is on schedule. This is particularly true of the structured design methodologies because design and implementation occur at the end of the project. The RAD-based methodologies move many of the critical design decisions earlier in the project to help project managers recognize and address risk factors and keep expectations in check. However, given the daily progress meetings associated with Agile approaches, schedule visibility is always on the proverbial front burner. YO U R 1-1 S e l e c t i n g a M e t h o d o l o g y TURN Suppose you are an analyst for the Roanoke Software international network, but the offices in each country Consulting Company (RSCC), a large consulting firm may use somewhat different hardware and software. with offices around the world. The company wants to RSCC management wants the system up and running build a new knowledge management system that can within a year. identify and track the expertise of individual consultants anywhere in the world based on their education and the Question various consulting projects on which they have worked. Assume that this is a new idea that has never before 1. What type of methodology would you recommend been attempted in RSCC or elsewhere. RSCC has an that RSCC use? Why? TYPICAL SYSTEMS ANALYST ROLES AND SKILLS It is clear from the various phases and steps performed during the SDLC that the project team needs a variety of skills. Project members are change agents who identify ways to improve an organization, build an information system to support them, and train and motivate others to use the system. Leading a successful organizational change effort is one of the most difficult jobs that someone can do. Understanding what to change and how to change it—and convincing others of the need for change—requires a wide range of skills. These skills can be broken down into six major categories: technical, business, analytical, interpersonal, management, and ethical. Analysts must have the technical skills to understand the organization’s existing tech- nical environment, the technology that will make up the new system, and the way both can fit into an integrated technical solution. Business skills are required to understand how IT can be applied to business situations and to ensure that the IT delivers real business value. Analysts are continuous problem solvers at both the project and the organizational level, and they put their analytical skills to the test regularly. Analysts often need to communicate effectively one-on-one with users and business managers (who often have little experience with technology) and with programmers (who often have more technical expertise than the analyst). They must be able to give presentations to large and small groups and write reports. Not only do they need to have strong interper- sonal abilities, but they also need to manage people with whom they work and they need to manage the pressure and risks associated with unclear situations. Finally, analysts must deal fairly, honestly, and ethically with other project team mem- bers, managers, and system users. Analysts often deal with confidential information or information that, if shared with others, could cause harm (e.g., dissent among employees); it is important to maintain confidence and trust with all people.  Typical Systems Analyst Roles and Skills 21 Role Responsibilities Business analyst Analyzing the key business aspects of the system Identifying how the system will provide business value Designing the new business processes and policies Systems analyst Identifying how technology can improve business processes Designing the new business processes Designing the information system Ensuring that the system conforms to information systems standards Infrastructure analyst Ensuring the system conforms to infrastructure standards Identifying infrastructure changes needed to support the system Change management analyst Developing and executing a change management plan Developing and executing a user training plan Project manager Managing the team of analysts, programmers, technical writers, and other specialists Developing and monitoring the project plan Assigning resources FIGURE 1-10 Serving as the primary point of contact for the project Project Team Roles In addition to these six general skill sets, analysts require many specific skills associated with roles performed on a project. In the early days of systems development, most organi- zations expected one person, the analyst, to have all the specific skills needed to conduct a systems development project. Some small organizations still expect one person to perform many roles, but because organizations and technology have become more complex, most large organizations now build project teams containing several individuals with clearly defined responsibilities. Different organizations divide the roles differently, but Figure 1-10 presents one commonly used set of project team roles. Most IS teams include many other individuals, such as the programmers, who actually write the programs that make up the system, and technical writers, who prepare the help screens and other documentation (e.g., users manuals and systems manuals). Business Analyst A business analyst focuses on the business issues surrounding the system. These issues include identifying the business value that the system will create, developing ideas and suggestions for how the business processes can be improved, and designing the new processes and policies in conjunction with the systems analyst. This individual likely has business experience and some type of professional training (e.g., the business analyst for accounting systems is likely a CPA [in the United States] or a CA [in Canada]). He or she represents the interests of the project sponsor and the ultimate users of the system. A business analyst assists in the planning and design phases but is most active in the analysis phase. Systems Analyst A systems analyst focuses on the IS issues surrounding the system. This person develops ideas and suggestions for how information technology can improve business processes, designs the new business processes with help from the business analyst, designs the new information system, and ensures that all IS standards are maintained. A systems analyst 22 Chapter 1 Introduction to Systems Analysis and Design likely has significant training and experience in analysis and design, programming, and even areas of the business. He or she represents the interests of the IS department and works intensively through the project but perhaps less so during the implementation phase. Infrastructure Analyst An infrastructure analyst focuses on the technical issues surrounding how the system will interact with the organization’s technical infrastructure (e.g., hardware, software, net- works, and databases). An infrastructure analyst’s tasks include ensuring that the new information system conforms to organizational standards and identifying infrastructure changes needed to support the system. This individual probably has significant training and experience in networking, database administration, and various hardware and soft- ware products. He or she represents the interests of the organization and IS group that will ultimately have to operate and support the new system once it has been installed. An infrastructure analyst works throughout the project but perhaps less so during planning and analysis phases. Change Management Analyst A change management analyst focuses on the people and management issues surrounding the system installation. The roles of this person include ensuring that the adequate docu- mentation and support are available to users, providing user training on the new system, and developing strategies to overcome resistance to change. This individual should have significant training and experience in organizational behavior in general and change man- agement in particular. He or she represents the interests of the project sponsor and users for whom the system is being designed. A change management analyst works most actively during the implementation phase but begins laying the groundwork for change during the analysis and design phases. Project Manager A project manager is responsible for ensuring that the project is completed on time and within budget and that the system delivers all benefits intended by the project sponsor. The role of the project manager includes managing the team members, developing the project plan, assigning resources, and being the primary point of contact when people outside the team have questions about the project. This individual likely has significant experience in project management and has probably worked for many years as a systems analyst before- hand. He or she represents the interests of the IS department and the project sponsor. The project manager works intensely during all phases of the project. YOUR 1-2 Being an Analyst TURN Suppose you decide to become an analyst after you grad- Question uate. Decide what type of analyst you would prefer to be and what types of courses you should take before you Develop a short plan that describes how you will prepare graduate. Then decide the type of summer job or intern- for your career as an analyst. ship you should seek.  Basic Characteristics of Object-Oriented Systems 23 BASIC CHARACTERISTICS OF OBJECT-ORIENTED SYSTEMS Object-oriented systems focus on capturing the structure and behavior of information sys- tems in little modules that encompass both data and process. These little modules are known as objects. In this section, we describe the basic characteristics of object-oriented systems, which include classes, objects, methods, messages, encapsulation, information hiding, inheritance, polymorphism, and dynamic binding.15 Classes and Objects A class is the general template we use to define and create specific instances, or objects. Every object is associated with a class. For example, all the objects that capture information about patients could fall into a class called Patient, because there are attributes (e.g., name, address, birth date, phone, and insurance carrier) and methods (e.g., make appointment, calculate last visit, change status, and provide medical history) that all patients share (see Figure 1-11). An object is an instantiation of a class. In other words, an object is a person, place, or thing about which we want to capture information. If we were building an appointment system for a doctor’s office, classes might include Doctor, Patient, and Appointment. The specific patients, such as Jim Maloney, Mary Wilson, and Theresa Marks, are considered instances, or objects, of the patient class (see Figure 1-11). Each object has attributes that describe information about the object, such as a patient’s name, birth date, address, and phone number. Attributes are also used to repre- sent relationships between objects; for example, there could be a department attribute in an employee object with a value of a department object that captures in which department the employee object works. The state of an object is defined by the value of its attributes and its relationships with other objects at a particular point in time. For example, a patient might have a state of new or current or former. Each object also has behaviors. The behaviors specify what the object can do. For example, an appointment object can probably schedule a new appointment, delete an appointment, and locate the next available appointment. In object-oriented programming, behaviors are implemented as methods (see the next section). FIGURE 1-11 Patient Classes and Objects -name -address -birthdate -phone -insurance carrier +make appointment() +calculate last visit() +change status() +provides medical history() +create() Jim Maloney : Patient Mary Wilson : Patient Theresa Marks : Patient 15 In Chapter 8, we review the basic characteristics of object-oriented systems in more detail. 24 Chapter 1 Introduction to Systems Analysis and Design FIGURE 1-12 Patient Messages and -name Methods -address create -birthdate -phone -insurance carrier aPatient +make appointment() +calculate last visit() +change status() Receptionist +provides medical history() +create() One of the more confusing aspects of object-oriented systems development is the fact that in most object-oriented programming languages, both classes and instances of classes can have attributes and methods. Class attributes and methods tend to be used to model attributes (or methods) that deal with issues related to all instances of the class. For example, to create a new patient object, a message is sent to the Patient class to create a new instance of itself. However, in this book, we focus primarily on attributes and methods of objects and not of classes. Methods and Messages Methods implement an object’s behavior. A method is nothing more than an action that an object can perform. As such, a method is analogous to a function or procedure in a tradi- tional programming language such as C, COBOL, or Pascal. Messages are information sent to objects to trigger methods. A message is essentially a function or procedure call from one object to another object. For example, if a patient is new to the doctor’s office, the recep- tionist sends a create message to the application. The patient class receives the create mes- sage and executes its create() method (see Figure 1-12), which then creates a new object: a Patient (see Figure 1-12). Encapsulation and Information Hiding The ideas of encapsulation and information hiding are interrelated in object-oriented sys- tems. However, neither of the terms is new. Encapsulation is simply the combination of process and data into a single entity. Traditional approaches to information systems devel- opment tend to be either process centric (e.g., structured systems) or data centric (e.g., information engineering). Object-oriented approaches combine process and data into holistic entities (objects). Information hiding was first promoted in structured systems development. The principle of information hiding suggests that only the information required to use a soft-