estimacion 2 pmbok

13

2. ESTIMACIÓN DE ESFUERZO EN EL DESARROLLO DE SOFTWARE.

1. INTRODUCCIÓN.

Este tema se centra en la estimación del esfuerzo que tendrá que realizar una empresa para desarrollar una aplicación. Por esfuerzo nos referimos a la cantidad de recursos humanos, usualmente medidos en meses/hombre. Partiremos de que ya se ha realizado un análisis estructurado y disponemos de la especificación de requerimientos del sistema. Por desgracia esto no es habitual, como dice Edward Yourdon un problema de la estimación es que se nos pide que la realicemos cuando aún no está claro que desea el usuario (no disponemos de la especificación).

Comparando esta ingeniería con la arquitectura (construcción de

edificios), el arquitecto para valorar lo que costará construir un edificio necesitará tener los planos de éste. Además, lo que en urbanismo se conoce con el nombre de edificio singular ,edificios que tienen formas extrañas (la Sagrada Familia de Gaudi, etc.), tienden a salirse del standard y deben ser valorados cuidadosamente. En el desarrollo de software nos podemos encontrar con algo similar, la gran mayoría de las aplicaciones que se desarrollan se hacen muy a medida del usuario, es decir se apartan con mucha frecuencia de lo que serían aplicaciones fácilmente estimables.

Descompondremos el proceso de estimación del esfuerzo necesario para

realizar el desarrollo de una aplicación informática como muestra la figura 1.

PROYECTOS INFORMATICOS

14

MEDIR LO QUE QUIERE EL USUARIO, volviendo al ejemplo anterior

sería como medir la casa que se quiere es decir lo que serían m2 de suelo, pilares, vigas, etc., (en otros temas veremos lo relacionado con las calidades y también los riesgos de construir en zonas sísmicas). Conociendo los elementos (pilares, etc.) de los que constará nuestro sistema, pasamos a valorar cada uno de ellos. Hay pilares gordos, finos, altos y bajos, cada uno requiere una cantidad de hormigón diferente, un trabajo de encofrado, etc. Para valorar cada elemento utilizaremos medidas "objetivas" (con estadísticas anteriores) y una dimensión "homogénea". En el caso de la construcción es difícil pensar en una medida "homogénea" ya que intervienen muchas dimensiones m3 hormigón, m2 cristal, horas de trabajo, etc. En el caso de proyectos informáticos esta medida hará referencia, de forma indirecta, a la cantidad de esfuerzo humano y técnico a aplicar. Sumando las valoraciones de cada elemento obtendremos una primera aproximación del esfuerzo demandado.

También deberemos valorar otros factores que pueden afectar al coste,

tales como el tener que armonizar con el entorno o si el lugar de construcción es muy lluvioso o muy frío.

A lo largo del tema transferiremos esta estructura de cálculo al caso de

proyectos informáticos.

Medir lo quequiere elusuario

Estimar loque Costara(esfuerzo)

Descomponerpor fases y

tareas

HistorialEmpresa

Especificación derequerimientos

Requisitos aCumplir

Medida de lo quequiere el usuario

Estimacióndel Esfuerzo

Tareas arealizar

figura 1

2. ESTIMACIÓN DE ESFUERZO EN DESARROLLO DE SOFTWARE

15

ESTIMAR LO QUE COSTARÁ, Una vez medido lo que quiere el

usuario debemos estimar lo que le costará a nuestra empresa desarrollar este proyecto. Para realizar este proceso hace falta experiencia en valoraciones. Esta experiencia puede gestionarse de dos formas diferentes, individual y de empresa:

La experiencia individual es la que aporta un individuo de la

organización que, tras acumular muchas experiencias en su mente, tiene una apreciación de "por donde van los tiros".

La experiencia de empresa se basa en la información que ésta ha ido

acumulando en ficheros históricos sobre valoraciones realizadas y costes reales de desarrollos realizados.

Ésta última forma de experiencia es más deseable que la primera ya que

permite un mayor cúmulo de información, más proyectos. También es menos dependiente de las personas, con lo que la empresa será más estable a posibles pérdidas de personal. Además esta más estructurada ya que se pueden recoger todas las medidas que los diferentes directores de proyecto estimen necesarias. Por ejemplo podría recoger información sobre herramientas usadas, grado de experiencia al aplicarse, etc. Esto no quiere decir que la primera sea innecesaria, sino que habrá que conjugar las dos, ya que siempre habrá momentos en los que aplicar el "sentido común" y este es imposible de sintetizar completamente.

DESCOMPONER EL ESFUERZO POR FASES. Una vez obtenido el

esfuerzo, meses/hombre o similares, hay que asignar estos esfuerzos a tareas y personas, dado que no suele cobrar lo mismo el analista que el programador, el que tiene experiencia y el que no, etc. Lo razonable es identificar a grandes rasgos las diferentes componentes del proceso de desarrollo del software de modo que cada a una se pueda asignar un tipo determinado de personal.


16

Una vez conocidas las tareas a realizar se deberá programar (planificar), el proceso de desarrollo y de esta planificación obtendremos una estimación económica del coste. Este punto lo veremos en otros temas.

En este tema revisaremos varios métodos para realizar estimaciones del

coste de software. Nos centraremos en uno de los que actualmente tiene más respaldo entre los consultores, además de soporte con herramientas CASE e incluso parece ser que se encamina a transformarse en un standard.

2. METODOS UTILIZADOS PARA LA ESTIMACIÓN DE PROYECTOS.

La estimación de proyectos acompaña a cualquier ingeniería y la informática no es una excepción. Otro tema son los métodos utilizados y su fiabilidad (conformidad con los resultados obtenidos). Dada la juventud de la informática hasta hace poco no se vislumbraban métodos estándar. Esta es una de las razones que hace aconsejable el hacer un pequeño repaso a los métodos utilizados hasta hoy en día. La siguiente clasificación ha sido ampliada en clase:

Métodos basados exclusivamente en la experiencia:

Juicio experto

Puro, tal y como lo propone Gibson (página 59)

Delphi que es la propuesta de O’Conell (página 128)

Analogía. King en la página 86 da una visión detallada, aunque con estos métodos cada uno se lo adapta. O’Conell también lo comenta

Distribución de la utilización de recursos en el ciclo de vida como

base de la estimación como propone King (página 86)


17

Método basado exclusivamente en los recursos: Parkinson: Método basado exclusivamente en el mercado: Precio para vender Método basado en los componentes del producto a desarrollar o

proceso de desarrollo:

Top-Down

Bottom-up Métodos algorítmicos, se basan en la utilización de fórmulas que

aplicadas sobre modelos top-down o bottom-up producen una estimación de coste del proyecto

Barry W. Boehm en su articulo titulado “Software Engineering

Economics” hace un repaso de algunos de estos métodos.

3. PUNTOS DE FUNCIÓN.

Esta técnica de medición y estimación trata de evaluar una aplicación informática en base a sus características externas. Estas características se descomponen en dos grupos: la funcionalidad que provee el sistema y los factores de complejidad. La funcionalidad que provee el sistema son aquellos elementos que dan soporte a formularios de entrada, salidas, consultas y ficheros a los que debe dar soporte la aplicación. Los factores de complejidad son indicadores del entorno en que se ha de desarrollar y explotar la aplicación informática.

Este método de estimación contempla la aplicación a desarrollar como

una caja negra, es decir, no se interesa por las interioridades de la aplicación, sino que se centra en lo que puede ver el usuario.

El ejemplo clásico de una caja negra es el equipo de música, en el que los

usuarios están interesados por su funcionamiento externo, la calidad del


18

sonido y el coste, prescindiendo usualmente de como estén construidos los circuitos integrados o sus transistores.

Por otra parte evaluamos de forma explícita los factores de desarrollo que

influyen sobre la productividad como lenguajes de desarrollo, entornos de trabajo, etc. Seguiremos manteniendo la idea de caja negra, ya que los gestores del desarrollo no están interesados en cómo se desarrolla en cada lenguaje (ensamblador, 4GL, etc.) sino que se centran en los diferentes niveles de productividad que se tiene con cada uno de ellos. El que realiza la estimación necesitará tener información histórica que sea apropiada sobre los lenguajes, como veremos más adelante.

3.1. IDENTIFICACIÓN DE LOS ELEMENTOS DE FUNCIÓN.

Partimos de una especificación de la aplicación a desarrollar, en nuestro caso suponemos que está disponible el DFD de ésta, el modelo Entidad-Relación de los datos y el Diccionario de Datos que definen a la aplicación. La funcionalidad que provee el sistema esta asociada a los siguientes componentes de la aplicación:

Entradas desde el exterior del sistema (Pantallas, lecturas de scanner, etc.). Salidas al exterior (Pantallas, Listados, etc.). Consultas (entrada seguida de una salida). Ficheros lógicos internos, grupos de datos que se mantienen internamente. Ficheros de interfaz, grupos de datos que se mantienen externamente. Veamos algunas definiciones previas: Proceso elemental: es la menor unidad de actividad que tiene sentido para

el usuario, conocedor del sistema en estudio.


19

Datos e informaciones de control: son los datos elementales con que trabaja la aplicación en estudio. Nos referiremos a ellos siempre como datos aunque se componen de los Datos propios del sistema en estudio más las Informaciones de Control que solicita el usuario (mensajes de error, claves de seguridad, etc.)

Lógica de proceso: se trata de procesos que se producen como

consecuencia de un proceso elemental y puede ser de dos tipos:

Ediciones, algoritmos o cálculos Accesos a un fichero ya sea para consulta o actualización

Veamos en detalle cada tipo de elemento de función, su definición, y ejemplos de éstos.

3.1.1. ENTRADAS DESDE EL EXTERIOR DEL SISTEMA.

En esta categoría clasificaremos todos los procesos elementales que hacen llegar a la aplicación datos desde el exterior, provenientes de un usuario o de otra aplicación. El flujo de datos deberá tener una sola dirección, del exterior al interior. Como consecuencia de una entrada siempre deberá actualizarse un fichero lógico interno. En la figura 2 se muestra su apariencia en el DFD.

Ejemplo de estas entradas son

los procesos asociados a: Pantallas para entrada de datos a la aplicación en cada transacción.

figura 2


20

Otros tipos de entradas como lecturas de códigos de barras, tarjetas magnéticas, captura de imágenes, voz, o cualquier otro sistema que se utilice para obtener información suministrada por el usuario.

Un mismo formato externo de pantalla de entrada que se utilice varias

veces, se contará como diferentes procesos en el caso de estar soportado con una lógica distinta. Nos realizamos las siguientes preguntas para asegurarnos de contar una entrada:

Cuestión: Respuesta Entran datos desde exterior de la aplicación Sí Existen datos en algún fichero lógico interno que son actualizados Sí El proceso es la unidad mínima de actividad que tiene sentido para el

usuario Sí

El proceso es completo y deja al sistema en un estado consistente SÍ Para el proceso subyacente se debe de cumplir A o B A Lógica del proceso exclusiva de esta entrada, o la primera vez

que la contamos

B Los datos elementales son diferentes de otras entradas

3.1.2. SALIDAS

En esta categoría clasificaremos los procesos elementales que elaboran informaciones dentro del sistema y que se transmitan a un usuario u otra aplicación atravesando la frontera del sistema. En la figura 3 se muestra su apariencia en el DFD.

Las salidas están asociadas a: Pantallas para informar al

usuario del resultado de un proceso. Este puede ser correcto o erróneo.

figura 3


21

Listados que se producen como consecuencia de un proceso, incluimos

cualquier formato, ya sean textos, gráficos, códigos de barras, etc. Formatos especiales de salida como grabación de bandas magnéticas,

etc. Transferencias de datos a otras aplicaciones, ya sea mediante ficheros

editados con el formato requerido o transmisiones de datos. Identificaremos distintas salidas aunque tengan el mismo formato si la

lógica de generación es diferente, o viceversa aunque tengan la misma lógica, difieran los datos elementales que la componen.

Si de un mismo listado se hacen varias copias para enviar a diferentes

usuarios, sólo se contará una vez. Por el contrario si un listado incluye varias lógicas de generación se contarán varias veces, por ejemplo listado de compras de clientes se podría componer de un listado individualizado y a continuación de un listado resumido por zonas. Los mensajes de error que se producen en la edición de una entrada no se han de contar, ya que pertenecen a la entrada.

Nos realizamos las siguientes preguntas para asegurarnos de contar una

salida:

Cuestión: Respuesta

El proceso envía datos o información al exterior de la aplicación Sí

El proceso es la unidad mínima de actividad con sentido para el usuario Sí

El proceso es completo y deja al sistema en un estado consistente SÍ

Para el proceso subyacente se debe de cumplir A o B

A Lógica del proceso exclusiva de esta salida (o primera vez)

B Los datos elementales son diferentes de otras salidas


22

3.1.3. CONSULTAS.

En esta categoría clasificaremos los procesos elementales que están formados por una combinación de entrada y salida, produciendo una consulta a los datos.

La salida no puede contener información derivada (calculada). Como

consecuencia de una consulta no se modifican los datos del sistema (de ningún Fichero Lógico Interno).

En la figura 4 se muestra su

apariencia en el DFD. Son usuales en los sistemas

EN_LÍNEA, Las entradas de datos EN_LÍNEA suelen ir precedidas de una consulta.

Nos realizamos las siguientes

preguntas para asegurarnos de contar una consulta:

Cuestión: Respuesta Una petición atraviesa la frontera del sistema Sí El proceso envía datos o información al exterior de la aplicación Sí Se recuperan datos Sí No se calculan datos derivados para enviar al exterior Sí El proceso (entrada/salida) es la unidad mínima de actividad que tiene

sentido para el usuario Sí

El proceso es completo y deja al sistema en un estado consistente Sí El proceso no actualiza ningún Fichero Lógico Interno Sí Para el proceso subyacente se debe de cumplir A o B

A Lógica del proceso en su parte de entrada o salida, es distinto del de otras consultas del sistema (o la primera vez)

B Los datos elementales de la entrada o salida son diferentes de otras consultas

figura 4


23

3.1.4. FICHEROS LÓGICOS INTERNOS.

Un fichero lógico interno es un grupo de datos relacionados, tal y como los percibe el usuario y que son mantenidos por la aplicación. Es decir, como se usarían en un sistema manual.

Es importante diferenciar estos

de las entidades, relaciones, las tablas o los ficheros resultantes del diseño físico. Se identifican a las agrupaciones de datos que el usuario ya conoce como relevantes para el sistema, por ejemplo: Clientes, Artículos, Facturas, Proveedores, etc.

Los ficheros se cuentan una sola vez independientemente del número de

procesos o frecuencia con que sean accedidos. Por supuesto de las veces que aparezcan en los DFD para mejorar la legibilidad.

No hay que contar los ficheros de índices ni los ficheros intermedios

creados durante el diseño para simplificar el desarrollo, por ejemplo ficheros de spool por no disponer de impresora dedicada, etc. Los ficheros intermedios inherentes a la filosofía de la aplicación sí que se cuentan, por ejemplo matrícula-curso-97-98 que es actualizado por la aplicación y que el usuario ha solicitado su existencia hasta que se cierre la matrícula del curso y que más tarde se consolida en el fichero de alumnos, etc.

Nos realizamos las siguientes preguntas para asegurarnos de contar un

Fichero Lógico Interno:

Cuestión: Respuesta, Se trata de una agrupación de datos lógica o identificable desde el punto de vista del usuario y satisface un requerimiento específico del usuario

Sí

La agrupación de datos es mantenida por procesos de la aplicación en estudio Sí La agrupación de datos es mantenida mediante un proceso elemental de la aplicación

Sí

figura 5


24

La agrupación de datos no ha sido contada como un fichero de interfaz externo

Sí

3.1.5. FICHEROS DE INTERFAZ EXTERNOS.

Un fichero de interfaz externo es un grupo de datos relacionados, tal y como los percibe el usuario, referenciados por la aplicación, pero mantenidos por otra aplicación. Es decir, nuestra aplicación nunca actualizará un fichero de este tipo y además será un fichero interno de otra aplicación.

Pueden ser ficheros que son

generados por otra aplicación y distribuidos en la empresa. Aparecerán en el diagrama de contexto. Si el fichero que aparece en el diagrama de contexto lo utiliza un proceso para cargar ficheros internos, entonces se deberá contemplar como una entrada. En caso de escribirse un fichero, que aparece en el diagrama de contexto, con el fin de que sea entrada a otra aplicación, deberá contarse como una salida. Sólo contaremos como ficheros externos a aquellos que son mantenidos por otras aplicaciones y de los que nuestra aplicación hace uso.

Nos realizamos las siguientes preguntas para asegurarnos de contar un

Fichero de Interfaz Externo: Cuestión: Respuesta Se trata de una agrupación de datos lógica o identificable desde el punto de vista del usuario y satisface un requerimiento específico del usuario

Sí

La agrupación de datos es referenciada, y externa, a la aplicación en estudio

Sí

La agrupación de datos no es mantenida mediante la aplicación en estudio

Sí

La agrupación de datos ha sido contada como un fichero lógico Interno en otra aplicación

Sí

La agrupación de datos no ha sido contada como un fichero Sí

DIAGRAMA DE CONTEXTO

figura 6


25

lógico Interno de la aplicación en estudio 3.2. CÁLCULO DE LOS PUNTOS DE FUNCIÓN SIN AJUSTAR.

Las siguientes tablas muestran como clasificar los diferentes elementos de función y asignarles pesos. Así por ejemplo una entrada que contenga 10 atributos y que en su lógica se requiera acceder a un fichero diremos que se clasifica de complejidad baja y tiene asociados tres puntos de función, ver tablas adjuntas.

CLASIFICACIÓN Número de Campos o Atributos de la Entrada ENTRADAS 1-4 Atributos 5-15 Atributos 16 ó más Atrib. 0 ó 1 ficheros accedidos BAJA 3 BAJA 3 MEDIA 4 2 ficheros accedidos BAJA 3 MEDIA 4 ALTA 6 3 ó más ficheros accedidos MEDIA 4 ALTA 6 ALTA 6

CLASIFICACIÓN Número de Campos o Atributos de la Salida SALIDAS 1-5 Atributos 6-19 Atributos 20 ó más Atrib. 0 ó 1 ficheros accedidos BAJA 4 BAJA 4 MEDIA 5 2 ó 3 ficheros accedidos BAJA 4 MEDIA 5 ALTA 7 4 ó más ficheros accedidos MEDIA 5 ALTA 7 ALTA 7

En el caso de las consultas diferenciaremos la complejidad de lo que sería

la entrada y la salida, le asignaremos la complejidad mayor de las dos (baja, media o alta), pero solo un peso (3, 4 ó 6), equivalente al de una entrada de la complejidad calculada.

Los ficheros de las entradas, salidas y consultas se calculan a partir de los

ficheros, lógicos internos o de interfaz externos, que son accedidos durante el proceso asociado.

Los atributos son tipos de datos elementales reconocibles por el usuario.

En las entradas se contarán también aquellos datos que son almacenados en un fichero como consecuencia de la entrada. Los datos que se almacenen en muchos campos se contarán sólo una vez. Ejemplo DNI en la gestión de notas. En las salidas se contarán los campos calculados, por ejemplo totales. En las salidas no se deben contar ni los literales ni los campos provenientes de variables del sistema como fecha, número de página, opciones de próxima


26

página o página previa. Siempre se contarán los mensajes de verificación y error como un campo que puede contener estos valores. También se cuentan las opciones que indican la tarea a realizar, ejemplos son: aceptar o continuar.

Complejidad FICHEROS Número de Campos o Atributos LÓGICOS INTERNOS 1-19 Atributos 20-50 Atributos 51 o Atributos 1 Registro Lógico BAJA 7 BAJA 7 MEDIA 10 2-5 Registros Lógicos BAJA 7 MEDIA 10 ALTA 15 6 o más Registros Lógicos MEDIA 10 ALTA 15 ALTA 15

Complejidad FICHEROS Número de Campos o Atributos INTERFAZ EXTERNOS 1-19 Atributos 20-50 Atributos 51 Atributos 1 Registro Lógico BAJA 5 BAJA 5 MEDIA 7 2-5 Registros Lógicos BAJA 5 MEDIA 7 ALTA 10 6 o más Registros Lógicos MEDIA 7 ALTA 10 ALTA 10

Cuando se cuenten los atributos en un fichero se tendrá en cuenta: Sólo aquellos que el usuario es capaz de reconocer, aunque aparezcan

de forma repetida se cuentan una sola vez. Se han de contar los campos que hacen falta para mantener las

relaciones con otros ficheros Internos o Externos. Contar como un solo campo aquellos que aparecen como

consecuencia de las técnicas utilizadas en la implementación física:

Campos que aparecen más de una vez en una agrupación de datos por la tecnología o implementación. Por ejemplo un DNI que aparezca en alumno y en una tabla de aficiones, si hemos decidido que forman parte del mismo fichero las dos tablas.

Campos repetidos con el mismo formato pero que están para

permitir múltiples ocurrencias. Por ejemplo nota ordinaria (Febrero) y nota extraordinaria (Junio)


27

Para contar los registros lógicos (tipo de registro) de una agrupación de datos (fichero), se han de tener en cuenta las siguientes reglas:

Todo fichero tiene un conjunto de datos básicos (no repetitivos) más

otros registros lógicos. Un registro lógico es un subgrupo de datos elementales de un fichero,

identificables por el usuario. Hay dos tipos de subgrupos los obligatorios y los opcionales. En el fichero de alumnos sería obligatorio sus datos de acceso (Mayor-25, FP, COU y Otras-Carreras que contendrán datos diferentes, habrá sólo uno de estos, con el que accedió a la carrera actual) y opcionales como sus aficiones deportivas, aficiones de lectura, etc. que pueden aparecer o no.

Contar un registro lógico por cada subgrupo, opcional u obligatorio. Si no hay subgrupos contar un registro lógico. Con esto se puede realizar la clasificación de los elementos de función. A

continuación hay que calcular los puntos de función sin ajustar, para ello se puede utilizar la siguiente tabla, que además deja documentado el cálculo del los Puntos de Función sin Ajustar (PFSA).


28

Tipo Elemento Dificultad Peso Cantidad

Total Puntos

Total Elemento

Entradas Simple 3 E1 3 * E1 Media 4 E2 4 * E2 Compleja 6 E3 6 * E3 Total Puntos de Función

Entradas Peso * Ei

Salidas Simple 4 S1 4 * S1 Media 5 S2 5 * S2 Compleja 7 S3 7 * S3 Total Puntos de Función

Salidas

Peso * Si Consultas: Simple 3 C1 3 * C1 Máximo - Media 4 C2 4 * C2 Complejidad( Compleja 6 C3 6 * C3 Entrada, Salida ) Total Puntos de Función

Consultas Peso * Ci

Ficheros Internos Simple 7 F1 7 * F1 Media 10 F2 10 * F2 Compleja 15 F3 15 * F3 Total Puntos de Función

Ficheros Internos

Peso * Fi Ficheros de Simple 5 I1 5 * I1 Interfaz Media 7 I2 7 * I2 Compleja 10 I3 10 * I3 Total Puntos de Función

Ficheros de Interfaz

Peso * Ii

Total Puntos de Función Sin Ajustar (PFSA)

Peso*Xij

3.3. IDENTIFICACIÓN DE LOS FACTORES DE COMPLEJIDAD.

Los Puntos de Función sin ajustar son una aproximación de la complejidad del sistema, pero quedan características externas que no hemos contemplado, así como características del proceso de desarrollo del sistema informático que influirán en el coste del sistema y que podemos cuantificar desde las primeras fases del desarrollo. Estos factores adicionales según


29

Albrecht son catorce. Cada factor tomará un valor entre 0 y 5, de modo que cuanta más importancia tenga un factor mayor valor se le asignará.

La siguiente tabla indica los valores posibles de un factor y su significado.

Valor asignado Significado del valor 0 Sin influencia, factor no presente 1 Influencia insignificante, muy baja 2 Influencia moderada o baja 3 Influencia media, normal 4 Influencia alta, significativa 5 Influencia muy alta, esencial

Con estos valores calculados, los sumaremos y obtendremos el Factor de

Complejidad Total. A continuación describimos cada factor e indicamos cuando deberían

tomar los valores extremos, a modo de guía.

1) COMUNICACIÓN DE DATOS.

Los datos usados en el sistema se envían o reciben por líneas de comunicaciones.

0 Sistema aislado del exterior (sólo usuarios directos. Ej.: PC; BATCH ). 1 Aplicación batch con entrada de datos remota o (exclusiva) utilización

de periféricos de salida remotos. 2 Aplicación batch con entrada de datos remota y utilización de

periféricos de salida remotos. 3 plicación de captura de datos en línea o hay un sistema de

teleproceso que pasa los datos a la aplicación batch o sistema de consulta.

4 Varios teleprocesos pero con el mismo protocolo de comunicaciones.


30

5 Hay teleproceso con varios protocolos de comunicación. Sistema

Abierto y con interfaces de todo tipo al exterior.

2) PROCESO DISTRIBUIDO.

Existen Procesos o Datos distribuidos y el control de estos forma parte del sistema.

0 Sistema totalmente Centralizado o no tiene como objetivo el transferir

datos o procesos entre componentes del sistema. 1 El sistema realiza sus procesos en un equipo, pero las salidas se

preparan de modo que son utilizadas vía software de otros equipos. Por ejemplo a la salida del sistema se accede vía una hoja de cálculo o un procesador de textos en un PC.

2 El sistema captura los datos en un equipo, que les da formato, siendo

enviados a otro equipo del sistema que los trata. 3 Proceso distribuido pero con transferencia de datos "en línea" en una

sola dirección. 4 Proceso de datos distribuidos y transferencia de datos "en línea" en

ambas direcciones. Por ejemplo una red de cajeros automáticos en donde éstos procesan parte la transacción.

5 El sistema esta ejecutándose en una red con procesos cooperantes

ejecutándose en distintos equipos.

3) OBJETIVOS DE RENDIMIENTO.

Si el rendimiento es un requisito del sistema. Es decir es crítico algún factor como tiempo de respuesta o cantidad de operaciones por hora. Se tendrá que hacer consideraciones especiales durante el diseño, codificación y mantenimiento.


31

0 Rendimiento normal (el que suelen dar los sistemas informáticos en los

que no se pone énfasis en este tema). 1 Se indican requerimientos de rendimiento y del diseño que son

revisados, pero no es necesario tomar medidas especiales. 2 El tiempo de respuesta o cantidad de operaciones por hora es crítico en

algunos momentos. No se solicita que realicemos un diseño de la utilización de la CPU. Los procesos deberán estar terminados antes de la siguiente sesión de trabajo (próximo día)

3 El tiempo de respuesta o cantidad de operaciones por hora es crítico

durante todas las horas de trabajo. No se solicita que realicemos un diseño de la utilización de la CPU. Los requerimientos indican que los procesos con sistemas de interfaz deberán estar terminados según ciertas restricciones.

4 Además, los requerimientos indican que el tiempo de respuesta o la

cantidad de operaciones por hora es lo suficientemente crítico, como para requerir tareas de análisis de rendimiento durante la fase de diseño.

5 Además se utilizan herramientas de análisis de rendimiento durante el

diseño, desarrollo e instalación, con el objetivo de alcanzar el rendimiento demandado por el usuario.

4) CONFIGURACIÓN DE EXPLOTACIÓN USADA INTENSAMENTE

POR OTROS SISTEMAS.

El sistema tendrá que ejecutarse en un equipo en el que coexistirá con otros, compitiendo por los recursos, y esta es una característica fundamental, teniendo que tenerse en cuenta en la fase de diseño.

0 No se han indicado restricciones ni explícita ni implícitamente.


32

1 Existen restricciones, pero son las usuales de cualquier equipo departamental. No es necesario hacer consideraciones especiales.

2 El usuario declara explícitamente características de seguridad o

relativos a tiempos. 3 Algunos programas deben funcionar con restricciones en algún

procesador. 4 Las restricciones operativas definidas implican que el software deberá

funcionar con restricciones de uso del procesador central o en un procesador dedicado.

5 Además, hay restricciones especiales para la aplicación en los

componentes distribuidos del sistema.

5) TASA DE TRANSACCIONES.

La tasa de transacciones será elevada. Se tendrá que hacer consideraciones especiales durante el diseño, codificación e instalación.

0 No se prevén períodos con picos de transacciones. 1 Se prevén picos de operaciones de forma regular, pero poco frecuente

(mensualmente, trimestralmente o anualmente). Ejemplos serían la auto matricula, los cierres de contabilidad, o el préstamo de libros antes de los exámenes.

2 Se prevén picos de operaciones semanales. 3 Se prevén horas punta, diarias. Ejemplo sería las ventas en los

supermercados. 4 La tasa de transacciones se prevé tan elevada que durante el diseño se

debe incluir tareas de análisis del rendimiento.


33

5 Se ha especificado una cantidad de transacciones muy elevada. Se utilizarán herramientas de análisis de rendimiento durante el diseño, implementación e instalación.

6) ENTRADA DE DATOS EN-LÍNEA.

La entrada de datos será directa desde el usuario a la aplicación, de forma interactiva. 0 No hay entrada de datos interactiva, todo es batch. 1 Entre el 1% y el 7% de las transacciones son entradas interactivas. 2 Entre el 8% y el 15% de las transacciones son entradas interactivas. 3 Entre el 16% y el 23% de las transacciones son entradas interactivas. 4 Entre el 24% y el 30% de las transacciones son entradas interactivas. 5 La entradas de datos interactivas superan el 30% de las transacciones. 7) EFICIENCIA CON EL USUARIO FINAL.

Se demanda eficiencia para el usuario en su trabajo, es decir se tiene que diseñar e implementar la aplicación con interfaces fáciles de usar y con ayudas integradas. Los tipos de elementos asociados a la eficiencia del usuario son: Menús. Ayudas "en línea". Movimiento automático del cursor. Efectos de Scroll (papiro). Impresión remota (mediante transacciones en línea) Teclas de función predefinidas Lanzamiento de procesos batch desde las transacciones "en línea". Selección mediante cursor de datos de la pantalla. Pantallas con muchos colores y efectos. Documentación impresa de las operaciones “en línea”.


34

Uso de ratón. Ventanas de "pop-up". Forzar la aplicación a tener el menor número posible de pantallas por

transacción. Aplicación bilingüe (cuenta por cuatro). Aplicación Multilingüe (más de dos, cuenta por seis).

Toma el valor:

0 No hay especial énfasis en los interfaces de uso con el usuario. 1 De uno a tres de los factores anteriores. 2 De cuatro a cinco. 3 Seis o más factores, pero sin especiales requerimientos de eficiencia. 4 Más de seis factores, con requerimientos lo suficientemente específicos

como para justificar en el diseño estudios de los factores humanos. Ejemplo: minimizar la cantidad de pulsaciones, proveer valores por defecto, uso de marcos estandarizados, etc.

5 Igual al anterior, pero los requerimientos son tan fuertes que se

demanda la construcción de prototipos y utilización de herramientas para su evaluación y comprobar que se alcanzarán los objetivos.

8) ACTUALIZACIONES EN-LÍNEA.

Los ficheros maestros y las Bases de Datos son modificados directamente de forma interactiva.

0 No hay actualizaciones interactivas. 1 Actualización en línea de uno a tres ficheros con información de

control. Ejemplo fichero con usuarios, horas en que se puede acceder,


35

etc. La cantidad de actualizaciones es baja y es fácil recuperar el fichero.

2 Igual al anterior, pero con cuatro o más ficheros de control. 3 Actualización En-Línea de ficheros lógicos internos importantes.

Ejemplo: en un banco sería TRANSACCIONES, CLIENTES, CUENTAS, etc.

4 Además de lo anterior, es esencial la protección ante perdidas y el

sistema se ha de diseñar e implementar con estas consideraciones. 5 Gran cantidad de actualizaciones interactivas, debiéndose considerar

los costes de recuperación. Además deben tenerse sistemas de recuperación, en caso de fallo, muy automatizados y con poca intervención del operador.

9) LÓGICA DE PROCESO INTERNO COMPLEJA.

La complejidad de los procesos es una característica de la aplicación. Alguna de las siguientes características está presente:

a) Los algoritmos matemáticos especificados complejos. b) Procesos con lógica compleja. c) Se han especificado muchas excepciones, consecuencia de

transacciones incompletas, que deberán tratarse. d) Manejar múltiples dispositivos de entrada/salida. e) La aplicación llevará incorporados sistemas de seguridad y control. La complejidad algorítmica realmente está mal resuelta en esta técnica.

Hay que tener en cuenta que se ha desarrollado pensando en sistemas de


36

proceso empresarial. Para sistemas complejos algorítmicamente hay técnicas que miden la complejidad como las de Mc Cabe. La valoración será la siguiente: 0 No se da ninguna de las características anteriores. 1 Se da una característica de las enunciadas. 2 Se dan dos características de las enunciadas. 3 Se dan tres características de las enunciadas. 4 Se dan cuatro características de las enunciadas. 5 Se dan las cinco características de las enunciadas. 10) REUSABILIDAD DEL CÓDIGO.

Se tendrá que hacer consideraciones especiales durante el diseño, codificación y mantenimiento para que el código se reutilice en otras aplicaciones.

0 No se piensa en reutilizar el código a generar. 1 Se pretende reutilizar el código a generar dentro de la propia

aplicación. 2 Menos del 10% de la aplicación tiene en cuenta las necesidades de más

de un usuario (sistema). 3 El 10% de la aplicación o más tiene en cuenta las necesidades de más

de un usuario (sistema). 4 La aplicación ha sido específicamente empaquetada y/o documentada

para ser fácil de reutilizar. La aplicación se adaptará a las necesidades de los usuarios a nivel de código.


37

5 La aplicación ha sido específicamente empaquetada y/o documentada

para ser fácil de reutilizar. La aplicación se adaptará a las necesidades de los usuarios por medio de parámetros.

11) CONTEMPLA LA CONVERSIÓN E INSTALACIÓN.

Se proveerán facilidades de instalación y conversión en el sistema. Se desea que la conversión del sistema antiguo sea fácil de realizar durante la puesta en marcha del sistema nuevo.

0 No reemplazamos un sistema existente o no se requiere conversión.

Tampoco se enuncia nada sobre la instalación. 1 Se solicita facilidad de instalación. 2 Se ha solicitado procesos de conversión e instalación, se han

construido guías y han sido probadas, pero no son considerados importantes en el proyecto.

3 Se han solicitado procesos de conversión e instalación, dándose guías

explícitas, y estos procesos han de ser probados. En este proyecto se considera muy importante el proceso de conversión.

4 Adicionalmente a la valoración de 2 se añade el que tendrán que

desarrollarse herramientas de conversión e instalación probadas. 5 Adicionalmente a la valoración de 3 se añade el que tendrán que

desarrollarse herramientas de conversión e instalación probadas. El sistema es crítico para la empresa y ya estaba automatizado. Los usuarios no pueden permitirse el lujo de tener problemas o bajo rendimiento durante la transición. Estas condiciones se han descrito como requisitos a cumplir por el sistema.


38

12) FACILIDAD DE OPERACIÓN.

Entendemos por operación del sistema los trabajos asignados al centro de proceso de datos para una aplicación dada como: arranque, parada, recuperación ante fallos, copias de seguridad. Aquí tendremos en cuenta la minimización de las actividades manuales en el CPD. Así, ésta característica se valora cuando se ha descrito desde las primeras fases, habiendo de dedicarse especial atención durante el diseño, codificación y pruebas.

Se pueden tener en cuenta las siguientes posibilidades de automatización:

Se proveerá de procesos de arranque, back-up y recuperación pero con

intervención del operador. Se proveerá de procesos de arranque, back-up y recuperación pero sin

intervención del operador (vale por dos). En la aplicación se minimiza la necesidad de montar cintas u otros

dispositivos de almacenamiento externo. Se minimiza la necesidad de manejar papel. Valoraremos con: 0 No se especifica nada, en todo caso lo que debieran ser procedimientos

usuales de back-up. 1 a 4 sumar la cantidad de ítems en la lista anterior. 5 Sistema automático sin intervención humana.

13) INSTALACIONES MÚLTIPLES

El sistema ha de incluir los requerimientos de diversas empresas o departamentos en donde se ejecutará (incluso distintas plataformas). Estas características estarán presentes durante el diseño, codificación y pruebas.


39

0 En sólo un lugar. 1 Múltiples lugares pero con idéntico Hardware y entorno Software. 2 En el diseño se ha de tener en cuenta que rodará en diferentes

entornos, pero con Hardware y Software similares. 3 La aplicación deberá rodar en múltiples entornos de Hardware o

Software y se tiene en cuenta desde la fase de diseño. 4 Se documentará y se planearán sistemas para dar soporte a la

situaciones descritas en las valoraciones 1 o 2. 5 Se documentará y se planearán sistemas para dar soporte a la situación

descrita en la valoración 3.

14) FACILIDAD DE CAMBIOS

Se tendrá que hacer consideraciones especiales durante el diseño, codificación y mantenimiento para que en el sistema sea fácil de introducir cambios y fácil de adaptar al usuario. Esto contemplara:

a) Consultas flexibles del usuario. Podemos tener Consultas:

Simples con condiciones lógicas And/Or que implican un solo fichero lógico. Contar 1.

Medias con condiciones lógicas de complejidad media mediante

And/Or que relacionan a más de un fichero lógico. Contar 2. Complejas con condiciones lógicas muy complejas mediante

combinaciones lógicas And/Or entre varios ficheros lógicos). Contar 3.

b) Parámetros de la aplicación vía tablas ajenas al código.


40

El cambio de la configuración se hace efectivo al arrancar el sistema al día siguiente. Contar 1.

El cambio de la configuración se hace interactivamente y tiene

efecto inmediato. Contar 2.

Toma el valor: 0 No se especifica nada. 1 Se da un ítem de los descritos anteriormente con valor 1. 2 Se dan algunos ítems de los descritos anteriormente acumulando un

valor de 2. 3 Se dan algunos ítems de los descritos anteriormente acumulando un



valor de 5.


41

CÁLCULO DEL FACTOR DE COMPLEJIDAD TOTAL.

La siguiente tabla documenta el cálculo del factor de complejidad total (FCT).

# Factor de Complejidad Valor (0..5)

1 Comunicación de Datos.

2 Proceso Distribuido.

3 Objetivos de Rendimiento

4 Configuración de Explotación compartida

5 Tasa de Transacciones

6 Entrada de Datos EN-LÍNEA

7 Eficiencia con el Usuario Final

8 Actualizaciones EN-LÍNEA

9 Lógica del Proceso Interno Compleja

10 Reusabilidad del Código

11 Contempla la Conversión e Instalación

12 Facilidad de Operación

13 Instalaciones Múltiples

14 Facilidad de Cambios

Factor de Complejidad Total (FCT) Valori

3.4. OBTENCIÓN DE LOS PUNTOS DE FUNCIÓN AJUSTADOS.

Para obtener los puntos de función ajustados de una aplicación se utiliza la siguiente fórmula:

PFA = PFSA * (0.65 + (0.01 * FCT))


42

Esta fórmula indica que en principio cada factor de complejidad puede actuar sobre los PFSA incrementando o disminuyendo en un 2,5% la cantidad de puntos de función ajustados.

De forma global producirá una

valoración de los PFA de entre el 65% y el 135% del PFSA.

Para calcular los puntos de función de un proyecto nos podemos

encontrar en tres situaciones: La aplicación a desarrollar parte de cero. No tenemos nada

desarrollado que podamos utilizar, ni tenemos que convertir datos de una aplicación previa. En este caso se aplica la fórmula que mide el tamaño de la aplicación.

La aplicación a desarrollar parte de una aplicación previa de la que

sólo se desea convertir los datos a la nueva aplicación. Deberemos añadir a los puntos de función sin ajustar el tamaño que incorporaran las utilidades de conversión (puntos de función de la conversión CONVER). Así:

PFC=(PFSA+CONVER)*(0,65+(0,01*FCT)) El cálculo más complejo se da cuando modificamos una aplicación. La

fórmula a utilizar es: PFM = [(AÑADIDO+CAMBIADO+CONVER) * (0,65+(0,01*FCD))] +

(BORR*(0,65+(0,01*FCP))) Donde se introducen los PF añadidos, cambiados, borrados y de

conversión, así como los factores de complejidad después de la modificación (FCD) y los factores de complejidad previos a la modificación (FCP)

0 35 700

20

40

60

80

100

120

140

0 35 70


43

4. ESTIMACIÓN DEL ESFUERZO REQUERIDO POR LA APLICACIÓN.

El objetivo ahora es estimar la cantidad de esfuerzo necesario para desarrollar la aplicación. Este esfuerzo se mide en horas/hombre, meses/hombre o años/hombre. Los puntos de función en cierto modo son una medida subjetiva (aunque el objetivo de IFPUG es que esta subjetividad se minimice), ya que se puede realizar valoraciones diferentes por personas con diferentes puntos de vista. Además en principio este número no dice nada, nos hace falta conocer la cantidad de meses/hombre que costará cada punto de función.

La cantidad de horas/hombre por punto de función es algo difícil e

impreciso de valorar, de forma global. Esto es normal, lo contrario sería suponer que la productividad de todas las empresas de desarrollo de software es igual.

Se ha constatado que en una misma empresa se pueden realizar

estimaciones muy buenas conociendo su productividad histórica, aquí si que tiene sentido el esperar que los puntos de función tengan cierta uniformidad, cuando se utilizan entornos similares.

De forma general, para proyectos de tamaño medio (300 PFA), se han

publicado valores como los mostrados en la siguiente tabla:

Entorno, Lenguaje Horas / Punto Función Líneas Código/P.Función Ensamblador 20 a 30 300 COBOL 10 a 20 100 Lenguajes 4GL 5 a 10 20

De todos modos esto no deja de ser una orientación ya que como indica

Thomsett algunas organizaciones usan valores como 40 horas por punto de función en COBOL.


44

Dreger comenta que la productividad no sólo varía entre programadores,

sino que también con el tamaño del proyecto. Indica que en algunos estudios se ha llegado a la conclusión de que un equipo medio, en un proyecto de 400 PFA, utiliza 20 horas por punto de función, mientras que en un proyecto de 2000 PFA, pasa a ser de 52 horas por punto de función.

En cualquier caso nuestra empresa deberá mantener una base de datos con

la información de los proyectos realizados en ésta. Se deberá tener como mínimo los puntos de función que se estimaron en cada proyecto, los que resultaron a final del proyecto, el esfuerzo que costó, el entorno y los lenguajes utilizados. Si deseamos una mejor información deberíamos mantener la información de base para calcular los puntos de función, factores de complejidad y añadir aquellos factores que pensemos que son relevantes en nuestra organización. Un ejemplo de esto puede ser el suponer que el apoyo de la alta dirección es un elemento clave, así pues lo valoraremos de 0 a 5 y mantendremos esta información para posibles interpretaciones futuras.

Con todas las cautelas que hemos indicado, podemos calcular el esfuerzo

requerido en nuestra organización para un proyecto como:

Suponiendo que nuestra organización realiza proyectos de características

similares, con tamaños de entre 200 y 500 puntos de función. Para una mayor precisión consultar la bibliografía.

Con esto obtendremos una aproximación a la cantidad bruta de horas,

meses o años hombre necesario. Hay que tener en cuenta que normalmente, aunque se trabaja 8 horas

diarias, sólo 5 son productivas, que un mes tiene 20 días de trabajo efectivos,

Esfuerzo = PFA * Promedio_Organización( Lenguaje )


45

y que un año tiene 11 meses de trabajo. Es decir aproximadamente un año tiene 220 días de trabajo real.

5. OTRAS UTILIDADES DE LAS MEDICIONES MEDIANTE PUNTOS DE FUNCIÓN.

Dado que lo que realmente miden los puntos de función es la funcionalidad de una aplicación informática, también se utilizan para:

Comparar lo que solicitó el cliente con lo que recibió. Comparar la productividad de los diferentes entornos de desarrollo. Comparar la calidad que se obtiene mediante las diferentes técnicas de

desarrollo.

6. BIBLIOGRAFÍA Y REFERENCIAS A CONSULTAR.

1. Albrecht, A.J. and Gaffney, J.E. "Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation". IEEE Transaction on Software Engineering, Vol. SE-9, Nº 6, Nov. 1983, pp. 639-648.

2. Boehm, Barry. Software Engineering Economics. Reimpreso en Software Management (4 ed.), Donald J. Reifer, IEEE Computer Society Press 1993.

3. Dreger, J.B. "Function Point Analysis", Prentice Hall, 1989. 4. Gibson, Robin. Managing Computer Projects. Avoiding the Pitfalls.

Prentice Hall, 1992. 5. International Function Point Users Group: "Function Point as an Asset -

Reporting to Management", 1992. 6. International Function Point Users Group: "Function Point Counting

Practices Manual: Case Studies (Case Study 2)", Release 1.0, 1994.


46

7. International Function Point Users Group: "Function Point Counting Practices Manual", Release 4.0, 1994.

8. Jones, Capers. Applied Software Measurement - Assuring Productivity and Quality". McGraw Hill, 1991.

9. Jones, Capers. Assessment and Control of Software Risks. Yourdon Press, Prentice Hall, 1994.

10. King, Davis. Project Management Made Simple. A guide to successful of computer Systems projects. Yourdon Press, Prentice Hall, 1992.

11. Kemerer, C.F.. "Reliability of Function Point Measurement: A Field Experiment", Communications of the ACM, Feb. 1993.

12. Kemerer, C.F. and Porter B.S. "Improving the Reliability of Function Point Measurement: An Empirical Study", IEEE Transaction on Software Engineering, Vol. SE-18, Nº 11, Nov. 1992, pp. 1011-1024.

13. Low, G.C. and Jeffery, D.R. "Function Point in the Estimation and Evaluation of the Software Process", IEEE Transaction on Software Engineering, Vol. SE-16, Nº 1, Jan. 1990, pp. 64-71.

14. O’Connell, Fergus. How to Run Successful projects. BCS Series, Prentice Hall, 1994.

15. Pressman, R. Ingeniería de Software, un enfoque aplicado. McGraw Hill 1993.

16. Thomsett, Rob. Third Wave Project Management: a Handbook for Managing the Complex Information Systems of the 1990s. Yourdon Press, Prentice Hall, 1993.

estimacion 2 pmbok

Documents

Transcript of estimacion 2 pmbok