HNDIT2032

System Analysis
and Design

Software Life Cycle Models

1
 Need of a life cycle
• We need a life cycle in systems development to,
1. ease the process of building a system
2. build high quality systems that meets customer
expectations, within time and cost estimates
3. work effectively and efficiently in the current and
planned information technology infrastructure
4. avoid failures like unclear objectives, cost overruns
5. maintain and enhance cost effectively
2
 The Systems Development Life Cycle
(SDLC)
• The Systems Development Life Cycle (SDLC)
identifies all the activities required to build,
launch, and maintain an information system.
 Core activities in the systems
development process
1. Systems analysis
2. Systems design
3. Programming
4. Testing
5. Conversion
6. Production and
Maintenance
 The Systems Development Life Cycle
(SDLC)
• Six core processes required in the development of any
new application:
1. Identify the problem or need and obtain approval to
proceed.
2. Plan and monitor the project—what to do, how to do it,
and who does it.
3. Discover and understand the details of the problem or
the need.
4. Design the system components that solve the problem or
satisfy the need.
5. Build, test, and integrate system components.
6. Complete system tests and then deploy the solution.
• Normally, the SDLC includes all the activities
that are part of systems analysis, systems
design, programming, testing, and maintaining
the system as well as other project
management processes that are required to
successfully launch and deploy the new
information system.
• During the last 10 years, several new
information systems development processes
have been developed to enhance project
success.
• One of the newer and more effective ones is
called Agile Development.
 Agile Development
• The basic philosophy of Agile Development is that
neither team members nor the user completely
understands the problems and complexities of a
new system, so the project plan and the
execution of the project must be responsive to
unanticipated issues.
• It must be agile and flexible.
• It must have procedures in place to allow for,
anticipate, and even embrace changes and new
requirements during the development process.
 Agile Development
• Agile development is a software development
methodology that delivers functionality in rapid
iterations—measured in weeks—requiring frequent
communication, development, testing, and delivery.

• It focuses on rapid development and frequent user

contact to create software that is highly relevant to
business users.

• This software does not have to include every possible

feature the user will require. Rather, it must meet only
the basic requirements.

9
Scrum
 Scrum
• Scrum is responsive to a highly changing,
dynamic environment in which users might
not know exactly what is needed and might
also change priorities frequently.
• Software is developed incrementally, and
controls are imposed empirically—by focusing
on things that can be accomplished.
 Scrum..
• The basic control mechanism for a Scrum project is a
list of all the things the system should include and
address.
• This list—called the product backlog—
– includes user functions (such as use cases),
– features (such as security),
– technology (such as platforms).
• The product backlog list is continually being prioritized,
• only a few of the high-priority items are worked on at a
time, according to the current needs of the project and
its sponsor.
 Scrum Organization
• The three main organizational elements that
affect a Scrum project are
– the product owner
– the Scrum master
– and the Scrum team or teams.
 The product owner
• The product owner is the client
• The product owner maintains the product
backlog list. For any function to be included in
the final system, it must first be placed on the
product backlog.
• In a Scrum project, the primary client controls
the requirements. This forces the client and
user to be intimately involved in the project.
 The Scrum master
• The Scrum master enforces Scrum practices and
helps the team complete its work.
• A Scrum master is comparable to a project
manager in other approaches.
• The Scrum master doesn’t set the schedule or
assign tasks. The team does.
• One of the primary duties of the Scrum master is
to remove impediments so the team can do its
work. In other words, the Scrum master is a
facilitator.
 The Scrum team
• The Scrum team is a small group of developers—typically
five to nine people—who work together to produce the
software.
• For projects that are very large, the work should be
partitioned and delegated to smaller teams.
• The Scrum team sets its own goal for what it can
accomplish in a specific period of time.
• It then organizes itself and parcels out the work to
members. In a small team, it is much easier to sit around a
table, decide what needs to be done, and have members of
the team volunteer or accept pieces of work.
 Scrum Practices
• The basic work process is called a sprint, and all other practices are
focused on supporting a sprint.
• A Scrum sprint is a firm 30-day period called a time box, with a specific
goal or deliverable.
• At the beginning of a sprint, the team gathers for a one-day planning
session.
– In this session, the team decides on the major goal for the sprint.
– The goal draws from several items on the prioritized product backlog list.
– The team decides how many of the highest-priority items it can accomplish
within the 30-day sprint.
– Sometimes, lower-priority items can be included for very little additional
effort and can be added to the deliverables for the sprint.
• After the team has agreed on a goal and has selected items from the
backlog list, it begins work.
• The scope of that sprint is then frozen, and no one can change it.
• If team members determine that they can’t accomplish everything in their
goal, they can reduce the scope for that sprint. However, the 30-day
period is kept constant.
extreme programming
 Extreme Programming (XP)
• Extreme Programming (XP) is an adaptive,
agile development methodology that was
created in the mid-1990s.
• XP is really an attempt to take the best
practices of software development and extend
them “to the extreme.”
 characteristics
• Takes industry best practices
• Combines those best practices (in their most
intense forms) in a new way to produce a
result .
 1. Communication
• Effective communication involves not only
documentation but also verbal discussion.
• The practices and methods of XP are designed
to ensure that open, frequent communication
occurs.
 2. Simplicity
• Even though developers have always
advocated keeping solutions simple, they
don’t always follow their own advice.
 3. Feedback
• Feedback on functionality and requirements
should come from the users,
• feedback on designs and code should come
from other developers,
• feedback on satisfying a business need should
come from the client.
XP integrates feedback into every aspect of
development.
 4. Courage
• Developers always need courage to face the
harsh choice of doing things right or throwing
away bad code and starting over.
• XP practices are designed to give developers
the courage to “do it right.”
XP Project Activities
 XP Project Activities
• A system is delivered to users in multiple stages called
releases. Each release is a fully functional system that
performs a subset of the full system requirements.
• A release is developed and tested within a period of no
more than a few weeks or months.
• During each iteration, developers code and test a
specific functional subset of a release. Iterations are
coded and tested in a few days or weeks. There are
multiple iterations within each release, so the iteration
ring (inner) cycles multiple times.
 XP Practice
Planning
• The basis of an XP plan is a set of stories that users develop.
A story describes what the system needs to do.
• XP doesn’t use the term use case, but a user story.
• Planning involves two aspects:
– business issues (decided by the users and clients)
– technical issues.(decided by the development team)
• The plan, especially in the early stages of the project,
consists of the list of stories (from the users) and the
estimates of effort, risk, and work dependencies for each
story (from the development team).
 Testing
• Testing Every new piece of software requires
testing, and every methodology includes testing.
• XP intensifies testing by requiring that the tests
for each story be written first—before the
solution is programmed.
• There are two major types of tests:
– unit tests, which test the correctness of a small piece
of code.
– acceptance tests, which test the business function.
• the tests can be rerun quickly and automatically
 Pair Programming
• Pair programming divides up the coding work.
– First, one programmer might focus more on
design and double-checking the algorithms while
the other writes the code.
• The quality of the code is always higher in a
pair-programming environment.
 Simple Designs
• It is one that accomplishes the desired result
with as few classes and methods as possible
and that doesn’t duplicate code.
Accomplishing all that is often a major
challenge.
 Refactoring
• Refactoring is the technique of improving the
code without changing what it does.
• Refactoring produces high-quality, robust
code.
 Owning the Code Collectively
• In XP, everyone is responsible for the code. No
one person can say “This is my code.”
Someone can say “I wrote it,” but everyone
owns it.
• Collective ownership allows anyone to modify
any piece of code.
 Continuous Integration
• Small pieces of code—which have passed the
unit tests—are integrated into the system
daily or even more often.
• Continuous integration highlights errors
rapidly and keeps the project moving ahead.
• XP’s practice of continuous integration
prevents tremendous amounts of rework .
 Small Releases
• A release is a point at which the new system
can be turned over to users for acceptance
testing and even for productive use.
• Frequent releases also facilitate practices,
such as immediate feedback and continual
integration.
 The Unified Process
• Development methodology originally offered
by Rational Software, which is now part of
IBM.
• The UP defines a complete methodology that
uses UML for system models and describes a
new, adaptive system development life cycle.
UP system development life cycle
FORMAL SYSTEM DEVELOPMENT
MODEL
Waterfall vs Agile
Timeboxing

40
 Linear or Waterfall Cycle
• An approach to system analysis and design
• Completes each phase one after another
and only once.

Problem Definition

Systems Analysis

Systems Design

Systems Implementation

Systems Testing

Maintenance
41
 Waterfall Strengths
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff,
track)
 Works well when quality is more important
than cost or schedule
42
Problems with Waterfall Development
Approach

43
Problems with Waterfall Development
Approach……
There are several problems with this approach.
1. It has a rigid design
2. Inflexible
3. It has a top-down procedure
4. One phase must be completed before the next
phase starts
5. No phase can be repeated
6. Time consuming

44
 Modified Waterfall development approach

Problem Definition

Systems Analysis

Systems Design

Systems Implementation

Systems Testing

Maintenance

45
 Modified Waterfall Development
Approach
• Uses the same phases as the pure waterfall
development approach.
• Allow some of the stages to overlap, such as the
requirements stage and the design stage.
• Overlapping stages make it possible to
integrate feedback from the design phase into
the requirements.
• Progress is more difficult to track.
46
 Iterative development approach
Complete
problem
Iteration # 1
definition
Some Some Some
System System System
Analysis Design Implementation

Iteration # 2
More More More
System System System
Analysis Design Implementation

Iteration # 3
Still more Still more Still more
System System System
Analysis Design Implementation

Repeat until no additional

47
iterations needed
 Iterative Development Approach
• Completes the entire IS in successive iterations.
• Each iteration does some
– analysis
– design
– construction
• Allows versions of usable information to be
delivered in regular and shorter time frames.
• it helps to develop a part of the new system and
place it into operation as quickly as possible.
48
 Advantages of Iterative model:
• we can track the defects at early stages. This
avoids the downward flow of the defects.

• we can get the reliable user feedback.

• Less time is spent on documenting and more

time is given for designing.
Disadvantages of Iterative model:
• Each phase of an iteration is rigid with no
overlaps

• Costly system architecture or design issues

may arise because not all requirements are
gathered up front for the entire lifecycle
 When to use iterative model:

• Requirements of the complete system are

clearly defined and understood.
• When the project is big.
• Major requirements must be defined;
however, some details can evolve with time.
 Prototyping

• It is very difficult for end-users to anticipate

how they will use new software systems to
support their work.
• If the system is large and complex, it is
probably impossible to make this assessment
before the system is built and put into use.
 When to use a Prototyping model
• It can be used to clear the vague
requirements.
• It should be evaluated with the user
participation.
Eg: web development
• They are excellent for designing good human
computer interface systems.
 Prototype model

There are two types of Prototyping techniques

* Throw-away Prototyping
* Evolutionary Prototyping
54
 Prototyping
1. It is very difficult for end-users to anticipate how they
will use new software systems to support their work.
2. If the system is large and complex.
3. it is probably impossible to make this assessment
before the system is built and put into use.
4. ( a small version of the system) can be used to clear
the vague requirements.
5. A prototype should be evaluated with the user
participation.
 Prototyping

There are two types of Prototyping techniques

* Throw-away Prototyping
* Evolutionary Prototyping
Throw-away and Evolutionary Prototyping

Throw-away Executable prototype +

prototyping System specification

Outline
Requirements
Evolutionary
prototyping Delivered system
Throw-away Prototyping

establish develop evaluate specify

outline prototype prototype system
specification
components

Delivered
design and validate system software
implement
system system
 Throw-away Prototyping

• Understand the system requirements clearly.

• Starts with poorly understood requirements. Once the
requirements are cleared, the system will be developed from
the beginning.
• This model is suitable if the requirements are vague but
stable.
 Some problems with Throw-away Prototyping
1. Important features may have been left out of the prototype to
simplify rapid implementation.
2. An implementation has no legal standing as a contract
between customer and contractor.
3. Non-functional requirements cannot be adequately tested in a
prototype implementation.(reliability, robustness, safety)
 Evolutionary Prototyping

Develop abstract Build prototype Evaluate prototype

system system
specification

YES

NO

Deliver System
system Adequate?
 Structured Evolutionary Prototyping
Strengths
1. Customers can “see” the system requirements as
they are being gathered
2. Developers learn from customers
3. A more accurate end product
4. Unexpected requirements accommodated
5. Allows for flexible design and development
6. Interaction with the prototype stimulates awareness
of additional needed functionality

62
 Prototyping Weaknesses
1. It can lead to false expectations.
2. It can lead to poorly designed systems.
3. Overall maintainability may be overlooked
4. The customer may want the prototype delivered.
5. Process may continue forever (scope creep)
6. Continual change tends to corrupt the structure of
the system.
7. Maintenance is difficult and costly.

63
 When to use Prototype model:
• when the desired system needs to have a lot
of interaction with the end users.
– Eg: web development
• They are excellent for designing good human
computer interface systems.
 The RAD model
• Rapid Application Development (RAD) is an
incremental software development process
model that emphasizes an extremely short
development cycle.
• Build complex solutions rapidly using highly collaborative
teams.
• Reduce the need for detailed documentation early in the
development cycle.
• Refine and validate features with stakeholders after each cycle
or iteration 66
67
 Processes in the RAD model
1. Business modelling –
The information flow in a business system considering its functionality.
2. Data Modelling
The information flow defined as part of the business modelling phase is refined into a
set of data objects that are needed to support the business
3. Process Modelling -
The data objects defined in the data modelling phase are transformed to achieve the
information flow necessary to implement business functions.
4. Application generation –
RAD assumes the use of 4GL or visual tools to generate the system using reusable
components.
5. Testing and turnover
New components must be tested and all interfaces must be fully exercised
 Advantages of RAD

• Can speed up systems development.

• Users thoroughly involved from the start.
• Improves the process of rewriting legacy
applications.

69
 Some problems with the RAD model
1. Requires sufficient human resources to
create right number of RAD teams
2. If a system cannot be properly modularized,
building the components necessary for RAD
will be problematic.
3. RAD is not applicable when technical risks are
high.
 When to use RAD model
• If requirements are well understood and
project scope is constrained, the RAD process
enables a development team to create a ‘fully
functional system’ within very short time
periods (eg. 60 to 90 days)
 Some problems with the RAD model
1. Requires sufficient human resources to create right
number of RAD teams
2. RAD requires developers and customers who are
committed to the rapid-fire activities necessary to get
a system completed in a much abbreviated time
frame.
3. If a system cannot be properly modularized, building
the components necessary for RAD will be
problematic.
4. RAD is not applicable when technical risks are high.