2 Models
2 Models
ENGINEERING
Software Process Models
Definition
Software Life Cycle Activities
Definition:
A software model also (Life-cycle model and
process model) is a description of the sequence of
activities carried out in an Software Engineering
project, and the relative order of these activities.
Definition
5
Analysis
Make sure you completely understand the problem
before starting the design or program a solution
Evaluate different approaches to the design
Software Life Cycle Activities
8
Design
Top-down approach: breaking a system into a set of
smaller subsystems
Object-oriented approach: identification of a set of
objects and specification of their interactions
UML diagrams are a design tool to illustrate the
interactions between
Classes
Classes and external entities
Software Life Cycle Activities
9
mechanistically.
Software Life Cycle Activities
10
Testing.
Once code has been generated, program testing
begins. The testing process
Focuses on the logical internals of the software,
Support (maintenance).
Software will undoubtedly undergo change after it is delivered to
the customer
(a possible exception is embedded software). Change will occur
because errors have been encountered, because the software
must be adapted to accommodate changes in its external
environment (e.g., a change required because of a new
operating system or peripheral device), or because the
customer requires functional or performance enhancements.
Software support/maintenance reapplies each of the preceding
phases to an existing program rather than a new one.
12
Generic software process models
Build and Fix
Waterfall
V- shaped
Rapid Prototyping
The Spiral
The Unified Process
Component-based software engineering
Build and Fix
13
Advantages
• No administrative overhead
• Signs of progress (code) early.
• Low expertise, anyone can use it!
• Useful for small “proof of concept” projects.
Build and Fix
17
Disadvantages
1. Dangerous
No visibility/control
No resource planning
No deadlines
Mistakes hard to detect/correct
2. Impossible for large projects.
3. Often results in a product of overall low quality
4. Maintenance can be extremely difficult without
specification and design document.
Waterfall Model
18
Advantage
Easy to understand, easy to use
or schedule
Waterfall Model
21
Disadvantages
All requirements must be known upfront
Technology is understood
Product
Requirements and System and
Specification Acceptance
Analysis Testing
Coding
V-Shaped Model
25
Coding
Transforms the algorithms defined during the design
phase into software.
Unit Testing
Checks each code module for errors.
Integration and Testing
Integrate and test individual code modules.
V-Shaped Model
27
Advantages
Emphasize planning for verification and validation
milestones
Easy to use
V-Shaped Model
29
Disadvantages
Does not easily handle concurrent events
requirements
Does not contain risk analysis activities
V-Shaped Model
30
Requirements
gathering
‘Quick’
design
build
prototype
evaluate &
refine
Engineer
product
Prototyping Model
36
Disadvantages
Customer could believe the prototype as the working version.
clarified
As the requirements clarification stage of a
waterfall model
Develop user interfaces
Short-lived demonstrations
resolved, project is
immediately terminated
Potential risks
Timing constraints
Lack of personnel
Competence of team
Dependency on
hardware delivery
Spiral Model
43
Simplified Waterfall model
plus risk analysis
Uses rapid prototypes
Precede each phase by
Alternatives
Risk analysis
Follow each phase by
Evaluation
Planning of next phase
Spiral model
44
Full Spiral Model
Spiral model
45
constraints
Identify risks (lack of experience, new technology,
Create a design
Review design
Develop code
Inspect code
Test product
Spiral model
48
Customer Risk
Communication Analysis
Start Axis
Customer
Evaluation Development
Integration
Spiral Model
50
Advantages:
Provides early indication of risks, without much cost
projects
Time spent planning, resetting objectives, doing risk analysis
activities
May be hard to define objective, verifiable milestones that
the project, then spiral model is the best choice for it.
Spiral model is suitable for medium risk projects and
Software
concept
Requirements
Analysis n
Architectural
Design
High Priority: Detailed design, code, debug,
test Stages prioritised
lower priority
Medium-High Priority: Detailed design, last. Thus if
code, debug, test
deadline or budget
Medium Priority: Detailed design, code, is reached before
Release
debug, test product finished
run out of time/money lowest priority
Medium-Low Priority: Detailed design,
code, debug, test
stages
can be omitted.
Low Priority: Detailed design, code, debug,
test
Incremental Model
55
Software
concept
Requirements
Analysis
Architectural
Design
Stage 1: Detailed design, code, debug, test
and delivery
Advantages
Develop high-risk or major functions first
Disadvantages
Requires good planning and design
each other.
Total cost of the complete system is not lower
Incremental Model
58
When to use the Incremental Model
Risk, funding, schedule, program complexity need for
schedules
On a project with new technology
Component-based Model
59
Modify
Outline
Identify candidate requirements
system
components according to discovered
requirements
components
Compose
Architectur al Identify candidate
components to
design components
create system
Component-based Model
62
Advantages:
Management of Complexity
Reduce Development Time
Increased Productivity
Improved Quality
63
Component-based Model
Disadvantages:
Development of Components
Lack of Components
Component Maintenance Costs
Unsatisfied Requirements
64
Component-based Model
When to use Component-Based Model :
When there is a pool of existing components that
range of suppliers
An Agile Process
65
Crystal Clear
Scrum
License Enforcement
When run for the first time, JeraWorks puts up a license dialog,
and will not proceed until the user enters either:
• a valid non-time-limited (paid) license certificate or
• a valid time-limited (demo) license that has not yet expired.
A valid license is stored so the user doesn't have to re-enter it on
subsequent runs.
License info is displayed on the splash screen.
When a demo license expires, the license dialog re-appears the
next time JeraWorks is run.
Extreme Programming (XP)
Twelve XP Practices
The Planning Game Pair Programming
Small Releases Collective Ownership
Metaphor Continuous Integration
Simple Design 40-Hours a Week
Test-driven development On-Site Customer
Refactoring Coding Standards
73
Extreme Programming (XP)
74
Small Release
Frequent and small releases are encouraged, and for a
Metaphor
Programmers have a simple shared story that explains the
system
Use metaphors to describe how the system should work.
The shape of the system is defined by a metaphor or set
of metaphors shared between the customer and
programmers.
A set of simple metaphors defines the internal and
external structure of the system.
it helps everyone understand the basic elements
Extreme Programming (XP)
77
Simple design
Do the simplest thing that could possibly work
No duplicate code
79
Extreme Programming (XP)
80
the back of the book. They do this because, you don't solve math
book problems to get the answer. Rather, you solve them to learn
the techniques for solving similar problems.
Test-first is like this: first you have the right answer -the test.
Refactoring
The restructuring of software without changing
the behavior.
Restructure the system continuously to improve code
and eliminate duplication
Continuously improve quality of the code
Extreme Programming (XP)
82
Refectory Example
Extreme Programming (XP)
Pair programming
Two programmers work together
at one machine
Driver enters code, while
navigator critiques it
Periodically switch roles
Research results:
Pair programming increases productivity
Higher quality code (15% fewer defects) in about half the time (58%)
83
Extreme Programming (XP)
84
Continuous integration
All changes are integrated into the code
after integration
Extreme Programming (XP)
86
On-site customer
A customer is accessible to the
Coding Standards
• Everyone codes to the same standards
Coding standards keep the code consistent and
easy for the entire team to read and refactor.
Extreme Programming (XP)
Why Extreme ?
If code reviews are good,
we’ll review code all the time (pair programming).
If testing is good,
everybody will test all the time (unit testing),
even the customers (functional testing)
If design is good,
we’ll make it part of everybody’s daily business (refactoring)
If simplicity is good,
we’ll always leave the system with the simplest design that supports
current functionality
(the simplest thing that could possibly work).
Extreme Programming (XP)
If architecture is important,
everybody will work defining and refining the architecture all the
time (metaphor)
ADVANTAGES Of XP
Customer focus increase the chance that the software
produced will actually meet the needs of the users
The focus on small, incremental release decreases the risk
on your project:
by showing that your approach works and
by putting functionality in the hands of your users, enabling them to
provide timely feedback regarding your work.
Continuous testing and integration helps to increase the
quality of your work
XP is attractive to programmers who normally are unwilling
to adopt a software process, enabling your organization to
manage its software efforts better.
Extreme Programming (XP)
92
DISADVANTAGES of XP
XP is geared toward a single project, developed and maintained by a
single team.
XP is particularly vulnerable to "bad apple" developers who:
don't work well with others
who think they know it all, and/or
who are not willing to share their "superior” code
XP will not work in an environment where a customer or manager insists
on a complete specification or design before they begin programming.
XP will not work in an environment where programmers are separated
geographically.
XP has not been proven to work with systems that have scalability issues
(new applications must integrate into existing systems).
Extreme Programming (XP)
93
When to use XP
Extreme Programming (XP) was created in
project risk
XP is set up for small groups of programmers.
Software Engineering Models
94
95