Class Note for EECS 448 with Professor Niehaus at KU 2
Class Note for EECS 448 with Professor Niehaus at KU 2
Popular in Course
Popular in Department
This 11 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at Kansas taught by a professor in Fall. Since its upload, it has received 18 views.
Reviews for Class Note for EECS 448 with Professor Niehaus at KU 2
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 02/06/15
PostDelivery Maintenance Chapter 15 EECS 448 Dr Douglas Niehaus EECS 448 1 Dr Douglas Niehaus 2009 Development vs Maintenance Why Maintenance is Necessary Three reasons for making a change to a product Corrective Maintenance changes required to correct a discovered fault Analysis design coding documentation fault Perfective Maintenance changes to improve a product s effectiveness New features Adaptive Maintenance changes accommodating a change in the environment New compiler OS or hardware Percentages of time from a study of 69 organizations Corrective 175 Perfective 605 Adaptive 18 Other 4 EECS 448 3 Dr Douglas Niehaus 2009 PostDelivery Programmer Requirements Most of the same activities FiX faults corrective maintenance Extend product capabilities enhancement Some computer scientists prefer the term evolution Viewing the entire software lifecycle as an evolutionary process Maintainability should be built into the product from the very beginning of the development process Different context postdelivery maintenance be ins after a client accepts the first version of the pro uct Maintenance is generally cheaper than re implementation Though it can be harder in some ways and less fun in most ways EECS 448 2 Dr Douglas Niehaus 2009 Even though on average 67 23 of the total cost of a product can be attributed to postdelivery maintenance Many organizations assign this to beginners and less competent programmers Those with less influence over their work aSSIgnments New development is generally more satisfying so everyone gravitates to it if they can Contradiction Postdelivery maintenance is the most difficult but is assigned to the lest able Counterpoint postdelivery maintenance is easiest on best designed products EECS 448 4 Dr Douglas Niehaus 2009 PostDelivery Programmer Requirements PostDelivery Programmer Requirements Postdelivery maintenance PDM incorporates all So PDM is potentially quite educational aspects of other phases lf approached correctly Thus properly managed it is an excellent training f supervised we grounId for 39Inexper39enc programmer Provide inexperienced programmers with a IIIDetIangging skills are requrred to determine where a mentor auties However PDM is often still a thankless job Dealing with dissatisfied customers You do not meet them unless they are unhappy Mandatory tour of product to learn its structure well enough to isolate fault Sometimes requires considerable debugging skills I I I I I in some way FiXing a fault Without introducmg others Fixing their probiem Cheers them UpI thought Requires considerable study and understanding of problems caused usuaiiy by originai existing product software architecture deveioperI not the maintainer Excellent training it product is well written EECS 44B 5 Dr Douglas Niehaus 2009 EECS 44B 7 Dr Douglas Niehaus 2009 PostDelivery Programmer Requirements PostDelivery Programmer Requirements Updates to incomplete incorrect or outofdate Further perils documentation also an excellent learning experience Code may be badiy written 39 TeSt39ngI I Many developers consider it a lowerstatus job SpeCIfic test cases for corrected fault or extended Being tOO good at it may get you stuck prOdUCt feature Managers want a quiet life and programmers Regression tests to check for regression faults efficient at fixing ierebiems a maior asset 39 QISO Excelleg ucat39ond39n prOdUiiCt PDM most challenging aspect of lifecycle and eve opmen i ey are oneIwe I I I management can heip 39 Dioggrpientat39on Of 3 Changes and 39mpl39cat39ons 395 apn Restrict PDM to programmers with required skills 0 Adaptive and perfective maintenance 39 orlgmal develOpers can x the bUgs Give PDM higher status and pay Programmer must perform requirements analysis U d design implementation and testing workflows 39 pgi is39t as a tra39n39ng groun maSter39apprentlce EECS 44B 6 Dr Douglas Niehaus 2009 EECS 44B 8 Dr Douglas Niehaus 2009 Managmenet of PDM Defect Report Data Base Each defect report should be tracked individually Filed by user with enough information to reproduce it Often a really hard problem Assigned to PDM developer Progress tracked ldeally defects should be fixed immediately PDM chronically understaffed Often a cost and not a revenue Often LowerROI even if explicitly paidfor Response time tied to defect criticality EECS 44B 9 Dr Douglas Niehaus 2009 Managmenet of PDM lf previously reported user can be given known information about fault If new defect maintenance programmer must study the problem and form a theory about how to fix it Perhaps ways to live with or workaround the defect are possible until it is fixed Programmers ideas and conclusions should be added to the set of information associated with the tracking data base defect record Management of PDM should consult set of open defect records regularly Rank criticality Monitor progress EECS 44B 10 Dr Douglas Niehaus 2009 Managmenet of PDM Defect data base should be open to users Users may not see all elements but Some information on open defects is reasonable for all users Can make the PDM organization look bad if some defects remain open for long periods Defects are often not fixed immediately for good reasons however Almost always cheaper to fixed a set of related defects all at once and perform related sets of testing and documentation rather than doing each separately Particularly true if new version of software must be EECS 44B installed on many machines 11 Dr Douglas Niehaus 2009 Authorizing Changes to a Product Once the corrective maintenance is approved a maintenance programmer is assigned to the task of determining the fault that has caused the failure and repairing it Code is changed and tested Regression testing of the product as a whole Documentation updated SOA testing before modified product distributed PDM is also fault prone Conducting complete testing is hard EECS 44B Importance of developing solid regression test suite along with the product 12 Dr Douglas Niehaus 2009 Authorizing Changes to a Product Ensuring Maintainability PDM is a significant cost and testing is a significant During PDM the maintainability of product lean 0f PDM expense Ideally should improve It is estimated that the first fix of a PDM fault is optimisticaiiy shouid get no worse itself incorrect 70 of the time Care in conducting PDM and care in oversight is thus important Causal and inadequately tested fixes often cause more problems than the original fault Probability of cascading problems greatly increases if the regression test suite Realistically entropy always wins Major rewrites and revisions are often a result of longterm PDM entropy Fixing individual faults always involves a restricted view of the product Leading to greater entropy of changes Even if a broad view is taken in fixing each fault 39 Does nOt eXlSt changing conditions often mean that some PDM ls not automated work pushes the existing design beyond its limits Ensuring Maintainability Problem of Repeated Maintenance PDM is not a one time effort Moving target problem is one of the biggest Successful products go through many versions difficulties 0f PDM over its lifetime Client Changes reqUIrements Some are PDM Frustratinglfor developers H Can result In poorly structured code 39 some are new developm9nt I Can add to the cost of product Planning for orderly andleffICIent PDM during All these issues only get worse during PDM entire software process is crUCIal The more a completed product changes I Well designed software architecture explicitly 39 The more It deVlateS from Its Ollglnal des39Qn supports extension and modification Documentation becomes less reliable Moving target has a management component Oble orlentafllon helps Wlth mlormatlon hldlng Firm control of client expectations and need to 39 l39llgh COheSIOn and lOW coupling freeze requirements for PDM Variable names comments documentation all 39 Some PDM ShOUld be development of new contribute product version EECS 44B 14 Dr Douglas Niehaus 2009 EECS 44B 16 Dr Douglas Niehaus 2009 ObjectOriented Software Maintenance ObjectOriented Software Maintenance OO paradigm promotes maintainability Consequences of inheritance Well designed objects exhibit high level of Changes are propagated to all descendants conceptual independence Fragile class problemquot is descriptive phrase 39 EncapSUIation high COheSion IOW coupling Inheritance increases scope of the analysis 39 Generally easy to see WhiCh perils Of a IDFOdUC E Inappropriate uses of inheritance tend to make reqUIFQ Changes this much worse 39 GOOd locality usually Inheritance is often an advantage during initial Information hiding increases object independence development but a disadvantage during PDM Reduces undesirable and unnecessary interaction Clarity Clarity Clarity Changes to one object rarely affect another object Simplicity Simplicity Simplicity EECS 44B 17 Dr Douglas Niehaus 2009 EECS 44B 19 Dr Douglas Niehaus 2009 ObjectOriented Software Maintenance PDM vs Development Skills Obstacles to 00 SW maintenance Many basic skills of reasoning and coding are of PDM programmer must study entire class hierarchy course common to both BUT Wnicn was Often deSigned by Others Remarkably important set of differences To understand context of a class reqUIring modification Ability to diagnose the cause of a problem GIood CASE tool support for browsing Class Starting point and among the most important PDm hierarchies is a big help skills Some tools can provide a flattened view of a Ability to read code to learn about it especially when class With all inherited features appearing eXpIICItIy inadequateI incompieteI or outofdate 39 PCBmorphism and dynamic binding documentation is available Programmer must consider a wider range of more COmioiex IDOSSibie behaviors and implications Learning from and about code written by someone Simioie is aimost aiWays better else is much harder in some ways than working on Clever should always have a good reason cede you WIrOte I I I I Strong analysis design implementation and testing EECS 448 18 Dr Douglas Niehaus 2009 EECS 44B 20 Dr Douglas Niehaus 2009 PDM vs Development Skills Reverse Engineering Hypothesis formulation and testing Major skill in Systems Programming Constant feature of learning about a large code 39 LinUX Kernel base completely separate from diagnosing and Compuers fixing a specific fault Sewers 39 PDM deSlgn Challenge CASE tools for process Createlmodifications that achieve a given purpose Pretty printers and formatting editors display code while Violating no assumptions of other modules in cearer and standardized ways Clearly requires a detailed understanding of Tools for displaying code structure and data overall software architecture dependence PDM developers must no only be skilled in a broad 39 Compiler plugins range of areas but must be highly skilled In them Lint looks for structural problems and39CoverOty Obviously contradictory to who is assigned PDM and Other analyZIng compilers nellc Wlln tasks most often concurrence Reverse Engineering Reverse Engineering Phrase reverse engineeringquot refers to starting with a Terminology product and recreating design and perhaps Forward engineering usual development process specifications documents that proceeds from analysis through design to Write accurate and complete documents starting 39mplementatlon and teSt39ng only with source code Reengineering reverse engineering followed by Clarity Of COde and deSign commentS Segtibiticigg39eitinrygving the product without Happens frequently during PDM Changing its function Possibly for specific modules rather than whole pretty printing code prOdUCt Refactoring of software architecture is term Far more common for legacy systems used in extreme programming Still in use even though code was written 1520 Two approaches are possible once as products years ago design has been reconstructed by reverse engineering EECS 44B 22 Dr Douglas Niehaus 2009 EECS 44B 24 Dr Douglas Niehaus 2009 Reverse Engineering Reverse Engineering Option 1 Option 1 39 Attempt to reCODStrUCt the Spelcmcaltlons Use disassembler machine codegt assembler Modify the reconstructed speCIfIcatIons Use reverse compiler assembler gt C ReImplement the product In normal forward P bl engineering manner r0 ems BUT BUT BUT Variable names are all lost Reconstruction of specifications is hard Compiler optimization makes deducing I When successful often crucially depends on structure harder and makes understanding extensive experience deduced structure harder Option 2 Loops in assembler have more than one Modify reconstructed design and forward engineer pOSSIble source code progenitor mom Tere H d b t It I If t Option 2 treat existing product as a black box 39 Ore requen y use U I eaves speC39 39Ca 390 One possible use forvirtualization is to provide documents OUt39Of39date specific environment for such products EECS 44B 25 Dr Douglas Niehaus 2009 EECS 44B 27 Dr Douglas Niehaus 2009 Reverse Engineering Reverse Engineering Situation is vastly more difficult if source code is lost Option 3 and the executable version is all that is available Reverse engineering is used to deduce snoud never happen yet does more often specifications from black box behavior than YOU might think Reconstructed specifications are updated to reflect Essentially impossible of source code control tools current enVIronment are used Newversion of product is built from updated Some version of code is always available SpeCIflcatlons Almost as bad however is that the executable 39 Best approaCh being used is not built by the corresponding Make sure it never happens source code All options are painful but there are 3 approaches that can be used EECS 44B 26 Dr Douglas Niehaus 2009 EECS 44B 28 Dr Douglas Niehaus 2009 Case Study SourceExec Mismatch Case Study SourceExec Mismatch 1985 Convergent Technologies is building the first Fourth set of problems deSktOP UNIX bOX for ATampT Executables built from source still don t match UnixPC or 381 testing executables after compare tool ignoring Deliver first product version of entire UNIX release ltlme39StampS 395 bUllt OS compilers DB Editors applications etc 39 Fifth set 0f PrOb39emS 50 514quot oppies How can I possibly tell my boss this incredibly brad Deliver source code and a machine the size of top news W39thOUt be39Wg ShOt or Othelw39se damged Opening freezer to build it N ecirrgore evrd rjfc offwhtat Is happetrrfling and Machine provided the specific version of UNIX W y U canno e ay or 00 ong 939 er software necessary to build release 39 S39Xth set 0f prOb39erlnsl I l was given the task to build the release from source 39 COde and 00mp39lat390n analys39s for N 24 hours Not easy gofund multiple copies of 45 header files that were i erent EECS 44B 29 Dr Douglas Niehaus 2009 EECS 44B 31 Dr Douglas Niehaus 2009 Case Study SourceExec Mismatch Case Study SourceExec Mismatch First set of problems Sixth set of problems Environmental variables and structure of source Telling my bosses code was not all set up correctly Told my boss at 9AM Not too frightening Second set of problems Not all makefiles called each other well and some Explained evidence and writeup until 945 Issue when up 4 levels of management above me makefile variables had to be defined 39 2 PM 39 When can YOU leaVe for califomiaquot More serious Seventh set of problems Third set of problems Proving to Convergent there was a problem Executables built did not match executables being Denial vs 250 Million dollar check teSted Seventh set of problems 39 A failed at 4398th We exeCUtable timestamp Designing a reliable source code control and 39 Create a too39 to f39X quot5 software manufacturing method EECS 44B 30 Dr Douglas Niehaus 2009 EECS 44B 32 Dr Douglas Niehaus 2009 Case Study SourceExec Mismatch Testing During PDM Eighth set of problems Test cases and outputs Convert entire UNIX release source to new Machine readable form methOd by myself Automatically executable preferably 39 Prove if bUi39d exaCt39y the same set 0f exeCUtab39es Automatically comparable to current output best as original source B bt PDM changes often require expansion of test suite 39 I or I as well as modification of existing tests or results Minus timestamps I Regression testing absolutely crucial aspect of PDM Ninth set of problems Convincecoerce Convergent developers to use new system How it worked discussed in case study segment in tools discussions EECS 44B 33 Dr Douglas Niehaus 2009 EECS 44B 35 Dr Douglas Niehaus 2009 Testing During PDM CASE Tools for PDM Unusual for PDM team to have been involved with PDM workers cannot keep track of version numbers original development for everything manually PDM iower status Tools support obviously required Personnei turnover in SW industry is nigh Source file version control for source code as well Maintainer generally not already aware of how 3le tests and even documents Is commonly changes to one arti act will affect another C T I Major object of study 39 ommon 008 Time generally too restricted to complete such 39 SCCS or39gmal umx tOOI 1980 study of interactions RCS gt CVS gt SVN Open source versions Documentation often iaoking Git BZR Hg etc are many other tools especially Comments those supporting distributed development without requiring connections to central servers Full record of all test cases and expected outcomes is thus vital EECS 44B 34 Dr Douglas Niehaus 2009 EECS 44B 36 Dr Douglas Niehaus 2009 CASE Tools for PDM Metrics for PDM Source code control tools manage versions of Metrics for analysis design implementation testing individual files and perhaps sets of files and documentation a apply to PDM Content Management Systems add DB support for 39 Metrics SpeCifiC t0 PDM inClUde predUCt VerSion numbers correspondence to Measures related to software defect reports spec39f39c Vers39ons Of a Component 3995 Number classification severity duration 39 Huge number 0f Componelnts Current status metrics and Monthly or Yearly CCC change and configuration control also a term performance statistics used If an organization is not buying a complete CCC tool Then at least as version control CVS and build tool make must be used together Defect tracking DB is also mandatory for PDM EECS 44B 37 Dr Douglas Niehaus 2009 EECS 44B 39 Dr Douglas Niehaus 2009 CASE Tools for PDM Challenges for PDM Other useful tools can produce representations of Toughest aspects of PDM code structure for reverse engineering mm is usuany harder than devebpment 39 Rational Rose Together PDM work is often lower status and avoided by Doxygen those who can Disassemblers reverse compilers PDM is often paid less than other development wor Binutils objdump Battlemap Teamwork Bachman Reengineering 39 FUtUre influences I Product Set Greater use of formal technio1lues for development Defect tracking would have use implications or PDM Rational CearQuest Intensive code reuse Bugzilla Certainties Trac SWE will still be hard and fun if you like it EECS 44B 38 Dr Douglas Niehaus 2009 EECS 44B 40 Dr Douglas Niehaus 2009 Conclusions PDM is often given far less attention and credit than it deserves PDM very difficult and educational PDM is a common first job for developers Emphasize educational opportunities Prepare for difficulties EECS 448 41 Dr Douglas Niehaus 2009
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'