A lot of discussion in the software development community surrounds the debate around two point of views related to software estimation – Yes to Software Estimation and No to Software Estimation. Both points of view have valid justifications.
Proponents of software estimation see estimation as a primary building block of the software development process. For them no estimation would mean planning to build the roof of a home without building the walls and foundation.
On the other hand, proponents of not carrying out an estimate believe that uncertainty around estimation can be a hindrance to the estimation process. They believe estimation as a redundant activity which wastes time and money. For them estimates are certain to change, scope creep is bound to happen and solid requirements analysis is an unachievable process.
Irrespective of whether you are a software estimation proponent or not, there seems to be a common outcome. With so much distrust looming over the estimation process, we have witnessed both categories of development fail.
Instead of debating on the usability of an estimation process, let us explore estimation objectively –
1. Cost Benefit Analysis
Any activity which requires construction, renovation or improvement must be visualized from a future perspective. We try and analyze whether our effort and cost of this new construction is going to provide a ‘value’ to us. We end up doing a cost/benefit analysis. But to do so, we need to calculate the cost.
How can you assess your benefit if you do not have a framework of your cost factors?
With a given set of variables, known conditions and expected results, it makes sense to do a cost/benefit analysis. Does the cost of doing the project equate the profit (both financial and brand development) to your firm?
2. Estimation is Not Specific But a Range – Control Variation in Functional Specification
Consider non creative conventional activities like running. You have a particular speed for a given distance and you should always record the time. However, most of the time even if you take the same track, the time to do this habitual activity varies. At best if you estimate –you can give a range for time. Estimation is variable in nature –it cannot be specific and objective.
If I tend to coin one word –Estimation is a range! In software development, this range is non linear and skewed. The actual estimate varies from the estimated number by a significant margin of 30-50 percent.
The reason being software development is a creative and complicated process.
There are interruptions, changing usability of features, new definition of user need (causing requirements to change), technological change, variability in market condition etc. Historical perspective cannot be solely responsible for future prediction of software estimates as in the technological landscape, history gets redundant very soon. Seldom is re-work or re-estimation effort is included in final estimation. All these factors cause variability in software estimate numbers.
However, if there happens to be a mechanism which allows robust estimates based on not just feature specification but on ‘system triggers’ or ‘implementation types’, estimate variability can be significantly reduced .
In short, estimation can be the most successful activity if estimation is in terms of how many times and through how many ways the user is going to trigger the system. To control function specification variation, after requirements analysis, graph the system in terms of –
• Project Setup and effort associated with development, installation, deployment, build script
• Use case and Implementation types for each
• Technology platform for development
• Version controls (if any) and its associated effort
• Level of complexity
• Testing environment & number of test cases
3. Organizational Control of Estimation Standards Limits Variation In Estimates– Benchmark Estimation Process
Apart from functional variation, environmental factors affect accuracy of estimates. The greatest problem at the macro level stems from the fact that in the software industry, we don’t have a system of benchmarks. Estimation benchmarks are not defined at the organizational level.
Different definitions exist for stakeholders and developers which cause poor synchronization of goals. Stakeholders and developers should speak a common language. For example – How do you control the productivity of your development team. Surely you cannot but by defining an effort model you can set benchmarks of effort estimation which can be controlled at the organization level.
Again ensuring benchmarking standards in various implementations and their variations pose a limit on the maximum cost one should expect from a certain implementation. By establishing standards, developers would aim for manage duration fluctuation through skill up-gradation and productivity enhancement.
4. Macro Factors Influence Delivery Schedules – Employ a System to Chart and Limit Them
Duration of the project is affected by various external factors such as:
• Unforeseen or unplanned events
• Tester efficiency and test management processes
• Developers tied into other project commitments
• Refactoring activities
• Re-design, rework due to changing user needs and demands
• Fresh feature requirements due to a feature getting suddenly obsolete
The list seems unending and these items can significantly affect delivery schedules. Controlling all of them is not practical, however a system in place which is able to assign effort values to relevant ones such as test management (test cases and testing effort), refactoring effort, developer allocation and related free effort, can help deal with schedule issues.
Intelekit Corporation has been working towards building a system that would restructure the software estimation process in software development. Many of you who deem estimation as unnecessary owing to its uncertain and inaccurate nature would be surprised to see the turnaround time in this software estimation process.
An innovation in this area, Quick FPA would enable designing a platform for benchmarking the effort involved in various implementations on different development platforms.
The system aims to limit all those issues which define software estimation as uncertain. Apart from developers, Quick FPA is equally beneficial for project stakeholders as it aims to ensure fairness and standards for all involved parties.
With Quick FPA, you are sure to transform into a proponent of software estimation.
For receiving an invite for a free trial, register on our website.