What are the core activities in the systems development process?

New information systems are an outgrowth 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 that the organization should take advantage of new op­portunities 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 solved with distinct ac­tivities. These activities consist of systems analysis, systems design, program­ming, testing, conversion, and production and maintenance.

Figure 13.4 illustrates the systems development process. The systems de­velopment activities depicted usually take place in sequential order. But some of the activities may need to be repeated or some may take place simultane­ously depending on the approach to system building that is being employed (see Section 13-4).

1. Systems Analysis

Systems analysis is the analysis of a problem that a firm tries 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 sys­tems, identifying the primary owners and users of data along with existing hard­ware and software. The systems analyst then details the problems of existing systems. By examining documents, work papers, and procedures, observing sys­tem operations, and interviewing key users of the systems, the analyst can iden­tify the problem areas and objectives a solution would achieve. Often, the solu­tion requires building a new information system or improving an existing one.

The systems analysis also includes a feasibility study to determine whether that solution is feasible, or achievable, from a financial, technical, and orga­nizational standpoint. The feasibility study determines whether the proposed system is expected to be a good investment, whether the technology needed for the system is available and can be handled by the firm’s information systems specialists, and whether the organization can handle the changes introduced by the system.

Normally, the systems analysis process identifies several alternative solu­tions that the organization can pursue and assess the feasibility of each. A writ­ten systems proposal report describes the costs and benefits, and the advantages and disadvantages, of each alternative. It is up to management to determine which mix of costs, benefits, technical features, and organizational impacts rep­resents 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 chosen system solution. 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 de­velops a detailed description of the functions that the new system must per­form. Faulty requirements analysis is a leading cause of systems failure and high systems development costs (see Chapter 14). A system designed around the wrong set of requirements will either have to be discarded because of poor per­formance or will need to undergo major modifications. Section 13-4 describes al­ternative 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.

2. Systems Design

Systems analysis describes what a system should do to meet information re­quirements, and systems design shows how the system will fulfill this objec­tive. 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 specifica­tions 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 ad­dress all of the managerial, organizational, and technological components of the system solution. Table 13.1 lists the types of specifications that would be produced during systems design.

Like houses or buildings, information systems may have many possible de­signs. Each design represents a unique blend of technical and organizational components. What makes one design superior to others is the ease and effi­ciency 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 accep­tance of the system. As we describe in Chapter 14, insufficient user involve­ment in the design effort is a major cause of system failure. However, some systems require more user participation in design than others, and Section 13-4 shows how alternative systems development methods address the user partici­pation issue.

3. 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 op­erational information system. These concluding steps consist of programming, testing, conversion, production, and maintenance.

3.1. 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 a software service provider, or out­sourcing firms that develop custom application software for their clients (see Section 13-4).

3.2. Testing

Exhaustive and thorough testing must be conducted to ascertain whether the system produces the right results. Testing answers the question: Will the sys­tem produce the desired results under known conditions? Some companies are starting to use cloud computing services for this work.

The amount of time needed to answer this question has been traditionally un­derrated in systems project planning (see Chapter 14). 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 activi­ties: 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, by 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 ca­pabilities, 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 13.5 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.

3.3. Conversion

Conversion is the process of changing from the old system to the new sys­tem. 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 func­tions 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 intro­duced by function, 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 unit, corporate headquarters might be converted first, followed by outlying op­erating 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 de­velopment process is very important.

3.4. 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 orig­inal objectives and to decide whether any revisions or modifications are in order. In some instances, a formal post-implementation 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 require­ments, or improve processing efficiency are termed maintenance. Routine maintenance consumes a large percentage of many firms’ IT budgets, but could be reduced significantly through more up-to-date systems-building practices and technology. Table 13.2 summarizes the systems development activities.

Source: Laudon Kenneth C., Laudon Jane Price (2020), Management Information Systems: Managing the Digital Firm, Pearson; 16^th edition.