Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Estimación para Proyectos de Software

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 19 Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

A los espectadores también les gustó (20)

Anuncio

Similares a Estimación para Proyectos de Software (20)

Anuncio

Más reciente (20)

Estimación para Proyectos de Software

  1. 1. 1 UNIANDES  FACULTAD DE SISTEMAS MERCANTILES CARRERA DE INGENIERÍA EN SISTEMAS ESTIMACIONES PARA  PROYECTO DE SOFTWARE Integrantes: Johanna Caragolla Alex Pujota
  2. 2. 2 Visión General • La  planeación  de  un  proyecto  software  implica  estimar  cuanto tiempo, esfuerzo, dinero y recursos serán necesarios  para construir un sistema. • Una vez que se definió el ámbito del proyecto y se dividió  el problema en su problemas, los gestores de proyecto usan  datos  históricos  (como  también  experiencia  personal  e  intuición) para realizar la estimación. • Las estimaciones se ajustan teniendo en cuenta los riesgos  y la complejidad del proyecto.
  3. 3. 3 Proceso de planificación del  proyecto • Proveer un marco de trabajo que permita al gestor de  proyecto hacer una estimación razonable de recursos,  costos y plan de trabajo. • Se deben usar escenarios de mejor caso" y peor caso"  para limitar los resultados del proyecto • Las estimaciones se deben actualizar a medida que el  proyecto progresa. Objetivos
  4. 4. 4 Factores de confiabilidad de la  estimación • Complejidad del proyecto. • Tamaño del proyecto. • Grado de incertidumbre estructural. • Disponibilidad de información histórica.
  5. 5. Tareas 5 1. Establecer el ámbito del proyecto. 2. Determinar la factibilidad. 3. Analizar los riesgos. 4. Determinar los recursos necesarios: • Determinar los recursos humanos necesarios. • Definir los recursos reusables. • Identificar recursos del entorno. 5. Estimar costo y esfuerzo: • Descomponer el problema. • Desarrollar dos o mas estimaciones. • Conciliar las estimaciones.
  6. 6. 4. Estimación del esfuerzo 6 6. Desarrollar el plan de proyecto: • Establecer un conjunto significativo de tareas. • Definir una red de tareas. • Usar herramientas de planificación para desarrollar un cronograma. • Definir mecanismos de seguimiento de la planificación.
  7. 7. Ámbito del software y factibilidad 7 Describe: • los datos que se procesan y producen, • los parámetros de control, • las funciones, • el rendimiento, • las restricciones, • las interfaces externas y • la confiabilidad. A menudo las funciones descriptas en el ámbito se refinan con el fin de permitir una mejor estimación.
  8. 8. Ámbito y comunicación con el cliente 4. Estimación del esfuerzo 8 • Determinar los objetivos globales del cliente para el sistema propuesto y algunos beneficios esperados. • Determinar las percepciones del cliente con respecto a la naturaleza de una buena solución al problema. • Evaluar la eficacia de la reunión con el cliente.
  9. 9. Factibilidad 4. Estimación del esfuerzo 9 • La factibilidad técnica no es una razón suficiente para construir un producto. • El producto debe cumplir las necesidades del cliente y no estar disponible como un producto de propósito general.
  10. 10. Estimación de recursos 10 • Recursos humanos: cantidad de personas y capacidades necesarias para completar el proyecto. • Recursos reusables: componentes ya desarrollados, componentes experimentados, componentes de experiencia parcial, componentes nuevos. • Recursos de entorno: que debe estar disponible para el equipo durante el proceso de desarrollo.
  11. 11. 11
  12. 12. Estimación del proyecto software 12 Opciones: •Demorar la estimación hasta avanzado el proyecto. •Basar la estimación en proyectos similares ya concluidos. •Usar técnicas simples de descomposición para estimar el costo y esfuerzo del proyecto. •Usar modelos empíricos para la estimación de costo y esfuerzo. •Las herramientas automatizadas pueden ayudar con la •descomposición y estimación del proyecto.
  13. 13. Técnicas de descomposición 13 • Tamaño del software: de lógica fuzzy, de puntos de función, de componentes estándar, de cambio. • Estimación basada en el problema: la estimación basada en LDC se centra en las funciones del software, mientras que el uso de PF hace énfasis en las características del dominio de información. • Estimación basada en el proceso: descomposición basada en las tareas requeridas para completar el marco de proceso software. • Estimación de casos de uso: técnica promisoria pero aun controversial debido a la falta de estandarización de los casos de uso.
  14. 14. Conciliación de estimaciones 14 Causas de los problemas de conciliación: •El planificador no entendió adecuadamente o interpreto mal el ámbito del proyecto. •El conjunto de datos usados en las técnicas basadas en el problema eran obsoletos o inadecuados para la aplicación.
  15. 15. Modelos empíricos de estimación 15 Se derivan de análisis de regresión de datos de proyectos software pasados con persona-mes estimados como variable dependiente y KLDC o PF como variables independientes. COCOMO (Modelo Constructivo de Costos) es un ejemplo de un modelo estático de estimación. La Ecuación del Software es un ejemplo de un modelo dinámico de estimación.
  16. 16. COCOMO II 16 • Es una jerarquía de modelos de estimación que abarca: • Modelo de composición de la aplicación. • Modelo de etapa de diseño temprano. • Modelo de etapa posterior a la arquitectura.
  17. 17. Estimación para desarrollo ágil 17 1. Cada escenario de usuario se considera por separado. 2. El escenario se descompone en un conjunto de tareas de ingeniera. 3. Cada tarea se estima por separado: • Se puede usar datos históricos, modelos empíricos o experiencia. • Se puede estimar el volumen del escenario (LDC, PF, cantidad de casos de uso, etc.)
  18. 18. 18 4. Calcular la estimación del escenario completo: •Sumar las estimaciones de cada tarea •Traducir el volumen estimado en esfuerzo usando datos históricos 5. Se suman los esfuerzos estimados para cada escenario de un incremento para obtener la estimación del incremento.
  19. 19. Decisión desarrollar-comprar 19 • Puede ser mas rentable comprar un producto software determinado que construirlo. • El análisis de un árbol de decisión brinda una manera sistemática de tomar una decisión desarrollar- comprar. • Como regla, la subcontratación requiere mas habilidad en la gestión que el desarrollo interno del mismo producto.

×