INGENIERA DE SOFTWARE

DE SALA LIMPIA

1
 CONTENIDO
1- INGENIERA DE SOFTWARE DE SALA LIMPIA .................................................... 3
1.1- Concepto .................................................................................................................. 3
1.2- Importancia .............................................................................................................. 4
1.3- Diferencia respecto al desarrollo convencional del software. ................................. 4
2- EL ENFOQUE DE SALA LIMPIA ............................................................................... 5
2.1 Tareas del Enfoque de Sala Limpia .............................................................................. 6
Planificacin de Incrementos ......................................................................................... 6
Recoleccin de Requisitos .............................................................................................. 6
Especificacin de la Estructura de Cajas ........................................................................ 6
Diseo Formal ................................................................................................................ 6
Verificacin de Correccin ............................................................................................. 6
Generacin de Cdigo, inspeccin y verificacin .......................................................... 6
Planificacin de la Comprobacin Estadstica ............................................................... 7
Comprobacin estadstica de utilizacin ........................................................................ 7
Certificacin ................................................................................................................... 7
3- ESPECIFICACIN FUNCIONAL ................................................................................... 7
3.1- Objetivo ................................................................................................................... 7
3.2- Estructura de Cajas .................................................................................................. 7
3.3- Especificacin de Caja Negra .................................................................................. 8
3.4- Especificacin de Caja de Estado ........................................................................... 9
3.5- Especificacin de Caja Transparente ...................................................................... 9
4- REFINAMIENTO Y VERIFICACIN DEL DISEO .................................................. 10
4.1- Finalidad ................................................................................................................ 10
Ejemplo de una verificacin del diseo:....................................................................... 12
4.2- Ventajas de la Verificacin del Diseo .................................................................. 14
5- COMPROBACIN DE SALA LIMPIA ......................................................................... 15
5.1- Finalidad ................................................................................................................ 15
5.2- Comprobacin de Estadstica de Casos Prcticos .................................................. 16
Ejemplo de comprobacin estadstica de casos prcticos: ........................................... 16
5.3- Certificacin ........................................................................................................... 18
ANEXOS .............................................................................................................................. 19
Anexo 1. Mapa Mental Ingeniera de Sala Limpia ........................................................... 19
BIBLIOGRAFA .................................................................................................................. 20

2
 1- INGENIERA DE SOFTWARE DE SALA LIMPIA

1.1- Concepto

Es un mtodo o enfoque de ingeniera de software propuesto en los aos 80 por

Harlan Mills, que hace hincapi en la necesidad de incluir la correccin en el software a
medida que ste se desarrolla, es una tcnica que puede dar lugar a un software de calidad
extremadamente alta. Es un resultado de la combinacin del modelo convencional de
ingeniera de software, mtodos formales, demostraciones de correccin y estadstica de
especificaciones para el aseguramiento de calidad (SQA).

Su filosofa consiste en evitar la dependencia de costosos procesos de eliminacin

de defectos, mediante la escritura de incrementos de cdigo desde un primer momento, y
mediante la verificacin de su correccin antes de las pruebas. Su modelo de proceso
incluye la certificacin estadstica de calidad de los incrementos de cdigo, a medida que
estos se van aadiendo en el sistema.

Al igual que las tcnicas de mtodos formales, el proceso de sala limpia hace
hincapi en el rigor en la especificacin y en el diseo, y en la verificacin formal de cada
uno de los elementos del modelo de diseo resultante mediante el uso de pruebas de
correccin basadas en fundamentos matemticos. Al extender el enfoque adoptado en los
mtodos formales, el enfoque de sala limpia hace hincapi tambin en tcnicas de control
estadstico de calidad, incluyendo las comprobaciones basadas en el uso anticipado del
software por parte de los clientes.

Debido al alto nivel de exigencia que este mtodo requiere, debe ser realizado por
un ingeniero de software formado para sta especializacin

3
1.2- Importancia

Los errores conllevan doble trab ajo. Trabajar el doble lleva ms tiempo y es
ms caro. No sera maravilloso poder reducir dramticamente la cantidad de errores (fallos
informticos) que se cometen en el diseo y construccin del software? Esto es lo que
promete la ingeniera del software de sala limpia.
Cuando el software falla en el mundo real, suelen abundar los peligros a largo plazo
as como los peligros inmediatos. Los peligros pueden estar relacionados con la seguridad
humana, con prdidas econmicas o con el funcionamiento efectivo de una infraestructura
social y de negocios. La ingeniera del software de sala limpia es un modelo de proceso que
elimina los defectos antes de que puedan dar lugar a riesgos graves.

1.3- Diferencia respecto al desarrollo convencional del software.

En el desarrollo convencional del software, los errores se aceptan como cosas que
pasan. Dado que se considera que los errores son inevitables, cada mdulo del programa
debe ser comprobado unitariamente (para descubrir los errores) y depurado despus (para
eliminar los errores). Cuando se publica finalmente el software, la utilizacin prctica
descubre aun ms defectos, y comienza otro ciclo de comprobacin y depuracin. Este
trabajo repetido asociado a las actividades mencionadas resulta costoso y lleva mucho
tiempo. Y lo que es peor, puede ser degenerativo; la correccin de errores puede
(inadvertidamente) dar lugar a la introduccin de otros errores.

Difiere tambin de los puntos de vista convencionales y orientados a objetos en cuanto a:

1. Hace uso explcito del control estadstico de calidad
2. Verifica la especificacin del diseo empleando una demostracin de correccin
basada en las matemticas.
3. Hace mucho uso de la comprobacin estadstica de utilizacin para descubrir
errores de especial incidencia.

4
 El enfoque de sala limpia aplica la mayor parte de los principios bsicos de
ingeniera del software. Prcticas convencionales: quita importancia al papel de la
comprobacin y depuracin de unitarios y al reducir mucho las comprobaciones que son
realizadas por quien desarrolla el software.
En sala limpia, la comprobacin unitaria y la depuracin se ven sustituidas por una
verificacin de correccin y por una comprobacin basada estadsticamente.

2- EL ENFOQUE DE SALA LIMPIA

El enfoque de la sala limpia en las tcnicas de fabricacin de software es la
siguiente: se trata de una forma efectiva y eficiente en trminos de tiempo de establecer un
enfoque de fabricacin que impida la introduccin de defectos de produccin. En lugar de
fabricar un producto y dedicarse despus a eliminar defectos, este enfoque demanda la
disciplina necesaria para eliminar errores en las especificaciones y en el diseo.
En el enfoque de sala limpia se desarrolla un tubo de incrementos de software por
parte de equipos de ingeniera del software pequeos e independientes. A medida que se va
certificando cada incremento, se integra en el todo. La funcionalidad del sistema va
creciendo con el tiempo. Una vez que se ha asignado una funcionalidad al elemento de
software del sistema, el tubo de la sala limpia comienza sus incrementos, como se muestra
en la siguiente figura:

5
2.1 Tareas del Enfoque de Sala Limpia
Planificacin de Incrementos

Se van estableciendo las funcionalidades de cada uno de los incrementos, su tamao

estimado, y un plan de desarrollo de sala limpia. Hay que tener cuidado de que los
incrementos se vayan integrando en forma oportuna.

Recoleccin de Requisitos

Se desarrolla una descripcin ms detallada de requisitos del nivel del usuario.

Especificacin de la Estructura de Cajas

Se utiliza para describir la especificacin funcional. La estructura de caja asla y

separa la definicin creativa del comportamiento, de los datos y de los procedimientos para
cada nivel de refinamiento.

Diseo Formal

Mediante el uso de estructura de cajas, el diseo de sala limpia es una extensin

natural y sin discontinuidades de la especificacin.las especificaciones (que se denominan
cajas negras) se refinan iterativamente (dentro de cada incremento) para transformarse en
diseos anlogos a la arquitectura y a los procedimientos (que se denominan cajas de estado
y cajas tranparentes)

Verificacin de Correccin

El equipo de sala limpia lleva a cabo una serie de rigurosas actividades de

verificacin de correccin aplicadas primero al diseo y despus al cdigo. La verificacin
comienza con la estructura de cajas del ms alto nivel y avanza hacia el detalle de diseo y
el cdigo.

Generacin de Cdigo, inspeccin y verificacin

Las especificaciones de estructura de caja, que se representan mediante un lenguaje

especializado, se traducen al lenguaje de programacin adecuado. Se utilizan tcnicas de
recorrido o de inspeccin para asegurar el cumplimiento semntico de las estructuras de

6
cdigo y de cajas, y la correccin sintctica del cdigo. Se efecta una verificacin de
correccin para el cdigo fuente.

Planificacin de la Comprobacin Estadstica

La utilizacin estimada del software se analiza y se planifica y se disea un

conjunto de casos de prueba que ejerciten la distribucin de probabilidad de esa utilizacin.
Especificacin, verificacin y generacin de cdigo en paralelo.

Comprobacin estadstica de utilizacin

Resulta necesario disear un conjunto finito de casos de prueba. Las tcnicas

estadsticas de utilizacin ejecutan una coleccin de pruebas derivadas de una muestra
estadstica de todas las posibles ejecuciones del programa por parte de todos los usuarios de
una cierta poblacin blanca.

Certificacin

Despus de la verificacin, inspeccin y la comprobacin se certifica el incremento

como preparado para su integracin.

3- ESPECIFICACIN FUNCIONAL
3.1- Objetivo

Independientemente del modelo de anlisis seleccionado. Se modelan los datos, la

funcin y el comportamiento. Los modelos resultantes deben ser desglosados para
proporcionar un grado de detalle cada vez ms elevado. El objetivo global consiste en pasar
de una especificacin que captura la esencia de un problema a una especificacin que
proporciona una cantidad de detalle sustancial para su implementacin.

3.2- Estructura de Cajas

En la especificacin funcional de la ingeniera de software de sala limpia, se emplea

un mtodo llamado Estructura de Cajas. Una caja encapsula el sistema con cierto grado de
detalle. Mediante un proceso de refinamiento progresivo, se van refinando las cajas para

7
formar una jerarqua en la cual cada caja tiene transferencia referencial: el contenido de
informacin de cada especificacin de caja basta para definir su refinamiento, sin depender
de la implementacin de ninguna otra caja (Ver Ilustracin 1). Esto capacita al analista para
desglosar jerrquicamente el sistema.

Ilustracin 1 Refinamiento de la Estructura de Cajas

Se utilizan tres tipos de cajas:

Caja Negra
Caja de Estado
Caja Transparente

3.3- Especificacin de Caja Negra

Es una abstraccin que describe la forma en que un sistema responde a unos

estmulos. Las abstracciones de datos, las operaciones que manipulan estas abstracciones,
se ven encapsuladas por la caja negra. Al igual que una jerarqua de clases, la
especificacin de caja negra puede mostrara las jerarquas de utilizacin en que las cajas de
nivel inferior heredan las propiedades de las cajas de nivel inferior dentro de la estructura
de rbol.

Ilustracin 2 Una especificacin de caja negra

8
3.4- Especificacin de Caja de Estado

Es una generalizacin sencilla de una mquina de estado. Un estado es algn modo

observable de comportamiento del sistema. A medida que se produce el procesamiento, el
sistema va respondiendo a sucesos (estmulos) efectuando una transicin que parte del
estado actual y llega a algn nuevo estado. A medida que se efecta la transicin, puede
producirse una accin.
Utiliza una abstraccin de datos para determinar la transicin al estado siguiente, y
la accin (respuesta) que se producir como consecuencia de la transicin.
La caja de estado contiene una caja negra (Ver Ilustracin 3).

Ilustracin 3 Una especificacin de caja de estado

3.5- Especificacin de Caja Transparente

Est ntimamente relacionada con el diseo de procedimientos y con la

programacin estructurada. Es importante tener en cuenta que la especificacin de
procedimientos descrita en la jerarqua de caja transparente se puede demostrar a efectos de
correccin.

9
 Ilustracin 4 Una especificacin de caja transparente

4- REFINAMIENTO Y VERIFICACIN DEL DISEO

4.1- Finalidad

El enfoque del diseo que se utiliza en la ingeniera del software de sala limpia hace
mucho uso de la filosofa de programacin estructurada. Pero dicha programacin se aplica
mucho ms rigurosa. Las funciones bsicas de procesamiento se refinan ahora utilizando
una expansin progresiva de funciones matemticas en estructuras de conectivas lgicas y
subfunciones, en donde la expansin se efecta hasta que todas las funciones identificadas
pudieran ser enunciadas directamente en el lenguaje de programacin utilizado para la
implementacin
Cada especificacin de caja transparente representa el diseo de un procedimiento
necesario para efectuar una transicin de caja de estado. Mediante la caja transparente, se
utilizan las estructuras de programacin estructurada y de refinamiento progresivo. (Ver
Ilustracin 5).

10
 Ilustracin 5 Refinamiento Progresivo

En cada nivel de refinamiento, el equipo de sala limpia lleva a cabo una verificacin
formal de correccin. Para lograr esto, se asocia un conjunto de condiciones genricas de
correccin a las estructuras de programacin estructurada. Si se expande una funcin f para
dar sucesin a g y h entonces la condicin de correccin para todas las entradas de f es:
Es cierto que g seguido por h da lugar a f?
Si se refina una funcin p para llegar a una estructura condicional (si-entonces-
sino), la condicin de correccin para toda entrada de p es:
Siempre que sea cierta la condicin (c) es cierto que q realiza p y siempre que
(c) sea falsa, es cierto que y realiza p?
Si se refina una funcin m en forma de bucle, las condiciones de correcci{on para
todas las entradas de m son:
Est garantizada la finalizacin?
Siempre que (c) sea verdadera es cierto que n seguido por m, siempre que (c)
sea falso sigue realizndose m si se obvia el bucle?

11
 Cada vez que se refina una caja limpia hasta el siguiente nivel de detalle, se aplican
las condiciones de correccin indicadas anteriormente.

Ejemplo de una verificacin del diseo:

Nuestro objetivo es disear y verificar un pequeo programa que calcule la parte

entera, y, de una raz cuadrada de un entero dado, x, El diseo de procedimientos se
representa empleando el diagrama de flujo de la Ilustracin 6.

Ilustracin 6 Clculo de la parte entera de una raz cuadrada.

Para verificar la correccin de este diseo, es preciso definir las condiciones de

entrada y de salida que se indican en la Ilustracin 7. La condicin de entrada indica que x
debe ser mayor o igual a 0. La condicin de salida requiere que x permanezca intacta y que
adopte un valor dentro del intervalo mostrado en la figura. Para demostrar que el diseo es
correcto, es necesario demostrar que las condiciones comienzo, bucle, cont, si y salida
mostrada en la Ilustracin 7 son ciertas en todos los casos. En algunas ocasiones se
denominan sub-demostraciones.

12
 Ilustracin 7 Demostracin de la Correccin del Diseo (Clculo de raz cuadrada)

1. La condicin comienzo exige que [x>=0 y y=0]. Basndose en los requisitos del
problema, se supone que la condicin de entrada es correcta.
Consiguientemente, se satisface la primera parte de la condicin comienzo, x
>=0. Consiguientemente la segunda parte de la condicin comienzo tambin se
satisface. De aqu que comienzo sea verdadero.
2. La condicin bucle se puede encontrar de dos maneras: a) directamente saliendo
de comienzo (en este caso, la condicin del bucle se satisface directamente) o
bien b) a travs del control de flujo que pasa la condicin cont. Dado que la
condicin cont es idntica a la condicin bucle es verdadera
independientemente de la rama de flujo que lleve a ella.
3. Se llega a la condicin cont nicamente despus de haber incrementado en 1 el
valor de y. Adems, la ruta de flujo de control que lleva a cont solamente se
puede invocar si la condicin si tambin es verdadera. Consiguientemente si
(y+1)2<= x, se sigue que y2<=x. La condicin cont se satisface.
4. La condicin si se comprueba en la lgica condicional que se muestra.
Consiguientemente la condicin si debe ser verdadera cuando el flujo de control
pase por la va mostrada.
5. La condicin salida exige, en primer lugar, que x no aparece en ningn lugar a
la izquierda de un operador de asignacin. No hay ninguna llamada a funcin
que utilice x. Por lo tanto, queda intacto. Dado que la comprobacin de

13
 2
condiciones (y+1) <=x. Adems, la condicin bucle debe seguir siendo
verdadera (esto es y2>=x). Consiguientemente, que (y+1) 2
>x e y2<=x se
pueden combinar para satisfacer la condicin salida.
Adems, es preciso asegurar que finalice el bucle. Un examen de la condicin
del bucle indica que dado que y se va incrementando y que x>=0, el bucle
finalmente debe terminar.

Los cinco pasos anteriormente descritos son una demostracin de la

correccin del diseo del algoritmo indicado en la Ilustracin 6. Ahora se puede
estar seguro de que el diseo calcular realmente, la parte entera de una raz
cuadrada.

4.2- Ventajas de la Verificacin del Diseo

Se reduce la verificacin a un proceso finito.

La forma anidada y secuencial, en que se organizan las estructuras de control en una
caja transparente, define de manera natural una jerarqua que revela las condiciones
de correccin que es preciso verificar. Un axioma de sustitucin nos permite
reemplazar las funciones objetivo por sus refinamientos de estructura de control
dentro de la jerarqua de subdemostraciones.

Permite que los equipos de sala limpia verifiquen todas las lneas de diseo y
cdigo.
Los diseadores pueden efectuar la verificacin mediante un anlisis y debate en
grupo de las bases del teorema de correccin y pueden producir pruebas escritas
cuando se necesite una confianza adicional en algn sistema crtico.

Da lugar a un nivel de defectos prximo a cero

Durante una revisin en equipo, se verifica por turnos la correccin de todas y cada
una de las estructuras de control. Cada miembro del equipo debe estar de acuerdo en
que cada condicin es correcta, por tanto, un error solamente es posible si todos y
cada uno de los miembros del equipo verifican incorrectamente una condicin. El

14
 requisito de acuerdo unnime basado en las verificaciones individuales de
resultados da lugar a un software que posee pocos o ningn defecto antes de su
primera ejecucin.

Es escalable.
Todo sistema de software, independientemente de su tamao, posee unos
procedimientos de caja transparente del ms alto nivel formados por estructuras de
secuencia, alternancias e iteraciones. Cada uno de estos invoca tpicamente a un
gran subsistema que posee miles de lneas de cdigo. Por lo tanto, las condiciones
de correccin para estas estructuras de control de alto nivel se verifican de la misma
forma en que se procede con las estructuras de bajo nivel.

Produce un cdigo mejor que la comprobacin unitaria.

La comprobacin unitaria solamente comprueba los efectos de ejecutar vas de
pruebas seleccionadas entre muchas vas posibles. Al basar la verificacin en la
teora de funciones, el enfoque de sala limpia puede verificar todos y cada uno de
los posibles efectos sobre los datos, porque an cuando un programa pueda tener
mltiples vas de ejecucin, solamente posee una funcin. La verificacin tambin
es ms eficiente que la comprobacin unitaria. La mayora de las condiciones de
verificacin se pueden verificar en unos pocos minutos, pero las comprobaciones
unitarias requieren una cantidad notable de tiempo para prepararlas, ejecutarlas y
comprobarlas.

5- COMPROBACIN DE SALA LIMPIA

5.1- Finalidad

Es algo fundamentalmente distinto de los enfoques convencionales de

comprobacin. Los mtodos convencionales derivan de un conjunto de casos de prueba
para descubrir errores de diseo y de codificacin. El objetivo de comprobacin de sala
limpia es validar los requisitos de software mediante la demostracin de que una muestra
estadstica de casos prcticos se ha ejecutado con xito.

15
5.2- Comprobacin de Estadstica de Casos Prcticos

La tctica y estrategia de la prueba de sala limpia es algo fundamentalmente distinto

de los enfoques convencionales de comprobacin. Los mtodos convencionales derivan de
casos de prueba para descubrir errores de diseo y codificacin. El objetivo de los casos de
prueba de sala limpia es validar los requisitos del software mediante la demostraci{on de
que una muestra estadstica de casos prcticos se han ejecutado con xito.
El usuario de un programa no suele necesitar comprender los detalles tcnicos del
diseo. El comportamiento visible para el usuario de ese programa est controlado por las
entradas y sucesos que suelen ser producidos por el usuario. Pero en casos complejos, el
espectro posible de entradas y sucesos (casos prcticos) pueden ser extremadamente
variables. Entonces Cul es el subconjunto de casos prcticos que verifica adecuadamente
el comportamiento del programa? sta es la primera cuestin que aborda la prueba
estadstica de casos prcticos.
La comprobacin estadstica de casos prcticos equivale a comprobar el software en
la forma en que los usuarios tienen intencin de utilizarlo. Para lograr esto, los equipos de
comprobacin de sala limpia deben determinar la distribucin de probabilidad de
utilizacin correspondiente al software. La especificacin (caja negra) de cada incremento
del software se analiza para definir un conjunto de estmulos (entradas o sucesos) que
pueden dar lugar a que el software modifique su comportamiento. Basndose en entrevistas
con usuarios potenciales, en la creacin de escenarios de utilizacin, y en una comprensin
general del dominio de la aplicacin, se asigna una probabilidad de utilizacin a cada uno
de los estmulos.
Los casos prcticos se generan para cada uno de los estmulos de acuerdo con la
distribucin de probabilidad de utilizacin.

Ejemplo de comprobacin estadstica de casos prcticos:

Supongamos que tenemos un sistema cualquiera, y se est utilizando la ingeniera

de software de sala limpia para desarrollar un incremento de software que gestione la
interaccin del usuario en una pantalla de administracin de clientes, Para ste incremento
se pueden identificar 4 estmulos. El anlisis indica el porcentaje de probabilidad de cada

16
estmulo. Para facilitar la seleccin de los casos de prueba, estas probabilidades se hacen
corresponder con intervalos numerados entre 1 y 99 (Ver Tabla 1).

Tabla 1 Ejemplo Porcentaje de Probabilidad de una determinada funcionalidad del uso de un Software

Estmulos de Programa Probabilidad Intervalo

Consultar (C) 50 % 1-49
Incluir Registro (IR) 30 % 50-78
Habilitar / Deshabilitar (HD) 15 % 79-94
Eliminar (E) 5% 95-99

Para generar una sucesin de casos de prueba de utilizacin que se ajuste a la

distribucin de probabilidades de utilizacin, se genera una serie de nmeros aleatorios
entre 1 y 99. El nmero aleatorio corresponde al intervalo de distribucin de probabilidad
anteriormente destacado. Consiguientemente, la sucesin de casos prcticos se define
aleatoriamente pero se corresponde con la probabilidad correspondiente de aparicin de ese
estmulo. Por ejemplo, supongamos que se generan las siguientes sucesiones de nmeros
aleatorios:
13-94-22-24-45-56
81-19-31-69-45-9
38-21-52-84-86-4
Se derivan los siguientes casos prcticos mediante la seleccin de los estmulos
adecuados basados en el intervalo de distribucin que se muestra en la tabla anterior:
C-HD-C-C-C-IR
HD-C-C-IR-C-C
C-C-IR-HD-C
El equipo de prueba ejecuta los casos prcticos indicados anteriormente (y otros
ms) y verifica el comportamiento del software frente a la especificacin del sistema. La
temporizacin de las pruebas se registra, de modo que sea posible determinar los intervalos
temporales, el equipo de certificacin puede calcular el tiempo mnimo entre fallos. Si se
lleva a cabo una larga sucesin de pruebas sin fallo, se puede suponer que la fiabilidad del
software es elevada.

17
5.3- Certificacin

Las tcnicas de verificacin y pruebas descritas anteriormente, dan lugar a

componentes de software y a incrementos completos que se pueden certificar. En el
contexto del enfoque de la ingeniera del software de sala limpia, la certificacin implica
que la fiabilidad (medida por el tiempo mnimo entre fallos) podr ser especificada para
cada componente.
El enfoque de certificacin implica cinco pasos:

1) es preciso crear escenarios de utilizacin

2) se especifica un perfil de utilizacin
3) se generan casos de prueba a partir del perfil
4) se ejecutan pruebas y los datos de los fallos se registran y se analizan
5) se calcula y se certifica la fiabilidad.

La Certificacin para la ingeniera de software de sala limpia requiere la creacin de

tres modelos:
Modelo de muestreo: la comprobacin de software ejecuta m casos de
prueba aleatorios y queda certificada si no se produce ningn fallo o si se
produce un nmero de fallos inferior al especificado. El valor de m se deriva
matemticamente para asegurar que se alcance la fiabilidad necesaria.
Modelo de componentes: es preciso certificar un sistema compuesto por n
componentes. El modelo de componentes capacita al analista para
determinar la probabilidad de que falle el componente i antes de finalizar el
programa.
Modelo de certificacin: se estima y certifica la fiabilidad global del sistema.

18
 ANEXOS
Anexo 1. Mapa Mental Ingeniera de Sala Limpia

19
 BIBLIOGRAFA

Ingeniera del Software, Un Enfoque Prctico. Quinta Edicin. Roger S. Pressman.

Editorial McGraw Hill.

20