ANÁLISIS DE PRECISIÓN DE TÉCNICAS DE AGREGACIÓN EN CONTEXTOS EXPERIMENTALES POCO MADUROS

Transcripción

1 TESIS DE MÁSTER EN INGENIERÍA DEL SOFTWARE ANÁLISIS DE PRECISIÓN DE TÉCNICAS DE AGREGACIÓN EN CONTEXTOS EXPERIMENTALES POCO MADUROS Autor: María Florencia Pollo Cattaneo Tutores: M Ing. Enrique Fernández Dr. Ramón García Martínez Buenos Aires, Noviembre de 2008

2 Ing. María Florencia Pollo Cattaneo Pág. 2

3 A Chicha y Beto los pilares. A Ani, Roberto y Fabi mis inicios. A Fer, Vali y Chabe mi presente, mi vida y mi futuro. A Dios por lo aprehendido en esta segunda oportunidad. Ing. María Florencia Pollo Cattaneo Pág. 3

5 AGRADECIMIENTOS A la Universidad Tecnológica Nacional, por ser el Alma Mater de mi profesión y donde quedan mis hijos académicos. Al Instituto Tecnológico de Buenos Aires, por llevar adelante una política consistente de formación en R.R.H.H. A mis directores M Ing Enrique Fernández y Dr Ramón García Martínez, por estar siempre y compartir conmigo su saber. A mi ángel de la guarda, Ing Hernán Amatriain, por estar y ser así, excepcional. A mis amigos M Ing Paola Britos, Darío Rodríguez, Mariana Acosta, por confiar en mí y no dejarme caer. Al Dr. José Tana, por ser mi padre académico. A Marcela Sotelo y Marcela Palomeque, porque con su arte me permiten encontrar el hermoso equilibrio en la vida. A mi amigo Diego Rambaud, por estar conmigo en mis inicios y ser un verdadero compañero. Al Lic Carlos A Uhalde, Ing Alejandra Torrá y M Ing Oscar Schivo, por enseñarme y dejarme crecer a su lado. A mis amigos Ing Pablo Pytel, Ing Cinthia Vegega, Ing Facundo Lonardi, Ing Anabella De Battista, Ing Eugenia Dearriba e Ing Daniel Svartman, por seguirme y acompañarme en la docencia. A mis Alumnos, quienes con su cariño y aliento acompañaron el avance de este proyecto. A todos los que interpusieron obstáculos en mi camino, porque me ayudaron a madurar y a ser quien soy. A mis reinas Valentina y Chabela, porque existen y me llenan el alma. A Fernando, por estar siempre, y dejarme ser. Ing. María Florencia Pollo Cattaneo Pág. 5

7 ÍNDICE 1.- INTRODUCCIÓN De qué trata esta Tesis? A quién está dirigida? Organización del documento INTRODUCCIÓN AL PROBLEMA Introducción a la agregación de experimentos Introducción a los métodos de agregación estadísticos Métodos Paramétrios Diferencia de Medias Ponderadas Estimación de Efecto Individual Estimación de Efecto Global Response Ratio Paramétrico Estimación de Efecto Individual Estimación de Efecto Global Métodos No Paramétricos Vote Counting Estimación de Efecto Individual Estimación de Efecto Global Response Ratio No Paramétrico Estimación de Efecto Individual Estimación de Efecto Global Estudios controlados en IS Definición del Problema Solución Propuesta Definición de variables poblacionales Definición de variables muestrales Desarrollo del proceso de simulación Análisis de resultados 052 Ing. María Florencia Pollo Cattaneo Pág. 7

8 Análisis por intervalo de confianza Análisis de correlación ESTUDIO DE VIABILIDAD DEL SISTEMA Establecimiento del alcance del Sistema Estudio de la solicitud Descripción general del Sistema Catálogo de Objetivos de la Evaluación del Sistema de Info Definición de Requisitos del Sistema Identificación de Requisitos (Generalidades) Identificación de Requisitos Catalogación de Requisitos Catálogo de Requisitos Arquitectura Tecnológica Estudio de alternativas de solución Preselección de alternativas de solución Alternativas de solución Descripción de alternativas de solución Descripción de la solución Valoración de las alternativas Estudio de riesgos Valoración de alternativas Planificación de alternativas Plan de trabajo de la alternativa Selección de la solución Convocatoria de la presentación Plan de presentación de alternativas Evaluación de las alternativas de selección Solución propuesta Aprobación de la solución Aprobación final de la solución 072 Ing. María Florencia Pollo Cattaneo Pág. 8

9 4.- ANÁLISIS DEL SISTEMA DE INFORMACIÓN Definición del problema Determinación del alcance del Sistema Modelo de negocio Identificación de los usuarios participantes y finales Catálogo de usuarios Establecimiento de Requisitos Especificación de casos de uso Casos de uso Análisis de los casos de uso Identificación de clases asociadas a un caso de uso Identificación de clases Descripción de la interacción de objetos Identificación de la interacción de objetos Análisis de clases Identificación de responsabilidades y atributos Definición de responsabilidades y atributos Identificación de asociaciones y agregaciones Diagrama de clases donde se identifican asociaciones y agregaciones Identificación de generalizaciones Descripción de las generalizaciones identificadas Identificación de interfaces de usuario Especificación de principios generales de la interfaz Principios generales de la interfaz Especificación de formato individuales de la interfaz de pantalla Modelo de navegación de la interfaz Descripción de las características generales de cada pantalla Definición de las pantallas del Sistema Especificación de formatos de impresión Formatos de impresión Análisis de consistencia y especificación de requisitos 151 Ing. María Florencia Pollo Cattaneo Pág. 9

10 Verificación de los modelos Verificación de modelos Análisis de consistencia entre métodos Análisis de consistencia Especificación del plan de pruebas Plan de pruebas Alcance Ítems y características a probar Características que no van a ser probadas Actividades a realizar Pruebas unitarias Pruebas de sistema Pruebas de aceptación Ejecución de las pruebas unitarias Ejecución de las pruebas de sistema Amplitud de las pruebas Reporte de fallas de las pruebas Trazabilidad de requerimientos Disponibilidad de ítems de prueba Disponibilidad de recursos para las pruebas Criterio para evaluar instancias de prueba Evaluación de instancias de prueba aplicado a cada ítems Evaluación de instancias de prueba sobre la aplicación Criterio de suspensión y reiniciación de pruebas Artefactos de las pruebas Actividades de prueba Procedimiento de pruebas Necesidades de ambiente Hardware Software Seguridad Modo de uso 173 Ing. María Florencia Pollo Cattaneo Pág. 10

11 Certificación de entorno Responsabilidades Riesgos y contingencias de pruebas Aprobación del Análisis del Sistema de Información Presentación y aprobación del Análisis del Sistema de Info DISEÑO DEL SISTEMA DE INFORMACIÓN Definición de la Arquitectura del Sistema Definición de niveles de Arquitectura Descripción de los niveles de Arquitectura del Sistema Identificación de requisitos de diseño y construcción Descripción de los requisitos adicionales Especificaciones de excepción Catálogo de excepciones Identificación de subsistemas de diseño Subsistemas de diseño Especificación de entorno tecnológico Especificación de Hardware Especificación de Software Especificación de Comunicación Especificación de requisitos de operación y seguridad Diseño de la arquitectura de soporte Diseño de subsistemas de soporte Diseño detallado del sistema de soporte Diseño de casos de uso reales Identificación de clases asociadas a un caso de uso Clases asociadas a los casos de uso Revisión de la interfaz de usuario Resultado de la revisión de la interfaz de usuario Diseño de clases Identificación de atributos de las clases Atributos de clases 208 Ing. María Florencia Pollo Cattaneo Pág. 11

12 Identificación de operaciones de clases Operaciones de clases Diagrama de clases de diseño Especificación de necesidades de migración y carga inic. de datos Carga inicial de datos Diseño físico de datos Diseño del modelo físico de datos Verificación y aceptación de la arquitectura del sistema Verificación de la especificación de diseño Resultado de la verificación de la especificación de diseño Análisis de consistencia de las especificaciones de diseño Consistencia de las especificaciones de diseño Aceptación de la arquitectura del sistema Generación de especificaciones de construcción Especificación del entorno de construcción Definición de componentes y subsistemas de construcción Componentes y subsistemas de construcción Especificación técnica del plan de prueba Especificación del entorno de prueba Entorno de pruebas Revisión de la planificación de pruebas Planificación de pruebas Pruebas unitarias Pruebas de integración Pruebas del sistema Aprobación del Diseño del Sistema de Información Presentación y Aprobación del Diseño del Sistema de Info CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN Preparación del entorno de generación y construcción Implantación de la base de datos física o ficheros Preparación del entorno de construcción 281 Ing. María Florencia Pollo Cattaneo Pág. 12

13 Generación del entorno de trabajo Generación del código de los componentes y procedimientos Generación del código de componentes Generación del código de los procedimientos de operación y seguridad Generación de Procedimientos de Operación y Seguridad Ejecución de las Pruebas Unitarias Realización y Evaluación de las Pruebas Unitarias Resultado de la Realización de las Pruebas Unitarias Ejecución de las Pruebas del Sistema Realización de las Pruebas del Sistema Resultado de la Realización de las Pruebas del Sistema Evaluación del Resultado de las Pruebas del Sistema Resultado de la Evaluación de los Resultados de las Pruebas de Sistema Aprobación del Sistema de Información IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA Establecimiento del Plan de Implantación Definición del Plan de Implantación Formación de usuarios finales y equipo de pruebas Preparación de la infraestructura necesaria para la incorporación del sistema al entorno de operación Ejecución de carga inicial Realización de las pruebas de implementación y aceptación del sistema Formalización del plan de mantenimiento Especificación del Equipo de Implantación Equipo de Implantación Incorporación del Sistema al Entorno de Operación Preparación de la Instalación Descripción de la Instalación 298 Ing. María Florencia Pollo Cattaneo Pág. 13

14 Realización de la Instalación Instalación del sistema Carga de Datos al Entorno de Operación Migración y Carga inicial de Datos Instalación del sistema Pruebas de Implantación del Sistema Preparación de las Pruebas de Implantación Pruebas de Implantación Realización de las Pruebas de implantación Prueba de Implantación Evaluación del Resultado de las Pruebas de Implantación Evaluación de la Prueba de Implantación Pruebas de Aceptación del Sistema Realización de las Pruebas de Aceptación Pruebas de Aceptación Presentación y Aprobación del Sistema APLICACIÓN DEL SISTEMA PARA EL ANÁLISIS DE TÉCNICAS DE AGREGACIÓN Preparación de las pruebas Especificación de los valores de prueba Asignación de límites para las distintas pruebas Realización de las pruebas Ejecución de las pruebas Análisis de resultados Análisis por intervalo de confianza Análisis de correlación Análisis de resultados obtenidos Valores con media experimental mayor que la de control (Análisis por intervalo de confianza) Valores con media experimental menor que la de control (Análisis por intervalo de confianza) 314 Ing. María Florencia Pollo Cattaneo Pág. 14

15 Valores con media experimental igual que la de control (Análisis por intervalo de confianza) Resultado del análisis de correlación CONCLUSIÓN Y FUTURAS LÍNEAS DE TRABAJO Conclusiones Futuras líneas de trabajo BIBLIOGRAFÍA Y GLOSARIO Bibliografía Glosario 333 A.- APÉNDICE 339 A.1.- Gestión de proyectos 339 A Inicio del Proyecto 340 A Estimación del esfuerzo 341 A.2.- Gestión de Configuración 347 A La Gestión de Configuración en el presente Proyecto 348 A Definición del proceso de gestión de configuración del Software 349 A Especificaciones de gestión 349 A Organización 350 A Actividades a realizar 351 A Implementación del plan de gestión de configuración 351 A Actividades de gestión de configuración 354 A Identificación de la configuración 354 A Diseño de registros 358 A Control de la configuración 359 A Auditoría de la configuración 359 A Recogida y retención de registros 360 A.3.- Plan de aseguramiento de la calidad 361 A Objetivos de calidad 362 A Definición de los recursos 363 Ing. María Florencia Pollo Cattaneo Pág. 15

16 A Métricas de proyecto 363 A Definición de las métricas 363 A Descripción de las métricas a aplicar en esta etapa del proyecto 366 A Auditorías 369 Ing. María Florencia Pollo Cattaneo Pág. 16

17 Capítulo 1 Introducción Ing. María Florencia Pollo Cattaneo Pág. 17

19 1.- INTRODUCCIÓN 1.1. DE QUÉ TRATA ESTA TESIS? Esta tesis trata sobre el desarrollo de una herramienta de software que ayude al análisis de precisión de las técnicas estadísticas de agregación de experimentos en contextos poco maduros. Está pensada para ser aplicada directamente al campo de la Ingeniería de Software. El trabajo persigue como objetivo principal, generar una herramienta que facilite el análisis y comparación de las diferentes técnicas de agregación para evaluar los resultados de distintos experimentos A QUIÉNES ESTÁ DIRIGIDA? El trabajo se encuentra dirigido principalmente a Ingenieros de Software y cátedras universitarias vinculadas al software, que se dediquen a la experimentación dentro del campo de la Ingeniería de Software. Ing. María Florencia Pollo Cattaneo Pág. 19

20 Asimismo, puede ser usado, entrenando adecuadamente al usuario, en cualquier otro contexto experimental poco maduro, siendo especialmente útil para aplicar en el campo de la investigación experimental ORGANIZACIÓN DEL DOCUMENTO El material se divide en 10 capítulos que abarcan la totalidad del trabajo de tesis, el cual se explica brevemente a continuación: El capítulo 1. Introducción (el presente capítulo) sintetiza los objetivos de la tesis, a quiénes está dirigida, y de qué manera se encuentra organizado el material de la misma. El capítulo 2. Introducción al problema, presenta un panorama de la situación actual, mostrando el contexto que da origen al trabajo de tesis. El capítulo 3. Estudio de viabilidad del sistema comprende la documentación resultante del proceso EVS: Estudio de la Viabilidad del Sistema de la metodología Métrica Versión III. La documentación cubre: el análisis de la situación actual, la descripción general del sistema, el estudio de las diferentes alternativas de solución, y la selección de la alternativa más adecuada. El capítulo 4. Análisis del sistema comprende la documentación resultante del proceso ASI: Análisis del Sistema de Información de la metodología Métrica Versión III. La documentación cubre el modelado en UML (Unified Modelling Language) [Booch & Jacobson & Rumbaugh, 1998] del negocio, los casos de uso (documentados en el formato sugerido por Larman Craig) [Larman, C., 2003], los prototipos de interfaces de usuario, y la estructura y comportamiento del sistema en términos de clases de análisis. Dentro de este capítulo se incluye también el diseño de las pruebas de la fase de análisis. Ing. María Florencia Pollo Cattaneo Pág. 20

21 El capítulo 5. Diseño del sistema comprende la documentación resultante del proceso DSI: Diseño del Sistema de Información de la metodología Métrica Versión III. La documentación cubre el modelado en UML del diseño arquitectónico del sistema [Booch & Jacobson & Rumbaugh, 1998 ; Larman, C., 2003] y los subsistemas que lo conforman [Sturm, J., 1999], y la estructura y comportamiento del mismo en términos de clases de diseño. Dentro de este capítulo se incluye también el Plan de pruebas. El capítulo 6. Construcción del sistema comprende la documentación resultante del proceso CSI: Construcción del Sistema de Información de la metodología Métrica Versión III. La documentación cubre la descripción del entorno de construcción [Sturm, J., 1999] y los resultados de las pruebas unitarias, de integración y del sistema. El capítulo 7. Implantación y aceptación del sistema comprende la documentación resultante del proceso IAS: Implantación y Aceptación del Sistema de la metodología Métrica Versión III. La documentación cubre la incorporación del sistema al entorno productivo y los resultados de las pruebas de implantación y aceptación. El capítulo 8. Aplicación del Sistema para Análisis de Técnicas de Agregación explica cómo se emplea el sistema desarrollado para realizar varias pruebas y exponer el resultado de las mismas, así como también al análisis de lo resultados para establecer la precisión de las técnicas aplicadas. El capítulo 9. Conclusiones y Futuras líneas de trabajo contiene las conclusiones obtenidas luego de finalizado el trabajo de tesis, y las futuras líneas de trabajo a seguir por aquellos interesados en el tema. Ing. María Florencia Pollo Cattaneo Pág. 21

22 El capítulo 10. Bibliografía y Glosario contiene las referencias bibliográficas utilizadas para el trabajo de tesis, y el glosario con los términos empleados en el mismo. El apéndice A. Contiene documentación anexa al contenido de la tesis. Entre los anexos figuran la documentación referente a las interfases provista por Métrica Versión III. Esto comprende la documentación resultante de las interfaces Gestión del proyecto [COCOMO II, 1999; Cosmos,1998], Gestión de la configuración [Gesmet, 2000], y Aseguramiento de la calidad. Ing. María Florencia Pollo Cattaneo Pág. 22

23 Capítulo 2 Introducción al Problema Ing. María Florencia Pollo Cattaneo Pág. 23

25 2.- INTRODUCCION AL PROBLEMA Desde hace varios años, la cantidad de experimentos realizados dentro del ámbito de la Ingeniería del Software (IS) se ha incrementado significativamente. Estos experimentos abarcan los más variados temas, como ser: el desempeño de las técnicas de prueba, la educción de requisitos, o el desempeño de los lenguajes de programación, entre otros. Si bien los experimentos aportan conocimientos interesantes en cada caso, en general son pequeños (rara vez utilizan más de 20 sujetos experimentales, por ejemplo, los estudios experimentales identificados en [Davis, A.; et al; 2006] y [Tonella P., 2007]). Por ello, para que la información que aportan sea valiosa, los resultados deben agregarse para poder obtener conclusiones avaladas con la mayor evidencia empírica posible INTRODUCCIÓN A LA AGREGACIÓN DE EXPERIMENTOS La agregación de experimentos consiste en combinar los resultados de varios experimentos, que analizan el comportamiento de un par de tratamiento específico, para obtener un único resultado final. El nuevo resultado será más general y fiable que los resultados individuales, porque el mismo estará sustentado por un mayor nivel de evidencia empírica [Cochrane, 2008]. Ing. María Florencia Pollo Cattaneo Pág. 25

26 Si bien se han desarrollado estudios tendientes a determinar el nivel de precisión de las técnicas de agregación [Lajeunesse, M.; et al; 2003], estos estudios fueron realizados pensando en la aplicación de los métodos de agregación en contextos experimentales maduros (por ejemplo: medicina), donde la cantidad de sujetos experimentales y la cantidad de estudios a agregar son altas. Lamentablemente el actual contexto experimental de la Ingeniería del Software dista bastante de un contexto maduro, en general los proceso de agregación incluyen pocos estudios que, a su vez, contienen pocos sujetos experimentales [Davis, A.; et al; 2006]. La presente tesis tiene como objetivo desarrollar un sistema que permita determinar el nivel de precisión de los métodos de agregación en contextos experimentales poco maduros, como el que actualmente presenta la Ingeniería del Software (donde es habitual que los estudios posean pocos sujetos experimentales y los procesos de agregación incluyan pocos experimentos) INTRODUCCIÓN A LOS MÉTODOS DE AGREGACIÓN ESTADÍSTICOS En el campo de la estadística se denominan parámetros [Epidat; 2008] a todas aquellas medidas que expresan alguna característica general de una población, tales como la media de los valores que toma una variable en todos los individuos de la población o la varianza de estos valores. Para estos ejemplos de parámetros, el valor real de la población suele ser desconocido porque para su cálculo sería necesario observar a la totalidad de los individuos que componen la población (algo imposible en la mayoría de las situaciones). A lo sumo se podrá observar a un grupo (más o menos grande) de individuos de esta población, o sea, una muestra. Con la información recogida en los datos de una muestra se puede hacer una aproximación al conocimiento de la población, en particular, al valor de sus parámetros. Este es un método de conocimiento inductivo o inferencial, conocido como Inferencia Estadística. Su desarrollo formal fue iniciado por [Neyman, J. y Pearson, E.; 1933] y hoy en día engloba una amplia colección de métodos con los que se pueden extraer Ing. María Florencia Pollo Cattaneo Pág. 26

27 conclusiones sobre los parámetros poblacionales a partir de la información que expresan los datos observados en una muestra. De forma general se distinguen dos grandes categorías de métodos de inferencia: Métodos para estimación de parámetros Métodos para contraste de hipótesis. En general cuando se analiza un estudio particular que analice el comportamiento de dos o más tratamientos, se aplican métodos de contraste de hipótesis que permiten indicar si las diferencias en los resultados obtenidos por los tratamientos son significativas o no. Por otra parte, cuando se lleva adelante un proceso de agregación lo que se intenta es obtener un índice de mejora, que indique en cuánto, uno de los tratamientos mejora el desempeño del otro. Por ello, los métodos de agregación deben ser considerados métodos de estimación de parámetros y no de contraste de hipótesis, a pesar de que sus resultados se utilizan para determinar si un tratamiento es mejor que otro. Como todo parámetro estadístico, el índice de mejora estimado en los procesos de agregación no puede analizarse como un resultado puntual, ya que es sabido que el mismo es, una estimación aproximada. Por ello además del tamaño de efecto deberá estimarse su respectivo intervalo de confianza [Gardner M; Altman D.; 1992]. Los límites de un intervalo de confianza representa el rango de valores entre los cuales podrá hallarse el valor exacto del parámetro con una confianza determinada (esta confianza es fijada por el investigador y en general se acostumbra a utilizar valores tales como: 0.90, 0.95 ó 0.99). Como sucede con la mayoría de los métodos estadísticos, existen dos grupos de métodos de agregación bien diferenciados [Hedges, L.; Olkin, I.; 1985]: el conformado por los métodos Paramétricos y el conformado por los métodos No Paramétricos. Ing. María Florencia Pollo Cattaneo Pág. 27

28 Los métodos paramétricos [García, R; 2004] basan su aplicación en la evaluación de un conjunto de variables estadísticas (llamadas parámetros) que determinan la naturaleza de la población. Mientras que, los métodos No Paramétricos [García, R; 2004] no realizan suposiciones respecto de la naturaleza de la población. El tener conocimiento de cómo es el comportamiento de la población aumenta la precisión de los parámetros estimados (esto se conoce como potencia estadística). Es la principal ventaja que poseen los métodos paramétricos respecto de los no paramétricos. Para poder aplicar un método paramétrico se debe poder determinar, entre otras cosas, si las poblaciones analizadas están normalmente distribuidas o, si tienen homogeneidad de varianzas. Pero para poder establecer el tipo de distribución en una población o la homogeneidad de las varianzas, se requiere que las muestras tomadas posean un tamaño mínimo (en general mayor a 300 sujetos experimentales [García, R; 2004]) o que los investigadores posean un conocimiento acabado del comportamiento del fenómeno que le permita deducir este aspecto. En caso de que el investigador no pueda determinar claramente cómo es la distribución del fenómeno, deberá utilizar métodos de agregación no paramétricos (a pesar de que su potencia estadística sea menor a la de los métodos paramétricos) MÉTODOS PARAMÉTRICOS Como se mencionó anteriormente, los métodos paramétricos basan su aplicación en la evaluación de un conjunto de parámetros que determinan la naturaleza de la población. A nivel general es necesario corroborar que [Hedges, L.; Olkin, I.; 1985]: Las muestras fueron tomadas de forma aleatoria, Las muestras fueron tomadas de forma independiente, Las poblaciones se encuentran normalmente distribuidas, Ing. María Florencia Pollo Cattaneo Pág. 28

29 Las poblaciones tienen homogeneidad de varianzas Además de los aspectos antes mencionados, los métodos de agregación paramétricos, requieren que se verifique la compatibilidad de las variables respuesta reportadas en los estudios experimentales que se van a agregar. Por ejemplo, no es válido juntar en un proceso de agregación, estudios que analicen el tamaño de los programas en cantidad de líneas de código con otros que analicen el mismo tamaño, en base a la cantidad de bytes que el programa ocupa en el disco rígido. Lo que si es válido, es reunir estudios que utilicen diferentes escalas de la misma variable, como podrían ser cantidad de líneas de código medidas en unidades o en miles de líneas. A continuación se presentan los dos métodos de agregación paramétricos que serán descriptos en el presente capítulo: Diferencia de Medias Ponderadas (DMP): ampliamente aplicado en medicina [Cochrane; 2008] y aplicado ya en IS [Dyba, T.; et al; 2007], Response Ratio versión paramétrica (RR paramétrico): creado recientemente dentro del campo de la ecología [Gurevitch, J. and L.V. Hedges, 1993] y todavía no utilizado en IS DIFERENCIA DE MEDIAS PONDERADAS La técnica Diferencias Medias Ponderadas (DMP o WMD por sus siglas en inglés) [Glass, G.; 1976] es la técnica de estimación de effect size, o mejora de un tratamiento respecto de otro, más conocida y difundida para el tratamiento de variables continuas. Esta técnica es conceptualmente sencilla: el estimador de efecto individual (representa la tasa de mejora de un tratamiento respecto del otro para cada uno de los experimentos) se estima como el cociente de las diferencias entre las medias y el desvío estándar y, el efecto global (representa la tasa de mejora general de un tratamiento respecto de otro, obtenido mediante la combinación de n estudios experimentales) se calcula como una media ponderada de los estimadores de efecto de los estudios individuales. Ing. María Florencia Pollo Cattaneo Pág. 29

30 ESTIMACIÓN DE EFECTO INDIVIDUAL La estimación del efecto individual consiste en estimar, para un estudio particular, en cuánto el tratamiento Experimental es mejor (o no) que el tratamiento de control. Esto se realiza dividiendo la diferencia de medias de ambos tratamientos, por la varianza conjunta [Glass, G; 1976]. La función de estimación es la siguiente: E Y Y g = S P C g es el Effect Size (efecto individual) Y s medias de los grupos experimental (E) y de control (C) S p desvío estándar conjunto Tabla IP 1: Estimación de efecto individual (effec Size) para un estudio El desvío estándar conjunto mencionado en la función anterior se estima: S ( n E 2 C C 1)( s ) + ( n 1)( s ) E n + n 2 E P = C 2 S p desvío estándar conjunto S s son el desvío estándar del grupo experimental (E) y de control (C) n s son el numero de sujetos del grupo experimental (E) y de control (C) Tabla IP 2: Estimación del desvío estándar conjunto La función de estimación de efecto [Glass, G; 1976] fue mejorada por [Hedges, L.; Olkin, I.; 1985], quien incorporó a la misma un factor de corrección J que permite mejorar la precisión de los resultados cuando la cantidad de sujetos experimentales es baja (fundamentalmente menor a 10). Este aspecto es relevante a la hora de desarrollar un proceso de agregación en IS, ya que en el actual contexto, es habitual que los experimentos posean, pocos sujetos experimentales (por ejemplo, ver [Burton, A.; et al; 1990.]). La nueva función (recomendada actualmente por [Cochrane, 2008]) es la siguiente: Ing. María Florencia Pollo Cattaneo Pág. 30

31 E C Y Y d es el Effect Size d = J ( N 2) S J (N 2) = factor de corrección P Y s son la media de los grupos experimental (E) y de control (C) S p es el desvío estándar conjunto N es el número de sujetos conjunto (n E + n C ) Tabla IP 3: Estimación del Effect Size El factor de ajuste J puede estimarse mediante la siguiente función: 3 J = 1 4N 9 J es el factor de ajuste N es el número de sujetos conjunto (n E + n C ) Tabla IP 4: Estimación del factor de ajuste Una vez estimado el tamaño de efecto, podrá estimarse el intervalo de confianza mediante la siguiente función [Hedges, L.; Olkin, I.; 1985]: d / 2 α / 2 Zα v λ d + Z v d es el Effect Size Z es la cantidad de desvíos estándar que separan, al nivel de significancia dado, la media del límite. En general se utiliza 1.96 (α = 0,05) v es el error típico Tabla IP 5: Estimación del intervalo de confianza La función para estimar el error típico, mencionado en la función anterior, es la siguiente [Hedges, L.; Olkin, I.; 1985]: 2 ñ + d v = E 2( n + n C ) v es el error típico ñ = (n E +n C ) / (n E *n C ) d son el effect size de los estudios individuales n s son el número de sujetos del grupo experimental (E) y de control (C) Tabla IP 6: Estimación del error típico Ing. María Florencia Pollo Cattaneo Pág. 31

32 ESTIMACIÓN DE EFECTO GLOBAL Si todos los estudios incluidos en el proceso de agregación fueran igualmente precisos, bastaría con estimar el tamaño de efecto para cada estudio particular, y luego promediar los mismos para obtener un tamaño de efecto global. Sin embargo, en la práctica, no todos los estudios tienen la misma precisión; por ello cuando se los combine, se debe asignar un mayor peso a los estudios que permiten obtener información más fiable. Esto, se logra combinando los resultados mediante un promedio ponderado. El cual, a diferencia de un promedio común (donde todos los elementos son promediados tomando su valor absoluto), se multiplica a cada valor por un factor de peso antes de ser promediado [Borenstein, M.; et al; 2007]. Como se mencionó en el párrafo anterior, la estimación del efecto global se realiza como el promedio ponderado de los efectos individuales [Borenstein, M.; et al; 2007] [Hedges, L.; Olkin, I.; 1985]. Donde cada estudio es ponderado en función de la inversa de la varianza. De esta forma, los estudios con mayor precisión (en general los que incluyan mayor cantidad de sujetos experimentales) recibirán una mayor ponderación por considerar que sus resultados son más fiables, o tienen menor posibilidad de incurrir en un error. La función de estimación general es la siguiente: dw = w 1 * d w k * d k dw es el efecto global w 1 w k son los pesos de lose studios individuales d 1..d k son los efectos individuales de cada estudio Tabla IP 7: Estimación del efecto global Si bien la ponderación de cada estudio se realiza en base a la inversa de la varianza, existen dos visiones de cómo debe estimarse esta varianza. Estas versiones son conocidas como: modelo de efecto fijo y modelo de efectos aleatorios. Nos concentraremos en el modelo de efecto fijo. Ing. María Florencia Pollo Cattaneo Pág. 32

33 A continuación se describe en detalle cómo estimar el efecto global: En primer lugar vamos a presentar la función de estimación de efecto global [Hedges, L.; Olkin, I.; 1985]: 2 di / σ i ( d) d* = 2 1/ σ i ( d) d* es el tamaño de efecto global 2 di / σ i ( d) es la sumatoria de los efectos individuales 2 1/ σ i ( d) es la sumatoria de la inversa varianza Tabla IP 8: Estimación del efecto global Para estimar el efecto global, es necesario calcular la varianza de los estudios ( σ 2 ( d) ), de la siguiente manera [Hedges, L.; Olkin, I.; 1985]: 2 2 ñi + d i σ i ( d) = E 2( n i + n C i ) ñ i = (n E i+n C i) / (n E i*n C i) d i son los efectos individuales n s número de sujetos de los grupos experimental y de control Tabla IP 9: Estimación de la varianza Una vez estimado el efecto global, podrá estimarse el intervalo de confianza del mismo, mediante la siguiente función [Hedges, L.; Olkin, I.; 1985]: d * α 2 Zα / 2 v λ d * + Z / v d* es el efecto global Z es la cantidad de desvíos estándar que separan, al nivel de significancia dado, la media del límite. En general es 1,96 (α = 0,05) 2 v es el error típico (1/ 1/ σ i ( d) ) Tabla IP 10: Estimación del intervalo de confianza Ing. María Florencia Pollo Cattaneo Pág. 33

34 RESPONSE RATIO PARAMÉTRICO El segundo método paramétrico que vamos a presentar es el Response Ratio. Si bien este método no es tan conocido como WMD, actualmente este método es recomendado en los procesos de agregación desarrollados dentro del ámbito de la ecología [Word, B.; et al; 2007] [Gurevitch, J. and Hedges, L.; 2001]. Uno de los motivos de esta preferencia es que, el mismo, tiene un bajo nivel de error cuando la cantidad de estudios incorporados al proceso de agregación es pequeña [Lajeunesse, M & Forbes, M.; 2003], por lo que parece un método adecuado para el actual contexto de la IS. El Response Ratio es conceptualmente muy simple, consiste en estimar un índice de mejora entre un tratamiento Experimental y otro de Control mediante el cociente de ambas medias. Este cociente permite estimar la proporción de mejora existente entre ambos tratamientos [Gurevitch, J. and Hedges, L.; 2001][Miguez, E. & Bollero, G; 2005]. Así, por ejemplo, un ratio de 1.3 indicará que el tratamiento experimental es un 30% mejor que el de control; un ratio de 0.7 indicará que el tratamiento de control es un 30% mejor que el experimental. Como puede verse la esencia de este índice es realmente sencilla. La aplicación del método consta de dos pasos: primero, se debe estimar el Ratio de cada uno de los experimentos (lo que llamaremos estimación del efecto individual). Una vez estimado el Ratio individual, podrá estimarse el Ratio o efecto global (representa la tasa de mejora general de un tratamiento respecto de otro, obtenido mediante la combinación de n estudios experimentales), para ello se realizará un promedio ponderado de los ratios individuales ESTIMACIÓN DE EFECTO INDIVIDUAL Para estimar el Response Ratio de un estudio particular, como se mencionó anteriormente, se debe dividir la media del tratamiento Experimental por la media del tratamiento de Control [Hedges, L.; et al; 1999] como se muestra a continuación: Ing. María Florencia Pollo Cattaneo Pág. 34

35 Y RR = Y E C RR es el Response Ratio Y s son las medias de los tratamientos experimental y de control Tabla IP 11: Estimación del RR Si bien, realizar en forma directa el cociente de ambas medias permite obtener un índice de mejora para un estudio en particular, para que la combinación de un conjunto de estudios sea más precisa se le incorporó, a la misma, el logaritmo natural [Hedges, L.; et al; 1999] [Miguez, E. & Bollero, G; 2005]. Esto permite linealizar los resultados (mientras que el RR es afectado más por los cambios en el denominador que en el numerador, el Ln (RR), gracias a las propiedades de los logaritmos, afecta de modo parejo al numerador y al denominador) y así normalizar su distribución, convirtiéndolo en un método apropiado para estimaciones de conjuntos de experimentos pequeños. La nueva función de estimación es la siguiente: L = Ln (RR) Una vez estimado el ratio, podrá estimarse el intervalo de confianza del mismo mediante la siguiente función [Gurevitch, J. and Hedges, L.; 2001] [Miguez, E. & Bollero, G; 2005]: l 2 Zα / 2 v λ l + Zα / v L = Ln (RR) Z es la cantidad de desvíos estándar que separan, al nivel de significancia dado, la media del límite. En general se utiliza 1.96 (α = 0.05) v es el error típico Tabla IP 12: Estimación del intervalo de confianza La función para estimar el error típico, mencionado en la función anterior, es la siguiente [Hedges, L.; et al; 1999]: Ing. María Florencia Pollo Cattaneo Pág. 35

36 S v = E n Y 2E E S + C n Y 2C C V es el error típico S 2 s son la varianza de los grupos experimental (E) y de control (C) Y s son las medias de los grupos experimental (E) y de control (C) n s son los números de sujetos de los grupos experimental (E) y de control (C) Tabla IP 13: Estimación del error típico Una vez estimados el intervalo de confianza, se debe aplicar al mismo el antilogaritmo para obtener nuevamente el índice de relación ESTIMACIÓN DE EFECTO GLOBAL La estimación del Ratio Global se realiza mediante el promedio ponderado de los ratios individuales [Gurevitch, J. and Hedges, L.; 2001]. Donde cada estudio es ponderado en función de la inversa de la varianza. Dado que la varianza tiende a disminuir cuando la cantidad de sujetos aumenta, (ya que esto reduce el nivel de error experimental), los estudios que incluyan mayor cantidad de sujetos experimentales recibirán una mayor ponderación, por considerar que sus resultados son más fiables, o tienen menor posibilidad de incurrir en un error, que los resultados obtenidos en los estudios pequeños. A continuación se describe la función de estimación del Ratio Global: k * Wi Li i= 1 L* = k * W i= 1 i L* es el efecto global L i es el efecto individual W i es el factor de peso = 1/v (donde v se estima como se indico en la funció (20)) Tabla IP 14: Estimación del efecto global Ing. María Florencia Pollo Cattaneo Pág. 36

37 Una vez estimado el Ratio Global, podrá estimarse el intervalo de confianza del mismo mediante la siguiente función [Gurevitch, J. and Hedges, L.; 2001] [Miguez, E. & Bollero, G; 2005]: L * / 2 * α / 2 Zα v λ L + Z v L* es el efecto global Z es la cantidad de desvíos estándar que separan, al nivel de significancia dado, la media del límite. En general se utiliza 1.96 (α = 0.05) i v es el error típico (1/ 1/ W ) ) Tabla IP 15: Estimación del intervalo de confianza Al igual que en el caso de la estimación del ratio individual, una vez estimados el intervalo de confianza, se debe aplicar el anti-logaritmo a los resultados para obtener nuevamente el índice de relación MÉTODOS NO PARAMÉTRICOS Como se mencionó anteriormente, los métodos no paramétricos no realizan suposiciones respecto del comportamiento de los parámetros estadísticos que afectan a la muestra. Facilita su aplicación, ya que se requiere un mínimo análisis previo del fenómeno, pero también reduce la potencia de los resultados, debido a que, como el conocimiento del fenómeno es menor, se debe ser más cauteloso a la hora de expresar los resultados. Dado que para la estadística es preferible equivocarse diciendo que los resultados de dos estudios son iguales cuando en realidad no lo son (error de tipo II), a equivocarse diciendo que existen diferencias entre los resultados cuando en realidad no la hay (error de tipo I). Los métodos no paramétricos aplican una política conservadora que se ve reflejada en el mayor tamaño de los intervalos de confianza [Conover W; 1980] que se estiman. De Ing. María Florencia Pollo Cattaneo Pág. 37

38 esta forma el riesgo de que el resultado verdadero no se encuente contemplado en el intervalo de confianza se reduce. A continuación se presentan los métodos de agregación no paramétricos que se van a analizar en detalle en las siguientes sesiones: Vote Counting (VC), es un método que intenta estimar, en base al signo de las diferencias entre las medias, el tamaño de efecto que se hubiera estimado mediante DMP si se contara con los parámetros estadísticos necesarios. En la actualidad se conoce un trabajo desarrollado en el ámbito de la IS que ha utilizado este método [Miller, J.; 2000] Response Ratio versión no paramétrica (RR no paramétrico), creada recientemente dentro del campo de la ecología [Worn, B.; 2007] y todavía no utilizado en IS VOTE COUNTING El Vote Counting es un método que requiere muy poca información para poder ser aplicado, básicamente conoce si existe o no diferencia entre las medias de los tratamientos y la cantidad de sujetos experimentales utilizados en cada estudio experimental. Si bien existen varias versiones de esta técnica, en este apartado se describirá la versión desarrollada por [Hedges, L.; Olkin, I.; 1985]. En este caso el método es más que una simple suma de votos, ya que el objetivo de la misma es estimar el tamaño de efecto (que se hubiera podido estimar si se contara con todos lo datos necesarios para aplicar WMD) partiendo del signo de las diferencias de las medias y la cantidad de sujetos experimentales, los cuales se combinan mediante la aplicación de un proceso de inferencia iterativo que intenta determinar cuál es el efecto de mayor probabilidad. Es importante destacar que cuando se aplica esta técnica, no es necesario que las variables respuesta incluidas en el proceso de agregación sean exactamente las mismas, pero si que estén relacionadas. Por ejemplo, es válido combinar estudios experimentales Ing. María Florencia Pollo Cattaneo Pág. 38

39 que midan el tamaño de un programa en líneas de código con otro que mida el tamaño en función de la cantidad de MB que ocupa el programa en el disco rígido. Sin embargo hay que ser muy cautelosos, ya que cuanto más diferentes sean las variables respuesta incluidas en el proceso de agregación, mayor será el riesgo de incurrir en conclusiones poco fiables ESTIMACIÓN DE EFECTO INDIVIDUAL Debido a que este método sólo requiere de cada estudio particular el signo de la diferencia de las medias y la cantidad de sujetos experimentales, no es posible estimar el tamaño de efecto para los estudios de forma particular. A continuación sólo se describe cómo se estima el tamaño de efecto global (para el conjunto de estudios seleccionados) ESTIMACIÓN DE EFECTO GLOBAL Como se mencionó anteriormente, la presente versión del Vote counting [Hedges, L.; Olkin, I.; 1985] tienen como objetivo estimar un tamaño del efecto de forma similar a como lo hace el método WMD. Es decir no se limitará a decir: el tratamiento experimental es mejor que el tratamiento de control por qué tiene mayor cantidad de votos (estudios a favor), sino que estimará un índice de mejora que permitirá determinar cuánto mejor es un tratamiento que el otro. Para aplicar esta técnica en primer lugar hay que fijar lo que se denomina valor de corte [Mohagheghi, P., & Conradi, R.; 2004], este valor de corte indica a partir de cuándo se considera que la diferencia de medias es válida para asignar un voto. En general se recomienda que la diferencia sea significativa al 0.05 (recomendado por [Hedges, L.; Olkin, I.; 1985] para estimar un efecto similar al estimado mediante WMD), pero puede establecerse un valor de corte menor, por ejemplo sólo analizar si la diferencia de las medias es mayor o menor a cero. Una vez fijado el valor de corte, se debe analizar cada uno de los estudios para determinar a qué categoría pertenece su voto. Las posibles categorías a las cuales serán asignados los votos son: Ing. María Florencia Pollo Cattaneo Pág. 39

40 Efecto positivo (el tratamiento Experimental es mejor que el de Control) Efecto negativo (el tratamiento de Control es mejor que el Experimental) Efecto nulo (ambos tratamientos son iguales) A efectos de aplicación del método, los votos sólo podrán tomar los valores 1 ó 0, perteneciendo al primer grupo los efectos positivos y al segundo los efectos negativos y nulos. Una vez establecidos los votos, se realiza un proceso de inferencia iterativo, basado en el método de máxima Verosimilitud. Este proceso, en base a los votos y la cantidad de sujetos experimentales de cada estudio, determinará cuál es el efecto de mayor probabilidad de ocurrencia dentro de un rango de efectos prefijados (variará entre -0.5 y 0.5 tal lo indicado en [Hedges, L.; Olkin, I.; 1985]). La función que permite establecer la probabilidad de cada efecto es la siguiente [Hedges, L.; Olkin, I.; 1985]: k X i ln[ 1 φ( ñδ )] + i 1 ( 1 X ) lnφ( ñδ ) L( δ X1,..., X i) = = i L(δ X 1,.X n ) es la probabilidad del efecto δ es el tamaño de efecto a testear X i es el valor del voto de cada estudio ñ = (n E +n C ) / (n E *n C ) φ es la probabilidad obtenida de la distribución normal Tabla IP 16: Estimación de las probabilidades de los efectos Una vez establecido el efecto de mayor probabilidad se podrá determinar el intervalo de confianza para el mismo, el cual en general es más amplio que el estimado Ing. María Florencia Pollo Cattaneo Pág. 40

41 mediante WMD. La función para estimar el intervalo de confianza es la siguiente [Hedges, L.; Olkin, I.; 1985]: δ Z α / 2 v( δ ) λ δ + Zα / 2 v( δ ) δ es el tamaño de efecto de mayor probabilidad Z es la cantidad de desvíos estándar que separan, al nivel de significancia dado, la media del límite. En general se utiliza 1.96 (α = 0.05) v(δ) es el error típico Tabla IP 17: Estimación del intervalo de confianza Donde el error típico (v(δ)) se estima como se muestra en la siguiente función [Hedges, L.; Olkin, I.; 1985]: k 1 2 [ Di ] v( δ ) = { } p (1 p ) i= 1 i i 1 k es el número de experimentos p = 1 φ( ñ δ ) i i D 1 i = ñi e 2π 1 2 ( ñ i δ ) 2 Tabla IP 18: Estimación del error típico RESPONSE RATIO NO PARAMÉTRICO El segundo método no paramétrico que vamos a presentar es el Response Ratio. Es una variación del Response Ratio paramétrico presentado en la sección ( Response Ratio (paramétrico) ). Como se mencionó anteriormente, el Response Ratio consiste en estimar un índice de mejora entre un tratamiento Experimental y otro de Control mediante el cociente de ambas medias. Este cociente permite estima la proporción de mejora existente entre ambos tratamientos [Gurevitch, J. and Hedges, L.; 2001][ Miguez, E. & Bollero, G; 2005][Worn, B.; et al; 2007]. Ing. María Florencia Pollo Cattaneo Pág. 41

42 La versión no paramétrica del Response Ratio no es muy diferente a la versión paramétrica, la diferencia principal radica en que esta versión del método no requiere conocer cómo es el comportamiento de la población (qué clase de distribución tiene) y no utiliza las varianzas de los tratamientos para la estimación del ratio global. De esta forma, se facilita su aplicación en entornos experimentales donde los reportes no son completos [Worn, B.; et al; 2007], como ocurre en este momento con la IS (por ejemplo, ver [Crandall Klein, et. al., 1989]). Es importante destacar que a pesar de ser un método no paramétrico, según los estudios hechos por [Lajeunesse, M.; et al; 2003] el nivel de error de esta técnica es bajo y similar al error de la versión paramétrica. Tal como sucede con la versión paramétrica del RR, para aplicar esta técnica es necesario que las variables respuesta reportadas en los distintos experimentos sean compatibles entre sí, por ejemplo, no es válido juntar en un proceso de agregación estudios que analicen el tamaño de los programas en cantidad de líneas de código con otros que analicen el mismo tamaño en base a la cantidad de bytes que el programa ocupa en el disco rígido. Lo que si es válido juntar son estudios que utilicen diferentes escalas de la misma variable, como podrían ser cantidad de líneas de código medidas en unidades o en miles líneas. Como se mencionó cuando se describió el apartado RR paramátrico, la aplicación del método consta de dos pasos: primero se debe estimar el Ratio de cada uno de los experimentos (lo que llamaremos estimación del efecto individual). Una vez hecho esto, podrá estimarse el Ratio o efecto global (representa la tasa de mejora general de un tratamiento respecto de otro, obtenido mediante la combinación de n estudios experimentales), para ello se realizará un promedio ponderado de los ratios individuales ESTIMACIÓN DE EFECTO INDIVIDUAL La estimación del Response Ratio consiste en dividir la media del tratamiento Experimental por la media del tratamiento de Control [Hedges, L.; et al; 1999] como se muestra a continuación: Ing. María Florencia Pollo Cattaneo Pág. 42

43 Y RR = Y E C RR es el Response Ratio Y s son la media de los grupos experimental (E) y de control (C) Tabla IP 18: Estimación del RR Como se mencionó cuando se describió a la versión paramétrica de este método, para mejorar la precisión de esta función (RR=Y E /Y C ), se incorporó a la misma el logaritmo natural [Hedges, L.; et al; 1999] [Miguez, E. & Bollero, G; 2005]. Esto permite linealizar los resultados (mientras que el RR es afectado más por los cambios en el denominador que en el numerador, el Ln (RR) afecta de modo parejo al numerador y el denominador) y, de esa forma, normalizar su distribución, convirtiéndolo en un método apropiado para estimaciones de experimentos de pequeño tamaño. La nueva función de estimación es la siguiente: L i = Ln(RR) Una vez estimado el tamaño de efecto, podrá estimarse el intervalo de confianza mediante la siguiente función [Gurevitch, J. and Hedges, L.; 2001] [Miguez, E. & Bollero, G; 2005]: L Zα v λ L + Z v L i = Ln(RR) i / 2 i α / 2 Z es la cantidad de desvíos estándar que separan, al nivel de significancia dado, la media del límite. En general se utiliza 1.96 (α = 0.05) V es el error típico Tabla IP 19: Estimación del intervalo de confianza Para estimar el error típico, esta versión del Response Ratio no requiere conocer las varianzas, como lo hace la versión original. En su lugar hace una estimación en base a la Ing. María Florencia Pollo Cattaneo Pág. 43

44 cantidad de sujetos y el response ratio, como se muestra a continuación [Worn, B.; et al; 2007]: nc + n v = n n E C E 2 Ln( RR ) + 2( n + n ) C E v es el error típico n s son los números de sujetos de los grupos experimental (E) y de control (C) RR es el Response Ratio Tabla IP 20: Estimación del error típico Una vez estimados el intervalo de confianza, se debe aplicar el anti-logaritmo a los resultados para obtener nuevamente el índice de relación. Es importante destacar que esta situación traer aparejado que el nuevo intervalo de confianza no sea simétrico ESTIMACIÓN DE EFECTO GLOBAL La estimación del efecto global se realiza mediante el promedio ponderado de los efectos individuales. Aquí cada estudio es ponderado en función de su tamaño (se debe a que no se conocen las varianzas reales). De esta forma, los estudios que incluyan mayor cantidad de sujetos experimentales recibirán una mayor ponderación por considerar que sus resultados son más fiables, o tienen menor posibilidad de incurrir en un error, que los resultados obtenidos en los estudios pequeños. A continuación se describe la función de estimación: k * Wi Li i= 1 L* = k * W i= 1 i L* es el efecto global L i es el efecto individual W i es el factor de peso = 1/v (donde v se estima como se indico en la funció (29)) Tabla IP 21: Estimación del RR global Ing. María Florencia Pollo Cattaneo Pág. 44

45 Una vez estimado el tamaño de efecto, podrá estimarse el intervalo de confianza mediante la siguiente función [Gurevitch, J. and Hedges, L.; 2001] [Miguez, E. & Bollero, G; 2005]: L * / 2 * α / 2 Zα v λ L + Z v L* es el efecto global Z es la cantidad de desvíos estándar que separan, al nivel de significancia dado, la media del límite. En general se utiliza 1.96 (α = 0.05) i v es el error típico (1/ 1/ W ) ) Tabla IP 22: Estimación del intervalo de confianza Al igual que en el caso de la estimación del efecto individual, una vez estimados el intervalo de confianza, se debe aplicar el anti-logaritmo a los resultados para obtener nuevamente el índice de relación ESTUDIOS CONTROLADOS EN IS Si bien se indicó que la cantidad de estudios que se producen dentro del ámbito de la IS se ha venido incrementando en los últimos años, la IS no es una ciencia con gran tradición en experimentación [Sjoberg, D.; et al; 2005]. En general, existen los siguientes problemas: La escasez de experimentos, replicaciones y homogeneidad entre los mismos. [Davis, A.; et al; 2006] y [Miller, J.; 2000]. La carencia de estándares para reportes de experimentos. Por ejemplo, [Burton, A.; et al; 1990.] no publican varianzas y [Crandall Klein, et. al., 1989] ni siquiera reporta las medias de los resultados experimentales. Ing. María Florencia Pollo Cattaneo Pág. 45

46 La falta de estandarización de las variables respuesta. Por ejemplo, los trabajos de [Agarwal, R.; Tanniru, M.; 1990] y [Woody, J.; Will, R.; Blanton, J.; 1996] utilizan diferentes variables respuesta para analizar un mismo aspecto, lo cual hace que estos experimentos no puedan ser agregados. Estas falencias fueron corroboradas en el proceso de revisión desarrollado por [Sjoberg, D.; et al; 2005]. Allí se confirman, entre otras cosas, la baja cantidad de experimentos por tópico y la baja cantidad de sujetos experimentales que utilizan los mismos DEFINICIÓN DEL PROBLEMA Si bien existen pruebas que muestran la potencia de las técnicas de agregación en contextos experimentales maduros (por ejemplo medicina), no se conoce como es el comportamiento de las mismas en contextos experimentales poco maduros en los cuales la cantidad de estudios experimentales a agregar y la cantidad de sujetos experimentales en dichos estudios son escasos, como sucede actualmente en Ingeniería del Software SOLUCIÓN PROPUESTA Para determinar la precisión de las distintas técnicas de agregación se llevará a cabo un proceso de simulación basado en la técnica de Monte Carlo. La simulación de Monte Carlo es una técnica que combina conceptos estadísticos (muestreo aleatorio) con la capacidad que tienen los ordenadores para generar números pseudo-aleatorios y automatizar cálculos. El proyecto incluye desarrollar un sistema para que realice las siguientes tareas: Establecer el contexto del problema mediante la definición de los valores de las variables poblacionales y la estimación de los efectos poblacionales. Ing. María Florencia Pollo Cattaneo Pág. 46

47 Generar, en base a los valores poblacionales establecidos mediante el método de Monte Carlo, el resultado de n conjuntos de experimentos. Agregar los resultados mediante los estimadores de efecto. Analizar qué relación existe entre los resultados poblacionales respecto de los resultados de las agregaciones hechas en base a los resultados simulados. Comparar de a pares los valores de efecto que fueron estimados por las diferentes técnicas. Dentro de este contexto se van a definir dos tipos de variables: las variables independientes y las variables dependientes. Se denomina variables independientes a aquéllas variables que son manipuladas por el investigador en un experimento con el objeto de estudiar cómo incide sobre la expresión de la variable dependiente. A la variable independiente también se la conoce como variable explicativa. Por otro lado, a la variable dependiente se la conoce como variable explicada. Esto significa que las variaciones en la variable independiente repercutirán en variaciones en la variable dependiente. A continuación se definen el conjunto de variables participantes DEFINICIÓN DE VARIABLES POBLACIONALES Variables independientes: estos valores fueron inferidos en base a los resultados de la revisión hecha por [Guerini, M.; 2008], donde se corrobora el alto nivel de variación de los resultas de los diferentes estudios experimentales: Tamaño de Efecto (mediante DMP), donde δ va desde 0 hasta 2 (avanzando con un paso de 0.1) Media del tratamiento experimental = 100 Ing. María Florencia Pollo Cattaneo Pág. 47

48 Desvío estándar conjunto = 10 Variables dependientes: Media del tratamiento de control. Para cada tamaño de efecto definido se estimará la media del tratamiento de control en función de la media del tratamiento experimental y el desvío c δσ µ = E estándar conjunto. La función de estimación será: µ RR Para cada combinación de valores de medias (experimental y de control) E µ RR = C se estimará el correspondiente Ratio. La función de estimación es µ DEFINICIÓN DE VARIABLES MUESTRALES Tomando como base las definiciones de las variables poblacionales, a continuación se describen las variables muestrales que se van a generar mediante el proceso de simulación. Variables Independientes: Cantidad de Sujetos Experimentales (de 2 a 20 variando de 1 en 1) Cantidad de estudios (de 2 a 10 variando de 1 en 1) Media del tratamiento experimental (generada por simulación para los parámetros poblacionales) Media del tratamiento de control (generada por simulación para los parámetros poblacionales) Desvío estándar (generada por simulación para los parámetros poblacionales) Ing. María Florencia Pollo Cattaneo Pág. 48

49 Variables Dependientes: El estimador del tamaño de Efecto (mediante WMD y VC) + Intervalo de confianza (al 90%, 95% y 99%) El estimador del RR (mediante RR paramétrico y no paramétrico) + Intervalo de confianza (al 90%, 95% y 99%) DESARROLLO DEL PROCESO DE SIMULACIÓN Como se mencionó anteriormente, se construirá mediante el método de Monte Carlo un conjunto de resultados de experimentos, estos resultados se corresponderán con los rangos de valores de las variables independientes definidas en la sección Variables muestrales. Para cada combinación de valores de las variables independientes, se construirán poblaciones. El objetivo del análisis es determinar el comportamiento de las variables dependientes a medida que varían las variables independientes definidas. Es decir, se intentará determinar si parámetros como la cantidad de sujetos experimentales o la cantidad de experimentos afectan a la precisión del efecto global estimado. Tabla IP 23): Para comparar los resultados se utilizarán una tabla con el siguiente formato (ver Ing. María Florencia Pollo Cattaneo Pág. 49

50 Y E Y C S N E WMD e Int. confianza 90% WMD e Int. confianza 95% WMD e Int. confianza 99% RR paramétrico e Int. confianza 90% RR paramétrico e Int. confianza 95% RR paramétrico e Int. confianza 99% RR no paramétrico e Int. confianza 90% RR no paramétrico e Int. confianza 95% RR no paramétrico e Int. confianza 99% Vote Counting paramétrico e Int. confianza 90% Vote Counting paramétrico e Int. confianza 95% ???????????? ???????????? Tabla IP 23: Modelo de tabla para evaluación de resultados Vote Counting paramétrico e Int. confianza 99% Ing. María Florencia Pollo Cattaneo Pág. 50

51 En la tabla 2.2 se describen cada una de las columnas definidas en la tabla 2.1: YE YC S N E Símbolo Descripción Es el valor de la media del tratamiento experimental en base a la cual se construyó la simulación Es el valor de la media del tratamiento de control en base a la cual se construyó la simulación Es el valor de la varianza conjunta en base a la cual se construyó la simulación Es la cantidad de sujetos experimentales que poseen los experimentos que se construyeron por la simulación Es la cantidad de experimentos que hacen parte del la agregación que se construyeron por la simulación WMD e int de confianza (*) RR paramétrico e int de confianza (*) RR no paramétrico e int de confianza (*) Vote counting e int de confianza (*) Es el tamaño de efecto promedio que se estimó, mediante la técnica WMD, con su respectivo intervalo de confianza Es el ratio promedio que se estimó, mediante la técnica Response ratio paramétrica, con su respectivo intervalo de confianza Es el ratio promedio que se estimó, mediante la técnica Response ratio no paramétrica, con su respectivo intervalo de confianza Es el ratio promedio que se estimó, mediante la técnica Vote Counting, con su respectivo intervalo de confianza Tabla IP 24: Descripción de las columnas de la tabla 2 (*) Se ha creado una columna por cada valor de confianza definido (90 %, 95% y 99%). Ing. María Florencia Pollo Cattaneo Pág. 51

52 ANÁLISIS DE RESULTADOS ANÁLISIS POR INTERVALO DE CONFIANZA Se contabilizará cuántas veces el intervalo de confianza estimado contiene al valor de efecto o ratio de la población. En base a esto, se establecerá el nivel de confianza del estimador respecto de la población. Determinado a partir de qué cantidad de sujetos y experimentos la contención del efecto real se encuentra contenida el 100% de las veces ANÁLISIS DE CORRELACIÓN realizar son: El objetivo es comparar las técnicas de a pares, las principales comparaciones a Análisis de correlación y diferencia de medias entre los resultados obtenidos mediante Diferencias Medias Ponderadas y Vote-Counting Análisis de correlación y diferencia de medias entre los resultados obtenidos mediante Response-Ratio Paramétrico y no Paramétrico Ing. María Florencia Pollo Cattaneo Pág. 52

53 Capítulo 3 Estudio de Viabilidad del Sistema Ing. María Florencia Pollo Cattaneo Pág. 53

55 3.- ESTUDIO DE VIABILIDAD DEL SISTEMA El objetivo del Estudio de Viabilidad del Sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas. La solución obtenida como resultado del estudio puede ser la definición de uno o varios proyectos que afecten a uno o varios sistemas de información ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situación actual. A partir del estado inicial, la situación actual y los requisitos planteados, se estudian las alternativas de solución. Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en la adquisición de productos software del mercado o soluciones mixtas. Se describen cada una de las alternativas, indicando los requisitos que cubre. Una vez descritas cada una de las alternativas planteadas, se valora su impacto en la organización, la inversión a realizar en cada caso y los riesgos asociados. Esta información se analiza con el fin de evaluar las distintas alternativas y seleccionar la más adecuada, definiendo y estableciendo su planificación. Ing. María Florencia Pollo Cattaneo Pág. 55

56 Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información que afecte al sistema objeto de este estudio, se dispondrá de un conjunto de productos que proporcionarán información a tener en cuenta en todo el proceso ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA En esta actividad se estudia el alcance de la necesidad existente, realizando una descripción general de la misma. Se determinan los objetivos, se inicia el estudio de los requisitos y se identifican las unidades organizativas afectadas estableciendo su estructura. Se analizan las posibles restricciones, tanto generales como específicas, que puedan condicionar el estudio y la planificación de las alternativas de solución que se propongan. Si la justificación económica es obvia, el riesgo técnico bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable, no es necesario profundizar en el estudio de viabilidad del sistema, analizando posibles alternativas y realizando una valoración y evaluación de las mismas, sino que ésta se orientará a la especificación de requisitos, descripción del nuevo sistema y planificación. Se detalla la composición del equipo de trabajo necesario para este proceso y su planificación. Finalmente, con el fin de facilitar la implicación activa de los usuarios en la definición del sistema, se identifican sus perfiles, dejando claras sus tareas y responsabilidades ESTUDIO DE LA SOLICITUD Se realiza una descripción general de la necesidad, y se estudian las posibles restricciones de carácter económico, técnico, operativo y legal que puedan afectar al sistema. Antes de iniciar el estudio de los requisitos del sistema se establecen los Ing. María Florencia Pollo Cattaneo Pág. 56

57 objetivos generales del Estudio de Viabilidad, teniendo en cuenta las restricciones identificadas anteriormente. Si el sistema objeto de estudio se encuentra en el ámbito de un Plan de Sistemas de Información vigente, se debe de tomar como referencia el catálogo de requisitos y la arquitectura de información resultante del mismo, como información adicional para la descripción general del sistema y determinación de los requisitos iniciales DESCRIPCIÓN GENERAL DEL SISTEMA Existe una necesidad, que es contar con un Software para generar un banco de pruebas que permita analizar la fiabilidad de las diferentes técnicas estadísticas de agregación de experimentos en un contexto experimental poco maduro como es la Ingeniería de Software. Este sistema es un desarrollo autónomo, es decir, no se vincula con los demás proyectos de desarrollo que se llevan a cabo en las Universidades donde el proyecto va a exponerse como tesis de la carrera Magíster en Sistemas de Información, ni tampoco con los Sistemas de Información existentes en las mismas. Es de hacer notar que el actual proyecto persigue un fin académico y no comercial, es decir, no se espera obtener fines de económicos con el actual proyecto de desarrollo. En virtud de lo expuesto anteriormente se detallan, a continuación, un conjunto de puntos que no serán tenidos en cuanta dentro del Estudio de Viabilidad del Sistema: Recuperación de la inversión económica, debido a que el proyecto no apunta a ser un producto comercial. Interacción entre el actual desarrollo y los demás proyectos de desarrollo de las Universidades: Instituto Tecnológico de Buenos Aires y Facultad de Informática de la Universidad Politécnica de Madrid. Ing. María Florencia Pollo Cattaneo Pág. 57

58 Contratación de recursos humanos que colaboren en el desarrollo del proyecto. Se evaluarán dentro del actual Estudio de Viabilidad del Sistemas restricciones de tipos funcionales y técnicas CATÁLOGO DE OBJETIVOS DE LA EVALUACIÓN DEL SISTEMA DE INFORMACIÓN Como se indicó en el punto anterior (descripción general del sistema) el actual sistema tiene como principal objetivo la construcción de un sistema software que permita generar un banco de pruebas que permitan analizar la fiabilidad de las distintas técnicas estadísticas de agregación de experimentos en un contexto experimental poco maduro como es la Ingeniería de Software, dentro del ámbito académico. Por tal motivo, se asume que la viabilidad del proyecto es alta desde todo punto de vista y, en base a lo que indica Métrica III (ver párrafo detallado a continuación) el objetivo de la fase análisis de viabilidad del sistema del sistema estará centrada en la especificación de requisitos, descripción del nuevo sistema y planificación. Párrafo aclaratorio de Métrica III: Si la justificación económica es obvia, el riesgo técnico bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable, no es necesario profundizar en el estudio de viabilidad del sistema, analizando posibles alternativas y realizando una valoración y evaluación de las mismas, sino que éste se orientará a la especificación de requisitos, descripción del nuevo sistema y planificación [Métrica III, 2000]. sistema: A continuación se detallan los objetivos principales del estudio de viabilidad del Analizar la situación actual Describir las posibles mejoras Ing. María Florencia Pollo Cattaneo Pág. 58

59 Analizar las alternativas de solución Establecer los requisitos del nuevo sistema DEFINICIÓN DE REQUISITOS DEL SISTEMA Esta actividad incluye la determinación de los requisitos generales, mediante una serie de sesiones de trabajo con los usuarios participantes, que hay que planificar y realizar. Una vez finalizadas, se analiza la información obtenida definiendo los requisitos y sus prioridades, que se añaden al catálogo de requisitos que servirá para el estudio y valoración de las distintas alternativas de solución que se propongan IDENTIFICACIÓN DE REQUISITOS (GENERALIDADES) Para la obtención de las necesidades que ha de cubrir el sistema en estudio, se debe decidir qué tipo de sesiones de trabajo se realizarán y con qué frecuencia tendrán lugar, en función de la disponibilidad de los usuarios participantes. Si se ha realizado el Estudio de la Situación Actual, puede ser conveniente seleccionar la información de los sistemas de información existentes que resulte de interés para el desarrollo de dichas sesiones de trabajo. Una vez establecidos los puntos anteriores, se planifican las sesiones de trabajo con los usuarios participantes identificados al estudiar el alcance del Estudio de Viabilidad del Sistema, y se realizan de acuerdo al plan previsto. La información obtenida depende del tipo de sesión de trabajo seleccionado. Ing. María Florencia Pollo Cattaneo Pág. 59

60 IDENTIFICACIÓN DE REQUISITOS Si bien no se ha considerado necesario la realización del análisis de los sistemas que actualmente operan en la organización, por considerar al actual proyecto como un desarrollo autónomo, a continuación se detallan nuevos requisitos a incorporar al sistema luego de una sesión de trabajo llevada a cabo entre la tesista y el director del proyecto: Perfiles de Usuarios del Sistema: El Sistema Software a desarrollar es monousuario. Este debe ser un usuario experimentado que utilizará todas las funciones del sistema para generar el banco de pruebas del que se habla en la descripción general del sistema. Consultas básicas del Sistema: El Sistema Software debe generar un banco de pruebas para evaluar la aplicación de las distintas técnicas estadísticas de agregación de experimentos, por lo que la única consulta al sistema será poder visualizar las pruebas realizadas con las distintas técnicas. Validación de Usuarios: Al tratarse de un sistema monousuario, no existirá la validación del mismo, ya que se trata de un gasto innecesario en el contexto. Requisitos no funcionales: Para el almacenamiento de los resultados de las distintas técnicas de agregación se generará un archivo de texto con todos los resultados y, una planilla de cálculo con los mismos datos. Ing. María Florencia Pollo Cattaneo Pág. 60

61 La pantalla principal del sistema deberá mostrar las distintas técnicas estadísticas de agregación para seleccionar las alternativas que se deseen analizar. El sistema actual no manejará los permisos del Sistema Operativo para restringir o habilitar el acceso de un usuario a una determinada carpeta o documento. El sistema sólo va a correr en Plataforma Windows CATALOGACIÓN DE REQUISITOS Se analiza la información obtenida en las sesiones de trabajo para la Identificación de Requisitos, definiendo y catalogando los requisitos (funcionales y no funcionales) que debe satisfacer el sistema, indicando sus prioridades. Se incluirán también requisitos relativos a distribución geográfica y entorno tecnológico CATÁLOGO DE REQUISITOS Requisitos funcionales: sistema: A continuación, en la figura EVS 1, se muestran los requisitos funcionales del Figura EVS 1, Requisitos Funcionales del Sistema Ing. María Florencia Pollo Cattaneo Pág. 61

62 Descripción de los requisitos funcionales: RF 1: Simular resultado mediante técnica de Montecarlo El Sistema debe poder generar un banco de números obtenidos aleatoriamente que sirvan como simulación para la prueba de las distintas técnicas estadísticas de agregación de experimentos. Dicha base de números aleatorios debe seguir la distribución de probabilidad normal o Gaussiana. RF 2: Aplicar DMP Al realizar la prueba de las distintas técnicas estadísticas mencionadas en el capítulo 2, el Sistema debe ser capaz de generar los reportes correspondientes (ver Tabla IP 23). En este caso el usuario ejecutará la aplicación de la técnica de agregación conocida como Diferencia de Medias Ponderadas. RF 3: Aplicar RRP Al realizar la prueba de las distintas técnicas estadísticas mencionadas en el capítulo 2, el Sistema debe ser capaz de generar los reportes correspondientes (ver Tabla IP 23). En este caso el usuario ejecutará la aplicación de la técnica de agregación conocida como Response Ratio Paramétrico. RF 4: Aplicar RRNP Al realizar la prueba de las distintas técnicas estadísticas mencionadas en el capítulo 2, el Sistema debe ser capaz de generar los reportes correspondientes (ver Tabla IP 23). En este caso el usuario ejecutará la aplicación de la técnica de agregación conocida como Response Ratio No Paramétrico. Ing. María Florencia Pollo Cattaneo Pág. 62

63 RF 5: Aplicar VC Al realizar la prueba de las distintas técnicas estadísticas mencionadas en el capítulo 2, el Sistema debe ser capaz de generar los reportes correspondientes (ver Tabla IP 23). En este caso el usuario ejecutará la aplicación de la técnica de agregación conocida como Vote Counting. RF 6: Aplicar Varias Técnicas Al realizar la prueba de las distintas técnicas estadísticas mencionadas en el capítulo 2, el Sistema debe ser capaz de generar los reportes correspondientes (ver Tabla IP 23). En este caso el usuario ejecutará la aplicación de varias técnicas de agregación pudiendo escoger entre las siguientes cuatro: Diferencia de Medias Ponderadas. Response Ratio Paramétrico. Response Ratio No Paramétrico. Vote Counting. Requisitos no funcionales: sistema: A continuación, en la figura EVS 2, se muestran los requisitos no funcionales del Ing. María Florencia Pollo Cattaneo Pág. 63

64 Figura EVS 2, Requisitos No Funcionales del Sistema Descripción de los requisitos no funcionales: RNF 1: Interfaz Gráfica El Sistema debe contar con una Interfaz Gráfica que le permita al Usuario: Generar un conjunto de números aleatorios de distribución de probabilidad normal o Gaussiana. Seleccionar qué técnica de agregación se desea aplicar al banco de prueba para agregar en el reporte, pudiendo elegir entre las siguientes cuatro (todas calculan el efecto individual y global): Diferencia de medias ponderadas. Response Ratio paramétrico. Response Ratio no paramétrico. Vote Counting. Ing. María Florencia Pollo Cattaneo Pág. 64

65 Seleccionar en qué tipo de archivo se va a imprimir el reporte, pudiendo elegir entre las siguientes alternativas: Archivo de texto. Plantilla de cálculo de Microsoft Excel. RNF 2: Soporte de Sistemas Operativos La primer versión del sistema sólo podrá ser ejecutado desde el Sistema Operativo Windows (NT, 2000, XP o superiores). RNF 3: Restricciones de Carpetas El sistema actual no manejará los permisos del Sistema Operativo para restringir o habilitar el acceso de un usuario a una determinada carpeta o documento. RNF 4: Editor de Archivos En la primer versión del sistema sólo se podrá editar y modificar plantillas de cálculo hechas con Microsoft Excel. Los archivos de texto generados podrán ser editados con cualquier editor de texto, otorgando mayor portabilidad a este formato de reporte ARQUITECTURA TECNOLÓGICA A continuación se detallan, para el desarrollo del primer prototipo, los elementos tecnológicos más apropiados: Ing. María Florencia Pollo Cattaneo Pág. 65

66 Entorno de Hardware: El hardware mínimo para el desarrollo del primer prototipo será del tipo PCs. Pentium III o superiores (1.0 GHZ), con 256 MB de memoria RAM (o más) y un disco rígido de 20 GB (o superior). El hardware requerido para la ejecución del sistema será del tipo PCs. Pentium III o superiores (1.0 GHZ), con 128 MB de memoria RAM (o más) y un disco rígido de 20 GB (o superior). Sistema Operativo: El sistema operativo utilizado para la construcción del primer prototipo será Windows XP. El sistema operativo requerido para la ejecución del sistema será: Windows NT/XP/2000 o superior. Lenguaje de desarrollo: El lenguajes de desarrollo será Visual Basic.NET Base de Datos: El Sistema en su primer prototipo no contará con Base de Datos ESTUDIO DE ALTERNATIVAS DE SOLUCIÓN Este estudio se centra en proponer diversas alternativas que respondan satisfactoriamente a los requisitos planteados, considerando también los resultados obtenidos en el Estudio de la Situación Actual, en el caso de que se haya realizado. Ing. María Florencia Pollo Cattaneo Pág. 66

67 Teniendo en cuenta el ámbito y funcionalidad que debe cubrir el sistema, puede ser conveniente realizar, previamente a la definición de cada alternativa, una descomposición del sistema en subsistemas. En la descripción de las distintas alternativas de solución propuestas, se debe especificar si alguna de ellas se encuentra basada, total o parcialmente, en un producto existente en el mercado. Si la alternativa incluye un desarrollo a medida, se debe incorporar en la descripción de la misma un modelo abstracto de datos y un modelo de procesos, y en orientación a objetos, un modelo de negocio y un modelo de dominio PRESELECCIÓN DE ALTERNATIVAS DE SOLUCIÓN Una vez definidos los requisitos a cubrir por el sistema, se estudian las diferentes opciones que hay para configurar la solución. Entre ellas, hay que considerar la adquisición de productos software estándar del mercado, desarrollos a medida o soluciones mixtas. Dependiendo del alcance del sistema y las posibles opciones, puede ser conveniente realizar inicialmente una descomposición del sistema en subsistemas. Se establecen las posibles alternativas sobre las que se va a centrar el estudio de la solución, combinando las opciones que se consideren más adecuadas ALTERNATIVAS DE SOLUCIÓN No se conoce al momento ningún sistema que permita analizar el resultado de aplicar las distintas técnicas estadísticas de agregación de experimentos para evaluar su efectividad en un marco experimental poco maduro como es la Ingeniería de Software. Por tal motivo, la única alternativa viable para cubrir la necesidad existente es la construcción de un Software a tal efecto. Ing. María Florencia Pollo Cattaneo Pág. 67

68 DESCRIPCIÓN DE ALTERNATIVAS DE SOLUCIÓN Para cada alternativa propuesta, se identifican los subsistemas que cubre y los requisitos a los que se da respuesta. Se deben considerar también aspectos relativos a la cobertura geográfica (ámbito y limitaciones) de procesos y datos, teniendo en cuenta a su vez la gestión de comunicaciones y control de red. En la definición de cada alternativa, se propone una estrategia de implantación teniendo en cuenta tanto la cobertura global del sistema como la cobertura geográfica. Si la alternativa incluye desarrollo se describe el modelo abstracto de datos y el modelo de procesos, y en el caso de Orientación a Objetos, el modelo de negocio y, opcionalmente, el modelo de dominio. Se propone el entorno tecnológico que se considera más apropiado para la parte del sistema basada en desarrollo y se describen los procesos manuales. Si la alternativa incluye una solución basada en producto se analiza su evolución prevista, adaptabilidad y portabilidad, así como los costes ocasionados por licencias, y los estándares del producto. Igualmente se valora y determina su entorno tecnológico. En el desarrollo del presente Sistema de Software no existen alternativas de solución, por lo que realizaremos el análisis de la única alternativa existente, sin tener que compararla con ninguna otra DESCRIPCIÓN DE LA SOLUCIÓN En virtud de haberse definido como única alternativa viable la construcción de un nuevo sistema, para el cual se han definido los requisitos en función de los módulos Ing. María Florencia Pollo Cattaneo Pág. 68

69 funcionales que componen el mismo. Para cada módulo no existe alternativa de solución. A continuación se detalla la solución para cada módulo en particular: Módulo 1, Generación de Distribución Normal: Se genera un banco de prueba consistente en un conjunto de números aleatorios de distribución de probabilidad normal o Gaussiana para aplicarles en un proceso de simulación las distintas técnicas estadísticas de agregación de experimentos. Módulo 2, Consultas: Se consultará sobre la aplicación de las distintas técnicas, generándose el reporte correspondiente. Los reportes se imprimirán en un archivo de texto y una plantilla de cálculo de Microsoft Excel VALORACIÓN DE LAS ALTERNATIVAS Como mencionamos anteriormente no existen alternativas de solución en nuestro Sistema de Software, existiendo una única solución evidente que es la que desarrollaremos ESTUDIO DE RIESGOS Para la solución propuesta, que es el desarrollo de un Sistema Software para analizar la efectividad de las distintas técnicas estadísticas de agregación de experimentos en Ingeniería de Software, no existen riesgos evidentes, ya que se realizarán simulaciones donde no hay posibilidad de perder los resultados de experimentos reales, y los bancos de prueba pueden generarse en cualquier momento de la ejecución del Sistema. Ing. María Florencia Pollo Cattaneo Pág. 69

70 VALORACIÓN DE ALTERNATIVAS La única alternativa válida en la solución del problema planteado es la de construir el Sistema de Software mencionado PLANIFICACIÓN DE ALTERNATIVAS En función del análisis de riesgos realizado en la tarea anterior, y para cada una de las alternativas existentes: Se determina el enfoque más adecuado para llevar a buen fin la solución propuesta en cada alternativa. Se realiza una planificación, teniendo en cuenta los puntos de sincronismo con otros proyectos en desarrollo o que esté previsto desarrollar, según se ha recogido en el catálogo de requisitos. De esta manera se garantiza el cumplimiento del plan de trabajo en los restantes procesos del ciclo de vida PLAN DE TRABAJO DE LA ALTERNATIVA A continuación, en la tabla EVS 1, se detalla el plan de proyecto para la construcción del sistema, en forma de Diagrama de Gantt. Ing. María Florencia Pollo Cattaneo Pág. 70

71 Tabla EVS 1, Plan de Trabajo. Para la duración se tubo en cuenta el trabajo de un desarrollador trabajando 8 horas diarias cinco días a la semana (40 horas semanales) SELECCIÓN DE LA SOLUCIÓN Antes de finalizar el Estudio de Viabilidad del Sistema, se convoca al Comité de Dirección para la presentación de las distintas alternativas de solución, resultantes de la actividad anterior. En dicha presentación, se debaten las ventajas de cada una de ellas, incorporando las modificaciones que se consideren oportunas, con el fin de seleccionar la más adecuada. Finalmente, se aprueba la solución o se determina su inviabilidad. En este caso, por existir una única alternativa, solamente se evaluará la aprobación de la misma como solución al problema CONVOCATORIA DE LA PRESENTACIÓN Se efectúa la convocatoria de la presentación de las distintas alternativas propuestas, adjuntando los productos de la actividad anterior con el fin de que el Comité Ing. María Florencia Pollo Cattaneo Pág. 71

72 de Dirección pueda estudiar previamente su contenido. Se espera confirmación por parte del Comité de Dirección de las alternativas a presentar PLAN DE PRESENTACIÓN DE ALTERNATIVAS No existe, en virtud de haber una única alternativa de solución EVALUACIÓN DE LAS ALTERNATIVAS DE SELECCIÓN Una vez recibida la confirmación de qué alternativas van a ser presentadas para su valoración, se efectúa su presentación al Comité de Dirección, debatiendo sobre las ventajas e inconvenientes de cada una de ellas y realizando las modificaciones que sugiera dicho Comité, hasta la selección de la solución final SOLUCIÓN PROPUESTA aprobada o no. Es la única alternativa que existe, por lo que se evaluará solamente si es APROBACIÓN DE LA SOLUCIÓN El Comité de Dirección da su aprobación formal o determina la inviabilidad del sistema, por motivos económicos, de funcionalidad como resultado del incumplimiento de los requisitos identificados en plazos razonables o de cobertura de los mismos, etc APROBACIÓN FINAL DE LA SOLUCIÓN En una reunión mantenida entre la Tesista y el Director del proyecto, se dio como válida a la actual propuesta de desarrollo y se considera aprobada la misma. Ing. María Florencia Pollo Cattaneo Pág. 72

73 Capítulo 4 Análisis del Sistema de Información Ing. María Florencia Pollo Cattaneo Pág. 73

75 4.- ANÁLISIS DEL SISTEMA DE INFORMACIÓN El objetivo de este proceso es la obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema. Al ser MÉTRICA III una metodología que cubre tanto desarrollos estructurados como orientados a objetos, las actividades de ambas aproximaciones están integradas en una estructura común. En la primera actividad, Definición del Sistema, se lleva a cabo la descripción inicial del sistema de información, a partir de los productos generados en el proceso Estudio de Viabilidad del Sistema (EVS). Se delimita el alcance del sistema, se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. También se identifican los usuarios que participan en el proceso de análisis, determinando sus perfiles, responsabilidades y dedicaciones necesarias. Así mismo se elabora el plan de trabajo a seguir. Ing. María Florencia Pollo Cattaneo Pág. 75

76 La definición de requisitos del nuevo sistema se realiza principalmente en la actividad Establecimiento de Requisitos. El objetivo de esta actividad es elaborar un catálogo de requisitos detallado, que permita describir con precisión el sistema de información, y que además sirva de base para comprobar que es completa la especificación de los modelos obtenidos en las actividades: Identificación de Subsistemas de Análisis, Análisis de Casos de Uso, Análisis de Clases, Elaboración del Modelo de Datos, Elaboración del Modelo de Procesos y Definición de Interfaces de Usuario. Estas actividades pueden provocar la actualización del catálogo, aunque no se refleja como producto de salida en las tareas de dichas actividades, ya que el objetivo de las mismas no es crear el catálogo sino definir modelos que soporten los requisitos. Para la obtención de requisitos en la actividad Establecimiento de Requisitos se toman como punto de partida el catálogo de requisitos y los modelos elaborados en la actividad Definición del Sistema, completándolos mediante sesiones de trabajo con los usuarios. Estas sesiones de trabajo tienen como objetivo reunir la información necesaria para obtener la especificación detallada del nuevo sistema. Las técnicas que ayudan a la recopilación de esta información pueden variar en función de las características del proyecto y los tipos de usuario a entrevistar. Entre ellas podemos citar: las reuniones, entrevistas, Joint Application Design (JAD), etc. Durante estas sesiones de trabajo se propone utilizar la especificación de los casos de uso como ayuda y guía en el establecimiento de requisitos. Esta técnica facilita la comunicación con los usuarios y en el análisis orientado a objetos constituye la base de la especificación. A continuación se identifican las facilidades que ha de proporcionar el sistema, y las restricciones a que está sometido en cuanto a rendimiento, frecuencia de tratamiento, seguridad y control de accesos, etc. Toda esta información se incorpora al catálogo de requisitos. En la actividad Identificación de Subsistemas de Análisis, se estructura el sistema de información en subsistemas de análisis, para facilitar la especificación de los distintos modelos y la traza de requisitos. Ing. María Florencia Pollo Cattaneo Pág. 76

77 En paralelo, se generan los distintos modelos que sirven de base para el diseño. En el caso de análisis estructurado, se procede a la elaboración y descripción detallada del modelo de datos y de procesos, y en el caso de un análisis orientado a objetos, se elaboran el modelo de clases y el de interacción de objetos, mediante el análisis de los casos de uso. Se especifican, asimismo, todas las interfaces entre el sistema y el usuario, tales como formatos de pantallas, diálogos, formatos de informes y formularios de entrada. En la actividad Análisis de Consistencia y Especificación de Requisitos, se realiza la verificación y validación de los modelos, con el fin de asegurar que son: Completos, puesto que cada modelo obtenido contiene toda la información necesaria recogida en el catálogo de requisitos. Consistentes, ya que cada modelo es coherente con el resto de los modelos. Correctos, dado que cada modelo sigue unos criterios de calidad predeterminados en relación a la técnica utilizada, calidad de diagramas, elección de nombres, normas de calidad, etc.). En la actividad Especificación del Plan de Pruebas, se establece el marco general del plan de pruebas, iniciándose su especificación, que se completará en el proceso Diseño del Sistema de Información (DSI). La participación activa de los usuarios es una condición imprescindible para el análisis del sistema de información, ya que dicha participación constituye una garantía de que los requisitos identificados son comprendidos e incorporados al sistema y, por tanto, de que éste será aceptado. Para facilitar la colaboración de los usuarios, se pueden utilizar técnicas interactivas, como diseño de diálogos y prototipos, que permiten al Ing. María Florencia Pollo Cattaneo Pág. 77

78 usuario familiarizarse con el nuevo sistema y colaborar en la construcción y perfeccionamiento del mismo DEFINICIÓN DEL SISTEMA Esta actividad tiene como objetivo efectuar una descripción del sistema, delimitando su alcance, estableciendo las interfaces con otros sistemas e identificando a los usuarios representativos. Las tareas de esta actividad se pueden haber desarrollado ya en parte en el proceso de Estudio de Viabilidad del Sistema (EVS), de modo que se parte de los productos obtenidos en dicho proceso para proceder a su adecuación como punto de partida para definir el sistema de información DETERMINACIÓN DEL ALCANCE DEL SISTEMA En esta tarea se delimita el sistema de información, utilizando como punto de partida el modelo de procesos especificado en la descripción de la solución del proceso Estudio de Viabilidad del Sistema (EVS). Se indican qué procesos pertenecen al ámbito del Sistema de Información y se identifican las entidades externas al sistema que aportan o reciben información. Asimismo, se obtiene un modelo conceptual de datos identificando las entidades y relaciones que forman parte del sistema de información objeto de este análisis a partir del modelo abstracto de datos generado en la tarea Evaluación de Alternativas y Selección. En el caso de análisis orientado a objetos, antes de la captura de requisitos empleando los casos de uso, puede ser conveniente establecer el contexto del sistema a partir del modelo de negocio obtenido en el proceso Estudio de Viabilidad del Sistema (EVS), y además, opcionalmente, del modelo de dominio. El modelo de negocio especifica los procesos a los que se quiere dar respuesta en el sistema de información, en forma de casos de uso de alto nivel, y el subconjunto de objetos del dominio requerido para ello. Ing. María Florencia Pollo Cattaneo Pág. 78

79 En esta actividad se realiza, también, la definición del catálogo de requisitos del sistema a partir del catálogo de requisitos generado en el proceso Estudio de Viabilidad del Sistema (EVS). A medida que se van generando los productos anteriores, se recomienda la definición de un glosario de términos del ámbito de negocio, con el fin de conseguir una mayor precisión en la especificación del sistema de información. El glosario es un catálogo de términos general y común a todos los procesos, y susceptible de ser entrada o salida en cualquier tarea, de modo que por sencillez en las restantes tareas se omite la referencia al mismo. Para obtener esta información es necesario llevar a cabo sesiones de trabajo con los usuarios responsables del sistema de información que se está analizando MODELO DE NEGOCIO El modelo de negocio contempla los procesos principales del negocio bajo análisis y la forma en que los mismos se llevan a cabo. Dentro de este modelo, los procesos se representan mediante casos de uso de negocio. El detalle sobre las actividades llevadas a cabo y las entidades utilizadas para completar cada proceso, se documentan mediante diagramas de actividades. El negocio cubierto por el Sistema es básicamente la administración de las pruebas de aplicar las distintas técnicas estadísticas para agregación de experimentos en contextos experimentales pocos maduros, centrando nuestra atención en los experimentos dentro de la Ingeniería de Software, como se ilustra en la figura ASI 1. Figura ASI 1: Modelo de negocio Ing. María Florencia Pollo Cattaneo Pág. 79

80 Actores: Usuario: este actor representa al único usuario que utiliza el sistema para generar pruebas con las que analizar la aplicación de las distintas técnicas de agregación estadísticas. Casos de Uso: Generar simulación: el proceso principal del negocio es la generación de pruebas a través de un proceso de simulación que genera números aleatoriamente pero siguiendo una distribución de probabilidad normal. Como resultado de este proceso se obtiene la información de aplicar las distintas técnicas estadísticas para agregación de experimentos, y así poder compararlas dentro de un contexto determinado (en nuestro caso, se trata de un contexto experimental poco maduro). Las actividades llevadas a cabo para completar el proceso de generación de pruebas descripto en el caso de uso se muestra en el diagrama de la figura ASI 2 Figura ASI 2: Detalle de las actividades principales llevadas a cabo durante la generación de pruebas. Además de las actividades se incluyen, en este diagrama, las principales entidades. Ing. María Florencia Pollo Cattaneo Pág. 80

81 A continuación se describen las actividades detalladas en el diagrama: Generar Valores Normalmente Distribuidos: este proceso consiste en generar un conjunto de prueba de números aleatorios con distribución Gaussiana para simular el resultado de experimentos. Para esto, hay que indicar una serie de parámetros como son: la media del tratamiento experimental, la media del tratamiento de control, el desvío estándar del tratamiento experimental, el desvío estándar del tratamiento de control, la cantidad de sujetos experimentales, la cantidad de experimentos y la cantidad de simulaciones. Aplicar Técnicas de Agregación: este proceso consiste en aplicar las distintas técnicas de agregación estadísticas a los resultados de los experimentos simulados con sus efectos individuales y globales IDENTIFICACIÓN DE LOS USUARIOS PARTICIPANTES Y FINALES En esta tarea se identifican los usuarios participantes y finales, interlocutores tanto en la obtención de requisitos como en la validación de los distintos productos y, la aceptación final del sistema. Para ello, se actualiza el catálogo de usuarios generado previamente en el Estudio de Viabilidad del Sistema (EVS). Dada la importancia que la colaboración de los usuarios tiene en el proceso de obtención de los requisitos, es conveniente determinar quiénes van a participar en las sesiones de trabajo, especificando sus funciones y asignando responsabilidades. Así mismo, se informa del plan de trabajo a los usuarios identificados. El alcance de este plan de trabajo se limita al proceso de análisis. Ing. María Florencia Pollo Cattaneo Pág. 81

82 CATÁLOGO DE USUARIOS El sistema se encuentra concebido para un único usuario experimentado, y con interés dentro del campo de la experimentación de Software. Debido a que, en la presente versión no se realizará ninguna validación de usuario, no se definirá ningún código de acceso. Por lo tanto, no hablaremos de privilegios de usuario ESTABLECIMIENTO DE REQUISITOS En esta actividad se lleva a cabo la definición, análisis y validación de los requisitos, a partir de la información facilitada por el usuario, completándose el catálogo de requisitos obtenido en la actividad Definición del Sistema. El objetivo de esta actividad es obtener un catálogo detallado de los requisitos, a partir del cual se pueda comprobar que, los productos generados en las actividades de modelización se ajustan a los requisitos de usuario. Esta actividad se descompone en un conjunto de tareas que, si bien tienen un orden, exige continuas realimentaciones y solapamientos, entre sí y con otras tareas realizadas en paralelo. No es necesaria la finalización de una tarea para el comienzo de la siguiente. Lo que se tiene en un momento determinado es un catálogo de requisitos especificado en función de la progresión del proceso de análisis. Se propone como técnica de obtención de requisitos la especificación de los casos de uso de la orientación a objetos, siendo opcional en el caso estructurado. Dicha técnica ofrece un diagrama simple y una guía de especificación en las sesiones de trabajo con el usuario ESPECIFICACIÓN DE CASOS DE USO Esta tarea es obligatoria en el caso de orientación a objetos, y opcional en el caso de análisis estructurado, como apoyo a la obtención de requisitos. Ing. María Florencia Pollo Cattaneo Pág. 82

83 El objetivo de esta actividad es especificar cada caso de uso identificado en la tarea anterior, desarrollando el escenario. Para completar los casos de uso, es preciso especificar información relativa a: Descripción del escenario, es decir, cómo un actor interactúa con el sistema, y cuál es la respuesta obtenida. Precondiciones y pos condiciones. Identificación de interfaces de usuario. Condiciones de fallo que afectan al escenario, así como la respuesta del sistema (escenarios secundarios). En escenarios complejos, es posible utilizar como técnica de especificación los diagramas de transición de estados, así como la división en casos de uso más simples, actualizando el modelo de casos de uso. Para la obtención de esta información es imprescindible la participación activa de los usuarios CASOS DE USO sistema: A continuación, en la figura ASI 3, se muestra el diagrama de casos de uso del Ing. María Florencia Pollo Cattaneo Pág. 83

84 Figura ASI 3: Diagrama de Casos de Uso A continuación se detalla la simbología aplicada a las flechas del diagrama: Las flechas de línea de punto sin estereotipo indican que entre ambos casos de uso existe una relación de Inclusión. Las flechas de línea llena que se identifican con el estereotipo extends indican que existe una relación de extensión entre ambos casos de uso (no hay en este caso). Las fechas de línea llena sin estereotipo indican que existen una relación de uso entre los participantes. Ing. María Florencia Pollo Cattaneo Pág. 84

85 A continuación se describen los casos de uso detallados en la figura ASI 3: Caso de Uso Descripción del Caso de Uso Flujo de Eventos Activación Flujo principal 1) El usuario presiona el botón Aplicar DMP 2) El sistema pide al caso de uso Seleccionar Parámetros los parámetros correspondientes a las pruebas a realizar 3) El sistema solicita al caso de uso Seleccionar Tipo de Archivo el tipo de archivo donde guardará los resultados 4) El sistema solicita al caso de uso Seleccionar DN el archivo donde se encuentra almacenada la distribución normal a usar. 5) El sistema pide al usuario el nombre de archivo y lugar de almacenamiento del mismo para guardar los resultados. Aplicar Diferencia de Medias Ponderadas (DMP) Se aplica la técnica de DMP al conjunto de números que simulan los experimentos, calculando el efecto individual y global El Usuario presiona el botón Aplicar DMP Ing. María Florencia Pollo Cattaneo Pág. 85

86 6) El usuario proporciona el nombre de archivo. 7) El sistema realiza el procesamiento y guarda el archivo. 8) Fin del caso de uso. Flujos alternativos Alternativa al paso 6 9) El sistema asigna por defecto el nombre de archivo prueba, y almacena el archivo en Mis Documentos El usuario no proporciona nombre de archivo ni selecciona lugar de almacenamiento Requisitos especiales No posee Precondiciones Debe haber generado una Distribución Normal Pos condiciones No posee Puntos de extensión No posee Tabla ASI 1: Descripción del caso de uso Aplicar Diferencia de Medias Ponderadas (DMP) Caso de Uso Descripción del Caso de Uso Aplicar Response Ratio Paramétrico (RRP) Se aplica la técnica de RRP al conjunto de números que simulan los experimentos, calculando el efecto individual y global Ing. María Florencia Pollo Cattaneo Pág. 86

87 Flujo de Eventos Activación Flujo principal 1) El usuario presiona el botón Aplicar RRP 2) El sistema pide al caso de uso Seleccionar Parámetros los parámetros correspondientes a las pruebas a realizar 3) El sistema solicita al caso de uso Seleccionar Tipo de Archivo el tipo de archivo donde guardará los resultados 4) El sistema solicita al caso de uso Seleccionar DN el archivo donde se encuentra almacenada la distribución normal a usar. 5) El sistema pide al usuario el nombre de archivo y lugar de almacenamiento del mismo para guardar los resultados. 6) El usuario proporciona el nombre de archivo 7) El sistema realiza el procesamiento y guarda el archivo. 8) Fin del caso de uso. Flujos alternativos El Usuario presiona el botón Aplicar RRP Ing. María Florencia Pollo Cattaneo Pág. 87

88 Alternativa al paso 6 9) El sistema asigna por defecto el nombre de archivo prueba, y almacena el archivo en Mis Documentos El usuario no proporciona nombre de archivo ni selecciona lugar de almacenamiento Requisitos especiales No posee Precondiciones Debe haber generado una Distribución Normal Pos condiciones No posee Puntos de extensión No posee Tabla ASI 2: Descripción del caso de uso Aplicar Response Ratio Paramétrico (RRP) Caso de Uso Descripción del Caso de Uso Flujo de Eventos Activación Flujo principal Aplicar Response Ratio No Paramétrico (RRNP) Se aplica la técnica de RRNP al conjunto de números que simulan los experimentos, calculando el efecto individual y global El Usuario presiona el botón Aplicar RRNP Ing. María Florencia Pollo Cattaneo Pág. 88

89 1) El usuario presiona el botón Aplicar RRNP 2) El sistema pide al caso de uso Seleccionar Parámetros los parámetros correspondientes a las pruebas a realizar 3) El sistema solicita al caso de uso Seleccionar Tipo de Archivo el tipo de archivo donde guardará los resultados 4) El sistema solicita al caso de uso Seleccionar DN el archivo donde se encuentra almacenada la distribución normal a usar. 5) El sistema pide al usuario el nombre de archivo y lugar de almacenamiento del mismo para guardar los resultados. 6) El usuario proporciona el nombre de archivo 7) El sistema realiza el procesamiento y guarda el archivo. 8) Fin del caso de uso. Flujos alternativos Alternativa al paso 6 El usuario no proporciona nombre de archivo ni selecciona lugar de almacenamiento Ing. María Florencia Pollo Cattaneo Pág. 89

90 9) El sistema asigna por defecto el nombre de archivo prueba, y almacena el archivo en Mis Documentos Requisitos especiales No posee Precondiciones Debe haber generado una Distribución Normal Pos condiciones No posee Puntos de extensión No posee Tabla ASI 3: Descripción del caso de uso Aplicar Response Ratio No Paramétrico (RRNP) Caso de Uso Descripción del Caso de Uso Flujo de Eventos Activación Flujo principal Aplicar Vote Counting (VC) Se aplica la técnica de VC al conjunto de números que simulan los experimentos, calculando el efecto individual y global El Usuario presiona el botón Aplicar VC Ing. María Florencia Pollo Cattaneo Pág. 90

91 1) El usuario presiona el botón Aplicar VC 2) El sistema pide al caso de uso Seleccionar Parámetros los parámetros correspondientes a las pruebas a realizar 3) El sistema solicita al caso de uso Seleccionar Tipo de Archivo el tipo de archivo donde guardará los resultados 4) El sistema solicita al caso de uso Seleccionar DN el archivo donde se encuentra almacenada la distribución normal a usar. 5) El sistema pide al usuario el nombre de archivo y lugar de almacenamiento del mismo para guardar los resultados. 6) El usuario proporciona el nombre de archivo 7) El sistema realiza el procesamiento y guarda el archivo. 8) Fin del caso de uso. Flujos alternativos Alternativa al paso 6 El usuario no proporciona nombre de archivo ni selecciona lugar de almacenamiento Ing. María Florencia Pollo Cattaneo Pág. 91

92 9) El sistema asigna por defecto el nombre de archivo prueba, y almacena el archivo en Mis Documentos Requisitos especiales No posee Precondiciones Debe haber generado una Distribución Normal Pos condiciones No posee Puntos de extensión No posee Tabla ASI 4: Descripción del caso de uso Aplicar Vote Counting (VC) Caso de Uso Descripción del Caso de Uso Flujo de Eventos Activación Flujo principal Aplicar Varias Técnicas Se aplican varias técnicas al conjunto de números que simulan los experimentos, calculando el efecto individual y global El Usuario presiona el botón Aplicar Varias Técnicas Ing. María Florencia Pollo Cattaneo Pág. 92

93 1) El usuario presiona el botón Aplicar Varias Técnicas 2) El sistema pide al caso de uso Seleccionar Técnica las técnicas a aplicar 3) El sistema pide al caso de uso Seleccionar Parámetros los parámetros correspondientes a las pruebas a realizar 4) El sistema solicita al caso de uso Seleccionar Tipo de Archivo el tipo de archivo donde guardará los resultados 5) El sistema solicita al caso de uso Seleccionar DN el archivo donde se encuentra almacenada la distribución normal a usar. 6) El sistema pide al usuario el nombre de archivo y lugar de almacenamiento del mismo para guardar los resultados. 7) El usuario proporciona el nombre de archivo 8) El sistema realiza el procesamiento y guarda el archivo. 9) Fin del caso de uso. Flujos alternativos Ing. María Florencia Pollo Cattaneo Pág. 93

94 Alternativa al paso 7 10) El sistema asigna por defecto el nombre de archivo prueba, y almacena el archivo en Mis Documentos El usuario no proporciona nombre de archivo ni selecciona lugar de almacenamiento Requisitos especiales No posee Precondiciones Debe haber generado una Distribución Normal Pos condiciones No posee Puntos de extensión No posee Tabla ASI 5: Descripción del caso de uso Aplicar Varias Técnicas Caso de Uso Descripción del caso de uso Flujo de eventos Activación Flujo principal Seleccionar Parámetros El usuario debe seleccionar los parámetros para aplicar la técnica seleccionada El sistema lo activa cuando necesita esta información del usuario al aplicar alguna de las técnicas de agregación Ing. María Florencia Pollo Cattaneo Pág. 94

95 1) El sistema muestra al usuario la pantalla para seleccionar parámetros 2) El usuario selecciona los parámetros correspondientes y presiona el botón Siguiente 3) El sistema incorpora los parámetros seleccionados por el usuario 4) Fin del caso de uso Flujos alternativos Primera alternativa al paso 2 5) El sistema emite un mensaje de error y vuelve al punto 1 El usuario ingresa algún parámetro erróneo Segunda alternativa al paso 2 6) El sistema selecciona por defecto los siguientes parámetros: Media tratamiento experimental = 100 Media tratamiento de control = 102 Desvío estándar tratamiento experimental = 10 El usuario no selecciona ningún parámetro Ing. María Florencia Pollo Cattaneo Pág. 95

96 Desvío estándar tratamiento de control = 10 Cantidad de sujetos de cada experimento desde = 4 Cantidad de sujetos de cada experimento hasta = 10 Cantidad de experimentos desde = 2 Cantidad de experimentos hasta = 10 Cantidad de simulaciones = 10 Tercera alternativa al paso 2 7) El sistema vuelve a la pantalla de inicio El usuario presiona el botón Atrás Cuarta alternativa al paso 2 El usuario presiona el botón Cancelar Ing. María Florencia Pollo Cattaneo Pág. 96

97 8) El sistema vuelve a la pantalla de inicio Requisitos especiales No posee Precondiciones No posee Pos condiciones No posee Puntos de extensión No posee Tabla ASI 6: Descripción del caso de uso Seleccionar Parámetros Caso de Uso Descripción del caso de uso Flujo de eventos Activación Flujo principal Seleccionar Tipo de Archivo El usuario debe seleccionar el tipo de archivo para almacenar los resultados de aplicar la/s técnica/s seleccionada/s El sistema lo activa cuando necesita esta información del usuario al aplicar alguna de las técnicas de agregación Ing. María Florencia Pollo Cattaneo Pág. 97

98 1) El sistema muestra al usuario la pantalla para seleccionar el tipo de archivo 2) El usuario selecciona el tipo de archivo (.txt,.xls o ambos) y presiona el botón Siguiente 3) El sistema incorpora la información proporcionada por el usuario 4) Fin del caso de uso Flujos alternativos Primera alternativa al paso 2 5) El sistema selecciona por defecto el tipo texto (.txt) El usuario no selecciona ningún tipo de archivo Segunda alternativa al paso 2 El usuario presiona el botón Atrás Ing. María Florencia Pollo Cattaneo Pág. 98

99 6) El sistema vuelve a la pantalla de selección de parámetros Tercera alternativa al paso 2 7) El sistema vuelve a la pantalla de inicio El usuario presiona el botón Cancelar Requisitos especiales No posee Precondiciones No posee Pos condiciones No posee Puntos de extensión No posee Tabla ASI 7: Descripción del caso de uso Seleccionar Tipo de Archivo Caso de Uso Descripción del caso de uso Flujo de eventos Seleccionar Distribución Normal El usuario debe seleccionar el archivo que contenga la distribución normal a al que se le aplicará la técnica de agregación Ing. María Florencia Pollo Cattaneo Pág. 99

100 Activación Flujo principal 1) El sistema muestra al usuario la pantalla para seleccionar el archivo 2) El usuario selecciona el archivo (a través de un diálogo con la opción de navegar por las carpetas del sistema) y presiona el botón Siguiente 3) El sistema incorpora la información proporcionada por el usuario 4) Fin del caso de uso Flujos alternativos Primera alternativa al paso 2 5) El sistema indica el error y vuelve a la pantalla de inicio El sistema lo activa cuando necesita esta información del usuario al aplicar alguna de las técnicas de agregación El usuario no selecciona ningún archivo Segunda alternativa al paso 2 Ing. María Florencia Pollo Cattaneo Pág. 100

101 6) El sistema vuelve a la pantalla de selección del tipo de archivo Tercera alternativa al paso 2 7) El sistema vuelve a la pantalla de inicio Requisitos especiales No posee Precondiciones No posee Pos condiciones No posee Puntos de extensión No posee Tabla ASI 8: Descripción del caso de uso Seleccionar Distribución Normal Caso de Uso Descripción del caso de uso Flujo de eventos Seleccionar Técnicas El usuario debe seleccionar varias técnicas para aplicar Ing. María Florencia Pollo Cattaneo Pág. 101

102 Activación Flujo principal 1) El sistema muestra al usuario la pantalla para seleccionar varias técnicas de agregación 2) El usuario selecciona varias técnicas (tildando las opciones) y presiona el botón Siguiente 3) El sistema incorpora la información proporcionada por el usuario 4) Fin del caso de uso Flujos alternativos El sistema lo activa cuando necesita esta información del usuario al aplicar alguna de las técnicas de agregación Primera alternativa al paso 2 5) El sistema selecciona por defecto las cuatro técnicas El usuario no selecciona ninguna técnica Segunda alternativa al paso 2 El usuario presiona el botón Atrás Ing. María Florencia Pollo Cattaneo Pág. 102

103 6) El sistema vuelve a la pantalla de inicio Tercera alternativa al paso 2 7) El sistema vuelve a la pantalla de inicio El usuario presiona el botón Cancelar Requisitos especiales No posee Precondiciones No posee Pos condiciones No posee Puntos de extensión No posee Tabla ASI 9: Descripción del caso de uso Seleccionar Técnicas Caso de Uso Descripción del caso de uso Flujo de eventos Generar Valores Normalmente Distribuidos Se genera un conjunto de números que siguen una distribución de probabilidad normal Ing. María Florencia Pollo Cattaneo Pág. 103

104 Activación Flujo principal 1) El usuario presiona el botón Generar Distribución Normal 2) El sistema solicita al caso de uso Seleccionar Parámetros los parámetros de la generación que va a realizar 3) El sistema solicita al usuario el nombre de archivo 4) El usuario proporciona el nombre de archivo 5) El sistema produce la generación, y vuelve a la pantalla principal 6) Fin del caso de uso El usuario presiona el botón Generar Distribución Normal Flujos alternativos Alternativa al paso 4 El usuario no proporciona ningún nombre Ing. María Florencia Pollo Cattaneo Pág. 104

105 7) El sistema asigna por defecto el nombre dn.txt al archivo y lo guarda en Mis Documentos Requisitos especiales No posee Precondiciones No posee Pos condiciones No posee Puntos de extensión No posee Tabla ASI 10: Descripción del caso de uso Generar Valores Normalmente Distribuidos ANÁLISIS DE LOS CASOS DE USO El objetivo de esta actividad, que sólo se realiza en el caso de Análisis Orientado a Objetos, es identificar las clases cuyos objetos son necesarios para realizar un caso de uso y, describir su comportamiento mediante la interacción dichos objetos. Esta actividad se lleva a cabo para cada uno de los casos de uso contenidos en un subsistema de los definidos en la actividad Identificación de Subsistemas de Análisis. Las tareas, de esta actividad, no se realizan en forma secuencial sino en paralelo, con continuas realimentaciones entre ellas y con las realizadas en las actividades: Establecimiento de Requisitos, Identificación de Subsistemas de Análisis, Análisis de Clases y Definición de Interfaces de Usuario. Ing. María Florencia Pollo Cattaneo Pág. 105

106 IDENTIFICACIÓN DE CLASES ASOCIADAS A UN CASO DE USO En esta tarea se comienzan a identificar los objetos necesarios para realizar el caso de uso, basándose en la especificación que tenemos del mismo. A partir del estudio del caso de uso, se extrae una lista de objetos candidatos a ser clases. Es posible que, inicialmente, no se disponga de la información necesaria para identificar todas, por lo que se hace una primera aproximación que se va refinando posteriormente, durante esta actividad y en el proceso de diseño. Además, algunos de los objetos representan mejor la información del sistema si se les identifica como atributos en vez de como clases. Para poder diferenciarlas, es necesario estudiar el comportamiento de esos objetos en el diagrama de interacción y además se debe tener en cuenta una serie de reglas, como puede ser el suprimir palabras no pertinentes, con significados vagos o sinónimos. Una vez definidas cada una de las clases, se incorporan al modelo de clases de la actividad Análisis de Clases, donde se identifican sus atributos, responsabilidades y relaciones. Las clases que se identifican en esta tarea pueden ser: Clases de Entidad (representan la información manipulada en el caso de uso). Clases de Interfaz de Usuario (se utilizan para describir la interacción entre el sistema y sus actores. Suelen representar abstracciones de ventanas, interfaces de comunicación, formularios, etc.). Clases de Control (son responsables de la coordinación, secuencia de transacciones y control de los objetos relacionados con un caso de uso). Ing. María Florencia Pollo Cattaneo Pág. 106

107 IDENTIFICACIÓN DE CLASES En este apartado no se utiliza la nomenclatura estándar de UML para estereotipar las clases, por problemas en la implementación de éstas en la herramienta de desarrollo, en su lugar se utilizará la nomenclatura detallada en la figura ASI 4. Figura ASI 4: Estereotipos de Clases A continuación se desarrolla el diagrama de clases para cada uno de los casos de uso del sistema, detallados en la figura ASI 3: Ing. María Florencia Pollo Cattaneo Pág. 107

111 DESCRIPCIÓN DE LA INTERACCIÓN DE OBJETOS El objetivo de esta tarea es describir la cooperación entre los objetos utilizados para la realización de un caso de uso, que ya fueron identificados en el punto anterior. Para representar esta información, se usan diagramas de interacción que contienen instancias de los actores participantes, objetos, y la secuencia de mensajes intercambiados entre ellos. Se pueden establecer criterios para determinar qué tipo de objetos y mensajes se van a incluir en este diagrama, como por ejemplo: si se incluyen objetos y llamadas a bases de datos, objetos de interfaz de usuario, de control, etc. Estos diagramas pueden ser tanto de secuencia como de colaboración, y su uso depende de si se quieren centrar en la secuencia cronológica o en cómo es la comunicación entre los objetos. En aquellos casos en los que se especifique más de un escenario para un caso de uso, puede ser conveniente representar cada uno de ellos en un diagrama de interacción. Ing. María Florencia Pollo Cattaneo Pág. 111

112 También es recomendable, sobre todo en el caso anterior, completar los diagramas con una descripción textual IDENTIFICACIÓN DE LA INTERACCIÓN DE OBJETOS A continuación se detallan los diagramas de colaboración de objetos, donde se muestra cómo se vinculan los diferentes objetos identificados en la tarea anterior. La forma de vincular a los objetos se encuentra relacionada con su participación dentro de los casos de uso. Por último, cabe aclarar que se mantendrá la misma simbología de clases (que permite identificar si una clase es del tipo de: Interfaz, Control o Entidad) utilizada en la tarea anterior. Ing. María Florencia Pollo Cattaneo Pág. 112

116 4.4.- ANÁLISIS DE CLASES El objetivo de esta actividad que sólo se realiza en el caso de Análisis Orientado a Objetos es describir cada una de las clases que ha surgido, identificando las responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas. Para esto, se debe tener en cuenta la normativa establecida en la tarea Especificación de Estándares y Normas, de forma que el modelo de clases cumpla estos criterios, con el fin de evitar posibles inconsistencias en el diseño. Teniendo en cuenta las clases identificadas en la actividad Análisis de los Casos de Uso, se elabora el modelo de clases para cada subsistema. A medida que avanza el análisis, dicho modelo se va completando con las clases que vayan apareciendo, tanto del estudio de los casos de uso, como de la interfaz de usuario necesaria para el sistema de información. Ing. María Florencia Pollo Cattaneo Pág. 116

117 IDENTIFICACIÓN DE RESPONSABILIDADES Y ATRIBUTOS El objetivo de esta tarea es identificar las responsabilidades y atributos relevantes de una clase. Las responsabilidades de una clase definen la funcionalidad de esa clase, y están basados en el estudio de los papeles que desempeñan sus objetos dentro de los distintos casos de uso. A partir de estas responsabilidades, se pueden comenzar a encontrar las operaciones que van a pertenecer a la clase. Estas deben ser relevantes, simples, y participar en la descripción de la responsabilidad. Los atributos de una clase especifican propiedades de la clase, y se identifican por estar implicados en sus responsabilidades. Los tipos de estos atributos deberían ser conceptuales y conocidos en el dominio. De manera opcional, se elabora una especificación para cada clase, que incluye: la lista de sus operaciones y las clases que colaboran para cubrir esas operaciones y una descripción de las responsabilidades, atributos y operaciones de esa clase. Para aquellas clases cuyo comportamiento dependa del estado en el que se encuentren se realiza, también de manera opcional, un diagrama de transición de estados DEFINICIÓN DE RESPONSABILIDADES Y ATRIBUTOS A continuación, en la tabla ASI 11, se muestran las distintas clases del sistema junto con sus responsabilidades y atributos: Ing. María Florencia Pollo Cattaneo Pág. 117

118 Clase Responsabilidades Atributos Interfaz Principal Usuario Establece una pantalla para Breve descripción comunicarse con el usuario de uso del sistema para realizar las actividades principales Interfaz Seleccionar Permite al usuario Código que Parámetros establecer los parámetros para la operatoria identifica al conjunto de parámetros Conjunto de parámetros a generar por defecto Interfaz Seleccionar Tipo Permite al usuario Tipo de archivo a de Archivo establecer el tipo de generar archivo donde se Tipo de archivo a almacenarán los resultados generar por defecto Interfaz Seleccionar DN Permite al usuario Código seleccionar la distribución normal con la que se Distribución Normal a generar trabajará Nombre archivo a generar Nombre de archivo a generar por defecto Dirección de almacenamiento del archivo a generar Dirección de almacenamiento del archivo a generar por defecto Ing. María Florencia Pollo Cattaneo Pág. 118

119 Interfaz Seleccionar Establece la interfaz con el Técnica a Técnicas usuario para que éste seleccionar seleccione las técnicas de agregación Conjunto de técnicas a aplicar por defecto Asistente Aplicar DMP Coordina la operación para aplicar la técnica DMP Código que identifica el resultado de aplicar DMP. Código que identifica el conjunto de parámetros Código que identifica la Distribución Normal a aplicar Tipo de archivo a generar Nombre del archivo resultado Nombre del archivo resultado por defecto Dirección de guardado del archivo resultado Dirección de guardado del archivo resultado por defecto Ing. María Florencia Pollo Cattaneo Pág. 119

120 Asistente Aplicar RRP Asistente Aplicar RRNP Coordina la operación para aplicar la técnica RRP Coordina la operación para aplicar la técnica RRNP Código que identifica el resultado de aplicar RRP. Código que identifica el conjunto de parámetros Código que identifica la Distribución Normal a aplicar Tipo de archivo a generar Nombre del archivo resultado Nombre del archivo resultado por defecto Dirección de guardado del archivo resultado Dirección de guardado del archivo resultado por defecto Código que identifica el resultado de aplicar RRNP. Código que identifica el conjunto de parámetros Código que identifica la Distribución Normal a aplicar Ing. María Florencia Pollo Cattaneo Pág. 120

121 Asistente Aplicar VC Coordina la operación para aplicar la técnica VC Tipo de archivo a generar Nombre del archivo resultado Nombre del archivo resultado por defecto Dirección de guardado del archivo resultado Dirección de guardado del archivo resultado por defecto Código que identifica el resultado de aplicar VC. Código que identifica el conjunto de parámetros Código que identifica la Distribución Normal a aplicar Tipo de archivo a generar Nombre del archivo resultado Nombre del archivo resultado por defecto Dirección de guardado del archivo resultado Ing. María Florencia Pollo Cattaneo Pág. 121

122 Dirección de guardado del archivo resultado por defecto Asistente Aplicar Varias Técnicas Coordina la operación para aplicar varias técnicas de agregación al mismo conjunto de datos Código que identifica el resultado de aplicar las distintas técnicas. Información de las técnicas aplicadas Código que identifica el conjunto de parámetros Código que identifica la Distribución Normal a aplicar Tipo de archivo a generar Nombre del archivo resultado Nombre del archivo resultado por defecto Dirección de guardado del archivo resultado Dirección de guardado del archivo resultado por defecto Ing. María Florencia Pollo Cattaneo Pág. 122

123 Asistente Generar Valores Normalmente Distribuidos (DN) Parámetros Coordina la generación de un archivo con un conjunto de números aleatorios de distribución de probabilidad Gaussiana Representa los parámetros con los que se va a generar la DN y aplicar la/s técnica/s Código que identifica la Distribución Normal a generar Código que identifica al conjunto de parámetros Nombre del archivo resultado Nombre del archivo resultado por defecto Dirección de guardado del archivo resultado Dirección de guardado del archivo resultado por defecto Identificador del conjunto de parámetros Media tratamiento experimental Media del tratamiento de control Desvío estándar del tratamiento de control Desvío estándar del tratamiento experimental Cantidad menor de sujetos de cada experimento Ing. María Florencia Pollo Cattaneo Pág. 123

124 Información Archivos Representa toda la información relacionada con los archivos donde se almacenará la información de la DN y resultados de las agregaciones Cantidad mayor de sujetos de cada experimento Cantidad mínima de experimentos Cantidad máxima de experimentos Cantidad de simulaciones Código de identificación del conjunto de información de un archivo Nombre del archivo Dirección del archivo Tipo de archivo Distribución Normal Representa la información de la distribución normal Identificador de la Distribución Normal Identificador del conjunto de parámetros asociados Conjunto de valores generados aleatoriamente Resultado Agregación Representa la información que se obtiene al aplicar la/s técnica/s de agregación seleccioanada/s Identificador del resultado obtenido Información de las técnicas aplicadas Ing. María Florencia Pollo Cattaneo Pág. 124

125 Identificador de la distribución normal asociada Identificador del conjunto de parámetros asociados Nombre de archivo Valor de DMP con intervalo de confianza del 90 % (límite inferior efecto individual) Valor de DMP con intervalo de confianza del 90 % (límite superior efecto individual) Valor de DMP con intervalo de confianza del 95 % (límite inferior efecto individual) Valor de DMP con intervalo de confianza del 95 % (límite superior efecto individual) Valor de DMP con intervalo de confianza del 99 % (límite inferior efecto individual) Ing. María Florencia Pollo Cattaneo Pág. 125

126 Valor de DMP con intervalo de confianza del 99 % (límite superior efecto individual) Valor de RRP con intervalo de confianza del 90 % (límite inferior efecto individual) Valor de RRP con intervalo de confianza del 90 % (límite superior efecto individual) Valor de RRP con intervalo de confianza del 95 % (límite inferior efecto individual) Valor de RRP con intervalo de confianza del 95 % (límite superior efecto individual) Valor de RRP con intervalo de confianza del 99 % (límite inferior efecto individual) Valor de RRP con intervalo de confianza del 99 % (límite superior efecto individual) Ing. María Florencia Pollo Cattaneo Pág. 126

127 Valor de RRNP con intervalo de confianza del 90 % (límite inferior efecto individual) Valor de RRNP con intervalo de confianza del 90 % (límite superior efecto individual) Valor de RRNP con intervalo de confianza del 95 % (límite inferior efecto individual) Valor de RRNP con intervalo de confianza del 95 % (límite superior efecto individual) Valor de RRNP con intervalo de confianza del 99 % (límite inferior efecto individual) Valor de RRNP con intervalo de confianza del 99 % (límite superior efecto individual) Valor de DMP con intervalo de confianza del 90 % (límite inferior efecto global) Ing. María Florencia Pollo Cattaneo Pág. 127

128 Valor de DMP con intervalo de confianza del 90 % (límite superior efecto global) Valor de DMP con intervalo de confianza del 95 % (límite inferior efecto global) Valor de DMP con intervalo de confianza del 95 % (límite superior efecto global) Valor de DMP con intervalo de confianza del 99 % (límite inferior efecto global l) Valor de DMP con intervalo de confianza del 99 % (límite superior efecto global) Valor de RRP con intervalo de confianza del 90 % (límite inferior efecto global) Valor de RRP con intervalo de confianza del 90 % (límite superior efecto global) Ing. María Florencia Pollo Cattaneo Pág. 128

129 Valor de RRP con intervalo de confianza del 95 % (límite inferior efecto global) Valor de RRP con intervalo de confianza del 95 % (límite superior efecto global) Valor de RRP con intervalo de confianza del 99 % (límite inferior efecto global l) Valor de RRP con intervalo de confianza del 99 % (límite superior efecto global) Valor de RRNP con intervalo de confianza del 90 % (límite inferior efecto global) Valor de RRNP con intervalo de confianza del 90 % (límite superior efecto global l) Valor de RRNP con intervalo de confianza del 95 % (límite inferior efecto global) Ing. María Florencia Pollo Cattaneo Pág. 129

130 Valor de RRNP con intervalo de confianza del 95 % (límite superior efecto global) Valor de RRNP con intervalo de confianza del 99 % (límite inferior efecto global) Valor de RRNP con intervalo de confianza del 99 % (límite superior efecto global) Valor de VC con intervalo de confianza del 90 % (límite inferior efecto global) Valor de VC con intervalo de confianza del 90 % (límite superior efecto global) Valor de VC con intervalo de confianza del 95 % (límite inferior efecto global) Valor de VC con intervalo de confianza del 95 % (límite superior efecto global) Ing. María Florencia Pollo Cattaneo Pág. 130

131 Valor de VC con intervalo de confianza del 99 % (límite inferior efecto global) Valor de VC con intervalo de confianza del 99 % (límite superior efecto global) Tabla ASI 11: Descripción de clases IDENTIFICACIÓN DE ASOCIACIONES Y AGREGACIONES En esta tarea se estudian los mensajes establecidos entre los objetos del diagrama de interacción para determinar qué asociaciones existen entre las clases correspondientes. Estas asociaciones suelen corresponderse con expresiones verbales incluidas en las especificaciones. Las relaciones surgen como respuesta a las demandas en los distintos casos de uso, y para ello puede existir la necesidad de definir agregaciones y herencia entre objetos. Una asociación esta caracterizada por: Los papeles que desempeña. Su direccionalidad, que representa el sentido en el que se debe interpretar. Su cardinalidad, que representa el número de instancias implicadas en la asociación. de uso. Dichas características pueden obtenerse a partir de la especificación de los casos Ing. María Florencia Pollo Cattaneo Pág. 131

132 A medida que se establecen las relaciones entre las clases, se revisa la especificación de subsistemas de análisis en la actividad Identificación de Subsistemas de Análisis, para conseguir optimizar los subsistemas DIAGRAMA DE CLASES DONDE SE IDENTIFICAN ASOCIACIONES Y AGREGACIONES Para entrar en detalle sobre este punto, en lo que se refiere al presente proyecto de tesis, podemos recordar que las clases de objetos se dividen en tres grandes categorías: interfaz, entidad y control. Por lo general los lenguajes de programación orientados a objetos vienen acompañados de librerías de clases, éstas contienen implementaciones orientadas a objetos de las características más importantes de las interfaces de usuarios. Es por esta razón, que cualquier desarrollo de interfaz estará fuertemente ligado a las clases provistas por el lenguaje en cuestión. Durante el análisis se ha optado por indagar en cuestiones relacionadas con las clases de control y entidad y postergar las definiciones relacionadas con la interfaz de usuario para un momento posterior en cuanto se trate el diseño detallado. Se entiende por asociación de objetos a la identificación de necesidad de cooperación entre los mismos para poder llevar a cabo una responsabilidad. Esto puede ser visto como las fechas que unen las clases en los diagramas de colaboración antes descriptos. En este caso es necesario estudiar cuidadosamente dichas conexiones dado que posteriormente indicarán referencias y agregaciones entre objetos. A continuación, en la figura ASI 24, se trata el tema de agregaciones y asociaciones para las clases de entidad. Ing. María Florencia Pollo Cattaneo Pág. 132

133 Las clases de control, por su parte, son responsables de administrar los flujos de trabajo necesarios para implementar un caso de uso. Por lo general, utilizan a las clases de entidad como materia prima y resultado de su operación. Por esta razón las relaciones de estas clases se analizan en forma individual. Ing. María Florencia Pollo Cattaneo Pág. 133

134 Asistente Aplicar DMP: Asistente Aplicar RRP: Figura ASI 26: Diagrama de Clases para la clase de control Asistente Aplicar RRP Ing. María Florencia Pollo Cattaneo Pág. 134

135 Asistente Aplicar RRNP: Figura ASI 27: Diagrama de Clases para la clase de control Asistente Aplicar RRNP Asistente Aplicar VC: Figura ASI 28: Diagrama de Clases para la clase de control Asistente Aplicar VC Ing. María Florencia Pollo Cattaneo Pág. 135

136 Asistente Aplicar Varias Técnicas: Figura ASI 29: Diagrama de Clases para la clase de control Asistente Aplicar Varias Asistente Generar DN: Técnicas Figura ASI 30: Diagrama de Clases para la clase de control Asistente Generar DN Ing. María Florencia Pollo Cattaneo Pág. 136

137 IDENTIFICACIÓN DE GENERALIZACIONES El objetivo de esta tarea es representar una organización de las clases que permita una implementación sencilla de la herencia y una agrupación semántica de las diferentes clases, basándose siempre en las normas y estándares definidos en la actividad Definición del Sistema DESCRIPCIÓN DE LAS GENERALIZACIONES IDENTIFICADAS La identificación de generalizaciones es utilizada durante el análisis para extraer comportamiento compartido y común entre diferentes clases de análisis. Las generalizaciones obtenidas en esta parte del proceso de desarrollo deben ser de nivel alto y conceptual dado que su objetivo debe ser mantener el modelo de análisis simple y de fácil comprensión. En nuestro caso, para la presente versión, no se observan generalizaciones entre las clases DEFINICIÓN DE INTERFACES DE USUARIO En esta actividad se especifican las interfaces entre el sistema y el usuario: formatos de pantallas, diálogos, e informes, principalmente. El objetivo es realizar un análisis de los procesos del sistema de información en los que se requiere una interacción del usuario, con el fin de crear una interfaz que satisfaga todos los requisitos establecidos, teniendo en cuenta los diferentes perfiles a quienes va dirigido. Al comienzo de este análisis es necesario seleccionar el entorno en el que es operativa la interfaz, considerando estándares internacionales y de instalación, y establecer las directrices aplicables en los procesos de diseño y construcción. El propósito es construir una interfaz de usuario acorde a sus necesidades, flexible, coherente, eficiente y fácil de utilizar, teniendo en cuenta la adaptación a cambio a otras plataformas, si fuera necesario. Ing. María Florencia Pollo Cattaneo Pág. 137

138 Se identifican los distintos grupos de usuarios de acuerdo con las funciones que realizan, conocimientos y habilidades que poseen, y características del entorno en el que trabajan. La identificación de los diferentes perfiles permite conocer mejor las necesidades y particularidades de cada uno de ellos. Asimismo, se determina la naturaleza de los procesos que se llevan a cabo (en lotes o en línea). Para cada proceso en línea se especifica qué tipo de información requiere el usuario para completar su ejecución realizando, para ello, una descomposición en diálogos que refleje la secuencia de la interfaz de pantalla tipo carácter o pantalla gráfica. Finalmente, se define el formato y contenido de cada una de las interfaces de pantalla especificando su comportamiento dinámico. Se propone un flujo de trabajo muy similar para desarrollos estructurados y orientados a objetos, coincidiendo en la mayoría de las tareas, si bien es cierto que en orientación a objetos, al identificar y describir cada escenario en la especificación de los casos de uso, se hace un avance muy significativo en la toma de datos para la posterior definición de la interfaz de usuario. Como resultado de esta actividad se genera la especificación de interfaz de usuario, como producto que engloba los siguientes elementos: Principios generales de la interfaz. Catálogo de perfiles de usuario. Descomposición funcional en diálogos. Catálogo de controles y elementos de diseño de interfaz de pantalla. Formatos individuales de interfaz de pantalla. Ing. María Florencia Pollo Cattaneo Pág. 138

139 Modelo de navegación de interfaz de pantalla. Formatos de impresión. Prototipo de interfaz interactiva. Prototipo de interfaz de impresión ESPECIFICACIÓN DE PRINCIPIOS GENERALES DE LA INTERFAZ El objetivo de esta tarea es especificar los estándares, directrices y elementos generales a tener en cuenta en la definición de la interfaz de usuario, tanto para la interfaz interactiva (gráfica o caracter), como para los informes y formularios impresos. En primer lugar, se selecciona el entorno de la interfaz interactiva (gráfico, carácter, etc.), siguiendo estándares internacionales y de instalación. Luego se determinan los principios de diseño de la interfaz de usuario, contemplando: Directrices generales en cuanto a la interfaz y aspectos generales de interacción. Principios de composición de pantallas y criterios de ubicación de los distintos elementos dentro de cada formato. Normas para los mensajes de error y aviso, codificación, presentación y comportamientos. Normas para la presentación de ayudas. Se deben establecer criterios similares para la interfaz impresa: Ing. María Florencia Pollo Cattaneo Pág. 139

140 Directrices generales. Principios de composición de informes y formularios. Normas de elaboración, distribución y salvaguarda de la información PRINCIPIOS GENERALES DE LA INTERFAZ La interfaz de usuario será gráfica e interactiva, de tipo estándar utilizado en todos los aplicativos basados en ventanas. los siguientes: Los lineamientos principales para la construcción de la interfaz de usuarios son La activación de las distintas funcionalidades del sistema se activan a través de una serie de botones dispuestos en la pantalla principal. Las pantallas de selección de parámetros, tipo de archivo y otros tópicos tendrán un botón para confirmar los datos seleccionados y/o ingresados, o cancelar toda la operación o volver a la operación anterior. Los mensajes de error se mostrarán mediante pantallas emergentes. El nombre de archivo que se seleccione se hará, al igual que el lugar de almacenamiento en disco, a través de una ventana de diálogo. La primera pantalla tendrá una muy breve explicación de utilización del sistema. Ing. María Florencia Pollo Cattaneo Pág. 140

141 ESPECIFICACIÓN DE FORMATOS INDIVIDUALES DE LA INTERFAZ DE PANTALLA El objetivo de esta tarea es especificar cada formato individual de la interfaz de pantalla, desde el punto de vista estático. Para cada proceso en línea identificado en la tarea anterior o en la especificación de los casos de uso, y teniendo en cuenta los formatos estándar definidos en la tarea Especificación de Principios Generales de la Interfaz, se definen los formatos individuales de la interfaz de pantalla requerida para completar la especificación de cada diálogo. En el caso de un análisis orientado a objetos, estos formatos individuales van completando las especificaciones de los casos de uso. En un análisis estructurado se tiene en cuenta, para la realización de esta tarea, el modelo de datos y el modelo de procesos generados en paralelo en las actividades Elaboración del Modelo de Datos y Elaboración del Modelo de Procesos. También se considera el catálogo de requisitos, para especificar las interfaces relacionadas con las consultas. En la definición de cada interfaz de pantalla se deben definir aquellos aspectos considerados de interés para su posterior diseño y construcción: Posibilidad de cambio de tamaño, ubicación, modalidad (modal del sistema, modal de aplicación), etc. Dispositivos de entrada necesarios para su ejecución. Conjunto y formato de datos asociados, identificando qué datos se usan y cuáles se generan como consecuencia de su ejecución. Ing. María Florencia Pollo Cattaneo Pág. 141

142 Controles y elementos de diseño asociados, indicando cuáles aparecen inicialmente activos e inactivos al visualizar la interfaz de pantalla MODELO DE NAVEGACIÓN DE INTERFAZ En este modelo se completan las interfaces de usuario que existen en el sistema y la forma en que las mismas pueden navegarse. se vinculan. A continuación se muestra las distintas interfaces del sistema y la forma en que Ing. María Florencia Pollo Cattaneo Pág. 142

143 DESCRIPCIÓN DE LAS CARACTERÍSTICAS GENERALES DE CADA PANTALLAS Pantalla Principal (Técnicas de Agregación): Desde aquí el usuario puede comenzar la ejecución de las principales funcionalidades del sistema, pudiendo lanzar la aplicación de cada una de las técnicas de agregación en forma individual, o varias al mismo tiempo. También puede realizar la generación de la distribución normal. Seleccionar Técnicas de Agregación: desea aplicar. En esta pantalla el usuario puede seleccionar la/s técnica/s de agregación que Seleccionar Parámetros: Aquí el usuario puede seleccionar todos los parámetros necesarios para generar la distribución normal o aplicar la/s técnica/s de agregación. Seleccionar Tipo de Archivo: El usuario selecciona en esta pantalla, el tipo de archivo en que quiere almacenar los resultados de la agregación. Tiene tres opciones: texto (.txt), excel (.xls) o ambas. Seleccionar DN: El usuario puede navegar por las carpetas del sistema en búsqueda de la distribución normal a la que desee aplicar las técnicas de agregación. Ing. María Florencia Pollo Cattaneo Pág. 143

144 Seleccionar Nombre: Es una ventana de diálogo donde seleccionar el nombre de archivo a guardar y el lugar de almacenamiento (pueden usarse las ventanas de diálogo que proporcionan los lenguajes de programación modernos). Por ser una ventana emergente, no la consideraremos en el modelo de análisis de interfaz, ya que en la etapa de diseño no deberemos preocuparnos por ella DEFINICIÓN DE LAS PANTALLAS DEL SISTEMA A continuación se detallan los prototipos de las pantallas del sistema: Pantalla Principal: Esta pantalla es la primera que se observa al ingresar al sistema, y se ilustra en la figura ASI 32. Tiene seis acciones y un botón de ayuda. La ayuda, en esta versión, es una breve explicación de cómo usar el sistema. Los botones restantes son para iniciar el procesamiento de la aplicación de las distintas técnicas de agregación (Diferencia de Medias Ponderadas, Response Ratio Paramétrico, Response Ratio No Paramétrico, Vote Counting) y otra posibilidad para seleccionar varias de estas técnicas a la vez. Finalmente se tiene otro botón para iniciar la generación de una distribución normal que pueda usarse en la aplicación de estas técnicas. Ing. María Florencia Pollo Cattaneo Pág. 144

145 Figura ASI 32: Pantalla principal. Pantalla de selección de parámetros: A esta pantalla se llega inmediatamente después de iniciar la ejecución de la aplicación de alguna de las cuatro técnicas de agregación estadística, y se puede ver en la figura ASI 33. En ella se ubican las casillas para ingresar los valores de los parámetros de los experimentos. A la izquierda de cada casilla hay una leyenda con el nombre del parámetro correspondiente, y estos son: media del tratamiento experimental, media del tratamiento de control, desvío estándar del tratamiento experimental, desvío estándar del tratamiento de control, cantidad mínima de sujetos por experimentos, cantidad máxima de sujetos por experimento, cantidad mínima de experimentos, cantidad máxima de experimentos y cantidad de simulaciones. Además, esta pantalla cuenta con tres botones: Cancela (finaliza toda la operación, volviendo a la pantalla principal), Atrás (vuelve a la pantalla anterior, en este caso la pantalla principal) y Siguiente (que pasa a la siguiente pantalla almacenando los valores de los parámetros, la Ing. María Florencia Pollo Cattaneo Pág. 145

146 cual puede ser la pantalla de selección de tipo de archivo si se está aplicando una técnica de agregación, o la pantalla de selección de nombre si se está generando una distribución normal).. Figura ASI 33: Pantalla de selección de parámetros Pantalla de selección del tipo de archivo: Se puede observar en la figura ASI 34, la posibilidad de seleccionar dos opciones, las cuales no son mutuamente excluyentes (pueden elegirse ambas simultáneamente). Son para seleccionar el tipo de archivo donde se almacenará el archivo que se está generando, que puede ser el archivo con los resultados de la agregación, o un archivo con la distribución normal, y pueden ser archivos de texto (extensión.txt) o plantilla de cálculo Microsoft Excel (extensión.xls). Para esta versión, los archivos de distribución normal sólo podrán ser de tipo texto. También tiene los tres botones de cancelar, atrás y siguiente. Ing. María Florencia Pollo Cattaneo Pág. 146

147 Figura ASI 34: Pantalla de selección de tipo de archivo Pantalla de selección de la distribución normal: Se ilustra en la figura ASI 35, y además de los tres botones de navegación (cancelar, atrás y siguiente), tiene la posibilidad de seleccionar un archivo (contiene la distribución normal) de dos formas diferentes: tipeando la dirección absoluta en la casilla correspondiente, o abriendo otra pantalla (ventana de diálogo) para navegar las carpetas del sistema con el botón Examinar. Ing. María Florencia Pollo Cattaneo Pág. 147

148 Figura ASI 35: Pantalla para seleccionar el archivo con ola distribución normal Pantalla de selección de técnicas de agregación: Se puede apreciar su formato en la figura ASI 36, y es muy similar a la pantalla de selección de tipo de archivo: tiene cuatro opciones que se relacionan con las cuatro técnicas de agregación que resuelve el sistema, y los tres botones de navegación. Ing. María Florencia Pollo Cattaneo Pág. 148

149 Figura ASI 36: Pantalla para seleccionar varias técnicas de agregación Pantalla de selección de nombre de archivo: Esta pantalla, que puede verse en la figura ASI 37, es una ventana de diálogo para que el usuario seleccione el nombre de archivo y lugar de almacenamiento del archivo que va a generar en esta operación, que puede ser la generación de una distribución normal, o la aplicación de una o varias técnicas de agregación. Ing. María Florencia Pollo Cattaneo Pág. 149

150 Figura ASI 37: Pantalla para ponerle nombre a los archivos y seleccionar su lugar de almacenamiento (ventana emergente) ESPECIFICACIÓN DE FORMATOS DE IMPRESIÓN El objetivo de esta tarea es especificar los formatos y características de las salidas o entradas impresas del sistema. De acuerdo a los estándares establecidos en la tarea Especificación de Principios Generales de la Interfaz, se definen los formatos individuales de informes y formularios, sus características principales, entre las que se especifican la periodicidad, confidencialidad, procedimientos de entrega o difusión, y salvaguarda de copia. Ing. María Florencia Pollo Cattaneo Pág. 150

151 FORMATOS DE IMPRESIÓN Esta primera versión no realizará impresiones, por lo que este aspecto quedará pendiente para futuros desarrollos ANÁLISIS DE CONSISTENCIA Y ESPECIFICACIÓN DE REQUISITOS El objetivo de esta actividad es garantizar la calidad de los distintos modelos generados en el proceso de Análisis del Sistema de Información, y asegurar que los usuarios y los Analistas tienen el mismo concepto del sistema. Para cumplir dicho objetivo, se llevan a cabo las siguientes acciones: Verificación de la calidad técnica de cada modelo. Aseguramiento de la coherencia entre los distintos modelos. Validación del cumplimiento de los requisitos. Esta actividad requiere una herramienta de apoyo para realizar el análisis de consistencia. También se elabora en esta actividad la Especificación de Requisitos Software (ERS), como producto para la aprobación formal, por parte del usuario, de las especificaciones del sistema. La Especificación de Requisitos Software se convierte en la línea base para los procesos posteriores del desarrollo del software, de modo que cualquier petición de cambio en los requisitos que pueda surgir posteriormente, debe ser evaluada y aprobada. Ing. María Florencia Pollo Cattaneo Pág. 151

152 VERIFICACIÓN DE LOS MODELOS El objetivo de esta tarea es asegurar la calidad formal de los distintos modelos, conforme a la técnica seguida para la elaboración de cada producto y a las normas determinadas en el Catálogo de Normas VERIFICACIÓN DE MODELOS Se verificó la calidad de los distintos modelos de forma separada con el propósito de garantizar su adecuación al problema a resolver y su seguimiento respecto de las técnicas de análisis seleccionadas. Como resultado de la verificación, se efectuaron correcciones que fueron posteriormente comprobadas ANÁLISIS DE CONSISTENCIA ENTRE MÉTODOS El objetivo de esta tarea es asegurar que los modelos son coherentes entre sí, comprobando la falta de ambigüedades o duplicación de información. Las diferentes comprobaciones varían en función del tipo de desarrollo, aunque, en general, son matrices entre los elementos comunes de los distintos modelos. Estas comprobaciones forman parte del producto Resultado de Análisis de Consistencia. Los análisis de consistencia propuestos en Desarrollo Estructurado son: Modelo Lógico de Datos Normalizado / Modelo de Procesos: Se verifica que: Ing. María Florencia Pollo Cattaneo Pág. 152

153 Cada uno de los almacenes definidos en el modelo de procesos se corresponde con una parte del modelo lógico de datos normalizado. Es decir, un almacén se puede corresponder con una entidad, atributos de una entidad o con varias entidades relacionadas. Los atributos del modelo lógico de datos normalizado y del modelo de procesos se ajustan a una misma especificación. El modelo lógico de datos normalizado satisface las principales consultas de información. Para comprobar que el modelo lógico de datos normalizado puede soportar dichas consultas, se proponen, como técnicas opcionales, la determinación de caminos de acceso lógico en consultas y el cálculo de accesos lógicos. Todas y cada una de las entidades del modelo lógico normalizado son accedidas por algún proceso primitivo. Para dicha comprobación, se propone una matriz de entidades/procesos, donde se especifique que tipo de acceso se realiza (alta, baja, modificación o consulta). Modelo Lógico de Datos Normalizado / Interfaz de Usuario: En este análisis se comprueba que los atributos relevantes que aparecen en cada diálogo de la interfaz de usuario forman parte del modelo lógico de datos normalizado o, en su caso, atributos derivados de los mismos. Modelo de Procesos / Interfaz de Usuario: Se comprueba que todo proceso en línea tiene asociado al menos un diálogo. Ing. María Florencia Pollo Cattaneo Pág. 153

154 El resultado del análisis de consistencia en un análisis estructurado es un producto que engloba los siguientes elementos: Matriz de almacenes de datos / entidades del modelo lógico de datos normalizado. Matriz de atributos de interfaz / atributos de entidades del modelo lógico de datos normalizado. Caminos de acceso lógico en consultas. Cálculo de accesos lógicos. Matriz de entidades / procesos. Matriz de diálogos / procesos. Los análisis de consistencia propuestos en Desarrollo Orientado a Objetos son los siguientes: Considerando que la interfaz de usuario incluye diagramas dinámicos y forma parte del modelo de clases, los análisis de consistencia con la interfaz pueden solaparse con los del resto de los modelos. Los análisis de consistencia propuestos son: Modelo de Clases / Diagramas Dinámicos: Se comprueba que: Cada mensaje entre objetos se corresponde con una operación de una clase y que todos los mensajes se envían a las clases correctas. Ing. María Florencia Pollo Cattaneo Pág. 154

155 La clase que recibe un mensaje con petición de datos tiene capacidad para proporcionar esos datos. Cada objeto del diagrama de interacción de objetos tiene una correspondencia en el modelo de clases. En el caso de haber elaborado diagramas de transición de estados para clases significativas: Se verifica que, para cada uno de ellos, todo evento se corresponde con una operación de la clase. También se tiene que establecer si las acciones y actividades de los diagramas de transición de estado se corresponden con operaciones de la clase. Modelo de clases / Interfaz de usuario Cada clase que requiera una clase de interfaz de usuario, debe tener asociación con ella en el modelo de clases. Todas las clases, atributos y operaciones identificados en la interfaz de usuario, deben tener su correspondencia con algún atributo, operación o clase en el modelo de clases. Análisis de la Realización de los Casos de Uso / Interfaz de Usuario Cada elemento que active la navegación entre pantallas, debe estar asociado con un mensaje del diagrama de interacción de objetos. Además, se revisa que los subsistemas satisfagan la realización de todos los casos de uso, e incluyan las clases identificadas hasta el momento. Ing. María Florencia Pollo Cattaneo Pág. 155

156 El resultado del análisis de consistencia en un análisis orientado a objetos es un producto que engloba los siguientes elementos: Matriz de mensajes del diagrama de interacción de objetos / operaciones del modelo de clases. Matriz de mensajes del diagrama de interacción de objetos / operaciones y atributos del modelo de clases. Matriz de objetos del diagrama de interacción de objetos / clases, atributos del modelo de clases. Matriz (evento, acción, actividad de clase) / operaciones de clase. Correspondencia elementos de negocio de interfaz de usuario / modelo de clases. Correspondencia entre elementos de navegación de interfaz de usuario / mensajes del diagrama de interacción de objetos ANÁLISIS DE CONSISTENCIA Se comprueba la coherencia entre los distintos modelos de acuerdo a las trazabilidades que se presentan en la figura ASI 32. Ing. María Florencia Pollo Cattaneo Pág. 156

157 Modelo de Negocio Catalogo de Requisitos Modelo de Navegación de Interfaz Modelo de Casos de Uso Prototipo de Interfaz Diagrama de Clases Figura ASI 39: Trazabilidades entre los distintos modelos trazabilidad. La comprobación se lleva a cabo mediante un conjunto de matrices de Catálogo de Requisitos vs Modelo de Negocio: La Matriz de la tabla ASI 12 muestra en las filas los requisitos del catálogo de requisitos y en las columnas las actividades del modelo de negocio. Como puede verse cada una de las actividades tiene su correspondencia con algún requisito. Ing. María Florencia Pollo Cattaneo Pág. 157

158 RF 1 Generar Valores Normalmente Distribuidos Generar Valores Normalmente X Aplicar Técnicas de Agregación RF 2 Aplicar DMP RF 3 Aplicar RRP RF 4 Aplicar RRNP RF 5 Aplicar VC RF 6 Aplicar Varias Técnicas X X X X X Tabla ASI 12: Trazabilidades entre el Catálogo de Requisitos y Modelo de Negocio Modelo de Casos de Uso vs Catálogo de Requisitos: La Matriz de la tabla ASI 13 muestra en las filas los requisitos del catálogo de requisitos y en las columnas los casos de uso del Modelo de Casos de Uso. Como se puede observar, cada requisito tiene correspondencia con algún caso de uso y viceversa. Ing. María Florencia Pollo Cattaneo Pág. 158

159 Aplicar Varias Técnicas Aplicar DMP Aplicar RRP Aplicar RRNP Aplicar VC Generar Valores Normalmente Distribuidos Selec. Técnica Agrega. Selec. Parémetros Selec. Tipo Archivo Selec. DN RF 1 Generar Valores Normalmente Distribuidos X X RF 2 Aplicar DMP X X X RF 3 Aplicar RRP X X X RF 4 Aplicar RRNP X X X RF 5 Aplicar VC X X X RF 6 Aplicar Varias Técnicas X X X X Tabla ASI 13: Trazabilidades entre el Modelo de Casos de Uso y el Catálogo de Requisitos Modelo de Casos de Uso vs Prototipo de Interfaz: La Matriz de la tabla ASI 14 muestra en las filas las pantallas del modelo del Prototipo de Interfaz y en las columnas los casos de uso del Modelo de Casos de Uso. Como se puede observar cada pantalla tiene correspondencia con algún caso de uso y viceversa. Ing. María Florencia Pollo Cattaneo Pág. 159

160 Aplicar Varias Técnicas Aplicar DMP Aplicar RRP Aplicar RRNP Aplicar VC Generar Valores Normalmente Distribuidos Selec. Técnica Agrega. Selec. Parémetros Selec. Tipo Archivo Selec. DN Pantalla Principal X X X X X Seleccionar Técnica Agregación X Seleccionar Parámetros X Seleccionar Tipo de Archivo X Seleccionar DN X Tabla ASI 14: Trazabilidades entre el Modelo de Casos de Uso y el Prototipo de Interfaz Modelo de Modelo de Navegación de Interfaz vs Prototipo de Interfaz: La Matriz de la tabla ASI 15 muestra en las filas las pantallas del modelo del Prototipo de Interfaz y en las columnas las pantallas del Modelo de Navegación. Como se puede observar cada pantalla de la intefaz de usuario tiene correspondencia con alguna de las pantallas del modelo de navegación. Ing. María Florencia Pollo Cattaneo Pág. 160

161 Pantalla Principal Seleccionar Técnica de Agregación Seleccionar Parámetros Seleccionar Tipo de Archivo Seleccionar DN Pantalla Principal X Seleccionar Técnica Agregación X Seleccionar Parámetros X Seleccionar Tipo de Archivo X Seleccionar DN X Tabla ASI 15: Trazabilidades entre el Modelo de Navegación de Interfaz y el Prototipo de Interfaz Modelo de Casos de Uso vs Clases: La Matriz de la tabla ASI 16 muestra en las filas las Clases y en las columnas los casos de uso del Modelo de Casos de Uso. Como se puede observar, cada clase tiene correspondencia con algún caso de uso y viceversa. Ing. María Florencia Pollo Cattaneo Pág. 161

162 Aplicar Varias Técnicas Aplicar DMP Aplicar RRP Aplicar RRNP Aplicar VC Generar Valores Normalmente Distribuidos Selec. Técnica Agrega. Selec. Parémetros Selec. Tipo Archivo Selec. DN Interfaz Principal Usuario X X X X X X Interfaz Seleccionar Parámetros X Interfaz Seleccionar Tipo de Archivo X Interfaz Seleccionar DN X Interfaz Seleccionar Técnicas X Asistente Aplicar DMP X Asistente Aplicar RRP X Asistente Aplicar RRNP X Asistente Aplicar VC X Asistente Aplicar Varias Técnicas X Asistente Generar Valores Normalmente Distribuidos X Parámetros X X X X X X X Información de Archivos X X X X X X X Distribución Normal X X X X X X X Resultado Agregación X X X X X Tabla ASI 22: Trazabilidades entre el Modelo de Casos de Uso y el Diagrama de Clases Ing. María Florencia Pollo Cattaneo Pág. 162

163 4.7.- ESPECIFICACIÓN DEL PLAN DE PRUEBAS En esta actividad se inicia la definición del plan de pruebas, el cual sirve como guía para la realización de las pruebas, y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad. El plan de pruebas es un producto formal que define los objetivos de la prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del marco adecuado para elaborar una planificación paso a paso de las actividades de prueba. El plan se inicia en el proceso Análisis del Sistema de Información (ASI), definiendo el marco general, y estableciendo los requisitos de prueba de aceptación, relacionados directamente con la especificación de requisitos. Dicho plan se va completando y detallando a medida que se avanza en los restantes procesos del ciclo de vida del software, Diseño del Sistema de Información (DSI), Construcción del Sistema de Información (CSI) e Implantación y Aceptación del Sistema (IAS). Se plantean los siguientes niveles de prueba: Pruebas unitarias. Pruebas de integración. Pruebas del sistema. Pruebas de implantación. Pruebas de aceptación. Ing. María Florencia Pollo Cattaneo Pág. 163

164 En esta actividad también se avanza en la definición de las pruebas de aceptación del sistema. Con la información disponible, es posible establecer los criterios de aceptación de las pruebas incluidas en dicho nivel, al poseer la información sobre los requisitos que debe cumplir el sistema, recogidos en el catálogo de requisitos PLAN DE PRUEBAS La presente planificación de pruebas tiene como objetivo servir de guía para la realización de las pruebas, permitiendo verificar que el sistema construido cumple las necesidades establecidas dentro de un marco de garantía de calidad. Para especificar las pruebas se ha adoptado el modelo de pruebas especificado en el estándar de Documentación de Pruebas de Software de la IEEE [IEEE 829,1983], el cual ha sido adaptado a las características del presente proyecto. El propósito de este plan es describir la estrategia, el alcance, la aproximación, el esquema de plazos y los recursos necesarios para llevar a cabo las actividades de prueba del Sistema de Análisis de Precisión de Técnicas de Agregación en Contextos Experimentales Poco Maduros. Este plan identifica los ítems a ser probados, las características de los mismos, las tareas a ser realizadas y los responsables de las mismas ALCANCE El alcance de este plan esta limitado a la definición de las actividades generales de prueba a realizarse para el Sistema de Análisis de Precisión de Técnicas de Agregación en Contextos Experimentales Poco Maduros Ing. María Florencia Pollo Cattaneo Pág. 164

165 ÍTEMS Y CARACTERÍSTICAS A PROBAR El presente plan tiene como objetivo probar el Sistema de Análisis de Precisión de Técnicas de Agregación en Contextos Experimentales Poco Maduros, para lo cual se estima pertinente realizar pruebas unitarias (para verificar cómo se realiza cada función del sistema) y una prueba global del Sistema CARACTERÍSTICAS QUE NO VAN A SER PROBADAS Aplicaciones y herramientas no desarrolladas (por ejemplo, Sistema Operativo). Performance del producto (por ejemplo, tiempo de respuesta de la aplicación e interfaz de usuario) ACTIVIDADES A REALIZAR Las principales actividades de prueba a realizar están asociadas con las tareas de: Pruebas unitarias. Pruebas de sistema. Análisis y evaluación de la prueba PRUEBAS UNITARIAS Esta actividad debe cubrir cada una de las clases creadas durante la etapa de codificación. Todas las entradas y salidas de una clase deben ser probadas, y en caso de Ing. María Florencia Pollo Cattaneo Pág. 165

166 existir la posibilidad de combinar varias al mismo tiempo, esto también debe ser probado. Las pruebas unitarias deben desarrollarse de forma paralela a la codificación de la aplicación. Y sólo cuando las actividades de pruebas unitarias hayan sido superadas exitosamente, se podrá avanzar a la siguiente actividad de prueba PRUEBAS DE SISTEMA Las pruebas de sistema serán orientadas según la técnica de caja negra ; utilizado particularmente los métodos de partición de equivalencias y análisis de valores límites. Una prueba de caja negra examina algunos aspectos externos del modelo del sistema sin tener en cuenta la estructura lógica interna del software. Una vez que todos los casos de prueba han sido superados exitosamente, la aplicación estará lista para ser entregada PRUEBAS DE ACEPTACIÓN Estas pruebas serán realizadas por el Director del Proyecto, quien tomará como criterio de evaluación el cumplimiento, por parte del sistema, de los requisitos funcionales del mismo EJECUCION DE LAS PRUEBAS UNITARIAS Los resultados de las pruebas unitarias deberán ser almacenados en el documento de registro estándar y la ejecución de los mismos será manual. Ing. María Florencia Pollo Cattaneo Pág. 166

167 EJECUCION DE LAS PRUEBAS DE SISTEMA Los resultados de las pruebas deberán ser almacenados en el documento de registro estándar y la ejecución de las mismas será manual AMPLITUD DE LAS PRUEBAS La amplitud y criterio de completitud a emplear se basará en la cobertura realizada sobre la funcionalidad requerida REPORTE DE FALLAS DE LAS PRUEBAS Las fallas serán identificadas durante el análisis y evaluación de los resultados de la ejecución de las pruebas. A continuación, en la figura ASI 40, se detalla el formato del reporte de pruebas a utilizar: Figura ASI 40: Documento de reporte de pruebas Ing. María Florencia Pollo Cattaneo Pág. 167

168 TRAZABILIDAD DE REQUERIMIENTOS En el punto Análisis de consistencia entre métodos se detallan las matrices de trazabilidad que muestran la consistencia entre los distintos modelos generados en la fase de análisis DISPONIBILIDAD DE ÍTEMS DE PRUEBA Las actividades de prueba no podrán comenzar hasta que todas las unidades de prueba se encuentren disponibles DISPONIBILIDAD DE RECURSOS PARA LAS PRUEBAS A continuación se detallan los elementos necesarios para llevar a delante las pruebas unitarias y de sistema: 1 PC equipada mínimamente con: un procesador Pentium III (1.0 GHZ) 128 Mb de Memoria RAM 10 Mb libre en el disco rígido Sistema operativo Windows XP Professional CRITERIO PARA EVALUAR INSTANCIAS DE PRUEBA A continuación se detallan los criterios a aplicar en la evaluación de las distintas instancias de prueba. El criterio que explicaremos a continuación es el criterio Paso/Falla. Ing. María Florencia Pollo Cattaneo Pág. 168

169 EVALUACION DE INSTANCIAS DE PRUEBA APLICADO A CADA ÍTEMS El criterio a emplear sobre cada uno de los ítems es el siguiente: Paso: Todas las pruebas realizadas sobre el ítem fueron exitosas. Fallo: Al menos una de las pruebas realizadas no fue exitosa EVALUACION DE INSTANCIAS DE PRUEBA SOBRE LA APLICACIÓN El criterio a emplear sobre las pruebas de la aplicación es el siguiente: Exitosa: Todas las pruebas fueron realizados y no se encontraron defectos de severidad 1, 2 o 3. (Véase Tabla ASI 23: Severidad de Defectos). Fallida: Al menos un defecto de severidad 1, 2 o 3 fue encontrado. (Véase Tabla ASI 23: Severidad de Defectos). Nivel de Severidad Descripción 1 Sistema detenido 2 Fallas de funcionalidad 3 Una solución alternativa puede aplicarse 4 Error de documentación/ayuda 5 Cambios y mejoras Tabla ASI 23: Severidad de Defectos Ing. María Florencia Pollo Cattaneo Pág. 169

170 CRITERIO DE SUSPENSIÓN Y REINICIACIÓN DE PRUEBAS situaciones: Las actividades de prueba deberían ser suspendidas si ocurre alguna de las Se encuentra un problema en una prueba que impide la realización de la prueba. Se encuentra un problema en un ítem que impide la realización de más pruebas. Cuando se encuentre un problema y el mismo no impida la realización de más pruebas, las mismas deben continuar. Una vez solucionados los problemas encontrados, las pruebas deben reiniciarse, comenzando nuevamente por el primer caso de prueba para verificar que la solución del problema no haya generado nuevos inconvenientes ARTEFACTOS DE LAS PRUEBAS A continuación se detallan los elementos a generar como resultado de la realización de las pruebas: Plan de pruebas y Documento de diseño de la prueba. Especificación de los casos de prueba y Especificación del procedimiento de prueba. Informe de los casos de prueba. Informe de la prueba. Ing. María Florencia Pollo Cattaneo Pág. 170

171 ACTIVIDADES DE PRUEBA A continuación se detallan las actividades a realizarse para concretar cada uno de los ciclos de prueba: Actualizar el plan de pruebas y documento de diseño. Crear o actualizar casos y procedimientos de prueba. Ejecutar las pruebas y realizar el análisis, evaluación e informe de las mismas. Llevar a cabo la prueba de aceptación PROCEDIMIENTO DE PRUEBAS pruebas: A continuación, en la figura ASI 41, se detalla el esquema de procedimiento de Ing. María Florencia Pollo Cattaneo Pág. 171

172 Figura ASI 41: Procedimiento de Pruebas NECESIDADES DE AMBIENTE Existe un único ambiente de trabajo (al menos en este primer prototipo) y las propiedades mínimas requeridas para el mismo se especifican a continuación. Ing. María Florencia Pollo Cattaneo Pág. 172

173 HARDWARE PC Pentium III (1.0 GHZ) o superior 128 MB de RAM Al menos 100 MB libres en el disco rígido SOFTWARE Microsoft Framework 2.0 instalado SEGURIDAD Esta primera versión carece de la misma MODO DE USO Referirse a Definición del Sistema y Establecimiento de Requisitos CERTIFICACIÓN DE ENTORNO No existen necesidades concretas de certificación de entorno RESPONSABILIDADES Ingeniero de pruebas (esta función se encuentra a cargo de la Tesista) Diseñar, preparar y realizar las actividades de prueba. Ing. María Florencia Pollo Cattaneo Pág. 173

174 Gestionar el entorno local de prueba. Recolectar y analizar los resultados obtenidos de la realización de las actividades de prueba. Líder de desarrollo (esta función se encuentra a cargo de la Tesista) Proveer de los ítems a probar. Revisar el plan de pruebas. Revisar las actividades de prueba. Revisar los resultados de las pruebas realizadas. Líder de proyecto (esta función se encuentra a cargo de la Tesista) Revisar el plan de pruebas. Revisar los resultados de las pruebas realizadas. Coordinar las actividades de prueba. Especialista en calidad (esta función se encuentra a cargo del Director de Tesis) Revisar el plan de pruebas. Revisar las actividades de prueba. Ing. María Florencia Pollo Cattaneo Pág. 174

175 Cliente (esta función se encuentra a cargo del Director de Tesis) Realizar las pruebas de aceptación RIESGOS Y CONTINGENCIAS DE PRUEBAS A continuación, en la tabla ASI 24, de detallan posibles riesgos a enfrentar en la implementación del sistema con sus respectivas contingencias Riesgos Diferencias entre el entorno de desarrollo y de pruebas y el entorno del cliente Falta de conocimiento del usuario de la herramienta para ejecutar la aplicación Contingencias Especificar como parte de la documentación a entregar los requerimientos de software y hardware y colaborar con el usuario en la verificación/instalación de los mismos Especificar como parte de la documentación a entregar los pasos para ejecutar el sistema y colaborar con el usuario en la realización de los mismos Tabla ASI 24: Análisis de Riesgos y Contingencias APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN PRESENTACIÓN Y APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN En esta tarea se realiza la presentación del análisis del sistema de información al Comité de Dirección, para la aprobación final del mismo. En una reunión mantenida entre la Tesista y el Director de la Tesis se dio por aprobada la fase de Análisis del Sistema de Información. Ing. María Florencia Pollo Cattaneo Pág. 175

177 Capítulo 5 Diseño del Sistema de Información Ing. María Florencia Pollo Cattaneo Pág. 177

179 5.- DISEÑO DEL SISTEMA DE INFORMACIÓN El objetivo del proceso de Diseño del Sistema de Información (DSI) es la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda. Al ser MÉTRICA Versión III una metodología que cubre tanto desarrollos estructurados como orientados a objetos, las actividades de ambas aproximaciones están integradas en una estructura común. Las actividades de este proceso se agrupan en dos grandes bloques: Ing. María Florencia Pollo Cattaneo Pág. 179

180 1. En un primer bloque de actividades, que se llevan a cabo en paralelo, se obtiene el diseño de detalle del sistema de información. La realización de estas actividades exige una continua realimentación. En general, el orden real de ejecución de las mismas depende de las particularidades del sistema de información y, por lo tanto, de generación de sus productos. En la actividad Definición de la Arquitectura del Sistema, se establece el particionamiento físico del sistema de información, así como su organización en subsistemas de diseño, la especificación del entorno tecnológico, y sus requisitos de operación, administración, seguridad y control de acceso. Se completan los catálogos de requisitos y normas, en función de la definición del entorno tecnológico, con aquellos aspectos relativos al diseño y construcción que sea necesario contemplar. Asimismo, se crea un catálogo de excepciones del sistema, en el que se registran las situaciones de funcionamiento secundario o anómalo que se estime oportuno considerar y, por lo tanto, diseñar y probar. Este catálogo de excepciones se utiliza como referencia en la especificación técnica de las pruebas del sistema. El particionamiento físico del sistema de información permite organizar un diseño que contemple un sistema de información distribuido, como por ejemplo la arquitectura cliente/servidor, siendo aplicable a arquitecturas multinivel en general. Independientemente de la infraestructura tecnológica, dicho particionamiento representa los distintos niveles funcionales o físicos del sistema de información. La relación entre los elementos del diseño y particionamiento físico, y a su vez, entre el particionamiento físico y el entorno tecnológico, permite una especificación de la distribución de los elementos del sistema de información y, al mismo tiempo, un diseño orientado a la movilidad a otras plataformas o la reubicación de subsistemas. El sistema de información se estructura en subsistemas de diseño. Éstos a su vez se clasifican como de soporte o específicos, al responder a propósitos diferentes. Ing. María Florencia Pollo Cattaneo Pág. 180

181 Los subsistemas de soporte contienen los elementos o servicios comunes al sistema y a la instalación, y generalmente están originados por la interacción con la infraestructura técnica o la reutilización de otros sistemas, con un nivel de complejidad técnica mayor. Los subsistemas específicos contienen los elementos propios del sistema de información, generalmente con una continuidad de los subsistemas definidos en el proceso de Análisis del Sistema de Información (ASI). También se especifica en detalle el entorno tecnológico del sistema de información, junto con su planificación de capacidades (capacity planning), y sus requisitos de operación, administración, seguridad y control de acceso. El diseño detallado del sistema de información, siguiendo un enfoque estructurado, comprende un conjunto de actividades que se llevan a cabo en paralelo a la Definición de la Arquitectura del Sistema. El alcance de cada una de estas actividades se resume a continuación: Diseño de la Arquitectura de Soporte, que incluye el diseño detallado de los subsistemas de soporte, el establecimiento de las normas y requisitos propios del diseño y construcción, así como la identificación y definición de los mecanismos genéricos de diseño y construcción. Diseño de la Arquitectura de Módulos del Sistema, en donde se realiza el diseño de detalle de los subsistemas específicos del sistema de información y la revisión de la interfaz de usuario. Diseño Físico de Datos, que incluye el diseño y optimización de las estructuras de datos del sistema, así como su localización en los nodos de la arquitectura propuesta. En el caso de Diseño Orientado a Objetos, conviene señalar que el diseño de la persistencia de los objetos se lleva a cabo sobre bases de datos Ing. María Florencia Pollo Cattaneo Pág. 181

182 relacionales, y que el diseño detallado del sistema de información se realiza en paralelo con la actividad de Diseño de la Arquitectura de Soporte, y se corresponde con las siguientes actividades: Diseño de Casos de Uso Reales, con el diseño detallado del comportamiento del sistema de información para los casos de uso, el diseño de la interfaz de usuario y la validación de la división en subsistemas. Diseño de Clases, con el diseño detallado de cada una de las clases que forman parte del sistema, sus atributos, operaciones, relaciones y métodos, y la estructura jerárquica del mismo. En el caso de que sea necesario, se realiza la definición de un plan de migración y carga inicial de datos. Una vez que se tiene el modelo de clases, se comienza el diseño físico en la actividad Diseño Físico de Datos, común con el enfoque estructurado. Una vez finalizado el diseño de detalle, se realiza su revisión y validación en la actividad Verificación y Aceptación de la Arquitectura del Sistema, con el objeto de analizar la consistencia entre los distintos modelos y conseguir la aceptación del diseño por parte de los responsables de las áreas de Explotación y Sistemas. 2. El segundo bloque de actividades complementa el diseño del sistema de información. En él se generan todas las especificaciones necesarias para la construcción del sistema de información: Generación de Especificaciones de Construcción, fijando las directrices para la construcción de los componentes del sistema, así como de las estructuras de datos. Ing. María Florencia Pollo Cattaneo Pág. 182

183 Diseño de la Migración y Carga Inicial de Datos, en el que se definen los procedimientos de migración y sus componentes asociados, con las especificaciones de construcción oportunas. Especificación Técnica del Plan de Pruebas, que incluye la definición y revisión del plan de pruebas, y el diseño de las verificaciones de los niveles de prueba establecidos. El catálogo de excepciones permite, de una forma muy ágil, establecer un conjunto de verificaciones relacionadas con el propio diseño o con la arquitectura del sistema. Establecimiento de Requisitos de Implantación, que hace posible concretar las exigencias relacionados con la propia implantación del sistema, tales como formación de usuarios finales, infraestructura, etc. Finalmente, en la actividad de Presentación y Aprobación del Diseño del Sistema de Información, se realiza una presentación formal y aprobación de los distintos productos del diseño DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA En esta actividad se define la arquitectura general del sistema de información, especificando las distintas particiones físicas del mismo, la descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición, así como la especificación detallada de la infraestructura tecnológica necesaria para dar soporte al sistema de información. El particionamiento físico del sistema de información se especifica identificando los nodos y las comunicaciones entre los mismos, con cierta independencia de la infraestructura tecnológica que da soporte a cada nodo. Ing. María Florencia Pollo Cattaneo Pág. 183

184 Con el fin de organizar y facilitar el diseño, se realiza una división del sistema de información en subsistemas de diseño, como partes lógicas coherentes y con interfaces claramente definidas. Para esto, se establece una distinción entre subsistemas específicos del sistema de información (en adelante, subsistemas específicos) y subsistemas de soporte, con la finalidad de independizar, en la medida de lo posible, las funcionalidades a cubrir por el sistema de información de la infraestructura que le da soporte. En la mayoría de los casos, los subsistemas específicos provienen directamente de las especificaciones de análisis y de los subsistemas de análisis, mientras que los subsistemas de soporte provienen de la necesidad de interacción del sistema de información con la infraestructura y con el resto de los sistemas, así como de la reutilización de módulos o subsistemas ya existentes en la instalación. Debido a que la definición de los subsistemas de soporte puede exigir la participación de distintos perfiles técnicos, se propone el diseño de ambos tipos de subsistemas en actividades distintas, aunque en paralelo. Una vez identificados y definidos los distintos subsistemas de diseño, se determina su ubicación óptima de acuerdo a la arquitectura propuesta. La asignación de dichos subsistemas a cada nodo permite disponer, en función de la carga de proceso y comunicación existente entre los nodos, de la información necesaria para realizar una estimación de las necesidades de infraestructura tecnológica que da soporte al sistema de información. Este factor es especialmente crítico en arquitecturas multinivel o cliente/servidor, donde las comunicaciones son determinantes en el rendimiento final del sistema. Se propone crear un catálogo de excepciones en el que se especifiquen las situaciones anómalas o secundarias en el funcionamiento y ejecución del sistema de información, el que se irá completando a medida que se avance en el diseño detallado de los subsistemas. Para ello, también se establecen los requisitos, normas y estándares originados como consecuencia de la adopción de una determinada solución de arquitectura o infraestructura, que serán aplicables tanto en este proceso como en la Construcción del Sistema de Información (CSI). Se detallan a su vez, de acuerdo a las Ing. María Florencia Pollo Cattaneo Pág. 184

185 particularidades de la arquitectura del sistema propuesta, los requisitos de operación, seguridad y control, especificando los procedimientos necesarios para su cumplimiento. Como resultado final de esta actividad, se actualizan los catálogos de requisitos y normas, y se generan los siguientes productos: Diseño de la Arquitectura del Sistema, como producto que engloba el particionamiento físico del sistema de información y la descripción de subsistemas de diseño. Entorno Tecnológico del Sistema, que a su vez comprende la especificación del entorno tecnológico, las restricciones técnicas y la planificación de capacidades. Catálogo de Excepciones. Procedimientos de Operación y Administración del Sistema. Procedimientos de Seguridad y Control de Acceso DEFINICIÓN DE NIVELES DE ARQUITECTURA En esta tarea se definen los niveles de arquitectura software, mediante la definición de las principales participaciones físicas del sistema de información, representadas como nodos y comunicaciones entre nodos. Se entenderá por nodo a cada participación física o parte significativa del sistema de información, con características propias de ejecución o función, e incluso, de diseño y construcción. Ing. María Florencia Pollo Cattaneo Pág. 185

186 Para facilitar la comprensión del sistema, el mismo se documentará mediante un Modelo de Despliegue de Componentes de UML. A continuación, se describen los elementos que contempla este tipo de diagrama: Nodos de procesamiento Dispositivos hardware Comunicación entre nodos y con dispositivos Componentes de software empaquetados en unidades instalables DESCRIPCIÓN DE LOS NIVELES DE ARQUITECTURA DEL SISTEMA sistema: A continuación, en la figura DSI 1, se describen los componentes del presente Figura DSI 1: Diagrama de componentes del Sistema Ing. María Florencia Pollo Cattaneo Pág. 186

187 siguientes: El sistema tiene un único equipo (único nodo), y sus características son las Requerimientos de Hardware mínimo: Procesador Pentium III (1.0 GHZ) o similar 128 MB de memoria RAM 20 MB libres en disco rígido Sistema Operativo Windows 2000/XP o superior A continuación realizaremos una descripción de los componentes identificados: DMP: generador de la técnica de agregación de Diferencian de Medias Ponderadas. Representa la función que el usuario puede ejecutar para aplicar dicha técnica a un conjunto de experimentos. RRP: generador de la técnica de agregación de Response Ratio Paramétrico. Representa la función que el usuario puede ejecutar para aplicar dicha técnica a un conjunto de experimentos. RRNP: generador de la técnica de agregación de Response Ratio No Paramétrico. Representa la función que el usuario puede ejecutar para aplicar dicha técnica a un conjunto de experimentos. VC: generador de la técnica de agregación de Vote Counting. Representa la función que el usuario puede ejecutar para aplicar dicha técnica a un conjunto de experimentos. Ing. María Florencia Pollo Cattaneo Pág. 187

188 DN: generador de distribución normal. Representa la función que el usuario puede ejecutar para generar, a partir de un conjunto de parámetros, otro conjunto de números aleatorios con distribución de probabilidad gaussiana. Tablas DN: represente un archivo físico donde se almacena el conjunto de números aleatorios de distribución normal. Archivo Resultado formato texto: también es un archivo físico, donde se almacena el resultado de la aplicación de la o las técnicas estadísticas de agregación. Archivo Resultado formato Excel: es similar al anterior, sólo que mantiene un formato de plantilla de cálculo Microsoft Excel. El sistema reside en un único equipo y no requiere de una base de datos (al menos en este primer prototipo). La información se almacena en archivos que pueden ser de texto o plantillas de cálculo Microsoft Excel. Debido a la existencia de un único equipo y la ausencia de Base de Datos, la comunicación entre componentes se realizará a través de mensajes en un modelo POO (Programación Orientada a Objetos) IDENTIFICACIÓN DE REQUISITOS DE DISEÑO Y CONSTRUCCIÓN En esta tarea se realiza la especificación de los requisitos que están directamente relacionados con la adopción o diseño de una arquitectura o infraestructura concreta, y que pueden condicionar el diseño o la construcción del sistema de información. Ing. María Florencia Pollo Cattaneo Pág. 188

189 Entre estos requisitos pueden estar los relacionados con lenguajes, rendimiento de los distintos elementos de la arquitectura, así como criterios de ubicación de módulos y datos en los distintos nodos. Por tanto, como resultado de esta tarea se actualiza el catálogo de requisitos elaborado en el proceso Análisis de Sistemas de Información DESCRIPCIÓN DE LOS REQUISITOS ADICIONALES A continuación, en la tabla DSI 1, se detallan los requisitos no funcionales identificados a lo largo de esta fase: Código de requisito Identificación del requisito Descripción del Requisito RNF-5 Carga de trabajo Los componentes del cliente serán desarrollados teniendo en cuenta soportar la carga de un único usuario Tabla DSI 1: Requisitos no funcionales de diseño ESPECIFICACIONES DE EXCEPCIÓN El objetivo de esta tarea es la definición de los comportamientos no habituales en el sistema, que reflejan situaciones anómalas o secundarias en el funcionamiento y ejecución del sistema de información. Para ello, se establece previamente el nivel de especificación de las mismas, así como los criterios de catalogación y clasificación. Se propone su catalogación como ayuda para el diseño del sistema de información y como guía en la especificación técnica de las pruebas, al permitir la generación de algunos casos de prueba de forma inmediata. Dicho catálogo se va completando a partir de las actividades correspondientes al diseño detallado de los subsistemas. Ing. María Florencia Pollo Cattaneo Pág. 189

190 Las excepciones se describen incluyendo, al menos, los siguientes conceptos: Tipo y descripción de la excepción. Condiciones previas del sistema de información. Elemento afectado (nodo, módulo, caso de uso). Respuesta del sistema de información. Elemento asociado a la respuesta esperada del sistema (módulo, clase, procedimiento, etc.). Las excepciones que se proponen como obligatorias son las relacionadas con el funcionamiento general del sistema de información, habitualmente asociadas a: Nodos y comunicaciones del particionamiento físico del sistema de información. Este tipo de excepciones tiene lugar cuando no están disponibles los gestores de bases de datos o los recursos compartidos del sistema (representados como nodos), cuando se producen fallos en las comunicaciones entre nodos, etc. Rangos o valores no válidos en la entrada de datos, como pueden ser atributos obligatorios, con formatos específicos, etc. Se recomienda, según el nivel de especificación que se establezca en cada caso, catalogar también las excepciones particulares que se identifiquen en las actividades del diseño de detalle. Ing. María Florencia Pollo Cattaneo Pág. 190

191 CATÁLOGO DE EXCEPCIONES Para el presente desarrollo se ha determinado que el principal motivo de excepción se puede producir por el acceso a archivos. Las excepciones de acceso a archivos se producirán cuando el archivo con la distribución normal no tiene el formato adecuado, o se solicita guardar el resultado en un archivo de extensión xls, y el equipo no tiene instalado Microsoft Office (o solamente carece de Excel). A continuación, en las tablas DSI 2 a DSI 5 se describen las excepciones que se contemplan en el presente desarrollo: Excepción Tipo Descripción Condiciones previas Elemento afectado Respuesta del sistema EX-A001 Acceso a archivo Se pretende acceder a un archivo de distribución normal que no es de tipo texto El archivo está almacenado en un formato que no es de texto Módulos de aplicación de técnicas de agregación (DMP, RRP, RRNP, VC y Varias Técnicas) Mensaje de error al usuario indicando la imposibilidad de usar el archivo seleccionado: El archivo seleccionado no es de texto, no puede procesarse Tabla DSI 2: Excepción de acceso a archivo Excepción Tipo Descripción EX-A002 Acceso a archivo Se pretende acceder a un archivo de distribución normal que tiene un formato equivocado Ing. María Florencia Pollo Cattaneo Pág. 191

192 Condiciones previas Elemento afectado Respuesta del sistema El archivo está almacenado en un formato que no es el de conjunto de números aleatorios Módulos de aplicación de técnicas de agregación (DMP, RRP, RRNP, VC y Varias Técnicas) Mensaje de error al usuario indicando la imposibilidad de usar el archivo seleccionado: El archivo seleccionado no tiene el formato adecuado, no puede procesarse Tabla DSI 3: Excepción de acceso a archivo Excepción Tipo Descripción Condiciones previas Elemento afectado Respuesta del sistema EX-A003 Almacenamiento de archivo Se pretende almacenar un archivo de resultado en un tipo xls, y el equipo no tiene instalado Excel El equipo no tiene instalado Microsoft Office o e componente Excel Módulos de aplicación de técnicas de agregación (DMP, RRP, RRNP, VC y Varias Técnicas) Mensaje de error al usuario indicando la imposibilidad de almacenar el archivo en este formato: No puede almacenar en Excel. Primero instale Microsoft Office Tabla DSI 3: Excepción de almacenamiento de archivo Excepción Tipo Descripción EX-A004 Almacenamiento de archivo Se pretende almacenar un archivo de resultado en un tipo xls, y el número de simulaciones es muy grande para Excel Ing. María Florencia Pollo Cattaneo Pág. 192

193 Condiciones previas Elemento afectado Respuesta del sistema El equipo no tiene instalado Microsoft Office o el componente Excel Módulos de aplicación de técnicas de agregación (DMP, RRP, RRNP, VC y Varias Técnicas) Mensaje de error al usuario indicando la imposibilidad de almacenar el archivo en este formato: No puede almacenar en Excel antas simulaciones. Se generarán en Excel las primeras 100 simulaciones en Excel, y la totalidad en txt Tabla DSI 4: Excepción de almacenamiento de archivo IDENTIFICACIÓN DE SUBSISTEMAS DE DISEÑO En esta tarea se divide de forma lógica el sistema de información en subsistemas de diseño, con el fin de reducir la complejidad y facilitar el mantenimiento. Hay que tomar como referencia inicial los subsistemas de análisis especificados en el proceso de Análisis del Sistema de Información (ASI). La división en subsistemas de diseño se puede realizar con una continuidad directa de los modelos del análisis, o aplicando nuevos criterios de diseño, entre los que es posible citar los siguientes: Facilidad de mantenimiento. Reutilización de elementos del propio sistema o de la instalación. Optimización de recursos (por ejemplo, líneas de comunicaciones). Características de ejecución (en línea o por lotes). Funcionalidad común. Ing. María Florencia Pollo Cattaneo Pág. 193

194 Aplicación de mecanismos genéricos de diseño al nivel de arquitectura. Los subsistemas resultantes se califican como específicos o de soporte, asignando cada subsistema al nodo correspondiente, en nuestro caso, un único nodo en este primer prototipo. Los subsistemas específicos contemplan las funcionalidades propias del sistema de información, mientras que los de soporte cubren servicios comunes, proporcionando un acceso transparente a los distintos recursos. Estos últimos están relacionados con: Comunicaciones entre subsistemas. Gestión de datos (acceso a bases de datos, ficheros, áreas temporales, importación y exportación de datos, sincronización de bases de datos, etc.). Gestión de transacciones. Control y gestión de errores. Seguridad y control de acceso. Gestión de interfaz. Interacción con los recursos propios del sistema. La interacción del sistema de información con la infraestructura que le da soporte, así como con el resto de los sistemas y servicios de la instalación, puede originar la necesidad de nuevos subsistemas, módulos, clases o servicios no especificados en el análisis. Ing. María Florencia Pollo Cattaneo Pág. 194

195 La definición del comportamiento externo de cada subsistema se completa durante el diseño de detalle con la especificación de su interfaz, así como con la dependencia entre subsistemas. El diseño de detalle de los subsistemas identificados por criterios de optimización y reutilización, puede aconsejar la reorganización y reubicación de los elementos que forman parte de cada subsistema y, a su vez, puede dar lugar a la identificación de nuevos subsistemas de soporte. En diseño estructurado, la descripción de los subsistemas de diseño que conforman el sistema de información se especifica mediante un diagrama de estructura de alto nivel, que muestra los distintos subsistemas de que consta el sistema, incluidos los subsistemas de soporte, junto con la definición de la interfaz de cada subsistema. La ubicación de subsistemas en nodos y la dependencia entre subsistemas se especifica por medio de técnicas matriciales, o bien en lenguaje natural o pseudocódigo SUBSISTEMAS DE DISEÑO En este prototipo no tenemos base de datos, y sólo hay un nodo en el diseño arquitectónico. Debido a estas simplificaciones, dividiremos lógicamente al sistema en dos capas, que representarán cada una a un subsistema. Estas capas serán las de interfaz de usuario, y la capa de lógica de negocio. Para próximas versiones se piensa incorporar, al menos, una capa de acceso a datos (puede ser la misma que la capa de lógica de negocio), y una capa de datos, que comprenderá la base de datos y los procedimientos almacenados. Volviendo a la presente versión, identificamos las dos capas mencionadas, que representamos gráficamente en la figura DSI 2. Ing. María Florencia Pollo Cattaneo Pág. 195

196 Figura DSI 2: Diagrama de capas del sistema en dos capas lógicas (subsistemas) ESPECIFICACIÓN DEL ENTORNO TECNOLÓGICO En esta tarea se definen en detalle los distintos elementos de la infraestructura técnica que dan soporte al sistema de información, determinando la implementación concreta de los nodos y comunicaciones especificados en la tarea Definición de Niveles de Arquitectura (DSI 1.1). Para esto, se propone agrupar los elementos de la infraestructura en los siguientes conceptos: Hardware: procesadores, unidades de almacenamiento, estaciones de trabajo, etc. Software: sistemas operativos, subsistemas, sistemas de ficheros, software de base, herramientas y utilidades de gestión propias del sistema, etc. Comunicaciones: diseño de la topología de la red, protocolos, nodos de red, etc. (en esta primera versión no tenemos en cuenta este punto) La definición de los distintos elementos puede generar restricciones técnicas que afecten al diseño o construcción del sistema de información. Ing. María Florencia Pollo Cattaneo Pág. 196

197 Asimismo, se realiza una estimación de la planificación de capacidades (capacity planning) o se especifican los parámetros que Explotación y Sistemas precisen para realizar dicha planificación. Se indican, al menos, las necesidades previstas de: Almacenamiento: espacio en disco, espacio en memoria, pautas de crecimiento y evolución estimada del sistema de información, etc. Procesamiento: número y tipo de procesadores, memoria, etc. Comunicaciones: líneas, caudal, capacidades de elementos de red, etc. Para poder determinar la planificación de capacidades, es necesario conocer los diseños detallados de los módulos / clases y escenarios, incluida la información de control en las comunicaciones, así como el diseño físico de datos optimizado, productos que se están generando en paralelo a esta actividad. También se tienen en cuenta, cuando proceda, las estimaciones de volúmenes de datos propios de la migración y carga inicial de datos ESPECIFICACIÓN DE HARDWARE El sistema podrá ser ejecutado en equipos de distintas tecnologías. Se estiman las siguientes configuraciones mínimas: Plataforma Intel: Procesador Pentium III (1.0 GHZ) o superior. 128 Mb de RAM. 1GB de espacio libre en disco. Plataforma AMD: Procesador Attlon o superior. 128 Mb de RAM. 1GB de espacio libre en disco. Ing. María Florencia Pollo Cattaneo Pág. 197

198 ESPECIFICACIÓN DE SOFTWARE Para ambas plataformas: Sistema Operativo Microsoft Windows XP Professional, 2000 o superior ESPECIFICACIÓN DE COMUNICACIÓN No se requiere en esta versión ESPECIFICACIÓN DE REQUISITOS DE OPERACIÓN Y SEGURIDAD El objetivo de esta tarea es definir los procedimientos de seguridad y operación necesarios para no comprometer el correcto funcionamiento del sistema y garantizar el cumplimiento de los niveles de servicios que exigirá el sistema en cuanto a la gestión de operaciones (procesos por lotes, seguridad, comunicaciones, etc.). Los niveles de servicio se especifican formalmente en el proceso Implantación y Aceptación del Sistema (IAS). Tomando como referencia los requisitos establecidos para el sistema, y teniendo en cuenta la arquitectura propuesta y las características del entorno tecnológico definido en esta actividad, se lleva a cabo la definición de los requisitos de seguridad y control de acceso necesarios para garantizar la protección del sistema y minimizar el riesgo de pérdida, alteración o consulta indebida de la información. Debido a que esta versión no posee base de datos (por no ser necesario almacenar información), este paso del diseño no se realizará en esta instancia. Queda como tarea pendiente para una futura versión. Ing. María Florencia Pollo Cattaneo Pág. 198

199 5.2.- DISEÑO DE LA ARQUITECTURA DE SOPORTE En esta actividad se lleva a cabo la especificación de la arquitectura de soporte, que comprende el diseño de los subsistemas de soporte identificados en la actividad de Definición de la Arquitectura del Sistema (DSI 1), y la determinación de los mecanismos genéricos de diseño. Estos últimos sirven de guía en la utilización de diferentes estilos de diseño, tanto en el ámbito global del sistema de información, como en el diseño de detalle. El diseño de los subsistemas de soporte, conceptualmente, es similar al diseño de los subsistemas específicos, aunque debe cumplir con unos objetivos claros de reutilización. De esta manera, se consigue simplificar y abstraer el diseño de los subsistemas específicos de la complejidad del entorno tecnológico, dotando al sistema de información de una mayor independencia de la infraestructura que le da soporte. Con este fin, se aconseja la consulta de los datos de otros proyectos existentes, disponible en el Histórico de Proyectos. Si no fuera suficiente, se puede contar en esta actividad, con la participación de perfiles técnicos, que poseen una visión global de la instalación. Esta actividad se realiza en paralelo al diseño detallado, debido a que existe una constante realimentación, tanto en la especificación de los subsistemas con sus interfaces y dependencias, como en la aplicación de esqueletos o patrones en el diseño. Los productos resultantes de esta actividad son: Diseño Detallado de los Subsistemas de Soporte. Mecanismos Genéricos de Diseño y Construcción. Ing. María Florencia Pollo Cattaneo Pág. 199

200 DISEÑO DE SUBSISTEMAS DE SOPORTE El objetivo de esta tarea es la especificación y diseño de los módulos/clases que forman parte de los subsistemas de soporte, identificados en la tarea Identificación de Subsistemas de Diseño. Se lleva a cabo siempre y cuando no se disponga en la instalación de servicios comunes que respondan satisfactoriamente a los requisitos planteados. El nivel de reutilización de los subsistemas de soporte y sus servicios es potencialmente alto, de modo que se debe intentar emplear, en la medida de lo posible, los subsistemas que ya existan en la instalación y se consideren viables. La información relativa a dichos subsistemas podrá obtenerse del Histórico de Proyectos. En cualquier caso, cuando se proceda a realizar el diseño de los subsistemas de soporte, se recomienda hacerlo con ese fin. El diseño sigue las mismas pautas que las establecidas para los subsistemas específicos, aunque con las siguientes particularidades: Generalmente, será necesaria una descomposición de los subsistemas de soporte en servicios, entendiendo como tales módulos o clases independientes y reutilizables. Se recomienda realizar una descripción de la interfaz y del comportamiento de cada servicio, previa a su diseño de detalle, que permita completar el diseño de los subsistemas específicos. La especificación y diseño de cada servicio, módulo o clase, se realiza con las técnicas habituales de especificación y diseño de módulos o clases, o incluso opcionalmente, si la simplicidad de los elementos lo aconseja, otros lenguajes de especificación, pseudocódigo o lenguaje natural. Ing. María Florencia Pollo Cattaneo Pág. 200

201 A medida que se lleva a cabo esta tarea pueden surgir comportamientos de excepción que deberán contemplarse igualmente en el diseño, y que en función del nivel de especificación que se haya establecido, se incorporan al catálogo de excepciones DISEÑO DETALLADO DEL SISTEMA DE SOPORTE La arquitectura del sistema consta de un único nodo, sin base de datos ni comunicación del equipo con otro equipo o dispositivo. Solamente se realizará el procesamiento del conjunto de números aleatorios de distribución de probabilidad gaussiana que se genere, y se trabajará con archivos. Esta simplicidad del sistema, hace que su soporte no requiera de mucha tecnología, utilizándose, solamente las clases estándar (incluyendo las de formato de pantallas) que proporciona Visual Basic NET. Al no tener que diseñar una base de datos, ni mecanismos de seguridad en relación al almacenamiento de información, no se trabaja con transacciones ni archivos de respaldo DISEÑO DE CASOS DE USO REALES Esta actividad, que se realiza sólo en el caso de Diseño Orientado a Objetos, tiene como propósito especificar el comportamiento del sistema de información para un caso de uso, mediante objetos o subsistemas de diseño que interactúan, y determinar las operaciones de las clases e interfaces de los distintos subsistemas de diseño. Para ello, una vez identificadas las clases participantes dentro de un caso de uso, es necesario completar los escenarios que se recogen del análisis, incluyendo las clases de diseño que correspondan y teniendo en cuenta las restricciones del entorno tecnológico, esto es, detalles relacionados con la implementación del sistema. Es necesario analizar los comportamientos de excepción para dichos escenarios. Algunos pueden haber sido identificados en el proceso de análisis, aunque no se resuelven hasta este momento. Dichas excepciones se añadirán al catálogo de excepciones para facilitar las pruebas. Ing. María Florencia Pollo Cattaneo Pág. 201

202 Algunos de los escenarios detallados requerirán una nueva interfaz de usuario. Por este motivo es necesario diseñar el formato de cada una de las pantallas o impresos identificados. Es importante validar que los subsistemas definidos en la tarea Identificación de Subsistemas de Diseño tengan la mínima interfaz con otros subsistemas. Por este motivo, se elaboran los escenarios al nivel de subsistemas y, de esta forma, se delimitan las interfaces necesarias para cada uno de ellos, teniendo en cuenta toda la funcionalidad del sistema que recogen los casos de uso. Además, durante esta actividad pueden surgir requisitos de implementación, que se recogen en el catálogo de requisitos. Las tareas de esta actividad se realizan en paralelo con las de Diseño de Clases IDENTIFICACIÓN DE CLASES ASOCIADAS A UN CASO DE USO El objetivo de esta tarea es identificar las clases que intervienen en cada caso de uso, a partir del conjunto de clases definidas en la tarea Identificación de Clases Adicionales, ya que, como se ha señalado en la introducción, las actividades Diseño de casos de uso reales y Diseño de clases, se realizan en paralelo. Dichas clases se identifican a partir de las clases del modelo del análisis y de aquellas clases adicionales necesarias para el escenario que se está diseñando. A su vez, a medida que se va estudiando la descripción de los casos de uso, pueden aparecer nuevas clases de diseño que no hayan sido identificadas anteriormente y que se incorporan al modelo de clases en la tarea Identificación de Clases Adicionales CLASES ASOCIADAS A LOS CASOS DE USOS A continuación, en las figuras DSI 3 a DSI 12, se describen las clases de diseño que se utilizan para realizar cada caso de uso: Ing. María Florencia Pollo Cattaneo Pág. 202

203 1) Caso de uso Aplicar DMP: Figura DSI 3: Diagrama de Clases del caso de uso Aplicar DMP 2) Caso de uso Aplicar RRP: Figura DSI 4: Diagrama de Clases del caso de uso Aplicar RRP 3) Caso de uso Aplicar RRNP: Figura DSI 5: Diagrama de Clases del caso de uso Aplicar RRNP Ing. María Florencia Pollo Cattaneo Pág. 203

204 4) Caso de uso Aplicar VC: Figura DSI 6: Diagrama de Clases del caso de uso Aplicar VC 5) Caso de uso Aplicar Varias Técnicas: Figura DSI 7: Diagrama de Clases del caso de uso Aplicar Varias Técnicas 6) Caso de uso Generar Valores Normalmente Distribuidos (DN): Figura DSI 8: Diagrama de Clases del caso de uso Generar Valores Normalmente stribuidos (DN) Ing. María Florencia Pollo Cattaneo Pág. 204

205 7) Caso de uso Seleccionar Parámetros: Figura DSI 9: Diagrama de Clases del caso de uso Seleccionar Parámetros 8) Caso de uso Seleccionar Técnica de Agregación: Figura DSI 10: Diagrama de Clases del caso de uso Seleccionar Técnica de Agregación 9) Caso de uso Seleccionar Tipo de Archivo: Figura DSI 11: Diagrama de Clases del caso de uso Seleccionar Tipo de Archivo 10) Caso de uso Seleccionar DN: Figura DSI 12: Diagrama de Clases del caso de uso Seleccionar DN Ing. María Florencia Pollo Cattaneo Pág. 205

206 REVISIÓN DE LA INTERFAZ DE USUARIO El objetivo de esta tarea es realizar el diseño detallado del comportamiento de la interfaz de usuario a partir de la especificación de la misma, obtenida en el proceso de análisis, y de acuerdo con el entorno tecnológico definido. Si se hubiera realizado un prototipo de la interfaz de usuario, éste se tomaría como punto de partida para el diseño. Además, se incluyen las ventanas alternativas o elementos de diseño surgidos como consecuencia del diseño de los escenarios definidos en la tarea anterior. Se debe revisar: la interfaz de usuario, la navegación entre ventanas, los elementos que forman cada interfaz, sus características (que deben ser consistentes con los atributos con los que están relacionadas), su disposición, y cómo se gestionan los eventos relacionados con los objetos. En aquellos casos en los que se realizan modificaciones significativas sobre la interfaz de usuario, es conveniente que éste las valide, siendo opcional la realización de un nuevo prototipo RESULTADO DE LA REVISIÓN DE LA INTERFAZ DE USUARIO Como puede verse en el apartado anterior, no aparecen nuevas clases de interfaz que deban ser tratadas en este punto. Igualmente se ha realizado una comparación entre las clases de interfaz antes definidas y las actuales clases de diseño y no se han encontrado diferencias significativas que justifiquen la modificación del actual modelo DISEÑO DE CLASES El propósito de esta actividad, que se realiza sólo en el caso de Diseño Orientado a Objetos, es transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño. Dicho modelo recoge la especificación detallada de cada Ing. María Florencia Pollo Cattaneo Pág. 206

207 una de las clases, es decir, sus atributos, operaciones, métodos, y el diseño preciso de las relaciones establecidas entre ellas, bien sean de agregación, asociación o jerarquía. Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno tecnológico y el entorno de desarrollo elegido para la implementación. Se identifican las clases de diseño, que denominamos clases adicionales, en función del estudio de los escenarios de los casos de uso, que se está realizando en paralelo en la actividad Diseño de Casos de Uso Reales, y aplicando los mecanismos genéricos de diseño que se consideren convenientes por el tipo de especificaciones tecnológicas y de desarrollo. Entre ellas se encuentran clases abstractas, que integran características comunes con el objetivo de especializarlas en clases derivadas. Se diseñan las clases de interfaz de usuario, que provienen del análisis. Como consecuencia del estudio de los escenarios secundarios que se está realizando, pueden aparecer nuevas clases de interfaz. También hay que considerar que, por el diseño de las asociaciones y agregaciones, pueden aparecer nuevas clases, o desaparecer incluyendo sus atributos y métodos en otras, si se considera conveniente por temas de optimización. La jerarquía entre las clases se va estableciendo a lo largo de esta actividad, a medida que se van identificando comportamientos comunes en las clases, aunque haya una tarea propia de diseño de la jerarquía. Otro de los objetivos del diseño de las clases es identificar para cada clase, los atributos, las operaciones que cubren las responsabilidades que se identificaron en el análisis, y la especificación de los métodos que implementan esas operaciones, analizando los escenarios del Diseño de Casos de Uso Reales, luego, se determina la visibilidad de los atributos y operaciones de cada clase, con respecto a las otras clases del modelo. Una vez que se ha elaborado el modelo de clases, se define la estructura física de los datos correspondiente a ese modelo, en la actividad Diseño Físico de Datos. Además, en los casos en que sea necesaria una migración de datos de otros sistemas o una carga inicial de información, se realizará su especificación a partir del modelo de clases y las estructuras de datos de los sistemas origen. Como resultado de Ing. María Florencia Pollo Cattaneo Pág. 207

208 todo lo anterior se actualiza el modelo de clases del análisis, una vez recogidas las decisiones de diseño IDENTIFICACIÓN DE ATRIBUTOS DE LAS CLASES El objetivo de esta tarea es identificar y describir, una vez que se ha especificado el entorno de desarrollo, los atributos de las clases. Para identificar los atributos se revisa el modelo de clases obtenido en el proceso de Análisis del Sistema de Información (ASI), considerando que, a partir de uno de ellos, puede ser necesario definir atributos adicionales. Para cada atributo identificado se define su tipo, con formatos específicos, y si existieran, las restricciones asociadas a ese atributo. Asimismo, se analiza la posibilidad de convertir un atributo en clase, para aquellos casos en los que: El atributo se defina en varias clases de diseño. La complejidad del atributo aumente la dificultad para comprender la clase a la que pertenece ATRIBUTOS DE CLASES Antes de pasar a definir los atributos de las clases, se mostrará, en la tabla DSI 5, cómo se vinculan las clases de análisis y diseño. Clases de Análisis Interfaz Principal Usuario Interfaz Seleccionar Parámetros Interfaz Seleccionar Tipo de Archivo Clases de diseño PrincipalIU SelecParametrosIU SelecTipoArchivoIU Ing. María Florencia Pollo Cattaneo Pág. 208

209 Clases de Análisis Interfaz Seleccionar DN Interfaz Seleccionar Técnicas Asistente Aplicar DMP Asistente Aplicar RRP Asistente Aplicar RRNP Asistente Aplicar VC Asistente Aplicar Varias Técnicas Asistente Generar DN Parámetros Información Archivos Distribución Normal Resultado Agregación Clases de diseño SelecDNIU SelecTecAgregacionIU AplicarDMP AplicarRRP AplicarRRNP AplicarVC AplcarVariasTec GenerarDN Parámetros InfoArchivo DistribucionNormal ResultadoAgregacion Tabla DSI 5: Comparación entre clases de Análisis y Diseño A continuación, en la tabla DSI 6, se completa la información de los atributos de las clases identificados en la fase de análisis: Clase Atributos Tipo PrincipalIU CodigoPpalIU DescripcionUso Int String SelecParametrosIU CodigoSelecParametros CodigoParametros Parámetros Int Int Float() SelecTipoArchivoIU CodigoSelecTipoA_IU TipoArchivo TipoArchivoDefecto Int Byte Bye Ing. María Florencia Pollo Cattaneo Pág. 209

210 Clase Atributos Tipo SelecDNIU CodigoSelecDN CodigoDN NombreArchivo NombreArchivoDefecto DirecciónDN DirecciónDNDefecto Int Int String String String String SelecTecAgregacionIU CodigoSelecTecA_IU TécnicaAgregacion TécnicaAgregacionDefecto Int Byte Byte AplicarDMP CódigoDMP. CodigoParametros CodigoDN TipoArchivo NombreResultadoDMP NombreResultadoDMPDefecto DirecciónDMP DirecciónDMPDefecto Int Int Int Byte String String String String AplicarRRP CodigoRRP. CodigoParametros CodigoDN TipoArchivo NombreResultadoRRP NombreResultadoRRPDefecto DirecciónRRP DirecciónRRPDefecto Int Int Int Byte String String String String AplicarRRNP CodigoRRNP. CodigoParametros CodigoDN TipoArchivo Int Int Int Byte Ing. María Florencia Pollo Cattaneo Pág. 210

211 Clase Atributos Tipo NombreResultadoRRNP NombreResultadoRRNPDefecto DirecciónRRNP DirecciónRRNPDefecto String String String String AplicarVC CodigoVC. CodigoParametros CodigoDN TipoArchivo NombreResultadoVC NombreResultadoVCDefecto DirecciónVC DirecciónVCDefecto Int Int Int Byte String String String String AplcarVariasTec CodigoVarTec. TecnicasAplicadas CodigoParametros CodigoDN TipoArchivo NombreResultadoVarTec NombreResultadoVarTecDefecto DirecciónVarTec DirecciónVarTecDefecto Int Boolean() Int Int Byte String String String String GenerarDN CodigoDN. CodigoParametros NombreDN NombreDNDefecto DirecciónDN DirecciónDNDefecto Int Int String String String String Parámetros CodigoParametros MediaTratamientoExperimental Int Float Ing. María Florencia Pollo Cattaneo Pág. 211

212 Clase Atributos Tipo MediaTratamientoControl DesvíoEstándarTrataControl DesvíoEstándarTrataExpe CantidadMenorSujetos CantidadMayorSujetos CantidadMínimaExperimentos CantidadMáximaExperimentos CantidadSimulaciones Float Float Float Int Int Int Int Int InfoArchivo CodigoInfoArchivo NombreArchivo DirecciónArchivo TipoArchivo Int String String Byte DistribucionNormal CodigoDN. CodigoParametros NombreDN DirecciónDN ValoresDN Int Int String String Float() ResultadoAgregacion CodigoResultado TecnicasAplicadas CodigoDN CodigoParametros NombreArchivo DMP90LimInfEI DMP90LimSupEI DMP95LimInfEI DMP95LimSupEI DMP99LimInfEI DMP99LimSupEI RRP90LimInfEI Int Boolean() Int Int String Float Float Float Float Float Float Float Ing. María Florencia Pollo Cattaneo Pág. 212

213 Clase Atributos Tipo RRP90LimSupEI RRP95LimInfEI RRP95LimSupEI RRP99LimInfEI RRP99LimSupEI RRNP90LimInfEI RRNP90LimSupEI RRNP95LimInfEI RRNP95LimSupEI RRNP99LimInfEI RRNP99LimSupEI DMP90LimInfEG DMP90LimSupEG DMP95LimInfEG DMP95LimSupEG DMP99LimInfEG DMP99LimSupEG RRP90LimInfEG RRP90LimSupEG RRP95LimInfEG RRP95LimSupEG RRP99LimInfEG RRP99LimSupEG RRNP90LimInfEG RRNP90LimSupEG RRNP95LimInfEG RRNP95LimSupEG RRNP99LimInfEG RRNP99LimSupEG Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Float Ing. María Florencia Pollo Cattaneo Pág. 213

214 Clase Atributos Tipo VC90LimInfEG VC90LimSupEG VC95LimInfEG VC95LimSupEG VC99LimInfEG VC99LimSupEG Float Float Float Float Float Float Tabla DSI 6: Atributos de la clase En necesario establecer el conjunto de restricciones que se les deben dar a los parámetros que establecerán las características de los experimentos simulados. Para ello, se define la tabla DSI 7, que plasma estas restricciones en la forma de mínimo y máximo: Atributo Tipo Valor Mínimo Valor Máximo MediaTratamientoExperimental Float Límite del tipo Límite del tipo MediaTratamientoControl Float Límite del tipo Límite del tipo DesvíoEstándarTrataControl Float DesvíoEstándarTrataExpe Float CantidadMenorSujetos Int 4 8 CantidadMayorSujetos Int 6 10 CantidadMínimaExperimentos Int 2 8 CantidadMáximaExperimentos Int 4 20 CantidadSimulaciones Int Tabla DSI 7: Restricciones en los valores de los parámetros IDENTIFICACIÓN DE OPERACIONES DE LAS CLASES El objetivo de esta tarea es definir, de forma detallada, las operaciones de cada clase de diseño. Para ello, se toma como punto de partida el modelo de clases generado Ing. María Florencia Pollo Cattaneo Pág. 214

215 en el análisis, así como el diseño de los casos de uso reales y los requisitos de diseño que pueden aparecer al definir el entorno de desarrollo. Las operaciones de las clases de diseño surgen para dar respuesta a las responsabilidades de las clases de análisis y, además, para definir las interfaces que ofrece esa clase. Según el entorno de desarrollo utilizado, se describe cada operación especificando: su nombre, parámetros y visibilidad (pública, privada, protegida). Si el entorno de desarrollo lo permite, se tiene en cuenta la posibilidad de simplificar el modelo de clases haciendo uso del polimorfismo y la sobrecarga de operaciones. Para identificar las operaciones de aquellos objetos que presenten distintos estados, por lo que su comportamiento depende del estado en el que se encuentren, es recomendable realizar un diagrama de transición de estados, y traducir cada acción o actividad del mismo en una de estas operaciones OPERACIONES DE CLASES En el presente trabajo, no se encuentran objetos cuyo comportamiento cambie en función de su estado, por lo tanto, no se desarrollarán diagrama de transición de estados. Para comenzar con el análisis de los métodos, hay que tener en cuenta la siguiente distinción: Métodos Triviales: Existen ciertos métodos utilizados para leer o escribir los valores de los atributos de un objeto (conocidos con getters y setters), que dependiendo del lenguaje en que se implemente, pueden ser implementados automáticamente por el lenguaje. Por tal motivo, estos métodos no se documentarán para facilitar el entendimiento del modelo. Ing. María Florencia Pollo Cattaneo Pág. 215

216 Métodos no triviales: Son aquellos métodos que agregan valor al sistema, es decir, modelan reglas de negocio y comportamiento de las clases del sistema. Estos métodos si serán diseñados y explicados en las tablas DSI 7 a DSI 12: 1) AplicarDMP: Método Tipo Descripción selecparametros Público Selecciona el conjunto de parámetros que establecerán las características de los experimentos simulados. Parámetros Resultado MediaTratamientoExperimental MediaTratamientoControl DesvíoEstándarTrataControl DesvíoEstándarTrataExpe CantidadMenorSujetos CantidadMayorSujetos CantidadMínimaExperimentos CantidadMáximaExperimentos CantidadSimulaciones selectipoarchivo Público El usuario establece el tipo de archivo en que quiere que se grave el reporte Parámetros Resultado TipoArchivo selecdn Público El usuario selecciona el archivo que contiene la distribución normal que servirá de base para la aplicación de la técnica Parámetros Ing. María Florencia Pollo Cattaneo Pág. 216

217 Método Tipo Descripción Resultado NombreDN DirecciónDN asignarnombre Público Asigna un nombre al archivo y la dirección de almacenamiento Parámetros Resultado NombreArchivo DireccionArchivo generarresultado Público Aplica la técnica DMP a la DN seleccionada teniendo en cuenta el conjunto de parámetros y genera un reporte de resultado Parámetros TipoArchivo NombreDN DirecciónDN NombreArchivo DireccionArchivo Ing. María Florencia Pollo Cattaneo Pág. 217

218 Método Tipo Descripción Resultado CodigoResultado TecnicasAplicadas CodigoDN CodigoParametros NombreArchivo DMP90LimInfEI DMP90LimSupEI DMP95LimInfEI DMP95LimSupEI DMP99LimInfEI DMP99LimSupEI DMP90LimInfEG DMP90LimSupEG DMP95LimInfEG DMP95LimSupEG DMP99LimInfEG DMP99LimSupEG Tabla DSI 7: Descripción de los métodos de la clase AplicarDMP 2) AplicarRRP: Método Tipo Descripción selecparametros Público Selecciona el conjunto de parámetros que establecerán las características de los experimentos simulados. Parámetros Ing. María Florencia Pollo Cattaneo Pág. 218

219 Método Tipo Descripción Resultado MediaTratamientoExperimental MediaTratamientoControl DesvíoEstándarTrataControl DesvíoEstándarTrataExpe CantidadMenorSujetos CantidadMayorSujetos CantidadMínimaExperimentos CantidadMáximaExperimentos CantidadSimulaciones selectipoarchivo Público El usuario establece el tipo de archivo en que quiere que se grabe el reporte Parámetros Resultado TipoArchivo selecdn Público El usuario selecciona el archivo que contiene la distribución normal que servirá de base para la aplicación de la técnica Parámetros Resultado NombreDN DirecciónDN asignarnombre Público Asigna un nombre al archivo y la dirección de almacenamiento Parámetros Resultado NombreArchivo DireccionArchivo generarresultado Público Aplica la técnica RRP a la DN seleccionada teniendo en cuenta el conjunto de parámetros y genera un reporte de resultado Ing. María Florencia Pollo Cattaneo Pág. 219

220 Método Tipo Descripción Parámetros TipoArchivo NombreDN DirecciónDN NombreArchivo DireccionArchivo Resultado CodigoResultado TecnicasAplicadas CodigoDN CodigoParametros NombreArchivo RRP90LimInfEI RRP90LimSupEI RRP95LimInfEI RRP95LimSupEI RRP99LimInfEI RRP99LimSupEI RRP90LimInfEG RRP90LimSupEG RRP95LimInfEG RRP95LimSupEG RRP99LimInfEG RRP99LimSupEG Tabla DSI 8: Descripción de los métodos de la clase AplicarRRP Ing. María Florencia Pollo Cattaneo Pág. 220

221 3) AplicarRRNP: Método Tipo Descripción selecparametros Público Selecciona el conjunto de parámetros que establecerán las características de los experimentos simulados. Parámetros Resultado MediaTratamientoExperimental MediaTratamientoControl DesvíoEstándarTrataControl DesvíoEstándarTrataExpe CantidadMenorSujetos CantidadMayorSujetos CantidadMínimaExperimentos CantidadMáximaExperimentos CantidadSimulaciones selectipoarchivo Público El usuario establece el tipo de archivo en que quiere que se grabe el reporte Parámetros Resultado TipoArchivo selecdn Público El usuario selecciona el archivo que contiene la distribución normal que servirá de base para la aplicación de la técnica Parámetros Resultado NombreDN DirecciónDN asignarnombre Público Asigna un nombre al archivo y la dirección de almacenamiento Parámetros Ing. María Florencia Pollo Cattaneo Pág. 221

222 Método Tipo Descripción Resultado NombreArchivo DireccionArchivo generarresultado Público Aplica la técnica RRNP a la DN seleccionada teniendo en cuenta el conjunto de parámetros y genera un reporte de resultado Parámetros TipoArchivo NombreDN DirecciónDN NombreArchivo DireccionArchivo Resultado CodigoResultado TecnicasAplicadas CodigoDN CodigoParametros NombreArchivo RRNP90LimInfEI RRNP90LimSupEI RRNP95LimInfEI RRNP95LimSupEI RRNP99LimInfEI RRNP99LimSupEI RRNP90LimInfEG RRNP90LimSupEG RRNP95LimInfEG RRNP95LimSupEG RRNP99LimInfEG RRNP99LimSupEG Tabla DSI 9: Descripción de los métodos de la clase AplicarRRNP Ing. María Florencia Pollo Cattaneo Pág. 222

223 4) AplicarVC: Método Tipo Descripción selecparametros Público Selecciona el conjunto de parámetros que establecerán las características de los experimentos simulados. Parámetros Resultado MediaTratamientoExperimental MediaTratamientoControl DesvíoEstándarTrataControl DesvíoEstándarTrataExpe CantidadMenorSujetos CantidadMayorSujetos CantidadMínimaExperimentos CantidadMáximaExperimentos CantidadSimulaciones selectipoarchivo Público El usuario establece el tipo de archivo en que quiere que se grabe el reporte Parámetros Resultado TipoArchivo selecdn Público El usuario selecciona el archivo que contiene la distribución normal que servirá de base para la aplicación de la técnica Parámetros Resultado NombreDN DirecciónDN asignarnombre Público Asigna un nombre al archivo y la dirección de almacenamiento Parámetros Ing. María Florencia Pollo Cattaneo Pág. 223

224 Método Tipo Descripción Resultado NombreArchivo DireccionArchivo generarresultado Público Aplica la técnica VC a la DN seleccionada teniendo en cuenta el conjunto de parámetros y genera un reporte de resultado Parámetros TipoArchivo NombreDN DirecciónDN NombreArchivo DireccionArchivo Resultado CodigoResultado TecnicasAplicadas CodigoDN CodigoParametros NombreArchivo VC90LimInfEI VC90LimSupEI VC95LimInfEI VC95LimSupEI VC99LimInfEI VC99LimSupEI VC90LimInfEG VC90LimSupEG VC95LimInfEG VC95LimSupEG VC99LimInfEG VC99LimSupEG Tabla DSI 10: Descripción de los métodos de la clase AplicarVC Ing. María Florencia Pollo Cattaneo Pág. 224

225 5) AplicarVariasTec: Método Tipo Descripción selectecnicas Público El usuario selecciona la combinación de técnicas de agregación que se va a aplicar a la DN escogida con el método selecdn Parámetros Resultado TecnicasAplicadas selecparametros Público Selecciona el conjunto de parámetros que establecerán las características de los experimentos simulados. Parámetros Resultado MediaTratamientoExperimental MediaTratamientoControl DesvíoEstándarTrataControl DesvíoEstándarTrataExpe CantidadMenorSujetos CantidadMayorSujetos CantidadMínimaExperimentos CantidadMáximaExperimentos CantidadSimulaciones selectipoarchivo Público El usuario establece el tipo de archivo en que quiere que se grabe el reporte Parámetros Resultado TipoArchivo selecdn Público El usuario selecciona el archivo que contiene la distribución normal que servirá de base para la aplicación de la técnica Ing. María Florencia Pollo Cattaneo Pág. 225

226 Método Tipo Descripción Parámetros Resultado NombreDN DirecciónDN asignarnombre Público Asigna un nombre al archivo y la dirección de almacenamiento Parámetros Resultado NombreArchivo DireccionArchivo generarresultado Público Aplica varias técnicas de agregación (las seleccionadas con el método selectecnicas) a la DN seleccionada teniendo en cuenta el conjunto de parámetros y genera un reporte de resultado Parámetros TipoArchivo TecnicasAplicadas NombreDN DirecciónDN NombreArchivo DireccionArchivo Ing. María Florencia Pollo Cattaneo Pág. 226

227 Método Tipo Descripción Resultado CodigoResultado TecnicasAplicadas CodigoDN CodigoParametros NombreArchivo DMP90LimInfEI, DMP90LimSupEI DMP95LimInfEI, DMP95LimSupEI DMP99LimInfEI, DMP99LimSupEI MP90LimInfEG, DMP90LimSupEG DMP95LimInfEG, MP95LimSupEG DMP99LimInfEG,DMP99LimSupEG RRP90LimInfEI, RRP90LimSupEI RRP95LimInfEI, RRP95LimSupEI RRP99LimInfEI, RRP99LimSupEI RRP90LimInfEG, RRP90LimSupEG RRP95LimInfEG, RRP95LimSupEG RRP99LimInfEG, RRP99LimSupEG RRNP90LimInfEI,RRNP90LimSupEI RRNP95LimInfEI,RRNP95LimSupEI RRNP99LimInfEI,RRNP99LimSupEI RRNP90LimInfEG,RRNP90LimSupEG RRNP95LimInfEG,RRNP95LimSupEG RRNP99LimInfEG,RRNP99LimSupEG VC90LimInfEI,VC90LimSupEI VC95LimInfEI,VC95LimSupEI VC99LimInfEI,VC99LimSupEI VC90LimInfEG,VC90LimSupEG VC95LimInfEG,VC95LimSupEG VC99LimInfEG,VC99LimSupEG Tabla DSI 11: Descripción de los métodos de la clase AplicarVariasTec Ing. María Florencia Pollo Cattaneo Pág. 227

228 6) rardn: Método Tipo Descripción selecparametros Público Selecciona el conjunto de parámetros que establecerán las características de los experimentos simulados. Parámetros Resultado MediaTratamientoExperimental MediaTratamientoControl DesvíoEstándarTrataControl DesvíoEstándarTrataExpe CantidadMenorSujetos CantidadMayorSujetos CantidadMínimaExperimentos CantidadMáximaExperimentos CantidadSimulaciones asignarnombre Público Asigna un nombre al archivo y la dirección de almacenamiento Parámetros Resultado NombreArchivo DireccionArchivo generarnumdn Público Con este método se genera un conjunto de números aleatorios con distribución de probabilidad normal en base a los parámetros pasados, y que simulan el conjunto de resultado de experimentos que se van a agregar Ing. María Florencia Pollo Cattaneo Pág. 228

229 Método Tipo Descripción Parámetros NombreArchivo DireccionArchivo MediaTratamientoExperimental MediaTratamientoControl DesvíoEstándarTrataControl DesvíoEstándarTrataExpe CantidadMenorSujetos CantidadMayorSujetos CantidadMínimaExperimentos CantidadMáximaExperimentos CantidadSimulaciones Resultado CódigoDN. CodigoParametros NombreDN DirecciónDN ValoresDN Tabla DSI 12: Descripción de los métodos de la clase GenerarDN DIAGRAMA DE CLASES DE DISEÑO Antes de desarrollar el diagrama de clases de diseño, es necesario mencionar el tema de paquetes. Los paquetes son una forma de agrupar clases. Si bien físicamente no tienen por qué conservar paralelismo alguno con cuestiones físicas de librería, sirven para agrupar clases en base a criterios de cohesión o acoplamiento conceptual. Para el presente proyecto, y dado que este es el diseño detallado, se divide el sistema en tres paquetes principales, los cuales se describen en la tabla DSI 13: Ing. María Florencia Pollo Cattaneo Pág. 229

230 Paquete Descripción Clases de Dominio Estas clases dominan fuertemente el dominio del negocio. Cada clase se corresponde con un concepto del negocio que es necesario modelar. Las relaciones entre estas clases, modelan las relaciones, restricciones y reglas del negocio. Clases de Proceso Estas clases modelan procesos dentro del dominio. Por lo general, estos procesos son de una importancia o complejidad tal que vale la pena su diseño e implementación fuera de las clases de dominio Clases de Interfaz Gráfica de Usuario Estas clases modelan la interfaz gráfica de usuario. Este tipo de clases están altamente ligadas con las características del lenguaje de implementación del sistema. Tabla DSI 13: Paquetes principales del sistema A continuación, en la figura DSI 13, se detalla en nomenclatura UML la relación de los paquetes descriptos en la tabla DSI 13: Figura DSI 13: Relación entre paquetes del sistema Ing. María Florencia Pollo Cattaneo Pág. 230

231 A continuación; en las figuras DSI 14, DSI 15 y DSI 16; se describen los diagramas de clases correspondientes a cada uno de los paquetes: 1) Diagrama de clases para las clases de dominio (debido a la gran cantidad de atributos que tienen estas clases, sobre todo la clase ResultadoAgregacion, es que aquí omitimos su representación, complementando, entonces, al gráfico, la tabla DSI 6): Figura DSI 14: Diagrama de clases del paquete de dominio Ing. María Florencia Pollo Cattaneo Pág. 231

232 2) Diagrama de clases para las clases de proceso: Figura DSI 15: Diagrama de clases del paquete de proceso 3) Clases de interfaz. Las clases de interfaz de usuario, por un tema de unificación de criterios de modelado, serán representadas como clases, pero no recibirán una implementación directamente como clases, sino que, serán implementadas a través de formularios de Visual Basic.NET: Figura DSI 16: Diagrama de clases del paquete de Interfaz de Usuario Ing. María Florencia Pollo Cattaneo Pág. 232

233 ESPECIFICACIÓN DE NECESIDADES DE MIGRACIÓN Y CARGA INICIAL DE DATOS En esta tarea se realiza una primera especificación de las necesidades de migración o carga inicial de los datos requeridos por el sistema, que se completa en la actividad Diseño de la Migración y Carga Inicial de Datos CARGA INICIAL DE DATOS Al no contar con una base de datos en esta primera versión, no hace falta cargar datos, por lo que no es necesario la carga inicial ni la migración de los mismos para el funcionamiento del sistema DISEÑO FÍSICO DE DATOS En esta actividad se define la estructura física de datos que utilizará el sistema, a partir del modelo lógico de datos normalizado o modelo de clases, de manera que teniendo presentes las características específicas del sistema de gestión de datos concretos a utilizar, los requisitos establecidos para el sistema de información, y las particularidades del entorno tecnológico, se consiga una mayor eficiencia en el tratamiento de los datos. También se analizan los caminos de acceso a los datos utilizados por cada módulo/clase del sistema en consultas y actualizaciones, con el fin de mejorar los tiempos de respuesta y optimizar los recursos de máquina. Las tareas de esta actividad se realizan de forma iterativa y en paralelo con las realizadas en las actividades Definición de la Arquitectura del Sistema, dónde se especifican los detalles de arquitectura e infraestructura y la planificación de capacidades, Diseño de la Arquitectura de Soporte, dónde se determinan y diseñan los servicios comunes que pueden estar relacionados con la gestión de datos (acceso a bases de datos, ficheros, áreas temporales, sincronización de bases de datos, etc.), Diseño de Ing. María Florencia Pollo Cattaneo Pág. 233

234 Casos de Uso Reales y de Clases, para desarrollo orientado a objetos, y Diseño de la Arquitectura de Módulos del Sistema, para desarrollo estructurado, dónde se especifica la lógica de tratamiento y las interfaces utilizadas. En el caso de diseño orientado a objetos, esta actividad también es necesaria. La obtención del modelo físico de datos se realiza aplicando una serie de reglas de transformación a cada elemento del modelo de clases que se está generando en la actividad Diseño de Clases. Asimismo, en esta actividad hay que considerar los estándares y normas establecidos para el diseño aplicando, cuando proceda, los mecanismos genéricos de diseño identificados en la tarea Identificación de Mecanismos Genéricos de Diseño DISEÑO DEL MODELO FÍSICO DE DATOS El objetivo de esta tarea es realizar el diseño del modelo físico de datos a partir del modelo lógico de datos normalizado o del modelo de clases, en el caso de diseño orientado a objetos. Como ya establecimos y reiteramos repetidas veces, este primer prototipo no cuenta con Base de Datos, por lo que simplemente, en este punto, estableceremos el tipo de archivo básico que manejará el sistema. En principio, los archivos serán todos de texto con la información separada por punto y coma y saltos de línea. También estará la posibilidad de crear un reporte con los resultados de la agregación en una plantilla de cálculo de Microsoft Excel. Estos reportes tendrán el formato establecido en la tabla IP 23 (Modelo de la tabla para evaluación de resultados). Ing. María Florencia Pollo Cattaneo Pág. 234

235 5.6.- VERIFICACIÓN Y ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA El objetivo de esta actividad es garantizar la calidad de las especificaciones del diseño del sistema de información y la viabilidad del mismo, como paso previo a la generación de las especificaciones de construcción. Para cumplir dicho objetivo, se llevan a cabo las siguientes acciones: Verificación de la calidad técnica de cada modelo o especificación Aseguramiento de la coherencia entre los distintos modelos VERIFICACIÓN DE LA ESPECIFICACIÓN DE DISEÑO El objetivo de esta tarea es asegurar la calidad formal de los distintos modelos, conforme a la técnica seguida para la elaboración de cada producto y a las normas y estándares especificados en el catálogo de normas RESULTADO DE LA VERIFICACIÓN DE LA ESPECIFICACIÓN DE DISEÑO Se han verificado los distintos modelos generados juntamente con el Director de Tesis y se han aplicado las modificaciones correspondientes. Ing. María Florencia Pollo Cattaneo Pág. 235

236 ANÁLISIS DE CONSISTENCIA DE LAS ESPECIFICACIONES DE DISEÑO El objetivo de esta tarea es asegurar que las especificaciones del diseño sean coherentes entre sí, comprobando la falta de ambigüedades o duplicación de información. Esta consistencia se asegura entre especificaciones de diseño, y con respecto a los modelos del análisis. Las diferentes comprobaciones se fundamentan generalmente en técnicas matriciales o de revisión entre los elementos comunes de los distintos modelos. El análisis de consistencia relativo a la arquitectura del sistema es común para desarrollo estructurado y orientado a objetos, aunque respecto a los productos del diseño detallado es específico para cada uno de los enfoques CONSISTENCIA DE LAS ESPECIFICACIONES DE DISEÑO Se comprueba la coherencia entre los distintos modelos de acuerdo a las trazabilidades que se presentan en la figura DSI 17. Figura DSI 17: Diagrama de entidad relación del proyecto Ing. María Florencia Pollo Cattaneo Pág. 236

237 Clases Asociadas a los Casos de Uso vs Clases de Interfaz de Usuario / Clases de Proceso / Clases de Dominio La Matriz de la tabla DSI 14 muestra dos columnas, a la izquierda, se describen las clases del paquetes de Clases de Interfaz de Usuario / Clases de Proceso / Clases de Dominio y, en la columna de la derecha, las clases asociadas a los Casos de Uso. Como se puede observar, existe una relación uno a uno entre ambas clases. Clases asociadas a los paquetes de clases de Interfaz de Usuario / Clases de Procesos / Clases de Dominios PrincipalIU SelecParametrosIU SelecTipoArchivoIU SelecDNIU SelecTecAgregacionIU AplicarDMP AplicarRRP AplicarRRNP AplicarVC AplcarVariasTec GenerarDN Parámetros InfoArchivo DistribucionNormal ResultadoAgregacion Clases asociadas a los casos de uso PrincipalIU SelecParametrosIU SelecTipoArchivoIU SelecDNIU SelecTecAgregacionIU AplicarDMP AplicarRRP AplicarRRNP AplicarVC AplcarVariasTec GenerarDN Parámetros InfoArchivo DistribucionNormal ResultadoAgregacion Tabla DSI 14, Trazabilidades entre Clases Asociadas a los Casos de Uso versus Clases de Interfaz de Usuario / Clases de Proceso / Clases de Dominio Ing. María Florencia Pollo Cattaneo Pág. 237

238 Clases de Interfaz de Usuario vs Pantalla de la fase de análisis La Matriz de la tabla DSI 15 muestra dos columnas, a la izquierda, se describen las clases del paquetes de Clases de Interfaz de Usuario y, en la columna de la derecha, las pantallas de la fase de análisis. Como se puede observar, existe una relación uno a uno entre ambos componentes: Clases de Interfaz de Usuario PrincipalIU SelecParametrosIU SelecTipoArchivoIU SelecDNIU SelecTecAgregacionIU Pantallas de la fase de análisis Pantalla Principal Seleccionar Parámetros Seleccionar Tipo de Archivo Seleccionar DN Seleccionar Técnica Agregación Tabla DSI 15, Trazabilidades entre las Clases de Interfaz de Usuario y las pantallas de la fase de análisis ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA El objetivo de esta tarea es obtener la aceptación, por parte de las áreas de explotación y sistemas, de la arquitectura del sistema de información y de los requisitos de operación y seguridad, con el fin de poder valorar su impacto en la instalación. En una reunión mantenida entre la tesista y el Director del proyecto se dio por aprobada la fase de Análisis del Sistema de Información GENERACIÓN DE ESPECIFICACIONES DE CONSTRUCCIÓN En esta actividad se generan las especificaciones para la construcción del sistema de información, a partir del diseño detallado. Ing. María Florencia Pollo Cattaneo Pág. 238

239 Estas especificaciones definen la construcción del sistema de información a partir de las unidades básicas de construcción (en adelante, componentes), entendiendo como tales unidades independientes y coherentes de construcción y ejecución, que se corresponden con un empaquetamiento físico de los elementos del diseño de detalle, como pueden ser: módulos, clases o especificaciones de interfaz. La división del sistema de información en subsistemas de diseño proporciona, por continuidad, una primera división en subsistemas de construcción, definiendo para cada uno de ellos los componentes que lo integran. Si se considera necesario, un subsistema de diseño se podrá dividir, a su vez, en sucesivos niveles para mayor claridad de las especificaciones de construcción. Las dependencias entre subsistemas de diseño proporcionan información para establecer las dependencias entre los subsistemas de construcción y, por lo tanto, definir el orden o secuencia que se debe seguir en la construcción y en la realización de las pruebas. Además, se generan las especificaciones necesarias para la creación de las estructuras de datos en los gestores de bases de datos o sistemas de ficheros. El producto resultante de esta actividad es el conjunto de las especificaciones de construcción del sistema de información, que comprende: Especificación del entorno de construcción. Descripción de subsistemas de construcción y dependencias. Descripción de componentes. Plan de integración del sistema de información. Ing. María Florencia Pollo Cattaneo Pág. 239

240 Especificación detallada de componentes. Especificación de la estructura física de datos ESPECIFICACIÓN DEL ENTORNO DE CONSTRUCCIÓN El objetivo de esta tarea es la definición detallada y completa del entorno necesario para la construcción de los componentes del sistema de información. conceptos: Se propone que la especificación del entorno se realice según los siguientes Entorno tecnológico: hardware, software y comunicaciones. Herramientas de construcción, generadores de código, compiladores, etc. Restricciones técnicas del entorno. Planificación de capacidades previstas, o la información que estime oportuna el departamento de sistemas para efectuar dicha planificación. Requisitos de operación y seguridad del entorno de construcción. tecnológico: A continuación, en la tabla DSI 16, se describen las especificaciones del entorno Ing. María Florencia Pollo Cattaneo Pág. 240

241 Concepto Entorno tecnológico: Hardware, software y comunicaciones Definición El equipo de desarrollo será un PC AMD Athlon 64 bits (2.0 GHZ), con 1.5 GB de memoria RAM y un disco rígido de 250GB. El sistema operativo es Windows XP Professional. Herramientas de construcción, generadores de código, compiladores, etc. Restricciones técnicas del entorno Planificación de capacidades previstas, o la información que estime oportuna el departamento de sistemas para efectuar dicha planificación Requisitos de operación y seguridad del entorno de construcción Visual Basic.NET No se observan No se observan No se observan Tabla DSI 16, Especificaciones del entorno tecnológico DEFINICIÓN DE COMPONENTES Y SUBSISTEMAS DE CONSTRUCCIÓN La especificación de los subsistemas de construcción se realiza a partir de los subsistemas de diseño, con una continuidad directa, permitiéndose a su vez un mayor nivel de detalle agrupando componentes en subsistemas dentro de un subsistema de construcción. Los componentes se definen mediante la agrupación de elementos del diseño de detalle de cada subsistema de diseño. En principio, cada módulo o clase y cada formato individual de interfaz se corresponden con un componente, aunque se pueden agrupar o redistribuir módulos o clases en componentes, siguiendo otros criterios más oportunos, como pueden ser: Ing. María Florencia Pollo Cattaneo Pág. 241

242 Optimización de recursos. Características comunes de funcionalidad o de acceso a datos. Necesidades especiales de ejecución: elementos críticos, accesos costosos a datos, etc. Los subsistemas de construcción y las dependencias entre subsistemas y entre componentes de un subsistema recogen aspectos prácticos relativos a la plataforma concreta de construcción y ejecución. Entre estos aspectos se pueden citar, por ejemplo: Secuencia de compilación entre componentes. Agrupación de elementos en librerías o packages (por ejemplo, DLL en el entorno Windows, packages en Java). La asignación de subsistemas de construcción a nodos, por continuidad con el diseño, determina la distribución de los componentes que lo integran. Opcionalmente, se propone la realización de un plan de integración del sistema de información, especificando la secuencia y organización de la construcción y prueba de los subsistemas de construcción y de los componentes, desde un punto de vista técnico COMPONENTES Y SUBSISTEMAS DE CONSTRUCCIÓN Para el presente trabajo, se ha decidido dejar las clases tal y como se han diseñado. De esta forma cada clase que compone el diseño se encontrará representada por una clase en el dominio de la implementación y viceversa. A continuación, en la figura DSI 18, se muestra el pertinente diagrama UML: Ing. María Florencia Pollo Cattaneo Pág. 242

243 Figura DSI 18: Relación entre los dominios de diseño y implementación ESPECIFICACIÓN TÉCNICA DEL PLAN DE PRUEBAS En esta actividad se realiza la especificación de detalle del plan de pruebas del sistema de información para cada uno de los niveles de prueba establecidos en el proceso Análisis del Sistema de Información: Pruebas unitarias. Pruebas de integración. Pruebas del sistema. Pruebas de implantación. Pruebas de aceptación. Para ello se toma como referencia el plan de pruebas, que recoge los objetivos de la prueba de un sistema, se establece y coordina una estrategia de trabajo, y se provee del marco adecuado para planificar paso a paso las actividades de prueba. También puede ser una referencia el plan de integración del sistema de información propuesto, opcionalmente, en la tarea Definición de Componentes y Subsistemas de Construcción. Ing. María Florencia Pollo Cattaneo Pág. 243

244 El catálogo de requisitos, el catálogo de excepciones y el diseño detallado del sistema de información, permiten la definición de las verificaciones que deben realizarse en cada nivel de prueba para comprobar que el sistema responde a los requisitos planteados. La asociación de las distintas verificaciones a componentes, grupos de componentes y subsistemas, o al sistema de información completo, determina las distintas verificaciones de cada nivel de prueba establecido. Las pruebas unitarias comprenden las verificaciones asociadas a cada componente del sistema de información. Su realización tiene como objetivo verificar la funcionalidad y estructura de cada componente individual. Las pruebas de integración comprenden verificaciones asociadas a grupos de componentes, generalmente reflejados en la definición de subsistemas de construcción o en el plan de integración del sistema de información. Tienen por objetivo verificar el correcto ensamblaje entre los distintos componentes. Las pruebas del sistema, de implantación y de aceptación corresponden a verificaciones asociadas al sistema de información, y reflejan distintos propósitos en cada tipo de prueba: Las pruebas del sistema son pruebas de integración del sistema de información completo. Permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y técnicas se cumplen. Las pruebas de implantación incluyen las verificaciones necesarias para asegurar que el sistema funcionará correctamente en el entorno de operación al responder satisfactoriamente a los requisitos de rendimiento, seguridad y operación, y coexistencia con el resto de los sistemas de la instalación, y conseguir la aceptación del sistema por parte del usuario de operación. Ing. María Florencia Pollo Cattaneo Pág. 244

245 Las pruebas de aceptación van dirigidas a validar que el sistema cumple los requisitos de funcionamiento esperado, recogidos en el catálogo de requisitos y en los criterios de aceptación del sistema de información, y conseguir la aceptación final del sistema por parte del usuario. Las pruebas unitarias, de integración y del sistema se llevan a cabo en el proceso Construcción del Sistema de Información (CSI), mientras que las pruebas de implantación y aceptación se realizan en el proceso Implantación y Aceptación del Sistema (IAS). Como resultado de esta actividad se actualiza el plan de pruebas con la información siguiente: Especificación del entorno de pruebas. Especificación técnica de niveles de prueba. Planificación de las pruebas ESPECIFICACIÓN DEL ENTORNO DE PRUEBAS El objetivo de esta tarea es la definición detallada y completa del entorno necesario para la realización de las pruebas del sistema: unitarias, de integración, de implantación y de aceptación. Se propone considerar los siguientes conceptos en la especificación del entorno: Entorno tecnológico: hardware, software y comunicaciones. Restricciones técnicas del entorno. Ing. María Florencia Pollo Cattaneo Pág. 245

246 Requisitos de operación y seguridad del entorno de pruebas. Herramientas de prueba relacionadas con la extracción de juegos de ensayo, análisis de resultados, utilidades de gestión del entorno, etc. Planificación de capacidades previstas, o la información que estime oportuna el departamento técnico para efectuar dicha planificación. Procedimientos de promoción de elementos entre entornos (desarrollo, pruebas, explotación, etc.). Procedimientos de emergencia y de recuperación ENTORNO DE PRUEBAS Para la realizar los casos de pruebas, no se requerirá especificar nuevos elementos de equipamiento, tanto a nivel de hardware como de software, a los ya explicados en las fases anteriores. A continuación se describe cuál será el mecanismo de promoción de elementos entre entornos y procedimientos de emergencia y recuperación en caso de fallo: a) Procedimientos de promoción: El sistema, para sus pruebas, será instalado en un equipo donde se cuente con el programa winrar (permite generar archivos tipo rar). De esta forma, una probado y aprobado, se generarán archivos de estas características para cada directorio involucrado con el sistema y los mismo serán resguardados para su puesta en producción. b) Procedimientos de emergencia y de recuperación: Se define como emergencia en la que haga falta una recuperación del sistema, a aquel caso en el que el servidor se vea dañado físicamente y por ende provoque mal funcionamiento en la Ing. María Florencia Pollo Cattaneo Pág. 246

247 aplicación. Deberá ser necesario recuperar el sistema con el siguiente curso de acción: 1) Tomar los archivos de instalación del sistema. 2) Proceder a instalar el sistema nuevamente. 3) Iniciar el sistema REVISIÓN DE LA PLANIFICACIÓN DE PRUEBAS En esta tarea se completa y especifica la planificación de las pruebas, determinando los distintos perfiles implicados en la preparación y ejecución de las pruebas y en la evaluación de los resultados, así como el tiempo estimado para la realización de cada uno de los niveles de prueba, de acuerdo a la estrategia de integración establecida PLANIFICACIÓN DE PRUEBAS Teniendo en cuanta que el sistema ha sido desarrollado con un enfoque de casos de uso, se genera un plan de pruebas que apunte a probar funcionalmente el sistema desde el punto de vista de los casos de uso, componentes de infraestructura y pruebas globales del sistema. Los tipos de prueba a realizar son: Pruebas Unitarias: prueban componentes específicos del sistema. Pruebas de Integración: abarca las pruebas por casos de uso. Pruebas de Sistema: las pruebas serán ejecutadas y obtenidos sus resultados (utilizando al propio sistema como herramienta y probando el circuito total). Ing. María Florencia Pollo Cattaneo Pág. 247

248 PRUEBAS UNITARIAS El único componente a probar en forma independiente es el que genera la Distribución Normal. Las pruebas tienen como objetivo generar una distribución normal a partir de un conjunto de parámetros, Se realizarán pruebas para su correcta generación, y pruebas donde forzaremos el error a través de una selección errónea de parámetros y tipo. Para esta prueba independientemente se deberá construir un programa especial que permita comprobar el componente. El programa recibirá por línea de comando todos los parámetros, en el siguiente orden: media tratamiento experimental, median tratamiento de control, desvío estándar experimental, desvío estándar de control, cantidad de sujetos mínima por experimento, cantidad de sujetos máxima por experimento, cantidad mínima de experimentos, cantidad máxima de experimentos, cantidad de simulaciones y una cadena de caracteres que indicarán la ruta absoluta, nombre y tipo de guardado del archivo a generar. Como resultado el programa deberá generar un archivo de texto con un conjunto de números aleatorios de distribución gaussiana separados por punto y coma y saltos de línea, los cuales serán comprobados a través de una plantilla de cálculo para graficar el conjunto de números y comprobar si efectivamente siguen una distribución normal con las medias y desvíos estándar pasados como parámetros. El programa se llamará comprbardn. A continuación, en las tablas DSI 17 a DSI 22, se describen en detalle los casos de prueba a realizar: CP-001 Objetivo Entrada Salida Generar en forma exitosa un archivo de texto con un conjunto de números aleatorios de distribución de probabilidad normal separados con coma C:/Mis Documentos/dn.txt DN generada Ing. María Florencia Pollo Cattaneo Pág. 248

249 CP-001 Condiciones Procedimiento No posee 1) Ejecutar el entorno de comandos 2) Ejecutar la instrucción comprobardn C:/Mis Documentos/dn.txt 3) Se deberá observar en la pantalla del menú de comandos el mensaje DN generada, y si se verifica en la carpeta Mis Documentos, deberá encontrarse el archivo dn.txt, el cual debe comprobarse que tiene números con una distribución normal. Prerrequisitos No posee Tabla DSI 17: Caso de Pruebas CP-001 CP-002 Objetivo Entrada Salida Condiciones Procedimiento Intentar generar un archivo de distribución normal con parámetros erróneos , C:/Mis Documentos/dn.txt Error en los parámetros No posee 1) Ejecutar el entorno de comandos 2) Ejecutar la instrucción comprobardn C:/Mis Documentos/dn.txt 3) Se deberá observar en la pantalla del menú de comandos el mensaje Error en los parámetros, archivo no generado, y si se verifica en la carpeta Mis Documentos, NO deberá encontrarse el archivo dn.txt. Prerrequisitos No posee Tabla DSI 18: Caso de Pruebas CP-002 Ing. María Florencia Pollo Cattaneo Pág. 249

250 CP-003 Objetivo Entrada Salida Condiciones Procedimiento Intentar generar un archivo de distribución normal con parámetros faltantes C:/Mis Documentos/dn.txt Error en el número de parámetros No posee 1) Ejecutar el entorno de comandos 2) Ejecutar la instrucción comprobardn C:/Mis Documentos/dn.txt 3) Se deberá observar en la pantalla del menú de comandos el mensaje Error en el número de parámetros, archivo no generado, y si se verifica en la carpeta Mis Documentos, NO deberá encontrarse el archivo dn.txt. Prerrequisitos No posee Tabla DSI 19: Caso de Pruebas CP-003 CP-004 Objetivo Intentar generar un archivo de distribución normal con nombre de archivo faltante. Entrada Salida Condiciones Procedimiento Error en el número de parámetros No posee 1) Ejecutar el entorno de comandos 2) Ejecutar la instrucción comprobardn ) Se deberá observar en la pantalla del menú de comandos el mensaje Error en el número de parámetros, archivo no generado, y si se verifica en la carpeta Mis Documentos, NO deberá encontrarse el archivo dn.txt. Ing. María Florencia Pollo Cattaneo Pág. 250

251 CP-004 Prerrequisitos No posee Tabla DSI 20: Caso de Pruebas CP-004 CP-005 Objetivo Entrada Salida Condiciones Procedimiento Intentar generar un archivo de distribución normal con dirección de archivo errónea D:/Mis Documentos/dn.txt Error en la ruta de almacenamiento No posee 1) Ejecutar el entorno de comandos 2) Ejecutar la instrucción comprobardn D:/Mis Documentos/dn.txt 3) Se deberá observar en la pantalla del menú de comandos el mensaje Error en la ruta de almacenamiento, archivo no generado, y si se verifica en la carpeta Mis Documentos, NO deberá encontrarse el archivo dn.txt. Prerrequisitos No hay unidad D en el equipo. Tabla DSI 21: Caso de Pruebas CP-005 CP-006 Objetivo Entrada Salida Condiciones Intentar generar un archivo de distribución normal con tipo de archivo erróneo C:/Mis Documentos/dn.xls Error en el tipo de archivo No posee Ing. María Florencia Pollo Cattaneo Pág. 251

252 CP-006 Procedimiento 1) Ejecutar el entorno de comandos 2) Ejecutar la instrucción comprobardn C:/Mis Documentos/dn.xls 3) Se deberá observar en la pantalla del menú de comandos el mensaje Error en el tipo de archivo, archivo no generado, y si se verifica en la carpeta Mis Documentos, NO deberá encontrarse el archivo dn.txt. Prerrequisitos No hay unidad D en el equipo. Tabla DSI 22: Caso de Pruebas CP PRUEBAS DE INTEGRACIÓN Las pruebas de integración tienen como objetivo encontrar fallas en el funcionamiento de los componentes y subsistemas del sistema, al funcionar en conjunto para proveer la funcionalidad deseada. Dada la topología y funcionalidad del presente desarrollo se harán las pruebas necesarias dentro de las pruebas del sistema PRUEBAS DEL SISTEMA Las pruebas de integración tienen como objetivo probar cada uno de los casos de uso implementados en la aplicación. DSI 23. El ingreso de los casos de prueba se hace en el orden en que se detalla en la tabla Ing. María Florencia Pollo Cattaneo Pág. 252

253 Código Caso de Uso Objetivo CP-007 Aplicar Varias Técnicas Generar un archivo con los resultados de aplicar varias técnicas de agregación a una distribución normal, escogiendo el nombre y ruta de almacenamiento. CP-008 Aplicar Varias Técnicas Generar un archivo con los resultados de aplicar varias técnicas de agregación a una distribución normal, sin escoger el nombre ni ruta de almacenamiento. CP-009 Aplicar DMP Generar un archivo con los resultados de aplicar la técnica de agregación DMP a una distribución normal, escogiendo el nombre y ruta de almacenamiento. CP-010 Aplicar DMP Generar un archivo con los resultados de aplicar la técnica de agregación DMP a una distribución normal, sin escoger el nombre ni ruta de almacenamiento. CP-011 Aplicar RRP Generar un archivo con los resultados de aplicar la técnica de agregación RRP a una distribución normal, escogiendo el nombre y ruta de almacenamiento. Ing. María Florencia Pollo Cattaneo Pág. 253

254 Código Caso de Uso Objetivo CP-012 Aplicar RRP Generar un archivo con los resultados de aplicar la técnica de agregación RRP a una distribución normal, sin escoger el nombre ni ruta de almacenamiento. CP-013 Aplicar RRNP Generar un archivo con los resultados de aplicar la técnica de agregación RRNP a una distribución normal, escogiendo el nombre y ruta de almacenamiento. CP-014 Aplicar RRN Generar un archivo con los resultados de aplicar la técnica de agregación RRNP a una distribución normal, sin escoger el nombre ni ruta de almacenamiento. CP-015 Aplicar VC Generar un archivo con los resultados de aplicar la técnica de agregación VC a una distribución normal, escogiendo el nombre y ruta de almacenamiento. CP-016 Aplicar VC Generar un archivo con los resultados de aplicar la técnica de agregación VC a una distribución normal, sin escoger el nombre ni ruta de almacenamiento. Ing. María Florencia Pollo Cattaneo Pág. 254

255 Código Caso de Uso Objetivo CP-017 Seleccionar Técnicas Seleccionar una o varias de entre cuatro técnicas de agregación (DMP, RRP, RRNP y VC). CP-018 Seleccionar Técnicas No seleccionar ninguna técnica. CP-019 Seleccionar Parámetros Seleccionar correctamente el conjunto de parámetros que establecerán las características de la distribución normal. CP-020 Seleccionar Parámetros Seleccionar erróneamente el conjunto de parámetros que establecerán las características de la distribución normal. CP-021 Seleccionar Parámetros No seleccionar el conjunto de parámetros que establecerán las características de la distribución normal. CP-022 Seleccionar Tipo de Archivo Seleccionar el tipo o tipos de archivo a generar. CP-023 Seleccionar Tipo de Archivo Seleccionar los dos tipos de archivo, (uno de ellos es xls), y con una cantidad de simulaciones muy grande para la generación de este tipo de archivo (Excel). Ing. María Florencia Pollo Cattaneo Pág. 255

256 Código Caso de Uso Objetivo CP-024 Seleccionar Tipo de Archivo Seleccionar el tipo xls y con una cantidad de simulaciones muy grande para la generación de este tipo de archivo. CP-025 Seleccionar Tipo de Archivo No seleccionar el tipo o tipos de archivo a generar. CP-026 Seleccionar DN Seleccionar correctamente la DN a la cual aplicar la/s técnica/s de agregación. CP-027 Seleccionar DN Seleccionar erróneamente la DN a la cual aplicar la/s técnica/s de agregación. CP-028 Seleccionar DN No selecciona ninguna DN. Tabla DSI 23: Secuencia de ingreso de casos de Prueba A continuación se descripción de los casos de prueba asociados a los casos de uso, según el orden definido en la tabla DSI 23: 1) Casos de prueba asociados al caso de uso Aplicar Varias Técnicas (ver tablas DSI 24 y DSI 25) CP-007 Objetivo Entrada Salida Condiciones Generar un archivo con el resultado de aplicar varias técnicas de agregación a la distribución normal seleccionada. Tipo de Archivo, Distribución Normal, Técnicas de Agregación, Archivo de Distribución Normal y Nombre de Archivo. Resultado Agregación de varias técnicas generado. No posee Ing. María Florencia Pollo Cattaneo Pág. 256

257 CP-007 Procedimiento 1) Desde la pantalla principal presionar el botón Aplicar Varias Técnicas. 2) Se seleccionan la técnicas de agregación, parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). 3) Se selecciona el nombre de archivo que va a tener el archivo generado como resultado, con la ruta completa. 4) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 24: Pruebas para Aplicar Varias Técnicas CP-008 Objetivo Generar un archivo con el resultado de aplicar varias técnicas de agregación a la distribución normal seleccionada sin asignarle nombre al archivo. Entrada Tipo de Archivo, Distribución Normal, Técnicas de Agregación, Archivo de Distribución Normal. Salida Resultado Agregación de varias técnicas generado. Condiciones No posee Procedimiento 1) Desde la pantalla principal presionar el botón Aplicar Varias Técnicas. Ing. María Florencia Pollo Cattaneo Pág. 257

258 CP-008 2) Se seleccionan la técnicas de agregación, parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). 3) En la pantalla de selección de nombre no se selecciona ninguno. 4) Por defecto se asigna el nombre VarTec con la extención correspondiente (txt o xls o ambos según se seleccionara oportunamente en el caso de uso Seleccionar Tipo de Archivo), se almacena en C:/Mis Documentos/, y se avisa al usuario mediante el mensaje: El archivo se guardará como C:/Mis Documentos/VarTec.txt (o xls o ambos según corresponda). 5) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 25: Pruebas para Aplicar Varias Técnicas 2) Casos de prueba asociados al caso de uso Aplicar DMP (ver tablas DSI 26 y DSI 27) CP-009 Objetivo Entrada Salida Condiciones Generar un archivo con el resultado de aplicar la técnica de agregación DMP a la distribución normal seleccionada. Tipo de Archivo, Distribución Normal, Archivo de Distribución Normal y Nombre de Archivo. Resultado Agregación de varias técnicas generado. No posee Ing. María Florencia Pollo Cattaneo Pág. 258

259 CP-009 Procedimiento 1) Desde la pantalla principal presionar el botón Aplicar DMP. 2) Se seleccionan los parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). 3) Se selecciona el nombre de archivo que va a tener el archivo generado como resultado, con la ruta completa. 4) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 26: Pruebas para Aplicar DMP CP-010 Objetivo Entrada Salida Condiciones Procedimiento Generar un archivo con el resultado de aplicar la técnica de agregación DMP a la distribución normal seleccionada sin asignarle nombre al archivo. Tipo de Archivo, Distribución Normal, Archivo de Distribución Normal. Resultado Agregación de varias técnicas generado. No posee 1) Desde la pantalla principal presionar el botón Aplicar DMP. 2) Se seleccionan los parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). 3) En la pantalla de selección de nombre no se selecciona ninguno. Ing. María Florencia Pollo Cattaneo Pág. 259

260 CP-010 4) Por defecto se asigna el nombre DMP con la extención correspondiente (txt o xls o ambos según se seleccionara oportunamente en el caso de uso Seleccionar Tipo de Archivo), se almacena en C:/Mis Documentos/, y se avisa al usuario mediante el mensaje: El archivo se guardará como C:/Mis Documentos/DMP.txt (o xls o ambos según corresponda). 5) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 27: Pruebas para Aplicar DMP 3) Casos de prueba asociados al caso de uso Aplicar RRP (ver tablas DSI 28 y DSI 29) CP-011 Objetivo Entrada Salida Condiciones Generar un archivo con el resultado de aplicar la técnica de agregación RRP a la distribución normal seleccionada. Tipo de Archivo, Distribución Normal, Archivo de Distribución Normal y Nombre de Archivo. Resultado Agregación de varias técnicas generado. No posee Procedimiento 1) Desde la pantalla principal presionar el botón Aplicar RRP. 2) Se seleccionan los parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). Ing. María Florencia Pollo Cattaneo Pág. 260

261 CP-011 3) Se selecciona el nombre de archivo que va a tener el archivo generado como resultado, con la ruta completa. 4) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 28: Pruebas para Aplicar RRP CP-012 Objetivo Entrada Salida Condiciones Procedimiento Generar un archivo con el resultado de aplicar la técnica de agregación RRP a la distribución normal seleccionada sin asignarle nombre al archivo. Tipo de Archivo, Distribución Normal, Archivo de Distribución Normal. Resultado Agregación de varias técnicas generado. No posee 1) Desde la pantalla principal presionar el botón Aplicar RRP. 2) Se seleccionan los parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). 3) En la pantalla de selección de nombre no se selecciona ninguno. 4) Por defecto se asigna el nombre RRP con la extención correspondiente (txt o xls o ambos según se seleccionara oportunamente en el caso de uso Seleccionar Tipo de Archivo), se almacena en C:/Mis Documentos/, y se avisa al usuario mediante el mensaje: El archivo se guardará como C:/Mis Documentos/RRP.txt (o xls o ambos según corresponda). Ing. María Florencia Pollo Cattaneo Pág. 261

262 CP-012 5) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 29: Pruebas para Aplicar RRP 4) Casos de prueba asociados al caso de uso Aplicar RRNP (ver tablas DSI 30 y DSI 31) CP-013 Objetivo Entrada Salida Condiciones Procedimiento Generar un archivo con el resultado de aplicar la técnica de agregación RRNP a la distribución normal seleccionada. Tipo de Archivo, Distribución Normal, Archivo de Distribución Normal y Nombre de Archivo. Resultado Agregación de varias técnicas generado. No posee 1) Desde la pantalla principal presionar el botón Aplicar RRNP. 2) Se seleccionan los parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). 3) Se selecciona el nombre de archivo que va a tener el archivo generado como resultado, con la ruta completa. 4) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 30: Pruebas para Aplicar RRNP Ing. María Florencia Pollo Cattaneo Pág. 262

263 CP-014 Objetivo Entrada Salida Condiciones Procedimiento Generar un archivo con el resultado de aplicar la técnica de agregación RRNP a la distribución normal seleccionada sin asignarle nombre al archivo. Tipo de Archivo, Distribución Normal, Archivo de Distribución Normal. Resultado Agregación de varias técnicas generado. No posee 1) Desde la pantalla principal presionar el botón Aplicar RRNP. 2) Se seleccionan los parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). 3) En la pantalla de selección de nombre no se selecciona ninguno. 4) Por defecto se asigna el nombre RRNP con la extención correspondiente (txt o xls o ambos según se seleccionara oportunamente en el caso de uso Seleccionar Tipo de Archivo), se almacena en C:/Mis Documentos/, y se avisa al usuario mediante el mensaje: El archivo se guardará como C:/Mis Documentos/RRNP.txt (o xls o ambos según corresponda). 5) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 31: Pruebas para Aplicar RRNP Ing. María Florencia Pollo Cattaneo Pág. 263

264 5) Casos de prueba asociados al caso de uso Aplicar VC (ver tablas DSI 32 y DSI 33) CP-015 Objetivo Entrada Salida Condiciones Procedimiento Generar un archivo con el resultado de aplicar la técnica de agregación VC a la distribución normal seleccionada. Tipo de Archivo, Distribución Normal, Archivo de Distribución Normal y Nombre de Archivo. Resultado Agregación de varias técnicas generado. No posee 1) Desde la pantalla principal presionar el botón Aplicar VC. 2) Se seleccionan los parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). 3) Se selecciona el nombre de archivo que va a tener el archivo generado como resultado, con la ruta completa. 4) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 32: Pruebas para Aplicar VC CP-016 Objetivo Entrada Salida Generar un archivo con el resultado de aplicar la técnica de agregación VC a la distribución normal seleccionada sin asignarle nombre al archivo. Tipo de Archivo, Distribución Normal, Archivo de Distribución Normal. Resultado Agregación de varias técnicas generado. Ing. María Florencia Pollo Cattaneo Pág. 264

265 CP-016 Condiciones Procedimiento No posee 1) Desde la pantalla principal presionar el botón Aplicar VC. 2) Se seleccionan los parámetros, tipo de archivo y distribución normal a través de otros casos de uso (que de no ejecutarse correctamente, no superará este paso, estas ejecuciones se detallan en los casos de uso correspondientes). 3) En la pantalla de selección de nombre no se selecciona ninguno. 4) Por defecto se asigna el nombre VC con la extención correspondiente (txt o xls o ambos según se seleccionara oportunamente en el caso de uso Seleccionar Tipo de Archivo), se almacena en C:/Mis Documentos/, y se avisa al usuario mediante el mensaje: El archivo se guardará como C:/Mis Documentos/VC.txt (o xls o ambos según corresponda). 5) Se genera el archivo correspondiente, y se muestra el mensaje Archivo generado. Prerrequisitos No posee Tabla DSI 33: Pruebas para Aplicar VC 6) Casos de prueba asociados al caso de uso Seleccionar Técnicas (ver tablas DSI 34 y DSI 35) CP-017 Objetivo Entrada Salida Seleccionar una o varias de entre cuatro técnicas de agregación (DMP, RRP, RRNP y VC). Ninguna Conjunto de técnicas de agregación seleccionadas (en un vector booleano que por cada elemento corresponde una técnicas) Ing. María Florencia Pollo Cattaneo Pág. 265

266 CP-017 Condiciones Procedimiento No posee 1) Comienza a partir de la ejecución del caso de uso Aplicar Varias Técnicas. 2) A partir de una pantalla donde se tiene la posibilidad de tildar una o varias técnicas, el usuario tilda las que va a aplicar. 3) El sistema debe almacenar la información de las técnicas escogidas por el usuario y pasar a la siguiente pantalla, de selección de parámetros. Prerrequisitos No posee Tabla DSI 34: Pruebas para Seleccionar Técnica CP-018 Objetivo Entrada Salida Condiciones Procedimiento El usuario no selecciona ninguna técnica. Ninguna Conjunto de técnicas de agregación seleccionadas (en un vector booleano que por cada elemento corresponde una técnicas) No posee 1) Comienza a partir de la ejecución del caso de uso Aplicar Varias Técnicas. 2) A partir de una pantalla donde se tiene la posibilidad de tildar una o varias técnicas, el usuario NO tilda ninguna técnica. 3) El sistema debe detecta la falta de selección del usuario y selecciona DMP, para pasar a la siguiente pantalla, de selección de parámetros. Prerrequisitos No posee Tabla DSI 35: Pruebas para Seleccionar Técnica Ing. María Florencia Pollo Cattaneo Pág. 266

267 7) Casos de prueba asociados al caso de uso Seleccionar Parámetros (ver tablas DSI 36 a DSI 38) CP-019 Objetivo Entrada Salida Condiciones Procedimiento Seleccionar correctamente el conjunto de parámetros que establecerán las características de la distribución normal. Ninguna Conjunto de técnicas de parámetros que darán las características a los experimentos simulados. No posee 1) Existe una pantalla de selección de parámetros donde se le asigna los valores a cado uno de ellos (se llega a ella a partir de la aplicación de DMP, RRP, RRNP o VC o de la pantalla de selección de técnicas o de Generar DN). 2) El usuario asigna los valores correspondientes a cada parámetro y presiona el botón Siguiente. 3) El sistema verifica el conjunto de parámetros. 4) El sistema almacena el conjunto de parámetros. 5) El sistema muestra la siguiente pantalla de selección de tipo de archivo. Prerrequisitos No posee Tabla DSI 36: Pruebas para Seleccionar Parámetros CP-020 Objetivo Entrada Salida Seleccionar erróneamente el conjunto de parámetros que establecerán las características de la distribución normal. Ninguna Error en la selección de parámetros Ing. María Florencia Pollo Cattaneo Pág. 267

268 CP-020 Condiciones No posee Procedimiento 1) Existe una pantalla de selección de parámetros donde se le asigna los valores a cado uno de ellos. 2) El usuario asigna los valores correspondientes a cada parámetro y presiona el botón Siguiente. 3) El sistema verifica el conjunto de parámetros y descubre alguna inconsistencia (el conjunto de parámetros tiene ciertos valores límites). 4) El sistema avisa al usuario del error y aborta la operación volviendo a la pantalla inicial. Prerrequisitos No posee Tabla DSI 37: Pruebas para Seleccionar Parámetros CP-021 Objetivo Entrada No seleccionar ninguno o algunos de los parámetros Ninguna Salida Condiciones Procedimiento Conjunto de técnicas de parámetros que darán las características a los experimentos simulados. No posee 1) Existe una pantalla de selección de parámetros donde se le asigna los valores a cado uno de ellos. 2) El usuario asigna los valores correspondientes a cada parámetro y presiona el botón Siguiente. Ing. María Florencia Pollo Cattaneo Pág. 268

269 CP-021 3) El sistema verifica el conjunto de parámetros y descubre que hay parámetros sin valor. 4) El sistema asigna a estos parámetros los valores por defecto si se inició el proceso por el caso de uso Generar DN, y no selecciona ninguno si se inició por algún caso de uso de aplicación de técnicas de agregación (Aplicar DMP, Aplicar RRP, etc., dejando que al seleccionar el archivo de DN se aporten los parámetros en ese instante). 5) El sistema almacena el conjunto de parámetros (nulos en caso de estar dentro del procesamiento de la aplicación de alguna de las técnicas de agregación). 6) El sistema muestra la siguiente pantalla de selección de tipo de archivo. Prerrequisitos No posee Tabla DSI 38: Pruebas para Seleccionar Parámetros 8) Casos de prueba asociados al caso de uso Seleccionar Tipo de Archivo (ver tablas DSI 39 a DSI 42) 9) CP-022 Objetivo Entrada Salida Condiciones Seleccionar el tipo o tipos de archivo a generar. Cantidad de simulaciones Tipo de archivo seleccionado. No posee Procedimiento 1) La pantalla es similar a la de seleccionar técnicas, pero el usuario tiene dos opciones para tildar que no son excluyentes: texto (txt) o plantillas Excel (xls). Ing. María Florencia Pollo Cattaneo Pág. 269

270 CP-022 2) El usuario tilda la/s opción/es que utilizará. 3) El sistema realiza las verificaciones de tamaño y opción escogida. 4) El sistema debe almacenar la información del tipo/s de archivo/s escogido/s por el usuario y pasar a la siguiente pantalla, de selección de distribución normal. Prerrequisitos No posee Tabla DSI 39: Pruebas para Seleccionar Tipo de Archivo CP-023 Objetivo Entrada Salida Condiciones Procedimiento Seleccionar los dos tipos de archivo, (uno de ellos es xls), y con una cantidad de simulaciones muy grande para la generación de este tipo de archivo (Excel). Cantidad de simulaciones Tipo de archivo txt y xls y mensaje de advertencia No posee 1) La pantalla es similar a la de seleccionar técnicas, pero el usuario tiene dos opciones para tildar que no son excluyentes: texto (txt) o plantillas Excel (xls). 2) El usuario selecciona los dos tipos de archivo. 3) El sistema realiza las verificaciones de tamaño y opción escogida. 4) El sistema encuentra que la cantidad de simulaciones es muy grande para un archivo Excel. 5) El sistema emite un mensaje informado que se generará l archivo txt sin problemas, y el xls con las primeras 200 simulaciones. Ing. María Florencia Pollo Cattaneo Pág. 270

271 CP-023 6) El sistema pasa a la siguiente pantalla, de selección de distribución normal. Prerrequisitos No posee Tabla DSI 40: Pruebas para Seleccionar Tipo de Archivo CP-024 Objetivo Entrada Salida Condiciones Procedimiento Seleccionar el tipo xls y con una cantidad de simulaciones muy grande para la generación de este tipo de archivo. Cantidad de simulaciones Tipo de archivos txt y xls con mensaje de advertencia No posee 1) La pantalla es similar a la de seleccionar técnicas, pero el usuario tiene dos opciones para tildar que no son excluyentes: texto (txt) o plantillas Excel (xls). 2) El usuario selecciona el tipo xls. 3) El sistema realiza las verificaciones de tamaño y opción escogida. 4) El sistema encuentra que la cantidad de simulaciones es muy grande para un archivo Excel. 5) El sistema emite un mensaje informado que se generará l archivo txt sin problemas, y el xls con las primeras 200 simulaciones. 6) El sistema pasa a la siguiente pantalla, de selección de distribución normal. Prerrequisitos No posee Tabla DSI 41: Pruebas para Seleccionar Tipo de Archivo Ing. María Florencia Pollo Cattaneo Pág. 271

272 CP-025 Objetivo Entrada Salida Condiciones Procedimiento No seleccionar el tipo o tipos de archivo a generar. Cantidad de simulaciones Tipo de archivo txt (con mensaje informativo) No posee 1) La pantalla es similar a la de seleccionar técnicas, pero el usuario tiene dos opciones para tildar que no son excluyentes: texto (txt) o plantillas Excel (xls). 2) El usuario no selecciona ningún archivo. 3) El sistema realiza las verificaciones. 4) El sistema detecta la falta de selección de archivo y escoge por defecto el tipo txt. 5) El sistema informa al usuario por medio de un mensaje de la generación del archivo en formato texto (txt). 6) El sistema pasa a la siguiente pantalla, de selección de distribución normal. Prerrequisitos No posee Tabla DSI 42: Pruebas para Seleccionar Tipo de Archivo 10) Casos de prueba asociados al caso de uso Seleccionar DN (ver tablas DSI 43 a DSI 45) CP-026 Objetivo Entrada Salida Seleccionar correctamente la DN a la cual aplicar la/s técnica/s de agregación. Conjunto de parámetros seleccionados en el caso de uso correspondiente Dirección de la DN a procesar Ing. María Florencia Pollo Cattaneo Pág. 272

273 CP-026 Condiciones Procedimiento No posee 1) Se llega a esta pantalla desde la pantalla de selección de tipo de archivo, y luego de haber iniciado la ejecución de alguna de las funciones de Aplicar Técnica X, y tras haber ejecutado exitosamente los casos de uso Seleccionar Técnica (solo para Aplicar Varias Técnicas), Seleccionar Parámetros, y Seleccionar Tipo de Archivo. 2) El usuario seleccionar un archivo correcto para la aplicación del proceso de agregación. 3) El sistema realiza las verificaciones de archivo y correspondencia de parámetros (si no se seleccionaron parámetros, se asignan en este paso). 4) El sistema almacena la información de la dirección del archivo seleccionado de DN. 5) El sistema vuelve al caso de uso que inició el proceso (Aplicar DMP, Aplicar RRP, Aplicar RRNP, Aplicar VC o Aplicar Varias Técnicas). Prerrequisitos No posee Tabla DSI 43: Pruebas para Seleccionar DN CP-027 Objetivo Entrada Salida Condiciones Seleccionar erróneamente la DN a la cual aplicar la/s técnica/s de agregación. Conjunto de parámetros seleccionados en el caso de uso correspondiente Mensaje de error No posee Ing. María Florencia Pollo Cattaneo Pág. 273

274 CP-027 Procedimiento 1) Se llega a esta pantalla desde la pantalla de selección de tipo de archivo, y luego de haber iniciado la ejecución de alguna de las funciones de Aplicar Técnica X, y tras haber ejecutado exitosamente los casos de uso Seleccionar Técnica (solo para Aplicar Varias Técnicas), Seleccionar Parámetros, y Seleccionar Tipo de Archivo. 2) El usuario seleccionar un archivo incorrecto para la aplicación del proceso de agregación (puede que no sea un archivo con el formato que debe tener, o sea una serie de números separados por punto y coma, o los datos del archivo no se corresponden con los parámetros ingresados). 3) El sistema realiza las verificaciones de archivo y correspondencia de parámetros. 4) El sistema detecta el error y emite un mensaje de error. Luego vuelve a la pantalla principal. Prerrequisitos No posee Tabla DSI 44: Pruebas para Seleccionar DN CP-028 Objetivo Entrada Salida Condiciones Procedimiento No selecciona ninguna DN. Conjunto de parámetros seleccionados en el caso de uso correspondiente Dirección de la DN a procesar No posee 1) Se llega a esta pantalla desde la pantalla de selección de tipo de archivo, y luego de haber iniciado la ejecución de alguna de las funciones de Aplicar Técnica X, y tras haber ejecutado exitosamente los casos de uso Seleccionar Técnica (solo para Aplicar Varias Técnicas), Seleccionar Parámetros, y Seleccionar Tipo de Archivo. Ing. María Florencia Pollo Cattaneo Pág. 274

275 CP-028 2) El usuario no selecciona ningún archivo y presiona el botón Siguiente. 3) El sistema detecta el error, emite un mensaje, y vuelve a la pantalla de seleccionar DN. Prerrequisitos No posee Tabla DSI 45: Pruebas para Seleccionar DN APROBACIÓN DEL DISEÑO DEL SISTEMA DE INFORMACIÓN PRESENTACIÓN Y APROBACIÓN DEL DISEÑO DEL SISTEMA DE INFORMACIÓN En esta tarea se realiza la presentación del diseño del sistema de información al Comité de Dirección para la aprobación final del mismo. En una reunión mantenida entre la Tesista y el Director del proyecto se dio por aprobada la fase de Diseño del Sistema de Información. Ing. María Florencia Pollo Cattaneo Pág. 275

277 Capítulo 6 Construcción del Sistema de Información Ing. María Florencia Pollo Cattaneo Pág. 277

279 6.- CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN En este proceso se genera el código de los componentes del Sistema de Información, se desarrollan todos los procedimientos de operación y seguridad y se elaboran todos los manuales de usuario final y de explotación con el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior implantación. Para conseguir dicho objetivo, en este proceso se realizan las pruebas unitarias, las pruebas de integración de los subsistemas y componentes y las pruebas del sistema, de acuerdo al plan de pruebas establecido. Asimismo, se define la formación de usuario final y, si procede, se construyen los procedimientos de migración y carga inicial de datos. Al ser MÉTRICA Versión III una metodología que cubre tanto desarrollos estructurados como orientados a objetos, las actividades de ambas aproximaciones están integradas en una estructura común. Ing. María Florencia Pollo Cattaneo Pág. 279

280 La fase Especificaciones de Construcción del Sistema de Información, obtenida en la actividad de Generación de Especificaciones de Construcción, es la base para la construcción del sistema de información. En dicho producto se recoge la información relativa al entorno de construcción del sistema de información, la especificación detallada de los componentes y la descripción de la estructura física de datos, tanto bases de datos como sistemas de ficheros. En la actividad Preparación del Entorno de Generación y Construcción, se asegura la disponibilidad de la infraestructura necesaria para la generación del código de los componentes y procedimientos del sistema de información. Una vez configurado el entorno de construcción, se realiza la codificación y las pruebas de los distintos componentes que conforman el sistema de información, en las actividades: Generación del Código de los Componentes y Procedimientos, que se hace según las especificaciones de construcción del sistema de información, y conforme al plan de integración del sistema de información Ejecución de las Pruebas Unitarias, dónde se llevan a cabo las verificaciones definidas en el plan de pruebas para cada uno de los componentes Ejecución de las Pruebas de Integración, que incluye la ejecución de las verificaciones asociadas a los subsistemas y componentes, a partir de los componentes verificados individualmente, y la evaluación de los resultados. Una vez construido el sistema de información y realizadas las verificaciones correspondientes, se lleva a cabo la integración final del sistema de información en la actividad Ejecución de las Pruebas del Sistema, comprobando tanto las interfaces entre Ing. María Florencia Pollo Cattaneo Pág. 280

281 subsistemas y sistemas externos como los requisitos, de acuerdo a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema. Si se ha establecido la necesidad de realizar una migración de datos, la construcción y pruebas de los componentes y procedimientos relativos a dicha migración y a la carga inicial de datos se realiza en la actividad Construcción de los Componentes y Procedimientos de Migración y Carga Inicial de Datos PREPARACIÓN DEL ENTORNO DE GENERACIÓN Y CONSTRUCCIÓN El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y facilidades para que se pueda llevar a cabo la construcción del sistema de información. Entre estos medios, cabe destacar la preparación de los puestos de trabajo, equipos físicos y lógicos, gestores de bases de datos, bibliotecas de programas, herramientas de generación de código, bases de datos o ficheros de prueba, entre otros. Las características del entorno de construcción y sus requisitos de operación y seguridad, así como las especificaciones de construcción de la estructura física de datos, se establecen en la actividad Generación de Especificaciones de Construcción, y constituyen el punto de partida para la realización de esta actividad IMPLANTACIÓN DE LA BASE DE DATOS FÍSICA O FICHEROS Como en este primer prototipo no hay base de datos, esta tarea no se realiza en el presente proyecto, quedando pendiente para una siguiente versión. Solamente se almacenarán los resultados en archivos, cuyo soporte estará dado por el mismo sistema operativo donde corre nuestro sistema PREPARACIÓN DEL ENTORNO DE CONSTRUCCIÓN Ing. María Florencia Pollo Cattaneo Pág. 281

282 En esta tarea se prepara el entorno en el que se construirán los componentes del sistema de información, contemplando aspectos tales como: Bibliotecas o librerías a utilizar Herramientas: generadores de código, editores, compiladores, verificadores sintácticos, montadores de enlace Puestos de trabajo Implementación de los procedimientos de operación y seguridad propios del entorno de construcción, de acuerdo a los requisitos de seguridad y operación establecidos en la tarea Especificación del Entorno de Construcción GENERACIÓN DEL ENTORNO DE TRABAJO Para el presente proyecto, se deberán instalar el entorno de trabajo de Visual Basic 2005 Express Edition para usar VB.NET. Para esta tarea se recomienda consultar el manual de instalación del producto GENERACIÓN DEL CÓDIGO DE LOS COMPONENTES Y PROCEDIMIENTOS El objetivo de esta actividad es la codificación de los componentes del sistema de información, a partir de las especificaciones de construcción obtenidas en el proceso Diseño del Sistema de Información, así como la construcción de los procedimientos de operación y seguridad establecidos para el mismo. En paralelo a esta actividad, se desarrollan las actividades relacionadas con las pruebas unitarias y de integración del sistema de información. Esto permite una Ing. María Florencia Pollo Cattaneo Pág. 282

283 construcción incremental, en el caso de que así se haya especificado en el plan de pruebas y en el plan de integración del sistema de información GENERACIÓN DEL CÓDIGO DE COMPONENTES En esta tarea se genera el código correspondiente a cada uno de los componentes del sistema de información, identificados en la tarea Definición de Componentes y Subsistemas de Construcción. Para generar el código fuente se tienen en cuenta los estándares de nomenclatura, codificación y calidad utilizados por la organización y recogidos en el catálogo de normas. Con el fin de verificar que el código fuente especifica de forma correcta el componente, se realiza su ensamblaje o compilación, verificando y corrigiendo los errores sintácticos, y el enlace del código objeto obtenido con las correspondientes bibliotecas GENERACIÓN DEL CÓDIGO DE LOS PROCEDIMIENTOS DE OPERACIÓN Y SEGURIDAD El objetivo de esta tarea es generar los procedimientos de operación y administración del sistema de información, así como los procedimientos de seguridad y control de acceso, necesarios para ejecutar el sistema una vez que se haya implantado y esté en producción GENERACIÓN DE PROCEDIMIENTOS DE OPERACIÓN Y SEGURIDAD Como ya se ha indicado antes, el sistema no posee base de datos ni se requiere en este primer prototipo validación de usuario (hacerlo sin una Base de Datos sería muy poco eficiente), por lo que esta tarea quedará relegada para uno próximo versionado. Ing. María Florencia Pollo Cattaneo Pág. 283

284 6.3.- EJECUCIÓN DE LAS PRUEBAS UNITARIAS En esta actividad se realizan las pruebas unitarias de cada uno de los componentes del sistema de información, una vez codificados, con el objeto de comprobar que su estructura es correcta y que se ajustan a la funcionalidad establecida. En el plan de pruebas se ha definido el entorno necesario para la realización de cada nivel de prueba, así como las verificaciones asociadas a las pruebas unitarias, la coordinación y secuencia a seguir en la ejecución de las mismas y los criterios de registro y aceptación de los resultados REALIZACIÓN Y EVALUACIÓN DE LAS PRUEBAS UNITARIAS El objetivo de esta tarea es comprobar el correcto funcionamiento de los componentes del sistema de información, codificados en la actividad Generación del Código de los Componentes y Procedimientos, conforme a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas unitarias, en la actividad Especificación Técnica del Plan de Pruebas. Para cada verificación establecida, se realizan las pruebas con los casos de pruebas asociados, efectuando el correspondiente análisis y evaluación de los resultados, y generando un registro conforme a los criterios establecidos en el plan de pruebas. Seguidamente, se analizan los resultados de las pruebas unitarias, evaluándose las mismas para comprobar que los resultados son los esperados. Si los resultados no son los esperados hay que proceder a realizar las correcciones pertinentes. Ing. María Florencia Pollo Cattaneo Pág. 284

285 RESULTADO DE LA REALIZACIÓN DE LAS PRUEBAS UNITARIAS A continuación, en la tabla CSI 1, se detalla el resultado de las pruebas unitarias luego de realizar dos iteraciones de modificación sobre el desarrollo de los componentes de comunicación: Código Componente Resultado CP-001 Generar DN Correcto CP-002 Generar DN Correcto CP-003 Generar DN Correcto CP-004 Generar DN Correcto CP-005 Generar DN Correcto CP-006 Generar DN Correcto Tabla CSI 1: Resultado de la ejecución de los casos de prueba unitarios EJECUCIÓN DE LAS PRUEBAS DEL SISTEMA El objetivo de las pruebas del sistema es comprobar la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. En la realización de estas pruebas es importante comprobar la cobertura de los requisitos, dado que su incumplimiento puede comprometer la aceptación del sistema por el equipo de operación responsable de realizar las pruebas de implantación del sistema, que se llevarán a cabo en el proceso Implantación y Aceptación del Sistema. Ing. María Florencia Pollo Cattaneo Pág. 285

286 REALIZACIÓN DE LAS PRUEBAS DEL SISTEMA El objetivo de esta tarea es comprobar la integración de todos los subsistemas y componentes del sistema de información, así como la interacción del mismo con otros sistemas de información con los que se relaciona, de acuerdo a las verificaciones establecidas para el nivel de pruebas del sistema. Para cada verificación establecida, se realizan las pruebas con los casos de pruebas asociados, efectuando el correspondiente análisis e informe de los resultados y generando un registro conforme a los criterios establecidos en el plan de pruebas RESULTADO DE LA REALIZACIÓN DE LAS PRUEBAS DE SISTEMA A continuación, en la tabla CSI 2, se detalla el resultado de las pruebas a nivel de sistemas luego de realizar tres iteraciones de modificación sobre el desarrollo del sistema: Código Caso de Uso Objetivo CP-007 Aplicar Varias Técnicas Correcto CP-008 Aplicar Varias Técnicas Correcto CP-009 Aplicar DMP Correcto CP-010 Aplicar DMP Correcto CP-011 Aplicar RRP Correcto CP-012 Aplicar RRP Correcto CP-013 Aplicar RRNP Correcto CP-014 Aplicar RRN Correcto Ing. María Florencia Pollo Cattaneo Pág. 286

287 Código Caso de Uso Objetivo CP-015 Aplicar VC Correcto CP-016 Aplicar VC Correcto CP-017 Seleccionar Técnicas Correcto CP-018 Seleccionar Técnicas Correcto CP-019 Seleccionar Parámetros Correcto CP-020 Seleccionar Parámetros Correcto CP-021 Seleccionar Parámetros Correcto CP-022 Seleccionar Tipo de Archivo Correcto CP-023 Seleccionar Tipo de Archivo Correcto CP-024 Seleccionar Tipo de Archivo Correcto CP-025 Seleccionar Tipo de Archivo Correcto CP-026 Seleccionar DN Correcto CP-027 Seleccionar DN Correcto CP-028 Seleccionar DN Correcto Tabla CSI 2: Resultado de la ejecución de los casos de prueba unitarios EVALUACIÓN DEL RESULTADO DE LAS PRUEBAS DEL SISTEMA El objetivo de esta actividad es analizar los resultados de las pruebas del sistema de información y efectuar su evaluación. Dicha evaluación recoge el grado de cumplimiento de las mismas. Ing. María Florencia Pollo Cattaneo Pág. 287

288 RESULTADO DE LA EVALUACIÓN DE LOS RESULTADOS DE LAS PRUEBAS DE SISTEMA En función del análisis de los resultado de los casos de prueba indicado en la tabla CSI 2 podemos decir que el sistema a alcanzado los niveles de calidad deseados, dado que todas las salidas se encuentran dentro de los parámetros de valores esperado APROBACIÓN DEL SISTEMA DE INFORMACIÓN En esta tarea se recopilan los productos del sistema de información y se presentan al Comité de Seguimiento para su aprobación. En una reunión mantenida entre la Tesista y el Director del proyecto se dio por aprobada la fase de Construcción del Sistema de Información. Ing. María Florencia Pollo Cattaneo Pág. 288

289 Capítulo 7 Implementación y Aceptación del Sistema de Información Ing. María Florencia Pollo Cattaneo Pág. 289

291 7.- IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA Este proceso tiene como objetivo principal la entrega y aceptación del sistema informático en su totalidad, además de todas las actividades necesarias para el paso a producción del mismo. En primer lugar, se revisa la estrategia de implantación que ya se determinó en el proceso Estudio de Viabilidad del Sistema (EVS). Se estudia su alcance y, en función de sus características, se define un plan de implantación y se especifica el equipo que lo va a llevar a cabo. Conviene señalar la participación del usuario de operación en las pruebas de implantación, del usuario final en las pruebas de aceptación, y del responsable de mantenimiento. Las actividades previas al inicio de la producción incluyen la preparación de la infraestructura necesaria para configurar el entorno, la instalación de los componentes, la activación de los procedimientos manuales y automáticos asociados y, cuando proceda, la migración o carga inicial de datos. Para ello se toman como punto de partida los productos software probados, obtenidos en el proceso Construcción del Sistema de Información (CSI) y su documentación asociada. Ing. María Florencia Pollo Cattaneo Pág. 291

292 Se realizan las pruebas de implantación y de aceptación del sistema en su totalidad, las mismas responden a los siguientes propósitos: Las pruebas de implantación cubren un rango muy amplio, que va desde la comprobación de cualquier detalle de diseño interno hasta aspectos tales como las comunicaciones. Se debe comprobar que el sistema puede gestionar los volúmenes de información requeridos, se ajusta a los tiempos de respuesta deseados y que los procedimientos de respaldo, seguridad e interfaces con otros sistemas funcionan correctamente. Se debe verificar, también, el comportamiento del sistema bajo las condiciones más extremas. Las pruebas de aceptación se realizan por y para los usuarios. Tienen como objetivo validar formalmente que el sistema se ajusta a sus necesidades. Asimismo, se llevan a cabo las tareas necesarias para la preparación del mantenimiento, siempre y cuando se haya decidido que éste va a efectuarse. En cualquier caso, es necesario que la persona que vaya a asumir el mantenimiento conozca el sistema, antes de su incorporación al entorno de producción. Además hay que determinar los servicios (y niveles para cada uno) que requiere el sistema que se va a implantar, y el acuerdo que se adquiere una vez que se inicie la producción. Hay que distinguir entre servicios de gestión de operaciones (servicios por lotes, seguridad, comunicaciones, etc.) y servicios al cliente (servicio de atención a usuario, mantenimiento, etc.) que se deben negociar en cuanto a recursos, horarios, coste, etc. Se fija el nivel con el que se prestará el servicio como indicador de la calidad del mismo. Ing. María Florencia Pollo Cattaneo Pág. 292

293 Conviene señalar que la implantación puede ser un proceso iterativo que se realiza de acuerdo al plan establecido para el comienzo de la producción del sistema en su entorno de operación. Para establecer este plan se tiene en cuenta: El cumplimiento de los requisitos de implantación definidos en la actividad Establecimiento de Requisitos y especificados en la actividad Establecimiento de Requisitos de Implantación. La estrategia de transición del sistema antiguo al nuevo. Finalmente, se realizan las acciones necesarias para el inicio de la producción ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN En esta actividad se revisa la estrategia de implantación para el sistema, establecida inicialmente en el proceso Estudio de Viabilidad del Sistema (EVS). Se identifican los distintos sistemas de información que forman parte del sistema objeto de la implantación. Para cada sistema se analizan las posibles dependencias con otros proyectos, que puedan condicionar el plan de implantación. Una vez estudiado el alcance y los condicionantes de la implantación, se decide si ésta se puede llevar a cabo. Será preciso establecer, en su caso, la estrategia que se concretará de forma definitiva en el plan de implantación. Se constituye el equipo de implantación, determinando los recursos humanos necesarios para la propia instalación del sistema, para las pruebas de implantación y aceptación, y para la preparación del mantenimiento. Se identifican, para cada uno de ellos, sus perfiles y niveles de responsabilidad. Ing. María Florencia Pollo Cattaneo Pág. 293

294 DEFINICIÓN DEL PLAN DE IMPLANTACIÓN La estrategia de implantación del sistema se habrá determinado en la tarea Evaluación de las Alternativas y Selección del proceso Estudio de Viabilidad del Sistema, en función de la envergadura del sistema, es decir el número de sistemas de información implicados en la implantación y la cobertura geográfica, cuyo alcance depende de las características y complejidad de los sistemas de información que conforman el sistema objeto de la implantación. Se revisan los requisitos de implantación (instalación, infraestructura, formación) establecidos en la tarea Especificación de Requisitos de Implantación y los procedimientos implicados en la implantación, establecidos para cada uno de los sistemas de información en la tarea Especificación de Requisitos de Operación y Seguridad, con el fin de asegurar su adecuación a la estrategia global de implantación. Una vez analizada la información anterior, se define un plan de implantación que permita calcular adecuadamente el esfuerzo y los recursos necesarios para llevar a cabo con éxito la implantación. Dicho plan debe contemplar todas las tareas relacionadas con: La formación necesaria para la implantación, tanto a usuarios finales como al equipo que se encarga de realizar las pruebas de implantación y aceptación del sistema. La preparación de la infraestructura necesaria para la incorporación del sistema al entorno de operación. La instalación de todos los componentes y procedimientos manuales y automáticos asociados a cada sistema de información implicado en la implantación. Ing. María Florencia Pollo Cattaneo Pág. 294

295 La ejecución de los procedimientos de carga inicial y migración de datos, si se determinó su necesidad. La realización de las pruebas de implantación y aceptación del sistema. La formalización del plan de mantenimiento FORMACIÓN DE USUARIOS FINALES Y EQUIPO DE PRUEBAS Se prevé capacitar a un usuario líder en el uso del sistema de información de forma tal que pueda utilizarlo para verificar que el mismo cumple con sus requisitos para posteriormente aceptar el sistema. Dicho usuario debe ser una persona con experiencia en la experimentación dentro de la Ingeniería de Software PREPARACIÓN DE LA INFRAESTRUCTURA NECESARIA PARA LA INCORPORACIÓN DEL SISTEMA AL ENTORNO DE OPERACIÓN Al tratarse de un sistema monousuario, sin base de datos ni validación de usuario, residente en un único equipo, no hay muchas consideraciones a tener en cuenta. La aplicación se instalará directamente en el equipo, que sólo debe tener instalado previamente el Microsoft Framework EJECUCIÓN DE CARGA INICIAL Este item no es necesario tratar debido a la carencia de Base de Datos. Ing. María Florencia Pollo Cattaneo Pág. 295

296 REALIZACIÓN DE LAS PRUEBAS DE IMPLEMENTACIÓN Y ACEPTACIÓN DEL SISTEMA Se realizan las pruebas necesarias con este propósito. Es el mismo usuario final el que realizará las pruebas, viendo que no hay diferenciación de usuarios en todos los puntos detallados hasta aquí FORMALIZACIÓN DEL PLAN DE MANTENIMIENTO El mantenimiento del sistema no es dificultoso debido a la baja complejidad del mismo, no obstante ello, la etapa de mantenimiento del sistema de información excede los límites del proyecto de tesis, y no se detallará en este punto ESPECIFICACIÓN DEL EQUIPO DE IMPLANTACIÓN Se constituye el equipo de trabajo necesario para llevar a cabo la implantación y aceptación del sistema, según el plan de implantación establecido en la tarea anterior. Para ello se identifican, en función del nivel de esfuerzo requerido, los distintos participantes implicados en la implantación del sistema (usuarios, equipo técnico y responsable de mantenimiento), determinando previamente sus perfiles, responsabilidades, nivel de implicación y fechas previstas de participación a lo largo de toda la implantación EQUIPO DE IMPLANTACIÓN Como el sistema es monousuario y el sistema fue desarrollado por la Tesista y el Director del Proyecto, y debido a que se utilizará para experimentación en el ámbito de la Ingeniería de Software, el equipo de implantación estará constituido, precisamente, por la Tesista y el Director del Proyecto (la Tesista también desempeñará el rol de usuario final descrito anteriormente). Ing. María Florencia Pollo Cattaneo Pág. 296

297 7.2.- INCORPORACIÓN DEL SISTEMA AL ENTORNO DE OPERACIÓN En esta actividad se realizan todas las tareas necesarias para la incorporación del sistema al entorno de operación en el que se van a llevar a cabo las pruebas de implantación y aceptación del sistema. Mientras que las pruebas unitarias, de integración y del sistema se pueden ejecutar en un entorno distinto de aquel en el que finalmente se implantará; las pruebas de implantación y aceptación del sistema deben ejecutarse en el entorno real de operación. El propósito es comprobar que, el sistema satisface todos los requisitos especificados por el usuario en las mismas condiciones que cuando se inicie la producción. Por tanto, como paso previo a la realización de dichas pruebas y de acuerdo al plan de implantación establecido, se verifica que los recursos necesarios están disponibles para que se pueda realizar, adecuadamente, la instalación de todos los componentes que integran el sistema, así como la creación y puesta a punto de las bases de datos en el entorno de operación. Asimismo, se establecen los procedimientos de explotación y uso de las bases de datos de acuerdo a la normativa existente en dicho entorno PREPARACIÓN DE LA INSTALACIÓN En esta tarea se verifica que la infraestructura necesaria para configurar el entorno se encuentra disponible. Debido a las características de este primer prototipo (monousuario, único equipo, sin base de datos y sin validación de usuario), la infraestructura es muy simple, y es de características muy similares (sino las mismas) que el entorno de desarrollo. Una vez comprobada la idoneidad de los distintos elementos relacionados con la infraestructura, se realiza la instalación del software de base necesario para la Ing. María Florencia Pollo Cattaneo Pág. 297

298 incorporación posterior de los componentes asociados a los sistemas de información implicados en la implantación DESCRIPCIÓN DE LA INSTALACIÓN Dentro del contexto de desarrollo del presente trabajo, se deberá proceder a la instalación del siguiente software: Sistema Operativo Windows XP Professional Service Pack 2 Microsoft Office 2003 Microsoft Framework REALIZACIÓN DE LA INSTALACIÓN Se realiza la instalación de todos los componentes del nuevo sistema, incluidos los procedimientos manuales y automáticos, de acuerdo al plan de implantación, establecida en el proceso Diseño del Sistema de Información. Se deben tener en cuenta los estándares y normativas por los que se rige la organización en los entornos de operación. Una vez comprobada la correcta instalación del nuevo sistema, se activan los procedimientos de operación, de administración del sistema INSTALACIÓN DEL SISTEMA Se procedió a realizar la instalación del sistema en lo que sería un ambiente de producción típico y la misma resulto completamente exitosa. Ing. María Florencia Pollo Cattaneo Pág. 298

299 7.3.- CARGA DE DATOS AL ENTORNO DE OPERACIÓN Teniendo en cuenta que los sistemas de información que forman parte del sistema a implantar pueden mejorar, ampliar o sustituir a otros ya existentes en la organización, puede ser necesaria una carga inicial y/o una migración de datos cuyo alcance dependerá de las características y cobertura de cada sistema de información implicado. Por tanto, la necesidad de una migración de datos puede venir determinada desde el proceso Estudio de Viabilidad del Sistema (EVS), en la actividad Selección de la Solución. Allí se habrá establecido la estrategia a seguir en la sustitución, evaluando las opciones del enfoque de desarrollo e instalación más apropiados para llevarlo a cabo MIGRACIÓN Y CARGA INICIAL DE DATOS No es requerida INSTALACIÓN DEL SISTEMA operable. Se procede a la instalación del sistema, y se encuentra correctamente instalado y PRUEBAS DE IMPLANTACIÓN DEL SISTEMA La finalidad de las pruebas de implantación es doble: Comprobar el funcionamiento correcto del mismo en el entorno de operación. Permitir que el usuario determine, desde el punto de vista de operación, la aceptación del sistema instalado en su entorno real, según el cumplimiento de los requisitos especificados. Ing. María Florencia Pollo Cattaneo Pág. 299

300 Para ello, el responsable de implantación revisa el plan de pruebas de implantación y los criterios de aceptación del sistema, previamente elaborados. Las pruebas las realizan los técnicos de sistemas y de operación, que forman parte del grupo de usuarios técnicos que ha recibido la formación necesaria para llevarlas a cabo. Una vez ejecutadas estas pruebas, el equipo de usuarios técnicos informa de las incidencias detectadas al responsable de implantación, el cual analiza la información y toma las medidas correctoras que considere necesarias para que el sistema dé respuesta a las especificaciones previstas, momento en el que el equipo de operación lo da por probado PREPARACIÓN DE LAS PRUEBAS DE IMPLANTACIÓN Se comprueba la disponibilidad de los recursos humanos y técnicos necesarios para realizar las pruebas de implantación. Se revisan las verificaciones establecidas en el plan de pruebas. Si fuera necesario, se crea algún caso de prueba adicional que se considere importante y que no se haya tenido en cuenta hasta entonces. Se preparan las condiciones que permitan simular las situaciones límite previstas para las pruebas, formalmente, se comunica el plan de pruebas de implantación al equipo responsable de llevarlas a cabo PRUEBAS DE IMPLANTACIÓN Luego de revisar el esquema de pruebas definido en la fase de diseño y aplicado durante la etapa de construcción, se considera que el mismo posee una adecuada cobertura de la funciones del sistema, y por tal motivo no se considera necesario la generación de un nuevo plan de pruebas. Ing. María Florencia Pollo Cattaneo Pág. 300

301 REALIZACIÓN DE LAS PRUEBAS DE IMPLANTACIÓN Se realizan las pruebas de implantación, de acuerdo a las verificaciones establecidas en el plan de pruebas definido en la actividad Especificación Técnica del Plan de Pruebas PRUEBA DE IMPLANTACIÓN La Tesista cargó todos los casos de prueba en el entorno de producción, y la ejecución de los mismos fue exitosa en todos los casos EVALUACIÓN DEL RESULTADO DE LAS PRUEBAS DE IMPLANTACIÓN Se evalúan los resultados de las pruebas analizando las incidencias recibidas y comprobando que se han llevado a cabo todos los casos de pruebas establecidos en el plan de pruebas EVALUACIÓN DE LA PRUEBA DE IMPLANTACIÓN Como el usuario (rol desempeñado por la Tesista) no ha registrado anomalías en la carga de los casos de prueba, se da por aprobada la prueba de implementación del sistema PRUEBAS DE ACEPTACIÓN DEL SISTEMA Las pruebas de aceptación tienen como fin validar que el sistema cumple los requisitos básicos de funcionamiento esperado y permitir que el usuario determine la aceptación del sistema. Son realizadas por el usuario final que, durante este período de Ing. María Florencia Pollo Cattaneo Pág. 301

302 tiempo, debe plantear todas las deficiencias o errores que encuentre antes de dar por aprobado el sistema definitivamente. Los Directores de los Usuarios revisan los criterios de aceptación, especificados previamente en el plan de pruebas del sistema, y dirigen las pruebas de aceptación final que llevan a cabo los usuarios expertos. A su vez, éstos últimos deben elaborar un informe que los Directores de los Usuarios analizan y evalúan para determinar la aceptación o rechazo del sistema REALIZACIÓN DE LAS PRUEBAS DE ACEPTACIÓN Se llevan a cabo las pruebas de aceptación final del sistema para asegurar que todos los componentes responden a los criterios de aceptación especificados. Se registra la realización de las pruebas, incluyendo un informe que recoja la desviación de los requisitos establecidos y los problemas que quedan sin resolver PRUEBAS DE ACEPTACIÓN Las pruebas de aceptación del sistema se han llevado a cabo por la tesista (que en el rol del usuario experimentado en la experimentación dentro del campo de la Ingeniería de Software) juntamente con la prueba de implementación. El resultado de la misma ha sido exitoso PRESENTACIÓN Y APROBACIÓN DEL SISTEMA Una vez que se han efectuado las pruebas de implantación, de aceptación, y que se ha fijado el acuerdo de nivel de servicio, el Comité de Dirección debe formalizar la aprobación del sistema. Por lo cual, se lleva a cabo una presentación general del sistema al Comité de Dirección y se espera la confirmación de su aprobación. Ing. María Florencia Pollo Cattaneo Pág. 302

303 En una reunión mantenida entre la Tesista y el Director del proyecto se dio por aprobada la fase de Implementación del Sistema de Información, no obstante, como el presente trabajo forma parte de la tesis de Maestría, la aprobación final del sistema consistirá en la defensa del mismo ante un tribunal evaluador oportunamente reunido a tal fin. Ing. María Florencia Pollo Cattaneo Pág. 303

305 Capítulo 8 Aplicación del Sistema para el Análisis de Técnicas de Agregación Ing. María Florencia Pollo Cattaneo Pág. 305

307 8.- APLICACIÓN DEL SISTEMA PARA EL ANÁLISIS DE TÉCNICAS DE AGREGACIÓN Una vez probado e implantado el software, se deben realizar los primeros análisis de precisión de las técnicas de agregación descriptas en el capítulo dos de la presente tesis. El objetivo que proponemos alcanzar, es utilizar el software desarrollado para iniciar el análisis, que resulta ser génesis del proyecto. Es intención de la Tesista usar la herramienta informática dentro del campo de la Ingeniería del Software, para obtener los primeros resultados y realizar un análisis de precisión. Ing. María Florencia Pollo Cattaneo Pág. 307

308 8.1.- PREPARACIÓN DE LAS PRUEBAS Con el objetivo de realizar un primer análisis, deberemos tener en cuenta todos los factores intervinientes para poder medir los resultados obtenidos. Por lo tanto, tendremos que tomar estos factores como variables independientes (o de control) y realizar todas las combinaciones de valores que nos sean posibles para tratar de aislar la influencia de los mismos en los resultados. Logrando este objetivo, podríamos establecer la precisión de cada técnica de agregación según las condiciones de los experimentos, y conseguir una información valiosa para el campo de la investigación experimental ESPECIFICACIÓN DE LOS VALORES DE PRUEBAS Tomando como base las definiciones de las variables poblacionales, se describen las variables muestrales que se van a generar mediante el proceso de simulación. Variables Independientes: Cantidad de Sujetos Experimentales (de 2 a 20 variando de 1 en 1) Cantidad de estudios (de 2 a 10 variando de 1 en 1) Media del tratamiento experimental (generada por simulación para los parámetros poblacionales) Media del tratamiento de control (generada por simulación para los parámetros poblacionales) Desvío estándar (generada por simulación para los parámetros poblacionales) Ing. María Florencia Pollo Cattaneo Pág. 308

309 Variables Dependientes: El estimador del tamaño de Efecto (mediante WMD y VC) + Intervalo de confianza (al 90%, 95% y 99%) El estimador del RR (mediante RR paramétrico y no paramétrico) + Intervalo de confianza (al 90%, 95% y 99%) Para realizar las pruebas, se tendrán en cuenta los siguientes puntos: Cantidad de experimentos: baja y alta (dentro de los límites establecidos). Debemos tener en cuenta que al tratarse de contextos poco maduros, la cantidad de experimentos siempre es baja. No obstante ello, intentaremos establecer una cantidad muy baja y otra simplemente baja. Esta situación la tiene en cuenta el sistema diseñado al hacer variar la cantidad de experimentos y realizar todas las combinaciones posibles con la cantidad de sujetos por experimentos (que también varía entre dos valores). Cantidad de sujetos experimentales: se aplica lo mismo que el inciso anterior. Relación entre la media y el desvío estándar. Trataremos con medias de tratamiento experimental y control muy similares, al igual que los desvíos estándar. Sin embargo, el valor del desvío estándar caracteriza la forma de la campana gaussiana, haciéndola más ancha o angosta, o aplastada, o alargada. La figura ASATA 1 ilustra este punto: Ing. María Florencia Pollo Cattaneo Pág. 309

310 Figura ASATA 1: Diferentes valores de la desviación estándar ASIGNACION DE LÍMITES PARA LAS DISTINTAS PRUEBAS Para la realización de las pruebas mencionadas, se deben establecer los límites para los diferentes valores involucrados en las pruebas. Se realizarán varias pruebas, y los límites para los valores de las variables independices serán los siguientes (valores que se asignarán a los parámetros en cada corrida de la aplicación): Ing. María Florencia Pollo Cattaneo Pág. 310

311 Tabla ASATA 1: Valores de los parámetros para pruebas del sistema REALIZACIÓN DE LAS PRUEBAS Una vez establecidos los valores de las pruebas a realizar, se utiliza el sistema informático y se asignan a los parámetros los valores indicados en el punto anterior. Realizadas las pruebas, se deberán analizar los archivos generados, que quedaron almacenados en disco. Realizados los análisis, repropone un resumen de los mismos, para llegar a una primera conclusión, la cual detallaremos en el siguiente capítulo. Ing. María Florencia Pollo Cattaneo Pág. 311

312 EJECUCIÓN DE LAS PRUEBAS Se hace correr la aplicación y se almacenan los resultados en archivos txt dentro de una carpeta creada a tal efecto. El nombre de la carpeta es Prueba, y los archivos se denominan Prueba001.txt, Prueba002.txt, etc. problemas. Durante el funcionamiento no se producen errores, y se generan los archivos sin ANÁLISIS DE RESULTADOS ANÁLISIS POR INTERVALO DE CONFIANZA Se contabilizará cuántas veces el intervalo de confianza estimado contiene al valor de efecto o ratio de la población. En base a ello, se establecerá el nivel de confianza del estimador respecto de la población. Determinando a partir de qué cantidad de sujetos y experimentos la contención del efecto real está contenida el 100% de las veces ANÁLISIS DE CORRELACIÓN realizar son: El objetivo es comparar las técnicas de a pares. Las principales comparaciones a Análisis de correlación y diferencia de medias entre los resultados obtenidos mediante Diferencias Medias Ponderadas y Vote-Counting Análisis de correlación y diferencia de medias entre los resultados obtenidos mediante Response-Ratio Paramétrico y no Paramétrico Ing. María Florencia Pollo Cattaneo Pág. 312

313 ANÁLISIS DE RESULTADOS OBTENIDOS realizadas. A continuación se vuelcan los análisis de los resultados de todas las pruebas VALORES CON MEDIA EXPERIMENTAL MAYOR QUE LA DE CONTROL (ANÁLISIS POR INTERVALO DE CONFIANZA) En estas pruebas, se observa que en ningún caso los métodos Response Ratio (para métrico y no paramétrico) y el Vote Counting suceda que el tratamiento experimental supere al de control. Para el caso de Diferencia de Medias Ponderadas, en cambio, el tratamiento de experimental supera al de control, esto quiere decir que el efecto final estimado es positivo y bastante distante del cero, lo cual indicaría que el tratamiento Experimental es mejor que el tratamiento de Control. Cuando corroboramos esta información con el intervalo de confianza, encontramos que el mismo no contiene al cero, lo cual indicaría que la mejora del tratamiento Experimental sobre el de Control, es significativa al 90, 95 y 99% (se corrobora para los tres intervalos de confianza tomados), tanto para el efecto individual como para el global. Sin embargo, se observa que el porcentaje de casos en que esto sucede disminuye a medida que aumenta el desvío estándar. Tal es así que, para un desvío estándar muy bajo, el tratamiento experimental supera al de control en casi un 100 %, porcentaje que disminuye hasta casi un 65 % para un desvío estándar muy alto (muy bajo y muy alto teniendo en cuenta los valores tomados para las pruebas). A continuación, en la Tabla ASATA 2, se detallan los resultados obtenidos: Ing. María Florencia Pollo Cattaneo Pág. 313

314 Tabla ASATA 2: resultados de las simulaciones VALORES CON MEDIA EXPERIMENTAL MENOR QUE LA DE CONTROL (ANÁLISIS POR INTERVALO DE CONFIANZA) En estas pruebas, se observa que en ningún caso los métodos Response Ratio (para métrico y no paramétrico) y el Vote Counting suceda que el tratamiento experimental supere al de control. Para el caso de Diferencia de Medias Ponderadas, en cambio, sucede lo contrario que en el caso anterior (punto ), y el tratamiento de experimental no supera al de control, tanto para el efecto individual como para el global. Sin embargo, se observa que el porcentaje de casos en que esto sucede disminuye a medida que aumenta el desvío estándar. Tal es así, que para un desvío estándar muy bajo, el tratamiento experimental NO supera al de control en casi un 100 %, porcentaje que disminuye hasta casi un 60 % para un desvío estándar muy alto, siendo que el tratamiento experimental, entonces, supera al de control en casi un 40 %. A continuación, en la Tabla ASATA 3, se detallan los resultados obtenidos: Comentario [P1]: nuevo Ing. María Florencia Pollo Cattaneo Pág. 314

315 Tabla ASATA 3: resultados de las simulaciones VALORES CON MEDIA EXPERIMENTAL IGUAL QUE LA DE CONTROL (ANÁLISIS POR INTERVALO DE CONFIANZA) En estas pruebas, se observa que, en ningún caso, los métodos Response Ratio (para métrico y no paramétrico) y el Vote Counting sucede que el tratamiento experimental supere al de control. Para el caso de Diferencia de Medias Ponderadas, sin embargo, sucede, y esto es sin importar el porcentaje del desvío estándar, el tratamiento experimental supera al de control la mitad de las veces. A continuación, en la Tabla ASATA 4, se detallan los resultados obtenidos: Tabla ASATA 4: resultados de las simulaciones Ing. María Florencia Pollo Cattaneo Pág. 315

316 RESULTADO DEL ANÁLISIS DE CORRELACIÓN Para el análisis de correlación se puede observar que al comparar el Vote Counting con Diferencia de Medias Ponderadas, el primero demuestra ser más preciso que el segundo, a tal punto que DMP no supera en ningún caso a VC, a lo sumo lo iguala en precisión. Sin embargo, la precisión del VC es mayor cuando se toma valores con media experimental mayor que la de control, y el desvío estándar es bajo. Para media experimental mayor que la de control, a medida que aumenta el desvío estándar, la DMP iguala al VC (aunque nunca lo supera), superando el VC a la DMP en un 60 % de las veces para valores altos de desvío estándar. Para el caso de media de tratamiento experimental menor que el de control, pasa a la inversa: para desvío estándar pequeño, DMP y VC tienen la misma precisión, y a medida que aumenta el desvío estándar, la precisión del VC va superando a la DMP, hasta llegar a casi un 40 % (que es el porcentaje de veces en que el VC supera a la DMP para los mayores valores de desviación estándar). Para el caso de media de tratamiento experimental igual que el de control, la precisión es pareja. Sin embargo, se debe resaltar que en ningún caso, la DMP tiene mayor precisión que el VC. Para el Response Ratio, cualquiera sea el caso, tanto el paramétrico como el no paramétrico tienen la misma precisión. Ing. María Florencia Pollo Cattaneo Pág. 316

317 Capítulo 9 Conclusión y Futuras Líneas de Trabajo Ing. María Florencia Pollo Cattaneo Pág. 317

319 9.- CONCLUSIÓN Y FUTURAS LÍNEAS DE TRABAJO CONCLUSIONES El sistema para análisis de precisión de técnicas de agregación en contextos experimentales poco maduros es una herramienta que facilitará el trabajo en este campo al investigador. Proporciona un medio para evaluar las distintas técnicas de agregación, pudiendo adaptar el método correcto, de acuerdo a las características de la experimentación que está realizando. Por otro lado, el hecho que los valores normalmente distribuidos generados aleatoriamente (y acorde a los parámetros de ajuste seleccionados por el usuario) sean almacenados en un archivo y después se pueda aplicar una o varias técnicas a dicho conjunto de valores da la posibilidad al investigador, no sólo de usar distintas distribuciones normales, sino que además, tiene el valor agregado de poder utilizar un conjunto de valores provenientes de experimentos reales almacenados previamente en un archivo con el formato adecuado. Ing. María Florencia Pollo Cattaneo Pág. 319

320 Tras haber realizado pruebas con la aplicación desarrollada, la tesista pudo comprobar la efectividad del la técnica por Diferencia de Media Ponderadas para el análisis por intervalo de confianza, ya sea para el efecto individual como el global. Las otras técnicas, de acuerdo al análisis por intervalo de confianza, no arrojaron resultados que permitan validar la efectividad o precisión de estas técnicas en contextos poco maduros. Además, se puedo observar cómo varían los resultados con la Diferencia de Medias Ponderadas a medida que se varía el desvío estándar de las poblaciones, punto desarrollado en el capítulo anterior. Si bien, haría falta realizar varias pruebas más, variando las condiciones ya manejadas, estos primeros resultados nos llevan a pensar que, la Diferencia de Medias Ponderadas sería la más adecuada para agregar experimentos en contextos poco maduros. Si bien el análisis de correlación nos da que el Vote Counting produce intervalos más acotados que la Diferencia de Medias Ponderadas (DMP), estos intervalos no son adecuados según el análisis por intervalo de confianza. Esto hace que nos inclinemos por la DMP. Por otro lado, el análisis de correlación no nos dio preferencias respecto a las distintas técnicas de Response Ratio (para métrico y no paramétrico), dando la misma precisión para ambas técnicas. Sin embargo, al no haber arrojado resultados positivos en el análisis por intervalo de confianza, en primera instancia nos inclinamos por dejar estas técnicas por la DMP. Por último, pudimos observar que la DMP varía acorde se modifican los valores de los desvíos estándar, por lo que ésta es una variable a tener en cuenta en el futuro para la realización de nuevas pruebas para analizar mejor las técnicas aquí presentadas, y que el sistema trata para su posterior análisis. Ing. María Florencia Pollo Cattaneo Pág. 320

321 9.2.- FUTURAS LÍNEAS DE TRABAJO Como líneas de investigación futura se han identificado dos aspectos: 1) Evolución del sistema en varios aspectos para aumentar su funcionalidad y ampliar su portabilidad. 2) Realizar nuevas pruebas para seguir incrementando los conocimientos en este campo, algo de lo que se beneficiarían todos los investigadores que desarrollen su experiencia en contextos poco maduros. puntos: Con respecto al primer aspecto identificado, se pueden desarrollar los siguientes 1) Incorporar nuevas técnicas de agregación de experimentos, o incorporar variaciones de las ya implementadas. Así, por ejemplo, para el Response Ratio Paramétrico, en el cálculo de efecto global existen dos versiones: Modelo de Efecto Fijo (que es el que desarrollamos en nuestra aplicación) y Modelo de Efectos Aleatorios (que es una versión que podría implementarse como una opción al aplicar esta técnica). 2) Desarrollar una Base de Datos para administrar en forma más ordenada y eficiente la información. Esto incluiría los conjuntos de valores normalmente distribuidos y los resultados de las aplicaciones de las distintas técnicas a estas distribuciones. Incluso, se podrían tener distribuciones de valores provenientes de experimentos reales. 3) Incorporación de seguridad al sistema, creando roles de usuarios con sus respectivos permisos de acceso. Así, por ejemplo, podría haber usuarios con permiso para acceder a los resultados de experimentos reales, y otros Ing. María Florencia Pollo Cattaneo Pág. 321

322 que solo podrían acceder a las distribuciones generadas por simulación. Podría haber usuarios con permiso para generar nuevas distribuciones, y otros que sólo podrían usar las existentes (permiso dado por el nivel de experiencia del usuario en este tipo de investigaciones). También se incorporaría el perfil de administrador. 4) Agregar funcionalidades que permitan al sistema realizar análisis de los resultados obtenidos al aplicar las distintas técnicas de agregación. Actualmente el sistema aplica las técnicas a un conjunto de valores normalmente distribuidos, generando un reporte con los valores de los intervalos de confianza de los efectos individuales y globales para cada técnica. Es así, que a través de estos reportes (como los de la Tabla IP 23) se pueden compra las distintas técnicas o analizarlas por intervalo de confianza. Lo que proponemos aquí como futura línea de trabajo, agregar una funcionalidad para automatizar estas comparaciones y análisis. Así, por ejemplo, si tenemos una tabla como la siguiente: Ing. María Florencia Pollo Cattaneo Pág. 322

323 Tabla CFLT 1: Tabla con valores de los parámetros para generar valores normalmente distribuidos y aplicar las técnicas de agregación La nueva funcionalidad que proponemos para el sistema, debería poder generar un informe en una tabla similar a la siguiente: Ing. María Florencia Pollo Cattaneo Pág. 323

324 Tabla CFLT 2: Tabla con análisis de los resultados de la agregación Ing. María Florencia Pollo Cattaneo Pág. 324