Unformatted text preview:

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 BazaarDilemmaCalendarReview of Online Course Evaluation SystemMaintenance: the Final ChapterCost of MaintenanceEstimates of percentage of total life cycle cost: 40% - 90%Cost of fixing a bugRequirements 1xDesign 5xCoding 10xTesting 20xDelivery 200xProblems of MaintenanceOrganizationalAlignment with objectivesCost benefit analysisProcessImpactDocumentationRegression testingTechnicalBuilding software that is maintainableProfessional hierarchyObjectives of MaintenanceChange over time!At release: bug-freeSix months later: competitive or competition-leading featuresTwo years later: reduce maintenance costBuilding Maintainable SoftwareCodeWell documented codeNames, headers, style, …Decoupled codeDocumentationArchitecture, design documentation, use cases, requirements, …But only if maintained!!!!!Software Maintenance TypesAdaptive maintenance: changes needed as a consequence of operation system, hardware, or DBMS changesCorrective maintenance: the identification and removal of faults in the softwarePerfective maintenance: changes required as a result of user requestsPreventive maintenance: changes made to software to make it more maintainableWhy adaptation?Lehman’s Law (1985): if a program doesn’t adapt, it becomes increasingly uselessExample: programs that didn’t adapt to the web The majority of maintenance is concerned with evolution deriving from user requested changesLehman’s Second LawAs an evolving program changes, its structure tends to become more complexExtra resources must be devoted to preserving the semantic and simplifying the structureFor most software, nothing has been done about it, so changes are increasingly more expensive and difficultReengineeringCode gets messy over timeExtreme programming re-factoringAt some point, quality suffersChanges slowFixes introducing errorsNeed to invest in the code!Rules as to when to rewrite a moduleAbstractions: variables -> methodsHarder: 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 changeUnderstand the problemDesign the changesAnalyze impactImplement changesUpdate documentationRegression testReleaseCost Benefit (Risk) AnalysisWill 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?PatchesWhat is a patch?Quick fix that doesn’t go through the full processWhen should it be used?Error that is preventing use of the systemProblems with useMultiple patches can be order dependentUsers can barely track which ones have been appliedCode version explosionPermanent fix may or may not be compatibleLegacy SystemsExisting systems that are still usefulMay not want to invest in enhancementsFuture functions will use new processMay not be able to easily modifyUnsupported language or librariesLack of skillsNo source code available!Handling Legacy SystemsIncorporationBusiness as usualEncapsulationAccessed from new systemAdaptersWrapper around the legacy systemAdapters in new systemReverse EngineeringReverse EngineeringWhat 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 abstractionIs it legal?Associated with hackers and crackersFundamental ProblemUnderstanding code with …no commentsmeaningless variable namesno 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 EngineeringLots of tools for simple translationDisassemblers, decompilers, hex editors, …How useful are these?What can they do and not do?Approaches to UnderstandingSource-to-source translationObject recovery and specificationIncremental approachesComponent-based approachesWikibook on the topic http://en.wikibooks.org/wiki/Reverse_EngineeringUses of Reverse EngineeringReasonably legalmanaging clearly owned coderecovery 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

UNC-Chapel Hill COMP 523 - LECTURE NOTES

Download LECTURE NOTES
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view LECTURE NOTES and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view LECTURE NOTES 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?