SlideShare una empresa de Scribd logo
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:
          o La función. ¿Qué hace?
          o El rendimiento. Requisitos de tiempos de respuesta y de procesamiento.
          o Las restricciones. Límites del software originados por el hardware externo, por la memoria disponible o por otros
             sistemas existentes.
          o Las interfaces. Definir la comunicación hombre-máquina y máquina-máquina.
          o La fiabilidad. Definir la tolerancia a fallas y a ataques de virus y/o hackers.

       Para obtener el medio ambiente la técnica más 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.
          o Es razonable si el cliente, condiciones de administración, el medio ambiente, los requisitos, las fechas límites, son
              similares a proyectos anteriores.
          o 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.
          o Utilizan un enfoque de divide y vencerás.
          o 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.
          o 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.

      Puede usarse LOC o PF para hacer estimaciones.
      Si se utiliza LOC, la descomposición es esencial y a menudo debe ser a detalle.
      Si se utiliza PF, en vez de centrar la descomposición en la función, se calcula el PF como se estudió en la sesión
       anterior, estimando de alguna forma, cada uno de los valores.
      En ambos casos, mediante datos históricos o la intuición, se estiman valores optimista (O), medio (M) y pesimista (P)
       para cada función o contador, y se calcula el valor esperado (E) con la siguiente fórmula:

                                                        E = (O + 4 * M + P) / 6

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.
                                                         LOC estimadas.
            Módulo
                                      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

                                               Cuenta
 Dominio de información                                              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
                                        1          1          2            1        7        7
externas
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.
          o Proyectos pequeños y sencillos.
          o Equipos pequeños con experiencia en la aplicación.
          o Requisitos poco rígidos.
      Semiacoplados.
          o Proyectos de tamaño y complejidad intermedia.
          o Equipos con variado niveles de experiencia.
          o Requisitos poco o medio rígidos.
      Empotrados.
          o 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.
           o Confiabilidad requerida.
           o Tamaño de la base de datos.
           o Complejidad del producto.
      Atributos de computadora. Son limitaciones puestas por el hardware y el sistema operativo donde el proyecto va a
       correr.
           o Restricciones de tiempo de ejecuccion.
           o Restricciones de memoria principal.
           o Volatilidad de la máquina virtual.
           o 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.
           o Capacidad del analista.
           o Experiencia en aplicaciones.
           o Capacidad del programador.
           o Experiencia con la máquina virtual.
o   Experiencia con el lenguaje de programación.
      Atributos del proyecto. Restricciones y condiciones bajo las cuales el proyecto se desarrolla.
           o Prácticas modernas de programación
           o Uso de herramientas de software.
           o 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?

Más contenido relacionado

Similar a Estimacion de Proyectos, Ingeniería de Software

Modelo cocomo
Modelo cocomo Modelo cocomo
Modelo cocomo
mireya2022
 
Cocomo
CocomoCocomo
Cocomo
Hugo Galvan
 
MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)
Yadith Miranda Silva
 
Planificacion De Proyectos De Software
Planificacion De Proyectos De SoftwarePlanificacion De Proyectos De Software
Planificacion De Proyectos De Software
Iván Sanchez Vera
 
Clase 6, 5/9/2007
Clase 6, 5/9/2007Clase 6, 5/9/2007
Clase 6, 5/9/2007
Christian Sifaqui
 
Ingenieria software
Ingenieria softwareIngenieria software
Ingenieria software
Iván Sanchez Vera
 
Estimacion De Proyecto
Estimacion De ProyectoEstimacion De Proyecto
Estimacion De Proyecto
javier
 
Calculo de esfuerzo en puntos de funcion final
Calculo de esfuerzo en puntos de funcion finalCalculo de esfuerzo en puntos de funcion final
Calculo de esfuerzo en puntos de funcion final
Omar Ordoñez
 
Modelos empiricos de_estimacion
Modelos empiricos de_estimacionModelos empiricos de_estimacion
Modelos empiricos de_estimacion
danymieres33
 
Ra semana 8
Ra semana 8Ra semana 8
Ra semana 8
victdiazm
 
Estimación para proyectos de software cap26
Estimación para proyectos de software cap26Estimación para proyectos de software cap26
Estimación para proyectos de software cap26
DEBANI SALAS
 
eog00-t4.ppt
eog00-t4.ppteog00-t4.ppt
eog00-t4.ppt
Raulneko090523667ram
 
Administración de proyectos de desarrollo de software
Administración de proyectos de desarrollo de softwareAdministración de proyectos de desarrollo de software
Administración de proyectos de desarrollo de software
jose_macias
 
MÉTRICAS PARA ASEGURAR LA CALIDAD DEL SOFTWARE
MÉTRICAS PARA ASEGURAR LA CALIDAD DEL SOFTWAREMÉTRICAS PARA ASEGURAR LA CALIDAD DEL SOFTWARE
MÉTRICAS PARA ASEGURAR LA CALIDAD DEL SOFTWARE
David Leon Sicilia
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
Andrés Felipe Montoya Ríos
 
Tema 3 estimacion
Tema 3 estimacionTema 3 estimacion
Tema 3 estimacion
everfavi0
 
Estimación temprana de proyectos software #pmot #pmlat @iprocuratio
Estimación temprana de proyectos software #pmot #pmlat @iprocuratioEstimación temprana de proyectos software #pmot #pmlat @iprocuratio
Estimación temprana de proyectos software #pmot #pmlat @iprocuratio
Alfonso Tienda Braulio MBA, PRINCE2®, PMP®, LION
 
Gestión de Proyectos Informáticos
Gestión de Proyectos InformáticosGestión de Proyectos Informáticos
Gestión de Proyectos Informáticos
Pilar Pardo Hidalgo
 
Gestion de proyectos de SW
Gestion de proyectos de SWGestion de proyectos de SW
Gestion de proyectos de SW
Pilar Pardo Hidalgo
 
Id sw06
Id sw06Id sw06

Similar a Estimacion de Proyectos, Ingeniería de Software (20)

Modelo cocomo
Modelo cocomo Modelo cocomo
Modelo cocomo
 
Cocomo
CocomoCocomo
Cocomo
 
MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)MODELO COCOMO (INGENIERA DE SOFTWARE)
MODELO COCOMO (INGENIERA DE SOFTWARE)
 
Planificacion De Proyectos De Software
Planificacion De Proyectos De SoftwarePlanificacion De Proyectos De Software
Planificacion De Proyectos De Software
 
Clase 6, 5/9/2007
Clase 6, 5/9/2007Clase 6, 5/9/2007
Clase 6, 5/9/2007
 
Ingenieria software
Ingenieria softwareIngenieria software
Ingenieria software
 
Estimacion De Proyecto
Estimacion De ProyectoEstimacion De Proyecto
Estimacion De Proyecto
 
Calculo de esfuerzo en puntos de funcion final
Calculo de esfuerzo en puntos de funcion finalCalculo de esfuerzo en puntos de funcion final
Calculo de esfuerzo en puntos de funcion final
 
Modelos empiricos de_estimacion
Modelos empiricos de_estimacionModelos empiricos de_estimacion
Modelos empiricos de_estimacion
 
Ra semana 8
Ra semana 8Ra semana 8
Ra semana 8
 
Estimación para proyectos de software cap26
Estimación para proyectos de software cap26Estimación para proyectos de software cap26
Estimación para proyectos de software cap26
 
eog00-t4.ppt
eog00-t4.ppteog00-t4.ppt
eog00-t4.ppt
 
Administración de proyectos de desarrollo de software
Administración de proyectos de desarrollo de softwareAdministración de proyectos de desarrollo de software
Administración de proyectos de desarrollo de software
 
MÉTRICAS PARA ASEGURAR LA CALIDAD DEL SOFTWARE
MÉTRICAS PARA ASEGURAR LA CALIDAD DEL SOFTWAREMÉTRICAS PARA ASEGURAR LA CALIDAD DEL SOFTWARE
MÉTRICAS PARA ASEGURAR LA CALIDAD DEL SOFTWARE
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
Tema 3 estimacion
Tema 3 estimacionTema 3 estimacion
Tema 3 estimacion
 
Estimación temprana de proyectos software #pmot #pmlat @iprocuratio
Estimación temprana de proyectos software #pmot #pmlat @iprocuratioEstimación temprana de proyectos software #pmot #pmlat @iprocuratio
Estimación temprana de proyectos software #pmot #pmlat @iprocuratio
 
Gestión de Proyectos Informáticos
Gestión de Proyectos InformáticosGestión de Proyectos Informáticos
Gestión de Proyectos Informáticos
 
Gestion de proyectos de SW
Gestion de proyectos de SWGestion de proyectos de SW
Gestion de proyectos de SW
 
Id sw06
Id sw06Id sw06
Id sw06
 

Más de Marvin Romero

Procesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas OperativosProcesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas Operativos
Marvin Romero
 
Gestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas OperativosGestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas Operativos
Marvin Romero
 
Guía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de ProgramaciónGuía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de Programación
Marvin Romero
 
Guia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de ProgramacionGuia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de Programacion
Marvin Romero
 
Todo sobre Sistemas Operativos
Todo sobre Sistemas OperativosTodo sobre Sistemas Operativos
Todo sobre Sistemas Operativos
Marvin Romero
 
Estructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativoEstructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativo
Marvin Romero
 
Clasificación de los Sistemas Operativos
Clasificación de los Sistemas OperativosClasificación de los Sistemas Operativos
Clasificación de los Sistemas Operativos
Marvin Romero
 
Introducción a los Sistemas Operativos
Introducción a los Sistemas OperativosIntroducción a los Sistemas Operativos
Introducción a los Sistemas Operativos
Marvin Romero
 
Importancia de los Sistemas Operativos
Importancia de los Sistemas OperativosImportancia de los Sistemas Operativos
Importancia de los Sistemas Operativos
Marvin Romero
 
Máquina de von neumann
Máquina de von neumannMáquina de von neumann
Máquina de von neumann
Marvin Romero
 
Estructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje CEstructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje C
Marvin Romero
 
Variables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en CVariables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en C
Marvin Romero
 
Importancia de la programación estructurada opt
Importancia de la programación estructurada optImportancia de la programación estructurada opt
Importancia de la programación estructurada opt
Marvin Romero
 
Historia y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c optHistoria y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c opt
Marvin Romero
 
Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012
Marvin Romero
 
Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012
Marvin Romero
 
Metodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de SoftwareMetodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de Software
Marvin Romero
 
Especificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de SoftwareEspecificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de Software
Marvin Romero
 
Cocomo ejemplo
Cocomo ejemploCocomo ejemplo
Cocomo ejemplo
Marvin Romero
 
Planificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera partePlanificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera parte
Marvin Romero
 

Más de Marvin Romero (20)

Procesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas OperativosProcesos e Hilos, Sistemas Operativos
Procesos e Hilos, Sistemas Operativos
 
Gestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas OperativosGestion Procesos, Sistemas Operativos
Gestion Procesos, Sistemas Operativos
 
Guía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de ProgramaciónGuía de Ejercicios de Fundamentos de Programación
Guía de Ejercicios de Fundamentos de Programación
 
Guia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de ProgramacionGuia de Ejercicios Fundamentos de Programacion
Guia de Ejercicios Fundamentos de Programacion
 
Todo sobre Sistemas Operativos
Todo sobre Sistemas OperativosTodo sobre Sistemas Operativos
Todo sobre Sistemas Operativos
 
Estructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativoEstructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativo
 
Clasificación de los Sistemas Operativos
Clasificación de los Sistemas OperativosClasificación de los Sistemas Operativos
Clasificación de los Sistemas Operativos
 
Introducción a los Sistemas Operativos
Introducción a los Sistemas OperativosIntroducción a los Sistemas Operativos
Introducción a los Sistemas Operativos
 
Importancia de los Sistemas Operativos
Importancia de los Sistemas OperativosImportancia de los Sistemas Operativos
Importancia de los Sistemas Operativos
 
Máquina de von neumann
Máquina de von neumannMáquina de von neumann
Máquina de von neumann
 
Estructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje CEstructuras de Control en Lenguaje C
Estructuras de Control en Lenguaje C
 
Variables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en CVariables, Constantes y Tipos de datos en C
Variables, Constantes y Tipos de datos en C
 
Importancia de la programación estructurada opt
Importancia de la programación estructurada optImportancia de la programación estructurada opt
Importancia de la programación estructurada opt
 
Historia y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c optHistoria y caracteristicas del lenguaje c opt
Historia y caracteristicas del lenguaje c opt
 
Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012Jornalizacion Sistemas Operativos I-2012
Jornalizacion Sistemas Operativos I-2012
 
Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012Jornalizacion Fundamentos de Programación I-2012
Jornalizacion Fundamentos de Programación I-2012
 
Metodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de SoftwareMetodologías y Técnicas de Diseño de Software
Metodologías y Técnicas de Diseño de Software
 
Especificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de SoftwareEspecificación de requerimientos, Ingenieria de Software
Especificación de requerimientos, Ingenieria de Software
 
Cocomo ejemplo
Cocomo ejemploCocomo ejemplo
Cocomo ejemplo
 
Planificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera partePlanificacion y gestion de proyectos primera parte
Planificacion y gestion de proyectos primera parte
 

Estimacion de Proyectos, Ingeniería de Software

  • 1. 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: o La función. ¿Qué hace? o El rendimiento. Requisitos de tiempos de respuesta y de procesamiento. o Las restricciones. Límites del software originados por el hardware externo, por la memoria disponible o por otros sistemas existentes. o Las interfaces. Definir la comunicación hombre-máquina y máquina-máquina. o La fiabilidad. Definir la tolerancia a fallas y a ataques de virus y/o hackers. Para obtener el medio ambiente la técnica más 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.
  • 2. 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. o Es razonable si el cliente, condiciones de administración, el medio ambiente, los requisitos, las fechas límites, son similares a proyectos anteriores. o 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. o Utilizan un enfoque de divide y vencerás. o 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. o 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).
  • 3. Técnicas de descomposición Estimación basada en el problema.  Puede usarse LOC o PF para hacer estimaciones.  Si se utiliza LOC, la descomposición es esencial y a menudo debe ser a detalle.  Si se utiliza PF, en vez de centrar la descomposición en la función, se calcula el PF como se estudió en la sesión anterior, estimando de alguna forma, cada uno de los valores.  En ambos casos, mediante datos históricos o la intuición, se estiman valores optimista (O), medio (M) y pesimista (P) para cada función o contador, y se calcula el valor esperado (E) con la siguiente fórmula: E = (O + 4 * M + P) / 6 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. LOC estimadas. Módulo 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
  • 4. 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 Cuenta Dominio de información 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 1 1 2 1 7 7 externas Total T 102
  • 5. 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.
  • 6. 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
  • 7. 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. o Proyectos pequeños y sencillos. o Equipos pequeños con experiencia en la aplicación. o Requisitos poco rígidos.  Semiacoplados. o Proyectos de tamaño y complejidad intermedia. o Equipos con variado niveles de experiencia. o Requisitos poco o medio rígidos.  Empotrados. o Proyectos que deben ser desarrollados con un conjunto de requisitos (hardware y software) muy restringidos.
  • 8. 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.
  • 9. 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. o Confiabilidad requerida. o Tamaño de la base de datos. o Complejidad del producto.  Atributos de computadora. Son limitaciones puestas por el hardware y el sistema operativo donde el proyecto va a correr. o Restricciones de tiempo de ejecuccion. o Restricciones de memoria principal. o Volatilidad de la máquina virtual. o 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. o Capacidad del analista. o Experiencia en aplicaciones. o Capacidad del programador. o Experiencia con la máquina virtual.
  • 10. o Experiencia con el lenguaje de programación.  Atributos del proyecto. Restricciones y condiciones bajo las cuales el proyecto se desarrolla. o Prácticas modernas de programación o Uso de herramientas de software. o 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.
  • 11. 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
  • 12. 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?