Chapter 3

System Development Approaches

Basically, there are 2 ways to implement SDLC. IT projects today will follow either a structured
approach or a Rapid Application Development (RAD) which is a newer approach.

Structured Approach to System Development

The structured approach to system development has been around since 1960s and 1970s when large
mainframe applications were developed

Applications then were built when:

1) Systems were fairly simple and independent from one another

2) Computer hardware was relatively more expensive than labour

3) Development and programming tools were primitive compared to today (Satzinger, Jackson &
Burd, 2oo2).

The waterfall method in Fig 1.4 follows SDLC in a very sequential and structured manner e.g.
design activities start only after analysis and requirements activities have been completed.
Subsequently, development or programming activities would not commence until the design phase
is complete. Even though one can go back to previous stages, it’s not always easy or desirable.

Planning overhead is minimised because it’s all done up-front and a tangible system is not
produced until the end of life cycle (McConnell, 1996). The notion of waterfall is a metaphor of a
number of activities from one phase to the next. This approach emphases a sequential and logical
flow of development activities.

18
This approach is suitable when developing structured systems plus assumes that requirements
defined in analysis stage don’t change significantly over the rest of the project. In addition because
it will provide a firm structure that can minimise wasted effort this approach may work well when
the project team is inexperience or less technically competent (McConnell, 1996).

Rapid Applications Development (RAD)

On the other hand, one can take a less-structured approach to designing systems. Today, taking less
time to develop and implement an IS can provide organisation with competitive advantage.
Furthermore as evidenced by CHAOS study, larger projects that take longer to develop are riskier
than smaller and shorter projects.

Satzinger, Jackson & Burd (2002) defined RAD as “a collection of development approaches,
techniques, tools and technologies, each of which has been proven to shorten development
schedules under some conditions.”This implies that various development approaches, tools and
techniques and so on can be mixed and matched based on the project. For some projects, it implies
that waterfall approach is most appropriate. Nonetheless, RAD often follows one of the following
iterative approaches:

Prototyping

Prototyping is an iterative approach to systems development. Here the developer and user work
together very close to develop a partially or fully functional system as soon as possible probably
within a few weeks. Prototyping will go through a number of iterations as functional requirements
are defined and changed.

This approach is most helpful when the requirements of new system are difficult to define or when
working with a new technology where the capabilities of the technology are unknown or not very
well understood. A prototype may be either a throwaway system or a fully usable system.

Throwaway prototype could be used to discover or refine requirements specifications that can be
used as a model for developing the real system. On the other hand, a prototype may become the
actual system after going through a number of refinements over time.

Spiral Development

Another way to expedite SDLC is the spiral approach proposed by Boehm (1998). The spiral model
offers a risk-oriented approach in which software project is split into a number of mini projects
where each addresses one or more risks until all major risks have been addressed.

A risk can be defined as a poorly understood requirement or architecture or a potential problem

Thus completing each iteration brings the project closer to a fully functional system. Each iteration
should be reviewed as it offers a way of controlling project’s overall risk. The main challenges will
crop up early in project thereby providing the chance to reduce the total cost of project. The
disadvantage of spiral development approach centres on its complexities (Satzinger, Jackson &

19
Burd). Complexities in managing projects because many people are working on a number of
parallel activities.

Extreme Programming (XP)

Kent Beck introduced idea of XP in the mid 1990s. Under XP, system is transferred to users in a
series of versions called releases. A release would be developed by deploying several iterations
developed and tested within weeks or months. Any release is a working system that only includes
one or several functions which are part of a complete system specifications.

The XP embodies a number of activities where user requirements are documented first as a user
story. Object-oriented model known as class diagram is used to document user stories. So a release
is developed over the course of several iterations. A set of acceptance tests for each story is then
developed. The Releases that pass acceptance test are then considered complete The XP offers
continuous testing and integration of different software modules and components while supporting
active user involvement.

In addition, XP often incorporates team programming where 2 programmers work together on the
same workstation (WS). Small teams of developers often work in a common room where WSs are
positioned in the centre and workspace for each team member is positioned around the perimeter.
Developer often, are prohibited from working more than 40 hours a week in order to avoid burntout
and mistakes that often occur because of fatigue (Satzinger, Jackson & Burd).

PLC versus SDLC 1/5

You may still be wondering about the difference between PLC and SDLC. Even though they may
seem to be similar, the difference is that PLC focuses on processes of managing a project while
SDLC focuses on creating and implementing a product i.e. the IS. But in this context, our focus is
solely on PLC

Although SDLC and the particular approach chosen will have a direct impact on a project’s scope
(i.e. deliverables that project team must provide) including work activities needed to produce those
deliverables, in effect, activities number, their sequence, time to complete and resources required
will directly establish the project’s schedule and budget.

As depicted in Fig 1.5, SDLC is really part of PLC since most of the activities for developing IS
take place during the execution phase.

20
While the last 2 stages of the PLC – closing and evaluating project take place after IS
implementation, integration of PM and system development activities is one vital component that
differentiates IT projects from other types of projects.

Project management Knowledge Areas

The Guide to PMBOK defines 9 knowledge management areas for understanding project
management. These 9 knowledge management areas are portrayed in Fig 1.6 (PMBOK).

21
Project Integration Management

Integration focuses on coordinating project’s plan development, execution and control of changes.

Project Scope Management

Project scope is work to be completed by project team. Scope management offers assurance that
project’s work is defined accurately and completely plus that it is completed as planned.
Furthermore, scope management embodies ways to ensure that proper scope changes procedures
are in place.

Project Time Management

Time management is vital for developing, monitoring and managing projects’ scope. This includes
identifying project’s phases and activities plus estimating, sequencing and designing resources for
each activity to ensure that the project’s scope and objectives are met.

Project Cost Management

Cost management makes sure that project’s budget is developed plus completed as approved.

Project Quality Management

Quality management focuses on planning, developing and managing quality environment which
allows the project to meet or exceed stakeholders’ needs or expectations.

Project Human Resource Management

People are the most important resource on a project. Human resources management focuses on
creating and developing a team as well as understanding and responding appropriately to project’s
stakeholders.

Project Communications Management

Communications management entails communicating timely and accurately information about the
project to project’s stakeholders.

Project Risk Management

Every project faces a certain amount of risk. Project risk management is concerned with identifying
and responding appropriately to risks that can impact the project.

Project Procurement Management

Projects time and time again need resources (people, hardware, software, etc) which are outside
organisation. So procurement management makes certain that these resources are acquired
properly.

22
Summary of Knowledge Areas (Brewer & Dittman, 2010)

Introduction to Project Selection and Initiation

Before initiating the start of a project, project managers need to take a step back plus figure out
what project the organisation should embark on. In the past, many projects have been selected
because of a “squeaky wheel” syndrome i.e. the person who makes the most noise repeatedly gets
his or her project selected. You can see that this is not the best approach to choosing a project.

An organisation needs to go through a formal process of selecting the right mix of projects before
formalising list into a project charter plus start work. In most organisations, there are more projects

23
that there are funds plus people to run them. Organisations would need to be very selective when
choosing projects and these should be the ones that will return most value to the organisation.

Value in this case does not only relate to dollars (profit) but factors such as market share, customer
relations, safety issues, environmental concerns and new government regulations

Questions like!

 Why this project?

These are all questions that require being asking plus answering before work on project
commences. You only need to look at the dismal success rate of IT projects to be aware of why it’s
vital that organisations begin by selecting the right projects to work on. In the past, IT professionals
have carried out a poor job of understanding and presenting the value of IT project

The reasons for this poor performance are two folds:

First – IT professionals spend more time studying technology than finance

Second – they are unable to communicate effectively to management that IT projects are different
from projects in other industries and therefore require different metrics. IT professionals most
specifically managers and project managers must have an understanding of the broader picture of
the organisation plus impact that a technology project will have on it from cost and other
perspectives. They should understand and possess ability to communicate the value of IT projects
in terms that the rest of organisation can understand.

We will describe some of the techniques that will help project manager to communicate the value
of IT projects. In today’s business climate of tight budgets, limited IT resources and low IT
projects, organisations are becoming more and more selective in IT projects they approve. Also
most organisations are starting to realise the strategic importance of IT to their success. A survey
commissioned by InfoWorld in 2002 found out that 70% of respondents said that IT was
“absolutely essential to their company’s business objectives” (InfoWorld, 2002). To get projects
approved, IT managers must learn to align their projects with the company’s strategic direction. To
achieve this, project managers must ask themselves some key questions concerning a project so that
they can understand what value it provides to the organisation, the risks associated with the project
and project value to organisation if it’s successful. Andriole (2001) identified 4 key issues that must
be considered in order to understand the bigger organisational picture in which IT projects play a
role. They include: business value, technology, cost/benefit questions and risks.

Business Value

IT managers must look at a project from a business perspective through identification of what
business process(es) will be affected. They need to thoroughly understand what impact a project
will have on these processes. They must also understand what impact a project will have on
associated processes. Deploying systems approach assists in learning what impact a project will
have on all parts of the organisation.

24
Technology

Technology utilise for a project needs to be well tested, scalable, secure, modifiable and usable.
There are some questions that need to be asked:

 Has technology been deployed in the organisation before and do we have experience with
it?

 What technology is the competition using?

 And how might technology permit the organisation to see what works?

 And what does not work in a specific industry?

Cost/Benefit Questions

Organisations need to understand whether the complete cost including acquisition, development and
ongoing support costs of projects outweigh its benefits.

Risks

IT project managers must do a thorough risk assessment for the project. They must know what
kinds of issues or problems that might crop during the project such as software vendor going out of
business in the middle of the project or funding for project being cut in half during execution plus
be sure to have appropriate safeguards or workarounds in place so that the project can still be
completed. All of this information needs to be presented in the project’s business case.

25