The Information System Consultant's Handbook

Systems Analysis and Design

William S. Davis, David C. Yen, William S. Davis, David C. Yen

• Publisher: CRC Press
• Year: 2019
• Print ISBN: 9780849370014
• eBook ISBN: 9781351835633
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Engineering
• Index: Computer Science

The Information System Consultant's Handbook familiarizes systems analysts, systems designers, and information systems consultants with underlying principles, specific documentation, and methodologies.
Corresponding to the primary stages in the systems development life cycle, the book divides into eight sections:

• Principles
  
• Information Gathering and Problem Definition
  
• Project Planning and Project Management
  
• Systems Analysis
  
• Identifying Alternatives
  
• Component Design
  
• Testing and Implementation
  
• Operation and Maintenance
  Eighty-two chapters comprise the book, and each chapter covers a single tool, technique, set of principles, or methodology. The clear, concise narrative, supplemented with numerous illustrations and diagrams, makes the material accessible for readers - effectively outlining new and unfamiliar analysis and design topics.

part one

Principles

chapter one

The systems development life cycle

William S. Davis

Contents

1.1 Purpose

1.2 Strengths, weaknesses, and limitations

1.3 Inputs and related ideas

1.4 Concepts

1.4.1 Information systems

1.4.2 The system life cycle

1.4.3 Methodologies

1.4.4 The waterfall method

1.5 Key terms

1.6 Software

1.7 References

1.1 Purpose

The purpose of a methodology is to specify a set of well-defined steps or phases, coupled with a set of clear, measurable exit criteria, for solving a complex problem (such as developing an information system). The system development life cycle (SDLC) is a set of steps that serves as the basis for most systems analysis and design methodologies.

1.2 Strengths, weaknesses, and limitations

A methodology (such as the system development life cycle) acts as a memory aid by imposing discipline, thus reducing the risk that key details will be overlooked. Communication is enhanced because the methodology imposes a consistent set of documentation standards. The steps in the methodology enhance management control, providing a framework for scheduling, budgeting, and project management. The tools associated with a good methodology make it easier to solve the problem. Finally, a good methodology increases the likelihood that significant errors are detected early.

There are dangers associated with using a methodology, however. Some people become so bogged down in the mechanics of following the steps and completing the exit criteria that they fail to solve the real problem. (There is a fine line between discipline and rigidity.) Additionally, no matter what methodology is chosen, there will be problems for which that methodology is (at best) inappropriate, and it is a mistake to try to force the application to fit the tool.

There is always a concern that the system developed may not accurately reflect the current business environment. The elapsed time between the initial proposal and system completion can be quite lengthy (often one or more years). Many methodologies require that specifications be “frozen” as work progresses from one step to the next, and user requirements do change over time. Given the fast pace of technology, this problem is particularly acute with hardware and/or software selected early in the process.

The traditional methodologies are not optimal for developing some types of information systems, such as expert systems and real-time processing systems. Additionally, fourth-generation, fifth-generation, and objected-oriented languages require modifications to the traditional approach.

Sometimes management is tempted to believe (or hope) that technology can replace technical experts. A good methodology makes a competent analyst more productive, but no methodology can convert an unskilled, untrained person into a competent analyst.

1.3 Inputs and related ideas

The system development life cycle provides a framework or structure for virtually all the tools and techniques discussed in this book.

The system development life cycle implies a phased approach, with complex tasks decomposed into smaller phases (stages, steps) that are easier to achieve, control, and manage. Many traditional methodologies, such as Martin’s information engineering (Chapter 2) and Orr’s structured requirements definition (Chapter 4), emphasize the phased approach, with clearly defined entrance and exit criteria for each individual phase. Practicing analysts often deviate from the rigidly phased approach defined by the methodology, however.

The project management life cycle is similar to the system development life cycle, with stages or phases defining a schedule and triggering resource allocations. Note, however, that a given project might encompass several related systems, and a given system might be divided into several sequential or concurrent projects.

1.4 Concepts

A system (Figure 1.1) is a set of interrelated components that function together in a meaningful way. A system is delimited from its environment (its suprasystem) by a boundary. A system accepts inputs at its boundaries. Outputs flow back across the boundaries. A process is an activity that changes the system in some way. Of particular interest are the interfaces, the points at which the various systemcomponents communicate or interact. As a general rule, the more interfaces a system contains, the more complex the system.

In addition to inputs, processes, interfaces, and outputs, the system also includes control and feedback mechanisms that together allow the system to determine if it is achieving its purpose. Feedback is the return of a portion of the system’s output to its input. If the feedback suggests a deviation from the expected value (the control), the system reacts by attempting to adjust itself.

1.4.1 Information systems

This book is concerned with the analysis and design of information systems. An information system is a set of hardware, software, data, human, and procedural components intended to provide the right data and information to the right person at the right time.

Figure 1.1 A system.

1.4.2 The system life cycle

Every system has a life cycle (Figure 1.2). An information system is “born” when a problem is recognized. After the system is developed, it grows until it reaches maturity. Eventually, a change in the nature of the problem or increasing maintenance costs degrade the value of the system, so it “dies” and a new or replacement system is born to take its place.

Figure 1.2 The system life cycle.

1.4.3 Methodologies

A methodology is a body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry. Often, a methodology is implemented as a set of well-defined steps or phases, each of which ends with a clear, measurable set of exit criteria. A key purpose of a methodology is ensuring that nothing is overlooked in the process of solving a complex problem (such as developing a complex information system).

Figure 1.3 The system development life cycle is sometimes called the waterfall method.

1.4.4 The waterfall method

The basis for most systems analysis and design methodologies is the system development life cycle or SDLC (Figure 1.3). It is sometimes called the waterfall method because the model visually suggests work cascading from step to step like a series of waterfalls. (Note: In reality, there is considerable feedback between the various steps or phases.)

The first step is problem definition. The intent is to identify the problem, determine its cause, and outline a strategy for solving it.

Given a clear problem definition, analysis begins. The objective of analysis is to determine exactly what must be done to solve the problem. Typically, the system’s logical elements (its boundaries, processes, and data) are defined during analysis.

The objective of design is to determine how the problem will be solved. During design the analyst’s focus shifts from the logical to the physical. Processes are converted to manual procedures or computer programs. Data elements are grouped to form physical data structures, screens, reports, files, and databases. The hardware components that support the programs...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Preface
• Author
• Acknowledgement
• Contributors
• Table of Contents
• Part I: Principles
• Part II: Information gathering and problem definition
• Part III: Project planning and project management
• Part IV: Systems analysis
• Part V: Identifying alternatives
• Part VI: Component design
• Part VII: Testing and implementation
• Part VIII: Operation and maintenance
• Glossary
• Trademarks
• Index