Software Engineering
Lecture - 2
Software Engineering 1
Content
Process models•
Waterfall
•
Incremental
• Week-01
Week - 2 Iterative
• The nature of software
V- model
• Software application domains
Spiral
• Intro. to software engineering
Prototyping
• Software process framework
Software Engineering 2
Software Engineering Phases
1. Vision – focus on why
2. Definition – focus on what
3. Development – focus on how ( how we can achieve this technically, design,
code)
4. Maintenance – focus on change
Vision Definition Development Maintenance
Detail Requirements Design, code
Software Engineering 3
In Software
One thing is constant that is Change
Software Engineering 4
Software Process
Software Engineering 5
What is Software Process?
“A software process is a set of related activities that leads to
the production of a software product.”
Software Engineering 6
The software process
Many different software processes but all involve:
Specification – defining what the system should do;
Design and implementation – defining the organization of the system
and implementing the system;
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing
customer needs.
Design and
Specification Validation Evolution
Implementation
Software Engineering 7
Software Process Models
Software Engineering 8
Software Process Models
• A software process model is a simplified
representation of a software process.
• Each process model represents a process
from a particular perspective.
• Provides only partial information about that
process
Software Engineering 9
Process Model
• Defines a distinct set of activities, actions, tasks, milestones, and
work products that are required to engineer high-quality software
• The activities may be linear, incremental, or evolutionary
10
Software Engineering 10
Waterfall Model
Software Engineering 11
The Waterfall Model
The first published model of the software
development process (Royce, 1970)
Because of the cascade from one phase to another,
this model is known as the ‘Waterfall Model’
Plan and schedule all of the process
activities before starting work on them
Software Engineering 12
Waterfall Model (Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
13
Software Engineering 13
The Waterfall Model - Pros
Simple, manageable and easy to understand
Fits to common project management practices (milestones,
deliverables etc.)
Focus on requirements and design at beginning, save money and
time at the end
Can be suitable for short projects (some weeks)
Can be suitable for "stable" projects, where requirements do not
change
Focus on documents, saves knowledge which can be reused by
other people.
Widely used, e.g. US Department of Defense
Can be suitable for fixed-price contracts
Software Engineering 14
Problem?
Software Engineering 15
The Waterfall Model
Requirements
Finish each phase
before continue to next
System Design
Why is the waterfall model
Program Design so criticized?
Which are the problems? Can
Implementation it be useful sometimes?
Integration
Testing
System Testing
Milestone and
Acceptance
deliverable at Test
each step. (Artifacts
Maintenance
such as Design
document, Requirement
Specification. etc.)
Software Engineering 16
Waterfall model problems
Inflexible partitioning of the project into distinct stages makes it difficult to
respond to changing customer requirements.
• Therefore, this model is only appropriate when the requirements are well-understood
and changes will be fairly limited during the design process.
• Few business systems have stable requirements.
The waterfall model is mostly used for large system engineering projects
where a system is developed at several sites.
• In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.
Software Engineering 17
The Waterfall Model - Cons
Software requirements change, hard to sign-off on a SRS.
Early commitment. Changes at the end, large impact.
Feedback is needed to understand a phase. E.g. implementation is needed to understand
some design.
Difficult to estimate time and cost for the phases.
Handling risks are not part of the model. Pushes the risks forward.
Software "is not" developed in such a way. It evolves when problems are more understood.
Doesn't support iteration, so changes can cause confusion
Difficult for customers to state all requirements explicitly and up front
Requires customer patience because a working version of the program doesn't occur until the
final phase
Problems can be somewhat alleviated in the model through the addition of feedback loops
Software Engineering 18
Can We Improve the Model?
Iteration back to previous phase
Danger! e.g. a performance
problem can result in a
major requirements change.
Very expensive rollback...
Software Engineering 19
Waterfall Model with Feedback (Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test
Deployment
Delivery
Support
Feedback
20
Software Engineering 20
V - Model
Software Engineering 21
V Model
• The V-model is a variation of the waterfall model that demonstrates how
the testing activities are related to analysis and design
• Developed by the German Ministry of Defense
• Unit and system testing verify the program design, ensuring that
parts and whole work correctly
• Acceptance testing, conducted by the customer rather than developers,
validates the requirements, trying each system function meets a
particular requirement in the specification
Software Engineering 22
V- Model
Software Engineering 23
V Model (Pros)
• It defines tangible phases of the process, and proposes a logical
sequence in which these phases should be approached
• It also defines logical relationships between the phases
• It demands that testing documentation is written as soon as possible
• It gives equal weight to development and testing
• It provides a simple and easy to follow map of the software
development process
Software Engineering 24
V Model (Cons)
• It is too simple to accurately reflect the software development
process
• It is inflexible; it has no ability to respond to change
• It produces inefficient testing methodologies
Software Engineering 25
Phased Development
(Incremental & Iterative Model)
Software Engineering 26
Phased Development
Design a system so it can be delivered in pieces, letting users
have some functionality while the rest is under development
There are usually two or more systems in parallel:
a) The operational or production system in use by customers
b) The development system which will replace the current release
Software Engineering 27
Phased Development
Phased Development
Incremental Iterative
Development Development
Software Engineering 28
Incremental Development
Incremental development partitions a system by functionality
Early release starts with small, functional subsystem, later
releases add functionality
Software Engineering 29
Incremental Model (Diagram)
Increment #1
Communication
Planning
Modeling
Increment #2 Construction
Deployment
Communication
Planning
Modeling
Construction
Increment #3 Deployment
Communication
Planning
Modeling
Construction
Deploy………
30
Software Engineering 30
Incremental Model (Description)
• Used when requirements are well understood
• Multiple independent deliveries are identified
• Work flow is in a linear (i.e., sequential) fashion within an increment and is
staggered between increments
• Iterative in nature; focuses on an operational product with each increment
• Provides a needed set of functionality sooner while delivering optional
components later
• Useful also when staffing is too short for a full-scale development
31
Software Engineering 31
Incremental development benefits
The cost of accommodating changing customer requirements is
reduced.
The amount of analysis and documentation that has to be redone is
much less than is required with the waterfall model.
It is easier to get customer feedback on the development work
that has been done.
Customers can comment on demonstrations of the software and see how
much has been implemented.
More rapid delivery and deployment of useful software to the
customer is possible.
Customers are able to use and gain value from the software earlier
than is possible with a waterfall process.
Software Engineering 32
Incremental development problems
The process is not visible.
Managers need regular deliverables to measure progress. If systems are
developed quickly, it is not cost-effective to produce documents that reflect every
version of the system.
System structure tends to degrade as new increments are added.
Unless time and money is spent on refactoring to improve the software,
regular change tends to corrupt its structure. Incorporating further software
changes becomes increasingly difficult and costly.
Software Engineering 33
Iterative Development
• Iterative development improves overall system in each release
• Delivers a full system in the first release, then changes the
functionality of each subsystem with each new release
Software Engineering 34
Iterative vs. Incremental Development
Incremental Development
Add a new "part" at each increment
Iterative Development
Improve a "working system" at each
iteration
Software Engineering 35
Iterative Development - Pros
• Misunderstandings and inconsistency are made clear early (e.g. between
requirement, design, and implementation)
• Encourage to use feedback -> elicit the real requirements
• Forced to focus on the most critical issues
• Continuous testing offers project assessment
• Workload is spread out over time (especially test)
• The team can get "lesson learned" and continuously improve the process
• Stakeholders gets concrete evidence of progress
Software Engineering 36
Iterative Development - Cons
• Problem with current business contracts, especially fixed-price
contracts
• With short iterations it can be hard to map customer requirements to
iterations
Software Engineering 37
Software Engineering 38
Activity 1
Software Engineering 39
Activity 2
Giving reasons for your answer based on the type of system being
developed, suggest the most appropriate generic software process
model that might be used as a basis for managing the development
of the following systems:
a) A system to control anti-lock braking in a car
b) An interactive travel planning system that helps users plan journey with
the lowest environment impact.
Software Engineering 40
Activity 1
Software Engineering 41
Activity 2
a) Anti-lock braking system This is a safety-critical system so requires a lot of up-front
analysis before implementation. It certainly needs a plan-driven approach to
development with the requirements carefully analysed. A waterfall model is
therefore the most appropriate approach to use, perhaps with formal
transformations between the different development stages.
b) Interactive travel planning system with a complex user interface but which must
be stable and reliable. An incremental development approach is the most
appropriate as the system requirements will change as real user experience with
the system is gained.
Software Engineering 42
Reference
• Chapter 2, I. Sommerville, Software Engineering, 9th Edition, Pearson
Education, 2011.
Software Engineering 43
