S YSTEM A NALYSIS AND DESIGN –

LECTURE 3

•I n f o r m a t i o n System Project
L EARNING O BJECTIVES
Explain clearly the concept of a software process
a nd a software process model
Describe t h e different software process
models
Propose and justify which software models are to
be used in a particular case study
R E CAP
Business Process Management (BPM)
Relationship between BPM and system analysis
a nd design
PM lifecycle
S YSTEM DEVELOPMENT (1)
Initial development of a new system is usually
done as a project.
The activities required to develop a new system
are identified, planned, organized, and
monitored.
Think of a project as a plan undertaking t h a t has a
beginning and a n end and produces some definite
result.
Some projects are very formal, whereas others
are so informal
S YSTEM DEVELOPMENT (2)
To manage a project with analysis, design, and
other development activities, we need a project
management framework to guide a nd coordinate
the work of the project team.
The Systems Development Life Cycle (SDLC)
identifies all the activities required to build,
launch, a nd maintain a n information system.
SDLC includes all the activities t h a t are par t of:
systems analysis, systems design, programming,
testing, and maintaining the system as well as other
project management processes t h a t are required to
successfully launch and deploy the new information
system.
S YSTEM DEVELOPMENT (3)
Many approaches to the SDLC and many variations
for projects t h a t have various needs.
However, there is a core set of processes t h a t is always
required
Six core processes required in the development of any
new application:
Identify the problem or need and obtain approval to
proceed.
Plan and monitor the project—what to do, how to do it, and
who does it.
Discover and understand the details of the problem or the
need.
Design the system components t h a t solve the problem or
satisfy the need.
Build, test, and integrate system components.
Complete system tests and then deploy the solution.
SOFTWARE PROCESS MODELS

Waterfall Model
Prototyping Model
Incremental Model
W ATERFALL M ODEL
Plan-driven model. Separate and distinct phases of specification and
development.
There are separate identified phases in the waterfall model:
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance

The Waterfall model (Royce,1970) also known as the Linear

Sequential model, was derived from engineering models to put
some order in the development of large software products.

The following phase should not st a rt until the previous phase has
finished. In practice, the stages overlap a nd feed information to
each other.

It enforces a disciplined approach as each step should be

completed.
W ATERFALL MODEL (1)
W ATERFALL MODEL (2)
Requirements analysis and d e fin it io n : Th e
functionalities to be provided by the system (e.g a search
engine, a password-protected login) are established
through consultation with end-users.
S y s t e m a n d s o f t w a r e d e s i g n : During this phase, a n
overall system architecture is established so t h a t the
developer can get a n idea how the different sub-systems
interact together.
I m p l e m e n t a t i o n a n d U n i t t e s t i n g : During this stage,
the software is implemented as a set of programs or
program units, using a n appropriate programming
platform. After the software has been implemented, the
software is tested to ensure t h a t it is working properly.
W ATERFALL MODEL (3)
Integration a n d system testing: The
individual program units or programs are
integrated and tested as a complete system to
ensure t h a t the software requirements have
been met.
O p e r a t i o n a n d m a i n t e n a n c e : The system is
installed at the customer’s site and end-users
are trained to use the system. Maintenance
involves correcting errors t h a t were not
discovered in earlier stages of the life cycle, in
order to improve the performance of the
system.
C HARACTERISTICS OF WATERFALL MODEL

The project activities are divided into

discrete, isolated stage.
The following phase should not s t a r t until
the previous phase has finished. Each
stage relies on the information produced
by the previous stage.
It enforces a disciplined approach as each
step should be completed.
D RAWBACKS OF WATERFALL MODEL (1)
The main drawback of the waterfall model is the
difficulty of accommodating change after the process
is underway. In principle, a phase h as to be complete
before moving onto the next phase.
Inflexible partitioning of the project in t o distin ct
stages makes it difficult to respond t o ch a n gin g
customer requirements.
Therefore, this model is only appropriate when the
requirements are well-understood an d changes will be
fairly limited during the design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large systems
engineering projects where a system is developed a t
several sites.
In those circumstances, the plan-driven nat ur e of the
waterfall model helps coordinate the work.
D RAWBACKS OF WATERFALL MODEL (2)
Commitments made a t a n early stage in the
process. This makes it difficult to respond to
changing customer requirements.
Distinct stages may become blocking st a t es
wh er e t ea m m em ber s m u st wa it for ot h er
members to complete dependent tasks.
It is difficult for cu st omer t o st a t e a ll
requirements explicitly.
The model has trouble accommodating the
uncertainty associated with incomplete
requirements a t the s t a r t of the project.
Does not support reuse.
Does not maintain customer involvement.
ACTIVITY
Give a n example
(1)where it is advisable to use waterfall model as
a software process (with justifications).
(2)wh er e it is n ot a dvisa ble t o u se wa t er fa ll
model as a software process (with justification)
P ROTOTYPING MODEL
A prototype is a simplified subset of the proposed system t h a t
simulates the actual processing t h a t will be done by the real
system. Typically it consists of a few screen designs and
reports t h a t provide just sufficient functionality to allow users
to experience how the proposed system might look and feel.
It is used in cases where,
the customer defines a general set of objectives for software but does not
provide detailed requirements,
OR, the developer may be unsure about the efficiency of a n algorithm,
the adaptability of a n operating system, the form of human-machine
interaction.
The objective of the prototyping model is to develop a
throwaway prototype to understand the customer
requirements and experiment with parts of the customer
requirements t h a t are poorly understood.
Prototypes should be discarded after development
The end-product should be better requirements definition for
the “final” software.
Software prototyping

CSE 2020Y(3) – Object Oriented Techniques 17

P ROTOTYPING MODEL

Begins with requirements gathering. Developer and

customer meet to
define the overall objectives for the software,
Identify whatever requirements are known, and
outline areas where further definition is mandatory
Define the functionality. A quick-design is made. Quick-
design focuses on those aspects of the s/w t h a t are visible to
the user.
Construction of throw-away prototype from quick-design.
Prototype is evaluated by customer/user and used to refine
requirements for the s/w to be developed.
Note: Iteration occurs as the prototype is tuned to satisfy
the needs of the customer and the developer better
understands what needs to be done.
BENEFITS P ROTOTYPING MODEL
A prototype can quickly resolve
misunderstanding between business managers
a nd analysts.
A prototype makes a n ideal tool for defining and
discussing user interaction.
Users can understand a prototype far more easily
t h a n most of the standard way of communicating
requirements in the form of models.
D RAWBACKS OF PROTOTYPING MODELS
The customer may want to adopt the prototype which
he/she sees as a working version of the software. He may be
unaware t h a t the prototype is a quick-and-dirty solution.
Some prototypes are so realistic t h a t they give the
impression th a t the project is almost finished whilst still a t
the systems analysis stage. This can put severe pressure on
the development team.
The effort required to produce a prototype may lead to the
development team using it as p art of the new system. This
can lead to quality problems with the resulting system.
The developer makes implementation compromises in order
to get a prototype working quickly.
e.g. inappropriate OS, programming language, inefficient algo’s
used just to demonstrate capability.
There is always the risk t h a t the developer forgets about initial
inhibitions and adopt these as long-term solutions.
ACTIVITY

What are the advantages and disadvantages of

using prototyping model for development?
I NCREMENTAL MODEL (1)
Combines elements of the Wa terfall Model with the
iterative feature of the Prototyping Model
Allows reduction of rework (due to cha nging
requirements) in the development process a nd gives
customers opportunity to delay decisions on their
deta iled requirements until they ha ve some experience
with the system
Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments
with each increment delivering part of the required
functionality
I NCREMENTAL MODEL (2)

• User requirements are prioritised and the highest priority

requirements are included in early increments.(core
product is first developed)
• Customer evaluation of the first increment helps in
formulating a development plan for the next increment
I NCREMENTAL MODEL (2)
The plan addresses the modification of the core product
to better satisfy customer needs and the delivery of
additional features and functionality
Once the development of an increment is started, the
requirements are frozen though requirements analysis for
later increments can continue
Once an increment is completed and delivered, customer
can out it into service – i.e. customer takes early delivery
of part of the system functionality, they may experiment
with it and clarify requirements for later requirements.
New increments are integrated with existing increments
so that system functionality improves with each delivered
increment.
I NCREMENTAL MODEL (3)
Customer value can be delivered with each increment so
system functionality is available earlier
No need to wait until the entire system is delivered.
First increment satisfy their most critical requirements
so the s/w can be immediately used
Early increments act as a prototype to help elicit
requirements for later increments
Lower risk of overall projectfailure
The highest priority system services tend to receive the
most testing
 P ROBLEMS WITH I NCREMENTAL MODEL (1)
Increments should be
relatively small
(< 20,000 loc). Increment should at least deliver some
system functionality. Hard to decide on the right size of
each increment
Most systems require a basic set of
facilities that are used by all parts.
As requirements are not defined in detail until an increment
is to be developed, it is difficult to identify common
facilities that all increments require
P ROBLEMS WITH I NCREMENTAL MODEL (2)
Management problems
Progress can be hard to judge and problems hard to find because
there is no documentation to demonstrate what h as been done.

Contractual problems
The normal contract may include a specification; without a
specification, different forms of contract have to be used.

Va l i d a t i o n p r o b l e m s
Without a specification, what is the system being tested against?

Maintenance problems
Continual change tends to corrupt software structure making it
more expensive to change and evolve to meet new requirements.
Weak n es s of Traditional Software
Development Methodology
Process control or documentation oriented methods like
structured analysis and design
Traditional, hard development tools like entity modelling
and data flow diagramming do not take the disorganised
world of people into consideration
The main problems of the traditional development
methods are their inability to face challenges set by
changing organisational, business and technical
environment and their insufficient emphasis on individuals
and individual talent and creativity
Traditional methods are often considered bureaucratic
and restrictive

CSE 3038 – Software Tools and Techniques

PART 2
Agile Software Development
Agile development is a methodology of software development
that emphasizes customer satisfaction through continuous
delivery of Functional software. Based on a variety of iterative
development disciplines Agile methods put developers to work
in small teams to tight budgets and short timescales.

Agile methods are considered

Lightweight
People-based rather than Process-based
Adaptive rather than predictive
Less document oriented than rigorous methods

CSE 3038 – Software Tools and Techniques

AGILE MODELLING APPROACH
Agile s o f t w a r e d e v e l o p m e n t refers to a group
of software development based on iterative
development, where requirements and solutions
evolve through collaboration between self-
organizing cross-functional teams.
Agile Modelling (AM) approach to developing
software-based systems aims to improve system
modelling process by combining best practices of
selected modelling methods in a context of a
particular project.
CHARACTERISTICS OF AGILE SOFTWARE
DEVELOPMENT

Agile development methods promote development,

teamwork, collaboration, an d process adaptability
throughout the life-cycle of the project.
Agile methods break tasks into small increments with
minimal planning, an d do not directly involve long-
term planning.
Iterations are short time frames known as “timebox”
t h a t typically last from one to four weeks.
Each iteration involves a team working through a full
software development cycle including planning,
requirements analysis, design, coding, unit testing
and when a working product is demonstrated to
stakeholders.
This helps minimize overall risk, an d lets the project
adapt to changes quickly.
C H A R A C T E R I S T I C S O F A G I LE
SOFTWARE DEVELOPMENT
Team composition in a n agile project is usually cross-
functional and self-organizing without consideration for
any existing corporate hierarchy or the corporate roles of
team members.
Team members normally take responsibility for tasks t h a t
deliver the functionality a n iteration requires.
They decide individually how to meet a n iteration's
requirements.
Agile methods emphasize face-to-face communication over
written documents when the tea m is all in the same
location.
When a team works in different locations, they maintain
daily contact through videoconferencing, voice, e-mail,
etc.
Key benefits of Agile
Increases Flexibility - Minimizes up-front investment and
maximizes return on investment (ROI) by creating an
efficient IT development process

Delivers the right solution - Aligns users and stakeholders

with the right people to deliver the solution that the
business actually needs

Accelerates Delivery - Iterations get to the right solution

faster

Reduces risk and increases Quality - Greater stakeholder

visibility and control

CSE 3038 – Software Tools and Techniques

Disadvantages of Agile
It’s hard!
Makes all dysfunction visible
Its doesn’t fix anything: the team has to do it
Feels like things are worse at the beginning
Bad products will be delivered sooner, and doomed
projects will failfaster
Partial adoption may be worse than none at all

CSE 3038 – Software Tools and Techniques

ACTIVITY
List the 5 principles of agile methods
What are the barriers to introducing agile
methods into large companies?
ANSWE R

List the 5 principles of agile methods

Customer involvement,
Incremental delivery,
People not process,
Embrace change,
Maintain simplicity.
ANSWE R

What are the barriers to introducing agile methods into large

companies?
Project managers may be reluctant to accept the risks of a new
approach.
The established quality procedures in large companies may be
incompatible with the informal approach to documentation in agile
methods.
The existing teams may not have the high level of skills to make
use of agile methods.
There may be cultural resistance if there is a long history of plan-
driven development in the company.