Software Engineering

UNIT I – Hour II
FUNDAMENTALS OF SE AND
REQUIREMENT ENGINEERING
Topic: SDLC

1
Software Lifecycle Models
A software lifecycle model is a standardised
format for
• planning
• organising, and
• running
a new development project.
Hundreds of different kinds of models are
known and used.

Many are minor variations on just a small

number of basic models. In this section we:

• survey the main types of model, and

• consider how to choose between them.
Planning with Models
SE projects usually live with a fixed financial
budget. (An exception is maintainance?)

Additionally, time-to-market places a strong

time constraint.

There will be other project constraints such

as staff.
designers
programmers managers

money staff

Project constraints

Computing
resources time

Examples of Project Constraints

Project planning is the art of scheduling the
necessary activities, in time, space and
across staff in order to optimise:

• project risk [low]

• profit [high]
• customer satisfaction [high]
• worker satisfaction [high]
• long-term company goals
Questions:

1. What are these necessary activities?

(besides programming)

2. Are there good patterns of organisation

that we could copy?
A project plan contains much information,
but must at least describe:
• resources needed
(people, money, equipment, etc)
• dependency & timing of work
(flow graph, work packages)
• rate of delivery (reports, code, etc)

It is impossible to measure rate of progress

except with reference to a plan.
In addition to project members, the following
may need access to parts of the project plan:

• Management,
• Customers
• Subcontractors
• Suppliers
• Investors
• Banks
Project Visibility
Unlike other engineers
(e.g. civil, electronic, chemical … etc.)
software engineers do not produce anything
physical.

It is inherently difficult to monitor an SE

project due to lack of visibility.
This means that SE projects must produce
additional deliverables (artifacts)
which are visible, such as:

• Design documents/ prototypes

• Reports
• Project/status meetings
• Client surveys (e.g. satisfaction level)
What is a Lifecycle Model?

Definition.
A (software/system) lifecycle model is a
description of the sequence of activities
carried out in an SE project, and the relative
order of these activities.
It provides a fixed generic framework that
can be tailored to a specific project.
Project specific parameters will include:
• Size, (person-years)
• Budget,
• Duration.

project plan =
lifecycle model + project parameters
There are hundreds of different lifecycle models
to choose from, e.g:
• waterfall,
• V Shaped
• code-and-fix
• spiral
• rapid prototyping
• unified process (UP)
• agile methods, extreme programming (XP)
• COTS …
but many are minor variations on a smaller
number of basic models.
By changing the lifecycle model, we can
improve and/or tradeoff:

• Development speed (time to market)

• Product quality
• Project visibility
• Administrative overhead
• Risk exposure
• Customer relations, etc, etc.
Normally, a lifecycle model covers the entire
lifetime of a product.

From birth of a commercial idea

to final de-installation of last release

i.e. The three main phases:

• design,
• build,
• maintain.
Note that we can sometimes combine
lifecycle models,
e.g. waterfall inside evolutionary – onboard
shuttle software

We can also change lifecycle model between

releases as a product matures,
e.g. rapid prototyping  waterfall
The Waterfall Model

• The waterfall model is the classic lifecycle

model – it is widely known, understood
and (commonly?) used.
• In some respect, waterfall is the ”common
sense” approach.
• Introduced by Royce 1970.
phase
User Requirements output User Requirements Document

Software Requirements Software Requirements

Document

Architecture Design Architectural Design

Document

”Swimming
Detailed design & Coding Detailed
upstream”
Design
& Code

Testing
The Waterfall
Lifecycle Workflow
Delivery
Time
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
Waterfall Deficiencies
• All requirements must be known upfront
• Deliverables created for each phase are considered
frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of software
development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the
system (until it may be too late)
When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.
V-Shaped SDLC Model
• A variant of the Waterfall
that emphasizes the
verification and validation
of the product.
• Testing of the product is
planned in parallel with a
corresponding phase of
development
V-Shaped Steps
• Project and Requirements Planning – • Production, operation and
allocate resources maintenance – provide for
enhancement and corrections
• Product Requirements and • System and acceptance testing –
Specification Analysis – complete check the entire software system in
specification of the software system its environment

• Architecture or High-Level Design –

defines how software functions fulfill • Integration and Testing – check that
the design modules interconnect correctly

• Detailed Design – develop algorithms • Unit testing – check that each

for each architectural component module acts as expected

• Coding – transform algorithms into

software
V-Shaped Strengths
• Emphasize planning for verification and
validation of the product in early stages of
product development
• Each deliverable must be testable
• Project management can track progress by
milestones
• Easy to use
V-Shaped Weaknesses
• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes in
requirements
• Does not contain risk analysis activities
When to use the V-Shaped Model
• Excellent choice for systems requiring high
reliability – hospital patient control
applications
• All requirements are known up-front
• When it can be modified to handle changing
requirements beyond analysis phase
• Solution and technology are known
Code-and-Fix
This model starts with an informal general
product idea and just develops code until a
product is ”ready” (or money or time runs
out). Work is in random order.

Corresponds with no plan! (Hacking!)

Advantages
1. No administrative overhead
2. Signs of progress (code) early.
3. Low expertise, anyone can use it!
4. Useful for small “proof of concept” projects,
e.g. as part of risk reduction.
Disadvantages
1. Dangerous!
1. No visibility/control
2. No resource planning
3. No deadlines
4. Mistakes hard to detect/correct
2. Impossible for large projects,
communication breakdown, chaos.
Incremental SDLC Model
• Construct a partial
implementation of a total system
• Then slowly add increased
functionality
• The incremental model prioritizes
requirements of the system and
then implements them in groups.
• Each subsequent release of the
system adds function to the
previous release, until all
designed functionality has been
implemented.
Incremental Model Strengths
• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced
Incremental Model Weaknesses
• Requires good planning and design
• Requires early definition of a complete and
fully functional system to allow for the
definition of increments
• Well-defined module interfaces are required
(some will be developed long before others)
• Total cost of the complete system is not lower
When to use the Incremental Model
• Risk, funding, schedule, program complexity, or need
for early realization of benefits.
• Most of the requirements are known up-front but
are expected to evolve over time
• A need to get basic functionality to the market early
• On projects which have lengthy development
schedules
• On a project with new technology
Spiral Model
Since end-user requirements are hard to
obtain/define, it is natural to develop software
in an experimental way: e.g.
1. Build some software
2. See if it meets customer requirements
3. If no goto 1 else stop.
This loop approach gives rise to structured
iterative lifecycle models.

In 1988 Boehm developed the spiral model as

an iterative model which includes risk
analysis and risk management.

Key idea: on each iteration identify and solve

the sub-problems with the highest risk.
Cumulative cost Evaluate alternatives,
Determine objectives, Identify & resolve risks
alternatives & constraints

Prototypes Operational
Review & Start P1 P2 P3 Prototype
commitment Requirements Concept
Design, Detailed design
plan Of Operation Validation
Development & Verification
plan Requirements
validation Coding
Integration &
Test plan Unit & Integration
Testing
End Acceptance Develop & verify
Plan next phase
Testing next-level product
Each cycle follows a waterfall model by:
1. Determining objectives
2. Specifying constraints
3. Generating alternatives
4. Identifying risks
5. Resolving risks
6. Developing next-level product
7. Planning next cycle
Advantages
1. Realism: the model accurately reflects the
iterative nature of software development on
projects with unclear requirements
2. Flexible: incoporates the advantages of the
waterfal and rapid prototyping methods
3. Comprehensive model decreases risk
4. Good project visibility.
Disadvantages
• Needs technical expertise in risk analysis to
really work
• Model is poorly understood by non-technical
management, hence not so widely used
• Complicated model, needs competent
professional management. High administrative
overhead.
Rapid Prototyping

Key idea: Customers are non-technical and

usually don’t know what they want/can have.

Rapid prototyping emphasises requirements

analysis and validation, also called:
• customer oriented development,
• evolutionary prototyping
Requirements Capture

Iterate
Quick Design

Build Prototype

Customer Evaluation of
Prototype

The Rapid Engineer Final

Product
Prototype Workflow
Advantages

1. Reduces risk of incorrect user

requirements
2. Good where requirements are
changing/uncommitted
3. Regular visible progress aids management
4. Supports early product marketing
Disadvantages I

1. An unstable/badly implemented prototype

often becomes the final product.
2. Requires extensive customer collaboration
– Costs customers money
– Needs committed customers
– Difficult to finish if customer withdraws
– May be too customer specific, no broad market
Disadvantages II
3. Difficult to know how long project will last
4. Easy to fall back into code-and-fix without
proper requirements analysis, design,
customer evaluation and feedback.
Agile (XP) Manifesto

XP = Extreme Programming emphasises:

• Individuals and interactions
– Over processes and tools
• Working software
– Over documentation
• Customer collaboration
– Over contract negotiation
• Responding to change
– Over following a plan
Agile Principles (Summary)
• Continuous delivery of software
• Continuous collaboration with customer
• Continuous update according to changes
• Value participants and their interaction
• Simplicity in code, satisfy the spec
XP Practices (Summary)
• Programming in pairs
• Test driven development
• Continuous planning, change , delivery
• Shared project metaphors, coding standards
and ownership of code
• No overtime! (Yeah right!)
Advantages
• Lightweight methods suit small-medium size
projects
• Produces good team cohesion
• Emphasises final product
• Iterative
• Test based approach to requirements and
quality assurance
Disadvantages
• Difficult to scale up to large projects where
documentation is essential
• Needs experience and skill if not to
degenerate into code-and-fix
• Programming pairs is costly
• Test case construction is a difficult and
specialised skill.
Unified Process (UP)
• Booch, Jacobson, Rumbaugh 1999.
• Lifetime of a software product in cycles:
• Birth, childhood, adulthood, old-age, death.
• Product maturity stages
• Each cycle has phases, culiminating in a new
release (c.f. Spiral model)
Inception Elaboration

Transition Construction

UP Lifecycle – single phase workflow

(drawn as a UML Statechart!)
• Inception – identify core use cases, and use
to make architecture and design tradeoffs.
Estimate and schedule project from derived
knowledge.
• Elaboration – capture detailed user
requirements. Make detailed design, decide
on build vs. buy.
• Construction – components are bought or
built, and integrated.
• Transition – release a mature version that
satisfies acceptance criteria.
Unified Process
Product
Management Software Lifecycle

Environment * * releases
Workflow Cycle

Requirements
Inception
4
Design
Phase Elaboration

Implementation
*
Construction

Assessment Iteration
Transition

Deployment *
Artifact
UML class diagram!
Use Case Model

specified by
realised by
Analysis Model
deployed by implemented by

Design Model verified by

Deployment Model

Implementation Model
All models are interdepedent
but this only shown for use Test Model
case model
COTS
• COTS =
Commercial Off-The-Shelf software
• Engineer together a solution from existing
commercial software packages using minimal
software ”glue”.
• E.g. using databases, spread sheets, word
proccessors, graphics software, web browsers,
etc.
Advantages
• Fast, cheap solution
• May give all the basic functionality
• Well defined project, easy to run
Disadvantages
• Limited functionality
• Licensing problems, freeware, shareware,
etc.
• License fees, maintainance fees, upgrade
compatibility problems
When to use
Structured Evolutionary Prototyping
• Requirements are unstable or have to be clarified
• As the requirements clarification stage of a waterfall
model
• Develop user interfaces
• Short-lived demonstrations
• New, original development
• With the analysis and design portions of object-
oriented development.
Rapid Application Model (RAD)
• Requirements planning phase (a workshop utilizing
structured discussion of business problems)
• User description phase – automated tools capture
information from users
• Construction phase – productivity tools, such as code
generators, screen generators, etc. inside a time-box.
(“Do until done”)
• Cutover phase -- installation of the system, user
acceptance testing and user training
RAD Strengths
• Reduced cycle time and improved productivity with
fewer people means lower costs
• Time-box approach mitigates cost and schedule risk
• Customer involved throughout the complete cycle
minimizes risk of not achieving customer satisfaction
and business needs
• Focus moves from documentation to code
(WYSIWYG).
• Uses modeling concepts to capture information
about business, data, and processes.
RAD Weaknesses
• Accelerated development process must give quick
responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• Requires a system that can be modularized
• Developers and customers must be committed to
rapid-fire activities in an abbreviated time frame.
When to use RAD
• Reasonably well-known requirements
• User involved throughout the life cycle
• Project can be time-boxed
• Functionality delivered in increments
• High performance not required
• Low technical risks
• System can be modularized
Answer the following questions
For each of the following documents, indicate in which phase(s) of the software life
cycle it is produced:
• final user manual,
• architectural design,
• SQA plan,
• module specification,
• source code,
• statement of work,
• test plan,
• preliminary user manual,
• detailed design,
• cost estimate,
• project plan,
• test report,
• documentation.

63
Answer !!!

Implementation phase
Design phase
Project planning phase
Design phase
Implementation phase
Feasibility phase
Requirements phase
Requirements phase
Design phase
Project planning phase
Project planning phase
Testing phase
Implementation phase

64
• Suppose that you have to build a product to
determine the inverse of 3.546784 to four
decimal places. Once the product has been
implemented and tested, it will be thrown
away. Which life-cycle model would you use?
Give reasons for your answer.

65