Etesoo - estimador de tiempo y esfuerzo en desarrollo de software orientado a objetos

Texto completo

(1)ETESOO: Estimador de Tiempo y Esfuerzo en desarrollo de Software Orientado a Objetos. EDWIN GRANADOS ANDRADE. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, D.C. 2003.

(2) ETESOO: Estimador de Tiempo y Esfuerzo en desarrollo de Software Orientado a Objetos. EDWIN GRANADOS ANDRADE. Documento de proyecto de grado para optar por el título de INGENIERO DE SISTEMAS Y COMPUTACIÓN. Directora ANGELA CARRILLO. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, D.C. 2003.

(3) Bogotá, Julio de 2003. Ingeniera: Ángela Cristina Carrillo Ramos Departamento de Sistemas y Computación Universidad de los Andes Ciudad. Cordial Saludo:. Por medio de la presente, me permito presentar mi documento de proyecto dirigido para optar al título de Ingeniero de Sistemas y Computación de la Universidad de los Andes. El nombre del proyecto es: ETESOO, Estimador de Tiempo y esfuerzo en desarrollo de Software Orientado a Objetos.. Agradezco su amable colaboración. Atentamente,. EDWIN FERNANDO GRANADOS ANDRADE C.C. 88’192.820 de Villa del Rosario, N.S..

(4) A mi familia y amigos….

(5) AGRADECIMIENTOS. El autor expresa sus agradecimientos:. A Dora, por habernos sacado, a mis hermanos y a mí, adelante a pesar de todas las dificultades que hemos tenido.. A Andrés, Sandy y Rodolfo, por el apoyo y los ánimos que me dieron en todo momento.. A Ángela Carrillo, Asesora de mi proyecto de grado, por su orientación y consejos que no se limitaron a este trabajo.. A Grecia López, por ser mi amiga incondicional durante tanto tiempo.. A todos mis compañeros de trabajo fuera de la Universidad, por ayudarme a crecer profesionalmente todos los días.. A todas las demás personas que de una u otra forma me apoyaron durante toda mi carrera..

(6) PRESENTACIÓN. Este documento representa el trabajo de investigación realizado a lo largo de un semestre para identificar los principales problemas que se tienen a la hora de estimar el tamaño y el esfuerzo requerido para desarrollar un proyecto de software orientado a objetos; estudiar las metodologías de estimación que comúnmente se usan; y diseñar una aplicación que implementa una metodología que propone una aproximación diferente a las estudiadas. El documento entonces está dividido en tres secciones principales: •. Presentación del problema a tratar y de las metodologías existentes con sus ventajas y desventajas.. •. Presentación de la metodología propuesta, wNumbers. •. Análisis y diseño de la aplicación que implementa ésta metodología. Finalmente se presentan las conclusiones obtenidas a partir de este estudio.

(7) ISC-2003-1-17. TABLA DE CONTENIDO 0. Introducción ......................................................................................................1. 1. Metodologías de estimación existentes............................................................2. 2. 1.1. COCOMO'81 (Constructive Cost Model)...................................................2. 1.2. SLIM (Software Life Cycle Management)..................................................3. 1.3. Puntos Funcionales...................................................................................4. 1.4. Conjunto de métricas de Chidamber y Kemerer .......................................6. Metodología propuesta.....................................................................................8 2.1. 3. 4. wNumbers .................................................................................................8. 2.1.1. Evaluación Inicial del Esfuerzo ..........................................................9. 2.1.2. Ajuste de Esfuerzos .........................................................................10. 2.1.3. Cálculo del Esfuerzo ........................................................................13. 2.1.4. Modificación del Esfuerzo ................................................................14. 2.1.5. Conclusión .......................................................................................15. Especificación.................................................................................................16 3.1. Descripción general de la aplicación.......................................................16. 3.2. Requerimientos funcionales ....................................................................16. 3.3. Usuarios del sistema ...............................................................................17. 3.4. Casos de uso ..........................................................................................18. 3.5. Entidades ................................................................................................20. 3.6. Definición de la Arquitectura ...................................................................24. 3.6.1. Evaluación de la Base de Datos ......................................................24. 3.6.2. Evaluación del Servidor de Aplicaciones .........................................26. Conclusiones ..................................................................................................28. i.

(8) ISC-2003-1-17. 5. Referencias ....................................................................................................29. Anexo 1. Diagrama de Casos de Uso ...................................................................30 Anexo 2. Casos de Uso Detallados .......................................................................37 Anexo 3. Modelo Entidad Relación........................................................................59. ii.

(9) ISC-2003-1-17. INDICE DE TABLAS Tabla 1. Etapas del Desarrollo de Software ............................................................8 Tabla 2. Métricas de tamaño iniciales ...................................................................10 Tabla 3. Categorización de las clases ...................................................................10 Tabla 4. Categorización de funciones ...................................................................12 Tabla 5. Categorías de datos ................................................................................13 Tabla 6. Prefijos usados en la metodología...........................................................14 Tabla 7. Requerimientos Funcionales del sistema ................................................17 Tabla 8. Casos de Uso ..........................................................................................19 Tabla 9. Características deseadas en el motor de Base de Datos........................25. iii.

(10) ISC-2003-1-17. 0 Introducción A partir de la experiencia he encontrado que la mayoría de los proyectos de software presentan un gran sobrecosto en su desarrollo. Algunas de las causas son la falta de buenas técnicas de diseño y, en la mayoría de los casos, la falta de una metodología de estimación del tamaño del proyecto y del esfuerzo requerido para desarrollarlo. Esto es especialmente cierto en ambientes de desarrollo Orientado a Objetos, pues las metodologías de estimación existentes fueron desarrolladas hace más de veinte años y pensando en software programado de manera procedimental y al aplicarlas a proyectos OO, los resultados no son tan precisos como se desearía. En los últimos años, debida a la gran fuerza que ha tomado la programación OO, gracias a JAVA principalmente, han surgido algunas metodologías de estimación para este tipo de proyectos. A continuación presentaré brevemente las más importantes metodologías convencionales con sus ventajas y desventajas desde el punto de vista OO y luego, los aspectos más relevantes de las nuevas aproximaciones para la estimación de tamaños y esfuerzos en proyectos.. 1.

(11) ISC-2003-1-17. 1 Metodologías de estimación existentes A continuación se presentan las metodologías más usadas para estimar tamaños y esfuerzos de desarrollo de aplicaciones convencionales.. 1.1 COCOMO'81 (Constructive Cost Model) Desarrollado por Boehm [Boehm], es uno de los modelos más usados comercialmente y consta de tres niveles: 1. El nivel básico calcula el esfuerzo y costo de desarrollo como función del tamaño de la aplicación expresado en líneas de código estimadas (LOC). 2. El nivel intermedio calcula el esfuerzo como función del tamaño del programa y un conjunto de indicadores de costos que incluyen medidas subjetivas del producto, personal, herramientas y atributos de proyecto. 3. El modelo detallado incorpora todas las características del nivel intermedio agregando mediciones del impacto de los costos en cada etapa del proceso de software (análisis, diseño, etc.). Estos modelos dependen de dos ecuaciones: •. Esfuerzo de desarrollo, basado en meses-hombre. Para el nivel básico, tiene esta forma: MM=aKDSIb. •. Tiempo y esfuerzo de desarrollo (TDEV) TDEV=cMMd. KDSI son los miles de líneas de código y es una medida de tamaño. Y los coeficientes a, b y c dependen del modo de desarrollo: Orgánico, Semi-acoplado e incrustado. Ventajas •. Transparente.. •. Los indicadores son de particular ayuda para entender el impacto de los factores que afectan los costos del proyecto.. Desventajas. 2.

(12) ISC-2003-1-17. •. Es difícil calcular con precisión la cantidad de líneas de código en las primeras etapas del proyecto donde la mayoría de estimaciones son requeridas.. •. KDSI no es una medida de tamaño sino de longitud. •. El éxito de este modelo depende de su ajuste a las necesidades de la organización, usando datos históricos que no siempre están disponibles.. 1.2 SLIM (Software Life Cycle Management) Este es uno de los primeros modelos algorítmicos. Está basado en las funciones de Norden / Rayleigh y conocido como un modelo de macro-estimación. SLIM usa una versión automatizada de conteo de líneas de código. La ecuación usada tiene la siguiente forma: Tamaño = P * (Esfuerzo/B) * Tiempo Donde el tamaño hace referencia a la cantidad de unidades creadas (líneas de código, puntos funcionales, objetos, etc.); P es el parámetro de productividad del grupo encargado del desarrollo. Este factor se determina a partir de datos históricos de otros proyectos desarrollados por el mismo grupo. B es un factor de ajuste de la complejidad que varía a medida que el tamaño del proyecto aumenta. Está relacionado con las etapas de documentación, pruebas y administración del proyecto. El tiempo a tener en cuenta para este cálculo es el transcurrido desde que se inicia la etapa de diseño detallado hasta el momento en que el producto está listo para entrar en funcionamiento. Ventajas •. Usa programación lineal para considerar restricciones de tiempo y esfuerzo.. •. Necesita menos parámetros que COCOMO para las estimaciones. Desventajas •. Las estimaciones son muy sensibles al factor tecnológico.. •. No apto para proyectos pequeños.. 3.

(13) ISC-2003-1-17. 1.3 Puntos Funcionales Los puntos funcionales proveen información básica para calcular métricas de productividad. Son usados de dos maneras: •. Como variables de estimación usada para predecir el tamaño de cada elemento de software,. •. Como un conjunto de medidas recolectadas de proyectos pasados y usadas con variables de estimación para desarrollar proyecciones de costo y esfuerzo.. La idea general de esta metodología es identificar y contar el número de funciones de tipos específicos. A cada tipo se le da un peso de acuerdo a la complejidad. Este peso puede variar entre 3(menos complejo) y 15(más complejo). Los puntos funcionales no ajustados se calculan multiplicando los totales por tipo de función por su peso asociado y luego sumando todos los resultados. Para hallar el total de puntos funcionales ajustados, se multiplica el total de puntos funcionales no ajustados por un factor de complejidad técnico que es calculado por medio de la siguiente fórmula: TCF = 0.65 + (suma de factores) / 100 Hay 14 factores de complejidad técnica. Cada factor tiene un valor asociado de acuerdo a su nivel de influencia. Estos son: •. Comunicación de datos. Envío de los datos e información de control usada en la aplicación.. •. Procesamiento distribuido de datos.. •. Desempeño. Objetivos de desempeño planteados y aprobados por el usuario, ya sea en tiempo de respuesta o comportamiento general, influyen en el diseño, desarrollo, instalación y soporte de la aplicación.. •. Uso muy frecuente de una configuración. Este tipo de configuración requiere consideraciones especiales de diseño.. •. Cantidad de transacciones. Este aspecto tiene mucha influencia en el diseño, desarrollo, instalación y soporte de la aplicación.. 4.

(14) ISC-2003-1-17. •. Ingreso de datos en línea. Funciones de ingreso y control de datos que provee la aplicación.. •. Eficiencia para usuario final.. •. Actualización en línea. La aplicación provee actualización en línea de sus archivos de sistema.. •. Procesamiento complejo.. •. Reusabilidad. El código de la aplicación se diseñó y desarrolló para ser usado en otras aplicaciones.. •. Facilidad de instalación.. •. Facilidad de operación. •. Múltiples sitios. La aplicación se desarrolló para ser utilizada en diferentes organizaciones.. •. Facilidad de cambio. La aplicación fe creada para facilitar una eventual transición entre plataformas.. Finalmente, los puntos funcionales ajustados se calculan usando a siguiente ecuación: FP = UFP x TCF Donde UFP es la cantidad de puntos funcionales no ajustados y TCF es el factor de complejidad técnica asociado. Ventajas •. No está restringido a código. •. Independiente del lenguaje. •. La información necesaria está disponible desde las etapas iniciales del proyecto. Sólo se necesita una especificación detallada.. •. Más preciso que la estimación de LOC.. Desventajas •. Conteo subjetivo. 5.

(15) ISC-2003-1-17. •. Difícil de automatizar y de computar. •. Ignora la calidad de las salidas. •. Orientado a aplicaciones tradicionales de proceso de datos. 1.4 Conjunto de métricas de Chidamber y Kemerer Este conjunto constituye la investigación más profunda en el tema de métricas OO. En él se definen 6 medidas para el diseño OO: •. Weighted Methods per Class (WMC). Métodos ponderados por clase. Es la suma de las complejidades de todos los métodos de una clase.. •. Depth of Inheritance Tree (DIT). Profundidad del árbol de herencia. Está definido como la máxima longitud desde un nodo hasta la raíz del árbol de herencia.. •. Number of Children (NOC). Número de hijos. Es el número de subclases inmediatas de un objeto.. •. Coupling Between Objects (CBO). Acoplamiento entre objetos. Es la cantidad de llamados desde un objeto de una clase a métodos e instancias de otra clase.. •. Response for a Class (RFC). Respuestas por clase. Proporción de métodos que pueden ser invocados en respuesta a un mensaje enviado por un objeto.. •. Lack of Cohesion in Methods (LCOM). Falta de cohesión entre métodos. Número de métodos diferentes de una clase que hacen referencia a una variable de instancia dada.. Ventajas •. Surgen naturalmente de la aproximación OO.. •. NOC y RFC dan alguna medida para calcular presupuestos y pruebas de la clase en cuestión.. Desventajas •. La medición de la complejidad de las clases se presta para confusión. •. No pueden dar una buena estimación de tamaños y esfuerzos. 6.

(16) ISC-2003-1-17. •. Sirven en la etapa de diseño solamente, pero no dan apoyo en términos de planeación. 7.

(17) ISC-2003-1-17. 2 Metodología propuesta Esta sección del documento está dedicada a presentar la metodología de números ponderados, wNumbers, desarrollada por Stuart Woodward [Woodward].. 2.1 wNumbers Para propósitos de cualificar las métricas especificadas en esta metodología, se han adoptado las siguientes etapas del desarrollo de software.. Código. Descripción. BDD. Estudio de factibilidad.. ANL. Análisis. Producción de una especificación de requerimientos o especificación funcional.. DES. Diseño. Especificación Técnica.. IMP. Implementación, Construcción de la aplicación, incluyendo pruebas unitarias y de integración.. TST. Pruebas del sistema, anteriores a la primera versión liberada.. INS. Instalación en ambiente de producción, incluyendo pruebas ‘beta’.. PRD. Ejecución en ambiente de producción.. Tabla 1. Etapas del Desarrollo de Software. Debido a que se pueden identificar los principales objetos del negocio de un sistema desde etapas tempranas, esta metodología se puede usar desde la etapa de estudio de factibilidad (BDD). De esta forma, mediciones más objetivas de los costos pueden alimentar el análisis de costo / beneficio del proyecto, proveyendo información más precisa sobre la cuál basar las decisiones. Después de esto, se usan resultados de desarrollo refinados, para cada etapa exitosa. Por ejemplo, durante la etapa de desarrollo, se agrega mayor detalle para producir la especificación técnica. Así, el método propuesto puede ser usado consistentemente a lo largo de las etapas de desarrollo y es refinado al final de cada una de estas.. 8.

(18) ISC-2003-1-17. Toda la información sobre las estimaciones debe ser guardada para que pueda ser usada como referencia en proyectos futuros. A continuación se presentan las etapas del cálculo del esfuerzo requerido para desarrollar un proyecto OO:. 2.1.1 Evaluación Inicial del Esfuerzo Un sistema OO consiste de una colección de clases, unidas por relaciones de herencia. Cada clase contiene funciones y datos. Los métodos para evaluar esfuerzos en la construcción de estas dos características pueden diferir. Esto es porque cada clase puede tener un amplio rango de funciones que pueden ser evaluadas individualmente, mientras que los datos prácticamente pueden ser evaluados sólo como un todo, dentro de cada clase. Por esta razón, probablemente existirán muchos tipos o categorías de funciones, pero pocos tipos de datos. Esta metodología propone la definición de las siguientes reglas para diferenciar el esfuerzo requerido en el desarrollo de funciones y datos contra el requerido por las clases como un todo: Funciones Sólo se medirá el esfuerzo requerido en la implementación de la función. No en su declaración en definiciones de clases. Datos El cálculo del esfuerzo será basado sólo en el desarrollo de persistencia de datos en las clases. Esto es, datos que existen después de que los objetos de la clase son destruidos en la ejecución del programa. Esto, normalmente implica desarrollo de bases de datos, desarrollo de cuadros de diálogo, definición de intercambio de datos entre aplicaciones y otros datos que pueden existir fuera del código del programa. Para propósitos de conteo, cada clase tendrá sólo un ‘bloque’ de datos persistentes. Una evaluación aproximada del esfuerzo de desarrollo de un sistema es establecido al reunir métricas de los entregables de una etapa de desarrollo. Las métricas iniciales son presentadas a continuación:. 9.

(19) ISC-2003-1-17. Código. Descripción. nCL. Número de clases objeto identificables. nFN. Número de clases función identificables. nDA. Número de categorías de datos identificadas. Tabla 2. Métricas de tamaño iniciales. 2.1.2 Ajuste de Esfuerzos Algunas clases serán inevitablemente más difíciles de especificar e implementar que otras. Por esto, las clases son categorizadas y se les asigna un peso acordemente. La siguiente tabla sugiere un conjunto inicial de categorías:. Código de Categoría. Código de Peso. Descripción. ccBCL. xwcBCL1. Clase básica. De donde las demás clases se derivan.. ccDLG. xwcDLG. Diálogos o clases de interfaz con usuario que contengan otros recursos como botones o listas.. ccRES. xwcRES. Recursos individuales.. ccSCT. xwcSCT. Contenedores estándar derivados de contenedores base de terceros, como listas, arreglos, colas.. ccOCT. xwcOCT. Otros contenedores de terceros que requieran procesamiento especial.. ccUTL. xwcUTL. Clases utilitarias con funcionalidad específica como procesamiento de datos.. ccSOB. xwcSOB. Objetos pequeños creados y destruidos durante la ejecución del programa.. ccITF. xwcITF. Interfaces para comunicación con otras aplicaciones.. ccBUS. xwcBUS. Objetos de negocio no abstractos identificables en el dominio del sistema.. Tabla 3. Categorización de las clases 1donde. 'x' debe ser remplazada por b, a, o d para las etapas BDD, ANL, DES respectivamente. Un resumen de todos los prefijos usados se presentará mas adelante.. 10.

(20) ISC-2003-1-17. Cada clase identificada es ubicada en una categoría existente y medida. Esto se hace ya que es mucho más fácil juzgar componentes pequeños por analogía con otros que a todo el sistema. De manera alternativa, y dependiendo de la cantidad de detalle disponible, se pueden utilizar métricas existentes para ayudar en la categorización. Si existe una correlación entre las categorías y métricas específicas, entonces esto es mejor que la simple analogía. Las categorizaciones son en esencia la aplicación de un factor de composición a cada clase. Este factor, expresado como “el esfuerzo requerido para construir un elemento de esta categoría” y cuantificado por los pesos, encierra otros factores como: •. Habilidades en Ingeniería. •. Tamaño. •. Complejidad. •. Uso de herramientas de desarrollo como CASE o generadores de código.. Para hallar el esfuerzo ajustado del desarrollo del sistema, el número de clases de cada categoría se multiplica por su peso asociado, o wNumber. Debida a que los pesos pueden variar dependiendo de la etapa, los valores de estos pesos no son presentados. Las categorías mencionadas son presentadas como ejemplo punto de partida, pero pueden ser eliminadas y remplazadas por otras que se ajusten mas a las necesidades particulares de cada grupo de desarrollo. El mismo método es utilizado para categorizar y dar peso a las funciones y datos:. 11.

(21) ISC-2003-1-17. Código de Categoría. Código de Peso. Descripción. fcADD. xwfADD. Inserción de objetos.. fcAPL. xwfAPL. Inicialización de aplicación.. fcBLN. xwfBLN. Comparación simple(BOOL).. fcCMN. xwfCMN. Comunicaciones.. fcCOM. xwfCOM. Controlador de diálogos.. fcCON. xwfCON. Constructor.. fcCTR. xwfCTR. Proceso contenedor.. fcDBA. xwfDBA. Procesamiento de base de datos.. fcDBI. xwfDBI. Inicialización de base de datos.. fcDBG. xwfDBG. Procesamiento de múltiples objetos en base de datos.. fcDES. xwfDES. Destructor... fcDLG. xwfDLG. Campos de consulta y modificación en diálogos.. fcERR. xwfERR. Construcción y presentación de errores.. fcFIL. xwfFIL. fcGSF. xwfGSF. Consultas y modificaciones. fcINT. xwfINT. Inicializaciones. fcMAT. xwfMAT. Procesos aritméticos y matemáticos. fcMNT. xwfMNT. Mantenimiento.. fcMOD. xwfMOD. Control de modificaciones.. fcRES. xwfRES. Proceso sencillo de recursos.. fcSTR. xwfSTR. Procesamiento de cadenas.. fcTRN. xwfTRN. Transacciones.. Acceso a archivos.. Tabla 4. Categorización de funciones. 12.

(22) ISC-2003-1-17. Código. Peso. Descripción. dcBUS. xwdBUS. Datos del Negocio.. dcDLG. xwdDLG. diálogos. dcGLB. xwdGLB. Datos globales. dcITF. xwdITF. Datos de interfaz de aplicaciones. Tabla 5. Categorías de datos. A medida que esta metodología es usada, las categorías de datos pueden ser desglosadas según sea necesario.. 2.1.3 Cálculo del Esfuerzo El cálculo del esfuerzo total requerido para construir el sistema propuesto es la suma de las mediciones ajustadas mencionadas anteriormente. La fórmula es:. ∑ (( cC × xwcC ) +( fF × xwfF ) + ( dD × xwdD )) Donde C representa las categorías de clases, F las categorías de funciones y D las categorías de datos; y c, f y d, representan los conteos respectivos.. Prefijo. Descripción Clasificación. n. Número de elementos. c. Número de clases. f. Número de funciones. d. Número de elementos de datos. cc. Categoría de clase. Ver Tabla 3. Categorización de las clases. fc. Categoría de funciones. Ver Tabla 4. Categorización de funciones. dc. Categoría de datos. Ver Tabla 5. Categorías de datos. 13.

(23) ISC-2003-1-17. Pesos. La etapa x está definida en la Tabla 1. Etapas del Desarrollo de Software xwc. Peso de la categoría de clases c en la etapa x. xwf. Peso de la categoría de funciones f en la etapa x. xwd. Peso de la categoría de datos d en la etapa x Resultados. xtc. Tiempo actual registrado para la categoría de clases c en la etapa x. xtf. Tiempo actual registrado para la categoría de funciones f en la etapa x. xtd. Tiempo actual registrado para la categoría de datos d en la etapa x. xto. Tiempo actual registrado para otras actividades del proyecto en la etapa x. Tabla 6. Prefijos usados en la metodología. En otras palabras, esta ecuación es la suma ponderada, según su complejidad, de los tamaños de todos los componentes identificados en la etapa actual del proceso. Entonces, En cada etapa del proceso se van a lograr estimaciones mas precisas y cercanas al tiempo real que requerido por las aplicación ya que se van a identificar mas detalladamente sus componentes. Debido a que los wNumbers representan estimados actuales de tiempo para desarrollar los componentes del sistema, esta suma representa un estimado del tiempo total requerido para construir todo el sistema. Por esta razón, no se intenta calibrar los pesos relativos entre estos tres grupos. La calibración se logra al obtener estos valores de datos históricos y empíricos para cada grupo. La precisión del resultado dependerá únicamente de la precisión de los pesos asignados a cada categoría. Por esto, es necesario ajustar regularmente los pesos de las categorías basados en los datos de tiempos ejecutados por categoría.. 2.1.4 Modificación del Esfuerzo Para llegar al costo total de desarrollo, se debe establecer una correlación entre el costo del desarrollo actual y el esfuerzo total del personal en el periodo de tiempo que requirió el proyecto.. 14.

(24) ISC-2003-1-17. La medición de los resultados recolectados permite crear un perfil de cómo se esta alcanzando el tiempo actual de desarrollo. Se debe asumir que el mismo patrón de trabajo se repetirá en el futuro en proyectos con características similares. Pero esto depende de muchos factores, además de la cantidad de personal trabajando en el proyecto. Cuando el esfuerzo de desarrollo es calculado desde una etapa anterior, éste puede ser multiplicado por un factor de modificación surgido de este análisis. Por ejemplo, si los resultados muestran que el tiempo de desarrollo fue sólo el 80% del total transcurrido, entonces el factor de modificación para calcular el esfuerzo total será de 1.25.. 2.1.5 Conclusión Como se ve, esta metodología contiene elementos usados por otros métodos de estimación: analogía, usada para categorizar nuevos componentes; mediciones; análisis estadístico, para calcular las estimaciones con un intervalo de confianza; formulas, para calcular el esfuerzo total; factores externos, etc. wNumbers es un sistema totalmente abierto, en el que ningún parámetro ni métrica está ‘cableado’. Cada organización puede, entonces, establecer sus propios códigos y etapas de desarrollo y la naturaleza de los productos que desarrolla sentará las bases para unas categorías estrechamente ligadas a los productos y por ende los costos asociados serán mas precisos. Precisamente estas características son la razón para proponer una aplicación que implemente esta metodología.. 15.

(25) ISC-2003-1-17. 3 Especificación A continuación se establecen las especificaciones básicas para desarrollar una aplicación que implemente la metodología de wNumbers presentada en la sección anterior de este documento.. 3.1 Descripción general de la aplicación Los objetivos básicos de esta aplicación son la captura de los conteos de objetos por categoría durante cada etapa del proyecto para calcular el tiempo estimado de desarrollo total en esa etapa particular; hacer el cierre de una etapa de un proyecto y calcular el tiempo estimado de desarrollo; capturar los tiempos reales de desarrollo y, finalmente, ajustar los pesos asociados a las categorías de acuerdo a los datos históricos y actuales. Para poder cumplir con estos objetivos, es necesario contar con un módulo de administración para realizar la configuración del sistema. Se deben poder crear modificar o eliminar categorías de objetos a tener en cuenta en los proyectos; se necesita hacer una administración de proyectos y usuarios asociados a estos, encargados de realizar la captura tanto de conteos como de tiempos y de generar las estimaciones correspondientes. Debido a que esta aplicación va a ser usada por muchas personas al mismo tiempo, se plantea que la solución se haga mediante un esquema Web con un servidor central en el que resida la aplicación y su base de datos y se tenga acceso a ella mediante un navegado Web.. 3.2 Requerimientos funcionales A continuación se presentan los requerimientos funcionales generales detectados en el diseño de la aplicación.. ID. NOMBRE. REQ-ADM-1. Administrar Categorías. REQ-ADM-2. Administrar Clientes. REQ -ADM-3. Administrar Proyectos. REQ -ADM-4. Administrar Usuarios. 16.

(26) ISC-2003-1-17. REQ -OPR-1. Ajustar Pesos. REQ -OPR-2. Generar Estimado Etapa. REQ -OPR-3. Registrar Conteo. REQ -OPR-4. Registrar Tiempo Ejecutado. REQ -OPR-5. Reporte Proyecto. Tabla 7. Requerimientos Funcionales del sistema. 3.3 Usuarios del sistema El sistema contará con dos perfiles de usuarios, a saber: •. Administrador. Encargado de crear, editar y borrar otros usuarios, proyectos, clientes y categorías del sistema, además de ajustar los pesos de cada categoría al finalizar un proyecto.. •. Operativo. Es el encargado de ingresar los conteos de objetos por categoría para un proyecto y de registrar los tiempos reales de ejecución del proyecto. También tiene la capacidad de generar estimados de tiempo en cada etapa del desarrollo de un proyecto.. 17.

(27) ISC-2003-1-17. 3.4 Casos de uso El siguiente es el listado de los casos de uso que dan soporte a los requerimientos de la aplicación. En el Anexo 1. Diagrama de Casos de Uso, se presentan los diagramas para esta aplicación. Y luego se presenta el detalle de cada uno en el Anexo 2. Casos de Uso Detallados.. ID. NOMBRE. CU-ADM-1. Administrar Categorías. CU-ADM-1.1. Crear Categoría. CU-ADM-1.2. Editar Categoría. CU-ADM-1.3. Eliminar Categoría. CU-ADM-2. Administrar Clientes. CU-ADM-2.1. Crear Cliente. CU-ADM-2.2. Editar Cliente. CU-ADM-2.3. Eliminar Cliente. CU-ADM-3. Administrar Proyectos. CU-ADM-3.1. Crear Proyecto. CU-ADM-3.1.1. Asociar Cliente. CU-ADM-3.1.2. Asociar Usuario. CU-ADM-3.2. Editar Proyecto. CU-ADM-3.3. Eliminar Proyecto. CU-ADM-4. Administrar Usuarios. CU-ADM-4.1. Crear Usuario. CU-ADM-4.2. Editar Usuario. 18.

(28) ISC-2003-1-17. CU-ADM-4.3. Eliminar Usuario. CU-OPR-1. Ajustar Pesos. CU-OPR-2. Generar Estimado Etapa. CU-OPR-3. Registrar Conteo. CU-OPR-4. Registrar Tiempo Ejecutado. CU-OPR-5. Reporte Proyecto. Tabla 8. Casos de Uso. 19.

(29) ISC-2003-1-17. 3.5 Entidades A continuación se presentan las entidades de base de datos sobre las cuáles se debe apoyar la aplicación. En el Anexo 3. Modelo Entidad Relación, se encuentra una representación gráfica de las mismas.. categorias cat_id. integer. NOT_NULL. cat_id_tipo_categoria. integer. NOT_NULL. cat_nombre. varchar(50). NOT_NULL. cat_descripcion. varchar(100). cat_peso. double. NOT_NULL. cat_etapa. integer. NOT_NULL. clie_id. integer. NOT_NULL. clie_nombre. varchar(50). NOT_NULL. clie_descripcion. varchar(100). clie_contacto. varchar(80). clie_direccion. varchar(100). clie_telefono. integer. clie_ciudad. varchar(50). clientes. etapas_proyecto. 20.

(30) ISC-2003-1-17. etpr_id. integer. NOT_NULL. etpr_nombre. varchar(50). NOT_NULL. etpr_descripcion. character(100). proyectos proy_id. integer. NOT_NULL. proy_nombre. varchar(50). NOT_NULL. proy_descripcion. varchar(100). proy_id_cliente. integer. NOT_NULL. proy_id_usuario. integer. NOT_NULL. sec_tabla. varchar(20). NOT_NULL. sec_proximo. integer. NOT_NULL. tcat_id. integer. NOT_NULL. tcat_nombre. varchar(50). NOT_NULL. tcat_descripcion. varchar(100). NOT_NULL. integer. NOT_NULL. secuencias. tipos_categorias. tipos_usuarios tusr_id. 21.

(31) ISC-2003-1-17. tusr_nombre. varchar(50). tusr_descripcion. varchar(100). NOT_NULL. usuarios usr_id. integer. NOT_NULL. usr_tipo. integer. NOT_NULL. usr_nombre. varchar(50). NOT_NULL. usr_login. varchar(50). NOT_NULL. usr_password. varchar(50). NOT_NULL. usr_descripcion. varchar(100). usr_id_jefe. integer. usr_habilidades. varchar(200). NOT_NULL. tiempos tie_id. integer. tie_ejecutado. double. tie_fecha_ejecutado. date. tie_id_proyecto. integer. NOT_NULL. tie_id_categoria. integer. NOT_NULL. tie_id_etapa. integer. NOT_NULL. tie_id_unidad. integer. NOT_NULL. 22. NOT_NULL.

(32) ISC-2003-1-17. conteos cnt_id. integer. NOT_NULL. cnt_conteo. integer. NOT_NULL. cnt_fecha_conteo. date. NOT_NULL. cnt_id_proyecto. integer. NOT_NULL. cnt_id_categoria. integer. NOT_NULL. cnt_id_etapa. integer. NOT_NULL. und_id. integer. NOT_NULL. und_nombre. varchar(50). NOT_NULL. und_descripcion. varchar(100). und_factor. integer. NOT_NULL. conp_id_proyecto. integer. NOT_NULL. conp_id_etapa. integer. NOT_NULL. conp_total_estimado. integer. conp_total_ejecutado. double. unidades. consolidados_proyecto. 23.

(33) ISC-2003-1-17. 3.6 Definición de la Arquitectura 3.6.1 Evaluación de la Base de Datos Herramientas evaluadas (MySQL, PostgreSQL). 3.6.1.1 Características Técnicas El siguiente cuadro compara las principales características generales que debe poseer una base de datos. Característica Licencia Plataformas Soporte SQL Características adicionales. Escalabilidad Velocidad Estabilidad Consumo de recursos Integridad de Datos Seguridad Autenticación Soporte SSL Soporte Unicode Concurrencia y Bloqueo Interfaces Programación Tipos de Tablas (motor). PostgreSQL BDS Unix ANSI SQL (consultas con UNION, UNION ALL y EXCEPT) Esquemas, Vistas, Triggers, Procedimientos, Outer Joins, Integridad Referencial, Reglas, Secuencias, Herencia Alta Media Alta Alto/Medio SI (transacciones, llaves foráneas) Media/Alta Kerberos, md5, crypt, password SI (Nativo) SI Alta (MVCC) ODBC, JDBC, C, C++, PHP, Perl, TCL, ECPG, Python y Ruby Tipo propietario. 24. MySQL GPL Unix y Windows ANSI SQL (sin subselects) Esquemas, Foreign Keys (tipo de tabla). Baja Alta Alta (mas utilizada) Bajo NO Alta (acceso a nivel de usuario, tabla y host) SI NO Media ODBC, JDBC, C/C++, OLEDB, Delphi, Perl, Python, PHP ISAM, MYISAM, BerkeleyDB, InnoDB, HEAP, MERGE, Gemini.

(34) ISC-2003-1-17. Transacciones. SI. Replicación Backup en Caliente. SI (mediante adiciones) SI. SI (dependiendo del tipo de tabla) SI SI. Tabla 9. Características deseadas en el motor de Base de Datos. 3.6.1.2 Características Adicionales PostgreSQL (versión 7.3.2) •. Permite la creación de índices parciales y funcionales. •. Posee herramientas para generar SQL portable para compartir con otros sistemas compatibles con SQL. •. Maneja un sistema de tipos de datos extensible para proveer tipos de datos definidos por el usuario, y rápido desarrollo de nuevos tipos. •. Tiene funciones de compatibilidad para ayudar en la transición desde otros sistemas menos compatibles con SQL. •. Posee las siguientes herramientas de administración (pgAccess, pgAdmin). MySQL (versión 4.0) •. Utiliza un cache de consultas. •. Permite el indexamiento y búsqueda sobre texto. •. Posee una librería para bases de datos incluidas. Herramienta escogida: PostgreSQL PostgreSQL tiene un conjunto de características destacadas en el soporte de transacciones y SQL que facilitan el desarrollo de aplicaciones de alto volumen ofreciendo gran estabilidad, confiabilidad, escalabilidad y rendimiento. Aunque MySQL ofrece características interesantes en cuanto al manejo de SQL y transacciones, carece de elementos importantes que faciliten y hagan flexible el desarrollo de aplicaciones. Además su escalabilidad e integridad de datos presenta problemas en grandes sistemas. Además, PostgreSQL posee todos los beneficios del software libre con un sistema de licenciamiento más flexible, permitiendo la instalación ilimitada en diferentes servidores, con altos beneficios en el ahorro de costos durante la operación y. 25.

(35) ISC-2003-1-17. mantenimiento y un constante desarrollo de nuevas características y corrección de errores.. 3.6.2 Evaluación del Servidor de Aplicaciones Herramientas evaluadas (Tomcat, JBoss) Tomcat (versión 4.1.24) Tomcat es un contenedor Web que implementa las especificaciones Servlet 2.3 y Java Server Pages 1.2 desarrolladas por Sun e incluye un conjunto de características adicionales que lo convierten en una herramienta útil para desarrollar y desplegar aplicaciones y servicios Web. o Ofrece facilidades de instalación sobre cualquier plataforma (Windows/Unix) y su configuración se hace mediante un único archivo en formato XML (server.xml) cuyas características y propiedades son sencillas de entender y están bien documentadas. o Soporta la integración de recursos JNDI. Esta característica facilita la utilización y configuración de Bases de Datos (mediante el uso de DataSource) de una manera transparente para las aplicaciones Web. o Permite personalizar el comportamiento y los recursos disponibles para cada aplicación Web mediante la configuración de descriptores XML (server.xml y web.xml) o Integra una aplicación Web de administración que permite manejar las aplicaciones Web sin necesidad de detener o reiniciar el servicio, esta funcionalidad permite desplegar e instalar nuevas aplicaciones, listar, remover o recargar aplicaciones existentes, revisar los recursos JNDI y detener o iniciar una aplicación. o Ofrece conectividad con diferentes servidores Web (principalmente Apache). Esta comunicación permite mantener en este servidor todo el contenido estático e integrar el contenido dinámico mediante la utilización del contenedor Web de Tomcat. o Posee características avanzadas que permiten: personalizar opciones en el motor JSP para optimizar su funcionamiento, integrar seguridad mediante los estándares de Java y utilizar protocolos como SSL. o Ha sido desarrollado en un ambiente de participación abierta y liberado bajo una licencia ASL (Apache Software Licence) y cuenta con el apoyo de un gran numero de desarrolladores en todo el mundo.. 26.

(36) ISC-2003-1-17. JBoss (versión 3.0.2) JBoss es un contenedor de EJB y componentes Web (Servlet/JSP) implementado mediante las especificaciones desarrolladas por Sun e incluye un amplio conjunto de características para facilitar el desarrollo de business componentes (EJB). o Es multiplataforma (Windows/Unix) y tiene como componentes integrados una base de datos (Hypersonic) y un servidor Web (JBossWEB, Tomcat) con configuraciones predeterminadas. o Integra un servicio JNDI mediante el modulo JBossNS, esto facilita la utilización de estos recursos dentro de los componentes del contenedor y de manera remota mediante propiedades de inicialización. o Requiere la configuración de los siguientes archivos básicos ejb-jar.xml, web.xml y jboss.xml, adicionalmente para cada uno de los servicios implementados por JBoss es necesario personalizar su propio archivo XML. o Permite manejar grandes aplicaciones mediante la utilización de clustering el cual esta apoyado en la integración de tecnologías como RMI, JNDI y EJB. o Ofrece las siguientes características para sus componentes EJB: persistencia (BMP y CMP), manejo de transacciones (BMT y CMT), seguridad (mediante JAAS), conexiones a base de datos y otros recursos (JCA) y servicio de mensajes (JMS).. Conclusión La herramienta escogida es Tomcat ya que se ajusta mejor a las necesidades del proyecto (ambiente Web) por su facilidad de instalación, configuración y mantenimiento, además posee una herramienta ágil para la administración de aplicaciones muy útil durante el desarrollo. Tomcat tiene una amplia aceptación en la comunidad Java, ya que es una de las primera implementaciones de Servlets/JSP, por tanto su madurez y estabilidad están plenamente comprobadas. Por otro lado, JBoss es una gran herramienta con muchas características y posibilidades de desarrollo, sin embargo si un proyecto no tiene todas estas necesidades, se puede presentar un aumento en la complejidad de la configuración de los servicios.. 27.

(37) ISC-2003-1-17. 4 Conclusiones Desafortunadamente el mal manejo del tiempo para esta investigación, sobre todo al inicio al buscar un tema de trabajo para el proyecto dirigido, no permitió el avance esperado y esto se ve reflejado en que no se logró terminar la etapa de desarrollo de la aplicación propuesta. Sin embargo, El estudio de las diferentes metodologías mencionadas en este documento muestra que aunque existe una dificultad inherente en el momento de calcular el esfuerzo requerido para el desarrollo de una aplicación orientada a objetos, también existen nuevas formas de aproximarse a una solución más cercana a la realidad. Un punto interesante, y a tener en cuenta sobre esté método es, como ya se había dicho anteriormente, que no tiene parámetros fijos o ‘cableados’ y esto hace que sea totalmente flexible y se pueda ajustar a un gran número de organizaciones diferentes entre sí y los resultados sean consistentes en cada uno de los casos. Otra característica es su mejora continua - ajuste de pesos - que hará que funcione cada vez mejor a medida que se vayan recolectando datos históricos de costos en diferentes proyectos y se vayan ajustando las categorías que le sirven a cada organización. Esta metodología no arroja resultados precisos desde la primera vez, pero mejora a medida que se sigue utilizando. En cuanto a la aplicación propuesta, es claro que es susceptible de muchas mejoras en su diseño y se le puede agregar mayor funcionalidad, como por ejemplo que el ajuste de los pesos se haga mediante cálculos estadísticos sobre los datos históricos y los nuevos; la implantación de un esquema de seguridad robusto; la presentación de reportes mediante en modo gráfico.. 28.

(38) ISC-2003-1-17. 5 Referencias. [Sencer]. Sencer Sultanoglu. Department of Computer Science & Engineering, Hacettepe University, Beytepe, Ankara, Turkey. http://ayna.hun.edu.tr/~sencer/research.html. [Woodward] Stuart Woodward. An Estimating Methodology for Object-Oriented Software. http://www.naturalmetrics.freeserve.co.uk/WNumbers.doc [Boehm]. Software Engineering Economics, Prentice Hall, 1981. [Tomcat]. http://jakarta.apache.org/tomcat/index.html. [Expresso]. http://www.jcorporate.com/product/expresso.html. [Struts]. http://jakarta.apache.org/struts/index.html. [Jboss]. http://www.jboss.org/. [Postgres]. http://www.postgres.org. [MySql]. http://mysql.org. 29.

(39) ISC-2003-1-17. Anexo 1. Diagrama de Casos de Uso. Figura 1. Diagrama de Casos de Uso del sistema. 30.

(40) ISC-2003-1-17. Figura 2. Casos de Uso del rol Administrador. 31.

(41) ISC-2003-1-17. Figura 3. Administración de Categorías. 32.

(42) ISC-2003-1-17. Figura 4. Administración de Clientes. 33.

(43) ISC-2003-1-17. Figura 5. Administración de Proyectos. 34.

(44) ISC-2003-1-17. Figura 6. Administración de Clientes. 35.

(45) ISC-2003-1-17. Figura 7. Casos de Uso del rol Usuario. 36.

(46) ISC-2003-1-17. Anexo 2. Casos de Uso Detallados A continuación se presentan los casos de uso identificados de la aplicación con su respectivo detalle y los procesos macro que deben ejecutar:. 37.

(47) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen:. CU-ADM-1 Administrar Categoría Administrador Permite la creación, edición y borrado de las categorías de clases, funciones y datos que son usadas por el sistema para la estimación de tamaños de los proyectos Indispensable. Deseable/ Indispensable: Prioridad: Alta Curso normal El sistema presenta en la página inicial el listado de las de eventos: categorías existentes y la opción de crear una nueva o editar o borrar una de las existentes. Caminos de excepción: Da soporte a:. Si no existen categorías actualmente, el listado inicial se presentará vacío y sólo estará disponible la opción CREAR REQ-ADM-1. 38.

(48) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen:. CU-ADM-1.1 Crear Categoría Administrador Permite la creación de nuevas categorías de clases, funciones y datos que son usadas por el sistema para la estimación de tamaños de los proyectos Indispensable. Deseable/ Indispensable: Prioridad: Alta Curso normal El sistema presenta en la página inicial el listado de las de eventos: categorías existentes y la opción de crear una nueva o editar o borrar una de las existentes. El administrador selecciona la opción ‘CREAR CATEGORÍA’. El sistema presenta el formulario de creación de categorías. El administrador debe: o seleccionar la etapa del desarrollo a la que va a pertenecer la nueva categoría, o seleccionar el tipo de categoría, o ingresar el nombre de la categoría, o ingresar una breve descripción o asignar un peso inicial o enviar el formulario El sistema recibe los datos y los inserta en la tabla categorias Caminos de Si el administrador no provee todos los datos mencionados, la excepción: el sistema rechazará la operación con un mensaje informando los datos que no han sido diligenciados. Da soporte a: CU-ADM-1. 39.

(49) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción: Da soporte a:. CU--ADM-1.2 Editar Categoría Administrador Permite la edición de una categoría existente en el sistema Deseable Media El sistema presenta en la página inicial el listado de las categorías existentes y la opción de crear una nueva o editar o borrar una de las existentes. El administrador selecciona para edición una categoría. El sistema presenta el formulario de edición de datos de la categoría. El usuario puede: o Modificar el texto de la descripción de la categoría o Modificar el peso de la categoría si ésta no está asociada a ningún conteo ni registro de tiempos. El usuario envía el formulario con las actualizaciones El sistema recibe los datos y actualiza el registro de la tabla categorias identificado con los datos recibidos Si no existen categorías registradas actualmente en el sistema, esta opción no estará disponible CU-ADM-1. 40.

(50) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción: Da soporte a:. CU-ADM-1.3 Borrar Categoría Administrador Permite borrar una categoría existente en el sistema Deseable Media El sistema presenta en la página inicial el listado de las categorías existentes y la opción de crear una nueva o editar o borrar una de las existentes. El administrador selecciona una categoría para su eliminación. El sistema verifica que la categoría no esté asociada a ningún conteo ni registro de tiempos. Si la categoría no tiene asociaciones, el sistema la elimina. Si la categoría tiene alguna asociación, le presenta al administrador un mensaje informando que no se puede eliminar debido a que ya está siendo usada. Si no existen categorías registradas actualmente en el sistema, esta opción no estará disponible CU-ADM-2. 41.

(51) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. CU-ADM-2 Administrar Clientes Administrador Permite la creación, edición y borrado de Clientes de la empresa en el sistema Deseable. Caminos de excepción: Da soporte a:. Si no existen clientes actualmente, el listado inicial se presentará vacío y sólo estará disponible la opción CREAR REQ-ADM-2. Media El sistema presenta en la página inicial el listado de los clientes de la empresa existentes en el sistema y la opción de crear uno nuevo o editar o borrar uno de los existentes. 42.

(52) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción: Da soporte a:. CU-ADM-2.1 Crear Cliente Administrador Permite registrar clientes de la empresa en el sistema Indispensable Alta El sistema presenta en la página inicial el listado de los clientes de la empresa existentes en el sistema y la opción de crear uno nuevo o editar o borrar uno de los existentes El administrador selecciona la opción CREAR un nuevo cliente El sistema presenta el formulario de creación de clientes donde El administrador debe: o ingresar el nombre del cliente, o ingresar una descripción del cliente o ingresar el nombre de un contacto o ingresar la dirección de la empresa o ingresar un teléfono o Ingresar la ciudad de la empresa o enviar el formulario El sistema recibe los datos y crea un nuevo registro con ellos en la tabla clientes Si el administrador no provee por lo menos el nombre de la empresa cliente, el sistema rechazará los datos informando al administrador mediante un mensaje en pantalla. CU-ADM-2. 43.

(53) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción: Da soporte a:. CU--ADM-2.2 Editar Cliente Administrador Permite la edición de un cliente existente en el sistema Deseable Baja El sistema presenta en la página inicial el listado de los clientes de la empresa existentes en el sistema y la opción de crear uno nuevo o editar o borrar uno de los existentes El administrador selecciona para edición un cliente de la lista El sistema presenta el formulario de edición de clientes El administrador puede cambiar la información contenida en uno o mas de los siguientes campos: o Nombre o Descripción o Contacto o Dirección o Teléfono o Ciudad El administrador envía el formulario El sistema recibe los datos y actualiza el registro de la tabla clientes que coincida con la identificación proporcionada Si no existen clientes actualmente, el listado inicial se presentará vacío y esta opción no estará disponible. Si el nombre es nulo, el sistema rechaza la operación notificándole al administrador la causa. CU-ADM-2. 44.

(54) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción:. Da soporte a:. CU-ADM-2.3 Borrar Cliente Administrador Permite borrar un cliente existente en el sistema Deseable Baja El sistema presenta en la página inicial el listado de los clientes de la empresa existentes en el sistema y la opción de crear uno nuevo o editar o borrar uno de los existentes El administrador selecciona para eliminación uno de los clientes de la lista El sistema verifica que si el cliente está asociado a un proyecto Si está asociado, rechaza la operación y notifica al administrador Si no está asociado, elimina el registro de la tabla clientes Si no existen clientes actualmente, el listado inicial se presentará vacío y esta opción no estará disponible. Si se intenta eliminar un cliente que esté asociado a un proyecto, el sistema no lo permitirá e informará mediante un mensaje de error al administrador CU-ADM-2. 45.

(55) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. CU-ADM-3 Administrar Proyectos Administrador Permite la creación, edición y borrado de proyectos. Caminos de excepción:. Si no existen proyectos en el sistema, el listado inicial se presentará vacío y la única opción disponible es CREAR proyecto REQ-ADM-3. Da soporte a:. Indispensable Media El sistema presenta en la página inicial el listado de los proyectos existentes y la opción de crear uno nuevo, o editar o borrar uno existente. 46.

(56) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen:. CU-ADM-3.1 Crear Proyectos Administrador Permite la creación de nuevas categorías de clases, funciones y datos que son usadas por el sistema para la estimación de tamaños de los proyectos Indispensable. Deseable/ Indispensable: Prioridad: Alta Curso normal El sistema presenta en la página inicial el listado de los de eventos: proyectos existentes y la opción de crear uno nuevo, o editar o borrar uno existente El administrador selecciona la opción CREAR un nuevo proyecto El sistema presenta el formulario de creación de proyectos donde El administrador debe: o ingresar el nombre del proyecto, o ingresar una breve descripción o seleccionar un cliente de la lista para asociarlo al proyecto o seleccionar el usuario del sistema encargado de la captura de datos para este proyecto o enviar el formulario El sistema recibe los datos y crea un nuevo registro con ellos en la tabla proyectos Si el usuario no proporciona el nombre del proyecto, el cliente Caminos de excepción: asociado y el usuario asignado, el sistema rechazará la operación indicando los datos faltantes Da soporte a: CU-ADM-3. 47.

(57) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción: Da soporte a:. CU--ADM-3.2 Editar Proyecto Administrador Permite la edición de un proyecto existente en el sistema Deseable Media El sistema presenta en la página inicial el listado de los proyectos existentes y la opción de crear uno nuevo, o editar o borrar uno existente El administrador selecciona un proyecto para edición El sistema presenta el formulario de modificación de proyectos El administrador sólo puede modificar la descripción del proyecto El administrador envía el formulario El sistema recibe los datos y actualiza el registro de la tabla proyectos identificado con los datos recibidos Si no existen proyectos en el sistema, esta opción no estará disponible CU-ADM-3. 48.

(58) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción: Da soporte a:. CU-ADM-3.3 Borrar Proyecto Administrador Permite borrar un proyecto existente en el sistema Deseable Media El sistema presenta en la página inicial el listado de los proyectos existentes y la opción de crear uno nuevo, o editar o borrar uno existente El administrador selecciona para eliminación un proyecto El sistema verifica que el proyecto seleccionado no tenga registrados conteos ni tiempos ni consolidados del proyecto Si existe alguna de estas asociaciones, el sistema rechaza la operación y notifica la causa al administrador. Si no existen estas asociaciones, el registro es eliminado Si no existen proyectos en el sistema, esta opción no estará disponible CU-ADM-3. 49.

(59) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. CU-ADM-4 Administrar Usuarios Administrador Permite la creación, edición y borrado de Usuarios del sistema Deseable. Caminos de excepción:. Si no existen usuarios registrados en el sistema, el listado inicial se presenta vacío y la única opción disponible es la de CREAR usuarios REQ-ADM-4. Da soporte a:. Media El sistema presenta en la página inicial el listado de los usuarios existentes en el sistema y la opción de crear uno nuevo o editar o borrar uno de los existentes. 50.

(60) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen:. CU-ADM-4.1 Crear Usuario Administrador Permite la creación de nuevos usuarios encargados del ingreso de conteo de objetos y estimación de tamaños en los proyectos Indispensable. Deseable/ Indispensable: Prioridad: Alta Curso normal El sistema presenta en la página inicial el listado de los de eventos: usuarios existentes en el sistema y la opción de crear uno nuevo o editar o borrar uno de los existentes El administrador selecciona la opción CREAR un nuevo usuario El sistema presenta el formulario de creación de usuarios donde El administrador debe: o seleccionar el tipo de usuario a crear o ingresar el nombre del usuario, o ingresar un login para el usuario en el sistema o ingresar la clave de este usuario en el sistema o ingresar una breve descripción o seleccionar de la lista de usuarios al superior inmediato o Ingresar una descripción de las habilidades generales del usuario o enviar el formulario El sistema recibe los datos y crea un nuevo registro con ellos en la tabla usuarios Caminos de Si alguno de los datos, a excepción de las descripciones, es excepción: nulo, el sistema rechaza la operación y notifica al administrador los datos faltantes. Da soporte a: CU-ADM-4. 51.

(61) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción: Da soporte a:. CU--ADM-4.2 Editar Usuario Administrador Permite la edición de un usuario existente en el sistema Deseable Media El sistema presenta en la página inicial el listado de los usuarios existentes y la opción de crear uno nuevo, o editar o borrar uno existente El administrador selecciona un usuario para edición El sistema presenta el formulario de modificación de usuarios El administrador sólo puede modificar la descripción general y/o las habilidades del usuario El administrador envía el formulario El sistema recibe los datos y actualiza el registro de la tabla usuarios identificado con los datos recibidos Si no existen usuarios registrados en el sistema, esta opción no estará disponible CU-ADM-4. 52.

(62) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción: Da soporte a:. CU-ADM-4.3 Borrar Usuario Administrador Permite borrar un usuario existente en el sistema Deseable Media El sistema presenta en la página inicial el listado de los usuarios existentes y la opción de crear uno nuevo, o editar o borrar uno existente El administrador selecciona para eliminación un usuario El sistema verifica que el usuario seleccionado no esté asignado a ningún proyecto Si no está asignado, el usuario se elimina Si está asignado a algún proyecto, el sistema rechaza la operación y notifica la causa al administrador. Si no existen usuarios registrados en el sistema, esta opción no estará disponible CU-ADM-4. 53.

(63) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen:. CU-OPR-1 Ajustar Pesos Administrador Toma como base el tiempo empleado en todos los proyectos para la creación de un objeto de cada categoría y ajusta el peso de las categorías para mejorar la estimación de tiempos en el siguiente proyecto. Indispensable. Deseable/ Indispensable: Prioridad: Alta Curso normal El administrados selecciona la opción de Ajustar Pesos del de eventos: sistema El sistema calcula, para cada categoría registrada, el tiempo ejecutado promedio histórico y actualiza su peso asignado con este valor Caminos de Si para una categoría no existen tiempos registrados, el peso excepción: asociado no se actualiza Da soporte a: REQ-OPR-1. 54.

(64) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen:. CU-OPR-2 Generar Estimado Etapa Usuario Registrado Calcula el tiempo estimado de desarrollo de los objetos detectados en la presente etapa de desarrollo del proyecto a partir de los conteos por categoría realizados y los pesos asociados a cada categoría. Indispensable. Deseable/ Indispensable: Prioridad: Alta Curso normal El sistema presenta la página inicial del usuario, donde éste de eventos: tiene las siguientes opciones: Registrar Conteo, Registrar Tiempo Ejecutado, Estimar Tiempo por Etapa, ver reporte de un proyecto. El usuario selecciona la opción de Generar Estimado para una Etapa El sistema presenta un listado de las etapas sobre las que se puede generar estimados El usuario selecciona la etapa para la que desea calcular el tiempo estimado de desarrollo El sistema calcula la sumatoria de todos los conteos asociados al proyecto seleccionado en la etapa seleccionada multiplicados por el peso asignado a la categoría a la que pertenece el conteo y presenta el resultado medido en horas Caminos de Si el usuario no tiene proyectos asignados, esta opción no excepción: estará disponible Da soporte a: REQ-OPR-2. 55.

(65) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción:. Da soporte a:. CU-OPR-3 Registrar Conteo Usuario Registrado Permite ingresar el conteo de objetos por categoría detectados en cada etapa del desarrollo de un proyecto Indispensable Alta El sistema presenta la página inicial del usuario, donde éste tiene las siguientes opciones: Registrar Conteo, Registrar Tiempo Ejecutado, Estimar Tiempo por Etapa, ver reporte de un proyecto. El usuario selecciona la opción Registrar Conteo El sistema presenta el formulario de registro de conteo El usuario debe: o seleccionar un proyecto de la lista de proyectos asignados o seleccionar la etapa que desea registrar o seleccionar el tipo de categoría sobre la que se van a registrar los conteos El sistema presenta las categorías creadas para el tipo seleccionado El usuario o ingresa las cantidades de objetos detectados para cada una de las categorías o envía el formulario El sistema recibe los datos y los registra en la tabla conteos Si el usuario no tiene proyectos asociados, no podrá registrar conteos. Si no existen categorías registradas del tipo seleccionado, el sistema no permitirá registrar conteos y notificará el usuario. Si el usuario no ingresa por lo menos un conteo para alguna categoría, el sistema rechazará la operación y notificará al usuario la causa. REQ-OPR-3. 56.

(66) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen: Deseable/ Indispensable: Prioridad: Curso normal de eventos:. Caminos de excepción:. Da soporte a:. CU-OPR-4 Registrar Tiempo Ejecutado Usuario Registrado Permite registrar los tiempos reales de desarrollo utilizados por cada objeto en la presente etapa de desarrollo Indispensable Alta El sistema presenta la página inicial del usuario, donde éste tiene las siguientes opciones: Registrar Conteo, Registrar Tiempo Ejecutado, Estimar Tiempo por Etapa, ver reporte de un proyecto. El usuario selecciona la opción Registrar Tiempo Ejecutado El sistema presenta el formulario de registro de Tiempos El usuario debe: o seleccionar un proyecto de la lista de proyectos asignados o seleccionar la etapa que desea registrar o seleccionar el tipo de categoría sobre la que se van a registrar los tiempos El sistema presenta las categorías creadas para el tipo seleccionado El usuario o digita los tiempos ejecutados para cada una de las categorías presentadas o selecciona las unidades en que están medios estos tiempos o envía el formulario El sistema recibe los datos, convierte todos los tiempos recibidos a horas y los registra en la tabla tiempos Si el usuario no tiene proyectos asociados, no podrá registrar tiempos. Si no existen categorías registradas del tipo seleccionado, el sistema no permitirá registrar tiempos y notificará el usuario. Si el usuario no ingresa por lo menos el tiempo ejecutado para alguna categoría, el sistema rechazará la operación y notificará al usuario la causa. REQ-OPR-4. 57.

(67) ISC-2003-1-17. ID: Caso de uso: Actores: Descripción o Resumen:. CU-OPR-5 Reporte Proyecto Administrador, Usuario Registrado Despliega un reporte de conteo de objetos, tiempo estimado de desarrollo y tiempo real ejecutado por categoría para un proyecto determinado Deseable. Deseable/ Indispensable: Prioridad: Baja Curso normal El usuario selecciona el proyecto para el cuál desea generar de eventos: el reporte El sistema le presenta los resultados en pantalla Caminos de excepción: Da soporte a: REQ-OPR-5. 58.

(68) ISC-2003-1-17. Anexo 3. Modelo Entidad Relación. 59.

(69)