Systems development methodologies

A Systems development methodology is a standard set

of steps, that organizations use to develop and support
their information systems. It is a standard process
followed in an organization to conduct all the steps
necessary to analyze, design, implement, and maintain
information systems. There are various systems
development methodologies, and they vary in terms of
the progression that is followed through the phases of
the systems development
 A Systems Development Life Cycle (SDLC) sometimes
referred to as the waterfall model or classic life cycle, is the
traditional methodology used to develop, maintain, and
replace information systems. It is a structured systems
analysis and design methodology that follows a set of five
fundamental phases: Planning, Analysis, Design,
Implementation and Maintanance.Each phase is itself
composed of a series of steps, which rely on techniques
that produce deliverables (specific documents and files
that explain various elements of the system)
Waterfall Model

With waterfall model, the analysts and users proceed

sequentially from one phase to the next.
Planning

In this phase, the need for a new or enhanced system

is identified. These needs are then analysed,
prioritized and arranged into a plan for the IT
department. The Phase starts with a project initiation
where the system’s business value to the organization
is identified (how the system will lower costs or
increase revenues)
Most ideas for new systems come from outside the IT
department (from the marketing department,
accounting department, etc.) in the form of a system
request. 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 IT
department will then work together with the person
or department generating the request to conduct a
feasibility analysis.
The system request and feasibility analysis are
presented to an information systems approval
committee (sometimes called a steering committee),
which decides whether the project should be
undertaken
Once the project is approved, the project manager
creates a work plan, establishes the size and
boundaries of the project, constraints or limitations of
the project, staffs the project, 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
FEASIBILITY ANALYSIS
Feasibility is the measure of how beneficial or practical the development
of information system will be to an organization The feasibility analysis
examines the following aspects of the proposed project:

1.Technical feasibility (Can we build it?)

2.Economic feasibility (Will it provide any business value?)

3.Operational feasibility (If we build it, will it be used?)

4.Schedule Feasibility
.
Technical feasibility

Technical Feasibility assesses the extent to which the system

can be successfully designed, developed, and installed by the IT
group. Technical feasibility analysis is, in essence, a technical
risk analysis that strives to answer the question: “Can we build
it?” Many risks can endanger the successful completion of the
project. First and foremost is the users’ and analysts’
familiarity with the application.
When analysts are unfamiliar with the business application area,
they have a greater chance of misunderstanding the users or
missing opportunities for improvement. The risks increase
dramatically when the users themselves are less familiar with an
application. In general, the development of new systems is riskier
than extensions to an existing system, because existing systems
tend to be better understood.
Familiarity with the technology is another important
source of technical risk. When a system will use
technology that has not been used before within the
organization, there is a greater chance that problems
and delays will occur because of the need to learn how
to use the technology. Risk increases dramatically when
the technology itself is new.
Project size is an important consideration, whether measured
as the number of people on the development team, the length of
time it will take to complete the project, or the number of distinct
features in the system.
Larger projects present more risk, because they are more
complicated to manage and because there is a greater
chance that some important system requirements will be
overlooked or misunderstood. The extent to which the
project is highly integrated with other systems (which is
typical of large systems) can cause problems, because
complexity is increased when many systems must work
together.
Compatibility of the new system with the technology
that already exists in the organization. Systems rarely
are built in a vacuum—they are built in organizations
that have numerous systems already in place.New
technology and applications need to be able to
integrate with the existing environment for many
reasons. They may rely on data from existing
systems, they may produce data that feed other
applications, and they may have to use the
company’s existing communications infrastructure.
Economic Feasibility
Economic feasibility also known as cost–
benefit analysis is determined by identifying
costs and benefits associated with the system,
assigning values to them, calculating future
cash flows, and measuring the financial
worthiness of the project. As a result of this
analysis, the financial opportunities and risks of
the project can be understood and the
common assessment measures that are used.
Identifying Costs and Benefits
The systems analyst’s first task when performing an economic
feasibility analysis is to identify the kinds of costs and benefits
of the project.The costs and benefits can be broken down into
four categories:

(1) Development costs,

(2) Operational costs,
(3) Tangible benefits
(4) Intangible benefits
Development costs
Development costs are those tangible expenses
that are incurred during the creation of the
system, such as salaries for the project team,
hardware and software expenses, consultant fees,
training, and office space and equipment.
Development costs are usually thought of as one-
time costs.
Operational costs
Operational costs are those tangible costs that are
required to operate the system, such as the salaries
for operations staff, software licensing fees,
equipment upgrades, and communications charges.
Operational costs are usually thought of as ongoing
costs.
Tangible benefits
Tangible benefits include revenue that the system
enables the organization to collect, such as increased
sales. In addition, the system may enable the
organization to avoid certain costs, leading to another
type of tangible benefit: cost savings. For example, if
the system produces a reduction in needed staff, lower
salary costs as a result. Similarly, a reduction in required
inventory levels due to the new system produces lower
inventory costs. In these examples, the reduction in
costs is a tangible benefit of the new system.
Intangible benefits
Intangible costs and benefits are more difficult to
incorporate into the economic feasibility analysis
because they are based on intuition and belief rather
than on “hard numbers. Nonetheless, they should be
identified along with the tangible items.
Assigning Values to Costs and Benefits
Once the types of costs and benefits have been identified, the
analyst needs to assign specific dollar values to them. The most
effective strategy for estimating costs and benefits is to rely on
the people who have the best understanding of them. For
example, costs and benefits that are related to the technology
or the project itself can be provided by the company’s IT group
or external consultants, and business users can develop the
numbers associated with the business (e.g., sales projections,
order levels)
The company also can consider past projects, industry
reports, and vendor information, although these sources
probably will be a bit less accurate. Likely, all of the
estimates will be revised as the project proceeds. What
about the intangible benefits and costs? Sometimes, it is
acceptable to list intangible benefits, such as improved
customer service, without assigning a dollar value. Other
times, estimates have to be made regarding how much an
intangible benefit is worth.
Suppose that a system claims to improve customer service.
This benefit is intangible, but let’s assume that the
improvement in customer service will decrease the number
of customer complaints by 10% each year over three years
and that $20,000 is currently spent on phone charges and
phone operators who handle complaint calls. Suddenly,
there are tangible numbers with which to set goals and
measure the originally intangible benefit.
Cash Flow Analysis and Measures

IT projects commonly involve an initial investment that produces a

stream of benefits over time, along with some ongoing support costs.
Therefore, the value of the project must be measured over time. Cash
flows, both inflows and outflows, are estimated over some future
period. Then, these cash flows are evaluated using several techniques to
judge whether the projected benefits justify incurring the costs. A cash
flow projection is shown in Figure 1 to demonstrate these evaluation
techniques.
Fig 1 : Cash Flow Projection
A system is developed in Year 0 (the current year) costing
$100,000. Once the system is operational, benefits and
ongoing costs are projected over three years. In row 3 of this
figure, net benefits are computed by subtracting each year’s
total costs from its total benefits. Finally, in row 4, we have
computed a cumulative total of the net cash flows
Two of the common methods for evaluating a project’s worth are:
1. Return on Investment
2. Break-Even Point (Payback period)
 1.Return on Investment

The return on investment (ROI) is a calculation that measures

the average rate of return earned on the money invested in
the project. ROI is a simple calculation that divides the
project’s net benefits (total benefits - total costs) by the total
costs. The ROI formula is:
ROI =Total Benefits - Total Costs X 100
Total Costs
Using values in Fig 1 :

ROI = 152 000 – 138 000 X 100

138 000

= 10.14%
A high ROI suggests that the project’s benefits far
outweigh the project’s cost, although exactly what
constitutes a high ROI is unclear. ROI is commonly used
in practice; however, it is hard to interpret and should
not be used as the only measure of a project’s worth.
 2.Break-Even Point

Another common approach to measuring a project’s worth is the

break-even point. The break-even point (also called the payback
method) is defined as the number of years it takes an organisation
to recover its original investment in the project from net cash
flows. As shown in row 4 of Figure 1, the project’s cumulative cash
flow figure becomes positive during Year 3, so the initial investment
is paid back over two years plus some fraction of the third year.
BEP= Number of years
of negative cash flow + That year’s Net - That year’s Cumulative Cash Flow
Cash Flow
That year’s Net Cash Flow

* Where “that year’s” refers to the year in which Cumulative Cash Flow turns
positive
Using values in Fig 1 :

BEP = 2+ 41 000 – 14 000

41 000

2 + 28 000 = 2.68 years

41 000
The break-even point is intuitively easy to understand and does give
an indication of a project’s liquidity, or the speed at which the project
generates cash returns. Also, projects that produce higher returns
early in the project’s life are thought to be less risky, since we can
anticipate near-term events with more accuracy than we can long-
term events. The break-even point ignores cash flows that occur after
the break-even point has been reached; therefore, it is biased against

longer-term projects.
Discounted Cash Flow Technique

The return on investment and break-even point

calculations both share the weakness of not
recognizing the time value of money. In these analyses,
the timing of cash flows is ignored. A dollar in Year 3 of
the project is considered to be exactly equivalent to a
dollar received in Year 1. Discounted cash flows are
used to compare the present value of all cash inflows
and outflows for the project in today’s dollar terms.
 The key to understanding present values is to recognize that if
you had a dollar today, you could invest it and receive some rate
of return on your investment. Therefore, a dollar received in the
future is worth less than a dollar received today, since you forgo
that potential return. The basic formula to convert a future cash
flow to its present value is:
PV= Cash flow amount
(1+ rate of return)n

where n is the year in which the cash flow occurs.

The rate of return used in the present value
calculation is sometimes called the required rate of
return, or the cost of obtaining the capital needed to
fund the project. Many organizations will have
determined the appropriate rate of return to use
when analyzing IT investments. The systems analyst
should consult the organization’s finance
department.
 Net Present Value (NPV)

The NPV is simply the difference between the total present value of the
benefits and the total present value of the costs.
NPV =∑ PV of Total Benefit - ∑ PV of Total Costs
As long as the NPV is greater than zero, the project is considered
economically acceptable. Unfortunately for this project, the NPV is less
than zero, indicating that for a required rate of return of 10%, for this
project should not be accepted. The required rate of return would have
to be something less than 6.65% before this Project returns a positive
NPV.This example illustrates the fact that sometimes the ROI and BEP
find that the project appears acceptable, but the more rigorous and
financially correct NPV technique finds the project is actually
unacceptable.
Operational Feasibility
It is a measure of how well the solution will work in an
organization. It is also a measure of how people feel about the
system/project. So, this feasibility is people oriented. Operational
feasibility addresses two major issues:
a. Is the problem worth solving with an information system , or will
the solution to the problem work?
b. How do end users and management feel about the problem /
solution?
Schedule Feasibility
It is a measure of how reasonable the project timetable is.
Schedule feasibility is the determination of whether the time
allocated for a project seems accurate. Projects are initiated with
specific deadlines. It is necessary to determine whether the
deadlines are mandatory or desirable. If the deadlines are
desirable rather than mandatory, the analyst can propose
alternative schedules.
 Analysis Phase
During this phase, the analyst studies the current system and
proposes alternative replacement systems. Here, the analyst
thoroughly studies the organization’s current procedures and the
information systems used to perform organizational tasks. The
analyst works with users to determine what the users want from
a proposed system. The analyst carefully studies any current
systems, manual and computerized, that might be replaced or
enhanced as part of this project
The analyst studies the requirements and structures them
according to their interrelationships and eliminates any
redundancies; generates alternative initial designs to match
the requirements ; compare these alternatives to determine
which best meets the requirements within the cost, labour,
and technical levels the organization is willing to commit to
the development process
The output of this phase is a description of the recommended
alternative solution. Once the recommendation is accepted
by owners, you can begin to make plans to acquire any
hardware and system software necessary to build or operate
the system as proposed.
 Design Phase
During this phase, the analyst converts the description of the
recommended alternative solution into logical and then
physical system specification. Logical design is the part of the
design process that is independent of any specific hardware
or software platform. Theoretically, the system could be
implemented on any hardware and systems software.
Physical design is the part of the design phase in which the
logical specifications of the system form logical design are
transformed into technology-specific details from which all
programming and system construction can be accomplished.
The design phase decides how the system will operate
in terms of the hardware, software, and network
infrastructure that will be in place; the user interface,
forms, and reports that will be used; and the specific
programs, databases, and files that will be needed.
 Implementation Phase

In this phase, the information system is coded, tested,

installed, and supported in the organization. During
coding, programmers write the programs that make up
the information system. During testing, programmers
and analysts test individual programs and the entire
system in order to find and correct errors
During installation, the new system becomes a part of the

daily activities of the organization. Implementation

activities also include initial user support such as the

finalization of documentation, training programs, and

ongoing user assistance.

 Maintenance Phase

In this phase, information system is systematically repaired and

improved. When a system is operating in an organization, users
sometimes find problems with how it works and often think of
better ways to perform its functions. Also the organization’s
needs with respect to the system change over time. In
maintenance, you make the changes that users ask for and
modify the system to reflect changing business conditions
 Advantages of the waterfall methodology

Waterfall development methodologies have the

advantages of identifying requirements long before
programming begins and limiting changes to the
requirements as the project proceeds.
 Disadvantages of the waterfall methodology

• It is often difficult for the customer to state all requirements

explicitly. The linear sequential model requires this and makes
difficulty to respond to changing customer requirements.
• A working version of the system will be available to customers
late in the project time-span. A major blunder, if undetected until
the working program is reviewed, can be disastrous.
• The linear nature of the classic life cycle leads to “blocking
states” in which some project team members must wait for other
members of the team to complete dependent tasks.
• User involvement is limited.
 Parallel development

The parallel development methodology evolved to address the

lengthy time frame of waterfall development. Instead of doing
the design and implementation in sequence, a general design for
the whole system is performed. Then the project is divided into
a series of subprojects that can be designed and implemented in
parallel. Once all subprojects are complete, there is a final
integration of the separate pieces, and the system is delivered.
Parallel development
Parallel development reduces the time required to
deliver a system, so changes in the business
environment are less likely to produce the need for
rework. The approach adds a new problem: If the
subprojects are not completely independent, design
decisions in one subproject may affect another, and at
the project end, integrating the subprojects may be
quite challenging.
 Rapid Application Development

Rapid application development is a collection of

methodologies that emerged in response to the weaknesses
of waterfall development and its variations. RAD
incorporates special techniques and computer tools to speed
up the analysis, design, and implementation phases in order
to get some portion of the system developed quickly and into
the hands of the users for evaluation and feedback
CASE (Computer-Aided Software Engineering) tools such as Microsoft visio
and fourth-generation visual programming languages such as Visual
Basic.NET may all play a role in RAD.

While RAD can improve the speed and quality of systems development, it
may also introduce a problem in managing user expectations. As systems
are developed more quickly and users gain a better understanding of
information technology, user expectations may dramatically increase and
system requirements may expand during the project (sometimes known
as scope creep or feature creep).
 Approaches to RAD

RAD may be conducted in a variety of ways but two common

approaches are Iterative development and Prototyping.

Iterative development breaks the overall project into a series

of versions that are developed sequentially. The most
important and fundamental requirements are bundled into
the first version of the system. This version is developed
quickly by a mini-waterfall process, and once implemented,
the users can provide valuable feedback to be incorporated
into the next version of the system.
Iterative development
Iterative development gets a preliminary version of the
system to the users quickly so that business value is
provided. Since users are working with the system,
important additional requirements may be identified and
incorporated into subsequent versions. The chief
disadvantage of iterative development is that users begin
to work with a system that is intentionally incomplete.
Users must accept that only the most critical requirements
of the system will be available in the early versions and
must be patient with the repeated introduction of new
system versions.
 Prototyping

Prototyping is a rapid, and incremental process of systems

development in which requirements are converted to a working
system that is continually revised through close work between
the development team and the users. In prototyping, the analyst
works with users to determine the initial or basic requirements
for the system. The analyst then quickly builds a prototype.
When the prototype is completed, the users work with it and tell
the analyst what they like and do not like about it.
 System Prototyping

System prototyping performs the analysis, design, and

implementation phases concurrently in order to quickly develop
a simplified version of the proposed system and give it to the
users for evaluation and feedback.
System prototyping
The system prototype is a quick version of the system and
provides minimal features. Following reaction and comments
from the users, the developers reanalyse, redesign, and
reimplement a second prototype that corrects deficiencies and
adds more features. This cycle continues until the analysts, users,
and sponsor agree that the prototype provides enough
functionality to be installed and used in the organization. System
prototyping very quickly provides a system for users to evaluate
and reassures users that progress is being made.
The approach is very useful when users have challenges
expressing requirements for the system. A disadvantage,
however, is the lack of careful, methodical analysis prior
to making design and implementation decisions. System
prototypes may have some fundamental design
limitations that are a direct result of an inadequate
understanding of the system’s true requirements early in
the project.
Throwaway prototyping

Throwaway prototyping prototypes primarily to explore design

alternatives rather than as the actual new system (as in system
prototyping).
Throwaway prototyping
Throwaway prototyping has a fairly thorough analysis phase that is
used to gather requirements and to develop ideas for the system
concept. Many of the features suggested by the users may not be
well understood, however, and there may be challenging technical
issues to be solved. Each of these issues is examined by analysing,
designing, and building a design prototype. A design prototype is
not intended to be a working system. It contains only enough detail
to enable users to understand the issues under consideration.
Agile Development

Agile development is a group of programming-centric

methodologies that focus on streamlining the SDLC. Much of the
modelling and documentation overhead is eliminated; instead,
face-to-face communication is preferred. A project emphasizes
simple, iterative application development in which every iteration is
a complete software project, including planning, requirements
analysis, design, coding, testing, and documentation.
Cycles are kept short, and the development team focuses on
adapting to the current business environment. There are several
popular approaches to agile development, including extreme
programming (XP), Scrum, and dynamic systems development
method (DSDM).