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
80
Desarrollo
60
40 Software 20
Mantenimiento
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
Informacin
100
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.25x
Viabilidad
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
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:

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 traducirla a nmero de puntos de funcin sin ajustar segn las tablas de contribucin y complejidad del apndice 2. Reglas de identificacin de DETs para consultas externas Un DET es un campo no recursivo y reconocible por el usuario que aparece en el proceso de una EQ. Para que tal campo sea reconocido como DET de tal EQ, debe verificar alguna de estas reglas: REGLAS DE IDENTIFICACIN PARA LA ENTRADA DE LA EQ Regla 1 Regla 2 Regla 3 Contar un DET por cada campo no recursivo, reconocible por el usuario que aparezca en la parte de entrada de una consulta Contar las siguientes tcnicas de implementacin fsica como un nico DET para el grupo completo de campos : Contar las siguientes tcnicas de implementacin fsica como un nico DET para el grupo completo de campos : 3.1 Campos que indican un error ocurrido durante el proceso del DET de entrada, o confirmacin del que el proceso ha terminado de manera correcta. Todos los mensajes se cuentan como un nico DET. 3.2 Campos que especifican que la EQ debe ser procesada REGLAS DE IDENTIFICACIN PARA LA SALIDA DE LA EQ Regla 1 Regla 2 Contar un DET por cada campo no recursivo y reconocible por el usuario que aparezca en la parte de salida de una consulta No contar como DETs literales como por ejemplo, ttulos de informes, identificacin de pantallas o paneles, cabeceras de columnas, y ttulos de campos. No contar variables o marcas generadas por el sistema o marcas, como son los nmeros de pgina, informacin de posicin, comandos de paginado o campos
Regla 3
Pg. 47
de fecha y hora Contar las siguientes tcnicas de implementacin fsica como un nico DET para el grupo completo de campos : 4.1 Un campo lgico que se almacena fsicamente en mltiples campos pero que es requerido por el usuario como una unidad de informacin 4.2 Campos que aparecen ms de una vez en un ILF debido a exigencias de la tecnologa o tcnicas de implementacin Reglas de identificacin de FTRs para consultas externas Regla 4 Un tipo fichero referenciado es un fichero que es ledo cuando se procesa la consulta externa. Para que un conjunto de datos sea reconocido como FTR para consultas externas, debe verificar alguna de las reglas siguientes:
Regla 1 (ENTRADA) Reglas 2 (SALIDA)
Contar un FTR por cada ILF o EIF ledo durante el proceso de la EQ Contar un FTR por cada ILF o EIF ledo durante el proceso de la EQ
Una vez identificados el nmero de FTR y DET se ha de acudir a la siguiente tabla para determinar la complejidad de la EI Para la parte de entrada DET FTR 0a1 2 3 o ms Para la parte de salida: DET FTR 0a1 2a3 4 o ms Baja Baja Media Baja Media Alta Media Alta Alta 1a4 5 a 19 20 o ms Baja Baja Media Baja Media Alta Media Alta Alta 1a4 5 a 15 16 o ms
Una vez definida la complejidad de cada parmetro se aplica el siguiente clculo: Complejidad X Peso Total Parmetro Entrada Media Baja Salida Alta Media Alta X X 4 X X X 6 = 3 7 5 = = = =
Pg. 48
Baja Fichero Lgico Interno Alta Media Baja Alta Media Baja Alta Media Baja
X X X X X X X X X X
4 15 10 7 10 7 5 6 4 3
= = = = = = = = = =
Fichero Lgico Externo
Consultas
La suma total da los Puntos de Funcin Sin Ajustar del Sistema.
5.5. Anlisis de las caractersticas generales del sistema Una vez obtenidos el total de Puntos de Funcin sin ajustar, debe realizarse un ajuste del mismo en funcin de las caractersticas generales del sistema. Estas caractersticas son: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Comunicacin de datos. Funciones distribuidas. Rendimiento. Configuraciones fuertemente utilizadas. Frecuencia de transacciones. Entrada on-line de datos. Diseo para la eficiencia del usuario final. Actualizacin on-line. Procesos complejos. Utilizacin en otros sistemas. Facilidad de instalacin. Facilidad de operacin. Instalacin de Mltiples sitios. Facilidad de cambio.
En funcin de estas catorce caractersticas se calcula el grado de influencia, del modo que se mostrar a continuacin. Una vez calculado el grado de influencia, TDI (del ingls Total Degree of Influence), de las caractersticas, se puede llegar al valor del factor de ajuste mediante la frmula:
AF = (TDI x O.O1) + 0.65

El valor final de Puntos de Funcin ajustados ser:
FPA = FP X AF Existe un debate general sobre las caractersticas generales del sistema, ya que en gran parte su evaluacin es subjetiva, y por otro lado su valor como multiplicador es muy bajo. Sin embargo, forma parte de la tcnica y en el futuro se prev que sea uno de los aspectos ms importantes en la evolucin de la misma. Vamos a estudiar la valoracin que hace de estas caractersticas el IFPUG. Cada una de ellas se evaluar de 0 a 5, segn las guas que se indican a continuacin, el TDI se obtendr como suma de los valores de cada una de ellas. 5.5.1. Comunicacin de datos Los datos e informacin de control utilizados en la aplicacin, se reciben o son enviados a travs de medios de telecomunicacin. Los terminales conectados localmente a la unidad de control, son considerados como medios de comunicacin. Los valores utilizados son los que se muestran en la Tabla 5.1: 0 1 2 3 4 5 La aplicacin es por lotes o utilizando un ordenador personal La aplicacin es por lotes pero existe una entrada de datos o impresin remotas La aplicacin es por lotes pero son remotas la entrada de datos o la impresin. Entrada on-line de datos a un proceso por lotes o sistema de consultas. Ms de un ordenador front-end, pero la aplicacin soporta un solo tipo de protocolo de comunicaciones. Ms de un ordenador front-end, pero la aplicacin soporta mas de un tipo de protocolo de comunicaciones Tabla 5.1. Comunicacin de Datos 5.5.2. Funciones distribuidas Son caractersticas de la aplicacin que permiten la existencia de datos o procesos distribuidos dentro del lmite de la aplicacin. Los valores son los mostrados en la Tabla 5.2. 0 1 No existe este tipo de funciones en la aplicacin. La aplicacin prepara datos para que el usuario final los procese en otro componente del sistema. Por ejemplo, en una hoja electrnica en un ordenador personal.
Pg. 50
2 3 4 5
Los datos son preparados para ser transferidos. Se transfieren y procesan en otro componente del sistema, pero no por el usuario final. El proceso distribuido y la transferencia de datos son on-line y slo en una direccin. El proceso distribuido y la transferencia de datos son on-line en ambas direcciones. Los procesos se desarrollan dinmicamente en el componente ms apropiado del sistema. Tabla 5.2. Funciones Distribuidas
5.5.3. Rendimiento Los objetivos de rendimiento del sistema, definidos o aprobados por el usuario, tanto en tiempo de respuesta como en volumen de datos a procesar, se vern influenciados por el diseo, desarrollo, instalacin y soporte de la aplicacin. La Tabla 5.3. muestra la valoracin del rendimiento. 0 1 2 No existen requisitos especficos de rendimiento. Rendimiento y requisitos de diseo han sido definidos y revisados pero no requieren ninguna accin especial. El tiempo de respuesta o la capacidad de proceso es crtico durante las horas punta. No se requiere ningn diseo especial para la utilizacin de la Unidad Central de Proceso (UCP) del ordenador. Los procesos demorados se ejecutan al siguiente da. El tiempo de respuesta o la capacidad de proceso es crtico durante todas las horas de operacin. No se requiere un diseo especial para la utilizacin de la UCP. Los requisitos de rendimiento por parte de los usuarios son suficientemente estrictos como para requerir un anlisis de rendimiento en la fase de diseo. Adems, hay que utilizar herramientas para el anlisis de rendimiento durante el diseo, desarrollo y/o fase de implantacin para verificar los requisitos de rendimiento. Tabla 5.3. Rendimiento
3 4 5
5.5.4. Configuraciones fuertemente utilizadas Es una caracterstica de la aplicacin que requiere consideraciones especiales de diseo debido a las limitaciones de los equipos a utilizar. Los valores se muestran en la Tabla 5.4. 0 1 2 3 4 5 No existen restricciones de ningn tipo. Existen restricciones operativas, pero no requieren un esfuerzo especial para conseguirlas. Existen algunas restricciones de seguridad o tiempo. Existen requisitos especficos de procesador para algunas partes de la aplicacin. Las restricciones definidas en el ordenador central o procesador dedicado obligan a limitaciones en la aplicacin. Adems de las caractersticas del punto 4, existen limitaciones en los componentes distribuidos del sistema. Tabla 5.4. Configuraciones fuertemente utilizadas
Pg. 51
5.5.5. Frecuencia de transacciones La frecuencia de transacciones es alta e influye sobre el diseo, desarrollo, instalacin y soporte de la aplicacin. Los valores a asignar son los de la Tabla 5.5. 0 No existe una definicin del periodo punta de transacciones. 1 Se conoce el periodo punta (mensual, trimestral, estacional, anual). 2 Se conoce el periodo semanal. 3 Se conoce el periodo punta diario. 4 La frecuencia de transacciones definida por el usuario en los requisitos de la aplicacin o acuerdos de nivel de servicio son suficientemente altos como para requerir anlisis de rendimiento de tareas durante la fase de diseo. 5 La frecuencia de transacciones definida por el usuario en los requisitos de la aplicacin o acuerdos de nivel de servicio son suficientemente altos como para requerir el uso de anlisis de rendimiento de tareas y de herramientas de medida del rendimiento en el diseo, desarrollo y/o fase de instalacin. Tabla 5.5. Frecuencia de Transacciones 5.5.6. Entrada de datos on-line Los valores son los de la Tabla 5.6. 0 1 2 3 4 5 Todas las transacciones se procesan por lotes. 1% al 7% de las transacciones son interactivas. 8% al 15% de las transacciones son interactivas. 16% al 23% de las transacciones son interactivas. 24% al 30% de las transacciones son interactivas Ms del 30% de las transacciones son interactivas. Tabla 5.6. Entradas on-line
5.5.7. Eficiencia del usuario final Las funciones on-line proporcionadas ponen nfasis en un diseo que incremente la eficiencia del usuario final. Estas funciones pueden ser: Ayudas a la navegacin. Mens Ayudas/Documentacin on-line Movimiento automtico del cursor. Scrolling. Impresin remota. Teclas de funcin preasignadas.
Pg. 52
Emisin de trabajos por lotes a travs de transacciones on-line. Seleccin mediante cursor de datos en pantalla. Uso amplio de facilidades de vdeo. Interfase de ratn. Ventanas. Racionalizacin del uso de pantallas para realizar una funcin de negocio. Soporte de dos lenguas (Contar como 4 funciones). Soporte multi-lengua (Contar como 6 funciones).
Los valores son los de la tabla 5.7.
0 1 2 3 4
Nada de lo anterior. 1-3 de las funciones anteriores. 4-5 de las funciones anteriores. 6 o ms, pero no existen requisitos del usuario respecto a la eficiencia. 6 o ms, pero estn definidos los requisitos de eficiencia del usuario que obligan a disear tareas que tienen en cuenta factores humanos; por ejemplo, minimizar el nmero de tecleos, uso de mascaras, etc. 6 o ms, y hay requisitos del usuario sobre eficiencia que obligan a utilizar herramientas especiales y procesos para demostrar que los objetivos se han alcanzado. Tabla 5.7. Eficiencia del usuario final.
5.5.8. Actualizacin on-line La aplicacin proporciona actualizacin on-line de los Ficheros Lgicos Internos. Los valores se muestran en la Tabla 5.8. 0 1 2 3 4 5 Ninguno. Actualizacin on-line de 1 a 3 ficheros. El volumen de actualizacin es bajo y la recuperacin fcil. Actualizacin on-line de 4 ms ficheros. El volumen de actualizacin es bajo y la recuperacin es baja. Actualizacin importante de los Ficheros Lgicos Internos. Adems de la proteccin contra la perdida de datos es esencial y ha sido especialmente diseada y programada en el sistema. Adems del punto 4, los altos volmenes de transacciones requieren que sea considerado el coste de los procesos de recuperacin. Los procedimientos de recuperacin estn altamente automatizados con intervencin mnima del operador. Tabla 5.8. Actualizacin on-line 5.5.9. Procesos complejos
Pg. 53
Es una caracterstica de la aplicacin. Las categoras existentes son: Controles especiales (procesos de auditora) y/o aplicaciones de seguridad. Proceso lgico complejo. Procesos matemticos complejos. Excesivas excepciones de proceso dando lugar a transacciones incompletas que deben ser procesadas de nuevo; por ejemplo, transacciones incompletas en cajeros automticos, falta de datos obligatorios, etc. Manejo de dispositivos complejos; por ejemplo, multi-media, independencia de dispositivos, etc. Los valores son los de la Tabla 5.9. 0 1 2 3 4 5 Nada de lo anterior. Uno de los anteriores. Dos de los anteriores. Tres de los anteriores. Cuatro de los anteriores. Todos los anteriores. Tabla 5.9. Procesos Complejos 5.5.10. Reutilizacin La aplicacin y el cdigo han sido diseados especficamente, desarrollados y soportados para ser utilizados en otras aplicaciones. Los valores aparecen en la Tabla 5.10. 0 1 2 3 4 5 No reusable. Se utiliza cdigo reusable dentro de la aplicacin. Menos del 10% de la aplicacin tiene en cuenta las necesidades de ms de un usuario. El 10% ms de la aplicacin tiene en cuenta las necesidades de ms de un usuario. La aplicacin fue empaquetada expresamente y/o documentada para ser fcilmente reusable. La aplicacin es adaptada por el usuario a nivel de cdigo fuente. La aplicacin fue empaquetada expresamente y/o documentada para ser fcilmente reusable. La aplicacin es adaptada por el usuario por medio de parmetros de mantenimiento. Tabla 5.10. Reutilizacin 5.5.11. Facilidad de instalacin La facilidad de conversin e instalacin son caractersticas de la aplicacin. Durante la fase de pruebas del sistema se proporcionarn y probarn un plan de conversin e instalacin as como herramientas para la conversin. Los valores son los de la Tabla 5.11.
Pg. 54
No se realizaron consideraciones ni se requirieron desarrollos especiales para la instalacin por parte del usuario. No se realizaron consideraciones especiales por el usuario pero se requirieron desarrollos especiales instalacin. Los requisitos de conversin e instalacin fueron definidos por el usuario y las guas para la conversin e instalacin fueron desarrolladas y probadas. El impacto de la conversin en el proyecto no se considera importante. Los requisitos de conversin e instalacin fueron definidos por el usuario y las guas para la conversin e instalacin fueron proporcionadas y probadas. Adems del punto 2, se proporcionaran y probaran la conversin automtica y herramientas para la instalacin. Adems del punto 3, se proporcionaran y probaran la revisin automtica y las herramientas para la instalacin. Tabla 5.11. Facilidad de instalacin
1 2
3 4 5
5.5.12. Facilidad de operacin La facilidad de operacin es una caracterstica de la aplicacin. Se proporcionarn y probarn durante la fase de pruebas del sistema, un arranque eficaz, procedimientos de respaldo y recuperacin. La aplicacin minimiza la necesidad de actividades manuales tales como montaje de cintas, manejo de papel o intervencin manual durante la operacin del sistema. Los valores aparecen en la Tabla 5.12. 0 1-4 No se definieron por parte del usuario necesidades especiales de operacin o respaldo de distintas de las normales. Seleccionar, valorando como uno, cada una de las siguientes solicitudes realizadas a la aplicacin: Procesos eficaces de arranque, respaldo y recuperacin pero con intervencin del operador. (Contar como 2) La aplicacin minimiza la necesidad de montajes de cintas. La aplicacin minimiza la necesidad de manejo de papel. La aplicacin debe disearse sin intervencin de operadores; es decir el operador no debe intervenir ms que para arrancar y parar la aplicacin. Uno de los elementos de la aplicacin es la recuperacin automtica de errores. Tabla 5.12. Facilidad de operacin 5.5.13. Instalacin en distintos lugares La aplicacin se disear y desarrollar para ser instalada y mantenida en distintos lugares por distintas organizaciones. Los valores los que se muestran en la Tabla 5.13. 0 No existen requisitos del usuario para considerar la necesidad de ms de un usuario lugar
Pg. 55
1 2 3 4
de instalacin. Se necesita disear la aplicacin para ser utilizada en mltiples lugares pero funcionar bajo entornos idnticos de hardware y software. Se necesita disear la aplicacin para ser utilizada en mltiples lugares y funcionar bajo un entorno de hardware y software similares. Se necesita disear la aplicacin para ser utilizada en distintos lugares y funcionar bajo entornos distintos de hardware y software. Debern ser proporcionados y probados la documentacin y los planes de soporte de la aplicacin para ser utilizados en distintos lugares, en el modo que se indic en los apartados (1) y (2). Debern ser proporcionados y probados la documentacin y los planes de soporte de la aplicacin para ser utilizada en distintos lugares, en el modo que se indic en el apartado (3). Tabla 5.13. Instalacin en distintos lugares
5.5.14. Facilidad de cambios La aplicacin debe ser especficamente diseada, desarrollada y mantenida para facilitar el cambio. Los siguientes son ejemplos de facilidades de cambios: Capacidad para proporcionar flexibilidad en las consultas y obtencin de informes. Los datos de la aplicacin relativos al negocio se mantienen en tablas por parte de los usuarios. Los valores son: 0 No existe ninguna especificacin por parte de los usuarios en este sentido. 1-5 Se seleccionar alguna de estas opciones: Facilidad para realizar consultas o informes simples tales como la utilizacin de operadores lgicos AND/OR sobre un Fichero Lgico Interno (se contar como 1). Facilidad para realizar consultas o informes de complejidad media tales como la utilizacin de operadores lgicos AND/OR sobre mas de un Fichero Lgico Interno (se contara como 2). Facilidad para realizar consultas/informes complejos. (Se contaran como 3). Se mantendrn datos de control en tablas que sern mantenidas por los usuarios a travs de procesos interactivos on-line, pero los cambios no sern efectivos hasta el siguiente da de funcionamiento de la aplicacin. (Se contar como 1) Igual que el caso anterior, pero los cambios sern efectivos inmediatamente (se contar como 2). Para usar eficientemente los Puntos de Funcin, se emplean unos ratios relativos a las siguientes mtricas: Productividad; Indica el nmero de Puntos de Funcin que puede desarrollar una persona en un mes. Calidad; Indica el nmero de errores que supuestamente se cometern por Punto de Funcin. Coste; Indica las pesetas que costar a la empresa el desarrollo de un Punto de Funcin.
Pg. 56
Documentacin; Indica el nmero de pginas de documentacin que se generar por Punto de Funcin. Lneas de Cdigo; Indica el nmero de lneas de un determinado lenguaje de Programacin, que se escribirn por Punto de Funcin.
Estos ratios vendrn medidos en: Productividad Calidad Coste Documentacin Lneas de Cdigo = puntos funcin/persona-mes = errores/punto funcin = pesetas/punto funcin = pginas/punto funcin = lneas/punto funcin
La clave de la utilizacin de esta tcnica radica en la obtencin de estos ratios, que sern especficos de cada organizacin, y que nos darn informacin sobre el tamao de la aplicacin. Estos ratios se obtendrn de proyectos anteriores que se hayan desarrollado en la organizacin.
Pg. 57
TEMA 6: COCOMO II
Pg. 58
7.1. Antecedentes de COCOMO II. 7.1.1. Qu es COCOMO II? 7.1.1.1. Introduccin. El modelo original COCOMO se pblico por primera vez en 1981 por Barry Boehm y reflejaba las prcticas en desarrollo de software de aquel momento. En la dcada y media siguiente las tcnicas de desarrollo software cambiaron drsticamente. Estos cambios incluyen el gasto de tanto esfuerzo en disear y gestionar el proceso de desarrollo software como en la creacin del producto software, un giro total desde los mainframe que trabajan con procesos batch nocturnos hacia los sistemas en tiempo real y un nfasis creciente en la reutilizacin de software ya existente y en la construccin de nuevos sistemas que utilizan componentes software a medida. Estos y otros cambios hicieron que la aplicacin del modelo COCOMO original empezara a resultar problemtica. La solucin al problema era reinventar el modelo para aplicarlo a los 90. Despus de muchos aos de esfuerzo combinado entre USC-CSE1, IRUS y UC Irvine22 y las Organizaciones Afiliadas al Proyecto COCOMO II, el resultado es COCOMO II, un modelo de estimacin de coste que refleja los cambios en la prctica de desarrollo de software profesional que ha surgido a partir de los aos 70. Este nuevo y mejorado COCOMO resultar de gran ayuda para los estimadores profesionales de coste software. Por tanto, COCOMO II es un modelo que permite estimar el coste, esfuerzo y tiempo cuando se planifica una nueva actividad de desarrollo software. Est asociado a los ciclos de vida modernos. El modelo original COCOMO ha tenido mucho xito pero no puede emplearse con las prcticas de desarrollo software ms recientes tan bien como con las prcticas tradicionales. COCOMO II apunta hacia los proyectos software de los 90 y de la primera dcada del 2000, y continuar evolucionando durante los prximos aos. En resumen, los objetivos a la hora de la creacin del modelo COCOMO II fueron:
Desarrollar un modelo de estimacin de tiempo y de coste del software de acuerdo con los ciclos de vida utilizados en los 90 y en la primera dcada del 2000. Desarrollar bases de datos con costes de software y herramientas de soporte para la mejora continua del modelo. Proporcionar un marco analtico cuantitativo y un conjunto de herramientas y tcnicas para la evaluacin de los efectos de la mejora tecnolgica del software en costes y tiempo del ciclo de vida software.
Estos objetivos apoyan las necesidades primarias expresadas por los usuarios de la estimacin de costes del software. En orden de prioridades, estas necesidades eran: el apoyo de la planificacin de proyectos, la previsin de personal del proyecto, la preparacin del proyecto, la replanificacin, el seguimiento del
Universidad del sur de California. Centro para la Ingeniera del Software Unidad de investigacin de software Irvine. Universidad Irvine de California
Pg. 59
proyecto, la negociacin del contrato, la evaluacin de la propuesta, la nivelacin de recursos, exploracin de conceptos, la evaluacin del diseo y decisiones referentes a la oferta/demanda. Para cada una de estas necesidades COCOMO II proporcionar un apoyo ms moderno que sus predecesores, el COCOMO original y Ada COCOMO. Los cuatro elementos principales de la estrategia que ha seguido COCOMO II son:
Preservar la apertura del COCOMO original. Desarrollar COCOMO II de forma que sea compatible con el futuro mercado del software Ajustar las entradas y salidas de los submodelos de COCOMO II al nivel de informacin disponible. Permitir que los submodelos de COCOMO II se ajusten a las estrategias de proceso particulares de cada proyecto.
COCOMO II sigue los principios de apertura usados en el COCOMO original. De esta manera todos sus algoritmos y relaciones estn disponibles pblicamente. Tambin todos sus interfaces estn diseadas para ser pblicas, bien definidas y parametrizadas para que los preprocesos complementarios (modelos de analoga basados en casos de otras medidas de estimacin), postprocesos (planificacin de proyectos y herramientas de control, modelos dinmicos de proyectos, analizadores de riesgo) y paquetes de alto nivel (paquetes de gestin de proyectos, ayudas de negociacin de producto) puedan combinarse estrechamente con COCOMO II. Para apoyar a los distintos sectores del mercado software, COCOMO II proporciona una familia de modelos de estimacin de coste software cada vez ms detallado y tiene en cuenta las necesidades de cada sector y el tipo de informacin disponible para sostener la estimacin del coste software. Esta familia de modelos est compuesta por tres submodelos cada uno de los cuales ofrece mayor fidelidad a medida que uno avanza en la planificacin del proyecto y en el proceso de diseo. Estos tres submodelos se denominan:
El modelo de Composicin de Aplicaciones. Indicado para proyectos construidos con herramientas modernas de construccin de interfaces grficos para usuario. El modelo de Diseo anticipado. Este modelo puede utilizarse para obtener estimaciones aproximadas del coste de un proyecto antes de que est determinada por completo su arquitectura. Utiliza un pequeo conjunto de drivers de coste nuevo y nuevas ecuaciones de estimacin. Est basado en Punto de Funcin sin ajustar o KSLOC (Miles de Lneas de Cdigo Fuente). El modelo Post-Arquitectura. Este es el modelo COCOMO II ms detallado. Se utiliza una vez que se ha desarrollado por completo la arquitectura del proyecto. Tiene nuevos drivers de coste, nuevas reglas para el recuento de lneas y nuevas ecuaciones.
La primera implementacin de COCOMO II se present al pblico general a mediados de 1997. USC COCOMOII.1997 se calibr con 83 puntos de datos (proyectos de desarrollo software histricos), utilizando un enfoque de media ponderada del 10% para combinar datos empricos con la opinin del experto y calibrar
los parmetros del modelo. USC COCOMOII.1998.0 beta se cre en Octubre de 1998. Esta versin se calibr con 161 puntos de datos y utilizando por primera vez un enfoque bayesiano para realizar la calibracin del modelo. USC COCOMO II.1999.0 se ha publicado a mediados de 1999 y USC-COCOMO II.2000.0 ser presentado en el ao 2000. Mientras cada versin nueva de la herramienta USC COCOMO II fue mejorando en cuanto a amigabilidad con el usuario, las calibraciones del modelo de los aos 1998, 1999 y 2000 son la misma. Es decir, no se han aadido nuevos puntos de datos a la base de datos utilizada para calibrar las versiones de la herramienta del ao 1999 y del ao 2000 aparte de aquellos que aparecieron en la calibracin de la base de datos del ao 1998. En las tres implementaciones aparecen los mismos 161 puntos de datos a los que hacamos referencia anteriormente Se prev que la versin USC-COCOMO II.2001.0 ya incluir una nueva calibracin. Por ltimo, la experiencia ha demostrado que si una organizacin calibra la constante multiplicativa en COCOMO II para sus propios datos empricos, la precisin del modelo puede aumentar significativamente por encima de los resultados de calibracin genricos obtenidos con las versiones mencionadas anteriormente. 7.1.2. Predecesores de COCOMO II. 7.1.2.1. Evolucin de COCOMO 81 a COCOMO II y comparativa con sus predecesores.
Es importante recalcar los cambios experimentados por COCOMO II con respecto a COCOMO 81 ya que reflejan cmo ha madurado la tecnologa de la Ingeniera del software durante las dos dcadas pasadas. Por ejemplo, cuando se public el primer modelo COCOMO 81 los programadores estaban sometidos a tareas batch. El giro total que se experiment afect a su productividad. Por lo tanto un parmetro como TURN que reflejaba la espera media de un programador para recibir de vuelta su trabajo ahora no tiene sentido porque la mayora de los programadores tienen acceso instantneo a los recursos computacionales a travs de su estacin de trabajo. Este parmetro ha desaparecido en el nuevo modelo. Las tablas 7.1 y 7.2 recalcan los principales cambios hechos a la versin original COCOMO 81 cuando se desarroll COCOMO II y un resumen de las principales diferencias entre ambos. La tabla 7.2 presenta una comparativa por modelos ms detallada de COCOMO II y adems incluye el modelo AdaCOCOMO. De ambas tablas podemos deducir:
COCOMO II se dirige a las siguientes tres fases del ciclo de vida en espiral: desarrollo de aplicaciones, diseo anticipado y Post-Arquitectura. Los tres modos del exponente se han reemplazado por cinco factores de escala. Se han aadido los siguientes drivers de coste a COCOMO II: DOCU, RUSE, PVOL, PEXP, LTEX, PCON y SITE. Se han eliminado los siguientes drivers de coste del modelo original: VIRT, TURN, VEXP, LEXP, Y MODP. Los valores de aquellos drivers de coste que se han conservado del modelo original fueron modificados considerablemente para reflejar las calibraciones actualizadas.
Pg. 61
Las otras diferencias principales se refieren a efectos relacionados con el tamao, que incluyen reutilizacin, reingeniera y cambios en efectos de escala.
Pg. 62
ESTRUCTURA DEL MODELO FORMA MATEMTICA DE LA ECUACIN DEL ESFUERZO EXPONENTE
COCOMO II Tres modelos que asumen que se progresa Un modelo nico que asume que se ha a lo largo de un desarrollo de tipo espiral comenzado con unos requisitos asignados para consolidar los requisitos y la para el software arquitectura, y reducir el riesgo. Esfuerzo = A (cI) (SIZE)Exponenente Esfuerzo = A (cI) (SIZE)Exponenente Constante fija seleccionada como una Variable establecida en funcin de una funcin de modo: medida de cinco factores de escala: Orgnico = 1.05 PREC Precedencia Semi-libre = 1.12 FLEX Flexibilidad de desarrollo Rgido = 1.20 RESL Resolucin de Arquitectura / Riesgos TEAM Cohesin del equipo PMAT Madurez del proceso Lneas de cdigo fuente (con extensiones Puntos objeto, Puntos de funcin lneas para puntos de funcin) de cdigo fuente. 15 drivers, cada uno de los cuales debe ser 17 drivers, cada uno de los cuales debe ser estimado: estimado: RELY Fiabilidad RELY Fiabilidad DATA Tamao Base de datos DATA Tamao Base de datos CPLX Complejidad CPLX Complejidad RUSE Reutilizacin requerida TIME Restriccin tiempo de ejecucin DOCU Documentacin STOR Restriccin de TIME Restriccin tiempo de almacenamiento principal ejecucin VIRT Volatilidad mquina virtual STOR Restriccin de almacenamiento principal TURN Tiempo de respuesta PVOL Volatilidad plataforma ACAP Capacidad del analista PCAP Capacidad programador ACAP Capacidad del analista AEXP Experiencia aplicaciones PCAP Capacidad programador VEXP Experiencia mquina virtual AEXP Experiencia aplicaciones LEXP Experiencia lenguaje PEXP Experiencia plataforma TOOL Uso de herramientas LTEX Experiencia lenguaje y software herramienta MODP Uso de Tcnicas modernas PCON Continuidad del personal de programacin TOOL Uso de herramientas SCED Planificacin requerida software SITE Desarrollo Multi-lugar SCED Planificacin requerida Modelo basado en: Tiene muchas otras mejoras que incluyen: Frmula de reutilizacin lineal Frmula de reutilizacin No-lineal Asuncin de requisitos Modelo de reutilizacin que razonablemente estables considera esfuerzo necesario para entender y asimilar Medidas de rotura que se usan para abordar la volatilidad de requisitos Caractersticas de autocalibracin
COCOMO 81
MEDIDA DRIVERS DE COSTE (ci)
OTRAS DIFERENCIAS DEL MODELO
Tabla 7.1. Comparativa entre COCOMO 81 Y COCOMO II
Pg. 63
7.1.2.2. COMPARATIVA CON SUS PREDECESORES
COCOMO II COCOMO 81 MEDIDA Instrucciones fuente entregadas (DSI) Lneas de Cdigo fuente (SLOC) REUTILIZACIN SLOC Equivalente= lineal f(DM,CM,IM) SLOC Equivalente= lineal f(DM,CM,IM) Implcito en el modelo DSI SLOC AdaCOCOMO Modelo Composicin de aplicaciones Puntos Objeto
COCOMO II Modelo Diseo Anticipado Puntos de funcin (FP) y lenguaje SLOC %reutilizacin %reutilizacin sin modificar: no SR lineal
COCOMO II Modelo Post-Arquitectura Puntos de funcin (FP) y lenguaje SLOC SLOC equivalente= no lineal
modificada:
f(AA,SU,DM,CM,IM)
f(AA,SU,DM,CM,IM) ROTURA Medida de Volatilidad de los requisitos (RVOL) MANTENIMIENTO Trfico anual de cambio (ACT) ACT Modelo de reutilizacin de Puntos Objeto Modelo de reutilizacin Modelo de reutilizacin Medida RVOL Implcito en el modelo Rotura % (BRAK) Rotura % (BRAK)
=%aadido + %modificado Factor B en MNnom== A (Size)B Orgnico = 1.05 Semi-libre = 1.12 Rgido = 1.20 Rgido: 1.04-1.24 dependiendo del grado de : Eliminacin anticipada del riesgo Arquitectura slida Requisitos estables Madurez del proceso Ada 1.0 1.01-1.21 dependiendo del grado de: Precedencia Conformidad Arquitectura resolucin de riesgos. Cohesin del equipo Madurez del proceso DRIVERS DE COSTE DE PRODUCTO RELY, DATA, CPLX RELY*, DATA*, CPLX* RUSE DRIVERS DE COSTE DE LA TIME, STOR, VIRT, TURN TIME, STOR, VMVH, VMVT, TURN Ninguno Dificultad de la plataforma: PDIF*T ACAP, AEXP, PCAP, VEXP, LEXP ACAP*, AEXP, PCAP*, VEXP, LEXP* Ninguno Capacidad y experiencia del personal: PERS*T, PREX*T DRIVERS DE COSTE DEL PROYECTO MODP, TOOL, SCED MODP*, TOOL*, SCED, SECU Ninguno SCED*T, FCIL*T ACAP*, AEXPT, PCAP*, PEXP*T, LTEX*T, PCON*T TOOL*T, SCED, SITE*T TIME, STOR, PVOL(=VIRT) Ninguno RCPX*T, RUSE*T anticipada, 1.01-1.21 dependiendo del grado de: Precedencia Conformidad Arquitectura resolucin de riesgos. Cohesin del equipo Madurez del proceso RELY, DATA, DOCU*T,, CPLX*T, RUSE*T anticipada,
PLATAFORMA DRIVERS DE COSTE DEL PERSONAL
Tabla 7.2. Comparativa entre COCOMO II y sus predecesores.

* Multiplicadores diferentes
T
Medida de escala diferente
Pag. 64
7.2. CONTEXTO DE UTILIZACIN DE LOS MODELOS DE COSTE DE COCOMO II. 7.2.1. SITUACIN DEL SW EN EL MERCADO FUTURO
Nos estamos convirtiendo en una compaa de software, es una frase cada vez ms repetida en organizaciones tan diversas como las finanzas, transporte, aeroespacial, electrnica y las empresas industriales. La ventaja competitiva depende cada vez ms del desarrollo de productos inteligentes y a medida, y de la habilidad de desarrollar y adaptar ms rpidamente que los competidores estos productos y servicios. La notable reduccin de los costes del hardware y la comodidad de las soluciones software han influido indirectamente en los costes del desarrollo de sistemas. Esta situacin hace que sean an ms importantes los clculos coste-beneficio, la seleccin de los componentes adecuados para la construccin y evolucin del ciclo de vida de un sistema y el convencimiento de la escptica direccin financiera de la ventaja comercial de las inversiones en software. Tambin resalta la necesidad de productos coexistentes, la determinacin del proceso y la habilidad de dirigir anlisis trazados entre el software y los costes del ciclo de vida del sistema, tiempos de ciclo, funciones y calidades. Al mismo tiempo, una nueva generacin de procesos software y productos estn cambiando la manera en que las organizaciones desarrollan software: Enfoque evolutivo, riesgo controlado, procesos software colaborativos, enfoque de desarrollo software de trayectoria rpida, lenguajes de 4 generacin, enfoque dirigido a la reutilizacin software. Todas estas prcticas mejoran la calidad del software y reducen el riesgo, el coste y el tiempo de ciclo. Sin embargo, aunque alguno de los ya existentes modelos de coste tiene iniciativas que se dirigen a aspectos de estos problemas, estos nuevos acercamientos no se han emparejado lo suficiente a los nuevos modelos complementarios para estimacin de software y planificacin. Esto dificulta a las organizaciones la realizacin de planes efectivos, anlisis y control de proyectos usando los nuevos enfoques. Estas preocupaciones han llevado a la formulacin de una nueva versin del modelo de coste constructivo COCOMO para la estimacin del esfuerzo, del tiempo y del coste software. El COCOMO original y su especializado sucesor Ada COCOMO fueron razonablemente bien equiparados con los tipos de proyectos software que ellos modelizaban: Gran extensin de clientes, software construido para la especificacin. Aunque Ada COCOMO aadi la capacidad de estimar costes y tiempos para el desarrollo incremental de software, COCOMO encontr una creciente dificultad para estimar los costes de software comercial, de software orientado a objetos, de software desarrollado mediante modelos en espiral modelos de desarrollo evolutivo, de software desarrollado en gran parte mediante utilidades de composicin de aplicaciones comerciales a medida. La figura 7.1 resume el modelo de mercado de las futuras prcticas de software que usamos para guiar el desarrollo de COCOMO II. Incluye en la plataforma superior un sector dedicado a la programacin para usuarios finales a la que pertenecern alrededor de 55 millones de personas en Estados Unidos cerca del ao 2005. A un nivel ms bajo, un sector de infraestructura, al que pertenecern aproximadamente 0.75 millones
Ana M Moreno S.-Capuchino Pg. 65 .
de personas y 3 sectores intermedios que incluyen el desarrollo de generadores de aplicaciones y ayudas para la composicin (0.6 millones), desarrollo de sistemas mediante la composicin de aplicaciones (0.7 millones) y sistemas de integracin a gran escala y/o sistemas de software embebidos (0.7 millones).
Programacin de usuario final (55,000,000)
Generador de Aplicaciones y Ayudas a la Composicin (600,000)
Composicin de Aplicacin (700,000)
Integracin de Sistema (700,000)
Infraestructura (750,000)
Figura 7.1. Modelo de mercado de futuras prcticas de software.
La programacin para usuarios finales estar dirigida por la creciente capacidad de la computadora de leer y escribir y por la presin competitiva para la creacin de soluciones de proceso de informacin rpidas, flexibles y manejables por el usuario. Estas tendencias empujarn al mercado del software a tener usuarios que desarrollen ellos mismos la mayora de aplicaciones que procesan informacin mediante generadores de aplicaciones. Algunos ejemplos de generadores de aplicaciones son las hojas de clculo, los sistemas de querys extendidas y los sistemas de inventarios de planificacin especializados. Ellos facilitarn el que los usuarios sean capaces de determinar la aplicacin que procese la informacin que ellos deseen mediante la opcin de dominios familiares reglas simples. Cada empresa de las compaas Fortune100 para pequeos negocios y el departamento de defensa de Estados Unidos estarn involucrados en este sector. Los productos tpicos del sector de la infraestructura estarn en las reas de Sistemas Operativos, Sistemas gestores de bases de datos, Sistemas de gestin de interfaz con el usuario y Sistemas de redes. Cada vez ms, el sector de la infraestructura se dirigir hacia soluciones middleware para problemas genricos tales como el proceso distribuido y el proceso transaccional. Empresas representativas del sector de la infraestructura son Microsoft, NeXT, Oracle, SyBase, Novell y los principales vendedores de computadoras. En contraste con los programadores para usuarios finales que suelen conocer bien el dominio de sus aplicaciones y relativamente poca informtica, los desarrolladores de infraestructura saben mucho de informtica y relativamente poco de aplicaciones. La lnea de sus productos tendr muchos componentes reutilizables pero el avance de la tecnologa (nuevos procesadores, memoria, comunicaciones, displays y tecnologa multimedia) les exigir que construyan muchos componentes y utilidades desde el principio.
Pg. 66 .
Las personas que pertenecen a los tres sectores intermedios de la figura 5.2, necesitarn conocer una buena parte de informtica y de software especializado para infraestructura, y tambin uno ms dominios de aplicacin. Esto supondr un gran reto. El sector de los Generadores de Aplicaciones crear numerosos paquetes de utilidades para la programacin de usuarios. Firmas tpicas que operan en este sector son Microsoft, Lotus, Novell, Borland y vendedores de sistemas para la ingeniera, la manufacturacin y la planificacin asistida por ordenador. Su lnea de productos tendr muchos componentes reutilizables, pero requerir en gran parte el desarrollo de utilidades a partir de cero. El sector de la Composicin de aplicaciones trata con aplicaciones demasiado diversificadas como para ser utilizadas en soluciones empaquetadas, pero que son lo suficientemente sencillas como para ser rpidamente compuestas a partir de componentes interoperables. Componentes tpicos sern Desarrolladores de interfaces grficos para usuarios, Bases de datos Gestores de objetos, middleware para procesos distribuidos procesos transaccionales, manejadores hipermedia, Buscadores de datos sencillos y Componentes de dominio especfico tales como paquetes de procesos de control mdico, financiero industriales. La mayora de las grandes empresas tendrn grupos para la creacin de aplicaciones como estas pero muchas de las empresas especializadas en software se comprometern a proporcionar aplicaciones compuestas. Dichas empresas van desde las grandes y verstiles como Andersen Consulting y EDP hasta pequeas empresas especializadas en reas tales como el soporte a la decisin proceso transaccional, en dominios de aplicaciones tales como las finanzas la manufacturacin. El sector de la Integracin de sistemas trata con sistemas a gran escala, altamente embebidos sistemas sin precedentes. Parte de estos sistemas pueden desarrollarse utilizando utilidades de composicin de aplicaciones, pero su demanda requiere una significativa cantidad de sistemas de ingeniera up-front y de desarrollo tradicional de software. Las empresas aeroespaciales trabajan dentro de este sector, as como empresas de integracin de sistemas especializados tales como EDS y Andersen Consulting, importantes empresas en desarrollo de productos software-intensivos y servicios, empresas de telecomunicaciones, automocin, finanzas y productos electrnicos, y empresas que desarrollan sistemas de informacin corporativa a gran escala sistemas de soporte a la fabricacin. 7.2.2. COCOMO II. MODELOS PARA LOS SECTORES DEL MERCADO DEL SW.
Pg. 67 .
Programacin de usuario final Generador de Aplicaciones y Ayudas a la Composicin Infraestructura Composicin de Aplicacin Integracin de Sistema
Figura 7.2. Modelo de mercado de futuras prcticas de software
El sector de la programacin de usuarios finales de la figura 7.2 no necesita un modelo COCOMO II. El desarrollo de sus aplicaciones lleva de das a horas, as pues, una estimacin simple basada en actividad, ser suficiente.
Figura 7.3.
Modelo de mercado de futuras prcticas de software
El modelo COCOMO II para el sector de la composicin de aplicaciones (figura 7.3) est basado en Puntos Objeto. Los Puntos Objeto son un conjunto de pantallas, informes y mdulos de lenguajes de 3 generacin desarrollados en la aplicacin, cada uno ponderado mediante un factor de complejidad de tres niveles (simple, medio y complejo). Esto se corresponde con el nivel de informacin que normalmente se conoce de un producto de Composicin de aplicaciones durante sus fases de planificacin y el nivel correspondiente de exactitud que se necesita para estimar el coste software (dichas aplicaciones se desarrollan usualmente por un equipo pequeo en semanas meses).
Pg. 68 .
Figura 7.4.
Modelo de mercado de futuras prcticas de software
La capacidad de COCOMO II para la estimacin del desarrollo de un Generador de Aplicacin, Integracin de un Sistema Infraestructura (figura 7.4) est basada en una mezcla hecha a medida del modelo de Composicin de Aplicaciones (para tiempos de prototipados tempranos anticipados) y dos modelos de estimacin cada vez ms detallados para porciones del ciclo de vida, Diseo Anticipado y Post-Arquitectura. Con respecto a la estrategia de proceso, los proyectos de Generador de Aplicaciones, Integracin de Software e Infraestructura involucrarn a una mezcla de los tres principales Modelos de proceso. Los drivers apropiados dependern de los drivers del mercado del proyecto y del grado de conocimiento del producto. La razn para proporcionar esta mezcla hecha a medida se basa en tres premisas fundamentales:
1. A diferencia de la situacin del COCOMO inicial a finales de los 70, en los que haba un nico y preferido modelo de ciclo software, los proyectos de software actuales y futuros ajustan sus procesos a los particulares drivers de proceso. Estos drivers de proceso incluyen COTS disponibilidad de software reutilizable, grados de composicin de arquitecturas y requisitos, ventana de mercado, y fiabilidad necesaria. 2. La granularidad que usa el modelo de estimacin de coste software debe ser consistente con la informacin disponible para dar soporte a la estimacin del coste software. En las primeras fases de un proyecto software se conoce muy poco del tamao del producto que se desarrolla, la naturaleza de la plataforma designada, la naturaleza del personal involucrado en el proyecto los datos concretos del proceso que se utilizar. 3. Dada la situacin de las premisas 1 y 2, COCOMO II permite que los proyectos proporcionen informacin sobre los drivers de coste, de grano grueso en las primeras etapas del proyecto y progresivamente informacin de grano fino en las etapas posteriores. As pues COCOMO II no produce valores de puntos de coste y esfuerzo software, sino un rango de valores asociado al grado de definicin de las entradas estimadas.
Pg. 69 .
7.2.3. CUNDO UTILIZAR CADA MODELO DE COSTE COCOMO II?
7.2.3.1. UTILIZACIN DEL MODELO DE COMPOSICIN DE APLICACIONES
Las primeras fases o ciclos en espiral utilizados en proyectos software de Generador de Aplicaciones, Integracin de Sistema e Infraestructura implicarn generalmente prototipado y utilizarn las utilidades del Mdulo de Composicin de Aplicaciones. El Modulo de Composicin de Aplicaciones COCOMO II, soporta estas fases y cualquier otra actividad de prototipado que se realice ms adelante en el ciclo de vida. Este modelo se dirige a aplicaciones que estn demasiado diversificadas para crearse rpidamente en una herramienta de dominio especfico, (como una hoja de clculo) y que todava no se conocen suficientemente como para ser compuestas a partir de componentes interoperables. Ejemplos de estos sistemas basados en componentes son los creadores de interfaces grficas para usuario, bases de datos gestores de objetos, middleware para proceso distribuido transaccional, manejadores hipermedia, buscadores de datos pequeos y componentes de dominio especfico tales como paquetes de control de procesos financieros, mdicos industriales. Dado que el Modelo de Composicin de Aplicaciones incluye esfuerzos de prototipado para resolver asuntos potenciales de alto riesgo tales como interfaces de usuario, interaccin software/sistema, ejecucin grado de madurez tecnolgica, los costes de este tipo de esfuerzo se estiman mejor mediante dicho modelo.
7.2.3.2. UTILIZACIN DEL MODELO DE DISEO ANTICIPADO
Hemos visto que las primeras fases o ciclos en espiral utilizados en proyectos software de Generador de Aplicaciones, Integracin de Sistema e Infraestructura se ajustaban mejor al modelo de Composicin de Aplicaciones. Las siguientes fases ciclos espirales normalmente incluirn la exploracin de arquitecturas alternativas estratgicas de desarrollo incremental. Para sostener estas actividades COCOMO II proporciona un modelo de estimacin anticipado: el Modelo de Diseo Anticipado. El nivel de detalle de este modelo puede ser consistente con el nivel general de informacin disponible y con el nivel general de aproximacin de la estimacin requerida en esta etapa. El Diseo Anticipado incluye la exploracin de arquitecturas de software/sistema alternativas y conceptos de operacin. En esta fase no se sabe lo suficiente como para dar soporte a la estimacin de grano fino. La correspondiente capacidad de COCOMO II incluye el uso de Puntos de Funcin y un conjunto de siete drivers de coste de grano grueso (por ejemplo, dos drivers de coste para capacidad del personal y experiencia del personal en lugar de los seis drivers de coste del Modelo Post-Arquitectura que cubren varios aspectos de capacidad del personal, continuidad y experiencia). El modelo de Diseo Anticipado usa Puntos de Funcin No Ajustados como mtrica de medida. Este modelo se utiliza en las primeras etapas de un proyecto software, cuando se conoce muy poco sobre el tamao del
producto que se va a desarrollar, la naturaleza de la plataforma objetivo, la naturaleza del personal involucrado en el proyecto especificaciones detalladas del proceso que se va a usar. Este modelo puede aplicarse a cada uno de los sectores de desarrollo de Generador de Aplicaciones, Integracin de sistemas Infraestructura. (ver apartado 5.2.1, Situacin del software en el mercado futuro). 7.2.3.3. UTILIZACIN DEL MODELO POST-ARQUITECTURA
Hemos visto que las primeras fases o ciclos en espiral usados en proyectos software de Generador de Aplicaciones, Integracin de Sistema e Infraestructura se ajustaban mejor al modelo de Composicin de Aplicaciones y que las siguientes fases ciclos espirales normalmente sern sostenidas por el modelo de Diseo Anticipado. Una vez que el proyecto est listo para desarrollar y sostener un sistema especializado, debe haber una arquitectura de ciclo de vida que proporcione informacin ms precisa de los drivers de coste de entradas y permita clculos de coste ms exactos. Para apoyar esta etapa COCOMO II proporciona el Modelo Post-Arquitectura. El Modelo Post-Arquitectura incluye el actual desarrollo y mantenimiento de un producto software. Esta fase avanza rentablemente si se desarrolla una arquitectura de ciclo de vida software vlida con respecto a la misin del sistema, al concepto de operacin y al riesgo, y establecido como marca de trabajo del producto. El modelo correspondiente de COCOMO II tiene aproximadamente la misma granularidad que los anteriores modelos COCOMO y AdaCOCOMO. Utiliza instrucciones fuente y/ Puntos de Funcin para medir, con modificadores para reutilizacin y objetos software; un conjunto de 17 drivers de coste multiplicativos; y un conjunto de 5 factores que determinan el exponente de escala del proyecto. Estos factores sustituyen los modos de desarrollo (Orgnico, Semilibre y Rgido) del modelo original COCOMO y refina los 4 factores de exponente-escala en Ada COCOMO.
7.3. MODELO DE COSTE DE COMPOSICIN DE APLICACIONES 7.3.1. INTRODUCCIN A LOS PUNTOS OBJETO
Los Puntos Objeto son el recuento de pantallas, informes y mdulos de lenguajes de 3 generacin desarrollados en la aplicacin, cada uno ponderado mediante un factor de complejidad de tres niveles (simple, medio y complejo). La estimacin de Puntos Objeto es un enfoque relativamente nuevo de medida del software, pero encaja bien en las prcticas del sector de la Composicin de Aplicaciones. Tambin encaja muy bien en los esfuerzos de prototipado asociados, basados en el uso de herramientas ICASE que proporcionan constructores de interfaces grficos de usuario, herramientas de desarrollo software; y en general, infraestructura que puede componerse y componentes de aplicacin. En estas reas se ha comparado bien con la estimacin de Puntos de Funcin en un conjunto de aplicaciones no triviales (pero todava limitadas).
Pg. 71 .
Uno de los estudios comparativos entre la estimacin de Puntos de Funcin y Puntos Objeto analiz una muestra de 19 proyectos software sobre inversin bancaria de una misma organizacin, desarrollado utilizando las utilidades de Composicin de Aplicaciones ICASE y con un rango de esfuerzo de 4.7 a 71.9 MM (Meses-Persona). El estudio descubri que el enfoque de Puntos Objeto justific un 73% de la varianza (R2) en meses-persona ajustados por la reutilizacin, comparada con el 76% para los Puntos de Funcin. Un experimento posterior diseado estadsticamente incluy cuatro gestores de proyecto experimentados utilizando Puntos de Funcin y Puntos Objeto para estimar el esfuerzo requerido en dos proyectos completos (3.5 y 6 Meses-persona actuales), basado en las descripciones del proyecto disponibles al principio para dichos proyectos. El experimento descubri que los Puntos de Funcin y los Puntos Objeto dan resultados comparablemente precisos (un poco ms precisos con Puntos Objeto pero estadsticamente insignificantes). Desde el punto de vista de la utilizacin, el tiempo medio para producir un valor de Punto Objeto era de alrededor del 47% del correspondiente tiempo medio para producir un valor de Puntos de Funcin. Tambin los gestores consideraron el mtodo de Puntos Objeto ms fcil de usar (ambos resultados fueron estadsticamente significantes). De esta manera aunque estos resultados no estn todava extendidos, su ajuste al desarrollo software de Composicin de Aplicaciones parece justificar la seleccin de Puntos Objeto como el punto de partida para el modelo de estimacin de Composicin de Aplicaciones.
7.3.2. PROCEDIMIENTO DE OBTENCIN DE PUNTOS OBJETO
La definicin de los trminos utilizados en los Puntos de Objetos es la siguiente: NOP: Nuevos Puntos Objeto. (Cantidad de Puntos Objeto ajustados por la reutilizacin). Srvr: Nmero de tablas de datos del servidor (mainframe
equivalente) usadas junto con la pantalla o el informe. Clnt: Nmero de tablas de datos del cliente (estacin de trabajo personal) usadas junto con la pantalla o el informe. %reuse: Porcentaje de pantallas, informes y mdulos 3GL
reutilizados a partir de grado de reutilizacin.
aplicaciones anteriores prorrateadas por
Los ratios de productividad se basan en los datos del proyecto del ao 1 y ao 2. En el ao 1 la herramienta CASE estaba construyndose y los desarrolladores no la conocan. La productividad media de NOP/Mespersona en los 12 proyectos del ao 1 se asocia con los niveles bajos de desarrollador y madurez y capacidad ICASE. En los siete proyectos del ao 2, ambos, herramientas CASE y capacidades de los desarrolladores se consideran ms maduras. La productividad media era 25 NOP/Meses-persona, que se corresponde con los niveles altos de madurez ICASE y del desarrollador.
Pg. 72 .
Hemos de destacar que el uso del trmino objeto en Puntos Objeto define pantallas, informes y mdulos 3GL como objetos. Esto puede tener relacin no con otras definiciones de objetos como aquellas caractersticas de posesin tales como, por ejemplo, pertenencia a una clase, herencia, encapsulacin, paso de mensajes y as sucesivamente. Las reglas de recuento para objetos de esa naturaleza, cuando se usan en lenguajes como C++, se discutirn en el Captulo del Modelo Post-Arquitectura. 1. Hacer el recuento de objetos: Estimar el nmero de pantallas, informes y componentes de las que consta esta aplicacin. Suponer las definiciones estndar de estos objetos en el entorno ICASE correspondiente.
2. Clasificar cada instancia de objeto dentro de niveles de complejidad simple, media y difcil
dependiendo de los valores de las dimensiones de la caracterstica. Usar la tabla 7.3:
Para Pantallas N de vistas que contiene # y fuente de tablas de datos N de secciones que contiene Para Informes # y fuente de tablas de datos
<3 3 7 >8
Total<4 (<2 srvr <3 clnt) Simple Simple Medio
Total<8 (2/3 srvr 3-5 clnt) Simple Medio Difcil
Total 8+ (>3 srvr >5 clnt) Medio Difcil Difcil
01 23 4+
Total<4 (<2 srvr <3 clnt) Simple Simple Medio
Total<8 (2/3 srvr 3-5 clnt) Simple Medio Difcil
Total 8+ (>3 srvr >5 clnt) Medio Difcil Difcil
Tabla 7.3. Complejidad asociada a las instancias de objetos
3. Pesar el nmero de cada celda usando la tabla 7.4. El peso refleja el esfuerzo relativo que se requiere
para implementar una instancia de ese nivel de complejidad:
Tipo de Objeto Simple Pantalla Informe Componente 3 GL 1 2 Complejidad-Peso Medio 2 5 Difcil 3 8 10
Pg. 73 .
Tabla 7.4.
Pesos asociados a los niveles de complejidad
4. Determinar Puntos Objeto: Suma todas las instancias de objeto pesadas para conseguir un nmero. El recuento de Puntos Objeto.
5. Estimar el porcentaje de reutilizacin que se espera lograr en este proyecto. Calcular los nuevos Puntos Objeto a desarrollar.
(Object NOP =
Points) 100
(100
6. Determinar un ratio de productividad PROD = NOP/Meses-persona a partir de la tabla 7.5:
Experiencia y capacidad de los desarrolladores ICASE madurez y capacidad
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
PROD
13
25
50
Tabla 7.5
Ratio de productividad PROD
7. Calcular el valor Meses-persona estimado segn la ecuacin:
NOP MM = PROD
7.4. EL MODELO DE DISEO ANTICIPADO Y POST-ARQUITECTURA. Los modelos de Diseo Anticipado y Post-Arquitectura se basan en la misma filosofa a la hora de proporcionar una estimacin. Como hemos indicado ya su principal diferencia se produce en la cantidad y
Pg. 74 .
detalle de la informacin que se utiliza para obtener la estimacin en cada uno de ellos. La frmula bsica para obtener una estimacin de esfuerzo con ambos modelos es:
MM
NOMINAL
= A X
(Size)B
Esta ecuacin calcula el esfuerzo nominal para un proyecto de un tamao dado expresado en Meses-persona (MM). Las entradas son la medida del desarrollo del software, una constante, A, y un factor de escala, B. La medida est en unidades de lneas de cdigo fuente (KSLOC). Esto se deriva de la medida de mdulos software que constituirn el programa de aplicacin, puede estimarse tambin a partir de Puntos de Funcin sin ajustar convirtiendo a SLOC y luego dividiendo por 1000. El factor de escala (exponencial B), explica el ahorro gasto relativo de escala encontrado en proyectos software de distintos tamaos. La constante A, se usa para cortar los efectos multiplicativos de esfuerzo en proyectos de tamao incremental. A continuacin desarrollamos la frmula completa del modelo de Diseo Anticipado y se describen sus componentes. 7.4.1. CONSTANTE A.
Como ya hemos visto anteriormente la constante A, se usa para capturar los efectos multiplicativos de esfuerzo en proyectos de tamao incremental. Provisionalmente se le ha estimado un valor de 2.45.
7.4.2. VARIABLE SIZE.
Dnde:
BRAK
Size
= Size
100 1
COCOMO II utiliza un porcentaje de Rotura BRAK para ajustar el tamao eficaz del producto. La rotura refleja la volatilidad de los requisitos en un proyecto. Es el porcentaje de cdigo desperdiciado debido a la volatilidad de los requisitos. El factor BRAK no se usa en el Modelo de Composicin de Aplicaciones donde se espera un cierto grado de iteracin en el producto y se incluye en la calibracin de datos.
Pg. 75 .
Por ejemplo, un proyecto que parte de 100.000 instrucciones (Size = 100.000) pero desecha el equivalente a 20.000 instrucciones tiene un valor de BRAK de 20. Esto debe usarse para ajustar el tamao efectivo del proyecto a 120.000 instrucciones para una estimacin COCOMO II. (Size = 100.000 x [1 + (20/100)])
El tamao de una aplicacin se mide en unidades de lneas de cdigo fuente (KSLOC). Al igual que en la versin inicial del COCOMO, este valor se deriva de la medida de mdulos software que constituirn el programa de aplicacin, sin embargo, en la nueva versin COCOMO II puede estimarse tambin a partir de Puntos de Funcin sin ajustar convirtiendo a SLOC y luego dividiendo por 1000. Si se opta por utilizar directamente el valor del nmero de lneas de cdigo, la meta es medir la cantidad de trabajo intelectual que se emplea en el desarrollo del programa, pero las dificultades aparecen al intentar definir medidas consistentes en diferentes lenguajes. Si se opta por utilizar los Puntos de Funcin sin Ajustar para determinar el tamao del proyecto, stos deben convertirse en lneas de cdigo fuente en el lenguaje de implementacin (ensamblador, lenguajes de alto nivel, lenguajes de cuarta generacin, etc...) para evaluar la relativamente concisa implementacin por Puntos de Funcin (ver tabla 7.6). COCOMO II realiza esto tanto en el Modelo de Diseo Anticipado como en el de Post-Arquitectura usando tablas que traducen Puntos de Funcin sin ajustar al equivalente SLOC.
Pg. 76 .
Lenguaje Ada Al Shell APL Assembly Assembly (Macro) ANSI/Quick/Turbo Basic Basic Compiled Basic Interpreted C C++ Visual Basic ANSI Cobol 85 Fortran 77 Forth Jovial Lisp Modula 2 Pascal Prolog Report Generator Spreadsheet
SLOC / UFP 71 49 32 320 213 64 91 128 128 29 32 91 105 64 105 64 80 91 64 80 6
Tabla 7.6.
Conversin de Puntos de Funcin a Lneas de cdigo
A continuacin slo nos quedara por hacer la conversin a KSLOC mediante la operacin SLOC/1000.
Por ejemplo, si al aplicar el procedimiento de clculo para puntos de funcin sin ajustar se obtiene un resultado de 165 UNFP (Puntos de Funcin sin Ajustar) y el proyecto va a desarrollarse en el lenguaje de programacin C++: 165 UNFP x 29 = 4785 SLOC (Lneas de Cdigo Fuente) Haciendo la conversin mencionada anteriormente: 4785/1000= 4.785 KSLOC (Miles de Lneas de Cdigo Fuente).
Pg. 77 .
7.4.3. Variable B (ahorro y gasto software de escala).
B = 0.91+ 0.01 x
SFj
Los modelos de estimacin de coste del software a menudo tienen un factor exponencial para considerar los gastos y ahorros relativos de escala encontrados en proyectos software de distinto tamao. El exponente B se usa para capturar estos efectos. El valor de B es calculado en la ecuacin anterior. Si B < 1.0. El proyecto presenta ahorros de escala. Si el tamao del producto se dobla, el esfuerzo del proyecto es menor que el doble. La productividad del proyecto aumenta a medida que aumenta el tamao del producto. Pueden lograrse algunos ahorros de escala del proyecto con herramientas de proyecto especficas (por ejemplo, simulaciones, testbeds) pero normalmente es difcil lograrlo. Para proyectos pequeos, fijar costes de salida tales como herramientas a medida y normas de montaje, e informes administrativos, son a menudo una fuente de ahorro de escala.
Si B = 1.0. Los ahorros y gastos de escala estn equilibrados. Este modelo lineal se usa a menudo para la estimacin de coste de proyectos pequeos. Se usa para el modelo COCOMO II: Composicin de Aplicaciones.
Si B > 1.0. El proyecto presenta gastos de escala. Esto se debe normalmente a dos factores principales: El crecimiento del gasto en comunicaciones y el gasto en crecimiento de la integracin de un gran sistema. Los proyectos ms grandes tendrn ms personal y por lo tanto ms vas de comunicacin interpersonales produciendo gasto. Integrar un producto pequeo como parte de uno ms grande requiere no slo el esfuerzo de desarrollar el producto pequeo sino
tambin el gasto adicional en esfuerzo para disear, mantener, integrar y probar sus interfaces con el resto del producto.
El exponente B se obtiene mediante los denominados drivers de escala. La seleccin de drivers de escala se basa en la razn de que ellos son un recurso significante de variacin exponencial en un esfuerzo variacin de la productividad del proyecto. Cada driver de escala tiene un rango de niveles de valores desde Muy Bajo hasta Extra Alto (tabla 7.7). Cada nivel de valores tiene un peso, SF, y el valor especfico del peso se llama
Pg. 78 .
factor de escala. Un factor de escala de un proyecto, SFj (ver tabla 7.8), se calcula sumando todos los factores y se usa para determinar el exponente de escala, B.
Factores de Escala (SFj) PREC Completamente Prcticamensin te Casi sin Algo familiar Muy familiar Completamente familiar Algo relajacin A menudo (60%) TEAM Interacciones muy difciles Algo de Interacciones de Conformidad Algo general Generalmente (75%) Bastante cooperativo de Metas generales Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
sin precedentes
precedentes FLEX Riguroso
precedentes Relajacin ocasional
conformidad
RESL*
Poco (20%)
Algo (40%)
En su mayor Por completo parte (90%) Altamente cooperativo (100%) Completas interacciones
dificultad en bsicamente las interacciones cooperativas
PMAT Peso medio de respuestas S para el cuestionario de Madurez CMM
Tabla 7.7. Factores de escala para el Modelo de COCOMO II de Diseo Anticipado.

*
% de mdulos de interfaz significativos especificados, % de riesgos significativos eliminados.

Factores de Escala (Wi) PREC FLEX RESL* TEAM PMAT 6.20 5.07 7.07 5.48 7.80 4.96 4.05 5.65 4.38 6.24 3.72 3.04 4.24 3.29 4.68 2.48 2.03 2.83 2.19 3.12 1.24 1.01 1.41 1.10 1.56 0.00 0.00 0.00 0.00 0.00 Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
Tabla 7.8. Valores de los Factores de escala para el Modelo de COCOMO II de Diseo Anticipado pertenecientes a la versin USC-COCOMOII.1999.0
Pg. 79 .
Por ejemplo, si tenemos factores de escala con valores Muy Bajo, entonces un proyecto 100 KSLOC esfuerzo relativo E= E=100
1.2325
tendr
SFj = 31,62, B=1.2325 y un
=291 PM.
Los valores actuales de los factores de escala estn reflejados en la tabla 7.8.
(PREC) (FLEX). Precedencia y Flexibilidad de desarrollo. Estos dos factores de escala capturan en gran parte las diferencias entre los modos Orgnico, Semilibre y Rgido del modelo original COCOMO. La tabla 7.9 se organiza para trazar su rango de proyecto dentro de las escalas de Precedencia y Flexibilidad de desarrollo.
Caractersticas Precedencia Comprensin organizacional Experiencia en trabajo con sistemas Sw relacionados Desarrollo concurrente de nuevo Hw asociado y procedimientos operacionales Necesidad de arquitecturas de proceso de datos innovativas, algoritmos Flexibilidad de Desarrollo Necesidad de conformidad del Sw con requisitos preestablecidos Necesidad de conformidad del Sw con especificaciones de interfaz externas Prioridad en finalizacin anticipada Alto Medio Bajo Completo Considerable Bsico Completo Considerable Bsico Considerable Algo Mnimo Extenso Moderado Algo Moderado Considerable Extenso General Considerable Profundo Muy Bajo Nominal/Alto Extra Alto
Tabla 7.9. Factores de escala relacionados con Modos de desarrollo COCOMO
Pg. 80 .
(RESL) Arquitectura/Resolucin de Riesgos Este factor combina dos factores de medida de AdaCOCOMO Minuciosidad del diseo por revisin del diseo del producto (PDR) y Eliminacin de riesgos por PDR. La tabla 7.10 consolida las medidas de AdaCOCOMO para formar una definicin ms comprensiva de los niveles de medida RESL de COCOMO II. La medida de RESL es la media pesada subjetiva de las caractersticas de la lista.
Pg. 81 .
Caractersticas
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
El plan de gestin de riesgos identifica todos los tems de riesgos crticos, establece hitos para resolverlos mediante PDR Horario, presupuesto e hitos internos con PDR compatible con el Plan de gestin de riesgos Tanto por ciento de horario desarrollado dedicado a establecer la arquitectura dados los objetivos generales del producto Porcentaje de arquitectos Sw de alto nivel requeridos, disponibles para el proyecto Herramientas de soporte disponibles para resolver tems de riesgo, desarrollar y verificar garantas de la arquitectura Nivel de incertidumbre en drivers de arquitectura claves: misin ,interfaz de usuario, COTS, Hw, tecnologa, ejecucin Nmero y criticidad de tems de riesgo
Ninguno
Poco
Algo
Generalmente
A menudo
Completamente
Ninguno
Poco
Algo
Generalmente
A menudo
Completamente
10
17
25
33
40
20
40
60
80
100
120
Ninguno
Poco
Algo
Bueno
Fuerte
Completo
Extremo
Significativo Considerable
Algo
Poco
Muy Poco
>10 Crtico
5-10 Crtico
2-4 Crtico
1 Crtico
>5 No Crtico
<5 No Crtico
Tabla 7.10. RESL Componentes de medida

(TEAM). Cohesin del Equipo El factor de escala de Cohesin del Equipo explica los recursos de turbulencia y entropa del proyecto debido a dificultades en la sincronizacin de los implicados en el proyecto, usuarios, clientes, desarrolladores, los que lo mantienen, etc... Estas dificultades pueden aparecer por las diferentes culturas y objetivos de los implicados; dificultades en conciliar objetivos y la falta de experiencia y de familiaridad de los implicados en trabajar como un equipo. La tabla 7.11 proporciona una informacin detallada para los niveles de medida completos TEAM. La medida final es la media pesada subjetiva de las caractersticas de la lista.
Pg. 82 .
Muy Bajo Caractersticas Poco Consistencia de objetivos y culturas Habilidad y servicialidad para acomodar objetivos de otros grupos Experiencia de los Desarrollados en operar como un equipo Para lograr visin compartida y compromisos Poco
Bajo
Nominal
Alto
Muy Alto
Extra Alto
Algo
Bsico
Considerable
Fuerte
Completo
Algo
Bsico
Considerable
Fuerte
Completo
Nada
Poco
Poco
Bsico
Considerable
Extensa
Nada
Poco
Poco
Bsico
Considerable
Extensa
Tabla 7.11.
(PMAT). Madurez del proceso
TEAM Componentes de medida
El procedimiento para determinar PMAT se obtiene a travs del Modelo de Madurez de Capacidad del Instituto de Ingeniera del Software (CMM). El periodo de tiempo para medir la madurez del proceso es el momento en el que el proyecto comienza. Hay dos formas de medir la madurez del proceso. La primera toma el resultado de una evaluacin organizada basada en el CMM. Nivel de Madurez Global
Nivel Nivel Nivel Nivel Nivel Nivel
1 1 2 3 4 5
CMM (Mitad inferior) CMM (Mitad superior) CMM CMM CMM CMM
reas de Proceso Principales
La segunda est organizada en base a 18 reas de proceso principales (KPAs) en el modelo de Madurez de Capacidad SEI. El procedimiento para determinar PMAT es decidir el porcentaje de conformidad para cada uno de los KPAs. Si el proyecto ha sufrido una valoracin CMM reciente entonces se usa el porcentaje de
conformidad para la KPA global (basada en datos de valoracin de la conformidad prctica principal). Si no se ha hecho una valoracin entonces se usan los niveles de conformidad para las metas de los KPAs (con la escala Likert de abajo) para poner el nivel de conformidad. El nivel basado en meta (objetivo) de conformidad se determina haciendo una media basada en juicio de las metas de cada rea de proceso principal (ver tabla 7.12.).
reas de Proceso Clave Casi siempre (>90%) 1 Gestin de Frecuentemente (60-90%) En la Mitad (40-60%) Ocasionalmente (10-40%) En Pocas Ocasiones (<10%) No se Aplica No se Conoce
requisitos 2 Planificacin de proyectos Software 3 Seguimiento de proyecto Software 4 Gestin de
subcontrato Software 5 de Aseguramiento la calidad
Software 6 Gestin de la configuracin Software 7 Focos de proceso de organizacin 8 Definicin de de
proceso organizacin 9 Programa
de
formacin 10 Gestin del
Software integrado 11 Ingeniera de producto Software 12 Coordinacin
intergrupos 13 Informes
detallados 14 Gestin de
proceso cuantitativo 15 Gestin de
calidad Software 16 Prevencin de defectos 17 Gestin de de
cambio tecnologa
Pg. 84 .

18 Gestin de cambio de proceso
Tabla 7.12.
Porcentaje de conformidad para las reas de proceso principales.
Verificar casi siempre, cuando las metas se logran de forma consistente y se establecen bien en procedimientos que operan bajo la norma (alrededor del 90% del tiempo). Verificar frecuentemente, cuando las metas se logran relativamente a menudo pero algunas veces se pasan por alto bajo circunstancias difciles (alrededor del 60% al 90% del tiempo). Verificar sobre la metas, cuando las metas se logran alrededor de la mitad del tiempo (alrededor del 40% al 60% del tiempo). Verificar ocasionalmente, cuando las metas se logran a veces pero menos a menudo (entre el 10% y 3l 40% del tiempo). Casi nunca verificar, si las metas no se alcanzan casi nunca (menos del 10% del tiempo). No aplicar verificacin, cuando se tiene conocimiento requerido para tu proyecto u organizacin y el KPA pero siente que el KPA no se adapta a tus circunstancias. No sabe verificar cuando no sabes cmo responder para el KPA.
Despus de que el nivel de conformidad del KPA se determina, se pesa cada nivel de conformidad y se calcula un factor PMAT. Inicialmente todos los KPAs tendrn el mismo peso.
18
5 -
KPA%i 100
Por ejemplo, el valor del factor PMAT para un caso en el que aplicando la tabla de reas de Proceso Clave: (Tabla 7.12.), obtengamos los siguientes resultados: 1. Gestin de requisitos: 90% 2. Planificacin de Proyectos Software: 50%
Pg. 85 .
3. Seguimiento del proyecto software: 60% 4. Gestin de subcontrato software: 30% 5. Aseguramiento de la calidad software: 60% 6. Gestin de la configuracin software: 80% 7. Focos de proceso de organizacin: 50% 8. Definicin de proceso de organizacin: 45% 9. Programa de formacin: 80% 10. Gestin del software integrado: 60% 11. Ingeniera de producto software: 40% 12. Coordinacin intergrupos: 60% 13. Informes detallados: 80% 14. Gestin de proceso cuantitativo: 10% 15. Gestin de calidad software: 25% 16. Prevencin de defectos: 20% 17. Gestin de cambio de tecnologa: 60% 18. Gestin de cambio de proceso: 45% ser: PMAT= 5- (9.45 X (5/18)) = 2.375
7.4.4. AJUSTE MEDIANTE DRIVERS DE COSTE
Los drivers de coste se usan para capturar caractersticas del desarrollo del software que afectan al esfuerzo para completar el proyecto. Los drivers de coste tienen un nivel de medida que expresa el impacto del driver en el esfuerzo de desarrollo. Estos valores pueden ir desde Extra Bajo hasta Extra Alto. Para el propsito del anlisis cuantitativo, cada nivel de medida de cada driver de coste tiene un peso asociado. El peso se llama multiplicador de esfuerzo (EM). La medida asignada a un driver de coste es 1.0 y el nivel de medida asociado con ese peso se llama nominal. Si un nivel de medida produce ms esfuerzo de desarrollo de software, entonces su correspondiente EM est por encima de 1.0. Recprocamente si el nivel de medida reduce el esfuerzo entonces el correspondiente EM es menor que 1.0. La seleccin de multiplicadores de esfuerzo se basa en una fuerte razn que explicara una fuente significativa de esfuerzo de proyecto variacin de la productividad independientemente. Los EM se usan para ajustar el esfuerzo Meses-persona nominal. Hay 7 multiplicadores de esfuerzo para el Modelo de Diseo Anticipado y 17 para el modelo de Post-Arquitectura.
MM = A x (Size)B x
EMi
Pg. 86 .
Los drivers de coste del Diseo Anticipado se obtienen combinando los drivers de coste del modelo PostArquitectura de la tabla 7.13. Siempre que una evaluacin de un driver de coste est entre niveles de ratio, hay que redondear al valor ms prximo al nominal. Por ejemplo, si un valor de un driver de coste est entre Muy Bajo y Bajo, entonces seleccionar Bajo.
Drivers de coste del Diseo Anticipado RCPX RUSE PDIF PERS PREX FCIL SCED Drivers de coste combinados, homlogos del Post-Arquitectura RELY, DATA, CPLX, DOCU RUSE TIME, STOR, PVOL ACAP, PCAP, PCON AEXP, PEXP, LTEX TOOL, SITE SCED
Tabla 7.13.
Multiplicadores de esfuerzo del Diseo Anticipado y Post-Arquitectura
7.4.4.1. OBTENCIN DE DRIVERS DE COSTE PARA MODELO DE DISEO ANTICIPADO (RCPX). Fiabilidad del Producto y Complejidad Este driver de coste del Diseo Anticipado combina los 4 drivers de coste: Fiabilidad Software (RELY); Tamao de la Base de Datos (DATA), Complejidad del Producto (CPLX), y Documentos que necesita el Ciclo de Vida (DOCU). La tabla 7.14 proporciona los niveles de medida de RCPX
Extra Bajo nfasis fiabilidad, documentacin en la Muy Poco
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
Poco
Algo
Bsico
Fuerte
Muy Fuerte
Extremo
Pg. 87 .
Complejidad producto
del Muy Simple Simple Algo Moderado Complejo Muy Complejo
Extremadamente Complejo
Medida de la Base de Datos
Pequeo
Pequeo
Pequeo
Moderado
Grande
Muy Grande
Muy Grande
Tabla 7.14.
Niveles de medida RCPX
(RUSE) Reutilizacin Requerida Este driver de coste del modelo de Diseo Anticipado (tabla 7.15) es el mismo que su homlogo de PostArquitectura.
Muy Bajo
Bajo
Nominal
Alto
Muy Alto A lo largo de la lnea de producto
Extra Alto A lo largo de mltiples lneas de producto
RUSE
Nada
A lo largo del programa
A lo largo del proyecto
Tabla 7.15. Resumen del nivel de medida RUSE
(PDIF) Dificultad de la Plataforma Este driver de coste del Diseo Anticipado combina los 3 drivers de coste de Post-Arquitectura siguientes: Tiempo de Ejecucin (TIME), Restricciones de Almacenamiento (STOR) y Volatilidad de la Plataforma (PVOL). La tabla 7.16 proporciona una ayuda para obtener los niveles de medida PDIF.
Bajo
Nominal
Alto
Muy Alto
Extra Alto
Restricciones tiempo y
de de 50% >50% 65% 80% 90%
almacenamiento Volatilidad Plataforma de la Muy Estable Estable Voltil Voltil Voltil
Tabla 7.16. Niveles de medida PDIF
(PREX) Experiencia Personal

Este driver de coste de Diseo Anticipado combina los 3 drivers de coste de Post-Arquitectura siguientes: Experiencia (AEXP), Experiencia en la Plataforma (PEXP) y Experiencia en el Lenguaje y Herramientas (LTEX). La tabla 7.17 asigna valores PREX en el rango correspondiente.
Extra Bajo Experiencia en aplicaciones, plataforma, lenguaje herramienta y 3 Meses
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
5 Meses
9 Meses
1 Ao
2 Aos
4 Aos
6 Aos
Tabla 7.17. Niveles de medida PREX
(FCIL) Facilidades Este driver de coste de Diseo Anticipado combina los 2 drivers de coste de Post-Arquitectura siguientes: Uso de Herramienta Software (TOOL) y Desarrollo MultiLugar (SITE). La tabla 7.18 de la asigna valores FCIL.
Extra Bajo
Muy Bajo
Bajo
Nominal Herramientas de ciclo de vida bsicas

Soporte bsico de desarrollo multilugar moderadamente complejo
Alto
Muy Alto
Extra Alto
Soporte TOOL
de
Mnimo
Algo
Herramienta CASE simple
Bueno; moderado
Fuerte; moderado
Fuerte; Bien integrado
Soporte
Algo de soporte de desarrollo multilugar complejo
Algo de soporte de desarrollo multilugar moderadamente complejo
Fuerte soporte de desarrollo multilugar moderadamente complejo
Condiciones Multilugar
dbil de desarrollo multilugar complejo
Fuerte soporte de desarrollo multilingue simple
Soporte muy fuerte de desarrollo multilingue simple
Tabla 7.18. Niveles de medida FCIL

(SCED) Planificacin Temporal El driver de coste de Diseo Anticipado (tabla 7.19.) es el mismo que su homlogo de Post-Arquitectura.
Pg. 89 .
Muy Bajo 75% del Nominal
Bajo
Nominal
Alto
Muy Alto
Extra Alto
SCED
85%
100%
130%
160%
Tabla 7.19. Resumen de nivel de medida SCED

En la tabla 7.20. se reflejan los valores actualizados que toman los drivers de coste para el modelo de Diseo Anticipado:
Extra Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto RCPX 0.73 0.81 0.98 1.00 1.30 1.74 2.38
RUSE
--
--
0.95
1.00
1.07
1.15
1.24
PDIF
--
--
0.87
1.00
1.29
1.81
2.61
PERS
2.12
1.62
1.26
1.00
0.83
0.63
0.50
PREX
1.59
1.33
1.12
1.00
0.87
0.71
0.62
FCIL
1.43
1.30
1.10
1.00
0.87
0.73
0.62
SCED
--
1.43
1.14
1.00
1.00
1.00
--
Tabla 7.20. Multiplicadores de esfuerzo actualizados para el modelo de Diseo Anticipado pertenecientes a la versin USC-COCOMOII.1999.0.
Por ejemplo, si al analizar los drivers de coste para nuestro proyecto obtenemos los siguientes resultados:
EMB RCPX RUSE PDIF PERS
N x x x
A x
MA EA
EB=Extra Bajo MB=Muy Bajo B=Bajo N=Nominal A=Alto MA=Muy Alto
Pg. 90 .
EMB PREX FCIL SCED
A x x
MA EA
Aplicando los valores de la tabla 7.20 obtendremos:

7
EMi = 1.30 x 1 x 1 x 1 x 0.87 x 0.87 x 1.0 = 0.984

i =1
En los drivers de coste como por ejemplo FCIL (ver tabla 7.18) se evalan varias caractersticas, en este caso Soporte de TOOL y Condiciones multilugar. El resultado Alto se ha obtenido de hacer la media subjetiva entre Soporte de TOOL= Alto y Condiciones Multilugar = Muy Alto. Esta media es Alto porque como hemos visto anteriormente siempre que una evaluacin de un driver de coste est entre dos niveles de ratio, hay que redondear al nivel ms prximo al nominal. Si la evaluacin hubiese estado entre Extra Bajo y Bajo la media subjetiva hubiese sido Muy Bajo.
7.4.4.2. OBTENCIN DE DRIVERS DE COSTE PARA MODELO DE DISEO POSTARQUITECTURA (RELY). Fiabilidad Requerida de Software Esta es la medida de hasta qu punto el software debe realizar su funcin esperada durante un periodo de tiempo. Si el efecto de un fracaso es slo una molestia ligera entonces RELY es Bajo. Si un fallo arriesgase vidas humanas entonces RELY es Muy Alto. (tabla 7.21)
Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto RELY Inconveniente ligero Bajo, prdidas fcilmente recuperables Moderado, prdidas recuperables Alta prdida financiera Riesgo de vidas humanas
Tabla 7.21. Niveles de medida RELY
(DATA). Medida del Volumen de Datos
Pg. 91 .
Esta medida intenta capturar lo que afecta en el desarrollo del producto unos requerimientos de datos grandes. La medida se determina calculando D/P. La razn por la que es importante considerar el tamao de la Base de Datos es por el esfuerzo necesario para generar datos de prueba que se usarn para ejecutar el programa. D
= DataBaseSize (Bytes)
DATA se valora como Bajo si D/P es menor que 10 y Muy Alto si es mayor que 1000 (tabla 7.22).
Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
DATA
DB bytes/ Pgm SLOC < 10
10 D/P < 100
100 D/P < 1000
D/P 1000
Tabla 7.23. Niveles de medida DATA

(CPLX). Complejidad del Producto La Tabla 7.24 proporciona la nueva escala de valores CPLX de COCOMO II. La complejidad se decide en 5 reas: Funcionamiento de control, Funcionamiento computacional, Funcionamiento de Dispositivos dependientes, Funcionamiento del sector de datos y Funcionamiento del Gestor de Interfaz de Usuario. Se seleccionar el rea combinacin de reas que caracterizan al producto a un subsistema del producto. La medida de complejidad es la media subjetiva de estas reas.
Pg. 92 .
Operaciones de control
Operaciones computacionales
Operaciones dependientes del dispositivo Declaraciones simples de lectura, escritura con formatos simples
Operaciones de gestin de datos Arrays simples en memoria principal. Actualizaciones, COTS-DB queries simples.
Operaciones de gestin de interfaz de usuario Forma de entrada simple, generadores de informes
Muy Bajo
Cdigo straight line con unos pocos operadores estructurados de de programacin no anidados: DOs, CASESs, IFTHENELSESs. Composicin de mdulos simple va llamadas a procedimientos simples scripts
Evaluacin de expresiones simples: p.e. A=B+C*(D-E)
Bajo
Anidamiento sencillo de operadores de programacin estructurados. Mayora de predicados simples
Evaluacin de expresiones de nivel moderad0: p.e. D=SQRT(B**2-4.*A*C)
No necesario conocimiento de caractersticas del procesador particular del dispositivo de I/O. I/O hecha a nivel GET/PUT.
Ficheros nicos sin cambio en la estructura de datos, sin ediciones, sin ficheros intermedios. COTS- DB moderadamente complejos, queries, actualizaciones.
Uso de constructores simples de interfaces grficos de usuarios
Nominal
Mayora de anidamiento simple. Llamadas paso de mensajes simples que incluye procesamiento distribuido para soportar middleware
Uso de rutinas matemticas y estadsticas estndar. Operaciones de matriz/vector bsicas
El procesamiento de I/O incluye seleccin de dispositivo, estado de validacin y procesamiento de errores.
Entrada de mltiples ficheros y salida de un nico fichero. Cambios estructurales simples, ediciones simples. Queries, actualizaciones y COTS-DB complejas.
Uso simple de conjunto widget
Alto
Operadores de programacin estructurados altamente anidados compuesto de muchos predicados. Control de pilas y colas. Proceso homogneo y distribuido.
Anlisis numrico bsico; Interpolacin multivariada, ecuaciones diferenciales ordinarias. Truncamiento bsico,
Operaciones de I/O a nivel fsico (traducciones de direcciones de almacenamiento fsicas; bsquedas, lecturas, etc.) Overlap de I/O optimizada.
Encadenamientos simples activados por contenidos de hileras de datos. . Reestructuracin de datos compleja
Extensin y desarrollo de conjunto widget. Voz simple de I/O, multimedia.
Muy Alto
Codificacin reentrante y recursiva. Manejo de interrupciones con prioridades fijadas. Sincronizacin de tareas, retornos de llamadas complejas, proceso distribuido heterogneo. Control en tiempo real de un nico procesador
Anlisis numrico difcil pero estructurado: ecuaciones de matrices , ecuaciones diferenciales parciales. Paralelizacin simple.
Rutinas para diagnstico de interrupciones, dar servicio enmascaramiento. Manejo de lnea de comunicacin. Sistemas embebidos de rendimiento intensivo.
Coordinacin de bases de datos distribuidas. Encadenamientos complejos. Optimizacin de la bsqueda.
Moderadamente complejo 2D/3D, grficos dinmicos multimedia
Extra Alto
Mltiples recursos de planificacin con cambio dinmico de prioridades. Control a nivel de microcdigo. Control distribuido en tiempo real.
Anlisis numrico difcil y sin estructurar: anlisis de ruido altamente aproximado, datos estocsticos. Paralelizacin compleja.
Dispositivo dependiente temporalmente de la codificacin, operaciones microprogramadas.
Fuerte acoplamiento, estructuras de objetos y relacionales dinmicas. Gestin de datos del lenguaje natural.
Multimedia compleja, realidad virtual
Tabla 7.24.
Medidas de complejidad del mdulo versus Tipo de mdulo
(RUSE). Reutilizacin Requerida

Este driver de coste explica el esfuerzo adicional necesario para construir componentes pensados para ser reutilizados en proyectos presentes futuros (tabla 7.25). Este esfuerzo se consume en crear un diseo ms genrico del software, documentacin ms detallada y pruebas ms extensas, para asegurar que los componentes estn listos para utilizar en otras aplicaciones.
RUSE
Nada
A lo largo de la lnea de producto
A lo largo de las lneas de producto mltiples
Tabla 7.25. Niveles de medida RUSE

(DOCU). Documentacin Asociada a las Necesidades del Ciclo de Vida Varios modelos de coste software tienen un driver de coste para el nivel de documentacin requerida. En COCOMO II la escala de medida para el driver de coste se evala en trminos de la adecuacin de la documentacin del proyecto a las necesidades de su ciclo de vida (tabla 7.26). La escala de valores va desde Muy Bajo (muchas necesidades del ciclo de vida sin cubrir) hasta Muy Alto (excesiva para las necesidades del ciclo de vida).
DOCU
Muchas
Algunas
Necesidades
Excesivas necesidades para el ciclo de vida
Necesidades muy elevadas para el ciclo de vida
necesidades del necesidades del correctas al ciclo ciclo de vida sin cubrir ciclo de vida sin cubrir de vida
Tabla 7.26. Niveles de medida DOCU

Factores de Plataforma La plataforma se refiere a la complejidad del objetivo-mquina del hardware y la infraestructura software (anteriormente llamada mquina virtual). Los factores deben ser revisados para reflejar esto tal y como se describe en esta seccin. Se consideraron algunos factores de la plataforma adicionales, tales como, distribucin, paralelismo, rigidez y operaciones en tiempo real. (TIME). Restriccin del Tiempo de Ejecucin
Esta es una medida de la restriccin del tiempo de ejecucin impuesta en un sistema software. Las medidas se expresan en trminos de porcentaje de tiempo de ejecucin disponible que se espera que sea usado por el subsistema sistema que consume el recurso de tiempo de ejecucin. Los valores van desde nominal, menos del 50% de recursos de tiempo de ejecucin utilizados, hasta Extra Alto, 95% del recurso de tiempo de ejecucin consumido (tabla 7.27).
TIME
50% del uso de tiempo de ejecucin disponible
70%
85%
95%
Tabla 7.27. Niveles de medida TIME

(STOR). Restriccin de Almacenamiento Principal Esta medida representa el grado de restriccin de almacenamiento principal impuesto a un sistema subsistema software. Dado el notable aumento en el tiempo de ejecucin disponible del procesador y de almacenamiento principal, uno puede cuestionar si estas variables de restriccin son todava pertinentes. Los valores van desde nominal, menos que el 50%, a Extra Alto, 95% (tabla 7.28).
STOR
50% del uso del almacenamiento disponible
70%
85%
95%
Tabla 7.28. Niveles de medida STOR

(PVOL). Volatilidad de la Plataforma Plataforma se usa aqu para significar la complejidad del Hardware y Software (OS, DBMS, etc.) que el producto software necesita para realizar sus tareas. Si el software a desarrollar es un sistema operativo, entonces la plataforma es el hardware del ordenador. Si se desarrolla un Gestor de Base de Datos, entonces la plataforma es el hardware y el sistema operativo. Si se desarrolla un browser de texto de red, entonces la plataforma es la red, el hardware del ordenador, el sistema operativo y los repositorios de informacin distribuidos. La plataforma incluye cualquier compilador ensamblador que soporta el desarrollo del sistema
software. Los valores van desde Bajo donde cada 12 meses hay un cambio importante, hasta Muy Alto, donde hay un cambio importante cada 2 semanas (tabla 7.29).
Muy Bajo PVOL Mayor cambio Mayor: 6 meses Menor: 2 semanas Mayor: 2 meses Menor: 1 semana Mayor: 2 semanas Menor: 2 das Bajo Nominal Alto Muy Alto Extra Alto
cada 12 meses Menor cada mes cambio
Tabla 7.29. Niveles de medida PVOL

Factores de Personal (ACAP). Habilidad del Analista Los analistas son personal que trabaja en los requisitos de diseo de alto nivel y en diseo detallado. Los atributos principales que deben considerarse en esta medida son la habilidad de anlisis y diseo, la eficiencia y minuciosidad y la habilidad para comunicar y cooperar. La medida no debe considerar el nivel de experiencia del analista, eso se mide con AEXP. Los analistas que caen en el 90vo percentil se evalan como Muy Alto (tabla 7.30.).
ACAP
15 percentil
35 percentil
55 percentil
75 percentil
90 percentil
Tabla 7.30. Niveles de medida ACAP

(PCAP). Habilidad del Programador Las tendencias actuales continan dando nfasis a la capacidad de los analistas. Sin embargo el creciente papel de los paquetes complejos COTS y la relevante influencia asociada a la capacidad de los programadores para tratar con esos paquetes COTS, indica una tendencia tambin a darle mayor importancia a la capacidad del programador. La evaluacin debe basarse en la capacidad de los programadores como un equipo, ms que individualmente. La habilidad del programador no debe considerarse aqu, eso se mide con AEXP. Unos valores Muy Bajos del equipo de programadores es el 15avo percentil y Muy Alto en el 90vo percentil (tabla 7.31).
Pg. 96 .
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
PCAP
15 percentil
35 percentil
55 percentil
75 percentil
90 percentil
Tabla 7.31. Niveles de medida PCAP

(AEXP). Experiencia en las Aplicaciones Esta medida depende del nivel de experiencia en aplicaciones del equipo de proyecto al desarrollar sistemas subsistemas software. Los valores se definen en trminos de nivel de experiencia del equipo de proyecto en este tipo de aplicaciones. Un valor muy bajo para experiencia en aplicaciones es menor que 2 meses. Un valor muy alto es por experiencia de 6 aos ms (tabla 7.32).
AEXP
2 meses
6 meses
1 ao
3 aos
6 aos
Tabla 7.32. Niveles de medida AEXP
(PEXP). Experiencia en la Plataforma El modelo post-Arquitectura ampla la influencia en productividad de PEXP, reconociendo la importancia de entender el uso de plataformas ms poderosas, incluyendo ms interfaces grficos de usuario, redes y capacidades de middleware distribuido (tabla 7.33).
PEXP
2 meses
6 meses
1 ao
3 aos
6 aos
Tabla 7.33. Niveles de medida PEXP
(LTEX). Experiencia en la Herramienta y en el Lenguaje
Pg. 97 .
Esta es una medida del nivel de experiencia en el lenguaje de programacin y en la herramienta software del equipo de proyecto que desarrolla el sistema subsistema software. El desarrollo de software incluye el uso de herramientas que realizan representacin de requisitos y diseo, anlisis, gestin de la configuracin, origen de los documentos, gestin de librera, estilo de programa y estructura, verificacin de consistencia, etc...Adems de la experiencia programando en un lenguaje especfico, las herramientas que dan soporte tambin influyen en el tiempo de desarrollo. Tener una experiencia de menos de 2 meses da un valor Bajo. Si es de 6 ms aos el valor es Muy Alto (tabla 7.34).
LTE X
2 meses
6 meses
1 ao
3 aos
6 aos
Tabla 7.35. Niveles de medida LTEX
(PCON). Continuidad del Personal La escala de valores de PCON se mide en trminos del movimiento de personal del proyecto anualmente: desde 3%, Muy Ato, hasta el 48%, Muy Bajo (tabla 7.36).
PCON
48% /ao
24% /ao
12% /ao
6% /ao
3% /ao
Tabla 7.36. Niveles de medida PCON
Factores del Proyecto (TOOL). Uso de Herramientas Software Las herramientas software han mejorado significativamente desde los proyectos de los 70 usados para calibrar COCOMO. Los valores para la herramienta van desde edicin y cdigo simple, Muy Bajo, hasta herramientas integradas de gestin del ciclo de vida, Muy Alto (tabla 7.37).
Pg. 98 .
TOOL
Editar, Cdigo, Depuracin
Simple, frontend, backend CASE, integracin pequea
Herramientas de ciclo de vida bsicas
Fuerte, herramientas de ciclo de vida maduras, moderada-mente integrada
Fuerte, maduro, herramientas de ciclo de vida proactivas, bien integrado con los procesos, mtodos, reutilizacin

(SITE). Desarrollo Multilugar Dada la frecuencia creciente de desarrollos multilugar e indicaciones de que los efectos del desarrollo multilugar son significantes. Se ha aadido en COCOMO II el driver de coste SITE. Determinar la medida del driver de coste incluye el clculo y la medida de 2 factores: Localizacin del lugar (desde totalmente localizado hasta distribucin internacional) y soporte de comunicacin (desde correo de superficie y algn acceso telefnico hasta multimedia totalmente interactivo) (tabla 7.38).
SITE: Localizacin
Internacion al
Multiciudad y Multicompaa
Multiciudad o Multicompaa Banda estrecha, mail
Misma ciudad Mismo edificio Completamenrea metrop. complejo te localizado
SITE: Comunicaciones
Algo de telfono, mail
Telfono individual FAX
Comunicacin electrnica de banda ancha
Comunicacin electrnica de banda ancha, video conferencia ocasional
Multimedia interactiva
Tabla 7.38. Niveles de medida SITE

(SCED). Calendario de Desarrollo Requerido Este valor mide las restricciones de horario impuestas al equipo de proyecto que desarrolla el software. Los valores se definen en trminos de porcentaje de aceleracin alargamiento sobre el calendario respecto de un calendario nominal para un proyecto que requiere una cantidad de esfuerzo dada. Los calendarios acelerados tienden a producir ms esfuerzo en las fases ms tardas de desarrollo porque se dejan por solucionar ms problemas debido a la falta de tiempo para resolverlos ms pronto. Una compresin del calendario del 74% se evala como Muy Bajo. Un alargamiento del calendario produce ms esfuerzo en las fases ms tempranas
Pg. 99 .
del desarrollo, donde hay ms tiempo para planificar, hacer especificaciones y validar minuciosamente. Un alargamiento del 160% se valora como Muy Alto (tabla 7.39).
SCED
75% del nominal
85%
100%
130%
160%
La tabla 7.40 muestra un resumen de los valores correspondientes a los drivers de coste estudiados para el modelo Post-Arquitectura. La tabla 7.41 muestra el valor de los multiplicadores para los drivers correspondientes.
Pg. 100 .
Bajo RELY Bajo, prdidas fcilmente recuperables DB bytes/ Pgm SLOC < 10
Nominal Moderado, prdidas recuperables 10 D/P < 100
Alto Alta prdida financiera 100 D/P < 1000 Ver Tabla 7.24.
Muy Alto Riesgo de vidas humanas D/P 1000
Extra Alto
DATA CPLX RUSE
Nada
A lo largo de la lnea de producto
A lo largo de las lneas de producto mltiples
DOCU
Algunas necesidades del ciclo de vida sin cubrir
Necesidades correctas al ciclo de vida
Excesivas necesidades para el ciclo de vida
Necesidades muy elevadas para el ciclo de vida 85% 95%
TIME
STOR
PVOL
ACAP PCAP PCON AEXP PEXP LTEX TOOL
50% del uso de tiempo de ejecucin disponible 50% del uso del almacenamiento disponible Mayor cambio cada Mayor: 6 meses Menor: 2 semanas 12 meses Menor cambio cada mes 35 percentil 55 percentil 35 percentil 24% /ao 6 meses 6 meses 6 meses Simple, frontend, backend CASE, integracin pequea 55 percentil 12% /ao 1 ao 1 ao 1 ao Herramientas de ciclo de vida bsicas moderadamente integradas
70%
70%
85%
95%
Mayor: 2 meses Menor: 1 semana
Mayor: 2 semanas Menor: 2 das
75 percentil 75 percentil 6% /ao 3 aos 3 aos 3 aos Fuerte, herramientas de ciclo de vida maduras, moderadamente integrada
90 percentil 90 percentil 3% /ao 6 aos 6 aos 6 aos Fuerte, maduro, herramientas de ciclo de vida proactivas, bien integrado con los procesos, mtodos, reutilizacin Mismo edificio complejo Comunicacin electrnica de banda ancha, video conferencia ocasional 160%
SITE: Localizacin SITE: Comunicaciones
Multi-ciudad y Multi-compaa Telfono individual, FAX
Multi-ciudad o Multicompaa Banda estrecha, mail
Misma ciudad rea metrop. Comunicacin electrnica de banda ancha 130%
Completament e localizado Multimedia interactiva
SCED
85%
100%
Tabla 7.40. Resumen del nivel de medida de los drivers de coste Post-Arquitectura
Pg. 101 .
Muy Bajo
Bajo
Nominal
Alto
Muy Alto
Extra Alto
RELY
0.82
0.92
1.00
1.10
1.26
--
DATA
--
0.90
1.00
1.14
1.28
--
CPLX
0.73
0.87
1.00
1.17
1.34
1.74
RUSE
--
0.95
1.00
1.07
1.15
1.24
DOCU
0.81
0.91
1.00
1.11
1.23
--
TIME
--
1.00
1.11
1.29
1.63
STOR
--
--
1.00
1.05
1.17
1.46
PVOL
--
0.87
1.00
1.15
1.30
--
ACAP
1.42
1.19
1.00
0.85
0.71
--
PCAP
1.34
1.15
1.00
0.88
0.76
--
PCON
1.29
1.12
1.00
0.90
0.81
--
AEXP
1.22
1.10
1.00
0.88
0.81
--
PEXP
1.19
1.09
1.00
0.91
0.85
--
LTEX
1.20
1.09
1.00
0.91
0.84
--
TOOL
1.17
1.09
1.00
0.90
0.78
--
SITE
1.22
1.09
1.00
0.93
0.86
0.80
SCED
1.43
1.14
1.00
1.00
1.00
--
Tabla 7.41. Multiplicadores de esfuerzo actualizados para el modelo Post-Arquitectura pertenecientes a la versin USC-COCOMOII.1999.0
Por ejemplo, si al analizar los drivers de coste para nuestro proyecto obtenemos los siguientes resultados:
E MB RELY DATA CPLX RUSE DOCU TIME STOR PVOL ACAP PCAP PCON AEXP PEXP LTEX TOOL SITE SCED B
N x
MA
EA EB=Extra Bajo
MB=Muy Bajo B=Bajo
x x x x x x x x x x x x x x x x
N=Nominal A=Alto MA=Muy Alto
17
i=1
Aplicando los valores de la tabla 7.41 obtendremos:
EMi = 1x 1.14 x 1 x 1 x 1 x 1.05x 1 X 1.19 x 1 x 1 x 1 x 1 x 0.91 x 0.90 x 1.09 x 0.93 x 1 = 1.085
Nota: En los drivers de coste como por ejemplo CPLX o SITE se evalan varias caractersticas, en este ltimo caso Comunicaciones y Localizacin (ver tabla 7.38). El resultado Alto se ha obtenido de hacer la media subjetiva entre Comunicaciones = Alto y Localizacin = Muy Alto. Esta media es Alto porque como hemos visto anteriormente siempre que una evaluacin de un driver de coste est entre dos niveles de ratio, hay que redondear al nivel nominal. Si la evaluacin hubiese estado entre Extra Bajo y Bajo la media subjetiva hubiese sido Muy Bajo.
7.4.5. VALORES DE TIEMPO DE DESARROLLO. La versin inicial de COCOMO II proporciona una capacidad de estimacin de tiempo simplemente similar a las de COCOMO. La ecuacin siguiente es la ecuacin inicial de tiempos base para las tres etapas de COCOMO II es:
TDEV
[3.67
(0 28+0 2X(B 1 01))
SCED% PM 100
Donde TDEV es el tiempo en meses desde la determinacin de una lnea base de requisitos del producto hasta que se completa una actividad de aceptacin que certifica que el producto satisface los requisitos. PM, es la estimacin de meses-persona, excluyendo el estimador de esfuerzo SCED, B, es la suma de los factores de escala del proyecto y SCED % es el porcentaje de compresin/expansin en el multiplicador de esfuerzo SCED, (ver tabla 7.39). A medida que COCOMO II evoluciona tendremos un modelo de estimacin del tiempo ms extenso que refleja las diferentes clases de modelo de proceso que puede usar un proyecto; los efectos de software COTS y reutilizable, y los efectos de las capacidades de composicin de las aplicaciones.
Por ejemplo, si tomamos un proyecto en el que hemos obtenido un resultado de 26 MM, B=0.75 y no existen restricciones de tiempo, al aplicar la ecuacin anterior obtenemos: TDEV = [3.67 x 26 (0.28+0.2 x (0.75-1.01))]
RANGOS DE SALIDA
Varios usuarios de COCOMO han expresado una preferencia por los rangos de estimacin en lugar de clculo de puntos como salidas de COCOMO. Las tres etapas del modelo COCOMO II permiten la estimacin de rangos probables de valores de salida usando distintas relaciones de exactitud de coste y medida. Una vez que se calcula el valor de esfuerzo ms probable, E, del modelo elegido: Composicin de Aplicaciones, Diseo anticipado o Post-Arquitectura, se calculan un conjunto de estimaciones optimistas y pesimistas que representan una desviacin estndar alrededor del valor ms probable, de la siguiente forma:
Pg. 104 .
Estimacin Optimista Composicin de Aplicaciones Diseo Anticipado Post-Arquitectura 0.50E 0.67 E 0.80 E
Estimacin Pesimista 2.0 E 1.5 E 1.25 E
Tabla 7.42. Rango de salida estimado

El rango de valores de esfuerzo puede utilizarse en la ecuacin de tiempo para determinar un rango de valores de tiempo.
Basndonos en el ejemplo anterior en el que calculamos el tiempo de desarrollo, si queremos estimar los rangos probables de valores de salida: MM = [0.80 (26) + 1.25 (26)] y los rangos de TDEV se obtendrn sustituyendo ambos valores en la ecuacin de tiempo correspondiente.
Veamos un ejemplo aadiendo una restriccin de tiempo: Supongamos que en un proyecto hemos aplicado la frmula del clculo del tiempo (con SCED=1 por ser la primera estimacin) y hemos obtenido que el tiempo estimado de duracin del proyecto es de 4 meses. Se nos ha impuesto una restriccin de tiempo, de forma que debemos ajustarnos a 3 meses que es el tiempo mximo que tenemos. Esto representa un 25% menos de tiempo del que obtenemos en la primera estimacin, es decir un 75% del nominal, lo que se corresponde con un valor de SCED= Muy Bajo segn la tabla 7.47. Ahora tenemos que volver a aplicar la frmula del esfuerzo ajustado, modificando el valor de SCED que sera 1.43. (tabla 7.41) para obtener un nuevo valor del esfuerzo, que ser mayor que el inicial.
Una vez estimado el esfuerzo y la duracin total de un proyecto, se puede calcular el esfuerzo y duracin distribuido por fases y subfases del proyecto con las tablas del modelo COCOMO 81, el cual supone un modelo de proceso en cascada (secuencial y progresivo). Si el modelo de proceso no es en cascada, no pueden aplicarse estas distribuciones de fases. 7.4.6. TRATAMIENTO DE LA REUTILZACIN EN LA ESTIMACIN En los modelos de Diseo Anticipado y Post-Arquitectura se pueden incluir consideraciones especiales cuando se prev reutilizacin del cdigo que compondr la aplicacin que estamos estimando. La inclusin de caractersticas de reutilizacin conlleva describir el parmetro Size como sigue:
100
Ana M Moreno S.-Capuchino Size
X
Pg. 105 .
= KSLOC + KASLOC 100 X (AAM)
Dnde la variable KSLOC ha sido explicada anteriormente, y representa el nmero de lneas de cdigo a desarrollar desde cero; la variable KASLOC representa miles de lneas de cdigo fuente adaptadas; el valor AT representa el porcentaje de traduccin automatizada y por ltimo la variable AAM representa un Multiplicador de Ajuste para la Adaptacin:
ASLOC [ AA+AAF(1+0.02(SU)(UNFM))] AAM [ESLOC] = AAF<=0.5 100 ASLOC [ AA+AAF+(SU)(UNFM)] AAM [ESLOC] = 100 AAF>0.5
AAF=0.4(DM)+0.3(CM)+0.3(IM)
El tratamiento que hace COCOMO II del software reutilizado utiliza un modelo de estimacin no lineal. Esto implica que hay que estimar la cantidad de software que se va a adaptar, ASLOC y tres parmetros de grado de modificacin: El porcentaje de diseo modificado (DM), el porcentaje de cdigo modificado (CM) y el porcentaje de esfuerzo inicial de integracin requerido para la integracin del software reutilizado (IM). El clculo de ESLOC se basa en una cantidad intermedia, el Factor de Ajuste de Adaptacin (AAF). Las cantidades de adaptacin DM, CM, IM se usan para calcular AAF, donde: DM: Porcentaje de diseo modificado. El porcentaje de diseo de software que es modificado para adaptarlo a los nuevos objetivos y al entorno. (Esto es necesariamente una cantidad subjetiva). CM: Porcentaje de cdigo modificado. El porcentaje de cdigo software adaptado que es modificado para adaptarlo a los nuevos objetivos y al entorno. IM: Porcentaje de integracin requerida para software modificado. El porcentaje de esfuerzo requerido para integrar el software adaptado dentro de la totalidad del producto y comprobar el producto resultante comparado con la cantidad de esfuerzo normal de integracin y pruebas para software de un tamao similar. Si no hay DM CM (el componente se usa sin modificaciones) entonces no es necesario SU. Se aplica SU si el cdigo es modificado.
Pg. 106 .
El incremento de comprensin del software (SU) se obtiene de la tabla 7.43. SU se expresa cuantitativamente como un porcentaje. Si el software se tasa muy alto en estructura, claridad y descriptividad del mismo, la comprensin del software y la penalizacin por comprobar el interfaz es del 10%. Si el software se tasa muy bajo en estos factores, es del 50%. SU se determina tomando el promedio subjetivo de las tres categoras.
Pg. 107 .

Cocomo Completo

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Cocomo Completo

Hochgeladen von

Copyright:

Verfügbare Formate

Estimacin de Proyectos Software

ESTIMACIN DE PROYECTOS SOFTWARE

ANA M MORENO S.- CAPUCHINO

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

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

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

0 1955 1975 1995

Figura 1.1. Relacin de costes Hw/Sw

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

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

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

TEMA 2: ESTIMACIN DE SOFTWARE

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Vida del producto Software

Figura 2.1. Grado de Informacin sobre un Proyecto

Estimacin de Proyectos Software

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

Especificacin de diseo detallado

Fasess del Software

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

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

TEMA 3: MTRICAS DE SOFTWARE

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

tareas que se desarrollan que no producen

Ana M Moreno S.-Capuchino

Estimacin de Proyectos Software

Estimacin de Proyectos Software

Ana M Moreno S.-Capuchino