Critical Design Decisions in the Development of the Standard for Process Assessment

Similar documents
MEASURING PROCESS CAPABILITY VERSUS ORGANIZATIONAL PROCESS MATURITY

Mediterranean Journal of Social Sciences MCSER Publishing, Rome-Italy

Process Quality Levels of ISO/IEC 15504, CMMI and K-model

Defining Leadership as Process Reference Model: translating organizational goals into practice using a structured leadership approach

The Internal Consistency of the ISO/IEC Software Process Capability Scale

A Model for Business Process Management Maturity

Very Small Enterprises (VSE) Quality Process Assessment

TrialStat Corporation: On Schedule with High Quality and Cost Savings for the Customer*

Architecture Practice: a fundamental discipline for information systems

REQUIREMENTS MANAGEMENT AND ACQUISITION MANAGEMENT EXPERIENCES IN SPANISH PUBLIC ADMINISTRATIONS

Using Knowledge Management to Improve Software Process Performance in a CMM Level 3 Organization

Staged Representation Considered Harmful?

Applying ISO/IEC Software Engineering Standards in Small Settings: Historical Perspectives and Initial Achievements

Structured process improvements in facilities management organisations: Best practice case studies in the retail sector

Towards Higher Configuration Management Maturity

Leading Indicators for Systems Engineering Effectiveness Presentation for NDIA SE Conference October 28, 2009

IEEE s Recommended Practice for Architectural Description

Dr. Nader Mehravari Research Scientist, CERT Division

Full Cycle Real Time Assurance

An Information Model for Software Quality Measurement with ISO Standards

Changes to the SCAMPI Methodology and How to Prepare for a SCAMPI Appraisal

11 A software process model for business reengineering

Software Process Assessment

International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.1, January 2012 RISK MANAGEMENT MEASURES IN CMMI.

Applying Integrated Assurance Management Scenarios for Governance Capability Assessment

Moving On Up: Data and Experience Doing CMM-Based Process Improvement

SOFTWARE PROCESS IMPROVEMENT AT ABB KRAFTWERKSLEITTECHNIK GMBH

Design and Assessment for Agile Auditing Model: The Case of ISO 9001 Traceability Requirements

Systematic review of success factors and barriers for software process improvement in global software development

ProPAM: SPI based on Process and Project Alignment

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials

Benchmarking and library quality maturity Frankie Wilson and J. Stephen Town ABSTRACT

Process-Based Knowledge Management and Modelling in E-government An Inevitable Combination

CASE STUDIES IN CONSTRUCTION PROCESS IMPROVEMENT

Enterprise Architecture and COBIT

Transactions on Information and Communications Technologies vol 14, 1997 WIT Press, ISSN

What is the Systems Engineering Capability Model (SECM)?

Sales Operations Maturity Why Does It Matter?

SCRUM and the CMMI. The Wolf and the Lamb shall Feed Together

This document is a preview generated by EVS

Towards Higher Configuration Management Maturity

People - Introduction to People Capability Maturity Model (P-CMM )

Downloaded from: Usage Guidelines

ANALYZING SYSTEM MAINTAINABILITY USING ENTERPRISE ARCHITECTURE MODELS

intacs TM newsletter edition

Square model is better than Spiral Model to improve the process of IVR Software

Monitoring Human Recources through People-Capability Maturity Model (P- Cmm) in Ansar Bank

An Empirical Study of Industrial Requirements Engineering Process Assessment and Improvement

The Business Case for Systems Engineering: Comparison of Defense-Domain and Non- Defense Projects

Standards, Processes and Practice

Pre-Publication Version. The Application of International Software Engineering Standards in Very Small Enterprises

Feature. IT Governance and Business-IT Alignment in SMEs

Quality management/change management: two sides of the same coin?

Re-engineering IT Internal Controls: Applying Capability Maturity Models to the Evaluation of IT Controls

Implementing integration of quality standards CMMI and ISO 9001 : 2000 for software engineering

Selftestengine COBIT5 36q

EA Best Practice Workshop Developing an assessment and improvement framework for managing an EA Program

Towards a Reference Model of Business Model & Business Process Management Alignment

Managing Information Security Complexity

TOWARDS UNDERSTANDING THE DO-178C / ED-12C ASSURANCE CASE

Assessor Training Syllabus

Taba Workstation: Supporting Software Process Deployment based on CMMI and MR-MPS

PROJECT MANAGEMENT KNOWLEDGE RETRIEVAL: PROJECT CLASSIFICATION

DW9MU***«' iteds. Technical Report CMU/SEI-95-TR-003 ESC-TR

CMMI-DEV V1.3 CMMI for Development Version 1.3 Quick Reference Guide

UML Extension for Business Modeling

Update Observations of the Relationships between CMMI and ISO 9001:2000

Using Architectural Models to Predict the Maintainability of Enterprise Systems

Product Line Engineering Lecture PL Architectures I

Comparing Maturity Models: CMMI, OPM3 and P3M3. Why Maturity Models?

Nationwide Mutual Insurance Company embraces IBM DevOp approach and Continues Testing, improves software quality by 50 percent

INTERNATIONAL STANDARD

Key words: software quality, testing models, ISO/IEC 12119, cooperative model of testing.

The escm-sp v2: T H E e S O U R C I N G C A P A B I L I T Y M O D E L F O R S E R V I C E P R O V I D E R S ( e S C M - S P ) v 2

Product Line Engineering Lecture PLE Principles & Experiences (2)

Process Assurance Audits: Lessons Learned

Governance SPICE. Using COSO and COBIT Process Assessment Models BPM GOSPEL

A Proposition for a Service Systems Design Method *

A Maturity Model for Segregation of Duties in Standard Business Software

CMMI for Technical Staff

Analysis and design of production and control structures

A Maturity Model for Green ICT: The case of the SURF Green ICT Maturity Model

ISO INTERNATIONAL STANDARD. Risk management Principles and guidelines. Management du risque Principes et lignes directrices

Component-based Development Process and Component Lifecycle

A Framework for Maturity Assessment in Software Testing for Small and Medium-Sized Enterprises

CMMI ACQUISITION MODEL (CMMI-ACQ):

SOA Research Agenda. Grace A. Lewis

Scrum and CMMI Level 5: The Magic Potion for Code Warriors

Passit4Sure.OG Questions. TOGAF 9 Combined Part 1 and Part 2

DEVELOPMENT OF MBSE/UML MATURITY MODEL

A Survey and Comparison of Some Research Areas Relevant to Software Process Modeling

Achieving CMMI Level 2 with Enhanced Extreme Programming Approach

COMPARISON BETWEEN THE BUSINESS MODELLING METHODS PROVIDED BY MEASUR AND RUP

Braindumps COBIT5 50q

Creating an ITIL-based Multidimensional Incident Analytics Method: A Case Study

Chapter 15. Supporting Practices Service Profiles 15.2 Vocabularies 15.3 Organizational Roles. SOA Principles of Service Design

Pittsburgh, PA

ISO/IEC JTC1/SC7 N2683

Integrating CMMI and TSP/PSP: Using TSP Data to Create Process Performance Models

2014 REVIEW OF THE AACA NATIONAL COMPETENCY STANDARDS IN ARCHITECTURE (NCSA)

Transcription:

Critical Design Decisions in the Development of the Standard for Process Assessment Author Rout, Terry Published 2013 Conference Title Software Process Improvement and Capability Determination DOI https://doi.org/10.1007/978-3-642-38833-0_24 Copyright Statement 2013 Springer-Verlag Berlin Heidelberg. This is the author-manuscript version of this paper. Reproduced in accordance with the copyright policy of the publisher.the original publication is available at www.springerlink.com Downloaded from http://hdl.handle.net/10072/56584 Link to published version http://www.spiceconference.com Griffith Research Online https://research-repository.griffith.edu.au

Critical Design Decisions in the Development of the Standard for Process Assessment Terence P Rout Software Quality Institute Institute for Integrated and Intelligent Systems Griffith University Queensland 4111 AUSTRALIA T.Rout@griffith.edu.au Abstract. The development of an International Standard for Process Assessment commenced in 1993. Over the past 20 years, the standard suite has moved through three formal releases, and multiple drafts; during this time, several key design issues have been addressed, and in many cases reconsidered. This paper identifies key issues in the design of the Standard, and discusses decisions taken and their impact on the Standard, and on the theory and practice of process assessment. Keywords. Process assessment; standardization; process improvement 1. Introduction The technique of process assessment derives from the classical studies on process improvement of workers including Deming, Juran and Crosby; application of these concepts in studies such as reported by Radice [1] led to the development of the concepts of "model-based process improvement", and this evolved through the work of Humphrey [2] to the development of comprehensive models such as the CMM for Software [3]. The increasing popularity of this approach, and the increasing use of the technique by acquirers seeking to establish higher confidence in their suppliers, led to the establishment of a Study Group on the need for an International Standard addressing process assessment for software life cycle processes. The report of the Study Group [4] was accepted in 1992, leading to the initiation of work on the International Standard, ISO/IEC 15504. The initial working drafts of the Standard documents were developed by the SPICE Project, and published in 1995; based on these drafts, the development of the first version of ISO/IEC 15504 (as a Technical Report, Type 2) proceeded, released in 1998. In 1999, work to restructure the TR as a full International Standard commenced, with publication of the first five parts over the period 2003 2008. Since then, a further five parts of the Standard have been published; the current baseline is listed in Table 1.

Part 1 - Concepts and Vocabulary Published (12 Nov 2004) Part 2 - Performing an assessment Published (31 Oct 2003) Part 3 - Guidance on performing an assessment Published (6 Jan 2004) Part 4 - Guidance on use for process improvement Published (2 Jul 2004) and process capability deter- mination Part 5 - An exemplar Process Assessment Published (2012) Model 2 nd Edition Part 6 - An exemplar system life cycle process assessment model 2 nd Edition Approved for publication (2013); 1 st Edition published (2010) Part 7 - Assessment of organizational Published (25 Nov 2008) maturity Part 8 - An exemplar assessment model Published (2012) for service management processes Part 9 - Target process profiles Published (2012) Part 10 Safety Extension Published (2012) Table 1 ISO/IEC 15504 Current Status At present, a major restructuring project is in progress, to redevelop the standard from a single, multi-part document to a set of related documents. In the course of this work, many of the design decisions taken over the course of development have been revisited; the purpose of this presentation is to summarise some of the critical decisions taken, and explore the rationale behind them. 2. Key Design Issues Design issues evolved over the course of the development of the standard suite, and impacted most of the key aspects of the technique of process assessment. It is important to note that the level of theoretical understanding of process assessment has evolved along with the development of the Standards, with each driving the other. Key features of the domain, where critical decisions were debated, include the following. Domain Scope for the Standard The most obvious decision taken in relation to the Standard suite as a whole is the extension of scope, from a limited "Software Process Assessment" in the TR to the current scope of "Information technology Process assessment". The decision was taken as part of the revision of the TR; while there was some discussion, it was seen as consistent with the overall extension in scope of the Standards Committee from "Software Engineering" to "Systems and Software Engineering"; it was also consistent with growing application of the technique of process assessment to other domains, in some cases well outside the field of Information Technology. Most recent-

ly, the extension of scope to address IT Service Management is another important decision; this was driven essentially by the adoption of this domain into the scope of JTC1/SC7. A further change in the scope of the Standard came with the development of Part 7 Assessment of Organizational Maturity. The original Study Group report was very firm in rejecting an approach based on providing any "single number" result of assessment, providing for the definition of a profile of Process Capability. Over time, the link between defined Process Capability Profiles and Organizational Maturity was recognized, and the extension of scope became possible. It is also significant that as the Standard moved towards recognition of Maturity Levels, the CMMI explicitly recognized the Continuous Representation. Definition and Measurement of Processes The approach to defining and measuring (assessing) processes has changed substantially over the course of development, and with the evolution to the 330xx series is likely to change still more. The original Baseline Practices Guide, in the SPICE document set, defined its own architecture for software life cycle processes, and defined these processes in terms of sets of Base Practices, following the pattern of the Capability Maturity Model. This led to a considerable debate concerning the relationship between the architecture in the BPG, and that established in ISO/IEC 12207 Software Life Cycle Processes. The outcome was the establishment of the concept of the Process Reference Model, to serve as a repository of process definitions for a domain, and of the approach of defining processes in terms of purpose and outcomes. The use of the Process Reference Model also opened the door to the broadening of scope of the Standard, referred to above. It made possible the adoption and development of additional process models, either as expansions to those currently available (e.g., Automotive SPICE [7]) or as an extension to new fields of interest (e.g. Enterprise SPICE [8] and the COBIT Assessment Model [9]). In parallel with the adoption of the Reference Model concept came the development of the Measurement Framework for Process Capability, a meta-level framework that addressed many of the problems identified in the Baseline Practices Guide. In the BPG, while the definitions of the Capability Levels were clear, the distribution of components across the scale was uneven Level 2 in the BPG contained 4 "common features" and a total of 12 "generic practices". In the revised Framework, levels from 2 to 5 all contained two "Process Attributes", which were the core elements in rating capability. What appears to be the most significant decision taken over the 20 years of the development has been one of the most recent: the expansion of the technique of process assessment to cover process characteristics other than capability. This has resulted in the definition of a set of meta-level requirements for Measurement Frameworks, and has had a major impact on the terminology to be employed in the new Standard suite. It will be most interesting to see what the final impact of the decision will be.

Performing Assessment The definition of a clear meta-level framework for processes and process capability impacted in turn on the approach for assessing capability. The definition of the Measurement Framework drove a significant change in the ratings mechanism; in the SPICE documents, each Base Practice or Generic Practice was rated for adequacy, and an overall rating was derived from a formal combination of the individual practice ratings, based on equal weightings. The basic scale for rating "adequacy", however, was a four-point ordinal scale (N P L F) which is still retained. The approach resulted in the need for a very large number of individual ratings to be determined, and then weighted. The adoption of the Measurement Framework resulted in a much simpler approach with a significantly lower workload; two Process Attributes were rated at each Capability Level above 1. The derivation of ratings was also impacted by decisions on the scope of the assessment. In the development of the SPICE Documents, the decision was that the scope of rating was to be the process instantiation, and this was retained through to the Preliminary Draft Technical Report ballot. At this stage, considerations of the difficulties encountered in consistent identification of instantiations led to the adoption of a requirement to rate Process Attributes across the whole scope of the assessment. The introduction of the concepts of assessment of organizational maturity, with the accompanying need for greater rigor in the conduct of the assessment, has led to the reintroduction of identification of instantiations.. This has had a significant impact on the redesign of the assessment framework, requiring definition of an agreed approach to aggregation of ratings and characterizations of process performance. The final impact of this on the rating approach is yet to be determined. 3. Impact The design changes taken since the commencement of the standards development have been substantial, and have had a major impact on the development of the Standard, and also on its adoption and on the conduct of process assessment. It is noteworthy that many of the decisions were made with the support of empirical studies conducted through the SPICE Trials [10, 11], and that these investigations have generally supported the decisions taken. The changes to the Standard have simplified the approach to exploring process capability, and have made the development of appropriate process models and tools simpler. The changes also opened up additional domains to the adoption of techniques of model-based improvement (through assessment) and benchmarking of organizational achievement. It remains to be seen what the effect of the most recent changes will be; certainly we can be optimistic that they will result in the development of opportunities to understand the operations and characteristics of processes implemented in organizations more clearly.

4. References 1. Radice, R.A., Harding, J.T., Munnis, P.E., Phillips, R.W., 1985. A Programming process study. IBM Systems Journal 24(2), 91-101. 2. Humphrey, W.S., Managing the Software Process. Reading, MA: Addison- Wesley, 1989. 3. M. Paulk, B. Curtis, M.B Chrissis, and C.V. Weber, Capability Maturity Model for Software, Version 1.1. Technical Report CMU/SEI-93-TR-24, Software Engineering Institute, Pittsburgh, February 1993. 4. ISO/IEC JTC1/SC7, 1992. The Need and Requirements for a Software Process Assessment Standard, Study Report, Issue 2.0, JTC1/SC7 N944R, 11 June. 5. ISO/IEC TR 15504: 1998 Information Technology Software Process Assessment, Parts 1 9. 6. ISO/IEC 15504: 2003-2012 Information Technology Process Assessment, Parts 1 10. 7. Automotive, S. I. G. "Automotive SPICE Process Assessment Model." Final Release, v4 4 (2010): 46. 8. Enterprise SPICE. An enterprise integrated standards-base model (2008), http://www.enterprisespice.com/ 9. ISACA (2011), COBIT Process Assessment Model (PAM), Using COBIT 4.1. 10. Ho-Won Jung, Robin Hunter, Dennis R. Goldenson and Khaled El-Emam, "Findings from Phase 2 of the SPICE Trials", Softw. Process Improve. Pract. 2001; 6: 205 242 11. Terence P. Rout & Khaled El Emam & Mario Fusani & Dennis Goldenson & Ho-Won Jung 2007, 'SPICE in retrospect: Developing a standard for process assessment', in Journal of Systems and Software, vol.80, no.9, Elsevier, Amsterdam.