SEA Side
Software Engineering Annotations
•AAnnotation 5:
Process Model
One hour presentation to inform you of new
techniques and practices in software development.
Professor Sara Stoecklin
Director of Software Engineering- Panama City
Florida State University – Computer Science
[email protected]
[email protected]
850-522-2091
850-522-2023 Ex 182
1
The Process Model
(Software Development Life Cycle (SDLC))
Methodology
2
Overview
 Heavyweight
 Waterfall Model, DOD Waterfall
 Unified Process
 RAD, Component Assembly Model
 Iterative, Evolutionary
 Spiral
 Middleweight
 Korbra
 UML Components
 CleanRoom
 Lightweight
 XP
 Agile Software Development
 CaLM
3
A Common Process Framework
Work Tasks
Work Products
Milestones
Deliverables
QA Checkpoints
4
Some Common Process Flows
Linear Process Flows
Iterative Process Flows
Incremental Process Flows
5
Linear Models
6
Linear Model Characteristics
Documentation driven model
 systematic and requires rigor.
 Inflexible partitioning of project into distinct stages
 difficult to respond to changes in customer requirements

Model appropriate when requirements are well-understood.
 Programmers HATE to create documentation.

Users HATE to read documentation.

If users read, they rarely understand documentation.
 Programmers don't understand other programmers documentations.
 Standards for documentation not clear although UML ordained.
7
Iterative Models
Prototyping
8
Evolutionary/Prototype Model
Issues
Process is not visible--Lack of process visibility
Systems are often poorly structured—Change tends to
corrupt the structures
Special tools and techniques may be required—Special
skills (e.g. in languages for rapid prototyping) 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
9
Iterative Models
team #3
team #2
team #1
b u s in e s s
m o d e l in g
b u s in e s s
m o d e lin g
m
d a t a
o d e l in g
p r o c e s s
m o d e l in g
business
modeling
d a ta
m o d e lin g
a p p l i c a tio n
g e n e r a t io n
te s tin g
&
tu rn o v e r
p ro cess
m o d e lin g
data
modeling
a p p lic a t io n
g e n e ra tio n
process
modeling
te s tin g
&
tu r n o v e r
application
generation
testing
&
turnover
60 - 90 days
RAD
10
The Incremental Model
increment 1
System/information
engineering
analysis
design
code
increment 2 analysis
test
design
analysis
increment 3
delivery of
1st increment
code
test
design
increment 4 analysis
delivery of
2nd increment
code
delivery of
3rd increment
test
design
code
test
delivery of
4th incremen
calendar time
11
Waterfall Model
SSR - System Software Review
PDR - Preliminary Design Review
CDR - Critical Design Review
TRR - Test Rediness Review
FCA - Functional Configuration Audit
PCA - Physical Configuration Audit
ORR - Operational Rediness Review
Software
Requirements
Analysis
SRS
Software
Design
SDS
Code and Unit
Testing
STP
Software
Integration
and Test
SIP
SSR
PDR
CDR
TRR
FCA
PCA
Software
Acceptance
Test
CRR
12
Waterfall - DOD Model
Hardware
Implementation
Hardware
System
Design
PP
Software
Requirements
Analysis
SRS
NASA Model)
Operational
Timelines
Preliminary
Software
Design
PDD
Detailed
Software
Design
SDS
Code and Unit
Testing
STP
Software
Integration
and Test
SIP
SDR
SSR
PDR
CDR
TRR
Software
Acceptance
Test
FCA
PCA
13
Rapid Application Development Model
Rapid Throwaway Prototype Model
Software
Requirements
Analysis
SRS
Build
Prototype
PDD
Software
Design
Code and Unit
Testing
SDS
STP
Software
Integration
and Test
SIP
SSR
PR
PDR
CDR
TRR
FCA
PCA
Software
Acceptance
Test
CRR
14
RAD Characteristics




High speed adaptation of the linear model
Based on Component-based construction
Has incremental flavor
Not well- suited where precision is required,
e.g. high risk systems not easily modularized systems
 Have rigid performance requirements
1. Model the Information Flow
2. Refine the flows into Data elements
3. Model the data transformations
4. Generate the code 4GLs, component reuse, CASE
5. Test and integration
15
Evolutionary (Prototype) Model
ONLY A PART OF THE FULL SYSTEM
Software
Requirements
Analysis
SRS
Build
Prototype
PDD
Software
Design
Code and Unit
Testing
SDS
STP
Software
Integration
and Test
SIP
SSR
PR
PDR
CDR
TRR
FCA
PCA
Series of Implementations of each PART
Software
Acceptance
Test
CRR
16
Incremental Development Model
ONLY A PART OF THE FULL SYSTEM
Software
Requirements
Analysis
SRS
Software
Design
SDS
Code and Unit
Testing
STP
Software
Integration
and Test
SIP
SSR
PDR
CDR
TRR
Can Determine a PART at any phase.
FCA
PCA
Software
Acceptance
Test
CRR
17
Characteristics of Incremental Model
Same Requirements, specification, maintenance,and
requirement phases as in Waterfall
The systems is partitioned into builds where each
build is independently designed and scheduled
"incrementally“ The 1st build gives some
"production"functionality Subsequent builds add
functionality
User perspective
Get some results quickly
Reduces new system "culture shock"
18
Characteristics of Incremental Model
Costs easily prorated over the development cycle
It employs the systems approach
Changes are easier to implement (e.g.design of later
builds may not start until some phases are complete
and all their changes well known).
Problems - May degenerate into "Build and Fix“
May result in builds that cannot integrate with one
another
19
Spiral Model
Planning
Risk
Analysis
Prototyping
Simulation
Client
Evaluation
and Input
Operational Prototype
Verification for Next Level
Developing
20
An Evolutionary (Spiral) Model
Planning
Customer
Communication
RiskAnalysis
Prototyping
Engineering
Customer
Evaluation
And
input
Construction & Release
Simulation/ Operational
Prototype/Verification for
the Next
Level/Development
21
V Model
REQUIREMENTS
ANALYSIS
OPERATION
& MAINTENANCE
Validate requirements
ACCEPTANCE
TESTING
SYSTEM
DESIGN
Verify design
PROGRAM
DESIGN
[Pfleeger 98]
SYSTEM
TESTING
UNIT & INTEGRATION TESTING
CODING
22
Operational Specification Model
[Pfleeger 98]
Execute and
Revise
OPERATIONAL
SPECIFICATION
(problem-oriented)
TRANSFORMED
SPECIFICATION
(implementation-
TEST
oriented)
SYSTEM
REQUIREMENTS
(sometimes informal
or incomplete)
DELIVERED
SYSTEM
23
Still Other Process Models
Concurrent process model—recognizes
that different part of the project will be
at different places in the process
Formal methods—the process to apply
when a mathematical specification is to
be developed
24
Heavyweight Methodologies
 Predictable sequential series of tasks
 Structured sequence of events
 Plan and work the plan
 Allows management of milestones
 Are rigid in deviations to the plan
 Lack flexibility to use different methods for
different problems
Trouble handling uncertainty
25
Capability Maturity Model
Organizations are not born using a mature process
model.
Most organizations use NO known process model
Watts Humphrey wrote a book to lay out a plan for
improving the process model within organizations.
His book “Managing the Software Process” and
other research has greatly improved the software
engineering process.
The SEI Developed a capability maturity model
which proposes a model for maturing an
organizations process model.
26
Capability Maturity Model
Five Process Maturity Levels
Level 0:
Level 1:
Level 2:
Level 3:
Level 4:
Level 5:
Chaos
Initial
Repeatable
Defined
Managed
Optimizing
27
Middleweight Methodologies






Predictable sequential series of tasks
Structured sequence of events
Plan and work the plan
Allows management of milestones
Are NOT rigid in deviations to the plan
Contain flexibility to use different methods for
different problems
 Handle uncertainty
 Domain experts and programmers work closely
28
CleanRoom Approach
Specification
Incremental
Development
Planning
Specification
and Design
Usage
Design
Statistical
Testing
Certification
29
Reuse and Automated Development
Models/Component Assembly Model
Software
Requirements
Analysis
SRS
Software
Design
SDS
Code and Unit
Testing
STP
Software
Integration
and Test
SIP
SSR
PDR
CDR
TRR
FCA
PCA
Software
Acceptance
Test
CRR
Identify Reusable Components
Informal Specification
Formal Specifications
Code
30
LightWeight Methodologies
Lightweight methodologies :
 Customer is the highest priority at all phases
 Change in requirements welcomed anytime
 Deliver is done frequently
 Domain experts and programmers work closely
 Motivate developers via various methods
 Hold conversations while prototyping or programming
 Amount of workable software is the measure of success
 Good Design occurs every moment
 Reflection on designs happen often
31
LightWeight Methodologies
Differenced between light and heavy
 Individuals over process
 Working software over documentation
 Customer collaboration over contracts
 Responding to change over planning
 Stepping up to the plate
32
LightWeight Methodology – CaLM
Design
Project
Management
Implementation
Meetings
33
The XP Process
Defines user
requirements
Build User
Stories
requirements
metaphor
Define Architectural
Spikes
bugs
new velocity
Conduct
Release
Planning
release plan
estimating
Conduct
Acceptance
Testing
Build
Iteration
release
next iteration
Controls Scope
Improves
Quality
34
Twelve XP Practices
Five Basic XP Principles
Small Releases
40-hour work week
On-site customer
Collective Ownership
Coding Standards
Seven Process Techniques
35
Twelve XP Practices
Seven Process Techniques
The Planning Game
Metaphor
Simple Design
Pair Programming
Refactoring
Continuous Integration
Testing
36
LightWeight Methodology – Agile
Visioning. A good visioning practice
Project initiation.
Short, iterative, feature-driven, timeboxed delivery
Constant feedback.
Customer involvement.
Technical excellence.
37
THE BEST
 Management must have milestones.
 Deliverables must be the payment guide.
 Lightweight methodologies do not scale.
 Pair programming WORKS for GOOD design.
 Customer involvement with constant feedback.
 Training is essential.
38
Descargar

Transparency Masters for Software Engineering: A