4.5 Omitted Activities


4.5 Omitted Activities

The previous sections described sources of error arising from the project itself. The remaining sections in this chapter turn to a discussion of errors that arise from the estimation practices.

One of the most common sources of estimation error is forgetting to include necessary tasks in the project estimates (Lederer and Prasad 1992, Coombs 2003). Researchers have found that this phenomenon applies both at the project planning level and at the individual developer level. One study found that developers tended to estimate pretty accurately the work they remembered to estimate, but they tended to overlook 20% to 30% of the necessary tasks, which led to a 20 to 30% estimation error (van Genuchten 1991).

Omitted work falls into three general categories: missing requirements, missing software-development activities, and missing non-software-development activities.

Table 4-2 lists requirements that are commonly missing from estimates.

Table 4-2: Functional and Nonfunctional Requirements Commonly Missing from Software Estimates

Functional Requirements Areas

Nonfunctional Requirements

Setup/installation program

Accuracy

Data conversion utility

Interoperability

Glue code needed to use third-party or open-source software

Modifiability

Performance

Help system

Portability

Deployment mode

Reliability

Interfaces with external systems

Responsiveness

 

Reusability

 

Scalability

 

Security

 

Survivability

 

Usability

Tip #17 

Include time in your estimates for stated requirements, implied requirements, and nonfunctional requirements—that is, all requirements. Nothing can be built for free, and your estimates shouldn't imply that it can.

Table 4-3 lists software activities that estimators often overlook.

Table 4-3: Software-Development Activities Commonly Missing from Software Estimates

Ramp-up time for new team members

Mentoring of new team members

Management coordination/manager meetings

Cutover/deployment

Data conversion

Installation

Customization

Requirements clarifications

Maintaining the revision control system

Supporting the build

Maintaining the scripts required to run the daily build

Maintaining the automated smoke test used in conjunction with the daily build

Installation of test builds at user location(s)

Creation of test data

Management of beta test program

Participation in technical reviews

Integration work

Processing change requests

Attendance at change-control/triage meetings

Coordinating with subcontractors

Technical support of existing systems during the project

Maintenance work on previous systems during the project

Defect-correction work

Performance tuning

Learning new development tools

Administrative work related to defect tracking

Coordination with test (for developers)

Coordination with developers (for test)

Answering questions from quality assurance

Input to user documentation and review of user documentation

Review of technical documentation

Demonstrating software to customers or users

Demonstrating software at trade shows

Demonstrating the software or prototypes

of the software to upper management, clients, and end users

Interacting with clients or end users; supporting beta installations at client locations

Reviewing plans, estimates, architecture, detailed designs, stage plans, code, test cases, and so on

Tip #18 

Include all necessary software-development activities in your estimates, not just coding and testing.

Table 4-4 lists the non-software-development activities that are often missing from estimates.

Table 4-4: Non-Software-Development Activities Commonly Missing from Software Estimates

Vacations

Company meetings

Holidays

Department meetings

Sick days

Setting up new workstations

Training

Installing new versions of tools on workstations

Weekends

Troubleshooting hardware and software problems

Some projects deliberately plan to exclude many of the activities in Table 4-4 for a small project. That can work for a short time, but these activities tend to creep back into any project that lasts longer than a few weeks.

Tip #19 

On projects that last longer than a few weeks, include allowances for overhead activities such as vacations, sick days, training days, and company meetings.

In addition to using the entries in these tables to avoid omitting parts of the software or kinds of activities from your estimates, you might also consider looking at a Work Breakdown Structure (WBS) for the standard kinds of activities to be considered. Section 10.3, "Hazards of Adding Up Best Case and Worst Case Estimates," discusses estimating with a WBS and provides a generic WBS.




Software Estimation. Demystifying the Black Art
Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))
ISBN: 0735605351
EAN: 2147483647
Year: 2004
Pages: 212

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net