Process Specification Tools In System Analysis And Design

OVERVIEW OF SYSTEMS DEVELOPMENT

Whatever their scope and objectives, new information systems are an outgrowth of a process of organizational problem solving. A new information system is built as a solution to some type of problem or set of problems the organization perceives it is facing. The problem may be one in which managers and employees realize that the organization is not performing as well as expected, or it may come from the realization that the organization should take advantage of new opportunities to perform more successfully.

The activities that go into producing an information system solution to an organizational problem or opportunity are called systems development. Systems development is a structured kind of problem solving with distinct activities. These activities consist of systems analysis, systems design, programming, testing, conversion, and production and maintenance.

Figure 14-5 illustrates the systems development process. The systems development activities depicted here usually take place in sequential order. But some of the activities may need to be repeated or some may take place simultaneously, depending on the approach to system building that is being employed (see section 14.4).

FIGURE 14-5 The systems development process
Building a system can be broken down into six core activities.

Systems Analysis

Systems analysis is the analysis of the problem that the organization will try to solve with an information system. It consists of defining the problem, identifying its causes, specifying the solution, and identifying the information requirements that must be met by a system solution.

The systems analyst creates a road map of the existing organization and systems, identifying the primary owners and users of data along with existing hardware and software. The systems analyst then details the problems of existing systems. By examining documents, work papers, and procedures; observing system operations; and interviewing key users of the systems, the analyst can identify the problem areas and objectives a solution would achieve. Often the solution requires building a new information system or improving an existing one.

The systems analysis would include a feasibility study to determine whether that solution was feasible, or achievable, from a financial, technical, and organizational standpoint. The feasibility study would determine whether the proposed system was a good investment, whether the technology needed for the system was available and could be handled by the firm�s information systems specialists, and whether the organization could handle the changes introduced by the system.

Normally, the systems analysis process identifies several alternative solutions that the organization can pursue. The process then assesses the feasibility of each. A written systems proposal report describes the costs and benefits, advantages and disadvantages of each alternative. It is up to management to determine which mix of costs, benefits, technical features, and organizational impacts represents the most desirable alternative.

ESTABLISHING INFORMATION REQUIREMENTS

Perhaps the most challenging task of the systems analyst is to define the specific information requirements that must be met by the system solution selected. At the most basic level, the information requirements of a new system involve identifying who needs what information, where, when, and how. Requirements analysis carefully defines the objectives of the new or modified system and develops a detailed description of the functions that the new system must perform. Faulty requirements analysis is a leading cause of systems failure and high systems development costs (see Chapter 15). A system designed around the wrong set of requirements will either have to be discarded because of poor performance or will need to undergo major modifications. Section 14.4 describes alternative approaches to eliciting requirements that help minimize this problem.

Some problems do not require an information system solution but instead need an adjustment in management, additional training, or refinement of existing organizational procedures. If the problem is information related, systems analysis still may be required to diagnose the problem and arrive at the proper solution.

Systems Design

Systems analysis describes what a system should do to meet information requirements, and systems design shows how the system will fulfill this objective. The design of an information system is the overall plan or model for that system. Like the blueprint of a building or house, it consists of all the specifications that give the system its form and structure.

The systems designer details the system specifications that will deliver the functions identified during systems analysis. These specifications should address all of the managerial, organizational, and technological components of the system solution. Table 14-3 lists the types of specifications that would be produced during systems design.

TABLE 14-3 Design Specifications

Like houses or buildings, information systems may have many possible designs. Each design represents a unique blend of all technical and organizational components. What makes one design superior to others is the ease and efficiency with which it fulfills user requirements within a specific set of technical, organizational, financial, and time constraints.

THE ROLE OF END USERS

User information requirements drive the entire system-building effort. Users must have sufficient control over the design process to ensure that the system reflects their business priorities and information needs, not the biases of the technical staff. Working on design increases users� understanding and acceptance of the system. As we describe in Chapter 15, insufficient user involvement in the design effort is a major cause of system failure. However, some systems require more user participation in design than others, and section 14.4 shows how alternative systems development methods address the user participation issue.

Completing the Systems Development Process

The remaining steps in the systems development process translate the solution specifications established during systems analysis and design into a fully operational information system. These concluding steps consist of programming, testing, conversion, production, and maintenance.

Building successful information systems requires close cooperation among end users and information systems specialists throughout the systems development process.

PROGRAMMING

During the programming stage, system specifications that were prepared during the design stage are translated into software program code. Today, many organizations no longer do their own programming for new systems. Instead, they purchase the software that meets the requirements for a new system from external sources such as software packages from a commercial software vendor, software services from an application service provider, or outsourcing firms that develop custom application software for their clients (see section 14.4).

TESTING

Exhaustive and thorough testing must be conducted to ascertain whether the system produces the right results. Testing answers the question, �Will the system produce the desired results under known conditions?�

The amount of time needed to answer this question has been traditionally underrated in systems project planning (see Chapter 15). Testing is time consuming: Test data must be carefully prepared, results reviewed, and corrections made in the system. In some instances parts of the system may have to be redesigned. The risks resulting from glossing over this step are enormous.

Testing an information system can be broken down into three types of activities: unit testing, system testing, and acceptance testing. Unit testing, or program testing, consists of testing each program separately in the system. It is widely believed that the purpose of such testing is to guarantee that programs are error free, but this goal is realistically impossible. Testing should be viewed instead as a means of locating errors in programs, focusing on finding all the ways to make a program fail. Once they are pinpointed, problems can be corrected.

System testing tests the functioning of the information system as a whole. It tries to determine whether discrete modules will function together as planned and whether discrepancies exist between the way the system actually works and the way it was conceived. Among the areas examined are performance time, capacity for file storage and handling peak loads, recovery and restart capabilities, and manual procedures.

Acceptance testing provides the final certification that the system is ready to be used in a production setting. Systems tests are evaluated by users and reviewed by management. When all parties are satisfied that the new system meets their standards, the system is formally accepted for installation.

The systems development team works with users to devise a systematic test plan. The test plan includes all of the preparations for the series of tests we have just described.

Figure 14-6 shows an example of a test plan. The general condition being tested is a record change. The documentation consists of a series of test-plan screens maintained on a database (perhaps a PC database) that is ideally suited to this kind of application.

FIGURE 14-6 A sample test plan to test a record change
When developing a test plan, it is imperative to include the various conditions to be tested, the requirements for each condition tested, and the expected results. Test plans require input from both end users and information systems specialists.

CONVERSION

Conversion is the process of changing from the old system to the new system. Four main conversion strategies can be employed: the parallel strategy, the direct cutover strategy, the pilot study strategy, and the phased approach strategy.

In a parallel strategy both the old system and its potential replacement are run together for a time until everyone is assured that the new one functions correctly. This is the safest conversion approach because, in the event of errors or processing disruptions, the old system can still be used as a backup. However, this approach is very expensive, and additional staff or resources may be required to run the extra system.

The direct cutover strategy replaces the old system entirely with the new system on an appointed day. It is a very risky approach that can potentially be more costly than running two systems in parallel if serious problems with the new system are found. There is no other system to fall back on. Dislocations, disruptions, and the cost of corrections may be enormous.

The pilot study strategy introduces the new system to only a limited area of the organization, such as a single department or operating unit. When this pilot version is complete and working smoothly, it is installed throughout the rest of the organization, either simultaneously or in stages.

The phased approach strategy introduces the new system in stages, either by functions or by organizational units. If, for example, the system is introduced by functions, a new payroll system might begin with hourly workers who are paid weekly, followed six months later by adding salaried employees (who are paid monthly) to the system. If the system is introduced by organizational units, corporate headquarters might be converted first, followed by outlying operating units four months later.

Moving from an old system to a new one requires that end users be trained to use the new system. Detailed documentation showing how the system works from both a technical and end-user standpoint is finalized during conversion time for use in training and everyday operations. Lack of proper training and documentation contributes to system failure, so this portion of the systems development process is very important.

PRODUCTION AND MAINTENANCE

After the new system is installed and conversion is complete, the system is said to be in production. During this stage, the system will be reviewed by both users and technical specialists to determine how well it has met its original objectives and to decide whether any revisions or modifications are in order. In some instances, a formal postimplementation audit document is prepared. After the system has been fine-tuned, it must be maintained while it is in production to correct errors, meet requirements, or improve processing efficiency. Changes in hardware, software, documentation, or procedures to a production system to correct errors, meet new requirements, or improve processing efficiency are termed maintenance.

Studies of maintenance have examined the amount of time required for various maintenance tasks (Lientz and Swanson, 1980). Approximately 20 percent of the time is devoted to debugging or correcting emergency production problems; another 20 percent is concerned with changes in data, files, reports, hardware, or system software. But 60 percent of all maintenance work consists of making user enhancements, improving documentation, and recoding system components for greater processing efficiency. The amount of work in the third category of maintenance problems could be reduced significantly through better systems analysis and design practices. Table 14-4 summarizes the systems development activities.

TABLE 14-4 Systems Development

Modeling and Designing Systems: Structured and Object-Oriented Methodologies

There are alternative methodologies for modeling and designing systems. Structured methodologies and object-oriented development are the most prominent.

STRUCTURED METHODOLOGIES

Structured methodologies have been used to document, analyze, and design information systems since the 1970s. Structured refers to the fact that the techniques are step by step, with each step building on the previous one. Structured methodologies are top-down, progressing from the highest, most abstract level to the lowest level of detail�from the general to the specific.

Structured development methods are process-oriented, focusing primarily on modeling the processes, or actions that capture, store, manipulate, and distribute data as the data flow through a system. These methods separate data from processes. A separate programming procedure must be written every time someone wants to take an action on a particular piece of data. The procedures act on data that the program passes to them.

The primary tool for representing a system�s component processes and the flow of data between them is the data flow diagram (DFD). The data flow diagram offers a logical graphic model of information flow, partitioning a system into modules that show manageable levels of detail. It rigorously specifies the processes or transformations that occur within each module and the interfaces that exist between them.

Figure 14-7 shows a simple data flow diagram for a mail-in university course registration system. The rounded boxes represent processes, which portray the transformation of data. The square box represents an external entity, which is an originator or receiver of data located outside the boundaries of the system being modeled. The open rectangles represent data stores, which are either manual or automated inventories of data. The arrows represent data flows, which show the movement between processes, external entities, and data stores. They always contain packets of data with the name or content of each data flow listed beside the arrow.

FIGURE 14-7 Data flow diagram for mail-in university registration system
The system has three processes: Verify availability (1.0), Enroll student (2.0), and Confirm registration (3.0). The name and content of each of the data flows appear adjacent to each arrow. There is one external entity in this system: the student. There are two data stores: the student master file and the course file.

This data flow diagram shows that students submit registration forms with their name, identification number, and the numbers of the courses they wish to take. In process 1.0 the system verifies that each course selected is still open by referencing the university�s course file. The file distinguishes courses that are open from those that have been canceled or filled. Process 1.0 then determines which of the student�s selections can be accepted or rejected. Process 2.0 enrolls the student in the courses for which he or she has been accepted. It updates the university�s course file with the student�s name and identification number and recalculates the class size. If maximum enrollment has been reached, the course number is flagged as closed. Process 2.0 also updates the university�s student master file with information about new students or changes in address. Process 3.0 then sends each student applicant a confirmation-of-registration letter listing the courses for which he or she is registered and noting the course selections that could not be fulfilled.

The diagrams can be used to depict higher-level processes as well as lower-level details. Through leveled data flow diagrams, a complex process can be broken down into successive levels of detail. An entire system can be divided into subsystems with a high-level data flow diagram. Each subsystem, in turn, can be divided into additional subsystems with second-level data flow diagrams, and the lower-level subsystems can be broken down again until the lowest level of detail has been reached.

Another tool for structured analysis is a data dictionary, which contains information about individual pieces of data and data groupings within a system (see Chapter 7). The data dictionary defines the contents of data flows and data stores so that systems builders understand exactly what pieces of data they contain. Process specifications describe the transformation occurring within the lowest level of the data flow diagrams. They express the logic for each process.

In structured methodology, software design is modeled using hierarchical structure charts. The structure chart is a top-down chart, showing each level of design, its relationship to other levels, and its place in the overall design structure. The design first considers the main function of a program or system, then breaks this function into subfunctions, and decomposes each subfunction until the lowest level of detail has been reached. Figure 14-8 shows a high-level structure chart for a payroll system. If a design has too many levels to fit onto one structure chart, it can be broken down further on more detailed structure charts. A structure chart may document one program, one system (a set of programs), or part of one program.

FIGURE 14-8 High-level structure chart for a payroll system
This structure chart shows the highest or most abstract level of design for a payroll system, providing an overview of the entire system.

OBJECT-ORIENTED DEVELOPMENT

Structured methods are useful for modeling processes, but do not handle the modeling of data well. They also treat data and processes as logically separate entities, whereas in the real world such separation seems unnatural. Different modeling conventions are used for analysis (the data flow diagram) and for design (the structure chart).

Object-oriented development tries to deal with these issues. Object-oriented development uses the object as the basic unit of systems analysis and design. An object combines data and the specific processes that operate on those data. Data encapsulated in an object can be accessed and modified only by the operations, or methods, associated with that object. Instead of passing data to procedures, programs send a message for an object to perform an operation that is already embedded in it. The system is modeled as a collection of objects and the relationships among them. Because processing logic resides within objects rather than in separate software programs, objects must collaborate with each other to make the system work.

Object-oriented modeling is based on the concepts of class and inheritance. Objects belonging to a certain class, or general categories of similar objects, have the features of that class. Classes of objects in turn can inherit all the structure and behaviors of a more general class and then add variables and behaviors unique to each object. New classes of objects are created by choosing an existing class and specifying how the new class differs from the existing class, instead of starting from scratch each time.

We can see how class and inheritance work in Figure 14-9, which illustrates the relationships among classes concerning employees and how they are paid. Employee is the common ancestor, or superclass, for the other three classes. Salaried, Hourly, and Temporary are subclasses of Employee. The class name is in the top compartment, the attributes for each class are in the middle portion of each box, and the list of operations is in the bottom portion of each box. The features that are shared by all employees (id, name, address, date hired, position, and pay) are stored in the Employee superclass, whereas each subclass stores features that are specific to that particular type of employee. Specific to Hourly employees, for example, are their hourly rates and overtime rates. A solid line from the subclass to the superclass is a generalization path showing that the subclasses Salaried, Hourly, and Temporary have common features that can be generalized into the superclass Employee.

FIGURE 14-9 Class and inheritance
This figure illustrates how classes inherit the common features of their superclass.

The phases of object-oriented development are similar to those of conventional systems development, consisting of analysis, design, and implementation. However, object-oriented development is more iterative and incremental than traditional structured development. During analysis, systems builders document the functional requirements of the system, specifying its most important properties and what the proposed system must do. Interactions between the system and its users are analyzed to identify objects, which include both data and processes. The object-oriented design phase describes how the objects will behave and how they will interact with one other. Similar objects are grouped together to form a class, and classes are grouped into hierarchies in which a subclass inherits the attributes and methods from its superclass.

The information system is implemented by translating the design into program code, reusing classes that are already available in a library of reusable software objects and adding new ones created during the object-oriented design phase. Implementation may also involve the creation of an object-oriented database. The resulting system must be thoroughly tested and evaluated.

Because objects are reusable, object-oriented development could potentially reduce the time and cost of writing software because organizations can reuse software objects that have already been created as building blocks for other applications. New systems can be created by using some existing objects, changing others, and adding a few new objects. Object-oriented frameworks have been developed to provide reusable, semicomplete applications that the organization can further customize into finished applications.

Unified Modeling Language (UML) has become the industry standard for representing various views of an object-oriented system using a series of graphical diagrams. The underlying model integrates these views to promote consistency during analysis, design, and implementation. UML uses two principal types of diagrams: structural diagrams and behavioral diagrams.

Structural diagrams are used to describe the relationship between classes. Figure 14-9 is an example of one type of structural diagram called a class diagram. It shows classes of employees and the relationships between them. The terminators at the end of the relationship lines in this diagram indicate the nature of the relationship. The relationships depicted in Figure 14-9 are examples of generalization, which is a relationship between a general kind of thing and a more specific kind of thing. This type of relationship is sometimes described as an �is-a relationship�. Generalization relationships are used for modeling class inheritance.

Behavioral diagrams are used to describe interactions in an object-oriented system. Figure 14-10 illustrates one type of behavioral diagram called a use case diagram. A use case diagram shows the relationship between an actor and a system. The actor (represented in the diagram as a stick man) is an external entity that interacts with the system, and the use case represents a series of related actions initiated by the actor to accomplish a specific goal. Several interrelated use cases are represented as ovals within a box. Use case modeling is used to specify the functional requirements of a system, focusing on what the system does rather than how it does it. The system�s objects and their interactions with each other and with the users of the system are derived from the use case model.

FIGURE 14-10 A UML use case diagram
Use case diagrams model the functions of a system, showing how objects interact with each other and with the users of the system. Illustrated here is a use case diagram for credit card processing that was created with SmartDraw software.

COMPUTER-AIDED SOFTWARE ENGINEERING

Computer-aided software engineering (CASE)�sometimes called computer-aided systems engineering�provides software tools to automate the methodologies we have just described to reduce the amount of repetitive work the developer needs to do. CASE tools also facilitate the creation of clear documentation and the coordination of team development efforts. Team members can share their work easily by accessing each other�s files to review or modify what has been done. Modest productivity benefits can also be achieved if the tools are used properly. Many CASE tools are PC-based, with powerful graphical capabilities.

CASE tools provide automated graphics facilities for producing charts and diagrams, screen and report generators, data dictionaries, extensive reporting facilities, analysis and checking tools, code generators, and documentation generators. In general, CASE tools try to increase productivity and quality by doing the following:

Enforce a standard development methodology and design discipline
Improve communication between users and technical specialists
Organize and correlate design components and provide rapid access to them using a design repository
Automate tedious and error-prone portions of analysis and design
Automate code generation and testing and control rollout

Many CASE tools have been classified in terms of whether they support activities at the front end or the back end of the systems development process. Front-end CASE tools focus on capturing analysis and design information in the early stages of systems development, whereas back-end CASE tools address coding, testing, and maintenance activities. Back-end tools help convert specifications automatically into program code.

CASE tools automatically tie data elements to the processes where they are used. If a data flow diagram is changed from one process to another, the elements in the data dictionary would be altered automatically to reflect the change in the diagram. CASE tools also contain features for validating design diagrams and specifications. CASE tools thus support iterative design by automating revisions and changes and providing prototyping facilities. A CASE information repository stores all the information defined by the analysts during the project. The repository includes data flow diagrams, structure charts, entity-relationship diagrams, UML diagrams, data definitions, process specifications, screen and report formats, notes and comments, and test results.

To be used effectively, CASE tools require organizational discipline, management support, and an organizational culture that appreciates the value of such tools (Limayem, Khalifa, and Chin, 2004). Every member of a development project must adhere to a common set of naming conventions and standards as well as to a development methodology. The best CASE tools enforce common methods and standards, which may discourage their use in situations where organizational discipline is lacking.