Medición del Tamaño Funcional de Aplicaciones Web

Transcripción

1 Seminario de Doctorado: Calidad de Sistemas de Información Web Medición del Tamaño Funcional de Aplicaciones Web Silvia Abrahão Departamento de Sistemas Inform áticos y Computación Universidad Politécnica de Valencia sabrahao@dsic.upv.es Contenido Introducción El proceso de medición de OOmFP La extensión de OOmFP para entornos Web (OOmFPWeb) Generación de Indicadores Aplicación de OOmFPWeb a un caso práctico 2

2 Introducción: Por qué Medir? No se puede controlar lo que no se puede medir Tom DeMarco 1 ¹ Tom DeMarco, Controlling Software Projects, Yourdon Press, Introducción: Por qué medir? Estimación Cuánto costará? Cuánto tiempo llevará hacerlo? Productividad Cuál es la productividad del equipo de desarrollo? Cuál es la productividad de una empresa comparada con las principales empresas del sector? La gestión de proyectos debe ser auxiliada por una métrica que permita medir un proyecto y generar su estimativa de duración, coste y recursos. 4

3 Introducción: Métricas del Software Métricas del Software Tamaño Esfuerzo Coste Calidad Hora $ Defecto Cambio Sintaxis Híbrido Semántico Tamaño Complejidad Halstead Reifer 3D Puntos de Función LOC McCabe 5 Medición del tamaño de software Tamaño del software? SINTACTCO Programas, líneas de código Significativo para el personal técnico. Para la administración no tiene sentido, Sólo es conocida con precisión en etapas tardías. SEMANTICO Requisitos funcionales desde el punto de vista del usuario Significativo para la administración, Significativo para el personal técnico, Puede ser medido en etapas tempranas, Independiente del esfuerzo, método o tecnología 6

4 Motivación La medición del tamaño funcional es una parte importante del proceso de desarrollo de software. Es uno de los factores clave que potencialmente afecta el coste y el tiempo de los proyectos software. Puede ser utilizado para una variedad de propósitos (ej., estimación de proyectos, medición de calidad, benchmarking, outsourcing, etc. Qué es el tamaño funcional? El tamaño de un sistema software derivado de la cuantificación de los Requisitos Funcionales del Usuario (ISO/IEC ) Se basa en el punto de vista de los usuarios Es independiente de cualquier componente físico o tecnológico. 7 Métodos de Tamaño Funcional para la Web Características Principales Dependencia de la tecnología usada para la implementación de las aplicaciones Web No pueden ser aplicados en las primeras fases del proceso de desarrollo de las Aplicaciones Web. Miden sitios Web estáticos Criteria IFPUG proposal Web Objects Web-Points Internet Points Data Web Points Dimensión estática Dimensión dinámica Dimensión navegación Dimensión presentación Soporte Automatizado Validación Datos empíricos disponibles 8

5 OOmFPWeb Características Básicas Un método para medir el tamaño funcional de artefactos Web a partir de esquemas conceptuales orientados a objeto. Se basa en el método estándar Análisis de Puntos de Función (IFPUG) para el paradigma de orientación a objetos. En OOmFPWeb el proceso de medición se hace en el esquema conceptual. El tamaño funcional de la aplicación se calcula en el espacio del problema. Se utiliza toda la información disponible durante la fase modelado conceptual con OOWS (estática y dinámica). Considera todos los conceptos básicos de OO (herencia, agregación, asociación, etc.), y las características específicas de las aplicaciones Web (navegación, presentación). 9 Visión General de OOmFP Tamaño Funcional en OOmFP 10

6 Contenido Introducción El proceso de medición de OOmFP La extensión de OOmFP para entornos Web (OOmFPWeb) Generación de Indicadores Aplicación de OOmFPWeb a un caso práctico 11 El proceso de medición de OOmFP Pasos El proceso de medición se realiza siguiendo los siguientes pasos: Paso 1. Determinación del tipo de medición. Paso 2. Identificación del alcance de la medición y los límites del sistema. Paso 2. Medición 1 de las funciones de datos. Paso 4. Medición 1 de las funciones transaccionales. Paso 5. Determinación del tamaño funcional del sistema (no ajustado). 1 Se determina la complejidad de cada función identificada. Se hace el mapeo de las funciones lógicas para niveles de complejidad bajo, mediano o alto. (tablas IFPUG Int. Function Point Users Group). 12

7 El proceso de medición de OOmFP Flujograma Paso 1 Determinar Tipo Medición Paso 2 Identificar Alcance Medición y Límites del Sistema Paso 3 Medir Funciones Datos Paso 4 Medir Funciones Transaccionales Paso 5 Determinar Tamaño Funcional No Ajustado 13 El proceso de medición de OOmFP Paso 1. Determinar tipo de medición Existen dos tipos de medición con OOmFP: Medición de Nuevos Proyectos de Desarrollo y Medición de Proyectos de Mantenimiento. Nuevos Proyectos de Desarrollo: Dado un modelo conceptual MC producido en la fase de modelado conceptual de OO-Method, OOmFP se calcula de la siguiente manera: OOmFP new = OOmFP D + OOmFP T donde: OOmFP D hace referencia a las funciones lógicas de datos, y OOmFP T hace referencia a las funciones lógicas de transacción. 14

8 El proceso de medición de OOmFP Paso 1. Determinar tipo de medición Proyectos de Mantenimiento: Dado un modelo conceptual MC producido en la fase de modelado conceptual de OO-Method, OOmFP se calcula de la siguiente manera: OOmFP Mant = n i= 1 ADD i + m j= 1 CHG j + l k = 1 DEL k donde: ADD: número de funciones adicionadas durante el mantenimiento CHG: número de funciones modificadas durante el mantenimiento DEL: número de funciones borradas durante el mantenimiento 15 OOmFP Paso 2. Identificación del Alcance de la Medición y de los límites del sistema Alcance de la Medición Define la funcionalidad que va a ser incluida en una medición especifica. Límites del Sistema Indica la frontera entre el software que se está midiendo y el usuario. Reglas Propuestas: Considere cada clase Agente 1 como un tipo de usuario del sistema. Considere cada Vista Legada del Modelo de Objetos como una aplicación externa. 1 La declaración de agentes especifica qué objetos (vistos como clientes) están autorizados a activar los servicios ofrecidos por las clases (vistas como servidoras). 16

9 OOmFP Paso 2. Identificación del Alcance de la Medición y de los límites del sistema Una vista legada se define como un filtro sobre una clase impuesto por el sistema software preexistente. La clase base de la que dicha vista legada se deriva es ajena al Dominio del Problema. Puede participar en alguna relación de agregación con clases del modelo. La especificación de un atributo en una vista legada constituye una observación sobre parte del estado del sistema legado. get_acumulado(clave=nie,...;acumulado= acum_ingr); 17 OOmFP D Paso 3. Medición de las Funciones de Datos OOmFP D, = OOmFP ILF DETs c RETs c c MO OOmFP EIF DETs vl, vl MO RETs vl + Donde: MO: denota un Modelo de Objetos C: Vl: es una clase del MO es una vista legada del MO DETs and RETs: son medidas elementales que son calculadas en las funciones de datos para determinar su complejidad. 18

10 OOmFP D Paso 3. Medición de Funciones de Datos Medición de las funciones de datos Identificar ILFs Identificar EIFs Determinar la Complejidad En FPA las funciones de datos representan la funcionalidad proporcionada al usuario para cumplir los requisitos de datos internos (ILFs) y externos (EIFs). Ficheros Lógicos Internos (ILFs) FPA: es un grupo de datos relacionados lógicamente o información de control identificable por el usuario y que residen dentro de los límites del sistema. OOmFP:es una clase que tiene relaciones de agente. Una clase encapsula un grupo de datos (atributos) que representan el estado de los objetos de la clase. 19 OOmFP D Paso 3. Medición de Funciones de Datos Identificable por el usuario: Es equivalente al término relaciones de agentes definido en OO-Method. Las relaciones de agentes definen los servicios y/o grupo de datos (clases y/o vistas legadas) que un perfil de usuario puede acceder. Mantenido: Es equivalente al término actualización del estado de la clase. Es la capacidad de modificar el estado de la clase a través de un proceso elemental. Proceso Elemental: Unidad de actividad más pequeña que es significativa para el (los) usuario (s). Debe ser autosuficiente y dejar el sistema en un es tado consistente. Se corresponden a los servicios definidos en las clases del Modelo de Objetos. 20

11 OOmFP D Paso 3. Medición de Funciones de Datos Ficheros de Interfaz Externos (EIFs) FPA: un grupo de datos identificable por el usuario que están relacionados lógicamente usados para propósitos de referencia. Los datos residen enteramente fuera de la aplicación y son mantenidos por otra aplicación. OOmFP: una vista legada que representa un filtro sobre una clase impuesto por el sistema software preexistente. Encapsula un grupo de datos (atributos) que representan el estado de los objetos de la vista legada. Tiene una relación de agente con alguna clase del Modelo de Objetos La clase base de la que dicha vista legada se deriva es externa al dominio del problema. 21 Medición de las funciones de datos Paso 3. Complejidad de los ILFs y EIFs Se determina la complejidad por la cantidad de: DET (Data Element Type, Tipo de Dato Elemental): dato único, no repetido, reconocible por el usuario. Atributo dato-valuado de clase o de vista legada. RET (Record Element Type, Tipo de Registro Elemental): subgrupo de datos elementales, reconocible por el usuario, dentro de una clase o vista legada. Existen dos tipos de subgrupos: Opcional: el usuario tiene la opción de usar uno o ninguno de los subgrupos durante un proceso elemental. Obligatorio: el usuario debe usar al menos un subgrupo. 22

12 Determinación de la Complejidad OOmFP D Reglas de Medición de Clases Reglas de Medición de DETs c 1 DET por cada atributo dato-valuado (no derivado) único de la clase. 1 DET por cada atributo en la Función de Identificación (FI) 1 de una relación de agregación univaluada. 1 DET por cada atributo en la FI de las superclases de las que desciende. OOmFP ILF DETs c, c MO RETs c Reglas de Medición de RETsc 1 RET por cada clase del Modelo de Objetos. 1 RET por cada relación de agregación multivaluada (si no es inclusiva 2 ). 1 Identifica una determinada clase. Esta compuesta por atributos constantes. Una clase puede tener 0 o N función de identificación. 2 En una agregación inclusivael objetocomponente estaencapsulado en el objeto compuesto (para acceder al componente hay que hacerlo a trav és del compuesto). 23 Determinación de la Complejidad OOmFP D Matriz complejidad funciones de dados OOmFP ILF DETsc, RETs c DETs RETs 1 = 2 a 5 6 o más 1 a a o más Donde, 7=simple, 10=media, 15=alta (complejidad) 24

13 OOmFP ILF Paso 3. Ejemplo de Medición de Clase Medición de clases con una relación de agregaci ón. La clase Provincia tiene 2 atributos que forman parte de la función de identificación (id_nombre y id_provincia). La clase Ciudad se identifica por id_nombre. Provincia (ILF) DETs = 2 (Atributos) RETs = 2 (Clase) + 1 (relación de agregaci ón) [Complejidad Baja = 7 PF] Ciudad (ILF) DETs = 4 2 (Atributos) + 2 (FI/agregación) RETs = 1 (Clase) [Complejidad Baja = 7 PF] 25 OOmFP ILF Paso 3. Ejemplo de Medición de Clase Medición de clases con relaciones de herencia y agregación. La clase Persona tiene una función de identificación (FI) formada por los atributos id_dni y id_nombre. La clase Coche se identifica por id_coche. Persona (ILF) DETs = 2 ( atributos) RETs = 2 ( clase + agregación) [Complejidad Baja = 7 PF] Estudiante (ILF) DETs = 4 ( 2 atributos + 2 FI ) RETs = 1 ( clase ) [Complejidad Baja = 7 PF] Coche (ILF) DETs = 3 ( 1 atributo + 2 FI ) RETs = 1 ( clase ) [Complejidad Baja = 7 PF] 26

14 Determinación de la Complejidad OOmFP D Reglas de Medición de Vistas Legadas OOmFP EIF DETsvl, vl MO RETs vl Reglas de Medición de DETs vl 1 DET por cada atributo dato-valuado (no derivado) de la vista legada. 1 DET por cada atributo en la FI de una relación de agregación univaluada con una clase. Reglas de medición de RETsvl 1 RET por cada vista legada del Modelo de Objetos. 1 RET por cada relación de agregación multivaluada con una clase. 27 Determinación de la Complejidad OOmFP D Matriz complejidad funciones de dados OOmFP EIF DETsvl, RETs vl DETs RETs 1 = 2 a 5 6 o más 1 a a o más Donde, 5=simple, 7=media, 10=alta (complejidad) 28

15 OOmFP EIF Paso 3. Ejemplo de Medición de Vista Legada Medición de una Vista Legada. En una clase Contrato existe un atributo derivado Media_Anual_Ingresos que para ser calculado necesita acceder a la vista legada Cliente. La expresión de cálculo del atributo es: Media_Anual_Ingresos = Cliente.acum_ingresos/12 El contrato deberá tener almacenada la referencia al cliente del sistema legado correspondiente (con la estructura definida en la FI) y deberá pasarle los datos de entrada correspondientes al servicio legado asociado al atributo de la vista legada acum_ingresos. Cliente (EIF) RETs = 1 (Vista Legada) DETs = 4 3 (atributos) + 1 (FI agregaci ón) [Complejidad Baja = 5 PF] Contrato (ILF) RETs = 1 (Clase) DETs = 3 2 (atributos) + 1 (FI agregaci ón) [Complejidad Baja = 7 PF] 29 OOmFP T Paso 4. Medición de Funciones Transaccionales En FPA las funciones de transacción representan la funcionalidad proporcionada al usuario para procesar los datos. Comprende tres tipos de función: Entradas externas (EIs), Salidas externas (EOs), y Consultas externas (EQs). Medición de las funciones transaccionales Identificar EIs Identificar EOs Identificar EQs Determinar la Complejidad 30

16 OOmFP T Paso 4. Medición de Funciones Transaccionales Entradas Externas (EIs) FPA: los datos o información de control se introducen en la aplicación desde fuera de sus limites. Propósito principal: mantener uno o más ILF s y/o modificar el comportamiento del sistema. Un EI se considera único si los datos son mantenidos en un ILF y el formato de entrada es único o la lógica de proceso es única. OOmFP: es un servicio que representa una unidad de lógica funcional de un objeto. Se identifica un EI por cada servicio de una clase con un agente asociado. Los servicios se miden una única vez mismo que este sea heredado por varias subclases. Un servicio siempre cambia el estado de los objetos de la clase. 31 OOmFP T Paso 4. Medición de las Funciones Transaccionales OOmFP T = OOmFPEI DETss, FTRs s MO s Donde: MO: denota el Modelo de Objetos. S: es un servicio de una clase o vista legada del MO. DETs y FTRs son medidas elementales de las funciones transaccionales para determinar su complejidad. 32

17 Medición de las funciones transaccionales Paso 4. Complejidad de los EIs, EOs y EQs Se determina la complejidad por la cantidad de: DET (Data Element Type, Tipo de Dato Elemental) dato único, no-repetido y reconocible por el usuario (atributo o argumento dato-valuado) FTR (File Type Referenced, Tipos de Fichero Referenciado) Una clase referenciada o actualizada por un servicio Una vista legada referenciada por un servicio de clase 33 Determinación de la Complejidad OOmFP T Reglas de Medición de Servicio (Clase) OOmFP EI DETss, s MO FTRs s Reglas de Medición de DETs s 1 DET por cada argumento dato-valuado del servicio. 1 DET por cada atributo en la FI de un argumento objeto-valuado. 1 DET por la capacidad del sistema en emitir mensajes (error/confirmación). 1 DET por la acción (Aceptar/Cancelar) de ejecución del servicio. Reglas de Medición de FTRss 1 FTR por cada clase del modelo de objetos. 1 FTR por cada argumento objeto-valuado del servicio. 34

18 Determinación de la Complejidad OOmFP T Paso 4. Reglas de Medición de Servicio (Clase) Reglas Opcionales de Medición de FTRs s : 1 FTR para cada elemento que supone el acceso a una nueva clase: Si es un evento portador/liberador, 1 FTR por cada clase de la que el evento sea portador/liberador La ejecución de un servicio en OO-Method sigue una estrategia compuesta por los siguientes pasos: Recuperación del objeto, Validación del cambio de estado, Comprobación de precondiciones explícitas, Realización de evaluaciones, Comprobación de restricciones de integridad y Comprobación condiciones de disparo. 35 Determinación de la Complejidad OOmFP T Paso 4. Reglas de Medición de Servicio (Clase) Reglas Opcionales de Medición FTRs s Estas reglas tienen en cuenta las formulas asociadas a la signatura de una clase. Si en éstas formulas hay una referencia a una clase que todav ía no fue contabilizada, contar: 1 FTR para cada nueva clase accedida en la formula especialización por condición. 1 FTR para cada nueva clase accedida en la formula restricciones de integridad. 1 FTR para cada nueva clase accedida en la formula precondiciones. 1 FTR para cada nueva clase accedida en la formula disparos. reglas ECA asociadas a cada argumento. 1 FTR para cada nueva clase accedida en la formula condiciones de control del DTE. 36

19 Determinación de la Complejidad OOmFP T Matriz complejidad funcciones transaccionales OOmFP EI DETss, FTRs s DETs FTRs 0 a 1 = 2 a 3 4 o más 1 a a o más Donde, 3=simple, 4=media, 6=alta (complejidad) 37 OOmFP EI Paso 4. Ejemplo de Medición de Servicio (Clase) Medición de un evento portador/liberador en una relación de herencia. Los argumentos del evento Persona.Matricular son: p_thispersona (objeto-valuado) p_atrnexp (dato-valuado) p_atrfacultad (dato-valuado) p_atrsueldo (dato-valuado) Así, la medición para este evento es: DETs = 8 3 (Arg. DV) + 3 (2 FI persona + 1 FI Estudiante) + 2 (mensaje + acci ón) FTRs = (clase Estudiante) + 1 (clase Becario) Complejidad Média = 4 PF Para los eventos portadores: Contar 1 FTR por cada clase de la que es evento portador y 1 DET para cada atributo que forma parte de la FI de la(s) clase(s) de la(s) que es portador. 38

20 Determinación de la Complejidad OOmFP T Reglas de Medición de Servicio (Vista Legada) OOmFP EI DETss, s MO FTRs s Reglas de Medición de DETs s 1 DET por cada argumento no derivado del servicio. 1 DET por la capacidad del sistema en emitir mensajes (error/confirmación). 1 DET por la acción (Aceptar/Cancelar) de ejecución del servicio. Reglas de Medición de FTRss 1 FTR por la vista legada. Reglas Opcionales de Medición de FTRss 1 FTR para cada nueva clase accedida en la formula precondiciones. 1 FTR para cada nueva clase accedida en la formula restricciones de integridad. 39 OOmFP Paso 5. Determinación del Tamaño Funcional OOmFP Nombre del Proyecto: Tipo de Conteo: Componente Complejidad Funcional del Componente Baja Media Alta Total Clase (ILF) x 7 = 0 x10 = 0 x 15 = 0 0 Vista legada (EIF) x 5 = 0 x 7 = 0 x 10 = 0 0 Servicio (EI) x 3 = 0 x 4 = 0 x 6 = 0 0 Tamaño Funcional (sin ajustar): 0 40

21 Contenido Introducción El proceso de medición de OOmFP La extensión de OOmFP para entornos Web (OOmFPWeb) Generación de Indicadores Aplicación de OOmFPWeb a un caso práctico 41 Motivación Estado Actual de la Web Muchos negocios se trasladaron para la web: 196 millones de nuevos sitios y aplicaciones web en 5 años. 84% de los proyectos entregados no corresponden a las necesidades del negocio. 79% de las veces ocurren retrasos en la entrega. 63% de las veces los proyectos exceden el presupuesto. 53% de las aplicaciones web entregadas no proporcionan la funcionalidad requerida. 52% de las aplicaciones web entregadas tienen baja calidad. Uno de los principales problemas es la falta de métricas y métodos para medir y estimar el desarrollo web (esfuerzo, tiempo de desarrollo, productividad, costo, etc.). 42

22 OO-Method/OOWS Arquitectura Coche matricula km alquilar devolver Contrato fecha precio alquilar devolver Cliente dni nombre crear alquilar Modelo Conceptual (Espacio del Problema) Modelo de Objetos Modelo Dinámico Modelo Funcional Modelo de Navegación :coche Self::(Km > x):alquilar() Clase: Persona [despedir] situacion= despedido [contratar] situacion= contratado <<Context>> Alquiler Internauta <<Context>> Home <<Context>> Coches Modelo de Ejecución (Espacio de la Solución) OASIS Traducción Automática VBasic BDR Java BDR Delphi BDR Modelo de Navegación Características Básicas Captura la semántica navegacional de una aplicación Web en base al Modelo de Objetos y requisitos de navegación. Utiliza una notación basada en UML. Las propiedades navegacionales de una aplicación Web se describen asociando un mapa navegacional para cada tipo de usuario. Introduce primitivas de abstracción que permiten: Representación de la navegación Especificación de búsquedas Ejecución de servicios Personalización de información de los distintos tipos usuarios 44

23 Modelo de Navegación Primitivas de Abstracción Básicas Mapa Navegacional. Visión Global de la aplicación Web para un perfil de usuario. Corresponde a un grafo dirigido donde los nodos son contextos de navegación y los arcos son vínculos de navegación. Contexto de Navegación. Conjunto de objetos que el usuario irá navegar y servicios que podrá ejecutar. Es una vista del Modelo de Objetos. Enlace de Navegación. Indica la navegación (alcanzabilidad) entre contextos de navegación. Clase Navegacional. Conjunto de atributos y servicios visibles. Es una vista de una clase del Modelo de Objetos. Relación de Contexto. Indica la dirección de navegación entre clases y contextos navegacionales. Se puede definir semántica con los atributos de contexto, enlace, filtro y rol. Relación de Dependencia Contextual. Proporciona información complementaria en el nodo actual sin denotar navegación. 45 Modelo de Navegación Ejemplos 46

24 Modelo de Presentación Primitivas Básicas Captura los requisitos de presentación de información Asocia patrones de presentación a los elementos de un contexto de navegación (clases navegacionales, relaciones navegacionales) Primitivas Básicas: Disposición de la información - layout (tabular, registro, maestro-detalle, árbol) Criterio de ordenación por valor de atributos (ASC/DESC) Paginación de información Cardinalidad: numero de instancias por bloque lógico Puede ser estática (num. fijo de instancias) o dinámica (num. variable). Modo de acceso: a los distintos bloques lógicos. Puede ser secuencial o aleatorio. 47 La extensión de OOmFP para entornos Web Alcance de la Medición FPA: Define la funcionalidad que va a ser incluida en una medición especifica de puntos de función. Define un (sub)conjunto del software a ser medido Podría incluir más de una aplicación Varia dependiendo si la medición es de desarrollo nuevo, mejora o de aplicación OOmFP Web : Define la funcionalidad que va a ser incluida en una medición específica de OOmFP web, que puede incluir: La aplicación Web completa (todos los agentes y sus mapas navegacionales ) El mapa navegacional de un agente Un contexto navegacional La primera opción es la más indicada para nuevos desarrollos mientras que las dos últimas para el mantenimiento de una aplicación web. 48

25 La extensión de OOmFP para entornos Web Límites del sistema FPA: indica el borde entre el proyecto o aplicación que está siendo medida y las aplicaciones externas o los usuarios. Depende de la visión del usuario. OOmFPWeb: Los modelos conceptuales OOWS representan la funcionalidad de la aplicación web en términos de información, servicios y navegación. Un mapa navegacional representa la funcionalidad que la aplicación Web proporciona a un tipo de usuario (agente). Reglas Propuestas: Considere cada agente como un tipo de usuario de la aplicación Web. Considere los límites de la aplicación Web como el borde entre los agentes y los respectivos mapas navegacionales existentes en un Modelo Navegacional. 49 La extensión de OOmFP para entornos Web OOmFPweb Consultas Externas (EQs) Límites de la Aplicación WebApp medida Aplicación Web Externa EIs EOs Usuarios Salidad Externas (EOs) Entradas Externas (EIs) Ficheros Lógicos Internos (ILFs) BD Lógica de Negócio EQs Aplicación Web Externa Una aplicación Web es un grupo de funciones relacionadas lógicamente que satisfacen los requisitos de negocio de los distintos tipos de usuario. 50

26 La extensión de OOmFP para entornos Web Nuevo Desarrollo Dado un modelo conceptual MC producido en la fase de modelado conceptual de OO-Method/OOWS, OOmFP web se calcula de la siguiente manera: OOmFP Web = OOmFP D + OOmFP T Donde: OOmFP D : OOmFP T : denota el tamaño funcional de las funciones de datos. denota el tamaño funcional de las funciones transaccionales. 51 La extensión de OOmFP para entornos Web Nuevo Desarrollo OOmFP, = D OOmFPILF DETsc RETs c c MO vl MO OOmFP EIF DETs vl, RETs + vl Donde: MO: denota el Modelo de Objetos. c: es una clase del MO. vl: es una vista legada del MO. DETs y RETs: son medidas elementales de las funciones de datos para determinar su complejidad. 52

27 La extensión de OOmFP para entornos Web Nuevo Desarrollo OOmFP T = OOmFPEI DETss, FTRs w s MO mn MN cn mn z OOmFP EQnc mn DETs Donde: MO: denota el Modelo de Objetos. s : es un servicio de una clase o vista legada del MO. MN: denota el Modelo Navegacional. mn: es un mapa navegacional del MN. cn: es un contexto navegacional único de un mapa navegacional. w: es el número total de mapas navegacionales de un MN. z: es el número total de contextos navegacionales únicos de un mapa navegacional. DETs y FTRs: son medidas elementales de las funciones transaccionales que sirven para determinar su complejidad. cn s +, FTRs cn 53 La extensión de OOmFP para entornos Web Paso 3. Medición de las Funciones Transaccionales Consultas Externas (EQs) FPA: es un proceso elemental que envía datos o información de control fuera de los limites de la aplicación. Propósito principal: presentar información al usuario mediante la recuperación de datos o información de control de un ILF o EIF. Tiene un componente de entrada y uno de salida. OOmFP: considere cada contexto navegacional único de los mapas navegacionales de un Modelo Navegacional como un EQ. Aunque un contexto navegacional sea reutilizado en un mapa de otro agente, este debe ser medido una única vez. 54

28 La extensión de OOmFP para entornos Web Consideraciones Para un EQ pueden ocurrir tres comportamientos a) Cuando el usuario navega seleccionando un elemento de un contexto navegacional (ej. usando un atributo definido en la relación de contexto), ninguna información cruza la frontera. c) Cuando un filtro de población sobre la clase navegacional se usa para búsquedas. b) Cuando un atributo de filtro (componente de entrada) se usa para recuperar las instancias de la(s) clase(s) navegacionales que serán presentadas (componente de salida), analizar los atributos que aparecen en los componentes de entrada y de salida y si son repetidos contarlo una única vez. 55 La extensión de OOmFP para entornos Web Paso 3. Medición de las Funciones Transaccionales Salidas Externas (EOs) FPA: es un proceso elemental que envía datos o información de control fuera de los limites de la aplicación. Propósito principal: presentar información al usuario mediante un proceso lógico que debe contener al menos una fórmula matemática o un cálculo, crear datos derivados, mantener uno o más ILFs o modificar el comportamiento del sistema. OOmFP:no procede. No se expresa actualmente en OO-Method/OOWS un proceso elemental que realiza algún cálculo, o crea datos derivados para presentar la información al usuario. 56

29 La extensión de OOmFP para entornos Web Paso 3. Complejidad de los EIs, EOs y EQs Se determina la complejidad por la cantidad de: DET (Data Element Type, Tipo de Dato Elemental) dato único, no-repetido y reconocible por el usuario FTR (File Type Referenced, Tipos de Fichero Referenciado) Una clase navegacional actualizada por un servicio. Una clase navegacional referenciada en un filtro de población. 57 La extensión de OOmFP para entornos Web Paso 3. Medición Func. Transaccionales Reglas de Medición de DETs cn : w mn MN cn mn z OOmFP EQnc mn DETs cn, FTRs 1 DET por cada atributo de las clases navegacionales del contexto, al ser información que se muestra al usuario. 2 DETs por cada relación de contexto 1 DET por cada relación de dependencia contextual. 1 DET por cada servicio de las clases navegacionales del contexto. 1 DET por cada enlace de servicio asociado a un servicio de clase navegacional. 1 DET por cada atributo en la formula de un filtro de población (clase nav.). 1 DET por cada atributo en la formula de un filtro de acceso a la información (a nivel del contexto). 1 DET por cada atributo en la formula de un índice. cn 58

30 La extensión de OOmFP para entornos Web Paso 3. Medición Func. Transaccionales Reglas de Medición de FTRs cn : 1 FTR por cada clase navegacional del contexto. w 1 FTR por cada nueva clase navegacional referenciada en la formula de un filtro de población. 1 DET por cada atributo en la formula de un filtro de acceso a la información. 1 FTR por cada nueva clase navegacional referenciada en la formula de un índice. mn MN cn mn z OOmFP EQnc mn DETs cn, FTRs cn 59 La extensión de OOmFP para entornos Web Paso 3. Medición Func. Transaccionales w mn MN cn mn z OOmFP EQnc mn DETs Reglas de Medición de DETs cn (perspectiva presentación) cn, FTRs 4 DETs por el modo de acceso secuencial, al proporcionar mecanismos para acceder al bloque lógico anterior, siguiente, primero y último. 5 DETs por el modo de acceso aleatorio, al proporcionar mecanismos para acceder al bloque lógico anterior, siguiente, primero y último, además de permitir que el usuario elija el bloque que desea mostrar. 2 DETs por el patrón cardinalidad (estática). 3 DETs por el patrón cardinalidad (dinámica). 1 DET por el criterio de ordenación de los elementos del contexto. 1 DET por la habilidad de la aplicación Web en proporcionar acciones al usuario. 1 DET por la capacidad de la aplicación Web en emitir mensajes de control, error, confirmación, etc. cn 60

31 Determining the Complexity of a Navigational w z Context OOmFP x= 1 y= 1 Guías para medir la complejidad de Contextos Navegacionales: Si el modo de acceso se define juntamente con el patrón cardinalidad, considere: ncontextxy 4 DETs si el modo de acceso es secuencial y la cardinalidad es estática. 5 DETs si el modo de acceso es secuencial y la cardinalidad es dinámica. 5 DETs si el modo de acceso es randomico y la cardinalidad es estática. 6 DETs si el modo de acceso es randomico y la cardinalidad es dinámica. 61 Determinación de la Complejidad OOmFP T Matriz complejidad funcciones transaccionales w mn MN cn mn z OOmFP EQncmn DETs cn, FTRs cn DETs FTRs 0 a 1 = 2 a 3 4 o más 1 a a o más Donde, 3=simple, 4=media, 6=alta (complejidad) 62

32 La extensión de OOmFP para entornos Web Ejemplo de Medición Disco Web: Modelo de Objetos Artist name : String <<new>> newartist() 1..* 1..* Album title : String recordlabel : String refnumber : Integer releasedate: Date format : String price : Currency <new<>> newalbum() addtocart() 1..* 1..* 1..* 1 0..* Track name : String <<new>> newtrack() 1..* <<agent>> Item quantity : Integer <<new>> newitem() <<destroy>> destroyitem() update() <<agent>> 0..* 1 Internaut name : String ShoppingCart subtotal : Currency additem() deleteitem() checkout() <<agent>> 0..* 1..* Category description : String ShoppingCart.checkOut <<temporal spec.>> Sale amount : Currency 63 La extensión de OOmFP para entornos Web Ejemplo de Medición Se identifican 13 EQs AnonymousUser.Home AnonymousUser.NewReleases AnonymousUser.Charts... AnonymousUser.YourCart Anonymous User <<Context>> Home E E E E <<Context>> <<Context>> <<Context>> New Releases Charts SpecialOffers E <<Context>> TheBest E <<Context>> InfoMusic S <<Context>> Albums E <<Context>> Howto order E <<Context>> Your Security E <<Context>> Ship Options E <<Context>> AboutUs E <<Context>> Customer Area E <<Context>> Your Cart 64

33 La extensión de OOmFP para entornos Web Ejemplo de Medición AnonymousUser.Albums DETs = 12 (7 atributos + 2 rel. contexto/ dependencia + 1 servicio + 2 acciones y mensajes) FTRs = 2 (2 clases navegacionales) E [Complejidad Media = 4 PF] <<view>> Album title : String recordlabel : String refnumber : Integer releasedate : Date format : String price : Currency addtocart(qtd ) <<Context>> Albums name [Album_Artist] <<view>> Artist name : String 65 La extensión de OOmFP para entornos Web Ejemplo de Medición AnonymousUser.NewReleases DETs = 11 (4 atributos+ 2 rel. Contexto + 1 rel. dep. contextual + 1 atrib. Filtro pobl. + 1 ordenaci ón + 2 acción y mensajes) FTRs = 2 (2 clases navegacionales) [Complejidad Media = 4 PF] E title [AlbumDetails] <<Context>> NewReleases <<view>> Album title : String format : String price : Currency <<view>> Artist name : String Presentation: Tabular Cardinality: 50 PopulationFilter: Calidad de Sistemas Album.price de Información < Web, 25,00 Silvia Abrahão, Ordering: DSIC-UPVprice, D 66

34 La extensión de OOmFP para entornos Web Ejemplo de Medición E <<Context>> YourCart Internaut.YourCart <<view>> YourCart subtotal purchase() * [Home] <<view>> Item price quantity name [Album_Details] <<view>> Internaut name <<view>> Album title description Presentation: Master-Detail pattern Cardinality: 1 FTRs = 4 (clases navegacionales) DETs = 13 (6 atributos + 2 rel. dep. contextual + 2 rel. contexto + 1 servicio + 2 acción y mensajes) [Complejidad Alta = 6 PF] 67 La extensión de OOmFP para entornos Web Ejemplo de Medición Album_Track Navigational Context Measurement (EQ): DETs = 18 3 atributos (title, price, name ) + 4 relaciones de contexto + 1 atributo link + 1 servicio (purchase) + 1 enlace de servicio (ShoppingCart in purchase) + 2 criterio de ordenaci ón (name, price) + 4 modo acceso secuencial con cardinalidad estática + 1 acción + 1 mensajes. FTRs= 2 2 (clasesnavegacionalesalbum y Track) [Complejidad Média = 4 PFs] 68

35 La extensiónde OOmFP para aplicaciones Web Paso 5. Determinación del Tamaño Funcional Nombre del Proyecto: Tipo de Conteo: Componente Complejidad Funcional del Componente Total Baja Media Alta Clase (ILF) x 7 = 0 x10 = 0 x 15 = 0 0 Vista legada (EIF) x 5 = 0 x 7 = 0 x 10 = 0 0 Servicio (EI) x 3 = 0 x 4 = 0 x 6 = 0 0 Contexto Navegacional (EQ) x 3 = 0 x 4 = 0 x 6 = 0 0 Tamaño Funcional (sin ajustar): 0 69 Contenido Introducción El proceso de medición de OOmFP La extensión de OOmFP para entornos Web (OOmFPWeb) Generación de Indicadores Aplicación de OOmFPWeb a un caso práctico 70

36 Generación de Indicadores La estimación del costo, del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo. 71 Generación de Indicadores Problemática en la estimación de proyectos software 1. No existe un modelo de estimación universal o una formula que pueda ser usada para todas las organizaciones. 2. Hay muchas personas implicadas en los proyectos que necesitan de estimaciones. 3. La utilidad de una estimación también dependerá de la etapa de desarrollo en la que nos encontremos. 4. Generalmente, la estimación se hace superficialmente, sin apreciar el esfuerzo requerido para hacer un trabajo. 5. Las estimaciones claras, completas y precisas son difíciles de formular, especialmente al inicio del proyecto. 6. La rapidez con la que cambia la tecnología de la información y las metodologías de desarrollo de software son un problema para la estabilización del proceso de estimación. 72

37 Generación de Indicadores Algunas definiciones Proyecto: Cualquier esfuerzo planeado que tiene productos a ser generados, compromisos de entrega preestablecidos y limitaciones de recursos y presupuesto. En general tiene las siguientes características: Fecha de inicio y fin Objetivos Uso de recursos restrictos a limites Una estructura jerárquica de actividades Tamaño: medida de cuan grande es el producto Esfuerzo: número de horas necesarias para completar una actividad. 73 Beneficios y Aplicación : Indicadores Indicadores de productividad Tratan el producto software en relación al esfuerzo y personal. 1. Tasa de Entrega de Proyecto 2. Tasa de Soporte Indicadores financieros Incluyen el valor del software 1. Recursos 2. Costo total de Proyecto 3. Costos Empresariales 4. Costos de Mantenimiento Indicadores de calidad Hacen referencia al costo de reparación, estabilidad, tasa de defectos, destreza en testeo y fiabilidad relativos al producto software. 1. Tasa de Coste de Reparación 2. Tasa de Estabilidad 3. Tasa de Defectos 4. Destreza en Testeo 5. Fiabilidad 74

38 Generación de Indicadores Indicadores de Productividad Tasa de entrega de proyecto = FP/h Mide la tasa de entrega de proyectos. FP es el valor de puntos de función no ajustados de un proyecto h indica todo el esfuerzo aplicado al proyecto. Tasa de soporte = h/fp período Refleja el trabajo realizado sobre las aplicaciones sin crear nuevas funcionalidades (reparación de defectos, conversiones o mantenimiento preventivo). h es el tiempo invertido en estas actividades durante un determinado período. FP es el tamaño del proyecto en PFs. Esta métrica se calcula anualmente o trimestralmente. 75 Generación de Indicadores Indicadores de Calidad (II) Tasa de Coste de Reparación = Coste / FP Cuantifica el coste de reparar los defectos del software excluyendo los costes de prevenci ón y detección de dichos errores. Se debe calcular mensualmente por un periodo no inferior a los primeros seis meses después de la implementaci ón del proyecto. coste es el tiempo total de reparación en horas multiplicado por la tasa de reparación por hora del personal. FP son los PFs totales de la aplicación que está siendo reparada. Tasa de Estabilidad = 1 - (#cambios / FP) Proporciona un indicador de cómo de bien una mejora o una aplicación cumplió las expectativas del usuario. #cambios son los cambios solicitados durante el primer trimestre (90 días) después de la implementaci ón. FP es el tamaño de la aplicaci ón en PFs. Tasa de Defectos = #defectos / FP Relaciona el numero de defectos con el tamaño en PFs de una aplicaci ón. #defectos es el total de incidencias en las que la aplicación no cumplió las especificaciones. FP son los PFs de la aplicación mantenida. Se debe calcular mensualmente solo durante los primeros seis meses después de la implementaci ón del proyecto. 76

39 Generación de Indicadores Indicadores de Calidad (III) Destreza en Testeo = #defectos/fp Es la tasa de defectos durante la fase de pruebas. Una tasa alta indica o bien poca calidad o unos procedimiento de pruebas muy efectivos. Se debe comparar con la tasa de defectos observada en la aplicación después de la implementación. Se calcula para cada ciclo de pruebas. Fiabilidad = 1 - (#fallos/fp) Considera el numero de fallos de la aplicación desde que se puso en marcha. #fallos incluye todos los fallos. Múltiples fallos causados por el mismo defecto se cuentan repetidamente. FP es el total de PFs de la aplicación que está siendo medida. Se debe calcular mensual o trimestralmente. 77 ISBSG International Software Benchmarking Standards Group (ISBSG), Australia. Método de Estimación: Ecuaciones para estimar tasa de entrega (persona hora por PF), esfuerzo (persona hora), duración (horas transcurridas) y tiempo de entrega (FP entregado por mes) de un proyecto. Se basa en los datos del repositorio ISBSG. Las ecuaciones pueden usar el tamaño del proyecto, el tamaño máximo del equipo de desarrollo o la combinación de ambos. Las ecuaciones son proporcionadas para: Plataforma de desarrollo (mainframe, mid-range & PC) Tipo de lenguaje (3GL, 4GL & generador de aplicaciones) Combinación de plataforma y lenguaje. 78

40 ISBSG Ejemplo: Proyecto software desarrollado en plataforma mainframe con 460 PFs. Tasa de Entrega (TE) TE = x Tamaño = 9.2 h/pf Esfuerzo Proy(PWE) PWE = C x Tamaño E = 4,245 h Duración (D) D = x Tamaño = 8.9 meses Tiempo de Entrega (TE) TE = x Tamaño = PF/mes 79 ISBSG Esfuerzo porplataforma PWE = C x Tamaño E Plataforma Lenguaje C E Num proyectos Ratio fiabilidad Mainframe Mini PC GL GL ApGen

41 ISBSG Esfuerzo porplataforma PWE = C x Tamaño E Plataforma Lenguaje C E Num proyectos Ratio fiabilidad Mainframe 3GL Mainframe 4GL Mainframe ApGen Mini 3GL Mini 4GL PC 3GL PC 4GL SPR (Caper Jones) Software Productivity Research Inc., USA. Métodos de Estimación Repositorio con proyectos Ecuaciones para estimar esfuerzo (persona hora), duración de un proyecto. Tablas de Lenguajes de Programación Tabla 1: Relación entre Nivel del Lenguaje y Productividad Tabla 2: Lenguaje de Programación y Niveles Herramienta: SPR KnowledgePLAN Soporta la herramienta Function Point WORKBENCH de la Charismatek Software Metrics. 82

42 SPR (Caper Jones) Ecuaciones: Estimación Indicativa o Ball-park :técnica de Macro-Estimación que se utiliza habitualmente en situaciones de falta de información sobre el proyecto. Ecuación para determinar el esfuerzo de desarrollo de un proyecto: TamañoPF Esfuerzo= * TamañoPF 150 Para un proyecto de 1000 PFs = 105,5 meses de trabajo Ecuación para determinar la duración de un proyecto 0.4 Duración= TamañoPF Para un proyecto de 1000 PFs = 15,85 meses SPR (Caper Jones) Tablas: Tabla 1: Relación entre Nivel del Lenguaje y Productividad Nivel del Lenguaje Arriba de 55 Productividad Media por persona mes 5 a 10 PFs 10 a 20 PFs 16 a 23 PFs 15 a 30 PFs 30 a 50 PFs 40 a 100 PFs 84

43 SPR (Caper Jones) Tablas: Tabla 2: Lenguaje de Programación y Niveles (Resumen) Lenguaje Nivel Horas / PF Promedio de sentencias del lenguaje por PFs 2GL GL GL GL Java Visual Basic Charismatek Cómo usar FPs para establecer contratos? Ejemplo 2. Tabla de Precios usada por Caper Jones (SPR) Ejemplo 3. Tabla de Cobros usada por el Departamento de Desarrollo en Victoria, Australia. 86

44 Soporte Automatizado para la estimación Principales herramientas del mercado Function Point Workbench Charismatek ( Knowledge Plan SPR ( Cost Xpert Marotz ( 87 Soporte Automatizado para la estimación Principales herramientas del mercado PQMPlus Q/P Management Group, Inc. SLIM QSM ( COSMIC Xpert: 88

45 Seminario de Doctorado: Calidad de Sistemas de Información Web Caso de Estudio: Sistema de Biblioteca Silvia Abrahão Departmento de Sistemas Inform áticos y Computación sabrahao@dsic.upv.es Contenido Medición del Tamaño Funcional Identificación del alcance de la medición y de los limites del sistema Medición de las funciones de datos Medición de las funciones transaccionales Traducción de los niveles de complejidad en valores Cálculo de OOmFPWeb Estimación del esfuerzo, duración y coste del proyecto Web 90

46 OOmFPWeb Proceso de Medición Dado un modelo conceptual MC producido en la fase de modelado conceptual de OOWS, OOmFPWeb se calcula de la siguiente manera: OOmFPWeb = OOmFPWeb D + OOmFPWeb T donde: OOmFPWeb D hace referencia a las funciones lógicas de datos, y OOmFPWeb T hace referencia a las funciones lógicas de transacción. 91 OOmFPWeb Proceso de Medición PASOS A SEGUIR: 1. Identificación del alcance de la medición y de los límites del sistema. Alcance de la Medición: Nuevo Proyecto de Desarrollo Límites del Sistema : Modelo de Objetos (Identificamos los agentes y las vistas legadas) 92

47 OOmFPWeb Proceso de Medición 2. Medición de las funciones de datos. 2.1 Identificación de ILFs: OOmFPWeb Proceso de Medición 2. Medición de las funciones de datos. 2.2 Identificación de EIFs : No se define ninguna vista legada en el Modelo de Objetos 94

48 OOmFPWeb Proceso de Medición PASOS A SEGUIR: 2. Medición de las funciones de datos. 2.3 Medición de la Complejidad de Clase: Clase DETs RETs Complejidad Libro atrib. no derivados + 1 atribfi de Proveedor(agregación univaluada) 2 1 (clase Libro) + 1(agregación multivaluadacon prestamo) Baja 95 OOmFPWeb Proceso de Medición PASOS A SEGUIR: 2. Medición de las funciones de datos. 2.3 Medición de la Complejidad de Clase: Clase DETs RETs Complejidad Socio_sanciona 2 1 atrib. no derivado + 1 atrib FI de Socio (superclase) 1 1 (socio_sanciona) Baja 96

49 OOmFPWeb Proceso de Medición PASOS A SEGUIR: 3. Medición de las funciones transaccionales 3.1 Identificación de EIs: 97 OOmFPWeb Proceso de Medición PASOS A SEGUIR: 3. Medición de las funciones transaccionales 3.1 Identificación de EIs: Clase Proveedor Libro Préstamo Socio Socio_sanciona Bibliotecario EIs Crear, destruir, cambiar Alta, baja, cambiar, copiar Cambiar, borrar Alta, baja, fichar, cambiar, prestar, devolver Perdonar Crear, destruir 3.2 Identificación de EOs: Actualmente no se identifican EOs en OOmFP 98

50 OOmFPWeb Proceso de Medición PASOS A SEGUIR: 3. Medición de las funciones transaccionales 3.3 Identificación de EQs: Bibliotecario E E E E E «Contexto» Bibliotecarios «Contexto» Proveedores «Contexto» Socios «Contexto» Libros «Contexto» Prestamos S S S S «Contexto» Detalle_Proveedor «Contexto» Detalle_Socio «Contexto» Detalle_Libro «Contexto» Detalle_Prestamo 99 OOmFPWeb Proceso de Medición PASOS A SEGUIR: 3. Medición de las funciones transaccionales 3.3 Medición Complejidad de EQs: E DETs = 21 8 atributos + 4 rel. contextos + 4 servicios + 3 atributos de filtro + 2 (acciones y mensajes) FTRs = 3 Clases Prestamo, Socio y Libro Complejidad Alta «Vista» Prestamo -codigo_prestamo -fecha_prestamo -fecha_devolver -fecha_devoluc -pendiente +Cambiar() +Borrar() +Prestar() +Devolver() <<Contexto>> Detalle_Prestamo nombre [Detalle_Socio] titulo [Detalle_Libro] -nombre «Vista» Socio -apellidos -titulo «Vista» libro FILTRO flt_fecha ATRIBUTO fecha_prestamo TIPO RANGO FILTRO flt_titulo ATRIBUTO Libro.titulo TIPO APROXIMADO FILTRO flt_socio ATRIBUTO Socio.nombre TIPO APROXIMADO 100

51 OOmFPWeb Proceso de Medición PASOS A SEGUIR: 4. Traducción de los Niveles de Complejidad en Valores 4.1 Cálculo de OOmFPD TIPO BAJA MEDIA ALTA TOTAL Clase 6 X 7 0 X 10 0 X Vista Legada _ X 5 _ X 7 _ X 10 0 Total OOmFP D OOmFPWeb Proceso de Medición PASOS A SEGUIR: 4. Traducción de los Niveles de Complejidad en Valores 4.2 Cálculo de OOmFPT TIPO BAJA MEDIA ALTA TOTAL Servicio 14 X 3 4 X 4 0 X 6 58 Contexto Navegacional 5 X 3 1 X 4 3 X 6 37 Total OOmFP T

52 OOmFPWeb Proceso de Medición PASOS A SEGUIR: 5. Cálculo de OOmFPWeb OOmFP = OOmFP D + OOmFP T = = Contenido Medición del Tamaño Funcional Identificación del alcance de la medición y de los limites del sistema Medición de las funciones de datos Medición de las funciones transaccionales Traducción de los niveles de complejidad en valores Cálculo de OOmFPWeb Estimación del esfuerzo, duración y coste del proyecto Web 104

53 Estimación del Esfuerzo ISBSG Para proyectos en plataforma PC y lenguajes 4GL como los lenguajes de script utilizados en el desarrollo de aplicaciones Web (o lenguajes como Visual Basic, ASP, y Java), la ecuación es: Esfuerzo = 3,38 * Esfuerzo = 3,38 * ( TamañoenPF ) 0,974 ( 137 ) 0,974 Esfuerzo = 407,45 horasdetrabajo= 2,9horas/ PF Estas 407,45 horas de trabajo equivalen a aproximadamente 2,9 horas de trabajo por puntos de función (h/pf). 105 Estimación del Esfuerzo ISBSG Teniendo en cuenta que el proyecto Biblioteca está siendo desarrollado por dos personas, la siguiente ecuación puede ser aplicada: Esfuerzo = 9,484 * Esfuerzo = 9,484 * 0,585 ( Tamaño en PF ) *( TamEquipo ) ( 137 ) 0, 585 1,038 * ( 2) Esfuerzo = 346,28 horas de trabajo = 2,5 horas / PF 1,

54 Estimación del Esfuerzo SPR Usando la estimación indicativa ( Ball-park) de la empresa SPR, el esfuerzo sería: Esfuerzo Esfuerzo Esfuerzo Tamaño en PF = * Tamaño en PF ,4 = * = 6,4 meses de trabajo 0,4 Estos 6,41 meses de trabajo suponen unas 896 horas de desarrollo, suponiendo una jornada laboral de 35 horas semanales. Es decir, una única persona trabajando en el desarrollo del proyecto debería invertir 896 horas hasta su finalización. 107 Estimación de la Duración ISBSG El ISBSG propone ecuaciones según el lenguaje de desarrollo utilizado. Para proyectos en lenguajes de cuarta generación (4GL), la ecuación es: Duración = 0,622 * Duración = 0,622 * Duración = 4,56 meses ( Tamaño en PF ) 0, 405 ( 137 ) 0, 405 Para un proyecto en plataforma PC, lenguaje 4GL, y un equipo de desarrollo compuesto por 2 personas, el cálculo de la duración sería: Duración = 0,649 * Duración Duración = 0,649 * = 3,75 *1,065 Duración = 3,9 meses ( Tamaño en PF ) 0,357 0, ( 137 ) * (2) 092 0,357 *( TamEquipo ) 0,

55 Estimación de la Duración SPR Aplicando la siguiente ecuación propuesta por Caper Jones la duración del proyecto sería: Duración Duración Duración = = ( Tamaño en PF ) 0,4 ( 137 ) = 7,1meses 0,4 109 Estimación de la Duración The David Consulting Group Tabla 1: PFs / persona mes y Horas por PF en diferentes plataformas Cliente-Servidor Mainframe Web E-Business Web Network Systems Según la propuesta de David Consulting, una persona al mes puede producir 27 FPs en el desarrollo de aplicaciones web. Lo que supone según el cálculo realizado 137/27 = 5.07 meses por una persona. Paquetes Software Data Warehouse Considerando una jornada laboral de 35 horas, las horas necesarias para desarrollar el proyecto Web son: 5.07 x 140 = 709,8 horas = 88,72 días de trabajo. 110

56 Conversión LOC / FP QSM Tabla 3: Conversión Líneas de Código a FPs. Por otra consultora Lenguaje Java Visual Basic ASP Oracle Access dbaseiv Perl Java Script VBScript Power Builder RPG SmallTalk Tasa Conversión (LOC por FP) Estimación del Coste Conociendo el tamaño funcional de un proyecto software en las primeras etapas del ciclo de desarrollo, y el coste de un punto de función, puede estimarse el coste total de proyecto software. El coste de un punto de función varía dependiendo del tipo de empresa y del país. Según el tamaño funcional obtenido en puntos de función y el coste de un punto de función, la aplicación Web puede costar: Precio oficial IFPUG (para USA y Australia[1]): 500 / PF 137 x 500= Precio aproximado Medianas y Grandes Empresas: /PF 137 x 240 = x 200 = x 180 = Precio real industrial: /PF 137 x 50 = x 70 = [1] Otras referencias: "Building a Web Site Using a Fixed Price per Function Point Fee Schedule. CHARISMATEK Software Metrics 112