A Data Analysis Methodology for Software Managers
This chapter is from the book
This chapter is from the book
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.