General systems design principles

General systems design principles

72.1 Purpose

This chapter discusses several general system design topics that are not fully covered in other chapters, including the system life cycle, important factors that affect system design, system attributes, and system design strategies.

72.2 Strengths, weaknesses, and limitations

Where applicable, strengths and weaknesses will be discussed in context.

72.3 Inputs and related ideas

The concepts discussed in this chapter can be applied to most of the methodologies, techniques, and tools in this book. Specifically, this chapter references expert systems (Chapter 7), prototyping (Chapter 31), hardware interface design (Chapter 42), file design (Chapter 44), database design (Chapter 45), report design (Chapter 47), network design (Chapter 52 to 54), program design (Chapter 62), and real-time systems (Chapter 73).

72.4 Concepts

This chapter discusses several general system design topics that are not fully covered in other chapters, including the system life cycle, important factors that affect system design, system attributes, and system design strategies.

72.4.1 The system life cycle

The system life cycle (Figure 72.1) focuses on various stages of system usefulness. In contrast, the systemdevelopment life cycle (Chapter 1) emphases the development stages associated with a new or replacement system.

During the system birth stage, the existing system’s problems, errors, and missing features are identified and investigated, and new opportunities suggested by emerging technologies and user requests are examined and evaluated. A systems analysis is then performed, and if the outcome is positive, a new or improved system is developed. This stage encompasses the problem definition, information gathering, and systems analysis stages of the system development life cycle.

During the system development stage, the design, development, conversion, testing, and implementation stages of the system development life cycle are performed.

The growth stage corresponds with the operation and maintenance stages of the system development life cycle. During this stage, usage grows as users become familiar with the new system, and system behavior is adjusted to improve performance and efficiency.

Figure 72.1  The system life cycle.

When the system reaches the maturity stage, its efficiency can no longer be enhanced and performance deficiencies may begin to appear. At this point, such options as upgrading the system, adding new functions, and expanding existing functions must be considered.

During the death stage, the system is investigated to determine if a new system should be developed on a new platform, if a new system should be developed on the existing platform, or if the existing system should be installed on a new platform. Once the platform decision is made, the system birth phase begins for a new system.

72.4.2 Factors that affect system design

Several factors have a broad impact on systems design.

72.4.2.1 The degree of automation

The degree of automation, the extent to which automated or computer-related components are used in a system, affects the design of virtually every system component. At one extreme are manual systems that incorporate few (if any) computer-related components. (Manual systems are not a primary concern of this book). At the other extreme, fully automated systems involve few (if any) human components. Most modern information systems lie between those two extremes.

72.4.2.2 Processing techniques

Batch processing is a transaction-oriented information processing technique in which transactions are accumulated over time and the system’s status is updated at the end of a business cycle. Transaction files and master files must be designed, sequential access techniques are often employed, and such reports as transaction listings, master file content listings, exception reports, summary reports, and utility documents (such as paychecks) are typical outputs. Batch processing is still common in banking and financial applications.

On-line processing is the de facto standard in today’s business environment. Typically, a transaction is used to update the relevant master file record as soon as it is received. User-friendliness and response time are important considerations, direct (or random) access is usually employed, and query support is at least as important as report generation. Additionally, database and network design are important considerations.

A real-time system responds to events as they occur and (typically) provides immediate feedback to influence or control those events in “real” time. Real-time systems use such tools as probes, sensors, and scanners to get direct input and automatically convert the data to a format that can be processed by the computer. Interrupt handling is particularly important on real-time systems.

72.4.2.3 Management and control

A centralized management philosophy provides integrated top-down control, centralized resource allocation, and good security while minimizing incompatibility problems. The disadvantages include a lack of flexibility, limited local processing power, and localized inefficiency.

Given the pace of information technology development and the growing popularity of microcomputers and networks, a distributed management philosophy is much more common today. Consequently, such topics as networking and hardware interface design have become increasingly important.

72.4.2.4 Information system types

A transaction processing system (TPS) accepts and processes transactions in either batch or on-line mode. The data generated by a transaction processing system are stored in traditional files or databases. Higher-level information systems are constructed on the resulting data platform.

A management information system (MIS) emphasizes report generation. A decision support system (DSS) is more response-oriented and user-controlled. For example, a manager might use a DSS to download a set of data from a central database and then use a fourth-generation language or a spreadsheet program to manipulate the data to generate the information needed to support a decision. A group decision support system (GDSS) adds communication capability and interaction to a DSS. An executive information system (EIS) is designed to support high-level decision-making based (typically) on aggregate and graphic data. An expert system (ES) relies on expertise, a rule base, a control engine, and an expert system shell, and utilizes such development languages as LISP and PROLOG.

72.4.3 System attributes

A system’s scope is a sense of its size or magnitude and is often expressed as an estimate of the system’s resource implications or cost. Scope is largely a function of the degree of automation, the type of information system, and the complexity of the system.

A system’s boundaries define its limits. Boundary-related concerns include interfaces with other systems, the system’s ability to be integra-ted into a super-system, its compatibility with other systems, and any customized routines that might be needed to perform cross-system data conversions.

Common criteria for measuring and evaluating system behavior include throughput, response time, on-line query support, report frequency and timeliness, integration, flexibility, user-friendliness, execution efficiency, fault tolerance, and so on. Note that several of the criteria conflict.

72.4.4 System design strategies

The system design strategies discussed in this section can be applied to virtually any system analysis and design methodology.

72.4.4.1 Top down

Top down-design is goal driven. Basically, the modules (and/or subsystems) at the top of the hierarchy (usually, the broad, control-oriented modules) are designed first and modules at the bottom of the hierarchy (the detailed, computational modules) are designed last. Typically, the designer starts by building a hierarchical structure that defines the links between all the subsystems, modules, subroutines, and/or functions in the proposed system. All the elements at one hierarchical level are then developed before work progresses to the next lower level.

72.4.4.2 Bottom up

Bottom-up design is data driven. Work begins at the lowest level, typically with the detailed, computational modules. When all the modules at one level are completed, work progresses to the next higher level. Bottom-up development is an excellent choice for a project with massive volumes of data.

72.4.4.3 Middle out

As the term suggests, the middle-out approach starts from the middle of the hierarchy. For example, the design of a student database might start with a student file. Subsequently, lower-level files (to hold data about courses, grades, finances, etc.) and higher-level files (to hold data about student organizations, the students enrolled in a given course, athletic teams, etc.) are designed.

72.4.4.4 Evolutionary

The evolutionary (or stepwise refinement) approach is similar to the prototyping methodology described inChapter 31. The idea is to start with a small program or subsystem and continuously refine it by adding new functions and/or by modifying features.

72.4.4.5 Incremental

The incremental or sequential increment approach starts with any module, subroutine, or subsystem. A second module is then developed and those two modules are integrated before work begins on the third module. This process continues until all the modules are developed.

72.5. Key terms

Analysis —

To attack a problem by breaking it into subproblems.

Batch processing —

A processing technique in which transactions are accumulated over time and the system’s status is updated at the end of a business cycle.

Birth —

The system life cycle stage during which the existing system’s problems, errors, and missing features are identified and investigated, and new opportunities suggested by emerging technologies and user requests are examined and evaluated.

Bottom-up design —

A data-driven design strategy in which work begins at the lowest level, typically with the detailed, computational modules; when all the modules at one level are completed, work progresses to the next higher level.

Boundary —

An entity that serves to delimit or separate a system from its environment.

Centralized management —

A management philosophy based on integrated top-down control.

Data driven —

A tool or technique that starts with the data and derives the necessary processes.

Death —

The system life cycle stage during which the decision is made to replace the system.

Decision support system (DSS) —

An information system that adds response orientation and user control to a management information system.

Degree of automation —

The extent to which automated or computer-related components are used in a system.

Development —

The system life cycle stage during which the system is designed, developed, tested, and implemented.

Distributed management —

A management philosophy that distributes responsibility and authority from the top to the bottom levels of the organization.

Evolutionary design (stepwise refinement) —

A design strategy that starts with a small program or subsystem and continuously refines it by adding new functions and/or modifying features.

Executive information system (EIS) —

An information system designed to support high-level decision making based (typically) on aggregate and graphic data.

Expert system (knowledge-based system) —

A computer program that emulates the thought process of a human expert.

Goal driven —

A method or technique that works through a process until a predefined goal is accomplished.

Group decision support system (GDSS) —

An information system that adds communication capability and interaction to a decision-support system.

Growth —

The system life cycle stage during which usage grows as users become familiar with the new system, and system behavior is adjusted to improve performance and efficiency.

Incremental design —

A design strategy that starts with any module, subroutine, or subsystem; a second module is then developed and those two modules are integrated before work begins on the third module. This process continues until all the modules are developed.

Information system —

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.

Management information system (MIS) —

An information system that emphasizes report generation and combines such attributes as centralized data management, integrated applications, distributed access, and interactive processing to support operational-level decision making.

Maturity —

The system life cycle stage during which the system’s efficiency can no longer be enhanced and performance deficiencies begin to appear.

Methodology —

A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; often implemented as a set of well-defined steps or phases, each of which ends with a clear, measurable set of exit criteria.

Middle out —

A design strategy that starts from the middle of the hierarchy.

On-line processing —

A processing technique in which a transaction is used to update the relevant master file record as soon as it is received.

Real-time system —

A system that responds to events as they occur and provides immediate feedback to influence or control those events in “real” time.

Response time —

The elapsed time between a request for service and the delivery of that service.

Scope —

A sense of a problem’s (or a system’s) magnitude; often, a preliminary estimate of the problem’s resource implications or cost.

System —

A set of interrelated components that function together in a meaningful way.

System development life cycle (SDLC) —

A set of steps for solving information system problems; the basis for most systems analysis and design methodologies.

System life cycle —

A model that stresses the stages of system usefulness; the stages are birth, development, growth, maturity, and death.

Throughput —

A measure of the amount of work going through a computer or a system; often expressed as a percent utilization.

Top-down design —

A goal-driven design strategy in which the modules (and/or subsystems) at the top of the hierarchy (usually, the broad, control-oriented modules) are designed first and modules at the bottom of the hierarchy (the detailed, computational modules) are designed last.

Transaction processing system (TPS) —

An information system that accepts and processes transactions in either batch or on-line mode.

72.6 Software

Not applicable.

72.7 References

1.  Davis, G. B. and Olson M. H., Management Information Systems: Conceptual Foundations, Structure, and Development, 2nd ed., McGraw-Hill, New York, 1985.

2.  Laudon, K. C. and Laudon, J. P., Managing Information Systems: A Contemporary Perspective,2nd ed., Macmillan, New York, 1991.

3.  Rockart, J. F., Chief executives define their own data needs, Harv. Bus. Rev., XX, XX, 1979.

4.  Rockart, J. F. and Treacy, M. E., The CEO goes on line, Harv. Bus. Rev., XX, XX, 1982.

5.  Shank, M. E., Boynton, A. C., and Zmud, R. W., Critical success factor analysis as a methodology for MIS planning, MIS Q., XX, XX, 1985.

6.  Yourdon, E, Managing the System Life Cycle, 2nd edition, Prentice-Hall, Englewood Cliffs, NJ, 1988.