modelo cocomo

Jorge Salamanca Escorial 1

CALIDAD DEL SOFTWARE TEMA 3

• Actualmente, el desarrollo y mantenimiento del software se concibe mediante un enfoque basado en los procesos.• Se asume que se debe controlar o supervisar la cantidad de incidencias, fallos, defectos y cambios durante el desarrollo y explotación del sistema.• Estos valores permiten que los gestores de proyecto puedan conocer cuál es el estado de los productos que se van generando.• Lo habitual es que estos datos procedan de las actividades de aseguramiento de calidad del software realizadas durante el proyecto.• Habitualmente, los datos sobre problemas en los productos que se generan durante los proyectos de sw. se relacionan con los procesos que han dado lugar a dichos productos.• De esta manera, se intenta caracterizar los procesos a través de los resultados o salidas que obtienen.

Medidas del proceso



• Por otra parte, también es necesario medir atributos específicos de los propios procesos, como el tiempo empleado, su coste y el esfuerzo requerido.• La relación entre las medidas de los resultados obtenidos en unproceso y los recursos usados en él permitirá medir la productividad.• Éste es un atributo por el que existe un gran interés en la industria del sw. ya que es clave para estimar el coste y el esfuerzo de los proyectos.

Medidas del proceso



Modelos de estimación• La estimación es el proceso de predicción de la duración, esfuerzosy costes necesarios para realizar todas las actividades y obtener todos los productos asociados a un proyecto.• Se hace necesario tener en cuenta multitud de aspectos que afectan a la estimación como son la complejidad del proyecto, su estructuración, el tamaño, los recursos involucrados y los riesgos asociados.• La estimación es siempre difícil de realizar por diversas razones:

– No existe un modelo ni una fórmula de estimación universal.– Son muchas las personas implicadas en el proyecto, desde la alta dirección de la empresa a los ejecutivos del proyecto, que precisan de las estimaciones.– La utilidad de una estimación varia con la etapa de desarrollo en que se encuentra el proyecto.– Las estimaciones precisas son difíciles de formular, sobre todo al inicio del proyecto.

Medidas del proceso


CALIDAD DEL SOFTWARE TEMA 3Medidas del proceso• La estimación es siempre difícil de realizar por diversas razones: (cont.)

– La estimación suele hacerse superficialmente, sin tener en cuenta el esfuerzo necesario para hacer el trabajo.– La rapidez del cambio de las metodologías y las tecnologías no permiten la estabilización del proceso de estimación.– Los estimadores pueden no tener experiencias sobre aquello que pretenden estimar.– Es estimador suele hacer la estimación en función del tiempo que a él le llevaría en realizar el trabajo, sin tener en cuenta la experiencia y formación de la persona que realmente lo realiza.– Existen malas interpretaciones en las relaciones lineales entre la capacidad requerida por unidad de tiempo y el tiempo disponible. Como consecuencia se cumple una de las leyes de Murphy, “la duración del trabajo se ajustará como mínimo al tiempo disponible. Añadir recursos a un proyecto retrasado, no tiene que disminuir el retraso”.– El estimador tiende a reducir en alguna medida sus estimaciones para hacer más aceptable su oferta.

Modelos de estimación



Modelos de estimación• Además de los métodos algorítmicos, se suelen utilizar por sus sencillez los siguientes:

– El juicio del experto– La analogía– La ley de Parkinson– La mejor oferta– Las estimaciones global y detallada

Medidas del proceso



– El juicio del expertoEn gran parte de los proyectos Sw, en el momento de estimar el coste de los desarrollos, se observa que el método utilizado se basa principalmente en juicios emitidos por uno o varios expertos avalados por su experiencia en entornos similares y apoyados, en algunos casos, en datos objetivos obtenidos de proyectos anteriores y almacenados.El método de Wideband Delphi es una aproximación que se puede definir como un protocolo multipaso cuyo fin es hacer coincidir la opinión de un grupo de expertos evitando así estimaciones parciales de individuos aislados.

Modelos de estimaciónMedidas del proceso



– El juicio del expertoLos pasos dentro del método de Wideband Delphi son:

• El coordinador del equipo técnico de expertos presenta a cada uno de ellos una especificación de estimación.• El coordinador convoca una reunión con el grupo de expertos para que se produzca un intercambio de opiniones entre ellos sobre el producto y sus estimaciones.• Cada experto aporta su estimación.• El coordinador remite a cada experto un informe con el valor medio de las estimaciones obtenidas así como el valor propuesto por cada individuo.• Se convoca una segunda reunión entre expertos donde se discuten el valor medio obtenido, así como los valores propuestos.• Los expertos vuelven a emitir sus estimaciones de forma independiente.• Se repiten los pasos 2 al 6 hasta la obtención de un valor en el que los expertos estén de acuerdo.




– El juicio del expertoEste método tiene como desventaja evidente el alto coste en tiempo y recursos humanos necesarios para su implantación, así como la subordinación al nivel de experiencia y conocimientos en el entorno que puedan aportar los técnicos.Como ventajas se podrían indicar que las estimaciones parciales son neutralizadas y se presenta un estimación global.Por otro lado las estimaciones suministradas por este grupo de expertos difícilmente pueden ser obviadas gracias a la trascendencia que la organización otorga a este proceso al proporcionar costosos recuros a esta tarea.




• Además de los métodos algorítmicos, se suelen utilizar por sus sencillez los siguientes:

– La analogíaSe hace la estimación de un proyecto nuevo por analogía con las estimaciones de proyectos anteriores comparables y que estén terminados.Como ventajas citaremos el menor coste en tiempo y recursos que el método del juicio del experto.Como desventajas cabría citar que las estimaciones de proyectos anteriores no siempre se ajustan a nuevos proyectos, ya que muchos de los factores de estas estimaciones no siempre se mantienen.º





– La ley de ParkinsonC.N. Parkinson formuló en 1987 unas leyes que, reformuladas, se pueden aplicar a la Ing. del Sw.Una de estas leyes dice: “los programas son como los gases perfectos, ocupan todo el espacio que se les da”.Esto significa que la estimación del esfuerzo se hace en base a los recursos disponibles y no al producto.– La mejor ofertaSe procura conocer hasta cuánto el cliente está dispuesto a pagar y cuales son las ofertas de la competencia. El valor que permite lograr el proyecto se toma como estimación del esfuerzo.





– Las estimaciones global y detalladaLa estimación global, también llamada descendente, se hace teniendo en cuenta las funcionalidades del producto, pasándose posteriormente al detalle.La estimación detallada o ascendente empieza por la estimación de los esfuerzo individuales, los cuales se suman para obtener el esfuerzo del proyecto.




• La reglas de estimación de De MarcoDe Marco formuló las siguientes nueve reglas, relativas a la estimación:

– Estimar no es repetir (vs. Analogía)– Estimar no es negociar (vs. mejor oferta)– Las estimaciones no admiten regateo– Estimar no es dividir en partes una duración fija– Un retraso en una fase de un proyecto implica un retraso proporcional en todas las fases siguientes.– Si desea que se le proporcione una estimación significativa, no sugiera la respuesta.– Una estimación útil es una proyección en la que la probabilidad no es optimista ni pesismista.– El ratio entre la estimación más optimista y la útil es medianamente uniforme a cualquier persona.– Las estimaciones deben formularlas un comité.




Estimación de costes y esfuerzo

• Si consideramos que el soporte informático es una actividad estratégica de primer orden en la sociedad actual, no es extraño que el cumplimiento de plazos y costes sea una exigencia inevitable en el proceso de creación de Sw.• El conocimiento de costes y esfuerzos futuros permite prever laasignación de recursos adecuándolos a las necesidades venideras.• Parece evidente que estimar, es decir, conocer cuál será el valor de cierta magnitud, no es una tarea simple, ya que numerosos factores de distinta naturaleza están presentes.• Sin embargo, esta necesidad por prever datos futuros, ha permitido un cierto desarrollo de métodos y modelos matemáticos.




Estimación de costes y esfuerzo• El coste y el esfuerzo son atributos propios del proceso de desarrollo de Sw. Dependiendo del modelo utilizado para su medida serán necesarios datos de diferente naturaleza.• El esfuerzo se entiende como el tiempo necesario para la realización de una cierta tarea por parte del equipo de desarrollo. (se suele expresar en hombre-mes)• El coste se encuentra directamente relacionado con el esfuerzo de cada tarea aunque en este caso se expresa en términos económicos.




Estimación de costes y esfuerzo• Principales modelosLos modelos matemáticos más importantes en la estimación del coste y esfuerzo son COCOMO, SLIM y Puntos de Función.El modelo COCOMO (COnstructive COst MOdel) fue ideado por Boehm, el modelo SLIM (Software, LIfe Cycle Management) fue creado por Putnam y el modelo Punto Función lo desarrolló Albretch.El modelo COCOMO y el de Puntos de Función pueden encuadrarse en aquellos modelos empíricos dependientes de una variable principal a los que se añaden factores de ajuste relacionados con la productividad. Se denominan modelos estáticos.El modelo SLIM es un modelo dinámico que realiza una repartición del esfuerzo en función del tiempo.





• El modelo permite la estimación del esfuerzo como una medida indirecta del tamaño del código fuente.• Boehm presentó este método en su libro Software EngineeringEconomics [1981]• El modelo de Boehm basa su estimación del esfuerzo en la posibilidad de conocer el tamaño del programa. Es, por tanto, una traslación del proceso predictivo desde un atributo (esfuerzo) a otro (tamaño)• Este modelo fue ideado tras el estudio de 63 proyectos softwarerealizados por el autor.


MODELO COCOMO




• El modelo COCOMO se basa en la existencia de tres niveles que ha de aplicarse según el estado en que se encuentre el desarrollo del proyecto.• Estos tres niveles son:

– Modelo básico– Modelo intermedio– Modelo detallado


MODELO COCOMO




• Modelo básico– Se utiliza al principio del proyecto, para estimaciones de proyecto rápidas y poco precisas.– La información que facilita es una estimación en cuanto al orden de magnitud del esfuerzo.– Las ecuaciones que rigen este modelo son:

E = a (KLOC)b

Donde E es el esfuerzo expresado en personas mes, el número de líneas de código estimadas excluyendo comentarios (en miles) viene indicado por KLOC.Los valores a y b son valores constantes que dependen de la clase o “modo” de proyecto que estemos evaluando.


MODELO COCOMO




• Modelo básico– Las ecuaciones que rigen este modelo son:

T = c E d

Donde T es el número de meses estimados para el desarrollo, E es el valor del esfuerzo calculado en la anterior ecuación.Los valores c y d son valores constantes que dependen de la clase o “modo” de proyecto que estemos evaluando.


MODELO COCOMO




• Modelo básico– Los posibles modos que nos encontramos son:

• Organico (organic): Equipos de trabajo pequeños. Existe un buen conocimiento de la aplicación y del sistema utilizado. Poca influencia de las comunicaciones. Poca innovación técnica y tamaño relativamente pequeño.• Semiacoplado (semidetached): Se sitúan en una posición intermedia en cuanto a complejidad y tamaño, entre el modo orgánico y el Integrado. Equipo formado por expertos y principiantes. Se han de satisfacer requisitos no excesivamente estrictos. Por ejemplo aplicaciones bancarias o que impliquen transacciones con bases de datos.• Integrado (embedded): Sistema hw/sw complejo con influencia clara de la seguridad o tiempo real. Costes de validación muy elevados. Requisitos estrictos e inamovibles. Entorno de gran innovación técnica. El problema a resolver es único y es difícil basarse en experiencias anteriores, puesto que quizá no existan.


MODELO COCOMO




• Modelo básico– La tabla para los valores de las constantes de las ecuaciones de esfuerzo (E) y tiempo (T) en función del “modo” del proyecto es:


MODELO COCOMO

Modo a b c d

Orgánico 2.4 1.05 2.5 0.38

Semiacoplado 3.0 1.12 2.5 0.35

Integrado 3.6 1.20 2.5 0.32




• Modelo intermedio– Se aplica cuando el proyecto ha sido dividido en subsistemas. – En este modelo se han de considerar factores relativos a atributos del producto sw. y de recursos (materiales, métodos y personal)– Los valores de las constantes también se ven afectados.– En este caso la ecuación de esfuerzo que rige este modelo es:

E = a (KLOC)b m(x)

– Donde E, KLOC, a y b tienen el mismo significado que en caso del modelo básico, aunque el valor de a y b es diferente.


MODELO COCOMO




• Modelo intermedio– La tabla para los valores de las constantes de las ecuaciones de esfuerzo (E) para este “modo” de proyecto es:


MODELO COCOMO

Modo a b

Orgánico 3.2 1.05

Semiacoplado 3.0 1.12

Integrado 2.8 1.20



• Modelo intermedio– El valor de m(x) es el peso del factor de coste xj, y cuya expresión matemática es:

m(x) = Π m(xj)

– El valor de m(x) en el caso del modelo básico tiene como valor fijo la unidad.

Estimación de costes y esfuerzoModelos de estimaciónMedidas del proceso

MODELO COCOMO

j=1

15



• Modelo intermedio– Boehm consideró quince factores de coste diferentes, agrupados según el siguiente esquema:

• Atributos del producto– Fiabilidad requerida.– Tamaño de la base de datos.– Complejidad del producto.

• Atributos de los recursos– El material

» Restricciones del rendimiento en tiempo de ejecución» Restricciones de memoria» Inestabilidad de la máquina virtual.» Tiempo de espera requerido.


MODELO COCOMO



• Modelo intermedio– Boehm consideró quince factores de coste diferentes, agrupados según el siguiente esquema:

• Atributos de los recursos– El personal

» Capacidad de análisis.» Capacidad del ingeniero de software.» Experiencia en aplicaciones.» Experiencia con máquina virtual.» Experiencia con lenguaje de programación.

– Métodos y herramientas» Práctica de los métodos modernos de programación.» Utilización de herramientas software.

– Tiempo» Planificación temporal del desarrollo requerida.


MODELO COCOMO



• Modelo intermedio– Cada factor es valorado por separado en una escala ordinal de seis puntos (muy bajo / bajo / nominal / alta / muy alta / extra alta)– A partir de las tablas hechas públicas por Boehm se asigna un valor numérico a cada factor y se aplica la ecuación; el resultado es el factor de ajuste del esfuerzo.


MODELO COCOMO



• Modelo intermedio


MODELO COCOMO



• Modelo detallado– Ideado para determinar las estimaciones en cada fase del proyecto.– Se basa en dividir el esfuerzo en fases, de forma que para cada una de ellas se obtenga el factor de coste correspondiente. Finalmente se ha de sumar cada uno de ellos para obtener el global.– Como guía para el uso del modelo COCOMO, en cualquiera de sus variedades, podemos indicar los siguientes pasos a seguir:

• Identificar el “modo” de desarrollo para el nuevo proyecto.• Estimar el tamaño del proyecto en KLOC y derivar una predicción del esfuerzo.• Determinar el valor de los 15 factores de ajuste.• Calcular y hacer uso de las ecuaciones de estimación del esfuerzo y tiempo de desarrollo.


MODELO COCOMO



• Modelo detallado– Señalaremos que este modelo introduce dos diferencias respecto a los anteriores:

• Los factores de coste se aplican a cada fase del proyecto, ya que algunas fases se ven más afectadas que otras por ellos. El modelo detallado proporciona un conjunto de valores para cada factor de coste.• Se puede aplicar a tres niveles de jerarquía de un producto de software (módulo, sistema y subsitema), agregando resultados según el esquema de descomposición.


MODELO COCOMO



• Para finalizar indicaremos los aspectos a favor y en contra de la utilización de este modelo:

– Pros: • Transparencia del modelo, así como el acierto de los factores definidos para obtener el factor de ajuste.• Uno de los modelos más documentados; correcto con referencia a los 63 proyectos utilizados para su creación.

– Contras:• La selección del modo de desarrollo es extremadamente importante.• Fuertemente dependiente de los datos históricos de la organización, que no siempre están disponibles.• No se puede asumir que sea totalmente válido en todos los entornos y proyectos.


MODELO COCOMO



• El modelo SLIM (Software LIfecycle Model) lo propuso Putnambasándose en su base de datos de proyectos [Putnam, 1978].• Se apoya en el modelo teórico de Norden-Rayleigh sobre la forma de la curva de desarrollo de los proyectos. Curva que se obtuvo basándose en datos recopilados por Norden y las descripciones analíticas de las curvas realizadas por Rayleigh.• Se afirma que el modelo es aplicable a proyectos de tamaño superior a 70.000 LOC.


MODELO SLIM (PUTNAM)



• Putnam define lo que él denomina la ecuación del software, basándose en que la cantidad de trabajo para desarrollar cualquier software se puede concebir como el producto del esfuerzo realizado en un periodo de tiempo.• Así, se puede escribir: L = C * K1/3 td

4/3

• Donde el tamaño del producto L (en LOC) representa una cierta medida de su funcionalidad y se asume que es proporcional al producto K * td• K representa el esfuerzo del trabajo humano, medido en personas-mes o personas-año.• td representa el tiempo que dura el trabajo, medido en meses o en años.





• Putnam define C como la constante de productividad del proceso. De esta manera la productividad no esta definida con precisión, aunque se supone que incluye un conjunto de factores que afectan a toda la organización, tales como la gestión del proyecto, el manejo de buenas especificaciones, diseños, codificaciones, inspecciones ypruebas, el estado de la tecnología, la experiencia de los miembros del grupo.• Los valores bajos de esta constante se asocian a entornos elementales con herramientas inadecuadas, o a una alta complejidad del producto.• Los valores altos se vinculan a buenos entornos, a personal experimentado o a productos de baja complejidad y fáciles de comprender.





• Algunos valores de C propuestos:



C Entorno2000 Desarrollo sin metodologías, pobre

documentación, modo de ejecución no interactivo.

8000 Buena metodología, revisiones acordadas, interactivo.

11000 Excelente entorno de desarrollo. Herramientas y técnicas automatizadas.



• Basándose en las tendencias establecidas en su base de datos, Putnam dedujo que la relación entre el esfuerzo no es lineal:

K = L3/ C3 * td4

• De esta segunda ecuación se deducen interesantes conclusiones. El factor td al estar afectado por una potencia tan alta indica que pequeñas variaciones en el tiempo de entrega pueden modificar enormemente el esfuerzo a realizar.





• Este modelo a recibido críticas por el hecho de que las curvas de Norden-Rayleigh no consideran la fase de especificación de requisitos, por lo que tampoco se tiene en cuenta esta fase del desarrollo en la correspondiente ecuación propuesta por Putnam.• Algunos técnicos consideran difícil utilizar este modelo en entornos de desarrollo pequeños. Esta consideración tiene su origen en que los datos recopilados para su creación han sido tomados en entornos de desarrollo grandes.



modelo cocomo

Documents