This book attempts to put some science onto the topic.
It attempts to give you methods for determining how big your project is compared to others, what is your code quality like and how efficient are your developers.
It contains many gems such as the relative inefficiencies of coding in different languages. For example VB has a "gear ration" of 42 while java & C# have a GR of 59 which means you must write 40% (59/24=1.41) more code to perform the same task in C# or Java. Which shouldn't come as a surprise to any one.
It even suggests that once you get a couple of projects into a development you might be able to develop a ratio between your specification size (user stories) and the number of NLOC (none-commented lines of code). A wooly estimate but perhaps a usefull one if pushed for an estimate, by a manager.
It goes on to argue that while LOC can be measured easily it is Functional Point Analysis (FPA) which will perhaps yield the best estimation results.
To me this is a better approach as it ties in with the Agile use of User Stories which can be estimated into their relative difficulties. However in Scrum the developers tend to use planning poker which is a method I am not personally in favor of as I prefer a more empirical approach and the use of historical data (see this post on using historical data).
The next stage this book suggests is then converting your Functional points to LOC (which is useful if parts are using different tech) and comparing it to your historical results ie your productivity.
The point here is DON'T GUESS!
Work it out!
"When you can measure what you are speaking about, and can express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind." - Lord Kelvin
"Science/It works bitches." - xkcd
Finally some tools to calculate LOC:
And some books:
Software Quality Metrics Overview
Implementing Automated Software Testing - Continuously Track Progress and Adjust Accordingly
Each application usually has a bit of specificity in some way (workflow complexity, external connection challenges, dynamic user interfaces, customized advanced business calculations or multi-tenancy for SaaS applications), so you can determine the impact that element has in terms of development cost is relatively constant from a project to another.
When determining the complexity of the project you combine several complexity factors, you may also find ratios that help you deal with this complexity and you should be able to evaluate a project based on the following numbers:
These numbers must then be combined with an uncertainty level to create a range for use with three point estimation.A final thought on functional point estimation.
In my experience, the size and complexity of a project is a function of a quite limited number of parameters, that compares from a project to another, whatever the sector or domain area.Each application usually has a bit of specificity in some way (workflow complexity, external connection challenges, dynamic user interfaces, customized advanced business calculations or multi-tenancy for SaaS applications), so you can determine the impact that element has in terms of development cost is relatively constant from a project to another.
When determining the complexity of the project you combine several complexity factors, you may also find ratios that help you deal with this complexity and you should be able to evaluate a project based on the following numbers:
- number of entities
- number of simple business rules
- number of advanced business rules (cross-entity for example)
- number of user interface elements (screens, web pages)
- number of reports
- number of external interfaces
- number of batch calculations or processes
- number of technology variations for components (rich-client, web page, mobile, database providers, cloud systems
But more on that an other day.!
Amitysoft is the best Celenium Training Institute in Chennai
ReplyDelete