Home > Articles > Software Development & Management > Management: Lifecycle, Project, Team

A Data Analysis Methodology for Software Managers

  • Print
  • + Share This
Software industry expert Katrina Maxwell demonstrates how to analyze complicated databases and transform information into management implications. Learn the methodology for analyzing software project data with this simplified approach.
This chapter is from the book

Introduction

Suppose you inherited the database in Table 1.1 and needed to find out what could be learned from it—fast. Say your boss entered your office and said, "Here's some software project data your predecessor collected. Is there anything interesting about it? I'd like you to present the results at next week's management meeting." Given that it usually takes a number of years to collect enough software project data to analyze, plus the software industry's high job turnover rate, and more often than not, you probably will be analyzing data that was collected by others.

What is this data? What do the abbreviations mean? What statistical methods should you use? What should you do first? Calm down and read on. After eight years of collecting, validating, analyzing, and benchmarking software projects, I've written the book that I wish had been available the day I was told to "find something interesting" about the European Space Agency software project database.

Table 1.1 Software Project Data

id

effort

size

app

telonuse

t13

t14

2

7871

647

TransPro

No

4

4

3

845

130

TransPro

No

4

4

5

21272

1056

CustServ

No

3

2

6

4224

383

TransPro

No

5

4

8

7320

209

TransPro

No

4

2

9

9125

366

TransPro

No

3

2

15

2565

249

InfServ

No

2

4

16

4047

371

TransPro

No

3

3

17

1520

211

TransPro

No

3

3

18

25910

1849

TransPro

Yes

3

3

19

37286

2482

TransPro

Yes

3

1

21

11039

292

TransPro

No

4

2

25

10447

567

TransPro

Yes

2

2

26

5100

467

TransPro

Yes

2

3

27

63694

3368

TransPro

No

4

2

30

1745

185

InfServ

No

4

5

31

1798

387

CustServ

No

3

3

32

2957

430

MIS

No

3

4

33

963

204

TransPro

No

3

3

34

1233

71

TransPro

No

2

4

38

3850

548

CustServ

No

4

3

40

5787

302

MIS

No

2

4

43

5578

227

TransPro

No

2

3

44

1060

59

TransPro

No

3

3

45

5279

299

InfServ

Yes

3

2

46

8117

422

CustServ

No

3

2

50

1755

193

TransPro

No

2

4

51

5931

1526

InfServ

Yes

4

3

53

3600

509

TransPro

No

4

2

54

4557

583

MIS

No

5

3

55

8752

315

CustServ

No

3

3

56

3440

138

CustServ

No

4

3

58

13700

423

TransPro

No

4

2

61

4620

204

InfServ

Yes

3

2


In this chapter, I will share with you my data analysis methodology. Each step is demonstrated using the software project data in Table 1.1. You do not need to understand statistics to follow the "recipe" in Sidebar 1.1. I simply explain what to do, why we do it, how to interpret the statistical output results, and what to watch out for at each stage.

Sidebar 1.1 Data Analysis Recipe

Ingredients:

As much high-quality data as possible

One package statistical analysis software

A good dose of common sense

Step 1: Validate your data

Step 2: Select the variables and model

Step 3: Perform preliminary analyses (using graphs, tables, correlation and stepwise regression analyses)

Step 4: Build the multi-variable model (using analysis of variance)

Step 5: Check the model

Step 6: Extract the equation

After you fully understand Steps 1 through 6, which are explained in this chapter, read the case studies in Chapters 2 through 5 to gain experience analyzing more complicated databases and to learn how to transform your equations into management implications. See Chapter 5 for an example of how to serve your results to your guests. If you have time, refer to Chapter 6 to learn more about the different statistical methods used in the recipe.

Data Validation

The most important step is data validation. I spend much more time validating data than I do analyzing it. Often, data is not neatly presented to you in one table as it is in this book, but it is in several files that need to be merged and which may include information you do not need or understand. The data may also exist on different pieces of paper.

What do I mean by data validation? In general terms, I mean finding out if you have the right data for your purpose. It is not enough to write a questionnaire and get people to fill it out; you need to have a vision. Like getting the requirement specifications right before starting to develop the software. Specifically, you need to determine if the values for each variable make sense.

Why Do It? You can waste months trying to make sense out of data that was collected without a clear purpose, and without statistical analysis requirements in mind. It is much better to get a precise idea of exactly what data you have and how much you trust it before you start analyzing. Regardless of whether the data concerns chocolate bar sales, financial indicators, or software projects, the old maxim "garbage in equals garbage out" applies. If you find out that something is wrong with the raw data after you have analyzed it, your conclusions are meaningless. In the best case, you may just have to correct something and analyze it all again. However, if the problem lies with the definition of a variable, it may be impossible to go back and collect the data needed. If you are collecting the data yourself, make sure you ask the right questions the first time. You may not have a second chance.

How to Do It

Start off by asking these questions:

  • What is this data?

  • When was the data collected?

  • Why was the data collected?

  • Who collected it?

  • How did that person ensure that everyone understood the definitions?

  • What is the definition of each variable?

  • What are the units of measurement of each variable?

  • What are the definitions of the values of each variable?

Example

The software development project data in Table 1.1 describes 34 COBOL applications running in a mainframe environment at a bank. Most of these applications used other languages in addition to COBOL. The project's manager collected the data upon completion of each project. One person entered all project data into a company database and validated it. The purpose of the data collection was to help manage project portfolios at the bank. Table 1.2 defines the variables. I recommend that you create a table like this for each database you analyze. It is important to be very organized so you can return to your work later and understand it (or leave it for someone else to understand).

Once we understand what the variables are, we need to check that the values make sense. One easy way to do this is to use a data summary function for all variables with numerical values. Example 1.1 shows the number of observations (Obs), the average (Mean), the standard deviation (Std. Dev.), the minimum (Min), and the maximum (Max) value for each variable. For the moment, we are just interested in the number of observations and range of values. If the number of observations is not the same for each variable, this means that data is missing. This may be normal as all variables may not have been collected for each project, or it may point to a problem. See if you can find these missing values and add them to the database before you go any further. Also, check to see if the maximum and minimum values make sense. In this case, they do. But if t13 or t14 had 7 as a maximum value, we would immediately know there was a problem because by definition, 5 is the highest value possible.

Table 1.2 Variable Definitions

Variable

Full Name

Definition

id

identification number

Each completed project has a unique identification number. (Originally, each project was given a name instead of a number, but I replaced these names for data confidentiality reasons.)

effort

effort

Work carried out by the software supplier from specification until delivery, measured in hours.

size

application size

Function points measured using the Experience method.

app

 

 

 

application type

 

 

 

CustServ = Customer service

MIS = Management information system

TransPro = Transaction processing

InfServ = Information/on-line service

telonuse

 

 

Telon use

 

 

Telon is a tool that generates code.

No = No Telon used

Yes = Telon used

t13

 

 

 

 

 

staff application knowledge

 

 

 

 

 

Knowledge of application domain in project team (supplier and customer):

1 = Very low; team application experience <6 months on average

2 = Low; application experience low; some members have experience; 6-12 months on average

3 = Nominal; application experience good; 1-3 years on average

4 = High; application experience good both at supplier and customer sites; 3-6 years on average; business dynamics known

5 = Very high; both supplier and customer know application area well, including the business; >6 years' average experience

t14

 

 

 

 

 

staff tool skills

 

 

 

 

 

Experience level of project team (supplier and customer) in regard to development and documentation tools at project kick-off:

1 = Very low; team has no experience in necessary tools; team's average experience <6 months

2 = Low; tools experience less than average; some members have experience with some tools; 6-12 months on average

3 = Nominal; tools experience good in about half the team; some members know development and documentation tools well; 1-3 years on average

4 = High; most team members know tools well; some members can help others; 3-6 years on average

5 = Very high; team knows all tools well; support available for specific needs of project; >6 years' average experience


This is also a useful exercise to undertake when someone transfers a very large database to you via the Internet. When it is impossible to check each value individually, check the summary values with the person who sent you the data. I also recommend checking all the variables one-by-one for the first project, the last project, and a few random projects from the middle of the database to make sure nothing got altered during the transfer.

Example 1.1

                                     . summarize
Variable    Obs     Mean        Std. Dev.      Min       Max
Id          34      31.5        17.9059          2        61
Effort      34    8734.912     12355.46        845     63694
Size        34    578.5882     711.7584         59      3368
t13         34    3.235294     .8548905          2         5
t14         34    2.911765     .9000891          1         5

Next, I tabulate each variable that has words or letters as values. Besides providing valuable information about how many projects are in each category, it is also an easy way to check for spelling mistakes. For example, if there was one observation for CustSer and five observations for CustServ, you should check if there are really two different categories.

In Examples 1.2 and 1.3, Freq. is the number of observations in each category, Percent is the percentage of observations in each category, and Cum. is the cumulative percentage. We can see that the majority of the applications (about 59%) are transaction processing (TransPro) applications. Seven applications used Telon in addition to COBOL. For business presentations, this type of information would look good displayed in a pie chart.

Example 1.2

                             . tabulate app
Application Type          Freq.         Percent          Cum.
CustServ                     6            17.65          17.65
MIS                          3             8.82          26.47
TransPro                    20            58.82          85.29
InfServ	5                14.71           100.00
Total                       34           100.00

Example 1.3

                   . tabulate telonuse
Telon Use          Freq.          Percent          Cum.
No                   27            79.41          79.41
Yes                   7            20.59         100.00
Total                34           100.00

What to Watch Out For

  • What does a blank mean? (Missing? Don't know? None?)

  • What does a 0 mean? (0? Missing? A number close to 0 that has been rounded to 0?)

  • If there is an "Other" category, what does it include? If the "Other" category is extremely diverse, it can't be analyzed as a homogenous category.

  • Can you cross-check any variables to see if they make sense? For example, if you have the start date, end date, and duration of a project, you can check if end date – start date = duration.

  • + Share This
  • 🔖 Save To Your Account