Chapter 2

SYSTEM DEVELOPMENT APPROACH

AND DEVELOPMENT LIFE CYCLE

BY GIZAW H.
 System Development Approach and Development Life Cycle

Tasks in system analysis and design require use of standard and

prescribed process.
If IS development projects follow no prescribed process, we will have a
situation of complexity, anarchy or chaos.
 Each developer uses his/her own tools and methods
 Communication between team members would be difficult
 Success or failure depends on the skill and experience of the project team
 Life cycle …

 The process will be unpredictable and not repeatable

 The project may become over budget and behind schedule
 Documentation will be haphazard creating problems for maintenance.
 Insufficient user involvement alone may lead to dissatisfaction at the end.
A standard systems analysis and design methodology thus results in better
productivity by alleviating the above problems.
Accordingly there are 5/6 standard phases in a system development which
collectively referred as SDLC.
Phases in the SDLC
 1. Project identification and selection

This is the first stage where the need for a new or enhanced system is
identified.
This need may arise as a result of
 Problems faced by users in day to day operations or their desire to perform additional tasks (by end
users)
 From the realization that information systems could be used to capitalize an opportunity as a result of
the organization’s strategic planning process (by system analysts)
 A need for efficiency and effectiveness (by the management)
 Project Identification…

Once potential system development projects have been identified, they have to
be classified and ranked. IS projects can be ranked based on:
 Value chain analysis
 Strategic alignment
 Potential benefits
 Availability of resources
 Project duration or size
 Technical difficulty or risks
The final step in project identification and selection involves choosing some IS
projects among the ones ranked as above. Those projects perceived most likely
to achieve business objectives are selected.
 2. Project Initiation and Planning

 The planning phase is the fundamental process of understanding why an

information system should be built and determining how the project team will
go about building it. It has two steps:
1. During project initiation
 The system’s business value to the organization is identified
Most ideas for new systems come from outside the IS area (from the
marketing department, accounting department, etc.) in the form of a system
request
 2. Project Initiation and Planning

A system request presents a brief summary of a business need, and it

explains how a system that supports the need will create business value.
The IS department works together with the person or department that
generated the request (called the project sponsor) to conduct a feasibility
analysis.
The feasibility analysis examines key aspects of the proposed project.
The system request and feasibility analysis are presented to steering
committee, which decides whether the project should be undertaken.
 2. Project Initiation and Planning

2. Once the project is approved,

It enters project management. During project management, the project
manager creates a work plan, staffs the projects, and puts techniques in
place to help the project team control and direct the project through the
entire SDLC.
The deliverable for project management is a project plan that describes how
the project team will go about developing the system
 In general this phase involves a preliminary investigation of the
system problem or opportunity at hand and the presentation of
reasons why the system should or should not be developed by
the organization.
 This phase specifically involves such tasks as:
 Assessing feasibility of the IS development project
 Listing the activities involved in the project
 Preparing a (time) schedule of the activities (using tools like PERT
and Gantt charts)
 3. Analysis

Analysis involves a through study of an organization’s current procedures

and the information systems used to perform organizational tasks.
It consists of the following major tasks:
 Requirement gathering
 Requirements structuring
 Prepare initial design alternatives and choose between them at this stage.
 4. Design

Design involves converting the description of the recommended alternative

system into logical and then physical design specifications. This means we
have to specify
 What input forms would look like
 What output forms (reports) would look like
 What other interfaces and dialogues would look like
 The database design
 Architectural design of the system
 5. Implementation

At this stage the physical specification is turned into a working system, the
system is tested and then put to use.
This phase specifically involves:
 Coding
 Testing
 Installation
 Data conversion (data entry)
 User training
 Finalizing documentation
 6. Maintenance/User support

A system has to be maintained once it has been implemented.

Maintenance requests may arise as a result of
 Faults found in the system by users
 Better ways of doing a task using the system or improvements on the system thought by users
 Change in the nature of business functions or environment
Over time it becomes obvious that because of prohibitive nature the costs
spent to maintain a system may be necessary to throw it out and design a new
system which takes as back to the project identification and selection phase.
 Cross life cycle activities

 Fact finding- involves gathering data or feedback about different aspects

 Documentation and presentation- recording facts and specifications for a
system for current and future reference and communicating these findings
 Feasibility analysis- measuring how beneficial the development of an IS
would be to the organization
 Project management-defining, planning, directing, monitoring and controlling
a project to develop an acceptable system within the allotted time and budget.
Change management- training and convincing users about the change that is
going to happen as a result of the IS to be developed
 Methodologies in SAD

Methodology is a formalized approach or series of steps

All system development methodologies lead to a representation of the system
concept in terms of processes and data
Process-centered methodologies:-focus on defining the activities associated
with the system
Process-centered methodologies utilize process models as the core of the
system concept.
Analysts concentrate initially on representing the system concept as a set of
processes with information flowing into and out of the processes
 Methodologies…

Data-centered methodologies:-focus first on defining the contents of the data

storage containers and how the contents are organized.
Data-centered methodologies utilize data models as the core of the system
concept.
For example, analysts concentrate initially on identifying the data that must be
available to produce the payroll and organizing that data into well-defined
structures.
Object-oriented methodologies:-attempt to balance the focus between
processes and data.
Object-oriented methodologies utilize the Unified Modeling Language (UML)
to describe the system concept as a collection of objects incorporating both
data and processes.
 Waterfall development methodology

The original structured design methodology is waterfall development.

In this methodology analysts and users proceed sequentially from one phase to
the next.
The key deliverables for each phase are typically voluminous and are
presented to the project sponsor for approval as the project moves from phase
to phase.
Once the sponsor approves the work that was conducted for a phase, the phase
ends and the next one begins.
Waterfall….
 Waterfall….

This methodology is called waterfall development because it moves forward

from phase to phase in the same manner as a waterfall.
Although it is possible to go backward in the SDLC (e.g., from design back to
analysis), it is extremely difficult (imagine yourself as a salmon trying to swim
upstream in a waterfall.
Advantages of waterfall development
 system requirements are identified long before programming begins
 changes to the requirements are minimized as the project proceeds.

Disadvantages
 The design must be completely specified before programming begins and
 long time elapses between the completion of the system proposal in the analysis phase and the
delivery of the system (usually many months or years).
 Prototype methodology

Refers to designing and building a miniaturized (scaled-down) but functional

version of the proposed system.
Prototypes can be used to validate users’ requirements at the analysis and
design stages. In this approach users work with the prototype and tell the
analyst what they like and do not like about it
The analyst then brings the prototype back to users after improving it based on
their feedback.
This iterative process continues until users are satisfied with what the
prototype does.
Prototyping…
 Prototyping…

Using prototyping as an analysis and design tool has got the following
advantages:
 Prototyping involves users to great extent
 it captures users’ requirements in concrete terms than abstract or graphical form
 If User requirements are not clear or well understood e.g. for a totally new system
 If Only one or a few users involved
 If Communication problems have existed in the past, between users and analysts
 Iterative methodology

The process of iterative model is cyclic, unlike the more traditional models
that focus on a rigorous step-by-step process of development.
In this process, once the initial planning is complete, a handful of phases are
repeated again and again, with the completion of each cycle incrementally
improving and iterating on the software.
Iterative…
 Advantages of Iterative Model

The biggest advantage of this model is:

 Some working functionality can be developed and early in the software development life cycle
(SDLC).
 It is easily adaptable to the ever changing needs of the project as well as the client.
 It is best suited for agile organization.
 It is more cost effective to change the scope or requirements in Iterative model.
 Parallel development can be planned.
Testing and debugging during smaller iteration is easy.
Risks are identified and resolved during iteration; and each iteration is an
easily managed.
In iterative model less time is spent on documenting and more time is given
for designing.
One can get reliable user feedback, when presenting sketches and blueprints of
the product to users for their feedback.
 Disadvantage of iterative Model

More resources may be required.

More management attention is required.
It is not suitable for smaller projects.
Highly skilled resources are required for skill analysis.
Project progress is highly dependent upon the risk of analysis phase.
Defining increments may require definition of the complete system.
 Incremental Model

Incremental model is a process of software development where requirements

are broken down into multiple standalone modules of software development
cycle.
 Incremental development is done in steps from analysis design,
implementation, testing/verification, maintenance.
Each iteration passes through the requirements, design, coding and testing
phases. And each subsequent release of the system adds function to the
previous release until all designed functionality has been implemented
 Projects Planning/Selection Phase
33

The planning and selection phase of the SDLC consists of a

number of activities. They are as follows:
 Needs Identification/Problem Definition
 Generation of alternative solutions
 Feasibility Study
 Preparation of Proposal/Baseline Project Plan
 The major deliverable from this phase is: The proposal (also
known as Baseline Project Plan or Statement of Work or
Statement of Requirements).
 Projects Planning/Selection Phase
34

The Proposal includes information about all of the following:

 The Terms of Reference

 Project goal
 Scope

 Constraints
 A description of the proposed solution, at a conceptual level
 If a feasibility study was carried out, it includes a brief description of
the alternatives considered, and why they were rejected
 The project plan - at a high level, showing the estimated timings,
resources and schedules for the project
 Needs Identification/Problem Definition
35

The first step is to identify a need for a system. The identified

need can be the result of:
 finding shortcomings or problems in an existing system or process
 a requirement to provide information and/or reports from existing
systems
 new features required in an existing system
 a new idea for which an information system is required
 a requirement to improve efficiency in the organization
 compulsory standards or benchmarks imposed by an external organization e.g.
a government
 needing to keep up with competitors.
Factors that Affect Systems Projects
37
 Project identification and Initiation
38

Unplanned System Requests

Traditionally system owners and users initiate system projects
as they are closer to the organizational activities that need
improvement
Alternatively, systems analysts work on possible system
improvements
 Both these can be called as unplanned system requests
which are further screened and prioritized by a steering
committee of system owners.
 Project identification and Initiation
39

Planned System Requests

Is the result of one of the following earlier projects
 An information System strategy plan examines the plan as
whole to identify areas with greater return
 A business process redesign analyses a series of business
processes to eliminate redundancy and bureaucracy and to improve
efficiency.
 Project identification and Initiation
40

Planned or unplanned, the force for most projects is some

combinations of problems, opportunities or directives
Problems: are undesirable situations that prevent the
organization from fully achieving its purpose, goals, and/or
objectives.
Opportunities: are chances to improve the organization even in
the absence of specific problems.
Directives: are new requirements that are imposed by
management, government, or some external influence.
 Project identification and Initiation
41

 These problems, opportunities and directives can be generalized as

PIECES
P the need to improve performance
I the need to improve information (and data)
E the need to improve economics, control costs, or increase profits
C the need to improve control or security
E the need to improve efficiency of people & processes
S the need to improve service to customers, suppliers, partners,
employees, etc. This is also known as establishing the project goal or
problem definition.
 Project Selection
42

In a given organization, it is likely that many possible systems

development projects may be identified at a given time. In that case, it
is necessary to select those projects most likely to yield benefits
for the organization, given the available resources.
 In larger organizations, this process of identification and selection
tends to be more formal and rigorous and may be part of an overall,
higher-level planning process.
In a smaller organization, the process may be informal, allow
more independence for individual departments and managers
 Project Selection
43

The following are some of the factors or criteria that are used to select
projects:
 Perceived and real needs
 Existing and available resources
 List of potential and ongoing projects
 Current business conditions

In addition to these, the perspectives of the decision-makers will

influence the selection.
 Generation of Alternative Solutions
44

For an identified need, there are often several possible solutions. It is

not always best to use the first suggested solution that comes up.
Sometimes the solution is obvious, sometimes it is necessary to think
about alternative solutions. Possible ways of doing this are:
Brainstorming – gather various people from the organization into
one room, and get them all to talk and think about possible ways of
solving the problem.
 Generation of Alternative Solutions
45

• Such meetings should be facilitated i.e. there should be a

facilitator whose role it is to control the meeting, ensure the
agenda is covered, ensure all attendees get to contribute and
ensure that all suggestions and discussions are documented.
Look at existing systems – internally or in other
organizations, if possible.
 Define Scope & Constraints
46

The project scope is defined during this phase.

The purpose of defining the scope is to define the boundary
of the system and the project.
The scope shows what aspects of the system will and will not
be included in the project.
To help to define the scope, the systems analyst should
attempt to find answers to the following questions:
 Define Scope & Constraints
47

 What units of the organization (business departments,

functions and/or divisions) may use or be affected by the
proposed system?
 What existing systems might the proposed system need to
interact with, or which existing systems might be changed by the
proposed system?
 Who, inside or outside the organisation, cares about the
proposed system?
 What functions, or capabilities, will the system include and
what will it not be able to do?
 Define Scope & Constraints
48

Defining the scope at this stage will help to eliminate scope

creep during the life cycle of the project. Scope creep occurs
when new functionality or requirements are added to the system
later during the cycle (e.g. during Analysis or Design).
Often, these additions are small in size, but they can
significantly impact the cost and resources for the project. Many
small additions could cause the project to be completed late or
over budget.
 Define Scope & Constraints
49

Sometimes it is necessary to increase the scope during the life

of the project (e.g. if an essential function was omitted during
the needs identification) but generally it is preferable to try to
keep scope creep to a minimum.
Clearly defining the scope at this stage helps to make all
involved people aware of what is and is not included.
 Constraints
50

Any factors that will limit the proposed solution or system

should be documented at this stage. These are constraints
on the system. Constraints fall into the categories listed below:
 Schedule – e.g. the new system must be in operation by
March 17th 2020.
Cost – e.g. the budget for the new system is Birr100,000 so
the total cost cannot exceed this amount
 51

Technology – e.g. the organizations already has MS Access

and the new system must use this database package, or the
application must run on Windows XP.
Policy – e.g. a particular method of accounting must be used
 Feasibility Study
52

In some cases, there may be a number of alternative solutions to be

considered.
It is then necessary to choose one as the most suitable solution.
 It is best to investigate as many alternatives as possible to ensure that
the best possible solution is selected. This process is called the
Feasibility Study.
There are a number of different areas which may need to be examined in
terms of the feasibility of the project
Economic feasibility is probably the most used, as it is always important
to determine if a project will cost more than it will yield or save.
 Project Planning
53

The activity of project planning takes place throughout the life

cycle. It involves tracking the project progress as well as revising
the plan to take account of events as they occur.
In this phase, it is not possible to produce a detailed project plan
– because there is not yet enough detailed information about
requirements. However, it is possible to produce a plan that
shows the estimated timings for each phase of the project.
The ability to accurately estimate the times for each activity is a
skill that is acquired with experience of systems development
projects.
 Project Planning
54

It is difficult to estimate the times required if you have not got
experience of carrying out each activity.
 Where possible, the responsible person or team should also be
assigned to each task
 Dates for starting each activity can be assigned, to show when the
project is likely to be completed – note that some activities must
finish before the next one begins, while others can begin before the
previous one has finished. This is because there are dependencies
between activities.
 Prepare Proposal
55

The major deliverable from this phase is a document that provides

all the information discovered during the above activities.
The name of the document and the format and content of it vary
from one organization to another.
In an organization where the IT/IS department carries out systems
development for other departments, the document acts as an
agreement as to what the problem is, what the proposed solution is
and what are the scope and constraints for the proposed system.
 Prepare Proposal
56

In the case where an outside supplier is providing the systems

development service, this document acts as an agreement between
the supplier of the system/project and the customer.
In this case, the document may need to be more detailed – as it
forms the basis of a legal agreement between the two parties, and
a contract may also be signed.
The document may also be called a Baseline Project Plan or a
Statement of Work or a Statement of Requirements. The
exact content and amount of detail in the document depends on
the organization and the participating parties.
 Prepare Proposal
57

The document also includes project-planning information,

such as:
Schedule, at a high level (approximate timings for each of
the subsequent phases)
Estimated time of completion
Resources required (people and equipment)
The Proposal document will usually have sections for the
following:
 Prepare Proposal
58

Introduction – an overview of the project, and its objective.

Scope & Constraints – describe the scope of the project, in words
and/or with diagrams, and what constraints have been identified.
Proposed Solution – describe the proposed solution at a
conceptual level; if a feasibility study was carried out, the rejected
solutions can be mentioned also, along with reasons for rejecting
them.
Schedule – indicate the estimated schedule for the project, showing
also the estimated resources required to achieve the completion date.