TICB2 - Tecnicas de Estimacion de Esfuerzo

www.haztefuncionario.com

Material registrado. Prohibida su reproducción.

Copia exclusiva de José Ignacio Méndez Yanes. Av de los Poblados 133, 7º - 3ª - 28025 - Madrid - Tel. 917464968

B2G1T04 - TÉCNICAS DE ESTIMACIÓN DE ESFUERZO DE DESARROLLO.

INTRODUCCIÓN A LAS TÉCNICAS DE ESTIMACIÓN DE ESFUERZO DE DESARROLLO ......................... 2

1.

1.1. 1.2. 1.2. 1.3. 1.4. 1.5.

PROBLEMÁTICA DEL PROCESO DE ESTIMACIÓN DE ESFUERZO DE DESARROLLO ................................ 3 MARCO TEMPORAL DE LA ESTIMACIÓN DE ESFUERZO................................................................................. 6 SALIDAS DEL PROCESO DE ESTIMACIÓN........................................................................................................... 8 TÉCNICAS DE ESTIMACIÓN ................................................................................................................................... 8 REQUISITOS DE UN BUEN MÉTODO DE ESTIMACIÓN ..................................................................................... 8 MÉTODOS DE ESTIMACIÓN ................................................................................................................................... 8

2.

OBJETIVOS DE LA ESTIMACIÓN ............................................................................................................................... 8

3.

MÉTODO DE LA SUMA DE LAS TAREAS.................................................................................................................. 8

4.

REGLA “3 VECES PROGRAMACIÓN” ....................................................................................................................... 8

5.

MODELO DE LÍNEAS DE CÓDIGO ............................................................................................................................. 8

6.

MODELO DE PUNTOS FUNCIONALES ...................................................................................................................... 8 6.1. DEFINICIÓN DE LOS LÍMITES DEL SISTEMA ...................................................................................................... 8 6.2. DEFINICIÓN DE PARÁMETROS.............................................................................................................................. 8 6.3. TIPOS DE FUNCIÓN DE DATOS .............................................................................................................................. 8 6.3.1 FICHEROS LÓGICOS INTERNOS...................................................................................................................... 8 6.3.2 FICHEROS INTERFASE EXTERNOS ................................................................................................................. 8 6.4 TIPOS DE FUNCIÓN TRANSACCIÓN..................................................................................................................... 8 6.4.1 ENTRADAS EXTERNAS....................................................................................................................................... 8 6.4.2 SALIDAS EXTERNAS........................................................................................................................................... 8 6.4.3 CONSULTAS EXTERNAS .................................................................................................................................... 8 6.5 VALORACIÓN DE LA COMPLEJIDAD ................................................................................................................... 8 6.6. ANÁLISIS DE LAS CARACTERÍSTICAS GENERALES DEL SISTEMA .............................................................. 8 6.7. CÁLCULO DEL FACTOR DE COMPLEJIDAD TOTAL. ........................................................................................ 8

7.

MODELO DE CICLO DE VIDA...................................................................................................................................... 8

8.

MODELO COCOMO 81 ................................................................................................................................................... 8 8.1 8.2. 8.2.

9.

MODELO COCOMO BÁSICO ................................................................................................................................... 8 MODELO COCOMO INTERMEDIO ......................................................................................................................... 8 MODELO COCOMO AVANZADO ........................................................................................................................... 8

MODELO COCOMO II .................................................................................................................................................... 8 9.1. 9.2. 9.3. 9.4. 9.5. 9.6.

LOS PUNTOS OBJETO COMO MEDIDA DEL TAMAÑO FUNCIONAL ............................................................. 8 PASO 1: CONTABILIZACIÓN DE OBJETOS. ......................................................................................................... 8 PASO 2: CLASIFICACIÓN DE LOS OBJETOS........................................................................................................ 8 PASO 3: ASIGNACIÓN DE PESOS A LOS OBJETOS DEL SISTEMA.................................................................. 8 PASO 4: CÁLCULO DEL NÚMERO TOTAL DE PUNTOS OBJETO SIN AJUSTAR........................................... 8 PASO 5: CÁLCULO DEL NÚMERO TOTAL DE PUNTOS OBJETO AJUSTADOS............................................. 8

10.

CONCLUSIÓN ............................................................................................................................................................... 8

11.

BIBLIOGRAFÍA ............................................................................................................................................................ 8

12.

ESQUEMA – RESUMEN .............................................................................................................................................. 8

TEMARIO-TICB-feb04 Actualizado en febrero de 2004

B2G1T04 Página 1 de 43




1. INTRODUCCIÓN A DESARROLLO

LAS TÉCNICAS DE ESTIMACIÓN DE ESFUERZO DE

Durante muchos años el proceso de gestión de desarrollo de software ha sido considerado como un arte dejado a la improvisación del jefe del proyecto. Los proyectos se dirigían más bajo consideraciones técnicas, que de gestión. Las actividades de estimación y de planificación quedaban relegadas a un mero acto protocolario al comienzo del proyecto. Posteriormente, el seguimiento y control se realizaban sin un mínimo de rigor, dada la baja calidad de la estimación y la planificación realizada. Mientras los proyectos han sido de complejidad media la euforia de la tecnología 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 cuándo se terminará el sistema ni cuánto costará. El continuo incremento de la potencia de los ordenadores ha hecho posible concebir sistemas cada vez más complejos. El cerebro humano tiene solamente una capacidad limitada para manejar tales sistemas, y esto puede aplicarse igualmente al desarrollo del software para tratarlos. Además, como puede verse en la FIG-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 difícil 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 médicos, tráfico aéreo, sistemas financieros o sistemas de misiles. Los errores en estos sistemas pueden implicar serios desastres. Según ha crecido la experiencia en la construcción de los sistemas software, se han elaborado técnicas para el desarrollo de las especificaciones y el diseño. Estas disciplinas pueden, en la actualidad, enseñarse y aplicarse según reglas muy precisas. Sin embargo, se ha puesto de manifiesto que el uso sistemático de estas técnicas para la especificación y el diseño de software no ha resuelto el problema de la producción del software. En la industria se sigue hablando de "crisis del software"; la cantidad de esfuerzo perdido en el desarrollo de software continua en situación similar a hace años 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 través de las etapas tradicionales del proceso de construcción de software y esperar un producto satisfactorio al final del mismo. El proceso de producción 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 estándares específicos de calidad.

FIG-1. Línea base de costes






La estimación se define como el proceso que proporciona un valor a un conjunto de variables para la realización de un trabajo, dentro de un rango aceptable de tolerancia. Podemos definirlo también como la predicción de personal, del esfuerzo, de los costes y de la planificación que se requerirá para realizar todas las actividades y construir todos los productos asociados con el proyecto. Uno de los parámetros críticos de la estimación es determinar su exactitud. La estimación puede realizarse a partir de datos históricos o con herramientas. Curiosamente, en la actualidad, está ocurriendo algo sorprendente y es que algunas herramientas actualmente existentes proporcionan una estimación más exacta que la obtenida por la empresa a partir de sus datos históricos.

1.1.

PROBLEMÁTICA DEL PROCESO DE ESTIMACIÓN DE ESFUERZO DE DESARROLLO

Ya en los años 70 se comenzó a hablar del proceso de estimación del software. Sin embargo, y desafortunadamente, el arte y la ciencia de la estimación están hoy en día es su infancia. La industria del software sigue fuera de control, con costes y tiempos desmedidos. Para hablar de las posibilidades actuales de la estimación, primero debemos revisar su estado actual y explorar las necesidades de la comunidad de desarrollo de software. ¿Qué es la estimación? Vista desde el punto de vista de un diccionario, una estimación 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 gestión del desarrollo de software considera la estimación como una actividad que permite obtener, principalmente, respuestas aproximadas a las siguientes preguntas: ¿Cuánto costará?, ¿cuánto 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 estimación sea tan difícil de realizar? Las razones para esta complejidad son las siguientes: □

No existe un modelo de estimación universal o una formula que pueda ser usada para todas las organizaciones. El hecho es que se pueden definir unos principios generales, pero cada interpretación es particular y diferente del resto. Cada organización tiene sus propios recursos, procedimientos e historia; y es necesario ajustar los procesos de estimación a esos parámetros únicos. Además, a medida que estos parámetros cambien, deben cambiar los procesos de estimación.

□

Hay muchas personas implicadas en los proyectos que precisan de estimaciones. La alta dirección 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 dirección del proyecto necesita las estimaciones para hacer sugerencias a la alta dirección, para obtener los resultados necesarios para el desarrollo del proyecto, y para hacer una planificación detallada y controlar el proyecto. Cada recurso del proyecto también necesita estimaciones para planificar y controlar su propio trabajo.

□

La utilidad de una estimación también dependerá de la etapa de desarrollo en la que nos encontremos. Al comienzo de un proyecto, normalmente sólo se necesitan estimaciones de coste y duración aproximadas. A medida que el proyecto madura las estimaciones que se necesitan serán más exactas. Con lo que una estimación útil al comienzo del proyecto puede no serlo más tarde.

□

La estimación, a menudo, se hace superficialmente, sin apreciar el esfuerzo requerido para hacer un trabajo. Además, también se suele dar el caso de que la estimación sea necesaria antes de obtener las especificaciones de requisitos del sistema. Por esta razón, una situación típica es que se presiona a los estimadores para que se apresuren en escribir una estimación anticipada del sistema que no comprenden aún.






□

Las estimaciones claras, completas y precisas son difíciles de formular, especialmente al inicio del proyecto. Los cambios, adaptaciones y ampliaciones son más la regla que la excepción: como consecuencia de ello, deben adaptarse también las planificaciones y los objetivos.

□

Las características del software y de su desarrollo hacen difícil la estimación. Por ejemplo, el nivel de abstracción, la complejidad, el grado de medición del producto y del proceso, los aspectos innovadores,...

□

La rapidez con la que cambia la tecnología de la información y las metodologías de desarrollo de software son problemas para la estabilización del proceso de estimación. Por ejemplo, son difíciles de predecir la influencia de nuevos bancos de pruebas, lenguajes de cuarta y quinta generación, estrategias de prototipado, y de técnicas y herramientas novedosas en general.

□

Un estimador puede no tener mucha experiencia en estimar desarrollos, especialmente de proyectos largos. ¿Cuántos proyectos largos puede alguien dirigir en, por ejemplo, 10 años?

□

Existe una tendencia aparente de los desarrolladores hacia la subestimación. Un estimador suele elegir una porción de software debería tomar para luego extrapolarlo al resto del sistema, normalmente se ignoran los aspectos no lineales del desarrollo de software, por ejemplo, la coordinación y la gestión.

□

El estimador estima el tiempo que le llevaría 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 años podrá ser llevado a cabo por 50 personas en un año. Añadir personal a un proyecto retrasado no tiene por qué disminuir el retraso.

□

El estimador tiende a reducir en algún grado las estimaciones para hacer más aceptable la oferta.

□

Influyen un gran número de factores en el esfuerzo y duración de un desarrollo de software. Estos factores se llaman “drivers de coste” o disparadores de coste. Ejemplos de estos disparadores son el tamaño y complejidad del software, el compromiso y participación del usuario, la experiencia del equipo de desarrollo. En general estos disparadores de coste son difíciles de determinar. Es importante profundizar más en el tema de los disparadores de coste. Para mostrar su importancia, estudiaremos a continuación algunos de ellos repartidos en cinco categorías, como se muestra en la FIG-2. El producto software que se tiene que desarrollar: QUÉ El significado de la producción: CON QUÉ El personal de producción: QUIÉN La organización de producción: CÓMO El usuario/organización del usuario: PARA QUIÉN






FIG-2. Disparadores de coste En la Tabla anterior podemos ver diversos tipos de disparadores, todos ellos influirán en la estimación que vayamos a realizar, lo realmente difícil es determinar cuáles son los disparadores de coste más importantes en cada situación específica, cuáles son sus valores y cómo influyen en el esfuerzo y la duración de cada proyecto. Para resolver estas cuestiones conviene tener en cuenta varios aspectos: □

Definición. Hay una falta de definiciones claras y aceptadas de los disparadores, tales como tamaño, calidad, complejidad, experiencia,... Por ejemplo, cuándo se dice que un desarrollador es experimentado y cuándo no.

□

Cuantificación. La mayoría de los disparadores de coste son difíciles 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.

□

Correlación. Es difícil considerar un disparador independiente de los demás. Un cambio en el disparador A, puede tener consecuencias en los valores de otros disparadores. Esta es una dificultad tremenda desde el punto de vista de la medibilidad.

□

Relación entre disparador y esfuerzo. Para la estimación es importante poder predecir la relación entre, por ejemplo, el tamaño del software y el esfuerzo requerido, el nivel de calidad especificado y el esfuerzo requerido, etc.

□

Calibración. Es imposible hablar de los disparadores de coste más importantes de forma aislada. Una situación difiere mucho de otra.






Todos estos aspectos pueden proporcionar una idea de la complejidad del proceso de estimación. Sin embargo, también se han destacado las consecuencias negativas de la falta de este proceso, y la importancia de su aplicación.

1.2.

MARCO TEMPORAL DE LA ESTIMACIÓN DE ESFUERZO

¿Cuándo se debe realizar la estimación de un proyecto software? A continuación veremos en qué momento del desarrollo de un proyecto se ha de realizar el proceso de estimación. La estimación, como ya hemos anticipado, es un proceso continuo. A medida que el proyecto avanza, más se conoce de él, y por lo tanto más parámetros están disponibles para introducir en un modelo de estimación. El grado de información sobre los parámetros del sistema sigue una curva en forma de "s" típica, como se muestra en la FIG-3. La estimación continua nos permite el uso de un único modelo coherente que pueda capturar y utilizar la información sobre el proyecto a medida que este se conozca. Más precisamente, el proceso de estimación comienza usando unas pocas variables claves para proveer las "macro-características" de un proyecto, y evoluciona incorporando información de más bajo nivel para producir las "micro-características" del proyecto. La naturaleza del proceso de estimación cambia a medida que el programa progresa. Supongamos que desarrollamos un proyecto con un ciclo de vida tradicional. Al principio, en la concepción del sistema, sólo necesitamos estimaciones a grosso modo para determinar el tamaño del proyecto y estudiar su viabilidad. Es interesante conocer el esfuerzo total del proyecto, su duración, riesgos, necesidades de personal, etc. A esta primera estimación se le denomina macro-estimación de un proyecto. Como entrada para esta estimación se necesitan algunos parámetros descriptivos y genéricos sobre el proyecto.

FIG-3. Grado de refinamiento de la estimación






Una vez que los requisitos han sido definidos, se necesita una estimación más detallada para la siguiente fase, diseño del producto, con el fin de utilizarla para confeccionar una planificación para dicha fase. También se necesita una estimación a más alto nivel para el resto del proyecto. En este momento, los parámetros descriptivos y genéricos que se emplean para hacer la primera estimación se conocen más exactamente, y también se dispone de información adicional sobre los recursos que intervendrán en el desarrollo, como por ejemplo la experiencia de los desarrolladores. Después de que el diseño del producto ha finalizado, puede ser incluso que la base de la estimación haya cambiado, es decir, se puede pasar de utilizar parámetros descriptivos a emplear otros más detallados como el número de módulos esperados, o el número de líneas de código. También podrían conocerse consideraciones tecnológicas a un nivel de detalle razonable. Al final de la fase de diseño detallado, la información sobre el número de módulos y líneas de código, por ejemplo, puede ser refinada para la mejora de las estimaciones de las restantes fases. Cuando la codificación, las pruebas y la instalación han finalizado podemos obtener datos sobre el rendimiento y la calidad del sistema que, cuantificados adecuadamente, pueden constituir la base para la estimación de defectos. Estos datos, junto con el conocimiento sobre el entorno del desarrollo, permitirán realizar estimaciones para la fase de mantenimiento. La FIG-4 muestra la exactitud con la que las estimaciones software se pueden hacer, en función de las fases del ciclo de vida tradicional, o el grado de conocimiento que tenemos sobre lo que pretende hacer el software.

FIG-4. Estimación de coste de un proyecto Como puede verse en la FIG-4, 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 analógicos, numéricos o texto,...) soportarán el sistema. Las incógnitas anteriores se conocen cuando finaliza la fase de viabilidad y se decide un procedimiento de operación. En este momento, el rango de nuestra estimación disminuye en dos en cada dirección. Este rango es razonable porque todavía no se tiene información sobre los tipos de consulta que soportará el sistema, las funciones concretas, etc. Estos elementos serán conocidos en el momento de realizar la especificación de requisitos, en el que la estimación software estará en un rango de 1,5 en cada dirección. En el momento en que hayamos completado y validado la fase de diseño del producto, tendremos información sobre la estructura de datos interna del producto software, sobre las técnicas para el manejo de buffers, etc. En este momento la estimación software tendrá un rango de exactitud del 1,25. Existen todavía incógnitas, como los algoritmos que se usarán para la planificación de tareas, el manejo de errores o los procedimientos de parada del sistema. Estas serán conocidas al final de la fase de diseño detallado, pero existirá todavía una incertidumbre del 10% basada en la exactitud con la que los programadores entiendan las especificaciones que tienen que codificar. Para otros ciclos de vida como, prototipado o desarrollos en tiempo real, el proceso de estimación sería muy similar, y en todos ellos a medida que el proyecto progresa, la base de la estimación y las salidas esperadas de este proceso cambiarán.

1.2.

SALIDAS DEL PROCESO DE ESTIMACIÓN

En esta sección intentaremos dar respuesta a la siguiente pregunta. ¿Qué es lo que debemos estimar? Cuando se habló de la definición de estimación, se vieron dos preguntas a las que este proceso debía dar respuesta. Estas preguntas eran: ¿Cuánto costará? ¿Cuánto tiempo llevará hacerlo? Esta información constituye la información básica de todo proceso de estimación. Los distintos métodos existentes para realizar este proceso proporcionan información adicional para dar respuestas, en función del método, a algunas de las siguientes preguntas: □

¿Cuánta gente se necesita?

□

¿De qué perfiles?

□

¿Cuáles son los riesgos?

□

¿Cómo afectan las restricciones impuestas a las estimaciones?

□

¿Cuánto esfuerzo se necesita para realizar cada fase del ciclo de vida?

□

¿Cómo impacta este proceso en el resto de los proyectos de la empresa?

□

¿Cuál será el esfuerzo para mantener este proyecto?

□

¿Cuál será el tamaño del sistema? (líneas de código)

□

¿Cuántos defectos tendrá el producto?

□

¿Cuánta documentación será generada?

□

¿Cuál será el esfuerzo para confeccionar dicha documentación?

Se podría crear una lista compuesta por todas estas preguntas, para utilizarla como base para la solución al problema de ¿Qué estimar?. Así, se observaría que existen muchos conceptos en la mente de los estimadores. Sin embargo, dada la rápida evolución de los métodos de desarrollo de sistemas y la creciente diversificación de alternativas hardware, es correcto suponer que esta lista aumenta constantemente.






1.3.

TÉCNICAS DE ESTIMACIÓN

Para la estimación, existen cuatro técnicas básicas y comunes: □

La opinión de los expertos; Esta técnica se basa en la experiencia profesional de los participantes en el proyecto de estimación.

□

La analogía; Es una aproximación más formal que la experiencia de los expertos y se basa en la comparación directa de uno o más proyectos pasados. La estimación inicial se ajusta dependiendo de las diferencias entre el proyecto pasado y el nuevo.

□

La descomposición; Consiste en la descomposición de un producto en componentes más pequeños, o descomponer un proyecto en tareas de nivel inferior. La estimación se hace a partir del esfuerzo requerido para producir los componentes más pequeños o para realizar las tareas de nivel inferior. La estimación global del proyecto resultará de sumar las estimaciones de los componentes.

□

Las ecuaciones de estimación; Son fórmulas matemáticas que establecen la relación de algunas medidas de entrada (que normalmente es la medida del tamaño del producto) y determinan el esfuerzo que se requerirá.

La primera técnica 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 estimación. Para poder utilizar la segunda técnica es necesario disponer de una base de datos histórica de proyectos finalizados con la que poder realizar la comparación. Además todos esos proyectos tendrán que haber seguido un proceso estándar. Es decir, el ciclo de vida utilizado y las actividades han de ser similares. Si no es así, es difícil hacer comparaciones proyecto-proyecto. Un proyecto puede haber comenzado siguiendo unos pasos totalmente definidos y formalizados, y otro puede que sólo tenga definida formalmente la fase de codificación 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 estandarización para usar esta técnica. 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 difícil que las empresas cumplan estos dos requisitos: estandarización de procesos y formalización de la recogida de medidas. Hay que tener en cuenta que las empresas deberían haberlos implantado desde hace algunos años atrás, y que en estos momentos todavía existen muchas empresas que no siguen una metodología de desarrollo y que tampoco intentan abordar la cuestión de la confección de un histórico de proyectos. Para aplicar la tercera técnica hay que disponer también de una base de datos histórica 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 estimación en una organización se utiliza algún método o modelo establecido, es decir, se emplea la cuarta técnica.

1.4.

REQUISITOS DE UN BUEN MÉTODO DE ESTIMACIÓN

Un método de estimación tendrá éxito si: □

La estimación inicial está dentro del 30% de desviación del coste final real.

□

El método permite el refinamiento de la estimación durante el ciclo de vida del producto software.






□

El método es fácil de usar por el estimador. Esto permite una rápida re-estimación cuando sea necesario; por ejemplo, para evaluar distintas alternativas.

□

Las reglas de la estimación son entendidas por todas las personas a las que afectan los resultados de la misma. Los directivos se sienten más seguros cuando el proceso de estimación es fácilmente comprensible.

□

El método es soportado por herramientas y está documentado. La disponibilidad de herramientas aumenta la eficacia de cualquier método. Esto es debido, principalmente, a que los resultados pueden ser obtenidos más rápidamente y de una forma estándar.

1.5.

MÉTODOS DE ESTIMACIÓN

Un método de estimación eficaz permitirá ignorar aspectos sin interés y concentrarse en los aspectos esenciales. Un buen modelo debería poseer capacidades predictivas, mejor que ser meramente descriptivo o explicativo. La validez de las métricas de software y de los modelos de estimación debe ser establecida demostrando la coincidencia entre los datos empíricos y los experimentales. Esto requiere una cuidadosa atención en la toma de medidas y en el análisis de los datos. En general, el análisis y la validación de las métricas y los modelos de estimación requieren una sólida base estadística y diseño de experimentos. Para obtener resultados significativos son necesarios una definición precisa de las métricas involucradas y de los procedimientos para la captura de datos. Los experimentos a pequeña escala deberían ser diseñados cuidadosamente, y no aleatoriamente, utilizando principios de diseño experimental. Los experimentos muy largos son muy difíciles de dirigir. Es esencial poseer una base sólida de estadística para llevar a cabo experimentos significativos y analizar los datos resultantes. En general, si no se posee la base estadística suficiente debería de solicitarse la ayuda de estadísticos para evaluar seriamente el trabajo realizado. Los modelos de estimación existentes se pueden clasificar como Modelos Estadísticos, Modelos basados en Teorías y Modelos Compuestos.

2.

OBJETIVOS DE LA ESTIMACIÓN

Los objetivos de la estimación de proyectos son reducir los costes e incrementar los niveles de servicio y de calidad.

3.

□

Midiendo determinados aspectos del proceso de software se puede tener una visión de alto nivel de lo que sucederá durante el desarrollo.

□

Las mediciones de procesos anteriores permiten realizar predicciones sobre los actuales.

□

Las mediciones de atributos de proceso en fases iniciales del desarrollo permiten realizar predicciones sobre fases posteriores.

□

Las predicciones conducen a la toma de decisiones antes del comienzo del desarrollo, durante el desarrollo, durante la transición del producto al cliente y a lo largo de la fase de mantenimiento.

MÉTODO DE LA SUMA DE LAS TAREAS

Normalmente se suele confundir el esfuerzo necesario para desarrollar una tarea (meses/hombre) con el tiempo necesario para llevar a cabo la misma. Una tarea que tenga asignado un esfuerzo de 10 días, puede llevarse a cabo en el plazo de 5 semanas, aplicando un esfuerzo de 2 días a la semana. También nos podemos encontrar con el caso contrario en que una






tarea que necesita el esfuerzo de 10 días se lleve a cabo en una semana, empleando a dos personas a tiempo completo en su ejecución. El esfuerzo aplicado puede verse afectado por interferencias externas. Por ejemplo, teniendo que realizarse un esfuerzo de una semana - hombre, y asignando una persona a esta tarea durante una semana, puede no finalizar a causa de las interferencias. Thomsett dice que hay muchas razones para esto y en concreto menciona algunas como: □

Es necesario repetir trabajos o corregir defectos de tareas previas, que se suponían terminadas, para poder realizar la tarea actual.

□

Hay que tener en cuenta las vacaciones, fiestas, fiestas locales, puentes, etc. que puedan afectar al proyecto tanto en los lugares de trabajo como en las zonas de clientes o usuario.

□

Otros equipos de la empresa pueden realizar consultas al personal del proyecto actual sobre temas ajenos a éste.

□

La falta de administrativos puede implicar que los programadores tengan que realizar todos sus papeleos que deberían haber sido delegados.

□

Falta de formación y adiestramiento adecuada en el personal del proyecto.

□

Falta de reuniones del equipo.

□

Interrupciones de todo tipo como llamadas telefónicas, etc.

□

Tiempo de espera en reuniones.

□

Tiempo que tarda el personal en cambiar de tarea, no se puede esperar que sea instantáneo.

Estos factores se pueden llevar entre el 30% y el 50% del esfuerzo realizado. No sería extraño que para una reunión en otra ciudad, de dos días de duración, a una persona dedique cuatro días de esfuerzo si no tiene soporte administrativo y tiene que gestionarse los billetes, las reservas de hotel, etc. Otro ejemplo lo dan los retrasos a la hora de comenzar una reunión por falta de personas. Aunque parezca paradójico, por culpa de estos factores, las personas con mayor nivel de experiencia y responsabilidad en la empresa son los más afectados. Pues: □

Deben enseñar y adiestrar al personal del proyecto en temas no previstos

□

Son consultados por otros proyectos

□

Se les suele pedir que asistan a reuniones, presentaciones, etc, que en principio no tienen relación con el proyecto actual.

A la hora de asignar personas a cada tarea nos encontramos con un grupo de tareas y otro de personas. Los enfoques actuales relativos a esta asignación pasan por evaluar de cada empleado y tarea los siguientes aspectos: □

□

El conativo o KAS (Knowledge, Abilities, Skills), se puede ver como la capacidad técnica. Es decir: à

Los conocimientos para realizar la tarea.

à

La capacidad de realizarla.

à

La experiencia sobre la materia.

El cognitivo o MAC (Motivation, Attachment, Confidence), se puede ver como la voluntad de realizar la tarea. Es decir: à

La motivación de la persona.

à

El compromiso que asumirá.

à

La seguridad que tiene en si para realizarla.






Da la impresión, de que basándose en esto, Fergus O'Connell compara a un proyecto con un puzzle e indica que se ha de asignar las piezas (tareas) a las personas. Dice que eres una persona con suerte si encuentras la persona apropiada a cada pieza. Por persona hace referencia al conjunto de personalidad, habilidades, experiencia, motivación, metas personales, puntos fuertes y puntos débiles que nos hacen como somos. Además asocia los aspectos conativos al que la persona pueda realizar la tarea desde el punto de vista técnico. Los aspectos cognitivos los asocia a si la persona quiere realizar la tarea. En principio el asignar muchas personas a una tarea no quiere decir que la tarea forzosamente dure menos tiempo. Es decir, la gente y la duración no son intercambiables. Frederick P. Brooks en su libro “The mythical man-month” ofrece cuatro tipos posibles de tareas. En cada una de ellas la relación existente entre meses y hombres es diferente. Las posibles situaciones son:

Duración

1) Las tareas se pueden repartir de forma perfecta, sin necesidad de comunicación entre las personas. Cuando más personas se asignen a una tarea, ésta tendrá una duración proporcionalmente menor FIG-5. 9 8 7 6 5 4 3 2 1 0 0

1

2

3

4

5

6

7

8

Personas

FIG-5. Tipo de tarea 1

Duración

2) La tarea no se puede partir (Para que nazca un niño se requieren nueve meses, no importa cuantas mujeres se asignen). Éste tipo de tareas suelen darse cuando tenemos limitaciones en algún recurso. Así por ejemplo, si para realizar las pruebas me hace falta un dispositivo Hw especial, del que tan solo se dispone de una unidad, no tendrá sentido que asigne muchas personas a esta tarea FIG-6.

9 8 7 6 5 4 3 2 1 0 0

1

2

3

4

5

6

7

8

Personas

FIG-6. Tipo de tarea 2 3) La tarea se puede partir, pero se requiere comunicación entre las personas. En principio es la situación más habitual dado que de contener subtareas independientes, esto se hubiera tenido en cuenta en la descomposición en tareas y tendríamos varias tareas bien definidas en el proyecto. Por otra parte es






Duración

habitual tener tareas grandes que son críticas requiriendo mucho esfuerzo y que necesitamos que tengan una duración limitada FIG-7.

9 8 7 6 5 4 3 2 1 0 0

1

2

3

4

5

6

7

8

Pe rsonas


Duración

4) La tarea se puede partir pero las interrelaciones son tan complejas que cuesta más tiempo realizar la tarea con muchas personas. Son las tareas en que habitualmente alguien dice: “mira prefiero hacerlo solo, por que entre varios no terminaremos nunca” FIG-8.

9 8 7 6 5 4 3 2 1 0 0

1

2

3

4

5

6

7

8

Pe rsonas


4.

REGLA “3 VECES PROGRAMACIÓN”

La regla “3 veces programación” se puede resumir en las siguientes 3 ideas: □

Consiste básicamente en realizar la estimación del número de módulos de software o programas y su complejidad.

□

Estimar el esfuerzo requerido para completar la codificación y la compilación de cada módulo y el esfuerzo total de la programación.

□

Esfuerzo del proyecto total = (Esfuerzo estimado para la programación) * 3

Incluye administración, documentación, diseño, etc.






5.

MODELO DE LÍNEAS DE CÓDIGO

La medida más utilizada de la longitud del código fuente de un programa es el Número de Líneas de Código (Lines of Code en ingles, abreviado LOC). Sin embargo, esta métrica puede calcularse de muchas maneras. Estas diferencias afectan al tratamiento de las líneas en blanco y las líneas de comentarios, las sentencias no ejecutables, las instrucciones múltiples por línea y las múltiples líneas por instrucción. Además, deberían contarse las líneas reusables de código. La definición más común es la siguiente: “Una línea de código es cualquier línea de un texto de un programa que no es un comentario o línea en blanco, sin tener en cuenta el número de instrucciones o parte de instrucciones en la línea”. Esta definición incluye todas las líneas 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 código fuente o cuántas páginas 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 justificación 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:

donde CLOC (Comentary Lines of Code es el número de líneas de comentarios). Una medida indirecta de la densidad de comentarios seria:

En general, es interesante obtener ambas medidas (NCLOC Y LOC) ya que expresan diferentes conceptos. Cuando se intenta utilizar esta medida (líneas de código) en términos de productividad surgen dos problemas: □

No se tiene en cuenta el concepto de reutilización.

□

No se tiene en cuenta el concepto de costes fijos ni tareas que se desarrollan que no producen instrucciones.

Por ello, no debe ser utilizada esta medida directamente en la estimación de esfuerzo o productividad. Cuando se esté buscando la noción pura de longitud existen dos alternativas aceptables si se quiere utilizar bajo el concepto de ratio: □

Medir la longitud en términos de número de bytes de almacenamiento requerido para contener el texto del programa.

□

Medir la longitud en términos de número de caracteres en el texto del programa. (CHAR, del inglés Character)

Si se conoce el número medio de caracteres por línea de texto, NL; el número de líneas sería:






6.

MODELO DE PUNTOS FUNCIONALES

Los Puntos de Función miden el software cualificando la funcionalidad que proporciona externamente, basándose en el diseño lógico del sistema. Por lo tanto, en el caso de subsistemas diseñados independientemente los Puntos de Función se calcularán para cada una de ellas, y luego se sumarán. 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 diseñado independientemente los dos subsistemas que proporcionan cada funcionalidad. Los objetivos de los Puntos de Función son: □

Medir lo que el usuario pide y lo que el usuario recibe.

□

Medir independientemente de la tecnología utilizada en la implantación del sistema.

□

Proporcionar una métrica de tamaño que dé soporte al análisis de la calidad y la productividad.

□

Proporcionar un medio para la estimación del software.

□

Proporcionar un factor de normalización para la comparación de distintos software.

Además de estos objetivos, el proceso de contabilizar los Puntos de Función debería ser: □

Suficientemente simple como para minimizar la carga de trabajo de los procesos de medida.

□

Conciso en sus resultados.

El análisis de los Puntos de Función se desarrolla considerando cinco parámetros básicos externos del Sistema: □

Entrada (EI, del inglés External Input).

□

Salida (EO, del inglés External Output).

□

Consultas (EQ, del inglés External Query).

□

Grupos de datos lógicos internos (ILF, del inglés Internal Logic File).

□

Grupos de datos lógicos externos (EIF, del inglés External Interface File).

Con estos parámetros, se determinan los puntos de función sin ajustar. A este valor, se le aplica un Factor de Ajuste obtenido en base a unas valoraciones subjetivas sobre la aplicación y su entorno. Es decir las características generales del sistema. La aplicación de la técnica de los Puntos de Función comprende los siguientes pasos: □

Definición de los límites del sistema.

□

Definición de parámetros.

□

Valoración de la complejidad.

□

Análisis de las características generales del sistema.

6.1.

DEFINICIÓN DE LOS LÍMITES DEL SISTEMA

El límite es utilizado para definir el alcance del sistema y ayudar a identificar los parámetros externos. Existen tres visiones de los límites del sistema, dependiendo de la utilización que quiera realizarse de la técnica: □

La aplicación o límite del producto. Abarca a la totalidad de la aplicación y se realiza la cuenta de puntos al final del desarrollo del proyecto cuando se gestiona el grupo de mantenimiento o cuando la






organización inicia el uso de FPA (Análisis de puntos de función). Este tipo de cuenta puede ser también obtenida de un sistema en funcionamiento. □

Limite 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.

□

Limite del proyecto de mejora. Esta situación surge cuando ya existe el sistema y se trata de obtener nuevas versiones del mismo. La utilización 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 después de las mejoras y luego substraer uno de otro.

Existe un elemento subjetivo en la determinación de los límites del sistema y obviamente un cambio en ellos cambiará el total de Puntos de Función. Aunque esto podría parecer una aproximación poco científica, en la práctica la orientación que el analista debería seguir es considerar el problema como un todo discreto. La formula que permite calcular los Puntos de Función de un nuevo desarrollo es la siguiente:

Donde: FP es el número de Puntos de Función sin ajustar de la aplicación AF es el Factor de Ajuste de la aplicación El cálculo de los Puntos de Función de un proyecto de mejora se puede obtener mediante la formula:

Donde: EFP es el número de Puntos de Función del Proyecto de Mejora. VAFB es el Factor de Ajuste de la aplicación antes del proyecto de mejora. ADD es el número de Puntos de Función de aquellas funciones que se añadirán al proyecto como consecuencia de la mejora. CHGA es el número de Puntos de Función sin ajustar de aquellas funciones que serán modificadas por el proyecto de mejora. Este número refleja las funciones después de la modificación. DEL es el número de Puntos de Función sin aquellas funciones que serán eliminadas en el proceso de mejora. VAFA es el Factor de Ajuste de la aplicación después del proyecto de mejora.

6.2.

DEFINICIÓN DE PARÁMETROS

Para poder determinar la existencia de los componentes que contribuirán al total final, hay que definirlos previamente. La definición que vamos a considerar aquí es la realizada por IFPUG en 1994, última versión. Estos componentes pueden ser clasificados como Tipos de Funciones y son de dos clases: Datos o Transacciones.

6.3.

TIPOS DE FUNCIÓN DE DATOS

Representan la funcionalidad proporcionada a los usuarios para cumplir con sus requisitos de datos internos y externos.






Son de dos tipos: Ficheros Lógicos Internos y Ficheros de Interface Externos.

6.3.1

FICHEROS LÓGICOS INTERNOS

Un Fichero Lógico Interno es un grupo de datos lógicamente relacionados identificables por los usuarios o información de control mantenidos y utilizados dentro de los límites de la aplicación. Por un grupo de datos lógicamente relacionados e identificables por un usuario se entiende aquellos datos que un usuario experto podría identificar cumpliendo con un requisito específico de la aplicación. Correspondería al almacén de datos identificado por un nombre en un Diagrama de Flujos de Datos. Información de control corresponde a datos utilizados por la aplicación cumpliendo con requisitos del negocio. Mantenidos es la habilidad para añadir, cambiar o borrar datos mediante procedimientos estandarizados a través de la aplicación. Las reglas para identificar estos tipos de función son las que se muestran en la FIG-9:

FIG-9. Reglas de identificación de ficheros lógicos internos

6.3.2

FICHEROS INTERFASE EXTERNOS

Representan un grupo de datos relacionados lógicamente identificables por el usuario o información de control utilizada por la aplicación, pero mantenida por otra aplicación. Las reglas para identificar estos tipos de función son que se muestran en la FIG-10:

FIG-10. Reglas de identificación de ficheros interfase externos






6.4

TIPOS DE FUNCIÓN TRANSACCIÓN

Comprende tres tipos de función: □

Entradas externas (EI): mantiene datos almacenados internamente.

□

Salidas externas (EO): datos de salida de la aplicación.

□

Consultas externas (EQ): Combinación de una entrada (pregunta) y de una salida (respuesta).

Vamos a comentar brevemente cada una de ellas.

6.4.1

ENTRADAS EXTERNAS

Las Entradas Externas son datos o información de control que se introducen en la aplicación desde fuera de sus límites. Estos datos mantienen un Fichero Lógico Interno. La Información de Control está constituida por datos utilizados por un proceso dentro de los límites de la aplicación para asegurar el cumplimiento de los requisitos del negocio definidos por los usuarios. Esta Información de Control puede mantener directamente un Fichero Lógico Interno. Una Entrada Externa debería ser considerada única si tiene un formato distinto de las demás o el diseño lógico requiere una lógica 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 Lógico Interno (ILF) y el formato de entrada es único o la lógica del proceso es única. Para cada proceso identificado que actualiza un Fichero Lógico 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 función son que se muestran en la FIG-11:

FIG-11. Reglas de identificación de entradas externas Ejemplos de este tipo de función son: □

Las transacciones: Datos introducidos para mantener Ficheros Lógicos Internos.

□

Las pantallas de entrada: Hay que añadir una unidad a Entradas Externas por cada función que mantiene un Fichero Lógico Interno. Por ejemplo, si los datos introducidos en esa pantalla pueden añadir, cambiar y borrar información en un Fichero Lógico Interno, se contarían tres Entradas Externas.






□

Las entradas por lotes: Por cada proceso único que mantiene un Fichero Interno Lógico se debe añadir una Entrada Externa por cada adición, modificación o borrado de datos. Un fichero físico de entrada, cuando se analiza lógicamente, 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 más ficheros físicos de entrada pueden corresponder a una Entrada Externa si el proceso lógico y el formato son idénticos 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 Automático o a través de una operación normal, siendo el mismo tipo de entrada.

En cambio, no son Entradas Externas: □

Los datos referenciados utilizados por la aplicación pero no mantenidos como Ficheros Lógicos Internos.

□

Las entrada de una Consulta

□

Los generadores de Informes

□

Las pantallas de Conexión que no mantengan un Fichero Lógico Interno.

6.4.2

SALIDAS EXTERNAS

Las Salidas Externas son datos o información de control que sale de los límites de la aplicación. Esta salida debe ser considerada única si tiene un formato único o si el diseño lógico requiere un proceso lógico distinto de otras salidas del mismo formato. Toda salida ha de requerir un proceso de cálculo de la información que se proporciona. Las reglas para identificar este tipo de funciones son que se muestran en la FIG-12:

FIG-12. Reglas de identificación de salidas externas Deben considerarse Salidas Externas: □

La transferencia de datos a otras aplicaciones: Datos que residen en un Fichero Lógico Interno que son formateados y procesados para ser utilizados por otra aplicación. Las salidas son identificadas basadas en los procesos requeridos para el tratamiento de los datos. Un fichero físico de salida, cuando se analiza lógicamente, puede corresponder a varias salidas. De una manera similar, dos o más ficheros físicos de salida pueden corresponder a una Salida Externa si el proceso lógico y los formatos son






idénticos para cada uno de ellos. Un método para identificar múltiples Salidas Externas es ver cuántos tipos de registros distintos hay en el fichero. □

Los mensajes de error/configuración: No se contaran si están asociados a una Consulta o a una Entrada.

□

Los gráficos: Cada gráfico distinto, solicitado por el usuario, debería ser contado como una salida. Así, si unos datos estadísticos se presentan en formato de tabla, diagrama de barras, y tarta, se contarán como 3 salidas.

□

Los generadores de informes: Una salida desarrollada por el usuario con un generador de informes debería ser contada como una salida para cada tipo de informe especificado. Si el usuario solicita una facilidad de generación de informes como parte de la aplicación para ser confeccionados por él mismo, la cuenta será la siguiente: à

Debería contarse una Entrada Externa por cada parámetro para la definición de informes o comando (ej. select, compare, sort merge, calculate, format, etc.) utilizado por el usuario para controlar la generación del informe.

à

Debería contarse una Salida por el informe total.

à

Debería contarse un Fichero Lógico si se crea un nuevo fichero y éste se salva.

No se deben contar como Salidas: □

Las ayudas

□

Las distintas formas de invocar la misma salida lógica

□

Los mensajes de error/confirmación asociados con tipos de función distintos de Entradas Externas. Por ejemplo, no se contabilizara como salida los mensajes de error/confirmación asociados a una Consulta Externa.

□

Los informes múltiples/valores únicos de datos: Informes idénticos con el mismo formato y la misma lógica de proceso, pero que existen debido a distintos valores de datos, no se cuentan como salidas distintas. Por ejemplo, dos informes idénticos en formato y construcción, 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 creación mediante la utilización de lenguajes como FOCUS o SQL de un número indefinido de informes, no se cuentan como salidas.

6.4.3

CONSULTAS EXTERNAS

Las consultas representan los requisitos de información a la aplicación en una combinación única de entrada/salida que se obtiene de una búsqueda de datos, no actualiza un Fichero Lógico 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 diseño lógico requiere ediciones distintas a las de otras consultas. Se entiende por datos derivados aquéllos que requieren un proceso distinto a la búsqueda directa, edición o clasificación de información de Ficheros Lógicos Internos o Ficheros Interfases Externos. Las reglas para identificar este tipo de función son que se muestran en la FIG-13:






FIG-13. Reglas de identificación de consultas externas. Ejemplos de Consultas son: □

La búsqueda inmediata de datos

□

Las consultas no explícitas: Las pantallas de modificación/borrado que proporcionan capacidad de búsqueda de datos antes de la funcionalidad de cambio/borrado se consideran como consultas sólo si la información que proporcionan se muestra al usuario. Si la entrada y salida de la consulta son idénticas en las funciones de modificación y borrado, se contará una sola consulta.

□

Los menús con consultas implícitas: Las pantallas de menú que proporcionan una selección de pantallas y entradas para la búsqueda de datos para la pantalla llamada, se cuenta como una Consulta.

□

Pantallas de conexión: Las pantallas de logon que proporcionarían 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 aplicación se cuenta como una consulta. Se pueden distinguir dos categorías de Ayudas como son consultas típicas: à

Ayudas a plena pantalla: Es una facilidad que proporciona una salida a pantalla como consecuencia de una llamada, también a través de una pantalla. Se cuenta como una consulta de baja complejidad por aplicación, sin tener en cuenta el número de pantallas devueltas.

à

Ayudas por campos: Es una facilidad que se proporciona dependiendo de la posición del cursor o algún otro método de identificación, mostrándose documentación especifica a dicho campo. Se cuenta como una consulta de baja complejidad por aplicación.

□

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 formación de usuarios debería contarse como un sistema distinto.

No se consideran como Consultas: □

Los mensajes de Error/Confirmación.






□

La utilización de distintos métodos de llamada a la misma consulta.

Puede ocurrir que en una organización en particular surja una situación que no esté cubierta por las guías existentes para contar Puntos de Función. Este método refleja que ésta es una técnica en evolución. En tales casos el técnico debe tomar la decisión de formular una regla, basada en su experiencia personal así como en la de otros. Lo más importante es documentar la regla y aplicarla consistentemente.

6.5 VALORACIÓN DE LA COMPLEJIDAD Las siguientes tablas (FIG-14) muestran como clasificar los diferentes elementos de función y asignarles pesos. Así por ejemplo una entrada que contenga 10 atributos y que en su lógica se requiera acceder a un fichero diremos que se clasifica de complejidad baja y tiene asociados tres puntos de función. CLASIFICACIÓN ENTRADAS 0 ó 1 ficheros accedidos 2 ficheros accedidos 3 ó más ficheros accedidos CLASIFICACIÓN SALIDAS 0 ó 1 ficheros accedidos 2 ó 3 ficheros accedidos 4 ó más ficheros accedidos

Número de Campos o Atributos de la Entrada 1-4 Atributos 5-15 Atributos 16 ó más Atrib. BAJA BAJA MEDIA 3 3 4 BAJA MEDIA ALTA 3 4 6 MEDIA ALTA ALTA 4 6 6

Número de Campos o Atributos de la Salida 1-5 Atributos 6-19 Atributos 20 ó más Atrib. BAJA BAJA MEDIA 4 4 5 BAJA MEDIA ALTA 4 5 7 MEDIA ALTA ALTA 5 7 7

FIG-14. Elementos de función y pesos En el caso de las consultas diferenciaremos la complejidad de lo que sería la entrada y la salida, le asignaremos la complejidad mayor de las dos (baja, media o alta), pero solo un peso (3, 4 ó 6), equivalente al de una entrada de la complejidad calculada. Los ficheros de las entradas, salidas y consultas se calculan a partir de los ficheros, lógicos internos o de interfaz externos, que son accedidos durante el proceso asociado. Los atributos son tipos de datos elementales reconocibles por el usuario. En las entradas se contarán también aquellos datos que son almacenados en un fichero como consecuencia de la entrada. Los datos que se almacenen en muchos campos se contarán sólo una vez. Ejemplo: DNI en la gestión de notas. En las salidas se contarán los campos calculados, por ejemplo totales. En las salidas no se deben contar ni los literales ni los campos provenientes de variables del sistema como fecha, número de página, opciones de próxima página o página previa. Siempre se contarán los mensajes de verificación y error como un campo que puede contener estos valores. También se cuentan las opciones que indican la tarea a realizar, ejemplos son: aceptar o continuar. En las siguientes figuras se muestra un ejemplo.






Complejidad FICHEROS LÓGICOS INTERNOS 1 Registro Lógico 2-5 Registros Lógicos 6 o más Registros Lógicos

Número de Campos o Atributos 1-19 Atributos 7 BAJA 7 MEDIA 10 BAJA

20-50 Atributos 7 MEDIA 10 ALTA 15 BAJA

51 o - Atributos MEDIA 10 ALTA 15 ALTA 15

FIG-15. Estimación de ficheros lógicos internos

Complejidad FICHEROS INTERFAZ EXTERNOS 1 Registro Lógico 2-5 Registros Lógicos 6 o más Registros Lógicos

Número de Campos o Atributos 1-19 Atributos 5 BAJA 5 MEDIA 7 BAJA

20-50 Atributos BAJA 5 MEDIA 7 ALTA 10

51 - Atributos MEDIA 7 ALTA 10 ALTA 10

FIG-16. Estimación de ficheros interfaz externos Cuando se cuenten los atributos en un fichero se tendrá en cuenta: □

Sólo aquellos que el usuario es capaz de reconocer, aunque aparezcan de forma repetida se cuentan una sola vez.

□

Se han de contar los campos que hacen falta para mantener las relaciones con otros ficheros Internos o Externos.

□

Contar como un solo campo aquellos que aparecen como consecuencia de las técnicas utilizadas en la implementación física: à

Campos que aparecen más de una vez en una agrupación de datos por la tecnología o implementación. Por ejemplo un DNI que aparezca en alumno y en una tabla de aficiones, si hemos decidido que forman parte del mismo fichero las dos tablas.

à

Campos repetidos con el mismo formato pero que están para permitir múltiples ocurrencias. Por ejemplo nota ordinaria (Febrero) y nota extraordinaria (Junio)

Para contar los registros lógicos (tipo de registro) de una agrupación de datos (fichero), se han de tener en cuenta las siguientes reglas: □

Todo fichero tiene un conjunto de datos básicos (no repetitivos) más otros registros lógicos.

□

Un registro lógico es un subgrupo de datos elementales de un fichero, identificables por el usuario. Hay dos tipos de subgrupos los obligatorios y los opcionales. En el fichero de alumnos sería obligatorio sus datos de acceso (Mayor-25, FP, COU y Otras-Carreras que contendrán datos diferentes, habrá sólo uno de estos, con el que accedió a la carrera actual) y opcionales como sus aficiones deportivas, aficiones de lectura, etc. que pueden aparecer o no.

□

Contar un registro lógico por cada subgrupo, opcional u obligatorio.

□

Si no hay subgrupos contar un registro lógico.

Con esto se puede realizar la clasificación de los elementos de función. A continuación hay que calcular los puntos de función sin ajustar, para ello se puede utilizar la siguiente tabla, que además deja documentado el cálculo del los Puntos de Función sin Ajustar (PFSA) FIG-17.






Tipo Elemento

Dificultad

Entradas

Simple Media Compleja Total Puntos de Función Entradas

Salidas

Consultas: Máximo Complejidad( Entrada, Salida ) Ficheros Internos

Ficheros de Interfaz

Simple Media Compleja Total Puntos Salidas

Peso

de

3 4 6

Cantidad

Total Puntos

E1 E2 E3

3 * E1 4 * E2 6 * E3

Total Elemento

Σ Peso * Ei

4 5 7 Función

S1 S2 S3

4 * S1 5 * S2 7 * S3

C1 C2 C3

3 * C1 4 * C2 6 * C3

Σ Peso * Si

Simple Media Compleja Total Puntos de Función Consultas

3 4 6

Simple Media Compleja Total Puntos de Ficheros Internos

7 10 15 Función

Simple Media Compleja Total Puntos de Ficheros de Interfaz

5 7 10 Función

Σ Peso * Ci F1 F2 F3

7 * F1 10 * F2 15 * F3 Σ Peso * Fi

I1 I2 I3

5 * I1 7 * I2 10 * I3

Total Puntos de Función Sin Ajustar (PFSA)

Σ Peso * Ii

ΣΣ Peso*Xij

FIG-17. Puntos de Función sin Ajustar

6.6.

ANÁLISIS DE LAS CARACTERÍSTICAS GENERALES DEL SISTEMA

Los Puntos de Función sin ajustar son una aproximación de la complejidad del sistema, pero quedan características externas que no hemos contemplado, así como características del proceso de desarrollo del sistema informático que influirán en el coste del sistema y que podemos cuantificar desde las primeras fases del desarrollo. Estos factores adicionales según Albrecht son catorce. Cada factor tomará un valor entre 0 y 5, de modo que cuanta más importancia tenga un factor mayor valor se le asignará. La siguiente tabla indica los valores posibles de un factor y su significado:






Valor asignado 0 1 2 3 4 5

Significado del valor Sin influencia, factor no presente Influencia insignificante, muy baja Influencia moderada o baja Influencia media, normal Influencia alta, significativa Influencia muy alta, esencial FIG-18. Valores posibles de un factor

Con estos valores calculados, los sumaremos y obtendremos el Factor de Complejidad Total. A continuación describimos cada factor a modo de guía. □

COMUNICACIÓN DE DATOS. Los datos usados en el sistema se envían o reciben por líneas de comunicaciones.

□

PROCESO DISTRIBUIDO. Existen Procesos o Datos distribuidos, y el control de estos, forma parte del sistema.

□

OBJETIVOS DE RENDIMIENTO. Si el rendimiento es un requisito del sistema. Es decir es crítico algún factor como tiempo de respuesta o cantidad de operaciones por hora. Se tendrá que hacer consideraciones especiales durante el diseño, codificación y mantenimiento.

□

CONFIGURACIÓN DE EXPLOTACIÓN USADA INTENSAMENTE POR OTROS SISTEMAS. El sistema tendrá que ejecutarse en un equipo en el que coexistirá con otros, compitiendo por los recursos, y esta es una característica fundamental, teniendo que tenerse en cuenta en la fase de diseño.

□

TASA DE TRANSACCIONES. La tasa de transacciones será elevada. consideraciones especiales durante el diseño, codificación e instalación.

□

ENTRADA DE DATOS EN-LÍNEA. La entrada de datos será directa desde el usuario a la aplicación, de forma interactiva.

□

EFICIENCIA CON EL USUARIO FINAL. Se demanda eficiencia para el usuario en su trabajo, es decir se tiene que diseñar e implementar la aplicación con interfaces fáciles de usar y con ayudas integradas. Los tipos de elementos asociados a la eficiencia del usuario son:

□

ACTUALIZACIONES EN-LÍNEA. Los ficheros maestros y las Bases de Datos son modificados directamente de forma interactiva.

□

LÓGICA DE PROCESO INTERNO COMPLEJA. La complejidad de los procesos es una característica de la aplicación.

Se tendrá que hacer

La complejidad algorítmica realmente está mal resuelta en esta técnica. Hay que tener en cuenta que se ha desarrollado pensando en sistemas de proceso empresarial. Para sistemas complejos algorítmicamente hay técnicas que miden la complejidad como las de McCabe. □

REUSABILIDAD DEL CÓDIGO. Se tendrá que hacer consideraciones especiales durante el diseño, codificación y mantenimiento para que el código se reutilice en otras aplicaciones.

□

CONTEMPLA LA CONVERSIÓN E INSTALACIÓN. Se proveerán facilidades de instalación y conversión en el sistema. Se desea que la conversión del sistema antiguo sea fácil de realizar durante la puesta en marcha del sistema nuevo.

□

FACILIDAD DE OPERACIÓN. Entendemos por operación del sistema los trabajos asignados al centro de proceso de datos para una aplicación dada como: arranque, parada, recuperación ante fallos, copias de seguridad. Aquí tendremos en cuenta la minimización de las actividades manuales en el CPD. Así, ésta característica se valora cuando se ha descrito desde las primeras fases, habiendo de dedicarse especial atención durante el diseño, codificación y pruebas.






6.7.

□

INSTALACIONES MÚLTIPLES. El sistema ha de incluir los requerimientos de diversas empresas o departamentos en donde se ejecutará (incluso distintas plataformas). Estas características estarán presentes durante el diseño, codificación y pruebas.

□

FACILIDAD DE CAMBIOS. Se tendrá que hacer consideraciones especiales durante el diseño, codificación y mantenimiento para que en el sistema sea fácil de introducir cambios y fácil de adaptar al usuario.

CÁLCULO DEL FACTOR DE COMPLEJIDAD TOTAL.

La siguiente tabla documenta el cálculo del factor de complejidad total (FCT).

#

Factor de Complejidad

1

Comunicación de Datos.

2

Proceso Distribuido.

3

Objetivos de Rendimiento

4

Configuración de Explotación compartida

5

Tasa de Transacciones

6

Entrada de Datos EN-LÍNEA

7

Eficiencia con el Usuario Final

8

Actualizaciones EN-LÍNEA

9

Lógica del Proceso Interno Compleja

10

Reusabilidad del Código

11

Contempla la Conversión e Instalación

12

Facilidad de Operación

13

Instalaciones Múltiples

14

Facilidad de Cambios

Factor de Complejidad Total (FCT)

Valor (0..5)

Σ Valori

FIG-19. Cálculo del factor de complejidad total

7.

MODELO DE CICLO DE VIDA

Pocos modelos propuestos tienen una base técnica substancial. El modelo más importante es el de Putnam. Este modelo asume una distribución específica 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 más pequeños. El modelo asume que el esfuerzo para proyectos de desarrollo de software se distribuye de forma similar a una colección de curvas de Rayleigh-Norden, pues la forma que toman estas curvas fueron descritas analíticamente por Lord Rayleigh, una para cada actividad del desarrollo, según se muestra en la siguiente figura FIG-20:






FIG-20. Curvas de Rayleigh-Norden de esfuerzo de desarrollo Putnam desarrolló la siguiente relación entre el tamaño del producto software y el tiempo de desarrollo:

E = L3/(C3 T4) Donde: L = el número de instrucciones fuente producidas. E = el esfuerzo durante todo el ciclo de vida en años/persona C = una constante dependiente de la tecnología. T = el tiempo de desarrollo en años. Los valores típicos de C pueden ser: C = 2.000 para un entorno pobre de desarrollo de software (sin metodología, con una documentación y unas revisiones pobres); C = 8.000 para un buen entorno de desarrollo de software (con una buena metodología, adecuadas documentación y revisiones); C = 11.000 para un entorno excelente (con herramientas y técnicas automáticas). Se puede obtener la constante C correspondiente al entorno propio a partir de datos históricos recopilados sobre anteriores esfuerzos de desarrollo.

8.

MODELO COCOMO 81

En el año 1981, Barry Boehm [BOEHM81] presenta el Modelo Constructivo de Coste (COCOMO), como una jerarquía de modelos de estimación para el software. En aquella época, este modelo era perfectamente aplicable a los procesos de desarrollo software del momento. Pero en casi 20 años que han pasado desde entonces, las cosas han cambiado bastante, y se ha hecho necesaria una readaptación del modelo de tal forma que contemple las características de los procesos de desarrollo software actuales. Así las cosas, el modelo COCOMO se ‘reinventó’ de nuevo a principios de los años 90, volviendo a nacer con el nombre de COCOMO II. Se trata, entonces, de una revisión del modelo original, adaptado a los cambios acontecidos en el desarrollo profesional de aplicaciones software, desde los años 70 a esta parte. Las nuevas características que introduce, su adaptación a las nuevas metodologías de desarrollo y la posibilidad de utilizarlo prácticamente en cualquiera de las etapas del ciclo de de vida del software (incluidas las primeras






etapas, como modelo de estimación de la funcionalidad y el esfuerzo de desarrollo), hará que el modelo COCOMO II se convierta en uno de los más populares y utilizados a lo largo de todo el mundo. La jerarquía de modelos propuesta por Boehm en 1981, consta de los 3 siguientes: □

El modelo COCOMO básico. Se trata de un modelo univariable estático que calcula el esfuerzo y el coste del desarrollo de un proceso software, en función del tamaño del programa expresado en líneas de código (LDC) estimadas.

□

El modelo COCOMO intermedio. Calcula el esfuerzo de desarrollo de una aplicación software, en función del tamaño del programa y de un conjunto de “conductores de costes”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.

□

El modelo COCOMO avanzado. Incorpora todas las características del modelo intermedio y lleva a cabo una evaluación del impacto de los conductores de coste en cada fase del proceso de desarrollo software (análisis, diseño, etc).

Además, Boehm clasifica los proyectos software en tres tipos distintos: □

De tipo Orgánico, que son proyectos software relativamente pequeños y sencillos, y similares a otros ya desarrollados anteriormente.

□

De tipo Semiacoplado, que son proyectos software intermedios en tamaño y en complejidad.

□

De tipo Empotrado, que son proyectos software que deberán ser desarrollados en un entorno muy restringido de hardware, software y restricciones operativas.

Tras la jerarquía de modelos y la clasificación de los proyectos software, Boehm formula las ecuaciones apropiadas para la estimación de la duración y el tamaño de las aplicaciones software, así como el conjunto de atributos conductores de coste, necesarios para la estimación de estos parámetros con el modelo COCOMO intermedio.

8.1

MODELO COCOMO BÁSICO

Se suele aplicar en los desarrollos de productos pequeños/medios, desarrollados por personal de la propia empresa en modo orgánico. Aunque también puede aplicarse al resto de los modos. Las ecuaciones de estimación de esfuerzo y tiempo de desarrollo para cada modo de desarrollo: □

Modo orgánico

MM = 2.4 (KDSI) 1.05 TDEV = 2.5 (MM) 0.38 □

Modo semiacoplado

MM = 3.0 (KDSI) 1.12 TDEV = 2.5 (MM) 0.35 □

Modo empotrado

MM = 3.6 (KDSI) 1.2 TDEV = 2.5 (MM) 0.32 donde: KDSI = Kilo-instrucciones fuente suministradas mm = Meses x hombre TDEV = Tiempo de desarrollo en meses Un resumen de las características comparativas de los modos orgánico, semiacoplado y empotrado se presenta en la tabla siguiente:






FIG-21. Características comparativas de los modos orgánico, semiacoplado y empotrado La mayor limitación del modelo básico es que no incorpora el efecto de los factores, como la experiencia de los recursos por ejemplo; que influyen sobre el coste ni el mantenimiento del producto. Las diferencias entre los tres modos orgánico, semiacoplado y empotrado, lógicamente se traducen en diferencias considerables en lo que respecta a la distribución del esfuerzo y la duración entre las diferentes fases del proyecto. Si comparamos el modo empotrado con el orgánico, las principales diferencias son las siguientes: □

En el modo empotrado se consume considerablemente mas esfuerzo en la fase de integración y pruebas. Ello es consecuencia de la necesidad de seguir y comprobar los requisitos del logical y las especificaciones de interfaz más cuidadosamente en los modos empotrado y semiacoplado.

□

En el modo empotrado se consumen proporcionalmente menos esfuerzos en la fase de codificación y pruebas unitarias. Esto resulta de la necesidad de dedicar más esfuerzo en términos proporcionales a las otras fases.

□

En el modo empotrado se consume notablemente más plazo en las fases de planificación y requisitos y de diseño del sistema, a causa de la necesidad de unos requisitos y especificaciones de diseño más completos y validados, y de hacer esto con un número relativamente reducido de personas.

□

En el modo empotrado se consume considerablemente menos plazo en la fase de programación, a consecuencia de la estrategia que se adopta de tener a muchos programadores trabajando en paralelo para reducir la duración total del proyecto.

En las tablas siguientes se presenta la distribución por fases del esfuerzo y la duración para los tres modos, y según el tamaño del proyecto.






FIG-22. Distribución por fases del esfuerzo y la duración - Modo orgánico.

FIG-23. Distribución por fases del esfuerzo y la duración - Modo semiacoplado.






FIG-24. Distribución por fases del esfuerzo y la duración - Modo empotrado.

8.2.

MODELO COCOMO INTERMEDIO

El modelo intermedio incorpora 15 variables de predicción que influyen en el coste del proyecto. Estas variables se agrupan en cuatro categorías: atributos del producto software, atributos del ordenador, atributos de personal y atributos del proyecto. Estas 15 variables explicativas son las que se relacionan a continuación agrupadas por categorías. □

□

□

□

Atributos del Producto à

Fiabilidad requerida del logical (RELY)

à

Tamaño de la base de datos (DATA)

à

Complejidad del producto

Atributos del Ordenador à

Restricciones de tiempo de ejecución (TIME)

à

Restricciones de Memoria principal (STOR)

à

Volatilidad de la máquina virtual (VIRT)

à

Tiempo de respuesta del ordenador (TURN)

Atributos del personal à

Capacidad de análisis (ACAP)

à

Experiencia en la aplicación (AEXP)

à

Capacidad de programación (PCAP)

à

Experiencia en la máquina virtual (VEXP)

à

Experiencia en el lenguaje de programción (LEXP)

Atributos del proyecto






à

Prácticas de programación modernas (MODP)

à

Uso de herramientas “software” (TOOL)

à

Planificación temporal del desarrollo exigido (SCED)

Estas 15 variables van a influir sobre la estimación de esfuerzo calculada. El esfuerzo calculado se ajusta multiplicándolo por el resultado de multiplicar entre sí los valores obtenidos de las tablas de atributos en función de los valores identificados en la definición del proyecto. La siguiente tabla muestra los multiplicadores de esfuerzos, donde la primera columna muestra las variables y las restantes el multiplicador a considerar para cada rango de valores desde Muy Bajo hasta Extra Alto.

FIG-25. Multiplicadores de esfuerzos La estimación de esfuerzo aplicando este modelo es: □

Modo Orgánico:

MM= 3.2. (KDSI)1,05 □

Modo Semilibre:

MM = 3.0 (KDSI)1,12 □

Modo Rígido:

MM = 2.8 (KDSI) 1,20 El tiempo de desarrollo TDEV se calcula como en el Modelo Básico.

8.2.

MODELO COCOMO AVANZADO

El Modelo Intermedio tiene dos limitaciones que pueden ser significativas en la estimación detallada de coste en grandes proyectos de software:






□

La distribución de esfuerzo por fases puede ser inadecuada.

□

Puede ser muy engorroso utilizarlo en un producto con muchos componentes.

El modelo avanzado presenta dos funcionalidades que resuelven las limitaciones de COCOMO intermedio:

9.

□

Multiplicadores de esfuerzo por fases: En el modelo COCOMO Intermedio, la distribución de esfuerzo por fase se determina únicamente por el tamaño del producto. En la práctica, factores como la fiabilidad requerida, la experiencia en aplicaciones y desarrollos interactivos afectan a unas fases más que a otras. El modelo avanzado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo en cada fase. Estos multiplicadores determinan el esfuerzo requerido para completar cada fase.

□

Descomposición jerárquica del producto a tres niveles. En el COCOMO Intermedio, los factores de ajuste del coste se calculaban para distintos componentes del producto. Este proceso puede ser muy tedioso e innecesariamente repetitivo si ciertos componentes son agrupados en subsistemas con prácticamente el mismo factor de ajuste. El COCOMO avanzado evita este problema proporcionando una jerarquizaron del producto a tres niveles: à

El Nivel modulo se describe por el número de instrucciones (DSI) producidas y por aquellos factores que tienden a modificar dicho nivel: Complejidad del módulo y adaptación a partir del software existente y de la capacidad y experiencia de los programadores que desarrollarán el módulo en el lenguaje y en la máquina virtual.

à

El Nivel subsistema queda descrito por los restantes factores (limitaciones en tiempo y memoria, capacidad de los analistas, herramientas, planificación etc.) que tienden a variar de un subsistema a otro, pero que son iguales para todos los módulos dentro de un subsistema.

à

El Nivel sistema se define mediante los factores correspondientes al conjunto del proyecto, como son el esfuerzo nominal y la planificación de tiempos. No se desarrolla este modelo dado que su aplicación queda reservada a grandes proyectos no muy frecuentes. El desarrollo completo de este modelo puede estudiarse en el libro "Software Engineering Economics" de B. Boehm, editorial Prentice Hall, 1981.

MODELO COCOMO II

Boehm, Clark, Horowitz, Westland, Madachy, and Selby [BOEHMN et al, 1995] reconocieron las limitaciones del modelo COCOMO 81, los beneficios de la utilización del análisis FPA y la importancia de poder realizar estimaciones precisas sobre las nuevas metodologías de desarrollo que existen hoy en día. Debido a ello apareció el nuevo modelo COCOMO II, resultado de la adaptación del modelo original de Boehm a las características y necesidades de los procesos de desarrollo software actuales. Al igual que el modelo COCOMO 81 comentado antes, COCOMO II está dividido en otros tres modelos distintos: □

El modelo de Composición de la Aplicación. Contempla las características de los proyectos software en los que se han utilizado las nuevas herramientas de desarrollo (sobre todo las orientadas a la construcción de interfaces gráficos). Se basa en lo que se ha dado en llamar Puntos Objeto.

□

El modelo de Diseño Preliminar. Permitirá la estimación de costes y duración de proyectos antes de haber determinado completamente su estructura (es decir, es de aplicación en las primeras etapas del ciclo de desarrollo). Utiliza un nuevo conjunto de atributos conductores de costes, y para él se definen nuevas ecuaciones para estimación. Se basa en las métricas de Puntos Función no Ajustados y en las Kilo–líneas de código fuente (KSLOC).

□

El modelo de Post-Arquitectura. Se trata del modelo más detallado de COCOMO II. Es de aplicación una vez que la arquitectura del sistema empieza a tomar forma (durante las fases de diseño). Incorpora nuevas ecuaciones y nuevos atributos conductores de costes.






Los objetivos de este modelo son: □

Desarrollar un modelo de estimación de costes y tiempos en consonancia con las prácticas actuales de ciclo de vida del software.

□

Construir una base de datos y una herramienta de costes del software que incluya capacidades para la mejora continua del modelo.

□

Proveer un marco analítico cuantitativo, y un conjunto de herramientas y técnicas para evaluar los efectos de las mejoras en la tecnología software sobre los costes y tiempos del ciclo de vida del software.

Estos objetivos intentan satisfacer las necesidades de los ingenieros del software: Soportar planificación de proyectos, previsión de personal, estimaciones a la conclusión, preparación de proyectos, replanificación, rastreo de proyectos, negociación de contratos, evaluación de propuestas, nivelación de recursos, evaluación de diseños, etc.

9.1.

LOS PUNTOS OBJETO COMO MEDIDA DEL TAMAÑO FUNCIONAL

La estimación con Puntos Objeto es una técnica relativamente nueva, cuyo campo de aplicación es doble: □

Por una parte, es útil en aquellas aplicaciones que puede desarrollarse con un alto componente de reutilización de software, es decir, como si se tratara de tomar componentes ya desarrollados y, al estilo de un puzzle, ensamblarlos y adaptarlos hasta conformar la nueva aplicación. Es lo que se ha dado en llamar Composición o Ensamblaje de Aplicaciones.

□

Por otra parte, es útil también en aplicaciones desarrolladas por herramientas RAD (Rapad Application Development), las cuales generan automáticamente (y con el mínimo esfuerzo), todo tipo de componentes software para el sistema que se está desarrollando (interfaces gráficos, prototipos operativos, etc...).

Según esto, los Puntos Objeto serán una métrica del tamaño funcional de una aplicación software, en función del número de pantallas generadas, informes producidos y, en general, cualquier módulo generado por sistemas automáticos de desarrollo (RAD) que haya sido integrado en la aplicación. Al igual que sucedía con los Puntos Función, los Puntos Objeto podrán utilizarse también para estimar el esfuerzo de desarrollo de una aplicación concreta, perteneciente al ámbito de la Composición o Ensamblaje de Aplicaciones. El proceso a seguir para la estimación en Puntos Objeto tiene cierta similitud con el proceso de conteo de Puntos Función, sólo que se tiene en cuenta un factor adicional: el % de componentes reutilizados que integrarán la aplicación, es decir, qué % de los componentes serán tomados de aplicaciones previamente desarrolladas. Este será el factor de ajuste para el conteo de Puntos Objeto, de igual manera que lo era el VAF para el conteo de Puntos Función. Antes de comentar los cinco pasos de que consta el proceso de conteo de Puntos Objeto, mostraremos el significado de la terminología utilizada: □

NOP: (New Object Points). Es el número total de Puntos Objeto Ajustados.

□

srvr: Es el número de tablas de datos del servidor (mainframe o equivalente) utilizadas por las pantallas de interfaz o por los informes (reports) generados por la aplicación.

□

clnt: Es el número de tablas de datos del cliente (ordenador personal o estación de trabajo) utilizadas por las pantallas de interfaz o por los informes (reports) generados por la aplicación.

□

%r: Es el porcentaje de pantallas, informes y módulos 3GL7 que han sido reutilizados, es decir, que provienen de otras aplicaciones previamente desarrolladas.






Los cinco pasos para el conteo de Puntos Objeto son los siguientes:

9.2.

PASO 1: CONTABILIZACIÓN DE OBJETOS.

En este primer paso de deberán contar los objetos del sistema que resultan de interés para la estimación, es decir, pantallas de interfaz, informes (reports) y módulos desarrollados en lenguajes 3GL. Por lo tanto, el concepto de objeto en el modelo COCOMO II no tiene porqué estar necesariamente relacionado con el concepto de objeto de la Programación Orientada a Objetos.

9.3.

PASO 2: CLASIFICACIÓN DE LOS OBJETOS.

Los objetos identificados en el Paso 1 deberán clasificarse en cuanto a su nivel de complejidad. Existen 3 niveles posibles: complejidad baja, media y alta en función, principalmente, de los atributos srvr y clnt comentados anteriormente. La siguiente tabla indica cómo han de clasificarse los objetos:

FIG-26. Clasificación de los objetos del sistema (pantallas de interfaz e informes). Como vemos, la tabla anterior sólo clasifica a las pantallas de interfaz y a los informes (reports), Los módulos desarrollados en lenguajes 3GL se considerarán siempre de complejidad Alta.

9.4.

PASO 3: ASIGNACIÓN DE PESOS A LOS OBJETOS DEL SISTEMA.

A cada objeto del sistema, una vez clasificado, hay que asignarle un valor concreto en Puntos Objeto (peso) que representará el esfuerzo requerido para su implementación. Los valores propuestos por el modelo COCOMO II son los que se muestran en la tabla siguiente:

FIG-27. Pesos (en Puntos Objeto), en función de la complejidad de los objetos del sistema.






9.5.

PASO 4: CÁLCULO DEL NÚMERO TOTAL DE PUNTOS OBJETO SIN AJUSTAR.

El número total de Puntos Objeto sin Ajustar (POsA) será la suma de todos los Puntos Objeto asignados a cada uno de los componentes del sistema (POi), es decir:

9.6.

PASO 5: CÁLCULO DEL NÚMERO TOTAL DE PUNTOS OBJETO AJUSTADOS

Para calcular el número total de Puntos Objeto Ajustados (POA), deberemos multiplicar el número total de Puntos Objeto sin Ajustar (POsA) por el % de componentes reutilizados que se espera incorporar al sistema (%r). El resultado obtendio (POA) también se conoce con el nombre de NOP (New Object Points), y representa el tamaño funcional de la aplicación en estudio.

Una extensión del modelo COCOMO II nos permitirá, incluso, determinar ratios de productividad tomando en consideración tanto las posibilidades de la aplicación RAD utilizada, como la experiencia y capacidades del equipo de desarrollo de la aplicación. Se utiliza la siguiente ecuación:

...obteniéndose el esfuerzo de desarrollo en Personas-Mes. PROD representa la productividad del equipo de desarrollo y del entorno, y se obtiene la siguiente tabla:

FIG-28. Ratios de productividad según equipo y entorno de desarrollo.

10. CONCLUSIÓN La estimación de los parámetros del software es una tarea fundamental en la gestión del proyecto, aunque históricamente no se ha tratado así y hemos aceptado como algo natural las desviaciones y atrasos en los proyectos. El aumento de los costes de desarrollo ha obligado a los gestores a poner más atención en las tareas de estimación. Sobre todo la estimación de los parámetros económicamente sensibles, tales como el tamaño del código, el número de personas que componen el equipo de desarrollo y el tiempo necesario para finalizar el proyecto. La estimación de proyectos lleva consigo una problemática asociada a su propia definición. Llamamos estimación al conjunto de valores para algo que vamos a hacer. De esto surgen las preguntas básicas ¿Cuánto costará y cuánto tardaremos? El proceso de estimación es algo vivo durante todo el proyecto, al principio se cuenta con pocos valores que permitan una estimación fiable, conforme avanza el proyecto el número de factores aumenta progresivamente, lo que nos permitirá afinar la estimación.






Al realizar la estimación tenemos que tener en cuenta lo que pretendemos conseguir, es decir, no solamente el número de horas que necesitaremos para realizar el proyecto, es necesario conocer también muchos otros valores, como por ejemplo número de recursos, perfiles de los mismos, etc. Toda esta información formará parte de la documentación que genera el proceso de estimación. Existen varias técnicas de estimación, algunas basadas simplemente en la opinión y conocimientos de una serie de personas, otras basadas en la historicidad y otras, las más fiables, basadas en algoritmos matemáticos y análisis del propio proyecto, que nos darán una idea más certera del coste del mismo. Depende del método de estimación que escojamos tendremos un resultado más o menos fiable. Al momento de elegir el método, es importante tener en cuenta una serie de consideraciones que definen la calidad del método de estimación. Es importante que el método esté implantado de forma correcta y completa en la organización y forme parte de la metodología de desarrollo de Sw. El objetivo principal de la estimación es tener claro el dimensionamiento del proyecto, conocer el mayor número de valores posibles que afectan a dicha dimensión, esto nos permitirá tener un buen mecanismo de toma de decisiones relativas al mismo. Los métodos de estimación están evolucionando continuamente. Aquí se han abordado algunos de los más conocidos, que son los métodos algorítmicos. Sin embargo se está trabajando mucho actualmente en los métodos del tipo no-algorítmicos, basados en técnicas de inteligencia artificial y más concretamente de aprendizaje máquina. De este modo aparecen métodos que emplean lógica difusa, razonamiento basado en casos o redes neuronales, por citar algunos. Y todos persiguen un único fin común: la calidad de la estimación.

11. BIBLIOGRAFÍA □

Connell, S. Desarrollo y Gestión de Proyectos Informáticos. McGraw-Hill Interamericana. España 1997.

□

Pressman, R.S., Ingeniería del Software. Un enfoque práctico, Mc Graw Hill, 2001.

□

Fergus O'Connell. "How to run successful projects". Prentice Hall, 1994. (Biblioteca UPV)

□

Metzger, P. Boddie, J. “Managing a programming project: people and processes” 3 ed. Prentice Hall, 1996.

□

Thomsett, R. “Third Wave Project Management”. Prentice Hall, 1993. (Biblioteca UPV)

□

Yourdon, Edward. Análisis Estructurado Moderno. Prentice Hall, 1993. (Biblioteca UPV)

□

Dreger, J.B. "Function Point Analysis", Prentice Hall, 1989. (Biblioteca UPV).






12. ESQUEMA – RESUMEN Como hemos podido ver la estimación se define como el proceso que proporciona un valor a un conjunto de variables para la realización de un trabajo, dentro de un rango aceptable de tolerancia. Podemos definirlo también como la predicción de personal, del esfuerzo, de los costes y de la planificación que se requerirá para realizar todas las actividades y construir todos los productos asociados con el proyecto. Uno de los parámetros críticos de la estimación es determinar su exactitud. La estimación puede realizarse a partir de datos históricos o con herramientas. Curiosamente, en la actualidad, está ocurriendo algo sorprendente y es que algunas herramientas actualmente existentes proporcionan una estimación más exacta que la obtenida por la empresa a partir de sus datos históricos. Larry Putnam ha apuntado que la gestión del desarrollo de software considera la estimación como una actividad que permite obtener, principalmente, respuestas aproximadas a las siguientes preguntas: ¿Cuánto costará? ¿Cuánto tiempo llevará hacerlo? Por otra parte existe una problemática bastante fuerte en el proceso de estimación de software debido a diversos factores. ¿Cuándo se debe realizar la estimación de un proyecto software? La estimación, como ya hemos dicho, es un proceso continuo. A medida que el proyecto avanza, más se conoce de él, y por lo tanto más parámetros están disponibles para introducir en un modelo de estimación. La estimación continua nos permite el uso de un único modelo coherente que pueda capturar y utilizar la información sobre el proyecto a medida que este se conozca. Más precisamente, el proceso de estimación comienza usando unas pocas variables claves para proveer las "macro-características" de un proyecto, y evoluciona incorporando información de más bajo nivel para producir las "micro-características" del proyecto. Para la estimación, existen cuatro técnicas básicas y comunes: □

La opinión de los expertos; Esta técnica se basa en la experiencia profesional de los participantes en el proyecto de estimación.

□

La analogía; Es una aproximación más formal que la experiencia de los expertos y se basa en la comparación directa de uno o más proyectos pasados. La estimación inicial se ajusta dependiendo de las diferencias entre el proyecto pasado y el nuevo.

□

La descomposición; Consiste en la descomposición de un producto en componentes más pequeños, o descomponer un proyecto en tareas de nivel inferior. La estimación se hace a partir del esfuerzo requerido para producir los componentes más pequeños o para realizar las tareas de nivel inferior. La estimación global del proyecto resultará de sumar las estimaciones de los componentes.

□

Las ecuaciones de estimación; Son fórmulas matemáticas que establecen la relación de algunas medidas de entrada (que normalmente es la medida del tamaño del producto) y determinan el esfuerzo que se requerirá.

Los objetivos de la estimación de proyectos son reducir los costes e incrementar los niveles de servicio y de calidad. □

Midiendo determinados aspectos del proceso de software se puede tener una visión de alto nivel de lo que sucederá durante el desarrollo.

□

Las mediciones de procesos anteriores permiten realizar predicciones sobre los actuales.

□

Las mediciones de atributos de proceso en fases iniciales del desarrollo permiten realizar predicciones sobre fases posteriores.






□

Las predicciones de proceso conducen la toma de decisiones antes del comienzo del desarrollo, durante el

□

proceso de desarrollo, durante la transición del producto al cliente y a lo largo de la fase de mantenimiento.

Un método de estimación eficaz permitirá ignorar aspectos sin interés y concentrare en los aspectos esenciales. Un buen modelo debería poseer capacidades predictivas, mejor que ser meramente descriptivo o explicativo. La validez de las métricas de software y de los modelos de estimación debe ser establecida demostrando la coincidencia entre los datos empíricos y los experimentales. Esto requiere una cuidadosa atención en la toma de medidas y en el análisis de los datos. Veamos algunos de estos métodos de estimación: □

Método de la suma de las tareas. Normalmente se suele confundir el esfuerzo necesario para desarrollar una tarea (meses/hombre) con el tiempo necesario para llevar a cabo la misma. Una tarea que tenga asignado un esfuerzo de 10 días, puede llevarse a cabo en el plazo de 5 semanas, aplicando un esfuerzo de 2 días a la semana. También nos podemos encontrar con el caso contrario en que una tarea que necesita el esfuerzo de 10 días se lleve a cabo en una semana, empleando a dos personas a tiempo completo en su ejecución. El esfuerzo aplicado puede verse afectado por interferencias externas.

□

Regla “3 Veces Programación”. Consiste básicamente en realizar la estimación del número de módulos de software o programas y su complejidad. Estimar el esfuerzo requerido para completar la codificación y la compilación de cada módulo y el esfuerzo total de la programación y multiplicarlo por 3

□

Modelo de líneas de Código. La medida más utilizada de la longitud del código fuente de un programa es el Número de Líneas de Código (Lines of Code en ingles, abreviado LOC). Sin embargo, esta métrica puede calcularse de muchas maneras. Estas diferencias afectan al tratamiento de las líneas en blanco y las líneas de comentarios, las sentencias no ejecutables, las instrucciones múltiples por línea y las múltiples líneas por instrucción. Además, deberían contarse las líneas reusables de código. La definición más común es la siguiente: Una línea de código es cualquier línea de un texto de un programa que no es un comentario o línea en blanco, sin tener en cuenta el número de instrucciones o parte de instrucciones en la línea.

□

Modelo de puntos Funcionales. Los Puntos de Función miden el software cualificando la funcionalidad que proporciona externamente, basándose en el diseño lógico del sistema. Por lo tanto, en el caso de subsistemas diseñados independientemente los Puntos de Función se calcularán para cada una de ellas, y luego se sumarán. Los objetivos de los Puntos de Función son: à

Medir lo que el usuario pide y lo que el usuario recibe.

à

Medir independientemente de la tecnología utilizada en la implantación del sistema.

à

Proporcionar una métrica de tamaño que dé soporte al análisis de la calidad y la productividad.

à

Proporcionar un medio para la estimación del software.

à

Proporcionar un factor de normalización para la comparación de distintos software.

Además de estos objetivos, el proceso de contabilizar los Puntos de Función debería ser: à

Suficientemente simple como para minimizar la carga de trabajo de los procesos de medida.






à

Conciso en sus resultados.

El análisis de los Puntos de Función se desarrolla considerando cinco parámetros básicos externos del Sistema: à

Entrada (EI, del inglés External Input).

à

Salida (EO, del inglés External Output).

à

Consultas (EQ, del inglés External Query).

à

Grupos de datos lógicos internos (ILF, del inglés Internal Logic File).

à

Grupos de datos lógicos externos (EIF, del inglés External Interface File).

La aplicación de la técnica de los Puntos de Función comprende los siguientes pasos: à

Definición de los límites del sistema. El límite es utilizado para definir el alcance del sistema y ayudar a identificar los parámetros externos.

à

Definición de parámetros. Para poder determinar la existencia de los componentes que contribuirán al total final, hay que definirlos previamente. La definición que vamos a considerar aquí es la realizada por IFPUG en 1994, última versión. Estos componentes pueden ser clasificados como Tipos de Funciones y son de dos clases: Datos o Transacciones.

à

Valoración de la complejidad. Se deben clasificar los diferentes elementos de función y asignarles pesos. Así por ejemplo una entrada que contenga 10 atributos y que en su lógica se requiera acceder a un fichero diremos que se clasifica de complejidad baja y tiene asociados tres puntos de función.

à

Análisis de las características generales del sistema. Existen características externas que no hemos contemplado, así como características del proceso de desarrollo del sistema informático que influirán en el coste del sistema y que podemos cuantificar desde las primeras fases del desarrollo. Estos factores adicionales según Albrecht son catorce. Cada factor tomará un valor entre 0 y 5, de modo que cuanta más importancia tenga un factor mayor valor se le asignará.

Comunicación de Datos.

Proceso Distribuido.

Objetivos de Rendimiento.

Configuración de Explotación Usada intensamente por Otros Sistemas.

Tasa de Transacciones.

Entrada de Datos EN-LÍNEA.

Eficiencia con el Usuario Final.

Actualizaciones EN-LÍNEA.

Lógica de Proceso Interno Compleja.

Reusabilidad del Código.

Contempla la Conversión e Instalación.

Facilidad de Operación.

Instalaciones Múltiples

Facilidad de Cambios

MODELO COCOMO 81 Modelo Constructivo de Coste (COCOMO), se define como una jerarquía de modelos de estimación para el software. Su adaptación a las nuevas metodologías de desarrollo y la posibilidad de utilizarlo prácticamente en






cualquiera de las etapas del ciclo de de vida del software (incluidas las primeras etapas, como modelo de estimación de la funcionalidad y el esfuerzo de desarrollo), hará que el modelo COCOMO se convierta en uno de los más populares y utilizados a lo largo de todo el mundo. La jerarquía de modelos propuesta por Boehm en 1981, consta de los 3 siguientes: □

El modelo COCOMO básico.

□

El modelo COCOMO intermedio.

□

El modelo COCOMO avanzado.

Además, Boehm clasifica los proyectos software en tres tipos distintos: □

De tipo Orgánico, que son proyectos software relativamente pequeños y sencillos, y similares a otros ya desarrollados anteriormente.

□

De tipo Semi-Acoplado, que son proyectos software intermedios en tamaño y en complejidad.

□

De tipo Empotrado, que son proyectos software que deberán ser desarrollados en un entorno muy restringido de hardware, software y restricciones operativas.

EL MODELO COCOMO BÁSICO Se suele aplicar en los desarrollos de productos pequeños/medios, desarrollados por personal de la propia empresa en modo orgánico. Aunque también puede aplicarse al resto de los modos. Las ecuaciones de estimación de esfuerzo y tiempo de desarrollo para cada modo de desarrollo: □

Modo orgánico

MM = 2.4 (KDSI) 1.05 TDEV = 2.5 (MM) 0.38 □

Modo semiacoplado

MM = 3.0 (KDSI) 1.12 TDEV = 2.5 (MM) 0.35 □

Modo empotrado

MM = 3.6 (KDSI) 1.2 TDEV = 2.5 (MM) 0.32 donde: KDSI = Kilo-instrucciones fuente suministradas mm = Meses x hombre TDEV = Tiempo de desarrollo en meses EL MODELO COCOMO INTERMEDIO El modelo intermedio incorpora 15 variables de predicción que influyen en el coste del proyecto. Estas variables se agrupan en cuatro categorías: atributos del producto software, atributos del ordenador, atributos de personal y atributos del proyecto. Estas 15 variables van a influir sobre la estimación de esfuerzo calculada. El esfuerzo calculado se ajusta multiplicándolo por el resultado de multiplicar entre sí los valores obtenidos de las tablas de atributos en función de los valores identificados en la definición del proyecto. La estimación de esfuerzo aplicando este modelo es:






□

Modo Orgánico:

MM= 3.2. (KDSI)1,05 □

Modo Semilibre:

MM = 3.0 (KDSI)1,12 □

Modo Rígido:

MM = 2.8 (KDSI) 1,20 El tiempo de desarrollo TDEV se calcula como en el Modelo Básico. EL MODELO COCOMO AVANZADO El modelo avanzado presenta dos funcionalidades que resuelven las limitaciones de COCOMO intermedio: □

Multiplicadores de esfuerzo por fases

□

Descomposición jerárquica del producto a tres niveles. à

El Nivel modulo.

à

El Nivel subsistema

à

El Nivel sistema

MODELO COCOMO II. Es el resultado de la adaptación del modelo original de Boehm (COCOMO 81) a las características y necesidades de los procesos de desarrollo software actuales. Al igual que el modelo COCOMO 81 comentado antes, COCOMO II está dividido en otros tres modelos distintos: □

El modelo de Composición de la Aplicación.

□

El modelo de Diseño Preliminar.

□

El modelo de Post-Arquitectura.

La estimación con Puntos Objeto es una técnica relativamente nueva, cuyo campo de aplicación es doble: □

Por una parte, es útil en aquellas aplicaciones que puede desarrollarse con un alto componente de reutilización de software, es decir, como si se tratara de tomar componentes ya desarrollados y, al estilo de un puzzle, ensamblarlos y adaptarlos hasta conformar la nueva aplicación. Es lo que se ha dado en llamar Composición o Ensamblaje de Aplicaciones.

□

Por otra parte, es útil también en aplicaciones desarrolladas por herramientas RAD (Rapad Application Development), las cuales generan automáticamente (y con el mínimo esfuerzo), todo tipo de componentes software para el sistema que se está desarrollando (interfaces gráficos, prototipos operativos, etc...).

Los cinco pasos para el conteo de Puntos Objeto son los siguientes: □

Paso 1: Contabilización de objetos.

□

Paso 2: Clasificación de los objetos.

□

Paso 3: Asignación de pesos a los objetos del sistema.






□

Paso 4: Cálculo del número total de Puntos Objeto sin Ajustar.

□

Paso 5: Cálculo del número total de Puntos Objeto Ajustados



TICB2 - Tecnicas de Estimacion de Esfuerzo

Recommend Documents