testing y calidad de software

Testing de software, normas de calidad y estándares 2012

Maria Victoria Anselmi



ContentsIntroducción.......................................................................................................................................8

Las pruebas del software..................................................................................................................10

Métodos de prueba: Verificación y Validación.................................................................................12

Validación.....................................................................................................................................12

Verificación..................................................................................................................................13

Pruebas humanas: recorridas y revisiones de programa..........................................................13

Cobertura de las pruebas.........................................................................................................15

Caja negra y caja blanca...........................................................................................................15

Diseño de los casos de prueba.................................................................................................16

Prueba por módulos.................................................................................................................18

Pruebas de nivel superior.........................................................................................................19

Planeamiento y control de las pruebas....................................................................................20

Terminación de las pruebas.....................................................................................................21

Debugging................................................................................................................................21

Sandboxes................................................................................................................................22

Control de los costos................................................................................................................22

Tareas para las pruebas, entregables y cronología...................................................................23

Las organizaciones y los métodos 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



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, categorías y niveles de madurez.................................................................37

Relaciones entre áreas de proceso...................................................................................................39

Gestión de procesos.....................................................................................................................39

Áreas de gestión de procesos básicas......................................................................................39

Áreas de gestión de procesos avanzadas.................................................................................40

Gestión de proyectos...................................................................................................................40

Áreas de gestión de proyectos básicas.....................................................................................41

Áreas de gestión de proyectos avanzadas................................................................................42

Ingeniería.....................................................................................................................................43

Recursividad e iteración del proceso de ingeniería..................................................................45

Soporte.........................................................................................................................................45

Áreas de soporte básicas..........................................................................................................46

Áreas de soporte avanzadas.....................................................................................................46

Las áreas de proceso de Ingeniería..................................................................................................47

Integración de producto...............................................................................................................47

Propósito..................................................................................................................................47

Notas introductorias................................................................................................................47

Áreas de proceso relacionadas.................................................................................................47

Resumen de Goles y Prácticas específicas................................................................................47

Desarrollo de requerimientos......................................................................................................48

Propósito..................................................................................................................................48






Solución técnica...........................................................................................................................50

Propósito..................................................................................................................................50




Validación.....................................................................................................................................51

Propósito..................................................................................................................................51




Prácticas específicas por gol.....................................................................................................53

Verificación..................................................................................................................................58

Propósito..................................................................................................................................58



Resumen de goles y prácticas específicas:...............................................................................59

Prácticas específicas por gol.....................................................................................................60

Norma ISO/IEC 12207, IEEE 12207-2008 – Ingeniería de sistemas y de software – Ciclo de vida de los procesos de software..................................................................................................................66

Alcance, propósito, limitaciones y conformidad de la norma......................................................66

Aplicación de la norma.................................................................................................................67

Categorías de procesos del ciclo de vida......................................................................................68

Procesos específicos de software.................................................................................................69

Procesos de implementación de software...............................................................................69

Procesos de soporte de software.............................................................................................70

Procesos de reutilización de software......................................................................................71

Procesos relacionados con la calidad del software......................................................................71

Proceso de testing de calificación del software........................................................................71

Proceso de aseguramiento de la calidad del Software.............................................................72

Proceso Verificación del Software............................................................................................74

Proceso Validación del Software..............................................................................................77



Proceso Revisión del Software.................................................................................................78

Proceso Auditoría del Software................................................................................................80

IEEE 829 – 2008 – Estándar para Software y Documentación 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 Adquisición............................................................................................................87

Proceso de Suministro..............................................................................................................88

Proceso de Desarrollo..............................................................................................................89

Proceso de operación...............................................................................................................92

Proceso de mantenimiento......................................................................................................93

Proceso de selección de contenido de la documentación de test................................................94

Plan maestro de test................................................................................................................95

Plan de nivel de test.................................................................................................................98

Diseño 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 anomalía (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

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

ROBOT............................................................................................................................................119

Que es Robot..............................................................................................................................119

Utilización 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 verificación............................................................................................................121

Timers....................................................................................................................................121

Comentarios y mensajes de Log.............................................................................................122

Selección del objeto a testear................................................................................................122

Selección de métodos de verificación....................................................................................122

Selección de métodos de identificación.................................................................................122

Scripts manuales....................................................................................................................123

Shell scripts............................................................................................................................123

Editar, compilar y depurar Scripts..........................................................................................123

Ejecución de GUI Scripts.........................................................................................................123

Grabación de sesiones............................................................................................................124

Dividir la sesión en múltiples scripts.......................................................................................126

Importar y exportar sesiones.................................................................................................126

Regeneración de scripts de una sesión...................................................................................126

Definir las propiedades de un script.......................................................................................126

Regrabar sesiones..................................................................................................................127

Opciones de ejecución de GUI scripts....................................................................................127

Resultados de la ejecución en el log de Test Manager...........................................................127

Datapools...............................................................................................................................128



Data Tests...............................................................................................................................128

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

Comparación entre los modelos....................................................................................................130

CONCLUSIONES..............................................................................................................................133

Bibliografía.....................................................................................................................................135



IntroducciónUn aspecto clave de la ingeniería 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 más importantes. Esto suele llevar a elevadas cantidades de “re-trabajo” e insatisfacción de parte del cliente.

Además de la etapa propia de pruebas de los programas, existen normativas y estándares 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 ingeniería de software. Es decir, no solo revisando con pruebas el producto final, sino teniendo revisiones y estándares establecidos para cada etapa del proceso, ya que cada una de ellas será determinante para que el producto final sea no sólo 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 características más relevantes del testing de software. Conocer el estado del arte en las normas de calidad y estándares vigentes de

aseguramiento de la calidad del software. Resaltar la importancia de la calidad de cada una de las etapas de ingeniería de

software para la generación de un producto final de calidad.

La metodología utilizada para alcanzar estos objetivos será la descripción de los métodos clásicos 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 específica de software, y del modelo de testing utilizado por UML y por la norma IEEE 829.

Finalmente se realizará una comparación de estos cuatro modelos, señalando sus similitudes y diferencias fundamentales.

El principal aporte que pretende este trabajo es reafirmar la importancia de la calidad de todo el proceso de ingeniería de software, con especial énfasis en los procesos de verificación y validación del software, y del testing, verificación del programa ejecutable, para obtener un producto final de calidad, entregado en tiempo, con el presupuesto estimado, y que satisfaga las expectativas del cliente.



Las pruebas del software Contrariamente a lo que la mayoría 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 cuestión.

En consecuencia, un caso de prueba exitoso debería ser aquel que descubre un error, dado que resulta haber sido una valiosa inversión.

En general no es posible encontrar todos los errores de un programa, esto debe ser tenido en cuenta al momento del diseño de las pruebas y de su ejecución.

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 definición 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 programación no debería probar sus propios programas

- El resultado de cada prueba debe ser inspeccionado concienzudamente

- Los casos de prueba deben contener escenarios tanto de entradas válidas y esperadas como inválidas e inesperadas.

- Examinar un programa para ver que no hace lo que se supone debe hacer eso solo la mitad, también 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 podrían 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.

- La probabilidad de encontrar errores adicionales en una sección de programa es proporcional a la cantidad ya encontrada en la misma sección



- Las pruebas constituyen una tarea altamente creativa y desafiante1

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 técnicas”. 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 diseño técnico, etc., la falta de los cuales puede provocar problemas de arquitectura así como también de actualización 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, integración, aceptación, para así probar que el sistema funciona apropiadamente antes de ser implementado.

Un testing completo y significativo debe también 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 seguirán presentes en el sistema y sobrevivirán y se multiplicarán a través de las diferentes fases del desarrollo, y en última instancia serán encontradas demasiado tarde en el desarrollo, o por los usuarios después de la implementación, teniendo así el mayor de los impactos y siendo los más caros de solucionar.3

1 Vid Myers, Glenford J., El arte de probar el software, El Ateneo, 1984, pp. 5-172 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



Métodos de prueba: Verificación y Validación

Los diferentes autores consultados no concuerdan en una definición unificada respecto de las definiciones de verificación y validación y sus límites.

A los fines de este trabajo definiremos verificación como aquéllas actividades que pertenecen al ciclo de vida de las pruebas y son exámenes humanos. El objetivo en cada una de ellas es detectar la mayor cantidad posible de errores. Las verificaciones deben ser lo más completas posible, ya que es una de las formas más seguras y efectivas vías para la mejora de la calidad. La verificación se realiza cuando el código ejecutable ya está disponible, testing es la verificación del código ejecutable.

La validación es el proceso de evaluar un sistema o componente durante o al final del desarrollo para determinar si satisface los requerimientos especificados. La validación no debe ser hecha por la persona u organización lo desarrollo.4 A los fines de este trabajo limitaremos la definición de validación a aquellas actividades que se realizan antes de que el código ejecutable esté disponible. Se aplica a las actividades de gestión de proyectos, análisis de requerimientos, diseño de software.

ValidaciónLos procesos de validación deben abarcar pruebas tanto para determinar si el producto satisface los requerimientos del usuario así como también otras para determinar si el comportamiento del producto se corresponde con el comportamiento deseado, descripto en la especificación funcional.

La validación de requerimientos es la que tiene el mayor potencial de ahorrar esfuerzos de desarrollo: puede detectar muchas deficiencias que de otro modo no serán encontradas hasta una etapa muy avanzada del desarrollo, donde el costo de corrección es mucho más alto. Además la etapa de definición de requerimientos es en la cual más del 50% de los defectos son introducidos. Si en esta etapa las revisiones se hacen de una forma correcta los beneficios serán muy altos ahorrando gran cantidad de esfuerzo y dinero en etapas posteriores.

Durante la etapa de aceptación la validación toma la forma de testing operacional y de aceptación. Es la determinación 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 terminación. La evaluación 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 4 Vid Kit, Edward, Software Testing in the real world, ACM Press, 1995, p.57.



desarrollo del producto. Alternativamente puede haber fallas en la validación si el desarrollados no comprendió las necesidades del cliente al serle comunicadas. Este tipo de fallas no deberían ser encontradas durante la aceptación del producto, si durante el desarrollo se realizaron revisiones apropiadas de los requerimientos y del diseño, dirigidas reflejando las necesidades del cliente.5

VerificaciónDentro de la verificación del código (testing) se incluyen diferentes clases de revisiones: inspecciones, recorridas de código, revisiones técnicas y otros métodos. El evento central para estos métodos es una reunión en la cual los defectos del producto son descubiertos y conversados.

Las actividades de verificación son implementadas en un orden en que el tamaño del producto, su nivel de detalle, y el costo de verificación van creciendo, mientras que la potencial rentabilidad disminuye.

En la etapa de testing, como sucede en todas sus actividades, la verificación no puede ser exhaustiva, por lo cual es recomendable combinar diferentes métodos de verificación y detectar partes críticas del código para en ellos realizar una inspección más profunda.

La verificación es casi siempre más efectiva que la validación, inclusive puede encontrar defectos que en la etapa de validación son prácticamente imposibles de detectar, pero lo más importante es que permite encontrar los defectos mucho antes.

Una herramienta fundamental en las actividades de verificación son las listas de verificación. Ejemplos de estas listas son las listas de verificación para requerimientos, para los diseños funcionales, para el diseño técnico, para código en general y para lenguajes en particular.

Las listas de verificación 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 programaLas pruebas humanas, es decir la lectura de los programas por parte de gente son un procedimiento efectivo para la detección de errores y deben ser empleadas en todo proyecto de programación.

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 diseñaron.

5 Vid Grady H. Campbell, Jr., Harry Levinson, Richard Librizzi, An Acquisition Perspective on Product Evaluation, 2011.6 Vid. Kit, Edward, op. cit. pp. 57-76.



Este tipo de pruebas resulta muy útil en la detección de grupos de errores, los costos de corrección 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 codificación y de lógica en programas típicos. Estos procesos son de gran valor para las pruebas de programas nuevos así como para modificaciones.

Se denomina inspección a un conjunto de procedimientos y técnicas 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 diseñador del programa, quien podría ser el mismo que el programador; y un experto en pruebas.

El procedimiento es el siguiente: días antes de la inspección los miembros del equipo reciben una copia del código para poder familiarizarse con él. Durante la inspección el programador debe ir describiendo sentencia por sentencia la lógica 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 corrección de los errores después de la sesión de inspección.

Para la sesión de inspección es importante contar con tiempo y lugar adecuados para evitar interrupciones del exterior. El lapso óptimo varía ente 90 y 120 minutos, dado que es requerido un considerable esfuerzo mental.

Las recorridas también consisten en la lectura del programa aplicando procedimientos y técnicas de detección de errores, pero en una forma diferente.

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 deberán familiarizarse con el código unos días, antes. Sin embargo el procedimiento durante la reunión el distinto: En este caso los participantes desempeñaran 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 ejecución existente entre una computadora y una persona, serán 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 crítico, sino que son un disparador para cuestionar al programador la lógica y suposiciones utilizadas, de este modo es como se encuentran la mayor cantidad de errores.

El tercer proceso humano de detección 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 lógica de casos de prueba a través de él.



Un último proceso humano de revisión de programas son las autoevaluaciones comparativas, que no se encargan de probar los programas sino de una evaluación anónima sobre la calidad general del programa, la facilidad de mantenimiento y claridad.7

Cobertura de las pruebasLa cobertura de las pruebas abarca tanto los requerimientos, la funcionalidad como la lógica. IEEE/ANSI destaca claramente la importancia de las dos primeras, sin embargo la cobertura de la lógica también es muy importante ya que indirectamente mejora la cobertura de funcionalidad y porque es necesaria para probar secuencias lógicas que podrían no ser discernibles desde la funcionalidad externa.

Hay dos cosas esenciales para las pruebas de validez: la definición 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 estén definidos previamente a la ejecución 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.

Las actividades de verificación se dividen de la siguiente forma:

Actividades de bajo nivel: comprende las pruebas de componentes individuales del programa, uno por vez o en combinación. Requiere un conocimiento alto de la estructura interna del programa y su ejecución es más apropiada para los desarrolladores. Comprenden:

- Test de unidad (modulo)- Test de integración

Actividades de alto nivel: comprende las pruebas del producto en su totalidad. Por cuestiones de objetividad es más apropiada la ejecución de las mismas fuera de la organización de desarrollo, usualmente por un grupo independiente de testeo. Comprenden:

- Test de usabilidad- Test de funcionalidad- Test de sistema- Test de aceptación8

Caja negra y caja blancaDentro de las estrategias de verificación 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 más alta probabilidad de detectar la mayor cantidad de errores.

7 Vid Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 19-368 Vid. Kit, Edward, op. cit. pp. 77-108



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 según lo esperado.

Según esta forma de probar los programas, si se quisiera encontrar todos los errores del programa se debería realizar una prueba exhaustiva de entrada de datos, es decir todas las condiciones posibles, lo cual en algunas circunstancias podrían ser virtualmente infinitas.

Dado que esto no es posible, podemos concluir, como decíamos 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 economía, es decir, maximizar el rendimiento de la inversión 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 lógica del programa. Esto puede ser considerado como una estrategia análoga 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 especificación, lo cual podría producir un programa que funciona bien pero no es el requerido, o un programa que realiza parte de lo requerido, pero con secuencias faltantes. También habría que tener en cuenta que las secuencias lógicas dentro del programa pueden producir una cantidad tan grande de combinaciones de sentencias que podría ser imposible de probar. En tercer lugar existe el problema de la sensibilidad de datos: podía haber sentencias que resultan ser correctas con ciertos datos de entrada, pero que con otros resultan erróneas, haciendo que la detección del error dependa de los datos de entrada, no de la ejecución misma de la sentencia.

Como podemos ver, si bien una prueba exhaustiva de entrada podría resultar superior a una prueba exhaustiva de secuencia, ninguna de las dos resulta útil, dado que son impracticables.10

Diseño de los casos de prueba11

Dadas las limitaciones existentes en tiempo, recursos, costos, la cuestión clave en referencia a las pruebas es: ¿cuál es el subconjunto de casos de prueba que tiene la mayor probabilidad de detectar el mayor número posible de errores?

9 Vid Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 8-1010 Vid Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 10-1211 Vid Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 37-79



Para esto existen una serie de metodologías de diseño de caso de prueba. Siendo la más pobre la metodología 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.

Es posible realizar una prueba rigurosa cambiando ciertas metodologías 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 métodos, o quizás todos, dado que cada uno de ellos tiene ciertas fortalezas y debilidades particulares.

Para el diseño de los casos de prueba debe disponerse tanto de la especificación sobre lo que el modulo debe hacer y su código fuente.

Estas pruebas estarán fuertemente orientadas hacia las metodologías de caja blanca, dado que cuanto mayor sea la entidad con que se trabaja esto se tornara más difícil, debiendo requerir así a las pruebas de caja negra, mas orientadas a las fallas respecto de los requerimientos que a la lógica en sí.

Métodos 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.

Análisis de valores límite: prueba de situaciones directamente arriba o debajo de los márgenes de las clases de equivalencia de entrada y salida

Gráficos causa-efecto: técnica sistemática de selección de casos de prueba para comprender las diferentes combinaciones de circunstancias de entrada

Conjetura de errores: proceso intuitivo de enumeración de posibles casos de error para escribir los casos de prueba

Métodos de caja blanca:Cobertura de sentencias: cada sentencia debe ser ejecutada al menos una vez (criterio débil)

Cobertura de decisiones: casos de prueba que cada decisión tenga al menos una vez un resultado verdadero y uno falso

Cobertura de condiciones: cada condición en una decisión debe tener todos los valores posibles al menos una vez

Cobertura de decisiones/condiciones: cada condición en una decisión debe tener todas las posibles salidas y cada punto de entrada debe ser activado por lo menos una vez



Cobertura de condición múltiple: todas las combinaciones posibles de resultados de condición en cada decisión y todos los puntos de entrada se invocan por lo menos una vez

Un conjunto de casos de prueba que satisface las necesidades de condición múltiple satisface también las de cobertura de decisión, condición y decisión/condición.

Todas estas metodologías 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 módulos12

Cuando los programas son grandes (500 sentencias o más) requieren tratamientos especiales para la ejecución de las pruebas, por ejemplo una estructuración de la prueba por módulos.

En lugar de realizar la prueba del programa como un todo, se divide y se concentra individualmente en los bloques más pequeños. De este modo es más fácil poder manejar las posibles combinaciones de datos de prueba, se facilita la localización y corrección de errores y posibilita cierto paralelismo en las pruebas de los diferentes módulos.

Es importante tanto contar con un set efectivo de casos de prueba como analizar la mejor forma de combinar los distintos módulos para constituir un programa funcional.

Un programa podría así probarse modulo a modulo para luego hacer una prueba con todos los módulos combinados (prueba no incremental o “big bang”), o podría probarse un módulo y luego ir combinando uno a uno los módulos siguientes con los previamente probados (prueba incremental).

Las pruebas no incrementales requieren mayor trabajo, dado que es necesaria la creación de una mayor cantidad de módulos impulsores (modulo creado especialmente para transmitir los datos de prueba del módulo que está siendo creado), mientras que en las pruebas incrementales los módulos ya probados pueden ser utilizados.

Con las pruebas incrementales los errores relacionados con la falta de adaptación de las diferentes interfaces pueden ser detectados antes, también se obtiene una prueba más profunda del programa dado que la prueba combinada de los módulos podría llevar a la prueba de una nueva condición antes no probada encontrando un error previamente pasado por alto.

Sin embargo con las pruebas no incrementales existen más posibilidades de paralelizar las pruebas de los módulos, lo cual podría tener un impacto importantes en proyectos grandes.

Todo esto parece sugerir que las pruebas incrementales son superiores a las pruebas no incrementales.

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



Dentro de las pruebas incrementales existen dos estrategias, la ascendente y la descendente.

La estrategia descendente comienza con la prueba del módulo inicial del programa, luego, para que un módulo pueda convertirse en el siguiente modulo a ser probado, debe cumplir con la condición de que previamente se haya probado por lo menos uno de los módulos correspondientes al módulo superior. Para este tipo de pruebas se requiere la creación de módulos auxiliares simulando el correspondiente modulo subsiguiente.

En este punto podrían también realizarse pruebas en paralelo, con las diferentes combinaciones de módulos subsiguientes.

De haber secciones críticas en el programa es recomendable que sean agregadas lo antes posible a las secuencias de prueba. También es importante que los módulos de entradas y salida sean incorporados a las pruebas lo más pronto posible.

En el caso de la estrategia ascendente se comienza por los módulos finales del programa, aquellos que no llaman a otros, para continuar con los del nivel superior una vez que todos los módulos del nivel subordinado hayan sido probados. Para estas pruebas se requiere la creación de módulos impulsores, los cuales son más fáciles de escribir que los módulos 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.

Pruebas de nivel superiorUna vez que se terminan de realizar las pruebas por módulos, 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 mayoría de los errores es atribuible a errores en la comunicación entre las diferentes etapas de comunicación y traducción de la información.

Para evitar estos errores es posible:

1) introducir más precisión en el proceso de desarrollo,

2) introducir al final de cada proceso una etapa de verificación, para evitar que los errores producidos en esa etapa pasen a la siguiente

13 Vid Ed Morris, William Anderson, Sriram Bala, David Carney, John Morley, Patrick Place, Soumya Simanta; Testing in Service-Oriented Environments



3) orientar distintos procesos de prueba hacia distintos procesos de desarrollo, como por ejemplo las pruebas de función, pruebas de sistemas, pruebas de instalación, pruebas de aceptación, etc. 14

Las pruebas de integración y de aceptación 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 más eficiente y efectiva se deben responder algunas preguntas básicas 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é visión dan las actividades sobre el riesgo residual que está presente en el sistema desarrollado?

- Qué evidencia es más probatoria para decidir si un sistema debe ser liberado o no?- Cuál es una base de principios teóricos para afirmar que hay confianza suficiente en el

comportamiento del software?- Que tipos de justificaciones son más o menos aceptables?- Está bien justificado un nivel de confianza propuesto, por principios y teorías sólidas?

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 día más importantes, debido a la complejidad creciente de los sistemas.15

Planeamiento y control de las pruebasEl mayor error cometido al planear un proceso de prueba es la suposición 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 efectúa 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 definición errónea de ellas: difícilmente el objetivo planteado sea “encontrar errores”.16

Terminación de las pruebasHabitualmente 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 visión equivocada.

Es necesario basar el final de las pruebas en criterios de mayor utilidad. Una forma seria basar la terminación en el uso de métodos específicos de diseño de casos de prueba. También podría

14 Vid Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 105-10615 Vid John Goodenough; Linda Northrop , Software Assurance for Systems of Systems, 201116 Vid Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 121-123



basarse en la detección de un número predefinido de errores, siendo aquí el problema como determinar el número de errores a encontrar. Un tercer criterio podría ser realizar un gráfico 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 debería para a la siguiente.

Probablemente lo mejor para determinar la finalización de las pruebas es una combinación de estas tres metodologías.17

La confiabilidad es el grado en que un sistema satisface sus propietarios y usuarios de las expectativas, por lo tanto es específica del sistema y de la misión.

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 histórico o la calidad de los resultados para los diseñadores, implementadores y usuarios de los productos o servicios en los que se desea confiar. Las pruebas, la validación y certificación son procesos que pueden aportar pruebas de confiabilidad.18

DebuggingDebugging de un programa es la tarea que debe ser realizada después de la ejecución de un caso de prueba exitoso: al detectarse un error se debe primero determinar su naturaleza y ubicación dentro del programa, para luego pasar a la corrección del mismo.

El debugging puede ser realizado mediante diferentes métodos.

El método de fuerza bruta es usualmente el más utilizado y consiste en recorrer de diferentes formas el código, analizando los valores que las variables van tomando, para así eventualmente detectar la causa del error. El problema con estos métodos es que habitualmente no tienen en cuenta el proceso de pensamiento.

El método de inducción 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 deducción consiste en partir de ciertas premisas, utilizar procesos de eliminación y clasificación, llegando así a una conclusión la cual detecta el error.

El debugging por rastreo hacia atrás consiste en recorrer la lógica del programa hacia atrás, hasta encontrar un punto donde esta se desvía de lo que es correcto.

Por último, el debugging por medio de casos de prueba consiste en la utilización de casos de prueba especiales, donde el propósito es obtener información útil para la ubicación del error, tratando de cubrir con ellos una condición única, o al menos pocas. Este método se utiliza asociado al método de inducción o al de deducción.

17 Vid. Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 123-12918 Vid. David A. Fisher, Principles of Trust for Embedded Systems, 2012



Es importante también tener en cuenta que el debugging, además de una herramienta valiosa para la eliminación de errores, puede servir para analizar en detalle los errores detectados, y así ser retroalimentación que también ayude a mejorar el diseño y los futuros procesos de prueba. Esto podría ser una tarea difícil y costosa, sin embargo con este tipo de análisis la calidad de los programas podría mejorar notablemente.19

SandboxesTambién relacionado con el testing, está la utilización de los llamados “sandboxes” (areneros), sistemas exclusivamente de prueba que se utilizan tanto para ejecutar aplicaciones como para hacer pruebas de código y configuraciones. Se han utilizado mucho en actividades de testing de mantenimiento, proveyendo un área segura para probar ideas nuevas y código. Otra utilización más 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, información, redes y dispositivos de entrada y salida. 20

Control de los costos De tener recursos ilimitados se podrían ejecutar todas las pruebas deseadas, sin embargo estamos habitualmente cortos no solo de dinero sino también de tiempo.

Es importante por eso tener definido un conjunto de entregables para las pruebas. El objetivo de esto es maximizar el potencial de detección de errores y minimizar la cantidad de pruebas requeridas, para así también poder controlar los costos. 21

Tareas para las pruebas, entregables y cronologíaLas pruebas efectivas son planificadas: requieren un enfoque metodológico, que abarca disciplina, estructura, y medidas.

Cada actividad de testing tiene una o más entradas y consiste en una o más tareas. Cada tarea produce uno o más entregables.

Cada tarea y entregable es mapeado en fases especificas del ciclo de vida del programa mostrando su tiempo relativo y su superposición.

19 Vid Myers, Glenford J., op.cit., El Ateneo, 1984, pp. 131-14620 Vid. Zacharie Hall Rick Kazman, Daniel Plakosh, Joseph Giampapa,Kurt Wallnau; Edge Enabled Systems, 201021 Vid. Kit, Edward, op. cit. pp. 77-108



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 métodos se utilizaran, que tipo de automatización, con qué presupuesto se cuenta, que programas de soporte y entrenamiento se necesita, como se realizara la gestión de la configuración son partes esenciales en la planificación de las pruebas de validación.

Se debe generar un plan maestro de validación, para todo el conjunto de los esfuerzos de las pruebas, y también se deben generar uno o más planes detallados, para cada actividad de validación: en él se detallara específicamente como esta validación será ejecutada, que cosas entran dentro de las pruebas y que cosas serán dejadas afuera.

Los entregables más importantes de la ejecución de las pruebas son los logs de las pruebas, los reportes de incidentes, y el reporte de cobertura de lógica.22

Las organizaciones y los métodos de pruebasUna organización de pruebas (test group) es un recurso o conjunto de recursos dedicados a realizar actividades de test.

El gerenciamiento de las pruebas es difícil: se debe tener habilidad para entender y evaluar el proceso de pruebas de un programa, los estándares, las políticas, las herramientas, los entrenamientos y las medidas. Se debe tener capacidad para mantener a la organización 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.

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 participación 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 nivelación 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 debería ser tenido en cuenta al momento de planificar modificaciones en la organización.

Hay siete enfoques distintos para la organización de las pruebas, los cuales reflejan la evolución de la madurez de una organización de desarrollo.

22 Vid. Kit, Edward, op. cit. pp. 118-133



1. Testing es responsabilidad de cada persona: es lo que habitualmente ocurre en el mundo real. Este enfoque se viola un principio básico, 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, estándares, políticas, herramientas, entrenamientos, métricas, etc.

3. Testing realizado por un recurso dedicado: este enfoque resuelve el problema de múltiples tareas para los desarrolladores, seleccionando uno en particular y dándole la tarea de probar software. Sin embargo en este caso el gerente a cargo de esta persona en quien es asignado a múltiples tareas, debiendo dar ahora soporte no solo a los desarrolladores sino también a este nuevo rol que es parte de su equipo. Esto es altamente improbable, por esto es que se vuelve claro que algún tipo de grupo de test independiente es necesario, para coordinar las actividades y dar a estas una dedicación full time.

4. Nueva organización de pruebas en QA: una solución común es crear la nueva organización 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.

5. La organización de test está en el sector de desarrollo: para resolver el problema del enfoque anterior se crea una organización de test dentro de la organización de desarrollo. En este caso el problema es que esta organización habitualmente queda bajo el mando de un gerente que ahora no solo es responsable por el desarrollo sino también 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. Organización de test centralizada: este enfoque resuelve el problema anterior, una organización de test centralizada, que vive dentro del área de desarrollo y le sirve. De este modo la organización de test tiene más posibilidades de mostrar su impacto dentro de la empresa, los testers tienen su lugar, capacitación, guía, 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 línea.

7. Organización de test centralizada con centro tecnológico de test: Los problemas de consistencia del enfoque anterior se resuelven creando un grupo tecnológico de test. Con esto se podrán gerenciar los esfuerzos, programas de entrenamiento, planificación e implementación de programas de herramientas de test, la documentación de los procesos, estándares y políticas será realizada de forma adecuada, y se podrán realizar mediciones de los test.23

23 Vid. Kit, Edward, op. cit. pp. 163-175



CMMI for development. – CMMI para desarrollo24

Los modelos de CMMI (Capability Maturity Model Integration) son colecciones de “best practices” (mejores prácticas) 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 para desarrollar mejores productos y serviciosLas compañías, más que nunca, quieren entregar mejores, más baratos productos y servicios y en forma más rápida. Al mismo tiempo los productos y servicios son cada vez más complejos, y se vuelve realmente complicado para una sola organización desarrollar cada uno de los componentes que formaran parte del complejo producto final. Comúnmente, 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 prácticas” que se dirigen a las actividades de desarrollo aplicadas a los productos y servicios. Estas prácticas cubren el ciclo de vida del producto desde su inicio, a través de la entrega y el mantenimiento.

CMMI-DEV se centra en las actividades de la organización que desarrolla el producto: contiene 22 áreas de proceso, 16 son principales, 1 es compartida, y 5 son específicas de desarrollo.

Las áreas específicas de desarrollo se dirigen a los requerimientos de desarrollo, la solución técnica, la integración del producto, verificación y validación.

El Software Engineering Instituto (SEI) ha encontrado en su investigación para ayudar a las organizaciones a mantener la calidad, varias dimensiones en las que una organización se puede enfocar para mejorar el negocio.

Tres dimensiones críticas en la que una organización típicamente se enfoca son: personas, procedimientos y métodos:

24 Vid. CMMI for development, Version 1.3, November 2010



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 representación simplificada de la realidad, que contiene elementos esenciales de procesos efectivos.

CMMI – CMM Integración, tal como otros modelos CMM, provee una guía a ser utilizada al crear procesos, no son procesos o descripciones de procesos. Fue creado para resolver el problema de utilizar múltiples modelos de CMM. La combinación 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 versión 1.3.

El siguiente grafico muestra los modelos que llevaron a esta versión:



CMMI para desarrolloCMMI 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, fabricación de automóviles, y telecomunicaciones usan CMMI para desarrollo.

CMMI para desarrollo contiene prácticas que cubren gestión de proyectos, gestión del proceso, ingeniería de sistemas, ingeniería de hardware, ingeniería de software, y otros procesos de soporte utilizados en desarrollo y mantenimiento.



Las áreas de procesosLos modelos de CMMI son producidos partiendo del marco de CMMI. Este marco contiene todos los goles y prácticas 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 básicos, fundamentales para la mejora de procesos en cualquier área de interés. Parte del material en las áreas de proceso principales es el mismo en todas las constelaciones, otro material puede ser ajustado para algún área específica de interés, con lo cual el material puede no ser exactamente el mismo.

Un área de procesos es un grupo de prácticas 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. Análisis de Causa y Resolución (CAR)2. Gestión de la Configuración (CM)3. Análisis de Decisiones y Resolución (DAR)4. Gestión de Proyectos integrada (IPM)5. Medición y Análisis (MA)6. Definición del Proceso Organizacional (OPD)7. Enfoque del Proceso Organizacional (OPF)8. Gestión del Desempeño Organizacional (OPM)9. Rendimiento del Proceso Organizacional (OPP)10. Entrenamiento Organizacional (OT)11. Integración de productos (PI)12. Monitoreo y Control de proyecto(PMC)13. Planificación de Proyectos (PP)14. Aseguramiento de la Calidad del Proceso y del Producto (PPQA)15. Gestión de Proyectos cuantitativa (QPM)16. Desarrollo de Requerimientos (RD)17. Gestión de Requerimientos (REQM)18. Gestión de Riesgos (RSKM)19. Gestión de Acuerdos de Proveedores (SAM)20. Solución Técnica (TS)21. Validación (VAL)22. Verificación (VER)



El modelo en su conjuntoCMMI-DEV no especifica que un proyecto u organización deba seguir un determinado proceso o que cierta cantidad de productos deban ser elaborados por día, o targets específicos de performance a ser alcanzados. El modelo especifica que un proyecto u organización deben tener procesos que cumplan con las prácticas de desarrollo relacionadas. Para determinar si estos procesos están en lugar, un proyecto u organización mapea sus procesos con las áreas de proceso del modelo. Este mapeo de procesos con áreas de proceso permite a la organización 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 línea de evolución recomendada para una organización que quiere mejorar los procesos que utiliza para desarrollar productos o servicios.

CMMI soporta dos vías 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 vías 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 organización debe satisfacer todos los goles de un área de proceso, o conjunto de áreas de proceso que están indicadas como objetivo de mejora, independientemente de si es un nivel de capacidad o de madurez.

La representación continua usa los niveles de capacidad para caracterizar el estado de los procesos de la organización en relación con un área de proceso individual.



La representación por niveles usa los niveles de madurez para caracterizar el estado total de los procesos de la organización relacionados con el modelo en su totalidad.

Si bien estas dos imagines son muy similares, la representación continua se enfoca en la capacidad de las áreas de proceso, medidas en niveles de capacidad, y la representación por niveles enfoca en la madurez general medida en niveles de madurez. Estas dimensiones son utilizadas como



punto de referencia y para actividades de evaluación, así como para guiar los esfuerzos de mejora de una organización.

Los niveles de capacidad aplican a los logros de mejora del proceso de una organización, en áreas de proceso individuales. Son niveles para mejorar incrementalmente los procesos correspondientes a un área determinada. Los cuatro niveles de capacidad están numerados del 0 al 3.

Los niveles de madurez aplican a los logros de mejora del proceso de una organización a traces de múltiples áreas de proceso. Son niveles para mejorar incrementalmente los procesos correspondientes a un grupo de áreas de proceso. Los cinco niveles de madurez están 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 Representación continuaNiveles de capacidad

Representación por nivelesNiveles de madurez

Nivel 0 IncompletoNivel 1 Realizado InicialNivel 2 Gestionado GestionadoNivel 3 Definido DefinidoNivel 4 Cuantitativamente GestionadoNivel 5 Optimizado

La representación 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 representación continua.

La representación por niveles se ocupa de seleccionar múltiples áreas de procesos para mejorar dentro de un nivel de madurez, si los procesos individuales están realizados o incompletos no es el foco primario. Por eso el nombre “inicial” es dado al punto de inicio de la representación por niveles.

Ambas representaciones proveen una forma de mejorar las procesos de una organización y de medir cuan bien las organizaciones pueden mejorar y mejoras sus procesos.

Niveles de capacidadUn nivel de capacidad para un área de proceso se alcanza cuando todos los goles genéricos son satisfechos hasta ese nivel. El hecho de que los niveles de capacidad 2 y3 usen los mismos



nombres que los goles genéricos 2 y3 es intencional, ya que cada uno de esos goles y prácticas genéricos reflejan el significado de los niveles de capacidad de los goles y prácticas.

Nivel de capacidad 0: IncompletoIn proceso incompleto es un proceso que no está siendo realizado o que se realiza parcialmente.

Uno o más de los goles específicos de las áreas de proceso no están satisfechos y ningún gol genérico existe para este nivel, ya que no hay razón para institucionalizar un proceso realizado parcialmente.

Nivel de capacidad 1: RealizadoUn 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 específicos del área de proceso están 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: GestionadoUn proceso de nivel de capacidad 2 es un proceso gestionado. Este es un proceso que está planificado y ejecutado de acuerdo con una política. 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 adhesión al proceso descripto.

La disciplina de procesos reflejada en el nivel 2 ayuda a asegurar que las prácticas existentes son retenidas durante momentos de estrés.

Nivel de capacidad 3: DefinidoUn proceso de nivel de capacidad 3 es un proceso definido. Este es un proceso gestionado que es adaptado desde el set de procesos estándar de la organización de acuerdo a los lineamientos de adaptación de la organización; tiene una descripción mantenida, y contribuye con experiencias relacionadas al proceso a los activos de la organización de procesos.

Una crítica diferencia entre los niveles de capacidad 2 y 3 es el alcance de los estándares, descripciones de procesos, y procedimientos. En el nivel 2 éstos pueden ser ligeramente diferentes en cada instancia específica del proceso. En el nivel 3, para un proyecto determinado



son adaptados desde el conjunto de procesos estándar de la organización para adaptarse a un proyecto particular o unidad organizativa, y por lo tanto son más consistentes, excepto por las diferencias permitidas por las guías de adaptación.

Otra diferencia critica es que en el nivel de capacidad 3 los procesos son descriptos típicamente en forma más rigurosa que en el nivel 2 y son gestionados en forma más proactiva.

Niveles de madurezUn nivel de madurez consiste en prácticas genéricas y especificas relacionadas por un grupo de áreas de procesos predefinidas que mejoran la performance general de la organización.

Son medidos por el logro de goles genéricos y específicos asociados con cada grupo de áreas de proceso predefinidas.

Recordemos que los niveles 2 y 3 usan los mismos términos 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 organización relacionada a un grupo de áreas de proceso, y los niveles de capacidad caracterizan la mejora de la organización relativa a un área de proceso particular.

Nivel de madurez 1: InicialLos procesos de nivel de madurez 1 son habitualmente ad hoc y caóticos.

La organización 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 más de lo que pueden llegar, abandonar los procesos en tiempos de crisis y ser incapaces de reproducir los éxitos.

Nivel de madurez 2: GestionadoEn el nivel de madurez 2 los proyectos tienen asegurado que los procesos están planificados y ejecutados de acuerdo con la política. 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 adhesión a las descripciones del proceso. La disciplina reflejada por el nivel de madurez 2 ayuda a asegurar que las prácticas existentes son mantenidas durante los tiempos de estrés. Cuando las practicas están en su lugar los proyectos sin realizados y gestionados de acuerdo con los planes documentados.

También en el nivel de madurez 3 el estado de los productos de trabajo son visibles a la gestión en puntos determinados Se establecen compromisos entre partes interesadas relevantes y se revisan según será necesario. Los productos de trabajo son apropiadamente controlados, y satisfacen las descripciones de procesos, estándares y procedimientos especificados.

Nivel de madurez 3: DefinidoEn el nivel de madurez 3 los procesos están bien caracterizados y comprendidos, y están descriptos en estándares, procedimientos, herramientas y métodos. El grupo de procesos estándar de la organización, que es la base para el nivel de madurez 3, están establecidos y mejoran con el tiempo.

La diferencia con el nivel 2 es el alcance de los estándares, 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 el grupo de procesos estándar de la organización para cumplir con un proyecto particular o unidad organizacional, y entonces son más consistentes excepto por las diferencias permitidas en el proceso de adaptación.

En el nivel 3 los procesos son manejados en forma más proactiva, son descriptos en forma más rigurosa. La organización además mejora sus procesos relacionados con las áreas de proceso del nivel de madurez 2. Las prácticas genéricas son asociadas con los goles genéricos 3, que no fueron logradas en el nivel 2 son aplicadas para lograr el nivel 3.

Nivel de madurez 4: Cuantitativamente GestionadoEn el nivel de 4 la organización y proyectos establecen objetivos cuantitativos para calidad y performance de procesos, en términos estadísticos, y los usan como criterios para gestionar los proyectos. Los objetivos cuantitativos están basados en las necesidades del cliente, usuarios finales, organización e implementadores del proceso.

Para subprocesos seleccionados, medidas específicas de performance de procesos son recogidas y son estadísticamente analizadas. Líneas 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 distinción crítica 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 estadísticos y otras técnicas cuantitativas. Las predicciones son basadas, en parte, en el análisis estadístico de datos específicos del proceso.

Nivel de madurez 5: Optimizado En el nivel de madurez 5, la organización continuamente mejora sus procesos, basado en la interpretación cuantitativa de los objetivos del negocio y las necesidades de performance. La organización utiliza un enfoque cuantitativo para comprender la variación inherente en el proceso y las causas de sus resultados.

Los objetivos de calidad y procesos de performance de la organización están establecidos, son continuamente revisados para reflejar el cambio en los objetivos del negocio y la performance de la organización, y son utilizados como criterio en la gestión de la mejora del proceso.

Los efectos de las mejoras de procesos son medidos utilizando estadística y otras técnicas cuantitativas, y son comparados con los objetivos de calidad y performance de procesos. Los procesos definidos del proyecto, los procesos estándar de la organización, y la tecnología de soporte son objetivos de actividades de mejora medibles.

Una distinción crítica entre los niveles de madurez 4 y 5 es el foco en gestión y mejora de la performance de la organización. En el nivel 4 la organización 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 organización está preocupada con toda la performance de la organización, usando datos recopilados de múltiples proyectos. El análisis de los datos identifica déficit o lagunas en la performance. Estas lagunas son utilizadas para dirigir el proceso organizacional de mejora que genera mejoras de performance medibles.



Áreas de proceso, categorías y niveles de madurezAREA DE PROCESO CATEGORIA NIVEL DE MADUREZAnálisis de Causa y Resolución (CAR)

Soporte 5

Gestión de la Configuración (CM) Soporte 2

Análisis de Decisiones y Resolución (DAR)

Soporte 3

Gestión de proyectos integrada (IPM)

Gestión de proyectos 3

Medición y Análisis (MA) Soporte 2Definición del Proceso Organizacional (OPD)


Enfoque del Proceso Organizacional (OPF)


Gestión del Desempeño Organizacional (OPM)


Rendimiento del Proceso Organizacional (OPP)


Entrenamiento Organizacional (OT)


Integración de productos (PI) Ingeniería 3

Monitoreo y Control de proyecto(PMC)


Planificación de Proyectos (PP) Gestión de proyectos 2

Aseguramiento de la Calidad del Proceso y del Producto (PPQA)

Soporte 2

Gestión de Proyectos cuantitativa (QPM)


Desarrollo de Requerimientos (RD) Ingeniería 3Gestión de Requerimientos (REQM)


Gestión de Riesgos (RSKM) Gestión de proyectos 3



Gestión de Acuerdos de Proveedores (SAM)


Solución Técnica (TS) Ingeniería 3

Validación (VAL) Ingeniería 3

Verificación (VER) Ingeniería 3



Relaciones entre áreas de procesoLas relaciones entre las múltiples áreas de proceso, incluyendo la información y artefactos que fluyen de una a otra, ayudan a tener una visión más completa del proceso de implementación y mejora. Las iniciativas exitosas de mejoras de procesos tienen que estar dirigidas por los objetivos de negocio de la organización.

Aunque las áreas de proceso son organizadas por grupos para simplificar la comprensión de sus relaciones, estas frecuentemente interactúan y tienen efectos sobre otra independientemente de su grupo, categoría 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.

Gestión de procesosLas áreas de proceso del grupo “Gestión 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:

Definición del Proceso Organizacional (OPD) Enfoque del Proceso Organizacional (OPF) Gestión del Desempeño Organizacional (OPM) Rendimiento del Proceso Organizacional (OPP) Entrenamiento Organizacional (OT)

Áreas de gestión de procesos básicasLas áreas de gestión de procesos básicas proveen a la organización de la capacidad de documentar, y compartir mejores prácticas, bienes del proceso de la organización, y aprendizaje a través de la organización.

El área Enfoque del Proceso Organizacional (OPF) ayuda a la organización a planificar, implementar, e instalar mejoras de los procesos de la organización basados en un entendimiento de las fortalezas y debilidades actuales de los procesos de la organización y sus bienes.

Mejoras candidatas a los procesos de la organización son obtenidas a través de varias fuentes, Estas actividades incluyen propuestas de mejoras de procesos, mediciones de los procesos, lecciones aprendidas en la implementación de los procesos, y resultados de las actividades de evaluación de los procesos y productos.



El área Definición del Proceso Organizacional (OPD) establece y mantiene el set de procesos estándar de la organización, sus estándares de ambiente de trabajo, y otros activos basados en las necesidades del proceso y objetivos de la organización. Estos otros activos incluyen descripciones del modelo de ciclo de vida, guías de proceso de adaptación, y documentación y datos relacionados con el proceso. El proyecto adaptara los procesos estándar de la organización para crear su proceso definido.

El área Entrenamiento Organizacional (OT) identifica las necesidades estratégicas de entrenamiento de la organización, así como también las necesidades tácticas de entrenamiento que son comunes a través de proyectos y grupos de soporte. En particular, el entrenamiento es desarrollado u obtenido para desarrollar las habilidades necesarias para realizar los procesos estándar de la organización. 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 gestión de procesos avanzadasLa áreas de gestión de procesos avanzadas proveen a la organización 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 gestión de procesos básicas.

El área Rendimiento del Proceso Organizacional (OPP) obtiene objetivos cuantitativos para calidad y performance de los procesos de los objetivos de negocio de la organización. La organización provee a los proyectos y grupos de soporte con medidas comunes, líneas de base de performance de procesos, y modelos de performance de procesos. La organización 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 estándar de la organización.

En el área de Gestión del Desempeño Organizacional (OPM) las líneas de base y los modelos de la performance de los procesos son analizados para comprender la habilidad de la organización para lograr sus objetivos de negocio y obtener los objetivos de calidad y performance de procesos. Basada en este entendimiento la organización, proactivamente, selecciona y recoge mejoras incrementales e innovadoras que mejoran sensiblemente la performance de la organización. La organización puede también ajustar los objetivos del negocio y la calidad y objetivos de performance de los procesos como sea apropiado.

Gestión de proyectosLas áreas de proceso de gestión de proyectos cubren las actividades relacionadas con planificación, monitoreo, y control del proyecto.



Estas siete áreas son:

Gestión de Proyectos Integrada (IPM) Monitoreo y Control de proyecto(PMC) Planificación de Proyectos (PP) Gestión de Proyectos cuantitativa (QPM) Gestión de Requerimientos (REQM) Gestión de Riesgos (RSKM) Gestión de Acuerdos de Proveedores (SAM)

Áreas de gestión de proyectos básicasLas áreas de gestión de proyectos básicas 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 planificación comienza con los requerimientos que definen el producto y el proyecto: “que construir”. El plan del proyecto cubre las variadas actividades de gestión 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 contribución al proyecto.

El área de Monitoreo y Control de proyecto contiene prácticas 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 desvía significativamente de los valores esperados, acciones correctivas se deben tomar apropiadamente, las cuales pueden comprender replanificación, lo que requiere prácticas de Planificación de Proyecto.

El área de Gestión 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 Gestión 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 Ingeniería; así, la gestión de requerimientos es una secuencia de eventos dinámica y a menudo recursiva. Es fundamental para para una ingeniería de procesos controlada y disciplinada.

El área de procesos Gestión 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 aceptación y pruebas son realizadas sobre el componente producido por el proveedor.

Áreas de gestión de proyectos avanzadasLas áreas de gestión de proyectos avanzadas se dirigen a actividades tales como establecer un proceso definido que es ajustado desde el set de procesos estándar de la organización, estableciendo el ambiente de trabajo del proyecto desde los estándares de la organización, coordinando y colaborando con las partes interesadas relevantes; formando y manteniendo equipos para la conducción de proyectos, manejando el proyecto cuantitativamente, y manejando los riesgos.

El área de proceso de Gestión de Proyectos Integrada establece y mantiene el proceso definido para el proyecto que es ajustado del set de estándares de procesos de la organización (Definición 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 proyecto es establecido y mantenido desde los estándares de ambiente de trabajo de la organización, y los equipos se establecen utilizando las reglas y guías de la organización. Las partes interesadas relevantes coordinan sus esfuerzos de una manera oportuna a través de la identificación, negociación, y seguimiento de dependencias críticas y la resolución de problemas de coordinación.

Aunque la identificación y monitoreo de riesgos está cubierta en la planificación de proyectos y en el monitoreo y control de proyectos, el área de gestión de riesgos toma un enfoque con visión de futuro y continuo para manejo de riesgos, con actividades que incluyen la identificación de parámetros de riesgos, evaluación de riesgos, y mitigación.

El área de Gestión 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 organización y el cliente.

El proceso definido para el proyecto se compone utilizando técnicas estadísticas y otras cuantitativas. Tal análisis permite al proyecto predecir si va a alcanzar los objetivos de calidad y performance.

Basado en esta predicción 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.

Ingeniería Las áreas de proceso de ingeniería cubren las actividades de desarrollo y mantenimiento que son compartidas a través de las disciplinas de ingeniería, cualquiera sea la disciplina del producto en desarrollo (software, mecánica, etc.), para mejorar su proceso.

De este modo el foco se pone en objetivos esenciales del negocio más que en disciplinas específicas.

Las cinco áreas de proceso de ingeniería son:

Integración de productos (PI) Desarrollo de Requerimientos (RD) Solución Técnica (TS) Validación (VAL) Verificación (VER)

Como se puede observar en el gráfico, las áreas de proceso de Verificación y Validación se aplican a todas las demás, realizándose así la verificación tanto de los Requerimientos, como de la



Construcción de la solución y de la Integración, obteniendo así la trazabilidad necesaria para obtener un producto que funcione correctamente y se adecúe 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 solución 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 características de diseño, los requerimientos de verificación, etc., en términos que el desarrollador use y comprenda.

El área de proceso de desarrollo de requerimientos provee requerimientos al área de proceso de Solución Técnica, donde los requerimientos son convertidos en arquitectura del producto, componentes de diseño del producto, y componentes de producto. Los requerimientos son también suministrados al área de Integración 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 Solución Técnica desarrolla paquetes de datos técnicos para componentes de producto ser utilizados por las áreas Integración de productos o Gestión de acuerdos de Proveedores. Se evalúan soluciones alternativas para seleccionar el diseño óptimo basado en criterios establecidos. La tarea de seleccionar la solución final hace uso de prácticas específicas en el área de Análisis de Decisiones y Resolución.

El área de Solución Técnica depende de prácticas específicas en el área de Verificación para realizar verificación del diseño y revisiones de pares durante el diseño y previo a la construcción final.

El área de proceso de Verificación asegura que productos de trabajo seleccionados alcancen los requerimientos especificados. Selecciona los productos de trabajo y los métodos de verificación que serán utilizados para verificar respecto de los requerimientos especificados. Habitualmente es un proceso incremental que comienza con la verificación de los componentes del producto y usualmente concluye con la verificación del producto completamente ensamblado. También comprende revisiones de pares.

El área de proceso de Validación incrementalmente valida los productos frente a las necesidades del cliente. Puede ser realizado en un ambiente de operación o en uno simulado. La coordinación con el cliente en la validación de los requerimientos es un elemento importante de esta área de proceso.

El alcance del área de Validación incluye validación 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 Solución Técnica.



El área de Integración del producto utiliza prácticas específicas de ambas, Verificación y Validación para implementar el proceso de integración. Las prácticas de verificación verifican las interfaces y los requerimientos de las interfaces de los componentes de productos antes de la integración. La verificación de interfaces es un evento esencial en la integración del producto. Durante la integración en el ambiente operacional, las prácticas específicas de Validación de procesos son utilizadas.

Recursividad e iteración del proceso de ingenieríaLa mayoría de los estándares de procesos están de acuerdo en que hay dos formas de aplicar los procesos. Estas dos formas son recursividad e iteración.

Recursividad ocurre cuando un proceso es aplicado en sucesivos niveles de elementos del sistema dentro de la estructura del sistema. Las salidas de una aplicación son utilizadas como entradas para el nivel siguiente de la estructura del sistema.

Iteración ocurre cuando los procesos se repiten en el mismo nivel, nueva información es creada en la implementación de un proceso que alimenta esa información a los procesos relacionados.

Los procesos de ingeniería son implementados repetidamente en un producto para asegurar que esos procesos de ingeniería han sido adecuadamente dirigidos antes de la entrega al cliente. Además, los procesos de ingeniería son aplicados a componentes del producto.

Recursividad e iteración 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 también podrían ser recursivos porque algunas veces los proyectos están anidados con otros proyectos.

SoporteLas á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 realización de otros procesos. En general, las áreas proceso de soporte se dirigen a procesos que están señalados a lo largo del proyecto y puede alcanzar proceso que se aplican más generalmente a la organización.

Las cinco áreas de proceso de soporte son:

Análisis de Causa y Resolución (CAR) Gestión de la Configuración (CM) Análisis de Decisiones y Resolución (DAR) Medición y Análisis (MA) Aseguramiento de la Calidad del Proceso y del Producto (PPQA)



Áreas de soporte básicasLas áreas de soporte básicas se dirigen a funciones de soporte fundamentales utilizadas por todas las áreas de proceso, ya que proveen funciones de soporte que también ayudan a implementar varias prácticas genéricas.

El área de Medición y Análisis da soporte a todas las áreas de proceso al proveer prácticas específicas que guían a los proyectos y organizaciones a alinear necesidades de medición y objetivos con un enfoque de medición que es utilizado para dar soporte a las necesidades de información de gestión.

Aseguramiento de la Calidad del Proceso y del Producto da soporte a todas las áreas de proceso al proveer practicas específicas para evaluar objetivamente los procesos realizados, los productos de trabajo, y los servicios frente a las descripciones de procesos aplicables, estándares, 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 realimentación de los procesos y productos de trabajo asociados a través del ciclo de vida del proyecto.

El área de proceso de gestión de la configuración da soporte a todas las áreas de proceso al establecer y mantener la integridad de los productos de trabajo utilizando identificación de la configuración, control de la configuración, estados de cuentas de la configuración, y auditorias de configuración. 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 creación y descripción de los productos de trabajo.

Áreas de soporte avanzadasLas áreas de soporte avanzadas proveen a los proyectos y organización con un mejorado soporte de la calidad. Cada una de estas áreas de proceso se apoya en inputs específicos o prácticas de otras áreas de proceso.

Al utilizar el área de proceso Análisis de Causa y Resolución 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.

Análisis de Decisiones y Resolución da soporte a todas las áreas de proceso al determinar que problemas deben ser sujetos a un proceso formal de evaluación y entonces aplicar el proceso formal de evaluación a éstos.



Las áreas de proceso de Ingeniería

Integración de producto

PropósitoEl propósito del área de proceso es ensamblar el producto desde sus componentes para asegurar que el producto integrado se comporta apropiadamente.

Notas introductoriasEsta área de proceso dirige la integración de los componentes del producto en otros más complejos o en productos completos.

El alcance es alcanzar la integración completa del producto, a través del ensamblado progresivo de os componentes, sea en una o más etapas. Un aspecto crítico es la gestión de interfaces internas o externas, con las cuales hay que asegurar la compatibilidad.

Este proceso puede incluir análisis y simulaciones, para progresar incrementalmente en prototipos, hasta alcanzar el producto final.

Para muchos productos o servicios la integración final se realiza cuando es implementado en el sitio de operación pretendido.

Áreas de proceso relacionadasDesarrollo de requerimientos: para más información sobre la identificación de requerimientos de interfaces.

Solución técnica: para más información sobre diseño de interfaces utilizando criterios.

Validación: para más información sobre cómo realizar las validaciones

Verificación: para más información sobre cómo realizar verificaciones.

Gestión de la configuración: para más información sobre seguimiento y control de cambios.

Análisis de decisión y resolución: para información sobre el análisis de posibles decisiones utilizando un proceso de evaluación formal que evalúa alternativas identificadas versus criterios establecidos.

Gestión de Riesgos: para más información sobre identificación y mitigación de riesgos.

Gestión de Acuerdos de proveedores: par amas información sobre gerenciamiento de la adquisición de productos y servicios de proveedores.

Resumen de Goles y Prácticas específicasSG 1 Preparación para la integración del producto



SP 1.1 Establecimiento de una estrategia de integración

SP 1.2 Establecimiento de un ambiente de integración del producto

SP 1.3 Establecimiento de procedimientos y criterios de integración del producto

SG 2 Asegurar la compatibilidad de las interfaces.

SP 2.1 Revisión de las descripciones de interfaces para completitud

SP 2.2 Gestión de interfaces

SG 3 Ensamble de los componentes de producto y entrega del producto

SP 3.1 Confirmación de disponibilidad de los componentes del producto para integración

SP 3.2 Ensamble de los componentes de producto

SP 3.3 Evaluación de los componentes de producto ensamblados

SP 3.4 Empaque y entrega del producto o componente de producto

Desarrollo de requerimientos

PropósitoEl propósito del desarrollo de requerimientos es obtener, analizar, y establecer los requerimientos del cliente, del producto, y de los componentes del producto.

Notas introductoriasEsta á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 están presentes en todos los proyectos de desarrollo, y son la base del diseño. Incluyen las siguientes actividades:

Obtención, análisis, validación y comunicación de las necesidades y expectativas del cliente, y restricciones para priorizar los requerimientos que satisfarán a las partes interesadas.

Recolección y coordinación 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 específicos de diseño.

Los requerimientos son identificados y refinados a lo largo de las fases del ciclo de vida del producto.

La definición de la funcionalidad requerida y atributos de calidad describe lo que el producto debe hacer. Esta definición puede incluir descripciones, descomposiciones, y particiones de las funciones –servicios- del producto.

Adicionalmente la definición especifica consideraciones de diseño o restricciones sobre cómo la funcionalidad requerida debe ser realizada. Atributos de calidad se dirigen a cosas tales como disponibilidad del producto, mantenimiento, modificabilidad, líneas de tiempo, rendimiento, respuesta, confiabilidad, seguridad y escalabilidad. Algunos de estos pueden ser de importancia en la arquitectura y dirigirán el desarrollo de la misma.

Áreas de proceso relacionadasIntegración de productos: para más información sobre asegurar compatibilidad de interfaces

Solución técnica: para más información sobre selección de soluciones de componentes de producto y desarrollo del diseño.

Validación: para más información sobre validación del producto y sus componentes

Verificación: para más información sobre verificación de productos de trabajo seleccionados.

Gestión de la configuración: para más información sobre el seguimiento y control de cambios

Gestión de requerimientos: para más información sobre gestionar los requerimientos

Gestión de riesgos: para más información sobre identificación y análisis de riesgos.

Resumen de Goles y Prácticas específicasSG 1 Desarrollo de requerimientos de cliente

SP 1.1 Obtención de necesidades

SP 1.2 Transformación de las necesidades de stakeholders en requerimientos de clientes

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 Asignación de requerimientos de componentes de producto

SP 2.3 Identificación de requerimientos de interfaz.



SG 3 Análisis y validación de requerimientos

SP 3.1 Establecimiento de conceptos operacionales y escenarios

SP 3.2 Establecimientos de una definición de funcionalidad requerida y atributos de calidad.

SP 3.3 Análisis de requerimientos

SP 3.4 Análisis de requerimientos para alcanzar un balance

SP 3.5 Validación de requerimientos

Solución técnica

PropósitoEl propósito de la solución técnica es seleccionar, diseñar, e implementar soluciones para los requerimientos. Soluciones, diseños e implementaciones abarcan productos, componentes de producto, y procesos relacionados al producto en el ciclo de vida, ya sea en forma singular o combinadamente.

Notas introductoriasEl área de proceso de solución técnica 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 diseños detallados para las soluciones seleccionadas Implementar los diseños como producto o componente de producto

Típicamente estas actividades se apoyan mutuamente. Algún nivel de diseño, 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 técnicos, o un set de requerimientos completo.

Para un proyecto de mantenimiento los requerimientos pueden ser dirigidos por las necesidades del usuario, maduración u obsolescencia de la tecnología, 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 Solución técnica deben ser usados para realizar el mantenimiento o sostenimiento de los esfuerzos de diseño.



Áreas de proceso relacionadasDesarrollo de requerimientos para más información sobre asignación de requerimientos de componentes de producto, establecimiento de conceptos y escenarios operacionales, e identificación de requerimientos de interfaz.

Verificación para más información sobre realización de revisiones de pares, y verificación de productos de trabajo seleccionados.

Análisis de decisiones y resolución para más información sobre análisis de posibles decisiones usando un proceso de evaluación formal, que evalúa alternativas identificadas versus criterios establecidos.

Gestión del rendimiento de la organización para más información sobre seleccionar mejoras y desplegar mejoras.

Gestión de requerimientos para más información sobre gestión de requerimientos de los productos y componentes de producto del proyecto, asegurando alineación entre estos requerimientos y los planes del proyecto y los productos de trabajo.

Resumen de Goles y Prácticas específicasSG 1 Selección de soluciones de componentes de producto

SP 1.1 Desarrollo de soluciones alternativas y criterios de selección

SP 1.2 Selección de soluciones de componentes de producto

SG 2 Desarrollo del diseño

SP 2.1 Diseño del producto o del componente de producto

SP 2.2 Establecimiento de un paquete técnico de datos

SP 2.3 Diseño de interfaces utilizando criterios

SP 2.4 Realización de análisis de construcción, compra o reutilización.

SG 3 Implementación del diseño del producto

SP 3.1 Implementación del diseño

SP 3.2 Desarrollo de la documentación de soporte del producto.



Validación

PropósitoEl propósito del área de proceso Validación es demostrar que un producto o componente de producto cumple con el uso pretendido cuando es puesto en su pretendido ambiente

Notas introductoriasLas actividades de validación pueden ser aplicadas a todos los aspectos del producto en cualquiera de sus pretendidos ambientes, tales como operación, entrenamiento, manufactura, mantenimiento, y servicios de soporte.

Los métodos empleados en la validación pueden ser aplicados a productos de trabajo así como también al producto y componentes de producto. Los productos de trabajo deben ser seleccionados en base a cuáles son los mejores predictores de cuán bien el producto y sus componentes satisfarán las necesidades del usuario, por lo tanto la validación se realizará temprana e incrementalmente a través del ciclo de vida del producto.

El ambiente de validación del producto debe representar el ambiente pretendido por el producto y los componentes de producto, así como también representar el ambiente pretendido adecuado para actividades de validación con productos de trabajo.

La validación demuestra que el producto, como está previsto, va a cumplir con su pretendido uso, mientras que la verificación se dirige a si el producto de trabajo refleja apropiadamente los requerimientos especificados. En otras palabras la verificación se asegura de que lo hiciste bien, mientras que la validación se asegura de que hiciste lo correcto Ambas actividades frecuentemente corren concurrentemente y pueden utilizar porciones del mismo ambiente.

Cuando sea posible, la validación debe ser realizada utilizando el producto en el ambiente pretendido. La validación de actividades de servicio puede ser aplicada a producto de trabajo tales como propuestas, catálogos de servicio, declaraciones de trabajo, y registros de servicio.

Cuando se identifican problemas en la validación, son referidos para resolución a procesos asociados con el desarrollo de los requerimientos, Solución técnica, o Monitoreo y control de proyectos.

Las prácticas específicas de esta área de proceso se fortalecen entre sí de la siguiente forma:

La selección de productos para validación habilita la identificación de productos o componentes de producto a ser validados y los métodos a ser utilizados para realizar la validación

El establecimiento del ambiente de validación habilita la determinación del ambiente a ser utilizado para realizar la validación



El establecimiento de los procesos y criterios de validación habilita el desarrollo de procesos de validación y criterios que están alineados con las características de productos seleccionados, restricciones del cliente en la validación, métodos y ambiente de validación.

La realización de la validación es la práctica específica que habilita la realización de la validación de acuerdo con los métodos, procedimientos y criterios.

Áreas de proceso relacionadasDesarrollo de requerimientos: para más información sobre como provocar, analizar, y establecer los requerimiento de cliente, producto y componentes de producto

Solución técnica. Para más información sobre seleccionar, diseñar e implementar soluciones para los requerimientos.

Verificación: Para más información sobre asegurar que el producto de trabajo seleccionado cumple con los requerimientos especificados.

Resumen de Goles y Prácticas específicasSG 1 Preparación para Validación

SP 1.1 Seleccionar productos para validación

SP 1.2 Establecer el ambiente de validación

SP 1.3 Establecer procedimientos y criterios de validación

SG 2 Validación del producto o componentes de producto

SP 2.1 Realizar la validación

SP 2.2 Analizar los resultados de la validación

Prácticas específicas por gol

SG 1 Preparación para ValidaciónLas actividades de preparación incluyen la selección de productos y componentes de productos para validación y establecer y mantener el ambiente de validación, los procedimientos y criterios.

Los ítems seleccionados para la validación pueden incluir sólo el producto o niveles apropiados de componentes de productos utilizados para construir el producto. Cualquier producto o componente de producto puede ser sujeto a validación, 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, diseñado y construido. Los ambientes utilizados para integración de productos y verificación pueden ser considerados en colaboración con el ambiente de validación, para reducir costos y mejorar la eficiencia o productividad.

SP 1.1 Seleccionar los productos para validación

Los productos y componentes de producto son seleccionados para validación basados en su relación con las necesidades del usuario final. Para cada componente de producto el alcance de la validación (por ejemplo comportamiento operacional, mantenimiento, entrenamiento, interfaz de usuario) debe ser determinado.

Algunos ejemplos de productos y componentes que pueden ser validados incluyen: requerimientos, diseños, interfaces, manuales de usuario, etc.

Los requerimientos y restricciones para realizar la validación son recolectados. Entonces, los métodos de validación son seleccionados basados en su habilidad para demostrar que las necesidades del usuario final están satisfechas. Los métodos de validación no solo definen el enfoque para la validación del producto, sino que también dirigen las necesidades de instalaciones, equipos, y ambientes. El enfoque de la validación puede resultar en la generación de requerimientos de componentes de producto de nivel más bajo, los cuales serán manejados por el proceso de desarrollo de requerimientos. Requerimientos derivados como interfaces o sets de pruebas pueden ser generados, y también serán 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 métodos.

Los métodos de validación deben ser seleccionados en forma temprana en la vida del proyecto para poder ser claramente comprendidos y acordados por las partes interesadas relevantes.

Los métodos de validación comprenden el desarrollo, mantenimiento, soporte, y entrenamiento para el producto o componentes de producto como es apropiado.

Algunos ejemplos de métodos de validación 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 validación, métodos de validación para cada producto o componente, requerimientos para la realización de la validación, restricciones a la validación.

Las subprácticas en este caso son: identificar los principios fundamentales, características, y fases para la validación del producto a través del ciclo de vida, determinar que categorías de usuarios finales es necesaria, seleccionar los componentes y productos a ser validados, seleccionar los métodos de evaluación, revisar la selección, restricciones y métodos de la validación con las partes interesadas relevantes.



SP 1.2 Establecer el ambiente de validación

Los requerimientos para el ambiente de validación son impulsados por el producto o componentes seleccionados, el tipo de producto de trabajo y por los métodos de validación.

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 validación puede incluir la reutilización de recursos existentes. En este caso se deben gestionar los arreglos para el uso de éstos.

Algunos ejemplos de elementos en un ambiente de validación incluyen: herramientas de prueba en interfaz con el producto validado, programas de pruebas temporalmente integrado, herramientas de grabación para análisis posterior, sistemas o componentes simulados, personas entrenadas para operar o utilizar los elementos, etc.

La selección temprana de productos o componentes a ser validados, productos de trabajo a ser utilizados en la validación, y métodos de validación es necesaria para asegurar que el ambiente de validación esté disponible cuando sea necesario. El ambiente de validación debe ser cuidadosamente controlado para proveer replicación, análisis de resultados, y revalidación de áreas de problemas.

El ambiente de validación es un ejemplo de producto de trabajo de esta práctica específica.

Las subprácticas en este caso son: identificar recursos para la validación del medio ambiente, productos entregados al cliente, equipos de pruebas y herramientas, validación de recursos que están disponibles para reutilización y modificación, planificación de la disponibilidad de recursos en detalle.

SP 1.3 Establecer los procedimientos y criterios de validación

Los procedimientos y criterios de validación 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 aceptación pueden ser utilizadas para los procedimientos de validación. Los procedimientos y criterios de validación incluyen pruebas y evaluaciones de mantenimiento, entrenamiento y servicios de soporte.

Ejemplos de fuentes para criterios de validación incluyen: requerimientos de productos y componentes, estándares, criterios de aceptación del cliente, desempeño ambiental y umbrales de rendimiento de la performance.



Ejemplos de productos de trabajo son: procedimientos de validación, criterios de validación, y pruebas y procedimientos de evaluación para mantenimiento, entrenamiento y soporte.

Las subprácticas son: revisión de los requerimientos de producto para asegurar que los problemas afectando la validación de producto son identificados y resuelta; documentación de ambiente, escenario de operación, procedimientos, entrada, salidas, y criterios para la validación de los productos seleccionados; evaluación del diseño mientras madura en el contexto de la validación del ambiente para identificar problemas de validación.

SG 2 Validación del producto o componentes de productoLos métodos de validación, 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 validación. Las actividades de validación son realizadas durante todo el ciclo de vida del producto.

SP 2.1 Realizar la validación

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 validación son realizadas y los datos de resultado con recogidos de acuerdo con métodos, procedimientos y criterios establecidos.

Los procedimientos de validación de ejecución deben ser documentados y las desviaciones ocurridas durante la ejecución deben ser anotadas apropiadamente.

Ejemplos de productos de trabajo son. Reportes de validación, resultados de validación, validación cruzada de matriz de referencia, log de procedimiento de ejecución, demostraciones de operación.

SP 2.2 Análisis de los resultados de validación

Los datos resultantes de las pruebas de validación, inspecciones, demostraciones o evaluaciones son analizados contra los criterios definidos de validación. Los reportes de análisis 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 evaluación para determinar si proceder o registrar requerimientos o designar problemas en el desarrollo, en los requerimientos o en las soluciones técnicas propuestas.



El análisis de los reportes o la documentación de la validación de ejecución pueden también indicar que los resultados fallidos de las pruebas se deben a problemas en los procedimientos de validación o del ambiente de validación.

Ejemplos de productos de trabajo son: reportes de deficiencia de validación, problemas en la validación, procedimientos de pedidos de cambios.

Las subprácticas son: comparación de los resultados reales con los esperados; identificación de productos y componentes que no funcionan adecuadamente en el ambiente pretendido de operación, o identificación de problemas con métodos, criterios o ambiente; análisis de datos de validación para encontrar defectos, registro de resultados del análisis e identificación de problemas; uso de los resultados de validación para comparar las medidas reales y rendimiento con el uso pretendido o las necesidades operacionales; proveer información sobre como los defectos pueden ser resueltos, incluyendo métodos de validación, criterios y ambiente de validación, e iniciar acciones correctivas.

El área de Monitoreo de proyectos y control puede aportar información sobre cómo gestionar las acciones correctivas.



Verificación

PropósitoEl propósito de la Verificación (VER) es asegurar que los productos de trabajo seleccionados alcanzan los requerimientos especificados

Notas introductoriasEl área de proceso Verificación abarca lo siguiente: preparación de la verificación, rendimiento de la verificación, e identificación de acciones correctivas.

La verificación incluye verificación del producto, y de trabajos de producto intermedios, contra todos los requerimientos seleccionados, incluyendo los requerimientos de cliente, producto, y componentes de producto.

Para líneas de producto, principales activos y sus mecanismos de variación de línea de productos deben también ser verificados. A través de las áreas de proceso, donde los términos “producto” y “componentes de producto” son utilizados, sus mecanismos pretendidos también abarcan servicios, sistemas de servicios, y sus componentes.

La verificación es inherentemente un proceso incremental porque ocurre a través del desarrollo del producto y productos de trabajo, comenzando con la verificación de requerimientos, pasando por la verificación de los productos de trabajo en evolución, y finalizando en la verificación del producto completo.

Las prácticas específicas de esta área de proceso se apoyan entre sí de la siguiente forma:

La selección de productos de trabajo permite la identificación de productos de trabajo a ser verificados, métodos a ser utilizados para realizar la verificación, y los requerimientos a ser satisfechos por cada producto de trabajo seleccionado.

Establecer el ambiente de verificación habilita la determinación del ambiente a ser usado para llevar a cabo la verificación.

El establecimiento de criterios y procedimientos de verificación habilita el desarrollo de procesos de verificación y criterios que se alienan con los productos de trabajo, requerimientos, métodos y características del ambiente de verificación seleccionados.

La realización de la práctica especifica de la verificación conduce la verificación conduce a la verificación en su totalidad de acuerdo con métodos, criterios y procedimientos disponibles.

La verificación 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 verificación y validación son muy similares, pero se dirigen a problemas diferentes. La validación demuestra que el producto, como será entregado, cumplirá con el uso pretendido, mientras que la verificación se dirige a si el producto de trabajo refleja apropiadamente los requerimientos especificados. En otras palabras, la verificación asegura que “lo hiciste bien”, mientras que la validación asegura que “hiciste la cosa adecuada”.

Revisiones de pares son una parte importante de la verificación, y son mecanismos probados de remoción 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 metódico de los productos de trabajo por parte de los compañeros de producción, para identificar defectos y otros cambios necesarios.

Ejemplos de métodos de revisión de pares incluyen: inspecciones, recorridas estructuradas, refactorización deliberada, programación de a pares, etc.

En los ambientes “Agile”, debido a la implicación del cliente y a las frecuentes versiones, la verificación y la validación se dan soporte mutuo, ayudando a asegurar un enfoque sistemático de selección de los productos de trabajo a ser revisados y probados, los métodos y ambientes a utilizar, y las interfaces a gestionar, lo que ayuda a asegurar que los defectos son identificados en forma temprana.

Áreas de proceso relacionadasDesarrollo de requerimientos: para más información sobre como provocar, analizar, y establecer los requerimientos del cliente, producto y componentes de producto

Validación: para demostrar que el producto o componentes de producto cumplen el uso pretendido cuando se los ubica en el ambiente pretendido.

Gestión de requerimientos: para más información sobre asegurar alineación entre el trabajo del proyecto y los requerimientos.

Resumen de goles y prácticas específicas:SG 1 Preparación para la verificación

SP 1.1 Seleccionar los productos de trabajo para la verificación

SP 1.2 Establecer el ambiente de verificación

SP 1.3 Establecer los procedimientos y criterios de verificación



SG 2 Realizar revisiones de pares

SP 2.1 Preparación 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 verificación

SP 3.2 Analizar los resultados de la verificación

Prácticas específicas por gol

SG 1 Preparación para la verificaciónPreparación por adelantado es necesaria para asegurar que las previsiones de la verificación están embebidas en los requerimientos, diseños, planes de desarrollo, y cronogramas del producto y componentes de producto. La verificación incluye la selección, inspección, pruebas, análisis y demostración de los productos de trabajo.

Los métodos de verificación incluyen, pero no se limitan a: inspecciones, revisiones de pares, auditorias, recorridos, análisis, evaluaciones de arquitectura, simulaciones, pruebas y demostraciones. Las prácticas relacionadas a revisiones de pares como método específico de verificación se incluyen en el gol específico 2.

La preparación también implica la definición de herramientas de soporte, equipos de pruebas, programas, simulaciones, prototipos, e instalaciones.

SP 1.1 Seleccionar los productos de trabajo para la verificación

Los productos de trabajo son seleccionados de acuerdo con la contribución 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 verificación son incluidos con los métodos de verificación. Los métodos de verificación direccionan el enfoque para la verificación de los productos de trabajo, y los enfoques específicos que serán utilizados para verificar que productos de trabajo específicos alcanzan los requerimientos.

Ejemplos de métodos de verificación incluyen: evaluación de la arquitectura del software, y evaluación de la conformidad de la implementación; pruebas de cobertura de rutas, pruebas de



carga estrés y performance; pruebas basadas en la descomposición funcional, integración continua, etc.

La verificación para ingeniería de sistemas típicamente incluye prototipos, modelos y simulación para verificar la adecuación del diseño del sistema.

La selección de los métodos de verificación típicamente comienza con la definición de los requerimientos del producto y componentes de producto para asegurar que los requerimientos sean verificables. Los proveedores deberían estar envueltos en esta selección para asegurarse que los métodos del proyecto son apropiados para su ambiente.

Ejemplos de productos de trabajo son: listas de productos de trabajo seleccionados para la verificación, métodos de verificación para cada producto de trabajo seleccionado.

Las subprácticas son: identificar productos de trabajo para verificación; identificar requerimientos a ser satisfechos por cada producto de trabajo seleccionado; identificación de métodos disponibles para utilización; definir los métodos de verificación para ser utilizados por cada producto de trabajo; presentar para integración con el plan del proyecto la identificación de productos de trabajo a ser verificados, los requerimientos a satisfacer, y los métodos a utilizar.

SP 1.2 Establecer el ambiente de verificación

Un ambiente debe ser establecido para permitir que la verificación tenga lugar. El ambiente de verificación puede ser adquirido, desarrollado, reusado, modificado u obtenido usando una combinación de esas actividades, dependiendo de las necesidades del proyecto.

El tipo de ambiente requerido depende de los productos de trabajo seleccionados para la verificación y los métodos utilizados. Una revisión de pares puede requerir poco más que un paquete de materiales, revisores y una sala. Las pruebas de un producto pueden requerir simulación simuladores, emuladores, generadores de escenario, herramientas de reducción de datos, controles ambientales, e interfaces con otros sistemas.

Productos de trabajo de esta práctica específica son, por ejemplo, ambientes de verificación.

Las subprácticas son: identificación de requerimientos ambientales de verificación; identificación de recursos de verificación que están disponibles para reutilización o modificación; identificación de equipos y herramientas; adquirir equipos y ambientes de soporte para la verificación.

SP 1.3 Establecer los procedimientos y criterios de verificación

Los criterios de verificación son definidos para asegurar que los productos de trabajo cumplen con los requerimientos.



Algunos ejemplos de fuentes de criterios de verificación incluyen: requerimientos de productos y componentes de producto, estándares, políticas de la organización, tipos de productos de trabajo, proveedores, propuestas y contratos, etc.

Ejemplos de productos de trabajo son: procedimientos de verificación, y criterios de verificación.

Las subprácticas son: generar un set de procedimientos de verificación exhaustivo, integrado, para productos de trabajo y productos comerciales fuera de plataforma, según será necesario; desarrollar y refinar los criterios de verificación 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 verificación.

SG 2 Realizar revisiones de paresLas revisiones de pares comprenden un examen metódico 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 método de verificación efectivo, implementado por medio de inspecciones, recorridos estructurados, u otros tantos métodos de revisión colectivos.

Las revisiones de pares son primariamente aplicadas a productos de trabajo desarrollados por los proyectos, pero pueden ser también aplicados a otros productos de trabajo tales como documentación o productos de entrenamiento que son típicamente desarrollados por grupos de soporte.

SP 2.1 Preparación para revisiones de pares

Las actividades de preparación para las revisiones de pares típicamente incluyen identificar al personal que será invitado a participar de la revisión para cada uno de los productos, identificar los revisores clave que deben participar en la revisión de pares, preparar y actualizar materiales a ser utilizados durante las revisiones de pares, tales como listas de verificación y criterios de revisión, y programar las revisiones.

Algunos ejemplos de productos de trabajo son: cronograma de revisión de pares; listas de verificación; criterios de entrada y salida de productos de trabajo, productos seleccionados para ser revisados, etc.

La subpráctica es determinar el tipo de revisión de par a ser realizada; definir los requerimientos para recoger los datos durante la revisión, establecer y mantener criterios de entrada y salida; establecer y mantener criterios para requerir otra revisión; establecer y mantener listas de verificación para asegurar que los productos son revisados consistentemente, desarrollar un



cronograma detallado de revisiones, incluyendo fechas de ejecución y cuando los materiales para la revisión estarán disponibles; asegurar que el producto de trabajo satisface los criterios de entrada a la revisión previamente a la distribución; distribuir el producto de trabajo a ser revisado y la información relacionada a los participantes suficientemente temprano como para permitirles prepararse adecuadamente a la revisión; asignar roles para la revisión, tales como líder, lector, grabador, autor; prepararse para la revisión revisando el producto de trabajo antes de conducir la revisión.

SP 2.2 Conducir las revisiones de pares

Uno de los propósitos de realizar una revisión de pares es definir y remover temprano los defectos. Las revisiones de pares se realizan incrementalmente mientras los productos de trabajo están siendo desarrollados. Estas revisiones están estructuradas y no son revisiones de gerencia.

Las revisiones de pares pueden ser realizadas en productos clave de especificación, diseño, prueba y actividades de implementación, y en productos específicos de planificación.

El foco de las revisiones de pares debe ser el producto en revisión, no en la persona que lo produce.

Cuando surgen problemas durante la revisión, deben ser comunicados al desarrollador primario del producto a corregir.

Las revisiones de pares deben seguir las siguientes guías: deben tener suficiente preparación, la realización debe ser gestionada y controlada, datos consistentes y suficientes deben ser grabados, y deben ser registrados ítems de acción.

Ejemplos de los productos de trabajo son: resultados de las revisiones, problemas de las revisiones y datos de la revisión de pares.

Las subprácticas son: realizar los roles asignados en la revisión de pares; identificar y documentar los defectos y otros problemas en el producto; registrar los resultados de la revisión, incluidos los ítems de acción; recolectar datos de la revisión de pares; identificar ítems de acción y comunicar los problemas a las partes interesadas relevantes; realizar revisiones adicionales si fueran necesarias; asegurar que los criterios de salida para la revisión están satisfechos.

SP 2.3 Analizar los datos de las revisiones de pares

Esta práctica especifica trata de analizar datos de la preparación, realización y resultados de la revisión de pares. Para más información sobre la obtención de datos de medida y su análisis se puede aplicar el área de proceso de Medición y análisis.



Ejemplos de productos de trabajo son: datos de revisión de pares; ítems de acción de las revisiones de pares.

Las subprácticas son: registro de datos relacionados con la preparación, ejecución y resultados de las revisiones de pares; almacenamiento de los datos para futuro análisis y referencia; protección de los datos para asegurar que las revisiones de pares no son utilizadas en forma inapropiada; análisis de los datos de las revisiones de pares.

SG 3 Verificar los productos de trabajo seleccionadosMétodos de verificación; procedimientos, y criterios son utilizados para verificar productos de trabajo seleccionados y el mantenimiento, entrenamiento y servicios de soporte asociados, utilizando el ambiente de verificación apropiado. Las actividades de verificación deben ser realizadas a través de todo el ciclo de vida del producto. Las prácticas relacionadas con las revisiones de pares como método especifico se incluyeron ya en el SG 2.

SP 3.1 Realizar la verificación

La verificación de productos y productos de trabajo de forma incremental promueve la detección temprana de problemas y puede resultar en una temprana remoción de los defectos. Los resultados de verificación ahorran los considerables costos de defectos de aislamiento y retrabajo asociados con la solución de problemas.

Ejemplos de productos de trabajo son: resultados de verificación, reportes de verificación, demostraciones y log de procedimientos como fueron ejecutados.

Las subprácticas son: realizar la verificación de productos de trabajo seleccionados contra los requerimientos; registro de los resultados de las actividades de verificación; identificación de ítems de acción resultantes de la verificación de productos de trabajo; documentación de los métodos de verificación como fueron ejecutados y desviaciones de los métodos y procedimientos disponibles descubiertos durante su rendimiento.

SP 3.2 Analizar los resultados de la verificación

Los resultados reales deben ser comparados contra los criterios de verificación establecidos para determinar la aceptabilidad.

Los resultados del análisis son registrados como evidencia de que la verificación fue realizada.

Para cada producto de trabajo, todos los resultados de verificación disponibles son analizados incrementalmente para asegurar que los requerimientos se han alcanzado. Como las revisiones de



pares son parte de los métodos de verificación, los datos de éstas deben ser incluidos en el análisis para asegurar que los resultados de la verificación son suficientemente analizados.

Reportes de análisis o documentación del método “as run” puede también indicar que los resultados negativos de una verificación son debidos a un problema de método, de criterio o a un problema del ambiente de verificación.

Ejemplos de productos de trabajo son: reporte de análisis, reporte de dificultad, pedios de cambios para métodos, criterios y ambiente de verificación.

Las subprácticas son: comparar los resultados reales con los esperados; según los criterios de verificación, identificar los productos que no alcanzan sus requerimientos o identificar problemas con métodos, procedimientos, criterios y de ambiente de verificación; análisis de datos de defecto; registro de todos los resultados del análisis en un reporte, utilizar los resultados de verificación para comparar las medidas y rendimiento reales con los parámetros técnicos de performance; proveer la información de cómo los defectos pueden ser resueltos e iniciar la acción correctiva.

Sobre las acciones correctivas, más datos pueden ser hallados en el área de proceso de monitoreo control de proyectos.



Norma ISO/IEC 12207, IEEE 12207-2008 – Ingeniería 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 estándar 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 propósitos de proceso y salidas, y estableciendo un Modelo de Proceso de Referencia, de acuerdo con los requerimientos de la norma ISO/IEC 15504-2, Ingeniería de software— evaluación de proceso.

Esta norma puede ser utilizada de diferentes maneras: por una organización, 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 guía 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, propósito, limitaciones y conformidad de la normaEsta norma establece un marco común para los procesos de ciclo de vida de software: contiene procesos, actividades y tareas que han de aplicarse durante la adquisición de un producto o servicio de software y durante el suministro, desarrollo, operación, mantenimiento y eliminación de productos de software.

La norma aplica a la adquisición de sistemas y productos y servicios de software, al suministro, desarrollo, operación, mantenimiento y eliminación de productos de software y a la parte de software de un sistema, ya sean realizadas interna o externamente a una organización.

También provee un proceso que puede ser empleado para definir, controlar y mejorar los procesos del ciclo de vida del software.

El propósito de esta norma es proveer un set de procesos definidos para facilitar la comunicación 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 organización.



Esta norma no detalla los procesos de ciclo de vida en términos de métodos o procedimientos requeridos para alcanzar los requerimientos y salidas de un proceso; no detalla documentación en términos de nombre, formato, contenido explícito 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 específico de ciclo de vida de sistemas o software, metodología de desarrollo, método, modelo o técnica, 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 cláusulas de la norma son seleccionadas o modificadas de acuerdo con el proceso de adaptación 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.

Aplicación de la normaEn general esta norma aplica tanto a productos como servicios de software. Las disposiciones de procesos específicos definen la aplicabilidad.

En esta norma se establece un fuerte vínculo entre sistema y software, basado en los principios generales de la ingeniería de sistemas. El software es tratado como una parte integral del sistema total, y desarrolla ciertas funciones en el sistema.

Una premisa fundamental en este estándar es que el software siempre existe en el contexto de un sistema.

Esta norma tiene una fuerte relación 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 mínimo apropiado para el software.

Respecto de todo el ciclo de vida, en nuestro análisis focalizaremos en las tareas referidas a: evaluación, aseguramiento de la calidad, verificación, validación, revisión, auditoría; y más específicamente 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 verificación y validación 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 evaluación se dan en los procesos de Revisión de Software, Auditoría de software, Aseguramiento de la calidad del software, y Gerenciamiento del modelo de ciclo de vida.

Categorías de procesos del ciclo de vidaEsta 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 términos de su propósito, salidas deseadas, y lista de actividades y tareas que necesitan ser realizadas para alcanzar esas salidas.

1) Proceso de contrato2) Proceso de habilitación organizacional del proyecto3) Procesos de proyecto4) Procesos técnicos5) Procesos de implementación del software 6) Procesos de soporte del software7) Procesos de reutilización del software



Todos estos procesos están descriptos y definidos a lo largo de las diferentes cláusulas de la norma (5, 6 y 7). Las dos mayores sub-divisiones de procesos están en las cláusulas 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 específicos de software para utilizar en la implementación de productos o servicios de software como elementos de un sistema mayor.

Dentro de estas cláusulas nuestra investigación se centrará, como ya fue anticipado, en los procesos específicos del software de la cláusula 7, y más en particular en las cláusulas 7.1.7 (Pruebas de calificación del software), 7.2.3 (Aseguramiento de la calidad del software), 7.2.4 (Verificación del software), 7.2.5 (Validación del software), 7.2.6 (Revisión del software) y 7.2.7 (Auditoría del software).

Procesos específicos de software

Procesos de implementación de softwareLos procesos de implementación del software son utilizados para producir un elementos específico del sistema (ítem de software) implementado en software. Estos procesos transforman comportamientos especificados, interfaces y restricciones de implementación en acciones de



implementación resultando en un elemento de sistema que satisface los requerimientos derivados de los requerimientos de sistema.

El propósito es producir un elemento de sistema especificado implementado como producto o servicio de software.

El proceso dentro del cual se encuentran los procesos de implementación es el Proceso de Implementación de Software. Este tiene varios procesos específicos de software de menor nivel:

a) Proceso de análisis de requerimientos de software: su propósito es establecer los requerimientos de los elementos de software del sistema

b) Proceso de diseño de arquitectura de software: su propósito es proveer un diseño para el software implementado y puede ser verificado contra los requerimientos.

c) Proceso de diseño de detalle del software: su propósito es proveer un diseño 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 codificación y testing.

d) Proceso de construcción del software: su propósito es producir unidades de software ejecutable que reflejan apropiadamente el diseño del sistema.

e) Proceso de integración del software: su propósito es combinar las unidades y los componentes de software produciendo ítems de software integrado, consistentes con el diseño de software, que demuestra que los requerimientos funcionales y no funcionales del software están satisfechos en una plataforma operacional completa o equivalente.

f) Proceso de testing de calificación del software: su propósito es confirmar que el producto de software integrado alcanza los requerimientos definidos.

Procesos de soporte de softwareLos procesos de soporte de software proveer un set de actividades específicamente enfocadas para realizar un proceso de software especializado. Un proceso de soporte asiste al proceso de implementación de software como una parte integral con un propósito distinto., contribuyendo al éxito y calidad del proyecto de software. Hay ocho procesos de soporte:

a) Proceso de gestión de la documentación del software: b) Proceso de gestión de la configuración del softwarec) Proceso de aseguramiento de la calidad del softwared) Proceso de verificación del softwaree) Proceso de validación del softwaref) Proceso de revisión del softwareg) Proceso de auditoría del softwareh) Proceso de resolución de problemas del software



Procesos de reutilización de softwareLos procesos de reutilización del software consisten en tres procesos que soportan la habilidad de una organización de reutilizar ítems de software a través de los límites del proyecto. Estos procesos son únicos porque, por su naturaleza, operan fuera de los límites de cualquier proyecto particular.

a) Proceso de dominio de la ingenieríab) Proceso de gestión de reutilización de bienesc) Proceso de gestión de reutilización de programas

Procesos relacionados con la calidad del software

Proceso de testing de calificación del software

PropósitoEl propósito del proceso de pruebas de calificación del software es confirmar que el producto de software integrado alcanza sus requerimientos definidos.

SalidasComo resultado de una implementación exitosa del proceso de testing de calificación 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 regresión es desarrollada y aplicada para re-testear el software

integrado cuando se realizan cambios en los ítems de software.

ActividadesEl proyecto deberá implementar las siguientes actividades de acuerdo con las políticas aplicables de la organización y procedimientos con respecto al proceso de testing de calificación del software.

Testing de calificación del software: Para cada ítem de software esta actividad consiste en las siguientes tareas:

1. El implementador conducirá el testing de calificación de acuerdo con los requerimientos de calificación para el ítem de software. Será asegurado que la implementación de cada requerimiento es testeado para conformidad. Los resultados serán documentados.



2. El implementador actualizará la documentación de usuario según sea necesario.3. El implementador evaluará el diseño, código, pruebas, resultados de las pruebas y

documentación de usuario considerando los siguientes criterios:a. Cobertura de los requerimientos en las pruebas del ítem de softwareb. Conformidad con los resultados esperadosc. Factibilidad de integración de sistema y testing, de realizarsed. Factibilidad de operación y mantenimiento

4. El implementador dará apoyo a las auditorías de acuerdo con la sub-cláusula 7.2.7 (proceso de auditoría de software). Los resultados serán documentados. Si ambos, hardware y software están en desarrollo o integración, las auditorías podrían ser pospuestas hasta el Testing de calificación del sistema.

5. Al completarse exitosamente las auditorías, de realizarse, el implementador actualizará y preparará el producto de software entregable para Integración de Sistema, Testing de calificación de sistema, Instalación de software, o Soporte de aceptación de software, según sea aplicable.

Proceso de aseguramiento de la calidad del Software

PropósitoEl propósito del proceso de aseguramiento de la calidad del software es proveer aseguramiento de que los productos de trabajo y los procesos están conforme a los planes dispuestos.

SalidasComo resultado de la implementación 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 adhesión de los productos, procesos y actividades a los estándares,

procedimientos y requerimientos aplicables

ActividadesEl proyecto deberá implementar las siguientes actividades de acuerdo con las políticas aplicables de la organización y procedimientos con respecto al proceso aseguramiento de la calidad del software.



Implementación del procesoConsiste 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 están 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 Verificación (sub-clausula 7.2.4), Validación (sub-cláusula 7.2.5), Revisión de Software (sub-cláusula 7.2.6) y Auditoría (sub-cláusula 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. Estándares de calidad, metodologías, procedimientos, y herramientas, para realizar las actividades de aseguramiento de la calidad

b. Procedimiento para revisión de contrato y coordinación del mismoc. Procedimientos para identificar, recolectar, completar, mantener y disponer de los

registros de calidadd. Recursos, cronograma, y responsabilidades para conducir las actividades de

aseguramiento de la calidade. Selección de actividades y tareas de los procesos de soporte, tales como

Verificación, Validación, Revisión, Auditoría, y Resolución de problemas.4. Se ejecutarán 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, deberán ser documentados y servir de input para el proceso de Resolución de problemas. Los registros de estas actividades y tareas, su ejecución, problemas y resolución de problemas serán preparados y mantenidos.

5. Los registros de las actividades y tareas de aseguramiento de la calidad estarán 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 resolución de problemas.

Aseguramiento del productoConsiste en las siguientes tareas:

1. Será asegurado que todos los planes requeridos por el contrato están documentados, están de acuerdo con el contrato, son mutuamente consistentes, y se están ejecutando como es requerido



2. Será asegurado que los productos de software y su documentación relacionada están de acuerdo al contrato y adhieren a los planes.

3. En preparación 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 procesoConsiste en las siguientes tareas:

1. Será asegurado que los procesos del ciclo de vida del software empleados por el proyecto están de acuerdo con el contrato y adhieren a los planes

2. Será asegurado que las prácticas internas de ingeniería de software, el ambiente de desarrollo, el ambiente de test, y las librerías están 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.

4. Será asegurado que el adquiriente y otras partes tienen el soporte requerido y la cooperación de acuerdo con el contrato, negociaciones y planes.

5. Debería ser asegurado que las medidas del producto y proceso de software están de acuerdo con los estándares 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 calidadConsiste en las siguientes tareas:

1. Las actividades adicionales de gestión de la calidad podrían ser aseguradas de acuerdo con las cláusulas de la norma ISO 9001.

Proceso Verificación del Software

PropósitoEl propósito del proceso de verificación del software es confirmar que cada producto de trabajo de software y/o servicio de un proceso o proyecto, reflejan apropiadamente los requerimientos especificados.

SalidasComo resultado de una exitosa implementación del proceso de Verificación del software:

- Una estrategia de verificación es desarrollada e implementada



- Son identificados criterios para verificación de todos los productos de trabajo de software- Se realizan las actividades de verificación requeridas- Los defectos son identificados y registrados- Los resultados de las actividades de verificación se hacen disponibles para el cliente y otras

partes involucradas.

ActividadesEl proyecto deberá implementar las siguientes actividades de acuerdo con las políticas aplicables de la organización y procedimientos con respecto al proceso de verificación de software.


1. Se hará una determinación para ver si el proyecto garantiza un esfuerzo de verificación y el grado de independencia organizacional que este esfuerzo precisa. Los requerimientos del proyecto serán analizados por criticidad, la cual será medida en términos de:

a. El potencial de un error no detectado en un sistema o software para causar la muerte o daños corporales, fracaso en la misión, o pérdidas financieras o perdidas catastróficas de equipos o daños.

b. La madurez y riesgos asociados con la tecnología de software a ser utilizadac. Disponibilidad de fondos y recursos

2. Si el proyecto garantiza un esfuerzo de verificación, un proceso de verificación será establecido para verificar el producto de software.

3. Si el proyecto garantiza un esfuerzo de verificación independiente, se deberá seleccionar una organización calificada, responsable de conducir la verificación. Dicha organización debe ser asegurada de independencia y autoridad para realizar las actividades de verificación.

4. Basado en el alcance, la magnitud, complejidad, y análisis crítico, se determinaran las actividades del ciclo de vida destino y los productos de software que requieran verificación Las actividades y tareas de verificación, incluyendo los métodos asociados, técnicas y herramientas para realizar las tareas, serán seleccionados para las actividades del ciclo de vida destino y productos de software.

5. Basado en las tareas de verificación determinadas, un plan de verificación será desarrollado y documentado. Dicho plan debe definir las actividades del ciclo de vida y los productos de software que requieran verificación, las tareas de verificación 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 verificación al adquiriente y otras organizaciones involucradas.



VerificaciónConsiste en las siguientes tareas:

1. Verificación de requerimientos: los requerimientos serán verificados considerando los siguientes criterios:

a. Los requerimientos de sistema son consistentes, factibles y testeables.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 métodos adecuadamente rigurosos.

2. Verificación del diseño: el diseño será verificado considerando los siguientes criterios:a. El diseño es correcto y consistente con los requerimientos trazables.b. El diseño implementa una secuencia apropiada de eventos, entradas, salidas,

interfaces, flujo de la lógica, asignación de tiempo, tamaño de los presupuestos, y definición de errores, aislamiento, y recuperación.

c. El diseño seleccionado puede ser derivado de los requerimientos.d. El diseño implementa seguridad, y otros requerimientos críticos en forma

correcta, como se muestra por métodos adecuadamente rigurosos.3. Verificación del código: el código será verificado considerando los siguientes criterios:

a. El código es trazable al diseño y a los requerimientos, testeable, correcto y conforme a los requerimientos y a los estándares de código.

b. El código implementa una secuencia de eventos adecuada, con interfaces consistentes, datos correctos y control de flujo, integridad, apropiada asignación de tiempo y de tamaño de los presupuestos, y definición de errores, aislamiento y recuperación.

c. El código seleccionado puede ser derivado del diseño o los requerimientos.d. El código implementa seguridad, y otros requerimientos críticos en forma

correcta, como se muestra por métodos adecuadamente rigurosos.4. Verificación de la Integración: la integración 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 integración han sido realizadas de acuerdo con un plan de

integración.5. Verificación de la documentación: la documentación será verificada considerando los

siguientes criterios:a. La documentación es adecuada, completa y consistente



b. La preparación de la documentación se hace en tiempoc. La gestión de la configuración de documentos sigue procedimientos específicos.

Proceso Validación del Software

PropósitoEl propósito del proceso de validación del software es confirmar que los requerimientos para un uso específico pretendido de producto de trabajo de software se cumplen.

SalidasComo resultado de una implementación exitosa del proceso de validación del software:

- Una estrategia de validación es desarrollada e implementada- Se identifican criterios para validación de los productos de trabajo requeridos - Se realizan las actividades de validación 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 validación se hacen disponibles al cliente y otras

partes involucradas

ActividadesEl proyecto deberá implementar las siguientes actividades de acuerdo con las políticas aplicables de la organización y procedimientos con respecto al proceso de validación de software.


1- Se realizará una determinación sobre si el proyecto garantiza un esfuerzo de validación y el grado de independencia organizacional que el esfuerzo necesita

2- Si el proyecto garantiza un esfuerzo de validación, un proceso de validación será establecido para validar el sistema o producto de software. Las tareas de validación, incluyendo métodos asociados, técnicas, y herramientas para realizar las tareas serán seleccionados.

3- Si el proyecto garantiza un esfuerzo independiente, una organización calificada responsable de conducir el esfuerzo será seleccionada. El conductor tendrá asegurada la independencia y autoridad para realizar las tareas de validación.

4- Un plan de validación será desarrollado y documentado. El plan incluirá, pero no se limitara a lo siguiente:



a. Items sujetos a validaciónb. Tareas de validación a ser realizadasc. Recursos, responsabilidades, y cronograma para la validaciónd. Procedimientos para entregar los reportes de validación al adquiriente y otras

partes.5- El plan de validación será implementado. Problemas y disconformidades detectadas por el

esfuerzo de validación serán ingresadas en el proceso de Resolución de problemas de software. Todos los problemas y no conformidades serán resueltas. Los resultados de las actividades de validación se harán disponibles al adquiriente y otras organizaciones involucradas.

ValidaciónConsiste en las siguientes tareas:

1- Preparación 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 específico pretendido.

3- Realizar los tests mencionados anteriormente, incluyendo:a. Testing con estrés, límites y entradas singularesb. Testear el producto de software por su habilidad de aislar y minimizar el efecto de

los errores, esto es, teniendo una elegante degradación en caso de fallas, requiriendo asistencia del operador en caso de estrés, límite 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 pretendido5- Testear el producto de software apropiadamente en áreas seleccionadas del ambiente de

destino.

Proceso Revisión del Software

PropósitoEl propósito del proceso de revisión del software es mantener un entendimiento común 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 técnico y tienen lugar a través de la vida del proyecto.



SalidasComo resultado de una exitosa implementación del proceso de revisión del software:

- El gerenciamiento y las revisiones técnicas son tomadas en base a las necesidades del proyecto.

- El estado y productos de las actividades de un proceso son evaluados a través de las actividades de revisión.

- Los resultados de la revisión son informados a todas las partes afectadas.- Los ítems de acción resultantes de las revisiones son seguidos hasta el cierre- Los riesgos y problemas son identificados y registrados

ActividadesEl proyecto deberá implementar las siguientes actividades de acuerdo con las políticas aplicables de la organización y procedimientos con respecto al proceso de Revisión de Software


1- Se realizarán revisiones periódicas en predeterminados hitos, según esté especificados en el plan del proyecto. Las partes interesadas deben determinar la necesidad para cualquier revisión ad hoc, en la cual las partes del acuerdo deberían participar.

2- Todos los recursos que son necesarios para realizar las revisiones serán proveídos. Estos recursos incluyen personal, locación, instalaciones, hardware, software, y herramientas.

3- Las partes que participan en una revisión deben acordar en los siguientes puntos para cada revisión: agenda de la reunión, productos de software, y problemas a ser revisados; alcance y procedimientos; y criterios de entrada y salida para la revisión.

4- Los problemas detectados durante las revisiones deben ser registrados e ingresados en el proceso de resolución de problemas de software según sea requerido.

5- Los resultados de la revisión deben ser documentados y distribuidos. Esta comunicación incluye idoneidad de la revisión (aprobación, desaprobación, aprobación con contingencias…) de los resultados de la revisión.

6- Las partes participantes deben acordar la salida de la revisión y cualquier responsabilidad de los ítem de acción y criterios de cierre

Revisiones de gestión de proyectoConsiste en las siguientes tareas:

1- El estado del proyecto debe ser evaluado en relación a los planes de proyecto aplicables, cronogramas, estándares, y directrices. La salida de la revisión debe ser considerada por la gerencia apropiada y debe proveer lo siguiente:



a. Realización del progreso de las actividades de acuerdo al plan, basado en una evaluación de la actividad del estado del producto de software.

b. Mantenimiento del control global del proyecto a través de una adecuada asignación de recursos.

c. Cambio de la dirección del proyecto o determinación 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 técnicasConsiste en las siguientes tareas:

1- Las revisiones técnicas deben tener lugar para evaluar los productos o servicios de software en consideración y proveer evidencia de que:

a. Están completosb. Cumplen con los estándares y especificacionesc. Los cambios están apropiadamente implementados y afectan sólo las áreas

identificadas por el proceso de Gestión de la configuraciónd. Adhieren a cronogramas aplicablese. Están listos para la próxima actividad planificadaf. El desarrollo, operación, o mantenimiento está siendo conducido de acuerdo a los

planes, cronogramas, estándares y directrices del proyecto.

Proceso Auditoría del Software

PropósitoEl propósito del proceso de auditoría del software es determinar, independientemente, la conformidad de productos y procesos seleccionados con los requerimientos, planes y acuerdos, según sea apropiado.

SalidasComo resultado de una exitosa implementación del proceso de Auditoría de software:

- Se desarrolla e implementa una estrategia de auditoría- 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 auditoría.

- Las auditorías son conducidas por un grupo apropiadamente independiente- Los problemas detectados durante la auditoría son identificados y comunicados a los

responsables de las acciones correctivas y resoluciones.



ActividadesEl proyecto deberá implementar las siguientes actividades de acuerdo con las políticas aplicables de la organización y procedimientos con respecto al proceso de Auditoría de Software


1- Auditorías deben ser realizadas en predeterminados hitos según 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 auditorías deben ser acordados por las partes. Estos recursos incluyen personal de soporte, ubicación, instalaciones, hardware, software, y herramientas.

4- Las partes deben acordar en los siguientes puntos en cada auditoría: agenda, productos de software (y resultados de la actividad) a ser revisados, alcance de la auditoría, y procedimientos, y criterios de entrada y salida de la auditoría.

5- Los problemas detectados durante las auditorías deben ser registrados e ingresados en el proceso de Resolución de problemas de software según sea requerido.

6- Después de completarse la auditoría, 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 auditoría y los planes relacionados para resolver el problema.

7- Las partes acordarán en la salida de la auditoría y cualquier responsabilidad sobre los puntos de acción y criterios de cierre.

Auditoría de SoftwareConsiste en las siguientes tareas:

1- Las auditorías de software deben ser realizadas para asegurar que:a. El modo en que están codificados, los productos de software reflejan la

documentación del diseñob. Los requerimientos de testing para la revisión de aceptación prescritos en la

documentación son adecuados para la aceptación de productos de softwarec. Los datos de las pruebas cumplen con la especificaciónd. 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 documentación de usuario cumple con los estándares 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.



IEEE 829 – 2008 – Estándar para Software y Documentación de Test de Sistemas25

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 están 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, precisión, consistencia, y testabilidad, y la documentación resultante que aplica.

El propósito 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 mínimas 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 documentación de test relacionada (Diseño de test, casos de test, procedimientos de test, reporte de anomalías, log de test, reporte de nivel de test, reporte provisional de test, y reporte maestro de test).

Objetivos de testingLos sistemas basados en software se componen de software, hardware, interfaces y operadores/usuarios.

Los procesos de test incluyen la consideración de interacciones con todos los otros componentes del sistema como medio ambiente, usuarios, hardware y otro software. Además 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, alcance de las tareas de testing, y debe seleccionar los documentos y tópicos de contenidos que son los más apropiados basados en esta información.

Los procesos de testing proveen una evaluación objetiva de los productos basados en software a través de cada ciclo de vida del proyecto además de proveer una evaluación objetiva del sistema al completarse cada iteración de desarrollo, todo el desarrollo y a través de las fases de operaciones

25 Vid. IEEE Standard for software and System Test Documentation, 2008, pp.-18-21



del ciclo. Esta evaluación demuestra si los requerimientos del software y del sistema están 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 detección y corrección de las anomalías de software y de sistema, proveer una temprana evaluación de la performance del software y del sistema, proveer información objetiva a la gerencia para determinar el riesgo de negocio de liberar el producto en el estado actual, e identificar áreas con grupos de anomalías en la funcionalidad.

El testing da soporte a los procesos primarios del ciclo de vida. Las actividades de testing son más efectivas cuando se realizan en paralelo con los procesos de desarrollo, no sólo al finalizar éste.

Este estándar puede ser utilizado de dos formas, con un flujo completo o con uno parcial.

El flujo completo comienza con el desarrollo o la utilización de un esquema de nivel de integridad; después se selecciona el nivel de integridad para el sistema basado en software que requiere documentación, cuanto más alto el nivel de integridad más rigurosa y extensa es la documentación requerida; luego se crea un inventario de todas las tareas de testing; el paso final de este inventario es la identificación 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 documentación de test más relevante según sus responsabilidades, otros pueden aun no tener o no querer la documentación completa de test. Los posibles contenidos para los distintos tipos de documentación de test son: documentos de plan, documento de diseño de test, descripción del caso de test, procedimientos para la ejecución de los casos de test.

Niveles de integridad de software y de sistemasUn 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 más 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. Podría llegar a haber elementos de software que no requirieran asignación a un nivel de integridad, debido a que su falla no tuviera consecuencias en la operación del sistema, en ese



caso se podría agregar un nivel de integridad cero, cubriendo las fallas que no tengan consecuencias.

Deberá haber una documentación de niveles de integridad o la decisión de no utilizar un esquema de niveles de integridad. Esto será asignado como resultado de los acuerdos entre todas las partes interesadas.

Niveles de integridadUn 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, evaluación de riesgos, nivel de seguridad, integridad de los datos, performance deseada, confiabilidad, calidad, costos, tamaño, y otras características particulares del software.

Este estándar uso el concepto de niveles de integridad para determinar las tareas de testing a ser realizadas mínimas recomendadas. Los procesos de test y la documentación resultante deben ser ajustados a los requerimientos y aplicaciones específicos del sistema a través de la selección de un nivel de integridad.

Como ejemplo este estándar trae un esquema de niveles de integridad de cuatro niveles, cuyas categorías son definidas basadas en la seriedad de las consecuencias de un comportamiento erróneo y en el potencial de mitigación. Cada nivel lleva asociada una palabra descriptiva:

Nivel 4: Catastrófico: el software debe ejecutarse bien o se producirán graves consecuencias, sin posible mitigación

Nivel 3: Critico: el software se debe ejecutar correctamente o el uso pretendido del sistema no será realizado causando serias consecuencias, es posible una mitigación parcial o completa.

Nivel 2: Marginal: el software se debe ejecutar correctamente o una función pretendida no será realizada, causando consecuencias menores, es posible una mitigación completa.

Nivel 1: Despreciable: el software se debe ejecutar correctamente o una función pretendida no será realizada causando consecuencias despreciables, la mitigación no es requerida.

El uso de un esquema de niveles de integridad es una “best practice” (mejor práctica) recomendada que facilita la selección de las tareas y actividades más apropiadas y de los documentos de test necesitados.

Procesos de testEsta norma sigue la estructura en el estándar IEEE/EIA 12207.0-1996 para describir los procesos: cada proceso tiene uno o más actividades de soporte que son ejecutadas por una o más tareas. Es



un método “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 estándar, los inputs y outputs determinan que documentación de test es necesaria.

El testing es un conjunto de actividades orientadas a verificar el código ejecutable. No obstante, desde otras gestiones se pueden invocar actividades de testing para adelantar e ir preparando el proceso, como por ejemplo Planificación del testing.

En nuestro trabajo hemos analizado la norma ISO/IEC 12207 del año 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 versión.

Los procesos soportados en este caso son:

Gerenciamiento

- Adquisición- Suministro- Desarrollo- Operación - Proceso de mantenimiento

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 realización y documentación de la tarea son proporcionales al nivel de integridad.

Proceso de GerenciamientoEl proceso de gerenciamiento de test incluye la preparación de los planes de ejecución de los procesos de test.

Una vez iniciada la implementación de los planes, ocurren las siguientes actividades:

Monitoreo del plan de ejecución Análisis de anomalías descubiertas durante la ejecución del plan Reporte de progreso de los procesos de prueba Evaluación 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 están completos

Actividad: gerenciamiento del testLa actividad de gerenciamiento del test monitorea y evalúa 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 según sea necesario basado en los cronogramas de proyecto actualizados, y estado de los desarrollos.

También coordina las actividades relacionadas con los resultados del test con el desarrollador, y otros procesos de soporte como aseguramiento de la calidad, gestión de la configuración, revisiones y auditorias.

A través del uso de métricas 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 integración, para realizar la oportuna notificación y resolución. 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.

Cuando sea necesario el gerente de testing identificará lecciones aprendidas y determinará si las tareas de testing deben ser reiteradas por alguna razón.

Las actividades mínimas recomendadas para gerenciamiento del test según sea apropiado para el nivel de integridad seleccionado son:

a. Generar el Plan de Test Maestro (MTP)b. Realizar revisiones de gerencia del esfuerzo de testc. Realizar revisiones de gerencia y revisión de soporte técnicod. Interfaces con los procesos organizacionales y de soportee. Identificar oportunidades de mejora de procesos, incluyendo lecciones aprendidas en la

realización del test.

Proceso de AdquisiciónEl proceso de adquisición comienza con la definición de las necesidades para adquirir un sistema, producto de software o servicio de software.

El proceso continua con la preparación y edición de un RFP (requerimiento de propuesta) y con la selección de un proveedor. Termina con el gerenciamiento del proceso de adquisición a través de la aceptación del sistema, producto o servicio de software. Las tareas de test son ejecutadas a través del proceso de adquisición para darle soporte. Las tareas van desde identificación de la documentación requerida del proveedor en el RFP y el contrato para la ejecución del test de aceptación.



Actividad: soporte de adquisiciónAl comienzo del proceso de adquisición descripto, la actividad de test realiza varias tareas que soportan el inicio del proyecto, especialmente el requerimiento de propuesta y preparación del contrato. Las tareas de test que dan soporte al balance del proceso de adquisición se describen en los procesos desde suministro hasta mantenimiento.

Los esfuerzos de test realizan, según sea apropiado para el nivel de integridad elegido, las siguientes tareas recomendadas como mínimo:

a. Alcance preliminar de los esfuerzos de testb. Planificación preliminar de la interfaz entre los esfuerzos de test y el proveedorc. Evaluación de los requerimientos del sistemad. Establecimiento del criterio del contrato para testing del proveedor.

Proceso de SuministroEl proceso de suministro se inicia sea por una decisión de preparar una propuesta para responder a un RFP de un adquiriente o mediante la firma y la creación de un contrato con el adquiriente para proveer el sistema basado en software, producto de software o servicio.

El proceso continua con la determinación de procedimientos y recursos necesarios para gerenciar el proyecto incluyendo la preparación del plan del proyecto, de la ejecución de los planes a través 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 planificación de las interfaces de test entre el proveedor y el adquiriente.

Actividad: planificación del testLos participantes en la actividad de planificación de test pueden participar en las actividades de iniciación del requerimiento de propuesta, preparación de la respuesta, planificación del contrato, ejecución y control, revisión y evaluación, y entrega y cierre.

El esfuerzo de test realiza de acuerdo con el nivel de integridad elegido, las siguientes tareas recomendadas como mínimo:

a. Se continúa la planificación de la interfaz entre el esfuerzo de test y el proveedor.b. Se continúa el alcance del esfuerzo de testc. Se identifican métricasd. Se identifica el nivel de integridad



Proceso de DesarrolloEl proceso de desarrollo consiste en las actividades y tareas del grupo de desarrollo. Cubre las actividades de desarrollo de análisis de requerimientos, diseño, codificación, integración de componentes, testing, instalación, y aceptación, 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 estándar están organizadas en las actividades del ciclo de vida de concepto, requerimientos, diseño, implementación, test e instalación/check out.

Los usuarios del estándar pueden necesitar ajustar estas actividades para reflejar las prácticas de sus organizaciones y trazar sus actividades a las definidas en este estándar.

Actividad: conceptoLa actividad de concepto representa la identificación de una implementación específica para resolver un problema de las partes interesadas o cubrir sus necesidades. Una arquitectura preliminar de sistema puede ser identificada y el análisis 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 según sea apropiado a los niveles de integridad, estas mínimas tareas recomendadas:

a. Revisión de la documentación de concepto para conocimientos del tester de las necesidades del usuario.

b. Revisión de los documentos de requerimientos del sistemac. Generación preliminar de la matriz de trazabilidad de pruebasd. Identificación el nivel de integridad

Actividad: requerimientosEn 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, documentación de usuario del sistema y del software, requerimientos de instalación y aceptación, requerimientos de operación y ejecución de los usuarios, y requerimientos de mantenimiento.



Durante esta actividad las actividades de testing participan en la verificación de los requerimientos de software.

El objetivo del esfuerzo de test en este caso es la verificación de los requerimientos de software, verificando la “testabilidad” y de los requerimientos asignados, así como también ayudando a identificar ambigüedades, poca claridad o requerimientos faltantes.

Durante esta actividad la planificación 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 mínimas recomendadas:

a. Generación del plan de pruebas de aceptaciónb. Generación del plan de pruebas de sistemac. Revisión de los requerimientos de software y de interfaces para pruebasd. Identificación actualizada del nivel de integridade. Generación de la matriz de trazabilidad de pruebas, actualizadaf. Identificación de riesgosg. Identificación de problemas de seguridad.

Actividad: diseñoEn la actividad de diseño los requerimientos del sistema son transformados en arquitectura y diseño detallado para cada componente de software.

El diseño incluye bases de datos e interfaces. Se crea el diseño de arquitectura del software y del sistema, y el diseño detallado del sistema. El objetivo del esfuerzo de test en este caso es continuar con la planificación de las pruebas.

El esfuerzo de test realiza de acuerdo con el nivel de integridad seleccionado las tareas mínimas recomendadas:

a. Generación del diseño de las pruebas de aceptaciónb. Generación del diseño de las pruebas de sistemac. Generación del plan de pruebas de integración de componentesd. Generación del diseño de pruebas de integración de componentese. Generación del plan de pruebas del componentef. Generación del diseño de pruebas del componenteg. Identificación actualizada del nivel de integridadh. Generación de la matriz de trazabilidad de pruebas, actualizadai. Identificación de riesgos - testj. Identificación de problemas de seguridad – test



Actividad: implementaciónEn la actividad de implementación el diseño es implementado y se genera el código, las estructuras de base de datos, y las representaciones de las ejecuciones relacionadas.

El diseño también puede ser implementado en personalizaciones o configuraciones de componentes o sistemas ya codificados. Esta actividad incluye creación o modificación de software y testing.

El objetivo de los esfuerzos de test en este caso es verificar que las implementaciones sean correctas, precisas, y completas.


a) Generación de casos de prueba de aceptaciónb) Generación de procedimientos de prueba de aceptaciónc) Generación de casos de prueba de sistemad) Generación de procedimientos de prueba de sistemae) Generación de casos de prueba de integración de componentesf) Generación de procedimientos de prueba de integración de componentesg) Generación de casos de prueba de componentesh) Generación de procedimientos de prueba de componentesi) Ejecución de pruebas de componentesj) Evaluación de los resultados de pruebas de componentesk) Preparación del reporte de pruebas de componentesl) Generación de la matriz de trazabilidad de pruebas, actualizadam) Realización de la revisión de preparación de pruebasn) Identificación actualizada del nivel de integridado) Identificación de riesgos - testp) Identificación de problemas de seguridad - test

Actividad: testEn la actividad de test propiamente dicha se cubre la integración de los componentes de software, pruebas de aceptación de software, integración del sistema, y pruebas de aceptación del sistema. El objetivo es verificar que los requerimientos de software y de sistema están satisfechos con la ejecución de las pruebas de integración de componentes, sistema y aceptación. Las versiones y releases del software son probados por progresión, es decir pruebas de características nuevas y corregidas; y por regresión, es decir pruebas para asegurar que no han ocurrido cambios indeseados.




a) Ejecución de pruebas de integración de componentesb) Evaluación de los resultados de las pruebas de integración de componentesc) Preparación del reporte de las pruebas de integración de componentesd) Ejecución de las pruebas de sistemae) Evaluación de los resultados de las pruebas de sistemaf) Preparación del reporte de las pruebas de sistemag) Ejecución delas pruebas de aceptaciónh) Evaluación de los resultados de las pruebas de aceptacióni) Preparación del reporte de las pruebas de aceptaciónj) Identificación de riesgosk) Identificación de problemas de seguridad

Actividad: instalación y check out

En la actividad de instalación/check out se abarca la instalación del sistema basado en software, el producto o servicio de software, en el ambiente de destino, y la revisión de aceptación y pruebas de producto del adquiriente.

El objetivo de los esfuerzos de test en este caso consiste en dar soporte a la instalación y aceptación del sistema instalado. El objetivo es verificar la correcta instalación del sistema en el ambiente de destino.


a) Soporte a las auditorías de instalación y configuración, físicas y funcionalesb) Realización de la instalaciónc) Evaluación de la instalaciónd) Preparación del reporte de instalacióne) Preparación del informe maestro de las pruebas, de ser requeridof) Identificación de riesgos - testg) Identificación de problemas de seguridad- test

Proceso de operaciónEl proceso de operación cubre la operación del producto de software y el soporte de operación a los usuarios. La actividad de operación realiza testing operacional, operación del sistema y soporte de usuarios.



Actividad: test operacionalLa 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 operación. La actividad de test operacional realiza el test operacional, operación 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 operación satisfacen los requerimientos de usuario y alcanzan las necesidades del negocio de la organización.


a. Evaluación de los procedimientos de operación b. Ejecución de test de operación c. Evaluación de los resultados del test de operación d. Preparación del reporte del test de operación e. Identificación de riesgos – testf. Identificación de problemas de seguridad – test

Proceso de mantenimientoEl proceso de mantenimiento se activa cuando el sistema basado en software o el producto de software sufren alguna modificación en el código y documentación asociada debido a algún problema, necesidad de mejora o adaptación.

La actividad de mantenimiento consiste en modificaciones, migración o retiro del sistema basado en software o producto de software durante el proceso de operación.

Las modificaciones serán tratadas como un proceso de desarrollo y serán verificadas según el proceso de gestión 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 operación cambiado o para responder a nuevos requerimientos de usuario o mejoras.

Actividad: test de mantenimientoLa actividad de mantenimiento cubre las modificaciones, migración, y retiro del sistema basado en software o producto de software.



Para la migración de software, que es el movimiento a un nuevo ambiente de operación, el esfuerzo de test verifica que el sistema migrado y el software alcancen los requerimientos de desarrollo y operación.

El retiro del software es la baja del soporte activo por la organización de operación y mantenimiento, parcial o total reemplazo por un nuevo sistema o instalación de un sistema actualizado.

Si el sistema fue desarrollado bajo este estándar, el mismo debe ser respetado en el proceso de mantenimiento, si no lo fue, y la documentación apropiada no está disponible o no es adecuada, entonces el esfuerzo de test debe recomendar la generación de los faltantes. Para esto se tendrán en cuenta los mínimos requerimientos asignados al nivel de integridad.

La actividad de mantenimiento realiza análisis de problemas y modificación, implementación de modificación, revisión y aceptación de mantenimiento, y retiro de sistema y software.

Los objetivos del esfuerzo de test son verificar y validar la modificación, migración o retiro de los requerimientos, y repetir las tareas de test del modo adecuado. Las versiones o releases del software son testeados para progresión (nuevas características) y regresión (que no haya cambios no deseados).


a. Revisión de todas la documentación de test afectadab. Realización de la evaluación de anomalíac. Test de iteración de tareas

Proceso de selección de contenido de la documentación de testLa norma IEEE 829 provee tópicos de contenidos de documentación a considerar para incluir en los diferentes documentos de testing. La lista siguiente está diseñada para incluir tantos tópicos de documentación de test como sea posible, proveyendo un set comprensivo:

- Plan maestro de test (MTP)- Plan de nivel de test (LTP)- Diseño 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 Anomalías (AR)- Reporte de estado interino de nivel de test (LITSR)- Reporte de nivel de test (LTR)



- Reporte maestro de test (MTR)

Los usuarios de la norma pueden elegir agregar, combinar o eliminar todos los documentos o tópicos de contenidos de documentación basados en las necesidades (y nivel de integridad) de sus sistemas individuales.

Cuando el contenido de la documentación 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 tópicos de contenido que no son utilizados. Puede ser deseable para esquemas modificados proveer una lista de las referencias que cubren los tópicos de contenido eliminados.

Un enfoque sugerido para adaptar la información provista a una circunstancia específica incluye consideraciones de:

a. Proveer una referencia a la información documentada en otro lugarb. Eliminar los tópicos de contenido cubiertos por el procesoc. Eliminar los tópicos de contenido cubiertos por herramientas automatizadasd. Combinación o eliminación de documentose. Combinación o eliminación de tópicos de contenido de documentos

Plan maestro de testEl propósito del plan maestro de test es proveer un documento total de plan de test y gestión de test para múltiples niveles, ya sea en un proyecto o a través de múltiples proyectos.

En vista de los requerimientos de software y de la planificación del aseguramiento de la calidad del proyecto, el plan maestro de test como actividad comprende la selección de los elementos constitutivos del esfuerzo de la prueba del proyecto: estableciendo los objetivos de cada parte, la división del trabajo y las interrelaciones entre las partes: identificando riesgos, asunciones, y estándares 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 planificación de aseguramiento de la calidad. Identifica el esquema de nivel de integridad y el nivel de integridad seleccionado, el número de niveles de test, el total de las tareas a ser realizadas, y los requerimientos de documentación.

MTP: introducción Introduce las secciones siguientes subordinadas, identifica el documento y lo ubica en el contexto de ciclo de vida específico del proyecto. El esfuerzo de test completo es descripto, incluyendo las organizaciones de test, el cronograma, es esquema de integridad.

Un resumen de los recursos requeridos, recursos, responsabilidades, y herramientas y técnicas pueden también ser incluidos en esta sección.



Identificador del documento

Se identificará la versión documento de forma única incluyendo información tal como la fecha del problema, organización, autores, firmas de aprobación, estado, versión, puede incluir también revisores y gerentes.

Alcance

Describe el propósito, goles y alcance del esfuerzo de pruebas del sistema o software. Incluye la descripción de cualquier adaptación del estándar que ha sido implementado. Se identifica el proyecto para el cual el plan se está escribiendo y los procesos específicos y productos cubiertos por el esfuerzo de test. Se describen las inclusiones, exclusiones, asunciones, limitaciones.

Es importante definir claramente los límites del esfuerzo de test para cualquier plan de test. Está implícito que las tareas de test reflejaran el enfoque global y la metodología de desarrollo. La documentación 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.

Visión de conjunto del sistema y características clave

Describe la misión o propósito de negocio del sistema o software que se está testeando. Se describen las características principales del sistema o software en test.

Visión de conjunto del test

Se describe la organización de test, el cronograma, el esquema de nivel de integridad, los recursos, las responsabilidades, herramientas, técnicas, y métodos necesarios para realizar el testing.

MTP: Detalles del plan maestro de testIntroduce las secciones siguientes subordinadas, describe los procesos de test, los requerimientos de documentación de test, y los requerimientos de reporte de test para todo el esfuerzo de test.

Procesos de test incluyendo definición de niveles de test

Se identifican las actividades y tareas a ser realizadas para cada proceso de test y se documentan. Se provee una visión general de las actividades de test y tareas para todos los procesos del ciclo de vida del desarrollo, se identifica el número y secuencia de los niveles de test, podría haber un



número diferente de niveles, respecto de los provistos en el estándar. La integración es frecuentemente llevada a cabo a través de una serie de niveles de test, tanto para integración de componentes y de sistemas.

Procesos del ciclo de vida

Se describe como todos los requerimientos del estándar son satisfechos si el ciclo de vida utilizado en el MTP es diferente del modelo del estándar. Testing requiere una planificación 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 métodos 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 documentación de test

Se define el propósito, el formato, y contenido de todos los otros documentos de se van a utilizar. Si el esfuerzo de test utiliza documentación de test o niveles de test diferentes a los del estándar, esta sección necesita mapear la documentación y requerimientos del proceso con el contenido de la documentación de test definidos en este estándar.

Requerimientos de administración de test

Se describe la resolución de anomalía y el proceso de reporting, la política de iteración de tareas, política de desviación, procedimientos de control y estándares, prácticas y convenciones.

Estas actividades son necesitadas para administrar las pruebas durante la ejecución.

Requerimientos de reportes de test

Especifica el propósito, contenido, formato, destinatarios, y tiempos de todos los reportes de test, Los reportes de test consisten en Logs de test, Reportes de anomalías, Reportes de estado interino de nivel de test, Reportes de nivel de test, y Reporte maestro de Test. También pueden incluir reportes opcionales definidos por el usuario de la norma. El formato y agrupación de estos es definido por el usuario y varía de acuerdo con la materia.



MTP: GeneralIntroduce las secciones subsiguientes. Esta sección incluye el glosario de términos y acrónimos.

También describe la frecuencia y el proceso por el cual el MTP es cambiado creada su línea de base.

También puede contener una página de cambios, con el historial de todos los cambios, fecha, razón, y quien lo realizó.

Plan de nivel de testEn 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, características, las tareas a ser realizadas, el personal responsable por cada tarea, y los riesgos asociados. En el título del plan la palabra “nivel” es reemplazada por el nombre que la organización le da al nivel particular que está siendo documentado (ej.: plan de test de componentes, plan de test de sistema, etc…).

En la mayoría de los proyectos hay niveles diferentes de test, requiriendo diferentes recursos, métodos 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 calificación de software para todos los requerimientos- Integración de sistema: agregados de otros ítems de configuración de software, hardware,

operaciones manuales, y otros sistemas. No es inusual para sistemas grandes tener múltiples niveles de integración de test.

- Test de calificación de sistema para requerimientos de sistema.

LTP: introducción Introduce las secciones subordinadas siguientes. En esta sección se identifica el documento y se lo pone en contexto del esfuerzo de test y del ciclo de vida específico del proyecto. Esta sección también identifica los tipos de test y las condiciones para los niveles específicos de testing.

Identificador 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 características a ser testeadas en este nivel en particular. La necesidad de cada ítem y su historia debe ser incluida. Esta sección puede ser una referencia a partes del MTP, una adición 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 jerarquía o secuencia de test. Esto se muestra mejor a través de una ilustración. Puede ser combinado con la sección 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 componenteb. Cada nivel de test de integración podría tener un inventario de las interfaces a ejecutarc. El test de sistema enfocara en alcanzar los requerimientos de sistemad. El test de aceptación enfocara en los atributos de aptitud de utilización

LTP: detalles para este nivel de plan de testIntroduce las secciones subsiguientes subordinadas. Describe los ítems específicos 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 sección el enfoque es descripto a lo largo de los criterios de pasa/falla y suspensión/reanudación, y los entregables de test son identificados.

Items de test y sus identificadores

Identifica los ítems de test que son objeto de test, como por ejemplo atributos específicos del software, instrucciones de instalación, instrucciones de usuario, hardware interconectado, software de conversión de base de datos que no es parte del sistema operacional; incluyendo su nivel de versión o revisión. También se identifican procedimientos para transferencia de otros ambientes al ambiente de test.

También proporciona referencias a la documentación de los ítems de test relevantes a un nivel de test individual, si existen, tales como requerimientos, diseño, guía de usuario, guía de operación, guía de instalación.



Referencia cualquier reporte de anomalía relacionado con los ítems de test, e identifica cualquier ítem que debe ser específicamente 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 más altos de test, o estándares de codificación o diseño para los niveles más bajos.

Esta matriz puede ser parte de una matriz de trazabilidad de requerimientos (RTM) más amplia referenciada por este plan que incluye requerimientos de todos los niveles de test y traza múltiples niveles del ciclo de vida de documentación de productos. Puede incluir trazabilidad tanto hacia adelante como hacia atrás.

Características a ser testeadas

Identifica todos los productos de software o características de sistema basadas en software y combinaciones de software o características de sistema a ser testeadas.

Características a no ser testeadas

Se identifican todas las características y combinaciones de características significantes conocidas que no serán testeadas y las razones para su exclusión.

Enfoque

Describe el enfoque general para el nivel de testing. Para cada característica principal o grupo de características, se especifica el enfoque se asegurara que están adecuadamente testeados. El enfoque puede ser descripto con suficiente detalle como para permitir la identificación de las principales tareas de testing y la estimación del tiempo requerido para cada una.

Las características a ser testeadas, las características 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 identificación de uno o más métodos genéricos de test, como por ejemplo caja negra, caja blanca, análisis o inspección.



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 número de anomalías encontradas en una categoría especifica de severidad.

Criterios de suspensión y requerimientos de resumen

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 información que será entregada por esta actividad de test. Los siguientes documentos pueden ser entregados: Plan de nivel de test, Diseño de nivel de test, Casos de nivel de test; Procedimientos de nivel de test, Log de nivel de test; Reportes de anomalía, 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 también pueden ser incluidas

Se describe el proceso de entrega de la información completa a los individuos y entidades organizativas que lo precisaran. Este documento puede ser una referencia al Plan de gestión de la configuración.

Esta descripción de entrega no es necesaria de estar previamente cubierta en el MTP y no ha habido cambios

LTP Gestión del testIntroduce las subsiguientes secciones subordinadas. Esta sección 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 más alto, como por ejemplo MTP.

Actividades y tareas planificadas, progresión del test

Se identifican un set de tareas necesarias para preparar y realizar el testing. Se identifican todas las dependencias entre tareas, cualquier restricción significativa tales como disponibilidad del ítem de



test, recursos de test, y fechas límite. Puede ser deseable combinar todos los tópicos contenidos en la documentación relacionados con los recursos en una sola sección.

Medio ambiente – infraestructura

Se especifican las propiedades tanto necesitadas como deseadas del ambiente de test y cualquier otro dato relevante de test. Esto puede incluir las características físicas 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 configuración antes del testing, ejecución durante el testing, y cualquier otra actividad posterior al testing. También 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 tópicos 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, diseñar, preparar, ejecutar, presenciar, y chequear resultados de este nivel de testing, y para resolver las anomalías encontradas. Además 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 operación, representantes de los usuarios, soporte técnico, 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 comunicación ente los individuos y los grupos identificados.

Recursos y su asignación

Delinea cualquier recurso adicional requerido que no haya ya sido documentado por otras partes del plan. Incluye tanto recursos internos como externos.



Entrenamiento

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 también todos los ítems de test de eventos de transmisión.

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 terminación 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 liberación de la primera versión del documento pueden cambiar cuando continúa el proyecto, pueden ser seguidos en un documento separado que no está bajo control de aprobación.

General

Introduce las secciones siguientes subordinadas. Describe los procedimientos y métricas de QA y contiene el glosario y la descripción de la frecuencia y procesos por los cuales es revisado el documento y creada una nueva línea de base.

También puede contener una página 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 anomalías y procedimientos de resolución. La información de aseguramiento de la calidad puede ser descripta en el Plan de aseguramiento de la calidad, o Procedimiento estándar, que pueden ser referenciados.



Métricas

Se identifican las medidas específicas que van a ser recolectadas, analizadas y reportadas. Las métricas 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 documentación en un programa genérico de medidas.

Cobertura del test

Especifica los requerimientos para cobertura del test. Es una indicación 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 varía de acuerdo al nivel de test. Por ejemplo en la cobertura de test de unidad se expresa frecuentemente en términos de porcentaje de código testeado y la validación de cobertura de test de software o sistema puede ser un porcentaje de los requerimientos testeados. Hay una necesidad de especificación de cobertura u otros métodos 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

Diseño de nivel de testEl propósito del diseño de nivel de test es especificar cualquier refinamiento del enfoque de test e identificar las características a ser testeadas por este diseño y sus tests asociados.

Introducción



Identifica la organización emisora, y los detalles de emisión. Incluye las aprobaciones requeridas y el estado (BORRADOR/ORIGINAL) del documento. Es acá donde el alcance es descripto e identificadas las referencias.

Detalles del diseño de nivel de test

Se describen las características a ser testeadas y cualquier refinamiento al enfoque de test según sea requerido por el nivel. También identifica los conjuntos de casos de test o escenarios con criterios de PASO/FALLA. Puede también incluir entregables de test.

General

Esta sección incluye el glosario y los procedimientos de cambio e historial del documento.

Casos de test de nivel. (LTC)El propósito del LTC es definir en un nivel de detalle apropiado la información 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.

Introducción

La identificación 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 través de internet.

La notación por descripción define cualquier esquema de numeración, por ejemplo escenarios y casos de prueba. En esta sección se explica cualquiera de estos esquemas.

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 características y configuraciones de hardware y software, y cualquier procedimiento especial. También se identifican las dependencias entre los diferentes casos de prueba.



General

Esta sección 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 testEl propósito del procedimiento de nivel de test es especificar los pasos para ejecutar un conjunto de casos de prueba o, más genéricamente, los pasos utilizados para ejercitar un producto de software o un ítem de sistema basado en software, en orden a evaluar un conjunto de características.

También describe las relaciones con otros procedimientos necesarios antes, durante o después de este.

En la sección de detalle presenta una descripción ordenada de los pasos a ser tomados por cada participante. Para cada procedimiento, de ser aplicable, y en diferentes grados según sea necesario, se incluirán: log, configuración, comienzo, procedimiento, medidas, apagado, reinicio, paro, conclusión, contingencias.

La sección general, como los documentos anteriores, incluirá un glosario, y un historial de cambios y procedimientos.

Log de nivel de testEl propósito del LTL es proveer un registro cronológico de los detalles relevantes sobre la ejecución de los tests. Una herramienta automatizada puede capturar todas o parte de esta información.

La introducción contendrá la identificación del documento, el alcance y las referencias, en forma similar a los documentos ya analizados.

La sección de detalle incluirá el log de test, especialmente la información referente a cada entrada. Contendrá información que aplica a todas las entradas en el log, de identificación, un registro de las actividades y eventos, una descripción de la ejecución, los resultados del procedimiento e información del ambiente. Se registraran los eventos anómalos con sus identificaciones.

La sección general contendrá un glosario.



Reporte de anomalía (AR)El propósito del AR es documentar cualquier evento que ocurre durante el proceso de testing que requiere investigación. Eso puede ser llamado problema, incidente, defecto, issue, anomalía o reporte de error.

La introducción incluirá un título para el AR si se desea, la identificación del documento, el alcance y las referencias, en forma similar a los documentos ya analizados.

La sección 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 anomalía, el software o ítem de software, o proceso en el cual se observó la anomalía. Se identifican los ítems de test involucrados indicando su versión. Se agregara una descripción de la anomalía, entradas, resultados esperados, salidas inesperadas, pasos del procedimiento y ambiente.

También será registrado el impacto que la anomalía tendrá en lo técnico y en el negocio, se identificara la existencia de alternativas de solución, y se podría incluir una estimación del tiempo, esfuerzo y riesgo de solucionar el defecto. Se proveerá una evaluación de la necesidad de una reparación inmediata.

Se agregara una descripción de la acción correctiva tomada para resolver la anomalía reportada, y el estado actual de la anomalía, sea abierta, aprobada para resolución, asignada a resolución, arreglada, y re testeada con el arreglo confirmado.

Se especificarán las recomendaciones para cambio al desarrollo y el proceso de testing y documentación que puede ayudar a prevenir este tipo de anomalías en el futuro.

La sección general contendrá como en documentos anteriores la historia de los procedimientos de cambios.

Reporte interino de estado de nivel de testEl propósito 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 título del documento por el nombre del nivel de test dado por la organización, como por ejemplo “reporte de estado interino de aceptación de test.

Contendrá una introducción 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 métricas.

La parte general será semejante a los documentos anteriores y contendrá un historial de los procedimientos de cambio.



Reporte de nivel de testEl propósito 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 título del documento por el nombre del nivel de test dado por la organización.

La introducción 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 anomalías resultas y las resoluciones, las razones de todas las decisiones, y las conclusiones finales y recomendaciones.

La sección general contendrá el glosario y la historia de los procedimientos de cambio como en los casos anteriores.

Reporte maestro de test (MTR)El propósito 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 organización, 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 implementación de MTP.

La introducción, como en los casos anteriores, contendrá el identificador del documento, el alcance, las referencias.

La sección de detalle describe una visión general de los resultados de test agregados: resumen de las actividades de test, de los resultados de las tareas de testing, anomalías y resoluciones, evaluación de la calidad y resumen final de métricas recogidas. También incluirá las razones de las decisiones, y las conclusiones finales y recomendaciones, con una evaluación final del software y puede agregar una estimación de riesgos de fallas.

Se pueden describir lecciones aprendidas y cambios que fueron descubiertos durante la ejecución del test. Puede incluir mejoras de proceso, identificadas e incorporadas durante la implementación del MTP.

La sección general como en los casos anteriores incorporará un glosario e historial de procedimientos de cambio.



UML UML es ampliamente independiente del proceso, es decir, no está atado a ningún ciclo de vida de software particular. Sin embargo, para obtener los mayores beneficios de UML se debería 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 aquél que envuelve la gestión y el flujo de los releases ejecutables. Un proceso incremental es aquel que envuelve la continua integración 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 más 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 están completos y las decisiones están hechas, para moverse a la fase siguiente

Hay cuatro fases en el ciclo de vida de desarrollo: comienzo, construcción y transición. Dentro de cada una de estas fases hay un número de iteraciones, las cuales representan un ciclo completo de desarrollo, desde la captura de requerimientos en análisis, hasta la implementación y testing, que resulta en la liberación de un proyecto ejecutable.26

26 Vid Rumbaug, Jacobson, Booch, The Unified Modeling Language User Guide, Addison-Wesley, 1998, pp. 38 y ss.



UML y los modelosUML 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 representación, 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 semántica y notación, y puede tomar varias formas que incluyen tanto imágenes como texto: el modelo trata de ser de uso más sencillo para ciertos propósitos que el sistema final.27

En UML cada modelo está focalizado en un aspecto específico del sistema:

- Modelos de requerimientos- Modelo de análisis- Modelo de diseño- Modelo de implementación

27 Vid Rumbaug, Jacobson, Booch, The unified modeling language reference manual, Addison-Wesley, 1999, p. 13 y ss



- Modelo de pruebas

El modelo de test de UMLEl modelo de pruebas tiene como objetivo la verificación del sistema. Principalmente envuelve la documentación 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.

También tiene como resultado el plan de test, evaluaciones de los test realizados, y defectos que pueden retroalimentar a otros procesos, tales como diseño e implementación.28

En este modelo, los niveles más bajos, como módulos y bloques, son probados primero. La integración no viene en un modelo “big bang” sino que estas pruebas son introducidas en diferentes niveles al integrar partes cada vez más grandes.

Una forma de realizar la integración 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 también nuevos problemas.

Un problema adicional surge con la herencia entre clases: se requieren pruebas más exhaustivas para determinar que una operación es válida en todos los niveles y no solo en el cual está siendo probado. Una operación 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 función deberá ser probada múltiples veces según 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 varían considerablemente de cualquier otro sistema.

Como ya hemos visto, las actividades clásicas de testing están divididas normalmente en verificación y validación.

La validación generalmente se obtiene con una activa participación de los clientes, muestras de prototipos y demás. El concepto de casos de uso ha resultado particularmente beneficioso para las tareas de validación, como complemento, no como reemplazo de las tareas habituales de

28 Vid, Jacobson, Booch, Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999, p. 313



testing como revisiones e inspecciones de código, que contribuyen a la obtención de un código de alta calidad.

Las actividades de testing llevan aproximadamente un 30% del costo completo del desarrollo, pero podrían llegar a llevar más 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 iteración.

Para los tests se tendrán en cuenta dos métricas 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 código que ha sido testeado, y la confiabilidad, la cual se basa en el análisis de tendencias en los defectos encontrados, y en las pruebas que se ejecutan con un resultado esperado. Para esto se crean diagramas que analizarán 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 dramático 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 más extensas que las tradicionales: los test de integración se realizan así en una etapa temprana, ya que la comunicación 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 también que los objetos se comuniquen correctamente entre sí, en ese caso de prueba particular. También se chequean así las interfaces descriptas en el modelo de requerimientos. 30

La calidad debe ser incorporada al producto desde el principio, el propósito de las pruebas finales es solamente certificar la calidad del producto, por eso se las llama a veces “certificación”, para distinguirlas de otras tareas de calidad. Las actividades de testing pueden ser hechas tanto en los documentos de análisis y de diseño, siendo verificados por medio de revisiones, para asegurar que fueron creados apropiadamente, y así eliminar las fallas lo más pronto posible.

Al testear rigurosa y continuamente todos los modelos, se obtiene finalmente un nivel mucho más alto de confianza en que el sistema modelado se comportará como es esperado en el mundo real.

La noción 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.

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



El testear continuamente cada elemento contra sus casos de uso, se valida continuamente su implementación. No solo estos casos de uso proveen una fuente de test de regresión, sino que cada vez que se agrega un caso de uso a un elemento, se fuerza reconsiderar la implementación 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.



TEST MANGERDentro de las herramientas de test comentaremos, basado en la investigación de Carolina Oberst en su trabajo de grado, el funcionamiento del Test Manager.

Que es el test managerEl test manager es una consola central para administración, ejecución y generación de reportes durante la etapa de testing.

Trabaja asociado a un proyecto Rational.

Soporta desde pruebas manuales hasta diferentes paradigmas de pruebas automáticas, incluyendo test de unidad, de regresión funcional, performance, etc. Además integra el testing con el resto de las actividades del ciclo de vida del proyecto, y permite mantener relaciones a través de los “artifacts” de todas las fases del ciclo, permitiendo así la rápida detección 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 Análisis, las cuales comentaremos a continuación.



Actividades del Test Manager

PlanningLa 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

Identificar y recolectar las entradas del test

Lo primero en la planificación es crear una lista con todo lo que es necesario probar, sean versiones, prototipos, requerimientos, código fuente, etc. Todo esto es llamado “test input”, el Test Manager provee algunos tipos de Test Input, pero también 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 información 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 jerárquicamente los Test Cases. Dentro de cada una de ellas se puede crear una nueva carpeta o un Test Case.

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 cuáles 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 dueño que deber ser miembro del equipo, el cual será responsable de llevar a cabo la ejecución de ese Test Case en particular.

Definir configuraciones e iteraciones

Las iteraciones se utilizan para especificar cuándo un Test Case se debe aprobar, es un lapso de tiempo durante un proyecto, el fin de la iteración 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.

Diseño e implementación

La actividad de Planning en Test manager abarca otras dos actividades de proceso de Testing: Diseño e Implementación.

Una vez definido que es lo que se va a testear, hay que definir cómo realizar el testing. Esta pregunta es respondida por la actividad de Diseño.

El diseño 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 implementación de los requerimientos, y además al haber un cambio en los requerimientos ésto se debe reflejar en el Test Case.

El diseño debe tener definido cuáles son las precondiciones, post condiciones y cuál es el criterio de aprobación.

Una vez diseñado 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 aplicación para asegurar que todos los botones, y menús funcionan correctamente, o para testear las actividades que la aplicación realiza detrás de la interfaz de usuario.

En Test Manager los Test Scripts se encuentran ordenados por tipo, permite implementar los test cases con implementación Manual, Automática o como Suites.



ExecutionCorrer o ejecutar un test case significa correr la implementación 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 Automáticos, Test Scripts Manuales, Test cases o Suites.

Suites son otra manera de implementar los Tests en Test Manager, muestran una representación jerárquica 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 cuántas veces debe correr cada Test Script. Se pueden utilizar tanto para tests de performance como funcionales.

En esta etapa también se administran las configuraciones, para que los Test Cases corran automáticamente en computadoras que cumple con cierta configuración de software y hardware. Esto es para asegurarse que los Test Cases funcionen correctamente en algún sistema operativo en especial, o browser, etc. También se podría 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- Liberar Testers Virtuales que se encuentren esperando en los puntos de sincronización

Las herramientas de monitoreo proveen información actual y actualizada dinámicamente durante la ejecución del test. Esta información incluye: el número de comandos ejecutados correctamente y el número de comandos fallidos; el estado general de los testers virtuales, si se están iniciando, conectando a una base de datos, finalizando, o haciendo otra tarea; si alguno de los testes virtuales termino en forma anormal.

Results and analysisLa evaluación de los tests involucra: determinar la validez de la ejecución; 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 automáticamente y marca los test cases asociados como “sospechosos”.

Los Test Logs son generados automáticamente por Test Manager cuando se ejecuta una Suite.



ROBOTLa segunda herramienta que comentaremos es Robot, nos basaremos en la investigación de Max Garay en su trabajo de grado.

Que es RobotRobot es una herramienta que forma parte del Rational Toolkit. Es un conjunto de componentes para la automatización de testing de aplicaciones de tipo cliente/servidor, así como también 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 sesión son para el testing de performance.

Utilización de Robot con otros productos RationalRobot se utiliza en conjunto con otras herramientas:

Rational Test Manager: maneja las actividades de testing: planeamiento, diseño, implementación, ejecución y análisis

Rational Test Factory: genera automáticamente scripts de acuerdo con la estructura navegable de la aplicación

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 aplicación en C/C++ asegurando que el código sea confiable así como también errores en los accesos a memoria.

Rational Quantify: Provee un análisis de performance en la aplicación, encontrando los cuellos de botella de la misma.

Rational Pure Coverage: Se ocupa de cubrir el código que se ejecutara, para evitar el que código no testeado sea ejecutado por el usuario final.

Rational Requisite Pro: Ayuda a controlar el proceso de desarrollo mediante la definición de los requerimientos

Rational Robot J: Se concentra en testear HTML y aplicaciones Java de escritorio o Java web.



Funcionamiento de RobotRational 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 interactúa con la GUI de la aplicación en cuestión. El método que se utiliza para testear es el de la comparación: tiene una línea de base que representa lo que se espera, y se ingresan puntos de verificación en la aplicación. 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)

ScriptsPara comenzar a crear scripts es necesario tener un contenedor para guardarlo. El ejecutar la aplicación el usuario comienza a grabar un script, con las acciones sobre la aplicación. Luego, al ejecutar el script, las acciones corren automáticamente como si lo estuviera haciendo nuevamente. De esta manera se puede ver cómo responde el sistema.

Verification PointsProveen un baseline de las propiedades o datos de un objeto: si un punto de verificación 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 MapsEl RobotJ Recorder va guardando los objetos que actúan durante una sesión de grabación, estos objetos se agrupan en “Test Object Maps”, el cual lleva registro de todos los aspectos de un objeto. A su vez también hay una sección donde se guardan los Verification Points.

GUI ScriptsCuando se graba un GUI script, Robot graba las acciones del usuario (teclas oprimidas, clics, etc…), y los puntos de verificación.



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 fácilmente o ubicar cambios con facilidad, y que sean fáciles de depurar.

Aplicaciones para TestingRobot 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 rígido las librerías de Java. Para aplicaciones HTML, mientras se graba o edita un script, se utiliza el botón “Start Browser” para arrancar el Internet Explorer o el Netscape según como esté configurado.

Mapeo de objetos conocidos y no conocidosRobot reconoce los objetos gráficos estándar de Windows, ya que tiene un mapeo para distintos lenguajes que se utilicen: Java, Delphi, Visual Basic, etc. Puede ocurrir durante una grabación que se cliquee sobre un objetos que Robot no reconozca. En este caso Robot actúa según se haya configurado: se puede mapear el objeto desconocido a un objeto genérico o a un objeto conocido. Esto evita que al momento de la ejecución aparezcan objetos que no sean conocidos.

Puntos de verificaciónLos puntos de verificación, sin puntos en un script que se crean para confirmar el estado de un objeto. Durante el período de grabación, el punto de verificación captura información acerca del objeto y lo guarda como línea de base. Durante la ejecución, el punto de verificación recaptura la información y la compara. Si el objeto no coincide con la información guardada, Robot crea un archivo de datos reales, con la información real de objeto. Luego de la ejecución del script, los resultados de cada punto de verificación aparecen el en log de Test Manager. Si un punto de verificación falla, se puede entonces ver por medio de comparadores los datos de la línea de base y los reales, para así determinar si las diferencias son intencionales o no.

Un punto de verificación se guarda en el proyecto y siempre está asociado a un script.

TimersRobot permite insertar Timers de dos tipos, los que arrancan y los que frenan. Sirven para grabar y escribir al archivo de log la duración 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 aplicación- Medir la performance de tareas específicas

Para ejecutar un script que incluye timers conviene configurar una opción de Robot para remover cualquier tiempo extra que Robot pueda tomarse y que pueda retrasar la aplicación.

Comentarios y mensajes de LogDurante la grabación o edición de GUI scripts se pueden agregar comentarios, los cuales son útiles para documentar. Al momento de compilación Robot ignora los comentarios.

También se pueden agregar mensajes de Log, descripciones y resultados en los GUI scripts. Durante la ejecución Robot inserta esta información en el log, la cual se puede utilizar para documentar el script en el proceso de ejecución.

Selección del objeto a testearHay dos maneras de seleccionar el objeto a testear: apuntarlo en la aplicación, 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 verificación.

Selección de métodos de verificaciónCuando se crean algunos puntos de verificación se puede seleccionar el método de verificación, el cual especifica cómo Robot compara los datos de la línea de base capturados durante la grabación con los datos capturados durante la ejecución. Esto se configura cuando se selecciona el punto de verificación que posee estas propiedades.

Los posibles métodos 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.

Selección de métodos de identificaciónUn método de identificación le dice a Robot cómo identificar los valores a comparar durante la grabación y ejecución. Por ejemplo si se tienen que testear los valores de una fila en una tabla se puede especificar un método de identificación para que Robot identifique los valores a pesar de la ubicación de la fila en la tabla.

Cuando se crean ciertos puntos de verificación, se pueden seleccionar métodos de identificación para datos que aparecen en una grilla de datos.



Hay cuatro métodos de identificación: por contenido, por ubicación, por título, o por clave/valor.

Scripts manualesA pesar de que es más fácil y más rápido generar automáticamente los scripts con Robot, se pueden codificar manualmente usando el lenguaje de scripts SQABasic, siendo el mismo Robot el que provee ésta opción.

Shell scriptsUn 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 análisis de los resultados.

Editar, compilar y depurar ScriptsSe puede querer editar un script para cambiar algún comando o algún argumento, o inclusive agregar lógica 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 compilación, se muestran los resultados de la compilación y los mensajes de error con el número de línea.

Robot incluye un entorno de depuración para ayudar durante el desarrollo de los GUI scripts, pero no tiene entorno de depuración para los VU scripts. Antes de comenzar a depurar se debe tener un script abierto. Cuando la ejecución de la depuración 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 próximo. Sólo se puede ubicar un breakpoint en líneas donde haya un comando SQABasic, no en comentarios, etiquetas o líneas en blanco.

Ejecución de GUI ScriptsLas fases de ejecución son dos: fase de desarrollo del test y fase de test de regresión.

Cualquier aplicación y ventana que estaba abierta, activa o desplegada al momento de la grabación, debería estar abierta, activa o desplegada cuando se comienza la ejecución, de lo contrario el script fallará. Además debe asegurarse que cualquier configuración de propiedades de red o base de datos deben estar en el mismo estado que cuando se grabó el script.



Fase de desarrollo del testDurante esta fase se ejecutan los scripts para verificar que funcionan como se pretende, usando la misma versión de la aplicación bajo testing que se utilizó para grabar los scripts. Esto valida la línea de base, que es el comportamiento esperado de la aplicación.

Fase de test de regresiónDurante esta fase se ejecutan scripts para comparar la última versión de la aplicación bajo test con la línea de base establecida durante la etapa de desarrollo del test. El test de regresión muestra cualquier diferencia que pueda haber sido introducida en la aplicación desde la última versión. Se pueden evaluar las diferencias para determinar si son defectos o cambios voluntarios.

Grabación de sesionesUna sesión 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 grabación. Estas grabaciones generan scripts de test que se guardan en un archivos de sesión.

En una sesión múltiple se pueden grabar: múltiples transacciones, transacciones contra el mismo servidor o contra distintos servidores, diferentes tipos de consultas.

Los archivos de sesión son guardados por default en el directorio TMS_Scripts del datastore del proyecto.

Al trabajar con sesiones se puede: dividir la sesión en múltiples scripts, regenerar los scripts de la sesión o ver las propiedades de la sesión.

Grabación APICon éste método Robot graba las llamadas de API entre la aplicación cliente y el servidor. La grabación se realiza en el cliente, como ocurre con los métodos Network y Proxy.

Es recomendable utilizar este método si se accede a daros seguros de un servidor Web y a que captura la información antes de que llegue al cable y sea encriptada.

La grabación 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 métodos Network y Proxy.



Grabación NetworkCon este método Robot graba el tráfico a niel de paquetes en la capa OSI utilizando el modo de la tarjeta de red. La grabación Network soporta estándares cómo Ethernet, Token Ring, t FDDI (Fiber Distributed Data Interface). En este método, a diferencia del API, la grabación ocurre en el cable y no en el cliente.

Grabación ProxyCon este método, el tráfico cliente-servidor es ruteado vía una computadora Proxy. La grabación de proxy ocurre en la capa OSI de la aplicación. Se pueden grabar conversaciones entre múltiples clientes y servidores. Ninguna de las computadoras cliente que envía consultas debe tener Robot instalado, solo debe estar instalado en las computadoras Proxy.

Grabación customPara que este método funcione es necesario que un adaptador de grabación custom y un adaptador generador de custom scripts estén instalados y configurados.

La GrabaciónInformación de autenticación

Si se corre un test contra una base de datos que requiere un ID de usuario y una contraseña, se debe proveer esta información cuando se graba el script y cuando se ejecuta también. Durante la grabación Robot detecta el ID de usuario y si hay otra información del usuario, guarda esta información, pero no la contraseña. Durante la ejecución cuando se requiere un ID de usuario y una contraseña, Robot encuentra el ID en el script y la contraseña en el datapool de autenticación asociado a este ID de usuario.

Comenzar a grabar

Para comenzar a grabar un script en una sesión se debe iniciar la grabación con el botón “Record Session” o por medio del menú “File>Record Session”.

Cancelación de scripts

Al cancelar el script durante la grabación el script es eliminado, esto es de gran utilidad si se cometen errores durante la grabación de una sesión o si no se quiere incluir actividades preliminares por ejemplo el logging.



Si no se ha dividido la sesión en múltiples scripts se pueden cancelar ambos, la sesión y el script, y luego frenar la grabación.

Cuando sí se ha dividido la sesión en múltiples scripts se puede cancelar el script actual, simplemente frenando la grabación e ignorando la información recién grabada. Los otros scripts grabados permanecerán en la sesión.

Para cancelar todos los scripts dentro de una sesión de múltiples scripts simplemente se debe parar la grabación y aceptar. Inmediatamente después de esto se debe cancelar la generación de scripts que comienza.

Dividir la sesión en múltiples scriptsLo que se logra al dividir una sesión en múltiples scripts es que cada elemento grabado es una unidad lógica de trabajo, se puede dividir la sesión en tantos scripts como uno quiera.

Si la reutilización de la sesión y la modularidad son el objetivo, las sesiones no deberían dividirse, sin embargo en otras ocasiones la división es óptima, por ejemplo cuando partes de una sesión necesitan ser repetidas muchas veces durante la ejecución, y otras no tanto.

Importar y exportar sesionesRobot permite importar una sesión de un archivo al proyecto actual. También permite exportar una sesión del datastore actual a cualquier ubicación dentro de la PC.

Regeneración de scripts de una sesiónCuando se regeneran scripts de una sesión 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 contenía.

Definir las propiedades de un scriptDefinir las propiedades de un script es importante ya que forma parte del proceso de planeamiento de test. Por esa razón típicamente se definen las propiedades de un script en el Test Manager antes de grabar el script. También pueden ser definidas después de la grabación del script.



Regrabar sesionesRegrabar sesiones es comenzar a grabar una sesión sobre otra que ya contiene scripts. Se puede borrar la sesión vieja y todos sus scripts o no. Grabar sobre una sesión afecta a todos los scripts: para grabar sólo sobre un script se debe seleccionar el nombre del mismo cuando Robot lo solicita.

Opciones de ejecución de GUI scriptsLas opciones de configuración de la ejecución proveen instrucciones a Robot sobre cómo ejecutar los scripts. Pueden ser configuradas antes de comenzar la ejecución 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 verificación

- 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 verificación al ejecutar el

script- Acknowledge results: Robot desplegará un mensaje de los resultados cada vez que se

ejecute un punto de verificación- Minimize Robot: ventana de Robot se minimiza y queda en la barra de tareas- Put Robot in background: la ventana de Robot queda detrás de la aplicación- Display script only: solo muestra el script durante la ejecución, se ocultan las barras de

herramientas- Display menues and toolbars: se muestran los menús y las barras de herramientas

mientras se ejecuta el script.

Las opciones de log también pueden ser seteadas:

- Output playback results to log: muestra resultados de la ejecución en un archivo de log.- View log after playback: automáticamente al finalizar la ejecución se muestra el log.- Prompt before overwrite log: Robot pregunta antes de sobrescribir un log.- Specify log information playback: despliega un diálogo en la ejecución para ingresar datos

como la versión de la aplicación, carpeta de log, archivo de log.- Use default information: utiliza la versión de la aplicación y la carpeta de log utilizada

durante la última ejecución. Utiliza el nombre de script como nombre del archivo de log.

Resultados de la ejecución en el log de Test ManagerLos resultados de la ejecución se pueden ver en el log, incluyendo fallas en los puntos de verificación, fallas procedurales, abortos y cualquier otra información adicional.



Los comparadores ayudan a determinar si la falla es un defecto o un cambio intencional a la aplicación bajo test. Esto se debe a que los comparadores analizan las diferencias entre los datos del punto de verificación de la línea de base y los del punto de verificación actual.

Hay 4 tipos de comparadores:

- Object properties: compara los datos de la línea de base con los datos que causaron la falla en el punto de verificación Object Properties.

- Text: compara los datos de la línea de base con los datos que causaron la falla para el punto de verificación Alphanumeric.

- Grid: compara los datos de la línea de base con los datos que causaron la falla para los puntos de verificación Menu y Object Data.

- Image: compara la imagen del baseline con la imagen que causó la falla para el punto de verificación Window image o Region image. Además permite ver inesperadas ventanas abiertas que provocan fallas durante la ejecución.

DatapoolsUn datapool es un conjunto de datos de test que suministra valores a las variables de un script durante la ejecución. 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 transacción varias veces pueda enviar datos reales al servidor en cada transacción.

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 operación una y otra vez, consecutiva y simultáneamente.

Data TestsLos data tests son los puntos de verificación “Object Data”. El punto de verificación 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.

Robot y el ciclo de vida del softwareEl 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 automáticos 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 implementación de los tests con los test scripts.



Comparación entre los modelosUno de los mayores problemas en lo referente al software es lograr que los ingenieros utilicen consistentemente métodos efectivos. Habitualmente la práctica los ha ido llevando a escribir los programas del mismo modo que lo hacían sus compañeros o superiores, e ignorar el modo apropiado de aplicar los métodos a programas pequeños, pensando que en esos casos no tendría sentido. Esto conduce a que las mejores prácticas tampoco puedan ser aplicadas a los programas grandes.

Los estudiantes de ingeniería de software terminan convenidos de que la codificación y el testing son necesarios, pero todo lo demás es opcional. El sistema educativo no provee a los graduados con las habilidades o con el convencimiento necesario para aplicar rigurosamente métodos efectivos, y pocas organizaciones están dispuestas a pagar por la capacitación necesaria para sus ingenieros.

Para cambiar las prácticas personales de los ingenieros de software se los debe convencer, primeramente, de que los nuevos métodos y modelos son más 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 través 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 implementación, ejecutando en cada etapa actividades de verificación y validación que garanticen encontrar errores o desviaciones en etapas tempranas del desarrollo, para luego en la integración encontrar errores menores, pero teniendo ya una interpretación clara del producto requerido.

El modelo CMMI garantiza la calidad evaluando los procesos de la empresa en niveles de capacidad o madurez, según la adecuación que han conseguido con el modelo presentado por CMMI.

CMMI presenta prácticas específicas–best 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 requisitos de trazabilidad en cada etapa. Realizando las tareas de verificación y validación correspondientes, que llevarán finalmente a un producto que funciona correctamente y realiza lo requerido por el cliente. CMMI presenta en particular las prácticas a realizarse durante la

32 Vid. Watts S. Humphrey, Why Don't They Practice What We Preach?, 04-08-2010



verificación del software –testing-, inputs y outputs requeridos para llegar al nivel de madurez deseado.

IEEE/EIA 12207 define estándares 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 verificación, validación, revisión y auditoría, que atravesando todo el proceso de desarrollo garantiza la trazabilidad desde los requerimientos hasta el producto final garantizando la adecuación con las necesidades del cliente y la ausencia de errores.

A diferencia de CMMI IEEE 12207 sugiere un proceso de adaptación 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 verificación y validación lo largo de todo el ciclo de vida del producto, desde los documentos iniciales de requerimientos, análisis y diseño, que son verificados por medio de revisiones, eliminando así en una etapa temprana las fallas de comprensión respecto de las necesidades del cliente, hasta tareas específicas de testing sobre el programa ya construido, para encontrar errores de programación y también de funcionalidad.

Estos tres primeros modelos analizados abarcan todo el ciclo de vida del software.

La norma IEEE 829 es más detallada y restringida en su alcance: tiene como objetivo establecer un marco de cómo realizar las actividades de testing y sus documentos, aplicable a cualquier ciclo de vida de software. Para la descripción de los procesos se basa en la estructura que provee la norma IEEE 12207.0 y dentro de este marco delinea las diferentes tareas y documentos que son necesarios en cada una de las actividades.

Dentro de los métodos 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 están dirigidas a verificar y validar el código para evitar errores, asegurando que el código ejecutable se adecúe a los requerimientos iniciales.



Por último hemos analizado dos herramientas, Test Manager y Robot, que ayudan a la aplicación del “COMO” de todos estos procesos y mejores prácticas, por medio de la automatización de pruebas y generación de documentos y logs de test, devolviendo los casos de prueba exitosos, los errores, y permitiendo el análisis del código para debug y corrección.

Es decir, el modelo de CMMI, la norma IEEE 12207 y el modelo de UML proponen mejores prácticas a realizar, mientras que la norma IEEE 829 propone un modo concreto de realizarlo. Las herramientas analizadas, Robot y Test manager facilitan la automatización de estos procesos. A través de todos estos enfoques vemos como se garantizan actividades de verificación y validación en cada etapa de desarrollo, revisiones de requerimientos, revisión de trazabilidad del código con respecto a los requerimientos, y generación 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 propagación, arraigándose en el tiempo y produciendo errores cada vez más difíciles de erradicar.



CONCLUSIONES

Como hemos visto en los diferentes enfoques de aseguramiento de la calidad, es importante contar con actividades específicas de verificación y validación a lo largo de todo el ciclo de vida. Una continua validación respecto de los requerimientos, junto con el testing del código, asegurarán no sólo que el producto sea construido con calidad respecto de los posibles errores en la codificación, sino también 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 prácticas, sirven para evitar que el realizado durante el lapso de duración de un proyecto desemboque en algo inútil. 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 verificación y validación necesarios, una especie de teléfono 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 verificación y validación del código, 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 planificación y de calidad.

Sin duda esto termina por ser aún más perjudicial, ya que se genera re-trabajo en las etapas de mantenimiento que al ser generadas por una mala interpretación 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 través 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 utilización de las mejores prácticas, procesos concretos con actividades y tareas tendientes a asegurar la trazabilidad en la construcción del software.

Las herramientas analizadas son una clara ayuda en la etapa de testing del software, automatizando la verificación del código y generando reportes automáticos de errores, facilitando así los datos necesarios para el análisis y detección de errores.

Se podrían realizar trabajos de investigación sobre la importancia específica de la calidad en la planificación, que diera lugar a una ejecución garantizada de las actividades de verificación y validación.

También podrían realizarse trabajos que profundizaran en las actividades de gestión de errores, análisis de causa y resolución, evaluando los diferentes orígenes de los errores, sean por estimaciones demasiado exigentes para las actividades, falta de entrenamiento de los desarrolladores, o fallas en los procesos de revisión.



Bibliografía

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 James, Unified Software Development Process, Addison-Wesley, 1999

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 Ingeniería, Universidad Austral.

Carolina Oberst, TEST MANAGER, trabajo de grado Facultad de Ingeniería, Universidad Austral.

Watts S. Humphrey, Why Don't They Practice What We Preach?, 2010-08-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/foser138-goodenough.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, 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_AFCEA_GMU_C4I.pdf


http://www.sei.cmu.edu/library/assets/whitepapers/Edge_Enabled_Systems_AFCEA_GMU_C4I.pdf

http://www.sei.cmu.edu/library/assets/whitepapers/Edge_Enabled_Systems_AFCEA_GMU_C4I.pdf

http://www.sei.cmu.edu/library/assets/whitepapers/Managing%20Tech%20Debt.pdf

http://www.sei.cmu.edu/library/assets/whitepapers/Managing%20Tech%20Debt.pdf

http://www.sei.cmu.edu/library/assets/whitepapers/foser138-goodenough.pdf

http://www.sei.cmu.edu/library/assets/whitepapers/17072009whydontthey.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


http://www.sei.cmu.edu/reports/10tr011.pdf

http://www.sei.cmu.edu/reports/11tn007.pdf

http://www.sei.cmu.edu/reports/12tn007.pdf

http://www.sei.cmu.edu/library/assets/happy.pdf

testing y calidad de software

Documents