Ch01 Software engineering.docx

Information systems engineering Software engineering Systems engineering Chapter 1 - Introduction CHAPTER OBJECTIVES (You should be able to): 1. Define a system, information system, and automated information system. 2. Define the basic components and the basic characteristics of an automated information system. 3. Define systems analysis and design and discuss why it is a difficult human endeavor. 4. Describe the skills and activities of a systems analyst. 5. Describe a general model of the analysis, design and implementation process. 6. Discuss systems analysis and design as a career. 7. Discuss what a systems analyst does. 8. Discuss systems analysis and design projects and where they come from. 9. Discuss the need for creating information systems requirements specifications. 10. Define and describe the information systems life cycle. 11. Define and describe the information systems development life cycle. 12. Discuss the principles used to guide systems analysis and design. A computer salesperson, a computer hardware engineer, and a computer software engineer were traveling the freeway together one afternoon to make a sales presentation. Suddenly the right front tire of the automobile they were riding in burst. After the driver calmly pulled the vehicle over to the side of the freeway, each got out of the car and looked at the problem tire. The salesperson said, "No problem, we should just call the auto club and have them take care of it for us." The hardware engineer said, "We don't need to call them. Let's just put the spare tire on ourselves." Finally, the software engineer said, "Let's all get back in the car and hope that the problem goes away all by itself." Welcome to the world of systems analysis and design, a discipline where we sometimes wish that "problems would just go away all by themselves." The fact is, they rarely do. Systems analysis and design is an exciting, challenging, and ever-evolving discipline. Its challenge is the development of quality information systems that meet users’ requirements and have a minimum of problems. I have been involved with systems analysis and design sine the late 1960s and am glad that you are studying it during this very exciting time of computer technology. I hope that you, too, have captured or soon will capture the excitement and challenge that this discipline has to offer men and women today. There are many different ways that the information in this book can be useful to you as you pursue your professional goals. So, let's get going. The purpose of this chapter is to give you a broad overview of systems analysis and design as a discipline. Although the book’s primary goal is to introduce you to an object-oriented methodology for analyzing, designing, and implementing information systems, this chapter is, by design, an overview of the discipline, void of much of the technical strategies, methodologies, and details used when analyzing, designing, and implementing information systems. As such, this chapter could be considered an introductory chapter for almost any systems analysis and design book. My hope is that the remainder of the book will bring the information in this chapter to life for you by introducing you to a specific and practical object-oriented methodology for systems analysis, design and implementation. SYSTEMS ANALYSIS AND DESIGN HAS MANY OTHER NAMES As with many disciplines, systems analysis and design has many terms that in a general sense refer to the same or similar topic. The actual differences are so subtle that their debate is of little value in an introductory book such as this one. For example, systems analysis and design is also known as information systems engineering, software engineering, systems engineering, software development, and systems development, to name a few. For purposes of this book, these terms will be considered synonymous. Professional men and women working in the field of systems analysis and design often have their own personal preference for the use of these terms. So, no matter which term I chose to emphasize in this book, I could not satisfy everyone. For example, the term information systems engineering could refer to the entire systems development discipline, while systems analysis, systems design, and systems implementation could refer to the three major partitions of information systems engineering. So, what’s the “bottom line” for this book? Here it is: When the term "systems analysis and design" is used throughout the book, it covers the entire systems development process, from planning all the way through implementation, maintenance, and evolution. At various points throughout the book, I may refer to one of the other above-mentioned synonyms for systems analysis and design. This is not done to confuse you, but merely because in some situations the use of one synonym fits better in a given sentence structure than does another synonym. Just remember that each is a synonym for systems analysis and design in this book. At other times I may refer to the individual terms—analysis, design or implementation—which is intended to refer to a smaller portion of systems analysis and design. There is no doubt that systems analysis and design is about developing software, but it is much more than that. While most computer programming courses focus primarily on learning the syntax of the language and then using that language to develop software that has zero defects, systems analysis and design takes a much broader perspective and focuses on: 1. Systems planning - performing planning and initial feasibility activities to determine which information systems projects take priority over others 2. Systems analysis - understanding and documenting the requirements of a specific problem domain. A problem domain refers to the business problem or function being planned, analyzed, designed, and ultimately implemented as an automated information system. 3. Systems design - designing an appropriate solution for the problem domain based on the documented requirements from systems analysis; a variation on this is an approach in which commercially available systems are evaluated for suitability to meet the requirements and one is selected. 4. Systems implementation - constructing, testing and installing the information system and having the users use the information system. 5. Systems evolution - maintaining and enhancing an information system so that it continues to meet the needs of the business. Think back to a computer-programming course that you have taken. In that course you probably had the opportunity to create and test one or more computer programs. Your instructor probably gave you a few pages of paper describing a particular problem domain and what your completed software was expected to accomplish. Your main task was to create the software to do it. To put this example in the context of systems analysis and design, your instructor completed the planning and systems analysis portion of your assignment. He or she gave you the results of the planning and analysis in the form of a few pages of paper describing the problem domain and your program (software) requirements. The systems design was your responsibility to complete. You did so by thinking about the requirements, designing your solution and finally coding and testing the program to generate results in keeping with the instructor provided requirements. Implementation was probably ignored in this project because it was strictly a laboratory learning assignment for you and not a real project for a business. Therefore systems analysis and design as a concept consisting of planning, systems analysis, systems design and systems implementation is a process that includes all activities performed to produce an automated information system. The details of these activities will be described later, but first let's discuss systems, information systems, and automated information systems. WHAT IS A SYSTEM? A system is a set of interrelated components, working together for a common purpose. There are two types of systems: natural and fabricated. Natural systems include the human body, the solar system, and the earth's ecological systems. Fabricated systems are created by people to satisfy some purpose that we have. Philosophically speaking, fabricated systems should serve you, not the other way around. For example, an automobile can be thought of as a fabricated system, so can a bicycle, a telephone, and any other manufactured item. Our federal, state, and local governments are fabricated systems as well as public and private schools and churches and synagogues. Even businesses such as AT&T, IBM, General Motors, the US Government's Internal Revenue Service (IRS), San Diego Chargers, and your local supermarket, frozen yogurt, pizza, and video stores can be thought of as systems. The term "business" will be used throughout this book as a generic term meaning a for-profit or non-profit company, governmental agency, organization, or any other similar entity. Fabricated systems are all around us. Unless we hike deep into the wilderness without our cellular phones and other electronic gadgets, we can hardly avoid them. We create, expand, split, praise, criticize, and "beat" systems. Some of the best-fabricated systems are the ones in which we are hardly aware that they are working for us. Televisions, VCRs, CD players, and stereos tend to be examples of ones that are taken for granted, mostly because they perform well. It's only when some part of the system fails or you want to use some lesser known feature of the system that extra attention is paid to these systems. As Figure 1.1a shows, a generic systems model consists of six components—inputs, processes, outputs, controls, feedback, and boundary. Using predetermined controls, a system accepts inputs at its boundary, processes them into outputs, and provides a feedback mechanism for taking any necessary corrective action. Your bicycle, having been designed to only allow the pedals to turn in one direction to give it forward motion (control), accepts the forward motion of the pedals (input) primarily from your legs and feet, and propels (process) the bicycle forward (output). By observing various road conditions (e.g. hills, potholes, traffic signals, stop signs, water, oil slicks, and so on) that translate into feedback mechanisms on your part, you control the bicycle's speed and balance to deal with them. The last component, boundary, is the perimeter or border of the system. The boundary can also be thought of as the scope of the system, in other words, what elements, features, options, and so on will be included in the system. By definition then, everything else is excluded from the system. A bicycle or any other manufactured item is designed to include certain parts, all others being outside the boundary of the bicycle or other item. As Figure 1.1b shows, virtually all systems are part of a larger system, called a suprasystem from the systems vantage point. An airplane, boat, automobile, and bicycle are all systems in their own right, and each belongs to the larger suprasystem called transportation system. Likewise, virtually all systems can be decomposed into smaller systems, called subsystems from the vantage point of the system in question. So, an airplane system consists of a wing subsystem, wheel subsystem, fuselage subsystem, electrical wiring subsystem, engine subsystem, fuel subsystem, and so on. Is a personal laser printer a suprasystem, system, or subsystem? Arguably, it could be any of these depending on your perspective. You could look at the printer and say, "the printer is a system, its component parts are its subsystems, and it is part of my personal computer suprasystem", or you could say "the printer is a subsystem in my personal computer system", or finally you could say, "the printer is a suprasystem, its paper, trays, toner cartridge, power cord, and so on are its systems". WHAT IS AN INFORMATION SYSTEM? An information system is a type of fabricated system that is used by one or more persons to help accomplish a task or assignment. Information systems come in all shapes and sizes and are limited only by human imagination. For example, you may have an address book that lists the names, addresses and telephone numbers of your friends and relatives. When you want to call one of them you refer to your book to get the phone number. If you desire to send your rich aunt a get-well card (of course you are sincere about this!), you look up her address in your book when addressing the envelope. On a much larger scale, the major airline companies have massive information systems to handle passenger reservations and baggage. Information systems are established to support policies and/or procedures. This can be done in virtually limitless ways; for example, you may have a mental policy stating that you will maintain an address book. You also have a procedure, probably in your head, of how to maintain the address book so that the names, addresses, and phone numbers are current. Your best friend may also have this same policy but with a different procedure for keeping it current. In addition to having the six general system components, an information system has three additional components—people, procedures, and data—shown in Figure 1.2. People interface in some way with a system. Sometimes we provide the input, sometimes we do the processing, sometimes we do the output, sometimes we do the controlling, and sometimes we provide the feedback. The way we are supposed to interface with the information system is often documented in the form of procedures, and our interaction usually results in providing data to the system. When one of your relatives changes his or her address, you have a procedure (undocumented no doubt) for providing new data to replace the obsolete data in your address book. Using a voting information system as another example, when we vote, we interact as people, according to the established voting procedures, and we provide our voting data to the voting system. As the amount of time to maintain an information system increases or the number of people needed to maintain it increases, it becomes economically justifiable to invest in an automated information system to accomplish the task. For example, many people who write personal checks have purchased personal money manager software to help them with the task of paying their bills by check and balancing their checkbook. Most people can do these tasks manually, but a personal money manager information system may reduce the time and effort to do the same thing. In addition, paying bills may actually be viewed as a more enjoyable task with the use of a personal money manager information system. WHAT IS AN AUTOMATED INFORMATION SYSTEM? An automated information system is an information system that incorporates the use of computer hardware and software as part of the system. Therefore, an automated information system adds two additional components, as in Figure 1.3, to the three associated with an information system. For example, a business may wish to send birthday cards to each of its employees just prior to their birthdays. This information system of course could be done manually with cards, envelopes, pen and a handwritten roster of employee names, addresses and date of birth. But what if the business is AT&T and employs thousands of employees? Sending birthday cards could get expensive as well as take significant time for someone using a handwritten roster of employees. The more reasonable way to accomplish this birthday card task would be to have software read through a computerized database roster of employees and generate envelope address labels for those employees whose birthdays are approaching. A more elaborate automated information system might even create a customized birthday card for each employee or even send the birthday greeting to the employee through electronic mail. Both large and small businesses have multiple information systems within them. For example, Blockbuster Video Stores probably has an automated payroll system, video rental/sale system, video purchasing system, as well as others. A small, independent video store a few blocks from your home may also have these same type of systems even though its systems may be manual. A manufacturing business with a few dozen employees has roughly the same information system needs as does a manufacturing business with thousands of employees. The difference is primarily the amount of data managed by these information systems. From this point forward this book will be dealing with automated information systems. For simplicity, I will omit the word automated and refer to all automated information systems merely as information systems. This choice was made based on simplicity as well as my belief that the vast majority of systems analysis and design focuses on automated information systems, rendering the word automated unnecessary or implied. WHAT ARE THE BASIC CHARACTERISTICS OF AN INFORMATION SYSTEM? The basic characteristics that exist within an information system are data, functions, and behavior, as illustrated in Figure 1.4. Information systems do not necessarily have to have all three characteristics but most do. Data are either 1) input via some data entry device such as a keyboard, scanner, or mouse, 2) already in the system and stored on a storage device such as a magnetic disk or diskette, or 3) displayed or printed on an output medium, such as a display screen, paper, or microfilm. As part of the information system, data that are input and data that are stored are transformed or processed into meaningful output data called information. For example, in a payroll information system, the hours that employees work in a pay period and the hourly wage they are paid are important pieces of data for computing an employee's payroll check. The hours worked are data that needs to be input each pay period, while the employee's hourly wage is stored data since it only changes when the employee gets a raise. The hours worked and the hourly wages are transformed by the payroll system into a paycheck and other meaningful payroll reports. Using another example, a simple multiplication can be a transformation of data into information, for example three (data) times two (data) is transformed into six (information). A function is a transformation or action taken by the information system. Information systems usually have many functions. Functions carry out and enforce business policies, rules, and procedures. Other synonyms for function are process, service, and method, the last two becoming more familiar with the popularization of object-oriented technologies. Examples of functions are printing a report, printing a paycheck, displaying the customer's account dollar balance, and dispensing cash from an ATM. In information systems, behavior is the observable effects of a request. Behavior is present in all systems; however, it is more pronounced or accentuated in systems that have a human interface component (systems that respond to keyboard data entry, commands or mouse clicks, such as word processors, spreadsheets, e-mail, and other systems). In addition, a furnace motor turning on or off in response to a thermometer reaching a certain temperature, a bottle filling device responding to messages like "fill bottle" and "full bottle", and an elevator responding to signals that its information system receives as it passes by actuators on the way up or down the elevator shaft are all examples of behavior in systems that have minimal human interaction. Different types of information systems may emphasize one or more of these three characteristics over the others. In typical business information systems the primary emphasis is usually on the data component with secondary emphasis placed on the functional aspect, followed by the behavioral. Why is this? Because in most business information systems, such as accounts payable and receivable, purchasing, manufacturing bill of materials, material requirements planning, payroll, and order entry, the data are the primary component. In elevator information systems the primary emphasis may be on the behavioral component, while realizing that it must also give attention to the functional and data component. Historically, business information systems were developed primarily from a functional perspective while being aware that these systems also had a strong data component. Since the mid-1970s and the introduction of database management systems and relational database technology, the functional perspective for developing business information systems has often been relegated to a lesser position in favor of a data perspective. However, the need to give primary consideration to the functional component may still be present in some types of information systems, and some businesses, no doubt, still prefer to practice using a functional perspective instead of a data or behavioral perspective. With the strong acceptance of the windowing graphical user interface made popular by Apple’s Macintosh computer in the 1980s followed by Microsoft's Windows for most other PC’s in the 1990s, behavior has become a dominant aspect of desktop business information systems. The iconic metaphor for user interaction has taken the human interface component of information systems to a new and improved level. WHAT IS SYSTEMS ANALYSIS AND DESIGN? Systems analysis and design is about developing software, but it is more about developing a complete automated information system which includes hardware, software, people, procedures, and data as shown in Figure 1.3. These five components exist in virtually all automated information systems although the amount of each will vary with respect to the specific system being developed. All of these components must be considered and addressed during systems analysis and design. If any one of them is slighted or overlooked, the system will more than likely not be successful. When you buy software at a retail store or the campus bookstore you are buying more than the software. For example, you expect the software to work with certain hardware, have its own set of procedures for using it, work with the data you want to give it, and interact with you; hence the five components have been considered. The culmination of the systems analysis and design process is to produce an acceptable automated information system for use in one or more of the following ways: 1) software to be used within the business that it was developed for (e.g., a payroll system developed by XYZ Corporation for its own internal use to produce paychecks for its employees), 2) software for sale via retail stores, mail order catalogs, or direct from the company that created it, or 3) software to be used within products produced by a business (e.g., an automated teller machine sold by IBM). In all three of these scenarios the other four components of an automated information system—hardware, data, procedures and people—have been analyzed and designed to work with the software. WHAT MAKES SYSTEMS ANALYSIS AND DESIGN SUCH A DIFFICULT HUMAN ENDEAVOR? Many times people have said that systems analysis and design activities are perhaps some of the most complex and involved activities ever conceived by and for humans. One significant study of information systems analysis by Vitalari and Dickson cited six reasons that contribute to the support of this belief, and each is discussed here. 1. Analysis problems, at their inception, have ill-defined boundaries and structure, and have a sufficient degree of uncertainty about the nature of the solution. What systems analysts constantly find at the start of systems development projects is that the user (remember, often the user can be many hundreds or thousands of people) is not certain of what he wants (ill-defined boundaries and structure), and this contributes to the uncertainty about the potential solution to the problem. You may be asking, "How can people (users) not know what they want out of an information system?" Consider the analogy of many first-year college students being uncertain of their major field of study as they begin taking their general education courses. 2. The solutions systems analysts come up with to solve the problems are artificial, and since they are designed by humans with different backgrounds, experiences, biases, and so on, there exists an endless variety of potential solutions. What this could translate to mean is that there is no single correct solution to a problem. Any number of solutions could possibly address the problem in a satisfactory manner. The difficulty often is the fact that most system solutions are compromises - a “satisficing” solution rather than the optimal solution. Why is this? The answer is because of the diversity of needs that the user community may have for the impending information system. One user wants it to do something one-way and another user wants it to do it a completely different way. So compromise needs to be reached in order to avoid win-lose situations with the users. 3. Analysis problems are dynamic. No business is standing still. A business is continually growing in one or more ways, shrinking in one or more ways, or growing in some ways and shrinking in others. In fact, the one thing that is constant about a business is change. Two common examples of this are the fast-food industry menu changes to stay abreast of consumer preferences and its competition, and the frequent shuffling of videos around the shelves in video stores to accommodate new arrivals, fast moving, and slow moving videos. As a result of this constant change, information system requirements and needs are like a moving target. The longer it takes to plan, analyze, design, program, test, and implement an information system, the greater the chances that it will not meet the business's needs simply due to the dynamics of change. A project scheduled to take five years to develop will either not meet the business's needs when implemented or will be in a constant state of change throughout its five year development cycle in order to keep up with the changes that will be occurring within the business during that same time. An information system developed in six to nine months will probably have a greater chance of meeting the business's needs, which may have not changed too much in this shorter time period. 4. The solutions to analysis problems require interdisciplinary knowledge and skills, hence the need for a team approach to information systems development. Today there is a strong emphasis on the partnership concept between the user community and the information systems developers. 5. The knowledge base of the systems analyst is continually evolving. As the apprentice systems analyst progresses through the junior, associate and senior systems analyst ranks over time, he or she continues to learn more about business problem domains as well as improving his or her analytical skills and software development tool and technique skills. 6. The process of analysis is primarily a cognitive activity in that we are asked to, 1) put structure to an abstract problem domain, 2) process diverse information from a variety of users, and 3) develop a logical and consistent specification that will lead to the creation of a successful information system. With these thoughts in mind, it is no wonder that the men and women in the systems analysis and design profession consider systems analysis and design to be very difficult activities to perform successfully. One additional factor that was not explicitly cited in the above study, which many believe contributes to the complexity of the analysis and design activities, is that of working with people. Why is working with people so difficult? Information systems involve people and, whenever people are involved in an activity, difficulties can arise due to the myriad number of human behavior and communication issues that people bring with them into the project. Oh, they don't carry these issues in a bag slung over their shoulder. On the contrary, these issues are buried deep into the makeup and experiences of each human being. Many information systems academics recommend to their students that they study human and organizational behavior as a compliment to systems analysis and design. The information learned in human and organizational behavior courses can go a long way to contributing to a more successful information systems development project and career. STAKEHOLDERS OF AN INFORMATION SYSTEM In a typical business, the systems analyst may need to interact with individuals who have different roles within that business, shown in Figure 1.5. The greater the number of interactions with individuals who have different roles calls for more experienced systems analysts. In situations where the systems analyst needs to be involved in many different human interactions, he or she may be functioning as a project manager. What is a stakeholder? A stakeholder is a business unit, individual, or group of individuals that affects or is affected by an information system. Be careful not to extrapolate from this definition that everyone in the known universe is a stakeholder of every system. Most of the time business units, individuals, or groups of individuals are considered stakeholders if they are directly affected by a system. For example, employees are stakeholders of a payroll system because they receive payroll checks from the system. The stockholders of this company are not stakeholders of the payroll system even though stock values may be affected by payroll. Often the majority of the stakeholders are the users of the information system, but they need not be. For example, a manager may be a stakeholder because she affects or is affected by the system but is not an actual user of the system. Who are the users of an information system? To answer this question, each system must be independently considered based on its requirements. Users can be almost anyone. For example, you are the potential user of a student registration system, an automated teller machine, and a bank credit card system such as VISA or MasterCard. The astronauts in a space shuttle as well as the crew in the ground control rooms are users of a number of information systems during a space flight. Referring to Figure 1.5, a steering committee is usually composed of cross-functional, senior managers within a business, such as vice presidents or directors. Included in this committee should be the senior information systems manager or a designate. The main role of this group is to conduct high-level reviews and evaluations of proposed information systems development projects and make recommendations for prioritization and resources for the projects. Finally, vendors are those businesses which support the information systems development effort, such as consultants, hardware and software companies, training companies, telecommunications companies, documentation companies, and so on. SYSTEMS ANALYSIS AND DESIGN AS A CAREER. Systems analyst is the title usually given to someone who chooses a career in systems analysis and design. Other synonymous titles can be found, such as software engineer, systems analyst/programmer, information systems engineer, and systems engineer. Systems analysis and design is a fascinating career choice for several reasons. First, you rarely, if ever, develop the same software or information system twice, which means that systems analysts are constantly being challenged to grow professionally, and rarely, if ever, are they bored with this discipline. Second, systems analysis and design is constantly changing and evolving, which points to a high degree of excitement for the men and women involved in this profession. Third, the systems analyst's learning and professional growth are never ending. Finally, organizational competitiveness and success often are dependent on the information systems that systems analysts help create, giving them a sense of significance and contribution to the business. Even if you don't intend to make systems analysis and design a career choice, its study and understanding will be very useful to you as you pursue other careers, since most careers involve the use of computers and the software that makes them do what they do. More than likely you will be called upon to be a part of a systems analysis and design project sometime during your career, and having some appreciation of its process will allow you to contribute more effectively and hopefully be more understanding of the difficulties involved in developing quality software and information systems. WHAT DOES A SYSTEMS ANALYST DO? A systems analyst studies the problems and needs of a business in order to ascertain how hardware, software, people, procedures, and data can best accomplish improvements for the business. Improvements translate primarily into one or more of three areas: (1) increasing the revenue and/or profits of the business, (2) decreasing the costs of the business, and (3) increasing the quality of the service(s) of the business. A systems analyst should keep these objectives in mind when working on information systems projects because these are the material ways that the systems analyst can make a valuable contribution to the business. If the work of systems analysts stops contributing to one of these three objectives, then it is possible that the business may no longer need their services. WHAT IS A SYSTEMS ANALYST RESPONSIBLE FOR? A systems analyst is responsible for determining the most effective and efficient (1) capture of input data from the myriad of potential sources, (2) processing and storage of the data, and (3) delivery of timely and accurate information to the user or other information systems. As technology evolves, it is clearly the responsibility of systems analysts to investigate and determine the most effective and efficient method for capturing input data from its source. For example, most major retail stores and supermarkets have moved from a cashier keying in the prices of each item purchased to a laser scanner device that they simply point at the product's bar code or move the product across or in front of the scanning device. Student course registration at some universities have migrated from walking through a long line and pulling punch cards out of a box of cards for each class they want to students calling on the telephone at appointed times to sign up for a class using the keys on the telephone and getting immediate confirmation or denial of a seat in the class. The processing and storage of data and delivery of timely and accurate information are continually investigated due to advances in technology. Businesses have migrated from information systems that were primarily run on the computer overnight (batch systems) to systems that the user directly interact with via a keyboard, mouse, scanner, and so on during their normal workday (on-line systems) and receive visual display of results or paper-based printouts on demand. Systems analysts and other technology professionals hoping to improve one of the three objectives discussed earlier handled these changes. SYSTEMS ANALYSIS AND DESIGN SKILLS AND ACTIVITIES. By now, you might be thinking, "What kind of skills are required to be a competent systems analyst?" Well, there are several systems analysis and design skills, depicted in Figure 1.6, required to consistently and successfully perform the role of a systems analyst. Problem solving ability and people skills are at the core of the skills and competencies of an aspiring or seasoned systems analyst. You may be thinking, "I don't like to solve problems. In fact, I don't even like problems." That's okay. That's a normal human tendency. Perhaps it's just the word problem that is bothering you. A different word set, such as situation-solving skill or condition-solving skill may be more palatable to you. These word sets may actually be more representative of systems analysis and design work; nonetheless, most people refer to this as problem solving skills. People skills refer to your ability to successfully work with diverse groups of people, such as those shown in Figure 1.5. Chances are, depending on your work experience, you have worked with diverse groups of people in some capacity. Did you mostly enjoy your interactions with them? The next skill and competency layer, working outward, is a familiarity and understanding of systems analysis and design concepts and principles. These first two inner layers form the basis for the core competencies for a well-rounded understanding of the process of analyzing and designing automated information systems. Concepts and principles are general and abstract statements that describe desirable properties of software development processes and the resulting software. By themselves, concepts and principles are not sufficient to drive information systems development. An example of concepts and principles is the notion that the information system being developed is for the user and the user is most often the owner of the system. This may seem quite basic yet you would be surprised to find out that some systems professionals view the systems that they help develop as their own rather than belonging to the users. There are many other concepts and principles, some of which are scattered throughout this book. Looking at the layers in Figure 1.6, the innermost layers generally change more slowly over time than do the outer-most layers. In fact, some of the concepts and principles of systems analysis and design that were taught in undergraduate curricula in the late 1960s still apply today. Methods and techniques operationalize concepts and principles. Systems analysts and programmers must learn the details of the prevailing methods and techniques in order to incorporate concept and principle properties into their information systems development process and the resulting products. Methods and techniques are sufficiently detailed, much like a cookbook full of recipes, to allow a certain amount of consistency for using the method or technique across a spectrum of systems analysts and programmers. There are methods and techniques for conducting user interviews, conducting surveys, doing feasibility studies, diagramming and documenting requirements, diagramming software, testing software, and so on. Other techniques include flow charts, data flow diagrams, entity-relationship diagrams, and HIPO charts to name a few. Since the mid-1980s, many of the techniques used in systems analysis and design have been automated. For example, drawing a data flow diagram can be done by hand, but is most often drawn with the assistance of data flow diagramming software, which is discussed later. Methods and techniques evolve more rapidly over time than do the concepts and principles and are often synonymous with the automated tools that support them. Packaging methods and techniques together form a methodology. The purpose of a methodology is to promote a certain problem-solving strategy by pre-selecting the methods and techniques to be used. Some methodologies can fill a bookshelf or two, similar to an encyclopedia. Some methodology examples are structured analysis, structured design, structured programming, object-oriented analysis, object-oriented design, object-oriented programming, and information engineering. Methodologies also evolve over time, a little slower perhaps than do methods and techniques. For example, during the 1960s traditional (informal) systems analysis and design was the dominant methodology; in the mid-1970s structured analysis and design methodologies became dominant; in the 1980s information engineering arose; today we are in another prolonged transition to object-oriented analysis, design, and programming methodologies. Keep in mind, however, that businesses will more than likely continue to use more than one of these methodologies for different projects due primarily to expertise in using the methodology as well as the strengths and weaknesses of the methodology when compared to another for a specific information systems project. Environments and tools are available to support the application of methods, techniques, and methodologies. Tool examples include automated flow charts, data flow diagrams, entity-relationship diagrams, HIPO charts, and so on. Remember that these tools deliver automated support for the techniques they support. Environments are often labeled as being one of computer-aided software engineering (CASE), integrated/software development environments (IDE or SDE), or integrated project/program support environments (IPSE). As you might expect, environments and tools evolve or change more rapidly than do the methodologies, methods and techniques, and the concepts and principles. Most of the initial use of techniques was done manually using pencil, paper, and an appropriate notation template for sketching out the tool's symbols. Since the mid-1980s a large number of automated technique support tools have become commercially available. In other words, personal computer graphical software is available that allows us to draw the technique symbol notations as well as apply some or all of the rules, guidelines or heuristics of the technique. This class of software is commonly referred to as CASE, IDE or SDE. Empirical studies, professional trade journal articles and discussions with information systems managers have suggested a few additional and complimentary skills necessary for a competent systems analyst. These include (1) general knowledge in the functional areas of business, such as accounting, marketing, finance, personnel, manufacturing, engineering, and so on, (2) verbal and written communication skills, and (3) work experience in systems analysis and design. GENERAL MODEL OF SYSTEMS ANALYSIS AND DESIGN Figure 1.7 is a general model of systems analysis and design (including implementation). Remember, systems analysis and design is a process consisting of many necessary activities in order to produce a successful information system. The general model identifies three major items: activities (analysis, design and implementation), people involved in the activities (user, information technology staff), and inputs and outputs (all of the things on the arrows). The inputs and outputs are numbered in this figure in order to give you a visual queue for the standard sequence of events. A "talk-through" this "partnership" general model would go something like this: A stakeholder(s) (user) has a problem or situation that he or she believes can be solved or addressed with the help of an information system. With the assistance of the information technology staff during the analysis activities, the user communicates the essence of the problem in written and verbal form. As the analysis activities progress, the information technology staff utilizes systems analysis problem definition skills to document the user’s requirements and produce a requirements specification document of these requirements. The requirements specification document is often equated to architectural drawings used in the construction industry because it represents "what" the system should do when developed just as the architectural drawings represent "what" a building or home should look like. The requirements specification becomes input to the design activities along with continued user involvement and information technology staff problem-solution skills. During design, the information technology staff develops detailed blueprints for the information system, similar to the detailed blueprints used in the construction industry and used by the construction site supervisor for detailed instructions regarding the construction of the building. Once design progresses through its activities, implementation activities begin. During implementation, software is constructed (although it may be purchased in some situations), tested, and finally implemented. The end-result of the implementation is the completed information system which is delivered to the stakeholder(s) (users) for his or her (their) use." THE DETAILED ACTIVITIES OF ANALYSIS AND DESIGN Zooming in on the two circles shown in Figure 1.7, Figure 1.8 "explodes" these two processes to reveal their detailed activities and deliverables. Activities, also referred to as tasks, are the work that is performed by systems analysts and others as part of analysis and design in order to complete the systems development process. Deliverables are the products that are produced during and at the conclusion of the systems development process. For example, drawings, documentation, training materials, requests for proposals, software, and of course the completed system are considered deliverables. Each of these activities and deliverables is briefly described here. Additional coverage of these activities and deliverables is found in subsequent chapters. Even though the discussion that follows appears to be highly linear and dogmatic, recognize that there is significant flexibility during projects to overlap, omit, and replace these activities and deliverables. I believe one final point is necessary before discussing the analysis and design activities and deliverables. You need to understand that there are a variety of ways in which the details of analysis and design could be divided up into detailed activities and deliverables. In fact, be aware that other seasoned professionals might choose to partition analysis and design somewhat differently than the way it is presented here - that's okay! Diversity of opinion usually based on years of experience may lead others to view analysis and design activities and deliverables somewhat differently than I do, and I want to recognize their views as being legitimate. Your instructor or another reference book may have a variation on what is presented here. I usually find no serious discrepancy or inconsistency in this. The software development community of professionals of which systems analysis and design is a part needs to focus on what things we have in common more than what things we disagree on. Where there is disagreement let us as professionals not allow these disagreements to keep us from moving forward with our efforts to find and communicate better ways to do systems analysis and design. Now, let’s move on with the discussion of the activities and deliverables. Refer to Figure 1.8 when necessary. Starting with the analysis circle, systems planning is an activity that seeks to identify and prioritize technologies and business applications that will yield high value to the business. A feasibility study is often done to determine the merits of developing or enhancing an information system. A feasibility study takes into consideration the technical, operational, and economic aspects of a proposed information systems project and compares them to goals, objectives and limitations as set forth by the business. The more in line a proposed project is with the business's goals, objectives and limitations, the more likely the project will be approved. Sometimes feasibility studies are bypassed during analysis simply because the information system is mandatory due to some internal or external regulation from labor unions, the government or other situation. Requirements determination is the most important and most difficult activity performed during systems analysis. It may also be the most important and most difficult activity performed during the entire systems analysis and design process. During this activity the systems analyst and the user work together to identify and document the true information systems requirements. In larger projects there are usually many systems analysts and users involved in this activity. The systems analyst is constantly questioning: "What is this information system supposed to do?" Mistakes and oversights made during this activity become prohibitively expensive when they are eventually discovered later in the project. In fact, a mistake found late in the project can cost as much as 70 times more to fix than if it were found and corrected early in the project. The output or deliverable of this activity is a requirements specification document that is analogous to architectural sketches and drawings of a home or building. User Acceptance is the informal and formal endorsement of the documented requirements by the users. User acceptance is more readily given if the users have been continuously involved in the work activities of the project that lead up to the formal acceptance point. Prototyping, an optional activity during analysis, may be useful to demonstrate the feasibility or some other aspects of the proposed information system in order to more fully understand the user's real requirements or to improve the chances of user acceptance of the proposed information system. The two primary deliverables from the analysis process are the requirements specification, mentioned earlier, and any prototype that may be developed. During the design process, several activities are performed. The physical design activity produces a physical design document, sometimes called a detailed design, for the proposed information system, which is analogous to the construction industry's detailed blueprints used to guide the construction of homes and buildings. Another, optional, prototyping activity may be useful at this time to produce another model of the proposed information system. Once physical design is completed or at least determined to be far enough along, implementation begins. This is when software construction/purchase commences. If a decision were made to purchase most of the information system from a commercial vendor, retail store, or mail order house, then the detailed design document would be less complex than if the majority of the information system is to be developed by your own information systems staff. If the decision was made to mostly construct the software then this is the activity for doing so. User documentation, both in paper and electronic form, is usually created during design. Testing usually runs parallel with software construction and continues up to the point of implementation. User training is conducted as the information system approaches its useable state. Just-in-time training is advisable so that the user will get maximum benefit from it. User acceptance again is required before implementing the new or changed system. In many systems development projects, the user acceptance at this point in the project is the final checkpoint prior to accepting the system as being ready for implementation. Recall once again that user acceptance is more readily given if the users have been continuously involved in the work activities of the project that lead up to this final and formal acceptance point. Conversion is the activity that transforms the stored data in the existing information system into the format required for use in the new or changed information system. Other activities may also be done during conversion. Conversions can be very simple or very complex. The final activity within design is implementing the system, which involves installing and getting the users to use the new or changed information system. The single deliverable from design, as depicted in the figure, is the completed information system. This deliverable includes more than just software. All documentation, models, prototypes, training aids, conversion aids, and so on may be considered as part of the completed information system. More often than not, the systems professionals retain some or all of the system development models, system documentation, prototypes and other analysis, design or implementation specific portions of the system. The reason for this is that the systems professionals will most likely be maintaining and enhancing the system over its lifetime and would prefer having these informational items for their support efforts. Two ongoing activities, documentation and project management, apply continuously throughout both analysis and design. As much as possible, the systems analyst must document what is discussed, discarded, approved, and learned during the entire systems analysis and design process. Failure to do this could result in some organizational knowledge loss when the systems analyst is no longer available as part of the business's development team. Project management is necessary for almost all projects in order to keep them on track from both a financial and schedule perspective. SYSTEMS ANALYSIS AND DESIGN PROJECTS Don't let anyone tell you differently, systems analysis and design is a highly labor intensive activity involving groups of people working together as a project team. The smallest team possible is you creating software for yourself. You are the user of the software as well as the systems analyst and programmer who creates it. So you would be playing all of the roles on this project team—user, systems analyst, and programmer. The only one you would have discussions, disagreements, and compromises with on this project team is yourself! The next smallest team possible is you creating an information system for one other person, say your roommate. He or she would be the user of the system and you would be the systems analyst and programmer. On this project team you only play the technical roles of systems analyst and programmer. Now you discuss, disagree, and compromise with the other team member who is the user of the system. Did you learn in a marketing class that the customer (user) is always right? Well, in systems analysis and design this notion is also true. The job of the systems analyst is to create an information system that will meet or exceed the user's requirements for the information system. Users come in all sizes and shapes. They also have differing levels of understanding about the process of systems analysis and design and their role in that process. Compounding this situation is the complexity of the problem that they are trying to solve with the information system that you will help create for them. Likewise, systems analysts also come in all shapes and sizes. Systems analysts have varying amounts of experience with analysis and design activities as well as varying experiences with the specific problem that the user is trying to solve with the information system that will be created. This combination of user and systems analyst characteristics makes for very different project teams each and every time one is formed. Most information systems are developed in projects that consist of more than two team members. This makes the communication between team members even more important and more difficult to coordinate than what was discussed previously. Project teams of ten, twenty, fifty, one hundred, and more are quite common in "industrial strength" systems analysis and design projects. Some of these members are managers and users, some are systems analysts, some programmers, and others are support staff. More often than not, users have a difficult time articulating their real and full requirements of the problem to the systems analyst, not because they are incompetent or inarticulate, but because the problem being solved is not straightforward. For example, try listing all the necessary mental and physical tasks, in correct order, that you would go through to successfully walk yourself across a busy traffic light controlled intersection in your city. When this task has been done as a class exercise, the students identify as few as five steps up to a maximum of about fifty steps. Quite a wide variation in "user requirements"! Another task that is easy to do but difficult to describe is tying your shoes. Try writing down the steps involved to do this. You are no doubt an expert at shoe tying, but trying to accurately articulate how you do it in writing will be very difficult. Have you ever tried to write down how you would apply cosmetics or tie a necktie? The same is true for users trying to tell you exactly how their job is performed or needed to be performed. They usually know their job very well and are competent at it but still have a difficult time telling someone how it is done. WHERE DO INFORMATION SYSTEMS ANALYSIS AND DESIGN PROJECTS COME FROM? New or changed information systems development projects come from problems, opportunities, and directives and are always subject to one or more constraints. Most maintenance of existing information systems projects come from users discovering real problems with existing information systems. Problems, often called bugs, can arise at any time during the life of an information system. There is no such thing as a problem-free or bug-free information system. What exist are information systems that are waiting for the next problem or bug to arise. As soon as a problem/bug is suspected, a project to find and correct the problem should be initiated. Opportunities are the most preferred way to kickoff an information systems development project. This means that the business is hoping to create a system that will help it with increasing its revenue, profit, or services, or decreasing its costs. American Airlines capitalized in a very big way many years ago when it created its SABRE on-line airline reservation system, years ahead of its competition. In the past an on-line reservation system was an option or luxury. Today an airline reservation system is a basic business requirement just to be in the passenger airline business. Southwest Airlines, one of the most profitable U.S. airlines in the 1990s, has a much simpler on-line reservation system than does American Airlines. Their reservation system does not include the option of advance seat selection. Directives are mandates that come from either an internal or an external source of the business. For example, the chief operating officer or president of a company (internal source) may issue a directive saying that the company will need to automate an information system during the next calendar year. A labor union (external source) may require certain reporting requirements for companies that have employees that are members of that labor union. The federal government (external source) may require that companies produce certain reports for equal employment opportunity statistics. In these situations the company has to comply or be penalized in some way. Constraints are limitations and compromises that come with the soon to be developed information system. A video store rental system may only work on Intel Pentium type computers; the word processing software you use may only work with Windows; the company's payroll system cannot produce an individual paycheck greater than $10,000, and so forth. Constraints and compromises are present in every information system and often exist in order to allow the system to be completed and implemented in a timely manner. For example, if a software development company, such as Microsoft, waited for its word processing software package to simultaneously run on Windows, Unix, Linux, Mac, OS/2, VM, CMS, and other platforms before releasing it, it would take several additional years. Limiting it to one specific operating system, such as Windows, would allow that version of the word processing software to be released much sooner. Versions for the other operating systems could follow after additional time has lapsed. INFORMATION SYSTEMS REQUIREMENTS SPECIFICATION If you were going to go on a two-week vacation, would you plan ahead of time for several aspects about your vacation, such as where you will go, where you will stay, what you will do and see? Or would you just jump in your car on the first day of the vacation and start driving? This latter question seems more like running away from home than going on a vacation! Hopefully, you would do some planning, scheduling, and documenting of your vacation plans prior to the start of your vacation. The same would apply if you decided to do a room addition to your home or build a swimming pool in your backyard. The city you live in would more than likely require drawings and blueprints of the anticipated additions prior to the actual work being done. Likewise, information systems of any consequence are usually preceded by a systems analyst documenting in writing with words, drawings and possibly pictures exactly what the information systems requirements are. Documenting exactly what the change will be should even come before making changes to enhance existing information systems. An article in Fortune magazine suggested that an IBM checkout scanner has 90,000 lines of code in it, a Citibank automated teller machine has 780,000 lines of code in it. Another report indicated that a space shuttle has 500,000 lines of code in it, and the ground support systems have 1.7 million lines of software code in them. It would be virtually impossible to create the software for a successful space shuttle flight without first documenting what the software is supposed to do. The document that contains the words, drawings, and pictures is often called the User Requirements Specification document. It becomes the blueprint for the information system waiting to be built or modified. Historically, information systems development has been plagued with three significant user criticisms: (1) development takes too long, (2) development costs too much, and (3) the information systems that are developed do not truly meet the business's objectives for the system. These items are still a constant source of tension for systems developers, but there is a significant movement to integrate the user as a strong participant in the development project. Keep in mind that the use of the word "user" often refers to more than one person. Therefore, a partnership is established for the development project between the user and the developers. In some situations, the user is actually the project leader which places a significant amount of project responsibility for overcoming the above three items directly on the user. With this type of project arrangement, should a system fail on any of the above three items (or others), the user is mostly responsible rather than the information systems development staff. INFORMATION SYSTEMS LIFE CYCLE AND INFORMATION SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC). Similar to plants, animals, and humans, information systems have a life cycle of their very own. A typical human life cycle starts when a man and a woman plan to have a baby. The couple implements the plan which leads to pregnancy, baby delivery, development from baby to child, teenager, young adult, adult, golden years, and death. Information systems have a similar life cycle in that they are planned for, then developed using an information systems engineering strategy, implemented for use, evolve as the needs of the business change, and replaced with some other information system at the end of their usefulness to the business. The information systems development life cycle (SDLC) is the process by which an information system comes to life and maintains its usefulness to a business as it moves from inception to replacement. The SDLC is a much-discussed topic among practitioners and researchers because there is so much variability in what it represents. What does this mean? Well, how many different "ways" can you think of for getting from Los Angeles, California to Boston, Massachusetts? You could fly, drive, take a bus or train. Within each of these transportation modes, there are several routing choices to get you from Los Angeles to Boston. The same holds true for the SDLC. We know where we are starting from and where we want to end up, but the process (routing) can be an infinite number of activities, choices, and decisions. Systems analysis and design textbooks have historically listed as few as five SDLC activities and a maximum of about 12 SDLC activities necessary for a complete SDLC process. A close examination of these life cycles reveals that all necessary activities are covered in one way or another regardless of the actual number of activities identified in the text. So, for our purposes the SDLC consists of nine activities as listed below: 1. Systems Planning - planning for an information system 2. Feasibility Study (optional) 3. Requirements Determination 4. Conceptual design 5. Physical design, prototyping (optional), construction and testing, or purchase, testing, and integration 6. Conversion from current system to new/changed system 7. Training 8. Implementation 9. Evolution for enhancements and maintenance - this activity actually could involve doing activities 1-8 over and over again. These same analysis and design textbooks have long presented the above or similar SDLC activities in pictorial form, but each has done so by presenting them in a variety ways, some of which are shown in Figure 1.9. Recognizing that there are professional differences of opinion on the visual presentation and the interpretation of how to carry out each of the SDLC activities, we simply list the activities here for your consideration. In looking for some common ground, many practitioners agree that the SDLC process moves through its activities in mostly a sequential manner while allowing for significant overlap of activities. In addition, inclusion or exclusion of one or more of these activities is allowed as a particular project dictates. Finally, revisiting or looping back to a particular activity as the need arises is also supported and advocated. Perhaps the worst thing that could happen relative to the application of the SDLC is to have a project manager treat it as if its strict adherence must be followed no matter what the cost or consequences to the project. PRINCIPLES TO GUIDE INFORMATION SYSTEMS ANALYSIS AND DESIGN Over the last three decades a number of systems analysis and design principles have been presented. Although not exhaustive, the list includes: 1. The system is for the user (it is not ours; we do not own the system just because we developed it) 2. A work breakdown structure such as a SDLC should be established for all information systems development projects 3. Information systems development is NOT a sequential process; it allows for activity overlap, revisiting, inclusion/exclusion, and so on. 4. Information systems are capital investments for the business 5.Tthe project manager should not be afraid to cancel a project if its success is seriously challenged 6. Documentation (manual and/or electronic) is a deliverable product during each activity of the SDLC 7. Senior management support for the development project SUMMARY This chapter has presented a number of introductory topics in order to set the framework for the remainder of this book. A system, an information system, and an automated information system have been defined and discussed along with the basic components of an automated information system. The three basic characteristics of an automated information system are data, functions, and behavior. The term systems analysis and design has many synonyms. An assertion was made that the systems analysis and design process is a difficult human endeavor. Systems analyst skills, activities, and career opportunities were presented along with a general model of information systems development activities and deliverables. Information systems requirements specifications were discussed followed by discussion of information systems life cycles and the information systems development life cycle. Finally, a discussion and a list of some of the common principles that are used to guide systems analysis and design were presented. CHAPTER QUESTIONS: 1.1 With what other terminology is systems analysis and design synonymous? 1.2 What activities and deliverables are included in analysis? 1.3 What activities and deliverables are included in design and implementation? 1.4 Describe a system and the components of a systems model. 1.5 What two key components distinguish an information system from an automated information system? 1.6 How is data incorporated into an automated information system and what role does it play? 1.7 How do the components of an information system relate and what is the purpose of each component? 1.8 Name and describe each of the basic characteristics of an automated information system? 1.9 What are some of the problems associated with systems analysis and design? 1.10 What sociological and psychological factors play a role in systems analysis and design? 1.11 Who is affected most by an information system? 1.12 Given the previous question, explain how a systems analyst is more than just a programmer. 1.13 Briefly describe the components of the General Model of systems analysis and design. 1.14 What are the activities involved in systems analysis and design? 1.15 What is the most critical element to keep in mind when developing an information system? Why? 1.16 How does your answer to the previous question affect a standardized application of a particular information system to all problems of a similar nature? 1.17 What are some of the causes that trigger new or updated information systems projects? 1.18 What is the purpose of the systems development life cycle (SDLC)? 1.19 Briefly describe the activities in an SDLC. 1.20 What are some of the guiding principles of information systems analysis and design?