Construct, Deliver and Maintain Systems Project:In-House Systems Development.

In-House Systems Development

Organizations usually acquire information systems in two ways: (1) they develop customized systems in- house through formal systems development activities and/or (2) they purchase commercial systems from software vendors. Numerous commercial vendors offer high-quality, general-purpose information systems. These vendors primarily serve organizations with generic information needs. Typically, their client firms have business practices so standardized that they can purchase predesigned information systems and employ them with little or no modifications. However, many organizations require systems that are highly tuned to their unique operations. These firms design their own information systems through in- house systems development activities.

Although each approach has advantages and disadvantages, they are not mutually exclusive options.

A firm may satisfy some of its information systems needs by purchasing commercial software and developing other systems in-house. This section is concerned with the in-house systems development component of Figure 14-1.

TOOLS FOR IMPROVING SYSTEMS DEVELOPMENT

Systems development projects are not always success stories. In fact, by the time they are implemented, some systems are obsolete or defective and must be replaced. Estimates hold that up to 25 percent of all systems projects fail. That is, they are terminated prematurely and never implemented, or they must be redesigned within 6 months of implementation. Historically, three problems that account for most systems failures have plagued the SDLC.

1. Poorly specified systems requirements. Systems development is not a precise science. The process involves human communications and the sharing of ideas between users and systems professionals. This information exchange is often imperfect. Mistakes are made in identifying problems and needs, new ideas emerge as the true nature of the problem unfolds, and people simply change their minds about what they really want and need from the system.

Because of this uncertainty, the SDLC tends not to be a smooth, linear process, where one stage is completed before the next one begins. In reality, the process is iterative or cyclical. For example, it is not uncommon for a systems designer to return to the analysis stage from the construct stage to gather additional information as his or her perception of the problem changes.

The cyclical nature of this process results in time-consuming false starts, much repeated work, and pressure from all fronts to get the job done. Too often, the result is a system that is poorly designed, over budget, and behind schedule.

2. Ineffective development techniques. The problems cited in the preceding section are amplified by ineffective techniques for presenting, documenting, and modifying systems specifications. In the worst-case scenario, systems development tools are simply paper, pencils, rulers, templates, and erasers. The use of computer-based graphics software that permits original designs and changes to be made electronically considerably improves the situation. Nevertheless, days or even weeks of work may need to be redone because of a change in a system’s specifications.

3. Lack of user involvement in systems development. The major cause of systems failure is the lack of end- user involvement during critical development stages. At one time, computer systems development was thought to be the exclusive domain of the systems professionals. During this period, users (including accountants) abdicated their traditional responsibility for systems design. Too often, this led to business problems because system designs reflected the analyst’s perception of information needs rather than the perception of accountants and other users. Systems often lacked adequate controls and audit trails.

Today we recognize that user involvement in a system’s development is the key to its ultimate success. However, achieving competent user involvement is still difficult to accomplish. There are two reasons for this: (1) users tend to become discouraged when they discover the amount of time they must actually invest and (2) communication between end users and systems professionals is generally not fluent. It is often said that these groups speak different languages. Each tends to resort to its own jargon when communicating with the other. Therefore, much time is spent identifying user problems and needs and formulating acceptable solutions. Miscommunications between users and systems professionals lead to mistakes that, sometimes, are discovered too late.

These problems have led researchers to seek ways to improve the development process. The focus of this effort has been on techniques to reduce development time, facilitate better information transfer, en- courage user involvement, and improve overall systems quality. Several widely used techniques for improving systems development are reviewed in the following section.

Prototyping

Prototyping is a technique for providing users a preliminary working version of the system. The proto- type is built quickly and inexpensively with the intention that it will be modified. The objective of this technique is for the prototype to represent ‘‘an unambiguous functional specification, serve as a vehicle for organizing and learning, and evolve ultimately into a fully implemented’’ system.1 As the users work

with the prototype and make suggestions for changes, both they and the systems professional develop a better understanding of the true requirements of the system.

Reducing its features to the essential elements keeps the costs of a prototype model low. For example, the prototype system will not contain the complex code necessary to perform transaction validation, exception-handling capabilities, and internal controls. Typically, prototypes are limited to user input screens, output reports, and some principal functions.

When incorporated in the front-end stages of the SDLC, prototyping is an effective tool for establishing user requirements. Once these are obtained, the prototype is discarded. This throwaway prototyping is used for developing structured applications, such as accounting systems.2 An alternative technique con- tinues the prototyping process until the system is completed. This approach is used for developing decision support systems and expert systems. Figure 14-2 illustrates the prototyping model.

The CASE Approach

Computer-aided software engineering (CASE) technology involves the use of computer systems to build computer systems. CASE tools are commercial software products consisting of highly integrated applications that support a wide range of SDLC activities. This methodology was developed to increase the productivity of systems professionals, improve systems design quality, and expedite the SDLC.

Most CASE products comprise both upper and lower tools or applications. Upper CASE tools support the conceptual activities of analysis and design. Lower CASE tools support the physical activities associated with application programming and system maintenance. CASE tools are used to define user requirements, create physical databases from conceptual entity relationship (ER) diagrams, produce system design specifications, automatically generate computer program code, and facilitate the maintenance of programs that both CASE and non-CASE techniques create. Figure 14-3 illustrates the CASE spectrum of tools as they apply to various stages in the SDLC. The appendix to this chapter presents more detailed discussion of CASE features.

PERT Chart

The project evaluation and review technique (PERT) is a tool for showing the relationship among key activities that constitute the construct and delivery process. Figure 14-4 presents a PERT chart for a hypothetical project. The principal features of this diagram are:

1. Activities—the tasks to be completed in the project. These are labeled (and lettered A through L) on the lines, along with the time estimate for their completion. For example, the process design activity (C) is estimated to take 4 weeks.

2. Events—mark the completion of one activity and the beginning of the next. The events in this diagram are numbered 1 through 9.

3. Paths—routes through the diagram that connect the events from the first to the last.

4. Critical path—the path with the greatest overall time. The critical path in this project is C-F-G-J-L, with a total time of 20 (4 þ 5 þ 3 þ 4 þ 4) weeks. Any time delays in the activities along this path will extend the overall project time, which is why this path is critical.

Gantt Chart

The Gantt chart is a horizontal bar chart that presents time on a horizontal plane and activities on a vertical plane. Figure 14-5 illustrates a Gantt chart for the same project that the PERT chart represents in Figure 14-4. A bar marking its starting and ending dates represents the time associated with each activity. The Gantt chart is popular because it can show the current status of the project at a glance. By comparing projected time and work completed to date, we can see which projects are on, ahead of, or behind schedule.