Software Engineering Body of Knowledge (v3) (2014) (811503), страница 28
Текст из файла (страница 28)
The softwarequality model suggests measures that are specificfor software maintenance. Measures for subcharacteristics of maintainability include the following [4*, p. 60]:• Analyzability: measures of the maintainer’seffort or resources expended in trying eitherto diagnose deficiencies or causes of failureor to identify parts to be modified.• Changeability: measures of the maintainer’seffort associated with implementing a specified modification.• Stability: measures of the unexpected behavior of software, including that encounteredduring testing.• Testability: measures of the maintainer’s andusers’ effort in trying to test the modifiedsoftware.• Other measures that maintainers use include• size of the software,• complexity of the software ,• understandability, and• maintainability.Providing software maintenance effort, bycategories, for different applications providesbusiness information to users and their organizations.
It can also enable the comparison of software maintenance profiles internally within anorganization.3. Maintenance ProcessIn addition to standard software engineering processes and activities described in IEEE 14764,there are a number of activities that are unique tomaintainers.3.1. Maintenance Processes[1*, c5] [2*, c5] [5, s5.5]Maintenance processes provide needed activitiesand detailed inputs/outputs to those activities asdescribed in IEEE 14764.
The maintenance process activities of IEEE 14764 are shown in Figure5.2. Software maintenance activities include• process implementation,• problem and modification analysis,• modification implementation,5-8 SWEBOK® Guide V3.0• maintenance review/acceptance,• migration, and• software retirement.activities and tasks are the responsibility of themaintainer. As already noted, many maintenanceactivities are similar to those of software development. Maintainers perform analysis, design, coding, testing, and documentation. They must trackrequirements in their activities—just as is donein development—and update documentation asbaselines change.
IEEE 14764 recommends thatwhen a maintainer uses a development process,it must be tailored to meet specific needs [1*,c5s3.2.2]. However, for software maintenance,some activities involve processes unique to software maintenance.3.2.1. Unique Activities[1*, c3s10, c6s9, c7s2, c7s3] [2*, c6, c7]There are a number of processes, activities, andpractices that are unique to software maintenance:Figure 5.2. Software Maintenance ProcessOther maintenance process models include:• quick fix,• spiral,• Osborne’s,• iterative enhancement, and• reuse-oriented.Recently, agile methodologies, which promotelight processes, have been also adapted to maintenance. This requirement emerges from the everincreasing demand for fast turnaround of maintenance services.
Improvement to the softwaremaintenance process is supported by specializedsoftware maintenance capability maturity models(see [6] and [7], which are briefly annotated in theFurther Readings section).3.2. Maintenance Activities[1*, c5, c6s8.2, c7s3.3]The maintenance process contains the activitiesand tasks necessary to modify an existing software product while preserving its integrity. These• Program understanding: activities needed toobtain a general knowledge of what a softwareproduct does and how the parts work together.• Transition: a controlled and coordinatedsequence of activities during which softwareis transferred progressively from the developer to the maintainer.• Modification request acceptance/rejection:modifications requesting work beyond a certain size/effort/complexity may be rejectedby maintainers and rerouted to a developer.• Maintenance help desk: an end-user andmaintenance coordinated support functionthat triggers the assessment, prioritization,and costing of modification requests.• Impact analysis: a technique to identify areasimpacted by a potential change;• Maintenance Service-Level Agreements(SLAs) and maintenance licenses and contracts: contractual agreements that describethe services and quality objectives.3.2.2. Supporting Activities[1*, c4s1, c5, c6s7] [2*, c9]Maintainers may also perform support activities,such as documentation, software configurationmanagement, verification and validation, problemresolution, software quality assurance, reviews,Software Maintenance 5-9and audits.
Another important support activityconsists of training the maintainers and users.3.2.3. Maintenance Planning Activities[1*, c7s3]An important activity for software maintenance isplanning, and maintainers must address the issuesassociated with a number of planning perspectives, including• business planning (organizational level),• maintenance planning (transition level),• release/version planning (software level), and• individual software change request planning(request level).At the individual request level, planning iscarried out during the impact analysis (see section 2.1.3, Impact Analysis). The release/versionplanning activity requires that the maintainer:• collect the dates of availability of individualrequests,• agree with users on the content of subsequentreleases/versions,• identify potential conflicts and developalternatives,• assess the risk of a given release and developa back-out plan in case problems shouldarise, and• inform all the stakeholders.Whereas software development projects cantypically last from some months to a few years,the maintenance phase usually lasts for manyyears.
Making estimates of resources is a key element of maintenance planning. Software maintenance planning should begin with the decisionto develop a new software product and shouldconsider quality objectives. A concept documentshould be developed, followed by a maintenanceplan. The maintenance concept for each softwareproduct needs to be documented in the plan [1*,c7s2] and should address the• scope of the software maintenance,• adaptation of the software maintenanceprocess,• identification of the software maintenanceorganization, and• estimate of software maintenance costs.The next step is to develop a correspondingsoftware maintenance plan. This plan should beprepared during software development and shouldspecify how users will request software modifications or report problems.
Software maintenanceplanning is addressed in IEEE 14764. It providesguidelines for a maintenance plan. Finally, atthe highest level, the maintenance organizationwill have to conduct business planning activities(budgetary, financial, and human resources) justlike all the other divisions of the organization.Management is discussed in the chapter RelatedDisciplines of Software Engineering.3.2.4. Software Configuration Management[1*, c5s1.2.3] [2*, c11]IEEE 14764 describes software configurationmanagement as a critical element of the maintenance process.
Software configuration management procedures should provide for the verification, validation, and audit of each step requiredto identify, authorize, implement, and release thesoftware product.It is not sufficient to simply track modification requests or problem reports. The softwareproduct and any changes made to it must be controlled. This control is established by implementing and enforcing an approved software configuration management (SCM) process. The SoftwareConfiguration Management KA provides detailsof SCM and discusses the process by which software change requests are submitted, evaluated,and approved. SCM for software maintenance isdifferent from SCM for software development inthe number of small changes that must be controlled on operational software.
The SCM process is implemented by developing and followinga software configuration management plan andoperating procedures. Maintainers participate inConfiguration Control Boards to determine thecontent of the next release/version.5-10 SWEBOK® Guide V3.03.2.5. Software Quality[1*, c6s5, c6s7, c6s8] [2*, c12s5.3]4.3. Reverse Engineering[1*, c6s2] [2*, c7, c14s5]It is not sufficient to simply hope that increasedquality will result from the maintenance of software. Maintainers should have a software quality program.
It must be planned and processesmust be implemented to support the maintenanceprocess. The activities and techniques for Software Quality Assurance (SQA), V&V, reviews,and audits must be selected in concert with allthe other processes to achieve the desired levelof quality. It is also recommended that the maintainer adapt the software development processes,techniques and deliverables (for instance, testingdocumentation), and test results. More details canbe found in the Software Quality KA.Reverse engineering is the process of analyzingsoftware to identify the software’s componentsand their inter-relationships and to create representations of the software in another form or athigher levels of abstraction. Reverse engineering is passive; it does not change the softwareor result in new software. Reverse engineering efforts produce call graphs and control flowgraphs from source code.
One type of reverseengineering is redocumentation. Another type isdesign recovery. Finally, data reverse engineering, where logical schemas are recovered fromphysical databases, has grown in importance overthe last few years. Tools are key for reverse engineering and related tasks such as redocumentation and design recovery.4. Techniques for MaintenanceThis topic introduces some of the generallyaccepted techniques used in software maintenance.4.4. Migration4.1. Program ComprehensionDuring software’s life, it may have to be modified to run in different environments. In order tomigrate it to a new environment, the maintainerneeds to determine the actions needed to accomplish the migration, and then develop and document the steps required to effect the migration ina migration plan that covers migration requirements, migration tools, conversion of productand data, execution, verification, and support.Migrating software can also entail a number ofadditional activities such as[2*, c6, c14s5]Programmers spend considerable time reading andunderstanding programs in order to implementchanges.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
