- Importance of Size
- Inputs to Sizing
- Impact of Delivery Rate
- Effort and Schedule
- Conclusion
- Other Interesting Reading Material
This chapter is from the book
This chapter is from the book
This chapter is from the book
Impact of Delivery Rate
Sizing a software project is important, but knowing the delivery capacity of your programmers is even more critical. The foundation of a predictable project execution is the ability to attain repeatable delivery processes. Having a good handle on the IT organization's delivery rate helps IT managers commit to project delivery timelines with higher confidence.
Measuring the actual productivity of the programmers in an organization is a lengthy and iterative process. Depending on the size of the IT organization and the variety of technology platforms in use, the definition of productivity becomes more and more complex. The following sections discuss some of these complexities and variations.
Productivity Drivers
Productivity, sometimes known as delivery rate, can be viewed as the ratio of output/input. In a software development parlance, output is typically the software product and input is the effort spent by the programmers. The three major ingredients that define productivity are
- Software product (application)
- Software production process (the software project lifecycle activities)
- Software development environment
The productivity measuring team should be able to define and measure each of these ingredients in order to be able to calculate delivery rate figures.
Software Product
The product that is the final delivered output is also called the software application. Other secondary outputs that are delivered during a typical software development project are documentation for requirement specification, design, test plans, test results, and operations manual. In project management, these are called project deliverables.
Software Production Process
Various activities that take place during typical software development lifecycle stages need different process definition. Typical lifecycle activities are
- Requirement analysis and specification
- Architecture
- Detailed design
- Build and unit test
- System and integration test
Different activities in each lifecycle stage need varied skills and competencies. Even with a well-defined process for executing each of the lifecycle activities, the competency of the individual resource controls the productivity for the lifecycle activity.
Software Development Environment
The general environment under which the software project team works contributes toward significant variation in productivity. A good development environment supported by tested and productive tools plays a big role in productivity improvements of the project team. A robust quality control mechanism backed further by reusable software components, artifacts, and best practices further enhances productivity rates. This is perhaps the most difficult part of setting up a well-structured IT organization. It takes considerable length of time to achieve the maturity in defining, deploying, and accepting a wide range of highly productive tools and an equally large number of reusable components that lead to high productivity figures.
Productivity Measurement
Among the three ingredients that impact software development productivity (the product, the development resources and processes, and the environment), the output is the software product and the input is the effort spent during software production stages. The environment, under which the production takes place, controls the variation in input efforts.
Figure 7.2 shows that different lifecycle stage activities require resources with an appropriate level of competency. The most common roles involved in a typical software development project are
- Project manager
- Technical architect
- Business analyst
- Programmers
- Testers
)
Figure 7.2 Productivity parameters.
The number of resources for each category for each lifecycle stage is directly dependent on the project size. Over and above the effort spent by each of the resource categories, a substantial amount of effort goes toward quality and audit-related checks throughout the project execution lifecycle. This quality-related effort is part of the cost of quality. Cost of quality is the cost an organization spends to attain a certain level of quality output.
Measuring Input
Input is the effort spent by various resources throughout the project execution lifecycle toward various kinds of activities like requirement analysis, high level and detail design (architecture), build and unit test, and system and integration tests. Also included are efforts toward cost of quality activities, as shown in Figure 7.2. The efforts thus can be classified as:
- Requirements/business analysis effort = # business analysts x assigned duration
- Architecture and design effort = # architects/technical leads x assigned duration
- Coding and unit testing effort = # programmers x assigned duration
- System and integration effort = (# testers + # programmers) x assigned duration
- Cost of quality = # reviewers x assigned duration for each + effort spent on defect removal + effort spent on orienting project team
Productivity
Adding all these efforts gives the overall effort for the entire project.
Productivity of the team = application size/total effort
Organization-wide baselines for different technologies are prepared using the preceding methods and are used in future projects. Execution of the future projects is improved through experience. In the absence of specific technology baseline productivity, the technology that is the closest is chosen. For example, if the productivity information for C++ is not available, you can start with the productivity figures of C or Java. If nothing close is found, you can use the weighted average productivity from Capers Jones's table of the languages and databases involved. (Refer to http://www.spr.com for more details on Capers Jones's tables.)
Often IT organizations face a dilemma while defining the list of software project execution activities that are included or excluded while calculating the delivery rate of the project team. There is no defined rule for this. It is best defined by individual organizations, based on the project execution processes they have adopted. Following is an illustrative list of activities that can be included when expressing the productivity for a typical software project:
- Requirement analysis
- High level design
- Detailed design
- Build and unit test
- Integration testing
- System testing
- User testing support
- Product quality checks and reviews
Different organizations adopt different methods of including or excluding certain lifecycle activities. Following is an illustrative list of some of the activities that are typically not considered while calculating productivity:
- Project management effort
- Configuration management effort
- Additional quality assurance efforts towards attaining SEI-CMMI Level 4-5
- User acceptance testing activity
- Developing prototype
- Warranty support
- Holidays and personal leaves