ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

THE CASE FOR AUTOMATED DEFECT PREVENTION


Enviado por   •  17 de Junio de 2012  •  5.693 Palabras (23 Páginas)  •  574 Visitas

Página 1 de 23

1

CHAPTER 1

THE CASE FOR AUTOMATED

DEFECT PREVENTION

Why do we never have time to do it right, but always have time to do it over?

—Anonymous

1.1 WHAT IS ADP?

ADP is a paradigm shift and a mindset. It is an approach to software development

and management infl uenced by three distinct yet related factors:

1. The need for new and effective methodologies focusing on improving

product quality

2. The fact that in today’s complex world of perpetual change, sophisticated

technology that assists software development must be an intrinsic part

of project and process management, not just an add-on feature

3. An understanding of the broad spectrum of human factors affecting

modern software development, in particular the psychology of

learning

ADP principles and practices are based on research combined with 20 years

of experience managing internal software projects, working with thousands of

customers, and dealing with software defects on a daily basis. ADP evolved

Automated Defect Prevention: Best Practices in Software Management, by Dorota Huizinga

and Adam Kolawa

Copyright © 2007 John Wiley & Sons, Inc.

COPYRIGHTED MATERIAL

2 THE CASE FOR AUTOMATED DEFECT PREVENTION

from the approach called Automated Error Prevention (AEP) [1], used and

practiced by Parasoft Corporation. Both adaptable and fl exible, ADP can be

applied to either existing or new projects, and it can be introduced as an extension

to any iterative and incremental software process model. When used with

a new project, ADP provides a best-practice guide to defi ning a software development

process and managing a project.

Software has become one of the most pervasive components of our lives.

Our unprecedented dependence on it ranges from keeping track of our calendars

and fi nancial records to controlling electronic devices in our automobiles,

pacemakers, and a host of other applications. Yet few other goods are

delivered to market with more defects than software products. This is because

there are now more opportunities than ever for defects to be injected into

software under development. For example, a typical enterprise system nowadays

encompasses many complex multitier applications and is often a precarious

combination of old and new technologies, such as legacy systems wrapped

as web services and integrated with newer components through a serviceoriented

architecture. At each layer there are possibilities for making mistakes,

and a simple defect in one component can ripple throughout the system,

causing far-reaching and diffi cult-to-diagnose problems. Additionally, today’s

most common method of verifying system quality is through testing at the end

of the life cycle. Unfortunately, this “quality through testing” approach is not

only resource-intensive, but also largely ineffective. Since most of the time the

number of possible states to be tested is prohibitively large [2], testing often

leaves many system states untested, waiting only to reveal previously undetected

defects at the most unexpected moment.

Thus, ADP takes an alternative approach of comprehensive defect prevention

by modifying the development process in the entire software life cycle [3]

to reduce opportunities for mistakes. In essence, ADP helps development

teams prevent software faults by learning from their own mistakes and the

mistakes of others. In order to achieve this, ADP describes a blueprint for life

cycle defect prevention in its set of principles, practices, and policies.

At the heart of ADP lies its infrastructure, which defi nes the roles of

people, required technology, and interactions of people with technology. This

infrastructure facilitates both the implementation and sustainability of ADP

processes through automation of repetitive, error-prone tasks and by automatic

verifi cation of error-preventive practices. This infrastructure also assists

in the seamless collection of project-related data that is used for making

informed management decisions. Thus, in ADP, the technology infrastructure,

together with policies guiding its use, becomes an intrinsic part of project and

process management.

However, no management approach can be effective unless it is based on

an understanding of human nature, and aims at creating an environment that

provides job satisfaction. This is particularly important in software development,

an intellectually challenging task in itself, that is complicated by seemingly

endless industry change that requires constant learning. ADP’s

automation of tedious, repetitive, and mundane tasks combined with gradual,

step-by-step introduction of new practices is an attempt to stimulate effective

learning and perhaps even help achieve a highly increased sense of satisfaction

by entering a peak of mental concentration called “fl ow” [4].

In the next section of this chapter, we will describe the goals that we set

forth for ADP. This will be followed by a high-level overview of ADP’s principles,

practices, and policies. The last section will delineate the relationship

between ADP and modern software development.

1.2 WHAT ARE THE GOALS OF ADP?

The development of ADP was triggered by the need for effective methodologies

that counter poor software quality, with its resulting high costs and operational

ineffi ciencies. However, the high complexity of modern software

development coupled with continuous changes of technology and short time

to market pose a set of unique challenges not found in other industries. To

address these challenges, we have defi ned and addressed the goals for each

category of the software project management [5] spectrum, concentrating not

only on the four Ps suggested by Pressman [6]—people, product, process, and

project—but on the organization as an entirety.

In subsequent sections, we will explain the primary ADP goals for each of

the above categories and the motivation for each goal. (See Figure 1.1.)

1.2.1 People: Stimulated and Satisfi ed

People are the most important resource in an organization, as they are the

sole source of creativity and intellectual power. As much as we strive to defi ne

processes and methods to be people independent, people will

...

Descargar como (para miembros actualizados)  txt (43 Kb)  
Leer 22 páginas más »
Disponible sólo en Clubensayos.com