Managing Maintenance管理维护.pptVIP

Managing Maintenance Many issues in “managing” the maintenance phase: Maintenance activities themselves are hard People and Morale Maintenance Process and Artifacts Maintenance cost Support metrics Maintenance Activities The basic activities of maintenance is not that different from development - - - but: “New” requirements + existing requirements “New” design + existing design “New” code + existing code “New” test + existing test “New” integration + existing files “New” documentation + existing documentations Importance of Regression Test Whenever a new release is built upon a previous release, we are concerned that no existing functions are destroyed. Integration and Regression tests are important - - - is it a must ? : Do we rerun all the previous test cases (especially with OO inheritances) along with the new test cases? If we run only part of the previous test cases, then which parts? Parts that have interfaces to the new parts? Parts that showed error proneness? Randomly pick test cases from previous regression bucket? Existing Material Complexity Many existing material are good and provide a basis for further development: Maintenance people need to be giving time to digest all the existing material; this takes time Some original developers should be made available to the maintenance personnel Tools should be provided to help understand and track the various pieces and parts Configuration management process Configuration management tool Version control Build and integration Some Complexity Measure for Maintenance McCabe’s Cyclomatic Number on a control flow graph: Complexity = edges – nodes + 2 or Complexity = # of binary decisions + 1 # of Fan-in and # of Fan-out for the effect of coupling on maintenance Gerlich Denskat (of m components and k needs changes) then: [ k*(m-k) + k*(k-1)/2 ] interfaces need to be checked Some Interesting Experiencesbased on Porter and Selby Using Classification Tree Analysis to predict interfac