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

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

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

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

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

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

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

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

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

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

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

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 © 2016-2017 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 Class\Complexity Simple Average Complex Inputs 3 4 6 Outputs 5 7 Inquiry Internal Files 10 15 External Interfaces Copyright © 2016-2017 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 http://www.qsm.com/blog/2013/staff-project Copyright © 2017 Curt Hill

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 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 Copyright © 2017 Curt Hill

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 Copyright © 2017 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 Copyright © 2017 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 Copyright © 2017 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 Copyright © 2017 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 Copyright © 2017 Curt Hill