1. Or are they really guidelines?
Software Project Laws
Or are they really guidelines?
Stole this from a blog post, but lost the citation.
Shameless plagiarism
Copyright © 2017 Curt Hill

2. Introduction The modern enterprise is dependent on software
Most of these do not do much development
Those that do must understand that a development project is subject to certain laws
Just like the moving things must obey the laws of physics
Copyright © 2017 Curt Hill

3. Five Laws Laws: We can now unpack these
Every software project has a minimum development time
Schedule and cost do not trade off evenly
Projects grow
Small teams are more productive
Allow sufficient time and effort for analysis and design
We can now unpack these
Copyright © 2017 Curt Hill

4. Minimum Time Every software project has a minimum development time
It does not matter what you believe, what your manager believes, what marketing believes or what the CEO/CIO believes
Things that cannot change this:
Pouring unlimited amounts of money into the project
Increasing the number of people
Most common source of failure is unrealistic expectations
Copyright © 2017 Curt Hill

5. Tradeoffs Schedule and cost do not trade off evenly
There are a range of possible schedules
With associated costs
Tighter schedules generally result in higher cost and lower quality
One of the problems is communication
The more staff the harder the communication
Copyright © 2017 Curt Hill

6. Staff and Communication
Two team members
One communication line
Four team members
Six communication lines
Six team members
Fifteen communication lines
The communication lines to not go up linearly
Copyright © 2017 Curt Hill

7. Other Problems
Besides the communication problems it gets worse when development staff are added once the project is started
Someone has to stop doing productive work and bring the new members up to speed
It is also not always possible to keep everyone busy
Workload is not always there, especially at beginning and end
They may be waiting on someone else
Copyright © 2017 Curt Hill

8. Projects grow
Most software projects are also knowledge acquisition projects
You do not know everything that you need to know
Exception: Re-implementing a well known system
The estimation process is dependent on what is known
When new things are discovered the estimate necessarily increases
Copyright © 2017 Curt Hill

9. Growth Factors
Similar to the lack of knowledge is the notion that a high level requirement may become a much more complicated implementation
New requirements are often added
Budget is not usually adjusted
Most enterprises want a budget prior to the start
They never want to increase it
Copyright © 2017 Curt Hill

10. Survey Says A 2007 survey verifies this On average:
Scope increases by 15%
Schedule by 8%
Cost/effort by 16%
You should fight scope creep, but it is not always possible to win this fight
Copyright © 2017 Curt Hill

11. Smaller teams Small teams are more productive
We already have seen the problem with communication
Management often increases the staff in the face of schedule slippage
This often has the opposite effect
Increases the budget but does not hasten delivery
Studies show this
Need a little digression on Function Points
Copyright © 2017 Curt Hill

12. Function Points Start with user requirements
Each requirement is categorized into one of five classes
Inputs
Outputs
Inquiries
Internal files
External interfaces
Next each is evaluated for complexity
Simple, average or complex
Copyright © Curt Hill

13. Points For each class, obtain a count
Given a type and a complexity we obtain a point score by multiplying the count by lookup from table
Class\Complexity
Simple
Average
Complex
Inputs 3 4 6
Outputs 5 7
Inquiry
Internal Files 10 15
External Interfaces
Copyright © Curt Hill

14. The Study Conducted by Quantitative Software Management (www.qsm.com)
They separated more than 2000 projects into groups based on number of function points
Of the projects in a group they considered staffing sizes of the project
They broke them into four equal sized pieces
Then compared the largest quarter and smallest quarter
Copyright © 2017 Curt Hill

15. Table of Results Productivity is in Function Points per Person Month
FP Sizes
Lowest Quarter
Highest Quarter
Ratio
1-100
7.17
2.57
2.77 : 1
13.68
2.83
4.83 : 1
17.44
3.15
5.54 : 1
27.15
3.96
6.86 : 1
34.96
4.35
8.04 : 1
Copyright © 2017 Curt Hill

16. Median Schedule Months by Staffing Quartile
Group Size by FP
Smallest
Second
Third
Largest
1-100
5.75
6.10
5.9
5.77
6.48
7.10
6.8
6.7
6.85
7.03
7.85
7.07
7.45
6.97
8.22
8.17
7.77
7.33
8.3
9.1
Copyright © 2017 Curt Hill

17. Commentary
Hard to do a very rigorous study since every project and staff is different
Function points are not completely objective
Yet we see that adding staff only adds cost
Only occasionally does the schedule shorten
Copyright © 2017 Curt Hill

18. Look Before You Leap
Allow sufficient time and effort for analysis and design
Aggressive schedules tend to make people anxious
One of the results is attempting to start coding before analysis and design are done
This usually results in:
More code being discarded
More code revised or left with defects
Copyright © 2017 Curt Hill

19. Another QSM Study
Projects that put in more than the average amount of time and effort into analysis and design had several characteristics
Finished earlier
Cost less
Developers were more productive
Fewer defects were in the products
Copyright © 2017 Curt Hill

20. Conclusions
Software development projects are not like construction projects
Throwing more money or people at them does not pay
Smaller teams do better than larger teams
Quality cannot be rushed
Software project management needs to understand these differences
Copyright © 2017 Curt Hill