Measurement In The Personal Software Process1

1

Seminar On

Measurement in the Personal Software Process III Sem. MTech. Software Engineering (QIP) SJCE, Mysore

Nitin Jain 5VZ07SSE04 III Sem. Software Engineering (QIP) SJCE, Mysore

2

3

4

CONTENTS • • • • • • • •

Measurement Overview Fundamental Process Measures Goal-Question-Metric Paradigm (GQM) General PSP Objectives, Goals, and Questions An Example of GQM Gathering Data The Impact of Data Gathering Establishing a Baseline for Personal Process 5

Measurement Overview We measure to get data, so data can help us to do the following • • • •

Gain Quantitative Understanding Evaluate a Product, Process or Organization Control a product or Process Make an estimate or a Plan 6

How to improve Software • Keep attention on what the Software Engineer do: Plan  Organize  Implement  Measure  Verify

7

8

9

CMM Improve from Bottom start from Personal and Move to Team. Team Management

Team Building

Humphrey Develop CMM which later Evolve to CMMI

Team Member Skills

T S P P S P

10

11

12

13

Principal Measurement Categories 1 Objective Subjective 2 Absolute

Relative 3 Explicit Derived 4 Dynamic Static 5 Predictive Explanatory

It Counts Things Involves Human Judgment They won’t vary from other. Eg size of Program is absolute it does not vary from adding other programs. Objectives are Absolute Changes. E.g. average. subjective are Relatives Are taken directly. E.g. Programmer hour Computed from others E.g. number of LOC per hour Have a time Dimension. E.g. date of project They are fixed. Total defect found Can be obtained or generated in advance They are produce after the fact 14

Measurement Required • A Mental Model for defined context to gather Data. • Mental Model helps to design the Schedule status. • Subdivision of the task (Unit Testing)

15

Fundamental Process Measures In establishing a measurement program, we will find it helpful to start with what objective, absolute and explicit measure we can identify. Then we use them as the foundation for a more useful derived measure which are 2. Product Measures 3. Process Measures 4. Resources measures 16

Product Measures • Generally refer to volume of product produce. e.g.. LOC, No. of files etc. • It is applicable for program, module component or manual. • It even include system throughput, memory capacity, module coupling and function point

17

Process Measures • Quantify the behavior of our process. Generally its absolute, explicit and dynamic. • E.g. Event Count( track the occurrence of a n event) • E.g. Time Count (critical in all industry)

18

Resources Measures • Apply to labor hour( Time Required to Develop Software). • It include talking on phone, meetings, discussions etc all are there with the development time. • In many Organizations the quickest and the least expensive way to improve productivity is reduce the amount of time on extraneous activity. 19

Goal-Question-Metric Paradigm It has been devised by Basili, it says Define the Principle Goals for our activity. Construct a comprehensive set of question to help us achieve these goals. Define and gather data required to answer these questions. 20

DEFINING GOALS • Why I am doing this? “Because my manager” told then odds to success decreases. • In measuring process we must think what we are trying to achieve ?

21

THE GOALS HIERARCHY • Helps us to put goals in proper context. • At senior management level they are stable • Understanding the connection between our goal and those above us help us to explain what we are doing in terms that are most meaningful to our management and get there support. • Goal should have lower defect rate or shorter schedule 22

THE GOALS HIERARCHY Customers Goal

Organization’s Goal

Project’s Goal

Manager’s Goal

Personal Goal

Career Goal

Job Goal

Task Goal

23

ROLE OF QUESTIONS • For each process goal, where did I start, where I now, and where do I want to go? • What is important about this goal? • What is the best that has been achieved against this goal? • Does improved performance against his goal have any absolute limit, and if so what is it? 24

METRICS DEFINITION • After setting the goals and determining the key question, we need to define specific measure. • It require presenting the required Data in a form that is understood able, consistent and retrieval . Hence FORMS are used to do.

25

General PSP Objectives, Goals, and Questions PSP Data Gathering Tools Objectives are • To understand how the personal software development works • To determine the steps we could take to improve product quality • To determine the impact of process changes on our productivity. • To establish benchmarks to measure process improvement and • To assist us in making more accurate plan. 26

Question that to be answered While Establishing an Initial Goal • What aspect of my performance are important? • How I would measure these aspect? • What's the best performance achieved by me? • How I can learn from these achievements? • What are other people achieving? • What of their methods might help me to improve 27

An Example of GQM Goal: To Produce Program that contain no defects

Question: How can we produce a Software of such quality that no defect will be found in later testing or use? 28

Producing Defect Free Software • No guarantee to produce defect free software • Its will be something like review with so many phases. • A key constraint is amount of time and expense needed to do the appraisal. • Block Dig… 29

A Software Quality Strategy Development Phase I Measures Appraisal Phase I

Analysis Phase I Control

Data Feedback

Development Phase n Appraisal Phase N Delivered Product Usage

Analysis Phase N

30

Table A PSP1 PROJECT PLAN SUMMARY WITH AND AFTER DEVELOPMENT

Student

Name of Student

Date

DY/MT/YEAR

Program

LOC Counter

Language

C Programming

Instructor

Mr. XYZ

Program #

Number

Summary LOC/Hour

Plan

Actual

To Date

9.0

14.1

13.4

LOC/Hr=60*total new & changed /total 31

Program Size (LOC) Base (B)

Plan 52 (Measured)

Deleted (D)

7

Modified (M)

(counted)

(Estimated)

5 ( counted)

25 (N-M)

Reused (R)

52 (T-B+D-R)

0 (Estimated)

Total LOC(T)

6

5

Added (A)

To Date

(Measured)

(Estimated)

Total New and Changed (N)

Actual 52

0

0

57

185

98

216

0

0

(counted)

30 (Estimated)

(A+M) 70

(N+B-M-D+R)

(Measured)

Total New Reuse

0

Estimated Object LOC(E)

23

32

Time in Phase (min)

Plan

Actual

To date

To date

Planning

10

7

37

4.5

Design

30

50

130

15.6

Code

75

48

268

32.3

Compile

25

9

7

9.3

Test

40

115

283

34.1

Postmort em

20

13

36

4.3

200

242

831

100.0

Total

33

Defect Injected

Planning

Actual

To date

To date %

0

0

0.0

1+1

1+3

12.5

Code

6

20

83.3

Compile

0

0

0.0

Test

0

1

4.1

Total Development

7

24

100.0

Design

34

Defect Removed

Actual

To date

To date %

Planning

0

0

0.0

Design

0

0

0.0

Code

0

0

0.0

Compile

4

13

54.2

Test

3

11

45.8

Total Development

7

24

100.0

After Development

1

1

35

Plan=60*30/200=9 Actual=60*57/242=14.1 To Date= 60*185/831=13.4 Estimated Object LOC(E)= βo + β1*(E=BA+NO+M) βo = 6.70 β1 = 0.0784 6.70+0.0784*(52+185+5) 36

Gathering Data •

No special tools are available for gathering Data.

3. 4. 5. 6. 7.

Manual Data Gathering Forms and Templates The Defect Database The PSP Spread Sheet The Engineering Notebook 37

38

1 Manual Data Gathering • Computer cant determine what we are doing when we stopped using key board. • We cant get the count of defect automatically, when code changes . • To gather data manually logs, forms, databases, spreadsheets and summary report.

39

2 Forms and Templates • Forms are used when • Templates are used amount of data we when amount of data gather is fixed. we gather is not fixed • E.g. forms can be • E.g. Templates have used to estimate time to be used to store required for different the data gathered at stage of project. each stage of the Software life cycle.

40

41

3 The defect Database Field

Data for Defect n

Data for Defect N+1

Data for Defect N+2

Data for Defect N+3

3A

3A

3A

3A

Program Defect Number

6

7

8

9

Type

20

20

40

20

Phase Injected

40

40

20

40

Phase Removed

60

60

70

70

Time-to-fix

1

1

30

1

Program Number

Fix Error

• • • • • •

10-Planning 20-Design 40-Code 60-Compile 70-Test 80-Postmortem

42

The Defect Database The table gives following: • Number of defect injected and removed in a specific phase. • Data on the numbers and types of defect found in a specific phase. • Time required to fix defect as a function of the phase in which its removed. 43

4 The PSP Spread Sheet • •

3. 4. 5.

Is used for recording the raw project and process project data for each program. It consist of following three Size Field Time Field Defect Field

44

Category

Field Name

Progra mn

Program n+1

Progra m n+2

Program Number Summary

Estimated new and Changed LOC Actual new and Changed LOC Estimated Time Actual Time Estimated Defect Actual Defect

45

SizeEstimated

Base Reused Added Deleted Total new and changed Total Estimated Object LOC

Size-Actual

Base Reused Added Deleted Total new and changed

46

TimeEstimated

Requirement & Planning Detailed Design Design Review Code Code review Compile Test Postmortem

Time-Actual

Requirement & planning Detailed Design ………………………

47

Defect Infected Estimated

Requirement and planning

Detailed Design

………………………

Defect Infected Actual

Requirement and planning

Detailed Design

………………………

48

Analyses that can be made using the above PSP spread sheet

• • • •

Regression Calculation Yield Productivity Charts

49

5 The Engineering Notebook

• Is a convenient place in which to make notes, do calculations or document exploratory designs.

50

The Impact of Data Gathering

• DATA GATHERING TAKES TIME • THE DATA CAN EFFECT OUR PERFORMANCE

51

Establishing a Baseline for Personal Process •

2. 3.

The problem of judging performance has two complication Bolstering Clutching

52

Establishing a Baseline for Personal Process Bolstering:is our selectively remembering those result that reinforce what we want to believe. When we don’t analyze we tend to forget disaster and remember successes. Clutching:-

occur when a result is so important that it affects our performance. Its caused due to unconscious feedback. 53

54

Summary • Data gathering falls into product, process, resource • The GQM paradigm helps us to design and implement a measurement program. • Forms, database, spreadsheet, & summary report are used to gather data for PSP. • Gathering data will impact our performance. • We will be curious weather the performance is improving after gathering Data or not, this can be told statistically only after examining huge data. • Sometime Data on Personal performance may be discouraging, as continues work may not improve that but may require change of Process. 55

Thank You

56