2.- Planificación Básica 2.5.- Estimación Justo N. Hidalgo Sanz

1. 2.- Planificación Básica 2.5.- Estimación Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

2. Tabla de contenidos • Calidad de Software • Puntos de Función • COCOMO

3. 1. Calidad de Software • Definición de CALIDAD (McCall, 1977). Se define a través de una serie de factores: • Corrección • Fiabilidad • Eficiencia • Integridad • Usabilidad • Mantenibilidad • Facilidad de prueba • Flexibilidad • Portabilidad • Reusabilidad • Interoperatividad • También puede existir el punto de vista subjetivo. • También, sencillamente: ausencia de defectos.

4. Fiabilidad • Probabilidad de que un programa realice su objetivo satisfactoriamente (sin fallos) en un determinado periodo de tiempo y en un entorno concreto (denominado perfil operacional) • Se supone que los fallos ocurren probabilísticamente en el tiempo de acuerdo con una "tasa de intensidad de fallos". • Una clase importante de modelos de fiabilidad, es la de considerar el número de fallos observados en el intervalo de tiempo (0, t) generados por un proceso de Poisson. • Si se satisfacen esas condiciones, un proceso de Poisson homogéneo -modelo de intensidad de fallos constante- caracteriza el comportamiento de los fallos de un programa en la fase de operación y entre diferentes versiones, provocado por la ausencia de depuración y corrección de fallos. • Un modelo de proceso de Poisson no homogéneo con una función de intensidad de fallos decreciente -modelo de fiabilidad creciente- es aplicable cuando se efectúan correcciones a los fallos observados, por ejemplo en la prueba del sistema.

5. Usabilidad • Grado en el que el producto es práctico y fácil de utilizar. • Esta característica debe subdividirse en atributos más fundamentales para que sea posible algún tipo de medición; algunos a considerar pueden ser • nivel requerido: medido en años de experiencia con aplicaciones similares • aprendizaje: medido en horas de adiestramiento requeridas antes de la utilización independiente • capacidad de manipulación: medida en velocidad de trabajo después del adiestramiento y/o errores cometidos a velocidad normal de trabajo.

6. Mantenibilidad • Facilidad de comprender, corregir, adaptar y mejorar el software. • Existen tres tipos de mantenimiento: • mantenimiento correctivo: corregir errores • mantenimiento adaptivo: modificar el software de acuerdo con el entorno • mantenimiento perfectivo: añadir nueva funcionalidad • El mantenimiento preventivo no están tan extendido y consiste en cambiar el producto pensando en mejoras futuras. • Medida más común: MTTR (Mean Time To Repair)

7. Defectos • Anomalía en la especificación, diseño o implementación de un producto. • Una mejora no es un defecto. • Se entiende por mejora un cambio que no hubiera sido detectado, o, en caso afirmativo, no hubiera sido corregido.

8. 2. Puntos de Función • Medición de la aplicación desde el punto de vista del usuario, dejando aparte los detalles de codificación. • Totalmente independiente de las consideraciones de lenguaje. • Evalúan con fidelidad: • valor comercial de un sistema para un usuario • tamaño del proyecto, coste y tiempo de desarrollo • calidad y productividad del programador • esfuerzo de adaptación • posibilidad de desarrollo propio • Puntos de Función de Albrecht.

9. 2.1. Funcionamiento • Interacción analista-usuario • Identificación de funciones disponibles para el usuario, organizadas en cinco grupos: • Salidas • Consultas • Entradas • Ficheros • Interfaces • Clasificación y ponderación de cada función por su nivel de complejidad (simple, media, compleja) • Ajuste de acuerdo a las características del entorno

10. Ajuste

11. Salidas

12. Entradas

13. Consultas

14. Ficheros

15. Interfaces

16. 3. COCOMO • Constructive Cost Model • Creado por Barry Boehm • jerarquía de modelos de estimación de costes software.

17. Fórmulas básicas • Esfuerzo = C1 * EAF(SIZE)P1 • C1: constante • SIZE: número de miles de líneas de código fuente • P1: constante • EAF: productorio de parámetros de caracterízación de proyectos • Tiempo = C2 * (Esfuerzo)P2 • C2: constante • P2: constante • Las constantes están determinadas por el tipo de proyecto: • Orgánico: fácil, “de casa” • Semiencajado • Empotrado (embedded): complejo.

18. Relación de constantes

19. Atributos de Coste • 15 atributos en 4 categorías: • atributos del producto • atributos del ordenador • atributos del personal • atributos del proyecto • Cada atributo se cuantifica en el entorno del proyecto, siendo la escala entre: • muy bajo • bajo • nominal • alto • muy alto • extremadamente alto

20. Atributos del producto • RELY: garantía de funcionamiento requerida al software • DATA: tamaño de la base de datos • CPLX: complejidad del producto

21. Atributos del ordenador • TIME: restricción de tiempo de ejecución • STOR: restricción del almacenamiento principal • VIRT: volatilidad de la máquina virtual • TURN: tiempo de respuesta del ordenador

22. Atributos del personal • ACAP: capacidad del analista • AEXP: experiencia en la aplicación • PCAP: capacidad del programador • VEXP: experiencia en máquina virtual • LEXP: experiencia en lenguaje de programación

23. Atributos del proyecto • MODP: prácticas de programación modernas • TOOL: utilización de herramientas software • SCED: plan de desarrollo requerido

24. COCOMO II • 1995-97, por el USC Center for Software Engineering • Enfocado para grandes proyectos • Provee “estimaciones de rango”, en lugar de “estimaciones puntuales”. • Existen tres modelos para estimación de costes: • Post-architecture: estabilidad (lo que COCOMO creía) • Esfuerzo = 2.45 EAPP (Size)p, • EAPP depende de 17 factores. • Early-design model: • Esfuerzo = 2.45 EARCH (Size)p, • EARCH depende de 7 factores • Prototyping • Esfuerzo lineal.

25. Bibliografía • Software Project Management. A Unified Framework. W. Royce. Addison-Wesley. • http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm (de la asignatura de Métricas y Modelos en la Ingeniería de Software de la Universidad del País Vasco)