Tecnicas de Estimación de Productos de Software

Clarena Rodriguez Pinto – 160002346Juan Camilo Cajamarca - 160002332

Estas técnicas de estimación son una forma de resolución de problemas en donde, en la mayoría de los casos, el problema a resolver es demasiado complejo para considerarlo como una sola parte. Por esta razón, descomponemos el problema, recaracterizándolo como un conjunto de pequeños problemas.

Las estimaciones están asociadas con el esfuerzo, costo y el tiempo de las actividades identificadas del proyecto. El objetivo de la estimación de proyectos es reducir los costos e incrementar los niveles de servicio y de calidad.

Tecnicas de Estimación

COCOMO 81 COCOMO II Delphi Analogia Punto de Función Lineas de Código

Modelos

Fue desarrollado por Barry Boehmen 1981. El modelo asume que los requerimientos son relativamente estables y que el proyecto será administrado por el cliente y el desarrollador. El modelo entrega un orden de magnitud de los costos del Software. Utiliza como datos el tamaño estimado del proyecto y el tipo de producto a desarrollar.

Cocomo

COCOMO’ 81 está compuesto por tres modelos que corresponden a distintos niveles de detalle y precisión.

 • Modelo COCOMO básico

• Modelo COCOMO intermedio

• Modelo COCOMO avanzado (o detallado)

 

Cocomo’81 – Modelos

Es un modelo univariable estático que calcula el esfuerzo y el tiempo del desarrollo de software en función del tamaño del programa, expresado en Líneas de Código (LDC) estimadas. Adecuado para hacer estimaciones de forma rápida, aunque sin gran precisión. 

Cocomo’81 – Modelo Basico

Es un modelo univariable estático que calcula el esfuerzo del desarrollo de software en función del tamaño del programa y un conjunto de “conductores de coste”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto. Estos conductores del coste se consideran como términos de impacto agregado al esfuerzo total del proyecto. 

Cocomo’81 – Modelo Intermedio

Es un modelo que incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de coste en cada fase(análisis, diseño, etc.) del proceso de ingeniería de software.

La estimación es más precisa a medida que se toman en cuenta mayor cantidad de factores que influyen en el desarrollo de un producto de software.

Cocomo’81 – Modelo Avanzado

Diseño del Producto (PD)Se define la arquitectura del hardware, software y las estructuras de datos y control. También se desarrolla un bosquejo del manual del usuario y los planes de aceptación y testeo.

Diseño Detallado (DD)

Codificación y Testeo de Unidades (CT)En estas dos fases el diseño global de la fase anterior es implementado, creando las componentes de software, que son testeadas y evaluadas individualmente.

Cocomo’81 - Fases

Integración y Testeo (IT)Se fusionan todas las componentes de software desarrolladas con el fin de lograr que el producto de software funcione correctamente. Los requerimientos definidos son usados para controlar las aptitudes del producto liberado. Los costos y tiempos de las fases excluidas (Requerimientos y Mantenimiento) deben ser estimados en forma separada empleando otros modelos.

Cocomo’81 - Fases

Los modelos COCOMO están definidos para tres modos de desarrollo:

 

Proyectos Orgánicos:El equipo de desarrollo es pequeño y experimentado, en un ambiente familiar y con aplicaciones conocidas. 

Proyectos Semiconectados (Semilibres): El equipo de desarrollo está formado por personal experimentado y novato con algo de experiencia en la tecnología y la aplicación. Suelen tener interacciones con otros sistemas.

Proyectos Integrados (Empotrados): Tiene un gran equipo de desarrollo, pero en general es poco experimentado en el tema dado que se trata de proyectos casi únicos. Corresponden a proyectos que representan un fuerte acoplamiento entre el Hardware, Software y los procedimientos operacionales. La modificación a los requerimientos no es práctica y los costos de validación son altos.

Cocomo’81 – Tipos de Proyectos

E=(a(Kl)^b )*m(X) (Esfuerzo)“E” Salario/mes = Esfuerzo“a” y “b” Constante según el tipo de proyecto“Kl” Cantidad e Lineas de Cod.“m(x)” Multiplicador que depende de 15 Atributos

Constantes. T=cE^d (Tiempo de Duración de

Desarrollo) P=E/T (Cantidad de Personas) KLDC=(PF*L)/1000 (Kilo de Lineas de

Cod.)

Formulas

¿Que es? Nuevas Mejoras Modelos

◦ Composición de Aplicación◦ Diseño temprano◦ Post-Arquitectura

COCOMO II

COCOMO II es un modelo que permite estimar el coste, esfuerzo y tiempo cuando se planifica una nueva actividad de desarrollo software.

COCOMO II está adaptado a los ciclos de vida de los modelos de desarrollo de software actuales, dado que esposible de aplicar a aquellas nuevas prácticas no tradicionales de software como desarrollo rápido de aplicaciones, aplicaciones no secuenciales, reusabilidad del software, reingeniería, programación orientada a objetos, entre otras.

¿Qué es?

Desarrollar un modelo de estimación de costo y cronograma de proyectos de software que se adaptara tanto a las prácticas de desarrollo de la década del 90 como a las futuras

Construir una base de datos de proyectos de software que permitiera la calibración continua del modelo, y así incrementar la precisión en la estimación

Implementar una herramienta de software que soportara el modelo

Proveer un marco analítico cuantitativo y un conjunto de herramientas y técnicas que evaluaran el impacto de las mejoras tecnológicas de software sobre los costos y tiempos en las diferentes etapas del ciclo de vida de desarrollo

Nuevas Mejoras

Indicado para proyectos construidos con herramientas modernas de construcción de interfaces gráficos para usuario

Composición de Aplicación

Se utiliza en las primeras etapas del desarrollo en las cuales se evalúan las alternativas de hardware y software de un proyecto. En estas etapas se tiene poca información, lo que concuerda con el uso de Puntos Función, para estimar tamaño y el uso de un número reducido de factores de costo.

Diseño Temprano

Este es el modelo COCOMO 2 más detallado. Puede ser utilizado después de haber desarrollado la arquitectura global del proyecto. Utiliza nuevos parámetros de costo, nuevas reglas de conteo de líneas y nuevas ecuaciones. Este modelo corresponde al esfuerzo de desarrollo estimado una vez que se ha fijado la arquitectura del sistema. Este modelo ‘base’ puede ajustarse para:

Estimaciones más tempranas, correspondiente al modelo de diseño temprano (Pre-arquitectura). Mantenimiento. Estimación de número de defectos esperados

Post-Arquitectura

Calcular el esfuerzo, el tiempo y personal que se debería implementar en el proyecto con los siguientes datos.

PF=261,36 Lenguaje – VB= 32 LDC * C/PF

Ejemplo

KLDC= (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000= 8,363

m(x)=1,15*1,00*0,85*1,11*1,00*1,00*1,07*0,86*0,82*0,70*1,00*0,95*1,00*0,91*1,08 = 0,53508480

E = a KLDC e * FAE = 3,2 * (8.363)^1,05 * 0,53508480 = 15,91 personas /mês

T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses

P = E/T = 15,91/7,15 = 2,22 personas

Solución

Fue concebido en los años cincuenta con fines militares y a partir de la década de los sesenta ha sido utilizado en los ámbitos académicos y empresariales. Ha sido empleado principalmente como técnica de previsión y consenso en situaciones de incertidumbre, en las que no es posible acudir a otras técnicas basadas en información objetiva.

Wideband Delphi

Es un proceso iterativo. Como mínimo los expertos deben ser consultados dos veces sobre la misma cuestión, de forma que puedan volver a pensar su respuesta ayudados por la información que reciben de las opiniones del resto de los expertos.

Mantiene el anonimato de los participantes, o al menos de sus respuestas, ya que éstas van directamente al grupo coordinador. Ello permite poder desarrollar Un proceso de grupo con unos expertos que no coinciden ni temporal ni espacialmente, y además busca evitar las influencias negativas que en las respuestas Individuales pudieran tener factores relativos a la personalidad de los expertos participantes.

Wideband Delphi - Caracteristicas

Feedback controlado. El intercambio de información entre los expertos no es libre, sino que se realiza a través del grupo coordinador del estudio, con lo que se elimina toda información que no sea relevante.

Respuesta estadística de grupo. Todas las opiniones forman parte de la respuesta final. Las preguntas están formuladas de forma que se pueda realizar un tratamiento cuantitativo y estadístico de las respuestas.

Wideband Delphi - Caracteristicas

Es un método grupal para refinar el Project plan, donde participan el Project Manager o un moderador, un recorder y estimadores. Las especificaciones se le dan a un grupo de expertos, quienes discuten las metas del proyecto, las suposiciones y estiman los recursos. Además, ellos hacen las estimaciones y se las dan a un moderador, quien compila las estimaciones. Luego, cada estimador sabe los resultados de sus estimaciones, las demás son anónimas.

Seguidamente, los expertos discuten los resultados y revisan las tareas. Este ciclo continua hasta que las estimaciones convergen en una que se encuentre en un rango aceptable.

Wideband Delphi - Metodologia

Planificación: Es el primer paso del proceso Wideband delphi que comienza con la definición y alcance del problema a estimar.

Reunión inicial: Consiste en la comprensión sobre el problema de estimación, en donde el equipo revisa los objetivos estimados, discute el problema y algunos asuntos de la estimación llegando a un acuerdo sobre las unidades de estimación (semanas, horas laborales, dólares, líneas de código) que se usaran a lo largo del proceso.

Wideband Delphi – Ciclo de Vida

Preparación individual: Consiste en que cada participante desarrolla independientemente una lista inicial de tareas que deberán ser completadas para alcanzar la meta del proyecto, donde cada participante estima el esfuerzo que cada tarea consumirá.

Reunión de estimación: El objetivo en este paso es establecer una lista con todas las estimaciones individuales para debatirlas en anonimato, evitando las posibles intimidaciones entre los participantes, todo esto, con el fin de debatir las diferentes estimaciones con el propósito de que cada integrante pueda modificar, añadir, eliminar sus estimaciones renovando la lista obtenida anteriormente .

Wideband Delphi – Ciclo de Vida

Ensamblando las tareas: Es donde el moderador o Project manager ensambla las tareas del proyecto y sus estimaciones individuales dentro de una lista maestra definitiva de tareas, en donde se encuentran recopilados todos los procesos trabajados con anterioridad.

Revisión de resultados: Finalmente, en este paso el equipo de estimación revisa los resultados resumidos y llega a un acuerdo sobre el resultado final.

Wideband Delphi – Ciclo de Vida

Ventajas Desventajas

Hay menos probabilidad de una estimación negativa.

Requiere de expertos para que hagan la estimación.

Esta basado en valores históricos.

No define un proceso a seguir cuando se esta estimando.

Wideband Delphi – Ventajas/Desventajas

El coste de un proyecto se calcula por comparación con proyectos similares en el mismo dominio de aplicación. Es aplicable cuando otros proyectos en el mismo dominio de aplicación se han completado. Se estima el costo de un nuevo proyecto por analogía con estos proyectos completados.

Analogía

La técnica de puntos de función fue introducida por Albrecht y su propósito es pedir el software cualificando la Funcionalidad que proporciona externamente, basándose en el diseño lógico del sistema.

Medir lo que el usuario pide y lo que el usuario recibe. Medir independientemente 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.

Análisis de Puntos de Función (FPA)

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). Ficheros Lógicos Internos (ILF, del inglés Internal Logic File). Ficheros Lógicos Externos (EIF, del inglés External Interface File)

FPA– Mecanismo

Es un proceso elemental o una acción que procesa datos o información de control que vienen desde afuera de la frontera de la aplicación hacia adentro. Los datos pueden venir desde otra aplicación o desde una pantalla de ingreso de datos. El objetivo fundamental es mantener uno o más archivos lógicos internos (o ILF de Internal Logical File) y/o alterar el comportamiento del sistema.

FPA – Entradas (EI)

Se aplican las siguientes reglas:

R1: Los datos se reciben desde fuera de los límites de la aplicación.

R2: Los datos mantienen un ILF a través de un proceso elemental de la aplicación.

R3: El proceso es la unidad más pequeña de actividad que es significativa para el negocio del usuario final.

R4: El proceso es auto contenido y deja la aplicación que está siendo contada en un estado consistente.

R5: El proceso identificado debe verificar alguna de estas reglas:

Su lógica de proceso es única respecto de otras entradas externas de la aplicación.

Los elementos de datos identificados son distintos a los de las otras EI de la aplicación.

Los ficheros lógicos referenciados son diferentes

FPA – Entradas (EI)

El objetivo fundamental es presentar información al usuario a través del procesamiento lógico de los datos o de la información de control obtenida.

Se aplican las siguientes reglas:R1: El proceso envía datos información de control.R2: Los datos o información de control se envían a través de un proceso elemental de la aplicación.R3: El proceso es la unidad más pequeña de actividad que es significativa para el negocio del usuario final.R4: El proceso es auto contenido y deja a la aplicación en un estado consistente.

FPA – Salidas(OI)

R5: El proceso identificado debe verificar alguna de estas reglas:◦ Su lógica de proceso es única respecto de otras salidas externas de la aplicación.◦ Los elementos de datos identificados son distintos a los de otras EO’s de la

aplicación.◦ Los ficheros lógicos referenciados son distintos.

R6: Debe cumplirse al menos una de las siguientes condiciones:◦ El proceso elemental contiene al menos una fórmula matemática o cálculo.◦ El proceso crea datos derivados◦ El proceso que genera la salida mantiene algún ILF◦ El proceso que genera la salida altera el comportamiento del sistema.

R7: La transferencia de datos a otras aplicaciones se cuenta como salidas

R8: Los informes escritos y online se cuentan como salidas independientes.

R9: Los gráficos se cuentan como una salida cada uno.

FPA – Salidas(OI)

El objetivo principal de un EQ es presentar información al usuario a travésde la obtención del dato o de la información de control.

Se aplican las siguientes reglas: R1: Una petición entra dentro del límite de la aplicación. R2: Un resultado sale del límite de la aplicación R3: Hay recuperación de datos R4: Los datos recuperados no contienen datos derivados. R5: El proceso lógico no contiene fórmulas matemáticas o cálculos R6: El proceso que genera la consulta no mantiene ningún ILF ni altera el

comportamiento del sistema R7: La petición de entrada y el resultado de salida juntos, hacen del

proceso la unidad de actividad más pequeña que es significativa para el negocio del usuario final.

R8: El proceso es auto contenido y deja a la aplicación que está siendo contada en un estado consistente.

FPA – Consultas(EQ)

El objetivo fundamental de un ILF es manejar los datos mantenidos a través de uno o más procesos elementales (o acciones) de la aplicación que está siendo contada.

Reglas para identificarlos:

R1: El grupo de datos o información de control es un grupo de datoslógico identificable por el usuario que cubre de manera completarequisitos específicos de este.R2: El grupo de datos es mantenido dentro de los límites de laaplicación.R3: El grupo de datos es mantenido o modificado por medio de unproceso elemental de la aplicación.R4: El grupo de datos identificado no se ha contado como ELF de laaplicación.

FPA - Ficheros Lógicos Internos (ILF)

El objetivo principal de un ELF es manejar los datos referenciados mediante uno o más procesos elementales (o acciones) dentro de la frontera de la aplicación contada.

Reglas: R1: El grupo de datos o información de control es un grupo de datos lógico

identificable por el usuario que cubre de manera completa requisitos específicos de este.

R2: El grupo de datos es referenciado y es externo a la aplicación que está siendo contada.

R3: El grupo de datos no es mantenido por la aplicación que está siendo contada.

R4: El grupo de datos se ha contado como ILF en al menos otra aplicación. R5: El grupo de datos identificado no ha sido contado como un ILF para la

aplicación.

FPA - Ficheros Lógicos Externos (ELF)

Regresar…

Es una medida propuesta inicialmente cuando los programas se escribían en tarjetas, con una línea por tarjeta. Actualmente los lenguajes permiten escribir varias sentencias en una línea, o una misma sentencia en varias líneas

Las LDC miden en forma directa el tamaño del producto de software. Se calculan simplemente contando las instrucciones de código fuente de cada componente del producto de software excluyendo, generalmente, los comentarios y blancos.

Lineas de Código

Entonces, se calcula el valor esperado de LDC. El valor esperado para la variable de estimación, E, se obtiene como una medida ponderada de las estimaciones LDC óptima (a), más probable (m) y pesimista (b).

Esta técnica trata de definir el tiempo y el costo del proyecto en base a la cantidad de líneas de código se tienen que escribir, cual es el costo por línea y cuantas líneas de código desarrollamos en un mes.

Formula:

Los pasos para desarrollar ese método son los siguientes:

Descomponemos el problema en los módulos importantes que posea. Estimar los valores para las columnas de líneas a escribir optimista Más

Probable, Pesimista Calcular la columna esperada en base a la fórmula Se coloca en la columna de "$/línea" el precio de cada línea en cada módulo,

esto generalmente se realiza basados en los costos de proyectos anteriores. La siguiente casilla pertenece a cuantas líneas se pueden escribir en un mes. La casilla de "Coste", nos permite tener el cálculo de cuanto costaría cada

módulo, esto se obtiene de multiplicar la columna de "$ por línea" con la de "Esperada".

Los meses se calculan multiplicando las "Líneas al mes" por "Esperada" Al totalizarlas columnas calculadas tendríamos en la columna de "Esperada"

la cantidad de líneas que se escribirían, el la de "Coste" el costo estimado del proyecto y en la de "Meses" los meses que demoraría el proyecto

Regresar