Home Computer Science 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:
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.
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:
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 
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.
|< Prev||CONTENTS||Next >|