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

2.- Planificación Básica2.- Planificación Básica

2.5.- Estimación2.5.- EstimaciónJusto N. Hidalgo SanzJusto N. Hidalgo Sanz

DEPARTAMENTO DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICAINFORMÁTICA

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

Tabla de contenidos

Calidad de Software Puntos de Función COCOMO


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.


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éneoPoisson 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éneoPoisson 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.


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.


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)


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.


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.


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


Ajuste


Salidas

1-5 ítems de datosreferenciados


20 o más items

0 ó 1 fichero referenciado Simple (4) Simple (4) Medio (5)

2 ó 3 ficheros referenciados Simple (4) Medio (5) Complejo (7)

4 o más ficherosreferenciados

Medio (5) Complejo (7) Complejo (7)


Entradas



16 o más ítems

0 ó 1 ficheroreferenciado

Simple (3) Simple (3) Medio (4)

2 ficherosreferenciados

Simple (3) Medio (4) Complejo (6)




Consultas

SALIDA 1-5 ítems de datosreferenciados


20 o más ítems

0 o 1 ficheroreferenciado


2 o 3 ficherosreferenciados




ENTRADA 1-4 ítems de datosreferenciados


16 o más ítems

0 o 1 ficheroreferenciado


2 o 3 ficherosreferenciados





Ficheros



51 o más ítems

1 formato/relaciónde registro lógico


2-5formatos/relacionesde registro lógico


6 o másformatos/relacionesde registro lógico



Interfaces

Utilización del fichero: En esta aplicación A En las otras aplicaciones

Recibido de B Sólo interfaz (sin actualizaciones) Ambos fichero e interfaz

Compartido con B Ambos fichero e interfaz Ambos fichero (si se mantiene) einterfaz

Enviado a B Ambos fichero e interfaz Sólo interfaz (sin actualizaciones)



51 o más ítems

1 formato/relaciónde registro lógico


2-5formatos/relacionesde registro lógico


6 o másformatos/relacionesde registro lógico



3. COCOMO

Constructive Cost Model Creado por Barry Boehm jerarquía de modelos de estimación de costes

software.


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.


Relación de constantes

Esfuerzo Básico Intermedio

Modo C1 P1 C1 P1

Orgánico 2.4 1.05 3.2 1.05

Semiencajado 3.0 1.12 3.0 1.12

Empotrado 3.6 1.2 2.8 1.2

Tiempo

Modo C2 P2

Orgánico 2.5 0.38

Semiencajado 2.5 0.35

Empotrado 2.5 0.32


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


Atributos del producto

RELY: garantía de funcionamiento requerida al software

DATA: tamaño de la base de datos CPLX: complejidad del producto


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


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


Atributos del proyecto

MODP: prácticas de programación modernas TOOL: utilización de herramientas software SCED: plan de desarrollo requerido


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.


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)

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

Documents

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