SYSTEM LIFE DEVELOPMENT CYCLE

(SDLC)
• A systems analysis team or analyst is often brought in to improve on an existing system.
• Frequently this involves moving from a paper-based filing system to one which is computerized.

• SDLC involves the following stages;

1. Problem identification
2. Fact finding
3. Feasibility study
4. Analysis
5. Design
6. Development and Testing
7. Documentation and User Training
8. Implementation, Evaluation and Maintenance
Problem Identification
Is the preliminary investigation of a problem used to decide whether a solution is possible and how it may
be done.
The initial definition of the problem is the important first stage. If it is not done correctly, the wrong problem
may be solved.
What prompts a new system
The current system may be no longer suitable for the purpose
Technological developments may have made the current system redundant or outdated.
The current system may be too inflexible or expensive to maintain.

Examples of a problem
a. Takes too long to find students records when paying school fees.
b. Tuckshop takes too long to serve customers.

Analyst has to turn the basic problem into a clearly defined set of tasks.
c. Develop a database of student details which can be searched by student number or name.
d. Develop a stock system , which shop keeper can use mouse or keyboard to get item details and calculate
totals.
Fact finding
It is concerned with finding out about the existing system i.e. how things are done at the moment before
suggesting any improvements.
There are four common methods used in fact finding.

Observation
Involve watching personnel using the existing system to find out exactly how it works.

Advantages
The analyst obtained reliable data
It is possible to see exactly what is being done
It is relatively in expensive method.

Disadvantages
People are generally uncomfortable being watched and may work in a different way.
If workers perform tasks that violate standard procedures, they may not do this while being watched.
Questionnaires
• Involves sending out questionnaires to the work force and /or to customers to find out their views of the
existing system and find out how some of the key tasks are carried out.

Advantages
• It is possible to find out the views of a large number of pupil.
• It is a relatively an inexpensive method.
• Individuals can remain anonymous if they want.
• It allows quick analysis of the data.

• Disadvantages
• Often the number of returned questionnaires is low.
• There is no way to clarify a vague or incomplete answer to a question.
• The questions have to be carefully constructed to elicit unambiguous answers.
Interviewing
• Involves a one-to-one question and answer session between the analyst and the employee/customer.

Advantages
• It gives the opportunity to motivate the interviewee into giving open and honest answers to the
analyst’s question.
• It allows the analyst to probe for more feedback from the interviewee, as it is easier to extend a
question.
• It is possible to modify questions as interview proceeds and ask questions specific to the interviewee.
• It is a good method if the analyst wants to probe deeply into one specific aspect of the existing
system.

Disadvantages
• It can be rather time consuming.
• It is relatively expensive, due to the use of the analyst’s time.
• The interviewee cannot remain anonymous.
Document inspection
• Allows the analyst to see how the paper files are kept, look at operating instructions and
training manuals, check the accounts, etc.

Advantages
• It allows information to be obtained which was not possible by any of the other methods.
• The analyst can see for themselves how the paper system operates.
• It allows the analyst to get some idea of the scale of the problem, memory size
requirements, type of input/output devices needed, etc

Disadvantages
• It can be very time consuming.
• Because of the analyst’s time, it is a relatively expensive method.
The Feasibility Study

• The aim of the feasibility study is to understand the problem and to determine whether
the project is worth proceeding and will work at a reasonable cost.

• The following are usually included in a feasibility report:

• A brief description of the system and any problems with the existing system.
• The objectives of the proposed system.
• Details of what part of the business is being looked at.
• A list of some alternative solutions considered and why these alternatives were rejected.
• The human, technical, legal, operational and economic factors:
• Do the staff have the expertise to cope with the new systems?
• Is the technology available, that is, can it be done?
• Is there enough money to go ahead?
• A plan for the implementation
• Technical feasibility
• Technical feasibility means investigating whether the technology exists to implement proposed
system, or whether this is a practical proposition, e.g. are necessary hardware and expertise
available.
• Economic feasibility has to do with establishing the cost effectiveness of the proposed system –
if the benefits do not outweigh the cost, then it is not worth going ahead.
• Legal feasibility
• It determines whether there is any conflict between the proposed system and legal
requirements – for example, will the system contravene the Data Protection Act?
• Operational feasibility
• Is concerned with whether the current work practises and procedures are adequate to support
the new system.
• Social feasibility is how the organisational change will affect the working lives of those affected
by the new system. E.g. new technology can bring resistance to change among older staff.

• The completion of this stage is marked by the production of a feasibility report produced by
the system analyst. If the report concludes that the project should go ahead, and this is agreed
by senior managers, detailed analysis will proceed.
 ANALYSIS
• The basic facts about the project are worked out so that
the design of a solution is focused on clear objectives.
• What data is required and where it will come from.
• How the data will be collected.
• What validation will be necessary.
• How the data will flow through the system. Flow charts
and data flow diagrams are helpful.
• What the output will be – decisions are made on the
layouts of screens and printed reports.
• Backup and security strategies.
 DESIGN

• Decide upon the content of database tables, together with their fields and
data types.
• Design the format of reports that will be generated from the system.
• Determine what searching and sorting processes will be employed.
• Establish what the program modules will be what language will be used for
the coding.
• Link all parts of the solution. This may include determined hyperlinks in a
web site, or passing data between program modules.
• Design the input and output screens and decide how they will link together.
Development and Testing
TESTING

Has to be planned in order to cover all foreseeable eventualities.

Each part of the solution has to be tested, and then the whole system must be tested to see that parts were
together properly.
Test data is devised to check that the system works under all circumstances, no matter what the users do.

Alpha testing
Testing that is done by software developers.

Beta testing
When chosen users are testing the software.

A test plan should include:

The part of the system to be tested.
The test data.
The expected result.
The actual result.
DOCUMENTATION
The job of software developer does not end with writing the software.
The parameter of software wants to know how to get the best out of it.
User documentation
The purchaser of the software needs to get the best out of it, so user documentation is provided.
Technical documentation
Is needed to help programmers who work on the software in the future.

Technical Documentation
Most software is complex and written by teams of people.
It changes often. It is unlikely that the same people who wrote it will maintain it.
It is important that the work done on the software is documented so that maintenance enhancement and debugging are
possible.

Technical documentation should include :

• An overview of the software.

• Input and output methods.
• System flow charts.
• Site map in the case of web site.
• Details of the way the software works.
• Details of screens and reports.
• Testing and test plans.
User documentation
• What the software does.
- A guide that describes what the software is supposed to do in non-technical terms.
- This will include the main feature of the software and the enhancement over the previous version if the software is an
upgrade.
• Instructions about preparing and entering data.
• Understanding the output data.
• Error messages and correction.
• Tutorials.
• Backing up.

Types of user documentation

1. Paper based documentation

- Most software comes with a printed manual.
Advantages
- Complete and laid out in logical sections.
- Can be studied anywhere.
Disadvantages
• Bulky and difficult to store.
• Often hard to find what you need.
• Difficult to update.
• Expensive to produce.
2. Online Documentation

Most software has online help, can be accessed by pressing F1.

Sometimes, help is supplied so separately on CD Rom, which makes it easier for the developer to provided
updates.
On-line help is not designed to be read in a linear way.
Any concept or word that may require further help is highlighted and acts as a link to further explanations.
This sort of documentation is an example of hypertext just like links on web sites.
Advantages

- Easy to jump to what you need.

- Easy and cheap to update.
- Compact to store.
- Context sensitive help.
When help is asked for, often it will automatically relate to the function currently being used, this avoids having
to look up the right topic.

Disadvantage
- Need to be at the computer to access it.
2. Web based Documentation
- Some software developers put all their documentation on their web site.
Advantages
- Always up to date.
- Cheap to distribute.
- Search facilities can be provided.
- Opportunities for feedback to the developer.
- Developers can collect marketing information.

Disadvantages
Need to log on.
May be difficult to find what you want.

3. Computer installations documentation

A network of computers consists of many components, with workstations, servers, hubs, switches, cables, wiring center and
routers as well as software.
People who look after a develop the network need clear documentation to tell them ;
- The different components.
- The makes and specifications of the equipment.
- The location and versions of software.
- The location and type of cables.
- The specification of bandwidths and protocols.
This document will include wiring diagrams as well as the written information.
IMPLEMENTATION
• SETTING UP OF DATA STRUCTURES
• WRITING THE CODE
• TESTING THE CODE
• CONVERTING ANY EXISTING DATA TO WORK WITH NEW SYSTEM.
• STAFF TRAINING
• INTRODUCTION OF NEW PROCEDURES.
• THE CHANGEOVER

TYPES OF CHANGEOVER
PARALLEL RUNNING
- Is where the old and new systems are run side by side until it is certain that the new systems are running side by side until it
is certain that the new one performs well.

PILOT RUNNING
• Key parts of the new system are run alongside the old system until it is considered that they have been fully tested.

DIRECT/ONCE AND FOR ALL (BIG BANG)

- Where the old system is abandoned and the new one is totally relied upon.
PHASING
Parts of a system are replaced while the remaining parts are covered by the old system. This allows for some testing of the
new system to be done, and for staff training to take place, but also allows for a back-up position if the new version does not
work as anticipated.
PROGRAM MAINTENANCE

Once a computer system has been delivered and instead, the development work does not stop.
Systems continue to cost throughout their lives.
Program maintenance is the process of updating and refining software throughout its life.
This thinks more effort than writing software in the first place. It is easier if;
The original software is constructed in a logical and ordered way.
Modules are kept small and do not do too much.
The programming style is kept simple.

Maintenance is required because of the following reasons;

Program faults
It is important and programs should not have bugs. With a big program, it is extremely difficult to rigourously test every every
circumstance.

- Changing needs of the organization.

- Changes in legislation.
- Improvement.
- New features.
- Changed platforms.
MONITORING
- No computer system is perfect.
- A new system is monitored throughout its life, more often in the early stages.
- Some faults will only show up later, when a lot of data is entered, or unusual situation arise.

Evaluation
- Questions are asked such as:
- Has the any shortcomings.
- With have to be made in the future.
- Does the software work as fast as is desirable.
- Was the document adequate.
- Is there on-screen help.
- Does the software give helpful feedback if operator errors occur.

The best way for developers to conduct an evaluation is by consultation with the client.
It can be helpful to follow some of the same which were used in the investigation phase such as:
- Questionnaires
- Visits
- Interviews

*It is good idea to keep this cycle of consultation and develop going in order to ensure that the software remains as effective
as possible.