Expert Systems Technology

Zagazig University Faculty of Computers and Informatics

Enhancing Software Process Improvement Models Capabilities A Doctoral Dissertation

By

Alshaimaa Adel Tantawy Abdou Lecturer - Information Systems Department College of Computers and Informatics - Zagazig University

Submitted to Faculty of Computers and Informatics-Zagazig University In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in Information Systems

Supervision Committee Prof. Abdel-Nasser

Hussien Zaied

Prof. of Information Systems Dean, College of Computers and Informatics

Prof. Khalid

Aly Eldrandaly

Prof. of Information Systems Vice dean for education and students CIO

INFORMATION SYSTEMS DEPARTMENT FACULTY OF COMPUTERS AND INFORMATICS ZAGAZIG UNIVERSITY – EGYPT

[October 2017]

CERTIFICATION This Ph.D. dissertation is submitted to the information systems department in the faculty of computers and informatics - Zagazig University – Egypt for the degree of doctor of philosophy in information systems. I certify that this work has not been accepted in substance for any academic degree or qualification in any other university or institution and is not currently being submitted in candidature for any other degree. Any portions of this Ph.D. thesis for which I am indebted to other sources are mentioned and explicit references are given.

Researcher Name: Alshaimaa Adel Tantawy Abdou Lecturer in Information Systems Department College of Computers and Informatics Zagazig University

Date: 23/10/2017 Signature:

ACKNOWLEDGEMENTS In the name of Allah, The Almighty, the Most Gracious, the Most Merciful, first and for most, I thank Allah who has helped and guided me throughout my entire life. I wish to express my sincere appreciation and thanks to my supervisors; Prof. Zaied and Prof. Eldrandaly, for their encouragement, supervision, constructive feedback, and for sharing with me their ideas and providing me with valuable papers from which I learned great deal. Special thanks to Dr. Nissreen ElSaber for her valuable suggestions, and suitable assistance. I would like to express my gratitude to Eng. Yasser Ghanim (CMMI Expert in SECC), and the CITC staff. They graciously provided relevant data and information which proved to be extremely important to the completion of this thesis.

Superior Appreciations for Prof. Ahmed Abou ElFetouh and Prof. Mohammed Monir for their participation in the examination committee. Superior Thanks, The SPI-CMMI ontology was conducted using the Protégé resource, which is supported by grant GM10331601 from the National Institute of General Medical Sciences of the U.S National Institutes of Health.

To my beloved father, be happy and proud in the Heaven, Amen. To my dear mother, thank you for your kind prayers. Last, but not Least, I could not forget the immense love and continuous support of my family, without their love, support, and encouragement, life could never be so enjoyable.

Abstract

ABSTRACT Recently software has become a vital resource for most industries and applications in several fields, so ensuring the quality and efficiency of this software has become an essential requirement for most companies. Therefore, software organizations are seeking to improve their software quality, the complications related to lack of quality can basically put a software organization out of business. The requirement to confirm high levels of software quality motivates organizations to adopt software improvement models to improve their software development process. Various international improvement models, such as; International Standardization Organization (ISO), Capability Maturity Model Integration (CMMI), Software Process Improvement and Capability dEtermination (SPICE), Trillium, Total Quality Management (TQM) approach, Six Sigma approach…etc., are developed. Numerous software development companies have chosen to utilize CMMI to access and improve their current software development processes, because CMMI is one of the most widespread and acknowledged improvement models. The CMMI model is classified as a Benchmark-based approach that prescriptive in nature, defining requirements or recommending a set of theoretical practices, it does not provide a practical procedure of determining how to improve the process. It hasn't and prioritization guide to help organizations select the most important and critical process area. That is, CMMI defines "what to do" but leaving "how/why to do it" to organizations. Thus, it is desirable to have practical means to guide the software companies in the improvement journey. Instead, the analytical improvement approaches are based on strategies that target first, to define business, process and product objectives and then establish a clear understating of the impact of process performance in these objectives, such as; Six Sigma approach. Therefore, a recent trend in software process improvement is the adoption of more than one improvement model into a single organizational environment, creating what are entitled multi-model environments. There can be different situations in which the usage of multiple approaches is desirable, exactly as in this research that aims to utilize the multimodel environment within software process improvement through incorporating the theoretical improvement models within the practical ones in order to get a comprehensive practical improvement methodology to be implemented in the software development organizations more effectively and precisely for enhancing the capabilities of the software process improvement models, in this dissertation the CMMI for Development (CMMI-Dev v1.3) model is selected to enhance its capabilities through proposing a practical improvement methodology that is based on integrating the Six sigma approach [analytical toolkits, candidate techniques and Define-Measure-Analysis-Improve-Control (DMAIC) methodology] and Quality Function Deployment (QFD) technique within the CMMI-Dev v1.3 model.

[i]

Abstract The proposed structured methodology helps to optimize and improve the most important and critical organization processes in addition to facilitating the adoption process of the CMMI-Dev model, thus it is named the proposed SPI-CMMI framework. It supports both the staged and continuous representations of the CMMI-Dev model and can be adopted in any size software organization. The significance intention of this integration is the incorporation of their best practical and theoretical practices in a comprehensive improvement strategy, that otherwise would not be possible to obtain by a single technological approach. Hence, the proposed SPI-CMMI framework fills in "what/how/why" technologies combination which provides theoretically what improvement processes should be done to satisfy most of the critical stakeholders' requirements, such as; customer, management, government, quality, and business, as well as practically how the organization and improvement processes can be implemented effectively using the analytical toolkits, appropriate techniques, and the detailed activities or action plans. The proposed SPI-CMMI framework is described in details with its structured phases, sequential steps, tasks, and action plans within the recommended analytical toolkits, candidate techniques, and methods selected from the six sigma approach. For enhancing and modifying the proposed SPI-CMMI framework; it is revised and estimated from the improvement and the CMMI professionals in the Software Engineering Competence Center (SECC) center which related to the communication ministry in order to modify it and confirm its validity through answering the corresponding validation questionnaire. Also, the proposed SPI-CMMI framework is compared with the previous multimodels according to a specific set of criteria via the characteristics comparison technique in order to describe its advantages. After that an ontological structure of the knowledge representation, retrieval, and query for the proposed SPI-CMMI framework is developed using the ontology engineering with the OWL ontology language that is constructed using the OWL-protégé editor. Finally, the proposed SPI-CMMI framework is implemented as a prototype to a real case study in the Communication and Information Technology Center (CITC) center in Zagazig University in order to specify to what extent it is able to accomplish the acceptable improvement degree and performance level. Its partial implementation in CITC center provides acceptable results and positive effects.

[ii]

Tables of Contents

TABLES OF CONTENTS Contents

Page

Abstract …………………………………………………………………..………...

i

Tables Of Contents ……………………………………………………….…..……

iii

List Of Abbreviations ……………………………….…………………….…..…...

vi

List Of Figures ...…..……………………………………………………….…..…...

vii

List Of Tables ……………………………………………………………….….…..

viii

CHAPTER ONE: INTRODUCTION

1

1.1 Background and Motivation ……………………….…………………………….

1

1.2 Research Problem …………….…….…………………………………………… 2 1.3 Research Contribution and Scope ……………….………………………………

3

1.4 The Research Methodology …..……………….………………………………… 4 1.5 The Thesis Outlines …………….…….………………………………………….

5

CHAPTER TWO: LITERATURE BACKGROUND AND RELATED WORK

6

2.1 Introduction ……………………………………………………………………... 2.2 Software Process Improvement (SPI) …………………………………………... 2.2.1 SPI Concepts …………………………………………………………….. 2.2.2 The SPI Lifecycle ………………………………………………………… 2.2.3 Software Process Improvement Approaches ...…………………………… 2.2.4 The Importance of SPI Standards ………………………………………… 2.3 The Multi-model Environments .……………………………………………….. 2.3.1 Multimodel Environments Description ………………………………….. 2.3.2 Multi-model Environments Survey ………………………………………. 2.4 Capability Maturity Model® Integration (CMMI®) ……………………….......... 2.4.1 A Brief History of CMMI ………………………………………………... 2.4.2 CMMI-DEV v1.3 Structure and Design ………………………………..... 2.4.3 CMMI-DEV 1.3 Implementation ………………………………………… 2.4.4 Motivations to select the CMMI Model ………………………………..... 2.4.5 CMMI Model Criticism ………………………………………………….. 2.4.6 CMMI Literature Survey …………………………………………………. 2.4.6.1 CMMI and ISO …………………………………………………... 2.4.6.2 CMMI and Agile ………………………………………………….

6 6 6 8 9 10 11 11 12 13 13 14 14 16 16 17 18 19

2.5 Six Sigma Approach …………………………………………………………...... 20

[iii]

Tables of Contents 2.5.1 Six Sigma History ………………………………………………………... 20 2.5.2 Six Sigma Description ……………………………………………………. 20 2.5.3 DMAIC Methodology ……………………………………………………. 2.5.4 CMMI and Six Sigma ………………………………………………….....

21 22

2.6 Quality Function Deployment (QFD) …………………………………………... 2.6.1 QFD Description ………………………………………………………..... 2.6.2 CMMI and QFD ………………………………………………………......

24 24 25

2.7 The Ontology Technical Background …………………………………………... 2.7.1 Ontology Definition ……………………………………………………… 2.7.2 Ontology Engineering ……………………………………………………. 2.7.3 Ontology Components ……………………………………………………. 2.7.4 Ontology Languages ……………………………………………………… 2.7.5 CMMI and Ontology Literature Survey ………………………………….. 2.8 Summary …………………………………………………………………………

25 25 26 26 27 28 29

CHAPTER THREE: THE PROPOSED FRAMEWORK

31

3.1 Introduction ……………………………………………………………………...

31

3.2 The Proposed SPI-CMMI Framework …………………………………………..

31

3.3 The Detailed Explanation of SPI-CMMI Framework …………………………... 3.3.1 Phase 1: Improvement Project Initiation …………………………………. 3.3.2 Phase 2: Performance Management and Success Metrics Derivation …… 3.3.3 Phase 3: Requirements Collection and Prioritization …………………….. 3.3.4 Phase 4: CMMI-DEV Process Areas Prioritization ……………………… 3.3.5 Phase 5: CMMI Specific Goal Prioritization …………………………….. 3.3.6 Phase 6: Specific Practices Prioritization ………………………………… 3.3.7 Phase 7: Action Plans Derivation and Prioritization ……………………... 3.3.8 Phase 8: Action Plans and Specific Practices Implementation …………... 3.3.9 Phase 9: CMMI Capability Levels Interpretation ………………………... 3.3.10 Phase 10: Capability Levels Activities Implementation ………………... 3.4 Summary …………………………………………………………………………

33 33 38 39 40 41 41 42 42 43 46 49

CHAPTER FOUR: THE ONTOLOGY REPRESENTATION OF THE SPI- 51 CMMI FRAMEWORK 4.1 Introduction ……………………………………………………………………... 4.2 OWL Ontology Language ………………………………………………………. 4.3 Structure of the SPI-CMMI Ontology …………………………………………... 4.4 Naming Conventions in OWL ontology ………………………………………… 4.5 The SPI-CMMI Ontology Components ………………………………………… 4.6 Class Creation in OWL Ontology ……………………………………………….

[iv]

51 52 54 54 56 57

Tables of Contents 4.7 Properties in OWL Ontology ……………………………………………………. 4.8 Design Criteria for SPI-CMMI ontology ……………………………………….. 4.9 Ontology Reasoners ……………………………………………………………... 4.10 Benefits of the SPI-CMMI Ontology ………………………………………….. 4.11 Summary ………………………………………………………………………..

59 66 67 69 69

CHAPTER FIVE: THE SPI-CMMI FRAMEWORK IMPLEMENTATION 70 AND VALIDATION 5.1 Introduction ………………………………………..……………………………

70

5.2 The Multimodels Comparative Study …………………………………………... 70 5.2.1 Characteristics Comparison Technique …………………………………... 70 5.2.2 The Description of the Comparison Characteristics ……….…………….. 70 5.3 The Evaluation of the Proposed SPI-CMMI Framework ……………………….. 5.3.1 The SPI-CMMI Framework Benefits …………………………………….. 5.3.2 The Implementation Requirements ………………………………………. 5.3.3 The SPI-CMMI Framework Revision ………………………………….. 5.4 The Validation Process ………………………………………………………… 5.5 The Case Study ………………………………………………………………… 5.5.1 The CITC Center Description …………………………………………… 5.6 The Implementation Process …………………………………………………… 5.6.1 Improvement Project Initiation ………………………………………….. 5.6.2 Performance Management and Success Metrics Derivation ……………... 5.6.3 Requirements Collection and Prioritization ……………………………… 5.6.4 CMMI-Dev Process Areas Prioritization ………………………………… 5.6.5 The Assessment Process for the MIS unit in CITC ………………………. 5.6.6 Action Plans Derivation/ Implementation………………………………… 5.7 The Implementation Results …………………………………………………….. 5.8 Summary ………………………………………………………………………… CHAPTER

SIX:

CONCLUSIONS, FUTURE RECOMMENDATIONS

WORK

74 74 75 75 76 76 76 77 78 81 82 82 83 85 88 88

AND 89

6.1 Summary and Conclusions ……………………………………….……………... 6.2 Future Work and Recommendations …………………………………………….

89 90

REFERENCES ...……………………………………………………….………….

91

APPENDIX (A): The Suggested Six Sigma Toolkits for CMMI PAs ………….....

95

APPENDIX (B): The Validation Questionnaire of The SPI-CMMI framework …...

101

ARABIC SUMMARY

[v]

List of Abbreviations

LIST OF ABBREVIATIONS Abbreviation AG AND BOOTSTRAP BPR CBPA CITC CMM CMMI CMMI-ACQ CMMI-DEV CMM-SW CTQ DFSS DMAIC DOE FMEA GG GOSPA GP GQM HOQ ISO IT ITIL MPQP MSA OKBC OWL QFD RACI SECC SEI SG SIPOC SMART SME SP SPA SPC SPI SPICE SPI-CMMI SWOT TQM TRILLIUM VOB/ VOC WBS

Definition Agile Manufacturing Activity Network Diagram European software process assessment/improvement methodology Business Process Reengineering/Redesign Correlation-Based Priority Assessment Communication and Information Technology Center Capability Maturity Model Capability Maturity Model Integration Capability Maturity Model Integration for Acquisition Capability Maturity Model Integration for Development Capability Maturity Model for software Critical To Quality Design for Six Sigma Define-Measure-Analysis-Improve-Control Design of Experiment Failure Modes and Effects Analysis Generic Goal Goals, Objectives, Strategies, Plan, and Actions Generic Practice Goal-Question-Metric House of Quality International Standardization Organization Information Technology Information Technology Infrastructure Library Market Perceived Quality Profile Measurement System Analysis Open Knowledge Base Connectivity Web Ontology Language Quality Function Deployment Responsible, Accountable, Consulted, and Informed Software Engineering Competence Center Software Engineering Institute Specific Goal Supplier-Inputs-Process-Outputs-Customer Specific-Measurable-Achievable-Realistic-Time-bounded Subject Matter Experts Specific Practice Software Process Assessment Statistical Process Control Software Process Improvement Software Process Improvement and Capability dEtermination Software Process Improvement- Capability Maturity Model Integration

Strengths-Weaknesses-Opportunities-Threats Total Quality Management Telecommunication product development and support capability Voice of Business/ Voice of Customer Work Breakdown Structure

[vi]

List of Figures

LIST OF FIGURES Figure

Page

Figure 1.1: The Research Structured Plan ……………………….…………………….

4

Figure 2.1: The Business Improvement Dimensions ………………………………….

6

Figure 2.2: Software Process Improvement Framework ………………………………

8

Figure 2.3: The SPI Life Cycle ………………………………………………………..

9

Figure 2.4: The History of CMMI Evolution ………………………………………….

13

Figure 2.5: Structure of the CMMI-Dev Representations ……………………………..

15

Figure 2.6: The DMAIC Process-step Structure ………………………………………

21

Figure 2.7: House Schematic of QFD Phases …………………………………………

24

Figure 3.1: The successive steps of SPI-CMMI framework …………………………..

32

Figure 3.2: The Illustration of SPI-CMMI Phases …………………………………….

34

Figure 4.1: The Initial Formalization of the SPI-CMMI ………………………………

55

Figure 4.2: The Detailed Formalization of the SPI-CMMI ……………………………

56

Figure 4.3: The Class Hierarchy of SPI-CMMI Ontology using Protégé ……………..

58

Figure 4.4: The Second Level of SPI-CMMI Ontology using Protégé ……………….. 63 Figure 4.5: Structure of the SPI-CMMI Ontology using Protégé ……………………..

64

Figure 4.6: The CMMI-Dev representation in SPI-CMMI Ontology ……………..….

65

Figure 4.7: The Consistency Checking of SPI-CMMI Ontology …………….……….. 67 Figure 4.8: Classification of the SPI-CMMI Ontology …………………………….….

68

Figure 4.9: Computing inferred types of SPI-CMMI Ontology …………………..…... 68 Figure 5.1: The SIPOC document for software development process ………………...

79

Figure 5.2: The process map for software development process ……………………...

79

[vii]

List of Tables

LIST OF TABLES

Table

Page

Table 2.1: Comparison of Levels in CMMI Dev v1.3 ………………………………..

15

Table 3.1: The Six Sigma toolkits of the OPD process area …………………………..

43

Table 3.2: The suggested activities of DMAIC with CL2 …………………………….. 45 Table 3.3: The suggested activities of DMAIC with CL3 ………………..…………… 46 Table 3.4: The DMAIC-Define Tasks-Tools- Deliverables …………………………..

46

Table 3.5: The DMAIC-Measure Tasks-Tools- Deliverables …………………………

47

Table 3.6: The DMAIC-Analyze Tasks-Tools- Deliverables …………………………

48

Table 3.7: The DMAIC- Improve Tasks-Tools- Deliverables ………………………...

48

Table 3.8: The DMAIC-Control Tasks –Tools – Deliverables ……………………….

49

Table 3.9: The Brief Description of the SPI-CMMI phases …………………………..

50

Table 4.1: Examples of Components in SPI-CMMI Ontology ………………………..

57

Table 4.2: Object Properties in the SPI-CMMI Ontology …………………………….. 62 Table 5.1 (a): The comparative study of the SPI-CMMI framework ………..………... 72 Table 5.1 (b): The comparative study of the SPI-CMMI framework ………..………... 73 Table 5.2: An example of the process inventory document …………………………...

80

Table 5.3: An example of the capability levels assignment …………………………...

80

Table 5.4: The Goal-Question-Metric approach of CITC center ……………………...

81

Table 5.5: The assessment process of the MIS unit in CITC center …………………..

84

[viii]

Chapter one

Introduction

Chapter One: Introduction

Chapter one

Introduction 1.1 Background and Motivation Currently Software has become an essential resource for many businesses and applications in numerous fields, thus most companies have to confirm the quality and efficiency of the required software. Therefore, software organizations are seeking to improve software quality. The need to ensure high levels of software quality motivates organizations to adopt approaches to improve their software development process and help them maintain their competitiveness. Thus, it is necessary to have systematic means to guide the software companies in the development of the required steps, procedures, and action plans with the appropriate toolkits and templates for executing the improvement project. Software Process Improvement (SPI) is a systematic procedure to improve the performance of an existing process system by changing the current processes or updating new processes to correct or avoid problems identified in the old process system by means of a process assessment. Various international SPI models, tools, technologies, and standards are developed. The SPI models and standards can be classified into two groups: the benchmarking or model based approach that describe theoretical best practices (what should be done), as for example ISO 9001 and CMMI, on the other hand, the analytical approaches are based on strategies that aim first, to define business, process and product objectives and then establish a clear understating of the impact of process performance in these objectives, such as; Six Sigma approach. Therefore, a current trend in software process improvement is the adoption of more than one improvement model into a single organizational environment, creating what are called multi-model environments. There can be different situations in which the usage of multiple approaches is needed, for example to strengthen a particular process with various aspects of multiple improvement approaches, to reach certification of compliance to a number of standards, or to learn the software organization how to implement the improvement model practices effectively in practical manner. As an effort for assisting organizations in the selection of the right implementation of improvements, multi-model environments are arised enabling the use of best practices from various reference models. Multi-model approach facilitates the improvement task in order to achieve the organization’s business goals. In this context, effective integration of models and standards can play a crucial role in the implementation of multi-model environments as reference support tool. Hence, this research adopt multi-model approach for enhancing the capabilities of the CMMI model in order to guide the software organizations achieve the process and product improvement more efficiently and get the CMMI accreditation.

[1]


1.2 Research Problem Numerous software development companies have chosen to utilize the CMMI model to access and improve their current software development process, as CMMI is one of the most widespread and acknowledged improvement models. CMMI model classifies as a Benchmark-based approach that prescriptive in nature, defining requirements or advising a set of theoretical practices, so CMMI model has some drawbacks; such as,  It does not provide a practical/analytical procedure of determining how to improve the organization processes. That is, CMMI defines "what to do" but leaving "how/why to do it" to organizations.  There is no effective/analytical tool to assist managers in determining the priorities of the CMMI process areas (No guidance on where to start improvements).  CMMI does not have structured methodology or precise steps for making the process improvements themselves.  There are no sufficient metrics to determine if process improvements are effective, measures and metrics require definition, collection and analysis to establish a baseline prior to the improvement.  The software organization takes long time and various resources in order to satisfy the requirements of specific maturity level in CMMI model. Therefore, this research aims to utilize the multi-model approach within software process improvement through merging the theoretical improvement models within the practical ones in order to get a comprehensive theoretical/practical improvement methodology to be implemented in the software development organizations more effectively and precisely for enhancing the capabilities of the CMMI model. Six Sigma is a process improvement management framework to achieve bottom-line results, and customer’s loyalty. In short the objective of Six Sigma is the implementation of a measurement based strategy that is focused on process improvement and variation reduction. Six Sigma proposes software quality improvement approach called DMAIC (Define, Measure, Analyze, Improve and Control). Six Sigma helps in improving capability of an organization by providing various statistical tools, analytical techniques and methods which help companies to achieve their goals by setting a business strategy. The Quality Function Deployment (QFD) technique is best viewed as a prioritization technique and planning tool that relates a list of delights, wants, and needs of customers to design technical functional requirements. With the application of QFD, possible relationships are explored between quality characteristics as expressed by customers and substitute quality requirements expressed in engineering terms. QFD technique helps the organization select the most critical process area within the CMMI model.

[2]


1.3 Research Contribution and Scope For enhancing the capabilities of the software process improvement models, this dissertation aims to propose a theoretical/practical improvement methodology to be implemented specifically within the software organizations aimed to adopt the CMMI for Development (CMMI-Dev) model. The proposed improvement methodology provides activities, tasks, and action plan to be performed, in addition to the recommended analytical toolkits, candidate techniques and methods to be implemented in the software organization in order to achieve the required improvement and adopt the CMMI-Dev model more successfully and effectively. Thus, this methodology is called the proposed SPI-CMMI framework. The proposed SPI-CMMI framework is based on employing organization assessment and improvement procedures through consolidating the six sigma approach (statistical toolkits, analytical techniques, and DMAIC methodology) and the Quality Function Deployment (QFD) technique within the CMMI-Dev v1.3 model for both the staged and continuous representations. The following objectives constitute the research scope: 1. Suggesting an effective methodology for enhancing the capabilities of the CMMI model. 2. Facilitating and supporting the adoption process of the CMMI model in the software development organizations. 3. Proposing a comprehensive improvement methodology with the appropriate action plans and the candidate toolkits and techniques. 4. Developing an ontological structure of the proposed improvement framework using the ontology engineering technology for the purpose of knowledge management. 5. Implementing the proposed improvement framework to a real case study in order to examine its validity.

1.4 The Research Methodology This section describes the sequence and action plans taken to examine the research problem and the justification for the application of specific procedures and techniques used to identify, select, process, and analyze information applied to understanding and manipulating the research problem as represented in this dissertation.

[3]

Chapter One: Introduction Figure 1.1 describes the structured methodology for conducting this dissertation, showing the sequential steps for performing this research.

Literature Review

Studying the multimodel approaches

CMMI Model

Six Sigma Approach

QFD Technique

Proposing the improvement methodology

Designing phases and steps of the proposed SPI-CMMI framework

Designing the validation questionnaire for the proposed SPI-CMMI framework revision

Ontology Literature Review

Real Case Study Data

Developing the Ontological Representation of the proposed SPI-CMMI framework

Validating the proposed SPI-CMMI framework

Figure 1.1: The Research Structured Plan

[4]


1.5 The Thesis Outlines This section presents the structure arrangement of this dissertation and describes briefly the contents related to each part. This dissertation consists of six chapters, references list, and two appendixes. The thesis chapters are arranged as follows:

Chapter Two: Literature Background and Related Work This chapter discusses the current state of the art of software process improvement, multimodel environment, CMMI-DEV model, Six Sigma approach, quality function deployment (QFD) technique, in addition to Ontology engineering, definition, components, and languages.

Chapter Three: The Proposed Framework based on Six Sigma, QFD, and CMMI This chapter presents the detailed description of the suggested stages, their corresponding steps and activities with the recommended toolkits and techniques of the proposed improvement methodology in this research.

Chapter Four: The Ontology Representation of the SPI-CMMI Framework This chapter describes how ontology engineering with the OWL language is used in this research in order to build a computerized version of the proposed SPI-CMMI framework with its phases, related activities, recommended toolsets and the CMMI-Dev 1.3 representation.

Chapter Five: The SPI-CMMI Framework Implementation and Validation This chapter describes the comparative study of the proposed SPI-CMMI framework with the previous multimodels through using the characteristics comparison technique. In addition to, the revision process and evaluation process of the proposed SPI-CMMI framework through the validation questionnaire which is answered by the quality and CMMI experts from the SECC center and the validation process through implementing the main parts of the SPI-CMMI framework on a real case study.

Chapter Six: Conclusions, Future work and Recommendations This chapter presents a summary of the research findings and its significance. Suggestions for improvement and future work are also discussed.

[5]

Chapter Two Literature Background and Related Work

Chapter Two: Literature Background and Related Work

Chapter Two Literature Background and Related Work 2.1 Introduction Nowadays, software firms are playing very significant roles in economies all over the world. That is why they are obligated to identify managed structure and improve their processes systematically, as software has long been one of the most difficult challenges faced by many businesses and it is a major asset of many organizations in various fields. High rates of failure, rework and cost of poor quality consume a large share of software resources. This chapter discusses the current state of the art of software process improvement, multimodel environment, CMMI-DEV model, Six Sigma, quality function deployment (QFD), and ontology engineering definition, components, and languages.

2.2 Software Process Improvement (SPI) 2.2.1 SPI Concepts Today, technology is changing at an incredible speed in the dynamic world. In its research to help organizations to develop and maintain quality products and services, the Software Engineering Institute (SEI) has found several dimensions that software organization can focus on to improve its business. Figure 2.1 below illustrates the three critical dimensions that organizations typically focus on: people, procedures and methods, and tools and equipment. Processes hold everything together and allow the enterprises to align the way they do their business and provide a way to incorporate knowledge of how to do tasks better. Also, processes allow to leverage the resources and to examine business trends [1]. Procedures and methods defining the relationship of tasks

Tools, Techniques, and Equipments

People with skills, training, and motivation

Figure 2.1: The Business Improvement Dimensions [1]

[6]

Chapter Two: Literature Background and Related Work A focus on process provides the infrastructure and stability necessary to deal with an everchanging world and to maximize the people productivity and the use of technology to be competitive [1]. Hence, process can be identified as a series of arranged activities or steps that performed to accomplish particular function to achieve predetermined objective. The process steps must be defined in such a definite way as to be clear that is, readily understood and capable of being followed in a consistent manner by anyone using the process [2]. Over the time, the processes should be changed and enhanced in order to accomplish improvements, such as; simplifying the activities, eliminating duplication and errors, providing new tools, reducing costs and cycle time, and reduction waste. Specifically, a software process can be defined as the logical organization of people, materials, equipment, and procedures into work activities designed to produce a specified end result. The result expected involves satisfying cost estimates, schedules and required quality attributes with some consistency. People and technology are integral parts that perform a fundamental role in the resulting product quality. To be effective a process must be planned and executed with accordance to a managed policy, realizing a first level of achievable control. Processes and methods are viewed as control levers in product quality, to improve quality; the process must be constantly improved [3]. In general process improvement can be defined as a systematic approach in which series of actions are taken to identify, analyze, and enhance existing processes within an organization to meet new goals and objectives and achieve more efficient results. There are several kinds of process improvement approaches such as; Benchmarking, Reverse Engineering, Model-based process improvement, Business Process Reengineering (BPR), and Process Engineering/Workflow Management [2]. Consequently, over the last decade, software industry has been concerned about software process improvement (SPI) that can be defined as a systematic procedure to improve the performance of an existing process system by changing the current processes or updating new processes in order to correct or avoid problems identified in the old process system by means of a process assessment [4]. SPI efforts are systematically justified by the endless quest of achieving competitiveness advantage in customer satisfaction, business profitability, market share, product and service quality, cost reduction, cycle time reduction, etc. [3]. Implementing the improvement process depends on the results that come from the assessment process which provides the evaluation of the organization current state in order to determine strength, weakness, problems, and where the organization should start the improvement for their processes. Thus, Software Process Assessment (SPA) is a systematic procedure to investigate the existence, adequacy, and performance of an implemented process system against a model, standard, or benchmark [4]. SPI action plans are performed to change an organization’s software processes of so that they meet the organization’s business requirements and help it to achieve its business goals more effectively. SPI is the goal of SPA, acting on issues found in an assessment and enhancing the processes effectiveness in the process system. Key categories of SPI philosophy are; goal-oriented, benchmark-based, and continuous process improvement [5].

[7]

Chapter Two: Literature Background and Related Work There are two basic SPI methods; assessment-based and benchmark-based process improvement. The former improves a process system from a given level in a defined scale to a next higher level; the latter provides improvement strategies by identifying gaps between an organization’s process system and a set of established benchmarks. Additionally, a combined approach may be adopted [5]. Figure 2.2 below illustrates the steps of the SPI process in the organization representing the association between the SPA and SPI [6].

Process is examined by

identifies changes to

Process Assessment

leads to

leads to Process Improvement

identifies capability and risks of

motivates

Capability Determination

Figure 2.2: Software Process Improvement Framework [6]

2.2.2 The SPI Lifecycle The SPI lifecycle provides an overview on how SPI work can be conducted, on what kind of work that should be done. This is described in the following inputs on the SPI lifecycle as displayed in figure 2.3 [7]:      



First define the desired business objectives, evaluate the current processes, problems, and project outcomes through an assessment. After learning the assessment insights and knowledge of software industry best practices, set realistic improvement goals. Identify a project or two on which to pilot new processes and make adjustments before officially progressing them out. Plan how to implement new ways, methods, or techniques of working to increase success chance. Implementing an action plan. Give the new processes some time, then see whether they’re easing the problems those improvement actions targeted. Hard data about process benefits is more definite than subjective insights. Then continue the improvement cycle with the next most persistent requirement.

[8]


Figure 2.3: The SPI Life Cycle [7]

2.2.3 Software Process Improvement Approaches Over the years, numerous quality management standards, engineering standards, and maturity models have been developed. These refer collectively to these documents, which provide the structure for capturing concepts, practices, and relationships, as frameworks. Frameworks include both models and standards. Each framework typically includes training material, interpretation guidance, and audit or appraisal approaches. The frameworks often address similar topics, but present information in different ways, addressing different disciplines, and using different language. Even where frameworks are each primarily focused on different topics, there is often some degree of overlap [8]. Many different quality approaches are available in the software industry. Discovery of approximately 315 quality approaches of 46 different organizations. Some of the approaches, such as ISO 9001 are not software specific, that is they define general requirements for an organization, and they can be used at any company. Others, such as Automotive Software Process Improvement and Capability dEtermination (SPICE), have been derived from a software specific approach, and can be used for improving specific (in this case automotive) processes. Some are created to improve development processes, others focus on services, and again others are related to particular processes such as software testing or resource management [9]. A picture of interrelations among 39 different quality approaches was published by Sheard in 2001[10]. There are several international models, methodologies and techniques for SPI such as; Total Quality Management (TQM) approach, capability maturity model integration (CMMI), ISO/IEC 9001, and the SPICE, Six-Sigma approach, Bootstrap methodology, Trillium model …etc. Some of these models are explicitly required by customers; some are implicitly required by the market; some may be imposed by statute or regulation; some are simply recognized as being useful in building or maintaining competitive position. While the frameworks' authors certainly hope that potential users will perceive the value added, users struggling with implementing a variety of improvement requirements and priorities can find the situation frustrating. A need expressed by some in the multimodel environment is for the ability to compare and integrate the various different frameworks that may be imposed on an organization [11].

[9]

Chapter Two: Literature Background and Related Work A number of differences among SPI approaches exist, for example one difference between ISO 9001 and CMMI for Development is in focus. ISO 9001 has a general business process focus and can be used in any business domain; CMMI for Development has a process specific focus and is mainly applied by software and system companies. Differences in structure and granularity also exist between quality approaches, for example both CMMI for Services and Information Technology Infrastructure Library (ITIL) focuses on services. However, whereas CMMI defines process areas, goals, and practices, it does not define the concrete steps of the processes. ITIL contains very detailed descriptions and provides process flowcharts for guiding service implementations [9]. ITIL framework is designed to standardize the selection, planning, delivery and support of IT services to a business. García-Mireles et al. (2015) provided an overview regarding initiatives that focused on promoting product quality improvement by applying SPI approaches via conducting a systematic mapping study. They identified 74 primary papers including both theoretical (75.7%) and empirical (24.3%) papers. The empirical papers suggested that traditional process reference models, such as CMM, CMMI or ISO9001, moderately increase product quality characteristics (maintainability and reliability). But, there was a need for more empirical research to evaluate the impact of SPI initiatives on software product quality by considering contextual factors. SPI initiatives should be more driven by performance goals related to product quality characteristics [12]. Suganya and Alagarsamy (2016) presented a brief description about SPI and a review on the current SPI methodologies for small and medium enterprises (SMEs), as SMEs were unaware of the effective innovations and the factors that could influence their adoption of SPI. Most of SMEs were not adopting existing standards. The reason was that they perceived them as being oriented towards large organizations only. Their studies had shown that small firms’ negative perceptions of process model standards were mainly driven by negative views of cost, documentation and bureaucracy. Therefore, there is a critical request for an improvement framework that applicable for all size software organizations [13].

2.2.4 The Importance of SPI Standards SPI Standards play a vital role in raising the level of quality, safety, reliability, maintainability, efficiency and interchangeability while also providing such benefits in an economical manner. Standards, as developed by various consortiums of experts from the industry, government and academia, provide a good source of reference for process improvements. They specifically address the issues of various vertical industries and hence are very unique in nature. Software development organizations adopt the best-suited preference among the whole range of standards available [14]. The benefits of adopting and using SPI standards can be summarized in the following: [15]  The ability to apply structured methodologies and procedures of the highest professional level.  Better mutual understanding and coordination among development teams but especially between development and maintenance teams.

[10]

Chapter Two: Literature Background and Related Work  Greater cooperation and communication between the software developer and external participants in the project.  Better understanding and cooperation between suppliers and customers, based on the adoption of standards as part of the contract.

2.3 The Multi-Model Environments In the field of SPI, the multimodel environments mean the simultaneous usage of more than one quality or improvement approach (e.g. standards, methods, techniques to improve software processes) under one incorporated model, so that they complement each other's deficiencies and drawbacks.

2.3.1 Multimodel Environments Description There are two paradigms to process improvement, the benchmark and the analytical based process improvement approaches. Benchmark based approaches are prescriptive in nature, defining requirements or advising a set of practices originating from top performing organizations, that are adopted by organizations aiming to improve their software process. Analytical approaches are based on strategies that aim first, to define business, process and product objectives and then establish a clear understating of the impact of process performance in these objectives. A recent trend in SPI is the adoption of more than one improvement model into a single organizational environment, originating what are denominated multi-model environments. The goal is to achieve the cumulative added benefit of adopted models [16]. Numerous challenges arise in these multi-model environments that motivate the research work of this dissertation through proposing an improvement multimodel. Improvement technologies provide unique features to address specific problems these vary in scope and domain of applicability. A simple taxonomy classifies technologies in two groups, the ones that are oriented to answer 'what' needs to be done and the ones that show 'how' it could be done. When organizations adopt a multi-model approach they aim to leverage the best practices made available by different models to better address improvement challenges [3]. There can be different situations in which the usage of multiple approaches is needed, for example to strengthen a particular process with various aspects of multiple quality approaches, to reach certification of compliance to a number of standards [9] or to learn the software organization how to implement the quality model practices effectively. The value proposition of using multiple technologies is the incorporation of their best practices in a single solution, that otherwise would not be possible to obtain by a single technological approach. Two general approaches are being considered when combining different technologies, these fall in what/how and what/what combinations. Examples of technologies that show what needs to be done are CMMI and ISO 9001. Six Sigma, Team Software Process, Personal Software Process and Project Management Body of Knowledge provide answers on how it could be done [3].

[11]


2.3.2 Multi-model Environments Survey Siviy et al. 2008 surveyed problems organizations encounter when operating in multimodel environments and the current process improvement approaches such organizations need to consider. They examined the approaches needed in technology selection including a strategic taxonomy, the decision authorities associated with that selection at all levels in the organization, and considerations for thoughtful sequencing of implementation in alignment with the organizations’ mission, goals and objectives [17]. Paulk 2009 described taxonomy for improvement frameworks that would support an understanding and comparison of a diverse set of frameworks. Discussing taxonomy issues can drive a better understanding of the underlying concepts and architecture of improvement frameworks, while at the same time not adding to the quagmire. His taxonomy was expected to evolve over time as the community gains knowledge and insights into successful improvement factors [11]. Ferreira and Machado 2009 identified principles and process characteristics for designing a system of processes at the architectural level. An improved understanding of improvement models interoperability was predictable by identifying the technical and structural relationships between processes that facilitated architecting a system of processes [3]. Ferreira et al. 2010 [a] proposed an approach to measure size and complexity of best practice models in a context where selection of models can benefit from explicit insights in terms of size and complexity. They provided a base for quantitative analysis of best practice models at the light of proposed attributes of size and complexity. They proposed a characterization of size as a measure of scope coverage and detail of descriptions between models and complexity in terms of structural connectedness [18]. Kelemen et al. 2012 analyzed current initiatives in multimodel SPI and identified criteria for multimodel solutions. They discussed first the current problems regarding the use of multiple software quality approaches. Subsequently, multimodel initiatives were categorized into three different groups, respectively: quality approach harmonization, quality approach integration, and quality approach mapping. Based on an analysis of the strengths and weaknesses of current multimodel initiatives, they derived a set of criteria, which could provide a basis for multimodel SPI solutions [9]. Pardo et al. 2013 presented a framework that defined elements needed to support the harmonization of multiple reference models, a process, which was the backbone and way of integrating all the elements defined in the framework, and a set of methods, which allowed them to know "what to do", and "how to put" two or more models in consonance with each other. The application experience of their proposal was illustrated in two case studies. The findings obtained showed that the harmonization process has enabled them to harmonize and put the models involved in consonance with each other [19].

[12]


2.4 Capability Maturity Model® Integration (CMMI®) Currently, CMMI is considered one of the most important and efficient models of quality and improvement which available for global use by software companies.

2.4.1 A Brief History of CMMI The CMM, and its evolution into CMMI, began in the wake of the personal computer revolution in 1980s. It was developed by SEI (Software Engineering Institute) of Carnegie Mellon University to guide development and maintenance activities applied to both products and services in early 1990s. CMM began as a standard for process assessment and improvement in the field of technology engineering. It is used to identify the key elements of effective software processes and to evaluate the maturity and capability of software processes of an organization [20]. The CMM Integration® project was formed to redeployment the problem of using multiple CMMs. The combination of selected models into a single improvement framework was intended for use by organizations in their detection of enterprise-wide process improvement. Using processes that promote consensus, the CMMI Product Team built a framework that accommodates multiple constellations. The first model to be developed was the CMMI for Development model (then simply called “CMMI”) [1]. Figure 2.4 illustrates the previous models that led to the CMMI version 1.3.

Figure 2.4: The History of CMMI Evolution [1]

[13]


2.4.2 CMMI-DEV v1.3 Structure and Design CMMI-DEV v1.3 is a reference model that addresses development activities applied to products and services. It addresses practices that cover the product’s lifecycle from conception through delivery and maintenance. The emphasis is on the work necessary to build and maintain the total product. It contains practices that cover project management, process management, systems engineering, hardware engineering, software engineering, and other supporting processes used in development and maintenance. CMMI-DEV contains 22 Process Areas (PAs) [1].

2.4.3 CMMI-DEV 1.3 Implementation CMMI-Dev v1.3 supports two implementation approaches to process improvement called “representations”. One path "The Continuous Representation" enables organizations to incrementally improve processes corresponding to an individual process area (or group of PAs) selected by the organization to achieve specific capability level. The continuous representation deals with the process category. It is concerned with selecting both a particular process area to improve and accomplish its desired capability level [1]. CMMI-Dev classify four process categories; Support, Engineering, Process Management, and Project Management. The other path, "The Staged Representation" enables organizations to improve a set of related processes by incrementally addressing successive predetermined sets of process areas to achieve “maturity levels”. It is concerned with selecting multiple process areas to improve within a particular maturity level; whether individual processes are performed or incomplete is not the primary focus [1]. Figure 2.5 illustrates the structures of the continuous and staged representations of the CMMI-Dev v1.3 model. The differences between the structures are subtle but significant. The staged representation uses maturity levels to characterize the overall state of the organization’s processes relative to the model as a whole, whereas the continuous representation uses capability levels to characterize the state of the organization’s processes relative to an individual process area. Capability levels apply to an organization’s process improvement achievement in individual process areas. Four capability levels (numbered from 0 to 3) will be applied to an organization’s process improvement achievement across multiple process areas. These levels are a means of improving the processes corresponding to a given set of process areas (i.e., maturity level). The five maturity levels are numbered 1 through 5 [1]. Table 2.1 compares the four capability levels to the five maturity levels. Notice that the names of two of the levels are the same in both representations (i.e., Managed and Defined). The differences are that there is no maturity level 0; there are no capability levels 4 and 5; and at level 1, the names used for capability level 1 and maturity level 1 are different.

[14]

Chapter Two: Literature Background and Related Work The CMMI Continuous Representations Process Areas

Specific Goals

Capability Levels

Generic Goals

Specific Practices

Generic Practices

Maturity Levels

The CMMI Staged Representations Process Areas

Specific Goals

Generic Goals

Specific Practices

Generic Practices

Figure 2.5: Structure of the CMMI-Dev Representations [1] Both CMMI-Dev v1.3 representations provide specific ways to improve processes to achieve business objectives, and both provide the same essential content and use the same model components. Table 2.1: Comparison of Levels in CMMI-Dev v1.3 [1] Level Number Level 0 Level 1 Level 2 Level 3 Level 4 Level 5

Continuous Representation (Capability Levels) Incomplete Performed Managed Defined

[15]

Staged Representation (Maturity Levels) Initial Managed Defined Quantitatively Managed Optimizing


2.4.4 Motivations to Select the CMMI Model Since its introduction, CMM has quickly become a major player in the IT world of process improvement and quality management. Today, it runs second only to its more established relative, the ISO 9001 program, in acceptance and use around the world. In terms of force, CMM is probably leading. It is being adopted as the preferred IT quality standard by more businesses, organizations, and government agencies. With ISO and Six Sigma, it has taken its place as one of a trio of quality management options the executive world is looking to. Its rising popularity can be attributed to many factors. It is relatively compact, specifically shaped to the needs of technology development, a public-domain specification, and free to anyone who wants to use it for applying improvement [20]. CMMs, for many years, has shown positive results in terms of both tangible benefits such as; cost, schedule, product quality, productivity, customer satisfaction, and amount of rework and intangible benefits such as; improvements in the quality of work life, organization communications; organization learning and efficiencies; the ability to attract, retain, and develop software professionals; and the coherency of its organization culture. Similarly, SEI also reported the effectiveness of CMMI by comparing data from 35 organizations [21]. Therefore, this research selects the CMMI model; because of its wide international popularity in the software industry, as it is being adopted worldwide and proven effectiveness and several progressive effects. Also, the Egyptian software companies can register and get the CMMI certificate from the Software Engineering Competence Center (SECC)1 center. According to SECC, already there are many accredited Egyptian companies that have got the CMMI certificate.

2.4.5 CMMI Model Criticism Although CMMI model is one of the most common and accredited software development process descriptions for improving software project performance, it has some criticism can be presented as the subsequent portions: CMMI models provide guidance to use when developing processes. CMMI models are not processes or process descriptions. The actual processes used in an organization depend on many factors, including application domains and organization structure and size. In particular, the CMMI PAs typically do not map one to one with the processes used in software organization [1]. One major factor in the CMM’s success is the simplicity of the idea. However two of the problems in CMMI include interpretation and organizational decisions. The model itself was written to cover many different organizational and project situations. An ambiguous style was intentionally chosen by the authors of CMMI to fit these many situations. This ambiguity results in the necessity for a lot of interpretation and decision making by the model users [2]. 1

The Software Engineering Competence Center (SECC) is an Egyptian leading ICT organization aiming at bridging the gap between the technologies needed to overcome the economical-social-environmental challenges and the current existing technologies. [www.secc.org.eg.]

[16]

Chapter Two: Literature Background and Related Work CMMI is a model, representing an ideal state that is used as a benchmark; it is not a process. CMMI describes best practices but it doesn’t specify how to implement those practices. Organizations have to interpret the model to meet their own applications and develop processes that will be implemented to best satisfy their business objectives. It describes what is expected in processes, not how to implement processes; definition of the how is left to each organization to decide [8]. CMMI is an "ivory tower" of theoretical concepts born of decades of research and practical application. It is a collection of the activities to be expected of an organization as it sets out to improve its processes. CMMI is not and never was meant to be a replacement or a definition of anything in the real world. CMMI contains neither processes nor procedures. The practices are not steps in organizations' set of standard processes, and they are not activities that necessarily occur within a specific business process [22]. SPI research also founds that CMMI tends to match the requirements of large organizations and requires tailoring to suit Small and Medium Enterprises (SMEs) needs. Tailoring CMMI at organizational level is not easy for SMEs as it requires hiring of skilled professionals and increases the improvement cost. Currently, extensive research is being carried out on integrating CMMI with other analytical SPI models for simplifying and accelerating its adoption. One such methodology is of integrating CMMI with Six Sigma and researchers have not only found their joint deployment synergistic, but have also showed that it can improve return on investment (ROI) overtime [23]. Tully 2007 combined the information gathered from outside sources with his own experiences and observations collected in the software development industry. By determining the common roadblocks, he gained an insight into the full range of problems from which root causes could be determined. Identified root causes included; lack of guidance on where to start improvements, unique aspects of organization not accounted for, absence of practical methodology, shortage of analytical tools, inadequate metrics to determine if process improvements are effective, measures and metrics require definition, collection and analysis to establish a baseline prior to the improvement [24].

2.4.6 CMMI Literature Survey This section provides the various pervious research and related work of the multimodel environments that focus in the CMMI model. Common approaches combine CMMI and Six Sigma or CMMI and ISO with the purpose of developing a single integrated multimodel solution. Examples of these combinations of different improvement models are illustrated in the following portions. Huang and Han (2006) presented a decision support model that assists managers in determining the priorities of the CMMI process areas for only software organizations that adopt the continuous representation of CMMI. The proposed model was validated by using the ISBSG repository, and an example was presented to demonstrate the application of the model. This study was a starting point in considering how to select the CMMI process areas to initialize process improvement [25].

[17]

Chapter Two: Literature Background and Related Work Ferreira et al. (2010) [b] proposed an approach to help address the multimodel environments challenges by comparing models at a quantitative level. They proposed a characterization of model size as a measure of scope coverage and detail of descriptions when compared to a reference model and model complexity in terms of architectural structural connectedness. An example of applying the proposed approach was described in an industrial context where a multi-model process solution was evolved from CMMI-Dev level 3 to level 5 [26]. Iqbal et al. (2016) used a questionnaire-based technique to measure to what extent the SMEs were compatible with the CMMI-based SPI requirements. Their research was based only on the specific practices of process areas related to level 2 in CMMI-Dev v1.3. They categorized 3 levels of compatibility; Non-potential, Semi-potential, and Fully potential SMEs for CMMI-based SPI. Their ultimate goal was proposing a framework in order to facilitate economical, swift and effective CMMI-based SPI for SMEs [27].

2.4.6.1 CMMI and ISO Vasiljevic and Skoog (2003) proposed a framework for SPI for Small Organizations “SPISO”. The SPISO-Model based on CMMI v1.1 and incorporated additional practices from: ISO 9001:2000 - Customer Communication and Resource Management, and SWCMM - Software Project Tracking and Oversight. The SPISO-Model primarily designed for small software organizations to improve their software processes [7]. This is a limited model for small organizations only; in addition it doesn’t provide any tools, methods, or metrics for model implementation. Also, the model didn’t consider the CMMI capability levels (Generic Goals/Practices). Yoo et al. (2006) presented a unified model for the ISO-certified organization which wishes to improve its processes continuously using the CMMI model. Their model would be a particularly useful tool only for ISO-certified organizations that plan to implement CMMI [28]. But, they didn’t provide any tools, methods, or metrics about how the software organization can implement the proposed model. Also, they didn’t evaluate this model empirically to confirm its efficiency in the implementation process. Qyser and Rao, (2008), explored how ISO/IEC 14598-5 standard can be combined with CMMI in order to produce a methodology that can be tailored for process evaluation to improve software processes. They also described the resulting method and field trials [29]. Their evaluation methodology was suitable only for small organizations. Mutafelija, and Stromberg, (2009), provided a mapping between CMMI® v1.2 and ISO Standards. They developed the relationships between several ISO standards and CMMI and between two widely used ISO standards: ISO 9001 and ISO 20000 [8]. They provided in their book what requirements the software organization should have for improvement without determining any methodology for how to implement these requirements, such as; detailed activities, tools, methods, or metrics. Doyle (2009) described the interrelationships among CMMI, ITIL and ISO 20000. He provided a mutually supportive relationship among these three technologies [30]. However, he didn’t provide an integration methodology to be implemented in a software organization for SPI.

[18]

Chapter Two: Literature Background and Related Work Baldassarre et al. (2009) presented a comparison between the process areas of CMMIDEV and the processes described in the latest version of ISO/IEC 12207:2008. Based on these results they investigated the relationship between the CMMI-DEV and ISO/IEC 15504-7 models with the aim of identifying the degree of coverage of CMMI-DEV maturity levels in relation to ISO/IEC 15504-7 [31]. Baldassarre et al. (2010) presented a what/what combination of ISO9001 and CMMI-Dev v.1.2 models in the direction from ISO-CMMI; and detailed the what/how perspective by showing how GQM was used to define operational goals that address ISO9001 statements, reusable in CMMI appraisals. The harmonization process had been applied to a SME certified ISO9001:2000 [32]. Baldassarre et al. (2012) proposed a theoretical harmonization process that supports organizations interested in introducing quality management and software development practices or concerned about improving those they already have. This was done with specific reference to CMMI-Dev and ISO 9001 models in the direction ‘‘ISO to CMMIDEV’’, showing how GQM was used to define operational goals that address ISO 9001 statements, reusable in CMMI appraisals. Then they applied the theoretical comparison process to a real case, i.e., a small enterprise certified ISO 9001 [33].

2.4.6.2 CMMI and Agile An SEI report published in 2008 showing the assumptions that CMMI and Agile are at odds with one another. It suggested a hypothetical approach to using Agile ideas in CMMIbased process improvement [34]. Elshafey and Galal-Edeen, (2008) proposed an integration strategy that fitted the agile methods inside the CMMI framework in the process areas to overcome some of both approaches weakness, and combining their strong points in one framework [35]. However, this framework didn’t provide the software organization any tools, methods, or metrics to execute the CMMI maturity and capability levels. CMMI and Agile are now being used together successfully. Past concerns about combining CMMI and Agile were based on beliefs held in various user “camps” rather than technical compatibility. The fact is that CMMI and Agile can complement each other in ways that enhance the other. There are many papers and books explained how CMMI and Agile used together can result in fast and effective process improvement. Review some of these publications for more details found in CMMI Institute web site [36]. Therefore, to help those who use Agile methods to interpret CMMI practices in their environments, notes have been added to selected process areas in the last version. These notes are added, usually in introductory notes, to ten process areas in CMMI-Dev v1.3 [1].

[19]


2.5 Six Sigma Approach Six Sigma approach is one of the most sophisticated analytical process and product improvement strategy that is applicable in various application and several fields. The following sections describe briefly the Six Sigma approach.

2.5.1 Six Sigma History Six sigma business improvement strategy was introduced by Motorola in the mid-1980s. The Greek symbol σ represents the standard deviation to measure variability from the mean or the average. From organizations perspective, variation is often the cause of defects or out-of-control processes and translates into products or services that do not meet customer needs or expectations [37]. Six Sigma approach was adopted successfully by General Electric and other large corporations in the 1990s. The key focus of all six sigma programs is to optimize overall business results by balancing cost, quality, features, and availability considerations for products and their production into a best business strategy. Six sigma programs combine the application of statistical and nonstatistical methods with the appropriate toolkits to achieve overall business improvements. In that sense, it is a more strategic and more aggressive initiative than simple improvement projects [38].

2.5.2 Six Sigma Description Six Sigma approach has various perspectives, such as; a business improvement strategy, a philosophy, a performance measurement, an improvement framework, a set of improvement statistical toolkits, and a critical mass of highly trained individuals who serve as analysts, problem solvers, and change agents [39]. It is also an organized and systematic method for strategic process improvement and new product and service development that relies on statistical methods and the scientific methodology to make dramatic reductions in customer defined defect rates [40]. The Six Sigma focus is on process improvement to increase capability, reduce variation, improve performance, and enhance effectiveness [41]. Six Sigma methods contain several common principles, such as data-driven, decisionmaking and project management fundamentals. Tools and methods used in it are adaptive and iterative. Adaptive implies the fact that it can be tailored to a variety of situations and business contexts. Moreover, any given Six Sigma method can be integrated with another process or methodology to identify, gather, analyze, and report on critical parameters in a proactive or reactive manner. The adaptive nature of these methods also speaks to the wide array of industries and situations in which they can be applied. The iterative nature stems from the fact that more information on a variable or potential root cause gets revealed as the project progresses [42]. Six Sigma approach can be effectively implemented through two main methodologies; Design For Six Sigma (DFSS) methodology and The Define Measure Analyze Improve Control (DMAIC) methodology.

[20]

Chapter Two: Literature Background and Related Work DFSS methodology is a Sigma methodology that represents a collection of methods and toolsets that expands six sigma concepts to take a preventative approach by designing quality into a process/product. The DFSS methodology applies to technical design applications; it also features a unique subset of toolkits applicable to general business applications. It evolved to address the need for a redesign or new design—an innovation in response to a problem. If the process is incapable of meeting the desired customer specifications, it requires a redesign or an altogether new design in order to be consistent with the new desires and requests [42]; hence, DFSS can dramatically reduce the requirements failures.

2.5.3 DMAIC Methodology The Define Measure Analyze Improve Control (DMAIC) methodology is the classic six sigma problem solving process. Traditionally, the approach is to be applied to a problem with an existing, steady-state process offering. It is designed to allow for flexibility and iterative work, such that it uses a sequential process-step structure; however, some activities from various steps may occur concurrently or may be iterative. Deliverables for a given step must be completed prior to formal gate review approval. Step Reviews do occur sequentially [42]. The sequential five steps of DMAIC methodology are described below in figure 2.6. Step 1 DEFINE the problem and scope the work effort of the project team.

Step 5

Step 2

CONTROL the improved process to ensure the targets are met.

MEASURE the current process or performance.

Step 3

Step 4

ANALYZE the current performance to isolate the problem.

IMPROVE the problem by selecting a solution.

Figure 2.6: The DMAIC Process-step Structure The DMAIC methodology is mainly based on the application of statistical process control, quality tools, and process capability analysis. It can be used to help redesign a process, given that the redesign fixes the initial process problem, improves effectiveness, and increases productivity. To be successfully executed, it requires the next four main components [42]:

[21]

Chapter Two: Literature Background and Related Work    

A measurement system; measurement of the process in concern. Standard toolset that supports tasks to produce deliverables. A capability to define an adjustment factor(s) to correct the process offering back on improvement objective. A control scheme to maintain the improvement or correction over time by implementing a control plan with a monitoring system to audit the response performance against statistical control limits and defined action plans if required.

2.5.4 CMMI and Six Sigma An increasing number of papers have been published about organizations’ successful integration of CMMI and Six Sigma. These organizations have found ways to overcome the perception that the initiatives are competitors or mutually exclusive alternatives and are effectively blending them to achieve their organizational missions. Siviy and Forrester (2004) provided some findings about using Six Sigma to accelerate the adoption of CMMI for optimal results such as; Six Sigma helps integrate multiple improvement approaches to create a unified, single solution, Six Sigma adopters have a high comfort level with a variety of measurement and analysis methods, Six Sigma can accelerate the transition of CMMI, Six Sigma is effectively used at all maturity levels, participants assert that the frameworks and toolkits of Six Sigma exemplify what CMMI high maturity requires, and CMMI-based organizational assets enable Six Sigma projectbased learnings to be shared across the software and systems organizations, and thereby, enable a more effective institutionalization of Six Sigma [43]. Siviy et al. (2005) discussed the concept of integrating SPI models with each other and focused on the joint use of CMMI and Six-Sigma. While some models can be mapped where one model subsumes the other, CMMI and six-sigma cannot because they are different types of models. Their joint deployment is synergistic. The potential value that was added was the accelerated achievement of performance goals, accelerated achievement of CMMI adoption, stronger foundational measurement and analysis skills to enable better quantification of results, and all of the corresponding culture change that goes along with these improvements [44]. Wilson (2005) provided summary of CMMI® and Six Sigma Synergies, such as; sharing infrastructure between CMMI and Six Sigma benefits both initiatives, good measurements are essential to successful Six Sigma implementation and support CMMI goals, DMAIC and DFSS have strong ties to CMMI specific and generic practices, etc. [45]. However, he provided just possibilities, visions, and advantages about the possible synergy between Six Sigma and CMMI without providing the actual implementation strategy of the integration and how the organization can implement that integration to improve its software and processes. Albeanu et al. (2006) described the usage of the six-sigma methodology for software quality assurance and how a mixed six-sigma and CMMI could be applied to increase the capability and maturity level of the software department [46]. The experience was reported for some small and medium-sized software projects. Also, they didn’t provide a complete methodology for process improvement using the CMMI capability and maturity levels.

[22]

Chapter Two: Literature Background and Related Work Siakas et al. (2006) explored Six Sigma and CMMI in terms of their relationships similarities and differences and how a company can blend the two for added value and argues that the Six Sigma methodology when blended with CMMI is likely to enable businesses to effectively overcome the challenges of deployment and deliver optimal results. They concluded that the Six Sigma toolkit aligns positively with quantitative process management, product quality management, and process optimization practices associated with level 4 and 5, so they recommend blending the two approaches [47]. But it is possible to use the Six Sigma toolkits and methodology to blend them with the CMMI model in implementing all the CMMI maturity and capability levels in the software organizations not just level 4 and 5 only. Persse (2006) described how ISO 9001:2000, CMMI, and Six Sigma can help a software organization improve by weighing the advantages of each for specific issues. He delivered in his book a combined guide to all three programs, compared their applicability, and then set the foundation for further investigation [20]. I think that he just provided a comparison study between the three improvement programs and some considerations for adoption, but he didn’t provide any methodology about how they can be integrated with each other. Siviy et al. (2007) abstracted the following strategies for using these initiatives together: Implement CMMI process areas as Six Sigma projects, Use Six Sigma as the tactical engine for high capability and high maturity, Apply Six Sigma to improve or optimize an organization’s improvement strategy and processes, and integrate CMMI, Six Sigma, and all other improvement initiatives to provide a standard for the execution of every project throughout its life cycle [39]. Tully (2007) provided a guide to Six Sigma practitioners in using the Six Sigma to meet CMMI guidelines. He showed how to use Six Sigma and the CMMI together to incrementally improve the maturity of the software organization [24]. But the proposed guide didn’t validate within the software organizations or professionals to prove its effectiveness. Also, when selecting the area to improve, he didn’t prioritize the different requirements from multiple perspectives; he just depended on the process failure modes because these different requirements reveal the organization requests and problems. In addition, there are other important Six Sigma tools, methods, and metrics to be used in the improvement process, he didn’t refer to them. Habib et al. (2008) explained how SMEs can adopt CMMI by first tailoring it to suit their requirements and then blending the cut-down version with Six Sigma's DMAIC methodology to reduce the time required to attain CMMI Maturity Level 2 and 3. Moreover, they recommended standard templates and Six Sigma tools to maintain and control CMMI artifacts for different process areas [23]. However, they made a very specific study for small and medium organizations required to attain CMMI Maturity Level 2 and 3 only. They didn’t take into their consideration all the sizes of organizations and the aim to attain all the CMMI maturity and capability levels. Also, they didn’t implement their framework within SMEs to check its feasibility and effectiveness in real world. Safaie (2017) used a questionnaire-based technique to investigate the connection between variables of CMMI, Six Sigma, and AM (Agile Manufacturing); to prepare organizations for creation of AM using CMMI and Six Sigma; to priority quality factors in 3 models (CMMI, Six Sigma, and proposal model) and determine best model that cover quality factors [48].

[23]


2.6 Quality Function Deployment (QFD) The QFD technique is best viewed as a prioritization technique and planning tool that relates a list of consummations, requests, and requirements of different organization stakeholders to design technical functional requirements.

2.6.1 QFD Description With the application of QFD, possible relationships are explored between quality characteristics as expressed by customers and substitute quality requirements expressed in engineering terms. Since 1966, QFD has been used world-wide in nearly every industry and sector to prioritize spoken and unspoken customer needs; to translate these needs into actions and designs such as technical characteristics and specifications; and to build and deliver a quality product or service by focusing on achieving a common goal of customer satisfaction [21]. In other words, QFD technique can be considered as a procedure to assure that customer desires and requirements drive the product design and production process. Typically, a QFD system can be broken down into four inter-linked phases to fully deploy the customer needs phase by phase. In QFD, each phase’s important outputs (HOWs), generated from the phase’s inputs (WHATs), are converted into the next phase as its inputs (new WHATs). So each phase can be described by a matrix of “WHATs” and “HOWs”, which is easy and convenient to deal with in practice [49]. The four QFD sequential phases include: Phase 1 to translate customer needs into product design attributes which we will call technical measures; Phase 2 to translate important technical measures into parts characteristics; Phase 3 to translate important parts characteristics into process operations; and Phase 4 to translate key process operations into day to day production requirements [49]. Figure 2.7 below illustrates graphically the four phases in the QFD house schematic.

Figure 2.7: House Schematic of QFD [42]

[24]

Chapter Two: Literature Background and Related Work Using the QFD technique in the improvement process helps the enterprises to: translate customer requirements into specific offering specifications, prioritize possible offering specifications and make trade-off decisions based on weighted customer requirements and ranked competitive assessment. It is a powerful prioritization tool that combines several different types of matrices into one to form a house-like structure that referred to as a House of Quality (HOQ), this tool captures the voice of the customer to identify the required quality, features, and functions needed to be deployed in a single offering [42]. According to Achimug et al. the QFD technique is considered one of the most used, cited, and famous periodization techniques. It is classified under the ordinal scale in their prioritization taxonomies [50].

2.6.2 CMMI and QFD Sun and Liu (2010) proposed SPI frameworks based on CMM or CMMI using QFD aim to achieve three objectives: to map process requirements, including business requirements, to CMM or CMMI, with the help of QFD; to develop a method based on QFD for the integration and prioritization of requirements from multiple perspectives; and to be able to prioritize SPI actions based on process requirements [21]. However, his SPI framework didn’t provide the organization any tools, methods, or metrics to execute the CMMI specific goals/practices and the suggested actions. Also, he didn’t address how the organization can implement the capability levels (Generic Goals/Practices) for each CMMI process area.

2.7 The Ontology Technical Background The proposed multimodel environment for improvement in this research will be represented as a computerized version using the ontology engineering. The following sections provide the technical background of ontology and the literature survey related to the CMMI model and the ontology.

2.7.1 Ontology Definition The term ontology has its origin in philosophy, and has been applied in several different behaviors. The word "ontology" comes from the Greek Ον (on), which literally means entity. The core meaning within computer science is a model for describing the world that consists of a set of types, properties, and relationship types. Ontology in common in both computer science and in philosophy is the representation of entities, ideas, and events, along with their properties and relations, according to a system of categories [51]. Ontologies aim to capture consensual information and knowledge within their relationships in a generic and formal way, and that they may be reused and shared across other applications (or software programs) and by groups of people in different locations for various purposes [52].

[25]


2.7.2 Ontology Engineering Ontology engineering is the knowledge engineering branch that studies the methods and methodologies for constructing ontologies. It studies the ontology development process, the ontology life cycle, the methods and methodologies for building ontologies, and the tool suites and languages that support them. Ontology engineering aims to make explicit the knowledge contained within software applications, and within enterprises and business procedures for a particular domain. It offers a direction towards solving the interoperability problems brought about by semantic obstacles, such as the obstacles related to the definitions of business terms and software classes. Ontology engineering is a set of tasks related to the development of ontologies for a particular domain [51]. Ontology engineering describes the main concepts and their relationships that are significant in a specific field, providing a particular terminology for knowledge in that field as well as a computerized specification of the meaning of terms used in the vocabulary. Ontologies range from taxonomies and classifications, database schemas, to fully axiomatized theories. In latest years, ontologies have been adopted in numerous business and scientific societies as a way to represent, share, reuse, query, and process domain knowledge. Ontologies are now essential to several applications such as; scientific knowledge portals, information management and integration systems, electronic commerce, and semantic web services, etc. [53].

2.7.3 Ontology Components Contemporary ontologies share many structural similarities, regardless of the language in which they are expressed. Most Ontologies describe individuals (instances), classes (concepts), attributes, and relations. Common components of ontologies are illustrated briefly in the following [51]:  Individuals: instances, the basic or "ground level" objects of the domain knowledge base.  Classes: sets, collections, concepts, classes in programming, types of objects, or categories of things.  Attributes: aspects, properties, features, characteristics, or parameters that objects (and classes) can have  Relations: proprieties or ways in which classes and individuals can be related to one another.  Function Terms: complex structures formed from certain relations that can be used in place of an individual term in a statement  Restrictions: formally stated descriptions of what must be true in order for some assertion to be accepted as input  Rules: statements in the form of an If-Then sentence that describe the logical inferences that can be drawn from an assertion in a particular form  Axioms: assertions (including rules) in a logical form that together comprise the overall theory that the ontology describes in its domain of application.  Events: the changing of attributes or relations.

[26]


2.7.4 Ontology Languages In computer science and artificial intelligence, ontology languages are formal languages used to construct ontologies. They allow the encoding of knowledge about specific domains and often include reasoning rules that support the processing of that knowledge. Ontology languages are usually declarative languages, generalizations of frame languages, and based on either first-order logic or on description logic. There are a number of such languages for the ontologies' representation, both proprietary and standards-based as summarized in the following [51]:  Common Algebraic Specification Language is a general logic-based specification language developed within the IFIP working group 1.3 "Foundations of System Specifications" and functions as a de facto standard in the area of software specifications. It is now being applied to ontology specifications to provide modularity and structuring mechanisms.  Common logic is ISO standard 24707, a specification for a family of ontology languages that can be accurately translated into each other.  The Cyc project has its own ontology language called CycL, based on first-order predicate calculus with some higher-order extensions.  DOGMA (Developing Ontology-Grounded Methods and Applications) adopts the fact-oriented modeling approach to provide a higher level of semantic stability.  The Gellish language includes rules for its own extension and thus integrates ontology with an ontology language.  IDEF5 is a software engineering method to develop and maintain usable, accurate, domain ontologies.  KIF is syntax for first-order logic that is based on S-expressions.  Rule Interchange Format (RIF) and F-Logic combine ontologies and rules.  OWL is a language for making ontological statements, developed as follow-on from RDF and RDFS, as well as earlier ontology language projects including OIL, DAML and DAML+OIL. OWL is intended to be used over the World Wide Web, and all its elements (classes, properties and individuals) are defined as RDF resources, and identified by URIs.  SADL captures a subset of the expressiveness of OWL, using an English-like language entered via an Eclipse Plug-in.  OBO, a language used for biological and biomedical ontologies. In this research, the OWL ontology language with the OWL- Protégé editor is selected in order to construct the ontological representation of the proposed SPI-CMMI framework as it will be described in chapter four of this dissertation.

[27]


2.7.5 CMMI and Ontology Literature Survey There are only limited studies on CMMI ontology in the literature, illustrated in the succeeding pieces. Liao et al. 2005 produced an OWL-based ontology for generic Software Process (SPO) and attempted to ensure that it covered the requirements of both CMMI and ISO/IEC 15504. His study indicated that an organization’s process model could be represented by using SPO and that a web-based process assessment tool that used SPO has been under development [50]. He targeted general software process ontology whereas this study aims to develop an OWL-BASED ontology of a comprehensive SPI-CMMI framework through adopting CMMI-Dev v1.3 with the Six Sigma approach and QFD technique [54]. Soydan, and Kokar 2006 provided a short description of Ontology of the CMMI-SW model. The ontology was coded in a formal language, OWL. Some test cases were used to assess the ontology validity by means of an OWL reasoner to derive the results [55]. In this work, only staged representation was analyzed whereas in this research, it is designed to meet the requirements of both staged and continuous representations. Rungratri and Usanavasin 2008 proposed a framework called ''CMMI v1.2 based Gap Analysis Assistant Framework (CMMI-GAAF)'' to perform automatic gap analysis with respect to CMMI. Also, Project Assets Ontology (PAO) was created based on CMMI ontology developed by Soydan, and Kokar 2006 to merge CMMI process areas and project assets [56]. Ferchichi et al. 2008 applied ontology to the integration of two quality standards - ISO 9001:2000 and CMMI - to generate a multi-vues quality ontology allowing a double certification relative to these two standards. This work was especially carried out only within a software engineering company (Sylis) [57]. Lee et al. 2008 proposed an ontology-based intelligent estimation agent, including a CMMI-based project planning ontology and a fuzzy cost estimation mechanism, for the total project cost estimation. Based on the information stored in the CMMI-based project planning ontology predefined by domain experts, the fuzzy cost estimation mechanism inferred the total project cost and then stored the related results to the project estimation repository [58]. Sharifloo, et al. 2008 introduced an ontology system to represent the CMMI-ACQ v1.2 domain knowledge. This ontology has been developed based on Suggested Upper Merged Ontology (SUMO) using SOU-KIF languages [59].

[28]

Chapter Two: Literature Background and Related Work Lee et al. 2008 presented an ontology-based intelligent decision support agent (OIDSA) to apply to project monitoring and control of CMMI. The OIDSA was composed of a natural language processing agent, a fuzzy inference agent, and a performance decision support agent. The OIDSA could be work for only project monitoring and control of CMMI [60]. Lee and Wang 2009 presented fan ontology-based computational intelligent mutli-agent for CMMI assessment. The system comprised a natural language processing agent, an ontological reasoning agent, and a summary agent to summarize the evaluation reports. It was built based on process and product quality assurance process area of CMMI [61]. Pardo et al. 2012 presented ontology for the harmonization of multiple models. It was supported by a web tool and; had been applied for the harmonization of COBIT 4.1, Basel II, VAL IT, RISK IT, ISO 27002 and ITIL [62]. Soydan, and Kokar 2012 presented a formalization of CMMI-DEV model. The formalization was expressed in OWL. This formalization aimed to be consistent with the CMMI-Dev model and to be operational, i.e., to allow for an automatic determination of a development process maturity level based upon data about the practices within a given organization. For the formalization validity, a number of test cases for the scenario of automatic determination of the maturity level were developed [70]. Gazel et al. 2012 developed an ontology-based SPA tool to support data collection phase of process assessment and to track conformance of software processes to CMMI as the process reference model. Ontology-based CMMI Mapping and Querying Tool (OCMQT) was developed as a plug-in to an open-source process management tool, namely EPF Composer which, was a realization of the process engineering meta-model SPEM [63]. Mejia et al. (2016) presented an ontological framework based on a multi-model approach, which facilitates and supports the SPI for small and medium companies for a life cycle process improvement. Life cycle process improvement followed the essential activities in a thoughtful, structured and methodical manner, required in each stage of the life cycle of software development, capable for improving process to current organization needs. They presented a case study to show the performance of the framework [64].

2.8 Summary According to the detailed description and criticism of the CMMI model, it is important to find a general improvement guideline to lead the software organization in the adoption of CMMI model through the improvement journey. Also, based on the exhaustive study and detailed analysis of the previous literature survey presented in the previous sections, these concerns can be concluded:

[29]

Chapter Two: Literature Background and Related Work  

  



 

The organization processes require periodically effective change and enhancement through systematic efficient improvement methodology. Software development is a good example of a process that needs a renovation. Whether done internally or externally, software development is error-prone, expensive, and time-consuming. Recently, the effective trend in SPI is to adopt the multimodel approach. Six Sigma approach has numerous sophisticated toolkits and techniques that are effective in enhancing performance through improvement projects. Six Sigma approach can help simplify and accelerate CMMI implementation at all levels of maturity and capability, Six Sigma strengths complement CMMI weaknesses, and CMMI strengths complement Six Sigma weaknesses [45]. Mapping the process, management, and user requirements with CMMI; QFD displays the benefits of satisfying requirements through process improvement. SPI actions are linked to the prioritized process requirements using QFD. By fulfilling the activities with the highest priorities, the highest satisfaction level of process requirements can be achieved [21]. Most of these previous studies adopt a restricted point of view or particular reasons for integrating CMMI with other SPI models and approaches. There is no comprehensive process improvement strategy to be implemented in the software organizations using automated tool and appropriate analytical techniques in addition to the theoretical practices.

For these previous concerns, this research aims to apply the multimodel approach through proposing an improvement methodology that provides a comprehensive systematic procedure for process improvement strategy to be implemented in any size software development organization wishes to implement system and software process improvement methodology more effectively and successfully and get the CMMI accreditation. Multi-model approach facilitates the improvement task in order to achieve the organization’s business goals. In this context, effective integration of models and standards can play a crucial role in the implementation of multi-model environments as reference support tool. Therefore, this research proposes an improvement framework based on integrating the Six Sigma approach, the QFD technique and the CMMI model as an overall theoretical/practical procedure in order to guide the software organization in the adoption of CMMI model through the improvement project.

[30]

Chapter Three The Proposed Framework based on Six Sigma, QFD and CMMI

Chapter Three: The Proposed Framework

Chapter Three The Proposed Framework based on Six Sigma, QFD and CMMI 3.1 Introduction Applying the SPI methodology becomes a critical necessity in the sophisticated companies, whereas enterprises that survive, succeed, and grow are constantly and rapidly improving. Effective change is frequently easiest to implement when improvements are guided by existing roadmaps, approaches or standards. Hence, this research proposes a comprehensive improvement methodology to enhance and improve the performance level in software companies which interested in adopting the CMMI-Dev model. This chapter presents a detailed description of the stages, their corresponding steps and activities with the suggested toolkits and techniques of the proposed improvement methodology in this research.

3.2 The Proposed SPI-CMMI Framework The proposed improvement methodology bases on integrating Six Sigma approach with its methodology, statistical toolkits, metrics, and techniques, besides the QFD technique within the CMMI-Dev v1.3 guidelines for increasing the likelihood and accelerating of its adoption and enhancing its capabilities and efficiency. This proposed improvement methodology is called the SPI-CMMI framework; as it aims to improve the organization performance and processes, in addition to facilitate the CMMI adoption process. The CMMI-Dev v1.3 model is selected in the SPI-CMMI framework proposed in this research as the reference model because of its wide popularity in the software industry as illustrated in chapter two. Therefore, the proposed SPI-CMMI framework satisfies the requirements of the CMMI-Dev v1.3 model adoption [1] in the software development enterprises. Some parts of the proposed SPI-CMMI framework are designed based on the work performed by Tully [24] which provided a guide for using the Six Sigma to meet CMMI guidelines. Plus the SPI framework suggested by sun [21] that depended on the QFD technique in addition to the CMMI-Six Sigma Excel document from the Carnegie Mellon University and a collection of Six Sigma toolkits and techniques from [42]. The proposed SPI-CMMI framework will demonstrate how to use Six Sigma methodology, toolkits, metrics and QFD technique to execute the improvement project in addition to meet CMMI-Dev v1.3 guidelines, to incrementally improve the maturity of the software development organization. It targets all companies that develop software and seeking to make improvements within their current software development processes through adopting the CMMI-Dev v1.3 model. The proposed SPI-CMMI framework contains ten consecutive phases.

[31]

Chapter Three: The Proposed Framework Figure 3.1 summarizes the successive recommended steps and sequential activities within the proposed SPI-CMMI framework.

Improvement Project Initiation Process Capability

Six sigma Tools Success Metrics Derivation

Improvement Measures QFD Technique

Requirements Collection and Prioritization Requirement Priorities

CMMI Maturity Levels

(Staged Representation)

Process Areas (PAs) Prioritization

CMMI Process Category (Continuous Representation)

Required Capability Level

CMMI-PAs Priorities Specific Goals Prioritization

CMMI Capability Levels Goals Priorities

Specific Practices Prioritization

Practices Priorities

Generic Goals/ Practices Implementing Six Sigma Methodology (DMAIC) Suggested activities

Action Plans Prioritization

Implementing suggested Six Sigma Tools and Metrics

Actions Priorities

Implementing suggested Six Sigma Tools

Figure 3.1: The successive steps of SPI-CMMI framework

[32]


3.3 The Detailed Explanation of SPI-CMMI Framework The following sections provide the detailed explanation of the ten phases related to the proposed SPI-CMMI framework with the corresponding steps and activities, besides the appropriate toolkits and techniques. Each recommended phase consists of a sequential series of the related steps and actions, besides the suggested tools and techniques required for the effective and accurate implementation. Figure 3.2 describes the detailed illustration of the proposed SPI-CMMI framework supported by the phase sequence, inputs and outputs. A variety of alternative toolkits and analytical methods are offered to implement the phase or step according to the available resources in the organization; in order to achieve flexibility and simplicity in the employment and adoption of the proposed SPI-CMMI framework by the software organizations. Here is the final version of the proposed SPICMMI framework after modifying and updating according to the revision process of the CMMI experts and parasailers.

3.3.1 Phase 1: Improvement Project Initiation The first phase of the proposed SPI-CMMI framework starts with the formation of the improvement teamwork that will execute the suggested activities and participate in the improvement project. Then, the recommended six sigma toolkits, templates and metrics are implemented -as possible as- to assess the organization current state, through determining the capabilities, strengths, and the weaknesses to specify where the organization should start the improvement process. The capability of a particular process will direct the process improvement work. This phase can be performed using the following successive steps: Step1: Assign the improvement teamwork. Step2: Develop a planning methodology for the improvement project. Step3: Generate a SIPOC of the entire organization processes. Step4: Construct the process map. Step5: Create the process inventory. Step6: Allocate capability levels for each process. Step7: Formulating strategic direction and management goals/objectives. Otherwise, the CMMI experts suggest that according to the organization experience and conditions, the Gap Analysis or SCAMPI C techniques can be used in performing this phase. The following paragraphs illustrate the details of the improvement project initiation steps, describing the complete activities and action plans with the suggested and appropriate Six Sigma tools and techniques.

[33]


Six Sigma tools and techniques

Six Sigma tools and techniques Need to improvement

Phase1

Process Capability

Improvement

Project Initiation

Improvement Measures

Requirements Priorities

Phase3: Requirements Collection and Prioritization

Phase4: CMMI-DEV Process Areas Prioritization

0 Process Areas Priorities

Phase2: Success Metrics Derivation


Six Sigma tools and techniques QFD Technique

QFD Technique CMMI-DEV Process Areas


Phase5:

QFD Technique

CMMI-DEV Specific Goals Prioritization

CMMI Maturity Levels (Staged Representation)

Requirements from various perspectives

Specific Goals Priorities


CMMI-DEV Specific Goals

QFD Technique

Phase6: CMMI-DEV Specific Practices Prioritization

CMMI-DEV Specific Practices

Phase8: Action Plans/ Specific Practices Implementation

Specific Practices Priorities


Phase7: Action Plans Derivation/ Prioritization

Action Plans Priorities

CMMI Capability Levels (Continuous Representation)

Six Sigma

Suggested Activities

QFD Technique Suggested Activities

Generic goals and practices

Methodology (DMAIC)


Suggested Actions/plans

Phase9: CMMI-DEV Capability Levels Interpretation


Figure 3.2: Illustration of SPI-CMMI Phases

[34]

Phase10: Capability Levels Activities and Generic Practices

Chapter Three: The Proposed Framework Step1: Assign the improvement teamwork. Who will participate in the improvement project? In view of the fact that most improvement professionals are not specialists in a particular business process they are improving, it is important to recognize persons who are experienced in that process. Within the effort of assessing the current state of the software development organization, the subject matter experts (SMEs) provide critical information about what the process accurately is and can provide essential input on identifying potential alternatives for the improvement projects. The Stakeholder Analysis tool may help performing this step. Moreover, the improvement team consultants work with the subject matter experts so as to identify the inventory of plans, phases, elements, activities, various resources and tools needed to implement and complete the improvement project.

Step2: Develop a planning methodology for the improvement project. How do the activities of an improvement project adjust to the overall organizational strategy and objectives? GOSPA (Goals, Objectives, Strategies, Plan [What], and Actions [Who-When-WhyHow much]) is a top-down planning technique that starts with the highest level organizational goals and defines how individual groups support specific objectives. This planning methodology summarizes an organization’s direction and defines how supporting programs and/or projects relate to it. The GOSPA technique should be implemented at the beginning of the planning phase of an improvement project in order to monitor its progress against the document throughout execution of a prearranged plan. The GOSPA document can be developed using either a matrix or Tree diagram. GOSPA technique provides the ability to:  Communicate direction and collaboration with organizational objectives.  Review particular actions to guarantee association with strategic direction.  Develop a planning methodology used to align activities with organizational direction and goals. Furthermore, at the beginning of the improvement project, the organization should answer that question; what is the most concise description of the improvement project’s goal and problem statements? The answer can be provided using the SMART technique [Specific-Measurable-Achievable (but Aggressive)-Realistic-Time-bounded]. This technique makes it straightforward to; communicate a clear, concise, complete description of a project’s goal and identify the problem it addresses.

Step3: Create a SIPOC of the entire organization processes. What is the scope of the business process? The SIPOC (Supplier-Inputs-Process-Outputs-Customer) technique serves as a high-level snapshot at the beginning of an improvement project to provide a big picture perspective of a process. SIPOC serves as an effective communication tool to describe what could be a multifaceted process in simple terms. The SIPOC technique helps the software company to; communicate a high-level view of the project scope or process, and prevent scope creep in a project.

[35]

Chapter Three: The Proposed Framework Step4: Construct the process map. What are the components (activities) of the process; what is involved? A standard tool within Six Sigma is a Process Map (Activity flowchart or Workflow diagram). Using this tool, the improvement team gains a greater depth of understanding of the process details. Using the high-level process steps defined in the SIPOC as starting point, the improvement team can further expand on each of the steps. In other words, list the sub-processes (Detailed Process Map) that make up the process step. Then, each of the steps listed in the SIPOC should be divided into a total of 5 to 7 sub-steps. Process maps tool enables the organization to:  Understand the process and where the opportunities for improvement exist.  Gain a common understanding of a process and identify waste and areas where the process is poorly defined.  Display and examine the current process and compare it with what could be.  Communicate what is involved in the process—its sequence of activities, inputs, outputs, and who is involved. Graphically outline a procedure.  Plan the future or improved process.  Categorize current process into its key components: activities, inputs, tools, resources and outputs. The SIPOC diagrams these five key elements in a column-structured chart to provide information as follows:  Suppliers: The key functions (roles or people) that produce the inputs.  Inputs: The key process information, parts, components, decisions contributions required prior to beginning or completing an activity or task.  Process: The high-level process activities (typically three to eight steps) that transform the inputs to produce the outputs.  Outputs: The key process deliverables or tangible outcomes.  Customers: The key customers (both external and internal) requesting the outputs (or deliverables).

Step5: Create the process inventory. The processes documentation is an essential part of process management/improvement. Process documentation is about keeping track of a process during the execution of an improvement project. The process improvement team creates a comprehensive document called a process inventory using the detailed process steps defined in the generated process map. A process inventory document collects information related to the various process steps. The process steps along with an assigned ID for reference purpose are the first pieces of information captured. Examples of relevant data included in the process inventory are process inputs, outputs, appropriate tools, assigned resources, capability levels, compliance rating and effectiveness metrics. Common office productivity tools can capture this information, such as; Microsoft Word or Excel. Later documented processes facilitate education and formal training that allows for smooth onboarding.

[36]

Chapter Three: The Proposed Framework Step6: Allocate capability levels for each process. How the process is executed, defined, managed and able to meet customer requirements? In addition to the process inventory created in the previous step, the capability level of each of the process activities is allocated in this step. This initial rating will allow the practitioner to identify the process activities that are more effective against the high-risk areas. It will also help the improvement professionals to understand which critical process areas need advance exploration. This step can be implemented efficiently using a Six Sigma tool called Process Capability Analysis that can be performed only on processes known to be in statistical control, meaning that the presented process variation is random and steady over time. Using this tool the improvement teamwork can:  Recognize if an existing, steady state, normal process, is capable of producing output within quantified specification limits.  Understand whether the actual process results are acceptable with respect to the predetermined specifications.  Evaluate the process performance.  Compare the performance level of two different processes; to select one. Moreover, the improvement team can use the CMMI concept of capability levels as defined in the CMMI-Dev model documentation to assign a capability level for each process or activity. At this point, the team should identify where the improvement project will start upgrading the processes with the lowest capability level.

Step7: Formulating strategic direction and management goals/objectives. How does the organization’s strengths and weaknesses compare with the competitive opportunities and threats? The SWOT (Strengths-Weaknesses-Opportunities-Threats) analysis focuses management on the competitive landscape and how well its organization competes. It embodies two challenges. First, the organization must objectively evaluate its internal strengths and weaknesses and relative position to competition. Management tends to amplify strengths and underplay weaknesses, thereby negating the SWOT process. Collecting the perspective of objective observers may serve the organization well. Second, the analysis represents only the initial phase in a strategic plan; the next phase requires the execution and delivery of an action plan. Using the SWOT analysis helps the improvement team to perform the following precise activities:  Identify the critical marketplace characteristics and organize them as a balanced scorecard to make strategic decisions.  Evaluate the balance between internal and external factors for a particular organization.  Classify and prioritize which market sectors fit the organization products or services. At the end of this phase, the process improvement professionals have gathered enough information to make an overall assessment and complete evaluation of the capabilities of the software development organization. The planning methodology GOSPA summarizes an organization’s direction and objectives to define how supporting improvement project

[37]

Chapter Three: The Proposed Framework relate to them. The SIPOC technique captures the overall scope of the organization and the high-level process. A process map tool captures more detailed process information and the organization can define a relative level of each of these process activities. In addition, the improvement professionals now have the process inventory document; with which to capture and trace further data on the process steps as the project processes. Also, the organization evaluates its external strengths and weaknesses and relative position to competition.

3.3.2 Phase 2: Performance Management and Success Metrics Derivation For CMMI based improvements, many organizations sightlessly choice a specific maturity level they would like to accomplish, but fail to display any success from their improvement efforts. What usually results is that the rejection of CMMI based maturity goals when the senior management decides to cut costs. Thus, for any process improvement project, one of the most essential facets is the measures and metrics taken to show enhancement, observe improvement activities and control project progress. Consequently, a methodology, like Six Sigma’s DMAIC, which requires the use of data to show objective indication of improvements, protects the adoption of CMMI. Thus, the DMAIC methodology can be used in performing this phase of the proposed SPI-CMMI framework. It ensures that the focus of all improvements is on providing obvious and measureable outcomes that translate into an economic value, justifying the improvement efforts. DMAIC defines the aim of the process improvement effort in the early stage called the Define phase. The aim includes a response variable or that measure which the project improvement team is trying to affect. In the Analysis phase, baseline data is captured to determine the current process performance. Finally, in the Improve phase, the improvement team pilots the contestant solution and the response variable is then measured to determine to what extent, if any, improvement has achieved. The Critical-to-Quality (CTQ) technique is a simple, yet powerful Six Sigma tool that understands and translates improvement project needs into a meaningful, measurable, and actionable metric for the improvement team needed to deliver these requirements. Also, an important methodology for deriving success metrics is the Goal-Question-Metric (GQM) approach. With metrics, there are often many good measures available for collection, but an organization should identify the vital few metrics needed to manage and control the organization performance. Using the GQM approach, first; the organization needs to define its business goals and improvement objectives. Once it has documented its goals, then at least on question should developed that when answered would provide information on whether the goal had been met or not. More than one question may be required to supply the essential information depending on the goal complexity. Using the definite question, the organization can then develop the corresponding metric to provide the answer to it. It is important to note that a single metric can answer multiple questions, but there is only one metric allowed per question. This then limits the collection, analysis and reporting to those vital few that associated with the overall goals.

[38]

Chapter Three: The Proposed Framework Moreover, in this phase the organization can use the ScoreCard tool. It is the main predictive tool for both in-process measures and performance results. Improvement team should measure progress in contrast to their goals. ScoreCard tool helps to:  Monitor the fitness of a task, project, process, or entire business.  Plan and guide the improvement team’s work.  Understand if the improvement team members, or process players, are using the right resources at the right time. Furthermore, an organization may use a document called a Dashboard to track and record the metrics. A Dashboard allows the display and review of multiple measures in a single view. This tool allows a senior manager to assess the performance of the organization including identifying the interaction between measures and the ability to ensure that all areas are performing sufficiently. Additionally, it provides the most critical information without devastating the individual responsible for managing the organization. Besides, Six Sigma provides the Data Collection Matrix that possibly will be used to plan and organize the data collection process for the improvement project. This tool provides a roadmap as to what data is required and organizes that which is collected to ensure nothing is missing or there’s no duplicity. It helps to plan and organize current data sources and collection plan, also identify what data is needed, what is available, where to get it, and who is responsible to get it.

3.3.3 Phase 3: Requirements Collection and Prioritization The concept of QFD technique is to cross-reference the high-level qualitative requests to measureable quantitative engineering specification that will implement the given requirement via the traceability matrices. Hence, the QFD technique will be used in the improvement project for the requirements aggregation, integration and prioritization. Software system’s acceptability level is frequently determined by how well the developed system has met or satisfied the definite stakeholder’s requirements. Hence, gathering and prioritizing the appropriate requirements and scheduling right releases with the correct functionalities are a critical success factor for building exciting software systems. Thus, this phase prefers a method based on the QFD technique and the priority assessment technique for the elicitation, integration and prioritization of requirements from multiple perspectives of the organization's stakeholders as suggested in through the next sequential steps: Step1: Define the various perspectives related to the different stakeholders of the organization, such as; government, customer, business, management, quality …etc. Step2: Collect and arrange the requirements from the various groups of organization stakeholders. Step3: The requirements from multiple perspectives are correlated with each other using the priority assessment technique into one single set. Step4: As a result, the priority value of each requirement is adjusted after the impacts from the other requirements are assessed.

[39]

Chapter Three: The Proposed Framework To make certain that the improved software process reflects the most significant requests from various perspectives, Correlation-Based Priority Assessment (CBPA) was developed in [19] to prioritize and integrate these requirements so that the best available resources can be allocated to the most critical requirements and related processes. Actually this phase aims to achieve the subsequent objectives:  Develop a method based on QFD technique for the collection, integration and prioritization of stakeholders' requirements from various perspectives.  Determine which critical process area to target first for process improvement according to the stakeholders' requirements prioritization. Often; there are more improvement requests then there are too numerous resources to make these improvements.  Map various process requirements to the corresponding process area in the CMMIDev model with the help of QFD technique. Besides the QFD technique, Six Sigma approach has additional alternative techniques that can support the improvement teamwork in completing the third, forth, sixth and seventh phases of the proposed SPI-CMMI framework -as possible as- according to the available experience and resources in the organization, such as;  Brainstorming is a technique that aids to generate and document a large volume of stakeholders' requirements, ideas or quality concepts in one managed meeting, and creates out-of-the-box thinking to develop new improvement ideas.  Voice of customer gathering is a technique that represents a collection of various approaches to capture stakeholders' requirements.  The Market Perceived Quality Profile (MPQP) is a technique that identifies and measures market perceived quality of an offering, relative to meeting customers’ requirements and expectations.  Prioritization Matrices tool is a six sigma tool that helps to focus options for a weighty decision to select the best one using several subjective criteria. It is a full analytical criteria method prioritizes the decision criteria, weights them, and applies numerical values to the options to indicate the best alternative.  Priority Assessment Technique and Stakeholder analysis tool.

3.3.4 Phase 4: CMMI-DEV Process Areas Prioritization For each of the process categories in the CMMI-Dev continuous representation (or for each maturity level in the CMMI-DEV staged representation), the set of requirements with adjusted priorities resulted from applying the QFD technique are related to the CMMI-Dev PAs. In this phase, the CMMI-Dev PAs are prioritized and selected for improvement first based on those prioritized stakeholders' requirements resulted from the previous phase. Thus, the critical PAs that achieve higher overall satisfaction of process requirements get higher importance and faster implementation and enhancement. This prioritization method within the QFD technique takes into account the unique aspects of the software engineering organization and its associated processes. The proposed tools and techniques used in the third phase implementation are continuing to implement this phase too.

[40]

Chapter Three: The Proposed Framework The organizations should adopt various methods or apply several techniques, as possible as, to accomplish advanced levels of quality and enhancement. Other techniques can be used to decide which process area to focus first; thus, in this phase the organization may use the failure modes and effects analysis (FMEA) tool. FMEA is designed to identify potential failure modes early to reduce their impact if they occur. It helps in creating a robust design and relevant control plans. FMEA detects prospective critical and significant characteristics in a project/process design. This tool generates a priority for processes or action plans and documents the justification used. The approach used to develop an FMEA is frequently referred to as a bottoms-up systems analysis approach, trying to identify possible failure modes before they occur. To utilize FMEA, the improvement team inputs all of the process steps into a FMEA worksheet. Then for each step; the team brainstorms possible ways in which there could be a failure during the process. The team can infer potential failures from experience, obvious threats or perceived weaknesses within the process. Through prioritizing the CMMI process areas in this phase, requirements from the organization stakeholders can be transformed to the specific goals in the next phase. Otherwise, according to the organization nature and circumstances, the CMMI could be divided into areas (not process areas) then assign priorities to these areas according to the various stakeholders' requirements. For example, these areas could be project management, software design and development, testing, configuration management, quality assurance, process management and training. Each area includes some practices from the CMMI model.

3.3.5 Phase 5: CMMI Specific Goal Prioritization In the fifth phase of the proposed SPI-CMMI framework, all the specific goals (SGs) related to the prioritized PAs in a particular maturity level (CMMI staged representation) or a particular process category (CMMI continuous representation) are selected and prioritized based on the prioritized PAs from the prior phase. These prioritized specific goals assist as the link between stakeholders' requirements and the associated action plans. The relationship matrix in QFD is used in this phase to generate robust connections between the prioritized requirements from the organization stakeholders and the specific goals in CMMI PAs. This matrix proves that fulfilling with the CMMI-Dev standard also supports satisfying the stakeholders' requirements in the organization. This phase is performed with the same tools, techniques and methods used in implementing the pervious phase. Through prioritizing the specific goals, requirements from the organization stakeholders can be transformed to the specific practices in the sixth phase, and finally to the action plans in the seventh phase. Thus, a set of action plans can be performed not only to attain a specific maturity level in CMMI-Dev, but also to satisfy various organizational process requirements in the improvement project.

3.3.6 Phase 6: Specific Practices Prioritization The sixth phase includes the prioritization of specific practices (SPs) within all the prioritized CMMI PAs of a specific maturity level (for CMMI continuous representation, the specific practices in each level of individual PAs are prioritized separately). The

[41]

Chapter Three: The Proposed Framework specific practices prioritization is carried out on the basis of the prioritized specific goals those outcomes from Phase five. Therefore, this phase is performed with the identical tools, techniques and methods used in implementing the pervious phase. The CMMI-Dev documentation obviously presents the relevance and mapping between the specific goals in CMMI process area and their associated practices. According to CMMI-Dev specifications, all these specific practices have to be performed to reach that particular maturity level. These specific practices serve as an association between the stakeholders' requirements and the final action plans, and it is necessary to know how these practices reflect the software process requirements. To display the relations between the requirements and the final action plans, these specific practices have to be prioritized based on the prioritized specific goals, which are now reflecting stakeholders' requirements priorities resulted from the previous phases. For criticism and modification from the proposed framework in [19], the specific goals prioritization and specific practices prioritization can be considered as optional phases in the proposed SPI-CMMI framework. As in the CMMI-Dev model documentation, each process area has a particular set of specific goals followed by a set of successive specific practices in a sequential logical order that can be executed in this order without having to give them special priorities. This case may be decided according to the stakeholders' requirements and the organization circumstances and resources when developing the improvement plan to adopt the CMMI-Dev model.

3.3.7 Phase 7: Action Plans Derivation and Prioritization As CMMI model contains neither processes nor procedures to guide the organization; a set of suitable action plans and detailed activities is derived from the prioritized specific practices for each prioritized specific goal in the CMMI-Dev process areas according to the indicated details and nature of the organization processes through the seventh phase of the proposed SPI-CMMI framework. These action plans should reflect the various stakeholders' requirements collected, integrated and prioritized in the third phase. These derived action plans guide the improvement project. Also, they determine what critical requests to be executed actually in the organization in order to reach a particular CMMI-Dev maturity level. Optionally, the derived action plans can be too prioritized with the same methodology for the specific practices prioritization in the prior phase. After that, according to the results from the process of the action plans prioritization, more resources should be assigned to those action plans with high priorities. As proposed in the SPI-CMMI framework, by combining requirements from the organization stakeholders and converting them into the corresponding action plans through the CMMI specific goals and practices, the association between the objectives of the organization and CMMI-Dev maturity levels becomes more strong and clear.

3.3.8

Phase 8: Action Implementation

Plans

and

Specific

Practices

The convenient Six Sigma statistical toolkits, templates, techniques and indicated metrics are executed in applying the required specific practices and the corresponding

[42]

Chapter Three: The Proposed Framework action plans for each process area, to ensure much more successful implementation of the CMMI-Dev specific goals and their practices in accurate and fast manner in addition to the presence of the corresponding documents and templates for the documentation purpose that required in the various types of the CMMI appraisal. Thus, through the eighth phase, the proposed SPI-CMMI framework suggests a set of appropriate Six Sigma statistical toolkits, analytical techniques and indicated metrics for each process area in the CMMI-Dev model to be used in the efficient and precise implementation of that process area. Here is an example of the suggested Six Sigma tools related to the Organizational Process Definition (OPD) process area. Organizational Process Definition (OPD) - [ML3-Process Management Category] The purpose of OPD is to establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams. Organizational process assets enable consistent process execution across organization and provide a basis for cumulative, long-term benefits to the organization. Its specific goals and practices are: SG 1 Establish Organizational Process Assets SP 1.1 Establish Standard Processes SP 1.2 Establish Lifecycle Model Descriptions SP 1.3 Establish Tailoring Criteria and Guidelines SP 1.4 Establish the Organization’s Measurement Repository SP 1.5 Establish the Organization’s Process Asset Library SP 1.6 Establish Work Environment Standards SP 1.7 Establish Rules and Guidelines for Teams The following recommended Six Sigma tools as shown in table 3.1 can be used in achieving the specific goals of OPD process area by implementing their specific practices. Table 3.1: The Six Sigma toolkits of the OPD process area Six Sigma Tools  Process Maps  Process Flow Charts  Activity Network Diagram (AND)  Work Breakdown Structure (WBS)  Develop Standards and Procedures  Statistical process control (SPC) charts Appendix (A) contains the suggested Six Sigma statistical toolkits, techniques and indicated metrics related to the reminder process areas of CMMI-Dev model.

3.3.9 Phase 9: CMMI Capability Levels Interpretation According to [1] Process capability deals with the how well defined and managed the organization process is. CMMI Generic goals and practices are those activities which ensure that the identified improvement processes and the organization related activities will be effective over the long term. They should be implemented to all of the process areas within the CMMI-Dev model.

[43]

Chapter Three: The Proposed Framework This phase includes interpreting the CMMI-Dev capability levels into a set of related organization tasks. The Interpretation process suggests sufficient activities and steps within the six sigma methodology (DMAIC) for each CMMI-Dev capability level through converting its related generic practices into the detailed organization activities besides providing the appropriate documents and templates for the documentation purpose that required in the various types of the CMMI appraisal.

CMMI-Dev Capability Levels CMMI-Dev v1.3 model reflects capability levels in its design and content. It has four capability levels, each a layer in the foundation for ongoing process improvement, are designated by the numbers 0 through 3; Incomplete, Performed, Managed, and Defined respectively. Each capability level has its related generic goals and generic practices. A capability level for a process area is achieved when all of the generic goals are satisfied up to that level.

Capability Level 0: Incomplete "An incomplete process is a process that either is not performed or is partially performed. One or more of the specific goals of the process area are not satisfied and no generic goals exist for this level since there is no reason to institutionalize a partially performed process".

Capability Level 1: Performed A performed process is a process that accomplishes the needed work to produce work products; the specific goals of process area are satisfied. The Generic goal and Generic practice of Capability Level 1are: GG 1 Achieve Specific Goals GP 1.1 Perform Specific Practices

Capability Level 2: Managed "A managed process is a performed process that is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description". Its Generic goal and related Generic practices of Capability Level 2 are represented as the following: GG 2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherence GP 2.10 Review Status with Higher Level Management

[44]

Chapter Three: The Proposed Framework Level 2: Managed DMAIC Suggested Activities Through utilizing the Six Sigma's DMAIC methodology, the process improvement team can systematically construct improvements to increase the process area's capability to level2: Managed. This section of the proposed SPI-CMMI framework contains the minimum set of activities or steps, by each phase, which the improvement team should complete. The following table 3.2 provides the suggested activities for each phase of the DMAIC methodology corresponding to capability level 2: Managed. Table 3.2: The suggested activities of DMAIC with CL2 DMAIC Methodology Phases Define Phase What does the customer define as the problem?

Measure Phase What characterizes the current process and performance metrics, and how has it changed over-time? Analyze Phase What are the root causes?

Improve Phase What improvement actions correct the root causes to meet customer requirements again? Control Phase What controls implemented to improvement?

should sustain

be this

Suggested Activities-CL2                     

Determine process owner Define project/process Charter Perform Stakeholder Analysis Gather existing process documentation Gather VOC/VOB to determine requirements Conduct interviews with the improvement team Create process maps (High/Detailed level) Develop data collection plan Collect data to and baseline current performance Analyze the current process Identify process performance requirements/gaps Brainstorm solutions Prioritize process solutions Prioritize and select process solutions Create organizational policy based on VOB Create process description and maps Pilot new process Gather and review metrics on improved process Create implementation plan Provide training Review progress with process owner

Capability Level 3: Defined "A defined process is a managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes process related experiences to the organizational process assets". Its generic goal and corresponding generic practices are: GG 3 Institutionalize a Defined Process GP 3.1 Establish a Defined Process GP 3.2 Collect Process Related Experiences Level 3: Defined DMAIC Suggested Activities Through implementing the Six Sigma's DMAIC methodology, the improvement team can systematically make improvements to enhance and increase the process area's capability to

[45]

Chapter Three: The Proposed Framework level3: Defined. This class of the proposed SPI-CMMI framework contains the minimum set of action plans or activities, by each DMAIC phase, which the improvement team should complete. The succeeding table 3.3 provides the suggested activities of the DMAIC methodology phases corresponding to capability level 3: Defined. Table 3.3: the suggested activities of DMAIC with CL3 DMAIC Methodology Phases Define Phase What does the customer define as the problem? Measure Phase What characterizes the current process and performance metrics, and how has it changed over-time? Analyze Phase What are the root causes?

Improve Phase What improvement actions correct the root causes to meet customer requirements again? Control Phase What controls implemented to improvement?

should sustain

be this

               

Suggested Activities-CL3 Define project/process Charter Gather existing process documentation Gather VOC/VOB to determine requirements Review data related to current performance Collect products, measures and lessons learned

Analyze the current process Identify process performance requirements/gaps Brainstorm solutions Prioritize process solutions Ensure the objectives achievement Prioritize and select process solutions Refine and document tailored process for particular area Pilot new tailored process Gather and review metrics on improved process Create implementation plan Review progress with process owner

3.3.10 Phase 10: Capability Levels Activities Implementation In the final phase, the candidate Six sigma toolsets, techniques and suggested metrics are recommended to be used in applying the recommended activities and tasks for each capability level resulted from previous phase, to ensure more successful implementation of the organization’s CMMI-Dev generic goals and practices in precise and managed manner which facilitate the adoption process of the CMMI-Dev model in the organization. The SPI-CMMI framework provides the improvement team with the detailed description of implementing CMMI capability levels within their generic goals and practices through executing DMAIC methodology with its 5 phases. Each phase of DMAIC has the corresponding tasks, candidate Six Sigma tools and the corresponding deliverables, as described in table 3.4 that offers the DMAIC-Define phase tasks to be performed, recommended tools to be used, and deliverables resulted. Table 3.4: The DMAIC-Define Tasks-Tools- Deliverables Phase Tasks Identify problem

Candidate Tools and Techniques 

SMART Tool

[46]

Deliverables Project

charter

Chapter Three: The Proposed Framework statement/ opportunity and goal statement.



Project Charter Form

Develop High-level process map of activities Gather VOC and business requirements



Process Map RACI Matrix

Develop communication plan Finalize project charter



VOC/VOB Gathering Techniques  Stakeholder Analysis  CTQ Tool  Communication Plan template 

Project Charter Form High-level Process Map  SIPOC Tool  Project RACI Matrix  

approved (contract with the sponsor) High-level process map constructed Critical Parameters Hypothesized Project charter published and communicated High-Level project plan defined/approved

The DMAIC methodology is mainly based on the application of statistical process control, quality tools, in addition to process capability analysis; it is not a product development methodology. Consequently, the DMAIC-Measure phase of the DMAIC methodology has its related tasks, candidate Six Sigma tools, and deliverables as shown in table 3.5. Table 3.5: The DMAIC-Measure Tasks-Tools- Deliverables Phase Tasks

Candidate Tools and Techniques

Define data sources Collect baseline data from existing process Determine current process performance; is it in control? Remove any known special causes; verify if process is in control Develop detailed process map of activities.



Data gathering plan template Control Charts  Statistical Sampling  Graphical methods  QFD Technique

Validate measurement and collection system. Is the process capable of meeting requirements? Revise Problem and Goal statements as needed. Update project plan.

 Measurement



 

Detailed Process Map RACI Matrix, revised System Analysis

( MSA)  Process

Capability Analysis

Project Charter; its plan and milestones.  Project RACI Matrix 

Deliverables Process data collected

Process map defined in-depth with current measures Current measurement system capability evaluated Project Charter and plan updated, as necessary.

The DMAIC methodology can be used to help redesign the organization processes, given that the redesign fixes the initial process problem. Table 3.6 below presents The DMAICAnalyze phase tasks, tools, and deliverables.

[47]

Chapter Three: The Proposed Framework Table 3.6: The DMAIC-Analyze Tasks-Tools- Deliverables Phase Tasks Validate gaps in requirements vs. current metrics. Quantify Opportunity to close gaps. Develop Detailed Process. Map of activities. Quantify Opportunity to close gaps.

Conduct root cause analysis. Prioritize root causes. Quantify opportunity to close gaps. Revise problem and goal statements as needed Update project plan.

Candidate Tools and Techniques Critical Gap/Step Analysis  Pareto Charts  Statistical Analysis: Normal Distribution, Variation  Correlation and Regression  Detailed Process Map  RACI Matrix, revised  Process Mapping of Critical Parameters  Y = f(X)  Pareto Charts  Process Capability Analysis  Brainstorming Technique  Hypothesis Testing  Five Whys  Cause and Effect Diagrams  Affinity Diagram (KJ)  FMEA and DOE  Project Charter; its plan and milestones.  Project RACI Matrix 

Deliverables Data Analyzed

Process Analyzed

Root Cause Analyzed

Project Charter and plan updated, as necessary.

The DMAIC methodology uses a process-step construction. These steps generally are sequential; however, some activities from various steps may occur concurrently or may be iterative. Deliverables for a given step must be completed prior to formal gate review approval. The Improve phase tasks-tools- deliverables are described below in table 3.7. Table 3.7: The DMAIC- Improve phase Tasks-Tools- Deliverables. Phase Tasks Develop potential improvements or solutions for root causes

Candidate Tools and Techniques  Brainstorming Technique  Positive Deviance  TRIZ Develop evaluation criteria  FMEA Measure results.  Basic DOE Evaluate improvements  Pilots/Tests meet targets Evaluate for Risk.  Cost/Benefit Analysis Select and implement  Pugh Concept Evaluation improved process and  Solution Selection matrix metrics.  Force Field diagram  Measurement System Analysis  Process Capability Analysis Develop detailed future  Detailed Process Map process map of  Procedure manual (standard improvement. operating procedure) 

Implementation and Transition Plan

[48]

Deliverables Potential solution generated. Potential solution Evaluated

Solution selected

Improved path forward implemented

Chapter Three: The Proposed Framework Revise problem and goal statements. Update project plan.

Project Charter; its plan and milestones.  Project RACI Matrix 

Project charter and plan updated, as necessary.

The DMAIC methodology uses a precise control scheme to maintain the improvement progress or correction over time by applying a control plan with a monitoring system to audit the response performance against statistical control limits and defined action plans if required, as illustrated below in table 3.8. Table 3.8: The DMAIC-Control phase Tasks –Tools – Deliverables Phase Tasks Document new measurement process Define control plan

Candidate Tools and Techniques

Control Charts (SPC) Stakeholder Analysis  Communication Plan  FMEA/Risk Analysis Validate metrics and  Measurement System Analysis collection systems  Process Capability Analysis  Cost/Benefit Analysis Train  Training/Transition plan Document recommendation  Process Map or improvement summary  RACI Matrix and highlight changes  Procedure manuals from As-Is to improved Establish tracking  Scorecard or Dashboard procedure  Data Mining (MINITAB) Revise problem and goal  Project Charter; its plan and statements to reflect actual. milestones. Update project plan.  Project RACI Matrix Record lessons learned and file along with final  New SIPOC project documentation.  

Deliverables Control plan defined

Improvement /innovation implemented Training conducted

Process documented

Tracking system deployed Lessons learned documented and project closed

After this detailed description of the recommended phases in the proposed SPI-CMMI framework with their definition, steps, activities, candidate tools and techniques, table 3.9 describes the brief representation of these sequential ten phases with the corresponding toolsets, suggested techniques and metrics which will be used in the software organization for the process assessment and improvement.

3.4 Summary This chapter describes in details the appropriate actions and activities required to be implemented in the software development organization in order to achieve a higher improvement level and optimize the development processes. These improvement steps and activities are organized in logical sequence within the successive phases of the proposed SPI-CMMI framework. The proposed SPI-CMMI framework supplies each step and action with the suitable tool, analytical technique, templates for the effective and accurate implementation.

[49]

Chapter Three: The Proposed Framework Table 3.9: The Brief Description of the SPI-CMMI phases The Phase

Phase 1 Improvement Project Initiation Phase 2 Success Metrics Derivation Phase 3 Requirements Collection and Prioritization

Phase 4 Process Areas Prioritization Phase 5 Specific Goal Prioritization Phase 6 Specific Practices Prioritization Phase 7 Action Plans Derivation and Prioritization

Phase 8 Action Plans and Specific Practices Implementation

Phase 9 CMMI Capability Levels Interpretation

Phase 10 Capability Levels Activities Implementation

The Brief Description

Suggested Tools or Metrics

      It is very important for any process improvement effort to  determine which measures should be specified to confirm  improvement benefits, manage performance and monitor  project progress.  Collects requirements from multiple perspectives  (customer, business, management, quality …etc.), and  develops a method based on the priority assessment  technique and QFD technique for the integration and  prioritization of requirements. As a result, the priority  value of each requirement is adjusted after the impacts  from the other requirements are assessed. The set of requirements with adjusted priorities are  related to the specific PAs. The specific PAs are  prioritized based on those process requirements. Thus, the  PAs that achieve higher overall satisfaction of process  requirements get higher importance. For each prioritized PA, specific goals are prioritized  based on those process requirements. Thus, the specific  goals that achieve higher overall satisfaction of process  requirements get higher importance. This level involves the prioritization of specific practices  within all PAs of a specific maturity level (Staged  CMMI) or within all PAs of a specific process category  (Continuous CMMI). Forming improvement teamwork. Six sigma toolkits and techniques are used to evaluate the current state of the organization. Determine the capabilities, strengths, and the weaknesses of the organization processes. The phase contains seven successive steps.

A set of actions is derived from the prioritized practices. The priorities of actions reflect the priorities of process requirements. By executing the actions with the highest priorities, the highest satisfaction level of process requirements can be achieved. Using the appropriate Six Sigma tools in applying the prioritized practices and action plans for each process area, to ensure much more successful implementation of the organization’s CMMI specific goals and practices in accurate and fast manner. Generic goals and practices for each capability level should be implemented to all the CMMI process areas. This phase includes suggested activities, actions and steps within the six sigma methodology (DMAIC). Using the appropriate Six Sigma tools in applying the suggested activities and steps for each capability level, to ensure much more successful implementation of the organization’s CMMI generic goals and practices in precise and managed manner.

[50]

SWOT Tool SIPOC Tool Process Map SMART Technique GOSPA Technique Process Capability Analysis GQM  CTQ Scorecards Dashboard Data Collection Matrix Stakeholder Analysis Brainstorming Technique Voice of Customer QFD Technique MPQP Priority Assessment QFD Technique Prioritization Matrices Priority Assessment FMEA Tool

QFD Technique Prioritization Matrices Priority Assessment Technique QFD Technique Prioritization Matrices Priority Assessment Technique  QFD Technique  Prioritization Matrices  Priority Assessment Technique  House of Quality (HOQ)  A group of appropriate Six Sigma techniques, methods, and suggested metrics for implementing each action and specific practice.  Applying Six Sigma methodology (DMAIC) [Define –Measure – Analyze – Improve - Control]  A group of appropriate Six Sigma toolkits, methods, and techniques for implementing each phase of DMAIC activities.

Chapter four The Ontology Representation of The SPI-CMMI Framework

Chapter Four: The Ontology Representation of SPI-CMMI framework

Chapter four The Ontology Representation of the SPI-CMMI Framework 4.1 Introduction Lately, Ontologies have been used across several domains and for numerous purposes to be applied for various applications. Besides, recent work in Artificial Intelligence is discovering the use of formal ontologies as a way of identifying content-specific agreements for the sharing and reuse of knowledge among software entities. Therefore, this chapter describes how ontology engineering is used in this research in order to build a computerized version of the proposed SPI-CMMI framework with its phases, related activities, recommended tools and the CMMI-Dev 1.3 representation.

For the most excellent and easiest use and adoption of the proposed SPI-CMMI framework in the software development enterprises; they are required to:      

appreciate the details of the phases with their recommended activities, understand the sequence and the reasonable arrangement between the subsequent phases, recognize and educate the various related six sigma tools and techniques which will be used, verify the relationships between various suggested tools, practices, goals and process areas, train all the participants in applying the SPI-CMMI framework, and record all the details of steps that performed in the appropriate documents.

For the objective of dealing with the previous concerns discussed above, a computerinterpretable version of the SPI-CMMI framework would have to be developed. The “computer-interpretable” means a version of the SPI-CMMI framework that could be used by a computer to actually represent all the proposed phases, activities, tools and techniques in addition to a full formalization of the CMMI-Dev v1.3 to facilitate the

[51]

Chapter Four: The Ontology Representation of SPI-CMMI framework adoption process of the proposed SPI-CMMI framework in the software development enterprises. Knowledge is broader than data and information. It is not only contained in information, but also in the relationships among items, their classification, and metadata. Ontology is the formalized definition of these components of knowledge. Ontologies are accepted as means for enabling the organization; storage, and retrieval of knowledge in an organizational memory system through defining a common understanding or vocabulary between people and across a range of applications [65]. Therefore, Ontologies engineering are accepted in this research as means for enabling the software organization, representing, storage, querying and retrieval of knowledge used in the SPI-CMMI in an organizational memory system. They do so by defining a common understanding or vocabulary between people and across a range of applications. When models/standards are presented in ontology, they gain the abilities of machine process ability, share ability, and querying. Liao et al. [54] presented the advantages of ontology use for process modeling clearly. In addition, when both of process reference models/standards and organizational processes are represented by ontologies, they can share the same concepts, be mapped to each other and queried.

4.2 OWL Ontology Language As mentioned earlier in chapter two there are numerous ontology languages provide various facilities for the ontology construction process. From these several languages we select the most recent development in standard ontology languages; it is OWL from the World Wide Web Consortium (W3C), Like Protégé. This choice is done according to the following reasons [66]: 

OWL language makes it possible to describe concepts and provides new facilities. It has a richer set of operators - e.g. intersection, union and negation. It is based on a different logical model which makes it possible for concepts to be defined as well as described. Complex concepts can therefore be built up in definitions out of simpler concepts.



Furthermore, the logical model allows the use of a reasoner which can check whether or not all of the statements and definitions in the ontology are mutually consistent and can also recognize which concepts fit under which definitions. The reasoner can therefore help to maintain the hierarchy correctly. This is particularly useful when dealing with cases where classes can have more than one parent.

[52]

Chapter Four: The Ontology Representation of SPI-CMMI framework Subsequently, for the construction of the SPI-CMMI ontology; the Protégé v3.5 (Build 663) is selected as an ontology editor and knowledge-base framework. Protégé is developed at the Stanford Center for Biomedical Informatics Research (BMIR) at the Stanford University School of Medicine. The Protégé editor provides the successive facilities [53]: 





  

Protégé is a free, open-source platform that provides a growing user community with a suite of tools to construct domain models and knowledge-based applications with ontologies. Protégé can be customized to provide domain-friendly support for creating knowledge models and entering data that is because the Protégé platform supports modeling ontologies via a web client or a desktop client. Protégé implements a rich set of knowledge-modeling structures and actions that support the creation, visualization, and manipulation of ontologies in various representation formats. Protégé ontologies can be developed in a variety of formats including OWL, RDF(S), and XML Schema. Protégé is based on Java, is extensible, and provides a plug-and-play environment that makes it a flexible base for rapid prototyping and application development. Protégé is supported by a strong community of developers and academic, government and corporate users, who are using Protégé for knowledge solutions in areas as diverse as biomedicine, intelligence gathering, and corporate modeling.

The Protégé platform supports two main ways of modeling ontologies [53]: 



The Protégé-Frames editor enables users to build and populate ontologies that are frame-based, in accordance with the Open Knowledge Base Connectivity protocol (OKBC). In this model, ontology consists of a set of classes organized in a subsumption hierarchy to represent a domain's salient concepts, a set of slots associated to classes to describe their properties and relationships, and a set of instances of those classes - individual exemplars of the concepts that hold specific values for their properties. The Protégé-OWL editor enables users to build ontologies for the Semantic Web, in particular in the W3C's Web Ontology Language (OWL). "OWL ontology may include descriptions of classes, properties and their instances. Given such ontology, the OWL formal semantics specifies how to derive its logical consequences, i.e. facts not literally present in the ontology, but entailed by the semantics. These entailments may be based on a single document or multiple distributed documents that have been combined using defined OWL mechanisms".

[53]


4.3 Structure of the SPI-CMMI Ontology Since the OWL is used as the language to construct the SPI-CMMI Ontology, the same approach as in the semantic web is followed. Protégé is the foremost ontology development tool. It is designed to be independent of any precise representation language. An OWL plug-in is available which is used in this study for the creation of SPI-CMMI framework ontology. With the plug-in, Protégé adopts OWL terminology and generates the OWL code for the ontology [53]. The Ontology representation of the proposed SPI-CMMI framework is constructed briefly according to the subsequent steps:  First, the proposed SPI-CMMI framework is initially formalized as ontology as shown in figure 4.1. This ontology captures the main concepts and properties of the framework, according to the interpretation of the ontology perception that is used in knowledge representation. It is called the SPI-CMMI Ontology.  This ontology is then used to represent the ten phases with their suggested activities of the comprehensive SPI-CMMI framework, and the six sigma approach in addition to the full formalization of the CMMI-Dev v1.3 model with its two representations staged and continuous.  In the next step, a generic OWL reasoner, for example; the built-in reasoners in protégé, such as; Pellet1.5.2 [67] , FaCT++, Hermit 1.3.8 or DIG reasoner, is used to verify the consistency checking of the representation, concept satisfiability, classification, and realization.

4.4 Naming Conventions in OWL ontology The naming style followed in constructing the SPI-CMMI ontology is capitalization of class names; for example; Phase_One, Success_Metrics, Maturity_Levels, and ProcessArea_ML4, and object properties names with low-case letters. For the Object Properties (Relations connects between classes) in SPI-CMMI ontology, the recommended style of using an action verb as a prefix to the property; such as executed_By, consists_Of, implemented_By, and has_Precedence. Figure 4.2 illustrated the detailed formalization of the SPI-CMMI ontology structure with its main classes and the corresponding relationships connected between them.

[54]


Continuous representation

Capability Levels

Staged representation

Maturity Levels

Generic Goals Phase Nine Generic Practices Phase Six

Phase Eight

QFD

Phase One

Phase Four

Six Sigma Tools Phase Five

Phase Two Phase Seven

Phase Ten

Figure 4.1: The Initial Formalization of the SPI-CMMI

[55]

Specific Goals Specific Practices

SPI-CMMI Framework

Phase Three

Technique

Process Areas

CMMI-DEV 1.3 Model


SPI-CMMI consists_Of

consists_Of

Phases

CMMI-Dev

satisfied_By

consists_Of

Phase Steps

consists_Of

Staged Representation

Continuous Representation

implemented_By represented_By

QFD Technique

represented_By

Maturity Level consists_Of

implemented_By

Capability Level reached_By

Process Area Six Sigma Approach

represented_By

represented_By

consists_Of

Specific Goal consists_Of

Techniques

DMAIC Methodology

satisfied_By

implemented_By

Generic Goal satisfied_By

Specific Practices

Generic Practices implemented_By

Figure 4.2: The Detailed Formalization of the SPI-CMMI

4.5 The SPI-CMMI Ontology Components Existing ontologies share many structural similarities, regardless of the language in which they are expressed. As mentioned in chapter two, most ontologies describe individuals (instances), classes (concepts), attributes, and relations. Some examples of these components in the SPI-CMMI ontology are given in table 4.1.

[56]

Chapter Four: The Ontology Representation of SPI-CMMI framework Table 4.1: Examples of Components in SPI-CMMI Ontology Component

Component Examples in SPI-CMMI ontology

Classes (Concepts)

Phase One – CMMI-DEV Model – Staged Representation – SixSigma Tools – QFD Technique - Maturity Levels - QPM Process Area ML3 – Assessment Steps – Success Metrics – Mlevel2_Managed

Data Properties (Attributes)

Individuals (Instances)

Object Properties (Relations)

phase name - phase description - process area purpose – step description - matlevel description – step name – process area category - specific goals – generic practices – tool description Create a Process Inventory Risk Mitigation Effectiveness Stakeholder Analysis Technique SG 1 Manage Business Performance GP 3.2 Collect Process Related Experiences The purpose of OPM is to proactively manage the … consists_Of - executed_By - has_Precedence - implemented_By reached_By - represented_By - implement_Proarea - part_Of implement_Caplevels - implement_Matlevels – guarantee_By

4.6 Class Creation in OWL Ontology In an OWL ontology, everything is a subclass of owl:Thing. So the SPI-CMMI Framework class is defined as subclasses of owl:Thing, and has thirteen subclasses belongs to it. There are thirteen classes in the SPI-CMMI ontology under the main class (SPI-CMMI Framework): Phase One, Phase Two, Phase Three, Phase Four, Phase Five, Phase Six, Phase Seven, Phase Eight, Phase Nine, Phase Ten, CMMI-DEV_1.3 Model, Six Sigma Tools, QFD Technique. In addition, each subclass has its own subclasses; for instance, Six Sigma Tools class has three subclasses: Methodologies, Techniques, and Graphical Methods, and so on. Figure 4.3 provides an instant of the class hierarchy of the SPI-CMMI ontology using Protégé editor v3.5 (Build 663).

[57]


Figure 4.3: The Class Hierarchy of SPI-CMMI Ontology using Protégé

[58]

Chapter Four: The Ontology Representation of SPI-CMMI framework Here is an example of the class definitions for the CMMI-DEV_1.3 Model class: CMMI-DEV v1.3 consists of best practices that address development activities applied to products and services. It addresses practices that cover the product’ s lifecycle from conception through delivery and maintenance. CMMI-DEV1.3_Model

4.7 Properties in OWL Ontology There are two main kinds of properties in OWL Ontology: Object Properties and Data type Properties. 

The first category is the Object Properties (relations connect between classes) which link an individual to another class or individual, e.g. consists_Of - executed_By has_Precedence - implemented_By.

As an example, the subsequent is the OWL-Object Property Definition for implemented_By [59]

Chapter Four: The Ontology Representation of SPI-CMMI framework implemented_By 

The second category of properties in OWL Ontology is the Data type Properties that link an individual to a precise value. As an illustration, the following is the OWL-Datatype Property Definition for phase_description. [60]

Chapter Four: The Ontology Representation of SPI-CMMI framework The information that describe the detailed activities of each phase in the proposed SPI-CMMI framework phase_description As stated previously, Protégé is based on Java; the following code sample gives an example of Java code generated by Protégé editor for the class of the six sigma tools in the SPICMMI ontology structure import java.util.*; /** * Generated by Protege (http://protege.stanford.edu). * Source Class: SixSigma_Tools * * @version generated on Thu Aug 17 12:44:58 EEST 2017 */ public interface SixSigma_Tools extends SPI_CMMI_Framework { // Slot tool_Description Collection getTool_Description(); boolean hasTool_Description(); void addTool_Description(String newTool_Description); void removeTool_Description(String oldTool_Description); void setTool_Description(Collection newTool_Description); // Slot tool_Name String getTool_Name(); boolean hasTool_Name(); void setTool_Name(String newTool_Name); void delete(); } For the SPI-CMMI ontology representation using Protégé editor, table 4.2 provides a brief explanation of object properties (relationships) in the SPI-CMMI ontology. Also, figure 4.4 describes the second level representation of the SPI-CMMI ontology structure using the corresponding notations for protégé class (object), slot (relation), and instance (knowledge). The general view of the SPI-CMMI ontology structure is displayed in the snapshot of the Protégé editor in figure 4.5. As the CMMI-Dev model is considered the main class (object) in the SPI-CMMI ontology structure, figure 4.6 revealed an extract of the instances of the CMMI-Dev representation in the SPI-CMMI Ontology using Protégé.

[61]

Chapter Four: The Ontology Representation of SPI-CMMI framework Table 4.2: Object Properties in the SPI-CMMI Ontology Name contain

consists_Of

Concepts Staged Representation → Maturity Levels Continuous Representation → Capability Levels Organization Assessment → Assessment Steps Maturity Level →Process Area

executed_By Generic Practices → DMAIC Activities

guarante_By has_Precedence

implemented_By

Process Area → Suggested Metrics SPI Phases with each other CMMI Maturity Levels CMMI Capability Levels Assessment Steps → Six Sigma Tools Success Metrics →Six Sigma Tools SPI Phases →Six Sigma Tools SPI Phases →QFD Technique Specific Practices → Six Sigma Tools DMAIC Activities →Six Sigma Tools

implement_ Caplevels

Phase Nine →DMAIC Activities

implement_ Matlevels

Phase Three→ Maturity Levels

implement_ Proarea reached_By

Phase Eight→ Process Area Generic Goals→Generic Practices SpecificGoals→Specific Practices

represented_By

CMMI-DEV 1.3 Model → Staged Representation CMMI-DEV 1.3 Model → Continuous Representation

[62]

Descriptions Return the (capability/ maturity) levels that exist in (continuous/staged) representation. Reflects all the PAs (steps) that require for achieving level (phase). Returns the DMAIC phases/activities that execute the capability levels. Represent the suggested metrics for each PA. Reflects all previous phases (levels) that require to be satisfied first. Represents the recommended tools, suggested activities and techniques for implementing the SPI phase, CMMI level, and CMMI-PA. Represent the proposed DMAIC activities in order to implement the capability levels. Reflects the priorities maturity level to be implemented Reflects the CMMI process area to be implemented Reflects the (specific/generic) practices needed to reach the (specific/generic) goals. Reflects the continuous and staged representation in CMMI model.


SPI-CMMI Framework

consists_Of

consists_Of CMMI-DEV 1.3 Model

Organ_Assmnt

Phase One

represnted_By

represnted_By

consists_Of Assmnt_Steps

Contin_Reprs

implmnt_By has_Precedence

Sixsigma_Tools Success_Metrics

Phase Two

contain

CapLevel0 CapLevel1 CapLevel2 CapLevel3

Capabl_Lvls

implmnt_By has_Precedence

Sixsigma_Tools

achieved_By implement_Proare a

Phase Eight

Generic_Goals

QFD_Technique

Phase_Three

reached_By

implmnt_By

has_Precedence

QFD_Technique

Phase_Five

achieved_By

implement_Caplevels DMAIC Activities

Phase Nine

contain Maturity_Lvls

MLevel1 MLevel2 MLevel3 MLevel4 MLevel5

Consists_Of Process_Area achieved_By

Specific_Goals

Generic_Practices

QFD_Technique

Phase_Four

Staged_Reprs

reached_By

Specific_Practices implmnt_By Sixsigma_Tools

QFD_Technique

Phase_Six

has_Precedence Phase_Seven

QFD_Technique

has_Precedence

implmnt_By

guarante_By sugsted_Metrics

Phase Ten

Sixsigma_Tools Figure Legend

Figure 4.4: The second level of SPI-CMMI Ontology using Protégé

Protégé Class (Object) Protégé Slot (Relation) Protégé Instance (Knowledge)

[63]


Figure 4.5: Structure of the SPI-CMMI Ontology using Protégé [64]


Figure: The Structure of the SPI-CMMI Ontology using Protégé 4.3

Figure 4.6: The CMMI-Dev Representation in SPI-CMMI Ontology [65]

Chapter Four: The Ontology Representation of The SPI-CMMI framework

4.8 Design Criteria for SPI-CMMI ontology Five main objective criteria for designing ontologies were established by Gruber [68] to guide and evaluate the ontologies designs whose specific intention is knowledge sharing. A brief summarize of how the SPI-CMMI ontology has taken them into consideration will be given in the following illustration. The five criteria are:  Clarity: Ontology should use objective definitions that are as complete as possible. The complete definitions of the SPI-CMMI ontology are documented with natural language.  Coherence: Inferences in ontology should be consistent with the definitions. The defining axioms should be logically consistent. This research is focused on representation, retrieval, and query rather than reasoning, while reasoning within the SPI domain might be a possibility. Because reasoning is not the intent of this research, no deliberate inferences were made in the design of the SPI-CMMI ontology. However, logical relationships can be implied by the structure and definitions of ontology. To check consistency, the SPI-CMMI ontology is tested by reasoning software as part of the later implementation process.  Extendibility: Ontology should be designed to anticipate the uses of the shared vocabulary. It should offer a conceptual foundation for a range of anticipated tasks. The SPI-CMMI ontology can be easily extended and specialized for each organization, through adding new phases, activities or tools when needed without having to revise the existing definitions.  Minimal Encoding Bias: The representation format or language for the ontology should not introduce constraints that are caused by the language and not the ontology. This was actually achieved with the SPI-CMMI ontology by explicitly designing the ontology structure before the choice of a particular knowledge representation was made. Only then were the available encodings considered.  Minimal Ontological Commitment: Ontology should make the least number of assertions regarding the domain being modeled that will still enable knowledge transfer. This was the philosophy in choosing the knowledge attributes for the representation of the SPI-CMMI ontology. In its slightest meaningful structure, ontology is a restricted terminology containing named concepts and their related natural language definitions. While in this research they may not provide the constructs for reasoning, these flat ontologies can be very useful for knowledge representation, sharing and querying. By emphasizing cleanness and simplicity, ontology can be used productively by a larger share of the community. With these criteria in mind, creation of the ontology can progress [60].

[66]


4.9 Ontology Reasoners Although the SPI-CMMI ontology was designed according to Gruber’s guidelines and criteria, there is an empirical check that can be performed on the SPI-CMMI ontology. One of the benefits of the OWL based ontologies is that they can be processed by a reasoner for consistency, species, and inferences. Consistency checking ensures that no class is defined such that it cannot have a logical instance. Species validation determines the sub-language of OWL that is being employed by the ontology. Several reasoners are available for OWL, including Hermit, FaCT, and Pellet. Because of its seamless integration with Protégé, Pellet reasoner [62] was chosen as the tool for consistency checking, classification and. After running the SPI-CMMI ontology through Pellet 1.5.2 reasoner, it was determined that there were no inconsistencies as described below in Figure 4.7.

Figure 4.7: The consistency checking of SPI-CMMI Ontology Also, figure 4.8 shows the classification of the SPI-CMMI Ontology using the Pellet 1.5.2 reasoner.

[67]


Figure 4.8: Classification of the SPI-CMMI Ontology The inferred OWL sub-language for the SPI-CMMI ontology representation is OWLDL. The computing inferred types of the SPI-CMMI ontology is presented below in figure 4.9.

Figure 4.9: Computing inferred types of SPI-CMMI Ontology

[68]


4.10 Benefits of the SPI-CMMI Ontology The ontology construction for the SPI-CMMI framework enables knowledge capture and sharing by establishing a common conceptualization. Aligning it with software process improvement makes relevant knowledge capture and retrieval more probable because it will happen relative to a particular improvement phase. Using a standard representation language to implement this SPI-CMMI ontology can ease implementation of the proposed SPI-CMMI framework in the software development enterprises and make it adaptable to future uses and changes. Developing the SPI-CMMI ontology is similar to defining a set of software improvement data and their relationships in a rigorous structure for other improvement applications or programs to use. As, Problem-solving methods, domainindependent applications, and software agents use ontologies and knowledge bases built from ontologies as data. The SPI-CMMI ontology provides the following benefits: 

   

  

The SPI-CMMI ontology defines a common vocabulary for researchers who need to share information in the SPI domain. It includes machine-interpretable definitions of basic concepts in SPA, SPI, CMMI, Six Sigma tools and relationships among them. The software development enterprises can use the SPI-CMMI ontology throughout knowledge retrieval and query. The SPI-CMMI ontology enables sharing common understanding of the structure of SPI information among people or different software agents. It enables reuse of improvement phase’s knowledge; in addition it makes domain assumptions explicit and separate domain knowledge from the operational knowledge. The SPI-CMMI ontology provides a complete structure and analysis of the knowledge represented in the proposed SPI-CMMI framework with its suggested phases, related detailed steps, activities, toolsets and recommended techniques. It could be cheaper, faster and easier to be learned and used; also, it decreases the probable mistakes and confusion. It offers a clear understanding of the relationships between the SPI phases, numerous Six Sigma tools, CMMI practices, goals and process areas in an organization. Moreover, any modification in the improvement phases/activities or CMMIDEV model could be relatively easily applied, and a new version could be made available to the users in a moderately short time.

4.11 Summary This chapter describes in details how the ontological representation of the proposed SPI-CMMI framework is constructed using the OWL- Protégé editor. The construction process of the SPI-CMMI ontology is obviously mentioned supported by the related steps, language, concepts, rules, in addition to the design criteria that used. Also, the benefits of the SPI-CMMI Ontology are illustrated in order to guide the software organizations how to use and benefit the SPI-CMMI ontology.

[69]

CHAPTER FIVE The Framework Implementation and Validation

Chapter Five: The SPI-CMMI Implementation and Validation

CHAPTER FIVE The Framework Implementation and Validation 5.1 Introduction The revision and validation process of the SPI-CMMI framework aims to determine to what extent the SPI-CMMI framework able to achieve the acceptable performance levels. There is no doubt that validating the recommended suggestion in the proposed SPI-CMMI framework empirically would require following several software development organizations over several years in addition to the recommended set of the Six Sigma tools and techniques that requires education and training. No software organization that participates would be anonymous from us and we do not have the real data to validate the recommended suggestion. Therefore, this chapter provides a comparative study of the proposed SPI-CMMI framework with the other multimodels which previously mentioned in the literature review in chapter two through using the Characteristics comparison technique. Also, it describes the revision and evaluation process of the proposed SPI-CMMI framework through the validation questionnaire [Appendix (B)] which is answered by the quality professionals and CMMI experts from the SECC center in addition to the validation process through implementing the main parts of the proposed SPI-CMMI framework on a real case study in the CITC center in Zagazig university.

5.2 The Multimodels Comparative Study In this section, the SPI-CMMI framework proposed in this research is compared with the other multimodels which previously mentioned in the literature review in chapter two through using the Characteristics comparison technique.

5.2.1 Characteristics Comparison Technique The characteristics comparison technique compares the various multimodels in a tabular format through describing an extensive list of relevant criteria or characteristics according to the field nature and requirements. Each multimodel is then described in terms of these predefined characteristics and the results are presented in a tabular format. This type of comparison is a high level comparison that well suited for a general overview of the multimodels and it can be used as a basis for other comparison methods with extra details can be collected elsewhere. A lot of information can be inferred from a table listing the characteristics of several improvement multi-models [69].

5.2.2 The Description of the Comparison Characteristics Here is the detailed description for the recommended set of characteristics used in the comparison between the various multimodels. These particular characteristics (or criteria) are selected according to the improvement domain environment, the software organization requirements, and the CMMI definite properties.

[70]

Chapter Five: The SPI-CMMI Implementation and Validation  The model integrated with CMMI: This characteristic determines the other standard, technique, approach, or methodology that integrated with the CMMI model in order to apply the multi-model approach.  Integration Purpose: This characteristic specifies the main objective/motivation for which the multi-model approach is designed.  Multimodel Paradigm: This characteristic classify the multi-model into two main types; whether prescriptive or descriptive model. A prescriptive model; prescribes requirements and processes that are mandatory, defines the desired processes and how they should/could/might be performed, establishes rules, guidelines, and behavior patterns which, if followed, would lead to the desired process performance. They can range from strict enforcement to flexible guidance. In contrast, a descriptive model does not assign specific actions to be taken by the organization. Instead, it describes a state or certain expectations to be met without stating how they should be accomplished.  Organization Size: This characteristic indicates the organization size for which the multi-model approach is suitable. Some multi-models are so comprehensive that only large corporations have the resources to use them. Other approaches are designed especially for smaller companies to employ.  Improvement Focus: This characteristic identifies whether the proposed multi-model approach provides additional assessment/improvement activities more than in the standard models. Improvement focus is related to activities and deals with the means of achieving the end result. Improvement focus may be software development only or organization improvement and software development.  CMMI Scope: This characteristic specifies whether the proposed multimodel supports the CMMI maturity levels or the capability levels.  CMMI Representation: This characteristic specifies whether the proposed multimodel supports the staged or the continuous representation of the CMMI model.  Improvement Initiation: This characteristic specifies to which degree the proposed multimodel provides additional activities and tools to initiate the improvement project and control its progress and benefits. The degree may be fully supported, partially supported, or not supported  Requirements Management: This characteristic specifies to which degree the multimodel approach support the management of the organization, stakeholders and business requirements. The degree may be fully supported, partially supported, or not supported.  Documents/templates Management: This characteristic specifies to which degree the multi-model approach provides the appropriate Documents/templates and supports the management of the documentation process. The degree may be fully supported, partially supported, or not supported.  Validation is needed to evaluate whether the improvement efforts have actually worked. The question should be answered, is whether the same benefits would have been achieved without a multi-model approach effort. In other words, the difficulty lies in establishing a direct causal relation between the multi-model approach efforts and the achieved improvements. The following tables 5.1 (a) and (b) demonstrate the comparative study of the proposed SPI-CMMI framework with the previous multimodel environments especially that related to the CMMI model.

[71]

Chapter Five: The SPI-CMMI Implementation and Validation Table 5.1 (a): The comparative study of the proposed SPI-CMMI framework

Multimodel Criteria The model integrated with CMMI

Integration Purpose

Multi-model Paradigm Organization Size Improvement Focus CMMI Scope CMMI Representation Improvement Initiation Requirements Management Documents/templates Management Validation

Vasiljevic and Skoog (2003)

The SPISO-Model

Yoo et al. (2006)

Tully (2007) Improvement Guide

Qyser and Rao (2008)

practices from ISO 9001:2000

ISO 9001:2000

The Six Sigma approach

The ISO/IEC 14598-5 standard

The SPISO-Model primarily designed for small software organizations in order to improve their software processes.

Presenting a unified model for the ISO-certified organization which wishes to improve its processes continuously using the CMMI model.

Descriptive Small Software development

Descriptive large Software development

Developing a CMMIbased software process evaluation method driven by ISO/IEC 14598-5 recommended activities and deliverables at a reasonable cost. Descriptive Small Software development

Maturity levels staged Not Supported Not Supported

Maturity levels and capability levels continuous Not Supported Not Supported

Providing a guide to Six Sigma practitioners in how using Six sigma to meet CMMI guidelines to incrementally improve the maturity of the software development organization. Prescriptive/Descriptive All Organization improvement and Software development Maturity levels and capability levels Staged and continuous Supported Not Supported

Not Supported

Fully Supported

Fully Supported

Fully Supported

No Validation

The model was compared with other models with respect to reliability, resource efficiency, and mapping complexity.

No Validation

No Validation

[72]

Not care Not care Not Supported Not Supported

Chapter Five: The SPI-CMMI Implementation and Validation Table 5.1 (b): The comparative study of the proposed SPI-CMMI framework Multimodel Criteria The model integrated with CMMI

Integration Purpose

Multi-model Paradigm Organization Size Improvement Focus

Elshafey and GalalEdeen (2008)

Habib et al. (2008)

Agile Methods

Six Sigma's DMAIC methodology

The proposed integration strategy is to use agile participles and methods to enhance or accelerate the implementation of CMMI process areas.

Proposing a framework for blending CMMI with Six Sigma's DMAIC methodology to reduce the time associated with CMMI certification.

Descriptive large Software development

Prescriptive Small and medium Software development

Sun and Liu (2010)

The SPI-CMMI Framework (2017)

The Quality Function Deployment (QFD) technique

The six sigma approach and Quality Function Deployment technique Proposing SPI framework Providing a based on CMMI using QFD comprehensive process/ technique aiming to map software improvement process requirements, strategy to be including business implemented more requirements, to CMMI. effectively and systematically. Descriptive Prescriptive/Descriptive large All Organization improvement Software development and Software development

CMMI Scope CMMI Representation Improvement Initiation Requirements Management Documents/templates Management

7 Process Areas 7 Process Areas Not Supported Not Supported Not Supported No Validation

Validation

CMMI Maturity Level 2 and 3 Staged Not Supported Not Supported Fully Supported

Maturity levels Staged and continuous Not Supported Fully Supported Not Supported

Maturity levels and capability levels Staged and continuous Fully Supported Fully Supported Fully Supported

Only two PAs: Project Planning. Process and Product Quality Assurance.

Only Continuous CMMI 2 PAs: Project Monitoring and Control and Risk Management

Implemented as a prototype in the CITC Center in the Zagazig University

[73]


5.3 The Evaluation of the Proposed SPI-CMMI Framework The proposed SPI-CMMI framework in this research provides a comprehensive systematic methodology for process and products improvement strategy to be implemented in any software development organization that aims to implement system and software process improvement more effectively and systematically. It is based on incorporating Six Sigma approach, and QFD technique within the CMMI-DEV v1.3 model for increasing the likelihood and accelerating of its adoption and enhancing its capabilities and efficiency.

5.3.1 The SPI-CMMI Framework Benefits The benefits of implementing the proposed SPI-CMMI framework in the software organizations may be described as the following; 









The SPI-CMMI framework is based on proposing ten consecutive phases each phase containing a specific set of steps and activities to be employed, in addition to identifying the appropriate toolsets and multiple techniques needed to perform these activities. This structure is based on the sequential association and logical sequence of these phases within their steps and actions. This structure facilitates applying each phase; control its inputs and deliverables, and the efficient use of its recommended toolkits and techniques. Six Sigma approach within its methodology, analytical toolkits and techniques in addition to the QFD technique provide the organization with the practical procedures (what/how/why) and detailed activities needed to execute the improvement project. Apply Six Sigma to improve process performance and serve as the tactical engine to achieve high capability and high maturity level within the CMMI-DEV model. The proposed SPI-CMMI framework provides performing organization assessment to evaluate its current state and determine process capability levels, in order to know where it must start improvement. Also, specifying success metrics and improvement measures to control performance level, show improvement progress towards organization objectives, show return-on-investment (ROI), and feedback for future trends. Using and applying the suggested toolkits and techniques with the corresponding documents and templates in the SPI-CMMI framework provides the full documentation of the improvement and organization processes which considered critical factor in the CMMI appraisal and for the organization training and education purposes. The SPI-CMMI can be considered a proposed improvement framework that is used to structure, plan, control and execute the improvement project from scratch in the software development organizations which aim to adopt the CMMI-DEV model. It will increase the probabilities of successful CMMI appraisals and to reduce the time and costs of understanding the various organization processes to deliver its products/services and to adhere to its contracts and/or improvement requirements.

[74]

Chapter Five: The SPI-CMMI Implementation and Validation 



The SPI-CMMI framework offers the organization with a set of alternatives for the recommended analytical toolkits and techniques in order to help it in selecting the most appropriate from them according to its available resources. The involvement of the various organization stakeholders and collecting the corresponding requests within the business requirements will demonstrate effective and significant enhancements early for the improvement project.

5.3.2 The Implementation Requirements For the effective implementation of the proposed SPI-CMMI framework in the software organizations, there are some issues must be considered, such as; 

 

Some members of the improvement team should have the full knowledge, some education and practice for the Six Sigma approach within its methodology, analytical toolkits and techniques in addition to the QFD technique, how they can use, apply and benefit. The organization should collect, organize, analyze and provide the required data in the applicable format to be used professionally within the suggested phase, step, tool, or technique. The organization should provide the required infrastructure and appropriate resources in addition to create an environment suitable for the efficient implementation and success of the improvement project.

5.3.3 The SPI-CMMI Framework Revision On the other hand, the proposed SPI-CMMI framework is revised and evaluated from the quality and CMMI professional in the SECC center. According to the quality experts'2 survey in the SECC center after applying the validation questionnaire of the SPI-CMMI framework [Appendix (B)], the proposed SPI-CMMI framework in general is nice and could be used, but some details need adjustments. They provide the research with valuable ideas that rich the framework, their estimations towards the proposed SPI-CMMI framework are represented in the following; 



2

They do not think that the approach will be faster than traditional approach. In the traditional approach the company usually needs 12 to 18 months to move from a maturity level to the next. This approach may consume same or more time. The main advantage of the approach is not the time factor. It is mainly in recognizing the benefit of the improvement. The approach considers the viewpoints of different stakeholders and sets the priorities according to this. If you set the priorities correctly, you will show some good and important improvements early and proof them quantitatively which will increase the buy-in of the stakeholders to the SPI program. Setting the priorities of Process Areas, then Goals, then Practices. The CMMI model is more complicated. Many practices in different process areas are closely

Software Process Improvement Professionals, greater than 15 years' experience, CMMI lead appraisers in the SECC center.

[75]


 

 



related. Being classified under different goals of different process areas does not mean we can give them different priorities according to process areas then goals. QFD is a nice approach to identify priorities, but it is not the only one and many other techniques could be better for many companies. Propose different priority identification tools showing the pros and cons of each, not only QFD. Using Six Sigma to improve every single part in the organization looks nice, but actually it is not. Many companies have no data that could be used by the Six Sigma tools. Using Statistical Process Control – through Six Sigma – is time and effort consuming and should be used only for critical aspects with many special considerations. It cannot be applied for everything. The Gap Analysis or SCAMPI C techniques may be used in the first phase for the current state assessment of the organization. Using the Six Sigma approach only when appropriate and applicable. Preferably do not start with Six Sigma. Most of the software companies are very bad in using numbers and statistics. Starting with Six Sigma may frustrate people and kill the SPI project before its start. However the idea could be used trying to measure the baseline performance and compare it later to the enhanced performance. But this could be done with simpler tools and techniques (even qualitative ones). The CMMI should be divided into areas (not process areas) then assign priorities to these areas. For example these areas could be Project Management, Software Design and Development, Testing, Configuration Management, Quality Assurance, Process Management and Training. Each area includes some practices from the CMMI model. For example the Configuration Management area includes all specific practices of CM, SP 1.3 of REQM, SP 2.3 of PP, SP 1.4 of PMC and GP 2.6 of all process areas. You may divide each area to sub areas and set priorities to sub areas. For example Configuration Management could be divided into CM Planning, Baselines, CM Audits and Change Management.

5.4 The Validation Process Because of the time constrain for this research, the validation process is made through implementing the proposed SPI-CMMI framework as a prototype, which means that only some parts of the SPI-CMMI framework phases is implemented –as possible as-on a real case study in the Center for Communication and Information Technology (CITC) in Zagazig University [http://www1.zu.edu.eg/citc/]. Whilst the real case study will not implement the proposed SPI-CMMI framework completely, it will give some indications and allow further elaboration and suggestion creation on that framework for valuable enhancement and modification.

5.5 The Case Study The CITC Center in the Zagazig University is chosen in this research for the validation process of the proposed SPI-CMMI framework according to the following reasons;

[76]

Chapter Five: The SPI-CMMI Implementation and Validation    

The CITC Center can be considered as a small software development organization, as it responsible for providing the university with specific types of software programs. In addition to its intent to register to get the CMMI certificate from the SECC center. Besides that the work environment in the CITC Center requires implementing the prioritization methodology in order to solve the processes importance and conflict in the high peak periods of work, such as the exam periods. The important reason is the agreement of the center manger to implement the framework.

5.5.1 The CITC Center Description CITC was established from 15/6/2004 to provide electronic and information services to Zagazig University. The CITC vision is: "The center aspires to become one of the important global information systems centers through the development of IT services in the university according to international standards." The Mission of the CITC center can be described as that the center desires to;    

create Zagazig University to meet its requirements for electronic information, spread the culture of learning and electronic services, contribute to the process of continuous improvement of the academic and institutional performance of the university, and gain the community confidence in the information and electronic university services.

The CITC center provides the various services to the university faculties, units, staff, employees, students …etc. through the following six main units;      

E-learning Unit Electronic Library Unit University web portal Unit University Automation Unit Training and Information Technology Unit University Infrastructure Development Unit

Therefore, the SPI-CMMI framework phases were implemented to the CITC center. The suggested phases, steps, statistical tools and analytical techniques are used only when appropriate and applicable. But this can be done with simpler tools and techniques (even qualitative ones); because of the infrastructure, resources of the CITC center and time constrains of the research.

5.6 The Implementation Process The implementation process of the proposed SPI-CMMI framework in the CITC center is performed according to the following activities and action described below in the next sections.

[77]


5.6.1 Improvement Project Initiation Primarily for the effective improvement project; it is significant and critical to know where you "actual current state" before you try to get where you are going "desired improved state"! Therefore the improvement in the CITC center will be started according to the following sequential steps: Step1: Formation of the improvement team. For executing the improvement project in the CITC center, it is very critical to form the improvement teamwork first in order to be responsible for all the corresponding improvement action and activities. The Stakeholder Analysis tool helps performing this step easily. The improvement teamwork contains; the CITC manager, the manager of the MIS unit, 2 CITC employees, 2 software developers, 3 programmers, 2 data entry staff, 2 database administrators, in addition to external quality/improvement expert. After the team configuration is completed, regular appointments are scheduled in order to meet periodically. Preliminary meeting and scheduled workshop were held with the improvement teamwork in the CITC center to clarify the objectives of the work and how to achieve them and carry out the required activities and the corresponding tasks. Step2: Develop a planning methodology for the improvement project. In the second meeting with the improvement teamwork, for the rapid employment of the case study in the CITC center, the improvement team developed the planning methodology with the related steps and actions to be performed for the improvement project, through summarizing CITC’s direction and defining how supporting programs and projects relate to it in order to achieve the CITC vision, mission and strategic objectives which previously prepared by the CITC committee. Step3: Specify the scope of the business process. The SIPOC (Supplier-Inputs-Process-Outputs-Customer) technique serves as a high-level snapshot at the beginning of the improvement project to provide a big picture perspective of the existing process. It served as an effective communication tool to explain what could be a multifaceted process in simple terms. The SIPOC technique helped the improvement team to; communicate a high-level view of its processes and related tasks, and prevent scope creep. An example of applying the SIPOC technique to the CITC main processes (for example; developing specific programs) is shown below in figure 5.1.     

Suppliers: University colleges, college students, additional units and centers of the university, other universities, etc. Inputs: University Policies, colleges' requirements, students requests, etc. Process: make students' cards, provide internet services, develop control software, provide exam results, etc. Outputs: control systems, exam results, Student Cards, etc. Customers: University colleges, college students, additional units and centers of the university, other universities.

[78]

Chapter Five: The SPI-CMMI Implementation and Validation The CITC center interests in producing various software programs for different purposes to the University colleges. Therefore, this is the SIPOC representation for the production process of the software programs in the CITC center.

SIPOC Suppliers

Inputs

Process

Outputs

Customers

 Customers  Senior

 Policies  Programming procedures  Customer needs  Requirements  Functional Design  Technical Design  Code

Gather Requirements

 Requirements  Functional Design  Technical Design  Code  Test Plans  Defect Reports  Status Reports

 Customers  Senior

Management

 Project Manager  Designers  Developers  Programmers  Data entry staff

Create Design

Code Software Test Software

 Implementation

Release Software

Management

 Project Manager  Designers  Developers  Testers  Engineers  Client Services

Plan

Figure 5.1: The SIPOC document for software development process Step4: Construct the process map (Activity flowchart or Workflow diagram) A sample of applying the process map tool to the CITC processes is displayed in the following map showed in figure 5.2. The map is constructed for the production process of the software programs in the CITC center in order to describe the activities sequence in that process. High-level Process Map Gather Requirements

Create Design

Code Software

Test Software

Release Software

Detailed Process Map Identify Stakeholde rs

Interview Customer

Document Requirement s

Review Requirement s

Update Requirement s

Figure 5.2: The process map for software development process Step5: Create a process inventory document. For the process documentation and control purpose; the improvement team creates a full document called a process inventory using the detailed process steps defined in the process

[79]

Chapter Five: The SPI-CMMI Implementation and Validation map. A process inventory document collects information related to the various process steps. The process steps along with an assigned ID for reference purpose are the first pieces of information captured. Examples of relevant data included in the process inventory are process inputs, outputs, appropriate tools, assigned resources, capability levels, compliance rating and effectiveness metrics. Microsoft Word was used to capture this information as represented below in table 5.2. Table 5.2: An example of the process inventory document Process ID

1 1.1 1.2 1.3 1.4 1.5

Process Step

Inputs

Outputs

Appropriate Assigned Capability Tools Resources Levels

Gather Requirements Identify Stakeholders Interview Customer Document Requirements Review Requirements Update Requirements

Step6: Assign capability levels for each process. In order to link the improvement project work with the concepts of the CMMI model, the improvement team used the CMMI concept of capability levels as defined in the CMMI model in order to assign a capability level for each process or activity. At this point, the improvement team identified where the improvement project could start upgrading and enhancing the processes with the lowest capability level. 0. Incomplete process 1. Performed process 2. Managed process 3. Defined process Here, table 5.3 provides an example of the capability levels assignment for each process in the CITC center. Table 5.3: An example of the capability levels assignment Process Process Name ID Gather Requirements 1 Create Design 2 Code Software 3 Test Software 4 Release Software 5

Current Capability Levels 0 1 1 1 1

Step7: Formulating strategic direction and management goals/objectives At the end of the first stage it was clear that the nature of work and processes in the CITC center was ad hoc and chaotic. The CITC did not provide a stable systematic environment

[80]

Chapter Five: The SPI-CMMI Implementation and Validation to support processes. Success in CITC depended on the skill and capability of the people in the CITC and not on the use of well-established and planned processes. CITC could produce products and services that work, but they often exceed the budget and schedule documented in their plans. Therefore, it was essential for the CITC center to formulate strategic direction and management objectives for the improvement project.

5.6.2 Performance Management and Success Metrics Derivation Because process improvement projects usually rely on metrics, it is exact important to quantify the clear and brief objectives by making them measurable. So, it is very significant for any process improvement effort to determine which measures should be specified to confirm improvement progress towards CITC objectives and benefits, in addition to, direct and control the various improvement activities and feedback for future objectives. Therefore, in this phase the Goal-Question-Metric (GQM) approach was used for deriving success metrics as illustrated in the table 5.4. Table 5.4: The Goal-Question-Metric approach of CITC center Goal

Increase Profits

Question

Metric

Are our profits increasing?

Profit Margin

Are we staying within budget? Are we gaining new customers?

Increase Product Quality

Increase Customer Satisfaction

Reduce Time to Market

What is our rate of defects?

Budget Performance New Customer sign-ups Production Defect Density

Measure Revenue – costs Return on Investment (Net Benefits/Costs) x 100 Actual – budget Cost Savings Customer Acquisition Customer Profitability Defects/Software size DPMO Functional Requirements Non- Functional Requirements

Is our customer able to access our applications?

System Availability

How satisfied are our customers with the products and services we provide?

Customer Satisfaction

Average Satisfaction rating Customer Use

Are we getting repeat business?

Customer Loyalty/Retention

Repeat customer/ current customers

How long is it taking us to deliver our product?

Cycle time

Duration/Effort

Are we doing more work in less time?

Productivity

Output produced per unit of input ex. Software size/ Effort

[81]


5.6.3 Requirements Collection and Prioritization Satisfying stakeholders' requirements are always the primary focus of most enterprises and improvement projects. Therefore, requirements collection was an important and effective step in the success and guidance of the improvement project within CITC center. According to the analysis of the CITC processes, the main stakeholders were center management, units' management, system staff, developers, some faculties' members, university students. In this stage the requirements were collected through interviewing and surveying the various CITC stakeholders in scheduled meetings. These requirements could be categorized in the simplest form as the following. Requirements from the management perspective primarily deal with the objectives toward the production of software. These requirements include; on schedule, within budget, increase productivity, high customer satisfaction, manage project aggressively, high conformance to software engineering standard. Requirements from the faculty members and students' point of view can be summarized in; accessibility, availability, ease of use, the speed of response, the accuracy of the results and the absence of errors. Requirements for achieving high level of quality mainly deal with the quality issues of software products. These requirements include; high usability, high reliability, low failure rate, low defect rate, high maintainability, and high requirement satisfaction. According to the detailed study of the collected requirements and the analysis of the work nature in CITC; the most active and core unit is the Management Information Systems Unit (MIS) which mainly interested in the automation process of the university basic functions and various systems. The MIS unit is based on design and implementation of the following systems in Zagazig University;         

Student affairs system.  Social solidarity system. Personnel Affairs System.  System of university cities The system of graduate studies.  System of cultural relations. Publishing system of university journals.  Systems of accounting units. System of automation of university councils. The system of members of the teaching body. System for automating the work of training courses. Performance evaluation system and quality assurance. System for automating students' hospital (medical examination automation).

Hence, according to the time constrain of the research; the succeeding phases of the proposed SPI-CMMI framework implemented only to the MIS unit and its main functions.

5.6.4 CMMI-Dev Process Areas (PAs) Prioritization When the improvement teamwork completed assessment process of the CITC center and the evaluation process of its related activities concluded the following from implementing the previous phases of the proposed SPI-CMMI framework;

[82]

Chapter Five: The SPI-CMMI Implementation and Validation  The CITC center aimed to adopt the CMMI-DEV model and intend to register for the corresponding CMMI level certificate.  The CITC processes could be classified within the CMMI-Dev Maturity level 1 according to their work methods and performance level.  The MIS unit was considered the most core and active unit in the CITC center according to its several software products and services that serves most of the center's stockholders.  There are high peak periods of work within the CITC center during the examination periods and the results announcement for the students in the various faculties at the university, in addition to the provision of numerous services to the students in that time. Therefore, there is a strong requisite to prioritize the existing processes within the CITC center. Therefore, the improvement team decided in this meeting to select the CMMI-Dev staged representation to apply first for the CMMI-Dev Maturity level 2. Although the CMMI-Dev Maturity level 2 contains 7 process areas, but according to the precise and critical requirements of the center stakeholders and the unique aspects of the CITC processes and functions, the higher priority and importance was assigned to the Configuration Management (CM) process area. At this point the improvement teamwork began to focus mainly on applying the configuration management process area with its related specific goals and practices first.

5.6.5 The Assessment Process for the MIS unit in CITC At this stage, an external team under the supervision of the researcher, consisting of 4 students from the fourth year of the Faculty of Computers and Informatics, was assigned to carry out the pre-appraisal of the MIS unit in the CITC center through comparing the CM theoretical goals and practices required by the CMMI model with the actual activities executed in the MIS unit in the current system. Configuration Management (CM) [Maturity level 2 - Support Category] According to the CMMI-DEV model, the purpose of CM is to create and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. It focuses on the accurate control of the managerial and technical facets of work products, including the provided product or service. This policy establishes organizational expectations for establishing and maintaining baselines, tracking and controlling changes to work products (under configuration management), and establishing and maintaining integrity of the baselines. The pre-appraisal process was carried out through a series of predefined meetings with all the staff of the MIS unit for information collection, as well as a detailed analytical study of the existing activities and the related tasks via the scientific methodology and modelling techniques (Data Flow Diagram, Entity Relationship Diagram, and Business Process Modelling Notation). The final results obtained by the pre-appraisal team are summarized as follows in the table 5.5.

[83]

Chapter Five: The SPI-CMMI Implementation and Validation Table 5.5: The assessment process of the MIS unit in CITC center CMMI-Dev Configuration Management (CM) A Support Category PA ML 2

Current System

SG 1 Establish Baselines SP 1.1 Identify Configuration Items SP 1.1.1 Select configuration items and work products that compose them based on documented criteria. SP 1.1.2 Assign unique identifiers to configuration items. SP 1.1.3 Specify the important characteristics of each configuration item. SP 1.1.4 Specify when each configuration item is placed under configuration management. SP 1.1.5 Identify the owner responsible for each configuration item. SP 1.1.6 Specify relationships among configuration items. SP 1.2 Establish a Configuration Management System SP 1.2.1 Establish a mechanism to manage multiple levels of control. SP 1.2.2 Provide access control to ensure authorized access to the configuration management system. SP 1.2.3 Store and retrieve configuration items in a configuration management system. SP 1.2.4 Share and transfer configuration items between control levels in the configuration management system. SP 1.2.5 Store and recover archived versions of configuration items. SP 1.2.6 Store, update, and retrieve configuration management records. SP 1.2.7 Create configuration management reports from the configuration management system. SP 1.2.8 Preserve the contents of the configuration management system. SP 1.2.9 Revise the configuration management structure as necessary.

No No No No No No No No No No No No No No No

SP 1.3 Create or Release Baselines SP 1.3.1 Obtain authorization from the CCB (configuration control board) before creating or releasing baselines of configuration items. SP 1.3.2 Create or release baselines only from configuration items in the configuration management system. SP 1.3.3 Document the set of configuration items that are contained in a baseline. SP 1.3.4 Make the current set of baselines readily available.

No No No No

SG 2 Track and Control Changes SP 2.1 Track Change Requests SP 2.1.1 Initiate and record change requests in the change request database. SP 2.1.2 Analyze the impact of changes and fixes proposed in change requests. SP 2.1.3 Categorize and prioritize change requests. SP 2.1.4 Review change requests to be addressed in the next baseline with relevant stakeholders and get their agreement.

[84]

No No No No

Chapter Five: The SPI-CMMI Implementation and Validation SP 2.1.5 Track the status of change requests to closure. SP 2.2 Control Configuration Items SP 2.2.1 Control changes to configuration items throughout the life of the product or service. SP 2.2.2 Obtain appropriate authorization before changed configuration items are entered into the configuration management system. SP 2.2.3 Check in and check out configuration items in the configuration management system for incorporation of changes in a manner that maintains the correctness and integrity of configuration items. SP 2.2.4 Perform reviews to ensure that changes have not caused unintended effects on the baselines. SP 2.2.5 Record changes to configuration items and reasons for changes as appropriate.

No

No Yes No No No

SG 3 Establish Integrity SP 3.1 Establish Configuration Management Records SP 3.1.1 Record configuration management actions in sufficient detail so the content and status of each configuration item is known and previous versions can be recovered. SP 3.1.2 Ensure that relevant stakeholders have access to and knowledge of the configuration status of configuration items. SP 3.1.3 Specify the latest version of baselines. SP 3.1.4 Identify the version of configuration items that constitute a particular baseline. SP 3.1.5 Describe differences between successive baselines. SP 3.1.6 Revise the status and history of each configuration item as necessary.

No No Yes Yes Yes No

SP 3.2 Perform Configuration Audits SP 3.2.1 Assess the integrity of baselines. SP 3.2.2 Confirm that configuration management records correctly identify configuration items. SP 3.2.3 Review the structure and integrity of items in the configuration management system. SP 3.2.4 Confirm the completeness, correctness, and consistency of items in the configuration management system. SP 3.2.5 Confirm compliance with applicable configuration management standards and procedures. SP 3.2.6 Track action items from the audit to closure

No No No Yes Yes No

5.6.6 Action Plans Derivation/ Implementation Based on the results of the MIS assessment process, there were only six sub-practices that actually implemented in the current system, which means that the implementation rate of the CM process area in the CITC center is only about 15%. Hence, the proposed SPICMMI framework provided the improvement team with the appropriate six sigma tools

[85]

Chapter Five: The SPI-CMMI Implementation and Validation and analytical techniques required to satisfy the CMMI-CM process area in the MIS unit as illustrated below in the following description. The Checklist (Check Sheet) helps the improvement team to determine what activities or deliverables are required to meet the various requirements. This can be achieved efficiently through the next sequential steps:  Outline (or list) the set of tasks or deliverables to be completed.  Remind someone of the various components to fulfill requirements.  List all possible considerations to determine if appropriate or required for a given situation.  Review the standard operating procedure (SOP) activities or deliverables.  Collect data about “how many” or “what type” of something occurred. Run Charts (or Time Series plot) tool answers three main questions about the performed process; how does the data look over time? Are the data randomly distributed over time? Does the process look stable and random over time? The improvement team can implement this tool professionally by performing these tasks;  Graphically display a data set to detect trends, shifts, cycles, or extreme values in the data.  Determine if the process is stable over time and randomly distributed. Statistical process control (SPC) charts (or Control Charts) are used to specify how is the process behaving; is it in statistical control? These can be done accurately via executing the following activities:  Determine whether a process is stable (in statistical control) over time.  Measure, monitor, and control processes.  Determine what is a special cause event (unexpected variation) that needs to be identified and eliminated.  Interpret common cause variation (predictable and expected) or the inherent variation in a process versus unexpected variation.  Predict changes and indicate the need to improve process performance or determine if an improvement actually reduces process variation. (Key triggers include quality, cost, and capacity.) The Critical-to-Quality (CTQ) Technique decides how does the actual work relate to the various collected requirements, and how do the process staff know when they have fulfilled them? Therefore, the appropriate persons in the MIS unit must perform the subsequent tasks effectively;  Understand customer, management, and quality general requirements in more explicit and specific terms.  Translate all the collected requirements into specific, actionable, measurable language for those who work in the process (ex. process worker).

[86]

Chapter Five: The SPI-CMMI Implementation and Validation The Pugh Concept Evaluation enables the designer, developer and programmer of the software to decide which design or potential solution option is the best one of the available alternatives according to the existing resources and the various requirements. These activities are automatically required from the development team in the MIS unit;  Articulate fundamental principles important to the integrity and feasibility of a concept.  Gain better insight into the concept requirements, design problems, and potential solutions.  Refine design options and select the optimal one based on a common set of criteria from benchmark data. The Conjoint Analysis Technique assists the development team in MIS unit to specify what product/services features and functionality do customers prefer and would be willing to accept? This technique can be implemented successfully through the following actions;  Determine consumer preference and behavior by making trade-offs between choices.  Understand price sensitivities to various product and/or services attributes and levels to determine the most appealing combinations.  Characterize and verify customer requirements (implicit and explicit). In addition to these recommended Six Sigma tools and techniques the improvement team in the CITC center can use the following CMMI-Dev recommendations as mentioned in the CMMI documentation in order to help the MIS unit for the CM sub-practices definite and accurate implementation. SP 1.1.3 Example characteristics of configuration items include author, document or file type, programming language for software code files, minimum marketable features, and the purpose the configuration item serves. SP 2.2.2 For example, authorization can come from the CCB, the project manager, product owner, or the customer. SP 3.2.4 Completeness, correctness, and consistency of the configuration management system’s content are based on requirements as stated in the plan and the disposition of approved change requests. Employing the recommended six sigma toolkits and techniques enabled the improvement team in CITC center implement most of the sub-practices related to CMMI-CM process area in accurate and effective manner in order to enhance the performance of MIS unit within the CITC center, besides providing the full documents related to CM work products for the CMMI appraisal. Also, according to CMMI-Dev for the documentation purpose, examples of work products of the software development that can be placed under the CM process area include the subsequent: Tool configurations, Process descriptions, Product specifications, Test tools and test scripts, Hardware and equipment, Code, compilers and libraries, Requirements and user stories, Product technical publications, Product data files and drawings, Iteration backlogs and installation logs, Architecture documentation and design data, Product line plans, processes, and core assets.

[87]


5.7 The Implementation Results Due to limited research time, after three months only of follow-up and implementation of these proposals and recommendations provided by the proposed SPI-CMMI framework in this research, the following results were obtained: 

The CITC center has a trained improvement team in order to prepare the center for the CMMI accreditation.



Availability of documents required for the evaluation and examination process by CMMI appraisals.



Determination of the control measures and metrics in order to manage, follow and control the improvement progress.



There is a structured methodology with the definite steps and appropriates tools in order to achieve the continuous improvement in the CITC center more accurate and efficiently.



The ratio between actual reality in the MIS unit in the CITC center and the implementation requirements of CM process area (specific goals, specific practices and their related sub practices) reached from 15% to about 35%.

This increase in compatibility ratio means that the proposed SPI-CMMI framework has progressive results and optimistic effects for the software development organizations if it is applied in a complete manner with the availability of resources and the required training for the suggested tools and recommended techniques, also within the large software organizations the proposed SPI-CMMI framework will achieve positive results; because of the availability of the required resources and infrastructure.

5.8 Summary This chapter describes the comparative study conducted on the proposed SPI-CMMI framework with the previous similar multimodels according to the selected criteria using the characteristics comparison technique. Also, it displays the review and evaluation process carried out by CMMI experts that was used to modify some of the proposed tools and steps. In addition to, it presents the implementation process the proposed SPI-CMMI framework on the case study and discusses the most important results of the implementation process.

[88]

CHAPTER SIX CONCLUSIONS, FUTURE WORK AND RECOMMENDATIONS

Chapter Six: Conclusions, Future work and Recommendation

CHAPTER SIX Conclusions, Future Work and Recommendations This chapter presents a summary of the research findings and its significance. Suggestions for improvement and future work are also discussed.

6.1 Summary and Conclusions In order to enhance the capabilities of the software process improvement models, especially the CMMI model; this research adopt the improvement multi-model environment through proposing a practical improvement methodology that is based on integrating the Six sigma approach (analytical toolkits, techniques and methodology) and QFD technique within the CMMI-Dev model. This proposed systematic methodology helps the organization to optimize and improve the existing processes in addition to facilitating the adoption process of the CMMI-Dev model, thus it is named the proposed SPI-CMMI framework. The value intention of this combination is the incorporation of their best practices in a comprehensive improvement strategy, that otherwise would not be possible to obtain by a single technological approach. Therefore, the proposed SPI-CMMI framework fills in "what/how/why" technologies combination which provides theoretically what improvement processes should be done in order to satisfy most of the critical stakeholders' requirements as well as practically how the organization and improvement processes can be implemented efficiently using the analytical toolkits, appropriate techniques, and the detailed steps or action plans. The proposed SPI-CMMI framework is described in details with its sequential phases, suggested tasks, and action plans within the recommended analytical toolkits, appropriate techniques, and methods. Then it is compared with the previous multimodels according to a specific set of criteria according to the field nature through the characteristics comparison technique in order to describe its valuable benefits and advantages. The proposed SPI-CMMI framework is revised and estimated from the improvement and the CMMI professionals in the SECC center via the corresponding validation questionnaire in order to confirm its validity. A computerized version for the knowledge representation, retrieval and query in the proposed SPI-CMMI framework is developed using the ontology engineering with the OWL language that is constructed using the OWL-protégé editor.

[89]

Chapter Six: Conclusions, Future work and Recommendation Finally, the proposed SPI-CMMI framework is implemented as a prototype to a real case study in the CITC center in Zagazig University to determine to what degree it is able to achieve the acceptable performance level. The implementation of proposed SPI-CMMI framework on the small scale -due to the limited time of the research- is proved progressive results and optimistic effects for the software development organizations.

The following list summarizes the contributions of this thesis; 1. An effective structured methodology is proposed for enhancing the capabilities of the CMMI-Dev model. 2. The adoption process of the CMMI-Dev model in the software development organizations will be facilitated through providing the organization with the analytical and practical toolkits and techniques. 3. A comprehensive improvement methodology called the proposed SPICMMI framework is proposed with the appropriate steps, actions and the candidate toolkits and techniques in order to implement the improvement project in accurate, effective, and systematic manner. 4. The proposed SPI-CMMI framework is compared with the other multimodels through a set of precise criteria in order to describe its benefits and advantages. 5. An ontological construction of the proposed SPI-CMMI framework is developed using the ontology engineering with the OWL language. 6. The proposed SPI-CMMI framework is revised from the quality experts through the validation questionnaire in order to confirm its validation degree. 7. The proposed SPI-CMMI framework is implemented to a real case study in order to examine its validity and to determine to what extent it is able to achieve the acceptable performance level.

6.2 Future Work and Recommendations This study is regarded as the primary step in the long term research agenda of the researcher in the area of SPI models, especially for enhancing the capabilities of the SPI models. Therefore, suggestion and recommendations for improvement and issues for future work can include the following research topics: 1. Distributing the validation questionnaire of the proposed SPI-CMMI framework to several business organizations in order to gain more responses and opinions towards the framework validity. 2. Implementing the full version of the proposed SPI-CMMI framework to many software organizations so as to measure the improvement degree and prove its effectiveness and efficiency. 3. Expanding the ontology representation of the SPI-CMMI framework in order to add more functions or to integrate with other ontologies. 4. Modifying the proposed improvement framework in order to include another improvement or quality model.

[90]

REFERENCES

References

REFERENCES [1] Carnegie Mellon University-Software Engineering Institute CMU-SEI, (2010), "CMMI® for Development, Version 1.3", CMU/SEI-2010-TR-033, ESC-TR-2010-033, Pittsburgh, USA. [2] Kulpa, K. M., and Johnson, A. K., (2008), Interpreting the CMMI®: a process improvement approach, 2nd ed., CRC Press LLC, Auerbach Publications, Taylor and Francis Group. [3] Ferreira, A., and Machado, R., (2009), ''Software Process Improvement in Multimodel Environments'', Fourth International Conference on Software Engineering Advances, IEEE Computer Society, DOI 10.1109/ICSEA.80, p.p. 512-517. [4] Dumke, R., Braungarten, R., Blazey, M., Hegewald, H., Reitz, D., and Richter, K., (2006), "Software Process Measurement and Control", Faculty of Computer Science, Otto von Guericke University Magdeburg. [5] Wang, Y., and Bryant, A., (2002), Process-Based Software Engineering, Annals of Software Engineering, Volume 14. [6] SPICE, (1995), "ISO/IEC Software Process Assessment", SPICE Working Draft V1.00. [7] Vasiljevic, D., and Skoog, S., (2003), "SPI Framework for Small Organizations", Master Thesis, Software Engineering, MSE-2003:28, Blekinge Institute of Technology, Sweden, August. [8] Mutafelija, B., and Stromberg, H. (2009), Process Improvement with CMMI® v1.2 and ISO Standards, CRC Press LLC, Auerbach Publications, Taylor and Francis Group. [9] Kelemen, Z. D., Kusters R., and Trienekens J., (2012), ''Identifying criteria for multimodel software process improvement solutions – based on a review of current problems and initiatives'', Journal of Software Maintenance and Evolution: Research and Practice, vol. 24, p.p. 895–909. [10] Sheard S., (2001), Evolution of the frameworks quagmire. Computer, vol. 34(7), p.p. 96–98. DOI: 10.1109/2.933516. [11] Paulk, C. M., (2009), ''A Taxonomy for Improvement Frameworks'', SEI-Carnegie Mellon University, Pittsburgh, PA USA. 10.1.1.141.6438. [12] García-Mireles, G. A.; Moraga, M. Á.; García, F.; and Piattini, M., (2015), "Approaches to promote product quality within software process improvement initiatives: A mapping study", The Journal of Systems and Software, vol. 103, pp. 150–166. [13] Suganya, M. and Alagarsamy, K. (2016), "A Review on Software Process Improvement Methodologies for Small and Medium Enterprises", IJSTE - International Journal of Science Technology & Engineering, vol. 2, Issue 08, February, ISSN (Online): 2349-784X. [14] Van der Piji, G.J., Swinkels, G.J.R, and Verrijdt, J.G., (1997), "ISO 9000 versus CMM: Standardization and Certification of IS Development", Information and Management Journal, Vol. 32, pp. 267-274. [15] Hari, S., and Sanne, S., (2004), "A Statistical Approach for Comparing TickIT and CMM", TickIT International 1Q04, Firm Focus on behalf of BSI. [16] Ferreira, A. L., (2016), ''Methodological approaches for software process improvement in multi-model environments'', Ph.D. thesis, engineering school, Minho's university.

[91]

References [17] Siviy, J., Kirwan, P., Marino, L., and Morley, J., (2008), Strategic Technology Selection and Classification in Multimodel Environments, SEI-Carnegie Mellon University, Pittsburgh. [18] [a] Ferreira, A., Machado, R., and Paulk, M. C., (2010), ''Size and Complexity Attributes for Multimodel Improvement Framework Taxonomy'', 36th EUROMICRO Conference on Software Engineering and Advanced Applications, IEEE Computer Society, DOI 10.1109/SEAA.54, p.p. 306-309. [19] Pardo, C.; Pino, F. J.; Garcia, F.; Baldassarre, M. T.; and Piattini, M., (2013), ''From chaos to the systematic harmonization of multiple reference models: A harmonization framework applied in two case studies'', The Journal of Systems and Software, Vol. 86 (1), pp. 125-143. [20] Persse, J. R., (2006), Process Improvement Essentials, O'Reilly Media, Inc., USA. [21] Sun, Y., and Liu, X., (2010), "Business-Oriented Software Process Improvement based on CMMI Using QFD", Information and Software Technology, vol. 52, pp. 79–91. [22] Carnegie Mellon University-Software Engineering Institute CMU-SEI, (2008), "CMMI® or Agile: Why Not Embrace Both!", CMU/SEI-2008-TN-003, Pittsburgh, USA. [23] Habib, M., Ahmed, S.; Rehmat, A.; Khan, M.J.; Shamail, S., (2008), ''Blending six sigma and CMMI – an approach to accelerate process improvement in SMEs'', p.p. 386391, Multitopic Conference. INMIC. IEEE International. [24] Tully, E. M., (2007), A guide for utilizing Six Sigma in achieving CMMI maturity goals, Master Thesis, ProQuest Dissertations and Theses (PQDT); Fall. [25] Huang, S.-J.; and Han, W.-M., (2006), ''Selection priority of process areas based on CMMI continuous representation'', Information and Management, vol. 43, p.p. 297–307. [26] [b] Ferreira, A., Machado, R., and Paulk, M. C., (2010), ''Quantitative Analysis of Best Practices Models in the Software Domain'', Asia Pacific Software Engineering Conference, IEEE Computer Society, DOI 10.1109/APSEC.56, p.p. 433-442. [27] Iqbal, J.; Ahmad, R. B.; Md Nasir, M. H. N.; Niazi, M.; Shamshirband, S.; and Noor, M. A. (2016), "Software SMEs’ unofficial readiness for CMMI_-based software process improvement", Software Qual J vol. 24, pp. 997–1023, DOI 10.1007/s11219-015-9277-3. [28] Yoo, C., Yoon, J., Lee, B., Lee, C., Lee, J., Hyun, S., and Wu, C., (2006), "A Unified Model for the Implementation of both ISO 9001:2000 and CMMI by ISO-Certified Organizations", the Journal of Systems and Software, Elsevier Inc., vol. 79, p.p. 954–961. [29] Qyser, M. A. A. and Rao, K. V. B., (2008), ''A Software Process Evaluation Method for Small Organizations combining ISO/IEC 14598 and CMMI'', Proceeding of the 2nd national conference, INDIACom, Computing for national development, February 8-9, New Delhi. [30] Doyle, K. (2009), CMMI, ITIL and ISO 20000: A Mutually Supportive Relationship, EXTERNAL – Lamri Ltd, MKTG_PRE_650. [31] Baldassarre, M. T., Pino, F. J., Piattini, M., and Visaggio, G., (2009), Comparing ISO/IEC 12207 and CMMI-DEV: towards a mapping of ISO/IEC 15504-7, ICSE’09 Workshop, WoSQ’09, May 16, Vancouver, Canada, IEEE. [32] Baldassarre, M. T., Caivano, D., Pino, F. J., Piattini, M., and Visaggio, G., (2010), A Strategy for Painless Harmonization of Quality Standards: A Real Case, Springer-Verlag Berlin Heidelberg, PROFES, LNCS 6156, pp. 395–408. [33] Baldassarre, M. T., Caivano, D., Pino, F. J., Piattini, M., and Visaggio, G., (2012), ''Harmonization of ISO/IEC 9001:2000 and CMMI-DEV: from a theoretical comparison to a real case application'', Springer Science Business Media, LLC, Software Quality Journal, vol. 20, p.p. 309–335.

[92]

References [34] Carnegie Mellon University-Software Engineering Institute CMU-SEI, (2008), "CMMI® or Agile: Why Not Embrace Both!", CMU/SEI-2008-TN-003, Pittsburgh, USA. [35] Elshafey, L. A., and Galal-Edeen, G. H., (2008), Combining CMMI and Agile Methods, INFOS2008, March 27-29, Cairo-Egypt, Faculty of Computers and Information-Cairo University, p.p. 27-39. [36] CMMI and Agile (2013), Retrieved 5 June 2013 from [http://cmmiinstitute.com/cmmi-getting-started/cmmi-compatibility/cmmi-and-agile/]. [37] Marchewka, J. T., (2006), Information Technology Project Management, second edition, John Wiley and Sons. [38] Kenett, R. S., and Baker, E. R. (2010), Process Improvement and CMMI® for Systems and Software, CRC Press, Auerbach Publications, Taylor & Francis Group, LLC, Boca Raton. [39] Siviy, J. M., Penn, M. L., and Stoddard, R. (2007), ''Achieving Success via MultiModel Process Improvement'', SEPG 2007, Carnegie Mellon University- SEI, Pittsburgh, PA 15213-3890. [40] Linderman, K., Schroeder, R.G., Zaheer, S., and Choo, A.S., (2003), ''Six Sigma: a goal-theoretic perspective'', Journal of Operations Management, vol. 21, p.p. 193–203. [41] El-Haik, B., and Shaout, A., (2010), ''Software Design for Six Sigma: A Roadmap for Excellence'', John Wiley and Sons, Inc., Hoboken, New Jersey. [42] Hambleton, L., (2008), Treasure chest of six sigma growth methods, tools and best practices, Prentice Hall, Pearson Education, Inc. [43] Siviy, J. M., and Forrester, E. C. (2004), ''Using Six Sigma to Accelerate the Adoption of CMMI for Optimal Results'', Carnegie Mellon University- Software Engineering Institute, Pittsburgh, PA 15213-3890. [44] Siviy, J. M., Penn, M. L., and Harper, E. (2005), ''Relationships between CMMI® and Six Sigma'', Carnegie Mellon University- Software Engineering Institute, CMU/SEI2005-TN-005, Pittsburgh. [45] Wilson, D., (2005), ''CMMI® and Six Sigma Synergy'', SEPG, Natural SPI, Inc. [46] Albeanu, G., Thyregod, P., Madsen, H., and Popentiu-Vladicescu, F., (2006), "On Using Six Sigma Methodology for Software Quality Assurance", the sixth Annual ENBIS Conference in Wroclaw, Poland. [47] Siakas K. V., Nisioti K. S., Voutsa E. A., Gellén M., (2006), ''Integrating Six Sigma with CMMI for High Quality Software, Perspectives in Software Quality'', Proceeding of the 14th Software Quality Management Conference, (SQM 2006), April, Southampton, UK, ISBN 1-902505-76-X, The British Computer Society, pp. 85-96. [48] Safaie, M., (2017), "Capability maturity model integration with approach of agile Six Sigma", International Journal of Agile Systems and Management (IJASM), vol. 10, no. 1. [49] Chan, L-K., and Wu, M-L., (2005), "A systematic approach to quality function deployment with a full illustrative example", The International Journal of Management Science, vol. 33, pp. 119 – 139, Omega. [50] Achimugu, P., Selamat, A., Ibrahim, R., and Mahrin, M. N., "A systematic literature review of software requirements prioritization research", Information and Software Technology, vol. 56, pp. 568–585, February 2014. [51] Ontology (2017) Available at http://en.wikipedia.org/wiki/Ontology_(information_science) [last Access 17/8/2017] [52] Corcho, O., Fernández-López, M., and Gómez-Pérez, A., (2003), ''Methodologies, tools and languages for building ontologies. Where is their meeting point?'', Data & Knowledge Engineering, vol. 46, p.p. 41–64.

[93]

References [53] Protégé 2017 Available at http://protege.stanford.edu (last Access 17/8/2017) [54] Liao, L., Qu, Y., and Leung, H., (2005), ''A Software Process Ontology and Its Application''. ISWC, Workshop on Semantic Web Enabled Software Engineering. [55] Soydan, G. H., and Kokar, M. M., (2006), “An OWL Ontology for Representing the CMMI-SW Model,” The 2nd International Workshop on Semantic Web Enabled Software Engineering, Athens, 6 November. [56] Rungratri, S., and Usanavasin, S., (2008), ''Project Assets Ontology (PAO) to Support Gap Analysis for Organization Process Improvement Based on CMMI'', Making Globally Distributed Software Development a Success Story, Springer, Berlin/Heidelberg, May, p.p. 76-87. [57] Ferchichi, A.; Bigand, M.; and Lef`ebvre, H., (2008), ''An Ontology for Quality Standards Integration in Software Collaborative Projects'', Proceedings of MDISIS, vol. 430, p.p. 17-30. [58] Lee, C.-S.; Wang, M.-H.; Yan, Z.; Lo, C.; Chuang, H.; and Lin, Y., (2008), ''Intelligent estimation agent based on CMMI ontology for project planning, Systems, Man and Cybernetics'', SMC 2008. IEEE International Conference, 12-15 Oct., pp. 228– 233, 978-1-4244-2384-2, Singapore. [59] Sharifloo, A. A.; Motazedi, Y.; Shamsfard, M.; and Dehkharghani, R., (2008), ''An Ontology for CMMI-ACQ Model, Information and Communication Technologies: From Theory to Applications'', IEEE, ICTTA 2008. 3rd International Conference, 7-11 April, p.p. 1–6, 978-1-4244-1752-0, Damascus. [60] Lee, C.-S.; Wang, M.-H.; and Chen, J.-J., (2008), ''Ontology-based intelligent decision support agent for CMMI project monitoring and control'', International Journal of Approximate Reasoning, vol. 48, p.p. 62–76. [61] Lee, C.-S.; and Wang, M.-H., (2009), ''Ontology-based computational intelligent multi-agent and its application to CMMI assessment'', Appl Intell, vol. 30, p.p. 203–219, DOI 10.1007/s10489-007-0071-1. [62] Pardo, C.; Pino, F. J.; García, F.; Piattini, M.; and Baldassarre, M. T., (2012), ''An ontology for the harmonization of multiple standards and models'', Computer Standards and Interfaces, vol. 34, p.p. 48–59. [63] Gazel, S., Sezer, E. and Tarhan, A., (2012), ''An Ontology Based Infrastructure to Support CMMI Based Software Process Assessment'', Gazi University, Journal of Science, vol. 25(1), p.p. 155-164. [64] Mejia, J.; Muñoz, E.; and Muñoz, M., (2016), "Reinforcing the applicability of multi-model environments for software process improvement using knowledge management", Science of Computer Programming vol. 121, pp. 3–15. [65] Sherman, S., (2009), ''A Process-Oriented Ontology for Representing Software Engineering Project Knowledge'', Ph.D. dissertation, Graduate School of Computer and Information Sciences, Nova Southeastern University, ProQuest LLC, USA. [66] Horridge, M., (2011), A Practical Guide to Building OWL Ontologies using Protégé 4 and CO-ODE Tools, ed. 1.3, The University Of Manchester. Available at [http://130.88.198.11/tutorials/protegeowltutorial/] [67] Pellet (2014) Available at [http://pellet.owldl.com/] last access 22/2/2014 [68] Gruber, T.R. (1995), ''Toward Principles for the Design of Ontologies for Knowledge Sharing'', International Journal of Human-Computer Studies, vol. 43(5-6), p.p. 907-928. [69] Halvorsen, C. P., and Conradi, R., (2002) "A Taxiomatic Attempt at Comparing SPI Frameworks", Springer Berlin / Heidelberg. [70] Soydan, G. H., and Kokar, M. M., (2010), "A Partial Formalization of the CMMI-DEV—A Capability Maturity Model for Development", Journal of Software Engineering and Applications, Vol 5, pp. 777-788.

[94]

Appendix (A) The Suggested Six Sigma Toolkits for the CMMI-Dev Process Areas

Appendix (A): The Six Sigma Tools for the CMMI Process Areas

Appendix (A) The Suggested Six Sigma Toolkits for the CMMIDev Process Areas This appendix contains the suggested Six Sigma statistical toolkits, templates, techniques and indicated metrics related to the process areas of the CMMI-Dev v1.3 model that recommended by the proposed SPI-CMMI framework. The process areas are organized in Alphabetical order. Causal Analysis and Resolution (CAR) – [ML5-Support Category] Six Sigma Tools  Regression Analysis  Design of Experiments  Activity Flow Diagram  Cause and Effect Diagram  Non-normal Data Analysis  Process Capability Analysis  Solution Prioritization Matrix  Cause and Prevention Diagram  Rolling Action Item Log (RAIL)  Box and whisker plots for attributes  Failure Modes and Effects Analysis (FMEA)  Cause/Effect Prioritization Matrix

Suggested Metrics              

Histogram Simulation Scatter Plot Run Charts Time Series Pareto Chart Brainstorming The five whys Control Charts Affinity Analysis Process Mapping Ishikawa Diagram Hypothesis Testing Process Flow Charts

 Non-conformances  Defect Density

Configuration Management (CM) - [ML2-Support Category]

    

Six Sigma Tools Run Charts  Time Series The checklist  Control charts The Critical-to-Quality (CTQ) The Pugh Concept Evaluation The Conjoint Analysis Technique

Suggested Metrics  Requirements Volatility

Decision Analysis and Resolution (DAR) - [ML3-Support Category] Six Sigma Tools  Affinity Analysis  Pugh Matrix Simulation  Solution Prioritization Matrix  Analytic Hierarchy Process (AHP)  Failure Modes and Effects Analysis

[95]

 Pareto Chart  Decision Tree  Brainstorming  Kano Analysis  House of Quality

Appendix (A): The Six Sigma Tools for the CMMI Process Areas Integrated Project Management (IPM) - [ML3-Project Management Category] Six Sigma Tools  Brainstorming  Control Charts  Process Mapping  Affinity Analysis  Check Point Sheets  Stakeholder Analysis  Measures and Statistics  Solution Prioritization Matrix  The Critical-to-Quality (CTQ)  Value and Non-Value Add Analysis  Quality Function Deployment (QFD)

 WBS  Checklists  Flowchart  SIPOC Tool  Project Map  Pareto Chart  Interviewing

Metrics  Process Compliance

Measurement and Analysis (MA) - [ML2-Support Category]

Six Sigma Tools  Affinity Analysis  Histograms  Traceability Matrix  Scatter Plot  Data Collection Plan  Pareto Chart  Cost Savings Calculations  Control Charts  Balanced ScoreCard (BSC)

Suggested Metrics  Measurement System Variation

Organizational Process Definition (OPD) - [ML3-Process Management Category] Six Sigma Tools  Process Maps  Process Flow Charts  Activity Network Diagram (AND)  Work Breakdown Structure (WBS)  Develop Standards and Procedures  Statistical process control (SPC) charts Organizational Process Focus (OPF) - [ML3-Process Management Category] Six Sigma Tools  Kaizen  Pareto Chart  Implementation Plan  The Critical-to-Quality (CTQ)  Quality Control Process Chart  Solution Prioritization Matrix

 Run Charts  Check Sheets  Control Charts

[96]

Metrics  Return On Investment (ROI)

Appendix (A): The Six Sigma Tools for the CMMI Process Areas Organizational Performance Management (OPM) [ML5-Process Management Category] Six Sigma Tools Cost/Benefit Analysis  simulation Critical-to-Quality (CTQ)  Control Charts Process Capability Analysis  Statistical Tools Solution Prioritization Matrix Failure Modes and Effects Analysis (FMEA)

    

Organizational Process Performance (OPP) [ML4-Process Management Category]

       

Six Sigma Tools Capability Analysis  Regression Analysis  Process Flow Charts  Prioritization Matrix  Data Collection Plan  Design of Experiments  Non-normal Data Analysis  Process Sigma Calculation 

Run Charts Scatter Plot Pareto Chart Control Plan Brainstorming Control Charts Queuing Theory Hypothesis Testing

Organizational Training (OT) - [ML3-Process Management Category] Six Sigma Tools  Histograms  Pareto Chart  Traceability Matrices  Develop Standards and Procedures

Suggested Metrics  Employee Satisfaction

Product Integration (PI) - [ML3-Engineering Category] Six Sigma Tools  Simulation  Process Maps  Traceability Matrices  Confirmation Checklists  Time Series; Run Charts

Suggested Metrics  Product Returns  Customer Complaints  Customer Satisfaction

Project Monitoring and Control (PMC) - [ML2-Project Management Category] Six Sigma Tools  5 Whys  Histograms  Control Plan  Multi-voting  Process Mapping

 WBS  SIPOC  Checklists  Run Charts  Time Series

[97]

Suggested Metrics  Earned Value  Schedule Variance

Appendix (A): The Six Sigma Tools for the CMMI Process Areas  Fishbone Diagram  Measures and Statistics  Confirmation Checklists  Capability Growth Models  Activity Network Diagram (AND)

 Gantt Charts  Pareto Chart  Swim Lanes  Control Chart  Brainstorming

Project Planning (PP) - [ML2-Project Management Category] Six Sigma Tools Suggested Metrics  Multi-voting  VOC  Estimation Accuracy  Gantt Charts  WBS  Schedule Performance  Transfer Plan  SIPOC  Brainstorming  Kaizen  Project Charter  Surveys  Affinity Analysis  Checklists  Process Mapping  Simulation  Workflow Diagrams  Cycle Time  Process Flow Charts  Swim Lanes  Stakeholder Analysis  Pareto Chart  Value and Non-Value  Interviewing Add Analysis Process and Product Quality Assurance (PPQA) - [ML2-Support Category] Six Sigma Tools  Sampling  Time Series  Run Charts  Process Maps  Histograms  Process Flows  Control Charts

Suggested Metrics  Process Compliance  Product Compliance

Quantitative Project Management (QPM) - [ML4-Project Management Category] Six Sigma Tools  Process Mapping  WBS  Affinity Analysis  SIPOC  Hypothesis Testing  Checklists  Statistical Analysis  Run Charts  Capability Analysis  Histograms  Process Flow Charts  Scatter Plot  Design of Experiments  Time Series  Cause and Effect Diagram  Pareto Chart  Capability Growth Models  Control Plan  Non-normal Data Analysis  Interviewing  Cause-and-Effect  Multi-voting Prioritization Matrix  Control Charts

[98]

Suggested Metrics  Earned value  Schedule Variance

Appendix (A): The Six Sigma Tools for the CMMI Process Areas Requirements Development (RD) - [ML3-Engineering Category] Six Sigma Tools  Interviewing  VOC  Brainstorming  QFD  CTQ Drilldown  5 Whys  Affinity Analysis  KJ Analysis  Process Mapping  Kano Analysis  House of Quality  Traceability Matrix  Conjoint Analysis  Stakeholder Analysis

Suggested Metrics  Requirements Change Controls  Requirements Volatility  Customer Satisfaction  Requirements Coverage

Requirements Management (REQM) - [ML2-Project Management Category] Six Sigma Tools  KJ Analysis  Kano Analysis  QFD Technique  House of Quality  Traceability Matrix  Critical-to-Quality (CTQ)

Suggested Metrics  Customer Satisfaction  Requirements Coverage  Requirements Volatility  Requirements Change Controls

Risk Management (RSKM) - [ML3-Project Management Category] Six Sigma Tools  Pareto Chart  WBS  Interviewing  FMEA  Brainstorming  Flowchart  Design FMEA  Checklists  Schuyler's Way  Simulation  Process Mapping  Scatter Plot  What IF Analysis  Multi-voting  Capability Analysis

Suggested Metrics  Risk Mitigation Effectiveness

Supplier Agreement Management (SAM) - [ML2-Project Management Category] Six Sigma Tools  Pugh Matrix  Check Sheets  Control Charts  Time Series; Run Charts  Analytic Hierarchy Process (AHP)

Suggested Metrics  Defect Density  Customer Satisfaction  Supplier Agreement Performance

Technical Solution (TS) - [ML3-Engineering Category] Six Sigma Tools  Analytic Hierarchy Process

[99]

 TRIZ

Appendix (A): The Six Sigma Tools for the CMMI Process Areas  Solution Prioritization Matrix  Robustness Performance Models  Variance and Tolerancing Models  Conceptual Modeling of Performance  Critical Adjustment Parameter Models  Manufacturing Process Variance Models  System, subsystem and subassembly transfer models of performance

 Simulation  Pugh Matrix  CTQ Drilldown  Mistake Proofing  Affinity Diagram  Concept Generation  Design of Experiments

Validation (VAL) - [ML3-Engineering Category] Six Sigma Tools

Metrics  Requirements Coverage

 SPC  Simulation  Setup Reduction  Traceability Matrices  Design of Experiments  Product Validation Plan/Piloting Verification (VER) - [ML3-Engineering Category]

         

Six Sigma Tools Affinity Analysis  Design of Experiments  Non-normal Data Analysis  Robustness Performance Models  Rolling Action Item Log (RAIL)  Defect Flow Models (DFM/ODC)  Variance and Tolerancing Models  Critical Adjustment Parameter  Models  Manufacturing Process Variance  Models  System, subsystem and subassembly  transfer models of performance  

SPC Scorecard Simulation Scatter Plot Time Series Run Charts Check Sheets Control Charts Setup Reduction Process Mapping Ishikawa Diagram Hypothesis Testing Process Flow Charts Regression Analysis

[100]

Metrics  Defect Density  Defect Removal Effectiveness  Phase Containment Effectiveness

Appendix (B) The Validation Questionnaire of The SPI-CMMI framework

Appendix (B): The Validation Questionnaire of The SPI-CMMI framework

Appendix (B) The Validation Questionnaire of the Proposed SPICMMI Framework The validation Questionnaire is designed to survey the views and opinions of specialists, quality and improvement experts as well as software companies' owners towards the proposed SPI-CMMI framework and to collect the information needed to identify the strengths and weaknesses of the model in order to improve it to suit the actual prerequisites of the software development industry. The validation questionnaire consists of a brief introduction and definition of the proposed SPI-CMMI framework, and a set of specific questions for each proposed phase, as well as some general and overall questions about the framework as an integral unit.

The Validation Questionnaire Phase1: Improvement Project Initiation Assessing the current status of the organization in terms of strengths and weaknesses and assign the teamwork for the beginning of the improvement project in the company using the proposed Six Sigma Approach. Q1. To what extent is the initial assessment phase of the current status in the company's important and necessary to determine the level of the company and guide the path and the starting point for the implementation of the improvement project? Q2. To what extent it is necessary to develop a clear and specific plan of action and a timetable for all activities and determine the appropriate action team to implement all phases and steps of the improvement project in the company from the beginning? Q3.To what extents are the proposed tools and techniques of Six Sigma Approach effective and necessary to facilitate the implementation of the initial assessment and evaluation stage? Phase2: Performance Management and Success Metrics Derivation Identifying metrics or measures for following and monitoring performance manage success and control the level of progress in the implementation of the improvement project in the company. Q4. The extent to which affect the development phase of declared and defined from the beginning to achieve the goals and determine the criteria and standards necessary to ensure that the proportion of the investigation over the implementation phases of the improvement project? Q5. The extent to which performance monitoring process continuing to evaluate specific steps and the results of the implementation of the improvement project and achieve the desired application in the interest of the company's standards affect? Q6. To what extent are the proposed tools and techniques of Six Sigma Approach effective and essential to facilitate the implementation phase to determine standards and criteria for monitoring and evaluating the performance of the improvement project?

[101]

Appendix (B): The Validation Questionnaire of The SPI-CMMI framework Phase3: Requirements Collection and Prioritization Aggregation of requirements from different perspective and determining the priorities for each requirement to determine the importance and influence in guiding the development project in the company using the QFD Technique. Q7. The extent to which the collation of the most multi-perspective different stage requirements are necessary to direct the course of the implementation of the improvement project in the company and to achieve better and faster results? Q8. To what extent it is necessary to arrange the requirements that have been collected from more than one perspective and give it the priority that are matching with the degree of importance and influence on the company? Q9. To what extent the proposed QFD technique is effective and necessary in the collation, integration, and arranging of the most multi-perspective based on the degree of requirements priority? Phase4: Process Areas (PAs) Prioritization Using QFD technique to determine priorities for the processes in the company to start the implementation of the development through the application of model CMMI-DEV. Q10. To what extent the prioritization process for the performance and the degree of implementation of important process areas will help in improving the speed and get better results from applying the improvement project in the company? Q11. To what extent the company concerned with the implementation of processes areas related to CMMI-DEV model according to the highest priority to meet its multiple requirements? Q12. To what extent the proposed QFD technique is effective and necessary in determining the starting point for the adoption of CMMI-DEV model through the selection of the process area with the highest priority and the most impact on the company's performance? Phase5: Specific Goal Prioritization For each prioritized PA, specific goals are prioritized based on those process requirements. Thus, the specific goals that achieve higher overall satisfaction of process requirements get higher importance. Q13. To what extent the prioritization process for performance and implementation of specific goals for each of the degree of importance of the process area will help improve the higher-speed access to the results of the application of the improvement project in the company? Q14. To what extent the company concerned with the implementation of specific goals and process areas related to CMMI-DEV model according to the highest priority to meet the multiple requirements? Q15. To what extent the QFD technique is effective and essential to prioritize specific goals for the process areas with the degree of significance highest in the company? Phase6: Specific Practices Prioritization This phase involves the prioritization of specific practices within all PAs of a specific maturity level (Staged CMMI) or within all PAs of a specific process category (Continuous CMMI). Q16. To what extent the company interested in executing the specific practices related to the specific goals for its process areas?

[102]

Appendix (B): The Validation Questionnaire of The SPI-CMMI framework Q17. To what extent the prioritization process of implementing the specific practices of specific goals related to the process areas with the highest importance will help in accelerating and enhancing the improvement project implementation? Q18. To what extent is the proposed QFD technique effective and necessary in determining priorities for the performance and implementation of specific practices and activities of specific goals for process areas with the highest degree of significance in the company? Phase7: Action Plans Derivation / Prioritization A set of actions is derived from the prioritized practices. The priorities of actions reflect the priorities of process requirements. By executing the actions with the highest priorities, the highest satisfaction level of process requirements can be achieved. Q19. To what extent the process of translating specific practices and goals for all the process areas in the CMMI-DEV model will lead to the ease understand and speed of implementation to meet the requirements for obtaining the levels of CMMI-DEV model? Q20. To what extent it is necessary to put the essential details and steps for executing all the actions and activities related to each process area in the CMMI-DEV model? Q21. To what extent the execution of the operations and activities with the highest priority and importance will affect the speed and quality to get the desired results of the improvement project in the company? Phase8: Action Plans/ Specific Practices Implementation Using the appropriate Six Sigma tools, methods, techniques and suggested metrics in applying the prioritized practices and action plans for each process area, in order to ensure much more successful implementation of the organization’s CMMI specific goals and practices in accurate and fast manner. Q22. To what extent is the process of determining the appropriate analytical techniques and tools considered one of the most important steps for the success of the performance and implementation of all activities and actions required to develop and improve the performance level and products of the software development companies? Q23. To what extent is the proposed tools and techniques of Six Sigma Approach considered effective and necessary to facilitate and improve efficiency and ensure the implementation of actions and activities related to each process area in the company departments as required by the CMMI-DEV model? Phase9: CMMI-DEV Capability Levels Interpretation Generic goals and practices for each capability level should be implemented to all of the process areas within CMMI. This phase includes suggested activities, actions and steps within the (DMAIC) methodology. Q24. To what extent the company concerned with achieving the highest Capability Level for each different process areas in accordance with the requirements for obtaining the levels of the CMMI-DEV quality model? Q25. To what extent it is necessary to convert the generic goals and practices related to each Capability Level into a range of actions and activities that are matching with the nature of the performance of the company to facilitate its understanding and implementation as required in the CMMI-DEV quality model? Phase10: Capability Levels Activities and Generic Practices Implementation

[103]

Appendix (B): The Validation Questionnaire of The SPI-CMMI framework Using the appropriate Six Sigma toolkits, techniques and metrics in applying the suggested activities and steps for each capability level, to ensure much more successful implementation of the organization’s CMMI generic goals/practices in precise and managed manner. Q26. To what extent are the proposed analytical tools and techniques of Six Sigma Approach effective and essential to facilitate and improve the implementation of actions and activities related to the generic goals and practices of each Capability Level for every process area in the company departments as required by the CMMI-DEV model quality? Q27. To what extent are the proposed successive phases in the development SPI-CMMI framework logical, necessary and can be implemented practically to develop and improve the performance level and products of the software development companies? Q28. To what extent the proposed SPI-CMMI framework will facilitate the implementation of the improvement project and enhance the performance and the products of the software development companies? Q29. To what level is the QFD technique appropriate and effective in collecting, and prioritizing various requirements and selecting the most important process area for improvement first? Q30. To what level is Six Sigma tools and QFD technique essential and effective to assist the organization in the adoption of CMMI-DEV model? Q31. To what level is the proposed SPI-CMMI model essential to maximize the customer satisfaction and business objectives? Q32. To what level will the proposed SPI-CMMI Framework help in translating the various requirements from several perspectives for software and process improvement in the software organization? Q33. To what level is the proposed Six Sigma tools and techniques will assist the organization in implementing specific goals/practices and generic goals/practices in CMMI-Dev? Integration Questions General and overall questions about the entire proposed SPI-CMMI framework as an integral unit. Q34. To what level are the proposed procedures significant to achieving the desired outcome of process and software improvement and enhancement? Q35. To what level is the sequence of the suggested phases and activities in the SPI-CMMI framework logical and imperative? Q36. To what level is the proposed SPI-CMMI framework contains all the steps and activities required to achieve the system and software improvement in the company? Q37. To what level will the proposed SPI-CMMI Framework facilitate the CMMI-DEV adoption for software and process improvement? Q38. To what level is the proposed SPI-CMMI model reduces the time and effort required to attain specific CMMI maturity level? Q39. To what level will you apply the proposed SPI-CMMI Framework in your company? Q40. Which phases from the proposed SPI-CMMI framework are actually applied in your company for the improvement project? Q41. What is the expected time needed for the actual implementation of the proposed SPICMMI framework in order to have results? Q42. What are the drawbacks of the proposed SPI-CMMI framework? Q43. What are the recommendations for enhancing the performance and results of the proposed SPI-CMMI framework in order to have results? [104]

‫جـامعة الزقـازيـق‬ ‫كلية الحاسـبات والمعلومـات‬ ‫قسـم نظم المعلومـات‬

‫حتسني قدرات مناذج تطوير البـرمـجيات‬ ‫رسالـة مقدمة إلـي‬ ‫كلـية الحـاسبات والمعلومـات ـ جامعة الزقازيق‬ ‫كجزء من متطلبات الحصول علي درجة دكتوراة الفلسفةفي نظم المعلومات‬

‫إعــداد‬

‫الـشـيـمـ اء عـ ـادل طـنـ طـاوي عـبـ ده‬ ‫مدرس مساعد بقسم نظم المعلومات‬

‫كلية الحاسبات والمعلومات ـ ـ جامعة الزقـازيق‬ ‫لجنة اإلشـراف‪:‬‬

‫أ‪.‬د‪ /‬عبد الناصر حسني زايد‬

‫أستاذ نظم المعلومات‬ ‫عميد كلية الحاسبات والمعلومات‬

‫أ‪.‬د‪ /‬خالـد عـلي الدرنديل‬

‫أستاذ نظم المعلومات‬ ‫وكيل الكلية لشئون التعليم والطالب‬ ‫المدير التنفيذي لمركز المعلومات‬

‫قسم نظم المعلومات‬ ‫كلية الحاسبات والمعلومات ـــ جامعة الزقازيق‬ ‫جمهورية مصر العربية‬

‫(‪)2017‬‬

‫‪‬‬

‫‪‬قُـلْ إِنَّ صَـالَتِي وَنُـسُكِي وَمَـحْيَايَ وَمَـمَاتِـي لِـلّهِ‬ ‫رَبِّ الْعَالَـمِـنيَ{‪ }162‬الَ شَـرِيكَ لَهُ وَبِـذَلِكَ أُمِـرْتُ وَأنَـاْ‬ ‫أَوَّلُ الْمُسْلِمِنيَ{‪}163‬‬ ‫(سورة األنعام‪ :‬اآلية ‪)162:163‬‬

‫‪‬‬

‫الملخص العربي‬

‫حتسني قدرات منـاذج تطوير الربمـجيات‬ ‫املـلـخـص الـعـربـي‬ ‫الخلفية والدوافع‪:‬‬ ‫لقد أصبحت البرمجيات مورد حيوي لمعظم الصناعات والتطبيقات في كافة المجاالت‪ ،‬ولذلك فإن التأكد من‬

‫جودة وكفاءة هذه البرمجيات أصبح مطلب رئيسي‪ ،‬ولهذا السبب فإن شركات صناعة البرمجيات تسعي‬

‫لتحسين جودة البرمجيات وتحقيق أعلي مستوي من الكفاءة‪ ،‬حيث أن التكاليف المرتبطة بنقص الجودة‬ ‫يمكن ببساطة أن تضع منظمة صناعة البرمجيات خارج نطاق العمل‪ .‬ولذا فإن الحاجة إلى ضمان‬

‫مستويات عالية من كفاءة وجودة البرمجيات تحفز المنظمات على اعتماد منهجية تطوير لتحسين عمليات‬

‫إنتاج البرمجيات الخاصة بها‪ ،‬وهو ما يسمي نماذج تطوير البرمجيات‪.‬‬

‫هناك العديد من نماذج وأساليب تحسين البرمجيات المختلفة المتاحة عالميا‪ ،‬لكل منها خصائص وسمات‬

‫معينة وكذلك أيضا المميزات والعيوب المرتبطة بكل نموذج‪ ،‬كما أن لكل شركة احتياجات ومتطلبات خاصة‬

‫بها وظروف وقوانين تعمل بناء عليها وكذلك متطلبات العمالء الذين تتعامل معهم‪ ،‬باإلضافة إلي طبيعة‬

‫اإلدراة ومتخذي القرار والمسئولين وأسلوب العمل في المنشأة؛ ومن ثم فإن كل هذه العوامل تتداخل معا في‬ ‫عملية اختيار وتطبيق أي من هذه النماذج المتاحة‪ .‬ولذلك تعتبر عملية اختيار وتطبيق أحد هذه النماذج‬

‫في شركات البرمجيات من العمليات الصعبة والمعقدة والمكلفة ماليا باإلضافة إلي الوقت الطويل الذي‬

‫تتطلبه عملية التطبيق‪.‬‬

‫وقد تم اختيار نموذج التحسين (‪ )CMMI‬في العديد من شركات إنتاج البرمجيات؛ بغرض تحسين وتطوير‬ ‫عمليااات إنتاااج البرمجيااات والحصااول علااي االعتماااد بأحااد مسااتويات هااذا النمااوذج‪ ،‬حيااث أنااه يعاد واحااد ماان‬ ‫انتشار‪ ،‬واستخداما‪ ،‬ومعترف به عالمياا‪ .‬وجادير بالاذكر أن نماوذج ‪ CMMI‬يصانف‬ ‫ا‬ ‫نماذج التحسين األكثر‬

‫ض اامن النما ااذج ذات الطبيع ااة المعياريا ااة النظري ااة‪ ،‬الت ااي تح اادد فقا ااط المتطلب ااات أو توص ااي بمجموع ااة ما اان‬ ‫الممارسات النظرية التاي يجاب توافرهاا فاي شاركات البرمجياات دون تاوفير اياة إجاراءات عملياة لتحدياد كياف‬

‫تاتم عمليااة التحساين والتطااوير فعلياا‪ .‬ممااا يعناي أن نمااوذج ‪ CMMI‬يعارف ممااا يجاب القيااام باهم ولكاان يتارك‬ ‫مكيف‪/‬لمااذا نفعال ذلاكم للمنظماات‪ .‬فاي حاين أن هناااك نمااذج تحساين أخاري لاديها منهجياات تحليلياة ماازودة‬ ‫باااألدوات والتقنيااات الالزمااة لتنفيااذ عمليااة التطااوير؛ وبالتااالي فماان الضاروري أن يكااون هناااك منهجياة تطااوير‬

‫عملياة محاددة بطريقااة علمياة تساتند إلااي إجاراءات تحليلياة ماان أجال توجياه ومساااعدة شاركات البرمجياات فااي‬ ‫تسهيل رحلة التحسين والتطوير وخاصة التي تود تبني نموذج ‪.CMMI‬‬ ‫‪1‬‬


‫ولذلك‪ ،‬فإن االتجاه الحديث في تحسين شركات البرمجيات هو دمج أكثر من نموذج تحسين في بيئة‬ ‫تنظيمية واحدة‪ ،‬وخلق ما يسمي بيئات متعددة النماذج (‪ )Multi-Model Environment‬حيث يمكن أن‬ ‫تكون هناك حاالت مختلفة يكون فيها من الضروري استخدام وتطبيق أكثر من نموذج تطوير معا كال‬

‫منهما يكمل النقص في اآلخر‪ ،‬كما هو الحال في هذا البحث الذي يهدف إلى االستفادة من بيئة النماذج‬

‫المتعددة ضمن عملية تطوير شركات البرمجيات من خالل دمج نماذج التحسين النظرية مع النماذج العملية‬

‫التحليلية من أجل الحصول على منهجية تطوير متكاملة يتم تنفيذها في منظمات البرمجيات بشكل أكثر‬ ‫فعالية ودقة‪ ،‬وذلك بهدف تحسين قدرات نماذج جودة البرمجيات وتسهيل عملية تطبيقها وتنفيذها عمليا‪.‬‬

‫في هذه األطروحة تم اختيار نموذج (‪ )CMMI-Dev v1.3‬لتعزيزه وتحسين قدراته من خالل اقتراح‬

‫تنفيذه ضمن منهجية التحسين العملي المتكاملة التي تقوم على دمج نهج ‪( Six Sigma‬أدوات تحليلية‪،‬‬ ‫تقنيات عملية ومنهجية ‪ )DMAIC‬وتقنية ‪ QFD‬مع ‪ .CMMI‬وتساعد المنهجية المقترحة على‬

‫تحسين وتطوير عمليات المنظمة المتعددة باإلضافة إلى تسهيل عملية االعتماد من قبل نموذج‬ ‫‪ ،CMMI‬وبالتالي تسمي ‪.The proposed SPI-CMMI framework‬‬

‫أهـداف البحـث‪:‬‬ ‫لتحسين قدرات نموذج ‪ ،CMMI‬تقترح هذه األطروحة منهجية تحسين عملية تحليلية تنفذ على وجه‬ ‫التحديد داخل مؤسسات البرمجيات التي تهدف إلى الحصول علي االعتماد ألحد مستويات التطوير‬

‫الخاصة بنموذج الجودة ‪ .CMMI-Dev‬توفر المنهجية المقترحة األنشطة والمهام وخطة العمل التي‬

‫يتعين القيام بها‪ ،‬باإلضافة إلى مجموعات األدوات التحليلية الموصى بها‪ ،‬والتقنيات العملية المرشحة‬

‫التي سيتم تنفيذها بقدر االمكان في تطوير عمليات المنظمة المتعددة من أجل تحقيق التحسين المطلوب‬ ‫ورفع مستوي األداء وتهيئة المنظمة للحصول علي اعتماد ‪ CMMI‬بنجاح أكبر وفعالية‪.‬‬

‫األهداف التالية تمثل مجال البحث‪:‬‬ ‫‪ .1‬دراسة وتحسين قدرات نموذج الجودة ‪.CMMI‬‬ ‫‪ .2‬اقتا اراح منهجي ااة تط ااوير متكامل ااة تس اااعد ش ااركات البرمجي ااات لتحس ااين مس ااتوي األداء والتهيئ ااة‬ ‫للحصول علي االعتماد من قبل نموذج الجودة ‪.CMMI‬‬

‫‪ .3‬بنااء نساخة حاساوبية مان ‪ The proposed SPI-CMMI framework‬لتمثيال ماا بهاا مان‬

‫معلوما ااات ومعرفا ااة وسا ااهولة االسا ااتخدام واالسا ااتعالم دوامكانيا ااة الا اادمج باسا ااتخدام تقنيا ااة هندسا ااة‬

‫‪ Ontology‬ولغتها المستخدمة ‪.OWL‬‬

‫‪2‬‬


‫‪ .4‬تطبيق منهجياة التطاوير المقترحاة ‪ The proposed SPI-CMMI framework‬علاي حالاة‬ ‫دراسية للتأكد من صحتها وصالحيتها لالستخدام‪.‬‬

‫محتويـات الرسالـة‬ ‫تحتوي الرسالة علي ستة فصول هي كالتالي‪ :‬المقدمة‪ ،‬االستعراض المرجعي واألساس العلمي باإلضافة‬ ‫إلاي الشارح التفصايلي لمنهجياة التطاوير المقترحاة ‪ The proposed SPI-CMMI framework‬بماا‬

‫تحتوي ااه م اان م ارح اال وخطا اوات وتقني ااات عملي ااة وأدوات تحليلي ااة موص ااي به ااا‪ ،‬ث اام مقارن ااة ه ااذه المنهجي ااة‬ ‫بمثيالتها بناء علي مجموعة من المعايير‪ ،‬بناء نسخة حاساوبية لهاا باساتخدام تقنياة هندساة ‪Ontology‬‬

‫ولغتهااا المسااتخدمة ‪ .OWL‬ثاام مراجعااة المنهجيااة وتطبيقهااا علااي حالااة د ارسااية فعليااة للتأكااد ماان صااحة‬ ‫بنائها وتصميمها وصالحيتها لالستخدام من قبل شركات البرمجيات‪ ،‬نهاياة بالخالصاة والتوصايات‪ .‬هاذا‬

‫إلااي جانااب ملخااص الرسااالة باااللغتين العربيااة واإلنجليزيااة‪ ،‬باإلضااافة إلااي قائمااة الم ارجااع المسااتخدمة فااي‬

‫إتمام هذا البحث‪ ،‬ملحق (أ) و(ب) وفيما يلي الوصف الملخص لمحتويات فصول الرسالة‪:‬‬

‫الفصـل األول‪Introduction :‬‬ ‫يباادأ هااذا الفصاال بمقدمااة للد ارسااة توضااح بصااورة عامااة موضااوم البحااث‪ ،‬وفيااه تاام عاارض أهميااة موضااوم‬

‫الرسااالة‪ ،‬وقااد تاام عاارض أهاام األهااداف والاادوافع إلج اراء الد ارسااة‪ ،‬باإلضااافة إلااي المنهجيااة المتبعااة فااي إج اراء‬

‫البحث للوصول إلي النتائج‪ ،‬ثم سرد ملخص لمحتويات وهيكل الرسالة‪.‬‬

‫الفصـل الثاني‪:‬‬

‫‪Literature Survey and Technical Background‬‬

‫يناقش هذا الفصل الحالة الراهنة لعملية تحسين وتطوير البرمجيات‪ ،‬والنماذج والتقنيات المتعددة المساتخدمة‬

‫فااي هااذا المجااال‪ .‬كمااا يتناااول الفصاال شاارح بعااض المفاااهيم األساسااية المسااتخدمة فااي هااذا البحااث مثاال‪ :‬بيئااة‬ ‫النماااذج المتعااددة المدمجااة معااا‪ ،‬أسااباب ظهورهااا وأهميتهااا؛ نمااوذج التحسااين (‪ ،)CMMI‬مستعرضااا تاريخااه‬ ‫وتكوينااه وتصااميمه‪ ،‬كمااا يوضااح أسااباب اختياااره كموضااوم للبحااث والنقااد الااذي وجااه إلي ه ‪ ،‬ه نههه( ( ‪Six‬‬

‫‪ )Sigma‬تاريخه ووصف ملخص له ومنهجية (‪ ،)DMAIC‬تقنية (‪ )QFD‬وما هي أهميتها‪ ،‬باإلضافة إلى‬ ‫هندس ااة (‪ )Ontology‬التعري ااف والمكون ااات واللغ ااات المس ااتخدمة ف ااي التطبي ااق‪ .‬وكا اذلك يس ااتعرض الفص اال‬ ‫األبحاث السابقة المتعلقة بموضوم الدراسة‪.‬‬

‫الفصـل الـثالــث‪The Proposed SPI-CMMI Framework :‬‬ ‫يعارض هااذا الفصاال وصاافا تفصاايليا دقيااق لمنهجيااة التطاوير المتكاملااة المقترحااة فااي هااذا البحااث لشااركات‬

‫البرمجيااات ‪ .The proposed SPI-CMMI framework‬المنهجيااة المقترحااة تتكااون ماان عش ارة‬ ‫‪3‬‬


‫مراحل متتالية مرتبة طبقا للتسلسل المنطقي لعملياات التطاوير والتحساين‪ .‬كال مرحلاة مقسامة إلاي سلسالة‬ ‫من األنشطة والمهام المتتابعة مزودة بشرح تفصيلي عن كيفية التنفيذ‪ ،‬باإلضافة إلي إدراج مجموعة مان‬

‫األدوات العملياة والتقنياات التحليلاة الموصاي بهاا مان نهاج ‪( Six Sigma‬أدوات تحليلياة‪ ،‬تقنياات عملياة‬

‫ومنهجية ‪ )DMAIC‬وتقنية ‪ ) QFD‬لتجميع االحتياجات والمتطلبات األساسية لعملية التطاوير وترتيبهاا‬

‫طبقااا لدرجااة األهميااة التااي تمثلهااا وتااؤثر بهااا علااي مسااتوي األداء) لتنفيااذ مشااروم التطااوير بطريقااة دقيقااة‬

‫وفعالة والتهيئة للحصول علي االعتماد من قبل نموذج الجودة ‪.CMMI‬‬ ‫الفصـل الـرابع‪The Ontology Representation of the SPI-CMMI Framework :‬‬ ‫يص ااف ه ااذا الفص اال كيفي ااة اس ااتخدام هندس ااة ‪ Ontology‬م ااع لغ ااة ‪ OWL‬م اان أج اال بن اااء نس ااخة حاس ااوبية‬ ‫لمنهجيااة التطااوير المقترحااة فااي هااذا البحااث متضاامنة الم ارحاال واألنشااطة والمهااام ذات الصاالة وأدوات ‪Six‬‬

‫‪ Sigma‬وتقنية ‪ QFD‬الموصى بها وتمثيل نموذج التحسين ‪ .CMMI-Dev‬يبدأ الفصل بمقدمة ثم شارح‬ ‫تفصاايلي للغااة المسااتخدمة فااي بناااء النمااوذج‪ ،‬يلااي ذلااك وصااف تصااميم الهيكاال المسااتخدم فااي بناااء النمااوذج‬

‫الحاسااوبي؛ طريقااة تحديااد أسااماء المفاااهيم والعالقااات المختلفااة التااي ت اربط فيمااا بياانهم والمكونااات المتعااددة‬ ‫الموجااودة فااي النمااوذج الحاسااوبي‪ .‬كمااا يعاارض الفصاال الخصااائص المتمثلااة فااي النمااوذج الحاسااوبي لتمثياال‬ ‫منهجيااة التطااوير‪ .‬تناااول الفصاال أيضااا شاارح معااايير التصااميم المسااتخدمة فااي بناااء هااذا النمااوذج وكيااف تاام‬ ‫تطبيقها فعليا‪ .‬ينتهي هاذا الفصال بعارض مختصار ألهمياة وفائادة هاذا النماوذج الحاساوبي لمنهجياة التطاوير‬

‫وكيفية استخدامه لتمثيل وعرض واستعالم المعرفة الممثلة به من قبل شاركات البرمجياات واألبحااث األخاري‬

‫التي يمكنها االستفادة منه والدمج معه بأنظمة أخري مشابهة أو مكملة له في نفس المجال‪.‬‬

‫الفصـل الخـامـس‪The SPI-CMMI Framework Validation and Implementation :‬‬

‫يقدم الفصل دراسة مقارنة لمنهجية التطوير المقترحاة ماع النمااذج األخاري الساابقة وذلاك بنااء علاي مجموعاة‬ ‫ماان المعااايير والخصااائص المحااددة طبقااا لطبيعااة مجااال الد ارسااة واحتياجااات شااركات البرمجيااات ومواصاافات‬

‫نموذج الجودة ‪ CMMI‬بهدف إبراز أهم اإلضافات والمميزات التي تحتويها هذه المنهجية‪.‬‬

‫كما يتناول الفصل مراجعة المنهجية المقترحة وتقييمها من قبل خبراء الجودة والمراجعين والمتخصصاين فاي‬ ‫نموذج ‪ CMMI‬في مركز تقييم واعتماد هندسة البرمجيات التابع لاو ازرة االتصااالت وتكنولوجياا المعلوماات‬

‫(‪ ،)Software Engineering Competence Center- SECC‬وذلااك ماان خااالل تجميااع اآلراء‬ ‫والمقترحات تجاه هذه المنهجية المسجلة في إجابات االستبيان المصمم في البحث لهذا الغرض‪.‬‬

‫باإلض ااافة إل ااي تطبي ااق منهجي ااة التط ااوير المقترح ااة عل ااي حال ااة د ارس ااية متمثل ااة ف ااي مرك ااز تقني ااة المعلوم ااات‬

‫واالتص اااالت (‪ )CITC‬بجامع ااة الزق ااازيق حي ااث يص ااف ه ااذا الفص اال تفص اايليا الخطا اوات المتبع ااة لتطبي ااق‬ ‫‪4‬‬


‫المنهجية المقترحة لتحسين وتطوير شركات البرمجيات التي تسعي للحصول علاي االعتمااد مان قبال نماوذج‬

‫‪ CMMI‬للتأكد من صالحيتها ومدي الفاعلية وصحة النتائج ودقتها‪.‬‬

‫وق ااد تاام اختيااار ه ااذا المركااز كحالااة د ارسااية ألنااه يعااد بمثابااة منظمااة إلنتاااج البرمجيااات الخاصااة بالجامعااة‬ ‫ومختلف الكليات‪ ،‬علي سبيل المثال؛ برامج اإلمتحانات وأعمال الكنتروالت ونتائج طالب الجامعة ‪ ...‬إلا‪،،‬‬

‫كمااا أن مركااز ‪ CITC‬مسااجل حاليااا ويسااعي للحصااول علااي اعتماااد مست ااوي ج ااودة ماان قباال نمااوذج الجااودة‬

‫(‪ .)CMMI‬باإلضااافة إلااي أنااه طبقااا لطبيعااة ونظااام العماال داخاال المركااز فهناااك أوقااات ذروة شااديدة للعماال‬ ‫داخل المركز وذلك خالل فترات االمتحاناات دواعاالن النتاائج للكلياات المتعاددة فاي الجامعاة وتقاديم الخادمات‬ ‫المختلفااة للطلبااة ‪ -‬ولااذلك فهناااك احتياااج قااوي لتحديااد أولويااات العماال داخاال المركااز وهااذا مااا تقدمااه الم ارحاال‬ ‫المتتالية ضمن المنهجية المقترحة في الرسالة‪ .‬كما أن مركز ‪ CITC‬يعتبر الجهة الوحيدة التي وافقات علاي‬

‫إجا اراء التطبي ااق العمل ااي له ااذا النم ااوذج المقت اارح ل ااديها‪ .‬وج اااءت نتيج ااة التطبي ااق المص ااغر لمنهجي ااة التط ااوير‬

‫المقترحااة فااي هااذا البحااث فعالااة وذات تااأثيرات إيجابيااة مشااجعة لشااركات البرمجيااات لتبنااي تطبيقهااا وتنفيااذها‬

‫إلحداث مستوي التطوير والتحسين المطلوب وتسهيل عملية الحصول علي االعتماد من قبال نماوذج الجاودة‬

‫(‪.)CMMI‬‬

‫الفصل السادس‪Conclusion, Future work and Recommendations :‬‬ ‫يقاادم هااذا الفصاال ملخصااا للرسااالة محتويااا علااي أهاام النقاااط التااي تناولهااا البحااث بالد ارسااة والتحلياال‬ ‫واألهااداف المرجااو تحقيقهااا والوصااول إليهااا ماان هااذه الرسااالة وكااذلك أهاام التوصاايات والنتااائج التااي‬

‫حققهااا البحااث‪ ،‬مااع ساارد أهاام الموضااوعات المقترحااة للد ارسااات المسااتقبلية واسااتكمال العماال فااي هااذه‬

‫النقطة من مجال نماذج جودة وتحسين صناعة البرمجيات‪.‬‬

‫وف ااي نهاي ااة الرس ااالة ت اام ع اارض الم ارج ااع المس ااتخدمة والت ااي تبل ااي حا اوالي (‪ )69‬مرج ااع مرتب ااة طبق ااا‬ ‫لوردوها في سياق البحث وموزعة علي أعوام تبدأ من عام ‪ 1995‬ونهاية بعام ‪2017‬م‪.‬‬

‫مدرج أيضا ضمن محتويات الرسالة عدد ‪ 2‬ملحق إضافي (أ) و(ب)‪ ،‬كما يلي‪:‬‬

‫ملحق (أ)‪:‬‬ ‫يحتوي هذا الملحق على مجموعة أدوات ‪ Six Sigma‬اإلحصائية والتقنيات التحليلية والمقاييس‬

‫المقترحة بالنسبة لتنفيذ كافة العمليات والممارسات النظرية ضمن نموذج ‪ CMMI‬التي ستساهم‬ ‫في تسهيل عملية تبني وتطبيق نموذج ‪ CMMI‬في شركات البرمجيات من أجل تحسين قدراته‪،‬‬ ‫وتنفيذ مشروم التطوير بشكل دقيق وفعال‪.‬‬

‫‪5‬‬


‫ملحق (ب)‪:‬‬ ‫يقدم هذا الملحق االستبيان المصمم الستكشاف واستطالم اراء المتخصصين في الجودة وخبراء‬ ‫التحسين وكذلك أصحاب شركات البرمجيات تجاه منهجية التطوير المقترحة في البحث وجمع‬ ‫المعلومات الالزمة لتحديد نقاط القوة والضعف في النموذج من أجل تحسينه ليتناسب مع‬

‫المتطلبات األساسية الفعلية لتطوير شركات البرمجيات‪ .‬االستبيان يقسم إلي مجموعة من األسئلة‬

‫الخاصة بكل مرحلة من المراحل المقترحة في منهجية التطوير ثم مجموعة أسئلة خاصة لتقييم‬ ‫المنهجية كوحدة متكاملة بكل ما يحتويه لتحسين وتطوير شركات البرمجيات التي تسعي لالعتماد‬

‫من قبل ‪.CMMI‬‬

‫النتائج والتوصيات‬ ‫‪ .1‬تحسااين قاادرات نم اوذج الجااودة ‪ CMMI‬ماان خااالل إضااافة األج ازاء العمليااة التحليليااة الضاارورية التااي‬ ‫تنقصه حيث أنه يحتوي فقط مجموعة الممارسات النظرياة‪ ،‬وذلاك مان خاالل الادمج بيناه و باين مانهج‬

‫‪ Six Sigma‬وتقنية ‪.QFD‬‬

‫‪ .2‬اقت اراح منهجيااة تطااوير متكاملااة لشااركات البرمجيااات (ماازودة بالممارسااات النظريااة مااع كيفيااة تطبيقهااا‬ ‫عملياا بااالطرق واألدوات الالزمااة) ماان أجاال تنفياذ مشااروم التحسااين بطريقااة دقيقااة وفعالااة والتهيئااة‬ ‫للحصول علي االعتماد من قبل نموذج ‪.CMMI‬‬

‫‪ .3‬عماال د ارسااة مقارنااة لمنهجيااة التطااوير المقترحااة مااع النماااذج السااابقة بناااء علااي مجموعااة ماان المعااايير‬ ‫المحااددة طبقااا لطبيعااة المجااال واحتياجااات شااركات البرمجيااات ومواصاافات نمااوذج الجااودة ‪CMMI‬‬ ‫بهدف إبراز أهم اإلضافات والمميزات التي تحتويها المنهجية المقترحة‪.‬‬

‫‪ .4‬بناء نسخة حاسوبية من ‪ The proposed SPI-CMMI framework‬لتمثيل ما بها من معلومات‬

‫ومعرفااة‪ ،‬وسااهولة االس ااتخدام واالسااتعالم دوامكانيااة ال اادمج مااع أنظمااة أخ ااري مماثلااة باسااتخدام تقني ااة‬

‫هندسة ‪ Ontology‬ولغتها المستخدمة ‪.OWL‬‬

‫‪ .5‬مراجعااة منهجيااة التطااوير المقترحااة ماان قباال الخب اراء والمتخصصااين فااي الجااودة وتحسااين البرمجيااات‬ ‫واعتم اااد نما اوذج ‪ CMMI‬ف ااي مرك ااز تقي اايم واعتم اااد هندس ااة البرمجي ااات ‪ SECC‬م اان خ ااالل تجمي ااع‬ ‫اإلجابات الخاصة باستبيان اختبار الصالحية‪.‬‬

‫‪ .6‬باإلض ااافة إل ااي تطبي ااق المنهجي ااة المقترح ااة عل ااي حال ااة د ارس ااية حقيقي ااة مص ااغرة للتأك ااد م اان ص ااحتها‬ ‫وصااالحيتها لالسااتخدام فااي شااركات البرمجيااات وتحديااد ماادر قاادرتها علااى تحقيااق مسااتور األداء‬

‫المقبول والتطبيق علي النطاق األوسع واألشمل‪.‬‬

‫‪ .7‬تحديد بعض الموضوعات الدراسية المستقبلية الستكمال البحث في هذه النقطة من مجال‬ ‫نماذج تحسين البرمجيات‪.‬‬

‫‪6‬‬