|LabVIEW 2016 Help|
|LabVIEW 2017 Help|
|LabVIEW 2018 Help|
|LabVIEW 2019 Help|
|LabVIEW 2020 Help|
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:
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.
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.
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:
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 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.
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.
Several other techniques exist for estimating development cost. The following list briefly describes some popular techniques:
Several third-party resources describe other estimation techniques in detail.