CPSC4175 Intro to Software Engineering Neal Rogers Process Foundations.
-
Upload
maria-cunningham -
Category
Documents
-
view
223 -
download
2
Transcript of CPSC4175 Intro to Software Engineering Neal Rogers Process Foundations.
CPSC4175Intro to Software Engineering
Neal Rogers
Process Foundations
• Lesson: Process Raison d’être• Strategic Objective: understand the rationale of
using processes• Tactical Objectives:
– know the work of the contemporary quality movement– Know how manufacturing processes have been applied
to software– Know the contemporary and classical schools of SwE– Understand the purpose and benefits of processes– Be able to identify “ingredients” of a process – Know the common processes currently in use– Understand the difference between a process model and
a model process– Understand the Capability Maturity Model (Integrated) for
Software; know the model’s key processes
• Support material:– Text 2, 3– Readings 2, 3, and 4– References 1, 2, 3, 8, and 9
• Immediate-use skills provided– interview buzzwords
• References:– CMMI Product Team 2002. Capability Maturity Model Integration
(CMMISM), Version 1.1. CMU/SEI-02-TR-01, 02-TR-28, 02-TR-29. Software Engineering Institute.
– IEEE. 1997. IEEE Standard for Developing Software Life Cycle Processes. IEEE Std 1074-1997.
– Paulk, M. et al. 1993. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24. Software Engineering Institute.
– Schmauch, C. 1995. ISO 9000 for Software Developers. Revised edition. ASQC Quality Press.
– Schulmeyer, G. G. 1987. Software quality lessons from the quality experts. From Handbook of Software Quality Assurance. Van Nostrand Reinhold. pp. 25-45.
• Software engineering raison d’être • Process foundations • Common process elements • Conceptual design • Size estimation• Task decomposition• Scheduling• Measurements• Reviews• Technical templates• Scaling up• Misc processes• Process descriptions• Infrastructure• Retrospective
Syllabus
Process foundations Industrial quality movement Software quality movement
Processes a la SwE Classical school Contemporary school
Processes explored further Processes rationale Function of processes Process model
Process Models Introduction Sample models
Discussion point …
How do we ensure the quality* of software?
*quality = software meeting customer needs, known software characteristics (e.g., defects, performance, content)
Follow-up point …
What stands in the way of your achieving “quality” the first time, every
time?
Contemporary Quality Movement• Kaoru Ishikawa
– company-wide quality control– top management buy-in– industrial education and training– application of statistical methods
• Joseph Juran– structured approach to manufacturing:
• study the symptoms of the defects and failures• develop a theory on the causes of these symptoms
– specifically, examine worker-controllable vs management-controllable aspects
• test the theory until the causes are known• stimulate remedial action
Contemporary Quality Movement• W. Edwards Deming
– statistical control– common method of attacking and describing problems
• P-D-C-A approach– plan– do– check– analyze
A C
P D
Contemporary Quality Movement• W. Edwards Deming (con’t)
– 13 pts• create constancy of purpose for improvement• adopt the new philosophy• cease dependence on mass inspection• end the practice of awarding business on price tag alone• improve constantly the system of production and service• institute training and retraining• institute leadership• drive out fear• break down barriers between staff areas• eliminate slogans, exhortations, and targets• remove barriers to pride of workmanship• institute a vigorous program of education and retraining• take action to accomplish transformation
Contemporary Quality Movement• Philip Crosby
– guiding principles:• “quality is conformance to requirements”• “quality is free, but only to those who are willing to pay heavily
for it.”
– Quality management maturity grid• 5 levels of maturity: uncertainty, awakening, enlightenment,
wisdom, certainty• 6 measurement categories
– management understanding– quality organization status– problem handling– cost of quality as % of sales– quality improvement actions– summation of company quality posture
Stage I: Uncertainty• Management understanding and attitude
– No comprehension of quality as a management tools. Tend to blame quality dept for “quality problems”
• Quality organization status– Quality is hidden in manufacturing or engineering departments.
Inspection probably not part of organization.
• Problem handling– Problems are fought as they occur; no resolution; inadequate
definition; lots of yelling and accusations.
• Cost of quality as % of sales– Reported: unknown– Actual: 20%
• Quality improvement actions– No organized activities. No understanding of such activities
• Summation of company quality posture– “We don’t know why we have problems with quality.”
Stage II: Awakening• Management understanding and attitude
– Recognizing that quality mgmt may be of value but not willing to provide money or time to make it happen
• Quality organization status– A stronger quality leader is appointed but main emphasis is still
on appraisal and moving the product. Still part of manufacturing or other
• Problem handling– Teams are set up to attack major problems. Long-range
solutions are not solicited.• Cost of quality as % of sales
– Reported: 3%– Actual: 18%
• Quality improvement actions– Trying obvious “motivational” short-range efforts
• Summation of company quality posture– “Is it absolutely necessary to always have problems with
quality?””
Stage III: Enlightenment• Management understanding and attitude
– While going thru quality improvement program learn more about quality management
• Quality organization status– Quality dept reports to top management
• Problem handling– Corrective action communication established. Problems are
faced openly and resolved in an orderly way.• Cost of quality as % of sales
– Reported: 8%– Actual: 12%
• Quality improvement actions– Implementation of a specified quality program with thorough
understanding of each step• Summation of company quality posture
– “Through management commitment and quality improvement we are identifying and resolving our problems.”
Stage IV: Wisdom• Management understanding and attitude
– Participating. Recognize their personal role in continuing emphasis
• Quality organization status– Quality manager is officer of company
• Problem handling– Problems identified early in their development. All functions open
to suggestion and improvement
• Cost of quality as % of sales– Reported: 6.5%– Actual: 8%
• Quality improvement actions– Continuing specific quality program
• Summation of company quality posture– “Defect prevention is a routine part of our operation.”
Stage V: Certainty• Management understanding and attitude
– Consider quality management an essential part of company system
• Quality organization status– Quality manager on board of directors. Prevention is main
concern. Quality is a thought leader.
• Problem handling– Except in the most unusual cases, problems are prevented.
• Cost of quality as % of sales– Reported: 2.5%– Actual: 2.5%
• Quality improvement actions– Quality improvement is a normal and continued activity
• Summation of company quality posture– “We know why we do not have problems with quality.”
Quality Movement wrt Software• Lennart Sandholm
– quality policy• statement of corporate-wide commitment to quality• promulgated by senior software executive
– quality objectives• statements of measurable improvements• e.g., number of errors per thousand LOC
– quality system• used to achieve the quality objectives• e.g., standards, procedures, etc.
– quality assurance organization• facilitating body• may process and/or product oriented
Premise that has evolved:• The quality of a product is largely determined
by the quality of the process that is used to develop and maintain it.
Ghost of SwE Past• Classical software development philosophy
– tenets:• software engineering = building software = technical activity• grab-bag of disjoint technical actions• software projects can be orchestrated no differently than
other projects in other fields
TOOLS
Identify Synthesize Articulate Interpret
People
Technical
Organize Staff DirectPlan Control
Product+ =
Ghost of SwE Present (sorta)• Contemporary software development philosophy
– tenets• software engineering = technical facets + managerial facets
orchestrated by process• focus on process activities
– teach the troops correct principles and they will govern themselves
– Humphrey [1995]:» “The quality of software is governed by the quality of
its worst components.”» “The quality of a software component is governed by
the individuals who developed it.”– teams with comprehensive processes are more likely to
contain cost and ensure quality than those without– processes can exist on a project-by-project basis, but are
leveraged best on an organization-wide basis
SwE now (sorta)• Contemporary software development philosophy
(con’t)– hence
TOOLS
Product with known “quality”
+ =
Identify Synthesize Articulate Interpret
Process
People
Technical
Organize Staff DirectPlan Control
Product Property SuccessLifecycle Infra
Processes Explored Further• Process
– ... is the set of all enterprise tasks needed to produce software
– ... “sets out the technical and management framework for applying methods, tools, and people.”
[Humphrey 1995]– our goal: use process measurements and controls to
guide production
PROJECTP
roce
ss 1
Pro
cess
n
Pro
cess
2
Pro
cess
3
Pro
cess
4
Consider: Example: % of requirements allocated to software: *
• B-2 -- 65%
• F-22 -- 80%
Process Rationale• Processes help ...
[Humphrey1995]
– ... identify the principal activities of doing a job– ... separate routine from complex tasks– ... establish starting and stopping criteria– ... facilitate tracking progress and measuring
performance– ... judge accuracy of work projections– ... provide orderly mechanism for learning– ... establish corporate memory of necessary activities– ... create a defined baseline for improvement
Example Process• PSP0 process script
• Problem description• Defect standard type
• Produce a requirements statement• Estimate and record the required development time• Record time spent planning
• Design the program• Implement the design• Compile program; fix and log all defects found• Test the program and fix and log all defects found.• Record time spent in development
• Calculate and record performance statistics
• Tested program• Completed plan, defect log, time log
Entry
Planning
Development
Postmortem
Exit
Tasks
Processes Explored Further• Function of processes: engineering insight
IN OUT
IN OUT
INOUT
INOUT
INOUT
[Paulk et al 1993a]
incr
easi
ng s
ophi
stic
atio
n
Processes Explored Further• Function of processes: enhance predictability
planned delivery
Well-defined processes
Ad hoc processes
[Paulk et al 1993a]time
prob
abili
ty
.
0 %
140%
-140%
....
.
..
. .. .
.
. . .. . .
.
.
..
..
. ...
..
. . .. ..
Without Historical Data With Historical DataVariance between + 20% to - 145% Variance between - 20% to + 20%
(Mostly Level 1 & 2) (Level 3)
Ove
r/U
nd
er P
erce
nta
ge
.
(Based on 120 projects in Boeing Information Systems)
.. . .
.
.. .
...
. .
. ..
.. .
..
...
. . .. . .. . . . .
. . . . .. . . . . .. . . . .. . . . . .
. . . . . . . .
. . . .. . . . . . .. . . .. .. . . . . ... .. .. .. ...... . .. . ... . ... .. .. . . . . .. . . . . .. . . . . .. . . .. . . . . . . . . . .. . . . .. . .. . . . . . . . .
. . . . . .. . . . . .
Reference: John D. Vu. “Software Process Improvement Journey:From Level 1 to Level 5.” 7th SEPG Conference, San Jose, March 1997.
Empirical evidence
Before After
Historical Perspective
X* Engineeringguarantors of
quality
* where X = civil, mechanical, electrical, etc.
codes
physical laws
mathematical analysis
Traditional engineering focuses on the product; software engineering focuses on the process of building the product
Software Engineeringguarantors of
quality
process (i.e., the way in which we build the software)
certification (i.e., rigorous examination of end product)
Historical Perspective
No process Process
?
Process Darwinism
Heavy-weight processes
Light-weight processes
IEEE 1074, CMM, ISO 9001 XP, Scrum, ASD, FDD
requirements containment vsrequirements adaptation
design-oriented vsconstruction-oriented
predictive vsadaptive
Common Processes• Pre-defined processes (a.k.a. model processes)
– MIL-STD 2167A– MIL-STD-498 -> IEEE 12207.0– IEEE 1074– XP– NASA xxx, Boeing xxx, etc., etc.
• Process model– “a structured collection of elements that describe
characteristics of effective processes” - SEI
– Examples• ISO 9001• CMMI (Capability Maturity Model – Integrated)• SPICE (Software Process Improvement and Capability
dEtermination … ISO/IEC TR 15504)
Common Process Model Ingredients• life cycle model
– sequence of technical tasks required to produce a product (e.g., analysis, design, code, test, etc.)
• product model– tasks needed to produce an artifact in a specific form
• property model– tasks needed to attain desired cost, schedule,
security, reuse, etc.
• success model– tasks needed to assure and assess correctness
• infrastructure model– administrative tasks needed to ensure day-to-day
activities are carried out
Samples• MIL-STD-2167A
– Planning, management, engineering procedures, standards, quality, configuration management
interface design
preliminary design
detailed design
req analysis
design code test
Samples• MIL-STD-2167A (con’t)
Preliminary design process
• develop prelim design
• develop interface design
• document rationale
• establish test requirements
• allocate/document FQT
• evaluate design docs
• baseline design docs
• conduct PDR
Samples• IEEE Std 1074-1997
– … “provides a set of Activities that constitute the Processes that are mandatory for the development and maintenance of software”
[IEEE 1997]– Processes:
• Software life cycle model processSoftware life cycle model
• Project management processesproject initiationproject monitoring and controlsoftware quality management
• Pre-development processesconcept explorationsystem allocation
• Development processesrequirementsdesignimplementation
• Post-development processesinstallationoperation and supportmaintenanceretirement
• Integral processesverification and validationsoftware configuration managementdocumentation developmenttraining
Samples• Extreme Programming (XP)
Customer
Customer
DeveloperDeveloper
Define values
Estim
ate
cost
Choose
value
Build va
lue
user stories
estimation via risk,
priority
spike solution
test first, sds, CM
Samples• ISO 9000 [Schmauch 1995]
– … defines minimum process requirements that must be met to ensure quality
– … is a framework: states what, not how– written originally for manufacturing, but also applied to
software
Samples• ISO 9000 (con’t)
– collection of individual, but related standards
• 9000-1 Guidelines for selection and use
• 9000-3 Guidelines for application of 9001 to software
• 9001 Model for quality assurance in design, development, production, installation,
servicing
• 9002 Model for QA in production, installation, servicing
• 9003 Model for QA in final inspection and test
• 9004 Guidelines for interpretation of 9001, 9002, 9003
Req Code Test Install MaintDesign
9001
90029003
Samples• ISO 9000 (con’t)
– 9001 Processes (interpreted through 9000-3)• Framework
management responsibilityquality systeminternal quality system auditscorrective action
• Life cycle activitiescontract reviewpurchaser’s requirements specdevelopment planningquality planningdesign and implementationtesting and validationacceptancereplication, delivery, and installationmaintenance
• Supporting activitiesconfig managementdocument controlquality recordsmeasurementrules, practices, and
conventionstools and techniquespurchasingincluded software
product training
Samples• Capability Maturity Model (Integrated)
– Basics• … gauges organizations’ ability to predict and control software
activities• identifies processes necessary for software production• provides a framework for measuring production
capability
– Views• continuous
– Q: how well am I performing software functions?• staged
– Q: how well can I control cost, schedule, performance?
– Misc• is called “integrated” because it is integrated with other CMMs
Requirements ManagementRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidation
Engineering
ProjectManagement
Project PlanningProject Monitoring and ControlSupplier Agreement ManagementIntegrated Project ManagementIntegrated Supplier Management Integrated Teaming Risk ManagementQuantitative Project Management
Organizational Process FocusOrganizational Process DefinitionOrganizational TrainingOrganizational Process PerformanceOrganizational Innovation and Deployment
ProcessManagement
Configuration ManagementProcess and Product Quality AssuranceMeasurement and AnalysisCausal Analysis and ResolutionDecision Analysis and ResolutionOrganizational Environment for Integration
Support
Category Process Area
CMMI – Process Areas
Samples• CMMI (con’t)
– continuous representation
pro
cess
are
a 1
pro
cess
are
a 2
pro
cess
are
a 3
pro
cess
are
a 4
pro
cess
are
a n
…
0
12
3
4
5
cap
abil
ity
process areas
CMMI process areas – staged
Organizational Innovation and DeploymentCausal Analysis and Resolution5 Optimizing
4 Quantitatively Managed
3 Defined
2 Managed
Continuous process improvement
Quantitativemanagement
Processstandardization
Basicprojectmanagement
Organizational Process PerformanceQuantitative Project Management
Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process DefinitionOrganizational Training Integrated Project ManagementIntegrated Supplier ManagementRisk ManagementDecision Analysis and ResolutionOrganizational Environment for IntegrationIntegrated Teaming
Requirements Management Project PlanningProject Monitoring and ControlSupplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality AssuranceConfiguration Management
1 Performed
Process AreasLevel Focus
Samples• CMMI (con’t)
– staged representation
Focus on process improvement
4 Quantitatively Managed
3 Defined
2 Managed
1 Performed
0 Not Performed
5 Optimized
Process matured and controlled
Process at org level
Process at project level
Process ad hoc
No process
incr
easin
g pr
edict
abilit
y;
decr
easin
g m
anag
emen
t risk
Empirical Data
Samples• PSP
– instantiation of CMMI for small organizations– includes:
• measurement and analyses framework to help characterize processes
• defined procedure to help improve performance
– CPSC4175 approach• introduce PSP in several upwardly compatible steps• write small programs at each step• gather and analyze data on work• use data and analyses to gain insight into process
management• scale up to multiple person efforts (CPSC4176)
Samples• PSP (con’t)
PSP0Current processTime recording
Defect recordingDefect type standard
PSP1Size estimating
Test report
PSP2Code reviews
Design reviews
PSP3Cyclic development
PSP1.1Task planning
Schedule planning
PSP0.1Coding standard
Size measurement
TSPTeam coordination
Summary Key Points• The manufacturing community
discovered processes long ago• SwE then = technical activities
SwE now = process orientation• A process is a set of enterprise
tasks• Processes have benefits: most
notable is management containment
• Process models describe what to do; model processes describe how to do it. Many exist
Topics• Process foundations• Processes a la SwE• Processes explored• Process Models
Next time: Common process elements