Estimation technique for an Agile Development

In previous posts, we have discussed various methods of estimation such as lines of code and function point. These are typically used for most software projects. But when you consider a project of very short software duration(consider a project which last just a few weeks) and also where there can be changes in requirements during the timeline of the project, it is difficult to use the lines of code or function point method. In such cases, one of the possible estimation technique is called estimation for agile development.

In a typical agile project, requirements are captured as stories or user scenarios; a different estimation method can be used for such projects. Some of the steps that are to be followed in such an agile project are:

- The estimation of each of the user stories is done on a standalone basis. Suppose the overall project has ten different user stories, we would need to do, at the minimum ten separate rounds of estimation.

- Each user story is further sub-divided into functions and tasks. Typically, each task is a separate discrete engineering unit, the start and end of which can be tracked separately from other tasks.

- Each task is a lowest unit at which estimation is done; at the end of the activity all the tasks have estimates. The engineering team is thus expected to provide estimates for each individual tasks.

- All these estimates for a user story are sum to create the total estimate for each user story.

- At a higher level, the estimates of all the user stories are summed to create the overall estimate.

Automated Estimation Techniques and Tools - Functions and types of tools

Automated estimation techniques and tools allows the planner to estimate the cost and effort and to perform what-if analysis for important project variables such as delivery date or staffing. If applying different estimation tools on the same project data, variation in estimated results are encountered. Sometimes, the predicted values are different from the actual values. The output of estimation tools should be used as one data point from which estimates are derived.

The six functions performed by the automated estimation tools are:

- Sizing of project deliverable.
- Selecting project activities.
- Predicting staffing levels.
- Predicting software effort.
- Predicting software cost.
- Predicting software schedules.

These automated tools require an estimate of project size for example LOC and FP. They require qualitative project characteristics such as complexity, reliability, or business criticality. They also require description of the development staff and/or development environment.

- Tools like BYL (Before You Leap) and WICOMO (Wang Institute Cost Model) require the user to provide lines of code estimates and these estimates are categorized by programming language and type. These tools produces estimated elapsed project duration (in months), effort in staff-months, average staffing per month, average productivity in LOC/pm, and cost per month.
- SLIM is an automated costing system based on the Rayleigh-Putnam Model.
- ESTIMACS uses function point estimation method. It helps the planner to estimate system development effort, cost and staff, the risk and the hardware configuration.
- SPQR/20 developed by Software Productivity Research Inc. It has the user complete a simple set of multiple choice questions.

Estimation techniques - estimation using use cases

We have read about estimation techniques like problem and process based estimation techniques. There is another estimation approach that uses use cases which provide insight into software scope and requirements. However, it is somewhat difficult to develop an estimation technique using use cases.

- There is no standard format or style in which use cases can be described because there are many different formats and styles that a use case can use.
- The complexity of the functions are not addressed by the use cases.
- Complex behavior like interactions among many functions and features are not described by the use cases.
- Use cases are used to represent the user's view of the software.

Use case estimation technique for one person can require a lot of effort while use case estimation technique for some other person can be done in a day or two. According to Smith, use cases can be used for estimation but it is only possible and considered within the context of structural hierarchy that the use case describe.

- structural hierarchy can have not more than 10 use cases.
- each use case can have not more than 30 different scenarios.
- before using use case estimation, level within structural hierarchy is established, average length of each use case is computed, type of software is defined, rough architecture is considered.
- empirical data is used to establish lines of code or function point for each level.

Estimation techniques - Process based Estimation

Another technique that is used is estimating a project on the basis of estimating the base on the process that will be used. A process is decomposed into small tasks and effort that is required to fulfill each task is estimated. As apart of this process one is required to take the project scope and derive software functions from the scope. Now typically, for each function, there are a series of framework activities that must be performed. A 2*2 table would typically be constructed which maps these functions and the related framework activities.

Once you get the problem functions and the process activities, the table is filled by estimating the effort for each software activity for each software function. Once you are done with all the estimation, you have a complete table that forms an input for an estimation of the total cost. As a part of this step, you need to have values for the costing for the various activities. As an example, initial architectural and design activities are done by more senior and experienced people, with the costing for these resources being significantly more than the costing for future coding and testing.

Based on the above, we can generate a total cost. We can also generate the total cost through the lines of code and function point methods. Now, we have three methods of costing and can compare one against the other. If these are close to each other, then the estimates are reliable. If this is not so, then more investigation is required. This would require that the steps that have been taken to research and estimate through the lines of code, function point, or process based estimation would need to be re-examined in much more detail until possible errors are detected and estimates re-calculated.

Estimation techniques - Problem based Estimation

In software estimation, lines of code and function point metrics can be used in two ways:
- it can be used as an estimation variable that could size each element of the software.
- it can be used as baseline metrics that are collected from past projects and are used with the estimation variables to develop cost and effort.

Lines of code and function point are different techniques but there are some characteristics that are common. Project planning begins with scope of the software and software is decomposed into problem functions and are estimated individually and then lines of code and function point are estimated for each function.

Baseline metrics are applied to estimation variable and cost and effort is derived. It should be kept in mind when collecting productivity metrics for projects, one should be sure to establish a taxonomy of project types. This will enable to compute domain specific averages making estimation more accurate.

LOC and FP techniques differ in how decomposition is used. Consider a case when LOC is used, it is essential to use decomposition and that too to a fairly detailed level. In order to get a higher level of accuracy, it is necessary to have a high degree of partitioning.

Now considering the case of FP, the usage of decomposition is different. It is required to get the five information domain characteristics, and the complexity adjacent values. Once these are available, and using past data, an estimate can be generated.

Alongside, a project planner estimates a range of values using historical data; these are the optimistic, most likely, and pessimistic sizes for each function. Based on these, an expected value for the estimation variable can be calculated.

Project Estimation - Decomposition techniques - Estimating the software size

In the estimation of software cost and effort, many variables that include human, technical, environmental, political can affect final cost and effort applied to software. It is a complex process. Decomposing the problem and re-characterization it into a set of smaller problems is an approach for software project estimation.

Decomposition approach has two point of views :
- problem decomposition
- process decomposition

Before estimating, estimating the size of the software is very important. The size of the software to be built can be estimated using lines of code which is a direct measure or through function point which is an indirect measure. Estimating software size is a major challenge. Size is the quantifiable outcome of software project.

Approaches to sizing problems are:
- Fuzzy logic sizing: Identify the application, its magnitude and refining the magnitude within original range.
- Function point sizing: Estimates of information domain characteristics are developed.
- Standard component sizing: The number of occurrences of each standard component
is estimated and project data is used to calculate the delivered size per standard component.
- Change sizing: Suppose an existing software is modified in some way. In this approach, the number and type of modifications are estimated.

These approaches were suggested by Putnam and Myers.

What is meant by Use-case oriented metrics?

Using the use case method is not dependent on the programming language. Typically, you can use use cases as another method of generating the size of the application; the value of use cases is in most cases to the lines of code (LOC) and also to the number of test cases that will have to be written for comprehensive testing of the application. Like many other estimation techniques, the use case method is used early in the software life cycle, before design, development and testing happens.

A use case is written to capture user interactions and functions that describe a system. Many users try to work out what a standard size for a use case is, but use cases can exist at different levels of abstraction. As a result, though there are many attempts to use the use case method as a instrument of trying to measure the effort required for building the application, the inability to define a size and coverage of the use case, means that not many people have been successfully able to do this.

Estimation through use case method is not a simple one; there are multiple steps required such as determining technical factors, determining environmental factors, determining use case points, determining product factors, and then overall, putting all these factors together to get use case points which translate into man-days or man-weeks.

What are different metrics used for software measurement?

Software measurement can be categorized in two ways:
- direct measures of software process.
- indirect measures of product.
There are many factors that can affect the software work so metrics should not be used to compare individuals or teams.

Size oriented software metrics are derived by normalizing quality measures by considering size of the software that is produced. Lines of code is chosen as the normalization value to develop metrics that can get absorbed with similar metrics from other projects. Size oriented metrics are widely used but there is always a debate about their validity and applicability continues.

Function oriented metrics uses measure of functionality that is delivered by an application as a normalization value. Function point metric is based on characteristics of software's information domain and complexity. Function point is language independent and it is based on data that is likely to be known early in evolution.

The quality of the design and the language used to implement the software defines the relationship between lines of code and function points. Function points and LOC based metrics are exact predictor of software development effort and cost.

What are User Interface Design and Operation oriented Metrics?

User interface design metrics are fine but above all else, be absolutely sure that your end users like the interface and are comfortable with the interactions required.
- Layout appropriateness is a design metric for human computer interface. The layout entities like graphic icons, text, menus, windows are used to assist the user.
- The cohesion metric for user interface measures the connection of on screen content to other on screen content. UI cohesion is high if data on screen belongs to single major data object. UI cohesion is low if different data are present and related to different data objects.
- The time required to achieve a scenario or operation, recover from an error, text density, number of data or content objects can be measured by direct measures of user interface interaction.

Operation oriented metrics are:
- Operation complexity is computed using complexity metrics because operations should be limited to a specific responsibility.
- Operation size depends on lines of code. As the number of messages sent by
a single operation increases, responsibilities have not been well allocated within a class.
- Average number of parameters per operation is defined as: larger the number of operation parameters, more complex is the relation between objects.