Software Process Improvement Cnd. - Aalborg Universitet

Software Process Improvement cnd.Peter Dologdolog [at] cs [dot] aau [dot] dkE2-201Information SystemsMarch 27, 2007

SPI as organizational changePeter Dolog, SOE, Software Process Improvement cnd.2

MotivationSoftware Engineering is a continued struggle to improve quality and fightschedule and cost overrunsPiles of literature have emerged over the last 15 years on how to improvesoftware processes (SPI)Many practical improvement efforts seem to failThe challenges of SPI seem poorly understoodAgile approaches seem to offer alternative strategies for SPI but cannot beunderstood from within the existing SPI frameworkPeter Dolog, SOE, Software Process Improvement cnd.3

A Definition of ProcessThe means by which people, procedures, methods,equipment, and tools are integrated to produce a desired endresult.BACDProcedures andmethods defining therelationship of tasksPROCESSPeople with skills,training, and motivationPeter Dolog, SOE, Software Process Improvement cnd.Tools and equipment4

A Defined Process Can:Help guide the work in an orderly wayImprove the understanding of what should be doneProvide organizations with a consistent working frameworkwhile permitting individual adjustments to particularneedsPeter Dolog, SOE, Software Process Improvement cnd.5

The Benefits of Process StandardsHelp reduce the problems of training, review, and tool support.With standard methods, each project’s experiences can contribute tooverall process improvement.Process standards provide the basis for process and quality measurements.Since process definitions take time and effort to produce, it is impractical toproduce new ones for each project.Peter Dolog, SOE, Software Process Improvement cnd.6

Organizational SystemStructureTaskTechnologyPeople (Actors)Leavitt, H. J. (1965) "Applied Organizational Change in Industry: Structural, Technological and HumanisticApproaches." In James G. March, Ed., Handbook of Organizations, 1144-1170. Chicago: Rand McNally.

SPI - Complex InteractionsCustomersProject ManagersDevelopersTop Managers

Organizational Change StrategiesLewin/ScheinKolb/FrohmanPrimary goalUnfreezingScoutingTo create aclimate forchangeEntryChangeDiagnosisPlanningActionProblem analysisDesign of alizationof solutionP. G. W. Keen: Information Systems and Organizational Change. Comm. Of ACM, 1981Peter Dolog, SOE, Software Process Improvement cnd.9

SPI processes: IDEAL Robert McFeeley: IDEAL: A User's Guide for Software Process Improvement. SEI

Software Process MeasurementProcess-related measuresProject-related measuresProduct-related and customer-related measuresZahran, S. (1998). Software Process Improvement: Practical Guidelines forBusiness Success. Reading, Mass., Addison-Wesley.Peter Dolog, SOE, Software Process Improvement cnd.11

Process-related measuresNumber of times the program failed to rebuild overnightNumber of defects introduced per developer hourNumber of changes to requirementsHours of programmer time available and spent per weekNumber of patch releases required after first product shipOverhead of each inspectionCost of first-time testingCost to fix code defectsCost to fix design defects

Project-related measuresProductivityStaff hoursDatesOverrun for schedulesProgress vs. PlanNumber of units completedNumber of units testedProblem Counts

Product/customer-related measuresCyclomatic ComplexityLines of CodeComments PercentageCyclomatic complexity MethodWeighted methods per classResponse for a classLack of cohesion of methodsCoupling between objectsDepth of inheritance treeNumber of childrenNumber of change requests

A MAP of SPI1998-2001Peter Dolog, SOE, Software Process Improvement cnd.15

MAP of Software Process ImprovementFeedbackManagement of rocessApproach to SPIPeter Dolog, SOE, Software Process Improvement cnd.CompetencePerspective in SPI16

Key elements in SPI ationManagement of SPIOrganizationDedicated and adapted effort Inadequate resources,emphasis andcoordinationPlanPlan goals, activities, responsibilities andcoordinationInability to improve.Diversity or deadlockFeedbackMeasure and assess benefitsOpportunism, andloss of relevancePeter Dolog, SOE, Software Process Improvement cnd.Pitfalls17

Key ideas in SPI onPitfallsApproach to SPIEvolutionExperimental learning andstepwise improvementWearing and inertiaNormSeek guidance in ideal processesHastiness and fundamentalismCommitmentEnsure dedication and legitimacyPolitics and goldplatingPeter Dolog, SOE, Software Process Improvement cnd.18

The general MAPConcernManagement of SPIApproach to SPIPerspective in SPIIdeaAspirationPitfallsOrganizationDedicated and adapted effortInadequate resources, emphasis andcoordinationPlanPlan goals, activities, responsibilitiesand coordinationInability to improve. Diversity ordeadlockFeedbackMeasure and assess benefitsOpportunism, and loss of relevanceEvolutionExperimental learning and stepwiseimprovementWearing and inertiaNormSeek guidance in ideal processesHastiness and fundamentalismCommitmentEnsure dedication and legitimacyPolitics and gold platingProcessIntegrate people, management andtechnologyDisinterested customersCompetenceEmpowerment through competencebuildingTurf guardingContextEstablish sustainable effortMachine bureaucracy

Diagnosis (case anization Plan Feedback—Evolutionary Norm Commitment—Process Competence Context—

No One-Size-Fits-All to SPINormative SPI concernsCorrect effortSPI Organization SPI Plan Ambitious effortGrass-root effortAdolescent effort SPI FeedbackEvolution Norm Commitment SE Process SE CompetenceSE Context

Blueprints versus recipes2002-2003Peter Dolog, SOE, Software Process Improvement cnd.22

The Blueprint approachExternalizationWhat is a software process? Where is it?SeparationWho designs the software process? How are they designed?StructurationWhen are software processes designed? Why are they designed?Peter Dolog, SOE, Software Process Improvement cnd.23

Improvement by Design threatsSeparation of knowledge from use Externalization of knowledgeGold-plating process models at the expense ofknowledge flow.Confusing information with knowledge.Lack of reflective dialogue between process users anddesigners.Reifying process knowledge.Process rollout by distributing process information.Paying little heed to the role and importance of tacitknowledge.Focusing on the past and the present and not the future. Process ossification - downplaying thinking and reasoning.Standard processes leaving little room forexperimentation.Read it on the intranet - substituting technologicalcontact for human interface.

Eleven Deadly SinsNot Developing a Working Definition of KnowledgeEmphasizing Knowledge Stock to the Detriment of Knowledge FlowViewing Knowledge as Existing Predominantly Outside the Heads of IndividualsNot Understanding that a Fundamental Intermediate Purpose of Managing Knowledge Is to Create Shared ContextPaying Little Heed to the Role and Importance of Tacit KnowledgeDisentangling Knowledge from Its UsesDownplaying Thinking and ReasoningFocusing on the Past and the Present and Not the FutureFailing to Recognize the Importance of ExperimentationSubstituting Technological Contact for Human InterfaceSeeking to Develop Direct Measures of KnowledgeFahey, L., and Prusak, L. (1998) The eleven deadliest sins of knowledgemanagement. California Management Review, 40, 3, 265-276.Peter Dolog, SOE, Software Process Improvement cnd.25

Design: Verb or noun?Software process design asarchitectureSoftware process design asimprovisationA software process is a blueprint.A software process is a recipe.A software process is constructed at a single point A software process is continually reconstructed.in time.Software processes produce order throughintention.Software processes produce order throughattention.A software process creates planned change.A software process codifies unplanned changeafter the fact.Inspired by: Weick, K. E. (1993) "Organizational redesign as improvisation." In G.P. Huber and W.H. Glick,Eds., Organizational Change and Redesign, 346-379. New York: Oxford University Press.

Recipes - the conceptAs an alternative to Blueprints, we can conceive of softwaredevelopment being supported by recipes—guidelinesthat we can tailor to specific and shifting conditions.Using a recipe, process users collectively design the softwareprocesses through facilitation, reflection, andimprovisation.Peter Dolog, SOE, Software Process Improvement cnd.27

Externalization - FacilitationProcess informationMethods, procedures, experiences, patternsToolsEnhance capabilities of individuals and teamsOrganization & competenceFacilitate sharing of knowledge (pair programming, collectivecode ownership, mentoring, .)Peter Dolog, SOE, Software Process Improvement cnd.28

Separation - ReflectionEngagementSee activity as a context for learning - use reviews, tracking and projectpost-mortemsImaginationCreate shared visions - use project kickoff meetingsAlignmentCoordinate energies and activities - use standards, policies, and valuesPeter Dolog, SOE, Software Process Improvement cnd.29

Structuration - ImprovisationFocus on interactionsSee everyday projects as experimentsEnsure the ability and latitude to improvise under commonstandardsEmpower teams to manage the unexpectedEncourage creativity through interactionPeter Dolog, SOE, Software Process Improvement cnd.30

Peter Dolog, SOE, Software Process Improvement cnd. 3 Motivation Software Engineering is a continued struggl