software engineering lecture note pptsoftware engineering lecture note pptsoftware engineering lecture note ppt

1. Software Processes 2-1
Chapter 2
Software processes
By: Tekalign B.
Adapted from Ian Sommerville 2006, Software
Engineering, 8th edition. Chapter 4

2. Software Processes
Chapter 2: Objectives
 To introduce software process models
 To describe three generic process models and when they
maybe used
 To describe outline process models for requirements
engineering, software development, testing and evolution
2-2

3. Software Processes
Chapter 2: roadmap
2.1 Software process and process models
2.2 Process iteration
2.3 Process activities
2.4 The Rational Unified Process
2.5 Computer-aided software engineering
2.6 Process assessment model and process metrics
2-3

4. Software Processes
2.1 Software process and process models
 Software process is a structured set of activities required to develop a
software system:
 There are many software processes but all involve:
 Specification;
 Design and implementation;
 Validation;
 Evolution.
 A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective.
2-4

5. Software Processes
Generic software process models
 These three generic process models are widely used in current
software engineering practice:
1. The waterfall model
 Separate and distinct phases of specification and development.
2. Evolutionary development
 Specification, development and validation are interleaved.
3. Component-based software engineering
 The system is assembled from existing components.
2-5

6. Software Processes
1.Waterfall Model
2-6

7. Software Processes
Cont’d…
2-7

8. Software Processes
Waterfall model Strengths
 The model is well known by non-software parties making it
easier to communicate.
 It is document driven and good model to use when requirements
are well understood and are quite stable.
 Late changes to requirements or design are limited.
 It offers a disciplined approach to software development because
all the steps of the project can be clear from the beginning.
2-8

9. Software Processes
Waterfall model problems
 The Model is inflexible for change as each phase results are
frozen
 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 systems engineering
projects where a system is developed at several sites.
2-9

10. Software Processes
When to use Waterfall model
 It works well for products that are well understood and
whose technical methodologies are also clear.
 It also works well for projects that are repeats of earlier
work such as migration, updates, new releases.
 When developing HRMS having had the experience of
similar reporting in the Payroll Systems.
2-10

11. Software Processes
2. Evolutionary(prototyping) development
 What is a Prototype?
It is a quickly developed,
easily modifiable and
extendible working model of the required application.
A prototype does not necessarily represent the complete
system.
2-11

12. Software Processes
Evolutionary development
2-12
Concurr
ent
activities
Validation
Final
version
Development
Inter
mediate
versions
Specifica
tion
Initial
version
Outline
description

13. Software Processes
Evolutionary development
 Problems
Lack of process visibility;
Systems are often poorly structured;
Special skills (e.g. in languages for rapid prototyping) may be
required.
 Applicability (when to use)
When requirement are not known at the beginning and unstable.
When quick demonstration required
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.
2-13

14. Software Processes
3. Component-based software engineering
 Based on systematic reuse where systems are integrated
from existing components or COTS (Commercial-off-the-
shelf) systems.
 Process stages
 Component analysis;
 Requirements modification;
 System design with reuse;
 Development and integration.
 This approach is becoming increasingly used as component
standards have emerged.
2-14

15. Software Processes 2-15
Reuse-oriented development
Requirements
specification
Component
analysis
Development
and integ
ration
System design
with reuse
Requirements
modification
System
validation

16. Software Processes
Chapter 2: roadmap
2.1 Software process and process models
2.2 Process iteration
2.3 Process activities
2.4 The Rational Unified Process
2.5 Computer-aided software engineering
2.6 Process assessment model and process metrics
2-16

17. Software Processes
2.2 Process iteration
 System requirements ALWAYS evolve in the course of a
project so process iteration where earlier stages are
reworked is always part of the process for large systems.
 Iteration can be applied to any of the generic process
models.
 Two (related) approaches
1. Incremental delivery;
2. Spiral development.
2-17

18. Software Processes
1. Incremental delivery
 Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
 User requirements are prioritised and the highest
priority requirements are included in early increments.
 Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.
2-18

19. Software Processes
Incremental delivery
2-19
Validate
increment
Develop system
increment
Design system
architectur
e
Integ
rate
increment
Validate
system
Define outline
requirements
Assign requirements
to increments
System incomplete
Final
system

20. Software Processes
Incremental delivery
2-20

21. Software Processes
Incremental development advantages
 Customer value can be delivered with each increment so
system functionality is available earlier.
 Early increments act as a prototype to help elicit
requirements for later increments.
 Lower risk of overall project failure.
 The highest priority system services tend to receive the
most testing.
2-21

22. Software Processes
Incremental development Weakness
 Use of the Incremental Model requires careful
partitioning of the system.
 Total cost is higher than waterfall.
 Lack of early planning may cause project management
problems: unknown schedules, budgets and deliverables.
2-22

23. Software Processes
When to use Incremental development
 When requirements are understood in the early stages
but can change during the project‘s life cycle.
 With lengthy projects.
 When new technology is being used.
 When it is too risky to develop the overall system as
one block.
2-23

24. Software Processes
2. Spiral development
 Process is represented as a spiral rather than as a
sequence of activities with backtracking.
 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.
2-24

25. Software Processes
Spiral model sector
 Objective setting
 Specific objectives for the phase are identified.
 Risk assessment and reduction
 Risks are assessed and activities put in place to reduce the key risks.
 Development and validation
 A development model for the system is chosen which can be any
of the generic models.
 Planning
 The project is reviewed and the next phase of the spiral is planned.
2-25

26. Software Processes
Spiral model of the software process
2-26

27. Software Processes
Spiral development
 Weakness
It requires excellent project management skills.
It demands expert knowledge of risk analysis and management.
 When to use
Projects that would benefit the most are those that would be
built on untested assumptions.
2-27

28. Software Processes
Chapter 2: roadmap
2.1 Software process and process models
2.2 Process iteration
2.3 Process activities
2.4 The Rational Unified Process
2.5 Computer-aided software engineering
2.6 Process assessment model and process metrics
2-28

29. Software Processes
2.3 Process activities
2.3.1. Software specification
2.3.2. Software design and implementation
2.3.3. Software validation
2.3.4. Software evolution
2-29

30. Software Processes
2.3.1 Software specification
 The process of establishing what services are required
and the constraints on the system’s operation and
development.
 Requirements engineering process
 Feasibility study;
 Requirements elicitation and analysis;
 Requirements specification;
 Requirements validation.
2-30

31. Software Processes
The requirements engineering process
2-31
Feasibility
stud
y
Requir
ements
elicitation and
analysis
Requir
ements
specification
Requir
ements
validation
Feasibility
report
System
models
User and system
requirements
Requir
ements
document

32. Software Processes
2.3.2 Software design and implementation
 The process of converting the system specification into
an executable system.
 Software design
 Design a software structure that realises the specification;
 Implementation
 Translate this structure into an executable program;
 The activities of design and implementation are closely
related and may be inter-leaved
2-32

33. Software Processes
Design process activities
 Architectural design
 Abstract specification
 Interface design
 Component design
 Data structure design
 Algorithm design
2-33

34. Software Processes
The software design process
2-34
Ar
chitectur
al
design
Abstr
act
specifica
tion
Inter
face
design
Component
design
Data
structur
e
design
Algorithm
design
System
architectur
e
Softw
are
specifica
tion
Inter
face
specifica
tion
Component
specifica
tion
Data
structur
e
specifica
tion
Algorithm
specifica
tion
Requir
ements
specifica
tion
Design acti
vities
Design pr
oducts

35. Software Processes
Structured methods
 Systematic approaches to developing a software design.
 The design is usually documented as a set of graphical
models.
 Possible models
 Object model;
 Sequence model;
 State transition model;
 Structural model;
 Data-flow model.
2-35

36. Software Processes
Programming and debugging
 Translating a design into a program and removing errors
from that program.
 Programming is a personal activity - there is no generic
programming process.
 Programmers carry out some program testing to
discover faults in the program and remove these faults in
the debugging process.
2-36

37. Software Processes
The debugging process
2-37
Loca
te
error
Design
err
or repair
Repair
err
or
Re-test
program

38. Software Processes
2.3.3 Software validation
 Verification and validation (V & V) is intended to show
that a system conforms to its specification and meets the
requirements of the system customer.
 Involves checking and review processes and system
testing.
 System testing involves executing the system with test
cases that are derived from the specification of the real
data to be processed by the system.
2-38

39. Software Processes
The testing process
2-39
Component
testing
System
testing
Acceptance
testing

40. Software Processes
Testing stages
 Component or unit testing
 Individual components are tested independently;
 Components may be functions or objects or coherent
groupings of these entities.
 System testing
 Testing of the system as a whole. Testing of emergent
properties is particularly important.
 Acceptance testing (alpha testing)
 Testing with customer data to check that the system meets the
customer’s needs.
2-40

41. Software Processes
Testing phases
2-41
Requirements
specifica
tion
System
specifica
tion
System
design
Detailed
design
Module and
unit code
and test
Sub-system
integration
test plan
System
integ
ration
test plan
Acceptance
test plan
Service
Acceptance
test
System
integration test
Sub-system
integration test

42. Software Processes
2.3.4 Software evolution
 Software is inherently flexible and can change.
 As requirements change through changing business
circumstances, the software that supports the business
must also evolve and change.
 Although there has been a distinction between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems are
completely new.
2-42

43. Software Processes
System evolution
2-43
Assess existing
systems
Define system
requirements
Propose system
changes
Modify
systems
New
system
Existing
systems

44. Software Processes
Chapter 2: roadmap
2.1 Software process and process models
2.2 Process iteration
2.3 Process activities
2.4 The Rational Unified Process
2.5 Computer-aided software engineering
2.6 Process assessment model and process metrics
2-44

45. Software Processes
2.4 The Rational Unified Process
Reading Assignment
2-45

46. Software Processes
Chapter 2: roadmap
2.1 Software process and process models
2.2 Process iteration
2.3 Process activities
2.4 The Rational Unified Process
2.5 Computer-aided software engineering
2.6 Process assessment model and process metrics
2-46

47. Software Processes
2.5 Computer-aided software engineering
 Computer-aided software engineering (CASE) is software to
support software development and evolution processes such as
requirements engineering, design, program development
and testing.
 Activity automation using CASE
 Graphical editors for system model development;
 Data dictionary to manage design entities;
 Graphical UI builder for user interface construction;
 Debuggers to support program fault finding;
 Automated translators to generate new versions of a program
2-47

48. Software Processes
Chapter 2: roadmap
2.1 Software process and process models
2.2 Process iteration
2.3 Process activities
2.4 The Rational Unified Process
2.5 Computer-aided software engineering
2.6 Process assessment model and process metrics
2-48

49. Software Processes
2.6 Process assessment model and process metrics
 A software process assessment is an appraisal, or review,
performed by a trained team of software professionals.
 Its purpose is፡
 to determine the current state of an organization's software
process,
 to identify the highest priority process issues, and
 to facilitate improvement actions.
 A good assessment requires a competent team, sound
leadership, and a cooperative organization.
2-49

50. Software Processes
Software Metrics
 Software metric relates the individual measures in some
way (e.g., the average number of errors found per review.
 A software engineer collects measures and develops
metrics so that indicators will be obtained.
 An indicator is a metric or combination of metrics that
provide insight into the software process, a software
project, or the product itself.
2-50

51. Software Processes
Why Measure Software
 Software projects are famous for running over schedule
and budget, yet still having quality problems.
 Software measurement lets one to quantify schedule,
work effort, product size, project status, and quality
performance.
 If one don‘t measure the current performance and use
the data to improve the future work estimates, those
estimates will just be guesses.
2-51

52. Software Processes
What to Measure
 One can measure many aspects of the software
products, projects, and processes.
 The trick is to select a small and balanced set of metrics
that will help the organization track progress toward its
goals.
2-52