Está en la página 1de 34

4. ESTIMACIN EN DESARROLLO DE SOFTWARE.

1. INTRODUCCIN.
Este tema se centra en la estimacin del esfuerzo que tendr que realizar una empresa para desarrollar una aplicacin. Por esfuerzo nos referimos a la cantidad de recursos humanos, usualmente medidos en meses/hombre. Partiremos de que ya se ha realizado un anlisis estructurado y disponemos de la especificacin de requerimientos del sistema. Por desgracia esto no es habitual, como dice Edward Yourdon un problema de la estimacin es que se nos pide que la realicemos cuando an no est claro que desea el usuario (no disponemos de la especificacin). Comparando esta ingeniera con la arquitectura (construccin de edificios), el arquitecto para valorar lo que costar construir un edificio necesitar tener los planos de ste. Adems, lo que en urbanismo se conoce con el nombre de edificio singular ,edificios que tienen formas extraas (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 mayora de las aplicaciones que se desarrollan se hacen muy a medida del usuario, es decir se apartan con mucha frecuencia de lo que seran aplicaciones fcilmente estimables. Descompondremos el proceso de estimacin del esfuerzo necesario para realizar el desarrollo de una aplicacin informtica como muestra la figura 1.

13

PLANIFICACIN DE PROYECTOS INFORMATICOS

Especificacin de requerimientos

Requisitos a Cumplir

Tareas a realizar

Medir lo que quiere el usuario

Estimacin Descomponer del Esfuerzo por fases y tareas Estimar lo que Costara (esfuerzo)

Medida de lo que quiere el usuario

Historial Empresa

figura 1 MEDIR LO QUE QUIERE EL USUARIO, volviendo al ejemplo anterior sera como medir la casa que se quiere es decir lo que seran m2 de suelo, pilares, vigas, etc., (en otros temas veremos lo relacionado con las calidades y tambin los riesgos de construir en zonas ssmicas). 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 hormign diferente, un trabajo de encofrado, etc.. Para valorar cada elemento utilizaremos medidas "objetivas" (con estadsticas anteriores) y una dimensin "homognea". En el caso de la construccin es difcil pensar en una medida "homognea" ya que intervienen muchas dimensiones m3 hormign, m2 cristal, horas de trabajo, etc.. En el caso de proyectos informticos esta medida har referencia, de forma indirecta, a la cantidad de esfuerzo humano y tcnico a aplicar. Sumando las valoraciones de cada elemento obtendremos una primera aproximacin del esfuerzo demandado. Tambin deberemos valorar otros factores que pueden afectar al coste, tales como el tener que armonizar con el entorno o si el lugar de construccin es muy lluvioso o muy fro. A lo largo del tema transferiremos esta estructura de clculo al caso de proyectos informticos.

14

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

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 organizacin que, tras acumular muchas experiencias en su mente, tiene una apreciacin de "por donde van los tiros". La experiencia de empresa se basa en la informacin que sta ha ido acumulando en ficheros histricos sobre valoraciones realizadas y costes reales de desarrollos realizados. sta ltima forma de experiencia es ms deseable que la primera ya que permite un mayor cmulo de informacin, ms proyectos. Tambin es menos dependiente de las personas, con lo que la empresa ser ms estable a posibles prdidas de personal. Adems esta ms estructurada ya que se pueden recoger todas las medidas que los diferentes directores de proyecto estimen necesarias. Por ejemplo podra recoger informacin 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 habrn momentos en los que aplicar el "sentido comn" 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. Una vez conocidas las tareas a realizar se deber programar (planificar), el proceso de desarrollo y de esta planificacin obtendremos una estimacin econmica del coste. Este punto lo veremos en otros temas.

15

PLANIFICACIN DE PROYECTOS INFORMATICOS

En este tema revisaremos varios mtodos para realizar estimaciones del coste de software. Nos centraremos en uno de los que actualmente tiene ms respaldo entre los consultores, adems de soporte con herramientas CASE e incluso parece ser que se encamina a transformarse en un standard.

2. METODOS UTILIZADOS PARA LA ESTIMACIN DE PROYECTOS.


La estimacin de proyectos acompaa a cualquier ingeniera y la informtica no es una excepcin. Otro tema son los mtodos utilizados y su fiabilidad (conformidad con los resultados obtenidos). Dada la juventud de la informtica hasta hace poco no se vislumbraban mtodos estndar. Esta es una de las razones que hace aconsejable el hacer un pequeo repaso a los mtodos utilizados hasta hoy en da. La siguiente clasificacin ha sido ampliada en clase: Mtodos basados exclusivamente en la experiencia: Juicio experto Puro, tal y como lo propone Gibson (pgina 59) Delphi que es la propuesta de OConell (pgina 128) Analoga. King en la pgina 86 da una visin detallada, aunque con estos mtodos cada uno se lo adapta. OConell tambin lo comenta Distribucin de la utilizacin de recursos en el ciclo de vida como base de la estimacin como propone King (pgina 86) Mtodo basado exclusivamente en los recursos: Parkinson: Mtodo basado exclusivamente en el mercado: Precio para vender

16

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

Mtodo basado en los componentes del producto a desarrollar o proceso de desarrollo: Top-Down Bottom-up Mtodos algortmicos, se basan en la utilizacin de frmulas que aplicadas sobre modelos top-down o bottom-up producen una estimacin de coste del proyecto Barry W. Boehm en su articulo titulado Software Engineering Economics hace un repaso de algunos de estos mtodos.

3. PUNTOS DE FUNCIN.
Esta tcnica de medicin y estimacin trata de evaluar una aplicacin informtica en base a sus caractersticas externas. Estas caractersticas 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 aplicacin. Los factores de complejidad son indicadores del entorno en que se ha de desarrollar y explotar la aplicacin informtica. Este mtodo de estimacin contempla la aplicacin a desarrollar como una caja negra, es decir, no se interesa por las interioridades de la aplicacin, sino que se centra en lo que puede ver el usuario. El ejemplo clsico de una caja negra es el equipo de msica, en el que los usuarios estn interesados por su funcionamiento externo, la calidad del sonido y el coste, prescindiendo usualmente de como estn construidos los circuitos integrados o sus transistores. Por otra parte evaluamos de forma explcita los factores de desarrollo que influyen sobre la productividad como lenguajes de desarrollo, entornos de 17

PLANIFICACIN DE PROYECTOS INFORMATICOS

trabajo, etc. Seguiremos manteniendo la idea de caja negra, ya que los gestores del desarrollo no estn interesados en cmo 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 estimacin necesitar tener informacin histrica que sea apropiada sobre los lenguajes, como veremos ms adelante. 3.1. IDENTIFICACIN DE LOS ELEMENTOS DE FUNCIN. Partimos de una especificacin de la aplicacin a desarrollar, en nuestro caso suponemos que est disponible el DFD de sta, el modelo EntidadRelacin de los datos y el Diccionario de Datos que definen a la aplicacin. La funcionalidad que provee el sistema esta asociada a los siguientes componentes de la aplicacin: Entradas desde el exterior del sistema (Pantallas, lecturas de scanner, etc.). Salidas al exterior (Pantallas, Listados, etc.). Consultas (entrada seguida de una salida). Ficheros lgicos 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. Datos e informaciones de control: son los datos elementales con que trabaja la aplicacin en estudio. Nos referiremos a ellos siempre como datos aunque se componen de los Datos propios del sistema en estudio ms las Informaciones de Control que solicita el usuario (mensajes de error, claves de seguridad, etc.) 18

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

Lgica de proceso: se trata de procesos que se producen como consecuencia de un proceso elemental y puede ser de dos tipos: Ediciones, algoritmos o clculos Accesos a un fichero ya sea para consulta o actualizacin Veamos en detalle cada tipo de elemento de funcin, su definicin, y ejemplos de stos. 3.1.1. ENTRADAS DESDE EL EXTERIOR DEL SISTEMA. En esta categora clasificaremos todos los procesos elementales que hacen llegar a la aplicacin datos desde el exterior, provenientes de un usuario o de otra aplicacin. El flujo de datos deber tener una sola direccin, del exterior al interior. Como consecuencia de una entrada siempre deber actualizarse un fichero lgico interno. En la figura 2 se muestra su apariencia en el DFD. Ejemplo de estas entradas son los procesos asociados a:

figura 2

Pantallas para entrada de datos a la aplicacin en cada transaccin. Otros tipos de entradas como lecturas de cdigos de barras, tarjetas magnticas, captura de imgenes, voz, o cualquier otro sistema que se utilice para obtener informacin 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

19

PLANIFICACIN DE PROYECTOS INFORMATICOS

una lgica distinta. Nos realizamos las siguientes preguntas para asegurarnos de contar una entrada:

Cuestin: Entran datos desde exterior de la aplicacin Existen datos en algn fichero lgico interno que son actualizados El proceso es la unidad mnima de actividad que tiene sentido para el usuario El proceso es completo y deja al sistema en un estado consistente Para el proceso subyacente se debe de cumplir A Lgica del proceso exclusiva de esta entrada, o la primera vez que la contamos B Los datos elementales son diferentes de otras entradas

Respuesta S S S S AoB

3.1.2. SALIDAS En esta categora clasificaremos los procesos elementales que elaboran informaciones dentro del sistema y que se transmitan a un usuario u otra aplicacin atravesando la frontera del sistema. En la figura 3 se muestra su apariencia en el DFD. Las salidas estn asociadas a: Pantallas para informar al usuario del resultado de un proceso. Este puede ser correcto o errneo. figura 3

Listados que se producen como consecuencia de un proceso, incluimos cualquier formato, ya sean textos, grficos, cdigos de barras, etc.. Formatos especiales de salida como grabacin de bandas magnticas, etc. 20

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

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 lgica de generacin es diferente, o viceversa aunque tengan la misma lgica, difieran los datos elementales que la componen. Si de un mismo listado se hacen varias copias para enviar a diferentes usuarios, slo se contar una vez. Por el contrario si un listado incluye varias lgicas de generacin se contar varias veces, por ejemplo listado de compras de clientes se podra componer de un listado individualizado y a continuacin de un listado resumido por zonas. Los mensajes de error que se producen en la edicin 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:
Cuestin: El proceso enva datos o informacin al exterior de la aplicacin El proceso es la unidad mnima de actividad con sentido para el usuario El proceso es completo y deja al sistema en un estado consistente Para el proceso subyacente se debe de cumplir A B Lgica del proceso exclusiva de esta salida (o primera vez) Los datos elementales son diferentes de otras salidas Respuesta S S S AoB

3.1.3. CONSULTAS. En esta categora clasificaremos los procesos elementales que estn formados por una combinacin de entrada y salida, produciendo una consulta a los datos.

21

PLANIFICACIN DE PROYECTOS INFORMATICOS

La salida no puede contener informacin derivada (calculada). Como consecuencia de una consulta no se modifican los datos del sistema (de ningn Fichero Lgico Interno). En la figura 4 se muestra su apariencia en el DFD. Son usuales en los sistemas EN_LNEA, Las entradas de datos EN_LNEA suelen ir precedidas de una consulta. Nos realizamos las siguientes preguntas para asegurarnos de contar una consulta: figura 4
Cuestin: Una peticin atraviesa la frontera del sistema El proceso enva datos o informacin al exterior de la aplicacin Se recuperan datos No se calculan datos derivados para enviar al exterior El proceso (entrada/salida) es la unidad mnima de actividad que tiene sentido para el usuario El proceso es completo y deja al sistema en un estado consistente El proceso no actualiza ningn Fichero Lgico Interno Para el proceso subyacente se debe de cumplir A Lgica 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 Respuesta S S S S S S S AoB

3.1.4. FICHEROS LGICOS INTERNOS. Un fichero lgico interno es un grupo de datos relacionados, tal y como los percibe el usuario y que son mantenidos por la aplicacin. Es decir, como se usaran en un sistema manual.

22

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

Es importante diferenciar estos de las entidades, relaciones, las tablas o los ficheros resultantes del diseo fsico. Se identifican a las agrupaciones de datos que el usuario ya conoce como relevantes para el sistema, por ejemplo: Clientes, Artculos, Facturas, Proveedores, etc.

figura 5

Los ficheros se cuentan una sola vez independientemente del nmero 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 diseo para simplificar el desarrollo, por ejemplo ficheros de spool por no disponer de impresora dedicada, etc.. Los ficheros intermedios inherentes a la filosofa de la aplicacin s que se cuentan, por ejemplo matrcula-curso-97-98 que es actualizado por la aplicacin y que el usuario ha solicitado su existencia hasta que se cierre la matrcula del curso y que ms tarde se consolida en el fichero de alumnos UPV, etc. Nos realizamos las siguientes preguntas para asegurarnos de contar un Fichero Lgico Interno:
Cuestin: Se trata de una agrupacin de datos lgica o identificable desde el punto de vista del usuario y satisface un requerimiento especfico del usuario La agrupacin de datos es mantenida por procesos de la aplicacin en estudio La agrupacin de datos es mantenida mediante un proceso elemental de la aplicacin La agrupacin de datos no ha sido contada como un fichero de interfaz externo Respuesta, S S S S

23

PLANIFICACIN DE PROYECTOS INFORMATICOS

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 aplicacin, pero mantenidos por otra aplicacin. Es decir, nuestra aplicacin nunca actualizar un fichero de este tipo y adems ser un fichero interno de otra aplicacin.

DIAGRAMA DE CONTEXTO

figura 6 Pueden ser ficheros que son generados por otra aplicacin y distribuidos en la empresa. Aparecern 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 aplicacin, deber contarse como una salida. Slo contaremos como ficheros externos a aquellos que son mantenidos por otras aplicaciones y de los que nuestra aplicacin hace uso. Nos realizamos las siguientes preguntas para asegurarnos Fichero de Interfaz Externo: Cuestin: Se trata de una agrupacin de datos lgica o identificable desde el punto de vista del usuario y satisface un requerimiento especfico del usuario La agrupacin de datos es referenciada, y externa, a la aplicacin en estudio La agrupacin de datos no es mantenida mediante la aplicacin en estudio La agrupacin de datos ha sido contada como un fichero lgico Interno en otra aplicacin La agrupacin de datos no ha sido contada como un fichero lgico Interno de la aplicacin en estudio 24 de contar un Respuesta
S

S S S S

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

3.2. CLCULO DE LOS PUNTOS DE FUNCIN SIN AJUSTAR. Las siguientes tablas muestran como clasificar los diferentes elementos de funcin y asignarles pesos. As por ejemplo una entrada que contenga 10 atributos y que en su lgica se requiera acceder a un fichero diremos que se clasifica de complejidad baja y tiene asociados tres puntos de funcin, ver tablas adjuntas.
CLASIFICACIN ENTRADAS 0 1 ficheros accedidos 2 ficheros accedidos 3 ms ficheros accedidos CLASIFICACIN SALIDAS 0 1 ficheros accedidos 2 3 ficheros accedidos 4 ms ficheros accedidos Nmero de Campos o Atributos de la Entrada 1-4 Atributos 5-15 Atributos 16 ms Atrib. BAJA BAJA MEDIA 3 3 4 BAJA MEDIA ALTA 3 4 6 MEDIA ALTA ALTA 4 6 6 Nmero de Campos o Atributos de la Salida 1-5 Atributos 6-19 Atributos 20 ms Atrib. BAJA BAJA MEDIA 4 4 5 BAJA MEDIA ALTA 4 5 7 MEDIA ALTA ALTA 5 7 7

En el caso de las consultas diferenciaremos la complejidad de lo que sera 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, lgicos 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 contarn tambin aquellos datos que son almacenados en un fichero como consecuencia de la entrada. Los datos que se almacenen en muchos campos se contarn slo una vez. Ejemplo DNI en la gestin de notas. En las salidas se contarn 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, nmero de pgina, opciones de prxima pgina o pgina previa. Siempre se contarn los mensajes de verificacin y error como un campo que puede contener estos valores. 25

PLANIFICACIN DE PROYECTOS INFORMATICOS

Tambin se cuentan las opciones que indican la tarea a realizar, ejemplos son: aceptar o continuar.
Complejidad FICHEROS LGICOS INTERNOS 1 Registro Lgico 2-5 Registros Lgicos 6 o ms Registros Lgicos Complejidad FICHEROS INTERFAZ EXTERNOS 1 Registro Lgico 2-5 Registros Lgicos 6 o ms Registros Lgicos Nmero de Campos o Atributos 1-19 Atributos 20-50 Atributos 51 o - Atributos BAJA BAJA MEDIA 7 7 10 BAJA MEDIA ALTA 7 10 15 MEDIA ALTA ALTA 10 15 15 Nmero de Campos o Atributos 1-19 Atributos 20-50 Atributos 51 - Atributos BAJA BAJA 5 5 MEDIA 7 BAJA MEDIA ALTA 5 7 10 MEDIA ALTA 7 10 ALTA 10

Cuando se cuenten los atributos en un fichero se tendr en cuenta: Slo 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 tcnicas utilizadas en la implementacin fsica: Campos que aparecen ms de una vez en una agrupacin de datos por la tecnologa o implementacin. 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 estn para permitir mltiples ocurrencias. Por ejemplo nota ordinaria (Febrero) y nota extraordinaria (Junio)

Para contar los registros lgicos (tipo de registro) de una agrupacin de datos (fichero), se han de tener en cuenta las siguientes reglas:

26

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

Todo fichero tiene un conjunto de datos bsicos (no repetitivos) ms otros registros lgicos. Un registro lgico 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 sera obligatorio sus datos de acceso (Mayor-25, FP, COU y OtrasCarreras que contendrn datos diferentes, habr slo 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 lgico por cada subgrupo, opcional u obligatorio. Si no hay subgrupos contar un registro lgico.

Con esto se puede realizar la clasificacin de los elementos de funcin. A continuacin hay que calcular los puntos de funcin sin ajustar, para ello se puede utilizar la siguiente tabla, que adems deja documentado el clculo del los Puntos de Funcin sin Ajustar (PFSA).

27

PLANIFICACIN DE PROYECTOS INFORMATICOS

Tipo Elemento Entradas

Dificultad

Peso

Salidas

Consultas: Mximo Complejidad( Entrada, Salida ) Ficheros Internos

Ficheros de Interfaz

Simple 3 Media 4 Compleja 6 Total Puntos de Funcin Entradas Simple 4 Media 5 Compleja 7 Total Puntos de Funcin Salidas Simple 3 Media 4 Compleja 6 Total Puntos de Funcin Consultas Simple 7 Media 10 Compleja 15 Total Puntos de Funcin Ficheros Internos Simple 5 Media 7 Compleja 10 Total Puntos de Funcin Ficheros de Interfaz

Cantid ad E1 E2 E3

Total Puntos 3 * E1 4 * E2 6 * E3

Total Elemento

Peso * Ei S1 S2 S3 4 * S1 5 * S2 7 * S3 Peso * Si C1 C2 C3 3 * C1 4 * C2 6 * C3 Peso * Ci F1 F2 F3 7 * F1 10 * F2 15 * F3 Peso * Fi I1 I2 I3 5 * I1 7 * I2 10 * I3 Peso * Ii Peso*Xij

Total Puntos de Funcin Sin Ajustar (PFSA)

3.3. IDENTIFICACIN DE LOS FACTORES DE COMPLEJIDAD. Los Puntos de Funcin sin ajustar son una aproximacin de la complejidad del sistema, pero quedan caractersticas externas que no hemos contemplado, as como caractersticas del proceso de desarrollo del sistema informtico que influirn en el coste del sistema y que podemos cuantificar desde las primeras fases del desarrollo. Estos factores adicionales segn Albrecht son catorce. Cada factor tomar un valor entre 0 y 5, de modo que cuanta ms importancia tenga un factor mayor valor se le asignar. 28

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

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


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

Con estos valores calculados, los sumaremos y obtendremos el Factor de Complejidad Total. A continuacin describimos cada factor e indicamos cuando deberan tomar los valores extremos, a modo de gua. 1) COMUNICACIN DE DATOS. Los datos usados en el sistema se envan o reciben por lneas de comunicaciones. 0 Sistema aislado del exterior (slo usuarios directos. Ej.: PC; BATCH ). 1 Aplicacin batch con entrada de datos remota o (exclusiva) utilizacin de perifricos de salida remotos. 2 Aplicacin batch con entrada de datos remota y utilizacin de perifricos de salida remotos. 3 plicacin de captura de datos En_Lnea o hay un sistema de teleproceso que pasa los datos a la aplicacin batch o sistema de consulta. 4 Varios teleprocesos pero con el mismo protocolo de comunicaciones. 29

PLANIFICACIN DE PROYECTOS INFORMATICOS

5 Hay teleproceso con varios protocolos de comunicacin. 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 va software de otros equipos. Por ejemplo a la salida del sistema se accede va una hoja de clculo 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 lnea" en una sola direccin. 4 Proceso de datos distribuidos y transferencia de datos "en lnea" en ambas direcciones. Por ejemplo una red de cajeros automticos en donde stos procesan parte la transaccin. 5 El sistema esta ejecutndose en una red con procesos cooperantes ejecutndose en distintos equipos. 3) OBJETIVOS DE RENDIMIENTO. Si el rendimiento es un requisito del sistema. Es decir es crtico algn factor como tiempo de respuesta o cantidad de operaciones por hora. Se tendr que hacer consideraciones especiales durante el diseo, codificacin y mantenimiento.

30

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

0 Rendimiento normal (el que suelen dar los sistemas informticos en los que no se pone nfasis en este tema). 1 Se indican requerimientos de rendimiento y del diseo que son revisados, pero no es necesario tomar medidas especiales. 2 El tiempo de respuesta o cantidad de operaciones por hora es crtico en algunos momentos. No se solicita que realicemos un diseo de la utilizacin de la CPU. Los procesos debern estar terminados antes de la siguiente sesin de trabajo (prximo da) 3 El tiempo de respuesta o cantidad de operaciones por hora es crtico durante todas las horas de trabajo. No se solicita que realicemos un diseo de la utilizacin de la CPU. Los requerimientos indican que los procesos con sistemas de interfaz debern estar terminados segn ciertas restricciones. 4 Adems, los requerimientos indican que el tiempo de respuesta o la cantidad de operaciones por hora es lo suficientemente crtico, como para requerir tareas de anlisis de rendimiento durante la fase de diseo. 5 Adems se utilizan herramientas de anlisis de rendimiento durante el diseo, desarrollo e instalacin, con el objetivo de alcanzar el rendimiento demandado por el usuario. 4) CONFIGURACIN DE EXPLOTACIN 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 caracterstica fundamental, teniendo que tenerse en cuenta en las fase de diseo. 0 No se han indicado restricciones ni explcita ni implcitamente. 1 Existen restricciones, pero son las usuales de cualquier equipo departamental. No es necesario hacer consideraciones especiales. 31

PLANIFICACIN DE PROYECTOS INFORMATICOS

2 El usuario declara explcitamente caractersticas de seguridad o relativos a tiempos. 3 Algunos programas deben funcionar con restricciones en algn 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 Adems, hay restricciones especiales para la aplicacin en los componentes distribuidos del sistema. 5) TASA DE TRANSACCIONES. La tasa de transacciones ser elevada. Se tendr que hacer consideraciones especiales durante el diseo, codificacin e instalacin. 0 No se prevn perodos con picos de transacciones. 1 Se prevn picos de operaciones de forma regular, pero poco frecuente (mensualmente, trimestralmente o anualmente). Ejemplos seran la automatricula, los cierres de contabilidad, o el prstamo de libros antes de los exmenes. 2 Se prevn picos de operaciones semanales. 3 Se prevn horas punta, diarias. Ejemplo sera las ventas en los supermercados. 4 La tasa de transacciones se prev tan elevada que durante el diseo se debe incluir tareas de anlisis del rendimiento. 5 Se ha especificado una cantidad de transacciones muy elevada. Se utilizarn herramientas de anlisis de rendimiento durante el diseo, implementacin e instalacin. 32

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

6) ENTRADA DE DATOS EN-LNEA. La entrada de datos ser directa desde el usuario a la aplicacin, 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 disear e implementar la aplicacin con interfaces fciles de usar y con ayudas integradas. Los tipos de elementos asociados a la eficiencia del usuario son: Mens. Ayudas "en lnea". Movimiento automtico del cursor. Efectos de Scroll (papiro). Impresin remota (mediante transacciones en lnea) Teclas de funcin predefinidas Lanzamiento de procesos batch desde las transacciones "en lnea". Seleccin mediante cursor de datos de la pantalla. Pantallas con muchos colores y efectos. Documentacin impresa de las operaciones en lnea. Uso de ratn. Ventanas de "pop-up". Forzar la aplicacin a tener el menor nmero posible de pantallas por transaccin. 33

PLANIFICACIN DE PROYECTOS INFORMATICOS

Aplicacin bilinge (cuenta por cuatro). Aplicacin Multilinge (ms 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 ms factores, pero sin especiales requerimientos de eficiencia. 4 Ms de seis factores, con requerimientos lo suficientemente especficos como para justificar en el diseo 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 construccin de prototipos y utilizacin de herramientas para su evaluacin y comprobar que se alcanzarn los objetivos. 8) ACTUALIZACIONES EN-LNEA. Los ficheros maestros y las Bases de Datos son modificadas directamente de forma interactiva. 0 No hay actualizaciones interactivas. 1 Actualizacin en lnea de uno a tres ficheros con informacin de control. Ejemplo fichero con usuarios, horas en que se puede acceder, etc.. La cantidad de actualizaciones es baja y es fcil recuperar el fichero. 2 Igual al anterior, pero con cuatro o ms ficheros de control.

34

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

3 Actualizacin En-Lnea de ficheros lgicos internos importantes. Ejemplo: en un banco sera TRANSACCIONES, CLIENTES, CUENTAS, etc.. 4 Adems de lo anterior, es esencial la proteccin ante perdidas y el sistema se ha de disear e implementar con estas consideraciones. 5 Gran cantidad de actualizaciones interactivas, debindose considerar los costes de recuperacin. Adems deben tenerse sistemas de recuperacin, en caso de fallo, muy automatizados y con poca intervencin del operador. 9) LGICA DE PROCESO INTERNO COMPLEJA. La complejidad de los procesos es una caracterstica de la aplicacin. Alguno de las siguientes caractersticas estn presentes: a) Los algoritmos matemticos especificados complejos. b) Procesos con lgica compleja. c) Se han especificado muchas excepciones, transacciones incompletas, que debern tratarse. d) Manejar mltiples dispositivos de entrada/salida. e) La aplicacin llevar incorporados sistemas de seguridad y control. La complejidad algortmica realmente est mal resuelta en esta tcnica. Hay que tener en cuenta que se ha desarrollado pensando en sistemas de proceso empresarial. Para sistemas complejos algortmicamente hay tcnicas que miden la complejidad como las de McCabe. La valoracin ser la siguiente: 0 No se da ninguna de las caractersticas anteriores. 1 Se da una caracterstica de las enunciadas. 35 consecuencia de

PLANIFICACIN DE PROYECTOS INFORMATICOS

2 Se dan dos caractersticas de las enunciadas. 3 Se dan tres caractersticas de las enunciadas. 4 Se dan cuatro caractersticas de las enunciadas. 5 Se dan las cinco caractersticas de las enunciadas. 10) REUSABILIDAD DEL CDIGO. Se tendr que hacer consideraciones especiales durante el diseo, codificacin y mantenimiento para que el cdigo se reutilice en otras aplicaciones. 0 No se piensa en reutilizar el cdigo a generar. 1 Se pretende reutilizar el cdigo a generar dentro de la propia aplicacin. 2 Menos del 10% de la aplicacin tiene en cuenta las necesidades de ms de un usuario (sistema). 3 El 10% de la aplicacin o ms tiene en cuenta las necesidades de ms de un usuario (sistema). 4 La aplicacin ha sido especficamente empaquetada y/o documentada para ser fcil de reutilizar. La aplicacin se adaptar a las necesidades de los usuarios a nivel de cdigo. 5 La aplicacin ha sido especficamente empaquetada y/o documentada para ser fcil de reutilizar. La aplicacin se adaptar a las necesidades de los usuarios por medio de parmetros.

36

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

11) CONTEMPLA LA CONVERSIN E INSTALACIN. Se proveern facilidades de instalacin y conversin en el sistema. Se desea que la conversin del sistema antiguo sea fcil de realizar durante la puesta en marcha del sistema nuevo. 0 No reemplazamos un sistema existente o no se requiere conversin. Tampoco se enuncia nada sobre la instalacin. 1 Se solicita facilidad de instalacin. 2 Se ha solicitado procesos de conversin e instalacin, se han construido guas y han sido probadas, pero no son considerados importantes en el proyecto. 3 Se han solicitado procesos de conversin e instalacin, dndose guas explcitas, y estos procesos han de ser probados. En este proyecto se considera muy importante el proceso de conversin. 4 Adicionalmente a la valoracin de 2 se aade el que tendrn que desarrollarse herramientas de conversin e instalacin probadas. 5 Adicionalmente a la valoracin de 3 se aade el que tendrn que desarrollarse herramientas de conversin e instalacin probadas. El sistema es crtico para la empresa y ya estaba automatizado. Los usuarios no pueden permitirse el lujo de tener problemas o bajo rendimiento durante la transicin. Estas condiciones se han descrito como requisitos a cumplir por el sistema. 12) FACILIDAD DE OPERACIN. Entendemos por operacin del sistema los trabajos asignados al centro de proceso de datos para una aplicacin dada como: arranque, parada, recuperacin ante fallos, copias de seguridad. Aqu tendremos en cuenta la minimizacin de las actividades manuales en el CPD. As, sta caracterstica se valora cuando se ha descrito desde las primeras fases, habiendo de dedicarse especial atencin durante el diseo, codificacin y pruebas. 37

PLANIFICACIN DE PROYECTOS INFORMATICOS

Se pueden tener en cuenta las siguientes posibilidades de automatizacin: Se proveer de procesos de arranque, back-up y recuperacin pero con intervencin del operador. Se proveer de procesos de arranque, back-up y recuperacin pero sin intervencin del operador (vale por dos). En la aplicacin 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 automtico sin intervencin humana. 13) INSTALACIONES MLTIPLES El sistema ha de incluir los requerimientos de diversas empresas o departamentos en donde se ejecutar (incluso distintas plataformas). Estas caractersticas estarn presentes durante el diseo, codificacin y pruebas. 0 En slo un lugar. 1 Mltiples lugares pero con idntico Hardware y entorno Software. 2 En el diseo se ha de tener en cuenta que rodar en diferentes entornos, pero con Hardware y Software similares.

38

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

3 La aplicacin deber rodar en mltiples entornos de Hardware o Software y se tiene en cuenta desde la fase de diseo. 4 Se documentar y se planearn sistemas para dar soporte a la situaciones descritas en las valoraciones 1 o 2. 5 Se documentar y se planearn sistemas para dar soporte a la situacin descrita en la valoracin 3. 14) FACILIDAD DE CAMBIOS Se tendr que hacer consideraciones especiales durante el diseo, codificacin y mantenimiento para que en el sistema sea fcil de introducir cambios y fcil de adaptar al usuario. Esto contemplara: a) Consultas flexibles del usuario. Podemos tener Consultas: Simples con condiciones lgicas And/Or que implican un solo fichero lgico. Contar 1.

Medias con condiciones lgicas de complejidad media mediante And/Or que relacionan a ms de un fichero lgico. Contar 2. Complejas con condiciones lgicas muy complejas mediante combinaciones lgicas And/Or entre varios ficheros lgicos). Contar 3. b) Parmetros de la aplicacin va tablas ajenas al cdigo. El cambio de la configuracin se hace efectivo al arrancar el sistema al da siguiente. Contar 1. El cambio de la configuracin se hace interactivamente y tiene efecto inmediato. Contar 2. Toma el valor:: 39

PLANIFICACIN DE PROYECTOS INFORMATICOS

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 3. 4 Se dan algunos tems de los descritos anteriormente acumulando un valor de 4. 5 Se dan algunos tems de los descritos anteriormente acumulando un valor de 5.

40

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

CLCULO DEL FACTOR DE COMPLEJIDAD TOTAL. La siguiente tabla documenta el clculo del factor de complejidad total (FCT).
# 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Factor de Complejidad Comunicacin de Datos. Proceso Distribuido. Objetivos de Rendimiento Configuracin de Explotacin compartida Tasa de Transacciones Entrada de Datos EN-LNEA Eficiencia con el Usuario Final Actualizaciones EN-LNEA Lgica del Proceso Interno Compleja Reusabilidad del Cdigo Contempla la Conversin e Instalacin Facilidad de Operacin Instalaciones Mltiples Facilidad de Cambios Valori Valor (0..5)

Factor de Complejidad Total (FCT)

3.4. OBTENCIN DE LOS PUNTOS DE FUNCIN AJUSTADOS. Para obtener los puntos de funcin ajustados de una aplicacin se utiliza la siguiente frmula: PFA = PFSA * (0.65 + (0.01 * FCT))

41

PLANIFICACIN DE PROYECTOS INFORMATICOS

Esta frmula indica que en principio cada factor de complejidad puede actuar sobre los PFSA incrementando o decrementando en un 2,5% la 140 cantidad de puntos de funcin 120 ajustados. 100
80 60 40 20 0 0 35 70

De forma global producir una valoracin de los PFA de entre el 65% y el 135% del PFSA. Para calcular los puntos de funcin un proyecto nos podemos

de encontrar en tres situaciones:

La aplicacin a desarrollar parte de cero. No tenemos nada desarrollado que podamos utilizar, ni tenemos que convertir datos de una aplicacin previa. En este caso se aplica la frmula que mide el tamao de la aplicacin. La aplicacin a desarrollar parte de una aplicacin previa de la que slo se desea convertir los datos a la nueva aplicacin. Deberemos aadir a los puntos de funcin sin ajustar el tamao que incorporaran las utilidades de conversin (puntos de funcin de la conversin CONVER). As: PFC=(PFSA+CONVER)*(0,65+(0,01*FCT))

El clculo ms complejo se da cuando modificamos una aplicacin. La frmula a utilizar es:

PFM = [(AADIDO+CAMBIADO+CONVER) * (0,65+(0,01*FCD))] + (BORR*(0,65+(0,01*FCP))) Donde se introducen los PF aadidos, cambiados, borrados y de conversin, as como los factores de complejidad despus de la modificacin (FCD) y los factores de complejidad previos a la modificacin (FCP) 42

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

4. ESTIMACIN DEL ESFUERZO REQUERIDO POR LA APLICACIN.


El objetivo ahora es estimar la cantidad de esfuerzo necesario para desarrollar la aplicacin. Este esfuerzo se mide en horas/hombre, meses/hombre o aos/hombre. Los puntos de funcin 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. Adems en principio este nmero no dice nada, nos hace falta conocer la cantidad de meses/hombre que costar cada punto de funcin. La cantidad de horas/hombre por punto de funcin es algo difcil e impreciso de valorar, de forma global. Esto es normal, lo contrario sera 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 histrica, aqu si que tiene sentido el esperar que los puntos de funcin tengan cierta uniformidad, cuando se utilizan entornos similares. De forma general, para proyectos de tamao medio (300 PFA), se han publicado valores como los mostrados en la siguiente tabla: Entorno, Lenguaje Ensamblador COBOL Lenguajes 4GL Horas / Punto Funcin 20 a 30 10 a 20 5 a 10 Lneas Cdigo/P.Funcin 300 100 20

De todos modos esto no deja de ser una orientacin ya que como indica Thomsett algunas organizaciones usan valores como 40 horas por punto de funcin en COBOL.

43

PLANIFICACIN DE PROYECTOS INFORMATICOS

Dreger comenta que la productividad no slo vara entre programadores, sino que tambin con el tamao del proyecto. Indica que en algunos estudios se ha llegado a la conclusin de que un equipo medio, en un proyecto de 400 PFA, utiliza 20 horas por punto de funcin, mientras que en un proyecto de 2000 PFA, pasa a ser de 52 horas por punto de funcin. En cualquier caso nuestra empresa deber mantener una base de datos con la informacin de los proyectos realizados en sta. Se deber tener como mnimo los puntos de funcin 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 informacin deberamos mantener la informacin de base para calcular los puntos de funcin, factores de complejidad y aadir aquellos factores que pensemos que son relevantes en nuestra organizacin. Un ejemplo de esto puede ser el suponer que el apoyo de la alta direccin es un elemento clave, as pues lo valoraremos de 0 a 5 y mantendremos esta informacin para posibles interpretaciones futuras. Con todas las cautelas que hemos indicado, podemos calcular el esfuerzo requerido en nuestra organizacin para un proyecto como:

Esfuerzo = PFA * Promedio_Organizacin( Lenguaje )

Suponiendo que nuestra organizacin realiza proyectos de caractersticas similares. con tamaos de entre 200 y 500 puntos de funcin. Para una mayor precisin consultar la bibliografa. Con esto obtendremos una aproximacin a la cantidad bruta de horas, meses o aos hombre necesarios. Hay que tener en cuenta que normalmente, aunque se trabaja 8 horas diarias, slo 5 son productivas, que un mes tiene 20 das de trabajo efectivos, y que un ao tiene 11 meses de trabajo. Es decir aproximadamente un ao tiene 220 das de trabajo real. 44

2. ESTIMACIN DE ESFUERZO EN DESARROLLO DE SOFTWARE

5. OTRAS UTILIDADES DE LAS MEDICIONES MEDIANTE PUNTOS DE FUNCIN.


Dado que lo que realmente miden los puntos de funcin es la funcionalidad de una aplicacin informtica, tambin 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 tcnicas de desarrollo.

6. BIBLIOGRAFA 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. (Hemeroteca UPV). 2. Boehm, Barry. Software Engineering Economics. Reimpreso en Software Management (4 ed.), Donald J. Reifer, IEEE Computer Society Press 1993. (Biblioteca UPV). 3. Dreger, J.B. "Function Point Analysis", Prentice Hall, 1989. (Biblioteca UPV). 4. Gibson, Robin. Managing Computer Projects. Avoiding the Pitfalls. Prentice Hall, 1992. (Biblioteca UPV). 5. International Function Point Users Group: "Function Point as an Asset Reporting to Management", 1992. (Disponible para consulta restringida en el Dpto.). 6. International Function Point Users Group: "Function Point Counting Practices Manual: Case Studies (Case Study 2)", Release 1.0, 1994. (Disponible para consulta restringida en el Dpto.).

45

PLANIFICACIN DE PROYECTOS INFORMATICOS

7. International Function Point Users Group: "Function Point Counting Practices Manual", Release 4.0, 1994. (Disponible para consulta restringida en Dpto.). 8. Jones, Capers. Applied Software Measurement - Assuring Productivity and Quality". McGraw Hill, 1991. (Biblioteca UPV). 9. Jones, Capers. Assessment and Control of Software Risks. Yourdon Press, Prentice Hall, 1994. (Biblioteca UPV). 10. King, Davis. Project Management Made Simple. A guide to successful of computer Systems projects . Yourdon Press, Prentice Hall, 1992. (Biblioteca UPV). 11. Kemerer, C.F.. "Reliability of Function Point Measurement: A Field Experiment", Communications of the ACM, Feb. 1993. (Hemeroteca UPV). 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. (Hemeroteca). 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. (Hemeroteca UPV). 14. OConell, Fergus. How to Run Successful projects. BCS Series, Prentice Hall, 1994. (Biblioteca UPV). 15. Pressman, R. Ingeniera del Software, un enfoque aplicado. McGraw Hill 1993. (Biblioteca UPV) 16. Thomsett, Rob. Third Wave Project Management: a Handbook for Managing the Complex Information Systems of the 1990s. Yourdon Press, Prentice Hall, 1993. (Biblioteca UPV).

46

También podría gustarte