Chapter 16

The objective of systems design is to produce the design specifications for the system that will satisfy the requirements defined during the systems analysis. These specifications should be detailed enough to become inputs to the programming stage that follows the design. The design process is usually broken down into two parts:

1. Logical design - produces the general specification of the resources that will make up the system.

2. Physical design - produces a complete, detailed specification of the named program components, called modules, which are to be programmed, and of the databases to be maintained by the system.

The following system aspects have to be determined and described in the appropriate documentation during the system design:

1. Hardware and systems software platforms for the application.

2. Programs that will constitute the application and the modules that will make up the programs.

3. Specification of individual software modules

4. Design of the database

5. Design of user interfaces

6. Procedures for system use.

Logical Design

During the logical design, the developers create the general specification for the information system's resources, often taking the existing system as a point of departure. The developers will devise alternative major solutions to the problem identified during the analysis phase and recommend one of these solutions for implementation.

Activities included in the logical design include:

1. The components of the hardware and systems software environment for the system are specified.

2. System outputs and the inputs needed to produce these outputs are identified.

3. The user interface (means whereby the user interacts with the system), is specified.

4. The logical design of the database is developed

5. The programs that will compose the system and the modules that will make up the programs are designed.

6. The procedures to be employed in operating the system are specified

7. The controls that will be incorporated in the system are specified, with information systems auditors participating in the process.

Physical Design

The objective of physical design is to produce a complete specification of all system modules and of interfaces between them, and to perform physical design of the database. Structured design methodologies help specify module logic during this stage.

When physical design is completed, the following aspects of the system will have been specified:

1. System outputs

2. System inputs

3. User-system interface

4. Platforms

5. Acquisition method

6. Modular design of the programs that will be developed for the application, interfaces between the modules, and the specifications of the logic of individual modules.

7. Detailed test plan

8. Database

9. Controls

10. Documentation

11. Conversion plan

It is critical to sustain the processes of organizational change connected with system implementation. This includes:

1. Reorganizing the affected units of the firm

2. Redesigning the jobs of people who will be affected by the system

3. Enhancing user motivation

4. Conducting user training.

16.2 Techniques and Tools of Structured Systems Design [Figure 16.2]

The principal objective of structured design is to specify the structure of the programs in the system in such a way that the system will be relatively easy to program and modify.

The principal product of the logical design stage of structured design is the structure charts of the programs that need to be coded and tested. A structure chart specifies the modules that the program will consist of and the interfaces between them. An interface is a call by a higher-level module - it calls a lower-level module to do part of the task.

Structured systems design is based on two basic principles:

1. Modular Structure

2. Hierarchical Design

Modular Structure

Programs must be constructed of modules. A module is a named program routine that is handled as a unit which is evoked (called) by their names during program execution. Characteristics of a module include:

1. A module ought to perform completely a well-defined function in the overall system

2. A module should be short enough so that its logic is relatively easy to understand.

3. Modules are relatively independent from one another and thus, a modification of some of them during maintenance will scarcely affect other modules.

Hierarchical Design

Program modules are identified top-down; thus, a hierarchical program structure emerges. Characteristics of a hierarchical design include:

1. Start with the single top module that provides the overall control

2. Break down its function into lower-level functions and so identify the modules it must call.

3. Maintenance is made easier as the maintainer can understand the program structure by studying the structure chart and relating it to the program code.

16.3 Programming

At this stage of its development, the system is coded, tested, and debugged in a process called programming. Programming is writing instructions for computer execution and testing the written code to ensure that it performs according to specifications. The objective of programming is thus to produce reliable software based on appropriate design specifications.

Programming tasks include:

1. Coding the software module specifications produced during system design into statements in a programming language.

2. Testing at several levels, beginning with testing individual modules as they are programmed and culminating in acceptance or installation testing before the system is placed into operation.

Debugging - problems discovered during testing are tracked down to their source in the code and removed.

To ensure quality of the product, the discipline of structured programming is essential. Coding the program by relying on a small number of simple programming structures for organizing its logic. This makes the program code relatively easy to understand, test, and modify.

16.4 Software Quality Assurance [Figure 16.3]

Software quality assurance includes a variety of techniques aimed at producing a software product that satisfies user requirements and organizational objectives.

Early detection of errors is the basis of cost-effective software quality assurance. Early errors that are not detected right after they are made are expensive to correct later. The severity of errors varies.

The principal means of software quality assurance in the early development stages are walkthroughs and inspections. The essential means of quality assurance when the program code is available is software testing.

Walkthroughs and Inspections

A walkthrough is a review by a small group of people of a system development product presented by its author. Walkthroughs should be scheduled frequently during systems development so that a manageable piece of work can be thoroughly reviewed in one to two hours. Walkthroughs include:

1. Specification walkthroughs, where the group looks for errors, omissions, and ambiguities in the data flow diagrams at various levels, in the data dictionary entries, and in other components of requirements specifications.

2. Design walkthroughs, where program listings are studied.

3. Code walkthroughs, where program listings are studied.

4. Test walkthroughs, to ensure that the test cases are prepared thoroughly.

It is crucial for the effectiveness of walkthroughs that they are established as a quality assurance tool as opposed to a management tool for evaluating the performance of IS professionals.

An inspection is similar to a walkthrough in its objectives, but it is a more formal review technique. In an inspection, a review team checks a data flow diagram or a program against a prepared list of concerns. At the heart of code inspection is the paraphrasing technique: An inspector verbally expresses the meaning of one or more lines of code at a time, with other participants striving to detect errors in this code. Inspections also include formal rework and follow-up stages to see that the discovered errors were corrected.

Testing [Figure 16.4]

Testing involves executing the information system components, and the entire system when available, for the purpose of fixing errors.

General principles of testing include:

1. A test plan must be prepared to specify the sequence in which the modules will be coded, in individually tested, and then integrated into the program.

2. Test cases must be prepared as part of the plan. Each test case should include a specification of the data to be submitted as inputs, as well as a specification of the expected results of the test.

3. All test results should be studied and recorded.

5. Test cases should be prepared for both valid and invalid input conditions.

6. Software tools are available to support testing and debugging; their use significantly increases the effectiveness of the process.

- after individual modules are coded and unit-tested, they are integrated into the overall program. Generally, one module at a time is added to the structure and the resulting partial product is tested.

3. System testing

- the system is validated against its functional specifications, in an environment and under loads that resemble the actual operation as closely as possible. The system is subjected to stress loads to see whether it degrades gracefully. The system's compatibility is checked against other systems it will have to interact with. Controls and recovery procedures are also tested. It is very important to test the documentation that will accompany the system along with the system itself.

A beta test of software is used to test the early copies of software by the intended end users in order to uncover problems in actual use.

4. Acceptance testing

- a set of systems tests are run in order to ensure that the requirements of Aall users@ have been satisfied. A suite of tests validating the overall system operation is identified, documented, and preserved for maintenance purposes. These regression tests will be used to revalidate the system following each maintenance procedure.

5. Installation testing

- if acceptance testing was done before a system was installed in its production environment, a set of system tests is run again following installation. The system is now ready for operation.

Following acceptance testing, a planned conversion to the new system is performed. The four common conversion methods include:

1. Parallel operation

- this method is the safest method of conversion

- the old and new systems are run simultaneously until sufficient confidence is gained in the new system.

- it is expensive to run both the old and new systems during this conversion method

2. Direct conversion

- this method is the most risky (and thus potentially the most expensive) method of conversion.

- at a certain point the old system is completely replaced by the new one.

3. Phased conversion

- involves a gradual conversion

- the new system is introduced in incremental stages, which are divided by function, organizational units served, the hardware on with the new system will reside, or some other factor.

4. Pilot version

- involves a gradual conversion

- this method relies on introducing a part of the system into one carefully designated organizational area, learning from this experience, and then introducing the complete system.

The final phase of the development life cycle is actually conducted during systems operations. Its objective is to assess both the system and the development methodology, and it is a vital aspect of organizational learning. This stage is called the postimplementation review.

A properly conducted review pursues several objectives:

1. The organizational impact of the system is studied and further effort is made to ensure successful implementation. The review may trigger adjustments in organizational structure, business processes, and job designs.

2. A major system development project should be a source of organizational learning.

3. The system's performance and controls are evaluated, with the IS auditors participating. Requests for maintenance frequently follow this evaluation.

Operational information systems must be maintained. Maintenance is the process of modifying an information system to continually satisfy organizational and user requirements. There is a vast difference between hardware and software maintenance in costs as well as in objectives.

Hardware maintenance - the purpose of maintaining computer system hardware is to keep the equipment in working order without changing its functionality. Traditionally, this aspect of system maintenance has been covered by maintenance contracts with equipment manufacturers.

Systems maintenance - the principal effort in system maintenance is directed at maintaining the applications software. Software maintenance includes all modifications of a software product after it has been turned over to operations. The cost of this maintenance over the useful life of an application is typically twice the development cost.

Software maintenance actually consists of three types of activities: [Figure 16.7]

1. Perfective maintenance

- enhancing and modifying the system to respond to changing user requirements and organizational needs, improving system efficiency, and enhancing documentation.

2. Adaptive maintenance

- changing the application to adapt it to a new hardware or software environment. Adaptive maintenance may involve, for example, moving an application from a mainframe to a client/server environment, or converting it from a file to a database environment.

3. Corrective maintenance

- correcting an error discovered during operations.

The Dynamics of Software Maintenance

A software maintenance procedure consists of three steps:

1. We need to understand the software to be modified and identify the parts targeted for maintenance.

2. We must then modify the appropriate components of the application system without adversely affecting the rest of the system

3. We must test and thus validate the modified components, as well as the entire system.

Two relatively new technologies offer particular promise to raise the productivity of information systems development and enhance the quality of the resulting product. These include:

1. CASE

2. Object oriented development (OOD)

Computer aided software engineering (CASE) technology offers development tools that automate important aspects of the software development process.

Object oriented development (OOD) is a software development methodology that offers the all-important possibility of large-scale software reuse: an ability to build up a collection of basic software components from which larger and larger systems may be constructed.

Computer-Aided Software Engineering (CASE) [Figure 16.8 & Figure 16.9]

Computer-Aided Software Engineering (CASE) tools assist software developers in planning, analyzing, designing, programming, and maintaining information systems. The principal advantage of a CASE tool is that it offers an integrated package of capabilities for several of these tasks.

The best-known CASE tools assist the developer in creating a complete set of requirements specifications for a system, with all the data flow diagrams and with the entities defined in the data dictionary. The tool subsequently supports the development of structure charts. Alternative development methodologies and the design of databases are also supported.

CASE tools combine several technologies:

1. Software development methodologies, such as structured systems development

2. Fourth-generation languages for nonprocedural coding

3. Graphical user interfaces.

It is important to stress to students that reference to CASE most often means the Afront-end@ tools that support the earlier phase of systems development, such as analysis and design. However, CASE tools also include the Aback-end@ tools such as code generators - software that produces program code from a terse specification.

CASE tools are an excellent vehicle for rapid applications development through prototyping. They help to develop the hierarchy of menus for the user interface and specify screens and reports, all of which can be done in consultation with the users. The code generator then produces the necessary code.

Figure 16.9 The focal facility of a CASE tool is the information repository, a central database for storing and managing project data dictionaries, which can contain all the information about the system being developed. This information begins with the plans and goes on to the entities that appear in data flow diagrams, onto the code, and even to the project management information. CASE tools facilitate traceability - the ability to relate program code to the analysis and design entities it implements.

CASE tools provide automatic assistance for checking the consistency and completeness of the products as the development goes on. The availability of this information makes it easier to introduce modifications in a consistent fashion at any time during system development or maintenance.

CASE tools can also contribute significantly to improved maintenance of information systems. In the first place, the use of CASE during the development means better documented systems, with essential documentation kept in the repository and thus relatively easy to maintain. It is possible to trace a user's request for an enhancement from a DFD to the code modules to be modified and thus to determine the impact of the change. CASE tools make it possible to maintain system specifications as they are changed during maintenance.

Certain CASE tools are expressly designed for maintenance activities. Such packages automatically recast a program from unstructured code into a structured format that relies disciplined programming.

More elaborate CASE packages for maintenance support reverse engineering - developing analysis and design specifications from the program code.

CASE technology has contributed significantly in reducing time-to-market for products and services. However, CASE is a complex technology, requiring organizational and individual learning. Quality improvements are likely to come before increases in productivity of systems development or maintenance. The complexity of CASE tools and the lack of integrated support for systems development have limited their adoption.

Object-Oriented Development

Object-oriented development (OOD) aims to build a software model of the real-world system. This explicit modeling is done by defining and implementing classes of objects using the vocabulary of the business that will be supported by the information system.

The central principal in object-oriented development (OOD) is building the system as a collection of interacting objects. If program objects represent real-world objects, we obtain a rather close correspondence between the program components and their real-world equivalents. Much of the development proceeds by defining the classes of objects for the information system. Classes are templates of objects and, conversely, objects are instances of classes. The classes and objects that information systems deal with are relatively permanent in their behaviour. Therefore, code libraries can be built up, to be used as needed.

The appeal of OOD is the ability to build up libraries of reusable code. Developers are able to use software components developed for other systems - and tested through prior use.

Producing reusable software components is only one of the potential benefits of the object-oriented approach. The process of systems analysis and design based on object orientation is a powerful technique for gaining understanding of a business system and casting this understanding into modifiable software components. With OOD, there is a smooth transition from analysis to design - both of these development tasks deal with objects and classes of objects.

OOD is especially promising for:

1. Graphical user interfaces, where objects such as icons are common

2. Complex applications running on several computers, such as client/server systems, where different objects can be allocated to different processors.

3. Multimedia applications, which need to support a variety of objects, such as test, voice, image, and video.

Proper management of a large software development maintenance project has three main aspects:

1. Estimation of the effort needed to develop the system

2. Project planning (or scheduling)

3. The organization of development teams.

Estimation of System Development Effort [Figure 16.10]

In general, projects start with a small number of people in the initial stages of systems analysis and design. The number then peaks during the coding and testing stage. The actual shape of the curve depends on a variety of factors.

There are several ways to estimate the development time and cost for a software system.

1. Estimating is done by analogy with a previously developed system.

2. Establishing a measure for the software product and by determining the relationship of this measure to the cost and time of software development. A frequent measure is the estimated count of lines of the code to be delivered.

3. Functional points technique of estimating software development effort early in development by considering the number and complexity of the system inputs, outputs, inquiries, and files.

Project Scheduling and Tracking: Use of Software Tools

Once the total development effort on the project has been estimated, a project schedule may be established. A schedule breaks the project up into stages, which may be further broken down into lower-level activities. Major activities terminate in a milestone, which is defined in terms of completed deliverables.

Methods used to schedule activities as a project progresses include:

1. PERT/CPM - is a method of scheduling systems development or maintenance activities and controlling the project. Figure 16.11 - a PERT chart shows the precedence relationships among the activities listed and the numbered completion events (milestones). The critical path consists only of critical activities. Any delay in an activity on this path will cause project delay.

Using PERT/CPM, enables us to answer questions such as these: [Figure 16.11]

1. How much total time will be needed to complete the project

2. What are the scheduled start and finish times for each activity

3. Which activities are critical and must be completed exactly as scheduled

4. How long may noncritical activities be delayed.

2. Gantt Chart - is a graphical tool for project management that represents project tasks over time as a bar chart.

Software Project Teams

Most software projects, in both development and maintenance, are carried out by teams. Team composition varies depending on the development phase - initially it may include largely systems analysts, but in the end it will consist chiefly of programmers. It is generally recognized that teams should be small (no more than 10 people), since the development of a complex product such as an information system calls for intense communication among team members.

Two organizational structures for a team, representing opposite extremes are the: