Software Project Laws Or are they really guidelines

Software Project Laws Or are they really guidelines? Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

• Laws: Five Laws – 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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

Tradeoffs • Schedule and cost do not trade off evenly • There 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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

Other Problems • Besides the communication problems it gets worse when development staff are added once the project is started – Someone must 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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

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 ClassComplexity Simple Average Complex Inputs 3 4 6 Outputs 4 5 7 Inquiry 3 4 6 Internal Files 7 10 15 External Interfaces 5 7 10 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

Table of Results • Productivity is in Function Points per Person Month 1 -100 Productivity Lowest Highest Quarter 7. 17 2. 57 101 -200 13. 68 2. 83 4. 83 : 1 201 -300 17. 44 3. 15 5. 54 : 1 301 -500 27. 15 3. 96 6. 86 : 1 501 -1000 34. 96 4. 35 8. 04 : 1 FP Sizes Creative Commons License - Curt Hill Ratio 2. 77 : 1

Median Schedule Months by Staffing Quartile Group Size by FP Smallest Second Third Largest 1 -100 5. 75 6. 10 5. 9 5. 77 101 -200 6. 48 7. 10 6. 8 6. 7 201 -300 6. 85 7. 03 7. 85 7. 07 301 -500 7. 45 6. 97 8. 22 8. 17 501 -1000 7. 77 7. 33 8. 3 9. 1 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill

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 Creative Commons License - Curt Hill