Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Spm unit v-software maintenance-intro

311 views

Published on

Spm unit v-software maintenance-intro

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Spm unit v-software maintenance-intro

  1. 1. SPM-UNIT - V SOFTWARE MAINTENANCE Prof. Kanchana Devi
  2. 2. Software Maintenance - Introduction Prof. Kanchana Devi 2  Modification of a software product after delivery to:  Correct faults  Improve performance or other attributes.  Adapt to a change in the environment.  A common work of maintenance is that it involves fixing defects.  Software maintenance is a very broad activity that includes  Error corrections  Enhancements of capabilities  Deletion of obsolete capabilities  Optimization. Resource: Wikipedia
  3. 3. Lehman’s Law Prof. Kanchana Devi 3  Maintenance is really evolutionary development and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Resource: Wikipedia
  4. 4. Software Maintenance – Issues & Side Effects Prof. Kanchana Devi 4  There are two main issues:  Management Issues  Technical Issues  Management issues are:  Alignment with customer priorities  Staffing, which organization does maintenance  Estimating costs.  Technical issues are:  Limited understanding  Impact analysis  Testing  Maintainability measurement. Resource: Wikipedia
  5. 5. Maintenance Activities & Characteristics Prof. Kanchana Devi 5  Adaptive  Modifying the system to cope with changes in the software environment  Perfective  Implementing new or changed user requirements which concern functional enhancements to the software  Corrective  Diagnosing and fixing errors, possibly ones found by users  Preventive  Increasing software maintainability or reliability to prevent problems in the future
  6. 6. Prof. Kanchana Devi 6
  7. 7. Software Maintenance Planning Prof. Kanchana Devi 7  Software Maintenance is an integral part, which requires an accurate maintenance plan.  It should specify how users will request modifications or report problems.  The budget should include resource and cost estimates.  It is an admitted fact that approximately 60 to 70% effort is spent on maintenance phase of software development life cycle.
  8. 8. Software Maintenance Processes Prof. Kanchana Devi 8  Software preparation and transition activities  Creation of the maintenance plan;  The preparation for handling problems  The follow-up on product configuration management.  The modification analysis process.  The implementation of the modification.  The process acceptance of the modification.  The migration process is exceptional, and is not part of daily maintenance tasks. (Platform Change)  Finally, the last maintenance process, is the retirement of a piece of software.
  9. 9. Reengineering Prof. Kanchana Devi 9
  10. 10. Metrics for Source Code Prof. Kanchana Devi 10  There are some measures to calculate the metrics:  n1 = number of distinct operators appear in the program  n2 = number of distinct operands appear in the program  N1 = Total number of operator occurrences  N2 = Total number of operand occurrences
  11. 11. Prof. Kanchana Devi 11  n1, n2, N1, N2 - These measures are used to develop expressions for  The overall length  Minimum volume for an algorithm  The actual volume  The program level  Language level  Other features  Development effort  Development time  Even the projected number of faults in the software.
  12. 12. Prof. Kanchana Devi 12  Length N  N = n1 log2 n1 + n2 log2 n2  Program Volume  V = N log2 (n1+n2)
  13. 13. Software Reliability Prof. Kanchana Devi 13  Categorising and specifying the reliability of software systems  Informal Definition:  Reliability is a measure of how well system users think it provides the services they require.  Probability of a software component will produce an incorrect output  Software can continue to operate after a bad result
  14. 14. ……… Prof. Kanchana Devi 14  Software Reliability is the probability of failure- free software operation for a specified period of time in a specified environment.  Software Reliability is also an important factor affecting system reliability.  It differs from hardware reliability in that it reflects the “design perfection”, rather than manufacturing perfection.  The high complexity of software is the major contributing factor of Software Reliability problems.
  15. 15. Traditional Methods For Improving Software Reliability Prof. Kanchana Devi 15  Three main techniques are used in industrial and open source projects to improve software reliability:  Manual Testing  Code Reviews:  Modifications are reviewed by experienced developers before being committed to the code base.  Coding Standards:  Requiring that all developers adhere to a set of rules when writing or maintaining code.  Coding standards can improve source code readability, making it easier to spot defects, and  Ban the use of programming idioms that are arguably dangerous.
  16. 16. Reliability Problems Prof. Kanchana Devi 16  They depend fundamentally on human reasoning and judgments  They do not provide guarantees
  17. 17. Measuring Reliability Prof. Kanchana Devi 17  A simple measure of reliability can be given as:  MTBF = MTTF + MTTR , where  MTBF is mean time between failures  MTTF is mean time to fail  MTTR is mean time to repair
  18. 18. Software Reliability Models Prof. Kanchana Devi 18  error seeding - estimates the number of errors in a program.  Errors are divided into indigenous errors and induced (seeded) errors. The unknown number of indigenous errors is estimated from the number of induced errors and the ratio of the two types of errors obtained from the testing data. • Reliability growth • Measures and predicts the improvement of reliability through the testing process using a growth function to represent the process. • Independent variables of the growth function could be time, number of test cases (or testing stages) and • The dependent variables can be reliability, failure rate or cumulative number of errors detected.
  19. 19. Prof. Kanchana Devi 19  Nonhomogeneous Poisson process (NHPP)  provide an analytical framework for describing the software failure phenomenon during testing.  the main issue is to estimate the mean value function of the cumulative number of failures experienced up to a certain point in time.  a key example of this approach is the series of Musa models
  20. 20. Prof. Kanchana Devi 20  A typical measure (failures per unit time) is the failure intensity (rate) given as:  where  = program CPU time (in a time shared computer) or wall clock time (in an embedded system). ) ],[infailuresof# ()(       f
  21. 21. Prof. Kanchana Devi 21  SR Growth models are generally “black box” - no easy way to account for a change in the operational profile  Operational profile: description of the input events expected to occur in actual software operation – how it will be used in practice  consequences are that we are unable to go from test to field
  22. 22. Prof. Kanchana Devi 22  Many models have been proposed, perhaps the most prominent are:  Musa Basic model  Musa/Okomoto Logarithmic model  Some models work better than others depending on the application area and operating characteristics: i.e. interactive? data intensive? control intensive? real-time?
  23. 23. Choice of Model Basic Model: Prof. Kanchana Devi 23 • For studies or predictions before execution and failure data available • Using study of faults to determine effects of a new software engineering technology • The program size is changing continually or substantially (i.e. during integration)
  24. 24. Logarithmic Model Prof. Kanchana Devi 24 • System subjected to highly non-uniform operational profiles. • Highly predictive validity is needed early in the execution period. The rapidly changing slope of the failure intensity during early stages can be better fitted with the logarithmic Poisson than the basic model .

×