CPSC333 SENG311: Foundations Principles of SE

1
CPSC333 / SENG311 Foundations / Principles of SE

• Software Process Improvement
• (Capability Maturity Model)

2
Agenda

• Organization of software development
• Capability Maturity Model

3
Organizational software engineering reference
model
project organization n
project organization l
project goals and characteristics
project management
software system/ product
require- ments
...
quality assurance
4
Experience management
store
5
Capability maturity model

• Organization of software development
• Capability Maturity Model

6
Continuous learning

• Record weaknesses based on measurable experiences
• Organizational feedback loop Translate gained
  experiences into improved plans for future
  projects

7
Capability Maturity Model

• Watts S. Humphrey Managing the Software Process,
  Addison-Wesley, 1989 (based on his SEI work)
• Goals
• Predictable processes
• Higher product quality
• Improved organization
• Stepwise addition of SE-Technology

8
CMM Overview

• If you dont know where you are going, any road
  will do
• If you dont know where you are, a map wont
  help
• You cant improve what you do not understand

9
CMM Preface

• Individuals, Teams, and Armies
• Super Programmers and the Software Process
• Process and Technology A fool with a tool is
  still a fool

10
Software process improvement

• (1) Understand the current state of the
  development process
• (2) Develop a vision of the desired process
• (3) Establish a list of required process
  improvement actions
• (4) Produce a plan to accomplish the required
  actions
• (5) Commit the resources to execute the plan
• (6) GOTO Step 1

11
CMM - Process Maturity Level
Process Control
Process Measurement
Process Definition
Basic Management Control
12
Initial Process (Level 1)

• No formalized procedures, cost estimates, project
  plans
• Tools not uniformly applied
• Change control is lax
• Improvements
• Basic project management controls
• planning, responsibilities, commitments
• Quality assurance
• Change control

13
Repeatable Process (Level 2)

• Provides control over the establishment of plans
  and commitments
• Meet their estimations
• Problem Based on prior experience in doing
  similar work
• Risks
• new tools and methods
• new kinds of products
• new people

14
Repeatable Process Key Actions

• Establish a process group
• Focus improving the process
• full time assignments (size 1-3, more than 4
  people)
• Establish a software development process
  architecture
• describes technical and management activities for
  proper process execution
• task decomposition
• Introduce software engineering methods
  technologies

15
Defined Process (Level 3)

• Foundation for continuing progress
• In a crisis Teams still follow process
• Question How effective is the process?
• No quantitative measures yet
• Key activities
• Basic set of measurements
• Establish a process database and provide
  resources to maintain it

16
Managed Process (Level 4)

• Problem Costs of gathering data
• enormous number of potentially valuable measures
• precise definitions needed(LOC can vary by a
  factor of 100)
• Key activities
• support automatic gathering
• analyze data and modify process

17
Roles of software measurement

• Estimation
• determine likely resource requirements
• Prediction
• determine likely values of measures
• Assessment
• compare measures to predetermined values
• Comparison
• make decision on tradeoffs
• Investigation
• support or refute hypothesis

18
Software metrics

• Project
• used to predict project needs (e.g. staffing,
  total effort)
• Design
• static state of project at a particular point of
  time

19
Lines of Code (LOC)

• Counts the number of lines of code
• Problems
• what is counted?
• Comments?
• Empty lines?
• depends on language, application, developer
• code complexity not reflected
• encourages larger code volume
• does not predict quality nor progress

20
OO Application size metrics

• Lorenz, Kidd Object-oriented software metrics,
  Prentice Hall, 1994
• Number of use cases
• Number of classes
• Number of key classes
• would a customer consider this class as
  important?
• discovered early in project
• not UI, communication, exception
• Number of support classes
• indicator for volume of work
• Average number of support classes per key class
• GUI intensive 2-3 x key classes

21
Staffing size

• Average person-days per class
• all classes
• Lorenz/Kidd
• C 25-35 days/class
• Smalltalk 2-10 days/class

22
Optimizing Process (Level 5)

• Again analyze data to determine possible
  improvements
• e.g. now data is available to justify the
  application of technology to various critical
  tasks

23
Principles of software process change

• Major changes to the software process must start
  at the top
• Ultimately, everyone must be involved
• Effective change requires a goal and knowledge of
  the current process
• Periodic reinforcement needed
• Improvement requires investment

24
Were Available!

• Questions?
• if you have any questions about contents of this
  lecture or other course-related issues, please
  come by during our office hours, or send us email
• Dr. Joshua MWF, 12-1pm, ICT 548
• joshuar_at_cpsc.ucalgary.ca
• Dr. Walker WF, 1-2pm, ICT 546
• rwalker_at_cpsc.ucalgary.ca