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

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

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 14764 which describes s/w maintenance as an iterative process for managing and executing software maintenance activities IEEE/EIA Standard 1074:1997 ISO/IEC 12207 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 840-1994 Both IEEE/EIA 1219 and ISO/IEC 14764 are part of ISO/IEC12207. Standards which focus on maintenance processes are IEEE Std 1219-1998 and ISO 14764: 1998 xx

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 12207 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 840-1994 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

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 840-1994

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.

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

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

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

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

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

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.

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

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)

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

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

Topic 2: Software Maintenance Standards IEEE Software and Systems Engineering Standards Committee (S2ESC)- Projects 1045 Std for Software Productivity Metrics 1175.4 Guide for CASE Tool Interconnections - Reference Model for Specifying System Behavior 1175.5 Guide for CASE Tool Interconnections - Syntax for Transferring Behavior Specifications 1648 RP for Establishing and Managing Software Development Efforts Using Agile Methods 12207.0 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

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

Topic 2: Software Maintenance Standards IEEE Software and Systems Engineering Standards Committee (S2ESC)- Standards Published in 2006 982.1-2005 IEEE Standard Dictionary of Measures of the Software Aspects of Dependability 1074-2006 IEEE Standard for Developing a Software Project Life Cycle Process 1175.2-2006 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

Topic 2: Software Maintenance Standards Borrowed from: www

Software engineering standards tree Topic 2: Software Maintenance Standards Software engineering standards tree ISO/IEC 12207 “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 12207 includes all of ISO 12207 and good parts of 016 (=498) MIL-STD-498 “Software Development and Documentation” Dec 94 J-STD-016-1995 (Trial Use) “Software Life Cycle Processes, Software Development” Sep 95 IEEE/EIA 12207.0-1996 IEEE/EIA 12207.1-1997 IEEE/EIA 12207.2-1997 “Software Life Cycle Processes” Mar/Apr 98 DOD-STD-7935A “DoD Automated Information Systems (AIS) Documentation Standards” Oct 88 Borrowed from: www

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 http://www.software.org/Quagmire/ Borrowed from: www

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 1994 ISO 9000 (series - on Quality Management, etc.) 1991- J-STD-016-1995 Software Development - 1995 Acquirer-Supplier Agreement ISO/IEC 12207 Information Technology - Software Life 1996 Cycle Processes IEEE/EIA 12207 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

Topic 3: Maintenance in the System Life Cycle ISO/IEC 15288 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 12207 includes all of ISO 12207 and good parts of 016 (=498) Borrowed from: www

Topic 3: Maintenance in the System Life Cycle IEEE 12207 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

Topic 4: ISO/IEC IEEE Std. 14764-2006 History The first edition of ISO/IEC 14764 was prepared by ISO/IEC JTC 1/SC 7. The current edition is the result of merging the original edition with IEEE Std 1219-1998. 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).

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.

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.

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 12207. 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.

Software Engineering — Software Life Cycle Processes — Maintenance Topic 4: ISO/IEC IEEE Std. 14764-2006 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:

Software Engineering — Software Life Cycle Processes — Maintenance Topic 4: ISO/IEC IEEE Std. 14764-2006 Software Engineering — Software Life Cycle Processes — Maintenance 6 Execution considerations 6.8 Maintainability 6.8.2.1 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 12207. 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  

Categories of maintenance in ISO/IEC 14764 Topic 4: ISO/IEC IEEE Std. 14764-2006 Categories of maintenance in ISO/IEC 14764 ISO/IEC 14764 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.

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. 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.

Defining maintenance strategy Topic 4: ISO/IEC IEEE Std. 14764-2006 Defining maintenance strategy Std. 14764 stresses the importance of formulating and composing a maintenance strategy. IEEE Std. 14764 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.

Maintenance process categories Topic 4: ISO/IEC IEEE Std. 14764-2006 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.

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

1. Process implementation Topic 4: ISO/IEC IEEE Std. 14764-2006 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 8.3.2 of this International Standard) should be developed in parallel with the Development Plan. The maintainer should also establish needed organizational interfaces during this activity.

1. Process implementation - Inputs Topic 4: ISO/IEC IEEE Std. 14764-2006 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

1. Process implementation - tasks Topic 4: ISO/IEC IEEE Std. 14764-2006 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).

1. Process implementation- Modification Request (MR) Topic 4: ISO/IEC IEEE Std. 14764-2006 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

1. Process implementation- Problem Report (PR) Topic 4: ISO/IEC IEEE Std. 14764-2006 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.

1. Process implementation- MR/PR procedures Topic 4: ISO/IEC IEEE Std. 14764-2006 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.

1. Process implementation - Outputs Topic 4: ISO/IEC IEEE Std. 14764-2006 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.

2. Problem and modification analysis Topic 4: ISO/IEC IEEE Std. 14764-2006 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.

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

2. Problem and modification analysis -tasks Topic 4: ISO/IEC IEEE Std. 14764-2006 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

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

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

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

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

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

4. Maintenance review/acceptance Topic 4: ISO/IEC IEEE Std. 14764-2006 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.

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

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

4. Maintenance review/acceptance - Outputs Topic 4: ISO/IEC IEEE Std. 14764-2006 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

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.

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

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.

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

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.

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.

6. Software retirement- Inputs Topic 4: ISO/IEC IEEE Std. 14764-2006 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

6. Software retirement- Tasks Topic 4: ISO/IEC IEEE Std. 14764-2006 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.

6. Software retirement-Outputs Topic 4: ISO/IEC IEEE Std. 14764-2006 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

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.

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

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

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

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

Topic 6: IEEE 12207 Objective ISO 12207 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.

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 12207.0 Para 1.1: Purpose

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

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.

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

Topic 6: IEEE 12207 Terminology 17 Life Cycle Processes 5 Primary Processes - 12207.0 § 5 8 Supporting Processes - 12207.0 § 6 4 Organizational Processes - 12207.0 § 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 - 12207.1 § 4.3 Generic guidelines for 7 categories - 12207.1 § 5 Specific guidelines for 30 - 12207.1 § 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.

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

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)

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.

Topic 6: IEEE 12207 12207’s Management Process An Organizational Life Cycle Process - 12207.0 § 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

Topic 6: IEEE 12207 12207’s Maintenance Process A Primary Life Cycle Process - 12207.0 § 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.

The IEEE 12207 Development process Topic 6: IEEE 12207 The IEEE 12207 Development process Activity Tasks (paraphrased) 12207.1 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

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

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 5.3.10 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 5.3.11 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 5.3.12 Software installation .1 Plan installation in target environment .2 Install software iaw plan 5.3.13 Software acceptance support .1 Support acquirer's acceptance tests .2 Deliver product per contract .3 Provide training per contract 83

Tailoring 12207 for a project Topic 6: IEEE 12207 Tailoring 12207 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 (12207.0 ) 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

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

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 2.3-2.6 Control, Output, Quality factors, Metrics. 4.3 Design 3.1-3.6 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 5.1-5.6 Input, Process, Control, Output, Quality factors, Metrics. 6. Acceptance test 6.1-6.6 Input, Process, Control, Output, Quality factors, Metrics. 7 Delivery 7.1-7.6 Input, Process, Control, Output, Quality factors, Metrics. © 2010 John Wiley & Sons Ltd.

Six attributes of each maintenance request phase Topic 7: IEEE 1219-1998: 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

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

IEEE 840-1994: Software Maintenance Table of Contents Topic 8: IEEE 840-1994 IEEE 840-1994: 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 2.3-2.6 Control, Output, Quality factors, Metrics. 3. Design 3.1-3.6 Input, Process, Control, Output, Quality factors, Metrics. © 2010 John Wiley & Sons Ltd.

Thank you for your attention.