UNIVERSIDAD POLITÉCNICA DE MADRID INSTITUTO TECNOLÓGICO BUENOS AIRES

Transcripción

1 UNIVERSIDAD POLITÉCNICA DE MADRID INSTITUTO TECNOLÓGICO BUENOS AIRES TESIS DE MAGISTER EN INGENIERÍA DEL SOFTWARE MÉTODO DE ESTIMACIÓN DE ESFUERZO PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN. HERRAMIENTA PARA SU VALIDACIÓN. AUTOR ING. PABLO PYTEL DIRECTORES M. ING. EDUARDO DIEZ (ITBA) M. ING. MARÍA FLORENCIA POLLO CATTANEO (UTN) BUENOS AIRES, JULIO DE 2011

2

3 AGRADECIMIENTOS A mis viejos y hermanos por estar y bancarme siempre. A Flo por ser mi mentora y amiga desde hace 10 años. A Ramón por haberme adoptado en esta nueva vida. A Maxi Tomasello por su gran auxilio en cuestiones de desarrollo. A Paola por su ayuda con los datos de los proyectos. A mis colegas de los grupos de investigación GEMIS (UTN FRBA) y GISI (UNLa) por sus aportes. A todos los que me ayudaron a llegar aquí Ing. Pablo Pytel 3

4

5 TABLA DE CONTENIDOS 1. INTRODUCCIÓN DE QUÉ TRATA ESTA TESIS? A QUIÉN ESTÁ DIRIGIDA? ORGANIZACIÓN DEL DOCUMENTO INTRODUCCIÓN AL PROBLEMA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN MODELOS DE ESTIMACIÓN DE PROYECTOS SOFTWARE MODELOS DE ESTIMACIÓN DE PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN MÉTODO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO) DESCRIPCIÓN FACTORES DE COSTO UTILIZADOS POR DMCOMO Factores de Costo Relacionados a los Datos Factores de Costo Relacionados a los Modelos Factores de Costo Relacionados a la Plataforma Factores de Costo Relacionados a las Técnicas y Herramientas Factores de Costo Relacionados al Proyecto Factores de Costo Relacionados al Personal FÓRMULAS UTILIZADAS POR DMCOMO DEFINICIÓN DEL PROBLEMA SOLUCIÓN PROPUESTA DEFINICIÓN DEL PROCESO DE SIMULACIÓN ANÁLISIS DE RESULTADOS REQUISITOS Y ESTUDIO DE VIABILIDAD DEL SISTEMA INTRODUCCIÓN ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA ESTUDIO DE LA SOLICITUD Descripción General del Sistema Catálogo de Objetivos de la Evaluación del Sistema Software 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 PRE-SELECCIÓ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...74 Ing. Pablo Pytel 5 Tabla de Contenidos

6 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 GESTIÓN DEL PROYECTO INTRODUCCIÓN INICIO DEL PROYECTO ESTIMACIÓN DEL ESFUERZO Estimación del sistema Interpretación de los Resultados PROCESO SOFTWARE Selección del Ciclo de Vida Alcance de los Ciclos de Desarrollo Definición de Mapa de Actividades Planificación de las Actividades GESTIÓN DE CONFIGURACIÓN ESTÁNDARES DE GESTIÓN DE CONFIGURACIÓN ORGANIZACIÓN DE GESTIÓN DE CONFIGURACIÓN ACTIVIDADES DE GESTIÓN DE CONFIGURACIÓN A REALIZAR IMPLEMENTACIÓN DEL PLAN DE GESTIÓN DE CONFIGURACIÓN Asignación de Actividades Auditorías Selección de Repositorio Identificación de la Configuración Administración de Cambios Diseño de Registros Resguardo y Retención de Registros Control de la Configuración PLAN DE ASEGURAMIENTO DE LA CALIDAD OBJETIVOS DEL PLAN DE CALIDAD DEFINICIÓN DE LOS RECURSOS MÉTRICAS DEL PROYECTO Definición de las Métricas Descripción de las Métricas a Aplicar AUDITORÍAS PRIMER CICLO DE DESARROLLO: ANÁLISIS DEL SISTEMA DE INFORMACIÓN INTRODUCCIÓN DEFINICIÓN DEL SISTEMA 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 Ing. Pablo Pytel 6 Tabla de Contenidos

7 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 incluyendo Asociaciones y Agregaciones IDENTIFICACIÓN DE GENERALIZACIONES Descripción de las Generalizaciones Identificadas DEFINICIÓN DE INTERFACES DE USUARIO ESPECIFICACIÓN DE PRINCIPIOS GENERALES DE LA INTERFAZ Principios Generales de la Interfaz ESPECIFICACIÓN DE FORMATOS INDIVIDUALES DE LA INTERFAZ DE PANTALLA MODELO DE NAVEGACIÓN DE INTERFAZ Descripción de las Características Generales de cada Pantallas 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 VERIFICACIÓN DE LOS 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 Integración Pruebas de Sistema Pruebas de Implantación Pruebas de Aceptación 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 Ing. Pablo Pytel 7 Tabla de Contenidos

8 Seguridad Modo de uso 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 INFORMACIÓN CORRESPONDIENTE AL PRIMER CICLO DE DESARROLLO PRIMER CICLO DE DESARROLLO: DISEÑO DEL SISTEMA DEL SISTEMA DE INFORMACIÓN INTRODUCCIÓ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 DEL 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 Usos 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 IDENTIFICACIÓN DE OPERACIONES DE LAS CLASES Operaciones de Clases DIAGRAMA DE CLASES DE DISEÑO ESPECIFICACIÓN DE NECESIDADES DE MIGRACIÓN Y CARGA INICIAL 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 Ing. Pablo Pytel 8 Tabla de Contenidos

9 ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA CORRESPONDIENTE AL PRIMER CICLO DE DESARROLLO 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 PRUEBAS ESPECIFICACIÓN DEL ENTORNO DE PRUEBAS 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 INFORMACIÓN CORRESPONDIENTE AL PRIMER CICLO DE DESARROLLO PRIMER CICLO DE DESARROLLO: CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN INTRODUCCIÓ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 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 DE INTEGRACIÓN EJECUCIÓN DE LAS PRUEBAS DEL SISTEMA REALIZACIÓN DE LAS PRUEBAS DEL SISTEMA Resultado de la Realización de las Pruebas de Sistema EVALUACIÓN DEL RESULTADO DE LAS PRUEBAS DEL SISTEMA Evaluación de los Resultados de las Pruebas de Sistema APROBACIÓN DEL SISTEMA SOFTWARE CORRESPONDIENTE AL PRIMER CICLO DE DESARROLLO SEGUNDO CICLO DE DESARROLLO: ANÁLISIS DEL SISTEMA DE INFORMACIÓN INTRODUCCIÓN ESTABLECIMIENTO DE REQUISITOS ESPECIFICACIÓN DE CASOS DE USO Casos de Uso ANÁLISIS DE LOS CASOS DE USO Ing. Pablo Pytel 9 Tabla de Contenidos

10 8.3.1 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 incluyendo Asociaciones y Agregaciones IDENTIFICACIÓN DE GENERALIZACIONES Descripción de las Generalizaciones Identificadas DEFINICIÓN DE INTERFACES DE USUARIO ESPECIFICACIÓN DE FORMATOS INDIVIDUALES DE LA INTERFAZ DE PANTALLA Modelo de Navegación de Interfaz Descripción de las Características Generales de cada Pantallas 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 VERIFICACIÓN DE LOS MODELOS ANÁLISIS DE CONSISTENCIA ENTRE MÉTODOS Análisis de Consistencia APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN PRESENTACIÓN Y APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN CORRESPONDIENTE AL SEGUNDO CICLO DE DESARROLLO SEGUNDO CICLO DE DESARROLLO: DISEÑO DEL SISTEMA DEL SISTEMA DE INFORMACIÓN INTRODUCCIÓ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 DISEÑO DE CASOS DE USO REALES IDENTIFICACIÓN DE CLASES ASOCIADAS A UN CASO DE USO Clases Asociadas a los Casos de Usos 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 IDENTIFICACIÓN DE OPERACIONES DE LAS CLASES Operaciones de Clases DIAGRAMA DE CLASES DE DISEÑO ESPECIFICACIÓN DE NECESIDADES DE MIGRACIÓN Y CARGA INICIAL DE DATOS Carga Inicial de Datos Ing. Pablo Pytel 10 Tabla de Contenidos

11 9.5 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 CORRESPONDIENTE AL SEGUNDO CICLO DE DESARROLLO ESPECIFICACIÓN TÉCNICA DEL PLAN DE PRUEBAS REVISIÓN DE LA 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 INFORMACIÓN CORRESPONDIENTE AL SEGUNDO CICLO DE DESARROLLO SEGUNDO CICLO DE DESARROLLO: CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN INTRODUCCIÓN 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 DE INTEGRACIÓN EJECUCIÓN DE LAS PRUEBAS DEL SISTEMA REALIZACIÓN DE LAS PRUEBAS DEL SISTEMA Resultado de la Realización de las Pruebas de Sistema EVALUACIÓN DEL RESULTADO DE LAS PRUEBAS DEL SISTEMA Resultado de la Evaluación de los Resultados de las Pruebas de Sistema ELABORACIÓN DE LOS MANUALES DE USUARIO RESULTADO DE LA ELABORACIÓN DE LOS MANUALES DE USUARIO APROBACIÓN DEL SISTEMA SOFTWARE CORRESPONDIENTE AL SEGUNDO CICLO DE DESARROLLO IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA DE INFORMACIÓN INTRODUCCIÓN 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 Ing. Pablo Pytel 11 Tabla de Contenidos

12 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 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 PRESENTACIÓN Y APROBACIÓN DEL SISTEMA SOFTWARE IMPLANTADO APLICACIÓN DEL SISTEMA PARA VALIDAR EL MÉTODO DE ESTIMACIÓN INTRODUCCIÓN PREPARACIÓN DE LOS EXPERIMENTOS DEFINICIÓN DE LOS EXPERIMENTOS PARÁMETROS UTILIZADOS EN LOS EXPERIMENTOS REALIZACIÓN DE LOS EXPERIMENTOS EJECUCIÓN DE LOS EXPERIMENTOS ANÁLISIS DE LOS RESULTADOS ANÁLISIS ESTADÍSTICO GENERAL ANÁLISIS DE FACTORES DE COSTO QUE PRODUCEN MAYOR INCREMENTO DEL ESFUERZO ESTIMADO ANÁLISIS DE FACTORES DE COSTO QUE PRODUCEN MAYOR DISMINUCIÓN DEL ESFUERZO ESTIMADO CONCLUSIONES Y FUTURAS LÍNEAS DE TRABAJO CONCLUSIONES FUTURAS LÍNEAS DE TRABAJO BIBLIOGRAFÍA Y GLOSARIO REFERENCIAS BIBLIOGRÁFICAS ACRÓNIMOS GLOSARIO Ing. Pablo Pytel 12 Tabla de Contenidos

13 APÉNDICES APÉNDICE A: CLASIFICACIÓN DE PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN APÉNDICE B: MÉTODO DE SIMULACIÓN MONTECARLO APÉNDICE C: MANUAL DE USO DEL SISTEMA SOFTWARE APÉNDICE D: REGISTROS DE LA GESTIÓN DEL PROYECTO Ing. Pablo Pytel 13 Tabla de Contenidos

14

15 CAPÍTULO 1 INTRODUCCIÓN

16

17 1. INTRODUCCIÓN 1.1. DE QUÉ TRATA ESTA TESIS? Esta tesis trata sobre la construcción de una herramienta de software que ayude a validar el método de estimación de esfuerzo para proyectos de Explotación de Información denominado Método Matemático Paramétrico de Estimación para Proyectos de Data Mining (DMCoMo) que ha sido propuesto en [Marbán, 2003; Marbán et al., 2003]. La herramienta está pensada para ser aplicada directamente al campo de Explotación de Información en el marco de la Ingeniería de Software. El objetivo principal de la herramienta generada es facilitar la generación un banco de pruebas con las características de proyectos de Explotación de Información relevantes para el método de estimación, y así luego analizar el comportamiento del método de estimación seleccionado. Dicha herramienta se construye utilizando la metodología para desarrollo de software Métrica Versión III [Métrica III, 2000] y aplicando el paradigma de desarrollo orientado a objetos A QUIÉN ESTÁ DIRIGIDA? El trabajo se encuentra dirigido principalmente a Ingenieros de Software y cátedras universitarias vinculadas a la Ingeniería de Software, que se dediquen al estudio de Proyectos de Explotación de Información ORGANIZACIÓN DEL DOCUMENTO El material se divide en 15 capítulos que abarcan la totalidad del trabajo de tesis los cuales pueden ser divididos en cinco grandes grupos, que se explican brevemente a continuación: Introducción: El capítulo 1 Introducción (el presente capítulo) define los objetivos del presente trabajo de 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 sobre métodos de estimación en proyectos software en general y de proyectos de explotación de información en particular, mostrando así el contexto que da origen al trabajo de tesis.

18 El capítulo 3 Requisitos y Estudio de Viabilidad del Sistema, comprende la documentación resultante del proceso Estudio de la Viabilidad del Sistema (EVS) 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 catálogo de requisitos funcionales y no funcionales, el estudio de las diferentes alternativas de solución, y la selección de la alternativa más adecuada. El capítulo 4 Gestión del Proyecto, contiene la documentación referente a las interfaces provista por Métrica Versión III para Gestión del proyecto, Gestión de la configuración, y Aseguramiento de la calidad. Esto incluye la estimación del sistema software a desarrollo, la selección del modelo de ciclo de vida con su mapa de actividades y la planificación de estas actividades Primer Ciclo de Desarrollo: El capítulo 5 Primer Ciclo de Desarrollo: Análisis del Sistema de Información, comprende la documentación resultante del proceso Análisis del Sistema de Información (ASI) de la metodología Métrica Versión III para los requerimientos comprendidos dentro del alcance del primer ciclo de desarrollo. La documentación cubre el modelado en UML (Unified Modelling Language) del negocio, los casos de uso (documentados en el formato sugerido por Larman Craig), 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 las verificaciones de los elementos generados por la fase de análisis y el diseño del plan de pruebas. El capítulo 6 Primer Ciclo de Desarrollo: Diseño del Sistema de Información, comprende la documentación resultante del proceso Diseño del Sistema de Información (DSI) de la metodología Métrica Versión III para el primer ciclo de desarrollo. La documentación cubre el modelado en UML del diseño arquitectónico del sistema, así como la estructura y comportamiento del mismo en términos de clases de diseño. Dentro de este capítulo también se incluyen las verificaciones de los elementos generados por la fase de diseño y el diseño de las pruebas incluidas en el plan de pruebas. El capítulo 7 Primer Ciclo de Desarrollo: Construcción del Sistema de Información, comprende la documentación resultante del proceso Construcción del Sistema de Información (CSI) de la metodología Métrica Versión III para el primer ciclo de desarrollo. La documentación cubre la descripción del entorno de construcción y los resultados de las pruebas unitarias, de integración y del sistema. Ing. Pablo Pytel 18 Introducción

19 Segundo Ciclo de Desarrollo: El capítulo 8 Segundo Ciclo de Desarrollo: Análisis del Sistema de Información, comprende la documentación resultante del proceso Análisis del Sistema de Información (ASI) de la metodología Métrica Versión III basado en los resultados del primer ciclo de desarrollo y los requerimientos que se encuentran dentro del alcance del segundo ciclo de desarrollo. El capítulo 9 Segundo Ciclo de Desarrollo: Diseño del Sistema de Información, comprende la documentación resultante del proceso Diseño del Sistema de Información (DSI) de la metodología Métrica Versión III para el segundo ciclo de desarrollo. El capítulo 10 Segundo Ciclo de Desarrollo: Construcción del Sistema de Información, comprende la documentación resultante del proceso Construcción del Sistema de Información (CSI) de la metodología Métrica Versión III para el segundo ciclo de desarrollo. Implantación y Análisis de Resultados: El capítulo 11 Implantación y Aceptación del Sistema de Información, comprende la documentación resultante del proceso Implantación y Aceptación del Sistema (IASI) de la metodología Métrica Versión III implementada cuando los ciclos de desarrollo han finalizado. 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 12 Aplicación del Sistema para Validar el Método de Estimación, explica cómo se utiliza el sistema software desarrollado para realizar experimentos y exponer el resultado de las mismas, así como también al análisis de los resultados para establecer la precisión del método de estimación propuesto para proyectos de explotación de información. El capítulo 13 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. Información Complementaria: El capítulo 14 Bibliografía y Glosario, contiene las referencias bibliográficas utilizadas para el trabajo de tesis, así como los acrónimos y el glosario con los términos empleados en el mismo. Ing. Pablo Pytel 19 Introducción

20 El Apéndice, contiene documentación anexa al contenido de la tesis como son: - Apéndice A: la clasificación de los proyectos de explotación de información utilizado para analizar el método DMCoMo, - Apéndice B: una descripción del método de simulación Montecarlo, - Apéndice C: el manual de uso del sistema software generado, y - Apéndice D: los registros de gestión del proyecto, gestión de configuración y gestión de calidad obtenidos al finalizar el proyecto. Ing. Pablo Pytel 20 Introducción

21 CAPÍTULO 2 INTRODUCCIÓN AL PROBLEMA

22

23 2. INTRODUCCIÓN AL PROBLEMA 2.1. PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN La Inteligencia de Negocio propone un abordaje interdisciplinario (dentro del que se encuentra la Informática), que se centra en generar conocimiento que contribuya con la toma de decisiones de gestión y generación de planes estratégicos en las organizaciones [Thomsen, 2003]. La Explotación de Información (en inglés Information Mining, IM) es la sub-disciplina Informática que aporta a la Inteligencia de Negocio [Negash & Gray, 2008] las herramientas de análisis y síntesis para extraer conocimiento no trivial que se encuentra (implícitamente) en los datos disponibles de diferentes fuentes de información [Schiefer et al., 2004]. Dicho conocimiento es previamente desconocido y puede resultar útil para algún proceso [Stefanovic et al., 2006]. Para un experto, o para el responsable de un sistema software, normalmente no son los datos en sí lo más relevante, sino el conocimiento que se encierra en sus relaciones, fluctuaciones y dependencias. Identificado el problema de inteligencia de negocio, un ingeniero de explotación de información decide la secuencia de procesos de explotación de información que deben ser ejecutados para obtener una solución al problema de inteligencia de negocio [Rodríguez et al., 2010]. Un proceso de Explotación de Información puede definirse como un conjunto de tareas relacionadas lógicamente [Curtis et al., 1992], el cual engloba un conjunto de técnicas de Minería de Datos (en inglés Data Mining, DM) que pueden ser elegidas para realizarlas y así lograr extraer de conocimiento procesable, implícito en el almacén de datos (en inglés Data Warehouse, DW) de la organización. Las bases de estas técnicas se encuentran en el análisis estadístico y en los sistemas inteligentes. Así se aborda la solución a problemas de predicción, clasificación y segmentación [Umapathy, 2007]. Por esta razón ha sido necesario disponer de métodos eficientes para la búsqueda de conocimiento en datos mediante el desarrollo de algoritmos y herramientas para la explotación de información. En cuanto al desarrollo de estos algoritmos y herramientas se necesita de una metodología que lo asista. Es decir, es necesaria una metodología que permita gestionar el proceso de construcción de un Sistema de Explotación de Información en una manera uniforme. Sin embargo, las metodologías para software convencional no consideran adecuados para empresas que se dedican a llevar a cabo proyectos de explotación de información [Vanrell et al., 2010]. Por lo que existen metodologías que acompañan el desarrollo de proyectos de explotación de información. La comunidad científica considera probadas a las metodologías CRISP-DM, SEMMA y P 3 TQ [Britos, 2008], las cuales se describen brevemente a continuación [Pollo-Cattaneo et al., 2009]. Ing. Pablo Pytel 23 Introducción al Problema

24 La metodología CRISP-DM [Chapman et al., 2000] ha evolucionado para resolver los problemas que las organizaciones tienen a la hora de desarrollar proyectos de explotación de información. Así CRISP-DM define los procesos y tareas que se deben realizar para desarrollar en forma exitosa un proyecto de explotación de información. Estos procesos y tareas se encuentran divididos en cuatro niveles de abstracción, organizándolas de forma jerárquica que van desde el nivel más general hasta los casos más específicos (ver figura IP 1). Figura IP 1. Esquema de los cuatro niveles de abstracción de la metodología CRISP-DM En el nivel más general, el proceso está organizado en seis fases, estando cada fase a su vez estructurada en varias tareas generales de segundo nivel o subfases. Las tareas generales se proyectan a tareas específicas, donde se describen las acciones que deben ser desarrolladas para situaciones específicas. Así si en el segundo nivel se tiene la tarea general limpieza de datos, en el tercer nivel se dicen las tareas que tienen que desarrollarse para un caso específico, como por ejemplo, limpieza de datos numéricos, o limpieza de datos categóricos. El cuarto nivel recoge el conjunto de acciones, decisiones y resultados sobre el proyecto de Explotación de Información específico. En la tabla IP 1, se indican las fases que componen la metodología CRISP-DM y cómo se componen cada una de ellas. FASE 1. COMPRENSIÓN DEL NEGOCIO SUBFASES ASOCIADAS 1.1 Determinar los objetivos de negocio 1.2 Evaluar la situación TAREAS ASOCIADAS Antecedentes Objetivos de negocio Criterios de éxito del negocio Evaluar la situación Requisitos, supuestos y limitaciones Riesgos y contingencias Terminología Costos y beneficios Ing. Pablo Pytel 24 Introducción al Problema

25 FASE SUBFASES ASOCIADAS 1.3 Determinar objetivos explotación de información 1.4 Producir el plan del proyecto 2.1 Recolección inicial de datos TAREAS ASOCIADAS Objetivos de explotación de información Criterios de éxito de la de explotación de información Plan del proyecto Evaluación inicial de herramientas y técnicas Informe inicial de recopilación de datos 2. ENTENDIMIENTO DE LOS DATOS 3. PREPARACION DE DATOS 2.2 Descripción de los datos Informe de descripción de datos 2.3 Exploración de los datos Informe de exploración de datos 2.4 Verificación de calidad de los datos 3.0 Tareas preparatorias Informe de calidad de datos Conjunto de datos Descripción del conjunto de datos 3.1 Selección de datos Justificación de la inclusión / exclusión 3.2 Limpieza de datos Informe de limpieza de datos 3.3 Construcción de datos Atributos derivados Registros generados 3.4 Integración de los datos Datos combinados 3.5 Formato de datos Datos reformateadas 4. MODELADO 5. EVALUACIÓN 4.1 Selección de la técnica de modelado 4.2 Generación del diseño del ensayo 4.3 Construcción del modelo 4.4 Evaluación del modelo 5.1 Evaluar los resultados Técnica de Modelado Supuestos del modelado Prueba de diseño Configuración de parámetros Modelos Descripción del modelo Evaluación del modelo Revisión de la configuración de parámetros Evaluación de los resultados de la explotación de información con respecto a los criterios de éxito del negocio Modelos aprobados 5.2 Proceso de revisión Revisión del proceso 5.3 Determinación de los próximos pasos Lista de posibles acciones Decisión Ing. Pablo Pytel 25 Introducción al Problema

26 FASE 6. IMPLANTACION SUBFASES ASOCIADAS 6.1 Plan de implantación 6.2 Plan de vigilancia y mantenimiento TAREAS ASOCIADAS Ejecución del plan de implantación Ejecución del plan de monitoreo y mantenimiento 6.3 Producción final Informe final Presentación final 6.4 Revisión del proyecto Documentación de la experiencia Tabla IP 1. Tareas de cada fase de la metodología CRISP-DM Por otro lado, la metodología SEMMA [SAS, 2008] se la define como el proceso de selección, exploración y modelado de grandes cantidades de datos para descubrir patrones de negocio desconocidos. El nombre de esta terminología es el acrónimo correspondiente a las cinco fases básicas del proceso en inglés sample, explore, modify, model, assess (o muestreo, exploración, modificación, modelado, valoración en castellano) como se puede ver en la figura IP 2. Figura IP 2. Fases de la metodología SEMMA El proceso se inicia con la definición de la población muestral sobre la que se va a aplicar el análisis a través de un muestreo aleatorio simple. La metodología SEMMA establece que para cada muestra considerada para el análisis del proceso se debe asociar un nivel de confianza de la muestra. Una vez determinada una muestra (o conjunto de muestras) representativas de la población en estudio, se debe proceder a una exploración de la información disponible con el fin de simplificar en lo posible el problema para optimizar la eficiencia del modelo. Para lograr este objetivo se propone la utilización de herramientas de visualización o de técnicas estadísticas que ayuden a poner de manifiesto relaciones entre variables. La tercera fase de la metodología consiste en la manipulación de los datos, en base a la exploración realizada, para que definan y tengan el formato adecuado los datos que serán introducidos en el modelo. Luego se procede al análisis y modelado de los datos. El objetivo de esta fase consiste en establecer una relación entre las variables explicativas y las variables objeto del estudio, que posibiliten inferir el valor de las mismas con un nivel de confianza determinado. Finalmente, la última fase del proceso Ing. Pablo Pytel 26 Introducción al Problema

27 consiste en la valoración de los resultados mediante el análisis de bondad del modelo o modelos, contrastado con otros métodos estadísticos o con nuevas poblaciones muestrales. Esta dinámica se puede ver gráficamente en la figura IP 3. Figura IP 3. Dinámica de la metodología SEMMA Finalmente, la metodología P 3 TQ [Pyle, 2003] es una abreviatura de Product, Place, Price, Time, Quantity (o Producto, Ubicación, Precio, Tiempo, Cantidad en castellano) y está compuesta por dos modelos, el Modelo de Negocio y el Modelo de Explotación de Información. El Modelo de Negocio (MII) proporciona una guía de pasos para el desarrollo y la construcción de un modelo que permita identificar un problema de negocio o la oportunidad del mismo. Mientras que el Modelo de Explotación de Información (MIII) proporciona una guía pasos para la ejecución de los modelos de Explotación de Información de acuerdo al modelo identificado en MII (modelado). Cada una de los modelos está estructurado en base a: una caja de actividades que indican una serie de pasos a realizar, una caja de descubrimientos que proveen acciones de exploración que se necesitan para poder decidir qué hacer en el próximo paso, una caja de técnicas que proporciona información suplementaria sobre los pasos recomendados en las cajas de descubrimiento o de acción y una caja de ejemplos que dan una descripción detallada de cómo usar una técnica específica, estas cajas se aplican en el Modelo de Explotación de Información. Las fases de la metodología P3TQ se presentan en la figura IP 4. Ing. Pablo Pytel 27 Introducción al Problema

28 Figura IP 4: Fases de la metodología P 3 TQ Resumiendo, al considerar al proceso de desarrollo, de las tres metodologías sólo una identifican técnicas de explotación de información utilizables [Britos, 2008]: CRISP-DM identifica problemas de inteligencia de negocio y hace una caracterización parcialmente abstracta de los mismos problemas de inteligencia de negocio ni formulan una caracterización abstracta de los mismos, pero SEMMA y P 3 TQ no identifican relaciones entre técnicas de explotación de información y problemas de inteligencia de negocio, ni procesos de explotación de información. Por otro lado, las tres metodologías dejan de lado aspectos a nivel gestión de los proyectos y de empresa [Vanrell et al., 2010]. En estas metodologías se observa la falta de herramientas que permitan soportar de forma completa las fases de administración de proyecto, a pesar que se encuentran algunas definiciones de tareas o actividades que pertenecen a este proceso como puede ser la construcción de un plan de desarrollo, definir el protocolo de entrega con el cliente, establecer el equipo de trabajo, definir el plan de manejo de riesgos, entre otras. Ing. Pablo Pytel 28 Introducción al Problema

29 2.2. MODELOS DE ESTIMACIÓN DE PROYECTOS SOFTWARE Al comenzar la gestión de todo proyecto de software es necesario realizar las actividades que se denominan planificación del proyecto. Esto incluye calcular el costo (o esfuerzo) del proyecto para lo cual es necesario realizar una estimación: del trabajo a ejecutar, de los recursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su realización [Pressman, 2004]. Así, la construcción de métodos de estimación de proyectos de software que logren resultados predictivos sobre los recursos a emplear que se ajusten de la mejor manera posible a la realidad obtenible, es un problema abierto en el campo de los sistemas de información [Rodríguez et al., 2010]. El proceso de estimación de un proyecto software está formado por un conjunto de técnicas y procedimientos que se usan en la organización para poder llegar a una predicción fiable. Éste es un proceso continuo, que debe ser usado y consultado a lo largo de todo el ciclo de vida del proyecto y que se divide en los siguientes pasos [Agarwal & Kumar, 2001]: 1) Estimación del tamaño. 2) Estimación del costo y del esfuerzo. 3) Estimación de la programación temporal. 4) Estimación de la cantidad de recursos computacionales. 5) Asunción de riesgos. 6) Inspección y aprobación. 7) Redacción de informes de estimación Se puede decir que toda técnica de estimación de un proyecto software pertenece a una de estas tres categorías [Bielak, 2000]: Modelos Analíticos que a través de la aplicación de métodos de regresión en datos históricos describen las relaciones matemáticas entre las variables del proyecto. Técnicas basadas en Teorías que consideran las bases teóricas del proceso de desarrollo de software. Técnicas Empíricas que incluyen la observación y entendimiento de esfuerzos históricos de proyectos concluidos para predecir esfuerzos futuros. A continuación se describen brevemente las técnicas de estimación software más utilizadas [Bielak, 2000]: Ing. Pablo Pytel 29 Introducción al Problema

30 COCOMO El método de COCOMO (COnstructive COst MOdel, o Modelo de Costos de Construcción en castellano) [Boehm, 1981] y el método COCOMO II (o COCOMO versión 2) [Boehm et al., 1995; Boehm et al., 2000] son técnicas de estimación analítica muy utilizadas y conocidas. Este modelo estima el esfuerzo, planificación y costo requerido para desarrollar un producto software aplicando ecuaciones matemáticas (basadas en la regresión de datos históricos) para calcular el tiempo y costo. En estas ecuaciones de consideran los factores de costo como son la experiencia del equipo, el tipo de sistema desarrollado, el tamaño del sistema, atributos no funcionales, etc. SLIM El método SLIM (Software LIfecycle Management, o Administración de Ciclo de Vida de Software) [Putman, 1978; Putnam et al., 2000] es una técnica de estimación basada en teorías que usa dos ecuaciones para calcular el esfuerzo de desarrollo y planificación requerido. La primera ecuación, derivada de la observación empírica de niveles de productividad, expresa el esfuerzo de desarrollo en términos de tamaño de proyecto y tiempo de desarrollo. Por otro lado, la segunda ecuación expresa los recursos humanos requeridos en función del tiempo de desarrollo. Delphi El método Delphi [Boehm, 1981; Wiegers, 2000] utiliza técnicas para descomponer el proyecto en actividades individuales de trabajo, permitiendo a los expertos generar estimaciones individuales para cada una de ellas y así generar un consenso en la estimación del proyecto. Esta estimación por analogía incluye examinar similitudes y diferencias entre esfuerzos anteriores y actuales para extrapolar la calidad de las medidas históricas a las estimaciones futuras. SSM El método SSM (Software Sizing Model, o Modelo de Tamaño de Software) [Bozoki, 1991] descompone al proyecto en módulos individuales para estimar el tamaño relativo de los módulos del sistema software a través de comparaciones de pares, de la identificación de los tamaños posibles más pequeño y más grande y técnicas de ordenamiento. Las estimaciones son ajustadas para las condiciones del proyecto al incluir al menos dos módulos de referencias de tamaño conocido. La técnica define un tamaño por cada módulo y para el proyecto completo. Ing. Pablo Pytel 30 Introducción al Problema

31 Puntos de Función La técnica de Puntos de Función [Albrecht, 1983] mide el tamaño del proyecto en función de las funcionalidades provistas por el sistema, independientemente del lenguaje de implementación. La técnica de puntos de función considera la estimación empírica [Fairley, 1992] dada por la relación observada entre el esfuerzo requerido para construir el sistema y las características del sistema identificadas, tales como entradas externas, archivos de interface, salidas, consultas y archivos lógicos internos. La cantidad para cada una de estas características son ajustadas a través de la ponderación y de factores de complejidad para obtener un tamaño expresado en puntos de función. Aunque esta técnica fue desarrollada originalmente para el paradigma de desarrollo estructurado, también puede ser utilizado en el paradigma de desarrollo orientado a objetos [Fetcke et al., 1998] MODELOS DE ESTIMACIÓN DE PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN Los proyectos de explotación de información no escapan a la necesidad de estimar el esfuerzo necesario para la construcción del sistema y la planificación de las actividades necesarias. Por ejemplo la metodología CRISP-DM también requiere de un proceso de planificación que se encuentra definido dentro de la tarea Producir el plan del proyecto en la fase de "Comprensión del Negocio, pero no propone ningún mecanismo, técnica ni herramienta para realizar dicha estimación [Rodríguez et al., 2010]. Dada las diferencias que existen entre un proyecto convencional de construcción de software y un proyecto de explotación de información, los métodos usuales de estimación no son aplicables ya que los parámetros a ser utilizados son de naturalezas diferentes [Marbán et al., 2003]. Por ejemplo, las herramientas de estimación de software convencional como COCOMO II, SLIM o PRICE-S [LLC PRICE, 1998] utilizan como parámetros la cantidad de líneas de código, la experiencia del equipo de trabajo, características de la plataforma de desarrollo, entre otras. Sin embargo, en proyectos de explotación de información existen otras características que deben ser consideradas para la estimación que las herramientas de ingeniería en software no consideran, como por ejemplo, cantidad de fuentes de información, nivel de integración de los datos, el tipo de problema a ser resueltos, entre las más representativas de este tipo de proyectos. Por lo tanto, ha sido necesario desarrollar métodos específicos ad-hoc de estimación de carga de trabajo para proyectos de explotación de información. Luego de una búsqueda documental se ha encontrado uno de naturaleza analítico denominado Método Matemáti- Ing. Pablo Pytel 31 Introducción al Problema

32 co Paramétrico de Estimación para Proyectos de Data Mining (DMCoMo) [Marbán, 2003; Marbán et al., 2003], el cual es descripto a continuación MÉTODO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO) DESCRIPCIÓN En [Marbán, 2003] se define un método analítico de estimación para proyectos de explotación de información el cual se denomina Matemático Paramétrico de Estimación para Proyectos de Data Mining (en inglés Data Mining COst MOdel, o DMCoMo). Los métodos analíticos de estimación utilizan ecuaciones matemáticas para obtener el costo o esfuerzo de desarrollo medido normalmente en meses/hombres (o sea, una estimación de cuantos meses serían necesarios para desarrollar el sistema si lo realizaría una única persona). Para realizar este cálculo son utilizados un conjunto de parámetros que describen las características del proyecto a los y que se denominan factores de costo (o cost drivers en inglés). El método DMCoMo es un modelo de estimación de esfuerzo paramétrico de la familia de COCOMO II que permite estimar los meses/hombre que serán necesarios para desarrollar un proyecto de explotación de información desde su concepción hasta su puesta en marcha. Para realizar la estimación, DMCoMo define una serie de factores de costo los cuales están vinculados a las características más importantes de los proyectos de explotación de información, que se clasifican en seis categorías. Estas categorías (indicadas en la tabla IP 2) se describen en detalle en la sección con cada uno de los factores de costo definidos y utilizados por el método DMCoMo. CATEGORÍA DATOS DESCRIPCIÓN Agrupa los factores de costo que tienen que ver con la cantidad y la calidad de los datos a tratar en el proyecto de explotación de información, también se agrupan bajo esta clasificación todos los factores relativos a modelos de datos y a sistemas gestores de bases de datos en los que se pueden encontrar los datos objetivos del análisis. Esta categoría, a su vez, cuenta con las siguientes subcategorías: - Datos Iniciales - Dispersión Ing. Pablo Pytel 32 Introducción al Problema

33 CATEGORÍA MODELOS DESCRIPCIÓN - Calidad de los Datos - Disponibilidad del Modelo de Datos - Nivel de Privacidad de los Datos Incluye todas aquellas características o factores de costo que tienen que ver con los modelos que hay que generar y que tienen en cuenta el volumen de datos que se va a utilizar para generar los modelos, la disponibilidad de técnicas para generar los modelos y la dificultad del mismo. Esta categoría no utiliza ninguna sub-categoría. PLATAFORMA TÉCNICAS Y HERRAMIENTAS Agrupa los factores de costo que tienen que ver con las características de los almacenes de datos y su localización. Esta categoría no utiliza ninguna sub-categoría. Agrupa las características de las técnicas y herramientas de explotación de información que se van a utilizar en el proyecto. Estas características se centran principalmente en el nivel de formación que requieren, la amigabilidad de las mismas y el número de técnicas que soportan. Esta categoría no utiliza ninguna sub-categoría. PROYECTO Agrupa aquellas características relativas a los departamentos y a las localizaciones para las que se desarrolla el proyecto de explotación de información. También incluye características acerca de la documentación que es necesario generar durante la realización del proyecto. Esta categoría no utiliza ninguna sub-categoría. PERSONAL (STAFF) Incluye aquellos factores relacionados con el equipo de trabajo que participa en el proyecto (dirección, implementadores, expertos, etc.). Estos factores evalúan el conocimiento y la capacidad requerida para llevar a cabo cada una de las tareas del proyecto Esta categoría no utiliza ninguna sub-categoría. Tabla IP 2. Categorías de Factores de Costo utilizadas por DMCoMo Una vez que los valores de los factores de costo son definidos para el proyecto a estimar, se ingresan estos valores en las ecuaciones suministradas por el método. El método DMCoMo dispone de dos ecuaciones, una que utiliza 23 factores de costo como variables que puede ser utilizada cuando el proyecto está bien definido y otra de 8 factores de cos- Ing. Pablo Pytel 33 Introducción al Problema

34 to como variables que puede utilizarse cuando no todos los datos del proyecto se encuentran definidos (ambas fórmulas son descriptas en la sección 2.4.3). Como resultado de ingresar los valores a la ecuación correspondiente, se obtiene la cantidad de meses/hombre correspondiente al proyecto FACTORES DE COSTO UTILIZADOS POR DMCOMO En las sub-secciones siguientes se describen cada uno de los factores de costo considerados por el método DMCoMo. Por cada uno de los factores, se define un rango de valores con un valor numérico relacionado el cual se ingresa en las fórmulas definidas en la sección Para denominar el rango de valores se utiliza la siguiente nomenclatura. - XB = Extra Bajo - MB = Muy Bajo - B = Bajo - N = Nominal - A = Alto - MA = Muy Alto - EA = Extra Alto Factores de Costo Relacionados a los Datos Esta categoría incluye los siguientes factores de costo los cuales se encuentran agrupados en seis sub-categorías que se detallan a continuación: Datos Iniciales Esta subcategoría incluye las características correspondientes al volumen inicial de datos disponible, antes de comenzar el proyecto, y define los factores de costo Cantidad de Tablas (NTAB), Cantidad de Tuplas de las Tablas (NTUP) y Cantidad de Atributos de las Tablas (NATR) que se describen a continuación. Cantidad de Tablas (NTAB) Este factor hace referencia a la cantidad inicial de tablas que se tendrán en consideración al comienzo del proyecto, y que serán las fuentes u orígenes de datos (archivos, bases de datos, etc.). En la tabla IP 3 se describen los posibles valores para este factor. Ing. Pablo Pytel 34 Introducción al Problema

35 Rango Descripción Valor XB Hasta 20 tablas 0 MB De 20 a 60 tablas 1 B De 60 a 80 tablas 2 N De 80 a 100 tablas 3 A De 100 a 120 tablas 4 MA De 120 a 300 tablas 5 EA Más de 300 tablas 6 Tabla IP 3. Posibles Valores del Factor NTAB Cantidad de Tuplas de las Tablas (NTUP) Este factor considera la cantidad total de tuplas que contienen las tablas que se van a tener en cuenta a la hora de comenzar el proyecto. En la tabla IP 4 se describen los posibles valores para este factor. Rango Descripción Valor MB Hasta 5 x 10 7 tuplas 1 B De 5 x 10 7 tuplas a 10 x 10 7 tuplas 2 N De 10 x 107 tuplas a 20 x 10 7 tuplas 3 A De 20 x 10 7 tuplas a 50 x 10 7 tuplas 4 MA Más de 50 x 10 7 tuplas 5 Tabla IP 4. Posibles Valores del Factor NTUP Cantidad de Atributos de las Tablas (NATR) Este factor considera la cantidad total de atributos que contienen las tablas que se van a tener en cuenta a la hora de comenzar el proyecto. En la tabla IP 5 se describen los posibles valores para este factor. Rango Descripción Valor MB Hasta 500 atributos 1 B De 500 a 1000 atributos 2 N De 1000 a 1500 atributos 3 A De 1500 a 2000 atributos 4 MA Más de 2000 atributos 5 Tabla IP 5. Posibles Valores del Factor NATR Ing. Pablo Pytel 35 Introducción al Problema

36 Dispersión Esta subcategoría incluye la dispersión de los datos disponibles, utilizando un único factor de costo Grado de Dispersión de Datos (DISP) que se describe a continuación. Grado de Dispersión de Datos o Cantidad de Diferentes de Valores de los Atributos (DISP) Este factor considera la cantidad de valores diferentes que pueden tomar los atributos en un proyecto de explotación de información. Para poder determinar los valores de este factor se utiliza la fórmula estadística de la entropía de la información definida por [Shannon & Weaver, 1949] la cual se indica como: = ( ) Dónde: P i es la probabilidad del elemento. M es la cantidad de elementos que aparecen en el sistema. Considerando el resultado de la fórmula, en la tabla IP 6 se describen los posibles valores para este factor. Rango Descripción Valor MB 0 H < 0,2 1 B 0,2 H < 0,4 2 N 0,4 H < 0,6 3 A 0,6 H < 0,8 4 MA 0,8 H 1 5 Tabla IP 6. Posibles Valores del Factor DISP Calidad de los Datos Esta subcategoría incluye un único factor, el Porcentaje de Valores NULL (PNUL) que considera la calidad de los datos a ser utilizados y que es descripto a continuación. Porcentaje de Valores NULL (PNUL) Este factor considera el porcentaje de valores nulos (NULL) o indefinidos en los atributos de las tablas que influirán para el desarrollo de un proyecto de explotación de informa- Ing. Pablo Pytel 36 Introducción al Problema

37 ción, puesto que hay que decidir que se hace con esos valores para la correcta definición del problema a resolver. Algunas de las posibles acciones a tomar son: - Eliminar las tuplas con valores nulos. - Eliminar únicamente los atributos con muchos nulos. - Asignar a los valores nulos un valor utilizando un modelo predictivo. En la tabla IP 7 se describen los posibles valores para este factor. Rango Descripción Valor MB Hasta 10% de valores NULL 1 B De 10 a 15% de valores NULL 2 N De 15 a 20% de valores NULL 3 A De 20 a 25% de valores NULL 4 MA Más de 25% de valores NULL 5 Tabla IP 7. Posibles Valores del Factor PNULL Disponibilidad del Modelo de Datos Esta subcategoría incluye la disponibilidad de los modelos de datos disponibles, utilizando un único factor de costo Grado de Documentación de las Fuentes de Información (DMOD) que se describe a continuación. Grado de Documentación de las Fuentes de Información (DMOD) Este factor considera el grado de documentación de las fuentes (bases de datos, archivos, etc.) que se utilizarán para el proyecto de explotación de información. En la tabla IP 8 se describen los posibles valores para este factor. Rango Descripción Valor XB Todos los modelos 0 MB 90% de los modelos 1 B De 80 a 90% de los modelos 2 N De 70 a 80% de los modelos 3 A De 60 a 70% de los modelos 4 MA Menos del 60% de los modelos 5 Tabla IP 8. Posibles Valores del Factor DMOD Ing. Pablo Pytel 37 Introducción al Problema

38 Nivel de Privacidad de los Datos Esta subcategoría incluye la necesidad de utilizar fuentes externas en caso de requerir datos privados por lo que se define un único factor de costo Necesidad de Adquisición de Datos Externos (DEXT) que se describe a continuación. Necesidad de Adquisición de Datos Externos (DEXT) Este factor considera el grado de utilización de fuentes de datos externas (reportes en papel, archivos externos, bases de datos, etc.), en el caso de que fuera necesario. En la tabla IP 9 se describen los posibles valores para este factor. Rango Descripción Valor B De 1 a 3 fuentes externas de datos 2 N De 3 a 5 fuentes externas de datos 3 A De 5 a 7 fuentes externas de datos 4 MA Más de 7 fuentes externas de datos 5 Tabla IP 9. Posibles Valores del Factor DEXT Factores de Costo Relacionados a los Modelos Esta categoría incluye los factores de costo que se detallan a continuación: Cantidad de Modelos (NMOD) Este factor considera la cantidad estimada de modelos a generar en el proyecto de explotación de información. En la tabla IP 10 se describen los posibles valores para este factor. Rango Descripción Valor B De 1 a 3 modelos 2 N De 3 a 5 modelos 3 A De 5 a 7 modelos 4 MA Más de 7 modelos 5 Tabla IP 10. Posibles Valores del Factor NMOD Tipo de Modelos (TMOD) Este factor considera el tipo o tipos de modelos a generar en el proyecto de explotación de información. Ing. Pablo Pytel 38 Introducción al Problema

39 Para ello se utiliza la siguiente clasificación de modelos: - Modelos Descriptivos: - Asociación. - Particionamiento (Clustering). - Patrones Secuenciales. - Modelos Predictivos: - Clasificación. - Predicción, Estimación o Series Temporales. En la tabla IP 11 se describen los posibles valores para este factor. Rango Descripción Valor MB Modelo Descriptivo: Asociación 1 B Modelo Descriptivo: Partición (Clustering) 2 N Modelo Descriptivo: Patrones Secuenciales 3 A Modelo Predictivo: Clasificación 4 MA Modelo Predictivo: Predicción, Estimación o Series Temporales Tabla IP 11. Posibles Valores del Factor TMOD 5 Cantidad de Tuplas de los Modelos (MTUP) Este factor considera la cantidad estimada de tuplas que utilizarán los modelos a generar. En la tabla IP 12 se describen los posibles valores para este factor. Rango Descripción Valor MB Hasta 5 x 10 6 tuplas 1 B Entre 5 x 10 6 tuplas y 10 x 10 6 tuplas 2 N Entre 10 x 10 6 tuplas y 20 x 10 6 tuplas 3 A Entre 20 x 10 6 tuplas y 50 x 10 6 tuplas 4 MA Más de 50 x 10 6 tuplas 5 Tabla IP 12. Posibles Valores del Factor MTUP Ing. Pablo Pytel 39 Introducción al Problema

40 Cantidad y Tipos de los Atributos por cada Modelo (MATR) Este factor de costo a su vez se divide en dos, uno para la cantidad de atributos (MATRn) y otro para el tipo de atributo (MATRt) los cuales se combinan con la siguiente fórmula para calcular el valor del atributo MATR: = + 2 A continuación se definen los factores MATRn y MATRt que son utilizados como parámetros para esta fórmula. - Cantidad de Atributos por cada Modelo (MATRn) Este factor considera la cantidad estimada de atributos que utilizarán los modelos a generar. En la tabla IP 13 se describen los posibles valores para este factor. Rango Descripción Valor MB Hasta 10 atributos 1 B Entre 10 y 20 atributos 2 N Entre 30 y 50 atributos 3 A Entre 50 y 70 atributos 4 MA Más de 70 atributos 5 Tabla IP 13. Posibles Valores del Factor MATRn - Tipo de Atributos por cada Modelo (MATRt) Este factor considera la proporción de los tipos de atributos (numéricos y no numéricos) que utilizarán los modelos a generar. En la tabla IP 14 se describen los posibles valores para este factor. Rango Descripción Valor MB Todos los atributos son no numéricos 1 B N A Más cantidad de atributos no numéricos que de atributos numéricos 50% de atributos no numéricos y 50% de atributos numéricos Más cantidad de atributos numéricos que de atributos no numéricos MA Todos los atributos son numéricos 5 Tabla IP 14. Posibles Valores del Factor MATRt Ing. Pablo Pytel 40 Introducción al Problema

41 Cantidad de Técnicas Disponibles para cada Modelo (MTEC) Este factor considera las distintas técnicas que se pueden aplicar para los distintos tipos de modelos a generar. Debido a que no todas las técnicas pueden ser utilizadas para todos los modelos se debe distinguir según la clasificación de los modelos en: - Para Modelos Descriptivos: En la tabla IP 15a se describen los posibles valores para este factor y tipo de modelo. Rango Descripción Valor MB Hay más de 4 técnicas disponibles para generar el modelo 1 B Hay 3 técnicas disponibles para generar el modelo 2 N Hay 2 técnicas disponibles para generar el modelo 3 A Hay 1 técnica disponible para generar el modelo 4 Tabla IP 15a. Posibles Valores del Factor MTEC para Modelos Descriptivos - Para Modelos Predictivos: En la tabla IP 15b se describen los posibles valores para este factor. Rango Descripción Valor B Hay más de 4 técnicas disponibles para generar el modelo 2 N Hay 4 técnicas disponibles para generar el modelo 3 A Hay 3 técnicas disponibles para generar el modelo 4 MA Hay 2 técnicas disponibles para generar el modelo 5 EA Hay 1 técnica disponible para generar el modelo 6 Tabla IP 15b. Posibles Valores del Factor METC para Modelos Predictivos Factores de Costo Relacionados a la Plataforma Esta categoría incluye los factores de costo que se detallan a continuación: Cantidad y Tipo de Fuentes de Información Disponibles (NFUN) Este factor considera la cantidad y tipo de las fuentes u orígenes de información (archivos, bases de datos, reportes en papel, etc.) que se utilizarán en la construcción del Ing. Pablo Pytel 41 Introducción al Problema

42 sistema de explotación de información. En la tabla IP 16 se describen los posibles valores para este factor. Rango Descripción Valor MB Hay 1 fuente de información disponible 1 B De 2 a 3 fuentes de información homogéneas disponibles 2 N De 2 a 3 fuentes de información heterogéneas disponibles 3 A Más de 3 fuentes de información heterogéneas disponibles sin datos en papel 4 MA Más de 3 fuentes de información heterogéneas disponibles con datos en papel 5 Tabla IP 16. Posibles Valores del Factor NFUN Distancia y Medio de Comunicación entre Servidores de Datos (SCOM) Este factor considera la forma y localización para acceder a los servidores que almacenan las fuentes de información a ser utilizadas. En la tabla IP 17 se describen los posibles valores para este factor. Rango Descripción Valor MB Todos los datos en la máquina que será analizada B Todos los datos en la misma base de datos 2 N A MA Todas las fuentes de datos en el mismo edificio comunicados a través de una red LAN Fuentes de datos en diferentes ubicaciones pero comunicadas Fuentes de datos en diferentes ubicaciones pero no comunicadas Tabla IP 17. Posibles Valores del Factor SCOM Factores de Costo Relacionados a las Técnicas y Herramientas Esta categoría incluye los factores de costo que se detallan a continuación: Herramientas Disponibles para Ser Usadas (TOOL) Este factor considera la disponibilidad de las herramientas de explotación de información disponibles para construir los modelos y la realización del proyecto. En la tabla IP 18 se describen los posibles valores para este factor. Ing. Pablo Pytel 42 Introducción al Problema

43 Rango Descripción Valor MB Herramientas usadas para todos los modelos 1 B N A Herramientas usadas para más del 70% de los modelos Herramientas usadas para el 50 al 70% de los modelos0 Herramientas usadas para menos del 50% de los modelos MA No se usan herramientas 5 Tabla IP 18. Posibles Valores del Factor TOOL Grado de Compatibilidad de las Herramientas (COMP) Este factor considera el grado de compatibilidad de las herramientas que se vayan a utilizar en el proyecto con el resto del software disponible para la realización del proyecto. En la tabla IP 19 se describen los posibles valores para este factor. Rango Descripción Valor EB MB B N A MA Total compatibilidad e integración con las herramientas disponibles en la organización Compatibilidad con editores de texto, planillas de cálculo, sistemas administradores de base de datos (DBMS) y herramientas de explotación de información disponibles en la organización Compatibilidad con editores de texto, planillas de cálculo y sistemas administradores de base de datos (DBMS disponibles en la organización Compatibilidad con editores de texto y planillas de cálculo disponibles en la organización Compatibilidad con editores de texto disponibles en la organización No hay compatibilidad con las herramientas disponibles en la organización Tabla IP 19. Posibles Valores del Factor COMP Nivel de Formación de los Usuarios en las Herramientas (NFOR) Este factor considera el nivel de formación (entrenamiento y experiencia) que requieren las herramientas de explotación de información a ser utilizadas para los usuarios. En la tabla IP 20 se describen los posibles valores para este factor. Rango Descripción Valor MB Las herramientas usan asistentes y agentes inteligentes para guiar al usuario durante el proceso de explotación de información. Los 1 Ing. Pablo Pytel 43 Introducción al Problema

44 Rango Descripción Valor B N A MA usuarios necesitan un pequeño conocimiento de las técnicas de explotación de información. Se requiere conocimiento en técnicas de explotación de información. Las herramientas usan asistente. Se requiere un pequeño conocimiento en técnicas de explotación de información y conocimiento en las herramientas. Se requiere conocimiento en técnicas de explotación de información y conocimiento experto en las herramientas. Se requiere conocimiento experto en técnicas de explotación de información y en las herramientas. Tabla IP 20. Posibles Valores del Factor NFOR Factores de Costo Relacionados al Proyecto Esta categoría incluye los factores de costo que se detallan a continuación: Cantidad de Departamentos Involucrados en el Proyecto (NDEP) Este factor considera la cantidad de departamentos diferentes de la organización que están involucrados en el proyecto. En la tabla IP 21 se describen los posibles valores para este factor. Rango Descripción Valor B Participa 1 sólo Departamento 2 N Participan 2 Departamentos 3 A Participan de 3 a 5 Departamentos 4 MA Participan más de 5 Departamentos 5 Tabla IP 21. Posibles Valores del Factor NDEP Grado de Documentación a Entregar (DOCU) Este factor considera el esfuerzo que es necesario para producir la documentación durante el proyecto de acuerdo a los requerimientos del cliente. En la tabla IP 22 se describen los posibles valores para este factor. Rango Descripción Valor B N Documentación sólo para Modelos implantados Documentación para todos los modelos generados 2 3 Ing. Pablo Pytel 44 Introducción al Problema

45 Rango Descripción Valor A MA Documentación para todos los modelos y fases centrales de explotación de información Documentación para todos los modelos y todas las fases de explotación de información Tabla IP 22. Posibles Valores del Factor DOCU 4 5 Desarrollo en Múltiples Localizaciones (SITE) Este factor considera la cantidad de sitios diferentes donde se realizará el desarrollo del proyecto y su grado de comunicación entre sí. En la tabla IP 23 se describen los posibles valores para este factor. Rango Descripción Valor MB B N A MA EA Comunicación interactiva multimedia en la misma ubicación Comunicación de gran ancho de banda con pocas videoconferencias en el mismo edificio o complejo Comunicación de gran ancho de banda en la misma ciudad o área metropolitana Comunicación de poco ancho de banda en varias ciudades u organizaciones Comunicación por teléfono o fax en varias ciudades u organizaciones Comunicación internacional por teléfono o correo Tabla IP 23. Posibles Valores del Factor SITE Factores de Costo Relacionados al Personal Esta categoría incluye los factores de costo que se detallan a continuación: Grado de Familiaridad con el Tipo de Problema (MFAM) Este factor considera la familiaridad de los participantes del equipo de trabajo en el tipo de problema que se intenta resolver. En la tabla IP 24 se describen los posibles valores para este factor. Rango Descripción Valor MB El equipo ha estado trabajando junto en los mismos tipos de proyectos de explotación de información igual al del nuevo proyecto y con datos similares 1 Ing. Pablo Pytel 45 Introducción al Problema

46 Rango Descripción Valor B N A MA El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto y con datos similares El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto pero con datos diferentes El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto pero nunca en el mismo ambiente El equipo nunca ha trabajado en proyectos de explotación de información Tabla IP 24. Posibles Valores del Factor MFAM Grado de Conocimiento de los Datos a utilizar (KDAT) Este factor considera si los participantes del equipo de trabajo en los datos que van a ser utilizados para el proyecto por haberlos manejados con anterioridad. En la tabla IP 25 se describen los posibles valores para este factor. Rango Descripción Valor MB Experto en correlación del negocio y datos 1 B Experto en correlación de datos 2 N A Datos desconocidos pero existe descripción de los datos No hay descripción de los datos o del modelo de datos Tabla IP 25. Posibles Valores del Factor KDAT 3 4 Actitud de los Directivos (ADIR) Este factor considera el grado de apoyo de la dirección de la organización o del departamento en el proyecto (o sea, el perfil del sponsor del proyecto). En la tabla IP 26 se describen los posibles valores para este factor. Rango Descripción Valor MB B N La dirección del departamento y la organización apoyan al proyecto La dirección del departamento apoya al proyecto pero la dirección de la organización no lo apoya. La dirección del departamento apoya al proyecto y la dirección de la organización no se opone Ing. Pablo Pytel 46 Introducción al Problema

47 Rango Descripción Valor A La dirección del departamento no apoya al proyecto o está en su contra, y la dirección de la organización no lo apoya. Tabla IP 26. Posibles Valores del Factor ADIR FÓRMULAS UTILIZADAS POR DMCOMO A continuación en la tabla IP 27 se muestran las fórmulas utilizadas por el método DMCoMo. La primera [Marbán, 2003] utiliza todos los factores de costo definidos en la sección 2.4.2, mientras que la segunda ecuación [Marbán et al., 2003] es una fórmula reducida que utiliza sólo 8 factores de costo significativos a través del Análisis de la Varianza (ANOVA) con un factor de confiabilidad del 95%. Fórmulas Fórmula con 23 factores de costo: MM 23 = 78, ,802 x NTAB + 1,953 x NTUP + 2,115 x NATR + 6,426 x DISP + 0,345 x PNUL + ( - 2,656 ) x DMOD + 2,586 x DEXT + ( -0,456 ) x NMOD + 6,032 x TMOD + 4,312 x MTUP + 4,966 x MATR + ( -2,591 ) x MTEC + 3,943 x NFUN + 0,896 x SCOM + ( -4,615 ) x TOOL + ( -1,831 ) x COMP + ( -4,689 ) x NFOR + 2,931 x NDEP + ( -0,892 ) x DOCU + 2,135 x SITE + ( -0,214 ) x KDAT + ( -3,756) x ADIR + ( -4,543) x MFAM Fórmula con 8 factores de costo: MM 8 = 70, ,368 x NTAB + 2,885 x NATR + 4,792 x DISP + 2,713 x DEXT + 7,257 x TMOD + 4,615 x MATR + ( -3,842 ) x NFOR + ( -3,275) x MFAM Ing. Pablo Pytel 47 Introducción al Problema

48 Donde para ambas fórmulas: ADIR: Actitud de los directivos. Fórmulas COMP: Grado de compatibilidad de las herramientas con otros software. DOCU: Grado de documentación que es necesario generar. DEXT: Grado de integración de datos externos. DISP: Grado de dispersión de datos. DMOD: Grado de documentación de las fuentes de información. KDAT: Grado de conocimiento de los datos. MATR: Cantidad y Tipo de atributos por cada modelo. MFAM: Grado de familiaridad con el tipo de problema. MTEC: Cantidad de técnicas disponibles para cada modelo. MTUP: Cantidad de tuplas de los modelos. NATR: Cantidad de atributos de las tablas. NDEP: Cantidad de departamentos involucrados en el proyecto. NFOR: Grado de entrenamiento de los usuarios de las herramientas. NFUN: Cantidad y Tipo de fuentes de información disponibles. NMOD: Cantidad de modelos a ser creados. NTAB: Cantidad de tablas. NTUP: Cantidad de tuplas de las tablas. PNUL: Porcentaje de valores NULL. SITE: Cantidad de sitios donde se realizará el desarrollo y su grado de comunicación. SCOM: Distancia y Medio de comunicación entre servidores de datos. TMOD: Tipo de modelos a ser creados. TOOL: Herramientas disponibles para ser usadas. Tabla IP 27. Fórmulas del Método DMCoMo 2.5. DEFINICIÓN DEL PROBLEMA En [Marbán, 2003; Marbán et al., 2003] para validar el método propuesto se utilizaron 15 proyectos reales de explotación de información para comparar el esfuerzo real de los proyectos con las estimaciones obtenidas por el método. Dicha comparación se puede ver en la tabla IP 28. Ing. Pablo Pytel 48 Introducción al Problema

49 Identificador del Proyecto Esfuerzo Real del proyecto Esfuerzo estimado por la fórmula de 23 factores de costo Esfuerzo estimado por la fórmula de 8 factores de costo 1 117,00 132, , ,00 100, , ,00 130, , ,00 136, , ,00 92, , ,00 146, , ,00 93, , ,00 117, , ,00 129, , ,00 138, , ,00 91, , ,00 101,14 114, ,00 87, , ,00 96, , ,00 132, ,079 Tabla IP 28. Comparación del esfuerzo real y los estimados para 15 proyectos Como resultado de dicha comparación y un análisis estadísticos de los resultados obtenidos se puede ver en la tabla IP 29 que la ecuación que utiliza 23 factores de costo posee una desviación estándar del error de ± 16,908 meses/hombre (o sea, ± 1,41 años/hombre), mientras que para la de 8 factores de costo la desviación estándar del error es de ± 23,105 meses/hombre (o sea. ± 1,93 años/hombre). Ecuación con 23 factores de costo Ecuación con 8 factores de costo Error Mínimo -17,559-23,979 Error Máximo 31,498 50,216 Error Medio 11,097 8,972 Error Medio Absoluto 18,025 20,066 Desviación Estándar del Error 16,908 23,105 Tabla IP 29. Análisis Estadístico de la comparación del esfuerzo estimado y el esfuerzo real Al revisar los resultados de la validación del método, se observa que los 15 proyectos de explotación de información utilizados se encuentren en el rango de esfuerzo de 87 meses/hombre a 167 meses/hombre (o sea, 7,25 años/hombre a 13,92 años/hombre). De hecho en [Marbán et al., 2003] se indica que el método es confiable para proyectos dentro del rango 90 meses/hombre a 185 meses/hombre (o sea, 7,5 años/hombre a 15,41 Ing. Pablo Pytel 49 Introducción al Problema

50 años/hombre) pero se desconoce el comportamiento del método para proyectos fuera de ese rango. En ese sentido se utilizó un caso de estudio de un proyecto de explotación de información para validar el método. Los datos del proyecto se pueden ver en la tabla IP 30 junto los resultados de la comparación del esfuerzo real y las estimaciones calculadas. Objetivo del Proyecto Técnica utilizada: Detección de evidencias de causalidad entre Satisfacción General e Internet Detección de evidencias de causalidad entre hechos (Redes Bayesianas). Factor de Costo Rango Valor ADIR COMP DEXT DISP La dirección del departamento apoya ampliamente el proyecto Compatible parcialmente con las herramientas de oficina de la organización No existen fuentes externas a la organización, pero como esta opción no la el método se utiliza de 1 a 3 fuentes externas de datos. Los valores disponibles eran claros y con poca dispersión DMOD Menos del 60% de los modelos 5 DOCU Documentación para todos los modelos y todas las fases de explotación de información 5 KDAT Experto en correlación de datos 2 MATRn Entre 30 y 50 atributos 3 MATRt Todos los atributos son no numéricos 1 MFAM MTEC El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto pero nunca en el mismo ambiente. Hay más de 4 técnicas disponibles para generar el modelo 4 2 MTUP Entre 5 x 10 6 tuplas y 10 x 10 6 tuplas 2 NATR Menos de 500 atributos 1 NDEP Participa 1 sólo Departamento 2 NFOR Se requiere un pequeño conocimiento en técnicas de explotación de información y conocimiento en las herramientas. 3 Ing. Pablo Pytel 50 Introducción al Problema

51 Objetivo del Proyecto Técnica utilizada: Detección de evidencias de causalidad entre Satisfacción General e Internet Detección de evidencias de causalidad entre hechos (Redes Bayesianas). Factor de Costo Rango Valor NFUN De 2 a 3 fuentes de información heterogéneas disponibles 3 NMOD De 3 a 5 modelos 3 NTAB Hasta 20 tablas 0 NTUP Hasta 5 x 10 7 tuplas 1 PNUL De 10 a 15% de valores nulos 2 SCOM SITE Fuentes de datos en diferentes ubicaciones pero comunicadas Comunicación de gran ancho de banda en la misma ciudad o área metropolitana 4 3 TMOD Modelo Descriptivo: Asociación 1 TOOL Herramientas usadas para todos los modelos 1 Esfuerzos Esfuerzo Real (El proyecto fue realizado por 3 personas durante 4 meses.) 12 meses/hombre o 1 año/hombre Esfuerzo estimado por la fórmula de 23 factores de costo 76,56 meses/hombre o 6,38 años/hombre Esfuerzo estimado por la fórmula de 8 factores de costo 75,86 meses/hombre o 6,32 años/hombre Tabla IP 30. Comparación del esfuerzo real y los estimados para proyecto caso de estudio Como resultado de dicha comparación se obtiene un error de -64,56 meses/hombre (o sea, -5,38 años/hombre), mientras que para la de 8 factores de costo el error es -63,86 meses/hombre (o sea, -5,32 años/hombre). Como puede verse, el error es considerable Ing. Pablo Pytel 51 Introducción al Problema

52 dado que DMCoMo indica que se requeriría 6 veces más cantidad de personas para realizar el proyecto en el mismo tiempo. Por lo tanto, en [Pytel et al., 2011] se indica la necesidad de validar este método de estimación analítico para proyectos fuera del rango definido como confiable. Pero, como se considera que 15 es una cantidad pequeña de experimentos para asegurar la validación del método, también es recomendable verificar el comportamiento del método también dentro de ese rango SOLUCIÓN PROPUESTA Dado que es muy difícil obtener datos de proyectos de explotación reales para poder realizar el análisis del comportamiento del método de estimación, se decide utilizar un proceso de simulación basado en el método de simulación de Montecarlo. La simulación de Montecarlo [Kalos & Whitlock, 1986; Peña Sánchez de Rivera, 2001] es una técnica que combina conceptos estadísticos (muestreo aleatorio) con la capacidad que tienen las computadoras para generar números pseudo-aleatorios y automatizar cálculos (para mayor información sobre el método Montecarlo ver el Apéndice B). De esta manera, este trabajo de tesis tiene el objetivo de desarrollar un sistema software para generar un banco de pruebas simulado de proyectos de explotación de información con sus características (relevantes para el método DMCoMo) determinadas aleatoriamente dentro de un marco definido por el usuario (utilizando los valores permitidos para el tamaño de proyecto seleccionado) al que le aplican las fórmulas de estimación del método DMCoMo. Al momento de generar los datos de los proyectos, se consideran tres rangos para tamaños de proyectos de explotación de información los cuales están definidos en el Apéndice A DEFINICIÓN DEL PROCESO DE SIMULACIÓN A continuación se definen con mayor detalle cómo se implementa el proceso de simulación Montecarlo para analizar el comportamiento del método DMCoMo. Objetivo El objetivo del proceso de simulación es determinar el comportamiento del método de estimación DMCoMo para diferentes variaciones de los factores de costo que consideren los tres rangos de tamaño de proyecto previamente definidos o sin restricciones (o sea variaciones totalmente aleatorias). Ing. Pablo Pytel 52 Introducción al Problema

53 Variables La simulación utiliza las siguientes variables independientes y dependientes: Variables Independientes La principal variable independiente que puede ser controlada por el experimentador es el rango de tamaño del proyecto, para el cual se consideran los tamaños Pequeño, Mediano, Grande, o Aleatorio (o sea, sin ninguna restricción en los valores). A su vez, las variables muestrales que se van a generar aleatoriamente mediante el proceso de simulación son los 23 factores de costo definidos por el método DMCoMo (en la sección 2.4.2) considerando las restricciones por el tamaño del proyecto seleccionado (definidos en el Apéndice A). Pero el experimentador también podría, en caso de que lo considere necesario, definir un valor específico para alguna de estos factores y así restringir la cantidad de combinaciones. En conclusión la lista de variables independientes es la siguiente: - TAMAÑO DEL PROYECTO, que puede tomar los valores Pequeño, Mediano, Grande o Aleatoria. - FACTOR DE COSTO CANTIDAD DE TABLAS (NTAB), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO CANTIDAD DE TUPLAS DE LAS TABLAS (NTUP), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO CANTIDAD DE ATRIBUTOS DE LAS TABLAS (NATR), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO GRADO DE DISPERSIÓN DE DATOS (DISP), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO PORCENTAJE DE VALORES NULL (PNUL), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO GRADO DE DOCUMENTACIÓN DE LAS FUENTES DE INFORMACIÓN (DMOD), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. Ing. Pablo Pytel 53 Introducción al Problema

54 - FACTOR DE COSTO GRADO DE INTEGRACIÓN DE DATOS EXTERNOS (DEXT), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO CANTIDAD DE MODELOS A SER CREADOS (NMOD), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO TIPO DE MODELOS A SER CREADOS (TMOD), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - CANTIDAD DE TUPLAS DE LOS MODELOS (MTUP), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO CANTIDAD Y TIPO DE ATRIBUTOS POR CADA MODELO (MATR), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO CANTIDAD DE TÉCNICAS DISPONIBLES PARA CADA MODELO (MTEC), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO CANTIDAD Y TIPO DE FUENTES DE INFORMACIÓN DISPONIBLES (NFUN), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO DISTANCIA Y MEDIO DE COMUNICACIÓN ENTRE SERVIDORES DE DATOS (SCOM), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO HERRAMIENTAS DISPONIBLES PARA SER USADAS (TOOL), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO GRADO DE COMPATIBILIDAD DE LAS HERRAMIENTAS CON OTROS SOFTWARE (COMP), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO GRADO DE ENTRENAMIENTO DE LOS USUARIOS DE LAS HERRAMIENTAS (NFOR), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO CANTIDAD DE DEPARTAMENTOS INVOLUCRADOS EN EL PROYECTO (NDEP), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. Ing. Pablo Pytel 54 Introducción al Problema

55 - FACTOR DE COSTO GRADO DE DOCUMENTACIÓN QUE ES NECESARIO GENERAR (DOCU), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO CANTIDAD DE SITIOS DONDE SE REALIZARÁ EL DESARROLLO Y SU GRADO DE COMUNICACIÓN (SITE), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO GRADO DE FAMILIARIDAD CON EL TIPO DE PROBLEMA (MFAM), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO GRADO DE CONOCIMIENTO DE LOS DATOS (KDAT), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. - FACTOR DE COSTO ACTITUD DE LOS DIRECTIVOS (ADIR), con un valor específico o un valor aleatorio del rango de valores predefinido por el TAMAÑO DEL PROYECTO. Variables Dependientes Para este proceso de simulación las variables dependientes, o sea las que son afectadas por las variables independientes, son los resultados de aplicar las fórmulas de estimación del método DMCoMo (definidas en la sección 2.4.3) para los factores de costo definidos. Entonces las dos variables dependientes a ser utilizadas son: - ESTIMACIÓN CALCULADA POR LA FÓRMULA DE 23 FACTORES DE COSTO (MM23), la cual depende de todos los factores de costo. - ESTIMACIÓN CALCULADA POR LA FÓRMULA DE 8 FACTORES DE COSTO (MM8), la cual depende sólo de los factores de costo MFAM, NTAB, NATR, DISP, DEXT, TMOD, MATR y NFOR. La relación entre las variables independientes y dependientes indicando como afectan unas a otras se puede ver en la figura IP 4. Ing. Pablo Pytel 55 Introducción al Problema

56 SCOM SITE NFUN KDAT ADIR MTUP TOOL MTEC MM23 PNUL NMOD NDEP DOCU TAMAÑO DEL PROYECTO NTUP COMP DMOD MFAM NTAB NATR DISP MM8 DEXT TMOD MATRt MATRn MATR NFOR Figura IP 4. Relación entre las variables independientes y dependientes Registro de Resultados Para poder realizar el análisis de los resultados es necesario obtener una tabla que contenga, para todas las simulaciones realizadas, los valores de todas las variables independientes aplicadas (o sea, las factores de costo) y de las variables dependientes (o sea, las estimaciones calculadas). Así la tabla tendrá las siguientes columnas: - N O DE PROYECTO: el identificador del proyecto generado. - NTAB: factor de costo cantidad de tablas. - NTUP: factor de costo cantidad de tuplas de las tablas. - NATR: factor de costo cantidad de atributos de las tablas. - DISP: factor de costo grado de dispersión de datos. Ing. Pablo Pytel 56 Introducción al Problema

57 - PNUL: factor de costo porcentaje de valores NULL. - DMOD: factor de costo grado de documentación de las fuentes de información. - DEXT: factor de costo grado de integración de datos externos. - NMOD: factor de costo cantidad de modelos a ser creados. - TMOD: factor de costo tipo de modelos a ser creados. - MTUP: factor de costo cantidad de tuplas de los modelos. - MATRn: factor de costo cantidad de atributos por cada modelo. - MATRt: factor de costo tipo de atributos por cada modelo. - MATR: factor de costo promedio calculado de cantidad (MATRn) y tipo de atributos (MATRt) por cada modelo. - MTEC: factor de costo cantidad de técnicas disponibles para cada modelo. - NFUN: factor de costo cantidad y tipo de fuentes de información disponibles. - SCOM: factor de costo distancia y medio de comunicación entre servidores de datos. - TOOL: factor de costo herramientas disponibles para ser usadas. - COMP: factor de costo grado de compatibilidad de las herramientas con otros software. - NFOR: factor de costo grado de entrenamiento de los usuarios de las herramientas. - NDEP: factor de costo cantidad de departamentos involucrados en el proyecto. - DOCU: factor de costo grado de documentación que es necesario generar. - SITE: factor de costo cantidad de sitios donde se realizará el desarrollo y su grado de comunicación. - KDAT: factor de costo grado de conocimiento de los datos. - ADIR: factor de costo actitud de los directivos. - MFAM: factor de costo grado de familiaridad con el tipo de problema. - MM23: costo estimado utilizando la fórmula que aplica los 23 factores de costo. - MM8: costo estimado utilizando la fórmula que aplica los 8 factores de costo ANÁLISIS DE RESULTADOS A partir de los resultados obtenidos en los experimentos realizados por la simulación Montecarlo y registrados en la tabla descripta en la sección anterior, se procede a revisar Ing. Pablo Pytel 57 Introducción al Problema

58 el comportamiento del método DMCoMo al analizar los valores de los esfuerzos estimados (variables dependientes MM8 y MM23) para diferentes variaciones del tamaño del proyecto y de los factores de costo del método (variables independientes definidas en la sección anterior). Ing. Pablo Pytel 58 Introducción al Problema

59 CAPÍTULO 3 REQUISITOS Y ESTUDIO DE VIABILIDAD DEL SISTEMA

60

61 3. REQUISITOS Y ESTUDIO DE VIABILIDAD DEL SISTEMA 3.1. INTRODUCCIÓN El objetivo del proceso de Estudio de Viabilidad del Sistema (EVS) es analizar un conjunto determinado de necesidades para proponer una solución a corto plazo y que considere todas las restricciones económicas, técnicas, legales y operativas. Como resultado del estudio se obtiene la solución que puede incluir la definición de uno o varios proyectos que afecten a uno o varios sistemas de información, tanto ya existentes como nuevos. Esto se realiza mediante la identificación de todos los requisitos que se han de satisfacer en un catálogo 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 desarrollas a medida, soluciones basadas en la adquisición de productos software existentes en el mercado o soluciones mixtas. Se realiza la descripción para cada una de estas alternativas, indicando los requisitos que cubre cada una. Luego de describir cada una de las posibles soluciones alternativas, se realiza el análisis del impacto de las mismas en la organización, indicando la inversión a realizar en cada caso y los riesgos asociados. La información generada para las distintas alternativas se compara y evalúa con el objetivo de seleccionar la más adecuada, definiendo y estableciendo su planificación. En el caso de que en la organización se haya realizado con anterioridad un Plan de Sistemas de Información que pueda afectar al sistema objeto de este estudio, se dispondrá de un conjunto de productos que proporcionan información a tener en cuenta en todo el proceso. Sin embargo, dado que este proyecto de desarrollo se realizó en un trabajo de tesis, no se cuenta con el Plan de Sistemas de Información ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA Esta actividad tiene el objetivo de estudiar el alcance de la necesidad existente, realizando una descripción general de la misma. Para ello se realiza la definición de los objetivos, se comienza el estudio de los requisitos y se identifican las unidades organizativas que son afectadas con su estructura. Se analizan las posibles restricciones, tanto generales como específicas, que puedan tener algún impacto sobre el estudio y la planificación de las alternativas de solución que se propongan. Ing. Pablo Pytel 61 Requisitos y Estudio de Viabilidad del Sistema

62 Debe considerarse que cuando exista una solución alternativa que posee bajo riesgo técnico, una justificación económica clara, pocos problemas legales y sin ninguna otra alternativa razonable, entonces 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. En este caso se utiliza esta solución alternativa para proceder a la especificación de requisitos, la descripción del nuevo sistema y su planificación. Finalmente se realiza la definición de la composición del equipo de trabajo necesario para este proceso y su planificación. Lo cual incluye la identificación de los perfiles de usuarios, dejando claras sus tareas y responsabilidades, para facilitar el involucramiento activo de ellos en la definición del sistema ESTUDIO DE LA SOLICITUD Se describe la necesidad en forma general, estudiando las posibles restricciones que puedan afectar al sistema de carácter tanto económico, técnico, operativo como legal. Antes de comenzar el estudio de los requisitos del sistema se deben establecer los objetivos generales del Estudio de Viabilidad, teniendo en cuenta las restricciones identificadas anteriormente. En caso de que existiese un Plan de Sistemas de Información vigente que incluya en su ámbito al sistema objeto de estudio, se debe considerar 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. Sin embargo, debido a que este proyecto corresponde a un trabajo de tesis y no se realizó dentro de una organización no se posee un Plan de Sistemas de Información vigente para ser considerado Descripción General del Sistema A partir del problema detectado y la solución propuesta (descriptas en las secciones 2.5 y 2.6 de este trabajo) se definió el objetivo del sistema software como la generación de bancos de pruebas de proyectos de explotación de información que permitan analizar el comportamiento del método de estimación DMCoMo. Los datos de los proyectos son creados aleatoriamente con las características requeridas por el método de estimación seleccionado (o sea los factores de costo) y de acuerdo a clasificaciones previamente seleccionadas (de acuerdo a lo definido en el Apéndice A). Este nuevo sistema software se ha desarrollo en forma autónoma, esto quiere decir que no se encuentra relacionado con ninguno de los proyectos de desarrollo que se llevaron a cabo en el Instituto Tecno- Ing. Pablo Pytel 62 Requisitos y Estudio de Viabilidad del Sistema

63 lógico de Buenos Aires (ITBA) y la Facultad de Informática de la Universidad Politécnica de Madrid (UPM) donde el proyecto va a exponerse como tesis de la carrera Magíster en Ingeniería en Software, ni tampoco con los Sistemas de Información existentes en las mismas. Debe notarse que el actual proyecto persigue un fin académico y no comercial, o sea, no se espera obtener logros económicos con el actual proyecto de desarrollo. Considerando lo indicado anteriormente, a continuación se detalla un conjunto de ítems que no son tenidos en cuanta dentro del Estudio de Viabilidad del Sistema: La recuperación de la inversión económica debido a que el proyecto no apunta a ser un producto comercial. La interacción entre el desarrollo del nuevo software con los demás proyectos de desarrollo de las universidades indicadas anteriormente. La contratación de recursos humanos que colaboren en el desarrollo del proyecto. Esto significa que dentro del actual Estudio de Viabilidad del Sistemas sólo se evaluaron las restricciones de tipos funcionales y técnicas para el desarrollo del sistema software Catálogo de Objetivos de la Evaluación del Sistema Software Como fue explicado en el punto anterior el sistema software actual tiene como principal objetivo la construcción de bancos de pruebas de proyectos de explotación de información los cuáles son creados aleatoriamente con las características requeridas por el método de estimación DMCoMo y de acuerdo a clasificaciones previamente seleccionadas. Este sistema software será utilizado sólo dentro del ámbito académico. Ya que Métrica Versión III define que 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], entonces para el sistema actual se consideró que la viabilidad del proyecto es alta y que el objetivo de la fase análisis de viabilidad del sistema del sistema está centrado en la especificación de requisitos, descripción del nuevo sistema y planificación. A continuación se detallan los objetivos principales del estudio de viabilidad del sistema: Analizar la situación actual. Describir las posibles mejoras. Analizar las alternativas de solución. Establecer los requisitos del nuevo sistema. Ing. Pablo Pytel 63 Requisitos y Estudio de Viabilidad del Sistema

64 3.3. DEFINICIÓN DE REQUISITOS DEL SISTEMA Esta actividad tiene el objetivo de determinar de los requisitos generales, mediante una serie de sesiones de trabajo con los usuarios participantes, los cuáles deben ser planificados y realizados. Una vez que las sesiones son finalizadas, se analiza la información obtenida definiendo los requisitos y sus prioridades, los cuáles 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 obtener las necesidades que ha de satisfacer el sistema actual se deciden los tipos de sesiones de trabajo realizadas y la frecuencia con que tienen lugar en función de la disponibilidad de los usuarios participantes. También 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, si ya se ha realizado el Estudio de la Situación Actual. 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 Identificación de Requisitos Dado que se había considerado el proyecto actual como un desarrollo autónomo, no se consideró necesario la realización del análisis de los sistemas actualmente utilizados en la organización. A continuación se detallan los requisitos a incorporar al sistema luego de una sesión de trabajo llevada a cabo entre el tesista (en su papel de ingeniero software) y los directores del proyecto de tesis (en su papel de futuros usuarios del sistema software): a. Perfiles de Usuarios del Sistema: El sistema software a ser desarrollado es monousuario, el cuál debe ser operado por un usuario experimentado que utiliza todas las funciones del sistema para generar el banco de pruebas del que se describe en la descripción general del sistema (sección ). Ing. Pablo Pytel 64 Requisitos y Estudio de Viabilidad del Sistema

65 b. Funciones básicas del Sistema: El sistema software debe generar bancos de pruebas para evaluar el comportamiento del método de estimación propuesto sobre proyectos de explotación de información con diferentes características a partir de la configuración indicada por el usuario antes de comenzar. Por lo tanto, a través de una función de consulta al sistema es posible visualizar los valores obtenidos por el método para diferentes proyectos y exportar estos valores en un archivo en caso de que sea necesario. c. Validación de Usuarios: Al tratarse de un sistema software monousuario donde no es posible modificar datos ya generados, esta funcionalidad se considera un esfuerzo innecesario por lo que no existe la validación de usuarios. d. Requisitos no funcionales: Los detallan a continuación los requisitos no funcionales a cumplir: El sistema software deberá utilizar la clasificación de proyectos por tamaño definida en el Apéndice A. El sistema software deberá permitir generar muchos proyectos de explotación de información en forma continua y automática hasta que el usuario decida parar la generación. El sistema software deberá permitir generar todas las combinaciones válidas de proyectos de explotación de información a partir de un tamaño de proyecto previamente seleccionado. El sistema software sólo será ejecutado en Plataforma Windows. El sistema software deberá ser capaz de exportar las características de cada proyecto evaluado con su estimación calculada en un archivo de texto para su posterior análisis utilizando herramientas de manejo de planillas de cálculos. El sistema software deberá poder mostrar un gráfico con el histograma de la estimación calculada para cada proyecto. El sistema software deberá poder mostrar un gráfico con la frecuencia de ocurrencia de cada una de las características de los proyectos y las estimaciones calculadas. El sistema software no necesita manejar los permisos del Sistema Operativo para restringir o habilitar el acceso de un usuario a una determinada carpeta o documento. Ing. Pablo Pytel 65 Requisitos y Estudio de Viabilidad del Sistema

66 CATALOGACIÓN DE REQUISITOS Se realiza el análisis de 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 el sistema debe satisfacer indicando también sus prioridades. Además se incluyen los requisitos relativos a distribución geográfica y entorno tecnológico Catálogo de Requisitos A continuación se describen los requisitos funcionales y no funcionales que fueron relevados para ser satisfechos por el sistema software. Se utiliza como guía de escritura el estándar IEEE para Especificación de los Requisitos del Software (ERS) [IEEE, 1998]. a. Requisitos Funcionales: En la figura EVS 1 se muestran los principales requisitos funcionales del sistema: Figura EVS 1: Requisitos Funcionales del Sistema Software Descripción de los requisitos funcionales: RF 1: Configurar Parámetros RF 1.1: Permitir al usuario indicar los parámetros utilizados para generar las características de los proyectos de explotación de información. RF 1.1.1: Permitir al usuario seleccionar la clasificación de proyectos de explotación de información dependiendo de su tamaño (proyectos de tipo Pequeño, Mediano o Grande definidos en el Apéndice A) o permitir cualquier valor (proyectos de tipo Aleatorios). Ing. Pablo Pytel 66 Requisitos y Estudio de Viabilidad del Sistema

67 RF 1.1.2: Permitir al usuario indicar si los valores de los factores de costo utilizados por el método DMCoMo (definidos en la sección 2.4.2) se deben generar al azar o no. RF 1.1.3: Permitir al usuario definir un valor específico para uno, más de uno o todos los factores de costo utilizados por el método DMCoMo (definidos en la sección 2.4.2). RF 1.2: Permitir al usuario indicar los parámetros utilizados para exportar los archivos de exportación. RF 1.2.1: Permitir al usuario indicar si se desea si desea exportar los datos de los proyectos generados y estimados. RF 1.2.2: Permitir al usuario indicar el nombre de archivo de exportación a utilizar. RF 1.2.3: Permitir al usuario utilizar un nombre de archivo de exportación ya existente para ser reemplazado. RF 1.2.4: Permitir al usuario modificar un nombre de archivo de exportación si el archivo ya existe y no se desea reemplazar. RF 2: Generar Datos de Proyecto RF 2.1: Definir aleatoriamente los valores de los factores de costo utilizados por el método DMCoMo (definidos en la sección 2.4.2) que no fueron configurados con un valor específico por el usuario. RF 2.2: Utilizar sólo los valores permitidos por el tamaño de proyecto configurado para los factores de costo (definidos en la sección 2.4.2) en caso de que se haya configurado un tamaño de proyecto (o sea, proyectos Pequeño, Mediano o Grande definidos en el Apéndice A). RF 2.3: Utilizar cualquiera de los valores permitidos por el método DMCoMo para los factores de costo (definidos en la sección 2.4.2) en caso de que no se haya configurado un tamaño de proyecto (o sea, proyectos de tipo Aleatorio). RF 2.4: Permitir al usuario visualizar los valores generados para los factores de costo de los proyectos procesados. Ing. Pablo Pytel 67 Requisitos y Estudio de Viabilidad del Sistema

68 RF 3: Calcular Estimación de Esfuerzo. RF 3.1: Aplicar a los proyectos generados la fórmula de estimación que utiliza los 23 factores de costo propuesta por el método DMCoMo (explicada en la sección 2.4.3). RF 3.2: Aplicar a los proyectos generados la fórmula de estimación que utiliza los 8 factores de costo propuesta por el método DMCoMo (explicada en la sección 2.4.3). RF 3.3: Permitir al usuario visualizar en pantalla los valores de la estimación calculados para el último proyecto procesado. RF 3.4: Permitir al usuario visualizar en pantalla la media estadística de los valores de la estimación calculados para los proyectos procesados. b. Requisitos No Funcionales: En la figura EVS 2 se muestran los requisitos no funcionales del sistema: Figura EVS 2: Requisitos No Funcionales del Sistema Software Descripción de los requisitos no funcionales: RNF 1: Modos de Procesamiento de Proyectos RNF 1.1: Permitir al usuario generar y procesar los proyectos de a uno por vez. RNF 1.2: Automatizar el proceso de generación y procesamiento de los proyectos para que se realice en forma continua. Ing. Pablo Pytel 68 Requisitos y Estudio de Viabilidad del Sistema

69 RNF 1.3: Automatizar el proceso de generación y procesamiento de los proyectos para que se pueda generar un análisis completo con todas las combinaciones válidas para el tamaño de proyecto seleccionado (o sea, sólo para proyectos pequeño, mediano y grande). RNF 2: Interfaz Gráfica RNF 2.1: Utilizar una interfaz gráfica para interactuar con el usuario. RNF 2.2: Permitir al usuario configurar los parámetros a través de una pantalla. RNF 2.3: Permitir al usuario visualizar en pantalla valores generados y procesados para los factores de costo de los proyectos procesados. RNF 2.4: Permitir al usuario visualizar un gráfico con el histograma de la estimación calculada para cada proyecto generado. RNF 2.4.1: Permitir al usuario visualizar en pantalla un gráfico con el histograma de la estimación calculada por la fórmula de 23 factores de costo para cada proyecto generado. RNF 2.4.2: Permitir al usuario visualizar en pantalla un gráfico con el histograma de la estimación calculada por la fórmula de 8 factores de costo para cada proyecto generado. RNF 2.5: Permitir al usuario visualizar un gráfico un gráfico con la frecuencia de ocurrencia de cada una de las características de los proyectos generados. RNF 2.6: Permitir al usuario visualizar un gráfico un gráfico con la frecuencia de ocurrencia de cada una de las estimaciones calculadas RNF 3: Soporte de Sistemas Operativos RNF 3.1: Permitir ser ejecutado desde el Sistema Operativo Microsoft Windows RNF 3.2: Permitir ser ejecutado desde el Sistema Operativo Microsoft Windows XP. RNF 3.3: Permitir ser ejecutado desde el Sistema Operativo Microsoft Windows 7 o superior. Ing. Pablo Pytel 69 Requisitos y Estudio de Viabilidad del Sistema

70 RNF 4: Restricciones de Carpetas RNF 4.1: No se manejan los permisos del Sistema Operativo para restringir el acceso de un usuario a una determinada carpeta o documento. RNF 4.2: No se manejan los permisos del Sistema Operativo para habilitar el acceso de un usuario a una determinada carpeta o documento. RNF 5: Generación de Archivos RNF 5.1: Permitir exportar las características de cada proyecto procesado con su estimación calculada en un archivo de texto para su posterior análisis detallado utilizando herramientas para el manejo de planilla de cálculo (como por ejemplo Microsoft Excel), otorgando así mayor portabilidad a este formato de reporte. RNF 5.2: Generar los archivos con un formato de valores delimitados por coma, o semi-coma ; (archivos de tipo CSV) para facilitar su operación con las otras herramientas (como por ejemplo Microsoft Excel) Arquitectura Tecnológica Se detallan a continuación los elementos tecnológicos más apropiados para el desarrollo del sistema software: a. Entorno de Hardware: El hardware mínimo para el desarrollo será una máquina de tipo PC con las siguientes características mínimas: - Pentium III o superiores (2.0 GHZ) - 1 GB de memoria RAM (o más) - Disco rígido de 20 GB (o superior) El hardware requerido para la ejecución del sistema software será una máquina de tipo PC con las siguientes características mínimas: - Pentium III o superiores (2.0 GHZ) - 1 GB de memoria RAM (o más) - Disco rígido de 20 GB (o superior) Ing. Pablo Pytel 70 Requisitos y Estudio de Viabilidad del Sistema

71 b. Sistema Operativo: El sistema operativo utilizado para la construcción será Microsoft Windows 7. El sistema operativo requerido para la ejecución del sistema será: Microsoft Windows XP, 2000, 7 o superior. c. Lenguaje de desarrollo: El lenguaje de desarrollo utilizado será Java, utilizando para ello el entorno provisto por la herramienta Easy Java Simulations (EJS), la cual es una herramienta de código abierto (Open Source) bajo licencia GNU GPL que facilita crear simulaciones interactivas en Java. Debido a que se utiliza Java como lenguaje de desarrollo es necesario la instalación de Java Runtime Environment (JRE) 1.5 o posterior para su ejecución. d. Base de Datos: El sistema software no cuenta con Base de Datos por lo que no es necesario definir ningún software de Gestión de Base de Datos ESTUDIO DE ALTERNATIVAS DE SOLUCIÓN Esta actividad tiene el objetivo de proponer y estudiar alternativas de solución 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). En la descripción de las distintas alternativas 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, en orientación a objetos, un Modelo de Negocio y, opcionalmente, un Modelo de Dominio. Además, considerando el ámbito y funcionalidad que debe cubrir el sistema, puede ser conveniente realizar una descomposición del sistema en subsistemas previamente a la definición de cada alternativa. Ing. Pablo Pytel 71 Requisitos y Estudio de Viabilidad del Sistema

72 PRE-SELECCIÓN DE ALTERNATIVAS DE SOLUCIÓN Al tener los requisitos a satisfacer por el sistema, se deben estudiar las diferentes opciones que hay para configurar la solución. Entre ellas, se considera 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 Al momento de realizar el análisis no se había encontrado ningún sistema software en el mercado que permita generar un banco de prueba de proyectos de explotación de información que pueda ser utilizado para analizar el método de estimación propuesto. Por tal motivo, la única alternativa viable para cubrir la necesidad existente fue la construcción de un sistema software a tal efecto DESCRIPCIÓN DE ALTERNATIVAS DE SOLUCIÓN Por cada alternativa propuesta, se identifican los subsistemas que cubre y los requisitos a los que satisface. También se consideran los aspectos relativos a la cobertura geográfica de procesos y datos, y teniendo en cuenta su ámbito, limitaciones, la gestión de comunicaciones y el control de la red. Para 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. En el caso de que la alternativa incluye desarrollo, se debe describir el modelo abstracto de datos y el modelo de procesos. Si se utiliza el paradigma de Orientación a Objetos, también se describe el Modelo de Negocio y, opcionalmente, el Modelo de Dominio. Así, 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. Cuando 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. Como en el desarrollo del presente sistema software no se han encontrado alternativas de solución, por lo que se realiza el análisis de la única alternativa existente sin tener que compararla con ninguna otra. Ing. Pablo Pytel 72 Requisitos y Estudio de Viabilidad del Sistema

73 Descripción de la Solución Se estableció como única alternativa viable la construcción de un nuevo sistema software, para el cual se han definido los requisitos funcionales y no funcionales para los módulos que componen el mismo. Para dichos módulo tampoco existió ninguna alternativa de solución. A continuación se detalla la solución para cada módulo en particular: Módulo 1 Configuración de Parámetros: Se solicita al usuario configurar los parámetros necesarios para generar los valores de las características generadas para los proyectos de explotación de información que son utilizados para generar el banco de pruebas. Módulo 2 - Generación de Banco de Prueba: Se genera un banco de prueba compuesto por los valores de las características generadas para los proyectos de explotación de información junto con los resultados de aplicar las fórmulas de estimación propuestas por el método DMCoMo. Además se muestra en pantalla los resultados de aplicar las fórmulas de estimación junto con gráficos para poder facilitar su análisis. Además será posible exportar los datos del banco de prueba en archivos de texto con un formato que permita ser utilizados desde aplicaciones de administración de planillas de cálculo (como por ejemplo Microsoft Excel) VALORACIÓN DE LAS ALTERNATIVAS Esta actividad tiene el objetivo de estudiar los riesgos y comparar las soluciones alternativas que cumplan los requisitos definidos para el proyecto. Sin embargo, como se ha mencionado anteriormente, no se han encontrado alternativas de solución para el sistema software, existiendo sólo una solución para ser desarrollada ESTUDIO DE RIESGOS Para la solución propuesta no se detectaron riesgos evidentes ya que el sistema software tiene fines académicos y además el objetivo del sistema software es generar bancos de prueba de proyectos de explotación de información con su estimación donde no hay posibilidad de perder los resultados de proyectos reales y, en caso necesario, los bancos de Ing. Pablo Pytel 73 Requisitos y Estudio de Viabilidad del Sistema

74 prueba pueden volver a generarse fácilmente en cualquier momento por la ejecución del sistema software Valoración de Alternativas La única alternativa válida para la solución del problema planteado consistió en construir el sistema software previamente descripto PLANIFICACIÓN DE ALTERNATIVAS De acuerdo al análisis de riesgos realizado en la tarea anterior y, para cada una de las alternativas existentes, se realiza las siguientes tareas: Se determina el enfoque más adecuado para obtener exitosamente 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 Dado que en este trabajo se detectó una única alternativa válida para la solución del problema planteado, las actividades correspondientes a la estimación y planificación de las tareas se explican en la sección 4 Gestión del Proyecto de este trabajo SELECCIÓN DE LA SOLUCIÓN Esta última actividad del Estudio de Viabilidad del Sistema tiene el objetivo de realizar la convocatoria 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 procede a la aprobación de la solución o se determina su inviabilidad. En este caso, por haber sido detectada una única alternativa, solamente se evaluó la aprobación de la misma como solución al problema. Ing. Pablo Pytel 74 Requisitos y Estudio de Viabilidad del Sistema

75 CONVOCATORIA DE LA PRESENTACIÓN Esta tarea consiste en efectuar la convocatoria con la presentación de las distintas alternativas propuestas, adjuntando los productos de la actividad anterior con el fin de que el Comité de Dirección pueda estudiar previamente su contenido Plan de Presentación de Alternativas La convocatoria no se realizó debido que se había detectado una única alternativa de solución EVALUACIÓN DE LAS ALTERNATIVAS DE SELECCIÓN Una vez recibida la confirmación de cuáles son alternativas que serán presentadas para su valoración, se presenta al Comité de Dirección donde se procede al debate 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 Al ser la única alternativa existente, se procedió solamente a la evaluación de si es aprobada o no APROBACIÓN DE LA SOLUCIÓN El Comité de Dirección decide la aprobación formal o la inviabilidad del sistema, indicando los motivos correspondientes tales como: aspectos 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 Luego de realizar una reunión mantenida entre el tesista y los directores del proyecto de tesis, se dio como válida a la actual propuesta de desarrollo y se consideró aprobada la misma para continuar con las actividades correspondientes a la iniciación del proyecto de desarrollo. Ing. Pablo Pytel 75 Requisitos y Estudio de Viabilidad del Sistema

76

77 CAPÍTULO 4 GESTIÓN DEL PROYECTO

78

79 4. GESTIÓN DEL PROYECTO 4.1. INTRODUCCIÓN La Gestión de Proyectos tiene como objetivo lograr conocer en todo momento qué problemas se producen en el proyecto y cómo resolverlos (o paliarlos de manera inmediata) mediante una planificación, seguimiento y control de las actividades, así como de los recursos humanos y materiales que intervienen en el desarrollo de un sistema de información. En este trabajo se decidió utilizar la interfaz de Gestión de Proyectos de Métrica Versión III [Métrica III, 2000], la cual contempla proyectos de desarrollo de sistemas de información en sentido amplio. Es decir, considera tanto proyectos de desarrollo de sistemas de información nuevos como también proyectos de ampliación y mejora de sistemas de información ya existentes (estos últimos, son contemplados en el proceso de Mantenimiento del Sistema de Información). Dentro de la de gestión de proyectos para este proyecto se distinguen tres actividades importantes: Las actividades de Inicio del Proyecto que se realizan al concluir el Estudio de Viabilidad e incluyen las actividades de estimación de esfuerzo, definición de las actividades del Proceso Software y la planificación del proyecto. Las actividades de Gestión de Configuración que incluye el control de los cambios producidos durante el desarrollo. Las actividades de Gestión de Calidad que incluye la definición y puesta en marcha de planes específicos de aseguramiento de calidad aplicables al proyecto INICIO DEL PROYECTO Las Actividades Inicio del Proyecto (GPI) de Métrica Versión III tienen un doble objetivo: por un lado estimar el esfuerzo necesario para desarrollar el sistema software y por otro planificar las actividades de dicho desarrollo. Se utiliza como punto de partida la solución seleccionada en el Estudio de Viabilidad del Sistema (EVS), del cual se identifican los elementos a desarrollar, se calcula el esfuerzo a realizar, y finalmente se planifican las actividades del proyecto comprendiendo los aspectos de recursos, programación de tareas y establecimiento de un calendario de entregas y recepciones entre el cliente y los proveedores. Ing. Pablo Pytel 79 Gestión del Proyecto

80 ESTIMACIÓN DEL ESFUERZO Esta actividad tiene el objetivo de conocer el tamaño aproximado del sistema software, y establecer el coste, la duración y los recursos necesarios para conseguir su desarrollo. Para ello se utilizan técnicas existentes de estimación software para realizar los cálculos que proporcionan un valor aproximado suficiente para el alcance del desarrollo del proyecto. De todas formas, es siempre útil la experiencia anterior que hubiese, extraída de la realización de proyectos similares en la organización, así como la existencia de una base de datos con información relativa a métricas, en el sentido del término en Ingeniería del Software Estimación del sistema En este trabajo se decidió utilizar el método de estimación la técnica de Punto de Función [Albrecht, 1983] y COCOMO II [Boehm et al., 1995; Boehm et al., 2000] para para la estimación del tamaño y tiempos del presente desarrollo se utilizan. ESTIMACIÓN DE PUNTOS DE FUNCIÓN: En la tabla AGP 1 se indican las valoraciones hechas para cada una de las características básicas del proyecto evaluadas durante la estimación de los puntos de función. Tipo de Parámetro Parámetro Cantidad por Complejidad Descripción Justificación 1- Selección de tamaño de Tipos de Función Transacción Entradas Externas -Complejidad Baja = 3 -Complejidad Media = 2 -Complejidad Alta = 0 proyecto. 2- Selección si se generan valores de costo aleatoriamente. 3- Ingreso de valor de factor de costo. 4- Ingreso de parámetros de exportación. 5- Selección del modo de generación y procesamiento Las entradas son pocas, se consideran que las entradas donde el usuario elige de una lista tienen complejidad baja (ítems 1, 2 y 5) y el resto (ítems 3 y 4) tienen complejidad media. de proyectos. Ing. Pablo Pytel 80 Gestión del Proyecto

81 Tipo de Parámetro Parámetro Cantidad por Complejidad Descripción Justificación 1- Modo de operación de un Salidas -Complejidad Baja = 2 -Complejidad proyecto. 2- Modo de operación de evaluación continua. 3- Modo de operación de análisis completo. 4- Mostrar Estadísticas de Se considera un nivel de complejidad alta para los gráficos (ítems 5 y 7), media para la tabla de datos y los modos de opera- Externas Media = 3 las estimaciones. ción con ciclo (ítems 2, -Complejidad Alta = 2 5- Gráfico de histograma con estimaciones. 6- Gráfico de frecuencia de ocurrencia. 7- Tabla de datos de pro- 3 y 7), y baja para las estadísticas de las estimaciones y el modo de operación sin ciclos (ítems 1 y 4). yectos generados. -Complejidad Consultas Externas Baja = 0 -Complejidad Media = 0 - No se provee ninguna pantalla de consulta para ser provista por el -Complejidad sistema software. Alta = 0 -Complejidad Tipos de Función Datos Archivos Lógicos Internos Baja = 0 -Complejidad Media = 0 -Complejidad 1- Archivo de exportación con datos de proyectos generados y estimados. Se considera que la generación del archivo de exportación tiene una complejidad alta. Alta = 1 Ing. Pablo Pytel 81 Gestión del Proyecto

82 Tipo de Parámetro Parámetro Cantidad por Complejidad Descripción Justificación -Complejidad Archivos Lógicos Externos Baja = 0 -Complejidad Media = 0 -Complejidad El sistema no interactuará con ningún otro sistema externo Alta =0 Tabla AGP 1: Parámetros básicos del sistema A partir de la información de la tabla AGP 1, se calculó el valor de los puntos de función sin ajustar [Métricas III] en la tabla AGP 2: Parámetro Complejidad Peso Total - Baja = Entradas Externas - Media = Alta = Baja = Salidas Externas - Media = Alta = Baja = Consultas Externas - Media = Alta = Baja = Archivos Lógicos Internos - Media = Alta = Baja = Archivos Lógicos Externos - Media = Alta = TOTAL FP 69 Tabla AGP 2: Cálculo de los puntos de función Luego de ingresar los parámetros básicos se procedió a realizar la valoración de los factores de ajuste, los cuales se definen en la tabla AGP 3. Ing. Pablo Pytel 82 Gestión del Proyecto

83 Factor Valor Descripción Comunicación de datos 1 Funciones Distribuidas 1 La aplicación es por lotes o utilizando un ordenador personal. La aplicación prepara datos para que el usuario final los procese en otro componente del sistema (en este caso en una planilla de cálculo) Rendimiento 0 No existen requisitos de rendimiento. Configuraciones fuertemente utilizadas 0 No existen restricciones de este tipo Frecuencia de las transacciones 0 No existe una definición del período punta de transacciones. Entradas de datos On-Line 0 Todas las transacciones se procesan por lotes. Eficiencia del usuario final 1 Actualización On-Line 0 El sistema va a contar con: Menú Selección mediante cursor de datos en pantalla Interfaces de ratón. No proporciona actualización on-line de los ficheros lógicos internos. Procesos complejos 1 Realiza procesos matemáticos complejos. Reutilización 0 No es necesario considerar la reutilización. Facilidad de instalación 0 Facilidad de operación 0 Instalación en distintos lugares 0 Facilidad de cambios 0 No se realizaron consideraciones ni se requirieron desarrollos especiales para la instalación por parte del usuario. No se definieron por parte del usuario necesidades especiales de operación o respaldo de distintas de las normales. No existen requisitos del usuario para considerar la necesidad de más de un usuario o lugar de instalación. No existe ninguna especificación por parte de los usuarios en este sentido TOTAL 4 Tabla AGP 3: Factores de Ajuste Luego se calcula el factor de ajuste como: AF = 0,65 + (0,01 x 4) = 0,69 Ing. Pablo Pytel 83 Gestión del Proyecto

84 Y la medida de puntos de función como: FPA = FP x AF = 69 x 0,69 = 47,61 En base a las ponderaciones ingresadas se obtuvo el siguiente resultado que se muestra en la tabla AGP 4. Para ello se estimó que la cantidad de líneas de código por punto de función en Java es de 30 líneas. Puntos de función sin ajustar 69 Factor de ajuste 0,69 Puntos de función ajustados 47,61 Líneas de código Tabla AGP 4: Resultado de la estimación de puntos de función ESTIMACIÓN DE COCOMO II: Una vez obtenida la cantidad estimada de líneas de código mediante puntos de función, se procedió a realizar la estimación del esfuerzo mediante la técnica COCOMO II. Debe tenerse en cuenta que en este trabajo no se consideró el valor de costo de la hora/hombre de trabajo debido a que este proyecto de desarrollo no posee fines económicos sino que tiene sólo fines académicos. De acuerdo a las características del sistema software se consideró que corresponde al modo y modelo definido en la tabla AGP 5. Justificación: Modo Orgánico El proyecto se desarrolla en un entorno estable y relativamente relacionado en cuanto a exigencia por parte de los usuarios para que el software cumpla las especificaciones y pueda ser desarrollado más fácilmente. Además su tamaño es pequeño (menos de líneas de código). Ing. Pablo Pytel 84 Gestión del Proyecto

85 Modelo Básico Justificación: Desarrollos de producto software de tamaño pequeño. Tabla AGP 5: Modo y Modelo seleccionado para COCOMO II Por lo tanto, las ecuaciones de estimación de esfuerzo y tiempo de desarrollo utilizadas fueron: MM = 2,4 x (KDSI) 1,05 TDEV = 2,5 x (MM) 0,38 dónde: KDSI = número de instrucciones de código en miles. MM = esfuerzo medido en meses/hombre. TDEV = duración en meses. Entonces el resultado de aplicar las fórmulas fue: MM = 2,4 x ( 1,428 ) 1,05 = 3, Meses/Hombre TDEV = 2,5 x (MM) 0,38 = 2,5 x ( 3,4888 ) 0,38 = 4, Meses Nº medio de empleado = 4 / 4 = 1 Persona Interpretación de los Resultados En base a las estimaciones hechas mediante la aplicación de puntos de función y COCOMO II, se puede indicar que el sistema es factible de ser desarrollado por un solo desarrollador (en este caso el tesista) en un tiempo inferior a medio año PROCESO SOFTWARE El Proceso Software es la colección de actividades que se realiza para poder realizar la construcción satisfactoria de un producto o sistema software. Comienza con la identificación de una necesidad y concluye con el retiro del software que satisface dicha necesidad. El proceso software más básico debe estar formado por seis etapas: Obtención de Requisitos, Diseñar, Implementar, Realizar Pruebas, Instalar, y Mantener y Ampliar. Sin embargo, debido a que estas actividades están interrelacionadas, se pueden plantear Ing. Pablo Pytel 85 Gestión del Proyecto

86 diferentes alternativas de cómo realizarlas. Las cuales se definen mediante la combinación de: un Ciclo de Vida, donde se definen los estados por los que va a pasar el producto software para su construcción, y un Mapa de Actividades, que indica qué actividades del proceso software genérico se van a ejecutar y en qué orden para un determinado proyecto Selección del Ciclo de Vida El Ciclo de Vida tiene el doble objetivo de, por un lado, determinar el orden de las fases del Proceso Software y, por otro, establecer los criterios de transición para pasar de una fase a la siguiente. Luego de analizar las características principales del proyecto de este trabajo se optó por utilizar el ciclo de vida de software iterativo incremental el cual tiene dos ciclos para realizar las fases de Análisis, Diseño, Construcción y Pruebas. Este modelo se muestra gráficamente en la figura AGP 1. La decisión para seleccionar este modelo se basó en las siguientes consideraciones: Todos los requisitos del sistema software son conocidos y estables. El tamaño del proyecto es mediano y no posee interacciones con otros sistemas software. No existen riesgos asociados al proyecto debido a que se trata de un sistema software con fines académicos. Por otro lado este modelo posee las siguientes características que se consideraron positivas para este proyecto: Se considera que para que un proyecto tenga éxito, todos los estados señalados en el modelo deben ser desarrollados. Se reduce el tiempo de desarrollo inicial debido a que no incluye la funcionalidad completa. En el primer ciclo se construye las funcionalidades principales (el núcleo del software), al que en el segundo ciclo se le incluye el resto de las funcionalidades. Las etapas están organizadas de un modo lógico. Es decir, si una etapa no puede llevarse a cabo hasta que se hayan tomado ciertas decisiones de más alto nivel, debe esperar hasta que esas decisiones estén tomadas. Así, el diseño espera a los requisitos, el código espera a que el diseño esté terminado, etc. Cada etapa incluye cierto proceso de revisión, y se necesita una aceptación del producto antes de que la salida de la etapa pueda usarse. Así se busca que se pase el menor número de errores de una etapa a la siguiente. Ing. Pablo Pytel 86 Gestión del Proyecto

87 Figura AGP 1: Ciclo de Vida Incremental Alcance de los Ciclos de Desarrollo Dado que en este trabajo se decidió utilizar un ciclo de vida incremental con dos ciclos de desarrollo, fue necesario definir qué requisitos se debían incluir en cada uno. A continuación se define el alcance de los dos ciclos de desarrollo, utilizando los requerimientos extraídos del Catálogo de Requisitos (sección ): Ing. Pablo Pytel 87 Gestión del Proyecto

88 Primer Ciclo de Desarrollo En esta primera versión se ha desarrollado el núcleo de la funcionalidad del sistema software, o sea la posibilidad de generar y procesar proyectos de explotación de información (de a uno por vez o en forma continua). Para ello también fue necesario incluir las funcionalidades de configurar los parámetros generales y factores de costo. Queda excluido de esta primera versión la funcionalidad de visualizar las estadísticas generadas con sus gráficos correspondientes, exportar los datos a un archivo y el modo de operación análisis completo. De esta forma, los requisitos a ser incluidos en esta primera versión fueron: RF 1 Configurar Parámetros : RF 1.1 RF 2 Generar Datos de Proyecto : RF 2.1, RF 2.2 y RF 2.3. RF 3 Calcular Estimación de Esfuerzo : RF 3.1, RF 3.2, RF 3.3 y RF 3.4. RNF 1 Modos de Procesamiento de Proyectos : RNF 1.1 y RNF 1.2. RNF 2 Interfaz Gráfica : RNF 2.1, RNF 2.2 y RNF 2.3. RNF 3 Soporte de Sistemas Operativos : RNF 3.1, RNF 3.2 y RNF 3.3. Segundo Ciclo de Desarrollo En esta segunda versión se incluyeron las funcionalidades excluidas de la versión anterior, o sea la funcionalidad de visualizar las estadísticas generadas con sus gráficos correspondientes, exportar los datos a un archivo y el modo de operación análisis completo. Los requisitos a ser incluidos en esta segunda versión fueron: RF 1 Configurar Parámetros : RF 1.2. RF 2 Generar Datos de Proyecto : RF 2.4. RNF 1 Modos de Procesamiento de Proyectos : RNF 1.3. RNF 2 Interfaz Gráfica : RNF 2.4, RNF 2.5 y RNF 2.6. RNF 4 Restricciones de Carpetas : RNF 4.1, RNF 4.2. RNF 5 Generación de Archivos : RNF 5.1 y RNF Definición de Mapa de Actividades Debido a que no todos los proyectos de desarrollo de sistema software son iguales, una vez que se haya seleccionado un modelo de ciclo de vida, se debe adaptar el proceso de software genérico al proyecto en particular utilizando como marco ese ciclo de vida. Para ello, se establece una tabla que indica las actividades del proceso software que se deben Ing. Pablo Pytel 88 Gestión del Proyecto

89 realizar se van a ejecutar para cada una de las fases del ciclo de vida en el proyecto. Esta tabla se denomina Mapa de Actividades. Para el presente proyecto de desarrollo software, se decidió utilizar las actividades definidas por Métrica Versión III para el Desarrollo Orientado a Objetos. En la tabla AGP 6 se indica el mapa de actividades para el presente proyecto definido de acuerdo al estándar [IEEE, 1997]. Nótese que las actividades correspondientes al Mantenimiento del Sistema se han encontrado fuera del alcance de este trabajo de tesis por lo que no fueron consideradas. Actividades / Ciclo de Vida Primer Ciclo de Desarrollo Segundo Ciclo de Desarrollo I O A D C P A D C P ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI) ASI 1 Definición del Sistema X ASI 2 Establecimiento de Requisitos X X ASI 4 Análisis de los Casos de Uso X X ASI 5 Análisis de Clases X X ASI 8 Definición de Interfaces de Usuario X X ASI 9 Análisis de Consistencia y Especificación de Requisitos X X ASI 10 Especificación del Plan de Pruebas X X ASI 11 Aprobación del Análisis del Sistema de Información X X DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI) DSI 1 - Definición de la Arquitectura del Sistema. DSI 2 - Diseño de la Arquitectura de Soporte. X X X Ing. Pablo Pytel 89 Gestión del Proyecto

90 Actividades / Ciclo de Vida Primer Ciclo de Desarrollo Segundo Ciclo de Desarrollo I O A D C P A D C P DSI 3 - Diseño de Casos de Uso Reales. X X DSI 4 - Diseño de Clases. X X DSI 6 - Diseño Físico de Datos. DSI 7 - Verificación y Aceptación de la Arquitectura del Sistema DSI 8 - Generación de Especificaciones de Construcción. DSI 10 - Especificación Técnica del Plan de Pruebas. DSI 12 - Aprobación del Diseño del sistema de Información. CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI) X X X X X X X X X CSI 1 - Preparación del Entorno de Generación y Construcción CSI 2 - Generación del Código de los Componentes y Procedimientos X X X CSI 3 - Ejecución de las Pruebas Unitarias X X CSI 4 Ejecución de las Pruebas de Integración X X CSI 5- Ejecución de las Pruebas del Sistema X X CSI 6 Elaboración de los Manuales de Usuario X X CSI 9 - Aprobación del Sistema Software X X X X IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA DE INFORMACIÓN (IASI) IASI 1 - Establecimiento del Plan de Implantación X Ing. Pablo Pytel 90 Gestión del Proyecto

91 Actividades / Ciclo de Vida Primer Ciclo de Desarrollo Segundo Ciclo de Desarrollo I O A D C P A D C P IASI 2 Formación necesaria para la implantación IASI 3 - Incorporación del Sistema al Entorno de Operación IASI 4 - Carga de Datos al Entorno de Operación IASI 5 - Pruebas de Implantación del Sistema IASI 6 - Pruebas de Aceptación del Sistema X X X X X X X X X X IASI 9 - Presentación y Aprobación del Sistema Dónde: A = Fase de Análisis D = Fase de Diseño C = Fase de Construcción P = Fase de Pruebas I = Fase de Implantación O = Fase de Operación Tabla AGP 6: Mapa de Actividades del Proyecto X X Planificación de las Actividades Una vez seleccionado el Ciclo de Vida con el alcance de cada ciclo de desarrollo y definido el Mapa de actividades, se detalla en la figura AGP 2 el plan de proyecto para la construcción del sistema con formato de Diagrama de Gantt. Nótese que para la duración se tuvo en cuenta el trabajo de un desarrollador trabajando 8 horas diarias cinco días a la semana (40 horas semanales). La información referente al cronograma final obtenido al terminar el proyecto se puede ver en el anexo Registros de la Gestión del Proyecto (Apéndice D). Ing. Pablo Pytel 91 Gestión del Proyecto

92 Figura AGP 2: Planificación de Trabajo GESTIÓN DE CONFIGURACIÓN El objetivo de la Gestión de la Configuración es mantener la integridad de los productos que se obtienen a lo largo del desarrollo de los sistemas garantizando que no se realizan cambios incontrolados y que todos los participantes en el desarrollo del sistema disponen de la versión adecuada de los productos que manejan. Así se busca reducir errores, aumentar la calidad y la productividad, y evitar los problemas que puede acarrear una incorrecta sincronización en dichos cambios de requisitos y fallos, al afectar a otros elementos del sistema o, a las tareas realizadas por otros miembros del equipo de proyecto. Para ello se realiza un control de los elementos de configuración software y un registro de los cambios. Entre los elementos de configuración software, se encuentran no únicamente ejecutables y código fuente, sino también los modelos de datos, modelos de procesos, especificaciones de requisitos, pruebas, etc. Ing. Pablo Pytel 92 Gestión del Proyecto

93 La gestión de configuración se realiza durante todas las actividades asociadas al desarrollo del sistema, y continúa registrando los cambios hasta que éste deja de utilizarse. Durante el desarrollo permite controlar el sistema como producto global, obtener informes sobre el estado de desarrollo en que se encuentra y reducir el número de errores de adaptación del sistema, lo que se traduce en un aumento de calidad del producto, de la satisfacción del cliente y, en consecuencia, de mejora de la organización. Además, al aportar información precisa para valorar el impacto de los cambios solicitados y reducir el tiempo de implementación de un cambio (tanto evolutivo como correctivo) facilita el mantenimiento del sistema. La interfaz de gestión de configuración de Métrica Versión III permite definir las necesidades de gestión de configuración para cada sistema de información, recogiéndolas en un plan de gestión de configuración, en el que se especifican las actividades de identificación y registro de productos en el sistema de gestión de configuración durante el desarrollo y posterior mantenimiento del sistema de información. Los productos registrados en el sistema de gestión de la configuración se encuentran identificados y localizados unívocamente, de manera que la información relativa a los productos es de fácil acceso. La información que puede solicitarse al sistema de gestión de la configuración incluye: Información relacionada con Análisis, Diseño, Construcción, Implantación y Aceptación del Sistemas de Información, como productos globales que integran todos los productos que lo componen. Información de un producto en concreto, su versión, estado, traza de su evolución y cualquier dato que el plan de gestión de la configuración determine de interés (por ejemplo, participantes en la elaboración o modificación del producto). Sin embargo, debe considerarse que si en la organización ya existiera un sistema de gestión de configuración estándar, para el sistema de información en concreto se deben analizar las necesidades de configuración específicas respecto a dicho sistema estándar y determinar las diferencias, si las hubiera, así como aquellas necesidades concretas que no se encuentren recogidas, estableciendo así el plan de gestión de configuración del sistema de información. No es el caso de este proyecto por tratarse de un trabajo totalmente autónomo. Finalmente, no debe tomarse al Plan de Gestión de Configuración como algo estático que se define al inicio del desarrollo del sistema y nunca más se modifica. Este plan debe revisarse y validarse al inicio de cada una de las fases del proyecto, modificándolo en caso de ser necesario. Todas las modificaciones al Plan de Gestión de Configuración Ing. Pablo Pytel 93 Gestión del Proyecto

94 deberán ser realizadas por quien lleva a delante el proceso de Gestión de Configuración del Proyecto. Quien ante cada pedido de cambio lleva a cabo una revisión formal del pedido e impulsa la implementación del mismo en caso de considerarlo necesario ESTÁNDARES DE GESTIÓN DE CONFIGURACIÓN Para el actual proyecto de desarrollo del sistema software, se ha decidido consultar los estándares de Gestión de Configuración definidos por ANSI e IEEE [IEEE, 1987]. Considerando estos estándares se definió el presente plan, por lo cual no se sigue exactamente los pasos definidos por Métrica Versión III. Ya que se había seleccionado el ciclo de vida incremental para ser utilizado en el proyecto, fue posible identificar a las líneas base del proyecto y sus elementos de configuración. Es decir, todos las salidas del proceso de software que necesiten, por su importancia para el proyecto, ser identificados y almacenados de forma controlada. Dicho control implica: identificar de forma univoca a cada elemento y corroborar el estado del mismo (validando su corrección y completitud). Asimismo, en esta sección se identifican las tareas de coordinación y gestión que son necesarias para llevar a cabo las actividades de Gestión de Configuración del Software en el proyecto de desarrollo del sistema software ORGANIZACIÓN DE GESTIÓN DE CONFIGURACIÓN Toda Gestión de Configuración del Proyecto debe estar a cargo de un responsable denominado Responsable de la Gestión de Configuración, que es parte del equipo de desarrollo. Sin embargo, aunque normalmente es recomendable contar con distintas personas para la implementación de cada una de las funciones de Gestión de Configuración, debido a las características del presente proyecto las mismas fueron distribuidas entre los integrantes del equipo de desarrollo del proyecto (es decir, los Directores del Proyecto de Tesis y el tesista). Esto pone de manifiesto la importancia de desarrollar proyectos con metodologías de trabajo flexibles que se puedan adaptar a las características de cada proyecto y su equipo de desarrollo. Por la magnitud del presente proyecto no fue necesario constituir un Comité de Control de Cambios, sino que los mismos serán tratados y evaluados por el Responsable de la Gestión de Configuración (función realizada por el tesista). Por otro lado, se considera necesaria que se realicen un conjunto de auditorías y controles por personal ajeno al equipo de desarrollo, para controlar la labor desarrollada por el Ing. Pablo Pytel 94 Gestión del Proyecto

95 Responsable de la Gestión de Configuración. Esta función quedó a cargo de uno de los Directores del Proyecto de Tesis ACTIVIDADES DE GESTIÓN DE CONFIGURACIÓN A REALIZAR Las tareas asociadas al presente Plan de Gestión de Configuración del Software se detallan a continuación: 1) Crear y mantener un Plan de Gestión de Configuración para la organización. 2) Asegurar el cumplimiento a nivel organizacional del estándar de gestión de configuración. 3) Proveer guías organizacionales para todas las actividades de gestión de configuración. 4) Asegurar que los cambios sobre la línea base se registran con suficiente detalle. 5) Asegurar que no se realicen cambios no autorizados sobre la línea base. 6) Operación de la herramienta de gestión de configuración. 7) Aprobar, monitorear y controlar requerimientos de cambios. 8) Establecer líneas base. 9) Auditar el proyecto IMPLEMENTACIÓN DEL PLAN DE GESTIÓN DE CONFIGURACIÓN Para realizar la implementación del plan de gestión de configuración se definen las siguientes cuestiones: Asignación de Actividades Primero se asignan las actividades definidas en la sección anterior a los integrantes del equipo. En la tabla AGP 7 se muestra la asignación de las tareas. Actividad Asignado a 1) Crear y mantener un Plan de Gestión de Configuración para la organización. 2) Asegurar el cumplimiento a nivel organizacional del estándar de gestión de configuración. 3) Proveer guías organizacionales para todas las actividades de gestión de configuración. 4) Asegurar que los cambios sobre la línea base se registran con suficiente detalle. Responsable de la Gestión de Configuración (el tesista) 5) Asegurar que no se realicen cambios no autorizados Ing. Pablo Pytel 95 Gestión del Proyecto

96 sobre la línea base. Actividad Asignado a 6) Operación de la herramienta de gestión de configuración. 7) Aprobar, monitorear y controlar requerimientos de cambios. 8) Establecer líneas base. 9) Auditar el proyecto. Auditor de Gestión de Configuración (uno de los Directores del Proyecto de Tesis) Tabla AGP 7: Asignación de actividades de Gestión de Configuración Auditorías Las auditorias de configuración fueron llevadas a cabo en el proyecto a solicitud del Director del proyecto de Tesis, quien verifica el cumplimiento de los pasos definidos dentro de la metodología de desarrollo Selección de Repositorio Debe considerarse que todos los elementos de configuración del proyecto que se encuentren bajo control de configuración son almacenados en un repositorio electrónico de proyecto cuyo acceso es limitado a aquellos participantes autorizados del proyecto. En caso de requerirse copias físicas de algún documento, dicha copia es numerada de manera unívoca; cualquier cambio sobre el documento requiere de la obtención de la versión controlada anterior y la sustitución de la misma por una nueva. Si bien no se cuenta con una herramienta especifica de gestión de configuración, se utilizó el Software GESMET para la generación de los documentos en la etapa de desarrollo. El mencionado software genera un documento por cada actividad definida en la metodología Métrica Versión III, cuando el tesista consideró que la fase metodológica estaba terminada unificó todos los documentos que completó en uno solo y lo presentó al Director del Proyecto de Tesis. Una vez que el documento es aprobado por el Director del proyecto de tesis, se resguardó en una carpeta llamada LineaBase que contiene una subcarpeta por cada fase de la metodología. Ing. Pablo Pytel 96 Gestión del Proyecto

97 Por otra parte, se registró en una planilla de Microsoft Excel, cada uno de los documentos ingresados a esta carpeta indicando: su nombre, la versión, la fecha en que fue ingresado, una breve descripción de propósito del mismo y el motivo de su generación. De esta manera cuando era necesario realizar alguna modificación a un documento (producto de alguna corrección generada por alguna iteración del proceso de desarrollo) quedó registrado cuál era el cambio realizado y por qué Identificación de la Configuración Esta tarea tiene el objetivo de definir e identificar todos los elementos de configuración que forman parte del proyecto. Estos elementos de configuración se determinan en función del ciclo de vida seleccionado para el proyecto. Para mayor facilidad de aplicación de las funcionalidades del software GESMET, se tomó al documento principal de cada una de las fases de la metodología como un elemento de configuración (este documento creado con Microsoft Word, contiene todos los documento que para cada fase de desarrollo se produjeron mediante GESMET) junto con los documentos auxiliares que el mismo contiene. Se definen las siguientes líneas base a establecer: Línea base de Planificación del Sistema de Información Línea base de Estudio de Viabilidad del Sistema Línea base de Análisis del Sistema de Información Línea base de Diseño del Sistema de Información Línea base de Construcción del Sistema de Información Línea base de Implementación del Sistema de Información Todos los elementos de configuración de tipo documento, fueron almacenados antes de ser aprobados y pasados a línea base, en la carpeta Tesis_Desarrollo_Docum, mientras que los elementos del tipo software (código fuente y ejecutables) fueron almacenados en la carpeta Tesis_Desarrollo_Prog_ <Versión>. La identificación de los distintos elementos de configuración se detalla a continuación: Documentos: El nombre de los documentos debe seguir la siguiente nomenclatura: <ID_Documento> + <Versión> +. + <Extensión> Dónde: Ing. Pablo Pytel 97 Gestión del Proyecto

98 ID_Documento: es el nombre del documento a resguardar, ver definición en la tabla AGP 8. Versión: es un número secuencial que se asigna al documento, comienza en uno y se incrementa de a uno por cada nueva versión del mismo. Extensión: es el tipo de archivo. Programas Fuentes y Ejecutables: Para la administración de los programas fuentes y ejecutables el esquema de identificación es el siguiente: por cada nueva versión de programa se genera una nueva carpeta que contendrá los objetos del proyecto a modificar. La forma de identificar a estas carpetas es la siguiente: Tesis_Desarrollo_Prog + <ID_Versión> Dónde: ID_Versión: es un número secuencial que se asigna al documento, comienza en 1 y se incrementa de a 1 por cada nueva versión del mismo A continuación en la tabla AGP 8 se detalla cómo se compone cada línea base, es decir que elementos de configuración que la integran. Línea Base Planificación del Sistema de Información (PSI) Estudio de Viabilidad del Sistema (EVS) Análisis del Sistema de Información (ASI) Diseño del Sistema de Información (DSI) Construcción del Sistema de Información (CSI) Elementos de configuración Planificación del Sistema de Información Diagramas de planificación Complementarios (por ej.: diagramas GANTT) Estudio de Viabilidad del Sistema Diagramas de Viabilidad Complementarios (por ej.: modelo de negocio) Análisis del Sistema de Información Diagramas de Análisis Complementarios (casos de uso y diagramas de clases) Diseño del Sistema de Información Diagramas de planificación Complementarios (por ej.: diagramas de secuencia) Construcción del Sistema de Información Diagramas de planificación Complementarios Código fuente - Id. de los elementos (documentos) Planificación Diag-Planificación Viabilidad Diag-Viabilidad Análisis Diag-Análisis Diseño Diag-Diseño Construcción Diag-construcción Ing. Pablo Pytel 98 Gestión del Proyecto

99 Línea Base Implementación del Sistema de Información (ISI) Ejecutables Elementos de configuración Entorno de desarrollo (contempla versión de sistema operativo, entorno de desarrollo, etc.) Implementación del Sistema de Información Diagramas de planificación Complementarios Id. de los elementos (documentos) Implementación Diag-Implementación Tabla AGP 8: Relación entre líneas base y elementos de configuración Para el alojamiento de un elemento de configuración en una línea base, se generaron dos carpetas similares a las creadas para la etapa de desarrollo, donde se incorporan los elementos aprobados por los Directores del Proyecto de Tesis. Finalmente, no existen requerimientos especiales para la aplicación de un esquema de control de interfaces en el presente proyecto Administración de Cambios El tesista fue el responsable por aprobar, rechazar y controlar la correcta implementación de los cambios que se produzcan sobre aquellos documentos que formen parte de la línea base del proyecto. Además fue el responsable de resolver situaciones relacionadas con el cambio de alcance del proyecto. Por otro lado, fue conveniente utilizar un procedimiento que permita administrar cambios en los elemento de configuración (documentos y código fuente) una vez que los mismos pasen satisfactoriamente sus revisiones y debían incorporarse a la línea base, también se previeron procedimientos de administración de cambio ante cambios que afecten el calendario o el tamaño del proyecto. El procedimiento propuesto para incorporar un documento a la línea base del proyecto comprende la realización de los siguientes pasos: 1) Cuando un documento se encuentra en condiciones de ser revisados, el autor del mismo (el tesista) le aplica una etiqueta con el siguiente formato: Nombre de la de desarrollo a la cual pertenece + <número de versión> Por ejemplo: Planificacion_1.doc, este nombre indica que se está presentando la versión 1 de la fase de Planificación del Sistema. 2) Llevar a cabo la reunión de revisión con el Director del proyecto de Tesis. 3) Cuando después de realizar la revisión es necesario corregir el documento, se le asigna al mismo una nueva etiqueta de línea base según el siguiente formato: Ing. Pablo Pytel 99 Gestión del Proyecto

100 Nombre de la de desarrollo a la cual pertenece + <último número de versión asignado para la fase> + 1 Siguiendo con el ejemplo del punto 1, el nombre del documento modificado quedaría así: Planificacion_2.doc Diseño de Registros Debido a todas tareas de construcción para el presente proyecto estaban a cargo de un único desarrollador (el tesista), solo se consideró necesario llevar registro de los elementos de configuración cuando los mismos ingresan a las líneas base. A continuación, se detalla el formato de la planilla Microsoft Excel que contendrá la información de los elementos de configuración incorporados a las líneas base: Documento Versión Fecha ingreso Propósito Motivo del cambio Tabla AGP 9: Diseño de la planilla de registración de elementos de configuración Ejemplos de los registros llevados durante el proyecto se pueden ver en el anexo Registros de la Gestión del Proyecto (Apéndice D) Resguardo y Retención de Registros Las carpetas del repositorio fueron resguardadas semanalmente mediante la generación de dos CD de back-up para estas carpetas (labor que realiza el tesista). Uno de los CD de back-up era guardado en la oficina del tesista, mientras que la otra copia de back-up era almacenada en la facultad hasta culminar el desarrollo del proyecto Control de la Configuración El control de configuración del proyecto fue regido por lo indicado en esta sección sin realizarse ningún tipo de desviación de dicho procedimiento PLAN DE ASEGURAMIENTO DE LA CALIDAD La interfaz de Aseguramiento de la Calidad de Métrica Versión III tiene el objetivo de proporcionar un marco común de referencia para la definición y puesta en marcha de planes específicos de aseguramiento de calidad aplicables a proyectos concretos. Si se considera que como Calidad se define al grado en que un conjunto de características inherentes cumple con unos requisitos, entonces el Aseguramiento de la Calidad Ing. Pablo Pytel 100 Gestión del Proyecto

101 debe lograr que el producto reúna las características necesarias para satisfacer todos los requisitos del Sistema de Información. Por lo tanto, se debe realizar un conjunto de actividades que sirvan para: Reducir, eliminar y prevenir las deficiencias de calidad de los productos a obtener. Alcanzar una razonable confianza en que las prestaciones y servicios esperados por el cliente o el usuario queden satisfechas. Es necesario desarrollar un plan de aseguramiento de calidad específico que se aplica durante la planificación del proyecto de acuerdo a la estrategia de desarrollo adoptada en la gestión del proyecto para lograr esos objetivos. En este plan se reflejan las actividades de calidad a realizar (normales o extraordinarias), los estándares a aplicar, los productos a revisar, los procedimientos a seguir en la obtención de los distintos productos durante el desarrollo en Métrica Versión III y la normativa para informar de los defectos detectados a sus responsables y realizar el seguimiento de los mismos hasta su corrección. El grupo de aseguramiento de calidad participa en la revisión de los productos seleccionados para determinar si son conformes o no a los procedimientos, normas o criterios especificados, siendo totalmente independiente del equipo de desarrollo. Las actividades a realizar por el grupo de aseguramiento de calidad vienen gobernadas por el plan. Sus funciones están dirigidas a: Identificar las posibles desviaciones en los estándares aplicados, así como en los requisitos y procedimientos especificados. Comprobar que se han llevado a cabo las medidas preventivas o correctoras necesarias. Una de las actividades más importantes del aseguramiento de la calidad son las revisiones, debido a que permiten eliminar defectos lo más pronto posible, o sea, cuando son menos costosos de corregir. La detección anticipada de errores evita el que se propaguen a los restantes procesos de desarrollo, reduciendo substancialmente el esfuerzo invertido en los mismos. Además existen otros procedimientos extraordinarios, como las auditorias, aplicables en desarrollos singulares y en el transcurso de las cuales se revisan tanto las actividades de desarrollo como las propias de aseguramiento de calidad. Es importante destacar que el establecimiento del plan de aseguramiento de calidad comienza en el Estudio de Viabilidad del Sistema y se aplica a lo largo de todo el desarrollo, en los procesos de Análisis, Diseño, Construcción, Implantación y Aceptación del Sistema y en su posterior Mantenimiento. Ing. Pablo Pytel 101 Gestión del Proyecto

102 OBJETIVOS DEL PLAN DE CALIDAD Se detallan a continuación los siguientes objetivos de calidad que han sido seleccionados para el actual proyecto: Objetivos de funcionamiento: Se decide que el producto software no se aceptará si en las pruebas de aceptación surgen errores de severidad inferior o igual a 4, es decir que se registre algún error de severidad 1 (Sistema detenido), 2 (Fallas de funcionalidad), 3 (Una solución alternativa puede aplicarse) o 4 (Error de documentación/guía/ayuda). Para poder cumplir con este objetivo se recolectará un conjunto de métricas relacionadas con los resultados obtenidos en las pruebas de aceptación final (ver Métricas de Proyecto) DEFINICIÓN DE LOS RECURSOS En este proyecto, debido a las características fueron distribuidas entre los integrantes del equipo de desarrollo del proyecto (los Directores del Proyecto de Tesis y el tesista). El tesista fue responsable de asegurar que existan los medios adecuados para recolectar y documentar métricas que permitan soportar los objetivos definidos en el punto anterior. La información recolectada y documentada debió ser presentada ante uno de los Directores del Proyecto de Tesis quién hace las veces de Auditor del sistema MÉTRICAS DEL PROYECTO A continuación se definen las métricas utilizadas en el presente proyecto para luego describirlas Definición de las Métricas Primero se detallan las métricas a ser obtenidas y reportadas para el aseguramiento de la calidad del proyecto en la tabla AGP 10. Dicha tabla posee cuatro columnas: en la primera, llamada Métrica, se detallan la distintas métricas a aplicar; en la segunda, llamada Aplica, se indica si esta métrica es recabada en este proyecto; en la tercera, llamada Ubicación de Recolección, se indica donde se irán registrando estos informes; y Ing. Pablo Pytel 102 Gestión del Proyecto

103 en la cuarta, llamada Comentarios, se incorpora un breve comentario aclaratorio de algunos aspectos. Métrica Aplica Ubicación Comentarios Satisfacción del usuario Datos de calidad de pruebas Defectos posteriores a la entrega del primer prototipo Defectos detectados por el usuario Total de errores y defectos conocidos en el código al momento de entregar el producto Tiempo calendario y productividad para mejoras del producto Adecuación de la estimación de esfuerzo Adecuación de la estimación de calendario Adecuación de la estimación de tamaño del producto Productividad Cantidad de código reutilizado Cantidad de requerimientos de cambio No Si No No Si No Si Si Si Si No No Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Carpeta de Métricas Costos No Carpeta de Resultados de la encuesta realizada luego de la entrega del producto. Debido a que no hay usuarios reales, no se realiza dicha encuesta. Establece parámetros que permiten evaluar la calidad y cantidad de casos de prueba evaluados. Los defectos producidos durante el desarrollo serán controlados durante la fase de mantenimiento que es administrada como un proyecto independiente. Los defectos producidos durante el desarrollo serán controlados durante la fase de mantenimiento que es administrada como un proyecto independiente. El producto debe ser entregado libre de errores conocidos. El proyecto implica el desarrollo de un producto nuevo por lo que no aplica en este trabajo. Análisis de las horas/hombre dedicada a cada fase del proyecto. Análisis de los desvíos producidos respecto del Calendario estimado del proyecto, hecho en base a COCOMO II. Comparación del producto respecto de las estimaciones hechas mediante puntos de función. Análisis de la productividad del desarrollador en cada una de las fases del proyecto. Se aplicará en la creación de las futuras nuevas versiones, que podrán implementar nuevas funciones de gestión o metodologías de desarrollo (no contemplado en este trabajo). No se implementan requerimientos de cambio para el trabajo. Debido a que este proyecto no tiene fines económicos, no se registrara el Ing. Pablo Pytel 103 Gestión del Proyecto

104 Métrica Aplica Ubicación Comentarios Métricas Gestión de riesgos No Plan de Riesgos Cantidad de replanificaciones Si Carpeta de Métricas costo del proyecto Se analizará la aparición de los riesgos definidos y como se soluciona los mismo, debido a que no se han detectado riesgos esta métrica no se utiliza. Se documentará cada cambio producido sobre el plan del proyecto. Tabla AGP 10: Definición de las Métricas para el Aseguramiento de la Calidad Para poder llevar a delante el proceso de recolección de Métricas se incorporó al proyecto una carpeta llamada Métricas, la cual almacenó todos los documentos que contengan las distintas métricas obtenidas Descripción de las Métricas a Aplicar A continuación se describa las métricas identificadas en la tabla AGP 10 que fueron aplicadas a esta primer etapa del proyecto, las mismas pueden identificarse, debido a que en la columna Aplica se les ha asignado el valor Si. Los registros llevados durante el proyecto se pueden ver en el anexo Registros de la Gestión del Proyecto (Apéndice D). Datos de calidad de pruebas: En la tabla AGP 11 se detalla el formato de la planilla que recoge los datos que se utilizan para armar esta métrica. La planilla era guardada en un archivo llamado Calidad_Pruebas.xls. Tipo de prueba Fecha Resultado Cantidad de casos Probados Cantidad de casos libres de error Cantidad de errores de por severidad Tabla AGP 11: Datos de Calidad de Pruebas Total de errores y defectos conocidos en el código al momento de entregar el producto: A continuación, en la tabla AGP 12, se detalla el formato de la planilla que recoge los datos que se utilizan para armar esta métrica. La planilla era guardada en un archivo llamado Total_Errores.xls. Ing. Pablo Pytel 104 Gestión del Proyecto

105 Tipo de Error Ubicación Severidad Detectado por Posible solución Tabla AGP 12: Total de errores y defectos conocidos en el código al momento de entregar el producto Adecuación de la estimación de esfuerzo. En la tabla AGP 13 se detalla el formato de la planilla que recoge los datos que se utilizan para armar esta métrica. La planilla era guardada en un archivo llamado Adecuación_Esfuerzo.xls. Fase de Desarrollo Esfuerzo Estimado Esfuerzo Aplicado Diferencia Tabla AGP 13: Adecuación de la estimación de esfuerzo Adecuación de la estimación de calendario: En la tabla AGP 14 se detalla el formato de la planilla que recoge los datos que se utilizan para armar esta métrica. La planilla era guardada en un archivo llamado Adecuación_Calendario.xls. Tiempo Estimado Tiempo Aplicado Diferencia Tabla AGP 14: Adecuación de la estimación de calendario Adecuación de la estimación de tamaño del producto: En la tabla AGP 15 se detalla el formato de la planilla que recoge los datos que se utilizan para armar esta métrica. La planilla era guardada en un archivo llamado Adecuación_Tamaño.xls. Tamaño estimado Tamaño aplicado Diferencia Tabla AGP 15: Adecuación de la estimación de tamaño del producto Ing. Pablo Pytel 105 Gestión del Proyecto

106 Productividad: En la tabla AGP 16 se detalla el formato de la planilla que recoge los datos que se utilizan para armar esta métrica. La planilla era guardada en un archivo llamado Productividad.xls. Fase de desarrollo Tiempo estimado por Desarrollador Tiempo aplicado por Desarrollador Diferencia Tabla AGP 16: Productividad Cantidad de re-planificaciones: En la tabla AGP 17 se detalla el formato de la planilla que recoge los datos que se utilizan para armar esta métrica. La planilla era guardada en un archivo llamado Replanificaciones.xls. Fase de Desarrollo Fecha estimada en planificación anterior Fecha de re-planificación Nueva fecha Estimada Motivo de la re-planificación Tabla AGP 17: Cantidad de re-planificaciones AUDITORÍAS Para realizar las auditorías se asigna a uno de los Directores del Proyecto de Tesis como el encargado de llevarlas a cabo. Dichas auditorías podían ser planificadas con antelación o ser sorpresivas. Para estas últimas, se le podía solicitar al tesista que traiga información adicional a la correspondiente a la reunión semanal. Se desarrollan los siguientes tipos de auditorías: Auditorias Funcionales. Auditorias de Configuración. El tesista era responsable por asegurar que se aplican respuestas de manera adecuada y a tiempo a las acciones correctivas surgidas durante las auditorias. Ing. Pablo Pytel 106 Gestión del Proyecto

107 CAPÍTULO 5 PRIMER CICLO DE DESARROLLO: ANÁLISIS DEL SISTEMA DE INFORMACIÓN

108

109 5. PRIMER CICLO DE DESARROLLO: ANÁLISIS DEL SISTEMA DE INFORMACIÓN 5.1. INTRODUCCIÓN El objetivo del proceso de Análisis del Sistema de Información (ASI) es obtener una especificación detallada del sistema software que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema. Dado que Métrica Versión III es 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 define la descripción inicial del sistema software a partir de los productos resultantes del proceso Estudio de Viabilidad del Sistema (EVS). Esta actividad incluye la definición del alcance del sistema y la descripción del 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 para, finalmente, elaborar el plan de trabajo a seguir. Durante la actividad de Establecimiento de Requisitos se produce la definición de los requisitos del nuevo sistema. El objetivo de esta actividad es describir con precisión el sistema software de forma tal que sirva de base para comprobar que es completa la especificación de los modelos obtenidos en las siguientes 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. Todas estas actividades pueden producir que se deba actualizar los requisitos, pero esto no se refleja como producto de salida en dichas actividades ya que el objetivo de las mismas es definir modelos que soporten a los requisitos. Para poder obtener los requisitos en la actividad de Establecimiento de Requisitos se toman como punto de partida el catálogo de requisitos definido en el proceso Estudio de Viabilidad del Sistema (EVS) para el primer ciclo de desarrollo, y los modelos elaborados en la actividad Definición del Sistema los cuales son completados a través de sesiones de trabajo con los usuarios. Estas sesiones tienen como objetivo obtener toda la información necesaria para definir 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 estas se destacan las reuniones, entrevistas, Joint Application Design (JAD), brainstorming, etc. Para este tra- Ing. Pablo Pytel 109 Análisis del Sistema de Información (Primer Ciclo)

110 bajo, durante las sesiones de trabajo, se propone utilizar la especificación de los casos de uso como guía en el establecimiento de requisitos. La especificación de casos de uso facilita la comunicación con los usuarios y en el análisis orientado a objetos constituye la base de la especificación. En la actividad de Identificación de Subsistemas de Análisis, se establece la estructura del sistema software para facilitar la especificación de los distintos modelos y la lista de requisitos. En paralelo se generan los distintos modelos que sirven de base para el diseño: utilizando casos de análisis estructurado, se consigue la elaboración y descripción detallada del modelo de datos y de procesos, y utilizando análisis orientado a objetos, se elaboran el modelo de clases y el de interacción de objetos. Asimismo se especifican 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 de Análisis de Consistencia y Especificación de Requisitos se realiza la verificación y validación de los modelos, para asegurar que son: Completos, lo que significa que cada modelo obtenido contiene toda la información necesaria recogida en el catálogo de requisitos. Consistentes, lo que significa que cada modelo es coherente con el resto de los modelos. Correctos, lo que significa 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 de Especificación del Plan de Pruebas se establece el marco general del plan de pruebas, iniciándose su especificación, que se termina en el proceso Diseño del Sistema de Información (DSI). Es importante indicar que la participación activa de los usuarios es una condición imprescindible para el Análisis del Sistema de Información. A través que dicha participación se consigue garantizar que los requisitos identificados han sido comprendidos e incorporados en el sistema y, por lo tanto, de que éste es aceptado. Para poder lograr la colaboración de los usuarios se pueden utilizar técnicas interactivas, como diseño de diálogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construcción y perfeccionamiento del mismo DEFINICIÓN DEL SISTEMA Esta actividad tiene el objetivo de efectuar una descripción del sistema, delimitando su alcance, estableciendo las interfaces con otros sistemas e identificando a los usuarios Ing. Pablo Pytel 110 Análisis del Sistema de Información (Primer Ciclo)

111 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, como punto de partida, para definir el sistema software. Debido a que se considera el alcance del sistema software completo, esta actividad se realiza una única vez y es utilizado en los dos ciclos de desarrollo DETERMINACIÓN DEL ALCANCE DEL SISTEMA Esta tarea utiliza como base el modelo de procesos especificado en la Descripción de la Solución del proceso Estudio de Viabilidad del Sistema (EVS) para fijar los límites del alcance del sistema software debe brindar. Para ello se indican cuáles son los procesos que deben ser provistos por el sistema software y las entidades externas al sistema que aportan o reciben información a través de dichos procesos. Además se genera un modelo conceptual de datos identificando las entidades y relaciones que forman parte a partir del modelo abstracto de datos generado en la tarea Evaluación de Alternativas y Selección del proceso anterior. Para poder obtener toda esta información es necesario llevar a cabo sesiones de trabajo con los usuarios responsables relacionados del sistema software que se está analizando. En el caso de análisis orientado a objetos, antes de proceder con la captura y descripción de requisitos con la ayuda de 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, 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 software, en forma de casos de uso de alto nivel, y el subconjunto de objetos del dominio requerido para ello. En paralelo con la generación de los productos anteriores, es recomendable 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 software. El glosario es un catálogo de términos general y común a todos los procesos, que pueden ser entrada o salida en cualquier proceso del sistema, de modo que por sencillez en las restantes tareas se omite la referencia al mismo. En este trabajo se utiliza un glosario general para todas las actividades que se encuentra en la sección Modelo de Negocio El Modelo de Negocio identifica los principales procesos del negocio bajo análisis y describe la forma en que los mismos se llevan a cabo. Dentro de este modelo, los procesos Ing. Pablo Pytel 111 Análisis del Sistema de Información (Primer Ciclo)

112 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. a. Descripción del Negocio En este proyecto el negocio cubierto por el sistema software es básicamente la generación de datos de prueba de proyectos de explotación de explotación al que se le aplican las dos fórmulas del método DMCoMo. Esto se muestra gráficamente en la figura PASI 1. Figura PASI 1: Modelo de negocio b. Descripción de los Actores: Usuario: Este actor representa al único usuario que utiliza el sistema para generar los datos pruebas con las que analizar la aplicación del método de estimación DMCoMo. c. Descripción de los Casos de Uso: Generar Banco de Prueba: El proceso principal del negocio es la generación de datos de proyectos de explotación de información con las características relevantes para el método de estimación DMCoMo. Dichas características pueden ser asignadas por el usuario o en forma aleatoriamente (siguiendo una distribución de probabilidad normal) dependiendo de la configuración seleccionada por el usuario. Luego se aplican las fórmulas definidas por DMCoMo para calcular los valores correspondientes. Como resultado de este proceso se obtiene una lista de proyectos generados con sus datos y los valores de estimación, para ser luego analizados en detalle. Ing. Pablo Pytel 112 Análisis del Sistema de Información (Primer Ciclo)

113 d. Actividades: Las actividades llevadas a cabo para completar el proceso de generación de datos de pruebas descripto en el caso de uso se muestra gráficamente en el diagrama de la figura PASI 2. Figura PASI 2: Detalle de las actividades principales llevadas a cabo, junto con las principales entidades. A continuación se describen las actividades detalladas en el diagrama: Configurar Parámetros Este proceso consiste en definir los parámetros que serán utilizados para generar aleatoriamente las características de los proyectos de explotación de información, considerando para ello los factores de costo definidos por el método de estimación DMCoMo. Para ello el usuario selecciona el tipo de proyecto a generar dependiendo de su tamaño y, en caso que lo considere necesario, el usuario puede determinar el valor de una o más características con un valor específico en lugar de utilizar valores definidos al azar. Generar Proyectos Estimados Este proceso tiene como objetivo obtener los valores de los factores de costo para proyectos de explotación de información con sus correspondientes estimaciones al aplicar las dos fórmulas del método DMCoMo. Para ello cuenta con tres pasos: Ing. Pablo Pytel 113 Análisis del Sistema de Información (Primer Ciclo)

114 1) Generar aleatoriamente los valores de los factores de costo para el proyecto, que no fueron establecidos por el usuario, de acuerdo al tamaño de proyecto seleccionado. 2) Aplicar la fórmula de estimación con 23 factores de costo. 3) Aplicar la fórmula de estimación con 8 factores de costo. Nótese que estos pasos pueden ser ejecutados tanto una sola vez (para generar los datos de un único proyecto), o muchas veces (para generar los datos de más de un proyecto) IDENTIFICACIÓN DE LOS USUARIOS PARTICIPANTES Y FINALES Esta tarea se ocupa de identificar a los usuarios participantes y finales, incluyendo a los participantes en la obtención de requisitos, la validación de los distintos productos y la aceptación final del sistema. Para ello, se utiliza y completa 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. Además, se informa del plan de trabajo a los usuarios identificados. El alcance de este plan de trabajo se limita solamente al proceso de análisis Catálogo De Usuarios Para este proyecto, el sistema software se encontró concebido para un único usuario que posee conocimientos en el dominio de los proyectos de explotación de información, conoce el método de estimación DMCoMo y, además, posee conocimientos en el campo de la experimentación de software. Por otro lado, no se realiza ninguna validación de usuario, por lo que no se define ningún chequeo de acceso ni se incluye ningún manejo de privilegios de usuario ESTABLECIMIENTO DE REQUISITOS Esta actividad tiene el objetivo de realizar la definición, análisis y validación de los requisitos, a partir de la información provista por el usuario. Así se logra completar los requisitos obtenidos en la actividad Definición del Sistema y obtener un los requisitos detallados. A través de los cuales se puede comprobar que los productos generados en las actividades de modelización se ajustan a los requisitos solicitados por los usuarios. Ing. Pablo Pytel 114 Análisis del Sistema de Información (Primer Ciclo)

115 Esta actividad incluye un conjunto de tareas que, si bien poseen un orden preestablecido, necesitan de continuas realimentaciones y solapamientos entre sí y con otras tareas realizadas en paralelo. Esto significa que no es necesario finalizar una tarea para el comienzo de la siguiente. Así se logran establecer requisitos en función de la progresión del proceso de análisis. La especificación de los casos de uso de la orientación a objetos es propuesta como técnica de obtención de requisitos 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 El objetivo de esta actividad es especificar cada caso de uso identificado en la tarea anterior, desarrollando el escenario correspondiente. En el caso de orientación a objetos esta actividad es obligatoria, pero es opcional en el caso de análisis estructurado, como apoyo a la obtención de requisitos. Para poder completar cada caso de uso, es necesario definir la siguiente información: Actores que participan en el caso de uso. Pre-condiciones y post-condiciones del caso de uso. Descripción del escenario, es decir, cómo los actores interactúan con el sistema, y cuál es la respuesta obtenida (flujo principal). Identificación de interfaces de usuario. Condiciones de fallo que afectan al escenario, así como la respuesta del sistema (escenarios o flujos alternativos). Para escenarios complejos es posible utilizar, como técnica complementaria, la descomposició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 Considerando los requisitos que forman parte del alcance del primer ciclo de desarrollo (definido en la sección ) se definieron los diagramas de casos de uso del sistema software que se muestran en la figura PASI 3. Ing. Pablo Pytel 115 Análisis del Sistema de Información (Primer Ciclo)

116 Figura PASI 3: Diagrama de Casos de Uso En este diagrama se utiliza la siguiente simbología para las flechas: - Las flechas con punta blanca sin estereotipo indican que entre ambos casos de uso existe una relación de Inclusión. - Las fechas con punta negra sin estereotipo indican que existen una relación de uso entre los participantes. Para cada uno de los casos de uso representados en la figura PASI 3, a continuación se definen sus detalles en las tablas PASI 1, PASI 2 y PASI 3. Nombre del Caso de Uso Descripción del Caso de Uso Actores Pre-condiciones Post-condiciones Configurar Parámetros Se definen los parámetros para ser utilizado al momento de generar las características de los proyectos de explotación de información. Usuario - El sistema está ejecutándose. - Se determina el tamaño del proyecto a utilizar como parámetro. - Se determina si todos los valores son generados aleatoriamente o no (en cuyo se debe definir los valores específicos a utilizar). Flujo de Eventos Activación Requisitos especiales Puntos de extensión El usuario selecciona la opción Configuración de Proyectos. No posee No posee Ing. Pablo Pytel 116 Análisis del Sistema de Información (Primer Ciclo)

117 Flujo Principal 1) El usuario selecciona la opción Configuración de Proyectos. 2) El sistema solicita al usuario seleccionar el tamaño del proyecto a utilizar como parámetro de la siguiente lista: - Proyectos Pequeños. - Proyectos Medianos. - Proyectos Grandes. - Proyectos Aleatorios. 3) El usuario selecciona el tamaño del proyecto de la lista. 4) El sistema pregunta si se desea generar todos los valores de los factores de costo en forma aleatoria. 5) El usuario indica que desea generar todos los factores en forma aleatoria. 6) El sistema define el/los posible/s valore/s que puede tener cada uno de los factores de costo considerando el tamaño de proyecto seleccionado. 7) Fin del caso de uso. Flujos Alternativos Ing. Pablo Pytel 117 Análisis del Sistema de Información (Primer Ciclo)

118 Alternativa al paso 3 El usuario no selecciona un tamaño de proyecto. a) El sistema utiliza la opción Proyectos Aleatorios (ya que es el valor por defecto). b) El sistema continúa en el paso 4 del flujo principal. Alternativa al paso 5 El usuario indica que no desea generar todos los valores de los factores de costo en forma aleatoria. a) El sistema solicita al caso de uso Configurar Factores de Costo del Proyecto la configuración de cada uno de los factores de costo. b) El sistema continúa en el paso 7 del flujo principal. Tabla PASI 1: Descripción del caso de uso Configurar Parámetros Ing. Pablo Pytel 118 Análisis del Sistema de Información (Primer Ciclo)

119 Nombre del Caso de Uso Descripción del Caso de Uso Actores Pre-condiciones Post-condiciones Configurar Factores de Costo del Proyecto Se definen para cada uno de los factores de costo del proyecto un valor específico a utilizar o si se desea utilizar un valor generado al azar. Usuario - El sistema está ejecutándose. - Se está realizando la configuración de los proyectos a generar y ya se ha seleccionado el tamaño del proyecto a utilizar. - Para cada uno de los factores de costo se determina un valor específico o un rango de valores asociados al tamaño del proyecto que se generarán al azar. Flujo de Eventos Activación Requisitos especiales Puntos de extensión El usuario indica no generar aleatoriamente todos los factores de costo en la opción Configuración de Proyectos. No posee No posee Flujo Principal 1) El sistema muestra la lista con los 23 factores de costo del método DMCoMo para configurar, o la opción para finalizar la configuración de los factores de costo. 2) El usuario selecciona el factor de costo a configurar. 3) El sistema solicita el valor del factor de costo. 4) El usuario ingresa el valor del factor de costo. 5) El sistema vuelve al paso 2 para que el usuario pueda configurar otro factor de costo. Flujos Alternativos Ing. Pablo Pytel 119 Análisis del Sistema de Información (Primer Ciclo)

120 Alternativa al paso 2 El usuario selecciona finalizar la configuración de los factores de costo. a) El sistema determina, para cada uno de los factores de costo no configurados por el usuario, el/los posible/s valore/s que puede tener para el factor de costo de costo considerando el tamaño de proyecto ya seleccionado. b) El sistema le envía los valores y opciones de los factores de costo configurados al caso de uso llamante. c) Fin del caso de uso Alternativa al paso 4 El usuario selecciona que se genere los valores del factor de costo al azar. a) El sistema define el/los posible/s valore/s que puede tener para el factor de costo de costo considerando el tamaño de proyecto ya seleccionado. b) El sistema vuelve al paso 2 del flujo principal para que el usuario pueda configurar otro factor de costo. Ing. Pablo Pytel 120 Análisis del Sistema de Información (Primer Ciclo)

121 Alternativa al paso 4 El usuario no ingresa un valor permitido para el factor de costo. a) El sistema muestra un mensaje de error. b) El sistema vuelve al paso 4 del flujo principal para que el usuario ingrese un nuevo valor. Tabla PASI 2: Descripción del caso de uso Configurar Factores de Costo del Proyecto Nombre del Caso de Uso Descripción del Caso de Uso Actores Pre-condiciones Post-condiciones Generar Proyectos Estimados Se generan los proyectos de explotación de información con sus factores de costo y sus correspondientes estimaciones al aplicar las dos fórmulas del método DMCoMo. Usuario - El sistema está ejecutándose. - Los parámetros ya fueron configurados en el caso de uso Configurar Parámetros. - Se obtiene los factores de costo con sus correspondientes estimaciones al aplicar las dos fórmulas del método DMCoMo para uno o más proyectos de explotación de información. Flujo de Eventos Activación Requisitos especiales Puntos de extensión El usuario selecciona la opción Generar Proyectos Estimados. No posee No posee Ing. Pablo Pytel 121 Análisis del Sistema de Información (Primer Ciclo)

122 Flujo Principal 1) El usuario selecciona la opción Generar Proyectos Estimados. 2) El sistema solicita el modo de generación de los proyectos estimados a partir de las siguientes opciones: - Calcular costo para un proyecto. - Evaluación continua de proyectos. 3) El usuario selecciona el modo Calcular costo para un proyecto. 4) El sistema define los valores de los factores de costo para un proyecto a evaluar de acuerdo a la configuración realizada. 5) El sistema calcula los valores de la estimación para los valores de los factores de costo del proyecto a evaluar (determinados en el paso anterior). 6) El sistema muestra en pantalla los valores de estimación calculados en el paso anterior. 7) Fin del caso de uso. Flujos Alternativos Alternativa al paso 3 El usuario selecciona el modo Evaluación continua de proyectos. a) El sistema define los valores de los factores de costo para un proyecto a evaluar de acuerdo a la configuración realizada. b) El sistema calcula los valores de la estimación para los valores de los factores de costo del proyecto a evaluar (determinados en el paso anterior). c) El sistema calcula la media estadística para cada uno de los valores de estimación calculados en el paso b). Ing. Pablo Pytel 122 Análisis del Sistema de Información (Primer Ciclo)

123 d) El sistema muestra en pantalla los valores de estimación calculados en el paso b) y la media estadística calculada en el paso c). e) El sistema vuelve a ejecutar este flujo alternativo desde el paso a) hasta que el usuario seleccione finalizar la evaluación continua. Tabla PASI 3: Descripción del caso de uso Generar Proyectos Estimados 5.3. ANÁLISIS DE LOS CASOS DE USO Esta actividad, que sólo se realiza en el caso de Análisis Orientado a Objetos, tiene el objetivo de identificar las clases cuyos objetos son necesarios para realizar un caso de uso y describir su comportamiento mediante la interacción entre dichos objetos. A partir de cada uno de los casos de uso contenidos en un subsistema y definidos en la actividad Identificación de Subsistemas de Análisis se realizan las tareas de esta actividad. Dichas tareas no se realizan en forma secuencial sino en paralelo, con continuas realimentaciones entre ellas y con las realizadas en las siguientes actividades: Establecimiento de Requisitos, Identificación de Subsistemas de Análisis, Análisis de Clases y Definición de Interfaces de Usuario IDENTIFICACIÓN DE CLASES ASOCIADAS A UN CASO DE USO Esta tarea comienza a analizar la especificación de los casos de uso, identificados en el punto anterior, para definir los objetos necesarios para realizar cada uno. Así, a partir del estudio del caso de uso, se extrae una lista de objetos candidatos a ser clases. Es posible que al principio no se disponga de toda la información necesaria para identificar todas las clases, por lo que normalmente se realizar primero una 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. Ing. Pablo Pytel 123 Análisis del Sistema de Información (Primer Ciclo)

124 En dicha tarea se pueden identificar clases de los siguientes tipos: Clases de Entidad, las cuales representan la información manipulada en el caso de uso. Clases de Control, las cuales son responsables de la coordinación, secuencia de transacciones y control de los objetos relacionados con un caso de uso. Clases de Interfaz de Usuario, las cuales se utilizan para describir la interacción entre el sistema y sus actores y que suelen representar abstracciones de ventanas, interfaces de comunicación, formularios, etc Identificación de Clases En esta sección se muestran los diagramas de clase desarrollados para cada uno de los casos de uso del primer ciclo de desarrollo identificados en la sección Los diagramas de clases se muestran en las figuras de PASI 4, PASI 5 y PASI 6. Figura PASI 4: Diagrama de Clases para el caso de uso Configurar Parámetros Ing. Pablo Pytel 124 Análisis del Sistema de Información (Primer Ciclo)

125 Figura PASI 5: Diagrama de Clases para el caso de uso Configurar Factores de Costo del Proyecto Figura PASI 6: Diagrama de Clases para el caso de uso Generar Proyectos Estimados Para estos diagramas se utiliza la simbología definida en la figura PASI 7 para estereotipar las clases. Figura PASI 7: Estereotipos de Clases Ing. Pablo Pytel 125 Análisis del Sistema de Información (Primer Ciclo)

126 DESCRIPCIÓN DE LA INTERACCIÓN DE OBJETOS Esta tarea tiene como objetivo describir la cooperación entre los objetos, identificados en el punto anterior, que son utilizados para la realización de un caso de uso. Para representarlo se usan diagramas de interacción que contienen instancias de los actores participantes, objetos, y la secuencia de mensajes intercambiados entre ellos. 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. Se establecen 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.). Aunque normalmente estos diagramas sólo incluyen el escenario (flujo) principal, para aquellos casos en los que se especifique más de un escenario para un caso de uso (flujos alternativos), puede ser conveniente representar cada uno de ellos en un diagrama de interacción diferente. 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 En esta sección se muestran los diagramas de colaboración de objetos desarrollados para cada uno de los casos de uso del primer ciclo de desarrollo, y donde se vinculan las clases identificadas en la sección Esta vinculación se encuentra relacionada con la participación de los objetos dentro de los casos de uso. Los diagramas de clases se muestran en las figuras de PASI 8, PASI 9 y PASI 10. Nótese que se mantiene la simbología de los estereotipos de clases utilizadas en la sección anterior. Ing. Pablo Pytel 126 Análisis del Sistema de Información (Primer Ciclo)

127 Figura PASI 8: Diagrama de Interacción para el caso de uso Configurar Parámetros Figura PASI 9: Diagrama de Interacción para el caso de uso Configurar Factores de Costo del Proyecto Ing. Pablo Pytel 127 Análisis del Sistema de Información (Primer Ciclo)

128 Figura PASI 10: Diagrama de Interacción para el caso de uso Generar Proyectos Estimados 5.4. ANÁLISIS DE CLASES Esta actividad, que sólo se realiza en el caso de Análisis Orientado a Objetos, tiene el objetivo de describir cada una de las clases que han identificado incluyendo también las responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas. Teniendo en cuenta las clases identificadas en la actividad de 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 software IDENTIFICACIÓN DE RESPONSABILIDADES Y ATRIBUTOS Esta tarea se ocupa de identificar las responsabilidades y atributos relevantes de una clase: Las responsabilidades de una clase indican la funcionalidad de esa clase, se pueden definir a partir del análisis de los papeles que desempeñan sus objetos dentro de los casos de uso. Una vez identificadas estas responsabilidades, se pueden encontrar las operaciones, comunes a todos los objetos, que van a pertenecer a la clase. Estas operaciones deben ser relevantes, simples, y participar en la descripción de la responsabilidad. Ing. Pablo Pytel 128 Análisis del Sistema de Información (Primer Ciclo)

129 Los atributos de una clase indican las 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. Además, 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 Definición de Responsabilidades y Atributos En la siguiente tabla PASI 4 se detallan las clases identificadas en la sección junto con su tipo, responsabilidades y atributos. Clase Tipo Responsabilidades Atributos Interfaz de Pantalla Principal Interfaz de Configurar Parámetros Interfaz de Configurar Factores de Costos Interfaz de Generar Proyectos Estimados Interfaz Interfaz Interfaz Interfaz Establece la pantalla que se utiliza para comunicarse con el usuario para realizar las actividades principales Establece la pantalla que se utiliza para seleccionar los parámetros a ser utilizados cuando se generen los proyectos estimados. Establece la pantalla que se utiliza para definir si se desea utilizar un valor específico o un valor al azar a cada uno de los factores de costo. Establece la pantalla que se utiliza para generar los proyectos estimados. Menú principal con las opciones a utilizar. Control para seleccionar el Tamaño del Proyecto. Control para indicar si se desea generar todos los valores de los factores de costo en forma aleatoria o no. Control para definir el valor del factor de costo a utilizar (opcional) Control para indicar que se desea generar al azar. Control para seleccionar el modo de generación. Controles para mostrar últimos valores de estimación calculados por las dos fórmulas. Controles para mostrar la media estadística de los valores de estimación calculados. Asistente para Configurar Parámetros Control Coordina los pasos que se deben realizar para configurar los parámetros a ser utilizados cuando se generen los proyectos estimados. Tamaño del Proyecto Seleccionado. Si se desea generar todos los valores de los factores de costo en forma aleatoria o no. Ing. Pablo Pytel 129 Análisis del Sistema de Información (Primer Ciclo)

130 Clase Tipo Responsabilidades Atributos Asistente para Configurar Factores de Costo Asistente para Generar Proyectos Estimados Asistente para Generar Datos de Proyectos Asistente para Calcular Costos Estimados Parámetros de Tamaños de Proyectos Control Control Control Control Entidad Coordina los pasos que se deben realizar para para definir si se desea utilizar un valor específico o un valor al azar a cada uno de los factores de costo. Coordina los pasos que se deben realizar para generar los proyectos estimados. Coordina los pasos que se deben realizar para generar los proyectos al azar. Coordina los pasos que se deben realizar para caculos los valores de costo estimados utilizando los factores de costo generados. Representa la información de los parámetros permitidos para cada uno de los tamaños de proyectos. Valores de los factores de costo a utilizar o la indicación que se desea generar al azar. Modo de generación. Últimos valores de estimación calculados por las dos fórmulas del método DMCoMo. Media estadística de los valores de estimación calculados por las dos fórmulas del método Los 23 factores de costo generados para el proyecto a estimar. Los 23 factores de costo generados para el proyecto a estimar. Valores de estimación calculados por las dos fórmulas del método DMCoMo. Identificador del tamaño del proyecto. Valores permitidos para cada uno de los 23 factores de costo. Parámetros Entidad Representa la información de los parámetros generales configurados para ser utilizados para generar los proyectos. Tamaño del Proyecto seleccionado. Nombre del Factor. Configuración de Factores de Costo Entidad Representa la configuración de los factores de costo para ser utilizados para generar los proyectos. Valor a utilizar (opcional) La indicación que se desea generar al azar o no. Posibles valores que se pueden utilizar de acuerdo al tamaño de proyecto seleccionado. Ing. Pablo Pytel 130 Análisis del Sistema de Información (Primer Ciclo)

131 Clase Tipo Responsabilidades Atributos Proyectos Estimados Entidad Representa la información de los proyectos generados y estimados. Valores de los 23 factores de costo generados. Valores de los costos estimados por las dos fórmulas del método DMCoMo. Tabla PASI 4: Descripción de Clases IDENTIFICACIÓN DE ASOCIACIONES Y AGREGACIONES Una vez establecido el diagrama de interacción, en esta tarea se estudian los mensajes entre los objetos 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 se encuentra caracterizada por los siguientes elementos que pueden obtenerse a partir de la especificación de los casos de uso: Los diferentes papeles que desempeña. Su direccionalidad, o sea, el sentido en el que se debe interpretar. Su cardinalidad, o sea, el número de instancias implicadas en la asociación. 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 intentar optimizar los subsistemas Diagrama de Clases incluyendo Asociaciones y Agregaciones Por asociación de objetos se define a la identificación de necesidad de cooperación realizada entre los mismos para poder llevar a cabo una responsabilidad. En los diagramas de colaboración esto puede ser visto a través de las flechas que unen las clases en los diagramas. En este caso fue necesario estudiar cuidadosamente dichas conexiones dado que posteriormente indican referencias y agregaciones entre objetos. A continuación por cada tipo de clase se identifican sus asociaciones y agregaciones: Ing. Pablo Pytel 131 Análisis del Sistema de Información (Primer Ciclo)

132 Clases de Entidad El diagrama de clases con sus agregaciones y asociaciones para las clases de entidad se muestra en la figura PASI 11. Figura PASI 11: Diagrama de Clases para de Entidad Clases de Control Estas clases 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. Sin embargo, en el caso de la clase Asistente para Generar Proyectos Estimados existe un vínculo directo con las clases de control Asistente para Generar Datos de Proyectos y Asistente para Calcular Costos Estimados que son utilizados como clases auxiliares para poder crear los datos del banco de prueba. A continuación se muestran las relaciones de las clases de control en las figuras PASI 12, ASI 13 y PASI 14. Ing. Pablo Pytel 132 Análisis del Sistema de Información (Primer Ciclo)

133 Figura PASI 12: Diagrama de Clases de Asistente para Configurar Parámetros Figura PASI 13: Diagrama de Clases de Asistente para Configurar Factores de Costo Ing. Pablo Pytel 133 Análisis del Sistema de Información (Primer Ciclo)

134 Figura PASI 14: Diagrama de Clases de Asistente para Generar Proyectos Estimados Clases de Interfaz Dado que generalmente los lenguajes de programación orientados a objetos proveen librerías de clases, las cuáles contienen implementaciones de las características más importantes de las interfaces de usuarios. Cualquier desarrollo de interfaz está siempre muy ligado a las clases provistas por el lenguaje en cuestión. Por lo tanto, durante el análisis se decidió postergar las definiciones relacionadas con la interfaz de usuario para un momento posterior en cuanto se trate el diseño detallado IDENTIFICACIÓN DE GENERALIZACIONES Esta tarea se ocupa de 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. Para ello se basa siempre en las normas y estándares definidos en la actividad Definición del Sistema. Las generalizaciones identificadas son utilizadas durante el análisis para extraer el comportamiento común y compartido por las diferentes clases de análisis. En esta parte del proceso, estas generalizaciones son de alto nivel y conceptuales dado que su objetivo debe ser mantener un análisis simple y fácil de comprender. Ing. Pablo Pytel 134 Análisis del Sistema de Información (Primer Ciclo)

135 Descripción de las Generalizaciones Identificadas Luego de haber analizado las clases definidas para el sistema software no fue detectada ninguna generalización posible entre las clases, por lo que no se modificaron las clases previamente definidas DEFINICIÓN DE INTERFACES DE USUARIO Esta actividad tiene el objetivo de definir las interfaces entre el sistema y el usuario. O sea, de los formatos de pantallas, diálogos, e informes, principalmente. Esto se realiza a través del análisis de los procesos del sistema software 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. Cuando se comienza dicho análisis se debe seleccionar el entorno operativo de la interfaz, considerando para ello estándares internacionales y de instalación, y establecer las directrices aplicables en los procesos de diseño y construcción. El propósito de esto es construir una interfaz de usuario acorde a las necesidades y que además sea flexible, coherente, eficiente y fácil de utilizar. Si fuera necesario, también se debe tener en cuenta la adaptación a cambio a otras plataformas. Luego se identifican los distintos grupos de usuarios de acuerdo con las tareas que realizan, los conocimientos y habilidades que poseen, y las características del entorno en el que trabajan. A través de la identificación de los diferentes perfiles de usuario es posible conocer mejor las necesidades y particularidades de cada uno de ellos. Además es necesario determinar la naturaleza de los procesos que se llevan a cabo, tanto en lotes (batch) como en línea (on-line). Para cada proceso en línea se debe especificar qué tipo de información requiere el usuario para completar su ejecución, una descomposición que refleje la secuencia de la interfaz de pantalla tipo carácter o pantalla gráfica y, para cada una de las interfaces de pantalla, se define el formato y contenido especificando su comportamiento dinámico. Para esta actividad se propone un flujo de trabajo muy similar para desarrollos estructurados y orientados a objetos, coincidiendo en la mayoría de las tareas. De todas formas, en el desarrollo con 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 producto resultante de realizar esta actividad se obtiene la especificación de interfaz de usuario, la cual incluye los siguientes elementos: Ing. Pablo Pytel 135 Análisis del Sistema de Información (Primer Ciclo)

136 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. 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 Esta tarea tiene como objetivo el de 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 como para los informes y formularios impresos. En primer lugar, se debe seleccionar 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, incluyendo los siguientes puntos: 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. En cuanto a la interfaz impresa se deben establecer criterios similares, como son: 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 Para el sistema software fue utilizado una interfaz de usuario interactiva y gráfica mismo del estilo que otras aplicaciones basadas en Microsoft Windows. Además se establecieron los siguientes lineamientos principales que debían ser utilizados para la construcción de la interfaz de usuarios: Ing. Pablo Pytel 136 Análisis del Sistema de Información (Primer Ciclo)

137 Para invocar a las distintas funcionalidades del sistema software se usa un menú desplegable ubicado en la pantalla principal. Cuando sea necesario solicitar ingresar un valor del tipo SI / NO (por ejemplo, para preguntar si se desea generar todos los valores de los factores de costo al azar) se utilizan casillas de selección / verificación ( check-box ). Cuando sea necesario solicitar ingresar un valor excluyente a partir de una serie de valores fijos (por ejemplo, para seleccionar el tamaño del proyecto) se utilizan botones de radio ( radio-buttons ). Cuando sea necesario solicitar un valor que el usuario pueda decidir (por ejemplo, el valor que se desea especificar para un factor de costo) se utilizan casillas de texto, donde el sistema software validará el valor ingresado cuando el usuario confirme la acción. Los mensajes de error se muestran mediante pantallas emergentes ESPECIFICACIÓN DE FORMATOS INDIVIDUALES DE LA INTERFAZ DE PANTALLA Esta tarea tiene como objetivo definir en forma detallada las pantallas del sistema software que implementan las clases de interfaz de usuario previamente identificadas. Esta definición se realiza en forma detallada desde un punto de vista estático utilizando las especificaciones de los casos de uso y los formatos estándar definidos en la tarea Especificación de Principios Generales de la Interfaz. En el caso de utilizar análisis orientado a objetos, estos formatos individuales van completando las especificaciones de los casos de uso. Mientras que en un análisis estructurado, se tiene en cuenta 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. Al momento de definir cada pantalla de interfaz se deben considerar los siguientes aspectos 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. Controles y elementos de diseño asociados, indicando cuáles aparecen inicialmente activos e inactivos al visualizar la pantalla. Ing. Pablo Pytel 137 Análisis del Sistema de Información (Primer Ciclo)

138 MODELO DE NAVEGACIÓN DE INTERFAZ En esta sección se define el modelo que indica cómo las diferentes interfaces de usuario previamente definidas pueden navegarse entre sí. En la figura PASI 15 se muestra el diagrama de navegación de las pantallas. Figura PASI 15: Diagrama de Navegación de Pantallas Descripción de las Características Generales de cada Pantallas A continuación se describen las principales características de cada una de las pantallas identificadas: a. Pantalla Principal (Menú Principal) Esta es la pantalla que el usuario utiliza para acceder a las principales funcionalidades del sistema software a través de un menú contextual. b. Configurar Parámetros Esta pantalla permite al usuario seleccionar los parámetros generales a ser utilizados cuando se generen los proyectos estimados. c. Configurar Factores de Costo Esta pantalla permite al usuario configurar los factores de costo al definir si se desea utilizar un valor específico o un valor al azar a cada uno. d. Generar Proyectos Estimados Esta pantalla permite al usuario realizar la generación de los datos de los proyectos y su estimación. Ing. Pablo Pytel 138 Análisis del Sistema de Información (Primer Ciclo)

139 Definición de las Pantallas del Sistema A continuación se detallan los prototipos de las pantallas del sistema software: a. Pantalla Principal (Menú Principal) Esta es la pantalla principal del sistema software que se observa al ingresar. La pantalla contiene una barra de menú con las principales funcionalidades del sistema: - Configurar Parámetros. - Configurar Factores. - Generar Proyectos Estimados. El prototipo de esta pantalla se muestra en la figura PASI 16. Figura PASI 16: Pantalla Principal (Menú Principal) b. Configurar Parámetros Esta pantalla se accede al seleccionar la opción Configurar Parámetros del menú contextual y contiene los siguientes elementos: - Una lista de botones de radio ( radio-buttons ) excluyentes entre sí para seleccionar el tamaño del proyecto a procesar. Ing. Pablo Pytel 139 Análisis del Sistema de Información (Primer Ciclo)

140 - Una casilla de selección ( check-box ) para indicar que se desea generar todos los factores de costo aleatoriamente. El prototipo de esta pantalla se muestra en la figura PASI 17. Figura PASI 17: Pantalla de Configurar Parámetros c. Configurar Factores de Costo Al seleccionar la opción Configurar Factores del menú contextual, el sistema software despliega las seis categorías de factores de costos definidas por el método DMCoMo. Al seleccionar una de estas categorías se despliega una pantalla con una pestaña por cada uno de los factores de costo asociados a la categoría seleccionada. Cada pestaña cuenta con los siguientes elementos: - Una casilla de texto para ingresar un valor específico que se quiere utilizar para el factor. - Una casilla de selección ( check-box ) para indicar si se desea generar los valores del factor de costo al azar. El prototipo de esta pantalla se muestra en la figura PASI 18. Ing. Pablo Pytel 140 Análisis del Sistema de Información (Primer Ciclo)

141 Figura PASI 18: Pantalla de Configurar Factores de Costo d. Generar Proyectos Estimados Esta pantalla se accede al seleccionar la opción Generar Proyectos Estimados del menú contextual y contiene los siguientes elementos: - Una lista de botones de radio ( radio-buttons ) excluyentes entre sí para seleccionar el modo de generación de los proyectos estimados. - Un botón para comenzar la generación de los proyectos estimados. - Un botón, que sólo estará habilitado cuando se seleccione el modo Activar Evaluación Continua, para finalizar la generación de los proyectos estimados. - Cuatro etiquetas para mostrar los resultados que se están calculando en tiempo real, los cuales son: los costos estimados calculados por las dos fórmulas de DMCoMo y la media estadística de los costos estimados calculados por las dos fórmulas de DMCoMo. El prototipo de esta pantalla se muestra en la figura ASI 19. Ing. Pablo Pytel 141 Análisis del Sistema de Información (Primer Ciclo)

142 Figura PASI 19: Pantalla de Generar Proyectos Estimados ESPECIFICACIÓN DE FORMATOS DE IMPRESIÓN Esta tarea define los formatos y características de las salidas o entradas impresas del sistema software. 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 copias impresas Formatos de Impresión En este sistema software no se realizan impresiones, por lo que este aspecto quedó pendiente para futuros cambios y desarrollos ANÁLISIS DE CONSISTENCIA Y ESPECIFICACIÓN DE REQUISITOS Esta actividad tiene el objetivo de garantizar la calidad de los distintos modelos generados en el proceso de Análisis del Sistema de Información, además de asegurarse que los usuarios y los Analistas tienen el mismo concepto del sistema. Para cumplir dichos objetivos se llevan a cabo las siguientes acciones: Ing. Pablo Pytel 142 Análisis del Sistema de Información (Primer Ciclo)

143 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. Para poder realizar esta actividad se requiere una herramienta de ayuda para el análisis de consistencia VERIFICACIÓN DE LOS MODELOS El objetivo de esta tarea es, conforme a la técnica seguida para la elaboración de cada producto y a las normas determinadas, asegurar la calidad formal de los distintos modelos generados. 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, se verifica la calidad de los distintos modelos de forma separada. Como resultado de la verificación, se efectuaron correcciones que fueron posteriormente comprobadas nuevamente en forma satisfactoria ANÁLISIS DE CONSISTENCIA ENTRE MÉTODOS Esta tarea se ocupa de asegurar la consistencia entre los modelos controlando que estos sean coherentes entre sí, y comprobando la falta de ambigüedades o duplicación de información. Las comprobaciones forman parte del producto Resultado de Análisis de Consistencia y pueden variar en función del tipo de desarrollo, aunque en general, son matrices entre los elementos comunes de los distintos modelos. a. Desarrollo Estructurado: Para Desarrollo Estructurado, los análisis de consistencia propuestos son: Modelo Lógico de Datos Normalizado / Modelo de Procesos: Se verifica que: - 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 poder realizar está comprobación se utiliza como técnicas Ing. Pablo Pytel 143 Análisis del Sistema de Información (Primer Ciclo)

144 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 poder realizar está comprobación se utiliza 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: 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. Como resultado del análisis de consistencia en un Desarrollo Estructurado, se obtiene un producto que incluye 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. b. Desarrollo Orientado a Objetos: Para el Desarrollo Orientado a Objetos, si se considera 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. De esta manera, los análisis de consistencia propuestos son: Ing. Pablo Pytel 144 Análisis del Sistema de Información (Primer Ciclo)

145 Catálogo de Requisitos / Modelo de Casos de Uso Se comprueba que: - Cada requisito está considerado en los casos de uso definidos en el análisis. - Todos los requisitos incluidos en el ciclo de desarrollo actual han sido considerado en los casos de uso del sistema. Modelo de Navegación de Interfaz / Prototipo Interfaz de usuario Se comprueba que: - Cada prototipo de interfaz de usuario debe estar incluido en el modelo de navegación de interfaz. Modelo de Casos de Uso / Prototipo de Interfaz de Usuario Se comprueba que: - Cada elemento de prototipo de pantallas, debe estar asociado con un mensaje del diagrama de interacción de objetos de los casos de uso. - Los subsistemas satisfagan la realización de todos los casos de uso, e incluyan las clases identificadas hasta el momento. Modelo de Casos de Uso / Modelo de Clases: Se comprueba que: - Cada caso de uso tiene todos sus objetos identificados en el modelo de clases. - Cada objeto del diagrama de interacción de objetos tiene una correspondencia en el modelo de casos de uso. En el caso de haber elaborado Diagramas de Transición de Estados para clases significativas: Se verifica que: - Para cada uno de los diagramas de transición de estados, todo evento se corresponde con una operación de la clase. - Las acciones y actividades de los diagramas de transición de estado se corresponden con operaciones de la clase. Como resultado del análisis de consistencia en un Desarrollo Orientado a Objetos, se obtiene un producto que incluye los siguientes elementos: Ing. Pablo Pytel 145 Análisis del Sistema de Información (Primer Ciclo)

146 Matriz de catálogo de requisitos / modelo de casos de uso. Correspondencia elementos de navegación de interfaz de usuario / prototipo de interfaz. Matriz de modelo de casos de uso / prototipo de interfaz de usuario. Matriz de modelo de casos de uso / clases del modelo de clases. Matriz de transición de estados / modelo de clases (si corresponde). c. Ambos: Tanto para el Desarrollo Estructurado como al Desarrollo Orientado a Objetos se considera los siguientes análisis de consistencia propuestos son: Catálogo de Requisitos / Modelo de Negocio Se comprueba que: - Cada requisito está considerado en el modelo de negocio definido en el análisis. - Todos los requisitos incluidos en el ciclo de desarrollo actual han sido considerado en las actividades del modelo de negocio. Como resultado del análisis de consistencia se agregan los productos que incluyen los siguientes elementos: Matriz de catálogo de requisitos / modelo de negocio Análisis de Consistencia Dado que este trabajo se realizó con desarrollo orientado a objetos, en esta sección se procede a comprobar la coherencia entre los distintos modelos del desarrollo orientado a objetos utilizado de acuerdo a las trazabilidades que se presentan en la figura PASI 20. Ing. Pablo Pytel 146 Análisis del Sistema de Información (Primer Ciclo)

147 Figura PASI 20: Trazabilidades entre los distintos modelos Para llevar a la comprobación se utiliza un conjunto de matrices de trazabilidad que se muestran a continuación: a. Catálogo de Requisitos vs Modelo de Negocio: En la tabla PASI 5 se muestra la matriz que incluye en sus filas los requisitos funcionales del catálogo de requisitos para el primer ciclo de desarrollo y en sus columnas las actividades del modelo de negocio. Como puede verse, se comprobó que cada una de las actividades tiene su correspondencia con algún requisito. Ing. Pablo Pytel 147 Análisis del Sistema de Información (Primer Ciclo)

148 Catálogo de Requisitos / Modelo de Negocio Configurar Parámetros Generar Proyectos Estimados RF 1: Configurar Parámetros RF 1.1 X RF X RF X RF X RF 2: Generar Datos de Proyecto RF 2.1 X RF 2.2 X RF 2.3 X RF 3: Calcular Estimación de Esfuerzo RF 3.1 X RF 3.2 X RF 3.3 X RF 3.4 X RNF 1: Modos de Procesamiento de Proyectos RNF 1.1 X RNF 1.2 X Ing. Pablo Pytel 148 Análisis del Sistema de Información (Primer Ciclo)

149 Catálogo de Requisitos / Modelo de Negocio Configurar Parámetros Generar Proyectos Estimados RNF 2: Interfaz Gráfica RNF 2.1 X X RNF 2.2 X RNF 2.3 X RNF 3: Soporte de Sistemas Operativos RNF 3.1 X X RNF 3.2 X X RNF 3.3 X X Tabla PASI 5: Trazabilidades entre el Catálogo de Requisitos y Modelo de Negocio b. Modelo de Casos de Uso vs Catálogo de Requisitos: En la tabla PASI 6 se muestra la matriz que incluye en sus filas los requisitos del catálogo de requisitos para el primer ciclo de desarrollo y en sus columnas los casos de uso del Modelo de Casos de Uso. Como puede verse, se comprobó que cada requisito tiene correspondencia con algún caso de uso y viceversa. Catálogo de Requisitos / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados RF 1: Configurar Parámetros RF 1.1 X X RF X Ing. Pablo Pytel 149 Análisis del Sistema de Información (Primer Ciclo)

150 Catálogo de Requisitos / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados RF X RF X RF 2: Generar Datos de Proyecto RF 2.1 X RF 2.2 X RF 2.3 X RF 3: Calcular Estimación de Esfuerzo RF 3.1 X RF 3.2 X RF 3.3 X RF 3.4 X RNF 1: Modos de Procesamiento de Proyectos RNF 1.1 X RNF 1.2 X RNF 2: Interfaz Gráfica RNF 2.1 X X X RNF 2.2 X X RNF 2.3 X Ing. Pablo Pytel 150 Análisis del Sistema de Información (Primer Ciclo)

151 Catálogo de Requisitos / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados RNF 3: Soporte de Sistemas Operativos RNF 3.1 X X X RNF 3.2 X X X RNF 3.3 X X X Tabla PASI 6: Trazabilidades entre el Modelo de Casos de Uso y el Catálogo de Requisitos c. Modelo de Casos de Uso vs Prototipo de Interfaz: En la tabla PASI 7 se muestra la matriz que incluye en sus filas las pantallas del modelo del Prototipo de Interfaz y en sus columnas los casos de uso del Modelo de Casos de Uso. Así se comprobó que cada pantalla tiene correspondencia con algún caso de uso y viceversa. Prototipo de Interfaz / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Pantalla Principal (Menú Principal) X X X Configurar Parámetros X Configurar Factores de Costo X Generar Proyectos Estimados X Tabla PASI 7: Trazabilidades entre el Modelo de Casos de Uso y el Prototipo de Interfaz Ing. Pablo Pytel 151 Análisis del Sistema de Información (Primer Ciclo)

152 d. Modelo de Modelo de Navegación de Interfaz vs Prototipo de Interfaz: En la tabla PASI 8 se muestra la matriz que incluye en sus filas las pantallas del modelo del Prototipo de Interfaz y en las columnas las pantallas del Modelo de Navegación. De esta forma se comprobó que cada pantalla de interfaz de usuario tiene correspondencia con alguna de las pantallas del modelo de navegación. Modelo de Navegación de Interfaz / Prototipo de Interfaz Pantalla Principal (Menú Principal) Configurar Parámetros Configurar Factores de Costo Generar Proyectos Estimados Pantalla Principal (Menú Principal) X Configurar Parámetros X Configurar Factores de Costo X Generar Proyectos Estimados X Tabla PASI 8: Trazabilidades entre el Modelo de Navegación de Interfaz y el Prototipo de Interfaz e. Modelo de Casos de Uso vs Clases: En la tabla PASI 9 se muestra la matriz que incluye en sus filas las Clases y en las columnas los casos de uso del Modelo de Casos de Uso. Se comprobó que cada clase tiene correspondencia con algún caso de uso y viceversa. Clases / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Interfaz de Pantalla Principal X X X Ing. Pablo Pytel 152 Análisis del Sistema de Información (Primer Ciclo)

153 Clases / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Interfaz de Configurar Parámetros X Interfaz de Configurar Factores de Costos X Interfaz de Generar Proyectos Estimados X Asistente para Configurar Parámetros X Asistente para Configurar Factores de Costo X Asistente para Generar Proyectos Estimados X Asistente para Generar Datos de Proyectos X Asistente para Calcular Costos Estimados X Parámetros de Tamaños de Proyectos X X Parámetros X X X Configuración de Factores de Costo X X X Proyectos Estimados X Tabla PASI 9: Trazabilidades entre el Modelo de Casos de Uso y el Diagrama de Clases Ing. Pablo Pytel 153 Análisis del Sistema de Información (Primer Ciclo)

154 5.7. ESPECIFICACIÓN DEL PLAN DE PRUEBAS Esta actividad tiene el objetivo de comenzar a definir el plan de pruebas, el cual sirve como guía para la realización de las pruebas y permite verificar que el sistema software cumple con las necesidades establecidas por el usuario y aplicando las debidas garantías de calidad. Así se define el marco general estableciendo los requisitos de prueba de aceptación, los cuales son relacionados directamente con la especificación de requisitos. 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. 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 (IASI). El plan posee los siguientes niveles de prueba: Pruebas unitarias. Pruebas de integración. Pruebas del sistema. Pruebas de implantación. Pruebas de aceptación. Además esta actividad busca continuar 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 En esta tarea se elabora la planificación de las pruebas para 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. Este plan describe 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 software desarrollado. Para realizar la especificación de 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, 1983], el cual ha sido adaptado a las características del presente proyecto. 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. Ing. Pablo Pytel 154 Análisis del Sistema de Información (Primer Ciclo)

155 Alcance El alcance del plan de pruebas para este proyecto fue limitado a las actividades generales de prueba a realizarse para el Sistema de Generación de Bancos de Pruebas de Proyectos de Explotación de Información Ítems y características a probar El plan de pruebas para este proyecto tuvo como objetivo probar el Sistema de Generación de Bancos de Pruebas de Proyectos de Explotación de Información, para lo cual se consideró la realización de pruebas unitarias para verificar cómo se realiza cada función del sistema, y una prueba global del sistema software para verificar el funcionamiento general del mismo Características que no van a ser probadas Fue excluido del plan de pruebas para este proyecto los siguientes elementos: Aplicaciones y herramientas no desarrolladas (por ejemplo, Sistema Operativo y Herramientas de Manejo de Planilla de Cálculos). 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 Integración Pruebas de Sistema. Pruebas de Implantación Pruebas de Aceptación Cada una de estas actividades es analizada en las secciones a continuación Pruebas Unitarias Las Pruebas Unitarias deben cubrir las principales clases definidas y desarrolladas durante la etapa de codificación. Todas las entradas y salidas de cada clase deben ser probadas y, en caso de existir la posibilidad de combinar varias al mismo tiempo, esto también debe ser probado. La ejecución de las pruebas unitarias es manual y sus resultados deberán ser registrados en el documento de registro estándar. Ing. Pablo Pytel 155 Análisis del Sistema de Información (Primer Ciclo)

156 Esta actividad fue desarrollada de forma paralela a la codificación de la aplicación. Y sólo cuando las actividades de pruebas unitarias fueron superadas exitosamente, se pudo avanzar a la siguiente actividad de prueba denominadas Pruebas de Integración Pruebas de Integración Las Pruebas de Integración deben cubrir la interacción entre las clases definidas y desarrolladas durante la etapa de codificación. Se busca encontrar fallas en el funcionamiento de los componentes y subsistemas del sistema, al funcionar en conjunto para proveer la funcionalidad deseada. Sin embargo, debido a la estructura y la funcionalidad brindada por el sistema software, estas pruebas fueron realizadas directamente junto con las Pruebas del Sistema Pruebas de Sistema Las Pruebas de Sistema utilizan la técnica de caja negra, la cual examina algunos aspectos externos del modelo del sistema sin tener en cuenta la estructura lógica interna del software. Para ello se utiliza los métodos de partición de equivalencias y análisis de valores límites. La ejecución de las pruebas de sistema fue manual y sus resultados fueron registrados en el documento de registro estándar. Una vez que todos los casos de prueba de sistema fueron superados exitosamente, se consideró que el sistema software estaba listo para ser instalado Pruebas de Implantación Las Pruebas de Implantación corresponden a las verificaciones necesarias para asegurar que el sistema software funciona correctamente en el entorno de operación real instalado para proceder con la entrega al usuario final. La ejecución de las pruebas de sistema fue manual y sus resultados fueron registrados en el documento de registro estándar. Una vez que todos los casos de prueba de implantación fueron superados exitosamente, se consideró que el sistema software estaba listo para ser entregado Pruebas de Aceptación Al momento de ser entregado, se realizaron estas pruebas, las cuales fueron realizadas por los usuarios del sistema (en este caso, el tesista y/o uno de los Directores del Proyec- Ing. Pablo Pytel 156 Análisis del Sistema de Información (Primer Ciclo)

157 to de Tesis). Éste tomó como criterio de evaluación el cumplimiento, por parte del sistema, de los requisitos funcionales del mismo Amplitud de las Pruebas La amplitud y criterio de completitud empleadas en las pruebas se basa en la cobertura realizada sobre la funcionalidad requerida REPORTE DE FALLAS DE LAS PRUEBAS Todas las fallas que sean detectadas durante el análisis y evaluación de los resultados de la ejecución de las pruebas se registran en el reporte correspondiente. En la figura PASI 21, se define el formato del reporte de pruebas a utilizar. Figura PASI 21: Documento de reporte de pruebas TRAZABILIDAD DE REQUERIMIENTOS En la sección de Análisis de Consistencia entre Métodos se incluyen las matrices de trazabilidad que muestran la consistencia entre los distintos modelos generados en la fase de análisis (realizados en la sección de este trabajo). Ing. Pablo Pytel 157 Análisis del Sistema de Información (Primer Ciclo)

158 Disponibilidad de Ítems de Prueba Las actividades de prueba no pudieron comenzarse hasta que todas las unidades de prueba se encontraban 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: - Pentium III o superiores (2.0 GHZ) - 1 GB de memoria RAM (o más) - Disco rígido de 20 GB (o superior) Sistema operativo Microsoft Windows XP, 2000, 7 o superior CRITERIO PARA EVALUAR INSTANCIAS DE PRUEBA En las siguientes subsecciones se detallan los criterios aplicados en la evaluación de las distintas instancias de prueba. Para lo cual se utilizó el criterio Paso/Falla Evaluación de Instancias de Prueba Aplicado a cada Ítems A continuación se define el criterio a emplear sobre cada uno de los ítems: Paso: Todas las pruebas realizadas sobre el ítem fueron exitosas. Fallo: Al menos una de las pruebas realizadas no fue exitosa Evaluación de Instancias de Prueba sobre la Aplicación A continuación se define el criterio a emplear sobre las pruebas de la aplicación: Exitosa: Todas las pruebas fueron realizados y no se encontraron defectos de severidad 1, 2 o 3 (ver tipos de severidad definidos en la tabla PASI 10). Fallada: Al menos un defecto de severidad 1, 2 o 3 fue encontrado (ver tipos de severidad definidos en la tabla PASI 10). Nivel de Severidad Descripción 1 Sistema detenido 2 Fallas de funcionalidad 3 Una solución alternativa puede aplicarse 4 Error de documentación / guía / ayuda Ing. Pablo Pytel 158 Análisis del Sistema de Información (Primer Ciclo)

159 Nivel de Severidad Descripción 5 Cambios y mejoras Tabla PASI 10: Severidad de Defectos CRITERIO DE SUSPENSIÓN Y REINICIACIÓN DE PRUEBAS Ante cualquiera de las siguientes situaciones, las actividades de prueba debían ser suspendidas: Se encuentra un problema en una prueba que impide realizar la prueba. Se encuentra un problema en un ítem que impide la realización de más pruebas. Una vez solucionados los problemas encontrados, las pruebas podían reiniciarse, comenzando nuevamente por el primer caso de prueba para verificar que la solución del problema no haya generado nuevos inconvenientes. Sin embargo, debe notarse que cuando se encontraba un problema y el mismo no impedía la realización de más pruebas, las mismas podían continuar ARTEFACTOS DE LAS PRUEBAS Los elementos generados como resultado de la realización de las pruebas son los siguientes: 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 ACTIVIDADES DE PRUEBA Las actividades realizadas para concretar cada uno de los ciclos de prueba son los siguientes: 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. Ing. Pablo Pytel 159 Análisis del Sistema de Información (Primer Ciclo)

160 PROCEDIMIENTO DE PRUEBAS Para definir el procedimiento de prueba se utiliza un esquema de procedimiento, el cual se muestra en la figura PASI 22. Figura PASI 22: Procedimiento de Pruebas NECESIDADES DE AMBIENTE En este sistema software existió un único ambiente de trabajo y las propiedades mínimas requeridas para el mismo se especifican a continuación. Ing. Pablo Pytel 160 Análisis del Sistema de Información (Primer Ciclo)

161 Hardware El hardware requerido para el ambiente de trabajo fue una máquina de tipo PC con las siguientes características mínimas: - Pentium III o superiores (1.0 GHZ) - 1 GB de memoria RAM (o más) - Disco rígido de 20 GB (o superior) Software El software mínimo requerido para el ambiente de trabajo fue el siguiente: - El sistema operativo requerido para la ejecución del sistema será: Microsoft Windows XP, 2000, 7 o superior. - Debido a que se utiliza Java como lenguaje de desarrollo es necesario la instalación de Java Runtime Environment (JRE) 1.5 o posterior para su ejecución. - Para realizar las pruebas de los archivos generados por el sistema software (funcionalidad incluida en el segundo ciclo de desarrollo) es necesario la instalación del producto Microsoft Office 2007 o superior Seguridad En este trabajo no se tuvo requerimientos para la seguridad del sistema Modo de uso Para la descripción del modo de uso referirse a Definición del Sistema y Establecimiento de Requisitos Certificación de entorno En este trabajo no existían necesidades de certificación de entorno RESPONSABILIDADES A continuación se detallan las responsabilidades de los integrantes del proyecto: a. Ingeniero de pruebas (esta función se encuentra a cargo del tesista) Diseñar, preparar y realizar las actividades de prueba. Gestionar el entorno local de prueba. Recolectar y analizar los resultados obtenidos de la realización de las actividades de prueba. Ing. Pablo Pytel 161 Análisis del Sistema de Información (Primer Ciclo)

162 b. Líder de desarrollo (esta función se encuentra a cargo del tesista) Proveer de los ítems a probar. Revisar el plan de pruebas. Revisar las actividades de prueba. Revisar los resultados de las pruebas realizadas. c. Líder de proyecto (esta función se encuentra a cargo del tesista) Revisar el plan de pruebas. Revisar los resultados de las pruebas realizadas. Coordinar las actividades de prueba. d. Especialista en calidad (esta función se encuentra a cargo de uno de los Directores de Tesis) Revisar el plan de pruebas. Revisar las actividades de prueba. e. Cliente (esta función se encuentra a cargo de uno de los Directores de Tesis) Realizar las pruebas de aceptación RIESGOS Y CONTINGENCIAS DE PRUEBAS Los posibles riesgos a enfrentar en la implementación del sistema con sus respectivas contingencias se detallan en la tabla PASI 11. Riesgos Diferencias entre el entorno de desarrollo y de pruebas con 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 PASI 11: Análisis de Riesgos y Contingencias Ing. Pablo Pytel 162 Análisis del Sistema de Información (Primer Ciclo)

163 5.8. APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN En esta tarea, el Comité de Dirección decide la aprobación formal o no del Análisis del Sistema de Información luego de que este es presentado PRESENTACIÓN Y APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN CORRESPONDIENTE AL PRIMER CICLO DE DESARROLLO Luego de realizar una reunión mantenida entre el tesista y los Directores del Proyecto de Tesis, se dio como válido el Análisis para el primer ciclo de desarrollo y se consideró aprobada la misma para continuar con las actividades de diseño. Ing. Pablo Pytel 163 Análisis del Sistema de Información (Primer Ciclo)

164

165 CAPÍTULO 6 PRIMER CICLO DE DESARROLLO: DISEÑO DEL SISTEMA DE INFORMACIÓN

166

167 6. PRIMER CICLO DE DESARROLLO: DISEÑO DEL SISTEMA DEL SISTEMA DE INFORMACIÓN 6.1. INTRODUCCIÓN El objetivo del proceso de Diseño del Sistema de Información (DSI) es definir 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 software. Dado que Métrica Versión III es 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. A partir de la arquitectura del sistema y su entorno tecnológico se pueden generar 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 corresponda. Para llevar a cabo este proceso, las actividades se agrupan en dos grandes bloques: En el primer bloque se encuentran todas las actividades que se llevan a cabo en paralelo para obtener el diseño de detalle del sistema software. En general, el orden real de ejecución de las mismas depende de las particularidades del sistema software y, por lo tanto, de generación de sus productos. Además, se exige una continua realimentación entre las mismas. El segundo bloque de actividades complementa el diseño del sistema de información. Dentro del primer bloque se encuentran las siguientes actividades que, como se ha mencionado anteriormente, se llevan a cabo en paralelo: Definición de la Arquitectura del Sistema. Esta actividad establece el particionamiento físico del sistema software, 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. El particionamiento físico del sistema permite organizar un diseño, independientemente de la infraestructura tecnológica, que contemple un sistema software distribuido (por ejemplo una arquitectura cliente/servidor) y representa los distintos niveles funcionales o físicos del sistema software. A través de la relación entre los elementos del diseño y Ing. Pablo Pytel 167 Diseño del Sistema de Información (Primer Ciclo)

168 particionamiento físico, y entre el particionamiento físico y el entorno tecnológico, es posible obtener una especificación de la distribución de los elementos del sistema software y, al mismo tiempo, un diseño orientado a la movilidad a otras plataformas o la reubicación de subsistemas. Al descomponer el sistema en subsistemas de diseño, éstos presentan diferentes características de acuerdo a su propósito, por lo que pueden ser clasificados en: - Subsistemas de Soporte, lo cuales 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. - Subsistemas Específicos, los cuales contienen los elementos propios del sistema software, generalmente con una continuidad de los subsistemas definidos en el proceso de Análisis del Sistema de Información (ASI). Por otro lado, durante esta actividad también es necesario especificar en detalle el entorno tecnológico del sistema software, junto con su planificación de capacidades (capacity planning), y sus requisitos de operación, administración, seguridad y control de acceso. Por último, también se completan los requisitos y las normas con los aspectos relativos al diseño y construcción que sea necesario contemplar en función de la definición del entorno tecnológico. Asimismo se define 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 es utilizado como referencia en la especificación técnica de las pruebas del sistema. Diseño de la Arquitectura de Soporte Esta actividad 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 Esta actividad, que se realiza sólo en el desarrollo estructurado, produce el diseño de detalle de los subsistemas específicos del sistema software y la revisión de la interfaz de usuario. Ing. Pablo Pytel 168 Diseño del Sistema de Información (Primer Ciclo)

169 Diseño de Casos de Uso Reales Esta actividad se ocupa del el diseño detallado del comportamiento del sistema software 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 Esta actividad incluye 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, por existir un sistema que es reemplazado, también define de un plan de migración y carga inicial de datos. Diseño Físico de Datos Una vez que se tiene el modelo de clases, se comienza esta actividad, que se encuentra tanto para el Diseño Estructurado como en el Diseño Orientado a Objetos. Esta actividad 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. Nótese que esta actividad sólo considera el diseño de la persistencia de los objetos sobre las bases de datos relacionales. Verificación y Aceptación de la Arquitectura del Sistema Una vez finalizado el diseño de detalle, se realiza su revisión y validación con el fin de analizar la consistencia entre los distintos modelos y conseguir la aceptación del diseño por parte de los responsables. Por otro lado, el segundo bloque de actividades complementa el Diseño del Sistema de Información, incluyendo En las actividades que se ocupan de generar especificaciones necesarias para la Construcción del Sistema de Información: Generación de Especificaciones de Construcción Esta actividad fijan las directrices para la construcción de los componentes del sistema, así como de las estructuras de datos. Ing. Pablo Pytel 169 Diseño del Sistema de Información (Primer Ciclo)

170 Diseño de la Migración y Carga Inicial de Datos, Esta actividad permite definir, en caso necesario, los procedimientos de migración y sus componentes asociados, considerando las normas de construcción oportunas. Especificación Técnica del Plan de Pruebas Esta actividad incluye la definición y revisión del plan de pruebas, y el diseño de las verificaciones de los niveles de prueba establecidos. A través del catálogo de excepciones es posible, en 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 Esta actividad hace posible concretar las exigencias relacionados con la propia implantación del sistema, tales como formación de usuarios finales, infraestructura, etc.. Presentación y Aprobación del Diseño del Sistema de Información Finalmente, en esta actividad se realiza una presentación formal y aprobación de los distintos productos del diseño DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA Esta actividad tiene como objetivo definir la arquitectura general del sistema software a desarrollar, mediante la especificación de las distintas particiones físicas del mismo, su descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición, además de definir en forma detallada la infraestructura tecnológica necesaria para dar soporte al sistema. Para especificar el particionamiento físico del sistema es necesario identificar los nodos y la comunicación necesaria entre los mismos, pero con independencia de la infraestructura tecnológica que da soporte a cada nodo. Con el fin de organizar y facilitar el diseño, se divide el sistema en subsistemas de diseño, como partes lógicas coherentes y con interfaces claras y definidas. Para poder realizar esto primero es necesario hacer una distinción entre subsistemas específicos del sistema software (de ahora en más, denominados subsistemas específicos) y los subsistemas de soporte. Así se intenta independizar, dentro de la medida de lo posible, las funcionalidades a cubrir por el sistema de la infraestructura que le da soporte. Normalmente los subsistemas específicos provienen directamente de las especificaciones de Ing. Pablo Pytel 170 Diseño del Sistema de Información (Primer Ciclo)

171 análisis y de los subsistemas de análisis, mientras que los subsistemas de soporte provienen de la necesidad de interacción del sistema software con la infraestructura y con el resto de los sistemas software, así como de la reutilización de módulos o subsistemas ya existentes en la instalación. Para poder definir los subsistemas de soporte es necesaria la participación de personas con distintos perfiles técnicos, por lo tanto se propone el diseño de ambos tipos de subsistemas en actividades realizadas 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 software. Este factor es especialmente crítico en arquitecturas multinivel o cliente/servidor, donde las comunicaciones son determinantes en el rendimiento final del sistema software. Además 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 software. Dicho catálogo 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 particularidades de la arquitectura del sistema propuesta, los requisitos de operación, seguridad y control, especificando los procedimientos necesarios para su cumplimiento. En resumen, como resultado final de esta actividad, se actualizan los requisitos y las normas, y se generan los siguientes productos: Diseño de la Arquitectura del Sistema, producto que engloba el particionamiento físico del sistema software y la descripción de subsistemas de diseño. Entorno Tecnológico del Sistema, producto 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, que incluye las situaciones anómalas en el funcionamiento del sistema software. Procedimientos de Operación y Administración del Sistema. Procedimientos de Seguridad y Control de Acceso. Ing. Pablo Pytel 171 Diseño del Sistema de Información (Primer Ciclo)

172 DEFINICIÓN DE NIVELES DE ARQUITECTURA Esta tarea define los niveles de arquitectura software, mediante la definición de las principales participaciones físicas del sistema software, representadas como nodos y comunicaciones entre nodos. Se entiende por nodo a cada participación física o parte significativa del sistema software, con características propias de ejecución o función, e incluso, de diseño y construcción. Para facilitar la comprensión del sistema, el mismo se documenta mediante un Modelo de Despliegue de Componentes de UML, el cual incluye los siguientes tipos de elementos: - 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 El sistema software de este proyecto se puede instalar en un único equipo, por lo que se define un único nodo con las siguientes características: a. Entorno de Hardware: El hardware es una máquina de tipo PC con las siguientes características mínimas: - Pentium III o superiores (2.0 GHZ) - 1 GB de memoria RAM (o más) - Disco rígido de 20 GB (o superior) b. Software: - Sistema Operativo Windows XP, 2000, 7 o superior. - Debido a que se utiliza Java como lenguaje de desarrollo es necesario la instalación de Java Runtime Environment (JRE) 1.5 o posterior para su ejecución. - No requiere de una base de datos. El nodo se encuentra formado por los componentes que se presentan, junto con su relación, en la figura PDSI 1. Debido a la existencia de un único equipo y la ausencia de Base de Datos, la comunicación entre componentes se realiza a través de mensajes en un modelo POO (Programación Orientada a Objetos). Ing. Pablo Pytel 172 Diseño del Sistema de Información (Primer Ciclo)

173 Figura PDSI 1: Diagrama de componentes del Sistema A continuación se realiza una descripción de los componentes identificados: Configurador: representa las funcionalidades que permiten al usuario definir los parámetros generales y de los factores de costo que serán utilizados para generar y procesar los proyectos. Procesador de Proyectos: representa las funcionalidades que permiten al usuario generar aleatoriamente los datos de los proyectos y estimarlos al utilizar las fórmulas del método DMCoMo. Tamaños de Proyectos: representa la tabla que contiene los valores permitidos para cada uno de los factores de costo de acuerdo al tamaño del proyecto. Parámetros de Configuración: representa la configuración seleccionada por el usuario para los parámetros generales que serán utilizados al momento de procesar los proyectos. Factores de Costo Configurados: representa la configuración seleccionada por el usuario para los factores de costo que es utilizada para generar aleatoriamente los proyectos. Ing. Pablo Pytel 173 Diseño del Sistema de Información (Primer Ciclo)

174 Proyectos Estimados: representa a los proyectos procesados, o sea, proyectos generados aleatoriamente por el sistema software a los cuáles se les aplico las fórmulas de estimación del método DMCoMo IDENTIFICACIÓN DE REQUISITOS DE DISEÑO Y CONSTRUCCIÓN Esta tarea se ocupa de realizar 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. 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 lo tanto, como resultado de esta tarea se actualiza el catálogo de requisitos elaborado en el Estudio de Viabilidad del Sistema Descripción de los Requisitos Adicionales Los requisitos no funcionales que se identificaron durante el diseño para el primer ciclo de desarrollo y se agregaron al Catálogo de Requisitos general (definido en la sección ) se detallan a continuación. Además, en la figura PDSI 2 se muestran los requisitos no funcionales del sistema incluyendo los nuevos agregados. b. Requisitos No Funcionales: RNF 6: Rendimiento General RNF 6.1: Se desarrollarán los componentes del sistema software teniendo en cuenta que serán utilizados por un único usuario. Ing. Pablo Pytel 174 Diseño del Sistema de Información (Primer Ciclo)

175 Figura PDSI 2: Nuevo Requisitos No Funcionales del Sistema Software (en gris oscuro se resaltan los requisitos incluidos en el actual ciclo de desarrollo) ESPECIFICACIONES DE EXCEPCIÓN Esta tarea tiene como objetivo definir los comportamientos no habituales del sistema software y que reflejan situaciones anómalas o secundarias en el funcionamiento y ejecución del sistema software. Para ello primero se define el nivel de especificación de las mismas, así como los criterios de catalogación y clasificación. A través de su catalogación, se busca ayudar la definición del diseño del sistema software y la especificación técnica de las pruebas, dado que permite generar algunos casos de prueba de forma inmediata. Este catálogo se va completando a partir de las actividades correspondientes al diseño detallado de los subsistemas. Para definir las excepciones se describen, al menos, los siguientes conceptos: Tipo y descripción de la excepción. Condiciones previas del sistema software. Ing. Pablo Pytel 175 Diseño del Sistema de Información (Primer Ciclo)

176 Elemento afectado (nodo, módulo, caso de uso). Respuesta del sistema software. 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 software, las cuales están normalmente asociadas a: Nodos y comunicaciones del particionamiento físico del sistema software. Este tipo de excepciones tiene lugar cuando no están disponibles los motores 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.. Además, 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 Catálogo de Excepciones Para el primer ciclo de desarrollo del sistema software no fueron detectadas excepciones para ser consideradas IDENTIFICACIÓN DE SUBSISTEMAS DE DISEÑO Esta tarea tiene el objetivo de dividir de forma lógica el sistema software en subsistemas de diseño. Así se busca reducir la complejidad y facilitar el mantenimiento. Como referencia inicial se toman 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. Aplicación de mecanismos genéricos de diseño al nivel de arquitectura. Ing. Pablo Pytel 176 Diseño del Sistema de Información (Primer Ciclo)

177 Los subsistemas resultantes se pueden calificar como específicos o de soporte, asignando cada subsistema al nodo correspondiente (de todas formas, esto no aplica en el caso del presente proyecto por haber existido un único nodo). Para definir la ubicación de subsistemas en nodos y la dependencia entre subsistemas se especifica por medio de técnicas matriciales, en lenguaje natural o en pseudocódigo. Como ya se ha dicho, los subsistemas específicos, se contemplan las funcionalidades propias del sistema software, mientras que los de soporte cubren servicios comunes, proporcionando un acceso transparente a los distintos recursos. Por la interacción del sistema software con la infraestructura que le da soporte, así como con el resto de los sistemas y servicios de la instalación, se pueden agregar nuevos subsistemas, módulos, clases o servicios no especificados en el análisis. Los subsistemas de soporta poseen funcionalidades relacionadas 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. Durante el diseño detallado se completa la definición del comportamiento externo de cada subsistema utilizando la especificación de su interfaz, así como con la dependencia entre subsistemas. Además, como esta tarea también se puede reorganizar y reubicar los elementos que forman parte de cada subsistema y, a su vez, identificar de nuevos subsistemas de soporte al utilizar los criterios de optimización y reutilización. En diseño estructurado, la descripción de los subsistemas de diseño que conforman el sistema software 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 Subsistemas de Diseño Dado que este sistema software no posee base de datos, y sólo hay un nodo en el diseño arquitectónico, se decidió dividir lógicamente al sistema en dos capas, que representan Ing. Pablo Pytel 177 Diseño del Sistema de Información (Primer Ciclo)

178 cada una a un subsistema. Estas capas serán las de interfaz gráfica de usuario y la capa de lógica de negocio, las cuales se representan en la figura PDSI 3. Figura PDSI 3: Diagrama de capas del sistema en dos capas lógicas (sub-sistemas) En caso necesario que en el futuro se necesite integrar con una base de datos se podría agregar, al menos, una capa de acceso a datos (que 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 ESPECIFICACIÓN DEL ENTORNO TECNOLÓGICO Esta tarea tiene como objetivo definir en detalle los elementos de la infraestructura técnica que da soporte al sistema software. Además se determinan la implementación concreta de los nodos y las comunicaciones especificados en la tarea Definición de Niveles de Arquitectura (sección 6.2.1). Para realizar 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 este sistema software no es necesario considerar este punto) A partir de la definición de los distintos elementos, se puede generar nuevas restricciones técnicas que afecten al diseño o Construcción del Sistema de Información. Además, se realiza una estimación de la planificación de capacidades (capacity planning) y se especifican los parámetros que Explotación y Sistemas precisen para realizar dicha planificación. Para ello se indican, al menos, las necesidades previstas de: Ing. Pablo Pytel 178 Diseño del Sistema de Información (Primer Ciclo)

179 Almacenamiento: espacio en disco, espacio en memoria, pautas de crecimiento y evolución estimada del sistema software, 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 software puede ser ejecutado en equipos de distintas tecnologías. Se estiman las siguientes configuraciones mínimas: Plataforma Intel: - Pentium III o superiores (2.0 GHZ) - 1 GB de memoria RAM (o más) - Disco rígido de 20 GB (o superior) Plataforma AMD: - Athlon o superiores (2.0 GHZ) - 1 GB de memoria RAM (o más) - Disco rígido de 20 GB (o superior) Especificación de Software Debido a que fue utilizado Java como lenguaje (el cual es multiplataforma), el sistema software podría ser ejecutado en distintas plataformas de software. Sin embargo dado el requerimiento no funcional RNF 3 Soporte de Sistemas Operativos, el sistema software fue desarrollado y probado solamente para los sistemas operativos Microsoft Windows XP, 2000, 7 o superior Especificación de Comunicación En este sistema software se utiliza en un único equipo por lo que no se requirió ninguna especificación para los medios de comunicación y red. Ing. Pablo Pytel 179 Diseño del Sistema de Información (Primer Ciclo)

180 ESPECIFICACIÓN DE REQUISITOS DE OPERACIÓN Y SEGURIDAD Esta tarea tiene el objetivo de 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.). Tomando como referencia los requisitos establecidos para el sistema además de la arquitectura propuesta y las características del entorno tecnológico definido en esta actividad, se define 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. Los niveles de servicio se especifican formalmente en el proceso Implantación y Aceptación del Sistema (IASI). Por otro lado, debido a que el sistema software no utiliza ninguna base de datos, este paso del diseño no se realizó en esta instancia. Queda como una posible modificación para realizar en una futura versión del sistema software en caso que sea necesario DISEÑO DE LA ARQUITECTURA DE SOPORTE Esta actividad específica la arquitectura de soporte, que incluye tanto el diseño de los subsistemas de soporte identificados en la actividad de Definición de la Arquitectura del Sistema (sección 6.2), como la definición de los mecanismos genéricos de diseño. Estos últimos son utilizados como guía en la utilización de diferentes estilos de diseño, tanto en el ámbito global del sistema software, como en el diseño de detalle. Para realizar el diseño de los subsistemas de soporte, se utiliza un proceso similar al diseño de los subsistemas específicos, aunque se debe cumplir con unos objetivos claros de reutilización. Así se consigue simplificar y abstraer el diseño de los subsistemas específicos de la complejidad del entorno tecnológico, dotando al sistema software de una mayor independencia de la infraestructura que le da soporte. Se aconseja consultar los datos de otros proyectos existentes, disponibles en el Histórico de Proyectos pero, 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. Debido a que existe una constante realimentación, esta actividad se realiza en paralelo al diseño detallado, 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: Ing. Pablo Pytel 180 Diseño del Sistema de Información (Primer Ciclo)

181 Diseño Detallado de los Subsistemas de Soporte. Mecanismos Genéricos de Diseño y Construcción DISEÑO DE SUBSISTEMAS DE SOPORTE Esta tarea tiene como objetivo la especificación y diseño de los módulos/clases que forman parte de los subsistemas de soporte, los cuales fueron 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. Se intenta que nivel de reutilización de los subsistemas de soporte y sus servicios sea alto al intentar emplear, en la medida de lo posible, los subsistemas que ya existan en la instalación y se consideren viables. Para ello se utiliza la información relativa a dichos subsistemas del Histórico de Proyectos. El diseño de los subsistemas de soporte sigue las mismas pautas que las establecidas para los subsistemas específicos, aunque con las siguientes particularidades: Generalmente, es 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. 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 Para el presente sistema software, la arquitectura del sistema consta de un único nodo (equipo), sin utilizar ninguna base de datos ni comunicación del equipo con otro equipo o dispositivo especial. El sistema software realiza principalmente la generación de valores numéricos aleatorios y cálculos sencillos (funcionalidad incluida en el primer ciclo de desarrollo), permitiendo Ing. Pablo Pytel 181 Diseño del Sistema de Información (Primer Ciclo)

182 visualizar los resultados (parte de la funcionalidad incluida en el primer ciclo de desarrollo y luego completada en el segundo ciclo) y almacenarlos en archivos de texto (funcionalidad a ser incluida en el segundo ciclo de desarrollo). Debido a que estas son operaciones sencillas y normales en cualquier aplicación no se requirió para su soporte de tecnología especial. Así se utilizaron solamente las clases estándar (incluyendo las de interfaz gráfica y manejo de archivos) que proporciona el lenguaje Java en general y el entorno Easy Java Simulations en particular. Además, al no utilizar ninguna base de datos ni mecanismos de seguridad en relación al almacenamiento de información, no fue necesario trabajar con transacciones ni con archivos de respaldo DISEÑO DE CASOS DE USO REALES Esta actividad sólo se realiza en el caso de Diseño Orientado a Objetos, y tiene como objetivo especificar el comportamiento del sistema software 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. Las tareas de esta actividad se realizan en paralelo con las de Diseño de Clases. 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 (o sea, los detalles relacionados con la implementación del sistema). Además, 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. Todas las excepciones identificadas se añadirán al catálogo de excepciones para facilitar las pruebas. En caso de se requiere una nueva interfaz de usuario, es necesario diseñar el formato de cada una de las pantallas o impresos identificados. Además, durante esta actividad pueden surgir requisitos de implementación, que se recogen en el catálogo de requisitos. Por último, 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. Ing. Pablo Pytel 182 Diseño del Sistema de Información (Primer Ciclo)

183 IDENTIFICACIÓN DE CLASES ASOCIADAS A UN CASO DE USO Esta tarea tiene como objetivo identificar las clases definidas en la tarea Identificación de Clases Adicionales que intervienen en cada caso de uso. 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 En esta tarea se describieron las clases de diseño que se utilizaron para realizar cada caso de uso identificado durante el proceso de Análisis del primer ciclo de desarrollo (sección ). Esto se representa a través de los diagramas de clases de caso de uso que se muestran en las figuras PDSI 4 a PDSI 6. Figura PDSI 4: Diagrama de Clases del caso de uso Configurar Parámetros Ing. Pablo Pytel 183 Diseño del Sistema de Información (Primer Ciclo)

184 Figura PDSI 5: Diagrama de Clases del caso de uso Configurar Factores de Costo del Proyecto Figura PDSI 6: Diagrama de Clases del caso de uso Generar Proyectos Estimados A continuación se muestra en la tabla PDSI 1 cómo se vinculan las clases definidas durante el proceso de análisis y las clases encontradas durante el diseño. Clases de Análisis Interfaz Principal Usuario Interfaz de Configurar Parámetros Interfaz de Configurar Factores de Costos Interfaz de Generar Proyectos Estimados Asistente para Configurar Parámetros Clases de diseño IUPrincipal IUConfigParametros IUConfigFactCosto IUProcProyectos ConfigParametros Ing. Pablo Pytel 184 Diseño del Sistema de Información (Primer Ciclo)

185 Clases de Análisis Asistente para Configurar Factores de Costo Asistente para Generar Proyectos Estimados Asistente para Generar Datos de Proyectos Asistente para Calcular Costos Estimados Parámetros de Tamaños de Proyectos Parámetros Configuración de Factores de Costo Proyectos Estimados Clases de diseño ConfigFactCosto ProcProyectos GenProyectos CalcCostosEstimados ParamTamProyecto ParamGral ParamFactCosto ProyEstimados Tabla PDSI 1: Vinculación entre clases de Análisis y Diseño REVISIÓN DE LA INTERFAZ DE USUARIO Esta tarea tiene como objetivo 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. Esto incluye 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. Para ello se utiliza el prototipo de la interfaz de usuario disponible 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. 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 los diagramas de clases asociados a los casos de uso (sección ) no aparecieron nuevas clases de interfaz ni modificaciones para las definidas en el análisis del primer ciclo de desarrollo. Ing. Pablo Pytel 185 Diseño del Sistema de Información (Primer Ciclo)

186 6.5. DISEÑO DE CLASES Esta actividad sólo se realiza en el caso de Diseño Orientado a Objetos, y su objetivo es transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño. Este modelo incluye la especificación detallada de cada 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. Además, se identifican las clases de diseño, que se denominan 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. Todas las clases definidas se agrupan en forma de paquetes. 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. En este caso, se divide el sistema en tres paquetes principales, los cuales se describen a continuación: Ing. Pablo Pytel 186 Diseño del Sistema de Información (Primer Ciclo)

187 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. La relación entre estos tres paquetes se puede ver en la figura PDSI 7. Figura PDSI 7: Relación entre los paquetes del sistema Por último, en los casos en que sea necesaria una migración de datos de otros sistemas o una carga inicial de información, se realiza su especificación a partir del modelo de clases y las estructuras de datos de los sistemas origen. Como resultado de 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 Esta tarea tiene como objetivo identificar y describir los atributos de las clases, una vez que se ha especificado el entorno de desarrollo. Para identificar los atributos se revisa el modelo de clases obtenido en el proceso de Análisis del Sistema de Información, considerando que puede ser necesario definir atributos adicionales. Ing. Pablo Pytel 187 Diseño del Sistema de Información (Primer Ciclo)

188 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 Para realizar esta tarea se completó para cada una de las clases de diseño la información, relativa a sus atributos y tipo de dato del atributo (utilizando los nombres provistos por Java), en la tabla PDSI 2 a continuación: Clase Atributos Tipo ConfigParametros ConfigFactCosto ProcProyectos GenProyectos CodigoTamProyectoSelecc GenTodosFactCostoAzar CodigoFactCosto ValorFactCosto GenFactCostoAzar CodigoModoGeneracion UltEstimCalculados23FactCosto UltEstimCalculados8FactCosto CantProyectosGenerados MediaEstimCalculados23FactCosto MediaEstimCalculados8FactCosto ValorFactCostNTAB ValorFactCostNTUP ValorFactCostNATR ValorFactCostDISP ValorFactCostPNUL ValorFactCostDMOD ValorFactCostDEXT ValorFactCostNMOD ValorFactCostTMOD ValorFactCostMTUP Boolean String Boolean Double Double Int Double Double Ing. Pablo Pytel 188 Diseño del Sistema de Información (Primer Ciclo)

189 Clase Atributos Tipo CalcCostosEstimados ValorFactCostMATRn ValorFactCostMATRt ValorFactCostMTEC ValorFactCostNFUN ValorFactCostSCOM ValorFactCostTOOL ValorFactCostCOMP ValorFactCostNFOR ValorFactCostNDEP ValorFactCostDOCU ValorFactCostSITE ValorFactCostMFAM ValorFactCostKDAT ValorFactCostADIR ValorFactCostNTAB ValorFactCostNTUP ValorFactCostNATR ValorFactCostDISP ValorFactCostPNUL ValorFactCostDMOD ValorFactCostDEXT ValorFactCostNMOD ValorFactCostTMOD ValorFactCostMTUP ValorFactCostMATRn ValorFactCostMATRt ValorFactCostMTEC ValorFactCostNFUN ValorFactCostSCOM ValorFactCostTOOL ValorFactCostCOMP ValorFactCostNFOR Ing. Pablo Pytel 189 Diseño del Sistema de Información (Primer Ciclo)

190 Clase Atributos Tipo ParamTamProyecto ValorFactCostNDEP ValorFactCostDOCU ValorFactCostSITE ValorFactCostMFAM ValorFactCostKDAT ValorFactCostADIR EstimCalculados23FactCosto EstimCalculados8FactCosto CodigoTamProyectoSelecc ValoresPermFactCostNTAB ValoresPermFactCostNTUP ValoresPermFactCostNATR ValoresPermFactCostDISP ValoresPermFactCostPNUL ValoresPermFactCostDMOD ValoresPermFactCostDEXT ValoresPermFactCostNMOD ValoresPermFactCostTMOD ValoresPermFactCostMTUP ValoresPermFactCostMATRn ValoresPermFactCostMATRt ValoresPermFactCostMTEC ValoresPermFactCostNFUN ValoresPermFactCostSCOM ValoresPermFactCostTOOL ValoresPermFactCostCOMP ValoresPermFactCostNFOR ValoresPermFactCostNDEP ValoresPermFactCostDOCU ValoresPermFactCostSITE ValoresPermFactCostMFAM ValoresPermFactCostKDAT Double Double Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Ing. Pablo Pytel 190 Diseño del Sistema de Información (Primer Ciclo)

191 Clase Atributos Tipo ParamGral ParamFactCosto ProyEstimados ValoresPermFactCostADIR CodigoTamProyectoSelecc GenTodosFactCostoAzar ValoresConfigFactCostNTAB ValoresConfigFactCostNTUP ValoresConfigFactCostNATR ValoresConfigFactCostDISP ValoresConfigFactCostPNUL ValoresConfigFactCostDMOD ValoresConfigFactCostDEXT ValoresConfigFactCostNMOD ValoresConfigFactCostTMOD ValoresConfigFactCostMTUP ValoresConfigFactCostMATRn ValoresConfigFactCostMATRt ValoresConfigFactCostMTEC ValoresConfigFactCostNFUN ValoresConfigFactCostSCOM ValoresConfigFactCostTOOL ValoresConfigFactCostCOMP ValoresConfigFactCostNFOR ValoresConfigFactCostNDEP ValoresConfigFactCostDOCU ValoresConfigFactCostSITE ValoresConfigFactCostMFAM ValoresConfigFactCostKDAT ValoresConfigFactCostADIR ProyectoNumeroID ValorFactCostNTAB ValorFactCostNTUP ValorFactCostNATR ValorFactCostDISP Array of Boolean Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Int Ing. Pablo Pytel 191 Diseño del Sistema de Información (Primer Ciclo)

192 Clase Atributos Tipo ValorFactCostPNUL ValorFactCostDMOD ValorFactCostDEXT ValorFactCostNMOD ValorFactCostTMOD ValorFactCostMTUP ValorFactCostMATRn ValorFactCostMATRt ValorFactCostMTEC ValorFactCostNFUN ValorFactCostSCOM ValorFactCostTOOL ValorFactCostCOMP ValorFactCostNFOR ValorFactCostNDEP ValorFactCostDOCU ValorFactCostSITE ValorFactCostMFAM ValorFactCostKDAT ValorFactCostADIR EstimCalculados23FactCosto EstimCalculados8FactCosto Double Double Tabla PDSI 2: Atributos de las clases Donde los tipos de datos provistos por Java están definidos en la tabla PDSI 3. Tipo de Dato Short Int Long Float Descripción Tipo de dato entero de 1 (8 bits). Tipo de dato entero de 2 s (16 bits). Tipo de dato entero de 4 s (32 bits). Tipo de dato entero de 8 s (64 bits). Tipo de dato con coma flotante 4 (32 bits). Ing. Pablo Pytel 192 Diseño del Sistema de Información (Primer Ciclo)

193 Tipo de Dato Double Boolean String Descripción Tipo de dato con coma flotante 8 s (64 bits) Tipo de dato lógico (verdadero/falso) de 1 bit. Tipo de dato de cadena de caracteres, su largo va a depender del largo de la cadena. Tabla PDSI 3: Tipos de datos utilizados en Java Por último, fue necesario definir el conjunto de restricciones que se les deben dar a los valores de los atributos de acuerdo a su significado y utilización en el sistema software. Estas restricciones en la forma de valores permitidos se muestran en la tabla PDSI 4, la cual está ordenada alfabéticamente por el nombre del atributo. Atributos Tipo Valores Permitidos CantProyectosGenerados CodigoFactCosto Int String Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. Cualquiera de los siguientes valores: ( "NTAB", "NTUP", "NATR", "DISP", "PNUL", "DMOD", "DEXT", "NMOD", "TMOD", "MTUP", "MATRn", "MATRt", "MTEC", "NFUN", "SCOM", "TOOL", "COMP", "NFOR", "NDEP", "DOCU", "SITE", "MFAM", "KDAT", "ADIR") CodigoModoGeneracion CodigoTamProyectoSelecc EstimCalculados23FactCosto EstimCalculados8FactCosto Double Double GenFactCostoAzar Boolean (Verdadero, Falso) GenTodosFactCostoAzar Boolean (Verdadero, Falso) MediaEstimCalculados23FactCosto Double Cualquiera de los siguientes valores: (1, 2) Dónde: 1 = Modo Calcular Costo para un proyecto. 2 = Modo Evaluación Continua. Cualquiera de los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Proyecto Tamaño Pequeño 2 = Proyecto Tamaño Mediano 3 = Proyecto Tamaño Grande 3 = Proyecto Tamaño Aleatorio Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. MediaEstimCalculados8FactCosto Double Cualquier valor mayor o igual a cero que sea Ing. Pablo Pytel 193 Diseño del Sistema de Información (Primer Ciclo)

194 Atributos Tipo Valores Permitidos ProyectoNumeroID UltEstimCalculados23FactCosto UltEstimCalculados8FactCosto ValoresConfigFactCostADIR ValoresConfigFactCostCOMP ValoresConfigFactCostDEXT ValoresConfigFactCostDISP ValoresConfigFactCostDMOD Int Double Double Array of Array of Array of Array of Array of permitido por el tipo de dato. Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) ValoresConfigFactCostDOCU Array of Lista que puede contener uno, más de uno o Ing. Pablo Pytel 194 Diseño del Sistema de Información (Primer Ciclo)

195 Atributos Tipo Valores Permitidos ValoresConfigFactCostKDAT ValoresConfigFactCostMATRn ValoresConfigFactCostMATRt ValoresConfigFactCostMFAM ValoresConfigFactCostMTEC ValoresConfigFactCostMTUP todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Array of Array of Array of Array of Array of Array of Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5, 6) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Ing. Pablo Pytel 195 Diseño del Sistema de Información (Primer Ciclo)

196 Atributos Tipo Valores Permitidos ValoresConfigFactCostNATR ValoresConfigFactCostNDEP ValoresConfigFactCostNFOR ValoresConfigFactCostNFUN ValoresConfigFactCostNMOD ValoresConfigFactCostNTAB Array of Array of Array of Array of Array of Array of Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: Ing. Pablo Pytel 196 Diseño del Sistema de Información (Primer Ciclo)

197 Atributos Tipo Valores Permitidos ValoresConfigFactCostNTUP ValoresConfigFactCostPNUL ValoresConfigFactCostSCOM ValoresConfigFactCostSITE ValoresConfigFactCostTMOD Array of Array of Array of Array of Array of 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) Ing. Pablo Pytel 197 Diseño del Sistema de Información (Primer Ciclo)

198 Atributos Tipo Valores Permitidos ValoresConfigFactCostTOOL ValoresPermFactCostADIR ValoresPermFactCostCOMP ValoresPermFactCostDEXT ValoresPermFactCostDISP ValoresPermFactCostDMOD Array of Array of Array of Array of Array of Array of 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) Ing. Pablo Pytel 198 Diseño del Sistema de Información (Primer Ciclo)

199 Atributos Tipo Valores Permitidos ValoresPermFactCostDOCU ValoresPermFactCostKDAT ValoresPermFactCostMATRn ValoresPermFactCostMATRt ValoresPermFactCostMFAM ValoresPermFactCostMTEC Array of Array of Array of Array of Array of Array of 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5, 6) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Ing. Pablo Pytel 199 Diseño del Sistema de Información (Primer Ciclo)

200 Atributos Tipo Valores Permitidos ValoresPermFactCostMTUP ValoresPermFactCostNATR ValoresPermFactCostNDEP ValoresPermFactCostNFOR ValoresPermFactCostNFUN ValoresPermFactCostNMOD Array of Array of Array of Array of Array of Array of 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Ing. Pablo Pytel 200 Diseño del Sistema de Información (Primer Ciclo)

201 Atributos Tipo Valores Permitidos ValoresPermFactCostNTAB ValoresPermFactCostNTUP ValoresPermFactCostPNUL ValoresPermFactCostSCOM ValoresPermFactCostSITE ValoresPermFactCostTMOD Array of Array of Array of Array of Array of Array of Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Ing. Pablo Pytel 201 Diseño del Sistema de Información (Primer Ciclo)

202 Atributos Tipo Valores Permitidos ValoresPermFactCostTOOL ValorFactCostADIR ValorFactCostCOMP ValorFactCostDEXT ValorFactCostDISP ValorFactCostDMOD Array of Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Cualquiera de los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: Ing. Pablo Pytel 202 Diseño del Sistema de Información (Primer Ciclo)

203 Atributos Tipo Valores Permitidos ValorFactCostDOCU ValorFactCostKDAT ValorFactCostMATRn ValorFactCostMATRt ValorFactCostMFAM ValorFactCostMTEC 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5, 6) Dónde: 1 = Muy Bajo (MB) Ing. Pablo Pytel 203 Diseño del Sistema de Información (Primer Ciclo)

204 Atributos Tipo Valores Permitidos ValorFactCostMTUP ValorFactCostNATR ValorFactCostNDEP ValorFactCostNFOR ValorFactCostNFUN ValorFactCostNMOD 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) Ing. Pablo Pytel 204 Diseño del Sistema de Información (Primer Ciclo)

205 Atributos Tipo Valores Permitidos ValorFactCostNTAB ValorFactCostNTUP ValorFactCosto ValorFactCostPNUL ValorFactCostSCOM 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) ValorFactCostSITE Cualquiera de los siguientes valores: (0, 1, 2, Ing. Pablo Pytel 205 Diseño del Sistema de Información (Primer Ciclo)

206 Atributos Tipo Valores Permitidos ValorFactCostTMOD ValorFactCostTOOL 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Tabla PDSI 4: Restricciones en los valores de los atributos IDENTIFICACIÓN DE OPERACIONES DE LAS CLASES Esta tarea tiene como objetivo 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 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. Cada una de las operaciones de las clases de diseño surge 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. En caso de identificar operaciones de objetos que presentan distintos estados, donde su comportamiento depende del estado en el que se encuentren, es recomendable realizar Ing. Pablo Pytel 206 Diseño del Sistema de Información (Primer Ciclo)

207 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 esta tarea fue realizado el análisis de los métodos de las clases identificadas teniendo en cuenta a la siguiente distinción: Métodos Triviales, lo cuales son utilizados para instanciar / eliminar un objeto o para leer / escribir valores en los atributos de un objeto (denominados comúnmente como getters y setters). Dependiendo del lenguaje en que se implemente, pueden ser implementados automáticamente por el lenguaje, por tal motivo, estos métodos no fueron documentados para facilitar el entendimiento del modelo. Métodos No Triviales, los cuales incluyen aquellos métodos que modelan e implementa reglas de negocio y de comportamiento de las clases del sistema. Estos métodos son diseñados y explicados en las tablas PDSI 5 a PDSI 8. Clase ProcProyectos Método Tipo Descripción Comenzar Finalizar Público Parámetros Resultado Público Parámetros --- Resultado Comienza a procesar los proyectos de acuerdo a al modo seleccionado y suministrado como parámetro al método. CodigoModoGeneracion: ProcesoFinalizadoConExito: Boolean ListaProyEstimados: Array of ProyEstimados Finaliza la ejecución del procesamiento de proyectos. Este método sólo es utilizado si se selecciona el modo de Evaluación Continua. ProcesoFinalizadoConExito: Boolean ListaProyEstimados: Array of ProyEstimados Tabla PDSI 5: Descripción de los métodos de la clase ProcProyectos Clase GenProyectos Método Tipo Descripción Generar Público Parámetros Resultado Genera aleatoriamente los datos de un proyecto de acuerdo a la configuración suministrada. configfactcosto: ParamFactCosto ProcesoFinalizadoConExito: Boolean Ing. Pablo Pytel 207 Diseño del Sistema de Información (Primer Ciclo)

208 Clase GenProyectos Método Tipo Descripción ValorFactCostNTAB: ValorFactCostNTUP: ValorFactCostNATR: ValorFactCostDISP: ValorFactCostPNUL: ValorFactCostDMOD: ValorFactCostDEXT: ValorFactCostNMOD: ValorFactCostTMOD: ValorFactCostMTUP: ValorFactCostMATRn: ValorFactCostMATRt: ValorFactCostMTEC: ValorFactCostNFUN: ValorFactCostSCOM: ValorFactCostTOOL: ValorFactCostCOMP: ValorFactCostNFOR: ValorFactCostNDEP: ValorFactCostDOCU: ValorFactCostSITE: ValorFactCostMFAM: ValorFactCostKDAT: ValorFactCostADIR: Tabla PDSI 6: Descripción de los métodos de la clase GenProyectos Clase CalcCostosEstimados Método Tipo Descripción Calcular23FactCosto Público Parámetros Calcula el costo estimado del proyecto utilizando los 23 factores de costo del método DMCoMo. ValorFactCostNTAB: ValorFactCostNTUP: ValorFactCostNATR: ValorFactCostDISP: ValorFactCostPNUL: ValorFactCostDMOD: ValorFactCostDEXT: ValorFactCostNMOD: Ing. Pablo Pytel 208 Diseño del Sistema de Información (Primer Ciclo)

209 Clase CalcCostosEstimados Método Tipo Descripción Calcular8FactCosto Resultado Público Parámetros Resultado ValorFactCostTMOD: ValorFactCostMTUP: ValorFactCostMATRn: ValorFactCostMATRt: ValorFactCostMTEC: ValorFactCostNFUN: ValorFactCostSCOM: ValorFactCostTOOL: ValorFactCostCOMP: ValorFactCostNFOR: ValorFactCostNDEP: ValorFactCostDOCU: ValorFactCostSITE: ValorFactCostMFAM: ValorFactCostKDAT: ValorFactCostADIR: ProcesoFinalizadoConExito: Boolean CostoEstimado: Double Calcula el costo estimado del proyecto utilizando los 23 factores de costo del método DMCoMo. ValorFactCostNTAB: ValorFactCostNATR: ValorFactCostDISP: ValorFactCostDEXT: ValorFactCostTMOD: ValorFactCostMATRn: ValorFactCostMATRt: ValorFactCostNFOR: ValorFactCostMFAM: ProcesoFinalizadoConExito: Boolean CostoEstimado: Double Tabla PDSI 7: Descripción de los métodos de la clase CalcCostosEstimados Clase ParamTamProyecto Método Tipo Descripción ObtenerValPermitidos Público Permite obtener los valores permitidos de los factores de costo a partir de un tamaño de proyecto seleccionado. Ing. Pablo Pytel 209 Diseño del Sistema de Información (Primer Ciclo)

210 Clase ParamTamProyecto Método Tipo Descripción Parámetros CodigoTamProyectoSelecc: Resultado ProcesoFinalizadoConExito: Boolean ValoresPermFactCostNTAB:Array of ValoresPermFactCostNTUP: Array of ValoresPermFactCostNATR: Array of ValoresPermFactCostDISP: Array of ValoresPermFactCostPNUL: Array of ValoresPermFactCostDMOD: Array of ValoresPermFactCostDEXT: Array of ValoresPermFactCostNMOD: Array of ValoresPermFactCostTMOD: Array of ValoresPermFactCostMTUP: Array of ValoresPermFactCostMATRn: Array of ValoresPermFactCostMATRt: Array of ValoresPermFactCostMTEC: Array of ValoresPermFactCostNFUN: Array of ValoresPermFactCostSCOM: Array of ValoresPermFactCostTOOL: Array of ValoresPermFactCostCOMP: Array of ValoresPermFactCostNFOR: Array of ValoresPermFactCostNDEP: Array of ValoresPermFactCostDOCU: Array of ValoresPermFactCostSITE: Array of ValoresPermFactCostMFAM: Array of ValoresPermFactCostKDAT: Array of ValoresPermFactCostADIR: Array of Tabla PDSI 8: Descripción de los métodos de la clase ParamTamProyecto Finalmente, dado que en esta tarea no fueron detectados objetos cuyo comportamiento cambie en función de su estado para el sistema software, por lo tanto, no fue necesario desarrollar los diagramas de transición de estados DIAGRAMA DE CLASES DE DISEÑO A continuación, en las figuras PDSI 8, PDSI 9 y PDSI 10 se describen los diagramas de clases en formato UML correspondientes a cada uno de los paquetes de Clases de Dominio, Clases de Procesos y Clases de Interfaz de Usuario respectivamente: Nota: Debido a la gran cantidad de atributos que tienen estas clases aquí fueron omitidas en su representación, complementando entonces al gráfico la tabla PDSI 2. Ing. Pablo Pytel 210 Diseño del Sistema de Información (Primer Ciclo)

211 a. Diagrama de clases para las Clases de Dominio: Figura PDSI 8: Diagrama de clases del Paquete de Dominio b. Diagrama de clases para las Clases de Proceso: Figura PDSI 9: Diagrama de clases del Paquete de Proceso Ing. Pablo Pytel 211 Diseño del Sistema de Información (Primer Ciclo)

212 c. Diagrama de Clases de Interfaz de Usuario Figura PDSI 10: Diagrama de clases del Paquete de Interfaz de Usuario Nótese que en este caso, por un tema de unificación de criterios de modelado las clases de interfaz fueron representadas como clases pero no recibieron una implementación directamente como clases, sino que fueron implementadas a través de formularios de Java ESPECIFICACIÓN DE NECESIDADES DE MIGRACIÓN Y CARGA INICIAL DE DATOS Esta tarea tiene como objetivo realizar 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 Debido a que en este sistema software no utiliza ninguna base de datos, no hizo falta definir datos iniciales. Por lo tanto, no fue necesaria la carga inicial ni la migración de los mismos para el funcionamiento del sistema DISEÑO FÍSICO DE DATOS Esta actividad se ocupa de definir la estructura física de datos que utiliza el sistema, a partir del modelo lógico de datos normalizado o modelo de clases. Así, teniendo presentes las características específicas del sistema de gestión de datos concretos a utilizar, los requisitos establecidos para el sistema software, y las particularidades del entorno tecnológico, se consiga una mayor eficiencia en el tratamiento de los datos. Ing. Pablo Pytel 212 Diseño del Sistema de Información (Primer Ciclo)

213 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. Se realizan de forma iterativa y en paralelo con las realizadas en las actividades de: 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 Casos de Uso Reales y de Clases, en el caso de que se utilice desarrollo orientado a objetos, dónde se especifica la lógica de tratamiento de los objetos y sus interfaces utilizadas. En este caso, 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. Diseño de la Arquitectura de Módulos del Sistema, en el caso de que se utilice desarrollo estructurado, dónde se especifica la lógica de tratamiento de los módulos y las interfaces utilizadas. 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 Como ya se ha mencionado, este sistema software no cuenta con Base de Datos. Por lo tanto no fue necesaria definir el modelo físico de los datos VERIFICACIÓN Y ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA Esta actividad tiene el objetivo de garantizar la calidad de las especificaciones del diseño del sistema software y su viabilidad, para poder luego comenzar la generación de las especificaciones de construcción. Las siguientes acciones se realizan para lograr esto: Verificación de la calidad técnica de cada modelo o especificación Aseguramiento de la coherencia entre los distintos modelos Ing. Pablo Pytel 213 Diseño del Sistema de Información (Primer Ciclo)

214 VERIFICACIÓN DE LA ESPECIFICACIÓN DE DISEÑO Esta tarea tiene como objetivo asegurar la calidad formal de los modelos de diseño generado, conforme a la técnica utilizada para la elaboración de cada producto y a las normas y estándares especificados Resultado de la Verificación de la Especificación de Diseño Para realizar esta tarea se han verificado los distintos modelos generados junto con los Directores de Tesis. Como resultado de esta tarea se han realizado modificaciones en los modelos, las cuales ya se encuentran aplicadas ANÁLISIS DE CONSISTENCIA DE LAS ESPECIFICACIONES DE DISEÑO Esta tarea tiene como objetivo asegurar que las especificaciones del diseño sean coherentes entre sí, es decir que no existen ambigüedades ni duplicación de información. Para ello se revisa la consistencia entre especificaciones de diseño con respecto a los modelos del análisis. Para realizar las diferentes comprobaciones se utilizan generalmente técnicas matriciales o de revisión entre los elementos comunes de los distintos modelos. Este análisis de consistencia relativo a la arquitectura del sistema es común para desarrollo estructurado y para el 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 Para realizar el análisis de consistencia se comprobó la coherencia entre los distintos modelos de acuerdo a las trazabilidades que se presentan en la figura PDSI 11. Ing. Pablo Pytel 214 Diseño del Sistema de Información (Primer Ciclo)

215 Figura PDSI 11: Diagrama de Entidad relación del proyecto a. Clases Asociadas a los Casos de Uso vs Clases de Interfaz de Usuario / Clases de Proceso / Clases de Dominio Se realizó la comparación de las clases de diseño asociadas a los casos, comparándolas con las clases de los tres paquetes (Paquete de Clases de Interfaz de Usuario, Paquete de Clases de Proceso y Paquete de Clases de Dominio). Para ello se completaron dos matrices: - Primero en la matriz de la tabla PDSI 9 se colocan en las filas se listan las clases de cada paquete y en las columnas los casos de uso, así por cada intersección se indica que casos de uso utilizan cada clase. - Por otro lado, en la matiz de la tabla PDSI 10 donde en las filas se listan las clases asociadas a los casos de uso y en las columnas los tres paquetes, así por cada intersección se indica a que paquete pertenece cada clase. Como se puede observar de ambas matrices, existe al menos una relación entre ambas clases. Ing. Pablo Pytel 215 Diseño del Sistema de Información (Primer Ciclo)

216 Clases asociadas a los Paquetes / Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Paquete de Clases de Dominios ParamGral X X X ParamTamProyecto X X ParamFactCost X X X ProyEstimados X ConfigParametros X Paquete de Clases ConfigFactCostos ProcProyectos X X de Procesos GenProyectos X CalcCostosEstimados X IUPrincipal X X X Paquete de clases IUConfigParametros X de Interfaz de Usuario IUConfigFactCostos X IUProcProyectos X Tabla PDSI 9: Trazabilidades entre Clases de Interfaz de Usuario / Clases de Proceso / Clases de Dominio vs. los Casos de Uso Clases asociadas a los Casos de Uso / Paquetes Paquete de Clases de Dominios Paquete de Clases de Procesos Paquete de clases de Interfaz de Usuario Caso de uso Configurar Parámetros ParamGral ParamTamProyecto X X Ing. Pablo Pytel 216 Diseño del Sistema de Información (Primer Ciclo)

217 Clases asociadas a los Casos de Uso / Paquetes Paquete de Clases de Dominios Paquete de Clases de Procesos Paquete de clases de Interfaz de Usuario ParamFactCosto X ConfigParametros X IUPrincipal X IUConfigParametros X ParamGral X Caso de uso Configurar Factores de Costo del Proyecto ParamTamProyecto ParamFactCosto ConfigFactCostos IUPrincipal X X X X IUConfigFactCostos X ParamGral X ParamFactCosto X ProyEstimados X Caso de uso Generar ProcProyectos X Proyectos Estimados GenProyectos X CalcCostosEstimados X IUPrincipal X IUProcProyectos X Tabla PDSI 10: Trazabilidades entre Clases Asociadas a los Casos de Uso versus Clases de Interfaz de Usuario / Clases de Proceso / Clases de Dominio Ing. Pablo Pytel 217 Diseño del Sistema de Información (Primer Ciclo)

218 b. Clases de Interfaz de Usuario vs Pantalla de la fase de Análisis revisadas Para realizar esta verificación se completó la matriz de la tabla PDSI 11 que contiene dos columnas: a la izquierda, se describen las clases de paquetes de Clases de Interfaz de Usuario y, en la columna de la derecha las pantallas de la fase de análisis revirevisadas durante el diseño. Como se puede observar, existe una relación uno a uno entre ambos componentes: Clases de Interfaz de Usuario IUPrincipal IUConfigParametros IUConfigFactCostos IUProcProyectos Pantallas Revisadas Pantalla Principal (Menú Principal) Configurar Parámetros Configurar Factores de Costo Generar Proyectos Estimados Tabla PDSI 11: Trazabilidades entre las Clases de Interfaz de Usuario y las Pantallas Revisadas ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA CORRESPONDIENTE AL PRIMER CICLO DE DESARROLLO Esta tarea tiene el objetivo de obtener la aceptación de la arquitectura del sistema software y de los requisitos de operación y seguridad, por parte de las áreas de explotación y sistemas, con el fin de poder valorar su impacto en la instalación. Luego de reunión mantenida entre el tesista y los directores del proyecto de tesis se dio por aprobada la arquitectura del sistema software para el primer ciclo de desarrollo GENERACIÓN DE ESPECIFICACIONES DE CONSTRUCCIÓN Esta actividad tiene el objetivo de generar las especificaciones que se utilizan para la Construcción del Sistema de Información, a partir del diseño detallado. Estas especificaciones definen la Construcción del Sistema de Información (CSI) a partir de los componentes, entendiendo como tales las unidades básicas 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. A través de la división del sistema software en subsistemas de diseño es posible obtener una primera división en subsistemas de construcción, definiendo para cada uno los componentes que lo integran. En caso necesario además se puede dividir un subsistema de Ing. Pablo Pytel 218 Diseño del Sistema de Información (Primer Ciclo)

219 diseño en sucesivos niveles para mayor claridad de las especificaciones de construcción. Por otro lado, las dependencias entre subsistemas de diseño proporcionan la información para establecer las dependencias entre los subsistemas de construcción, y así permite definir el orden (o secuencia) que se debe seguir en la construcción y en la realización de las pruebas. Por último, también se definen las especificaciones necesarias para la creación de las estructuras de datos en los motores de bases de datos y/o sistemas de archivos. El producto resultante de esta actividad es el conjunto de las especificaciones de Construcción del Sistema de Información (CSI), 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 software. Especificación detallada de componentes. Especificación de la estructura física de datos ESPECIFICACIÓN DEL ENTORNO DE CONSTRUCCIÓN Esta tarea tiene el objetivo de definir en forma detallada y completa del entorno necesario para la construcción de los componentes del sistema software. Para ello se propone que la especificación del entorno se realice según los siguientes conceptos: 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. En la tabla PDSI 12, se completan las especificaciones del entorno tecnológico para el sistema software: Concepto Definición Entorno tecnológico: Hardware, Software y Comunicaciones PC Intel Core Duo PC 2.20Ghz/2.20Ghz con 4 GB Memoria RAM y un disco rígido de 300 GB Ing. Pablo Pytel 219 Diseño del Sistema de Información (Primer Ciclo)

220 Concepto Definición Sistema Operativo Windows 7 No se observan requisitos de comunicaciones Herramientas de construcción, generadores de código, compiladores, etc. Easy Java Simulations (EJS) Java Runtime Environment (JRE) 1.5 o posterior Microsoft Office 2007 o superior Restricciones técnicas del entorno No se observan restricciones Planificación de capacidades previstas, o la información que estime oportuna el departamento de sistemas para efectuar dicha planificación No se observan Requisitos de operación y seguridad del entorno de construcción No se observan requisitos Tabla PDSI 12: Especificaciones del entorno tecnológico DEFINICIÓN DE COMPONENTES Y SUBSISTEMAS DE CONSTRUCCIÓN En esta tarea se determina, a partir de los subsistemas de diseño, la especificación de los subsistemas de construcción, permitiéndose a su vez un mayor nivel de detalle agrupando componentes en subsistemas dentro de un subsistema de construcción. Para definir los componentes se utiliza la agrupación de elementos del diseño de detalle de cada subsistema de diseño. En principio, para cada clase/módulo y cada formato individual de interfaz se corresponden con un componente, aunque se pueden agrupar o redistribuir clases/ módulos en componentes, siguiendo otros criterios más oportunos, como los siguientes: 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. Ing. Pablo Pytel 220 Diseño del Sistema de Información (Primer Ciclo)

221 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. Por ejemplo entre estos aspectos se pueden mencionar: secuencia de compilación entre componentes y agrupación de elementos en librerías o packages (DLL en el entorno Windows o packages en Java). La asignación de subsistemas de construcción a nodos, determina la distribución de los componentes que lo integran. En forma opcional, se propone también la realización de un plan de integración del sistema software, 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 este sistema software fue decidido dejar las clases tal y como se han diseñado. Entonces, cada clase que compone el diseño se encuentra representada por una clase en el dominio de la implementación y viceversa. Esto se muestra en el diagrama UML de la figura PDSI 12. Dominio de Diseño Dominio de Implementación Clases de Diseño <<Traza>> Componentes de Implementación Figura PDSI 12: Relación entre los dominios de diseño e implementación 6.9. ESPECIFICACIÓN TÉCNICA DEL PLAN DE PRUEBAS Esta actividad tiene el objetivo de especificar el detalle del plan de pruebas del sistema software para cada uno de los niveles de prueba establecidos en el proceso Análisis del Sistema de Información (ASI). Para ello se utiliza como referencia el plan de pruebas que incluye los objetivos de la prueba de un sistema, luego 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 Ing. Pablo Pytel 221 Diseño del Sistema de Información (Primer Ciclo)

222 puede ser una referencia el plan de integración del sistema software propuesto, opcionalmente, en la tarea Definición de Componentes y Subsistemas de Construcción. Por otro lado, a través del catálogo de requisitos, el catálogo de excepciones y el diseño detallado del sistema software, se puede definir las verificaciones que deben realizarse en cada nivel de prueba para comprobar que el sistema responde a los requisitos planteados. Las distintas verificaciones de cada nivel de prueba establecido se logran a través de la asociación de las distintas verificaciones a componentes, grupos de componentes y subsistemas, o al sistema software completo. Entonces considerando los niveles de pruebas establecidos en el proceso Análisis del Sistema de Información se define el siguiente alcance: Pruebas Unitarias Estas pruebas comprenden las verificaciones asociadas a cada componente del sistema software, y su realización tiene como objetivo verificar la funcionalidad y estructura de cada componente individual. Pruebas de Integración Estas pruebas 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 software; tienen por objetivo verificar el correcto ensamblaje entre los distintos componentes. Pruebas del Sistema Estas pruebas corresponden a verificaciones asociadas a la integración del sistema software completo, y entonces 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. Pruebas de Implantación Estas pruebas corresponden a las verificaciones necesarias para asegurar que el sistema software funciona 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. Pruebas de Aceptación Estas pruebas corresponden a verificaciones que van dirigidas a validar que el sistema cumple los requisitos de funcionamiento esperado, recogidos en el catálogo de Ing. Pablo Pytel 222 Diseño del Sistema de Información (Primer Ciclo)

223 requisitos y en los criterios de aceptación del sistema software, y conseguir la aceptación final del sistema por parte del usuario. Las pruebas unitarias, de integración y del sistema se ejecutan 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 (IASI). Como resultado de esta actividad se actualiza el plan de pruebas con la siguiente información: 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 Esta tarea tiene el objetivo de definir en forma detallada y completa el entorno necesario para la realización de las pruebas unitarias, de integración, del sistema, de implantación y de aceptación. Entonces se propone considerar los siguientes conceptos en la especificación del entorno: Entorno tecnológico: hardware, software y comunicaciones. Restricciones técnicas del entorno. 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 este proyecto no fue requerido especificar nuevos elementos de equipamiento, tanto a nivel de hardware como de software, para poder ejecutar los casos de pruebas. A continuación se describe cuál es el mecanismo de promoción de elementos entre entornos y procedimientos de emergencia y recuperación en caso de fallo: Ing. Pablo Pytel 223 Diseño del Sistema de Información (Primer Ciclo)

224 a. Procedimientos de Promoción: Para realizar las pruebas, el sistema software es instalado en un equipo donde se cuente con un programa de compresión de archivos (por ejemplo aplicaciones comerciales como WinRar o WinZip). Una vez que el sistema software es probado y aprobado, se generan archivos de estas características para cada directorio involucrado con el sistema y los mismo son resguardados para su puesta en producción. b. Procedimientos de Emergencia y de Recuperación: Como emergencia se define la necesidad de hacer una recuperación del sistema, cuando el equipo se vea dañado físicamente y por ende provoque mal funcionamiento en la aplicación. Debe 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 Esta tarea tiene como objetivo completar y especificar 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 de acuerdo a la estrategia de integración establecida Planificación de Pruebas Se generó un plan de pruebas, considerando que el sistema ha sido desarrollado con un enfoque de casos de uso, para probar funcionalmente el sistema desde el punto de vista de los casos de uso, componentes de infraestructura y pruebas globales del sistema. Por eso, los tipos de prueba a realizar son: Pruebas Unitarias, los cuales prueban componentes específicos del sistema. Pruebas de Integración, los cuales abarcan las pruebas por casos de uso. Pruebas de Sistema, los cuales serán ejecutadas y obtenidos sus resultados (utilizando al propio sistema como herramienta y probando el circuito total). Ing. Pablo Pytel 224 Diseño del Sistema de Información (Primer Ciclo)

225 Pruebas Unitarias Para el primer ciclo de desarrollo del sistema software fue identificado un único componente que es probado en forma independiente y corresponde al componente CalcCostosEstimados del caso de uso Generar los Proyectos Estimados. Las pruebas tuvieron el objetivo de verificar la correcta implementación de las fórmulas para el cálculo del costo estimado definidas por el método DMCoMo. Se utilizó la funcionalidad provista por el caso de uso Configurar Factores de Costo del Proyecto para definir los valores específicos de los factores de costo que se deseaban utilizar para luego calcular los costos estimados mediante el caso de uso Generar los Proyectos Estimados. Estos valores fueron comparados con los resultados de la planilla de cálculo Prueba DMCoMo que implementaba también las fórmulas como medio de control (esta planilla fue utilizada para definir la salida esperada para cada uno de los casos de prueba). En la tabla PDSI 13 se listan los casos de prueba unitarias que fueron realizados: Código CP-001 CP-002 CP-003 CP-004 CP-005 CP-006 Componente (Caso de Uso) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) Objetivo Calcular los costos estimados para un proyecto de tamaño pequeño. Calcular los costos estimados para un proyecto de tamaño mediano. Calcular los costos estimados para un proyecto de tamaño grande. Calcular los costos estimados para un proyecto de tamaño aleatorio (o sea, sin restricción en los valores a utilizar). Calcular los costos estimados para un proyecto de tamaño aleatorio variando sólo uno de los factores de costo que afecta ambas fórmulas. Calcular los costos estimados para un proyecto de tamaño aleatorio variando sólo uno de los factores de costo que afecta sólo a una de las fórmulas. Tabla PDSI 13: Caso de Pruebas Unitarias Ing. Pablo Pytel 225 Diseño del Sistema de Información (Primer Ciclo)

226 A continuación se describen en detalle de los casos de prueba unitarios en las tablas PDSI 14 a PDSI 19. Código Objetivo Entrada CP-001 Calcular los costos estimados para un proyecto de tamaño pequeño. Proyecto de tamaño Pequeño. Los factores de costo utilizados son: NTAB = 0 NTUP = 1 NATR = 1 DISP = 1 PNUL = 1 DMOD = 0 DEXT = 2 NMOD = 2 TMOD = 1 MTUP = 1 MATRn = 1 MATRt = 2 MTEC = 1 NFUN = 2 SCOM = 1 TOOL = 2 COMP = 0 NFOR = 2 NDEP = 2 DOCU = 2 SITE = 1 KDAT = 1 ADIR = 1 MFAM = 1 Salida Condiciones Pre-requisitos Los valores estimados son: Fórmula de 23 factores de costo = 94,41 Fórmula de 8 factores de costo = 89,53 No posee No posee Procedimiento 1) Se ejecuta el sistema software. Ing. Pablo Pytel 226 Diseño del Sistema de Información (Primer Ciclo)

227 Código CP-001 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Pequeño Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla PDSI 14: Caso de Pruebas CP-001 Código Objetivo Entrada CP-002 Calcular los costos estimados para un proyecto de tamaño mediano. Proyecto de tamaño Mediano. Los factores de costo utilizados son: NTAB = 2 NTUP = 2 NATR = 2 DISP = 2 PNUL = 2 DMOD = 0 DEXT = 2 NMOD = 3 TMOD = 1 MTUP = 1 MATRn = 3 MATRt = 2 MTEC = 1 NFUN = 3 SCOM = 2 TOOL = 2 COMP = 0 NFOR = 2 NDEP = 2 DOCU = 2 SITE = 1 KDAT = 1 ADIR = 1 MFAM = 1 Ing. Pablo Pytel 227 Diseño del Sistema de Información (Primer Ciclo)

228 Código Salida Condiciones Pre-requisitos CP-002 Los valores estimados son: Fórmula de 23 factores de costo = 125,20 Fórmula de 8 factores de costo = 106,56 No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Mediano Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla PDSI 15: Caso de Pruebas CP-002 Código Objetivo Entrada CP-003 Calcular los costos estimados para un proyecto de tamaño grande. Proyecto de tamaño Grande. Los factores de costo utilizados son: NTAB = 5 NTUP = 4 NATR = 3 DISP = 4 PNUL = 4 DMOD = 3 DEXT = 4 NMOD = 4 TMOD = 1 MTUP = 4 MATRn = 4 MATRt = 4 MTEC = 3 NFUN = 4 SCOM = 4 TOOL = 4 COMP = 3 Ing. Pablo Pytel 228 Diseño del Sistema de Información (Primer Ciclo)

229 Código NFOR = 3 NDEP = 4 DOCU = 4 SITE = 4 KDAT = 3 ADIR = 1 MFAM = 1 CP-003 Salida Los valores estimados son: Fórmula de 23 factores de costo = 159,02 Fórmula de 8 factores de costo = 132,33 Condiciones Pre-requisitos No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla PDSI 16: Caso de Pruebas CP-003 Código Objetivo Entrada CP-004 Calcular los costos estimados para un proyecto de tamaño aleatorio (o sea, sin restricciones en los valores). Proyecto de tamaño Aleatorio. Los factores de costo utilizados son: NTAB = 1 NTUP = 2 NATR = 3 DISP = 3 PNUL = 4 DMOD = 1 DEXT = 2 NMOD = 4 TMOD = 1 Ing. Pablo Pytel 229 Diseño del Sistema de Información (Primer Ciclo)

230 Código MTUP = 1 MATRn = 4 MATRt = 4 MTEC = 1 NFUN = 2 SCOM = 4 TOOL = 4 COMP = 3 NFOR = 1 NDEP = 4 DOCU = 2 SITE = 4 KDAT = 1 ADIR = 4 MFAM = 5 CP-004 Salida Condiciones Pre-requisitos Los valores estimados son: Fórmula de 23 factores de costo = 104,13 Fórmula de 8 factores de costo = 107,22 No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla PDSI 17: Caso de Pruebas CP-004 Código Objetivo CP-005 Calcular los costos estimados para un proyecto de tamaño aleatorio variando sólo uno de los factores de costo que afecta ambas fórmulas. Ing. Pablo Pytel 230 Diseño del Sistema de Información (Primer Ciclo)

231 Código Entrada CP-005 Los factores de costo utilizados son los mismos del caso de prueba CP-004, salvo: NTAB = 3 Salida Condiciones Pre-requisitos Los valores estimados son: Fórmula de 23 factores de costo = 109,73 Fórmula de 8 factores de costo = 111,96 No posee Se acaba de ejecutar satisfactoriamente el caso de prueba CP-004. Procedimiento 1) Se modifica el valor del factor de costo NTAB utilizando el valor definido en <Entrada> 2) Se selecciona la opción Generar Proyectos Estimados. 3) Se ejecuta con el modo Calcular costo para un proyecto. 4) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla DSI 18: Caso de Pruebas CP-005 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-006 Calcular los costos estimados para un proyecto de tamaño aleatorio variando sólo uno de los factores de costo que afecta sólo a una de las fórmulas. Los factores de costo utilizados son los mismos del caso de prueba CP-004, salvo: SITE = 2 Los valores estimados son: Fórmula de 23 factores de costo = 105,46 Fórmula de 8 factores de costo = 111,96 No posee Se acaba de ejecutar satisfactoriamente el caso de prueba CP-005. Procedimiento 1) Se modifica el valor del factor de costo SITE utilizando el valor definido en <Entrada> 2) Se selecciona la opción Generar Proyectos Estimados. 3) Se ejecuta con el modo Calcular costo para un proyecto. 4) Se compara los resultados obtenidos con los valores definidos en <Salida>. Note que solamente se modifica el valor de la fórmula de 23 factores de costo, pero la fórmula de 8 factores de costo no varía. Tabla PDSI 19: Caso de Pruebas CP-006 Ing. Pablo Pytel 231 Diseño del Sistema de Información (Primer Ciclo)

232 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. Debido a la estructura y la funcionalidad brindada por el sistema software, estas pruebas fueron realizadas directamente junto con las pruebas del sistema Pruebas del Sistema Las pruebas de sistema tienen como objetivo probar la integración de los casos de uso implementados en el primer ciclo de desarrollo así como su integración con otros sistemas. Para poder verificar la interacción entre los casos de uso, se definieron pruebas donde a partir de ciertos parámetros se controlaba que la salida sea igual a la esperada luego de hacer funcionar varios casos de uso. Por otro lado, como en esta versión del sistema software no generaba ningún archivo de salida, las pruebas de integración con otros sistemas no fueron realizadas en este ciclo de desarrollo. En la tabla PDSI 20 se listan los casos de prueba del sistema que fueron realizados: Código Casos de Uso Objetivo CP-101 CP-102 CP-103 CP-104 CP-105 Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Generar un proyecto estimado de tamaño pequeño con factores de costo establecidos. Generar un proyecto estimado de tamaño pequeño con factores de costo aleatorios. Generar varios proyectos estimados de tamaño pequeño con factores de costo aleatorios. Generar un proyecto estimado de tamaño mediano con factores de costo establecidos. Generar un proyecto estimado de tamaño mediano con factores de costo aleatorios. Ing. Pablo Pytel 232 Diseño del Sistema de Información (Primer Ciclo)

233 Código Casos de Uso Objetivo CP-106 CP-107 CP-108 CP-109 CP-110 CP-111 Configurar Parámetros Generar Proyectos Estimados Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Generar varios proyectos estimados de tamaño mediano con factores de costo aleatorios. Generar un proyecto estimado de tamaño grande con factores de costo establecidos. Generar un proyecto estimado de tamaño grande con factores de costo aleatorios. Generar varios proyectos estimados de tamaño grande con factores de costo aleatorios. Generar un proyecto estimado de tamaño aleatorio con factores de costo establecidos. Generar un proyecto estimado de tamaño aleatorio con factores de costo aleatorios. CP-112 Configurar Parámetros Generar Proyectos Estimados Generar varios proyectos estimados de tamaño aleatorio con factores de costo aleatorios. Tabla PDSI 20: Caso de Pruebas del Sistema A continuación se describen los casos de prueba del sistema según el orden definidos en la tabla PDSI 20. Estos casos de pruebas se detallan en las tablas PDSI 21 a PDSI 32. Código Objetivo Entrada CP-101 Generar un proyecto estimado de tamaño pequeño con factores de costo establecidos. Proyecto de tamaño Pequeño. Los factores de costo utilizados son: NTAB = 0 NTUP = 1 NATR = 1 DISP = 1 PNUL = 1 DMOD = 0 Ing. Pablo Pytel 233 Diseño del Sistema de Información (Primer Ciclo)

234 Código DEXT = 2 NMOD = 2 TMOD = 1 MTUP = 1 MATRn = 1 MATRt = 2 MTEC = 1 NFUN = 2 SCOM = 1 TOOL = 2 COMP = 0 NFOR = 2 NDEP = 2 DOCU = 2 SITE = 1 KDAT = 1 ADIR = 1 MFAM = 1 CP-101 Salida Condiciones Pre-requisitos Los valores estimados son: Fórmula de 23 factores de costo = 94,41 Fórmula de 8 factores de costo = 89,53 Se muestran en pantalla los valores de costos estimados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Pequeño Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla PDSI 21: Caso de Pruebas CP-101 Código CP-102 Ing. Pablo Pytel 234 Diseño del Sistema de Información (Primer Ciclo)

235 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-102 Generar un proyecto estimado de tamaño pequeño con factores de costo aleatorios. Proyecto de tamaño Pequeño. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Pequeño Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se ven los resultados obtenidos. Tabla PDSI 22: Caso de Pruebas CP-102 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-103 Generar varios proyectos estimados de tamaño pequeño con factores de costo aleatorios. Proyecto de tamaño Pequeño. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Pequeño Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se decide parar el proceso. 5) Se ven los resultados obtenidos de los valores calculados. Tabla PDSI 23: Caso de Pruebas CP-103 Ing. Pablo Pytel 235 Diseño del Sistema de Información (Primer Ciclo)

236 Código Objetivo Entrada CP-104 Generar un proyecto estimado de tamaño mediano con factores de costo establecidos. Proyecto de tamaño Mediano. Los factores de costo utilizados son: NTAB = 2 NTUP = 2 NATR = 2 DISP = 2 PNUL = 2 DMOD = 0 DEXT = 2 NMOD = 3 TMOD = 1 MTUP = 1 MATRn = 3 MATRt = 2 MTEC = 1 NFUN = 3 SCOM = 2 TOOL = 2 COMP = 0 NFOR = 2 NDEP = 2 DOCU = 2 SITE = 1 KDAT = 1 ADIR = 1 MFAM = 1 Salida Condiciones Pre-requisitos Los valores estimados son: Fórmula de 23 factores de costo = 125,20 Fórmula de 8 factores de costo = 106,56 Se muestran en pantalla los valores de costos estimados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Mediano Ing. Pablo Pytel 236 Diseño del Sistema de Información (Primer Ciclo)

237 Código Generar los factores de costo al azar = No CP-104 Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla PDSI 24: Caso de Pruebas CP-104 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-105 Generar un proyecto estimado de tamaño mediano con factores de costo aleatorios. Proyecto de tamaño Mediano. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Mediano Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se ven los resultados obtenidos. Tabla PDSI 25: Caso de Pruebas CP-105 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-106 Generar varios proyectos estimados de tamaño mediano con factores de costo aleatorios. Proyecto de tamaño Mediano. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. No posee No posee Procedimiento Ing. Pablo Pytel 237 Diseño del Sistema de Información (Primer Ciclo)

238 Código CP-106 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Mediano Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se decide parar el proceso. 5) Se ven los resultados obtenidos Tabla PDSI 26: Caso de Pruebas CP-106 Código Objetivo Entrada CP-107 Generar un proyecto estimado de tamaño grande con factores de costo establecidos. Proyecto de tamaño Grande. Los factores de costo utilizados son: NTAB = 5 NTUP = 4 NATR = 3 DISP = 4 PNUL = 4 DMOD = 3 DEXT = 4 NMOD = 4 TMOD = 1 MTUP = 4 MATRn = 4 MATRt = 4 MTEC = 3 NFUN = 4 SCOM = 4 TOOL = 4 COMP = 3 NFOR = 3 NDEP = 4 DOCU = 4 SITE = 4 KDAT = 3 ADIR = 1 MFAM = 1 Ing. Pablo Pytel 238 Diseño del Sistema de Información (Primer Ciclo)

239 Código CP-107 Salida Condiciones Pre-requisitos Los valores estimados son: Fórmula de 23 factores de costo = 159,02 Fórmula de 8 factores de costo = 132,33 No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla PDSI 27: Caso de Pruebas CP-107 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-108 Generar un proyecto estimado de tamaño grande con factores de costo aleatorios. Proyecto de tamaño Grande. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se ven los resultados obtenidos. Tabla PDSI 28: Caso de Pruebas CP-108 Ing. Pablo Pytel 239 Diseño del Sistema de Información (Primer Ciclo)

240 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-109 Generar varios proyectos estimados de tamaño grande con factores de costo aleatorios. Proyecto de tamaño Grande. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se decide parar el proceso. 5) Se ven los resultados obtenidos. Tabla PDSI 29: Caso de Pruebas CP-109 Código Objetivo Entrada CP-110 Generar un proyecto estimado de tamaño aleatorio con factores de costo establecidos. Proyecto de tamaño Aleatorio. Los factores de costo utilizados son: NTAB = 1 NTUP = 2 NATR = 3 DISP = 3 PNUL = 4 DMOD = 1 DEXT = 2 NMOD = 4 TMOD = 1 MTUP = 1 MATRn = 4 MATRt = 4 MTEC = 1 NFUN = 2 SCOM = 4 Ing. Pablo Pytel 240 Diseño del Sistema de Información (Primer Ciclo)

241 Código TOOL = 4 COMP = 3 NFOR = 1 NDEP = 4 DOCU = 2 SITE = 4 KDAT = 1 ADIR = 4 MFAM = 5 CP-110 Salida Condiciones Pre-requisitos Los valores estimados son: Fórmula de 23 factores de costo = 104,13 Fórmula de 8 factores de costo = 107,22 No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla PDSI 30: Caso de Pruebas CP-110 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-111 Generar un proyecto estimado de tamaño aleatorio con factores de costo aleatorios. Proyecto de tamaño Aleatorio. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. No posee No posee Procedimiento 1) Se ejecuta el sistema software. Ing. Pablo Pytel 241 Diseño del Sistema de Información (Primer Ciclo)

242 Código CP-111 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se ven los resultados obtenidos. Tabla PDSI 31: Caso de Pruebas CP-111 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-112 Generar varios proyectos estimados de tamaño aleatorio con factores de costo aleatorios. Proyecto de tamaño Aleatorio. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se decide parar el proceso. 5) Se ven los resultados obtenidos. Tabla PDSI 32: Caso de Pruebas CP APROBACIÓN DEL DISEÑO DEL SISTEMA DE INFORMACIÓN En esta tarea, el Comité de Dirección decide la aprobación formal o no del Diseño del Sistema de Información luego de que este es presentado. Ing. Pablo Pytel 242 Diseño del Sistema de Información (Primer Ciclo)

243 PRESENTACIÓN Y APROBACIÓN DEL DISEÑO DEL SISTEMA DE INFORMACIÓN CORRESPONDIENTE AL PRIMER CICLO DE DESARROLLO Luego de realizar una reunión mantenida entre el tesista y los Directores del Proyecto de Tesis, se dio como válida a la fase de Diseño para el primer ciclo de desarrollo y se consideró aprobada la misma para continuar con las actividades correspondientes a la construcción del sistema software. Ing. Pablo Pytel 243 Diseño del Sistema de Información (Primer Ciclo)

244

245 CAPÍTULO 7 PRIMER CICLO DE DESARROLLO: CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN

246

247 7. PRIMER CICLO DE DESARROLLO: CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN 7.1. INTRODUCCIÓN El objetivo del proceso de Construcción del Sistema de Información (CSI) es generar el código de los componentes del sistema software, desarrollando todos los procedimientos de operación y seguridad y se elaborando los manuales de usuario final y de explotación para así asegurar el correcto funcionamiento del sistema software en su posterior implantación. Al ser utilizada la metodología Métrica Versión III que cubre tanto desarrollos estructurados como orientados a objetos, las actividades de ambas aproximaciones están integradas en una estructura común. Para poder conseguir este objetivo, durante este proceso se realizan las pruebas unitarias, las pruebas de integración y las pruebas del sistema, de acuerdo al plan de pruebas establecido anteriormente. Además, se define cómo se realiza la formación de los usuarios finales y, si procede, se construyen los procedimientos de migración y carga inicial de datos. Este proceso se basa en el producto resultante de la fase Especificaciones de Construcción del Sistema de Información, obtenida en la actividad de Generación de Especificaciones de Construcción del proceso de Diseño del Sistema de Información (DSI). 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. Durante 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 software. Una vez configurado el entorno de construcción, se realizan las actividades: Generación del Código de los Componentes y Procedimientos, que se realiza según las especificaciones de Construcción del Sistema de Información y conforme al plan de integración del sistema software. 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. Ing. Pablo Pytel 247 Construcción del Sistema de Información (Primer Ciclo)

248 Una vez que se ha construido el sistema software y se han realizado satisfactoriamente las verificaciones unitarias y de integración, se lleva a cabo la integración final del sistema software en la actividad Ejecución de las Pruebas del Sistema. Durante esta actividad se comprueba las interfaces entre subsistemas y los sistemas externos como los requisitos, de acuerdo a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema. Por último, en caso de que sea necesario 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 definen 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 Esta actividad tiene el objetivo de asegurar la disponibilidad de todos los medios, recursos y facilidades para que se pueda llevar a cabo la construcción del sistema de información. Entre estos medios se pueden 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. En la actividad Generación de Especificaciones de Construcción se establecen 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 para ser el punto de partida de la realización de esta actividad IMPLANTACIÓN DE LA BASE DE DATOS FÍSICA O FICHEROS Para este sistema software no se utiliza base de datos, por lo tanto esta tarea no fue realizada en el presente proyecto, quedando pendiente para futuras modificaciones del sistema software (no contempladas en este trabajo). Por otro lado, durante el segundo ciclo de desarrollo fue agregada la funcionalidad para almacenar los resultados en archivos que se ubican en la carpeta de trabajo del sistema software. El soporte de estos archivos está dado por el mismo sistema operativo donde se ejecuta el sistema software. Ing. Pablo Pytel 248 Construcción del Sistema de Información (Primer Ciclo)

249 PREPARACIÓN DEL ENTORNO DE CONSTRUCCIÓN Esta tarea tiene el objetivo de preparar el entorno en el que se construirán los componentes del sistema software, incluyendo los siguientes aspectos: 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 la construcción de presente sistema software, fue instalado el entorno de trabajo de Easy Java Simulations (EJS) versión junto con el Java Runtime Enviroment. Para esto fueron consultados los manuales de instalación de los productos GENERACIÓN DEL CÓDIGO DE LOS COMPONENTES Y PROCEDIMIENTOS Esta actividad tiene el objetivo de realizar la codificación de los componentes del sistema software, a partir de las especificaciones de construcción obtenidas en el proceso Diseño del Sistema de Información (DSI), así como la construcción de los procedimientos de operación y seguridad establecidos para el mismo. Esta actividad se realiza en paralelo con las actividades relacionadas con las pruebas unitarias y de integración del sistema software. Esto permite una 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 software GENERACIÓN DEL CÓDIGO DE COMPONENTES Esta tarea tiene el objetivo de generar el código correspondiente a cada uno de los componentes del sistema software, identificados en la tarea Definición de Componentes y Subsistemas de Construcción. Por último, para 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. Ing. Pablo Pytel 249 Construcción del Sistema de Información (Primer Ciclo)

250 GENERACIÓN DEL CÓDIGO DE LOS PROCEDIMIENTOS DE OPERACIÓN Y SEGURIDAD Esta tarea tiene el objetivo de generar los procedimientos de operación y administración del sistema software, 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 Esta tarea no fue realizada en este sistema software al no existir requerimientos relativos a la validación de usuarios ni utilizar base de datos para almacenar dicha información EJECUCIÓN DE LAS PRUEBAS UNITARIAS Esta actividad tiene el objetivo de realizar las pruebas unitarias de cada uno de los componentes del sistema software a medida que son codificados, con el objeto de comprobar que su estructura es correcta y que se ajustan a la funcionalidad establecida. Para ello se utiliza el entorno para la realización de cada nivel de prueba, 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. Toda esta información se encuentra definida en el plan de pruebas REALIZACIÓN Y EVALUACIÓN DE LAS PRUEBAS UNITARIAS Esta tarea tiene el objetivo de comprobar el correcto funcionamiento de los componentes del sistema software, conforme son codificados en la actividad Generación del Código de los Componentes y Procedimientos y utilizando las verificaciones ya establecidas en el plan de pruebas para el nivel de pruebas unitarias. 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. Luego, se analizan los resultados de las pruebas unitarias, evaluándose las mismas para comprobar que los resultados son los esperados. En caso de que los resultados no son los esperados, se procede a realizar las correcciones pertinentes. Ing. Pablo Pytel 250 Construcción del Sistema de Información (Primer Ciclo)

251 Resultado de la Realización de las Pruebas Unitarias Luego de realizar las pruebas unitarias con tres iteraciones de corrección a los componentes se detalla su resultado final en la tabla PCSI 1. El detalle de los problemas encontrados durante estas pruebas se encuentra en el Apéndice D. Código CP-001 CP-002 CP-003 CP-004 CP-005 Componente (Caso de Uso) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) Resultado Exitosa Exitosa Exitosa Exitosa Exitosa CalcCostosEstimados CP-006 Exitosa (Generar los Proyectos Estimados) Tabla PCSI 1: Resultado de la ejecución de los casos de prueba unitarios 7.5. EJECUCIÓN DE LAS PRUEBAS DE INTEGRACIÓN Esta actividad tiene como objetivo comprobar la integración interna del sistema software buscando encontrar fallas en el funcionamiento de los componentes y subsistemas del sistema, al funcionar en conjunto para proveer la funcionalidad deseada. Sin embargo, en este proyecto, debido a la estructura y la funcionalidad brindada por el sistema software desarrollado, estas pruebas fueron realizadas directamente junto con las pruebas del sistema EJECUCIÓN DE LAS PRUEBAS DEL SISTEMA Esta actividad tiene como objetivo comprobar la integración del sistema software 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. Ing. Pablo Pytel 251 Construcción del Sistema de Información (Primer Ciclo)

252 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 (actividades que se llevan a cabo en el proceso Implantación y Aceptación del Sistema) REALIZACIÓN DE LAS PRUEBAS DEL SISTEMA Esta tarea tiene el objetivo de comprobar la integración de todos los subsistemas y componentes del sistema software, 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 Luego de realizar las pruebas del sistema con cuatro iteraciones de corrección a los componentes se detalla su resultado final en la tabla PCSI 2. El detalle de los problemas encontrados durante estas pruebas se encuentra en el Apéndice D. Código Casos de Uso Resultado Configurar Parámetros CP-101 Configurar Factores de Costo del Proyecto Exitosa Generar Proyectos Estimados CP-102 Configurar Parámetros Generar Proyectos Estimados Exitosa CP-103 Configurar Parámetros Generar Proyectos Estimados Exitosa Configurar Parámetros CP-104 Configurar Factores de Costo del Proyecto Exitosa Generar Proyectos Estimados CP-105 Configurar Parámetros Generar Proyectos Estimados Exitosa CP-106 Configurar Parámetros Generar Proyectos Estimados Exitosa Configurar Parámetros CP-107 Configurar Factores de Costo del Proyecto Exitosa Generar Proyectos Estimados Ing. Pablo Pytel 252 Construcción del Sistema de Información (Primer Ciclo)

253 Código Casos de Uso Resultado CP-108 Configurar Parámetros Generar Proyectos Estimados Exitosa CP-109 Configurar Parámetros Generar Proyectos Estimados Exitosa Configurar Parámetros CP-110 Configurar Factores de Costo del Proyecto Exitosa Generar Proyectos Estimados CP-111 Configurar Parámetros Generar Proyectos Estimados Exitosa CP-112 Configurar Parámetros Generar Proyectos Estimados Exitosa Tabla PCSI 2: Resultado de la ejecución de los casos de prueba de sistema EVALUACIÓN DEL RESULTADO DE LAS PRUEBAS DEL SISTEMA Esta actividad tiene el objetivo de analizar los resultados de las pruebas del sistema software y efectuar su evaluación. Para poder realizar esta evaluación se debe establecer el grado de cumplimiento de las mismas Evaluación de los Resultados de las Pruebas de Sistema Luego de haber analizados los resultados de los casos de prueba para el sistema indicado en la tabla PCSI 2 se puede indicar que el sistema ha alcanzado los niveles de calidad deseados, dado que todas las salidas se encuentran dentro de los parámetros de valores esperados APROBACIÓN DEL SISTEMA SOFTWARE CORRESPONDIENTE AL PRIMER CICLO DE DESARROLLO En esta tarea, se recopilan los productos del sistema software y se presentan al Comité de Seguimiento para su aprobación. Luego de realizar una reunión mantenida entre el tesista y los Directores del Proyecto de Tesis, se dio como aprobada la fase de Construcción del primer ciclo de desarrollo y se pudo continuar con las actividades correspondientes al segundo ciclo de desarrollo. Ing. Pablo Pytel 253 Construcción del Sistema de Información (Primer Ciclo)

254

255 CAPÍTULO 8 SEGUNDO CICLO DE DESARROLLO: ANÁLISIS DEL SISTEMA DE INFORMACIÓN

256

257 8. SEGUNDO CICLO DE DESARROLLO: ANÁLISIS DEL SISTEMA DE INFORMACIÓN 8.1 INTRODUCCIÓN El proceso de Análisis del Sistema de Información (ASI) se volvió a realizar en el segundo ciclo de desarrollo considerando tanto los modelos generados durante las actividades de análisis del primer ciclo de desarrollo como los requerimientos que no se habían considerado en ese ciclo. Por lo tanto, a los modelos creados durante el Análisis del Sistema de Información en el primer ciclo de desarrollo (capítulo 5 de este trabajo) se les incluyeron elementos nuevos y/o modificaciones para que satisfagan todas las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema. Se debe considerar que durante este segundo ciclo de desarrollo no fue necesario realizar las actividades de Definición del Sistema y Especificación del Plan de Pruebas ya que no fueron afectadas por los requerimientos del segundo ciclo de desarrollo. 8.2 ESTABLECIMIENTO DE REQUISITOS Esta actividad tiene el objetivo de realizar la definición, análisis y validación de los requisitos que forman parte del segundo ciclo de desarrollo, a partir de la información provista por el usuario. Así se logra completar los requisitos obtenido en la actividad Definición del Sistema y obtener requisitos detallados. A través de los mismos se puede comprobar que los productos generados en las actividades de modelización se ajustan a los requisitos solicitados por los usuarios. Esta actividad incluye un conjunto de tareas que, si bien poseen un orden preestablecido, necesitan de continuas realimentaciones y solapamientos entre sí y con otras tareas realizadas en paralelo. Esto significa que no es necesario finalizar una tarea para el comienzo de la siguiente. Así se logran requisitos establecido en función de la progresión del proceso de análisis. La especificación de los casos de uso de la orientación a objetos es propuesta como técnica de obtención de requisitos 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. Ing. Pablo Pytel 257 Análisis del Sistema de Información (Segundo Ciclo)

258 8.2.1 ESPECIFICACIÓN DE CASOS DE USO El objetivo de esta actividad es especificar cada caso de uso considerando los requerimientos del segundo ciclo de desarrollo y definiendo el escenario correspondiente como se ha explicado durante el primer ciclo de desarrollo Casos de Uso Dado que se utilizó el ciclo de vida incremental, a los casos de uso previamente definidos en primer ciclo de desarrollo (sección ) se les incluyeron las modificaciones y casos de usos nuevos para cumplir los requerimientos del segundo ciclo (los cuales fueron definidos en la sección ). En la figura SASI 1 se muestra el diagrama de casos de uso del sistema software: Figura SASI 1: Diagrama de Casos de Uso Se recuerda que en este diagrama se utiliza la siguiente simbología para las flechas: - Las flechas con punta blanca sin estereotipo indican que entre ambos casos de uso existe una relación de Inclusión. - Las fechas con punta negra sin estereotipo indican que existen una relación de uso entre los participantes. Para cada uno de los casos de uso representados en la figura SASI 1, a continuación se definen sus detalles en las tablas SASI 1 a SASI 5. Nótese que para mayor claridad fue incluido también el caso de uso Configurar Factores de Costo del Proyecto definido en el primer ciclo pero que no fue afectado por los requerimientos del segundo ciclo. Ing. Pablo Pytel 258 Análisis del Sistema de Información (Segundo Ciclo)

259 Nombre del Caso de Uso Descripción del Caso de Uso Actores Pre-condiciones Post-condiciones Configurar Parámetros Se definen los parámetros para ser utilizado al momento de generar las características de los proyectos de explotación de información. Usuario - El sistema está ejecutándose. - Se determina el tamaño del proyecto a utilizar como parámetro. - Se determina si todos los valores son generados aleatoriamente o no (en cuyo se debe definir los valores específicos a utilizar). Flujo de Eventos Activación Requisitos especiales Puntos de extensión El usuario selecciona la opción Configuración de Proyectos. No posee No posee Flujo Principal 1) El usuario selecciona la opción Configuración de Proyectos. 2) El sistema solicita al usuario seleccionar el tamaño del proyecto a utilizar como parámetro de la siguiente lista: - Proyectos Pequeños. - Proyectos Medianos. - Proyectos Grandes. - Proyectos Aleatorios. 3) El usuario selecciona el tamaño del proyecto de la lista. 4) El sistema pregunta si se desea generar todos los valores de los factores de costo en forma aleatoria. 5) El usuario indica que desea generar todos los factores en forma aleatoria. 6) El sistema define el/los posible/s valore/s que puede tener cada uno de los factores de costo considerando el tamaño de proyecto seleccionado. 7) El sistema pregunta si desea exportar los Ing. Pablo Pytel 259 Análisis del Sistema de Información (Segundo Ciclo)

260 datos de los proyectos generados y estimados. 8) El usuario indica que no desea exportar los datos de los proyectos generados y estimados. 9) Fin del caso de uso. Flujos Alternativos Alternativa al paso 3 El usuario no selecciona un tamaño de proyecto. a) El sistema utiliza la opción Proyectos Aleatorios (ya que es el valor por defecto). b) El sistema continúa en el paso 4 del flujo principal. Ing. Pablo Pytel 260 Análisis del Sistema de Información (Segundo Ciclo)

261 Alternativa al paso 5 El usuario indica que no desea generar todos los valores de los factores de costo en forma aleatoria. a) El sistema solicita al caso de uso Configurar Factores de Costo del Proyecto la configuración de cada uno de los factores de costo. b) El sistema continúa en el paso 7 del flujo principal. Alternativa al paso 8 El usuario indica que desea exportar los datos de los proyectos generados y estimados. a) El sistema solicita al caso de uso Configurar Archivo de Exportación los datos del archivo a generar. b) Fin del caso de uso. Tabla SASI 1: Descripción del caso de uso Configurar Parámetros Ing. Pablo Pytel 261 Análisis del Sistema de Información (Segundo Ciclo)

262 Nombre del Caso de Uso Descripción del Caso de Uso Actores Pre-condiciones Post-condiciones Configurar Factores de Costo del Proyecto Se definen para cada uno de los factores de costo del proyecto un valor específico a utilizar o si se desea utilizar un valor generado al azar. Usuario - El sistema está ejecutándose. - Se está realizando la configuración de los proyectos a generar y ya se ha seleccionado el tamaño del proyecto a utilizar. - Para cada uno de los factores de costo se determina un valor específico o un rango de valores asociados al tamaño del proyecto que se generarán al azar. Flujo de Eventos Activación Requisitos especiales Puntos de extensión El usuario indica no generar aleatoriamente todos los factores de costo en la opción Configuración de Proyectos. No posee No posee Flujo Principal 1) El sistema muestra la lista con los 23 factores de costo del método DMCoMo para configurar, o la opción para finalizar la configuración de los factores de costo. 2) El usuario selecciona el factor de costo a configurar. 3) El sistema solicita el valor del factor de costo. 4) El usuario ingresa el valor del factor de costo. 5) El sistema vuelve al paso 2 para que el usuario pueda configurar otro factor de costo. Flujos Alternativos Ing. Pablo Pytel 262 Análisis del Sistema de Información (Segundo Ciclo)

263 Alternativa al paso 2 El usuario selecciona finalizar la configuración de los factores de costo. a) El sistema determina, para cada uno de los factores de costo no configurados por el usuario, el/los posible/s valore/s que puede tener para el factor de costo de costo considerando el tamaño de proyecto ya seleccionado. b) El sistema le envía los valores y opciones de los factores de costo configurados al caso de uso llamante. c) Fin del caso de uso. Alternativa al paso 4 El usuario selecciona que se genere los valores del factor de costo al azar. a) El sistema define el/los posible/s valore/s que puede tener para el factor de costo de costo considerando el tamaño de proyecto ya seleccionado. b) El sistema vuelve al paso 2 del flujo principal para que el usuario pueda configurar otro factor de costo. Ing. Pablo Pytel 263 Análisis del Sistema de Información (Segundo Ciclo)

264 Alternativa al paso 4 El usuario no ingresa un valor permitido para el factor de costo. a) El sistema muestra un mensaje de error. b) El sistema vuelve al paso 4 del flujo principal para que el usuario ingrese un nuevo valor. Tabla SASI 2: Descripción del caso de uso Configurar Factores de Costo del Proyecto Nombre del Caso de Uso Descripción del Caso de Uso Actores Pre-condiciones Post-condiciones Configurar Archivo de Exportación Se define el nombre del archivo que será utilizado para exportar los datos de los proyectos generados y estimados. Usuario - El sistema está ejecutándose. - Los parámetros ya fueron configurados en el caso de uso Configurar Parámetros. - Se determina el nombre del archivo que será utilizado para exportar los datos de los proyectos generados y estimados. Flujo de Eventos Activación Requisitos especiales Puntos de extensión El usuario indica que desea exportar los datos de los proyectos generados y estimados. No posee No posee Ing. Pablo Pytel 264 Análisis del Sistema de Información (Segundo Ciclo)

265 Flujo Principal 1) El sistema solicita al usuario que indique el nombre del archivo para exportar. 2) El usuario ingresa el nombre del archivo. 3) El sistema verifica que el archivo no exista. 4) El archivo crea el archivo vacío para comenzar la exportación. 5) Fin del caso de uso. Flujos Alternativos Alternativa al paso 2 El usuario no ingresa el nombre del archivo por defecto. a) El sistema utiliza el nombre de archivo por defecto ( data.csv ). b) El sistema continúa en el paso 3 del flujo principal. Ing. Pablo Pytel 265 Análisis del Sistema de Información (Segundo Ciclo)

266 Alternativo al paso 3 El sistema detecta que el archivo ya existe y el usuario selecciona sobrescribirlo. a) El sistema pregunta al usuario si desea sobrescribir el archivo existente. b) El usuario selecciona sobrescribir el archivo existente. c) El sistema continúa en el paso 4 del flujo principal. Alternativo al paso 3 El sistema detecta que el archivo ya existe y el usuario selecciona no sobrescribirlo. a) El sistema pregunta al usuario si desea sobrescribir el archivo existente. b) El usuario selecciona no sobrescribir el archivo existente. c) El sistema vuelve al paso 1 para que el usuario ingrese un nuevo nombre de archivo. Tabla SASI 3: Descripción del caso de uso Configurar Archivo de Exportación Nombre del Caso de Uso Descripción del Caso de Uso Actores Pre-condiciones Generar Proyectos Estimados Se generan los proyectos de explotación de información con sus factores de costo y sus correspondientes estimaciones al aplicar las dos fórmulas del método DMCoMo. Usuario - El sistema está ejecutándose. - Los parámetros ya fueron configurados en el caso de uso Configurar Parámetros. Ing. Pablo Pytel 266 Análisis del Sistema de Información (Segundo Ciclo)

267 Post-condiciones - Se obtiene los factores de costo con sus correspondientes estimaciones al aplicar las dos fórmulas del método DMCoMo para uno o más proyectos de explotación de información. Flujo de Eventos Activación Requisitos especiales Puntos de extensión El usuario selecciona la opción Generar Proyectos Estimados. No posee No posee Flujo Principal 1) El usuario selecciona la opción Generar Proyectos Estimados. 2) El sistema solicita el modo de generación de los proyectos estimados a partir de las siguientes opciones: - Calcular costo para un proyecto. - Evaluación continua de proyectos. - Análisis completo para todas las posibilidades. 3) El usuario selecciona el modo Calcular costo para un proyecto. 4) El sistema define los valores de los factores de costo para un proyecto a evaluar de acuerdo a la configuración realizada. 5) El sistema calcula los valores de la estimación para los valores de los factores de costo del proyecto a evaluar (determinados en el paso anterior). 6) El sistema exporta los datos generados en los pasos anteriores en el archivo de exportación utilizando el formato correspondiente (si fue configurado el archivo de exportación). 7) El sistema muestra en pantalla los valores de estimación calculados en el paso anterior. También con estos valores se muestra un gráfico con el histograma de la estimación calculada para cada una de las fórmulas de Ing. Pablo Pytel 267 Análisis del Sistema de Información (Segundo Ciclo)

268 estimación. 8) Fin del caso de uso. Flujos Alternativos Alternativa al paso 2 El sistema detecta que el tamaño del proyecto seleccionado es Proyectos Aleatorios a) El sistema solamente muestra como modos de generación las siguientes opciones: - Calcular costo para un proyecto. - Evaluación continua de proyectos. Nota: esto se debe a que no es posible generar todas las combinaciones posibles para proyectos generados aleatoriamente. b) El sistema continúa en el paso 3 del flujo principal. Alternativa al paso 3 El usuario selecciona el modo Evaluación continua de proyectos. a) El sistema define los valores de los factores de costo para un proyecto a evaluar de acuerdo a la configuración realizada. b) El sistema calcula los valores de la estimación para los valores de los factores de costo del proyecto a evaluar (determinados en el paso anterior). c) El sistema exporta los datos generados en los pasos anteriores en el archivo de exportación utilizando el formato correspondiente (si fue configurado el archivo de exportación). d) El sistema calcula la media estadística para cada uno de los valores de estimación calculados en el paso b). e) El sistema muestra en pantalla los valores de estimación calculados en el paso b) y la media estadística calculada en el paso c). También con estos valores se muestra un Ing. Pablo Pytel 268 Análisis del Sistema de Información (Segundo Ciclo)

269 gráfico con el histograma de la estimación calculada en el paso b) para cada una de las fórmulas de estimación. f) El sistema vuelve a ejecutar este flujo alternativo desde el paso a) hasta que el usuario seleccione finalizar la evaluación continua. Alternativa al paso 3 El usuario selecciona el modo Análisis completo para todas las posibilidades. a) El sistema define los valores de los factores de costo para un proyecto a evaluar de acuerdo a la configuración realizada. b) El sistema calcula los valores de la estimación para los valores de los factores de costo del proyecto a evaluar (determinados en el paso anterior). c) El sistema exporta los datos generados en los pasos anteriores en el archivo de exportación utilizando el formato correspondiente (si fue configurado el archivo de exportación). d) El sistema calcula la media estadística para cada uno de los valores de estimación calculados en el paso b). e) El sistema muestra en pantalla los valores de estimación calculados en el paso b) y la media estadística calculada en el paso c). También con estos valores se muestra un gráfico con el histograma de la estimación calculada en el paso b) para cada una de las fórmulas de estimación. f) El sistema vuelve a ejecutar este flujo alternativo desde el paso a) hasta que se generan todas las combinaciones posibles de los factores de costo. Tabla SASI 4: Descripción del caso de uso Generar Proyectos Estimados Ing. Pablo Pytel 269 Análisis del Sistema de Información (Segundo Ciclo)

270 Nombre del Caso de Uso Descripción del Caso de Uso Actores Pre-condiciones Post-condiciones Mostrar Resultados de Proyectos Estimados Se muestran los detalles de los resultados generados para los proyectos estimados Usuario - El sistema está ejecutándose. - Los proyectos estimados ya fueron generados en el caso de uso Generar Proyectos Estimados. - Se muestran los resultados generados para los proyectos estimados a través de gráficos con la frecuencia de ocurrencia de los valores generados o una tabla detallando con todos estos valores. Flujo de Eventos Activación Requisitos especiales Puntos de extensión El usuario selecciona la opción Mostrar Resultados. No posee No posee Flujo Principal 1) El usuario selecciona la opción Mostrar Resultados. 2) El sistema muestra la lista de opciones que incluye: los 23 factores de costo del método DMCoMo, los dos valores de costo estimados calculados por las fórmulas del método DMCoMo y la tabla de valores detallados. 3) El usuario selecciona ver un factor de costo específico. 4) El sistema muestra un gráfico de barras con la frecuencia de ocurrencia de los valores generados para este factor de costo. 5) Fin del caso de uso. Flujos Alternativos Ing. Pablo Pytel 270 Análisis del Sistema de Información (Segundo Ciclo)

271 Alternativa al paso 2 El usuario selecciona mostrar los valores de costo estimados a) El sistema muestra dos gráficos de barras con la frecuencia de ocurrencia de los valores estimados calculados por cada una de las fórmulas para los proyectos generados y procesados. b) Fin del caso de uso. Alternativa al paso 2 El usuario selecciona mostrar la tabla de valores detallados a) El sistema muestra una tabla mostrando para cada uno de los proyectos generados y procesados, cada uno de los valores de los factores de costo utilizados y los dos valores estimados por DMCoMo b) Fin del caso de uso. Tabla SASI 5: Descripción del caso de uso Mostrar Resultados de Proyectos Estimados 8.3 ANÁLISIS DE LOS CASOS DE USO Esta actividad, que se realizó nuevamente en el segundo ciclo de desarrollo, tiene el objetivo de identificar las clases cuyos objetos son necesarios para realizar un caso de uso y describir su comportamiento mediante la interacción entre dichos objetos IDENTIFICACIÓN DE CLASES ASOCIADAS A UN CASO DE USO Esta tarea comienza a analizar la especificación de los casos de uso, identificados en el punto anterior para el segundo ciclo de desarrollo, definiendo los objetos necesarios para Ing. Pablo Pytel 271 Análisis del Sistema de Información (Segundo Ciclo)

272 realizar cada uno. Una vez definidas cada una de las clases, se incorporan al modelo de clases de la actividad Análisis de Clases de los siguientes tipos: Clases de Entidad, las cuales representan la información manipulada en el caso de uso. Clases de Control, las cuales son responsables de la coordinación, secuencia de transacciones y control de los objetos relacionados con un caso de uso. Clases de Interfaz de Usuario, las cuales se utilizan para describir la interacción entre el sistema y sus actores y que suelen representar abstracciones de ventanas, interfaces de comunicación, formularios, etc Identificación de Clases En esta sección se desarrollan los diagramas de clase correspondientes a cada uno de los casos de uso del segundo ciclo de desarrollo identificados en la sección Los diagramas de clases se muestran en las figuras de SASI 2 a SASI 6. Como se puede ver, en este segundo ciclo, se agregaron los nuevos diagramas de las figuras SASI 4 (caso de uso Configurar Archivo de Exportación ) y SASI 6 (caso de uso Mostrar Resultados de Proyectos Estimados ), y se realizaron cambios al diagrama de la figura SASI 5 (caso de uso Generar Proyectos Estimados ). Figura SASI 2: Diagrama de Clases para el caso de uso Configurar Parámetros Ing. Pablo Pytel 272 Análisis del Sistema de Información (Segundo Ciclo)

273 Figura SASI 3: Diagrama de Clases para el caso de uso Configurar Factores de Costo del Proyecto Figura SASI 4: Diagrama de Clases para el caso de uso Configurar Archivo de Exportación Ing. Pablo Pytel 273 Análisis del Sistema de Información (Segundo Ciclo)

274 Figura SASI 5: Diagrama de Clases para el caso de uso Generar Proyectos Estimados Figura SASI 6: Diagrama de Clases para el caso de uso Mostrar Resultados de Proyectos Estimados Al igual que en el primer ciclo de desarrollo, para estos diagramas se utiliza la simbología definida en la figura SASI 7 para estereotipar las clases. Figura SASI 7: Estereotipos de Clases Ing. Pablo Pytel 274 Análisis del Sistema de Información (Segundo Ciclo)

275 8.3.2 DESCRIPCIÓN DE LA INTERACCIÓN DE OBJETOS Esta tarea tiene como objetivo describir la cooperación entre los objetos, identificados en el punto anterior, que son utilizados para la realización de los casos de uso del segundo ciclo de desarrollo. Para representarlo se usan diagramas de interacción que contienen instancias de los actores participantes, objetos, y la secuencia de mensajes intercambiados entre ellos Identificación de la Interacción de Objetos En esta sección se desarrollan los diagramas de colaboración de objetos correspondientes a cada uno de los casos de uso identificados del segundo ciclo de desarrollo, donde se vinculan las clases identificadas en la sección Esta vinculación se encuentra relacionada con la participación de los objetos dentro de los casos de uso. Los diagramas de clases se muestran en las figuras de SASI 8 a SASI 12. En los cuales se mantiene la simbología de los estereotipos de clases utilizadas en la sección anterior. Figura SASI 8: Diagrama de Interacción para el caso de uso Configurar Parámetros Ing. Pablo Pytel 275 Análisis del Sistema de Información (Segundo Ciclo)

276 Figura SASI 9: Diagrama de Interacción para el caso de uso Configurar Factores de Costo del Proyecto Figura SASI 10: Diagrama de Interacción para el caso de uso Configurar Archivo de Exportación Ing. Pablo Pytel 276 Análisis del Sistema de Información (Segundo Ciclo)

277 Figura SASI 11: Diagrama de Interacción para el caso de uso Generar Proyectos Estimados Figura SASI 12: Diagrama de Interacción para el caso de uso Mostrar Resultados de Proyectos Estimados 8.4 ANÁLISIS DE CLASES Esta actividad, que se vuelve a realizar en el segundo ciclo de desarrollo, tiene el objetivo de describir cada una de las clases que han identificado incluyendo también las responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas IDENTIFICACIÓN DE RESPONSABILIDADES Y ATRIBUTOS Esta tarea se ocupa de identificar las responsabilidades y atributos relevantes de una clase: Las responsabilidades de una clase indican la funcionalidad de esa clase. Ing. Pablo Pytel 277 Análisis del Sistema de Información (Segundo Ciclo)

278 Los atributos de una clase indican las propiedades de la clase. Las operaciones que provee cada clase. De esta forma se terminó de completar la tabla correspondiente que fue creada en el primer ciclo de desarrollo con las nuevas clases definidas durante el segundo ciclo Definición de Responsabilidades y Atributos En la siguiente tabla SASI 6 se detallan las clases identificadas en la sección junto con su tipo, responsabilidades y atributos. Clase Tipo Responsabilidades Atributos Interfaz de Pantalla Principal Interfaz de Configurar Parámetros Interfaz de Configurar Factores de Costos Interfaz de Configurar Archivo de Exportación Interfaz de Generar Proyectos Estimados Interfaz Interfaz Interfaz Interfaz Interfaz Establece la pantalla que se utiliza para comunicarse con el usuario para realizar las actividades principales Establece la pantalla que se utiliza para seleccionar los parámetros a ser utilizados cuando se generen los proyectos estimados. Establece la pantalla que se utiliza para definir si se desea utilizar un valor específico o un valor al azar a cada uno de los factores de costo. Establece la pantalla que se utiliza para definir el archivo que será utilizado para exportar los datos generados y estimados. Establece la pantalla que se utiliza para generar los proyectos estimados. Menú principal con las opciones a utilizar. Control para seleccionar el Tamaño del Proyecto. Control para indicar si se desea generar todos los valores de los factores de costo en forma aleatoria o no. Control para definir el valor del factor de costo a utilizar (opcional) Control para indicar que se desea generar al azar. Control para definir el nombre del archivo a generar. Control para seleccionar el modo de generación. Controles para mostrar últimos valores de estimación calculados por las dos fórmulas. Controles para mostrar la media estadística de los valores de estimación calculados. Gráficos con el histograma de las estimaciones calculadas. Ing. Pablo Pytel 278 Análisis del Sistema de Información (Segundo Ciclo)

279 Clase Tipo Responsabilidades Atributos Interfaz de Mostrar Resultados Asistente para Configurar Parámetros Asistente para Configurar Factores de Costo Interfaz Control Control Establece la pantalla que se utiliza para mostrar los resultados de los proyectos generados y estimados. Coordina los pasos que se deben realizar para configurar los parámetros a ser utilizados cuando se generen los proyectos estimados. Coordina los pasos que se deben realizar para para definir si se desea utilizar un valor específico o un valor al azar a cada uno de los factores de costo. Gráficos de barras con la frecuencia de ocurrencia de valores generados. Tabla detallando los datos de los proyectos generados y procesados. Tamaño del Proyecto Seleccionado. Si se desea generar todos los valores de los factores de costo en forma aleatoria o no. Valores de los factores de costo a utilizar o la indicación que se desea generar al azar. Asistente para Configurar Archivo de Exportación Control Coordina los pasos que se deben realizar para definir el archivo que será utilizado para exportar los datos generados y estimados. Nombre del archivo a generar. Modo de generación. Asistente para Generar Proyectos Estimados Control Coordina los pasos que se deben realizar para generar los proyectos estimados. Últimos valores de estimación calculados por las dos fórmulas del método DMCo- Mo. Media estadística de los valores de estimación calculados por las dos fórmulas del método Asistente para Generar Datos de Proyectos Control Coordina los pasos que se deben realizar para generar los proyectos al azar. Los 23 factores de costo generados para el proyecto a estimar. Asistente para Calcular Costos Estimados Control Coordina los pasos que se deben realizar para caculos los valores de costo estimados utilizando los factores de costo generados. Los 23 factores de costo generados para el proyecto a estimar. Valores de estimación calculados por las dos fórmulas del método DMCoMo. Ing. Pablo Pytel 279 Análisis del Sistema de Información (Segundo Ciclo)

280 Clase Tipo Responsabilidades Atributos Asistente para Mostrar Resultados Control Coordina los pasos que se deben realizar para mostrar los resultados de los proyectos generados y estimados. Tipo de visualización seleccionada Parámetros de Tamaños de Proyectos Entidad Representa la información de los parámetros permitidos para cada uno de los tamaños de proyectos. Identificador del tamaño del proyecto. Valores permitidos para cada uno de los 23 factores de costo. Parámetros Entidad Representa la información de los parámetros generales configurados para ser utilizados para generar los proyectos. Tamaño del Proyecto seleccionado. Nombre del Factor. Configuración de Factores de Costo Entidad Representa la configuración de los factores de costo para ser utilizados para generar los proyectos. Valor a utilizar (opcional) La indicación que se desea generar al azar o no. Posibles valores que se pueden utilizar de acuerdo al tamaño de proyecto seleccionado. Archivo de Exportación Entidad Representa al archivo que se utiliza para exportar los datos de los proyectos generados y estimados. Si se debe exportar los datos en un archivo o no. Nombre del archivo a generar. Proyectos Estimados Entidad Representa la información de los proyectos generados y estimados. Tabla SASI 6: Descripción de Clases Valores de los 23 factores de costo generados. Valores de los costos estimados por las dos fórmulas del método DMCoMo IDENTIFICACIÓN DE ASOCIACIONES Y AGREGACIONES Una vez establecido el diagrama de interacción para el segundo ciclo de desarrollo, en esta tarea se estudian los mensajes entre los objetos para determinar qué asociaciones Ing. Pablo Pytel 280 Análisis del Sistema de Información (Segundo Ciclo)

281 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 Diagrama de Clases incluyendo Asociaciones y Agregaciones Por asociación de objetos se define a la identificación de necesidad de cooperación realizada entre los mismos para poder llevar a cabo una responsabilidad. En los diagramas de colaboración esto puede ser visto a través de las flechas que unen las clases en los diagramas. En este caso fue necesario estudiar cuidadosamente dichas conexiones dado que posteriormente indican referencias y agregaciones entre objetos. A continuación por cada tipo de clase se identifican sus asociaciones y agregaciones: Clases de Entidad El diagrama de clases con sus agregaciones y asociaciones para las clases de entidad se muestra en la figura SASI 13. El único cambio con respecto al diagrama del primer ciclo de desarrollo fue la incorporación de la nueva clase de entidad ArchivoExportación el cual se vincula con la clase de entidad Parámetros. Figura SASI 13: Diagrama de Clases para de Entidad Ing. Pablo Pytel 281 Análisis del Sistema de Información (Segundo Ciclo)

282 Clases de Control Estas clases son responsables de administrar los flujos de trabajo necesarios para implementar un caso de uso. A continuación se muestran las relaciones de las clases de control en las figuras SASI 14 a SASI 18. Con respecto al primer ciclo de desarrollo, en estos diagramas fue modificado la figura SASI 17 (clase Asistente para Generar Proyectos Estimados ) y fueron agregados las figuras SASI 16 (clase Asistente para Configurar Archivo de Exportación ) y SASI 18 (clase Asistente para Mostrar Resultados ). Figura SASI 14: Diagrama de Clases de Asistente para Configurar Parámetros Ing. Pablo Pytel 282 Análisis del Sistema de Información (Segundo Ciclo)

283 Figura SASI 15: Diagrama de Clases de Asistente para Configurar Factores de Costo Figura SASI 16: Diagrama de Clases de Asistente para Configurar Archivo de Exportación Ing. Pablo Pytel 283 Análisis del Sistema de Información (Segundo Ciclo)

284 Figura SASI 17: Diagrama de Clases de Asistente para Generar Proyectos Estimados Figura SASI 18: Diagrama de Clases de Asistente para Mostrar Resultados Clases de Interfaz Dado que generalmente los lenguajes de programación orientados a objetos proveen librerías de clases, las cuáles contienen implementaciones de las características más importantes de las interfaces de usuarios. Cualquier desarrollo de interfaz está siempre muy ligado a las clases provistas por el lenguaje en cuestión. Por lo tanto durante el análisis fue decidido postergar las definiciones relacionadas con la interfaz de usuario para un momento posterior en cuanto se trate el diseño detallado. Ing. Pablo Pytel 284 Análisis del Sistema de Información (Segundo Ciclo)

285 8.4.3 IDENTIFICACIÓN DE GENERALIZACIONES Esta tarea se ocupa de 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 correspondientes al segundo ciclo de desarrollo Descripción de las Generalizaciones Identificadas Luego de analizar las clases definidas para el segundo ciclo de desarrollo del sistema software no fue detectada ninguna generalización entre las clases. 8.5 DEFINICIÓN DE INTERFACES DE USUARIO Esta actividad tiene el objetivo de definir las interfaces entre el sistema y el usuario. O sea, de los formatos de pantallas, diálogos, e informes, principalmente. Para ello fueron utilizados los principios generales de la interfaz que fueron definidos durante el primer ciclo de desarrollo (sección 5.5.1). Como producto resultante de realizar esta actividad se obtuvieron la especificación de interfaz de usuario del segundo ciclo de desarrollo, la cual incluye los siguientes elementos: Formatos individuales de interfaz de pantalla. 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 FORMATOS INDIVIDUALES DE LA INTERFAZ DE PANTALLA Esta tarea tiene como objetivo definir en forma detallada las pantallas del sistema software que implementan las clases de interfaz de usuario previamente identificadas contemplando los Principios Generales de la Interfaz y los prototipos ya definidos durante el primer ciclo de desarrollo Modelo de Navegación de Interfaz En esta sección se define el modelo que indica como las diferentes interfaces de usuario previamente definidas pueden navegarse entre sí. En la figura SASI 19 se muestra el diagrama de navegación de las pantallas. Ing. Pablo Pytel 285 Análisis del Sistema de Información (Segundo Ciclo)

286 Figura SASI 19: Diagrama de Navegación de Pantallas Descripción de las Características Generales de cada Pantallas A continuación se describen las principales características de cada una de las pantallas identificadas: a. Pantalla Principal (Menú Principal) Esta es la pantalla, ya existente en el primer ciclo de desarrollo, que el usuario utiliza para acceder a las principales funcionalidades del sistema software a través de un menú contextual. Para el segundo ciclo de desarrollo fue agregada la opción de acceder a la clase de interfaz Mostrar Resultados. b. Configurar Parámetros Esta pantalla, ya existente en el primer ciclo de desarrollo, permite al usuario seleccionar los parámetros a ser utilizados cuando se generen los proyectos estimados. Para el segundo ciclo de desarrollo fueron agregados controles para acceder a la clase Configurar Archivo de Exportación. c. Configurar Archivo de Exportación Esta pantalla, agregada en el segundo ciclo de desarrollo, permite al usuario definir el archivo que es utilizado para exportar los datos generados y estimados. Ing. Pablo Pytel 286 Análisis del Sistema de Información (Segundo Ciclo)

287 d. Configurar Factores de Costo Esta pantalla, ya existente en el primer ciclo de desarrollo, permite al usuario configurar los factores de costo al definir si se desea utilizar un valor específico o un valor al azar a cada uno. El segundo ciclo de desarrollo no afectó está pantalla. e. Generar Proyectos Estimados Esta pantalla, ya existente en el primer ciclo de desarrollo, permite al usuario realizar la generación de los datos de los proyectos y su estimación. Para el segundo ciclo de desarrollo fue agregado un nuevo modo de operación ( Análisis Completo ) y los gráficos de las estimaciones calculadas. f. Mostrar Resultados Esta pantalla, agregada en el segundo ciclo de desarrollo, permite al usuario visualizar los resultados de los proyectos generados y estimados utilizando gráficos y una tabla detallada Definición de las Pantallas del Sistema A continuación se detallan los prototipos de las pantallas del sistema software incluyendo las modificaciones correspondientes al segundo ciclo de desarrollo (explicados en el punto anterior): a. Pantalla Principal (Menú Principal) Esta es la pantalla principal del sistema software que se observa al ingresar. La pantalla contiene una barra de menú con las principales funcionalidades del sistema: - Configurar Parámetros. - Configurar Factores. - Generar Proyectos Estimados. - Mostrar Resultados. El prototipo de esta pantalla se muestra en la figura SASI 20. Ing. Pablo Pytel 287 Análisis del Sistema de Información (Segundo Ciclo)

288 Figura SASI 20: Pantalla Principal (Menú Principal) b. Configurar Parámetros Esta pantalla se accede al seleccionar la opción Configurar Parámetros del menú contextual y contiene los siguientes elementos: - Una lista de botones de radio ( radio-buttons ) excluyentes entre sí para seleccionar el tamaño del proyecto a procesar. - Una casilla de selección ( check-box ) para indicar que se desea generar todos los factores de costo aleatoriamente. - Una casilla de selección ( check-box ) para indicar que se desea exportar los datos en un archivo. - El prototipo de esta pantalla se muestra en la figura SASI 21. Ing. Pablo Pytel 288 Análisis del Sistema de Información (Segundo Ciclo)

289 Figura SASI 21: Pantalla de Configurar Parámetros c. Configurar Archivo de Exportación Esta pantalla se accede al indicar que se desea exportar los datos en un archivo y permite al usuario ingresar el nombre del archivo a generar a través de una casilla de texto. El usuario puede confirmar este archivo o cancelar la operación a través de dos botones. El prototipo de esta pantalla se muestra en la figura SASI 22. Ing. Pablo Pytel 289 Análisis del Sistema de Información (Segundo Ciclo)

290 Figura SASI 22: Pantalla de Configurar Archivo de Exportación d. Configurar Factores de Costo Al seleccionar la opción Configurar Factores del menú contextual, el sistema software despliega las seis categorías de factores de costos definidas por el método DMCoMo. Al seleccionar una de estas categorías se despliega una pantalla con una pestaña por cada uno de los factores de costo asociados a la categoría seleccionada. Cada pestaña cuenta con los siguientes elementos: - Una casilla de texto para ingresar un valor específico que se quiere utilizar para el factor. - Una casilla de selección ( check-box ) para indicar si se desea generar los valores del factor de costo al azar. El prototipo de esta pantalla se muestra en la figura SASI 23. Ing. Pablo Pytel 290 Análisis del Sistema de Información (Segundo Ciclo)

291 Figura SASI 23: Pantalla de Configurar Factores de Costo e. Generar Proyectos Estimados Esta pantalla se accede al seleccionar la opción Generar Proyectos Estimados del menú contextual y contiene los siguientes elementos: - Una lista de botones de radio ( radio-buttons ) excluyentes entre sí para seleccionar el modo de generación de los proyectos estimados. - Un botón para comenzar la generación de los proyectos estimados. - Un botón, que sólo estará habilitado cuando se seleccione el modo Activar Evaluación Continua, para finalizar la generación de los proyectos estimados. - Cuatro etiquetas para mostrar los resultados que se están calculando en tiempo real, los cuales son: los costos estimados calculados por las dos fórmulas de DMCoMo y la media estadística de los costos estimados calculados por las dos fórmulas de DMCoMo. - Un gráfico para mostrar el gráfico con el histograma de la estimación calculada para cada una de las fórmulas de estimación (utilizando un color diferente para cada fórmula). - Un gráfico para mostrar el gráfico con el histograma de la media estadística de la estimación calculada para cada una de las fórmulas de estimación (utilizando un color diferente para cada fórmula). Ing. Pablo Pytel 291 Análisis del Sistema de Información (Segundo Ciclo)

292 El prototipo de esta pantalla se muestra en la figura SASI 24. Figura SASI 24: Pantalla de Generar Proyectos Estimados f. Mostrar Resultados Esta pantalla se accede al seleccionar la opción Mostrar Resultados del menú contextual y está formada por pestañas por cada una de las categorías de factores de costos definidas por el método DMCoMo más dos pestañas especiales, una llamada Costos y otra Tabla de Datos. A continuación se explican los elementos de cada pestaña: - En las pestañas correspondientes a las categorías de factores de costos definidas se muestra un gráfico de barras con la frecuencia de ocurrencia de valores por cada uno de los factores correspondientes a la categoría. - En la pestaña Costos se muestran dos gráficos de barras con la frecuencia de ocurrencia de valores uno para cada uno de los costos estimados por el método DMCoMo. - En la pestaña Tabla de Datos se muestra una grilla mostrando todos los valores de los factores de costo generados y los dos costos calculados. Los prototipos de esta pantalla para los diferentes tipos de pestaña se muestran en las figuras SASI 25, SASI 26 y SASI 27. Ing. Pablo Pytel 292 Análisis del Sistema de Información (Segundo Ciclo)

293 Figura SASI 25: Pantalla de Mostrar Resultados (Gráficos de Factores) Figura SASI 26: Pantalla de Mostrar Resultados (Gráficos de Costos) Ing. Pablo Pytel 293 Análisis del Sistema de Información (Segundo Ciclo)

294 Figura SASI 27: Pantalla de Mostrar Resultados (Tabla Detallada) ESPECIFICACIÓN DE FORMATOS DE IMPRESIÓN Esta tarea define los formatos y características de las salidas o entradas impresas del sistema software Formatos de Impresión En este sistema software no se realizan impresiones, por lo que este aspecto queda pendiente para futuras modificaciones (no contemplados en este trabajo). 8.6 ANÁLISIS DE CONSISTENCIA Y ESPECIFICACIÓN DE REQUISITOS Esta actividad tiene el objetivo de garantizar la calidad de los distintos modelos generados en el proceso de Análisis del Sistema de Información, además de asegurarse que los usuarios y los Analistas tienen el mismo concepto del sistema. Para cumplir dichos objetivos 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. Ing. Pablo Pytel 294 Análisis del Sistema de Información (Segundo Ciclo)

295 Para realizar esta actividad se requiere una herramienta de ayuda para el análisis de consistencia VERIFICACIÓN DE LOS MODELOS El objetivo de esta tarea es, conforme a la técnica seguida para la elaboración de cada producto y a las normas determinadas para asegurar la calidad formal de los distintos modelos. 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, se verifica la calidad de los distintos modelos de forma separada. Como resultado de la verificación, se efectuaron correcciones que fueron posteriormente comprobadas nuevamente en forma satisfactoria ANÁLISIS DE CONSISTENCIA ENTRE MÉTODOS Esta tarea se ocupa de asegurar la consistencia entre los modelos controlando que estos sean coherentes entre sí, y comprobando la falta de ambigüedades o duplicación de información. Las comprobaciones forman parte del producto Resultado de Análisis de Consistencia y pueden variar en función del tipo de desarrollo, aunque en general, son matrices entre los elementos comunes de los distintos modelos como se indicó durante el primer ciclo de desarrollo Análisis de Consistencia En esta sección se procedió a comprobar la coherencia entre los distintos modelos de acuerdo a las trazabilidades definidas en el primer ciclo de desarrollo para los requerimientos incluidos en el segundo ciclo de desarrollo y los modelos resultantes del proceso de análisis en ese ciclo. Para llevar a la comprobación se utilizó un conjunto de matrices de trazabilidad que se muestran a continuación: a. Catálogo de Requisitos vs Modelo de Negocio: En la tabla SASI 7 se muestra la matriz que incluye en sus filas los requisitos del catálogo para el segundo ciclo de desarrollo y en sus columnas las actividades del modelo de negocio. Como puede verse, se comprobó que cada una de las actividades tiene su correspondencia con algún requisito. Ing. Pablo Pytel 295 Análisis del Sistema de Información (Segundo Ciclo)

296 Catálogo de Requisitos / Modelo de Negocio RF 1: Configurar Parámetros RF 1.2 Configurar Parámetros X Generar Proyectos Estimados RF X RF X RF X RF X RF 2: Generar Datos de Proyecto RF 2.4 X RNF 1: Modos de Procesamiento de Proyectos RNF 1.3 X RNF 2: Interfaz Gráfica RNF 2.4 X RNF X RBF X RNF 2.5 X RNF 2.6 X Ing. Pablo Pytel 296 Análisis del Sistema de Información (Segundo Ciclo)

297 Catálogo de Requisitos / Modelo de Negocio Configurar Parámetros Generar Proyectos Estimados RNF 4: Restricciones de Carpetas RNF 4.1 X X RNF 4.2 X X RNF 5: Generación de Archivos RNF 5.1 X RNF 5.2 X Tabla SASI 7: Trazabilidades entre el Catálogo de Requisitos y Modelo de Negocio b. Modelo de Casos de Uso vs Catálogo de Requisitos: En la tabla SASI 8 se muestra la matriz que incluye en sus filas los requisitos del catálogo de requisitos para el segundo ciclo de desarrollo y en sus columnas los casos de uso del Modelo de Casos de Uso. Como puede verse, se comprobó que cada requisito tiene correspondencia con algún caso de uso y viceversa. Catálogo de Requisitos / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados RF 1: Configurar Parámetros RF 1.2 X X RF X X RF RF RF X X X Ing. Pablo Pytel 297 Análisis del Sistema de Información (Segundo Ciclo)

298 Catálogo de Requisitos / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados RF 2: Generar Datos de Proyecto RF 2.4 X RNF 1: Modos de Procesamiento de Proyectos RNF 1.3 X RNF 2: Interfaz Gráfica RNF 2.4 RNF RBF X X X RNF 2.5 RNF 2.6 X X RNF 4: Restricciones de Carpetas RNF 4.1 X X RNF 4.2 X X RNF 5: Generación de Archivos RNF 5.1 RNF 5.2 X X Tabla SASI 8: Trazabilidades entre el Modelo de Casos de Uso y el Catálogo de Requisitos c. Modelo de Casos de Uso vs Prototipo de Interfaz: En la tabla SASI 9 se muestra la matriz que incluye en sus filas las pantallas del modelo del Prototipo de Interfaz y en sus columnas los casos de uso del Modelo de Casos de Uso. De esta forma, se comprobó que cada pantalla tiene correspondencia con algún caso de uso y viceversa. Ing. Pablo Pytel 298 Análisis del Sistema de Información (Segundo Ciclo)

299 Prototipo de Interfaz / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Pantalla Principal (Menú Principal) Configurar Parámetros X X X X X Configurar Factores de Costo X Configurar Archivo de Exportación X Generar Proyectos Estimados X Mostrar Resultados X Tabla SASI 9: Trazabilidades entre el Modelo de Casos de Uso y el Prototipo de Interfaz d. Modelo de Modelo de Navegación de Interfaz vs Prototipo de Interfaz: En la tabla SASI 10 se muestra la matriz que incluye en sus filas las pantallas del modelo del Prototipo de Interfaz y en las columnas las pantallas del Modelo de Navegación. Así se comprobó que cada pantalla de interfaz de usuario tiene correspondencia con alguna de las pantallas del modelo de navegación. Modelo de Navegación de Interfaz / Prototipo de Interfaz Pantalla Principal (Menú Principal) Configurar Parámetros Configurar Factores de Costo Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados Pantalla Principal (Menú Principal) X Configurar Parámetros X Configurar Factores de Costo X Configurar Archivo de Exportación X Ing. Pablo Pytel 299 Análisis del Sistema de Información (Segundo Ciclo)

300 Modelo de Navegación de Interfaz / Prototipo de Interfaz Pantalla Principal (Menú Principal) Configurar Parámetros Configurar Factores de Costo Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados Generar Proyectos Estimados X Mostrar Resultados X Tabla ASI S10: Trazabilidades entre el Modelo de Navegación de Interfaz y el Prototipo de Interfaz e. Modelo de Casos de Uso vs Clases: En la tabla SASI 11 se muestra la matriz que incluye en sus filas las Clases y en las columnas los casos de uso del Modelo de Casos de Uso. Se comprobó que cada clase tiene correspondencia con algún caso de uso y viceversa. Clases / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Interfaz de Pantalla Principal X X X X Interfaz de Configurar Parámetros X Interfaz de Configurar Factores de Costos X Interfaz de Configurar Archivo de Exportación Interfaz de Generar Proyectos Estimados X X Interfaz de Mostrar Resultados X Ing. Pablo Pytel 300 Análisis del Sistema de Información (Segundo Ciclo)

301 Clases / Modelo de Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Asistente para Configurar Parámetros X Asistente para Configurar Factores de Costo Asistente para Configurar Archivo de Exportación Asistente para Generar Proyectos Estimados Asistente para Generar Datos de Proyectos Asistente para Calcular Costos Estimados X X X X X Asistente para Mostrar Resultados X Parámetros de Tamaños de Proyectos X X Parámetros X X X X Configuración de Factores de Costo X X X Archivo de Exportación X X Proyectos Estimados X X Tabla SASI 11: Trazabilidades entre el Modelo de Casos de Uso y el Diagrama de Clases 8.7 APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN En esta tarea el Comité de Dirección decide la aprobación formal o no del Análisis del Sistema de Información luego de que este es presentado. Ing. Pablo Pytel 301 Análisis del Sistema de Información (Segundo Ciclo)

302 8.7.1 PRESENTACIÓN Y APROBACIÓN DEL ANÁLISIS DEL SISTEMA DE INFORMACIÓN CORRESPONDIENTE AL SEGUNDO CICLO DE DESARROLLO Luego de realizar una reunión mantenida entre el tesista y los Directores del Proyecto de Tesis, se dio como válida Análisis para el segundo ciclo de desarrollo y se consideró aprobada la misma para continuar con las actividades de diseño. Ing. Pablo Pytel 302 Análisis del Sistema de Información (Segundo Ciclo)

303 CAPÍTULO 9 SEGUNDO CICLO DE DESARROLLO: DISEÑO DEL SISTEMA DE INFORMACIÓN

304

305 9. SEGUNDO CICLO DE DESARROLLO: DISEÑO DEL SISTEMA DEL SISTEMA DE INFORMACIÓN 9.1 INTRODUCCIÓN El proceso de Diseño del Sistema de Información (DSI) se volvió a realizar en el segundo ciclo de desarrollo considerando tanto los modelos generados durante las actividades de diseño del primer ciclo de desarrollo como los modelos de análisis generados durante el segundo ciclo de desarrollo. Por lo tanto, a los modelos creados durante el Diseño del Sistema de Información en el primer ciclo de desarrollo (capítulo 6 de este trabajo) se les incluyeron elementos nuevos y/o modificaciones para que satisfagan todas las modelos del Análisis del Sistema de Información en el segundo ciclo de desarrollo (capítulo 8). Se debe considerar que durante este segundo ciclo de desarrollo no fue necesario realizar las actividades de Diseño de la Arquitectura de Soporte y Generación de Especificaciones de Construcción ya que no fueron afectadas por los requerimientos del segundo ciclo de desarrollo. 9.2 DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA Esta actividad tiene como objetivo completar la arquitectura general del sistema software definida durante el primer ciclo de desarrollo con los elementos agregados y/o modificados por la incorporación de los requerimientos del segundo ciclo de desarrollo DEFINICIÓN DE NIVELES DE ARQUITECTURA Esta tarea define los niveles de arquitectura software para el segundo ciclo de desarrollo, mediante la definición de las principales participaciones físicas del sistema software, representadas como nodos y comunicaciones entre nodos. Para facilitar la comprensión del sistema, el mismo se documenta mediante un Modelo de Despliegue de Componentes de UML, el cual incluye los siguientes tipos de elementos: - Nodos de procesamiento - Dispositivos hardware - Comunicación entre nodos y con dispositivos - Componentes de software empaquetados en unidades instalables Ing. Pablo Pytel 305 Diseño del Sistema de Información (Segundo Ciclo)

306 Descripción de los Niveles de Arquitectura del Sistema El sistema software de este proyecto reside en un único equipo con las características definidas en el primer ciclo de desarrollo (sección ). El nodo se encuentra formado por los componentes del primer ciclo de desarrollo con los nuevos agregados en el segundo ciclo de desarrollo en la figura SDSI 1. Debido a la existencia de un único equipo y la ausencia de Base de Datos, la comunicación entre componentes se realiza a través de mensajes en un modelo POO (Programación Orientada a Objetos). Figura SDSI 1: Diagrama de componentes del Sistema A continuación se realiza una descripción de todos los componentes identificados para el segundo ciclo de desarrollo: Configurador: representa las funcionalidades que permiten al usuario definir los parámetros generales y de los factores de costo que serán utilizados para generar y procesar los proyectos. Ing. Pablo Pytel 306 Diseño del Sistema de Información (Segundo Ciclo)

307 Procesador de Proyectos: representa las funcionalidades que permiten al usuario generar aleatoriamente los datos de los proyectos y estimarlos al utilizar las fórmulas del método DMCoMo. Visualizador de Resultados: representa las funcionalidades que permiten al usuario ver los resultados del procesamiento de los proyectos. Tamaños de Proyectos: representa la tabla que contiene los valores permitidos para cada uno de los factores de costo de acuerdo al tamaño del proyecto. Parámetros de Configuración: representa la configuración seleccionada por el usuario para los parámetros generales que serán utilizados al momento de procesar los proyectos. Factores de Costo Configurados: representa la configuración seleccionada por el usuario para los factores de costo que es utilizada para generar aleatoriamente los proyectos. Proyectos Estimados: representa a los proyectos procesados, o sea, proyectos generados aleatoriamente por el sistema software a los cuáles se les aplico las fórmulas de estimación del método DMCoMo. Archivo de Exportación: archivo físico donde se puede almacenar el resultado de los proyectos procesados por el sistema software IDENTIFICACIÓN DE REQUISITOS DE DISEÑO Y CONSTRUCCIÓN Esta tarea se ocupa de realizar 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 (CSI). Por lo tanto, como resultado de esta tarea se actualiza el catálogo de requisitos elaborado en el Estudio de Viabilidad del Sistema (capítulo 3 de este trabajo) Descripción de los Requisitos Adicionales Se detallan a continuación los requisitos no funcionales que fueron identificados durante el diseño y fueron agregados al Catálogo de Requisitos (definido en la sección al que se le ha agregado un requerimiento no funcional en la sección ). Además, en la figura SDSI 2 se muestran los requisitos no funcionales del sistema incluyendo los nuevos agregados. Ing. Pablo Pytel 307 Diseño del Sistema de Información (Segundo Ciclo)

308 Figura SDSI 2: Nuevo Requisitos No Funcionales del Sistema Software (en gris oscuro se resaltan los requisitos incluidos en el actual ciclo de desarrollo) a. Requisitos No Funcionales: RNF 6: Rendimiento General RNF 6.2: Se restringe la información mostrada en el caso de generar el análisis completo de combinaciones. RNF 6.2.1: No se muestra el gráfico de histograma al utilizar el modo de operación análisis completo. RNF 6.2.2: No se muestra la tabla completa de valores generados y procesados al utilizar el modo de operación análisis completo. Nota: Este nuevo requerimiento se debe a que luego de haber estimado, para el hardware y software propuesto, el tiempo de procesamiento en alrededor de proyectos/minuto, y considerando que para poder realizar el procesamien- Ing. Pablo Pytel 308 Diseño del Sistema de Información (Segundo Ciclo)

309 to en modo análisis completo el sistema software debe generar y procesar todas las combinaciones válidas para el tamaño de proyecto seleccionado ( combinaciones para proyectos de tamaño grande, para tamaño mediano y para tamaño pequeño), entonces para poder generar el banco de prueba completo al sistema le llevaría mucho tiempo (1 día y medio para proyectos de tamaño grande, 12 días para tamaño mediano y 1 día para proyectos de tamaño pequeño). Por otro lado, fue observado que el mayor tiempo de procesamiento es utilizado para poder generar el gráfico de histograma y mostrar los datos en la tabla de datos provistos por el sistema software. Por lo tanto, se decidió que en caso de seleccionar el modo análisis completo, el sistema software no genera esta información sólo exportando los resultados para ser analizados luego mediante Microsoft Excel. Este nuevo requisito modificó levemente el comportamiento del sistema software para el caso de uso Generar Proyectos Estimados para el flujo alternativo del paso 3 El usuario selecciona el modo Análisis completo para todas las posibilidades. RNF 7: Cantidad Filas en Archivos Generados RNF 7.1: Permitir al usuario indicar si sólo se generará un único archivo de exportación o en más de uno considerando una cantidad máxima de proyectos por archivo. RNF 7.2: Permitir al usuario configurar la cantidad máxima de proyectos que se pueden incluir por archivo. Nota: Este nuevo requerimiento fue agregado porque Microsoft Excel posee una restricción de la cantidad máxima de filas para abrir un archivo ( filas en Microsoft Excel 2010 y filas en versiones anteriores). Así fue necesario permitir al usuario indicar si se desea exportar los resultados generados en más de un archivo considerando una cantidad máxima de filas definida también por el usuario. De esta manera, se podría generar un solo archivo o más archivos dependiendo de la configuración seleccionada por el usuario ESPECIFICACIONES DE EXCEPCIÓN Esta tarea tiene como objetivo definir los comportamientos no habituales del sistema software y que reflejan situaciones anómalas o secundarias en el funcionamiento y ejecu- Ing. Pablo Pytel 309 Diseño del Sistema de Información (Segundo Ciclo)

310 ción del sistema software. Para ello, primero se define el nivel de especificación de las mismas, así como los criterios de catalogación y clasificación. A través de su catalogación se busca ayudar la definición del diseño del sistema software y la especificación técnica de las pruebas, dado que permite generar algunos casos de prueba de forma inmediata. Este catálogo se va completando a partir de las actividades correspondientes al diseño detallado de los subsistemas. Las excepciones que se proponen como obligatorias son las relacionadas con el funcionamiento general del sistema software, las cuales están normalmente asociadas a: Nodos y comunicaciones del particionamiento físico del sistema software. Este tipo de excepciones tiene lugar cuando no están disponibles los motores 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. Además 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 Catálogo de Excepciones Durante el segundo ciclo de desarrollo del sistema software fue detectado que el principal motivo de excepción se puede producir por problemas en la escritura de los archivos de exportación. Así las excepciones se pueden producir cuando no se puede crear o modificar un archivo por problemas de permiso o por falta de espacio en disco, o bien no se puede modificar un archivo existente por ya estar tomado por otra aplicación. Las excepciones que fueron contempladas se detallan en las tablas SDSI 1 a SDSI 5. Excepción Tipo Descripción Condiciones previas Elemento afectado EX-C01 Crear archivo Se pretende crear un archivo nuevo para almacenar los resultados por el sistema, pero puede crear por falta de permisos. No se tienen permisos del usuario para crear al archivo en el directorio de trabajo. Módulos de configuración y procesamiento de proyectos (Configuración y Procesador de Proyectos). Ing. Pablo Pytel 310 Diseño del Sistema de Información (Segundo Ciclo)

311 Excepción Respuesta del sistema EX-C01 Mensaje de error al usuario indicando la imposibilidad de crear el archivo seleccionado. Tabla SDSI 1: Excepción de creación de archivo Excepción Tipo Descripción Condiciones previas Elemento afectado Respuesta del sistema EX-C02 Crear archivo Se pretende crear un archivo nuevo para almacenar los resultados por el sistema, pero no hay espacio disponible en disco. No hay espacio suficiente en disco para crear el archivo. Módulos de configuración y procesamiento de proyectos (Configuración y Procesador de Proyectos). Mensaje de error al usuario indicando la imposibilidad de crear el archivo seleccionado. Tabla SDSI 2: Excepción de creación de archivo Excepción Tipo Descripción Condiciones previas Elemento afectado Respuesta del sistema EX-M01 Modificar archivo ya existente Se pretende modificar un archivo ya existente para almacenar los resultados por el sistema, pero no se puede acceder por falta de permisos. No se tienen permisos del usuario para acceder al archivo y modificarlo. Módulos de configuración y procesamiento de proyectos (Configuración y Procesador de Proyectos). Mensaje de error al usuario indicando la imposibilidad de modificar el archivo seleccionado. Tabla SDSI 3: Excepción de modificar archivo ya existente Excepción Tipo Descripción Condiciones previas Elemento afectado Respuesta del sistema EX-M02 Modificar archivo ya existente Se pretende modificar un archivo ya existente para almacenar los resultados por el sistema, pero no ha espacio disponible en disco. No hay espacio suficiente en disco para modificar el archivo. Módulos de configuración y procesamiento de proyectos (Configuración y Procesador de Proyectos). Mensaje de error al usuario indicando la imposibilidad de modificar el archivo seleccionado. Tabla SDSI 4: Excepción de modificar archivo ya existente Excepción Tipo EX-M03 Modificar archivo ya existente Ing. Pablo Pytel 311 Diseño del Sistema de Información (Segundo Ciclo)

312 Excepción Descripción Condiciones previas Elemento afectado Respuesta del sistema EX-M03 Se pretende modificar un archivo ya existente para almacenar los resultados por el sistema, pero el archivo se encuentra abierto por otra aplicación. El archivo está tomado por otra aplicación. Módulos de configuración y procesamiento de proyectos (Configuración y Procesador de Proyectos). Mensaje de error al usuario indicando la imposibilidad de modificar el archivo seleccionado. Tabla SDSI 5: Excepción de modificar archivo ya existente IDENTIFICACIÓN DE SUBSISTEMAS DE DISEÑO Esta tarea tiene el objetivo de dividir de forma lógica el sistema software en subsistemas de diseño. Como referencia inicial se toman los modelos especificados en el Diseño del Sistema de Información (DSI) del primer ciclo de desarrollo y con los modelos generados en el proceso Análisis del Sistema de Información (ASI) del segundo ciclo de desarrollo. En este caso no fueron realizados modificaciones por lo que se utilizaron los Subsistemas de Diseño y Entorno Tecnológico y los Requisitos de Operación y Seguridad definidos durante el diseño del primer ciclo de desarrollo (secciones 6.2.4, y de este trabajo respectivamente). 9.3 DISEÑO DE CASOS DE USO REALES Esta actividad sólo se realiza en el caso de Diseño Orientado a Objetos y tiene como objetivo especificar el comportamiento del sistema software para un caso de uso mediante objetos o subsistemas de diseño que interactúan. De esta forma se busca determinar las operaciones de las clases e interfaces de los distintos subsistemas de diseño. 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 Esta tarea tiene como objetivo identificar las clases definidas en la tarea Identificación de Clases Adicionales que intervienen en cada caso de uso del segundo ciclo de desarrollo. 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. Ing. Pablo Pytel 312 Diseño del Sistema de Información (Segundo Ciclo)

313 Clases Asociadas a los Casos de Usos En esta tarea fueron descriptas las clases de diseño que se utilizaron para realizar cada caso de uso identificado durante el proceso de Análisis del segundo ciclo de desarrollo. Esto se representa a través de los diagramas de clases de caso de uso que se muestran en las figuras SDSI 3 a SDSI 7. Nótese que con respecto al primer ciclo de desarrollo fueron agregados los diagramas de las figuras SDSI 5 (caso de uso Configurar Archivo de Exportación ) y SDSI 7 (caso de uso Mostrar Resultados de Proyectos Estimados ); y sólo fue modificado el diagrama de la figura SDSI 6 (caso de uso Generar Proyectos Estimados ). Figura SDSI 3: Diagrama de Clases del caso de uso Configurar Parámetros Figura SDSI 4: Diagrama de Clases del caso de uso Configurar Factores de Costo del Proyecto Ing. Pablo Pytel 313 Diseño del Sistema de Información (Segundo Ciclo)

314 Figura SDSI 5: Diagrama de Clases del caso de uso Configurar Archivo de Exportación Figura SDSI 6: Diagrama de Clases del caso de uso Generar Proyectos Estimados Figura SDSI 7: Diagrama de Clases del caso de uso Mostrar Resultados de Proyectos Estimados A continuación se muestra en la tabla SDSI 6, cómo se vinculan las clases definidas durante el proceso de análisis del segundo ciclo de desarrollo y las clases definidas durante el diseño. Ing. Pablo Pytel 314 Diseño del Sistema de Información (Segundo Ciclo)

315 Clases de Análisis Interfaz Principal Usuario Clases de diseño IUPrincipal Interfaz de Configurar Parámetros Interfaz de Configurar Archivo de Exportación Interfaz de Configurar Factores de Costos Interfaz de Generar Proyectos Estimados Interfaz de Mostrar Resultados Asistente para Configurar Parámetros Asistente para Configurar Factores de Costo Asistente para Configurar Archivo de Exportación Asistente para Generar Proyectos Estimados Asistente para Generar Datos de Proyectos Asistente para Calcular Costos Estimados Asistente para Mostrar Resultados Parámetros de Tamaños de Proyectos Parámetros Configuración de Factores de Costo IUConfigParametros IUConfigFactCosto IUProcProyectos IUMostrarResultados ConfigParametros ConfigFactCosto ConfigArchivoExp ProcProyectos GenProyectos CalcCostosEstimados MostrarResultados ParamTamProyecto ParamGral ParamFactCosto Archivo de Exportación ArchExp Proyectos Estimados ProyEstimados Tabla SDSI 6: Vinculación entre clases de Análisis y Diseño REVISIÓN DE LA INTERFAZ DE USUARIO Esta tarea tiene como objetivo 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. Esto incluye revisar la interfaz de usuario, la navegación entre ventanas, los elementos que forman cada interfaz, sus Ing. Pablo Pytel 315 Diseño del Sistema de Información (Segundo Ciclo)

316 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 Resultado de la revisión de la Interfaz de Usuario Como puede verse en los diagramas de clases asociados a los casos de uso del segundo ciclo de desarrollo no aparecieron nuevas clases de interfaz pero hay dos modificaciones. En el diseño de las clases de los casos de uso Configurar Parámetros y Configurar Archivo de Exportación se decidió unificar la clase de interfaz (o sea, la pantalla) para realizar ambas operaciones. De esta manera, la interfaz de configurar parámetros (clase de diseño IUConfigParametros, la cual en el análisis se denominaba Interfaz de Configurar Parámetros ) incluye también los elementos definidos durante el análisis para el caso de uso Configurar Archivo de Exportación (clase de análisis Interfaz de Configurar Archivo de Exportación ). Además, al considerar el nuevo requisito no funcional RN 7 Cantidad Filas en Archivos Generados, fue necesario agregar dos nuevos elementos para configurar el archivo de exportación y así permitir al usuario seleccionar cómo se quiere manejar la cantidad de filas en los archivos de exportación generados. Como resultado de todo esto, se modificó el diagrama de navegación de las pantallas y el prototipo de la pantalla Configurar Parámetros. Las versiones modificadas se muestran en las figuras SDSI 8 y SDSI 9. Figura SDSI 8: Nuevo Diagrama de Navegación de Pantallas Ing. Pablo Pytel 316 Diseño del Sistema de Información (Segundo Ciclo)

317 Figura SDSI 9: Nueva Pantalla de Configurar Parámetros La pantalla de Configurar Parámetros se accede al seleccionar la opción Configurar Parámetros del menú contextual y contiene los siguientes elementos: - Una lista de botones de radio ( radio-buttons ) excluyentes entre sí para seleccionar el tamaño del proyecto a procesar. - Una casilla de selección ( check-box ) para indicar que se desea exportar los datos en un archivo. - Una casilla de texto que permite al usuario ingresar el nombre del archivo para exportar con un botón para confirmar esto. - Una casilla de selección ( check-box ) para indicar que se desea dividir los datos exportados en múltiples archivos, considerando la cantidad máxima de filas que se puede indicar al elegir esta opción. - Una casilla de selección ( check-box ) para indicar que se desea generar todos los factores de costo aleatoriamente. 9.4 DISEÑO DE CLASES Esta actividad sólo se realiza en el caso de Diseño Orientado a Objetos, y su objetivo es transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño. Este modelo incluye la especificación detallada de cada una de las clases, es Ing. Pablo Pytel 317 Diseño del Sistema de Información (Segundo Ciclo)

318 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 IDENTIFICACIÓN DE ATRIBUTOS DE LAS CLASES Esta tarea tiene como objetivo identificar y describir los atributos de las clases, una vez que se ha especificado el entorno de desarrollo. Para identificar los atributos se revisa el modelo de clases obtenido en el proceso de Análisis del Sistema de Información del segundo ciclo de desarrollo, considerando que 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 Para realizar esta tarea se completó para cada una de las clases de diseño la información, relativa a sus atributos y tipo de dato del atributo (utilizando los nombres provistos por Java) en la tabla SDSI 7 a continuación: Clase Atributos Tipo ConfigParametros ConfigFactCosto ConfigArchivoExp ProcProyectos CodigoTamProyectoSelecc GenTodosFactCostoAzar CodigoFactCosto ValorFactCosto GenFactCostoAzar ExportarDatos NombreArchExp DividirArchivoFilas CantMaxFilasArchivo CodigoModoGeneracion UltEstimCalculados23FactCosto UltEstimCalculados8FactCosto Boolean String Boolean Boolean String(256) Boolean Int Double Double Ing. Pablo Pytel 318 Diseño del Sistema de Información (Segundo Ciclo)

319 Clase Atributos Tipo GenProyectos CalcCostosEstimados CantProyectosGenerados MediaEstimCalculados23FactCosto MediaEstimCalculados8FactCosto ValorFactCostNTAB ValorFactCostNTUP ValorFactCostNATR ValorFactCostDISP ValorFactCostPNUL ValorFactCostDMOD ValorFactCostDEXT ValorFactCostNMOD ValorFactCostTMOD ValorFactCostMTUP ValorFactCostMATRn ValorFactCostMATRt ValorFactCostMTEC ValorFactCostNFUN ValorFactCostSCOM ValorFactCostTOOL ValorFactCostCOMP ValorFactCostNFOR ValorFactCostNDEP ValorFactCostDOCU ValorFactCostSITE ValorFactCostMFAM ValorFactCostKDAT ValorFactCostADIR ValorFactCostNTAB ValorFactCostNTUP ValorFactCostNATR ValorFactCostDISP ValorFactCostPNUL Int Double Double Ing. Pablo Pytel 319 Diseño del Sistema de Información (Segundo Ciclo)

320 Clase Atributos Tipo ValorFactCostDMOD ValorFactCostDEXT ValorFactCostNMOD ValorFactCostTMOD ValorFactCostMTUP ValorFactCostMATRn ValorFactCostMATRt ValorFactCostMTEC ValorFactCostNFUN ValorFactCostSCOM ValorFactCostTOOL ValorFactCostCOMP ValorFactCostNFOR ValorFactCostNDEP ValorFactCostDOCU ValorFactCostSITE ValorFactCostMFAM ValorFactCostKDAT ValorFactCostADIR EstimCalculados23FactCosto EstimCalculados8FactCosto Double Double MostrarResultados TipoVisualizacionSeleccionada ParamTamProyecto CodigoTamProyectoSelecc ValoresPermFactCostNTAB ValoresPermFactCostNTUP ValoresPermFactCostNATR ValoresPermFactCostDISP ValoresPermFactCostPNUL ValoresPermFactCostDMOD ValoresPermFactCostDEXT ValoresPermFactCostNMOD ValoresPermFactCostTMOD Array of Array of Array of Array of Array of Array of Array of Array of Array of Ing. Pablo Pytel 320 Diseño del Sistema de Información (Segundo Ciclo)

321 Clase Atributos Tipo ParamGral ParamFactCosto ValoresPermFactCostMTUP ValoresPermFactCostMATRn ValoresPermFactCostMATRt ValoresPermFactCostMTEC ValoresPermFactCostNFUN ValoresPermFactCostSCOM ValoresPermFactCostTOOL ValoresPermFactCostCOMP ValoresPermFactCostNFOR ValoresPermFactCostNDEP ValoresPermFactCostDOCU ValoresPermFactCostSITE ValoresPermFactCostMFAM ValoresPermFactCostKDAT ValoresPermFactCostADIR CodigoTamProyectoSelecc GenTodosFactCostoAzar ExportarDatos ValoresConfigFactCostNTAB ValoresConfigFactCostNTUP ValoresConfigFactCostNATR ValoresConfigFactCostDISP ValoresConfigFactCostPNUL ValoresConfigFactCostDMOD ValoresConfigFactCostDEXT ValoresConfigFactCostNMOD ValoresConfigFactCostTMOD ValoresConfigFactCostMTUP ValoresConfigFactCostMATRn ValoresConfigFactCostMATRt ValoresConfigFactCostMTEC ValoresConfigFactCostNFUN Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Boolean Boolean Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of Ing. Pablo Pytel 321 Diseño del Sistema de Información (Segundo Ciclo)

322 Clase Atributos Tipo ArchExp ProyEstimados ValoresConfigFactCostSCOM ValoresConfigFactCostTOOL ValoresConfigFactCostCOMP ValoresConfigFactCostNFOR ValoresConfigFactCostNDEP ValoresConfigFactCostDOCU ValoresConfigFactCostSITE ValoresConfigFactCostMFAM ValoresConfigFactCostKDAT ValoresConfigFactCostADIR NombreArchExp DividirArchivoFilas CantMaxFilasArchivo SobrescribirArchivo EstadoArchivo ProyectoNumeroID ValorFactCostNTAB ValorFactCostNTUP ValorFactCostNATR ValorFactCostDISP ValorFactCostPNUL ValorFactCostDMOD ValorFactCostDEXT ValorFactCostNMOD ValorFactCostTMOD ValorFactCostMTUP ValorFactCostMATRn ValorFactCostMATRt ValorFactCostMTEC ValorFactCostNFUN ValorFactCostSCOM ValorFactCostTOOL Array of Array of Array of Array of Array of Array of Array of Array of Array of Array of String(256) Boolean Int Boolean Int Ing. Pablo Pytel 322 Diseño del Sistema de Información (Segundo Ciclo)

323 Clase Atributos Tipo ValorFactCostCOMP ValorFactCostNFOR ValorFactCostNDEP ValorFactCostDOCU ValorFactCostSITE ValorFactCostMFAM ValorFactCostKDAT ValorFactCostADIR EstimCalculados23FactCosto EstimCalculados8FactCosto Double Double Tabla SDSI 7: Atributos de las clases Por último, fue necesario definir el conjunto de restricciones que se les deben dar a los valores de los atributos de acuerdo a su significado y utilización en el sistema software. Estas restricciones en la forma de valores permitidos se muestran en la tabla SDSI 8, la cual está ordenada alfabéticamente por el nombre del atributo. Atributos Tipo Valores Permitidos CantMaxFilasArchivo CantProyectosGenerados CodigoFactCosto CodigoModoGeneracion Int Int String Cualquier valor mayor a 200 y menor al largo permitido por el tipo de dato. Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. Cualquiera de los siguientes valores: ( "NTAB", "NTUP", "NATR", "DISP", "PNUL", "DMOD", "DEXT", "NMOD", "TMOD", "MTUP", "MATRn", "MATRt", "MTEC", "NFUN", "SCOM", "TOOL", "COMP", "NFOR", "NDEP", "DOCU", "SITE", "MFAM", "KDAT", "ADIR") Cualquiera de los siguientes valores: (1, 2, 3). Dónde: 1 = Modo Calcular Costo para un proyecto. 2 = Modo Evaluación Continua. 3 = Análisis Completo. Ing. Pablo Pytel 323 Diseño del Sistema de Información (Segundo Ciclo)

324 Atributos Tipo Valores Permitidos CodigoTamProyectoSelecc Cualquiera de los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Proyecto Tamaño Pequeño 2 = Proyecto Tamaño Mediano 3 = Proyecto Tamaño Grande 3 = Proyecto Tamaño Aleatorio DividirArchivoFilas Boolean Cualquiera de los siguientes valores: (Verdadero, Falso) EstadoArchivo Cualquiera de los siguientes valores: (1, 2, 3) Dónde: 1 = No Definido 2 = Abierto 3 = Cerrado EstimCalculados23FactCosto Double Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. EstimCalculados8FactCosto Double Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. ExportarDatos Boolean (Verdadero, Falso) GenFactCostoAzar Boolean (Verdadero, Falso) GenTodosFactCostoAzar Boolean (Verdadero, Falso) MediaEstimCalculados23FactCosto Double Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. MediaEstimCalculados8FactCosto Double Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. NombreArchExp String(256) Cualquier cadena de caracteres hasta 256 caracteres de largo. ProyectoNumeroID Int Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. SobrescribirArchivo Boolean (Verdadero, Falso) TipoVisualizacionSeleccionada Cualquiera de los siguientes valores: (1, 2, 3, 4, 5, 6, 7) Dónde: 1 = Visualizar gráficos de factores de costo con categoría Datos. 2 = Visualizar gráficos de factores de costo con categoría Modelos. 3 = Visualizar gráficos de factores de costo con categoría Plataforma. 4 = Visualizar gráficos de factores de costo con categoría Técnicas y Herramientas. 5 = Visualizar gráficos de factores de costo con categoría Proyecto. 6 = Visualizar gráficos de factores de costo con categoría Personal. Ing. Pablo Pytel 324 Diseño del Sistema de Información (Segundo Ciclo)

325 Atributos Tipo Valores Permitidos UltEstimCalculados23FactCosto UltEstimCalculados8FactCosto ValoresConfigFactCostADIR ValoresConfigFactCostCOMP ValoresConfigFactCostDEXT ValoresConfigFactCostDISP ValoresConfigFactCostDMOD Double Double Array of Array of Array of Array of Array of 7 = Visualizar tabla de datos generados y calculados. Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. Cualquier valor mayor o igual a cero que sea permitido por el tipo de dato. Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Ing. Pablo Pytel 325 Diseño del Sistema de Información (Segundo Ciclo)

326 Atributos Tipo Valores Permitidos ValoresConfigFactCostDOCU ValoresConfigFactCostKDAT ValoresConfigFactCostMATRn ValoresConfigFactCostMATRt ValoresConfigFactCostMFAM ValoresConfigFactCostMTEC Array of Array of Array of Array of Array of Array of 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5, 6) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) Ing. Pablo Pytel 326 Diseño del Sistema de Información (Segundo Ciclo)

327 Atributos Tipo Valores Permitidos ValoresConfigFactCostMTUP ValoresConfigFactCostNATR ValoresConfigFactCostNDEP ValoresConfigFactCostNFOR ValoresConfigFactCostNFUN Array of Array of Array of Array of Array of 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) ValoresConfigFactCostNMOD Array of Lista que puede contener uno, más de uno Ing. Pablo Pytel 327 Diseño del Sistema de Información (Segundo Ciclo)

328 Atributos Tipo Valores Permitidos ValoresConfigFactCostNTAB ValoresConfigFactCostNTUP ValoresConfigFactCostPNUL ValoresConfigFactCostSCOM ValoresConfigFactCostSITE o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Array of Array of Array of Array of Array of Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: Ing. Pablo Pytel 328 Diseño del Sistema de Información (Segundo Ciclo)

329 Atributos Tipo Valores Permitidos ValoresConfigFactCostTMOD ValoresConfigFactCostTOOL ValoresPermFactCostADIR ValoresPermFactCostCOMP ValoresPermFactCostDEXT Array of Array of Array of Array of Array of 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) Ing. Pablo Pytel 329 Diseño del Sistema de Información (Segundo Ciclo)

330 Atributos Tipo Valores Permitidos ValoresPermFactCostDISP ValoresPermFactCostDMOD ValoresPermFactCostDOCU ValoresPermFactCostKDAT ValoresPermFactCostMATRn ValoresPermFactCostMATRt Array of Array of Array of Array of Array of Array of 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Ing. Pablo Pytel 330 Diseño del Sistema de Información (Segundo Ciclo)

331 Atributos Tipo Valores Permitidos ValoresPermFactCostMFAM ValoresPermFactCostMTEC ValoresPermFactCostMTUP ValoresPermFactCostNATR ValoresPermFactCostNDEP Array of Array of Array of Array of Array of Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5, 6) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) Ing. Pablo Pytel 331 Diseño del Sistema de Información (Segundo Ciclo)

332 Atributos Tipo Valores Permitidos ValoresPermFactCostNFOR ValoresPermFactCostNFUN ValoresPermFactCostNMOD ValoresPermFactCostNTAB ValoresPermFactCostNTUP Array of Array of Array of Array of Array of 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Ing. Pablo Pytel 332 Diseño del Sistema de Información (Segundo Ciclo)

333 Atributos Tipo Valores Permitidos ValoresPermFactCostPNUL ValoresPermFactCostSCOM ValoresPermFactCostSITE ValoresPermFactCostTMOD ValoresPermFactCostTOOL Array of Array of Array of Array of Array of Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Lista que puede contener uno, más de uno o todos los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Ing. Pablo Pytel 333 Diseño del Sistema de Información (Segundo Ciclo)

334 Atributos Tipo Valores Permitidos ValorFactCostADIR ValorFactCostCOMP ValorFactCostDEXT ValorFactCostDISP ValorFactCostDMOD ValorFactCostDOCU Cualquiera de los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Cualquiera de los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (0, 1, 2, 3, 4, 5) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Ing. Pablo Pytel 334 Diseño del Sistema de Información (Segundo Ciclo)

335 Atributos Tipo Valores Permitidos ValorFactCostKDAT ValorFactCostMATRn ValorFactCostMATRt ValorFactCostMFAM ValorFactCostMTEC ValorFactCostMTUP Cualquiera de los siguientes valores: (1, 2, 3, 4) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5, 6) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Ing. Pablo Pytel 335 Diseño del Sistema de Información (Segundo Ciclo)

336 Atributos Tipo Valores Permitidos ValorFactCostNATR ValorFactCostNDEP ValorFactCostNFOR ValorFactCostNFUN ValorFactCostNMOD ValorFactCostNTAB Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (2, 3, 4, 5) Dónde: 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Ing. Pablo Pytel 336 Diseño del Sistema de Información (Segundo Ciclo)

337 Atributos Tipo Valores Permitidos ValorFactCostNTUP ValorFactCosto ValorFactCostPNUL ValorFactCostSCOM ValorFactCostSITE ValorFactCostTMOD Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (0, 1, 2, 3, 4, 5, 6) Dónde: 0 = Extra Bajo (XB) 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) 6 = Extra Alto (EA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) Ing. Pablo Pytel 337 Diseño del Sistema de Información (Segundo Ciclo)

338 Atributos Tipo Valores Permitidos ValorFactCostTOOL 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Cualquiera de los siguientes valores: (1, 2, 3, 4, 5) Dónde: 1 = Muy Bajo (MB) 2 = Bajo (B) 3 = Nominal (N) 4 = Alto (A) 5 = Muy Alto (MA) Tabla SDSI 8: Restricciones en los valores de los atributos IDENTIFICACIÓN DE OPERACIONES DE LAS CLASES Esta tarea tiene como objetivo definir, de forma detallada, las operaciones de cada clase de diseño. Para ello, se tomó como punto de partida el modelo de clases generado en el análisis del segundo ciclo de desarrollo, así como el diseño de los casos de uso reales y los requisitos de diseño que aparecieron al definir el entorno de desarrollo del primer y segundo ciclo. Cada una de las operaciones de las clases de diseño surge 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. En caso de identificar operaciones de objetos que presentan distintos estados, donde 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 Como fue realizado en el primer ciclo de desarrollo, esta tarea tiene en cuenta la siguiente distinción para el análisis de los métodos de las clases identificadas Métodos Triviales, lo cuales son utilizados para instanciar / eliminar un objeto o para leer / escribir valores en los atributos de un objeto (denominados comúnmente Ing. Pablo Pytel 338 Diseño del Sistema de Información (Segundo Ciclo)

339 como getters y setters). Dependiendo del lenguaje en que se implemente, pueden ser implementados automáticamente por el lenguaje, por tal motivo, estos métodos no fueron documentados para facilitar el entendimiento del modelo. Métodos No Triviales, los cuales incluyen aquellos métodos que modelan e implementa reglas de negocio y de comportamiento de las clases del sistema. Estos métodos si fueron diseñados y explicados en las tablas SDSI 9 a SDSI 13. Clase ProcProyectos Método Tipo Descripción Comenzar Finalizar Público Parámetros Resultado Público Parámetros --- Resultado Comienza a procesar los proyectos de acuerdo a al modo seleccionado y suministrado como parámetro al método. CodigoModoGeneracion: ProcesoFinalizadoConExito: Boolean ListaProyEstimados: Array of ProyEstimados Finaliza la ejecución del procesamiento de proyectos. Este método sólo es utilizado si se selecciona el modo de Evaluación Continua. ProcesoFinalizadoConExito: Boolean ListaProyEstimados: Array of ProyEstimados Tabla SDSI 9: Descripción de los métodos de la clase ProcProyectos Clase GenProyectos Método Tipo Descripción Generar Público Parámetros Resultado Genera aleatoriamente los datos de un proyecto de acuerdo a la configuración suministrada. configfactcosto: ParamFactCosto ProcesoFinalizadoConExito: Boolean ValorFactCostNTAB: ValorFactCostNTUP: ValorFactCostNATR: ValorFactCostDISP: ValorFactCostPNUL: ValorFactCostDMOD: ValorFactCostDEXT: ValorFactCostNMOD: ValorFactCostTMOD: ValorFactCostMTUP: ValorFactCostMATRn: Ing. Pablo Pytel 339 Diseño del Sistema de Información (Segundo Ciclo)

340 Clase GenProyectos Método Tipo Descripción ValorFactCostMATRt: ValorFactCostMTEC: ValorFactCostNFUN: ValorFactCostSCOM: ValorFactCostTOOL: ValorFactCostCOMP: ValorFactCostNFOR: ValorFactCostNDEP: ValorFactCostDOCU: ValorFactCostSITE: ValorFactCostMFAM: ValorFactCostKDAT: ValorFactCostADIR: Tabla SDSI 10: Descripción de los métodos de la clase GenProyectos Clase CalcCostosEstimados Método Tipo Descripción Calcular23FactCosto Público Parámetros Calcula el costo estimado del proyecto utilizando los 23 factores de costo del método DMCoMo. ValorFactCostNTAB: ValorFactCostNTUP: ValorFactCostNATR: ValorFactCostDISP: ValorFactCostPNUL: ValorFactCostDMOD: ValorFactCostDEXT: ValorFactCostNMOD: ValorFactCostTMOD: ValorFactCostMTUP: ValorFactCostMATRn: ValorFactCostMATRt: ValorFactCostMTEC: ValorFactCostNFUN: ValorFactCostSCOM: ValorFactCostTOOL: ValorFactCostCOMP: ValorFactCostNFOR: ValorFactCostNDEP: ValorFactCostDOCU: Ing. Pablo Pytel 340 Diseño del Sistema de Información (Segundo Ciclo)

341 Clase CalcCostosEstimados Método Tipo Descripción Calcular8FactCosto Resultado Público Parámetros Resultado ValorFactCostSITE: ValorFactCostMFAM: ValorFactCostKDAT: ValorFactCostADIR: ProcesoFinalizadoConExito: Boolean CostoEstimado:Double Calcula el costo estimado del proyecto utilizando los 23 factores de costo del método DMCoMo. ValorFactCostNTAB: ValorFactCostNATR: ValorFactCostDISP: ValorFactCostDEXT: ValorFactCostTMOD: ValorFactCostMATRn: ValorFactCostMATRt: ValorFactCostNFOR: ValorFactCostMFAM: ProcesoFinalizadoConExito: Boolean CostoEstimado: Double Tabla SDSI 11: Descripción de los métodos de la clase CalcCostosEstimados Clase ParamTamProyecto Método Tipo Descripción ObtenerValPermitidos Público Parámetros Resultado Permite obtener los valores permitidos de los factores de costo a partir de un tamaño de proyecto seleccionado. CodigoTamProyectoSelecc: ProcesoFinalizadoConExito: Boolean ValoresPermFactCostNTAB:Array of ValoresPermFactCostNTUP: Array of ValoresPermFactCostNATR: Array of ValoresPermFactCostDISP: Array of ValoresPermFactCostPNUL: Array of ValoresPermFactCostDMOD: Array of ValoresPermFactCostDEXT: Array of ValoresPermFactCostNMOD: Array of ValoresPermFactCostTMOD: Array of ValoresPermFactCostMTUP: Array of ValoresPermFactCostMATRn: Array of Ing. Pablo Pytel 341 Diseño del Sistema de Información (Segundo Ciclo)

342 Clase ParamTamProyecto Método Tipo Descripción ObtenerTodasComb Público Parámetros Resultado ValoresPermFactCostMATRt: Array of ValoresPermFactCostMTEC: Array of ValoresPermFactCostNFUN: Array of ValoresPermFactCostSCOM: Array of ValoresPermFactCostTOOL: Array of ValoresPermFactCostCOMP: Array of ValoresPermFactCostNFOR: Array of ValoresPermFactCostNDEP: Array of ValoresPermFactCostDOCU: Array of ValoresPermFactCostSITE: Array of ValoresPermFactCostMFAM: Array of ValoresPermFactCostKDAT: Array of ValoresPermFactCostADIR: Array of Permite obtener todas las combinaciones de los valores permitidos de los factores de costo a partir de un tamaño de proyecto seleccionado. CodigoTamProyectoSelecc: ProcesoFinalizadoConExito: Boolean CombTodosValores:Array of {Array of } Tabla SDSI 12: Descripción de los métodos de la clase ParamTamProyecto Clase ArchExp Método Tipo Descripción CrearArchivo GrabarProyEstimado Público Parámetros Resultados Público Parámetros Genera el archivo que se va a utilizar para exportar los datos. NombreArchExp: String(256) SobreescribirExistente: Boolean ArchivoCreadoConExito: Boolean Graba en el archivo de exportación una línea con los datos del proyecto generado y procesado. ProyectoNumeroID:Int ValorFactCostNTAB: ValorFactCostNTUP: ValorFactCostNATR: ValorFactCostDISP: ValorFactCostPNUL: ValorFactCostDMOD: ValorFactCostDEXT: ValorFactCostNMOD: Ing. Pablo Pytel 342 Diseño del Sistema de Información (Segundo Ciclo)

343 Clase ArchExp Método Tipo Descripción CerrarArchivo Resultado Público Parámetros - Resultados ValorFactCostTMOD: ValorFactCostMTUP: ValorFactCostMATRn: ValorFactCostMATRt: ValorFactCostMTEC: ValorFactCostNFUN: ValorFactCostSCOM: ValorFactCostTOOL: ValorFactCostCOMP: ValorFactCostNFOR: ValorFactCostNDEP: ValorFactCostDOCU: ValorFactCostSITE: ValorFactCostMFAM: ValorFactCostKDAT: ValorFactCostADIR: EstimCalculados23FactCosto:Double EstimCalculados8FactCosto:Double ProyectoGrabadoConExito: Boolean Indica que se finaliza la exportación de datos al archivo. ArchivoCerradoConExito: Boolean Tabla SDSI 13: Descripción de los métodos de la clase ArchExp Finalmente, para la clase ArchExp se definió un el diagrama de transición de estados ya que su comportamiento puede variar de acuerdo al estado. En el diagrama de la figura SDSI 10 se puede ver como se modifican los estados considerando las operaciones definidas en la tabla SDSI 13. Ing. Pablo Pytel 343 Diseño del Sistema de Información (Segundo Ciclo)

344 Figura SDSI 10: Diagrama de transición de estados de la clase ArchExp DIAGRAMA DE CLASES DE DISEÑO A continuación, en las figuras SDSI 11, SDSI 12 y SDSI 13 se describen los diagramas de clases en formato UML correspondientes a cada uno de los paquetes de Clases de Dominio, Clases de Procesos y Clases de Interfaz de Usuario respectivamente: Nota: Debido a la gran cantidad de atributos que tienen estas clases, aquí fueron omitidos en su representación, complementando entonces al gráfico la tabla SDSI 7. Ing. Pablo Pytel 344 Diseño del Sistema de Información (Segundo Ciclo)

345 a. Diagrama de clases para las Clases de Dominio: Figura SDSI 11: Diagrama de clases del Paquete de Dominio b. Diagrama de clases para las Clases de Proceso: ConfigParametros ConfigFactCostos ConfigArchExp MostrarResultados ProcProyectos Calcular23FactCosto Generar GenProyectos CalcCostosEstimados Calcular8FactCosto Figura SDSI 12: Diagrama de clases del Paquete de Proceso Ing. Pablo Pytel 345 Diseño del Sistema de Información (Segundo Ciclo)

346 c. Diagrama de Clases de Interfaz de Usuario Figura SDSI 13: Diagrama de clases del Paquete de Interfaz de Usuario En este caso, por un tema de unificación de criterios de modelado, las clases de interfaz fueron representadas como clases, pero no recibieron una implementación directamente como clases, sino que fueron implementadas a través de formularios de Java ESPECIFICACIÓN DE NECESIDADES DE MIGRACIÓN Y CARGA INICIAL DE DATOS Esta tarea tiene como objetivo realizar 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 Debido a que en este sistema software no utiliza ninguna base de datos, no hace falta cargar datos. Por lo tanto, no fue necesaria la carga inicial ni la migración de los mismos para el funcionamiento del sistema. 9.5 DISEÑO FÍSICO DE DATOS Esta actividad se ocupa de definir la estructura física de datos que utiliza el sistema, a partir del modelo lógico de datos normalizado o modelo de clases. Teniendo presentes las características específicas del sistema de gestión de datos concretos a utilizar, los requisitos establecidos para el sistema software, y las particularidades del entorno tecnológico, se consiga una mayor eficiencia en el tratamiento de los datos. Ing. Pablo Pytel 346 Diseño del Sistema de Información (Segundo Ciclo)

347 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 DISEÑO DEL MODELO FÍSICO DE DATOS Como ya se ha mencionado, en este sistema software no se cuenta con Base de Datos, por lo que simplemente, en este ciclo de desarrollo sólo se estableció el tipo de archivo básico que se maneja para exportar los datos generados. Formato: Estos archivos son de texto con la información separada por punto y coma ( ; ) y saltos de línea ( End-of-Line o EOL ). Datos en el Archivo: El formato del archivo es el siguiente: - La primera línea tendrá como título, los nombres de los campos exportados (o sea, número de proyecto generado, nombre de los factores de costo y tipo de fórmula usada para calcular el valor estimado) separados por punto y coma ( ; ). - Las líneas restantes tendrán los valores correspondientes para los proyectos procesados separados por punto y coma ( ; ). Por ejemplo, los siguientes son ejemplos de las primeras dos líneas de un archivo de exportación: Nro Proyecto;NTAB;NTUP;NATR;DISP;PNUL;DMOD;DEXT;NMOD;TMOD;MTUP;MATRn; MATRt; MATR; MTEC;NFUN;SCOM;TOOL;COMP;NFOR;NDEP;DOCU;SITE;KDAT;ADIR; MFAM;MM23;MM8 1;6;5;5;5;5;4;5;5;5;5;5;5;5;5;4;5;5;4;5;5;5;6;4;4;5;164.2; ;0;1;1;1;1;3;2;2;3;2;2;4;3;3;2;3;4;3;5;2;4;1;2;2;3;65.76;90.58 Ing. Pablo Pytel 347 Diseño del Sistema de Información (Segundo Ciclo)

348 9.6 VERIFICACIÓN Y ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA Esta actividad tiene el objetivo de garantizar la calidad de las especificaciones del diseño del sistema software y su viabilidad, para poder luego comenzar la generación de las especificaciones de construcción. Las siguientes acciones se realizan para lograr esto: 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 Esta tarea tiene como objetivo asegurar la calidad formal de los modelos de diseño generado, conforme a la técnica utilizada para la elaboración de cada producto y a las normas y estándares especificados Resultado de la Verificación de la Especificación de Diseño Para realizar esta tarea fue verificado los distintos modelos generados junto con los Directores de Tesis. Como resultado de esta tarea fueron realizados modificaciones en los modelos, los cual ya se encuentran aplicados en este trabajo ANÁLISIS DE CONSISTENCIA DE LAS ESPECIFICACIONES DE DISEÑO Esta tarea tiene como objetivo asegurar que las especificaciones del diseño sean coherentes entre sí, es decir que no existen ambigüedades ni duplicación de información. Para ello se revisa la consistencia entre especificaciones de diseño con respecto a los modelos del análisis. Para realizar las diferentes comprobaciones se utilizan generalmente técnicas matriciales o de revisión entre los elementos comunes de los distintos modelos. Este análisis de consistencia relativo a la arquitectura del sistema es común para desarrollo estructurado y para el 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 Para realizar el análisis de consistencia se comprobó la coherencia entre los distintos modelos para el segundo ciclo de desarrollo de acuerdo a las trazabilidades indicadas durante el primer ciclo de desarrollo. Ing. Pablo Pytel 348 Diseño del Sistema de Información (Segundo Ciclo)

349 a. Clases Asociadas a los Casos de Uso vs Clases de Interfaz de Usuario / Clases de Proceso / Clases de Dominio Se realizó la comparación de las clases de diseño asociadas a los casos, comparándolas con las clases de los tres paquetes (Paquete de Clases de Interfaz de Usuario, Paquete de Clases de Proceso y Paquete de Clases de Dominio). Para ello se completan dos matrices: - Primero en la matriz de la tabla SDSI 14 se colocan en las filas se listan las clases de cada paquete y en las columnas los casos de uso, así por cada intersección se indica que casos de uso utilizan cada clase. - Por otro lado, en la matiz de la tabla SDSI 15 donde en las filas se listan las clases asociadas a los casos de uso y en las columnas los tres paquetes, así por cada intersección se indica a que paquete pertenece cada clase. Como se puede observar de ambas matrices, existe al menos una relación entre ambas clases. Clases asociadas a los Paquetes / Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados ParamGral X X X Paquete de Clases de Dominios ParamTamProyecto X X ParamFactCost X X X ArchExp X X ProyEstimados X X ConfigParametros X Paquete ConfigFactCostos X de Clases ConfigArchExp X de Procesos ProcProyectos X GenProyectos X Ing. Pablo Pytel 349 Diseño del Sistema de Información (Segundo Ciclo)

350 Clases asociadas a los Paquetes / Casos de Uso Configurar Parámetros Configurar Factores de Costo del Proyecto Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados CalcCostosEstimados X MostrarResultados X IUPrincipal X X X X Paquete IUConfigParametros X X de clases de Interfaz de Usuario IUConfigFactCostos IUProcProyectos IUMostrarResultados X X X Tabla SDSI 14: Trazabilidades entre Clases de Interfaz de Usuario / Clases de Proceso / Clases de Dominio vs. los Casos de Uso Clases asociadas a los Casos de Uso / Paquetes Paquete de Clases de Dominios Paquete de Clases de Procesos Paquete de clases de Interfaz de Usuario ParamGral X ParamTamProyecto X Caso de uso Configurar Parámetros ParamFactCosto ConfigParametros X X IUPrincipal X IUConfigParametros X Caso de uso ArchExp X Configurar Archivo de ConfigArchExp X Exportación IUConfigParametros X Ing. Pablo Pytel 350 Diseño del Sistema de Información (Segundo Ciclo)

351 Clases asociadas a los Casos de Uso / Paquetes Paquete de Clases de Dominios Paquete de Clases de Procesos Paquete de clases de Interfaz de Usuario ParamGral X Caso de uso ParamTamProyecto X Configurar Factores de Costo del ParamFactCosto ConfigFactCostos X X Proyecto IUPrincipal X IUConfigFactCostos X ParamGral X ParamFactCosto X ArchExp X Caso de uso ProyEstimados X Generar Proyectos ProcProyectos X Estimados GenProyectos X CalcCostosEstimados X IUPrincipal X IUProcProyectos X Caso de uso ProyEstimados X Mostrar Resultados de Proyectos MostrarResultados IUPrincipal X X Estimados IUMostrarResultados X Tabla SDSI 15: Trazabilidades entre Clases Asociadas a los Casos de Uso versus Clases de Interfaz de Usuario / Clases de Proceso / Clases de Dominio Ing. Pablo Pytel 351 Diseño del Sistema de Información (Segundo Ciclo)

352 b. Clases de Interfaz de Usuario vs Pantalla de la fase de Análisis revisadas Para realizar esta verificación se completó la matriz de la tabla SDSI 16 que contiene dos columnas: a la izquierda, se describen las clases de paquetes de Clases de Interfaz de Usuario y, en la columna de la derecha las pantallas de la fase de análisis revirevisadas durante el diseño. Como se puede observar existe una relación uno a uno entre ambos componentes: Clases de Interfaz de Usuario IUPrincipal IUConfigParametros IUConfigFactCostos IUProcProyectos IUMostrarResultados Pantallas Revisadas Pantalla Principal (Menú Principal) Configurar Parámetros Configurar Factores de Costo Generar Proyectos Estimados Mostrar Resultados Tabla SDSI 16: Trazabilidades entre las Clases de Interfaz de Usuario y las Pantallas Revisadas ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA CORRESPONDIENTE AL SEGUNDO CICLO DE DESARROLLO Esta tarea tiene el objetivo de obtener la aceptación de la arquitectura del sistema software y de los requisitos de operación y seguridad, por parte de las áreas de explotación y sistemas, con el fin de poder valorar su impacto en la instalación. Luego de reunión mantenida entre el tesista y los directores del proyecto de tesis se dio por aprobada la arquitectura del sistema software para el segundo ciclo de desarrollo. 9.7 ESPECIFICACIÓN TÉCNICA DEL PLAN DE PRUEBAS Esta actividad tiene el objetivo de especificar el detalle del plan de pruebas del sistema software del segundo ciclo de desarrollo considerando el plan ya definido durante el Diseño del primer ciclo de desarrollo y las modificaciones de los modelos de diseño para el segundo ciclo de desarrollo. Por lo tanto el Entorno de Pruebas definido durante el primer ciclo de desarrollo (sección 6.9.1) no se modifica. Ing. Pablo Pytel 352 Diseño del Sistema de Información (Segundo Ciclo)

353 9.7.1 REVISIÓN DE LA PLANIFICACIÓN DE PRUEBAS Esta tarea tiene como objetivo completar y especificar la planificación de las pruebas, contemplando las modificaciones del segundo ciclo de desarrollo para definir las pruebas Unitarias y del Sistema para este ciclo Pruebas Unitarias Para el segundo ciclo de desarrollo del sistema software fueron identificados dos componentes que serán probados en forma independiente. Primero se decidió volver a verificar el correcto funcionamiento del componente Calc- CostosEstimados del caso de uso Generar los Proyectos Estimados a través de las pruebas unitarias ya definidas para el primer ciclo de desarrollo las cuales fueron utilizadas nuevamente para asegurar que por introducir nuevas funcionalidades al sistema software este componente no fue afectado. Por otro lado, se verificó el componente ConfigArchExp del caso de uso Configurar Archivo de Exportación. Estas pruebas tuvo el objetivo de verificar el correcto de la generación de los archivos de exportación sobre todo considerando los casos de excepción (identificados en la sección ). Para ello fueron probadas las situaciones donde no es posible configurar el archivo de exportación por los problemas de excepción detectadas. Las pruebas correspondientes a la generación satisfactorias de los archivos de exportación se realizaron durante las pruebas del sistema. En la siguiente tabla SDSI 17 se listan los casos de prueba unitarias que se realizaron: Código CP-001 CP-002 CP-003 CP-004 Componente (Caso de Uso) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) Objetivo Calcular los costos estimados para un proyecto de tamaño pequeño. Calcular los costos estimados para un proyecto de tamaño mediano. Calcular los costos estimados para un proyecto de tamaño grande. Calcular los costos estimados para un proyecto de tamaño aleatorio (o sea, sin restricción en los valores a utilizar). CP-005 CalcCostosEstimados Calcular los costos estimados para un pro- Ing. Pablo Pytel 353 Diseño del Sistema de Información (Segundo Ciclo)

354 Código CP-006 CP-011 CP-012 CP-013 CP-014 CP-015 Componente (Caso de Uso) (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) ConfigArchExp (Configurar Archivo de Exportación) ConfigArchExp (Configurar Archivo de Exportación) ConfigArchExp (Configurar Archivo de Exportación) ConfigArchExp (Configurar Archivo de Exportación) ConfigArchExp (Configurar Archivo de Exportación) Tabla SDSI 17: Caso de Pruebas Unitarias Objetivo yecto de tamaño aleatorio variando sólo uno de los factores de costo que afecta ambas fórmulas. Calcular los costos estimados para un proyecto de tamaño aleatorio variando sólo uno de los factores de costo que afecta sólo a una de las fórmulas. Intentar crear un archivo nuevo de exportación sin permisos en el directorio de trabajo. Intentar crear un archivo nuevo de exportación sin espacio en disco disponible. Intentar modificar un archivo existente de exportación sin permisos en el directorio de trabajo. Intentar modificar un archivo existente de exportación sin espacio en disco disponible. Intentar modificar un archivo existente de exportación que se encuentra abierto por otra aplicación. Se describen en detalle los casos de prueba unitarias en las tablas SDSI 18 a SDSI 28. Código Objetivo Entrada CP-001 Calcular los costos estimados para un proyecto de tamaño pequeño. Proyecto de tamaño Pequeño. Los factores de costo utilizados son: NTAB = 0 NTUP = 1 NATR = 1 DISP = 1 PNUL = 1 DMOD = 0 DEXT = 2 NMOD = 2 TMOD = 1 MTUP = 1 MATRn = 1 MATRt = 2 Ing. Pablo Pytel 354 Diseño del Sistema de Información (Segundo Ciclo)

355 Código Salida Condiciones Pre-requisitos MTEC = 1 NFUN = 2 SCOM = 1 TOOL = 2 COMP = 0 NFOR = 2 NDEP = 2 DOCU = 2 SITE = 1 KDAT = 1 ADIR = 1 MFAM = 1 Los valores estimados son: CP-001 Fórmula de 23 factores de costo = 94,41 Fórmula de 8 factores de costo = 89,53 No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Pequeño Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla SDSI 18: Caso de Pruebas CP-001 Código Objetivo CP-002 Calcular los costos estimados para un proyecto de tamaño mediano. Ing. Pablo Pytel 355 Diseño del Sistema de Información (Segundo Ciclo)

356 Código Entrada Salida Condiciones Pre-requisitos CP-002 Proyecto de tamaño Mediano. Los factores de costo utilizados son: NTAB = 2 NTUP = 2 NATR = 2 DISP = 2 PNUL = 2 DMOD = 0 DEXT = 2 NMOD = 3 TMOD = 1 MTUP = 1 MATRn = 3 MATRt = 2 MTEC = 1 NFUN = 3 SCOM = 2 TOOL = 2 COMP = 0 NFOR = 2 NDEP = 2 DOCU = 2 SITE = 1 KDAT = 1 ADIR = 1 MFAM = 1 Los valores estimados son: Fórmula de 23 factores de costo = 125,20 Fórmula de 8 factores de costo = 106,56 No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Mediano Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Ing. Pablo Pytel 356 Diseño del Sistema de Información (Segundo Ciclo)

357 Tabla SDSI 19: Caso de Pruebas CP-002 Código Objetivo Entrada Salida CP-003 Calcular los costos estimados para un proyecto de tamaño grande. Proyecto de tamaño Grande. Los factores de costo utilizados son: NTAB = 5 NTUP = 4 NATR = 3 DISP = 4 PNUL = 4 DMOD = 3 DEXT = 4 NMOD = 4 TMOD = 1 MTUP = 4 MATRn = 4 MATRt = 4 MTEC = 3 NFUN = 4 SCOM = 4 TOOL = 4 COMP = 3 NFOR = 3 NDEP = 4 DOCU = 4 SITE = 4 KDAT = 3 ADIR = 1 MFAM = 1 Los valores estimados son: Fórmula de 23 factores de costo = 159,02 Fórmula de 8 factores de costo = 132,33 Condiciones Pre-requisitos No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. Ing. Pablo Pytel 357 Diseño del Sistema de Información (Segundo Ciclo)

358 Código CP-003 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla SDSI 20: Caso de Pruebas CP-003 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-004 Calcular los costos estimados para un proyecto de tamaño aleatorio (o sea, sin restricciones en los valores). Proyecto de tamaño Aleatorio. Los factores de costo utilizados son: NTAB = 1 NTUP = 2 NATR = 3 DISP = 3 PNUL = 4 DMOD = 1 DEXT = 2 NMOD = 4 TMOD = 1 MTUP = 1 MATRn = 4 MATRt = 4 MTEC = 1 NFUN = 2 SCOM = 4 TOOL = 4 COMP = 3 NFOR = 1 NDEP = 4 DOCU = 2 SITE = 4 KDAT = 1 ADIR = 4 MFAM = 5 Los valores estimados son: Fórmula de 23 factores de costo = 104,13 Fórmula de 8 factores de costo = 107,22 No posee No posee Procedimiento 1) Se ejecuta el sistema software. Ing. Pablo Pytel 358 Diseño del Sistema de Información (Segundo Ciclo)

359 Código CP-004 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla SDSI 21: Caso de Pruebas CP-004 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-005 Calcular los costos estimados para un proyecto de tamaño aleatorio variando sólo uno de los factores de costo que afecta ambas fórmulas. Los factores de costo utilizados son los mismos del caso de prueba CP-004, salvo: NTAB = 3 Los valores estimados son: Fórmula de 23 factores de costo = 109,73 Fórmula de 8 factores de costo = 111,96 No posee Se acaba de ejecutar satisfactoriamente el caso de prueba CP-004. Procedimiento 1) Se modifica el valor del factor de costo NTAB utilizando el valor definido en <Entrada> 2) Se selecciona la opción Generar Proyectos Estimados. 3) Se ejecuta con el modo Calcular costo para un proyecto. 4) Se compara los resultados obtenidos con los valores definidos en <Salida>. Tabla SDSI 22: Caso de Pruebas CP-005 Código Objetivo Entrada CP-006 Calcular los costos estimados para un proyecto de tamaño aleatorio variando sólo uno de los factores de costo que afecta sólo a una de las fórmulas. Los factores de costo utilizados son los mismos del caso de prueba CP-004, salvo: SITE = 2 Ing. Pablo Pytel 359 Diseño del Sistema de Información (Segundo Ciclo)

360 Código Salida Condiciones Pre-requisitos CP-006 Los valores estimados son: Fórmula de 23 factores de costo = 105,46 Fórmula de 8 factores de costo = 111,96 No posee Se acaba de ejecutar satisfactoriamente el caso de prueba CP-005. Procedimiento 1) Se modifica el valor del factor de costo SITE utilizando el valor definido en <Entrada> 2) Se selecciona la opción Generar Proyectos Estimados. 3) Se ejecuta con el modo Calcular costo para un proyecto. 4) Se compara los resultados obtenidos con los valores definidos en <Salida>. Note que solamente se modifica el valor de la fórmula de 23 factores de costo, pero la fórmula de 8 factores de costo no varía. Tabla SDSI 23: Caso de Pruebas CP-006 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-011 Intentar crear un archivo nuevo de exportación sin permisos en el directorio de trabajo. Proyecto de tamaño Aleatorio. Nombre del archivo prueba.csv Se muestra un mensaje de error. No posee El archivo prueba.csv no existe. El usuario no tiene permisos para escribir en el directorio de trabajo. Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se indica el nombre del archivo de exportación definido en <Entrada> y se elige la opción Crear. 4) Se muestra en pantalla el mensaje de error indicando que el archivo seleccionado no se puede crear para exportar los datos. Tabla SDSI 24: Caso de Pruebas CP-011 Ing. Pablo Pytel 360 Diseño del Sistema de Información (Segundo Ciclo)

361 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-012 Intentar crear un archivo nuevo de exportación sin espacio en disco disponible. Proyecto de tamaño Aleatorio. Nombre del archivo prueba.csv Se muestra un mensaje de error. No posee El archivo prueba.csv no existe. El disco en que se encuentra el directorio de trabajo no tiene espacio disponible. Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se indica el nombre del archivo de exportación definido en <Entrada> y se elige la opción Crear. 4) Se muestra en pantalla el mensaje de error indicando que el archivo seleccionado no se puede crear para exportar los datos. Tabla SDSI 25: Caso de Pruebas CP-012 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-013 Intentar modificar un archivo existente de exportación sin permisos en el directorio de trabajo. Proyecto de tamaño Aleatorio. Nombre del archivo prueba.csv Se muestra un mensaje de error. No posee El archivo prueba.csv ya existe en el directorio de trabajo. El usuario no tiene permisos para escribir en el directorio de trabajo. Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se indica el nombre del archivo de exportación definido en <Entrada> y se elige la opción Crear. Ing. Pablo Pytel 361 Diseño del Sistema de Información (Segundo Ciclo)

362 Código CP-013 4) Se muestra en pantalla el mensaje de error indicando que el archivo seleccionado no se puede crear para exportar los datos. Tabla SDSI 26: Caso de Pruebas CP-013 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-024 Intentar modificar un archivo existente de exportación sin espacio en disco disponible. Proyecto de tamaño Aleatorio. Nombre del archivo prueba.csv Se muestra un mensaje de error. No posee El archivo prueba.csv ya existe en el directorio de trabajo. El disco en que se encuentra el directorio de trabajo no tiene espacio disponible. Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se indica el nombre del archivo de exportación definido en <Entrada> y se elige la opción Crear. 4) Se muestra en pantalla el mensaje de error indicando que el archivo seleccionado no se puede crear para exportar los datos. Tabla SDSI 27: Caso de Pruebas CP-014 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-015 Intentar modificar un archivo existente de exportación que se encuentra abierto por otra aplicación. Proyecto de tamaño Aleatorio. Nombre del archivo prueba.csv Se muestra un mensaje de error. No posee El archivo prueba.csv ya existe en el directorio de trabajo. El archivo se encuentra abierto por Microsoft Excel. Procedimiento 1) Se ejecuta el sistema software. Ing. Pablo Pytel 362 Diseño del Sistema de Información (Segundo Ciclo)

363 Código CP-015 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se indica el nombre del archivo de exportación definido en <Entrada> y se elige la opción Crear. 4) Se muestra en pantalla el mensaje de error indicando que el archivo seleccionado no se puede crear para exportar los datos. Tabla SDSI 28: Caso de Pruebas CP Pruebas de Integración Como ha sucedido durante el primer ciclo de desarrollo y, debido a la estructura y la funcionalidad brindada por el sistema software desarrollado, estas pruebas se realizaron directamente junto con las pruebas del sistema Pruebas del Sistema Las pruebas de sistema tienen como objetivo probar la integración de los casos de uso implementados en la aplicación durante el segundo ciclo de desarrollo así como su integración con otros sistemas. Para poder verificar la interacción entre los casos de uso, se definieron pruebas donde a partir de ciertos parámetros se controlaba que la salida sea igual a la esperada luego de hacer funcionar varios casos de uso. Por otro lado para verificar la interacción con otros sistemas se utilizó el archivo de exportación generado por otras aplicaciones (en este caso, Microsoft Excel). En la siguiente tabla SDSI 29 se listan los casos de prueba del sistema que se realizan para el segundo ciclo de desarrollo: Código Casos de Uso Objetivo CP-201 CP-202 Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Generar un proyecto estimado de tamaño pequeño con factores de costo establecidos. Generar un proyecto estimado de tamaño pequeño con factores de costo aleatorios. Ing. Pablo Pytel 363 Diseño del Sistema de Información (Segundo Ciclo)

364 Código Casos de Uso Objetivo CP-203 CP-204 CP-205 CP-206 CP-207 CP-208 CP-209 CP-210 Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Esti- Generar varios proyectos estimados de tamaño pequeño con factores de costo aleatorios. Generar análisis completo de proyectos estimados de tamaño pequeño con factores de costo aleatorios. Generar un proyecto estimado de tamaño mediano con factores de costo establecidos. Generar un proyecto estimado de tamaño mediano con factores de costo aleatorios. Generar varios proyectos estimados de tamaño mediano con factores de costo aleatorios. Generar análisis completo de proyectos estimados de tamaño mediano con factores de costo aleatorios. Generar un proyecto estimado de tamaño grande con factores de costo establecidos. Generar un proyecto estimado de tamaño grande con factores de costo aleatorios. Ing. Pablo Pytel 364 Diseño del Sistema de Información (Segundo Ciclo)

365 Código Casos de Uso Objetivo mados CP-211 CP-212 CP-213 CP-214 CP-215 CP-216 CP-217 Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados CP-218 Configurar Parámetros Generar varios proyectos estimados de tamaño grande con factores de costo aleatorios. Generar análisis completo de proyectos estimados de tamaño grande con factores de costo aleatorios. Generar un proyecto estimado de tamaño aleatorio con factores de costo establecidos. Generar un proyecto estimado de tamaño aleatorio con factores de costo aleatorios. Generar varios proyectos estimados de tamaño aleatorio con factores de costo aleatorios. Generar análisis completo de proyectos estimados de tamaño aleatorio con factores de costo aleatorios. Generar archivo de exportación para varios proyectos estimados de tamaño aleatorio. Generar archivos particionados de exportación para varios proyectos estimados de Ing. Pablo Pytel 365 Diseño del Sistema de Información (Segundo Ciclo)

366 Código Casos de Uso Objetivo Configurar Archivo de tamaño aleatorio. Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-219 Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Tabla SDSI 29: Caso de Pruebas del Sistema Generar archivos particionados de exportación para el análisis completo de proyectos estimados de tamaño grande con factores de costo aleatorios. A continuación se describen de los casos de prueba del sistema según el orden definido en la tabla SDSI 29. Estos casos de pruebas están de la tabla SDSI 30 a SDSI 48. Código Objetivo Entrada CP-201 Generar un proyecto estimado de tamaño pequeño con factores de costo establecidos. Proyecto de tamaño Pequeño. Los factores de costo utilizados son: NTAB = 0 NTUP = 1 NATR = 1 DISP = 1 PNUL = 1 DMOD = 0 DEXT = 2 NMOD = 2 TMOD = 1 MTUP = 1 MATRn = 1 MATRt = 2 MTEC = 1 NFUN = 2 SCOM = 1 TOOL = 2 COMP = 0 NFOR = 2 NDEP = 2 DOCU = 2 SITE = 1 Ing. Pablo Pytel 366 Diseño del Sistema de Información (Segundo Ciclo)

367 Código Salida Condiciones Pre-requisitos KDAT = 1 ADIR = 1 MFAM = 1 Los valores estimados son: CP-201 Fórmula de 23 factores de costo = 94,41 Fórmula de 8 factores de costo = 89,53 Se muestran en pantalla los valores de costos estimados, gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Pequeño Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 30: Caso de Pruebas CP-201 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-202 Generar un proyecto estimado de tamaño pequeño con factores de costo aleatorios. Proyecto de tamaño Pequeño. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Pequeño Ing. Pablo Pytel 367 Diseño del Sistema de Información (Segundo Ciclo)

368 Código Generar los factores de costo al azar = Si CP-202 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se ven los resultados obtenidos. 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 31: Caso de Pruebas CP-202 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-203 Generar varios proyectos estimados de tamaño pequeño con factores de costo aleatorios. Proyecto de tamaño Pequeño. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Pequeño Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se decide parar el proceso. 5) Se ven los resultados obtenidos y el histograma de los valores calculados 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 32: Caso de Pruebas CP-203 Código Objetivo Entrada Salida CP-204 Generar análisis completo de proyectos estimados de tamaño pequeño con factores de costo aleatorios. Proyecto de tamaño Pequeño. No se muestra el gráfico de histograma ni la tabla de valores en pan- Ing. Pablo Pytel 368 Diseño del Sistema de Información (Segundo Ciclo)

369 Código Condiciones Pre-requisitos talla. No posee No posee Procedimiento CP-204 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Pequeño Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Análisis completo. 5) Se selecciona la opción Mostrar Resultado s de Proyectos Estimados. 6) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 33: Caso de Pruebas CP-204 Código Objetivo Entrada CP-205 Generar un proyecto estimado de tamaño mediano con factores de costo establecidos. Proyecto de tamaño Mediano. Los factores de costo utilizados son: NTAB = 2 NTUP = 2 NATR = 2 DISP = 2 PNUL = 2 DMOD = 0 DEXT = 2 NMOD = 3 TMOD = 1 MTUP = 1 MATRn = 3 MATRt = 2 MTEC = 1 NFUN = 3 SCOM = 2 TOOL = 2 COMP = 0 NFOR = 2 NDEP = 2 DOCU = 2 SITE = 1 KDAT = 1 Ing. Pablo Pytel 369 Diseño del Sistema de Información (Segundo Ciclo)

370 Código Salida Condiciones Pre-requisitos ADIR = 1 MFAM = 1 Los valores estimados son: CP-205 Fórmula de 23 factores de costo = 125,20 Fórmula de 8 factores de costo = 106,56 Se muestran en pantalla los valores de costos estimados, gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Mediano Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 34: Caso de Pruebas CP-205 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-206 Generar un proyecto estimado de tamaño mediano con factores de costo aleatorios. Proyecto de tamaño Mediano. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Mediano Generar los factores de costo al azar = Si Ing. Pablo Pytel 370 Diseño del Sistema de Información (Segundo Ciclo)

371 Código CP-206 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se ven los resultados obtenidos. 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 35: Caso de Pruebas CP-206 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-207 Generar varios proyectos estimados de tamaño mediano con factores de costo aleatorios. Proyecto de tamaño Mediano. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Mediano Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se decide parar el proceso. 5) Se ven los resultados obtenidos y el histograma de los valores calculados 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 36: Caso de Pruebas CP-207 Código Objetivo Entrada Salida Condiciones CP-208 Generar análisis completo de proyectos estimados de tamaño mediano con factores de costo aleatorios. Proyecto de tamaño Mediano. No se muestra el gráfico de histograma ni la tabla de valores en pantalla. No posee Ing. Pablo Pytel 371 Diseño del Sistema de Información (Segundo Ciclo)

372 Código Pre-requisitos No posee Procedimiento CP-208 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Mediano Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Análisis completo. 5) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 6) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 37: Caso de Pruebas CP-208 Código Objetivo Entrada CP-209 Generar un proyecto estimado de tamaño grande con factores de costo establecidos. Proyecto de tamaño Grande. Los factores de costo utilizados son: NTAB = 5 NTUP = 4 NATR = 3 DISP = 4 PNUL = 4 DMOD = 3 DEXT = 4 NMOD = 4 TMOD = 1 MTUP = 4 MATRn = 4 MATRt = 4 MTEC = 3 NFUN = 4 SCOM = 4 TOOL = 4 COMP = 3 NFOR = 3 NDEP = 4 DOCU = 4 SITE = 4 KDAT = 3 ADIR = 1 MFAM = 1 Ing. Pablo Pytel 372 Diseño del Sistema de Información (Segundo Ciclo)

373 Código Salida Condiciones Pre-requisitos Los valores estimados son: CP-209 Fórmula de 23 factores de costo = 159,02 Fórmula de 8 factores de costo = 132,33 Se muestran en pantalla los valores de costos estimados, gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 38: Caso de Pruebas CP-209 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-210 Generar un proyecto estimado de tamaño grande con factores de costo aleatorios. Proyecto de tamaño Grande. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = Si Ing. Pablo Pytel 373 Diseño del Sistema de Información (Segundo Ciclo)

374 Código CP-210 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se ven los resultados obtenidos. 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 39: Caso de Pruebas CP-210 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-211 Generar varios proyectos estimados de tamaño grande con factores de costo aleatorios. Proyecto de tamaño Grande. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se decide parar el proceso. 5) Se ven los resultados obtenidos y el histograma de los valores calculados 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 40: Caso de Pruebas CP-211 Código Objetivo Entrada Salida Condiciones CP-212 Generar análisis completo de proyectos estimados de tamaño grande con factores de costo aleatorios. Proyecto de tamaño Grande. No se muestra el gráfico de histograma ni la tabla de valores en pantalla. No posee Ing. Pablo Pytel 374 Diseño del Sistema de Información (Segundo Ciclo)

375 Código Pre-requisitos No posee Procedimiento CP-212 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Análisis completo. 5) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 6) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 41: Caso de Pruebas CP-212 Código Objetivo Entrada CP-213 Generar un proyecto estimado de tamaño aleatorio con factores de costo establecidos. Proyecto de tamaño Aleatorio. Los factores de costo utilizados son: NTAB = 1 NTUP = 2 NATR = 3 DISP = 3 PNUL = 4 DMOD = 1 DEXT = 2 NMOD = 4 TMOD = 1 MTUP = 1 MATRn = 4 MATRt = 4 MTEC = 1 NFUN = 2 SCOM = 4 TOOL = 4 COMP = 3 NFOR = 1 NDEP = 4 DOCU = 2 SITE = 4 KDAT = 1 ADIR = 4 MFAM = 5 Ing. Pablo Pytel 375 Diseño del Sistema de Información (Segundo Ciclo)

376 Código Salida Condiciones Pre-requisitos Los valores estimados son: CP-213 Fórmula de 23 factores de costo = 104,13 Fórmula de 8 factores de costo = 107,22 Se muestran en pantalla los valores de costos estimados, gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = No Se definen los valores a los factores de costo de acuerdo a lo definido en <Entrada>. 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se compara los resultados obtenidos con los valores definidos en <Salida>. 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 42: Caso de Pruebas CP-213 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-214 Generar un proyecto estimado de tamaño aleatorio con factores de costo aleatorios. Proyecto de tamaño Aleatorio. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si Ing. Pablo Pytel 376 Diseño del Sistema de Información (Segundo Ciclo)

377 Código CP-214 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Calcular costo para un proyecto. 5) Se ven los resultados obtenidos. 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 43: Caso de Pruebas CP-214 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-215 Generar varios proyectos estimados de tamaño aleatorio con factores de costo aleatorios. Proyecto de tamaño Aleatorio. Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se decide parar el proceso. 5) Se ven los resultados obtenidos y el histograma de los valores calculados 6) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 7) Se muestran las opciones para seleccionar visualizar los resultados. Tabla SDSI 44: Caso de Pruebas CP-215 Código Objetivo Entrada Salida Condiciones CP-216 Generar análisis completo de proyectos estimados de tamaño aleatorio con factores de costo aleatorios. Proyecto de tamaño Aleatorio. El modo Análisis completo se encuentra deshabilitado para ser seleccionado. No posee Ing. Pablo Pytel 377 Diseño del Sistema de Información (Segundo Ciclo)

378 Código Pre-requisitos No posee Procedimiento CP-216 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se selecciona la opción Generar Proyectos Estimados. 4) No se puede seleccionar el modo Análisis completo. Tabla SDSI 45: Caso de Pruebas CP-216 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-217 Generar archivo de exportación para varios proyectos estimados de tamaño aleatorio. Proyecto de tamaño Aleatorio. Nombre archivo de exportación pruebatodo.csv Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. Los datos contenidos en el archivo de exportación se muestran en Microsoft Excel y son iguales a los datos de la tabla de datos. No posee El archivo de exportación pruebatodo.csv no existe. Se tienen permisos y espacio en disco para crear el archivo de exportación. Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se indica el nombre del archivo de exportación definido en <Entrada> y se elige la opción Crear. 4) Se selecciona la opción Generar Proyectos Estimados. 5) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se decide parar el proceso (por ejemplo, hasta tener 100 proyectos generados). 6) Se ven los resultados obtenidos y el histograma de los valores calculados Ing. Pablo Pytel 378 Diseño del Sistema de Información (Segundo Ciclo)

379 Código CP-217 7) Se selecciona la opción Cerrar Archivo. 8) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 9) Se muestran las opciones para seleccionar visualizar los resultados. 10) Se abre el archivo de exportación creado en Microsoft Excel. Tabla SDSI 46: Caso de Pruebas CP-217 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-218 Generar archivos particionados de exportación para varios proyectos estimados de tamaño aleatorio. Proyecto de tamaño Aleatorio. Nombre archivo de exportación pruebavarios.csv Cantidad de registros por archivo = 300 Se muestran los valores de costo estimados en pantalla de acuerdo a los datos generados al azar. Se muestran en pantalla los gráficos de frecuencia y la tabla de los valores generados. Se generan tres archivos de exportación (dos archivos de 300 registros y uno de 100 registros). Los datos contenidos en los tres archivos de exportación se muestran en Microsoft Excel y son iguales a los datos de la tabla de datos. No posee El archivo de exportación pruebavarios.csv no existe. Se tienen permisos y espacio en disco para crear el archivo de exportación. Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Aleatorio Generar los factores de costo al azar = Si 3) Se indica el nombre del archivo de exportación definido en <Entrada> y se elige la opción Crear. 4) Se indica que se quiere dividir los datos generados en varios archivos de 300 registros cada uno. 5) Se selecciona la opción Generar Proyectos Estimados. 6) Se ejecuta con el modo Evaluación continua, dejándolo ejecutar por un tiempo hasta que se tengan 700 registros generados. 7) Se ven los resultados obtenidos y el histograma de los valores calculados 8) Se selecciona la opción Cerrar Archivo. 9) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 10) Se muestran las opciones para seleccionar visualizar los resultados. Ing. Pablo Pytel 379 Diseño del Sistema de Información (Segundo Ciclo)

380 Código CP ) Se abren los tres archivos de exportación creados en Microsoft Excel. Tabla SDSI 47: Caso de Pruebas CP-218 Código Objetivo Entrada Salida Condiciones Pre-requisitos CP-219 Generar archivos particionados de exportación para el análisis completo de proyectos estimados de tamaño grande con factores de costo aleatorios. Proyecto de tamaño Grande. Nombre archivo de exportación pruebacompleto.csv Cantidad de registros por archivo = No se muestran los valores de costo estimados ni los resultados en pantalla. Se generan los archivos de exportación correspondientes para todas las combinaciones. Los datos contenidos en los archivos de exportación se muestran en Microsoft Excel. No posee No posee Procedimiento 1) Se ejecuta el sistema software. 2) Se configura el sistema software con los siguientes parámetros: Tamaño de Proyecto = Proyecto Grande Generar los factores de costo al azar = Si 3) Se indica el nombre del archivo de exportación definido en <Entrada> y se elige la opción Crear. 4) Se indica que se quiere dividir los datos generados en varios archivos de registros cada uno. 5) Se selecciona la opción Generar Proyectos Estimados. 6) Se ejecuta con el modo Análisis completo. 7) Se selecciona la opción Mostrar Resultados de Proyectos Estimados. 8) Se muestran las opciones para seleccionar visualizar los resultados. 9) Se abren los archivos de exportación creados en Microsoft Excel. Tabla SDSI 48: Caso de Pruebas CP-219 Ing. Pablo Pytel 380 Diseño del Sistema de Información (Segundo Ciclo)

381 9.8 APROBACIÓN DEL DISEÑO DEL SISTEMA DE INFORMACIÓN En esta tarea, el Comité de Dirección decide la aprobación formal o no del Diseño del Sistema de Información luego de que este es presentado PRESENTACIÓN Y APROBACIÓN DEL DISEÑO DEL SISTEMA DE INFORMACIÓN CORRESPONDIENTE AL SEGUNDO CICLO DE DESARROLLO Luego de realizar una reunión mantenida entre el tesista y los Directores del Proyecto de Tesis, se dio como válida a la fase de Diseño del segundo ciclo de desarrollo y se consideró aprobada la misma para continuar con las actividades correspondientes a la construcción del sistema software. Ing. Pablo Pytel 381 Diseño del Sistema de Información (Segundo Ciclo)

382

383 CAPÍTULO 10 SEGUNDO CICLO DE DESARROLLO: CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN

384

385 10. SEGUNDO CICLO DE DESARROLLO: CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN 10.1 INTRODUCCIÓN El proceso de Construcción del Sistema de Información (CSI) se volvió a realizar en el segundo ciclo de desarrollo considerando el código de los componentes ya generados durante el primer ciclo de desarrollo y los modelos generados durante el Diseño del Sistema de Información (DSI) del segundo ciclo de desarrollo. Se debe considerar que durante este segundo ciclo de desarrollo no fue necesario realizar las actividades de Preparación del Entorno de Generación y Construcción que ya fue realizada durante el primer ciclo de desarrollo (sección 7.2) pero fue agregada la actividad de Elaboración de los Manuales de Usuario que es utilizado durante la Implantación del sistema software GENERACIÓN DEL CÓDIGO DE LOS COMPONENTES Y PROCEDIMIENTOS Esta actividad tiene el objetivo de realizar la codificación de los componentes del sistema software, completando los componentes ya codificados en el primer ciclo de desarrollo con las especificaciones de construcción obtenidas en el proceso Diseño del Sistema de Información (DSI) del segundo ciclo. Esta actividad se realizó en paralelo con las actividades relacionadas con las pruebas unitarias y de integración del sistema software. Esto permite una 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 software GENERACIÓN DEL CÓDIGO DE COMPONENTES Esta tarea tiene el objetivo de generar el código correspondiente a cada uno de los componentes del sistema software. Por último, para 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. Ing. Pablo Pytel 385 Construcción del Sistema de Información (Segundo Ciclo)

386 GENERACIÓN DEL CÓDIGO DE LOS PROCEDIMIENTOS DE OPERACIÓN Y SEGURIDAD Esta tarea tiene el objetivo de generar los procedimientos de operación y administración del sistema software, 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 Esta tarea tampoco se realizó porque para el sistema software no existen requerimientos relativos a la validación de usuarios y no se utiliza base de datos para almacenar la información generada EJECUCIÓN DE LAS PRUEBAS UNITARIAS Esta actividad tiene el objetivo de realizar las pruebas unitarias de cada uno de los componentes del sistema software a medida que son codificados con el objeto de comprobar que su estructura es correcta y que se ajustan a la funcionalidad establecida REALIZACIÓN Y EVALUACIÓN DE LAS PRUEBAS UNITARIAS Esta tarea tiene el objetivo de comprobar el correcto funcionamiento de los componentes del sistema software conforme son codificados en la actividad Generación del Código de los Componentes y Procedimientos utilizando las verificaciones ya establecidas en el plan de pruebas para el nivel de pruebas unitarias. Luego, se analizaron los resultados de las pruebas unitarias, evaluándose las mismas para comprobar que los resultados son los esperados. En caso de que los resultados no son los esperados, se procede a realizar las correcciones pertinentes Resultado de la Realización de las Pruebas Unitarias Luego de realizar las pruebas unitarias del segundo ciclo de desarrollo con dos iteraciones de corrección a los componentes se detalla su resultado final en la tabla SCSI 1. El detalle de los problemas encontrados durante estas pruebas unitarias se encuentra en el Apéndice D de este trabajo. Código CP-001 Componente (Caso de Uso) CalcCostosEstimados (Generar los Proyectos Estimados) Resultado Exitosa Ing. Pablo Pytel 386 Construcción del Sistema de Información (Segundo Ciclo)

387 Código CP-002 CP-003 CP-004 CP-005 CP-006 CP-011 CP-012 CP-013 CP-014 Componente (Caso de Uso) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) CalcCostosEstimados (Generar los Proyectos Estimados) ConfigArchExp (Configurar Archivo de Exportación) ConfigArchExp (Configurar Archivo de Exportación) ConfigArchExp (Configurar Archivo de Exportación) ConfigArchExp (Configurar Archivo de Exportación) Resultado Exitosa Exitosa Exitosa Exitosa Exitosa Exitosa Exitosa Exitosa Exitosa ConfigArchExp CP-015 Exitosa (Configurar Archivo de Exportación) Tabla SCSI 2: Resultado de la ejecución de los casos de prueba unitarios 10.4 EJECUCIÓN DE LAS PRUEBAS DE INTEGRACIÓN Esta actividad tiene como objetivo comprobar la integración interna del sistema software buscando encontrar fallas en el funcionamiento de los componentes y subsistemas del sistema, al funcionar en conjunto para proveer la funcionalidad deseada. Como ya se ha mencionado, en este proyecto, debido a la estructura y la funcionalidad brindada por el sistema software desarrollado, estas pruebas fueron realizadas directamente junto con las pruebas del sistema EJECUCIÓN DE LAS PRUEBAS DEL SISTEMA Esta actividad tiene como objetivo comprobar la integración del sistema software globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos Ing. Pablo Pytel 387 Construcción del Sistema de Información (Segundo Ciclo)

388 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 (actividades que se llevan a cabo en el proceso Implantación y Aceptación del Sistema) REALIZACIÓN DE LAS PRUEBAS DEL SISTEMA Esta tarea tiene el objetivo de comprobar la integración de todos los subsistemas y componentes del sistema software, 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 realizaron 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 Luego de realizar las pruebas del sistema para el segundo ciclo de desarrollo con tres iteraciones de corrección a los componentes se detalle su resultado final en la siguiente tabla SCSI 2. El detalle de los problemas encontrados durante estas pruebas se encuentra en el Apéndice D de este trabajo. Código Casos de Uso Resultado CP-201 Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Exitosa Configurar Parámetros CP-202 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-203 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-204 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-205 Configurar Parámetros Exitosa Ing. Pablo Pytel 388 Construcción del Sistema de Información (Segundo Ciclo)

389 Código Casos de Uso Resultado Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-206 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-207 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-208 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-209 Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Exitosa Configurar Parámetros CP-210 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-211 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-212 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-213 Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Exitosa Configurar Parámetros CP-214 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-215 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-216 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-217 Configurar Archivo de Exportación Exitosa Generar Proyectos Estimados Ing. Pablo Pytel 389 Construcción del Sistema de Información (Segundo Ciclo)

390 Código Casos de Uso Resultado Mostrar Resultados de Proyectos Estimados CP-218 Configurar Parámetros Configurar Archivo de Exportación Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-219 Configurar Parámetros Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Exitosa Tabla SCSI 2: Resultado de la ejecución de los casos de prueba de sistema EVALUACIÓN DEL RESULTADO DE LAS PRUEBAS DEL SISTEMA Esta actividad tiene el objetivo de analizar los resultados de las pruebas del sistema software y efectuar su evaluación. Para poder realizar esta evaluación se debe establecer el grado de cumplimiento de las mismas Resultado de la Evaluación de los Resultados de las Pruebas de Sistema Luego de analizar los resultados de los casos de prueba para el sistema indicado en la tabla CSI 2, se decidió que el sistema había alcanzado los niveles de calidad deseados, al encontrase sus salidas dentro de los parámetros de valores esperados ELABORACIÓN DE LOS MANUALES DE USUARIO Esta tarea tiene el objetivo de preparar la documentación del sistema software que serán utilizados por los usuarios finales para su operación. Esta documentación se genera en paralelo con las tareas de construcción del software, finalizándola una vez que las pruebas del sistema son finalizadas exitosamente RESULTADO DE LA ELABORACIÓN DE LOS MANUALES DE USUARIO En el caso del presente sistema software se generó un manual de uso del sistema software el cual se puede encontrar en el Apéndice C de este trabajo. Ing. Pablo Pytel 390 Construcción del Sistema de Información (Segundo Ciclo)

391 10.7 APROBACIÓN DEL SISTEMA SOFTWARE CORRESPONDIENTE AL SEGUNDO CICLO DE DESARROLLO En esta tarea, se recopilan los productos del sistema software y se presentan al Comité de Seguimiento para su aprobación. Luego de realizar una reunión mantenida entre el tesista y los Directores del Proyecto de Tesis, se dio como aprobada la fase de Construcción para el segundo ciclo de desarrollo y se pudo continuar con las actividades finales de implantación y aceptación del sistema de información. Ing. Pablo Pytel 391 Construcción del Sistema de Información (Segundo Ciclo)

392

393 CAPÍTULO 11 IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA DE INFORMACIÓN

394

395 11. IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA DE INFORMACIÓN 11.1 INTRODUCCIÓN El objetivo del proceso de Implantación y Aceptación del Sistema de Información (IASI) es lograr 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. Primero, se revisa la estrategia de implantación donde se estudia su alcance y, dadas sus características, se define un plan de implantación donde 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. Antes de realizar la puesta en se realizan las actividades que 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 la migración o carga inicial de datos, si corresponde. Para pode realizarlas se utilizan como punto de partida los productos software probados, obtenidos en el proceso Construcción del Sistema de Información (CSI) del segundo ciclo de desarrollo y su documentación asociada. Se realizan las pruebas de implantación y de aceptación del sistema en su totalidad: Pruebas de Implantación Estas pruebas cubren un rango muy amplio del sistema software, 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 software 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. Pruebas de Aceptación Estas pruebas se realizan por y para los usuarios y tienen como objetivo validar formalmente que el sistema se ajusta a sus necesidades. Ing. Pablo Pytel 395 Implantación y Aceptación del Sistema de Información

396 Es importante mencionar también 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. Se debe además determinar los servicios y sus niveles para cada uno, que el sistema software requiere. El nivel con el que se presta cada servicio se negocia (en cuanto a recursos, horarios, coste, etc.) y una vez definido es utilizado como indicador de la calidad del mismo. Hay que distinguir entre dos tipos de servicios: Servicios de Gestión de Operaciones, que incluyen los servicios por lotes, seguridad, comunicaciones, etc. Servicios al Cliente, que incluyen servicio de atención al usuario, mantenimiento, etc. El proceso de implantación suele ser iterativo y 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 utilización del sistema software ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN Esta actividad tiene como objetivo revisar la estrategia de implantación para el sistema, la cual fue establecida inicialmente en el proceso Estudio de Viabilidad del Sistema (EVS). Para ello se identifican los distintos sistemas de información que forman parte del sistema objeto de la implantación y 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. En ese caso, es preciso establecer la estrategia detallada que se concreta de forma definitiva en el plan de implantación. Por último se constituye el equipo de implantación, determinando los recursos humanos necesarios, indicando sus perfiles y niveles de responsabilidad, tanto para la propia insta- Ing. Pablo Pytel 396 Implantación y Aceptación del Sistema de Información

397 lación del sistema, para las pruebas de implantación y aceptación, y para la preparación del mantenimiento DEFINICIÓN DEL PLAN DE IMPLANTACIÓN Esta tarea se basa en la estrategia de implantación del sistema que es determinada en función del 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. Además 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, los cuales fueron establecidos para cada uno de los sistemas de información en la tarea Especificación de Requisitos de Operación y Seguridad. Así se busca asegurar su adecuación a la estrategia global de implantación. Una vez analizada toda 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. Para ello debe incluir las siguientes tareas: Formación sobre el funcionamiento e implantación del sistema, tanto a usuarios finales como al equipo que se encarga de realizar las pruebas de implantación y aceptación del sistema. Preparación de la infraestructura necesaria para la incorporación del sistema al entorno de operación. Instalación de todos los componentes y procedimientos manuales y automáticos asociados a cada sistema software implicado en la implantación. Ejecución de los procedimientos de carga inicial y migración de datos, sólo si son necesarios. Realización de las pruebas de implantación y aceptación del sistema. Formalización del plan de mantenimiento Formación de Usuarios Finales y Equipo de Pruebas Durante esta tarea se capacitó a uno de los Directores de Tesis que toma el rol de usuario líder para verificar que se cumple con los requisitos y luego aceptar el sistema. Como requisito para realizar la capacitación, los usuarios debían tener conocimientos previos sobre proyectos de explotación de información, métodos de estimación utilizados para la Ingeniería en Software en general y sobre el método DMCoMo en particular. Ing. Pablo Pytel 397 Implantación y Aceptación del Sistema de Información

398 Preparación de la Infraestructura Necesaria para la Incorporación del Sistema al Entorno de Operación Debido a que el sistema software es monousuario, sin base de datos ni validación de usuario, residente en un único equipo, no existieron muchas consideraciones a tener en cuenta. Solamente se indicó que la aplicación debe ser instalada en un equipo que tenga instalado previamente el Java Runtime Environment (JRE) 1.5 o posterior Ejecución de Carga Inicial Dado que el sistema software no posee Base de Datos no fue necesario definir ningún procedimiento para poder ni ejecutar esta tarea Realización de las Pruebas de Implementación y Aceptación del Sistema En esta tarea el tesista tomó el rol de usuario final que se ocupa de realizar todas las pruebas de implementación y aceptación, ya que no hay diferenciación de usuarios en todos los puntos detallados hasta aquí Formalización del Plan de Mantenimiento Debido a la baja complejidad del sistema software (sistema monousuario sin base de datos) el mantenimiento del sistema no es dificultoso. De todas formas, se consideró que la etapa de mantenimiento del sistema software excede los límites del proyecto de tesis por lo que no se detalla en este punto ESPECIFICACIÓN DEL EQUIPO DE IMPLANTACIÓN Esta tarea se ocupó de establecer 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. En función del nivel de esfuerzo requerido, se identificaron 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 Dado que el sistema software es monousuario y fue desarrollado por el tesista junto con la participación de los Directores del Proyecto de Tesis, el equipo de implantación fue Ing. Pablo Pytel 398 Implantación y Aceptación del Sistema de Información

399 constituido, precisamente, por el tesista y los directores del proyecto de tesis. En este caso el tesista también desempeñó el rol de usuario final para realizar las pruebas de aceptación e implantación INCORPORACIÓN DEL SISTEMA AL ENTORNO DE OPERACIÓN Esta actividad tiene como objetivo realizar 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. Las pruebas de implantación y aceptación del sistema deben ejecutarse en el entorno real de operación a pesar que las pruebas unitarias, de integración y del sistema se pueden ejecutar en un entorno distinto. Esto se debe a que el propósito de estas pruebas de implantación y operación es comprobar que, el sistema satisface todos los requisitos especificados por el usuario en las mismas condiciones que cuando se inicie el uso en producción. Por lo tanto antes de la realización de dichas pruebas se debe verificar que: - Los recursos necesarios están disponibles para que se puedan realizar adecuadamente. - Se han realizado 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. - Se ha establecido 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 Esta tarea tiene el objetivo de verificar que la infraestructura necesaria para configurar el entorno se encuentra disponible. 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 incorporación posterior de los componentes asociados a los sistemas de información implicados en la implantación Descripción de la Instalación Por las características de este sistema software (monousuario, único equipo, sin base de datos y sin validación de usuario), la infraestructura es muy simple y comparte mucho de las características del entorno de desarrollo. Ing. Pablo Pytel 399 Implantación y Aceptación del Sistema de Información

400 El siguiente software de base fue utilizado en el equipo de trabajo: Sistema Operativo Windows 7 Microsoft Office 2010 Java Runtime Environment REALIZACIÓN DE LA INSTALACIÓN Esta tarea se ocupa de realizar la instalación de todos los componentes del nuevo sistema software, incluidos los procedimientos manuales y automáticos, de acuerdo al plan de implantación. Para ello también se tienen en cuenta los estándares y normativas por los que se rige la organización en los entornos de operación (si los hubiera). Una vez comprobada la correcta instalación del nuevo sistema, se activan los procedimientos de operación y de administración del sistema Instalación del sistema Se realizó la instalación del sistema software en lo que sería un ambiente de producción típico y la misma resultó completamente exitosa CARGA DE DATOS AL ENTORNO DE OPERACIÓN Esta actividad tiene el objetivo de realizar necesaria una carga inicial y/o una migración de datos cuyo alcance depende de las características y cobertura de cada sistema software implicado cuando el sistema de información a implantar forma parte de un plan para mejorar, ampliar o sustituir a otros ya existentes en la organización. En esa actividad se ha 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 Dado que el sistema software no posee Base de Datos no fue necesario ejecutar esta tarea para este proyecto INSTALACIÓN DEL SISTEMA Luego de realizar la instalación del sistema, se verificó que se encuentra correctamente instalado y operable. Ing. Pablo Pytel 400 Implantación y Aceptación del Sistema de Información

401 11.5 PRUEBAS DE IMPLANTACIÓN DEL SISTEMA En esta actividad se ejecutan las pruebas de implantación del sistema. 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. Estas pruebas tienen la doble funcionalidad de: 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. Una vez ejecutadas estas pruebas, el equipo de usuarios técnicos informa sobre las incidencias detectadas al responsable de implantación (en caso de encontrarse alguna). El responsable 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 Esta tarea se ocupa de comprobar la disponibilidad de los recursos humanos y técnicos necesarios para realizar las pruebas de implantación, para luego revisar las verificaciones establecidas en el plan de pruebas. Si fuera necesario, se debe crear 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 del sistema que fue definido en la fase de diseño del último ciclo de desarrollo y aplicado durante la etapa de construcción, se consideró que el mismo posee una adecuada cobertura de todas las funciones provistas por el sistema software, y por lo tanto se consideró que no era necesaria la generación de un nuevo plan de pruebas. Ing. Pablo Pytel 401 Implantación y Aceptación del Sistema de Información

402 REALIZACIÓN DE LAS PRUEBAS DE IMPLANTACIÓN En esta tarea 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 El tesista (en su rol de usuario) ejecutó todos los casos de prueba en el entorno de producción. El resultado de la a ejecución se ve en la tabla IASI 1 y es exitosa en todos los casos. Código Casos de Uso Resultado CP-201 Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Exitosa Configurar Parámetros CP-202 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-203 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-204 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-205 Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Exitosa Configurar Parámetros CP-206 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-207 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-208 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-209 Configurar Factores de Costo del Proyecto Exitosa Generar Proyectos Estimados Ing. Pablo Pytel 402 Implantación y Aceptación del Sistema de Información

403 Código Casos de Uso Resultado Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-210 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-211 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-212 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-213 Configurar Parámetros Configurar Factores de Costo del Proyecto Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Exitosa Configurar Parámetros CP-214 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-215 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-216 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-217 Configurar Parámetros Configurar Archivo de Exportación Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-218 Configurar Parámetros Configurar Archivo de Exportación Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-219 Configurar Parámetros Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Exitosa Tabla IASI 1: Resultado de la ejecución de los casos de prueba de implantación Ing. Pablo Pytel 403 Implantación y Aceptación del Sistema de Información

404 EVALUACIÓN DEL RESULTADO DE LAS PRUEBAS DE IMPLANTACIÓN En esta tarea 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 Dado que el tesista (en su rol de usuario) no encontró ninguna anomalía en la ejecución de los casos de prueba, se dio por aprobada la prueba de implementación del sistema PRUEBAS DE ACEPTACIÓN DEL SISTEMA En esta actividad se realizan y analizan los resultados de las pruebas de aceptación que tienen el objetivo de validar que el sistema cumple los requisitos básicos de funcionamiento esperado y permitir que el usuario determine la aceptación del sistema. Estas pruebas son realizadas por el usuario final que, durante este período de 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 En esta tarea 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 fueron llevado a cabo por uno de los directores de tesis (en el rol de usuario experimentado líder) una vez finalizadas con éxito la pruebas de implantación. Como se puede ver en la tabla IASI 2, el resultado de las mismas fue exitoso. Código Casos de Uso Resultado Ing. Pablo Pytel 404 Implantación y Aceptación del Sistema de Información

405 Código Casos de Uso Resultado Configurar Parámetros CP-201 CP-202 CP-203 CP-204 CP-205 CP-206 CP-207 CP-208 CP-209 CP-210 CP-211 CP-212 CP-213 Configurar Factores de Costo del Proyecto Exitosa Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros Configurar Factores de Costo del Proyecto Exitosa Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros Configurar Factores de Costo del Proyecto Exitosa Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros Exitosa Configurar Factores de Costo del Proyecto Ing. Pablo Pytel 405 Implantación y Aceptación del Sistema de Información

406 Código Casos de Uso Resultado Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-214 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-215 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados Configurar Parámetros CP-216 Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-217 Configurar Parámetros Configurar Archivo de Exportación Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-218 Configurar Parámetros Configurar Archivo de Exportación Generar Proyectos Estimados Exitosa Mostrar Resultados de Proyectos Estimados CP-219 Configurar Parámetros Configurar Archivo de Exportación Generar Proyectos Estimados Mostrar Resultados de Proyectos Estimados Exitosa Tabla IASI 2: Resultado de la ejecución de los casos de prueba de aceptación 11.7 PRESENTACIÓN Y APROBACIÓN DEL SISTEMA En esta actividad, 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. Para ello 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 PRESENTACIÓN Y APROBACIÓN DEL SISTEMA SOFTWARE IMPLANTADO Luego de realizar una reunión mantenida entre el tesista y los Directores del Proyecto de Tesis, se dio como válida a la fase de Implantació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. Pablo Pytel 406 Implantación y Aceptación del Sistema de Información

407 CAPÍTULO 12 APLICACIÓN DEL SISTEMA PARA VALIDAR EL MÉTODO DE ESTIMACIÓN

408 12. APLICACIÓN DEL SISTEMA PARA VALIDAR EL MÉTODO DE ESTIMACIÓN 12.1 INTRODUCCIÓN Dado que el sistema software ya fue probado, implantado y aceptado, en este capítulo se realizan los primeros análisis de los resultados obtenidos. Así la propuesta de este capítulo es utilizar el sistema software desarrollado para generar datos experimentales que fueron analizados para intentar dar respuesta a la cuestión planteado en la sección 2.5 sobre comportamiento del método de estimación Matemático Paramétrico de Estimación para Proyectos de Data Mining (en inglés Data Mining COst MOdel, o DMCoMo) para proyectos de explotación de información con diferentes características. Es intención de esta esta tesis utilizar el sistema software desarrollado dentro del campo de la Ingeniería del Software para realizar los primeros análisis del comportamiento del método de estimación DMCoMo en diferentes variaciones de los factores de costo que consideren los tres rangos de tamaño de proyecto previamente definidos o sin restricciones (o sea variaciones totalmente aleatorias). Para ello se analizaron los datos que se obtienen de los archivos de exportación generados por el sistema software desarrollado PREPARACIÓN DE LOS EXPERIMENTOS En esta sección se definen los experimentos de simulación Montecarlo a realizar con el sistema software desarrollado para analizar el comportamiento del método DMCoMo. Primero se definen los experimentos a realizar y a partir de los mismos se definen los parámetros (valores de las variables independientes) que deben utilizarse DEFINICIÓN DE LOS EXPERIMENTOS El experimento consiste en generar datos de proyectos generados en forma aleatoria pero restringidos por tamaño del proyecto (de acuerdo a la definición del Apéndice A). Se generan tres bancos de datos (uno para proyectos de tamaño pequeño, otro para medianos y uno para grandes) donde los valores de los factores de costo (variables independientes) se generan en forma aleatoria pero dependiendo del tamaño del proyecto seleccionado. De esta manera se busca ver el comportamiento de las fórmulas del método DMCoMo (variables dependientes) de acuerdo a la clasificación definida en este trabajo. Ing. Pablo Pytel 408 Validación del Método de Estimación

409 Se recuerda la relación entre las variables independientes y dependientes utilizadas en el experimento de acuerdo a la definición realizada en la sección 2.6.1, la cual se muestra en la figura VME 1. SCOM SITE NFUN KDAT ADIR MTUP TOOL MTEC MM23 PNUL NMOD NDEP DOCU TAMAÑO DEL PROYECTO NTUP COMP DMOD MFAM NTAB NATR DISP MM8 DEXT TMOD MATRt MATRn MATR NFOR Figura VME 1. Relación entre las variables independientes y dependientes De esta forma, el estudio experimental se realiza aplicando el método de simulación Montecarlo con el siguiente protocolo: Paso 1: Desarrollo de tres bancos de pruebas de proyectos cada uno donde se generan los datos de proyectos de explotación de información con los valores de los factores de costo determinados aleatoriamente dentro del marco de la clasificación del tamaño de los proyectos. Para cada proyecto generado se le aplican las fórmulas de estimación del método DMCoMo. Este paso del experimento es realizado mediante la utilización del sistema software desarrollado. Ing. Pablo Pytel 409 Validación del Método de Estimación

410 Paso 2: Integrar estadísticamente la información obtenida para cada tamaño de proyecto generando los gráficos auxiliares que se consideren necesarios. Paso 3: Interpretar los resultados obtenidos y formular conclusiones PARÁMETROS UTILIZADOS EN LOS EXPERIMENTOS A partir del experimento definido, se definen los valores de las variables independientes (tamaño de proyecto y factores de costo) que son utilizados como parámetros para generar los bancos de prueba. Estos parámetros se muestran en la tabla VME 1. VARIABLE INDEPENDIENTE TAMAÑO DEL PROYECTO Proyectos Pequeños Proyectos Medianos Proyectos Grandes "Pequeño" "Mediano" "Grande" ADIR Aleatoria Aleatoria Aleatoria COMP Aleatoria Aleatoria Aleatoria DEXT Aleatoria Aleatoria Aleatoria DISP Aleatoria Aleatoria Aleatoria DMOD Aleatoria Aleatoria Aleatoria DOCU Aleatoria Aleatoria Aleatoria KDAT Aleatoria Aleatoria Aleatoria MATR Aleatoria Aleatoria Aleatoria MFAM Aleatoria Aleatoria Aleatoria MTEC Aleatoria Aleatoria Aleatoria MTUP Aleatoria Aleatoria Aleatoria NATR Aleatoria Aleatoria Aleatoria NDEP Aleatoria Aleatoria Aleatoria NFOR Aleatoria Aleatoria Aleatoria NFUN Aleatoria Aleatoria Aleatoria NMOD Aleatoria Aleatoria Aleatoria NTAB Aleatoria Aleatoria Aleatoria NTUP Aleatoria Aleatoria Aleatoria PNUL Aleatoria Aleatoria Aleatoria SCOM Aleatoria Aleatoria Aleatoria SITE Aleatoria Aleatoria Aleatoria TMOD Aleatoria Aleatoria Aleatoria TOOL Aleatoria Aleatoria Aleatoria Tabla VME 1: Parámetros del Experimento Ing. Pablo Pytel 410 Validación del Método de Estimación

411 12.3 REALIZACIÓN DE LOS EXPERIMENTOS Una vez definidos los experimentos se utiliza el sistema software desarrollado para generar los experimentos incluyendo los datos de los proyectos (factores de costo) con sus correspondientes esfuerzos estimados (variables dependientes) EJECUCIÓN DE LOS EXPERIMENTOS Se ha ejecutado el sistema software ingresando los parámetros definidos en la tabla VME 1 y configurándola para que los datos generados y procesados sean exportados. Durante el funcionamiento no se producen errores y se generan los archivos sin problemas. Estos archivos se importan en Microsoft Excel y se consolidan en una sola planilla 1 para realizar si integración y posterior análisis ANÁLISIS DE LOS RESULTADOS En esta sección se muestra el análisis del comportamiento del método DMCoMo utilizando los datos generados por los experimentos ejecutados. Para ello primera se realiza un análisis general de los costos estimados obtenidos por ambas fórmulas y luego se analiza cómo la variación de los factores de costo con mayor impacto en la fórmulas influye en los costos estimados ANÁLISIS ESTADÍSTICO GENERAL Como primer análisis se indica en la tabla VME 2 la media estadística obtenida por cada una de las fórmulas y tamaño de proyecto. MEDIA (en meses/hombre) MM23 MM8 Proyectos Pequeños 84,41 102,59 Proyectos Medianos 128,89 126,30 Proyectos Grandes 183,45 148,51 Tabla VME 2: Media por Fórmula y Tamaño de Proyecto De esta tabla se puede ver que la media de la fórmula que utiliza los 23 factores de costo (representada por la variable MM23) en proyectos medianos es un 52% más grande que 1 Esta planilla se encuentra disponible en la siguiente URL Y0O3vy7NDkzODRhY2MtNzM2ZS00ZmQ4LWI2ZDQtZTRiOWFmMjUxYmU4&hl=en_US&authkey=CJKwi5cB. Ing. Pablo Pytel 411 Validación del Método de Estimación

412 la de proyectos pequeños y la media de los proyectos grandes es un 42% más grande que los proyectos medianos (o sea un 117% con respecto a los proyectos pequeños). Por otro lado, la fórmula que utiliza sólo 8 factores de costo (variable MM8) posee un crecimiento menor por escalones de aproximadamente el 22% con respecto al tamaño anterior. Entonces debido a que la fórmula de 23 factores de costo crece aproximadamente el doble con respecto a la otra fórmula al variar el tamaño del proyecto, se podría decir que es más conservadora. Para realizar un análisis más detallado del comportamiento de las fórmulas por tamaño de proyecto se utilizan gráficos Boxplot. Estos gráficos [Turkey, 1977] permiten ver en un único gráfico los datos correspondientes a los límites superior e inferior (valores máximo y mínimo), el desvío máximo (media más la desviación estándar) y mínimo (media menos la desviación estándar) y la media de los resultados obtenidos en el experimento. En la figura VME 2 se muestra cómo se pueden observar estos datos en un gráfico Boxplot. Figura VME 2: Explicación de los gráficos Boxplot Al realizar la primera observación de los gráficos Boxplot en la tabla VME 3, se nota que los costos de ambas fórmulas poseen un solapamiento entre sí, siendo mayor para la fórmula de 8 factores de costo (variable MM8) que la de 23 factores de costo (MM23). Además se puede observar que los valores de MM23 poseen costos estimados dispersos entre 33,16 meses/hombre (valor mínimo para proyectos pequeños) y 234,14 meses/hombre (valor máximo para proyectos grandes) y los valores de MM8 se encuentran comprendidos entre 71,45 y 183,09 meses/hombre. Como se dijo anteriormente, esto se debe a que la función de MM23 es más conservadora que MM8. Ing. Pablo Pytel 412 Validación del Método de Estimación

413 MM23 MM8 Tabla VME 3: Gráficos Boxplot por fórmula Por otro lado en la tabla VME 4 se muestra la distribución del costo por fórmula y tamaño de proyecto. MM23 MM8 Proyectos Grandes Proyectos Medianos Proyectos Pequeños Tabla VME 4: Gráficos de Distribución de Costo por Fórmula y Tamaño de Proyecto De estos gráficos se nota que la mayor cantidad de los proyectos (más del 70% de los proyectos para cada muestra de proyectos) se encuentra: para Proyectos Pequeños o entre 70 y 100 meses/hombre en MM23, y o entre 90 y 120 meses/hombre en MM8. Ing. Pablo Pytel 413 Validación del Método de Estimación

414 para Proyectos Medianos o entre 110 y 145 meses/hombre en MM23, y o entre 110 y 140 meses/hombre en MM8. para Proyectos Grandes o entre 168 y 200 meses/hombre en MM23, y o entre 130 y 160 meses/hombre en MM8. por lo que se confirma el comportamiento antes observado. Por último, si se comparan los resultados obtenidos por tamaño de proyecto con la definición de los tamaños de proyecto realizada en el Apéndice A de este trabajo se puede ver que en los tres casos el resultado no cumple con las restricciones definidas: Los Proyectos Pequeños deberían tener un costo estimado menor a 24 meses/hombre, pero los resultados obtenidos para ambas fórmulas sobrepasan siempre este valor máximo (un mínimo obtenido de 33,16 meses/hombre para MM23 y de 71,45 meses/hombre para MM8). Los Proyectos Medianos deberían tener un costo estimado entre 24 y 60 meses/hombre, pero los resultados obtenidos para ambas variables sobrepasan siempre este rango (un mínimo obtenido de 71,94 meses/hombre para MM23 y de 87,57 meses/hombre para MM8). Los Proyectos Grandes deberían tener un costo estimado mayor a 60 meses/hombre, lo cual se cumple pero con un mínimo de aproximadamente el doble de ese valor permitido (un mínimo obtenido de 127,75 meses/hombre para MM23 y de 110,20 meses/hombre para MM8) ANÁLISIS DE FACTORES DE COSTO QUE PRODUCEN MAYOR INCREMENTO DEL ESFUERZO ESTIMADO Para realizar este análisis se seleccionaron los tres factores de costo de DMCoMo que producen el mayor impacto en el incremento del esfuerzo estimado en ambas fórmulas para ver como su variación afecta el comportamiento de las fórmulas. Los factores de costo seleccionados son TMOD, DISP y MATR por poseer los mayores coeficientes positivos (con los coeficientes 6,032, 6,426 y 4,966 respectivamente para la primera fórmula; y 7,257, 4,792 y 4,615 respectivamente para la segunda fórmula). Con estos factores se generan los gráficos de la tabla VME 5. Ing. Pablo Pytel 414 Validación del Método de Estimación

415 Variando sólo TMOD Variando sólo DISP Variando sólo MATR Tabla VME 5: Gráficos de variación de las variables que aumentan el costo estimado Ing. Pablo Pytel 415 Validación del Método de Estimación

416 La tabla VME 5 posee la siguiente estructura: por columnas se incluyen los gráficos con la variación de cada uno de los factores de costo. por filas se incluyen los gráficos para los diferentes tamaños de proyecto (pequeño, mediano y grande). en cada gráfico se muestra: - en el eje X los valores que toma el factor de costo de la columna para el tamaño de proyecto indicado en la fila, - en el eje Y los valores de los costos estimados por las fórmulas, donde la línea negra corresponde a la fórmula de 23 factores de costo (MM23) y línea gris para la fórmula de sólo 8 factores de costo (MM8). Al analizar los gráficos de por columna (o sea por factor de costo) se puede observar que: Para el factor de costo Tipo de Modelo a Ser Creado (TMOD): - En los Proyectos Pequeños el crecimiento de ambas fórmulas es el mismo para Modelos Descriptivos (TMOD=1, TMOD=2 y TMOD=3) por ser las rectas paralelas, pero en los Modelos Predictivos (TMOD=4 y TMOD=5) los valores estimado por MM23 no crecen igual que MM8. Además se puede ver que los valores estimados por MM8 son siempre superiores a los de MM23. - En los Proyectos Medianos los valores estimados por ambas fórmulas son muy cercanos, siendo casi idénticos para los Modelos Predictivos (TMOD=4 y TMOD=5). - En los Proyectos Grandes, sucede algo similar que en los proyectos pequeños: para los Modelos Descriptivos (TMOD=1, TMOD=2 y TMOD=3) el crecimiento de ambas fórmulas es similar pero para proyectos Predictivos (TMOD=4 y TMOD=5) los valores estimado por MM23 no crecen en la misma medida que MM8. Además los valore de MM8 son siempre inferiores a los de MM23. En general al analizar el factor de costo TMOD se podría decir que construir un sistema de explotación de información con Modelos Predictivos posee un costo estimado mayor que utilizando Modelos Descriptivos. Para el factor de costo Grado de Dispersión de Datos (DISP): - En los Proyectos Pequeños solamente pueden tomar un valor (DISP=1 que corresponde a dispersión menor al 20%) donde el valor estimado por MM8 es superior al de MM23. Ing. Pablo Pytel 416 Validación del Método de Estimación

417 - En los Proyectos Medianos solamente toma dos valores (DISP=2, DISP=3 y DISP=4 correspondientes a una dispersión entre 20 y 80%). Los valores estimados por ambas fórmulas son muy cercanos siendo más similares a medida que la dispersión es menor (o sea a medida que el valor de DISP es menor). - En los Proyectos Grandes solamente toma dos valores (DISP=4 y DISP=5 correspondientes a una dispersión mayor al 60%). Se ve que las dos rectas son casi paralelas por lo que ambas fórmulas crecen de la misma manera pero, al contrario que con proyectos pequeños, los valores estimados por MM23 son superiores a los de MM8. Por lo tanto se podría al analizar este factor de costo decir que utilizar datos con mayor dispersión de valores trae aparejado un mayor costo estimado. Para Cantidad y Tipos de los Atributos por cada Modelo (MATR): - En los Proyectos Pequeños el crecimiento de los valores estimados por ambas fórmulas es similar. Además se puede ver que para estos proyectos los valores estimados por MM8 son siempre superiores a los estimados por MM23. - En los Proyectos Medianos los valores estimados por ambas fórmulas son muy cercanos. - En los Proyectos Grandes se mantiene el crecimiento similar de ambas fórmulas pero, al contrario que para los proyectos pequeños, los valores estimados por MM8 son siempre inferiores a los estimados por MM23. Entonces se podría decir que utilizar fuentes de datos con mayor cantidad y tipos de atributos trae aparejado un mayor costo estimado. Por otro lado, al analizar los gráficos de la tabla VME 5 por fila (o sea por tamaño de proyecto) se puede ver que: Para Proyectos Pequeños, los valores estimados de ambas fórmulas poseen valores más extremos con la variación del factor de costo TMOD que con respecto a DISP y MATR donde se ve una diferencia casi constante. Para los Proyectos Medianos, la diferencia entre MM8 y MM23 es casi inexistente para los factores de costo DISP y MATR mientras que para TMOD posee una distancia mayor, sobre todo cuando toma valores correspondientes a Modelos Descriptivos. En los Proyectos Grandes se mantiene el crecimiento similar de ambas fórmulas pero, al contrario que para los proyectos pequeños, los valores estimados por MM8 son siempre inferiores a los estimados por MM23. Ing. Pablo Pytel 417 Validación del Método de Estimación

418 ANÁLISIS DE FACTORES DE COSTO QUE PRODUCEN MAYOR DISMINUCIÓN DEL ESFUERZO ESTIMADO Finalmente se analiza el comportamiento de los tres factores de costo de DMCoMo que producen el mayor impacto en la disminución del esfuerzo estimado en ambas fórmulas para ver como su variación afecta el comportamiento de las fórmulas. Los factores de costo que son seleccionados ahora son NFOR, TOOL y MFAM por poseer los mayores coeficientes negativos (con los coeficientes -4,689, -4,615 y -4,543 respectivamente para la primera fórmula; y sólo -3,842 y -3,275 en la segunda dado que TOOL no se utiliza). Con estos factores se generan los gráficos de la tabla VME 6 que poseen la misma estructura que la tabla VME 5. Al analizar los gráficos de la tabla VME 6 por factor de costo (o sea por columna de la tabla) se puede observar que: Para Nivel de Formación de los Usuarios en las Herramientas (NFOR): - En los Proyectos Pequeños el crecimiento de los valores estimados por ambas fórmulas es similar. Además se puede ver que para estos proyectos los valores estimados por MM8 son siempre superiores a los estimados por MM23. - En los Proyectos Medianos los valores estimados por ambas fórmulas son muy cercanos, tomando valores casi idénticos cuando NFOR=4 ( Se requiere conocimiento en técnicas de explotación de información y conocimiento experto en las herramientas ) y NFOR=5 ( Se requiere conocimiento experto en técnicas de explotación de información y en las herramientas ). - En los Proyectos Grandes se mantiene el crecimiento similar de ambas fórmulas, pero, al contrario que para los proyectos pequeños, los valores estimados por MM8 son siempre inferiores a los estimados por MM23. Así parecería que el costo estimado disminuye a media que se requiere mayor conocimiento experto en técnicas de en técnicas de explotación de información y en las herramientas (o sea, mayor valor del factor de costo). Esto indicaría que al requerirse mayor experiencia para manejar las herramientas, el equipo de trabajo podrá finalizar el proyecto en menos tiempo que un equipo sin experiencia con herramientas que poseen asistentes para su uso. Ing. Pablo Pytel 418 Validación del Método de Estimación

419 Para Herramientas Disponibles para Ser Usadas (TOOL) el crecimiento de MM23 está afectado por la variación de los valores del factor de costo, pero no afecta a MM8 que posee un valor constante para cualquier valor de TOOL. Además parecería que el costo estimado por MM23 disminuye a media que se usa menos cantidad de herramientas (o sea, a medida que el valor del factor de costo crece). Esto no tiene mucho sentido porque indicaría que es preferible no utilizar ninguna herramienta para realizar el proyecto en menos tiempo y menor costo. Para Grado de Familiaridad con el Tipo de Problema (MFAM): - En los Proyectos Pequeños el crecimiento de los valores estimados por ambas fórmulas es similar. Además se puede ver que para estos proyectos los valores estimados por MM8 son siempre superiores a los estimados por MM23. - En los Proyectos Medianos los valores estimados por ambas fórmulas son muy cercanos, tomando valores casi idénticos cuando MFAM=3 ( El equipo ha trabajado en tipos de proyectos igual al del nuevo proyecto pero con datos diferentes ) y MFAM=4 ( El equipo ha trabajado en tipos de proyectos igual al del nuevo proyecto pero nunca en el mismo ambiente ). - En los Proyectos Grandes se mantiene el crecimiento similar de ambas fórmulas, pero, al contrario que para los proyectos pequeños, los valores estimados por MM8 son siempre inferiores a los estimados por MM23. En general parecería que el costo estimado disminuye a media que el equipo de trabajo posee menos experiencia trabajando en proyectos de explotación de información (o sea, a medida que el valor del factor de costo crece). Esto no tiene sentido porque indicaría que es preferible tener un equipo de trabajo con menos conocimiento y experiencia para realizar el proyecto en menos tiempo y menor costo. Finalmente, al analizar los gráficos de la tabla VME 6 por tamaño de proyecto (o sea por fila) se puede ver que sin importar el tamaño del proyecto las fórmulas MM23 y MM8 tienen un comportamiento similar para los tres factores de costo analizados, presentado en todos los casos tanto valores extremos máximos y mínimos, como pendientes similares. Ing. Pablo Pytel 419 Validación del Método de Estimación

420 Variando sólo NFOR Variando sólo TOOL Variando sólo MFAM Tabla VME 6: Gráficos de variación de las variables que disminuyen el costo estimado Ing. Pablo Pytel 420 Validación del Método de Estimación

421 CAPÍTULO 13 CONCLUSIONES Y FUTURAS LÍNEAS DE TRABAJO

422

423 13. CONCLUSIONES Y FUTURAS LÍNEAS DE TRABAJO 13.1 CONCLUSIONES Fue desarrollado un sistema software para generar bancos de pruebas de proyectos de explotación de información basado en el método de simulación Montecarlo. Los datos generados por este sistema software se utilizan para analizar el comportamiento del método de estimación de proyectos de explotación de información Método Matemático Paramétrico de Estimación para Proyectos de Data Mining (DMCoMo). El ciclo de vida de software aplicado para el desarrollo fue el iterativo incremental en dos fases junto con las actividades definidas por Métrica Versión III para el Desarrollo Orientado a Objetos. En la primera fase fueron construidas las funciones principales del sistema software dejando para la segunda las funciones complementarias de exportación de datos, visualización de gráficos y estadísticas. En cuanto a la planificación del proyecto, se produjo una demora de sólo 7 días producto de la falta de experiencia en el entorno utilizado para la codificación, lo cual no tuvo impacto en el éxito del proyecto. Una vez que el sistema software ha sido desarrollado, instalado y aceptado para su utilización se procedió a su utilización para generar datos que han sido analizados para obtener las siguientes conclusiones iniciales. Dada la necesidad de estimar correctamente el costo de un proyecto de explotación de información para poder planificar las actividades a realizar y los recursos necesarios, y las diferencias de estos proyectos y los proyectos convencionales de construcción de software, se ha realizado una búsqueda documental. Como resultado de dicha búsqueda se ha encontrado uno de naturaleza analítica denominado DMCoMo [Marbán, 2003; Marbán et al., 2003] y otro de naturaleza empírica [Rodríguez et al., 2010]. De estos dos métodos se ha decidido validar el comportamiento del método de estimación analítico DMCoMo [Pytel et al., 2011] en el rango de proyectos de explotación de información pequeños, medianos y grandes (según la clasificación definida en este trabajo). Del análisis general del método de estimación DMCoMo se puede concluir que la fórmula que utiliza los 23 factores de costo es más conservadora por crecer casi el doble con respecto a la que sólo utiliza 8 de los factores de costo al aumentar el tamaño de proyecto a estimar. Así, la fórmula de 8 factores de costo produce cambios menos Ing. Pablo Pytel 423 Conclusiones

424 abruptos de los resultados a partir de las mismas características de proyectos. Sin embargo se considera que esta fórmula, al utilizar sólo 8 de los 23 factores de costo, está descartando información importante que debería usarse para la estimación (por ejemplo el grado de disponibilidad de las herramientas a ser utilizadas). Además se puede ver que el método DMCoMo no se comporta correctamente para la clasificación de los proyectos pequeños, medianos y grandes realizada en el Apéndice A de este trabajo. Las estimaciones obtenidas sobrepasan con una gran diferencia al máximo definido para proyectos pequeños y medianos; mientras que para los proyectos grandes también se detecta una sobrevaloración pero en menor medida. De las dos fórmulas, la que se acerca más a los rangos definidos por tamaño de proyecto es la que utiliza los 23 factores de costo. Se ve que el método DMCoMo siempre sobreestima el esfuerzo de los proyectos dado que la mayoría de los valores generados están entre 9 y 12 años/hombre por lo cual se podría indicar que serviría sólo para proyectos grandes (de más de 5 años/hombre) pero no para proyectos medianos ni pequeños. Nótese que esto confirma, al menos en parte, las conclusiones de [Marbán et al., 2003] donde se dice que el método es confiable para proyectos entre 7,5 años/hombre a 15,41 años/hombre. Por otro lado, como resultado del estudio detallado de los factores de costo se puede señalar que en general para los proyectos medianos el costo estimado por ambas fórmulas es muy similar (casi idéntico en algunos casos), pero esto no sucede en los otros tamaños de proyectos. En los proyectos pequeños los valores estimados por la fórmula de 8 factores de costo son siempre superiores, mientras que en los proyectos grandes sucede lo contrario. De esto se podría concluir que sólo para proyectos entre 2 y 5 años/hombre las dos fórmulas poseen un comportamiento similar, mientras que para proyectos fuera de ese rango el comportamiento es distinto. Por último se destaca el comportamiento del método para la variación de sus valores de tres de los factores de costo estudiados. Si se considera el tipo de modelo a desarrollar, se nota que las dos fórmulas poseen un comportamiento diferente con respecto a sus valores, obteniendo un costo estimado mayor para los modelos predictivos que para los descriptos. En el caso de las herramientas disponibles y el grado de familiaridad con el tipo de problema, se detecta una incongruencia entre el comportamiento de las fórmulas y la realidad. Según DMCoMo el costo estimado parecería reducirse al poseer menor cantidad de herramientas disponible y menor experiencia trabajando en Ing. Pablo Pytel 424 Conclusiones

425 proyectos similares, lo cual se contradice con el sentido común y con los datos conocidos de proyectos históricos FUTURAS LÍNEAS DE TRABAJO Como líneas de trabajo futuro se han identificado los siguientes aspectos: 1) Implementar modificaciones perfectivas al sistema software en varios aspectos para aumentar su funcionalidad y ampliar su portabilidad. En ese sentido, se pueden considerar los siguientes puntos: Al momento de realizar el análisis inicial del método DMCoMo se utilizaron dos tipos de gráficos que se consideran muy útiles por la forma que muestran la información y que deberían ser incluirlos en el sistema software para que su generación sea automática (o sea, sin necesitar exportar los datos a MS Excel para generarlos). - El primer tipo de gráfico son los gráficos Boxplot utilizados en la tabla VME 3 de la sección El sistema software debería incluir una nueva pestaña en la funcionalidad Mostar Estadísticas que permita generar dos gráficos de este tipo, uno para los costos estimados por fórmula de 23 factores de costo y otro para los costos estimados por la fórmula de 8 factores de costo. - El segundo tipo de gráfico son los gráficos donde se muestra la variación de los valores de un factor de costo con respecto a las dos fórmulas, los cuales fueron utilizados en las tablas VME 5 y VME 6 de la secciones y respectivamente. El sistema software debería incluir otra nueva pestaña en la funcionalidad Mostar Estadísticas que muestre un diagrama con la variación de los costos estimados por las dos fórmulas a partir de un factor de costo previamente seleccionado por el usuario. Se considera que sería útil para el análisis del método DMCoMo ampliar la clasificación de los proyectos de explotación de información al agregar nuevas subclasificaciones a los tamaños ya definidos (por ejemplo, proyectos muy pequeños, pequeños relativamente pequeños, proyectos reducidos, etc.). De esta forma se podría analizar el comportamiento de las fórmulas con mayor nivel de granularidad. Este cambio implicaría modificar la funcionalidad de Configurar Parámetros para que el usuario pueda seleccionar los nuevos. Además, para aumentar la flexibilidad del sistema software, también sería recomendable agregar una nue- Ing. Pablo Pytel 425 Conclusiones

426 va pantalla de configuración donde los usuarios puedan administrar los tamaños de proyectos modificando los valores permitidos para los factores de costo. Así, los usuarios no estarían atados a la clasificación definida inicialmente por el desarrollador y podrían probar el método de estimación con diferentes variantes. 2) Realizar nuevas pruebas utilizando el sistema software para lograr obtener el análisis completo del comportamiento del método DMCoMo. En ese sentido, se pueden considerar los siguientes puntos: Realizar el estudio detallado de los restantes 17 factores de costo para analizar el comportamiento de las fórmulas de estimación con respecto a la variación de cada uno de ellos. Realizar un estudio del comportamiento de las dos fórmulas en proyectos donde el costo estimado se encuentra fuera del rango de 2 a 5 años/hombre con el objetivo de determinar cuál es preferible de utilizar en esas condiciones. Finalmente realizar nuevas simulación con mayor cantidad de proyectos simulados para corroborar las conclusiones obtenidas. Ing. Pablo Pytel 426 Conclusiones

427 CAPÍTULO 14 BIBLIOGRAFÍA Y GLOSARIO

428

429 14. BIBLIOGRAFÍA Y GLOSARIO 14.1 REFERENCIAS BIBLIOGRÁFICAS [Agarwal & Kumar, 2001] Agarwal, R. y Kumar, M. (2001) Estimating software projects. Software engineering Notes, 26(4), pp [Albrecht, 1983] Albrecht, A. (1983) Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation. IEEE Trans. Software Eng., Vol. SE-9, No. 6, [Bielak, 2000] Bielak, J. (2000) Improving Size Estimates Using Historical Data. IEEE Software, vol. 17, no. 6, pp , Nov./Dec. 2000, doi: / [Boehm, 1981] Boehm, B. (1981) Software Engineering Economics. Prentice Hall, Upper Saddle River, N.J. [Boehm et al., 1995] Boehm, B.; Clark, B.; Horowitz, E.; Westland, C.; Madachy, R.; Selby, R. (1995) Cost Models for Future Software Life Cycle Process: COCOMO 2.0. Ann. of Software Eng. Special Volume on Software Process and Product Measurement, J.D. Arther and S.M. Henry, eds., Science Publishers, Amsterdam, The Netherlands, Vol. 1, pp [Boehm et al., 2000] Boehm, B.; Abts, C.; Brown, A.W.; Chulani, S.; Clark, B.K.; Horowitz, E.; Madachy, R.; Reifer, D.; Steece, B. (2000) Software Cost Estimation with COCOMO II, Prentice-Hall, Englewood Cliffs, NJ. [Bozoki, 1991] Bozoki, G.J. (1991) Performance Simulation of SSM (Software Sizing Model), Proc. 13th Conf., Int l Soc. of Parametric Analysts, Int l Soc. of Parametric Analysts, New Orleans, pp. CM 14. [Britos, 2008] Britos, P. (2008). Procesos de Explotación de Información Basados en Sistemas Inteligentes. Tesis Doctoral. Facultad de Informática. Universidad Nacional de La Plata. Ultimo Acceso Abril [Chapman et al., 2000] Chapman, P.; Clinton, J.; Keber, R.; Khabaza, T.; Reinartz, T.; Shearer, C.; Wirth, R. (2000). CRISP-DM 1.0 Step by step BI guide. Edited by SPSS. Ultimo acceso 01/06/08. Ing. Pablo Pytel 429 Bibliografía y Glosario

430 [Curtis et al., 1992] Curtis, B.; Kellner, M.; Over, J. (1992). Process Modelling. Communications of the ACM, 35(9): [Fairley, 1992] Fairley, R.E. (1992) Recent Advances in Software Estimation Techniques. Proc. 14th Int l Conf. Software Eng., ACM Press, New York. [Fetcke et al., 1998] Fetcke, T.; Abran, A.; Nguyen, T. H. (1998) Mapping the OO- Jacobson Approach into Function Point Analysis. Proc. TOOLS-23 97, IEEE Press, Piscataway, N.J.. [IEEE, 1983] Institute of Electronic and Electrical Engineers (1983) IEEE Standard IEEE Standard for Software Test Documentation. IEEE Computer Society. E-ISBN: Ultimo Acceso Abril [IEEE, 1987] Institute of Electronic and Electrical Engineers (1987) IEEE Standard IEEE Guide to Software Configuration Management. IEEE Computer Society. E-ISBN: Ultimo Acceso Abril [IEEE, 1997] Institute of Electronic and Electrical Engineers (1997) IEEE Standard IEEE Standard for Developing Software Life Cycle Processes. IEEE Computer Society. E-ISBN: Ultimo Acceso Abril [IEEE, 1998] Institute of Electronic and Electrical Engineers (1998) IEEE Standard IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society. E-ISBN: Ultimo Acceso Abril [Métrica III, 2000] Ministerio de Administración Pública del Gobierno Español (2000) Metodología de planificación, Desarrollo y Mantenimiento de Sistemas de Información del Ministerio de Administración Pública del Gobierno Español. Ultimo Acceso Abril [Kalos & Whitlock, 1986] Kalos, M.H.; Whitlock P.A. (1986) Monte Carlo Methods. Vol I. Basics. John Wiley & Sons. New York. Ing. Pablo Pytel 430 Bibliografía y Glosario

431 [Lewis, 1994] Lewis G. (1994). What is Software Engineering?. DataPro (4015). Feb pp [LLC PRICE, 1998] LLC PRICE Systems. (1998) PRICE-S Reference Manual Version 3.0, Lockheed-Martin. [Marbán, 2003] Marbán, O. (2003) Modelo Matemático Paramétrico de Estimación para Proyectos de Data Mining (DMCoMo), Ph.D. Thesis, Facultad de Informática, Universidad Politécnica de Madrid,. [Marbán et al., 2003] Marbán, O.; Menasalvas, E.; Fernández-Baizán, C. (2003) A cost model to estimate the effort of data mining projects (DMCoMo) Information Systems 33: [Merlino et al., 2005] Merlino, H., Britos, P., Ierache, J., Diez E. & García-Martínez, R. (2005) Un Método de Transformacion De Datos orientado al uso de Explotación de Información. II Workshop de Ingeniería del Software y Bases de Datos. XI Congreso Argentino de Ciencias de la Computación. Pág [Negash & Gray, 2008] Negash, S.; Gray, P. (2008). Business Intelligence. In Handbook on Decision Support Systems 2, ed.eds. F. Burstein y C. Holsapple (Heidelberg, Springer), Pág.Pp [Peña Sánchez de Rivera, 2001] Peña Sánchez de Rivera, D. (2001). Deducción de distribuciones: el método de Montecarlo. Fundamentos de Estadística. Madrid: Alianza Editorial. ISBN [Pollo-Cattaneo et al., 2009] Pollo-Cattaneo, F., Britos, P. Pesado, P., García-Martínez, R. (2009). Metodología para Especificación de Requisitos en Proyectos de Explotación de Información. Proceedings XI Workshop de Investigadores en Ciencias de la Computación. Pág ISBN [Pollo-Cattaneo et al., 2010] Pollo-Cattaneo, F., Britos, P., Pesado, P., García-Martínez, R. (2010). Proceso de Educción de Requisitos en Proyectos de Explotación de Información. In Ingeniería de Software e Ingeniería del Conocimiento: Tendencias de Investigación e Innovación Tecnológica en Iberoamérica, Eds: R. Agui-lar, J. Díaz, G. Gómez, E- León. Pp Alfaomega Grupo Editor. ISBN [Pollo-Cattaneo et al., 2010b] Pollo-Cattaneo, F., Britos, P., Pesado, P., García-Martínez, R. (2010). Ingeniería de Procesos de Explotación de Información. In Ingenie- Ing. Pablo Pytel 431 Bibliografía y Glosario

432 ría de Software e Ingeniería del Conocimiento: Tendencias de Investigación e Innovación Tecnológica en Iberoamérica, Eds: R. Aguilar, J. Díaz, G. Gómez, E- León. Pp Alfaomega Grupo Editor. ISBN [Pressman, 2004] Pressman, R. (2004). Software Engineering: A Practitioner's Approach. Editorial Mc Graw Hill. [Putman, 1978] Putnam, L.H. (1978) A General Empirical Solution to the Macro Software Sizing and Estimating Problem. IEEE Trans. Software Eng., Apr. 1978, pp [Putnam et al., 2000] Putnam Sr., L.H.; D.T. Putnam, D.T.; Putnam Jr., L.H.; Ross, M.A. (2000). Software Lifecycle Management (SLIM) Training. SLIM Estimate Exercises with Answers, Quantitative Software Management, Mc Lean, VA. [Pyle, 2003] Pyle, D. (2003). Business Modeling and Business Intelligence. Morgan Kaufmann Publishers. [Pytel et al., 2011] Pytel, P., Tomasello, M., Rodríguez, D.; Arboleya, H., Pollo-Cattaneo. M., Britos, P., García-Martínez, R. (2011). Estimación de Proyectos de Explotación de Información. Estudio Comparado de Modelos Analíticos y Empíricos. Proceedings XIII Workshop de Investigadores en Ciencias de la Computación. Artículo [Rodríguez et al., 2010] Rodríguez, D., Pollo-Cattaneo, F., Britos, P., García-Martínez, R. (2010). Estimación Empírica de Carga de Trabajo en Proyectos de Explotación de Información. Anales del XVI Congreso Argentino de Ciencias de la Computación. Pp ISBN [SAS 2008] SAS, (2008). SAS Enterprise Miner: SEMMA. /semma.html. Ultimo Acceso Abril [Schiefer et al., 2004] Schiefer, J.; Jeng, J.; Kapoor, S.; Chowdhary, P. (2004). Process Information Factory: A Data Management Approach for Enhancing Business Process Intelligence. Proceedings 2004 IEEE International Conference on E- Commerce Technology. Pág [Shannon & Weaver, 1949] Shannon C. E.; Weaver W. (1949) The Mathematical Theory of Communication. Univ. of Illinois Press, Urbana, USA. Ing. Pablo Pytel 432 Bibliografía y Glosario

433 [Stefanovic et al., 2006] Stefanovic, N.; Majstorovic. V.; Stefanovic, D. (2006). Supply Chain Business Intelligence Model. Proceedings 13th International Conference on Life Cycle Engineering. Pág [Thomsen, 2003] Thomsen, E. (2003). BI s Promised Land. Intelligent Enterprise, 6(4): [Turkey, 1977] Tukey, J. (1977) Exploratory Data Analysis. Addison-Wesley Publishing Company. [Umapathy, 2007] Umapathy, K. (2007). Towards Co-Design of Business Processes and Information Systems Using Web Services. Proceedings 40th Annual Hawaii International Conference on System Sciences. Pág [Vanrell et al., 2010] Vanrell, J., Bertone, R., García-Martínez, R. (2010). Un Modelo de Procesos de Explotación de Información. Proceedings XII Workshop de Investigado-res en Ciencias de la Computación. Pp ISBN [Wiegers, 2000] Wiegers, K. (2000) Stop Promising Miracles. Software Development, Vol. 8, No. 2, Feb. 2000, p ACRÓNIMOS ADIR: Factor de costo actitud de los directivos. ANSI: American National Standards Institute (Instituto Nacional de Estándares Americano) COMP: Factor de costo grado de compatibilidad de las herramientas con otros software. DEXT: Factor de costo grado de integración de datos externos. DISP: Factor de costo grado de dispersión de datos. DMCoMo: Método Matemático Paramétrico de Estimación para Proyectos de Data Mining. DMOD: Factor de costo grado de documentación de las fuentes de información. DOCU: Factor de costo grado de documentación que es necesario generar. IEEE: Institute of Electrical and Electronic Engineers (Instituto de Ingenieros en Electricidad y Electrónica) IS: Ingeniería en Software Ing. Pablo Pytel 433 Bibliografía y Glosario

434 KDAT: Factor de costo grado de conocimiento de los datos. MM23: Costo estimado utilizando la fórmula que aplica los 23 factores de costo. MM8: Costo estimado utilizando la fórmula que aplica los 8 factores de costo. MATR: Factor de costo promedio calculado de cantidad (MATRn) y tipo de atributos (MATRt) por cada modelo. MATRn: Factor de costo cantidad de atributos por cada modelo. MATRt: Factor de costo tipo de atributos por cada modelo. MFAM: Factor de costo grado de familiaridad con el tipo de problema. MTEC: Factor de costo cantidad de técnicas disponibles para cada modelo. MTUP: Factor de costo cantidad de tuplas de los modelos. NATR: Factor de costo cantidad de atributos de las tablas. NDEP: Factor de costo cantidad de departamentos involucrados en el proyecto. NFOR: Factor de costo grado de entrenamiento de los usuarios de las herramientas. NFUN: Factor de costo cantidad y tipo de fuentes de información disponibles. NMOD: Factor de costo cantidad de modelos a ser creados. NTAB: Factor de costo cantidad de tablas. NTUP: Factor de costo cantidad de tuplas de las tablas. PNUL: Factor de costo porcentaje de valores NULL. SCOM: Factor de costo distancia y medio de comunicación entre servidores de datos. SITE: Factor de costo cantidad de sitios donde se realizará el desarrollo y su grado de comunicación. SW: Software TOOL: Factor de costo herramientas disponibles para ser usadas. TMOD: Factor de costo tipo de modelos a ser creados. UML: Lenguaje de Modelado Universal (en inglés Universal Modelling Language) GLOSARIO Ciclo de Vida: Es una sucesión de estados o fases por los cuales pasa un software a lo largo de su "vida". Básicamente estos estados son: definición o desarrollo del concepto (lo que el software hará), desarrollo técnico (creación del software), Uso u operación (uso del software) y finalmente evolución (mantenimiento y fin de operación). Costo Estimado: Ver Esfuerzo Estimado. Ing. Pablo Pytel 434 Bibliografía y Glosario

435 Costo Real: Ver Esfuerzo Real. Esfuerzo Estimado: El tiempo o costo de un proyecto definido a partir de la utilización de un método de estimación. Esfuerzo Real: El tiempo o costo real registrado una vez que el proyecto ha finalizado. Factores de Costo: Conjunto de variables utilizadas por un método de estimación para predecir el tiempo y/o costo de un proyecto GESMET: Software, de distribución gratuita, para la gestión de Proyectos de Ingeniería del Software basados en Métrica Versión III. Desarrollado por la Empresa Getronic para el Instituto Nacional de Administración Pública Español. Gráfico Boxplot: Es un gráfico representativo de las distribuciones de un conjunto de datos en cuya construcción se usan cinco medidas descriptivas de los mismos: los límites superior e inferior, el desvío máximo y mínimo y la media estadística. Ingeniería en Software: es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software. Lenguaje de Modelado Universal (en inglés, Universal Modelling Language o UML): Es un lenguaje gráfico que permite modelar los elementos que constituyen un Sistema de Software. Método de Estimación: Conjunto de técnicas y procedimientos que se usan en la organización para poder llegar a una predicción fiable del tiempo y/o costo para realizar cierta actividad o grupo de actividades. Método de Simulación: Ver Método Montecarlo. Método Matemático Paramétrico de Estimación para Proyectos de Data Mining (DMCoMo): Método de estimación analítico para proyectos de explotación de información. Método Montecarlo: Consiste en generar mediante una simulación aleatoria (hecha por computadora), un conjunto de números que se correspondan con la distribución normal. Métrica Versión III: Metodología de planificación, desarrollo y mantenimiento de Sistemas de Información. Desarrollada por el por el Instituto Nacional de Administración Pública Español. Ing. Pablo Pytel 435 Bibliografía y Glosario

436 Modelo de Negocio: Modelo gráfico que forma parte de UML, el mismo tiene como objetivo mostrar el comportamiento del sistema, desde el punto de vista de un usuario externo. Proceso Software: Conjunto de etapas parcialmente ordenadas con la intención de lograr un producto de software de calidad. Se logra traduciendo las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo. Concretamente define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo. Proyecto de Explotación de Información: Proyecto de desarrollo que tiene como objetivo construir un Sistema de Explotación de Información. Pruebas de Caja Negra: Método de prueba que toma al sistema como una caja negra, es decir, no analiza cómo funciona internamente el mismo, sino, que se base en el análisis de las respuestas que el sistema debe generar en base a las entradas recibidas Requisitos Funcionales: Especifican qué debe hacer el sistema que se va a construir desde el punto de vista funcional, es decir, qué funciones se necesita que el sistema realice. Requisitos No Funcionales o Especiales: Complementan a los requisitos funcionales, y tienen como objetivo indicar aspectos técnicos que condicionan el funcionamiento del sistema, por ejemplo, el tiempo de respuesta del sistema o el tipo de interfaz de usuario que deberá implementar el mismo. Sistema de Información: Conjunto interrelacionado de elementos que tiene el objetivo de recolectar, almacenar, procesar y distribuir información en tiempo y forma para la toma de decisiones dentro una organización. Sistema de Explotación de Información: Sistema Software que aplica herramientas de análisis y síntesis para extraer conocimiento no trivial que se encuentra (implícitamente) en los datos disponibles de diferentes fuentes de información. Sistema Software: Conjunto de programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo los cuales fueron diseñados en base a los requisitos de los usuarios. Ing. Pablo Pytel 436 Bibliografía y Glosario

437 Tupla: Cada una de las filas (registros) de una relación. Contiene la información relativa a una única entidad. Variable Dependiente: Variable de un experimento cuyos valores dependen de los que tome otra variable independiente ya que las variables independientes se dividen entre ellas. Variable Independiente: Variable de un experimento que es manipulada por el investigador con el objeto de estudiar cómo incide sobre la expresión de la variable dependiente. Ing. Pablo Pytel 437 Bibliografía y Glosario

438

439 APÉNDICES

440

441 APÉNDICES APÉNDICE A: CLASIFICACIÓN DE PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN A.1. INTRODUCCIÓN Para facilitar el análisis de los resultados de aplicar el método DMCoMo a la estimación de proyectos de explotación en este trabajo se decide utilizar una clasificación de los proyectos de acuerdo a tres rango de tamaño: proyectos Pequeños, Medianos y Grandes. En este apéndice se define las características que tienen cada una de estas tres clasificaciones así como los valores permitidos para cada uno de los factores de costo utilizados por DMCoMo los cuales se listan en la tabla APA 1 (los cuales se encuentran definidos en la sección 2.4.2). CATEGORÍA FACTOR DE COSTO FACTORES DE COSTO RELACIONADOS A LOS DATOS FACTORES DE COSTO RELACIONADOS A LOS MODELOS FACTORES DE COSTO RELACIONADOS AL DESARROLLO DE LA PLATAFORMA FACTORES DE COSTO RELACIONADOS A LAS TÉCNICAS Y HERRAMIENTAS CANTIDAD DE TABLAS (NTAB) CANTIDAD DE TUPLAS DE LAS TABLAS (NTUP) CANTIDAD DE ATRIBUTOS DE LAS TABLAS (NATR) GRADO DE DISPERSIÓN DE DATOS (DISP) PORCENTAJE DE VALORES NULL (PNUL) GRADO DE DOCUMENTACIÓN DE LAS FUENTES DE INFORMACIÓN (DMOD) GRADO DE INTEGRACIÓN DE DATOS EXTERNOS (DEXT) CANTIDAD DE MODELOS A SER CREADOS (NMOD) TIPO DE MODELOS A SER CREADOS (TMOD) CANTIDAD DE TUPLAS DE LOS MODELOS (MTUP) CANTIDAD Y TIPO DE ATRIBUTOS POR CADA MODELO (MATR) CANTIDAD DE TÉCNICAS DISPONIBLES PARA CADA MODELO (MTEC) CANTIDAD Y TIPO DE FUENTES DE INFORMACIÓN DISPONIBLES (NFUN) DISTANCIA Y MEDIO DE COMUNICACIÓN ENTRE SERVIDORES DE DATOS (SCOM) HERRAMIENTAS DISPONIBLES PARA SER USADAS (TOOL) GRADO DE COMPATIBILIDAD DE LAS HERRAMIENTAS CON OTROS SOFTWARE (COMP) GRADO DE ENTRENAMIENTO DE LOS USUARIOS DE LAS HERRAMIENTAS (NFOR) FACTORES DE COSTO CANTIDAD DE DEPARTAMENTOS INVOLUCRADOS Ing. Pablo Pytel 441 Apéndice A

442 CATEGORÍA FACTOR DE COSTO RELACIONADOS AL PROYECTO EN EL PROYECTO (NDEP) GRADO DE DOCUMENTACIÓN QUE ES NECESARIO GENERAR (DOCU) CANTIDAD DE SITIOS DONDE SE REALIZARÁ EL DESARROLLO Y SU GRADO DE COMUNICACIÓN (SITE) FACTORES DE COSTO RELACIONADOS AL EQUIPO DE TRABAJO GRADO DE FAMILIARIDAD CON EL TIPO DE PROBLEMA (MFAM) GRADO DE CONOCIMIENTO DE LOS DATOS (KDAT) ACTITUD DE LOS DIRECTIVOS (ADIR) Tabla APA 1. Factores de Costo del Método DMCoMo A.2. DEFINICIÓN DE LOS TAMAÑOS DE PROYECTOS De acuerdo a los resultados de los experimentos realizados en [Rodríguez et al., 2010], se puede observar que las fases de la metodología CRISP-DM para desarrollar un proyecto de explotación de información que poseen mayor esfuerzo (más del 70% del esfuerzo total) son las siguientes: Comprensión del Negocio ( 20,70% del esfuerzo total ) Preparación de Datos ( 15,61% del esfuerzo total ) Modelado ( 34,41% del esfuerzo total ) 21% 29% 71% 16% 34% Otros Preparación de Datos Comprensión del Negocio Modelado Figura APA 1. Esfuerzo relativo de las fases de CRISP-DM En la primera fase se realiza el análisis del problema, que incluye la comprensión de los objetivos y requerimientos del proyecto desde la perspectiva de la organización con el fin de convertirlos en objetivos técnicos y en una planificación. Por lo que es recomendable la definición de una metodología para educir los requerimientos y objetivos del proyecto Ing. Pablo Pytel 442 Apéndice A

443 [Pollo-Cattaneo et al., 2009] para luego ser documentados de forma que pueda ser accedidos y utilizados en las siguientes fases [Pollo-Cattaneo et al., 2010]. Durante la prepapreparación de los datos, se incluyen las tareas generales de selección de datos a los que se va a aplicar la técnica de modelado (variables y muestras), limpieza de los datos, generación de variables adicionales, integración de diferentes orígenes de datos y cambios de formato. Para ello es necesario también definir un método [Merlino et al., 2005] que primero registre los requerimientos para luego diseñar un proceso que aplique las técnicas y herramientas más convenientes. Finalmente, en la fase de modelado se seleccionan las técnicas de modelado más apropiadas para el proyecto de explotación de información específico considerando las más convenientes de acuerdo a los objetivos y requisitos definidos [Pollo-Cattaneo et al., 2010b]. Por lo tanto al momento de definir la clasificación de los tamaños de los proyectos de explotación de información se debe considerar: Las características de los Departamentos de la Organización que participan en el proyecto, ya son estas las que definirán los requerimientos y objetivos del proyecto. Las características de las Fuentes de Información disponibles para utilizar, ya que estas definirán la complejidad de la preparación de los datos y el modelo a utilizar. Las características de los Modelos a ser utilizados. Considerando esto, a continuación se definen las características que tiene cada uno de los tamaños de proyectos: PROYECTOS PEQUEÑOS Se considera como proyecto pequeño a todo proyecto que posee las siguientes características: Los requerimientos son definidos por menos de tres departamentos de la organización ubicados en la mismo lugar (permitiendo también que el equipo de trabajo también lo este). Las fuentes de información a utilizar poseen pocas tablas (menos de 80 tablas), tuplas (menos de 5 x 10 7 tuplas) y atributos (menos de 500 atributos). Estos atributos además no poseen gran variedad de valores y buena calidad (poca cantidad de valores NULL). No es necesario utilizar más de tres fuentes internas ni externas de datos, que se encuentran en el mismo ambiente. Los modelos a generar son menores a seis, sin importar el tipo, pero con una cantidad acotada de tuplas y atributos. Ing. Pablo Pytel 443 Apéndice A

444 El proyecto utiliza tipos de modelos y/o datos conocidos por el equipo de trabajo. Por cumplir todas estas características, se considera que estos proyectos deberían tener un esfuerzo menor a 24 meses / hombre (o sea menor a 2 años). PROYECTOS MEDIANOS Se considera como proyecto mediano a todo proyecto que posee las siguientes características: Los requerimientos son definidos por menos de cinco Departamentos de la organización ubicados en la mismo edificio (permitiendo también que el equipo de trabajo también lo este). Las fuentes de información a utilizar poseen pocas tablas (entre 60 y 120 tablas), tuplas (entre 5 x 10 7 y 20 x 10 7 tuplas) y atributos (menos de atributos). Estos atributos además poseen una variedad amplia de valores y calidad regular (por la cantidad de valores NULL). No es necesario utilizar más de siete fuentes internas ni externas de datos, que se pueden encontrar en distintas ubicaciones pero todas comunicadas entre sí. Los modelos a generar son entre tres y siete, sin importar el tipo, pero con una cantidad amplia de tuplas y atributos (con más de 20 atributos). El proyecto utiliza tipos de modelos y/o datos que pueden ser conocidos para el equipo de trabajo, pero existen medios para conocerlos. Por cumplir todas estas características, se considera que estos proyectos deberían tener un esfuerzo mayor a 24 meses / hombre y menor a 60 meses / hombre (o sea, entre 2 años y 5 años). PROYECTOS GRANDES Se considera como proyecto grande a todo proyecto que posee las siguientes características: Los requerimientos son definidos por más de tres Departamentos de la organización ubicados en la misma ciudad (permitiendo también que el equipo de trabajo también lo este) o no (necesitando comunicaciones por teléfono, fax, Internet o correo). Ing. Pablo Pytel 444 Apéndice A

445 Las fuentes de información a utilizar poseen muchas tablas (más de 120 tablas), tuplas (más de 20 x 10 7 tuplas) y atributos (más de atributos). Estos atributos además poseen una gran amplia de valores y puede tener poca calidad (gran cantidad de valores NULL). Es necesario utilizar más de cinco fuentes externas de datos y más de tres internas de datos (que pueden estar en papel), que se pueden encontrar en distintas ubicaciones y no comunicadas entre sí. Los modelos a generar son más de cinco, sin importar el tipo, pero con una cantidad amplia de tuplas (más de 20 x 10 6 tuplas) y atributos (con más de 50 atributos). El proyecto utiliza tipos de modelos y/o datos que pueden ser conocidos para el equipo de trabajo, y pueden no existir medios para conocerlos. Por cumplir todas estas características, se considera que estos proyectos deberían tener un esfuerzo mayor a 60 meses / hombre (o sea, mayor a 5 años). A.3. CONSIDERACIONES ADICIONALES Antes de comenzar a definir los tamaños de los proyectos de explotación de información, se indican ciertas consideraciones que se consideran a la hora de caracterizar los proyectos en este trabajo. Estas consideraciones buscan reducir la cantidad de combinaciones posibles para generar el banco de prueba y así facilitar el análisis del método. Las consideraciones contempladas se detallan a continuación: Se considera que si la dirección del departamento no apoya al proyecto o está en su contra, o si la dirección de la organización no lo apoya entonces el proyecto no podrá existir (o sea, el valor 4 del factor de costo ADIR se elimina). Se considera que el equipo de trabajo debe poseer un mínimo de experiencia trabajando en proyectos de explotación similares (o sea, el valor 5 del factor de costo MFAM se elimina). Además el equipo de trabajo debe conocer las herramientas que van a utilizar para generar los modelos. De estas herramientas se considera que no poseen agentes inteligentes y que en caso de necesitar conocimiento experto para su utilización también se va a necesitar conocimiento experto en las técnicas de explotación de información (o sea, se eliminan los valores 1 y 4 del factor de costo NFOR). Se considera que los tipos de atributos a ser utilizados en el modelo tendrán una cantidad equitativa de tipos numéricos y no numéricos, por lo que no se Ing. Pablo Pytel 445 Apéndice A

446 utilizan las combinaciones: todos numéricos, todos no numéricos y mitad numéricos / mitad no numéricos (o sea, se eliminan los valores 1, 3 y 5 del factor de costo MATRt). Se considera que normalmente se disponen de herramientas para generar algunos de los modelos pero no todos, por lo que no se utilizan las combinaciones extremas (o sea, se eliminan los valores 1, 3 y 5 del factor de costo TOOL). Dado que no el nivel compatibilidad de la herramienta no posee restricciones por el tamaño de proyecto sólo se analizan tres niveles: compatibilidad completa, media y nula (o sea, se eliminan los valores 1, 2 y 4 del factor de costo COMP). Dado que el grado de documentación de las fuentes de información no posee restricciones por el tamaño de proyecto sólo se analizan tres niveles: documentación completa, media y reducida (o sea, se eliminan los valores 1, 2 y 4 del factor de costo DMOD). Dado que la cantidad de técnicas por tipo de modelo no posee restricciones por el tamaño de proyecto sólo se analizan los valores extremos(o sea, para el factor de costo MTEC se eliminan los valores 2 y 4 del Modelo Descriptivo y los valores 3 y 5 del Modelo Predictivo). A.4. DEFINICIÓN DE LOS FACTORES DE COSTO DE LOS TAMAÑOS DE PROYECTOS De acuerdo a las características de los proyectos definidos en la sección anterior, a continuación se detallan los valores que serán permitidos para cada uno de los factores de costo utilizados por el método DMCoMo por cada tamaño de proyecto. PROYECTOS PEQUEÑOS Los valores permitidos de los factores de costo para proyectos pequeños se definen a continuación en la tabla APA 2. Factor de Costo Rangos Permitidos Valores Permitidos ADIR MB: La dirección del departamento y la organización apoyan al proyecto B: La dirección del departamento apoya al proyecto pero la dirección de la organización no lo apoya. N: La dirección del departamento apoya al proyecto y la dirección de la organización no se opone. 1, 2, 3 Ing. Pablo Pytel 446 Apéndice A

447 Factor de Costo Rangos Permitidos Valores Permitidos COMP EB: Total compatibilidad e integración con las herramientas disponibles en la organización N: Compatibilidad con editores de texto y planillas de cálculo disponibles en la organización MA: No hay compatibilidad con las herramientas disponibles en la organización 0, 3, 5 DEXT B: De 1 a 3 fuentes externas de datos 2 DISP MB: 0 H < 0,2 1 DMOD XB: Todos los modelos N: De 70 a 80% de los modelos MA: Menos del 60% de los modelos 0, 3, 5 DOCU B: Documentación sólo para Modelos implantados N: Documentación para todos los modelos generados A: Documentación para todos los modelos y fases centrales de explotación de información MA: Documentación para todos los modelos y todas las fases de explotación de información 2, 3, 4, 5 KDAT MB: Experto en correlación del negocio y datos B: Experto en correlación de datos 1, 2 MATRn MB: Hasta 10 atributos B: Entre 10 y 20 atributos N: Entre 30 y 50 atributos A: Entre 50 y 70 atributos 1, 2, 3, 4 MATRt B: Más cantidad de atributos no numéricos que de atributos numéricos A: Más cantidad de atributos numéricos que de atributos no numéricos 2, 4 MFAM MB: El equipo ha estado trabajando junto en los mismos tipos de proyectos de explotación de información igual al del nuevo proyecto y con datos similares B: El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto y con datos similares N: El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto pero con datos diferentes 1, 2, 3 Ing. Pablo Pytel 447 Apéndice A

448 Factor de Costo MTEC Rangos Permitidos Modelo Descriptivos MB: Hay más de 4 técnicas disponibles para generar el modelo N: Hay 2 técnicas disponibles para generar el modelo Modelo Predictivos: B: Hay más de 4 técnicas disponibles para generar el modelo A: Hay 3 técnicas disponibles para generar el modelo EA: Hay 1 técnica disponible para generar el modelo Valores Permitidos 1, 3 2, 4, 6 MTUP MB: Hasta 5 x 10 6 tuplas B: Entre 5 x 10 6 tuplas y 10 x 10 6 tuplas 1, 2 NATR MB: Hasta 500 atributos 1 NDEP B: Participa 1 sólo Departamento N: Participan 2 Departamentos 2, 3 NFOR B: Se requiere conocimiento en técnicas de explotación de información. Las herramientas usan asistente. N: Se requiere un pequeño conocimiento en técnicas de explotación de información y conocimiento en las herramientas. MA: Se requiere conocimiento experto en técnicas de explotación de información y en las herramientas. 2, 3, 5 NFUN MB: Hay 1 fuente de información disponible B: De 2 a 3 fuentes de información homogéneas disponibles 1, 2 NMOD B: De 1 a 3 modelos N: De 3 a 5 modelos 2, 3 NTAB XB: Hasta 20 tablas MB: De 20 a 60 tablas B: De 60 a 80 tablas 0, 1, 2 NTUP MB: Hasta 5 x 10 7 tuplas 1 PNUL MB: Hasta 10% de valores NULL B: De 10 a 15% de valores NULL 1, 2 Ing. Pablo Pytel 448 Apéndice A

449 Factor de Costo Rangos Permitidos Valores Permitidos SCOM MB: Todos los datos en la máquina que será analizada B: Todos los datos en la misma base de datos N: Todas las fuentes de datos en el mismo edificio comunicados a través de una red LAN 1, 2, 3 SITE MB: Comunicación interactiva multimedia en la misma ubicación 1 TMOD TOOL Modelo Descriptivo: MB: Asociación B: Partición (Clustering) N: Patrones Secuenciales Modelo Predictivo: A: Clasificación MA: Predicción, Estimación o Series Temporales B: Herramientas usadas para más del 70% de los modelos A: Herramientas usadas para menos del 50% de los modelos 1, 2, 3 4, 5 2, 4 Tabla APA 2. Valores permitidos para Proyectos de Tamaño Pequeño PROYECTOS MEDIANOS Los valores permitidos de los factores de costo para proyectos medianos se definen a continuación en la tabla APA 3. Factor de Costo Rangos Permitidos Valores Permitidos ADIR MB: La dirección del departamento y la organización apoyan al proyecto B: La dirección del departamento apoya al proyecto pero la dirección de la organización no lo apoya. N: La dirección del departamento apoya al proyecto y la dirección de la organización no se opone. 1, 2, 3 COMP EB: Total compatibilidad e integración con las herramientas disponibles en la organización N: Compatibilidad con editores de texto y planillas de cálculo disponibles en la organización MA: No hay compatibilidad con las herramientas disponibles en la organización 0, 3, 5 Ing. Pablo Pytel 449 Apéndice A

450 Factor de Costo DEXT DISP DMOD DOCU KDAT MATRn MATRt MFAM MTEC Rangos Permitidos B: De 1 a 3 fuentes externas de datos N: De 3 a 5 fuentes externas de datos A: De 5 a 7 fuentes externas de datos B: 0,2 H < 0,4 N: 0,4 H < 0,6 A: 0,6 H < 0,8 XB: Todos los modelos N: De 70 a 80% de los modelos MA: Menos del 60% de los modelos B: Documentación sólo para Modelos implantados N: Documentación para todos los modelos generados A: Documentación para todos los modelos y fases centrales de explotación de información MA: Documentación para todos los modelos y todas las fases de explotación de información MB: Experto en correlación del negocio y datos B: Experto en correlación de datos N: Datos desconocidos pero existe descripción de los datos N: Entre 30 y 50 atributos A: Entre 50 y 70 atributos MA: Más de 70 atributos B: Más cantidad de atributos no numéricos que de atributos numéricos A: Más cantidad de atributos numéricos que de atributos no numéricos MB: El equipo ha estado trabajando junto en los mismos tipos de proyectos de explotación de información igual al del nuevo proyecto y con datos similares B: El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto y con datos similares N: El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto pero con datos diferentes A: El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto pero nunca en el mismo ambiente Modelo Descriptivos MB: Hay más de 4 técnicas disponibles para generar el modelo N: Hay 2 técnicas disponibles para generar el modelo Valores Permitidos 2, 3, 4 2, 3, 4 0, 3, 5 2, 3, 4, 5 1, 2, 3 3, 4, 5 2, 4 1, 2, 3, 4 1, 3 Modelo Predictivos: 2, 4, 6 Ing. Pablo Pytel 450 Apéndice A

451 Factor de Costo Rangos Permitidos Valores Permitidos B: Hay más de 4 técnicas disponibles para generar el modelo A: Hay 3 técnicas disponibles para generar el modelo EA: Hay 1 técnica disponible para generar el modelo MTUP MB: Hasta 5 x 10 6 tuplas B: Entre 5 x 10 6 tuplas y 10 x 10 6 tuplas N: Entre 10 x 10 6 tuplas y 20 x 10 6 tuplas A: Entre 20 x 10 6 tuplas y 50 x 10 6 tuplas 1, 2, 3, 4 NATR B: De 500 a 1000 atributos N: De 1000 a 1500 atributos 2, 3 NDEP B: Participa 1 sólo Departamento N: Participan 2 Departamentos A: Participan de 3 a 5 Departamentos 2, 3, 4 NFOR B: Se requiere conocimiento en técnicas de explotación de información. Las herramientas usan asistente. N: Se requiere un pequeño conocimiento en técnicas de explotación de información y conocimiento en las herramientas. MA: Se requiere conocimiento experto en técnicas de explotación de información y en las herramientas. 2, 3, 5 NFUN N: De 2 a 3 fuentes de información heterogéneas disponibles A: Más de 3 fuentes de información heterogéneas disponibles sin datos en papel 3, 4 NMOD N: De 3 a 5 modelos A: De 5 a 7 modelos 3, 4 NTAB B: De 60 a 80 tablas N: De 80 a 100 tablas A: De 100 a 120 tablas 2, 3, 4 NTUP B: De 5 x 10 7 tuplas a 10 x 10 7 tuplas N: De 10 x 10 7 tuplas a 20 x 10 7 tuplas 2, 3 PNUL B: De 10 a 15% de valores NULL N: De 15 a 20% de valores NULL 2, 3 SCOM B: Todos los datos en la misma base de datos N: Todas las fuentes de datos en el mismo edificio comunicados a través de una red LAN A: Fuentes de datos en diferentes ubicaciones pero comunicadas 2, 3, 4 SITE MB: Comunicación interactiva multimedia en la misma ubicación B: Comunicación de gran ancho de banda con pocas videoconferencias en el mismo edificio o complejo 1, 2 Ing. Pablo Pytel 451 Apéndice A

452 Factor de Costo Rangos Permitidos Valores Permitidos TMOD TOOL Modelo Descriptivo: MB: Asociación B: Partición (Clustering) N: Patrones Secuenciales Modelo Predictivo: A: Clasificación MA: Predicción, Estimación o Series Temporales B: Herramientas usadas para más del 70% de los modelos A: Herramientas usadas para menos del 50% de los modelos 1, 2, 3 4, 5 2, 4 Tabla APA 3. Valores permitidos para Proyectos de Tamaño Mediano PROYECTOS GRANDES Los valores permitidos de los factores de costo para proyectos grandes se definen a continuación en la tabla APA 4. Factor de Costo ADIR COMP DEXT DISP DMOD DOCU Rangos Permitidos MB: La dirección del departamento y la organización apoyan al proyecto B: La dirección del departamento apoya al proyecto pero la dirección de la organización no lo apoya. N: La dirección del departamento apoya al proyecto y la dirección de la organización no se opone. EB: Total compatibilidad e integración con las herramientas disponibles en la organización N: Compatibilidad con editores de texto y planillas de cálculo disponibles en la organización MA: No hay compatibilidad con las herramientas disponibles en la organización A: De 5 a 7 fuentes externas de datos MA: Más de 7 fuentes externas de datos A: 0,6 H < 0,8 MA: 0,8 H 1 XB: Todos los modelos N: De 70 a 80% de los modelos MA: Menos del 60% de los modelos B: Documentación sólo para Modelos implantados N: Documentación para todos los modelos Valores Permitidos 1, 2, 3 0, 3, 5 4, 5 4, 5 0, 3, 5 2, 3, 4, 5 Ing. Pablo Pytel 452 Apéndice A

453 Factor de Costo KDAT MATRn MATRt MFAM MTEC MTUP NATR NDEP Rangos Permitidos generados A: Documentación para todos los modelos y fases centrales de explotación de información MA: Documentación para todos los modelos y todas las fases de explotación de información B: Experto en correlación de datos N: Datos desconocidos pero existe descripción de los datos A: No hay descripción de los datos o del modelo de datos A Entre 50 y 70 atributos MA Más de 70 atributos B: Más cantidad de atributos no numéricos que de atributos numéricos A: Más cantidad de atributos numéricos que de atributos no numéricos MB: El equipo ha estado trabajando junto en los mismos tipos de proyectos de explotación de información igual al del nuevo proyecto y con datos similares B: El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto y con datos similares N: El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto pero con datos diferentes A: El equipo ha trabajado en tipos de proyectos de explotación de información igual al del nuevo proyecto pero nunca en el mismo ambiente Modelo Descriptivos MB: Hay más de 4 técnicas disponibles para generar el modelo N: Hay 2 técnicas disponibles para generar el modelo Modelo Predictivos: B: Hay más de 4 técnicas disponibles para generar el modelo A: Hay 3 técnicas disponibles para generar el modelo EA: Hay 1 técnica disponible para generar el modelo A: Entre 20 x 10 6 tuplas y 50 x 10 6 tuplas MA: Más de 50 x 10 6 tuplas N: De 1000 a 1500 atributos A: De 1500 a 2000 atributos MA: Más de 2000 atributos A: Participan de 3 a 5 Departamentos MA: Participan más de 5 Departamentos Valores Permitidos 2, 3, 4 4, 5 2, 4 1, 2, 3, 4 1, 3 2, 4, 6 4, 5 3, 4, 5 4, 5 Ing. Pablo Pytel 453 Apéndice A

454 Factor de Costo Rangos Permitidos Valores Permitidos NFOR NFUN NMOD NTAB NTUP PNUL SCOM SITE TMOD TOOL B: Se requiere conocimiento en técnicas de explotación de información. Las herramientas usan asistente. N: Se requiere un pequeño conocimiento en técnicas de explotación de información y conocimiento en las herramientas. MA: Se requiere conocimiento experto en técnicas de explotación de información y en las herramientas. A: Más de 3 fuentes de información heterogéneas disponibles sin datos en papel MA: Más de 3 fuentes de información heterogéneas disponibles con datos en papel A: De 5 a 7 modelos MA: Más de 7 modelos MA: De 120 a 300 tablas EA: Más de 300 tablas A: De 20 x 10 7 tuplas a 50 x 10 7 tuplas MA: Más de 50 x 10 7 tuplas A: De 20 a 25% de valores NULL MA: Más de 25% de valores NULL A: Fuentes de datos en diferentes ubicaciones pero comunicadas MA: Fuentes de datos en diferentes ubicaciones pero no comunicadas A: Comunicación de poco ancho de banda en varias ciudades u organizaciones MA: Comunicación por teléfono o fax en varias ciudades u organizaciones EA: Comunicación internacional por teléfono o correo Modelo Descriptivo: MB: Asociación B: Partición (Clustering) N: Patrones Secuenciales Modelo Predictivo: A: Clasificación MA: Predicción, Estimación o Series Temporales B: Herramientas usadas para más del 70% de los modelos A: Herramientas usadas para menos del 50% de los modelos 2, 3, 5 4, 5 4, 5 5, 6 4, 5 4, 5 4, 5 4, 5, 6 1, 2, 3 4, 5 2, 4 Tabla APA 4. Valores permitidos para Proyectos de Tamaño Grande Ing. Pablo Pytel 454 Apéndice A

455 APÉNDICE B: MÉTODO DE SIMULACIÓN MONTECARLO B.1. INTRODUCCIÓN El método de simulación Montecarlo [Kalos & Whitlock, 1986; Peña Sánchez de Rivera, 2001] es un método no determinístico o estadístico numérico usado para aproximar expresiones matemáticas complejas y costosas de evaluar con exactitud. La invención del método de Montecarlo se asigna a Stanislaw Ulam y a John von Neumann en 1944 como herramienta para simular problemas probabilísticos de hidrodinámica concernientes a la difusión de neutrones en el material de fisión realizados en el Laboratorio Nacional de Los Álamos (EE.UU). Este trabajo conllevaba la simulación de problemas probabilísticos de hidrodinámica concernientes a la difusión de neutrones en el material de fisión. Esta difusión posee un comportamiento eminentemente aleatorio. Por eso el nombre del método hace referencia al Casino de Montecarlo (Principado de Mónaco) por ser la capital del juego de azar, al ser la ruleta un generador simple de números aleatorios. El método de Montecarlo proporciona soluciones aproximadas a una gran variedad de problemas matemáticos posibilitando la realización de experimentos con muestreos de números pseudo-aleatorios en una computadora. El método es aplicable a cualquier tipo de problema, ya sea estocástico o determinista. En problemas determinísticos se suelen utilizar uno o más de los parámetros como una distribución aleatoria y se simula dicha distribución. B.2. MODO DE USO Para realizar una simulación por el método Montecarlo se crea un modelo matemático del sistema, proceso o actividad que se quiera analizar, identificando aquellas variables de entrada (también llamadas variables independientes ) cuyo comportamiento aleatorio determina el comportamiento global del sistema (afectando a las llamadas variables dependientes ). En todo experimento, las variables son los eventos medibles en una investigación cuantitativa para evaluar el fenómeno bajo estudio. Las variables independientes son las controladas por el experimentador y que afectan a las variables dependientes, las cuales son las que se medirán para analizar el experimento. Por ejemplo: - En un experimento químico donde se quiere ver la reacción de una mezcla de sustancias, las variables independientes pueden ser la cantidad de sustancias a Ing. Pablo Pytel 455 Apéndice B

456 mezclar, mientras que las variables dependientes serán el tiempo y efecto de la reacción. - En un experimento psicológico sobre aprendizaje, las variables independientes pueden ser el tema a aprender y la cantidad de individuos por edad, mientras que las variables dependientes el resultado obtenido en los exámenes realizados. - En un experimento de Ingeniería en Software para comparar lenguajes de programación, las variables independientes pueden ser los requerimientos del software a desarrollar y la cantidad de individuos por experiencia, mientras que las variables dependientes pueden ser la cantidad de errores (bugs) en el software y el tiempo de desarrollo. Una vez identificados las variables, se lleva a cabo un experimento consistente en (1) generar muestras aleatorias con ayuda de una computadora para generar diferentes variaciones y (2) analizar el comportamiento del sistema ante los valores generados. Tras repetir n veces este experimento, se dispone de n observaciones sobre el comportamiento del sistema, lo cual es de utilidad para entender el funcionamiento del mismo. Así, el análisis será más preciso cuanto mayor sea el número n de experimentos que se lleven a cabo. B.3. EJEMPLO DE APLICACIÓN DE MÉTODO MONTECARLO Se considera un cuadrado de lado "l" con una circunferencia inscrita como se ve en la figura APB 1, y en la que se ve la relación matemática. Figura APB 1. Figura del Ejemplo Mediante una computadora se genera una serie de puntos al azar al azar para los diferentes valores de las coordenadas "x" e "y", imponiendo la condición de que todos los puntos generados estén dentro del cuadrado, es decir imponiendo: x l/2 e y l/2 Ing. Pablo Pytel 456 Apéndice B

457 Luego de generar puntos, aproximadamente entre y están en el círculo. La relación entre puntos que caen dentro del círculo y puntos totales debe ser igual a la relación entre áreas como se muestra en la figura APB 2. Figura APB 2. Relación Obtenida del Ejemplo Esto demuestra que la generación de una serie de puntos generados al azar permite el cálculo de una relación de áreas o también en área del círculo si se conoce la del cuadrado. Ing. Pablo Pytel 457 Apéndice B

458

459 APÉNDICE C: MANUAL DE USO DEL SISTEMA SOFTWARE C.1. INTRODUCCIÓN Esta sistema software tiene el objetivo de generar bancos de pruebas simulados con datos de proyectos de explotación de información para analizar el comportamiento del método de estimación Matemático Paramétrico de Estimación para Proyectos de Data Mining (en inglés Data Mining COst MOdel, o DMCoMo). Para ello se generan para cada proyecto las características relevantes al método DMCo- Mo (también denominadas factores de costo), considerando el tamaño de proyecto previamente seleccionado, y al que le aplican las fórmulas de estimación del método. Es recomendable para la utilización de este sistema y el análisis de los resultados generados tener conocimientos en los siguientes temas: Experimentación en Ingeniería Software. Métodos de Estimación de Software. Proyectos de Explotación de Información. Método de estimación DMCoMo. C.2. REQUERIMIENTOS MÍNIMOS DEL SISTEMA Para poder utilizar este sistema software se debe contar con una máquina que cumpla los siguientes requisitos mínimos: Entorno Hardware Sistema Operativo Software Adicional - Pentium III o superiores (2.0 GHZ) - 1 GB de memoria RAM (o más) - Disco rígido de 20 GB (o superior) Microsoft Windows XP, 2000, 7 o superior. Java Runtime Environment (JRE) 1.5 o posterior C.3. ACCESO AL SISTEMA Al hacer doble click en el acceso directo correspondiente al sistema se puede acceder a la aplicación. Al acceder al sistema, se muestra la pantalla de configuración de parámetros principales (explicada en la sección C.4.2). Ing. Pablo Pytel 459 Apéndice C

460 Figura APC 1: Pantalla de Acceso al Sistema C.4. FUNCIONALIDADES DEL SISTEMA A continuación se describen las funcionalidades provistas por el sistema software: C.4.1. MENÚ PRINCIPAL Para acceder a las diferentes funcionalidades provistas por el sistema software se cuenta con un menú en la parte superior de la pantalla. Figura APC 2: Menú Principal El menú cuenta con las siguientes opciones: Configurar Parámetros: permite acceder a la funcionalidad de configuración de los parámetros generales para generar el banco de pruebas (funcionalidad descripta en la sección C.4.2). Configurar Factores de Costo: permite realizar la configuración de cada uno de los factores de costo para generar el banco de pruebas (funcionalidad descripta en la sección C.4.3). Ing. Pablo Pytel 460 Apéndice C

461 Generar Proyectos Estimados: permite acceder a la funcionalidad de generación del banco de pruebas (funcionalidad descripta en la sección C.4.4). Mostrar Resultados: permite acceder a la funcionalidad de visualización de las estadísticas (funcionalidad descripta en la sección C.4.5). Además en la esquina superior derecha se encuentran las opciones del menú de windows para minimizar ( ), maximizar ( ) y cerrar la aplicación ( ). C.4.2. CONFIGURACIÓN DE PARÁMETROS GENERALES Esta funcionalidad permite configurar los parámetros generales que serán utilizados para generar el banco de prueba de datos de proyectos. Al seleccionar la opción Configurar Parámetros del menú se muestra la siguiente pantalla. Figura APC 3.1: Pantalla de Configuración de Parámetros Generales Ing. Pablo Pytel 461 Apéndice C

462 Esta pantalla se encuentra dividida en tres secciones: Tamaño de Proyecto a procesar: Esta sección de la pantalla permite al usuario restringir los valores de los factores de costo a generar por el sistema de acuerdo al tamaño de los proyectos de explotación de información que se quiere utilizar. Figura APC 3.2: Sección de Tipo de Proyecto a Evaluar El usuario solamente puede elegir una de las siguientes opciones disponibles: - Proyectos Pequeños: indica que sólo se generarán los valores de los factores de costo de proyectos considerados como pequeños (que deberían tener un esfuerzo menor a 2 años). - Proyectos Medianos: indica que sólo se generarán los valores de los factores de costo de proyectos considerados como medianos (que deberían tener un esfuerzo entre 2 años y 5 años). - Proyectos Grandes: indica que sólo se generarán los valores de los factores de costo de proyectos considerados como grandes (que deberían tener un esfuerzo mayor a 5 años). - Proyectos Aleatorios: indica que se generará cualquier combinación de los valores de los factores de costo sin ninguna restricción (este es el valor por defecto) Configurar Exportación de Datos: Esta sección de la pantalla permite al usuario indicar los parámetros para generar los archivos de salida con los datos de los proyectos generados y estimados por el sistema software. Para mayor información sobre el formato de los archivos de exportación se recomienda ver la sección C.5. Ing. Pablo Pytel 462 Apéndice C

463 Figura APC 3.3: Sección de Exportación de Datos En caso de decidir generar archivos de exportación, el usuario puede modificar el nombre de archivo por defecto ( data.csv ) escribiéndolo en la casilla de texto correspondiente y confirmando la acción al presionar la tecla <Enter>. Una vez que el nombre del archivo es el desea, el archivo puede ser creado presionando el botón <Crear archivo>. Si el archivo es creado exitosamente, se creará en el directorio de trabajo incluyendo la línea de título (ver sección C.5). En caso de que el archivo ya existiera se le pedirá al usuario confirmar la operación a través del siguiente mensaje: Figura APC 3.4: Mensaje de confirmación de sobrescribir archivo En caso de que sucediese un error al intentar crear, o sobrescribir un archivo existente, se muestran el siguiente mensaje de error: Figura APC 3.5: Mensajes de Error Ing. Pablo Pytel 463 Apéndice C

464 Finalmente, el usuario puede indicar si desea dividir los datos a ser exportados en múltiples archivos al seleccionar la opción Particionar archivos. En ese caso, el sistema permite además indicar la cantidad máxima de proyectos que se incluirán en cada archivo (por defecto el sistema utiliza la cantidad máxima de renglones permitidos por MS Excel 2010). Opciones Generales: Esta sección de la pantalla permite al usuario indicar si se desea generar todos los factores de costo aleatoriamente o no. Figura APC 3.6: Sección de Opciones Generales Por defecto el sistema software considera que se desea generar todos los factores de costo en forma aleatorio y el usuario no podrá modificar los valores de estos manualmente. Sin embargo, en caso necesario, el usuario podrá deseleccionar esta opción permitiéndole configurar manualmente los factores de costo a través de la funcionalidad descripta en la sección C.4.3. C.4.3. CONFIGURACIÓN DE FACTORES DE COSTO Esta funcionalidad permite configurar manualmente los valores de los factores de costo que serán utilizados para generar el banco de prueba. Al seleccionar el menú Configurar Factores de Costo, el sistema despliega las seis categorías de factores de costos definidas por el método DMCoMo: "Datos, la que a su vez muestra las sub-categorías Datos Iniciales, Dispersión, Calidad de los Datos, Disponibilidad del Modelo de Datos y Nivel de Privacidad de los Datos. Modelos. Plataforma. Técnicas y Herramientas. Ing. Pablo Pytel 464 Apéndice C

465 Proyecto. Personal. Figura APC 4.1: Menú de Configuración de Factores de Costo Al seleccionar una de estas categorías (o sub-categoría en caso de Datos ) se muestra una pantalla con una pestaña por cada uno de los factores de costo asociados a la categoría seleccionada. Si el usuario indico que desea generar todos los factores de costo aleatoriamente en la configuración general de parámetros, las opciones de esta pantalla estarán deshabilitadas. Sin embargo si indico que no desea generar los factores de costo aleatoriamente, podrá: - ingresar un valor específico para el factor de costo (en ese caso todos los proyectos generados tendrán el mismo valor) que será validada al presionar la tecla <Enter>, o - indicar que desea que este factor de costo sea generado aleatoriamente (en este caso los proyectos generados podrán tener valores diferentes). Figura APC 4.2: Pantalla de Configuración de Factores de Costo Ing. Pablo Pytel 465 Apéndice C

466 C.4.4. GENERAR DE PROYECTOS ESTIMADOS Esta funcionalidad permite generar los datos de los proyectos y su estimación para el banco de prueba. Al seleccionar la opción de menú Generar Proyectos Estimados se muestra la siguiente pantalla. Figura APC 5.1: Pantalla de Generar Proyectos Estimados La pantalla se encuentra dividida en dos secciones: Modo de Operación para Generar y Procesar Proyectos: Esta sección de la pantalla permite al usuario indiciar el modo de operación que el usuario desea utilizar para generar y procesar los proyectos de explotación de información. Figura APC 5.2: Sección de Modo de Operación Ing. Pablo Pytel 466 Apéndice C

467 El usuario solamente puede elegir entre siguientes opciones disponibles: - Modo uno por vez: este es el modo por defecto que se utiliza para generar y procesar a los proyecto de a uno por vez. Para utilizar este modo el usuario sólo debe presionar el botón <Calcular costo> cada vez que desee generar y procesar un nuevo proyecto. - Evaluación Continua: este modo hace que la herramienta comience a generar y procesar proyectos en forma automática hasta que el usuario decida parar. Para utilizar este modo se debe seleccionar la opción Evaluación Continua y presionar el botón <Comenzar>. El sistema software comenzará a generar y procesar proyectos en forma automática hasta que se presione el mismo botón, que ahora aparece con la leyenda <Parar>. La velocidad con que se generan y procesan los proyectos puede ser controlada a través del control Proyectos por segundo que aparece en la parte inferior de la pantalla. Figura APC 5.3: Sección de Modo de Operación Evaluación Continua no activado Figura APC 5.4: Sección de Modo de Operación Evaluación Continua activado Ing. Pablo Pytel 467 Apéndice C

468 - Análisis Completa: este modo genera y procesa todas las combinaciones válidas para el tipo de proyecto seleccionado durante la configuración, por lo que sólo funciona para proyectos pequeños, medianos y grandes pero no para los de tipo aleatorio. Para utilizar este modo se debe seleccionar la opción Análisis Completo y presionar el botón < Calcular costo>. Figura APC 5.5: Sección de Modo de Operación Análisis Completo A su vez, la herramienta posee un botón <Limpiar> que le indica que se desea realizar una nueva serie de simulaciones y por lo que se regresa a la pantalla de Configuración de Parámetros Generales. Por último, en el caso de que se haya configurado el sistema software para que se exporten los datos en archivo, se habilita la opción <Cerrar Archivo> que el usuario puede utilizar para indicar que se desea parar la exportación de los datos generados. Nótese que en caso de presionar el botón <Limpiar>, internamente también se realiza esta acción. Figura APC 5.6: Sección de Modo de Operación con botón <Cerrar Archivo> habilitado Ing. Pablo Pytel 468 Apéndice C

469 Resultados Generados: Esta sección de la pantalla permite al usuario visualizar los siguientes datos para los proyectos que se procesaron. Figura APC 5.7: Sección de Resultados Generados El usuario solamente puede ver los siguientes datos disponibles: - N o de Proyectos: que indica la cantidad de proyectos generados al momento. - Costo estimado por 23 FC: que muestra el último costo estimado utilizando la fórmula que aplica los 23 factores de costo. - Media del Costo por 23 FC: que muestra la media estadística del costo estimado utilizando la fórmula que aplica los 23 factores de costo. - Costo estimado por 8 FC: que muestra el último costo estimado utilizando la fórmula que aplica los 8 factores de costo. - Media del Costo por 8 FC: que muestra la media estadística del costo estimado utilizando la fórmula que aplica sólo 8 factores de costo. - Gráfico de Costos (23 FC vs. 8 FC): que muestra con el histograma de la estimación calculada para cada una de las fórmulas de estimación (utilizando el color azul para la fórmula de 23 factores de costo y el color rojo para la de sólo 8 factores de costo). Ing. Pablo Pytel 469 Apéndice C