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

2. Process Database & Process Capability Baseline 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.

3. Process Database & Process Capability Baseline 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

4. Process Database & Process Capability Baseline 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.

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

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

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

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

9. Purpose of collecting metrics Analyzing and Improving the organization ’ s processes. 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

10. Process Database 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

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

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

13. Project schedule Expected start date Expected end date Actual start date Actual end date

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

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

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

17. Data entry & Access to PDB 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.

18. General data about project called NICE at Infosys General characteristic Field nameValue for NICE project Delivery codeDevelopment Delivery NotesRetail Market Process tailoring notesnil Peak team size12

19. General data about project called NICE at Infosys Tools usedVSS5.0 for CM LOCCOUNT for counting SLOC EstimatedStart01-Oct-96 EstimatedFinish23-Apr-97 EstimatedEffortHrs12410 EstimatedNotes Effort of prototypes developed at the 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

20. Estimated ActualStart01-Oct-96 ActualFinish23-Apr-97 FirstRiskNew Technology SecondRiskAttrition of staff ThirdRiskothers RiskNotesTalks 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

21. Effort Data Table of PDB Effort by Stage (person hours) StageTaskEffortReviewEffort Requirement analysis3,9360 Design784471 Coding4728537 Independent Unit Testing6370 Integration Testing7000 AT & Installation140 Project management900 Configuration Management100

22. Effort Data Table of PDB Project-Specific training 12000 Others3100

23. Defect Data Defects by Stage Stage DetectedStage InjectedDefect Count Design reviewRequirement18 Design reviewDesign182 Code ReviewRequirement7 Code ReviewDesign10 Code Reviewcoding476 Unit TestingRequirement0

24. Defect Data Defects by Stage Stage DetectedStage InjectedDefect Count Unit TestingDesign10 Unit Testingcoding89 System TestingRequirement2 System TestingDesign13 System Testingcoding112 Acceptance Testing Requirement0

25. Defect Data Defects by Stage Stage DetectedStage InjectedDefect Count Acceptance testRequirement0 Acceptance testDesign0 Acceptance testCoding7