Effort may be generated via an estimating model that uses size as an input (among other parameters), or it may be gathered from individual tasks in a work breakdown structure, or a combination of both. In some cases, an effort-based estimate makes more sense than a size-based estimate, especially in a legacy product where enhancements may be small incremental additions to the product. In the case of small incremental changes, size is still a useful measure to track, as it will provide input to the coding effort, inspection effort, and defect estimates. Actual size can be measured by the configuration management system. When dealing with corrective maintenance (defect fixing), you should be using the number of changes/defects distributed by severity. This is still a volume or count and can be translated into size in lines of code when useful, but typically the count of fixes will be more useful. When these tasks exceed forty hours, the usefulness of effort-based estimating declines as the larger tasks start to become "fuzzy" in their definition, and the risk of omissions or oversight increases. I have always thought one of the side benefits to size-based estimating is that it shows the correlation between functions in the requirements statement and the effort required to implement them at a level of granularity that is harder to dispute than large-effort estimates.
Cost data not related directly to effort should be estimated and tracked. This includes travel, equipment, overhead, and other non-labor expenses.
Schedule data should include start and end dates, as well as intermediate key milestones and activities in the project plan. The schedule should relate to the effort and cost estimates.
5) Critical Computer Resources
If performance or capacity is an issue for the installed software, then estimate and track these measures. Merely saying, "Performance is not an issue because we buy more hardware," is not a good answer here. If more resources are required, someone somewhere will need advance notice, as purchasing cycles do take time.
6) Engineering Facilities and Support Tools
Development and test hardware and support software needs to be estimated and tracked. The above elements are those required by the Project Planning and Project Tracking and Oversight Key Process Areas. Estimates, actuals, re-estimates, and replans all need to be captured, along with the reasons for changes, as part of improving the database used to develop future estimates.