Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry we don’t do a great job of estimation. In this article I offer six safety tips to keep in mind as you prepare estimates for your project and for your individual work... These six safety tips might not help you create estimates that all of your customers, managers, and coworkers will dance to, but at least they will help you and your team hear the same music.

A bid is like a product that, once designed, the team must be able to deliver it. This delivery includes manufacturing the product, testing it, preparing the marketing for the product launch and finally launch it.  We propose a staged approach that replace guessing a number with qualitative investigation. The model suggested, distilled from experience, shows how estimates are transformed into effort and, ultimately, into a coherent story with a price tag attached.
The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team.

Use Case Points are used as an analysis phase technique for estimating software development. Assuming the Business Analyst (BA) composes system use cases for describing functional requirements, the BA can use this technique for estimating the follow-on implementation effort. This article reviews the process of estimating the follow-on development effort for use cases.


When you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking - I know this from experience. It's like driving a racing car - you have to push close to the limits but any error can throw you completely off the track.


Software production has become one of the key activities of the industrialized world. Software applications are now the driving force of business, government operations, military equipment, and most of the services that we take for granted: electric power, water supplies, telephones, and transportation.

Most major companies and government agencies build or commission new software applications every year. But software development and software contracts have been very troublesome. Cost and schedule overruns are common, and litigation for software problems is a frequent outcome. Successful development of large software projects is so difficult that significant percentage of large systems greater than 10,000 function points are canceled and never completed.

One of the major challenges of software cost and schedule estimation is “sizing” or predicting the amount of source code and other deliverables that must be built to satisfy the requirements of a software application. Sizing is a critical precursor to software cost estimating whether estimation is done manually or by means of a commercial software cost estimating tool.

For software applications that are similar to existing applications, size can be derived by analogy to the existing packages. When the software application is a new kind of application then sizing by analogy is not a feasible approach.

For much of the history of the software industry, sizing was considered a very difficult and intractable problem. Sizing is still difficult, but over the past 30 years an interesting new methodology for dealing with size prediction has been developed based on the use of the function point metric. This new methodology has the advantage that it can not only predict the volume of source code, but also the volumes of planning documents, specifications, user manuals, test cases, and even the probable number of errors or bugs that might be encountered.




Author: Capers Jones is the President of Capers Jones & Associates LLC. He is also the founder and former chairman of Software Productivity Research, LLC (SPR), where he holds the title of Chief Scientist Emeritus. He is a well-known author and international public speaker, and has authored the books “Patterns of Software Systems Failure and Success,” “Applied Software Measurement,” “Software Quality: Analysis and Guidelines for Success,” “Software Cost Estimation,” and “Software Assessments, Benchmarks, and Best Practices.” Jones and his colleagues from SPR have collected historical data from more than 600 corporations and more than 30 government organizations. This historical data is a key resource for judging the effectiveness of software process improvement methods. The total volume of projects studied now exceeds 12,000. 

Copyright * 2008 by Capers Jones & Associates LLC.  All Rights Reserved.


The Volere requirements techniques were developed to answer the need for a common language for discovering requirements and connecting them to solutions. The language needs to be understandable by business people, customers, business analysts, engineers, designers, suppliers, testers or anyone else whose input is needed. All of these people have different skills and, not surprisingly, different views of what is important. A language intended for all of these people must recognise the differences in peoples’ viewpoints and yet have a consistent way of communicating and tracing the
relevant knowledge. This realisation that requirements is a socio-technical discipline has a strong influence on the development of the techniques.

Author: Suzanne Robertson & James Robertson, The Atlantic Systems Guild


Discusses the use of worker time and how it impacts estimating and scheduling in Project Management....

It's been a while since I've discussed the concept of "effectiveness" but I was recently up in Cincinnati and saw it in action again. This time, I happened to be visiting my brother-in-law who had hired a crew to tear down some dead trees on his property. I went outside to enjoy a cigar and watch the activity. There were three workers who tended to their own individual tasks most of the time; one was busy cutting wood, one was concerned with splitting wood, and one was responsible for hauling it away. When each tended to their own task, they were very productive, but when they grouped together to perform something collectively, I noticed their output dropped significantly as it seemed two watched one work.

Author: Tim Bryce


Having been involved with the systems methodologies field for over 30 years I have been occasionally asked what percentage of time in a project should typically be devoted to a specific phase of work, for example a Phase 1 Feasibility Study, Phase 2 Systems Design, etc. Basically, the reason the person wants to know this is to use it as a means for estimating the remainder of the project. For example, if I were to say Phase 1 represents 10% of the overall project, they would simply multiply the amount of time spent in Phase 1 by ten. This is an unreliable approach for estimating which is why I usually balk at giving out such figures.



Copyright 2006-2024 by Modern Analyst Media LLC