cocomo completo

Estimacin de Proyectos Software

ESTIMACIN DE PROYECTOS SOFTWARE

ANA M MORENO S.- CAPUCHINO

Ana M Moreno S.-Capuchino

Pg. 1


CONTENIDO

TEMA 1: TEMA 2: TEMA 3: TEMA 4: TEMA 5:

INTRODUCCIN ESTIMACIN DE SOFTWARE MTRICAS DE SOFTWARE TCNICAS DE ESTIMACIN MTODO DE ESTIMACIN DE PUNTOS DE FUNCIN MTODO DE ESTIMACIN COCOMO

TEMA 6:

BIBLIOGRAFA


Pg. 2


TEMA 1: INTRODUCCIN


Pg. 3


1.1. Marco de la Gestin de Proyectos. Durante muchos aos el proceso de desarrollo de software ha sido considerado como un arte dejado a la improvisacin del jefe del proyecto. Los proyectos se dirigan ms bajo consideraciones tcnicas, que de gestin. Las actividades de estimacin y de planificacin quedaban relegadas a un mero acto protocolario al comienzo del proyecto. Posteriormente, el seguimiento y control se realizaban sin un mnimo de rigor, dada la baja calidad de la estimacin y la planificacin realizada. Mientras los proyectos han sido de complejidad media la euforia de la tecnologa ha dominado el mercado. Las desviaciones en costos y tiempo han sido consideradas como algo natural en un proyecto software. Algo as como si nadie estuviera obligado a saber cundo se terminar el sistema ni cunto costar. El continuo incremento de la potencia de los ordenadores ha hecho posible concebir sistemas cada vez ms complejos. El cerebro humano tiene solamente una capacidad limitada para manejar tales sistemas, y esto puede aplicarse igualmente al desarrollo del software para tratarlos. Adems, como puede verse en la Figura 1.1, conforme los costes del hardware disminuyen, el coste de producir el software tiene un mayor peso dentro del coste del proyecto. Conforme los costes de desarrollo y mantenimiento del software crecen es necesario predecirlos y controlarlos. Esto es algo que hasta el momento los constructores de software han encontrado muy difcil de realizar. Otro problema existente es que no es siempre posible evitar errores en los sistemas complejos, lo cual puede producir costes elevados, y perdidas fatales. El software controla actualmente sistemas mdicos, trfico areo, sistemas financieros o sistemas de misiles. Los errores en estos sistemas pueden implicar serios desastres. Los ejemplos son innumerables en todos los dominios de la aplicacin de las Tecnologas de la Informacin, como se ha visto en la Unidad de Introduccin a la Ingeniera del Software. Segn ha crecido la experiencia en la construccin de los sistemas software, se han elaborado tcnicas para el desarrollo de las especificaciones y el diseo. Estas disciplinas pueden, en la actualidad, ensearse y aplicarse segn reglas muy precisas. Sin embargo, se ha puesto de manifiesto que el uso sistemtico de estas tcnicas para la especificacin y el diseo de software no ha resuelto el problema de la produccin del software. En la industria se sigue hablando de "crisis del software"; la cantidad de esfuerzo perdido en el desarrollo de software continua en situacin similar a hace aos y los productos a menudo son entregados con errores significativos que producen costes y peligros graves. El hecho es que no es suficiente avanzar a travs de las etapas tradicionales del proceso de construccin de software y esperar un producto satisfactorio al final del mismo. El proceso de produccin del software tiene que ser gestionado y dirigido de una manera extremadamente rigurosa y cuantitativa. De este modo se podr verificar que el trabajo correspondiente a cada fase se ha realizado completamente dentro de los plazos de tiempo y coste establecidos y de acuerdo con estndares especficos de calidad.


Pg. 4


Coste 100

80Desarrollo

60

40 Software 20Mantenimiento

0 1955 1975 1995

Ao

Figura 1.1. Relacin de costes Hw/Sw

Por lo tanto, las claves del xito en la gestin del desarrollo de software son: una adecuada gestin del proyecto de desarrollo de software y una adecuada gestin del proceso de software. Qu entendemos por gestin del proyecto de desarrollo de software? La gestin del proyecto consiste en la utilizacin de las tcnicas y actividades de gestin requeridas para conseguir un producto software de alta calidad, de acuerdo con las necesidades de los usuarios, dentro de un presupuesto y con una planificacin de tiempos establecidos previamente. Qu es entonces, la gestin del proceso del software? La gestin del proceso es el conjunto de tcnicas y actividades que permiten una adecuada gestin de los procesos personales de los constructores y de los productos que participan en el proyecto. A lo largo de esta Unidad y en las Unidades de Planificacin y Seguimiento profundizaremos en los conceptos de la gestin de proyectos. Veremos las actividades que lo componen y cmo llevarlas a cabo eficazmente. La gestin del proceso se ver cuando se explique el propio proceso de desarrollo. En primer lugar daremos una definicin rigurosa de proyecto. Un proyecto es una accin en la que recursos humanos, financieros y materiales se organizan de una nueva forma para acometer un trabajo nico. En este trabajo, dadas unas especificaciones y dentro de


Pg. 5


unos lmites de costes y tiempo, se intenta conseguir un cambio beneficioso dirigido por unos objetivos cualitativos y cuantitativos. El aspecto esencial de un proyecto es el ser un trabajo nico que se realiza con una nueva organizacin para producir un cambio beneficioso. Estos elementos implican que un proyecto lleva una incertidumbre considerable y riesgo, y por lo tanto su xito depender en gran medida de una adecuada gestin.

1.2. Tareas Crticas en la Gestin de Proyectos. El nmero de tareas identificables a realizar por un director de proyectos, dentro del rea de la gestin de proyectos excede de cien. Sin embargo, hay tres que son crticas y que deben ser desarrolladas correctamente si se desea que el proyecto termine bien. Estas tareas son: a) Estimacin de duracin, coste y esfuerzo necesarios para construir el producto. b) Planificacin de tareas a realizar, asignacin de personas, tiempos, etc. para construir el producto. c) Seguimiento, durante la realizacin del trabajo, para asegurar el cumplimiento de lo planificado en cuanto a costes, fechas, etc. En caso de desviaciones del plan, se deben tomar las medidas pertinentes.

1.2.1. Estimacin de Proyectos La primera tarea en la gestin de proyectos es la estimacin. La estimacin se define como el proceso que proporciona un valor a un conjunto de variables para la realizacin de un trabajo, dentro de un rango aceptable de tolerancia. Podemos definirlo tambin como la prediccin de personal, del esfuerzo, de los costes y de la planificacin que se requerir para realizar todas las actividades y construir todos los productos asociados con el proyecto. Uno de los parmetros crticos de la estimacin es determinar su exactitud. La estimacin puede realizarse a partir de datos histricos o con herramientas. Curiosamente, en la actualidad, est ocurriendo algo sorprendente y es que algunas herramientas actualmente existentes proporcionan una estimacin ms exacta que la obtenida por la empresa a partir de sus datos histricos.

1.2.2. Planificacin de Proyectos La planificacin de un proyecto se define como el proceso de seleccin de una estrategia para la produccin de unos productos finales dados, as como la definicin de las actividades a realizar para conseguir ese objetivo, la concurrencia y solapamiento de dichas actividades. Tambin debe asignar recursos a las actividades anteriores en funcin del plan establecido.


Pg. 6


La estimacin y la planificacin son actividades relacionadas pero difieren en su alcance y propsito. La estimacin normalmente est orientada al proyecto en su conjunto, mientras que la planificacin esta dirigida a los individuos. Obviamente, debe existir una fuerte correlacin entre la estimacin realizada y las tareas especficas a realizar da a da por el equipo de proyecto. La estimacin la realizaremos al principio del proyecto, precisamente para pedir presupuesto, saber cunta gente se necesita, otros recursos, etc., y la planificacin es la etapa donde se asigna exactamente quin hace qu y en cuanto tiempo. Algo as como: Cunto tiempo y dinero necesito para conocer Pars?, 10 das y 500.000 pesetas. Esto es una estimacin. El primer da voy al aeropuerto a las 10 horas, cojo el avin y llego a Pars a las... es una planificacin. Una diferencia tcnica entre las herramientas de planificacin y estimacin es que estas ltimas son normalmente sistemas expertos, construidos a partir de las reglas derivadas de miles de proyectos. Las herramientas para la planificacin, en cambio, no son sistemas expertos, sino herramientas para ser utilizadas por personas expertas. La razn para esta diferencia es que las herramientas de estimacin estn basadas en miles de proyectos y pueden llegar a alcanzar una gran exactitud, pero el trabajo da a da de las personas que participan en el proyecto con sus conocimientos, planes de vacaciones e interrupciones requieren un director de proyectos expertos y casi con ajustes diarios de la planificacin. Se puede sacar una conclusin y es que las herramientas de planificacin dan los mejores resultados con los mejores directores. En cambio, las herramientas de estimacin pueden aumentar y mejorar las capacidades de los nuevos jefes de proyecto o de los expertos cuando tienen que planificar proyectos en los que no existe una experiencia previa. Las herramientas de planificacin son las ms utilizadas por los jefes de proyectos. 1.2.3. Seguimiento de Proyectos El seguimiento es la recoleccin de datos y su almacenamiento, sobre tiempos, recursos, costes, e hitos asociados con un proyecto, para el anlisis y estudio de la evolucin real de dicho proyecto, comparando el progreso real con el planificado. Desafortunadamente, el seguimiento de los proyectos de desarrollo de software no ha sido todo lo correcto que cabra esperar. Como ya se vio en otra Unidad, muchos sistemas son inexactos y entre el 35% y el 75% de los costes reales del software no son registrados. Las mayores omisiones en el seguimiento son debidos a: Tiempo extra de profesionales no registrado. Coste de viajes y reuniones. Esfuerzo de los directivos. Esfuerzo de los usuarios en tareas tcnicas, como escritura de manuales, pruebas o participacin en revisiones. Soporte administrativo. Desarrollos iniciales antes de comenzar el proyecto.

Existen muchas ms, pero stos son una muestra de la situacin, y de la poca exactitud del seguimiento.


Pg. 7


As mismo, adems de la omisin de datos, la descripcin de cuentas utilizadas para acumular costes no es lo suficientemente detallada como para llevar una contabilidad seria del proyecto. Algunos costes se acumulan solamente como gasto del proyecto, y estn ms pensados para ser utilizados por los contables, que para servir de ayuda a los jefes de proyectos. 1.2.4. Relacin entre las Actividades Clave de la Gestin de Proyectos Los conceptos anteriores pueden dar la falsa impresin de que cada uno de los procesos descritos es independiente, discreto y de que se aplican una sola vez. El hecho es que ste no es el caso. Cuando tenemos una estimacin inicial sobre el proyecto que vamos a desarrollar, debemos de definir una planificacin para el proyecto siempre dentro del marco de esa estimacin, es decir, la salida del proceso de estimacin debe ser una de las entradas del proceso de planificacin. Una vez realizada la planificacin comenzaremos el seguimiento del proyecto. Por lo tanto, las entradas del proceso de seguimiento sern la estimacin y planificacin del proyecto, adems de los datos reales recogidos mientras evoluciona el proyecto. Durante la realizacin del proceso de seguimiento se puede producir una replanificacin si nos apartamos del plan original. Una fuerte desviacin durante el seguimiento puede ser la consecuencia, por ejemplo, de un cambio en la naturaleza del proyecto. En ese caso, necesitaremos una reestimacin y replanificacin en consecuencia, como muestra la Figura 1.2. La gestin del desarrollo del software es ineficaz a causa de que dicho desarrollo es extremadamente complejo, disponindose de pocas medidas para guiar y evaluar el proceso. De esta manera sin una estimacin eficaz y exacta, la planificacin y el seguimiento eficaces son prcticamente imposibles de conseguir.

ESTIMACION

PLANIFICACION

SEGUIMIENTO DESARROLLO

Figura 1.2. Relacin entre las Tareas de Estimacin Planificacin y Seguimiento.

A partir de este momento, esta Unidad se centra en el proceso de Estimacin de software. Existen otras unidades que tratan la Planificacin y el Seguimiento.


Pg. 8


TEMA 2: ESTIMACIN DE SOFTWARE


Pg. 9


2.1. Problemtica del Proceso de Estimacin del Software Ya en los aos 70 se comenz a hablar del proceso de estimacin del software. Sin embargo, y desafortunadamente, el arte y la ciencia de la estimacin estn hoy en da es su infancia. La industria del software sigue fuera de control, con costes y tiempos desmedidos. Para hablar de las posibilidades actuales de la estimacin, primero debemos revisar su estado actual y explorar las necesidades de la comunidad de desarrollo de software. Qu es la estimacin? Vista desde el punto de vista de un diccionario, una estimacin es un conjunto aproximado de valores para algo que ha de ser hecho. En el mundo del desarrollo de software, Larry Putnam ha apuntado que la gestin del desarrollo de software considera la estimacin como una actividad que permite obtener, principalmente, respuestas aproximadas a las siguientes preguntas Cunto costar? Cunto tiempo llevar hacerlo? La respuesta a estas dos preguntas constituye el quid del tema que aqu se contempla. Sin embargo, y como se puede prever sta no es tan sencilla. Qu hace que la estimacin sea tan difcil de realizar? Las razones para esta complejidad son las siguientes: 1. No existe un modelo de estimacin universal o una formula que pueda ser usada para todas las organizaciones. El hecho es que se pueden definir unos principios generales, pero cada interpretacin es particular y diferente del resto. Cada organizacin tiene sus propios recursos, procedimientos e historia; y es necesario ajustar los procesos de estimacin a esos parmetros nicos. Adems, a medida que estos parmetros cambien, deben cambiar los procesos de estimacin. Hay muchas personas implicadas en los proyectos que precisan de estimaciones. La alta direccin de la empresa necesita las estimaciones para tomar decisiones de negocio, sobre la viabilidad del proyecto y su continuidad a lo largo del desarrollo. La direccin del proyecto necesita las estimaciones para hacer sugerencias a la alta direccin, para obtener los resultados necesarios para el desarrollo del proyecto, y para hacer una planificacin detallada y controlar el proyecto. Cada recurso del proyecto tambin necesita estimaciones para planificar y controlar su propio trabajo. La utilidad de una estimacin tambin depender de la etapa de desarrollo en la que nos encontremos. Al comienzo de un proyecto, normalmente slo se necesitan estimaciones de coste y duracin aproximadas. A medida que el proyecto madura las estimaciones que se necesitan sern ms exactas. Con lo que una estimacin til al comienzo del proyecto puede no serlo ms tarde.

2.

3.


Pg. 10


4.

La estimacin, a menudo, se hace superficialmente, sin apreciar el esfuerzo requerido para hacer un trabajo. Adems, tambin se suele dar el caso de que la estimacin sea necesaria antes de obtener las especificaciones de requisitos del sistema. Por esta razn, una situacin tpica es que se presiona a los estimadores para que se apresuren en escribir una estimacin anticipada del sistema que no comprenden an. Las estimaciones claras, completas y precisas son difciles de formular, especialmente al inicio del proyecto. Los cambios, adaptaciones y ampliaciones son ms la regla que la excepcin: como consecuencia de ello, deben adaptarse tambin las planificaciones y los objetivos. Las caractersticas del software y de su desarrollo hacen difcil la estimacin. Por ejemplo, el nivel de abstraccin, la complejidad, el grado de medicin del producto y del proceso, los aspectos innovadores,... La rapidez con la que cambia la tecnologa de la informacin y las metodologas de desarrollo de software son problemas para la estabilizacin del proceso de estimacin. Por ejemplo, son difciles de predecir la influencia de nuevos bancos de pruebas, lenguajes de cuarta y quinta generacin, estrategias de prototipado, y de tcnicas y herramientas novedosas en general. Un estimador puede no tener mucha experiencia en estimar desarrollos, especialmente de proyectos largos. Cuntos proyectos largos puede alguien dirigir en, por ejemplo, 10 aos? Existe una tendencia aparente de los desarrolladores hacia la subestimacin. Un estimador suele elegir una porcin de software debera tomar para luego extrapolarlo al resto del sistema, normalmente se ignoran los aspectos no lineales del desarrollo de software, por ejemplo, la coordinacin y la gestin. El estimador estima el tiempo que le llevara ejecutar personalmente una tarea, ignorando el hecho de que, a menudo, una parte del trabajo la realiza personal menos experimentado, con un ndice de productividad menor. Existen malas interpretaciones en las relaciones lineales entre la capacidad requerida por unidad de tiempo y el tiempo disponible. Esto significa que el software desarrollado por 25 personas en dos aos podr ser llevado a cabo por 50 personas en un ao. Esta interpretacin es errnea. Como ya se coment en otra Unidad una mujer puede dar a luz un nio a lo largo de 9 meses, pero 9 mujeres no dan a luz un nio en un mes. Aadir personal a un proyecto retrasado no tiene por qu disminuir el retraso. El estimador tiende a reducir en algn grado las estimaciones para hacer ms aceptable la oferta. Influyen un gran nmero de factores en el esfuerzo y duracin de un desarrollo de software. Estos factores se llaman drivers de coste o disparadores de coste. Ejemplos de estos disparadores son el tamao y complejidad del software, el compromiso y participacin del usuario, la experiencia del equipo de desarrollo. En general estos disparadores de coste son difciles de determinar.

5.

6.

7.

8.

9.

10.

11.

12. 13.


Pg. 11


Es importante profundizar ms en el tema de los disparadores de coste. Para mostrar su importancia, estudiaremos a continuacin algunos de ellos repartidos en cinco categoras, como se muestra en la Tabla 2.1. el producto software que se tiene que desarrollar: QU el significado de la produccin: CON QU el personal de produccin: QUIN la organizacin de produccin: CMO usuario/organizacin del usuario: PARA QUIN QU producto Tamao del software Calidad requerida Volatilidad de requisitos Complejidad del software Nivel de utilizacin Cantidad de documentacin Tipo de aplicacin Uso de tcnicas modernas de programacin - ocultacin de informacin - equipo de programacin principal - programac. estructurada - diseo top-down CON QU significado Restricciones del ordenador - tiempo de ejecucin - tiempo de respuesta - capacidad de memoria Usuarios de herramientas QUIN personal CMO proyecto PARA QUIN usuario Participacin Nmero de usuarios Estabilidad de la organizacin del usuario, procedimientos, formas de trabajo Experiencia del usuario con la informtica, nivel de conocimientos informticos

Calidad del personal Requisitos de la duracin del Experiencia del proyecto personal - dilatacin - compresin Calidad de gestin Bases para el control Disponibilidad para del proyecto el proyecto - matriz de organizacin - organizacin del proyecto - prototipado - incremental - desarrollo lineal

Tabla 2.1. Disparadores de coste En la Tabla anterior podemos ver diversos tipos de disparadores, todos ellos influirn en la estimacin que vallamos a realizar, lo realmente difcil es determinar cules son los disparadores de coste ms importantes en cada situacin especfica, cules son sus valores y cmo influyen en el esfuerzo y la duracin de cada proyecto. Para resolver estas cuestiones conviene tener en cuenta varios aspectos: Definicin


Pg. 12


Hay una falta de definiciones claras y aceptadas de los disparadores, tales como tamao, calidad, complejidad, experiencia,... Por ejemplo, cundo se dice que un desarrollador es experimentado y cundo no. Cuantificacin: La mayora de los disparadores de coste son difciles de cuantificar. A menudo, se utilizan medidas tales como: mucho, moderado, poco,... Objetividad: La objetividad es un factor de riesgo potencial. Lo que puede ser complejo para el desarrollador A, puede no serlo para el B. Correlacin: Es difcil considerar un driver independiente de los dems. Un cambio en el driver A, puede tener consecuencias en los valores de otros disparadores. Esta es una dificultad tremenda desde el punto de vista de la medibilidad. Relacin entre disparador y esfuerzo: Para la estimacin es importante poder predecir la relacin entre, por ejemplo, el tamao del software y el esfuerzo requerido, el nivel de calidad especificado y el esfuerzo requerido, etc. Calibracin: Es imposible hablar de los disparadores de coste ms importantes de forma aislada. Una situacin difiere mucho de otra.

Todos estos aspectos pueden proporcionar una idea de la complejidad del proceso de estimacin. Sin embargo, tambin se han destacado las consecuencias negativas de la falta de este proceso, y la importancia de su aplicacin.

2.2 Requisitos que debe Cumplir un Buen Estimador Quin debe realizar el proceso de estimacin de un proyecto software? El estimador debe se un profesional, que no tenga ningn inters, directo o indirecto, en los resultados del proceso de estimacin y que est nicamente guiado por su profesionalidad. El principal objetivo de un estimador es obtener unas estimaciones de calidad, las cuales no tienen siempre por qu coincidir con las expectativas de la direccin en trminos de coste y tiempo. Un buen estimador debera cumplir los siguientes requisitos: 1. Debe poseer una importante formacin y experiencia profesional que le ayuden a entender y solucionar los problemas de la gestin de proyectos.Pg. 13



2. 3.

Debe tener una posicin en la organizacin que le permita adoptar un juicio independiente. Debe basarse en un mtodo que pueda ser explicado, cuestionado, discutido y auditado por otros expertos. Siempre que use una herramienta de estimacin, sta debe ajustarse a su propsito de estimacin y debe soportar el mtodo. La herramienta tambin debe estar documentada y controlada. Debe ser capaz de describir su experiencia en cada estimacin. Es decir, describir los problemas a los que ha tenido que enfrentarse, las soluciones, etc. Debe ser capaz de documentar su estimacin, incluyendo los resultados obtenidos y cualquier informacin necesaria para hacer el proceso de estimacin repetible y verificarle.

4.

5.

6.

2.3. Marco Temporal de la Estimacin de Proyectos Cundo se debe realizar la estimacin de un proyecto software? A continuacin veremos en qu momento del desarrollo de un proyecto se ha de realizar el proceso de estimacin. La estimacin, como ya hemos anticipado, es un proceso continuo. A medida que el proyecto avanza, ms se conoce de l, y por lo tanto ms parmetros estn disponibles para introducir en un modelo de estimacin. El grado de informacin sobre los parmetros del sistema sigue una curva en forma de "s" tpica, como se muestra en la Figura 2.1. La estimacin continua nos permite el uso de un nico modelo coherente que pueda capturar y utilizar la informacin sobre el proyecto a medida que este se conozca. Ms precisamente, el proceso de estimacin comienza usando unas pocas variables claves para proveer las "macro-caractersticas" de un proyecto, y evoluciona incorporando informacin de ms bajo nivel para producir las "micro-caractersticas" del proyecto. La naturaleza del proceso de estimacin cambia a medida que el programa progresa. Supongamos que desarrollamos un proyecto con un ciclo de vida tradicional. Al principio, en la concepcin del sistema, slo necesitamos estimaciones a grosso modo para determinar el tamao del proyecto y estudiar su viabilidad. Es interesante conocer el esfuerzo total del proyecto, su duracin, riesgos, necesidades de personal, etc. A esta primera estimacin se le denomina macro-estimacin de un proyecto. Como entrada para esta estimacin se necesitan algunos parmetros descriptivos y genricos sobre el proyecto.


Pg. 14


Informacin100

1

Concepcin

Instalacin

Vida del producto Software

Figura 2.1. Grado de Informacin sobre un Proyecto

Una vez que los requisitos han sido definidos, se necesita una estimacin ms detallada para la siguiente fase, diseo del producto, con el fin de utilizarla para confeccionar una planificacin para dicha fase. Tambin se necesita una estimacin a ms alto nivel para el resto del proyecto. En este momento, los parmetros descriptivos y genricos que se emplean para hacer la primera estimacin se conocen ms exactamente, y tambin se dispone de informacin adicional sobre los recursos que intervendrn en el desarrollo, como por ejemplo la experiencia de los desarrolladores.Error! Marcador no definido. Despus de que el diseo del producto ha finalizado, puede ser incluso que la base de la estimacin haya cambiado, es decir, se puede pasar de utilizar parmetros descriptivos a emplear otros ms detallados como el nmero de mdulos esperados, o el nmero de lneas de cdigo. Tambin podran conocerse consideraciones tecnolgicas a un nivel de detalle razonable. Al final de la fase de diseo detallado, la informacin sobre el nmero de mdulos y lneas de cdigo, por ejemplo, puede ser refinada para la mejora de las estimaciones de las restantes fases. Cuando la codificacin, las pruebas y la instalacin han finalizado podemos obtener datos sobre el rendimiento y la calidad del sistema que, cuantificados adecuadamente, pueden constituir la base para la estimacin de defectos. Estos datos, junto con el conocimiento sobre el entorno del desarrollo, permitirn realizar estimaciones para la fase de mantenimiento. La Figura 2.2 muestra la exactitud con la que las estimaciones software se pueden hacer, en funcin de las fases del ciclo de vida tradicional, o el grado de conocimiento que tenemos sobre lo que pretende hacer el software. Ana M Moreno S.-Capuchino Pg. 15


Exactitud

4x

2x 1.5x 1.25x x 0.8x 0.67x 0.5x

tipos de personas y datos tipo de consultas carga de datos, tpo. de respuesta esttructuras de datos internas algoritmos detallados entendimeitno de especificaciones

0.25xViabilidad

Iniciacin

Especificacin requisitos

Especificacin de diseo

Especificacin de diseo detallado

Software aceptado

Fasess del Software

Planificacin y requisitos

Diseo producto

Diseo detallado

Desarrollo y pruebas

Figura 2.2. Exactitud de las Estimaciones a lo largo del Desarrollo.

Como puede verse en la Figura 2.2, cuando comenzamos a estudiar las distintas posibilidades para desarrollar un nuevo sistema, las estimaciones pueden oscilar en un rango de cuatro veces por arriba o por abajo. Este rango proviene de la gran incertidumbre que se tiene en este momento sobre la naturaleza real del producto. As, por ejemplo, no se sabe qu tipo de personas (gestores, consultores, analistas,...) o qu tipos de datos (digitales o analgicos, numricos o texto,...) soportarn el sistema. Las incgnitas anteriores se conocen cuando finaliza la fase de viabilidad y se decide un procedimiento de operacin. En este momento, el rango de nuestra estimacin disminuye en dos en cada direccin. Este rango es razonable porque todava no se tiene informacin sobre los tipos de consulta que soportar el sistema, las funciones concretas, etc. Estos elementos sern conocidos en el momento de realizar la especificacin de requisitos, en el que la estimacin software estar en un rango de 1,5 en cada direccin. En el momento en que hayamos completado y validado la fase de diseo del producto, tendremos informacin sobre la estructura de datos interna del producto software, sobre las tcnicas para el manejo de buffers, etc. En este momento la estimacin software tendr un rango de exactitud del 1,25. Existen todava incgnitas, como los algoritmos que se usarn para la planificacin de tareas, el manejo de errores o los procedimientos de parada del sistema. Estas sern conocidas al final de la fase de diseo detallado, pero existir todava una incertidumbre del 10% basada en la exactitud con la que los programadores entiendan las especificaciones que tienen que codificar.


Pg. 16


Para otros ciclos de vida como, prototipado o desarrollos en tiempo real, el proceso de estimacin sera muy similar, y en todos ellos a medida que el proyecto progresa, la base de la estimacin y las salidas esperadas de este proceso cambiarn. 2.4. Salidas del Proceso de Estimacin En esta seccin intentaremos dar respuesta a la siguiente pregunta. Qu es lo que debemos estimar? Cuando se habl de la definicin de estimacin, se vieron dos preguntas a las que este proceso deba dar respuesta. Estas preguntas eran: Cunto costar? Cunto tiempo llevar hacerlo? Esta informacin constituye la informacin bsica de todo proceso de estimacin. Los distintos mtodos existentes para realizar este proceso proporcionan informacin adicional para dar respuestas, en funcin del mtodo, a algunas de las siguientes preguntas: Cunta gente se necesita? De qu perfiles? Cules son los riesgos? Cmo afectan las restricciones impuestas a las estimaciones? Cunto esfuerzo se necesita para realizar cada fase del ciclo de vida? Cmo impacta este proceso en el resto de los proyectos de la empresa? Cul ser el esfuerzo para mantener este proyecto? Cul ser el tamao del sistema? (lneas de cdigo) Cuntos defectos tendr el producto? Cunta documentacin ser generada? Cul ser el esfuerzo para confeccionar dicha documentacin? Se podra crear una lista compuesta por todas estas preguntas, para utilizarla como base para la solucin al problema de Qu estimar? As, se observara que existen muchos conceptos en la mente de los estimadores. Sin embargo, dada la rpida evolucin de los mtodos de desarrollo de sistemas y la creciente diversificacin de alternativas hardware, es correcto suponer que esta lista aumenta constantemente. Todos estos parmetros que se pretenden obtener, son en realidad medidas sobre el producto software, es decir mtricas, de las que hablaremos en el tema siguiente.


Pg. 17


TEMA 3: MTRICAS DE SOFTWARE


Pg. 18


3.1. Definicin de Mtrica Podemos definir las Mtricas de Software o Medidas de Software como: La aplicacin continua de tcnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una informacin de gestin significativa y a tiempo. Esta informacin se utilizar para mejorar esos procesos y los productos que se obtienen de ellos. Como se puede observar, esta definicin cubre infinidad de aspectos relacionados con el desarrollo de software. Las mtricas de software implican medir: medir involucra nmeros; el uso de nmeros para hacer cosas mejor. Las mtricas de software pretenden mejorar los procesos de desarrollo del software y mejorar, por tanto, todos los aspectos de la gestin de aquellos procesos. Estas medidas son aplicables a todo el ciclo de vida del desarrollo, desde la iniciacin, cuando debemos estimar los costes, al seguimiento y control de la fiabilidad de los productos finales, y a la forma en que los productos cambian a travs del tiempo debido a la aplicacin de mejoras. Las mtricas incluyen el uso de tcnicas por parte de ingenieros de software y programadores para detectar y corregir anticipadamente los errores de los distintos componentes de los productos, antes de llegar a la codificacin. Adems las mtricas controlan el progreso del proyecto, de tal manera que lo que pueda ocurrir seis meses ms tarde se pueda identificar tan pronto como sea posible. Esencialmente, las Mtricas de Software se aplican al producto software y a los procesos mediante los que se desarrolla. El producto software debera ser visto como un objeto abstracto que evoluciona desde una definicin inicial de necesidades hasta un sistema terminado, que incluyen codificacin, fuente y objetos, as como los distintos documentos producidos durante el desarrollo. A menudo, estas medidas de los procesos de desarrollo y de los productos software son estudiadas para su utilizacin en la monitorizacin de dichos procesos. Por tanto, las medidas del software y los modelos de medida son entonces tiles para estimar y predecir costes y para medir la productividad y la calidad del producto.

3.2. reas de Aplicacin Para qu podemos utilizar las mtricas? Hay diferentes formas en las que pueden ser utilizadas las Mtricas de Software, algunas de las cuales constituyen una especialidad por si solas. La ms consolidada de las reas en el estudio de las mtricas es la correspondiente a las tcnicas de estimacin de costes y tamao. Existen distintos paquetes en el mercado que proporcionan estimacin del tamao del software a desarrollar, coste de desarrollo del sistema y duracin del proyecto de desarrollo o mejora del software.


Pg. 19


Estos paquetes estn basado en modelos de estimacin y el ms conocido es el COCOMO, desarrollado por Barry Boehm en 1981 aunque existen otros como son ESTIMACS, SOFTCOST, SPQR o COPMO, que se explicarn posteriormente. Existe una gran cantidad de investigacin sobre esta rea en EE.UU., Europa y otros lugares. Hay organizaciones especialmente interesadas en la implantacin de mtricas en el desarrollo de software, por ejemplo el Departamento de Defensa de EE.UU. El control de proyectos de desarrollo de software a travs de medidas es un rea que esta generando un gran inters tanto en Europa como en EE.UU. Este es un tema que ha alcanzado un inters relevante con el incremento de contratos a precio fijo para desarrollar un producto software y la utilizacin de clusulas de penalizacin en los mismos en caso de retrasos, sobrecostos, etc... La prediccin de los niveles de calidad del software, a menudo en trminos de fiabilidad, es otra rea en que las Mtricas de Software tienen un importante papel que jugar. El uso de las Mtricas de Software en proporcionar una verificacin cuantitativa del diseo del software es otra rea bien definida. Estas mtricas no se van a estudiar en esta Unidad sino en la Unidad de Diseo. Recientemente se ha estudiado el efecto de los factores del entorno en la eficacia de los procesos de desarrollo. Esta opcin no esta abierta para todas las organizaciones, pero existe una gran preocupacin sobre como incrementar la productividad de los procesos de desarrollo, introduciendo cambios en el entorno en el cual aquellos tienen lugar. Las medidas pueden ser utilizadas para identificar donde deberan concentrarse los cambios. La utilizacin de las Mtricas para comparar unas organizaciones con otras es un rea de aplicacin muy importante. CSC-Index en Europa y el Software Engineering Institute en EE.UU. ofrecen este tipo de servicios a la industria y muchas organizaciones los utilizan. Un resultado de esta aplicacin es que se puede identificar qu se est haciendo mal y quin lo esta haciendo bien y aprender de esas empresas. Finalmente, el uso ms comn de las medidas de software es la provisin de informacin de gestin, que incluye datos acerca de la productividad, calidad y eficacia de los procesos. El valor de esta informacin est en analizar los datos de las tendencias, da a da. Est mejorando o empeorando la calidad de un equipo de desarrollo? Si es as, por qu ocurre? qu puede hacer la direccin para mejorar la situacin? Este campo ofrece pues importantes aspectos para mejorar la calidad de los procesos de desarrollo de software. 3.3. Caractersticas de las Mtricas de Software La calidad de las medidas debera facilitar el desarrollo de modelos que sean capaces de predecir el comportamiento de determinados parmetros que afectan al desarrollo de productos o de procesos. Una medida ideal debera ser:


Pg. 20


Objetiva. Sencilla, definible con precisin para que pueda ser evaluada. Fcilmente obtenible (a un coste razonable). Valida, la mtrica debera medir exactamente lo que se quiere medir y no otra cosa. Robusta. Debera de ser relativamente insensible a cambios poco significativos en el proceso o en el producto.

Adems, para una mejor utilizacin de estas medidas, a la hora de realizar estudios analticos o anlisis estadsticos deberan de tener unos valores que se ajusten a una cierta escala de medida.

3.4. Clasificacin de las Mtricas del Software Las Mtricas de Software se pueden clasificar, de una manera general, en Mtricas de producto y Mtricas de proceso. Las Mtricas de producto son medidas del producto software durante cualquier fase de su desarrollo, desde los requisitos hasta la instalacin. Las Mtricas de producto pueden medir la complejidad del diseo, el tamao del producto final (fuente u objeto) o el nmero de pginas de documentacin producida. Las Mtricas de proceso, son medidas del proceso de desarrollo del software tales como tiempo de desarrollo total, esfuerzo en das/hombre o meses/hombre de desarrollo del producto, tipo de metodologa utilizada o nivel medio de experiencia de los programadores. Adems de esta clasificacin de las mtricas, se pueden categorizar de otras formas. Por ejemplo, por la diferencia de las propiedades objetivas y subjetivas. De una manera general las medidas objetivas deberan tener siempre un valor igual para una medida dada, cuando es medida por dos o ms observadores cualificados. Para medidas subjetivas, aun observadores cualificados pueden incluir diferentes valores para una medida dada, ya que sus juicios personales estn involucrados en la obtencin del valor medido. As por ejemplo, el tamao del producto medido en lneas de cdigo (LOC) es una medida objetiva del producto, ya que cualquier observador que trabajara con la misma definicin de LOC, debera obtener el mismo valor para un programa dado. Un ejemplo de medidas subjetivas del producto es la clasificacin del software segn el modelo de estimacin de costes de Boehm (COCOMO) en orgnico, semilibre o rgido. Para medidas de procesos, el tiempo de desarrollo es una medida objetiva y el nivel de experiencia de un programador es una medida subjetiva.


Pg. 21


Otra forma de clasificar las mtricas puede ser en mtricas primitivas o mtricas calculadas. Las mtricas primitivas son aquellas que pueden ser observadas directamente, tales como las lneas de cdigo, nmero de defectos observados en una prueba unitaria o el tiempo de desarrollo total de un proyecto. Mtricas calculadas son aquellas que no pueden ser observadas directamente sino que se obtienen a partir de otras. Ejemplos de este tipo de medidas pueden ser las utilizadas en la expresin de la productividad como lneas de cdigo producidas por una persona durante un mes o para la calidad del producto, el nmero e errores por cada mil lneas de cdigo. Las mtricas calculadas son combinaciones de otros valores de medidas y son valiosas para comprender o evaluar los procesos del software.

3.5. Mtricas de Productos Muchos de los trabajos iniciales realizados sobre las mtricas de producto estn relacionados con las caractersticas del cdigo fuente. Conforme se ha ido ganando experiencia con las mtricas y los modelos se ha puesto de manifiesto que la informacin disponible durante los primeros momentos del ciclo de desarrollo puede ser de gran valor para controlar el proceso y los resultados. Vamos a analizar, de todos los tipos de medidas utilizadas en la medicin del producto software, nicamente aquellas que nos interesen para realizar el proceso de estimacin del software, que sern las mtricas del tamao, y en cierto grado las de calidad. 3.5.1 Mtricas del Tamao Existe un cierto nmero de mtricas que intentan cuantificar el tamao del software. La mtrica ms utilizada, lneas de cdigo, tiene el inconveniente obvio de que sus valores no pueden ser medidos hasta que el proceso de codificacin ha finalizado. Los Puntos de Funcin, y los Bang de DeMarco tienen la ventaja de ser medibles durante los primeros pasos del desarrollo. El estado actual en el estudio de las medidas del tamao es: Existe un cierto consenso en cuanto a las medidas de la longitud, pero no en cuanto a las medidas de las especificaciones o diseo. Existen algunos trabajos de medicin de las funcionalidades de las especificaciones (que se aplican igualmente al diseo y a los programas) Existen muy pocos trabajos en cuanto a la medida de la complejidad del problema a resolver. Ntese que este concepto es distinto que el de complejidad computacional, por tanto el trabajo hecho en esa rea no sirve. A continuacin, vamos a analizar las medidas ms utilizadas en la determinacin del tamao del software. a) Lneas de Cdigo: La medida ms utilizada de la longitud del cdigo fuente de un programa es el Nmero de Lneas de Cdigo (Lines of Code en ingles, abreviado LOC). Sin embargo, esta mtrica puede


Pg. 22


calcularse de muchas maneras. Estas diferencias afectan al tratamiento de las lneas en blanco y las lneas de comentarios, las sentencias no ejecutables, las instrucciones mltiples por lnea y las mltiples lneas por instruccin. Adems, deberan contarse las lneas reusables de cdigo. La definicin ms comn es la siguiente: Una lnea de cdigo es cualquier lnea de un texto de un programa que no es un comentario o lnea en blanco, sin tener en cuenta el nmero de instrucciones o parte de instrucciones en la lnea. Esta definicin incluye todas las lneas que contienen cabeceras de programas, declaraciones e instrucciones ejecutables y no ejecutables. Esta medida se suele representar por NCLOC (No Comentary Lines of Code). Sin embargo, en algunos casos, por ejemplo cuando deseamos conocer qu capacidad de almacenamiento que necesitamos para el cdigo fuente o cuntas pginas vamos a imprimir, esta medida debe incluir los comentarios. Como puede verse no es una medida que refleje la longitud real de un programa. Su justificacin est en el uso que se ha hecho de ella en ciertos modelos para determinar el esfuerzo desde el punto de vista de evaluar la productividad. Sin embargo, si queremos conocer la longitud real del programa esta seria: LOC = NCLOC + CLOC donde CLOC (Comentary Lines of Code(es el nmero de lneas de comentarios. Una medida indirecta de la densidad de comentarios seria: CLOC / LOC En general, es interesante obtener ambas medidas (NCLOC Y LOC) ya que expresan diferentes conceptos. Cuando se intenta utilizar esta medida (lneas de cdigo) en trminos de productividad surgen dos problemas: a) No se tiene en cuenta el concepto de reutilizacin. b) No se tiene en cuenta el concepto de costes fijos ni instrucciones.

tareas que se desarrollan que no producen

Por ello, no debe ser utilizada esta medida directamente en la estimacin de esfuerzo o productividad. Cuando se est buscando la nocin pura de longitud existen dos alternativas aceptables si se quiere utilizar bajo el concepto de ratio: 1. Medir la longitud en trminos de nmero de bytes de almacenamiento requerido para contener el texto del programa.Pg. 23



2.

Medir la longitud en trminos de nmero de caracteres en el texto del programa. (CHAR, del ingls Character)

Si se conoce el nmero medio de caracteres por lnea de texto, NL; el nmero de lneas sera: LOC = CHAR/NL b) Especificaciones de diseo: La definicin de medidas anlogas a la de longitud para las especificaciones y los documentos de diseo no es fcil. Al comienzo del ciclo de vida, tales documentos consisten en una infinidad de texto, grafos, diagramas matemticos y smbolos. La naturaleza de aquellos depender en particular del estilo, el mtodo o la notacin utilizada. Unas especificaciones o un diseo, estn compuestos por textos o diagramas, los cuales parecen inmedibles con relacin a la longitud. Una medida que se ha utilizado para permitir las comparaciones es la del Nmero de Pginas. Sin embargo, la unidad pgina no puede ser formalmente definida si se desea incluir textos y diagramas. Si un documento de especificaciones o de diseo est compuesto de textos y diagramas donde estos ltimos tienen una sintaxis uniforme, entonces se podra representar la longitud del texto y la de los diagramas. Tambin se pueden utilizar objetos o elementos atmicos representativos para los distintos tipos de diagramas y smbolos. As, DeMarco identifica en la fase de especificaciones tres vistas del sistema con relacin a cuatro tipos de diagramas y seis elementos bsicos: Visin Funcional Diagrama Diagrama de Flujo de Datos Diccionario de Datos Diagrama E/R Diagrama de Transicin de estado Elemento Bsico Burbuja Dato elemental Objetos y relaciones Estados y transiciones

Datos Estado

Sin embargo, no existen medidas de longitud relativas a dichas funciones primitivas. Por tanto, puede decirse que, hoy por hoy, no existe una mtrica para comparar especificaciones ni diseos.

c) Prediccin de la longitud. Existen una serie de modelos que veremos mas adelante para la prediccin del coste, que dependen de la habilidad para predecir la longitud (NLOC) con exactitud en la fase de definicin de especificaciones del sistema a implantar. Un modo intuitivo de predecir la longitud es obteniendo una relacin entre la longitud de los distintos productos obtenidos durante el ciclo de vida. En particular, una prediccin de longitud, se puede obtener Ana M Moreno S.-Capuchino Pg. 24


considerando la relacin ratio de expansin entre la longitud de las especificaciones o del diseo y la longitud del cdigo en proyectos similares de los que se mantienen datos. Ha habido algunos intentos para establecer relaciones empricas entre la longitud del cdigo de programas y la longitud de la documentacin. d) Funcionalidad. El concepto de funcionalidad de un producto se origina a partir de una nocin intuitiva de la cantidad de funciones que proporciona. Ha habido dos intentos serios para medir la funcionalidad de un producto software. Uno de ellos se debe a Albrecht y corresponde a los Puntos de Funcin (FPA, del ingls Function Point Analysis)) y otro debido a DeMarco, los Bang, que no ha tenido una gran difusin. El objetivo ms importante es identificar una medida del tamao del software que pueda ser la variable predominante en los sistemas de prediccin de costes y esfuerzo, as como en la evaluacin de la productividad. Este es un objetivo encomiable, ya que una medida de la funcionalidad sera claramente preferible a la medida del tamao exclusivamente de la longitud. En ambos casos, los productos cuya funcionalidad est siendo medida son documentos de especificacin, pero que podan aplicarse posteriormente a otros productos del ciclo de vida. La funcionalidad, a pesar de los problemas existentes, es un atributo muy importante del producto y es la mejor aproximacin existente hasta la fecha. 3.5.2. Mtricas de Calidad Se puede generar una larga lista de caractersticas de la calidad del software: correccin, eficacia, portabilidad, mantenibilidad, fiabilidad, etc. Desafortunadamente, las caractersticas a veces se solapan y entran en conflicto unas con otras. Por ejemplo, incrementar la portabilidad, que es muy deseable, puede dar lugar a una eficacia menor. Aunque se han realizado una gran cantidad de trabajos en esta rea, presenta una gran variedad en los caminos seguidos frente a otras reas de investigacin de las mtricas, tales como el tamao de software o la complejidad, cuyo estudio ha sido ms uniforme. Han tenido considerable atencin tres reas: Correccin de los programas, medida como el nmero de defectos. Fiabilidad del software, calculada a partir del dato anterior. Mantenibilidad del software, que se mide a partir otro conjunto de mtricas, incluidas las de complejidad.

La calidad del software es una caracterstica que, tericamente al menos, puede ser medida en cada fase del ciclo de desarrollo del software. Estas mtricas de calidad se vern a lo largo del curso, en las Unidades de Calidad, Validacin, etc.


Pg. 25


3.6. Mtricas de Procesos Estas mtricas evalan el proceso en s de fabricacin del producto correspondiente. Ejemplos de este tipo de mtricas son el tiempo de desarrollo del producto, el esfuerzo que conlleva dicho desarrollo, el nmero y tipo de recursos empleados (personas, mquinas,...), el coste del proceso, etc. La obtencin de este tipo de mtricas est asociada generalmente a alguna tcnica de estimacin. En el siguiente tema describiremos las tcnicas bsicas de estimacin, y los mtodos que se pueden aplicar.

3.7. Conclusin Desde el punto de vista de la estimacin de software, la clasificacin ms til de mtricas es la que distingue en mtricas del producto y del proceso. De las mtricas del producto, las que realmente nos interesan son las de Nmero de Lneas de Cdigo y los Puntos de Funcin de Albrecht. La primera mtrica es interesante porque sirve de punto de partida de diversos mtodos de estimacin como el Mtodo COCOMO, que se ver en el TEMA 6 de esta Unidad llamado Mtodo de Estimacin COCOMO. La segunda, est teniendo cada vez mayor importancia en la estimacin de software, debido a que se ha demostrado en estos ltimos aos su utilidad para medir el tamao de un producto software, y tambin en gran parte, debido a la labor del IFPUG que sirve de apoyo y de soporte para todos los usuarios que apliquen la tcnica de los Puntos de Funcin. El resto de mtricas del producto se han enunciado, simplemente para que el alumno tenga conocimiento de ellas, sin necesidad de entrar ms en detalle. En cuanto a las mtricas de procesos, como se ha indicado en el apartado anterior, suelen estar con alguna tcnica de estimacin, que se estudiar en el siguiente tema.


Pg. 26


TEMA 4: TCNICAS DE ESTIMACIN


Pg. 27


4.1. Visin General Para la estimacin, existen cuatro tcnicas bsicas y comunes: 1. La opinin de los expertos; Esta tcnica se basa en la experiencia profesional de los participantes en el proyecto de estimacin. La analoga; Es una aproximacin ms formal que la experiencia de los expertos y se basa en la comparacin directa de uno o ms proyectos pasados. La estimacin inicial se ajusta dependiendo de las diferencias entre el proyecto pasado y el nuevo. La descomposicin; Consiste en la descomposicin de un producto en componentes ms pequeos, o descomponer un proyecto en tareas de nivel inferior. La estimacin se hace a partir del esfuerzo requerido para producir los componentes ms pequeos o para realizar las tareas de nivel inferior. La estimacin global del proyecto resultar de sumar las estimaciones de los componentes. Las ecuaciones de estimacin; Son frmulas matemticas que establecen la relacin de algunas medidas de entrada (que normalmente es la medida del tamao del producto) y determinan el esfuerzo que se requerir.

2.

3.

4.

La primera tcnica es un tanto informal y es la que se ha llevado a cabo hasta el momento, con no muy buenos resultados como ya hemos visto, dada la complejidad del propio proceso de estimacin. Para poder utilizar la segunda tcnica es necesario disponer de una base de datos histrica de proyectos finalizados con la que poder realizar la comparacin. Adems todos esos proyectos tendrn que haber seguido un proceso estndar. Es decir, el ciclo de vida utilizado y las actividades han de ser similares. Si no es as, es difcil hacer comparaciones proyecto-proyecto. Un proyecto puede haber comenzado siguiendo unos pasos totalmente definidos y formalizados, y otro puede que slo tenga definida formalmente la fase de codificacin y pruebas, el resto de las fases nadie sabe como se hicieron ni si se hicieron. Por lo tanto, a menos que los proyectos tengan un esquema de proceso similar, compararlos unos con otros es como comparar peras con manzanas. Es necesaria una estandarizacin para usar esta tcnica. Otro aspecto a tener en cuenta es que los datos sobre esos proyectos han de ser fiables. Esto quiere decir que las empresas correspondientes han de tener un programa formalizado para la toma de medidas sobre sus proyectos. Actualmente es difcil que las empresas cumplan estos dos requisitos: estandarizacin de procesos y formalizacin de la recogida de medidas. Hay que tener en cuenta que las empresas deberan haberlos implantado desde hace algunos aos atrs, y que en estos momentos todava existen muchas empresas que no siguen una metodologa de desarrollo y que tampoco intentan abordar la cuestin de la confeccin de un histrico de proyectos.


Pg. 28


Para aplicar la tercera tcnica hay que disponer tambin de una base de datos histrica para poder identificar el esfuerzo de las distintas actividades de bajo nivel, y sta no est normalmente definida por las razones que anteriormente hemos indicado. Por todo ello, cuando se comienza a realizar el proceso de estimacin en una organizacin se utiliza algn mtodo o modelo establecido, es decir, se emplea la cuarta tcnica. 4.2. Requisitos de un Buen Mtodo de Estimacin Un mtodo de estimacin tendr xito si: La estimacin inicial est dentro del 30% de desviacin del coste final real. El mtodo permite el refinamiento de la estimacin durante el ciclo de vida del producto software. El mtodo es fcil de usar por el estimador. Esto permite una rpida re-estimacin cuando sea necesario; por ejemplo, para evaluar distintas alternativas. Las reglas de la estimacin son entendidas por todas las personas a las que afectan los resultados de la misma. Los directivos se sienten ms seguros cuando el proceso de estimacin es fcilmente comprensible. El mtodo es soportado por herramientas y est documentado. La disponibilidad de herramientas aumenta la eficacia de cualquier mtodo. Esto es debido, principalmente, a que los resultados pueden ser obtenidos ms rpidamente y de una forma estndar.

4.3. Mtodos de Estimacin Un mtodo de estimacin eficaz permitir ignorar aspectos sin inters y concentrare en los aspectos esenciales. Un buen modelo debera poseer capacidades predictivas, mejor que ser meramente descriptivo o explicativo. La validez de las mtricas de software y de los modelos de estimacin debe ser establecida demostrando la coincidencia entre los datos empricos y los experimentales. Esto requiere una cuidadosa atencin en la toma de medidas y en el anlisis de los datos. En general, el anlisis y la validacin de las mtricas y los modelos de estimacin requieren una slida base estadstica y diseo de experimentos. Para obtener resultados significativos es necesaria una definicin precisa de las mtricas involucradas y de los procedimientos para la captura de datos. Los experimentos a pequea escala deberan ser diseados cuidadosamente, y no aleatoriamente, utilizando principios de diseo experimental. Los experimentos muy largos son muy difciles de dirigir. Es esencial poseer una base slida de estadstica para llevar a cabo experimentos significativos y analizar los datos resultantes. En general, si no se posee la base estadstica suficiente debera de solicitarse la ayuda de estadsticos para evaluar seriamente el trabajo realizado.


Pg. 29


Los modelos de estimacin existentes se pueden clasificar como Modelos Estadsticos, Modelos basados en Teoras y Modelos Compuestos. A continuacin describiremos cada uno de ellos.

4.3.1. Modelos Estadsticos C.E. Walston y P.C. Felix, de IBM utilizaron datos de 60 proyectos terminados completamente para desarrollar un modelo simple de clculo del esfuerzo de desarrollo de software. El principal determinante del esfuerzo de desarrollo fue la mtrica LOC. Se asumi una relacin de la forma: E = aLb, donde L es el nmero de lneas de cdigo, en miles y E es el esfuerzo total requerido en meses/personas. Mediante un anlisis de regresin se encontraron los valores apropiados para a y b. La ecuacin resultante fue: E = 5,2 L0,9l

La productividad nominal de programacin en LOC por persona/mes, puede ser calculada como L/E. Walston y Felix tambin intentaron desarrollar un ndice de productividad, I, que podra hacer incrementar o disminuir la productividad, dependiendo de la naturaleza del proyecto.


Pg. 30


4.3.2. Modelos basados en Teoras: Modelo de Putnam. Pocos modelos propuestos tienen una base tcnica substancial. El modelo ms importante es el de Putnam. Este modelo asume una distribucin especfica del esfuerzo a lo largo de la vida de un proyecto de desarrollo de software. El modelo se ha obtenido a partir de distribuciones de mano de obra en grandes proyectos. Sin embargo, se puede extrapolar a proyectos ms pequeos. Putnam desarroll la siguiente relacin entre el tamao del producto software y el tiempo de desarrollo: E = L3/(C3 T4) donde L = el nmero de instrucciones fuente producidas. E = el esfuerzo durante todo el ciclo de vida en aos/persona C = una constante dependiente de la tecnologa. T = el tiempo de desarrollo en aos. Los valores tpicos de C pueden ser: C = 2.000 para un entorno pobre de desarrollo de software (sin metodologa, con una documentacin y unas revisiones pobres); C = 8.000 para un buen entorno de desarrollo de software (con una buena metodologa, adecuadas documentacin y revisiones); C = 11.000 para un entorno excelente (con herramientas y tcnicas automticas). Se puede obtener la constante C correspondiente al entorno propio a partir de datos histricos recopilados sobre anteriores esfuerzos de desarrollo.

4.3.3. Modelos Compuestos Son modelos que utilizan una combinacin de intuicin, anlisis estadstico y juicio de expertos. A continuacin se describen los ms importantes.

a) Modelo COCOMO de Boehm. Es probablemente el ms conocido y slidamente documentado de todos los modelos de estimacin de costes. En el TEMA 6. Modelo de Estimacin COCOMO se estudia en profundidad este modelo, con aplicaciones prcticas.

b) SOFTCOST - Tausworthe Tausworthe, de Jet Propulsion Laboratory, intent desarrollar una estimacin de coste del software utilizando elementos de los modelos de ms xito disponibles. Este modelo requiere 68 parmetros de entrada, cuyos valores se deducen a partir de las respuestas del usuario a 47 preguntas acerca del proyecto.

c) SPQR - Capers Jones Capers Jones ha desarrollado un modelo de estimacin de costes llamado Software Productivity, Quality and Reliability (SPQR).


Pg. 31


El enfoque del problema es similar al de Boehm en su modelo COCOMO. Est basado en 20 factores que influyen razonablemente en el coste y productividad del desarrollo de software y que estn bien definidos y otros 25 factores que no estn tan bien definidos. SPQR es un producto comercial, pero no est tan bien documentado como otros modelos. Requiere responder a ms de 100 preguntas relacionadas con el proyecto para formular los parmetros de entrada necesarios en el clculo de los costes y los planes. Jones seala que con este modelo es posible proporcionar estimaciones de coste que estarn el 90% de las veces dentro del valor real con una desviacin del 15%. d) COPMO - Thebaut Thebaut propone un modelo de desarrollo de software que intenta contabilizar el esfuerzo requerido cuando los equipos de programacin estn involucrados en grandes proyectos. La ecuacin general de clculo de esfuerzo es:

E = a + bS + cPd

donde a, b, c y d son constantes para ser determinadas a partir de datos empricos mediante anlisis de regresin: S es el tamao del programa en miles de LOC P es el nivel medio de personal durante el ciclo de vida del proyecto. Desafortunadamente, este modelo requiere no uno sino dos parmetros cuyos valores no son conocidos hasta la terminacin del proyecto. Adems, las constantes b y c dependientes de la complejidad del software no son fcilmente determinables. Este modelo presenta una formula interesante, pero necesita un mayor desarrollo y ajuste para que sea de inters general.


Pg. 32


e) ESTIMACS - Rubin Rubin ha desarrollado un modelo de estimacin que utiliza especificaciones del negocio para sus clculos. El modelo proporciona estimacin del esfuerzo total, requisitos de personal, coste, riesgo y efecto sobre la cartera de proyectos. ESTIMACS ser analizado en la prctica de la asignatura.


Pg. 33


TEMA 5: MTODO DE ESTIMACIN DE PUNTOS DE FUNCIN


Pg. 34


5.1. Desarrollo de la tcnica de Puntos de Funcin Los Puntos de Funcin miden el software cualificando la funcionalidad que proporciona externamente, basndose en el diseo lgico del sistema. Por lo tanto, en el caso de subsistemas diseados independientemente los Puntos de Funcin se calcularn para cada una de ellas, y luego se sumarn. Por ejemplo, cuando un sistema que proporcione por un lado una funcionalidad on-line y por otro lado una funcionalidad batch, y por tanto, se han diseado independientemente los dos subsistemas que proporcionan cada funcionalidad. Los objetivos de los Puntos de Funcin son: Medir lo que el usuario pide y lo que el usuario recibe. Medir independientemente de la tecnologa utilizada en la implantacin del sistema. Proporcionar una mtrica de tamao que d soporte al anlisis de la calidad y la productividad. Proporcionar un medio para la estimacin del software. Proporcionar un factor de normalizacin para la comparacin de distintos software.

Adems de estos objetivos, el proceso de contabilizar los Puntos de Funcin debera ser: Suficientemente simple como para minimizar la carga de trabajo de los procesos de medida. Conciso en sus resultados.

El anlisis de los Puntos de Funcin se desarrolla considerando cinco parmetros bsicos externos del Sistema: 1. 2. 3. 4. 5. Entrada (EI, del ingls External Input). Salida (EO, del ingls External Output). Consultas (EQ, del ingls External Query). Grupos de datos lgicos internos (ILF, del ingls Internal Logic File). Grupos de datos lgicos externos (EIF, del ingls External Interface File).

Con estos parmetros, se determinan los puntos de funcin sin ajustar. A este valor, se le aplica un Factor de Ajuste obtenido en base a unas valoraciones subjetivas sobre la aplicacin y su entorno. Es decir las caractersticas generales del sistema. La aplicacin de la tcnica de los Puntos de Funcin comprende los siguientes pasos: Definicin de los lmites del sistema. Definicin de parmetros. Valoracin de la complejidad. Anlisis de las caractersticas generales del sistema.


Pg. 35


5.2. Definicin de los Lmites del Sistema El lmite es utilizado para definir el alcance del sistema y ayudar a identificar los parmetros externos. Existen tres visiones de los lmites del sistema, dependiendo de la utilizacin que quiera realizarse de la tcnica: 1 La aplicacin o lmite del producto. Abarca a la totalidad de la aplicacin y se realiza la cuenta de puntos al final del desarrollo del proyecto cuando se gestiona el grupo de mantenimiento o cuando la organizacin inicia el uso de FPA. Este tipo de cuenta puede ser tambin obtenida de un sistema en funcionamiento. 2 Lmite inicial del proyecto a desarrollar. Es un tipo de conteo similar al anterior, la diferencia est en que se deriva de los requisitos de un sistema que no existe aun. 3 Lmite del proyecto de mejora. Esta situacin surge cuando ya existe el sistema y se trata de obtener nuevas versiones del mismo. La utilizacin de FPA en proyectos de mejora difiere de las anteriores en que se consideran adiciones, modificaciones o anulaciones de funcionalidades, en lugar de la totalidad del sistema. No se puede caer en la trampa de calcular los puntos del sistema total antes y despus de las mejoras y luego substraer uno de otro. Existe un elemento subjetivo en la determinacin de los lmites del sistema y obviamente un cambio en ellos cambiar el total de Puntos de Funcin. Aunque esto podra parecer una aproximacin poco cientfica, en la prctica la orientacin que el analista debera seguir es considerar el problema como un todo discreto. La formula que permite calcular los Puntos de Funcin de un nuevo desarrollo es la siguiente: FPA = FP X AF Donde: FP es el nmero de Puntos de Funcin sin ajustar de la aplicacin AF es el Factor de Ajuste de la aplicacin El clculo de los Puntos de Funcin de un proyecto de mejora se puede obtener mediante la formula: (ADD+CHGA) * VAFA + (DEL * VAFB) = EFP donde: EFP es el nmero de Puntos de Funcin del Proyecto de Mejora.


Pg. 36


VAFB es el Factor de Ajuste de la aplicacin antes del proyecto de mejora. ADD es el nmero de Puntos de Funcin de aquellas funciones que se aadirn al proyecto como consecuencia de la mejora. CHGA es el nmero de Puntos de Funcin sin ajustar de aquellas funciones que sern modificadas por el proyecto de mejora. Este nmero refleja las funciones despus de la modificacin. DEL es el nmero de Puntos de Funcin sin aquellas funciones que sern eliminadas en el proceso de mejora. VAFA es el Factor de Ajuste de la aplicacin despus del proyecto de mejora. 5.3. Definicin de Parmetros Para poder determinar la existencia de los componentes que contribuirn al total final, hay que definirlos previamente. Estos componentes pueden ser clasificados como Tipos de Funciones y son de dos clases: Datos o Transacciones.

5.3.1. Tipos de Funcin Datos Representan la funcionalidad proporcionada a los usuarios para cumplir con sus requisitos de datos internos y externos. Son de dos tipos: Ficheros Lgicos Internos y Ficheros de Interface Externos. 5.3.1.1. Ficheros Lgicos Internos Un Fichero Lgico Interno es un grupo de datos lgicamente relacionados identificables por los usuarios o informacin de control mantenidos y utilizados dentro de los lmites de la aplicacin. Por un grupo de datos lgicamente relacionados e identificables por un usuario se entiende aquellos datos que un usuario experto podra identificar cumpliendo con un requisito especfico de la aplicacin. Correspondera al almacn de datos identificado por un nombre en un Diagrama de Flujos de Datos. El significado de almacn u Diagrama de Flujo de Datos se ver en las Unidades de Anlisis y Diseo.

Informacin de control corresponde a datos utilizados por la aplicacin cumpliendo con requisitos del negocio. Mantenidos es la habilidad para aadir, cambiar o borrar datos mediante procedimientos estandarizados a travs de la aplicacin.


Pg. 37


Las reglas para identificar estos tipos de funcin son: Regla 1 El grupo de datos o informacin de control es un grupo de datos lgico identificable por el usuario que cubre de manera completa requisitos especfico de ste El grupo de datos es mantenido dentro de los lmites de la aplicacin El grupo de datos es mantenido o modificado por medio de un proceso elemental de la aplicacin El grupo de datos identificado no se ha contado como un fichero interfase externo de la aplicacin

Regla 2 Regla 3 Regla 4

Ejemplos de ILF son: Ficheros maestros Aplicaciones de Seguridad de Datos Datos de Auditora Actualizados por la aplicacin Mensajes Help Actualizados por la aplicacin Mensajes de Error Actualizados por la aplicacin Datos de Back-up, si el usuario lo requiere Ficheros Internos Lgicos mantenidos por ms de una aplicacin

5.3.1.2. Ficheros Interfase Externos Representan un grupo de datos relacionados lgicamente identificables por el usuario o informacin de control utilizada por la aplicacin, pero mantenida por otra aplicacin. Las reglas para identificar estos tipos de funcin son:

Regla 1

Regla 2 Regla 3 Regla 4 Regla 5

El grupo de datos o informacin de control es un grupo e datos lgico identificable por el usuario que cubre de manera completa requisitos especficos de ste El grupo de datos es referenciado y es externo a la aplicacin que est siendo contada El grupo de datos no es mantenido por la aplicacin que est siendo contada El grupo de datos se ha contado como un ILF por, al menos, otra aplicacin El grupo de datos identificado no ha sido contado como un ILF para la aplicacin

5.3.2. Tipos de Funcin Transaccin Comprende tres tipos de funcin: Entradas externas (EI): mantiene datos almacenados internamente. Salidas externas (EO): datos de salida de la aplicacin.


Pg. 38


Consultas externas (EQ): Combinacin de una entrada (pregunta) y de una salida (respuesta).

Vamos a comentar brevemente cada una de ellas. 5.3.2.1. Entradas Externas Las Entradas Externas son datos o informacin de control que se introducen en la aplicacin desde fuera de sus lmites. Estos datos mantienen un Fichero Lgico Interno. La Informacin de Control est constituida por datos utilizados por un proceso dentro de los lmites de la aplicacin para asegurar el cumplimiento de los requisitos del negocio definidos por los usuarios. Esta Informacin de Control puede mantener directamente un Fichero Lgico Interno. Una Entrada Externa debera ser considerada nica si tiene un formato distinto de las dems o el diseo lgico requiere una lgica de procesamiento distinta de otra Entrada Externa del mismo formato. En otras palabras, una Entrada Externa se considera nica si los datos son mantenidos en un Fichero Lgico Interno (ILF) y el formato de entrada es nico o la lgica del proceso es nica. Para cada proceso identificado que actualiza un Fichero Lgico Interno: Hay que considerar cada formato de entrada como un proceso distinto, si los datos utilizados por el proceso pueden tener distintos formatos. Hay que sumar una unidad a cada Entrada Externa por cada actividad de mantenimiento de datos realizada (sumar, cambiar, borrar). Las reglas para identificar estos tipos de funcin son: Regla 1 Regla 2 Regla 3 Regla 4 Regla 5 Los datos se reciben desde fuera de los lmites de la aplicacin Los datos mantienen un ILF a travs de un proceso elemental de la aplicacin El proceso es la unidad ms pequea de actividad que es significativa para el negocio del usuario final El proceso es autocontenido y deja a la aplicacin que est siendo contada en un estado consistente El proceso identificado debe verificar alguna de estas dos reglas : - Su lgica de proceso es nica respecto otras entradas externas de la aplicacin. - Los elementos de datos identificados son distintos a los de las otras EIs de la aplicacin.

Ejemplos de este tipo de funcin son: Las transacciones: Datos introducidos para mantener Ficheros Lgicos Internos. Las pantallas de entrada: Hay que aadir una unidad a Entradas Externas por cada funcin que mantiene un Fichero Lgico Interno. Por ejemplo, si los datos introducidos en esa pantalla


Pg. 39


pueden aadir, cambiar y borrar informacin en un Fichero Lgico Interno, se contaran tres Entradas Externas. Las entradas por lotes: Por cada proceso nico que mantiene un Fichero Interno Lgico se debe aadir una Entrada Externa por cada adicin, modificacin o borrado de datos. Un fichero fsico de entrada, cuando se analiza lgicamente, corresponde a una Entrada Externa o varias, dependiendo de los tipos de registros contenidos y del proceso requerido para su tratamiento. As mismo dos o ms ficheros fsicos de entrada pueden corresponder a una Entrada Externa si el proceso lgico y el formato son idnticos para cada uno de los ficheros. Las entradas externas duplicadas: Si distintos procesos de entrada solicitados expresamente por el usuario duplican una Entrada Externa, son contados independientemente cada uno. Un ejemplo puede ser un ingreso en una cuenta bancaria que se puede hacer por un Cajero Automtico o a travs de una operacin normal, siendo el mismo tipo de entrada. En cambio, no son Entradas Externas: Los datos referenciados utilizados por la aplicacin pero no mantenidos como Ficheros Lgicos Internos. Las entrada de una Consulta Los generadores de Informes Las pantallas de Conexin que no mantengan un Fichero Lgico Interno.

5.3.2.2. Salidas Externas Las Salidas Externas son datos o informacin de control que sale de los lmites de la aplicacin. Esta salida debe ser considerada nica si tiene un formato nico o si el diseo lgico requiere un proceso lgico distinto de otras salidas del mismo formato. Toda salida ha de requerir un proceso de clculo de la informacin que se proporciona. Las reglas para identificar este tipo de funciones son:


Pg. 40


Regla 1 Regla 2 Regla 3 Regla 4 Regla 5

El proceso enva datos o informacin de control Los datos o informacin de control se envan a travs de un proceso elemental de la aplicacin El proceso es la unidad ms pequea de actividad que es significativa para el negocio del usuario final El proceso es autocontenido y deja a la aplicacin en un estado consistente El proceso identificado debe verificar alguna de estas dos reglas : - Su lgica de proceso es nica respecto otras salidas externas de la aplicacin - Los elementos de datos identificados son distintos a la los de otras EOs de la aplicacin

Deben considerarse Salidas Externas: La transferencia de datos a otras aplicaciones: Datos que residen en un Fichero Lgico Interno que son formateados y procesados para ser utilizados por otra aplicacin. Las salidas son identificadas basadas en los procesos requeridos para el tratamiento de los datos. Un fichero fsico de salida, cuando se analiza lgicamente, puede corresponder a varias salidas. De una manera similar, dos o ms ficheros fsicos de salida pueden corresponder a una Salida Externa si el proceso lgico y los formatos son idnticos para cada uno de ellos. Un mtodo para identificar mltiples Salidas Externas es ver cuntos tipos de registros distintos hay en el fichero.

Los mensajes de error/configuracin: No se contaran si estn asociados a una Consulta o a una Entrada. Los grficos: Cada grfico distinto, solicitado por el usuario, debera ser contado como una salida. As, si unos datos estadsticos se presentan en formato de tabla, diagrama de barras, y tarta, se contarn como 3 salidas. Los generadores de informes: Una salida desarrollada por el usuario con un generador de informes debera ser contada como una salida para cada tipo de informe especificado. Si el usuario solicita una facilidad de generacin de informes como parte de la aplicacin para ser confeccionados por l mismo, la cuenta ser la siguiente: Debera contarse una Entrada Externa por cada parmetro para la definicin de informes o comando (ej. select, compare, sort merge, calculate, format, etc.) utilizado por el usuario para controlar la generacin del informe. Debera contarse una Salida por el informe total. Debera contarse un Fichero Lgico si se crea un nuevo fichero y ste se salva.

No se deben contar como Salidas:


Pg. 41


Las ayudas Las distintas formas de invocar la misma salida lgica Los mensajes de error/confirmacin asociados con tipos de funcin distintos de Entradas Externas Por ejemplo, no se contabilizara como salida los mensajes de error/confirmacin asociados a una Consulta Externa. Los informes mltiples/valores nicos de datos: Informes idnticos con el mismo formato y la misma lgica de proceso, pero que existen debido a distintos valores de datos, no se cuentan como salidas distintas. Por ejemplo, dos informes idnticos en formato y construccin, el primero de los cuales contiene nombres comenzando desde la A a la L y el segundo desde la M a la Z se cuenta como una nica salida. Los informes Ad Hoc: Cuando el usuario dirige y es responsable de la creacin mediante la utilizacin de lenguajes como FOCUS o SQL de un nmero indefinido de informes, no se cuentan como salidas.

5.3.2.3. Consultas Externas Las consultas representan los requisitos de informacin a la aplicacin en una combinacin nica de entrada/salida que se obtiene de una bsqueda de datos, no actualiza un Fichero Lgico Interno y no contiene datos derivados. Una consulta se considera nica si tiene un formato distinto de otras consultas, ya sea en entrada o salida, o si el diseo lgico requiere ediciones distintas a las de otras consultas. Se entiende por datos derivados aqullos que requieren un proceso distinto a la bsqueda directa, edicin o clasificacin de informacin de Ficheros Lgicos Internos o Ficheros Interfases Externos. Las reglas para identificar este tipo de funcin son: Regla 1 Regla 2 Regla 3 Regla 4 Regla 5 Regla 6 Regla 7 Regla 8 Una peticin entra dentro del lmite de la aplicacin Un resultado sale del lmite de la aplicacin Hay recuperacin de datos Los datos recuperados no contiene datos derivados la peticin de entrada y el resultado de salida juntos, hacen del proceso la unidad de actividad ms pequea que es significativa para el negocio del usuario final El proceso es autocontenido y deja a la aplicacin que est siendo contada en un estado consistente El proceso no actualiza ILFs El proceso identificado debe verificar alguna de estas dos reglas : - La lgica de proceso sobre la entrada y la salida es nica respecto a otras EQs de la aplicacin - Los elementos de datos (DETs) que forman la entrada y la salida son distintos a los de las otras EQs de la aplicacin

Ejemplos de Consultas son: Ana M Moreno S.-Capuchino Pg. 42


La bsqueda inmediata de datos Las consultas no explcitas: Las pantallas de modificacin/borrado que proporcionan capacidad de bsqueda de datos antes de la funcionalidad de cambio/borrado se consideran como consultas slo si la informacin que proporcionan se muestra al usuario. Si la entrada y salida de la consulta son idnticas en las funciones de modificacin y borrado, se contar una sola consulta. Los mens con consultas implcitas: Las pantallas de men que proporcionan una seleccin de pantallas y entradas para la bsqueda de datos para la pantalla llamada, se cuenta como una Consulta. Pantallas de conexin: Las pantallas de logon que proporcionaran seguridad se cuentan como una consulta. Las ayudas: Son una consulta donde la entrada y la salida (texto) son nicas. Un texto que puede ser accedido o mostrado en pantalla mediante distintas peticiones o diferentes reas de una aplicacin se cuenta como una consulta. Se pueden distinguir dos categoras de Ayudas como son consultas tpicas: a) Ayudas a plena pantalla: Es una facilidad que proporciona una salida a pantalla como consecuencia de una llamada, tambin a travs de una pantalla. Se cuenta como una consulta de baja complejidad por aplicacin, sin tener en cuenta el nmero de pantallas devueltas. b) Ayudas por campos: Es una facilidad que se proporciona dependiendo de la posicin del cursor o algn otro mtodo de identificacin, mostrndose documentacin especifica a dicho campo. Se cuenta como una consulta de baja complejidad por aplicacin. Las salidas duplicadas: Consultas iguales que producen una salida en diferentes soportes, como consecuencia de especificaciones del usuario, se cuentan como consultas distintas. Tutoriales: Los sistemas de software relativos a la formacin de usuarios deberan contarse como un sistema distinto. No se consideran como Consultas: Los mensajes de Error/Confirmacin. La utilizacin de distintos mtodos de llamada a la misma consulta. Puede ocurrir que en una organizacin en particular surja una situacin que no est cubierta por las guas existentes para contar Puntos de Funcin. Este mtodo refleja que sta es una tcnica en evolucin. En tales casos el tcnico debe tomar la decisin de formular una regla, basada en su experiencia personal as como en la de otros. Lo ms importante es documentar la regla y aplicarla consistentemente.


Pg. 43


5.4. Valoracin de la Complejidad Para cada uno de los parmetros externos se ha de indicar su complejidad como Baja, Media o Alta. Para las entradas, salidas y consultas, se puede evaluar su complejidad en funcin del nmero de campos que contengan y del nmero de ficheros a los que hagan referencia. Para los ficheros, por el contrario, su complejidad vendr dada en funcin del nmero de registros y de campos que tengan. Valoracin de la complejidad de los tipos de funcin datos A cada ILF y EIF identificado se le asigna una complejidad funcional que es funcin del nmero de tipos de elementos datos (DETs) y el nmero de tipos de elementos registros (RETs) de los que estn compuestos, y que vienen expresada mediante las tablas de contribucin y complejidad del apndice 2. Reglas de identificacin de DETs para tipo de funcin datos Un tipo de elemento dato es un campo nico y no recursivo sobre un tipo de funcin datos y que es reconocible por el usuario. Normalmente se corresponden con los atributos de las entidades lgicas de usuario. Para que un campo sea reconocido como DET de un tipo de funcin datos, debe verificar, al menos, una de las siguientes reglas:


Contar cada campo nico y no recursivo sobre los ILFs o EIFs que sean reconocibles por el usuario Contar un DET por cada dato que exista sobre un ILF o un EIF porque el usuario requiere mantener una relacin de stos con otro ILFF (claves ajenas) Contar las siguientes tcnicas de implementacin fsica como un nico DET para el grupo completo de campos : 3.1 campo que aparecen ms de una vez en un ILF o EIF debido a la tecnologa o tcnicas de implementacin 3.2 campos repetitivos que tiene el mismo formato y que existen para permitir mltiples ocurrencias del valor de un dato

Reglas de identificacin de RETs Un tipo de elemento registro es un subgrupo de datos elementales reconocibles por el usuario dentro de un tipo de funcin datos. Los subgrupos son de dos tipos; opcionales y mandatorios. Los grupos opcionales son aquellos que usuario tiene la opcin de incluir o no mediante un proceso elemental que aada o cree una instancia dentro un tipo de funcin datos. Los grupos mandatorios son aquellos en los que el usuario debe incluir cuando se crea o aade una instancia. Para que un subgrupo de datos sea reconocido como RET debe verificar, alumnos, una de las siguientes reglas:


Pg. 44


Regla 1 Regla 2

Contar un RET por cada subgrupo opcional o mandatorio de un tipo de funcin datos Si no hay subgrupos, contar el ILF o EIF como un nico RET

Una vez identificados el nmero de RET y DET se ha de acudir a la siguiente tabla para determinar la complejidad del ILF o EIF. DET RET 1 2a5 6 o ms Baja Baja Media Baja Media Alta Media Alta Alta 1 a 19 20 a 50 51 o ms

Valoracin de la complejidad de los tipos de funcin transaccin Valoracin de la complejidad de las entradas externas A cada EI identificada se le asigna una complejidad funcional que es funcin del nmero de tipos de elementos datos (DETs) que procese el procedimiento elemental, y el nmero de tipos fichero referenciados (FTRs) a los que acceda tal proceso. Viene expresada mediante las tablas de contribucin y complejidad del apndice 2. Reglas de identificacin de DETs para entradas externas UN DET es un campo no recursivo y nico, reconocible por el usuario y mantenido sobre un ILF durante el proceso de una El. Para que un campo sea reconocido como DET de un tipo de funcin transaccin debe verificar, al menos, una de las siguientes reglas:


Contar un DET por cada campo no recursivo y nico, reconocible por el usuario y mantenido sobre un ILF durante el proceso la El Contar un DET por cada campo que no es introducido por el usuario, pero que es mantenido sobre un ILF por medio de una El Contar las siguientes tcnicas de implementacin fsica como un nico DET para el grupo completo de campos : 3.1 Un campo lgico que es almacenado fsicamente en mltiples campos, pero que es requerido por el usuario como una nica pieza de informacin 3.2 Campos que aparecen ms de una vez en un ILF debido a exigencias de implementacin o tecnologa 3.3 Campos que indican un error ocurrido durante el proceso o confirmaciones de que ste ha finalizado con xito. Todos los mensajes se cuentan como un nico DET 3.4 Contar un nico DET para la capacidad de especificar una accin que debe ser tomada para una El

Reglas de identificacin de FTRs para entradas externas


Pg. 45


Un tipo fichero referenciado es: Un fichero lgico interno ledo o mantenido por un tipo funcin transaccin Un fichero interfase externo ledo por un tipo funcin transaccin Para que un conjunto de datos sea reconocido como FTR para entradas externas, debe verificar, al menos, una de las siguientes reglas: Reglas 1 Reglas 2 Reglas 3 Contar un FTR por cada ILF mantenido durante el proceso de una El Contar un FTR por cada ILF o EIF ledo durante el proceso de una El Contar un nico FTR por cada ILF que sea tanto mantenido como ledo sobre un ILF durante el proceso de una El

Una vez identificados el nmero de FTR y DET se ha de acudir a la siguiente tabla para determinar la complejidad de la EI DET FTR 0a1 2 3 o ms Baja Baja Media Baja Media Alta Media Alta Alta 1a4 5 a 15 16 o ms

Valoracin de la complejidad de las salidas externas A cada EO identificada, asignarle una complejidad funcional basada en el nmero de tipos fichero referenciado (FTRs) por el proceso elemental de dicha EO y el nmero de tipos elemento de datos (DETs) que la forman. Viene expresada mediante las tablas de contribucin y complejidad del apndice 2. Reglas de identificacin de DETs para salidas externas UN DET es un campo no recursivo y nico, reconocible por el usuario y que aparece durante el proceso de una EO. Para que tal campo sea reconocido como DET debe verificar alguna de estas reglas: Regla 1 Regla 2 Regla 3 Regla 4 Contar un DET por cada campo no recursivo y nico, reconocible por el usuario y que aparece durante el proceso una la EO No contar literales como DETs, como ttulos de informes, pantallas o paneles de identificacin, cabeceras de columnas y ttulos de campos No contar las variables de paginado ni las marcas generadas por el sistema Contar las siguientes tcnicas de implementacin fsica como un nico DET para el grupo completo de campos : 4.1 Un campo lgico que es almacenado fsicamente en mltiples campos, pero que es requerido por el usuario como una nica pieza de informacin 4.2 Cada tipo de etiqueta y cada tipo de equivalente numrico en un grfico de salida 4.3 Informacin de texto, que puede ser una nica palabra, una sentencia o una frase Reglas de identificacin de FTRs para salidas externas


Pg. 46


Un tipo fichero referenciado es un fichero que es ledo cuando se procesa la salida externa. Para que un conjunto de datos sea reconocido como FTR para salidas externas, debe verificar la regla siguiente: Regla 1 Contar un FTR por cada ILF o EIF ledo durante el proceso de una EO

Una vez identificados el nmero de FTR y DET se ha de acudir a la siguiente tabla para determinar la complejidad de la EI DET FTR 0a1 2a3 4 o ms Baja Baja Media Baja Media Alta Media Alta Alta 1a4 5 a 19 20 o ms

Valoracin de la complejidad de las consultas externas A cada EQ que ha sido identificada, asignarle una complejidad funcional basada en el nmero de tipos fichero referenciados (FTRs) y de tipos elemento de datos (DETS) que intervienen en el proceso de la componente de entrada y de la componente de salida respectivamente. Una vez calculada ambas complejidades, escoger la ms alta entre la de la entrada y la de la salida, y tra

cocomo completo

Documents