oomfpweb

Medición del TamañoFuncional de

Aplicaciones Web

Silvia Abrahão Departamento de Sistemas Inform áticos y Computación

Universidad Politécnica de Valencia

[email protected]

Seminario de Doctorado: Calidad de Sistemas de Información Web

2Calidad de Sistemas de Información Web, Silvia Abrahão, DSIC-UPV

Contenido

n Introducción

n El proceso de medición de OOmFP

n La extensión de OOmFP para entornos Web (OOmFPWeb)

n Generación de Indicadores

n Aplicación de OOmFPWeb a un caso práctico


“No se

puede controlar

lo que no se

puede medir” Tom DeMarco1

¹ Tom DeMarco, Controlling Software Projects, Yourdon Press, 1982.

Introducción: ¿Por qué Medir?


n Estimación

u ¿Cuánto costará ?

u ¿Cuánto tiempo llevará hacerlo?

n Productividadu ¿Cuál es la productividad del equipo de desarrollo?u ¿Cuál es la productividad de una empresa comparada con

las principales empresas del sector?

Introducción: ¿Por qué medir?

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.


Métricas del Software

Tamaño Esfuerzo Coste Calidad

Sintaxis HíbridoSemántico

Hora$

Defecto Cambio

Tamaño Complejidad

McCabeLOC

Halstead Reifer3D

Puntos de Función

Introducción: Métricas del Software


¿Tamaño del ¿Tamaño del software?software?

Programas, líneas de código

Requisitos funcionales desde el punto de vista del usuario

ü Significativo para el personal técnico.ü Para la administración no tiene sentido,üSólo es conocida con precisión en etapastardías.

ü 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

SIN

TA

CT

CO

SEM

AN

TIC

O

Medición del tamaño de software


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.

n ¿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 14143-1)

¨ Se basa en el punto de vista de los usuarios¨ Es independiente de cualquier componente físico o

tecnológico.

Motivación


Métodos de Tamaño Funcional para la Web

n Características Principalesu Dependencia de la tecnología usada para la implementación

de las aplicaciones Webu No pueden ser aplicados en las primeras fases del proceso de

desarrollo de las Aplicaciones Web.u Miden sitios Web estáticos

üüDimensión navegación

ü

ü

ü

ü

Data Web Points

ü

ü

ü

Internet Points

Validación

üDatos empíricos disponibles

Soporte Automatizado

Dimensión presentación

Dimensión dinámica

üüüDimensión estática

Web-PointsWeb Objects

IFPUG proposal

Criteria


n Un método para medir el tamaño funcional de artefactos Web a partir de esquemas conceptuales orientados a objeto.

n Se basa en el método estándar Análisis de Puntos de Función (IFPUG) para el paradigma de orientación a objetos.

n 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.

n Se utiliza toda la información disponible durante la fase modelado conceptual con OOWS (estática y dinámica).

n 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).

OOmFPWebCaracterísticas Básicas


Visión General de OOmFP Tamaño Funcional en OOmFP


Contenido

n Introducción






n 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ón1 de las funciones de datos.

Paso 4. Medición1 de las funciones transaccionales.

Paso 5. Determinación del tamaño funcional del sistema (no ajustado).

El proceso de medición de OOmFPPasos

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).


Paso 1

Determinar Tipo

Medición

Identificar Alcance

Medición y Límites del

Sistema

Medir Funciones Datos

Medir Funciones Transaccionales

Determinar Tamaño

Funcional No Ajustado

Paso 2Paso 3

Paso 4

Paso 5

El proceso de medición de OOmFPFlujograma


n Existen dos tipos de medición con OOmFP: Medición de Nuevos Proyectos de Desarrollo y Medición de Proyectos de Mantenimiento.

n Nuevos Proyectos de Desarrollo:u Dado un modelo conceptual MC producido en la fase de modelado

conceptual de OO-Method, OOmFP se calcula de la siguiente manera:

El proceso de medición de OOmFPPaso 1. Determinar tipo de medición

TDnew OOmFPOOmFPOOmFP +=

donde:OOmFPD hace referencia a las funciones lógicas de datos, y OOmFPT hace referencia a las funciones lógicas de transacción.


n Proyectos de Mantenimiento:u Dado un modelo conceptual MC producido en la fase de modelado

conceptual de OO-Method, OOmFP se calcula de la siguiente manera:

El proceso de medición de OOmFPPaso 1. Determinar tipo de medición

∑∑∑===

++=l

kk

m

jj

n

iiMant DELCHGADDOOmFP

111

donde:ADD: número de funciones adicionadas durante el mantenimientoCHG: número de funciones modificadas durante el mantenimientoDEL: número de funciones borradas durante el mantenimiento


OOmFPPaso 2. Identificación del Alcance de la Medición y de los límites del sistema

n Alcance de la Medición u Define la funcionalidad que va a ser incluida en una medición

especifica.

n Límites del Sistemau Indica la frontera entre el software que se está midiendo y el usuario.

n Reglas Propuestas:

F Considere cada clase Agente1 como un tipo de usuario del sistema.

F 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).


n Una vista legada se define como un filtro sobre una clase impuesto por el sistema software preexistente.u La clase base de la que dicha vista legada se deriva es ajena al

Dominio del Problema. u Puede participar en alguna relación de agregación con clases del

modelo. u 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);

OOmFPPaso 2. Identificación del Alcance de la Medición y de los límites del sistema


∑∈

+=

MOc

ccILFD RETsDETsOOmFPOOmFP ,

∑∈

MOvl

vlvlEIF RETsDETsOOmFP ,

OOmFPDPaso 3. Medición de las Funciones de Datos

Donde:

n MO: denota un Modelo de Objetosn C: es una clase del MO

n Vl: es una vista legada del MOn DETs and RETs: son medidas elementales que son calculadas en las

funciones de datos para determinar su complejidad.


n En FPA las funciones de datos representan la funcionalidad proporcionada al usuario para cumplir los requisitos de datos internos (ILFs) y externos (EIFs).

n Ficheros Lógicos Internos (ILFs)u 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.

u 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.

OOmFPDPaso 3. Medición de Funciones de Datos

Medición de las funciones de datos

Identificar ILFs

Identificar EIFsDeterminar la Complejidad


n Identificable por el usuario:u 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.

n Mantenido:u 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.

n Proceso Elemental:u 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.



n Ficheros de Interfaz Externos (EIFs)

u FPA: un grupo de datos identificable por el usuario que están relacionados lógicamente usados para propósitos de referencia.F Los datos residen enteramente fuera de la aplicación y son

mantenidos por otra aplicación.

u OOmFP: una vista legada que representa un filtro sobre una clase impuesto por el sistema software preexistente. F Encapsula un grupo de datos (atributos) que representan el estado de

los objetos de la vista legada.

F Tiene una relación de agente con alguna clase del Modelo de Objetos

F La clase base de la que dicha vista legada se deriva es externa al dominio del problema.



Medición de las funciones de datos Paso 3. Complejidad de los ILFs y EIFs

n Se determina la complejidad por la cantidad de:

u DET (Data Element Type, Tipo de Dato Elemental): dato único, no repetido, reconocible por el usuario.F Atributo dato-valuado de clase o de vista legada.

u 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:F Opcional: el usuario tiene la opción de usar uno o ninguno de los

subgrupos durante un proceso elemental.

F Obligatorio: el usuario debe usar al menos un subgrupo.


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 inclusiva el objetocomponente esta encapsulado en el objetocompuesto (para acceder al componente hay que hacerlo a trav és del compuesto).

Determinación de la Complejidad OOmFPDReglas de Medición de Clases

n Reglas de Medición de DETsc

u 1 DET por cada atributo dato-valuado (no derivado) único de la clase.

u 1 DET por cada atributo en la Función de Identificación (FI) 1 de una relación de agregación univaluada.

u 1 DET por cada atributo en la FI de las superclases de las que desciende.

n Reglas de Medición de RETsc

u 1 RET por cada clase del Modelo de Objetos.u 1 RET por cada relación de agregación multivaluada (si no es inclusiva 2).

∑∈

MOc

ccILF RETsDETsOOmFP ,


Determinación de la Complejidad OOmFPDMatriz complejidad funciones de dados

Donde,

7=simple, 10=media, 15=alta (complejidad)

=

1515106

1510752

10771515020191

,

máso

a

másoaa

RETsDETsOOmFP

RETsDETs

ccILF


OOmFPILFPaso 3. Ejemplo de Medición de Clase

n 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)



OOmFPILFPaso 3. Ejemplo de Medición de Clase

n 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.

Estudiante (ILF)DETs = 4

( 2 atributos + 2 FI )RETs = 1

( clase )


Coche (ILF)DETs = 3

( 1 atributo + 2 FI )RETs = 1

( clase )


Persona (ILF)DETs = 2

( atributos)RETs = 2

( clase + agregación)



∑∈

MOvl


n Reglas de Medición de DETsvl

u 1 DET por cada atributo dato-valuado (no derivado) de la vista legada.

u 1 DET por cada atributo en la FI de una relación de agregación univaluadacon una clase.

n Reglas de medición de RETsvl

u 1 RET por cada vista legada del Modelo de Objetos.u 1 RET por cada relación de agregación multivaluada con una clase.

Determinación de la Complejidad OOmFPDReglas de Medición deVistas Legadas


Determinación de la Complejidad OOmFPDMatriz complejidad funciones de dados

=

101076

1075527551

515020191

,

máso

a

másoaa

RETsDETsOOmFP

RETsDETs

vlvlEIF

Donde,



OOmFPEIFPaso 3. Ejemplo de Medición de Vista Legada

Cliente (EIF)

RETs = 1(Vista Legada)

DETs = 43 (atributos) + 1 (FI agregaci ón)


n 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/12El 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.

Contrato (ILF)RETs = 1

(Clase)DETs = 3

2 (atributos) + 1 (FI agregaci ón)



n En FPA las funciones de transacción representan la funcionalidad proporcionada al usuario para procesar los datos. u Comprende tres tipos de función: Entradas externas (EIs), Salidas

externas (EOs), y Consultas externas (EQs).

OOmFPTPaso 4. Medición de Funciones Transaccionales

Medición de las funciones transaccionales

Identificar EIs

Identificar EQs

Determinar la Complejidad

Identificar EOs


n Entradas Externas (EIs)u FPA: los datos o información de control se introducen en la

aplicación desde fuera de sus limites.

F Propósito principal: mantener uno o más ILF’s y/o modificar el comportamiento del sistema.

F 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.

u OOmFP: es un servicio que representa una unidad de lógica funcional de un objeto. F 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.

F Un servicio siempre cambia el estado de los objetos de la clase.

OOmFPTPaso 4. Medición de Funciones Transaccionales


∑∈

=MOs

ssEIT FTRsDETsOOmFPOOmFP ,

Donde:

n MO: denota el Modelo de Objetos.

n S: es un servicio de una clase o vista legada del MO.n DETs y FTRs son medidas elementales de las funciones

transaccionales para determinar su complejidad.

OOmFPTPaso 4. Medición de las Funciones Transaccionales


Se determina la complejidad por la cantidad de:

n DET (Data Element Type, Tipo de Dato Elemental)u dato único, no-repetido y reconocible por el usuario

(atributo o argumento dato-valuado)

n FTR (File Type Referenced, Tipos de Fichero Referenciado)u Una clase referenciada o actualizada por un servicio

u Una vista legada referenciada por un servicio de clase

Medición de las funciones transaccionalesPaso 4. Complejidad de los EIs, EOs y EQs


Determinación de la Complejidad OOmFPTReglas de Medición deServicio (Clase)

n Reglas de Medición de DETss

u 1 DET por cada argumento dato-valuado del servicio.

u 1 DET por cada atributo en la FI de un argumento objeto-valuado.

u 1 DET por la capacidad del sistema en emitir mensajes(error/confirmación).

u 1 DET por la acción (Aceptar/Cancelar) de ejecución del servicio.

n Reglas de Medición de FTRss

u 1 FTR por cada clase del modelo de objetos.u 1 FTR por cada argumento objeto-valuado del servicio.

∑∈

MOs

ssEI FTRsDETsOOmFP ,


Determinación de la Complejidad OOmFPTPaso 4. Reglas de Medición de Servicio (Clase)

n Reglas Opcionales de Medición de FTRss : 1 FTR para cada elemento que supone el acceso a una nueva clase:

u Si es un evento portador/liberador,1 FTR por cada clase de la que el evento sea portador/liberador

n La ejecución de un servicio en OO-Method sigue una estrategia compuesta por los siguientes pasos:u 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.


Determinación de la Complejidad OOmFPTPaso 4. Reglas de Medición de Servicio (Clase)

n Reglas Opcionales de Medición FTRss

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:

u 1 FTR para cada nueva clase accedida en la formula especializaciónpor condición.

u 1 FTR para cada nueva clase accedida en la formula restricciones deintegridad.

u 1 FTR para cada nueva clase accedida en la formula precondiciones.u 1 FTR para cada nueva clase accedida en la formula disparos.

F reglas ECA asociadas a cada argumento.u 1 FTR para cada nueva clase accedida en la formula condiciones de

control del DTE.


Determinación de la Complejidad OOmFPTMatriz complejidad funcciones transaccionales

=

6644

6433243310

2019651

,

máso

aa

másoaa

FTRsDETsOOmFP

FTRsDETs

ssEI

Donde,



OOmFPEIPaso 4. Ejemplo de Medición de Servicio (Clase)

n Medición de un evento portador/liberador en una relación deherencia. 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 = 31 + 1 (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.


Determinación de la Complejidad OOmFPTReglas de Medición deServicio (Vista Legada)

n Reglas de Medición de DETss

u 1 DET por cada argumento no derivado del servicio.

u 1 DET por la capacidad del sistema en emitir mensajes(error/confirmación).

u 1 DET por la acción (Aceptar/Cancelar) de ejecución del servicio.

n Reglas de Medición de FTRss

u 1 FTR por la vista legada.

n Reglas Opcionales de Medición de FTRss

u 1 FTR para cada nueva clase accedida en la formula precondiciones.u 1 FTR para cada nueva clase accedida en la formula restricciones de

integridad.

∑∈

MOs

ssEI FTRsDETsOOmFP ,


OOmFPPaso 5. Determinación del Tamaño Funcional OOmFP

Nombre del Proyecto:

Tipo de Conteo:

Clase (ILF) x 7 = 0 x10 = 0 x 15 = 0 0Vista legada (EIF) x 5 = 0 x 7 = 0 x 10 = 0 0Servicio (EI) x 3 = 0 x 4 = 0 x 6 = 0 0

0Tamaño Funcional (sin ajustar):

Componente Complejidad Funcional del Componente Total Baja Media Alta


Contenido

n Introducción






MotivaciónEstado Actual de la Web

n Muchos negocios se trasladaron para la web: 196 millones de nuevos sitios y aplicaciones web en 5 años.

n 84% de los proyectos entregados no corresponden a las necesidades del negocio.

n 79% de las veces ocurren retrasos en la entrega.

n 63% de las veces los proyectos exceden el presupuesto.

n 53% de las aplicaciones web entregadas no proporcionan la funcionalidad requerida.

n 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.).


Modelo Conceptual (Espacio del Problema)

OASISModelo de Ejecución (Espacio de la Solución)

Cochematriculakmalquilardevolver

Contratofechaprecioalquilardevolver

Clientedninombrecrearalquilar

Modelo de Objetos Modelo Dinámico Modelo Funcional

Clase: Persona

[despedir] situacion=“despedido”

[contratar] situacion=“contratado”

Self::(Km > x):alquilar():coche

...

OO-Method/OOWSArquitectura

Modelo de Navegación

VBasicBDR

Java BDR

DelphiBDR

Traducción Automática

Internauta

<<Context>>Home

<<Context>>Coches

<<Context>>Alquiler


Modelo de NavegaciónCaracterísticas Básicas

n Captura la semántica navegacional de una aplicación Web en base al Modelo de Objetos y requisitos de navegación.

n Utiliza una notación basada en UML.

n Las propiedades navegacionales de una aplicación Web se describen asociando un mapa navegacional para cada tipo de usuario.

n Introduce primitivas de abstracción que permiten:u Representación de la navegaciónu Especificación de búsquedasu Ejecución de serviciosu Personalización de información de los distintos tipos usuarios


Modelo de NavegaciónPrimitivas de Abstracción Básicas

n 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.

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.

n Enlace de Navegación. Indica la navegación (alcanzabilidad) entre contextos de navegación.

n Clase Navegacional. Conjunto de atributos y servicios visibles. Es una vista de una clase del Modelo de Objetos.

n 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.

n Relación de Dependencia Contextual. Proporciona información complementaria en el nodo actual sin denotar navegación.


Modelo de NavegaciónEjemplos


Modelo de PresentaciónPrimitivas Básicas

n Captura los requisitos de presentación de información

n Asocia patrones de presentación a los elementos de un contexto de navegación (clases navegacionales, relaciones navegacionales)

n Primitivas Básicas:u Disposición de la información - layout

(tabular, registro, maestro-detalle, árbol)u Criterio de ordenación por valor de

atributos (ASC/DESC)u 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.


n FPA: Define la funcionalidad que va a ser incluida en una medición especifica de puntos de función. u Define un (sub)conjunto del software a ser medidou Podría incluir más de una aplicaciónu Varia dependiendo si la medición es de desarrollo nuevo, mejora o de

aplicación

n OOmFPWeb : Define la funcionalidad que va a ser incluida en una medición específica de OOmFPweb, que puede incluir:u La aplicación Web completa (todos los agentes y sus mapas

navegacionales )u El mapa navegacional de un agenteu 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.

La extensión de OOmFP para entornos WebAlcance de la Medición


n FPA: indica el borde entre el proyecto o aplicación que está siendo medida y las aplicaciones externas o los usuarios. Depende de lavisión del usuario.

n OOmFPWeb: Los modelos conceptuales OOWS representan la funcionalidad de la aplicación web en términos de información, servicios y navegación.

u Un mapa navegacional representa la funcionalidad que la aplicación Web proporciona a un tipo de usuario (agente).

u Reglas Propuestas:

F Considere cada agente como un tipo de usuario de la aplicación Web.

F 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.

La extensión de OOmFP para entornos WebLímites del sistema


La extensión de OOmFP para entornos WebOOmFPweb

WebApp medida

BD Aplicación Web Externa

Lógica de Negócio

Límites de la Aplicación

Usuarios

Salidad Externas (EOs)

Consultas Externas

(EQs)

Ficheros Lógicos Internos (ILFs)

EOs

EIs

EQsEntradas Externas

(EIs)

Una aplicación Web es un grupo de funciones relacionadas lógicamente que satisfacen los requisitos de negocio de los distintos tipos de usuario.

Aplicación Web Externa


La extensión de OOmFP para entornos WebNuevo Desarrollo

Donde:

OOmFPD: denota el tamaño funcional de las funciones de datos.OOmFPT: denota el tamaño funcional de las funciones transaccionales.

TDWeb OOmFPOOmFPOOmFP +=

n Dado un modelo conceptual MC producido en la fase de modelado conceptual de OO-Method/OOWS, OOmFPweb se calcula de la siguiente manera:


∑∈

+=

MOc

ccILFD RETsDETsOOmFPOOmFP ,

∑∈

MOvl



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.


+= ∑∈

MOs

ssEIT FTRsDETsOOmFPOOmFP ,

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.


∑∑∈∈

z

mncncncnEQ

w

M Nmn

FTRsDETsOOmFPmnnc

,


n Consultas Externas (EQs)u FPA: es un proceso elemental que envía datos o información

de control fuera de los limites de la aplicación. F 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.

u OOmFP: considere cada contexto navegacional único de los mapas navegacionales de un Modelo Navegacional como un EQ.F Aunque un contexto navegacional sea reutilizado en un mapa de

otro agente, este debe ser medido una única vez.

La extensión de OOmFP para entornos WebPaso 3. Medición de las Funciones Transaccionales


n Para un EQ pueden ocurrir tres comportamientosa) 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.

La extensión de OOmFP para entornos WebConsideraciones


n Salidas Externas (EOs)u FPA: es un proceso elemental que envía datos o información

de control fuera de los limites de la aplicación.

F Propósito principal: presentar información al usuario mediante un proceso lógico que debe contener al menos una fórmulamatemática o un cálculo, crear datos derivados, mantener uno o más ILFs o modificar el comportamiento del sistema.

u OOmFP:no procede.F 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.

La extensión de OOmFP para entornos WebPaso 3. Medición de las Funciones Transaccionales


Se determina la complejidad por la cantidad de:

n DET (Data Element Type, Tipo de Dato Elemental)u dato único, no-repetido y reconocible por el usuario

n FTR (File Type Referenced, Tipos de Fichero Referenciado)u Una clase navegacional actualizada por un servicio.

u Una clase navegacional referenciada en un filtro de población.

La extensión de OOmFP para entornos WebPaso 3. Complejidad de los EIs, EOs y EQs


∑∑∈∈

z

mncncncnEQ

w

M Nmn

FTRsDETsOOmFPmnnc

,

n Reglas de Medición de DETscn:u 1 DET por cada atributo de las clases navegacionales del contexto, al

ser información que se muestra al usuario. u 2 DETs por cada relación de contexto

u 1 DET por cada relación de dependencia contextual.

u 1 DET por cada servicio de las clases navegacionales del contexto. u 1 DET por cada enlace de servicio asociado a un servicio de clase

navegacional.

u 1 DET por cada atributo en la formula de un filtro de población (clase nav.).

u 1 DET por cada atributo en la formula de un filtro de acceso a la información (a nivel del contexto).

u 1 DET por cada atributo en la formula de un índice.

La extensión de OOmFP para entornos WebPaso 3. Medición Func.Transaccionales


n Reglas de Medición de FTRscn:

u 1 FTR por cada clase navegacional del contexto.

u 1 FTR por cada nueva clase navegacional referenciada en la formula de un filtro de población.

u 1 DET por cada atributo en la formula de un filtro de acceso a la información.

u 1 FTR por cada nueva clase navegacional referenciada en la formula de un índice.

∑∑∈∈

z

mncncncnEQ

w

M Nmn

FTRsDETsOOmFPmnnc

,



∑∑∈∈

z

mncncncnEQ

w

M Nmn

FTRsDETsOOmFPmnnc

,

n Reglas de Medición de DETscn (perspectiva presentación)u 4 DETs por el modo de acceso secuencial, al proporcionar mecanismos

para acceder al bloque lógico anterior, siguiente, primero y último.

u 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.

u 2 DETs por el patrón cardinalidad (estática).

u 3 DETs por el patrón cardinalidad (dinámica).

u 1 DET por el criterio de ordenación de los elementos del contexto.

u 1 DET por la habilidad de la aplicación Web en proporcionar acciones al usuario.

u 1 DET por la capacidad de la aplicación Web en emitir mensajes de control, error, confirmación, etc.



u Guías para medir la complejidad de Contextos Navegacionales:u Si el modo de acceso se define juntamente con el patrón

cardinalidad, considere:

u 4 DETs si el modo de acceso es secuencial y la cardinalidad es estática.

u 5 DETs si el modo de acceso es secuencial y la cardinalidad es dinámica.

u 5 DETs si el modo de acceso es randomico y la cardinalidad es estática.

u 6 DETs si el modo de acceso es randomico y la cardinalidad es dinámica.

Determining the Complexity of a Navigational Context ∑∑

==

z

ynContext

w

xyx

OOmFP11


Determinación de la Complejidad OOmFPTMatriz complejidad funcciones transaccionales

=∑∑∈∈

66446433243310

2019651

,

másoaa

másoaa

FTRsDETsOOmFP

FTRsDETs

z

mncncncnEQ

w

MNmnmnnc

Donde,



n Disco Web : Modelo de Objetos

Saleamount : Currency

<<agent>>

Internautname : String

ShoppingCartsubtotal : Currency

addItem()deleteItem()checkOut()

ShoppingCart.checkOut

1

0..1

1

0..1

Itemquantity : Integer

<<new>> newItem()<<destroy>> destroyItem()update()

0..* 10..* 1

Trackname : String

<<new>> newTrack()

Artistname : String

<<new>> newArtist()1..* 1..*1..* 1..*

Albumtitle : StringrecordLabel : StringrefNumber : IntegerreleaseDate : Dateformat : Stringprice : Currency

<new<>> newAlbum()addToCart()

1 0..*1 0..*

1..*

1..*

1..*

1..*1..*

1..*

1..*

1..*

Categorydescription : String

0..*

1..*

0..*

1..*

<<agent>>

<<agent>>

<<temporal spec.>>

La extensión de OOmFP para entornos WebEjemplo de Medición


<<Context>>SpecialOffers

<<Context>>Home

E<<Context>>

Charts<<Context>>

New Releases

E E E<<Context>>

TheBest

E

Anonymous User

<<Context>>InfoMusic

E

<<Context>>Howto order

E<<Context>>

Your Security

E<<Context>>

ShipOptions

E<<Context>>AboutUs

E<<Context>>

Customer Area

E<<Context>>Your Cart

E


<<Context>>Albums

S

n Se identifican 13 EQsAnonymousUser.Home

AnonymousUser.NewReleases

AnonymousUser.Charts

....

AnonymousUser.YourCart


La extensión de OOmFP para entornos WebEjemplo de Medición AnonymousUser.AlbumsDETs = 12

(7 atributos + 2 rel. contexto/ dependencia + 1 servicio + 2 acciones y mensajes)

FTRs = 2(2 clases navegacionales)

[Complejidad Media = 4 PF]

<<Context>>Albums

E

Artistname : String

<<view>>

Albumtitle : StringrecordLabel : StringrefNumber : IntegerreleaseDate : Dateformat : Stringprice : Currency

addToCart(qtd )

<<view>>

name[Album_Artist]


NewReleases<<Context>>

E

Cardinality: 50

Ordering: price , D

Presentation: Tabular

Artistname : String

<<view>>Albumtitle : Stringformat : Stringprice : Currency

<<view>>

[AlbumDetails]title

Population Filter: Album.price < 25,00

La extensión de OOmFP para entornos WebEjemplo de Medición AnonymousUser.NewReleasesDETs = 11

(4 atributos+ 2 rel. Contexto + 1 rel. dep. contextual + 1 atrib. Filtropobl. + 1 ordenaci ón +2 acción y mensajes)

FTRs = 2(2 clases navegacionales)[Complejidad Media = 4 PF]


<<Context>> YourCart

Presentation: Master-Detail pattern Cardinality: 1

E

Internaut

name

<<view>>

[Album_Details]

Item

price

<<view>>

quantity

Album

title

<<view>>

description

name

YourCart

subtotal

<<view>>

purchase() * [Home]

Internaut.YourCart

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]



Album_Track Navigational ContextMeasurement (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 = 22 (clases navegacionales Album y Track)

[Complejidad Média = 4 PFs]



Nombre del Proyecto:

Tipo de Conteo:

Componente Total

Clase (ILF) x 7 = 0 x10 = 0 x 15 = 0 0Vista legada (EIF) x 5 = 0 x 7 = 0 x 10 = 0 0Servicio (EI) x 3 = 0 x 4 = 0 x 6 = 0 0Contexto Navegacional (EQ) x 3 = 0 x 4 = 0 x 6 = 0 0

Tamaño Funcional (sin ajustar): 0

AltaMediaBajaComplejidad Funcional del Componente

La extensión de OOmFP para aplicaciones WebPaso 5. Determinación del Tamaño Funcional


Contenido

n Introducción






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.


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.

Generación de IndicadoresProblemática en la estimación de proyectos software


n 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

n Tamaño: medida de cuan grande es el producto

n Esfuerzo: número de horas necesarias para completar una actividad.

Generación de IndicadoresAlgunas definiciones


n Indicadores de productividad

Tratan el producto software en relación al esfuerzo y personal.

1. Tasa de Entrega de Proyecto

2. Tasa de Soporte

Beneficios y Aplicación : Indicadores

n 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

n Indicadores financieros

Incluyen el valor del software1. Recursos

2. Costo total de Proyecto

3. Costos Empresariales4. Costos de Mantenimiento


n Tasa de entrega de proyecto = FP/hMide 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.

n Tasa de soporte = h/FP períodoRefleja 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.

Generación de IndicadoresIndicadores de Productividad


n Tasa de Coste de Reparación = Coste / FPu 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.

n Tasa de Estabilidad = 1 - (#cambios / FP)u 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.

n Tasa de Defectos = #defectos / FPu 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. FPson 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.

Generación de IndicadoresIndicadores de Calidad (II)


n Destreza en Testeo = #defectos/FP u 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.

n Fiabilidad = 1 - (#fallos/FP)u 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.

Generación de IndicadoresIndicadores de Calidad (III)


ISBSG

International Software Benchmarking Standards Group (ISBSG), Australia.

u 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.


Ejemplo: Proyecto software desarrollado en plataforma mainframe con 460 PFs.

= 51.63 PF/mesTE = 0.925 x Tamaño0.410Tiempo de Entrega (TE)

= 8.9 mesesD = 1.081 x Tamaño0.344Duración (D)

= 4,245 hPWE = C x TamañoEEsfuerzo Proy(PWE)

= 9.2 h/PFTE = 14.35 x Tamaño -0.072Tasa de Entrega (TE)

ISBSG


ISBSG Esfuerzo por plataforma

0.4922900.89910.074GL

0.6332850.97313.343GL

0.6313840.92814.35Mainframe

0.672460.71639.54ApGen

0.4731161.0163.78PC

0.5401080.90014.89Mini

Ratio fiabilidad

Num proyectos

ECLenguajePlataforma

PWE = C x TamañoE


PWE = C x TamañoE

0.955101.3900.5873GLPC

0.483580.85118.074GLMini

0.727401.0687.243GLMini

0.6501930.95015.103GLMainframe

0.519810.9743.384GLPC

0.714420.75333.81ApGenMainframe

0.6181120.89612.474GLMainframe

Ratio fiabilidad

Num proyectos

ECLenguajePlataforma

ISBSG Esfuerzo por plataforma


SPR (Caper Jones)

Software Productivity Research Inc., USA.Métodos de Estimación

¨ Repositorio con 8.000 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.


SPR (Caper Jones)

Ecuaciones:n 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.

n Ecuación para determinar el esfuerzo de desarrollo de un proyecto:

n Para un proyecto de 1000 PFs = 105,5 meses de trabajo

n Ecuación para determinar la duración de un proyecto

n Para un proyecto de 1000 PFs = 15,85 meses

4.0*150

PFTamañoPFTamaño

Esfuerzo

=

4.0PFTamañoDuración=


SPR (Caper Jones)

n Tablas:n Tabla 1: Relación entre Nivel del Lenguaje y Productividad

30 a 50 PFs24 – 55

10 a 20 PFs4 – 8

16 a 23 PFs9 – 15

40 a 100 PFsArriba de 55

15 a 30 PFs16 – 23

5 a 10 PFs1 – 3

Productividad Media por persona mes

Nivel del Lenguaje


SPR (Caper Jones)n Tablas:

n Tabla 2: Lenguaje de Programación y Niveles (Resumen)

8.80

11.73

7.65

17.60

Horas / PF

2911.00Visual Basic 5.0

6.00

70.00

16.00

4.00

3.00

Nivel

53Java

803GL

204GL

55GL

1072GL

Promedio de sentencias del lenguaje por PFs

Lenguaje


Charismatek

n ¿Cómo usar FPs para establecer contratos?u Ejemplo 2. Tabla de Precios usada por Caper Jones (SPR)

u Ejemplo 3. Tabla de Cobros usada por el Departamento de Desarrollo en Victoria, Australia.


Soporte Automatizado para la estimaciónPrincipales herramientas del mercado

Function Point Workbenchu Charismatek

(www.charismatek.com)

n Knowledge Planu SPR (www.spr.com)

n Cost Xpertu Marotz (www.costxpert.com)


n PQMPlus™ u Q/P Management Group, Inc.

n SLIM– QSM (www.qsm.com)

n COSMIC Xpert:

http://www.lrgl.uqam.ca/cosmic-ffp/tools.jsp

Soporte Automatizado para la estimaciónPrincipales herramientas del mercado

Caso de Estudio: Sistema de Biblioteca

Silvia AbrahãoDepartmento de Sistemas Inform áticos y Computación

[email protected]

Seminario de Doctorado: Calidad de Sistemas de Información Web


Contenido

n Medición del Tamaño Funcionalu Identificación del alcance de la medición y de los limites del

sistema

u Medición de las funciones de datos

u Medición de las funciones transaccionales

u Traducción de los niveles de complejidad en valores

u Cálculo de OOmFPWeb

n Estimación del esfuerzo, duración y coste del proyecto Web


n Dado un modelo conceptual MC producido en la fase de modelado conceptual de OOWS, OOmFPWeb se calcula de la siguiente manera:

TD OOmFPWebOOmFPWebOOmFPWeb +=

donde:OOmFPWebD hace referencia a las funciones lógicas de datos, y OOmFPWebT hace referencia a las funciones lógicas de transacción.

OOmFPWebProceso de Medición


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)


2. Medición de las funciones de datos.


2.1 Identificación de ILFs:

2

1

3

4

56




2.2 Identificación de EIFs :

No se define ninguna vista legada en el Modelo de Objetos


n PASOS A SEGUIR :



2.3 Medición de la Complejidad de Clase:

Baja21 (clase Libro) + 1(agregación multivaluadacon prestamo)

1312 atrib. no derivados + 1 atribFI de Proveedor(agregación univaluada)

Libro

ComplejidadRETsDETsClase


n PASOS A SEGUIR :



2.3 Medición de la Complejidad de Clase:

Baja11 (socio_sanciona)

21 atrib. no derivado + 1 atribFI de Socio (superclase)

Socio_sanciona

ComplejidadRETsDETsClase


n PASOS A SEGUIR :

3. Medición de las funciones transaccionales


3.1 Identificación de EIs:


n PASOS A SEGUIR :



3.1 Identificación de EIs:

Crear, destruir, cambiarAlta, baja, cambiar, copiarCambiar, borrarAlta, baja, fichar, cambiar, prestar, devolverPerdonarCrear, destruir

ProveedorLibroPréstamoSocio

Socio_sancionaBibliotecario

EIsClase

3.2 Identificación de EOs: Actualmente no se identifican EOs en OOmFP


n PASOS A SEGUIR :



3.3 Identificación de EQs:

«Contexto»Proveedores

«Contexto»Socios

«Contexto»Prestamos

«Contexto»Libros

Bibliotecario

E E EE

«Contexto»Detalle_Proveedor

S

«Contexto»Detalle_Socio

S

«Contexto»Detalle_Libro

S

«Contexto»Bibliotecarios

E

«Contexto»Detalle_Prestamo

S


n PASOS A SEGUIR :



3.3 Medición Complejidad de EQs:

E

+Cambiar()+Borrar()+Prestar()+Devolver()

-codigo_prestamo-fecha_prestamo-fecha_devolver-fecha_devoluc-pendiente

«Vista»Prestamo

<<Contexto>>Detalle_Prestamo

-nombre-apellidos

«Vista»Socio

-titulo

«Vista»libro

nombre[Detalle_Socio]

titulo[Detalle_Libro]

FILTRO flt_fechaATRIBUTO fecha_prestamoTIPO RANGOFILTRO flt_tituloATRIBUTO Libro.tituloTIPO APROXIMADOFILTRO flt_socioATRIBUTO Socio.nombreTIPO APROXIMADO

DETs = 218 atributos + 4 rel. contextos + 4 servicios + 3 atributos de filtro + 2 (acciones y mensajes)

FTRs = 3Clases Prestamo, Socio y Libro

Complejidad Alta


n PASOS A SEGUIR :

4. Traducción de los Niveles de Complejidad en Valores


4.1 Cálculo de OOmFPD

42Total OOmFPD

0_ X 10_ X 7_ X 5Vista Legada

420 X 150 X 106 X 7Clase

TOTALALTAMEDIABAJATIPO


n PASOS A SEGUIR :

4. Traducción de los Niveles de Complejidad en Valores


4.2 Cálculo de OOmFPT

95Total OOmFP T

373 X 61 X 45 X 3Contexto Navegacional

580 X 64 X 414 X 3Servicio

TOTALALTAMEDIABAJATIPO


n PASOS A SEGUIR :

5. Cálculo de OOmFPWeb


TD OOmFPOOmFPOOmFP +=

= 42 + 95

= 137


Contenido

n Medición del Tamaño Funcionalu Identificación del alcance de la medición y de los limites del

sistema

u Medición de las funciones de datos

u Medición de las funciones transaccionales

u Traducción de los niveles de complejidad en valores

u Cálculo de OOmFPWeb

n Estimación del esfuerzo, duración y coste del proyecto Web


n 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:

n Estas 407,45 horas de trabajo equivalen a aproximadamente 2,9 horasde trabajo por puntos de función (h/PF).

Estimación del EsfuerzoISBSG

( )( )

PFhorastrabajodehorasEsfuerzo

Esfuerzo

PFenTamañoEsfuerzo

/9,245,407

137*38,3

*38,3974,0

974,0

==

=

=


n Teniendo en cuenta que el proyecto “Biblioteca” está siendo desarrollado por dos personas, la siguiente ecuación puede ser aplicada:

Estimación del EsfuerzoISBSG

( ) ( )( ) ( )

PFhorastrabajodehorasEsfuerzoEsfuerzo

TamEquipoPFenTamañoEsfuerzo

/5,228,3462*137*484,9

**484,9038,1585,0

038,1585,0

===

=


n Usando la estimación indicativa (‘Ball-park) de la empresa SPR, el esfuerzo sería:

n 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.

Estimación del EsfuerzoSPR

trabajodemesesEsfuerzo

Esfuerzo

PFenTamañoPFenTamaño

Esfuerzo

4,6

137*150137

*150

4,0

4,0

=

=

=


n El ISBSG propone ecuaciones según el lenguaje de desarrollo utilizado. Para proyectos en lenguajes de cuarta generación (4GL), la ecuación es:

n 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:

Estimación de la DuraciónISBSG

( )( )

mesesDuración

Duración

PFenTamañoDuración

56,4

137*622,0

*622,0405,0

405,0

=

=

=

( )( )

mesesDuración

DuraciónDuración

TamEquipoPFenTamañoDuración

9,3

065,1*75,3)2(*137*649,0

)(**649,0092,0357,0

092,0357,0

=

==

=


n Aplicando la siguiente ecuación propuesta por Caper Jones la duración del proyecto sería:

Estimación de la DuraciónSPR

( )( )

mesesDuraciónDuración

PFenTamañoDuración

1,7137 4,0

4,0

==

=


n Tabla 1: PFs / persona mes y Horas por PF en diferentes plataformas

Estimación de la DuraciónThe David Consulting Group

8

21

24

16

27

12

18

22.0

8.4

7.3

11.0

6.5

14.7

9.8

NetworkSystems

Paquetes Software

Web

Data Warehouse

E-Business Web

Mainframe

Cliente-Servidor 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.

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.


n Tabla 3: Conversión Líneas de Código a FPs. Por otra consultora

52dBase IV

60Perl

58Java Script

50VBScript

30Oracle

35Access

32Power Builder

69ASP

61RPG

47Visual Basic

26SmallTalk

62Java

Tasa Conversión(LOC por FP)

Lenguaje

www.qsm.com

Conversión LOC / FPQSM


n 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 .

n 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 €/ PF137 x 500= 68.500 €

Precio aproximado Medianas y Grandes Empresas: 180-200-240 €/PF137 x 240 = 32.880 € 137 x 200 = 27.400 € 137 x 180 = 24.660 €

Precio real industrial: 50-70 €/PF137 x 50 = 6.850 € 137 x 70 = 9.590 €

[1] Otras referencias: "Building a Web Site Using a Fixed Price per Function Point Fee Schedule”. CHARISMATEK Software Metrics

Estimación del Coste

oomfpweb

Documents

data element type

ficheros lgicos internos

file type referenced

tipo de conteo

oomfpwebproceso de medicin2

componente de entrada

tiempo de entrega

seminario de doctorado