Software Maintenance Process of IEEE Standard 14764-2006
IEEE 12207: International Standard: Software Engineering - Softare Life Cycle Processes defines that all the processes, activities, and tasks required for designing, developing and maintaining software to consist of five primary life cycle process categories: Acquisition, Supply, Development, Operation, and Maintenance (2008). IEEE 14764, International Standard: Software Engineering - Softare Life Cycle Processes - Maintenance (2006), offers expanded guidance on the processes that comprise the Maintenance category defined in IEEE Std. 12207. It is not intended to replace the guidance offered in IEEE Std. 12207 but rather builds upon and is intended to be a supplement to it.
This paper is organized into three sections. The first section is a discussion about the guidance offered by IEEE Std. 14764 regarding the importance of formulating and composing a maintenance strategy. The composition of a maintenance strategy involves the preliminary definition of a maintenance concept, which will define the high level goals of the effort in terms of scope; a designation of the responsibility of the processes and an estimation of their costs; the establishment of a maintenance plan, that will define the actual tasks, controls, schedule and standards by which maintenance activities will be conducted; and the finally an analysis of the estimated resources and costs associated with the implementation of the plan.
The second section of this paper provides an examination of the six primary categories of maintenance activities as defined by both IEEE Std. 12207 and IEEE Std. 14764. Briefly, these processes are maintenance process planning; problem and modification analysis processes, maintenance implementation processes, maintenance review and acceptance processes, system migration processes, and software retirement processes (2006). This section provides and an enumeration of each of these categories along with a summary of the processes offered with each of them.
The final section of this paper offers a summary of the considerations that IEEE Std. 14764offers with regards to the implementation of the six maintenance process categories discussed in the second section. This section services to provide a reiteration of the best practices and common concerns associated with the execution of these processes.
IEEE Std. 14764defines a maintenance strategy as, "the strategy [that] prepares for the human and material resources required to provide software maintenance for software products" (2006, p. 31). The development of a software maintenance strategy is fundamental in establishing a maintenance effort for it serves to not only to define the purpose and goals behind it, but establishes the spirit and objectives by which all subsequent and component maintenance planning efforts will be defined.
Defining a maintenance strategy should started with an assessment of the maintainability of the system to be supported (2006). Assessment through analysis is an important preliminary step for it provides an orientation on the state of the software to be supported. This analysis should include a review of the existing software code and the technologies used to develop it to derive a list of the skill sets and tools that will be necessary to implement changes. This review should also include a review of its architectural integrity and the degree to which software decay has compromised it (Bennet & Rajlich, 2000). This is important in developing a feel for how difficult it will be to provide modifications and is helpful in determining the level of support that can be provided. This maintainability assessment should also include a determination of the amount of system expertise and domain knowledge of its original developers if any, that is at hand. Borrowing from the Staged Model, these two factors (i.e. the current state of its architectural integrity and the amount of system expertise/domain knowledge that has been retained and is available) will determine whether the system is in an evolutionary or servicing phase of its lifecycle. (Bennet & Rajlich, 2000) Understanding this will be invaluable in determining the type of modifications that can supported (e.g. adaptive, corrective, perfective, etc.) and will assist the maintainer in subsequent resource estimation efforts.
Intuitively, many successful endeavors are the results of great plans. Great plans are derived from great strategies; which in turn are inspired of great concepts. IEEE Std. 14764follows this logic in that it advocates that first a preliminary maintenance strategy be developed which will serve as implementation plan, it calls the maintenance plan (2006). It defines a maintenance strategy as consists of the two primary components: a maintenance concept, which includes a preliminary high-level definition of the scope, identification of responsibilities, costs, and processes for the maintenance effort. The second component is the maintenance plan, which essentially defines the tasks and schedule by which the maintenance concept will be implemented and conducted; and a resource analysis, which will provide a high-level estimate of the necessary resources and their associated costs required to execute the plan.
Defining the maintenance concept, as IEEE Std. 14764states, "[it] should be the first step in developing the software maintenance strategy" (2006, p. 32) and should be developed when the initial software maintenance needs are first expressed. As indicated the maintenance concept should define scope, the processes that will be used, the designation of who will be providing the maintenance services (e.g. an internal team or third party) and an estimate of the costs associated with it.
The scope of the maintenance concept should express the types of maintenance to be performed. This should be a reflection the assessed maintainability of the system placed in balanced with the support requirements of its users. The scope should also include a definition of the amount of documentation that will be maintained and expectations of the responsiveness of the maintenance team. It should include an assessment of the level and type of training that will be necessary to provide and should define both the scale of the delivery and helpdesk support.
The maintenance concept should also include a high-level definition of the processes that will be used to provide maintenance support for the intended system. This should not only include identification of the high-level tasks and methodologies necessary to facilitate the declared scope of support; but also, identify the stakeholders and other entities involved with the execution of those activities.
As eluded to in the previous paragraph, the maintenance concept should also include an identification the responsibilities, qualifications, accommodations, and considerations of the costs that will be necessary to provide the desired level of support as defined by its scope. This should include an assessment of the service level required, the requirements pertaining to and availability of space, the qualifications necessary to perform the various tasks ranging from helpdesk to programming, and an estimate of the start-up to long term costs associated with all of it. IEEE Std. 14764suggests that IEEE Std. 12207 be sought for additional guidance on acquiring and supplying software services (2006).
In formulating a high-level estimate of the costs discussed so far, IEEE Std. 14764 states that "costs should be a function of the scope of maintenance [defined]" (2006, p. 33). Additional considerations offered by it are to include any travel costs associated with user locations; the costs of training the maintenance staff in addition to the users; the costs associated with maintaining the development and testing environment necessary to conduct programming and testing tasks; the estimated personnel costs, to including estimated salaries and benefits. One final cost consideration offered by IEEE Std. 14764 that has composite cost implications beyond the maintenance effort itself, is an estimate of the amount of system down time that will be necessary and the associated costs of that down time to its users. These estimates should not be static. In the beginning these estimations will be based upon assumptions and limited information; and as the effort progresses, these estimates should be revised with new information as it comes to light.
With the maintenance concept established, the next step in formulating a maintenance strategy is to plan on how to turn the concept into to reality -- to formulate a plan for its execution. IEEE Std. 14764states that maintenance plan which should cover: why maintenance is necessary; how users will submit modification and support requests; and a decomposition of the tasks necessary to provide support to include assignment of responsibilities. A maintenance plan will define what resources will be available to provide support; where that support will be performed and when it will commence. As suggested, it should define not only the protocols of how requests will be submitted, but also define the protocols that will be used to analyze, implement, and provide feedback to those requestors. It should indicate the documentation that will be generated as a product of those protocols and provide what training and controls will be used to support and monitor the process. IEEE Std. 14764suggests that for additional guidance in planning for maintenance, that IEEE Std. 1058 be references. IEEE Std. 14764 also provides a general outline for the structure of a maintenance plan document along with the categorical items of information that should be provided.
With the scope of the effort defined by the maintenance concept and the responsibility for whom will perform the activities and tasks defined, the final component of the maintenance strategy is to perform a resource analysis which will the determine the personnel, environments, and financial resources required to support the plan.
Determining the personnel resources for a maintenance effort is perhaps the most challenging; for not only does the cost of people comprise a large portion of the overall costs; it is also perhaps the most difficult of the resource components to estimate accurately, particularly in advance.
IEEE Std. 14764 states that there are two primary approaches to estimating of software maintenance resources. If empirical data from previous maintenance efforts is available, parametric models may be used to provide a statistical estimate of resource costs. The other approach involves the use of non-quantitative, user intuition techniques based on experience, such as Delphi and work-breakdown structures, to estimate staffing needs and their associated costs. While these two categories of may be used individually, the likely best results will be from using them in combination. Regardless of the approaches and techniques selected, IEEE Std. 14764 iterates the importance of establishing a "standard, agreed-upon methodology for estimating maintenance" (2006, p. 38). By having a consistent methodology established, it can be refined based upon comparisons with actual costs as they are incurred, allowing for improved accuracy in subsequent efforts.
As with its initial development, providing maintenance services for a software system requires, at a minimum, the use of two separate environments. The first is a software engineering environment (SEE), to serve as a development environment where software modifications will be implemented in isolation from the production system. The second environment is a software test environment (STE), to serve as staging and integration environment that will be used to validate and verify for quality the modifications before they are introduced to the users in production. IEEE Std. 14764 advocates that "it is critical to get the maintenance environment included in early planning efforts when funds are allocated and a budget is determined" (2006, p. 38). This will ensure that all engaged modification efforts are conducted in an appropriate environment that is conducive to the effort.
The final component of a resource analysis relates to finances. To effectively provide for maintenance support, a budget needs to be determined that reflects the costs associated with: the salaries of personnel; the costs of training and technical materials for personnel; software and hardware licenses costs for the maintenance environments, and travel requirements for personnel
So far some of the IEEE Std. 14764 the components of effectively planning for a maintenance effort have been discussed. In the following section, the maintenance processes that will define the individual activities and tasks that will be work items of a maintenance plan will be discussed.
Commonly cited in works seeking a standardized definition of the term, IEEE Std. 14764defines software maintenance processes as "the actives and tasks for the primary lifecycle process of software maintenance" (2006, p. 5); of which, it defines five types.
The first category of processes consists of those that are associated with the implementation of process itself. These implementation processes are the set of practices by which the maintainer of the system establishes the plans and procedures to be used during over all the Maintenance Process. If establishment of the maintenance plan coincides with the original development of the system, it is important that the development of the Maintenance Plan begin in parallel with the development of the Development Plan. It is also important for the maintainer to establish the organizational interfaces necessary to support the Maintenance Process.
According to IEEE 14764, there are four activities associated with the process implementation phases that serve to lay the foundation for the rest of the effort; they include: initiating the developing the maintenance plan; establish MR/PR procedures; implementing configuration management; and developing a configuration management plan.
Much like a battle-plan, the maintenance plan serves to document the strategy and overall goal of the maintenance process, while its maintenance procedures serve to describe the activities and tasks that are executed to achieve it. In order to establish an effective maintenance plan and procedures, the following tasks and considerations should be performed: developing the maintenance concept, determine the scope of the maintenance effort, and to evaluate all the determined organizational alternatives for maintenance; establish, in writing, who will be the maintainer of the system; perform resource analysis to determine the number of personnel and equipment necessary to support the selected effort and the cost associated with that selection. It is also important at this time, to determine the maintainability of the system. This will factor largely in the aforementioned scope, cost, and resource estimations. At this point, the transition requirements and milestones should be identified and the entirety of the results of these tasks should be documented in the form operating procedures, so that they can be easily referenced.
Of special importance during this phase is the establishment of the modification request (MR) and problem report (PR) procedures, for these will be the primary means by which requests for modification of the system will be received and addressed and their resolution communicated. These processes are vital for they establish not only human interfaces (i.e. user-to-support) that will be used to convey information, but also provide a structure such those responses to those requests can be conducted in a matter that is not only conductive to their resolution but provides a means to control and assess those modification. Establishing MR/PR procedures should consist, at a minimum, of the following: a identify numbers scheme that can be used to uniquely identify a request; a scheme for categorizing these requests (e.g. as adaptive, corrective, or perfective modification requests, etc.), assigning a status (e.g. received, under evaluation, approved, etc.), and assigning a graduated priority-level (e.g. high, medium, low, etc.). Metrics (e.g. break/fix rate, complexity, etc.) should be gathered and analyzed for trends, so that relative directions of the maintenance effort can be monitored. An outline of the actual workflow process by which submitters of requests and items will use should be constructed to include a solid mechanism for communicating between the maintenance team members and users. Finally, the items should be placed into configuration management and organized in a database.
So far, the tasks described had been associated with the establishment of the procedures concerning the collection, organization, processing, and retention of work items (e.g. MRs, PRs.) information will be inputted and processed; correspondingly, it is also important to establish the procedures by which information will get back to those outside the system, particularly to those who requested a modification or submitted feedback; as such, it is important to also establish the procedures by which follow-up feedback will be provided to submitters of requests to include any work-a-rounds that may assist the user or the decisions made regarding MR/PR requests.
The results of these process implementation processes should be: the maintenance plan; the training plan; the maintenance procedures; the project management plan; the problem resolution procedures; the measurement plan; the maintenance manual; plans for user feedback; the transition plan; the maintainability assessment; and the configuration management plan.
The second set of processes, referred to by IEEE Std. 14764as the "Problem and Modification Analysis" processes (2006, p. 9); these are those that pertain to the analysis of modification and problem support requests to determine a course of action is response to them.
For every MR or PR received, the high-level process for analyzing them should include: replication or verification of the problem described in the request; the development of the options for implementing the modification; documenting the MR/PR, the results, and execution options; and obtaining approval for the selected modification option.
In performing the analysis on whether and how to pursue the resolution of an MR/PR, the maintainer ought to ensure that they are adequately staffed and funded to implement the proposed modification. Pertaining more to MRs than PRs, the maintainer should also be confident that the implementation of the modification will not affect, or at least understand how it will affect, any ongoing or future projects. Consideration should also be given to how the fulfillment of the request will affect the overall operability of the system.
The third category of maintenance processes are "Modification Implementation" processes (2006, p. 13). These processes are associated with the development and testing of modifications to the software system once they have been vetted through the previous set.
The required materials for these practices (i.e. the inputs) are the baseline of the system, which consists of the system architecture definition: the modification request record, and the source code of the system; the approved MR/PR; and the approved modification documentation, which consists of the impact analysis report and any other outputs from the preliminary Problem and Modification Analysis activity.
These inputs are used with two sets of sub-category activities: analysis activities and development processes. Following the definition of IEEE Std. 12207, analysis activities are those associated determining which documentation and software units, to include which versions thereof would be affected by the implementation of a change. More specifically, these activities involve accomplishing the following: identifying the software components and interface elements affected by the modification; the documentation that would require modification; and actual updating of documentation to reflect the change.
The development processes of this category are involved with the actual implementation of the modification and should be tailored to meet the needs of the system at hand. As defined by IEEE Std. 12207 the requirements for these processes include the test and evaluation criteria for testing and evaluating the modified and the unmodified parts of the system. This suggests that testing associated with verification of the change should include the normal unit and system level tests; however, this also suggests that a best practice is also to include regression tests to ensure that untouched areas of the system are functioning properly. This information could also address the accuracy of the impact analysis.
In agreement with IEEE Std. 12207, IEEE 14764 reiterates that configuration management practices should include the version management of the system and that both the original and modified versions of the software shall be maintained. This is a best practice that ensures not only the ability to roll back any changes, but also preserves the history of changes for sake of knowing where potential issues where introduced.
As with the previous categories of processes, with regards to controls for this effort, IEEE Std. 14764advocates the use of a Joint Reviews to validate that these analysis and development processes have been conducted according to plan and to verify that a consensus exists that it was performed in an acceptable way.
The end result of the Modification Implementation activities should include not only the modified source code; but also, the updated, test plans, test procedures, test reports, and system documentation that were impacted by this change. This should include: the updated modification request with completed resolution to it; a detailed analysis report that lists the components affected by this change; updates to the baseline requirements of the system; and the updated user and training manuals the cover the implementation of this change.
The fourth category of activities offered by IEEE Std. 14764is the " Maintenance Review/Acceptance" processes(2006, p. 15). In addition to the use of Joint Reviews advocated in the previous category, these processes are designed to ensure that the modifications to the system are made in acceptable manner and in-line with the methodologies and standards established for the system in the maintenance strategy.
These validation and verification associated processes require the modified software and the results of the tests performed on it. With these pieces of information, IEEE Std. 14764 suggests that the following the minimum checks should be performed:
First, to in order to ensure that there is a relationship between the requirements and the delivered modified system, there ought to be verification that there is traceability between the MR/PR from the requirement to the code. This traceability audit should also include verification that all required documentation has been appropriately updated (e.g. training manuals, administration guides, etc.)
Second, so that verification that the modification was performed and functions correctly, and also to ensure that no defects were introduced by the change, there should be a check to ensure that the modified code is testable.
Third, in order to preserve maintainable through conservation of the understandability of the code (i.e. the ability for programmers to easily understand it), there ought to be check to determine that the modified code, particularly any new code that was introduced, conforms to the established coding standards.
Fourth, there ought to be verification that only and all of the software components identified through the impact analysis have been modified. This check ensures that the implementation of the change did not go beyond what was necessary while simultaneously ensuring that all necessary components were changed.
The fifth process suggested is that an effort be made to test the end result of the modification on a compiled and fully integrated system. This involves having the configuration management personnel build/compile a completely integrated version of the modified of the software and performing a series of system tests designed to verify the accuracy of the new functionality.
When possible, IEEE Std. 14764 suggests that a testing be performed by an independent test organization. Conceptually, independent verification and validation (IV&V) is a relatively expensive but highly effective means mitigating project risk. This is particularly true for mission-critical or high-value systems which have extremely low fault tolerances and where often the costs associated with project failure far exceed the costs of purchasing IV&V.
Finally the last process offered is to compile the results of these component activities into a final test report. With regards to seeking final approval and acceptance of the modification, if it was not previously sought before the implementation of the modification, the test report would prove valuable in encapsulating the results of it.
IEEE Std. 14764states that "if was implemented without an agreement, approval should be obtained" (2006, p. 16). This standard suggests that the following activities be performed in support of this.
Reiterating IEEE Std. 12207, IEEE Std. 14764advocates the use of that standard's QA life cycle supporting processes as the framework methodology by which approval should be sought. It continues to suggest that verification that this process has been followed should also be performed (2006).
In addition to this framework, IEEE Std. 14764advocates the seeking of approval by notifying the operators that a delivery package, compiled by the configuration management personnel, is expected at their facility. There, the standard continues, functional and physical configuration ought to be performed during the package's deployment along with providing any necessary training to its operators (2006).
There results of these activities, those being of the fourth category of maintenance process activities offered by IEEE Std. 14764(i.e. Maintenance Review/Acceptance processes) should be a new baseline of the system that incorporates the accepted modifications; a list of any rejected modifications; and acceptance report that illustrates the owner of the systems formal acceptance of the results; al audit and review reports that were created as a result of the aforementioned processes; and a Software Qualification Test Report.
The fifth category of maintenance process activities offered by IEEE Std. 14764is those concerning migration or porting the system to a new platform or environment. In order to accomplish this, the activities described here will support the maintainer in determining the necessary actions to successfully accomplish and guide them through the process of developing and documenting these actions. There are five component sets of activities that comprise the category of software migration processes; they are: the composition of a migration plan, notification of users that the software has been migrated; the implementation of operations and training for those users on the new version of the software; final notification of the user that the software has been migrated; a review of the migration results after they have been completed; and the archival of the old system's data if they version of the software is not to run concurrently with the old version.
In order to begin these processes, a copy of the existing and target (i.e. new) environments/platforms are required, along with the systems baseline that operates on the existing environment. These artifacts are necessary in developing a new migrated or ported version of the software.
There are two corner stone activities that comprise this category: the tasks associated with the establishment of a migration plan and the implementation of it. The composition of a migration plan, supported by input from the users, should consist of the following activities: an analysis of the migration requirements. This is important for three reasons; first, it allows for the determination the scope of the effort; second, it facilitates the traceability necessary to establish a successful porting effort; and third, it permits the completion of an impact analysis that the implementation of the migration requirements will have to the baseline system.
Continuing on, other activities that support the establishment of a migration plan are the establishment of a migration schedule and the identification of the risks associated with the migration. With risks identified, mitigation strategies can be developed whose implementations would be represented in the composed schedule.
In addition to the identifying of risk items and mitigation strategies, the tools necessary support the migration effort should be identified; this should include the any tools which must custom-developed. The acquisition and/or development of these tools should also be in performed.
Since often the migration of a software platform must be performed in parallel with the support of the existing system the resources required to support the existing system need to be determined, acquired, and assembled.
In the development of a migration plan, IEEE Std. 14764also suggests that the system to be migrated should be "incrementally decomposed" (2006, p. 18) of the data and software component items to be converted and a priority be assigned to each. The prioritization of itemized components and data to be ported will comprise a significant portion of the migration schedule's content.
After composing a migration plan and orchestrating schedule by which the software components and data items will be migrated, the next set of activities are associated with the implementation of that plan. As such, IEEE Std. 14764suggests that this should include: providing support for the existing system while the migration plan is implemented; converting the components on the schedule agreed; and concluding the effort by verifying the migration to the new environment is successful through conducting tests (2006).
In order to give the users a means to prepare, IEEE Std. 14764offers guidance on notification of the user that the software has been or will be ported to the new environment. In accordance with IEEE Std. 12207, this guidance includes providing a statement of why this effort is being performed and if the old platform will no longer be supported. This is particularly important if the second part of that is true (i.e. that the old version will be discontinued). This statement should include any pertinent dates, specifically when the new version will be available and, if that is the intent, when the old version will be retired or no longer supported (2006). If the intent is to discontinue the old version, this statement should also include information pertaining to when support for the old version will be suspended, if at all.
In addition to the preparation of this notification statement, all the affected users and/or locations should be identified along with issues that may be site or user group-specific. Plan should also be made on how feedback from the affected users/sites will be processes.
The next subset of activities associated with the migration of software pertains to the implementation of operations and training for those users affected by the new version of the software. These activities include performing a site survey; installation of the equipment necessary to run the new version of the software at those sites along with the software itself. Tests to verify the successful completion of these installation efforts should also be conducted. When possible and appropriate, the production use of the new version of the system ought to run in parallel with the operation of the existing (i.e. old). This will serve to mitigate the risk of turning off the old system before confidence has been established that the new version is working as expected. In order to establish that confidence, IEEE Std. 14764suggests that "data reduction and analysis" (2006, p. 19) be performed along with the collection of data from both the new and old versions of the system, if they are running in parallel. Doing this will serve to pain the difficulties associated with the eventual cut-over to the new version.
In preparation of and with regards to the training the users on the new version of the system, IEEE Std. 14764advocated that the initial migration training requirements be preliminarily identified, scheduled for implementation, and a review be conducted on the results on the provided training. This will provide an opportunity to validate that they were sufficiently conducted; the definition of which, should be that the user have been given all the necessary information in order to operate the new version of the system once it has been released (2006).
With the software system migrated to the target platform completed and its success verified, final notification should be provided to the users that the new version of the system is ready for full-production use. This is the next subset of processes offered IEEE Std. 14764, those concerning informing the user community of the readiness of the migrated software system. In addition to actually preparing and sending the notification, supporting activities of this subset include the archival of the old software system implementations, particularly any production data that has been produced through their use (2006). Additional information regarding the activities that support the archival of data is discussed later.
In the final notification, any site or user group specific issues should be documented along with any corresponding identified resolutions to them. Concluding this subset of activities is the final switch-off of the old system and the removal of the old equipment.
Following the final switch-off of the old system, now to be considered the legacy system, IEEE Std. 14764advocates that a series of post-operational reviews be conducts in order to assess the impact, if any, of the cut-over to the new system so that this information can be provided to appropriate authorities (2006).
Activities that support this endeavor are the comparative review of the results of operation of the legacy system and its replacement; identification of any potential risks determined by that analysis and any further site specific issues. These identified risk and site specific issues should be documented, along with any lessons-learned from the migration effort.
Introduced briefly during the notification of the completion of the system's migration, the final subset of migration activities are those concerning the necessity to archive the data of the legacy system. Doing so can prove invaluable for several reasons. It provides the means to retrieve of historical data, either for sake of traceability of transactions across the different versions of the system or reasons of auditability; or in the case of the unfortunate circumstances that may warrant it, the complete roll-back of the migrated system to its legacy version. Activities that comprise this category include the storage of the old software and data (2006). A good idea with regards to this is to make multiple copies of the archived data and software and store at least one set of them at a safe off-site location that is geographically distant that the new production one. This ensures that should the existing production site become compromised by disaster, at least one copy of the archived system should be unaffected.
To summarize the results of the migration category of maintenance processes, the output that should result from them include should include, as discussed, a migration plan; the migration tools used to perform it; the notification of intent to migrate the software; the migrated (i.e. new) version of the software system itself; the final notification of the migrations completion; the comparative analysis of the new and legacy systems conducted during the post-operative reviews; and finally, the archived legacy system.
Last, but by no means least significant, the final category of maintenance processes offered by IEEE Std. 14764are those concerning the retirement of the system itself. Often derived through an analysis to determine the economic cost-effectiveness of continuing to operate a system, there are a number of ways in which the end of a software system's can occur. Often the technology used to implement the software has become outdated (i.e. no longer supported) or that here been a shift to new technology offers enough of a long-term cost-advantage to merit replacing the system. Often this long (or even short term) cost-advantage is realized by moving to a system that supports improved modularity, implements an technological standard, or achieve vendor independence driving forces. Lastly, often it end of the system usefulness is the product of it succumbing to software-decay that forces the issue (Bennet & Rajlich, 2000). Regardless of the reasons, when the decision has been made to retire the system, there are a number of activities that should be accomplished to develop and document the steps to bring it to a graceful end.
Similar in organization of those offered by the migration processes, IEEE Std. 14764offers five component sets of activities that comprise the category of software retirement processes; they are: the composition of a retirement plan, notification of the systems users that the software has been slated for retirement; the implementation of parallel operations of the existing system with its replacement; final notification of the users that the system has been retired; and the archival of the existing systems data (2006).
Looking at the structure of the advice listed above, at first glance, it may be easy to assume that because the IEEE Std. 14764process categories associated with the retirement match nearly identically to those of migration processes, a discussion of this category may seem redundant. This is not entirely true. While these two categories of processes do have a considerable amount of cross-over, they should be seen as complimentary; for after all, generally in order to migrate to a new system an old one must exist and vice versa. This behind said though, for sake of eliminating the duplication of material, only the where the guidance regarding retirement is different than migrations process will be discussed.
Retirement processes are dependent on a similar set of inputs in order to facilitate their execution; they include: the old/existing system's software, data and environment; and the new software system intended to replace it.
The first subset of processes for this category concerns the establishment of a retirement plan. With regards to this, IEEE Std. 14764extends the practice offered in ISO\IEC Std. 12207 which advocates that all planning activities include input and participation by the users and operators of the system, whenever appropriate. This should include a determination of the amount of support that will be provided to the users (i.e. full or partial) and the duration that this support will be provided. A plan should also address where the archives of the retired system will reside, the amount of support users and operators may require and who will provide it.
Continuing on with the retirement planning process advocated by IEEE Std. 14764, it advocates that the retirement plan activities should include an analysis of the retirement requirements, to include their itemization and cataloging for sake of establishing artifact traceability; determination of what impact that the system's retirement will have on its users and operators. A retirement plan should include identification of a suitable replacement, if any. Decomposition of work retirement activities should be used to develop a retirement plan schedule (2006).
After composing a retirement plan schedule by which the software components and data items will be migrated, the next set of activities are associated with the implementation of that plan. As such, IEEE Std. 14764suggests that this should include: providing support for the existing system while the migration plan is implemented; converting the components on the schedule agreed; and concluding the effort by verifying the migration to the new environment is successful through conducting tests (2006).
The second category of retirement processes offered by IEEE Std. 14764is regarding the notification of the users of the system's retirement. In accordance with IEEE Std. 12207, this guidance includes providing a statement of why this effort is being performed and if the old platform will no longer be supported. This is particularly important if the second part of that is true (i.e. that the old version will be discontinued). This notification will give an opportunity for them to prepare. This statement should include any pertinent dates, specifically when the new version will be available and, if that is the intent, when the old version will be retired or no longer supported. If the intent is to discontinue the old version, this statement should also include information pertaining to when support for the old version will be suspended, if at all.
The last three categories of retirement processes offered by IEEE Std. 14764(i.e. those regarding the implementation of parallel operations of the existing system with its replacement; final notification of the users that the system has been retired; and the archival of the existing systems data) is has largely been discussed already. The only difference between them is that with regards to the migrated system, the retired system can be supplanted.
The final section of this paper is a summary is on, what IEEE Std. 14764 refers to as, the "Execution Considerations" (2006, p. 24) for designing, planning, and implementing the six maintenance process categories previously discussed.
The first area of concern is regarding the types of maintenance as they relate the types of modifications that will be supported. It suggests that consideration be given to whether the service will provide only corrective maintenance (i.e. those modifications made to remedy actual errors discovered through the operational use of the system) or if also adaptive and/or perfective modifications will be performed (i.e. those that associated with enhancing the software to better meet the needs, or changing needs, of its users.) The current state of the system's architecture integrity will, in part, dictate the constraints in which this decision will be made along with the costs considerations associated with implementing these different types of modification requests.
Building upon the previous concern of the types of modifications that will be provided is consideration for whom will provide them. This is another point offered by IEEE Std. 14764 (2006). It suggests that the maintenance service model should be agree upon in the beginning of the effort and should address and define the maintenance types that will be provided and by whom. Maintenance models can consist of a single internal entity providing all types of support or a have the different maintenance types provided by different entity, of either an internal or external nature. This maintenance agreement should stipulate the terms of the services that will be provided, to duration that support will be provided, by whom, and define the protocols by which the supplier and consumers of the services will interact.
IEEE 14764 offers that "a potential means of containing software maintenance costs is to use CASE tools" (2006, p. 26). Computer-Aided Software Engineering (CASE) tools are those that provide an integrated environment that automates the maintenance methodologies defined and to supports the activities and production of artifacts involved in all aspects of software development and maintenance, especially by the maintenance team. The acquisition of CASE tools enables the functionality that will define the SEE environment, including support for documenting the results of test performed in the STE environment. As such, IEEE Std. 14764 suggests careful consideration be given to the decision of what CASE tools will be used to support the maintenance effort (2006).
For sake of supporting ongoing improvement to maintenance effort efficiency, particularly that of modification efforts, and for sake of supporting the desire to ever improve the ability to accurately estimate the resources and time necessary to implement modifications, IEEE Std. 14764 advocates the use of metrics and the collection empirical data on the results of modification efforts (2006). This empirical data can be used to gain a better understanding of how maintenance team's time is being spent and to glean how improvement to these processes can be made.
In order to ensure that all personnel on the maintenance team are executing the same processes and in the same manner, IEEE Std. 14764 offers that all processes and the execution of processes be documented for sake of validating that they adhere to same established guidelines and so that their quality can be verified.
Perhaps one of the greatest areas of concern in executing the maintenance processes, which is also to say the guiding principal that should govern all maintenance modification efforts, is to how to preserve the overall system's maintainability and defend its architectural integrity from software decay.
Preserving maintainability can be thought of as the preservation of four aspects of the system: the analyzability of the system, which is an indication of how readable and understandable the systems code is for sake of determining how to implement change; its changeably, which is a reference to the ease in which modifications can be implemented; its stability, the degree to which the system is likely to operate without failure due to defects; and the testability of the system, or the ability to validate and verify the modifications of the code (2006).
With regards to the computer language(s) and products used to develop the system, there are a number of significant factors that have implications on these for aspects of maintainability; among them are: the portability, structural and feature flexibility, legibility and stability of the computer language(s); the data structuring possibilities; testing tools available for these products; and the overall availability, and for how long, these tools and skill sets available to use them.
With regards to the system itself, the degree to which the architecture adheres to a logical and componentized separation of concerns, along with adhering to the concepts of limiting unnecessary coupling and promoting functional cohesion will have major implications on the maintainability of the system. Wandering from this principle degrades the ability for the maintenance team to implement clean and logical modifications, which thereby further degrades the overall architectural integrity of the system. This principle is known as software decay and, according to the Staged Model; it is one of the primary reasons why systems are forced into retirement and replaced with new systems. (Bennet & Rajlich, 2000)
The manner in which modifications are implemented can have significant ramifications on preserving maintainability. Coding and testing efforts should be in pursuant of ensuring legibility of the code through adherence to established coding standards and the pursuit of structured and logical code; minimizing and reducing code complexity whenever possible; and utilize techniques and code structures that that promote the traceability of errors. Code inspections and reviews should be performed to identify inefficiencies and incongruence with the structures of other modification implementations. Finally, all documentation should be updated during the development process to ensure traceability of modifications to both their designs and requirements. This principle is vital in support of subsequent verification, validation, and quality assurance efforts, which should be performed to vet and approve the modifications before they are placed into production.
In summary, IEEE Std. 14764, along with a preliminary orientation on the life cycle definitions and processes proposed by IEEE 12207, should be considered fundamental in establishing an understanding of the processes that comprise and are used in the construction of a software maintenance effort.
It defines the approach of establishing a maintenance strategy, initially directed by a maintenance concept that is then used to derive a plan for its fulfillment. IEEE Std. 14764 then provides a decomposition of the six primary categories of maintenance complete with the tasks and activities that are associated with each. The standard then provides contextual guidance on the execution of those processes and provides suggestion on ways in which commonly observed pitfalls can be avoided.
References
Bennet, K., and Rajlich, V. (2000). Staged model for software life cycle. Computer, 33(7), p. 66-71.
IEEE 12207 (2008) and IEEE 12207. (2008). International Standard: Software Engineering - Softare Life Cycle Processes. New York: Internatlional Organization for Standardization and Institute of Electrical and Electronic Engineers.
IEEE 14764 (2008) and IEEE 14764. (2006). International Standard: Software Engineering -- Software Life Cycle Processes -- Software Maintenance. New York: Internatonal Organization for Standardization and Institute of Electrical and Electronic Engineers.
Comments
Anonymous
November 11, 2014
Hi i have read your post and i think it's usefull.Thanks for the sharing this website. it is very useful professional knowledge.Anonymous
November 11, 2014
Thanks for sharing your comment! If your comment doesn't appear right away, please be patient as it may take a few minutes to publish or may require moderation.<a href="www.martechnical.com/.../maintenance-procedure-developmen">Maintenance Procedure</a>