Вы находитесь на странице: 1из 39

Estimacin de proyectos de software

Andrs Felipe Montoya Ros re.vu/AndresMontoya @montoya118 Edwar Andrs Ruiz Medina @EdwarRuiz324

Que es la estimacin?
Estimacin Apreciar, poner precio, evaluar algo Estimacin de proyectos de software Actividad de la planificacin del proyecto de sw que intenta determinar cunto dinero, esfuerzo, recursos y tiempo tomar construir un sistema o producto sw.

En qu consiste la estimacin de proyectos software?


Aplicacin continua de tcnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una informacin de gestin significativa y a tiempo. Esta informacin se utilizar para mejorar esos procesos los productos que se obtienen de ellos (SYMONS, C., 1998).

Cul es el objetivo de la estimacin?


Predecir las variables involucradas en el proyecto con cierto grado de certeza. Trata de aportar una prediccin de algn indicador importante para la gestin de proyectos de software tiempo, esfuerzo, cantidad de defectos esperados entre otros. Es razonable conocer, antes de comenzar a desarrollar el SW, cunto se va a invertir, qu tareas se deben realizar y cunto tiempo se necesitar.

Quin es y cul es el objetivo del estimador de un proyecto software?


El estimador debe ser un profesional que no tenga ningn inters, directo o indirecto, en los resultados del proceso de estimacin y que este nicamente guiado por su profesionalismo. El principal objetivo del estimador es obtener estimaciones de calidad, las cuales no tienen siempre por qu coincidir con las expectativas de la empresa en trminos de costo y tiempo.

Requisitos que debe cumplir un buen estimador


Formacin y experiencia profesional adecuada.
Una posicin en la organizacin que le permita adoptar un juicio independiente. Debe basarse en un mtodo que pueda ser explicado, cuestionado, discutido y auditado. Debe poder describir su experiencia en cada estimacin. Debe documentar su estimacin, incluyendo los resultados obtenidos y cualquier informacin necesaria para hacer el proceso de estimacin repetible y verificable.

Cundo se debe llevar a cabo?


La estimacin es un proceso continuo. A medida que el proyecto avanza, ms se conoce de l, y por lo tanto ms parmetros estn disponibles para introducir en un modelo de estimacin.

La estimacin continua nos permite el uso de un nico modelo coherente que pueda capturar y utilizar la informacin sobre el proyecto a medida que ste se conozca.

El proceso de estimacin comienza usando unas pocas variables claves para proveer las macrocaractersticas de un proyecto, y evoluciona incorporando informacin de ms bajo nivel para producir las microcaractersticas del proyecto.

Ejemplo con un MCVS en cascada

TCNICAS DE ESTIMACIN

Tcnicas de estimacin
La opinin de los expertos Esta tcnica se basa en la experiencia profesional de los Participantes en el proyecto de estimacin. La analoga o Se basa en la comparacin directa de uno o ms proyectos pasados. o Para poder utilizar esta tcnica es necesario disponer de una base de datos histrica de proyectos finalizados con la que poder realizar la comparacin. o Los proyectos deben tener muchas similitudes en cuanto a su esquema.

Tcnicas de estimacin
La descomposicin o Consiste en la descomposicin de un producto en componentes ms pequeos, o descomponer un proyecto en tareas de nivel inferior. o La estimacin se hace a partir del esfuerzo requerido para producir los componentes ms pequeos o para realizar las tareas de nivel inferior. Las ecuaciones de estimacin: o Son frmulas matemticas que establecen la relacin de algunas medidas de entrada (que normalmente es la medida del tamao del producto) y determinan el esfuerzo que se requerir.

MTODOS DE ESTIMACIN

Mtodo de puntos de casos de uso

mtodo de estimacin y clculo de tamao del software basado en cuentas hechas sobre los casos de uso para un sistema de software. o o o o o o Cuantificacin de caractersticas funcionales del Sistema: Clasificacin de Actores, Clasificacin de los Casos de Uso Obtencin del Peso o Puntos de Casos de Uso Cuantificacin de caractersticas no funcionales del Sistema: Clasificacin de Factores de Complejidad Tcnica (FCT) Clasificacin de Factores Ambientales (FA) Clculo de Puntos de Casos de Uso Ajustados (PCU)

Clasificacin de Actores...
Todos los actores del sistema deben ser clasificados como Simple, Promedio y Complejo:

Actor Simple: Se trata de otro sistema interactuando a travs de una interfaz de programacin definida y conocida (API). Actor Promedio: Es otro sistema interactuando a travs de un protocolo (como TCP/IP). Actor Complejo: se trata de una persona interactuando con el sistema a travs de una interfaz grfica de usuario (GUI) o pgina Web.

Se cuentan los actores de acuerdo a su clasificacin o grado de complejidad, multiplicando cada subtotal por su factor de complejidad y sumando cada producto obtenindose el peso de los actores sin ajustar (PASA).

Clasificacin de Casos de Uso a partir de las Transacciones


Teniendo el modelo de casos de uso, cada uno de ellos debe clasificarse como Simple, Medio o Complejo, de acuerdo al nmero de transacciones descritas en el caso de uso. Se clasifican desacuerdo a lo siguiente: Casos de Uso Simple: Tres o menos transacciones (o pasos). Casos de Uso Promedio: entre 4 o 7 Transacciones. Casos de Uso Complejos: Ms de 7 Transacciones.

Se cuentan los casos de uso de acuerdo a su clasificacin por numero de transacciones, multiplicando cada subtotal por su factor de complejidad y sumando cada producto obtenindose el peso de los actores sin ajustar (PTSA).

Obtencin de Factores de Peso o Puntos de Casos de Uso Sin Ajustar (PCUSA). Es la suma del Peso de los Actores Sin ajustar ms el Peso de las Transacciones Sin Ajustar, es decir:

PCUSA = PASA + PTSA

Clasificacin de Factores de Complejidad Tcnica (FCT)


Son los factores de peso que incorporan la complejidad tcnica del sistema y algunas caractersticas no funcionales, el peso se representa de la siguiente manera: 0: Sin influencia 3: Promedio 5: Fuerte influencia

Para obtener el factor final se debe multiplicar cada item (T1 a T13) por el grado de influencia sobre el sistema y se obtiene la suma llamada FactorT, de acuerdo a la siguiente Frmula: FCT = 0.6 + (0.01*FactorT)

Clasificacin de Factores Ambientales (FA)


Corresponden en trminos generales, las caractersticas del equipo de desarrollo en cuanto a perfiles, experiencia y capacidad tcnica. Se clasifican de la siguiente manera 0: Sin influencia 3: Promedio 5: Fuerte influencia

Para obtener el factor final se debe multiplicar cada item (F1 a F8) por el grado de influencia sobre el sistema y se obtiene la suma llamada FactorA, de acuerdo a la siguiente Frmula: FA = 1.4 + (-0.03*FactorA)

Clculo de Puntos de Casos de Uso Ajustados (PCU)

Finalmente, se obtiene la siguiente frmula que representa los puntos de casos de uso ajustados: PCU = PCUSA* FCT*FA

MTODO DE ESTIMACIN COCOMO

Cuando un ingeniero est ante un proyecto a estimar, lo primero que debe hacer para aplicar el COCOMO es situar su proyecto en el espacio de dos dimensiones (modo, modelo).

Segn COCOMO existen tres modos de desarrollo, a cada uno de estos modos se le pueden aplicar tres mtodos de estimacin diferentes

Modo orgnico
El proyecto se desarrolla en equipos relativamente pequeos Muchas personas relacionadas con el proyecto tienen amplia experiencia trabajando en sistemas similares y tienen un buen conocimiento de cmo el sistema que se est desarrollando contribuir a los objetivos de la organizacin. Se desarrolla en un entorno generalmente estable, con muy pequea probabilidad de coincidencia en el desarrollo de un nuevo hardware u operaciones desconocidas. Proyectos de tamao relativamente pequeo. Como mximo 50 KDSI (miles de instrucciones).

Modo semilibre
El equipo del proyecto tiene un nivel medio de experiencia en proyectos similares. El equipo es una combinacin de personal experto e inexperto. El tamao del producto llega a las 300 KDSI.

Modo rgido
Proyectos que deben desarrollarse dentro de unas limitaciones muy estrictas.
El producto debe explotarse dentro de un entorno muy acoplado de hardware, software, normativa y procedimientos operativos Estos proyectos se desarrollan en reas generalmente desconocidas, lo cual lleva inicialmente a equipos pequeos de analistas y, a una sobrecarga de comunicacin importante durante el desarrollo. Se aplica a proyectos de cualquier tamao.

Modelo bsico
Se suele aplicar en los desarrollos de productos pequeos/medios Las ecuaciones de estimacin de esfuerzo y tiempo de desarrollo para cada modo de desarrollo:

Orgnico: MM = 2,4 (KDSI)1,05 TDEV = 2,5 (MM)0,38 Semilibre: MM = 3,0 (KDSI)1,12 TDEV = 2,5 (MM)0,35 Rgido: MM = 3,6 (KDSI)1,20 TDEV = 2,5 (MM)0,32

KDSI = nmero de instrucciones de cdigo en miles. MM = esfuerzo medido en meses/hombre. TDEV = duracin en meses

Modelo intermedio
Atributos del producto software:
RELY: Fiabilidad requerida del software DATA: Tamao de la base de datos. CPLX: Complejidad del producto. TIME: Limitaciones en el tiempo de ejecucin STOR: Limitaciones de memoria principal. VIRT: Volatilidad de la mquina virtual TURN: Frecuencia de cambio en el modelo de explotacin del ordenador.

Atributos de personal ACAP: Capacitacin de los analistas AEXP: Experiencia en aplicaciones. PCAP: Capacitacin de los programadores VEXP: Experiencia en la mquina virtual. LEXP: Experiencia en el lenguaje de programacin. Atributos del proyecto MODP: Prcticas Modernas de programacin. TOOL: Uso de herramientas para el desarrollo de software. SCED: Limitaciones en la planificacin.

La estimacin de esfuerzo aplicando este modelo es: Modo orgnico: MM = 3,2 (KDSI) 1,05 Modo semilibre: MM = 3,0 (KDSI) 1,12 Modo rgido: MM = 2,8 (KDSI) 1,20

Modelo detallado
Multiplicadores de esfuerzo por fases En el modelo COCOMO intermedio, la distribucin de esfuerzo por fase se determina nicamente por el tamao del producto. En la prctica, factores como la fiabilidad requerida, la experiencia en aplicaciones y desarrollos interactivos afectan a unas fases ms que a otras. El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo en cada fase. Descomposicin Jerrquica del producto a tres niveles: Nivel mdulo. Nivel subsistema. Nivel sistema.

Modelo SLIM
Est basado en la curva de Rayleigh, que describe la necesidad de personal al desarrollar proyectos complejos. Fue desarrollada para estimar los costes de los grandes proyectos de software. En proyectos pequeos hara falta ajustar la ecuacin.

o T= Tamao en LDC o C= factor dependiente del entorno ( (vale 2.000 para entornos poco productivos, 8.000 para entornos buenos, 11.000 para entornos excelentes) o K= Esfuerzos de personas ao o Td= tiempo para completar el proyecto en aos.

Conclusiones!!!

Вам также может понравиться