TRADITIONAL SYSTEM LIFE CYCLE

The goal of the Traditional System Life Cycle is to keep the project under control and assure that the information system produced, satisfies the requirements. The traditional system life cycle divides the project into a series of steps, each of which has distinct deliverables, such as documents or computer programs. This is known as the Systems Development Life Cycle (SDLC). The deliverables are related because each subsequent step builds on the conclusions of previous steps. Some deliverables are oriented toward the technical staff, whereas others are directed toward or produced by users and mangers. The latter ensure that users and their management are included in the system development process.                                

Although there is general agreement about what needs to be done in the traditional system life cycle, different authors name individual steps and deliverables differently. Many versions of the traditional system life cycle emphasize the building or software and de-emphasize what happens in the organization before and after software development. Because this article is directed at business professionals, its version of the traditional system life cycle emphasizes implementation and operation in the organization in addition to software development. 

The Four Phases of Traditional System Life Cycle are (Visit Table-I ):

1.   Initiation

2.   Development

3.   Implementation

4.   Operation and Maintenance 

Table-I : Phases and Steps of Traditional System Life Cycle

how we can see that Nova BBom comes back to work

1.  Initiation

The initiation phase may begin in many different ways. A user may work with the IS staff to produce a written request to study a particular business problem. The IS staff may discover an opportunity to use information systems beneficially and then try to interest users. A top manager may notice a business problem and ask the head of IS to look into it. A computer crash or other operational problem may reveal a major problem that can be patched temporarily but requires a larger project to fix it completely. Regardless of how this phase begins, its goal is to analyze the scope and feasibility of a proposed system and to develop a project plan. This involves two steps, the feasibility study and project planning, which produce the functional specification and a project plan. The feasibility study is a user-oriented overview of the proposed information system’s purpose and feasibility. A system’s feasibility is typically considered from economic, technical, and organizational viewpoints.  

-Economic feasibility involves question such as whether the firm can afford to build the information system, whether its benefits should substantially exceed its costs, and whether the project has higher priority than other projects that might use the same resources.

-Technical feasibility involves question such as whether the technology needed for the information system exists and whether the firm has enough experience using that technology.

-Organizational feasibility involves questions such as whether the information system has enough support to be implemented successfully, whether it brings as excessive amount of change, and whether the organization is changing too rapidly to absorb it. 

If the information system appears to be feasible, the initiation phase produces a functional specification and a project plan. The functional specification explains the important of the business problem; summarizes changes in business processes; and estimates the project’s benefits, costs, and risks. The project plan breaks the project into sub-projects with start and completion times. It also identifies staffing, resource requirements, and dependencies between project steps. The functional specification is approved by both user and IS personnel. It clarifies the purpose and scope of the proposed project by describing the business processes that will be affected and how they will be performed using the system. 

Functional specifications once consisted primarily of prose. With the advent of diagramming tools such as data flow have become much easier to read and understand. These visual representations help parts of the system will play. Functional specifications typically do not explain exactly what data, reports, or data entry screens will be included. This more detailed description is produced in the development phase. 

2.  Development

The development phase creates computer programs (with accompanying user and programmer documentation) plus installed hardware that accomplishes the data processing described in the functional specification. This is done through a process of successive refinement in which the functional requirements are translated into computer programs and hardware requirements. The purpose of the various steps and deliverables in the development phase is to ensure that the system accomplishes the goals explained in the functional specification.  

The first step in the development phase is the detailed requirements analysis, which produces a user-oriented description of exactly what the information system will do. This step is usually performed by a team including user representative and the IS department. 

It produces a document called the external specification. Building on the functional specification, the external specification shows the data input screens and major reports and explains the calculations that will be automated. It shows what information system users will see, rather than explaining exactly how the computer will perform the required processing. Users reviewing this document focus on whether they understand the data input screens, reports, and calculations, and whether these will support the desired business process. By approving the external specification, the users and IS staff signify their belief that the information system will accomplish what they want. 

The next step is internal system design, in which the technical staff decides how the data processing will be configured on the computer. This step produces the internal specification, a technical blueprint for the information system. It documents the computer environment the system will operate in, the detailed structure and content of the database, and the inputs and outputs of all programs and subsystems. Users do not sign off on the internal specification because it addresses technical system design issues. Instead, the IS staff signs off that the internal specification accomplishes the functions called for in the external specification the users have approved.  

Thus far the discussion has focused on software. Because the software will work only if there is hardware for it to run on, and essential step in the development phase is hardware acquisition and installation. For some information systems, this is not an issue because it is a foregone conclusion that existing hardware will be used. Other systems require a careful analysis to decide which hardware to acquire, how to acquire it most economically, where to put it, and how to install it by the time it is indeed. Factors considered in hardware acquisition decisions include compatibility with existing hardware and software, price, customer service, and compatibility with long-term company plans. Computer hardware can be purchased or rented through a variety of financing arrangements, each with its own tax consequences. A firm’s finance department usually makes the financing arrangements for significant hardware purchases. Especially if new computer hardware requires a new computer room, lead times for building the room, installing the electricity and air conditioning, and installing the computer may be important factors in the project plan. 

In firms with large IS staffs; users rarely get involved with the acquisition, installation, and operation of computer hardware. Much as with telephone systems, users expect the hardware to be available when needed and complain furiously whenever it goes down. This is one reason computer hardware managers sometimes consider their jobs thankless. 

Programming is the creation of the computer code that performs the calculations, collects the data, and generates the reports. It can usually proceed while the hardware is being acquired and installed. Programming includes the coding, testing, and documentation of each program identified in the internal specification. Coding is what most people think of as programming. The testing done during the programming step is often called unit testing, because it treats the programs in isolation. The documentation of each program starts with the explanation from the internal specification and includes comments about technical assumptions made in writing the program, plus any subtle, non-obvious processing done by the program. 

A number of improvements in programming methods have made programming faster and more reliable. Structured programming is often used to make the programs more consistent, easier to understand and less error prone. Fourth Generation Languages (4GLs) also expedite programming for some systems. However, as should be clear from all of the steps leading up to coding and following coding, coding often accounts for less than 20% of the work in developing a system. This is one of the reasons 4GLs and other improved programming tools do not drastically shrink the system life cycle for large systems, even when they slash programming time. 

Documentation is another activity that can proceed in parallel with programming and hardware acquisition. Both user and technical documentation is completed from the material that already exists. The functional specification and external specification are the basis for the user documentation, and the internal specification and program documentation are the basis for the programmer documentation. With the adoption of Computer Aided Software Engineering (CASE) tools, more of the documentation is basically a compilation of data and diagrams already stored on a computer. Additional user documentation is usually required, however, because different users need to know different things depending on their roles. People who perform data entry tasks need to understand the data entry procedures and what the data mean; people who use data from the system need to understand what the data mean and how to retrieve and analyze data, but do not need to know much about data entry details.

After the individual programs have been tested, the entire information system must be tested to ensure that the programs operate together to accomplish the desired functions. This is called the system testing, or integration testing. System tests frequently uncover inconsistencies among programs as well as inconsistencies in the original internal specification. These must be reconciled and the programs changed and retested. One of the reasons for Microsoft’s “synch and stabilize” method is to eliminate the surprises and extensive network that might occur if system testing showed that programs were incompatible. Although system testing may seem an obvious requirement, inadequate system testing has led to serious problems. For example, a new trust accounting system put into operation prematurely by Bank of America on March 1, 1987, lost data and fell months behind in generating statements for customers. By January 1988, 100 institutional customers with $ 4 billion in assets moved to other banks, several top executives resigned, and 2.5 million lines of code were scrapped. 

An important part of testing is the creations of a testing plan, a precise statement of exactly how the information system will be tested. This plan includes the data that will be used for testing. Creating a testing plan serves many purposes. It encourages careful thought about how the system will be tested. In addition, a thorough plan increases the likelihood that all foreseeable contingences will be considered and that the testing will catch more of the bugs in the system. 

It should be clear that the development phase for a large information system is a complex undertaking, quite different from sitting down at a personal computer and developing a small spreadsheet model. Explicitly separating out all the steps in the development phase helps to ensure that the information system accomplishes the desired functions and is debugged. Such an elaborate approach is needed because the system is a tool of an organization rather than an individual. An individual producing a spreadsheet is often typing to solve a current problem with no intention to use the spreadsheet next month, much less that someone else will need to decipher and modify it next year. In contrast, the traditional system life cycle assumes that the information system may survive for years, may be used by people who were not involved in its development, and may be changed repeatedly during that time by people other than the original developers. The steps in the traditional life cycle try to make the long-term existence of the information system as efficient error-free as possible. 

3.  Implementation

Implementation is the process of putting a system into operation in an organization. It starts with the end product of the development phase, namely, a set of computer programs that run correctly on the computer, plus accompanying documentation. This phase begins with implementation planning, the process of creating plans for training, conversion, and acceptance testing. 

The training plan explains how and when the user will be trained. The conversion plan explains how and when the organization will convert to new business processes. The acceptance-testing plan describes the process and criteria for verifying that the information system works properly in supporting the improved work system.  

Training is the process of ensuring that system participants know what they need to know about both the work system and the information system. The training format depends on user backgrounds and the purpose and features of both the work system and the information system. Users with no computer experience may require special training. Training for frequently used transaction processing systems differs from training for data analysis systems that are used occasionally. Information systems performing diverse functions require more extensive training than systems used repetitively for new functions. Training manuals and presentations help in the implementation system. After the previous methods have receded into history, other types of training material are more appropriate. 

Following the training comes the carefully planned process of conversion from the old business processes to new ones using the new information system. Conversion is often called cutover or changeover. It can be accomplished in several ways, depending on the nature of the work and the characteristics of the old and new systems. One possibility is to simply choose a date, shut off the old information system, and turn on the new one while hoping that the work system will operate as intended. This is risky, though, because it does not verify that the information system will operate properly and that the users understand how to use it. 

Consider the following example: The State of California installed an optical disk system to streamline the process of doing title searches (establishing ownership and identifying indebtedness on a property) for borrowers who wished to purchase property. Previously, there was a 2 to 3 week delay between the borrower’s loan request and the bank’s receipt of a confirmation that the title was clear. The new system was to reduce this delay to 2 days. Both the vendor and several state officials recommended that the existing manual system remain in full operation during the conversion in case of problems. However, the Secretary of Finance rejected the request for an additional $2.4 million, and the manual system was simply shut down when the optical disk system came up. Unfortunately, software bugs plagued the new system, and the resulting logjam of 50,000 loan requests delayed title searches for up to 10 weeks. The new system was shut down for repair, and the old manual system reinstated. The Assistant Secretary of State said that some banks almost went out of business because of the slow turnaround. 

To minimize risk and wasted effort, most conversions occur in stages, which can be done in several ways. A phased approach uses the new information system and work system for a limited subset of the processing while continuing to use old methods for the rest of the processing. If something goes wrong, the part of the business using the new system can switch back to the old system. The simultaneous use of the old system and the new system is called running in parallel. Although this involves double record keeping for a while, it verifies that the new information system operates properly and helps the users understand how to use it effectively within the new work system. 

Conversions from one computerized system to another are often far more difficult than users anticipate. Part of the problem is that computerized data in the old system must be converted into the formats used by the new system. In consistencies between the two systems frequently lead to confusion about whether the data in either system are correct. Furthermore, programs that convert the data from one system to another may have their own bugs, thereby adding to confusion and delays. 

Conversion requires careful planning because people who don’t want the new system and use the problems as an opportunity to complain can blow even minor problems out of proportion. For these reasons, it is often wise to do a pilot implementation with a small group of users who are enthusiastic about the system improvements. Ideally, their enthusiasm will motivate them to make the effort to learn about the changes and to forgive minor problems. After a pilot implementation demonstrates that the new information system works, it is usually much easier to motivate everyone else (including the skeptics) to start using it. 

Acceptance testing is testing of the information system by the users as it goes into operation. Acceptance testing is important because the information system may not fit, regardless of what was approved and signed off in the external specification. The business situation may have changed; the external specification may reflect misunderstandings; the development process may have introduced errors; or the implementation may have revealed unforeseen problems. For all these reasons, it makes sense to include an explicit step of deciding whether the information system is accepted for ongoing use. If it doesn’t fit user needs, for whatever reason, installing it without changes may lead to major problems and may harm the organization instead of helping. Acceptance testing also solidifies user commitment because it gets people in the user organization to state publicly that the system works.  

The post-implementation audit is the last step in the implementation phase, even though it occurs after the new system has been in operation for a number of months. Its purpose is to determine whether the project has met its objectives for costs and benefits and to make recommendations for the future. This is also an opportunity to identify what the organization can learn from the way the project was carried out. 

4.   Operations and Maintenance 

The operation and maintenance phase starts after the users have accepted the new system. This phase can be divided into two activities: (1) ongoing operation and support, and (2) maintenance. Unlike the other steps in the life cycle, these steps continue throughout the system’s useful life. The end of a system’s life cycle is its absorption into another system or its termination. 

Ongoing operation and support is the process of ensuring that the technical system components continue to operate correctly and that the users use it effectively. This process is similar to the process of making sure a car or building operates well. It works best when a person or group has direct responsibility for keeping the information system operating. This responsibility is often split, with the technical staff taking care of computer operations and a member of the user organization ensuring that users understand the system and use it effectively. 

Day-to-day computer operations typically include scheduled events such as generating summary reports from management and backups of the database. The operations manual specifies when these jobs should be done. For transaction processing systems essential to the operation of the business, a member of the technical staff also monitors computer-generated statistics related to response times, program run times, disk space utilization, and similar factors to ensure the programs are running efficiently. 

When the database becomes too full, or when response times start to increase, the technical configuration of the information system must be changed. This is done by allocating more disk space, unloading (backing up onto tape or discarding) data that are not current, or changing job schedules. 

Maintenance is the process of modifying the information system over time. As users gain experience with a system, they discover its shortcomings and usually suggest improvements. The shortcomings may involve problems unrelated to the information system or may involve ways that the information system might do more to support the work system, regardless of the original intentions. Some shortcomings are bugs. Important shortcomings must be corrected if users are to continue using an information system enthusiastically. 

Handling enhancement requests and bug fix requests is both a technical challenge and a delicate political issue for IS departments. The technical challenge is ensuring that changes don’t affect other parts of the system in unanticipated ways. The traditional life cycle helps here because documentation and internal design methods enforce modularization and make it easier to understand the scope and impact of changes. 

The political issue for most IS departments are their inability to support even half of the enhancement requests they receive. For new or inadequately planned information systems, some departments have more enhancement requests than they can even analyze. In this environment, it requires both technical and political skill to keep users satisfied. Users are often frustrated by how long it takes to make changes. 

What might seem to be a simple change to a person who “programs” spreadsheet is often vastly more complex in a large information spawn changes in several levels of documentation. 

The steps in each of the four phases of the traditional system life cycle have now been introduced. Table -1 outlines above the steps in each phase and makes two major points in addition to the details it presents. First it shows that users are highly involved in three of the four phases. In other words, building information systems is not just technical work done by the technical staff. It also shows that each step has specific deliverables that document progress to date and help keep the project under control. 

The traditional system life cycle is a tightly controlled approach designed to reduce the likelihood of mistakes or omissions? Despite its compelling logic, it has both advantages and disadvantages. Adherence to fixed deliverables and signoffs improves control but guarantees a lengthy process. Having specific deliverables due at specific times makes it schedule of deliverables sometimes takes on a life of its own and seems as important as the real project goals. 

When merely going through the motions of producing deliverables on schedule, participants may be tempted to turn in work that is incomplete and to approve documents they do not truly understand.

The traditional system life cycle is the standard against which other approaches are compared. Project managers who want to bypass some of its steps still need a way to deal with the issues they raise.