Software Engineering Body of Knowledge (v3) (2014) (811503), страница 29
Текст из файла (страница 29)
Code browsers are key tools for programcomprehension and are used to organize and present source code. Clear and concise documentationcan also aid in program comprehension.4.2. Reengineering[2*, c7]Reengineering is defined as the examination andalteration of software to reconstitute it in a newform, and includes the subsequent implementation of the new form. It is often not undertaken toimprove maintainability but to replace aging legacy software. Refactoring is a reengineering technique that aims at reorganizing a program withoutchanging its behavior. It seeks to improve a program structure and its maintainability.
Refactoring techniques can be used during minor changes.[1*, c5s5]• notification of intent: a statement of whythe old environment is no longer to be supported, followed by a description of the newenvironment and its date of availability;• parallel operations: make available theold and new environments so that the userexperiences a smooth transition to the newenvironment;• notification of completion: when the scheduled migration is completed, a notification issent to all concerned;Software Maintenance 5-11• postoperation review: an assessment of parallel operation and the impact of changing tothe new environment;• data archival: storing the old software data.4.5. Retirement[1*, c5s6]Once software has reached the end of its useful life, it must be retired. An analysis shouldbe performed to assist in making the retirementdecision.
This analysis should be included in theretirement plan, which covers retirement requirements, impact, replacement, schedule, and effort.Accessibility of archive copies of data may alsobe included. Retiring software entails a numberof activities similar to migration.5. Software Maintenance Tools[1*, c6s4] [2*, c14]This topic encompasses tools that are particularlyimportant in software maintenance where existing software is being modified. Examples regarding program comprehension include• program slicers, which select only parts of aprogram affected by a change;• static analyzers, which allow general viewing and summaries of a program content;• dynamic analyzers, which allow the maintainer to trace the execution path of aprogram;• data flow analyzers, which allow the maintainer to track all possible data flows of aprogram;• cross-referencers, which generate indices ofprogram components; and• dependency analyzers, which help maintainers analyze and understand the interrelationships between components of a program.Reverse engineering tools assist the process byworking backwards from an existing product tocreate artifacts such as specification and designdescriptions, which can then be transformed togenerate a new product from an old one.
Maintainers also use software test, software configuration management, software documentation, andsoftware measurement tools.5-12 SWEBOK® Guide V3.0Grubb and Takang 2003[2*]c3c1s2, c2s2Sneed 2008[3*]IEEE/ISO/IEC 14764 2006[1*]MATRIX OF TOPICS VS. REFERENCE MATERIAL1. Software MaintenanceFundamentals1.1. Definitions and Terminology1.2. Nature of Maintenancec1s31.3. Need for Maintenancec1s51.4. Majority of Maintenance Costsc4s3, c5s5.21.5. Evolution of Software1.6. Categories of Maintenancec3s5c3, c6s2c3s3.1, c4s32. Key Issues in SoftwareMaintenance2.1. Technical Issues2.1.1. Limited Understanding2.1.2. Testingc6c6s2.2.2c92.1.3. Impact Analysisc5s2.5c13s32.1.4. Maintainabilityc6s8, c3s4c12s5.52.2. Management Issues2.2.1. Alignment withOrganizational objectivesc42.2.2. Staffing2.2.3. Process2.2.4. Organizational Aspects ofMaintenancec4s5, c10s4c5c5c7s.2.3c102.2.5. Outsourcing/Offshoringall2.3. Maintenance Cost Estimation2.3.1. Cost Estimationc7s4.1c7s2.42.3.2. Parametric Modelsc12s5.62.3.3. Experiencec12s5.52.4. Software MaintenanceMeasurementc6s52.4.1. Specific Measuresc12, c12s3.1c123. Maintenance Process3.1. Maintenance Processes3.2. Maintenance Activities3.2.1. Unique Activities3.2.2. Supporting Activities3.2.3. Maintenance PlanningActivities3.2.4. Software ConfigurationManagement3.2.5. Software Qualityc5c5, c5s3.2.2,c6s8.2, c7s3.3c3s10, c6s9, c7s2,c7s3c4s1, c5, c6s7c5c6,c7c9c7s2, c7s.3c5s1.2.3c11c6s5, c6s7, c6s8c12s5.34. Techniques for Maintenance4.1. Program Comprehensionc6,c14s54.2. Reengineeringc74.3. Reverse Engineeringc6s24.4. Migrationc5s54.5. Retirementc5s65. Software Maintenance Toolsc6s4c7, c14s5c14Sneed 2008[3*]Grubb and Takang 2003[2*]IEEE/ISO/IEC 14764 2006[1*]Software Maintenance 5-135-14 SWEBOK® Guide V3.0FURTHER READINGSREFERENCESA.
April and A. Abran, Software MaintenanceManagement: Evaluation and ContinuousImprovement [6].[1*] IEEE Std. 14764-2006 (a.k.a. ISO/IEC14764:2006) Standard for SoftwareEngineering—Software Life CycleProcesses—Maintenance, IEEE, 2006.This book explores the domain of small softwaremaintenance processes (S3M). It provides roadmaps for improving software maintenance processes in organizations.
It describes a softwaremaintenance specific maturity model organizedby levels which allow for benchmarking and continuous improvement. Goals for each key practice area are provided, and the process model presented is fully aligned with the architecture andframework of international standards ISO12207,ISO14764 and ISO15504 and popular maturitymodels like ITIL, CoBIT, CMMI and CM3.M. Kajko-Mattsson, “Towards a BusinessMaintenance Model,” IEEE Int’l Conf.Software Maintenance [7].This paper presents an overview of the Corrective Maintenance Maturity Model (CM3). Incontrast to other process models, CM3 is a specialized model, entirely dedicated to correctivemaintenance of software.
It views maintenance interms of the activities to be performed and theirorder, in terms of the information used by theseactivities, goals, rules and motivations for theirexecution, and organizational levels and rolesinvolved at various stages of a typical correctivemaintenance process.[2*] P. Grubb and A.A. Takang, SoftwareMaintenance: Concepts and Practice, 2nded., World Scientific Publishing, 2003.[3*] H.M. Sneed, “Offering SoftwareMaintenance as an Offshore Service,” Proc.IEEE Int’l Conf. Software Maintenance(ICSM 08), IEEE, 2008, pp. 1–5.[4*] J.W. Moore, The Road Map to SoftwareEngineering: A Standards-Based Guide,Wiley-IEEE Computer Society Press, 2006.[5] ISO/IEC/IEEE 24765:2010 Systems andSoftware Engineering—Vocabulary, ISO/IEC/IEEE, 2010.[6] A.
April and A. Abran, SoftwareMaintenance Management: Evaluationand Continuous Improvement, Wiley-IEEEComputer Society Press, 2008.[7] M. Kajko-Mattsson, “Towards a BusinessMaintenance Model,” Proc. Int’l Conf.Software Maintenance, IEEE, 2001, pp.500–509.CHAPTER 6SOFTWARE CONFIGURATION MANAGEMENTACRONYMSCCBCMFCAConfiguration Control BoardConfiguration ManagementFunctional Configuration AuditPCAPhysical Configuration AuditSCCBSCISCMSCMPSCRSCSASDDSEI/CMMISQASRSto serve a particular purpose. Configuration management (CM), then, is the discipline of identifying the configuration of a system at distinct pointsin time for the purpose of systematically controlling changes to the configuration and maintainingthe integrity and traceability of the configurationthroughout the system life cycle.
It is formallydefined asSoftware Configuration ControlBoardSoftware Configuration ItemSoftware ConfigurationManagementSoftware ConfigurationManagement PlanSoftware Change RequestSoftware Configuration StatusAccountingSoftware Design DocumentSoftware Engineering Institute’sCapability Maturity ModelIntegrationSoftware Quality AssuranceSoftware RequirementSpecificationA discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item,control changes to those characteristics,record and report change processing andimplementation status, and verify compliance with specified requirements.
[1]Software configuration management (SCM)is a supporting-software life cycle process thatbenefits project management, development andmaintenance activities, quality assurance activities, as well as the customers and users of the endproduct.The concepts of configuration managementapply to all items to be controlled, although thereare some differences in implementation betweenhardware CM and software CM.SCM is closely related to the software quality assurance (SQA) activity. As defined in theSoftware Quality knowledge area (KA), SQAprocesses provide assurance that the softwareproducts and processes in the project life cycleconform to their specified requirements by planning, enacting, and performing a set of activitiesto provide adequate confidence that quality isbeing built into the software.
SCM activities helpin accomplishing these SQA goals. In some project contexts, specific SQA requirements prescribecertain SCM activities.INTRODUCTIONA system can be defined as the combination ofinteracting elements organized to achieve one ormore stated purposes [1]. The configuration of asystem is the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product [1]; itcan also be thought of as a collection of specificversions of hardware, firmware, or software itemscombined according to specific build procedures6-16-2 SWEBOK® Guide V3.0Figure 6.1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
