E-Clases
Ingenieria de Software V
Home
SIA: Definiciones
SIA: Centros de Cómputo
SIA: Areas de Administracion de un CC
SIA: Técnicas y sistemas de gestión de la innovación
Matematicas
SIA II - Proyecto
Códigos para Programadores
Bases de Datos I
Diseño Páginas Web
Curso de Ingles Diciembre 2003
Ingles Tecnico
CENAFOM - Computación 02076
Ingenieria de Software I
Ingenieria de Software II
Ingenieria de Software III
Ingenieria de Software IV
Ingenieria de Software V
Ingenieria de Software VI
Ingenieria de Software VII
Ingenieria de Software VIII
Ingenieria de Software IX
Ingenieria de Software X
Ingenieria de Software XI
Encuestas y Libro de Visitas
Sitios Web
De todo Un Poco
Servicio Tecnico
Nuestros Clientes
Trabajos
Introducción a la Programación

clases2.jpg

Estimación de Proyectos de Software:

Estimación

Su objetivo es permitir al administrador del proyecto hacer estimaciones razonables de recursos, costo y tiempo. Dentro de la planeación existen las siguientes actividades:

  • Determinar el medio ambiente del software. Hay que evaluar:
    • La función. ¿Qué hace?
    • El rendimiento. Requisitos de tiempos de respuesta y de procesamiento.
    • Las restricciones. Límites del software originados por el hardware externo, por la memoria disponible o por otros sistemas existentes.
    • Las interfaces. Definir la comunicación hombre-máquina y máquina-máquina.
    • La fiabilidad. Definir la tolerancia a fallas y a ataques de virus y/o hackers.
    Para obtener el medio ambiente la técnica mas usada es la entrevista con el cliente.

  • Estimación de recursos requeridos. Cada recurso queda especificado mediante cuatro características: descripción del recurso, informe de disponibilidad, fecha en la que se requiere el recurso, tiempo durante el que será aplicado el recurso. Se puede pensar en tres clases de recursos:

    1. Recursos de hardware y software.
    2. Recursos de software reutilizables. Existen cuatro categorías de recursos de software que se deben tomar en cuenta.
      • Componentes ya desarrollados. Se pueden comprar a un tercero o haber sido desarrollados para un proyecto anterior. Están validados totalmente y listos para usarse en este proyecto.
      • Componentes ya experimentados. Existen componentes parecidos a los que se requieren para el proyecto actual. El equipo tiene experiencia en el área de aplicación y los cambios son mínimos.
      • Componentes con experiencia parcial. Existen componentes que se relacionan con los que se requieren para el proyecto actual. El equipo sólo tiene experiencia en el área de aplicación anterior y los cambios serán sustanciales.
      • Componentes nuevos. Los componentes deben construirse específicamente para este proyecto.

      Hay que considerar lo siguiente:

      • Si los componentes ya desarrollados cumplen con los requisitos del proyecto, hay que comprarlos. El costo de compra y de integración será siempre menor que el costo de desarrollarlos. Además el riesgo es bajo.
      • Si se dispone de componentes ya experimentados, los riesgos asociados a la modificación e integración generalmente se aceptan.
      • Si se dispone de componentes con experiencia parcial, hay que analizar su uso con cuidado. Puede ser que el costo de modificarlos e integrarlos sea mayor que el de desarrollar componentes nuevos.
    3. Recursos humanos. Hay que especificar el esfuerzo requerido en hombres-mes u hombres-año, el número de personas dependiendo del tiempo de entrega y la posición de las personas dentro del equipo (jefe, programador, bibliotecario, especialista en comunicaciones, base de datos, microprocesadores, etc.). Las técnicas para estimación de esfuerzo vienen a continuación.

Estimación del proyecto

Para realizar estimaciones de costos y esfuerzos hay tres opciones:

  1. Basar las estimaciones en proyectos similares ya terminados.
    • Es razonable si el cliente, condiciones de administración, el medio ambiente, los requisitos, las fechas límites, son similares a proyectos anteriores.
    • A pesar de eso la experiencia anterior no ha sido siempre un buen indicador de resultados futuros.
  2. Utilizar técnicas de descomposición del problema.
    • Utilizan un enfoque de divide y vencerás.
    • Descomponen el proyecto en sus funciones principales y la estimación del costo y esfuerzo puede realizarse en base a métricas históricas de manera más fiable.
  3. Desarrollar un modelo empírico de cálculo de costos y esfuerzos.
    • Se basan en datos históricos y son de la forma d = f (vi) donde d es el valor estimado (p.e. esfuerzo, costo, duración del proyecto) y los vi son algunos parámetros independientes (p.e. LOC o PF estimados).

Técnicas de descomposición

Estimación basada en el problema.

Ejemplo de estimación basada en LOC.

Supongamos que nos piden hacen un sistema que implemente las principales operaciones con matrices, que tenga una interface gráfica y un reporteador. El primer paso es analizar el problema y descomponerlo en tareas que sean más fáciles de estimar. Digamos que después de un estudio a fondo, nos damos cuenta que necesitamos tres módulos o tareas específicas:

  • Interface gráfica.
  • Rutinas matemáticas para procesar matrices.
  • Reportes
Y digamos que en base a datos históricos, de sistemas que hayamos realizado, obtenemos los siguientes estimados.

Módulo LOC estimadas.
Optimista Medio Pesimista Esperado
Interface gráfica 1,200 1,800 3,000 1,900
Rutinas matemáticas 3,000 4,200 6,000 4,300
Reportes 600 1,200 1,800 1,200
Total 7,400

Si en base a los datos históricos sabemos que tenemos una productividad media de 500 LOC/hombre-mes, podemos calcular que el esfuerzo de desarrollar el sistema será de (7,400 / 500) = 15 hombres-mes (siempre hay que redondear hacia arriba). Y si cada hombre-mes cuesta $10,000 (entre sueldos y gastos extras), entonces el costo del sistema será de $150,000.

Ejemplo de estimación basada en PF.

Si queremos hacer una estimación del mismo sistema, pero usando ahora PF, en vez de tratar de estimar las LOC que tendrá el sistema, tratamos de estimar cada uno de los valores necesarios para calcular el PF. Digamos que después del análisis, llegamos a los siguientes valores:

Valores del dominio de información

Dominio de información Cuenta Peso Subtotal
Optimista Medio Pesimista Esperado
Número de entradas 7 8 10 8 4 32
Número de salidas 4 5 7 5 5 25
Número de peticiones 5 7 9 7 4 28
Número de archivos 1 1 2 1 10 10
Número de interfaces externas 1 1 2 1 7 7
Total T 102

Factores

Factor Valor
Copia de seguridad y recuperación 4
Comunicaciones de datos 2
Proceso distribuido 0
Rendimiento crítico 4
Entorno operativo existente 3
Entrada de datos en línea 4
Transacciones de entrada en múltiples pantallas 5
Archivos maestros actualizados en línea 2
Complejidad de valores del dominio de información 5
Complejidad del procesamiento interno 5
Código diseñado para ser reusado 4
Conversión/instalación en diseño 3
Instalaciones múltiples 5
Aplicación diseñada para el cambio 5
Total F 51

Aplicando la fórmula PF = T * (0.65 + 0.01 * F), se obtiene que PF = 118.

Si los datos históricos indican que nuestra productividad es de 7 PF / hombre-mes, entonces el esfuerzo requerido será de (118 / 7) = 17 hombres-mes, y si el costo por hombre-mes es de $10,000, entonces el costo del proyecto será de $170,000.

Modelos empíricos de estimación

  • Utilizan fórmulas derivadas empíricamente de una muestra limitada de proyectos para predecir el esfuerzo en función de LOC o PF.
  • La estimación de los valores de LOC y PF se realizan utilizando las técnicas de descomposición vistas con anterioridad.
  • Los valores resultantes se aplican a la fórmula del modelo que se haya escogido para obtener el esfuerzo en hombres-mes.
  • Precisamente por venir de una muestra limitada, no son adecuados para toda clase de software ni para todo medio ambiente de desarrollo.

Algunos modelos

E = 5.2 * KLOC0.91 Modelo de Walston-Felix
E = 5.5 + 0.73 * KLOC1.16 Modelo de Bailey-Basisli
E = 3.2 * KLOC1.05 Modelo simple de Boehm
E = 5.288 * KLOC1.047 Modelo Doty para KLOC > 9
E = -13.39 + 0.054 * PF Modelo de Albretch-Gaffney
E = 60.62 * 7.728 * 10-8 * PF3 Modelo de Kemerer
E = 585.7 + 15.12 * PF Modelo de Matson-Barnett-Mellichamp

Modelo COCOMO

Creado por Barry Boehm en 1981. Su nombre significa COnstructive COst MOdel (Modelo constructivo de costo) y se puede dividir en tres modelos.

  • COCOMO básico. Calcula el esfuerzo y el costo del desarrollo en función del tamaño del programa estimado en LOC.
  • COCOMO intermedio. Calcula el esfuerzo del desarrollo en función del tamaño del programa y un conjunto de conductores de costo que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.
  • COCOMO detallado. Incorpora las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costo en cada fase (análisis, desarrollo, etc.) del proceso.

Los modelos COCOMO están definidos para tres tipos de proyectos de software:

  • Orgánicos.
    • Proyectos pequeños y sencillos.
    • Equipos pequeños con experiencia en la aplicación.
    • Requisitos poco rígidos.
  • Semiacoplados.
    • Proyectos de tamaño y complejidad intermedia.
    • Equipos con variado niveles de experiencia.
    • Requisitos poco o medio rígidos.
  • Empotrados.
    • Proyectos que deben ser desarrollados con un conjunto de requisitos (hardware y software) muy restringidos.
COCOMO básico

Las ecuaciones del modelo COCOMO básico son de la forma:

E = a * KLOCb
D = c * Ed         

donde E es el esfuerzo aplicado en hombre-mes, D es el tiempo de desarrollo en meses y KLOC es el número de miles de líneas de código estimado para el proyecto. Los coeficientes a y c y los exponentes b y d se obtienen de la siguiente tabla:

Tipo de proyecto a b c d
Orgánico 2.4 1.05 2.5 0.38
Semiacoplado 3.0 1.12 2.5 0.35
Empotrado 3.6 1.20 2.5 0.32

Aplicando el modelo COCOMO básico al ejemplo anterior y usando un tipo de proyecto orgánico obtenemos una estimación para el esfuerzo:

E = 2.4 * KLOC1.05  
= 2.4 * 7.41.05     
= 20 hombre-mes

Para calcular la duración del proyecto usamos la estimación de esfuerzo:

D = 2.5 * E0.38     
= 2.5 * 200.38
= 8 meses     

El valor de la duración del proyecto permite al planificador recomendar un número de personas N para el proyecto.

N = E / D           
= 20 / 8       
= 3 personas

Por supuesto que el planificador puede decidir emplear sólo una o dos personas y ampliar por tanto la duración del proyecto.

COCOMO intermedio

En el COCOMO intermedio, la ecuación para calcular el tiempo de desarrollo es la misma que la del COCOMO básico. La ecuación para calcular el esfuerzo es:

E = a * KLOCb * EAF

donde E es el esfuerzo en hombre-mes, KLOC es el número estimado de miles de líneas de código. El coeficiente a y el exponente b están dados por la tabla:

Tipo de proyecto a b
Orgánico 3.2 1.05
Semiacoplado 3.0 1.12
Empotrado 2.8 1.20

y EAF es un factor de ajuste del esfuerzo que se calcula valorando en una escala de muy bajo, bajo, nominal, alto y muy alto cada uno de los siguientes 15 atributos, agrupados en 4 categorías

  • Atributos del producto. Son restricciones y requerimientos del proyecto que va a ser desarrollado.
    • Confiabilidad requerida.
    • Tamaño de la base de datos.
    • Complejidad del producto.
  • Atributos de computadora. Son limitaciones puestas por el hardware y el sistema operativo donde el proyecto va a correr.
    • Restricciones de tiempo de ejecuccion.
    • Restricciones de memoria principal.
    • Volatilidad de la máquina virtual.
    • Tiempo de respuesta de la computadora.
  • Atributos de personal. Nivel de habilidades que tiene el personal. Son habilidades profesionales generales, habilidad de programación, experiencia con el medio ambiente de desarrollo y familiaridad con el dominio del proyecto.
    • Capacidad del analista.
    • Experiencia en aplicaciones.
    • Capacidad del programador.
    • Experiencia con la máquina virtual.
    • Experiencia con el lenguaje de programación.
  • Atributos del proyecto. Restricciones y condiciones bajo las cuales el proyecto se desarrolla.
    • Prácticas modernas de programación
    • Uso de herramientas de software.
    • Calendario de desarrollo requerido.

A cada atributo se le asigna un número real de acuerdo a la tabla siguiente:

Escala Número
muy bajo 0.75
bajo 0.88
nominal 1
alto 1.15
muy alto 1.40

El número indica el grado con el que cada factor puede influenciar la productividad. Un valor menor que 1 indica que el factor puede decrementar el calendario y el esfuerzo. Un valor mayor que 1 denota un factor que extiende el calendario y el esfuerzo. Finalmente, un valor igual a 1 no extiende ni decrementa el calendario y el esfuerzo (esta clase de factor se llama nominal). Para obtener el EAF se multiplican cada uno de los 15 factores.

Se puede simplificar el cálculo del EAF porque hay una tendencia a considerar los atributos marcados en negritas, como los más relevantes y que deberían ser tomados más en cuenta.

La ecuación del software

  • Propuesta por Putnam y Myers en 1992.
  • Asume una distribución específica del esfuerzo a lo largo de la vida de un proyecto.
  • Se obtuvo a partir de datos de productividad de unos 4,000 proyectos.
  • Es de la forma:

    E = (LOC * B0.333 / P)3 * (1 / t4)

    donde E = esfuerzo en hombres-año.
      t = duración del proyecto en años.
      B = factor especial de destrezas. Para programas pequeños B vale 0.16, para programas intermedios vale 0.28, para programas mayores vale 0.39.
      P = parámetro de productividad, para un software de tiempo real, P vale 2,000, para comunicaciones vale 10,000, para software científico vale 12,000 y para aplicaciones comerciales de sistemas vale 28,000.

  • Para simplificar el proceso de estimación se sugiere un conjunto de ecuaciones obtenidas de la ecuación del software.
  • Un tiempo mínimo de desarrollo de software se define como:

    tmin = 8.14 * (LOC / P)0.43 para tmin > 6 meses.                                                          
    E = 180 * B * t3 en hombres-mes para E >= 20 hombres-mes y t representado en años

    Aplicando las ecuaciones al ejemplo anterior, obtenemos:

    tmin = 8.14 * (7,400 / 12,000)0.43
    = 7 meses                     
    E = 180 * 0.28 * 0.753                
    = 21 hombres-mes                

La decisión de desarrollar o comprar

Hay varias opciones de compra de software:

  • Comprarlo (con licencia) ya desarrollado.
  • Comprar componentes de software total o parcialmente experimentado y modificarse para cumplir las necesidades específicas.
  • Encargarlo para su desarrollo a la medida a una empresa externa.

En algunos casos (p.e. software para PC de bajo costo), es menos caro comprar y experimentar que llevar a cabo una larga evaluación de paquetes.

Para productos de software más caros, se pueden aplicar las directrices siguientes:

  1. Desarrollar especificaciones.
  2. Estimación del costo de desarrollo interno y fecha de entrega.
  3. Seleccionar 3 o 4 aplicaciones candidatas o componentes reusables.
  4. Hacer una matriz de compración checando una a una las funciones claves o hacer un benchmark.
  5. Evaluar cada paquete de software o componente según la calidad de productos anteriores, soporte del vendedor, reputación, etc.
  6. Contacto con otros usuarios del paquete.

En el análisis final, la decisión de desarrollar o comprar se basa en las condiciones siguientes:

  • ¿La fecha de entrega del software es anterior que la del software desarrollado internamente?
  • ¿El costo de adquisición junto con el de personalización es menor que el costo del desarrollo interno?
  • ¿El costo del soporte externo (contrato de mantenimiento) es menor que el costo del soporte interno?

WorldPrime Computacion (C) 2004