Summary

1. System design is a transition from a user-oriented document to a document oriented to programmers or data base personnel. It goes through logical and physical design with emphasis on the following:

   a. Preparing input/output specifications.

   b. Preparing security and control specifications.

   c. Specifying the implementation plan.

   d. Preparing a logical design walkthrough before implementation.

   2. Structured design is a data-flaw-based methodology that identifies in­ puts and outputs and describes the functional aspects of the system. It partitions a program into a hierarchy of modules organized in a top­ down manner with the details at the bottom.

   3. The documentation tool is the structure chart. It has three elements­ the module, the connection, and the couple. When a module is evaluated, the module's connections to other modules (coupling) and its intramodule strength (cohesion) are considered.

   4.One way of developing an input process/output chart for modules is with the HlPO chart. It consists of the hierarchy chart plus the input process/output (IPO) chart, thus capturing the essence of top-down decomposition. The aids are the HlPO work sheet and template.

   5. A useful activity in all phases of a structured project is the walkthrough where ideas are interchanged among peers. User involvement is extremely important.

   6. The major development activities during structured design are data base design, implementation planning, system test planning, system interface specifications, and user documentation. Much of the documentation is written after conversion, a task that follows design.

   7. A well-designed system should provide for controls to eliminate errors check fraud, and ensure system integrity. Audit trails, documentation and processing control must be incorporated into the system before- it is released to the end user.

Audit Trail And Documentation Control

An important function of system controls is providing for an audit trail. Anaudit trail is a routine designed to allow the analyst, user, or auditor to verify a process or an area in the new system. In a manual system, the audit includes journals, ledgers, and other documents that the auditor use trace transactions through the system. In a computerized system, re content and format frequently make it difficult to trace a transaction completely. Some reasons are the following:

   1. Records stored on a magnetic medium (tape, disk, etc.) can be read only by a computer and with the use of a computer program.

   2. Data processing activities are difficult to observe, since they take place within the computer system.

   3. The record sequence is difficult to check without the assistance of a computer system.

   4. Direct data entry eliminates the physical documentation for an audit program.

One way to overcome these constraints is to keep a file on all transactions as they occur. For example, transactions can be recorded on tape, which can be an input to an audit program. The program pulls selected transactions and makes them available for tracing their' status. The systems analyst must be familiar with basic auditing or work closely with an auditor to ensure an effective audit trail during the design phase.

The proper audit of a system also requires documentation. Documentation is the basis for the review of internal controls by internal or independent auditors. It also provides a reference for system maintenance. Preparing documentation occupies much of the analyst's time. When the implementation deadline is tight, documentation is often the first item to be ignored.

Documentation may be internal (in program documentation) or external hard-copy documentation. It must be complete and consistent for all systems prepared according to standards. So a plan to approve a new design should include documentation standards before programming and conversion.

In summary, the primary purpose of auditing is to check that controls built into the design of candidate systems ensure its integrity. Audit considerations must be incorporated at an early stage in the system development so that changes can be made in time. Neglecting this "ital step could spell trouble for system implementation.

Processing Controls And Data Validation

Several methods have been devised to control processing activities. Data records, for example, may be batched into small groups to control totals. In batch processing, if an error is detected, the batch that contains the error reviewed without disturbing the remaining batches of the file. If all con totals balance, the batch is accepted. If the batch balances but certain records are rejected, the batch may be held until the errors are correct

           In addition to batch controls, several other programmed checks can be used for testing the data:

   1. Completeness check ensures that all fields in a record are present and are read in the proper sequence. In a multiple-record check, the program verifies the self-checking number of the record(s) that make up transaction. If an error is detected, the entire group of records is rejected.

   2. Consistency check refers to the relevance of one type of data to another. For example, a retailer may have a policy of extending a 30 percent discount to religious leaders on all merchandise ordered and up $2,000 credit at no interest. An order-received rom a customer must checked against these provisions to ensure consistency with the specified policy.

  3. Reasonableness check evaluates a transaction against a standard determine whether it meets the test. For example, if the maximum w rate is $5 per hour and no overtime is allowed, an employee's wee gross pay of $210 would be unreasonable, since the limit is $200.

   4. Sequence check verifies that data records are in sequence prior processing. A check of duplicate records may also be incorporated in the routine.

Audit Considerations

A well-designed system should have controls to ensure proper operation and routine auditing. A candidate system's failure often results from a lack of emphasis on data control. Therefore, standards of accuracy, consistency, and maintainability must be specified to eliminate errors and control for fraud.

A system design introduces new control elements and changes the control procedures. New controls in the form of relational comparisons are designed to detect and check errors that arise from the use of the system. In a manual system, internal control depends on human judgment, personal care, and division of labor. In a computer-based system, the number of persons involved is considerably reduced. A software package is an effective substitute for human judgment in processing routines and error checks.

In designing a new system, the designer should specify the location error-control points and evaluate them on the basis of error frequency, cost and timing of error detection. By identifying points where potential e may occur, designers can create error control procedures for hand errors immediately at a reasonable cost.

Personnel Allocation

In the past, a medium or large project was handled by a team of programmers with the goal of speeding up implementation. Unfortunately, was more emphasis on numbers than on talent. The structured approach design and implementation is useful in facilitating the planning process. Emphasis is on· allocating the right programmers to the task within a realistic timetable.

A completed structure chart gives the designer a realistic outline of the programming work to be done. Programmers can be assigned to the workload rather than the other way around. A team of programs assigned a subsystem that is strongly cohesive and loosely coupled to other' subsystems. Once this responsibility is assigned, roles are allocated. within each team. The designer, of course, oversees the work of the teams.

What module(s) in the chart is assigned to what size team can be very important. Modules at the bottom of a structure chart are usually utility and data base access modules. This sector represents the user interface. With today’s emphasis on what the Germans call Benutzefreundlichkeit or user­ friendliness, a team with specialized skills should be assigned to the interface subsystem.

Major Development Activities

Several development activities are carried out during structured design. They are data base design, implementation planning, system test preparation, system interface specification, and user documentation .

1.Data base design. This activity deals with the design of the physical database. A key is to determine how the access paths are to be implemented. A physical path is derived from a logical path. Pointers, chains, or other mechanisms may implement it, as we discuss in Chapter.

2.  Program design. In conjunction with database design is a decision on the programming language to be used and the flowcharting, coding, and debugging procedure prior to conversion. The operating system limits the programming languages that will run on the system.

       When the system design is under way and programming begins, the plans and test cases for implementation are soon required. This means ere must be detailed schedules for system testing and training of the user staff. Planned training allows time for selling the candidate system to those ho will deal with it on a regular basis. Consequently, user would be minimized.

3. System and program test preparation. Each aspect of the system has a separate test requirement. System testing is done after all programming and testing is completed. The test cases cover every aspect of candidate system-actual operations, user interface and so on. System program test requirements become a part of design specifications-a p requisite to implementation.

4. In contrast to system testing is acceptance testing, which puts system through a procedure design to convince the user that the candidate system will meet the stated requirements. Acceptance testing is technically similar to system testing, but politically it is different. In system testing, b are found and corrected with no one watching. Acceptance testing conducted in the presence of the user, audit representatives, or the entire staff.

               Since test cases may be shared by both system testing and accept testing, system testing may be viewed as a dress rehearsal for the acceptance test. The criteria or plan for acceptance should be available in structured specification.

5. System interface specification. This phase specifies for the user information should enter and leave the system. The designer offers the various options. By the end of the design, formats have to be agreed upon that machine-machine and human-machine protocols are well defined prior to implementation.

             Before the system is ready for implementation, user documentation the form of a user or operator's manual must be prepared. The m provides instructions on how to install and operate the system, how to provide input, how to access, update, or retrieve information, how to play or print output, in what format, and so on. Much of this documentation cannot be written until the operation documentation is finalized task that usually follows design.

User Involvement

Walkthroughs may be held at various points in the system development life cycle. In addition to system design, they may be held to review system test plan, program design, and production acceptance. In each c the people who will be running the system should be consulted.

The probability of success improves with the user's interest and involvement in the design of the system. The user can save a system that might otherwise he of marginal benefit, and likewise he/she can kill a superbly designed system if it is perceived as making only a small contribution to performance. Thus, promoting a user’s contribution in the walkthrough and throughout the design phase can be crucial for successful implementation. 

User involvement gives the designer important feedback as the design is being completed. It also provides the user with a basic understanding of what the candidate system will and will not do. User involvement invariably paves the way for acceptance of the system by the user staff. It also bridges the gap between the designer, who as a staff person has an "expert" perspective, and the user, who is more typically "line" with a generalist or managerial view.

Stuctured Walkthrough

An activity of all phases of a structured project is the walkthrough. It is interchange of ideas among peers who review a product presented by its author (s) and agree on the validity of a proposed solution to a problem. In design walkthrough, the purpose is to anticipate as many problems in the design as possible while they are still "paper tigers." It is cheaper to make changes now than later during conversion. This is a practical implementation of "A stitch in time saves nine." The objective is to come up with maintainable design that is flexible and adaptable and meets the organization’s standards.

HIPO And IPO Charts

HIPO is a forms-driven technique in that standard forms are used document the information. It consists of a hierarchy chart and an associated set of input/process/output charts. HlPO captures the essence of t down decomposition; it describes the data input and output from processes and defines the data flow composition. It was developed by IBM as a design aid and implementation technique with the following objectives:

   1. Provide a structure by which the functions of a system can be und stood.

   2. State the functions to be performed by the program rather than specifying the program statements to be used to perform the functions.

   3. Provide a visual description of input to be used and output to be 'produced for each level of the diagram. HIPO makes the transformation of input JO output data visible. 

      HIPO uses easy-to-draw vector-like symbols between processes that define data communicati0I1 and data direction. As shown in the procedure for generating HIPO diagrams is simple:

   1. Begin at the highest level of abstraction and define the inputs to the system and the outputs from it in aggregate terms.

   2. Identify the processing steps by those that convert input into output. 

   3. Document each element using HIPO diagram notation and the associated treelike structure.

   4. Identify sub processes and their respective inputs and outputs. Continue decomposition until the processes cannot be decomposed any further.

      There are two aids available for drawing HIPO diagrams: the HIPO work sheet, jacket describes the symbols. The HIPO package format consists of the following:

1. Visual table of contents shows the structure of the diagram and the relationships of the functions in a hierarchical manner, It also has a legend to show how the symbols are to be used.

2. Overview diagrams describe the major functions and reference the detail diagram(s) needed to expand the functions adequately. They provide the following:

   a. The input section that contains the data items used by the process steps.

   b. The output section that contains the data items created by the process steps.

   c. Process section that contains numbered steps that describe the functions to be performed. Arrows connect then to the output step_ and input/output data items.

   d. The extended description refers to non-HIPO documentation and code. 

        3. Detail diagram contains an extended description section that amplifies, the process steps and references the code associated with each process step.

It is important to use HIPD early in the design phase of a project so that designers can document their thoughts concurrently with the design process. Thus, the preparation of HIPO diagrams is a by-product of the though process of the design rather than an additional chore.

From-Driven Methodology-The Ipo Charts

In structured design a hierarchy chart represents a good program design it meets the criteria of cohesion and coupling. Each module performs single function (cohesion) and should be independent of the rest of program (coupling). Each criterion calls for more details than are available. This prompts the analyst to develop input/process/output (IPO) charts for each module in the hierarchy chart.

Functional Decomposition

The documentation tool for structured design is the hierarchy lure chart. It is a graphic tool for representing hierarchy, and it elements:

   1. The module is represented by a rectangle with a name It is a contiguous set of statements.

   2. The connection is represented by a vector linking two modules. It usually means one module has called another module. 

   3. The couple is represented by an arrow with a circular tail. It represents data items moved from one module to another. In Likewise, module A calls C, passing P downward and receiving Q back. More on coupling is described next.

In the functional decomposition approach to structured design, software is partitioned into independent modules so that each module is small enough to be manageable. In the evaluation of a program module, two criteria are considered: the module's connections to other modules, called coupling, and its intramodule strength, or cohesion.

Module coupling refers to the number of connections between a "calling" and a "called" module and the complexity of these connections. There must be at least one connection between a module and a calling module. A design objective for producing an easily understood code is to make the modules as independent as possible. For example, in which is the calling module. In this case, we have coupling.

Module cohesion refers to the relationship among elements (instructions) within a module. If a module does more than one discrete task, the instructions in that module are said not to be bound together very closely. Modules that perform only one task are said to be more cohesive (and less error-prone) than modu1lols that perform multiple tasks. Compare it to the poorly cohesive modules in and you can see how important cohesion is.

Structured Design

Structured design is a data-flow-based methodology. The approach begins with a system specification that identifies inputs 'and outputs and describes the functional aspects of the system. The system specifications, then are used as a basis for the graphic representation-data flow diagram (DFD)-of the data flows and processes From the DFD, the next step is the definition of the modules and their relationships to one another in a form called a structure chart, using a data dictionary and other structured tools.

Structured design partitions a program into small, independent modules. The are arranged in a hierarchy that approximates a model of the business area and is organized in a top-down manner with the details shown at the bottom. Thus, structured design is an attempt to minimize "

Complexity and make a problem manageable by subdividing it into s segments, which is called modularization or decomposition structuring minimizes intuitive reasoning and promote maintainable, provable systems.

A design is said to be top-down if it consists of a hierarchy of mod each module having a single entry and a single exit subroutine. The advantages of this design are as follows:

   1. Critical interfaces are tested first.

   2. Early versions of the design, though incomplete, are useful enough resemble the real system.

   3. Structuring the design, per se, provides control and improves morale.

   4. The 'procedural characteristics define the order that determines processing.

So structured design arises from the hierarchical view of the application rather than the procedural view. The top level shows the most important division of work; the lowest level at the bottom shows the detail.

Design Methodologies

During the past decade, there has been a growing move to transform "art" of systems analysis and design into an "engineering-type" discipline. The feeling that there has to be a more clearly defined logical method developing a system that meets user requirements has led to new teach niques and methodologies that fundamentally attempt to do the following:

   1. Improve productivity of analysts and programmers.

   2. Improve documentation and subsequent maintenance and enhancements.

   3. Cut down drastically on cost overruns and delays.

   4. Improve communication among the user, analyst, designer, and grammar.

   5. Standardize the approach to analysis and design.

   6. Simplify design by segmentation.

Logical And Phycal Design

Systems design goes though two phases of development: logical and physical design. As we saw in Chapter G, a data flow diagram shows the' flow of a system and defines the boundaries of the system. For a candidate system it describes the inputs (source), outputs (destination), data (data stores), and procedures (data flows)-all in a format that meets user's requirements. When analysts prepare the logical system design, they specify the use" needs at a level of detail that· virtually determine information How into and out of the system and the required data sources. The design covers the following:

   1. Reviews the current physical system-its data flows, file content volumes, frequencies, etc.

   2. Prepares output specifications-that is, determines the format, content and frequency of reports, including terminal specifications and locations.

   3. Prepares input specifications-format, content, and most of the input functions. This includes determining the flow of the document from the input data source to the actual input location.

   4. Prepares edit, security, and control specifications. This includes spec­ if) ring the rules for edit correction, backup processing, and the controls that ensure processing and file integrity.

   5. Specifies the implementation plan.

   6. Prepares a logical design walkthrough of the information flow, output, input, controls, and implementation plan.

  7. Reviews benefits, costs, target dates, and system constraints.

      As an illustration, when a safe deposit tracking system is designed, system specifications include weekly reports, a definition of boxes rented d boxes vacant, and a summary of the activities of the week-boxes -ed, boxes drilled, and so on. The logical design also specifies output, at, file, and screen layouts. In contrast, procedure specifications show \ data are entered, how files are accessed, and how reports are produced.

Following logical "design is physical design. This produces the working system by defining the design specifications that tell programmers exactly the candidate system must do. In turn, the programmer writes the necessary programs or modifies the software package that accepts input from the user, performs the necessary calculations through the existing or data base, produces the report on a hard copy or displays it on a sc and maintains an updated data base at all times. Specifically, physical system design consists of the following steps:

1. Design the physical system.

   a. Specify input/output media.

   b. Design the database and specify backup procedures.

   c. Design physical information flow through the system and a Physical design walkthrough.

2. Plan system implementation.

   a. Prepare a conversion schedule and a target date.

   b. Determine training procedure, courses, and timetable.       

   c. Devise a test and implementations plan and specify any new hard\software.

   d. Update benefits, costs, conversion date, and system constraints (legal financial, hardware, etc,)

The physical design for our safe deposit illustration is a software age written in Pascal (a programming language). It consists of program s that accept new box rental information; change the number of boxes a able with every new box rental; print a report by box type, box size, and location; and store the information in the data base for reference. Analyst instructs the software programmer to have the package dips. Menu that specifies for the user how to enter a new box rental, produce report, or display various information on the screen. These and 0 procedure specifications are tested and implemented as a working model the candidate system.