ESTIMACION DE PROYECTOS DE SOFTWARE

EPN

–

ASI

Desarrollo de Software

ESTIMACION DE PROYECTOS DE SOFTWARE Introducción: El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar razonablemente los recursos, costo y programa de trabajo. Sin embargo aunque la estimación se la realiza en etapas tempranas del proyecto ésta se debe ajustar a lo largo del transcurso del mismo, pues entre más conozca menor será el grado de incertidumbre y las estimaciones serán más precisas. La estimación se basa en las métricas de proyectos anteriores, las cuales sirven de línea base sobre las que, de acuerdo a la clasificación de los proyectos y una evaluación del tamaño y complejidad del software se utilizan en las técnicas y modelos existentes. Este trabajo contiene, en una primera parte algunos conceptos que son necesarios para realizar una buena estimación: ámbito y complejidad del software, luego analizaremos cuando un proyecto es factible, y finalmente algunos modelos empíricos de estimación, COCOMO el cual es uno de los más utilizados, la ecuación del software también será tratada y la medición orientada a objetos que es un modelo nuevo aún en desarrollo.

ESTIMACION DEL SOFTWARE Una de las primeras actividades de este proyecto es la todas las demás actividades de la planificación.

estimación, que es la base de

Características del proyecto a estimar.

Complejidad del proyecto . Tiene un gran efecto sobre la incertidumbre; que es inherente a la planificación. El tamaño del proyecto. Es otro factor importante que puede afectar a la precisión y eficacia de las estimaciones. Grado de estructuración del proyecto . Se refiere a la facilidad con que las funciones pueden ser compartidas y a la naturaleza de la información que debe ser procesada.

Giovanny Cholca

1

The world's largest digital library

Try Scribd FREE for 30 days to access over 125 million titles without ads or interruptions! Start Free Trial Cancel Anytime.





EPN

–

ASI


Observaciones acerca de la estimación La estimación y planificación temporal de un proyecto software requiere: experiencia, buena información histórica, coraje de confiar en las métricas, para obtener buenos resultados, debido a que cada proyecto es diferente, cada empresa es diferente y el contexto de los sistemas que desarrollamos cambian constantemente, no existe un método que se adapte completamente a cualquier proyecto, así la estimación debe ajustarse localmente. Hay cuatro factores que influyen significativamente en las estimaciones: La complejidad del proyecto. El tamaño del proyecto. El grado de incertidumbre estructural. Disponibilidad de información histórica.

ÁMBITO DEL SOFTWARE Y FACTIBILIDAD Son las funciones y características, datos de entrada, salida y el contenido que se presenta a los usuarios finales. El ámbito se define mediante: Mediante una descripción narrativa. Los usuarios desarrollan un conjunto de casos de uso. Así mismo se debe analizar si el software es factible de acuerdo a: Tecnología Finanzas Tiempo Recursos

TÉCNICAS DE DESCOMPOSICIÓN Tamaño del software ¿Cómo se define tamaño del software?, es un resultado cuantificable del proyecto. Se pueden asumir dos enfoques: directo, se mide mediante líneas de código (LDC) e indirecto, se mide mediante puntos de función f unción (PF). Putman y Myers sugieren: Tamaño de lógica difusa, Tamaño de punto de función Tamaño de componentes estándar Tamaño del cambio





EPN

–

ASI


Estimación basada en el problema Los datos de LDF y PF son distintas técnicas de estimación, pero que tienen varias características en común, y se utilizan en dos formas para estimar el proyecto de software: i. Como variable para estimar el tamaño del software ii. Como métrica de línea base recolectada de proyectos históricos Teniendo el ámbito del software, se descompone el mismo en funciones problemas, para ser evaluadas individualmente y obtener valores para LDC y PF, entonces se aplican métricas (LDC/pm o PF/pm) las cuales resultan en el tamaño o costo de la función, que combinadas derivan en la estimación global del proyecto. Sin embargo esta estimación basada en métricas de productividad es dispersa, por lo que se debe considerar que no es suficiente, el dominio del problema debe calcular las métricas de LDC/pm o PF/pm Consejo: Definir una taxonomía de proyectos para establecer un dominio permite obtener métricas más precisas. Cuando se estima un nuevo proyecto primero debe ubicarse en un dominio, y luego aplicar el promedio del dominio apropiado para la productividad y así generar la estimación¨

El valor esperado se calcula mediante una ponderación de: S = (Sopt + 4Sm + Spes) / 16

Estimación con casos de uso Desarrollar un enfoque de estimación de casos de uso es un problema debido a: No existe un formato estándar para describir los casos de uso. Están descritos con diferentes grados de abstracción (dependen del usuario). Los casos de uso no explican la complejidad de las funciones y de las características del software. Los casos de uso no explican el comportamiento de las diferentes funciones y características. Para evitar estos problemas Smith sugiere el uso de los casos de uso en la “jerar quía estructural”, estructural” , ésta se describe estimación estimación pero dentro de un contexto de “jerarquía con no más de 10 casos de uso y 30 escenarios distintos para cada caso de uso.





EPN

–

ASI


Como en toda estimación utilizamos datos históricos según la ecuación: LDC estimada = N x LDC prom + [(Sa /S /Sh 1) + (Pa /P /Ph – 1)] – 1)] x LDCajuste Donde: N = número real de casos de uso LDCprom = promedio histórico de LDC LDCajuste = diferencia entre este proyecto y los proyectos promedio Sa = escenarios reales de casos de uso Sh = escenarios promedio de casos de uso Pa = páginas reales por caso de uso Ph = páginas promedio por caso de uso

MODELOS EMPIRICOS DE ESTIMACIÓN No hay ningún modelo específico para todo proyecto de software, como vimos en las secciones anteriores utilizamos datos históricos, pero éstos están limitados a una muestra pequeña de proyectos anteriores, además que cada escenario y grupo de trabajo es diferente da lugar a que cada modelo se debe adecuar localmente.

EL MODELO COCOMO COCOMO son las siglas para COnstructive COst MOdel (Modelo constructivo de costos) Este modelo es una jerarquía de modelos de estimación que aborda: Modelo de composición de la aplicación, al inicio del ciclo de vida, cuando se realiza la recolección r ecolección de requerimientos. Modelo de etapa de diseño temprano, se utiliza cuando se realiza el diseño de la aplicación, en la evaluación de la tecnología. Modelo de etapa posterior, cuando ya se encuentra en la fase de construcción del software.

Además de estos tres modelos, COCOMO hace una clasificación en tres tipos de proyecto, ya que la productividad no es la misma para todos los proyectos. Los tipos ti pos de proyecto son: Organic Mode (Orgánico): Proyectos pequeños con pocos requerimientos, sin innovación tecnológica, usualmente un solo equipo de trabajo. Semidetached Mode (Semiacoplado): Proyectos de complejidad media, con algo de innovación tecnológica, ya interviene más de un equipo de t rabajo. Embedded Mode (Encajado): Proyectos de complejidad alta, con requerimientos rigurosos y con varios equipos trabajando coordinadamente.





EPN

–

ASI


Las ecuaciones del modelo COCOMO tienen la forma general: b

E = a · L · CDA, d

T = c · E

Donde: E es el esfuerzo (en personas-mes), L son las líneas de código (en miles), T es el tiempo de desarrollo del proyecto (en meses) y CDA los cost driven attributes. a, b, c y d son coeficientes que el modelo proporciona como resultado del análisis de los

datos de sesenta y tres proyectos realizados entre 1965 y 1980, de tamaños que varían de 2 a 1.000 KLDC y con una productividad que se sitúa entre 28 y 250 LDC por persona-mes. Para que COCOMO funcione se supone que: No se tienen en cuenta los comentarios en el recuento de las LDC. Se admite la equivalencia siguiente: 1 persona/mes son 152 horas de trabajo. Se considera que los requerimientos son estables. Se acepta que el proyecto está bien gestionado

COCOMOII La siguiente versión del modelo, COCOMOII, aun se encuentra en fase de elaboración, es más complejo y al igual que su antecesor presenta tres modelos: •

•

•

Modelo de composición de aplicaciones, uso de prototipos, se definen puntos de objeto Modelo de diseño primerizo, primera aproximación al inicio del ciclo de vida, cuando se conocen pocas características del producto. Modelo de postarquitectura, se aplica cuando ya se tienen tienen requerimientos estab estables, les, utiliza primitivas de salida como: LDC y TUFP (puntos de función sin ajustar)

En el modelo de postarquitectura aparecen nuevos nuevos términos, como NLDC , esto básicamente cuando se adopta el uso de componentes genéricos o componentes comerciales ya probados, o extender la funcionalidad de componentes propios de un proyecto. Los puntos de objeto, mencionados mencionados anteriormente, anteriormente, se calculan mediante el conteo conteo de: Pantallas (en la interfaz de usuario) Reportes





EPN

–

ASI


Cada instancia de un objeto de clasifica en uno de tres niveles de complejidad (simple, medio o difícil), de acuerdo a la siguiente tabla:

Tipo de Objeto

Peso de Paso complejidad

Pantalla Reporte Componente 3GL

Simp Medio le 1 2 2 5

de

Difícil 3 8 10

Una vez determinada la complejidad, el número de pantallas y componentes, se calcula la cuenta de puntos de objeto al multiplicar el número original de instancias de objeto por el factor de ponderación, y se suma para obtener una cuenta total de puntos de objeto. Cuando existe un desarrollo basado en componentes o reutilización de software se estima el porcentaje de reutilización. NPO = (puntos objeto) x [(100 - %reut) / 100)] NPO son los nuevos puntos de objeto La tasa de productividad se calcula mediante: PROD = NPO / pm Y el esfuerzo estimado con:

E = NPO / PROD

ECUACIÓN DEL SOFTWARE Este modelo procede de datos para productividad de casi 4000 proyectos de software contemporáneos, contemporáneos, se ha estimado un modelo de la forma: E = [LDC x B0.333 / P]3 x (1/t4) Donde: E

esfuerzo en pm

t

duración del proyecto en meses o años

B

factor especial de habilidades

P

parámetro de productividad

La ecuación del software tiene dos parámetros independientes: independientes: estimación del tamaño (LDC)







EPN

–

ASI


ESTIMACIÓN PARA PROYECTOS ORIENTADOS A OBJETOS 1. Desarrollar estimaciones aplicando: descomposición de esfuerzo, análisis de PF, esto para aplicaciones convencionales. convencionales. 2. Aplicar el modelo orientado a objetos desarrollar casos de uso y determinar un conteo. 3. Determinar el número de clases clave. 4. El número de clases clave por el multiplicador determina el número de clases soporte. 5. Multiplicar el número total de clases por el número promedio de unidades de trabajo por clase (15-20 personas-día).

RESULTADOS Mediante el estudio de las técnicas y modelos de estimación, nos hemos dado cuenta que es una de las principales tareas durante la planificación, quizá de las más importantes. Aunque Aunque muchas veces veces estas tareas previas al desarrollo mismo de la aplicación son vistas como algo que retrasa el proyecto, resultan cruciales ya que como gestores del proyecto nos ayudan a reducir la incertidumbre.

CONCLUSIONES La estimación es una de las principales actividades de la planificación ya que el costo del proyecto es lo que un cliente primero exige. No existe una fórmula mágica o modelo que se adapte a cualquier proyecto, una estimación muchas veces depende de la experiencia del gestor del proyecto y de los datos históricos que se posea. El número de personas que requiere un proyecto solo se determina después de que se haya hecho una estimación del esfuerzo. Las técnicas y los modelos son útiles al estimar pero no son confiables al 100%.

BIBLIOGRAFIA [1] PRESSMAN Roger S. Ingeniería del Software. Un enfoque práctico 6ta

ESTIMACION DE PROYECTOS DE SOFTWARE

Recommend Documents