1. Software Maintenance and Evolution JMSE-SM&E Unit 5: Maintenance Process and Standards
Prof. Mohammad A. Mikki
Gaza, Palestine,

2. Course Title: Software Maintenance and Evolution
Unit 5: Maintenance Process and Standards

3. Introduction
This unit presents software maintenance process and standards. It first introduces the topic of standards in software engineering. It provides the definition of a standard, the motivation for standards, the advantages and benefits of using standards, the aproblems with standards. The unit then presents the different standards organizations that works in the field of software maintenance in particular, and software engineering in general. The unit explains the portfolio of ISO software and systems engineering standards and the relationships between systems engineering and software engineering ISO/IEC standards.
Later unit presents several of these standards in some detail. Mainly, the unit presents:
ISO/IEC IEEE standard which describes s/w maintenance as an iterative process for managing and executing software maintenance activities
IEEE/EIA Standard 1074:1997
ISO/IEC standard for software life-cycle processes w.r.t software evolution. It is a standard for information technology-software life cycle processes-Maintenance processes.
IEEE/EIA 1219 standard for software maintenance. It organizes the maintenance process in seven phases
IEEE
Both IEEE/EIA 1219 and ISO/IEC are part of ISO/IEC Standards which focus on maintenance processes are IEEE Std and ISO 14764: 1998 xx

4. Objectives/ILOs By the end of this unit, a student should be able:
ILO 1: Define standards
ILO 2: Present the advantages and disadvantages of standards
ILO 3: Explain why software engineering standards were developed
ILO 4: Explain the portfolio of ISO software and systems engineering standards and the relationships between various standards organizations
ILO 5: Understand ISO/IEC IEEE Standard 14764
ILO 6: Understand IEEE/EIA Standard 1074:1997
LIO 7: Explain ISO/IEC Standard for Information Technology-software life cycle processes-Maintenance processes
ILO 8: Explain IEEE/EIA 1219: Standard for Software Maintenance. It organizes the maintenance process in seven phases
ILO 9: Explain IEEE standard
To explain the importance of software change management
To describe key change management activities - planning, change management, version management and system building
To discuss the use of CASE tools to support change management processes

5. Unit 5: List of Topics Topic 1: Introduction
Topic 2: Software Maintenance Standards
Topic 3: Maintenance in the System Life Cycle
Topic 4: ISO/IEC IEEE Standard 14764: describes s/w maintenance as an iterative process for managing and executing software maintenance activities
Topic 5: IEEE/EIA Standard 1074:1997
Topic 6: ISO/IEC 12207: Standard for Information Technology-software life cycle processes-Maintenance processes
Topic 7: IEEE/EIA 1219: Standard for Software Maintenance. It organizes the maintenance process in seven phases
Topic 8: IEEE

6. Definition of standard
Topic 1: Introduction
Definition of standard
A standard is a technical specification or other document available to the public, drawn up with the cooperation and consensus or general approval of all interests affected by it, based on the consolidated results of science, technology and experience, aimed at the promotion of optimum community benefits.

7. Software engineering standard
Topic 1: Introduction
Software engineering standard
Software engineering standard addresses:
guidelines for process
guidelines for techniques
few guidelines for product evaluation

8. Why software engineering standards?
Topic 1: Introduction
Why software engineering standards?
Standards are maturing and gaining acceptance in many companies
Standards emphasize communication and shared understanding
Communication and shared understanding is also important in both global development environment and small group working in the same office might that might have difficulties in communication and understanding of shared issues
Standards can help in institutions and enterprises to make the business more profitable because less time is spent on non- productive work
Establish uniform requirements for development and documentation
Define a common framework for software life cycle processes
Clarify the roles and interfaces of participants
Clarify the types and contents of documentation
Identify the tasks, phases, baselines, reviews, and documents needed

9. Why software engineering standards?
Topic 1: Introduction
Why software engineering standards?
Encapsulate best practice and avoid repetition of past mistakes
Ensure quality of processes through checking standard compliance
Provide continuity where new staff can understand the organisation by understanding standards used

10. Benefits of standards to business
Topic 1: Introduction
Benefits of standards to business
Improved management of software
Schedules and budgets are more likely to be met
Quality goals are likely to be reached
Employee training and turnover can be managed
Visible certification can attract new customers or be required by existing ones
Partnerships and co-development, particularly in a global environment, are enhanced
Develop new markets
Influence industry evolution
Structure regional/international competition 10 10

11. Benefits of standards to business
Topic 1: Introduction
Benefits of standards to business
Better regulation
- Customer assurance
- Reduced product liability
- Enhanced governance
Reduced cost
- Reduced transaction costs
- Product/process interoperability
Increased Revenue
Improve speed to market
Product acceptance
Product life cycle management 11 11

12. Problems with standards
Topic 1: Introduction
Problems with standards
majority of small software organizations do not adopt existing standards
Very Small Enterprises (VSEs) find it difficult to relate standards to their business needs and to justify the application of the international standards in their operations
Standards are seen as orientated towards large organizations.

13. Topic 1: Introduction How standards look? like a shopping checklist
Remind you of things you may forget
Force you to acknowledge the consequences of not doing one of the tasks on the standard
Don’t build the list from scratch: use one built by hundreds or thousands of professionals

14. Standards organizations
Topic 2: Software Maintenance Standards
Standards organizations
IEEE (Institute of Electrical and Electronics Engineers)
ISO (International Organization for Standardization)
IEC (International Electrotechnical Commission): is the international standards and conformity assessment body for all fields of electrotechnology
ANSI (American National Standards Institute)
US DoD (US Department of Defense)

15. IEEE Software and Systems Engineering Standards Committee (S2ESC)
Topic 2: Software Maintenance Standards
IEEE Software and Systems Engineering Standards Committee (S2ESC)
Terms of Reference
Codify the norms of professional software engineering practices into standards. Promote use of software engineering standards among clients, practitioners, and educators. Harmonize national and international software engineering standards development
Forty+ Standards in Software and Systems Engineering

16. Topic 2: Software Maintenance Standards
IEEE Software and Systems Engineering Standards Committee (S2ESC)- Projects
730 Std for Software Quality Assurance Planning
829 Std for Software Test Documentation
1012 Std for Software Verification and Validation
1016 RP for Software Design Descriptions
1028 Std for Software Reviews
1044 Std Classification for Software Anomalies

17. Topic 2: Software Maintenance Standards
IEEE Software and Systems Engineering Standards Committee (S2ESC)- Projects
1045 Std for Software Productivity Metrics
Guide for CASE Tool Interconnections - Reference Model for Specifying System Behavior
Guide for CASE Tool Interconnections - Syntax for Transferring Behavior Specifications
1648 RP for Establishing and Managing Software Development Efforts Using Agile Methods
Industry Implementation of International Standard ISO/IEC 12207:1995 Standard for Information Technology- Software life cycle processes – Software Life Cycle Processes
15026 System and Software Engineering – System and Software Assurance

18. Topic 2: Software Maintenance Standards
IEEE Software and Systems Engineering Standards Committee (S2ESC)- Projects
15289 Industry Implementation of International Standard ISO/IEC :1995 Standard for Information Technology-Software life cycle processes – Software Life Cycle Processes- life cycle data
16326 Information Technology - Software Engineering - Software Project Management
Std for Service Management - Part 1: Specification (IEEE adoption of ISO/IEC :2005)
Std for Service Management - Part 2: Code of Practice (IEEE adoption of ISO/IEC :2005) Information Technology-Software Packages – Quality Requirements and Testing
90003 Software and Systems Engineering - Guidelines for the Application of ISO 9001:2000 to Computer Software

19. Topic 2: Software Maintenance Standards
IEEE Software and Systems Engineering Standards Committee (S2ESC)- Standards Published in 2006
IEEE Standard Dictionary of Measures of the Software Aspects of Dependability
IEEE Standard for Developing a Software Project Life Cycle Process
IEEE Recommended Practice for CASE Tool Interconnection-Characterization of Interconnections
14764:2006 (E) ISO/IEC Standard for Software Engineering— Software Life Cycle Processes—Maintenance
16085: 2006 Systems and software engineering-Life cycle processes-Risk management
23026: 2006 Software Engineering---Recommended Practice for the Internet---Web Site Engineering, Web Site Management, and Web Site Life Cycle

20. Topic 2: Software Maintenance Standards
Borrowed from: www

21. Software engineering standards tree
Topic 2: Software Maintenance Standards
Software engineering standards tree
ISO/IEC “Software Life Cycle Processes” Aug 95
DOD-STD-2167A “Defense System Software Development” Feb 88
2167A
7935A
498
ISO 12207
IEEE Stds
IEEE/EIA 12207
016
Animation - figures and text fly in from left automatically
This shows that 2167A and 7935A were combined and replaced by 498; 498 became the basis for J-STD-016 (along with portions of ISO 12207)
IEEE includes all of ISO and good parts of 016 (=498)
MIL-STD-498
“Software Development and Documentation” Dec 94
J-STD
(Trial Use)
“Software Life Cycle Processes, Software Development” Sep 95
IEEE/EIA
IEEE/EIA
IEEE/EIA
“Software Life Cycle Processes”
Mar/Apr 98
DOD-STD-7935A “DoD Automated Information Systems (AIS) Documentation Standards” Oct 88
Borrowed from: www

22. Software engineering standards tree
Topic 2: Software Maintenance Standards
Software engineering standards tree
The multitude of standards and maturity models sometimes appears as a quagmire... The software development industry is being overwhelmed with a proliferation of standards and maturity models. The Software Productivity Consortium has studied those frameworks that are relevant to companies building software-intensive systems. The results of this research are documented in the paper, "The Frameworks Quagmire, A Brief Look," and are presented here in this graphic.
In addition, a Compliance Frameworks Comparison Course that describes the relationships, similarities, and differences among maturity models, technical and quality standards, and contractor selection vehicles, is available to Consortium members.
The colors of the frameworks names indicate the category or source of the framework:
Color Meaning of color
Red A Capability Maturity Model
Green A U.S. Government or military document
Purple An international standard
Blue Developed by a professional organization (mostly U.S.)
Black Other
From the SPC’s
Borrowed from: www

23. The evolution of standards affecting DoD software development
Topic 2: Software Maintenance Standards
The evolution of standards affecting DoD software development
MIL-STD-1679A Software Development 1983
DOD-STD-2167A Defense System Software Development 1988
DOD-STD-7935A AIS Documentation Standards 1988
MIL-STD-498 Software Development and Documentation ISO (series - on Quality Management, etc.) 1991-
J-STD Software Development Acquirer-Supplier Agreement
ISO/IEC Information Technology - Software Life Cycle Processes
IEEE/EIA Software Life Cycle Processes 1998
Animation - text rolls down automatically
In contrast to the many documents on last viewgraph - these are the ones we will cover in this session.
Even if superseded - some standards live forever (story of US rail lines at 4’ 8.5” apart, based on British rail, British trams, British carriages, all European roads built by Romans, Roman chariot wheel width based on width of two horses rear ends)
Borrowed from: www

24. Topic 3: Maintenance in the System Life Cycle
ISO/IEC system life cycle processes
SYSTEM LIFE CYCLE
PROJECT ASSESSMENT
PROJECT PLANNING
PROJECT CONTROL
DECISION MAKING
RISK MANAGEMENT
CONFIGURATION MANAGEMENT
INFORMATION MANAGEMENT
ENTERPRISE
SYSTEM LIFE CYCLE MANAGEMENT
RESOURCE MANAGEMENT
QUALITY MANAGEMENT
ENTERPRISE ENVIRONMENT MANAGEMENT
INVESTMENT MANAGEMENT
TECHNICAL
PROJECT
ACQUISITION
SUPPLY
AGREEMENT
TRANSITION
STAKEHOLDER REQUIREMENTS DEFINITION
REQUIREMENTS ANALYSIS
ARCHITECTURAL DESIGN
IMPLEMENTATION
INTEGRATION
VERIFICATION
VALIDATION
OPERATION
MAINTENANCE
DISPOSAL
Animation - figures and text fly in from left automatically
This shows that 2167A and 7935A were combined and replaced by 498; 498 became the basis for J-STD-016 (along with portions of ISO 12207)
IEEE includes all of ISO and good parts of 016 (=498)
Borrowed from: www

25. Topic 3: Maintenance in the System Life Cycle
IEEE system life cycle processes
SOFTWARE LIFE CYCLE
TAILORING
CONFIGURATION MANAGEMENT
DOCUMENTATION
QUALITY ASSURANCE
VERIFICATION
VALIDATION
JOINT REVIEW
AUDIT
PROBLEM RESOLUTION
PRIMARY
DEVELOPMENT
OPERATION
ACQUISITION
SUPPLY
ORGANIZATIONAL
MANAGEMENT
INFRASTRUCTURE
IMPROVEMENT
TRAINING
SUPPORTING
Bug fixing = preventive, corrective, emergency
Post delivery = perfective
Development or migration = adaptive

26. Topic 4: ISO/IEC IEEE Std. 14764-2006
History
The first edition of ISO/IEC was prepared by ISO/IEC JTC 1/SC 7.
The current edition is the result of merging the original edition with IEEE Std
ISO/IEC JTC 1/SC 7 and the IEEE Computer Society cooperated in this project to merge the two standards. This second edition cancels and replaces the first edition(1999).

27. Topic 4: ISO/IEC IEEE Std. 14764-2006
Overview
This International Standard describes in greater detail management of the Maintenance Process described in ISO/IEC 12207, including Amendments.
This International Standard also establishes definitions for the various types of maintenance.
This International Standard provides guidance that applies to planning, execution and control, review and evaluation, and closure of the Maintenance Process.
The scope of this International Standard includes maintenance for multiple software products with the same maintenance resources. “Maintenance” in this International Standard means software maintenance unless otherwise stated.

28. Topic 4: ISO/IEC IEEE Std. 14764-2006
Objective
Standard focuses on maintenance processes
ISO/IEC 14764:2006 describes in greater detail management of the Maintenance Process described in ISO/IEC 12207, including Amendments.
It also establishes definitions for the various types of maintenance.
ISO/IEC 14764:2006 provides guidance that applies to planning, execution and control, review and evaluation, and closure of the Maintenance Process.
The scope of ISO/IEC 14764:2006 includes maintenance for multiple software products with the same maintenance resources.
"Maintenance" in ISO/IEC 14764:2006 means software maintenance unless otherwise stated.

29. Topic 4: ISO/IEC IEEE Std. 14764-2006
Objective
Provides the framework within which generic and specific software maintenance plans may be executed, evaluated, and tailored to the maintenance scope and magnitude of given software products.
Provides the framework, precise terminology and processes to allow the consistent application of technology (tools, techniques and methods) to software maintenance.
Provides guidance for the maintenance of software.
The basis for the Maintenance Process and its activities comes from the definitions of ISO/IEC It defines the activities and tasks of software maintenance, and provides maintenance planning requirements.
ISO/IEC 14764:2006 is written primarily for maintainers of software and additionally for those responsible for development and quality assurance. It may also be used by acquirers and users of systems containing software who may provide inputs to the maintenance plan.

30. Software Engineering — Software Life Cycle Processes — Maintenance
Topic 4: ISO/IEC IEEE Std
Software Engineering — Software Life Cycle Processes — Maintenance
5 Maintenance Processes
5.1 Process Implementation
5.1.4 Support The Process Implementation activity uses the following supporting life cycle processes of ISO/IEC 12207:
Quality Assurance Process;
5.2 Problem and Modification Analysis
5.2.4 Support The Process Implementation activity uses the following supporting life cycle processes of ISO/IEC 12207:
5.3 Modification Implementation
5.3.4 Support The Process Implementation activity uses the following supporting life cycle processes of ISO/IEC 12207:
5.4 Maintenance Review/Acceptance
5.4.4 Support The Process Implementation activity uses the following supporting life cycle processes of ISO/IEC 12207:
Quality Assurance Process;
5.5 Migration
5.5.4 Support The Process Implementation activity uses the following supporting life cycle processes of ISO/IEC 12207:
5.6 Software retirement
5.6.4 Support The Process Implementation activity uses the following supporting life cycle processes of ISO/IEC 12207:

31. Software Engineering — Software Life Cycle Processes — Maintenance
Topic 4: ISO/IEC IEEE Std
Software Engineering — Software Life Cycle Processes — Maintenance
6 Execution considerations
6.8 Maintainability
Software requirements analysis
The software specifications should exhaustively and unambiguously describe the maintainability requirements of the software. These should be included in the quality characteristics specifications required by ISO/IEC The following aspects affect maintainability and should be considered:
The identification and definition of functions, particularly optional functions;
The accuracy and logical organization of data;
Interfaces (machine and users), particularly future interfaces;
The performance requirements, including the effects of any corrections and additions;
Requirements imposed by the planned environment including scalability requirements and projected system growth;
The granularity of requirements as it impacts the ease or difficulty of traceability;
The Software Quality Assurance Plan which should emphasize documentation and its compliance

32. Categories of maintenance in ISO/IEC 14764
Topic 4: ISO/IEC IEEE Std
Categories of maintenance in ISO/IEC 14764
ISO/IEC defines:
Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems.
Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.
Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability.
Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.

33. Topic 4: ISO/IEC IEEE Std. 14764-2006
Comparison with IEEE 12207
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 (2008):
Acquisition
Supply
Development
Operation, and
Maintenance
IEEE 14764, International Standard: Software Engineering - Software Life Cycle Processes - Maintenance (2006), offers expanded guidance on the processes that comprise the Maintenance category defined in IEEE Std It is not intended to replace the guidance offered in IEEE Std but rather builds upon and is intended to be a supplement to it.

34. Defining maintenance strategy
Topic 4: ISO/IEC IEEE Std
Defining maintenance strategy
Std stresses the importance of formulating and composing a maintenance strategy.
IEEE Std defines a maintenance strategy as, "the strategy [that] prepares for the human and material resources required to provide software maintenance for software products".
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
Establishes the spirit and objectives by which all subsequent and component maintenance planning efforts will be defined.
preliminary definition of a maintenance concept, which defines 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 
Analysis of the estimated resources and costs associated with the implementation of the plan.

35. Maintenance process categories
Topic 4: ISO/IEC IEEE Std
Maintenance process categories
Six maintenance process categories:
Process implementation
Problem and modification analysis
Modification implementation
Maintenance review/acceptance
Migration
Retirement
Each of these maintenance process category is made up of activities and tasks.
Each activity/task describes a specific action with inputs and outputs.

36. Topic 4: ISO/IEC IEEE Std. 14764-2006
Figure: An overview of the Maintenance Process

37. 1. Process implementation
Topic 4: ISO/IEC IEEE Std
1. Process implementation
During Process Implementation, the maintainer establishes the plans and procedures which are to be executed during the Maintenance Process.
The Maintenance Plan (see sub-clause of this International Standard) should be developed in parallel with the Development Plan.
The maintainer should also establish needed organizational interfaces during this activity.

38. 1. Process implementation - Inputs
Topic 4: ISO/IEC IEEE Std
1. Process implementation - Inputs
The inputs for the Process Implementation activity should include:
⎯ Relevant baselines
⎯ System documentation, if available
⎯ A Modification Request (MR) or Problem Report (PR), if applicable

39. 1. Process implementation - tasks
Topic 4: ISO/IEC IEEE Std
1. Process implementation - tasks
In order to effectively implement the Maintenance Process, the maintainer should develop and document a strategy for performing the maintenance.
To accomplish this effort, the maintainer must execute the following tasks:
⎯ Develop Maintenance Plans and Procedures;
⎯ Establish MR/PR Procedures;
⎯ Implement Configuration Management;
⎯ Develop a Configuration Management Plan, (may not be necessary for MRs/PRs).

40. 1. Process implementation- Modification Request (MR)
Topic 4: ISO/IEC IEEE Std
1. Process implementation- Modification Request (MR)
MR is a generic term used to identify proposed modifications to a software product that is being maintained
NOTE—The MR may later be classified as a correction or enhancement and identified as corrective, preventive, adaptive, or perfective maintenance. MRs are also referred to as change requests.
Figure: Modification Request

41. 1. Process implementation- Problem Report (PR)
Topic 4: ISO/IEC IEEE Std
1. Process implementation- Problem Report (PR)
PR is a term used to identify and describe problems detected in a software product
NOTE—PRs are either submitted directly to denote faults or established after impact analysis is performed on Modification Requests and faults are found.

42. 1. Process implementation- MR/PR procedures
Topic 4: ISO/IEC IEEE Std
1. Process implementation- MR/PR procedures
The maintainer shall establish procedures for
receiving,
recording, and
tracking
problem reports and modification requests from the users and providing feedback to the users.
Whenever problems are encountered, they shall be recorded and entered into the Problem Resolution Process.

43. 1. Process implementation - Outputs
Topic 4: ISO/IEC IEEE Std
1. Process implementation - Outputs
The outputs of this activity are:
⎯ The Maintenance Plan
⎯ Training Plan
⎯ Maintenance Procedures
⎯ Project Management Plan
⎯ Problem Resolution Procedures
⎯ Measurement Plan
⎯ Maintenance Manual
⎯ Plans for User Feedback
⎯ The Transition Plan
⎯ Maintainability Assessment
⎯ Configuration Management Plan
All outputs should be placed under configuration management.

44. 2. Problem and modification analysis
Topic 4: ISO/IEC IEEE Std
2. Problem and modification analysis
This and subsequent activities are activated after the software transition and are called iteratively when the need for modification arises.
During the Problem and Modification Analysis Activity, the maintainer:
⎯ Analyzes MRs/PRs
⎯ Replicates or verifies the problem
⎯ Develops options for implementing the modification
⎯ Documents the MR/PR, the results, and execution options
⎯ Obtains approval for the selected modification option
Input for the Problem and Modification Analysis activity should be a validated Modification
Request or Problem Report, system/project documentation, and requirements documentation.

45. 2. Problem and modification analysis - Inputs
Topic 4: ISO/IEC IEEE Std
2. Problem and modification analysis - Inputs
The inputs for the Problem and Modification Analysis activity should be:
⎯ MR/PR
⎯ Baseline
⎯ Software repository
⎯ System documentation

46. 2. Problem and modification analysis -tasks
Topic 4: ISO/IEC IEEE Std
2. Problem and modification analysis -tasks
Before modifying the system, the maintainer should analyze the MR/PR to:
determine its impact on the organization, the existing system, and the interfacing systems
develop and document recommended potential solutions
obtain approval to implement the desired solution

47. 2. Problem and modification analysis- output
Topic 4: ISO/IEC IEEE Std
2. Problem and modification analysis- output
The outputs of this activity are:
⎯ Impact analysis
⎯ Recommended option
⎯ Approved modification
⎯ Updated documentation

48. 3. Modification implementation
Topic 4: ISO/IEC IEEE Std
3. Modification implementation
During the Modification Implementation Activity, the maintainer develops and tests the modification of the software product.

49. 3. Modification implementation - Inputs
Topic 4: ISO/IEC IEEE Std
3. Modification implementation - Inputs
The inputs to the Modification Implementation activity are:
⎯ The Baseline
⎯ The Approved MR/PR
⎯ The Approved Modification Documentation

50. 3. Modification implementation - Tasks
Topic 4: ISO/IEC IEEE Std
3. Modification implementation - Tasks
The maintainer performs analysis, then invokes the Development Process of ISO/IEC to effect the modification.

51. 3. Modification implementation - Outputs
Topic 4: ISO/IEC IEEE Std
3. Modification implementation - Outputs
The outputs of this activity should include:
⎯ Updated Test Plans and Procedures
⎯ Updated documentation
⎯ Modified source code
⎯ Test reporting
⎯ Measures

52. 4. Maintenance review/acceptance
Topic 4: ISO/IEC IEEE Std
4. Maintenance review/acceptance
This activity ensures that the modifications to the system are correct and that they were accomplished in accordance with the approved standards using the correct methodology.

53. 4. Maintenance review/acceptance - Inputs
Topic 4: ISO/IEC IEEE Std
4. Maintenance review/acceptance - Inputs
The inputs to the Maintenance Reviews/Acceptance activity are:
⎯ The modified software
⎯ Modification test results

54. 4. Maintenance review/acceptance - Tasks
Topic 4: ISO/IEC IEEE Std
4. Maintenance review/acceptance - Tasks
Reviews are conducted to ensure that modifications are correct and approval is obtained for satisfactory completion of the modifications.

55. 4. Maintenance review/acceptance - Outputs
Topic 4: ISO/IEC IEEE Std
4. Maintenance review/acceptance - Outputs
The outputs of this activity are:
⎯ New Baseline, incorporating accepted modifications
⎯ Rejected modifications
⎯ An Acceptance report
⎯ Audit and Review Reports
⎯ A Software Qualification Test Report

56. Topic 4: ISO/IEC IEEE Std. 14764-2006
5. Migration
During a system's life, it may have to be modified to run in different environments.
In order to migrate a system to a new environment, the maintainer needs to determine the actions needed to accomplish the migration, and then develop and document the steps required to effect the migration.

57. Topic 4: ISO/IEC IEEE Std. 14764-2006
5. Migration - Inputs
The inputs to the Migration activity are:
⎯ The old environment
⎯ The new environment
⎯ The old baseline
⎯ The new baseline

58. Topic 4: ISO/IEC IEEE Std. 14764-2006
5. Migration - Tasks
The Maintainer effects the migration by conforming with ISO/IEC 12207, developing a Migration Plan, notifying users of the migration, providing training, providing a notification of completion, assessing the impact of the new environment, and archiving data. All artifacts from the Migration activity are controlled by CM.

59. Topic 4: ISO/IEC IEEE Std. 14764-2006
5. Migration - Outputs
The outputs of this activity are:
⎯ Migration Plan
⎯ Migration tools
⎯ Notification of Intent
⎯ Migrated Software Product
⎯ Notification of Completion
⎯ Measures
⎯ Archived data

60. Topic 4: ISO/IEC IEEE Std. 14764-2006
6. Software retirement
Once a software product has reached the end of its useful life, it must be retired. An analysis should be performed to assist in making the decision to retire a software product.
The analysis is often economic-based and may be included in the Retirement Plan. Analysis should determine if it is cost effective to:
⎯ Retain outdated technology;
⎯ Shift to new technology by developing a new software product;
⎯ Develop a new software product to achieve modularity;
⎯ Develop a new software product to facilitate maintenance;
⎯ Develop a new software product to achieve standardization;
⎯ Develop a new software product to facilitate vendor independence.

61. Topic 4: ISO/IEC IEEE Std. 14764-2006
6. Software retirement
The software product may be replaced by a new software product but in some cases it will not be replaced.
In order to retire a software product, the maintainer should determine the actions needed to accomplish the retirement, and then develop and document the steps required to effect the retirement.
Consideration should be given to accessing data stored by the retired software product.
All artifacts from the Retirement activity are controlled by CM.

62. 6. Software retirement- Inputs
Topic 4: ISO/IEC IEEE Std
6. Software retirement- Inputs
The inputs to the Retirement Activity are:
⎯ The old software product baseline to be retired
⎯ The new software product
⎯ The old environment

63. 6. Software retirement- Tasks
Topic 4: ISO/IEC IEEE Std
6. Software retirement- Tasks
The Maintainer effects the retirement by:
conforming with ISO/IEC 12207
developing a Retirement Plan, notifying users of the retirement implementing parallel operations and training
providing a notification of completion
archiving data
All artifacts from the Retirement activity are controlled by CM.

64. 6. Software retirement-Outputs
Topic 4: ISO/IEC IEEE Std
6. Software retirement-Outputs
The outputs of this activity are:
⎯ A Retirement Plan
⎯ A Notification of Intent
⎯ Retirement results
⎯ Trained people
⎯ A retired software product
⎯ A Notification of Completion
⎯ Measures
⎯ Archived baseline and data

65. Topic 5: IEEE/EIA Standard 1074:1997
Maintenance objective
The IEEE 1074:1997 is a standard on developing life cycle processes
IEEE/EIA12207:1997 provides a list of processes and activities for software development and maintenance
IEEE/EIA12207:1997 contains mechanisms and recommendations for accomplishing the adaptation.

66. Topic 5: IEEE/EIA Standard 1074:1997
Maintenance objective
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

67. Topic 5: IEEE/EIA Standard 1074:1997
Details
Provides a list of processes and activities for software development and maintenance
- A list of life cycle activities which can be mapped into processes and organized in the same way as any of the software life cycle models
Standard identifies and links other IEEE software standards to these activities
Standard can be used to build processes conforming to any of the life cycle models

68. Topic 5: IEEE/EIA Standard 1074:1997
Details
IEEE Std 1074
Project
Management
Pre-
Development
Develop-
ment
Post-
Cross-
(Integral Processes)
> Project Initiation
>Project Monitoring
&Control
> Software Quality
> Concept
Exploration
> System
Allocation
> Requirements
Analysis
> Design
> Implemen-
tation
> Installation
> Operation &
Support
> Maintenance
> Retirement
> V & V
> Configuration
> Documen-
> Training
Process Group
Processes

69. Topic 6: IEEE 12207 What is ISO/IEC 12207 ?
The major world-wide standard for software related processes, activities, and tasks
Tailored for any organization or project
High level process architecture
An ‘inventory’ of processes from which to choose
A world-wide agreement on what activities make up a software project

70. Topic 6: IEEE 12207
Objective
ISO offers a framework for software life-cycle processes from concept through retirement.
To acquire, supply, develop, operate, and maintain software products
To define, control, and improve software life cycle processes
Suitable for acquisitions
To support software quality assurance, configuration management, joint reviews, audits, verification, validation, problem resolution, and documentation standards
It is not applicable to the purchase of commercial-off-the-shelf (COTS) software products.

71. Topic 6: IEEE 12207
Objective
It contains processes, activities, and tasks that are to be applied during the acquisition of a system that contains software, a stand-alone software product, and software service and during the supply, development, operation, and maintenance of software products.
Well-defined terminology that can be referenced by the software industry.
Provides a structure of processes using mutually accepted terminology
“shall" to indicate mandatory provisions
"should" for recommendations, and
"may" for permissible actions
This from Para 1.1: Purpose

72. Topic 6: IEEE 12207
Objective
12207 provides industry a basis for software practices usable for both national and international business
To establish software management and engineering environments based upon the life cycle processes as adapted and tailored to serve business needs
To foster improved understanding between customers and vendors and among the parties involved in the life cycle of a software product

73. Topic 6: IEEE 12207
Concepts
The standard is based on two basic principles:
Modularity
Modularity means processes with minimum coupling and maximum cohesion.
Responsibility
Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved.

74. Topic 6: IEEE 12207 Concepts Process Architecture
Modular: Handle all types of projects
Cohesion: one process for one major function
Responsibility: One process for one party
Number of processes in the standard is 18 processes

75. Topic 6: IEEE 12207 Terminology 17 Life Cycle Processes
5 Primary Processes § 5
8 Supporting Processes § 6
4 Organizational Processes § 7
Each Process is broken down into Activities
Each Activity is broken down into Tasks
Tasks reference Information Items (software products/documents)
84 items in matrix § 4.3
Generic guidelines for 7 categories § 5
Specific guidelines for § 6
(Note: § = Clause/Section)
12207 assumes life cycle begins with an idea or need that can be satisfied wholly or partly by software and ends with the retirement of the software. Architecture is build with a set of processes and interrelationships. Based on two principles: modularity and responsibility. (.0 Annex E)
A task is expressed in the form of self-declaration, requirement, recommendation, or permissible action. Doc uses auxiliary verbs (will, shall, should, may) to differentiate.
Will = self-declaration of purpose or intent by one party.
Shall = binding provision between two parties.
Should = recommendation among other possibilities.
May = permissible within limits.

76. Topic 6: IEEE 12207
Software life cycle 18 processes- Maintenance in the software life cycle
MANAGEMENT
SUPPLY
OPERATION
MAINTENANCE
DEVELOPMENT
ACQUISITION
DOCUMENTATION
JOINT REVIEW
SUPPORTING PROCESSES CM QA
PROB. RES.
AUDIT
VERIFICATION
VALIDATION
contract
INFRASTRUCTURE
TRAINING
IMPROVEMENT
ORGANIZATIONAL PROCESSES 76

77. Topic 6: IEEE 12207
Software life cycle 18 processes- Maintenance in the software life cycle
Organizational
MANAGEMENT
INFRASTRUCTURE
IMPROVEMENT
TRAINING
Primary
ACQUISITION
SUPPLY
DEVELOPMENT
OPERATION
MAINTENANCE
Supporting
JOINT REVIEW
AUDIT
V & V
QUALITY ASSURANCE
DOCUMENTATION
CONFIGURATION MANAGAMENT
PROBLEM RESOLUTION
TAILORING ( SPECIAL)

78. Topic 6: IEEE 12207
Software life cycle 18 processes- Maintenance in the software life cycle
Primary processes
ACQUISITION: Defines the activities of the acquirer, the organization that acquires a system, software product, or software service.
SUPPLY: Defines the activities of the supplier, the organization that provides the system, software product or software service to the acquirer.
DEVELOPMENT: Defines the activities of the developer, the organization that defines and develops the software product.
OPERATION: Defines the activities of the operator, the organization that provides the service of operating a computer system in its live environment for its users.
MAINTENANCE: Defines the activities of the maintainer, the organization that provides the service of maintaining the software product; that is, managing modifications to the software product to keep it current and in operational fitness. This process includes the migration and retirement of the software product.

79. Topic 6: IEEE 12207
12207’s Management Process An Organizational Life Cycle Process § 7.1
Defines the basic activities of the management, including project management, related to the execution of a life cycle process.
Activity Tasks
1 Initiation and .1 Establish the requirements for management
scope definition .2 Check resources: personnel, materials, etc.
.3 Modify requirements to achieve criteria
2 Planning .1 Plan efforts, schedules, tasks, duties, costs (in Management process plan)
3 Execution and .1 Implement plan to meet objectives
control .2 Monitor process
.3 Investigate and resolve problems
.4 Report progress
4 Review and .1 Ensure products and plans are evaluated
evaluation .2 Assess evaluation results
5 Closure .1 Determine when process is complete
.2 Check results for completeness
Management process can apply to any primary process: acquisition, supply, development, operation, maintenance

80. Topic 6: IEEE 12207
12207’s Maintenance Process A Primary Life Cycle Process § 5.5
Defines the basic activities of the maintainer: managing modifications to the software product to keep it current and in operational fitness.
Activity Tasks
1 Process Implementation Document maintenance activities (in Maintenance process plan). Document problem tracking procedures. Manage modifications to the system.
2 Problem and modification Analyze problem reports. Replicate or verify analysis problems. Develop modifications. Document problems, analysis, fixes (with Modification request). Get modifications approved per contract.
3 Modification implementation Document where changes are needed. Implement modifications (use Development Process).
4 Maintenance review/ Review integrity of modified system. Get approval for acceptance modifications per contract.
5 Migration Ensure products meet with this standard. Develop and use Migration Plan. Notify users of migration. Conduct parallel operations if needed. Notify all concerned, archive all records. Perform post-op review of changes. Keep data from old environment.
6 Software retirement Document plans for retirement. Notify all users of plans and activities. Conduct parallel operations. Notify all concerned, archive all records. Keep data from retired product per contract.

81. The IEEE 12207 Development process
Topic 6: IEEE 12207
The IEEE Development process
Activity
Tasks (paraphrased)
Information Item guidelines
5.3.1 Process Implementation
.1 Define software life cycle model
.2 Document and control outputs
.3 Select and use standards, tools, languages
.4 Document development plans
.5 Deliver all needed products --
Plan, Desc
6.5 DPP, 6.17 SDSD
5.3.2 System requirements analysis
.1 Specify system requirements
.2 Evaluate requirements against criteria
Specification
Spec, Record
6.26 SRS
6.26 SRS, 6.6 SRER
5.3.3 System architectural design
.1 Establish top-level architecture
.2 Evaluate architecture against criteria
Description
Desc, Record
6.25 SARAD
6.25 SARAD, 6.6 SAER
5.3.4 Software requirements analysis
.1 Document software requirements
.3 Conduct joint reviews iaw 6.6
Desc
6.22 SRD, 6.30 UDD
6.22 SRD, 6.6 SRER
5.3.5 Software architectural design
.1 Transform requirements into architecture
.2 Document top-level design for interfaces
.3 Document top-level design for database
.4 Document preliminary user documentation
.5 Document preliminary test requirements
.6 Evaluate architecture against criteria
.7 Conduct joint reviews iaw 6.6
Plan
6.12 SAD
6.19 SIDD
6.4 DBDD
6.30 UDD
6.27 T/VP
6.12 SAD, 6.6 SAER 81

82. Topic 6: IEEE 12207 The IEEE 12207 Development process 82
5.3.6 Software detailed design
.1 Document design for each component
.2 Document design for interfaces
.3 Document design for database
.4 Update user documentation
.5 Document unit test requirements
.6 Update integration test requirements
.7 Evaluate detailed design against criteria
.8 Conduct joint reviews iaw 6.6
Description
Plan
Rec, Desc --
6.16 SDD
6.19 SIDD
6.4 DBDD
6.30 UDD
6.27T/VP
6.6 DDER, 6.16 SDD
5.3.7 Software coding and testing
.1 Document each unit, database and tests
.2 Conduct and document unit testing
.3 Update user documentation
.4 Update integration test requirements
.5 Evaluate code and test results
Desc, Rec, Proc
Report
Rec, Plan
6.4 DBDD, 6.24 SCR, 6.28 T/VPr
6.29 T/VRR
6.7 EOCR,6.6 SCTRE, 6.24SCR, 6.27T/VP
5.3.8 Software integration
.1 Document integration plans
.2 Conduct and document integration tests
.4 Document qualification tests
.5 Evaluate plans and tests against criteria
.6 conduct joint reviews iaw 6.6
Plan, Proc
Proc
Proc, Desc
Record, Plan
6.18 SIP, 6.28 T/VPr
6.28 T/VPr
6.28 T/VPr, 6.30 UDD
6.6 SIER, 6.18 SIP 82

83. Topic 6: IEEE 12207 The IEEE 12207 Development process 83
5.3.9 Software qualification testing
.1 Conduct and document qualification testing
.2 Update user documentation
.3 Evaluate tests against criteria
.4 Support audits iaw 6.7
.5 Prepare product for next phase
Report
Description
Record --
6.29 T/VRR
6.30 UDD
6.6 SIER
6.24 SCR
System integration
.1 Integrate software with hardware & others
.2 Document integration tests
.3 Evaluate integrated system against criteria
Procedure
6.28 T/VPr
6.6 SQTER
System qualification testing
.1 Conduct and document qualification tests
.2 Evaluate system against criteria
.3 Support audits iaw 6.7
.4 Prepare product for installation
6.6 SER
Software installation
.1 Plan installation in target environment
.2 Install software iaw plan
Software acceptance support
.1 Support acquirer's acceptance tests
.2 Deliver product per contract
.3 Provide training per contract 83

84. Tailoring 12207 for a project
Topic 6: IEEE 12207
Tailoring for a project
12207 should be tailored for a project - no two projects are the same
Tailoring considerations:
Life cycle activity: prototyping, maintenance
Software characteristics: COTS, reuse, embedded firmware
Org’s policies, languages, hardware reserve, culture
Acquisition strategy: contract type, contractor involvement
Life cycle strategy: waterfall, evolutionary, spiral, etc.
The Tailoring Process ( )
1. Identify project environment - strategy, activity, requirements
2. Solicit inputs - from users, support team, potential bidders
3. Select processes, activities, documentation, responsibilities
4. Document tailoring decisions and rationale
What CAN’T be tailored: the intent or objectives
What CAN be tailored: number of phases/activities, roles, responsibilities, document formats, formality/frequency of reports or reviews

85. Topic 7: IEEE 1219-1998: Software Maintenance
Objective
Standard focuses on maintenance processes
© 2010 John Wiley & Sons Ltd.

86. Topic 7: IEEE 1219-1998: Software Maintenance
Table of content
1 Problem identification
1.1 Input
1.2 Process
1.3 Control
1.4 Output
1.5 Quality factors
1.6 Metrics
4.2 Analysis
2.1 Input
2.2 Process
2.2.1 Feasibility analysis
2.2.2 Detailed analysis
Control, Output,
Quality factors, Metrics.
4.3 Design
Input, Process, Control, Output, Quality factors, Metrics.
4 Implementation
4.1 Input
4.2 Process
4.2.1 Coding and & testing
4.2.3 Risk analysis & review
4.2.4 Test-readiness review
4.3-6 Control, Output,
Quality factors, Metrics.
5 System test
Input, Process, Control, Output, Quality factors, Metrics.
6. Acceptance test
Input, Process, Control,
Output, Quality factors, Metrics.
7 Delivery
Input, Process, Control, Output, Quality factors, Metrics.
© 2010 John Wiley & Sons Ltd.

87. Six attributes of each maintenance request phase
Topic 7: IEEE : Software Maintenance
Six attributes of each maintenance request phase
Phase
Attributes
1. Problem identification
2. Analysis
3. Design
4. Implementation
5. System test
6. Acceptance test
7. Delivery
a. Input life cycle arti-facts for this step
b. Process required for this step
c. How the process is controlled
d. Output life cycle artifacts
e. Process quality factors involved
f. Metrics for this step

88. Maintenance Processes
Topic 7: IEEE : Software Maintenance
Maintenance Processes
Problem/modification identification, classification, and prioritization
Analysis
Design
Implementation
Regression/system testing
Acceptance testing
Delivery

89. IEEE 840-1994: Software Maintenance Table of Contents
Topic 8: IEEE
IEEE : Software Maintenance Table of Contents
1. Problem identification
1.1 Input
1.2 Process
1.3 Control
1.4 Output
1.5 Quality factors
1.6 Metrics
2. Analysis
2.1 Input
2.2 Process
2.2.1 Feasibility analysis
2.2.2 Detailed analysis
Control, Output,
Quality factors, Metrics.
3. Design
Input, Process, Control,
Output, Quality factors, Metrics.
© 2010 John Wiley & Sons Ltd.

90. Thank you for
your attention.