PROJECT DATABASEPDB PROCESS CAPABILITY BASELINEPCB Presented By Basker

PROJECT DATABASE(PDB) & PROCESS CAPABILITY BASELINE(PCB) Presented By Basker George

Process Database & Process Capability Baseline n n Past experience play a key role in any organization for improvement & management. This experience should be captured & organized to enable learning This experience should be made available to others For software projects PDB & PCB are two mechanism for encapsulating past experience for use in Project Planning & Management.

Process Database & Process Capability Baseline n n The PDB & PCB encapsulate (装入胶囊) the experience with previous projects. The metrics from PDB & PCB of the previous projects is made available to fresh Project Planning & Management. These two PROCESS are not part of the Project Planning But provide key inputs for planning the infrastructure (基础下部组织) of the project

Process Database & Process Capability Baseline n n n This chapter explains how these two planning support system are implemented at Infosys. The process database is the requirement of Organization Process Focus & Organization Process Definition KPA’s of CMM Level 3. The PCB is a requirement of Quantitative Process Management KPA & Software Quality Management KPA of Level 4.

Process Database & Process Capability Baseline Process Database Process Capability Baseline Closure Analysis Project

Role of Software Metrics & Process Management n Process metrics quantify attributes of the software process, such as n n n Productivity Quality Resource Defects Removal Efficiency of metrics

Role of Software Metrics & Process Management n Product metrics are the measure of the software, such as n n n Size Reliability Quality(metrics of both Process & Product) Complexity of code functionality

Purpose of collecting metrics n The important use of software metrics are: n Project Planning n n Past data from completed projects are invaluable in developing reasonable plans for new projects & setting realistic goals for it. Controlling a project process n Metrics can provide accurate information about the state of a project, which can then be used to take corrective

Purpose of collecting metrics n Analyzing and Improving the organization’s processes. n n n Only through metrics can an organization know the quality & productivity Capability of its processes & the change in quality & productivity with time. Potential area of improvement

Process Database n n n Process database is a collection of process performance data from different projects The PDB is used for project planning, particularly estimation of efforts & defects. To collect metrics on productivity & Quality from different projects To aid in creating process capability baseline To facilitate data analysis for identifying areas & scope of improvement

Process Database DATA n The data collected in PDB can be classified as: n n n Project characteristic Project schedule Project effort Size Defects

Project characteristic n The project characteristic are: n n n Name of Project, PM, PLs Business unit to which it belongs Process being employed n n n Development, Reengineering or Maintenance Project goals, risks, duration, team size Hardware platform, language, DBMS used

Project schedule n n Expected start date Expected end date Actual start date Actual end date

Project effort n n Information on project effort include data on: Initial estimated efforts Total actual estimated effort Efforts include n Project initiation, RM, Design, Built, Testing & other phases.

Size n Information on size include n n LOC No of simple, medium or complex programs.

Defects n Information on defects include n No of Defects found during review of n n n Requirement Management Design Code Unit testing & other phases

Data entry & Access to PDB n n n PDB is owned by SEPG Only SEPG has write access to PDB PM’s & PL’s can only read The input to PDB comes from project closure analysis report The quality advisor examines to verify if data is useful for decision making & then submit the data to PBD.

General data about project called NICE at Infosys General characteristic Field name Value for NICE project Delivery code Development Delivery Notes Retail Market Process tailoring notes nil Peak team size 12

General data about project called NICE at Infosys Tools used VSS 5. 0 for CM LOCCOUNT for counting SLOC Estimated. Start 01 -Oct-96 Estimated. Finish 23 -Apr-97 Estimated. Effort. Hrs 12410 Effort of prototypes developed at the Estimated. Notes beginning of the project was used as the basic for estimation, size prototype was found to be 5000 lines/module. The actual project has 10 modules, so total size estimated as 50, 000 lines & later changed to 60, 000

Estimated Actual. Start Actual. Finish First. Risk Second. Risk Third. Risk. Notes 01 -Oct-96 23 -Apr-97 New Technology Attrition of staff others Talks by team members helped spread knowledge & reduce the learning curve. Two onsite members did liaison with the client & helped freeze requirement faster. Team building exercise were done

Effort Data Table of PDB Effort by Stage (person hours) Stage Task. Effort Review. Effort Requirement analysis Design 3, 936 784 0 471 Coding Independent Unit Testing Integration Testing AT & Installation Project management 4728 637 700 14 90 537 0 0 Configuration Management 10 0

Effort Data Table of PDB Project-Specific 1200 training 0 Others 0 310

Defect Data Defects by Stage Detected Stage Injected Defect Count Design review Requirement 18 Design review Design 182 Code Review Requirement 7 Code Review Design 10 Code Review coding 476 Unit Testing Requirement 0

Defect Data Defects by Stage Detected Stage Injected Defect Count Unit Testing Design 10 Unit Testing coding 89 System Testing Requirement 2 System Testing Design 13 System Testing coding 112 Acceptance Requirement 0 Testing

Defect Data Stage Detected Acceptance test Defects by Stage Injected Defect Count Requirement 0 Design 0 Acceptance test Coding 7