Variances In Personnel Can Change Productivity By a Factor of 10
I got a question today from someone defining best practices on productivity based on personnel. They wanted to know what the differences might be based on their capabilities. It was easy to perform such a trade study in SEER-SEM for the overall productivity or just a partial.
Knowledge bases normally set these so no work is required unless there are known or anticipated specific circumstances. But this trade study took seconds. Here is part of the answer provided:
SEER people-specific parameters include:
Analyst Capabilities: Capabilities of the team to function (not just the individuals) and the impacts of management, motivation, etc. on that team
Analyst Application Experience: Average experience of the software team that will work on the project with the overall domain (such as finance or command & control)
Programmer Capabilities: Capabilities of the team to function (not just the individuals) and the impacts of management, motivation, etc. on that team
Programmers Language Experience: Average team experience with the programming language(s) that will be used in this implementation activity
Development System Experience: Average team experience with the computers, operating systems and other items that will be used to develop the software
Target System Experience: Average team experience with the target computers, operating systems and other items that will be used to execute the software in the end (target) environment
Practices & Methods Experience: Average team experience with the development processes, methods, standards and procedures used on this project
Knowledge bases set these in normal ranges so individual ratings are not required. And if you do know or want to do tradeoffs: One of the important things is to rate the team, not just the individuals, and how they will perform together. And of course the range allows the expressions of your uncertainty up-front.
Looking at the full range, from the worst of the worst to the best of the best, can provide a 10 to 1 variance in cost.
Also, here is a chart showing how those parameters increase costs when they are at the worst case.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Estimating the Cost & Schedule of Packaged Software Deployments
Packages (such as ERP systems, payroll systems, etc) can be great cost savings to organizations, offloading most of the development and maintenance. But they are not a panacea and many deployments fail. About two thirds of the cost of a large package deployment is not the software itself, but the IT infrastructure and other services. SEER for IT covers all those other two thirds of the cost along with SEER for Software (SEER-SEM) which handles all the software development and COTS cognition associated with such a program. Thus a complete package deployment can be estimated, planned and controlled.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
SEER-H Electro Optical Sensor Estimation Validation
If you estimate Electro Optical Sensors you will know what a challenge it can be. That is why SEER-H’s ElectroOptical Sensor model was developed. The following is feedback from a user: SEER-H EOS was within 6% of actuals and they thought they could have gotten even closer had they answered all the questions instead of just the first three. The report follows:
A confirmation of the SpyGlass EOS estimating tool and platform influence factors.
I received a recent Government Procurement announcement for one of the systems in the EO Sensor model database that provided the the unit’s cost and procurement history. The sensor is one of the projects in the CostIQ library. I loaded the the procurement info into the CostIQ SEER-H EOS project i.e. prior units, quantity buy and learning curve. SEER-H EOS projected a production cost of $487,722 and the actual Government procurement cost was $458,000, within 6% of the actual. Note: I had only reset the 3 parameters noted above.
I would expect if I were to do a detail analysis of the procurement/procurement history and tweaked SEER-H EOS the results would even more closely matched the actual procurement cost.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Viable Software Estimation Modeling: A Key Component Of Software Risk Management
I spoke with someone recently who explained the reason they use SEER is for risk management. They pointed out that not only can they determine the risks of schedule, effort and reliability, but the whole of SEER allows them to do risk reduction. A process improvement: no problem, a quick trade off is performed by setting the appropriate SEER parameters for process improvement, process experience, development tools and practices and they can see exactly what to expect, both good and bad. Then when asked to justify the result he can state explicitly: this includes reduction of team experience with processes, the process improvement going on during this project, any tools being deployed in the process improvement effort and the anticipated cost / benefit.
And for projects that are not challenged with new and different challenges, knowledge bases do the job without needing to concentrate on parameters.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Software Staff Size Still Impacts Productivity: Brooks Law Lives!
When drawing conclusions from data it is important to analyse all the relevant considerations and not just one variable. Â For example, the first chart “effective productivity versus effective functions” shows a slight increase in productivity as the project gets bigger. Â Some people have jumped to conclusions stating that bigger projects are more productive. Â However, when looking at staff levels the fallacy becomes apparent.
Of course it is important to define what productivity is. If someone changes a 10,000 function point system and adds 5, the productivity is not 10,005. Â The effective productivity id based on the new functionality and the work involved in redesign, reimplementation, and retest, forming an effective productivity. Â Some studies leave out such detail.
The second chart, from the same data-set, shows that as the staff gets bigger the productivity gets lower, exactly what Brooks Law stated.
Note this analysis was performed using a portion of our database that includes function points, and effective function points as well a effort and staff.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Schedule As an Independent Variable
There has been much talk given, in some development circles, of CAIV, cost as an independent variable (you can request my software CAIV briefing via comment on this BLOG.) This means what it costs should be a key criterion just like other key criteria such as functionality and performance. In a CAIV analysis there is a balance: what you get and how much it costs. This is a good thing since functionality only has a certain value, and spending more on it causes other things to suffer.
Schedule as an Independent Variable (SAIV) has significant merit as well. Getting it done when I need it, perhaps with less functionality than what I think I need (the Agile community points out a third of software functionality developed is rarely used or doesn’t add significant usefulness.) In an outsourced environment there are several main elements to SAIV:
- Incentives for positive contractor performance
- Penalties for poor contractor performance
- Clear definition of the minimum acceptable capability
- Pay the bonus ONLY for major completion, not time phased
Of course, an impossible date will help no one. A minimum time schedule as SEER provides and many iterations are key to success.
SAIV is applicable to computer projects (until Brooks law kicks in) and has been used successfully in construction. F0r example: the Santa Monica freeway repair following the 1994 North-ridge earthquake is an example of a successful SAIV project. Contractors wre informed that that if work completed after the date they would e penalized $200,000 per day and they would receive a bonus of $200,000 per day for each day they beat the schedule.
The winning contractor, made schedule (SAIV) a key criterion. Repairs were completed 74 days early: a $14.5 million bonus. Because the state of California estimated that the freeway’s closure cost Los Angeles’ economy $1 million a day, the speediness of completion may have saved the state as much as $34 million. And as a Los Angeles resident I can attest to the community morale improvement provided by SAIV.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
C Language is AGAIN the Most Widely Used Programming Language
I hear so often tha tthe “C” programing language is dying or dead. I suppose I hear it mostly from Java lovers.. but I can recall having similar conversations with Galorath staff and others.
A new study came out this month showing the C programming language is number one most widely used, followed by JAVA, C++, PHP, Visual Basic, and C#. Â The rise of C was really a drop in JAVA. Very interesting since the PHP and Visual Basic take less time to master and are much less powerful. Â According to studies encapsulated in SEER, it takes about 6 months to become a black belt in Basic or PHP and a year in C, JAVA, C+ and C#.
Interestingly ABAP (SAP language) is number 17 on the list, COBOL is number 29 and good old FORTRAN (where I cut my teeth) is number 34.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
US Software Costs In Rank Order
Thanks to Capers Jones for passing this list rank ordered list of software costs.� As most of us know, software is in crisis and knowing the issues can lead us to solutions.
Here is a ranked list of U.S. software cost drivers:
U.S. Software Costs in Rank Order:
1. The cost of finding and fixing bugs
2. The cost of cancelled projects
3. The cost of producing English words
4. The cost of security flaws and attacks
5. The cost of requirements changes
6. The cost of programming or coding
7. The cost of customer support
8. The cost of meetings and communication
9. The cost of project management
10. The cost of renovation and migration
11. The cost of innovation and new kinds of software
12. The cost of litigation for failures and disasters
13. The cost of training and learning
14. The cost of avoiding security flaws
15.The cost of assembling reusable components
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Project Prediction Infographic
