Software Engineering SW Cost Estimation Slide 1 Software Engineering Software Cost Estimation.
Software Engineering SW Process
Transcript of Software Engineering SW Process
-
8/20/2019 Software Engineering SW Process
1/43
Software Processes
October 2009 Ian Sommerville 1
-
8/20/2019 Software Engineering SW Process
2/43
Objectives
• To introduce software process models
• To describe three generic process models andwhen they may be used
• To describe outline process models forrequirements engineering, softwaredevelopment, testing and evolution
• To explain the Rational Unified Process model• To introduce CASE technology to support
software process activities
October 2009 Ian Sommerville 2
-
8/20/2019 Software Engineering SW Process
3/43
The software process
• A structured set of activities required to develop a
software system
1. Specification;
2. Design;
3. Validation;
4. Evolution.
• A software process model is an abstract representation of a
process. It presents a description of a process from some
particular perspective.
October 2009 Ian Sommerville 3
-
8/20/2019 Software Engineering SW Process
4/43
Generic software process models
• The waterfall model
– Separate and distinct phases of specification and development.
• Evolutionary development
– Specification, development and validation are interleaved.
• Component-based software engineering – The system is assembled from existing components.
• There are many variants of these models e.g. formal developmentwhere a waterfall-like process is used but the specification is a formalspecification that is refined through several stages to animplementable design.
October 2009 Ian Sommerville 4
-
8/20/2019 Software Engineering SW Process
5/43
Waterfall model
October 2009 Ian Sommerville 5
Requir ementsdefinition
System and
software design
Implementa tion
and unit testing
Integration and
system testing
Oper ation and
maintenance
-
8/20/2019 Software Engineering SW Process
6/43
Waterfall model phases
1. Requirements analysis and definition
2. System and software design
3. Implementation and unit testing
4. Integration and system testing5. Operation and maintenance
The main drawback of the waterfall model is the
difficulty of accommodating change after theprocess is underway. One phase has to be completebefore moving onto the next phase.
October 2009 Ian Sommerville 6
-
8/20/2019 Software Engineering SW Process
7/43
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 systems engineering
projects where a system is developed at several sites.
October 2009 Ian Sommerville 7
-
8/20/2019 Software Engineering SW Process
8/43
Evolutionary development
• Exploratory development
– Objective is to work with customers and to evolve a
final system from an initial outline specification.
Should start with well-understood requirements andadd new features as proposed by the customer.
• Throw-away prototyping
– Objective is to understand the system requirements.
Should start with poorly understood requirements to
clarify what is really needed.
October 2009 Ian Sommerville 8
-
8/20/2019 Software Engineering SW Process
9/43
Evolutionary development
October 2009 Ian Sommerville 9
Concurr entacti vities
ValidationFinal
version
DevelopmentIntermedia te
versions
Specification
Initial
version
Outlinedescription
-
8/20/2019 Software Engineering SW Process
10/43
Evolutionary development
• Problems
– Lack of process visibility;
– Systems are often poorly structured;
– Special skills (e.g. in languages for rapidprototyping) may be required.
• Applicability
– For small or medium-size interactive systems; – For parts of large systems (e.g. the user interface);
– For short-lifetime systems.
October 2009 Ian Sommerville 10
-
8/20/2019 Software Engineering SW Process
11/43
-
8/20/2019 Software Engineering SW Process
12/43
Reuse-oriented development
October 2009 Ian Sommerville 12
Requirements
specification
Component
analy sis
Development
and integ ration
System design
with reuse
Requirements
modification
System
validation
-
8/20/2019 Software Engineering SW Process
13/43
Process iteration
• System requirements ALWAYS evolve in thecourse of a project so process iteration whereearlier 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 – Incremental delivery; – Spiral development.
October 2009 Ian Sommerville 13
-
8/20/2019 Software Engineering SW Process
14/43
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 priorityrequirements 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.
October 2009 Ian Sommerville 14
-
8/20/2019 Software Engineering SW Process
15/43
Incremental development
October 2009 Ian Sommerville 15
Validate
increment
Develop system
increment
Design system
architectur e
Integrate
increment
Validate
system
Define outline requirements
Assign requirements to increments
System incomplete
Finalsystem
-
8/20/2019 Software Engineering SW Process
16/43
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.
October 2009 Ian Sommerville 16
-
8/20/2019 Software Engineering SW Process
17/43
Extreme programming
• An approach to development based on the
development and delivery of very small
increments of functionality.
• Relies on constant code improvement, user
involvement in the development team and
pairwise programming.
• Covered in Chapter 17
October 2009 Ian Sommerville 17
-
8/20/2019 Software Engineering SW Process
18/43
Spiral development
• Process is represented as a spiral rather thanas 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.
October 2009 Ian Sommerville 18
-
8/20/2019 Software Engineering SW Process
19/43
Spiral model of the software process
October 2009 Ian Sommerville 19
Risk
anal ysis
Risk
anal ysis
Risk
anal ysis
Risk
anal ysis Proto-
type 1
Prototype 2
Prototype 3Oper a-
tional
pr oto ype
Concept of
Oper ation
Simul ations, models , benchmar ks
S/W
requir ements
Requir ement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integ ration
test Acceptance
testService Develop , verify
next-level pr oduct
Evalua te alterna tives,
identify , resolv e risks
Deter mineobjecti ves,
alterna tives and
constr aints
Plan ne xt phase
Integ ration
and test plan
Development
plan
Requir ements plan
Li fe-cy cle plan
REVIEW
-
8/20/2019 Software Engineering SW Process
20/43
Spiral model sectors
• 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 beany of the generic models.
• Planning
– The project is reviewed and the next phase of the spiral isplanned.
October 2009 Ian Sommerville 20
-
8/20/2019 Software Engineering SW Process
21/43
Process activities
1. Software specification
2. Software design and implementation
3. Software validation4. Software evolution
October 2009 22Ian Sommerville
-
8/20/2019 Software Engineering SW Process
22/43
Software specification (1)
• The process of establishing what services are
required and the constraints on the system’s
operation and development.
• Requirements engineering process
1. Feasibility study;
2. Requirements elicitation and analysis;
3. Requirements specification;
4. Requirements validation.
October 2009 23Ian Sommerville
-
8/20/2019 Software Engineering SW Process
23/43
The requirements engineering process
Feasibility
stud y
Requir ements
elicitation and
anal ysis
Requir ements
specification
Requir ements
validationFeasibil ity
repor t
System
models
User and system
requirements
Requir ements
document
October 2009 24Ian Sommerville
-
8/20/2019 Software Engineering SW Process
24/43
Software design and implementation (2)
• The process of converting the systemspecification into an executable system.
• Software design
– Design a software structure that realises thespecification;
• Implementation – Translate this structure into an executable
program;• The activities of design and implementation
are closely related and may be inter-leaved.
October 2009 25Ian Sommerville
-
8/20/2019 Software Engineering SW Process
25/43
Design process activities
1. Architectural design
2. Abstract specification
3. Interface design4. Component design
5. Data structure design
6. Algorithm design
October 2009 26Ian Sommerville
-
8/20/2019 Software Engineering SW Process
26/43
A general model of the design process
27Chapter 2 Software Processes
-
8/20/2019 Software Engineering SW Process
27/43
The software design process
Ar chitectural
design
Abstract
specif ication
Interface
design
Component
design
Data
structure
design
Algorithm
design
System
architecture
Software
specif ication
Interface
specif ication
Component
specif ication
Data
structurespecif ication
Algorithm
specif ication
Requirementsspecif ication
Design activities
Design products
October 2009 28Ian Sommerville
1 2 3 4 5 6
-
8/20/2019 Software Engineering SW Process
28/43
Structured methods
• Systematic approaches to developing asoftware 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.
October 2009 29Ian Sommerville
-
8/20/2019 Software Engineering SW Process
29/43
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.
October 2009 30Ian Sommerville
-
8/20/2019 Software Engineering SW Process
30/43
Software validation (3)
• Verification and validation (V & V) is intendedto show that a system conforms to itsspecification and meets the requirements ofthe system customer.
• Involves checking and review processes andsystem testing.
• System testing involves executing the system
with test cases that are derived from thespecification of the real data to be processedby the system.
October 2009 31Ian Sommerville
-
8/20/2019 Software Engineering SW Process
31/43
The testing process
Componenttesting
Systemtesting
Acceptancetesting
October 2009 32Ian Sommerville
-
8/20/2019 Software Engineering SW Process
32/43
Testing phases
Requir ements
specification
System
specification
System
design
Detailed
design
Module and
unit codeand test
Sub-system
integ rationtest plan
System
integrationtest plan
Acceptance
test plan
Service Acceptance
test
System
integ ration test
Sub-system
integ ration test
October 2009 33Ian Sommerville
-
8/20/2019 Software Engineering SW Process
33/43
Software evolution (4)
• Software is inherently flexible and can change.
• As requirements change through changingbusiness circumstances, the software that
supports the business must also evolve andchange.
• Although there has been a demarcationbetween development and evolution(maintenance) this is increasingly irrelevant asfewer and fewer systems are completely new.
October 2009 34Ian Sommerville
-
8/20/2019 Software Engineering SW Process
34/43
System evolution
Assess existingsystems
Def ine systemrequirements
Propose systemchanges
Modifysystems
New
system
Existing
systems
October 2009 35Ian Sommerville
-
8/20/2019 Software Engineering SW Process
35/43
The Rational Unified Process
• A modern process model derived from the
work on the UML and associated process.
• Normally described from 3 perspectives
1. A dynamic perspective that shows phases over
time;
2. A static perspective that shows process
activities;3. A proactive perspective that suggests good
practice.
October 2009 36Ian Sommerville
-
8/20/2019 Software Engineering SW Process
36/43
The Rational Unified Process
phase model
Phase iteration
Inception Elaboration Construction Transition
October 2009 37Ian Sommerville
-
8/20/2019 Software Engineering SW Process
37/43
RUP phases
• Inception
– Establish the business case for the system.
• Elaboration
– Develop an understanding of the problem domainand the system architecture.
• Construction
– System design, programming and testing.• Transition
– Deploy the system in its operating environment.
October 2009 38Ian Sommerville
-
8/20/2019 Software Engineering SW Process
38/43
RUP good practice
• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Verify software quality
• Control changes to software
October 2009 39Ian Sommerville
-
8/20/2019 Software Engineering SW Process
39/43
Static workflows
Workflow Description
Business modelling The business processes are modelled using business use cases.
Requirements Actors who interact with the system are identified and use cases aredeveloped to model the system requirements.
Analysis and design A design model is created and documented using architectural
models, component models, object models and sequence models.
Implementation The components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from design
models helps accelerate this process.
Test Testing is an iterative process that is carried out in conjunction withimplementation. System testing follows the completion of the
implementation.
Deployment A product release is created, distributed to users and installed in their
workplace.
Configuration and
change management
This supporting workflow managed changes to the system (see
Chapter 29).
Project management This supporting workflow manages the system development (see
Chapter 5).
Environment This workflow is concerned with making appropriate software tools
available to the software development team.
October 2009 40Ian Sommerville
-
8/20/2019 Software Engineering SW Process
40/43
Computer-aided software engineering
• Computer-aided software engineering (CASE) is software to
support software development and evolution processes.
• Activity automation
– 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.
October 2009 41Ian Sommerville
-
8/20/2019 Software Engineering SW Process
41/43
Case technology
• Case technology has led to significant
improvements in the software process. However,
these are not the order of magnitude
improvements that were once predicted – Software engineering requires creative thought - this
is not readily automated;
– Software engineering is a team activity and, for large
projects, much time is spent in team interactions.
CASE technology does not really support these.
October 2009 42Ian Sommerville
-
8/20/2019 Software Engineering SW Process
42/43
CASE classification
• Classification helps us understand the different types of CASE
tools and their support for process activities.
• Functional perspective
– Tools are classified according to their specific function.
• Process perspective
– Tools are classified according to process activities that are
supported.
• Integration perspective
– Tools are classified according to their organisation into integratedunits.
October 2009 43Ian Sommerville
-
8/20/2019 Software Engineering SW Process
43/43
Key points
• Requirements engineering is the process of developing asoftware specification.
• Design and implementation processes transform thespecification to an executable program.
• Validation involves checking that the system meets to itsspecification and user needs.
• Evolution is concerned with modifying the system after it is inuse.
• The Rational Unified Process is a generic process model that
separates activities from phases.• CASE technology supports software process activities.