{"id":307,"date":"2018-07-25T06:54:49","date_gmt":"2018-07-25T06:54:49","guid":{"rendered":"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/?post_type=chapter&p=307"},"modified":"2018-08-08T06:10:29","modified_gmt":"2018-08-08T06:10:29","slug":"software-maintenance","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/chapter\/software-maintenance\/","title":{"rendered":"Software Maintenance"},"content":{"raw":"
\r\n\r\n \r\n

SOFTWARE MAINTENANCE<\/strong><\/p>\r\n \r\n

Software maintenance is the process of modification or making changes in the system after delivery to overcome errors and faults in the system that were not uncovered during the early stages of the development cycle.<\/p>\r\n \r\n

LEARNING OBJECTIVES\u00a0<\/strong><\/p>\r\n \r\n

\u2022 To study on why maintenance is an issue.<\/em><\/p>\r\n

\u2022 To study on reverse engineering and limitations.<\/p>\r\n

\u2022 To organize data.<\/p>\r\n

\u2022 To check what the system does.<\/p>\r\n \r\n

SOFTWARE MAINTENANCE\u00a0<\/strong><\/p>\r\n \r\n

The IEEE Standard for Software Maintenance (IEEE 1219) gave the definition for software maintenance as \u201cThe process of modifying a software system or component after delivery to correct faults, improves performance or other attributes, or adapt to a changed environment.\u201d<\/p>\r\n \r\n\r\n<\/div>\r\n\"\"\r\n

\r\n\r\n \r\n\r\n\"\"\r\n

The IEEE\/EIA 12207 Standard defines maintenance as modification to code and associated documentation due to a problem or the need for improvement.<\/p>\r\n \r\n\r\nNature of Maintenance\u00a0<\/strong>\r\n\r\n \r\n

Modification requests are logged and tracked, the impact of proposed changes are determined, code and other software artifacts are modified, testing is conducted, and a new version of the software product is released. Maintainers can learn from the developer\u00b4s knowledge of the software.<\/p>\r\n \r\n\r\nNeed for Maintenance\u00a0<\/strong>\r\n\r\n \r\n\r\nMaintenance must be performed in order to:\r\n\r\n \r\n\r\n\u2022 Correct faults.\r\n\r\n\u2022 Improve the design.\r\n\r\n\u2022 Implement enhancements.\r\n\r\n\u2022 Interface with other systems.\r\n\r\n\u2022 Adapt programs so that different hardware, software, system features, and telecommunications facilities can be used.\r\n\r\n\u2022 Migrate legacy software.\r\n\r\n\u2022 Retire software\r\n\r\n<\/div>\r\n

\r\n\r\n \r\n\r\nTasks of a Maintainer<\/strong>\r\n\r\n \r\n\r\nThe maintainer does the following functions:\r\n\r\n \r\n\r\n\u2022\u00a0 Maintain control over the software\u00b4s day-to-day functions.\r\n\r\n\u2022\u00a0 Maintain control over software modification.\r\n\r\n\u2022\u00a0 Perfecting existing functions.\r\n\r\n\u2022\u00a0 Preventing software performance from degrading to unacceptable levels.\r\n\r\n \r\n\r\nMajority of Maintenance Costs\u00a0<\/strong>\r\n\r\n \r\n

Maintenance consumes a major share of software life cycle financial resources. But studies and surveys have shown that \u201cover 80% of the maintenance effort is used for non-corrective actions. Quality of software design, construction, documentation, and testing affects software maintenance costs.<\/p>\r\n \r\n\r\nEvolution of Software\u00a0<\/strong>\r\n\r\n \r\n

Lehman has studied software maintenance and evolution for over 20 years, leading to \u2018Lehman\u00b4s Laws\u2019. E.g. increasing complexity \u2014 as a program is evolved, its complexity increases unless work is done to maintain or reduce it.<\/p>\r\n \r\n\r\nCATEGORIES OF MAINTENANCE\u00a0<\/strong>\r\n\r\n \r\n\r\nMaintenance can be categorized into the follwing:\r\n

    \r\n \t
  • Corrective maintenance<\/li>\r\n \t
  • Adaptive maintenance<\/li>\r\n \t
  • Perfective maintenance<\/li>\r\n \t
  • Preventive maintenance<\/li>\r\n<\/ul>\r\n \r\n

    Corrective maintenance<\/strong>: Reactive modification of a software product performed after delivery to correct discovered problems.<\/p>\r\n \r\n

    Adaptive maintenance<\/strong>: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.<\/p>\r\n \r\n

    Perfective \u00a0maintenance<\/strong>: \u00a0Modification \u00a0of \u00a0a \u00a0software \u00a0product \u00a0after \u00a0delivery \u00a0to \u00a0improve performance or maintainability.\r\n<\/span><\/p>\r\n \r\n

    Preventive maintenance<\/strong>: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.<\/span><\/p>\r\n\r\n<\/div>\r\n

    \r\n\r\n \r\n\r\nKEY TO MAINTENANCE\u00a0<\/strong>\r\n\r\n \r\n

    The key to effective maintenance lies in development. Depending upon the development of the product the maintenance of the product is determined.<\/p>\r\n\r\n

      \r\n \t
    • Higher quality \u00de less (corrective) maintenance<\/li>\r\n \t
    • Anticipating changes \u00a0\u00de less (adaptive and perfective) maintenance<\/li>\r\n \t
    • Better tuning to user needs \u00a0\u00de less (perfective) maintenance<\/li>\r\n \t
    • Less code \u00de less maintenance<\/li>\r\n<\/ul>\r\n \r\n\r\nThe distribution of maintenance activities are shown in the figure below:\r\n\r\n \r\n\r\n\"\"\r\n\r\nMajor causes of maintenance problems\u00a0<\/strong>\r\n\r\n \r\n\r\nSome of the major factors which causes problem in maintenance is as follows:<\/span>\r\n
        \r\n \t
      • Unstructured code<\/span><\/li>\r\n \t
      • Insufficient domain knowledge<\/span><\/li>\r\n \t
      • Insufficient documentation<\/span><\/li>\r\n<\/ul>\r\n<\/div>\r\n \r\n

        The key issues in software maintenance include:<\/span><\/p>\r\n\r\n

        \r\n
          \r\n \t
        • Limited Understanding<\/li>\r\n \t
        • Shift in type of maintenance<\/li>\r\n \t
        • Impact Analysis<\/li>\r\n \t
        • Maintainability<\/li>\r\n \t
        • Alignment with organizational objectives<\/li>\r\n \t
        • Staffing<\/li>\r\n \t
        • Process<\/li>\r\n \t
        • Organizational aspects of maintenance<\/li>\r\n \t
        • Outsourcing<\/li>\r\n \t
        • Cost Estimation<\/li>\r\n \t
        • Specific Measures<\/li>\r\n<\/ul>\r\n \r\n\r\nLimited Understanding\u00a0<\/strong>\r\n\r\n \r\n

          The maintainers make changes or corrections to software that they did not write, so they should quickly understand the software. 40%-60% of the maintenance effort is devoted to understanding the software. Comprehension is difficult in the absence of documentation and when the original developers are unavailable. The maintainers must quickly understand the software and should make modifications to overcome the issues in the system.<\/p>\r\n \r\n\r\nShift in type of maintenance\u00a0<\/strong>\r\n\r\n \r\n\r\nShift in type of maintenance over time can be projected as follows:\r\n

            \r\n \t
          • Introductory stage: emphasis on user support.<\/li>\r\n \t
          • Growth stage: emphasis on correcting faults.<\/li>\r\n \t
          • Maturity: emphasis on enhancements.<\/li>\r\n \t
          • Decline: emphasis on technology changes.<\/li>\r\n<\/ul>\r\n \r\n\r\nImpact Analysis\u00a0<\/strong>\r\n\r\n \r\n\r\nThe objectives of impact analysis are:\r\n
              \r\n \t
            • Determination of the scope of the change in order to plan and implement the work.<\/li>\r\n \t
            • Development of accurate estimates of resources needed to perform the work<\/li>\r\n \t
            • Analysis of the cost\/benefits of the requested change<\/li>\r\n \t
            • Communication to others of the complexity of a given change\u201d.<\/li>\r\n<\/ul>\r\n<\/div>\r\n \r\n

              Maintainability<\/strong><\/p>\r\n \r\n

              IEEE [IEEE610.12-90] defines maintainabiliy as the ease with which software can be maintained, enhanced, adapted, or corrected to satisfy specified requirements and the presence of systematic and mature processes, techniques, and tools helps to enhance the maintainability of a system.<\/p>\r\n \r\n\r\nWeb Links<\/strong>\r\n

                \r\n \t
              • swebokwiki.org\/Chapter_5:_Software_Maintenance<\/li>\r\n \t
              • agile.csc.ncsu.edu\/SEMaterials\/MaintenanceRefactoring.pdf<\/li>\r\n \t
              • https:\/\/www.tutorialspoint.com\/software...\/software_maintenance_overview.htm<\/li>\r\n<\/ul>\r\n \r\n\r\nSupporting & Reference Materials<\/strong>\r\n
                  \r\n \t
                • Roger S. Pressman, \u201cSoftware Engineering: A Practitioner\u2019s Approach\u201d, Fifth Edition, McGraw Hill, 2001.<\/li>\r\n \t
                • Pankaj Jalote, \u201cAn Integrated Approach to Software Engineering\u201d, Second Edition, Narosa Publications, 2005.<\/li>\r\n \t
                • Ian Sommerville, \u201cSoftware Engineering\u201d, Tenth Edition, Pearson Education, 2017.<\/li>\r\n<\/ul>","rendered":"
                  \n

                   <\/p>\n

                  SOFTWARE MAINTENANCE<\/strong><\/p>\n

                   <\/p>\n

                  Software maintenance is the process of modification or making changes in the system after delivery to overcome errors and faults in the system that were not uncovered during the early stages of the development cycle.<\/p>\n

                   <\/p>\n

                  LEARNING OBJECTIVES\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  \u2022 To study on why maintenance is an issue.<\/em><\/p>\n

                  \u2022 To study on reverse engineering and limitations.<\/p>\n

                  \u2022 To organize data.<\/p>\n

                  \u2022 To check what the system does.<\/p>\n

                   <\/p>\n

                  SOFTWARE MAINTENANCE\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  The IEEE Standard for Software Maintenance (IEEE 1219) gave the definition for software maintenance as \u201cThe process of modifying a software system or component after delivery to correct faults, improves performance or other attributes, or adapt to a changed environment.\u201d<\/p>\n

                   <\/p>\n<\/div>\n

                  \"\"<\/p>\n

                  \n

                   <\/p>\n

                  \"\"<\/p>\n

                  The IEEE\/EIA 12207 Standard defines maintenance as modification to code and associated documentation due to a problem or the need for improvement.<\/p>\n

                   <\/p>\n

                  Nature of Maintenance\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  Modification requests are logged and tracked, the impact of proposed changes are determined, code and other software artifacts are modified, testing is conducted, and a new version of the software product is released. Maintainers can learn from the developer\u00b4s knowledge of the software.<\/p>\n

                   <\/p>\n

                  Need for Maintenance\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  Maintenance must be performed in order to:<\/p>\n

                   <\/p>\n

                  \u2022 Correct faults.<\/p>\n

                  \u2022 Improve the design.<\/p>\n

                  \u2022 Implement enhancements.<\/p>\n

                  \u2022 Interface with other systems.<\/p>\n

                  \u2022 Adapt programs so that different hardware, software, system features, and telecommunications facilities can be used.<\/p>\n

                  \u2022 Migrate legacy software.<\/p>\n

                  \u2022 Retire software<\/p>\n<\/div>\n

                  \n

                   <\/p>\n

                  Tasks of a Maintainer<\/strong><\/p>\n

                   <\/p>\n

                  The maintainer does the following functions:<\/p>\n

                   <\/p>\n

                  \u2022\u00a0 Maintain control over the software\u00b4s day-to-day functions.<\/p>\n

                  \u2022\u00a0 Maintain control over software modification.<\/p>\n

                  \u2022\u00a0 Perfecting existing functions.<\/p>\n

                  \u2022\u00a0 Preventing software performance from degrading to unacceptable levels.<\/p>\n

                   <\/p>\n

                  Majority of Maintenance Costs\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  Maintenance consumes a major share of software life cycle financial resources. But studies and surveys have shown that \u201cover 80% of the maintenance effort is used for non-corrective actions. Quality of software design, construction, documentation, and testing affects software maintenance costs.<\/p>\n

                   <\/p>\n

                  Evolution of Software\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  Lehman has studied software maintenance and evolution for over 20 years, leading to \u2018Lehman\u00b4s Laws\u2019. E.g. increasing complexity \u2014 as a program is evolved, its complexity increases unless work is done to maintain or reduce it.<\/p>\n

                   <\/p>\n

                  CATEGORIES OF MAINTENANCE\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  Maintenance can be categorized into the follwing:<\/p>\n

                    \n
                  • Corrective maintenance<\/li>\n
                  • Adaptive maintenance<\/li>\n
                  • Perfective maintenance<\/li>\n
                  • Preventive maintenance<\/li>\n<\/ul>\n

                     <\/p>\n

                    Corrective maintenance<\/strong>: Reactive modification of a software product performed after delivery to correct discovered problems.<\/p>\n

                     <\/p>\n

                    Adaptive maintenance<\/strong>: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.<\/p>\n

                     <\/p>\n

                    Perfective \u00a0maintenance<\/strong>: \u00a0Modification \u00a0of \u00a0a \u00a0software \u00a0product \u00a0after \u00a0delivery \u00a0to \u00a0improve performance or maintainability.
                    \n<\/span><\/p>\n

                     <\/p>\n

                    Preventive maintenance<\/strong>: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.<\/span><\/p>\n<\/div>\n

                    \n

                     <\/p>\n

                    KEY TO MAINTENANCE\u00a0<\/strong><\/p>\n

                     <\/p>\n

                    The key to effective maintenance lies in development. Depending upon the development of the product the maintenance of the product is determined.<\/p>\n

                      \n
                    • Higher quality \u00de less (corrective) maintenance<\/li>\n
                    • Anticipating changes \u00a0\u00de less (adaptive and perfective) maintenance<\/li>\n
                    • Better tuning to user needs \u00a0\u00de less (perfective) maintenance<\/li>\n
                    • Less code \u00de less maintenance<\/li>\n<\/ul>\n

                       <\/p>\n

                      The distribution of maintenance activities are shown in the figure below:<\/p>\n

                       <\/p>\n

                      \"\"<\/p>\n

                      Major causes of maintenance problems\u00a0<\/strong><\/p>\n

                       <\/p>\n

                      Some of the major factors which causes problem in maintenance is as follows:<\/span><\/p>\n

                        \n
                      • Unstructured code<\/span><\/li>\n
                      • Insufficient domain knowledge<\/span><\/li>\n
                      • Insufficient documentation<\/span><\/li>\n<\/ul>\n<\/div>\n

                         <\/p>\n

                        The key issues in software maintenance include:<\/span><\/p>\n

                        \n
                          \n
                        • Limited Understanding<\/li>\n
                        • Shift in type of maintenance<\/li>\n
                        • Impact Analysis<\/li>\n
                        • Maintainability<\/li>\n
                        • Alignment with organizational objectives<\/li>\n
                        • Staffing<\/li>\n
                        • Process<\/li>\n
                        • Organizational aspects of maintenance<\/li>\n
                        • Outsourcing<\/li>\n
                        • Cost Estimation<\/li>\n
                        • Specific Measures<\/li>\n<\/ul>\n

                           <\/p>\n

                          Limited Understanding\u00a0<\/strong><\/p>\n

                           <\/p>\n

                          The maintainers make changes or corrections to software that they did not write, so they should quickly understand the software. 40%-60% of the maintenance effort is devoted to understanding the software. Comprehension is difficult in the absence of documentation and when the original developers are unavailable. The maintainers must quickly understand the software and should make modifications to overcome the issues in the system.<\/p>\n

                           <\/p>\n

                          Shift in type of maintenance\u00a0<\/strong><\/p>\n

                           <\/p>\n

                          Shift in type of maintenance over time can be projected as follows:<\/p>\n

                            \n
                          • Introductory stage: emphasis on user support.<\/li>\n
                          • Growth stage: emphasis on correcting faults.<\/li>\n
                          • Maturity: emphasis on enhancements.<\/li>\n
                          • Decline: emphasis on technology changes.<\/li>\n<\/ul>\n

                             <\/p>\n

                            Impact Analysis\u00a0<\/strong><\/p>\n

                             <\/p>\n

                            The objectives of impact analysis are:<\/p>\n

                              \n
                            • Determination of the scope of the change in order to plan and implement the work.<\/li>\n
                            • Development of accurate estimates of resources needed to perform the work<\/li>\n
                            • Analysis of the cost\/benefits of the requested change<\/li>\n
                            • Communication to others of the complexity of a given change\u201d.<\/li>\n<\/ul>\n<\/div>\n

                               <\/p>\n

                              Maintainability<\/strong><\/p>\n

                               <\/p>\n

                              IEEE [IEEE610.12-90] defines maintainabiliy as the ease with which software can be maintained, enhanced, adapted, or corrected to satisfy specified requirements and the presence of systematic and mature processes, techniques, and tools helps to enhance the maintainability of a system.<\/p>\n

                               <\/p>\n

                              Web Links<\/strong><\/p>\n

                                \n
                              • swebokwiki.org\/Chapter_5:_Software_Maintenance<\/li>\n
                              • agile.csc.ncsu.edu\/SEMaterials\/MaintenanceRefactoring.pdf<\/li>\n
                              • https:\/\/www.tutorialspoint.com\/software…\/software_maintenance_overview.htm<\/li>\n<\/ul>\n

                                 <\/p>\n

                                Supporting & Reference Materials<\/strong><\/p>\n

                                  \n
                                • Roger S. Pressman, \u201cSoftware Engineering: A Practitioner\u2019s Approach\u201d, Fifth Edition, McGraw Hill, 2001.<\/li>\n
                                • Pankaj Jalote, \u201cAn Integrated Approach to Software Engineering\u201d, Second Edition, Narosa Publications, 2005.<\/li>\n
                                • Ian Sommerville, \u201cSoftware Engineering\u201d, Tenth Edition, Pearson Education, 2017.<\/li>\n<\/ul>\n","protected":false},"author":4,"menu_order":31,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["dr-r-baskaran"],"pb_section_license":""},"chapter-type":[],"contributor":[58],"license":[],"class_list":["post-307","chapter","type-chapter","status-publish","hentry","contributor-dr-r-baskaran"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/users\/4"}],"version-history":[{"count":6,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/307\/revisions"}],"predecessor-version":[{"id":418,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/307\/revisions\/418"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/307\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/media?parent=307"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapter-type?post=307"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/contributor?post=307"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/license?post=307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}