Project Estimation

One goal of planning is to estimate the size of the project and then fit the project into the schedule because schedules partially, if not completely, drive most projects. Accurately estimating the size of a project can be challenging for the following reasons:

• People are usually overly optimistic. An estimate of two months at first seems like an infinite amount of time. However, during the last two weeks of a project, when developers find themselves working many overtime hours, it becomes clear that two months is too little time.
• The objectives, implementation issues, and quality requirements are not understood clearly. When challenged with the task of creating a data monitoring system, an engineer might estimate two weeks. If the product is designed by the developer and for the developer, this estimate might be accurate. However, if the product is designed for other users, the developer probably is not considering requirements that a less knowledgeable user assumes but never clearly specifies.
• VIs need to be reliable and easy to use because the developer cannot be there to fix them if a problem occurs. Thus a considerable amount of testing and documentation is necessary. The user also needs to save results to disk, print reports, and view and manipulate the data on screen. If the user does not discuss the project in detail with the developer, the project can potentially fail.
• People often forget to account for daily tasks in their schedule. There are meetings and conferences to attend, reports to write, existing projects to maintain, holidays, and other tasks that make up a standard work week.

Accurate estimates are difficult because of the imprecise nature of most software projects. In the initial phase of a project, complete requirements are unknown. The implementation of those requirements is even less clear. As you clarify the objectives and implementation plans, you can make more realistic estimates.

The following techniques are some of the current best-practice estimation techniques in software engineering. All these techniques require breaking the project down into more manageable components you can estimate individually. There are other methods of estimating development time. Several third-party resources contain more information about these and other estimation techniques.

Source Lines of Code/Number of Nodes Estimation

Software engineering documentation frequently refers to source lines of code (SLOC) as a measurement, or metric, of software complexity. SLOC as a measurement of complexity is popular partially because the information is easy to gather. Numerous programs exist for analyzing text-based programming languages to measure complexity. In general, SLOC measurements include every line of source code developed for a project, excluding comments and blank lines.

The VI Metrics window, included in the LabVIEW Professional Development System, provides a method for measuring a corresponding metric for LabVIEW code. The VI Metrics window counts the number of nodes used within a VI or within a hierarchy of VIs. A node is almost any object, including functions, VIs, and structures, such as loops and sequences, on the block diagram excluding labels and graphics.

You can use the number of nodes as a method for estimating future project development efforts. For this to work, you must build a base of knowledge about current and previous projects. You need an idea of the amount of time it took to develop components of existing software products and associate that information with the number of nodes used in that component.

Using historical information, you then need to estimate the number of nodes required for a new project. You cannot do this for an entire project at once. Instead, divide the project into sub-projects that you can compare to other tasks completed in the past. Once you have sub-projects, estimate the number of nodes required for each sub-project and produce a total estimate of nodes and the time required for development.

Problems with Source Lines of Code and Number of Nodes

Size-based metrics are not accepted uniformly in software engineering. Many people favor size-based metrics because they are relatively easy to gather and because there is a lot of literature on size-based metrics. However, opponents of size-based metrics have the following arguments:

• Size-based metrics are dependent on the organization. Lines of code and numbers of nodes are useful in an organization if you are working with the same group of people who follow the same style guidelines. Using size-based metrics from other companies or groups can be difficult because of differing levels of experience, different expectations for testing and development methodologies, and so on.
• Size-based metrics also are dependent on the programming language. Comparing a line of code in assembly language to one written in C is like comparing apples to oranges. Statements in higher level programming languages can provide more functionality than those in lower level programming languages. Comparing numbers of nodes in LabVIEW to lines of code in a text-based programming language is inexact for this reason.
• Not all code is created with the same level of quality. A VI that retrieves information from a user and writes it to a file can be written so efficiently that it involves a small number of nodes or it can be written poorly with a large number of nodes.
• Not all code is equal in complexity. An Add function is much easier to use than an array index. A block diagram that consists of 50 nested loops is much more difficult to understand than 50 subVIs connected together in a line.
• Size-based metrics rely on a solid base of information that associates productivity with various projects. To be accurate, have statistics for each member of a team because the experience levels of team members vary.

Despite these problems, many developers use size-based metrics for estimating projects. A good technique is to estimate a project using size-based metrics in conjunction with one of the other methods, such as Wideband Delphi Estimation or others listed below. Two different methods can complement each other. If you find differences between the two estimates, analyze the assumptions in each to determine the source of the discrepancy.

Effort Estimation

Effort estimation is similar in many ways to number of nodes estimation. You break down the project into components that are easier to estimate. A good guideline is to divide the project into tasks that take no more than a week to complete. More complicated tasks are difficult to estimate accurately.

Once you have broken down the project into tasks, you can estimate the time to complete each task and add the results to calculate an overall cost.

Wideband Delphi Estimation

You can use Wideband Delphi estimation in conjunction with any other estimation technique, such as function-point estimation, to achieve more reliable estimates. For successful Wideband Delphi estimation, multiple developers must contribute to the estimation process.

First divide the project into separate tasks. Then meet with other developers to explain the list of tasks. Avoid discussing time estimates during this early discussion.

Once you have agreed on a set of tasks, each developer separately estimates the time it takes to complete each task using uninterrupted eight hour work days as the unit of estimation. Have the developers list any assumptions made in forming estimates. Then reconvene the group to graph the overall estimates as a range of values. Keep the estimates anonymous and have a person outside the development team lead this meeting.

After graphing the original set of values, each developer reports any assumptions made in determining the estimate. For example, one developer might have assumed a certain VI project takes advantage of existing libraries. Another developer might point out that a specific VI is more complicated than expected because it involves communicating with another application or a shared library. Another team member might be aware of a task that involves an extensive amount of documentation and testing.

After stating assumptions, the developers reexamine and adjust the estimates. The group then graphs and discusses the new estimates. This process can go on for three or four cycles.

In most cases, you converge to a small range of values. Absolute convergence is not required. After the meeting, the developer in charge of the project can use the average of the results and ignore certain outlying values to create an estimate. If some tasks turn out to be too expensive for the time allowed, the developer can consider adding resources or scaling back the project.

Even if the estimate is incorrect, the discussion from the meetings provides a better idea of the scope of a project. The discussion serves as an exploration tool during the specification and design part of the project so you can avoid problems later.

Several third-party resources contain more information about the Wideband Delphi estimation method.

Other Estimation Techniques

Several other techniques exist for estimating development cost. The following list briefly describes some popular techniques:

• Function-Point Estimation�Function-point estimation differs considerably from the size-estimation techniques described earlier. Rather than dividing the project into tasks that are estimated separately, function points are based on a formula applied to a category breakdown of the project requirements. This method analyzes the requirements for features such as inputs, outputs, user inquiries, files, and external interfaces. These features are tallied and weighted. The results produce a number that represents the complexity of the project. You can compare this number to function-point estimates of previous projects to determine an estimate.
  
  Function-point estimates work well primarily with database applications but also are applicable to other software areas. Function-point estimation is popular as a rough estimation method because it is useful early in the development process based on requirements documents. However, the accuracy of function points as an estimation method has not been analyzed thoroughly.
• COCOMO II Estimation�The second-generation COnstructive COst MOdel (COCOMO II) is a formula-based estimation method for converting software size estimates to estimated development time. COCOMO II includes a set of models that reflects different stages of software development. These models are the Application Composition model (used in the prototyping stage), the Early Design model, and the Post-Architecture model (usually used to evaluate the development and maintenance of the software).

Several third-party resources describe other estimation techniques in detail.