Chapter 2: SDLC and Documentation

2.2 VARIOUS PHASES OF THE SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)

❖ The basic idea of SDLC is that there is a well-defined process by which a system is conceived,
developed and implemented. The system development starts when management of an
organization or sometimes system development personnel realize that a particular business
system needs improvement. The system development life cycle (See Figure 2.1) consists of the
following activities:
(a) Preliminary investigation
(b) Feasibility study
(c) System analysis
(d) System design
(e) Development of software
(f) System testing
(g) Implementation and Evaluation
(h) Maintenance

2.2.1 Preliminary Investigation (Problem formulation)

❖ One of the most difficult tasks of the system analyst is identifying the real problem of the
existing system. Without clear understanding of the problem in the system, any further work
done will lead to wastage of effort at a later stage.
❖ Problem definition defines the user requirements, of what the user expects out of the system.
This phase also sets the project boundaries, which define what parts of the system can be
changed by the project and what parts are to remain without any change. This also includes a
rough idea of the resource requirements for the project as well as the estimated start and
completion dates for each phase and the number of persons expected to be involved in each
phase
❖ All projects that are requested are not always feasible. Some organizations receive so many
project requests from employees that only a few of them can be pursued. Even those projects
that are feasible and desirable should be put into a schedule. The management decides the
requests, that are most important and only after a project request is approved, the cost of the
project, priority, complexion time and personnel required are estimated.

In system development life cycle, problem identification helps in:

(a) Pinpointing the problems.

(b) Setting proper system goals.

(c) Determining the boundaries of the project by taking into consideration the limitations of the
available resources.

2.2.2 Feasibility Study

❖ A feasibility study is undertaken to determine the possibility of either improving the existing
system or developing a completely new system. This study helps to obtain an overview of the
problem and to

get rough assessment of whether feasible solution exist. Since the feasibility study may lead to
commitment of large resources, it is important that it is conducted competently and that no
fundamental errors of judgement are made.

Feasibility studies are used as a basis for deciding whether to proceed with, postpone or cancel
The project.

❖ The purpose of feasibility study is to determine whether the requested project is successfully
realizable. There are three aspects of feasibility study namely,
(a) Technical feasibility
(b) Economic feasibility
(c) Operational feasibility
1. Technical feasibility
❖ technical feasibility centers around the required /existing computer system (hardware/software)
to what extent it can support the proposed application. For example, if the current computer is
operating at 80 % capacity, then running another application could overload the system or
require additional hardware. This involves financial consideration to accommodate technical
enhancement. If the budget is a serious constraint (limitation) then project is judged as not
feasible.
This study should answer the following questions:
(a) Whether the project can be carried out with the existing equipment?
(b) Whether the existing software is enough?
(c) Can the work be done with the existing?
(d) If a new technology is required, how best can be implemented?

Technical feasibility is concerned with specifying equipment and software that will
successfully support the required task.

2. Economic feasibility

❖ Economic feasibility study is the most frequently used method for evaluating the effectiveness
of new system. Cost-benefit analysis is performed determine the benefits and savings that are
expected from the new system and compare them with costs. If benefits outweigh costs, then
the decision is made to design and implement the new system.
By conducting this study, the analyst can ascertain the following:
(a) Whether the project is economically feasible?
(b) If enough funds are not available, then what the sources of funds?
(c) Whether there are sufficient benefits when compared to the costs incurred?

3. Operational feasibility

❖ Operational feasibility is concerned with human organizational and political aspects. Operational
feasibility covers two aspects. One is a technical performance aspect, and the other is
acceptance within the organization.
❖ Technical performance includes issues such determining whether the system can provide right
information for the organization's personnel and whether the system can be organized so that
always delivers this information at the right place and at right time.
❖ Operational feasibility must determine how the proposed system will fit in with the current
operations and what, if any, job reconstruction and retraining will be needed to implement the
system.
❖ The evaluation must then determine the general attitudes and job skills of existing personnel
whether any such restructuring of jobs will be acceptable to the current users.
The analyst should determine,
(a) Whether the system can be used if it is developed and implemented?
(b) Will there be resistance from users that will cripple the possible application benefit?
The feasibility study is carried out by small group of people who are familiar with
information systems technique

2.2.3 System Analysis

❖ The analysis phase is the detailed understanding of all-important facts of the
business area under investigation the relationships of the various system
components among themselves and with environment are studied and understood.
This requires data collection from a variety of sources. For this, questionnaire,
forms, interview, study of existing documents, records etc. are used the analyst
must try to answer the following set of questions,
(a) What is being done in the organization?
(b) How is it being done?
(c) What is the volume of the transactions?
(d) How frequently do the transactions occur?
(e) What are the problems that may arise?
(f) a problem arises, how will it be solved?
(g) What could cause such a problem?
❖ To answer these questions, the system analyst must consult a variety of persons He
has to understand the whole details about the business, the processes involved in it
and the problems faced by the staff. He should also identify the reasons for the
problems that have occurred and the preventive measures to avoid them.
❖ The analyst must have a detailed study of the manuals and reports about the
organization Further he should have a direct observation of the activities in the
organization and collect a sample of the forms and documents to understand the
whole system.

2.2.4 Development of Prototype

❖ prototype is a model of the final system. The purpose of a prototype is to allow the
user to see something concrete. It is very difficult to form an idea of the features of
a system from a set of written specifications particularly for the user. The prototype
shows the user how some part of the system will look the system that is developed
at a high cost may fail in certain situations. To avoid this, the analyst should design a
mini system like the one to be developed. This prototype acts as a test System. If
this system is successful, the analyst can start designing the actual system.

2.2.5 System Design

 ❖ In the system design process, the primary objective is to identify user requirements
and to build a system that satisfies these requirements Design of system is largely
the logical design. The logical design can be sketched on a paper or on a computer
terminal. The design, also including the physical design elements, describes the data
to be inputted, the processes involved in the manipulation of data and the output.
(a) The analyst should specify the file structures, storage devices etc.
(b) The database is also designed in this phase.
(c) Hardware cost, capability, speed, error rates, and other performance
characteristics are specified.
(d) Changes to be made in the organizational structure of the firm are outlined.
(e) Input, output, files, forms and procedures are planned
(f) Finally, standards for testing, documentation and system control are formulated.

The most challenging and creative part of the system development life cycle is the
design of the system.1

2.2.6 Development of Software

❖ Development is the phase where detailed design is used to construct and build the
system in this phase, the system is programmed. Now, the analyst should decide
whether to buy a commercial software or to develop new customized Programs
with the help of programmers. The choice depends on the cost of the software and
the cost of Programming such software. In large organizations the work is entrusted
to programmers, whereas in small organizations, the job is assigned to outside
Organizations.
❖ Programmers are also responsible for document in the programs. The documents
should include comments that provide explanation of the Procedures coded in the
programs.

2.2.7 System Testing

❖ Testing is the process of making sure that the programs perform the intended tasks.
Once the system is designed it should be tested for validity During system testing,
the system is used experimentally to ensure that the software does not file. it will
run according to its specification and in the way, users expect it to.
❖ The system is tested with special test data and the results are examined for their
validity. Some of the users may be permitted to operate on the system so that the
analyst can ascertain that the system can work in the specified environment.

2.2.8 Implementation and Evaluation

Implementation
 ❖ Implementation is the final phase of development. It consists of installing hardware,
programs, collecting data and organizing people to interact with and run
the system.
❖ In the implementation phase, the user starts using the system. This phase therefore
involves training the users in using the system and also providing them friendly
documentation to refer to.
❖ Implementation can be done in two ways. One way is by implementing the new
system along with the old system and make them run in parallel. The other method
is to replace the entire system. In large organizations, the new system can be
implemented in certain areas as a pilot project and if satisfactory results are
obtained, it can be implemented to other areas also.
Evaluation
❖ Once the system is implemented, it should be evaluated Evaluation is the process of
verifying the capability of a system, after it is put in operation, to see whether it is
meeting the objectives or not. Evaluation is an important aspect, due to the
following reasons:
(a) To assess the system, i.e. how the system is functioning. what the response time,
overall reliability and level of utilization is etc.
(b) To find the limitations in the system.
(c) To identify whether the new system developed would be beneficial to the
organization under operating conditions
(d) To judge the attitude of different persons in the organization regarding the
newly developed system
(e) Evaluation of cost, time and effort taken for the overall project.

2.2.9 Maintenance

❖ Maintenance is the process of incorporating changes in the implemented existing

system for proper utilization. This involves enhancement, adaptation and
correction
Enhancement
❖ Enhancement implies adding new functions or additional capabilities to the system.
Adaptation
❖ Adaptation implies customizing the software to run in the new environment.
Correction
❖ Correction implies correcting the bugs in the existing software.
2.3 SYSTEM DOCUMENTATION CONSIDERATION

2.3.1 What is Documentation?

❖ Documentation is a description of the system used to communicate, instruct and

record information for historical, operational or reference purposes. Documents are
very important because they represent the formal information flow of the present
system Documentation establishes and declares the performance criteria of a
system and provide an explanation of how the system can be used

Documentation is the process of collecting, organizing storing and maintaining

historical record of programs and other documents used or prepared during the
different phases of the life cycle of the software

2.3.2 Uses of Documentation

❖ Documentation is used in many ways for different purpose. These are as follows:
(a) Documents facilitate communication about an application between the technical
development personnel and the non-technical users
(b) Documents are necessary during abnormal maintenance, i.e. when a new
programmer has to maintain old software system after the original programmer or
analyst has left the organization
(c) It is also very helpful to train the users. Good documentation will provide a sell-
instructional approach that will allow employees to learn at
their own pace
(d) Documents are also very helpful for trouble shooting when the application
system breaks down.
(e) Documents help corporate management to understand the system sufficiently to
make decisions and to appreciate its financial and resource implications
(f) Documentation can provide controls not only internal to the firm, but also
external to the business application such as audit trails.
(g) Documentation also helps in the evaluation process.

Documentation of a computer-based information system must be a clear, coherent

and complete description of the functioning system. It must be updated to retain its
relevance and must be well organized to be useful

Documentation of Program

❖ Documentation provides a general outline as well as a few specific details of the

overall program structure the documentation of a program or system is a
continuous process. After successfully completing the system installation, and
 running software packages, we must ensure that documentation is complete and is
in a finished, usable form. This includes both technical documentation for the
programmers who may be working on the system and modifying the completed
program and user-level documentation for the users of the program

❖ We may decide at a future date to add new features to the program, or we may
have to find and correct errors in the program, both of which can be Virtually
impossible if the technical documentation is inadequate.

A good user documentation is essential if a program is to be a useful tool. Good

technical documentation is essential for maintaining a program.

Aim of Program or System Documentation

❖ The main aim of documentation is to keep the system running in optimum

conditions. Some other reasons for the need for documentation are as follows:
(a) To help in the design of the system by working to a set of standards and for
making available a clear description of the work done so far. The documentation
needs to be kept up-to-date throughout the project.
(b) Good documentation ensures that all those involved in the system (system
designers, programmers and users) fully understand how their aspect of the system
will work, e.g. what data will be inputted and how, and what information will be
available from the system.
(C) To ensure that the system can be maintained after completion even though the
programmers involved in the original design or programming of the system may not
be available. It is essential that proper documentation is kept enabling a new
commerce to make necessary corrections, changes, or enhancements to the
program.

Contents of a Document of a System

The following are the contents of a document of a system:

(a) An accurate and up-to-date system specification
(b) System flowchart(s) or data flow diagrams (DFDs) showing the inputs to the
system, files required, processes to be carried out, and output from the system
(c) A description of the purpose of each program within the system
(d) Organization, contents, and layout of each file used
(e) Layout and contents of all output print and displays
(f) Listing of current versions of each program
(g) Test data and expected results
(h) Introductory note on type of documentation and its importance.
2.3.3 Critical Documents

❖ The following documents are critical for proper functioning of the new system.
These are to be prepared carefully and kept up-to-date continually till
the new system is in operation.
(a) Clerical Procedure Manual
(b) Operating Instructions
(c) Data Preparation Instructions

Clerical Procedure Manual

❖ These manual details the activities that the clerical staff will undertake in preparing
data for input to the system. For example, batching documents and calculating hash
totals. It will also describe what action is to be taken when errors occur, e.g. when a
validation program reports errors

Operating Instructions

❖ This document gives the details to the computer operator how to run the program.
It may include:
(a) Details of the procedure, for starting the program
(b) Details of disks, tapes or CD required
(c) Special stationery to be used
(d) The number of copies of each report, and who is to receive the output
(e) Backup procedures to be followed.
(f)Recovery procedures in the event of hardware failure

Data Preparation Instructions

❖ This will contain instructions on data entry, showing, if necessary, how each field
should be entered for example, a date field may be entered in different formats and
the correct one needs to be specified
In a small system written perhaps for a single user working on a micro-computer,
these three manuals may be combined into one User Manual

2.4 PRINCIPLES OF SYSTEM DOCUMENTATION

❖ Information systems continuously evolve and undergo changes with the changes in
the organizational procedures and processes to achieve various tasks System
documents typically archive various aspects of information systems, viz.
(a) Problem definition
(b) Reasons for introduction of a new information system
(c) Systems flow chart or DFDS
(d) Data and file specifications
(e) Input and output layouts
 (f) Program specifications
(g) System error control
(h) System test and maintenance plan
❖ With the changes in the organizational procedures and processes, users demand
changes in the end products of the information systems. This sets the chain reaction
across the information systems, leading to changes in one or more aspects
mentioned above. System documentation, thus, supports information systems
experts in system maintenance, updating and development. Certain principles that
are relevant in this respect are:

2.4.1 Archive the Changes

❖ The purpose of the documentation must remain in focus, any change that affects
any aspect mentioned above must be recorded systematically stating the change
itself, reason for change, proposed/carried out by whom, date, page number etc.

2.4.2 Version System

❖ Every updated system must be assigned a new version Old version must be
retained. Commercial software developers assign versions to their new software
Similarly in-house developers must also do so (Similarly, all other system documents
need to be changed and catalogued along with the new version Modern CASE tools
are very handy tools to carry out changes in the system and keeping systematic
records.

2.4.3 Control and Security of Systems Documents

❖ Systems documents along with source code are the property of the organization.
They need to be protected like any other fixed deposit document. Only designated
information system experts should handle these documents. Access rights are to be
given on need basis. Any breach of the source code and the design aspects in the
wrong hands can be detrimental to the organization

2.4.4 Proprietary Rights

❖ An information system developed by the outsourced agency must have "No sharing
of design and source code" clause and the relevant penalty clause in the agreement

2.5 TYPES OF DOCUMENTATION AND THEIR IMPORTANCE

❖ Different types of documentation needed are:

(a) Design Documentation
(b) Program Documentation
(c) Training Documentation
(d) Operations Documentation
 (e) User Reference Documentation
2.5.1 Design Documentation
❖ It describes the overall system design and includes system flow chart, all
input/output formats, file description control requirements and report
specifications
2.5.2 Program Documentation
❖ It consists of programming specification like program, graphic aids, input-output
formats etc.
2.5.3 Training Documentation
❖ It includes user training manuals and material to be used in the conversion and the
installation of system
2.5.4 Operations Documentation
❖ It contains instructions for normal operations as well as directions for handling
problems and break down of the system
2.5.5 User Reference Documentation
❖ It is used after training is over and the system Is installed. It should provide quick,
clear answers like a dictionary

2.6 ENFORCING DOCUMENTATION DISCIPLINE IN AN ORGANIZATION

❖ Documents play a variety of roles in any office Table 2.1 shows the generic roles
that are supported by the document-related activities.
❖ Documents and information system must be managed effectively as this function
affects the efficiency and the ability of an organization to deliver intended purpose
❖ The documentation-discipline in an organization pertains to their creation,
processing, storage retrieving and communication. These aspects Are mentioned
individually but these have overlapped implications. In relation to these factors the
following issues are important in enforcing documentation discipline

S.NO Generic Purpose Document-Related Activities

1. Coordination and Management of Managing documents by creating,

people and work storing, and communicating
2. Linking organization units and Scheduling individuals and groups by
projects. creating, managing, and communicating
documents, plans and calendars
3. Coupling the organization to (a) Communicating with individuals
outside groups and people and groups (initiating, receiving,
 and managing documents.)
(b) Managing data on individuals
and groups both internal and
external
(c) Managing Projects (Planning,
initiating, evaluating and
monitoring projects).

2.6.1 Creation of Documents

❖ Creating a document requires collation of facts from one or more databases. There
must be an unambiguous policy in respect of "access rights" of each individual
dealing with the databases. It must evolve on 'need-to-know basis'. A lot of effort
and time is spent, and draft copies are prepared before a final copy is ready. The
staff needs to be trained in respect of document format and manager's style and
choice. On-line checking and correcting could avoid wastages. This requires training
of managers at all levels for handling the computerized systems
2.6.2 Processing of Documents
❖ Processing of documents includes manipulation of data and creation of new data. In
this respect rights for "update and delete" must be clearly defined.
2.6.3 Storage of Documents
❖ It is one of the most important aspects in enforcing documentation discipline. The
salient features that must be catered to are:
(a) If the databases are integrated and accessed on time-sharing basis, each
department must have designated space on which it should store its documents.
Within each department, each end user must have dedicated directory/folder in
which he should archive his documents. Read/write rights are to be assigned
accordingly
(b) In case of single-user computing environment, each functional area must be
assigned a separate directory/folder.
(c) Within a folder there may be several files. The documents of policy nature may
be kept in a single file in a particular area of activity and routine correspondence
documents in a separate file. Documents pertaining to similar type of activity must
be kept in a single file and not be fragmented across several files.
(d) Files should be assigned meaningful names.
❖ (e) Back-up policy must be clearly enunciated. Who can keep the back up and type
of data they can handle on server or through floppies must be well established?
(f) Security and password system must be enforced.
2.6.4 Retrieving of Documents
❖ The success and end-user satisfaction of computerized information systems largely
depends on the ability of retrieving piece of data/information in shortest possible
time This is intimately linked to storage system and processing capability of the
hardware. If the storage system is well planned and staff and managers are trained
 properly to use the system, the retrieving of documents becomes easy. In this
respect it is necessary to strictly enforce the "read/write" rights of each end-user.
2.6.5 Communication of Documents
❖ Communicating documents, physically through floppies or through the network,
needs a thorough planning. Carrying hardcopy and magnetic media can be physically
checked and enforced through organizational policies and orders. Incoming
documents on the network can be checked for virus activities through firewalls etc.