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:
- Systems planning – performing planning and initial feasibility activities to determine which information systems projects take priority over others
- 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.
- 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.
- Systems implementation – constructing, testing and installing the information system and having the users use the information system.
- 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”.