Download Process Areas - DePaul University

SE 325/425
Principles and
Practices of Software
Engineering
Autumn 2006
James Nowotarski
7 November 2006
Today’s Agenda
Topic
Duration

Recap
20 minutes

Capability maturity model (CMM)
60 minutes
*** Break

Current event reports
20 minutes

CMM (continued)
60 minutes
2
Design
Planning & Managing
Communication
project initiation
requirements
Modeling
analysis
design
Design model:
• Data/Class
• Architecture
• Interfaces
• Components
Construction
code
test
Deployment
delivery
support
Primary deliverables
3
Key principles of
architectural design
Abstraction
 Modularity
 Reuse

4
Two qualitative criteria


Cohesion
A measure of the relative functional strength of
a module
Func A-1
Func B-1
Func A-2
Func B-2
Func A-3
Func B-3
High Cohesion (good)
Coupling
A measure of the relative interdependence
among modules
High coupling (bad)
5
Architecture
arch·i·tec·ture n. An
architecture depicts the
overall structure of a
man-made complex
system
6
Software architecture
Applications and
Data
• Presentation layer
• Application logic
• Data management
Middleware
System Software
Hardware/Network
7
Taxonomy of architectural
styles
 Data-centered
 Data
flow (aka pipes and filters)
 Call and return
 Object oriented architectures
 Layered Systems
 Online transaction processing
 Process control
8
Data centered
9
Data flow
Filter
Pipe
Filter
Filter
Pipe
Filter
Pipe
Filter
Filter
Pipe
Pipe
Pipe
Filter
 Examples:
 UNIX shell commands
 Compilers:
Lexical Analysis -> parsing -> semantic analysis -> code
generation
 Batch Processing
10
Call and return
PROCESS_PAYROLL
for each employee
get_data(:employee_data)
calc_salary(employee_data:salary)
calc_tax(salary:tax)
print_check(employee_data, salary, tax)
employee_data
employee_data
employee_
data
salary
salary
tax
salary
GET_DATA
CALC_SALARY
CALC_TAX
tax
PRINT_CHECK
11
Deriving a software architecture:
Structured approach
Derive architectural context diagram
(ACD)
 Refine the DFD
 Map DFD to program structure:

Transform mapping
 Transaction mapping

12
Architecture context diagram
(ACD)
Safehome
Product
control
panel
homeowner
Internet-based
system
target system:
Security Function
uses
surveillance
function
peers
uses
uses
sensors
sensors
13
Transform mapping
a
b
d
e
h
g
f
i
c
j
data flow model
x1
x2
b
x4
x3
c
a
"Transform" mapping
d
e
f
g
i
h
j
14
Transaction Mapping
Data flow model
f
e
a
d
b
mapping
t
x1
program structure
i
g
h
l
k
j
m
t
b
a
x2
n
d
e
x4
x3
f
g
l
x3.1
h
m
n
j
i
k
15
Software configuration
management (SCM)

The art of coordinating software changes to
minimize confusion

SCM activities:
 Identification
 Change control
 Version control
 Configuration auditing
 Reporting
16
Baselined SCI’s
modified
Project database
SCIs
approved
Software
engineering
tasks
SCIs
Formal
technical
reviews
SCIs
stored
SCIs
SCM
controls
extracted
SCIs
17
Traceability matrix
Req No.
Description
Traces To
U2
Users shall be able to process retirement claims
S10, S11, S12
U3
Users shall be able to process survivor claims
S13
S10
The system shall accept retirement data
U2
S11
The system shall calculate the amount of retirement
U2
S12
The system shall calculate point-to-point travel time
U2
S13
The system shall calculate the amount of survivor
annuity.
U3
Entities
U2
U3
S10
U2
X
U3
X
S12
S13
X
X
S10
X
S11
X
S12
X
S13
S11
X
18
Traceability matrix
An alternate and probably more common representation.
19
Control the Change
1.
2.
3.
4.
5.
Need for change is
recognized
Change request is
submitted as a “request
for change” (RFC)
Developer evaluates
Change report is
generated
Change control
authority makes a
decision to either:


Proceed
Deny request.
6.
7.
8.
9.
10.
11.
12.
Request if queued for
action. ECO is
generated
(Engineering Change
Order).
Individuals assigned to
configuration objects.
Objects checked out
and change made.
Change audited.
Objects checked in.
Baseline established.
SQA activities
performed.
20
Rebuild & distribute.
Sample RFC form from:
http://www.nws.noaa.gov/oso/oso1/oso11/oso112/drg/drgrc.htm
21
Check-in/Check-out

Most version control tools in widespread use employ
the checkout-edit-checkin model to manage the
evolution of version-controlled files in a repository or
codebase.
http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
22
Serial development with
exclusive checkouts.



In a strictly sequential development model, when a
developer checks-out a file, the file is write-locked:
No one may checkout the file if another developer has it
checked-out. Instead, they must wait for the file to be
checked-in (which releases or removes the write-lock).
This is considered a pessimistic concurrency scheme
which forces all work to take place on a single line of
development.
http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
23
Concurrent development using
branches



Branching is a common mechanism to support concurrent
software development.
Allows development to take place along more than one
path for a particular file or directory.
When the revision on the new branch is modified and
checked-in, the two lines of development will have different
contents and will evolve separately
24
http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
Synchronizing using merges


Merging is the means by which one development line
synchronizes its contents with another development line.
The contents of the latest version on a child branch are
reconciled against the contents of the latest version on the
parent branch (preferably using a 2-way or 3-way file
differencing or comparison tool).
http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
25
Today’s Agenda
Topic
Duration

Recap
20 minutes

Capability maturity model (CMM)
60 minutes
*** Break

Current event reports
20 minutes

CMM (continued)
60 minutes
26
Software process assessment
and improvement
Software Process
is examined by
identifies
modifications to
identifies capabilities
and risk of
Software Process
Assessment
Software Process
Improvement
leads to
leads to
Capability
Determination
motivates
27
Sources of improvement
ideas

28
Software Process Improvement
Models
A number of models enable software development
organizations to compare their practices to a set of
“best practices”
IT specific models




ISO 15504
ISO 9000-3
TickIT
Capability Maturity Model Integration (CMMI)
General models


Total Quality Management (TQM)
Six Sigma
29
Capability Maturity Model
Integration (CMMI)
“the de facto process
improvement framework for
software developers”
- Gartner Group
30
What is CMMI




CMMI = Capability Maturity Model
Integration
Developed in1991 by Software Engineering
Institute (SEI) to assess the software
engineering capability of government
contractors
A framework for software process
improvement (SPI) that has gained wide
acceptance in the industry
A roadmap of effective practices that build
on one another in a logical progression


coherent
ordered set of incremental improvements
31
What is SEI

SEI = Software Engineering Institute






Federally funded research & development
center
Sponsored by Department of Defense
Affiliated with Carnegie Mellon University in
Pittsburgh
Established in 1984
Research and publications oriented
Mission is to improve the state of the
practice of software engineering
32
Brief History - CMMI
1989 1991 -
1993 1994 2001 2002 2006 -
Publication of Managing the
Software Process by Watts
Humphrey
Capability Maturity Model for
Software (CMM) v1.0 released by
Software Engineering Institute (SEI)
CMM v1.1 released
Systems engineering (SE) CMM
released
CMM Integration (CMMI)-SE/SW
v1.0 released
CMMI-SE/SW/IPPD/SS v1.1
released
CMMI-Dev v1.2 released
33
A proliferation of models

Different capability maturity models
Software CMM (SW)
 Systems Engineering CMM (SE)
 Integrated Product and Process
Development CMM (IPPD)
 Supplier Sourcing (SS)
 Software Acquisition (ACQ)
 Services (SVC)
 Team Software Process
 Personal Software Process
 People CMM (P-CMM)

34
Brief History - CMMI
1989 1991 1993 1994 2001 -
2002 2006 -
Publication of Managing the
Software Process by Watts
Humphrey
Capability Maturity Model for
Software (CMM) v1.0 released
CMM v1.1 released
Systems engineering (SE) CMM
released
CMM Integration (CMMI)-SE/SW
v1.0 released
CMMI-SE/SW/IPPD/SS v1.1
released
CMMI-Dev v1.2 released
35
Why CMMI?
Benefits
Practical
 Structured
 Proven reputation
 Quantitative benefits (median):

cost
 productivity:
 time to market:
 post-release defects:
 customer satisfaction:
 return on investment:

34%
61%
50%
48%
14%
4:1
36
CMMI Maturity Levels
Optimized
(5)
Process improvement
(“nirvana”)
Quantitatively Process measured and
Managed
controlled
(4)
Defined
(3)
Managed
(2)
Initial
(1)
Process characterized for the
organization and is proactive
Process characterized for projects and is
often reactive
Process poorly controlled and unpredictable
37
Process areas (PAs)
Maturity levels
Contain
Process areas
38
CMMI Process Areas
Process Areas
Level 5
Optimized
Level 4
Quantitatively
Managed
Level 3
Defined
Level 2
Managed
Causal Analysis & Resolution
Organizational Innovation & Deployment
Organizational Process Performance
Quantitative Project Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organization Process Focus
Organization Process Definition
Organizational Training
Integrated Project Management
Risk Management
Decision Analysis & Resolution
Requirements Management
Project Planning
Project Monitoring & Control
Supplier Agreement Management
Measurement & Analysis
Product & Process Quality Assurance
Configuration Management
39
Process areas (PAs)
Process area
categories
Maturity levels
Contain
Contain
Process areas
Achieve
Specific goals
Contain
Specific practices
40
Process areas (PAs)

Process area


Specific goals


“A cluster of related practices in an area that, when
performed collectively, satisfy a set of goals considered
important for making significant improvement in that area.”
What must be achieved to satisfy the process area
Specific practices

Refine a goal into a set of process-related activities
41
Process areas (PAs)
Process area category
Maturity level
Project
management
Level 2 - Managed
Process area
Project planning
Specific goal
Establish estimates
Specific practice
Determine estimates of effort and cost
42
Level 1: Initial




Instability
Dependence on “heroes”
Inability to meet targets
Key process areas:

none
43
Class Activity

Summarize and explain to the rest of the class:

The 22 key process areas
44
Appraisal process
CMMI
Reference model
used by
Standard
CMMI
Appraisal
Method for
Process
Improvement
(SCAMPI)
Appraisal process
45
CMMI Appraisal Method
Team
Selection
Maturity
Questionnaire
Response
Analysis
3
2
1
PA
Profile
On-site visit
Interviews &
document
reviews
4
Findings
based on the
CMMI
5
6
46
Appraisal Process

For internal purposes:



Performed in open, collaborative
environment
Focuses on improving the organization’s
software process
For external credential:



Performed in a more audit-oriented
environment
Focuses on identifying risks associated with
a contractor
Team’s recommendation will help select
contractors or set fees
47
CMMI Issues in the Real-World
“Level envy”
 Areas not addressed:

Business strategy and linkage to IT
 Operations, help desk, support
 Management of the IT human
resource
 Application portfolio
 Tools


Many question whether it is worth the
effort to pursue levels 4 and 5
48
Process Maturity Profile
1998 thru August 2002
100%
90%
% of Organizations
80%
70%
60%
43.2%
50%
40%
23.4%
30%
19.3%
20%
7.3%
6.8%
10%
0%
Initial
Repeatable
Defined
Managed
Based on assessments from 1998-2002 of 1124 organizations
Optimized
49
Process Maturity Profile,
April 2002-June 2006
50
Time to Move Up
# of months
to move to
next level
75
50
Largest observed value that
is not an outlier
28
Recommended time
between appraisals
(18-30 mos)
23
25
75th percentile
22
17
Median (50th percentile)
25th percentile
Smallest observed value that
is not an outlier
0
1 to 2
2 to 3
3 to 4
4 to 5
51
CMMI Market Pressure
Many, if not most, of the publicly-acknowledged Level 5
CMM-certified organizations are in India


Marketing tool to win clients, who are based
predominantly in US and Europe
Clients using Indian service providers should
have certain key processes in place:




service level agreements
identifying business requirements
scoping requirements
managing changes
52
CMMI-based Software Process
Improvement (SPI)

Time and cost often exceed expectations





18-24 months to advance 1 level
Can cost $2K per software engineer per year
1-2% full-time resources (e.g., 5-10 in a 500-person
organization)
2-4% of rest of organization’s time
Key success factors





Senior management is engaged
Participation and buy-in at all levels, including middle
management and technical staff
Clearly stated, well understood SPI goals
Clear assignment of responsibility
SEPG staffed by highly respected people
53
For more information

http://www.sei.cmu.edu/cmmi/cmmi.html
54
For November 14


See course home page for light reading
Current event reports:
Karas
 Modi
 Paternostro


Final exam review
55
Extra slides
56
Core Concepts
The focus of SE 425 is
the process component
of software engineering
Process
Technology
People
… for the delivery of
technology-enabled
business solutions
Process
People
Technology
57
Software Process Improvement
Models
ISO 15504



International collaborative effort (including SEI)
Sparked by an investigative study sponsored by
the U.K. Ministry of Defense (MOD)
Objective: To develop a standard in the area of
software process assessment


establish a common framework for expressing the
process capability ratings resulting from a 15504conformant assessment
provide a migration path for existing assessment
models and methods wishing to become 15504conformant
58