1. A Best Practice Approach for Software Maintenance - Sustaining Critical Capability Paul R. Croll Chair, IEEE Software and Systems Engineering Standards Committee Convener, ISO/IEC JTC1/SC7 WG9 Computer Sciences Corporation pcroll@csc.com 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved

2. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 2 Agenda l The Five Types of Software Maintenance l A Best Practice Approach l Maintenance in the System Life Cycle l Maintenance in the Software Life Cycle l The CMMI  and Maintenance l ISO/IEC 14764 – The International Software Maintenance Standard l IEEE 1219 – The National Software Maintenance Standard l ISO/IEC 14764 / IEEE 1219 Harmonization l Final Thoughts on Software Maintenance

3. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 3 Five Types of Software Maintenance l Corrective Maintenance u Identify and remove defects u Correct actual errors l Perfective Maintenance u Improve performance, dependability, maintainability u Update documentation l Adaptive Maintenance u Adapt to a new/upgraded environment (e.g., hardware, operating system, middleware) u Incorporate new capability l Emergency Maintenance u Unscheduled corrective maintenance (Risks due to reduced testing) l Preventive Maintenance u Identify and detect latent faults u Systems with safety concerns

4. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 4 Two Types of Maintenance Activities – Bug Fixing l Corrective Maintenance u Identify and remove defects u Correct actual errors l Emergency Maintenance u Unscheduled corrective maintenance (Risks due to reduced testing) l Preventive Maintenance u Identify and detect latent faults u Systems with safety concerns

5. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 5 Two Types of Maintenance Activities – Development/Migration l Perfective Maintenance u Improve performance, dependability, maintainability u Update documentation l Adaptive Maintenance u Adapt to a new/upgraded environment (e.g., hardware, operating system, middleware) u Incorporate new capability

6. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 6 A Best Practice Approach for Software Maintenance Look to the CMMI  for Process Capability Expectations Look to Supporting Standards for Process Detail Build or Refine Your Process Architecture Look to Framework Standards for Maintenance Process Objectives

7. How do we know what the objectives and expected outcomes should be for Maintenance? Look to Framework Standards for Maintenance Process Objectives 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved

8. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 8 Maintenance in the System Life Cycle SYSTEM LIFE CYCLE PROJECT ASSESSMENT PROJECT PLANNING PROJECT CONTROL DECISION MAKING RISK MANAGEMENT CONFIGURATION MANAGEMENT INFORMATION MANAGEMENT ENTERPRISE(5) SYSTEM LIFE CYCLE MANAGEMENT RESOURCE MANAGEMENT QUALITY MANAGEMENT ENTERPRISE ENVIRONMENT MANAGEMENT INVESTMENT MANAGEMENT TECHNICAL (11) PROJECT (7) ACQUISITION SUPPLY AGREEMENT (2) TRANSITION STAKEHOLDER REQUIREMENTS DEFINITION REQUIREMENTS ANALYSIS ARCHITECTURAL DESIGN IMPLEMENTATION INTEGRATION VERIFICATION VALIDATION OPERATION MAINTENANCE DISPOSAL (25) Maintenance ISO/IEC 15288 System Life Cycle Processes

9. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 9 ISO/IEC 15288 – Maintenance Process – Purpose l Clause 5.5.11.1 Purpose of the Maintenance Process u The purpose of the Maintenance Process is to sustain the capability of the system to provide a service. u This process monitors the system’s capability to deliver services, records problems for analysis, takes corrective, adaptive, perfective and preventive actions and confirms restored capability. Source: ISO/IEC 15288:2002, © ISO/IEC2002.

10. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 10 ISO/IEC 15288 – Maintenance Process – Purpose Source: ISO/IEC 15288:2002, © ISO/IEC2002. l Sustain the capability of the system to provide a service l Monitor and record problems l Take corrective, adaptive, perfective and preventive actions l Confirm restored capability

11. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 11 ISO/IEC 15288 – Maintenance Process – Expected Outcomes l Clause 5.5.11.2 Maintenance Process Outcomes u As a result of the successful implementation of the Maintenance Process: u a) A maintenance strategy is developed. u b) Maintenance constraints are provided as inputs to requirements. u c) Replacement system elements are made available. u d) Services meeting stakeholder requirements are sustained. u e) The need for corrective design changes is reported. u f) Failure and lifetime data is recorded. Source: ISO/IEC 15288:2002, © ISO/IEC2002.

12. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 12 ISO/IEC 15288 – Maintenance Process – Expected Outcomes Source: ISO/IEC 15288:2002, © ISO/IEC2002. l A maintenance strategy is developed l Maintenance constraints are provided l Replacement system elements are made available l Services are sustained l The need for changes is reported l Failure and lifetime data is recorded

13. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 13 Maintenance in the Software Life Cycle MAINTENANCE Maintenance IEEE/EIA 12207 Software Life Cycle Processes

14. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 14 IEEE/EIA 12207 – Maintenance Process – Purpose l Clause 5.5 Maintenance process u This process is activated when the software product undergoes modifications to code and associated documentation due to a problem or the need for improvement or adaptation The objective is to modify the existing software product while preserving its integrity This process includes the migration and retirement of the software product The process ends with the retirement of the software product u The activities provided in this clause are specific to the Maintenance Process; however, the process may utilize other processes in this International Standard. If the Development Process (5.3) is utilized, the term developer there is interpreted as maintainer Source: IEEE/EIA 12207.0-1996, © IEEE.1998

15. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 15 IEEE/EIA 12207 – Maintenance Process – Purpose Source: IEEE/EIA 12207.0-1996, © IEEE.1998 l Activated when the software product undergoes post-delivery modifications l Modifies the existing software product while preserving its integrity l Includes the migration and retirement of the software product

16. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 16 IEEE/EIA 12207 – Maintenance Process – Expected Outcomes l Appendix G, Clause G.9 Maintenance process u The use of the Maintenance process should achieve the following objectives: a) Define the impact of organization, operations, and interfaces on the existing system in operation; b) Identify and update appropriate life cycle data; c) Develop modified system components with associated documentation and tests that demonstrate that the system requirements are not compromised; d) Migrate system and software upgrades to the user's environment; e) Ensure fielding of new systems or versions does not adversely affect ongoing operations; f) Maintain the capability to resume processing with prior versions. Source: IEEE/EIA 12207.0-1996, © IEEE.1998

17. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 17 IEEE/EIA 12207 – Maintenance Process – Expected Outcomes Source: IEEE/EIA 12207.0-1996, © IEEE.1998 l Defined impact on the existing system in operation l Updated life cycle data l Modified system components l Demonstration that the system requirements are not compromised l Migration of upgrades to the user's environment l No adverse affect ongoing operations l The capability to restore prior versions

18. How do we know what the process capability expectations are for Maintenance? Look to the CMMI  for Process Capability Expectations 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved

19. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 19 Bug Fixing vs. Post-Delivery Development/Migration VERVALTSREQMPI Bug Fixing CAR PPCMPMCRSKM PPQA All Maintenance Post-Delivery Development/ Migration RDREQMTSPI VERVAL ISMSAM

20. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 20 How does the CMMI  Treat Maintenance? l Development u The word “development,” when used in the CMMI Product Suite, implies not only development activities, but also maintenance activities. u Projects that benefit from the best practices of CMMI can focus on maintenance, development, or both. Source: CMMI  -SE/SW/IPPD/SS, V1.1, Continuous Representation, © CMU SEI,2002. The term Maintenance appears in the CMMI 70 times

21. How does the CMMI  map to the consensus-based objectives and expected outcomes for Maintenance? 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved

22. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 22 The CMMI  and System Maintenance – Objectives ISO/IEC 15288 Maintenance Objectives CMMI  Process Areas Monitor the system’s capability to deliver services Record problems for analysis Take corrective, adaptive, perfective and preventive actions Confirm restored capability CMRSKM VERVALCARRSKMVERVALPMC RDTSPIREQMPPQA CMCAR

23. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 23 The CMMI  and System Maintenance – Outcomes ISO/IEC 15288 Maintenance Outcomes CMMI  Process Areas A maintenance strategy is developed Maintenance constraints are provided as inputs to requirements Replacement system elements are made available Services meeting stakeholder requirements are sustained The need for corrective design changes is reported Failure and lifetime data is recorded PPTSRDPIPMCSAMRDRSKMISMPPQACMRSKMCMPPQAPMC

24. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 24 The CMMI  and Software Maintenance – Objectives IEEE/EIA 12207 Maintenance Objectives CMMI  Process Areas Define the impact of organization, operations, and interfaces on the existing system in operation Identify and update life cycle data Develop modified system components with associated documentation and tests that demonstrate that the system requirements are not compromised Migrate system and software upgrades to the user's environment Ensure fielding of new systems or versions does not adversely affect ongoing operations Maintain the capability to resume processing with prior versions TSRSKM CMPPQARDREQMTSPIVERVALRSKMPIVERVALRSKMTSCMPPQACM

25. Where do we find detailed information to help us build or refine processes for Maintenance? Look to Supporting Standards for Process Detail 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved

26. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 26 ISO/IEC 14764 – Maintenance Processes 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6 Clause number

27. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 27 ISO/IEC 14764 – Process Implementation 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6 8.1.2.1 Maintenance plans and procedures The maintainer shall (ISO/IEC 12207 sub-clause 5.5.1.1) develop, document, and execute plans and procedures for conducting the activities and tasks of the Maintenance Process. The Maintenance Plan should document the strategy to be used to maintain the system, while the Maintenance Procedures should provide a more detailed approach on how to actually accomplish the maintenance. In order to develop effective Maintenance Plans and Procedures, the maintainer should perform the following task-steps: a) Assist the acquirer in developing the maintenance concept. b) Assist the acquirer in determining the scope of maintenance. c) Assist the acquirer in analyzing maintenance organization alternatives. d) Ensure written designation as the maintainer for the software product. e) Conduct resource analyses. f) Estimate maintenance costs. g) Perform a maintainability assessment of the system. h) Determine transition requirements. i) Determine transition milestones. j) Identify the maintenance process which will be used. k) Document the maintenance process in the form of operating procedures. 8.1.2.2 MR/PR procedures.

28. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 28 ISO/IEC 14764 – Process Implementation 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6 8.1.2.1 Maintenance plans and procedures The maintainer shall (ISO/IEC 12207 sub-clause 5.5.1.1) develop, document, and execute plans and procedures for conducting the activities and tasks of the Maintenance Process. The Maintenance Plan should document the strategy to be used to maintain the system, while the Maintenance Procedures should provide a more detailed approach on how to actually accomplish the maintenance. In order to develop effective Maintenance Plans and Procedures, the maintainer should perform the following task-steps: a) Assist the acquirer in developing the maintenance concept. b) Assist the acquirer in determining the scope of maintenance. c) Assist the acquirer in analyzing maintenance organization alternatives. d) Ensure written designation as the maintainer for the software product. e) Conduct resource analyses. f) Estimate maintenance costs. g) Perform a maintainability assessment of the system. h) Determine transition requirements. i) Determine transition milestones. j) Identify the maintenance process which will be used. k) Document the maintenance process in the form of operating procedures. 8.1.2.2 MR/PR procedures. 8.1.2.1 Maintenance plans and procedures The maintainer shall develop, document, and execute plans and procedures for conducting the activities and tasks of the Maintenance Process. The Maintenance Plan should document the strategy to be used to maintain the system, while the Maintenance Procedures should provide a more detailed approach on how to actually accomplish the maintenance. In order to develop effective Maintenance Plans and Procedures, the maintainer should perform the following task-steps: a) Assist the acquirer in developing the maintenance concept. b) Assist the acquirer in determining the scope of maintenance. c) Assist the acquirer in analyzing maintenance organization alternatives. d) Ensure written designation as the maintainer for the software product. e) Conduct resource analyses. f) Estimate maintenance costs. g) Perform a maintainability assessment of the system. h) Determine transition requirements. i) Determine transition milestones. j) Identify the maintenance process which will be used. k) Document the maintenance process in the form of operating procedures.

29. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 29 ISO/IEC 14764 – Problem and Modification Analysis 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6

30. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 30 ISO/IEC 14764 – Problem and Modification Analysis 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6 8.2.2.1 MR/PR analysis The maintainer shall analyze the problem report or modification request for its impact on the organization, the existing system, and the interfacing systems for the following: a) Type; for example, corrective, improvement, preventive, or adaptive to new environment; b) Scope; for example, size of modification, cost involved, time to modify; c) Criticality; for example, impact on performance, safety, or security. In order to ensure that the requested MR/PR is feasible, the maintainer should perform the following task-steps: d) Determine if the maintainer is adequately staffed to implement the proposed change. e) Determine if the program is adequately budgeted to implement the proposed change. f) Determine if sufficient resources are available and whether this modification will affect ongoing or projected projects (may not be necessary for PRs). g) Determine the operational issues to be considered. For example, what are the anticipated changes to system interface requirements, the expected useful life of the system, the operational priorities, safety, and security, security impacts, if it is not implemented? (may not be necessary for PRs). h) Determine safety and security implications (may not be necessary for PRs). i) Determine short-term and long-term costs (may not be necessary for PRs). j) Determine the value of the benefit of making the modification. k) Determine the impact on existing schedules. l) Determine the level of test and evaluation required. m) Determine the estimated management cost to implement the change (may not be necessary for PRs).

31. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 31 ISO/IEC 14764 – Modification Implementation 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6

32. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 32 ISO/IEC 14764 – Modification Implementation 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6 8.3.2.1 Analysis Once the MR/PR has been approved, the maintainer shall conduct analysis and determine which documentation, software units, and versions thereof need to be modified. These shall be documented. The results of this additional analysis should be documented in the software development folders (SDFs). This effort includes the following task-steps: a) Identify the elements to be modified in the existing system. b) Identify the interface elements affected by the modification. c) Identify the documentation to be updated. d) Update the SDFs.

33. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 33 ISO/IEC 14764 – Maintenance Review/Acceptance 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6

34. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 34 ISO/IEC 14764 – Maintenance Review/Acceptance 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6 8.4.2.1 Reviews The maintainer shall conduct review(s) with the organization authorizing the modification to determine the integrity of the modified system. The following task-steps should be performed: a) Trace the MR/PR from requirements, to design, to code. b) Verify testability of the code. c) Verify that coding standards were complied with. d) Verify that only necessary software components were modified. e) Verify that the new software components were integrated properly. f) Check documentation to ensure that it was updated. g) Perform testing. h) Develop test report.

35. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 35 ISO/IEC 14764 – Migration 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6

36. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 36 ISO/IEC 14764 – Migration 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6 8.5.2.2 Migration plan In order to adequately control the migration of a system, a migration plan shall be developed, documented and executed. The planning activities shall include users. Items included in the plan shall include the following: a) Requirements analysis and definition of migration; b) Development of migration tools; c) Conversion of software product and data; d) Migration execution; e) Migration verification; f) Support for the old environment in the future. The development of the Migration Plan should include input from the users. As part of this task, the maintainer should perform the following task-steps: a) Analyze the migration requirements. b) Determine the impact of migrating the software product. c) Establish a schedule for performing the migration. d) Identify data collection requirements for post-operation review. e) Define and document the migration effort. f) Determine and mitigate risks. g) Identify needed migration tools. h) Identify support for the old environment. i) Develop and/or acquire migration tools. j) Incrementally decompose software products and data for conversion. k) Prioritize conversion of software products and data. l) Convert software products and data. m) Migrate software products and data to new environment. n) Run parallel operations. o) Verify migration through testing. p) Provide support for old environment.

37. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 37 ISO/IEC 14764 – Retirement 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6

38. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 38 ISO/IEC 14764 – Retirement 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs 8 Maintenance Processes u Inputs u Tasks u Controls u Support u Outputs Source: ISO/IEC 14764:1999, © ISO/IEC1999. Process Implementation 8.1 Problem and Modification Analysis 8.2 Maintenance Review/ Acceptance 8.4 Modification Implementation 8.3 Migration 8.5 Retirement 8.6 8.6.2.1 Retirement plan A retirement plan to remove active support by the operation and maintenance organizations shall be developed and documented. The planning activities shall include users. The plan shall address the items listed below. The plan shall be executed. a) Cessation of full or partial support after a certain period of time; b) Archiving of the software product and its associated documentation; c) Responsibility for any future residual support issues; d) Transition to the new software product, if applicable; e) Accessibility of archive copies of data. As part of this task, the maintainer should perform the following task-steps: a) Analyze the retirement requirements. b) Determine the impact of retiring the software product. c) Identify replacement software product, if any. d) Establish a schedule for retiring the software product. e) Identify the responsibility for any future residual support. f) Define and document the retirement effort.

39. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 39 IEEE 1219 – Maintenance Processes Process Associated Processes OutputInput Control 4.3 Design 4.4 Implementation 4.5 Regression/system testing 4.6 Acceptance testing 4.7 Delivery 4.1 Problem/modification identification, classification, and prioritization 4.2 Analysis Source: IEEE 1219-1998, © IEEE, 1998. Clause number

40. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 40 Process Associated Processes Output Input Control 4.3 Design 4.4 Implementation 4.5 Regression/system testing 4.6 Acceptance testing 4.7 Delivery 4.1 Problem/modification identification, classification, and prioritization 4.2 Analysis IEEE 1219 – Process Inputs 4.2.1 Input The input to the analysis phase of the maintenance process shall include the following: a) Validated MR; b) Initial resource estimate and other repository information; c) Project and system documentation, if available. Source: IEEE 1219-1998, © IEEE, 1998.

41. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 41 Process Associated Processes OutputInput Control 4.3 Design 4.4 Implementation 4.5 Regression/system testing 4.6 Acceptance testing 4.7 Delivery 4.1 Problem/modification identification, classification, and prioritization 4.2 Analysis IEEE 1219 – Process Requirements 4.3.2 Process The process steps for design shall include the following: a) Identify affected software modules; b) Modify software module documentation [e.g., data and control flow diagrams, schematics, program design language (PDL), etc.]; c) Create test cases for the new design, including safety and security issues (for guidance, see also A.9 and A.10); d) Identify/create regression tests; e) Identify documentation (system/user) update requirements; f) Update modification list. Source: IEEE 1219-1998, © IEEE, 1998.

42. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 42 Process Associated Processes OutputInput Control 4.3 Design 4.4 Implementation 4.5 Regression/system testing 4.6 Acceptance testing 4.7 Delivery 4.1 Problem/modification identification, classification, and prioritization 4.2 Analysis IEEE 1219 – Process Controls 4.4.3 Control The control of implementation shall include the following: a) Conduct software inspections of the code in compliance with IEEE Std 1028-1997. b) Ensure that unit and integration testing are performed and documented in a software development folder. c) Ensure that test documentation (e.g., test plan, test cases, and test procedures) are either updated or created. d) Identify, document, and resolve any risks exposed during software and test-readiness reviews. e) Verify that the new software is placed under SCM control. f) Verify that the training and technical documentation have been updated. g) Verify the traceability of the design to the code. Source: IEEE 1219-1998, © IEEE, 1998.

43. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 43 Process Associated Processes Output Input Control 4.3 Design 4.4 Implementation 4.5 Regression/system testing 4.6 Acceptance testing 4.7 Delivery 4.1 Problem/modification identification, classification, and prioritization 4.2 Analysis IEEE 1219 – Process Outputs 4.5.4 Output The output for this phase of maintenance shall include the following: a) Tested and fully integrated system; b) Test report; c) Test-readiness review report. Source: IEEE 1219-1998, © IEEE, 1998.

44. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 44 Process Associated Processes OutputInput Control 4.3 Design 4.4 Implementation 4.5 Regression/system testing 4.6 Acceptance testing 4.7 Delivery 4.1 Problem/modification identification, classification, and prioritization 4.2 Analysis IEEE 1219 – Associated Processes (Internal) 4.6.3 Control Control of acceptance tests shall include the following: a) Execute acceptance tests; b) Report test results for the functional configuration audit (FCA); c) Conduct functional audit; d) Establish the new system baseline; e) Place the acceptance test documentation under SCM control. Consult A.6, A.7, and A.11.2 for guidance on activities related to V&V, SQA, and SCM. Source: IEEE 1219-1998, © IEEE, 1998.

45. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 45 Process Associated Processes OutputInput Control 4.3 Design 4.4 Implementation 4.5 Regression/system testing 4.6 Acceptance testing 4.7 Delivery 4.1 Problem/modification identification, classification, and prioritization 4.2 Analysis IEEE 1219 – Associated Processes (External) 4.7.3 Control Control for delivery shall include the following: a) Arrange and document a PCA; b) Provide system materials for access to users, including replication and distribution; c) Complete the version description document (VDD) (IEEE Std 1042-1987); d) Complete updates to status accounting database; e) Place contents of the delivery under SCM control. Consult A.6, A.7, and A.11.2 for guidance on activities related to V&V, SQA, and SCM. 4.7.4 Output Output for delivery shall include the following: a) PCA report (IEEE Std 1028-1997); b) VDD. Source: IEEE 1219-1998, © IEEE, 1998.

46. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 46 IEEE 1219 – Annexes l Annex A (informative) Maintenance guidelines l Annex B (informative) Supporting Maintenance Technology u Re-engineering u Reverse engineering u Holistic reusing (i.e., cloning of a “new” system from a parent system) u Software tools l Annex C (normative) Maintenance Plan Guidelines l Annex D (informative) Guidelines For Compliance With IEEE/EIA 12207.1-1997 Source: IEEE 1219-1998, © IEEE, 1998.

47. How are these Standards being harmonized to be consistent and complimentary? 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved

48. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 48 ISO/IEC14764 / IEEE 1219 Harmonization - Differences ISO/IEC 14764 1.Process Implementation 2.Problem and modification analysis 3.Modification implementation 4.Maintenance review/acceptance 5.Migration 6.Software retirement IEEE STD 1219 1.Problem identification 2.Analysis 3.Design 4.Implementation 5.System test 6.Acceptance test 7.Delivery The Standards Have Different Process Models

49. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 49 ISO/IEC14764 / IEEE 1219 Harmonization Approach l Assumptions u Use the ISO/IEC 14764 process model as the basic structure u Fold IEEE Std 1219 into the 14764 structure l Approach u Include relevant IEEE Std 1219 normative material in the document body u Include relevant IEEE Std 1219 informative material in annexes to the document Create Two Standards With Identical Normative Content

50. Some Final Thoughts on Software Maintenance Build or Refine Your Process Architecture 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved

51. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 51 Software Maintenance is Different Than Software Development l Establish the maintenance process u Develop maintenance plans and procedures u Establish MR/PR procedures u Implement configuration management l Perform problem/modification analysis u Analyse MRs/PRs u Replicate or verify the problem u Develop options for implementing the modification u Document the MR/PR, the results, and implementation options u Obtain approval for the selected modification option l Develop and test the modification l Verify and validate the modification Source: ISO/IEC 14764:1999, © ISO/IEC1999.

52. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 52 A Best Practice Approach for Software Maintenance Look to the CMMI  for Process Capability Expectations Look to Supporting Standards for Process Detail Build or Refine Your Process Architecture Look to Framework Standards for Maintenance Process Objectives

53. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 53 For More Information... Paul R. Croll Computer Sciences Corporation 5166 Potomac Drive King George, VA 22485-5824 Phone:+1 540.644.6224 Fax:+1 540.663.0276 e-mail:pcroll@csc.com For IEEE Standards: http://computer.org/standards/sesc/ http://computer.org/cspress/CATALOG/st01110.htm For ISO/IEC Standards: http://saturne.info.uqam.ca/Labo_Recherche/Lrgl/sc7/

54. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 54 References CMMI  -SE/SW/IPPD/SS, V1.1, CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development, and Supplier Sourcing Version 1.1, CMMI  -SE/SW/IPPD/SS, V1.1, Continuous Representation. CMU/SEI-CMU/SEI-2002-TR-011, ESC-TR-2002-011, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, PA, March 2002. IEEE Standard 1219-1998, IEEE Standard for Software Maintenance, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998. IEEE/EIA Standard 12207.0-1996, Industry Implementation of International Standard ISO/IEC12207:1995 — (ISO/IEC 12207) Standard for Information Technology —Software life cycle processes, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998

55. 16 th Annual Systems and Software Technology Conference – Track 6, IEEE Sponsored Track – 20 April 2004, 1355-1440 Copyright 2004, Paul R. Croll, All rights reserved Paul R. Croll - 55 References - 2 Introduction to CMMI – Continuous V 1.1, Carnegie Mellon University, 2002-2003 ISO/IEC 14764-1999, Software Engineering — Software Maintenance, ISO/IEC JTC1/SC7, 1999. ISO/IEC 15288:2002, Systems Engineering — System Life Cycle Processes, ISO/IEC JTC1/SC7, 2002. [Singh97] Raghu Singh, An Introduction to International Standards ISO/IEC 12207, Software Life Cycle Processes, 1997.