Chapter 2 Book.pdf

CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 9 There are several benefits to iterative development. For one, portions of the system can sometimes be deployed sooner. If there are core functions that provide basic support for users, these can be deployed in an early iteration. Second, by taking a small portion and developing it first, the most difficult problems can be identified and addressed early in the project. Many of today’s systems are so large and complex that even with a formal process it is impossible to remember and understand everything. By focusing on only a small portion at a time, the requirements are fewer and easier to solve. Finally, developing a system in iterations makes the entire development process more flexible and able to address new requirements and issues that come up throughout the project. A key element of iterative development is dividing system components into pieces that can be completed in two to four weeks. During one iteration, all the core development processes are involved, including programming and systemwide testing, so the result is a working part of the system, even though it may only have a portion of the functionality that is ultimately required. Developers choose components for each iteration based on priority, either the components most needed or riskiest to implement. To better illustrate these concepts, we will walk through a complete example in the next sections concerning Ridgeline Mountain Outfitters (RMO). These sections use a fairly small information system to demonstrate all six core processes (as much as is feasible in a textbook, anyway). The example completes one iteration in detail, but the project actually requires multiple iterations. By going all the way through a very simple project, you will more easily understand the complex concepts provided in the rest of the text. ■ Introduction to Ridgeline Mountain Outfitters (RMO) Ridgeline Mountain Outfitters (RMO) is a large retail company that specializes in clothing and related accessories for all types of outdoor and sporting activities. The mountain and western regions of the United States and Canada witnessed tremendous growth in recreation activities in recent years, including skiing, snowboarding, mountain biking, water skiing, jet skiing, river running, sailing, jogging, hiking, ATVing, cycling, camping, mountain climbing, and rappelling. With the increased interest in outdoor sports, the market for winter and summer sports clothing and accessories exploded, so RMO continually expanded its line of sportswear to respond to this market. The company’s growth charted an interesting history of mail-order, brickand-mortar, and online sales. RMO got its start by selling to clothing stores in the Park City, Utah, area. In the late 1980s and early 1990s, it began selling directly to customers using catalogs with mail-in and telephone-order options. It opened its first store in 1994. After the Winter Olympics in Park City in 2002, business exploded and RMO quickly expanded to 10 retail outlets throughout the West and added Internet sales. Last year, retail store revenue was $67 million, telephone- and mail-order revenues were $10 million, and Internet sales were $200 million. Most sales continue to be in the West, although the market in several areas of the eastern United States and Canada is growing. By the Winter Olympics in Vancouver, British Columbia, in 2008, RMO’s growth and profits resulted mainly from online sales and service, as with most specialty retailers; however, the brick-and-mortar and mail-order business remained important, too. After the Winter Olympics in Sochi in 2014, RMO negotiated with several Utah Olympic Medal Winners for endorsements. This provided additional interest throughout the West and instigated another period of rapid growth. Figure 1-6 shows a sample of the catalog that RMO still mails out. Although mail-order and telephone sales are modest, receiving the catalog encourages 10 PART 1 ■ Introduction to System Development FRE 1-6 RMO winter catalog 2016 WINTER CATALOG 2016 WINTER CATALOG FRE 1-7 RMO online ordering home page customers to go online to make purchases, so RMO continues to produce and mail abbreviated versions. Figure 1-7 shows the RMO online ordering home page. RMO produces its own line of outdoor clothing and sportswear. However, to offer a complete range of clothing in its retail outlets, it also sells brands of clothing sourced from other vendors. Furthermore, most accessories sold are sourced through vendors. ■ Trade Shows To keep its product line innovative and responsive to consumer demand, RMO’s purchasing agents attend apparel and accessory trade shows around the world CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 11 where vendors exhibit their merchandise. RMO is good at anticipating trends and profiting from interesting vendor specials. Furthermore, its agents are always watching for new products and accessories to expand RMO’s product line appropriately. At the trade shows, RMO purchasing agents frequently find products they want to add to the spring, summer, or winter apparel offering. In the past, when RMO purchasing agents wanted to place an order with a vendor, they would exchange contact information with the vendor at the trade show and would then follow up via e-mails and phone calls to create a purchase order. In the current 24/7 business climate, this business process was just too slow. RMO needed to speed things up to keep ahead of the competition, take advantage of vendor deals at the trade shows, and be more responsive to customer demands. To solve this problem, RMO initiated an information system project to develop a system for collecting and tracking information about suppliers and about products added to its merchandise offerings. The Tradeshow System needs to take advantage of the latest in wireless devices and data capturing technology to allow purchasing agents to research and complete purchase orders on the spot at the trade shows. RMO decided to use an agile, iterative project management approach to get the small system completed as fast as possible with maximum flexibility. ■ Developing RMO’s Tradeshow System We will organize our sample project—the RMO Tradeshow System—into several iterations. Our plan for the first iteration is to have it finished in just six days. Our primary objective is to introduce you to the concepts and techniques of the six core processes. To do this, we may go a little deeper into a core process than we might usually do on the first iteration of a real project. Additionally, the iteration will appear to be managed much more formally than might be the case in the real world for such a small project. The second and subsequent iterations will not be described in any detail, but the complete Tradeshow System project will need several more iterations for a finished product. Most new information system applications require a project with several iterations. In the first iteration, there are usually three major objectives. The first objective is to get project approval. The second objective is to get a clear picture of the system’s overall vision—the overall functions and data requirements. The third objective is to determine the detail specifications and develop a solution for one portion of the system (i.e., actually analyze, design, build, and test one part of the system). The second and third iterations would continue to work on the additional portions of the system based on the system vision. In our project, we will touch on all these objectives within the first iteration. We will show an example of a System Vision Document and then develop one portion of the overall system. It should be noted that the division of this project into days and daily activities is somewhat arbitrary. The following organization is quite workable, but it is not the only way to organize the project. ■ Initial Project Activities Before the project actually begins, the head of RMO’s Purchasing Department works with a systems analyst to identify and document the specific business need and to define the project objectives. RMO’s management then reviews the primary project objectives and provides budget approval. Every organization has to give budget approval before a project can start. Some organizations have a formal process to get a project approved; other organizations have a less-formal process. Although these activities are part of Core Process 1 of the SDLC, they 12 PART 1 ■ Introduction to System Development are often completed well in advance of the start of the first project iteration. They might be called pre-project activities of Core Process 1: ■ ■ Identify the problem and document the objective of the solution system. Obtain approval to commence the project. ❚ System Vision Document As with all new projects within RMO, a System Vision Document is developed to identify the benefits to the company and the functional capabilities that will be included in the system. Frequently, this is done in two steps: developing a preliminary statement of benefits and then adding estimates of specific dollar costs and dollar benefits. Figure 1-8 is the System Vision Document for this project. As described earlier, RMO needs a mobile system that can be used by its purchasing agents as they attend various product, clothing, and fabric trade shows. The system needs to fulfill two major requirements. First, it has to have the functionality to capture information about suppliers and products. Second, it needs to be able to communicate with the home office systems, and because these trade shows are held in various venues around the world, various methods of connectivity are needed. Preliminary investigation included various equipment options, like notebook computers, tablets, and smartphones. Smartphones appeared to have the best connection options, but their small size made viewing the details of photographs somewhat difficult; the iPad and other portable tablets with advanced connectivity options also appear to be viable options. Because smartphones and tablets have similar requirements, analysts determine to develop an application that will execute on either type of device, giving purchasing agents multiple options for system access. Toward the end of the initial project activities, a meeting is held involving all the key persons, including a representative of executive management. The decision is made to move ahead with the project and budget the necessary funds. ■ Day 1 Activities ❚ RMO—Tradeshow System Overall The project actually begins with Day 1, which is essentially a planning day. Usually, the project team first reviews the System Vision Document and verifies that the preliminary work is still valid. It reviews the scope of the project to become familiar with the problem, and then it plans the iterations and activities for the remainder of the project. The second SDLC core process—Plan and monitor the project—includes business analysis and project management activities. These Core Process 2 activities are completed on Day 1: ■ ■ ■ Determine the major components (functional areas) that are needed. Define the iterations and assign each functional area to an iteration. Determine team members and responsibilities. ❚ Planning the Overall Project and the Project Iterations subsystem an identifiable and fully functional part of a complete system Many details need to be considered in a project plan. For our project, we will only focus on the bare essentials. We will describe project planning more elaborately in later chapters. The project team meets with the users to review the overall business need and the objectives of the new system. The System Vision Document serves as the starting point for these discussions. As is often the case, the list of system capabilities provides the foundation information for determining the overall project plan. The first step is to divide the system into several subsystems or components. A subsystem is a fully functional part of the complete CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design FRE 1-8 Tradeshow System Vision Document 13 System Vision Document RMO Tradeshow System Problem Description Trade shows have become an important information source for new products, new fashions, and new fabrics. In addition to the large providers of outdoor clothing and fabrics, there are many smaller providers. It is important for RMO to capture information about these suppliers while the trade show is in progress. It is also important to obtain information about specific merchandise products that RMO plans to purchase. Additionally, if quality photographs of the products can be obtained while at the trade show, then the creation of online product pages is greatly facilitated. It is recommended that a new system be developed and deployed so field purchasing agents can communicate more rapidly with the home office about suppliers and specific products of interest. This system should be deployed on portable equipment. System Capabilities The new system should be capable of: • Collecting and storing information about the manufacturer/wholesaler (suppliers) • Collecting and storing information about sales representatives and other key personnel for each supplier • Collecting information about products • Taking pictures of products (and/or uploading stock images of products) • Functioning as a stand-alone without connection • Connecting via Wi-Fi (Internet) and transmitting data • Connecting via telephone and transmitting data Business Benefits It is anticipated that the deployment of this new system will provide the following business benefits to RMO: • Increase timely communication between trade show attendees and home office, thereby improving the quality and speed of purchase order decisions • Maintain correct and current information about suppliers and their key personnel, thereby facilitating rapid communication with suppliers • Maintain correct and rapid information and images about new products, thereby facilitating the development of catalogs and Web pages • Expedite the placing of purchase orders for new merchandise, thereby catching trends more rapidly and speeding up product availability information system. Based on the list of system capabilities, the project team identifies these two subsystems: ■ ■ Supplier Information Subsystem Product Information Subsystem The Supplier Information Subsystem will collect and maintain information about the manufacturers or wholesalers and the contact people who work for them. The Product Information Subsystem will capture information about the various products offered by the manufacturers or wholesalers, including detailed descriptions and photographs. 14 PART 1 ■ Introduction to System Development The next step is to identify the order in which the subsystems will be developed. Many issues are considered, such as dependencies between the various tasks, sequential versus parallel development, project team availability, and project urgency. In our case, the team decides that the Supplier Information Subsystem should be scheduled for the first iteration and the Product Information Subsystem should be scheduled for the second iteration. The third and fourth iterations would complete the implementation, testing, and deployment of the system based on what was initially implemented in the first two iterations. ❚ Planning the Rest of the First Iteration: The Supplier Subsystem Each iteration is like a system development mini-project. The core processes described earlier can all be applied, with the scope limited to the component that is to be developed during the iteration. The planning process for an iteration consists of these three steps: ■ ■ ■ Identify the tasks required for the iteration. Organize and sequence these tasks into a schedule. Identify required resources (especially people), and assign people to tasks. The first step is to identify—or attempt to identify—all the individual tasks that need to be done. As these tasks are identified, they are compiled and organized. Sometimes, this organized list of tasks is called a work breakdown structure (WBS). Figure 1-9 shows the WBS for this iteration. Part of this effort is trying to estimate how long each task will take. Because this iteration has a very limited scope (and only six days), all the estimates will be in hours. These estimates do not include the time expended by those who are not on the team. However, of those on the team, the estimates include the time for the original work, the time for discussion, and the time for reviewing and checking the WBS for accuracy and correctness. © Cengage Learning ® FRE 1-9 Sample handwritten work breakdown structure (WBS) CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 15 The next step is get these tasks organized into a schedule. Again, we can be very formal and use a sophisticated project scheduling tool, or we can just list the tasks in the order we think they need to be done. Creating the tasks in order is an important part of building the schedule because it identifies any dependencies among the tasks, though many tasks can be done in parallel. For example, it does not make sense to try to design the database before we have identified the information requirements. Again, the great benefit of planning a single iteration is that we can make the schedule informal, and we will be able to adjust the work day-by-day to respond to complexities that occur. For this iteration, we have taken the tasks from the WBS and placed them on a day-by-day sequence that we call an iteration schedule, as shown in Figure 1-10. The project manager can use this diagram to assign people to the tasks and to put the tasks on a specific schedule chart with calendar dates if necessary. FRE 1-10 Schedule for the first iteration Start 0-1 Develop project plan I-1 3 hrs I-2 Meet with purchasing manager I-3 Day 1: Plan project 4 hrs Meet with purchasing agents I-4 3 hrs 2 hrs Define information requirements Define use cases I-5 Day 2: 12 hours 6 hrs Develop workflows II-1 8 hrs Design screens II-2 Day 3: 14 hours 4 hrs II-3 Design and build database 4 hrs Design overall architecture Morning of Day 4: 8 hours 6 hrs III-1 14 hrs Code and test GUI layer IV-1 III-2 8 hrs Code and test logic layer Day 5: 28 hours 5 hrs Perform functional tests Day 6: 12 hours IV-2 7 hrs Perform user acceptance test © Cengage Learning ® II-4 Design program details 16 PART 1 ■ Introduction to System Development You should be aware that the sequence of activities and the dependencies of those activities are represented in this diagram with only partial accuracy. For example, we show that programming does not start until design has finished. However, in reality, there may be some overlap between the two activities. The benefit of an iteration schedule is threefold. First, it helps the team organize its work so developers have enough time to think through the critical design issues before programming begins. Second, it provides a measuring rod to see if the iteration is on schedule. For example, if meetings with the purchasing agents take all day or more than a day, the team will know early on that this iteration will take longer than expected. Third, the project manager can see that programming may require more resources if the project is going to stay on this schedule. Hence, the project manager can begin lining up resources to help with that part of the iteration. It should be obvious that even this simple diagram can help a project manager plan and organize the work. ■ Day 2 Activities ❚ The Tradeshow System Overall Day 1 involved planning and organizing the project. Day 2 involves discovering and understanding details, which is a key part of systems analysis. Now we will complete the systems analysis activities in more detail for the complete Tradeshow System. These Core Process 3 activities include: ■ ■ ■ Do fact-finding tasks to understand the requirements. Develop a list of use cases and a use case diagram. Develop a list of classes and a class diagram. ❚ Fact Finding and User Involvement Before the project commenced, a broad definition of requirements was developed. It is now time to examine those requirements and determine exactly what the user needs the system to do. There are various techniques to ensure that the fact finding is complete and thorough. These include interviewing the key users, observing existing work processes, reviewing existing documentation and existing systems, and even researching other companies and other systems. The first step is to identify the key users who will define these details. In this scenario, the manager of the Purchasing Department will be one of the first users to meet with. She will probably designate one or two knowledgeable purchasing agents who can work with the team on an ongoing basis to develop the specifications and to verify that the system performs as required. All successful projects depend on heavy user involvement. In Chapter 2, you will learn more about identifying key stakeholders and gathering information. ❚ Identifying Use Cases Identifying and describing use cases is the way to document what the users need to do with the system, hence, the term use case—a case or situation where the system is used. For example, suppose a purchasing agent goes to a trade show and finds a new lightweight sports jacket that will work well for RMO’s fall merchandise offerings. Suppose that the first task the purchasing agent needs to do is find out if this supplier has worked with RMO before. Thus, a use case required for the Tradeshow System might be Look up a supplier. One good way to help you talk about use cases is to say, “The purchasing agent ‘uses’ the system to ‘Look up a supplier.’” There are multiple methods used to identify use cases, which you will learn later in this book. Some developers prefer to use a similar concept called a user story. FRE 1-11 List of use cases for Tradeshow System 17 Use Case Description Look up supplier Using supplier name, ﬁnd supplier information and contacts Enter/update supplier information Enter (new) or update (existing) supplier information Look up contact Using contact name, ﬁnd contact information Enter/update contact information Enter (new) or update (existing) contact information Look up product information Using description or supplier name, look up product information Enter/update product information Enter (new) or update (existing) product information Upload product image Upload images of the merchandise product Figure 1-11 is a preliminary list of use cases for the entire Tradeshow System. When the project team meets with the purchasing agents in brainstorming sessions, they identify the use cases together. Because the first iteration is focusing only on the Supplier Information Subsystem, the project team will also focus its attention on only the first four use cases on the list. ❚ Identifying Domain Classes FRE 1-12 List of domain classes for Tradeshow System Object Classes Attributes Supplier supplier name, address, description, comments Contact name, address, phone(s), e-mail address(es), position, comments Product category, name, description, gender, comments ProductPicture ID, image © Cengage Learning ® Domain classes identify those things in the real world that the system needs to know about and keep track of. To find domain classes, we look for all objects, or things, that the system uses or captures. Objects come in all types and variations, from tangible items (such as merchandise products that you can see and touch) to more abstract concepts that you cannot touch (such as a promotion), which, though intangible, is an important thing to remember and track. Domain classes are the categories of objects identified, much like a table in a database represents the category of the records it contains. A Product class represents all of the product objects used by the system. Domain classes are identified during the discussions with purchasing agents by looking for the nouns that describe categories of things. For example, the agents will often talk about suppliers, merchandise products, or inventory items. These nouns become the domain classes, and each domain class has attributes (like contact information, product, or business location) that detail the information you need to store about the domain class. Figure 1-12 illustrates which nouns are fundamental domain classes for the Tradeshow System. The attributes are pieces of information that help define and describe details about a domain class. © Cengage Learning ® CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design PART 1 ■ Introduction to System Development FRE 1-13 Preliminary domain class diagram for the Tradeshow System Contact Supplier name address description comments 1 1..* name address phone(s) emailAddress(es) position comments 1 1..* ProductPicture Productltem productCategory name description gender comments 1 0..* pictureID image In addition to just providing a list of domain classes, systems analysts often develop a visual diagram of the classes, their attributes, and their associations with other classes. This diagram is called a domain class diagram. Figure 1-13 shows the domain class diagram for the Tradeshow System. Each box is a class and can be thought of as a particular set of objects that are important to the system. Important attributes of each class are also included in each box. These represent the detailed information about each object that will be maintained by the system. Note that some classes have lines connecting them. These represent associations between the classes that need to be remembered by the system. For example, a contact is a person who works for a particular supplier. A specific example might be that Bill Williams is the contact person for the South Pacific Sportswear Company. Thus, the system needs to associate Bill Williams and the South Pacific Sportswear Company. The association line documents that requirement. Domain class diagrams are a powerful and frequently used way to understand and document the information requirements of a system. The Tradeshow System is very simple, with only four classes identified—two of which belong to the Supplier Information Subsystem. Most real-life systems are much larger and have dozens or even hundreds of domain classes. ■ Day 3 Activities The purpose of Day 3 activities is to analyze in detail the use cases and domain classes that are scheduled to be implemented in the first iteration for the Supplier Subsystem. Included are these Core Process 3 activities: ■ ■ ■ Perform in-depth fact finding to understand details of each use case. Understand and document the detailed workflow of each use case. Define the user experience with sketches of screens and reports needed for each use case. After working with the purchasing agents, developers determined the following use cases pertaining to the Supplier Information Subsystem: ■ ■ Look up supplier Enter/update supplier information © Cengage Learning ® 18 CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design ■ ■ 19 Look up contact information Enter/update contact information From this list, the developer will then create a use case diagram. A use case diagram is used to graphically portray the use cases and users involved in the subsystem. Figure 1-14 illustrates a simple use case diagram for the Supplier Information Subsystem showing the four use cases as ovals and the two users as stick figures. The lines connecting users and use cases shows who uses the system for the use case: The purchasing agent carries out all four use cases, but the manager also looks up suppliers or contacts. The project team will look closely at the steps to follow for each use case to better understand how the application needs to work and to identify what screens and reports will need to be developed. As the team gets more into the details, it may discover that some of the initial analysis is incomplete or not correct and can adjust the WBS to reflect the changes. This is a good time to make such discoveries—much better to find mistakes earlier than after the programs have been written. ❚ Developing Use Case Descriptions and Workflow Diagrams There are various methods for documenting the details of a use case. One that you will learn later in this text is called a use case description. Another method is developing an activity diagram, which shows all the steps within the use case. The purpose with either method is to document the interactions between the user and the system (i.e., how the user interacts and uses the system to carry out a specific work task for a single use case). Let us develop an activity diagram for one use case. Figure 1-15 illustrates the Look up supplier use case. The flattened ovals in the diagram represent the activities, the diamonds represent decision points, and the arrows represent the sequence of the flow. The columns designate the person who performs the activities, in this case the purchasing agent in the first column and the Tradeshow System in the second column. Usually, activity diagrams are quite easy for users to understand and critique. FRE 1-14 Use case diagram for the Supplier Information Subsystem Look up supplier Enter/update supplier information Look up contact Manager Enter/update contact information © Cengage Learning ® Purchasing agent PART 1 ■ Introduction to System Development FRE 1-15 Activity diagram for the Look up supplier use case Purchasing Agent Tradeshow System Start Enter supplier name Return supplier information not found found View supplier and contact names done look up contact Select contact name Retrieve contact information View contact information End The arrows that cross the line between users (center) represent the interactions between the user and the system. These are critically important because they designate situations where the developers must provide a screen or Web page that either captures or displays information. These situations become part of the user interface. In Figure 1-15, the top arrow indicates that the supplier name is entered into the system first. Thus, we infer that the use case must have an online lookup page with a field available to enter the supplier name. The next arrow indicates the application requires a page that displays all the details for an individual supplier, including a list of existing contacts. The user may also want to see more details about a specific contact person for this supplier, so the application must provide detailed information request fields for a particular contact. Because the user will need to select one of the displayed results, we must design the page so each entry on the list is either a hot link or can be selected. ❚ Defining Screen Layout User-interface design includes creating how a system looks and how the user interacts with it. Because the user interface is the user’s window to the functionality of the system, it is essentially the system itself to the users. If the interface is poorly designed, users will not be able to take full advantage of the system; they may even consider the system to be less than optimal. On the other © Cengage Learning ® 20 CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 21 hand, a well-designed user interface—one that is intuitive and easy to use, has a full range of features to facilitate navigation, and provides good information— will enhance the utility of the system tremendously. Figure 1-16 illustrates the layout of the first page used for the workflow in the use case Look up supplier. The top half of the page provides the fields where the user enters supplier information, and the bottom portion of the page shows the results. After results are provided, the search box for data entry will remain visible to allow the user to enter another search. Each entry in the results section will be built as a hot link, so the user can click on any particular supplier to retrieve more detailed information. This drill-down technique is a common method used in today’s systems and will be intuitively easy for the users. Data for all of the required fields are stored in the database. Searches seek information in the database, and display the required data, such as name, address, and contact information. An Internet-wide search is also possible. This allows the purchasing agents to look for and view the suppliers’ own Web sites, including forums and discussions about the supplier. ■ Day 4 Activities The primary focus of Day 4 is to design the various components of the solution system, corresponding to Core Process 4: Design System Components. Up to now, we have mostly been gathering the user requirements. On Day 4, we design the system based on the user requirements, which leads to programming efforts. In that sense, design activities can be considered a bridge. The design documents provide the blueprints for how the solution will be structured and how it is to be programmed. System design also tends to involve the technical people, with less need for user participation. Design can be a complex process. In our small project, we will limit our design examples to only a few models and techniques. Day 4 activities (Core Process 4) include the following: ■ Design the database structure (schema). Design the system’s high-level structure. FRE 1-16 Initial page layout for the Look up supplier use case Web Search GO Logo RMO Database Search Supplier Name Product Category Product Country Contact Name GO Search Results Supplier Name Contact Name Contact Position © Cengage Learning ® ■ 22 PART 1 ■ Introduction to System Development Database design is a fairly straightforward activity that uses the domain class diagram and develops the detailed database schema that can be directly implemented by a database management system. Such elements as table design, key and index identification, attribute types, and other efficiency decisions are made during this activity. Designing the high-level system structure and the individual programs can be an intricate and complex process. First, the overall structure of the system is designed by identifying the subsystems and connections to other systems. Then, within each subsystem, decisions are made about individual program modules, such as the user interface, business logic, and database access. It is not uncommon for developers to begin writing program code as they develop portions of the design. However, best practice suggests that the designer complete most of the high-level structure design before writing code. Consequently, in the RMO Tradeshow System project, we will list them as separate activities. ❚ Designing the Database Designing the database uses the information provided by the domain class diagram to determine the tables, the columns in the tables, and other components. Sometimes, the database design is done for the entire system at once or by subsystem. At other times, it is built piecemeal—use case by use case. To keep our project simple, we will just show the database design for the two Supplier Information Subsystem classes. Figure 1-17 shows the two relational database tables that result with attributes included along with data types and other properties. ❚ A General Approach to Design One of the first questions encountered in software design is how and where to start. So far, we have compiled three sets of information that can answer that question: ■ ■ FRE 1-17 Database design for Supplier Information Subsystem Use cases, with activity diagrams Domain classes, with accompanying diagrams Pages and reports, with program and display logic specifications Table Name Attributes Supplier SupplierID: integer {key} Name: string {index} Address1: string Address1: string City: string State-province: string Postal-code: string Country: string SupplierWebURL: string Comments: string Contact ContactID: integer {key} SupplierID: integer {foreign key} Name: string {index} Title: string WorkAddress1: string WorkAddress2: string WorkCity: string WorkState: string WorkPostal-code: string WorkCountry: string WorkPhone: string MobilePhone: string EmailAddress1: string EmailAddress2: string Comments: string © Cengage Learning ® ■ CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 23 FRE 1-18 Tradeshow System software components diagram Browser Internet Internet server Tradeshow System Product Information subsystem © Cengage Learning ® Supplier Information subsystem Incidentally, in the previous section, we used the class diagram as the basis for the database design. Those same classes are important in developing objectoriented program classes. Before we jump more into software design, let us briefly discuss the objective of systems design and what we expect the output or result to be. Object-oriented programs are structured as a set of interacting objects based on classes. To program, we need to know what the classes are, what the logic is within each class (i.e., the functions), and which classes must interact. This is the final objective of systems design. We perform this design by starting at the very highest level and then drilling down to the lowest level until we have defined all the functions within each class. Detailed design documents the thought process of how to program each use case. For Day 4, we focus only on the overall design. ❚ Designing the Software Components Figure 1-18 shows the overall structure of the new system in terms of software components. Although the figure itself appears rather simple, some important decisions have been involved in the development of this design. First, note that the decision was made to build this application as a browser-based system designed for use on smartphones and tablets. A different and very popular approach would have been to build specific smartphone or tablet applications. Browser-based systems sometimes do not provide the same connectivity speed and control as smartphone or tablet applications, but they are more versatile because they are easily deployed on different equipment, such as laptops and tablets, without modification, and on smartphones with only slight modification due to screen size. These high-level design decisions will determine the detailed structure of the system. A browser-based system is structured and constructed differently than an application system that runs on a smartphone or a tablet computer. ❚ Defining the Preliminary Design Class Diagram The Tradeshow System will be built by using object-oriented programming (OOP) techniques, beginning with developing the set of software classes and 24 PART 1 ■ Introduction to System Development their methods that will be needed for the system. Figure 1-19 is a preliminary design class diagram for the Supplier Information Subsystem that identifies the software classes needed for the system (for example, the SupplierView and ContactView classes). In Figure 1-19, we show only the problem domain design classes and the user-interface View layer classes. Problem domain design classes are usually derived from those classes that were identified during analysis activities—hence, the name: problem (user need) domain design classes. You will also notice that they very closely correspond to the database tables; in fact, in this simple project, they are almost exactly the same as the database tables. The design classes in Figure 1-19 include the attributes that are needed for the class. They also include method names of the important methods within each class. One final element in the design class diagram is the arrows that show where a class accesses the methods of another class. ❚ Designing Subsystem Software Architecture Once we have an overall structure and approach for implementing the new system, we begin to drill down to the software design for the subsystem. Figure 1-20 illustrates the design of the Supplier Information Subsystem. Notice that this subsystem is further divided into layers: a View layer and a Domain layer. One of the advantages of partitioning the system into layers is it is much easier to build and maintain with this kind of structure given its modular format. For example, the system will be browser based, but different browsers require different techniques. It is better not to get these complexities mixed in with the basic program functions. Hence, they are separated out into a distinct layer. SupplierView +lookupSupplier ( ) +displaySupplier ( ) Supplier ContactView +lookUpContact ( ) +displayContact ( ) Contact –supplierID {key} name: string address: string address2: string city: string state: string country: string URL: string comments: string –contactID {key} –name: string {index} title: string waddress1: string waddress2: string wcity: string wstate: string wpostal: string wcountry: string wphone: string mobilephone: string email1: string email2: string comments: string +getSupplierInfo ( ) +getContactInfo ( ) © Cengage Learning ® FRE 1-19 Preliminary design class diagram CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design Supplier Subsystem Domain layer View layer SupplierView lookUpSupplier ( ) displaySupplier ( ) ContactView lookUpContact ( ) displayContact ( ) Supplier getSupplierInfo ( ) Contact getContactInfo ( ) Javascript Functions validateSupplierInput ( ) validateContactInput ( ) php html/css javascript php sql The View layer includes two classes that represent what is seen on the user interface—SupplierView and ContactView—as well as some JavaScript functions. The Domain layer includes two classes that interact with each other and with the database—Supplier and Contact. ❚ Managing the Project Design is a complex activity with multiple perspectives—from high-level structural design to low-level detailed program design. In our project, we have separated the tasks for designing the overall system structure from detailed design of the programs themselves. However, these activities are often done concurrently. The basic high-level software architectural structure is defined first, but midlevel and low-level design are often done concurrently with programming. Detailed design and programming are quite time-consuming activities. A project manager must decide whether to extend the project or bring on additional programmers to help write the code. In our project, we have elected to insert a half-day of free time to bring in two additional programmers and train them. Of course, we could go ahead and begin Day 5’s activities to ensure that we keep the project on schedule. ■ Day 5 Activities As mentioned previously, though detailed design and programming may begin earlier in the project, we identify it as a separate day’s activity. We want to emphasize that it is not a good practice to begin programming before critical information is obtained and decisions are made. A much better approach is to understand, design, and build small chunks of the system at a time. Iterative © Cengage Learning ® FRE 1-20 Supplier Subsystem software architecture 25 26 PART 1 ■ Introduction to System Development development anticipates and plans for the expected changes and refinements to the problem requirements that happen during detailed design and programming. Day 5 activities include the following (Core 5 Process): ■ ■ Create detail design. Program the subsystem components. As the programmers write the code, they also perform individual testing on the classes and functions they program. This textbook does not focus on programming activities. However, we include an example of program code so you can see how systems design relates to the final program code. Figure 1-21 shows PHP code that defines the SupplierView class that receives and processes the request for supplier information. Note that it sends a message to the Supplier class requesting information when needed. ■ Day 6 Activities The focus of Day 6 activities is final testing, a step that is required before the system is ready to be deployed. Although there are many types of testing, we mention only two types at this time: overall system functional testing and user acceptance testing. Functional testing is usually a test of all user functions and is often done by a quality assurance team. User acceptance tests are similar in nature, but these are completed by the users, who test both the correctness of the system and its “fitness” to accomplish the business requirements. Each of the various testing activities in Day 6 has a similar sequence of tasks to perform. The tasks themselves highly depend on the test data and on the method for testing a particular test case. In some instances, the testing may be automated. In others, individuals may need to manually conduct the tests. <?php class SupplierView { private Supplier $theSupplier; function __construct() { $this->theSupplier = new Supplier(); } function lookupSupplier() { include('lookupSupplier.inc.html'); } function displaySupplier() { include('displaySupplierTop.inc.html'); extract($_REQUEST); // get Form data //Call Supplier class to retrieve the data $results = $theSupplier->getSupplierInfo($supplier, $category, $product, $country, $contact); foreach ($results as $resultItem){ ?> <tr> <td style="border:1px solid black"> <?php echo $resultItem->supplierName?></td> <td style="border:1px solid black"> <?php echo $resultItem->contactName?></td> <td style="border:1px solid black"> <?php echo $resultItem->contactPosition?></td> </tr> <?php } include('displaySupplierFoot.inc.html'); } } ?> © Cengage Learning ® FRE 1-21 Code for the SupplierView class CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 27 FRE 1-22 Flowchart for testing tasks Create test data Conduct tests Document errors and issues Fix errors © Cengage Learning ® Start End Figure 1-22 is a flowchart for testing the new system. In this flowchart, we have shown the different testing tasks as separate steps; in reality, they tend to all be carried out together. However, any given test case will follow this flow. ■ First Iteration Recap Figure 1-23 is a screen shot of the browser page that is used in the Tradeshow System to enter and view suppliers. This page will be seen on a tablet. The smartphone page will look different, but it will carry out the same functionality. As stated previously, this is the first (six-day) iteration of a longer project. Using Agile techniques and iterations within an overall project allows flexibility in defining and building a new system. In this six-day project, the users have had major involvement during all days except Day 4 and Day 5. A primary problem in developing a new system is that as the project progresses, new requirements are often identified. This happens because the users and the project team learn more about how to solve the business need. Agile, iterative projects are structured to handle these new requirements—often by adding another iteration to the overall project. As a final step in a current iteration, or perhaps as part of the planning process for the next iteration, there should be a review of the tasks completed and evaluation of the success of the current iteration. The lessons learned and issues to be carried forward create an environment of continual improvement and refinement. Because of this, iterative projects tend to improve and become more efficient during the life of the project. In this project, the planning for Iteration 2 would confirm the intention of focusing on the use cases and domain classes for the Product Information FRE 1-23 Screen capture for page in Look up supplier use case for tablet Web Search GO RMO Database Search Supplier Name Product Category Product Country Contact Name GO Search Results Supplier Name Contact Name Contact Position 28 PART 1 ■ Introduction to System Development Subsystem. Efforts would focus on understanding the details of the three use cases and two domain classes required. Activity diagrams or use case descriptions might be created for the complex use cases. Two more database tables would be designed and implemented. Two more software view classes and design domain classes would be defined. Code would then be written and tested to implement the classes and use cases. ■ Where You Are Headed—The Rest of This Book This seventh edition of Systems Analysis and Design in a Changing World includes the printed textbook and supporting online chapters. The current printed textbook provides a compact, streamlined, and focused presentation of those topics that are essential for information system developers. The online chapters extend those concepts and provide a broader presentation of several topics. The online chapters may be integrated into the course or simply used as additional reading as prescribed by the instructor. We focus on three major subject areas in this book: systems analysis, systems design, and project management. To a lesser extent, we cover systems implementation, testing, and deployment. In addition, we have taken an approach that is quite different from other texts. By providing a basic overview in Chapter 1, we can immediately present in-depth concepts about systems analysis and design in the following chapters. Furthermore, we present project management topics after our discussion on the elements of systems analysis and design, so the reader can use his or her knowledge of necessary analysis and design tasks to understand project management. ■ Part 1: Introduction to System Development Part 1—comprising Online Chapter A and Chapter 1—presents an overview of systems development. Online Chapter A, “The Role of the Systems Analyst,” describes the many skills required of a systems analyst. It also discusses the various career options available to information systems majors. For those of you who are new to the discipline of information systems, this chapter provides interesting and helpful knowledge about information systems careers. Be sure to find and refer to this online chapter. This chapter (Chapter 1) provided a detailed, concrete example of what is required in a typical (though simplified) system development project, including processes, techniques, and diagrams. You are not expected to understand all the elements from this brief introduction. However, you should have a general idea of how to approach developing systems. You may want to refer back to this chapter to understand the big picture. ■ Part 2: Systems Analysis Tasks Chapters 2, 3, 4, and 5 cover systems analysis in detail. Chapter 2 discusses techniques for gathering information about the business problem. Developing the right system solution is possible only if the problem is accurately understood. The people who are affected by the system (the stakeholders) are included in the development of the solution. Chapter 2 explains how to identify and involve the stakeholders, and introduces the concept of models and modeling. Chapters 3 and 4 present methods for capturing the detailed system requirements in a useful format, often models. Chapter 5 presents in-depth models that focus on the details of each use case—use case descriptions, activity diagrams, and system sequence diagrams. Online Chapter B, “The Traditional Approach to Requirements,” presents a traditional, structured approach to developing systems. To those instructors and CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 29 students who desire to learn about data flow diagrams, this chapter provides an in-depth presentation. ■ Part 3: Essentials of Systems Design Chapters 6, 7, 8, and 9 cover the fundamental concepts related to systems design, including design activities, architectural design, user-interface design, and database design. Chapter 6 provides broad and comprehensive coverage of important concepts and activities of systems design. It serves not only as a broad overview of design principles, but also as a foundation for later chapters that explain the detailed techniques, tasks, skills, and models used to carry out design. Chapter 7 covers key aspects of architectural design. System interfaces occur when one information system communicates or interacts with another information system without human intervention. System interfaces are becoming increasingly important because of Web services and cloud computing. Other related concepts, such as controls and security, are also presented in this chapter. Chapter 8 presents design principles related to the user. Designing the user interface requires a combination of analysis and design. It is related to analysis because it requires heavy user involvement and includes specifying user activities and desires. On the other hand, it is a design activity because it specifies final components that are used to drive the programming effort. The pages, forms, reports, and other user interaction components must be precisely designed so they can be programmed as part of the final system. Chapter 9 explains how to design the database from the information gleaned during analysis and the identification of the domain classes. ■ Part 4: Projects and Project Management By this point, you will have a basic understanding of all the elements of system development. Part 4 uses these concepts to explain the process of organizing and managing development projects. Chapter 10 describes different approaches to system development in today’s environment, including important system development life cycle models. It is an important chapter to help you understand how projects actually get executed. Additionally, Agile development is discussed in more detail along with two specific Agile system development methodologies—Agile Unified Process and Scrum. Chapter 11 teaches foundational principles of project management. Every systems analyst helps organize, coordinate, and manage software development projects. In addition, many analysts will become team leaders and project managers. The principles presented in Chapter 11 are essential to a successful career and they are related specifically to Agile methodologies. Online Chapter C, “Project Management Techniques,” goes into more detail regarding the tools and techniques used by systems analysts and project managers to plan and monitor development projects. For those instructors and students who would like to learn advanced project management skills, this is an important chapter. ■ Part 5: Advanced Design and Deployment Concepts Chapters 12 and 13 explain the models, skills, and techniques used to design software for each use case, including designing for multilayer software. The objective of these two chapters is to teach you the techniques—from simple to complex— that can be used to effectively design software. Chapter 14 describes the final elements in system development: testing, deployment, maintenance, and version control. 30 PART 1 ■ Introduction to System Development CHAPTER SMMARY This chapter provided an overview of an information systems development project called the Tradeshow System. An information system is a set of interrelated components that collect, process, store, and provide as output the information needed to complete business tasks. Systems analysis is the set of activities used to understand and document what the new information system should accomplish. Systems design involves describing in detail the resulting system. The system development life cycle (SDLC) identifies all of the activities required to research, build, launch, and maintain an information system. Most SDLCs include the following six core processes, although names used for the processes vary: 1. 2. 3. 4. Identify the problem and obtain project approval. Plan and monitor the project. Discover and understand the details of the problem. Design the system components that solve the problem. 5. Build, test, and integrate system components. 6. Complete system tests and then deploy the solution. A system development methodology (also called a development process) provides a comprehensive set of guidelines for carrying out the core processes and corresponding activities and tasks for the SDLC. Agile development refers to recent methodologies that emphasize flexibility and rapid response to change. Iterative development is an approach to the SDLC where the system is “grown” through a series of mini-projects. Agile development is highly iterative. The activities and tasks that support the six core processes of the SDLC were explained as we went through an implementation of one subsystem of the Tradeshow System. We divided the project into initial project activities that comprised six project work days to show how the first iteration of the Tradeshow System was completed. KEY TRMS Agile development project computer application (app) subsystem information system system development life cycle (SDLC) iterative development system development process (methodology) systems analysis systems design REIEW QSTIOS 1. What is the difference between an information system and a computer application? 2. What is the purpose of systems analysis? Why is it important? 3. What is the difference between systems analysis and systems design? 4. What is a project? 5. What is the purpose of the system development life cycle (SDLC)? 6. What are the six core processes of the SDLC? 7. What is meant by Agile development and iterative development? 8. What is the purpose of a System Vision Document? 9. What is the difference between a system and a subsystem? 10. What is the purpose of a work breakdown structure (WBS)? 11. What are the components of a work breakdown structure (WBS)? What does it show? 12. What information is provided by use cases and a use case diagram? 13. What information is provided by a domain class diagram? 14. How do a use case diagram and a domain class diagram drive the system development process? 15. What is an activity diagram? What does it show? 16. How does an activity diagram help in userinterface design? 17. What is the purpose of software component design? 18. What new information is provided in a design class diagram (more than a domain class diagram)? 19. What are the steps of system testing? 20. What is the purpose of user acceptance testing? 21. Why is it a good practice to divide a project into separate iterations? 22. What should be the primary objective of each iteration? CHAPTER 1 ■ From Beginning to End: An Overview of Systems Analysis and Design 31 PROBLEM AND EXERCISES 1. Consider the example that described the responsibilities of a property owner, an architect, and a contractor when creating a new building. Create a similar analogy for a high school reunion project where there is the reunion committee, a professional event planner, and a hotel event vendor that would manage the actual event. h. Initial Screen Layout (Figure 1-16) i. D

Chapter 2 Book.pdf

Document Details

Tags

Related

Full Transcript

Upgrade to continue