Software Process Improvement SEII - Lecture 24

Software Process ImprovementSEII-Lecture 24Dr. Muzafar KhanAssistant ProfessorDepartment of Computer ScienceCIIT, Islamabad.RecapClass-oriented metricsWeighted methods per class, depth of the inheritance tree, number of children, coupling, response for class, lack of cohesionComponent-level design metricsCohesion, coupling, and complexityOperation-oriented metricsAverage operation size, operation complexity average number of parameters per operationDesign metrics for WebAppsMetrics for source codeMetrics for object-oriented testingMetrics for maintenance2Software Process ImprovementTriple constraintEffective software process can be defined in effective mannerAssessment of existing process based on the defined effective processMeaningful strategy to transform the processIt is not freeReduced costs after the process improvement3SPI Framework4Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 788SPI Support GroupsQuality certifiersProcess quality leads to product qualityFormalistsProcess workflow, modeling languagesTool advocatesTool-orientedPractitionersProject-level planning and metricsReformersOrganizational change, human issuesIdeologistsSuitability for particular domain or organization structure5Maturity Model [1/2]Overall indication of process maturityCapability maturity modelLevel-5, OptimizedQuantitative feedback to identify process weaknessesPro-active approach to strengthen itSoftware processes are evaluated and updated to prevent known types of defects from recurringLevel-4, ManagedDetailed process and product metricsMeaningful variations in process performance can be distinguished from noiseTrends can be predicted in process and product quality6Maturity Model [2/2]Level-3, DefinedProcesses are documented, standardized, and integrated into a standard software processAll projects follow an approved, customized version of processLevel-2, RepeatableBasic processes are established to track cost, schedule, and functionalityPlanning and managing new products is based on experienceLevel-1, InitialFew processes are definedSuccess depends on individual efforts7Four Levels of Immaturity [1/2]Level-0, NegligentFailure to allow successful development processAll problems are perceived to be technicalManagerial and quality assurance activities are considered as overheadLevel-1, ObstructiveCounterproductive processes are imposedProcesses are rigidly definedAdherence to the form is stressedStatus quo, no power delegation8Four Levels of Immaturity [2/2]Level-2, ContemptuousDisregard for good software engineeringComplete schism between software development activities and process improvement activitiesNo training programLevel-3, UnderminingTotal neglect of own charterConscious discrediting of peer organization’s process improvement effortsRewarding failure and poor performance9SPI ProcessWho need SPILarge organizations?How to initiate the processSEI proposed IDEALInitiating, Diagnosing, Establishing, Acting, and LearningAnother approachLook in the mirror, then get smarter, select the process model, instantiate the model, evaluate what has been done10Assessment and Gap AnalysisBefore starting the journey, know precisely where you areFirst road-map activity – assessmentUncover strengths and weaknessesExamine existing generic mechanisms / process activitiesIs the objective of the action clearly defined?Are work products required as input and produced as output identified and described?Are the work tasks to be performed clearly described?Are the people who must perform the action identified by role?Have metrics for the action been established?Are tools available to support the action?11Assessment and Gap AnalysisFocus on the following attributesConsistencyImportant activities, actions, and tasks appliedSophisticationLevel of sophistication for management and technical actions performedAcceptanceSoftware process and SE practice acceptance by management and technical staffCommitmentManagement commitment to provide resources to achieve above attributes12Education and TrainingGeneric concepts and methodsFocus on managers and practitionersProcess and practiceIntellectual tools to apply process effectively and to make rational decisions about improvementsSpecific technology and toolsFocus on practitionersTraining for tools used in processBusiness communication and quality-related topicsFocus on all stakeholders“soft” topicsBetter communication and quality13Selection and JustificationSuitable process modelSet of framework activities to be appliedMajor work products to be producedQuality assurance checkpoints to assess progressFocus on weaknessesConsensus is difficultBad choice can do more harm than goodOnce a choice is made, efforts should be done14Installation / MigrationSoftware process redesignFeel of changeSometimes entirely new process is recommendedSubstantial organizational and technological transition is involvedIf changes are minor, process migrationIncremental migration is more effective strategy15EvaluationEvaluation occurs throughout SPIQualitative factors Management and practitioners’ attitudesQuantitative metricsProduct related metrics16Risk Management for SPI [1/2]SPI is a risky undertakingLack of management supportCultural resistance by technical staffPoorly planned SPI strategyOverly formal approach to SPISelection of inappropriate processRisk management at three pointsPrior to the initiation of SPI road mapDuring the execution of SPI activitiesDuring the evaluation activity that follows the initiation17Risk Management for SPI [2/2]Risk categoriesBudget and costContent and deliverablesCultureMaintenance of SPI deliverablesMission and goalsOrganizational managementOrganizational stabilityProcess stakeholdersSchedule for SPI developmentsSPI development environment and processSPI project management and staff18Critical Success Factors [1/2]Management commitment and supportOrganizational and culture changesSenior business managers should recognize the importance of softwareTechnical managers should be involved in the development of local SPI strategyStaff involvementSPI cannot imposed top down or from outsideProcess integration and understandingProcess should be integrated with other business processes and requirements19Critical Success Factors [2/2]A customized SPI strategyConsider the local environmentSolid management of the SPI projectSPI is a project like any otherProject management20SummarySoftware process improvementFramework for SPISPI support groups, maturity and immaturity modelsAssessment and gap analysisEducation and trainingSelection and justificationInstallation / migrationEvaluationRisk managementCritical success factors21