Desktop version

Home arrow Computer Science arrow Object-Oriented Analysis and Design for Information Systems Modeling with UML, OCL, and IFML


Use Case Based Project Planning

Introduction to effort estimation and risk analysis in software projects

The motivation for effort estimation in software projects comes from the fact that historically most software development projects:

  • • Take more time to complete than expected.
  • • Cost much more than expected.
  • • Generate a product that does not have the quality expected.
  • • Generate a product that does not have the scope expected.

Thus, the point is that software development teams and clients must learn to expect the right time, cost, quality, and scope regarding their project and their team. Effort estimation techniques are used to accomplish these goals.

Ad hoc techniques

A number of techniques for effort estimation have been proposed and used in the last several decades. One that is very popular is the Smith technique, which may be summarized as “Smith, tell us how much time you need to develop that system!” A variation of the Smith technique is the constrained Smith technique, which may be summarized as “Smith, you have three months to develop that system!” Although popular (and known by other names, such as Susan, Peter, Mary, etc.), this approach is not very accurate.

Another ad-hoc technique that is used is the six months technique. It consists of estimating “six months” for any software project at the beginning of its development and then adjusting it up or down as the scope and requirements are discovered. Variations of that technique are virtually infinite, including the One Year technique and the Eighteen Months technique, among others.

These kinds of techniques are known as nonparametric estimation because they are not based on measures on the project to be developed. Somerville (2006) identifies some other nonparametric techniques:

Expert judgment. The expert judgment technique proposes that one or more experts on the project domain and software development should meet and use their experience to produce an estimate. The Smith technique is a potentially bad scenario for the expert judgment technique: the technique may be very inaccurate, depending on the expertise of the estimators. However, if the experts really have experience in similar projects it is a feasible, quick, and relatively cheap technique.


Object-Oriented Analysis and Design for Information Systems. ЕЮI: h Hp ://d.doi.or 10.1016/B978-0-12-41Х67Л-6.00004-1 © 2014 Elsevier Inc. All rights reserved.

  • Estimation by analogy. That technique is in fact the pragmatic basis for the expert judgment technique. It is assumed that the effort for developing a new system will be similar to the effort for developing other similar systems. The technique is not feasible if similar projects are not available for comparison. It can make good use of one or more experts in order to determine what qualifies as a similar system and how the time spent to develop it may be used as a basis to estimate the effort for the current project. Thus, this technique usually may evolve to expert judgment.
  • Parkinson’s Law. That technique is not usually adopted openly, but it is recurrent in software projects and in other areas: the project costs whatever resources are available. The advantage is that the project will not cost more than expected, but frequently the scope of the system will not be completely covered.
  • Pricing to win. The cost of the project is equal to the price that it is believed will win the contract. The disadvantage of this method is that the system the client gets may not be what she expected, because as costs must usually be reduced, this may impact quality and scope. However, when there is no detailed information about the system and the team lacks experience on more advanced estimation techniques this technique may be chosen: the project cost is agreed based on common understandings and the development is constrained by the cost.

The agile community usually adopts an estimation strategy that is based on story points. A user story is a scenario of use of a system, and it is somewhat similar to a use case. However, use cases are more structured and formal; they are produced by a team of analysts. User stories, on the other hand, must be written by the users themselves. They must represent a scenario where the users see themselves using the system that is going to be produced. The idea behind this is that the users present the needs that are most important for them first; the details would be remembered later.

One story point is considered to be an ideal working day (6 to 8 hours focused and dedicated to a project). The estimation effort is then calculated for each user story in terms of story points. The question to be answered by the team is, “How many ideal days x people would take to develop a given user story?” If the answer is x people would take y days, then the number of story points is x*y. Story points assignment is subjective and may be considered a nonparametric technique. The team usually evaluates the effort based on their experience on similar past projects. The assignment is made based on effort, complexity, and risk. For example, the following questions could be asked:

  • Complexity: Does this user story have many possible scenarios?
  • Effort: Is the change going to be made in many different components?
  • Risk: Does anyone in the team know the technology necessary to develop this story?

Another way to estimate user stories is to place all user stories on cards on the table. Then, the simplest ones to develop are separated and one story point or less is assigned to them. After that, the simplest of the remaining stories are separated and two story points assigned to them. This procedure is repeated until no more user stories remain on the table. It is suggested that each iteration increase the number of story points by following a series similar to the Fibonacci series such as 0, V2, 1, 2, 3, 5, 8, 13, 20, 40, 100, etc.1 The reasoning behind this is that for an average human it is [1]

hard to estimate how much a horse weighs; however, most people will agree that a horse weighs more than a dog and less than an elephant.

If a user story is determined to take less than one ideal working day, it must be attached to another story, and stories that are above a given limit (for example, 10 story points) must be split into simpler stories.

  • [1] [In the actual Fibonacci series, each number is the sum of the previous two. Thus, the original series is 1, 1, 2, 3, 5, 8,13, 21, 34, 55, 89, etc. However, for estimation purposes an approximate series is used because as numbers grow theestimation is less accurate.
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >

Related topics