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

Presentación del tema: "2.- Planificación Básica 2.5.- Estimación Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA."— Transcripción de la presentación:

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

2 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Tabla de contenidos Calidad de Software Puntos de Función COCOMO

3 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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. Poisson homogéneo 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. Poisson no homogéneo 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Ajuste

11 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Salidas

12 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Entradas

13 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Consultas

14 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Ficheros

15 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Interfaces

16 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 3. COCOMO Constructive Cost Model Creado por Barry Boehm jerarquía de modelos de estimación de costes software.

17 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Relación de constantes

19 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Atributos del producto RELY: garantía de funcionamiento requerida al software DATA: tamaño de la base de datos CPLX: complejidad del producto

21 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Atributos del proyecto MODP: prácticas de programación modernas TOOL: utilización de herramientas software SCED: plan de desarrollo requerido

24 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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 E APP (Size) p, EAPP depende de 17 factores. Early-design model: Esfuerzo = 2.45 E ARCH (Size) p, EARCH depende de 7 factores Prototyping Esfuerzo lineal.

25 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) 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)