Improving Software Processes

Process is an overloaded term. For software-oriented organizations, there are many processes and subprocesses. I use three distinct process perspectives.

• Metaprocess: an organization's policies, procedures, and practices for pursuing a software-intensive line of business. The focus of this process is on organizational economics, long-term strategies, and a software ROI.

• Macroprocess: a project's policies, procedures, and practices for producing a complete software product within certain cost, schedule, and quality constraints. The focus of the macroprocess is on creating an adequate instance of the metaprocess for a specific set of constraints.

• Microprocess: a project team's policies, procedures, and practices for achieving an artifact of the software process. The focus of the microprocess is on achieving an intermediate product baseline with adequate quality and adequate functionality as economically and rapidly as practical.

Table 3-4. Three levels of process and their attributes

attributes

metaprocess

macroprocess

microprocess

Subject

Line of business

Project

Iteration

Objectives

Line-of-business profitability

Competitiveness

Project profitability

Risk management

Project budget, schedule, quality

Resource management

Risk resolution

Milestone budget, schedule, quality

Audience

Acquisition authorities, customers

Organizational management

Software project managers

Software engineers

Subproject managers Software engineers

Metrics

Project predictability

Revenue, market share

On budget, on schedule

Major milestone success

Project scrap and rework

On budget, on schedule

Major milestone progress

Release/iteration scrap and rework

Concerns

Bureaucracy vs. standardization

Quality vs. financial performance

Content vs. schedule

Time scales

6 to 12 months

1 to many years

1 to 6 months

Although these three levels of process overlap somewhat, they have different objectives, audiences, metrics, concerns, and time scales, as shown in Table 3-4. The mac-roprocess is the project-level process that affects the cost estimation model discussed in this chapter.

To achieve success, most software projects require an incredibly complex web of sequential and parallel steps. As the scale of a project increases, more overhead steps must be included just to manage the complexity of this web. All project processes consist of productive activities and overhead activities. Productive activities result in tangible progress toward the end product. For software efforts, these activities include prototyping, modeling, coding, debugging, and user documentation. Overhead activities that have an intangible impact on the end product are required in plan preparation, documentation, progress monitoring, risk assessment, financial assessment, configuration control, quality assessment, integration, testing, late scrap and rework, management, personnel training, business administration, and other tasks. Overhead activities include many value-added efforts, but, in general, the less effort devoted to these activities, the more effort that can be expended in productive activities. The objective of process improvement is to maximize the allocation of resources to productive activities and minimize the impact of overhead activities on resources such as personnel, computers, and schedule.

Some people may be offended by my categorization of late scrap and rework and personnel training as overhead activities that need to be minimized. I have modified scrap and rework with late to differentiate it from the sort of scrap and rework that is a natural by-product of prototyping efforts. Early scrap and rework is a productive necessity for most projects to resolve the innumerable unknowns in the solution space, but it is clearly undesirable in the later phases of the life cycle. With a good process, it is clearly unnecessary.

People will argue that personnel training cannot be a bad thing, but it is for a project. Training is an organizational responsibility, not a project responsibility. Any project manager who bears the burden of training people in processes, technologies, or tools is far worse off than a project manager who has a fully trained work force. Staffing every project with a fully trained work force may not be possible, but employing trained people is always better than employing untrained people, other things being equal. In this sense, training is not considered a value-added activity.

The quality of the software process strongly affects the required effort and therefore the schedule for producing the software product. In practice, the difference between a good process and a bad one will affect overall cost estimates by 50% to 100%, and the reduction in effort will improve the overall schedule. Furthermore, a better process can have an even greater effect in reducing the time it will take for the team to achieve the product vision with the required quality. Why is this true? Schedule improvement has at least three dimensions.

1. We could take an N-step process and improve the efficiency of each step.

2. We could take an N-step process and eliminate some steps so that it is now only an M-step process.

3. We could take an N-step process and use more concurrency in the activities being performed or the resources being applied.

Many organizational time-to-market improvement strategies emphasize the first dimension. However, the focus of most process improvements described in this book is on achieving the second and third dimensions, where there is greater potential. In particular, the primary focus of process improvement should be on achieving an adequate solution in the minimum number of iterations and eliminating as much downstream scrap and rework as possible.

Every instance of rework introduces a sequential set of tasks that must be redone. For example, suppose that a team completes the sequential steps of analysis, design, coding, and testing of a feature, then uncovers a design flaw in testing. Now a sequence of redesign, recode, and retest is required. These task sequences are the primary obstacle to schedule compression. Notwithstanding technological breakthroughs that can eliminate complete process steps, the primary impact of process improvement should be the reduction of scrap and rework in late life-cycle phases.

In a perfect software engineering world with an immaculate problem description, an obvious solution space, a development team of experienced geniuses, adequate resources, and stakeholders with common goals, we could execute a software development process in one iteration witji almost no scrap and rework. Because we work in an imperfect world, however, we need to manage engineering activities so that scrap and rework profiles do not have an impact on the win conditions of any stakeholder. This should be the underlying premise for most process improvements.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment