Chapter 1: 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 information systems development projects. It describes the evolution of systems development method- ologies and discusses the roles and skills required for 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 Be familiar with the different roles played by and the skills of a systems analyst. Understand the fundamental systems development life cycle and its four phases. Understand the evolution of systems development methodologies. 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. Be familiar with the basic characteristics of object-oriented systems. INTRODUCTION The systems development life cycle (SDLC) is the process of understanding how an information 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 prob- ably 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 simi- lar study conducted in 1996 by the General Accounting Office found that 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. For example, IAG Consulting reports that 80 percent of the projects were over time, 72 percent were over budget, and 55 percent contained less than the full functionality; Panorama Consulting Solutions reports that 54 percent of the ERP projects were over time, 56 percent were over budget, and 48 percent delivered less than 50 percent of the initial benefits; and an IBM study reports that 59 percent of the projects missed one or more of on time, within budget, and quality constraints.1 Although we would 1 For more information on the problem, see Capers Jones, Patterns of Software System Failure and Success (London: International Thompson Computer Press, 1996); and Keith Ellis, Business Analysis Benchmark: The Impact of Business Requirements on the Success of Technology Projects (2008). Retrieved May 2014 from IAG Consulting, www.iag.biz; H. H. Jorgensen, L. Owen, and A. Neus, Making Change Work (2008). Retrieved May 2014 from IBM, www.ibm. com; Panorama Consulting Solutions, 2012 ERP Report (2012). Retrieved May 2014 from Panorama-Consulting.com. 1 2 Cha pt e r 1 Introduction to Systems Analysis and Design like to promote this book as a silver bullet 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 developing a system is the systems analyst, who analyzes the business situation, identifies opportunities for improvements, and designs an information system to implement them. Being a systems analyst is one of the most interesting, exciting, and chal- lenging jobs around. Systems analysts work with a variety of people and learn how they con- duct 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 system; 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 organization’s goals, current business processes, and other information systems to provide value. An investment in an information system is like any other investment. 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 that 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 the 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 out of this book, you will need to actively apply to your own systems development project the ideas and concepts in the examples. This book guides you through all the steps for delivering a success- ful information 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. TYPICAL SYSTEMS ANALYST ROLES AND SKILLS It is clear during systems development that the project team needs a variety of skills. Project members are change agents who identify ways to improve an organization, build an informa- tion system to support them, and train and motivate others to use the system. 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 techni- cal 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 levels, 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 analysts). 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. Typical Systems Analyst Roles and Skills 3 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 infor- mation that, if shared with others, could cause harm (e.g., dissent among employees); it is important to maintain confidence and trust with all people. 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 organiza- tions expected one person, the analyst, to have all the specific skills needed to conduct a sys- tems 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. 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., user 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. 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 during 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 likely has signifi- cant 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, networks, 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 software 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 documen- tation and support are available to users, providing user training on the new system, and 4 Cha pt e r 1 Introduction to Systems Analysis and Design developing strategies to overcome resistance to change. This individual should have signifi- cant training and experience in organizational behavior in general and change management 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 beforehand. He or she represents the interests of the IS department and the project sponsor. The project man- ager works intensely during all phases of the project. 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 or 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 systems development life cycle (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 ele- ments 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). 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 infor- mation, 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 fin- ish. In other projects, the project teams move through the steps consecutively, incrementally, 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. 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 understand 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 The Systems Development Life Cycle 5 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 elabo- rates 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 identi- fied: 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 and 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 system request and feasibility analysis are presented to an information sys- tems 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 cur- rent system(s), identifies opportunities for improvement, and develops a concept for the new system. 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 questionnaires). The analysis of this information—in conjunction with input from the project spon- sor and many other people—leads to the development of a concept for a new sys- tem. 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. 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 6 Cha pt e r 1 Introduction to Systems Analysis and Design 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 programs, 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 specifi- cations, 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. Implementation The final phase in the SDLC is the implementation phase, during which the system is actually 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 expensive 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 that it performs 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. 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. Systems Development Methodologies 7 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 methodolo- gies are formal standards used by government agencies, whereas others have been developed by consulting firms to sell to clients. Many organizations have internal methodologies 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 method- ology emphasizes process models as the core of the system concept. In Figure 1-1, for exam- ple, process-centered methodologies would focus first on defining the processes (e.g., assemble sandwich ingredients). Data-centered methodologies emphasize data models 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 contents were organ- ized.2 In contrast, object-oriented methodologies attempt to balance the focus between process and data by incorporating both into one model. In Figure 1-1, these methodologies would focus first on defining the major elements of the system (e.g., sandwiches, 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 computing, programmers did not understand the need for formal and well-planned life-cycle methodolo- gies. They tended to move directly from a very simple planning phase right into the construc- tion 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 programs 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, throwing 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 accomplished and how to work together to produce a final product. In this section, we describe a set of different classes of systems devel- opment methodologies: structured design, rapid application development, object-oriented systems analysis and design, agile development, DevOps, and custom methodologies. 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 catego- ries outlined next. 2 The classic modern process-centered methodology is that by Edward Yourdon, Modern Structured Analysis (Engle- wood Cliffs, NJ: Yourdon Press, 1989). An example of a data-centered methodology is information engineering; 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 Com- merce, 1993). 3 A good reference for comparing systems development methodologies is Steve McConnell, Rapid Development (Red- mond, WA: Microsoft Press, 1996). 8 Cha pt e r 1 Introduction to Systems Analysis and Design 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 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. The key deliverables for each phase are typically very long (often hundreds of pages in length) and are presented to the project spon- sor 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 methodol- ogy is referred to as waterfall development because it moves forward from phase to phase in the same manner as a waterfall. Although it is possible to go backward in the SDLC (e.g., from design back to analysis), it is extremely difficult (imagine yourself as a salmon trying to swim upstream against a waterfall). 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 Systems Development Methodologies 9 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. 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 (usu- ally many months or years). If the project team misses important requirements, expensive post-implementation programming may be needed (imagine yourself trying to design a car on paper; how likely would you be able 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 when the analysis phase occurred. Parallel Development Parallel development methodology attempts to address the problem 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. 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, 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 integra- tion efforts. 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 sys- tem 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 computer-aided software engineering (CASE) tools, joint application design (JAD) sessions, fourth-generation or visual programming languages that simplify and speed up programming, 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 expectations. Owing to the use of the tools and techniques that can improve the speed and quality of systems development, user expecta- tions of what is possible can change dramatically. As a 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 thoroughly documenting requirements. 4 One of the best RAD books is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996). 10 C ha pt e r 1 Introduction to Systems Analysis and Design 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 over- all 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. 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 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 of 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 program 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 com- ments. These comments are used to reanalyze, redesign, and reimplement 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. 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 organizational 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. The major problem with prototyping is that its fast-paced system releases challenge attempts to conduct careful, methodical analysis. Often the prototype undergoes such signifi- cant changes that many initial design decisions become poor ones. This can cause problems in the development of complex systems because fundamental issues and problems are not recog- nized 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; how- ever, 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. Systems Development Methodologies 11 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. However, 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 analyz- ing, 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 consideration. For example, suppose users are not completely clear on how an order-entry system should work. 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 relies on several design prototypes during the analysis and design phases. Each of these prototypes is used to minimize the risk associated with the system by confirming that important issues are understood before the real system is built. Once the issues are resolved, the project moves into design and implementa- tion. 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. 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 prototyping-based methodologies, but this type of methodology usually produces more stable and reliable systems. Object-Oriented Systems Analysis and Design (OOSAD) A third category of information systems development methodologies is object-oriented analysis and design. Object-oriented approaches to developing information systems, techni- cally speaking, can use any of the traditional methodologies. However, the object-oriented approaches are most associated with a phased development RAD. The primary difference between a traditional approach like structured design and an object-oriented approach is how a problem is decomposed. In traditional approaches, the problem-decomposition process is either process-centric or data-centric. However, processes and data are so closely related that it is difficult to pick one or the other as the primary focus. Based on this lack of congruence with the real world, new object-oriented methodologies have emerged that use the RAD-based sequence of SDLC phases but attempt to balance the emphasis between process and data by focusing the analysis of problems on objects that contain both data and processes. According to the creators of the Unified Modeling Language (UML), Grady Booch, Ivar Jacobson, and James Rumbaugh,5 any modern object-oriented approach to developing infor- mation systems must be use-case driven, architecture-centric, and iterative and incremental. Use-Case Driven Use-case driven means that use cases are the primary modeling tools defin- ing the behavior of the system. A use case describes how the user interacts with the system to perform some activity, such as placing an order, making a reservation, or searching for infor- mation. The use cases are used to identify and to communicate the requirements of the system to the programmers who must write the system. Use cases are inherently simple because they focus on only one business process at a time. In contrast, the process model diagrams used by 5Grady Booch, Ivar Jacobson, and James Rumbaugh, The Unified Modeling Language User Guide (Reading, MA: Addison-Wesley, 1999). 12 C ha pt e r 1 Introduction to Systems Analysis and Design traditional structured and RAD methodologies are far more complex because they require the systems analyst and user to develop models of the entire system. With traditional methodolo- gies, each system is decomposed into a set of subsystems, which are, in turn, decomposed into further subsystems, and so on. This goes on until no further process decomposition makes sense, and it often requires dozens of pages of interlocking diagrams. In contrast, a use case focuses on only one business process at a time, so developing models is much simpler.6 Architecture-Centric Any modern approach to systems analysis and design should be architecture-centric. Architecture-centric means that the underlying software architecture of the evolving system specification drives the specification, construction, and documentation of the system. Modern object-oriented systems analysis and design approaches should support at least three separate but interrelated architectural views of a system: functional, static, and dynamic. The functional, or external, view describes the behavior of the system from the per- spective of the user. The structural, or static, view describes the system in terms of attributes, methods, classes, and relationships. The behavioral, or dynamic, view describes the behavior of the system in terms of messages passed among objects and state changes within an object. Iterative and Incremental Modern object-oriented systems analysis and design approaches emphasize iterative and incremental development that undergoes continuous testing and refinement throughout the life of the project. This implies that the systems analysts develop their understanding of a user’s problem by building up the three architectural views little by little. The systems analyst does this by working with the user to create a functional representa- tion of the system under study. Next, the analyst attempts to build a structural representation of the evolving system. Using the structural representation of the system, the analyst distrib- utes the functionality of the system over the evolving structure to create a behavioral repre- sentation of the evolving system. As an analyst works with the user in developing the three architectural views of the evolving system, the analyst iterates over each of and among the views. That is, as the analyst better understands the structural and behavioral views, the ana- lyst uncovers missing requirements or misrepresentations in the functional view. This, in turn, can cause changes to be cascaded back through the structural and behavioral views. All three architectural views of the system are interlinked and dependent on each other (see Figure 1-2). As each increment and iteration is completed, a more-complete representation of the user’s real functional requirements is uncovered. Object-Oriented Functional view FIGURE 1-2 Itera- Structural Behavioral tive and Incremental view view Development 6 For those of you who have experience with traditional structured analysis and design, this is one of the most unusual aspects of object-oriented analysis and design using UML. Unlike structured approaches, object-oriented approaches stress focusing on just one use case at a time and distributing that single use case over a set of communicating and collaborating objects. Systems Development Methodologies 13 Benefits of Object-Oriented Systems Analysis and Design Concepts in the object-oriented approach enable analysts to break a complex system into smaller, more-manageable modules, work on the modules individually, and easily piece the modules back together to form an information system. This modularity makes systems development easier to grasp, easier to share among members of a project team, and easier to communicate to users, who are needed to provide requirements and confirm how well the system meets the requirements through- out the systems development process. By modularizing systems development, the project team actually is creating reusable pieces that can be plugged into other systems efforts or used as starting points for other projects. Ultimately, this can save time because new projects don’t have to start completely from scratch. Agile Development7 A fourth category of systems development methodologies is agile development. All agile devel- opment 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 devel- opers, the working software, the customers, and addressing changing 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, satis- fying the customer. Changing requirements are embraced regardless of when they occur in the develop- ment 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 systems 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.8 All agile development methodologies follow a simple cycle through the traditional phases of 7 Three good sources of information on agile development and object-oriented systems are S. W. Ambler, Agile odeling: Effective Practices for Extreme Programming and the Unified Process (New York: Wiley, 2002); C. Larman, M Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004); R. C. Martin, Agile Software Development: Principles, Patterns, and Practices (Upper Saddle River, NJ: Prentice Hall, 2003). 8 See Agile Alliance, www.agilealliance.com. 14 C ha pt e r 1 Introduction to Systems Analysis and Design the systems development process. 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 is offshored, outsourced, and/or subcontracted. Given agile development methodologies requir- ing co-location of the development team, this seems to be a very unrealistic assumption. 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 documentation 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 applica- tion backlog and to provide timely solutions to many business problems, agile approaches should be considered in some circumstances. Furthermore, many of the techniques encour- aged by attending to the underlying purpose of the agile manifesto 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. Extreme Programming9 Extreme programming (XP) is founded on four core values: com- munication, simplicity, feedback, and courage. These four values provide a foundation that XP developers use to create any system. First, the developers must provide rapid feedback to the end users on a continuous basis. Second, XP requires developers to follow the KISS prin- ciple.10 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 it is completely free of errors. 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 prac- tices. 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 stakeholders is improved. Continuous testing of the evolving system is encouraged. The system is devel- oped in an evolutionary and incremental manner, which allows the requirements to evolve as the stakeholders understand the potential that the technology has in providing a solution to 9 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); www.extremeprogramming.org. 10 Keep it simple, stupid. Systems Development Methodologies 15 their problem. Estimation is task driven and is performed by the programmer who will imple- ment the solution for the task under consideration. Because all programming is done in pairs, a shared responsibility for each software component develops 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,11 the suc- cess 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.12 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 is recommended 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 information systems tend to exist for a long time, the utility of XP as a business information systems development methodology is in doubt. Finally, the methodology needs a lot of on-site user input, something to which many business units cannot commit.13 However, some of the techniques associated with XP are useful in object-oriented systems development. For example, user stories, pair program- ming, and continuous testing are invaluable tools from which object-oriented systems devel- opment could benefit. Scrum14 Scrum is a term that is well known to rugby fans. In rugby, a scrum is used to restart a game. 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 out and the plans go out the window.15 The best you can do is to react to where the proverbial 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. 11 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). 12 Considering the tendency for offshore outsourcing, this is a major obstacle for XP to overcome. For more informa- tion on offshore outsourcing, see P. Thibodeau, “ITAA Panel Debates Outsourcing Pros, Cons,” Computerworld Morning Update (September 25, 2003); S. W. Ambler, “Chicken Little Was Right,” Software Development (October 2003). 13 Many of the observations on the utility of XP as a development approach were based on conversations with Brian Henderson-Sellers. 14 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); R. Wysocki, Effective Project Management: Traditional, Agile, Extreme, 5th Ed. (Indianapolis, IN: Wiley Pub- lishing, 2009). 15 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, Street- wise Project Management: How to Manage People, Processes, and Time to Achieve the Results You Need (Avon, MA: F+W Publications, 2003), p. 43. 16 C ha pt e r 1 Introduction to Systems Analysis and Design Scrum meetings are one of the most interesting aspects of the Scrum development pro- cess. The team members attend the meetings, but anyone can attend. However, with very few exceptions, only team members may speak. One prominent exception is management pro- viding feedback on the business relevance of the work being performed by a 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 anything 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. Larman16 suggests that each team mem- ber should report any additional requirements that have been uncovered during the sprint and anything that the team member learned that could be useful for other team mem- bers to know. 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 typical 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 development 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 incremental and iterative approach to the development of the system. DevOps Another category of systems development methodologies is DevOps.17 DevOps approaches incorporate ideas from both object-oriented approaches to systems development and lean manufacturing into the agile approaches. Two of the more popular approaches are DAD18 and SAFe.19 The primary extensions that DevOps approaches support are the inclusion of operations personnel with the development team and continuous deployment. In earlier approaches, end users were identified as very important stakeholders who should be included in the development team. However, new technology developers realized that including end users, even though necessary, was not sufficient to deliver high quality systems. For example, with cloud technologies concerns related to deployment of the system should be addressed before the development team “throws the system over the wall” to the operations personnel. Consequently, DevOps approaches include operations personnel as members of the development team. In this way, nonfunctional requirements, such as security, can be addressed during the design of the system to be deployed. 16 C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004). 17 For more information, see Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations (Portland, OR: IT Revolution Press, 2016); Nicole Forsgren, Jex Humble, and Gene Kim, The Science Behind DevOps, Accelerate: Building and Scaling High Performing Technology Organizations (Portland, OR: IT Revolution Press, 2018). 18 For more information, see Scott W. Ambler and Mark Lines, Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise (Upper Saddle River, NJ: IBM Press, 2012). 19 For more information, see Richard Knaster and Dean Leffingwell, SAFe® Distilled: Applying the Scaled Agile Frame- work® for Lean Software and Systems Engineering (Boston, MA: Addison-Wesley, 2017); Dean Leffingwell with Alex Yakyma, Richard Knaster, Drew Jemilo, and Inbar Oren, SAFe® Reference Guide: Scaled Agile Framework® for Lean Software and Systems Engineering (Boston, MA: Addison-Wesley, 2017). The Unified Process 17 With both object-oriented and agile approaches, deployment was only performed after a version of the system was completed. In other words, the operations personnel took over the system and deployed it. With DevOps approaches, deployment is completed when a new chunk of software has passed a set of relevant tests. Consequently, deployment of a new ver- sion of the system is not performed all at once. Instead, the new version is deployed in pieces over time; this is also referred to as a rolling upgrade. This approach requires quite a bit of automation of the actual deployment pipeline.20 Custom Methodologies This last category of systems development methodologies supports the idea of applying both agile and object-oriented ideas to the systems development methodology itself. The idea behind these approaches is to support the development team in a way that is customized to their specific systems development project. In this case, only a high-level framework is used to create the project-specific method. Two of the approaches that have made progress in this area are based on the work of Brian Henderson-Sellers21 and of Ivar Jacobson.22 Both of these groups allow the team to pick and choose different components of a methodology from a component repository to create a custom methodology. Care must be taken to ensure that each component is plug compatible. By that we mean the inputs into a component are com- patible with the outputs of the preceding component in the methodology. THE UNIFIED PROCESS The Unified Process is a specific methodology that maps out when and how to use the various Unified Modeling Language (UML) techniques for object-oriented analysis and design. The primary contributors were Grady Booch, Ivar Jacobson, and James Rumbaugh. Whereas the UML provides structural support for developing the structure and behavior of an information system, the Unified Process provides the behavioral support. The Unified Process, of course, is use-case driven, architecture-centric, and iterative and incremental. Furthermore, the Unified Process is a two-dimensional systems development process described by a set of phases and workflows. The phases are inception, elaboration, construction, and transition. The workflows include business modeling, requirements, analysis, design, implementation, test, deployment, configuration and change management, project management, and environ- ment.23 Figure 1-3 depicts the Unified Process. 20 A good overview of these approaches is described in Len Bass, Ingo Weber, and Liming Zhu, DevOps: A Software Architect’s Perspective (Upper Saddle River, NJ: Pearson Education, 2015). 21 For more information, see Ian Graham, Brian Henderson-Sellers, and Houman Younessi, The OPEN Process Speci- fication (New York, NY: ACM Press, 1997); Brian Henderson-Sellers, Anthony Simons, and Houman Younessi, The OPEN Toolbox of Techniques (New York, NY: ACM Press, 1998); Donald G. Firesmith and Brian Henderson-Sellers, The OPEN Process Framework (London, Addison-Wesley, 2002); Brian Henderson-Seller, Jolita Ralyte’, Par J. Agerfalk, and Matti Rossi, Situational Method Engineering (Berlin: Springer, 2014). 22 For more information, see Ivar Jaconson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, and Svante Lidman, The ESSENCE of Software Engineering: Applying the SEMAT Kernel (Upper Saddle River, NJ: Addison-Wesley, 2013); Ivar Jacobson, Harold “Bud” Lawson, Pan-Wei Ng, Paul E. McMahon, and Michael Goedicke, The Essentials of Modern Software Engineering: Free the Practices from the Method Prisons! (ACM Books, 2019). 23 The material in this section is based on Khawar Zaman Ahmed and Cary E. Umrysh, Developing Enterprise Java Applications with J2EE and UML (Boston, MA: Addison-Wesley, 2002); Jim Arlow and Ila Neustadt, UML and the Unified Process: Practical Object-Oriented Analysis & Design (Boston, MA: Addison-Wesley, 2002); Peter Eeles, Kelli Houston, and Wojtek Kozacynski, Building J2EE Applications with the Rational Unified Process (Boston, MA: Addison-Wesley, 2003); Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Pro- cess (Reading, MA: Addison-Wesley, 1999); Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd Ed. (Boston, MA: Addison-Wesley, 2000); “Rational Unified Process: Best Practices for Software Development Teams,” Rational Software White Paper, TP026B, Rev 11/01. 18 C ha pt e r 1 Introduction to Systems Analysis and Design Phases The phases of the Unified Process support an analyst in developing information systems in an iterative and incremental manner. The phases describe how an information system evolves through time. Depending on which development phase the evolving system is currently in, the level of activity varies over the workflows. The curve in Figure 1-3 associated with each workflow approximates the amount of activity that takes place during the specific phase. For example, the inception phase primarily involves the business modeling and requirements workflows, while practically ignoring the test and deployment workflows. Each phase con- tains a set of iterations, and each iteration uses the various workflows to create an incremental version of the evolving system. As the system evolves through the phases, it improves and becomes more complete. Each phase has objectives, a focus of activity over the workflows, and incremental deliverables. Each of the phases is described next. Inception In many ways, the inception phase is very similar to the planning phase of a tradi- tional SDLC approach. In this phase, a business case is made for the proposed system. This includes feasibility analysis that should answer questions such as the following: Do we have the technical capability to build it (technical feasibility)? If we build it, will it provide business value (economic feasibility)? If we build it, will it be used by the organization (organizational feasibility)? Engineering Workflows Phases Inception Elaboration Construction Transition Business Modeling Requirements Analysis Design Implementation Test Deployment Supporting Workflows Phases Inception Elaboration Construction Transition Configuration and Change Management Project Management Environment Iter … Iter Iter … Iter Iter … Iter Iter … Iter 1 i i+1 j j+1 k k+1 m FIGURE 1-3 The Unified Process The Unified Process 19 To answer these questions, the development team performs work related primarily to the business modeling, requirements, and analysis workflows. In some cases, depending on the technical difficulties that could be encountered during the development of the system, a throwaway prototype is developed. This implies that the design, implementation, and test workflows could also be involved. The project management and environment supporting workflows are very relevant to this phase. The primary deliverables from the inception phase are a vision document that sets the scope of the project; identifies the primary requirements and constraints; sets up an initial project plan; and describes the feasibility of and risks associ- ated with the project, the adoption of the necessary environment to develop the system, and some aspects of the problem domain classes being implemented and tested. Elaboration When we typically think about object-oriented systems analysis and design, the activities related to the elaboration phase of the Unified Process are the most relevant. The analysis and design workflows are the primary focus during this phase. The elaboration phase continues with developing the vision document, including finalizing the business case, revis- ing the risk assessment, and completing a project plan in sufficient detail to allow the stake- holders to be able to agree with constructing the actual final system. It deals with gathering the requirements, building the UML structural and behavioral models of the problem domain, and detailing how the problem domain models fit into the evolving system architec- ture. Developers are involved with all but the deployment engineering workflow in this phase. As the developers iterate over the workflows, the importance of addressing configuration and change management becomes apparent. Also, the development tools acquired during the inception phase become critical to the success of the project during this phase.24 The primary deliverables of this phase include the UML structure and behavior diagrams and an executa- ble of a baseline version of the evolving information system. The baseline version serves as the foundation for all later iterations. By providing a solid foundation at this point, the developers have a basis for completing the system in the construction and transition phases. Construction The construction phase focuses heavily on programming the evolving informa- tion system. This phase is primarily concerned with the implementation workflow. However, the requirements workflow and the analysis and design workflows also are involved with this phase. It is during this phase that missing requirements are identified and the analysis and design models are finally completed. Typically, there are iterations of the workflows during this phase, and during the last iteration, the deployment workflow kicks into high gear. The configuration and change management workflow, with its version-control activities, becomes extremely important during the construction phase. At times, an iteration has to be rolled back. Without good version controls, rolling back to a previous version (incremental imple- mentation) of the system is nearly impossible. The primary deliverable of this phase is an implementation of the system that can be released for beta and acceptance testing. Transition Like the construction phase, the transition phase addresses aspects typically asso- ciated with the implementation phase of a traditional SDLC approach. Its primary focus is on the testing and deployment workflows. Essentially, the business modeling, requirements, and analysis workflows should have been completed in earlier iterations of the evolving informa- tion system. Furthermore, the testing workflow should have been executed during the earlier phases of the evolving system. Depending on the results from the testing workflow, some redesign and programming activities on the design and implementation workflows could be 24With UML comprising fifteen different, related diagramming techniques, keeping the diagrams coordinated and the different versions of the evolving system synchronized is typically beyond the capabilities of a mere mortal systems developer. These tools typically include project management and CASE tools. We describe the use of these tools in Chapter 2. 20 C ha pt e r 1 Introduction to Systems Analysis and Design necessary, but they should be minimal at this point. From a managerial perspective, the pro- ject management, configuration and change management, and environment are involved. Some of the activities that take place are beta and acceptance testing, fine-tuning the design and implementation, user training, and rolling out the final product onto a production plat- form. Obviously, the primary deliverable is the actual executable information system. The other deliverables include user manuals, a plan to support the users, and a plan for upgrading the information system in the future. Workflows The workflows describe the tasks or activities that a developer performs to evolve an informa- tion system over time. The workflows of the Unified Process are grouped into two broad categories: engineering and supporting. Engineering Workflows Engineering workflows include business-modeling, requirements, analysis, design, implementation, test, and deployment workflows. The engineering work- flows deal with the activities that produce the technical product (i.e., the information system). Business Modeling Workflow The business modeling workflow uncovers problems and iden- tifies potential projects within a user organization. This workflow aids management in under- standing the scope of the projects that can improve the efficiency and effectiveness of a user organization. The primary purpose of business modeling is to ensure that both developer and user organizations understand where and how the to-be-developed information system fits into the business processes of the user organization. This workflow is primarily executed dur- ing the inception phase to ensure that we develop information systems that make business sense. The activities that take place on this workflow are most closely associated with the planning phase of the traditional SDLC; however, requirements gathering, and use-case and business process modeling techniques also help us to understand the business situation. Requirements Workflow In the Unified Process, the requirements workflow includes eliciting both functional and nonfunctional requirements. Typically, requirements are gathered from project stakeholders, such as end users, managers within the end user organization, and even customers. The requirements workflow is used the most during the inception and elaboration phases. The identified requirements are very helpful for developing the vision document and the use cases used throughout the development process. Additional requirements tend to be discovered throughout the development process. In fact, only the transition phase tends to have few, if any, additional requirements identified. Analysis Workflow The analysis workflow primarily addresses the creation of an analysis model of the problem domain. In the Unified Process, the analyst begins designing the archi- tecture associated with the problem domain; using the UML, the analyst creates structural and behavior diagrams that depict a description of the problem domain classes and their interactions. The primary purpose of the analysis workflow is to ensure that both the devel- oper and user organizations understand the underlying problem and its domain without overanalyzing. If they are not careful, analysts can create analysis paralysis, which occurs when the project becomes so bogged down with analysis that the system is never actually designed or implemented. A second purpose of the analysis workflow is to identify useful reusable classes for class libraries. By reusing predefined classes, the analyst can avoid rein- venting the wheel when creating the structural and behavior diagrams. The analysis workflow is predominantly associated with the elaboration phase, but like the requirements workflow, it is possible that additional analysis will be required throughout the development process. The Unified Process 21 Design Workflow The design workflow transitions the analysis model into a form that can be used to implement the system: the design model. Whereas the analysis workflow concentrates on understanding the problem domain, the design workflow focuses on developing a solution that will execute in a specific environment. Basically, the design workflow simply enhances the description of the evolving system by adding classes that address the environment of the system to the evolving analysis model. The design workflow uses activities such as detailed problem domain class design, optimization of the evolving information system, database design, user-interface design, and physical architecture design. The design workflow is associ- ated primarily with the elaboration and construction phases of the Unified Process. Implementation Workflow The primary purpose of the implementation workflow is to cre- ate an executable solution based on the design model (i.e., programming). This includes not only writing new classes but also incorporating reusable classes from executable class libraries into the evolving solution. As with any programming activity, the new classes and their inter- actions with the incorporated reusable classes must be tested. Finally, in the case of multiple groups performing the implementation of the information system, the implementers also must integrate the separate, individually tested modules to create an executable version of the system. The implementation workflow is associated primarily with the elaboration and con- struction phases. Testing Workflow The primary purpose of the testing workflow is to increase the quality of the evolving system. Testing goes beyond the simple unit testing associated with the imple- mentation workflow. In this case, testing also includes testing the integration of all modules used to implement the system, user acceptance testing, and the actual alpha testing of the software. Practically speaking, testing should go on throughout the development of the sys- tem; testing of the analysis and design models occurs during the elaboration and construction phases, whereas implementation testing is performed primarily during the construction and, to some degree, transition phases. Basically, at the end of each iteration during the develop- ment of the information system, some type of testing should be performed. Deployment Workflow The deployment workflow is most associated with the transition phase of the Unified Process. The deployment workflow includes activities such as software packaging, distribution, installation, and beta testing. When actually deploying the new sys- tem into a user organization, the developers might have to convert the current data, interface the new software with the existing software, and train the end user to use the new system. Supporting Workflows The supporting workflows include the project management, con- figuration and change management, and environment workflows. The supporting workflows focus on the managerial aspects of information systems development. Project Management Workflow Whereas the other workflows associated with the Unified Process are technically active during all four phases, the project management workflow is the only truly cross-phase workflow. The development process supports incremental and iterative development, so information systems tend to grow or evolve over time. At the end of each iteration, a new incremental version of the system is ready for delivery. The project manage- ment workflow is quite important owing to the complexity of the two-dimensional develop- ment model of the Unified Process (workflows and phases). This workflow’s activities include identifying and managing risks, managing scope, estimating the time to complete each itera- tion and the entire project, estimating the cost of the individual iteration and the whole pro- ject, and tracking the progress being made toward the final version of the evolving information system. 22 C ha pt e r 1 Introduction to Systems Analysis and Design Configuration and Change Management Workflow The primary purpose of the configura- tion and change management workflow is to keep track of the state of the evolving system. In a nutshell, the evolving information system comprises a set of artifacts (e.g., diagrams, source code, and executables). During the development process, these artifacts are modified. A sub- stantial amount of work—and, hence, money—is involved in developing the artifacts. The artifacts themselves should be handled as any expensive asset would be handled—access controls must be put into place to safeguard the artifacts from being stolen or destroyed. Furthermore, because the artifacts are modified on a regular, if not continuous, basis, good version control mechanisms should be established. Finally, a good deal of project manage- ment information needs to be captured (e.g., author, time, and location of each modification). The configuration and change management workflow is associated mostly with the construc- tion and transition phases. Environment Workflow During the development of an information system, the develop- ment team needs to use different tools and processes. The environment workflow addresses these needs. For example, a CASE tool that supports the development of an object-oriented information system via the UML could be required. Other tools necessary include program- ming environments, project management tools, and configuration management tools. The environment workflow involves acquiring and installing these tools. Even though this work- flow can be active during all of the phases of the Unified Process, it should be involved pri- marily with the inception phase. Extensions to the Unified Process As large and as complex as the Unified Process is, many authors have pointed out a set of critical weaknesses. First, the Unified Process does not address staffing, budgeting, or contract management issues. These activities were explicitly left out of the Unified Process. Second, the Unified Process does not address issues relating to maintenance, operations, or support of the product once it has been delivered. Thus, it is not a complete software process; it is only a development process. Third, the Unified Process does not address cross- or inter-project issues. Considering the importance of reuse in object-oriented systems development and the fact that in many organizations employees work on many different projects at the same time, leaving out inter-project issues is a major omission. To address these omissions, Ambler and Constantine suggest adding a production phase and two workflows: the operations and support workflow and the infrastructure management workflow (see Figure 1-4).25 In addition to these new workflows, the test, deployment, and environment workflows are modified, and the project management and the configuration and change management workflows are extended into the production phase. These extensions are based on alternative object-oriented software processes: the OPEN process (Object-oriented Process, Environment, and Notation) and the Object-Oriented Software Process.26 25 S. W. Ambler and L. L. Constantine, The Unified Process Inception Phase: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler and L. L. Constantine, The Unified Process Elaboration Phase: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler and L. L. Constantine, The Unified Process Construction Phase: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler and L. L. Constantine, The Unified Process Transition and Production Phases: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2002). 26 S. W. Ambler, Process Patterns—Building Large-Scale Systems Using Object Technology (Cambridge, UK: SIGS Books/Cambridge University Press, 1998); S. W. Ambler, More Process Patterns—Delivering Large-Scale Systems Using Object Technology (Cambridge, UK: SIGS Books/Cambridge University Press, 1999); I. Graham, B. Henderson- Sellers, and H. Younessi, The OPEN Process Specification (Harlow, UK: Addison-Wesley, 1997); B. Henderson-Sellers and B. Unhelkar, OPEN Modeling with UML (Harlow, UK: Addison-Wesley, 2000). The Unified Process 23 Engineering Workflows Phases Inception Elaboration Construction Transition Production Business Modeling Requirements Analysis Design Implementation Test Deployment Supporting Workflows Phases Inception Elaboration Construction Transition Production Configuration and Change Management Project Management Environment Operations and Support Infrastructure Management Iter … Iter Iter … Iter Iter … Iter Iter … Iter 1 i i+1 j j+1 k k+1 m FIGURE 1-4 The Enhanced Unified Process Production Phase The production phase is concerned primarily with issues related to the software product after it has been successfully deployed. This phase focuses on issues related to updating, maintaining, and operating the software. Unlike the previous phases, there are no iterations or incremental deliverables. If a new release of the software is to be developed, then the developers must begin a new run through the first four phases. Based on the activities that take place during this phase, no engineering workflows are relevant. The supporting workflows that are active during this phase include the configuration and change manage-

Chapter 1: Introduction to Systems Analysis and Design PDF

Document Details

Tags

Related

Summary

Full Transcript