Testing y Calidad de Software

Testing de software, normas de calidad y estndares
201
2
Testing de
software, normas
de calidad y
estndares
Maria Victoria Anselmi
Page 1
201
2
Contents
Introduccin........................................................................................................ 8
Las pruebas del software.................................................................................. 10
Mtodos de prueba: Verificacin y Validacin...................................................12
Validacin...................................................................................................... 12
Verificacin.................................................................................................... 13
Pruebas humanas: recorridas y revisiones de programa............................13
Cobertura de las pruebas........................................................................... 15
Caja negra y caja blanca............................................................................. 15
Diseo de los casos de prueba...................................................................16
Prueba por mdulos.................................................................................... 18
Pruebas de nivel superior........................................................................... 19
Planeamiento y control de las pruebas.......................................................20
Terminacin de las pruebas........................................................................21
Debugging.................................................................................................. 21
Sandboxes.................................................................................................. 22
Control de los costos................................................................................... 22
Tareas para las pruebas, entregables y cronologa.....................................23
Las organizaciones y los mtodos de pruebas...............................................23
CMMI for development. CMMI para desarrollo................................................26
Mejorar los procesos para desarrollar mejores productos y servicios...............26
CMMI para desarrollo..................................................................................... 28
Las reas de procesos....................................................................................... 29
El modelo en su conjunto.................................................................................. 30
Niveles de capacidad..................................................................................... 32
Nivel de capacidad 0: Incompleto...............................................................33
Nivel de capacidad 1: Realizado.................................................................33
Nivel de capacidad 2: Gestionado..............................................................33
Page 2
201
2
Nivel de capacidad 3: Definido...................................................................33

Niveles de madurez....................................................................................... 34
Nivel de madurez 1: Inicial.........................................................................34
Nivel de madurez 2: Gestionado.................................................................34
Nivel de madurez 3: Definido......................................................................35
Nivel de madurez 4: Cuantitativamente Gestionado..................................35
Nivel de madurez 5: Optimizado.................................................................36
reas de proceso, categoras y niveles de madurez...................................37
Relaciones entre reas de proceso...................................................................39
Gestin de procesos....................................................................................... 39
reas de gestin de procesos bsicas........................................................39
reas de gestin de procesos avanzadas...................................................40
Gestin de proyectos..................................................................................... 40
reas de gestin de proyectos bsicas.......................................................41
reas de gestin de proyectos avanzadas..................................................42
Ingeniera....................................................................................................... 43
Recursividad e iteracin del proceso de ingeniera.....................................45
Soporte.......................................................................................................... 45
reas de soporte bsicas............................................................................ 46
reas de soporte avanzadas.......................................................................46
Las reas de proceso de Ingeniera...................................................................47
Integracin de producto................................................................................. 47
Propsito..................................................................................................... 47
Notas introductorias................................................................................... 47
reas de proceso relacionadas...................................................................47
Resumen de Goles y Prcticas especficas..................................................47
Desarrollo de requerimientos.........................................................................48
Propsito..................................................................................................... 48
Page 3
201
2
Solucin tcnica............................................................................................. 50
Propsito..................................................................................................... 50
Validacin...................................................................................................... 51
Propsito..................................................................................................... 51
Prcticas especficas por gol.......................................................................53
Verificacin.................................................................................................... 58
Propsito..................................................................................................... 58
Resumen de goles y prcticas especficas:.................................................59
Prcticas especficas por gol.......................................................................60
Norma ISO/IEC 12207, IEEE 12207-2008 Ingeniera de sistemas y de software
Ciclo de vida de los procesos de software......................................................66
Alcance, propsito, limitaciones y conformidad de la norma.........................66
Aplicacin de la norma................................................................................... 67
Categoras de procesos del ciclo de vida.......................................................68
Procesos especficos de software...................................................................69
Procesos de implementacin de software...................................................69
Procesos de soporte de software................................................................70
Procesos de reutilizacin de software.........................................................71
Procesos relacionados con la calidad del software.........................................71
Proceso de testing de calificacin del software...........................................71
Proceso de aseguramiento de la calidad del Software................................72
Proceso Verificacin del Software...............................................................74
Proceso Validacin del Software.................................................................77
Proceso Revisin del Software....................................................................78
Page 4
201
2
Proceso Auditora del Software...................................................................80

IEEE 829 2008 Estndar para Software y Documentacin de Test de
Sistemas........................................................................................................... 83
Objetivos de testing....................................................................................... 83
Niveles de integridad de software y de sistemas...........................................84
Niveles de integridad.................................................................................. 85
Procesos de test.......................................................................................... 85
Proceso de Gerenciamiento........................................................................86
Proceso de Adquisicin............................................................................... 87
Proceso de Suministro................................................................................ 88
Proceso de Desarrollo................................................................................. 89
Proceso de operacin.................................................................................. 92
Proceso de mantenimiento.........................................................................93
Proceso de seleccin de contenido de la documentacin de test..................94
Plan maestro de test................................................................................... 95
Plan de nivel de test................................................................................... 98
Diseo de nivel de test............................................................................. 104
Casos de test de nivel. (LTC)..............................................................105
Procedimiento de nivel de test.................................................................106
Log de nivel de test.................................................................................. 106
Reporte de anomala (AR).........................................................................107
Reporte interino de estado de nivel de test..............................................107
Reporte de nivel de test............................................................................108
Reporte maestro de test (MTR).................................................................108
UML................................................................................................................. 109
UML y los modelos....................................................................................... 110
El modelo de test de UML............................................................................ 111
TEST MANGER................................................................................................. 114
Que es el test manager................................................................................ 114
Actividades del Test Manager.......................................................................115
Planning.................................................................................................... 115
Execution.................................................................................................. 117
Page 5
201
2
Results and analysis................................................................................. 117

ROBOT............................................................................................................ 119
Que es Robot............................................................................................... 119
Utilizacin de Robot con otros productos Rational.......................................119
Funcionamiento de Robot............................................................................ 120
Scripts....................................................................................................... 120
Verification Points..................................................................................... 120
Test Object Maps....................................................................................... 120
GUI Scripts................................................................................................ 120
Aplicaciones para Testing..........................................................................121
Mapeo de objetos conocidos y no conocidos............................................121
Puntos de verificacin............................................................................... 121
Timers....................................................................................................... 121
Comentarios y mensajes de Log...............................................................122
Seleccin del objeto a testear...................................................................122
Seleccin de mtodos de verificacin.......................................................122
Seleccin de mtodos de identificacin....................................................122
Scripts manuales...................................................................................... 123
Shell scripts.............................................................................................. 123
Editar, compilar y depurar Scripts............................................................123
Ejecucin de GUI Scripts...........................................................................123
Grabacin de sesiones.............................................................................. 124
Dividir la sesin en mltiples scripts.........................................................126
Importar y exportar sesiones....................................................................126
Regeneracin de scripts de una sesin.....................................................126
Definir las propiedades de un script.........................................................126
Regrabar sesiones.................................................................................... 127
Opciones de ejecucin de GUI scripts.......................................................127
Resultados de la ejecucin en el log de Test Manager..............................127
Datapools................................................................................................. 128
Data Tests................................................................................................. 128
Page 6
201
2
Robot y el ciclo de vida del software.........................................................128

Comparacin entre los modelos......................................................................130
CONCLUSIONES............................................................................................... 133
Bibliografa...................................................................................................... 135
Page 7
201
2
Introduccin
Un aspecto clave de la ingeniera de software es el aseguramiento de la
calidad. Dentro del ciclo de vida del software existe la etapa de testeo, la cual
no pocas veces corre el riesgo de ser minimizada debido a los escasos tiempos,
y la creencia de que otras etapas del proceso son ms importantes. Esto suele
llevar a elevadas cantidades de re-trabajo e insatisfaccin de parte del
cliente.
Adems de la etapa propia de pruebas de los programas, existen normativas y
estndares de calidad, tales como normas ISO o el modelo de CMMI, los cuales
apuntan a una mejora de la calidad revisando el proceso completo de
ingeniera de software. Es decir, no solo revisando con pruebas el producto
final, sino teniendo revisiones y estndares establecidos para cada etapa del
proceso, ya que cada una de ellas ser determinante para que el producto final
sea no slo de calidad, sino que represente realmente lo que el cliente deseaba
y cubra sus necesidades.
El presente proyecto de trabajo de grado propone:
Describir las caractersticas ms relevantes del testing de

software.
Conocer el estado del arte en las normas de calidad y estndares
vigentes de aseguramiento de la calidad del software.
Resaltar la importancia de la calidad de cada una de las etapas de
ingeniera de software para la generacin de un producto final de
calidad.
La metodologa utilizada para alcanzar estos objetivos ser la descripcin de

los mtodos clsicos de testing de software dentro del ciclo de vida de
desarrollo, de las normativas para los ciclos de vida de desarrollo de software
establecidas en la norma de la IEEE, ISO/IEC1227, del modelo CMMI para
desarrollo, en el rea especfica de software, y del modelo de testing utilizado
por UML y por la norma IEEE 829.
Finalmente se realizar una comparacin de estos cuatro modelos, sealando
sus similitudes y diferencias fundamentales.
El principal aporte que pretende este trabajo es reafirmar la importancia de la
calidad de todo el proceso de ingeniera de software, con especial nfasis en
los procesos de verificacin y validacin del software, y del testing, verificacin
del programa ejecutable, para obtener un producto final de calidad, entregado
Page 8
201
2
en tiempo, con el presupuesto estimado, y que satisfaga las expectativas del

cliente.
Page 9
201
2
Las pruebas del software

Contrariamente a lo que la mayora de la gente puede pensar, PRUEBA de un
programa es un proceso en el cual se intenta encontrar errores al mismo.
Una prueba exitosa es aquella que encuentra un error, dado que este es el
nico modo en el cual se podr agregar valor al programa. Este valor agregado
es deseado ya que el proceso de prueba es un proceso costoso, del cual se
espera agregue valor al programa en cuestin.
En consecuencia, un caso de prueba exitoso debera ser aquel que descubre un
error, dado que resulta haber sido una valiosa inversin.
En general no es posible encontrar todos los errores de un programa, esto debe
ser tenido en cuenta al momento del diseo de las pruebas y de su ejecucin.
Principios de prueba
Hay ciertos principios que deben ser seguidos al realizar las pruebas de un
programa, que si bien al enunciarlos pueden parecer obvios, son
frecuentemente ignorados llevando as al fracaso del proceso de prueba:
- La definicin del resultado esperado a la salida del programa es una parte
integrante y necesaria del caso de prueba
- Un programador debe evitar probar su propio programa
- Una empresa de programacin no debera probar sus propios programas
- El resultado de cada prueba debe ser inspeccionado concienzudamente
- Los casos de prueba deben contener escenarios tanto de entradas vlidas y
esperadas como invlidas e inesperadas.
- Examinar un programa para ver que no hace lo que se supone debe hacer eso
solo la mitad, tambin debe comprobarse que el programa hace lo que debe
hacer.
- Los casos de prueba desechables deben ser evitados, de lo contrario cuando
el programa sea modificado podran incorporarse errores que no sean
detectados por las nuevas pruebas.
- Las pruebas deben ser planificadas, no se puede suponer que un programa no
contendr errores.
Page 10
201
2
- La probabilidad de encontrar errores adicionales en una seccin de programa

es proporcional a la cantidad ya encontrada en la misma seccin
- Las pruebas constituyen una tarea altamente creativa y desafiante 1
Cuando un plan de pruebas no es realizado en forma completa se incurre en la
llamada deuda de testing, la cual forma parte de las ahora llamadas deudas
tcnicas. Si parte del sistema no se somete a todas las pruebas pretendidas,
hay riesgo de que queden algunos defectos remanentes, que de otro modo
hubieran sido detectados. Lo mismo sucede en otras reas como los
documentos requerimientos, los artefactos de diseo tcnico, etc., la falta de
los cuales puede provocar problemas de arquitectura as como tambin de
actualizacin y completitud. 2
Testing es una actividad compleja, que cuando se realiza apropiadamente
emplea muchas herramientas y enfoques diferentes. Debe ser planificado y
ejecutado exitosamente, en los diferentes niveles: unidad, integracin,
aceptacin, para as probar que el sistema funciona apropiadamente antes de
ser implementado.
Un testing completo y significativo debe tambin tratar de emular el ambiente
operacional en el cual el sistema ser implementado. Un testing exhaustivo
debe tratar de romper el sistema, para que las consecuencias y
comportamiento probable del sistema puedan ser entendidos.
Los problemas no descubiertos seguirn presentes en el sistema y sobrevivirn
y se multiplicarn a travs de las diferentes fases del desarrollo, y en ltima
instancia sern encontradas demasiado tarde en el desarrollo, o por los
usuarios despus de la implementacin, teniendo as el mayor de los impactos
y siendo los ms caros de solucionar.3
1 Vid Myers, Glenford J., El arte de probar el software, El Ateneo, 1984, pp. 5-17
2 Brown, N., Cai, Y., Guo, Y., Kazman, R., Kim, M., Kruchten, P, Lim, E,
MacCormack, Nord, R., Ozkaya, I., Sangwan, R, Seaman, C, Sullivan, K.,
Zazworka, N.; Managing Technical Debt in Software-Reliant Systems, 2011.
3 Vid. Acquisition Archetypes: Happy Path Testing, 2009
Page 11
201
2
Mtodos de prueba: Verificacin y Validacin

Los diferentes autores consultados no concuerdan en una definicin unificada
respecto de las definiciones de verificacin y validacin y sus lmites.
A los fines de este trabajo definiremos verificacin como aqullas actividades
que pertenecen al ciclo de vida de las pruebas y son exmenes humanos. El
objetivo en cada una de ellas es detectar la mayor cantidad posible de errores.
Las verificaciones deben ser lo ms completas posible, ya que es una de las
formas ms seguras y efectivas vas para la mejora de la calidad. La
verificacin se realiza cuando el cdigo ejecutable ya est disponible, testing
es la verificacin del cdigo ejecutable.
La validacin es el proceso de evaluar un sistema o componente durante o al
final del desarrollo para determinar si satisface los requerimientos
especificados. La validacin no debe ser hecha por la persona u organizacin lo
desarrollo.4 A los fines de este trabajo limitaremos la definicin de validacin a
aquellas actividades que se realizan antes de que el cdigo ejecutable est
disponible. Se aplica a las actividades de gestin de proyectos, anlisis de
requerimientos, diseo de software.
Validacin
Los procesos de validacin deben abarcar pruebas tanto para determinar si el
producto satisface los requerimientos del usuario as como tambin otras para
determinar si el comportamiento del producto
se corresponde con el
comportamiento deseado, descripto en la especificacin funcional.
La validacin de requerimientos es la que tiene el mayor potencial de ahorrar
esfuerzos de desarrollo: puede detectar muchas deficiencias que de otro modo
no sern encontradas hasta una etapa muy avanzada del desarrollo, donde el
costo de correccin es mucho ms alto. Adems la etapa de definicin de
requerimientos es en la cual ms del 50% de los defectos son introducidos. Si
en esta etapa las revisiones se hacen de una forma correcta los beneficios
sern muy altos ahorrando gran cantidad de esfuerzo y dinero en etapas
posteriores.
4 Vid Kit, Edward, Software Testing in the real world, ACM Press, 1995, p.57.
Page 12
201
2
Durante la etapa de aceptacin la validacin toma la forma de testing

operacional y de aceptacin. Es la determinacin de que el producto provee al
cliente con las capacidades necesarias para realizar su trabajo en forma
efectiva, esto significa que las capacidades requeridas corresponden con lo que
el cliente realmente necesita al momento de terminacin. La evaluacin puede
fallar si las necesidades del cliente fueron incomprendidas, o si fueron
especificadas incorrectamente; este tipo de fallas son menos probables si
usuarios representativos han sido consultados durante el desarrollo del
producto. Alternativamente puede haber fallas en la validacin si el
desarrollados no comprendi las necesidades del cliente al serle comunicadas.
Este tipo de fallas no deberan ser encontradas durante la aceptacin del
producto, si durante el desarrollo se realizaron revisiones apropiadas de los
requerimientos y del diseo, dirigidas reflejando las necesidades del cliente. 5
Verificacin
Dentro de la verificacin del cdigo (testing) se incluyen diferentes clases de
revisiones: inspecciones, recorridas de cdigo, revisiones tcnicas y otros
mtodos. El evento central para estos mtodos es una reunin en la cual los
defectos del producto son descubiertos y conversados.
Las actividades de verificacin son implementadas en un orden en que el
tamao del producto, su nivel de detalle, y el costo de verificacin van
creciendo, mientras que la potencial rentabilidad disminuye.
En la etapa de testing, como sucede en todas sus actividades, la verificacin
no puede ser exhaustiva, por lo cual es recomendable combinar diferentes
mtodos de verificacin y detectar partes crticas del cdigo para en ellos
realizar una inspeccin ms profunda.
La verificacin es casi siempre ms efectiva que la validacin, inclusive puede
encontrar defectos que en la etapa de validacin son prcticamente imposibles
de detectar, pero lo ms importante es que permite encontrar los defectos
mucho antes.
Una herramienta fundamental en las actividades de verificacin son las listas
de verificacin. Ejemplos de estas listas son las listas de verificacin para
requerimientos, para los diseos funcionales, para el diseo tcnico, para
cdigo en general y para lenguajes en particular.
5 Vid Grady H. Campbell, Jr., Harry Levinson, Richard Librizzi, An Acquisition
Perspective on Product Evaluation, 2011.
Page 13
201
2
Las listas de verificacin son una parte muy importante en las pruebas, deben
reflejar el enfoque elegido y el grado de madurez de nuestras verificaciones. 6
Pruebas humanas: recorridas y revisiones de programa
Las pruebas humanas, es decir la lectura de los programas por parte de gente
son un procedimiento efectivo para la deteccin de errores y deben ser
empleadas en todo proyecto de programacin.
El proceso de inspecciones y recorridas es llevado a cabo por tres o cuatro
personas, una de las cuales es la autora del programa, de este modo el
programa es probado por esencialmente por personas que no lo disearon.
Este tipo de pruebas resulta muy til en la deteccin de grupos de errores, los
costos de correccin son menores, dado que la naturaleza del error est bien
definida, y est probado que son eficaces para encontrar entre el 30 y el 70%
de los errores de codificacin y de lgica en programas tpicos. Estos procesos
son de gran valor para las pruebas de programas nuevos as como para
modificaciones.
Se denomina inspeccin a un conjunto de procedimientos y tcnicas para la
lectura de programas efectuada por un grupo de personas. El grupo consta de
un moderador, quien debe ser un programador experto; el programador; el
diseador del programa, quien podra ser el mismo que el programador; y un
experto en pruebas.
El procedimiento es el siguiente: das antes de la inspeccin los miembros del
equipo reciben una copia del cdigo para poder familiarizarse con l. Durante
la inspeccin el programador debe ir describiendo sentencia por sentencia la
lgica del programa, y se le van haciendo preguntas para determinar si existen
errores. En general el mismo programador es quien encuentra la mayor
cantidad de errores. El programa es analizado por medio de una lista ayuda
memoria, que incluye frecuentes errores.
El programador realizara la correccin de los errores despus de la sesin de
inspeccin.
Para la sesin de inspeccin es importante contar con tiempo y lugar
adecuados para evitar interrupciones del exterior. El lapso ptimo vara ente 90
y 120 minutos, dado que es requerido un considerable esfuerzo mental.
Las recorridas tambin consisten en la lectura del programa aplicando
procedimientos y tcnicas de deteccin de errores, pero en una forma
diferente.
6 Vid. Kit, Edward, op. cit. pp. 57-76.
Page 14
201
2
El grupo est formado por tres, cuatro o cinco personas. Una tendr un papel
similar al del moderador, otra har las veces de secretaria para tomar nota de
los errores encontrados, y una tercera persona tendr el rol de probador.
Al igual que en el caso anterior los participantes debern familiarizarse con el
cdigo unos das, antes. Sin embargo el procedimiento durante la reunin el
distinto: En este caso los participantes desempearan el rol de la computadora,
el probador contara un conjunto de casos de prueba representativos a ser
ejecutados. Estos, siendo simples y pocos debido a la diferencia de velocidad
de ejecucin existente entre una computadora y una persona,
sern
ejecutados mentalmente uno a uno, y el estado del programa ira siendo
registrado en un papel o pizarra. Los casos de prueba no juegan en s mismos
un rol crtico, sino que son un disparador para cuestionar al programador la
lgica y suposiciones utilizadas, de este modo es como se encuentran la mayor
cantidad de errores.
El tercer proceso humano de deteccin de errores son las pruebas de escritorio,
similares a las inspecciones o recorridas pero realizadas por una sola persona,
quien lee el programa, chequea una lista posible de errores y ejecuta la lgica
de casos de prueba a travs de l.
Un ltimo proceso humano de revisin de programas son las autoevaluaciones
comparativas, que no se encargan de probar los programas sino de una
evaluacin annima sobre la calidad general del programa, la facilidad de
mantenimiento y claridad.7
Cobertura de las pruebas
La cobertura de las pruebas abarca tanto los requerimientos, la funcionalidad
como la lgica. IEEE/ANSI destaca claramente la importancia de las dos
primeras, sin embargo la cobertura de la lgica tambin es muy importante ya
que indirectamente mejora la cobertura de funcionalidad y porque es necesaria
para probar secuencias lgicas que podran no ser discernibles desde la
funcionalidad externa.
Hay dos cosas esenciales para las pruebas de validez: la definicin de
resultados y la repetitividad. Myers dijo El ojo ve lo que quiere ver. Por esto
es importante que los resultados esperados en un caso de prueba estn
definidos previamente a la ejecucin del mismo, as como que el caso de
prueba arroje resultados consistentes cada vez que se lo ejecute con las
mismas configuraciones de software y hardware. Cuando los resultados reales
difieren de los resultados esperados la falla debe ser recreada para debugging.
7 Vid Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 19-36
Page 15
201
2
Las actividades de verificacin se dividen de la siguiente forma:

Actividades de bajo nivel: comprende las pruebas de componentes individuales
del programa, uno por vez o en combinacin. Requiere un conocimiento alto de
la estructura interna del programa y su ejecucin es ms apropiada para los
desarrolladores. Comprenden:
-
Test de unidad (modulo)

Test de integracin
Actividades de alto nivel: comprende las pruebas del producto en su totalidad.

Por cuestiones de objetividad es ms apropiada la ejecucin de las mismas
fuera de la organizacin de desarrollo, usualmente por un grupo independiente
de testeo. Comprenden:
-
Test
Test
Test
Test
de
de
de
de
usabilidad
funcionalidad
sistema
aceptacin8
Caja negra y caja blanca

Dentro de las estrategias de verificacin se encuentran las pruebas de caja
negra y las pruebas de caja blanca. Como las pruebas exhaustivas no son
posibles es muy importante encontrar un subconjunto de casos de prueba que
contengan la ms alta probabilidad de detectar la mayor cantidad de errores.
Pruebas tipo caja negra

Una forma de probar un programa es la denominada caja negra, es decir, el
programa se toma como una caja negra, que recibe datos y devuelve datos.
Los datos de entrada se seleccionan en base a las especificaciones dadas, y los
datos de salida se analizan a la luz de estas mismas, esperando encontrar
casos en los cuales el programa no se comporte segn lo esperado.
Segn esta forma de probar los programas, si se quisiera encontrar todos los
errores del programa se debera realizar una prueba exhaustiva de entrada de
datos, es decir todas las condiciones posibles, lo cual en algunas circunstancias
podran ser virtualmente infinitas.
Dado que esto no es posible, podemos concluir, como decamos antes, que no
se puede garantizar que un programa est libre de errores, y que un factor
fundamental en la prueba de programas es la economa, es decir, maximizar el
8 Vid. Kit, Edward, op. cit. pp. 77-108

Page 16
201
2
rendimiento de la inversin de las pruebas, encontrar la mayor cantidad de

errores posibles con la menor cantidad de pruebas. 9
Pruebas tipo caja blanca:

Las pruebas de caja blanca permiten analizar la estructura interna del
programa, con lo cual los datos de prueba se pueden obtener a partir del
examen de la lgica del programa. Esto puede ser considerado como una
estrategia anloga a la prueba exhaustiva en las pruebas de caja negra.
El problema con esta estrategia es, por un lado, que muchas veces se focaliza
en que todas las sentencias del programa sean ejecutadas, sin tener en cuenta
la especificacin, lo cual podra producir un programa que funciona bien pero
no es el requerido, o un programa que realiza parte de lo requerido, pero con
secuencias faltantes. Tambin habra que tener en cuenta que las secuencias
lgicas dentro del programa pueden producir una cantidad tan grande de
combinaciones de sentencias que podra ser imposible de probar. En tercer
lugar existe el problema de la sensibilidad de datos: poda haber sentencias
que resultan ser correctas con ciertos datos de entrada, pero que con otros
resultan errneas, haciendo que la deteccin del error dependa de los datos de
entrada, no de la ejecucin misma de la sentencia.
Como podemos ver, si bien una prueba exhaustiva de entrada podra resultar
superior a una prueba exhaustiva de secuencia, ninguna de las dos resulta til,
dado que son impracticables.10
Diseo de los casos de prueba11
Dadas las limitaciones existentes en tiempo, recursos, costos, la cuestin clave
en referencia a las pruebas es: cul es el subconjunto de casos de prueba que
tiene la mayor probabilidad de detectar el mayor nmero posible de errores?
Para esto existen una serie de metodologas de diseo de caso de prueba.
Siendo la ms pobre la metodologa que elige los datos de prueba al azar, hay
otras consideraciones a tener en cuenta que pueden ayudar a detectar un
conjunto de datos de prueba inteligente.
Page 17
201
2
Es posible realizar una prueba rigurosa cambiando ciertas metodologas

aplicables a las pruebas de caja negra, junto con otras de caja blanca, los
cuales listaremos brevemente.
Para realizar una prueba rigurosa es recomendable utilizar varios de estos
mtodos, o quizs todos, dado que cada uno de ellos tiene ciertas fortalezas y
debilidades particulares.
Para el diseo de los casos de prueba debe disponerse tanto de la
especificacin sobre lo que el modulo debe hacer y su cdigo fuente.
Estas pruebas estarn fuertemente orientadas hacia las metodologas de caja
blanca, dado que cuanto mayor sea la entidad con que se trabaja esto se
tornara ms difcil, debiendo requerir as a las pruebas de caja negra, mas
orientadas a las fallas respecto de los requerimientos que a la lgica en s.
Mtodos de caja negra:

Particiones de equivalencia: Se identifican clases de equivalencia (valores
representativos de otros valores) y se definen los casos de prueba basados en
ellos.
Anlisis de valores lmite: prueba de situaciones directamente arriba o debajo
de los mrgenes de las clases de equivalencia de entrada y salida
Grficos causa-efecto: tcnica sistemtica de seleccin de casos de prueba
para comprender las diferentes combinaciones de circunstancias de entrada
Conjetura de errores: proceso intuitivo de enumeracin de posibles casos de
error para escribir los casos de prueba
Mtodos de caja blanca:

Cobertura de sentencias: cada sentencia debe ser ejecutada al menos una vez
(criterio dbil)
Cobertura de decisiones: casos de prueba que cada decisin tenga al menos
una vez un resultado verdadero y uno falso
Cobertura de condiciones: cada condicin en una decisin debe tener todos los
valores posibles al menos una vez
Page 18
201
2
Cobertura de decisiones/condiciones: cada condicin en una decisin debe

tener todas las posibles salidas y cada punto de entrada debe ser activado por
lo menos una vez
Cobertura de condicin mltiple: todas las combinaciones posibles de
resultados de condicin en cada decisin y todos los puntos de entrada se
invocan por lo menos una vez
Un conjunto de casos de prueba que satisface las necesidades de condicin
mltiple satisface tambin las de cobertura de decisin, condicin y
decisin/condicin.
Todas estas metodologas deben ser combinadas en una estrategia general, ya
que cada una contribuye con un conjunto particular de casos de prueba pero
ninguna por s misma es un conjunto perfectamente abarcativo de la totalidad.
Prueba por mdulos12
Cuando los programas son grandes (500 sentencias o ms) requieren
tratamientos especiales para la ejecucin de las pruebas, por ejemplo una
estructuracin de la prueba por mdulos.
En lugar de realizar la prueba del programa como un todo, se divide y se
concentra individualmente en los bloques ms pequeos. De este modo es ms
fcil poder manejar las posibles combinaciones de datos de prueba, se facilita
la localizacin y correccin de errores y posibilita cierto paralelismo en las
pruebas de los diferentes mdulos.
Es importante tanto contar con un set efectivo de casos de prueba como
analizar la mejor forma de combinar los distintos mdulos para constituir un
programa funcional.
Un programa podra as probarse modulo a modulo para luego hacer una
prueba con todos los mdulos combinados (prueba no incremental o big
bang), o podra probarse un mdulo y luego ir combinando uno a uno los
mdulos siguientes con los previamente probados (prueba incremental).
Las pruebas no incrementales requieren mayor trabajo, dado que es necesaria
la creacin de una mayor cantidad de mdulos impulsores (modulo creado
especialmente para transmitir los datos de prueba del mdulo que est siendo
creado), mientras que en las pruebas incrementales los mdulos ya probados
pueden ser utilizados.

Page 19
201
2
Con las pruebas incrementales los errores relacionados con la falta de

adaptacin de las diferentes interfaces pueden ser detectados antes, tambin
se obtiene una prueba ms profunda del programa dado que la prueba
combinada de los mdulos podra llevar a la prueba de una nueva condicin
antes no probada encontrando un error previamente pasado por alto.
Sin embargo con las pruebas no incrementales existen ms posibilidades de
paralelizar las pruebas de los mdulos, lo cual podra tener un impacto
importantes en proyectos grandes.
Todo esto parece sugerir que las pruebas incrementales son superiores a las
pruebas no incrementales.
Dentro de las pruebas incrementales existen dos estrategias, la ascendente y
la descendente.
La estrategia descendente comienza con la prueba del mdulo inicial del
programa, luego, para que un mdulo pueda convertirse en el siguiente
modulo a ser probado, debe cumplir con la condicin de que previamente se
haya probado por lo menos uno de los mdulos correspondientes al mdulo
superior. Para este tipo de pruebas se requiere la creacin de mdulos
auxiliares simulando el correspondiente modulo subsiguiente.
En este punto podran tambin realizarse pruebas en paralelo, con las
diferentes combinaciones de mdulos subsiguientes.
De haber secciones crticas en el programa es recomendable que sean
agregadas lo antes posible a las secuencias de prueba. Tambin es importante
que los mdulos de entradas y salida sean incorporados a las pruebas lo ms
pronto posible.
En el caso de la estrategia ascendente se comienza por los mdulos finales del
programa, aquellos que no llaman a otros, para continuar con los del nivel
superior una vez que todos los mdulos del nivel subordinado hayan sido
probados. Para estas pruebas se requiere la creacin de mdulos impulsores,
los cuales son ms fciles de escribir que los mdulos auxiliares. Un
inconveniente de esta estrategia es que no existe una estructura previa del
programa, y el programa operativo no existe hasta que se incorpora el ultimo
modulo, resultando as la estructura del programa completo.
Page 20
201
2
Pruebas de nivel superior

Una vez que se terminan de realizar las pruebas por mdulos, es el momento
de probar el programa en su totalidad, lo cual significa el verdadero momento
de prueba: hace el programa lo que el usuario espera que haga?
Los enfoques de pruebas de nivel superior sirven tanto para los programas
tradicionales, modularizados y con componentes, como para las nuevas
estrategias de arquitectura, por ejemplo la arquitectura orientada a servicios
(SOA): las pruebas, en todos estos casos, tienen que abordar la funcionalidad, y
verificar que sta est completa y correcta. 13
La mayora de los errores es atribuible a errores en la comunicacin entre las
diferentes etapas de comunicacin y traduccin de la informacin.
Para evitar estos errores es posible:
1) introducir ms precisin en el proceso de desarrollo,
2) introducir al final de cada proceso una etapa de verificacin, para evitar que
los errores producidos en esa etapa pasen a la siguiente
3) orientar distintos procesos de prueba hacia distintos procesos de desarrollo,
como por ejemplo las pruebas de funcin, pruebas de sistemas, pruebas de
instalacin, pruebas de aceptacin, etc. 14
Las pruebas de integracin y de aceptacin pueden tomar meses y pueden
tener que ser realizadas de nuevo en forma completa cuando se realizan
cambios, causando indeseables retrasos. Para realizar este proceso de manera
ms eficiente y efectiva se deben responder algunas preguntas bsicas tales
como:
-
Que actividades proveen el mayor aumento en confianza justificada de

que el sistema se comportar aceptablemente?
Puede alguna actividad recortarse sin disminuir esta confianza
justificada en el comportamiento del sistema? Es decir: es razonable
detener las pruebas de un sistema, y por qu?
Qu visin dan las actividades sobre el riesgo residual que est presente
en el sistema desarrollado?
Qu evidencia es ms probatoria para decidir si un sistema debe ser
liberado o no?
13 Vid Ed Morris, William Anderson, Sriram Bala, David Carney, John Morley,
Patrick Place, Soumya Simanta; Testing in Service-Oriented Environments
Page 21
201
2
Cul es una base de principios tericos para afirmar que hay confianza
suficiente en el comportamiento del software?
Que tipos de justificaciones son ms o menos aceptables?
Est bien justificado un nivel de confianza propuesto, por principios y
teoras slidas?
Las respuestas adecuadas a estas preguntas y a otras similares suelen no

existir, aunque stas aplican a todo tipo de software, y se vuelven cada da
ms importantes, debido a la complejidad creciente de los sistemas. 15
Planeamiento y control de las pruebas
El mayor error cometido al planear un proceso de prueba es la suposicin de
que no se encontraran errores al programa, llevando a que los recursos
estimados sean subestimados. Esto se debe a que el proceso de prueba se
efecta al final del desarrollo, no pudiendo ya cambiar la cantidad de recursos
estimados. Por otro lado se puede ver que la forma en que se plantean las
pruebas ya viene orientada por una definicin errnea de ellas: difcilmente el
objetivo planteado sea encontrar errores. 16
Terminacin de las pruebas

Habitualmente se da por terminada la etapa de pruebas cuando el tiempo se
agota o cuando se han ejecutado todos los casos de prueba sin errores. Esta es
una visin equivocada.
Es necesario basar el final de las pruebas en criterios de mayor utilidad. Una
forma seria basar la terminacin en el uso de mtodos especficos de diseo de
casos de prueba. Tambin podra basarse en la deteccin de un nmero
predefinido de errores, siendo aqu el problema como determinar el nmero de
errores a encontrar. Un tercer criterio podra ser realizar un grfico para
representar os errores encontrados por cantidad de tiempo, analizando la curva
se podr determinar si conviene seguir con esta fase de prueba o si ya se
debera para a la siguiente.
Probablemente lo mejor para determinar la finalizacin de las pruebas es una
combinacin de estas tres metodologas. 17
15 Vid John Goodenough; Linda Northrop , Software Assurance for Systems of

Systems, 2011
Page 22
201
2
La confiabilidad es el grado en que un sistema satisface sus propietarios y

usuarios de las expectativas, por lo tanto es especfica del sistema y de la
misin.
La confianza debe ser basada en la evidencia y nunca absoluta. La confianza
justificada es imposible sin pruebas. La evidencia puede tomar muchas formas,
pero en ltima instancia, depende de las observaciones del rendimiento
histrico o la calidad de los resultados para los diseadores, implementadores
y usuarios de los productos o servicios en los que se desea confiar. Las
pruebas, la validacin y certificacin son procesos que pueden aportar pruebas
de confiabilidad.18
Debugging
Debugging de un programa es la tarea que debe ser realizada despus de la
ejecucin de un caso de prueba exitoso: al detectarse un error se debe primero
determinar su naturaleza y ubicacin dentro del programa, para luego pasar a
la correccin del mismo.
El debugging puede ser realizado mediante diferentes mtodos.
El mtodo de fuerza bruta es usualmente el ms utilizado y consiste en
recorrer de diferentes formas el cdigo, analizando los valores que las variables
van tomando, para as eventualmente detectar la causa del error. El problema
con estos mtodos es que habitualmente no tienen en cuenta el proceso de
pensamiento.
El mtodo de induccin supone que en muchos casos los errores pueden
encontrarse mediante un cuidadoso raciocinio, utilizando pistas y relaciones,
sin necesidad de utilizar la computadora.
El proceso de deduccin consiste en partir de ciertas premisas, utilizar
procesos de eliminacin y clasificacin, llegando as a una conclusin la cual
detecta el error.
El debugging por rastreo hacia atrs consiste en recorrer la lgica del programa
hacia atrs, hasta encontrar un punto donde esta se desva de lo que es
correcto.
Por ltimo, el debugging por medio de casos de prueba consiste en la
utilizacin de casos de prueba especiales, donde el propsito es obtener
17 Vid. Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 123-129
18 Vid. David A. Fisher, Principles of Trust for Embedded Systems, 2012
Page 23
201
2
informacin til para la ubicacin del error, tratando de cubrir con ellos una
condicin nica, o al menos pocas. Este mtodo se utiliza asociado al mtodo
de induccin o al de deduccin.
Es importante tambin tener en cuenta que el debugging, adems de una
herramienta valiosa para la eliminacin de errores, puede servir para analizar
en detalle los errores detectados, y as ser retroalimentacin que tambin
ayude a mejorar el diseo y los futuros procesos de prueba. Esto podra ser una
tarea difcil y costosa, sin embargo con este tipo de anlisis la calidad de los
programas podra mejorar notablemente.19
Sandboxes
Tambin relacionado con el testing, est la utilizacin de los llamados
sandboxes (areneros), sistemas exclusivamente de prueba que se utilizan
tanto para ejecutar aplicaciones como para hacer pruebas de cdigo y
configuraciones. Se han utilizado mucho en actividades de testing de
mantenimiento, proveyendo un rea segura para probar ideas nuevas y cdigo.
Otra utilizacin ms relevante de los sandboxes es la relacionada con las reas
de seguridad, proveyendo un ambiente virtual para correr aplicaciones que no
han sido probadas. Habitualmente tienen acceso limitado a los recursos,
informacin, redes y dispositivos de entrada y salida. 20
Control de los costos

De tener recursos ilimitados se podran ejecutar todas las pruebas deseadas,
sin embargo estamos habitualmente cortos no solo de dinero sino tambin de
tiempo.
Es importante por eso tener definido un conjunto de entregables para las
pruebas. El objetivo de esto es maximizar el potencial de deteccin de errores
y minimizar la cantidad de pruebas requeridas, para as tambin poder
controlar los costos. 21

20 Vid. Zacharie Hall Rick Kazman, Daniel Plakosh, Joseph Giampapa,Kurt
Wallnau; Edge Enabled Systems, 2010
Page 24
201
2
Tareas para las pruebas, entregables y cronologa

Las pruebas efectivas son planificadas: requieren un enfoque metodolgico,
que abarca disciplina, estructura, y medidas.
Cada actividad de testing tiene una o ms entradas y consiste en una o ms
tareas. Cada tarea produce uno o ms entregables.
Cada tarea y entregable es mapeado en fases especificas del ciclo de vida del
programa mostrando su tiempo relativo y su superposicin.
El tiempo y los recursos casi siempre limitan las pruebas que en realidad se
pueden hacer: es importante establecer prioridades basadas en el riesgo.
Que mtodos se utilizaran, que tipo de automatizacin, con qu presupuesto se
cuenta, que programas de soporte y entrenamiento se necesita, como se
realizara la gestin de la configuracin son partes esenciales en la planificacin
de las pruebas de validacin.
Se debe generar un plan maestro de validacin, para todo el conjunto de los
esfuerzos de las pruebas, y tambin se deben generar uno o ms planes
detallados, para cada actividad de validacin: en l se detallara
especficamente como esta validacin ser ejecutada, que cosas entran dentro
de las pruebas y que cosas sern dejadas afuera.
Los entregables ms importantes de la ejecucin de las pruebas son los logs de
las pruebas, los reportes de incidentes, y el reporte de cobertura de lgica. 22
Las organizaciones y los mtodos de pruebas

Una organizacin de pruebas (test group) es un recurso o conjunto de recursos
dedicados a realizar actividades de test.
El gerenciamiento de las pruebas es difcil: se debe tener habilidad para
entender y evaluar el proceso de pruebas de un programa, los estndares, las
polticas, las herramientas, los entrenamientos y las medidas. Se debe tener
capacidad para mantener a la organizacin de pruebas fuerte e independiente.
Se debe poder reclutar y retener profesionales excepcionales. Y, en definitiva,
se debe contar con el tiempo necesario para manejar y dar el cuidado
necesario a los grupos de test.
Page 25
201
2
Los riesgos de tener una estructura de testing equivocada incluyen: debilitar la

independencia y formalidad de las pruebas; que la gente de testing no tenga
participacin en los programas de recompensa; que el rea de testing se
convierta en un rea con poco personal; o en un rea con personal no
capacitado, junior; que gente con poca experiencia maneje el rea de testing;
que no haya una nivelacin en cuanto a los conocimientos de testing, las
herramientas, los procesos; que testing no tenga la capacidad de frenar
entregas de productos de pobre calidad; que falte el foco en la mejora
continua; que el management no tenga capacidad para manejar a los grupos
de testing; que el foco en la calidad no sea enfatizado; y que los gerentes se
desmoralicen debido a la falta de crecimiento de carrera.
Todo esto debera ser tenido
modificaciones en la organizacin.
en
cuenta
al
momento
de
planificar
Hay siete enfoques distintos para la organizacin de las pruebas, los cuales
reflejan la evolucin de la madurez de una organizacin de desarrollo.
1. Testing es responsabilidad de cada persona: es lo que habitualmente
ocurre en el mundo real. Este enfoque se viola un principio bsico, de
que las pruebas deben ser realizadas en forma independiente. Probar el
programa creado impide al desarrollador encontrar sus propios errores,
es propio de la naturaleza humana.
2. Testing es responsabilidad de cada unidad: este enfoque resuelve el
problema del primero, sin embargo el problema es ahora para las
personas encontrar el tiempo de comprender el trabajo de testing tan
bien como comprenden el de desarrollo, con sus procesos, estndares,
polticas, herramientas, entrenamientos, mtricas, etc.
3. Testing realizado por un recurso dedicado: este enfoque resuelve el
problema de mltiples tareas para los desarrolladores, seleccionando
uno en particular y dndole la tarea de probar software. Sin embargo en
este caso el gerente a cargo de esta persona en quien es asignado a
mltiples tareas, debiendo dar ahora soporte no solo a los
desarrolladores sino tambin a este nuevo rol que es parte de su equipo.
Esto es altamente improbable, por esto es que se vuelve claro que algn
tipo de grupo de test independiente es necesario, para coordinar las
actividades y dar a estas una dedicacin full time.
4. Nueva organizacin de pruebas en QA: una solucin comn es crear la
nueva organizacin como un componente de Quality Assurance. Sin
embargo el gerente de QA puede no entender el proceso de pruebas de
sistemas, y la gente empieza a preguntarse quien realmente es el
responsable por la calidad.
Page 26
201
2
5. La organizacin de test est en el sector de desarrollo: para resolver el

problema del enfoque anterior se crea una organizacin de test dentro
de la organizacin de desarrollo. En este caso el problema es que esta
organizacin habitualmente queda bajo el mando de un gerente que
ahora no solo es responsable por el desarrollo sino tambin por calidad,
lo que no es su principal objetivos. A su vez, cuando el grupo de calidad
va creciendo no es claro si debe ser un grupo centralizado o varios
descentralizados.
6. Organizacin de test centralizada: este enfoque resuelve el problema
anterior, una organizacin de test centralizada, que vive dentro del rea
de desarrollo y le sirve. De este modo la organizacin de test tiene ms
posibilidades de mostrar su impacto dentro de la empresa, los testers
tienen su lugar, capacitacin, gua, los recursos pueden ser compartidos
de una mejor forma, y a su vez el rea de calidad pasa a ser un rea
potencial de hacer carrera para los gerentes de primera lnea.
7. Organizacin de test centralizada con centro tecnolgico de test: Los
problemas de consistencia del enfoque anterior se resuelven creando un
grupo tecnolgico de test. Con esto se podrn gerenciar los esfuerzos,
programas de entrenamiento, planificacin e implementacin de
programas de herramientas de test, la documentacin de los procesos,
estndares y polticas ser realizada de forma adecuada, y se podrn
realizar mediciones de los test. 23

Page 27
201
2
CMMI for development. CMMI para desarrollo24

Los modelos de CMMI (Capability Maturity Model Integration) son colecciones
de best practices (mejores prcticas) que ayudan a las organizaciones a
mejorar sus procesos. Estos modelos son desarrollados por equipos de
producto, integrados por miembros de la industria, del gobierno, y del Software
engineering institute (SEI).
El modelo que analizaremos, CMMI para desarrollo, provee un conjunto de
pautas exhaustivamente integradas para desarrollo de productos y servicios.
Mejorar los procesos

productos y servicios
para
desarrollar
mejores
Las compaas, ms que nunca, quieren entregar mejores, ms baratos

productos y servicios y en forma ms rpida. Al mismo tiempo los productos y
servicios son cada vez ms complejos, y se vuelve realmente complicado para
una sola organizacin desarrollar cada uno de los componentes que formaran
parte del complejo producto final. Comnmente, algunos productos son
fabricados internamente, y otros son adquiridos. Por esto es que las
organizaciones deben ser capaces de gestionar y controlar estos complejos
desarrollos y procesos de mantenimiento.
CMMI for development consiste en mejores prcticas que se dirigen a las
actividades de desarrollo aplicadas a los productos y servicios. Estas prcticas
cubren el ciclo de vida del producto desde su inicio, a travs de la entrega y el
mantenimiento.
CMMI-DEV se centra en las actividades de la organizacin que desarrolla el
producto: contiene 22 reas de proceso, 16 son principales, 1 es compartida, y
5 son especficas de desarrollo.
Las reas especficas de desarrollo se dirigen a los requerimientos de
desarrollo, la solucin tcnica, la integracin del producto, verificacin y
validacin.
El Software Engineering Instituto (SEI) ha encontrado en su investigacin para
ayudar a las organizaciones a mantener la calidad, varias dimensiones en las
que una organizacin se puede enfocar para mejorar el negocio.
24 Vid. CMMI for development, Version 1.3, November 2010

Page 28
201
2
Tres dimensiones crticas en la que una organizacin tpicamente se enfoca

son: personas, procedimientos y mtodos:
Lo que une todo es el proceso utilizado, el cual permite nivelar los recursos y
examinar las tendencias de negocios.
Capability Maturity Model es una representacin simplificada de la realidad,
que contiene elementos esenciales de procesos efectivos.
CMMI CMM Integracin, tal como otros modelos CMM, provee una gua a ser
utilizada al crear procesos, no son procesos o descripciones de procesos. Fue
creado para resolver el problema de utilizar mltiples modelos de CMM. La
combinacin de modelos seleccionados en un solo marco mejorado. El primer
modelo creado fue el CMMI para desarrollo, llamado en su momento solamente
CMMI. Actualmente el modelo ya se encuentra en su versin 1.3.
El siguiente grafico muestra los modelos que llevaron a esta versin:
Page 29
201
2
CMMI para desarrollo

CMMI para desarrollo es un modelo de referencia que cubre actividades
para desarrollar tanto productos como servicios. Organizaciones de
muchas industrias, incluidos aeroespacial, bancos, hardware, software,
defensa, fabricacin de automviles, y telecomunicaciones usan CMMI
para desarrollo.
CMMI para desarrollo contiene prcticas que cubren gestin de
proyectos, gestin del proceso, ingeniera de sistemas, ingeniera de
hardware, ingeniera de software, y otros procesos de soporte utilizados
en desarrollo y mantenimiento.
Page 30
201
2
Las reas de procesos

Los modelos de CMMI son producidos partiendo del marco de CMMI. Este marco
contiene todos los goles y prcticas que son utilizadas para producir modelos
CMMI que pertenecen a las constelaciones CMMI.
Todos los modelos CMMi contienen 16 reas principales de proceso, que cubren
los conceptos bsicos, fundamentales para la mejora de procesos en cualquier
rea de inters. Parte del material en las reas de proceso principales es el
mismo en todas las constelaciones, otro material puede ser ajustado para
algn rea especfica de inters, con lo cual el material puede no ser
exactamente el mismo.
Un rea de procesos es un grupo de prcticas relacionadas en un rea, las
cuales, implementadas colectivamente, satisfacen una serie de goles,
importantes para hacer una mejora en el rea.
Las 22 reas de proceso son:
1. Anlisis de Causa y Resolucin (CAR)
2. Gestin de la Configuracin (CM)
3. Anlisis de Decisiones y Resolucin (DAR)
4. Gestin de Proyectos integrada (IPM)
5. Medicin y Anlisis (MA)
6. Definicin del Proceso Organizacional (OPD)
7. Enfoque del Proceso Organizacional (OPF)
8. Gestin del Desempeo Organizacional (OPM)
9. Rendimiento del Proceso Organizacional (OPP)
10.Entrenamiento Organizacional (OT)
11.Integracin de productos (PI)
12.Monitoreo y Control de proyecto(PMC)
13.Planificacin de Proyectos (PP)
14.Aseguramiento de la Calidad del Proceso y del Producto (PPQA)
15.Gestin de Proyectos cuantitativa (QPM)
16.Desarrollo de Requerimientos (RD)
17.Gestin de Requerimientos (REQM)
18.Gestin de Riesgos (RSKM)
19.Gestin de Acuerdos de Proveedores (SAM)
20.Solucin Tcnica (TS)
21.Validacin (VAL)
22.Verificacin (VER)
Page 31
201
2
El modelo en su conjunto
CMMI-DEV no especifica que un proyecto u organizacin deba seguir un
determinado proceso o que cierta cantidad de productos deban ser elaborados
por da, o targets especficos de performance a ser alcanzados. El modelo
especifica que un proyecto u organizacin deben tener procesos que cumplan
con las prcticas de desarrollo relacionadas. Para determinar si estos procesos
estn en lugar, un proyecto u organizacin mapea sus procesos con las reas
de proceso del modelo. Este mapeo de procesos con reas de proceso permite
a la organizacin un seguimiento de sus procesos comparado con el modelo de
CMMI-DEV mientras actualiza o crea nuevos procesos.
Los niveles son utilizados en CMMI-DEV para describir una lnea de evolucin
recomendada para una organizacin que quiere mejorar los procesos que
utiliza para desarrollar productos o servicios.
CMMI soporta dos vas de mejora, utilizando niveles. Una permite a las
organizaciones mejorar incrementalmente los procesos que corresponden con
un rea de proceso individual. La otra permite a las organizaciones mejorar un
grupo de procesos relacionados al incrementar sucesivamente un grupo de
reas de proceso.
Estas dos vas de mejora son asociadas con los dos tipos de niveles: Niveles de
Capacidad y Niveles de Madurez. Estas dos representaciones son llamadas
continua y por etapas respectivamente.
Para alcanzar un nivel particular, una organizacin debe satisfacer todos los
goles de un rea de proceso, o conjunto de reas de proceso que estn
indicadas como objetivo de mejora, independientemente de si es un nivel de
capacidad o de madurez.
La representacin continua usa los niveles de capacidad para caracterizar el
estado de los procesos de la organizacin en relacin con un rea de proceso
individual.
Page 32
201
2
La representacin por niveles usa los niveles de madurez para caracterizar el

estado total de los procesos de la organizacin relacionados con el modelo en
su totalidad.
Page 33
201
2
Si bien estas dos imagines son muy similares, la representacin continua se

enfoca en la capacidad de las reas de proceso, medidas en niveles de
capacidad, y la representacin por niveles enfoca en la madurez general
medida en niveles de madurez. Estas dimensiones son utilizadas como punto
de referencia y para actividades de evaluacin, as como para guiar los
esfuerzos de mejora de una organizacin.
Los niveles de capacidad aplican a los logros de mejora del proceso de una
organizacin, en reas de proceso individuales. Son niveles para mejorar
incrementalmente los procesos correspondientes a un rea determinada. Los
cuatro niveles de capacidad estn numerados del 0 al 3.
Los niveles de madurez aplican a los logros de mejora del proceso de una
organizacin a traces de mltiples reas de proceso. Son niveles para mejorar
incrementalmente los procesos correspondientes a un grupo de reas de
proceso. Los cinco niveles de madurez estn numerados del 1 al 5.
Las diferencias son que no hay nivel de madurez 0, no hay niveles de
capacidad 4 y 5, y al nivel 1 los nombres utilizados son diferentes entre s.
Nivel
Nivel
Nivel
Nivel
Nivel
Nivel
0
1
2
3
4
Representacin
continua
Niveles de capacidad
Incompleto
Realizado
Gestionado
Definido
Nivel 5
Representacin
por
niveles
Niveles de madurez
Inicial
Gestionado
Definido
Cuantitativamente
Gestionado
Optimizado
La representacin continua se ocupa de seleccionar tanto un rea de proceso

particular a mejorar como del nivel de capacidad deseado para ese proceso. En
este contexto, si un proceso est realizado o incompleto es importante. Por eso
es que el nombre incompleto es dado al punto de inicio de la representacin
continua.
La representacin por niveles se ocupa de seleccionar mltiples reas de
procesos para mejorar dentro de un nivel de madurez, si los procesos
individuales estn realizados o incompletos no es el foco primario. Por eso el
nombre inicial es dado al punto de inicio de la representacin por niveles.
Page 34
201
2
Ambas representaciones proveen una forma de mejorar las procesos de una

organizacin y de medir cuan bien las organizaciones pueden mejorar y
mejoras sus procesos.
Niveles de capacidad
Un nivel de capacidad para un rea de proceso se alcanza cuando todos los
goles genricos son satisfechos hasta ese nivel. El hecho de que los niveles de
capacidad 2 y3 usen los mismos nombres que los goles genricos 2 y3 es
intencional, ya que cada uno de esos goles y prcticas genricos reflejan el
significado de los niveles de capacidad de los goles y prcticas.
Nivel de capacidad 0: Incompleto

In proceso incompleto es un proceso que no est siendo realizado o que se
realiza parcialmente.
Uno o ms de los goles especficos de las reas de proceso no estn
satisfechos y ningn gol genrico existe para este nivel, ya que no hay razn
para institucionalizar un proceso realizado parcialmente.
Nivel de capacidad 1: Realizado

Un proceso de nivel de capacidad 1 se caracteriza como un proceso realizado.
Un proceso realizado es aquel que cumple con el trabajo requerido para
producir productos de trabajo; los goles especficos del rea de proceso estn
satisfechos.
Aunque hay mejoras importantes en este nivel, estas mejoras pueden perderse
con el tiempo de no ser institucionalizada, lo que ayuda a asegurar que las
mejoras se mantengan.
Nivel de capacidad 2: Gestionado

Un proceso de nivel de capacidad 2 es un proceso gestionado. Este es un
proceso que est planificado y ejecutado de acuerdo con una poltica. Se
emplea gente con habilidades que tiene los recursos adecuados para producir
una salida controlada; involucra a las partes interesadas relevantes, es
monitoreado, controlado, y revisado, y es evaluado en su adhesin al proceso
descripto.
Page 35
201
2
La disciplina de procesos reflejada en el nivel 2 ayuda a asegurar que las

prcticas existentes son retenidas durante momentos de estrs.
Nivel de capacidad 3: Definido

Un proceso de nivel de capacidad 3 es un proceso definido. Este es un proceso
gestionado que es adaptado desde el set de procesos estndar de la
organizacin de acuerdo a los lineamientos de adaptacin de la organizacin;
tiene una descripcin mantenida, y contribuye con experiencias relacionadas al
proceso a los activos de la organizacin de procesos.
Una crtica diferencia entre los niveles de capacidad 2 y 3 es el alcance de los
estndares, descripciones de procesos, y procedimientos. En el nivel 2 stos
pueden ser ligeramente diferentes en cada instancia especfica del proceso. En
el nivel 3, para un proyecto determinado son adaptados desde el conjunto de
procesos estndar de la organizacin para adaptarse a un proyecto particular o
unidad organizativa, y por lo tanto son ms consistentes, excepto por las
diferencias permitidas por las guas de adaptacin.
Otra diferencia critica es que en el nivel de capacidad 3 los procesos son
descriptos tpicamente en forma ms rigurosa que en el nivel 2 y son
gestionados en forma ms proactiva.
Niveles de madurez
Un nivel de madurez consiste en prcticas genricas y especificas relacionadas
por un grupo de reas de procesos predefinidas que mejoran la performance
general de la organizacin.
Son medidos por el logro de goles genricos y especficos asociados con cada
grupo de reas de proceso predefinidas.
Recordemos que los niveles 2 y 3 usan los mismos trminos que los niveles de
capacidad 2 y 3, esta consistencia es intencional porque los conceptos de
capacidad y madurez son complementarios.
Los niveles de madurez se utilizan para caracterizar las mejoras de la
organizacin relacionada a un grupo de reas de proceso, y los niveles de
capacidad caracterizan la mejora de la organizacin relativa a un rea de
proceso particular.
Page 36
201
2
Nivel de madurez 1: Inicial

Los procesos de nivel de madurez 1 son habitualmente ad hoc y caticos.
La organizacin habitualmente no provee un ambiente estable para dar soporte
a los procesos. El xito en estas organizaciones depende de la competencia y
heroicidad de la gente, y no en el uso de procesos probados. Debido a este
caos las organizaciones de nivel 1 producen habitualmente productos y
servicios que funcionan, pero frecuentemente se exceden en costos y
cronograma respecto de lo planificado.
Las organizaciones de nivel 1 se caracterizan por una tendencia a
comprometerse a ms de lo que pueden llegar, abandonar los procesos en
tiempos de crisis y ser incapaces de reproducir los xitos.
Nivel de madurez 2: Gestionado

En el nivel de madurez 2 los proyectos tienen asegurado que los procesos
estn planificados y ejecutados de acuerdo con la poltica. Los proyectos
emplean personas capacitadas que tienen los recursos adecuados para
producir salidas controladas, envuelven a las partes interesadas relevantes,
son monitoreados, controlados y revisados, y son evaluados por si adhesin a
las descripciones del proceso. La disciplina reflejada por el nivel de madurez 2
ayuda a asegurar que las prcticas existentes son mantenidas durante los
tiempos de estrs. Cuando las practicas estn en su lugar los proyectos sin
realizados y gestionados de acuerdo con los planes documentados.
Tambin en el nivel de madurez 3 el estado de los productos de trabajo son
visibles a la gestin en puntos determinados Se establecen compromisos entre
partes interesadas relevantes y se revisan segn ser necesario. Los productos
de trabajo son apropiadamente controlados, y satisfacen las descripciones de
procesos, estndares y procedimientos especificados.
Nivel de madurez 3: Definido

En el nivel de madurez 3 los procesos estn bien caracterizados y
comprendidos, y estn descriptos en estndares, procedimientos, herramientas
y mtodos. El grupo de procesos estndar de la organizacin, que es la base
para el nivel de madurez 3, estn establecidos y mejoran con el tiempo.
La diferencia con el nivel 2 es el alcance de los estndares, descripciones de
procesos, y procedimientos, en el nivel 2 pueden ser algo diferentes en cada
instancia especifica del proceso, en el nivel 3 en cambio, son adaptados desde
Page 37
201
2
el grupo de procesos estndar de la organizacin para cumplir con un proyecto

particular o unidad organizacional, y entonces son ms consistentes excepto
por las diferencias permitidas en el proceso de adaptacin.
En el nivel 3 los procesos son manejados en forma ms proactiva, son
descriptos en forma ms rigurosa. La organizacin adems mejora sus
procesos relacionados con las reas de proceso del nivel de madurez 2. Las
prcticas genricas son asociadas con los goles genricos 3, que no fueron
logradas en el nivel 2 son aplicadas para lograr el nivel 3.
Nivel de madurez 4: Cuantitativamente Gestionado

En el nivel de 4 la organizacin y proyectos establecen objetivos cuantitativos
para calidad y performance de procesos, en trminos estadsticos, y los usan
como criterios para gestionar los proyectos. Los objetivos cuantitativos estn
basados en las necesidades del cliente, usuarios finales, organizacin e
implementadores del proceso.
Para subprocesos seleccionados, medidas especficas de performance de
procesos son recogidas y son estadsticamente analizadas. Lneas de base de
performance de procesos y modelos pueden ser utilizados para ayudar a
establecer los objetivos de calidad y performance que ayuden a obtener los
objetivos del negocio.
Una distincin crtica entre los niveles 3 y 4 es la predictibilidad de los procesos
de performance. En el nivel 4 la performance de los proyectos y subprocesos
seleccionados es controlada utilizado datos estadsticos y otras tcnicas
cuantitativas. Las predicciones son basadas, en parte, en el anlisis estadstico
de datos especficos del proceso.
Nivel de madurez 5: Optimizado

En el nivel de madurez 5, la organizacin continuamente mejora sus procesos,
basado en la interpretacin cuantitativa de los objetivos del negocio y las
necesidades de performance. La organizacin utiliza un enfoque cuantitativo
para comprender la variacin inherente en el proceso y las causas de sus
resultados.
Los objetivos de calidad y procesos de performance de la organizacin estn
establecidos, son continuamente revisados para reflejar el cambio en los
objetivos del negocio y la performance de la organizacin, y son utilizados
como criterio en la gestin de la mejora del proceso.
Page 38
201
2
Los efectos de las mejoras de procesos son medidos utilizando estadstica y

otras tcnicas cuantitativas, y son comparados con los objetivos de calidad y
performance de procesos. Los procesos definidos del proyecto, los procesos
estndar de la organizacin, y la tecnologa de soporte son objetivos de
actividades de mejora medibles.
Una distincin crtica entre los niveles de madurez 4 y 5 es el foco en gestin y
mejora de la performance de la organizacin. En el nivel 4 la organizacin y el
proyecto se enfocan en entender y controlar la performance a nivel de
subproceso, y utilizar los resultados para gestionar los proyectos. En el nivel 5
la organizacin est preocupada con toda la performance de la organizacin,
usando datos recopilados de mltiples proyectos. El anlisis de los datos
identifica dficit o lagunas en la performance. Estas lagunas son utilizadas para
dirigir el proceso organizacional de mejora que genera mejoras de performance
medibles.
Page 39
201
2
reas de proceso, categoras y niveles de madurez

AREA DE PROCESO
CATEGORIA
NIVEL DE MADUREZ
Anlisis
de
Causa y Soporte
5
Resolucin (CAR)
Gestin
de
Configuracin (CM)
la
Soporte
Anlisis
de
Decisiones
y Resolucin (DAR)
Soporte
Gestin
de
proyectos
integrada (IPM)
Medicin y Anlisis (MA)
Definicin del
Proceso
Organizacional (OPD)
Gestin de proyectos
Soporte
Gestin de proyectos
2
3
Enfoque del
Proceso
Organizacional (OPF)
Gestin de proyectos
Gestin
del
Desempeo Organizacional
(OPM)
Gestin de proyectos
Rendimiento del
Proceso
Organizacional (OPP)
Gestin de proyectos
Entrenamiento Organizacion
al (OT)
Gestin de proyectos
Integracin
productos (PI)
Ingeniera
de
Monitoreo y
proyecto(PMC)
Control de
Gestin de proyectos
Planificacin
Proyectos (PP)
de
Gestin de proyectos
Soporte
Aseguramiento
de
la Calidad del Proceso y del
Producto (PPQA)
Page 40
Gestin
de
Proyectos
cuantitativa (QPM)
Gestin de proyectos
Desarrollo
de
Requerimientos (RD)
Gestin de Requerimientos
(REQM)
Ingeniera
Gestin de proyectos
Gestin de Riesgos (RSKM)
Gestin de proyectos
Gestin de Acuerdos
Proveedores (SAM)
Gestin de proyectos
Solucin Tcnica (TS)
Ingeniera
Validacin (VAL)
Ingeniera
Verificacin (VER)
Ingeniera
de
Page 41
201
2
201
2
Relaciones entre reas de proceso

Las relaciones entre las mltiples reas de proceso, incluyendo la informacin y
artefactos que fluyen de una a otra, ayudan a tener una visin ms completa
del proceso de implementacin y mejora. Las iniciativas exitosas de mejoras de
procesos tienen que estar dirigidas por los objetivos de negocio de la
organizacin.
Aunque las reas de proceso son organizadas por grupos para simplificar la
comprensin de sus relaciones, estas frecuentemente interactan y tienen
efectos sobre otra independientemente de su grupo, categora o nivel.
Estar al tanto de las relaciones que existen entre las reas de proceso de CMMI
ayudara a aplicar CMMI de una manera til y productiva.
Gestin de procesos
Las reas de proceso del grupo Gestin de procesos contienen las
actividades de proyecto transversales, relacionadas con definir, planificar,
instalar, implementar, monitorear, controlar, evaluar, medir y mejorar los
procesos.
Estas cinco reas son:
Definicin del Proceso Organizacional (OPD)

Enfoque del Proceso Organizacional (OPF)
Gestin del Desempeo Organizacional (OPM)
Rendimiento del Proceso Organizacional (OPP)
Entrenamiento Organizacional (OT)
reas de gestin de procesos bsicas

Las reas de gestin de procesos bsicas proveen a la organizacin de la
capacidad de documentar, y compartir mejores prcticas, bienes del proceso
de la organizacin, y aprendizaje a travs de la organizacin.
El rea Enfoque del Proceso Organizacional (OPF) ayuda a la organizacin a
planificar, implementar, e instalar mejoras de los procesos de la organizacin
basados en un entendimiento de las fortalezas y debilidades actuales de los
procesos de la organizacin y sus bienes.
Page 42
201
2
Mejoras candidatas a los procesos de la organizacin son obtenidas a travs de

varias fuentes, Estas actividades incluyen propuestas de mejoras de procesos,
mediciones de los procesos, lecciones aprendidas en la implementacin de los
procesos, y resultados de las actividades de evaluacin de los procesos y
productos.
El rea Definicin del Proceso Organizacional (OPD) establece y mantiene el set
de procesos estndar de la organizacin, sus estndares de ambiente de
trabajo, y otros activos basados en las necesidades del proceso y objetivos de
la organizacin. Estos otros activos incluyen descripciones del modelo de ciclo
de vida, guas de proceso de adaptacin, y documentacin y datos
relacionados con el proceso. El proyecto adaptara los procesos estndar de la
organizacin para crear su proceso definido.
El rea Entrenamiento Organizacional (OT) identifica las necesidades
estratgicas de entrenamiento de la organizacin, as como tambin las
necesidades tcticas de entrenamiento que son comunes a travs de proyectos
y grupos de soporte. En particular, el entrenamiento es desarrollado u obtenido
para desarrollar las habilidades necesarias para realizar los procesos estndar
de la organizacin. El componente central de entrenamiento incluye un
desarrollo gerenciado del programa de entrenamiento, planes documentados
personal con el conocimiento apropiado, y mecanismos para medir la
efectividad del programa de entrenamiento.
reas de gestin de procesos avanzadas

La reas de gestin de procesos avanzadas proveen a la organizacin de una
capacidad avanzada de lograr sus objetivos cuantitativos
de calidad y
performance de los procesos. Cada una de ellas depende de la habilidad de
implantar y desarrollar procesos y activos de soporte, lo cual es provisto por las
reas de gestin de procesos bsicas.
El rea Rendimiento del Proceso Organizacional (OPP) obtiene objetivos
cuantitativos para calidad y performance de los procesos de los objetivos de
negocio de la organizacin. La organizacin provee a los proyectos y grupos de
soporte con medidas comunes, lneas de base de performance de procesos, y
modelos de performance de procesos. La organizacin analiza los datos de
performance de los proyectos recogidos para desarrollar un entendimiento
cuantitativo de la calidad del producto, la calidad del servicio, y la performance
de los procesos estndar de la organizacin.
En el rea de Gestin del Desempeo Organizacional (OPM) las lneas de base
y los modelos de la performance de los procesos son analizados para
Page 43
201
2
comprender la habilidad de la organizacin para lograr sus objetivos de

negocio y obtener los objetivos de calidad y performance de procesos. Basada
en este entendimiento la organizacin, proactivamente, selecciona y recoge
mejoras incrementales e innovadoras que mejoran sensiblemente la
performance de la organizacin. La organizacin puede tambin ajustar los
objetivos del negocio y la calidad y objetivos de performance de los procesos
como sea apropiado.
Gestin de proyectos
Las reas de proceso de gestin de proyectos cubren las actividades
relacionadas con planificacin, monitoreo, y control del proyecto.
Estas siete reas son:
Gestin de Proyectos Integrada (IPM)

Monitoreo y Control de proyecto(PMC)
Planificacin de Proyectos (PP)
Gestin de Proyectos cuantitativa (QPM)
Gestin de Requerimientos (REQM)
Gestin de Riesgos (RSKM)
Gestin de Acuerdos de Proveedores (SAM)
reas de gestin de proyectos bsicas

Las reas de gestin de proyectos bsicas abordan actividades relacionadas a
establecer y mantener el plan del proyecto y los compromisos, monitorear el
progreso respecto del plan, tomar acciones correctivas, y manejar los acuerdos
con los proveedores.
La planificacin comienza con los requerimientos que definen el producto y el
proyecto: que construir. El plan del proyecto cubre las variadas actividades
de gestin del proyecto y actividades de desarrollo realizadas por el proyecto.
El proyecto revisa otros planes de varias partes interesadas, que afectan al
proyecto, y establece compromisos con ellos para su contribucin al proyecto.
El rea de Monitoreo y Control de proyecto contiene prcticas para monitorear
y controlar actividades y tomar acciones correctivas. El plan del proyecto
especifica la frecuencia de las revisiones de avance y las medidas usadas para
monitorear el progreso. El progreso se determina primariamente comparando
el estatus del proyecto con el plan. Cuando el estatus real se desva
significativamente de los valores esperados, acciones correctivas se deben
Page 44
201
2
tomar apropiadamente, las cuales pueden comprender replanificacin, lo que

requiere prcticas de Planificacin de Proyecto.
El rea de Gestin de requerimientos mantiene los requerimientos. Describe las
actividades para obtener y controlar los cambios en los requerimientos y
asegura que otros planes y datos relevantes se mantienen actualizados. Provee
trazabilidad de requerimientos desde el cliente hasta el producto, y hasta los
requerimientos de los componentes del producto.
La Gestin de Requerimientos asegura que los cambios a los requerimientos
sean reflejados en los planes del proyecto, actividades, y productos de trabajo.
El ciclo de cambios puede afectar las reas de proceso de Ingeniera; as, la
gestin de requerimientos es una secuencia de eventos dinmica y a menudo
recursiva. Es fundamental para para una ingeniera de procesos controlada y
disciplinada.
El rea de procesos Gestin de Acuerdos de Proveedores se dirige a las
necesidades del proyecto de adquirir las porciones de trabajo que son
producidas por proveedores. Las fuentes de productos que pueden ser
utilizadas para satisfacer los requerimientos del proyecto son identificadas
proactivamente. El proveedor es seleccionado, y el acuerdo con el proveedor
es establecido para el gerenciamiento.
El progreso y performance del proveedor son controlados como est
especificado en el contrato, y ste es revisado apropiadamente. Las revisiones
de aceptacin y pruebas son realizadas sobre el componente producido por el
proveedor.
reas de gestin de proyectos avanzadas

Las reas de gestin de proyectos avanzadas se dirigen a actividades tales
como establecer un proceso definido que es ajustado desde el set de procesos
estndar de la organizacin, estableciendo el ambiente de trabajo del proyecto
desde los estndares de la organizacin, coordinando y colaborando con las
partes interesadas relevantes; formando y manteniendo equipos para la
conduccin de proyectos, manejando el proyecto cuantitativamente, y
manejando los riesgos.
El rea de proceso de Gestin de Proyectos Integrada establece y mantiene el
proceso definido para el proyecto que es ajustado del set de estndares de
procesos de la organizacin (Definicin del Proceso Organizacional OPD). El
proyecto es gerenciado utilizando los procesos definidos para l, y usa y
contribuye a los activos organizacionales de los procesos, el ambiente de
Page 45
201
2
proyecto es establecido y mantenido desde los estndares de ambiente de

trabajo de la organizacin, y los equipos se establecen utilizando las reglas y
guas de la organizacin. Las partes interesadas relevantes coordinan sus
esfuerzos de una manera oportuna a travs de la identificacin, negociacin, y
seguimiento de dependencias crticas y la resolucin de problemas de
coordinacin.
Aunque la identificacin y monitoreo de riesgos est cubierta en la
planificacin de proyectos y en el monitoreo y control de proyectos, el rea de
gestin de riesgos toma un enfoque con visin de futuro y continuo para
manejo de riesgos, con actividades que incluyen la identificacin de
parmetros de riesgos, evaluacin de riesgos, y mitigacin.
El rea de Gestin de Proyectos cuantitativa establece objetivos de calidad y
performance de procesos, compone un proceso que puede ayudar a alcanzar
esos objetivos, y cuantitativamente gestiona el proyecto. Los objetivos de
calidad y performance se basan en los objetivos establecidos por la
organizacin y el cliente.
El proceso definido para el proyecto se compone utilizando
tcnicas
estadsticas y otras cuantitativas. Tal anlisis permite al proyecto predecir si va
a alcanzar los objetivos de calidad y performance.
Basado en esta prediccin el proyecto puede ajustar el proceso definido o
puede negociar cambios a los objetivos de calidad y performance. Al progresar
el proyecto, la performance de subprocesos seleccionados es cuidadosamente
monitoreada para ayudar a evaluar si el proyecto est en camino de alcanzar
los objetivos.
Ingeniera
Las reas de proceso de ingeniera cubren las actividades de desarrollo y
mantenimiento que son compartidas a travs de las disciplinas de ingeniera,
cualquiera sea la disciplina del producto en desarrollo (software, mecnica,
etc.), para mejorar su proceso.
De este modo el foco se pone en objetivos esenciales del negocio ms que en
disciplinas especficas.
Las cinco reas de proceso de ingeniera son:
Integracin de productos (PI)

Desarrollo de Requerimientos (RD)
Solucin Tcnica (TS)
Page 46
201
2
Validacin (VAL)
Verificacin (VER)
Como se puede observar en el grfico, las reas de proceso de Verificacin y

Validacin se aplican a todas las dems, realizndose as la verificacin tanto
de los Requerimientos, como de la Construccin de la solucin y de la
Integracin, obteniendo as la trazabilidad necesaria para obtener un producto
que funcione correctamente y se adece a las necesidades del cliente.
El rea de proceso de desarrollo de requerimientos identifica las necesidades
del cliente y las traduce en requerimientos del producto. El set de
requerimientos de producto es analizado para producir una solucin conceptual
de alto nivel. Este set de requerimientos es entonces asignado para establecer
un set inicial de requerimientos de componentes de producto. Este grupo de
requerimientos del producto y requerimientos de componentes de producto
describen claramente la performance del producto, los atributos de calidad, las
caractersticas de diseo, los requerimientos de verificacin, etc., en trminos
que el desarrollador use y comprenda.
El rea de proceso de desarrollo de requerimientos provee requerimientos al
rea de proceso de Solucin Tcnica, donde los requerimientos son convertidos
en arquitectura del producto, componentes de diseo del producto, y
Page 47
201
2
componentes de producto. Los requerimientos son tambin suministrados al

rea de Integracin de producto, donde los componentes de producto son
combinados y sus interfaces son verificadas para asegurar que alcanzan los
requerimientos de interfaz dados por Desarrollo de Requerimientos.
El rea de proceso Solucin Tcnica desarrolla paquetes de datos tcnicos para
componentes de producto ser utilizados por las reas Integracin de productos
o Gestin de acuerdos de Proveedores. Se evalan soluciones alternativas para
seleccionar el diseo ptimo basado en criterios establecidos. La tarea de
seleccionar la solucin final hace uso de prcticas especficas en el rea de
Anlisis de Decisiones y Resolucin.
El rea de Solucin Tcnica depende de prcticas especficas en el rea de
Verificacin para realizar verificacin del diseo y revisiones de pares durante
el diseo y previo a la construccin final.
El rea de proceso de Verificacin asegura que productos de trabajo
seleccionados alcancen los requerimientos especificados. Selecciona los
productos de trabajo y los mtodos de verificacin que sern utilizados para
verificar respecto de los requerimientos especificados. Habitualmente es un
proceso incremental que comienza con la verificacin de los componentes del
producto y usualmente concluye con la verificacin del producto
completamente ensamblado. Tambin comprende revisiones de pares.
El rea de proceso de Validacin incrementalmente valida los productos frente
a las necesidades del cliente. Puede ser realizado en un ambiente de operacin
o en uno simulado. La coordinacin con el cliente en la validacin de los
requerimientos es un elemento importante de esta rea de proceso.
El alcance del rea de Validacin incluye validacin de productos, componentes
de productos, productos intermedios seleccionados, y procesos. Los problemas
encontrados durante esta etapa son resueltos usualmente en las reas de
Desarrollo de Requerimientos o Solucin Tcnica.
El rea de Integracin del producto utiliza prcticas especficas de ambas,
Verificacin y Validacin para implementar el proceso de integracin. Las
prcticas de verificacin verifican las interfaces y los requerimientos de las
interfaces de los componentes de productos antes de la integracin. La
verificacin de interfaces es un evento esencial en la integracin del producto.
Durante la integracin en el ambiente operacional, las prcticas especficas de
Validacin de procesos son utilizadas.
Page 48
201
2
Recursividad e iteracin del proceso de ingeniera

La mayora de los estndares de procesos estn de acuerdo en que hay dos
formas de aplicar los procesos. Estas dos formas son recursividad e iteracin.
Recursividad ocurre cuando un proceso es aplicado en sucesivos niveles de
elementos del sistema dentro de la estructura del sistema. Las salidas de una
aplicacin son utilizadas como entradas para el nivel siguiente de la estructura
del sistema.
Iteracin ocurre cuando los procesos se repiten en el mismo nivel, nueva
informacin es creada en la implementacin de un proceso que alimenta esa
informacin a los procesos relacionados.
Los procesos de ingeniera son implementados repetidamente en un producto
para asegurar que esos procesos de ingeniera han sido adecuadamente
dirigidos antes de la entrega al cliente. Adems, los procesos de ingeniera son
aplicados a componentes del producto.
Recursividad e iteracin de estos procesos permite al proyecto asegurar la
calidad en todos los componentes del producto antes de la entrega al cliente.
Algunos procesos de Gerenciamiento de Proyectos tambin podran ser
recursivos porque algunas veces los proyectos estn anidados con otros
proyectos.
Soporte
Las reas de soporte cubren las actividades que dan soporte al desarrollo del
producto y su mantenimiento, se dirigen a procesos que son utilizados en el
contexto de realizacin de otros procesos. En general, las reas proceso de
soporte se dirigen a procesos que estn sealados a lo largo del proyecto y
puede alcanzar proceso que se aplican ms generalmente a la organizacin.
Las cinco reas de proceso de soporte son:
Anlisis de Causa y Resolucin (CAR)

Gestin de la Configuracin (CM)
Anlisis de Decisiones y Resolucin (DAR)
Medicin y Anlisis (MA)
Aseguramiento de la Calidad del Proceso y del Producto (PPQA)
Page 49
201
2
reas de soporte bsicas

Las reas de soporte bsicas se dirigen a funciones de soporte fundamentales
utilizadas por todas las reas de proceso, ya que proveen funciones de soporte
que tambin ayudan a implementar varias prcticas genricas.
El rea de Medicin y Anlisis da soporte a todas las reas de proceso al
proveer prcticas especficas que guan a los proyectos y organizaciones a
alinear necesidades de medicin y objetivos con un enfoque de medicin que
es utilizado para dar soporte a las necesidades de informacin de gestin.
Aseguramiento de la Calidad del Proceso y del Producto da soporte a todas las
reas de proceso al proveer practicas especficas para evaluar objetivamente
los procesos realizados, los productos de trabajo, y los servicios frente a las
descripciones de procesos aplicables, estndares, y procedimientos, y
asegurando que cualquier problema que surja de estas revisiones es abordado.
Aseguramiento de la Calidad del Proceso y del Producto da soporte a la entrega
de productos y servicios de alta calidad al proveer al personal del proyecto y a
todos los niveles de gerencia de la visibilidad apropiada y realimentacin de los
procesos y productos de trabajo asociados a travs del ciclo de vida del
proyecto.
El rea de proceso de gestin de la configuracin da soporte a todas las reas
de proceso al establecer y mantener la integridad de los productos de trabajo
utilizando identificacin de la configuracin, control de la configuracin,
estados de cuentas de la configuracin, y auditorias de configuracin. Los
productos de trabajo de esta rea incluyen productos que son entregados al
cliente, productos de trabajo designados internos, productos adquiridos,
herramientas, y otros tems que son utilizados en la creacin y descripcin de
los productos de trabajo.
reas de soporte avanzadas

Las reas de soporte avanzadas proveen a los proyectos y organizacin con un
mejorado soporte de la calidad. Cada una de estas reas de proceso se apoya
en inputs especficos o prcticas de otras reas de proceso.
Al utilizar el rea de proceso Anlisis de Causa y Resolucin los miembros del
proyecto identifican las causas de resultados seleccionados y toma acciones
para prevenir que los resultados negativos ocurran en el futuro o para
aprovechar los resultados positivos.
Page 50
201
2
Anlisis de Decisiones y Resolucin da soporte a todas las reas de proceso al

determinar que problemas deben ser sujetos a un proceso formal de
evaluacin y entonces aplicar el proceso formal de evaluacin a stos.
Page 51
201
2
Las reas de proceso de Ingeniera

Integracin de producto
Propsito
El propsito del rea de proceso es ensamblar el producto desde sus
componentes para asegurar que el producto integrado se comporta
apropiadamente.
Notas introductorias
Esta rea de proceso dirige la integracin de los componentes del producto en
otros ms complejos o en productos completos.
El alcance es alcanzar la integracin completa del producto, a travs del
ensamblado progresivo de os componentes, sea en una o ms etapas. Un
aspecto crtico es la gestin de interfaces internas o externas, con las cuales
hay que asegurar la compatibilidad.
Este proceso puede incluir anlisis y simulaciones, para
incrementalmente en prototipos, hasta alcanzar el producto final.
progresar
Para muchos productos o servicios la integracin final se realiza cuando es

implementado en el sitio de operacin pretendido.
reas de proceso relacionadas
Desarrollo de requerimientos: para ms informacin sobre la identificacin de
requerimientos de interfaces.
Solucin tcnica: para ms informacin sobre diseo de interfaces utilizando
criterios.
Validacin: para ms informacin sobre cmo realizar las validaciones
Verificacin: para ms informacin sobre cmo realizar verificaciones.
Gestin de la configuracin: para ms informacin sobre seguimiento y control
de cambios.
Anlisis de decisin y resolucin: para informacin sobre el anlisis de posibles
decisiones utilizando un proceso de evaluacin formal que evala alternativas
identificadas versus criterios establecidos.
Gestin de Riesgos: para ms informacin sobre identificacin y mitigacin de
riesgos.
Page 52
201
2
Gestin de Acuerdos de proveedores: par amas informacin sobre

gerenciamiento de la adquisicin de productos y servicios de proveedores.
Resumen de Goles y Prcticas especficas
SG 1 Preparacin para la integracin del producto
SP 1.1 Establecimiento de una estrategia de integracin
SP 1.2 Establecimiento de un ambiente de integracin del producto
SP 1.3 Establecimiento de procedimientos y criterios de integracin del
producto
SG 2 Asegurar la compatibilidad de las interfaces.
SP 2.1 Revisin de las descripciones de interfaces para completitud
SP 2.2 Gestin de interfaces
SG 3 Ensamble de los componentes de producto y entrega del producto
SP 3.1 Confirmacin de disponibilidad de los componentes del producto
para integracin
SP 3.2 Ensamble de los componentes de producto
SP 3.3 Evaluacin de los componentes de producto ensamblados
SP 3.4 Empaque y entrega del producto o componente de producto
Desarrollo de requerimientos
Propsito
El propsito del desarrollo de requerimientos es obtener, analizar, y establecer
los requerimientos del cliente, del producto, y de los componentes del
producto.
Esta rea de proceso describe tres tipos de requerimientos: del cliente, del
producto, y de los componentes del producto. En su conjunto alcanzan las
necesidades de las principales partes interesadas, incluyendo las necesidades
pertinentes a varias fases del ciclo de vida del producto y sus atributos.
Los requerimientos estn presentes en todos los proyectos de desarrollo, y son
la base del diseo. Incluyen las siguientes actividades:
Page 53
201
2
Obtencin, anlisis, validacin y comunicacin de las necesidades y

expectativas del cliente, y restricciones para priorizar los requerimientos
que satisfarn a las partes interesadas.
Recoleccin y coordinacin de las necesidades de las partes interesadas.
Desarrollo de los requerimientos del ciclo de vida del producto.
Establecimiento de los requerimientos funcionales y de calidad del
cliente.
Establecimiento de los requerimientos del producto inicial y
componentes de producto consistentes con las necesidades del cliente.
Esta rea de proceso se dirige a todos los requerimientos del cliente, no solo a
los de producto, debido a que el cliente puede proporcionar requerimientos
especficos de diseo.
Los requerimientos son identificados y refinados a lo largo de las fases del ciclo
de vida del producto.
La definicin de la funcionalidad requerida y atributos de calidad describe lo
que el producto debe hacer. Esta definicin puede incluir descripciones,
descomposiciones, y particiones de las funciones servicios- del producto.
Adicionalmente la definicin especifica consideraciones de diseo o
restricciones sobre cmo la funcionalidad requerida debe ser realizada.
Atributos de calidad se dirigen a cosas tales como disponibilidad del producto,
mantenimiento, modificabilidad, lneas de tiempo, rendimiento, respuesta,
confiabilidad, seguridad y escalabilidad. Algunos de estos pueden ser de
importancia en la arquitectura y dirigirn el desarrollo de la misma.
Integracin de productos: para ms informacin sobre asegurar compatibilidad
de interfaces
Solucin tcnica: para ms informacin sobre seleccin de soluciones de
componentes de producto y desarrollo del diseo.
Validacin: para ms informacin sobre validacin del producto y sus
componentes
Verificacin: para ms informacin sobre verificacin de productos de trabajo
seleccionados.
Gestin de la configuracin: para ms informacin sobre el seguimiento y
control de cambios
Page 54
201
2
Gestin de requerimientos: para ms informacin sobre gestionar los

requerimientos
Gestin de riesgos: para ms informacin sobre identificacin y anlisis de
riesgos.
SG 1 Desarrollo de requerimientos de cliente
SP 1.1 Obtencin de necesidades
SP 1.2 Transformacin
requerimientos de clientes
de
las
necesidades
de
stakeholders
en
SG 2 Desarrollo de los requerimientos de producto

SP 2.1 Establecimiento de los requerimientos del producto y de los
componentes del producto
SP 2.2 Asignacin de requerimientos de componentes de producto
SP 2.3 Identificacin de requerimientos de interfaz.
SG 3 Anlisis y validacin de requerimientos
SP 3.1 Establecimiento de conceptos operacionales y escenarios
SP 3.2 Establecimientos de una definicin de funcionalidad requerida y
atributos de calidad.
SP 3.3 Anlisis de requerimientos
SP 3.4 Anlisis de requerimientos para alcanzar un balance
SP 3.5 Validacin de requerimientos
Solucin tcnica
Propsito
El propsito de la solucin tcnica es seleccionar, disear, e implementar
soluciones para los requerimientos. Soluciones, diseos e implementaciones
abarcan productos, componentes de producto, y procesos relacionados al
producto en el ciclo de vida, ya sea en forma singular o combinadamente.
Page 55
201
2
El rea de proceso de solucin tcnica es aplicable a cualquier nivel de la
arquitectura de producto, y a todos los productos, componentes de producto y
procesos relacionados al producto en el ciclo de vida.
Esta rea de proceso se enfoca en:
Evaluar y seleccionar soluciones que pueden satisfacer un set apropiado

de requerimientos funcionales y de calidad
Desarrollar diseos detallados para las soluciones seleccionadas
Implementar los diseos como producto o componente de producto
Tpicamente estas actividades se apoyan mutuamente. Algn nivel de diseo,

en algunos casos bastante definido, puede ser necesario para seleccionar
soluciones. Prototipos o pilotos pueden ser utilizados como medios para
obtener conocimientos para desarrollar un paquete de datos tcnicos, o un set
de requerimientos completo.
Para un proyecto de mantenimiento los requerimientos pueden ser dirigidos
por las necesidades del usuario, maduracin u obsolescencia de la tecnologa,
o defectos latentes en componentes de producto. Nuevos requerimientos
pueden surgir de cambios en el ambiente operacional.
Los procesos asociados con el rea de proceso Solucin tcnica deben ser
usados para realizar el mantenimiento o sostenimiento de los esfuerzos de
diseo.
Desarrollo de requerimientos para ms informacin sobre asignacin de
requerimientos de componentes de producto, establecimiento de conceptos y
escenarios operacionales, e identificacin de requerimientos de interfaz.
Verificacin para ms informacin sobre realizacin de revisiones de pares, y
verificacin de productos de trabajo seleccionados.
Anlisis de decisiones y resolucin para ms informacin sobre anlisis de
posibles decisiones usando un proceso de evaluacin formal, que evala
alternativas identificadas versus criterios establecidos.
Gestin del rendimiento de la organizacin para ms informacin sobre
seleccionar mejoras y desplegar mejoras.
Gestin de requerimientos para ms informacin sobre gestin de
requerimientos de los productos y componentes de producto del proyecto,
Page 56
201
2
asegurando alineacin entre estos requerimientos y los planes del proyecto y

los productos de trabajo.
SG 1 Seleccin de soluciones de componentes de producto
SP 1.1 Desarrollo de soluciones alternativas y criterios de seleccin
SP 1.2 Seleccin de soluciones de componentes de producto
SG 2 Desarrollo del diseo
SP 2.1 Diseo del producto o del componente de producto
SP 2.2 Establecimiento de un paquete tcnico de datos
SP 2.3 Diseo de interfaces utilizando criterios
SP 2.4 Realizacin de anlisis de construccin, compra o reutilizacin.
SG 3 Implementacin del diseo del producto
SP 3.1 Implementacin del diseo
SP 3.2 Desarrollo de la documentacin de soporte del producto.
Validacin
Propsito
El propsito del rea de proceso Validacin es demostrar que un producto o
componente de producto cumple con el uso pretendido cuando es puesto en su
pretendido ambiente
Las actividades de validacin pueden ser aplicadas a todos los aspectos del
producto en cualquiera de sus pretendidos ambientes, tales como operacin,
entrenamiento, manufactura, mantenimiento, y servicios de soporte.
Los mtodos empleados en la validacin pueden ser aplicados a productos de
trabajo as como tambin al producto y componentes de producto. Los
productos de trabajo deben ser seleccionados en base a cules son los mejores
predictores de cun bien el producto y sus componentes satisfarn las
Page 57
201
2
necesidades del usuario, por lo tanto la validacin se realizar temprana e

incrementalmente a travs del ciclo de vida del producto.
El ambiente de validacin del producto debe representar el ambiente
pretendido por el producto y los componentes de producto, as como tambin
representar el ambiente pretendido adecuado para actividades de validacin
con productos de trabajo.
La validacin demuestra que el producto, como est previsto, va a cumplir con
su pretendido uso, mientras que la verificacin se dirige a si el producto de
trabajo refleja apropiadamente los requerimientos especificados. En otras
palabras la verificacin se asegura de que lo hiciste bien, mientras que la
validacin se asegura de que hiciste lo correcto Ambas actividades
frecuentemente corren concurrentemente y pueden utilizar porciones del
mismo ambiente.
Cuando sea posible, la validacin debe ser realizada utilizando el producto en
el ambiente pretendido. La validacin de actividades de servicio puede ser
aplicada a producto de trabajo tales como propuestas, catlogos de servicio,
declaraciones de trabajo, y registros de servicio.
Cuando se identifican problemas en la validacin, son referidos para resolucin
a procesos asociados con el desarrollo de los requerimientos, Solucin tcnica,
o Monitoreo y control de proyectos.
Las prcticas especficas de esta rea de proceso se fortalecen entre s de la
siguiente forma:
La seleccin de productos para validacin habilita la identificacin de

productos o componentes de producto a ser validados y los mtodos a
ser utilizados para realizar la validacin
El establecimiento del ambiente de validacin habilita la determinacin
del ambiente a ser utilizado para realizar la validacin
El establecimiento de los procesos y criterios de validacin habilita el
desarrollo de procesos de validacin y criterios que estn alineados con
las caractersticas de productos seleccionados, restricciones del cliente
en la validacin, mtodos y ambiente de validacin.
La realizacin de la validacin es la prctica especfica que habilita la
realizacin de la validacin de acuerdo con los mtodos, procedimientos
y criterios.
Page 58
201
2

Desarrollo de requerimientos: para ms informacin sobre como provocar,
analizar, y establecer los requerimiento de cliente, producto y componentes de
producto
Solucin tcnica. Para ms informacin sobre
implementar soluciones para los requerimientos.
seleccionar,
disear
Verificacin: Para ms informacin sobre asegurar que el producto de trabajo

seleccionado cumple con los requerimientos especificados.

SG 1 Preparacin para Validacin
SP 1.1 Seleccionar productos para validacin
SP 1.2 Establecer el ambiente de validacin
SP 1.3 Establecer procedimientos y criterios de validacin
SG 2 Validacin del producto o componentes de producto
SP 2.1 Realizar la validacin
SP 2.2 Analizar los resultados de la validacin
Prcticas especficas por gol

SG 1 Preparacin para Validacin
Las actividades de preparacin incluyen la seleccin de productos y
componentes de productos para validacin y establecer y mantener el
ambiente de validacin, los procedimientos y criterios.
Los tems seleccionados para la validacin pueden incluir slo el producto o
niveles apropiados de componentes de productos utilizados para construir el
producto. Cualquier producto o componente de producto puede ser sujeto a
validacin, incluyendo productos de reemplazo, mantenimiento, y
entrenamiento.
El ambiente requerido para validar el producto o componente de producto se
prepara. El ambiente puede ser comprado o especificado, diseado y
construido. Los ambientes utilizados para integracin de productos y
Page 59
201
2
verificacin pueden ser considerados en colaboracin con el ambiente de

validacin, para reducir costos y mejorar la eficiencia o productividad.
SP 1.1 Seleccionar los productos para validacin

Los productos y componentes de producto son
basados en su relacin con las necesidades
componente de producto el alcance de
comportamiento operacional, mantenimiento,
usuario) debe ser determinado.
seleccionados para validacin

del usuario final. Para cada
la validacin (por ejemplo
entrenamiento, interfaz de
Algunos ejemplos de productos y componentes que pueden ser validados

incluyen: requerimientos, diseos, interfaces, manuales de usuario, etc.
Los requerimientos y restricciones para realizar la validacin son recolectados.
Entonces, los mtodos de validacin son seleccionados basados en su habilidad
para demostrar que las necesidades del usuario final estn satisfechas. Los
mtodos de validacin no solo definen el enfoque para la validacin del
producto, sino que tambin dirigen las necesidades de instalaciones, equipos, y
ambientes. El enfoque de la validacin puede resultar en la generacin de
requerimientos de componentes de producto de nivel ms bajo, los cuales
sern manejados por el proceso de desarrollo de requerimientos.
Requerimientos derivados como interfaces o sets de pruebas pueden ser
generados, y tambin sern derivados al proceso de desarrollo de
requerimientos, para asegurar que el producto o componentes de producto
pueden ser validados en un ambiente que soporte los mtodos.
Los mtodos de validacin deben ser seleccionados en forma temprana en la
vida del proyecto para poder ser claramente comprendidos y acordados por las
partes interesadas relevantes.
Los mtodos de validacin comprenden el desarrollo, mantenimiento, soporte,
y entrenamiento para el producto o componentes de producto como es
apropiado.
Algunos ejemplos de mtodos de validacin son: debates con los usuarios
finales, muestras de prototipos, muestras funcionales, entregas incrementales
de producto, etc.
Algunos ejemplos de productos de trabajo son: listas de productos y
componentes seleccionados para la validacin, mtodos de validacin para
cada producto o componente, requerimientos para la realizacin de la
validacin, restricciones a la validacin.
Page 60
201
2
Las subprcticas en este caso son: identificar los principios fundamentales,

caractersticas, y fases para la validacin del producto a travs del ciclo de
vida, determinar que categoras de usuarios finales es necesaria, seleccionar
los componentes y productos a ser validados, seleccionar los mtodos de
evaluacin, revisar la seleccin, restricciones y mtodos de la validacin con
las partes interesadas relevantes.
SP 1.2 Establecer el ambiente de validacin

Los requerimientos para el ambiente de validacin son impulsados por el
producto o componentes seleccionados, el tipo de producto de trabajo y por los
mtodos de validacin.
Estas selecciones pueden generar requerimientos de compra, o desarrollo de
equipos, programas u otros recursos. Estos requerimientos se ingresan al
proceso de desarrollo de requerimientos para su desarrollo. El ambiente de
validacin puede incluir la reutilizacin de recursos existentes. En este caso se
deben gestionar los arreglos para el uso de stos.
Algunos ejemplos de elementos en un ambiente de validacin incluyen:
herramientas de prueba en interfaz con el producto validado, programas de
pruebas temporalmente integrado, herramientas de grabacin para anlisis
posterior, sistemas o componentes simulados, personas entrenadas para
operar o utilizar los elementos, etc.
La seleccin temprana de productos o componentes a ser validados, productos
de trabajo a ser utilizados en la validacin, y mtodos de validacin es
necesaria para asegurar que el ambiente de validacin est disponible cuando
sea necesario. El ambiente de validacin debe ser cuidadosamente controlado
para proveer replicacin, anlisis de resultados, y revalidacin de reas de
problemas.
El ambiente de validacin es un ejemplo de producto de trabajo de esta
prctica especfica.
Las subprcticas en este caso son: identificar recursos para la validacin del
medio ambiente, productos entregados al cliente, equipos de pruebas y
herramientas, validacin de recursos que estn disponibles para reutilizacin y
modificacin, planificacin de la disponibilidad de recursos en detalle.
SP 1.3 Establecer los procedimientos y criterios de validacin

Page 61
201
2
Los procedimientos y criterios de validacin son definidos para asegurar que el

producto o componente de producto va a cumplir su pretendido uso cuando
sea ubicado en su pretendido ambiente. Los casos de prueba y procedimientos
para pruebas de aceptacin pueden ser utilizadas para los procedimientos de
validacin. Los procedimientos y criterios de validacin incluyen pruebas y
evaluaciones de mantenimiento, entrenamiento y servicios de soporte.
Ejemplos de fuentes para criterios de validacin incluyen: requerimientos de
productos y componentes, estndares, criterios de aceptacin del cliente,
desempeo ambiental y umbrales de rendimiento de la performance.
Ejemplos de productos de trabajo son: procedimientos de validacin, criterios
de validacin, y pruebas y procedimientos de evaluacin para mantenimiento,
entrenamiento y soporte.
Las subprcticas son: revisin de los requerimientos de producto para asegurar
que los problemas afectando la validacin de producto son identificados y
resuelta; documentacin de ambiente, escenario de operacin, procedimientos,
entrada, salidas, y criterios para la validacin de los productos seleccionados;
evaluacin del diseo mientras madura en el contexto de la validacin del
ambiente para identificar problemas de validacin.
SG 2 Validacin del producto o componentes de producto

Los mtodos de validacin, procedimientos y criterios son utilizados para
validar los productos y componentes de productos seleccionados y cualquier
otro servicio de mantenimiento, entrenamiento, y soporte, utilizando el
ambiente apropiado de validacin. Las actividades de validacin son realizadas
durante todo el ciclo de vida del producto.
SP 2.1 Realizar la validacin

Para ser aceptable por las partes interesadas, un producto o componente de
producto debe actuar como es esperado en el ambiente operacional
pretendido.
Las actividades de validacin son realizadas y los datos de resultado con
recogidos de acuerdo con mtodos, procedimientos y criterios establecidos.
Los procedimientos de validacin de ejecucin deben ser documentados y las
desviaciones ocurridas durante la ejecucin deben ser anotadas
apropiadamente.
Page 62
201
2
Ejemplos de productos de trabajo son. Reportes de validacin, resultados de

validacin, validacin cruzada de matriz de referencia, log de procedimiento de
ejecucin, demostraciones de operacin.
SP 2.2 Anlisis de los resultados de validacin

Los datos resultantes de las pruebas de validacin, inspecciones,
demostraciones o evaluaciones son analizados contra los criterios definidos de
validacin. Los reportes de anlisis indican si las necesidades han sido
cubiertas. En caso de deficiencias, estos reportes documentan el grado de
xito o falla y categorizan las causas probables de falla.
Los resultados de las pruebas, inspecciones, o revisiones son comparados con
los criterios establecidos de evaluacin para determinar si proceder o registrar
requerimientos o designar problemas en el desarrollo, en los requerimientos o
en las soluciones tcnicas propuestas.
El anlisis de los reportes o la documentacin de la validacin de ejecucin
pueden tambin indicar que los resultados fallidos de las pruebas se deben a
problemas en los procedimientos de validacin o del ambiente de validacin.
Ejemplos de productos de trabajo son: reportes de deficiencia de validacin,
problemas en la validacin, procedimientos de pedidos de cambios.
Las subprcticas son: comparacin de los resultados reales con los esperados;
identificacin de productos y componentes que no funcionan adecuadamente
en el ambiente pretendido de operacin, o identificacin de problemas con
mtodos, criterios o ambiente; anlisis de datos de validacin para encontrar
defectos, registro de resultados del anlisis e identificacin de problemas; uso
de los resultados de validacin para comparar las medidas reales y rendimiento
con el uso pretendido o las necesidades operacionales; proveer informacin
sobre como los defectos pueden ser resueltos, incluyendo mtodos de
validacin, criterios y ambiente de validacin, e iniciar acciones correctivas.
El rea de Monitoreo de proyectos y control puede aportar informacin sobre
cmo gestionar las acciones correctivas.
Page 63
201
2
Verificacin
Propsito
El propsito de la Verificacin (VER) es asegurar que los productos de trabajo
seleccionados alcanzan los requerimientos especificados
El rea de proceso Verificacin abarca lo siguiente: preparacin de la
verificacin, rendimiento de la verificacin, e identificacin de acciones
correctivas.
La verificacin incluye verificacin del producto, y de trabajos de producto
intermedios, contra todos los requerimientos seleccionados, incluyendo los
requerimientos de cliente, producto, y componentes de producto.
Para lneas de producto, principales activos y sus mecanismos de variacin de
lnea de productos deben tambin ser verificados. A travs de las reas de
proceso, donde los trminos producto y componentes de producto son
utilizados, sus mecanismos pretendidos tambin abarcan servicios, sistemas de
servicios, y sus componentes.
La verificacin es inherentemente un proceso incremental porque ocurre a
travs del desarrollo del producto y productos de trabajo, comenzando con la
verificacin de requerimientos, pasando por la verificacin de los productos de
trabajo en evolucin, y finalizando en la verificacin del producto completo.
Las prcticas especficas de esta rea de proceso se apoyan entre s de la
siguiente forma:
La seleccin de productos de trabajo permite la identificacin de

productos de trabajo a ser verificados, mtodos a ser utilizados para
realizar la verificacin, y los requerimientos a ser satisfechos por cada
producto de trabajo seleccionado.
Establecer el ambiente de verificacin habilita la determinacin del
ambiente a ser usado para llevar a cabo la verificacin.
El establecimiento de criterios y procedimientos de verificacin habilita
el desarrollo de procesos de verificacin y criterios que se alienan con
los productos de trabajo, requerimientos, mtodos y caractersticas del
ambiente de verificacin seleccionados.
La realizacin de la prctica especifica de la verificacin conduce la
verificacin conduce a la verificacin en su totalidad de acuerdo con
mtodos, criterios y procedimientos disponibles.
Page 64
201
2
La verificacin de productos de trabajo incrementa sustancialmente la

posibilidad de que el producto alance los requerimientos del cliente, de
producto y de componente de productos.
Las reas de proceso de verificacin y validacin son muy similares, pero se
dirigen a problemas diferentes. La validacin demuestra que el producto, como
ser entregado, cumplir con el uso pretendido, mientras que la verificacin se
dirige a si el producto de trabajo refleja apropiadamente los requerimientos
especificados. En otras palabras, la verificacin asegura que lo hiciste bien,
mientras que la validacin asegura que hiciste la cosa adecuada.
Revisiones de pares son una parte importante de la verificacin, y son
mecanismos probados de remocin de defectos.
Un corolario importante es desarrollar un mejor entendimiento de los productos
de trabajo y de los procesos que los producen, as los defectos pueden ser
prevenidos y se pueden identificar oportunidades de mejora de procesos.
Las revisiones de pares abarcan un examen metdico de los productos de
trabajo por parte de los compaeros de produccin, para identificar defectos y
otros cambios necesarios.
Ejemplos de mtodos de revisin de pares incluyen: inspecciones, recorridas
estructuradas, refactorizacin deliberada, programacin de a pares, etc.
En los ambientes Agile, debido a la implicacin del cliente y a las frecuentes
versiones, la verificacin y la validacin se dan soporte mutuo, ayudando a
asegurar un enfoque sistemtico de seleccin de los productos de trabajo a ser
revisados y probados, los mtodos y ambientes a utilizar, y las interfaces a
gestionar, lo que ayuda a asegurar que los defectos son identificados en forma
temprana.

Desarrollo de requerimientos: para ms informacin sobre como provocar,
analizar, y establecer los requerimientos del cliente, producto y componentes
de producto
Validacin: para demostrar que el producto o componentes de producto
cumplen el uso pretendido cuando se los ubica en el ambiente pretendido.
Gestin de requerimientos: para ms informacin sobre asegurar alineacin
entre el trabajo del proyecto y los requerimientos.
Page 65
201
2
Resumen de goles y prcticas especficas:

SG 1 Preparacin para la verificacin
SP 1.1 Seleccionar los productos de trabajo para la verificacin
SP 1.2 Establecer el ambiente de verificacin
SP 1.3 Establecer los procedimientos y criterios de verificacin
SG 2 Realizar revisiones de pares
SP 2.1 Preparacin para revisiones de pares
SP 2.2 Conducir las revisiones de pares
SP 2.3 Analizar los datos de las revisiones de pares
SG 3 Verificar los productos de trabajo seleccionados
SP 3.1 Realizar la verificacin
SP 3.2 Analizar los resultados de la verificacin
Prcticas especficas por gol

SG 1 Preparacin para la verificacin
Preparacin por adelantado es necesaria para asegurar que las previsiones de
la verificacin estn embebidas en los requerimientos, diseos, planes de
desarrollo, y cronogramas del producto y componentes de producto. La
verificacin incluye la seleccin, inspeccin, pruebas, anlisis y demostracin
de los productos de trabajo.
Los mtodos de verificacin incluyen, pero no se limitan a: inspecciones,
revisiones de pares, auditorias, recorridos, anlisis, evaluaciones de
arquitectura, simulaciones, pruebas y demostraciones. Las prcticas
relacionadas a revisiones de pares como mtodo especfico de verificacin se
incluyen en el gol especfico 2.
La preparacin tambin implica la definicin de herramientas de soporte,
equipos de pruebas, programas, simulaciones, prototipos, e instalaciones.
SP 1.1 Seleccionar los productos de trabajo para la verifi cacin
Page 66
201
2
Los productos de trabajo son seleccionados de acuerdo con la contribucin

para alcanzar los objetivos y requerimientos del proyecto, y direccionamiento
de los riesgos del proyecto.
Los productos de trabajo a ser verificados pueden incluir los asociados con
mantenimiento, entrenamiento, y soporte de servicios. Los requerimientos de
los productos de trabajo para verificacin son incluidos con los mtodos de
verificacin. Los mtodos de verificacin direccionan el enfoque para la
verificacin de los productos de trabajo, y los enfoques especficos que sern
utilizados para verificar que productos de trabajo especficos alcanzan los
requerimientos.
Ejemplos de mtodos de verificacin incluyen: evaluacin de la arquitectura del
software, y evaluacin de la conformidad de la implementacin; pruebas de
cobertura de rutas, pruebas de carga estrs y performance; pruebas basadas
en la descomposicin funcional, integracin continua, etc.
La verificacin para ingeniera de sistemas tpicamente incluye prototipos,
modelos y simulacin para verificar la adecuacin del diseo del sistema.
La seleccin de los mtodos de verificacin tpicamente comienza con la
definicin de los requerimientos del producto y componentes de producto para
asegurar que los requerimientos sean verificables. Los proveedores deberan
estar envueltos en esta seleccin para asegurarse que los mtodos del
proyecto son apropiados para su ambiente.
Ejemplos de productos de trabajo son: listas de productos de trabajo
seleccionados para la verificacin, mtodos de verificacin para cada producto
de trabajo seleccionado.
Las subprcticas son: identificar productos de trabajo para verificacin;
identificar requerimientos a ser satisfechos por cada producto de trabajo
seleccionado; identificacin de mtodos disponibles para utilizacin; definir los
mtodos de verificacin para ser utilizados por cada producto de trabajo;
presentar para integracin con el plan del proyecto la identificacin de
productos de trabajo a ser verificados, los requerimientos a satisfacer, y los
mtodos a utilizar.
SP 1.2 Establecer el ambiente de verifi cacin

Un ambiente debe ser establecido para permitir que la verificacin tenga lugar.
El ambiente de verificacin puede ser adquirido, desarrollado, reusado,
Page 67
modificado u obtenido usando una combinacin

dependiendo de las necesidades del proyecto.
de
esas
201
2
actividades,
El tipo de ambiente requerido depende de los productos de trabajo

seleccionados para la verificacin y los mtodos utilizados. Una revisin de
pares puede requerir poco ms que un paquete de materiales, revisores y una
sala. Las pruebas de un producto pueden requerir simulacin simuladores,
emuladores, generadores de escenario, herramientas de reduccin de datos,
controles ambientales, e interfaces con otros sistemas.
Productos de trabajo de esta prctica especfica son, por ejemplo, ambientes
de verificacin.
Las subprcticas son: identificacin de requerimientos ambientales de
verificacin; identificacin de recursos de verificacin que estn disponibles
para reutilizacin o modificacin; identificacin de equipos y herramientas;
adquirir equipos y ambientes de soporte para la verificacin.
SP 1.3 Establecer los procedimientos y criterios de verifi cacin

Los criterios de verificacin son definidos para asegurar que los productos de
trabajo cumplen con los requerimientos.
Algunos ejemplos de fuentes de criterios de verificacin incluyen:
requerimientos de productos y componentes de producto, estndares, polticas
de la organizacin, tipos de productos de trabajo, proveedores, propuestas y
contratos, etc.
Ejemplos de productos de trabajo son: procedimientos de verificacin, y
criterios de verificacin.
Las subprcticas son: generar un set de procedimientos de verificacin
exhaustivo, integrado, para productos de trabajo y productos comerciales fuera
de plataforma, segn ser necesario; desarrollar y refinar los criterios de
verificacin como sea necesario; identificar los resultados esperados,
tolerancias permitidas, y otros criterios para satisfacer los requerimientos;
identificar equipo y componentes ambientales necesarios para dar soporte a la
verificacin.
Page 68
201
2
SG 2 Realizar revisiones de pares

Las revisiones de pares comprenden un examen metdico de productos de
trabajo por los pares para identificar defectos a remover, y para recomendar
otros cambios necesarios.
Las revisiones de pares son una parte importante y un mtodo de verificacin
efectivo, implementado por medio de inspecciones, recorridos estructurados, u
otros tantos mtodos de revisin colectivos.
Las revisiones de pares son primariamente aplicadas a productos de trabajo
desarrollados por los proyectos, pero pueden ser tambin aplicados a otros
productos de trabajo tales como documentacin o productos de entrenamiento
que son tpicamente desarrollados por grupos de soporte.
SP 2.1 Preparacin para revisiones de pares

Las actividades de preparacin para las revisiones de pares tpicamente
incluyen identificar al personal que ser invitado a participar de la revisin para
cada uno de los productos, identificar los revisores clave que deben participar
en la revisin de pares, preparar y actualizar materiales a ser utilizados
durante las revisiones de pares, tales como listas de verificacin y criterios de
revisin, y programar las revisiones.
Algunos ejemplos de productos de trabajo son: cronograma de revisin de
pares; listas de verificacin; criterios de entrada y salida de productos de
trabajo, productos seleccionados para ser revisados, etc.
La subprctica es determinar el tipo de revisin de par a ser realizada; definir
los requerimientos para recoger los datos durante la revisin, establecer y
mantener criterios de entrada y salida; establecer y mantener criterios para
requerir otra revisin; establecer y mantener listas de verificacin para
asegurar que los productos son revisados consistentemente, desarrollar un
cronograma detallado de revisiones, incluyendo fechas de ejecucin y cuando
los materiales para la revisin estarn disponibles; asegurar que el producto de
trabajo satisface los criterios de entrada a la revisin previamente a la
distribucin; distribuir el producto de trabajo a ser revisado y la informacin
relacionada a los participantes suficientemente temprano como para
permitirles prepararse adecuadamente a la revisin; asignar roles para la
revisin, tales como lder, lector, grabador, autor; prepararse para la revisin
revisando el producto de trabajo antes de conducir la revisin.
Page 69
201
2
SP 2.2 Conducir las revisiones de pares

Uno de los propsitos de realizar una revisin de pares es definir y remover
temprano los defectos. Las revisiones de pares se realizan incrementalmente
mientras los productos de trabajo estn siendo desarrollados. Estas revisiones
estn estructuradas y no son revisiones de gerencia.
Las revisiones de pares pueden ser realizadas en productos clave de
especificacin, diseo, prueba y actividades de implementacin, y en
productos especficos de planificacin.
El foco de las revisiones de pares debe ser el producto en revisin, no en la
persona que lo produce.
Cuando surgen problemas durante la revisin, deben ser comunicados al
desarrollador primario del producto a corregir.
Las revisiones de pares deben seguir las siguientes guas: deben tener
suficiente preparacin, la realizacin debe ser gestionada y controlada, datos
consistentes y suficientes deben ser grabados, y deben ser registrados tems
de accin.
Ejemplos de los productos de trabajo son: resultados de las revisiones,
problemas de las revisiones y datos de la revisin de pares.
Las subprcticas son: realizar los roles asignados en la revisin de pares;
identificar y documentar los defectos y otros problemas en el producto;
registrar los resultados de la revisin, incluidos los tems de accin; recolectar
datos de la revisin de pares; identificar tems de accin y comunicar los
problemas a las partes interesadas relevantes; realizar revisiones adicionales si
fueran necesarias; asegurar que los criterios de salida para la revisin estn
satisfechos.
SP 2.3 Analizar los datos de las revisiones de pares

Esta prctica especifica trata de analizar datos de la preparacin, realizacin y
resultados de la revisin de pares. Para ms informacin sobre la obtencin de
datos de medida y su anlisis se puede aplicar el rea de proceso de Medicin
y anlisis.
Ejemplos de productos de trabajo son: datos de revisin de pares; tems de
accin de las revisiones de pares.
Page 70
201
2
Las subprcticas son: registro de datos relacionados con la preparacin,

ejecucin y resultados de las revisiones de pares; almacenamiento de los datos
para futuro anlisis y referencia; proteccin de los datos para asegurar que las
revisiones de pares no son utilizadas en forma inapropiada; anlisis de los
datos de las revisiones de pares.
SG 3 Verificar los productos de trabajo seleccionados

Mtodos de verificacin; procedimientos, y criterios son utilizados para verificar
productos de trabajo seleccionados y el mantenimiento, entrenamiento y
servicios de soporte asociados, utilizando el ambiente de verificacin
apropiado. Las actividades de verificacin deben ser realizadas a travs de
todo el ciclo de vida del producto. Las prcticas relacionadas con las revisiones
de pares como mtodo especifico se incluyeron ya en el SG 2.
SP 3.1 Realizar la verifi cacin

La verificacin de productos y productos de trabajo de forma incremental
promueve la deteccin temprana de problemas y puede resultar en una
temprana remocin de los defectos. Los resultados de verificacin ahorran los
considerables costos de defectos de aislamiento y retrabajo asociados con la
solucin de problemas.
Ejemplos de productos de trabajo son: resultados de verificacin, reportes de
verificacin, demostraciones y log de procedimientos como fueron ejecutados.
Las subprcticas son: realizar la verificacin de productos de trabajo
seleccionados contra los requerimientos; registro de los resultados de las
actividades de verificacin; identificacin de tems de accin resultantes de la
verificacin de productos de trabajo; documentacin de los mtodos de
verificacin como fueron ejecutados y desviaciones de los mtodos y
procedimientos disponibles descubiertos durante su rendimiento.
SP 3.2 Analizar los resultados de la verifi cacin

Los resultados reales deben ser comparados contra los criterios de verificacin
establecidos para determinar la aceptabilidad.
Los resultados del anlisis son registrados como evidencia de que la
verificacin fue realizada.
Page 71
201
2
Para cada producto de trabajo, todos los resultados de verificacin disponibles

son analizados incrementalmente para asegurar que los requerimientos se han
alcanzado. Como las revisiones de pares son parte de los mtodos de
verificacin, los datos de stas deben ser incluidos en el anlisis para asegurar
que los resultados de la verificacin son suficientemente analizados.
Reportes de anlisis o documentacin del mtodo as run puede tambin
indicar que los resultados negativos de una verificacin son debidos a un
problema de mtodo, de criterio o a un problema del ambiente de verificacin.
Ejemplos de productos de trabajo son: reporte de anlisis, reporte de dificultad,
pedios de cambios para mtodos, criterios y ambiente de verificacin.
Las subprcticas son: comparar los resultados reales con los esperados; segn
los criterios de verificacin, identificar los productos que no alcanzan sus
requerimientos o identificar problemas con mtodos, procedimientos, criterios
y de ambiente de verificacin; anlisis de datos de defecto; registro de todos
los resultados del anlisis en un reporte, utilizar los resultados de verificacin
para comparar las medidas y rendimiento reales con los parmetros tcnicos
de performance; proveer la informacin de cmo los defectos pueden ser
resueltos e iniciar la accin correctiva.
Sobre las acciones correctivas, ms datos pueden ser hallados en el rea de
proceso de monitoreo control de proyectos.
Page 72
201
2
Norma ISO/IEC 12207, IEEE 12207-2008 Ingeniera de

sistemas y de software Ciclo de vida de los procesos
de software
La norma ISO/IEC 12207 fue publicada en Agosto de 1995 y fue el primer
estndar internacional en proveer un set exhaustivo de procesos de ciclo de
vida, actividades y tareas para software que sea parte de un sistema mayor.
En el 2002 y 2004 se hicieron enmiendas a la norma, agregando propsitos de
proceso y salidas, y estableciendo un Modelo de Proceso de Referencia, de
acuerdo con los requerimientos de la norma ISO/IEC 15504-2, Ingeniera de
software evaluacin de proceso.
Esta norma puede ser utilizada de diferentes maneras: por una organizacin,
para ayudar a establecer un ambiente de procesos deseados, utilizando la
norma para evaluar la conformidad de los procesos de ciclo de vida con lo
dispuesto; por un proyecto, para ayudar a seleccionar, estructurar, y emplear
los elementos de un set de procesos de ciclo de vida establecidos, utilizando la
norma para evaluar la conformidad del proyecto respecto del ambiente
declarado y establecido; por un adquiriente y un proveedor, ayudando a
desarrollar un acuerdo concerniente a actividades y procesos, utilizando la
norma como gua en el desarrollo del acuerdo; por organizaciones y asesores,
para realizar evaluaciones que pueden ser utilizados como soporte en la
mejora de los procesos organizacionales.
Alcance, propsito, limitaciones y conformidad de la norma

Esta norma establece un marco comn para los procesos de ciclo de vida de
software: contiene procesos, actividades y tareas que han de aplicarse durante
la adquisicin de un producto o servicio de software y durante el suministro,
desarrollo, operacin, mantenimiento y eliminacin de productos de software.
La norma aplica a la adquisicin de sistemas y productos y servicios de
software, al suministro, desarrollo, operacin, mantenimiento y eliminacin de
productos de software y a la parte de software de un sistema, ya sean
realizadas interna o externamente a una organizacin.
Tambin provee un proceso que puede ser empleado para definir, controlar y
mejorar los procesos del ciclo de vida del software.
Page 73
201
2
El propsito de esta norma es proveer un set de procesos definidos para

facilitar la comunicacin entre adquirientes, proveedores, y otras partes
interesadas en el ciclo de vida de un producto de software. Esta norma est
pensada para el uso en situaciones de dos partes, y puede ser igualmente
aplicada cuando las dos partes son de la misma organizacin.
Esta norma no detalla los procesos de ciclo de vida en trminos de mtodos o
procedimientos requeridos para alcanzar los requerimientos y salidas de un
proceso; no detalla documentacin en trminos de nombre, formato, contenido
explcito y medios de registro; s puede requerir el desarrollo de documentos de
tipo o clase similar, como por ejemplo varios planes, pero esto no implica que
estos documentos deban ser desarrollados de cierto modo, estas decisiones se
dejan a criterio del usuario de la norma.
Tampoco se prescribe un modelo especfico de ciclo de vida de sistemas o
software, metodologa de desarrollo, mtodo, modelo o tcnica, sino que el
modelo elegido debe ser mapeado con los procesos, actividades y tareas de la
norma.
La conformidad con esta norma puede ser completa o adaptada a medida.
La conformidad completa se alcanza demostrando que todos los
requerimientos del conjunto de procesos declarados han sido satisfechos,
utilizando los resultados como evidencia.
La conformidad a medida est dada cuando la norma se utiliza como base para
establecer un conjunto de procesos que no llegan a alcanzar la conformidad
completa, pero las clusulas de la norma son seleccionadas o modificadas de
acuerdo con el proceso de adaptacin descripto en el anexo A de la misma
norma, y se demuestra que los requerimientos para los procesos, del modo que
han sido adaptados, han sido satisfechos, utilizando los resultados como
evidencia.
Aplicacin de la norma
En general esta norma aplica tanto a productos como servicios de software. Las
disposiciones de procesos especficos definen la aplicabilidad.
En esta norma se establece un fuerte vnculo entre sistema y software, basado
en los principios generales de la ingeniera de sistemas. El software es tratado
como una parte integral del sistema total, y desarrolla ciertas funciones en el
sistema.
Page 74
201
2
Una premisa fundamental en este estndar es que el software siempre existe

en el contexto de un sistema.
Esta norma tiene una fuerte relacin con ISO/IEC 15288:2008, Procesos de ciclo
de vida de sistemas, y puede ser utilizada en conjunto con sta.
En caso de que las porciones que no son de software de un sistema sean muy
pocas, y se quiera aplicar esta norma sin referencia a la 15288, contiene los
procesos adicionales a nivel de sistema, para proveer un contexto mnimo
apropiado para el software.
Respecto de todo el ciclo de vida, en nuestro anlisis focalizaremos en las
tareas referidas a: evaluacin, aseguramiento de la calidad, verificacin,
validacin, revisin, auditora; y ms especficamente en lo referido al testing
del software.
Las organizaciones envueltas en cualquier proceso del ciclo de vida realizan
evaluaciones de los productos. Los procesos de verificacin y validacin
proveen la oportunidad de evaluaciones adicionales. Estos procesos son
realizados por el adquiriente, el proveedor, o por un grupo independiente para
verificar y validar los productos con una profundidad variante dependiendo del
proyecto. Estas evaluaciones no duplican o reemplazan otras evaluaciones,
sino que las suplementan. Otras oportunidades de evaluacin se dan en los
procesos de Revisin de Software, Auditora de software, Aseguramiento de la
calidad del software, y Gerenciamiento del modelo de ciclo de vida.
Categoras de procesos del ciclo de vida

Esta norma agrupa las actividades que pueden ser realizadas durante el ciclo
de vida de un sistema de software en siete grupos de procesos. Cada uno de
los procesos del ciclo de vida dentro de esos grupos es descripto en trminos
de su propsito, salidas deseadas, y lista de actividades y tareas que necesitan
ser realizadas para alcanzar esas salidas.
1)
2)
3)
4)
5)
6)
7)
Proceso de contrato
Proceso de habilitacin organizacional del proyecto
Procesos de proyecto
Procesos tcnicos
Procesos de implementacin del software
Procesos de soporte del software
Procesos de reutilizacin del software
Page 75
201
2
Todos estos procesos estn descriptos y definidos a lo largo de las diferentes

clusulas de la norma (5, 6 y 7). Las dos mayores sub-divisiones de procesos
estn en las clusulas 6, que provee un contexto para sistema para tratar con
productos o servicios de software independientes o sistemas de software, y 7,
que contiene los procesos especficos de software para utilizar en la
implementacin de productos o servicios de software como elementos de un
sistema mayor.
Dentro de estas clusulas nuestra investigacin se centrar, como ya fue
anticipado, en los procesos especficos del software de la clusula 7, y ms en
particular en las clusulas 7.1.7 (Pruebas de calificacin del software), 7.2.3
(Aseguramiento de la calidad del software), 7.2.4 (Verificacin del software),
7.2.5 (Validacin del software), 7.2.6 (Revisin del software) y 7.2.7 (Auditora
del software).
Page 76
201
2
Procesos especficos de software

Procesos de implementacin de software
Los procesos de implementacin del software son utilizados para producir un
elementos especfico del sistema (tem de software) implementado en
software. Estos procesos transforman comportamientos especificados,
interfaces y restricciones de implementacin en acciones de implementacin
resultando en un elemento de sistema que satisface los requerimientos
derivados de los requerimientos de sistema.
El propsito es producir un elemento de sistema especificado implementado
como producto o servicio de software.
El proceso dentro del cual se encuentran los procesos de implementacin es el
Proceso de Implementacin de Software. Este tiene varios procesos especficos
de software de menor nivel:
a) Proceso de anlisis de requerimientos de software: su propsito es
establecer los requerimientos de los elementos de software del sistema
b) Proceso de diseo de arquitectura de software: su propsito es proveer
un diseo para el software implementado y puede ser verificado contra
los requerimientos.
c) Proceso de diseo de detalle del software: su propsito es proveer un
diseo para el software que implementa y que puede ser verificado
contra los requerimientos y la arquitectura del software, y es
suficientemente detallado como para permitir codificacin y testing.
d) Proceso de construccin del software: su propsito es producir unidades
de software ejecutable que reflejan apropiadamente el diseo del
sistema.
e) Proceso de integracin del software: su propsito es combinar las
unidades y los componentes de software produciendo tems de software
integrado, consistentes con el diseo de software, que demuestra que
los requerimientos funcionales y no funcionales del software estn
satisfechos en una plataforma operacional completa o equivalente.
f) Proceso de testing de calificacin del software: su propsito es confirmar
que el producto de software integrado alcanza los requerimientos
definidos.
Procesos de soporte de software
Los procesos de soporte de software proveer un set de actividades
especficamente enfocadas para realizar un proceso de software especializado.
Un proceso de soporte asiste al proceso de implementacin de software como
Page 77
201
2
una parte integral con un propsito distinto., contribuyendo al xito y calidad

del proyecto de software. Hay ocho procesos de soporte:
a)
b)
c)
d)
e)
f)
g)
h)
Proceso
Proceso
Proceso
Proceso
Proceso
Proceso
Proceso
Proceso
de
de
de
de
de
de
de
de
gestin de la documentacin del software:

gestin de la configuracin del software
aseguramiento de la calidad del software
verificacin del software
validacin del software
revisin del software
auditora del software
resolucin de problemas del software
Procesos de reutilizacin de software

Los procesos de reutilizacin del software consisten en tres procesos que
soportan la habilidad de una organizacin de reutilizar tems de software a
travs de los lmites del proyecto. Estos procesos son nicos porque, por su
naturaleza, operan fuera de los lmites de cualquier proyecto particular.
a) Proceso de dominio de la ingeniera
b) Proceso de gestin de reutilizacin de bienes
c) Proceso de gestin de reutilizacin de programas
Procesos relacionados con la calidad del software

Proceso de testing de calificacin del software
Propsito
El propsito del proceso de pruebas de calificacin del software es confirmar
que el producto de software integrado alcanza sus requerimientos definidos.
Salidas
Como resultado de una implementacin exitosa del proceso de testing de
calificacin del software:
-
Criterios para el software integrado es desarrollado, el cual demuestra

conformidad con los requerimientos de software
El software integrado es verificado utilizando el criterio definido
Los resultados de test son registrados
Una estrategia de regresin es desarrollada y aplicada para re-testear el
software integrado cuando se realizan cambios en los tems de software.
Page 78
201
2
Actividades
El proyecto deber implementar las siguientes actividades de acuerdo con las
polticas aplicables de la organizacin y procedimientos con respecto al proceso
de testing de calificacin del software.
Testing de calificacin del software:

Para cada tem de software esta actividad consiste en las siguientes tareas:
1. El implementador conducir el testing de calificacin de acuerdo con los
requerimientos de calificacin para el tem de software. Ser asegurado
que la implementacin de cada requerimiento es testeado para
conformidad. Los resultados sern documentados.
2. El implementador actualizar la documentacin de usuario segn sea
necesario.
3. El implementador evaluar el diseo, cdigo, pruebas, resultados de las
pruebas y documentacin de usuario considerando los siguientes
criterios:
a. Cobertura de los requerimientos en las pruebas del tem de
software
b. Conformidad con los resultados esperados
c. Factibilidad de integracin de sistema y testing, de realizarse
d. Factibilidad de operacin y mantenimiento
4. El implementador dar apoyo a las auditoras de acuerdo con la subclusula 7.2.7 (proceso de auditora de software). Los resultados sern
documentados. Si ambos, hardware y software estn en desarrollo o
integracin, las auditoras podran ser pospuestas hasta el Testing de
calificacin del sistema.
5. Al completarse exitosamente las auditoras, de realizarse, el
implementador actualizar y preparar el producto de software
entregable para Integracin de Sistema, Testing de calificacin de
sistema, Instalacin de software, o Soporte de aceptacin de software,
segn sea aplicable.
Proceso de aseguramiento de la calidad del Software

Propsito
El propsito del proceso de aseguramiento de la calidad del software es
proveer aseguramiento de que los productos de trabajo y los procesos estn
conforme a los planes dispuestos.
Page 79
201
2
Salidas
Como resultado de la implementacin exitosa del proceso de aseguramiento de
calidad del software:
-
Se desarrolla una estrategia para conducir aseguramiento de la calidad

del software
Se produce y mantiene evidencia del aseguramiento de la calidad del
software
Se identifican y registran problemas y disconformidades con los
requerimientos
Se verifica la adhesin de los productos, procesos y actividades a los
estndares, procedimientos y requerimientos aplicables
Actividades
aseguramiento de la calidad del software.
Implementacin del proceso

Consiste en las siguientes tareas:
1. Se establecer un proceso de aseguramiento de la calidad adecuado al
proyecto, para asegurar que los productos de software y los procesos
empleados estn de acuerdo con los requerimientos establecidos, y
adhieren a los planes establecidos.
2. El proceso de aseguramiento de la calidad debe ser coordinado con los
procesos relacionados de Verificacin (sub-clausula 7.2.4), Validacin
(sub-clusula 7.2.5), Revisin de Software (sub-clusula 7.2.6) y
Auditora (sub-clusula 7.2.7).
3. Se desarrollar, documentar, implementar y mantendr, para la vida
del contrato, un plan para conducir las actividades y tareas del proceso
de aseguramiento de calidad. Ese plan incluir:
a. Estndares de calidad, metodologas, procedimientos, y
herramientas, para realizar las actividades de aseguramiento de la
calidad
b. Procedimiento para revisin de contrato y coordinacin del mismo
c. Procedimientos para identificar, recolectar, completar, mantener y
disponer de los registros de calidad
d. Recursos, cronograma, y responsabilidades para conducir las
actividades de aseguramiento de la calidad
Page 80
201
2
e. Seleccin de actividades y tareas de los procesos de soporte, tales

como Verificacin, Validacin, Revisin, Auditora, y Resolucin de
problemas.
4. Se ejecutarn las actividades y tareas de aseguramiento de la calidad
programadas y en curso. Cuando se encuentren problemas o no
conformidades con los requerimientos del contrato, debern ser
documentados y servir de input para el proceso de Resolucin de
problemas. Los registros de estas actividades y tareas, su ejecucin,
problemas y resolucin de problemas sern preparados y mantenidos.
5. Los registros de las actividades y tareas de aseguramiento de la calidad
estarn disponibles para el adquiriente, como se especifique en el
contrato.
6. Deber ser asegurado que las personas responsables de asegurar la
conformidad con los requerimientos del contrato tienen la libertad
organizacional, recursos y autoridad que permita evaluaciones objetivas
e iniciar, efectuar, resolver y verificar la resolucin de problemas.
Aseguramiento del producto
1. Ser asegurado que todos los planes requeridos por el contrato estn
documentados, estn de acuerdo con el contrato, son mutuamente
consistentes, y se estn ejecutando como es requerido
2. Ser asegurado que los productos de software y su documentacin
relacionada estn de acuerdo al contrato y adhieren a los planes.
3. En preparacin a la entrega de los productos de software ser asegurado
que han satisfecho completamente los requerimientos contractuales y
son aceptables para el adquiriente.
Aseguramiento del proceso
1. Ser asegurado que los procesos del ciclo de vida del software
empleados por el proyecto estn de acuerdo con el contrato y adhieren a
los planes
2. Ser asegurado que las prcticas internas de ingeniera de software, el
ambiente de desarrollo, el ambiente de test, y las libreras estn de
acuerdo con el contrato.
3. Ser asegurado que los requerimientos aplicables al primer contrato son
pasados al subcontratista y que los productos de software del
subcontratista satisfacen los requerimientos del primer contrato.
Page 81
201
2
4. Ser asegurado que el adquiriente y otras partes tienen el soporte

requerido y la cooperacin de acuerdo con el contrato, negociaciones y
planes.
5. Debera ser asegurado que las medidas del producto y proceso de
software estn de acuerdo con los estndares y procedimientos
establecidos.
6. Ser asegurado que el personal asignado tiene las habilidades y
conocimientos necesarios para alcanzar los requerimientos del proyecto,
y reciben el entrenamiento necesario.
Aseguramiento de sistemas de calidad
1. Las actividades adicionales de gestin de la calidad podran ser
aseguradas de acuerdo con las clusulas de la norma ISO 9001.
Proceso Verificacin del Software
Propsito
El propsito del proceso de verificacin del software es confirmar que cada
producto de trabajo de software y/o servicio de un proceso o proyecto, reflejan
apropiadamente los requerimientos especificados.
Salidas
Como resultado de una exitosa implementacin del proceso de Verificacin del
software:
-
Una estrategia de verificacin es desarrollada e implementada

Son identificados criterios para verificacin de todos los productos de
trabajo de software
Se realizan las actividades de verificacin requeridas
Los defectos son identificados y registrados
Los resultados de las actividades de verificacin se hacen disponibles
para el cliente y otras partes involucradas.
Actividades
de verificacin de software.
Page 82
201
2

1. Se har una determinacin para ver si el proyecto garantiza un esfuerzo
de verificacin y el grado de independencia organizacional que este
esfuerzo precisa. Los requerimientos del proyecto sern analizados por
criticidad, la cual ser medida en trminos de:
a. El potencial de un error no detectado en un sistema o software
para causar la muerte o daos corporales, fracaso en la misin, o
prdidas financieras o perdidas catastrficas de equipos o daos.
b. La madurez y riesgos asociados con la tecnologa de software a
ser utilizada
c. Disponibilidad de fondos y recursos
2. Si el proyecto garantiza un esfuerzo de verificacin, un proceso de
verificacin ser establecido para verificar el producto de software.
3. Si el proyecto garantiza un esfuerzo de verificacin independiente, se
deber seleccionar una organizacin calificada, responsable de conducir
la verificacin. Dicha organizacin debe ser asegurada de independencia
y autoridad para realizar las actividades de verificacin.
4. Basado en el alcance, la magnitud, complejidad, y anlisis crtico, se
determinaran las actividades del ciclo de vida destino y los productos de
software que requieran verificacin Las actividades y tareas de
verificacin, incluyendo los mtodos asociados, tcnicas y herramientas
para realizar las tareas, sern seleccionados para las actividades del
ciclo de vida destino y productos de software.
5. Basado en las tareas de verificacin determinadas, un plan de
verificacin ser desarrollado y documentado. Dicho plan debe definir
las actividades del ciclo de vida y los productos de software que
requieran verificacin, las tareas de verificacin requeridas en cada
actividad del ciclo de vida y producto de software, y los recursos
relacionados, responsabilidades y cronograma. El plan definir
procedimientos para llevar los reportes de verificacin al adquiriente y
otras organizaciones involucradas.
Verificacin
1. Verificacin de requerimientos: los requerimientos sern verificados
considerando los siguientes criterios:
a. Los requerimientos de sistema son consistentes, factibles y
testeables.
Page 83
201
2
b. Los requerimientos de sistema han sido apropiadamente

asignados a los tems de hardware, a los tems de software, y a las
operaciones manuales de acuerdo con criterios designados.
c. Los requerimientos de software son consistentes, factibles,
testeables, y reflejan apropiadamente los requerimientos de
sistema
d. Los requerimientos de software relacionados con seguridad y
criticidad son correctos y se muestran por mtodos
adecuadamente rigurosos.
2. Verificacin del diseo: el diseo ser verificado considerando los
siguientes criterios:
a. El diseo es correcto y consistente con los requerimientos
trazables.
b. El diseo implementa una secuencia apropiada de eventos,
entradas, salidas, interfaces, flujo de la lgica, asignacin de
tiempo, tamao de los presupuestos, y definicin de errores,
aislamiento, y recuperacin.
c. El diseo seleccionado puede ser derivado de los requerimientos.
d. El diseo implementa seguridad, y otros requerimientos crticos en
forma correcta, como se muestra por mtodos adecuadamente
rigurosos.
3. Verificacin del cdigo: el cdigo ser verificado considerando los
siguientes criterios:
a. El cdigo es trazable al diseo y a los requerimientos, testeable,
correcto y conforme a los requerimientos y a los estndares de
cdigo.
b. El cdigo implementa una secuencia de eventos adecuada, con
interfaces consistentes, datos correctos y control de flujo,
integridad, apropiada asignacin de tiempo y de tamao de los
presupuestos, y definicin de errores, aislamiento y recuperacin.
c. El cdigo seleccionado puede ser derivado del diseo o los
requerimientos.
d. El cdigo implementa seguridad, y otros requerimientos crticos
en forma correcta, como se muestra por mtodos adecuadamente
rigurosos.
4. Verificacin de la Integracin: la integracin ser verificada considerando
los siguientes criterios:
a. Los componentes de software y las unidades de cada tem de
software han sido completa y correctamente integrados en el tem
de software.
b. Los tems de hardware y software y las operaciones manuales del
sistema han sido completa y correctamente integrados al sistema.
c. Las tareas de integracin han sido realizadas de acuerdo con un
plan de integracin.
Page 84
201
2
5. Verificacin de la documentacin: la documentacin ser verificada

considerando los siguientes criterios:
a. La documentacin es adecuada, completa y consistente
b. La preparacin de la documentacin se hace en tiempo
c. La gestin de la configuracin de documentos sigue
procedimientos especficos.
Proceso Validacin del Software
Propsito
El propsito del proceso de validacin del software es confirmar que los
requerimientos para un uso especfico pretendido de producto de trabajo de
software se cumplen.
Salidas
Como resultado de una implementacin exitosa del proceso de validacin del
software:
-
Una estrategia de validacin es desarrollada e implementada

Se identifican criterios para validacin de los productos de trabajo
requeridos
Se realizan las actividades de validacin requeridas
Los problemas son identificados y registrados
Se provee evidencia de que los productos de trabajo de software
desarrollados son adecuados para su uso pretendido
Los resultados de las actividades de validacin se hacen disponibles al
cliente y otras partes involucradas
Actividades
de validacin de software.

1- Se realizar una determinacin sobre si el proyecto garantiza un
esfuerzo de validacin y el grado de independencia organizacional que el
esfuerzo necesita
Page 85
201
2
2- Si el proyecto garantiza un esfuerzo de validacin, un proceso de

validacin ser establecido para validar el sistema o producto de
software. Las tareas de validacin, incluyendo mtodos asociados,
tcnicas, y herramientas para realizar las tareas sern seleccionados.
3- Si el proyecto garantiza un esfuerzo independiente, una organizacin
calificada responsable de conducir el esfuerzo ser seleccionada. El
conductor tendr asegurada la independencia y autoridad para realizar
las tareas de validacin.
4- Un plan de validacin ser desarrollado y documentado. El plan incluir,
pero no se limitara a lo siguiente:
a. Items sujetos a validacin
b. Tareas de validacin a ser realizadas
c. Recursos, responsabilidades, y cronograma para la validacin
d. Procedimientos para entregar los reportes de validacin al
adquiriente y otras partes.
5- El plan de validacin ser implementado. Problemas y disconformidades
detectadas por el esfuerzo de validacin sern ingresadas en el proceso
de Resolucin de problemas de software. Todos los problemas y no
conformidades sern resueltas. Los resultados de las actividades de
validacin se harn disponibles al adquiriente y otras organizaciones
involucradas.
Validacin
1- Preparacin de requerimientos de test seleccionados, y especificaciones
de test para analizar los resultados del test.
2- Asegurar que esos requerimientos de test, casos de test, y
especificaciones de test reflejan el requerimiento particular para el uso
especfico pretendido.
3- Realizar los tests mencionados anteriormente, incluyendo:
a. Testing con estrs, lmites y entradas singulares
b. Testear el producto de software por su habilidad de aislar y
minimizar el efecto de los errores, esto es, teniendo una elegante
degradacin en caso de fallas, requiriendo asistencia del operador
en caso de estrs, lmite y condiciones singulares.
c. Testear que usuarios representativos pueden exitosamente
alcanzar sus tareas pretendidas utilizando el producto de
software.
4- Validar que el producto de software satisface el uso pretendido
5- Testear el producto de software apropiadamente en reas seleccionadas
del ambiente de destino.
Page 86
201
2
Proceso Revisin del Software

Propsito
El propsito del proceso de revisin del software es mantener un entendimiento
comn con las partes interesadas sobre el progreso contra los objetivos del
acuerdo, y que debe ser hecho para ayudar a asegurar el desarrollo de un
producto que satisfaga a las partes interesadas. Las revisiones de software son
tanto de nivel de gerenciamiento del proyecto como tcnico y tienen lugar a
travs de la vida del proyecto.
Salidas
Como resultado de una exitosa implementacin del proceso de revisin del
software:
-
El gerenciamiento y las revisiones tcnicas son tomadas en base a las

necesidades del proyecto.
El estado y productos de las actividades de un proceso son evaluados a
travs de las actividades de revisin.
Los resultados de la revisin son informados a todas las partes
afectadas.
Los tems de accin resultantes de las revisiones son seguidos hasta el
cierre
Los riesgos y problemas son identificados y registrados
Actividades
de Revisin de Software

1- Se realizarn revisiones peridicas en predeterminados hitos, segn est
especificados en el plan del proyecto. Las partes interesadas deben
determinar la necesidad para cualquier revisin ad hoc, en la cual las
partes del acuerdo deberan participar.
2- Todos los recursos que son necesarios para realizar las revisiones sern
provedos. Estos recursos incluyen personal, locacin, instalaciones,
hardware, software, y herramientas.
Page 87
201
2
3- Las partes que participan en una revisin deben acordar en los

siguientes puntos para cada revisin: agenda de la reunin, productos
de software, y problemas a ser revisados; alcance y procedimientos; y
criterios de entrada y salida para la revisin.
4- Los problemas detectados durante las revisiones deben ser registrados e
ingresados en el proceso de resolucin de problemas de software segn
sea requerido.
5- Los resultados de la revisin deben ser documentados y distribuidos.
Esta comunicacin incluye idoneidad de la revisin (aprobacin,
desaprobacin, aprobacin con contingencias) de los resultados de la
revisin.
6- Las partes participantes deben acordar la salida de la revisin y
cualquier responsabilidad de los tem de accin y criterios de cierre
Revisiones de gestin de proyecto
1- El estado del proyecto debe ser evaluado en relacin a los planes de
proyecto aplicables, cronogramas, estndares, y directrices. La salida de
la revisin debe ser considerada por la gerencia apropiada y debe
proveer lo siguiente:
a. Realizacin del progreso de las actividades de acuerdo al plan,
basado en una evaluacin de la actividad del estado del producto
de software.
b. Mantenimiento del control global del proyecto a travs de una
adecuada asignacin de recursos.
c. Cambio de la direccin del proyecto o determinacin de la
necesidad de planes alternativos
d. Evaluar y gestionar el riesgo de los problemas que pueden poner
en peligro el xito del proyecto
Revisiones tcnicas
1- Las revisiones tcnicas deben tener lugar para evaluar los productos o
servicios de software en consideracin y proveer evidencia de que:
a. Estn completos
b. Cumplen con los estndares y especificaciones
c. Los cambios estn apropiadamente implementados y afectan slo
las reas identificadas por el proceso de Gestin de la
configuracin
d. Adhieren a cronogramas aplicables
e. Estn listos para la prxima actividad planificada
Page 88
f.
201
2
El desarrollo, operacin, o mantenimiento est siendo conducido

de acuerdo a los planes, cronogramas, estndares y directrices del
proyecto.
Proceso Auditora del Software

Propsito
El propsito del proceso de auditora del software es determinar,
independientemente, la conformidad de productos y procesos seleccionados
con los requerimientos, planes y acuerdos, segn sea apropiado.
Salidas
Como resultado de una exitosa implementacin del proceso de Auditora de
software:
-
Se desarrolla e implementa una estrategia de auditora

La conformidad de productos o servicios de trabajo de software
seleccionados o procesos, con los requerimientos, planes y acuerdos se
determina de acuerdo a la estrategia de auditora.
Las auditoras son conducidas por un grupo apropiadamente
independiente
Los problemas detectados durante la auditora son identificados y
comunicados a los responsables de las acciones correctivas y
resoluciones.
Actividades
de Auditora de Software

1- Auditoras deben ser realizadas en predeterminados hitos segn se
especifica en el plan del proyecto.
2- El personal auditor no debe tener ninguna responsabilidad directa por los
productos de software y las actividades que audita
3- Todos los recursos requeridos para realizar las auditoras deben ser
acordados por las partes. Estos recursos incluyen personal de soporte,
ubicacin, instalaciones, hardware, software, y herramientas.
Page 89
201
2
4- Las partes deben acordar en los siguientes puntos en cada auditora:

agenda, productos de software (y resultados de la actividad) a ser
revisados, alcance de la auditora, y procedimientos, y criterios de
entrada y salida de la auditora.
5- Los problemas detectados durante las auditoras deben ser registrados e
ingresados en el proceso de Resolucin de problemas de software segn
sea requerido.
6- Despus de completarse la auditora, los resultados deben ser
documentados y provistos a la parte auditada. La parte auditada deber
reconocer a la parte auditora cualquier problema encontrado en la
auditora y los planes relacionados para resolver el problema.
7- Las partes acordarn en la salida de la auditora y cualquier
responsabilidad sobre los puntos de accin y criterios de cierre.
Auditora de Software
1- Las auditoras de software deben ser realizadas para asegurar que:
a. El modo en que estn codificados, los productos de software
reflejan la documentacin del diseo
b. Los requerimientos de testing para la revisin de aceptacin
prescritos en la documentacin son adecuados para la aceptacin
de productos de software
c. Los datos de las pruebas cumplen con la especificacin
d. Los productos de software fueron exitosamente testeaos y
cumplen con las especificaciones.
e. Los reportes de test son correctos y las discrepancias entre los
resultados reales y los esperados han sido resueltas.
f. La documentacin de usuario cumple con los estndares
especificados.
g. Las actividades se han realizado de acuerdo con los
requerimientos, planes y contrato aplicable.
h. Los costos y cronograma adhieren a los planes establecidos.
Page 90
IEEE 829 2008 Estndar para

Documentacin de Test de Sistemas25
201
2
Software
La norma IEEE 829 aplica a todos los sistemas basados en software, soporta
todos los procesos de ciclo de vida y sirve para sistemas que estn siendo
desarrollados, adquiridos, operados, mantenidos y/o reutilizados.
Cuando se realiza el proceso de test es importante examinar el software en sus
interacciones con otras partes del sistema. Esta norma identifica las
consideraciones que los procesos y tareas de test realizan para determinar la
exactitud y otros atributos como integridad, precisin, consistencia, y
testabilidad, y la documentacin resultante que aplica.
El propsito de esta norma es establecer un marco para los procesos,
actividades, tareas de test, en soporte de todos los procesos de ciclo de vida
software; definir tareas, inputs y outputs requeridos, identificar y las mnimas
tareas de pruebas correspondientes a los niveles de integridad definidos en un
esquema de cuatro niveles de integridad; definir el uso y contenidos del Plan
Maestro de Test y del Plan de Nivel de Test; y definir el uso y contenidos de
documentacin de test relacionada (Diseo de test, casos de test,
procedimientos de test, reporte de anomalas, log de test, reporte de nivel de
test, reporte provisional de test, y reporte maestro de test).
Objetivos de testing
Los sistemas basados en software se componen de software, hardware,
interfaces y operadores/usuarios.
Los procesos de test incluyen la consideracin de interacciones con todos los
otros componentes del sistema como medio ambiente, usuarios, hardware y
otro software. Adems proveen evidencia objetiva de que los sistemas basados
en software y sus productos asociados satisfacen los requerimientos de
sistema asignados, resuelven el problema adecuado y satisfacen el uso
pretendido y las necesidades del usuario.
El desarrollo de un cuerpo de evidencia razonable requiere equilibrio entre la
cantidad de tiempo utilizado y un set de condiciones y asunciones finitas de
sistema contra los cuales realizar las tareas de test. Cada proyecto debe definir
criterios para tener un cuerpo de evidencia razonable, cronograma de tiempos,
25 Vid. IEEE Standard for software and System Test Documentation, 2008, pp.18-21
Page 91
201
2
alcance de las tareas de testing, y debe seleccionar los documentos y tpicos

de contenidos que son los ms apropiados basados en esta informacin.
Los procesos de testing proveen una evaluacin objetiva de los productos
basados en software a travs de cada ciclo de vida del proyecto adems de
proveer una evaluacin objetiva del sistema al completarse cada iteracin de
desarrollo, todo el desarrollo y a travs de las fases de operaciones del ciclo.
Esta evaluacin demuestra si los requerimientos del software y del sistema
estn satisfechos.
Otros objetivos de las actividades de testing son: validar que el sistema
satisfaga los requerimientos para su uso pretendido y para las necesidades del
usuario, validar que el problema resuelto es el adecuado, establecer
responsabilidad por los procesos de testing, facilitar la temprana deteccin y
correccin de las anomalas de software y de sistema, proveer una temprana
evaluacin de la performance del software y del sistema, proveer informacin
objetiva a la gerencia para determinar el riesgo de negocio de liberar el
producto en el estado actual, e identificar reas con grupos de anomalas en la
funcionalidad.
El testing da soporte a los procesos primarios del ciclo de vida. Las actividades
de testing son ms efectivas cuando se realizan en paralelo con los procesos
de desarrollo, no slo al finalizar ste.
Este estndar puede ser utilizado de dos formas, con un flujo completo o con
uno parcial.
El flujo completo comienza con el desarrollo o la utilizacin de un esquema de
nivel de integridad; despus se selecciona el nivel de integridad para el
sistema basado en software que requiere documentacin, cuanto ms alto el
nivel de integridad ms rigurosa y extensa es la documentacin requerida;
luego se crea un inventario de todas las tareas de testing; el paso final de este
inventario es la identificacin de las entradas y salidas de cada tarea, las
cuales pueden ser compiladas en una lista de documentos necesitados.
El flujo parcial es utilizado por usuarios que no son responsables de un
programa completo de test, y que pueden querer considerar solo la
documentacin de test ms relevante segn sus responsabilidades, otros
pueden aun no tener o no querer la documentacin completa de test. Los
posibles contenidos para los distintos tipos de documentacin de test son:
documentos de plan, documento de diseo de test, descripcin del caso de
test, procedimientos para la ejecucin de los casos de test.
Page 92
201
2
Niveles de integridad de software y de sistemas

Un esquema de niveles de integridad provee los medios estructurados para
establecer la amplitud y profundidad del testing. Un nivel alto de integridad
requiere testing de mayor profundidad que un nivel menor. Sin un
requerimiento por un nivel especifico de integridad el tester no sabr que
funciones, requerimientos, o productos requieren solo un esfuerzo superficial y
cuales uno ms intenso.
Si un nivel de integridad es obligatorio depende de las necesidades de las
partes interesadas del sistema. El usuario puede seguir el esquema de cuatro
niveles o utilizar uno diferente, sin embargo, de utilizar uno diferente, deber
mapear su esquema con el presentado en la norma. Podra llegar a haber
elementos de software que no requirieran asignacin a un nivel de integridad,
debido a que su falla no tuviera consecuencias en la operacin del sistema, en
ese caso se podra agregar un nivel de integridad cero, cubriendo las fallas que
no tengan consecuencias.
Deber haber una documentacin de niveles de integridad o la decisin de no
utilizar un esquema de niveles de integridad. Esto ser asignado como
resultado de los acuerdos entre todas las partes interesadas.
Niveles de integridad
Un nivel de integridad es un indicador de la relativa importancia del software
para las partes interesadas, de acuerdo con ciertos atributos establecidos tales
como complejidad, evaluacin de riesgos, nivel de seguridad, integridad de los
datos, performance deseada, confiabilidad, calidad, costos, tamao, y otras
caractersticas particulares del software.
Este estndar uso el concepto de niveles de integridad para determinar las
tareas de testing a ser realizadas mnimas recomendadas. Los procesos de test
y la documentacin resultante deben ser ajustados a los requerimientos y
aplicaciones especficos del sistema a travs de la seleccin de un nivel de
integridad.
Como ejemplo este estndar trae un esquema de niveles de integridad de
cuatro niveles, cuyas categoras son definidas basadas en la seriedad de las
consecuencias de un comportamiento errneo y en el potencial de mitigacin.
Cada nivel lleva asociada una palabra descriptiva:
Nivel 4: Catastrfico: el software debe ejecutarse bien o se producirn graves
consecuencias, sin posible mitigacin
Page 93
201
2
Nivel 3: Critico: el software se debe ejecutar correctamente o el uso pretendido

del sistema no ser realizado causando serias consecuencias, es posible una
mitigacin parcial o completa.
Nivel 2: Marginal: el software se debe ejecutar correctamente o una funcin
pretendida no ser realizada, causando consecuencias menores, es posible una
mitigacin completa.
Nivel 1: Despreciable: el software se debe ejecutar correctamente o una
funcin pretendida no ser realizada causando consecuencias despreciables, la
mitigacin no es requerida.
El uso de un esquema de niveles de integridad es una best practice (mejor
prctica) recomendada que facilita la seleccin de las tareas y actividades ms
apropiadas y de los documentos de test necesitados.
Procesos de test
Esta norma sigue la estructura en el estndar IEEE/EIA 12207.0-1996 para
describir los procesos: cada proceso tiene uno o ms actividades de soporte
que son ejecutadas por una o ms tareas. Es un mtodo top-down para
determinar que tareas son requeridas. Una vez que cada tarea ha sido
identificada, los inputs necesarios y outputs resultantes pueden ser
identificados. En el caso de este estndar, los inputs y outputs determinan que
documentacin de test es necesaria.
El testing es un conjunto de actividades orientadas a verificar el cdigo
ejecutable. No obstante, desde otras gestiones se pueden invocar actividades
de testing para adelantar e ir preparando el proceso, como por ejemplo
Planificacin del testing.
En nuestro trabajo hemos analizado la norma ISO/IEC 12207 del ao 2008. Sin
embargo la norma IEEE 829 es anterior a esta, por lo cual soporta procesos de
la norma IEEE 12207.0, los cuales son ligeramente diferentes a los de la ltima
versin.
Los procesos soportados en este caso son:
Gerenciamiento
-
Adquisicin
Suministro
Desarrollo
Operacin
Proceso de mantenimiento
Page 94
201
2
No todos los proyectos de software incluyen cada uno de estos procesos, para
estar en conformidad con la actual norma, los procesos de test necesitan
incluir solo los procesos del ciclo de vida utilizados por el proyecto. El grado de
intensidad y rigor en la realizacin y documentacin de la tarea son
proporcionales al nivel de integridad.
Proceso de Gerenciamiento
El proceso de gerenciamiento de test incluye la preparacin de los planes de
ejecucin de los procesos de test.
Una vez iniciada la implementacin de los planes, ocurren las siguientes
actividades:
Monitoreo del plan de ejecucin

Anlisis de anomalas descubiertas durante la ejecucin del plan
Reporte de progreso de los procesos de prueba
Evaluacin de los resultados de las pruebas para conformidad con las
expectativas
Determinar si una tarea de testing est completa
Chequear los resultados para ver si estn completos
Actividad: gerenciamiento del test

La actividad de gerenciamiento del test monitorea y evala los resultados del
test. Es realizada en todos los procesos y actividades del ciclo de vida. Revisa
continuamente el testing, genera el MTP (Plan de test maestro) si el nivel de
integridad lo requiere, y lo revisa acorde a lo necesario. Genera Planes de test
de nivel, y los revisa segn sea necesario basado en los cronogramas de
proyecto actualizados, y estado de los desarrollos.
Tambin coordina las actividades relacionadas con los resultados del test con el
desarrollador, y otros procesos de soporte como aseguramiento de la calidad,
gestin de la configuracin, revisiones y auditorias.
A travs del uso de mtricas y otras medidas cualitativas y cuantitativas,
desarrolla datos de tendencia de test e identifica posibles problemas de riesgo
que son dados a las organizaciones afectadas, como desarrollo e integracin,
para realizar la oportuna notificacin y resolucin. En hitos importantes el
gerente de testing consolida los resultados del test para establecer evidencia
correspondiente en cuanto a si se debe proceder al siguiente set de actividades
de desarrollo del sistema y del software.
Page 95
201
2
Cuando sea necesario el gerente de testing identificar lecciones aprendidas y

determinar si las tareas de testing deben ser reiteradas por alguna razn.
Las actividades mnimas recomendadas para gerenciamiento del test segn
sea apropiado para el nivel de integridad seleccionado son:
a.
b.
c.
d.
e.
Generar el Plan de Test Maestro (MTP)

Realizar revisiones de gerencia del esfuerzo de test
Realizar revisiones de gerencia y revisin de soporte tcnico
Interfaces con los procesos organizacionales y de soporte
Identificar oportunidades de mejora de procesos, incluyendo lecciones
aprendidas en la realizacin del test.
Proceso de Adquisicin
El proceso de adquisicin comienza con la definicin de las necesidades para
adquirir un sistema, producto de software o servicio de software.
El proceso continua con la preparacin y edicin de un RFP (requerimiento de
propuesta) y con la seleccin de un proveedor. Termina con el gerenciamiento
del proceso de adquisicin a travs de la aceptacin del sistema, producto o
servicio de software. Las tareas de test son ejecutadas a travs del proceso de
adquisicin para darle soporte. Las tareas van desde identificacin de la
documentacin requerida del proveedor en el RFP y el contrato para la
ejecucin del test de aceptacin.
Actividad: soporte de adquisicin

Al comienzo del proceso de adquisicin descripto, la actividad de test realiza
varias tareas que soportan el inicio del proyecto, especialmente el
requerimiento de propuesta y preparacin del contrato. Las tareas de test que
dan soporte al balance del proceso de adquisicin se describen en los procesos
desde suministro hasta mantenimiento.
Los esfuerzos de test realizan, segn sea apropiado para el nivel de integridad
elegido, las siguientes tareas recomendadas como mnimo:
a. Alcance preliminar de los esfuerzos de test
b. Planificacin preliminar de la interfaz entre los esfuerzos de test y el
proveedor
c. Evaluacin de los requerimientos del sistema
d. Establecimiento del criterio del contrato para testing del proveedor.
Page 96
201
2
Proceso de Suministro
El proceso de suministro se inicia sea por una decisin de preparar una
propuesta para responder a un RFP de un adquiriente o mediante la firma y la
creacin de un contrato con el adquiriente para proveer el sistema basado en
software, producto de software o servicio.
El proceso continua con la determinacin de procedimientos y recursos
necesarios para gerenciar el proyecto incluyendo la preparacin del plan del
proyecto, de la ejecucin de los planes a travs de la entrega del sistema
basado en software, producto de software o servicio al adquiriente.
El esfuerzo de test usa el proceso de suministro para continuar determinando
el alcance de los esfuerzos de test. La actividad de plan de test usa los
requerimientos del contrato, incluyendo el cronograma general para revisar y
actualizar la planificacin de las interfaces de test entre el proveedor y el
adquiriente.
Actividad: planificacin del test

Los participantes en la actividad de planificacin de test pueden participar en
las actividades de iniciacin del requerimiento de propuesta, preparacin de la
respuesta, planificacin del contrato, ejecucin y control, revisin y evaluacin,
y entrega y cierre.
El esfuerzo de test realiza de acuerdo con el nivel de integridad elegido, las
siguientes tareas recomendadas como mnimo:
a. Se contina la planificacin de la interfaz entre el esfuerzo de test y el
proveedor.
b. Se contina el alcance del esfuerzo de test
c. Se identifican mtricas
d. Se identifica el nivel de integridad
Proceso de Desarrollo
El proceso de desarrollo consiste en las actividades y tareas del grupo de
desarrollo. Cubre las actividades de desarrollo de anlisis de requerimientos,
diseo, codificacin, integracin de componentes, testing, instalacin, y
aceptacin, relacionadas con el software o el producto de sistema basado en
software.
Las actividades de test verifican los productos de estas actividades de
desarrollo. Las actividades de test descriptas en este estndar estn
Page 97
201
2
organizadas en las actividades del ciclo de vida de concepto, requerimientos,

diseo, implementacin, test e instalacin/check out.
Los usuarios del estndar pueden necesitar ajustar estas actividades para
reflejar las prcticas de sus organizaciones y trazar sus actividades a las
definidas en este estndar.
Actividad: concepto
La actividad de concepto representa la identificacin de una implementacin
especfica para resolver un problema de las partes interesadas o cubrir sus
necesidades. Una arquitectura preliminar de sistema puede ser identificada y
el anlisis de los requerimientos del sistema puede comenzar durante esta
actividad. Durante esta actividad la arquitectura del sistema es seleccionada, y
los requerimientos de sistema son asignados a los componentes de hardware,
software e interfaz de usuario. El objetivo del esfuerzo de test es revisar los
documentos de concepto y requerimientos para comprender mejor las
necesidades del usuario.
Los esfuerzos de test realizan segn sea apropiado a los niveles de integridad,
estas mnimas tareas recomendadas:
a. Revisin de la documentacin de concepto para conocimientos del tester
de las necesidades del usuario.
b. Revisin de los documentos de requerimientos del sistema
c. Generacin preliminar de la matriz de trazabilidad de pruebas
d. Identificacin el nivel de integridad
Actividad: requerimientos
En la actividad de requerimientos se definen los requerimientos funcionales y
no funcionales, seguidos por las interfaces externas al software, requerimientos
de seguridad, definiciones de datos, documentacin de usuario del sistema y
del software, requerimientos de instalacin y aceptacin, requerimientos de
operacin y ejecucin de los usuarios, y requerimientos de mantenimiento.
Durante esta actividad las actividades de testing participan en la verificacin
de los requerimientos de software.
El objetivo del esfuerzo de test en este caso es la verificacin de los
requerimientos de software, verificando la testabilidad y de los
requerimientos asignados, as como tambin ayudando a identificar
ambigedades, poca claridad o requerimientos faltantes.
Page 98
201
2
Durante esta actividad la planificacin de test que se extiende a varias

actividades de desarrollo comienza. El esfuerzo de test realiza de acuerdo con
el nivel de integridad seleccionado, las tareas mnimas recomendadas:
a. Generacin del plan de pruebas de aceptacin
b. Generacin del plan de pruebas de sistema
c. Revisin de los requerimientos de software y de interfaces para
pruebas
d. Identificacin actualizada del nivel de integridad
e. Generacin de la matriz de trazabilidad de pruebas, actualizada
f. Identificacin de riesgos
g. Identificacin de problemas de seguridad.
Actividad: diseo
En la actividad de diseo los requerimientos del sistema son transformados en
arquitectura y diseo detallado para cada componente de software.
El diseo incluye bases de datos e interfaces. Se crea el diseo de arquitectura
del software y del sistema, y el diseo detallado del sistema. El objetivo del
esfuerzo de test en este caso es continuar con la planificacin de las pruebas.
El esfuerzo de test realiza de acuerdo con el nivel de integridad seleccionado
las tareas mnimas recomendadas:
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
Generacin del diseo de las pruebas de aceptacin

Generacin del diseo de las pruebas de sistema
Generacin del plan de pruebas de integracin de componentes
Generacin del diseo de pruebas de integracin de componentes
Generacin del plan de pruebas del componente
Generacin del diseo de pruebas del componente
Identificacin actualizada del nivel de integridad
Generacin de la matriz de trazabilidad de pruebas, actualizada
Identificacin de riesgos - test
Identificacin de problemas de seguridad test
Actividad: implementacin
En la actividad de implementacin el diseo es implementado y se genera el
cdigo, las estructuras de base de datos, y las representaciones de las
ejecuciones relacionadas.
El diseo tambin puede ser implementado en personalizaciones o
configuraciones de componentes o sistemas ya codificados. Esta actividad
incluye creacin o modificacin de software y testing.
Page 99
201
2
El objetivo de los esfuerzos de test en este caso es verificar que las

implementaciones sean correctas, precisas, y completas.
a)
b)
c)
d)
e)
f)
Generacin de casos de prueba de aceptacin

Generacin de procedimientos de prueba de aceptacin
Generacin de casos de prueba de sistema
Generacin de procedimientos de prueba de sistema
Generacin de casos de prueba de integracin de componentes
Generacin de procedimientos de prueba de integracin
componentes
g) Generacin de casos de prueba de componentes
h) Generacin de procedimientos de prueba de componentes
i) Ejecucin de pruebas de componentes
j) Evaluacin de los resultados de pruebas de componentes
k) Preparacin del reporte de pruebas de componentes
l) Generacin de la matriz de trazabilidad de pruebas, actualizada
m) Realizacin de la revisin de preparacin de pruebas
n) Identificacin actualizada del nivel de integridad
o) Identificacin de riesgos - test
p) Identificacin de problemas de seguridad - test
de
Actividad: test
En la actividad de test propiamente dicha se cubre la integracin de los
componentes de software, pruebas de aceptacin de software, integracin del
sistema, y pruebas de aceptacin del sistema. El objetivo es verificar que los
requerimientos de software y de sistema estn satisfechos con la ejecucin de
las pruebas de integracin de componentes, sistema y aceptacin. Las
versiones y releases del software son probados por progresin, es decir
pruebas de caractersticas nuevas y corregidas; y por regresin, es decir
pruebas para asegurar que no han ocurrido cambios indeseados.
a) Ejecucin de pruebas de integracin de componentes
b) Evaluacin de los resultados de las pruebas de integracin de
componentes
c) Preparacin del reporte de las pruebas de integracin de componentes
d) Ejecucin de las pruebas de sistema
e) Evaluacin de los resultados de las pruebas de sistema
f) Preparacin del reporte de las pruebas de sistema
g) Ejecucin delas pruebas de aceptacin
Page 100
h)
i)
j)
k)
201
2
Evaluacin de los resultados de las pruebas de aceptacin

Preparacin del reporte de las pruebas de aceptacin
Identificacin de riesgos
Identificacin de problemas de seguridad
Actividad: instalacin y check out

En la actividad de instalacin/check out se abarca la instalacin del sistema
basado en software, el producto o servicio de software, en el ambiente de
destino, y la revisin de aceptacin y pruebas de producto del adquiriente.
El objetivo de los esfuerzos de test en este caso consiste en dar soporte a la
instalacin y aceptacin del sistema instalado. El objetivo es verificar la
correcta instalacin del sistema en el ambiente de destino.
a) Soporte a las auditoras de instalacin y configuracin, fsicas y
funcionales
b) Realizacin de la instalacin
c) Evaluacin de la instalacin
d) Preparacin del reporte de instalacin
e) Preparacin del informe maestro de las pruebas, de ser requerido
f) Identificacin de riesgos - test
g) Identificacin de problemas de seguridad- test
Proceso de operacin
El proceso de operacin cubre la operacin del producto de software y el
soporte de operacin a los usuarios. La actividad de operacin realiza testing
operacional, operacin del sistema y soporte de usuarios.
Actividad: test operacional

La actividad de test operacional es el uso del sistema basado en software,
producto de software o servicio por el usuario final, en el ambiente de
operacin. La actividad de test operacional realiza el test operacional,
operacin del sistema y soporte de usuario.
Los objetivos de este esfuerzo de test son para validar que el sistema basado
en software, el producto de software o servicio en operacin satisfacen los
Page 101
201
2
requerimientos de usuario y alcanzan las necesidades del negocio de la

organizacin.
a.
b.
c.
d.
e.
f.
Evaluacin de los procedimientos de operacin

Ejecucin de test de operacin
Evaluacin de los resultados del test de operacin
Preparacin del reporte del test de operacin
Identificacin de riesgos test
Identificacin de problemas de seguridad test
Proceso de mantenimiento
El proceso de mantenimiento se activa cuando el sistema basado en software o
el producto de software sufren alguna modificacin en el cdigo y
documentacin asociada debido a algn problema, necesidad de mejora o
adaptacin.
La actividad de mantenimiento consiste en modificaciones, migracin o retiro
del sistema basado en software o producto de software durante el proceso de
operacin.
Las modificaciones sern tratadas como un proceso de desarrollo y sern
verificadas segn el proceso de gestin y desarrollo de esta misma norma.
Los niveles de integridad son evaluados durante el proceso de mantenimiento,
y pueden ser revisados apropiadamente para reflejar los requerimientos del
proceso de mantenimiento. Estas modificaciones pueden ser derivadas de
requerimientos especificados para corregir errores de software, para adaptarlo
a un ambiente de operacin cambiado o para responder a nuevos
requerimientos de usuario o mejoras.
Actividad: test de mantenimiento

La actividad de mantenimiento cubre las modificaciones, migracin, y retiro del
sistema basado en software o producto de software.
Para la migracin de software, que es el movimiento a un nuevo ambiente de
operacin, el esfuerzo de test verifica que el sistema migrado y el software
alcancen los requerimientos de desarrollo y operacin.
Page 102
201
2
El retiro del software es la baja del soporte activo por la organizacin de

operacin y mantenimiento, parcial o total reemplazo por un nuevo sistema o
instalacin de un sistema actualizado.
Si el sistema fue desarrollado bajo este estndar, el mismo debe ser respetado
en el proceso de mantenimiento, si no lo fue, y la documentacin apropiada no
est disponible o no es adecuada, entonces el esfuerzo de test debe
recomendar la generacin de los faltantes. Para esto se tendrn en cuenta los
mnimos requerimientos asignados al nivel de integridad.
La actividad de mantenimiento realiza anlisis de problemas y modificacin,
implementacin de modificacin, revisin y aceptacin de mantenimiento, y
retiro de sistema y software.
Los objetivos del esfuerzo de test son verificar y validar la modificacin,
migracin o retiro de los requerimientos, y repetir las tareas de test del modo
adecuado. Las versiones o releases del software son testeados para progresin
(nuevas caractersticas) y regresin (que no haya cambios no deseados).
a. Revisin de todas la documentacin de test afectada
b. Realizacin de la evaluacin de anomala
c. Test de iteracin de tareas
Proceso de seleccin de contenido de la documentacin de

test
La norma IEEE 829 provee tpicos de contenidos de documentacin a
considerar para incluir en los diferentes documentos de testing. La lista
siguiente est diseada para incluir tantos tpicos de documentacin de test
como sea posible, proveyendo un set comprensivo:
-
Plan maestro de test (MTP)

Plan de nivel de test (LTP)
Diseo de nivel de test (LTD)
Caso de nivel de test (LTC)
Procedimiento de nivel de test (LTPr)
Log de nivel de test (LTL)
Reporte de Anomalas (AR)
Reporte de estado interino de nivel de test (LITSR)
Reporte de nivel de test (LTR)
Reporte maestro de test (MTR)
Page 103
201
2
Los usuarios de la norma pueden elegir agregar, combinar o eliminar todos los
documentos o tpicos de contenidos de documentacin basados en las
necesidades (y nivel de integridad) de sus sistemas individuales.
Cuando el contenido de la documentacin est cubierto en cualquier otro lado,
el esquema del documento puede ser llevado igualmente, haciendo un
esquema al otro documento en el lugar apropiado. Otra alternativa es modificar
el esquema para eliminar tpicos de contenido que no son utilizados. Puede ser
deseable para esquemas modificados proveer una lista de las referencias que
cubren los tpicos de contenido eliminados.
Un enfoque sugerido para adaptar la informacin provista a una circunstancia
especfica incluye consideraciones de:
a. Proveer una referencia a la informacin documentada en otro lugar
b. Eliminar los tpicos de contenido cubiertos por el proceso
c. Eliminar los tpicos de contenido cubiertos por herramientas
automatizadas
d. Combinacin o eliminacin de documentos
e. Combinacin o eliminacin de tpicos de contenido de documentos
Plan maestro de test

El propsito del plan maestro de test es proveer un documento total de plan de
test y gestin de test para mltiples niveles, ya sea en un proyecto o a travs
de mltiples proyectos.
En vista de los requerimientos de software y de la planificacin del
aseguramiento de la calidad del proyecto, el plan maestro de test como
actividad comprende la seleccin de los elementos constitutivos del esfuerzo
de la prueba del proyecto: estableciendo los objetivos de cada parte, la divisin
del trabajo y las interrelaciones entre las partes: identificando riesgos,
asunciones, y estndares de mano de obra a ser considerados y tenidos en
cuenta por las partes; definiendo los controles de los esfuerzos de test; y
confirmando los objetivos aplicables establecidos por la planificacin de
aseguramiento de la calidad. Identifica el esquema de nivel de integridad y el
nivel de integridad seleccionado, el nmero de niveles de test, el total de las
tareas a ser realizadas, y los requerimientos de documentacin.
MTP: introduccin
Introduce las secciones siguientes subordinadas, identifica el documento y lo
ubica en el contexto de ciclo de vida especfico del proyecto. El esfuerzo de
test completo es descripto, incluyendo las organizaciones de test, el
cronograma, es esquema de integridad.
Page 104
201
2
Un resumen de los recursos requeridos, recursos, responsabilidades, y

herramientas y tcnicas pueden tambin ser incluidos en esta seccin.
Identifi cador del documento

Se identificar la versin documento de forma nica incluyendo informacin
tal como la fecha del problema, organizacin, autores, firmas de aprobacin,
estado, versin, puede incluir tambin revisores y gerentes.
Alcance
Describe el propsito, goles y alcance del esfuerzo de pruebas del sistema o
software. Incluye la descripcin de cualquier adaptacin del estndar que ha
sido implementado. Se identifica el proyecto para el cual el plan se est
escribiendo y los procesos especficos y productos cubiertos por el esfuerzo de
test. Se describen las inclusiones, exclusiones, asunciones, limitaciones.
Es importante definir claramente los lmites del esfuerzo de test para cualquier
plan de test. Est implcito que las tareas de test reflejaran el enfoque global y
la metodologa de desarrollo. La documentacin requerida depender del
enfoque de test elegido.
Referencias
Se listan todos los documentos de referencia que aplican. Las referencias son
separadas en externas que son impuestas externamente al proyecto, e
internas que son impuestas dentro del proyecto.
Visin de conjunto del sistema y caractersticas clave

Describe la misin o propsito de negocio del sistema o software que se est
testeando. Se describen las caractersticas principales del sistema o software
en test.
Visin de conjunto del test

Se describe la organizacin de test, el cronograma, el esquema de nivel de
integridad, los recursos, las responsabilidades, herramientas, tcnicas, y
mtodos necesarios para realizar el testing.
MTP: Detalles del plan maestro de test

Introduce las secciones siguientes subordinadas, describe los procesos de test,
los requerimientos de documentacin de test, y los requerimientos de reporte
de test para todo el esfuerzo de test.
Page 105
201
2
Procesos de test incluyendo defi nicin de niveles de test

Se identifican las actividades y tareas a ser realizadas para cada proceso de
test y se documentan. Se provee una visin general de las actividades de test y
tareas para todos los procesos del ciclo de vida del desarrollo, se identifica el
nmero y secuencia de los niveles de test, podra haber un nmero diferente
de niveles, respecto de los provistos en el estndar. La integracin es
frecuentemente llevada a cabo a travs de una serie de niveles de test, tanto
para integracin de componentes y de sistemas.
Procesos del ciclo de vida
Se describe como todos los requerimientos del estndar son satisfechos si el
ciclo de vida utilizado en el MTP es diferente del modelo del estndar. Testing
requiere una planificacin avanzada que se extiende a varias actividades de
desarrollo.
Para cada actividad de test se identifican las tareas de test a ser realizadas, se
describen los mtodos y procedimientos para cada tarea de test, incluyendo las
herramientas, se identifican los inputs y outputs requeridos para y por la tarea,
se describe el cronograma para la tarea de test, se identifican los recursos por
la performance de las tareas de test, se identifican los riesgos y las asunciones
relacionadas con las tareas de test, y se identifican los roles y
responsabilidades para cada tarea de test.
Requerimientos de documentacin de test

Se define el propsito, el formato, y contenido de todos los otros documentos
de se van a utilizar. Si el esfuerzo de test utiliza documentacin de test o
niveles de test diferentes a los del estndar, esta seccin necesita mapear la
documentacin y requerimientos del proceso con el contenido de la
documentacin de test definidos en este estndar.
Requerimientos de administracin de test

Se describe la resolucin de anomala y el proceso de reporting, la poltica de
iteracin de tareas, poltica de desviacin, procedimientos de control y
estndares, prcticas y convenciones.
Page 106
201
2
Estas actividades son necesitadas para administrar las pruebas durante la

ejecucin.
Requerimientos de reportes de test

Especifica el propsito, contenido, formato, destinatarios, y tiempos de todos
los reportes de test, Los reportes de test consisten en Logs de test, Reportes de
anomalas, Reportes de estado interino de nivel de test, Reportes de nivel de
test, y Reporte maestro de Test. Tambin pueden incluir reportes opcionales
definidos por el usuario de la norma. El formato y agrupacin de estos es
definido por el usuario y vara de acuerdo con la materia.
MTP: General
Introduce las secciones subsiguientes. Esta seccin incluye el glosario de
trminos y acrnimos.
Tambin describe la frecuencia y el proceso por el cual el MTP es cambiado
creada su lnea de base.
Tambin puede contener una pgina de cambios, con el historial de todos los
cambios, fecha, razn, y quien lo realiz.
Plan de nivel de test

En cada plan de nivel de test se especifica el alcance, enfoque, recursos, y
cronograma de las actividades de testing para el nivel de testing especificado.
Se identifican los tems a ser testeados, caractersticas, las tareas a ser
realizadas, el personal responsable por cada tarea, y los riesgos asociados. En
el ttulo del plan la palabra nivel es reemplazada por el nombre que la
organizacin le da al nivel particular que est siendo documentado (ej.: plan de
test de componentes, plan de test de sistema, etc).
En la mayora de los proyectos hay niveles diferentes de test, requiriendo
diferentes recursos, mtodos y ambientes. Como resultado cada nivel se
describe mejor en un plan diferente. Algunos ejemplos de niveles de test para
desarrollo de actividades a tener en cuenta son:
-
Cada unidad de software

Unidades integradas y componentes
Pruebas para cada requerimiento de software
Pruebas de calificacin de software para todos los requerimientos
Page 107
201
2
Integracin de sistema: agregados de otros tems de configuracin de

software, hardware, operaciones manuales, y otros sistemas. No es
inusual para sistemas grandes tener mltiples niveles de integracin de
test.
Test de calificacin de sistema para requerimientos de sistema.
LTP: introduccin
Introduce las secciones subordinadas siguientes. En esta seccin se identifica
el documento y se lo pone en contexto del esfuerzo de test y del ciclo de vida
especfico del proyecto. Esta seccin tambin identifica los tipos de test y las
condiciones para los niveles especficos de testing.
Identifi cador del documento

Los datos son similares al identificador del documento maestro de test antes
comentado (MTP)
Alcance
Se realiza un resumen de los productos de software o tems de sistema y
caractersticas a ser testeadas en este nivel en particular. La necesidad de
cada tem y su historia debe ser incluida. Esta seccin puede ser una referencia
a partes del MTP, una adicin al este o reflejar cambios.
Referencias
Los datos son similares al identificador del documento maestro de test antes
comentado (MTP)
Nivel en la secuencia general

Se muestra el nivel actual en el contexto general de la jerarqua o secuencia de
test. Esto se muestra mejor a travs de una ilustracin. Puede ser combinado
con la seccin de alcance.
Clases de test y condiciones generales de test

Resume la nica naturaleza de este nivel particular de test. Esto es un detalle
adicional al alcance definido anteriormente. Provee, por ejemplo, descripciones
de del nivel particular, tales como:
a. El test de componentes se enfocara en ciertos atributos deseados de
cada componente
b. Cada nivel de test de integracin podra tener un inventario de las
interfaces a ejecutar
c. El test de sistema enfocara en alcanzar los requerimientos de sistema
Page 108
201
2
d. El test de aceptacin enfocara en los atributos de aptitud de utilizacin
LTP: detalles para este nivel de plan de test

Introduce las secciones subsiguientes subordinadas. Describe los tems
especficos a ser testeados en el nivel designado y provee una Matriz de
trazabilidad de test que une los tems a ser testeados con los requerimientos.
En esta seccin el enfoque es descripto a lo largo de los criterios de pasa/falla
y suspensin/reanudacin, y los entregables de test son identificados.
Items de test y sus identifi cadores

Identifica los tems de test que son objeto de test, como por ejemplo atributos
especficos del software, instrucciones de instalacin, instrucciones de usuario,
hardware interconectado, software de conversin de base de datos que no es
parte del sistema operacional; incluyendo su nivel de versin o revisin.
Tambin se identifican procedimientos para transferencia de otros ambientes al
ambiente de test.
Tambin proporciona referencias a la documentacin de los tems de test
relevantes a un nivel de test individual, si existen, tales como requerimientos,
diseo, gua de usuario, gua de operacin, gua de instalacin.
Referencia cualquier reporte de anomala relacionado con los tems de test, e
identifica cualquier tem que debe ser especficamente excluido del testing.
Matriz de trazabilidad de test

Provee una lista de requerimientos que son realizados por este nivel de test y
muestra los casos de test o procedimientos correspondientes. Los
requerimientos pueden ser de producto de software o bien requerimientos
funcionales o no funcionales de sistemas basados en software para los niveles
ms altos de test, o estndares de codificacin o diseo para los niveles ms
bajos.
Esta matriz puede
(RTM) ms amplia
todos los niveles
documentacin de
como hacia atrs.
ser parte de una matriz de trazabilidad de requerimientos

referenciada por este plan que incluye requerimientos de
de test y traza mltiples niveles del ciclo de vida de
productos. Puede incluir trazabilidad tanto hacia adelante
Page 109
201
2
Caractersticas a ser testeadas

Identifica todos los productos de software o caractersticas de sistema basadas
en software y combinaciones de software o caractersticas de sistema a ser
testeadas.
Caractersticas a no ser testeadas

Se identifican todas las caractersticas y combinaciones de caractersticas
significantes conocidas que no sern testeadas y las razones para su exclusin.
Enfoque
Describe el enfoque general para el nivel de testing. Para cada caracterstica
principal o grupo de caractersticas, se especifica el enfoque se asegurara que
estn adecuadamente testeados. El enfoque puede ser descripto con suficiente
detalle como para permitir la identificacin de las principales tareas de testing
y la estimacin del tiempo requerido para cada una.
Las caractersticas a ser testeadas, las caractersticas a no ser testeadas y el
enfoque suelen combinarse en una tabla llamada Matriz de test. Contiene un
identificador nico para cada requerimiento de test, un indicador de la fuente
del requerimiento y un resumen de los requerimientos y una identificacin de
uno o ms mtodos genricos de test, como por ejemplo caja negra, caja
blanca, anlisis o inspeccin.
Criterios de paso/falla del tem

Especifica los criterios a ser utilizados para determinar si cada tem de test ha
pasado o ha fallado en el testing. Esto esta habitualmente basado en el nmero
de anomalas encontradas en una categora especifica de severidad.
Criterios de suspensin y requerimientos de resumen
Page 110
201
2
Especifica los criterios utilizados para suspender todos o una parte de las
actividades de testing en los tems de test asociados al plan. Especifica las
actividades de testing que deben ser repetidas cuando el testing es reanudado.
Entregables de test
Se identifica toda la informacin que ser entregada por esta actividad de test.
Los siguientes documentos pueden ser entregados: Plan de nivel de test,
Diseo de nivel de test, Casos de nivel de test; Procedimientos de nivel de test,
Log de nivel de test; Reportes de anomala, Reportes de estado de test de nivel
intermedio, Reporte de nivel de test, Reporte maestro de test.
Los datos de input y output de test pueden ser identificados como entregables.
Las herramientas de test tambin pueden ser incluidas
Se describe el proceso de entrega de la informacin completa a los individuos y
entidades organizativas que lo precisaran. Este documento puede ser una
referencia al Plan de gestin de la configuracin.
Esta descripcin de entrega no es necesaria de estar previamente cubierta en
el MTP y no ha habido cambios
LTP Gestin del test
Introduce las subsiguientes secciones subordinadas. Esta seccin describe las
actividades de test y tareas para el nivel especificado y las progresiones de
estas. Es aqu que la infraestructura, responsabilidades, y autoridad, interfaces
organizacionales, recursos, entrenamiento, cronograma, y riesgos son
identificados si no han sido identificados o descriptos en un nivel ms alto,
como por ejemplo MTP.
Actividades y tareas planifi cadas, progresin del test

Se identifican un set de tareas necesarias para preparar y realizar el testing. Se
identifican todas las dependencias entre tareas, cualquier restriccin
significativa tales como disponibilidad del tem de test, recursos de test, y
fechas lmite. Puede ser deseable combinar todos los tpicos contenidos en la
documentacin relacionados con los recursos en una sola seccin.
Medio ambiente infraestructura
Page 111
201
2
Se especifican las propiedades tanto necesitadas como deseadas del ambiente

de test y cualquier otro dato relevante de test. Esto puede incluir las
caractersticas fsicas de las instalaciones, incluyendo el hardware, software
comercial, las herramientas de soporte de test y bases de datos, el personal, y
cualquier otra cosa necesaria para dar soporte al test. Incluye el ambiente de
configuracin antes del testing, ejecucin durante el testing, y cualquier otra
actividad posterior al testing. Tambin especifica el nivel de seguridad que
debe ser provisto y cualquier otro tem relacionado con seguridad,
instalaciones de testing, software y componentes propietarios. Puede incluir
tpicos de contenido provistos externamente, incluyendo sistemas y
subsistemas. Identifica las fuentes para todas estas necesidades.
Responsabilidad y autoridad
Identifica los individuos o grupos responsables de gestionar, disear, preparar,
ejecutar, presenciar, y chequear resultados de este nivel de testing, y para
resolver las anomalas encontradas. Adems identifica las personas
responsables de proveer los tems de test y las necesidades ambientales ya
identificadas.
Las partes responsables pueden incluir desarrolladores, testers, personal de
operacin, representantes de los usuarios, soporte tcnico, administradores de
datos, y soporte de calidad. Pueden participar a tiempo completo o a medio
tiempo y pueden tener responsabilidades primarias o secundarias.
Interfaces entre las partes involucradas

Describe los medios y los contenidos de comunicacin ente los individuos y los
grupos identificados.
Recursos y su asignacin
Delinea cualquier recurso adicional requerido que no haya ya sido
documentado por otras partes del plan. Incluye tanto recursos internos como
externos.
Entrenamiento
Page 112
201
2
Especifica las necesidades de entrenamiento por el nivel de habilidad.
Cronogramas, estimaciones y costos

Incluye los hitos identificados en el cronograma de software o de sistema as
como tambin todos los tems de test de eventos de transmisin.
Define cualquier hito adicional necesario. Estima el tiempo requerido para
hacer cada tarea de test. Especifica el cronograma para cada tarea de test y
cada hito. Para cada recurso de test especifica su periodo de uso.
Riesgos y contingencias
Identifica los riesgos de problemas que pueden impactar adversamente en la
terminacin exitosa de las actividades de nivel de test planificadas. Especifica
los potenciales impactos de cada riesgo, con plan de contingencia para mitigar
o evitar el riesgo. Como los riesgos y contingencias que pueden estar vigentes
al momento de la liberacin de la primera versin del documento pueden
cambiar cuando contina el proyecto, pueden ser seguidos en un documento
separado que no est bajo control de aprobacin.
General
Introduce las secciones siguientes subordinadas. Describe los procedimientos y
mtricas de QA y contiene el glosario y la descripcin de la frecuencia y
procesos por los cuales es revisado el documento y creada una nueva lnea de
base.
Tambin puede contener una pgina con el historial de cambios.
Procedimientos de aseguramiento de la calidad

Identifica los medios por medio de los cuales se asegurara la calidad del testing
de los procesos y productos.
Incluye o referencia seguimiento de anomalas y procedimientos de resolucin.
La informacin de aseguramiento de la calidad puede ser descripta en el Plan
Page 113
201
2
de aseguramiento de la calidad, o Procedimiento estndar, que pueden ser

referenciados.
Mtricas
Se identifican las medidas especficas que van a ser recolectadas, analizadas y
reportadas. Las mtricas especificadas aqu son las que solo aplican a este
nivel de test particular. Puede ser una referencia a donde est documentado el
Plan de aseguramiento de la calidad o como parte de la documentacin en un
programa genrico de medidas.
Cobertura del test

Especifica los requerimientos para cobertura del test. Es una indicacin del
grado al cual ha sido alcanzado el tem de test o cubierto por los casos de
prueba, incluyendo ambos amplitud y profundidad.
El tipo de cobertura que es relevante vara de acuerdo al nivel de test. Por
ejemplo en la cobertura de test de unidad se expresa frecuentemente en
trminos de porcentaje de cdigo testeado y la validacin de cobertura de test
de software o sistema puede ser un porcentaje de los requerimientos
testeados. Hay una necesidad de especificacin de cobertura u otros mtodos
para asegurar la suficiencia del testing.
Glosario
Es similar al glosario descripto en MTP
Procedimientos e historial de cambios de documentos

Similares a los descriptos en MTP
Diseo de nivel de test

El propsito del diseo de nivel de test es especificar cualquier refinamiento
del enfoque de test e identificar las caractersticas a ser testeadas por este
diseo y sus tests asociados.
Page 114
201
2
Introduccin
Identifica la organizacin emisora, y los detalles de emisin. Incluye las
aprobaciones requeridas y el estado (BORRADOR/ORIGINAL) del documento. Es
ac donde el alcance es descripto e identificadas las referencias.
Detalles del diseo de nivel de test

Se describen las caractersticas a ser testeadas y cualquier refinamiento al
enfoque de test segn sea requerido por el nivel. Tambin identifica los
conjuntos de casos de test o escenarios con criterios de PASO/FALLA. Puede
tambin incluir entregables de test.
General
Esta seccin incluye el glosario y los procedimientos de cambio e historial del
documento.
Casos de test de nivel. (LTC)

El propsito del LTC es definir en un nivel de detalle apropiado la informacin
necesaria en lo que se refiere a inputs y outputs del software o sistema basado
en software que est siendo testeado. Incluye todos los casos de test
identificados por el segmento asociado de LTD de haber uno.
Introduccin
La identificacin del documento, alcance y referencias son similares a las
descriptas para los documentos anteriores.
El contexto provee cualquier contexto requerido que no haya sido ya cubierto
por otras secciones del documento, como por ejemplo terceros realizando
testing a travs de internet.
La notacin por descripcin define cualquier esquema de numeracin, por
ejemplo escenarios y casos de prueba. En esta seccin se explica cualquiera de
estos esquemas.
Page 115
201
2
Detalles del caso de test de nivel

Describe a los casos de test con sus identificaciones nicas, objetivos, salidas,
necesidades de medio ambiente, por ejemplo caractersticas y configuraciones
de hardware y software, y cualquier procedimiento especial. Tambin se
identifican las dependencias entre los diferentes casos de prueba.
General
Esta seccin y sus partes, tales como el glosario y el historial de cambios y
procedimientos son similares a los de los documentos anteriores.
Procedimiento de nivel de test

El propsito del procedimiento de nivel de test es especificar los pasos para
ejecutar un conjunto de casos de prueba o, ms genricamente, los pasos
utilizados para ejercitar un producto de software o un tem de sistema basado
en software, en orden a evaluar un conjunto de caractersticas.
Tambin describe las relaciones con otros procedimientos necesarios antes,
durante o despus de este.
En la seccin de detalle presenta una descripcin ordenada de los pasos a ser
tomados por cada participante. Para cada procedimiento, de ser aplicable, y en
diferentes grados segn sea necesario, se incluirn: log, configuracin,
comienzo, procedimiento, medidas, apagado, reinicio, paro, conclusin,
contingencias.
La seccin general, como los documentos anteriores, incluir un glosario, y un
historial de cambios y procedimientos.
Log de nivel de test

El propsito del LTL es proveer un registro cronolgico de los detalles
relevantes sobre la ejecucin de los tests. Una herramienta automatizada
puede capturar todas o parte de esta informacin.
La introduccin contendr la identificacin del documento, el alcance y las
referencias, en forma similar a los documentos ya analizados.
Page 116
201
2
La seccin de detalle incluir el log de test, especialmente la informacin

referente a cada entrada. Contendr informacin que aplica a todas las
entradas en el log, de identificacin, un registro de las actividades y eventos,
una descripcin de la ejecucin, los resultados del procedimiento e informacin
del ambiente. Se registraran los eventos anmalos con sus identificaciones.
La seccin general contendr un glosario.
Reporte de anomala (AR)

El propsito del AR es documentar cualquier evento que ocurre durante el
proceso de testing que requiere investigacin. Eso puede ser llamado
problema, incidente, defecto, issue, anomala o reporte de error.
La introduccin incluir un ttulo para el AR si se desea, la identificacin del
documento, el alcance y las referencias, en forma similar a los documentos ya
analizados.
La seccin de detalle identifica los tems contenidos en el AR incluyendo su
estado y las acciones correctivas tomadas. Registrar la fecha en que se
descubri la anomala, el software o tem de software, o proceso en el cual se
observ la anomala. Se identifican los tems de test involucrados indicando su
versin. Se agregara una descripcin de la anomala, entradas, resultados
esperados, salidas inesperadas, pasos del procedimiento y ambiente.
Tambin ser registrado el impacto que la anomala tendr en lo tcnico y en el
negocio, se identificara la existencia de alternativas de solucin, y se podra
incluir una estimacin del tiempo, esfuerzo y riesgo de solucionar el defecto. Se
proveer una evaluacin de la necesidad de una reparacin inmediata.
Se agregara una descripcin de la accin correctiva tomada para resolver la
anomala reportada, y el estado actual de la anomala, sea abierta, aprobada
para resolucin, asignada a resolucin, arreglada, y re testeada con el arreglo
confirmado.
Se especificarn las recomendaciones para cambio al desarrollo y el proceso de
testing y documentacin que puede ayudar a prevenir este tipo de anomalas
en el futuro.
La seccin general contendr como en documentos anteriores la historia de los
procedimientos de cambios.
Page 117
201
2
Reporte interino de estado de nivel de test

El propsito del LITSR es resumir el estado de las actividades de test
designadas y opcionalmente proveer evaluaciones y recomendaciones basadas
en estos resultados. Es acostumbrado reemplazar la palabra nivel en el ttulo
del documento por el nombre del nivel de test dado por la organizacin, como
por ejemplo reporte de estado interino de aceptacin de test.
Contendr una introduccin como los documentos anteriores con identificador,
alcance y referencias.
El detalle describir un resumen de estado del test, cambios en el plan de test,
y las mtricas.
La parte general ser semejante a los documentos anteriores y contendr un
historial de los procedimientos de cambio.
Reporte de nivel de test

El propsito del reporte de nivel de test es resumir los resultados de las
actividades de testing designadas y proveer evaluaciones y recomendaciones
basadas en esos resultados. Se acostumbra reemplazar la palabra nivel en el
ttulo del documento por el nombre del nivel de test dado por la organizacin.
La introduccin contendr el identificador del documento, el alcance, las
referencias.
La parte de detalle provee un resumen de los resultados de test, los detalles de
los mismos, las anomalas resultas y las resoluciones, las razones de todas las
decisiones, y las conclusiones finales y recomendaciones.
La seccin general contendr el glosario y la historia de los procedimientos de
cambio como en los casos anteriores.
Reporte maestro de test (MTR)

El propsito del MTR es resumir los resultados de los niveles de las actividades
de test designadas y proveer evaluaciones basadas en esos resultados. Puede
ser utilizado por cualquier organizacin, utilizando el plan de test maestro
(MTP). Cuando el MTP es generado e implementado, necesita tener un MTR
correspondiente que describa los resultados de la implementacin de MTP.
La introduccin, como en los casos anteriores, contendr el identificador del
documento, el alcance, las referencias.
Page 118
201
2
La seccin de detalle describe una visin general de los resultados de test

agregados: resumen de las actividades de test, de los resultados de las tareas
de testing, anomalas y resoluciones, evaluacin de la calidad y resumen final
de mtricas recogidas. Tambin incluir las razones de las decisiones, y las
conclusiones finales y recomendaciones, con una evaluacin final del software
y puede agregar una estimacin de riesgos de fallas.
Se pueden describir lecciones aprendidas y cambios que fueron descubiertos
durante la ejecucin del test. Puede incluir mejoras de proceso, identificadas e
incorporadas durante la implementacin del MTP.
La seccin general como en los casos anteriores incorporar un glosario e
historial de procedimientos de cambio.
Page 119
201
2
UML
UML es ampliamente independiente del proceso, es decir, no est atado a
ningn ciclo de vida de software particular. Sin embargo, para obtener los
mayores beneficios de UML se debera considerar un proceso que sea:
-
Dirigido por casos de uso

Centrado en la arquitectura
Interactivo e incremental
Dirigido por casos de uso significa que los casos de uso son utilizados como el
artefacto primario para establecer el comportamiento deseado del sistema,
para verificar y validar su arquitectura, para realizar el testing, y para
comunicarse con las partes interesadas del proyecto.
Centrado en la arquitectura significa que la arquitectura del sistema es
utilizada como un artefacto primario para conceptualizar, construir, gerenciar y
evolucionar el sistema en desarrollo.
Un proceso iterativo es aqul que envuelve la gestin y el flujo de los releases
ejecutables. Un proceso incremental es aquel que envuelve la continua
integracin de la arquitectura del sistema para producir estos releases. Con
cada nuevo release abarcando mejoras incrementales por sobre el anterior.
Juntos, un proceso iterativo e incremental es dirigido por los riesgos, esto
significa que cada nuevo release se enfoca en atacar y reducir los riesgos ms
importantes para el xito del proyecto.
Este proceso dirigido por casos de uso, centrado en la arquitectura e
iterativo/incremental puede ser dividido en fases.
Una fase es el lapso de tiempo entre dos grande hitos en el proceso. Cuando un
grupo de objetivos bien definidos se alcanzan, los artefactos estn completos y
las decisiones estn hechas, para moverse a la fase siguiente
Hay cuatro fases en el ciclo de vida de desarrollo: comienzo, construccin y
transicin. Dentro de cada una de estas fases hay un nmero de iteraciones,
las cuales representan un ciclo completo de desarrollo, desde la captura de
requerimientos en anlisis, hasta la implementacin y testing, que resulta en la
liberacin de un proyecto ejecutable.26
26 Vid Rumbaug, Jacobson, Booch, The Unified Modeling Language User Guide,
Addison-Wesley, 1998, pp. 38 y ss.
Page 120
201
2
UML y los modelos

UML pone su foco en manejar la complejidad en una manera organizada, para
eso trabaja con un enfoque basado en diferentes modelos.
Un modelo es una representacin, en cierto medio, de algo del mismo u otro
medio. El modelo captura los aspectos importantes de lo que se est
modelando, desde un punto de vista particular y simplifica u omite el resto.
Un modelo de software puede ser representado con un lenguaje de modelos,
tal como lo es UML. El modelo tiene semntica y notacin, y puede tomar
varias formas que incluyen tanto imgenes como texto: el modelo trata de ser
de uso ms sencillo para ciertos propsitos que el sistema final. 27
En UML cada modelo est focalizado en un aspecto especfico del sistema:
-
Modelos de requerimientos
Modelo de anlisis
Modelo de diseo
27 Vid Rumbaug, Jacobson, Booch, The unified modeling language reference

manual, Addison-Wesley, 1999, p. 13 y ss
Page 121
201
2
Modelo de implementacin
Modelo de pruebas
El modelo de test de UML

El modelo de pruebas tiene como objetivo la verificacin del sistema.
Principalmente envuelve la documentacin de los casos de prueba y los
resultados de los mismos. Incluye:
-
Casos de Test, que definen que testear en el sistema

Procedimientos de Test, que especifican como ejecutar los casos de test.
Componentes de Test, que automatizaran los procedimientos de test.
Tambin tiene como resultado el plan de test, evaluaciones de los test

realizados, y defectos que pueden retroalimentar a otros procesos, tales como
diseo e implementacin.28
En este modelo, los niveles ms bajos, como mdulos y bloques, son probados
primero. La integracin no viene en un modelo big bang sino que estas
pruebas son introducidas en diferentes niveles al integrar partes cada vez ms
grandes.
Una forma de realizar la integracin envuelve el modelo de casos de uso,
utilizado para integrar un caso de uso a la vez, hasta llegar a la prueba
completa del sistema. De este modo se prueban las interfaces descriptas en el
modelo de requerimientos, y el mismo modelo de requerimientos es entonces
chequeado en el proceso de pruebas. Habitualmente esto se realiza por un
grupo independiente de testing.
Un enfoque de desarrollo orientado a objetos da, en el momento de las
pruebas, nuevas posibilidades, pero tambin nuevos problemas.
Un problema adicional surge con la herencia entre clases: se requieren pruebas
ms exhaustivas para determinar que una operacin es vlida en todos los
niveles y no solo en el cual est siendo probado. Una operacin puede ser
cambiada en las clases hijas de la clase abstracta donde fue creada, sus
propiedades pueden cambiar, el contexto puede cambiar. Por esto es que
normalmente la misma funcin deber ser probada mltiples veces segn el
entorno en que se encuentra y la clase instanciada en ese contexto.
Sin embargo las pruebas de un sistema desarrollado de una forma orientada a
objetos no varan considerablemente de cualquier otro sistema.
28 Vid, Jacobson, Booch, Rumbaugh, Unified Software Development Process,
Addison-Wesley, 1999, p. 313
Page 122
201
2
Como ya hemos visto, las actividades clsicas de testing estn divididas

normalmente en verificacin y validacin.
La validacin generalmente se obtiene con una activa participacin de los
clientes, muestras de prototipos y dems. El concepto de casos de uso ha
resultado particularmente beneficioso para las tareas de validacin, como
complemento, no como reemplazo de las tareas habituales de testing como
revisiones e inspecciones de cdigo, que contribuyen a la obtencin de un
cdigo de alta calidad.
Las actividades de testing llevan aproximadamente un 30% del costo completo
del desarrollo, pero podran llegar a llevar ms del 50%. Es importante que sea
incluido en el plan del proyecto junto con las otras actividades.
El principal objetivo del testing es realizar y evaluar los tests descriptos en el
modelo de test. Esto lo realizan los ingenieros de test, quienes planifican los
esfuerzos de test en cada iteracin.
Para los tests se tendrn en cuenta dos mtricas en particular, integridad de
los tests, lo cual se deriva de la cobertura de los casos de prueba y de los
componentes a ser testeados, lo cual indica el porcentaje de cdigo que ha
sido testeado, y la confiabilidad, la cual se basa en el anlisis de tendencias en
los defectos encontrados, y en las pruebas que se ejecutan con un resultado
esperado. Para esto se crean diagramas que analizarn las tendencias y la
confiabilidad. 29
Las pruebas pueden ser hechas en un estilo top down, bottom up o por casos
de uso. Luego se prueba el sistema en su conjunto, con un enfoque big
bang. Este tipo de enfoque habitualmente no es tan dramtico en un sistema
orientado a objetos, ya que consiste en una serie de objetos que se comunican
entre s, lo que hace que los test de unidad en realidad involucre unidades ms
extensas que las tradicionales: los test de integracin se realizan as en una
etapa temprana, ya que la comunicacin es esencial en estos sistemas.
En el modelo UML habitualmente los casos de uso son utilizados como fuente
para crear los casos de prueba. Al ejecutar cada caso de prueba se chequea
tambin que los objetos se comuniquen correctamente entre s, en ese caso de
prueba particular. Tambin se chequean as las interfaces descriptas en el
modelo de requerimientos. 30
29 Vid. Jacobson, Booch, Rumbaug, op. cit, pp. 295 y ss.
30 Vid Jacobson, Ivar, Object Oriented Software Engineering, Addison-Wesley,
1992, pp. 313-339
Page 123
201
2
La calidad debe ser incorporada al producto desde el principio, el propsito de

las pruebas finales es solamente certificar la calidad del producto, por eso se
las llama a veces certificacin, para distinguirlas de otras tareas de calidad.
Las actividades de testing pueden ser hechas tanto en los documentos de
anlisis y de diseo, siendo verificados por medio de revisiones, para asegurar
que fueron creados apropiadamente, y as eliminar las fallas lo ms pronto
posible.
Al testear rigurosa y continuamente todos los modelos, se obtiene finalmente
un nivel mucho ms alto de confianza en que el sistema modelado se
comportar como es esperado en el mundo real.
La nocin de casos de uso y escenarios son utilizadas para alinear el flujo del
proceso desde la captura de requerimientos hasta el testing, y para proveer
trazabilidad desde el desarrollo hasta el sistema entregado. Los casos de uso
sirven como base para el testing de cada elemento, mientras este evoluciona
durante el desarrollo.
El testear continuamente cada elemento contra sus casos de uso, se valida
continuamente su implementacin. No solo estos casos de uso proveen una
fuente de test de regresin, sino que cada vez que se agrega un caso de uso a
un elemento, se fuerza reconsiderar la implementacin para asegurar que este
elemento es resistente al cambio. Si no lo es, se debe arreglar la arquitectura
apropiadamente. 31
31 Vid Rumbaug, Jacobson, Booch, op.cit. , pp.18 195 367.

Page 124
201
2
TEST MANGER
Dentro de las herramientas de test comentaremos, basado en la investigacin
de Carolina Oberst en su trabajo de grado, el funcionamiento del Test Manager.
Que es el test manager

El test manager es una consola central para administracin, ejecucin y
generacin de reportes durante la etapa de testing.
Trabaja asociado a un proyecto Rational.
Soporta desde pruebas manuales hasta diferentes paradigmas de pruebas
automticas, incluyendo test de unidad, de regresin funcional, performance,
etc. Adems integra el testing con el resto de las actividades del ciclo de vida
del proyecto, y permite mantener relaciones a travs de los artifacts de
todas las fases del ciclo, permitiendo as la rpida deteccin del impacto de
cambios hechos en un rea de proyecto, y actuar en consecuencia.
En la vista principal del Test manager se muestran 4 tabs, que representan las
cuatro actividades de testing, Planning, Execution, Results y Anlisis, las cuales
comentaremos a continuacin.
Page 125
201
2
Actividades del Test Manager

Planning
La actividad de Plannning responde a la pregunta Qu es lo que tengo que
testear para alcanzar los objetivos de calidad?
En test manager el planeamiento consiste en:
Identificar y recolectar las entradas del test

Crear el o los Test Plans
Crear Test Case folders
Crear los Test Cases
Definir las configuraciones para realizar el test
Definir las iteraciones, cuando correr el test
Identifi car y recolectar las entradas del test

Lo primero en la planificacin es crear una lista con todo lo que es necesario
probar, sean versiones, prototipos, requerimientos, cdigo fuente, etc. Todo
esto es llamado test input, el Test Manager provee algunos tipos de Test
Input, pero tambin permite crear nuevo, de acuerdo a los requerimientos de
cada uno.
Crear el o los Test Plans

El Test Plan provee una estructura organizacional para los otros componentes
del proyecto, puede contener informacin referente a: que tests se deben
llevar a cabo, cuando, y cuando se espera que sean aprobados, quien es el
responsable de cada uno, donde deben correr, que configuraciones de software
y hardware requieren, etc.
Test Manager permite administrar varios test plans para un mismo proyecto.
Crear Test Case folders

Dentro de los Test Plan, se pueden crear las Test Case Folders, para organizar
jerrquicamente los Test Cases. Dentro de cada una de ellas se puede crear
una nueva carpeta o un Test Case.
Page 126
201
2
Crear Test Cases

El Test Case es el elemento que responde a la pregunta: qu es lo que voy a
testear?. Especifica una forma de testear el sistema; incluye que es lo que se
va a testear, a partir de cules entradas, y esperando qu resultados bajo
ciertas condiciones. El qu testear puede ser un requerimiento del sistema o un
grupo de requerimientos. Cada Test Case debe tener un dueo que deber ser
miembro del equipo, el cual ser responsable de llevar a cabo la ejecucin de
ese Test Case en particular.
Defi nir confi guraciones e iteraciones

Las iteraciones se utilizan para especificar cundo un Test Case se debe
aprobar, es un lapso de tiempo durante un proyecto, el fin de la iteracin
asegura que el producto ha alcanzado cierto nivel de calidad, este nivel es
definido por los Test Cases que debe aprobar. Las iteraciones se utilizan para
especificar donde se debe ejecutar el Test Case, es decir sobre que
configuraciones de software y hardware.
Diseo e implementacin
La actividad de Planning en Test manager abarca otras dos actividades de
proceso de Testing: Diseo e Implementacin.
Una vez definido que es lo que se va a testear, hay que definir cmo realizar el
testing. Esta pregunta es respondida por la actividad de Diseo.
El diseo del Test Case se puede realizar a partir de los Test Inputs, por ejemplo
los requerimientos. De esta forma el Test Case es independiente de la
implementacin de los requerimientos, y adems al haber un cambio en los
requerimientos sto se debe reflejar en el Test Case.
El diseo debe tener definido cules son las precondiciones, post condiciones y
cul es el criterio de aprobacin.
Una vez diseado el Test Case, est listo para ser implementado. Implementar
un Test Case implica crear un Test Script y asociarlo al Test Case.
Los Test Scripts son set s de instrucciones, que se pueden utilizar para navegar
la interfaz de usuario de una aplicacin para asegurar que todos los botones, y
Page 127
201
2
mens funcionan correctamente, o para testear las actividades que la

aplicacin realiza detrs de la interfaz de usuario.
En Test Manager los Test Scripts se encuentran ordenados por tipo, permite
implementar los test cases con implementacin Manual, Automtica o como
Suites.
Execution
Correr o ejecutar un test case significa correr la implementacin de cada test
case para validar el comportamiento del producto, asegurando que funcione
como se supone que debe hacerlo y que est hecho con la calidad necesaria.
En Test manager se pueden correr: Test Scripts Automticos, Test Scripts
Manuales, Test cases o Suites.
Suites son otra manera de implementar los Tests en Test Manager, muestran
una representacin jerrquica de last reas a testear, o de la carga de trabajo
que se quiere agregar a un sistema. Cada suite muestra los tems, como el
usuario o el grupo de computadoras; los recursos asignados a cada grupo; los
Test Scripts que cada grupo puede correr; y cuntas veces debe correr cada
Test Script. Se pueden utilizar tanto para tests de performance como
funcionales.
En esta etapa tambin se administran las configuraciones, para que los Test
Cases corran automticamente en computadoras que cumple con cierta
configuracin de software y hardware. Esto es para asegurarse que los Test
Cases funcionen correctamente en algn sistema operativo en especial, o
browser, etc. Tambin se podra pretender que funcionen correctamente en
combinaciones de sistemas operativos y browsers. Una vez creadas las
configuraciones, se pueden asociar a los Test Cases para crear Test Cases
configurados.
Mientras una Suite, un Test Case o un Test Script corre, es posible monitorear
su progreso. Test Manager crear Suites temporarias para ejecutar tanto Test
Scripts como Test Cases.
Test Manager permite:
-
Confirmar que el test est progresando satisfactoriamente

Descubrir tempranamente problemas potenciales, permitiendo intervenir
para evitarlos de ser necesario
Suspender o reiniciar Testers Virtuales
Cambiar valores de variables compartidas
Page 128
201
2
Liberar Testers Virtuales que se encuentren esperando en los puntos de

sincronizacin
Las herramientas de monitoreo proveen informacin actual y actualizada

dinmicamente durante la ejecucin del test. Esta informacin incluye: el
nmero de comandos ejecutados correctamente y el nmero de comandos
fallidos; el estado general de los testers virtuales, si se estn iniciando,
conectando a una base de datos, finalizando, o haciendo otra tarea; si alguno
de los testes virtuales termino en forma anormal.
Results and analysis

La evaluacin de los tests involucra: determinar la validez de la ejecucin;
analizar las salidas del test para determinar el resultado, en testing de
performance se busca en los reportes si la performance alcanzada es
aceptable; mirar los resultados agregados para verificar cuanto de los test
plans se ha cubierto; si un test input cambia, Test Manager informa del impacto
que esto tiene en el test plan; lo identifica automticamente y marca los test
cases asociados como sospechosos.
Los Test Logs son generados automticamente por Test Manager cuando se
ejecuta una Suite.
Page 129
201
2
ROBOT
La segunda herramienta que comentaremos es Robot, nos basaremos en la
investigacin de Max Garay en su trabajo de grado.
Que es Robot
Robot es una herramienta que forma parte del Rational Toolkit. Es un conjunto
de componentes para la automatizacin de testing de aplicaciones de tipo
cliente/servidor, as como tambin de aplicaciones de Internet. Soporta
aplicaciones que corran sobre Windows NT 4.0, Windows XP, Windows 2000,
Windows 98 y Windows Mc.
La funcionalidad de Robot permite desarrollar 2 tipos de scripts: GUI scripts y
Session scripts. Los primeros son para el testing funcional, mientras que los
scripts de sesin son para el testing de performance.
Utilizacin de Robot con otros productos Rational

Robot se utiliza en conjunto con otras herramientas:
Rational Test Manager: maneja las actividades de testing: planeamiento,

diseo, implementacin, ejecucin y anlisis
Rational Test Factory: genera automticamente scripts de acuerdo con la
estructura navegable de la aplicacin
Rational Clear Quest: maneja los cambios en los requerimientos, y
controla defectos durante el proceso de desarrollo.
Rational Purify: Sirve para detectar escasez de memoria en los
componentes de una aplicacin en C/C++ asegurando que el cdigo sea
confiable as como tambin errores en los accesos a memoria.
Rational Quantify: Provee un anlisis de performance en la aplicacin,
encontrando los cuellos de botella de la misma.
Rational Pure Coverage: Se ocupa de cubrir el cdigo que se ejecutara,
para evitar el que cdigo no testeado sea ejecutado por el usuario final.
Rational Requisite Pro: Ayuda a controlar el proceso de desarrollo
mediante la definicin de los requerimientos
Rational Robot J: Se concentra en testear HTML y aplicaciones Java de
escritorio o Java web.
Page 130
Page 131
201
2
201
2
Funcionamiento de Robot
Rational RobotJ se concentra en testear HTML y aplicaciones Java de escritorio
o aplicaciones Java web.
Es una herramienta que permite ejecutar scripts, los cuales simulan las
acciones de un usuario que interacta con la GUI de la aplicacin en cuestin.
El mtodo que se utiliza para testear es el de la comparacin: tiene una lnea
de base que representa lo que se espera, y se ingresan puntos de verificacin
en la aplicacin. El ejecutarla, si estos coinciden, eso indica que est
funcionando como se espera, de lo contario habr que rever el sistema.
Rational Robot permite captar 3 tipos de scripts:
1. SQABasic scripts (utiliza el lenguaje MS-Basic)
2. RobotJ scripts (utiliza el lenguaje Java)
3. Virtual User scripts (utiliza el lenguaje C)
Scripts
Para comenzar a crear scripts es necesario tener un contenedor para guardarlo.
El ejecutar la aplicacin el usuario comienza a grabar un script, con las
acciones sobre la aplicacin. Luego, al ejecutar el script, las acciones corren
automticamente como si lo estuviera haciendo nuevamente. De esta manera
se puede ver cmo responde el sistema.
Verification Points
Proveen un baseline de las propiedades o datos de un objeto: si un punto de
verificacin falla se ha encontrado un defecto o un cambio en el sistema. El
RobotJ Verification Point comparator muestra los resultados reales y los
esperados, para poder detectar defectos o cambios que se hayan realizado.
Test Object Maps

El RobotJ Recorder va guardando los objetos que actan durante una sesin de
grabacin, estos objetos se agrupan en Test Object Maps, el cual lleva
registro de todos los aspectos de un objeto. A su vez tambin hay una seccin
donde se guardan los Verification Points.
Page 132
201
2
GUI Scripts
Cuando se graba un GUI script, Robot graba las acciones del usuario (teclas
oprimidas, clics, etc), y los puntos de verificacin.
Antes de comenzar a grabar se deben tomar ciertos recaudos: se deben
establecer datos iniciales y finales predecibles de los scripts, para luego poder
ser ejecutados en forma independiente unos de otros; se debe establecer el
entorno de testing; y se deben modularizar los scripts, para luego poder
modificarlos fcilmente o ubicar cambios con facilidad, y que sean fciles de
depurar.
Aplicaciones para Testing

Robot provee soporte para testear objetos en aplicaciones que son creadas por
IDEs. Se deben habilitar para cada caso en particular las aplicaciones. Por
ejemplo, para aplicaciones Java hay que correr un Java Enabler que localiza en
el disco rgido las libreras de Java. Para aplicaciones HTML, mientras se graba o
edita un script, se utiliza el botn Start Browser para arrancar el Internet
Explorer o el Netscape segn como est configurado.
Mapeo de objetos conocidos y no conocidos

Robot reconoce los objetos grficos estndar de Windows, ya que tiene un
mapeo para distintos lenguajes que se utilicen: Java, Delphi, Visual Basic, etc.
Puede ocurrir durante una grabacin que se cliquee sobre un objetos que Robot
no reconozca. En este caso Robot acta segn se haya configurado: se puede
mapear el objeto desconocido a un objeto genrico o a un objeto conocido.
Esto evita que al momento de la ejecucin aparezcan objetos que no sean
conocidos.
Puntos de verificacin
Los puntos de verificacin, sin puntos en un script que se crean para confirmar
el estado de un objeto. Durante el perodo de grabacin, el punto de
verificacin captura informacin acerca del objeto y lo guarda como lnea de
base. Durante la ejecucin, el punto de verificacin recaptura la informacin y
la compara. Si el objeto no coincide con la informacin guardada, Robot crea
un archivo de datos reales, con la informacin real de objeto. Luego de la
ejecucin del script, los resultados de cada punto de verificacin aparecen el
en log de Test Manager. Si un punto de verificacin falla, se puede entonces ver
Page 133
201
2
por medio de comparadores los datos de la lnea de base y los reales, para as
determinar si las diferencias son intencionales o no.
Un punto de verificacin se guarda en el proyecto y siempre est asociado a un
script.
Timers
Robot permite insertar Timers de dos tipos, los que arrancan y los que frenan.
Sirven para grabar y escribir al archivo de log la duracin de los eventos de un
script. Miden el tiempo que lleva realizar una actividad. De esta manera se
pueden medir una variedad de tareas.
Los timers se pueden utilizar para:
-
Medir la performance general de la aplicacin

Medir la performance de tareas especficas
Para ejecutar un script que incluye timers conviene configurar una opcin de
Robot para remover cualquier tiempo extra que Robot pueda tomarse y que
pueda retrasar la aplicacin.
Comentarios y mensajes de Log

Durante la grabacin o edicin de GUI scripts se pueden agregar comentarios,
los cuales son tiles para documentar. Al momento de compilacin Robot
ignora los comentarios.
Tambin se pueden agregar mensajes de Log, descripciones y resultados en los
GUI scripts. Durante la ejecucin Robot inserta esta informacin en el log, la
cual se puede utilizar para documentar el script en el proceso de ejecucin.
Seleccin del objeto a testear

Hay dos maneras de seleccionar el objeto a testear: apuntarlo en la aplicacin,
lo cual es muy til para seleccionar objetos visibles; o seleccionarlos desde una
lista de objetos, lo cual es til para seleccionar objetos ocultos. Para
seleccionar el objeto primero hay que crear el punto de verificacin.
Page 134
201
2
Seleccin de mtodos de verificacin

Cuando se crean algunos puntos de verificacin se puede seleccionar el
mtodo de verificacin, el cual especifica cmo Robot compara los datos de la
lnea de base capturados durante la grabacin con los datos capturados
durante la ejecucin. Esto se configura cuando se selecciona el punto de
verificacin que posee estas propiedades.
Los posibles mtodos son: Case-sensitive, Case-Insensitive, Find Sub String
Case-Sensitive, Find Sub String Case-Insensitive, Numeric Equivalence, Numeric
Range y Verify that selected field is blank.
Seleccin de mtodos de identificacin

Un mtodo de identificacin le dice a Robot cmo identificar los valores a
comparar durante la grabacin y ejecucin. Por ejemplo si se tienen que
testear los valores de una fila en una tabla se puede especificar un mtodo de
identificacin para que Robot identifique los valores a pesar de la ubicacin de
la fila en la tabla.
Cuando se crean ciertos puntos de verificacin, se pueden seleccionar mtodos
de identificacin para datos que aparecen en una grilla de datos.
Hay cuatro mtodos de identificacin: por contenido, por ubicacin, por ttulo, o
por clave/valor.
Scripts manuales
A pesar de que es ms fcil y ms rpido generar automticamente los scripts
con Robot, se pueden codificar manualmente usando el lenguaje de scripts
SQABasic, siendo el mismo Robot el que provee sta opcin.
Shell scripts
Un Shell script es un script que ejecuta otros scripts en secuencia. Antes de
crear un Shell script es necesario que se hayan grabado todos los scripts que
se intentan incluir. Los resultados de todos los scripts se guardan en el mismo
log para facilitar el anlisis de los resultados.
Page 135
201
2
Editar, compilar y depurar Scripts

Se puede querer editar un script para cambiar algn comando o algn
argumento, o inclusive agregar lgica utilizando el lenguaje SQABasic para GUI
Scripts o el lenguaje VU para virtual user scripts. Antes de comenzar a editar
un script, el mismo debe estar abierto.
Durante la compilacin, se muestran los resultados de la compilacin y los
mensajes de error con el nmero de lnea.
Robot incluye un entorno de depuracin para ayudar durante el desarrollo de
los GUI scripts, pero no tiene entorno de depuracin para los VU scripts. Antes
de comenzar a depurar se debe tener un script abierto. Cuando la ejecucin de
la depuracin se detiene en un breakpoint, se pueden examinar los valores de
una variable o chequear el estado de un objeto antes de que sea modificado
por un comando prximo. Slo se puede ubicar un breakpoint en lneas donde
haya un comando SQABasic, no en comentarios, etiquetas o lneas en blanco.
Ejecucin de GUI Scripts

Las fases de ejecucin son dos: fase de desarrollo del test y fase de test de
regresin.
Cualquier aplicacin y ventana que estaba abierta, activa o desplegada al
momento de la grabacin, debera estar abierta, activa o desplegada cuando
se comienza la ejecucin, de lo contrario el script fallar. Adems debe
asegurarse que cualquier configuracin de propiedades de red o base de datos
deben estar en el mismo estado que cuando se grab el script.
Fase de desarrollo del test
Durante esta fase se ejecutan los scripts para verificar que funcionan como se
pretende, usando la misma versin de la aplicacin bajo testing que se utiliz
para grabar los scripts. Esto valida la lnea de base, que es el comportamiento
esperado de la aplicacin.
Fase de test de regresin

Durante esta fase se ejecutan scripts para comparar la ltima versin de la
aplicacin bajo test con la lnea de base establecida durante la etapa de
desarrollo del test. El test de regresin muestra cualquier diferencia que pueda
haber sido introducida en la aplicacin desde la ltima versin. Se pueden
evaluar las diferencias para determinar si son defectos o cambios voluntarios.
Page 136
201
2
Grabacin de sesiones
Una sesin grabada con Robot contiene todas las consultas del cliente al
servidos y las respuestas del servidor realizadas desde que se comienza a
grabar hasta que se para la grabacin. Estas grabaciones generan scripts de
test que se guardan en un archivos de sesin.
En una sesin mltiple se pueden grabar: mltiples transacciones,
transacciones contra el mismo servidor o contra distintos servidores, diferentes
tipos de consultas.
Los archivos de sesin son guardados por default en el directorio TMS_Scripts
del datastore del proyecto.
Al trabajar con sesiones se puede: dividir la sesin en mltiples scripts,
regenerar los scripts de la sesin o ver las propiedades de la sesin.
Grabacin API
Con ste mtodo Robot graba las llamadas de API entre la aplicacin cliente y
el servidor. La grabacin se realiza en el cliente, como ocurre con los mtodos
Network y Proxy.
Es recomendable utilizar este mtodo si se accede a daros seguros de un
servidor Web y a que captura la informacin antes de que llegue al cable y sea
encriptada.
La grabacin API soporta clientes Windows NT, Windows 2000, y Windows XP.
No se deben especificar direcciones IP o nombres de red del cliente y el
servidor como en los mtodos Network y Proxy.
Grabacin Network
Con este mtodo Robot graba el trfico a niel de paquetes en la capa OSI
utilizando el modo de la tarjeta de red. La grabacin Network soporta
estndares cmo Ethernet, Token Ring, t FDDI (Fiber Distributed Data
Interface). En este mtodo, a diferencia del API, la grabacin ocurre en el cable
y no en el cliente.
Grabacin Proxy
Con este mtodo, el trfico cliente-servidor es ruteado va una computadora
Proxy. La grabacin de proxy ocurre en la capa OSI de la aplicacin. Se pueden
Page 137
201
2
grabar conversaciones entre mltiples clientes y servidores. Ninguna de las

computadoras cliente que enva consultas debe tener Robot instalado, solo
debe estar instalado en las computadoras Proxy.
Grabacin custom
Para que este mtodo funcione es necesario que un adaptador de grabacin
custom y un adaptador generador de custom scripts estn instalados y
configurados.
La Grabacin
Informacin de autenticacin
Si se corre un test contra una base de datos que requiere un ID de usuario y
una contrasea, se debe proveer esta informacin cuando se graba el script y
cuando se ejecuta tambin. Durante la grabacin Robot detecta el ID de
usuario y si hay otra informacin del usuario, guarda esta informacin, pero no
la contrasea. Durante la ejecucin cuando se requiere un ID de usuario y una
contrasea, Robot encuentra el ID en el script y la contrasea en el datapool de
autenticacin asociado a este ID de usuario.
Comenzar a grabar
Para comenzar a grabar un script en una sesin se debe iniciar la grabacin
con el botn Record Session o por medio del men File>Record Session.
Cancelacin de scripts
Al cancelar el script durante la grabacin el script es eliminado, esto es de gran
utilidad si se cometen errores durante la grabacin de una sesin o si no se
quiere incluir actividades preliminares por ejemplo el logging.
Si no se ha dividido la sesin en mltiples scripts se pueden cancelar ambos, la
sesin y el script, y luego frenar la grabacin.
Cuando s se ha dividido la sesin en mltiples scripts se puede cancelar el
script actual, simplemente frenando la grabacin e ignorando la informacin
recin grabada. Los otros scripts grabados permanecern en la sesin.
Page 138
201
2
Para cancelar todos los scripts dentro de una sesin de mltiples scripts
simplemente se debe parar la grabacin y aceptar. Inmediatamente despus
de esto se debe cancelar la generacin de scripts que comienza.
Dividir la sesin en mltiples scripts

Lo que se logra al dividir una sesin en mltiples scripts es que cada elemento
grabado es una unidad lgica de trabajo, se puede dividir la sesin en tantos
scripts como uno quiera.
Si la reutilizacin de la sesin y la modularidad son el objetivo, las sesiones no
deberan dividirse, sin embargo en otras ocasiones la divisin es ptima, por
ejemplo cuando partes de una sesin necesitan ser repetidas muchas veces
durante la ejecucin, y otras no tanto.
Importar y exportar sesiones

Robot permite importar una sesin de un archivo al proyecto actual. Tambin
permite exportar una sesin del datastore actual a cualquier ubicacin dentro
de la PC.
Regeneracin de scripts de una sesin

Cuando se regeneran scripts de una sesin los scripts regenerados heredan las
propiedades de los scripts originales, esto es til si se quieren modificar las
propiedades o incluso agregar opciones que antes no contena.
Definir las propiedades de un script

Definir las propiedades de un script es importante ya que forma parte del
proceso de planeamiento de test. Por esa razn tpicamente se definen las
propiedades de un script en el Test Manager antes de grabar el script. Tambin
pueden ser definidas despus de la grabacin del script.
Regrabar sesiones
Regrabar sesiones es comenzar a grabar una sesin sobre otra que ya contiene
scripts. Se puede borrar la sesin vieja y todos sus scripts o no. Grabar sobre
una sesin afecta a todos los scripts: para grabar slo sobre un script se debe
seleccionar el nombre del mismo cuando Robot lo solicita.
Page 139
201
2
Opciones de ejecucin de GUI scripts

Las opciones de configuracin de la ejecucin proveen instrucciones a Robot
sobre cmo ejecutar los scripts. Pueden ser configuradas antes de comenzar la
ejecucin o ni bien arranca.
Las opciones son:
-
Delay between commands: se ingresa un valor de demora entre las

acciones del usuario y cada punto de verificacin
Use recorded think time: se ingresa un valor de demora entre cada tecla
que se ejecuta
Use recorded type delays: se utilizan los tiempos de demora grabados
Skip verification points: no se tienen en cuenta los puntos de verificacin
al ejecutar el script
Acknowledge results: Robot desplegar un mensaje de los resultados
cada vez que se ejecute un punto de verificacin
Minimize Robot: ventana de Robot se minimiza y queda en la barra de
tareas
Put Robot in background: la ventana de Robot queda detrs de la
aplicacin
Display script only: solo muestra el script durante la ejecucin, se
ocultan las barras de herramientas
Display menues and toolbars: se muestran los mens y las barras de
herramientas mientras se ejecuta el script.
Las opciones de log tambin pueden ser seteadas:

-
Output playback results to log: muestra resultados de la ejecucin en un

archivo de log.
View log after playback: automticamente al finalizar la ejecucin se
muestra el log.
Prompt before overwrite log: Robot pregunta antes de sobrescribir un
log.
Specify log information playback: despliega un dilogo en la ejecucin
para ingresar datos como la versin de la aplicacin, carpeta de log,
archivo de log.
Use default information: utiliza la versin de la aplicacin y la carpeta
de log utilizada durante la ltima ejecucin. Utiliza el nombre de script
como nombre del archivo de log.
Page 140
201
2
Resultados de la ejecucin en el log de Test Manager

Los resultados de la ejecucin se pueden ver en el log, incluyendo fallas en los
puntos de verificacin, fallas procedurales, abortos y cualquier otra informacin
adicional.
Los comparadores ayudan a determinar si la falla es un defecto o un cambio
intencional a la aplicacin bajo test. Esto se debe a que los comparadores
analizan las diferencias entre los datos del punto de verificacin de la lnea de
base y los del punto de verificacin actual.
Hay 4 tipos de comparadores:
-
Object properties: compara los datos de la lnea de base con los datos
que causaron la falla en el punto de verificacin Object Properties.
Text: compara los datos de la lnea de base con los datos que causaron
la falla para el punto de verificacin Alphanumeric.
Grid: compara los datos de la lnea de base con los datos que causaron
la falla para los puntos de verificacin Menu y Object Data.
Image: compara la imagen del baseline con la imagen que caus la falla
para el punto de verificacin Window image o Region image. Adems
permite ver inesperadas ventanas abiertas que provocan fallas durante
la ejecucin.
Datapools
Un datapool es un conjunto de datos de test que suministra valores a las
variables de un script durante la ejecucin. Se utilizan para que cada tester
virtual que corre el script pueda enviar datos reales al servidor y para que un
tester particular que realiza la misma transaccin varias veces pueda enviar
datos reales al servidor en cada transaccin.
Si se ejecuta un script una vez, probablemente no precise acceder a un
datapool, pero generalmente es necesario acceder a ellos, sobre todo cuando
se realizan tests funcionales y de performance, para simular que se realiza la
misma operacin una y otra vez, consecutiva y simultneamente.
Data Tests
Los data tests son los puntos de verificacin Object Data. El punto de
verificacin Object data soporta data tests para capturar los datos en los
objetos. Hay dos tipos de data tests, los Built-in, que vienen con Robot, y los
Custom, que son creados por el usuario.
Page 141
201
2
Robot y el ciclo de vida del software

El USDP (United Software Development Process) define workers, activities y
artifacts para el desarrollo de la etapa de test.
Entre los artifacts define:
Plan Test
Model Test
Test Case
Test Procedure
Test Component
Defect
Evaluate Test
Entre los workers define:
Test Designer
Component Engineer
Integration Tester
System Tester
Entre las actividades define:
Plan Test
Design Test
Implement Test
Perform Test
Evaluate Test
Las actividades que principalmente realiza Robot es la de Implement Test ya

que desarrolla scripts automticos para luego ser ejecutados.
Test manager es un componente de Robot y realiza todas las actividades
definidas por el USDP. Robot en cambio, ayuda a Test Manager en la
implementacin de los tests con los test scripts.
Page 142
201
2
Comparacin entre los modelos

Uno de los mayores problemas en lo referente al software es lograr que los
ingenieros utilicen consistentemente mtodos efectivos. Habitualmente la
prctica los ha ido llevando a escribir los programas del mismo modo que lo
hacan sus compaeros o superiores, e ignorar el modo apropiado de aplicar los
mtodos a programas pequeos, pensando que en esos casos no tendra
sentido. Esto conduce a que las mejores prcticas tampoco puedan ser
aplicadas a los programas grandes.
Los estudiantes de ingeniera de software terminan convenidos de que la
codificacin y el testing son necesarios, pero todo lo dems es opcional. El
sistema educativo no provee a los graduados con las habilidades o con el
convencimiento necesario para aplicar rigurosamente mtodos efectivos, y
pocas organizaciones estn dispuestas a pagar por la capacitacin necesaria
para sus ingenieros.
Para cambiar las prcticas personales de los ingenieros de software se los debe
convencer, primeramente, de que los nuevos mtodos y modelos son ms
efectivos que la forma actual de trabajo que utilizan. 32
Todos los modelos analizados previamente presentan una serie de actividades
para garantizar la calidad del software. A travs del ciclo de vida, se van
presentando determinadas tareas que se deben realizar para garantizar que el
producto cumpla con lo que el cliente requiere, utilizando la trazabilidad desde
los requerimientos hasta la implementacin, ejecutando en cada etapa
actividades de verificacin y validacin que garanticen encontrar errores o
desviaciones en etapas tempranas del desarrollo, para luego en la integracin
encontrar errores menores, pero teniendo ya una interpretacin clara del
producto requerido.
El modelo CMMI garantiza la calidad evaluando los procesos de la empresa en

niveles de capacidad o madurez, segn la adecuacin que han conseguido con
el modelo presentado por CMMI.
CMMI presenta prcticas especficasbest practices- que deben ser definidas a
lo largo del proceso y se debe demostrar que fueron realizadas, para garantizar
as la calidad. Para esto los procesos de la empresa deben ser mapeados con
las reas de proceso del modelo CMMI, garantizando as que se cumplen los
32 Vid. Watts S. Humphrey, Why Don't They Practice What We Preach?, 04-08-2010
Page 143
201
2
requisitos de trazabilidad en cada etapa. Realizando las tareas de verificacin y

validacin correspondientes, que llevarn finalmente a un producto que
funciona correctamente y realiza lo requerido por el cliente. CMMI presenta en
particular las prcticas a realizarse durante la verificacin del software
testing-, inputs y outputs requeridos para llegar al nivel de madurez deseado.
IEEE/EIA 12207 define estndares para los procesos del ciclo de vida del
software. Cada proceso tiene una serie de actividades y tareas a ser realizadas
para garantizar la calidad. Para esto hay procesos primarios y procesos de
soporte, que son los que ayudan a los procesos primarios a ser ejecutados con
calidad.
Dentro de los procesos de soporte se encuentran los procesos de verificacin,
validacin, revisin y auditora, que atravesando todo el proceso de desarrollo
garantiza la trazabilidad desde los requerimientos hasta el producto final
garantizando la adecuacin con las necesidades del cliente y la ausencia de
errores.
A diferencia de CMMI IEEE 12207 sugiere un proceso de adaptacin que, dentro
de ciertas condiciones, puede ser aplicado sobre los procesos presentados,
para que el usuario pueda definir su propio proceso siguiendo los lineamientos
de la norma. De este modo el cliente definir su propio proceso, y luego deber
por medio de los productos de trabajo demostrar que cumpli con lo
establecido.
El modelo de UML presenta actividades de verificacin y validacin lo largo de

todo el ciclo de vida del producto, desde los documentos iniciales de
requerimientos, anlisis y diseo, que son verificados por medio de revisiones,
eliminando as en una etapa temprana las fallas de comprensin respecto de
las necesidades del cliente, hasta tareas especficas de testing sobre el
programa ya construido, para encontrar errores de programacin y tambin de
funcionalidad.
Estos tres primeros modelos analizados abarcan todo el ciclo de vida del
software.
La norma IEEE 829 es ms detallada y restringida en su alcance: tiene como
objetivo establecer un marco de cmo realizar las actividades de testing y sus
documentos, aplicable a cualquier ciclo de vida de software. Para la descripcin
de los procesos se basa en la estructura que provee la norma IEEE 12207.0 y
Page 144
201
2
dentro de este marco delinea las diferentes tareas y documentos que son
necesarios en cada una de las actividades.
Dentro de los mtodos de testing que hemos analizado se puede apreciar el
modo particular en que se aplica el QUE establecido por CMMI y la norma
IEEE 12207, dentro del COMO presentado por IEEE 829.
Estas diferentes actividades estn dirigidas a verificar y validar el cdigo para
evitar errores, asegurando que el cdigo ejecutable se adece a los
requerimientos iniciales.
Por ltimo hemos analizado dos herramientas, Test Manager y Robot, que
ayudan a la aplicacin del COMO de todos estos procesos y mejores
prcticas, por medio de la automatizacin de pruebas y generacin de
documentos y logs de test, devolviendo los casos de prueba exitosos, los
errores, y permitiendo el anlisis del cdigo para debug y correccin.
Es decir, el modelo de CMMI, la norma IEEE 12207 y el modelo de UML
proponen mejores prcticas a realizar, mientras que la norma IEEE 829 propone
un modo concreto de realizarlo. Las herramientas analizadas, Robot y Test
manager facilitan la automatizacin de estos procesos. A travs de todos estos
enfoques vemos como se garantizan actividades de verificacin y validacin en
cada etapa de desarrollo, revisiones de requerimientos, revisin de trazabilidad
del cdigo con respecto a los requerimientos, y generacin de casos de prueba
que verifican que los requerimientos han sido implementados, y
correctamente. De este modo se apuntan a eliminar los errores en etapas
tempranas, evitando as su propagacin, arraigndose en el tiempo y
produciendo errores cada vez ms difciles de erradicar.
Page 145
201
2
CONCLUSIONES
Como hemos visto en los diferentes enfoques de aseguramiento de la calidad,
es importante contar con actividades especficas de verificacin y validacin a
lo largo de todo el ciclo de vida. Una continua validacin respecto de los
requerimientos, junto con el testing del cdigo, asegurarn no slo que el
producto sea construido con calidad respecto de los posibles errores en la
codificacin, sino tambin que ste sea construido de acuerdo a las
necesidades reales del cliente, y no se aleje, poco a poco, de los
requerimientos originales, desembocando en un producto que tal vez funcione
bien, pero no realiza lo que originalmente fue requerido.
Hay una imagen frecuentemente utilizada para describir este problema, que no
por mucho que haya sigo utilizada deja de ser representativa:
Los procesos utilizados y recomendados, las mejores prcticas, sirven para

evitar que el realizado durante el lapso de duracin de un proyecto
Page 146
201
2
desemboque en algo intil. Muchas veces los clientes no saben bien como
expresar sus necesidades, otras veces la persona encargada de interpretar el
requerimiento no tiene el suficiente conocimiento del proceso de negocio del
que se est tratando. Estos requerimientos iniciales son luego analizados e
interpretados por muchas otras personas en sus diferentes etapas generando,
de no existir los procesos de verificacin y validacin necesarios, una especie
de telfono descompuesto que lleva a un producto final inadecuado. Por eso es
que son necesarias las revisiones frecuentes, verificaciones y validaciones de
los requerimientos con el cliente, y en etapas posteriores verificacin y
validacin del cdigo, asegurando as que no se ha perdido la trazabilidad con
las necesidades originales.
Todos coincidimos en que la calidad es importante al construir un producto,
pero habitualmente las exigencias de fechas de entrega, la urgencia de los
clientes, es decir la falta de tiempo, y otras veces la falta de presupuesto
desembocan en recortes de actividades, habitualmente de planificacin y de
calidad.
Sin duda esto termina por ser an ms perjudicial, ya que se genera re-trabajo
en las etapas de mantenimiento que al ser generadas por una mala
interpretacin de los requerimientos o pruebas insuficientes quedan a cargo
del rea de desarrollo.
Incorporados en el proceso de desarrollo de software, los modelos y
herramientas que hemos analizado en el presente trabajo ayudan a evitar los
problemas mencionados, a travs de distintos enfoques que tienden a
minimizar los errores en cada una de las etapas.
Los modelos analizados pueden ser incorporados en el ciclo de vida del
software siguiendo la utilizacin de las mejores prcticas, procesos concretos
con actividades y tareas tendientes a asegurar la trazabilidad en la
construccin del software.
Las herramientas analizadas son una clara ayuda en la etapa de testing del
software, automatizando la verificacin del cdigo y generando reportes
automticos de errores, facilitando as los datos necesarios para el anlisis y
deteccin de errores.
Se podran realizar trabajos de investigacin sobre la importancia especfica de
la calidad en la planificacin, que diera lugar a una ejecucin garantizada de
las actividades de verificacin y validacin.
Tambin podran realizarse trabajos que profundizaran en las actividades de
gestin de errores, anlisis de causa y resolucin, evaluando los diferentes
Page 147
201
2
orgenes de los errores, sean por estimaciones demasiado exigentes para las
actividades, falta de entrenamiento de los desarrolladores, o fallas en los
procesos de revisin.
Page 148
201
2
Bibliografa
Kit, Edward, Software Testing in the real world, ACM Press, 1995
Myers, Glenford J., El arte de probar el software, El Ateneo, 1984
Jacobson, Ivar, Object Oriented Software Engineering, Addison-Wesley,
1992
Booch, Grady; Rumbaugh James; Jacobson Ivar, The Unified Modeling
Language User Guide, Addison-Wesley, 1998
Rumbaugh James; Jacobson Ivar; Booch, Grady, The Unified Modeling
Language Reference Manual, Addison-Wesley, 1999
Jacobson Ivar; Booch, Grady; Rumbaugh
Development Process, Addison-Wesley, 1999
James,
Unified
Software
CMMI for development, Version 1.3, November 2010

IEEE 829-2008, Standard for software and System Test Documentation,
2008
IEEE 12207-2008, Systems and software engineering Software life
cycle processes, 2008
Max Garay, ROBOT, trabajo de grado Facultad de Ingeniera, Universidad
Austral.
Carolina Oberst, TEST MANAGER, trabajo de grado Facultad de Ingeniera,
Universidad Austral.
Watts S. Humphrey, Why Don't They Practice What We Preach?, 201008-04, www.sei.cmu.edu/library/assets/whitepapers/17072009whydontthey.pdf
John Goodenough; Linda Northrop , Software Assurance for Systems of
Systems, 2011-05-03, www.sei.cmu.edu/library/assets/whitepapers/foser138goodenough.pdf
Brown, N., Cai, Y., Guo, Y., Kazman, R., Kim, M., Kruchten, P, Lim, E,
MacCormack, Nord, R., Ozkaya, I., Sangwan, R, Seaman, C, Sullivan, K.,
Zazworka, N.; Managing Technical Debt in Software-Reliant Systems,
Page 149
201
2
2011-04-12, http://www.sei.cmu.edu/library/assets/whitepapers/Managing
%20Tech%20Debt.pdf
Zacharie Hall Rick Kazman, Daniel Plakosh, Joseph Giampapa,Kurt Wallnau;
Edge Enabled Systems, 2010-06-15,
http://www.sei.cmu.edu/library/assets/whitepapers/Edge_Enabled_Systems_AFC
EA_GMU_C4I.pdf
Acquisition Archetypes: Happy Path Testing, 2009-10-15,
http://www.sei.cmu.edu/library/assets/happy.pdf
David A. Fisher, Principles of Trust for Embedded Systems, March 2012,
http://www.sei.cmu.edu/reports/12tn007.pdf
Grady H. Campbell, Jr., Harry Levinson, Richard Librizzi, An Acquisition
Perspective on Product Evaluation, October 2011,
http://www.sei.cmu.edu/reports/11tn007.pdf
Ed Morris, William Anderson, Sriram Bala, David Carney, John Morley, Patrick
Place, Soumya Simanta; Testing in Service-Oriented Environments, March
2010, www.sei.cmu.edu/reports/10tr011.pdf
Page 150

Testing y Calidad de Software

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Testing y Calidad de Software

Transféré par

Droits d'auteur :

Formats disponibles

Testing de software, normas de calidad y estndares

Maria Victoria Anselmi

Maria Victoria Anselmi

Testing de software, normas de calidad y estndares

Testing de software, normas de calidad y estndares

Nivel de capacidad 3: Definido...................................................................33

Maria Victoria Anselmi

Testing de software, normas de calidad y estndares

Testing de software, normas de calidad y estndares

Proceso Auditora del Software...................................................................80

Testing de software, normas de calidad y estndares

Results and analysis................................................................................. 117

Maria Victoria Anselmi

Testing de software, normas de calidad y estndares

Robot y el ciclo de vida del software.........................................................128

Maria Victoria Anselmi

Testing de software, normas de calidad y estndares

Describir las caractersticas ms relevantes del testing de

La metodologa utilizada para alcanzar estos objetivos ser la descripcin de

Testing de software, normas de calidad y estndares

en tiempo, con el presupuesto estimado, y que satisfaga las expectativas del

Maria Victoria Anselmi

Testing de software, normas de calidad y estndares

Las pruebas del software

Maria Victoria Anselmi

Testing de software, normas de calidad y estndares

- La probabilidad de encontrar errores adicionales en una seccin de programa

Testing de software, normas de calidad y estndares

Mtodos de prueba: Verificacin y Validacin

Testing de software, normas de calidad y estndares

Durante la etapa de aceptacin la validacin toma la forma de testing

Testing de software, normas de calidad y estndares

Testing de software, normas de calidad y estndares

Testing de software, normas de calidad y estndares

Las actividades de verificacin se dividen de la siguiente forma:

Test de unidad (modulo)

Actividades de alto nivel: comprende las pruebas del producto en su totalidad.

Caja negra y caja blanca

Pruebas tipo caja negra

8 Vid. Kit, Edward, op. cit. pp. 77-108

Testing de software, normas de calidad y estndares

rendimiento de la inversin de las pruebas, encontrar la mayor cantidad de

Pruebas tipo caja blanca:

Testing de software, normas de calidad y estndares

Es posible realizar una prueba rigurosa cambiando ciertas metodologas

Mtodos de caja negra:

Mtodos de caja blanca:

Maria Victoria Anselmi

Testing de software, normas de calidad y estndares

Cobertura de decisiones/condiciones: cada condicin en una decisin debe

12 Vid Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 79-103

Testing de software, normas de calidad y estndares

Con las pruebas incrementales los errores relacionados con la falta de

Maria Victoria Anselmi

Testing de software, normas de calidad y estndares

Pruebas de nivel superior

Que actividades proveen el mayor aumento en confianza justificada de

Testing de software, normas de calidad y estndares

Las respuestas adecuadas a estas preguntas y a otras similares suelen no

Terminacin de las pruebas

15 Vid John Goodenough; Linda Northrop , Software Assurance for Systems of

Testing de software, normas de calidad y estndares

La confiabilidad es el grado en que un sistema satisface sus propietarios y

Testing de software, normas de calidad y estndares