Incomplete Requirements And Specifications

Published Date: 02 Nov 2017

CHAPTER ONE

INTRODUCTION

1.1 OVERVIEW

Industries like Construction and manufacturing have been widely known to be delivering (most of the time) on budget and on time and with proper quality. On other hand we frequently see projects out of budget with cost and time overruns and rarely meets the customer expectations of quality. Standish Group in its Chaos report (Standish, 1994) reported the following percentages for failures in software industry:

1. Lack of User Input (12.8%)

2. Incomplete Requirements & Specifications (12.3%)

3. Changing Requirements & Specifications (11.8%)

4. Lack of Executive Support (7.5%)

5. Technology Incompetence (7.0%)

6. Lack of Resources (6.4%)

7. Unrealistic Expectations (5.9%)

8. Unclear Objectives (5.3%)

9. Unrealistic Time Frames (4.3%)

10. New Technology (3.7%)

11. Other (23.0%)

Only two of the top 10 reasons for failure are related to the technical capability, all the rest are directly related to management which raised the importance of software process improvement as a way to overcome all these management problems affecting the success of software projects

This has lead to emphasis from several entities world wide to either implement their own initiatives or develop models or standards to be sued by others. Efforts have been dedicated by entities like IEEE and others to publicize their models and try to improve the situation but one of the most successful projects was the CMMI or the Capability Maturity Model Integration. CMMI has been developed and spread by the Software Engineering Institute (SEI) and started as a project by the Department of Defense to improve quality of the contractors and to be able to manage the contracts for a higher success rates.

CMMI managed to revive quality initiatives in the industry and succeeded in grabbing attention to new forces in software industry (especially those in outsourcing business). Companies in Egypt, Ireland and before them in India succeeded in being appraised for CMMI and many of these companies have now high maturity levels. This showed their quality and helped them in getting outsourcing contracts and created interest in CMMI world wide. This interest encouraged SEI to gather comments from over the world which lead to more successful versions and more world wide adoption

In order to achieve CMMI, companies need to invest time; money and effort to gain the knowledge needed and apply this knowledge on their existing business. CMMI due to its nature as Software Process Improvement methodology it needs to be adopted wisely because it needs acceptance by people and support by management otherwise will be considered as overhead to and a waste of time. This has created complexity in implementing the CMMI model in many organizations

This complexity needs to be understood by management and by practitioners, this research is an attempt to layout a framework for understanding the CMMI Implementation Dynamics from a knowledge and management perspectives.

1.2 PROBLEM STATEMENT

Software Process Improvement projects conducted to implement CMMI model showed complexity of implementation due to soft factors related to management commitment, employee commitment, knowledge of employees, �.etc. Transforming a company from a static state without established process into a dynamic state through implementing CMMI L2 Process Areas is a complex process (achieving higher maturity levels would be easier because if CMMI L 2 is adopted first it will lay down the way to the next phases) that needs to take feedback effects into consideration. Failure to understand this complexity by the traditional linear thinking leads to a high probability of failure

1.3 RESEARCH OBJECTIVES

The overall aim of this research is to contribute to the efforts made to ease preparation for CMMI L2 in software firms through allowing self assessment method and deeper understand of the CMMI implementation dynamics. This may lead to more successful and smooth transition of software organizations into the CMMI L2 state. This could be achieved through appreciation of the different organizational factors and their impact of the success of the project.

1.4 CONCEPTUAL FRAMEWORK

The conceptual framework developed in this research is targeting to model the most effective factors that interact to provide overall process effectiveness that achieves in return the required CMMI L2, this is based on the CMMI model, system thinking methodology and dynamic modeling

Dependent Variable

Average Process Effectiveness: This represents the current state of company process effectiveness during the course of implementation of the CMMI model

Independent Variables

Independent variables are those variables that could be affecting the management commitment like competition, shareholder pressure, cost pressure, customer satisfaction which in turn has its impact on overall process adoption and improvement. Independent variables like networking, team work, corporate culture,�etc also have their own impact on the final process effectiveness

Complete list of Independent is shown in Fig 1.1

Fig 1.1 Independent Variables

As shown in Fig 3.2, there are 35 independent variables controlling the model through 5 main dynamic variables to realize the Process Effectiveness Gap

Research Assumptions

Average Process Effectiveness: It is assumed to be reflecting how close the company is from adopting CMMI Level 2

Research Limitations

The final developed dynamic model needs to be adapted to each organization to reflect the individual characteristics that distinguish one organization from another but the cause and effect relations are still valid on all situations

1.5 RESEARCH QUESTIONS

Major Research Questions

1) What factors could make a company transform into CMMI L2 Company? What elements make up the best policy?

2) What are the cause-effect relationships that exist between different policy elements? How to identify such relationships and their feedback effects?

3) What is the most influential part(s) of the policy that policy markers should focus their efforts on? How could the effect of its elements be tested prior to policy application?

Minor Research Questions

1) To What extent do competition, customer satisfaction, government funding (for CMMI) affect the dynamism of implementing CMMI L2 inside organization? What is its effect on other related variables?

2) What is the effect of special input factors (such as Shareholder pressure, strategic intent, for example)? What is its effect on other related variables? How would Knowledge transfer affect company success in adopting L2 CMMI?

3)What is the effect of throughput goals on the project dynamics? What is its effect on other related variables to what extend would collective actions affect it?

1.6 RESEARCH METHODOLOGY

This research is considered to be of the analytical type and qualitative. Since we are applying this research to CMMI Implementations using cause and effect relationship then research is applied and of deductive type.

1.7 THESIS STRUCTURE

Chapter 3 introduces the variables being studied as independent and dependent and the research questions as well as the method adopted to meet the research objectives

Chapter 4 introduces the causal loop variables, their description, cause and effect, the different interactions between the different variables, the different interacting loops that govern the system behavior

Chapter 5 introduces the stock and flow diagram and simulation results answering the research questions as well as the future research work and conclusions

All work in Chapter 4 and 5 are based on system thinking and system dynamics presented in (Sterman, 2000) and (Maani, 2000)

CHAPTER TWO

LITERATURE REVIEW

2.1 OVERVIEW

The phenomenal growth of software industry over the past 35 years has spread throughout all industries. All Consumers now are almost exposed on daily basis to products or services that are using software as integral part of their architecture. The examples are enormous and are related to everyday life such as mobile phones, video recorders, cars, washing machines�.etc.

Due to this spreading through all industries, the demand has increased for complex, flexible and stable software and to get this delivered cheaply, on time and with the highest quality. These demands have created challenges in management of software firms competing to fulfill customer demands and needs

Research efforts have been made to provide software firms with tools, methodologies and models to help them in managing software development to satisfy the evolving needs(Madachy,2000), (SEI,2006), (SEI,2007). Major category of these efforts is under what we call Software Process Improvement (SPI); Software Process Improvement is the identification of the current practices of software development within a firm and then improving it.

One of the most successful models developed with purpose to structure the software process improvement within software firms is the CMMI which is developed by the Software Engineering Institute (SEI, 2006)

In this research, we are developing a dynamic model based on system thinking methodology to understand the dynamic cause and effect of implementing CMMI Maturity Level 2. The dynamic model will improve the SPI Program management and will allow teams responsible for SPI to simulate the different scenarios and policies to implement the program

2.2 KNOWLEDGE NATURE OF SOFTWARE INDUSTRY

Software is by nature different and complex. It is both intellectual and immaterial; In fact the software is the output of a combination of interacting dimensions.

Fig 2.1 Software As Knowledge Based Industry

The software development cycle starts with an idea (to solve a problem to replace a value chain or to revolutionize existing systems), or a need from customer who want to solve an existing problem or fulfill expansion need. Sometimes also it comes from the competition especially if the firm is a follower not a leader. Ideas, needs and competition are the basic source or input to the software development. The three inputs are dependent on knowledge, the process to generate each is totally different but the common factor is knowledge nature of the inputs

It is the development team responsibility to capture the relevant knowledge from people (tacit knowledge) or from processes, historical data, �etc(explicit knowledge) to be able to propose a solution. Proposing the solution itself is a knowledge sharing and transfer process between all stakeholders and the output of this is what we call the solution know how. Transforming this into a design is another knowledge process in which the analyst is accepting knowledge and injecting knowledge into the process and the work product resulting from this is the design of the solution which is entirely knowledge dependent on technology platform knowledge, people knowledge, �etc

To deliver the solution, the team needs to manage development know how, testing and QA know how to deliver the final solution and maintenance comes after the delivery

In all steps knowledge transfer, sharing and management are involved in the production of the software application, repeating these steps for certain application accumulates what we call the domain knowledge which is the unique advantage the team will enjoy after going through development of certain kind of applications(ex: Enterprise Resource Planning)

2.3 CHALLENGES OF SOFTWARE INDUSTRY

Due to knowledge nature of the industry, it is innovative and highly vulnerable to factors related to people. That�s why implementing Software Process Improvement programs are very important to structure the process of acquiring and managing knowledge between stakeholders and producing a workable software application (Standish, 1994). Below is a list on non inclusive answers to the question why do we need Software Improvement Programs to overcome software challenges:

� Due to the fierce competition in the software development, companies are more and more in need to be faster, better and cheaper. In order to be faster and better they need to be able to manage complexity of the processes involved in producing, supporting and maintaining their products and services. The complexity of these processes was always a result of the accumulative growth in customer needs and the market pressure. Managing these process and improving them is a key success factor of companies although it is seen by many people as a waste of production throughput. Also every organization has its own DNA which means that a process implemented in one company cannot be just replicated or copied into another (that�s why in CMMI Model, we are taking about process areas not processes. Process areas are areas for improvement of the current process deployed in the firm, whatever the actual process is , it has to fulfill the objectives of the process areas. One process in a company could include multiple process areas of the CMMI according to the company tailoring to CMMI model)

� One of reasons to allocate money and resources for SPI programs in general and consequently models like the CMMI is the percentage of failures reported for software projects. This has been studied by Standish Group (Standish, 1994). Standish Group in its Chaos report in 1994 reported the following: ��.The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars��..� and also said ����..On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.� As reported by Standish Group the reasons for failure was due to:

1. Lack of User Input (12.8%)

2. Incomplete Requirements & Specifications (12.3%)

3. Changing Requirements & Specifications (11.8%)

4. Lack of Executive Support (7.5%)

5. Technology Incompetence (7.0%)

6. Lack of Resources (6.4%)

7. Unrealistic Expectations (5.9%)

8. Unclear Objectives (5.3%)

9. Unrealistic Time Frames (4.3%)

10. New Technology (3.7%)

11. Other (23.0%)

We can map the above failures into the following table (table 2.1):

Table 2.1: Mapping Failure Reasons to CMMI Model

Lack of User Input Covered by CMMI Generic Goals and Practices

Incomplete Requirements & Specifications Covered by CMMI in REQM Process

Changing Requirements & Specifications Covered by CMMI in REQM Process

Lack of Executive Support Covered by CMMI Generic Goals and Practices

Technology Incompetence Covered by CMMI Generic Goals and Practices

Lack of Resources Covered by CMMI Generic Goals and Practices

Unrealistic Expectations Covered by CMMI in REQM Process

Unclear Objectives Covered by CMMI in REQM and PP Process

Unrealistic Time Frames Covered by CMMI in PP Process

New Technology Covered by CMMI Generic Goals and Practices

All of the above failure reasons are covered by CMMI Level 2 Process Areas (covered in section 2.4) which shows that SPI models in general and specifically the CMMI are developed with failure reasons of software projects in mind. Many companies adopted CMMI have reported an improvement in success rates of projects (CMMI Performance Results, http://www.sei.cmu.edu/cmmi/results/results-by-category.html)

� Gordon Brooks CEO of Symphony Services wrote a well known about the �10 Challenges for Software CEOs� (Brooks,2005) the article proposes a 10 challenges that CEOs in Software firms should handle to survive and be competitive in the software market. The 10 Challenges are:

1. What is core to your business - and what is context?

2. How much are you really spending on innovation?

3. Are you hooked on maintenance?

4. Are you really maximizing services revenue?

5. Do you know if your customers are really happy?

6. Are you truly leveraging the vendor ecosystems?

7. Is acquisition really your path to success?

8. Are your resources strategically located?

9. What is your product development outsourcing goal?

10. Are you ready for a new breed of competitor?

These challenges can be easily mapped to CMMI model generic goals, practices and process areas as we did for Standish Group Failure reasons

Complexity of software development comes mainly from the fact that software is an original work that comes out by creativity, knowledge and innovation of people working in the field and by organizations governing the work rules for these people. This situation has created many objectives that need to be taken care of by a project lead or project manager or senior manager while producing the software. The objectives are

� Predictable cost

� Schedule management

� Quality management

� Quality influenced by process not by people

� Shorter Cycle time

� Faster time to market

� Align management and engineering objectives with organization objectives

� Incorporate lessons learned and learn from mistakes

These contradicting and interlaced objectives make it very difficult to manage software development process without a model or without specific improvement initiatives

2.4 CMMI (Capability Maturity Model Integration)

2.4.1 What is CMMI?

Capability Maturity Model Integration (CMMI) is a process improvement approach which provides the guidance to effectively manage enterprises for faster output and better quality. CMMI provides the basis for every organization to custom tailor its own process according to their own problems, cycles, customer needs and management style effectively without sacrificing the industry best practices (SEI, 2006).

CMMI was originally developed by Software Engineering Institute to allow a structured approach to be followed by vendors undertaking Department of Defense (DoD), then it was developed more and more to be more generic. CMMI has achieved a world wide adoption and according to Capability Maturity Model� Integration (CMMI�) Version 1.2 Overview (SEI, 2007), there are 1,377 organizations reported to be following CMMI (took SCAMPI A) world wide and also it shows that 63.8% are non-USA organizations. Some of the most important organizations adopting CMMI are:

� Accenture

� Boeing

� General Dynamics

� Honeywell

� Intel

� Nokia

� U.S. Army

� Wipro

� EDS

� General Motors

� IBM Global Services

� BMW

� Ericsson

� Fujitsu

� Hitachi

� Infosys

� KPMG

� Motorola

� NEC

� Reuters

� U.S. Air Force

� U.S. Treasury Department

In Egypt. According to the Software Competence Centre (the SEI strategic partner in Egypt) there are twenty three Egyptian Software Companies achieved Capability Maturity Model Integration (CMMI) accreditation levels

Now CMMI is being used by companies in the new emerging outsourcing forces (India, Ireland, Egypt, Syria) as a marketing tool for outsourcing business to be able to compete on US outsourcing contracts

2.4.2 CMMI history

The CMMI is the successor of CMM. CMM was developed from 1987 until 1997. CMMI version 1,1 was released in 2002 with the intention to overcome problems aroused in CMMs. CMMI version 1.2 was release in 2006 to serve as the CMMI for Development (CMMI-DEV) constellation.

Three constellations have been developed by the CMMI Group:

� CMMI for Development(CMMI-DEV): the purpose of this is to provide framework to cover life cycle management for development of products (SEI,2007)

� CMMI for Acquisition(CMMI-ACQ): the purpose of this is to provide framework for acquisition of services, which covers process of acquiring products or services through contract (SEI,2007)

� CMMI for Services(CMMI-SVC):the purpose of this is to provide framework to cover the provision of services(including training, maintenance, operational support) (SEI,2007)

Fig 2.2: The History of CMMs (Source: Carnegie Mellon University, Software Engineering Institute (SEI) (August 2006) CMMI for Development, Version 1.2. CMMI-DEV)

Fig 2.2 shows how the model has developed since 1993 to 2007

2.4.3 Model Structure

SEI developed the model to typically focus on: people, procedures and methods, and tools and equipment as shown in Figure 2.3

Fig 2.3: The Three Critical Dimensions

What ties up the whole three, are the processes that are used by organizations. Processes are those activities that are achieved by a well trained and/or skilled people using a predefined (whether documented or not) methods and procedures using tools and equipments to produce a certain work product. This work product could be a full software application, part of application, component, documentation or any other artifact. Processes are the only thing that (if properly managed) will ensure that organization is improving customer satisfaction

2.4.4 CMMI Implementation

The following steps are the usual steps needed to accomplish the CMMI project successfully:

� Provide Funding and Sponsorship: Software Process Improvement efforts are like most of the change management initiatives, it starts with a vision and empowerment from top management as well as necessary budget for the project

� Forming CMMI Team: firm should form a task force to start the implementation. The task force should include (but not limited to) members of quality assurance team, project management, development, testing as well as the leadership from the senior management

� Provide Core Training: firm should provide the CMMI team with the necessary basic training to understand the model and the issues involved in the process

� Informal Gap Analysis: SCAMPI C in CMMI language, its objective is to know where are we, checking all practices and see clearly the deficiencies, limitations, constraints to the project,�etc. This informal Gap analysis is very important in paving the way to a good planning of the project and can be done by external consultants or internal expertise if available

� Plan for the change: firm should plan for CMMI project like any other project, starting with the scope, objectives, WBS, resource allocation, risk management,�.etc. Select which way you need to go either using staged or continuous representations as well as the target levels for the staged representation

� Define the Processes: involve all stakeholders to generate a new version of the process to be implemented

� Communicate the plan to all team members and start deploying the new process

� Track progress and improve, to measure progress an objective SCAMPI B is needed either by authorized SEI partner or from SEI directly, the role if the SCAMPI B is to provide guidance on model implementation and assessment of the current implementation

� Rating: in order to be rated by SEI, SCAMPI A should take place, it is the most rigorous and detailed method that checks all artifacts, practices, project, people,�etc

Fig 2.4: Appraisal and Implementation Steps

The differences between SCAMPI A, B and C are correlated to the objectives from each, evidence gathered, ratings to be generated, coverage, team size and team skills

In SCAMPI C, consultant is gathering documents conducting interviews to assess the current situation, at this type of assessments there is no rating allowed, one consultant is capable to do the SCAMPI C, no need for a lead appraiser to do this SCAMPI C appraisal

In SCAMPI B the team size should increase to at least two consultants. For SCAMPI A, rating will be provided and team size will be at least 4, SCAMPI A lead appraiser is required

As shown in Fig 2.4 the feedback loops are mandatory for the successful implementation of the CMMI which proves the Cause and Effect behaviors of the process

2.4.5 CMMI staged and continuous representations

The building blocks of the CMMI model are organized into Process Areas. Process Areas are not processes with entry criteria, exit criteria,�.etc but they are describing how to effectively manage the processes

A representation is the way these process areas are organized in order to implement the CMMI, there are two types of representations as shown in Fig 2.5

Fig 2.5: Staged versus Continuous Representations

Selecting either staged or continuous representation is totally dependent on the objectives of the software process improvement program. The comparison between both representations as provided by (SEI, 2007):

Table 2.2: Staged versus Continuous Representation

Staged Representation Continuous Representation

Process status is measured using maturity levels

Fig 2.6: Staged Representation

Process status is measured using capability levels

Fig 2.7: Continuous Representation

Maturity levels have predefined groups of PAs you provide proven path for improvement Capability levels apply to individual Pas allowing organization to select an improvement path

Organizational process maturity describes the degree to which the organization implements the behaviors described in a set of PAs Process area capability describes the degree to which the organization implements the behaviors described in a single PA

Systematic and structured approach to software process improvement

Flexible approach to applying software process improvement program, in this approach an organization would be choosing the process areas that needs improvement first, which provide a priority based phased approach

Realizing each maturity level will make sure that we have enough infrastructure for the next phase

Selection of Process Area is critical because dependencies between process areas will be an issue

In case organization doesn�t have a clue on what areas that needs to be improved or needs certain level as marketing tool for their outsourcing business then Staged representation will be better because it specific, robust and number of organizations adopted it are very large compared to continuous representation

It allows organizations with knowledge about which processes need to be improved to customize the program at whatever rate they want. It is possible that continuous improvement be done on multiple processes with different rates for each

2.4.6 CMMI Process Areas

Process Areas are the cluster of best practices related to areas of effective management in the software development life cycle, these process areas when applied with the required set of goals and practices, the processes organization wide will be improved(SEI,2006)

There are 22 process areas, presented here in alphabetical order:

Causal Analysis and Resolution (CAR)

Configuration Management (CM)

Decision Analysis and Resolution (DAR)

Integrated Project Management +IPPD (IPM+IPPD)

Measurement and Analysis (MA)

Organizational Innovation and Deployment (OID)

Organizational Process Definition +IPPD (OPD+IPPD)

Organizational Process Focus (OPF)

Organizational Process Performance (OPP)

Organizational Training (OT)

Product Integration (PI)

Project Monitoring and Control (PMC)

Project Planning (PP)

Process and Product Quality Assurance (PPQA)

Quantitative Project Management (QPM)

Requirements Development (RD)

Requirements Management (REQM)

Risk Management (RSKM)

Supplier Agreement Management (SAM)

Technical Solution (TS)

Validation (VAL)

Verification (VER)

2.4.7 CMMI Maturity Level 2 Process Areas

For an organization to achieve Maturity Level 2 it has to satisfy the following Process Areas:

Configuration Management (CM)

Measurement and Analysis (MA)

Project Monitoring and Control (PMC)

Project Planning (PP)

Process and Product Quality Assurance (PPQA)

Requirements Management (REQM)

Supplier Agreement Management (SAM)

CMMI Maturity Level 2 should satisfy the following objectives:

� Defined and practiced processes according to organizational policy

� Processes are deployed by well trained people having the proper knowledge to do this

� Processes are deployed with involvement of relevant stakeholders

� Processes are deployed, controlled, monitored and reviewed

� Processes are evaluated for adherence for definitions

CMMI Maturity Level 2 should satisfy certain Generic Goals which contribute to process institutionalization, build infrastructure and will be applied on all process areas

To achieve maturity level 2 the following Generic Goals and related practices should be fulfilled:

GG1: Achieve Specific Goals

GP 1.1 Perform Specific Practices

GG2: Institutionalize a Managed Process

GP 2.1 Establish and 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 Manage Configurations

GP 2.7 Identify and Involve Relevant Stakeholders

GP 2.8 Monitor and control Process

GP 2.9 Objectively evaluate adherence

GP 2.10 Review status with the high level management

2.4.8 Requirements Management Process Area (REQM)

Requirements management purpose is to manage the requirements of a project properly to be able to(SEI, 2007) :

� Accurately manage scope

� Achieve completeness of requirements

� Ensure feasibility and clarity of requirements

� Achieve stability of the requirements

� Minimize inconsistencies between gathered , agreed on requirements and the project plans and work products identified and resolved

� Establish baselines for project activities

� Verify work products with customer needs

Requirements Management is affected by Configuration Management (CM), Requirements Development (Not CMMI Maturity Level 2 PA), Project Monitoring and control. REQM affects by Requirements Development, Technical Solution (Not CMMI Maturity Level 2 PA), Product Integration (Not CMMI Maturity Level 2 PA), Project Planning (PP), Supplier Agreement Management (SAM). (SEI, 2007)

This is prove the cause and effect relation between REQM process area and other process areas

For each process area there is a number of specific goals and practices describing the governing rules to effectively manage the processes involving this process area (SEI, 2007)

� SG1 Manage Requirements

o SP 1.1 Obtain and Understanding of Requirements

o SP 1.2 Obtain Commitment to requirements

o SP 1.3 Manage Requirements Changes

o SP 1.4 Maintain Bidirectional Traceability of Requirements

o SP 1.5 Identify Inconsistencies between Project Work and Requirements

2.4.9 Project Planning Process Area (PP)

The purpose of this process area is to establish and maintain plans that identify project activities, tasks,�etc. Project Planning provide (SEI, 2007):

� Support for projects to think in advance of what should be done before doing it to overcome through review and documentation priceless mistakes

� Alignment between the different stakeholders working on the same project

� Preemptive rules and procedures to overcome any conflicts due to lack of clear interaction rules between stakeholder, responsibilities,�etc

� Corrective actions path to solve problems

� Clear risk determination

� Cleat resources allocation

Project Planning Process is affected by (SEI, 2007) Requirements Management (REQM), Requirements Development, Risk Management (Not CMMI Maturity Level 2 PA), Project Monitoring and Control (PMC)

PP affects Project Monitoring and Control (PMC), Configuration Management (CM), Process and Product Quality Assurance (PPQA) and Organizational Training, Verification, Integrated Project Management

Specific practices and goals related to PP are:

� SG1 Establish Estimates

o SP 1.1 Estimate the Scope of the Project

o SP 1.2 Establish Estimate of Work Product and Task Attributes

o SP 1.3 Define Project Lifecycle

o SP 1.4 Determine Estimates of Effort and Cost

� SG2 Develop a Project Plan

o SP 2.1 Establish the budget and schedule

o SP 2.2 Identify Project Risks

o SP 2.3 Plan for Data Management

o SP 2.4 Plan for Project Resources

o SP 2.5 Plan for Needed Knowledge and Skills

o SP 2.6 Plan for stakeholder Involvement

o SP 2.7 Establish the Project Plan

� SG3 Obtain Commitment to the Plan

o SP 3.1 Review Plan that Affect the Project

o SP 3.2 Reconcile Work and Resources Levels

o SP 3.3 Obtain Plan Commitment

Stakeholder involvement, Management Commitment and Employee Commitments are the key to success of the project planning activities, also by establishing formal and approved document used to manage the project execution

2.4.10 Project Monitoring and Control Process Area (PMC)

The purpose of the Project Monitoring and Control is to:

� Track project progress

� Detect inconsistencies between planned and actual implementation

� Resolve inconsistencies between plan and actual implementation

� Allow management to take corrective actions

� Allow communication of project progress between all stakeholders

PMC is affected by Project Planning and Measurement and Analysis and it affects all process areas

PMC depends on the following specific goals and practices (SEI,2007):

� SG1 Monitor Project Against Plan

o SP 1.1 Monitor Project Planning Parameters

o SP 1.2 Monitor Commitments

o SP 1.3 Monitor Project Risks

o SP 1.4 Monitor Data Management

o SP 1.5 Monitor Stakeholder Involvement

o SP 1.6 Conduct Progress Reviews

o SP 1.7 Conduct Milestone Reviews

� SG2 Manage Corrective Action to Closure

o SP 2.1 Analyze Issues

o SP 2.2 Take Corrective Action

o SP 2.3 Manage Corrective Action

2.4.11 Supplier Agreement Management (SAM)

The purpose of the Supplier Agreement Management is to (SEI,2007):

� Select suppliers

� Identify scope of agreement

� Evaluate Supplier Management and execution

� Evaluate delivery of the acquired products

� Detect inconsistencies between planned and actual implementation and resolving them

SAM is affected by Technical Solution, Requirements Management (REQM), Decision Analysis and Resolution (DAR), Verification (VER) and affects Technical Solution as well as Project Planning and Integrated Project Management (Not CMMI Level 2 Process Area)

SAM specific goals and practices are:

� SG1 Establish Supplier Agreements

o SP 1.1 Determine Acquisition Type

o SP 1.2 Select Suppliers

o SP 1.3 Establish Supplier Agreements

� SG2 Satisfy Supplier Agreement

o SP 2.1 Execute the Supplier Agreement

o SP 2.2 Monitor Selected Supplier Processes

o SP 2.3 Evaluate Selected Supplier Work Products

o SP 2.4 Accept the Acquired Product

o SP 2.5 Transition Products

2.4.12 Configuration Management (CM)

The purpose of the Configuration Management is to (SEI,2007):

� Identify work products under configuration management

� Provide tracking of changes doe to work products and having different version and history

� Minimize rework due to updating the wrong version

CM is affected by Project Planning and Project Monitoring and Control and it affects almost all process areas which shows its importance

CM specific practices and goals are:

� SG1 Establish Baselines

o SP 1.1 Identify Configuration Items

o SP 1.2 Establish a Configuration Management System

o SP 1.3 Create or Release Baselines

� SG2 Track and Control Changes

o SP 2.1 Track Change Requests

o SP 2.2 Control Configuration Items

� SG3 Establish Integrity

o SP 3.1 Establish Configuration Management Records

o SP 2.2 Perform Configuration Audits

2.4.13 Process and Product Quality Assurance (PPQA)

The purpose of the Process and Product Quality Assurance is to (SEI,2007):

� Provide insight into processes� weaknesses and strengths

� Objectively Audit and evaluate processes

PPQA is affected by Project Planning and Verification and it affects all process areas which shows its importance

PPQA specific practices and goals are(SEI,2007):

� SG1 Objectively Evaluate Processes and Work Products

o SP 1.1 Objectively Evaluate Processes

o SP 1.2 Objectively Evaluate Work Products and Services

� SG2 Provide Objective Insight

o SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues

o SP 2.2 Establish Records

Objectivity is a major issue here and it is governed by:

� Use of the defined Criteria

� No pre intended bias

� Not being a producer for the work product removes chances for bias and conflict of interest

2.4.14 Measurement and Analysis (MA)

The purpose of the Measurement and Analysis is to (SEI, 2007):

� Develop and Maintain Measurement capability in the organization

� Align Measurement objectives with the actual needs of effective management

� Increase quality of Decisions (Estimations, Problem Resolutions,�.etc)

MA is affected by Project Planning, Project Monitoring and Control, Organizational Process Definition and Quantitative Project Management and it affects all process areas since MA measures outcomes from all other processes

MA specific practices and goals are (SEI, 2007):

� SG1 Align Measurement and Analysis Activities

o SP 1.1 Establish Measurement Objectives

o SP 1.2 Specify Measures

o SP 1.3 Specify Data Collection and Storage Procedures

o SP 1.4 Specify Analysis Procedures

� SG2 Provide Measurement Results

o SP 2.1 Collect Measurement Data

o SP 2.2 Analyze Measurement Data

o SP 2.3 Store Data and Results

o SP 2.4 Communicate Results

2.5 SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION (SPICE)

Software Process Improvement and Capability dEtermination (SPICE) is developed by ISO/IEC 15504. SPICE is comprised of the following maturity levels(Wang, 1997):

0 Not-Performed: No shared characteristics between the different projects and there is a failure in applying practices and there is no documented way to identify work products, and monitor progress and consequently there is no way to predict the output

1 Performed-Informally: Best practices are performed but quality of implementation is totally dependent on the knowledge of individuals practicing the process and there is a well determination of work products

2 Planned and Tracked: Performance is well planned and tracked, work products are aligned with the requirements

3 Well Defined: Practices are performed according to well documented definitions and are tailored to the different situations and scenarios organization wide

4 Quantitatively Controlled: Measures are collected and analyzed and this will give a deeper view of the processes and how they are working and consequently their capability levels

5 Continuously Improving: Measurements and lessons learnt are used for continuous improvement organization wide

2.6 BOOTSTRAP MODEL

It is developed by a non-profit organization to ensure synergy with ISO standards for the software process improvement and SPICE (Wang, 1997)

The BOOTSTRAP methodology has the following objectives:

� To provide assessment of process capability against well known practices

� To provide evaluation method for interaction organization wide

� To ensure objectivity of evaluation for processes across the organization

� To come up with process strengths and weaknesses;

� to align organization goals with improvement initiative activities

� To improve overall process effectiveness of the organization

BOOTSTRAP process model defines processes and capability levels as follows:

Level 0 : Incomplete Process

Level 1 : Performed Process

Level 2 : Managed Process

Level 3 : Established Process

Level 4 : Predictable Process

Level 5 : Optimizing Process

The figure below represents the tree structure of the BOOTSTRAP process model:

Fig 2.8: Bootstrap Model (Source: http://www.cse.dcu.ie/essiscope/sm5/approach/boot-2.html)

2.7 SYSTEM DYNAMICS

System dynamics is a methodology for understanding the complexity of systems based on cause and effect relations between variables as well as the feedback relations. It is adapted from Control Theory and used in simulation of physics and business (Sterman,2000)

The methodology depends on identifying the problem then converting the problem to the dynamic cause and effect relation and based on this we should build what we call the stock and flow which will be deployed on simulation environment (STELLA, VENSIM, POWERSIM, in this research we are using STELLA to build the simulation model)

The model to be simulated will allow user to study the dynamic effect between variables, ability to restructure the business by changing the simulation model and test results

The field developed initially from the work of Jay W. Forrester.

STELLA is developed by isee systems (formerly High Performance Systems). In 1987, the Company was awarded the Jay Forrester prize when it was the first to introduce an icon-based model building and simulation tool, STELLA. STELLA brought computer simulation-based model-building to the mass market.

STELLA allows building stock and flow models that can be simulated to see dynamic effects of the causality represented in the stock and flow.

2.8 SYSTEM THINKING

Systems thinking is used to understand the cause and effect relation between variables and the final causal loop diagram is then created (CLD), this CLD is then used to develop the stock and flow which is the result to the system dynamics

The two techniques share the same causal loop mapping techniques. System dynamics takes the additional step of developing simulation models

2.9 CONCLUSION

Applying software improvement within a company is a complex initiative that requires deep understanding of the cause and effect relationship between the different variables. System dynamics and thinking methodologies is a must to understand this dynamics, that�s why it is somehow represented in the CMMI model within the Causal Analysis and Resolution Process area but within high maturity levels for staff to understand how to improve the performance and reach the learning organization state