“DISEÑO Y EJECUCIÓN DE PRUEBAS NO...

“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.

2015

“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.

2015

Nota de aceptación: .

____________________________ ____________________________ ____________________________ ____________________________ ____________________________ ____________________________

____________________________ Firma del Presidente del jurado.

___________________________ Firma del jurado .

___________________________ Firma del jurado .

Dedicación De quien aprendí que el camino recto se hace siendo justo y con ella al creador.

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. Al profesor Emilio por su constancia y paciencia.

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 Pruebas de Software ................................................................................ 47

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

Anexos ................................................................................................................. 154

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

Figura 23. Resumen base de requisitos del sistema Sigedoc por Anexo 9.……130

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 22. Descripción pasos de procesos de prueba. ......................................... 103

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

Tabla 35. Documentación y artefactos generales PNF. ....................................... 140

11

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.

‡Falla: En la jerga informática se tiene más precisión llamar incidencia a un fallo.

12

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 †Término de referencia: documento que describe el interés de propuesta para contratar la adquisición y puesta

en marcha de un sistema de gestión documental, una solución de “fax server”, la organización física y técnica

del archivo y la digitalización de folios para la contraloría general de la república.(1)

13

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.

†Las pruebas no funcionales específicas son: disponibilidad, rendimiento y seguridad.

14

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.

*Los procesos oficiales directamente implicados y descritos por la CGR son: ADMINISTRACIÓN DE

PROCESOS Y PROCEDIMIENTOS, CONTROL FISCAL MACRO, CONTROL FISCAL MICRO, ENLACE CON

CLIENTES Y PARTES INTERESADAS, RESPONSABILIDAD FISCAL Y JURISDICCION COACTIVA. Los

anteriores documentos se encuentran en el repositorio del proveedor del software.

15

6. Establecer el costo y el beneficio inherente a la realización de las pruebas no funcionales. 7. Elaborar análisis, conclusiones y recomendaciones en la aplicación del esquema propuesto.

16

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.

* Esta solidez de la herramienta acoge los parámetros instaurados por el Instituto Colombiano de Normas

Técnicas y Certificación ISO 15489 (2) que tiene como característica el valioso aporte de gestión documental

física y electrónica.

17

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.

* MDI 829 (Véase numeral 4.4 ): Esquema que asocia la norma IEEE 829 y el modelo de desarrollo R.U.P.

18

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.

*Información resumen se encuentra en el Abstract: http://ieeexplore.ieee.org: Draft IEEE Standard for

software and system test documentation (Revision of IEEE 829-1998)

19

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. Este estándar usa el concepto de niveles de integridad para determinar las tareas de prueba mínimas recomendadas a realizar. Se precisa entonces que las entradas (inputs) y las salidas (outputs) de las tareas de prueba presentan la documentación necesaria.

20

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.

*Se describe con más precisión a una actividad como una actividad de prueba y su ejemplo práctico se

presenta en la Tabla 4.

21

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

Fuente4.1Integrity levels, p.13.(1)

22

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.

*Si no hay MTP se acoge el documento LPT

23

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

Generación del estado de la

prueba de aceptación interna

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

DesarrolloSuministro

Planeación Diseño

nivel de integridad

Generación de casos de prueba

de aceptación

Ejecución de pruebas de

aceptación

Generación de regis tro de

pruebas de aceptación

Generación de plan de prueba

de Aceptación

Generación de Procedimiento

de prueba de aceptación.

X X X

X XX

X X X

X X

X X X

X

X XX

XX X

Implementación

Generación de diseño de

prueba de aceptación

Generación de estado de

prueba de aceptaciónX XX

Evaluación (operacional ) de

Anomal iaX X X

Generación de estado de

anomal iaX X X X XX X X X XX X X X XX X X X X

Generación reporte de estado

de prueba de componente

interno

X XX

Generación de caso de prueba

de componenteX X X

Ejecución de prueba de

componente

Generación de diseño prueba

de componenteX X X

X X X

Generación de regis tro de

prueba de componenteX X X

X X XGeneración de plan de prueba

de componente

24

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



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 XGeneración de regis tro prueba

de integración componente

X X X XEjecución prueba de

integración de componente

X X X XGeneración de diseño de

prueba de integración de

componente

XX X XGeneración caso de prueba de


X X X X X XX XX X X XProcesos de soporte y

organización con interfaz

X X XGeneración de reporte de

estado de prueba interna de


X X Xreporte

Insta lación/Veri ficación

XXAuditoria configuración

insta lación (fi s ico y, funcional )

X XReporte de insta lación/

veri ficación

X X XRevis ión de interfaz de

requerimientos para pruebas

X X X X X XX XX X X XIdenti ficar riesgos

X X XX X XX X XX X XIdenti ficar riesgos de

seguridad (prueba)

X X XX X X X X XX X X X X X XX X X X X XX X X X X XX X X X X XIdenti ficación de

oportunidades de mejora en

prueba de conducta

X X X X

X XX

X X

Preparación estado de prueba

maestra

XX X X X X XX X X X XX XX X X X X XAnal is i s Cri ticos

X XPropos i to de la prueba por

revición de concepto de

documentación

X X XGeneración de reporte de

prueba de componente

X X XGeneración de procedimiento

de prueba de componente

25

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




Pruebas de

adquisicion de


Instalación/

verificación

Pruebas de

Operación

XX X XGeneración plan prueba de


Generación plan de

procedimiento de integración

componente

X X X X

Generación prueba reporte de

integración de componenteX X XX

X X X XX X X XX X X X XIdenti ficar nivel de integridad

XX X X X XX X X X XX X X X XEsfuerzo prueba de Gestión

X X X X X X X X XX X X X XX X X X XX X X X X

X XX X XX X XSoporte de revis ión tecnica y de

gestiónX X X XX XX X XX X X

Generación reporte prueba

operacionalX X

X X X XPlaneación de la interfaz entre

el es fuerzo de prueba y el

proveedor

X X X X

X X X XDeterminar el a lcance del

es fuerzo de la pruebaX X X X

Generación reporte estado de

prueba interna del s i s tema X XX

X XX XEvaluación de requerimientos

del software para propos i tos

de prueba

Revis ión de requerimientos del

s i s tema para probarX X X X

Generación plan prueba

maestroX X

revis ion plan prueba maestroX X X X X X

Idenficación MetricasX X X X

Ejecución prueba operacionalX X

26


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




Pruebas de

adquisicion de


Instalación/

verificación

Pruebas de

Operación

Pruebas de

mantenimiento

nivel de integridad nivel de integridad nivel de integridad nivel de integridad

Generación matrix de

trazabi l idad de pruebaX X X X X X X X X X X X X X X

X X X X X XGeneración reporte prueba

Maestra

X XX XGeneración plan de prueba de

s is tema

Generación procedimiento de

prueba del s is temaX X X X

Generación reporte prueba de

prueba de s is temaX X XX

Sis tema ejecución pruebaX X XX

Iteración de tareasX X X X

Participación revis ión de

disponibi l idad de pruebaXX X X

X X X XGeneración casos de prueba de

s is tema

X X XGeneración diseño de prueba

de s is temaX

X X XEjecución pruebas de s is tema

Generación regis tro prueba de

s is tema

X

X X X X

27

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.

Fuente: IEEE/EIAStd 12207.0-1996 Process Definition Infrastructure.p.15.(1).

Figura 1. Estructura de definición de procesos.

28

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.

Fuente Figure 1. Structure of this International Standard. Pag. 7.(1).

29

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.

*De (1) 3. Definitions, acronyms, and abbreviations p.8.

30

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 anomaliasentrada 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

El MTP sera actualizado durante todo el desarrollo del ciclo de vida.

31

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. El presente esquema permite comprender qué tipo de documentación se debe gestionar, su representación jerárquica se presenta en varios niveles en el siguiente esquema gráfico representado en la Figura 3.

32

Figura 3.Vista de la documentación de pruebas.

Fuente Figure 4–Test documentation overview p.34.(1).

33

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.

*SUT (system under test) Sistema bajo prueba: se refiere a un sistema que está siendo probado para su correcto funcionamiento. El término se utiliza sobre todo en las pruebas de software. Un caso especial de un sistema de software es una aplicación que, durante la prueba, se llama aplicación bajo prueba. El término relaciona la etapa de madurez del software, ya que una prueba del sistema es el sucesor del ensayo de la integración en el ciclo de pruebas (5).

34

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. Como resumen, ese nivel permite obtener un registro detallado y cronológico de datos relevantes de detalles referente a la ejecución de las pruebas. Las herramientas automáticas sirven de ayuda para poder capturar todo o parte de la información. La implementación de este artefacto soporta LTPr, LTC, LTD, LTP, o MTP.

35

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” †Incidencia: puede tratarse como un bug o error para seguimiento en caso de ser iterativo.

36

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. En este proyecto se definieron los documentos a generar según la Tabla 30 … de la sección 5.2.4.8.5, paso 5 del esquema MDI 829 …

37

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.

* Marcha blanca: Este término tiene una interpretación práctica en el ambiente interno de la CGR puesto que

indica que es necesario probar el software en conjunto con los sistemas y usuarios con los cuales tiene

relación funcional incluyendo datos e información similar a la real antes de su salida a producción.

38

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.

*Tramite: flujo de trabajo para los documentos.

39

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”. El acople e integración de estos dos conjuntos de procesos o técnicas generarán un arquetipo o esquema llamado MDI 829.

40

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).

Figura 4. Relación entre actividades de prueba y procesos.

41

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. La decisión de agregar actividades diferentes a las contempladas en el proceso de pruebas del estándar IEEE 829 radica en que esta norma tiene seis procesos totalmente independientes y establecidos en orden secuencial y en una línea de tiempo determinada sin mezclar actividades de otros procesos, por tanto el resultado de las actividades para cada proceso de prueba ya está dimensionado. En el esquema MDI 829 las actividades agregadas de otros procesos ayudan a completar las tareas necesarias para cumplir con las labores faltantes y poco

42

detalladas de las pruebas no funcionales, por ejemplo: la actividad con Id 41 denominada Generación plan prueba maestro en la Tabla 7 corresponde al proceso de Adquisición y sub proceso de Pruebas de Adquisición de software. De esta manera se agrega la actividad y se la asocia a la fase de pruebas de R.U.P para tener completitud de la prueba. Se hace de esta manera pues es gracias a esta metodología que se facilita trabajar con estas actividades en iteraciones.

43

Tabla7. Mapeo o asignación de actividades del estándar IEEE 829 al esquema MDI 829.

4 3 2 1

idco

nsec

utiv

o

Pruebasnivel de integridad



Desarrollo

1 1 Generación del estado de la prueba de aceptación interna X X X

2 4 Ejecución de pruebas de aceptación X X X

3 5 Generación de regis tro de pruebas de aceptación X X X

4 7 Generación de Procedimiento de prueba de aceptación. X X X

5 8 Generación de estado de prueba de aceptación X X X

6 9 Evaluación (operacional ) de Anomal ia A A

7 10 Generación de estado de anomal ia X X X X

8 11 Generación reporte de estado de prueba de componente interno X X X

9 12 Generación de caso de prueba de componente A A

10 13 Generación de diseño prueba de componente A A A

11 14 Ejecución de prueba de componente A A

12 15 Generación de regis tro de prueba de componente A A A

13 16 Generación de plan de prueba de componente A A

14 17 Generación de procedimiento de prueba de componente A A A

15 18 Generación de reporte de prueba de componente A A

16 19 Propos i to de la prueba por revis ión de concepto de documentación A A

17 20 Anal is i s Cri ticos A A

18 21 Preparación estado de prueba maestra A A A A

19 22 Identi ficación de oportunidades de mejora en prueba de conducta X X X X

20 23 Identi ficar riesgos de seguridad (prueba) X X

21 24 Identi ficar riesgos X X

22 26 Insta lación/ Veri ficación A A A A

23 29Generación de reporte de estado de prueba interna de integración de

componente X X X

24 30 Procesos de soporte y organización con interfaz X X

25 33 Ejecución prueba de integración de componente X X X X

26 34 Generación de regis tro prueba de integración componente X X X X

27 37 Generación prueba reporte de integración de componente X X X X

28 39 Esfuerzo prueba de Gestión X X X X

29 40 Soporte de revis ión tecnica y de gestión X X

30 41 Generación plan prueba maestro A A A A

31 42 Revis ión plan prueba maestro A A A A

32 48 Generación reporte estado de prueba interna del s i s tema X X X

33 49 Evaluación de requerimientos del software para propós i tos de prueba A A A

34 50 Revis ión de requerimientos del s i s tema para probar A

35 51 Generación casos de prueba de s is tema A A A A

36 52 Generación diseño de pruebas de s is tema A A A A

37 53 Ejecución pruebas de s is tema X X X X

38 54 Generación regis tro prueba de s is tema X X X X

39 55 Generación plan de prueba de s is tema A A A A

50 57 Generación reporte prueba de prueba de s is tema X X X X

51 58 Sis tema ejecución prueba X X X X

52 60 Participación revis ión de disponibi l idad de prueba X X

53 61 Generación reporte prueba Maestra A A

54 62 Generación matriz de trazabi l idad de prueba X X X

44

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.

*Ver numeral 4.1.6 Esquema general para documentación.

45

- 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.

†Ver Tabla 6 …del numeral 4.1.4… Procesos de prueba.

46

Fuente Figure 16-1.An iteration in the inception phase. Chapter 16.(1).

Figura 5.Interacción modelo de desarrollo RUP y estándar IEEE 829

47

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. Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro del principio de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.(3)

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

Fuente (4).

49

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: La Tecnologí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).

Fuente(5).

50

Figura 7. Estructura general del aseguramiento analítico en las pruebas*

Fuente (6). 4.5.1.1.1 Pruebas de Rendimiento. “Consisten en determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema.”(7)

“Esta prueba permite determinar respuestas del sistema bajo carga de trabajo como también establecer una línea base que pueda ser utilizada en un futuro para comparar el incremento en el rendimiento de la aplicación bajo pruebas. Comúnmente incluye las pruebas de carga, pruebas de estrés y pruebas de resistencia entre otras.” (7), las pruebas de rendimiento también pueden servir para “validar y verificar otros atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos” (7) En el ámbito de “testing” las pruebas de rendimiento también se las puede denominar pruebas de desempeño, y en el ámbito de requerimientos como pruebas de escalamiento. 4.5.1.1.2 Pruebas de Disponibilidad. La disponibilidad del software está descrito en su ámbito particular como la verificación de que los “procesos de

* Solo se presenta la estructura dinámica pues el enfoque se basa en el comportamiento del sistema y la

estructura constructiva la cual no se presenta en la figura corresponde a los métodos técnicos y de

organización para la creación del software.

Aseguramiento de calidad

Analítico

Dinámico

Caja Negra Caja Blanca

Pruebas Funcionales Pruebas no funcionales

51

negocio están funcionando de forma correcta, al margen del estado de sus recursos hardware” (7) y la utilización de los mismos.

Como marco general se tiene las pruebas de disponibilidad de datos, labor que “consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo físico como lógico, sin comprometer la integridad de los datos.” (7)

4.5.1.1.3 Pruebas de Seguridad. Estas pruebas se enfocan en la confidencialidad, la integridad y la disponibilidad de la información. Permitiendo además detectar vulnerabilidades que pueden ser aprovechadas por personal no deseado, y tener “mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos”(7). Estos controles permiten proteger el sistema de una irrupción inadecuada. 4.5.2 Calidad de software.

La calidad del software se traduce como el nivel en el cual una aplicación o parte de ella cumple la totalidad de las exigencias o necesidades buscadas por el usuario y son satisfechas por medio de procesos que involucran acciones inquisitivas que buscan fallas en el software, las cuales al evidenciarse y controlarse de una manera adecuada ayudan a la correcta y oportuna detección y corrección de defectos. Un factor importante de calidad son los recursos asignados para resolver las pruebas, este factor se considera como recurso tangible e intangible el cual presta beneficios en resultados, entendiéndose como recursos tangibles al hardware, documentación, artefactos u otros similares, para recursos intangibles energía cerebral, energía eléctrica, mano de obra, tiempo, trabajo, experiencia, dedicación y software. El tercer factor puede ser denominado procedimiento de calidad, que simplemente es relacionar de una manera planificada las pruebas con los recursos antes mencionados. Así la forma para resolver estas relaciones es verificar qué normas, técnicas o metodologías hacen buen uso de los anteriores factores.

52

5. DESARROLLO METODOLÓGICO El sistema de gestión documental Sigedoc es creado usando la metodología de desarrollo R.U.P e integra el esquema MDI 829 para permitir seleccionar, evaluar, diseñar, ejecutar, controlar, verificar y obtener documentación referente a pruebas no funcionales. En el ámbito general del proyecto, el esquema MDI 829 es integrado en todo el proceso de desarrollo del software y la pasantía tiene por objetivo apreciar su ejecución en la fase de transición. Por lo tanto, la aplicación metodológica se basa en ocho pasos del esquema MDI 829, los cuales se enfocan en pruebas de rendimiento, seguridad y disponibilidad, sin perder las relaciones de las características de la metodología R.U.P y las características del estándar IEEE 829 cuyo propósito es especificar el conjunto de documentos utilizados para las pruebas en diez etapas o niveles de pruebas de software. 5.1 Políticas de privacidad La mayor parte de documentación generada en el proyecto del sistema de gestión documental Sigedoc de la Contraloría General de la República de Colombia corresponde a actividades de desarrollo intelectual y tecnológico, restringiendo su uso confidencial exclusivamente al personal directamente implicado en la dirección del proyecto, es por esta causa que las condiciones que regulan el acceso a los contenidos, los servicios y los productos creados intelectualmente, intangiblemente, material o física, sólo son posibles de obtener bajo condiciones extraordinarias. Por lo tanto se presentarán rasgos generales de muchos de los documentos, artefactos e incluso algunas herramientas que fueron creadas o utilizadas para probar funcional y no funcionalmente el sistema de gestión documental, siendo esta política un limitante en la presentación de resultados a los jurados, público académico y general.

53

5.2 Planteamientos para el desarrollo metodológico 5.2.1 Planteamiento de la metodología R.U.P Esta metodología se utiliza en el proyecto Sigedoc porque cumple con las pautas necesarias para el correcto desarrollo de este tipo de software, ya que formaliza procesos de análisis, diseño, implementación y documentación de sistemas orientados a objetos, apoyados en metodologías internas que son adaptables a diferentes necesidades. Al usar eficientemente el lenguaje unificado de modelado UML a través de la metodología R.U.P, se permite gestionar por cada vista y por la capa del negocio los diferentes artefactos y documentos dispuestos por el esquema MID 829. Es por esta razón que Sigedoc utiliza UML 4+1*para describir la arquitectura del software en cinco vistas UML. Se decidió escoger este tipo de lenguaje de modelado porque se aplica a todos los procesos del proyecto ayudando así a “presentar un modelo que describe la arquitectura de un sistema de software intensivo, basado en el uso de múltiples y concurrentes vistas” para los “stakeholder’s”, manejando de manera separada los requerimientos funcionales y no funcionales de la aplicación para así aplicarlos a las pruebas no funcionales. La Figura 8 presenta la vista arquitectural aplicada al sistema de gestión documental Sigedoc.

*UML 4+1: lenguaje unificado de modelado 4+1, o en ingles The “4+1” View Model of Software

Architecture (8).

54

Fuente (9) basado en (8). UML 4+1 es una de las ayudas y colaboraciones más importantes en el tratamiento y la organización de la documentación para pruebas, puesto que cada una de las vistas indicadas y mencionadas en el siguiente párrafo ayudaron con la correcta interpretación y alcance de las prueba ejecutadas. La descripción de cada vista está contenida en el artefacto “Documento de arquitectura y estructurado UML 4+1 V4” entregada a la CGR que contiene la siguiente información:

- Vista Lógica (en inglés “Logical View”): presenta el modelo de clases más utilizadas en el software y el modelo entidad – relación para la base de datos.

- Vista de Procesos (en inglés “Process View.”): Vista cuyo énfasis es el modelo de concurrencia y sincronización, el “lenguaje” por decirse de manera íntegra es visual y es similar a los diagramas de flujo pero con la gran diferencia que su notación es BPMN sobre actividades propias del negocio.

- Vista de Desarrollo (en inglés “Development View”): Esta vista es la organización estática del software en su entorno de desarrollo. Aquí se

Figura 8. Modelo de la vista arquitectural 4+1 en sigedoc.

VISTA LOGICA

• Usuario final • Usuario funcional

VISTA DESARROLLO

• Arquitectos • Desarrolladores • Administradores

software

VISTA DE PROCESOS

• Integradores

VISTA FISICA

• Ingenieros de sistemas, de infraestructura y de comunicaciones

ESCENARIOS • Sistema

• Ambiente

55

presentan los componentes de la aplicación. Las librerías, componentes, .ear, .jar, .war,..etc. fueron dispuestas según las pruebas a realizar.

- Vista Física (en inglés “Physical View”): Modelo de correspondencia software - hardware (aspectos de distribución en máquinas, por ejemplo)

- Vista de escenario (en inglés “Scenarios”): Es descrita por medio de los casos de uso de la aplicación general del sistema de gestión documental.

R.U.P se articula con el estándar IEEE 829 cuando aplica los principios de enfoque a la calidad y demostración de valor iterativamente, pues lo utiliza como un apoyo y mecanismo para evaluar la calidad del sistema en cada etapa iterada. El recuadro verde inscrito en la Figura 9 presenta 3 iteraciones o ciclos que se realizaron para la fase de transición respecto al flujo de trabajo prueba en el proyecto, aplicando los principios de calidad y valor iterativo de R.U.P. Se tiene en cuenta que este trabajo se delimita a la fase de transición pues es una de las etapas en la cual el pasante tiene un nivel adecuado de madurez respecto a las pruebas realizadas en las anteriores fases, por tanto los artefactos y procesos realizados en esta última fase contemplan un desarrollo con más habilidades sobre los procesos y herramientas utilizadas, siendo también más objetivo e imparcial con las pruebas no funcionales.

56

Fuente Figure 16-1.An iteration in the inception phase.Chapter 16.(1).

Figura 9.Estructura general de flujos de trabajo R.U.P.

57

5.2.2 Planteamiento Norma IEEE 829 Según el índice …del numeral 4.1 Norma IEEE 829… la norma IEEE 829 tiene como fin la documentación de pruebas de software y sistema, labor que permite controlar la fase de pruebas durante la construcción de software. Los tópicos*fundamentales tratados en las pruebas no funcionales radican en tres principios descritos en el propósito de la norma IEEE829. Así, el primer tópico será definir tareas de prueba, entradas y salidas requeridas, el segundo tópico es identificar las tareas de prueba mínimas recomendadas correspondientes a los niveles de integridad, y el tercero será definir el uso y el contenido de la documentación de prueba relacionada. Esta catalogación de tópicos compone y forja el planteamiento general del ciclo de pruebas no funcionales del esquema MID 829, adoptando y refiriendo cuatro fases que se tendrán que relacionar en el ciclo de pruebas y son:

- Planeación.

- Diseño.

- Procedimiento de casos de prueba y ejecución.

- Reporte de resultados.

Tal como se indica en los propósitos de la norma, existe un modo de proceder con la documentación suministrada en cada uno de los tópicos indicados, como también niveles de integridad asociados a los mismos, los cuales observados en el contexto administrativo permitieron establecer la amplitud y la profundidad de las pruebas. Otra particular característica ofrecida por la norma IEEE 829 es la compatibilidad que tiene con los diferentes modelos de desarrollo de software y con sus respectivos procesos del ciclo de vida de los mismos; por tanto esta norma fue una “herramienta” adecuada en la colaboración con los procesos de calidad de software. Cabe incluir que la norma IEEE 829 es utilizada para conseguir dos propósitos esenciales en el proyecto; el primero, como ya se mencionó es utilizar la norma

*Los tópicos se presentan en el numeral…4.1.1… del propósito de la norma IEEE 289.

58

como un procedimiento para ayudar a validar si el software de gestión documental en el contexto de pruebas no funcionales cumple con requisitos de calidad y el segundo propósito es respaldar y soportar las pruebas no funcionales realizadas al software con todos los artefactos fruto de labores de involucrar el estándar. Una de las condiciones básicas para utilizar la norma IEEE 829 fue comprender cómo están descritos los procesos de pruebas de éste estándar pues es necesario identificar las similitudes con la fase de prueba del modelo de desarrollo R.U.P y así utilizar los documentos o artefactos definidos en la norma. Las actividades se definen en el estándar IEEE 829 como un conjunto de tareas relacionadas y agrupadas con un fin en común, ayudar en la ejecución de un proceso. Es así que cada uno de los procesos descritos en la norma (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”) tienen su respectiva actividad de pruebas y estos a su vez tiene tareas específicas y concretas según el proceso relacionado. El proceso del ciclo de vida del software descrito en esta norma que más se relaciona con la fase de transición en el modelo de desarrollo R.U.P es el que concierne al proceso denominado Desarrollo, el cual contiene actividades y tareas consistentes del grupo de desarrollo. Las actividades de este proceso están organizadas de la siguiente manera: concepto, requerimientos, diseño, implementación, pruebas e instalación/comprobación, y a su vez tienen actividades de prueba que son tareas específicas dentro del marco del proceso. Como bien se menciona en los objetivos del esquema y en la descripción de la figura asociada a los procesos y actividades (ver la Figura 4 descriptiva para el proceso de pruebas del numeral 4.1.6). Las actividades de pruebas asociadas a la actividad Prueba serán los insumos para poner en funcionamiento los niveles de integridad y para desarrollar las pruebas con su documentación. Para tener una referencia más entendible al interior del equipo de pruebas, los procesos principales del ciclo de vida, tales como Adquisición, Suministro, Desarrollo y Operación podrán ser llamados macro procesos*y a las actividades como micro procesos, pues según la experiencia de trabajo, al poder segmentar en partes más digeribles los macro procesos, las tareas de gran magnitud se

*Macro proceso: todos los procesos del ciclo de vida del software pueden ser denominados macro procesos, y

estos a su vez abarcan micro procesos. Así, el proceso prueba es considerado un proceso macro. Ver

referencia de macro procesos en la fuente bibliográfica número (14).

59

convertirán en labores más sencillas y eficientes, y esto tendrá como posible resultado verificaciones más claras de las especificaciones que se solicitan por parte del cliente. 5.2.2.1 Nivel de integridad aplicado. Con el anterior enfoque contextual de proceso de pruebas y de actividades de pruebas, se introduce el concepto de nivel de integridad. …tal como se menciona en el numeral 4.1.3.1… el nivel de integridad tiene como propósito estructurar y establecer la amplitud y la profundidad de la prueba e indica la importancia relativa del software respecto a una característica que será evaluada y medida. En la Tabla 1 … Tabla del numeral 4.1… se presenta la especificación del nivel de integridad el cual fue diseñado para evaluar características de atributos funcionales y no funcionales, por tanto el esquema presentado es un esquema de integridad basado en riesgos, así las tablas: Tabla 1, Tabla 2, Tabla 3, Tabla 4 y Tabla 5, representan la descripción que relaciona los niveles de integridad, las consecuencias y las tareas de prueba mínimas que se deben realizar a cada actividad de prueba según el nivel de integridad asociado. Ahora bien, las características que se necesitan evaluar corresponden a propiedades de desempeño, de continuidad operacional y de seguridad del sistema; por consiguiente, a través de las pruebas no funcionales es posible evaluar estas características, que esencialmente corresponden a una validación de tareas y que son complementadas con la instauración de niveles de integridad del estándar IEEE 829. La Tabla 9 representa desde este momento el punto de partida del esquema de nivel de integridad basado en riesgos, esquema que análogamente indicará cuatro niveles de integridad cuyas descripciones son perfectamente amoldables a los atributos evaluados de los tres tipos de pruebas no funcionales abordados. En consecuencia se tomará como única guía el esquema de nivel de integridad basado en riesgos REDISE* para cada una de las pruebas no funcionales, de tal manera que no será necesario crear los siguientes esquemas para cada prueba:

- Esquema para el nivel de integridad de rendimiento. - Esquema para el nivel de integridad de disponibilidad.

- Esquema para el nivel de integridad de seguridad.

*REDISE: iniciales de referencia a Rendimiento, Disponibilidad y Seguridad.

60

Se conviene plantear un solo esquema para las pruebas no funcionales puesto que pueden evaluar cada prueba con los mismos parámetros de las actividades de prueba y con los niveles de integridad que éstas ofrecen. Tabla 9.Esquema del nivel de integridad basado en riesgos REDISE.

Descripción por tipo de prueba

Rendimiento Disponibilidad Seguridad Nivel

El software necesita tener un desempeño con alta carga, operacional con total disponibilidad y un nivel de seguridad riguroso o se tendrá graves consecuencias (pérdida de vidas, perdida del sistema, daños del ambiente, pérdidas sociales y económicas) si ocurren.

El software necesita tener disponibilidad operacional de continuidad permanente con un nivel soporte las 24 horas los 7 días a la semana durante todo el año o se tendrá graves consecuencias (pérdida de vidas, perdida del sistema, daños del ambiente, pérdidas sociales y económicas) si ocurren.

El software necesita contar con seguridad en Autenticación, Control de acceso, Auditoria, Confidencialidad, Integridad, Disponibilidad y No Repudio a un nivel riguroso o se tendrá graves consecuencias (pérdida de vidas, perdida del sistema, daños del ambiente, pérdidas sociales y económicas) si ocurren.

4

El software necesita desempeñarse con carga escalable, operacional con alta disponibilidad y un nivel de seguridad riguroso o el uso (misión) del software/sistema no será realizable causando serias consecuencias (daños permanentes, mayor degradación del sistema, daño del ambiente, impacto social y económico). Una mitigación completa o parcial a estas consecuencias es posible.

El software necesita tener disponibilidad operacional de continuidad permanente con un nivel soporte las 24 horas los 7 días a la semana durante todo el año, el uso (misión) del software/sistema no será realizable causando serias consecuencias (daños permanentes, mayor degradación del sistema, daño del ambiente, impacto social y económico). Una mitigación completa o parcial a estas consecuencias es posible.

El software necesita contar con seguridad en Autenticación, Control de acceso, Auditoria, Confidencialidad, Integridad, Disponibilidad y No Repudio a un nivel riguroso o el uso (misión) del software/sistema no será realizable causando serias consecuencias (daños permanentes, mayor degradación del sistema, daño del ambiente, impacto social y económico). Una mitigación completa o parcial a estas consecuencias es posible.

3

El software necesita tener un desempeño con alta capacidad, ser operacional con alta disponibilidad y un nivel de seguridad riguroso o estaría destinado a no realizarse y causaría consecuencias menores. Una mitigación completa es posible.

El software necesita tener disponibilidad operacional de continuidad permanente con un nivel soporte las 24 horas los 7 días a la semana durante todo el año o estaría destinado a no realizarse y causaría consecuencias menores. Una mitigación completa es posible.

El software necesita contar con seguridad en Autenticación, Control de acceso, Auditoria, Confidencialidad, Integridad, Disponibilidad y No Repudio a un nivel riguroso o estaría destinado a no realizarse y causaría consecuencias menores. Una mitigación completa es posible.

2

El software necesita desempeñarse con alta capacidad, operacional con alta disponibilidad y un nivel de seguridad riguroso o estaría destinado a no realizarse y causaría consecuencias despreciables. La mitigación no es requerida.

El software necesita tener disponibilidad operacional de continuidad permanente con un nivel soporte las 24 horas los 7 días a la semana durante todo el año o estaría destinado a no realizarse y causaría consecuencias despreciables. La mitigación no es requerida.

El software necesita contar con seguridad en Autenticación, Control de acceso, Auditoria, Confidencialidad, Integridad, Disponibilidad y No Repudio a un nivel riguroso o estaría destinado a no realizarse y causaría consecuencias despreciables. La mitigación no es requerida.

1

Fuente conforme a esquema de riesgos para pruebas no funcionales(9). La Tabla 10 es la referencia del esquema REDISE pero se basa en consecuencias; sin embargo, es la guía que permite iniciar la aplicación del esquema para pruebas.

61

Tabla 10. Esquema del nivel de integridad basado en consecuencias.

Descripción Nivel

El software necesita ejecutarse correctamente o se tendrá graves consecuencias (pérdida de vidas, perdida del sistema, daños del ambiente, pérdidas sociales y económicas) si ocurren.

4

El software necesita ejecutarse correctamente o el uso (misión) del software/sistema no será realizable causando serias consecuencias (daños permanentes, mayor degradación del sistema, daño del ambiente, impacto social y económico). Una mitigación completa o parcial a estas consecuencias es posible.

3

El software necesita ejecutarse correctamente o estaría destinado a no realizarse y causaría consecuencias menores. Una mitigación completa es posible.

2

El software necesita ejecutarse correctamente o estaría destinado a no realizarse y causaría consecuencias despreciables. La mitigación no es requerida.

1

Fuente Table 1 — Consequence-based integrity level scheme, p.14.(1). 5.2.3 Planteamiento pruebas no funcionales Dado que las pruebas no funcionales se relacionan directamente con los requerimientos no funcionales, es necesario comunicar que “En el proceso de elicitación* los Requerimientos No Funcionales (RNF) (9) pueden presentarse junto a los requerimientos funcionales a través de diversas formas: políticas de negocio o políticas externas al negocio, paradigmas de programación, tecnología de autorización, infraestructura existente, etc. La dificultad para identificar, evaluar y tipificar los RNF se relaciona con la falta de consenso en definiciones y esquemas de clasificación en la literatura existente sobre ellos. Esta dificultad se agrava si el enfoque utilizado para de desarrollo de la aplicación web carece de lineamientos, técnicas y/o herramientas específicas de soporte al proceso de requerimientos.” (10).

*Elicitación: por definición (30) “se tiene que es el traspaso en forma fluida de información de un programa a

otro sin dificultades. Atrapar o inducir información de un programa a otro, o, de un usuario a otro en forma

entendible”.

62

La empresa desarrolladora del sistema de gestión documental Sigedoc se encarga de traducir los documentos de requerimientos proporcionados por el cliente y organizarlos en la estructura funcional y no funcional para así abordar técnicamente cada ítem asociado a las pruebas no funcionales. Una vez realizado el filtro y obtenida toda la información concerniente al requisito no funcional que se requiere probar, la empresa inicia modelos y métricas internas de calidad sobre las pruebas. El objetivo de cada prueba no funcional fue establecer y evaluar propiedades de fiabilidad, eficiencia, seguridad, integridad, interoperabilidad y usabilidad del sistema, por tanto se plantea inicialmente abordarlas alineándolas con los mismos propósitos de las guías de la metodología del estándar, con el fin de controlarlas. Seguido se realiza verificación en conjunto con el cliente sobre el concepto general de las mismas, con el fin que se clarifique el cometido y se comprenda el alcance que tendrán en el sistema, para que no se sobrestimen o subestimen tiempos, trabajos y recursos. En tanto, antes de iniciar con cada una de las fases de las pruebas no funcionales es necesario realizar un diagnóstico del alcance general de las pruebas y convenir el tipo de resultado que se desea, tareas necesarias para fijar resultados concretos sin ambigüedades tanto en el planteamiento de las condiciones solicitadas en los requerimientos como en las soluciones. Confirmado y convenido los conceptos y alcances, se detalla cada prueba no funcional con sus objetivos y cualidades específicas de acuerdo a las características o atributos del software o el sistema a evaluar. El anterior planteamiento traerá consigo que los objetivos inicialmente descritos por el cliente tendrán que ser ajustados a cada tipo de prueba y por ende tendrán que ser presentados como anotaciones o como sugerencias concretas al cliente sobre las apreciaciones que se realizaron a cada requisito solicitado. Las pautas necesarias para llevar a cabo la puesta en marcha de cada prueba en particular corresponden a tres tareas descritas en la Figura 10. La primera labor consiste en realizar una gestión particular a cada prueba, lo que implica crear por cada una un programa interno. La segunda labor es cuantificar el número de tareas por programa interno, para validar la estimación del alcance de la prueba, esta cuantificación se realiza por los objetivos y características del sistema. La tercera labor es identificar las etapas de realización de pruebas de cada programa interno, las cuales se definen de la Tabla11.

63

Fuente (7). Tabla 11. Definición de programa interno de pruebas.

Etapa de prueba Descripción

Levantamiento de información y documentación de pruebas

Información detallada solo para el ámbito de la prueba.

Planeación de prueba Indica de manera operacional, la forma de cómo se establecerá y se definirá el alcance de las pruebas técnicas, identificando factores de riesgo, características del sistema, arquitectura física y lógica, y herramientas necesarias.

Diseño de prueba Establece el paso a paso en detalle de la prueba técnica a realizar, presentando configuraciones, permisos, datos y resultados esperados.

Ejecución de prueba Se verifican datos y se ejecuta prueba, se registran resultados.

Resultados de prueba Se organiza y se analiza resultados.

Fuente (7).

5.2.4 Planteamiento y ejecución del esquema MDI 829

Figura 10. Gestión de pruebas no funcionales

64

La ejecución del esquema MDI 829 tiene por tarea principal diseñar y ejecutar pruebas no funcionales en el sistema de gestión documental, sin perder la esencia de las pruebas cuyo enfoque plantea inducir a que el sistema falle. El esquema MDI 829 desarrolla como tema principal el hilado y entramado de las pruebas no funcionales con la metodología de desarrollo de software R.U.P y la documentación del estándar IEEE829, ésta asociación es vista como la ejecución del esquema MDI 829 por medio de una serie de procesos denominados pasos del esquema, los cuales permiten entretejer el tipo específico de prueba no funcional que se tratara en cada una de las fases y ciclos de las etapas de desarrollo del software de gestión documental. Uno de los efectos directos y provechosos de poner en marcha el esquema, es obtener información, documentación y artefactos de manera eficaz, permanente, precisa y rápida de las pruebas realizadas al sistema, de modo que al evaluar las características particulares del software tales como: seguridad, desempeño y disponibilidad por medio del esquema, se asocia una serie de procesos que indican como se tiene que abordar, iniciar, ejecutar y finalizar las pruebas relacionadas en el esquema MDI 829 de acuerdo al tipo de característica buscada en el sistema, lo que involucra directamente el tema de calidad de software, pues sigue un procedimiento metódico con respuestas y resultados a cada uno de los pasos tratados por cada tipo de prueba. 5.2.4.1 Recomendaciones previas. La utilización del esquema tiene un mayor impacto funcional si sobre la empresa u organización en la cual se va implementar, tiene personal con el conocimiento por lo menos académicamente entendido sobre la metodología de desarrollo en la cual se basa el proyecto, considerando también que se tenga un mínimo de conocimiento del estándar IEEE 829, o en su defecto personal que lo conozca y lo pueda difundir sin ningún inconveniente a los directamente involucrados en las pruebas del sistema. Las implicaciones funcionales generarán entonces el cometido de dar un enfoque más gerencial sobre la información obtenida de las pruebas realizadas sobre el software. Es preciso presentar las siguientes recomendaciones sugeridas por el esquema MDI 829, las cuales son en realidad un croquis de las necesidades más relevantes del sistema para poder funcionar correctamente, el esbozo permite entonces poder dimensionar hasta cierto punto cómo realizar una verificación de las características inmediatas y necesarias del sistema para iniciar las pruebas no funcionales o funcionales del sistema, cuyo beneficio será permitir tener una consecución de pruebas de manera uniforme y sin fluctuaciones graves que retrasen tiempos planeados y proyectados al cronograma del proyecto.

65

Las verificaciones no formales del bosquejo son las siguientes:

- Información de todas las posibles herramientas que se utilizarán en la ejecución de pruebas desde diferentes perspectivas técnicas y funcionales.

- Realizar verificación de los alcances y limitaciones de las herramientas escogidas.

- Indagación de metodologías ágiles para realizar pruebas de humo encaminadas a la verificación física y lógica de las herramientas seleccionadas.

- Analizar el alcance y el límite de la prueba a realizar para no contar con pronósticos imprecisos de lo que es o no posible realizar.

- Verificar las interfaces, los componentes y los subsistemas que se relacionan con la prueba.

- Indagación en detalle del ámbito* de ejecución dentro y fuera del sistema, esto incluye el ambiente emulado del sistema en producción.

- Usuarios involucrados.

- Estructura física o lógica que soporta el proyecto.

- Configuraciones técnicas.

- Confirmación de tiempos o cronologías para la implementación y ejecución del esquema de acuerdo a las pruebas a realizar.

*Ámbito: la real academia española define al ámbito como el contorno o perímetro de un espacio o lugar. En

el ámbito informático se describe como el entorno interno o externo con el cual intercambia información o

datos de manera directa o indirecta de acuerdo a la ejecución de un sistema o funcionalidad del mismo.

66

Se enfatiza realizar a modo de verificación las anteriores actividades por el simple motivo que en muchas ocasiones estos ítems pueden omitirse al verse insignificantes sin una evaluación completa, razón por la cual si quedan desatendidos posteriormente pueden convertirse en fallos perjudiciales al proyecto. Entre los factores más dominantes que pueden inducir este tipo de fallos pueden ser: falta de tiempo, escasa planeación, falta de experiencia en especificación de detalles, desconocimiento total de la lógica del negocio, omisión de recursos y recomendación de tareas a terceros sin experiencia. El fin de realizar las verificaciones es evitar presiones críticas respecto a tiempos de entrega para resultados de las ejecuciones de las pruebas previstas y tratadas en el esquema MID 829, seleccionar las herramientas para pruebas técnicas correctamente y determinar el alcance de lo que se realizará con las pruebas. La recomendación es optada porque permite acelerar procesos de comunicación entre el cliente y el oferente, y porque en estos procesos de comunicación surgen sugerencias, aprobaciones sobre herramientas o licencias, concesiones de espacios adecuados para pruebas, avalados para realizar las actividades funcionales con usuarios o con personas relacionadas con el proyecto, y en fin diferentes actividades que pueden no estar descritas en los documentos formales que se presentarán a lo largo del diseño y ejecución de las pruebas. 5.2.4.2 Esquema en fases. Se tiene en entonces un quehacer según la fase en la cual se pretenda introducir el esquema. Por tanto se describe tres casos particulares para integrar el esquema a la metodología de desarrollo y son: 5.2.4.3 Caso ideal. El caso ideal, es una de las mejores prácticas ya que se introduce el esquema en la fase inicio de la metodología de desarrollo R.U.P y por tanto se tiene la ayuda en profundidad del estándar IEEE 829 respecto a la gestión de información en el proyecto.

67

5.2.4.4 Caso de inmediatez. Para el caso en que el esquema ingrese de manera repentina en un proyecto en marcha, el comportamiento del esquema tendrá dependencia inmediata con la fase o ciclo actual, y se verá forzado a tomar los principios que gobiernan en la metodología utilizada. Este caso se podría denominar caso de inmediatez porque su documentación se rige por pautas guiadas de la metodología de desarrollo. 5.2.4.5 Caso dual. En este caso puntual el esquema MDI 829 tiene la característica del caso ideal y del caso de inmediatez. El caso ideal indica que el esquema inicia en la primera fase del proyecto del sistema de gestión documental según la metodología de desarrollo R.U.P y se mantiene durante todo el proyecto. La característica del caso de inmediatez se presenta en el momento que solo se aborda una fase específica, en este caso es la última fase de la metodología de desarrollo fase transición. El motivo principal por el cual toma el nombre de caso dual es porque el proyecto inicia con el esquema, se mantiene durante todas las fases de desarrollo de software, pero solo se demuestra su efectividad a cabalidad con la documentación en la última fase del proyecto. Para aclarar el tema, la vinculación laboral del estudiante fue un factor importante en la implementación del esquema al proyecto, dado que durante su permanencia en la empresa, ésta le permitió generar y gestionar el esquema en su totalidad, para una vez evaluado y aceptado en la empresa se pudiese ejecutar con todas las características formales de un trabajo de grado en el último periodo del proyecto de gestión documental agregando la experiencia reflejada sobre el manejo del mismo en el lapso de tiempo correspondiente al tiempo estipulado del proyecto de grado tipo pasantía. Como conclusión el esquema MDI 829 se aplicó sólo a la fase transición en el contexto del proyecto de grado para el estudiante pasante, y se enfocó en dos iteraciones de fase. Así, las actividades o procedimientos que se realicen en esta última fase, tendrán documentos y artefactos de las tres pruebas no funcionales, los cuales serán documentos oficiales, certificados y avalados por la empresa que los gestiona, teniendo en cuenta que la implementación del esquema trae consigo trabajos realizados procedimentalmente con documentos fuente de las pruebas no funcionales, por tanto los documentos que se mencionan en los siguientes pasos del esquema, serán para el cliente descripciones de documentación técnica puntual que le permitirá tener soporte digital o físico de la globalidad de las pruebas no funcionales en el proyecto.

68

Se tiene en consideración que una de las grandes cualidades del esquema es proporcionar resultados eficientes con los recursos suministrados y a la mano, lo que se traduce en resultados con información liviana y completa por cada uno de los ciclos o iteraciones de fase de pruebas del proyecto en marcha. Este argumento se defiende con el hecho de que toda la información de las pruebas siempre será soportada con documentación, artefactos o cualquier tipo de medio informativo dirigido directamente al involucrado y firmado por el autor responsable, y con información del estado actual en cada entrega. Uno de los resultados de la evolución del esquema es el mejoramiento de las técnicas utilizadas por el mismo, como por ejemplo la técnica de mapeo de artefactos utilizada recursivamente para trazar la bitácora a los documentos entregados con información que vincula e incluye la relación de las personas o recursos implicados en la gestión, creación, modificación, entrega y eliminación de los mismos, todo con el fin de seguir un control más riguroso del líder de pruebas y que ayuda a no sobrecargar a personal no involucrado con información que no le corresponde directamente. La fase de transición obtuvo la información detallada de cada tipo de prueba no funcional realizada, junto con los artefactos vinculados a las mismas y dirigidos solo a los “stakeholder’s” que le ofician, de hecho tendrán tareas puntuales según su ámbito de trabajo. Se describe entonces todos los “stakeholder´s” involucrados en el proyecto del sistema de gestión documental para la etapa de transición: Directores de proyecto, probadores “tester’s” funcionales y no funcionales, desarrolladores, arquitectos, usuarios finales, cliente, documentadores, capacitadores y coordinadores. 5.2.4.6 Gestión de artefactos y niveles de integridad en el esquema. De acuerdo a la Figura 3…del numeral 4.1.6… del estándar IEEE 829, la gestión de documentos y artefactos se realiza en tres pautas globales definidas así: - Preparación de las pruebas.

- Ejecución de las pruebas.

- Finalización de las pruebas. En lo respecto al marco de actividades en los cuales se agruparía los diferentes artefactos o resultados para las pautas de preparación, ejecución y finalización de las pruebas no funcionales es necesario asociar cada uno de los índices de las Tablas 12, 13 y 14 con los Nombres de Nivel de las Tablas 24, 25 y 26 de integridad de las pruebas …Tablas del numeral 5.2.4.8.4…

Estas pautas tienen asociado un conjunto de niveles que permiten indicar en un orden consecutivo la documentación o artefactos a utilizar.

69

La organización de las tres pautas globales encierra una serie de niveles, documentación y artefactos descritos a continuación. 5.2.4.6.1 Preparación de las pruebas. Esta serie involucra cinco tipos de niveles definidos y descritos en la Tabla 12. Tabla 12. Pauta 1. Preparación de pruebas.

Índice Descripción

MTP Plan Maestro de pruebas o Master Test Plan

LTP Nivel de plan de Prueba o Level Test Plan

LTD Nivel de diseño de prueba o Level Test Design

LTC Nivel de especificación de Casos de prueba o Level Test Case

LTPr Nivel de procedimiento de prueba o Level Test Procedure

Fuente tomada de (1) 6. Test documentation content selection process. p 30.

5.2.4.6.2 Ejecución de las pruebas. La segunda serie involucra tres tipos de niveles descritos en la Tabla 13. Tabla 13. Pauta 2. Ejecución de pruebas.


LTL Nivel de registro de prueba o Level Test Log

AR Nivel de notificación de incidentes o Anomal and Report

LITSR Nivel Informe provisional de estado de la prueba o level Interim Test Status Report

Fuente tomada de (1) 6. Test documentation content selection process. p 30.

70

5.2.4.6.3 Finalización de las pruebas. La tercera serie involucra dos tipos de niveles descritos en la Tabla 14.

Tabla 14.Pauta 3. Finalización de pruebas.


LTR Nivel de informe de la prueba o Level Test Report

MTR Informe de prueba maestro o Master Test Report

Fuente tomada de (1) 6. Test documentation content selection process. p 30. La organización, selección, clasificación y agrupación de los niveles de pruebas trae como beneficio permitir definir un orden en la gestión de la documentación para cada una de las pruebas realizadas. De hecho, la norma IEEE 829 agrupa estos documentos en conjuntos específicos asociados a un nivel de integridad y los relaciona directamente con la característica o atributo que será probado en el sistema, la Tabla 15 presenta todos los documentos definidos en las pautas de preparación, ejecución y finalización de las pruebas con su respectivo nivel de integridad asociado.

71

Tabla 15.Documentos por nivel de integridad.

Fuente Table 2 ⎯Test documentation mapped to integrity levels for development page. 16.(1). 5.2.4.7 Esquemas del nivel de integridad con amplitud y profundidad. Una vez identificados los documentos necesarios de prueba en cada pauta, se correlacionan los documentos en la Tabla 15, asociando y definiendo el nivel de integridad de las tres pruebas no funcionales y por último, el esquema MID 829 evalúa para cada prueba el alcance de las mismas a través de dos factores importantes …como bien se definen en el numeral 4.1.3… , el primer factor es confirmar la amplitud de la pruebas y el segundo limitar la profundidad de las mismas, por lo cual estas dos tareas definen la cantidad, la calidad y el esfuerzo dedicado a cada tipo de prueba realizada al software de gestión documental.

Integrity level Example test documentation Id

4 Catastrophic Master Test Plan MTP

Level Test Plan (Component, Component Integration, System, Acceptance) LTP

Level Test Design (Component, Component Integration, System, Acceptance) LTD

Level Test Case (Component, Component Integration, System, Acceptance) LTC

Level Test Procedure (Component, Component Integration, System, Acceptance) LTPr

Level Test Log (Component, Component Integration, System, Acceptance) LTL

Anomaly Report AR

Level Interim Test Status Report (Component, Component Integration, System, Acceptance) LITSR

Level Test Report (Component, Component Integration, System, Acceptance) LTR

Master Test Report MTR

3 Critical Master Test Plan MTP

Level Test Plan (Component, Component Integration, System, Acceptance) LTP


Level Test Case (Component, Component Integration, System, Acceptance) LTC



Anomaly Report AR



Master Test Report MTR

2 Marginal Level Test Plan (Component, Component Integration, System, Acceptance) LTP


Level Tests Case (Component, Component Integration, System, Acceptance) LTC



Anomaly Report AR



1 Negligible Level Test Plan (Component Integration, System) LTP

Level Test Design (Component Integration, System) LTD

Level Test Case (Component Integration, System) LTC

Level Test Procedure (Component Integration, System,) LTPr

Level Test Log (Component Integration, System) LTL

Anomaly Report (Component Integration, System) AR

Level Test Report (Component Integration, System) LTR

72

Se describe en más detalle que el factor de amplitud implica extensión, cantidad o dilatación de la tarea o tareas a realizar y como profundidad a la atención, cuidado y rigor sobre la tarea o tareas de la prueba. En este orden de ideas se puede establecer que la relación entre la amplitud y la profundidad da como resultado un nivel de trabajo ponderado respecto al esfuerzo, tiempo y recursos dedicados a evaluar características del software. Con el anterior principio el grupo de pruebas establece criterios propios y presenta en la Tabla 16 el rango y la descripción que permite medir el trabajo ponderado por medio de un indicador de este esfuerzo. En este punto se evalúan tres factores críticos e importantes para cada prueba no funcional, el primero es sin duda el nivel de integridad en completitud del tipo de prueba, cuya labor permite seleccionar, organizar y delimitar toda la documentación y todos los artefactos relacionados con las mismas, el segundo factor es el nivel de trabajo ponderado de amplitud que consiste en apreciar y consolidar que tan extenso es el trabajo atribuido a cada una de las actividades de las pruebas, lo que incluye planeación, tiempos, recursos y documentación asociada. El último factor es el nivel de trabajo ponderado de profundidad que implica un nivel de detalle riguroso y delicado sobre el alcance técnico. Validado el nivel de integridad de cada prueba no funcional, se puede proseguir a establecer la plantilla esquemática que incluye el nivel de integridad, y trabajo ponderado de amplitud y profundidad que aplica a pruebas de rendimiento, de disponibilidad y pruebas de seguridad. Por tanto, es necesario aclarar que los datos que conforman los indicadores tanto para el nivel de profundidad como de amplitud, son estimados y puntualizados por los mismos probadores “Testers” basados en la experiencia. La Tabla 17será la guía representativa de la plantilla esquemática referente al nivel de integridad y trabajo ponderado a usar en todas las pruebas. Tabla 16. Rango de peso real de trabajo para amplitud y profundidad.

Rango Descripción

1 Insignificante

2 Bajo

3 Medio

4 Moderado

5 Alto

Fuente propia (1).

73

Tabla 17. Esquema del Nivel de integridad por amplitud y profundidad.

Nivel de integridad 1/2/3/4

Pauta N° Índice Descripción Amplitud Profundidad

Pre

par

ació

n

1 LTD Nivel de diseño de prueba o Level Test Design 1 2

2 LTC Nivel de especificación de Casos de prueba o Level Test Case 3 4

3 LTD Nivel de diseño de prueba o Level Test Design -1 -1

4 LTC Nivel de especificación de Casos de prueba o Level Test Case 1 2

5 LTPr Nivel de procedimiento de prueba o Level Test Procedure 1 2

Ejec

uci

ón

6 LTL Nivel de registro de prueba o Level Test Log 1 2

7 AR Nivel de notificación de incidentes o AnomalyReport 2 3

8 LITSR Nivel Informe provisional de estado de la prueba o levelInterim Test Status Report 4 5

Fin

aliz

ació

n

9 LTR Nivel de informe de la prueba o Level Test Report 3 4

10 MTR Informe de prueba maestro o Master Test Report 5 2

Fuente (1). La plantilla del esquema del nivel de integridad por amplitud y profundidad puede verse gráficamente en la figura radial para pruebas no funcionales presente en el ejemplo de la Figura 11.

Agrupación de niveles por pauta

Valor de los niveles de integridad: 1.Despreciable, 2.Marginal, 3.Crítica, 4.Catastrófico

El valor -1 indica que el nivel no aplica para la prueba (este valor depende del nivel de integridad de la prueba)

Nivel del documento cuya existencia depende de la evaluación del grupo de testing según MID 829

Los cinco posibles valores del nivel amplitud y profundidad corresponden a los siguientes valores:

1.insignificante, 2.bajo, 3.medio, 4.moderado, 5.alto.

74

Fuente (1). Conforme al número de pruebas no funcionales a realizar, se tendrán 3 tablas esquemáticas, cada una de ellas analizadas y evaluadas en amplitud y profundidad por el grupo de pruebas. Así, las tablas en mención y su correspondiente figura radial son las que se construyen con datos en detalle en el cuarto paso del esquema; por tanto, es necesario remitirse al final del numeral 6.2.4.5.4 donde se presentan las siguientes tablas y figuras:

- Tabla 27 y Figura 19, presenta los niveles y documentos seleccionados para las pruebas de rendimiento.

- Tabla 28 y Figura 20, presenta los niveles y los documentos para las pruebas de disponibilidad.

- Tabla 29 y Figura 21, presenta los niveles y documentos que le corresponden a las pruebas de seguridad.

Figura 11. Nivel de integridad radial por prueba no funcional.

75

Es de señalar que la profundización en la información presentada por cada nivel de pruebas es realizada exclusivamente en la fase de transición; sin embargo, es conveniente mencionar que mientras el sistema cambiaba entre fases, en la fase de construcción se exigieron nuevos requerimientos por parte del cliente, los cuales tenían un alto riesgo en el proyecto debido a su cronograma rígido por cada fase, como por ejemplo: en el inicio de la fase de transición, mientras se realizaba el desarrollo de operaciones establecidas hubo la necesidad de incluir e instaurar requerimientos exigidos por el cliente en la fase de construcción; por tanto, los cambios se tuvieron que ver reflejados en todos los procesos internos de cada una de las pruebas no funcionales, lo anterior debido a que los escenarios cambiaban en un gran porcentaje, por ende era completamente necesario acondicionar y modificar las nuevas características de las pruebas no funcionales, dando como resultado actualizaciones en los documentos ya diseñados y difundidos. Como nota adicional, se entiende que en la fase de construcción es donde se establecen las pautas generales de las pruebas funcionales y no funcionales ya que estas deben de ejecutarse de acuerdo a los requerimientos impuestos, se considera entonces que en esta fase se realizan los prototipos y los diseños del sistema final, finiquitando el mejor diseño presentado al cliente, quien lo valida en el cumplimiento con sus expectativas. Siendo así que, en uno de los últimos prototipos ya certificados, cuando se realizaba pruebas de integración y pruebas de aceptación, el sistema sufrió pequeños cambios que perjudicaban de igual manera las pruebas no funcionales debido a que se encontraron errores funcionales inducidos por los nuevos requerimientos solicitados, confirmando así que fue completamente ineludible realizar un recorrido por toda la documentación realizada de las pruebas no funcionales.

76

5.2.4.8 Pasos del esquema. Estratégicamente las pautas definidas para las pruebas no funcionales están descritas en el orden metódico de la Figura12. Figura 12. Pasos generales del esquema.

Paso 1. Identificar el estado del proyecto por fases. Fase 1: Inicio. Fase 2: Elaboración.

Fase 3: Construcción. Fase 4: Transición.

Paso2. Identificar iteración o iteraciones de fase. Paso 3. Obtener examen previo informativo de pruebas. Paso 4. Crear estrategia. Paso 5. Aplicar control. Paso 6. Encajar. Paso 7. Verificar, validar e inspeccionar. Paso 8. Evaluación y ejecución del tipo de prueba.

De esta manera, a continuación se definen en detalle cada uno de los pasos descritos en la anterior figura, también se agrega el tipo de labor realizada por el pasante y los resultados obtenidos.

77

5.2.4.8.1 Paso1. Identificar el estado del proyecto. Para poder identificar el estado del proyecto es necesario conocer e identificar en el modelo de proceso unificado de rational R.U.P todas las fases que lo comprenden, de esta manera verificar la evolución de las pruebas que se han realizado y las que se han de realizar, también conocer los procesos puntuales en los que se tiene que realizar mayor esfuerzos, validar tiempos a favor o en contra respecto al cronograma general proyectado y en especial los tiempos dispuestos a la fase de transición.

La Figura13 presenta la interacción de cada fase y las iteraciones internas de cada una, completando así un ciclo.

Fuente (1). Cada una de las fases presentadas en la anterior figura describe iteraciones globales que son tratadas en relación con las pruebas funcionales y no funcionales.

Figura 13. Perspectiva en Tiempo de R.U.P.

78

5.2.4.8.1.1 Fase 1: Inicio. El propósito de esta fase consiste en validar que los stakeholder’s estén de acuerdo con el propósito y dirección del proyecto, con el dominio del problema, el plan general del proyecto y con los riesgo del mismo.

Objetivos de la fase Los objetivos principales de esta fase se describieron con el hito denominado “objetivo del ciclo de vida” y se especifica en los siguientes criterios definidos para el sistema de gestión documental: - Entendimiento integral y completo del sistema. La experiencia en el

desarrollo de otras aplicaciones también enfatizadas en la gestión documental permitió tener un conocimiento técnico y conceptual muy fuerte para abordar nuevos requisitos específicos de la herramienta. Por este hecho se recoge información de los otros sistemas que la compañía ha creado y así reutilizar y optimizar recursos, código y procedimientos de desarrollo.

- Acatamiento de costos y presupuestos asignados al proyecto en virtud al

alcance general. La tarea de verificar los presupuestos básicos para el inicio del proyecto la realiza el director de proyecto, porque es la persona directamente interesada en conocer en el contexto empresarial los factores de éxito del sistema, además evalúa los ingresos esperados, el reconocimiento del mercado, la retribución económica, etc.

- Reglas del negocio. Aquí se describió el modelo de negocio, se aprobó el modelo básico de casos de uso, se verificó los requisitos básicos del sistema, se estableció el plan general del proyecto, se evalúo y describió el proyecto con las características principales y finalmente se incluyeron los riesgos y limitaciones del mismo.

- Revelar la mayor funcionalidad del sistema.

- Abarcar los requerimientos funcionales y no funcionales del sistema. Se pone en contextualización que el sistema de gestión documental se creó con las pautas internas de acuerdo al futuro interés del cliente antes de las posibles alternativas de negocio como licitaciones públicas u ofertas de compra. Así las normas de funcionamiento del software Sigedoc son cabalmente asociadas a los estándares archivísticos que gobiernan la gestión documental.

79

Labores realizadas En esta instancia se aborda el ámbito de negocio de la fase de inicio realizando las siguientes tareas necesarias: - Contextualización lógica de negocio.

- Lectura de documentación de gestión documental incluida normas

regulatorias del proceso archivístico.

- Contextualización de metodología de desarrollo R.U.P aplicada en el proyecto.

- Lectura de estándares internos de la empresa.

- Lectura y organización de requerimientos no funcionales.

- Contextualización con cliente sobre nuevas exigencias del negocio para adaptación a funcionalidades ya establecidas.

- Validación de los cambios a realizar sobre software Sigedoc y su impacto sobre las pruebas no funcionales.

Resultados obtenidos La siguiente lista presenta los resultados más importantes realizados. - Contextualización de la lógica de negocio concentrada en tareas

relacionadas con procesos de negocio de ámbito archivístico.

- Investigación y lectura de normas regulatorias archivísticas de repositorio interno de la empresa desarrolladora del proyecto. Ver Tabla 18.

80

Tabla 18. Documentación normas regulatorias archivísticas.

Documento, comunicado o norma

Descripción

Acuerdo 060 de 2001. Comunicación oficial del Archivo general de la república de Colombia que define las pautas para la administración de las comunicaciones oficiales en las entidades públicas y las privadas.

Acuerdo 042 de 2002. Criterios para la organización de los archivos de gestión en las entidades públicas y las privadas que cumplen funciones públicas, se regula el Inventario Único Documental y se desarrollan los artículos 21, 22, 23 y 26 de la Ley General de Archivos 594 de 2000.

Anexo 1 de la circular No. 004 de 2010.

Estándares mínimos a considerar en la implementación de sistemas para la gestión de documentos electrónicos de archivo.

Decreto número 1151 de 2008.

Por el cual se establecen los lineamientos generales de la Estrategia de Gobierno en Línea de la República de Colombia, se reglamenta parcialmente la Ley 962 de 2005, y se dictan otras disposiciones.

ISAD(11) Madrid 2000. Norma Internacional General de Descripción Archivística.

ISO 23081-2(12) Procesos de gestión de documentos. Metadatos para la gestión de documentos.

Ley 527(13) de 1999. Reglamentación del acceso y uso de los mensajes de datos, del comercio electrónico y de las firmas digitales, y se establecen las entidades de certificación.

Ley 594(13) Ley general de Archivos. Objeto, ámbito de aplicación, definiciones fundamentales y principios generales.

Norma ISO 15489 1(15)

Directrices de la política de gestión documental. Primera norma ISO elaborada para la gestión integral de los sistemas archivísticos, los archivos y los documentos de archivo.

Norma técnica colombiana NTC 15489 (15)

Norma general para la descripción archivística, describe archivos, catalogación, descripción archivística, archivo histórico, descripción documental. ( núcleo del software Sigedoc )

Manual de procedimientos de gestión documental, archivo y correspondencia

*

Políticas que normalizan y racionalizan la producción y el manejo de los documentos logrando regularizar el flujo de los mismos. Procedimientos administrativos y técnicos que garanticen la conservación y uso del patrimonio documental de la Contraloría General de la República. Pautas necesarias para una adecuada gestión de la documentación producida y recibida por la Contraloría General de la República en desarrollo de sus funciones. Importancia del acervo documental en los funcionarios, con sensibilidad de responsabilidad en el manejo de los documentos.

*El Manual de procedimiento en la CGR es el documento que identifica el proceso administrar

documentación, y está dentro del macro proceso gestión de recursos de la entidad. Este documento fue

obtenido del sistema integrado de gestión y control de calidad (SIGCC) de CGR, código documento GRE-

81115-M-01, versión 1.0, 03 mayo de 2010.

81

- Contextualización normatividad interna con metodología de desarrollo R.U.P, adecuación a la organización de documentación en el repositorio de proyecto, buenas prácticas de desarrollo con conceptualización Java EE 6* y pruebas de software.

- La información de los criterios de aceptación proporcionada por el cliente se filtra y se organiza en requerimientos funcionales y no funcionales, y se relaciona en las fases del proyecto, como también los actores que les compete dichas labores, por ejemplo, se relaciona el número de requerimiento funcional o no funcional en una de las cuatro fases y se asocia al actor o conjunto de actores agrupados en usuario funcional o director de proyecto al lado de la empresa desarrolladora o directores de proyecto cliente. En la fase de transición se confirma que el sistema cumpla con estos criterios y esto se realiza a través del Anexo 9†.

- Se establece internamente el impacto en las pruebas no funcionales y se

indican los riesgos no materializados que generarían los cambios críticos del sistema una vez finalice la construcción del mismo.

- Se estima y se aceptan tiempos definidos para pruebas no funcionales y los recursos necesarios para los proyectos internos de cada prueba, realizando cronogramas de gestión para estos y asociándolos directamente a pruebas de seguridad, pruebas de disponibilidad y pruebas de rendimiento.

- Cada uno de los guiones de prueba, es decir el artefacto funcional o de ejecución solo se crea o actualiza en caso de existir en el paso 7 …del numeral 5.2.4.8.7… , sin embargo el nivel LTC contiene estos guiones.

- Los entregables agrupados en el marco general documental se empiezan a referenciar en la Tabla 35 …del numeral 5.2.4.9… de acuerdo al nivel que posea la actividad, por ejemplo los documentos del nivel MTP tienen por actividad generar el plan de pruebas maestro.

*Se utiliza Java EE 6(23) por ser plataforma de programación edición empresarial, en ingles Java Platform

Enterprise Edition, y está acorde con la buenas practicas al interior de la empresa en buenas practicas. †Anexo 9: nombre estricto del documento de requerimientos funcionales y no funcionales que el sistema debe

de cumplir. No se adiciona en este proyecto por la restricción de confidencialidad de información dictada en

el numeral 5.1 sin embargo se presenta un resumen grafico de los principales requisitos solicitados (Vease

Figura 24).

82

5.2.4.8.1.2 Fase 2: Elaboración. Cuando se definió el análisis del dominio del problema, esta fase instauró la arquitectura del proyecto, verificó en su totalidad los casos de uso que se aplican al sistema y los actores involucrados.

Objetivos de la fase Gestionar casos de uso con “stakeholder’s”.

Labores realizadas Las labores directas realizadas con ayuda de otras áreas de la empresa generaron los siguientes resultados: - Generación del modelo general de casos de uso, con identificación y

descripción de módulos con sus respectivos diagramas y actores del sistema de gestión documental Sigedoc.

- Descripción de la arquitectura de software. Se generaron artefactos de la

arquitectura física y lógica del sistema. - Comprobación de la correcta relación entre las diferentes capas* del

sistema, la arquitectura, los componentes del software y los casos de uso, con el fin de confirmar la consistencia de la arquitectura diseñada y su futuro acople a la infraestructura del cliente. El beneficio obtenido será el de obtener una aplicación escalable la cual estará preparada para hacerse más grande sin perder calidad en los servicios ofrecidos.

- Análisis de riesgos del proyecto respecto a las reglas del negocio. - Plan general del desarrollo del proyecto, con detalle de implementación y

precisión de tareas por recursos. - Identificación de riesgos con sus correspondientes técnicas de mitigación.

Así, según la lista de los diferentes tipos† de riesgos establecidos o descubiertos se describe el plan de mitigación para cada uno, lo que incluye

*Capas: En sentido estricto, las capas analizadas en el sistema Sigedoc son capa del cliente, capa web

frontend, capa de negocio o backend y capa de persistencia, cada una de ellas asociadas directamente con la

tecnología J2EE. †El Tipo de riesgo puede referirse al ámbito lógico, físico, de costos, de tiempos, de recursos humanos o de

tecnología.

83

diferentes técnicas y diferentes herramientas para prevención de que los mismos se vean materializados, envolviendo pros o contras en la utilización de estas herramientas.

- Manuales preliminares para usuario y cliente. Se produce guías cortas,

documentos de resumen que presentan las funcionalidades más generales del software y permite establecer en los clientes el concepto fundamental del software que se irá a implementar. Los manuales preliminares en muchos casos solo sirven para guiar al usuario y al cliente en sus actividades de prueba externa del software y por tanto no son documentos estrictamente estandarizados pues el interés es cumplir con ayudar a usuarios funcionales y al cliente a cumplir con tareas que están asociadas a funcionalidades del sistema. Muchos de los manuales solo servirán para esta fase pues posteriormente y al final solo será necesario entregar documentos aprobados según lo establecido en los requerimientos y según los criterios de aceptación del cliente.

- Organización y gestión de requerimientos funcionales y no funcionales. Esta

información se descompone a partir del documento general el cual incluye toda una lista de requerimientos que deben ser cumplidos en el sistema, la lista organizada de cada tipo de requerimiento será llevada a nivel de detalle para poder cumplir con la verificación por parte del cliente.

Para los primeros tres puntos del anterior párrafo, los diferentes artefactos obtenidos fueron creados y diseñados en la herramienta libre StarUml (16) gracias a la facilidad de uso, soporte y especificaciones técnicas que la distinguían al momento de compararla con otras herramientas para el mismo fin, éste software permitió una creación ágil y eficiente de entregables.

Resultados obtenidos Las tareas encomendadas al estudiante en esta fase ayudaron en la realización y seguimientos de muchos de los puntos anteriormente expuestos, obteniendo el siguiente resultado a conformidad de sus labores y contextualizado en los requisitos de las pruebas no funcionales.

- De los casos de uso realizados, se seleccionaron los posibles escenarios que tenían un gran impacto en las pruebas de rendimiento según los usuarios reales que navegan en la aplicación de manera concurrente.

- De acuerdo a la infraestructura del sistema Sigedoc, se emularon las

condiciones reales de la solución a entregar en el ambiente de pruebas. Lo que permitió indicar para la prueba de disponibilidad los diferentes focos

84

o puntos de control sobre los cuales se pudo monitorear e instalar herramientas para verificar la continuidad operacional de la aplicación.

- Se utilizó el modelo UML 4+1 para validar la correcta relación entre capas

del sistema, arquitectura física y lógica, componentes del software, casos de uso y procesos, con el fin de asegurar que las pruebas no funcionales pudieran seguir ejecutándose sin miedo a que alguna de las anteriores vistas modificaran los escenarios de las pruebas, y así continuar con la planificación de cada una de ellas en el sistema.

- Por cada prueba no funcional se relacionó en la documentación las respectivas métricas a evaluar y por consiguiente los riesgos inherentes a cada prueba.

- De acuerdo al plan general del desarrollo del proyecto, se entrega estimación de tiempos, recursos y cronograma de ejecuciones para pruebas no funcionales sin el detalle de implementación.

- En concordancia con los requisitos no funcionales, se trató en su mayoría el tema de seguridad con las pruebas de seguridad tabulando cada uno de los requisitos exigidos por el cliente con cada especificación de seguridad exigida.

- Se colaboró en la realización de manuales preliminares para usuario y cliente.

- Se organizó todos los requerimientos funcionales y no funcionales, acogiendo y asumiendo total responsabilidad por los últimos con ayuda del esquema MID 829.

Tanto para las pruebas de disponibilidad, rendimiento y seguridad, se verificó y confirmó la existencia de las tareas realizadas, referencias o indicaciones en los respectivos documentos de plan de pruebas ya establecidas. La evidencia de estos resultados se presentan en la Figura 16 …ver página 102…

85

5.2.4.8.1.3 Fase 3: Construcción. La fase de construcción es la más fuertemente trabajadas en el proyecto debido a que fue la fase en la cual se materializó el sistema y lo volvió funcional con las nuevas reglas de negocio.

Objetivos de la fase Al ser Sigedoc en una aplicación a la medida, establece que la empresa desarrolladora indiscutiblemente tuvo que adicionar requerimientos específicos de acuerdo a las necesidades del modelo del negocio archivístico para la Contraloría General de la Republica. La inclusión de las nuevas especificaciones y requerimientos trajo consigo tener que acoplar código certificado en los prototipos funcionales creados por la empresa desarrolladora a la lógica de negocio de las nuevas funcionalidades de la respectiva aplicación creada, esto implicó agregar y validar nuevas especificaciones con una correcta implementación la cual se planificó realizar en 2 iteraciones sobre esta fase, y asoció los casos de uso específicos de cada uno de los nuevos módulos del sistema a los que ya existían para los prototipos certificados del mismo ámbito archivístico, por tanto fue necesario actualizar y crear los diseños generales de las pruebas no funcionales.

Labores realizadas Dentro de las tareas específicas cubiertas por esta etapa fueron: - Verificar todos los requisitos del nuevo software Sigedoc, en base a

prototipos robustos ya creados en la empresa y con el mismo ámbito funcional de gestión de documentación.

- Verificación del diseño y desarrollo general de los casos de uso.

- Validación de pruebas funcionales y no funcionales realizadas a las primeras versiones o “releases”* del sistema.

- Validación y certificación de pruebas unitarias.

- Validación y certificación de la base de datos con sus correspondientes diagramas ER†.

*Un release o en español liberación, es la publicación o lanzamiento de un prototipo funcional y operacional

del sistema. †Un ER toma su nombre de las iniciales del modelo Entidad Relación.

86

- Se realizó el diccionario de datos y documentación asociada a la base de datos.

- Envío de módulos a área de validación y certificación de código fuente.

- Aseguramiento en la configuración de módulos de integración.

Resultados obtenidos Las tareas puntuales realizadas en esta fase fueron: - Para los requerimientos nuevos del sistema Sigedoc, en las dos iteraciones

de esta fase se realizaron pruebas alfa para cada módulo y sub módulo específico de las áreas funcionales del sistema. Se indica a las pruebas alfa como ayuda para permitir que el usuario funcional en conjunto con el desarrollador como observador en un entorno controlado realizara pruebas vigiladas para identificar de manera más precisa y coherente los nuevos requisitos funcionales que la entidad demandaba al sistema, como también descubrir errores en las mismas pruebas. Las pruebas alfa se mejoraron al intercalarlas con pruebas beta, lo que permitió avanzar eficazmente en el cumplimiento de los criterios de aceptación* descritos por la CGR.

- Se realizó el análisis de los casos de uso existentes y se crearon los nuevos escenarios propios para el nuevo sistema obteniendo así todos los diseños de los casos de uso según la especificación de la lógica de negocio correspondientes a la gestión archivística en la CGR.

- Como proveedores del sistema, se justificó y se presentó los cambios realizados al software en varios despliegues en el ambiente de preproducción. Las características funcionales y no funcionales adicionadas al sistema fueron probadas regularmente con el cliente a través de una lista† de control y verificación realizada entre el personal funcional oferente y cliente, esta lista contiene el estado y la descripción de las validaciones inmediatas a realizar según los cambios funcionalidades del sistema, vinculados con documentos o artefactos según el tipo de funcionalidad o prueba realizada.

*Los criterios de aceptación fueron el mecanismo para aceptar pruebas, definidas por el cliente las cuales le

permitieron validar internamente los requisitos solicitados a su proveedor de software. †Lista de gran utilidad para soporte del documento guía llamado: “criterios de aceptación”, gestionada en

tiempo real por medio de la herramienta web de servicio de backup remoto dropbox (25).

87

- Por cada una de las iteraciones en la fase de construcción se realizan

varias pruebas de regresión para cada grupo de funcionalidades implementadas y aceptadas por el cliente. Este procedimiento permitió validar que las versiones entregadas eran completamente estables de acuerdo a los rediseños realizados a ciertas partes del sistema, además permitió controlar, probar y verificar con usuarios funcionales de la CGR el correcto funcionamiento y el comportamiento deseado del software. Antes de las pruebas de regresión se colaboraba en crear escenarios para las pruebas unitarias, y una vez ejecutadas exitosamente se daba paso a continuar con los despliegues solicitados, paso seguido pruebas de regresión dependiendo de los módulos afectados. Cada tipo de prueba se validaba en el ambiente emulado de la compañía oferente y posterior en las instalaciones de la CGR teniendo en cuenta los factores internos de la infraestructura.

- En la actualización de la base de datos para los nuevos módulos y sub

módulos del sistema, se operó con reglas de validación de base de datos que permitieron validar los datos de todos los campos nuevos. Estas reglas de validación limitó y controló la mayoría de información que los usuarios finales pueden ingresar en los nuevos campos. El enfoque de la validación puede observarse en la Tabla 19.

Tabla 19. Reglas de control a la base de datos.

Control Descripción

Propiedades de la tabla Obligatoriedad de los datos.

Tipo de dato Establecer el tipo de dato para cada campo de las tablas diseñadas.

Tamaños de campos Establecimiento de longitudes exactas de cada campo.

Mínimos y máximos Regla que establece en valor mínimo y el máximo de cada tipo de dato según propósito del mismo.

Máscaras Son definidas como máscaras de entrada que permite validar datos determinados para cada campo.

Indexación Referencias específicas que permiten hacer más rápida las consultas, se aplica a campos determinados y relacionados con la lógica de este negocio.

Integridad referencial Validación de registros relacionados dependientes.

Claves Evitar duplicidad de registros.

Carga de datos Migración de datos básicos para funcionamiento del sistema.

Parametrización del sistema

Es la correcta configuración de información que permite al sistema dinamizar contenido estático que presenta al usuario por medio de parámetros de entrada.

Formas normales y las no normales.

Reglas establecidas en las políticas de desarrollo de aplicaciones de la empresa proveedora.

Modelo relacional. Actualización y diseño del modelo Entidad Relación.

88

- Creación de diccionario de datos.

- De las secciones de módulos y sub módulos desarrollados del sistema, se

envió compendio de archivos construidos para su certificación por directores de proyecto y jefes de desarrollo.

- Las pruebas integrales son tomadas a cargo por el director de proyecto y a la vez jefe de desarrollo de software para validar con pruebas de caja blanca y pruebas de regresión los bloques que permiten la integración de interfaces del sistema a los componentes o módulos que tiene actualmente operando varios sistemas asociados de la CGR. Una de estas tareas incluía módulos de autenticación, autorización e ingreso sin repudio a los usuarios finales al sistema por medio de Single Sign-on*(17) y ldap (18)†.

Estas tareas permiten al pasante conocer el detalle funcional de cada módulo del sistema con el fin de alistar entornos estables para la ejecución pruebas no funcionales.

*SSO es el procedimiento de autenticación que habilita al usuario para acceder a varios sistemas con una sola

instancia de identificación. †LDAP es el protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y

distribuido para buscar diversa información en un entorno de red.

89

5.2.4.8.1.4 Fase 4: Transición. En el momento en que el estudiante realiza su vinculación laboral en la empresa desarrolladora del software de gestión documental, éste inicia con labores específicas que inician desde la primera fase de R.U.P, las cuales son encomendadas por su director en jefe del proyecto. Así, de acuerdo a las tareas a realizar, fue necesario enfocar y agrupar ciertas pruebas no funcionales en la fase de transición, guiadas con el esquema MDI 829 con sus 8 pasos que le constituyen. Las actividades y tareas primordiales relacionadas en esta fase constaron esencialmente de la revisión en cada una de las fases del proyecto de todo el tipo de pruebas no funcionales realizadas o pendientes por realizar.

Objetivos de la fase El plan general de la fase de transición fue constituido por las siguientes actividades, de las cuales la mayoría se establecieron en consenso con el cliente en razón de tener una correcta etapa de entregables del sistema y componentes del mismo. Por tanto las actividades correspondientes a esta fase son: - Asegurar disponibilidad del sistema para los usuarios.

- Planear iteraciones para esta fase que permita el seguimiento y control de

las pruebas.

- Pruebas del producto en base a la metodología de desarrollo y a estándares de calidad.

- Realización de ajustes a diseños de pruebas, planes de ejecución, ejecuciones y entregas de resultados, todas para pruebas no funcionales.

- Utilización y pruebas piloto del sistema con retroalimentación de usuarios e ingenieros líderes.

- Depuración de errores por usuarios finales.

- Configuraciones de entornos finales para el sistema en colaboración con la implementación del MDI

- Instalación.

- Validar entregables y tipos de pruebas.

- Validación y cumplimiento de características exigidas del software en las pruebas no funcionales.

90

- Entrega de soportes de las pruebas.

- Evaluación de cumplimiento.

- Control de cambios.

- Confirmación de ciclos adicionales.

- Pruebas beta.

- Integración con otros sistemas.

- Estandarización y parametrización de funciones.

- Capacitación usuarios finales.

- Distribución.

- Consenso con el cliente sobre la certificación del mismo antes de la

liberación.

Labores realizadas según las condiciones de las pruebas no funcionales de seguridad de control de acceso

A nivel de usuario esta prueba consistió en establecer que sólo se permite al actor acceder exclusivamente a las funcionalidades, datos e información, según su perfil, su rol, su autorización y sus permisos asignados.

A nivel de sistema, se validó que el acceso a los usuarios se aplicara a través de módulos específicos para la administración y autorización de mismos.

Ambos niveles implicaron atender con cuidado las tareas relacionadas con la confidencialidad, la integridad, la autenticación y la autorización, evitando y previniendo los accesos no autorizados, accidentales o planeados al sistema. En el paso séptimo del esquema MDI se explican cómo se abordaron estos temas y en el paso ocho la forma como se desarrolla y se pone en práctica el tratamiento de estas tareas. La evidencia de estos resultados se presentan en la Figura 16 …ver página 102…

91

Labores realizadas según las condiciones de las pruebas no funcionales de disponibilidad.

Las condiciones generales de las pruebas de disponibilidad comprendieron específicamente en establecer que se realizaría el monitoreo total al sistema, validando la caída del mismo, su recuperación, guías de acción y políticas de implementación. Aclarando también los criterios de alcance de estas pruebas y las sugerencias de la empresa desarrolladora sobre la recuperación de copias y restauración del sistema, tarea aplicada a los servidores lógicos, físicos, de base de datos, y si es el caso a los ambientes de preproducción. El fin correspondió a proporcionar alta disponibilidad. Remitirse al paso ocho del esquema para su implementación.

Labores realizadas según las condiciones de las pruebas no funcionales de rendimiento.

Verificar la estabilidad y el rendimiento del sistema evaluando en este la capacidad de desempeño por medio de pruebas puntuales de carga, estrés, picos y de resistencia. Los factores evaluados fueron los de dimensionamiento, cuyo interés busca entregar el insumo de cantidad de usuarios que interactuaran con el sistema de manera concurrente o de acuerdo a indicadores de procesos sobre folios o documentos en tiempos determinados. Remitirse al paso ocho para ver el detalle de resultados.

Condiciones generales de las pruebas En la medida que se desarrollaba el paso 1 del esquema MDI, se pudo establecer que era necesario sincronizar las actividades y tareas de las pruebas funcionales y las tres pruebas no funcionales, debido a que en el momento en que se realizó el respectivo análisis de cada tipo de prueba se encontró que para varios casos las pruebas funcionales podían afectar seriamente a las pruebas no funcionales y también que las pruebas no funcionales afectaban a las funcionales en igual medida, por tal motivo se presenta a continuación y en relación a la Tabla 20, las actividades y tareas identificadas para esta relación de pre y post condición entre pruebas del sistema. Actividades de estandarización y parametrización: Para las actividades referentes a estandarización, parametrización, carga y migración de datos, como también parametrización de perfiles de usuarios y pruebas de integración, todas son necesarias realizarlas antes que las pruebas funcionales y con los datos que alimentan al sistema, pues si se realiza y ejecuta primero el sistema arrojaría un alto porcentaje de desviación de los resultados debido a que muchas

92

funcionalidades operan según los parámetros de variables o datos específicos y planificados para operación funcional. La base en la cual se fundamenta esta afirmación radica en que el sistema está desarrollado para trabajar con parámetros iniciales que son proporcionados externamente y es necesario realizar carga de configuración por medio de pruebas no funcionales de rendimiento que genera inyección de cargas de volumen de datos y archivos; y pruebas de integridad de información. Este poblamiento de parámetros de arranque se realiza de manera automática. Las tareas claves a realizar para una correcta ejecución de pruebas funcionales fue la de realizar pruebas de alistamiento que consistían en la preparación de datos y carga de los mismos al sistema. Así, la labor de preparación consistió en hallar, seleccionar, organizar y subir datos al sistema sea por la interfaz web de usuario o a través de procedimientos de inserción de datos por medio del motor de base de datos SQL o por programas similares a un “batch input”* desarrollados solo y específicamente para la aplicación. La actividad de hallar datos consistentes, exactos y precisos residió esencialmente en una labor logística en asocio con el cliente. El desarrollo logístico fue el de encomienda de formatos de datos especiales a diligenciar por los usuarios o ingenieros líderes, variando según los diferentes tópicos del sistema la información contenida como: perfiles de usuarios, permisos, ámbito, restricciones de acceso e información geo departamental entre otros. La migración de datos se realizó desde el repositorio de la empresa oferente. Cuando se trató de imágenes digitales escaneadas de documentación pública o privada, se crearon y habilitaron funcionalidades extraordinarias para realizar cargue masivo, esta funcionalidad radicó en vincular información de archivos planos con imágenes tipo “tiff” guardadas metódicamente por personal diestro en la mecánica archivística física. Para datos de arranque del sistema, se validaron todas las posibles configuraciones de inicio del sistema, validando permisos jerárquicos de datos. Para datos técnicos como unidades de volumen, precio, tiempo, objetos, documentos, mensajes a usuario, palabras en otro idioma y palabras reservadas,

*batch input: es un método confiable y rápido de transferir grandes cantidades de datos por medio de un

programa o proceso que evita la intervención manual. Los datos transferidos los toma el programa de un

conjunto de archivos de datos como entrada, los procesa y produce otro conjunto de archivos de datos de

salida con unas características especiales.

93

se subieron tablas específicas y prediseñadas, consolidadas y probadas con información técnica según el ámbito de negocio archivístico del cliente. Los procesos sobre archivos, documentos y folios de tipo imagen, determinados como cargue masivo, consumían grandes recursos al sistema, así que al ser una tarea que se realizaba una sola vez, se eligió cargarlos en modo batch* debido a que como se mencionaba anteriormente sería una ejecución sin supervisión interactiva o directa del usuario pues al tratarse de una labor repetitiva y tediosa sería muy propensa a errores humanos. Actividades de planes de capacitación: El plan de capacitación de usuarios se realizó por módulo y por procesos relacionados con los sub sistemas creados en la metodología RUP. La capacitación se realizó con la versión alfa del sistema en una prueba piloto la cual se aprovechó para corroborar información contenida de los registros de pruebas no funcionales de desempeño validando cantidad y concurrencia de usuarios, y tiempos de respuesta, pruebas de seguridad con el acceso de usuarios según perfiles y prueba de disponibilidad al trabajar en ambientes de preproducción del cliente. Actividad de documentación técnica: Es requisito entregar documentación técnica de las pruebas no funcionales conforme se entregaban resultados de las pruebas funcionales y pruebas de aceptación a razón que los líderes del proyecto debían conocer la capacidad máxima de usuarios y valores críticos de uso de la aplicación, restricción por módulo, por usuarios y por perfiles de los mismos, como también la arquitectura física y lógica del sistema, servidores, máquinas y herramientas auxiliares, servicios, instalación, configuración y relaciones de la base de datos entre otros factores, todos estos descritos a profundidad en los siguientes pasos del esquema MID 829. En la elaboración de los manuales técnicos se valoró la importancia de los mismos, pues el ejercicio consistía en establecer como guía principal estos manuales para puesta en producción del sistema de gestión documental por los líderes de proyecto en cualquier momento. Así, estas guías técnicas y memorias de capacitación permitían al cliente seguir pasos específicos para su correcta instalación y puesta en marcha evitando en la menor medida la intervención del proveedor.

*Batch o batch processing significa “procesamientos por lotes”, y es un mecanismo para ejecutar tareas o

procesos sobre lotes de archivos.

94

Seguridad: El acceso de las pruebas no funcionales, realizadas en torno a la seguridad sobre usuarios, se prepararon y enfocaron teniendo en cuenta que previamente se tuvo que asegurar por medio de las pruebas funcionales que las configuraciones, parametrización y políticas de seguridad de cuentas de usuarios hubiesen quedado certificadas, este tipo de auditoría se valida con pruebas funcionales de seguridad. Las pruebas no funcionales realizan un “match” o igualación de condiciones de variables respecto a los registros cifrados, codificados y obtenidos con las herramientas olfateadoras* o en inglés “sniffers” y confirman que la información crítica se mantiene a salvo. Actividad de migración: La migración de datos fue una labor importante en el proyecto debido a que la migración de datos de varios sistemas incluyendo el antiguo sistema de correspondencia tenían que ser reconocidos completamente en el nuevo sistema. Esta actividad permitió que los datos antiguos fueran seleccionados y utilizados de manera consistente en la aplicación. La prueba no funcional que relacionada esta actividad fue la de rendimiento, pues con los datos tratados y funcionales se podían replicar y utilizar para crear cargas o despliegues de pruebas. Actividad de soporte: Esta actividad comprendió la puesta en producción del sistema de gestión documental considerando establecer un continuo soporte a los usuarios hasta que estos desarrollen las destrezas necesarias para sentirse a gusto y sin rechazo al uso, ni resistencia. Esta etapa a pesar que no se puede clasificar como una prueba funcional o no funcional, es de gran utilidad pues al obtener los resultados que los usuarios finales realizaron al evaluar al sistema permitió eventualmente detectar falencias que no se trataron, encontraron o comprobaron en las anteriores etapas de pruebas realizadas, sean en las pruebas funcionales o no funcionales. Las anteriores actividades y tareas reflejan los filtros en el documento de aceptación que valida cada una de las características del producto e involucra las tres pruebas no funcionales generales de este proyecto. Al finalizar la primera iteración de la fase de transición se realizó una evaluación para determinar si se cumplió, o no se cumplió con los objetivos planteados, según los resultados los objetivos no cumplidos se retomaron en el segundo ciclo lo más rápido posible y se aseguró una solución efectiva. La Tabla 20 representa la descripción del tipo de pruebas por cada iteración que se realizaron al sistema

* Olfateador o en inglés “snnifer”: es un programa especial que se encarga de capturar tramas de red,

analizando los paquetes obtenidos.

95

teniendo en cuenta las pruebas no funcionales de rendimiento, seguridad y disponibilidad.

Tabla 20. Iteraciones por fase de transición.

Iteración de fase Descripción

Iteración 1 Pruebas de humo y pruebas de regresión.

Iteración 2 Pruebas de regresión y aceptación.

96

Resultados obtenidos En esta fase se definieron tareas macro representadas en dos iteraciones, agrupadas en pruebas funcionales y pruebas no funcionales, con el supuesto que se debe respetar las precondiciones y pos condiciones de todas las pruebas y así establecer el plan general para esta fase, logrando el propósito de asegurar que el software esté disponible para los usuarios finales. En este orden, para lograr este objetivo fue necesario realizar control por medio de trazas de registros con todos los objetivos realizados sobre las actividades materializadas. Ver traza resumida en la Tabla 21. Tabla 21. Actividades materializadas fase de transición.

Actividad materializada Iteración Tipo de prueba

I II Funcional No Funcional

1. Asegurar disponibilidad del sistema para los usuarios. x x

2. Planeación de iteraciones para permitir el seguimiento y control de las pruebas.

x

3. Pruebas del producto en base a la metodología de desarrollo y a estándares de calidad.

x x x x

4. Realización de ajustes a diseños de pruebas, planes de ejecución, ejecuciones y entregas de resultados, todas para pruebas no funcionales.

x x x x

5. Prueba 1 piloto del sistema. x x

6. Prueba 2 piloto del sistema con retroalimentación de usuarios e ingenieros líderes.

x x x x

7. Depuración de errores del sistema por resultados de pruebas.

x x

8. Depuración de errores por usuarios finales. x x

9. Configuraciones de entornos finales para el sistema. (utilización de MDI)

x x x x

10. Instalación. x x x

11. Validar entregables y tipos de pruebas. x x x

12. Validación y cumplimiento de características exigidas del software en las pruebas funcionales.

x x

13. Validación y cumplimiento de características exigidas del software en las pruebas no funcionales.

x x

14. Entrega de soportes de las pruebas. x x

15. Evaluación de cumplimiento funcional. x x

x

16. Evaluación de cumplimiento no funcional. x x x

17. Control de cambios. x

97

Tabla 20 (continuación 1)

Actividad materializada Iteración Tipo de prueba

I II Funcional No

Funcional

18. Confirmación de ciclos (iteraciones) adicionales. x x x

19. Prueba "Beta" del sistema. x x

20. Integración con otros sistemas. x x x

21. Estandarización y parametrización de datos. x x

22. Capacitación usuarios finales. x x

23. Capacitación ingenieros líderes. x x x

24. Distribución. x x x

25. Consenso con el cliente sobre la certificación del software antes de la liberación del mismo.

x x x

26. Carga de datos. x x x x

27. Planes de capacitación. x x

28. Manuales. x x x

29. Parametrización de perfiles de usuarios. x x

30. Migración de datos. x x x

31. Liberación del software. x x x

32. Prueba de integración. x x x

33. Reportes de Pruebas x x x x

34. Informe estado actual del Proyecto x x x x

35. Documentación Técnica x x x

36. Acta de Reuniones x x x x

37. Estado de la Fase x x x x

38. Pruebas de Aceptación x x x x

39. Prueba “Alfa” del sistema x x x

40.Seguimiento y control a pruebas no funcionales x x x

41.Seguimiento y control a pruebas funcionales x x x

Fuente (7) La evidencia de estos resultados se presentan en la Figura 16 …ver página 102…

98

5.2.4.8.2 Paso 2. Identificar iteración o iteraciones de fase. Este paso se encarga de resolver qué cantidad de iteraciones se pueden generar en la fase en la cual se aplique el esquema, seguido se procede a identificar e indagar el detalle funcional de cada iteración con cada nivel de integridad de las pruebas. La identificación de iteraciones permite ajustar los tiempos para cada pauta de cada esquema de nivel de integridad, siendo posible fijar cronogramas determinados para preparación, ejecución y finalización de pruebas, junto con la asociación de documentación y artefactos directamente implicados por cada nivel de integridad.

Objetivos del paso Fijar cronogramas, documentación, recursos, asignar y organizar el tipo de tareas que le corresponderán a cada integrante del grupo de pruebas no funcionales.

Labores y resultados obtenidos Los resultados obtenidos de este paso de identificación fue la organización de tres series globales de artefactos para pruebas no funcionales en dos iteraciones de fase. La Figura 14 presenta la asociación de la fase de transición de la metodología R.U.P con cada uno de los niveles del estándar IEEE 829 y se refleja en parte inferior derecha de la misma denominándose matriz de asociación para pruebas no funcionales de disponibilidad, rendimiento y seguridad. Cuando una prueba cruza e intercepta el esquema general de documentación IEEE 829 se selecciona los niveles que más determinen la prueba, y se indica de este modo confirmando el nivel.

99

Fuente adicional (19)

Figura 14. Matriz de asociación R.U.P con estándar IEEE 829.

100

5.2.4.8.3 Paso 3. Examen previo informativo de pruebas. Examinar por cada fase y por cada iteración revisada un borrador del alcance sobre lo realizado o no realizado en el proyecto respecto a las pruebas técnicas de software. Este proceso permite recoger información de resultados, propuestas, esbozos, documentación estable, anotaciones, cronogramas y demás características con información útil para darle continuidad a las pruebas, crear formatos de seguimiento sobre cambios en los ciclos e iteraciones y formar documentos de contingencia sin protocolos exigentes ni desgastantes que expliquen de manera precisa el núcleo de negocio de cada tipo de prueba tanto en su contexto general como particular y técnico con el objeto de dar una correcta continuación a pruebas críticas. Este examen tiene la cualidad de relacionar estrechamente el contenido estático del flujo de trabajo o “workflow” de R.U.P. (Ver Figura 15) con cada tipo de pruebas no funcionales en la fase de transición. La cantidad de iteraciones que se realizan para cada fase depende necesariamente de la cantidad requerimientos establecidos, complejidad y tamaño del proyecto, tiempo y criticidad del mismo. En la fase de transición se estima inicialmente realizar tres iteraciones; sin embargo, esta determinación dependerá de cómo se analiza el sistema por el director de proyecto; por tanto, cuando se enumere la cantidad de iteraciones de fase requeridas, las pruebas no funcionales se adecuarán a estos ciclos determinados debido a que existe una relación estrecha con los tiempos y cronogramas de estas pruebas.

Objetivos del paso

Resolver y planear adecuadamente la asociación del estándar IEEE 829 en el modelo R.U.P.

Labores y resultados obtenidos A medida que se realizaban, certificaban y aceptaban las pruebas, la segunda iteración no alcanzó a cubrir en el cronograma la totalidad de las tres pruebas no funcionales; por esta razón, se convino finalizar las pruebas pendientes en un plazo de tiempo determinado sin adicionar más iteraciones, así se pudo acordar concluir con las ejecuciones e informes sin afectar otras entregas de versiones actualizadas del sistema. Se indica que hubo la necesidad de gestionar el impacto que generaba las tareas pendientes en la segunda iteración sobre los tiempos estimados del proyecto.

101

En este paso se realizó transferencia de conocimiento técnico al grupo de pruebas respecto a las iteraciones sufridas en el sistema con las pruebas no funcionales, e introdujo la relación con los siguientes cinco pasos restantes del esquema. La comprensión de fondo del propósito y alcance general de todas las pruebas no funcionales se presentó de una manera sencilla en la Figura 16 donde se indicó las relaciones existentes e interacciones entre la metodología R.U.P, el estándar de documentación IEEE 829 y el ciclo de pruebas no funcionales tratadas con el esquema MID 829, con las cuales el pasante o líder de pruebas no funcionales afianzó conocimientos. Figura 15. Metodología R.U.P Fuente Figure 16-1. An iteration in the inception phase. Chapter 16.(19).

102

Fuente (7).

Figura 16. Ciclo general de pruebas no funcionales en MID 829.

Los hipervínculos direccionan a cuatro (4) carpetas: Artefactos de rendimiento, disponibilidad, seguridad y documentación suplementaria.

103

5.2.4.8.4 Paso 4. Estrategia. Como se mencionó en el paso número tres, el pasante o líder de pruebas y el grupo de calidad deben conocer muy bien las pruebas que se están realizando al sistema y también las pruebas que se piensan realizar al mismo, todas estas en referencia a pruebas no funcionales. Por consiguiente, la estrategia de este paso incluye la comprensión del contexto general del ciclo total de las pruebas no funcionales. Este ciclo se compone de cinco procesos que pertenece a los cinco pasos siguientes del esquema y son presentados en la Tabla 22 y en la Figura 17.

Fuente (7). Tabla 22.Descripción pasos de procesos de prueba.

Paso de prueba

Proceso de prueba

Descripción

Paso 5 Control Punto de concentración y monitoreo de procesos de pruebas no funcionales.

Paso 6 Encaje Unión y mezcla del plan de acción de pruebas no funcionales en el programa interno de la metodología de desarrollo.

Paso 7 Preparación Verificación, validación e inspección de los niveles de prueba a aplicar.

Paso 8 Ejecución Evaluación y acción procedimental de las pruebas no funcionales.

Paso 8 Finalización Conclusión y registro de las pruebas no funcionales.

Figura 17 Ciclo pruebas no funcionales.

104

La destreza y la habilidad en determinar el tipo de prioridad de las pruebas no funcionales, la necesidad de recursos y el tiempo para desarrollar las tareas de las mismas, son planeadas en este paso. Por tanto el equipo de trabajo debe concebir la realización de un programa de este tipo de especificación según la criticidad de pruebas, recursos o personas a necesitar y tiempos requeridos para el desarrollo de estas tareas. Continuando en la especificación de este paso, se establece y se define el nivel de integridad general que aplicará a cada tipo de prueba no funcional, teniendo en cuenta el nivel de integridad mencionado en la Tabla 1 …descrito en el numeral 4.1.3.1... . Por otro lado, en este paso también se valida la relación que se crea entre el tipo de actividades de pruebas y las pruebas no funcionales. Así, a partir de la Tabla 5 se crea la Tabla 23, la cual es la guía estructural general de este tipo de asociación, por tanto esta tabla presenta a modo de ejemplo once actividades de pruebas que pueden ser seleccionadas de acuerdo a un tipo de tarea específica, con su correspondiente nivel de integridad. Es de notar que en esta tabla las casillas seleccionadas con la letra “X” están asociadas por defecto a la actividad Pruebas y que las casillas seleccionadas con la letra “A” cuya signatura corresponde a la frase “Adición”, significa que su asociación corresponde con otra actividad diferente a Pruebas, en este caso a la actividad Planeación, la cual se puede identificar en la Figura 18 que contiene todas las actividades para todos los procesos del ciclo de desarrollo de software según la norma IEEE829. En el ejemplo que se presenta en la Tabla 23, se indica cómo es posible activar los formatos y tareas establecidas de un determinado nivel en otra actividad de prueba, por tanto las nuevas relaciones establecidas entre actividades de prueba y procesos del ciclo de vida se crean como un mecanismo de mejoramiento al esquema MID 829 pues cada prueba no funcional requiere contar con mecanismos de desarrollo para el buen procesamiento de las tareas que serán utilizadas en las pruebas. Después de entender la estructura guía de la Tabla 23 se procedió a establecer formalmente las tablas para cada tipo de prueba no funcional con sus respectivas actividades activadas. Estas tablas son: Tabla 24, Tabla 25 y Tabla 26.

105

Tabla 23.Relación de actividades y nivel de integridad.

Fuente (7).

4 3 2 1


Desarrollo

61 Generación reporte prueba Maestra

54 Generación regis tro prueba de s is tema

51 Generación casos de prueba de s is tema

52 Generación diseño de prueba de s is tema

53 Ejecución pruebas de s is tema

42 revis ion plan prueba maestro

41 Generación plan prueba maestro

24 Identi ficar riesgos

23 Identi ficar riesgos de seguridad (prueba)

9 Evaluación (operacional ) de Anomal ia

10 Generación de estado de anomal ia

id Actividades de prueba

A A A AX X X X

A AX X X X

A A A A A A X XX XX X X XA A

Pruebas

nivel de integridad

106

Figura 18. Actividades de procesos por ciclos de desarrollo de software según la norma IEEE829.

FUENTE (7).

107

La estructura de la norma IEEE 829 tiene definido cinco niveles generales de documentos, los cuales se enfocan en una gama específica citada como “gama de niveles de prueba”*la cual comprende de: componentes, integración de componentes, sistemas y aceptación. En este orden de ideas, al relacionar actividades de prueba de otros procesos del ciclo de vida del software para pruebas no funcionales, se encuentra que es necesario incluir este nombre de la gama del nivel de prueba en las nuevas relaciones creadas entre las actividades de prueba y el respectivo proceso del ciclo de vida del software con el objetivo de poder conocer el tipo de comportamiento y alcance que tendrá el nivel de prueba. Continuando con la estructura de la Tabla 8, para tratar de una manera práctica esta nueva asociación entre la gama de nivel de prueba, los indicadores “A” de las nuevas relaciones que existen entre las actividades de pruebas y los procesos de ciclo de vida del software, y los tres tipos de pruebas no funcionales, se tendrá que crear o indicar una tabla o tablas que represente estas asociaciones. En estas tablas correspondientes a las pruebas de disponibilidad, rendimiento y seguridad se tendrá que tener en cuenta el nivel de integridad de cada prueba y las correspondientes modificaciones, actualizaciones o restricciones que se requieran aplicar a las actividades de prueba de acuerdo a los documentos o artefactos que se utilicen en ellas, en tanto el área de calidad y el de pruebas tendrán que trabajar con diferentes gamas de nivel de prueba, así el diseño de esta tabla tendrá que estar bien sustentada pues no se desea tener efectos descontrolados por un incorrecto uso, por ende es necesario justificar correctamente y validar las labores específicas.

Objetivos del paso Entregar indicadores de tiempos estimados, presupuestos de recursos y tiempos de trabajo a su director de proyecto para la elaboración de las pruebas no funcionales, en este caso el pasante cumple el rol de líder en el área de pruebas no funcionales con ayuda, soporte y colaboración total del área de pruebas técnicas y de calidad de la empresa oferente. Otra tarea importante desarrollada, fue crear las tablas de relación de actividades de pruebas y nivel de integridad, cuyo objetivo es relacionar las actividades de

*La gama de nivel solo es utilizada para referirse a las fases de desarrollo de software en el estándar IEEE

829.

108

prueba, los niveles de integridad, los procesos de ciclo de vida del software y la gama del nivel de prueba. Entrando en detalle, se sabe que las pruebas no funcionales están relacionadas básicamente solo con la gama del nivel de prueba denominada sistemas, por tanto al enfatizar que estas pruebas no funcionales pueden establecer relaciones con otras gamas de niveles de prueba, es necesario presentar la nueva asociación en nuevas tablas de actividades de prueba y nivel de integridad. Por esta razón se presenta las actividades de pruebas mínimas de cada nivel de integridad descritas en la Tabla 5, las cuales permitieron armar, analizar, validar y presentar nuevas estructuras de detalle para cada prueba no funcional correspondiente a disponibilidad (Véase tabla 24), rendimiento (Véase tabla 25) y seguridad (Véase Tabla 26), con la anotación que cada tabla tiene los indicadores “A” de las nuevas relaciones entre las actividades de pruebas.

109

Tabla 24. Integridad de pruebas de disponibilidad. Procesos del ciclo de vida: Desarrollo

Actividad: Pruebas

Tabla de integridad: Disponibilidad

Nivel de integridad Aplica

Gama nivel de prueba Id Nivel Nombre Nivel Nombre de actividad en Ingles Id Actividades de prueba 4 3 2 1 si/no

Sistemas 0 N/A Software requirements evaluation for test purposes

49 Evaluación de requerimientos del software para propósitos de prueba

A A A si

Sistemas 0 N/A System requirements review for testability

50 Revisión de requerimientos del sistema para probar

A A si

sistemas 8 MTP Identify Integrity Level 38 Identificar nivel de integridad A A si

sistemas 8 MTP Master Test Plan generation 41 Generación plan prueba maestro A A A A si

Sistemas 9 LTP Scoping the test effort 47 Determinar el alcance del esfuerzo de la prueba A A no

Sistemas 9 LTP System Test Plan generation 55 Generación plan de prueba de sistema A A A A si

Sistemas 10 LTD System Test Design generation 52 Generación diseño de prueba de sistema A A A A si

Sistemas 11 LTC System Test Case generation 51 Generación casos de prueba de sistema A A A A si

Integración componentes

12 LTPr Installation/checkout 26 Instalación/ Verificación

A A A A no

Sistemas 12 LTPr System Test Procedure generation 56 Generación procedimiento de prueba del sistema A A si

Aceptación 12,5 12 LTPr& 13 LTL

Acceptance test execution 4 Ejecución de pruebas de aceptación

X X X no

Sistemas 12,5 12 LTPr& 13 LTL

System test execution 53 Ejecución pruebas de sistema

X X X X si

Integración componentes

13 LTL Installation/checkout report 28 reporte Instalación/Verificación

A A si

Aceptación 14 AR Anomaly Report generation 10 Generación de estado de anomalía X X X X si

Aceptación 14 AR Anomaly (operational) evaluation 9 Evaluación (operacional) de Anomalía A A si

Sistemas 15 LITSR System Interim Test Status Report generation

48 Generación reporte estado de prueba interna del sistema

X X X si

Sistemas 16 LTR Master Test Report generation 61 Generación reporte prueba Maestra A A si

Sistemas 17 MTR Test Traceability Matrix generation 62 Generación matriz de trazabilidad de prueba X X X no

110

Tabla 25. Integridad de pruebas de rendimiento. Procesos del ciclo de vida: Desarrollo

Actividad: Pruebas

Tabla de integridad: Rendimiento

Nivel de

integridad Aplica


Sistemas N/A N/A Software requirements evaluation for test purposes


A A A si

Sistemas N/A N/A System requirements review for testability

50 Revisión de requerimientos del sistema para probar

A A si

sistemas 8 MTP Identify Integrity Level 38 Identificar nivel de integridad A A si

sistemas 8 MTP Master Test Plan generation 41 Generación plan prueba maestro A A A A si

sistemas 8 MTP Master Test Plan revision 42 revisión plan prueba maestro A A A A si

Sistemas 9 LTP Scoping the test effort 47 Determinar el alcance del esfuerzo de la prueba A A si


sistemas 10 LTD Metrics identification 43 Identificación Métricas A A si

Sistemas 10 LTD System Test Design generation 52 Generación diseño de prueba de sistema A A A A si

Sistemas 11 LTC System Test Case generation 51 Generación casos de prueba de sistema A A A A si

Integración componentes 12 LTPr Installation/checkout 26 Instalación/ Verificación A A A A si

Sistemas 12 LTPr System Test Procedure generation 56 Generación procedimiento de prueba del sistema A A si

Sistemas 12 LTPr Test Readiness Review participation 60 Participación en la revisión de preparación de prueba X X si

Sistemas 12,5 12 LTPr& 13 LTL System test execution 53 Ejecución pruebas de sistema X X X X si

Aceptación 12,5 12 LTPr& 13 LTL Acceptance test execution 4 Ejecución de pruebas de aceptación X X X si

Sistemas 13 LTL System Test Log generation 54 Generación registro prueba de sistema X X X X si


Sistemas 15 LITSR System Interim Test Status Report generation

48 Generación reporte estado de prueba interna del sistema

X X X si

Sistemas 16 LTR Operational Test Report generation 45 Generación reporte prueba operacional A A si

Sistemas 16 LTR System Test Report generation 57 Generación reporte prueba de prueba de sistema X X X X si

Sistemas 16 LTR Master Test Report generation 61 Generación reporte prueba Maestra A A si

Sistemas 17 MTR Test Traceability Matrix generation 62 Generación matrix de trazabilidad de prueba X X X si

111

Tabla 26. Integridad de pruebas de seguridad.

Procesos del ciclo de vida: Desarrollo

Actividad: Pruebas

Tabla de integridad: Seguridad

Nivel de

integridad Aplica


Sistemas N/A Software requirements evaluation for test purposes


A A A si

Sistemas N/A System requirements review for testability 50 Revisión de requerimientos del sistema para probar A A si

Sistemas 8 MTP Identify Integrity Level 38 Identificar nivel de integridad A A si

Sistemas 8 MTP Master Test Plan generation 41 Generación plan prueba maestro A A A A si

Integración componentes 9 LTP Identify security issues (test) 23 Identificar riesgos de seguridad (prueba) A A no

Integración componentes 9 LTP Identify risks 24 Identificar riesgos A A A A si

Sistemas 9 LTP Scoping the test effort 47 Determinar el alcance del esfuerzo de la prueba A A A A si


Sistemas 10 LTD System Test Design generation 52 Generación diseño de prueba de sistema A A A A no

Sistemas 11 LTC System Test Case generation 51 Generación casos de prueba de sistema A A si

Integración componentes 12 LTPr Installation/checkout 26 Instalación/ Verificación X X X X si

Sistemas 12 LTPr System Test Procedure generation 56 Generación procedimiento de prueba del sistema X X X si

Aceptación 12,5 12 LTPr& 13 LTL Acceptance test execution 4 Ejecución de pruebas de aceptación X X X X si

Sistemas 12,5 12 LTPr& 13 LTL System test execution 53 Ejecución pruebas de sistema A A si

Sistemas 13 LTL System Test Log generation 54 Generación registro prueba de sistema X X X X si


Sistemas 15 LITSR System Interim Test Status Report generation 48 Generación reporte estado de prueba interna del sistema X X X si

Sistemas 16 LTR System Test Report generation 57 Generación reporte prueba de prueba de sistema A A si

Sistemas 16 LTR Master Test Report generation 61 Generación reporte prueba Maestra X X si

Sistemas 17 MTR Test Traceability Matrix generation 62 Generación matriz de trazabilidad de prueba X X no

112

Es de resaltar que hasta este punto sólo se han especificado los niveles de integridad de cada prueba no funcional, ahora es necesario poner en práctica el valor de la labor real de trabajo aplicado a cada nivel de las actividades de pruebas, por lo tanto esta tarea le corresponde a dos factores importantes denominados amplitud y profundidad, tema que fue tratado previamente …en el numeral 5.2.5.7 Esquemas del nivel de integridad con amplitud y profundidad.. Preparación de las pruebas… donde se indica el rango de peso real de trabajo. El pasante en su gestión propia como líder en pruebas no funcionales se encargó de utilizar como guía la tabla esquemática de nivel de integridad (véase Tabla 17) por amplitud y profundidad, para la elaboración de los esquemas de los niveles de rendimiento, disponibilidad y seguridad, con el objetivo de tener el insumo básico y esencial de su trabajo. Se precisa aquí que se presentan las proyecciones de trabajo para pruebas de rendimiento en la Tabla 27, para pruebas de disponibilidad en la Tabla 28 y para pruebas de seguridad en la Tabla 29, cada una de las anteriores tablas con su correspondiente figura radial, para rendimiento ver Figura 19, para seguridad ver Figura 20 y para disponibilidad ver Figura 21.

Labores y resultados obtenidos Al ser posible comprobar el nivel de integridad respecto a la amplitud y profundidad de las pruebas, se pudieron definir grupo de pruebas, grupo de calidad y grupo de personas encargadas en asumir totalmente la responsabilidad de aplicar o no el respectivo nivel de integridad de las pruebas. Esto se traduce en que la labor principal y específica de este paso consistió en gestionar la correcta forma de implementar la toma de decisiones respecto a trabajo en amplitud y profundidad por prueba no funcional, cuyos factores decisivos son los definidos en el paso 3 del esquema, como por ejemplo la cantidad de iteraciones, la cantidad requerimientos, el tiempo, la complejidad, tamaño y criticidad del proyecto. Así, el grupo de pruebas incluido el pasante validaron las Tablas 27, 28 y 29, dando su voto para establecer la versión final de las mismas y sobre estas trabajar:

113

Tabla 27. Niveles y documentos IEEE829 por pruebas de rendimiento.

Prueba no funcional de rendimiento

Nivel de integridad 3


1.preparación

8 MTP Plan Maestro de pruebas o Master Test Plan 2 4

9 LTP Nivel de plan de Prueba o Level Test Plan 1 3


11 LTC Nivel de especificación de Casos de prueba o Level Test Case

5 2

12 LTPr Nivel de procedimiento de prueba o Level Test Procedure

3 5

2.Ejecución



15 LITSR Nivel Informe provisional de estado de la prueba o levelInterim Test Status Report

2 1

3. Finalización 16 LTR Nivel de informe de la prueba o Level Test Report 2 2

17 MTR Informe de prueba maestro o Master Test Report 1 1

Tabla 28. Niveles y documentos IEEE829 por pruebas de disponibilidad.

Prueba no funcional de disponibilidad



1.preparación





3 4


2 4

2.Ejecución




1 3


17 MTR Informe de prueba maestro o Master Test Report

114

Tabla 29. Niveles y documentos IEEE829 por pruebas de seguridad.

Prueba no funcional de seguridad



1.preparación





2 4


2 5

2.Ejecución




1 2



En este punto es necesario comprender la importancia que tienen las figuras radiales para el esquema MDI 829, por consiguiente se explica su funcionamiento. Desde el centro hacia el exterior se indica el nivel de esfuerzo a realizar en las actividades de prueba por nivel. Se mide de 0 a 5 siendo el nivel 0 nulo y 5 el máximo valor. La figura radial tiene varios ejes, los cuales corresponden a los diez niveles de la norma IEEE 829, más el eje de inicio. Así, el primer eje que corresponde al eje inicio indica que el “Stakeholder” tendrá que comenzar en este punto las actividades de prueba relacionadas con todos los niveles de documentación de la norma IEEE 829. Seguido se presentan dos ejes que corresponden al primer nivel de la norma IEEE 829 denominado 8 MTP, dos ejes para 9 LTP, dos ejes para 10 LTD, dos ejes para 11 LTC, dos ejes para 12 LTPr, dos ejes para 13 LTL, dos ejes para 14 AR, dos ejes para 15 LITSR, dos ejes para 16 LTR, y dos ejes para 17 MTR. Cada par de ejes por nivel presenta cuatro nodos que sirven para indicar la amplitud y la profundidad del nivel en el cual se encuentre el stakeholder de pruebas. En este orden hay una línea consecutiva para el nivel de amplitud y otra para el nivel de profundidad que pueden variar dependiendo del rango de datos inscritos en las Tablas 27, 28 y 29. Como ejemplo para la Figura 19, al evaluar las pruebas de rendimiento en el primer nivel MTP se tiene que los stakeholder´s tienen un mayor grado de Amplitud debido al nivel de esfuerzo ponderado en 4

115

unidades y un menor grado de profundidad según el nivel de esfuerzo ponderado en 2 unidades, esto quiere decir que el enfoque de este nivel no tiene una gran cantidad de actividades, documentos y artefactos a realizar, gestionar y trabajar, sin embargo estas actividades y documentos son de vital importancia pues requieren mucha atención, cuidado y rigor sobre sus tareas. Las gráficas radiales también presentan un nivel de integridad que se basa tanto en la amplitud y profundidad de tareas necesarias a realizar por cada nivel de prueba.

Actividades no ejecutadas Surgió la idea de utilizar la regla de Sturges (20) como modelo estadístico para ayuda en la toma de decisiones en la solicitud de recursos de personal para pruebas. Este modelo establecía diferentes rangos de datos para esta decisión, sin embargo al no contar con el tiempo suficiente para investigación, ni con recursos dé personal dedicado a esta tarea, se decidió no aplicar esta regla estadística y así no afectar otros tiempos críticos en el proyecto. El ejemplo de la regla de Sturges modificada, comprendía en evaluar los requerimientos no funcionales por varias personas con experiencia en pruebas técnicas y en virtud a una serie de parámetros analizados según el tipo específico de las pruebas, el tiempo, prioridad y a la profundidad y cantidad de pruebas, evaluar y comunicar la cantidad de personas que se necesitarían en el proyecto de pruebas no funcionales.

116

Fuente propia (7).

Rango Descripción

0 No aplica en la prueba

1 Insignificante

2 Bajo

3 Medio

4 Moderado

5 Alto

Figura 19. Niveles y documentos IEEE829 por pruebas de rendimiento.

Análisis general de la figura radial de rendimiento19. Amplitud: La actividad para especificar los casos de prueba (LTC) tiene varias tareas e implican varios recursos para cubrir todas las labores requeridas, sin embargo no son tareas de un alto grado de cuidado. Profundidad: La actividad que define el procedimiento de las pruebas (LTPr) requiere de personal calificado pues el cuidado en la realización de los scripts de carga es fundamental.

117

Fuente propia (7).

.

𝑋

Rango Descripción


1 Insignificante

2 Bajo

3 Medio

4 Moderado

5 Alto

Figura 20. Niveles y documentos IEEE829 por pruebas de seguridad.

Análisis general de la figura radial de seguridad 20. Amplitud: Casi todas las actividades no requieren mucho esfuerzo en la cantidad de tareas de un alto grado de cuidado ni tampoco de personal. Esto se debe a que la tecnología utilizada cubre muchos de los requisitos solicitados. Solo es requerido una cantidad media de recursos para diseñar los casos (LTP) y para registrar las ejecuciones (LTL ). Profundidad: La actividad que define el procedimiento de las pruebas (LTPr) requiere de personal calificado pues el cuidado en la realización del tipo de escenarios y herramientas a utilizar es importante.

118

Fuente propia (7).

Figura 21. Niveles y documentos IEEE829 por pruebas de disponibilidad.

Análisis general de la figura radial de disponibilidad 21. Amplitud: La actividad para especificar los casos de prueba (LTC) y la actividad para informe de pruebas (LTR) tiene varias tareas de trabajo continuo pero aceptable. Profundidad: Tanto la actividad para especificar los casos de prueba (LTC) y La actividad de procedimiento de las pruebas (LTPr), requieren de personal con un nivel adecuado de conocimiento en la creación y detalle de los escenarios respecto a la infraestructura y comunicación del sistema.

119

5.2.4.8.5 Paso 5. Control. La tarea principal de este paso comprende en monitorear los pasos 6, 7 y 8, dar continuidad a la ejecución de cada uno de los documentos necesarios para cada tipo de prueba e ir confirmando el inicio, el proceso y finalización de los mismos en el registro de control. El paso de control será el mecanismo por el cual se comprueba e inspecciona que las pruebas del sistema se estén realizando de acuerdo al plan general y al plan particular de las pruebas no funcionales y así guiar operacionalmente todas las actividades de pruebas. Hay que tener en cuenta que este paso liga su operación respecto a los cronogramas establecidos y al recurso o entidad que los hace ejecutar, por tanto es una tarea constante y diaria debido a las revisiones de labores, validación de porcentajes y avances.

Los métodos para poder llevar a cabo el control sobre las pruebas consisten en: - Agenda de reuniones periódicas con directores de proyecto y cliente.

- Actualizar documentación.

- Presentar informes de avances a los interesados.

- Recoger informes de las pruebas ejecutadas.

- Dar indicaciones sobre el inicio, pausa y finalización de las actividades de

pruebas por cada nivel. Las reuniones periódicas avalan los tiempos establecidos para las pruebas y el tipo de resultado que se requieren obtener de las mismas. La documentación y los informes de avance son soportados según las versiones sobre las pruebas no funcionales y no sobre las fases del proyecto dado que las pruebas también tienen fases concretas en su desarrollo, como por ejemplo: pruebas alpha, pruebas de humo, pruebas de sanidad, pruebas de regresión, pruebas beta y pruebas de aceptación entre otras, son mencionadas aquí porque en relación a los ciclos del desarrollo del software pueden existir altas posibilidades de realizar cambios en la presentación o en inglés “look and feel” o “front end”, o cambios en la estructura funcional de la aplicación dado las características del sistema o back-end. Los anteriores factores también son decisivos al momento de controlar las pruebas puesto que si estos llegan a materializarse con mucha frecuencia, el impacto en las fases de pruebas internas para las pruebas no funcionales pueden verse afectados críticamente, como también los cronogramas planeados al sistema. El control de estado sobre la documentación se basa en la sección 8.1.1 de la norma IEEE 829, pues ahí se indica cómo utilizar las versiones en los documentos, de aquí se tomó como referencia cuatro estados generales que son:

120

borrador, revisado, corregido y final. Las subversiones se generan de acuerdo a cambios que se realizan sobre las versiones generales. Por el anterior motivo, el control de versiones sobre los documentos creados para pruebas no funcionales es independiente a cada iteración de cada fase o a cada ciclo del desarrollo del proyecto, y se considera así porque el software puede tener relativamente muchas versiones y sub-versiones, y además porque son conceptos muy diferentes. Para ámbitos inmediatos, un porcentaje considerable en este paso de control de las pruebas se hace en convenio con el cliente CGR, debido a que existen asociaciones de pruebas funcionales con pruebas no funcionales que podría generar inconvenientes a la hora de ejecutarlas asincrónicamente, pues cada prueba no funcional no necesita cruzar con los tiempos de ejecución de las pruebas funcionales para no alterar los registros y malinterpretar la información obtenida. Se sincroniza entonces en este paso todos los documentos del esquema y se inicia con una primera tarea de verificación de los requisitos según el anexo 9*. Como anotación general para las pruebas funcionales, estas fueron ejecutadas antes de iniciar con las pruebas no funcionales, llevando un control del histórico de pruebas realizadas a la fecha, de acuerdo a las pruebas alfa y a las pruebas beta del sistema con el fin de proporcionar las primeras entregas al informe de seguimiento en la CGR en base a las pruebas no funcionales.

Objetivos Generar la continuidad a los distintos documentos para las tres pruebas no funcionales del sistema de gestión documental en base al esquema MDI 829, llevando un control sobre las mismas.

Resultados obtenidos Para llevar el control de las pruebas, fue necesario conocer el rol de cada tipo de documentación para cada prueba, y establecer el lineamiento que se consideró útil en la continuidad de la documentación. Así, el rol de cada prueba fue armada y estructurada según una lista de documentos (Véase Tabla 30), la cual se basa en el ejemplo de la tabla que se generó en la II sección de la Figura 6 …del numeral 4.4.7…

*Anexo 9 es el documento de requerimientos funcionales y no funcionales que el sistema debe de cumplir.

121

Tabla 30. Artefactos documento de pruebas no funcionales.

Índice Documentos y artefactos de actividades

1 Plan general de pruebas no funcionales

Plan general de pruebas de disponibilidad

Plan general de pruebas de rendimiento

Plan general de pruebas de seguridad

Entrega de informes parciales y totales

2 Plan general de pruebas no funcionales o plan maestro

Revisión plan de prueba maestro de rendimiento

3 Propuesta GESDOC

Documento licitación (página 13)

4 Anexo 9

Anexo 9 basado en requerimientos funcionales y no funcionales

5 Proyección de pruebas

Proyección de alcance pruebas de seguridad

Proyección de alcance pruebas de rendimiento

6 Pruebas de diseño

Prueba de diseño para pruebas de disponibilidad

Prueba de diseño para pruebas de rendimiento

Prueba de diseño para pruebas de seguridad


7 Plan de pruebas de nivel de prueba no funcional

Plan de pruebas de nivel de prueba no funcional disponibilidad

Plan de pruebas de nivel de prueba no funcional rendimiento

Plan de pruebas de nivel de prueba no funcional seguridad

8 Planeación de prueba

Diseño y creación de métricas de pruebas de rendimiento por módulos y usuarios concurrentes.

9 Especificación casos de prueba

Especificación casos de prueba de disponibilidad

Especificación casos de prueba de rendimiento

Especificación casos de prueba de seguridad


122


10 Procedimiento de especificación casos de prueba de disponibilidad

prueba de monitoreo

pruebas de recuperación ante caídas

pruebas de recuperación de copias y restauración

11 Procedimiento de especificación casos de prueba de rendimiento

prueba de carga y rendimiento

prueba de estrés

pruebas de picos

12 Procedimiento de especificación casos de prueba de seguridad

prueba de confidencialidad

pruebas de integridad

pruebas de autenticación

pruebas de autorización

13 Instalación herramientas

Instalación herramientas de monitoreo

Instalación herramientas de rendimiento

Instalación herramientas de seguridad

Reporte de instalación y verificación de herramientas de disponibilidad.

Reporte de instalación y verificación de herramientas de rendimiento.

Reporte de instalación y verificación de herramientas de seguridad.

14 Plan procedimental

Plan procedimental pruebas de Disponibilidad

Plan procedimental pruebas de Seguridad

Plan procedimental pruebas de Rendimiento

15 Ajustes y calibración

Ajuste y calibración pruebas de rendimiento

16 Bitácora de aceptación Anexo 9


123


17 Prueba de registro

registro de pruebas para las especificaciones de ensayo de procedimiento de disponibilidad

registro de pruebas para las especificaciones de ensayo de procedimiento de rendimiento

registro de pruebas para las especificaciones de ensayo de procedimiento de seguridad

18 Prueba de notificación de incidentes/anomalías

informe general de incidentes para pruebas de disponibilidad

informe general de incidentes para pruebas de rendimiento

informe general de incidentes para pruebas de seguridad

19 Control de estado de pruebas no funcionales

Reporte estado de prueba interna de Disponibilidad

Reporte estado de prueba interna de Seguridad

Reporte estado de prueba interna de Rendimiento

20 Reporte de prueba operacional

Reporte de prueba operacional prueba de rendimiento

21 Detalle procedimental

Detalle de respuesta procedimental pruebas de Disponibilidad

Detalle de respuesta procedimental pruebas de Seguridad

Detalle de respuesta procedimental pruebas de Rendimiento

22 Prueba de Informe Resumen

Análisis de resultados disponibilidad

Análisis de resultados rendimiento

Análisis de resultados seguridad

23 Matriz de trazabilidad

Matriz de trazabilidad pruebas de rendimiento

Matriz de trazabilidad pruebas de disponibilidad

Matriz de trazabilidad pruebas de seguridad

Remítase ver el numeral 5.2.4.9 de la página 139 para aclarar la manera en que se asocia el compendio general de documentación en la Tabla 35 para todas las pruebas no funcionales.

124

Teniendo en cuenta que la información inscrita en la Tabla 30 se relaciona con las actividades de prueba asociadas con los índices de la Tabla 31, permite definir que las tareas de prueba mínimas recomendadas por el estándar IEEE 829 correspondientes a entradas (inputs) y salidas (outputs) …de la sección numeral 4.1.4...se realicen de acuerdo con la Tabla 6; sin embargo, el objetivo propuesto no se consiguió debido a que cuando se estableció la ejecución de las pruebas, la respectiva utilización de documentación fue realizada en cascada y de manera consecutiva, lo que quiere decir que los índices de los documentos y artefactos de actividades se comportaban como las entradas (inputs) de su documento consecutivo por nivel, lo que indicó que se podía omitir utilizar la Tabla 6. Es importante mencionar que por cada nivel de integridad, se asoció las actividades de prueba de cada prueba no funcional y los niveles se mapearon a la Tabla final 35. Tabla 31. Tareas mínimas recomendadas.

La Tabla 31 es el ejemplo básico de cómo se empezaron a utilizar los índices y los identificadores de cada actividad de prueba para poder formar las estructuras finales de documentación para los tres tipos de prueba no funcionales, y con ello poder también relacionar las figuras radiales de los niveles de integridad que permiten llevar el control de los estados de los niveles y sus correspondientes actividades asociadas ya mencionadas.

4 3 2 1

0

3

2

3,4

6

1

1

7

7

7

7


Desarrollo

ind

ice

61 Generación reporte prueba Maestra

54 Generación regis tro prueba de s is tema

51 Generación casos de prueba de s is tema

52 Generación diseño de prueba de s is tema

53 Ejecución pruebas de s is tema

42 revis ion plan prueba maestro

41 Generación plan prueba maestro

24 Identi ficar riesgos

23 Identi ficar riesgos de seguridad (prueba)

9 Evaluación (operacional ) de Anomal ia

10 Generación de estado de anomal ia

id Actividades de prueba

A A A AX X X X

A AX X X X

A A A A A A X XX XX X X XA A

Pruebas

nivel de integridad

125

Tomando como ayuda las Figuras 19, 20, y 21 de los esquemas radiales se genera un nuevo esquema radial que lleva el orden en la ejecución de los niveles por cada prueba. El pasante utiliza las figuras de los esquemas radiales de las pruebas del paso 4 y las actualiza por fecha y por estado, permitiendo llevar así control general de las mismas, tal como se presenta en la Figura 22. La explicación del control de estado se da de la siguiente manera:

- Los estados de cada nivel están relacionados en la cuarta actividad general del paso 8 del esquema.

- La Figura 22 ejecuta la Tabla 30, y se desencadena de manera consecutiva según el índice de cada actividad de prueba.

- Las tareas mínimas recomendadas para todas las pruebas se establecen según los documentos y artefactos de actividades.

Los pasos posteriores 6, 7 y 8 ayudan a discernir sobre los niveles que se estén tratando con control sobre su proceso de prueba, y estos a su vez sobre la documentación aplicada.

126

Rango Descripción


1 Insignificante

2 Bajo

3 Medio

4 Moderado

5 Alto

Figura 22.Control de estado por nivel.

El control de nivel se establece a través el estado actual del mismo y permite agendar y realizar cronogramas de las actividades de cada prueba no funcional. De esta manera al digitalizarla o imprimirla según convenga se puede asociarla a recursos, fechas y artefactos relacionados.

127

5.2.4.8.6 Paso 6. Encaje.

Este paso se encarga de iniciar todo el contexto de las pruebas no funcionales en el sistema, siendo uno de los procedimientos más importantes pues tiene por objetivo indicar cuál será el alcance general y detallado de las pruebas y decidir la cantidad de recursos necesarios para poderlas llevar a cabo. El encaje concierne exclusivamente en indicar como se realizará cada una de las pruebas al sistema, y de hecho al momento de conocer los cuatro primeros pasos del esquema MDI 829, se tiene una clara perspectiva del ámbito de la pruebas, tanto así que los objetivos y los resultados se vuelven más precisos. Es necesario mencionar que se tiene que justificar procedimentalmente cuál será el plan de acción de las pruebas no funcionales, y así determinar la gestión de las tareas inherentes en el programa interno …tal como se menciona en el numeral 5.2.3… El trabajo realizado en este paso no es tan fuerte en su amplitud pero si en profundidad, pues literalmente los informes y documentos generados en esta sección dependen en mayor medida de la información recogida en los pasos anteriores, y bien no sobra mencionar que la principal tarea desarrollada acá es la evaluación de los pormenores con que tienen que ser evaluados los documentos de planeación, pues es una labor minuciosa que requiere conocer el detalle de las pruebas. Se considera entonces el futuro de las pruebas al proyectar el alcance teórico y su proyección, junto con los aspectos de gestión los cuales tienen implicaciones en el proyecto. Con la anterior idea, este paso se enfoca en los documentos MTP y LTP referenciados en la Tabla 32.

128

Tabla 32. Documentos por nivel de preparación, ejecución y finalización.

Estado general

Nivel

Id Ref. Descripción

Pau

ta 1

pre

par

ació

n 1 MTP Plan Maestro de pruebas o Master Test Plan

2 LTP Nivel de plan de Prueba o Level Test Plan

3 LTD Nivel de diseño de prueba o Level Test Design


Pau

ta 2

Eje

cuci

ón


6 LTL Nivel de registro de prueba o Level Test Log

7 AR Nivel de notificación de incidentes o Anomaly Report

8 LITSR Nivel Informe provisional de estado de la prueba o level Interim Test Status Report

Pau

ta 3

Fin

aliz

ació

n

9 LTR Nivel de informe de la prueba o Level Test Report


Fuente propia (7).

Como se mencionó en el anterior párrafo, el énfasis de este paso consiste en enfocarse de la manera más clara en la pauta de preparación, por tanto su objetivo radica en los documentos y artefactos correspondientes a MTP y LTP, generar levantamiento de información y proyección de la planeación de las pruebas.

Objetivos del paso Preparar los documentos y artefactos correspondientes a MTP y LTP, generar procesos de levantamiento de información y proyectar la planeación de las pruebas.

Resultados obtenidos Identificación del tipo de actividades que se deben realizar en esta pauta de preparación de pruebas no funcionales para rendimiento, disponibilidad y seguridad, estableciendo los primeros y principales insumos necesarios para

129

iniciar las actividades del esquema MDI, fundamentados en el levantamiento de información con su correspondiente selección y análisis (Véase Tabla 18). En el nivel MTP se prepara la maquinaria de insumos para pruebas no funcionales analizando y generando los objetivos en el plan maestro y el plan general de todas las pruebas no funcionales, ajustando los mismos en contraposición a documento de licitación de la Propuesta GESDOC. Se filtra los requerimientos funcionales y no funcionales descritos en el Anexo 9 (Véase resumen general base de los requisitos más importantes del Anexo 9 en la Figura 23), para constituir la documentación de plan maestro y plan general de pruebas. Para el nivel LTP, la documentación proporcionada por el esquema se utiliza para realizar el documento exclusivo para los planes de pruebas por nivel no funcional, y se detalla el alcance técnico de las tres pruebas no funcionales. Por último, se analiza matemáticamente la proyección de las pruebas de rendimiento. Esta proyección se realiza calculando la cantidad de transacciones de cada funcionalidad en el tiempo determinado de la carga concurrente. Estos cálculos permiten obtener información aproximada de la cantidad de eventos por usuario que el robot emula. Los cálculos para las pruebas de seguridad se realizan básicamente para determinar cuántos casos de prueba son necesarios realizar si se tiene un conjunto establecido de valores límite valido e inválido, en este caso para inyecciones de código.

130

Fuente propia relacionada del Anexo 9.

Figura 23. Resumen base de requisitos del sistema Sigedoc por Anexo 9.

131

5.2.4.8.7 Paso 7. Verificación, validación e inspección. Este paso presenta para cada una de las pruebas no funcionales una de las etapas más arduamente trabajadas, debido a las tareas con nivel de detalle funcional a realizar. Así en cada prueba se tiene por labor examinar con cuidado una serie de características técnicas, variables, datos, recursos y ambientes, todos necesarios para la ejecución ideal exitosa. Lo que conlleva a abordar en su totalidad cada característica propia de la prueba no funcional, validando así que los insumos sean los correctos y que las configuraciones se establezcan de manera consistente. En si se considera una etapa ardua debido a que se considera la materialización de las ideas técnicas en el diseño y planeación de las pruebas, lo que implica directamente un trabajo fuerte en amplitud y en profundidad. (Ver tabla 32). Tabla 34. Documentos por nivel de preparación, ejecución y finalización.

Estado general

Nivel


Pau

ta 1

pre

par

ació





Pau

ta 2

Eje

cuci

ón




8 LITSR

Nivel Informe provisional de estado de la prueba o level Interim Test Status Report

Pau

ta 3

Fin

aliz

ació

n



Debido a que las tareas que se generan en este paso, son las más importantes para la proyección de las pruebas debido a que definen el ámbito general del nivel técnico a implementar, no se genera el continuo bombardeo de información de estados de las pruebas al paso 5 de control. Por tanto, la presión del nivel de control es baja mas no relajada para este paso y está pendiente en los objetivos más relevantes de las pruebas.

132

Objetivos del paso Correcta relación de los escenarios y casos de pruebas apropiados con la investigación literaria de herramientas y aplicaciones para ejecución de las pruebas.

Resultados obtenidos Concluida las dos actividades previas de preparación dedicadas a los documentos del plan maestro y a los planes de pruebas no funcionales, se procedió a dividir este paso en dos actividades generales por la gran cantidad de esfuerzo en recursos y tiempo, así las actividades se distribuyeron de la siguiente manera: - Primera actividad general: El nivel LTC realizó el diseño y creación de la

especificación de los casos de prueba no funcional para las tres pruebas, precisando la cantidad y el nivel de detalle de cada caso. Aquí se entiende el alcance de los procesos o actividades específicas involucrados en los escenarios de prueba del sistema.

- Segunda actividad general: Corresponde al nivel LTD que permitió encargarse de diseñar técnicamente cada tipo de configuración macro por prueba, lo que significa que se transforma la idea y el concepto de la prueba general y de los casos de prueba no funcional en su equivalente técnico. Aquí fue necesario establecer y utilizar las herramientas y los lenguajes específicos para registrar, grabar y guardar configuraciones en las mismas con los datos e información suministrada por el sistema o estructuradas y diseñadas específicamente para las pruebas no funcionales. El resultado de este trabajo se centró en la forma cómo se van a organizar y disponer de los ejecutables, robots, ambientes, vínculos o archivos según el caso, para su utilización en el paso 8. La mayoría de todos los artefactos manejados en esta actividad cargan información correctamente parametrizada generando sus propios registros de operación. Respecto al control de métricas de pruebas. Éstas se implementaron directamente en los documentos finales entregados al cliente, las cuales permitieron relacionar la prueba específica con la o las característica del sistema probado.

133

5.2.4.8.8 Paso 8. Evaluación y ejecución del tipo de prueba. La ejecución de las prueba y el resultado de las mismas, forman parte del programa interno de pruebas …según la Tabla 11 del numeral 5.2.3… se tiene en la planeación realizar dos actividades macro. La primera actividad es verificar los datos que alimentan las pruebas, realizando “Smoke test” para confirmar las correctas configuraciones y por ende obtener los registros adecuados según las tareas propias inscritas en el respectivo plan de pruebas no funcional, seguido se ratifica que la información registrada sea consistente y válida para así continuar con la ejecución. Concluida la anterior verificación se procede a realizar la ejecución total, donde se constata que también cumpla con las condiciones de consistencia en los registros obtenidos y así categorizar el resultado como información fiable para su organización y análisis.

La certificación forma parte de esta segunda etapa macro y basa su criterio de aceptación en que el tipo de prueba se realiza en pasos detallados, que pueden replicarse en cualquier momento de acuerdo a los documentos o artefactos obtenidos en ambientes de pruebas al lado del proveedor. En efecto las características evaluadas y probadas del proceso de certificación se realizan en dos ambientes, el primer ambiente es el del proveedor y el segundo es el del cliente, resaltando que al lado del proveedor pueden estar limitadas a características de hardware o software, siendo una constante de riesgo que tiene que poder mitigarse con soluciones prácticas según el tipo de prueba. La forma de mitigar los riesgos en las pruebas es permitir que se hagan realidad en un ambiente controlado. Se puede considerar según las anteriores apreciaciones que cuando se realiza pruebas de aceptación en el ambiente de preproducción de la CGR, los resultados tendrán que ser igual de consistentes y similares a los ambientes emulados por el proveedor. Como efecto del presente paso, la evaluación y ejecución para los tres tipos de pruebas fueron realizadas y presentadas directamente a los “stakeholder´s” cliente. El cliente en esta instancia del proyecto hace referencia puntual a los ingenieros de la CGR, siendo un subgrupo especializado en la adopción del sistema de gestión documental, a ellos se presentó cada prueba para su aprobación, previamente certificada y probada en los ambientes emulados al interior de la empresa desarrolladora del producto.

En referencia a la organización, gestión de la documentación y artefactos de las pruebas no funcionales, las pautas globales que se tienen que utilizar en este paso son las referentes a ejecución y finalización, cuya información se presenta en la Tabla 34. Que dependiendo del nivel de integridad de las pruebas, algunos documentos no aplicarán según el estándar IEEE 829, y de acuerdo a la

134

importancia de las pruebas, estas serán evaluadas y analizadas para validar la amplitud y profundidad de las mismas. En este contexto, los documentos que fueron utilizados por las pautas definidas para ejecución y finalización serán: LTPr Nivel de especificación de Casos de prueba, LTL Nivel de registro de prueba, AR Nivel de notificación de incidentes, LITSR Nivel Informe provisional de estado de la prueba, LTR Nivel de informe de la prueba y MTR Informe de prueba maestro. Tabla 32. Documentos por nivel de preparación, ejecución y finalización.

Estado general

Nivel


Pau

ta 1

pre

par

ació





Pau

ta 2

Eje

cuci

ón




8 LITSR

Nivel Informe provisional de estado de la prueba o level Interim Test Status Report

Pau

ta 3

Fin

aliz

ació

n



Fuente propia (7).

Objetivos del paso Ejecutar pruebas no funcionales objetivo de acuerdo al nivel procedimental, nivel de registro y nivel de informe. Obtener soportados de registros y anomalías si llegasen a generar. Finalizar pruebas no funcionales objetivo con informes de tipo nivel de pruebas y plan maestro.

135

Resultados obtenidos Debido a que este nivel se compone de muchos aspectos técnicos, genera la mayoría de comunicados e informes al paso 5 (paso de control), por tanto se utiliza el siguiente protocolo de comunicación: - Envió de informe a control. El recurso a cargo y que recibe como tarea uno

de los tres niveles indicados en este nivel, debe informar al recurso de control un informe preciso con la siguiente información: fechas reales de inicio, ejecución y finalización de la actividad que esté realizando, junto con la duración en el registro o creación del nivel de prueba según el caso, avances porcentuales del diseño o de la especificación de casos de prueba o del procedimiento de la prueba, inscripción de la complejidad, prioridad, los recursos asociados activos del total asignado, riesgos encontrados en el nivel, fallas o errores presentes, mitigación o posibles soluciones a las fallas o errores, hechos pendientes, estado del nivel de prueba y finalmente precondiciones y post condiciones parciales. De esta manera el organismo de control podrá gestionar mejor el inicio o finalización de cada documento y dar prioridad a las pruebas.

- Respuesta de confirmación en la entrega del informe a control.

- Comunicado de continuidad o de pausa en la ejecución de las actividades de pruebas por nivel por parte de control.

- Respuesta de confirmación de continuidad o de pausa en la ejecución de las actividades.

- Comunicado de finalización de actividades de pruebas.

- Respuesta de confirmación de finalización de actividades y de pruebas. Con las condiciones de configuraciones técnicas tomadas en el paso 7, se valida cuáles de ellas se mantienen en todo momento, y así establecerlas como condiciones fijas en este paso, lo que permite adicionarlas y replicarlas en el control de pruebas. Respecto a las pruebas de humo realizadas con su correspondiente herramienta, programa o aplicación a cada tipo de prueba no funcional, se permitió prever y controlar mejor las ejecuciones pues se evitó errores en ejecuciones costosas y con complejidad en su alistamiento. Las validaciones de ejecuciones en las pruebas de humo ayudaron a pronosticar y acertar las posibles causas que no permitieron un correcto flujo en la ejecución, como también poder corregir los defecto encontrados y darles solución, generar guías sencillas que indicaban los pasos correctos y alternativos para permitir

136

continuar con una ejecución exitosa hasta el final, y guías de mejoramiento en la formas de optimizar la ejecución de las mismas. Los informes mencionados a continuación corresponden a la traza de eventos por cada nivel de pruebas realizado, organizados de manera que se pueda diferenciar secuencialmente las actividades ejecutadas y finalizadas. Las seis actividades generales en este paso fueron divididas de la siguiente manera.

- Primera actividad general: Corresponde al nivel LTPr, y es la actividad núcleo principal de las pruebas no funcionales puesto que implicó toda la concentración técnica aplicada al fin común del objetivo de las pruebas técnicas. Esta actividad necesitó de una gran inversión y esfuerzo en actividades específicas relacionadas en la Tabla 33.

Tabla 33. Actividades núcleo de LTPr.

Tipo de actividad

Descripción

Estructuración Estructuración del plan procedimental de detalle de las tres pruebas no funcionales.

Procedimental Validación e instalación de herramientas específicas según las pruebas.

Documentación Manuales detallados de los procedimientos de especificación técnica para los casos de prueba de rendimiento, disponibilidad y seguridad, cada procedimiento dividido en sus correspondientes pruebas más específicas.

Configuración Ajustes y calibraciones en los planes procedimentales.

Ejecución Ejecución y posterior ajustes y calibraciones.

Validación Confirmación de ejecuciones en las pruebas de aceptación.

Como anotación de estas actividades, el desarrollo de habilidades ejecutoras como el manejo en profundidad de herramientas o programas específicos permitió realizar un análisis más objetivo y claro del alcance de las pruebas en relación con el alcance de las herramientas y las características del sistema.

137

- Segunda actividad general: Durante la ejecución de las pruebas, las herramientas utilizadas para cada tipo de prueba no funcional generan archivos con un tipo de extensión específica, registros, log´s de eventos o actividades, o sencillamente actualizar variables o datos en ubicaciones determinadas, así, dependiendo de las mismas se tuvo que recolectar de manera manual o automática estos datos e información producida, seleccionar herramientas o medios para tratar los mismos, clasificar los resultados, validar las fecha de inicio y finalización de pruebas, y por ultimo clarificar la consistencia de los resultados. Todas estas tareas tienen el fin de proporcionar el insumo a la etapa de análisis de información de la pauta 3 para finalización de pruebas. Nivel aplicado LTL.

- Tercera actividad general: Después de realizar las prueba de humo se

prosigue con la ejecución de las pruebas generales o totales, queriendo decir que se confía en una ejecución que represente una emulación real para probar una característica del sistema en un entorno adecuado para tal fin, en este caso el propósito de esta actividad general consistió en documentar eventos ocurridos que causaron incidentes, problemas, defectos, anomalías o errores reportados durante estas ejecuciones y que requirieron ser investigados. La prueba que más generó este tipo de incidentes fue la prueba de rendimiento y su informe se encuentra en el informe general de incidentes y anomalías. Nivel aplicado AR.

- Cuarta actividad general: En el paso 7 del esquema se habló del protocolo

de comunicación entre este paso y el paso 5 de control, allí se mencionó que el recurso que estaba a cargo de las pruebas debía enviar un informe preciso del estado de la prueba. La misma relación se presentó en esta actividad, con la adición el estado será: abierto o en ejecución, en proceso de iniciar resolución o ejecución, y resuelto o ejecutado. Cada estado anterior podía depender de la anterior actividad que relaciona las anomalías encontradas en el sistema, de manera que el informe podía identificar si algunas métricas se veían afectadas y si este era el caso, se enviaba con las pertinentes recomendaciones para que fueran tomadas en cuenta en decisiones del paso de control. Esta actividad se denominó control de estado. Nivel aplicado LITST.

- Quinta actividad general: Con esta actividad, se proporcionó los

resultados analizados de la correspondiente evaluación de cada una de las tres pruebas no funcionales realizadas al sistema en el documento de detalle de resultados técnicos o procedimentales de disponibilidad, rendimiento y seguridad. Para pruebas de rendimiento se adquirió además informes operacionales con frecuencia según los módulos probados, este documento contenía información del tipo de carga, infraestructura probada y volumen inyectado de usuarios a la aplicación. Además, para estas tres

138

pruebas no funcionales se hizo cobertura completa de artefactos, archivos, datos y herramientas que permitían la correcta interpretación de resultados para confirmar que el sistema cumplía con los requerimientos que la CGR demandaba de la aplicación sigedoc.

Las conclusiones, los detalles de los resultados, recomendaciones y certificaciones fueron indicadas en los documentos de esta actividad general cuya asociación se ligaba a las pruebas de aceptación realizadas con los “Stakeholder´s” CGR encargados de aprobar o no aprobar las pruebas. Nivel aplicado LTR.

- Sexta actividad general: Por medio de la matriz de trazabilidad obtenida en referencia al anexo 9, se realizó un informe resumido de los resultados de las actividades de prueba y se proporcionó evaluaciones basados en estos. Nivel aplicado MTR. Así mismo se presentaron informes generales al director de proyecto de cada nivel de pruebas, los cuales se presentan en la Tabla 34.

Tabla 34. Informes generales de nivel MTR.

Tipo de evaluación Descripción

Resumen ejecutivo Resumen ejecutivo de todas las actividades de pruebas realizadas, el cual el líder de proyecto se encarga de evaluar y dar su consentimiento de aprobación.

Resumen ejecutivo Resumen ejecutivo de los resultados de todas las tareas de prueba.

Resumen de anomalías

Resumen de anomalías y resolución de las mismas.

Evaluación Evaluación de la liberación o release de la aplicación / incremento de calidad, es una evaluación general de la calidad de los productos entregados de la versión entregada.

Resumen ejecutivo Resumen de métricas generales.

El resumen general de las actividades es resumida en el detalle descriptivo de la Tabla 35.

139

5.2.4.9 Documentación generada por los pasos del esquema. La documentación generada a partir del momento en que se inició con la ejecución del esquema MDI 829 es evaluada y almacenada en el repositorio de la empresa que realizó el sistema, así el cliente sólo recibirá documentos específicos, los cuales son generados a partir de la unión, integración, composición o compilación de muchos de los documentos relacionados entre sí y tratados durante toda la ejecución de pruebas en el esquema MDI, por tanto los documentos específicos son transparentes para el cliente respecto a la cantidad, numeración, indexación, y requisitos de los mismos.

A partir del ejemplo de la Tabla 30 …del numeral 5.2.4.8.5… se organizan los resultados obtenidos por el nivel de prueba, así en La Tabla 35 resume todo el trabajo realizado en el proyecto, presentando en ella la relación existente entre los diferentes niveles y actividades de prueba, resaltando que este resultado es también el resumen del trabajo del paso 5 de control. Aunque la evaluación de las pruebas realizadas al proyecto basado en el esquema MDI 829 consiste en describir todos los resultados analizados, organizados, estructurados y resumidos de las ejecuciones. Su labor se centra en los documentos del nivel LTR y MTR de la pauta 3 del paso 8. Este nivel entrega formalmente todos los documentos.

140

Tabla 35. Documentación y artefactos generales PNF.

Actividad de pruebas Nivel Documentación

Nombre ID Nombre ID ID* Detalle de documentos y artefactos de actividades Referencia

Generación plan prueba maestro

41 MTP 1 1 Plan general de pruebas no funcionales

plan general de pruebas de disponibilidad PR_PD1_PlanGeneral_PruebasDeDisponibilidad

plan general de pruebas de rendimiento PR_PR1_PlanGeneral_PruebasDeRendimiento

plan general de pruebas de seguridad PR_PS1_PlanGeneral_PruebasDeSeguridad

entrega de informes parciales y totales PR_PNF1_PlanGeneral_InformeParcial o PR_PNF1_PlanGeneral_Informe

revisión plan prueba maestro 42 MTP 1 2 Plan general de pruebas no funcionales o plan maestro PR_PNF1_PlanGeneral_PruebasNoFuncionales

Revisión plan de prueba maestro de rendimiento PR_PR1_PlanGeneral_PruebasDeRendimiento

Evaluación de requerimientos del software para propósitos de prueba

49 0 1 3 Propuesta GESDOC

Documento licitación (página 13) Propuesta Gestión documental: CONTRALORÍA GENERAL DE LA REPÚBLICA

Revisión de requerimientos del sistema para probar

50 0 1 4 Anexo 9


Anexo 9

Generación plan de prueba de sistema

55 LTP 2 7 Plan de pruebas de nivel de prueba no funcional

Plan de pruebas de nivel de prueba no funcional PR_PD_PlanDePruebas_PruebasDeDisponibilidad

Plan de pruebas de nivel de prueba no funcional PR_PR_PlanDePruebas_PruebasDeRendimiento

Plan de pruebas de nivel de prueba no funcional PR_PS_PlanDePruebas_PruebasDeSeguridad

Determinar el alcance del esfuerzo de la prueba

47 LTP 2 5 Proyección de pruebas

Alcance y Proyección de pruebas de seguridad PR_PS_Proyeccion_PruebasDeSeguridad

Alcance y Proyección de pruebas de rendimiento PR_PR_Proyeccion_PruebasDeRendimiento

Alcance de pruebas de disponibilidad

141

Tabla 35 (Continuación 1)


Nombre ID Nombre ID ID*

Detalle de documentos y artefactos de actividades Referencia

Generación diseño de prueba de sistema

52 LTD 2 6 Pruebas de diseño

prueba de diseño para pruebas de disponibilidad

Configuración herramienta de monitoreo ManageEngine (Edición de monitoreo para RED, CPU, MEMORIA, ESPACIO DE DISCO, URL´S) y SIGESDOC (Consola de administración de servidor) y SQL Server (Consola de administración).

prueba de diseño para pruebas de rendimiento

SCRIPTS o robots nombrados con la nomenclatura de cada módulo y tipo de prueba, alojados en el repositorio de la empresa

prueba de diseño para pruebas de seguridad

Preparación de herramientas, archivos y ambientes. como por ejemplo: En RED , configuración herramienta de olfateo AirCraf (snnifer "hombre en el medio", preparación de despliegues del sistema en protocolos base y encriptados), en SIGEDOC (listar entradas por puertas traseras, accesos privilegiados e inyecciones de código ).

entrega de informes parciales y totales PR_PNF_InformeActividades

Identificación Métricas 43 LTD 3 8 Planeación de prueba

Diseño y creación de métricas de pruebas de rendimiento por módulos y usuarios concurrentes.

Inclusión de listado general métricas.

Generación casos de prueba de sistema

51 LTC 3 9 Especificación casos de prueba

Especificación casos de prueba de disponibilidad PR_PD_CasosDePrueba_PruebasDeDisponibilidad

Especificación casos de prueba de rendimiento PR_PR_CasosDePrueba_PruebasDeRendimiento

Especificación casos de prueba de seguridad PR_PS_CasosDePrueba_PruebasDeSeguridad

entrega de informes parciales y totales N/A

142



Nombre ID Nombre ID ID* Detalle de documentos y artefactos de actividades Referencia

Ejecución pruebas de sistema 53 LTPr LTL 3,4 10 Procedimiento de especificación casos de prueba de disponibilidad PR_PD_ProcedimientoCasosPrueba_PruebaDeDisponibilidad

prueba de monitoreo PR_PD_ProcedimientoCasosPrueba_PruebaDeDisponibilidad

pruebas de recuperación ante caídas PR_PD_ProcedimientoCasosPrueba_PruebaDeDisponibilidad

pruebas de recuperación de copias y restauración PR_PD_ProcedimientoCasosPrueba_PruebaDeDisponibilidad

3,4 11 Procedimiento de especificación casos de prueba de rendimiento PR_PR_ProcedimientoCasosPrueba_PruebaDeRendimiento

prueba de carga y rendimiento PR_PR_ProcedimientoCasosPrueba_PruebaDeRendimiento

prueba de estrés PR_PR_ProcedimientoCasosPrueba_PruebaDeRendimiento

pruebas de picos PR_PR_ProcedimientoCasosPrueba_PruebaDeRendimiento

3,4 12 Procedimiento de especificación casos de prueba de seguridad PR_PS_ProcedimientoCasosPrueba_PruebaDeSeguridad

prueba de confidencialidad PR_PS_ProcedimientoCasosPrueba_PruebaDeSeguridad

pruebas de integridad PR_PS_ProcedimientoCasosPrueba_PruebaDeSeguridad

pruebas de autenticación PR_PS_ProcedimientoCasosPrueba_PruebaDeSeguridad

pruebas de autorización PR_PS_ProcedimientoCasosPrueba_PruebaDeSeguridad

Instalación/ Verificación 26 LTPr 5 13 Instalación herramientas PR_PNF_Herramientas_PruebasNoFuncionales

Instalación herramientas de monitoreo N/A

Instalación herramientas de rendimiento N/A

Instalación herramientas de seguridad N/A

Reporte de instalación y verificación de herramientas de disponibilidad. N/A

Reporte de instalación y verificación de herramientas de rendimiento. N/A

Reporte de instalación y verificación de herramientas de seguridad. N/A

143



Nombre ID Nombre Nombre ID Nombre Nombre

Generación procedimiento de prueba del sistema

56 LTPr 5 14 Plan procedimental PR_PNF_PlanProcedimental_PruebaNoFuncionales

Plan procedimental pruebas de Disponibilidad N/A

Plan procedimental pruebas de Seguridad N/A

Plan procedimental pruebas de Rendimiento N/A

Participación revisión de disponibilidad de prueba

60 LTPr 5 15 Ajustes y calibración N/A

Ajuste y calibración pruebas de rendimiento PR_PR_AjusteYCalibracion_PruebasDeRendimiento

Ejecución de pruebas de aceptación

4 LTPr LTL 5,6 16 Bitácora de aceptación Anexo 9

Anexo 9 basado en requerimientos funcionales y no funcionales EJ_PNF_BitacoraEjecucion_PruebasNoFuncionales

Generación registro prueba de sistema

54 LTL 6 17 Prueba de registro

registro de pruebas para las Especificaciones de ensayo de procedimiento de disponibilidad archivos de evidencias pruebas de disponibilidad

registro de pruebas para las Especificaciones de ensayo de procedimiento de rendimiento archivos de evidencias pruebas de rendimiento

registro de pruebas para las Especificaciones de ensayo de procedimiento de seguridad archivos de evidencias pruebas de seguridad

Evaluación (operacional) de anomalía

9 AR 7 18 Prueba de notificación de incidentes/anomalías

informe general de incidentes para pruebas de disponibilidad N/A. No se generaron

informe general de incidentes para pruebas de rendimiento

N/A. No se generaron

informe general de incidentes para pruebas de seguridad N/A. No se generaron

144



Nombre ID Nombre Nombre ID Nombre Nombre

Generación de estado de anomalía 10 AR 7 Prueba de notificación de incidentes/anomalías

informe general de incidentes para pruebas de disponibilidad Aplica Sistema de seguimiento de errores Bug tracker.

informe general de incidentes para pruebas de rendimiento Aplica Sistema de seguimiento de errores Bug tracker.

informe general de incidentes para pruebas de seguridad Aplica Sistema de seguimiento de errores Bug tracker.

Identificar riesgos de seguridad (prueba)

23 LTP 7 Prueba de notificación de incidentes/anomalías

informe general de incidentes para pruebas de disponibilidad EJ_PD_ReporteIncidenteAnomalia_PruebasDeDisponibilidad

informe general de incidentes para pruebas de rendimiento EJ_PD_ReporteIncidenteAnomalia_PruebasDeRendimiento

informe general de incidentes para pruebas de seguridad EJ_PD_ReporteIncidenteAnomalia_PruebasDeSeguridad

Identificar riesgos 24 LTP 7 Prueba de notificación de incidentes/anomalías

informe general de incidentes para pruebas de disponibilidad EJ_PD_ReporteIncidenteAnomalia_PruebasDeDisponibilidad

informe general de incidentes para pruebas de rendimiento EJ_PD_ReporteIncidenteAnomalia_PruebasDeRendimiento

informe general de incidentes para pruebas de seguridad EJ_PD_ReporteIncidenteAnomalia_PruebasDeSeguridad

Generación reporte estado de prueba interna del sistema

48 LITSR 8 19

Control de estado de pruebas no funcionales

Reporte estado de prueba interna de Disponibilidad EJ_PD_InformeDeEstado_PruebaDeDisponibilida+L182d

Reporte estado de prueba interna de Seguridad EJ_PS_InformeDeEstado_PruebaDeSeguridad

Reporte estado de prueba interna de Rendimiento EJ_PR_InformeDeEstado_PruebaDeRendimiento

Generación reporte prueba operacional

45 LTR 9 20

Reporte de prueba operacional

Reporte de prueba operacional prueba de rendimiento FI_PR_InformeOperacionalDeEjecucion_PruebaDeRendimiento

145



Nombre ID Nombre Nombre

ID Nombre Nombre

Generación reporte de prueba de sistema

57 LTR 9 21

Detalle procedimental

Detalle de respuesta procedimental pruebas de Disponibilidad FI_PD_Procedimiento_PruebasDeDisponibilidad

Detalle de respuesta procedimental pruebas de Seguridad FI_PS_Procedimiento_PruebasDeSeguridad

Detalle de respuesta procedimental pruebas de Rendimiento FI_PR_Procedimiento_PruebasDeRendimiento

Generación reporte prueba Maestra 61 LTR 9 22 Prueba de Informe Resumen

Análisis de resultados disponibilidad FI_PD_AnalisisDeResultados_PruebasDeDisponibilidad

Análisis de resultados rendimiento FI_PR_AnalisisDeResultados_PruebasDeRendimiento

Análisis de resultados seguridad

FI_PS_AnalisisDeResultados_PruebasDeSeguridad ; Manual de mantenimiento (Procesos de mantenimiento periódico, backup y recuperación ); memorias.

Generación matrix de trazabilidad de prueba

62 MTR 10 23

Matriz de trazabilidad

Matriz de trazabilidad pruebas de rendimiento FI_PR_MatrizDeTrazabilidad_PruebasDeRendimiento

Matriz de trazabilidad pruebas de disponibilidad FI_PD_MatrizDeTrazabilidad_PruebasDeDisponibilidad

Matriz de trazabilidad pruebas de seguridad FI_PS_MatrizGeneralDeTrazabilidadDeTérminos

La anterior tabla se relaciona estrechamente con la Figura 16 a través de cada uno de los niveles de integridad, sin embargo se presenta el hipervínculo “DocumentacionSuplementariaTabla35” como soporte adicional a los niveles de integridad para todas las pruebas no funcionales.

DocumentacionSuplementariaTabla35

146

5.2.4.10 Especificación adicional de resultados de los pasos del esquema. En referencia a la norma IEEE 829 …numeral 4.1.6.1… el plan maestro indica cómo se llevará a cabo la prueba específica al sistema. En este orden de ideas se realizan tres pruebas globales que son: pruebas de rendimiento, pruebas de disponibilidad y pruebas de seguridad. A éstas se asocia software y hardware para el correcto diseño y ejecución. 5.2.4.10.1 Pruebas de rendimiento. Se requiere herramientas* de generación de carga, cuya funcionalidad permite realizar pruebas de carga, picos, estrés y sobrecarga. Estas herramientas crean y utilizan sus propios archivos para emular peticiones a la aplicación web del sistema de gestión documental de la CGR, por tanto es necesario tener conocimientos básicos de lenguajes de programación y etiquetado como: java†, ajax‡, javascript§, html** y xml††.

La ejecución de cada prueba presenta información estadística y gráfica de acuerdo a cada tipo de prueba realizada al sistema El hardware al cual se realiza esta prueba corresponde a los equipos que se mencionan en la documentación de infraestructura y arquitectura física. Es explicito mencionar que primero se realizan pruebas en equipos de la empresa desarrolladora y posteriormente se concluye con pruebas en los equipos finales que se encuentran ubicados en las instalaciones de la Contraloría General de la República.

Resultados técnicos pruebas de rendimiento

El procedimiento de planeación, diseño, ejecución y resultados técnico, hacen parte de las etapas de las pruebas internas (ver Tabla 11). Así, los documentos y entregables que describe estas tareas se describen en el Anexo 1, cuyos artefactos se unifican para entregar al cliente CGR.

*El Software necesario para esta prueba se define en los artefactos de tipo documento.

†Java: lenguaje de programación de alto nivel orientado a objetos.

‡Ajax: acrónimo de JavaScript asíncrono y XML, Asynchronous JavaScript and XML.

§Java script: lenguaje de programación interpretado, orientado a objeto y basado en prototipos.

**Html: lenguaje de marcado de hipertexto Hyper Text Markup Language.

††Xml: 'lenguaje de marcas extensible eXtensible Markup Language.

147

Es de indicar que en el ejemplo del anexo 1 se tiene los documentos de planeación, diseño, ejecución y análisis de resultados los cuales son:

- Plan de pruebas. Abarca casos de prueba con la configuración técnica básica de la herramienta a utilizar y la especificación por cada módulo funcional de la aplicación del sistema de gestión documental.

- Especificación de casos de uso*. Indica: requerimientos de ejecución, tiempos, resultados esperados, ambientes necesarios, casos de prueba especificados técnicamente en la herramienta de inyección masiva, entradas, resultados esperados, evaluación e integración de las plantillas para los resultados reales.

- Análisis de resultados para pruebas no funcionales. Presenta los resultados generales, análisis, módulos probados, software, ámbito de prueba, análisis matemático (media, rendimiento y errores), análisis gráfico, y resultados por cada característica de rendimiento probado.

Incluido para este anexo se incluirá un ejemplo práctico para aplicar los lenguajes de programación y etiquetado en las herramientas de rendimiento, teniendo en cuenta las condiciones y políticas de confidencialidad.

* En la referenciada es claro que se tuvo error por digitalización en el título del documento.

148

5.2.4.10.2 Pruebas de disponibilidad. Se requiere herramientas de Monitoreo*, cuya funcionalidad consiste en verificar que los procesos de negocio que conforman el sistema de gestión documental estén funcionando de manera correcta y se encuentren disponibles. El hardware al cual se realiza el monitoreo de disponibilidad corresponde con la infraestructura y arquitectura propia de la CGR y consiste de: dos servidores de aplicación web y un servidor fax. La robustez de estos equipos corresponde a requerimientos no funcionales del sistema.

Resultados técnicos pruebas de disponibilidad

Análisis de resultados y procedimiento técnico con ejemplo en el Anexo 2†. Por el principio de confidencialidad de información descrito en el numeral 5.1, esta política de privacidad no permite: presentar, indicar, dar a conocer, difundir física o digitalmente información, artefactos o resultados de las labores realizadas para el proyecto de la CGR. Sin embargo se referenciara por medio de imágenes capturadas los documentos más importantes y principales del proyecto, los cuales son sinónimos del trabajo del pasante.

5.2.4.10.3 Pruebas de seguridad. Los mecanismos de seguridad para esta prueba utilizan: recursos propios de seguridad de los servidores de aplicación web, códigos de intrusión en lenguaje SQl‡, validación protocolos de comunicación y manipulación de etiquetado html.

Esta prueba se enfoca en asegurar la confidencialidad e integridad de información, autenticación y autorización al sistema de gestión documental. El hardware necesario para este ámbito corresponde a la infraestructura y arquitectura física que es emulada en la empresa que desarrolla el proyecto y también corresponde a los requerimientos no funcionales.

Resultados técnicos pruebas de seguridad

Análisis de resultados y procedimiento técnico con ejemplo en el Anexo 3*

* La herramienta puntual de monitorización utilizada para este proyecto fue Manage Engine Opmanager

versión 9.0. † El anexo 2 y 3 tienen la misma estructura que el anexo 1.

‡SQL: lenguaje de consulta estructurado, Structured Query Language.

149

6. CONCLUSIONES. La importancia de haber diseñado y ejecutado las pruebas no funcionales con el esquema metodológico MDI 829 fue de gran valor organizacional y excelente planteamiento metodológico, pues genero resultados fiables y determinantes en la toma de decisiones favorables para el proyecto Sigedoc. Estas pruebas se abordaron de una manera muy práctica, sin embargo es necesario contar con tiempos a favor para obtener buenos resultados ya que es un trabajo de mucha disciplina, dedicación, organización, y ante todo de mucha investigación y de recursividad. La finalización de estas pruebas no funcionales también permitió establecer que a proyectos de gran intensidad en el ámbito empresarial es necesario darles la verdadera importancia, pues según esta experiencia profesional se subestimada o sobrestimaba muchos factores entre los cuales se encuentran: la falta de medidas de comparación, preguntas concretas a evaluar, incorrecta contextualizaciones del tipo solución que abarcaban las pruebas, inexactitud en los requisitos y poco conocimiento por parte del cliente este tipo de pruebas. Esto conllevaba a que muchas de las características del software a probar y muchos de los criterios de aceptación definidos por el cliente fueran superfluos y pudiesen ser resueltas por la vía más rápida por el proveedor, sin embargo para evitar este tipo de solución no profesional ni de calidad, se utilizó el esquema metódicamente para poder fijar los límites, organizar y darle sentido a las pruebas y a los resultados, establecer criterios más precisos de las mismas, y finalmente cambiar el paradigma que se tenía de este tipo de pruebas. Otro punto importante analizado con este tipo de pruebas fue encontrar que un alto porcentaje de empresas desarrolladoras de software no evalúan ni aplican estas metodologías de calidad porque se piensa erróneamente que invertir en estas actividades pueden ser recursos y tiempos desperdiciados, no obstante también porque es complicado encontrar profesionales con experiencia, habilidades, calidad en su trabajo y certificados que los acrediten.

150

7. Bibliografía 1. IEEE Institute of Electrical and Electronics Engineers, en español Instituto de Ingenieros Eléctricos y Electrónicos. Sitio web http://ieeexplore.ieee.org/xpl/aboutUs.jsp. [En línea] 2014. [Citado el: 10 de Enero de 2012.] http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4459216. P829/D11, Feb 2008 - Draft IEEE Standard for software and system test documentation (Revision of IEEE 829-1998). 2. IEEE.IEEE/EIA Std 12207.0TM-1996. IEEE and EIA Joint Standard Development, Industry Implementation of International Standard ISO/IEC 12207-1995. 3. Wikipedia®. Software test, en español pruebas de software. [En línea] [Citado el: 10 de Marzo de 2014.] http://en.wikipedia.org/wiki/Software_testing. 4. tutorials point symply easy learning.Software Testing. [En línea] [Citado el: 10 de junio de 2013.] http://www.tutorialspoint.com/software_testing/levels_of_testing.htm. 5. Edo, Mauri. Testing funcional. Blog de WordPress.com. [En línea] [Citado el: 15 de Junio de 2013.] https://testingfuncional.wordpress.com/tag/no-funcional/. 6. Grupo Arquisoft. Pruebas de software, grupo Arquisoft. [En línea] http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/HTML%20-%20Pruebas%20de%20software/node1.html (fuente caducada). 7. XUE COLOMBIA LTDA.Reservado. 8. Wikipedia®. 4+1 architectural view model, en español Modelo de vista de arquitectura 4+1. [En línea] Wikimedia Foundation, Inc. [Citado el: 12 de Marzo de 2012.] http://en.wikipedia.org/wiki/4%2B1_architectural_view_model. 9. Requerimientos no funcionales. PMOinformática.com. [En línea] [Citado el: 23 de enero de 2013.] http://www.pmoinformatica.com/2013/01/requerimientos-no-funcionales-porque.html. 10. Silvana del Valle Rojo, Alejandro Oliveros. Requerimientos No funcionales para aplicaciones Web. [En línea] 2012. [Citado el: 17 de febrero de 2013.] http://www.41jaiio.org.ar/sites/default/files/432_ASSE_2012.pdf. 11. Archivo General de la Nación Colombia. Norma Internacional General de Descripción Archivística. [En línea] 19-22 de septiembre de 1999. [Citado el: 15 de febrero de 2013.] http://www.archivogeneral.gov.co/?idcategoria=2216. Norma Internacional General de Descripción Archivística, en ingles General International Standard Archival Description..

151

12. Procesos de gestión de documentos. Metadatos para la gestión de documentos. Revista española de documentación científica. pág. 453-506, Madrid España : s.n., 2008, Vols. Parte 2: Aspectos conceptuales y de implementación. Julio-Septiembre. 13. Secretaría General de la Alcaldía Mayor de Bogotá D.C. Ley 527 de 1999 Nivel Nacional. [En línea] 21 de Agosto de 1999. [Citado el: 8 de Febrero de 2012.] http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=4276. 14. Secretaría General de la Alcaldía Mayor de Bogotá D.C. LEY 594 DE 2000. [En línea] [Citado el: 9 de Noviembre de 2012.] http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=4275. 15. Normalización-ISO.NTC 15489 Norma general para la descripción archivística. Bogotá Colombia. : (ICONTEC), Archivo general de la nación., 1997. Editada por el instituto de Normas técnicas y certificación el 04 marzo 2004.. 16. GPL (GNU Public License). StarUML. [En línea] [Citado el: 10 de Junio de 2012.] http://staruml.sourceforge.net/en/index.php. 17. Wikipedia @. Single Sign On, en español Inicio de Sesión Unico. [En línea] [Citado el: 10 de mayo de 2013.] http://es.wikipedia.org/wiki/Single_Sign-On. 18. —. LDAP Lightweight Directory Access Protocol o en español Protocolo Ligero de Acceso a Directorios. [En línea] [Citado el: 19 de Enero de 2013.] http://es.wikipedia.org/wiki/LDAP. 19. JACOBSON, IVARBOOCH, GRADY RUMBAUGH, JAMES.R.U.P El proceso unificado de desarrollo de software. s.l. : Addison Wesley, 2004. R.U.P. 20. REGLA DE STURGES. The problem with Sturges’ rule for constructing Histograms. Hyndman, Rob J. http://robjhyndman.com/papers/sturges.pdf, 1995. 21. Colvatel. [En línea] http://www.colvatel.com/licitaciones/archivos/TerminosdeReferenciaGD.pdf. 22. ISO copyright office.Norma internacional ISO 15489-1. Primera edición. Ginebra : Departamento de derechos de autor de ISO, 2001. 15489 Información y documentación – Gestión de documentos– 15-09-2001. 23. Wikipedia®. System under test, es español sistema bajo prueba. [En línea] [Citado el: 10 de Noviembre de 2012.] http://en.wikipedia.org/wiki/System_under_test.

152

24. PMOinformática.com. PMOinformática.com " La Oficina de Proyectos de Informática". participante en el Programa de Servicios de Amazon Associates LLC. [En línea] [Citado el: 10 de Junio de 2013.] http://www.pmoinformatica.com/2013/01/requerimientos-no-funcionales-porque.html. 25. Wikipedia®. Tecnología informática. [En línea] Wikimedia Foundation, Inc. [Citado el: 10 de Mayo de 2013.] http://es.wikipedia.org/wiki/Tecnolog%C3%ADa_inform%C3%A1tica. 26. Ambler, Scott W. humbertocervantes.net. [En línea] 1997. http://www.humbertocervantes.net/homepage/itzamna/DOCUMENTACION/Doc1.html. 27. Wikipedia. [En línea] http://en.wikipedia.org/wiki/4%2B1_architectural_view_model. 28. Eric Jendrock, Ricardo Cervera-Navarro, Ian Evans, Devika Gollapudi, Kim Haase, William Markito, Chinmayee Srivathsa.The Java EE 6 Tutorial. Plataforma Java empresarial. [En línea] Enero de 2013 (actualizado). [Citado el: 3 de Enero de 2012.] http://docs.oracle.com/javaee/6/tutorial/doc/p1.html. 29. Dropbox. Servicio de backup remoto. [En línea] 2013 (actualizado). [Citado el: 20 de Enero de 2012.] https://www.dropbox.com/.

“DISEÑO Y EJECUCIÓN DE PRUEBAS NO...

Documents

Transcript of “DISEÑO Y EJECUCIÓN DE PRUEBAS NO...