Custom Search

Popular Posts

Friday, April 11, 2014


Information Systems Life Cycle can be divided into three broad categories. 

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, and production and maintenance. 

1. Programming

The process of translating design specifications into software for the computer constitutes a smaller portion of the systems development cycle than design and perhaps the testing activities. But it here, in providing the actual instructions for the machine, that the heart of the system takes shape. During the programming stage, system specifications that were prepared during the design stage are translated into program code. On the basis of detailed design documents for files, transaction and report layouts, and other design details, specifications for each program in the system are prepared. 

EvoWP has an incredible listing of single page wordpress themes that's worth checking out. This is a list of only the very best premium themes around and it's frequently updated.
Some systems development projects assign programming tasks to specialists whose work consists exclusively of coding programs. Other projects prefer programmer/ analysts who both design and program functions. Since large systems entail many programs with thousands – even hundreds of thousands – of lines of code, programming teams are frequently used. Moreover, even if an entire system can be programmed by a single individual, the quality of the software will be higher if it is subject to group review. 

2. 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. As much as 50 per cent of the entire software development budget can be extended in testing. Testing is also 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. Yet the risks of glossing over this step are enormous. 

Testing information system can be broken down into three types of activities: Unit testing, or program testing, consists of testing each program separately in the system. While it is widely believed that the purpose of such testing each program separately in antee that programs is error free, 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 pinpointed, problems can be corrected. 

System testing the functioning of the information system as a whole. It tries to determine if discrete modules will function together as planned and whether discrepancies exist between the ways the system actually works and the way it was conceived. Among the areas examined are performance times, capacity for the 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. 

It is essential that all aspects of testing be carefully thought out and that they be as comprehensive as possible. To ensure this, the development team works with users to devise a systematic test plan. The test plan includes all of the preparations for the series of tests previously described. 

The general condition being tested here is a record change. The documentation consists of a series of test-plan screens maintained on a database (perhaps a microcomputer database) that is ideally suited to this kind of application. 

Users play a critical role in the testing process. They understand the full range of data and processing conditions that might occur within their system. Moreover, programmers tend to be aware only of the conditions treated in their programs; the test data they devise are usually too limited. Therefore, input from other team members and users will help ensure that the range of conditions included in the test data is complete. Users can identify frequent and less common transactions, unusual conditions to anticipate, and most of the common types of errors that might occur when the system is in use. User input is also decisive in verifying the manual procedures for the system. 

3. Conversion

Conversion is the process of changing from the old system to the new system. It answers the question, “Will the new system work under real conditions?” 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 even to 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 replaced the old system entirely with the new system on an appointed day. At first glance, this strategy seems less costly than parallel conversion strategy. However, it is a very risky approach that can potentially be more costly than parallel activities 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 only to 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 outlaying operating units four months later. 

A formal conversion plan provides a schedule of all the activities required to install the new system. The most time-consuming activity is usually the conversion of data. Data from the old system must be transferred to the new system, either manually or through special conversion software programs. The converted data then must be carefully verified for accuracy and completeness. 

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. 

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, 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 will review the system. Changes in hardware, software, documentation, or improve processing efficiency are termed maintenance. 

Studies of maintenance have examined the amount of time required for various maintenance tasks. Approximately 20 per cent of the 20 per cent 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 recording system components for greater processing efficiency. The amount of work in the third category of maintenance problems could be reduced significantly through better system analysis and design practices. 


Blog Widget by LinkWithin