3 AprilDilemmaMaintenance: the Final ChapterCost of MaintenanceProblems of MaintenanceObjectives of MaintenanceBuilding Maintainable SoftwareSoftware Maintenance TypesWhy adaptation?Lehman’s Second LawReengineeringLehman’s Five LawsSteps for handling a changeCost Benefit (Risk) AnalysisPatchesLegacy SystemsHandling Legacy SystemsReverse EngineeringSlide 19Fundamental ProblemSlide 21Uses of Reverse EngineeringDigital Millennium Copyright Act (1998)EthicsACM Code of Ethics and Professionalism (Excerpt)Intellectual Honesty (McConnell, Code Complete)Whistle BlowingEthics of a projectCathedral and BazaarOpen SourceThe Cathedral and the Bazaar Eric RaymondRaymond’s PrinciplesRaymond’s Principles (cont.)Slide 34Two Other GemsMythical Man-MonthNo Silver Bullet3 April MaintenanceReverse Engineering EthicsCathedral and BazaarDilemmaCalendarReview of Online Course Evaluation SystemMaintenance: the Final ChapterCost of MaintenanceEstimates of percentage of total life cycle cost: 40% - 90%Cost of fixing a bugRequirements 1xDesign 5xCoding 10xTesting 20xDelivery 200xProblems of MaintenanceOrganizationalAlignment with objectivesCost benefit analysisProcessImpactDocumentationRegression testingTechnicalBuilding software that is maintainableProfessional hierarchyObjectives of MaintenanceChange over time!At release: bug-freeSix months later: competitive or competition-leading featuresTwo years later: reduce maintenance costBuilding Maintainable SoftwareCodeWell documented codeNames, headers, style, …Decoupled codeDocumentationArchitecture, design documentation, use cases, requirements, …But only if maintained!!!!!Software Maintenance TypesAdaptive maintenance: changes needed as a consequence of operation system, hardware, or DBMS changesCorrective maintenance: the identification and removal of faults in the softwarePerfective maintenance: changes required as a result of user requestsPreventive maintenance: changes made to software to make it more maintainableWhy adaptation?Lehman’s Law (1985): if a program doesn’t adapt, it becomes increasingly uselessExample: programs that didn’t adapt to the web The majority of maintenance is concerned with evolution deriving from user requested changesLehman’s Second LawAs an evolving program changes, its structure tends to become more complexExtra resources must be devoted to preserving the semantic and simplifying the structureFor most software, nothing has been done about it, so changes are increasingly more expensive and difficultReengineeringCode gets messy over timeExtreme programming re-factoringAt some point, quality suffersChanges slowFixes introducing errorsNeed to invest in the code!Rules as to when to rewrite a moduleAbstractions: variables -> methodsHarder: when is REDESIGN needed?Lehman’s Five Laws1. The law of continuing change: A program that is used in a real-world environment necessarily must change or become less and less useful in that environment. 2. The law of increasing complexity: As an evolving program changes, its structure becomes more complex unless active efforts are made to avoid this phenomenon. 3. The law of large program evolution: Program evolution is a self-regulating process and measurement of system attributes such as size, time between releases, number of reported errors, etc., reveals statistically significant trends and invariances. 4. The law of organizational stability: Over the lifetime of a program, the rate of development of that program is approximately constant and independent of the resources devoted to system development. 5. The law of conservation of familiarity: Over the lifetime of a system, the incremental system change in each release is approximately constant.Lehman, M. and Belady, L. (1985). Program Evolution: Processes of Software Change, volume 27 of A.P.I.C. Studies in Data Processing. Academic Press.Steps for handling a changeUnderstand the problemDesign the changesAnalyze impactImplement changesUpdate documentationRegression testReleaseCost Benefit (Risk) AnalysisWill this problem reduce the number of programs that I sell?Will this problem impact future sales?How many people will it affect?How important are the customers it will affect?Is it a “show stopper” or an annoyance?PatchesWhat is a patch?Quick fix that doesn’t go through the full processWhen should it be used?Error that is preventing use of the systemProblems with useMultiple patches can be order dependentUsers can barely track which ones have been appliedCode version explosionPermanent fix may or may not be compatibleLegacy SystemsExisting systems that are still usefulMay not want to invest in enhancementsFuture functions will use new processMay not be able to easily modifyUnsupported language or librariesLack of skillsNo source code available!Handling Legacy SystemsIncorporationBusiness as usualEncapsulationAccessed from new systemAdaptersWrapper around the legacy systemAdapters in new systemReverse EngineeringReverse EngineeringWhat is it?Discovering the technology through analysis of a program’s structure and operation Analyzing a system to identify its components and interrelationships in order to create a higher abstractionIs it legal?Associated with hackers and crackersFundamental ProblemUnderstanding code with …no commentsmeaningless variable namesno visible structure void p (int M){int c = 2;while (c <= M){int t = 2;boolean f = true;while (t ** 2 <= c){if (c % t == 0){f = false;break;}t++;}if (f) l(c);c++;}}Reverse EngineeringLots of tools for simple translationDisassemblers, decompilers, hex editors, …How useful are these?What can they do and not do?Approaches to UnderstandingSource-to-source translationObject recovery and specificationIncremental approachesComponent-based approachesWikibook on the topic http://en.wikibooks.org/wiki/Reverse_EngineeringUses of Reverse EngineeringReasonably legalmanaging clearly owned coderecovery of data from proprietary file formats creation of hardware documentation from binary drivers (often used for producing Linux drivers) enhancing consumer electronics devices malware analysis discovery of undocumented APIs (but probably a bad
View Full Document