Estimación para proyectos de software

Métodos y Herramientas de Ingeniería de software

OBSERVACIÓN ACERCA DE LAS ESTIMACIONES

La estimación de recursos, costo y calendario para un esfuerzo de ingeniería de software requiereexperiencia, acceso a buena información histórica (métricas) y coraje para comprometerse con laspredicciones cuantitativas cuando todo lo que existe es información cualitativa. La estimación porta unriesgo inherente, y éste conduce a incertidumbre.

La complejidad del proyecto tiene un fuerte efecto sobre la incertidumbre inherente a la planificación.

El tamaño del proyecto es otro factor importante que puede afectar la precisión y la eficacia de lasestimaciones. Conforme aumenta el tamaño, la interdependencia entre varios elementos del softwarecrece rápidamente.

El grado de incertidumbre estructural también tiene un efecto sobre el riesgo de estimación.

EL PROCESO DE PLANIFICACIÓN DE PROYECTOS

El objetivo de la planificación del proyecto de software es proporcionar un marco conceptual quepermita al gerente hacer estimaciones razonables de recursos, costo y calendario.

Además, las estimaciones deben intentar definir los escenarios de mejor caso y peor caso, de modoque los resultados del proyecto puedan acotarse.

Aunque hay un grado inherente de incertidumbre, el equipo de software se embarca en un plan que sehaya establecido como consecuencia de dichas tareas.

ÁMBITO Y FACTILIDAD DEL SOFTWARE

El ámbito del software describe las funciones y características que se entregan a los usuarios finales; los datos que son entrada y salida; el “contenido” que se presenta a los usuarios como consecuencia de usar el software y el desempeño, las restricciones, las interfaces y la confiabilidad que se ligan al sistema.

El ámbito se define usando una de dos técnicas:

1. Una descripción narrativa del ámbito del software se desarrolla después de la comunicación con todos losparticipantes.

2. Los usuarios finales desarrollan un conjunto de casos de uso.

Las funciones descritas en el enunciado del ámbito (o dentro de los casos de uso) se evalúan y en algunoscasos se desglosan para proporcionar más detalle, previamente al comienzo de la estimación. Puesto que lasestimaciones de costo y calendario están funcionalmente orientadas, con frecuencia es útil cierto grado dedescomposición.

RECURSOS

La segunda tarea en la planificación es la estimación de los recursos requeridos para lograr el esfuerzode desarrollo del software.

Recursos humanos

El planificador comienza por evaluar el ámbito del software y seleccionando las habilidades requeridaspara completar el desarrollo. Se especifican tanto la posición organizacional (por ejemplo, gerente,ingeniero de software ejecutivo) como la especialidad (por ejemplo, telecomunicaciones, base dedatos, cliente-servidor).

Para proyectos relativamente pequeños (algunos persona-meses), un solo individuo puede realizartodas las tareas de ingeniería de software y consultar especialistas según lo requiera.

La figura muestra las tres principales categorías de los recursos de la ingeniería de software: personal, componentes de software reutilizables y entorno de desarrollo (herramientas de hardware y software).

Recursos de software reutilizables

Bennatan sugiere cuatro categorías de recursos de software que deben considerarse conforme avanza laplanificación:

1) Componentes comerciales: Es el software existente que puede adquirirse de una tercera parte o de unproyecto anterior.

2) Componentes de experiencia completa: Son especificaciones, diseños, código o datos de pruebaexistentes, desarrollados para proyectos anteriores que son similares al software que se va a construir parael proyecto en cuestión.

3) Componentes de experiencia parcial: Son especificaciones, diseños, código o datos de prueba existentes,desarrollados para proyectos anteriores que se relacionan con el software que se va a construir para elproyecto en cuestión, pero que requerirán modificación sustancial.

4) Componentes nuevos. Son componentes de software que el equipo de software debe construirespecíficamente para las necesidades del proyecto en cuestión.

Recursos ambientales

El entorno que soporta a un proyecto de software, con frecuencia llamado entorno de ingeniería desoftware (EIS), incorpora hardware y software. El hardware proporciona una plataforma que soporta lasherramientas (software) requeridas para producir los productos operativos que son resultado de labuena práctica de la ingeniería de software.

Cuando un sistema basado en computadora (que incorpore hardware y software especializados) debesometerse a ingeniería, el equipo de software puede requerir acceso a elementos de hardware que se vaa desarrollar por otros equipos de ingeniería.

ESTIMACIÓN DE PROYECTOS DE SOFTWARE

la estimación del proyecto de software puede transformarse de un arte oscuro a una serie de pasos sistemáticos que proporcionen estimaciones con riesgo aceptable. Para lograr estimaciones confiables de costo y esfuerzo, surgen algunas opciones:

1. Retrase la estimación hasta avanzado el proyecto (obviamente, ¡puede lograr estimaciones

100 por ciento precisas después de que el proyecto esté completo!).

2. Base las estimaciones en proyectos similares que ya estén completos.

3. Use técnicas de descomposición relativamente simples para generar estimaciones de

costo y esfuerzo de proyecto.

4. Use uno o más modelos empíricos para estimación de costo y esfuerzo de software.

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.

Técnicas de descomposición

La estimación del proyecto de software es una forma de resolución de problemas y, en la mayoría de los casos, el problema por resolver; es decir, desarrollar una estimación de costo y esfuerzo para un proyecto de software es muy complejo como para considerarse en una sola piez.

Dimensionamiento del software

La precisión de una estimación de proyecto de software se basa en algunas cosas:

1) el grado en el que se estimó adecuadamente el tamaño del producto que se va a construir.

2) la habilidad para traducir la estimación de tamaño en esfuerzo humano, tiempo calendario y dinero

3) el grado en el que el plan del proyecto refleja las habilidades del equipo de software

4) la estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de ingeniería de software

Estimación basada en problema

Los datos LOC y PF se usan en dos formas durante la estimación del proyecto de software:

1) como variables de estimación para “dimensionar” cada elemento del software

2) como métricas de referencia recopiladas de proyectos pasados y utilizadas en conjunto con variables de estimación para desarrollar proyecciones de costo y esfuerzo.

Un ejemplo de estimación basada en LOC

considere un paquete de software que se va a desarrollar para una aplicación de diseño asistido por computadora para componentes mecánicos

Estimación basada en proceso

Es decir, el proceso se descompone en un conjunto relativamente pequeño de tareas y se estima el esfuerzo requerido para lograr cada tarea. Como en las técnicas basadas en problemas, la estimación basada en proceso comienza con un delineado de las funciones de software obtenidas del ámbito del proyecto. Para cada función debe realizarse una serie de actividades de marco conceptual.

Un ejemplo de estimación basada en proceso

Estimación con casos de uso

Sin embargo, desarrollar un enfoque de estimación con casos de uso es problemático por las siguientes razones [Smi99]:

• Los casos de uso se describen usando muchos formatos y estilos diferentes; no existe una forma estándar.

• Los casos de uso representan una visión externa (la visión del usuario) del software y, por tanto, pueden escribirse en muchos niveles de abstracción diferentes.

• Los casos de uso no abordan la complejidad de las funciones y de las características que se describen.

• Los casos de uso pueden describir comportamiento complejo (por ejemplo, interacciones) que involucran muchas funciones y características.

Un ejemplo de estimación basada en caso de uso

Reconciliación de estimaciones

como resultado estimaciones múltiples que deben reconciliarse para producir una sola estimación de esfuerzo, duración de proyecto o costo.

MODELOS DE ESTIMACIÓN EMPÍRICAS

Un modelo de estimación para software de computadora usa formulas empíricamente inferidas para predecir el esfuerzo como una función de LOC o PF

Los datos empíricos que soportan a la mayoría de los modelos de estimación se infieren de una muestra limitada de proyectos. Por esta razón, ningún modelo de estimación es adecuado para todas las clases de software y en todos los entornos de desarrollo.

Se deben hacer pruebas, si la concordancia es pobre , el modelo debe afinarse y volverse a probar antes de poder usarse.

La estructura de los modelos de estimación

Un modelo de estimación típico se infiere usando análisis de regresión sobre los datos recopilados

de proyectos de software anteriores. La estructura global de tales modelos toma la forma

E = A + B X (ev)^C

donde A, B y C son constantes derivadas empíricamente, E es esfuerzo en persona-meses y ev es la variable de estimación (LOC o PF).

El modelo COCOMO II

Constructive Cost Model: modelo de construcción de costos.

Modelo de composición de aplicación. Se usa durante las primeras etapas de la ingeniería de software, cuando son primordiales la elaboración de prototipos de las interfaces de usuario, la consideración de la interacción del software y el sistema, la valoración del rendimiento y la evaluación de la madurez de la tecnología.

• Modelo de etapa temprana de diseño. Se usa una vez estabilizados los requisitos y establecida

la arquitectura básica del software.

• Modelo de etapa postarquitectónica. Se usa durante la construcción del software.

La ecuación del software

Es un modelo dinámico multivariable que supone una distribución de esfuerzo especifica durante la vida de un proyecto de desarrollo del software. El modelo se infirió a partir de datos de productividad recopilados por más de 4 000 proyectos de software contemporáneos. Con base en dichos datos, se infiere un modelo de estimación de la forma

donde

E = esfuerzo en persona-meses o persona-años

t =duración del proyecto en meses o años

B = “factor de habilidades especiales”

P =“parámetro de productividad” que refleja: madurez global del proceso y prácticas administrativas,

la medida en la que se usan buenas prácticas de ingeniería de software, el nivel de lenguajes de programación utilizado, el estado del entorno de software, las habilidades y experiencia del equipo de software y la complejidad de la aplicación.

ESTIMACIÓN PARA PROYECTOS ORIENTADOS A OBJETOS

Los métodos de estimación de costo de software convencional con una técnica que se diseñó explícitamente para software OO. Lorenz y Kidd sugieren lo siguiente:

1. Desarrollar estimaciones usando descomposición de esfuerzo, análisis PF y cualquier otro método que sea aplicable para aplicaciones convencionales.

2. Usar el modelo de requisitos (capítulo 6), desarrollar casos de uso y determinar un conteo. Reconocer que el número de casos de uso puede cambiar conforme avance el proyecto.

3. A partir del modelo de requisitos, determinar el número de clases clave

4. Categorizar el tipo de interfaz para la aplicación y desarrollar un multiplicador para clases de apoyo:

Multiplique el número de clases clave (paso 3) por el multiplicador a fin de obtener una

estimación para el número de clases de apoyo.

5. Multiplicar el número total de clases (clave + apoyo) por el número promedio de unidades de trabajo por clase.

6. Comprobación cruzada de la estimación basada en clase, multiplicando el número promedio de unidades de trabajo por caso de uso.

TÉCNICAS DE ESTIMACIÓN ESPECIALIZADAS

Estimación para desarrollo ágil.

Los requisitos para un proyecto ágil, se definen mediante un conjunto de escenarios de usuario.

Se tiene un enfoque estimado para el desarrollo de un incremento de software de corta duración el cual tiene dos propósitos:

Asegurarse de que el número de escenarios que se van a incluir en el incremento se ajusta a los recursos disponibles.

Establecer una base para asignar esfuerzo conforme se desarrolla el incremento.

Estimación para webapp.

Puntos de función para estimación de webapps:

Entrada: Cada pantalla o formulario de entrada, así como cualquier etiqueta.

Salida: Cada pagina web estática, cada guión de pagina web dinámica y cada reporte.

Tablas: Cada tabla lógica en la base de datos.

Interfaces: Conservar su definición como archivos lógicos dentro de las fronteras del sistema.

Consulta: Cada una de las publicaciones externas o el uso de una interfaz.

26.10 LA DECISIÓN HACER/COMPRAR

1) el software puede comprarse (o licenciarse) de manera comercial, 2) los componentes de software de “experiencia completa” o “experiencia parcial”pueden adquirirse y luego modificarse e integrarse para satisfacer necesidades específicas

3) el software puede construirse a la medida por parte de un contratista externo para satisfacer las especificaciones del comprador.

Creación de un árbol de decisión

Los pasos recién descritos pueden aumentar usando técnicas estadísticas como el análisis de árbol de decisión.

Outsourcing

Como concepto, el outsourcing (la subcontratación) es extremadamente simple. Las actividades de ingeniería de software se contratan a una tercera parte, que hace el trabajo a un costo más bajo y, con un poco de suerte, con mayor calidad.

puede ser estratégica o táctica. En el nivel estratégico, los gerentes empresariales consideran si una porción significativa de todo el trabajo de software puede contratarse a otros. En el nivel táctico, un gerente de proyecto determina si parte o todo un proyecto puede lograrse mejor al subcontratar el trabajo de software

Preguntas

1. ¿Son las 3 medidas de las métricas del diseño arquitectónico?

Complejidad estructuralComplejidad de datosComplejidad del sistema

2. ¿Qué significa COCOMO?

Constructive Cost model o modelo de construcción de costos.

3. ¿Significado de MPM?

Meta/Pregunta/Métrica.

4. Mencione 3 actividades de las cinco que menciona Roche…

Formulación, Recolección, Análisis, Interpretación y Retroalimentación.