|
|
|
|
|
|
Lesson#18
|
Systems Development Life Cycle
|
|
|
|
Systems Development Life Cycle
System Development Life Cycle (SDLC) is the overall process of
developing information systems through a
multi-step process from investigation of initial requirements
through analysis, design, implementation and
maintenance. SDLC is also known as information systems
development or application development. SDLC
is a systems approach to problem solving and is made up of
several phases, each comprised of multiple
steps. It describes the stages a system passes through from
inception until it is discarded or replaced. SDLC
provides
1. Structure
2. Methods
3. Controls
4. Checklist
18.1 Project lifecycle vs. SDLC
The systems development life cycle is a project management
technique that divides complex projects into
smaller, more easily managed segments or phases. Segmenting
projects allows managers to verify the
successful completion of project phases before allocating
resources to subsequent phases. Although System
development can be seen as a project in itself, but the
attribute that makes system development different
from regular projects is that a project has a definite end and
it is unlikely that ongoing maintenance will be
included in the scope of the project but this falls in the
definition of SDLC.
18.2 Types of System Development Life-Cycle Model
The concept of system development lifecycle model has been
explained in various shapes and forms. The
concluding form follows the same spirit except for minor
differences.
Waterfall model / Classic lifecycle/ Linear Sequential Model
The waterfall model is a software development model (a process
for the creation of software) in which
development is seen as flowing steadily downwards (like a
waterfall) through the various phases
Incremental Models
In incremental models, software is built not written. Software
is constructed step by step in the same way a
building is constructed. The products is designed, implemented,
integrated and tested as a series of
incremental builds, where a build consists of code pieces from
various modules interacting together to
provide a specific functional capability and testable as a
whole.
Iterative Models
In these models customer feed back is taken at each phase and
project is modified accordingly – if need be.
72
Prototypes are used in these models.
Need Assessment
Information systems are usually developed on need-basis, that
is, problems and opportunities arise and
render system development necessary. In this phase the
stakeholders must attempt to come to some
understanding of the nature of the problem or opportunity they
are addressing. Issues which can be
considered in this phase are. Is the problem
•
Well
structured/Structured -- constrained problems with convergent solutions, limited
number of rules
and principles within well-defined parameters.
•
Unstructured -- multiple
solutions, fewer parameters, and contain uncertainty about which concepts and
rules.
Should formal terms of reference be prepared and approved by the
steering committee or project
committee? This depends on the size, impact and cost of the
system being prepared. The TOR usually
covers following aspects.
•
Investigation on
existing system
•
Definition of system
requirements
•
Specifying performance
criteria for the system
•
Detailed cost budget
•
Draft plan for
implementation
If the problem is decided to be addressed, the level of
acceptance that exists among the stakeholders on the
need of change. The level of technological uncertainty the
proposed solution to the problem/opportunity
has. The most critical phase is the agreement of the
stakeholders on the definition of problem and
parameters of solution.
Entry and Feasibility Study
The purpose of this phase is to obtain a commitment to change
and to evaluate whether cost effective
solutions are available to address the problem or opportunity
that has been identified. Following examples
can be considered to explain this situation.
•
Say a problem has been
recognized by a group of users. They believe they can design and implement a
solution themselves using a high level language. Their proposed
system will have little impact on others
within the organization, nor will it be material from the
viewpoint of the overall organization. In this
situation, the users are already motivated to bring about
change. Thus activities to accomplish successful
entry are minor or unnecessary.
•
On the other hand,
consider a solution where potential solutions will have a widespread impact on
the
overall organization. Activities to accomplish successful entry
are now critical. Information systems
professionals must seek to establish themselves as legitimate
change agents among the stake holders.
Moreover they must seek to foster among the stakeholders a
commitment to change. If potential
solutions will have a significant impact on task and social
systems, a spirit of collaborative analysis and
evaluation among stakeholders must be developed.
Once the entry is successful, a preliminary study can be carried
out to evaluate the feasibility of the new
system. A Feasibility study team should be constituted
•
Draw representatives
from the departments affected by the project
73
•
At least one person must
have a detailed knowledge of computers and systems design (called system
analyst).
•
At least one person
should have a detailed knowledge of
•
The organization
•
How current system
operates
•
Information needs of the
system
•
Defects in the existing
system
•
Consultants from the
outside
Key Areas of Feasibility
Following aspects/criteria can be covered in a feasibility
study.
•
Technical Feasibility –
is the available technology sufficient to support the proposed project? Can the
technology be acquired or developed?
•
Response times – time
between request and execution
•
Volume of transactions
which can processed within the given time
•
Capacity to hold files
or records of a certain size
•
Number of users
supported without execution
•
Operational
Feasibility
– compliance and
adjustability with the way organization works with attitude to
change or chains of command.
•
Can the input data be
collected for the system?
•
Is the output usable?
•
Economic
feasibility
– Do the benefits of the
system exceed the costs?
It should be the BEST OPTION among those under consideration for
the same purpose.
•
Behavioural feasibility
– What impact will the system have on the user’s quality of working life?
•
Reduction is job stress
•
Job satisfaction
•
Quality of output by
employees
18.3 Costs of Proposed System
74
18.4 Benefits from the proposed system
When a system is being introduced, management should consider
the impact and amount of proposed
benefits. The purpose of this activity is to consider and
•
Better decision making
•
Savings
•
Possible in staff costs
through increase of efficiency and not necessarily through redundancies.
•
In costs of running the
department through more organized and efficient computerisation.
•
More sales revenue
•
Efficient use of staff
time
•
Customer satisfaction
•
Better planning of
resources required for operations e.g. inventory ordering, fixed asset
utilization.
18.5 Classic lifecycle Model / Waterfall Model
Waterfall model is the earliest of software process models.
Cascade of phases, the output of one is input to
the next. The waterfall model is a software development model (a
process for the creation of software) in
which development is seen as flowing steadily downwards (like a
waterfall) through the various phases.
Various phases of waterfall model are
•
Need Assessment
•
Entry and feasibility
study
•
Analysis of the existing
system
•
Information processing
systems design – This also includes
•
Formulation of strategic
requirements
•
Organizational & job
design
75
•
Program Development –
this includes
•
Application software
acquisition & development
•
Hardware/system software
acquisition
•
Procedures development
•
Testing
•
Conversion
•
Operating & maintenance
1
Waterfall Model
Need
Assessment
Entry &
Feasibility
Study
System
Analysis
System
Design
Next
15
Waterfall Model
Procedures
Development
Program
Development
Testing
Operations &
Maintenance
Changeover
Previous
76
Two phases need assessment and feasibility study, have already
been explained in detail. Now let’s take a
look at other phases one by one.
18.6 Analysis of Existing system
Once feasibility has been drawn up, next stage comes for
analysis of existing system. Even if the existing
system is to be replaced the designers must study the existing
system as this improves the quality of the
work. For example
The new system may change the way employees are rewarded. In
such a case the redistribution of rewards
may have to be carefully negotiated. Concerns of employees
cannot be ignored. Analysis is a two-part
episode. Studying organization’s history, structure, culture –
this would help to understand
•
The social & task
systems
•
The way systems are
coupled
•
Willingness of
stakeholders to change (Change Management to be discussed later)
The greater the impact of the new system, greater time should be
spent in understanding the present
organization. Analysis of existing product & information flows.
This includes the use of various tools for
documenting the existing system. What these tools are will be
discussed in detail in later Lessons.
System Design
System design includes the desired features and operations in
detail, including screen layouts, business rules,
process diagrams other documentation. It involves converting the
informational, functional, and network
requirements identified during the initiation and planning
phases into unified design specifications. This
includes
•
Formulation of strategic
requirements
•
Organizational & job
design
•
Elicitation of detailed
requirements
•
Design of the
information flow
•
Design of database
•
Design of user interface
•
Physical design
•
Design of hardware &
software platform
Formulation of Strategic Requirements
The overall goals and objectives the system must accomplish.
Forms can be accomplished in any form, for
instance:
•
A vague goal – increase
in the wealth of shareholders
•
A specific goal – reduce
staff turnover by 30%
Strategic requirements for the new system are identified based
on perceived deficiencies of existing system.
Trying to fit people and organizations into information systems
has been major reason for failure. If
strategic requirements are clear, stakeholders are better placed
to consider and evaluate alternative designs.
Organizational & Job Design
77
Change in the strategic requirements will necessitate the change
in the following for the parts of the
organization being affected
•
Organizational structure
•
Job descriptions for new
or change in existing ones
Trying to fit people and organizations into information systems
has been major reason for failure. So
change in both the above is important. If uncertainty surrounds
the tasks to be accomplished in the
proposed system, loose organic organizational structures and job
designs might be successful. Such promote
creativity and innovations. If organization is dominated by top
management and culture is autocratic,
employees might be unwilling to accept the high level of
responsibility.
18.7 Elicitation of Detailed Requirements
Designers must understand
•
What information an IS
must provide
•
The data that must be
captured to produce this information
Two approaches can be followed
•
Ask the stakeholders
what they require – helps when they are clear about the requirements on
the basis of past experience or good understanding.
•
Analysis &
experimentation – Where the ones bearing interest are not clear or have no past
experience, onus falls on the designer to work out the
requirements. |
|
|
|
|
|
|