Upload
lyhanh
View
216
Download
0
Embed Size (px)
Citation preview
Chapter 2 Software Processes Slide 2
Topics covered
Software processes and process models
Generic models:
• Waterfall
• Incremental development
• Reuse-oriented software engineering
Basic process activities:
• Specification
• Development
• Validation
• Evolution
(cont'd)
Chapter 2 Software Processes Slide 3
Topics covered (cont’d)
Coping with change
Software prototyping:
• Uses of prototypes
• Classifying prototypes
• User Interface prototyping
(Mills’) Incremental Delivery (cf. Incremental
development)
Boehm’s spiral model
The Rational Unified Process (an example of a
modern software development method)
Chapter 2 Software Processes Slide 5
The software process
A process is a structured set of activities required to develop a software system.
Many different software processes, but all involve:
• Specification – defining what the system should do;
• Design & implementation;
• Validation – checking that it does what the customer wants (and
Verification – checking that it does what is specified);
• Evolution – changing the system in response to changing customer needs.
A process MODEL is an abstract representation of a process. It presents a description of a process from some particular perspective
Models should be as simple as possible, but no simpler. – A. Einstein
[struhk-cherd] –adjective; having a
clearly defined structure or organization.
Chapter 2 Software Processes Slide 6
The software process
A process is a structured set of activities required to develop a software system.
Many different software processes, but all involve:
• Specification – defining what the system should do;
• Design & implementation;
• Validation – checking that it does what the customer wants (and
Verification – checking that it does what is specified);
• Evolution – changing the system in response to changing customer needs.
A process MODEL is an abstract representation of a process. It presents a description of a process from some particular perspective
Models should be as simple as possible, but no simpler. – A. Einstein
[struhk-cherd] –adjective; having a
clearly defined structure or organization.
Chapter 2 Software Processes Slide 7
Plan-driven and agile processes
Plan-driven processes: all of the process activities
are planned in advance and progress is measured
against this plan.
Agile processes: planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
In practice, most practical processes include
elements of both plan-driven and agile approaches.
There are no right or wrong software processes!
Chapter 2 Software Processes Slide 9
Generic software process models
The Waterfall Model – plan-driven model; separate and
distinct phases of specification and development. not iterative
Incremental Development – specification, development,
& validation are interleaved; may be plan-driven or agile.
Reuse-Based Development – e.g., “component-
based SE”: the system is assembled from existing
components; may be plan-driven or agile.
-----------------------------
In practice, most large systems are developed using a pro-
cess that incorporates elements from all of these models.
(And, at no additional cost: Boehm’s Spiral Model.)
Chapter 2 Software Processes Slide 10
Waterfall model (W. Royce)
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Chapter 2 Software Processes Slide 11
Waterfall model (cont’d)
There are separate phases in the waterfall model:
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
Model is mostly used for large systems engineering
projects where a system is developed at several sites.
In such circumstances, its plan-driven nature helps in
coordinating the work.
Chapter 2 Software Processes Slide 12
Waterfall model problems
Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
• Thus, more appropriate when requirements are well-
understood to begin with.
• This applies to relatively few systems.
---------------------------------------------
In general, the drawback of the waterfall model is the
difficulty of accommodating change after the pro-
cess is underway.
Chapter 2 Software Processes Slide 13
Incremental development
ValidationFinal
version
DevelopmentIntermediate
versions
SpecificationInitial
version
Outline
description
Concurrent
activities
Chapter 2 Software Processes Slide 14
Incremental development benefits
Reduces cost of accommodating changing customer
requirements - amount of analysis and documentation that
has to be re-done is much less than is required with the waterfall
model.
Easier to get customer feedback - customers can
comment on demonstrations of the software and see how much
has been implemented.
More rapid delivery & deployment of useful software
to the customer is possible - customers may be able to
use and gain value from the software earlier than is possible
with a waterfall process.
Chapter 2 Software Processes Slide 15
Incremental development problems
Lack of process visibility - lack of document 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.
Chapter 2 Software Processes Slide 16
Reuse-oriented software engineering
Based on systematic (as opposed to serendipitous)
reuse - systems are integrated from existing components or COTS
(Commercial-Off-The-Shelf) systems.
Process stages
• Component analysis (Assessing what’s available.)
• Requirements modification (Why is this needed?)
• System design with reuse
• Development and integration
“Reuse” is now the standard approach for building many
types of business systems.
(cont'd)
Chapter 2 Software Processes Slide 17
Reuse-oriented software engineering
Requirementsspecification
Componentanalysis
Developmentand integration
System designwith reuse
Requirementsmodification
Systemvalidation
(what’s available?)
(cont'd)
Chapter 2 Software Processes Slide 18
Types of reusable software components
Web services that are developed according to
service standards and which are available for
remote invocation.
Collections of objects that are developed as a
package to be integrated within a component
framework such as .NET or J2EE (Java EE 6).
Stand-alone software systems (COTS) that
are configured for use in a particular environ-
ment.
Chapter 2 Software Processes Slide 20
Process activities
Actual software processes are interleaved or se-
quences of technical, collaborative and managerial
activities with the overall goal of specifying,
designing, implementing and testing a software
system.
The four basic process activities of specification,
development, validation (& verification), and
evolution are organized differently in different
development processes. In the waterfall model, they
are organized in sequence; in incremental
development they are interleaved.
Chapter 2 Software Processes Slide 21
Software specification / RE
The process of establishing what services are required
and the constraints on the system’s operation and
development.
Requirements Engineering (RE) process:
• Feasibility (technical and otherwise) study
• Requirements elicitation and analysis
• Requirements specification (documentation)
• Requirements validation
(cont'd)
Chapter 2 Software Processes Slide 22
The requirements engineering
process (waterfall perspective)
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirements
document
Chapter 2 Software Processes Slide 23
Software design and implementation
The process of producing an executable system
based on the specification (waterfall perspective)
• Software design – design a software structure that realizes
the specification.
• Implementation – translate this structure into an executable
program.
Note: the activities of specification, design, and
implementation are closely related and may be
interleaved (as with incremental development).
Chapter 2 Software Processes Slide 24
Design activities
Architectural design: identify overall structure of
system, principal components (sometimes called
sub-systems or modules), their relationships, and
how they are distributed.
Interface design: define the interfaces between
system components.
Component design: design how each system
component will operate.
Database (data structure) design: design the system
data structures and how these are to be represented
in a database.
Chapter 2 Software Processes Slide 25
Software verification & validation
Verification and validation (V&V) determines whether or
not a system (1) conforms to its specification and (2)
meets the requirements of the customer.
Involves checking processes (e.g., inspections/reviews,
formal verification) and program (machine-based)
testing.
Testing is the most commonly used V&V activity
and involves executing program elements with test
cases that are derived from analyzing specifications
and/or program logic.
Chapter 2 Software Processes Slide 26
Testing stages
Development or component 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
• Testing with customer data to check that the system
meets the customer’s needs/desires.
Chapter 2 Software Processes Slide 27
Software evolution (“maintenance”)
Software is inherently flexible and subject to change.
As requirements change through changing
business/environmental circumstances, the software
must also evolve and change.
The distinction between development and evolution
has become increasingly irrelevant as fewer and
fewer systems are completely new.
(cont'd)
Chapter 2 Software Processes Slide 28
Software evolution (“maintenance”)
Assess existing
systems
Define systemrequirements
Propose systemchanges
Modify
systems
Newsystem
Existing
systems
e.g., change
requests
Chapter 2 Software Processes Slide 30
Inevitability of change
Change is inevitable in all large software projects.
• Business/environmental changes lead to new and
changed system requirements.
• New technologies open up new possibilities for improving
implementations.
• Changing platforms require application changes.
Change costs include both re-work (redoing already
completed work -- e.g., re-analyzing requirements)
and the cost of implementing new functionality.
Chapter 2 Software Processes Slide 31
Reducing the costs of re-work
Change avoidance: includes process activities that can
stimulate user/stakeholder anticipation of needs/require-
ments before development begins.
• E.g., a prototype may allow users/stakeholders to better envi-
sion how the system would actually be used.
Change tolerance: the development process and/or
product may be designed to reduce change costs.
• If the systems is delivered in increments (e.g., via Mills’ Incre-
mental Delivery), re-work may only be required in those
increments that have already been developed.
• Information hiding techniques (isolating potentially changeable
design decisions) may be employed in product design.
Chapter 2 Software Processes Slide 33
What is prototyping?
An iterative process emphasizing:
• Rapid development
• Concreteness and evaluative use (a “real system” is developed and presented to real users for hands-on evaluation)
• Consideration of alternatives
• Feedback
• Modification
Chapter 2 Software Processes Slide 34
General Prototyping process
Establishprototypeobjectives
Defineprototype
functionality
Developprototype
Evaluateprototype
Prototypingplan
Outlinedefinition
Executableprototype
Evaluationreport
What to include & what
NOT to include.
Chapter 2 Software Processes Slide 35
Uses of prototypes
Principal use is to help customers and
developers better understand system
requirements.
• Experimentation stimulates anticipation of how
a system could/may actually be used.
• Attempting to use functions together to
accomplish some task often reveals subtle
requirements problems.
(cont’d)
Chapter 2 Software Processes Slide 36
Uses of prototypes (cont’d)
Other potential uses:
1. Evaluating proposed solutions for feasibility
(=“Experimental Prototyping”)
2. Develop and evaluate User Interface designs
3. “Back-to-back testing”
4. Training users before system delivery
Prototyping is most often undertaken as a
risk reduction activity.
Chapter 2 Software Processes Slide 37
Classifying prototypes
By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
Chapter 2 Software Processes Slide 38
Throw-away prototyping
Outline
requirements
Develop
prototype
Evaluate
prototype
Specify
system
Developsoftware
Validatesystem
Deliveredsoftwaresystem
Reusablecomponents
Elicit/validate REQMTS
Chapter 2 Software Processes Slide 39
Classifying prototypes
By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
Chapter 2 Software Processes Slide 40
Classifying prototypes
By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
F
i
d
e
l
i
t
y
Number of features few many
low
high Vertical prototype
Horizontal prototype points of
comparable effort
Chapter 2 Software Processes Slide 44
Classifying prototypes
By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
Chapter 2 Software Processes Slide 45
Quin Tech “Self-service check-in and
baggage drop-off design”
“The design was tested through a full-scale mock-up.”
Chapter 2 Software Processes Slide 46
Electronic circuit on a bread-
board (REUK.co.uk)
“There is no need to solder anything, and the components can be moved
around and the circuit modified thousands of times without damaging parts.”
Chapter 2 Software Processes Slide 47
Classifying prototypes
By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed?)
Chapter 2 Software Processes Slide 49
The Wizard of Oz exposed…
“The truth is the Wizard was an illusion created by a man hidden behind a curtain.”
Chapter 2 Software Processes Slide 50
Prototyping versus simulation
What’s the difference between prototyping and
simulation?
Chapter 2 Software Processes Slide 51
Throw-away prototype delivery
Developers may be “pressurized” to deliver a throw-
away prototype as the final system.
This is problematic...
• It may be impossible to meet non-functional
requirements with the prototype.
• The prototype is almost certainly undocumented.
• The system (prototype) may be poorly structured
and therefore difficult to maintain.
• Normal organizational quality standards may not
have been applied.
?
Air Tank
Developer
User Mgmt
No, no, no! I won’t
deliver the prototype to
you!
“Pressurizing” the
Developer
Chapter 2 Software Processes Slide 53
Implementation techniques
Various techniques may be used to implement
prototypes:
• Dynamic, high-level languages
• Database programming (RAD)
• Component and application assembly
These are NOT mutually exclusive – they are
often used together.
Visual programming is also an inherent part of
most prototype development systems.
Chapter 2 Software Processes Slide 54
User interface prototyping
User interface development consumes an
increasing part of overall system develop-
ment costs.
It is usually impossible to pre-specify the look
and feel of a complex user interface in an
effective way. Thus, prototyping is essential.
(cont’d)
Chapter 2 Software Processes Slide 55
User interface prototyping (cont’d)
Aim is to allow users to gain direct experi-
ence with the interface.
Without this, it is almost impossible to judge
usability.
Often a two-stage process:
• paper prototypes are developed initially,
• followed by a series of increasingly sophis-
ticated automated prototypes.
Chapter 2 Software Processes Slide 56
Paper prototyping
Step through scenarios using sketches of the
interface.
Use storyboards to present a series of interactions
with the system.
Paper prototyping is a cost-effective way of obtaining
user reactions to an interface design proposal.
Chapter 2 Software Processes Slide 57
(Mills’) Incremental Delivery
(not to be confused with
“incremental development”)
Chapter 2 Software Processes Slide 58
Incremental Delivery
Rather than deliver the system as a single unit, the
development and delivery is broken down into
increments, each of which incorporates part of the
required functionality.
User requirements are prioritized and the highest
priority requirements are included in early
increments.
Once the development of an increment is started, its
requirements are “frozen” while requirements for
later increments can continue to evolve. (Compromise between Waterfall & Incremental Development)
(cont’d)
Chapter 2 Software Processes Slide 59
Incremental Delivery
Valida te
increment
Develop systemincrement
Design systemarchitecture
Integrateincrement
Valida te
system
Define outline requirements
Assign requirements to increments
System incomplete
Finalsystem
(cont'd)
Chapter 2 Software Processes Slide 60
Incremental development versus
Incremental Delivery
Incremental development
• Develop the system in increments that are made available for
customer evaluation & feedback (but not usually for actual
work in the customer’s own environment) before proceeding to
the development of the next increment;
• Normal approach used in agile methods (but may also be used
in plan-driven development);
• Evaluation undertaken by user/customer (or a proxy).
(Mills’) Incremental Delivery
• Deploy increments for actual work-place use by end-users;
• Permits more realistic evaluation of practical usefulness;
• Difficult to carry out for replacement systems as increments
provide less functionality than the system being replaced.
Chapter 2 Software Processes Slide 61
Advantages of Incremental Delivery
Useful functionality is delivered with each increment,
so customers derive value early.
Early increments assist in eliciting requirements for
later increments.
Lower risk of overall project failure.
The highest priority system services tend to receive
the most testing. (They're subject to more “validation” steps.)
(cont'd)
Chapter 2 Software Processes Slide 62
Potential problems with Incremental
Delivery
Requirements may NOT be partitionable into usable,
stand-alone increments. (e.g., consider a compiler)
Most systems require a set of basic facilities that are used by
different parts of the system. But since requirements are not
defined in detail until an increment is to be implemented, it can
be hard to identify common facilities that are needed by all
increments to be useful.
The essence of an iterative process is that the specification is
developed in conjunction with the software. But this conflicts
with the procurement model of many organizations, where
the complete specification is part of the system development
contract (also a problem with incremental development).
Chapter 2 Software Processes Slide 64
Boehm’s spiral development model
Process is represented as a spiral rather than 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.
Explicitly incorporates risk assessment and
resolution throughout the process.
(cont'd)
Chapter 2 Software Processes Slide 66
Boehm’s spiral development model
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2
Prototype 3Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
Code
Unit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
Chapter 2 Software Processes Slide 67
Spiral model quadrants
Objective Setting – specific objectives for the phase are
identified. Project risks and alternative strategies 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.
Chapter 2 Software Processes Slide 68
Spiral model usage
The model has been very influential in
helping people think about iteration in
software processes and introducing the risk-
driven approach to development.
In practice, however, the model is rarely used
as published for practical software develop-
ment.
Chapter 2 Software Processes Slide 70
The Rational Unified Process
A modern process model derived from the work on
the UML and its associated process.
A hybrid process model that brings together aspects
of the generic process models discussed previ-
ously…it represents a new generation of generic
processes.
Normally described from 3 perspectives
• A dynamic perspective that shows phases over time;
• A static perspective that shows process activities;
• A practice perspective that suggests good practices.
Chapter 2 Software Processes Slide 71
RUP phase model
Phase iteration
Inception Elaboration Construction Transition
cf. Waterfall Model: RUP phases are more closely
related to business rather than technical concerns.
“in-phase iteration” “cross-phase iteration”
Chapter 2 Software Processes Slide 72
RUP phases
Inception
• Establish the business case for the system.
Elaboration
• Develop an understanding of the problem domain and the
system architecture.
Construction
• System design, programming and testing.
Transition
• Deploy the system in its operating environment.
Chapter 2 Software Processes Slide 73
Static workflows (process activities) in RUP
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 are developed 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 into implementation sub-systems.
Automatic code generation from design models helps
accelerate this process.
Chapter 2 Software Processes Slide 74
RUP “good practices”
Develop software iteratively: plan increments
based on customer priorities and deliver highest
priority increments first.
Manage requirements: explicitly document and
keep track of changes.
Use component-based architectures: organize
system architecture as a set of reusable
components.
(cont'd)
Chapter 2 Software Processes Slide 75
RUP “good practices” (cont’d)
Visually model software: using graphical UML
models to present static and dynamic views.
Verify software quality: ensure software meets
organizational quality standards.
Control changes to software: using change
management system and configuration management
tools.
Chapter 2 Software Processes Slide 76
Key points
Software processes are the activities involved
in producing and evolving a software system.
They are represented abstractly by software
process models.
Generic models are very general and represent
different approaches to development.
Examples are the waterfall model, incremental
development, and reuse-oriented development.
(cont'd)
Chapter 2 Software Processes Slide 77
Key points (cont’d)
Requirements engineering is the process of establishing what services are required and the constraints on the system’s operation and development.
Design and implementation processes produce an executable system based on the specification.
V&V involves checking that the system meets its specification and satisfies user needs.
Evolution is concerned with modifying the system after it is placed in use. Software must evolve to remain useful.
(cont'd)
Chapter 2 Software Processes Slide 78
Key points (cont’d)
Processes should include activities to cope with
change. This may involve a prototyping phase
that helps avoid poor decisions on requirements
and design.
Throw-away prototyping is used to explore
requirements and design options.
Rapid development of prototypes is essential.
This usually requires leaving out functionality or
relaxing non-functional constraints.
(cont'd)
Chapter 2 Software Processes Slide 79
Key points (cont’d)
Prototyping may be essential for parts of the
system such as the user interface which cannot
be effectively pre-specified.
Users must be involved in prototype evaluation.
The Rational Unified Process is a modern
generic process model that is organized into
phases (inception, elaboration, construction and
transition) but separates activities (requirements,
analysis and design, etc.) from these phases.