SYSTEM ANALYSIS AND DESIGN (SAD) NOTES

SYSTEMS ANALYSIS AND DESIGN

SYSTEM ANALYST.

He is described as an agent of change.  An agent of change is a person who conceives of new ideas or technology and influences other people to adopt the new idea, innovation or change.

ROLE OF SYSTEM ANALYST AS AN AGENT OF CHANGE.

1. Acts as a catalyst – he provides an opportunity for users to examine closely the job functions and use of the system, in order to determine how the system will adequately solve their problems.
2. Acts as an adviser. He is an adviser to the users about what can be done and not be done by a computer system.
3. Acts as an educator. In most cases the analyst will be dealing with people with little knowledge about computers.  He therefore has to educate them and encourage participation of users during information systems development.
4. Acts as a salesman. The system analyst attempts to sell his ideas at every stage of the system development cycle.  He tries to convince users that the new system will work and will be on improvement to the current working methods and procedures and will benefit the organization.

5          He acts as a detective i.e one whose primary task is to uncover the facts of an event and determine the responsibility of event.

6. He acts as puzzle solver i.e One who either puts things together from component pieces or determines solution from clues and hints.
7. Acts as Indian Scout i.e one is usually first on the scene and who looks for hidden dangers as for the correct path through the wilderness of the corporate environment. He also be the person who finds hidden dangers first and draws the preventive move first.
8. He acts as a reporter as well as an artist. He has a vast knowledge and experience in system development.

BENEFITS OF USING AN EXTERNAL SYSTEM ANALYST

( OUT SOURCED SYSTEM ANALYST ).

1. The cost can be controlled, since he is paid on the basis of work done or performance.
2. He is unlikely to be influenced by organizations internal politics and he is independent.
3. It saves an organization the trouble associated with administration of full time employees.

(system analyst).

4. It saves an organization the cost of hiring and maintaining a full time analyst.
5. He is likely to bring up new ideas gathered din other developed systems elsewhere.
6. He is likely to be listened to since naturally people are ready to listen/talk to visitors rather than ordinary people they are used to.

QUALITIES OF GOOD SYSTEM ANALYST.

1. Should be properly trained with at least a degree in computer science.
2. He should have good communication skills i.e writing and verbally.
3. He should be independent/self-reliant.
4. Should be creative.
5. Should be analytical.
6. Should be experienced.
7. Should be patient.

System development methods.

There are several methods of system development e.g:

1. System Development Life Cycle (SDLC)
2. Structured System Analysis Design methods (SSADM) method.
3. Prototyping method.
4. Rapid Application Development (RAD) etc.

 

System development life cycle

SDLC also known as traditional system development method or function driven method or Process Driven method.  The method requires the analyst to follow a sequence of phases during the development and implementation of an information system.  This involves various people and is described as information system development project.

The following are the System Development cycle phases/stages.

1. Preliminary survey/study (problem definition)
2. Feasibility study.
3. Facts finding, Recording and Analysis.
4. System design.
5. System development/Production.
6. System implementation.
7. Post implementation Review and Maintenance.

PRELIMINARY STUDY.

This stage involves determination of whether there is need to change the existing system of business procedures.  It may require management requests for a change of the existing system to give an organization a competitive advantage or to improve the staff morale.

Professionals

The user department should be involved during the definition of the problem.  The problem to be solved should be very specific, clear and precise.  It should not be too broad to cause ambiguities in its solution.

Objectives of preliminary study:

1. To understand organizational characteristics and its objectives.
2. To understand organizational structure.
3. To identify organizational missions and collect relevant data or documents regarding

organizational information.

4. To develop a brief and accurate problems statement usually known as system term ofreference (T.O.R)

TERMS OF REFERENCE

It’s a documentation prepared by steering committee to act as a reference document throughout system development stages.

Contents

1. Project title.
2. Subject of study.

• Purpose of study

1. Sections affected or involved during the system implementation.

• Available resources and constraints, the analyst, the project leader should consider.
• The projects estimated duration or schedule.

Steering committee.

It’s formed by 2 or 3 people to oversee the system development project from its initiation to its completion.  It comprises of system analyst as the leader of the project and a representative of the user department.  They should understand all processing objectives and procedures within the affected department.  A management representative and accountant or auditors may be incorporated to advise initially on financial aspects on the project.

Functions of the steering committee.

1. a) To study the current processing procedures that may require to be improved.
2. b) To prepare problem statement inform of terms of reference.
3. c) To co-ordinate system development activities throughout development life cycle.
4. d) To interface the project development team with organizational management.
5. e) Te resolve conflict that may arise during system development.
6. f) To direct, control and monitor the system development progress.

FEASIBILITY STUDY.

This is a more detailed study carried out by feasibility study team.  Its purpose is to define the problem and decide whether or not a new system to replace the existing one is viable or feasible.

During the study the analyst should assess the magnitude of the problem and attempts to restrict or

at least identify the scope of the project.

The analyst must list precisely the problems of the current system and indicate what would be required of the new system.  He must identify alternative solutions to the problems and recommend the most cost-effective solution. and recommend the most cost-effective solution.

Feasibility study activities:-

1. Identification of main characteristics of the existing system.
2. Determination of the main output requirements.
3. Considerations of alternative ways of meeting similar requirements.
4. Preparation of gross estimates of developments, implementation and operation cost for

each probable alternative solution.

5. Documentation of the study i.e writing of feasibility study report.
6. Preparation of gross estimates of possible direct and indirect benefits for each probable alternative solution.

♦ The following are areas of feasibility study.

1. Technical Terms (Technical feasibility.
2. Operational Terms (Social feasibility).
3. Economical Terms (Economical feasibility).
4. Legal Terms (Legal feasibility).

TECHNICAL FEASIBILITY.

Technical questions are those that deal with equipment and software e.g determination of whether the new study can be developed using the current facilities within the company.

Technical feasibility is thus aimed at evaluation of the following: 

(i)         The hardware required for the new system.

(ii)        The software required for the new system after its implementation.

• Determination of whether the current facilities are adequate or inadequate for the new system after implementation.

(iv)       Evaluation of the current technology and how applicable it is to the new system.

(v)        Determination of the need for telecommunication equipment in the new system to improve both data capture and preparation activities.

(vi)       The inputs, outputs, files and procedures that the proposed system should have as compared to the input, outputs, file and procedures for the current system.

(vii)      Determination of whether training is necessary for the employees before the new system is implemented and the relevant skills required.

(viii)      Suggesting suitable method of developing the new systems, methods of running it when it becomes operational and ways of implementing it.

SOCIAL FEASIBILITY.

Operational feasibility also known as social feasibility mostly deals with the effect of the system on the current society within the company.

It’s carried out on the following areas:

1. I) The reaction of individuals both inside and outside the company as a result of the new system.

2)         The effect of the system on the existing organizational structure.

3)         The effect of the system on the current working practices and management levels i.e whether there would be any change required and if so, the cost of the change socially.

4)         Redundancy or retrenchment, implication to the company as a result of the new system.

5)         Implication of the system on existing staff development programmers.

 

The social feasibility is carried out along with Technical feasibility such that every alternative technical solution to the problem that emerges its social implication must be evaluated.  Areas to consider include:

Group relationships, salary levels, authority levels, job titles and job descriptions etc.  Social cost to be evaluated e.g cost of user training consultancy that may be engaged during development pf the new system, job improvement and salary changes.

legal FEASIBILITY.

Managers may wish to know the effect of uncertainty on an investments appraisal.  The following are ways in which risks can be taken into account when making a capital investment decision i.e

1. i) Set a short pay back period. If the risk is deemed to increase with the length of time then a short pay back period tends to reduce the risks.
2. ii) Use a higher discount rate – This is called adding a risk premium. If its considered to be

fairly risky to undertake a project, then say 2% could be added to the basic cost of

capital.  If its considered to be very risky to undertake a project then 5% could be added.

iii)         Undertake sensitivity analysis – This involves asking a series of “what if” questions and reevaluating the projects with assumptions e.g A manager might ask “what if” the sales are 5% lower than that expected.  He should evaluate this to see how sensible the final results would be affected by the change.  By carrying out a series of sensitivity analysis, its possible to highlight the outcome of a project.

Feasibility study report:

After the feasibility study and the cost benefit appraisal, a report is prepared that gives the recommendation on whether or not to commit any further resources on the projects.

Contents of feasibility study:

2. Introduction – It gives general description of the existing system, the people contacted during the study and the purpose of the report.
3. Description of the alternative proposed systems, in terms of the inputs, outputs, file processed, response time etc.
4. Quantification to justify the cost of running the proposed system.
5. The recommendation by the analyst on the most cost effective alternative solution.
6. The author of the report.
7. System analyst recommendation of the new system should indicate whether to commit further resources “continue with the project” or to abandon it.  If to continue with the project then, its development plan should be given.

The report is submitted to the management for approval.  After approval a more detailed survey is conducted on the existing system mostly to establish its weakness and strength. This is called fact finding or fact gathering.

fact – finding/investigation.

It involves collection of information about the existing system on which to base analysis in order to determine whether user’s current needs are being met.  The following are some of the activites that are looked at:

• a. Functional requirements: – the requirement should be established and whether they are achieved.

• Determination of proposed system requirements: – This is necessary as it may suggest a change in the existing system requirement.

• Establish any weakness or problem associated with the present and working method and procedures.

• Determination of organizations growth rate. This will assist in determination of the growth of volume of transaction to be processed.

• Determination of the organization structure, objective and the cost associated with the present system.

 

Occasions of fact-finding:

Facts may be gathered at the following stages of SDLC

▪           Preliminary study stage where the analyst learns and understands the existing information System.

▪           Feasibility study stage the analyst collects facts about user references, priorities and inputs methods.  Also gathered are fact about technical solution and operational implications of the proposed system.  This enables the analyst to select the most appropriate and cost-effective alternative solution to the problem.

▪           Design stage where the analyst gathers facts, about suitable terminals, dialogue, report formats, operations proposed systems.

▪           At the past implementation stage, where facts are gathered to establish the success of the implemented system in terms of user’s satisfaction, improved response times, ease of use

etc.

♦ Fact-finding comprise of 3 activites i.e

1. Fact-gathering
2. Fact-recording
3. Fact-evaluation

Facts finding is done by use of the fact finding technique i.e use of questionnaires, interviews, observation, record inspection (research/document review) and sampling.  Facts are recorded or documented through the use of (procedure charts), decision tables/trees, grid charts, pseudo-codes etc.  Facts assessment or evaluation is done comparing the strength and weakness clearly implies or identified during fact-finding.

 ACT- FINDING TECHNIQUE:

USE OF QUESTIONNAIRE

A questionnaire is a special document that allows the analyst to ask a number of standard questions set to be asked a large number of people in order to gather information from them.

When it’s used:    – When the system analyst is located at a considerably long distance from the respondents.

– When there is a large number of respondents such that in interviewing them will be limited by time.

–  When the question to asked are simple and straight forward and require direct answers.

–  When limited information is required from a large number of people.

–  When it’s used as a means to verify facts found using other methods.

Advantages:   

▪           They provide a cheap means of gathering information/data from a large number of people.

▪           They encourage individuals to provide response without fear of intimidation or victimization.

▪           The respondents can complete the questionnaire at their own convenience with minimal or limited interruption of their work.

▪           Questions are presented consistently to all without bias.

Disadvantages:

▪           Response is often too slow since the respondents complete and return back the form at their own convenience.

▪           They don’t provide opportunity for respondents to obtain clarification of questions which may appear vague or ambiguous.

▪           Does not provide an opportunity for the analyst to observe respondents reaction.

▪           The design of the questionnaire require an expert who may change expensively and may not economical when used foe a small group of users.

▪           All forms may not be returned and also not all questions will be answered which lead to incomplete data for analysis.

 

Requirement for preparing a questionnaire.

♦          Questions should be simple and clear.

♦          The questions should be objectively oriented and one should avoid leading questions.

♦          The new systems legal implications should be evaluated e.g if it requires that the computer should be insured or whether the stored data should be registered with the government registrar before use.

♦          The copyright implication for restriction should be assessed before the new system is implemented.  Generally any legal aspects associated with the new system should be and adequate measures taken to protect the interest of the user company

 

ECONOMICAL FEASIBILITY

Economic feasibility is aimed at determination of whether or not to continue with the project depending on whether the project is economically viable.  The systems benefits and estimated implementation cost should be determined before any further resources can be sent on the project.

Coat Benefit Analysis (CBA) is carried out to determine whether the new system is economically viable.

COST/BENEFIT ANALYSIS

BENEFIT ANALYSIS

Benefit Analysis is obtained through comparison of the new a system and the existing system.  Benefits of the new system fall under 2 categories i.e Direct and Indirect Benefit i.e Tangible and Intangible benefits irrespectively.

Direct (Tangible)

They fall under 2 categories i.e Measurable benefits and Direct savings.

Measurable benefits   – Are those that can be quantified in monetary terms e.g increase in working capital as a result of purchasing of computer systems or reduction of delays in decision making which is obtained through improved procedures e.g invoicing procedures and credit control procedures.

Direct savings – Are the costs, reduced or eliminated as a result of introducing of computerized system “They include:

–           Reduction or elimination of clerical personnel.

–           Elimination of some specific costs e.g stationery cost etc.

Like measurable benefits, direct savings can be quantified in monetary terms.

 Intangible Benefits –

They are the benefits that cannot be quantified on monetary terms or those that are difficult or impossible to quantify in monetary terms.  They are clearly desirable but very difficult to evaluate in terms of money value.  Examples include improved customer satisfaction, better information, improved organizational image, increased staff morale, a competitive advantage to an organization etc.

COST ANALYSIS

Cost are expenses or expenditure which is reflected from the system. These may include:

Equipment cost, Development cost, Operation cost and Software cost.  During its analysis one should consider both the new and the existing system.

The cost of retaining and operating the existing system should be compared to the cost of introducing and running the computerized information system.  These costs fall under the following categories:

1. a) The cost of running the existing system. This is calculated from the past records.

The items to be considered include:

1. i)        Man power cost – Which is extracted from the budgets and payroll reports.
2. ii) Material cost – Which includes consumable e.g stationary, work in progress and current stock.

• Operational cost e.g the equipment cost expressed in terms of unit rate. Others to consider include the duration the project takes to be completed and initial replacement cost.

• Overhead costs – Which are direct expenses incurred by the company on behalf of all departments e.g rent. Electricity, telephone bills etc.  These can easily be extracted from departments or centres to which are allocated.

• The intangible cost of existing system e.g loss of sales or cost as a result of inappropriate stock levels or loss of interest in bank as a result of improper credit control system.

 

1. b) The cost of operating the proposed system. This is likely to include all the areas covered in (a) above i.e man-power, materials, overheads and intangible cost.  However, there are additional costs associated with computerized system e.g service contracts for the computer system, insurance of the computer system cost of data transmission, cost of

consumables like printer cartridges, ribbons etc.  All these should be evaluated as accurately as possible.

NB:      It is usual to add amounts relating to employees additional costs to the company e.g statutory deductions, medical covers, insurance covers, pension scheme contributions etc. This should be considered under manpower.

• The cost of new system development. This will include the cost incurred for any consultancy services that may have been hired during the development.  Allowances

given to the system development team members fall under this category.  Overall effects of the system development and implementation should be determined and any associated established.  The above estimated are based on both the time and activities involved in the project.  Staff training cost recruitment costs and retrenchment costs should be considered under system development cost.  It is advisable that the estimates on these costs be as accurate as possible although they may change at later stages during the development cycle.

Cost Benefit Analysis (CBA) should be conducted on each alternative solution to the problem.  This enables the analyst to make recommendation on a suitable cost alternative solution to the problem.

COST/BENEFIT ANALYSIS TECHNIQUES.

The techniques used in economical evaluation of a computer based information system are the same as those used in investment appraisal in other areas of commercial world.  These techniques tend to produce contradictory results and none of them is universally accepted.  Basically, these techniques are based on either marginal costing methods or life cycle costing method.  Marginal costing methods deals with snapshots of systems performance at a given point in time.

Lifecycle-costing methods deals with measuring system performance over its working life.

These techniques includes:

1. a) The ARR (Accounting Rate of Returns).
2. b) Pay back period.
3. c) Discounted cash flow – Net Present Value (NPV).

Internal Rate of Return (IRR).

Disadvantages of CBA (Cost Benefits Analysis):-

1. Difficult to consider all factors that might contribute cost or benefits yet the future is very uncertain.

2. It’s difficult to quantify some benefits e.g intangible benefits yet they are expected to be quantified.

TAKING ACCOUNT OF RISKS.

So far we have assumed that cash flows are known with certainty. It is more likely that there would be uncertainty in estimates particularly those focused or preferred for several years ahead.

• The questions should be logically organized.
• The form should be neat.

INTERVIEWING:

It is a direct face to face to face conversation between the system analyst (the interviewer) and uses (interviewees).  He obtains answers to questions he asks the interviewee.  He gets interviewees suggestions and recommendations that may assist during the design of the proposed system.

 

Purpose of the interviews

–           It acts as a method of fact-finding to gather facts about the existing system.

–           Used for verifying gathered facts through other methods.

–           Used for clarifying gathered facts through other methods.

–           Used to get the user involved in the development of the new system.

 

When to use interviewing

–           When the respondents are few e.g corporate managers.

–           When the respondents are physically available and accessible

–           When the main emphasis of system investigation is people.

–           When the analyst wishes to seek direct answers, opinions, suggestions and detailed information.

–           When the analyst wishes to verify validity of facts collected through other technique.

–           When immediate response is required.

Advantages

–           The analyst can frame questions differently, individuals depending on their level of understanding, thus it allows details facts to be gathered.

–           The analyst can observe non-verbal communication from the respondents or interviewees.

–           The response rate tends to be high.

–           It provides an immediate response.

–           The analyst can get detailed facts from each respondent.

 

Disadvantages

–           Its costly and time consuming when used on large number of people.

–           Its success highly depends on the analyst human relation skills, expertise and experience.

–           It may mot be practical due to location of the respondent.

–           It may make the respondents to feel that they are being summoned or grilled by analyst then fail to give adequate information.

–           Interviews fail when:

 

1. Ambiguous questions are asked.
2. When personal questions are asked.

• Inadequate time allocation for the exercise.

1. Lack of earlier preparation by both parties.
2. When the analyst is biased on using technical jargon.

 

OBSERVATION

Observation is the most effective fact-finding technique but requires the analyst to participate in performing some activities carried-out by user.

He may choose to watch them as they perform their activities and gather the facts intended.

When to use observation:

1. When validity of facts gathered through other method are questionable.
2. When complexity of certain aspects of a system prevent a clear explanation by the respondents of the user.

3. Used to confirm whether the procedures specified in the manuals are being followed.
4. When one needs to obtain first hand and reliable information.

 

Advantages

–           Data gathered is highly reliable thus the method can be used to verify facts collected through other methods.

–           The analyst can see what is being done clearly including the tasks which are difficult to explain clearly in writing or in words.

–           Inaccuracy or inaccurately described tasks can easily be identified.

–           It allows the analyst to easily compare gathered facts through other methods and what actually happened on the ground.

• It’s relatively cheap compared to other methods.

 

Disadvantages:

–           People feel uncomfortable when being observed and behave abnormally thus influence conclusion.

–           The exercise may take place at odd-times thus inconvenience those involved.

–           The analyst may observe exceptio0nal activities, leaving some critical areas his patience and expertise play a great role.

–           The tasks being observed may be interrupted and then analyst gather wrong facts.

 

Guidelines about observation

1. There should be permission from concerned authorities before the exercise.
2. Gathered fact should be recorded.
3. Those to be observed should be notified and the purpose of the exercise explained.
4. The analyst should be objective and avoid performed opinion. He should have an open-mind.

5. The analyst should record also ordinary events

RECORD INSPECTION /DOCUMENT REVIEW.

This method involves the perusing through literature or documents to gain a better understanding about the existing system.  Documents that are perused include sales.  Orders, job descriptions, existing system documentation, management reports, procedure manuals, organized structure charts, trade journals etc.

When to use these method:

1. When the analyst needs to have a quick overview of the existing system.
2. When the information required cannot be obtained through any other techniques.

Advantages    

1. It’s comparatively cheap than other techniques.
2. It’s a faster method of fact-finding especially when documents to be considered few.

Disadvantages

1. It could be time consuming if the documents are many or if they are not within the same locality.

2. The relevant document of perusing may not be available.
3. The success depends on the expertise of the analyst.
4. Most of the documents or information obtained may be outdated.

SAMPLING                 

Sampling is a systematic selection of representative elements of a population.  The selected elements are examined closely and the results assumed to reveal useful information about the entire population

When it is used:

–           When the target population is too large and its impractical to study every element of the population.

–           When the target population contains homogenous (elements with similar characteristics).

–           When the analyst wishes to get a large enough cross-section to determine what can happen to the system.

 

Advantages

• It reduces the cost e.g by avoiding to examine every document or talking to everyone in the organization gather facts.

• It speeds up fact-finding process.

iii.        It improves effectiveness since one can concentrate on few people and fewer documents and get adequate accurate information.

1. May reduce biasness, if representative sample is taken. All the elements of the population stands a chance of being selected.

Disadvantages

1. The sample may not be representative enough which leads to bias conclusion.
2. The expertise of the analyst are required since sampling involves a lot of mathematical computation.

FACT ANALYSIS         

A system analysis involves evaluation of the current system using the gathered facts or information.  One should evaluate whether the current and the projected user needs are being met.

If not, he should give a recommendation of what is to be done.

Analysis involves detailed assessment of the components of the existing system and the    requirements of the system.

The Objectives/aims of system – analysis

 

1. To determine information needs of an organization and the users of that information.
2. Determination of the current activities of the system i.e functions involved in conversion of inputs to outputs.

iii.        Determination of the intended systems output.

1. Determination of the resources required for the intended system.
2. Determine capabilities required in the system to meet information needs of the organization.

SYSTEM ANALYSIS ACTIVITIES 

1. Analysis of the organization environment. The analyst should evaluate in details information needs of the organization environment e.g information needs of the consumers, suppliers, competitors, government department etc.
2. Analysis of the present system. The analyst should study the current system in meeting the stated information needs.  This guides a decision to be made on whether the existing system stands to be improved, changed or done away with altogether.  Some aspects of the existing system that are examined includes: Input transactions, outputs or results, existing controls, or files, user interaction, methods procedures or function and any existing hardware or software.

 

3. Requirement analysis – which involves determination of user requirements e.g task performed, output expected, proposed system development cycle and user goals. Also determined should be

 

• Maximum, minimum and average levels of activities.
• Duplicated procedures e.g two people entering the same transaction but at different times.
• Labour intensive tasks – the tasks that are manual and can easily be computerized.
• Activities or tasks that involve complex or repetitive computation.
• Procedures that have become obsolete.

 

Once all the facts are analyzed and documented, a formal report is written called statement or requirements.

Contents of statement of requirements:

1. Description of the initial system goals whether or not they are being met and are still applicable.

2. Description of whether the existing the output is adequate, timely and well-controlled.
3. Description of whether files held are suitable for supporting current organization information requirements.

4. Description of whether files held are suitable for supporting current organization information requirements.

5. Description of whether current system input and whether or not they support current file maintenance activities.

6. Description of the existing system work-flow efficiency.
7. Description of any constraints within the system.
8. Description of any existing system equipment and procedures and controls that can be transferred to the system.

 

Importance of system analysis:

1. It helps the analyst or system developer to gain understanding of the existing system.
2. It allows the analyst or the system developer to record existing system information in a standard form to design of a new system.  It also facilitates understanding of the system by the user staff.

3. Enables the analyst or developer to define existing system procedure into a logical model.
4. Helps the analyst to write or produce statement of requirements which guides the development team throughout subsequent stages of the development life cycle.

 

DESIGN STAGE (SYSTEM DESIGN)

The system design objective is to put a logical structure of the real system in a form that can be interpreted by other people from the designer.  The analyst should derive a logical model of the way existing system works. This assumption that the existing system provides a good guide to what is required of a new system.  It should be different from the new system is to achieve the given requirement.

Limitations.

1. There could be come requirements of the new systems that are not currently being satisfied by the current system.  These requirements should not be taken into account.
2. Inefficiency in the current system may be translated into a logical model and these will be transferred to the new system.  Ideally, the models should reveal the logic of an efficient system and should be amended accordingly.

1. It’s likely that physical aspects of the existing system may be transferred to the logical

            analysis.  The analysts should guard against that.

How to deal with above limitations

1. Treatment of the new recruitment: The new requirement can be estimated through     interview with management and users.  It’s important that the logical model be amended to reflect the new requirement.  They are likely to lead to new processes which are added to higher level design.

 

2. Treatment of inefficiencies. The model should be adjusted through the decomposition of top level design tools e.g DFD.  The lower level data flow diagram tend to be determined partly by what is done in existing system to fulfill a specific function.

 

3. Treatment of the physical aspects: Certain physical consideration may have shifted into a logical model e.g to incorporate separate files.  There are two types of system design:

  Logical design and physical design.

Logical Design

A logical design produces specifications of major features of the new system, which meets the systems objectives. The delivered products of the logical design is a blue-print of the new system.  It includes:

 The requirement of existing system components:

1. Outputs (reports, displays, timings, frequencies etc)
2. Inputs (dialogs, forms, screens etc)

• Storage (requirements for data to be stored in database.

Procedures (To collect, transform and output data)

Controls (requirements for data integrity, security, data recovery procedures)

NB:  Logical design of the system is viewed in terms of what process i.e procedures, inputs, outputs storage and control the new system should have.

Physical design  

It takes the logical design blue print and produces the program specification, physical files of database and user interface for the selected or targeted hardware and software.

Physical design is mostly concerned with how the current or future system works in terms of how the program are written, files organized in a storage, media tasks carried for user interface with the system.

System Design Objectives

System Design should design that meets the following criteria:

1. User needs as cost effectively as possible.
2. One that is within the constraints laid down in the TQR i.e terms of Reference.
3. Produce correct outputs by processing data accurately and efficiency.
4. Simple to operate i.e easy to use.
5. One with sufficient in-built controls and provide feedback to it’s user.
6. Should be reliable.
7. Should be functional etc.

System design constraints

1. The budget:  Better design system incurs greater expenses.  The total system cost of the objectives must be considered in the light with available budget.

 

3. Time:      Time taken to produce very usable, would increase development cost and delay system delivery.
4. Integration with       Existing and planned system may limit option available other existing system.         features of the system.
5. Skills limitation       May arise from the range of skills and level of competence in both the design team and the system users.
6. The standards       Standards may drive the design tasks in a specified direction.

PROGRAM DESIGN

The following terms may be used to represent a program module, a process, a unit, routine procedure function macro segment or fragment.

The following are some important aspects about a program:

1. One function: A program should carry out only one task.  If several interrelated programs are linked together, they form a system which is easy to maintain for it comprises several units.

2. Size:  A program should be small enough so that its easy to maintain can take

less memory and make optimal use of CPU.

3. Cohesion:   This measures the strength of relation within a program.  This implies that what happens in one sub-routine or other programs.  A program that performs more than one function has a low cohesion.  A high degree cohesion within a program results in lower coupling between programs.
4. Coupling:   Is a measure of the strength of the bond between programs.  Ideally, program should have little dependences on other program in the system.

This is so that any amendment to the program should have little or no impact on other programs of the system.  Programs should thus be

developed in modules.

Why break a system into modules

One program should be written by one programmer.  If a system has only one program, it will take a programmer time influenced by his competence in programming. Small programs are easier to specify, test and modify than large programs, thus errors of the impact of a change are contained within fewer lines of code when modules are used.  Also a programmer can choose the area of the system that interests them to code which is motivating to them.  A large number of small programs make re-scheduling work easier i.e some programs can be assigned to someone else to write if the first programmer is taking longer than estimated for a particular program.

To breakdown a system into modules there should be good program specification.

SYSTEM SPECIFICATION

It is a form document produced at the design stage of system development life cycle.  It represents the conceptual system or the logical system.  There is a system in paper-form.

Contents of System Specification:

1. Introduction of existing system i.e Details of its objective and a brief description of how these objectives are met.

2. Description of the proposed system as a solution to the problem as specified in T.O.R.
3. Justification of proposed system as a solution to the problem as specified in T.OR Costs and benefits justification for the proposed system should be shown.

4. Comparison of both existing and proposed system in terms of inputs i.e specifications of frequency, volume, timings etc.

5. Proposed system file descriptions: This should include file names, organization methods, access method, Nature of the system, the storage media, record structures and file activities.

6. Proposed system control specifications i.e error handling procedures, recovery procedures, in built – can handle both hardware and software related.

PRODUCTION STAGE:

It involves following activities: Programming, testing and documentation.

Programming:

This activity involves translation of system specification into program codes.  A programmer should interface a requirement into the computer system.  Programming standards should be adhered to e.g use of a standard programming language.

Decomposition of a program into smaller units or modules etc.  It’s necessary that programming team work in lia to improve quality of programs produced.

Contents of good program specification:

3. Document details:                     This include file, program identifier i.e name, author, version number., reviewer of the program etc.
4. Introduction:  Contain a brief summary of what the program does in business application area.
5. Assumption and restriction: This list any constraints of the program or information which affects the logic causing the problem.
6. Attributes:  This outlines the program environment e.g hardware, operating system, programming language etc.
7. Data:  i.e inputs and outputs of the program.
8. Functional Description:          i.e  the processing or tasks carried out to convert Program input into meaningful outputs.
9. Detailed Processing Requirement: Indicates functional description i.e low level detailed view of the processing paths.
10. Operation Consideration:  Then describes how operations interacts with the program in the normal running and how he can save or restore the program if anything goes wrong.
11. Sub-routines: These are modules or segments used by the program as well as their input parameters.
12. Messages: Identifies message sent and received by the program and their purpose.
13. Print Layout: Describes print or screen dialogue or layout of theprogram.

Testing:          

Program testing also called unit testing involves testing of a program i.e individual program which are part of the entire suite.  Generally all programs should be tested before the system conversion.  There are two major testing techniques i.e white box and black box testing.

White box testing:   It mainly concentrates on internal construction of a program.  It’s carried out on the following aspects:

(i)        Cyclomatic Complexity   – Are measures of logical complexity of a program.

(ii)       Graph Matrix (matrices) – Are used for condition testing.

(iii)      Data Flow Testing – Commonly associated with SS ADM.  It is used to select paths of a program according to location and definition of variables.

(iv)      The Loop Testing – It focuses on exclusive validity of loops within a program.

Black box testing:

It focuses on functional requirement of software.    It attempts to find errors in the following categories.

Incorrect or missing function:

–           Interface errors.

–           Data structured errors.

–           Performance errors.

–           Initialization and termination errors.

These method is based on the input and output to end form software.  They do not emphasize on structure of a software.

Software testing is conducted in the following aspects or stages:

2. Unit Testing – Is testing of program segments that do a specific function. It emphasize the local data structures, boundaries, interfaces etc.
3. Modular Testing – Involves testing of interrelated units within a program which perform a specific task.  Debugging and correction of errors during each individual program segment could be part of modular testing.
4. Integration Testing – Also known as verification of program construction testing. It involves moving downwards through a control hierarchy i.e from subordinate modules it can either be top down integration or bottom up integration.  Top down integration verifies major controlled and decision points early in testing process.  Bottom up integration uses drivers to co-ordinate a test cases.
5. System testing – It involves linking all modules of a suite to test whether they are interfacing properly.  Its primary purpose is to fully test functionality of a computer based system.  Integration testing is testing of modules during the time they are linked up or

combined together into a suite.

5. Accepted testing – This is carried out by Software User and management representative for the following reasons: –        To discover software not yet detected.

–    To discover the actual and exact demands of the system.

–    To discover whether any major changer are requires by the system can be adopted.

STRUCTURED WALK THROUGH:

(Peer Review) It’s a planned review of system by people not involved in it’s development effort. It’s carried out to establish areas where improvement can be made in the system or it’s development process.  The review is done by between 5 – 10 people as a software quality assurance measure.

Types of walk through:

♦ Requirement Review –It’s conducted to examine a proposed system as formulated by the system analyst.  If there are any inconsistencies between the requirements stated by the users and those that the analyst is proposing.  The walk through should be able to uncover such inconsistencies so that they can be dealt with early enough.

♦ Design Review     –      It’s purpose is to determine whether the proposed design will meet the requirement, they should give solutions to such discrepancies.

♦ Program Review –      This is conducted to examine the program development along with it’s documentation.  The programs are compared with their specific design specifications to determine whether the specifications are being satisfied.  Any programming errors are detected and dealt with.

♦ Testing review:    –     It assists in development of test data that can be used to detect system design errors.  The system testing strategy is not to prove programmer correctness but assess reliability and suitability of the system through detecting critical system errors

Walk Through Team Members:

Chairman: –   He controls the overall direction of a walk through and ensures that its agenda is adhered to.  He gives approval by formerly signing the project milestones when users are satisfied as each development stage.

Author: –         He is the creator or designer of the systems.  He presents and explains the materials that are being walked through.

Recorder: –    Acts as the secretary of the team and ensures that all agreed actions pointed out, are noted and followed up.

Reviewers: – They get in advance the materials being walked through a working model.  They walk through the proposed system and check whether it falls short of required quality.

User Representative:

Approve their understanding and satisfaction of what they will do with the system when it becomes operational.  The representatives may be senior managers, auditors etc.

Importance of Structured Walk-through. 

1. It identifies error, omissions and inconsistencies in a system.
2. It focuses on quality of good practices in system operation generally.
3. It involves the users and gives them an opportunity to give a feedback on critical appraisal of their work.

4. It avoids description about who is responsible for what, thus encouraging team work.
5. It reduces user resistance since they are incorporated and recognized by the development team. 

DOCUMENTATION:

Software documentation is a description of a software or system after its development.  Software product therefore, comprises of codes and documentation

–           Documentation includes a wide range of technical and non technical manuals, books, description and diagrams relating to the use and operation of produced software.  It’s vital for success of software engineering to allocate time to the software engineering particularly

documentation through out its development.

Documentation is aimed at 3 different audiences’ i.e

1. System developer – Who will depend on documents from previous life cycle stages to guide continues development and subsequent maintenance of the software/system.
2. Management –  Who uses documents from past project to plan and understand current projects.
3. System User-   Who learns how to use a software/ system from its narrative, description. or documentation.

In an organization, decisions have to be recorded in some permanent form as a baseline for continuing development of products.  Such base line documentation can only be changed with special authorization.

This is particularly true when documentation form a part of project database (recording about project progress and reporting allow one to access information quickly and always provides exact information requested by any interested party.  It gives needed feasibility to the progress of the project.  Users are justified when they judge a product e.g software on the basis of its documentation rather than its performance.

The best program in the world is useless if one does not know how to co-operate or maintain it.  The most critical aspect of software development is the creation of excellent documentation and not the production of working codes or program thus documentation is more important than programming since even the program becomes useful after or only through documentation.

Objectives of Good Documentation:

The following factors should be considered when preparing a good documentation.

1. Documentation should be complete: This implies that all known aspects of components of documents should be given somewhere.
2. Documentation should be consistent: Inconsistency will destroy the reader’s confidence in the documentation.  The biggest challenge is not consistence in the original documentation but maintaining consistency through all the changes the software or products may undergo.
3. Documentation should be targeted at the right levels i.e for its intended audience e.g a training manual demands as much from its readers as a design documentation to the

programmer one has thus to identify the audience, determine its characters, background and needs and plan documentation accordingly o, one should use appropriate level of formality and appropriate vocabulary in the documentation presentation.  The right approach should also be selected in presenting information so that it can be understood clearly.  One should choose the format of text, technical manual, tutorial, video or audio tapes on line help packs etc.

Illustration and tables should be used since they organize and present large amount of materials for quick comprehension.  Supplementary materials e.g exercises, glossaries, appendices etc should he used.

There are two major reasons why software engineers dislike producing documentation.

(i)        They do not see the need for it because it may indicate that one is new to the profession and has not yet had time to appreciate the benefits of documentation.  It may indicate also that one is so wrapped up in pressure of the moment that long range goals have become absurd.

(ii)       They do not feel capable of doing it.  Although sometimes the feeling of inadequacy derives inability to talk about technical subjects with non technical people.

Importance of System Documentation                                       

1. It guides the development team at various stages of development life-cycle.
2. Can be used as a system back up copy to recover the system, should something happen to its implementation.
3. It aids or assists during system maintenance since it guides in identification of system modules to be changed.
4. It can effectively provide a check list of items to be covered during subsequent system audit or a system maintenance.
5. It guides against loss of system understanding particularly when the author leaves the company or dies.
6. It may act as a training guide or document to ones programmers, analyst or users who may join after system implementation.

Contents of system documentation.

1. Table of contents – Acts as document index.
2. Introduction – Indicates the systems capabilities and constraints or limitation.
3. System specification – it specifies the conceptual system in term of process, data structures, files etc.

4. A list of files to be used by the system – used for reference should something go wrong when the system is live.

5. System JSP – There are pictorial diagrams that describe how the system operates and relationship between various components.

6. Test Data – Shows the data used to evaluate system function ability.
7. Recovery procedures – guides the user on how to recover the system should something go wrong when the system is running..

8. Samples of input and output /results: These helps the user to identify errors when they occur during system- live – running.

9. Back-up procedures: It advises the reader on how to make security copies of files for use to recover the system incase something goes wrong during the system live running.

10. Contact Address/ Telephone number – to be used by the operator to seek help if other options fail.

 

IMPLEMENTATION

This phase involves the following activities

1. Hardware selection, acquisitions and installation.
2. User training
3. File conversion / creation
4. Change over.

Hardware and Software Acquisition.

A user may acquire the hardware and software directly from a manufacturer and developer respectively.  He may also purchase them from an intermediate supplier.  Whichever way a carefully, controlled purchasing procedures should be followed.  The procedure should include. invitation to tender and comparative analysis to determine appropriate supplier of the required hardware and software.

Invitation to tender (ITT)

It is issued to a range of suppliers.  ITT sets put specifications for the required equipment and software and should explore how the hardware will be used and the time scale for implementation.  It sets the performance criteria required for the new system.

 Contents of ITT.

Background information and the companies together with an indication of the purpose of the system.  These includes:

1. The volume of data to be processed by the system. Complexity of the processing requirements and system interfaces should be stated.
2. The number of individuals who will want to access the computer system after installation and whether access needs to be instant or not.
3. The speed of processing required and expected.
4. Input and Output derived.
5. The type of processing methods preferred.
6. Estimated life of the system.
7. Possible upgrades or expansion anticipated.
8. Other general consideration include: contact person in the company.

• Overall financial constraints.
• The form that sub-mission is to take.
• Closing date for sub-mission of tender.
• The address to which tender is to be sent.
• The reference person to which tender is to be addressed.

 

While all the above features are necessary to consider, it’s important to decide the financing methods.  This includes purchasing where the buyer acquires ownership of item after payment of an agreed amount upon time.

Leasing involves formation of an agreement between the lessee and lesser detailing the use of equipment, the length of time to use the equipment and the periodical payment.

Renting involves a single agreement where one party agrees to use another party.  Resources at certain periodical payments.  The agreement is not as binding as that of lease agreement.

Evaluation of Vendor Proposal

1. Bench marks – Tests how long it takes for a machine to run through a particular set of programs.  Its carried out to compare performance of a piece of software or hardware against present criteria e.g speed of performance, response times and user friendliness of the equipment.
2. Stimulation Test – It uses synthetic program written specifically for testing purpose. They are programmed in cooperated with routines designed to test a variety of situations.  Other features or factors include:

• Supplies reliability i, e both financial stability and Tract record.
• Cost i.e equipment cost, installation cost and training costs.
• Utility software supported and preloaded in the hardware.
• The warrant period, units and maintenance commitments.
• Software support upgrades maintenance.
• Training requirements which includes timings, number of personnel etc.

Software Factors:

9. User requirements: the selected software or package should fit user requirement as closely as possible.
10. Processing time: these involves the response time e.g if the response time is slow the user might consider software or package as unsuccessful.
11. Documentation: the software should be accompanied by manual, which is easy to understand, by non technical person.  The manual should not contain technical jargon.
12. User friendliness: The package should be easier to use with clear on screen prompts, menu driven and extensive on screen help facilities etc.
13. Controls: The software should have in-built controls which may include password options, validation checking audit trail or trace facilities etc.
14. Up-to datedness: The software should be upto date e.g should have changes or corrections in line with business procedures.
15. Modification: One should be up to date e.g should have changes or corrections in line with business procedures.
16. Its success in the market: One should consider how many users are using the software and how long it has to be in the market.
17. Compatibility of the software : i.e how the software integrates with other software and how long it has to be in the market.
18. Portability: One should consider how the software runs on the user computer and whether there will be need for the user to upgrade his hardware.
19. Cost: The user company should consider its financial position to establish whether it can afford the software required for efficient operations rather than the least cost packages software available.

1. Software Contracts:

Software contracts includes the costs, purpose and capacity of the software it describes what it cannot do.  In summary the following are covered in software contracts.

 

1. Warrant terms.
2. Support available
3. Arrangement for upgrades.
4. Maintenance arrangement.
5. Delivery period / time for especially written software.
6. Performance criteria

 

Software Licensing:

Software licensing covers the following:

1. Number of users that can install and use the software legally.
2. Whether the software can be copied without infringing copyrights.
3. Whether it can be altered without the developer’s consent.
4. Circumstances under which the licensing can be terminated.
5. Limitation of liability e.g of the user commits fraud using the software.
6. Obligation to correct errors or bugs if they exist in the software.

 Installation:

Software and Hardware Installation is done by supplier technicians or the user organization appointed person to avoid the risks associated with improper installation of the equipment.  The system analyst and other development team members may be called to assist where appropriate.

User training

It’s important that the system users be trained to familiarize themselves with hardware and the system before the actual change over.

AIMS OF USER TRAINING: 

1. To reduce errors arising from learning through trial and error method.
2. To make the system to be more acceptable to the users.
3. To improve security by reducing accidental destruction of data.
4. To improve quality of operation and services to the users.
5. To reduce the cost of maintenance by minimizing accidental destruction of data or hardware.
6. To ensure efficiency in system operation when it goes live.

Persons to be trained:

1. Persons operating the system when it becomes operation (system operators).
2. Senior managers.
3. Middle managers.
4. Any person generally affected by system directly or indirectly.

Training should cover current staff and recruited personnel.

Recruitment of new personnel involves:  Job specification,  advertising salary and interviewing those to be recruited for training to be effective e.g lectures, tutorials, case studies etc  It must be clear what the objectives of the training is i.e what it is trying to achieve form of education or training

▪   For successful implementation of a system, training should be planned well right to the project onset.  The following may be in co-operated in education and in training plans to meet charging circumstances.

▪   To organize classroom sessions with user groups depending on specific areas of interest to be discussed.

▪   To use leaflets and manuals and distribute to relevant recipient.

▪   To demonstrate and allow hands on training on training on technical aspect.  These is necessary when skills are required to be developed.

Areas to emphasize

1. Background information which may help user to understand and therefore co-operation.
2. Developers expectation of the users during the entire system development process and post implementation activities.

3. The developer’s expectation of the user when the system becomes live or operational.
4. How user activities fit in the rest of the development team.
5. How the system failures can affect the users.

 

Timing of User’s Training

1. Before the feasibility study when the users are given general explanation of computer systems, their relevance in function application and reason for desire to introduce a computer in the specific functions.
2. Before investigation where the user’s are explained about the impact to the new system and importance of their involvement in development.  This may help gain user confidence and facilitate their acceptance of the system.
3. During the fact-finding so that they can co-operate and provide useful information to guide system developer analysis stage of SDLC.
4. Before programming so that they can prepare themselves for specific roles at the implementation stage.  These may include testing activities roles.
5. Before implementation to enable the users to co-operate and play their roles assigned to them.
6. After implementation in-order to assist in evaluation of system performance.

FILE CONVERSION:

This involves changing of existing form of files into a form suitable for the new system when it becomes operational.  It may require that the analyst creates the file from scratch if there are no existing computer based files.  In an on event that computer based files exist they should be converted to a form relevant or sensible to the new system.

File conversion procedure:

1. Record manually the existing data i.e the old master file.
2. Transfer the recorded data to special form required by the new system.
3. Insert any new data into the file i.e update the file already in the new form (form should include data contents and their corresponding formats and layout).

4. Transcribe the completed form into a medium or storage relevant for the new system.
5. Validate the file contents to ensure that they are error free before they can be used in the new system.

Problems associated with file creation / conversion

1. Records may be stored or located at different places or locations, thus may be difficult to gather them all.

2. Some record may require up-dating which may slow down changes over plan.
3. Records may be too numerous i.e too large in volume which may slow down the change-over plan since transaction will take long.

4. Some records may not exist at all e.g a customer who makes an order through a phone call.

There will be no hard copy record left to rely on.

 Methods of file conversion

File conversion methods are:

(i)         Straight file conversion / creation.

(ii)        Dummy file conversion / creation

(iii)       Phased file conversion

 

Straight file conversion

It requires that the files be converted by bit phases.  This implies that instead of changing e.g a whole department file, the file is charged on section by section basis.  It may suitably be applicable on phased change.

THE CHANGE – OVER METHODS

It involves changing or switching from existing system to the new developed system.  Either of the following method can be adopted i.e.

1. i) Direct change over
2. ii) Parallel change over

• Phased change over

Pilot change over

The old system ceases its operation one day and the new system commence operation the next day.  The old system is made redundant in all its aspect as illustrated below:

 

________________________________

 

 

Old system running

 

___________________________________________________________

 

New system being                                              New System

Developed                                                       running live

 

___________________________________________________________

 

This method is applicable in the following circumstances:

–           When the new system and simple.

–           When both new and old system are substantially.

–           When extra staff to oversee or undertake parallel running of both systems are available or Unavailable

 

–           When the management has complete confidence that the new system will work

 

Advantages:

1. It’s relatively cheap
2. It prevents the weakness of the old system from being passed over to the new system.
3. It reduces system implementation duration.

 

Disadvantages:

1. It’s very risky especially if the new system fails. The cost of switching back to the old system will be high.

2. If not properly planned, it may interrupt user organization operations and bring confusion amongst staff members.

Parallel Change Over

A method where new and old systems are allowed to run side by side until its proved beyond reasonable doubts that the new system is sophisticated and very careful change-over is require.  When development team has no confidence in the new system.  Where there are more staff to cope up with operations of both system running parallel as illustrated below.

Both system are running in parallel

Advantages

2. Users become familiar with the new system prior to the change-over which may enhance their efficiency
3. The organization is exposed to less risk in case the new system fails.
4. There would be less interruption and inconveniences in the organization operations during the change over period.

Disadvantages:

1. It’s an expensive method.
2. It might delay system implementation schedule or period.

Phased Change Over

The method involves implementation of a system on step on step approach.  This implies that only a portion pf the system is implemented initially.  Other portions are implemented later in phases as illustrated below.

 

Previous System        Part of previous      Part of the

Running Live              System and             previous system

 

__________________________________________________________________________

Phase 1, 2, 3 of the        Phase 1 of the        Phase 1 & 2 of            New system

New system being        New system            the new system           Running live

developed                      running                  running LIVE

 

_________________________________________________________________________

Phase 2and 3 of

the new system

being developed

 

___________________________________________________

 

 

Pilot Change Over

It involves installation of new system but using it only in one part of organization on experimental basis e.g A bank wishing to computerize its operations may install a computerized system on one branch on experimental basis.

When the system is proved to be successful, it is transferred to another etc until the entire bank is computerized.  Any refinement that ought to be done on the system should be done before its installed in the next branch.

Both pilot and phased change over method share the same advantages and disadvantages as follows:

Advantages:

–           Allow a new system to be implemented quickly with minimum risks.

–           Allow training of personnel on the new system during its implementation.

–           They cause minimum interruption to operations during system’s implementation.

–           The peak demands are lighter on the ends user and the operational environment.

–           They are less costly.

–           The risks associated with errors and system failures are minimized.

 

Disadvantages:

–           Interfacing both the new and the old system may usually bring problems.

            They may be additional costs associated with running both systems at the same time.

 

Change over plan should include the following:

1. Time limit for the parallel run.
2. Instructions on error handling procedures.
3. Instruction on how to cope with major problem in the new system.

 

POST IMPLEMENTATION REVIEW / SYSTEM EVALUATION STAGE.

Its an important activity which like training and testing is a continuous process. It involves measuring or assessment of system development stage and the final produced system.  It may be carried out from the 3^rd to 7^th month after change-over.  The development team member, the users, or auditors, the management representative and those affected by the system may take part in the exercise.  This is to ensure that specified objectives are met and are justifiable in terms of cost, benefits and other performance.

The review focuses on the following areas:

1. Comparison on the actual system part performance against the anticipated performance objectives.  This involves assessment of system running cost, benefits etc as they compare with the estimated or anticipated.

2. The staffing needs of and whether they are more or less than anticipated.
3. Any delays in the processing and effects of such delays.
4. Effectiveness of the security procedures in-built in the system.
5. The error rates for input data.
6. The output i.e whether its correct, timely and distributed correctly to the relevant users.

Research findings reveal that much of evaluation is performed and manager by members of development team.  They determined evaluation criteria and the methodology to be used.  Evaluation of a system should be carried out after completion of every stage of SDLC.  There are 3 types of evaluations.

Formative evaluation (Feedback)

It produces information that is feedback into the development cycle improve products under development.  It serves the needs of those who are involved into the development process.

Summative evaluation – It’s done after system development project is completed.  It provides information about efficiency of the product to these decision makers adopt it. 

Documentation (post implementation evaluation is performed just before and after Hardware and Software installation and also after system change-over. It’s carried out to assess general functionality of a system after settling down.

Benefits of post-implementation – evaluation

It improves system development practices, decisions to adopt, modify or discard an information system.

• Ensures compliance with user objectives.

–           It enhances evaluation and training of personnel responsible for a system development.

–           It improves effectiveness and productivity of subsequent system design.

–           It ensures realization of cost saving operations by modifying the system.

 

Aspects to be evaluated:

1. Systems output accuracy i.e information produced by the system.
2. User satisfaction with information system.
3. The attitude towards the system by those directly affected by the system.
4. Effective systems of internal control.
5. Project schedule compliance.

 

Other project/factors may include:

–           The impact of the system on the organization structure.

–           The equality of program produced.

–           The operational cost of the system (Net cost).

–           The savings made as a result of the system

–           The impact of the system on users and their job.

–           Quality and completeness of the system documentation.

 

Reasons why post implementation evaluation is carried out.

–           To verify that the installed system meets user requirements.

–           To provide a feedback to the development personnel.

–           To justify adoption, continuation or termination of installed system.

–           To clarify and set priorities for any needed modification on the system.

–           To transfer responsibility of the system from the development team to the users.

 

N: B System post implementation review team writes a report that indicates specific areas within the system that needs improvement.  This report is called Post implementation review report.

It acts as a reference document during system maintenance.

SYSTEM MAINTENANCE

It involves changing part of the system according to the recommendation of the post implementation review team.

Causes of system maintenance:

–           Defects in the system after its delivery.  This involves any errors or bugs in the newly implemented system e.g Use of formula within a system.

–           Environment change – e.g A government tax policy change which influence a change of payroll system.

–           A change in user requirements.  A business organization exists in a changing environment, therefore the user requirements change e.g A payslip in a payroll system may initially be required to show the employees corporate share amount.  Employees may feel that such

information should not appear in the payslip and thus influence a change in the system.

Poor documentation of the system:

It makes it difficult for one to understand the system, and also over to change it should there be a need to do so.

A system may be changed and its documentation re-written in order to improve its maintainability.

Basically system maintenance is carried to improve the system adaptability and flexibility.

Flexibility involves minor changes in a system in order to benefit the user from advances in both software and hardware technology. The process of the system maintenance should be controlled by the system analyst.  When a manager or a user suggests a change to the system regardless of the reasons, the analyst should prepare diagrams and estimates the impact.

The change control board decides whether or not to implement the change.  If change should take place, the analyst modifies all the documentation’s by merging the diagram and estimated into the existing problem and designs the specification.  The programmers and testing teams are responsible for incorporating any change into the programs.  They test the system to ensure that no errors or problems are introduced as a result of change.  Once the change is satisfied as default free, the revised system is adopted immediately.

TYPES OF SYSTEM MAINTENANCE

(i)         Corrective maintenance

(ii)        Perfective

(iii)       Adoptive

(iv)       Preventive

 

Corrective maintenance

Its usually a change effected in a system response to detect problem or error. It’s objective is to ensure that the system remains functional.  It basically involves removal of errors on the already newly developed system.

Example could be a failure in parts of the system.

Perfective maintenance

It’s a change to perfect a system i.e improve it’s performance in terms of response times to user request or to amend a system interface to make a system more user friendly.

Adaptive maintenance

Involves changing a system to take an account of a change in its functional environment.

Preventive maintenance

Carried out on a system to ensure that it can withstand stress.  It helps in ensuring data and software integrity.

Replacive maintenance

It carried out on s system when a system becomes almost unmaintainable e.g due to lack of documentation, poor design or age.

system success and failure

An information development is in itself a project which takes up resources and time to develop.  It is a fail if does not perform as it’s expected or if it is not compiled altogether.

If the number of errors or the frequency of errors is high, it can also be said to be failure.

Information system development is successful if it achieves the goals set in terms of business goals, operation, performance goals etc.  It should fit in the structure of the organization for which it was developed.  It should be flexible to allow change in order to meet the changing business conditions.  It should be accurate, secure and reliable.  It should be then calculated in order to support its maintainability.  It is very expensive for system to fail.  One way of limiting the expenses associated with system failure is to take am account of the system at the design stage, and at the documentation stage.  Documentation of a system is a continuous activity right from the analysis up to post implementation stage.

System success can be measured through:

1. High level of System use. This can be done through monitoring parameters e.g Volume of transactions processed.  Use of questionnaires.

2. User satisfaction which can be measured through interview, user opinion, system accuracy information, timeliness, relevance etc.

3. Favorable attitudes of users about information system and information system staff members.

4. Financial pay off to the organization either through reducing the costs by increasing profits or both.

5. Achievements of objectives: This is the extent to which a system meets specified goals as reflected by improved organization affairs and decision making by the users of the information.

6. Positive attitude or comments from the organization management.

System failure can be measured through:

1. Negative attitude from the staff and organization management.
2. Lack of user satisfaction.
3. More costs involving the system which leads to less profits.
4. When organization’s specified needs are not met by the developed information system.
5. Dissatisfaction of the management and about the Information system they pioneered.

Causes of information system failure:

It’s difficult to single out one explanation for system development success or failure.  However, the following factors can largely determine systems development and implementation outcome.

(i)         User involvement in the development and implementation of information system.  If users are highly involved in the system development project may be successful since users are likely to react positively.

Failure to involve them may lead to project failure.

(ii)        The user/the designer communication: If the user and designer have different interests, and priorities there would be communication gap between the two.  Those will lead to comprise on the organization layout which will lead to the system failure.  If the gap is reduced or eliminated, both parties would work towards achievement of organizational objectives thus may lead to success of information development project.

(iii)       Management support and commitment: If the management is supporting and committed to the system development project, the project may be successful since the development team and the users are likely to perceive the development project positively.

(iv)       Management support also ensures that the project receives sufficient funding and resources. Lack of management support leads to the project failure since the development team may not perceive sufficient resources and fundings which is determined by organization

management.

(v)        The level of complexity and the list of project implementation activities.  There are 4 key dimensions that the level of project lists i.e

(a)       The project size: – The larger the project, the greater the risks and the higher the chance of failing.

(b)       Project structure: – Well structured project has its requirements clearly define.  They are straight forward and they have least risk of failure.

(c)       The project experience in technology.  A project handled by a team without technology expertise and experience has a high risk if failing.

 

(d)       Quality of management for project implementation.  The management of system development and implementation must be people with high inter personal skills. The conflicts and uncertainties in any implementation will be magnified if the project is poorly managed.

 

Improper management of system development project will:-

• Exceed budget.
• Delay to complete.
• Leads to technical shortfalls, resulting in performance that is significantly low than

estimated level.

(iv)       Failure to obtain the anticipated benefits.

(v)        Unrealistic deadline, poor planning, lack of control, changing user requirement, poor time

tabling and resources.