SlideShare une entreprise Scribd logo
1  sur  41
Télécharger pour lire hors ligne
Clarena Rodriguez Pinto – 160002346
 Juan Camilo Cajamarca - 160002332
Estas técnicas de estimación son una forma de resolución de problemas en
donde, en la mayoría de los casos, el problema a resolver es demasiado
complejo    para   considerarlo  como    una   sola    parte.  Por   esta
razón, descomponemos el problema, recaracterizándolo como un conjunto de
pequeños problemas.

Las estimaciones están asociadas con el esfuerzo, costo y el tiempo de las
actividades identificadas del proyecto. El objetivo de la estimación de proyectos
es reducir los costos e incrementar los niveles de servicio y de calidad.
   COCOMO 81
   COCOMO II
   Delphi
   Analogia
   Punto de Función
   Lineas de Código
Fue desarrollado por Barry Boehmen 1981. El modelo asume que los
requerimientos son relativamente estables y que el proyecto será
administrado por el cliente y el desarrollador. El modelo entrega un orden de
magnitud de los costos del Software. Utiliza como datos el tamaño estimado
del proyecto y el tipo de producto a desarrollar.
COCOMO‟ 81 está compuesto por tres modelos que corresponden a distintos
niveles de detalle y precisión.


• Modelo COCOMO básico

• Modelo COCOMO intermedio

• Modelo COCOMO avanzado (o detallado)
Es un modelo univariable estático que calcula el esfuerzo y el tiempo del
desarrollo de software en función del tamaño del programa, expresado en
Líneas de Código (LDC) estimadas. Adecuado para hacer estimaciones de
forma rápida, aunque sin gran precisión.
Es un modelo univariable estático que calcula el esfuerzo del desarrollo de
software en función del tamaño del programa y un conjunto de “conductores
de coste”, que incluyen la evaluación subjetiva del producto, del hardware, del
personal y de los atributos del proyecto. Estos conductores del coste se
consideran como términos de impacto agregado al esfuerzo total del
proyecto.
Es un modelo que incorpora todas las características de la versión intermedia y
lleva a cabo una evaluación del impacto de los conductores de coste en cada
fase(análisis, diseño, etc.) del proceso de ingeniería de software.

La estimación es más precisa a medida que se toman en cuenta mayor
cantidad de factores que influyen en el desarrollo de un producto de
software.
  Diseño del Producto (PD)
Se define la arquitectura del hardware, software y las estructuras de datos y
control. También se desarrolla un bosquejo del manual del usuario y los planes
de aceptación y testeo.

   Diseño Detallado (DD)

  Codificación y Testeo de Unidades (CT)
En estas dos fases el diseño global de la fase anterior es
implementado, creando las componentes de software, que son testeadas y
evaluadas individualmente.
  Integración y Testeo (IT)
Se fusionan todas las componentes de software desarrolladas con el fin de
lograr que el producto de software funcione correctamente. Los requerimientos
definidos son usados para controlar las aptitudes del producto liberado. Los
costos y tiempos de las fases excluidas (Requerimientos y Mantenimiento)
deben ser estimados en forma separada empleando otros modelos.
Los modelos COCOMO están definidos para tres modos de desarrollo:


  Proyectos Orgánicos:
El equipo de desarrollo es pequeño y experimentado, en un ambiente familiar y
con aplicaciones conocidas.

  Proyectos Semiconectados (Semilibres):
El equipo de desarrollo está formado por personal experimentado y novato con
algo de experiencia en la tecnología y la aplicación. Suelen tener interacciones
con otros sistemas.

  Proyectos Integrados (Empotrados):
Tiene un gran equipo de desarrollo, pero en general    es poco experimentado en
el tema dado que se trata de proyectos casi únicos.    Corresponden a proyectos
que representan un fuerte acoplamiento entre el        Hardware, Software y los
procedimientos operacionales. La        modificación   a los requerimientos no
es práctica y los costos de validación son altos.
   E=(a(Kl)^b )*m(X) (Esfuerzo)
     “E” Salario/mes = Esfuerzo
     “a” y “b” Constante según el tipo de proyecto
     “Kl” Cantidad e Lineas de Cod.
     “m(x)” Multiplicador que depende de 15 Atributos
       Constantes.
   T=cE^d (Tiempo de Duración de Desarrollo)
   P=E/T (Cantidad de Personas)
   KLDC=(PF*L)/1000 (Kilo de Lineas de Cod.)
   ¿Que es?
   Nuevas Mejoras
   Modelos
    ◦ Composición de Aplicación
    ◦ Diseño temprano
    ◦ Post-Arquitectura
COCOMO II es un modelo que permite estimar el coste, esfuerzo y tiempo
cuando se planifica una nueva actividad de desarrollo software.

COCOMO II está adaptado a los ciclos de vida de los modelos de desarrollo de
software actuales, dado que esposible de aplicar a aquellas nuevas prácticas no
tradicionales de software como desarrollo rápido de aplicaciones, aplicaciones
no secuenciales, reusabilidad del software, reingeniería, programación orientada
a objetos, entre otras.
    Desarrollar un modelo de estimación de costo y cronograma de proyectos de
    software que se adaptara tanto a las prácticas de desarrollo de la década del
    90 como a las futuras

   Construir una base de datos de proyectos de software que permitiera la
    calibración continua del modelo, y así incrementar la precisión en la
    estimación

   Implementar una herramienta de software que soportara el modelo

   Proveer un marco analítico cuantitativo y un conjunto de herramientas y
    técnicas que evaluaran el impacto de las mejoras tecnológicas de software
    sobre los costos y tiempos en las diferentes etapas del ciclo de vida de
    desarrollo
Indicado para proyectos construidos con herramientas modernas de construcción
de interfaces gráficos para usuario
Se utiliza en las primeras etapas del desarrollo en las cuales se evalúan las
alternativas de hardware y software de un proyecto. En estas etapas se tiene
poca información, lo que concuerda con el uso de Puntos Función, para estimar
tamaño y el uso de un número reducido de factores de costo.
Este es el modelo COCOMO 2 más detallado. Puede ser utilizado después de
haber desarrollado la arquitectura global del proyecto. Utiliza nuevos parámetros
de costo, nuevas reglas de conteo de líneas y nuevas ecuaciones. Este modelo
corresponde al esfuerzo de desarrollo estimado una vez que se ha fijado la
arquitectura del sistema. Este modelo „base‟ puede ajustarse para:

 Estimaciones más tempranas, correspondiente al modelo de diseño temprano
(Pre-arquitectura).
 Mantenimiento.

 Estimación de número de defectos esperados
   Calcular el esfuerzo, el tiempo y personal que se debería implementar en el
    proyecto con los siguientes datos.

   PF=261,36
   Lenguaje – VB= 32 LDC * C/PF
   KLDC= (PF * Líneas de código por cada PF)/1000 =
    (261,36*32)/1000= 8,363
   m(x)=1,15*1,00*0,85*1,11*1,00*1,00*1,07*0,86*0,82*0,7
    0*1,00*0,95*1,00*0,91*1,08     = 0,53508480
   E = a KLDC e * FAE = 3,2 * (8.363)^1,05   * 0,53508480 =
    15,91 personas /mês
   T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses
   P = E/T = 15,91/7,15 = 2,22 personas
Fue concebido en los años cincuenta con fines militares y a partir de la
década de los sesenta ha sido utilizado en los ámbitos académicos y
empresariales. Ha sido empleado principalmente como técnica de previsión y
consenso en situaciones de incertidumbre, en las que no es posible acudir a
otras técnicas basadas en información objetiva.
   Es un proceso iterativo. Como mínimo los expertos deben ser consultados
    dos veces sobre la misma cuestión, de forma que puedan volver a pensar su
    respuesta ayudados por la información que reciben de las opiniones del
    resto de los expertos.

   Mantiene el anonimato de los participantes, o al menos de sus respuestas, ya
    que éstas van directamente al grupo coordinador. Ello permite poder
    desarrollar Un proceso de grupo con unos expertos que no coinciden ni
    temporal ni espacialmente, y además busca evitar las influencias negativas
    que en las respuestas Individuales pudieran tener factores relativos a la
    personalidad de los expertos participantes.
   Feedback controlado. El intercambio de información entre los expertos no es
    libre, sino que se realiza a través del grupo coordinador del estudio, con lo
    que se elimina toda información que no sea relevante.

   Respuesta estadística de grupo. Todas las opiniones forman parte de la
    respuesta final. Las preguntas están formuladas de forma que se pueda
    realizar un tratamiento cuantitativo y estadístico de las respuestas.
Es un método grupal para refinar el Project plan, donde participan el Project
Manager o un moderador, un recorder y estimadores. Las especificaciones se le
dan a un grupo de expertos, quienes discuten las metas del proyecto, las
suposiciones y estiman los recursos. Además, ellos hacen las estimaciones y se
las dan a un moderador, quien compila las estimaciones. Luego, cada estimador
sabe los resultados de sus estimaciones, las demás son anónimas.

Seguidamente, los expertos discuten los resultados y revisan las tareas. Este
ciclo continua hasta que las estimaciones convergen en una que se encuentre
en un rango aceptable.
Planificación: Es el primer paso del proceso Wideband delphi que comienza
con la definición y alcance del problema a estimar.

Reunión inicial:       Consiste en la comprensión sobre el problema de
estimación, en donde el equipo revisa los objetivos estimados, discute el
problema y algunos asuntos de la estimación llegando a un acuerdo sobre las
unidades de estimación (semanas, horas laborales, dólares, líneas de código)
que se usaran a lo largo del proceso.
Preparación individual: Consiste en que cada participante desarrolla
independientemente una lista inicial de tareas que deberán ser completadas
para alcanzar la meta del proyecto, donde cada participante estima el esfuerzo
que cada tarea consumirá.

Reunión de estimación: El objetivo en este paso es establecer una lista con
todas las estimaciones individuales para debatirlas en anonimato, evitando las
posibles intimidaciones entre los participantes, todo esto, con el fin de debatir
las diferentes estimaciones con el propósito de que cada integrante pueda
modificar, añadir, eliminar sus estimaciones renovando la lista obtenida
anteriormente .
Ensamblando las tareas: Es donde el moderador o Project manager ensambla
las tareas del proyecto y sus estimaciones individuales dentro de una lista
maestra definitiva de tareas, en donde se encuentran recopilados todos los
procesos trabajados con anterioridad.

Revisión de resultados: Finalmente, en este paso el equipo de estimación revisa
los resultados resumidos y llega a un acuerdo sobre el resultado final.
Ventajas                      Desventajas
Hay menos probabilidad de una   Requiere de expertos para que
     estimación negativa.           hagan la estimación.
    Esta basado en valores      No define un proceso a seguir
          históricos.            cuando se esta estimando.
El coste de un proyecto se calcula por comparación con proyectos similares en
el mismo dominio de aplicación. Es aplicable cuando otros proyectos en el
mismo dominio de aplicación se han completado. Se estima el costo de un
nuevo proyecto por analogía con estos proyectos completados.
La técnica de puntos de función fue introducida por Albrecht y su propósito es
pedir   el   software   cualificando   la  Funcionalidad    que   proporciona
externamente, basándose en el diseño lógico del sistema.

   Medir lo que el usuario pide y lo que el usuario recibe.
   Medir independientemente la tecnología utilizada en la implantación del
    sistema.
   Proporcionar una métrica de tamaño que dé soporte al análisis de la calidad y
    la productividad.
   Proporcionar un medio para la estimación del software.
El análisis de los puntos de función se desarrolla considerando cinco
parámetros básicos externos del sistema:

   Entrada (EI, del inglés External Input).
   Salida (EO, del inglés External Output).
   Consultas (EQ, del inglés External Query).
   Ficheros Lógicos Internos (ILF, del inglés Internal Logic File).
   Ficheros Lógicos Externos (EIF, del inglés External Interface File)
   Es un proceso elemental o una acción que procesa datos o información de
    control que vienen desde afuera de la frontera de la aplicación hacia
    adentro. Los datos pueden venir desde otra aplicación o desde una pantalla
    de ingreso de datos. El objetivo fundamental es mantener uno o más
    archivos lógicos internos (o ILF de Internal Logical File) y/o alterar el
    comportamiento del sistema.
   Se aplican las siguientes reglas:
    R1: Los datos se reciben desde fuera de los límites de la aplicación.
    R2: Los datos mantienen un ILF a través de un proceso elemental de la
      aplicación.
    R3: El proceso es la unidad más pequeña de actividad que es significativa
      para el negocio del usuario final.
    R4: El proceso es auto contenido y deja la aplicación que está siendo
      contada en un estado consistente.
    R5: El proceso identificado debe verificar alguna de estas reglas:
       Su lógica de proceso es única respecto de otras entradas externas de la
        aplicación.
       Los elementos de datos identificados son distintos a los de las otras EI
        de la aplicación.
       Los ficheros lógicos referenciados son diferentes
   El objetivo fundamental es presentar información al usuario a través del
    procesamiento lógico de los datos o de la información de control obtenida.

   Se aplican las siguientes reglas:
    R1: El proceso envía datos información de control.
    R2: Los datos o información de control se envían a través de un proceso
    elemental de la aplicación.
    R3: El proceso es la unidad más pequeña de actividad que es significativa
    para el negocio del usuario final.
    R4: El proceso es auto contenido y deja a la aplicación en un estado
    consistente.
R5: El proceso identificado debe verificar alguna de estas reglas:
   ◦ Su lógica de proceso es única respecto de otras salidas externas de la aplicación.
   ◦ Los elementos de datos identificados son distintos a los de otras EO‟s de la
       aplicación.
   ◦ Los ficheros lógicos referenciados son distintos.
R6: Debe cumplirse al menos una de las siguientes condiciones:
   ◦ El proceso elemental contiene al menos una fórmula matemática o cálculo.
   ◦ El proceso crea datos derivados
   ◦ El proceso que genera la salida mantiene algún ILF
   ◦ El proceso que genera la salida altera el comportamiento del sistema.
R7: La transferencia de datos a otras aplicaciones se cuenta como salidas
R8: Los informes escritos y online se cuentan como salidas independientes.
R9: Los gráficos se cuentan como una salida cada uno.
El objetivo principal de un EQ es presentar información al usuario a través
de la obtención del dato o de la información de control.

   Se aplican las siguientes reglas:
   R1: Una petición entra dentro del límite de la aplicación.
   R2: Un resultado sale del límite de la aplicación
   R3: Hay recuperación de datos
   R4: Los datos recuperados no contienen datos derivados.
   R5: El proceso lógico no contiene fórmulas matemáticas o cálculos
   R6: El proceso que genera la consulta no mantiene ningún ILF ni altera el
    comportamiento del sistema
   R7: La petición de entrada y el resultado de salida juntos, hacen del proceso
    la unidad de actividad más pequeña que es significativa para el negocio del
    usuario final.
   R8: El proceso es auto contenido y deja a la aplicación que está siendo
    contada en un estado consistente.
El objetivo fundamental de un ILF es manejar los datos mantenidos a través de
uno o más procesos elementales (o acciones) de la aplicación que está siendo
contada.

   Reglas para identificarlos:

    R1: El grupo de datos o información de control es un grupo de datos
    lógico identificable por el usuario que cubre de manera completa
    requisitos específicos de este.
    R2: El grupo de datos es mantenido dentro de los límites de la
    aplicación.
    R3: El grupo de datos es mantenido o modificado por medio de un
    proceso elemental de la aplicación.
    R4: El grupo de datos identificado no se ha contado como ELF de la
    aplicación.
El objetivo principal de un ELF es manejar los datos referenciados mediante
   uno o más procesos elementales (o acciones) dentro de la frontera de la
   aplicación contada.

   Reglas:
   R1: El grupo de datos o información de control es un grupo de datos lógico
    identificable por el usuario que cubre de manera completa requisitos
    específicos de este.
   R2: El grupo de datos es referenciado y es externo a la aplicación que está
    siendo contada.
   R3: El grupo de datos no es mantenido por la aplicación que está siendo
    contada.
   R4: El grupo de datos se ha contado como ILF en al menos otra aplicación.
   R5: El grupo de datos identificado no ha sido contado como un ILF para la
    aplicación.



                                                                      Regresar…
Es una medida propuesta inicialmente cuando los programas se escribían en
tarjetas, con una línea por tarjeta. Actualmente los lenguajes permiten escribir
varias sentencias en una línea, o una misma sentencia en varias líneas

Las LDC miden en forma directa el tamaño del producto de software. Se calculan
simplemente contando las instrucciones de código fuente de cada componente
del producto de software excluyendo, generalmente, los comentarios y blancos.
Entonces, se calcula el valor esperado de LDC. El valor esperado para la variable
de estimación, E, se obtiene como una medida ponderada de las estimaciones
LDC óptima (a), más probable (m) y pesimista (b).

Esta técnica trata de definir el tiempo y el costo del proyecto en base a la
cantidad de líneas de código se tienen que escribir, cual es el costo por línea y
cuantas líneas de código desarrollamos en un mes.

Formula:
Los pasos para desarrollar ese método son los siguientes:

   Descomponemos el problema en los módulos importantes que posea.
   Estimar los valores para las columnas de líneas a escribir optimista Más
    Probable, Pesimista
   Calcular la columna esperada en base a la fórmula
   Se coloca en la columna de "$/línea" el precio de cada línea en cada módulo, esto
    generalmente se realiza basados en los costos de proyectos anteriores.
   La siguiente casilla pertenece a cuantas líneas se pueden escribir en un mes.
   La casilla de "Coste", nos permite tener el cálculo de cuanto costaría cada
    módulo, esto se obtiene de multiplicar la columna de "$ por línea" con la de
    "Esperada".
   Los meses se calculan multiplicando las "Líneas al mes" por "Esperada"
   Al totalizarlas columnas calculadas tendríamos en la columna de "Esperada" la
    cantidad de líneas que se escribirían, el la de "Coste" el costo estimado del
    proyecto y en la de "Meses" los meses que demoraría el proyecto



                                                                             Regresar

Contenu connexe

Tendances

Ingeniería inversa y reingeniería de software
Ingeniería inversa y reingeniería de softwareIngeniería inversa y reingeniería de software
Ingeniería inversa y reingeniería de softwareMoises Medina
 
MODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMicky Jerzy
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de SoftwareCamila Arbelaez
 
Desarrollo de software basado en componentes
Desarrollo de software basado en componentesDesarrollo de software basado en componentes
Desarrollo de software basado en componentesmellcv
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareJennifer Andrea Cano Guevara
 
Especificación y resultados de las pruebas de software
Especificación y resultados de las pruebas de softwareEspecificación y resultados de las pruebas de software
Especificación y resultados de las pruebas de softwareJesús E. CuRias
 
El Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanEl Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanJuan Pablo Bustos Thames
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de softwareGeorgy Jose Sanchez
 
Análisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de softwareAnálisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de softwareAngel Reyes
 
Construccion y Pruebas de Software
Construccion y Pruebas de SoftwareConstruccion y Pruebas de Software
Construccion y Pruebas de SoftwareGustavo Bazan Maal
 
Modelos de desarrollo del software
Modelos de desarrollo del softwareModelos de desarrollo del software
Modelos de desarrollo del softwareRenny Batista
 
Planificación de proyectos de software
Planificación de proyectos de softwarePlanificación de proyectos de software
Planificación de proyectos de softwarehrubenleiva21
 
Metricas del proyecto de Software - introduccion
Metricas del proyecto de Software - introduccionMetricas del proyecto de Software - introduccion
Metricas del proyecto de Software - introduccionJose Diaz Silva
 
Fundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareFundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareNelson Guanipa
 

Tendances (20)

Ingeniería inversa y reingeniería de software
Ingeniería inversa y reingeniería de softwareIngeniería inversa y reingeniería de software
Ingeniería inversa y reingeniería de software
 
Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
 
MODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWAREMODELO DE PROCESOS DEL SOFTWARE
MODELO DE PROCESOS DEL SOFTWARE
 
Modelos concurrentes
Modelos concurrentesModelos concurrentes
Modelos concurrentes
 
Modelo TSP
Modelo TSPModelo TSP
Modelo TSP
 
Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
 
Estimación Software por Puntos de Función
Estimación Software por Puntos de FunciónEstimación Software por Puntos de Función
Estimación Software por Puntos de Función
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
Desarrollo de software basado en componentes
Desarrollo de software basado en componentesDesarrollo de software basado en componentes
Desarrollo de software basado en componentes
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
Especificación y resultados de las pruebas de software
Especificación y resultados de las pruebas de softwareEspecificación y resultados de las pruebas de software
Especificación y resultados de las pruebas de software
 
Requerimientos norma ieee830
Requerimientos norma ieee830Requerimientos norma ieee830
Requerimientos norma ieee830
 
El Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanEl Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger Pressman
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de software
 
Análisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de softwareAnálisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de software
 
Construccion y Pruebas de Software
Construccion y Pruebas de SoftwareConstruccion y Pruebas de Software
Construccion y Pruebas de Software
 
Modelos de desarrollo del software
Modelos de desarrollo del softwareModelos de desarrollo del software
Modelos de desarrollo del software
 
Planificación de proyectos de software
Planificación de proyectos de softwarePlanificación de proyectos de software
Planificación de proyectos de software
 
Metricas del proyecto de Software - introduccion
Metricas del proyecto de Software - introduccionMetricas del proyecto de Software - introduccion
Metricas del proyecto de Software - introduccion
 
Fundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareFundamentos del Diseño de Software
Fundamentos del Diseño de Software
 

En vedette

Estimación por puntos de función
Estimación por puntos de funciónEstimación por puntos de función
Estimación por puntos de funciónLuisa Sanchez
 
Estimacion De Proyecto
Estimacion De ProyectoEstimacion De Proyecto
Estimacion De Proyectojavier
 
Metricas Tecnicas Del Software
Metricas Tecnicas Del SoftwareMetricas Tecnicas Del Software
Metricas Tecnicas Del Softwarejuic
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareantonio
 
Tema 3 estimacion
Tema 3 estimacionTema 3 estimacion
Tema 3 estimacioneverfavi0
 

En vedette (6)

Estimación por puntos de función
Estimación por puntos de funciónEstimación por puntos de función
Estimación por puntos de función
 
Estimacion de costos del Software
Estimacion de costos del SoftwareEstimacion de costos del Software
Estimacion de costos del Software
 
Estimacion De Proyecto
Estimacion De ProyectoEstimacion De Proyecto
Estimacion De Proyecto
 
Metricas Tecnicas Del Software
Metricas Tecnicas Del SoftwareMetricas Tecnicas Del Software
Metricas Tecnicas Del Software
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
Tema 3 estimacion
Tema 3 estimacionTema 3 estimacion
Tema 3 estimacion
 

Similaire à Tecnicas de estimacion de software

Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de softwareClare Rodriguez
 
Estimacion De Proyecto
Estimacion De ProyectoEstimacion De Proyecto
Estimacion De Proyectojavier
 
Procesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareProcesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareAngel Macas
 
Jessika parica. planificación de un proyecto de software
Jessika parica. planificación de un proyecto de softwareJessika parica. planificación de un proyecto de software
Jessika parica. planificación de un proyecto de softwareJessika Parica
 
GA1-220501093-AA1-EV01- TRABAJO METODOLOGIAS.pdf
GA1-220501093-AA1-EV01- TRABAJO METODOLOGIAS.pdfGA1-220501093-AA1-EV01- TRABAJO METODOLOGIAS.pdf
GA1-220501093-AA1-EV01- TRABAJO METODOLOGIAS.pdfEdinsonboteroBotero
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de softwareUVM
 
GA1-220501093-AA1-EV02- INFOGRAFIA.pdf
GA1-220501093-AA1-EV02- INFOGRAFIA.pdfGA1-220501093-AA1-EV02- INFOGRAFIA.pdf
GA1-220501093-AA1-EV02- INFOGRAFIA.pdfEdinsonboteroBotero
 
RUP - Fase de Elaboración
RUP - Fase de ElaboraciónRUP - Fase de Elaboración
RUP - Fase de ElaboraciónAdrian González
 
Estimación de costo de software
Estimación de costo de softwareEstimación de costo de software
Estimación de costo de softwareJhoseph Lugo
 
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 cap26DEBANI SALAS
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rupmireya2022
 

Similaire à Tecnicas de estimacion de software (20)

Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de software
 
Estimacion De Proyecto
Estimacion De ProyectoEstimacion De Proyecto
Estimacion De Proyecto
 
Estimación para proy_soft-caja_b_y_n
Estimación para proy_soft-caja_b_y_nEstimación para proy_soft-caja_b_y_n
Estimación para proy_soft-caja_b_y_n
 
Desarrollo de Sistemas de Información
Desarrollo de Sistemas de InformaciónDesarrollo de Sistemas de Información
Desarrollo de Sistemas de Información
 
Procesos de Ingenieria de Software
Procesos de Ingenieria de SoftwareProcesos de Ingenieria de Software
Procesos de Ingenieria de Software
 
Metodologia msf
Metodologia msfMetodologia msf
Metodologia msf
 
Metodologia msf
Metodologia msfMetodologia msf
Metodologia msf
 
Metodologia msf
Metodologia msfMetodologia msf
Metodologia msf
 
Jessika parica. planificación de un proyecto de software
Jessika parica. planificación de un proyecto de softwareJessika parica. planificación de un proyecto de software
Jessika parica. planificación de un proyecto de software
 
COCOMO
COCOMOCOCOMO
COCOMO
 
Cocomo 1
Cocomo 1Cocomo 1
Cocomo 1
 
GA1-220501093-AA1-EV01- TRABAJO METODOLOGIAS.pdf
GA1-220501093-AA1-EV01- TRABAJO METODOLOGIAS.pdfGA1-220501093-AA1-EV01- TRABAJO METODOLOGIAS.pdf
GA1-220501093-AA1-EV01- TRABAJO METODOLOGIAS.pdf
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de software
 
GA1-220501093-AA1-EV02- INFOGRAFIA.pdf
GA1-220501093-AA1-EV02- INFOGRAFIA.pdfGA1-220501093-AA1-EV02- INFOGRAFIA.pdf
GA1-220501093-AA1-EV02- INFOGRAFIA.pdf
 
Cocomo
CocomoCocomo
Cocomo
 
Cocomo
CocomoCocomo
Cocomo
 
RUP - Fase de Elaboración
RUP - Fase de ElaboraciónRUP - Fase de Elaboración
RUP - Fase de Elaboración
 
Estimación de costo de software
Estimación de costo de softwareEstimación de costo de software
Estimación de costo de software
 
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
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 

Tecnicas de estimacion de software

  • 1. Clarena Rodriguez Pinto – 160002346 Juan Camilo Cajamarca - 160002332
  • 2. Estas técnicas de estimación son una forma de resolución de problemas en donde, en la mayoría de los casos, el problema a resolver es demasiado complejo para considerarlo como una sola parte. Por esta razón, descomponemos el problema, recaracterizándolo como un conjunto de pequeños problemas. Las estimaciones están asociadas con el esfuerzo, costo y el tiempo de las actividades identificadas del proyecto. El objetivo de la estimación de proyectos es reducir los costos e incrementar los niveles de servicio y de calidad.
  • 3. COCOMO 81  COCOMO II  Delphi  Analogia  Punto de Función  Lineas de Código
  • 4. Fue desarrollado por Barry Boehmen 1981. El modelo asume que los requerimientos son relativamente estables y que el proyecto será administrado por el cliente y el desarrollador. El modelo entrega un orden de magnitud de los costos del Software. Utiliza como datos el tamaño estimado del proyecto y el tipo de producto a desarrollar.
  • 5. COCOMO‟ 81 está compuesto por tres modelos que corresponden a distintos niveles de detalle y precisión. • Modelo COCOMO básico • Modelo COCOMO intermedio • Modelo COCOMO avanzado (o detallado)
  • 6. Es un modelo univariable estático que calcula el esfuerzo y el tiempo del desarrollo de software en función del tamaño del programa, expresado en Líneas de Código (LDC) estimadas. Adecuado para hacer estimaciones de forma rápida, aunque sin gran precisión.
  • 7. Es un modelo univariable estático que calcula el esfuerzo del desarrollo de software en función del tamaño del programa y un conjunto de “conductores de coste”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto. Estos conductores del coste se consideran como términos de impacto agregado al esfuerzo total del proyecto.
  • 8. Es un modelo que incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de coste en cada fase(análisis, diseño, etc.) del proceso de ingeniería de software. La estimación es más precisa a medida que se toman en cuenta mayor cantidad de factores que influyen en el desarrollo de un producto de software.
  • 9.  Diseño del Producto (PD) Se define la arquitectura del hardware, software y las estructuras de datos y control. También se desarrolla un bosquejo del manual del usuario y los planes de aceptación y testeo.  Diseño Detallado (DD)  Codificación y Testeo de Unidades (CT) En estas dos fases el diseño global de la fase anterior es implementado, creando las componentes de software, que son testeadas y evaluadas individualmente.
  • 10.  Integración y Testeo (IT) Se fusionan todas las componentes de software desarrolladas con el fin de lograr que el producto de software funcione correctamente. Los requerimientos definidos son usados para controlar las aptitudes del producto liberado. Los costos y tiempos de las fases excluidas (Requerimientos y Mantenimiento) deben ser estimados en forma separada empleando otros modelos.
  • 11. Los modelos COCOMO están definidos para tres modos de desarrollo:  Proyectos Orgánicos: El equipo de desarrollo es pequeño y experimentado, en un ambiente familiar y con aplicaciones conocidas.  Proyectos Semiconectados (Semilibres): El equipo de desarrollo está formado por personal experimentado y novato con algo de experiencia en la tecnología y la aplicación. Suelen tener interacciones con otros sistemas.  Proyectos Integrados (Empotrados): Tiene un gran equipo de desarrollo, pero en general es poco experimentado en el tema dado que se trata de proyectos casi únicos. Corresponden a proyectos que representan un fuerte acoplamiento entre el Hardware, Software y los procedimientos operacionales. La modificación a los requerimientos no es práctica y los costos de validación son altos.
  • 12. E=(a(Kl)^b )*m(X) (Esfuerzo) “E” Salario/mes = Esfuerzo “a” y “b” Constante según el tipo de proyecto “Kl” Cantidad e Lineas de Cod. “m(x)” Multiplicador que depende de 15 Atributos Constantes.  T=cE^d (Tiempo de Duración de Desarrollo)  P=E/T (Cantidad de Personas)  KLDC=(PF*L)/1000 (Kilo de Lineas de Cod.)
  • 13. ¿Que es?  Nuevas Mejoras  Modelos ◦ Composición de Aplicación ◦ Diseño temprano ◦ Post-Arquitectura
  • 14. COCOMO II es un modelo que permite estimar el coste, esfuerzo y tiempo cuando se planifica una nueva actividad de desarrollo software. COCOMO II está adaptado a los ciclos de vida de los modelos de desarrollo de software actuales, dado que esposible de aplicar a aquellas nuevas prácticas no tradicionales de software como desarrollo rápido de aplicaciones, aplicaciones no secuenciales, reusabilidad del software, reingeniería, programación orientada a objetos, entre otras.
  • 15. Desarrollar un modelo de estimación de costo y cronograma de proyectos de software que se adaptara tanto a las prácticas de desarrollo de la década del 90 como a las futuras  Construir una base de datos de proyectos de software que permitiera la calibración continua del modelo, y así incrementar la precisión en la estimación  Implementar una herramienta de software que soportara el modelo  Proveer un marco analítico cuantitativo y un conjunto de herramientas y técnicas que evaluaran el impacto de las mejoras tecnológicas de software sobre los costos y tiempos en las diferentes etapas del ciclo de vida de desarrollo
  • 16. Indicado para proyectos construidos con herramientas modernas de construcción de interfaces gráficos para usuario
  • 17. Se utiliza en las primeras etapas del desarrollo en las cuales se evalúan las alternativas de hardware y software de un proyecto. En estas etapas se tiene poca información, lo que concuerda con el uso de Puntos Función, para estimar tamaño y el uso de un número reducido de factores de costo.
  • 18. Este es el modelo COCOMO 2 más detallado. Puede ser utilizado después de haber desarrollado la arquitectura global del proyecto. Utiliza nuevos parámetros de costo, nuevas reglas de conteo de líneas y nuevas ecuaciones. Este modelo corresponde al esfuerzo de desarrollo estimado una vez que se ha fijado la arquitectura del sistema. Este modelo „base‟ puede ajustarse para:  Estimaciones más tempranas, correspondiente al modelo de diseño temprano (Pre-arquitectura).  Mantenimiento.  Estimación de número de defectos esperados
  • 19. Calcular el esfuerzo, el tiempo y personal que se debería implementar en el proyecto con los siguientes datos.  PF=261,36  Lenguaje – VB= 32 LDC * C/PF
  • 20. KLDC= (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000= 8,363  m(x)=1,15*1,00*0,85*1,11*1,00*1,00*1,07*0,86*0,82*0,7 0*1,00*0,95*1,00*0,91*1,08 = 0,53508480  E = a KLDC e * FAE = 3,2 * (8.363)^1,05 * 0,53508480 = 15,91 personas /mês  T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses  P = E/T = 15,91/7,15 = 2,22 personas
  • 21. Fue concebido en los años cincuenta con fines militares y a partir de la década de los sesenta ha sido utilizado en los ámbitos académicos y empresariales. Ha sido empleado principalmente como técnica de previsión y consenso en situaciones de incertidumbre, en las que no es posible acudir a otras técnicas basadas en información objetiva.
  • 22. Es un proceso iterativo. Como mínimo los expertos deben ser consultados dos veces sobre la misma cuestión, de forma que puedan volver a pensar su respuesta ayudados por la información que reciben de las opiniones del resto de los expertos.  Mantiene el anonimato de los participantes, o al menos de sus respuestas, ya que éstas van directamente al grupo coordinador. Ello permite poder desarrollar Un proceso de grupo con unos expertos que no coinciden ni temporal ni espacialmente, y además busca evitar las influencias negativas que en las respuestas Individuales pudieran tener factores relativos a la personalidad de los expertos participantes.
  • 23. Feedback controlado. El intercambio de información entre los expertos no es libre, sino que se realiza a través del grupo coordinador del estudio, con lo que se elimina toda información que no sea relevante.  Respuesta estadística de grupo. Todas las opiniones forman parte de la respuesta final. Las preguntas están formuladas de forma que se pueda realizar un tratamiento cuantitativo y estadístico de las respuestas.
  • 24. Es un método grupal para refinar el Project plan, donde participan el Project Manager o un moderador, un recorder y estimadores. Las especificaciones se le dan a un grupo de expertos, quienes discuten las metas del proyecto, las suposiciones y estiman los recursos. Además, ellos hacen las estimaciones y se las dan a un moderador, quien compila las estimaciones. Luego, cada estimador sabe los resultados de sus estimaciones, las demás son anónimas. Seguidamente, los expertos discuten los resultados y revisan las tareas. Este ciclo continua hasta que las estimaciones convergen en una que se encuentre en un rango aceptable.
  • 25. Planificación: Es el primer paso del proceso Wideband delphi que comienza con la definición y alcance del problema a estimar. Reunión inicial: Consiste en la comprensión sobre el problema de estimación, en donde el equipo revisa los objetivos estimados, discute el problema y algunos asuntos de la estimación llegando a un acuerdo sobre las unidades de estimación (semanas, horas laborales, dólares, líneas de código) que se usaran a lo largo del proceso.
  • 26. Preparación individual: Consiste en que cada participante desarrolla independientemente una lista inicial de tareas que deberán ser completadas para alcanzar la meta del proyecto, donde cada participante estima el esfuerzo que cada tarea consumirá. Reunión de estimación: El objetivo en este paso es establecer una lista con todas las estimaciones individuales para debatirlas en anonimato, evitando las posibles intimidaciones entre los participantes, todo esto, con el fin de debatir las diferentes estimaciones con el propósito de que cada integrante pueda modificar, añadir, eliminar sus estimaciones renovando la lista obtenida anteriormente .
  • 27. Ensamblando las tareas: Es donde el moderador o Project manager ensambla las tareas del proyecto y sus estimaciones individuales dentro de una lista maestra definitiva de tareas, en donde se encuentran recopilados todos los procesos trabajados con anterioridad. Revisión de resultados: Finalmente, en este paso el equipo de estimación revisa los resultados resumidos y llega a un acuerdo sobre el resultado final.
  • 28. Ventajas Desventajas Hay menos probabilidad de una Requiere de expertos para que estimación negativa. hagan la estimación. Esta basado en valores No define un proceso a seguir históricos. cuando se esta estimando.
  • 29. El coste de un proyecto se calcula por comparación con proyectos similares en el mismo dominio de aplicación. Es aplicable cuando otros proyectos en el mismo dominio de aplicación se han completado. Se estima el costo de un nuevo proyecto por analogía con estos proyectos completados.
  • 30. La técnica de puntos de función fue introducida por Albrecht y su propósito es pedir el software cualificando la Funcionalidad que proporciona externamente, basándose en el diseño lógico del sistema.  Medir lo que el usuario pide y lo que el usuario recibe.  Medir independientemente la tecnología utilizada en la implantación del sistema.  Proporcionar una métrica de tamaño que dé soporte al análisis de la calidad y la productividad.  Proporcionar un medio para la estimación del software.
  • 31. El análisis de los puntos de función se desarrolla considerando cinco parámetros básicos externos del sistema:  Entrada (EI, del inglés External Input).  Salida (EO, del inglés External Output).  Consultas (EQ, del inglés External Query).  Ficheros Lógicos Internos (ILF, del inglés Internal Logic File).  Ficheros Lógicos Externos (EIF, del inglés External Interface File)
  • 32. Es un proceso elemental o una acción que procesa datos o información de control que vienen desde afuera de la frontera de la aplicación hacia adentro. Los datos pueden venir desde otra aplicación o desde una pantalla de ingreso de datos. El objetivo fundamental es mantener uno o más archivos lógicos internos (o ILF de Internal Logical File) y/o alterar el comportamiento del sistema.
  • 33. Se aplican las siguientes reglas: R1: Los datos se reciben desde fuera de los límites de la aplicación. R2: Los datos mantienen un ILF a través de un proceso elemental de la aplicación. R3: El proceso es la unidad más pequeña de actividad que es significativa para el negocio del usuario final. R4: El proceso es auto contenido y deja la aplicación que está siendo contada en un estado consistente. R5: El proceso identificado debe verificar alguna de estas reglas:  Su lógica de proceso es única respecto de otras entradas externas de la aplicación.  Los elementos de datos identificados son distintos a los de las otras EI de la aplicación.  Los ficheros lógicos referenciados son diferentes
  • 34. El objetivo fundamental es presentar información al usuario a través del procesamiento lógico de los datos o de la información de control obtenida.  Se aplican las siguientes reglas: R1: El proceso envía datos información de control. R2: Los datos o información de control se envían a través de un proceso elemental de la aplicación. R3: El proceso es la unidad más pequeña de actividad que es significativa para el negocio del usuario final. R4: El proceso es auto contenido y deja a la aplicación en un estado consistente.
  • 35. R5: El proceso identificado debe verificar alguna de estas reglas: ◦ Su lógica de proceso es única respecto de otras salidas externas de la aplicación. ◦ Los elementos de datos identificados son distintos a los de otras EO‟s de la aplicación. ◦ Los ficheros lógicos referenciados son distintos. R6: Debe cumplirse al menos una de las siguientes condiciones: ◦ El proceso elemental contiene al menos una fórmula matemática o cálculo. ◦ El proceso crea datos derivados ◦ El proceso que genera la salida mantiene algún ILF ◦ El proceso que genera la salida altera el comportamiento del sistema. R7: La transferencia de datos a otras aplicaciones se cuenta como salidas R8: Los informes escritos y online se cuentan como salidas independientes. R9: Los gráficos se cuentan como una salida cada uno.
  • 36. El objetivo principal de un EQ es presentar información al usuario a través de la obtención del dato o de la información de control.  Se aplican las siguientes reglas:  R1: Una petición entra dentro del límite de la aplicación.  R2: Un resultado sale del límite de la aplicación  R3: Hay recuperación de datos  R4: Los datos recuperados no contienen datos derivados.  R5: El proceso lógico no contiene fórmulas matemáticas o cálculos  R6: El proceso que genera la consulta no mantiene ningún ILF ni altera el comportamiento del sistema  R7: La petición de entrada y el resultado de salida juntos, hacen del proceso la unidad de actividad más pequeña que es significativa para el negocio del usuario final.  R8: El proceso es auto contenido y deja a la aplicación que está siendo contada en un estado consistente.
  • 37. El objetivo fundamental de un ILF es manejar los datos mantenidos a través de uno o más procesos elementales (o acciones) de la aplicación que está siendo contada.  Reglas para identificarlos: R1: El grupo de datos o información de control es un grupo de datos lógico identificable por el usuario que cubre de manera completa requisitos específicos de este. R2: El grupo de datos es mantenido dentro de los límites de la aplicación. R3: El grupo de datos es mantenido o modificado por medio de un proceso elemental de la aplicación. R4: El grupo de datos identificado no se ha contado como ELF de la aplicación.
  • 38. El objetivo principal de un ELF es manejar los datos referenciados mediante uno o más procesos elementales (o acciones) dentro de la frontera de la aplicación contada.  Reglas:  R1: El grupo de datos o información de control es un grupo de datos lógico identificable por el usuario que cubre de manera completa requisitos específicos de este.  R2: El grupo de datos es referenciado y es externo a la aplicación que está siendo contada.  R3: El grupo de datos no es mantenido por la aplicación que está siendo contada.  R4: El grupo de datos se ha contado como ILF en al menos otra aplicación.  R5: El grupo de datos identificado no ha sido contado como un ILF para la aplicación. Regresar…
  • 39. Es una medida propuesta inicialmente cuando los programas se escribían en tarjetas, con una línea por tarjeta. Actualmente los lenguajes permiten escribir varias sentencias en una línea, o una misma sentencia en varias líneas Las LDC miden en forma directa el tamaño del producto de software. Se calculan simplemente contando las instrucciones de código fuente de cada componente del producto de software excluyendo, generalmente, los comentarios y blancos.
  • 40. Entonces, se calcula el valor esperado de LDC. El valor esperado para la variable de estimación, E, se obtiene como una medida ponderada de las estimaciones LDC óptima (a), más probable (m) y pesimista (b). Esta técnica trata de definir el tiempo y el costo del proyecto en base a la cantidad de líneas de código se tienen que escribir, cual es el costo por línea y cuantas líneas de código desarrollamos en un mes. Formula:
  • 41. Los pasos para desarrollar ese método son los siguientes:  Descomponemos el problema en los módulos importantes que posea.  Estimar los valores para las columnas de líneas a escribir optimista Más Probable, Pesimista  Calcular la columna esperada en base a la fórmula  Se coloca en la columna de "$/línea" el precio de cada línea en cada módulo, esto generalmente se realiza basados en los costos de proyectos anteriores.  La siguiente casilla pertenece a cuantas líneas se pueden escribir en un mes.  La casilla de "Coste", nos permite tener el cálculo de cuanto costaría cada módulo, esto se obtiene de multiplicar la columna de "$ por línea" con la de "Esperada".  Los meses se calculan multiplicando las "Líneas al mes" por "Esperada"  Al totalizarlas columnas calculadas tendríamos en la columna de "Esperada" la cantidad de líneas que se escribirían, el la de "Coste" el costo estimado del proyecto y en la de "Meses" los meses que demoraría el proyecto Regresar