Herramienta de Estimación del Esfuerzo en Proyectos...

Herramienta de Estimación del Esfuerzo en Proyectos de Explotación de Información

(DMCoMo)

Diego Cañete, Hugo Cerón, Germán Podestá

Cátedra Proyecto de Software Licenciatura en Sistemas

2010

2 Cañete Diego, Cerón Hugo y Podestá Germán

Índice

1. Requerimientos del Artefacto de Software…………..………………………4 2. Proceso de Selección del Modelo de Ciclo de Vida………………………..10 3. Procesos de Gestión del Proyecto…………………………………………..12

3.1. Proceso de Iniciación del Proyecto…………………………………12 3.1.1. Plan de Gestión de Proyecto………………………………..12

3.1.2. Plan de Retiro. ……………………………………………...18 3.2.. Proceso de Seguimiento y Control del Proyecto. ……………...……19 3.2.1. Análisis de Riesgo .……………………………….……...19

3.2.2. Plan de Contingencias. …………………………………..…19 3.2.3. Registro Histórico del Proyecto. …………………………...19

3.3. Proceso de Gestión de la Calidad del Software.…………………….19 3.3.1. Plan de Garantía de Calidad del Software. ………………...19 3.3.2. Recomendaciones de Mejora en la Calidad del Software…..21

4. Procesos de Pre-Desarrollo. ………………………………………………..22 4.1. Proceso de Exploración de Conceptos. ………………………………..22

4.1.1. Modelo de la Situación Actual. …………………………….22 4.1.2. Modelo del Dominio del Problema. ………………………..22 4.1.3. Informe Preliminar de las Necesidades. ……………………22 4.1.4. Soluciones Alternativas Posibles. ………………………….22 4.1.5. Soluciones Recomendadas. ………………………………..23 4.1.6. Plan de Transición. ………………………………………...23 4.2. Proceso de Asignación del Sistema. ………………………………..…24 4.2.1. Especificación de Requisitos Funcionales del Software……24 4.2.2. Especificación de Requisitos Funcionales del Hardware…..24 4.2.3. Especificación de la Interfaz del Sistema. …………………24 4.2.4. Descripción Funcional del Sistema. ………………………..25 4.2.5. Arquitectura del Sistema. …………………………………..29

5. Procesos de Desarrollo. …………………………………………………….31 5.1. Proceso de Requisitos. ………………………………………………...31

5.1.1. Especificación de Requisitos del Software. ………………..31 5.1.2. Requisitos de la Interfaz del Usuario. ……………………...32 5.1.3. Requisitos de la Interfaz con otro Software. ……………….33 5.1.4. Requisitos de la Interfaz con Hardware. …………………...33 5.1.5. Requisitos de la Interfaz con el Sistema Físico. …………...33 5.2. Proceso de Diseño. …………………………….………………………33 5.2.1. Descripción del diseño del software. ………………………33 5.2.2. Descripción de la arquitectura del software. ……………….33 5.2.3. Descripción del flujo de Información. ……………………..35 5.2.4. Descripción de la Base de Datos. …………………………..37 5.2.5. Descripción de las Interfaces. ……………………………...39 5.2.6. Descripción de los Algoritmos. ……………………………40 5.3. Proceso de Implementación. …………………………………………..40 5.3.1. Datos para las Pruebas. …………………………………….40 5.3.2. Documentación del Sistema. ……………………………….40

Índice 3

5.3.3. Documentación del Usuario. ………………………………53 5.3.4. Plan de Integración. …………………………………..……53 5.3.5. Sistema de Software Integrado. ……………………………53

6. Procesos de Post-Desarrollo. ………………………………………………54 6.1. Proceso de Instalación. ………………………………………………...54

6.1.1. Plan de Instalación del Software. …………………………..54 6.1.2. Informe de Instalación. …………………………………….54 6.2. Proceso de Operación y Soporte. …………………………………..….54 6.2.1. Histórico de Peticiones de Soporte. ………………………..54 6.3. Proceso de Mantenimiento. ……………………………………………54 6.3.1. Orden de Mantenimiento. ………………………………….55 6.3.2. Recomendaciones de Mantenimiento. ………………….…55 6.4. Proceso de Retiro.………….…….……….…….……..…………….…55 6.4.1. Plan de Retiro. .………….…….……….…….…….….……55

7. Procesos Integrales del Proyecto. .………….…….……….…….…….…...56 7.1. Proceso de verificación y validación. .…………….……….…….…56

7.1.2. Plan de Pruebas. .………….…….……….…….…….……..56 7.1.3. Informe de Pruebas. .………….…….……….……………..56 7.2. Proceso de Gestión de la Configuración. .………….…….…….……...57 7.2.1. Plan de Gestión de Configuración del Software……....……57

7.3. Proceso de Desarrollo de Documentación. .………….………….…….57 7.3.1. Plan de Documentación. .………….…….……….…….…..57 7.4. Proceso de Formación. .………….…….……….…….…….….………58 7.4.1. Plan de Formación. .………….…….……….…….……..…58

Anexo A:……………………………………………………………………………..59 Anexo B:……………………………………………………………………………..61 Anexo C: .……………………………………………………………………………65


Modelo de estimación de costos para un proyecto de explotación de datos (DMCoMo)

Cañete Diego, Cerón Hugo y Podestá Germán.

Cátedra Proyecto de Software, Licenciatura en Sistemas, Departamento de

Desarrollo Productivo y Tecnológico, Universidad Nacional de Lanús.

[email protected], [email protected] y [email protected]

1. Requerimientos del Artefacto de Software

Este documento describe los requerimientos de funcionalidades del artefacto que soportará el modelo propuesto por la tesis doctoral de Marbán, O. (2008). A cost model to estimate the effort of data mining proyect (DMCoMo).

1.1. Antecedentes

Este fragmento de los requerimientos se desarrollará en tres secciones, en la sección 1.1.1 mostraremos las generalidades sobre el artefacto software a desarrollar, después en la sección 1.1.2 veremos las variables que utilizaremos para el desarrollo de artefacto y mas abajo en la sección 1.1.3 se encuentran las ecuaciones principales para estimar el esfuerzo en un proyecto de extracción de datos.

1.1.1. Generalidades El estándar CRISP-DM supone un modelo de procesos en el cual se definen no sólo las fases, sino que también los procesos a realizar en cada una de ellas con las entradas y salidas correspondientes. CRISP-DM propone un modelo para el desarrollo de proyectos de extracción de datos, de forma similar que otros modelos de procesos para el desarrollo de software. Los modelos de procesos suponen una fase de gestión de proyectos, dentro de la cual una subtarea es siempre la estimación del esfuerzo y el tiempo que llevara el desarrollo del producto. Para realizar dicha estimación se han desarrollado distintos modelos, siendo los modelos matemáticos paramétricos una de las primeras metodologías de estimación de costes. El funcionamiento de estos modelos se fundamenta en la utilización de ecuaciones matemáticas mediante las cuales se obtiene el valor de un conjunto de variables dependientes, en función de los valores numéricos dados a otro conjunto de variables independientes de entrada. Como ejemplos de estos modelos matemáticos de estimación se destacan SLIM, SEERSEM, PRECIO-S y COCOMO entre otros. También existen modelos de este tipo en otros campos como pueden ser para el desarrollo del hardware o para

Modelo de estimación de costos para un proyecto de explotación de datos (DMCoMo) 5

proyectos de lanzamientos espaciales en la NASA. Sin embargo, no han propuesto modelos para la estimación de proyectos de extracción de datos.

Si bien, CRISP-DM, como modelo de proceso, contiene una subtarea que incluye la estimación del proyecto, no indica como estimar los proyectos de extracción de datos. Por tanto, se podría pensar en aplicar los modelos de estimación propuestos para el desarrollo de productos software (COCOMO, SLIM, etc.).

No obstante, los modelos de estimación que se utilizan en proyectos de construcción de software no resultan útiles para proyectos de extracción de datos, puesto que todos ellos utilizan como principal entrada el tamaño del software a construir. Por este motivo estos métodos de estimación no resultan validos para proyectos de extracción de datos, puesto que este tipo de proyectos no se trata de una herramienta software, que se puede medir en líneas de código, sino que el objetivo básico del proceso, trata de construir modelos que a partir de los datos de entrada permitan la obtención de patrones de datos.

La ausencia de un modelo de estimación de costes ha dado lugar a que muchos proyectos de minería de datos fracasen o no lleguen a concluirse. En consecuencia, [DMCoMo] propone diseñar y validar un modelo paramétrico, similar a COCOMO o SLIM, pero enfocado a proyectos de extracción de datos.

1.1.2. Variables de Entradas El modelo DMCoMo utiliza una serie de variables de costo. En la Tabla 1 se detallan las variables independientes.

Variable: Descripción Se obtiene por:

ADIR Nivel de la participación en los proyectos de extracción de datos de la dirección de la empresa para el que se desarrolla el proyecto de extracción de datos (apoyo, no apoyo).

Tabla.

DEXT Necesidad de adquisición de datos externos. Tabla.

DMOD Disponibilidad de modelos de datos para la realización del proyecto.

Tabla.

DOCU Tipo de documentación a entregar. Tabla.

KDAT Conocimientos de datos que se utilizan en los proyectos de extracción de datos.

Tabla.

Table 1.A: Variables de costo independientes.


NDEP Número de departamentos involucrados en el proyecto de extracción de datos.

Tabla.

NMOD Número de modelos. Tabla.

SCOM Distancia y forma de comunicación entre los orígenes de datos.

Tabla.

SITE Donde se encuentran ubicados los diferentes participantes en el proyecto de extracción de datos (Desarrollo en múltiples localizaciones).

Tabla.

TOOL Disponibilidad de herramientas. Tabla.

Table 2.B: Variables de costo independientes.

En la Tabla 2 se detallan las variables dependientes. Variable Descripción Se obtiene por

COMP Nivel de compatibilidad de las herramientas de extracción de datos, y forma de interacción de las herramientas con la complejidad de uso.

Tabla y ecuación.

DISP Dispersión o número diferentes de valores de atributos.

Tabla y ecuación.

MATR Número y tipo de atributos que se utilizan para la construcción de un modelo de extracción de datos.

Tabla y ecuación.

MFAM Familiaridad con el tipo de de problema de extracción de datos que a resolver.

Tabla y ecuación.

MTEC Disponibilidad de técnicas para el tipo de problema a tratar.

Tabla y ecuación.

MTUP Número de tuplas que se utilizan para la construcción de un modelo de extracción de datos.

Ecuación y tabla.

Table 3.A: Variables de costo independientes.


NATR Número de atributos que contienen las tablas iniciales.

Ecuación y tabla.

NFOR Nivel de formación de los usuarios que requieren las herramientas.

Tabla y ecuación.

NFUN Número y tipos de fuentes donde residan los datos.

Tabla y ecuación.

NTAB Número de tablas iniciales que se utilizan en un proyecto de extracción de datos.

Tabla y ecuación.

NTUP Número de tuplas que contienen las tablas iniciales.

Tabla y ecuación.

PNUL Porcentaje de valores nulos en los atributos iniciales.

Tabla y ecuación.

TMOD Tipo de modelo. Tabla y ecuación.

Table 4.B: Variables de costo independientes.

1.1.3. DMCoMo DMCoMO es el nombre que los autores han decidido llamar a dicho modelo paramétrico de estimación.

Con el propósito de construir el nuevo modelo, se comienza por definir todos los posibles factores que van a influir en la estimación del esfuerzo total del proyecto, tal y como se hace en los modelos de estimación paramétricos. El autor propone inicialmente una serie de parámetros denominados variables de coste que van a estar agrupados en 6 categorías diferentes:

• Costos de manejo de los datos: Hacen referencia al esfuerzo del manejo de los datos en el proyecto.

• Costos de los modelos: Referencia a la variabilidad, disponibilidad de los modelos de extracción de datos.

• Costos de desarrollo de la plataforma: Agrupa a las variables relacionadas con el esfuerzo requerido para integrar datos de las diversas fuentes de datos.

• Costos de las técnicas y herramientas: Hacen referencia a las técnicas y herramientas que pueden facilitar el desarrollo.

• Costos del proyecto: Se refieren al número de departamentos involucrados y el esfuerzo de integrarlos.


• Costos de integración del equipo: Tienen que ver con el personal de las diferentes áreas y como son las relaciones entre ellos.

Teniendo ya definidas las variables de coste, los autores recolectan los valores de estas variables de 40 proyectos ya finalizados utilizando un formulario que es llenado por los jefes de cada proyecto. Cada una de estas variables puede ser llenada con los siguientes valores: Extra Bajo. Bajo, Nominal, Alto, Muy Alto o Extra Alto. Adicionalmente, también se recolectan los datos de la duración de cada proyecto y la cantidad de personas involucradas en el mismo. Luego se traducen estos valores cualitativos a cuantitativos a través de la siguiente correlación: Extra Bajo, 0; Muy Bajo, 1; Bajo, 2; Nominal, 3; Alto, 4; Muy Alto, 5; Extra alto, 6 Más tarde se estudian las variables y las correlaciones entre ellas y deciden eliminar, de las variables correlativas, las menos significativas. Por lo que quedan 23 variables. Con las variables definidas, se puede aplicar la regresión lineal usando la siguiente ecuación:

(1)

En donde y es el esfuerzo en hombresxmes, xi son las variables de costo. Se obtiene como resultado los valores de los coeficientes ai. Obteniendo la ecuación del modelo DMCoMo:

E(p)=78,752 + 2,802 x NTAB + 1,953 x N T U P + 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

(2)

De esta manera se obtiene el primer modelo que emplea 23 variables. Después, se busca conseguir otro modelo con menos variables que sea útil para proyectos no tan definidos. Con este propósito, se analiza el significado de la ecuación anterior y se eliminan variables que son poco significativas de forma que no afecte demasiado al resultado. Y finalmente se crea una variación mas reducida del modelo anterior:

E(p) = 70,879 + 2,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

(3)

Por lo que se obtiene otro modelo mas reducido que emplea solo 8 variables para la estimación. Luego de obtener ambos modelos, se prueba su eficacia experimentando con valores de 15 nuevos proyectos. Habiendo realizado la estimación, se comparan los costos estimados con los costos reales obtenidos al finalizar los proyectos. Y al final se tiene que el margen de error del primer modelo de 23 variables está entre -16,908 y 16,908


(MM) y en el modelo con 8 variables el error está entre -23,105 y 23,105 (MM). Los márgenes de error son aceptables y por eso DMCoMo es un modelo de estimación útil.

1.2. Funcionalidades del Artefacto de Software

En este contexto, se plantea la necesidad de un artefacto de software que automatice la aplicación del modelo para estimar el esfuerzo en los proyectos de extracción de datos (DMCoMo). Las funcionalidades se agrupan en las siguientes categorías. − Privacidad:

• Cada usuario del sistema podrá identificarse valiéndose de un nombre de usuario y una contraseña.

• Agregar y quitar usuarios del sistema.

− Interfaz:

• Una interfaz Web para ingresar los valores de las variables correspondientes con el modelo, para luego obtener una estimación del costo.

• Prestar asistencia acerca de los datos que se deben ingresar en cada uno de los campos. Cada uno de estos campos contendrá una breve descripción de no más de tres renglones, que guíe al usuario a la hora de ingresar los datos.

• Facilitar las descripciones y terminologías serán traducidas en idioma castellano manteniendo el significado original propuesto en el documento.

− Módulo de Cálculo:

• Permitir elegir entre las ecuaciones (2) y (3) para estimar su proyecto.

• Poder ingresar la información de manera parcial y luego modificarla, completarla y/o consultarla en caso de error u omisión.


2. Modelo de Ciclo de Vida Seleccionado.

Luego de indagar acerca de las ventajas y desventajas de los diversos tipos de ciclo de vida decidimos utilizar principalmente el ciclo de vida Cascada Extendido para el desarrollo de la documentación y del artefacto de software. Las razones por las cuales se decidió optar por este ciclo de vida son: • Consideramos que los requisitos del sistema no van a variar a lo largo del proyecto. • Este modelo incorpora pruebas de unidad, pruebas de componentes, pruebas de

integración, pruebas del sistema software y pruebas de integración hardware y software. Y creemos que son un aspecto importante para el buen funcionamiento del sistema.

• Creemos que este modelo encaja adecuadamente porque es un software relativamente pequeño.

En contraste, no se seleccionó el ciclo de vida prototipazo para el desarrollo de la documentación y el artefacto de software debido a que se han estudiado con suficiente detenimiento los requisitos. Tampoco se seleccionó el modelo en espiral porque consideramos que las dimensiones del proyecto son pequeñas y los riesgos son bajos. Por lo que no vale la pena usar este modelo tan complejo. Ni tampoco se utilizará el ciclo de vida cascada convencional ya que no enfatiza la validación de los productos y en el proceso de composición existente en la construcción del sistema software. El modelo de ciclo de vida en cascada extendido se detalla en la Figura 1.

Fig. 1. Modelo de Ciclo de Vida Cascada Extendido

Con respecto a las interfaces con el usuario, en cambio, se decidió utilizar el modelo de ciclo de vida prototipado. Consideramos que las interfaces con el usuario son uno


de los componentes críticos de la aplicación, por lo tanto fallar en la interfaz usuario seguramente significará el fracaso en la implantación de la aplicación. Por lo que este ciclo de vida nos da la posibilidad de establecer un mayor diálogo con el usuario final. En la interfaz con el usuario, utilizar el ciclo de vida en cascada sería trabajoso, ya que los ciclos de desarrollo son largos. Y utilizar un modelo de ciclo de vida en espiral sería algo exagerado considerando los riesgos y las dimensiones del sistema de software a construir. En la Figura 2 que se muestra a continuación, se puede ver el orden de los procesos de este ciclo de vida:

Fig. 2. Modelo de Ciclo de Vida Prototipado.


3. Procesos de Gestión del Proyecto.

En la gestión del proyecto estableceremos condiciones para el desarrollo del mismo. Abarcando las actividades de planificación, estimación de recursos, seguimiento y control, y evaluación del proyecto.

3.1. Proceso de Iniciación del Proyecto.

Dentro de esta sección se agrupan las actividades de creación de la estructura del proyecto. Se define el ciclo de vida del software para este proyecto y se establecen los planes para su gestión. En la sección 3.1.1 se desarrolla el Plan de Gestión del Proyecto del Software.

3.1.1. Plan de Gestión del Proyecto. Seleccionado los modelos de ciclo de vida más adecuados para el proyecto, se procede a establecer el mapa de actividades correspondiente al proyecto que se muestra a continuación:

3.1.1.1. Mapa de Actividades Cascada Extendido: A continuación se mostrará el mapa de actividades del ciclo de vida cascada extendido:

ACTIVIDADES DE LOS PROCESOS RSG DP DD COD PU PC IS PSS ISH Proceso de Selección de un MCVS Identificar los posibles MCVS. x Seleccionar un modelo para el proyecto. x Proceso de Iniciación, Planificación y Estimación del Proyecto Establecer la matriz de actividades para el MCVS. x Asignar recursos del proyecto. x X X X x x X X X Definir el entorno del proyecto. X Planificar la gestión del proyecto. x Proceso de Seguimiento y Control del Proyecto Analizar riesgos. x X X X x x X X

Tabla 3.1.A: Mapa de Actividades del Ciclo de Vida Cascada Extendido.


Realizar la planificación de contingencias. X X X x x X Gestionar el proyecto. x X X X x X X X X Implementar el sistema de informes de problemas. X x X X X X Archivar registros. X X X x X X X X Proceso de Gestión de Calidad del Software Planificar la garantía de calidad del software. x X X X x X X X Desarrollar métricas de calidad. x X X X x x X X X Gestionar la calidad del software. x X X X x x X X X Identificar necesidades de mejora de la calidad. x X X X x x x X X Proceso de Exploración de Conceptos Identificar ideas o necesidades. x X Formular las soluciones potenciales. x X X Refinar y finalizar la idea o necesidad. x x x X X Proceso de Asignación del Sistema Analizar las funciones del sistema. x X X Desarrollar la arquitectura del sistema. x X X X x x Descomponer los requisitos del sistema. x X X X Proceso de Análisis de Requisitos Definir y desarrollar los requisitos de software. X X X x x x Definir los requisitos de la interfaz. X X Priorizar e integrar los requisitos del software. X X Proceso de Diseño Realizar el diseño preliminar. X Analizar el flujo de información. X X X Diseñar la base de datos. X X X x x x

Tabla 3.1.B: Mapa de Actividades del Ciclo de Vida Cascada Extendido.


Diseñar las interfaces. X X X x x x Seleccionar o desarrollar algoritmos. X X X Realizar el diseño detallado. X Proceso de Implementación e Integración Crear los datos de prueba. x x x X Crear el código fuente. X X Generar el código objeto. X X Crear la documentación de operación. x X X X x x x X X Planificar la integración. X X x Realizar la integración. x Proceso de Instalación y Aceptación Planificar la instalación. x x X X Distribuir el software. x x X X Cargar la base de datos. X x x x X X Instalar el software. x x X X Aceptar el software en el entorno de operación. x x X X Proceso de Operación y Soporte Operar el sistema. x x x X X Proceso de Mantenimiento No se realizarán tareas en este proceso. Proceso de Retiro No se realizarán tareas en este proceso. Proceso de Verificación y Validación Planificar la validación y verificación. x X X Ejecutar las tareas de verificación y validación. x X X X x x x X X Recoger y analizar los datos de las métricas. x X X X x x x X X Planificar las pruebas. X X X x x x X Desarrollar las especificaciones de las pruebas. X X X x x x Ejecutar las pruebas. x x x

Tabla 3.1.C: Mapa de Actividades del Ciclo de Vida Cascada Extendido.


Proceso de Configuración Planificar la gestión de la configuración. x X X Realizar la identificación de la configuración. X X X x x x X X Realizar el control de la configuración. X X X x x x X X Realizar la información del estado de la configuración. x X X x x x X X Proceso de Documentación Planificar la documentación. x x X X x x x X X Implementar la documentación. x x X X x x x X X Producir la documentación. x x X X x x x X X Proceso de Formación No se realizarán tareas en este proceso.

Tabla 3.1.D: Mapa de Actividades del Ciclo de Vida Cascada Extendido.

Acontinuación se mostrará que valor toma cada etapa del ciclo de vida castaca extendido:

RSG = Requisitos del Sistema Global DP = Diseño Preliminar DD = Diseño Detallado.

COD = Código PU = Prueba de Unidad

PC = Prueba de Componente IS = Integración del Software

PSS = Prueba del Sistema de Software ISH = Integración Soft-Hard

Tabla 3.2.: Descripciones de cada Etapa.


Notas relacionadas con el mapa Cascada Extendido: Conocidas las características del proyecto, se omiten las siguientes actividades:

– Proceso de Exploración de Conceptos: Dirigir los estudios de viabilidad; Planificar la transición del sistema; – Proceso de Instalación y Aceptación:

Realizar las actualizaciones; – Proceso de Operación y Soporte;

Proveer de asistencia técnica y consultas; Mantener el histórico de peticiones de soporte;

– Proceso de Mantenimiento: Realizar el mantenimiento correctivo; Reaplicar el ciclo de vida del software;

– Proceso de Retiro; Notificar al usuario; Conducir operaciones en paralelo; Retirar el sistema;

– Proceso de Formación: Planificar el programa de formación; Desarrollar los materiales de formación; Validar el programa de formación; Implementar el programa de formación;

3.1.1.2. Mapa de Actividades Prototipado: Notas relacionadas: Como se decidió utilizar el ciclo de vida prototipado solo para la interfaz con el usuario, este mapa de actividades solo abarca los procesos de:

– Proceso de Selección de un MCVS: Seleccionar un modelo para el proyecto, que se realizara en la fase de Recolección y Refinamiento de Requisitos.

– Proceso de Diseño: Realizar el diseño preliminar, que se realizara en la fase de Diseño Rápido. Diseñar las interfaces, que se realizara en la fase de Diseño Rápido. Realizar el diseño detallado, que se realizara en la fase de Refinamiento del Prototipo y Producto de Ingeniería.

– Proceso de Instalación y Aceptación: Distribuir el software, que se realizara en la fase de Evaluación del Prototipo por el Cliente.


3.1.1.3. Recursos Necesarios:

Recursos humanos. En la siguiente tabla se detallan los roles de cada integrante del proyecto:

Rol Abreviación Persona Descripción Desarrollador Des Podestá

Germán Desarrollo del artefacto y la documentación correspondiente.

Analista AnT Cerón Hugo Testeo el artefacto y la documentación correspondiente.

Líder de Proyecto

Lid Cañete Diego Control de la documentación y de las funcionalidades del equipo.

Tabla 3.5: Roles de los integrantes del proyecto. Recursos físicos: • Servidor Web con soporte PHP, con su Framework CodeIgniter y con base de

datos MySQL. También se utilizará el XE-macs 21.4.22 como editor de HTML y el TortoiseSVN para el desarrollo de todo el proyecto y su trabajo en paralelo.

• No se realizaran tareas de estimación de costos económicos por tratarse de un proyecto de índole estudiantil, por lo menos en esta etapa inicial.

• El tiempo requerido está delimitado por la cátedra en “Guía de artefacto softweare”, y mostraremos una aproximación mediante el diagrama de Gantt a continuación. La fecha estimada de la entrega final del proyecto impuesta por la cátedra es el 23 de noviembre del 2010 presentado con el artefacto software, toda la documentación correspondiente. En la columna de la izquierda se encuentran:

• Estudiar material (16/08/2010 a 31/08/2010); • Requerimientos Funcionales(30/08/2010 a 14/09/2010): • Documentar, desarrollar y probar el Artefacto Software Documentado.

(13/09/2010 a 26/10/2010); • Reporte Final (25/10/2010 a 09/11/2010); • Exposición (08/11/2010 a 23/11/2010);


A continuación se mostrará el Gantt sobre las etapas del proyecto:

Figura 3.3: Etapas del proyecto.

A continuación se muestra un segundo diagrama Gantt mostrando todos los procesos que se realizan para la documentación a partir del 13/09/2010 hasta 26/10/2010:

Figura 3.4. Gantt de los procesos del proyecto.

3.1.1.4. El Entorno del Proyecto: • A nivel global de gestión, el proyecto se llevara a cabo en un entorno

académico, más precisamente en la Universidad Nacional de Lanús. • Operativamente, el desarrollo se llevara a cabo respetando pautas

establecidas por la cátedra de la Licenciatura en Sistemas “Proyecto Software” en coordinación con el Departamento de Desarrollo Productivo y Tecnológico.

• Se tomara como guía el modelo propuesto por la tesis doctoral de Marbán, O. (2008). A cost model to estimate the effort of data mining proyect (DMCoMo).

• Usaremos la versión 1.7.1 del Framework CodeIgniter para Php, MySQL como la base de datos y un servidor gratuito.

3.1.2. Plan de Retiro. El estándar IEEE prevee la inclusión de un plan de retiro el cual no será tomado en cuenta porque el artefacto software no compromete a un sistema existente, ni otro recurso importante para su retiro.


3.2. Proceso de Seguimiento y Control del Proyecto.

En este proceso se realiza el análisis de los riesgos que permite identificar los problemas potenciales, determinar su probabilidad de ocurrencia y su impacto, y establecer los pasos para su gestión

3.2.1. Análisis de Riesgo. Para el Proyecto se contemplaran los siguientes riesgos posibles:

1. Perdida total o parcial de los datos de la base de datos durante el desarrollo de la aplicación.

2. Perdida total o parcial de los datos almacenados en la base de datos durante la implementación.

3. No contar con una conexión a Internet durante la exposición del proyecto.

3.2.2. Plan de Contingencias. 1. Perdida total o parcial de los datos de la base de datos durante el desarrollo

de la aplicación. • Se volverá a ingresar los datos, ya que son datos de prueba.

2. Perdida total o parcial de los datos almacenados en la base de datos durante la implementación. • Se realizaran copias de seguridad de la información de la base de datos

mensualmente que serán almacenadas en un dispositivo almacenamiento de la preferencia del cliente.

3. No contar con una conexión a Internet durante la exposición del proyecto. • Tener disponibles dos computadoras de las cuales, una actúe como el

servidor y la otra como el cliente o usuario.

3.2.3. Registro histórico del proyecto. Este proceso de la gestión de proyectos no se aplica al proyecto ya que este grupo no formó un proyecto anteriormente.

3.3. Proceso de Gestión de la Calidad del Software.

En esta sección se planifican y administran las acciones necesarias para proveer una confianza adecuada en la calidad del artefacto software.

3.3.1. Plan de Garantía de Calidad del Software. A lo largo del proyecto se aplican Métricas a fin de encontrar fallas que degraden la calidad del producto final y estudiarlas para corregirlas. Para cada una de las funcionalidades se realizarán pruebas de verificación y validación representadas en el diagrama de caso de uso en la sección 4.2.4. Descripción Funcional del Sistema, descripta más adelante. También se desarrollará un plan de pruebas en la sección 7 Procesos Integrales del Proyecto donde se desarrollará una etapa de pruebas de verificación y validación del


producto intentado probar si este esta construido satisfactoriamente y si esa construcción satisface a los requerimientos establecidos. A continuación se muestran las métricas y los indicadores usados a lo largo del proyecto:

Métrica Indicador El sistema debe ser de alta calidad y de una interfaz muy amigable con el usuario final.

Puntos de función determinada por las siguiente 5 características: -Número de entradas de usuario; -Número de salidas de usuario; -Número de petición de usuario; -Número de archivos; -Número de interfaces externas; Este indicador pretende medir la funcionalidad, independientemente de la tecnología utilizada para la construcción y explotación del artefacto software.

El sistema software debe desarrollarse sólo a lo largo de las primeras ocho semanas de todo el proyecto y con mayor énfasis sobre las últimas dos semanas después de haber terminado la documentación.

Relación con el número medio de errores encontrados de persona/líneas de código. Este indicador nos da una visión del proyecto para establecer, a los programadores, el tiempo de desarrollo del artefacto software.

Tabla 3.6: Metricas e indicadores del proyecto. A continuación mostraremos los Puntos de Función para el siguiente proyecto:

Factor de

Ponderación Parámetro de medición Cuenta Simple Media Compleja Número de entradas de usuario 10 x 3 4 6 = 60 Número de salidas de usuario 1 x 4 5 7 = 7 Número de petición de usuario 2 x 3 4 6 = 12 Número de archivos 9 x 7 10 18 = 162 Número de interfaces externas 5 x 5 7 10 = 50 Cuenta Total ····································································································> 291

Tabla 3.4: .Puntos de Función. La cuenta total se debe ajusta usando la siguiente ecuación, por lo tanto:


PF=291x(0,65+0,01x46) = 8834,76

3.3.2. Recomendaciones de Mejora en la Calidad del Software. Sugerencia de mejoras: • Con el fin de atenuar la pérdida de datos importantes imponer una política de

copias de seguridad en dispositivos externos, secuencial y semanal, en el mejor de los casos, contar con la posibilidad de migrar todo a un servidor con discos en espejo para una mejor recuperación de información.

• Contar con mínimamente 2 Gigabytes de memoria RAM en la PC. • Realizar encuestas periódicas a los miembros de la organización para comprobar el

nivel de conocimiento del plan estratégico y su aplicación a sus actividades así como la toma de conciencia sobre las necesidades del cliente.

• Un mayor ancho de banda con el servicio de Internet para una mejor performance del sistema con el usuario y del sistema para el procesamiento de los datos contenidos en el.

• Establecer reglas de seguridad informática para preservar los datos del cliente o usuarios del sistema.

• Formar reportes acerca del sistema, de los proyectos que contiene y de las copias de seguridad.


4. Procesos de Pre-Desarrollo.

En esta sección se desarrollarán los procesos que se deben realizar antes de que comience el desarrollo propiamente dicho. El esfuerzo del desarrollo se inicia con la identificación de una necesidad de automatización. Esta necesidad, para ser satisfecha, puede requerir una nueva aplicación, o un cambio de todo o parte de una aplicación existente.

4.1. Proceso de Exploración de Conceptos.

Este proceso incluye la identificación de una necesidad, la formulación de soluciones potenciales, su evolución y refinamiento a nivel de sistemas.

4.1.1. Modelo de la Situación Actual. La aparición del modelo CRISP-DM, supuso un modelo de procesos en el cual no sólo se definen las fases, sino que también se definen los procesos a realizar en cada una de ellas con las entradas y salidas correspondientes. El estándar propone un modelo para el desarrollo sistemas de extracción de datos.

4.1.2. Modelo del Dominio del Problema. El modelo CRISP-DM propone procesos de gestión de proyectos dentro de la cual una subtarea es siempre la estimación del esfuerzo y del tiempo que llevará el desarrollo del producto. Para realizar dicha estimación se han desarrollados distintos modelos de estimación siendo los modelos matemáticos paramétricos una de las primeras metodologías de estimación de costes desarrollados, pero si bien CRISP-DM incluye esta subtarea que incluye la estimación del proyecto no indica como estimarlo. Por lo tanto se podría aplicar los modelos de estimación propuestos para el desarrollo. No obstante, los modelos de estimación que se utilizan en los proyectos de construcción de software no resultan útiles para proyectos de extracción de datos.

4.1.3. Informe Preliminar de Necesidades. A fin de poder desarrollar correctamente el proyecto deberemos disponer de los siguientes recursos: • Lectura completa y reiterada como para contar con todas las herramientas

necesarias para desarrollar el artefacto software que se extiende en el articulo: A cost model to estimate the effort of data mining proyect (DMCoMo).

• Entorno de desarrollo en PHP con su Framework, CodeIgniter, en el que se desarrollará el patrón de diseño MVC (Model–View-Controller).

• Documentación acerca de estimación de proyectos ya realizados.


4.1.4. Soluciones Alternativas Posibles. En lo que refiere a las funcionalidades del sistema en si, no existen alternativas porque los requerimientos fueron establecidos sin lugar a variaciones. Es decir, los requerimientos establecen que se desarrolle el artefacto software utilizando una arquitectura de cliente/servidor en una plataforma Web. En cuanto a la implementación del artefacto de software, básicamente la codificación, se decide no contemplar soluciones alternativas. Ya que contemplar la utilización de otros lenguajes de programación, u otro Framework implicaría una suma adicional de tiempo y también, en el caso particular de otro lenguaje de programación, habría que consumir más recursos en aprender ese nuevo lenguaje.

4.1.5. Soluciones Recomendadas. En este contexto, se plantea la necesidad de un artefacto de software que automatice la aplicación del modelo para estimar el esfuerzo en los proyectos de extracción de datos (DMCoMo). Se decide utilizar el lenguaje de programación Php ya que es ampliamente usado en el ámbito Web, con el framework CodeIgniter (este, un potente framework Php con un tamaño muy pequeño, una herramienta simple, para crear aplicaciones Web con todas las funciones necesarias) y con MySQL para soporte de los datos, que corra sobre un servidor web Apache, permitiéndonos también una gran integración con MySQL y Php.

4.1.5.1. Privacidad: • Cada usuario del sistema podrá identificarse valiéndose de un nombre de

usuario y una contraseña. • Agregar y quitar usuarios del sistema.

4.1.5.2. Interfaz: • Una interfaz Web para ingresar los valores de las variables correspondientes con

el modelo, para luego obtener una estimación del costo. • Prestar asistencia acerca de los datos que se deben ingresar en cada uno de los

campos. Cada uno de estos campos contendrá una breve descripción de no más de tres renglones, que guíe al usuario a la hora de ingresar los datos.


4.1.5.3. Módulo de Cálculo: • Permitir elegir entre las ecuaciones (2) y (3) para estimar su proyecto. • Poder ingresar la información de manera parcial y luego modificarla,

completarla y/o consultarla en caso de error u omisión.

4.1.6. Plan de Transición. Este proceso contemplado por la IEEE 1074-1989 no se aplica.


4.2. Proceso de Asignación del Sistema.

Este proceso se realiza cuando el sistema requiere tanto del desarrollo de hardware como del software, o cuando no se puede asegurar que sólo se necesita desarrollo del software.

4.2.1. Especificación de Requisitos Funcionales del Software. Los requisitos del software se dividen dos partes: los requisitos de software del servidor y los del cliente. El sistema funciona en cualquier sistema operativo que corra el servidor apache pero las pruebas se van a llevar a cabo sobre un servidor con Linux que es el más extendido en los servidores Web. Servidor:

• Servidor Web Apache versión 2.2 en adelante. • PHP versión 5 en adelante integrado con Apache. • Plugin de conexión de PHP con MySQL. • Servidor de base de datos MySQL versión 5 en adelante.

Cliente: Para utilizar la aplicación debería bastar un navegador que cumpla con el estándar HTML versión 4 y CSS versión 2. Pero sólo se garantiza que funciona en los siguientes navegadores:

Internet Explorer 5 en adelante. Mozilla Firefox 1.5 en adelante.

4.2.2. Especificación de Requisitos Funcionales del Hardware. Este artefacto software requiere una computadora con un Hard Disk de 320 Gb y mínimamente con 2 Gb de memoria RAM. Que tenga instalada cualquier versión de Windows mayor a Windows Profesional o 2000, o cualquier otra distribución.

4.2.3. Especificación de la Interfaz del Sistema. El estándar IEEE prevee la inclusión de una especificación de la interfaz del sistema la cual no será tomado en cuenta porque el artefacto software no compromete una interfaz con otro software. Mostraremos los Prototipos de las vistas más a delante en el proyecto.


4.2.4. Descripción Funcional del Sistema. En la figura siguiente se muestra un diagrama de casos de uso de UML que muestra las funcionalidades principales del sistema:

Figura 4.1: Diagrama de casos de uso.

4.2.4.1. Descripción General. A continuación se muestra una referencia de cada uno de los casos de uso mostrados en el diagrama anterior. Referencia del caso de uso validar usuario:

Nombre del Caso de Uso: Validar usuario. ID Única: UC 001 Área: Sistema DMCoMo. Actor(es): Usuario. Descripción: El sistema se cerciora que el usuario que intenta

ingresar al sistema está entre los usuarios del sistema y ha ingresado la contraseña adecuada.

Activar Evento: El usuario se crea una cuenta, introduciendo un nombre, apellido, dirección de email, login, password y hace clic en Agregar Usuario, y el sistema valida al usuario.

Tipo de Señal: Externa. Pasos Desempeñados (ruta principal) Información para los Pasos

1. El usuario se conecta al programa vía Web. Conexión del usuario.

Tabla 4.1.A: Referencia del caso de uso validar usuario.


2. El estudiante ingresa nombre, apellido, dirección de email, login, password y hace clic en Agregar Usuario.

Nombre, apellido, dirección de email, login, password.

3. El sistema valida los campos. Validación de: nombre, apellido, dirección de email, login, password.

4. La página muestra la confirmación de usuario o los mensajes de error en caso contrario.

Pagina de confirmación.

Precondiciones: El usuario está en la vista Agregar Usuario.

Poscondiciones: El usuario se ah agregado exitosamente al sistema.

Suposiciones: El usuario tiene un navegador o browser, un nombre, login, una contraseña, email válido.

Reunir Requerimientos: Mostrarle al usuario si hay predisposición del usuario.

Aspectos Sobresalientes: ¿Se debe controlar el número de veces que el usuario ingresa al sistema?

Prioridad: Media.

Riesgo: Media.

Tabla 4.1.B: Referencia del caso de uso validar usuario.

Referencia del caso de uso registrar nuevo usuario:

Nombre del Caso de Uso: Registrar Nuevo Usuario. ID Única: UC 002 Área: Sistema DMCoMo. Actor(es): Usuario. Descripción: Se añade un nuevo usuario al sistema. Activar Evento: A partir de que el usuario hace clic en Agregar

Ususario el sistema lo valida y lo agrega a la base de datos.

. Tipo de Señal: Externa. Pasos Desempeñados (ruta principal) Información para los Pasos 1. El sistema recibe los nuevos campos. Nombre, apellido, dirección de

email, login, password. 2. El sistema valida los campos. Validación de: nombre, apellido,

dirección de email, login, password.

3. El sistema carga los campos a la base de datos. Carga de la base de datos.

4. El sistema envía la confirmación del nuevo usuario agregado.

Formulario de confirmación.

Tabla 4.2.A: Referencia del caso de uso registrar nuevo usario.


Precondiciones: El usuario está en la vista Agregar Usuario y el sistema validó los campos exitosamente.

Poscondiciones: El usuario fue agregado exitosamente.

Suposiciones: El usuario tiene un navegador o browser.

Reunir Requerimientos: Agregar al usuario al sistema.

Aspectos Sobresalientes: ¿El sistema deberá contar a cada usuario que ingresa y no se registra?

Prioridad: Media.

Riesgo: Media.

Tabla 4.2.B: Referencia del caso de uso registrar nuevo usario. Referencia del caso de uso estimar costos:

Nombre del Caso de Uso: Estimar Costos. ID Única: UC 003 Área: Sistema DMCoMo. Actor(es): Usuario. Descripción: El sistema realizará el cálculo de estimación de

costos del modelo DMCoMo. Activar Evento: Permite al usuario poder estimar el costo de un

proyecto de extracción de datos.

Tipo de Señal: El usuario ingresa todas las variables un hace clic en Enviar.

Pasos Desempeñados (ruta principal) Información para los Pasos

1. El sistema recibe las variables obtenidas. Variables de costo.

2. El sistema las junta en una solo array. Juntar variables.

3. El sistema suma y multiplica las variables. Suma y multiplicación de variables.

4. El sistema entrega el resultado final. Formulario con el resultado.

Precondiciones: El usuario debió primero Validar Usuario.

Poscondiciones: Permitió que el sistema Estimó los Costos.

Suposiciones: El sistema debe obtener todas las variables.

Reunir Requerimientos: Estimación de los variables de costos.

Aspectos Sobresalientes: ¿Se debe controlar las variables por si sucede algún imprevisto?

Prioridad: Media – Alta.

Riesgo: Media – Alta.

Tabla 4.3: Referencia del caso de uso estimar costos.


Referencia del caso de uso ingresar variables de costo: Nombre del Caso de Uso: Ingresar Variables de Costo. ID Única: UC 004 Área: Sistema DMCoMo. Actor(es): Usuario. Descripción: Permite completar los valores de las variables de

costes del modelo DMCoMo de un proyecto a estimar.

Activar Evento: El usuario creó una cuenta en el sistema y empieza a crear el proyecto para estimar su proyecto de extracción de datos.

Tipo de Señal: Externa.


1. El usuario crea la cuenta en el sistema. Página confirmación.

2. El usuario carga el sistema con las variables que se piden en la vista correspondiente.

Carga variables.

3. El usuario recibe el resultado del costo total de las variables.

Resultado variables.

Precondiciones: El usuario debió primero Validar Usuario. Poscondiciones: El usuario recibe la estimación del costo de las

variables. Suposiciones: El usuario tiene un navegador o browser y el proyecto

correspondiente para completar las variables de costo. Reunir Requerimientos: El sistema se cargará de las variables para estimar el

proyecto. Aspectos Sobresalientes: ¿El sistema tendrá que tener todos los campos llenos?

Prioridad: Alta.

Riesgo: Alta.

Tabla 4.4: Referencia del caso de uso ingresar variables de costo. Referencia del caso de uso mostrar estimación:

Nombre del Caso de Uso: Mostrar Estimación. ID Única: UC 005 Área: Sistema DMCoMo. Actor(es): Usuario. Descripción: Visualiza el resultado de aplicar el modelo

DMCoMo sobre las variables de costo ingresadas.

Activar Evento: El usuario debe hacer clic sobre el botón aceptar para que el sistema de el coste final.

Tipo de Señal: Interna. Tabla 4.7.A: Referencia del caso de uso mostrar estimación



1. El sistema recibe todas las variables subidas por el usuario.

Variables de costo.

2. El sistema guarda las variables en la base de datos.

Guardar variables.

3. El sistema valida que las variables sean correcta.

Validación de variables.

4. El sistema realiza la multiplicación y a suma total de las variables.

Operaciones de variables.

5. El sistema pasa las variables en un formulario.

Pasa como formulario.

6. El sistema muestra la estimación del proyecto

Mostrar la estimación.

Precondiciones: El usuario debió anteriormente Estimar Costos de su proyecto

Poscondiciones: El sistema va a Mostrar la Estimación.

Suposiciones: El usuario tiene un navegador o browser.

Reunir Requerimientos: Poder mostrar al usuario la estimación del proyecto.

Aspectos Sobresalientes: ¿Se debe contemplar la posibilidad de error máxima o mínima?

Prioridad: Alta.

Tabla 4.8.B: Referencia del caso de uso mostrar estimación

4.2.5. Arquitectura del sistema. El sistema presenta una arquitectura cliente/servidor clásica que se esquematiza en la siguiente figura. Se utilizó un Diagrama de Contexto, en dónde el cliente es representado como una entidad externa y el servidor el es el proceso principal, el sistema.


La siguiente figura muestra una arquitectura cliente/servidor clásica:

Figura 4.5: Diagrama de contexto.

4.2.5.1. Descripción de los Elementos. A continuación mostraremos una tabla con la descripción de los elementos:

Elemento Nombre Descripción

Entidad externa a

Computadora Usuario

Representa a la computadora que va a utilizar el usuario para conectarse al sistema. Es el cliente y se encarga de visualizar el resultado enviado por el servidor.

Proceso 0 Sistema DMCoMo

Representa a la computadora que va a alojar la aplicación. Es el servidor, el encargado del proceso de las variables.

Flujo F1 Petición al Sistema

Son las peticiones que va haciendo el usuario para interactuar con el sistema. Por ejemplo : Mostrar Proyectos Ingresados – Mostrar Estimación

Flujo F3 Página Web Es el resultado de la petición procesada por el sistema y lista para ser mostrada en un navegador Web.

Flujo F2 Variables de Proyecto

Son los datos del proyecto que se quiere estimar y que van a ser guardados en el servidor para la utilización posterior.

Flujo F4 Datos de Proyectos

Son los datos del proyecto que se utilizan para completar o modificar un proyecto de estimación.

Almacén D1

Datos Proyectos

Simboliza la base de datos en dónde serán guardados los datos de los proyectos de explotación de información que se quieran estimar.

Tabla 4.9: Descripción de los elementos


5. Procesos de Desarrollo.

Los procesos de diseño se deben realizar para la construcción del producto software. Estos definirán qué información obtener y cómo estructurar los datos, qué algoritmos usar para procesar los datos y cómo implementarlos y qué interfases desarrollar para operar con el software y cómo hacerlo.

5.1. Proceso de Requisitos.

Incluye las actividades interarias dirigidas al desarrollo de la Especificación de Requisitos del Software. Para la determinación completa y consistente de los requisitos de los datos, el procesamiento de los datos, las bases de datos, y las interfases del usuario, del software y del hardware.

5.1.1. Especificación de Requisitos del Software. DMCoMO es el nombre que los autores han decidido llamar a dicho modelo paramétrico de estimación. Con el propósito de construir el nuevo modelo, se comienza por definir todos los posibles factores que van a influir en la estimación del esfuerzo total del proyecto, tal y como se hace en los modelos de estimación paramétricos. El autor propone inicialmente una serie de parámetros denominados variables de coste que van a estar agrupados en 6 categorías diferentes: • Costos de manejo de los datos: Hacen referencia al esfuerzo del manejo de los

datos en el proyecto. • Costos de los modelos: Referencia a la variºabilidad, disponibilidad de los modelos

de extracción de datos. • Costos de desarrollo de la plataforma: Agrupa a las variables relacionadas con el

esfuerzo requerido para integrar datos de las diversas fuentes de datos. • Costos de las técnicas y herramientas: Hacen referencia a las técnicas y

herramientas que pueden facilitar el desarrollo. • Costos del proyecto: Se refieren al número de departamentos involucrados y el

esfuerzo de integrarlos. • Costos de integración del equipo: Tienen que ver con el personal de las diferentes

áreas y como son las relaciones entre ellos. Teniendo ya definidas las variables de coste, los autores recolectan los valores de estas variables de 40 proyectos ya finalizados utilizando un formulario que es llenado por los jefes de cada proyecto. Cada una de estas variables puede ser llenada con los siguientes valores: Extra Bajo. Bajo, Nominal, Alto, Muy Alto o Extra Alto. Adicionalmente, también se recolectan los datos de la duración de cada proyecto y la cantidad de personas involucradas en el mismo. Luego se traducen estos valores cualitativos a cuantitativos a través de la siguiente correlación: Extra Bajo, 0; Muy Bajo, 1; Bajo, 2; Nominal, 3; Alto, 4; Muy Alto, 5; Extra alto, 6 Más tarde se estudian las variables y las correlaciones entre ellas y deciden eliminar, de las variables correlativas, las menos significativas. Por lo que quedan 23 variables.


Con las variables definidas, se puede aplicar la regresión lineal usando la siguiente ecuación:

(4)

En donde y es el esfuerzo en hombresxmes, xi son las variables de costo. Se obtiene como resultado los valores de los coeficientes ai. Obteniendo la ecuación del modelo DMCoMo:

E(p)=78,752 + 2,802 x NTAB + 1,953 x N T U P + 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

(5)

De esta manera se obtiene el primer modelo que emplea 23 variables. Después, se busca conseguir otro modelo con menos variables que sea útil para proyectos no tan definidos. Con este propósito, se analiza el significado de la ecuación anterior y se eliminan variables que son poco significativas de forma que no afecte demasiado al resultado. Y finalmente se crea una variación mas reducida del modelo anterior:

E(p) = 70,879 + 2,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

(6)

Por lo que se obtiene otro modelo mas reducido que emplea solo 8 variables para la estimación. Luego de obtener ambos modelos, se prueba su eficacia experimentando con valores de 15 nuevos proyectos. Habiendo realizado la estimación, se comparan los costos estimados con los costos reales obtenidos al finalizar los proyectos. Y al final se tiene que el margen de error del primer modelo de 23 variables está entre -16,908 y 16,908 (MM) y en el modelo con 8 variables el error está entre -23,105 y 23,105 (MM). Los márgenes de error son aceptables y por eso DMCoMo es un modelo de estimación útil.

5.1.2. Requisitos de la Interfaz del Usuario. • A la interfaz se podrá ingresar a través de cualquier browser sea Chrome,

Firefox, etc. • Una interfaz Web para ingresar los valores de las variables correspondientes con

el modelo, para luego obtener una estimación del costo. • Prestar asistencia acerca de los datos que se deben ingresar en cada uno de los

campos. Cada uno de estos campos contendrá una breve descripción de no más de tres renglones, que guíe al usuario a la hora de ingresar los datos.



5.1.3. Requisitos de la Interfaz con Otro Software. Este proceso contemplado por la IEEE 1074-1989 no se aplica.

5.1.4. Requisitos de la Interfaz con Hardware. Este proceso contemplado por la IEEE 1074-1989 no se aplica.

5.1.5. Requisitos de la Interfaz con el Sistema Físico. Este proceso contemplado por la IEEE 1074-1989 no se aplica.

5.2. Proceso de Diseño.

Es el proceso central que unifica los procesos de desarrollo y de mantenimiento del artefacto software. Su objetivo es desarrollar una representación coherente y organizada del sistema software que satisfaga la Especificación de Requisitos del Software.

5.2.1. Descripción del Diseño del Software. El artefacto software esta montado sobre un ambiente Web, su estructura esta desarrollada bajo el patrón de diseño MVC explicado anteriormente. El Controlador invoca al Modelo que es el encargado de realizar los cálculos y el manejo de los datos. El Modelo devuelve los datos al Controlador para que se los envíe a la vista y esta lo formatee y los envíe al cliente como una página Web.

5.2.2. Descripción de la Arquitectura del Software. La figura a continuación simboliza la arquitectura que presentará el software. Se utilizó un DFD de nivel 1 utilizando como base el Diagrama de Contexto presentado en la Sección Arquitectura del Sistema:

Figura 5.1: DFD.

La arquitectura del software se centra en la utilización del patrón Modelo-Vista-Controlador. En dicha arquitectura, todas las peticiones al sistema se dirigen al


Controlador. El Controlador invoca al Modelo que es el encargado de realizar los cálculos y el manejo de los datos. El Modelo devuelve los datos al Controlador para que se los envíe a la vista y esta lo formatee y los envíe al cliente como una página Web.

5.2.2.1. Descripción de los elementos

A continuación se encuentra una tabla con la descpción de los elementos del dfd.. Elemento Nombre Descripción

Almacén D1 Datos Proyectos

Simboliza la base de datos en dónde serán guardados los datos de los proyectos de explotación de información que se quieran estimar.

Entidad externa a

Computadora Usuario

Representa a la computadora que va a utilizar el usuario para conectarse al sistema. Es el cliente y se encarga de visualizar el resultado enviado por el servidor.

Flujo F1 Petición al Sistema

Son las peticiones que va haciendo el usuario para interactuar con el sistema. Por ejemplo : Mostrar Proyectos Ingresados – Mostrar Estimación

Flujo F2 Variables de Proyecto

Son los datos del proyecto que se quiere estimar y que van a ser guardados en el servidor para la utilización posterior.

Flujo F3 Página Web Es el resultado de la petición procesada por el sistema y lista para ser mostrada en un navegador Web.

Flujo F4 Datos de Proyectos

Son los datos del proyecto que se utilizan para completar o modificar un proyecto de estimación.

Flujo F5 Datos a Mostrar

Son los datos que van a ser formateados por la Vista

Flujo F6 Petición de Datos

Orden del Controlador para procesar los datos.

Proceso 1 Controlador Es el módulo encargado invocar al Modelo y a las vistas según las peticiones del usuario

Proceso 2 Modelo Es el módulo que realiza el proceso de toda la información con la que trabaja el sistema.

Proceso 3 Vista Este módulo se encarga de transformar los datos del Modelo en una página web para que el usuario pueda interactuar con ella.

Tabla 5.1: Descpción de los elemntos del dfd.


5.2.3. Descripción del Flujo de Información. Representamos esta sección a través de diagramas de secuencia, en donde anteriormente en la sección 4.2.4. Descripción Funcional del Sistema mostramos su correspondiente Caso de Uso: -Corresponde a Validar Usuario:

Figura 5.2: Corresponde a Validar Usuario.

-Corresponde a Registrar Nuevo Usuario:

Figura 5.3: Corresponde a Registrar Nuevo Usuario.


-Corresponde a Estimar Costos:

Figura 5.6: Corresponde a Estimar Costos.

-Corresponde a Ingresar Variables de costo:

Figura 5.5: Corresponde a Ingresar Variables de costo


-Corresponde a Mostrar Estimación:

Figura 5.6: Corresponde a Mostrar Estimación.

5.2.4. Descripción de la Base de Datos. En la siguiente imagen se encuentra el DER de la base de datos:

Figura 5.7: DER de la base de datos.


5.2.4.1. Entidades y atributos. A continución mostraremos las entidades y atributos del DER:

USUARIO PROYECTO VARIABLE ARDELPROY CORRELACION

Login idProyecto invariable R2 R5

Nombre nombreProy Abrev R3 Abrev

Apellido R1 Descripción Valor Descripción

Password Coeficiente Valor

Tabla 5.2: Entidades y atributos del DER.

5.2.4.2. Descripción de las entidades y atributos. -Correlacion

Nombre Dominio Descripción

IdVariable (R5) Entero(11) Número de identificación de la variable.

Denominacion 'Extra Bajo', 'Bajo',

'Nominal', 'Alto', 'Muy Alto', 'Extra Alto'

Descripción cualitativa del valor que recibe la variable.

Descripcion Texto(255) Texto descriptivo que orienta acerca de que valor debe tomar la variable.

valorNum Entero(4) Valor que indica la apreciación cuantitativa de la variable de costo.

Tabla 5.3: Correliación. -Proyecto Nombre Dominio Descripción

idProyecto Entero(11) Número identificador del proyecto.

nombre Texto(45) Nombre del proyecto.

login (R1) Texto(45) Login del usuario dueño del proyecto. Tabla 5.4: Proyecto.


-Usuario

Nombre Dominio Descripción

login Texto(45) Nombre que identifica al usuario en el sistema

nombre Texto(45) Primer nombre del usuario.

apellido Texto(45) Apellido del usuario

email Texto(45) Dirección de mail del usuario.

Password Texto(33) Contraseña del usuario. Se almacena encriptada en md5.

Tabla 5.5: Usuario. -VarDelProy Nombre Dominio Descripción

IdProyecto (R2) Entero(11) Número identificador del proyecto.

idVariable (R3) Entero(11) Número identificador de la variable

Valor 1, 2, 3, 4 o 5 Valor que toma la variable para este proyecto.

Tabla 5.6: VarDelProy. -Variable Nombre Dominio Descripción

idVariable Entero(11) Número identificador de la variable.

Abrev Texto(4) Abreviación de 4 letras en mayúscula que identifica a la variable.

Descripcion Texto(255) Texto descriptivo de lo que requiere la variable.

Coheficiente Decimal Número decimal que corresponde con el coheficiente de la regresión lineal de una variable.

Tabla5.7: Variables.

5.2.5. Descripción de las Interfaces. El artefacto software divide sus interfaces en diferentes vistas desarrolladas bajo el Ciclo de Vida Prototipado, estas vistas pueden ser las de administrador o de usuario final, el administrador se encargará, (a través de un formulario de la vista Solicitar Usuario) que deberá llenar el usuario final con sus datos correspondientes, de darle un usuario y contraseña al usuario final. Con respecto a las vistas del usuario serán de ayuda para este, guiaran al usuario final para el perfecto desarrollo de la estimación del proyecto a estimar, en donde cada paso o proceso de la estimación irá acompañado de la ayuda correspondiente para un mejor entendimiento del desarrollo del proyecto.


5.2.6. Descripción de los Algoritmos. El modelo va a almacenar el único algoritmo que va a intervenir en el MVC, y es el que calculará el costo del proyecto. Por lo que solamente hay validaciones y todas las cuestiones de la presentación de los datos que están ligadas con la implementación propia de las herramientas que utilizamos almacenadas dentro del MVC para la estimación del proyecto correspondiente.

5.3. Proceso de Implementación.

Este proceso transforma la representación del diseño detallado de un producto software a una realización en un lenguaje de programación apropiado. El proceso de implementación produce el código fuente, el código de la base de datos y la documentación, que constituyen la manifestación física del diseño de acuerdo a los estándares y metodologías del proyecto.

5.3.1. Datos para las Pruebas.

Los datos para las pruebas se encuentran detallados en el Anexo A: Datos de Prueba.

5.3.2. Documentación del Sistema. El modelo DMCoMo utiliza una 23 variables de costo para calcular el esfuerzo empleado en un proyecto de extracción de datos. Detalladas a continuación:

5.3.2.1. NTAB (numero de tablas): Este factor hacer referencia al numero inicial de tablas que se tendrán en consideración al comienzo del proyecto, o lo que es lo mismo hace referencia al número de tablas que albergan fuentes u orígenes de datos (ficheros, bases de datos, etc,)

Rango Descripción Valor Extra bajo Hasta 20 tablas 0 Muy bajo Desde 20 a 50 tablas 1 Bajo Desde 50 hasta 80 tablas 2 Nominal Desde 80 hasta 100 3 Alto Desde 100 hasta 200 talbas 4 Muy alto Desde 200 hasta 300 tablas 5 Extra alto Mas de 300 tablas 6

Tabla 5.8: Factor NTAB

5.3.2.2. NTUP (número de tablas): Este factor considera el número inicial de tuplas que contienen las tablas que se van a tener en cuenta a la hora de comenzar el proyecto. La forma de calcular el número


total de tupas es la siguiente.

(7)

En donde ntab es el número de tablas a considerar y ntup es el número de tuplas de la tabla iesima. Si los datos residen en un Sistema Gestor de Bases de Datos, la forma de calcular el número de tuplas se puede realizar mediante consultas SQL sobre las tablas de la base de datos. Una vez calculado el número de tuplas se utiliza el siguiente cuadro para obtener el valor de este driver:

Rango Descripción Valor Muy bajo Menos de 5 * tuplas 1

Bajo Entre 5 * y 10 * tuplas 2

Nominal Entre 10 * y 20 * tuplas 3

Alto Entre 20 * y 50 * tuplas 4

Muy alto Más de 50 * tuplas 5

Tabla 5.9: Factor NTUP

5.3.2.3. NATR (numero de atributos): Este driver de coste tiene en cuenta el esfuerzo introducido en la realización de un proyecto de Data Mining debido al número inicial de atributos que contienen las tablas candidatas a ser consideradas en el proyecto.

(8)

Donde ntab es el numero de tablas y natri es el numero de atributos de la tabla iesima. Para obtener los valores que se utilizan en las ecuaciones del modelo se utiliza el siguiente cuadro:

Rango Descripción Valor Muy bajo Menos de 500 atributos 1 Bajo Entre 500 y 1000 atributos 2 Nominal Entre 1000 y 1500 atributos 3 Alto Entre 1500 y 2000 atributos 4 Muy alto Mas de 2000 atributos 5

Tabla 5.10: Factor NATR 5.3.2.4. DISP (dispersión de valores de los atributos): Este driver esta definido como el número de diferentes valores en el dominio de los atributos. Como medidas de dispersión de los datos, se pueden utilizar medidas estadísticas, tales como la varianza o la desviación típica, si los datos son cuantitativos, y si los datos son cualitativos se puede emplear la entropía de la información definida por Shanon u otras medidas tales como asignar valores a las


categorías, si tienen un orden, teniendo en cuenta que la diferencia entre cada categoría es la misma y luego aplicar la varianza estadística sobre las categorías en forma numérica. En caso de los proyectos de Data Mining los valores de las variables que se están utilizando pueden ser tanto cuantitativas como cualitativas, para solucionar este problema se ha optado por utilizar una combinación de la varianza, para los atributos cuantitativos, y de la entropía propuesta por Shannon para los atributos cualitativos. La varianza se define de la siguiente manera:

(9)

En donde k es el número de observaciones de la variable, x es la medida de los valores de la variable analizada, es el valor iésimo que toma la variable, es el número de veces que la variable toma el valor y N es el numero total de observaciones o valores que toma la variable analizada. La entropía se define como:

H=- (10)

En donde H representa la entropía del sistema, es la probabilidad del elemento , y M es el número de elementos que aparecen en el sistema. Para calcular el valor del driver de coste DISP, se calcula la varianza de cada uno de los atributos cuantitativos y la entropía de cada uno de los atributos cualitativos. Posteriormente para el cálculo final del driver se aplica la siguiente ecuación:

DISP= (11)

Siendo el numero de atributos cuantitativos, el numero de los atributos cualitativos, V la varianza y M la media de todos los calores de las varianzas y las entropías de los atributos. La resta de M y la división por V se hace para normalizar los valores de la dispersión de los atributos en el intervalo [0,1. De la siguiente tabla se saca el valor final de DISP:

Rango Descripción Valor Muy bajo 0≤H<0,2 1 Bajo 0,2≤H<0,4 2 Nominal 0,4≤H<0,6 3 Alto 0,6≤H<0,8 4 Muy alto 0,8≤H≤1 5

Tabla 5.11: Factor DISP

5.3.2.5. PNUL (porcentaje de nulos): Este factor se refiere al esfuerzo que se realiza para el tratamiento de los valores nulos que aparecen en los valores iniciales de los datos. El valor PNUL se obtiene redondeando la suma de los valores PNULp de cada atributo dividido entre el número total de atributos tal y como se muestra próximamente:


Primero se obtiene el valor de los diferentes PNUL utilizando la siguiente tabla:

Rango Descripción Valor Muy bajo Hasta un 10% de valores nulos 1 Bajo Desde un 10% hasta un 15% de valores nulos 2 Nominal Desde un 15% hasta un 20% de valores nulos 3 Alto Desde 20% a 25% de valores nulos 4 Muy alto Mas de 25% de valores nulos 5

Tabla 5.12: PNULp: Factor PNUL para cada atributo Luego con la siguiente ecuación se el valor final de PNUL:

PNUL=ROUND (12)

Siendo n el numero total de atributos a tratar. El redondeo y la división entre el número total de atributos se hace para dejar un valor entero y normalizado entre 1 y 5 para que el valor total se corresponda con alguno de los valores de los rangos del driver de coste que se muestra a continuación:

Rango Descripción Valor Muy bajo 1 1 Bajo 2 2 Nominal 3 3 Alto 4 4 Muy alto 5 5

Tabla 5.13: Factor PNUL 5.3.2.6. DMOD (disponibilidad de los modelos de datos): Este driver toma en cuenta la disponibilidad de los modelos de datos. El rango, la descripción de cada rango y los valores correspondientes que se utilizaran en el cálculo del esfuerzo para el factor DMOD se pueden observar en la siguiente tabla. A continuación mostraremos cada rango y los valores correspondientes que se utilizaran en el cálculo del esfuerzo para el factor DMOD:

Rango Descripción Valor Extra bajo Todos los modelos documentados 0 Muy bajo El 90% de los modelos disponibles 1 Bajo Entre el 80%% y el 90% de los modelos

disponibles 2

Nominal Entre el 70%% y el 80% de los modelos disponibles

3

Alto Entre el 60%% y el 70% de los modelos disponibles

4

Muy alto Menos del 60% de los modelos disponibles

5

Tabla 5.14: Factor DMOD


5.3.2.7. DEXT (necesidad de adquisición de datos externos): Este driver estudia la necesidad de utilizar datos externos a la organización para la cual se realiza el proyecto, por ejemplo datos geográficos del estilo de las bases de datos MOSAIC. Los valores a utilizar para el cálculo del esfuerzo y la forma de seleccionarlos se describe en la siguiente tabla:

Rango Descripción Valor Bajo Entre 1 y 3 fuentes son externas 2 Nominal Entre 3 y 5 fuentes son externas 3 Alto Entre 5 y 3 fuentes son externas 4 Muy alto Mas de 7 fuentes son externas 5

Tabla 5.15: Factor DEXT

5.3.2.8. NMOD (numero de modelos): El factor NMOD tiene en cuenta el número de modelos que hay que generar como proceso del resultado de Data Minning. Esta claro que cuantos mas modelos se tengan que entregar mayor será el esfuerzo que hay que realizar. En la tabla que se muestra a continuación se presenta la forma de seleccionar los valores para este factor de coste:

Rango Descripción Valor Bajo De 1 a 3 modelos 2 Nominal De 3 a 5 modelos 3 Alto De 5 a 7 modelos 4 Muy alto Mas de 7 modelos 5

Tabla 5.16: Factor NMOD

5.3.2.9. TMOD (tipo de modelo): El valor de este driver esta dado por el tipo de modelo o modelos que hay que generar, ya que no requiere el mismo esfuerzo obtener un modelo predictivo que un modelo descriptivo. Para calcular el valor de este driver de coste, primero hay que hacer uso de la siguiente tabla y obtener el valor TMOD:

Rango Descripción Valor Muy bajo Modelo descriptivo: asociación 1 Bajo Modelos descriptivo: clustering 2 Nominal Modelo descriptivo: patrones secuenciales 3 Alto Modelo predictivo: clasificación 4 Muy alto Modelo predictivo: predicción o estimación o series

temporales 5

Tabla 5.17: TMODp: Factor TMOD para cada modelo

El valor TMOD por lo tanto se obtiene redondeando la suma de los valores TMOD de cada modelo dividido entre el número total de modelos mediante la siguiente ecuación:

TMOD=ROUND (13)


Finalmente, una vez obtenido el valor de TMOD, el valor final de este driver estará dado por la siguiente tabla:


Tabla 5.18: Factor TMOD

5.3.2.10. MTUP (numero de tuplas): Este driver de coste representa el número de tuplas que utilizara cada modelo. El valor de este modelo se obtiene de manera similar al driver anterior. De la próxima tabla obtenemos el valor de MTUP:

Rango Descripción Valor Muy bajo Menos de 5 * tuplas 1

Bajo Entre 5 * y 10 * tuplas 2

Nominal Entre 10 * y 20 * tuplas 3

Alto Entre 20 * y 50 * tuplas 4

Muy alto Más de 50 * tuplas 5

Tabla 5.19: MTUPp: Factor MTUP para cada modelo

La reducción de magnitud del número de tuplas para los modelos frente al nmero de tuplas totales que se utilizaran para el proyecto tiene que ver con que los datos ya se encuentran procesados y se habrán eliminado aquellas tuplas que no son necesarias para el modelo) ahora aplicamos la ecuación:

MTUP=ROUND (14)

Y obtendremos el valor final usando la tabla.


Tabla 5.20: Factor MTUP


5.3.2.11. MATR (número y tipos de atributos): Este driver toma en consideración el número de atributos utilizados para cada modelo. Los atributos pueden ser cuantitativos o cualitativos. Primeramente se obtiene el valor de coste para los atributos cuantitativos y cualitativos usando las siguientes tablas:

Tabla 5.21: MATRnp: Factor MATRn para cada modelo

La siguiente tabla muestra como se obtiene los valores de MATR:

Rango Descripción Valor Muy bajo Todos los atributos no numéricos 1

Bajo Mayor numero de atributos no numéricos que numéricos 2

Nominal 50% de atributos numéricos y 50% de atributos no numéricos 3

Alto Mayor numero de atributos numéricos que no numéricos 4 Muy alto Todos los atributos numéricos 5

Tabla 5.22: MATRtp: Factor MATRt para cada modelo

MATRn=ROUND

MATRt=ROUND

Próximamente obtenemos el valor de MATR con la siguiente ecuación:

MATR=TRUNC

Donde TRUNC es la función que solo devuelve la parte entera del número que se le pasa como parámetro, finalmente comparamos este resultado en la siguiente tabla y obtenemos el valor del driver MATR:


Tabla 5.23: Factor MATR

Rango Descripción Valor Muy bajo Menos de 10 atributos 1 Bajo Entre 10 y 20 atributos 2 Nominal Entre 20 y 50 atributos 3 Alto Entre 50 y 70 atributos 4 Muy alto Mas de 70 atributos 5


5.3.2.12. SITE (desarrollo para varias localizaciones): El valor de este factor se basa en si el desarrollo se lleva a cabo en la misma localización o en diferentes lugares. En la siguiente tabla se muestran la descripción y el valor para cada nivel del rango de este factor:

Descripción Rango

Ubicación Comunicaciones Valor

Muy bajo En el mismo lugar Comunicación multimedia interactiva

1

Bajo Mismo edificio o compleajo

Banda ancha de comunicaciones y ocasionalmente videoconferencia

2

Nominal Misma ciudad o area metropolitana

Banda ancha de comunicaciones

3

Alto Varias ciudades y varias compañías

Banda estrecha de comunicaciones, e-mail

4

Muy alto Varias ciudades y varias compañías

Teléfono, fax 5

Extra alto Internacional Teléfono, correo 6 Tabla 5.24: Factor SITE

5.3.2.13. KDAT (conocimiento de los datos que se van a utilizar): KDAT tiene en cuenta si los participantes del proyecto conocen los datos que van a utilizar para el proyecto y los han manejado con anterioridad. Si los datos son conocidos y han sido utilizados con anterioridad el esfuerzo será menos que si se van a utilizar por primera vez y sin un conocimiento previo de los datos. Al igual que el driver anterior, este también se obtiene mediante una tabla:

Rango Descripción Valor Muy bajo Hay colaboración de personal experto en los datos para ayudar al

entendimiento de los mismos y colaboración de un experto en el negocio

1

Bajo Hay colaboración de personal experto en los datos para ayudar el entendimiento de los mismo

2

Nominal El equipo no esta familiarizado con los datos y se suministra una descripción de los mismos que no tiene porque ser real

3

Alto Nos hay descripción de los datos ni modelo de datos 4

Tabla 5.25: Factor KDAT 5.3.2.14. ADIR (actitud de la dirección del proyecto): Este factor tiene en cuenta la facilidad que da la dirección de la empresa a los participantes en el proyecto de Data Mining para utilizar los datos, para moverse entre los diferentes sistemas de la organización. Si la organización facilita este trabajo el


esfuerzo será menor. Este factor también se obtiene por tabla:

Tabla 5.26: Factor ADIR 5.3.2.15. MFAM (familiaridad con el tipo de problema): El valor de este factor esta dado por el grado de familiaridad que tienen los participantes en el proyecto con el problema a resolver, ya que si los participantes conocen el problema, el esfuerzo para resolverlo será menor. Para obtener el valor de este driver, primeramente tenemos que obtenel el valor de MFAMp de cada subproblema mediante la siguiente tabla:

Rango Descripción Valor Muy bajo Los participantes en el proyecto siempre trabajan con el tipo de

problema de Data Mining del proyecto actual y con datos similares

1

Bajo Los participantes en el proyecto han trabajado en problemas de Data Mining como el actual y con datos similares

2

Nominal 12% Los participantes en el proyecto han trabajado en problemas de Data Mining pero no con datos del proyecto real

3

Alto 12% Los participantes en el proyecto han trabajado en problemas de Data Mining pero nunca en el entorno del proyecto actual

4

Muy alto Los participantes en el proyecto no han trabajado en problemas de Data Mining

5

Tabla 5.27: MFAMp: Factor MFAM para cada modelo Luego hacemos la sumatoria de MFAMp de cada uno de los subproblemas mediante la siguiente ecuación:

MFAM=ROUND

Siendo n el numero de subproblemas en los que se descompone el problema global.

Rango Descripción Valor Muy bajo La dirección del departamento y la empresa apoyan

positivamente el proyecto de Data Mining 1

Bajo La dirección del departamento apoya el proyecto pero la de la empresa no

2

Nominal El director del departamento involucrado apoya el proyecto y la dirección no se opone al proyecto

3

Alto La dirección del departamento no apoya o esta en contra de los procesos de Data Mining y la dirección de la empresa no apoya el proyecto

4


Y finalmente mediante la siguiente tabla obtenemos el valor final para este factor:


Tabla 5.28: Factor MFAM 5.3.2.16. DOCU (documentación a entregar): Este factor de escala refleja el esfuerzo empleado en producir la documentación que hay que desarrollar durante el proyecto de acuerdo a las exigencias del cliente y de la organización. El valor de este driver esta dado por la siguiente tabla:

Rango Descripción Valor Bajo Solo se genera documentación para el modelo que se implanta

finalmente 2

Nominal Se genera documentación para todos los modelos generados 3 Alto Se genera documentación para todos los modelos y además se crea

documentación para lasfases centrales de Data Mining 4

Muy alto Se genera documentación para todos los modelos y además se crea documentación para cubrir todas las fases de Data Mining

5

Tabla 5.29: Factor DOCU

5.3.2.17. TOOL (disponibilidad de herramientas): El valor de este driver esta dado por la cantidad de herramientas de las que se disponen para el desarrollo de un proyecto de Data Mining. El valor de este driver se obtiene mediante la siquiente tabla:

Rango Descripción Valor Muy bajo Se utilizaran herramientas para el desarrollo de todos los modelos 1 Bajo Mas del 70% de los modelos se desarrollaran utilizando una

herramienta 2

Nominal Entre el 50% y el 70% de los modelos se desarrollaran utilizando una herramienta

3

Alto Hasta el 50% de los modelos se desarrollaran utilizando una herramienta

4

Muy alto No se utilizaran herramientas en el desarrollo de ninguno de los modelos

5

Tabla 5.30: Factor TOOL


5.3.2.18. COMP (compatibilidad): Este factor tiene en cuenta el grados 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. Para comenzar con el calculo de este driver hay que analizar la siguiente tabla y obtener el valor de compatibilidad para cada una de las herramientas:

Rango Descripción Valor Extra bajo Compatibilidad nula con el resto de las herramientas disponibles 0 Muy bajo Compatibilidad con editores de texto 1 Bajo Compatibilidad con editores de texto y hojas de calculo 2 Nominal Compatibilidad con editores de texto y hojas de calculo y SGBDs 3 Alto Compatibilidad con editores de texto y hojas de calculo y SGBDs

y herramientas de Data Mining 4

Muy alto Compatibilidad e integración total con el resto de las herramientas disponibles

5

Tabla 5.31: Comp: Factor COMP para cada herramienta

Luego sumamos todos los valores según lo indica la siguiente ecuación:

COMP=ROUND

Y comparamos este resultado con la siguiente tabla para obtener el valor final:

Rango Descripción Valor Extra bajo 0 0 Muy bajo 1 1 Bajo 2 2 Nominal 3 3 Alto 4 4 Muy alto 5 5

Tabla 5.32: Factor COMP

5.3.2.19. NFOR (nivel de formación de los usuarios que requieren las herramientas): El valor de este driver esta dado por el esfuerzo que implica que los usuarios tengan experiencia en el uso de las herramientas. El calculo del valor de este driver es similar al anterior.

Tabla 5.33: NFORp: Factor NFOR para cada herramienta

Rango Descripción Valor Muy bajo La herramienta utiliza asistentes inteligentes que guían al usuario a

través del proceso de Data Mining. El usuario necesita únicamente un leve conocimiento de las técnicas

1

Bajo Conocimiento de las técnicas de Data Mining. La herramienta funciona atravez de asistentes

2

Nominal Conocimiento ligero de las técnicas y de la herramienta 3 Alto Conocimiento de las técnicas y experto en la herramienta 4 Muy alto Experto tanto en técnicas como en la herramienta 5


NFOR=ROUND

Donde es el número de herramientas.


Tabla 5.34: Factor NFOR

5.3.2.20. NDEP (numero de departamentos involucrados en el proyecto): Este factor refleja el esfuerzo que implica la cantidad de departamentos que intervienen en el proyecto. El valor de este driver se obtiene analizando la siguiente tabla:

Rango Descripción valor Bajo Solo participa un departamento 2

Nominal Participan 2 departamentos 3 Alto Participan entre 3 y 5 departamentos 4 Muy alto Participan mas de 5 departamentos 5

Tabla 5.35: Factor NDEP

5.3.2.21. SCOM (distancia y forma de comunicación entre los orígenes de los datos: Ente driver toma en cuenta el esfuerzo que implica que los orígenes de los datos se encuentren o no en la misma localización. El valor de este driver de coste lo obtenemos utilizando la siguiente tabla:

Rango Descripción Valor Muy bajo Datos en la misma maquina donde se van a analizar 1

Bajo Datos en la misma base de datos 2 Nominal Todos los orígenes de datos en el mismo edificio, comunicados a

través de LAN 3

Alto Todos los orígenes de datos en un lugar diferente a donde se van a analizar pero existe comunicación entre ellos

4

Muy alto Todos los orígenes de datos en un lugar diferente a donde se van a analizar y no existe comunicación entre ellos

5

Tabla 5.36: Factor SCOM


5.3.2.22. NFUN (numero de fuentes): Este driver tiene en cuenta tanto el número de fuentes u orígenes de datos, como el tipo de fuente donde residen los datos. El valor de este driver se obtiene por tabla:

Rango Descripción Valor Muy bajo Una sola fuente de datos 1 Bajo Varias fuentes (2-3) homogeneas 2 Nominal 2-3 fuentes heterogeneas 3 Alto Mas de 3 fuentes heterogeneas sin ficheros en papel 4 Muy alto Mas de 3 fuentes heterogeneas con algún fichero en papel 5

Tabla 5.37: Factor NFUN

5.3.2.23. MTEC (disponibilidad de técnicas para el tipo de problema a tratar): Este driver tiene en cuenta la cantidad de técnicas que existe para generar los distintos tipos de modelos. Primero se obtiene el valor de MTECp de la siguiente tabla:

Modelos descriptivos Modelos predictivos Rango

Descripción Valor Descripción Valor Muy bajo Existen mas de 4

tecnicas para el modelo a generar

1 - -

Bajo Existen 3 tecnicas para el modelos a generar

2 Existen mas de 4 tecnicas para el modelo a generar

2

Nominal Esisten 2 tecnicas para el modelo a generar

3 Existen 4 tecnicas para el modelo a generar

3

Alto Existe 1 tecnica para el modelo a generar

4 Existen 3 tecnicas para el modelo a generar

4

Muy alto - - Existen 2 tecnicas para el modelo a generar

5

Extra alto - - Existe 1 técnica para el modelo a generar

6

Tabla 5.38: MTECp: Factor MTEC para cada modelo


Luego aplicamos la siguiente ecuación:

MTEC=ROUND

Y luego comparamos este valor con la tabla para obtener el valor final: Rango Descripción Valor Muy bajo 1 1 Bajo 2 2 Nominal 3 3 Alto 4 4 Muy alto 5 5 Extra alto 6 6

Tabla 5.39: Factor MTEC

5.3.3. Documentación del Usuario. Se encuentra detallado en el Anexo B: Manual de Usuario.

5.3.4. Plan de Integración. Se procederá a instalar el software en una computadora que conste con las necesidades anteriormente nombradas. Se ejecutara el programa y se introducirán valores a las distintas variables para realizar una prueba.

5.3.5. Sistema de Software Integrado. Pendientes hasta la integración completa del software.


6. Procesos de Post-Desarrollo.

Son los procesos que deben realizar para la instalar, operar, mantener y retirar un producto software. Se realizan después de la construcción del software. Se aplica a las últimas fases del ciclo de vida.

6.1. Proceso de Instalación.

Implica el transporte y la instalación de un sistema software desde el entorno de desarrollo al entorno de destino. Incluye la carga, si es necesario, de la base de datos, las modificaciones necesarias del software, las comprobaciones en el entorno de destino y la aceptación del cliente.

6.1.1. Plan de Instalación del Software. Se procede a descomprimir el paquete del software en la ubicación donde el servidor aloja las páginas Web, además se deben configurar la conexión a la base de datos, y si fuera necesario otros parámetros del servidor.

6.1.2. Informe de Instalación. Se implementa la correcta configuración del sistema alojado en un servidor Web, lo cual no se contempla la necesidad de la instalación local de la aplicación, ya que sólo bastará con ejecutarla desde cualquier navegador de Internet.

6.2. Proceso de Operación y Soporte.

Involucra la operación del sistema por parte del usuario y el soporte continuo al usuario que incluye asistencia técnica, consultas con el usuario y registro de las peticiones de soporte. Este proceso puede descansar la actividad del Proceso de Mantenimiento que provee información re-entrante al ciclo de vida del software.

6.2.1. Histórico de Peticiones de Soporte. Debido a que el principal objetivo de la construcción de este artefacto software es que como no existe ningún método de estimación que calcule la duración y el esfuerzo para este tipo de proyecto, creemos que exigirán un gran volumen de consultas hacia el funcionamiento, el uso y la exactitud de la estimación de los proyectos, sobre todo en el primer período de lanzamiento del artefacto software.

6.3. Proceso de Mantenimiento.

Se interesa por los errores, defectos, fallos, mejoras y cambios del software. Un requisito de mantenimiento del software inicia los cambios del ciclo de vida del software; este se reasigna y se ejecuta.


6.3.1. Orden de Mantenimiento. Debido al gran impacto que suponemos que alcanzará el artefacto software decidimos atender muy seriamente todo lo que apalee a todo el mantenimiento, comenzando por el mantenimiento correctivo, a través de cualquier defecto o error encontrado por el usuario final, también aplicar el mantenimiento adaptativo conforme a su entorno, para así acomodarlo a su cambios externos y contemplar muy seriamente el mantenimiento de mejora para completar el artefacto y mejorarlo conforme a funciones adicionales que podrían ser de interés su incorporación y así poder solucionar inconvenientes mejorar al máximo el rendimiento de la garantía de calidad del artefacto software.

6.3.2. Recomendaciones de Mantenimiento. En este último subproceso de mantenimiento aplicamos un mantenimiento preventivo, mediante el cual se intentará estudiar el volumen de acceso de los usuarios que visiten a lo largo del día, el artefacto software y también de la semana y se intenta deducir los errores del sistema para intentar evitar el degradamiento del funcionamiento o futuros colapsos o rupturas en el servicio por sobrecargas de usuarios al sistema.

6.4. Proceso de Retiro.

Es la jubilación del sistema existente de su soporte activo o de su uso mediante el cese de su operación o soporte, o mediante su reemplazamiento tanto por un nuevo sistema como por una versión actualizada del sistema existente. Si el sistema en uso, sea manual o automatizado, se reemplaza por un nuevo sistema se requiere un período de operación dual, denominado ensayo en paralelo. En este período se utiliza el sistema en retiro para los resultados oficiales, mientras se completa la preparación del nuevo sistema para la operación formal. Es un período de formación del usuario sobre el nuevo sistema y de validación del mismo.

6.4.1. Plan de Retiro. Como explicamos anteriormente el estándar IEEE prevee la inclusión de un plan de retiro el cual no será tomado en cuenta porque el artefacto software no compromete a un sistema existente, ni otro recurso importante para su retiro.


7. Procesos Integrales del Proyecto.

Son procesos simultáneos y complementarios a los procesos orientados al desarrollo. Incluyen actividades imprescindibles para que el sistema construido sea fiable (sección 7.1.1) y sea utilizado al máximo de sus capacidades (secciones 7.2. y 7.3.).

7.1. Proceso de Verificación y Validación.

Abarca la planificación y la realización de todas las tareas de verificación, incluyendo pruebas de verificación, revisiones y auditorias, y todas las tareas de validación, incluyendo pruebas de validación, que se ejecutan durante el ciclo de vida del software para asegurar que se satisfacen todos los requisitos del software.

7.1.1. Plan de Pruebas. En primera instancia haremos una prueba del software utilizando los datos usados en la documentación, de esta manera podremos verificar los resultados son iguales. También podremos verificar la correcta instalación del artefacto software en el ambiente de servicio.

7.1.1. Informe de las Pruebas. En el presente informe se realizaron una serie de pruebas orientadas a la validación de las funcionalidades de los componentes del sistema:

7.1.1. Prueba Validar Usuario: El sistema se cerciora que el usuario que intenta ingresar al sistema está entre los usuarios del sistema y ha ingresado la contraseña adecuada. Este módulo, se ha probado creando una cuenta, introduciendo un nombre, apellido, dirección de email, login, password y haciendo clic en Agregar Usuario, y el sistema valida al usuario correctamente, en el caso particular de la falta de algún elemento o error al introducir los datos, el sistema se encarga de avisar e informar de que hay datos faltantes o erróneos, correctamente como se pensó con anterioridad.

7.1.2. Prueba Registrar Nuevo Usuario: Se añade un nuevo usuario al sistema. Al probar el alta de usuarios partir de que hicimos el clic en Agregar Ususario el sistema lo valida perfectamente al usuario, comprueba algún error en el sistema y lo agrega a la base de datos creando una cuenta, un nombre y apellido, una dirección de email, un login y password, de acuerdo a los datos del usuario a registrar.

7.1.3. Prueba Ingresar Variables de Costo: Permite completar los valores de las variables de costes del modelo DMCoMo de un proyecto a estimar. Empezamos probando las variables del sistema para la estimación de un proyecto “X”, dejando el proyecto por la mitad para su posterior continuación, verificando si el


sistema guarda adecuadamente las variables ya elegidas para la estimación, verificamos la utilización de varios modelos conjuntamente y su eliminación, viendo en que manera influye a la total estimación del proyecto.

7.1.4. Prueba Mostrar Estimación: Visualiza el resultado de aplicar el modelo DMCoMo sobre las variables de costo ingresadas. Una vez terminado la estimación hicimos clic sobre el botón aceptar para que el sistema muestre la estimación total, intercambiamos los distintos valores de las variables para buscar un defecto importante en la estimación, pero no se han encontrado algún tipo de error en él, el sistema no muestra el coste final al apretar “aceptar” hace falta dirigirse hacia “Mis Proyectos” para ver el resultado de la estimación total del proyecto.

7.2. Proceso de Gestión de la Configuración.

Este proceso involucra un conjunto de actividades desarrolladas para gestionar los cambios durante todo el ciclo de vida del software. Identifica la estructura de un sistema en un momento dado a lo que se denomina configuración del sistema. Su objetivo es el control de los cambios en el sistema, mantener su coherencia y su “rastreabilidad” y “trazabilidad”, y poder realizar auditorias de control sobre la evolución de las configuraciones.

7.2.1. Plan de Gestión de Configuración del Software. El artefacto software no incumbe un proceso de configuración local, ya que como se explico anteriormente, el procesamiento esta montado a servidor Web por lo cual cualquier configuración requerida será perteneciente al mismo servidor. A la hora de la puesta en funcionamiento será el administrador del sistema el que tendrá el poder de crear o generar nuevos usuarios para el Usuario Final del proyecto a estimar, quienes se encargarán de la carga de todos los datos y a quienes corresponderán la mayor parte del flujo de información para la completa estimación del proyecto.

7.3. Proceso de Desarrollo de la Documentación.

Este proceso de actividades para el desarrollo y el uso del software es un conjunto de actividades que planifican, diseñan, implementan, editan, producen, distribuyen y mantienen los documentos necesarios para los desarrolladores y los usuarios.

7.3.1. Plan de Documentación. La documentación del presente artefacto software se desarrollo íntegramente bajo las normas del estándar IEEE 1074 - 1989. Estas normas están previstas para el control y el aseguramiento de la calidad del software, conformando los procesos base de la construcción de artefacto software.


7.4. Proceso de Formación.

Dentro de este proceso podemos encontrar la planificación, desarrollo e implementación de los programas de formación de desarrolladores, personal de soporte técnico y clientes y la elaboración de los materiales de formación adecuados.

7.4.1. Plan de Formación. El estándar IEEE prevee la inclusión de un plan de formación el cual no se aplica en este proyecto en particular.

Anexo A 59

Anexo A

1. Datos de Prueba

Los datos que se han utilizado (Figura 1: Datos de Prueba) provienen de proyectos

de extracción de datos realizados por el grupo de Bases de Datos de la Facultad de Informática de la Universidad Politécnica (Madrid, España), por la Universidad del Valle (Cali, Colombia), por la Universidad de Stony Brook (Nueva York, U.S.A.) y por el Naval Research Laboratory (Monterrey, U.S.A.).

Este anexo muestra un resumen de los datos utilizados para la creación de la ecuación de DMCOMO. Se muestran los datos recogidos (Figura 1: Datos de Prueba) que se han utilizado para la creación de la ecuación de estimación del esfuerzo así como las distribuciones, en forma de histogramas, de los 23 drivers de coste de los proyectos utilizados para crear el modelo.


Aquí mostraremos los datos de pruebas:

Figura 1: Datos de Prueba.

Anexo B 61

Anexo B

1. Manual de Usuario

Este manual le permitirá aprender a utilizar todas las funcionalidades básicas para el uso del artefacto software DMCoMosoft.

1.1. Acceso a la Página Web

Para acceder a la aplicación usted deberá abrir con su navegador web el sitio www.dmcomo.com.ar

1.2. Iniciar sesión

Para comenzar a trabajar necesitará primero iniciar sesión. Ingresar su nombre de usuario y contraseña en los campos correspondientes que se encuentran en la esquina superior derecha, como se muestra en la siguiente imagen de la Figura 1.1.

Figura 1: Iniciar Sesión

1.3. Crear un nuevo proyecto

• Iniciar sesión tal como se explicó anteriormente. • A continuación deberá ingresar el nombre que identifique a su nuevo proyecto. • Pulse sobre el botón “Nuevo Proyecto” para confirmar la acción. • Podrá ver como aparece su nuevo proyecto agregado a la lista de proyectos, justo

debajo de donde usted ingresó el nombre del proyecto.


La Figura 3, a continuación muestra como crear un nuevo proyecto.:

Figura 3: Nuevo Proyecto

1.4. Completar los datos de un proyecto.

• Habiendo iniciado sesión en el sistema, diríjase a la sección “Mis Proyectos” presionando sobre el botón correspondiente.

• Bajo el título de proyectos aparecerá la lista de sus proyectos (ver Figura 4) y el estado de su estimación.

Figura 4: Mis Proyectos

• Presione sobre el nombre del proyecto del cual desea ingresar datos. • A continuación, usted deberá seleccionar los valores que mas concuerden con su

proyecto, el sistema le dará una descripción de cada instancia que deba ingresar. Si lo desea puede completar parcialmente los valores para continuar en otro momento.

Anexo B 63

La figura 5 muestra un ejemplo de la primera pantalla.

Figura 5: Variables a Completar

• A medida que usted va avanzando en el proceso de completar todas las variables,

estas (las completas) se irán transformando de otro color más claro para que usted sepa, si es que tiene la necesidad de cerrar el proyecto actual antes de concluirlo, exactamente en donde dejo el trabajo para continuarlo posteriormente.

• Luego de haber completado todos los datos requeridos debe dirigirse de nuevo a “Mis Proyectos” para visualizar el resultado de la estimación.

Figura 6: Estimar Proyecto

1.6. Cerrar Sesión

• Para cerrar sesión solamente usted se debe dirigirse con el curso hacia la esquina superior derecha de la pantalla donde se encuentra el botón de “Cerrar sesión”,


mostrado a continuación en la Figura 8. Y sólo deberá apretar el botón verde de “Cerrar Sesión” para concluir con la visita al sistema.

Figura 8: Cerrar Sesión

Anexo c 65

Anexo c

1. Manual de Instalación

Este manual le permitirá poder conocer los componenetes necesarios para la segura y completa instalación del artefácto software DMCoMoSofT.

1.1. Requisitos de la instalación.

Para utilizar DMCoMoSoft usted debe contar con un servidor Apache 2+ con el módulo para PHP 5+. El módulo de PHP debe tener soporte para la conexión con MySQL 5+, y por lo tanto también necesitará un servidor MySQL 5+. Si va a instalarlo sobre un servidor propio recomendamos la utilización de XAMPP que trae todo el software mencionado anteriormente perfectamente integrado y soporta varios sistemas operativos. (http://www.apachefriends.org/es/xampp.html)

1.2. Instalación del Sistema

1. Descomprima el archivo dmcomosoft.zip en una carpeta temporal de su preferencia. Deberá realizar unos cambios de acuerdo a la configuración de su servidor.

2. Abra el archivo config/config.php con un editor de texto y establezca el URL con el que los usuarios accederán al sistema. Puede ver un ejemplo en la Figura 1. Usted debe cambiar “http://localhost/dmcomo/” por el URL de su servidor.


Figura 1: Archivo config/config.php

3. Abra el archivo config/database.php con un editor de texto. En la Figura 2 se

muestra el archivo /config/database.php que usted deberá modificar para la instalación y sólo se debe ser modificada la porción de la sentencia que se encuentra entre " ", estas sentencias son las que normalmente deberían ser cambiadas en el archivo, para lograr su correcto funcionamiento:

$db['default']['hostname'] = "localhost"; $db['default']['username'] = "root"; $db['default']['password'] = ""; $db['default']['database'] = "dmcomo"; $db['default']['dbdriver'] = "mysql";

Seguidamente explicaremos simplemente a que se debe cada sentencia: ['Hostname'] El URL de su servidor de base de datos. ['Username'] El nombre de usuario utilizado para conectarse a la base de datos. ['Password'] La contraseña utilizada del usuario. ['Database'] El nombre de la base de datos que desea conectarse. ['Dbdriver'] El motod de base de datos, en este caso: mysql.

Anexo c 67

La Figura 2, a continuación muestra el archivo config/database.php:

Figura 2: Archivo config/database.php

Herramienta de Estimación del Esfuerzo en Proyectos...

Documents

Transcript of Herramienta de Estimación del Esfuerzo en Proyectos...