Software Reengineering SEII - Lecture 26

Software ReengineeringSEII-Lecture 26Dr. Muzafar KhanAssistant ProfessorDepartment of Computer ScienceCIIT, Islamabad.RecapCMMIContinuous as well as staged modelCMMI capability levelsIncomplete, performed, managed, defined, quantitatively managed, optimizedExample – process areaSpecific goals and practices, general goals and practicesOther SPI frameworksSPICE, Bootstrap, TickIT, PSP, TSPSPI return on investmentSPI trends2Unified Theory of Software Evolution [1/2]The law of continuing changeReal world computing contextThe law of increasing complexityComplexity increases if software evolvesThe law of self regulationDistribution of process and product measures close to normalThe law of conservation of organizational stabilityAverage effective global activity rate is invariant3Unified Theory of Software Evolution [2/2]The law of conservation of familiarityMaintain mastery of its content and behaviorThe law of continuing growthFunctional content must be continually increasedThe law of declining qualityQuality will be declined unless rigorously maintainedThe feedback system lawGood feedback system4ReengineeringRadical redesign of business processes and computingPositive and negative changesEfforts to improve competitiveness, downsizing, and outsourcingSystem view – business reengineering and software engineering5Business Process Reengineering“The search for, and the implementation of, radical change in business process to achieve breakthrough results.”How is the search conducted?How is the implementation achieved?How to ensure that the “radical change” lead to breakthrough results (rather than organizational chaos)?6Business ProcessesSet of logically related tasksPeople, equipment, material resources, and business proceduresExamples: designing a new product, purchasing services and supplies, hiring a new employeeEvery business process has a defined customerAcross the organizational boundariesThe business → business subsystems → business processes → business sub-processes7BPR Model [1/3]BPR is iterative and evolutionary processChanging business environmentBusiness definitionBusiness goals are definedCost reduction, time reduction, quality improvement, personal development and empowermentBusiness level or specific business componentProcess identificationCritical processes are definedProcesses ranking 8BPR Model [2/3]Process evaluationExisting processes analysisCosts are notedQuality/performance problems are isolatedProcess specification and designUse cases are preparedNew set of tasks are designedPrototypingPrototyping of the redesigned business processRefinement and instantiationFeedback from the prototype9BPR Model [3/3]10Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 766Software Reengineering Process Model [1/4]Reengineering absorbs a lot of resourcesIt is a rebuilding activityInventory analysisInventory of all applicationsBusiness criticality, longevity, current maintainabilityCandidates for reengineeringResource allocation to candidate applicationsInventory analysis on a regular basis11Software Reengineering Process Model [2/4]Document restructuringWeak documentation for legacy systemCreating documentation is too time consumingDocumentation must be updated, but your organization has limited resourcesThe system is business critical and must be fully re-documented Reverse engineeringOrigin is hardware worldOne or more design and manufacturing specificationsIn SE, it is design recovery12Software Reengineering Process Model [3/4]Code restructuringThe most common type of reengineeringCode is restructure/rewrittenReviews and testing Data restructuringFull-scale reengineering activityExisting data architecture is analyzedCauses program architecture and code-level changesForward engineeringAutomated generation of new applicationRecover the design information from existing software and use it to alter the existing system13Software Reengineering Process Model [4/4]14Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 769Reverse Engineering [1/2]There is no “magic slot”Abstraction level, documentation completeness, tools, human analysts, process direction are highly variableAbstraction level should be highCompleteness is the level of detail provided at an abstraction levelCompleteness is directly proportional to the amount of analysis performedInteractivity refers to integration of automated tools and analystsOne-way directionality15Reverse Engineering [2/2]16Figure source: Software Engineering: A Practitioner’s Approach, R. S. Pressman, 7th ed., p. 773Reverse Engineering to Understand Data [1/2]First reengineering taskDifferent levels of abstractionAt the program level, internal program data structuresAt system level, global data structuresInternal data structuresDefinition of classesGrouping related program variables17Reverse Engineering to Understand Data [2/2]Database structureDefinition of data objects and their relationshipsBuild an initial object modelDetermine candidate keysRefine the tentative classesDefine generalizationsDiscover associations18Reverse Engineering to Understand ProcessingUnderstand and extract procedural abstractionsDifferent level of abstractionsSystem, program, component, pattern, and statementOverall functionality must be understoodBlock diagram of system interactionComponent specifications (if available) are reviewed for conformance to existing codeFor large systems, automated tools may be usedOutput of this process is passed to restructuring and forward engineering tools19Reverse Engineering User InterfacesMost common reengineering activityWhat are the basic actions (e.g., keystrokes and mouse clicks) that the interface must process?What is a compact description of the behavioral response of the system to these actions?What is meant by a "replacement," or more precisely, what concept of equivalence of interfaces is relevant here?New interface may not mirror the old oneIt is good to develop new metaphor20SummaryUnified theory of software evolutionReengineeringBusiness process reengineering and software reengineeringBPR modelBusiness definition, process identification, Process evaluation, process specification and design, prototyping, refinement and instantiationSoftware reengineering process modelInventory analysis, document restructuring, reverse engineering, code restructuring, data restructuring, forward engineeringReverse engineering21