Regional Office: Coimbatore,

Management by metrics is the expectation from the IT service providers to stay as a differentiator. Given a project, the associated parameters and dynamics, the behaviour and outcome need to be predicted. There is lot of focus on the end state and in minimizing defect leakage as much as possible. In most of the cases, the actions taken are re-active. It is too late in the life cycle. Root cause analysis and corrective actions can be implemented only to the benefit of the next project. The focus has to shift left, towards the execution phase than waiting for lessons to be learnt post the implementation. How do we pro-actively predict defect metrics and have a preventive action plan in place. This paper illustrates the process performance model to predict overall defect density based on data from projects in an organization.


INTRODUCTION TO OVERALL DEFECT DENSITY
Number of defects leaked into production is a key metric that IT service providers will track month on month and intend to show a downward trend to their clients.Number of defects as a measure alone might not make sense, its relationship with size or effort is important.
For example, if we have 40 defects leaked in January, 30 in February and 5 in March, it doesn't mean that there is a downward trend.30 defects could be for a project effort of 1000 hrs whereas 5 defects could be for a project size of 50 hrs.Hence, the metric that need to be closely tracked is overall defect density, number of defects leaked against the project effort.

II. PROCESS PERFORMANCE MODELS IN ORGANIZATIONS
Process Performance Models (PPM) is probabilistic, statistical and simulative in nature.It can predict interim and final outcome, it is a proactive measure of tracking the end goal instead of a reactive one.It can model the variation of factor and help us understand the predicted range or the variation of its outcomes.Mid-course correction can be made to achieve desired outcome.Interestingly, PPMs enable "What-if" analysis for project planning, dynamic re-planning and problem resolution during project execution.We can run "what if" exercises holding one or more values constant.We can see the effect of tradeoffs between schedule, effort, defects, staff and functionality.CMMI Dev 1.2 predominantly focuses on development and enhancement type of projects.CMMI for Services focuses on production support or maintenance type of projects.At an organization level, the respective Software Engineering Process Group (SEPG) develops few standard process performance models.These models are developed based on the data gathered from different types of projects within the organization.The organization focuses on three to four key models; typically they are around defect density, productivity, and schedule variance.The important step is to agree to standard definitions for the entities and their measured attributes.When we use terms like defect, productivity, size, and even project, different teams will tend to interpret in their own context.Hence it is important to have a common definition.
Managers should have a good understanding of process performance models and should use it to pro-actively manage the customer needs.Project Managers will check the availability of organizational developed process performance models with respect to the project objectives and quality and process performance objectives.During planning phase, managers are expected to implement process models to manage the objectives.Project manager has to define the project objective and consider the organization objective if there is no client objective defined.The specification limit of the objective is derived from process performance baseline arrived at the organization level.Project Manager is expected to provide the values for the controllable factors in process model prediction section.The prediction intervals are automatically generated based on the values provided

III. VARIABLES ASSOCIATED IN PREDICTION MODEL
Based on brain storming session with the project team in the organization the different parameters that influence overall defect density were looked at.The team shortlisted following factors to start with, domain experience, technical experience, defects identified during design and coding phase, overall review efficiency and usage of tools.Operational definitions for these parameters were baseline and data was collected from projects in a particular account against these parameters.Linear regression was performed against the data to find out which are the key variables that influences the overall defect density.www.ijacsa.thesai.orgAfter many trial and error methods the below three variables were established as the x factors.

Y -Overall defect density -No of defects identified
in the entire life cycle of the project against total effort for the project 2. X1 -Technical experience -Average technical experience of the team, in person months 3. X2 -DDD -Design Defect Density -Defects attributed to design identified during design review against effort spent for design 4. X3 -CDD -Coding Defect Density -Defects attributed to coding, identified during code review against effort spent for coding.

IV. DEFECT DENSITY -REGRESSION EQUATION
The project data collated for the x and y factors are as shown in the Table 3   Based on project data analyzed it is evident that overall defect density is critically influenced by design sub process, code sub process and technical experience.Organization Metrics group would help with the baseline data for these metrics.For code sub process and CDD metric, based on the technology (Java, .Net) and review type (manual, tool, FxCop) the baseline values can be tabled.Organization Metrics group will share the baseline values for these combinations.Baseline values will include lower specification limit (LSL), goal and upper specification limit (USL).
The same can be gathered for Design Defect Density as well.Project team needs to choose the process that they would be following for coding or design sub process.Based on the composition of sub process, project goal for DDD and CDD would be calculated.It is also important for the project team to justify why they have gone with a particular sub process and the rationale.Table 4.1 gives the sub process performance baseline for Coding Defect Density and Design Defect Density.The values are represented by A1, A2, A3 and so on.Organization Metrics team would have the actual baseline values for LSL, Goal and USL for these identified metrics.Based on the current project context, the type of technology and review type will selected as shown in Table 4  This plan has to be revisited after completion of each stage.If defects detected during the completed stage fall under different defect types and defect causes not identified for preventing at that stage, then these new types need to be included in the on-going phases.

VII. CONCLUSION
IT organizations focus on customer satisfaction is the key for survival.Unfortunately the element of predictive behavior during planning phase is very minimal and subjective.While Capability Maturity Model recommends pro-active management using quantitative models, the practical implementation is very low.The context of the organization is important in building these models.It is also important to understand that the project managers need to be equipped with the right information, metrics baseline and subject matter expertise.Defect leakage is a standard concern in the industry.The practical case study demonstrated the influence of Coding Defect Density and Design Defect Density.The case study also helped us understand how the values need to be determined, the steps around what-if analysis, the defect prevention plan and the tracking mechanism.This illustration gives us the confidence that the predictive mechanism can be planned and executed well in an organization.

Figure 3 .
Figure 3.1 -Residual PlotMirror pattern is not found in Figure3.1,Residual Plot and hence no heteroscedasticity is found.The normal probability plot is approximately linear.This would indicate that the normality assumption for the errors has not been violated.Looking at the p value, since it is 0.0003 which is < 0.05, null hypothesis is not valid, which means the variables selected have an impact to overall defect density

Table 3 .
.1.Data points from 25 projects in an organization were collected and considered for analysis.Projects factored in were similar in nature.
1 -Project data values

Table 3 .
2 -Regression EquationAs shown in Table3.2,technical experience has a negative influence on overall defect density.As the team's technical experience increases the overall defect density is reduced.The influence of Design Defect Density and Coding Defect Density is positive.This means that when the values of Design Defect Density and Coding Defect Density are low the overall defect density will be low and vice versa.www.ijacsa.thesai.orgV. DEFECT DENSITY -COMPONENTS OF PREDICTION MODEL .2, Selected Sub process performance baseline.

Table 4 .
1 -Sub process performance baseline Sub process performance baseline data was reviewed and based on the current project context the below selection was made.As shown in Table5.1 the sub process code and design review were selected.Based on the project usage, .nettechnologywas selected.The goal, upper specification limit and lower specification limit are chosen from organization baseline report.Estimated effort in person days for the project is 1000 person days.Based on the predicted defect density and organizations standard effort distribution across phases, the defects that could be injected at each phase are predicted as show inTable 5.4

Table 5 .
4 -Predicted-Actual Defects phase wise 9. Based on the actual data collated, keep updating Table 5.4 to compare the expected and actual defects captured.Based on the actual value in each phases, the predicted value for next phases are accordingly impacted.If there any specific inputs or considerations on the actual values, those are highlighted in the remarks column.10.Prepare the detailed defect prevention plan.Against each phase, list down the defect type, defect cause, root cause, preventive action planned, responsible person, target date and the status.Defect types could be incorrect functionality or missing functionality or incorrect user interface or missing user interface.