Andrés Felipe Montoya Ríos

re.vu/AndresMontoya

@montoya118

Edwar Andrés Ruiz Medina

@EdwarRuiz324

Estimación de proyectos de software

¿Que es la estimación?

Estimación

“Apreciar, poner precio, evaluar algo”

Estimación de proyectos de software

“Actividad de la planificación del proyecto de sw que intenta determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto sw”.

¿En qué consiste la estimación de proyectos software?

«Aplicación continua de técnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una información de gestión significativa y a tiempo. Esta información se utilizará para mejorar esos procesos los productos que se obtienen de ellos» (SYMONS, C., 1998).

¿Cuál es el objetivo de la estimación?

Predecir las variables involucradas en el proyecto con cierto grado de certeza.

Trata de aportar una predicción de algún indicador importante para la gestión de proyectos de software tiempo, esfuerzo, cantidad de defectos esperados entre otros.

Es razonable conocer, antes de comenzar a desarrollar el SW, cuánto se va a invertir, qué tareas se deben realizar y cuánto tiempo se necesitará.

¿Quién es y cuál es el objetivo del estimador de un proyecto software?

El estimador debe ser un profesional que no tenga ningún interés, directo o indirecto, en los resultados del proceso de estimación 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 términos de costo y tiempo.

Requisitos que debe cumplir un buen estimador…

Formación y experiencia profesional adecuada.

Una posición en la organización que le permita adoptar un juicio independiente.

Debe basarse en un método que pueda ser explicado, cuestionado, discutido y auditado.

Debe poder describir su experiencia en cada estimación.

Debe documentar su estimación, incluyendo los resultados obtenidos y cualquier información necesaria para hacer el proceso de estimación repetible y verificable.

¿Cuándo se debe llevar a cabo?

La estimación 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 éste se conozca.

El proceso de estimación comienza usando unas pocas variables claves para proveer las «macrocaracterísticas» de un proyecto, y evoluciona incorporando información de más bajo nivel para producir las «micro-características» del proyecto.

Ejemplo con un MCVS en cascada

TÉCNICAS DE ESTIMACIÓN…

Técnicas de estimación…

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 o Se basa en la comparación directa de uno o más

proyectos pasados.o Para poder utilizar esta técnica es necesario disponer

de una base de datos histórica de proyectos finalizados con la que poder realizar la comparación.

o Los proyectos deben tener muchas similitudes en cuanto a su esquema.

Técnicas de estimación…

La descomposicióno Consiste en la descomposición de un producto en

componentes más pequeños, o descomponer un proyecto en tareas de nivel inferior.

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

Las ecuaciones de estimación: o 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á.

MÉTODOS DE ESTIMACIÓN…

 Método de puntos de casos de uso

método de estimación y cálculo de tamaño del software basado en cuentas hechas sobre los casos de uso para un sistema de software.

Cuantificación de características funcionales del Sistema:o Clasificación de Actores, o Clasificación de los Casos de Usoo Obtención del Peso o Puntos de Casos de Uso

Cuantificación de características no funcionales del Sistema:o Clasificación de Factores de Complejidad Técnica (FCT)o Clasificación de Factores Ambientales (FA)o Cálculo de Puntos de Casos de Uso Ajustados (PCU)

Clasificación de Actores...

Todos los actores del sistema deben ser clasificados como Simple, Promedio y Complejo:

Actor Simple: Se trata de otro sistema interactuando a través de una interfaz de programación definida y conocida (API).

Actor Promedio: Es otro sistema interactuando a través de un protocolo (como TCP/IP).

Actor Complejo: se trata de una persona interactuando con el sistema a través de una interfaz gráfica de usuario (GUI) o página Web.

 Se cuentan los actores de acuerdo a su clasificación o grado de complejidad, multiplicando cada subtotal por su factor de complejidad y sumando cada producto obteniéndose el peso de los actores sin ajustar (PASA).

Clasificación 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 número 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: Más de 7 Transacciones.

Se cuentan los casos de uso de acuerdo a su clasificación por numero de transacciones, multiplicando cada subtotal por su factor de complejidad y sumando cada producto obteniéndose el peso de los actores sin ajustar (PTSA).

Obtención de Factores de Peso o Puntos de Casos de Uso Sin Ajustar

(PCUSA).

Es la suma del Peso de los Actores Sin ajustar más el Peso de las Transacciones Sin Ajustar, es decir:

PCUSA = PASA + PTSA

Clasificación de Factores de Complejidad Técnica (FCT)

Son los factores de peso que incorporan la complejidad técnica del sistema y algunas características 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 Fórmula: FCT = 0.6 + (0.01*FactorT)

Clasificación de Factores Ambientales (FA)

Corresponden en términos generales, las características del equipo de desarrollo en cuanto a perfiles, experiencia y capacidad técnica. Se clasifican de la siguiente manera

0: Sin influencia3: Promedio5: 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 Fórmula:

FA = 1.4 + (-0.03*FactorA)

Cálculo de Puntos de Casos de Uso Ajustados (PCU)

Finalmente, se obtiene la siguiente fórmula que representa los puntos de casos de uso ajustados:

PCU = PCUSA* FCT*FA

MÉTODO DE ESTIMACIÓN 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).

Según COCOMO existen tres modos de desarrollo, a cada uno de estos modos se le pueden aplicar tres métodos de estimación diferentes

Modo orgánico…

El proyecto se desarrolla en equipos relativamente pequeños

Muchas personas relacionadas con el proyecto tienen amplia experiencia trabajando en sistemas similares y tienen un buen conocimiento de cómo el sistema que se está desarrollando contribuirá a los objetivos de la organización.

Se desarrolla en un entorno generalmente estable, con muy pequeña probabilidad de coincidencia en el desarrollo de un nuevo hardware u operaciones desconocidas.

Proyectos de tamaño relativamente pequeño. Como máximo 50 KDSI (miles de instrucciones).

 

Modo semilibre…

El equipo del proyecto tiene un nivel medio de experiencia en proyectos similares.

El equipo es una combinación de personal experto e inexperto.

El tamaño del producto llega a las 300 KDSI.

Modo rígido…

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 pequeños de analistas y, a una sobrecarga de comunicación importante durante el desarrollo.

Se aplica a proyectos de cualquier tamaño.

Modelo básico…

Se suele aplicar en los desarrollos de productos pequeños/medios Las ecuaciones de estimación de esfuerzo y tiempo de desarrollo para cada modo de desarrollo:

 Orgánico: 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 Rígido: MM = 3,6 (KDSI)1,20

TDEV = 2,5 (MM)0,32

“KDSI = número de instrucciones de código en miles.

MM = esfuerzo medido en meses/hombre.

TDEV = duración en meses”

Modelo intermedio…

Atributos del producto software:   RELY: Fiabilidad requerida del software DATA: Tamaño de la base de datos. CPLX: Complejidad del producto. TIME: Limitaciones en el tiempo de ejecución STOR: Limitaciones de memoria principal. VIRT: Volatilidad de la máquina virtual TURN: Frecuencia de cambio en el modelo de

explotación del ordenador.

Atributos de personal  ACAP: Capacitación de los analistas AEXP: Experiencia en aplicaciones. PCAP: Capacitación de los programadores VEXP: Experiencia en la máquina virtual. LEXP: Experiencia en el lenguaje de programación.

Atributos del proyecto  MODP: Prácticas Modernas de programación. TOOL: Uso de herramientas para el desarrollo de

software. SCED: Limitaciones en la planificación.

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

Modelo detallado…

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 detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo en cada fase.

Descomposición Jerárquica del producto a tres niveles: Nivel módulo. 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 pequeños haría falta ajustar la ecuación.

o T= Tamaño en LDCo 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 año o Td= tiempo para completar el proyecto en años.

Conclusiones!!!