ADMINISTRACIÓN DE PROYECTOS. Facultad de Estadística e Informática

Transcripción

1 ADMINISTRACIÓN DE PROYECTOS

2 Bibliografía Pressman, R.S., Ingeniería del Software. Un enfoque práctico, quinta edición, 2002, España. Parte 2 Sommerville I., Ingeniería de Software, Addison-Wesley, 6ª. Edición, 2002, México. COCOMO. Gómez, A. López, M. Migani, S. et al. (s.f.). Extraído desde: Consultado el 10 de agosto de El Modelo COCOMO. (s.f.). Extraído desde: Consultado el 20 de agosto de 2017.

3 Clase 64. Agenda Unidad III. 3. Estimación. 3.1 Enfoques a la estimación 3.2 Estimación del tamaño del software (PF(#),PCU(#), COCOMO y COCOMO 2) 3.3 Estimación de Esfuerzo y Tiempo 3.4 Estimación de Costo

4 3. Estimación ESTIMACIÓN Intento por determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto específico basado en software

5 Objetivos de la estimación: Durante la etapa de planeamiento: Permite decidir cuantas personas son necesarias para llevar a cabo el proyecto y establecer el cronograma. Para controlar el progreso del proyecto: Evaluar si el proyecto está evolucionando de acuerdo al cronograma y tomar las acciones (si es necesario).

6 Relación entre costo, cronograma y calidad. Estos tres aspectos están íntimamente relacionados y confrontados entre sí Si aumenta calidad, aumenta costo. Si aumenta la calidad, aumenta el cronograma. Si el cronograma reduce, reduce la calidad. Si reduce el cronograma, aumenta el costo.

7 Los modelos de estimación equilibran los tres factores. Métodos de estimación: ojuicio de Expertos. oanalogía. oparkinson. otasar para ganar oestimación top-down oestimación bottom-up omodelos Algorítmicos.

8 COCOMO. COnstructive COst Model. Modelo Constructivo de Costos. Permite estimar el costo, el esfuerzo y el calendario de desarrollo. Es un modelo empírico basado en el análisis de proyectos grandes. Modelo bien documentado, de dominio público, utilizado y evaluado ampliamente.

9 Su primera versión surgió en 1981 (Bohem, 1981). "Software Engineering Economics" (Prentice-Hall, 1981) La aparición y generalización del uso de las computadoras provocó cambios en el modelo.

10 En 1983 se introduce el lenguaje de programación Ada (American National Standard Institute) para reducir los costos de desarrollo de grandes sistemas. Provocaron un gran impacto en los costos de desarrollo y mantenimiento Sufrió un refinamiento para el desarrollo de software en ADA (Bohem y Royce, 1989). Su versión más reciente es COCOMO II, en el año 2000 (Bohem, et al., 2000).

11 COCOMO 81 aplicable a: Software desarrollado para procesos en cascada. Software en lenguajes de programación procedimentales (Como C o FORTRAN). No soporta desarrollo por prototipos, desarrollo incremental, programas de desarrollo de scripts, SQL, SGBD

12 COCOMO 81 permite estimar cómo se distribuye el esfuerzo y el tiempo en las distintas fases del desarrollo de un proyecto y dentro de cada fase. Diseño del Producto. Arquitectura del hardware, software y las estructuras de datos y control. Diseño Detallado. Diseño de componentes. Codificación y Testeo de Unidades. Creación de componentes. Integración y Testeo. Se fusionan todas las componentes

13 COCOMO 81 distingue las siguientes actividades: Análisis de Requerimientos Diseño del producto Programación (Diseño detallado + Unit Test) Planificación del Testeo Verificación y Validación Actividades de oficina Administración de la Configuración y Aseguramiento de la Calidad (CM/QA): Manuales

14 Para COCOMO 81, uno de los factores más importantes que influye en la duración y el costo de un proyecto de software es el Modo de Desarrollo, todo proyecto corresponde a uno de los tres modos: Modo orgánico. Modo semi-orgánico. Modo empotrado.

15 Modo orgánico: Pequeño grupo de programadores. Ambiente familiar y estable. Poca innovación en algoritmos, estructuras de datos y hardware. Gran entendimiento del sistema. Flexible en requerimientos, especificaciones y entregas. Tamaño de miles de líneas (tamaño pequeño) a unas decenas de miles de líneas (medio). 50KSLOC.

16 Modo semi-acoplado o semi-orgánico: Software de tamaño medio. Software de complejidad media. Conocimiento del sistema: medio. Experiencia en el sistema: medio. Sistemas que presentan niveles variados de exigencia, algunas interfases rigurosas (auditadas por el gobierno) y otras interfases muy flexibles. Tamaño 300 KSLOC.

17 Modo Empotrado: Proyectos grandes, ambiente complejo, fuertes restricciones respecto al hardware, software y operaciones. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla. No existe flexibilidad a cambios de requerimientos o especificaciones de interfaz. altos costos en los procesos de Verificación y Validación y en la Administración de la Configuración Ejemplo: sistemas de tráfico aéreo, Sistemas complejos de procesamiento de transacciones

18 Primera versión COCOMO, llamada COCOMO 81. Tres niveles: Primer nivel (Básico), proporciona estimación inicial burda. Segundo nivel (Intermedio), más refinado utilizando valores del proceso y el proyecto. Tercer nivel (Detallado), otorga estimaciones para las diferentes fases del proceso del proyecto.

19 Nivel básico. Estima el esfuerzo y el tiempo usando dos variables Factores de costo (cost drivers): Tamaño del software Modo de desarrollo. Las ecuaciones básicas son:

20 Esfuerzo: PM = A x (KSLOC) B PM es el esfuerzo estimado. Representa los meses-persona3 necesarios para ejecutar el proyecto. KSLOC es el tamaño del software a desarrollar en miles de líneas de código. A y B son coeficientes que varían según el Modo de Desarrollo (Orgánico, Semiacoplado, Empotrado).

21 Cronograma: TDEV = C x (PM) D TDEV representa los meses de trabajo que se necesitan para ejecutar el proyecto C y D son coeficientes que varían según el Modo de Desarrollo (Orgánico, Semiacoplado, Empotrado)

22

23 Su precisión es muy limitada debido a que no contempla factores que tienen significativa influencia en los costos, como: Restricciones de hardware Experiencia Calidad del equipo de trabajo, etcétera.

24 Nivel intermedio. Es apropiado para etapas de mayor especificación, ofrece mayor detalle y preicisón. Incorpora un conjunto de quince variables de predicción que toman en cuenta las variaciones de costos no consideradas por COCOMO Básico.

25 Los factores o variables se agrupan en cuatro categorías: Atributos del producto de software. orely Confiabilidad Requerida odata Tamaño de la Base de Datos ocplx Complejidad del Producto

26 Atributos del hardware otime Restricción del Tiempo de Ejecución ostor Restricción del Almacenamiento Principal ovirt Volatilidad de la Máquina Virtual oturn Tiempo de Respuesta de la computadora expresado en horas

27 Atributos del personal involucrado en el proyecto o ACAP Capacidad del Analista oaexp Experiencia en Aplicaciones Similares opcap Capacidad del Programador ovexp Experiencia en la máquina virtual olexp Experiencia en el Lenguaje de Programación

28 Atributos propios del proyecto omodp Prácticas Modernas de Programación otool Uso de Herramientas de Software osced Cronograma de Desarrollo Requerido

29 El proceso de estimación de esfuerzo en el nivel intermedio consiste en: i. Se calcula el esfuerzo nominal PM Nominal, al igual que en el modelo Básico, donde los únicos factores de costo son el tamaño y el modo de desarrollo.

30 Se determina el Factor de Ajuste del Esfuerzo (EAF, Effort Adjustment Factor) según la fórmula: EM, factor multiplicador de esfuerzo, es el valor que corresponde a cada atributo de acuerdo al grado de influencia (Muy Bajo, Bajo, Nominal, Alto, Muy Alto, Extra Alto).

31 Finalmente, se ajusta el esfuerzo nominal aplicando el EAF.

32

33 El nivel intermedio COCOMO 81 tiene dos limitaciones importantes a la hora de estimar grandes proyectos de software: ola estimación de la distribución del esfuerzo para cada fase resulta imprecisa. ono es muy práctico si el producto de software tiene un gran número de componentes

34 Nivel detallado. Proporciona estimaciones con mayor grado de precisión y detalle. Se basa en dos aspectos principales: o Jerarquía de niveles del producto. o Multiplicadores de Esfuerzo (EM Effort Multipliers) sensitivos a las fases.

35 Jerarquía de niveles del producto. Aplica al producto de software una descomposición jerárquica de tres niveles. En el nivel inferior, nivel de módulo, la estimación se basa en el número de líneas de código del módulo (SLOC) y factores varían en ese nivel: complejidad del módulo y adaptación del software existente, nivel de capacidad y experiencia del programador, con el lenguaje y la máquina virtual sobre la que se construirá el software.

36 En el segundo nivel, nivel de subsistema, están los factores de costo que pueden variar de un subsistema a otro, pero que tienden a ser los mismos para todos los módulos dentro de un subsistema. Entre ellos se encuentran: restricciones de tiempo y espacio, capacidad del analista, herramientas,etc

37 El nivel superior, nivel de sistema, se usa para aplicar las ecuaciones de esfuerzo nominal y cronograma y calcular las estimaciones tanto para todo el proyecto como para cada fase.

38 Nivel detallado. Proporciona estimaciones con mayor grado de precisión y detalle. Se basa en dos aspectos principales: o Jerarquía de niveles del producto. o Multiplicadores de Esfuerzo (EM Effort Multipliers) sensitivos a las fases.

39 Multiplicadores de Esfuerzo (EM Effort Multipliers) sensitivos a las fases. oel modelo Detallado provee un conjunto de multiplicadores diferentes para cada factor de costo, según la fase del ciclo de desarrollo que se considere olos multiplicadores se utilizan para determinar el esfuerzo requerido para completar cada fase.

40 3. Estimación. Modelo COCOMO

41 3. Estimación. Modelo COCOMO

42 3. Estimación. Modelo COCOMO

43 Procedimiento de estimación del cronograma PDC Nom : Porcentaje de Distribución Nominal del Cronograma PDE Nom : Porcentaje de Distribución Nominal del Esfuerzo PDE Ajus : Porcentaje de Distribución Ajustada del Esfuerzo

44 COCOMO II

45 COCOMO II. Historia. En los 90s, las técnicas de desarrollo de software cambiaron dramáticamente Esfuerzo combinado entre USC-CSE ( University of Southern California- Center For Software Engineering), IRUS at UC Irvine y organizaciones privadas Fue publicado en el año 2000 por B. Bohem.

46 COCOMO II. Historia. Considera los enfoques de desarrollo de construcción de prototipos, desarrollo basado en componentes, bases de datos, modelo de desarrollo en espiral, paradigma orientado a objetos

47 1995 COCOMO 81 COCOMO II

48 Permite realizar estimaciones en función del tamaño del software, y de un conjunto de factores de costo y de escala. Posee tres modelos: Composición de Aplicación, Diseño Temprano y Post-Arquitectura.

49 GRACIAS POR SU ATENCIÓN