PRINCIPLES OF SOFTWARE

ENGINEERING
Software Process Models

Dr. Abdul Karim ABED

 OUTLINE
2

 Definition
 Software Life Cycle Activities

 Generic software process models

• Build and Fix
• Waterfall
• V- shaped
• Rapid Prototyping
• The Spiral
• The Unified Process
• Component-based software engineering
• Agile Process
 Extreme programming
 Definition
3

 Software products go through several stages as they

mature from initial concept to finished product
 The sequence of stages is called a process model or
life cycle
 A process is a sequence of steps performed for a
given purpose
 Definition
4

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

 It provides a fixed generic framework that can be

tailored to a specific project

 A process model for software engineering is chosen

based on the nature of the project and application,
the methods and tools to be used, and the controls
and deliverables that are required
 Software Life Cycle Activities
6

The main activates in software project are:

 Requirements Specification

 System analyst works with software users to clarify the

detailed system requirements
 Questions include format of input data, desired form of
any output screens, and data validation
 Software Life Cycle Activities
7

 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

 Code generation (Implementation).

The design must be translated into a machine-
readable form.
 The code generation step performs this task. If

design is performed in a detailed manner,

 code generation can be accomplished

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,

ensuring that all statements have been tested, and

on the functional externals; that is, conducting tests
to uncover errors and ensure that defined input will
produce actual results that agree with required
results.
 Software Life Cycle Activities
11

 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

 In this most simple model of software

development, the product is constructed with
minimal requirements, and generally no
specifications nor any attempt at design, and testing
is most often neglected. This is a representation of
what is happening in many software development
projects.
 Build and Fix
14
 Build and Fix
15

 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.
 Build and Fix
16

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

 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.
 Document-oriented
 The output of one phase constitutes the input to next
(Liner).
 Waterfall Model
19
 Waterfall Model
20

Advantage
 Easy to understand, easy to use

 Provides structure to inexperienced staff

 Milestones are well understood

 Good for management control (plan, staff, track)

 Works well when quality is more important than cost

or schedule
 Waterfall Model
21
Disadvantages
 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

 Little opportunity for customer to preview the system

(until it may be too late)

 Waterfall Model
22

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 Model
23

 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 Model
24
Project and Production
Requirements Operation and
Planning Maintenance

Product
Requirements and System and
Specification Acceptance
Analysis Testing

Architecture or Integration and

High-Level Testing
Design

Detailed Design Unit Testing

Coding
 V-Shaped Model
25

 Project and requirements planning

 Determines system requirements and allocation of
resources.
 Product requirements and specification analysis
 Analysis of software problem, concludes with complete
specification of the software.
 Architecture or High-level design
 - Determines how the software functions are to
implement the design.
 Detailed Design

 Defines algorithms for components that were defined

during the architecture phase.
 V-Shaped Model
26

 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

 System and acceptance testing

Test entire software system in its hardware
environment
 Productions, operation and maintenance
Puts software into production and provides for
enhancements and corrections.
 V-Shaped Model
28

Advantages
 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 Model
29

Disadvantages
 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
 V-Shaped Model
30

When to use the V-Shaped Model

 Excellent choice for systems requiring high

reliability – hospital patient control applications

 All requirements are known up-front
 Evolutionary Process Models
31

 Evolutionary models are iterative

 They are characterized in a manner that enables
software engineers to develop increasingly more
complete versions of the software
 Prototyping
 Incremental
 Spiral
 Prototyping Model
32

Some strong limitations of waterfall model is:

 It assumes that the requirements of a system can be

frozen before the design begins. This is possible for

systems designed to automate an existing manual
system. But for new systems, determining the
requirements is difficult as the user does not even
know the requirements. Hence, having unchanging
requirements is unrealistic for such projects.
 Prototyping Model
33

 The basic idea is that instead of freezing the

requirements before any design or coding can
proceed, a prototype is built to help understand the
requirements. This prototype is developed based on
the currently known requirements. Development of
the prototype obviously undergoes design, coding, and
testing, but each of these phases is not done very
formally or thoroughly. By using this prototype, the
client can get an actual feel of the system, which can
enable the client to better understand the requirements
of the desired system. This results in more stable
requirements that change less frequently.
 Prototyping Model
34
 Prototyping Model
35

Requirements
gathering
‘Quick’
design
build
prototype
evaluate &
refine
Engineer
product
 Prototyping Model

36

 When customer or developer is not sure

 Of requirements (inputs, outputs)
 Of algorithms, efficiency, human-machine interaction
 A prototype built from currently known user needs
 Prototyping Model
37
Advantages
1. It could serve as the first system.
 Prototyping Model
38

2) The customer doesn’t need to wait long as in the

Linear Model.
3) Feedback from customers are received periodically
and the changes don’t come as a last minute
surprise
 Prototyping Model
39

Disadvantages
 Customer could believe the prototype as the working version.

 Developer also could make the implementation compromises

where he could make the quick fixes to the prototype and
make is as a working version.
 Often clients expect that a few minor changes to the
prototype will more than suffice their needs. They fail to
realize that no consideration was given to the overall quality
of the software in the rush to develop the prototype
 Effort in building a prototype may be wasted

 Difficult to plan and manage

 Prototyping Model
40

When to use prototyping model

 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

 Spiral Model
41

 Process is represented as a spiral rather than as a

sequence of activities Each loop in the spiral
represents a phase in the process.
 No fixed phases such as specification or design -
loops in the spiral are chosen depending on what
is required.
 Risks are explicitly assessed and resolved
throughout the process.
 Spiral Model
42

Simplified Spiral Model

 If risks cannot be

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

Phase 1 : Determine objectives, alternatives and

constraints
 Objectives: functionality, performance,

hardware/software interface, critical success factors,

etc.
 Alternatives: build, reuse, buy, sub-contract, etc.

 Constraints: cost, schedule, interface, etc.

 Spiral model
46

Phase 2: Evaluate alternatives, identify and resolve

risks
 Study alternatives relative to objectives and

constraints
 Identify risks (lack of experience, new technology,

tight schedules, poor process, etc.

 Resolve risks (evaluate if money could be lost by

continuing system development

 Spiral model
47

Phase 3: develop next product

 Typical activates:

 Create a design

 Review design

 Develop code

 Inspect code

 Test product
 Spiral model
48

Phase 4 Plan next phase

 Typical activities

 Develop project plan

 Develop configuration management plan

 Develop a test plan

 Develop an installation plan

 Spiral Model
49

Six phases spiral model Planning

Customer Risk
Communication Analysis

Start Axis

Customer
Evaluation Development

Integration
 Spiral Model
50

Advantages:
 Provides early indication of risks, without much cost

 Users see the system early

 Critical high-risk functions are developed first

 The design does not have to be perfect

 Users can be closely tied to all lifecycle steps

 Early and frequent feedback from users

 Cumulative costs assessed frequently

 Spiral Model
51
Disadvantages
 Time spent for evaluating risks too large for small or low-risk

projects
 Time spent planning, resetting objectives, doing risk analysis

and prototyping may be excessive

 The model is complex

 Spiral may continue indefinitely

 Developers must be reassigned during non-development phase

activities
 May be hard to define objective, verifiable milestones that

indicate readiness to proceed through the next iteration

 Spiral Model
52

When to use the Spiral Model

 If the risk evaluation and cost evaluation is important for

the project, then spiral model is the best choice for it.
 Spiral model is suitable for medium risk projects and

high risk projects.

 Spiral model is also preferred when the project has

complex requirement or a new product line is introduced.

 If the User is not sure of the project needs or significant

research has to be done on the project, then spiral model

is used.
 Incremental Model
53
 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.
 Differs from Prototyping in that requirements are
fully known at the start
 Incremental Model
54

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

Stage 2: Detailed design, code, debug, test

and delivery

Stage n: Detailed design, code, debug, test

and delivery
 Incremental Model
56

Advantages
 Develop high-risk or major functions first

 Each release delivers an operational product

 Customer can respond to each build

 Lowers initial delivery cost

 Initial product delivery is faster

 Customers get important functionality early

 Risk of changing requirements is reduced

 Incremental Model
57

Disadvantages
 Requires good planning and design

 Requires early definition of a complete and fully

functional system to allow for the definition of

increments
 Each phase of an iteration is rigid and do not overlap

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

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
 Component-based Model
59

 Component-based is an approach to software

development that relies on software reuse.
 Based on systematic reuse where systems are
integrated from existing components systems.
 This approach is becoming increasingly used as
component standards have emerged.
 Component-based Model
60

 Component-based model incorporates many of the

iterative characteristics of the spiral model.
 The main difference is that in this model the
emphasis is on composing solutions from
prepackaged software components or classes
Component-based Model
61
The component base process

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

could satisfy the requirements of the new product

 Emerging trend: integration of web services from a

range of suppliers
 An Agile Process
65

Agile approaches are based on some common principles,

some of which are

 Working software is the key measure of progress in a

project.
 For progress in a project, therefore, software should be
developed and delivered rapidly in small increments.
 Even late changes in the requirements should be
entertained (small-increment model of development
helps in accommodating them).
 An Agile Process
66

 Face-to-face communication is preferred over

documentation.
 Continuous feedback and involvement of customer
is necessary for developing good-quality software.
 Simple design which evolves and improves with
time is a better approach than doing an elaborate
design up front for handling all possible scenarios.
 The delivery dates are decided by empowered
teams of talented individuals
(and are not dictated).
An Agile Process
67
 An Agile Process
68

Some Agile Methods

 Adaptive Software Development (ASD)

 Feature Driven Development (FDD)

 Crystal Clear

 Dynamic Software Development Method (DSDM)

 Rapid Application Development (RAD)

 Scrum

 Extreme Programming (XP)

 Extreme Programming - XP
69

 For small-to-medium-sized teams developing

software with vague or rapidly changing
requirements
 Coding is the key activity throughout a software
project
 Communication among teammates is done with
code
 Life cycle and behavior of complex objects defined
in test cases – again in code
 Extreme Programming (XP)
70

 An extreme programming project starts with user

stories which are short (a few sentences) descriptions
of what scenarios the customers and users would like
the system to support.

 A user story is a short description of what the

business or customer wants the software to do,
written by the customer in the customer terminology
without techno-syntax
71
The XP lifecycle
 Extreme Programming (XP)
72
Example of user story
"Tell me the story and write down the name of the story and a paragraph
or two."

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

The planning game

 Quickly determine the scope of the next release, combining business priorities
and technical estimates.
 Business decisions (customer)
 Scope: which “stories” should be developed
 Priority of stories (features)
 Release dates
 Technical decisions (developers)
 Time estimates for features/stories
 Elaborate consequences of business decisions
 Team organization and process
 Scheduling
 Extreme Programming (XP)
75

Small Release
 Frequent and small releases are encouraged, and for a

release, iterations are employed.

 Start with the smallest useful feature set
 Release early and often, adding a few features each time
 Extreme Programming (XP)
76

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

XP Metaphor Example-Payroll system is like an

assembly line:

 A large XP project was a payroll system for

Chrysler (Car Company).
 The metaphor for this project was that the payroll
system was like an assembly line where hour
parts were converted to dollar parts, all parts
were assembled and a paycheck was produced .
 Extreme Programming (XP)
78

Simple design
 Do the simplest thing that could possibly work

 Passes all the tests

 No duplicate code

 Fewest possible classes and methods

 Extreme Programming (XP)
Test-driven development
 Test first: before adding a feature, write a test for it!

 When the complete test suite passes 100%, the feature is

accepted
 Tests come in two basic flavors…

 Unit Tests automate testing of functionality as developers

write it
 Each unit test typically tests only a single class, or a
small cluster of classes !
 Acceptance Tests (or Functional Tests) are specified by the
customer

79
 Extreme Programming (XP)
80

XP Metaphor Example: Test-First Programming is like a Math Book

 Many math books have the answers to odd-numbered problems in

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.

Your challenge is to write the code that provides the answer.

Usually, if your code is wrong, your test will detect that.
 The fun part is, you act as both textbook author and student. The

author chooses a problem at just the right of level of difficulty,

just as you must do for your test.
 So, test-first is like a math book.
 Extreme Programming (XP)
81

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

Collective code ownership

 No single person "owns" a module

 Any developer can work on any part of the

code base at any time

 Extreme Programming (XP)
85

Continuous integration
 All changes are integrated into the code

base at least daily

 Tests have to run 100% both before and

after integration
 Extreme Programming (XP)
86

Work no more than 40 hours per week as a rule.

• Never work overtime two weeks in a row.
•Work only as many hours as you can be
productive and only as many hours as you can
sustain.
 Extreme Programming (XP)
87

On-site customer
 A customer is accessible to the

programming team at all times

 Extreme Programming (XP)
88

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)

 If integration testing is important,

we’ll integrate and test several times a day (continuous
integration).

 If short iterations are good,

we’ll make the iterations really, really short –seconds and minutes
and hours, not weeks and months and years (the Planning Game).
 Extreme Programming (XP)
91

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

response to problem domains whose requirements

change
 XP was also set up to address the problems of

project risk
 XP is set up for small groups of programmers.
 Software Engineering Models
94
95