Transcript Software Process Models Lawrence Chung Software Engineering What is a Process?     Given input, transforms it into output Consist of a set of activities Ordering among.

Software Process Models
Lawrence Chung
Software Engineering
1
What is a Process?




Given input, transforms it into output
Consist of a set of activities
Ordering among the activities (a partial order)
Software Process





Also called methodology sometimes
People are everything
Involves use of “resources”, such as ???
Software process models ~~ software lifecycle models
Process descriptions are also specifications

Should be as complete, consistent and clear
2
Why Software Process?
Quality of product
Quality of Process
Garbage in garbage out,
so get the right requirements
Good Process: Input -> Software
Input -> Software
Bad Process: Input -> Software
Input -> Software
P
r
o
c
e
s
s
 thru garbage, garbage out,
so get the right process
Product
So, know the input sources, specify process & specify product
3
Software lifecycle models:
Generic software process models

The waterfall model


Incremental development (w. evolutionary)



Each loop in the spiral represents an incremental phase in the process.
Formal systems development


Each increment represents one functionality;
Specification and development can be interleaved
The Spiral model


Separate and distinct phases of specification and development
A mathematical system model is formally transformed to an implementation
Reuse-based development

The system is assembled from existing components
4
Waterfall model 1 [aka Royce1970]
Separate and distinct phases of specification and development
Systems Engineering
Software Req. Analysis
Operation/Maintenance
Project Planning
Design
Implementation
Testing/Verification
Release
5
Waterfall model 2 [Sommerville2000]
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
6
Waterfall model – pros and cons





Inflexible partitioning of the project into distinct
stages
This makes it difficult to respond to changing
customer requirements
This model is only appropriate when the requirements
are well-understood
Big design up front - time spent early on making sure that
requirements and design are correct is very useful in
economic terms (it will save you much time and effort later)
Simplicity and controllability
7
Incremental development
Define outline
requirements
Develop system
increment
Assign requirements
to increments
Valida te
increment
Design system
architecture
Integrate
increment
Valida te
system
Final
system
System incomplete




Development and delivery is broken down into increments
Each increment delivers part of the required functionality
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

Requirements for later increments can continue to evolve
8
Incremental development advantages




System functionality is available earlier and
customer does not have to wait as long
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
9
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

10
Spiral model
Deter mine ob jectiv es
alternatives and
cons traint s
Risk
analys is
Evaluate altern atives
id en tif y, resol ve risk s
Risk
analys is
Risk
analys is
REVIE W
Require ment s plan
Life-c ycle plan
Develop ment
plan
Plan next p hase
Integrati on
and test p lan
Prot otype 3
Prot otyp e 2
Risk
analysis Prot oty pe 1
Operati onal
prot oype
Simulati ons, models, b en ch marks
Concept of
Operati on
S/W
require ment s
Require ment
valid ati on
Prod uct
desi gn
Detailed
desi gn
Code
Unit tes t
Desi gn
V&V
Integr ati on
test
Accep tance
test
Develop, v erif y
Serv ice
next-level prod uct
11
Formal systems development



Based on the transformation of a mathematical
specification through different representations to
an executable program
Transformations are ‘correctness-preserving’ so it is
straightforward to show that the program
conforms to its specification
Embodied in the ‘Cleanroom’ approach to software
development

No need to test for defects
12
Formal systems development
Requirements
definition
Integration and
system testing
Formal
transformation
Formal
specification
Formal transformations
T1
Formal
specification
T2
R1
P1
T3
R2
P2
T4
Executable
program
R3
P3
Proofs of transformation correctness
P4
13
Formal systems development

Problems





Need for specialised skills and training to apply the technique
Difficult to formally specify some aspects of the system such
as the user interface
Changes require new transformations and proofs
Typically does not scale
Applicability

Critical systems (e.g., in terms of safety or security)
14
Reuse-oriented development


Based on systematic reuse where systems are integrated
from existing components or COTS systems
Process stages





Component analysis
Requirements modification
System design with reuse
Development and integration
Becoming important but still limited experience with it
Requirements
specification
Component
analysis
Requirements
modification
System design
with reuse
Development
and integration
System
validation
15
Extreme programming


New 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

Recently included into ‘agile methods’ since ‘extreme’
had a negative connotation
16
Capability Maturity Model [SEI]



Developed in 1986 with leadership from the Software Engineering
Institute (SEI) of Carnegie Mellon University (CMU), CMU-SEI.
For assessing and improving software processes
As a guidance for measuring software process maturity
Continuously
Improving
process
Predictable
process
4 - Managed
Standard,
Consistent
process
Disciplined
process
5 - Optimizing
3- Defined
2 - Repeatable
1 - Initial
17
Some CMM Observations…
 The number of companies using CMM to assess their software management
practices more than doubles every 5 years
 Software Quality Assurance is the biggest obstacle for organizations trying to move
from level 1 to level 2.
 Organization Process Definition is one of the biggest obstacles for organization
trying to move from level 2 to level 3.
 On average, it takes an organization:



25 months to move from level 1 to 2
22 months to move from level 2 to 3
36.5 months to move from level 3 to 4
 Only 1.2% of companies engaged in CMM have IT departments with over 2000
employees. Of these large companies, 40% are at CMM levels 3, 4 or 5.
 About 80% of companies engaged in CMM have IT departments with less than over
300 employees. Of these smaller companies, 21% are at CMM levels 3, 4, or 5.
 About 1/3 of companies engaged in CMM are located overseas (primarily India), and
are 3 times more likely to reach CMM level 4 or 5 than US organizations.
 Only about 23% of organizations surveyed eventually move from level 2 to level
3 or higher.
18
Focus
Continuous
Process Improvement
CMMI-SE/SW/IPPD/SS Staged
Optimizing
(5)
•Organizational Innovation and Deployment (OID)
•Causal Analysis and Resolution (CAR)
(2 PAs)
Quantitatively
Managed
(4)
Quantitative
Management
(2 PAs)
Defined
(3)
Process
Standardization
(11 PAs)
Basic Project
Management
Managed
(2)
(7 PAs)
Initial
(1)
•Organizational Process Performance (OPP)
•Quantitative Project Management (QPM)
•Requirements Development (RD)
•Technical Solution (TS)
•Product Integration (PI)
•Verification (VER)
•Validation (VAL)
•Organizational Process Focus (OPF)
•Organizational Process Definition (OPD)
•Organization Training (OT)
•Integrated Project Management (IPM) *
•Risk Management (RSKM)
•Decision Analysis and Resolution (DAR)
•Requirements Management (REQM)
•Project Planning (PP)
•Project Monitoring and Control (PMC)
•Supplier Agreement Management (SAM)
•Measurement and Analysis (M&A)
•Process and Product Quality Assurance (PPQA)
•Configuration Management (CM)
•Organization Environment
for Integration (OEI)
•Integrated Teaming (IT)
•Integrated Supplier
Management (ISM)
* Additional PA goals and
activities added for IPPD
Ad hoc, chaotic processes
19
Software Process Variability
Many Variety …and Evolution is inevitable


Software processes may vary radically from one
organisation to another
Factors contributing to this variability include






Technical maturity
Disciplinary involvement
Organisational culture
Application domain
…
There is therefore no ‘ideal’ software engineering
process [KotonyaSummerville98]
20
Points to Ponder



What kind of software process are you using for
doing your course project now? And why?
Have you ever reused any software components?
If so, what kind of software process was used
during the reuse?
When you carry out testing, what would be the
criteria to say a line of program is an error?
21