“DISEÑO Y EJECUCIÓN DE PRUEBAS NO FUNCIONALES EN LA APLICACIÓN SISTEMA DE GESTIÓN DOCUMENTAL BASADOS EN EL ESQUEMA MDI 829”
William Alfredo Rodríguez López
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERIADE SISTEMAS BOGOTÁ D.C.
“DISEÑO Y EJECUCIÓN DE PRUEBAS NO FUNCIONALES EN LA APLICACIÓN SISTEMA DE GESTIÓN DOCUMENTAL BASADOS EN EL ESQUEMA MDI 829”
William Alfredo Rodríguez López Código 20032020119
Trabajo De Grado Modalidad Pasantía para optar título en Ingeniera de Sistemas DIRECTOR INTERNO:
Luis Emilio Montenegro Salcedo
Docente Proyecto Curricular Ingeniera de Sistemas DIRECTOR EXTERNO:
Carlos Manuel Chaparro Escobar Ingeniero de Sistemas
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERIADE SISTEMAS BOGOTÁ D.C.
Nota de aceptación: .
____________________________ ____________________________ ____________________________ ____________________________ ____________________________ ____________________________
____________________________ Firma del Presidente del jurado.
___________________________ Firma del jurado .
___________________________ Firma del jurado .
Dedicación
Agradecimientos
A la empresa que fundó en mí el sentido de trabajo, de metas y sacrificios y generosa dio su voto de confianza. Al alma máter por una opción de vida profesional inculcada en los mejores docentes, en especial a los que creen en sus estudiantes.
CONTENIDO
pág.
INTRODUCCIÓN ... 11
1. PLANTEAMIENTO DEL PROBLEMA ... 12
1.1 FORMULACIÓN DEL PROBLEMA ... 12
2. OBJETIVOS ... 14
2.1 OBJETIVO GENERAL ... 14
2.2 OBJETIVOS ESPECÍFICOS ... 14
3. JUSTIFICACIÓN ... 16
4. MARCO TEÓRICO ... 17
4.1 Norma IEEE 829 ... 17
4.1.1 Propósito. ... 18
4.1.2 Que pretende la norma. ... 18
4.1.3 Niveles de integridad del sistema. ... 19
4.1.4 Procesos de prueba. ... 27
4.1.5 Documentación tratada en la norma IEEE 829. ... 31
4.1.6 Esquema general para documentación. ... 31
4.2 Sistema de gestión documental ... 37
4.2.1 Módulos funcionales del sistema bajo estudio ... 38
4.3 Modelo de Proceso Unificado de Rational o Rational Unified Process (R.U.P) ………39
4.4 MDI 829 ... 39
4.4.1 Descripción del esquema. ... 39
4.4.2 ¿Dónde toma el nombre? ... 39
4.4.3 Objetivos del esquema. ... 40
4.4.4 ¿Por qué el acople? ... 41
4.4.5 Proceso soportado. ... 41
4.4.6 ¿Para qué se utiliza? ... 44
4.4.7 ¿Cómo se ejecuta y cuál es el funcionamiento de los modelos de desarrollo de software con el estándar? ... 44
4.5.1 Clasificación de las pruebas. ... 48
4.5.2 Calidad de software. ... 51
5. DESARROLLO METODOLÓGICO ... 52
5.1 Políticas de privacidad ... 52
5.2 Planteamientos para el desarrollo metodológico ... 53
5.2.1 Planteamiento de la metodología R.U.P ... 53
5.2.2 Planteamiento Norma IEEE 829 ... 57
5.2.2.1 Nivel de integridad aplicado. ... 59
5.2.3 Planteamiento pruebas no funcionales ... 61
5.2.4 Planteamiento y ejecución del esquema MDI 829 ... 63
6. Conclusiones. ... 149
7. Bibliografía ... 150
LISTA DE FIGURAS
pág.
Figura 1. Estructura de definición de procesos. ... 27
Figura 2. Procesos soportados por la norma IEEE829. ... 28
Figura 3.Vista de la documentación de pruebas. ... 32
Figura 4. Relación entre actividades de prueba y procesos. ... 40
Figura 5.Interacción modelo de desarrollo RUP y estándar IEEE 829 ... 46
Figura 6. Clasificación general de pruebas de software. ... 48
Figura 7. División de estructura de calidad ... 50
Figura 8.Modelo de la vista arquitectural 4+1 en sigedoc. ... 54
Figura 9.Estructura general de flujos de trabajo R.U.P. ... 56
Figura 10. Gestión de pruebas no funcionales ... 63
Figura 11. Nivel de integridad radial por prueba no funcional. ... 74
Figura 12. Pasos generales del esquema. ... 76
Figura 13. Perspectiva en Tiempo de R.U.P. ... 77
Figura 14. Matriz de asociación R.U.P con estándar IEEE 829. ... 99
Figura 15. Metodología R.U.P... 101
Figura 16. Ciclo general de pruebas no funcionales en MID 829... 102
Figura 17 Ciclo pruebas no funcionales. ... 103
Figura 18. Actividades de procesos por ciclos de desarrollo de software según la norma IEEE829. ... 106
Figura 19. Niveles y documentos IEEE829 por pruebas de rendimiento. ... 116
Figura 20. Niveles y documentos IEEE829 por pruebas de seguridad. ... 117
Figura 21. Niveles y documentos IEEE829 por pruebas de disponibilidad. ... 118
Figura 22. Control de estado por nivel. ... 126
LISTA DE TABLAS
pág.
Tabla 1.Descripción de nivel de integridad ... 21
Tabla 2.Identificación de nivel de integridad ... 21
Tabla 3.Descripción de consecuencias de las fallas ... 22
Tabla 4. Esquema basado en riesgos. ... 22
Tabla 5.Tareas de prueba mínimas asignadas para cada nivel de integridad durante cada actividad. ... 23
Tabla 6. Tareas de prueba, entradas (inputs) y salidas (outputs). ... 30
Tabla 7. Mapeo o asignación de actividades del estándar IEEE 829 al esquema MDI 829. ... 43
Tabla 8. Descripción Requerimientos no funcionales. ... 49
Tabla 9. Esquema del nivel de integridad basado en riesgos REDISE. ... 60
Tabla 10. Esquema del nivel de integridad basado en consecuencias. ... 61
Tabla 11. Definición de programa interno de pruebas. ... 63
Tabla 12. Pauta 1. Preparación de pruebas. ... 69
Tabla 13. Pauta 2. Ejecución de pruebas. ... 69
Tabla 14. Pauta 3. Finalización de pruebas. ... 70
Tabla 15. Documentos por nivel de integridad. ... 71
Tabla 16. Rango de peso real de trabajo para amplitud y profundidad. ... 72
Tabla 17. Esquema del Nivel de integridad por amplitud y profundidad. ... 73
Tabla 18. Documentación normas regulatorias archivísticas. ... 80
Tabla 19. Reglas de control a la base de datos. ... 87
Tabla 20. Iteraciones por fase de transición. ... 95
Tabla 21. Actividades materializadas fase de transición. ... 96
Tabla 23. Relación de actividades y nivel de integridad. ... 105
Tabla 24. Integridad de pruebas de disponibilidad. ... 109
Tabla 25. Integridad de pruebas de rendimiento... 110
Tabla 26. Integridad de pruebas de seguridad... 111
Tabla 27. Niveles y documentos IEEE829 por pruebas de rendimiento. ... 113
Tabla 28. Niveles y documentos IEEE829 por pruebas de disponibilidad. ... 113
Tabla 29. Niveles y documentos IEEE829 por pruebas de seguridad. ... 114
Tabla 30. Artefactos documento de pruebas no funcionales. ... 121
Tabla 31. Tareas mínimas recomendadas. ... 124
Tabla 32. Documentos por nivel de preparación, ejecución y finalización. ... 128
Tabla 33. Actividades núcleo de LTPr. ... 136
Tabla 34. Informes generales de nivel MTR. ... 138
INTRODUCCIÓN
El presente proyecto diseña e implanta la propuesta denominada esquema prototipo MDI 829, cuyo propósito consiste en la unificación e integración del modelo de desarrollo de software R.U.P y el estándar IEEE 829*. Este esquema permitió ejecutar pruebas no funcionales del sistema de gestión documental Sigedoc†adquirido por la Contraloría General de la República para radicar, producir, tramitar, archivar y hacer seguimiento a la documentación.
Una vez se ejecute el esquema prototipo MDI 829 en el proyecto, las fallas‡ encontradas podrán administrarse con procesos gerenciales según el enfoque de pruebas no funcionales.
La ejecución del esquema se realiza teniendo en cuenta tanto las recomendaciones propias del concepto del esquema, la forma de integración con la metodología de desarrollo, la gestión de artefactos y el nivel de integridad de las pruebas según el estándar IEEE 829. Así, la materialización del esquema acata los anteriores conceptos y los aplica en 8 pasos secuenciales e independientes en cada una de las tres pruebas no funcionales abordadas. En este orden el paso 1 identifica el estado del proyecto dentro de las fases del modelo R.U.P; el paso 2 fija en cada iteración de fase las tareas de gestión; el paso 3 establece el alcance general de las pruebas; el paso 4 identifica la estrategia para la realización de pruebas no funcionales en el contexto del ciclo de procesos, el paso 5 controla el inicio, el proceso y finalización de las pruebas, monitoreando los 3 pasos siguientes; el paso 6 precisa el alcance general detallando las actividades e inicia el contexto de las pruebas procedimentalmente encajando las pruebas en el proyecto; el paso 7 recoge las ideas de las pruebas, las organiza, las separa y las vuelve un hecho técnico con un alto grado de nivel de detalle funcional; y el paso 8 evalúa, ejecuta, obtiene el registro o evidencia de las pruebas y analiza los resultados.
Para todos los pasos se aplicaron objetivos y resultados obtenidos por el pasante exceptuando los pasos seis, siete y ocho en los cuales se incluyeron niveles de integridad.
*IEEE 829: Es el estándar para documentación de pruebas de software (1). †Sigedoc: Aplicación web desarrollada en el lenguaje de programación java. ‡
1. PLANTEAMIENTO DEL PROBLEMA
1.1 FORMULACIÓN DEL PROBLEMA
La Contraloría General de la Republica (CGR, en adelante) como máximo órgano de control fiscal nacional público colombiano procura el buen uso de los recursos y bienes públicos para contribuir a la modernización del estado. Basado en este hecho, del escenario archivístico de la CGR depende la creación, generación, organización, administración, eliminación y distribución de la documentación que ingresa desde diferentes sedes a nivel nacional. De aquí la importancia de utilizar herramientas tecnológicas actualizadas que soporten operaciones archivísticas. A partir de esta exigencia archivística, el sistema* al que se pretende reemplazar no suple la mayoría de estas necesidades, puesto que su ámbito radica en funciones sólo de recepción y correspondencia únicamente a la capital colombiana, razón por la cual no es una herramienta integral de gestión documental.
La CGR, por ser una entidad con varias sedes a nivel nacional, necesita tener un cubrimiento descentralizado con las gerencias departamentales. Esta característica descentralizada obliga a almacenar la documentación en un punto central para que pueda ser correctamente gestionada, de manera que tiene que recurrir a utilizar diferentes tipos de recursos como medios de traslado físico o medios de comunicación tecnológicos como internet, con el fin de llevar a cabo la unificación de procesos sobre esta documentación. Otra necesidad que tiene que ser atendida por la entidad es acceder y consultar de manera frecuente los documentos que ingresan diariamente en la CGR desde sus distintas gerencias departamentales, siendo un proceso que actualmente no es posible.
Dentro de las exigencias más apremiantes que debe cumplir el sistema Sigedoc para poder ser acogido como el nuevo sistema de gestión documental a nivel nacional, es cumplir con lo que señala el anexo número 9 descrito en el documento de términos de referencia† para la solicitud de oferta publica No 08-GDCOLCGR-24032010 en la licitación de la contraloría, cuyos requisitos son: 1. El sistema de gestión documental debe operar sobre documentos digitales.
*
CORDIS: herramienta software de apoyo para la recepción, tramite, gestión y clasificación de correspondencia interna y externa de la CGR
2. Cumplir con organización física y técnica del archivo y la digitalización de folios*. Los anteriores requisitos implican que el sistema debe tener un nivel de calidad óptimo para que no resulte frágil a los requisitos que se le solicitan y que también supere limitaciones que pueden afectar al sistema en su totalidad, como: deficiencia en comunicaciones, no disponibilidad de documentos, destrucción o manipulación no autorizada y tiempos de respuesta demasiado largos. Por tal razón se deben realizar pruebas a la aplicación que permitan establecer si el sistema cumple con los requisitos no funcionales requeridos.
Los requisitos por los cuales se interesa y son solicitados por la CGR, son obtener una herramienta que permita superar las anteriores limitaciones, evaluando las características del sistema en el ámbito de las pruebas no funcionales.
¿El esquema prototipo MDI 829 permite evaluar las pruebas no funcionales† para comprobar la calidad y cumplimiento de los requisitos solicitados por la CGR?
*Folio: hoja documental que puede ser física o digital. †
2. OBJETIVOS
2.1 OBJETIVO GENERAL
Diseñar y ejecutar pruebas no funcionales de rendimiento, seguridad y disponibilidad en el sistema de gestión documental Sigedoc de la Contraloría General de la República de acuerdo al esquema prototipo MDI 829.
2.2 OBJETIVOS ESPECÍFICOS
1. Revisar la norma IEEE 829 y relacionarla con la metodología de desarrollo R.U.P en el esquema MDI 829, para comprender el alcance general del proyecto. 2. Recurrir a la caracterización de procesos* y a la comprensión de macro-procesos del sistema de gestión documental de la CGR para adquirir la visión integral del mismo.
3. Utilizar el esquema prototipo MDI 829 en el proyecto de software de gestión documental para generar la documentación necesaria y requerida para la ejecución de las pruebas no funcionales. Identificando así los pasos propuestos en este tipo de pruebas y en concordancia con la fase de transición de la metodología R.U.P.
4. Aplicar prueba piloto con personas implicadas en el proyecto para de esta manera verificar que el sistema Sigedoc se acopla a los tiempos de gestión utilizados por la CGR en la etapa de preproducción del sistema.
5. Evaluación de los resultados de la prueba piloto, precisando los “bugs” o errores que se pueden presentar en la aplicación en el contexto del tipo de prueba realizada. Verificar el logro de los objetivos propuestos en el esquema MDI 829 sobre las pruebas de disponibilidad, rendimiento y seguridad, conforme a los niveles de integridad de la norma IEEE 829.
*
6. Establecer el costo y el beneficio inherente a la realización de las pruebas no funcionales.
3. JUSTIFICACIÓN
La Contraloría General de la República (CGR), por ser una entidad gubernamental, adopta los objetivos del Archivo General de la Nación de Colombia, característica que le da la facultad de acoger un sistema de gestión documental para permitir contribuir de manera ejemplar al logro de los objetivos archivísticos.
Los objetivos misionales y visionales acogidos del Archivo General de la Nación mencionan que se debe conservar y difundir el acervo documental del país, como también articular, asegurar y ampliar la disponibilidad y acceso a todos los archivos públicos y patrimoniales del país para poder contribuir al fortalecimiento de la participación ciudadana y el control social.
Al dotar a la CGR con una estructura de tecnología sólida* para la gestión documental representada en una aplicación web cuyo objetivo es suplir las necesidades propias archivísticas de la entidad, la empresa que suministra el software garantizará un nivel de calidad aceptable y suficiente basadas en la realización de las pruebas funcionales y no funcionales correspondientes al sistema de gestión documental.
4. MARCO TEÓRICO
La serie de elementos conceptuales que soportan y fundamentan el trabajo desarrollado alrededor a las pruebas no funcionales del sistema de gestión documental Sigedoc son:
- R.U.P. Tomado como modelo de proceso en marco del desarrollo del software de gestión documental Sigedoc.
- Sigedoc. Sistema sobre el cual se realizaron pruebas no funcionales y se aplicó el esquema MDI 829.
- Norma IEEE 829. Norma que presenta los diferentes artefactos y documentos que se tienen que utilizar de acuerdo con la importancia de los niveles de integridad sobre las pruebas.
- Esquema MDI 829*. Esquema prototipo que utiliza la información suministrada por el estándar IEEE 829 para gestionar la documentación que ahí se establece.
- Pruebas no funcionales. Labores y procesos para verificar y probar las características del sistema, las cuales son diseñadas, creadas y ejecutadas en base a escenarios de pruebas no funcionales de esquema MDI 829 y que permiten el aseguramiento de la calidad del software.
4.1 Norma IEEE 829
La norma 829 del estándar IEEE 1998 o norma IEEE 829-1998 se entiende que es la norma para la documentación de pruebas de software.
Esta norma es compatible con todos los procesos del ciclo de vida del software y con todos los modelos de desarrollo.
Los procesos de prueba de software y sistema determinan si los resultados de una determinada actividad se ajustan a los requisitos de dicha actividad y si el desarrollo del producto o los productos satisfacen su uso previsto y las necesidades del usuario.
*
4.1.1 Propósito.
El enfoque general del estándar es permitir comprender y proceder con un determinado tipo de documentación para pruebas de software. Sin embargo, los propósitos principales establecen 5 objetivos, definidos así:
- Establecer un marco de trabajo común para los procesos de pruebas, actividades y tareas de apoyo a todos los procesos del ciclo de vida del software, incluyendo la adquisición, suministro, desarrollo, operación y procesos de mantenimiento.
- Definir tareas de prueba, entradas y salidas requeridas.
- Identificar las tareas de prueba mínimas recomendadas correspondientes a los niveles de integridad
- Definir el uso y el contenido del plan de pruebas Maestro y el Plan de Pruebas de Nivel(es).
- Definir el uso y el contenido de la documentación de pruebas relacionadas e implicadas en el diseño de pruebas, casos de prueba, procedimiento de prueba, informe de anomalías, registro de prueba, informe de prueba de nivel y entre otras el informe provisional de pruebas e informe de plan maestro.
4.1.2 Que pretende la norma.
La norma IEEE 829, en especial la aprobación de la versión de 1998 en la revisión de la publicación 2008: IEEE Standard for Software and System Test Documentation (Revision of Std829-1998)*, pretende proporcionar evidencia que el sistema basado en software y sus productos asociados puedan satisfacer los requerimientos que se asignaron al sistema, soluciones correctas, satisfacción al uso y necesidades de los usuarios.
4.1.3 Niveles de integridad del sistema.
Un esquema de niveles de integridad proporciona los medios estructurados para establecer la amplitud y la profundidad de las pruebas; por lo tanto a un mayor nivel de integridad mayores tareas adicionales de bajo nivel se tendrán que realizar y mayores pruebas en profundidad.
Si no se tiene un requisito de un cierto nivel de integridad, el probador o Tester no sabrá qué funciones, requisitos o productos se necesitan, solo sabrá que es un esfuerzo superficial e intenso.
En este contexto la norma IEEE 829 usa niveles de integridad para determinar las tareas de prueba a ser realizadas al sistema. Así, los niveles de integridad pueden ser aplicados a requerimientos, funciones, grupos de funciones, componentes y subsistemas. Por tanto, el esquema de integridad puede estar basado en funcionalidades, rendimiento, seguridad o en otras características del software o de otro sistema.
4.1.3.1 Niveles de integridad. El nivel de integridad indica la importancia relativa del software; por tanto, el nivel de integridad puede estar asociado a una característica, un componente o un nivel de prueba, basados en un conjunto de atributos seleccionados como por ejemplo: complejidad, riesgo, nivel seguro, nivel de seguridad, integridad de datos, rendimiento, fiabilidad, calidad, costos, tamaño y otras características únicas del software. Entonces el nivel de integridad varía dependiendo de su uso y de cómo sea previsto en el sistema.
El nivel de integridad puede denotarse por identificadores únicos como números. Un software con un relativo alto nivel de integridad requiere de más esfuerzo en las pruebas y más documentación de pruebas que un software con bajo nivel de integridad.
La Tabla 1 describe la asignación de niveles de integridad y gradualidad, la Tabla 2 puntualiza los niveles de integridad que identifica el impacto de una falla, la Tabla 3 proporciona definiciones de las consecuencias del fracaso y la Tabla 4 describe un esquema basado en el riesgo, incluyendo los posibles niveles de integridad, los cuales relacionan la probabilidad de materialización de un defecto con el tipo de consecuencia de la falla o error.
Para identificar las tareas de prueba es necesario saber qué procesos de prueba tiene el sistema, de esta manera si se tiene como ejemplo un software de alta integridad se requerirá de un conjunto grande de procesos de prueba, por ende también se necesita una rigurosidad de tareas de prueba que da como resultado más documentación sobre las pruebas realizadas. Los procesos de prueba aquí mencionados y la documentación de las pruebas resultante se deben adaptar a los requisitos del sistema y a la aplicación o aplicaciones específicas a través de la selección de un nivel de integridad (estos niveles tienen sus correspondientes tareas mínimas de prueba con la alternativa de poder adicionar tareas de prueba si es necesario).
Esta norma presenta niveles de integridad como ejemplos descriptivos, permitiendo al usuario de la norma hacer uso de los mismos. Igualmente el usuario puede utilizar otros criterios y por supuesto otra documentación si lo desea; por tanto, no obliga a que se deba seguir la norma en rigurosidad.
Esta norma es una de las buenas prácticas en desarrollo de software pues al aplicarse a través de un esquema de nivel de integridad facilita la selección de
actividades*y tareas apropiadas que se deben seguir, teniendo como resultado la documentación necesaria para pruebas.
Esta norma provee como ejemplo un esquema de cuatro niveles de integridad, que son categorizados según la gravedad de las consecuencias (del incorrecto comportamiento durante la ejecución) y sobre el potencial de mitigación (pasos para disminuir el riesgo mediante la reducción de la probabilidad de ocurrencia de un evento del riesgo o reduciendo el efecto si llega a ocurrir), tal como se presenta en la Tabla 1, siendo estos datos en la tabla un esquema basado en el análisis de riesgos.
Tabla 1. Descripción de nivel de integridad
Nivel de
integridad Descripción
4
Una falla en una función o en una característica del sistema genera consecuencias catastróficas al sistema, se incluye consecuencias al usuario y al ambiente entre muchos otros; con una razonable, probable o probabilidad ocasional de ocurrencia de un estado operacional que contribuye a generar el error.
3
Una falla en una función o en una característica del sistema genera consecuencias críticas al sistema, con una razonable, probable, o probabilidad ocasional de ocurrencia de un estado operacional que contribuye a generar el error.
2
Una falla en una función o en una característica del sistema genera consecuencias marginales al sistema, con una razonable, probable, o probabilidad ocasional de ocurrencia de un estado operacional que contribuye a generar el error.
1
Una falla en una función o en una característica del sistema genera consecuencias despreciable al sistema, con una razonable, probable, o probabilidad ocasional de ocurrencia de un estado operacional que contribuye a generar el error.
Fuente Annex B, Table B.1—Description of integrity levels, p.72.(1)
La identificación de cada nivel se presenta en la Tabla 2.
Tabla 2.Identificación de nivel de integridad
Nivel de integridad Descripción general
Nivel 1 Es despreciable
Nivel 2 Es Marginal
Nivel 3 Es Crítica
Nivel 4 Es Catastrófico
Tabla 3.Descripción de consecuencias de las fallas
Consecuencia Definición
Catastrófica
Pérdidas de vidas humanas, misión completa fallida, pérdida de seguridad del sistema y del seguro del sistema, gran pérdida financiera o social.
Crítica Mayores y permanentes daños, pérdida parcial de la misión, daño al sistema principal, importante pérdida de financiación o social.
Marginal Daños marginales moderados, degradación de la misión secundaria, pérdida moderada financiera o social.
Despreciable Menor daño, menor impacto sobre el rendimiento del sistema, o inconveniente a operar.
Fuente Annex B, Table B.2—Definitions of consequences of failures,p.72. (1).
Tabla 4. Esquema basado en riesgos.
Consecuencia
Probabilidad de ocurrencia de un estado operativo que contribuye a error
Muy Probable Probable Ocasional Improbable
Catastrófica 4 4 4 o 3 3
Crítica 4 4 o 3 3 2 o 1
Marginal 3 3 o 2 2 o 1 1
Despreciable 2 2 o 1 1 1
Fuente Annex B, Table B.3—Risk assessment scheme,p.73.(1).
La Tabla 5 presenta las tareas de prueba mínimas que van a ser realizadas para cada nivel de integridad. De este modo el usuario de este estándar podrá asignar este esquema de nivel de integridad y asociarlo a tareas mínimas de prueba a su propio esquema de nivel de integridad. Este tipo de asignación o mapeo del esquema de integridad asocia las tareas de prueba mínimas como los documentos del plan de pruebas maestro MTP* en ingles Master Test Plan o el Plan de alto nivel de prueba LTP, en inglés, Highest Level Test Plan.
*
Tabla 5.Tareas de prueba mínimas asignadas para cada nivel de integridad durante cada actividad.
4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1
nivel de integridad
Requerimientos Pruebas
nivel de integridad Actividades de prueba
Adquisición
Pruebas de adquisicion de software
nivel de integridad nivel de integridad
Genera ci ón del es ta do de l a prueba de a cepta ci ón i nterna
nivel de integridad
Operación Mantenimiento Procesos del ciclo de vida
Instalación/ verificación
nivel de integridad
Pruebas de Operación
nivel de integridad
Pruebas de mantenimiento
nivel de integridad Concepto
nivel de integridad Desarrollo Suministro
Planeación Diseño
nivel de integridad
Genera ci ón de ca s os de prueba de a cepta ci ón
Ejecuci ón de prueba s de a cepta ci ón
Genera ci ón de regi s tro de prueba s de a cepta ci ón Genera ci ón de pl a n de prueba de Acepta ci ón
Genera ci ón de Procedi mi ento de prueba de a cepta ci ón.
X X X
X X X
X X X
X X
X X X
X X X X X X X Implementación
Genera ci ón de di s eño de prueba de a cepta ci ón
Genera ci ón de es ta do de
prueba de a cepta ci ón X X X
Eva l ua ci ón (opera ci ona l ) de
Anoma l i a X X X
Genera ci ón de es ta do de
a noma l i a X X X X X X X X X X X X X X X X X X X X
Genera ci ón reporte de es ta do de prueba de componente i nterno
X X X
Genera ci ón de ca s o de prueba
de componente X X X
Ejecuci ón de prueba de componente
Genera ci ón de di s eño prueba
de componente X X X
X X X
Genera ci ón de regi s tro de
prueba de componente X X X
X X X Genera ci ón de pl a n de prueba
Tabla 5. (Continuación 1)
4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1
nivel de integridad nivel de integridad nivel de integridad
Actividades de prueba
Procesos del ciclo de vida
Adquisición Suministro Desarrollo Operación Mantenimiento
Pruebas de adquisicion de
software Planeación Concepto Requerimientos Diseño Implementación Pruebas
Instalación/ verificación Pruebas de Operación Pruebas de mantenimiento
nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad
X X X X
Ge ne ra ci ón de re gi s tro prue ba de i nte gra ci ón compone nte
X X X X
Eje cuci ón prue ba de i nte gra ci ón de compone nte
X X X X
Ge ne ra ci ón de di s e ño de prue ba de i nte gra ci ón de compone nte
X X X X
Ge ne ra ci ón ca s o de prue ba de i nte gra ci ón de compone nte
X X X X X X X X X X X X
Proce s os de s oporte y orga ni za ci ón con i nte rfa z
X X X
Ge ne ra ci ón de re porte de e s ta do de prue ba i nte rna de i nte gra ci ón de compone nte
X X X
re porte
Ins ta l a ci ón/Ve ri fi ca ci ón
X X
Audi tori a confi gura ci ón i ns ta l a ci ón (fi s i co y, funci ona l )
X X
Re porte de i ns ta l a ci ón/ ve ri fi ca ci ón
X X X
Re vi s i ón de i nte rfa z de re que ri mi e ntos pa ra prue ba s
X X X X X X X X X X X X
Ide nti fi ca r ri e s gos
X X X
X X X
X X X
X X X
Ide nti fi ca r ri e s gos de s e guri da d (prue ba )
X X X X X X X X X
X X X X X X X X X X X X X X X X X X X X X X X X X
Ide nti fi ca ci ón de oportuni da de s de me jora e n prue ba de conducta
X X X X
X X X
X X
Pre pa ra ci ón e s ta do de prue ba ma e s tra
X X X X X X X
X X X X X X X X X X X X X
Ana l i s i s Cri ti cos
X X
Propos i to de l a prue ba por re vi ci ón de conce pto de docume nta ci ón
X X X
Ge ne ra ci ón de re porte de prue ba de compone nte
X X X
Tabla 5.(Continuación 2)
4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1
Pruebas de mantenimiento
nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad
Actividades de prueba
Procesos del ciclo de vida
Adquisición Suministro Desarrollo Operación Mantenimiento
Pruebas de adquisicion de
software Planeación Concepto Requerimientos Diseño Implementación Pruebas
Instalación/ verificación
Pruebas de Operación
X X X X
Ge ne ra ci ón pl a n prue ba de i ntegra ci ón de compone nte
Ge ne ra ci ón pl a n de proce di mi e nto de i ntegra ci ón compone nte
X X X X
Ge ne ra ci ón prue ba re porte de
i ntegra ci ón de compone nte X X X X
X X X X X X X X
X X X X X
Ide nti fi ca r ni ve l de i ntegri da d
X X X X X X X X X X X
X X X X X
Es fue rzo prue ba de Ge s ti ón X X X X X X X X X X X X X X X X X X X X X X X X
X X
X X X
X X X
Soporte de re vi s i ón tecni ca y de
ge s ti ón X X X X X X X X X X X X
Ge ne ra ci ón re porte prue ba
ope ra ci ona l X X
X X X X
Pl a ne a ci ón de l a i nterfa z e ntre e l e s fue rzo de prue ba y e l prove e dor
X X X X
X X X X
De termi na r e l a l ca nce de l
e s fue rzo de l a prue ba X X X X Ge ne ra ci ón re porte e s ta do de
prue ba i nterna de l s i s tema X X X
X X X X
Eva l ua ci ón de re que ri mi e ntos de l s oftwa re pa ra propos i tos de prue ba
Re vi s i ón de re que ri mi e ntos de l
s i s tema pa ra proba r X X X X Ge ne ra ci ón pl a n prue ba
ma e s tro X X
re vi s i on pl a n prue ba ma e s tro X X X X X X
Ide nfi ca ci ón Me tri ca s X X X X
Tabla 5. (Continuación 3)
FuenteTable 3--Minimum testing tasks assigned to each integrity level during each activity,p.23-29.(1).
4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1 4 3 2 1
nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad nivel de integridad Actividades de prueba
Procesos del ciclo de vida
Adquisición Suministro Desarrollo Operación Mantenimiento
Pruebas de adquisicion de
software Planeación Concepto Requerimientos Diseño Implementación Pruebas
Instalación/ verificación Pruebas de Operación Pruebas de mantenimiento nivel de integridad nivel de integridad nivel de integridad nivel de integridad
Genera ci ón ma tri x de
tra za bi l i da d de prueba X X X X X X X X X X X X X X X
X X X X X X
Genera ci ón reporte prueba Ma es tra
X X X X Genera ci ón pl a n de prueba de
s i s tema
Genera ci ón procedi mi ento de
prueba del s i s tema X X X X
Genera ci ón reporte prueba de
prueba de s i s tema X X X X
Si s tema ejecuci ón prueba X X X X
Itera ci ón de ta rea s X X X X
Pa rti ci pa ci ón revi s i ón de
di s poni bi l i da d de prueba X X X X
X X X X Genera ci ón ca s os de prueba de
s i s tema
X X X Genera ci ón di s eño de prueba
de s i s tema X
X X X Ejecuci ón prueba s de s i s tema
Genera ci ón regi s tro prueba de s i s tema
X
4.1.4 Procesos de prueba.
Esta norma sigue una estructura bien definida en el estándar IEEE/EIAStd 12207.0-1996(2) utilizado para describir procesos según como se presenta en la Figura 1. Cada proceso tiene uno o más actividades de apoyo que se ejecutan por una o más tareas. Este es un método top-down que sirve para determinar cuáles tareas son requeridas. Cada una de las tareas tiene que ser identificada, de este modo las entradas inputs y salidas outputs resultantes de este proceso pueden ser identificadas y por ende como caso particular de esta norma las entradas y salidas determinan cuales documentos de pruebas son necesarios.
Las pruebas necesitan soportar los procesos de la norma IEEE/EIAStd 12207.0-1996, los cuales se describen a continuación y se presentan en la Figura 2: - Gestión (Management).
- Adquisición (Acquisition). - Suministro (Supply). - Desarrollo (Development). - Operación (Operation).
- Mantenimiento (MaintenanceProcess).
Figura 2. Procesos soportados por la norma IEEE829.
Para cada uno de los procesos anteriores hay actividades con tareas mínimas recomendadas que la norma IEEE 829 soporta y son descritos con sus respectivas entradas (inputs) y salidas (outputs).
Al mencionar los términos actividad y tarea, es necesario indicar estas palabras en el contexto del estándar, por ende la definición de actividad se refiere al “elemento para cumplir con un trabajo específico durante la ejecución de un proceso, normalmente tiene una duración prevista, coste y recursos necesarios. El término tarea se define como la unidad más pequeña de trabajo, siendo sujeta a una gestión en términos contables, la tarea ésta bien definida en un trabajo sí está asignada para uno o más miembros del proyecto. Las tareas relacionadas generalmente se agrupan para formar actividades”*
.
Como ejemplo general, en la Tabla 6 se presenta la Actividad gestión de prueba
para el proceso de gestión (en inglés Management) con su correspondiente documentación para las entradas y salidas.
*
Tabla6. Tareas de prueba, entradas (inputs) y salidas (outputs).
Fuente IEEE 829Annex C, Table C.1—Testing tasks, inputs, and outputs. Pág. 74-75.(1).
Tareas de prueba Entradas Inputs Salidas Outputs
(1) Generar Plan de Pruebas Maestro (MTP) norma IEEE Std 829
a) Generar el MTP para todo los procesos del ciclo de vida
> Plan Maestro de Pruebas
Master Test Plan(con actualizaciones en caso de la existencia de las mismas)
> Plan Maestro de Pruebas Master Test Plan
y sus actualizaciones
b) Establecer un lineamiento base para MTP antes de los requerimientos de la actividad
> Identificar los niveles de integridad (tarea 4)
c) Identificar los hitos del proyecto en el MTP > Calendario Maestro
d) Planificar las tareas de prueba
> Documentos de conceptos (ejemplo, reglas de negocio, requerimientos del sistema.. Etc)
(2) Revisión de la gestión del esfuerzo de pruebas Plan de Pruebas Maestro
Riesgos y Reportes de Anomalias
a)
Examinar y resumir el esfuerzo de la prueba para definir cambios en las tareas de prueba o para redirigir la prueba
Reportes de anomalias
entrada a Reporte de Prueba Maestro
b) Recomendaciones para pasar a la siguiente serie de tareas de prueba y presentar informes de anomalías e informes de nivel de prueba.
> Planes de desarrollo y planificación
Actualización Plan de Prueba Maestro
c) Verificacion de que todas las tareas de prueba cumplen con los requisitos definidos en el MTP
>Productos de desarrollo Reportes de Nivel de Prueba
d) Verificar que los resultados de las tareas de prueba tienen una base de evidencias que respaldan los resultados.Planificar las tareas de prueba
(3) Proporcionar revisión a la gestión y soporte a la Revisión Técnica Documentos de desarrollo Reportes de Anomalias a) Apoyo a la revisión de proyectos de gestión y revisiones técnicas
(por ejemplo,Revisión del diseño preliminar y Revisión Crítica del Diseño) para evaluación de los materiales , atendiendo a la revisiones previas y proporciona informes de nivel de prueba y reportes de anomalías.
Reportes de anomalias entrada a Reporte de Prueba Maestro
b)
…* …* revisión de reportes de
resultados
c) …* …* …*
d) …*
* entradas para la tarea 3 * salidas para la tarea 3 (4) Interfaz con organización y apoyo a procesos
a) …*
Plan de Pruebas Maestro Master Test Plan
Actualización del Plan de Pruebas Maestro Master Test Plan
b) …* …* …*
c) …* …* …*
…* …*
* entradas para la tarea 4 * salidas para la tarea 4 Tareas de prueba durante el proceso de gestión: Actividad gestion de prueba
* especificación de subtareas de la tarea 3
* especificación de subtareas de la tarea 4
4.1.5 Documentación tratada en la norma IEEE 829.
La documentación que arroja esta norma depende en gran medida de los procesos del ciclo de vida del software, así los documentos que se requerirán estarán asociados y supeditados previamente a una lista de actividades y tareas de prueba las cuales están definidas por los procesos que se seleccionan de acuerdo a los contenidos adecuados de documentación .
Se tiene entonces un esquema general para obtener la documentación relacionada.
4.1.6 Esquema general para documentación.
Figura 3.Vista de la documentación de pruebas.
4.1.6.1 Plan Maestro de pruebas o Master Test Plan (MTP): Este plan de pruebas es un artefacto que permite planificar la gestión de todas las pruebas que se llevarán a cabo y los documentos de pruebas. Especifica cinco temas básicos. - Permite conocer cómo se llevará a cabo la prueba e incluye el sistema bajo
la prueba (SUT*) con sus configuraciones. - ¿Quién lo realizará?
- ¿Que se pondrá a prueba?
- El tiempo necesario para la realización de la prueba o pruebas. Respecto a los recursos.
- Nivel de calidad de la prueba. Se identifica con la cobertura que se da a la prueba.
Este nivel de pruebas contempla la planificación global de la prueba y gestión de documentos e identifica los puntos de mayor esfuerzo. Así, el MTP define el esquema de nivel de integridad y su selección, los procesos de prueba general, actividades y tareas, selecciona los niveles de prueba y sus documentos.
4.1.6.2 Nivel de plan de Prueba o Level Test Plan (LTP): Define contenido recomendado de diseño de pruebas.
Este nivel también define el alcance, enfoque, recursos y cronogramas definidos, qué elementos se prueban y la característica asociada a la prueba, los responsables y los riesgos. Se ayuda con una matriz de rastreabilidad la cual vincula requisitos de la prueba y elementos a probar.
*
4.1.6.3 Nivel de diseño de prueba o Level Test Design (LTD):
Especificación de refinamientos del enfoque de prueba. Este nivel precisa detalladamente la prueba y ajustes al diseño, verifica si existe otro tipo de asociación con otras pruebas y el estado del documento.
4.1.6.4 Nivel de especificación de Casos de prueba o Level Test Case (LTC): Detalla los datos que se probarán según las condiciones de diseño de la prueba.
Este nivel limita la información necesaria de las pruebas, acotando las entradas (en inglés “Input”) y salidas (en inglés “Output”) para el tipo de prueba.
4.1.6.5 Nivel de procedimiento de prueba o Level Test Procedure (LTPr):
Etapa en la cual se especifica cómo se deberá ejecutar cada prueba, comprende prerrequisitos, configuración y guías.
Los pasos específicos o procedimientos en la realización de los conjuntos de pruebas, son evaluados según las características de las pruebas. Cuando se detallan las entradas y salidas, requerimientos especiales, asociaciones con herramientas automatizadas o sistemas externos, permite soportar la implementación de otros niveles de prueba como LTC, LTD, LTP o MTP. Este nivel también comprende soportar información de las pruebas tales como: registro, configuración, inicio, procedimiento, medición, reinicio, pausa o detención, condiciones y contingencias, en si define todas las configuraciones e instrucciones de ejecución de la prueba.
4.1.6.6 Nivel de registro de prueba o Level Test Log (LTL): Etapa en la cual se registra o graba lo encomendado por el tipo de prueba, es un registro de toda actividad concerniente a la prueba. Autor, orden, aprobada. Describe en los registros la siguiente información: ítems iniciados, versión, cambios por entorno, fechas de inicio y detención de prueba, causas de no continuación.
4.1.6.7 Nivel de notificación de incidentes o Anomaly Report (AR):
Comunica si una prueba según un control preestablecido generó una falla, esta prueba presenta además otro artefacto que informa indicios del suceso que originó la falla. Es el Informe de incidencias*†, informe con resultados reales y esperados,
puede contener información del impacto de un incidente en las pruebas.
El propósito principal del nivel es entender y describir la anomalía de acuerdo al tipo, fecha, software asociado con su versión, acciones de corrección, entradas, resultados esperados, resultados reales, resultados inesperados, réplicas de intentos, probadores (en inglés “testers”) y observadores. También indicar la profundidad y amplitud del impacto que tendrá sobre los temas técnicos y de negocio como documentación de pruebas, documentación de desarrollo, habilidades de usuario para tareas de rendimiento, el estado de la anomalía como abierto, aprobado, asignado, fijo o en prueba. Puede también incluir los tiempos estimados, el esfuerzo y el riesgo de los defectos fijados. En si el nivel define resultados inesperados o incorrectos generados.
4.1.6.8 Nivel Informe provisional de estado de la prueba o level Interim
Test Status Report (LITSR): Informe de gestión que permite su análisis,
evaluación de la calidad de la prueba, evaluación del sistema de software que soporta la prueba.
Este nivel resume los resultados de las actividades de prueba designados y opcionalmente proporciona evaluaciones y recomendaciones basadas en los resultados.
4.1.6.9 Nivel de informe de la prueba o Level Test Report (LTR): Informe de gestión que permite obtener un resumen y una evaluación de cada nivel de prueba.
Tiene como propósito resumir los resultados de las actividades de prueba designados y proporcionar evaluaciones y recomendaciones basadas en los resultados.
*
Incidencia: se define en cantidad según la real academia española “rae. 2. f. Número de casos ocurridos”
†
4.1.6.10 Informe de prueba maestro o Master Test Report (MTR): Informe de gestión sobre los resultados.
Resume los resultados de los niveles de cada nivel de las actividades de prueba y permite evaluar según los resultados.
Las comparaciones y estadísticas son derivadas de los informes en un cronograma de todos los artefactos de las pruebas de notificación de incidentes. Permite además planificar pruebas a futuro.
En el contexto de la norma no todos los documentos tienen que ser necesariamente utilizados pues el criterio para la selección de los mismos lo define el nivel de integridad, el objetivo o razón de ser del software y también dependerá de los criterios del personal, grupo o director de pruebas encargado del proyecto.
4.2 Sistema de gestión documental
La idea principal de un sistema de gestión documental es aplicar los conceptos archivísticos en una aplicación informática, manejando el conjunto de técnicas y prácticas para la administración de documentos.
El sistema aborda procesos para la gestión documental al interior de una organización, tiene a disposición la información completa de la documentación, tiempos de gestión, tiempos de resguardo o eliminación, disposición final de los mismos y su conservación.
El sistema administra entradas: correspondencia, trámites internos, expedientes, resoluciones, circulares, actas y demás tipos de comunicados; recepcionando, radicando y digitalizando de manera manual o automática la documentación. Seguidamente distribuye, organiza y pone a disposición y consulta según las restricciones propias de confidencialidad contenida o según las tablas de retención la información o documentación que se demande.
Cuenta también con funcionalidades de administración de usuarios, mensajería, tesauro, alertas, visores de documentación, flujos de trabajo y reportes.
Dicha síntesis compacta a mayor grado todo el tipo de procesos, actividades e instancias que involucran personal y tiempo en las labores determinadas para procesos o actividades en documentación.
Con la idea del sistema ya establecida, se contempla que el proyecto de pruebas no funcionales se enmarca en la fase de transición para la correcta culminación y despliegue funcional del software en la etapa de pre producción (con ejercicio de marcha blanca*). Sin embargo se aclara que para la fase de transición se relaciona varias pruebas aplicadas en las fases previas.
4.2.1 Módulos funcionales del sistema bajo estudio
4.2.1.1 Módulo Radicación: Encargado de registrar y radicar comunicación denominada entrante o saliente, documentación, administrar distribución y devoluciones, indexación manual y automática y digitalizar.
4.2.1.2 Módulo Documentos: Módulo con la funcionalidad de buscar documentación, administrar carpeta personal de los usuarios, traslados de documentación o carpetas, trámites de documentación, actividades* y formatos de documentación de acuerdo a los procedimientos definidos para cada tipología documental.
4.2.1.3 Módulo Archivo: Permite el manejo de archivos de gestión, central e histórico, respecto a las tablas de retención documental (TRD) y tablas de valoración documental (TVD), sobre los préstamos y transferencias de documentación y carpetas genera las respectivas alertas.
4.2.1.4 Módulo Reportes: Permite generar información de conocimiento interno para control y estadística de procesos al interior de la entidad.
4.2.1.5 Módulo Base: Módulo de auditoría, registra acciones sobre el sistema, administra usuarios, controles de acceso y funcionalidades sobre los perfiles y los módulos dispuestos en la aplicación.
*
4.3 Modelo de Proceso Unificado de Rational o Rational Unified Process (R.U.P)
El marco de desarrollo para el proyecto Sigedoc es el modelo R.UP, el cual se relaciona e integra con el estándar IEEE 829 para obtener el esquema MDI 829. R.U.P permite a los equipos de desarrollo reconocer todos los beneficios del Lenguaje Unificado de Modelado UML, del software y de otras mejores prácticas de la industria. Esta metodología es generalmente la más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Reconoce y aprovecha las características de los procesos de desarrollo: cascada, evolutivo, componentes, incremental y espiral.
4.4 MDI 829
4.4.1 Descripción del esquema.
Este es un esquema nuevo que surge al integrar procesos del modelo de desarrollo de software R.U.P y el estándar IEEE 829. La perspectiva por la cual surgió este esquema es para poder tener un compendio o cuadro referencial de documentación ágil para entrega de pruebas de un proyecto de desarrollo en cualquier fase del mismo, este esquema entonces se introduce como un esquema liviano de información en el cual se destaca la manera en cómo se utiliza la información de las diferentes etapas de un modelo de software involucrando los documentos funcionales del estándar IEEE 829.
4.4.2 ¿Dónde toma el nombre?
.Como se menciona el MDI 829 hace referencia a un esquema que representa el resultado del ensamble de un conjunto de actividades inherentes a una metodología particular de desarrollo y al estándar IEEE 829; por tal motivo, este esquema toma su nombre simplemente de la descripción aplicada de este conjunto y es: MDI 829 “Metodología de Desarrollo Acoplado con estándar IEEE 829”.
4.4.3 Objetivos del esquema.
Este esquema tiene como finalidad cumplir con los siguientes propósitos:
- Asociar un modelo de desarrollo de software R.U.P con el estándar IEEE 829 (1).
- Generar los artefactos de tipo informe funcional, operacional y gerencial del proyecto según la necesidad de información solicitada por los procesos de desarrollo del ciclo de vida de software.
- Soportar el proceso de pruebas del modelo de desarrollo de software del estándar IEEE 829. Ver recuadro verde en la Figura 4.
- Adoptar del estándar IEEE 829 el nivel de integridad adecuado, según las características que se necesite evaluar del software, estas pueden ser atributos como: complejidad, riesgo, nivel de seguridad, integridad de datos, rendimiento, fiabilidad, calidad, costos, tamaño, disponibilidad, usabilidad, mantenibilidad…etc., además seguir las actividades necesarias según el proceso del ciclo de vida del software sobre el cual se necesite trabajar. Ver Figura 4.
- Ejecutar los pasos de cada nivel de pruebas según el esquema.
Fuente Table 3--Minimum testing tasks assigned to each integrity level during each activity, p.23-29.(1).
4.4.4 ¿Por qué el acople?
En referencia al actual proyecto, el acople o integración se da al suplir necesidades de entrega liviana y confiable de documentación de pruebas no funcionales en la fase de transición para la aplicación del sistema de gestión documental.
En teoría se puede realizar la integración con diferentes tipos de metodologías de desarrollo de software como los son: modelo en cascada, desarrollo evolutivo, modelo basado en componentes, modelo incremental o modelo en espiral, lo cual daría resultados similares como en el proyecto presente utilizando la metodología RUP “modelo de proceso unificado de Rational”.
4.4.5 Proceso soportado.
El estándar IEEE 829 soporta seis procesos propios en su modelo de desarrollo de software y son: gestión (en inglés “management”), adquisición (en inglés “acquisition”), suministro (en inglés “supply”), desarrollo (en inglés “development”), operación (en inglés “operation”) y mantenimiento (en inglés “maintenance Process”). De los cuales se acoge el proceso de desarrollo para el proyecto, en el cual se enfoca al subproceso pruebas porque este proceso del ciclo de vida del software tiene definida actividades de prueba y tareas mínimas recomendadas por la norma, además de tener definido un nivel de integridad asociado a sus actividades, a las entradas inputs y a las salidas outputs.
Como referencia, la Tabla 5…de la sección con numeral 4.1.3.1… presenta el ciclo de vida del software con todos los procesos, subprocesos, actividades de prueba y niveles de integridad. Tomando como base la Tabla 5 solo se asigna o mapea el proceso Desarrollo, obteniendo la Tabla 7, la cual es el resumen de seleccionar solo el subproceso Pruebas. En esta tabla presentada se aclara que se añade en los campos de las columnas de integridad la letra A para identificar que se Agrega y se tiene en cuenta una nueva asociación de actividades; lo que permite poder determinar qué tipos de actividades pueden ser requeridas para este proyecto en relación a las pruebas no funcionales.
Tabla7. Mapeo o asignación de actividades del estándar IEEE 829 al esquema MDI 829.
4 3 2 1
id co ns ec ut ivo Pruebas
nivel de integridad Acti vi dades de prueba
Procesos del ci cl o de vi da Desarrol l o
1 1Ge ne ra ci ón de l e s ta do de l a prue ba de a ce pta ci ón i nterna X X X
2 4Eje cuci ón de prue ba s de a ce pta ci ón X X X
3 5Ge ne ra ci ón de re gi s tro de prue ba s de a ce pta ci ón X X X
4 7Ge ne ra ci ón de Proce di mi e nto de prue ba de a ce pta ci ón. X X X
5 8Ge ne ra ci ón de e s ta do de prue ba de a ce pta ci ón X X X
6 9Eva l ua ci ón (ope ra ci ona l ) de Anoma l i a A A
7 10Ge ne ra ci ón de e s ta do de a noma l i a X X X X
8 11Ge ne ra ci ón re porte de e s ta do de prue ba de compone nte i nterno X X X
9 12Ge ne ra ci ón de ca s o de prue ba de compone nte A A
10 13Ge ne ra ci ón de di s e ño prue ba de compone nte A A A
11 14Eje cuci ón de prue ba de compone nte A A
12 15Ge ne ra ci ón de re gi s tro de prue ba de compone nte A A A
13 16Ge ne ra ci ón de pl a n de prue ba de compone nte A A
14 17Ge ne ra ci ón de proce di mi e nto de prue ba de compone nte A A A
15 18Ge ne ra ci ón de re porte de prue ba de compone nte A A
16 19Propos i to de l a prue ba por re vi s i ón de conce pto de docume nta ci ón A A
17 20Ana l i s i s Cri ti cos A A
18 21Pre pa ra ci ón e s ta do de prue ba ma e s tra A A A A
19 22Ide nti fi ca ci ón de oportuni da de s de me jora e n prue ba de conducta X X X X
20 23Ide nti fi ca r ri e s gos de s e guri da d (prue ba ) X X
21 24Ide nti fi ca r ri e s gos X X
22 26Ins ta l a ci ón/ Ve ri fi ca ci ón A A A A
23 29Ge ne ra ci ón de re porte de e s ta do de prue ba i nterna de i ntegra ci ón de
compone nte X X X
24 30Proce s os de s oporte y orga ni za ci ón con i nterfa z X X
25 33Eje cuci ón prue ba de i ntegra ci ón de compone nte X X X X
26 34Ge ne ra ci ón de re gi s tro prue ba de i ntegra ci ón compone nte X X X X
27 37Ge ne ra ci ón prue ba re porte de i ntegra ci ón de compone nte X X X X
28 39Es fue rzo prue ba de Ge s ti ón X X X X
29 40Soporte de re vi s i ón tecni ca y de ge s ti ón X X
30 41Ge ne ra ci ón pl a n prue ba ma e s tro A A A A
31 42Re vi s i ón pl a n prue ba ma e s tro A A A A
32 48Ge ne ra ci ón re porte e s ta do de prue ba i nterna de l s i s tema X X X
33 49Eva l ua ci ón de re que ri mi e ntos de l s oftwa re pa ra propós i tos de prue ba A A A
34 50Re vi s i ón de re que ri mi e ntos de l s i s tema pa ra proba r A
35 51Ge ne ra ci ón ca s os de prue ba de s i s tema A A A A
36 52Ge ne ra ci ón di s e ño de prue ba s de s i s tema A A A A
37 53Eje cuci ón prue ba s de s i s tema X X X X
38 54Ge ne ra ci ón re gi s tro prue ba de s i s tema X X X X
39 55Ge ne ra ci ón pl a n de prue ba de s i s tema A A A A
50 57Ge ne ra ci ón re porte prue ba de prue ba de s i s tema X X X X
51 58Si s tema e je cuci ón prue ba X X X X
52 60Pa rti ci pa ci ón re vi s i ón de di s poni bi l i da d de prue ba X X
53 61Ge ne ra ci ón re porte prue ba Ma e s tra A A
4.4.6 ¿Para qué se utiliza?
Pretende entregar artefactos de tipo informe funcional, operacional y gerencial del proyecto al cual se ha introducido de una manera más ágil, pues toma los temas primordiales para su operación sin descuidar ni descartar la cobertura que se da por parte de la metodología de desarrollo y el estándar que adopta, ya que sobre estos enfoques trabaja el esquema.
4.4.7 ¿Cómo se ejecuta y cuál es el funcionamiento de los modelos de desarrollo de software con el estándar?
Ya que el esquema MDI 829 es el resultado del acople e integración de un estándar y una metodología de desarrollo de software, sobre estas instancias se pretende hacer el ejercicio práctico de instaurar criterios básicos para su implementación, siguiendo las pautas requeridas y fundamentales del conjunto de procesos y técnicas utilizadas en el esquema.
Las pruebas no funcionales abordadas en este proyecto son pruebas de rendimiento, seguridad y disponibilidad con el enfoque de ser ejecutadas usando el esquema MDI 829.
La ejecución corresponde en validar el siguiente conjunto de labores generales para las cuales se obtiene su propia caracterización y posteriormente se ponen en práctica:
- La primera labor corresponde en identificar en qué fase, flujo de trabajo y ciclo o iteración se encuentra el desarrollo del software según el modelo de desarrollo R.U.P.
- En razón al estándar IEEE 829, la segunda labor constituiría en identificar comparativamente qué proceso, qué actividad y qué tarea le es correspondida a la iteración obtenida en la primer labor realizada.
- La tercer labor constituye en seleccionar la documentación que se asocia a las actividades de prueba de acuerdo al esquema general para documentación*y que cumplan con el tipo de prueba a realizar.
*
- La cuarta labor tiene como fin validar o actualizar el nivel de integridad, si es necesario de las actividades de prueba*.
- La quinta labor consiste en trabajar en las tareas de prueba†. Lo que permite generar, gestionar y obtener la documentación del proyecto para pruebas no funcionales. La característica de esta labor es controlar las pruebas.
- La sexta labor es encajar las pruebas no funcionales en la metodología R.U.P y darles el alcance general en el proyecto.
- La labor número siete presenta la planeación y casos de prueba de las pruebas no funcionales, con su respectiva verificación, validación e inspección en el detalle técnico y funcional de los documentos y herramientas utilizadas.
- La última labor radica en la materialización de las pruebas no funcionales, con su respectiva ejecución y resultados.
En la Figura 5 se presenta un ejemplo básico de la labor número dos mencionada previamente, que consiste en la unión de la metodología R.U.P y estándar IEEE 829 como guía representativa para seguir el esquema MDI 829. El enfoque de la unión en esta figura es abordar el mecanismo para seleccionar los documentos según las pruebas funcionales o no funcionales que se requieran; por tanto, en el ejemplo se indica que la Sección I y Sección II permiten inicialmente realizar la verificación de documentos que se planean utilizar para un tipo de prueba específica.
*Ver …numeral 4.1.4… Procesos de prueba.
4.5 Pruebas de Software
Las pruebas de software son determinadas por las cualidades de la aplicación a probar, razón por la cual hay que estimar un plan general que involucre tiempos, recursos e intereses sobre la finalidad y rol que cumplirán las pruebas, esto permite de manera fiel verificar y controlar la realización de las mismas por medio de estándares, guías o procesos adoptados o generados por la organización que las realiza.
Las pruebas no funcionales permiten verificar los requerimientos no funcionales del software, las cuales comprometen un plan de pruebas específico. El plan de pruebas no funcionales actúa como guía técnica para la realización de las pruebas, permitiendo definir las condiciones necesarias para la ejecución, los recursos utilizados, los resultados y tratar con las posibles fallas que puedan generarse.
Pruebas de software, (En inglés “testing”) son los procesos que permiten validar la calidad de un producto software. Son utilizadas para identificar y detectar defectos que pueden verse materializados, indicar un nivel de calidad del sistema, obtener información para la toma de decisiones y para la prevención de defectos. Básicamente es un proceso que consiste en planificar, diseñar, ejecutar, evaluar controlar y gestionar las pruebas realizadas al sistema.
48 4.5.1 Clasificación de las pruebas.
La clasificación general para pruebas de software se presenta en la Figura 6.
Figura 6. Clasificación general de pruebas de software.
Pruebas unitarias
Caja Blanca (prueba estructural “ligada a código”) Pruebas de flujo de control
Pruebas de flujo de datos
Pruebas de bifurcación (branch testing) Pruebas de caminos básicos
Pruebas de integración Técnica Bing Bang Técnica Top Down Técnica Bottom up Técnica Middle-out Estrategias combinadas
Funcionales (comportamiento o pruebas de caja negra) Partición de equivalencia
Análisis de valores limite Prueba de transición de estado
Tablas de decisión
Prueba de caso de uso
Pruebas de sistema
No funcionales (pruebas de caja negra) Comunicaciones
Rendimiento
Carga y rendimiento (Load and Performance Test Tools) Estrés
Resistencia
Prueba de estabilidad (soak testing) Pruebas de picos (spike testing) Tensión
Recuperación Usabilidad Facilidad de uso Operación Entorno Seguridad Usabilidad Almacenamiento Configuración Instalación Documentación Recuperación Implantación
Pruebas de Aceptación Alfa
Beta Pruebas de Regresión
4.5.1.1 Pruebas no funcionales: Las pruebas no funcionales (PNF) implican la interacción con varios procesos técnicos involucrados en el sistema y tiene relación directa con el enfoque de caja negra (ver Figura 7) pues se encarga de obtener resultados coherentes y precisos sobre el correcto funcionamiento del sistema bajo restricciones o validaciones de requerimientos no funcionales, por ejemplo, en la Tabla 8 se presenta una de las maneras posibles de agrupar los diferentes tipos de requerimientos no funcionales.
Tabla 8. Descripción Requerimientos no funcionales.
Requerimiento no
funcional Descripción y enfoque
Comprobabilidad Grado en que un sistema, software o servicio de TI *
permite y facilita que sea probado en un determinado contexto.
Disponibilidad
Corresponde al tiempo total en que un sistema puede ser usado en un período determinado. También puede definirse el grado en que un sistema está en un estado operable definido cada vez que se necesite.
Extensibilidad Grado en que la implementación del sistema toma en consideración y facilita su crecimiento en el futuro.
Escalabilidad
Capacidad de un sistema o servicio de TI de manejar una creciente carga de trabajo, por ejemplo mayor número de conexiones o usuarios. No debe confundirse con extensibilidad, que mide la capacidad del sistema de crecer en funcionalidades.
Mantenibilidad
Mide la facilidad con que puede darse mantenimiento al producto (en este caso al software o servicio de TI), con la finalidad de: Desarrollar nuevos requerimientos, Aislar los defectos y sus causas, corregir estos defectos y atender las demandas del entorno cambiante.
Seguridad
Grado de protección de los datos, software y plataforma de tecnología de posibles pérdidas, actividades no permitidas o uso para propósitos no establecidos previamente.
Usabilidad Definido como la facilidad de uso y aprendizaje de un Sistema, Software o Servicio de Tecnología de Información.
*TI: LaTecnología Informática(IT), según lo definido por la asociación de la Tecnología Informática de
América (ITAA), es “el estudio, diseño, desarrollo, innovación, puesta en práctica, ayuda o gerencia de los sistemas informáticos computarizados, particularmente usos del software y hardware.” En general, se ocupa del uso de computadoras y del software electrónico, así como de convertir, almacenar, proteger, procesar, transmitir y de recuperar la información.(9).
