ISO/IEC JTC1/SC7 N2182

Transcription

1 ISO/IEC JTC1/SC7 Software Engineering Secretariat: CANADA (SCC) ISO/IEC JTC1/SC7 N /07/19 Document Type Title Source Proposed Draft Amendment 12207/PDAM 1 - Software Engineering - Life Cycle Processes. JTC1/SC7/WG7 Secretary Project Status PDAM Ballot References Supersedes 07n2135 which was cancelled ( ) Action ID ACT Due Date 1999/10/19 Mailing Date 1999/07/19 Distribution Medium SC7_AG Encoded Acrobat No. of Pages 35 Note Includes a "Commenting Package" in Excel97 spreadsheet format (07n2182c). Address reply to: ISO/IEC JTC1/SC7 Secretariat Bell Canada - Quality Engineering & Research 1050 Beaver Hall Hill, 2 nd Floor, Montréal (Québec) Canada H2Z 1S4 Tel.: +1 (514) Fax: +1 (514) sc7@qc.bell.ca

2 ISO/IEC JTC1/SC7 PDAM 12207:1995/AMD 1 Date Reference number 1999/07/19 ISO/JTC 1/SC 7 N2182 Supersedes document N2135 ISO/JTC 1/SC 7 Committee Title Software Engineering Secretariat: Standards Council of Canada (SCC) THIS DOCUMENT IS STILL UNDER STUDY AND SUBJECT TO CHANGE. IT SHOULD NOT BE USED FOR REFERENCE PURPOSES. Circulated to P- and O-members, and to technical committees and organizations in liaison for: X voting by (P-members only) 1999/10/19 Please return all votes and comments in electronic form directly to the SC 7 Secretariat by the due date indicated. ISO/IEC JTC1/SC7 Title: 12207/PDAM 1 - Software Engineering - Life Cycle Processes. Project: Introductory note: See page ii of the document Medium: Encoded Acrobat No. of pages: 35

3 Vote on PDAM 12207:1995/AMD 1 Date of circulation Reference number 1999/07/19 ISO/JTC 1/SC 7 N2182 Closing date 1999/10/19 ISO/JTC 1/SC 7 Committee Title Software Engineering Secretariat: Standards Council of Canada (SCC) Circulated to P-members of the committee for voting Please return all votes and comments in electronic form directly to the SC 7 Secretariat by the due date indicated. ISO/IEC JTC1/SC7 Title: 12207/PDAM 1 - Software Engineering - Life Cycle Processes. Project: Vote: APPROVAL OF THE DRAFT AS PRESENTED APPROVAL OF THE DRAFT WITH COMMENTS AS GIVEN ON THE ATTACHED General: Technical: Editorial: DISAPPROVAL OF THE DRAFT FOR REASONS ON THE ATTACHED Acceptance of these reasons and appropriate changes in the text will change our vote to approval ABSTENTION (FOR REASONS BELOW): P-member voting: National Body (Acronym) Date: YYYY-MM-DD Submitted by: Your Name

4 To: SC 7 Secretariat Subject: PDAM ballot of ISO/IEC Dear Jean-Normand The PDAM of ISO/IEC is hereby submitted for ballot. This document was reviewed by WG 7 in Curitiba. Please find attached the following documents to support the ballot: WG 7 N0295 ISO/IEC 12207:1995/PDAM 1 WG 7 N0288 WG 7 commenting package - Excel template and instructions Comments were provided in Curitiba, by the UK only, for the document which is currently (prematurely) out to ballot. The accepted comments have been incorporated into the accompanying PDAM. It would be appreciated if you would bring to the attention of National Bodies, a request from WG 7 for comments to be submitted using the template provided. The templates are imported to a database for comment resolution. The next meeting of WG 7 is being held in Nantes, France, October I understand that any comments and a ballot disposition will be available for that meeting. Your assistance in meeting this objective is much appreciated. Regards Stan Magee WG 7 Interim Convener

5 ISO/IEC JTC 1/SC 7 Date: ISO/IEC 12207:1995/PDAM 1 ISO/IEC JTC1/SC7/WG7/N0295 Secretariat: Canada Amendment to ISO/IEC 12207:1995 Information Technology - Software life cycle processes Document type: International Standard Document subtype: Amendment Document stage: (30) Committee Document language: E C:\WINDOWS\DESKTOP\My Briefcase\SC7 Documents To Issue\07n2182.doc ISOSTD ISO Template Version ii

6 Contents Foreward... iii Introduction.. iv 1. Changes made by this Amendment Changes to the Text of ISO/IEC 12207: Specific Changes... 1 Annex D Bibliography 3 Annex E Relationship to ISO/IEC Annex F Process Purpose and Outcomes. 6 Annex G ISO/IEC 12207:1995 Process Structure for Expansion of Scope Items 25 iii

7 Copyright notice This ISO document is a draft amendment and is copyright-protected by ISO. Except as permitted under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, photocopying, recording or otherwise, without prior written permission being secured. Requests for permission to reproduce should be addressed to ISO at the address below or ISO's member body in the country of the requester: Copyright Manager ISO Central Secretariat 1 rue de Varembé 1211 Geneva 20 Switzerland tel fax central@iso.ch Reproduction may be subject to royalty payments or a licensing agreement. Violators may be prosecuted. iv

8 Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. The Amendment to International Standard ISO/IEC was prepared by JTC1, Information Technology, Subcommittee 7, Software Engineering. This Amendment to ISO/IEC includes minor changes defined in the Project Requirements Document as A (Amendment) requirements. The Amendment adds four annexes to ISO/IEC Annex F forms an integral part of the International Standard. Annexes D, E and G are for information. v

9 Introduction ISO/IEC was published on 1 August 1995 and is the first international standard to provide a comprehensive set of life cycle processes, activities and tasks for software that is part of a larger system, stand alone software product, and software services. The standard provides common software process architecture for the acquisition, supply, development, operation and maintenance of software. The standard also provides the necessary supporting processes, activities and tasks, and organizational processes, activities and tasks for managing and improving the processes. This Amendment provides an interim revision to ISO/IEC that establishes a coordinated set of software process information which accommodates the requirements of the current SC 7 standards and technical reports, notably ISO/IEC and ISO/IEC TR 15504, and considers other standards, i.e., ISO/IEC and ISO/IEC Experience in using ISO/IEC as the basis for organizations software life cycle process and in twoparty situations, has resulted in some lessons learned and has provided some valuable inputs to the update process. During the development of ISO/IEC TR Software Process Assessment, issues were highlighted in regard to the scope and granularity of the process model and process definition in ISO/IEC 12207, such that it was not easily utilized for assessment. A further issue was that for use ISO/IEC as a reference model, for the purpose of process assessment, it was difficult to derive a rating component. This Amendment establishes an interim revision to ISO/IEC which improves the consistency and usability with current and developing SC7 standards and technical reports, i.e., ISO/IEC TR 15504, ISO/IEC and ISO/IEC This Amendment is the first of a two-step revision process. The second stage will commence with the release of the final draft amendment (FDAM). The current ISO/IEC process architecture defines the hierarchical relationship among process, activity and task and the invocation rules among the software life cycle processes. Inclusion of a process, an activity, or a task for the Amendment is in accordance and consistent with the existing architecture of ISO/IEC vi

10 1. Changes made by this Amendment This amendment changes the text of ISO/IEC in several places and adds three additional annexes one of the normative and two of them informative. 1.1 Changes to the Text of ISO/IEC 12207:1995 Throughout the text of ISO/IEC 12207:1995, the name of the Training process is changed to Human Resources Specific Changes The text of subclause 1.2 of ISO/IEC 12207:1995, paragraph 4, is clarified as follows: 1.2 Field of Application This clause does not prohibit the use of ISO/IEC by suppliers or developers of off-the-shelf software. The text of subclause 1.4 of ISO/IEC 12207:1995 is supplemented with the following text: Conformance to Purposes and Outcomes Annex F provides an alternative form of conformance that allows an organization or project to use alternative activities and tasks that achieve the Purpose and Outcomes of the processes of this standard. To claim conformance for a declared set of processes listed in Annex F, it shall be demonstrated that the declared Purpose and Outcomes, respectively, of the selected set of processes, activities and tasks have been satisfied. The text of subclause 1.5 of ISO/IEC 12207:1995, paragraph 6, should read as follows: 1.5 Limitations In this International Standard, there are a number of lists for tasks; none of these is presumed to be exhaustive -- they are intended as examples unless introduced by a clause containing a shall or a will. The text of clause 4 of ISO/IEC 12207:1995, the following text should be added as subclause 4.2: 4.2 Impact of Annex F on ISO/IEC 12207:1995 (The text will clarify the use of Purpose and Outcomes in the text of the standard and to address the impact and the proposed use of Annex F is TBD) The text of subclause of ISO/IEC 12207:1995, sentence 2, should read as follows: Subclause , Shall should be changed to will The text of subclause of ISO/IEC 12207:1995, paragraph e, should be added as follows: Subclause : e) Establish baselines for each configuration item at appropriate times, as determined by the acquirer and the supplier. The text of subclause of ISO/IEC 12207:1995, sentence 2, should be deleted. The text of subclause b of ISO/IEC 12207:1995, should be deleted. The text of subclause b of ISO/IEC 12207:1995, should be deleted. 1

11 The text of subclause 6.1 of ISO/IEC 12207:1995, the following should be added as a second paragraph to the preamble: Subclause 6.1 Execution of this process by an organization results in the establishment of internal documentation standards (such as standards for program management plan and software design document) in a suitable media -- paper, electronic, or other. The terms used in this process need to be interpreted accordingly for a given media or domain. The text of subclause 6.2 of ISO/IEC 12207:1995, the following should be added in line 2 of the preamble as follows: Subclause 6.2 Baseline should be deleted. The resulting sentence should read as follows: The Configuration Management Process is a process of applying administrative and technical procedures throughout the software life cycle to: identify and define software items in a system; control modifications and releases of the items; record and report the status of the items and modification requests; ensure the completeness, consistency, and correctness of the items, and control storage, handling, and delivery of the items. The text of subclause of ISO/IEC 12207:1995, the following should be added as follows: Subclause Additional quality management activities shall be assured in accordance with the clauses of ISO The text of subclause of ISO/IEC 12207:1995, the following should be changed as follows: Subclause This clause depends heavily on testing (real-time executions) for validation. To allow flexibility, the following note should be added at the end of clause : NOTE: Other means besides testing (such as, analysis, modeling, simulation, etc.) may be employed for validation. The text of subclause e of ISO/IEC 12207:1995, paragraph e should added as follows: Subclause e) They are ready for the next planned activity. 2

12 Annex D (informative) Bibliography D.1 Classification of Bibliography Information Throughout this Amendment, a careful distinction has been made between documents, which are published, as International Standards and those, which are not. For example, ISO/IEC refers to the International Standard but ISO/IEC TR refers to the Technical Report. D.2 Published standards and technical reports a) ISO Quality management and quality assurance standards -- Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software b) ISO 9001:1994 Quality systems - Models for quality assurance in design/development, production, installation and servicing c) ISO :1994 Quality Management and quality system elements -- Part 4: Guidelines for quality improvement d) ISO/IEC 9126 Software Product Evaluation - Quality Characteristics and Guidelines for their Use e) ISO/IEC Software Engineering Product Evaluation f) ISO/IEC TR Software process assessment g) ISO/IEC 12119:1994 Information Technology Software Packages Quality requirements and testing D.3 Developing standards and technical reports a) ISO 9000 (2000) Quality management systems Concepts and vocabulary b) ISO 9001 (2000) Quality management systems - Requirements c) ISO 9004 (2000) Quality management systems Guidance for performance improvement d) ISO/IEC Software process assessment e) ISO/IEC (WD) Software process measurement 3

13 Annex E (informative) Relationship to ISO/IEC E.1 Relationship of Purpose and Outcomes to ISO/IEC 12207:1995 ISO/IEC 12207:1995 documents the set of software engineering processes that are fundamental to good software engineering and cover best practices. The Purposes and Outcomes, defined in Annex F, together with ISO/IEC 12207:1995, provides a reference model which describes processes that an organization can use to acquire, supply, develop, operate and maintain software. The reference model is also used to provide a common basis for different models and methods for software process assessment, ensuring that the results of the assessments can be reported in a common context. Annex F groups the Purposes and Outcomes into the three life cycle process categories of ISO/IEC 12207:1995, i.e., Organizational, Primary and Supporting. Within each of the process categories are descriptions in terms of a purpose statement, which comprise unique functional objectives when instantiated in a particular environment. The purpose statement includes additional material identifying the outcomes of successful implementation. Annex F does not define how, or in what order, the elements of the purpose statements are to be achieved. The purposes will be achieved in an organization through various detailed activities, tasks, and practices being carried out to produce work products. These performed tasks, activities, and practices, and the characteristics of the work products produced, are indicators that demonstrate whether the specific purpose is being achieved. The Purpose/Outcomes and their relationship to the existing International Standard, ISO/IEC 12207:1995, is depicted in Table E-1. For those Purpose and Outcomes that are an expansion in scope to ISO/IEC 12207:1995, Annex G provides a description of their activities and/or tasks. The activity and task description provided in Annex G is in accordance with process structure of ISO/IEC 12207:1995. E.2 Purpose and The Purpose and Outcomes in Annex F are at the appropriate process, activity or task level to align with the process structure of ISO/IEC The description of purpose and outcomes are as follows: Purpose provides a general characterization of the overall thrust of the process, activity, or task Outcomes are observable results and provide more specific indications of what the process, activity, or task should accomplish when successfully enacted 4

14 ISO/IEC Process Annex F - Purpose/Outcomes ISO/IEC Scope Status Acquisition process Acquisition process Acquisition preparation Supplier selection Supplier monitoring Customer acceptance Product evaluation Supply process Supply process Development process Development process Requirements elicitation System Requirements Analysis System Architectural Design Software Requirements Analysis Software Design Software Construction Software Integration Software Testing System Integration & Testing Product evaluation Operation process Operation process Operational use Customer support Maintenance process Maintenance process Documentation process Documentation process Configuration management process Configuration management process Quality assurance process Quality assurance process Verification process Verification process Validation process Validation process Joint Review process Joint Review process Audit process Audit process Problem Resolution process Problem Resolution process Usability process Usability process Expansion in scope Management process Management process Organization management Project management Quality management Risk management Organizational alignment Measurement Expansion in scope Asset management Expansion in scope Reuse program management Expansion in scope Domain engineering Expansion in scope Improvement process Improvement process Process establishment Process Assessment Process Improvement Human resource management process Human resource management process Expansion in scope Training Infrastructure process Infrastructure process Table E.1 Correlation of ISO/IEC 12207:1995 to Annex F 5

15 Annex F (normative) Process Pupose and Outcomes F.1 Primary Life Cycle Processes: F.1.1 Acquisition Process The purpose of the Acquisition Process is to obtain the product and/or service that satisfies the need expressed by the customer. The process begins with the identification of a customer need and ends with the acceptance of the product and/or service needed by the customer. The Acquisition Process includes process purposes and outcomes for: Acquisition Preparation Supplier Selection Supplier Monitoring Customer Acceptance Product Evaluation F Acquisition preparation The purpose of Acquisition preparation is to establish the needs and goals of the acquisition and to communicate these with the potential suppliers. As a result of successful implementation of Acquisition preparation: the concept or the need for the acquisition, development, or enhancement will be established; the customer s requirements will be defined and validated; an acquisition strategy/plan will be developed; selection criteria will be defined. F Supplier selection The purpose of Supplier selection is to choose the organization that will be responsible for the implementation of the project s requirements. As a result of successful implementation of Supplier selection: 6

16 the needed acquisition requirements (e.g. request for proposal) defining the project needs will be defined and validated; the supplier selection criteria will be used to evaluate potential suppliers; the supplier will be selected based upon the evaluation of the supplier s proposals, capabilities, and other factors; a contract will be established and negotiated between the customer and the supplier. F Supplier monitoring The purpose of Supplier monitoring is to monitor the supplier's activities during the development of the software product and/or service. As a result of successful implementation of Supplier monitoring: joint activities between the customer and the supplier will be performed as needed; information on technical progress will be exchanged regularly with the supplier; performance of the supplier will be monitored against the agreed requirements. F Customer acceptance The purpose of Customer acceptance is to approve the supplier's deliverable when all acceptance conditions are satisfied. As a result of successful implementation of Customer acceptance: acceptance will be based on the acquisition strategy and conducted according to the agreed acceptance criteria; the delivered software product and/or service will be evaluated with regard to the agreed requirements. F Product Evaluation Ensure that a product meets the stated and implied needs of the users of that product. Guidance for performing product evaluations found in ISO/IEC 14598, Software product evaluation, Part 4: Process for Acquires. It may be applied to intermediate or final products. As a result of successful implementation of Product Evaluation: a suitable quality model will be selected and applied; a list of products that evaluate satisfactorily will be maintained. 7

17 F.1.2 Supply Process The purpose of the Supply process is to provide a product or service to the customer that meets the agreed requirements. As a result of successful implementation of the Supply process: a response to customer's request will be produced; a contract will be established between the customer and the supplier for developing, packaging, delivering, and installing the product and/or service; a product and/or service that meets the agreed requirements will be developed by the supplier; the product and/or service will be delivered to the customer and installed in accordance with the agreed requirements. F.1.3 Development Process The purpose of the Development Process is to transform a set of requirements into a functional software product or software-based system that meets the customer s stated needs. The activities of the Development Process are composed for Systems Developer role and Software Developer role. The Product Evaluation activity applies to both roles. The Development Process includes purposes and outcomes for: Requirements Elicitation Requirements Analysis Design Construction Integration Testing Product Evaluation F Requirements elicitation The purpose of the Requirements elicitation is to gather, process, and track evolving customer needs and requirements throughout the life of the product and/or service so as to establish a requirements baseline that serves as the basis for defining the needed work products. As a result of successful implementation of Requirements elicitation: continuing communication with the customer will be established; agreed customer requirements will be defined and baselined; 8

18 a mechanism will be established to incorporate new customer requirements into the baselined requirements baseline; a mechanism will be established for continuous monitoring of customer needs; a mechanism will be established for ensuring that customers can easily determine the status and disposition of their requests; enhancements arising from changing technology and customer needs will be identified and their impact managed. F System requirements analysis The purpose of the System requirements analysis is to transform the defined stakeholder requirements into a set of desired system technical requirements that will guide the design of the system. As a result of successful implementation of System requirements analysis: a defined set of system requirements stated in acceptable technical terms describing the problem to be solved; the requirements allocated to system components and their interfaces are traceable to the customer s requirements baseline; system requirements will be analyzed for correctness and testability; the impact of the system requirements on the operating environment will be understood; the requirements will be approved and updated as needed; consistency will be established between the system requirements of each component and the customer s requirements baseline; the system requirements will be communicated to all affected parties and baselined; the system requirements provide the basis for establishing the design solution of the system architecture. F System architectural design The purpose of the System architectural design is to identify which system requirements should be allocated to which elements of the system and to which releases. As a result of successful implementation of System architectural design: a system architecture design will be proposed that identifies the main elements of the system; the requirements will be allocated to each of the main elements of the system; internal and external interfaces of each system component will be defined; consistency between the system requirements and the system architecture will be established; the system requirements will be approved and updated as needed; the system requirements, the system architecture design, and their relationships will be communicated to all affected parties. 9

19 F Software requirements analysis The purpose of the Software requirements analysis is to establish the requirements of the software components of the system. As a result of successful implementation of Software requirements analysis: the requirements allocated to software components of the system and their interfaces will be traceable to the system requirements baseline; software requirements will be analyzed for correctness and testability; the impact of software requirements on the operating environment will be understood; consistency will be established between the software components and system requirements baseline; the software requirements will be approved and updated as needed; the software requirements will be communicated to all affected parties and baselined. F Software design The purpose of the Software design is to define a design for the software that implements the requirements and can be tested against them. As a result of successful implementation of Software design: a software architectural design will be developed that describes the major software components that will implement the software requirements; internal and external interfaces of each software component will be defined; a verified detailed design will be developed that describes software units that can be built and tested; consistency will be established between software requirements and software designs. F Software construction The purpose of Software construction is to code and test each software unit developed in the software design process. Each unit of code is reviewed for compliance with the corresponding requirements, design, and the software coding standards prior to establishing control over the unit and making it available for integration. As a result of successful implementation of Software construction: verification criteria will be defined for all software units against their requirements; software units defined by the design will be produced; consistency will be established between software requirements and design and software components; 10

20 verification of the software units against the design will be accomplished. F Software integration The purpose of Software integration is to ensure the performance and functionality of the software on an equivalent or complete operational platform. Software integration combines the software units into software aggregates in accordance with the software integration plan. The execution of this process results in producing integrated software items and to verify that the integrated software item satisfies the software design and the software requirements. As a result of successful implementation of Software integration: an integration strategy will be developed for software units consistent with the release strategy; verification criteria for software items will be developed that ensure compliance with the software requirements allocated to the items; software items defined by the integration strategy will be produced; software items will be verified using the defined acceptance criteria; results of integration testing will be recorded; consistency will be established between software requirements and software items; a regression strategy will be developed for reverifying software items should a change in software units occur; regression testing will be carried out as necessary. F Software testing The purpose of Software testing is to test the integrated software item to the software requirements and ensuring that each software requirement is tested for compliance. As a result of successful implementation of the process: acceptance criteria for integrated software will be developed that verify compliance with the software requirements; integrated software will be verified using the defined acceptance criteria; test results will be recorded; a regression strategy will be developed for retesting the integrated software should a change in software items be made; regression testing will be carried out as necessary. F System integration and testing The purpose of the System integration and testing is to integrate the software item with other software items, and to integrated the software with hardware items, manual operations, and other systems, as necessary, to produce a complete system that will satisfy the customers expectations expressed in the system requirements. 11

21 As a result of successful implementation of the process: an integration strategy will be developed to build system unit aggregates according to the release strategy; acceptance criteria for each aggregate will be developed to verify compliance with the system requirements allocated to the components; system aggregates will be verified using the defined acceptance criteria; consistency will be established between the system requirements and the system components; an integrated system demonstrating compliance with the system requirements (functional, non-functional, operations and maintenance) and validation that a complete set of useable deliverable components exists, will be constructed; test results will be recorded; a regression strategy will be developed for retesting aggregates or the integrated system should a change be made to existing components; regression testing will be carried out as necessary. F Product Evaluation Product evaluations are planned and conducted by the system and software roles associated with the Development Process. System and software engineering will establish the applicable evaluation criteria and coordinate to ensure consistency. Systems and software engineering will each ensure that their respective system and software products meets the stated and implied needs of the users of that product. Guidance for performing software product evaluations are found in ISO/IEC 14958, Software product evaluations, Part 3: Process for Developers. System and software product evaluations may be applied to intermediate or final products. As a result of successful implementation of Product Evaluation: a suitable quality model will be selected and applied. a list of products that evaluate satisfactorily will be maintained. F.1.4 Operation Process The purpose of the Operation Process is to operate the software product in its intended environment and to provide support to the customers of the software product. The Operation Process includes purpose and outcomes for: Operational Use Customer Support F Operational use The purpose of the Operational use is to ensure the correct and efficient operation of the product for the duration of its intended usage and in its installed environment. 12

22 As a result of successful implementation of Operational use: operational risks for the product introduction and operation will be identified and monitored; the product will be operated in its intended environment according to requirements; assurance will be provided that product capacities are adequate to meet customer needs. F Customer support The purpose of the Customer support is to establish and maintain an acceptable level of service to the customer to support effective use of the product. Assistance and consultation to the customer is provided as requested to support the use of the product or service. As a result of successful implementation of the process: customer support service needs will be identified and monitored on an ongoing basis; customer satisfaction with both the support services being provided and the product itself will be evaluated on an ongoing basis; operational support will be provided by resolving operational problems and handling customer inquiries and requests; customer needs will be met through delivery of appropriate services. F.1.5 Maintenance Process The purpose of the maintenance process is to manage modification, migration and retirement of the product in response to customer requests. The origin of requests might be a discovered problem or the need for improvement or adaptation. The objective is to modify and/or retire products while preserving the integrity of the organization's operations. As a result of successful implementation of the process: a maintenance strategy will be developed to manage modification, migration and retirement of products according to the release strategy; the impact of changes to the existing system on organization, operations or interfaces will be defined; specifications, design documents and test strategies will be updated; modified products will be developed with associated tests that demonstrate that requirements will not be compromised; product upgrades will be migrated to the customer s environment; on request, products will be retired from use in a controlled manner that minimizes disturbance to the customers. 13

23 F.2. Supporting Life Cycle Processes F.2.1 Documentation Process The purpose of the Documentation process is to develop and maintain the recorded software information produced by a process or activity. As a result of successful implementation of the process: a strategy identifying the documentation to be produced during the life cycle of the software product will be developed; the standards to be applied for the development of the software documentation will be identified; all documentation to be produced by the process or project will be identified; the content and purpose of all documentation will be specified, reviewed and approved; all documentation will be developed and made available for viewing in accordance with identified standards; all documentation will be maintained in accordance with specified criteria. F.2.2 Configuration Management Process The purpose of the Configuration management process is to establish and maintain the integrity of all the work products of a process or project. As a result of successful implementation of the process: a configuration management strategy will be developed; all items generated by the process or project will be identified, defined and baselined; modifications and releases of the items will be controlled; the status of the items and modification requests will be recorded and reported; the completeness and consistency of the items will be ensured; storage, handling and delivery of the items will be controlled. F.2.3 Quality Assurance Process The purpose of the Quality assurance process is to provide assurance that work products and processes of a process or project comply with their specified requirements and adhere to their established plans. As a result of successful implementation of the process: a strategy for conducting quality assurance will be developed, implemented and maintained; evidence of quality assurance will be produced and maintained; 14

24 problems or non-conformances with contract requirements will be identified; adherence of products, processes and activities to the applicable standards, procedures and requirements will be verified objectively. F.2.4 Verification Process The purpose of the Verification process is to confirm that each software work product and/or service of a process or project properly reflects the specified requirements. As a result of successful implementation of the process: a verification strategy will be developed and implemented; criteria for verification of all required software work products will be identified; required verification activities will be performed; identified defects will be found and removed from software work products; results of the verification activities will be made available to the customer and other involved parties. F.2.5 Validation Process The purpose of the Validation process is to confirm that the requirements for a specific intended use of the software work product are fulfilled. As a result of successful implementation of the process: a validation strategy will be developed and implemented; criteria for validation of all required work products will be identified; required validation activities will be performed; all identified problems will be resolved; evidence will be provided that the software work products as developed are suitable for their intended use; results of the validation activities will be made available to the customer and other involved parties. F.2.6 Joint Review Process The purpose of the Joint review process is to maintain a common understanding with the customer of the progress against the objectives of the contract and what should be done to help ensure development of a product that satisfies the customer. Joint reviews are at both project management and technical levels and are held throughout the life of the project. As a result of successful implementation of the process: periodic reviews will be held at predetermined milestones; 15

25 the status and products of an activity of a process will be evaluated through joint review activities between the customers, suppliers and other stakeholders (or interested parties); review results will be made known to all affected parties; action items resulting from reviews will be tracked to closure. F.2.7 Audit Process The purpose of the Audit process is to independently determine compliance of selected products and processes with the requirements, plans and contract, as appropriate. As a result of successful implementation of the process: an audit strategy will be developed and implemented; audits will be held at predetermined milestones; compliance of selected software work products and/or services or processes with requirements, plans and contract will be determined according to the audit strategy; the conduct of audits by an appropriate independent party will be arranged; problems detected during an audit will be identified, communicated to those responsible for corrective action, and resolved. F.2.8 Problem Resolution Process The purpose of the Problem resolution process is to ensure that all discovered problems are analyzed and resolved and that trends are recognized. As a result of successful implementation of the process: the problem resolution activities will be identified to ensure that all discovered problems are analyzed and resolved; problem reports will be prepared upon detection of problems (including non-conformances) in a software product or activity; a mechanism will be provided for recognizing and acting on trends in problems identified. F.2.9 Usability process The purpose of the Usability process is the consideration of the interests and needs of the individuals and/or groups which will work with or use the output from a system. As a result of successful implementation of this process: 16

26 design of systems will taking account of human capabilities, skills, limitations and needs; system usability will be given specific attention; human factors and ergonomics knowledge and techniques will be incorporated; human-centered design activities will be identified and planned in an effective and timely manner; potentially increased productivity enhanced quality of work, reductions in support and training costs; enhanced user effectiveness and efficiency improved human working conditions, and counteraction of possible adverse effects of use on human health, safety and performance; users will feel more empowered and motivated to learn. 17

27 F.3 Organizational Life Cycle Processes F.3.1 Management Process The Management Process is established by an organization to ensure the consistent application of practices for use at both the organization and the project. While these practices are inherent to the management of an organization, they are intended to be instantiated for use by a project. The Management Process includes purposes and outcomes for: Organization Management Project Management Quality Management Risk Management Organizational Alignment Measurement Asset Management Reuse Program Management Domain Engineering F Organization Management The purpose of the Organization Management is to organize, monitor, and control the initiation and performance of any processes or functions to achieve their goals in accord with the business goals of the organization. As a result of successful implementation of Organization Management: the scope of the activity to be managed will be defined; the activities and tasks that must be performed to achieve the purpose of the process or function will be identified; the feasibility of achieving process goals with available resources and constraints will be evaluated; the resources and infrastructure required to perform the identified activities and tasks will be established; plans for execution will be developed and implemented; activities will be identified and tasks will be implemented; performance of the defined activities and tasks will be monitored; work products resulting from the process activities will be reviewed and results analyzed and evaluated; action will be taken to modify the performance of the process or function when performance deviates from the identified activities and tasks or fails to achieve their goals; successful achievement of the purpose of the process or function will be demonstrated. F Project management The purpose of Project management is to identify, establish, coordinate, and monitor the activities, tasks, and 18

28 resources necessary for a project to produce a product and/or service, and to meet the project s requirements. As a result of successful implementation of Project management: the scope of the work for the project will be defined; the feasibility of achieving the goals of the project with available resources and constraints will be evaluated; the tasks and resources necessary to complete the work will be sized and estimated; interfaces between elements in the project, and with other project and organizational units, will be identified and monitored; plans for the execution of the project will be developed and implemented; progress of the project will be monitored and reported; actions to correct deviations from the plan and to prevent recurrence of problems identified in the project, will be taken when project targets are not achieved. F Quality management The purpose of the Quality management is to achieve customer satisfaction by meeting customer requirements. As a result of successful implementation of Quality management: quality goals based on the customer's stated and implicit quality requirements will be established; an overall strategy will be developed to achieve the defined goals; a quality management system will be established to implement the strategy; identified quality control and assurance activities will be performed and their performance confirmed; actual performance against the quality goals will be monitored; appropriate action will be taken when quality goals are not achieved. F Risk management The purpose of the Risk management is to identify and mitigate the risks continuously. As a result of successful implementation of Risk management: the scope of the risk management to be performed will be determined; appropriate risk management strategies will be defined and implemented; risks be identified in a strategy, and as they develop during the conduct of the project; the risks will be analyzed and the priority in which to apply resources to monitor these risks will be determined; risk metrics will be defined, applied, and assessed to determine the change in the risk state and the progress of the monitoring activities; appropriate action will be taken to correct or avoid the impact of risk. 19

29 F Organizational alignment The purpose of the Organizational alignment is to ensure that the individuals in the organization share a common vision and culture and understanding of the business goals to empower them to function effectively. Although business re-engineering and Total Quality Management have a much broader scope than that of software process, software process improvement occurs in a business context and, to be successful, must address business goals. As a result of successful implementation of Organizational alignment: a vision, mission, goals and objectives for the business will be made known to all employees; everyone in the organization understands their role in achieving the goals of the business and is able to perform that role. F Measurement The purpose of the Measurement is to collect and analyze data relating to the products developed and processes implemented within the organizational unit, to support effective management of the processes and to objectively demonstrate the quality of the products. As a result of successful implementation of Measurement: the organization needs of organizational and management processes will be identified; an appropriate set of measures, driven by the information needs, will be identified and/or developed; the data required will be collected and analyzed, and the analysis results interpreted; analysis results will be used to support decisions and provide an objective basis for communication between the interested parties; historical information on the success of measures relating to the information needs will be identified and their definitions retained; measurement will be regularly evaluated and improved. F Asset Management The purpose of the Asset management is to manage the life of reusable assets from conception to retirement. As a result of successful implementation of Asset management: an asset management plan will be documented; an asset storage and retrieval mechanism will be operated; the use of assets will be recorded; configuration management will be performed for the assets. 20

30 F Reuse program management The purpose of Reuse program management is to plan, establish, manage, control, and monitor an organization s reuse program. As a result of successful implementation of Reuse program management: define the organization s reuse strategy including its purpose, scope, goals and objectives; identify the domains in which to investigate reuse opportunities or in which it intends to practice reuse; assess the organization s systematic reuse capability; assess each domain to determine its reuse potential; prepare a reuse plan for implementing the practice of reuse in the organization; establish feedback, communication, and notification mechanisms that operate between reuse program administrators, asset managers, domain engineers, developers, operators, and maintainers; execute the reuse program implementation plan; monitor and evaluate the reuse program; improve the reuse program. F Domain engineering The purpose of Domain engineering is to develop and maintain domain models, domain architectures and assets for the domain. As a result of successful implementation of Domain engineering: the representation forms for the domain models and the domain architectures will be selected; the boundaries of the domain and its relationships to other domains will be established; a domain model that captures the essential common and different features, capabilities, concepts, and functions in the domain will be developed; a domain architecture describing the family of systems within the domain will be developed; assets belonging to the domain will be specified; assets belonging to the domain will be acquired or developed and maintained throughout their life cycles; the domain models and architectures will be maintained throughout their life cycles. F.3.2 Improvement Process The purpose of the Improvement Process is to establish, assess, measure, control, and improve a software life cycle process. The Improvement Process contains purpose and outcomes for: Process Establishment Process Assessment Process Improvement 21

31 F Process establishment The purpose of the Process establishment is to establish a suite of organizational processes for all life cycle processes as they apply to its business activities. As a result of successful implementation of Process establishment: a defined and maintained standard set of processes will be established, along with an indication of each process's applicability; the detailed tasks, activities and associated work products of the standard process will be identified, together with expected performance characteristics; a strategy for tailoring the standard process for the product or service will be developed in accordance with the needs of the project; information and data related to the use of the standard process for specific projects will exist and be maintained. F Process assessment The purpose of the Process assessment is to determine the extent to which the organization's standard processes contribute to the achievement of its business goals and to help the organization focus on the need for continuous process improvement. As a result of successful implementation of the process: an efficient and effective process assessment method will exist to determine the current capability of the organization and its processes to produce products and services consistent with its business goals; the relative strengths and weaknesses of the organization's standard processes will be understood; accurate and accessible assessment records will be kept and maintained; reviews of the organization's standard processes will be carried out at appropriate intervals to ensure their continuing suitability and effectiveness in light of assessment results. F Process improvement The purpose of the Process improvement is to continually improve the effectiveness and efficiency of the processes used by the organization in line with the business need. As a result of successful implementation of Process improvement: changes to standard and defined processes will be made in a controlled way, with predictable results; the organization will effect improvements to its processes through activities such as process assessment and review; 22