Técnicas de gestión de proyectos

Capítulo 7 Técnicas de gestión de proyectos En este capítulo se van a tratar algunas de las principales técnicas de gestión de proyectos correspondientes a los procesos de organización, estimación, planificación y seguimiento de proyectos. Las técnicas que se presentarán han sido escogidas teniendo en cuenta su madurez y difusión. Primero se tratarán las técnicas de estimación, a continuación las técnicas de organización, después las correspondientes al proceso de planificación y finalmente las técnicas de seguimiento de proyectos. 7.1. Técnicas de estimación La estimación es un proceso de gestión de una importancia estratégica para cualquier proyecto software y comprende la evaluación del esfuerzo, de la duración y de los recursos necesarios para llevarlo a cabo. Se realiza en las primeras fases del ciclo de vida. Esto implica una cierta incertidumbre y por este motivo es conveniente realizar también un análisis de los riesgos asociados a un posible error en dicha estimación. Los resultados del mismo se suelen dar en función de una probabilidad de cumplimiento del esfuerzo y del tiempo estimados inicialmente. Las continuas mejoras que la ingeniería del software ha introducido sobre distintos aspectos implicados en la proaucción de productos software, tales como el establecimiento de medidas de madurez para los procesos, las metodologías de desarrollo o los modelos de ciclo de vida, han permitido sentar las bases sobre las que se han podido desarrollar muchos tipos diferentes de técnicas de estimación que permiten predecir,

278 Gestión del proceso software cada vez con más exactitud, el costo, el calendario y la calidad de los productos software a desarrollar. Una posible clasificación de dichos métodos nos permite distinguir los cuatro grupos que se describen a continuación. Modelos matemáticos paramétricos Los modelos paramétricos relacionan un conjunto de variables dependientes (por ejemplo, esfuerzo y10 calendario) con una o más variables independientes denominadas factores de costo (por ejemplo el uso de herramientas CASE o la capacidad de los analistas) de tal forma que se realizan las estimaciones a través de unas expresiones matemáticas ajustadas mediante un conjunto de parámetros. Las diferencias fundamentales entre los distintos modelos paramétricos están en el tipo de formulación matemática que se utiliza en las relaciones entre las variables dependientes e independientes elegidas. Los primeros modelos paramétricos de estimación de esfuerzo fueron propuestos por primera vez en los años 50 y 60. Se trataba de modelos lineales cuyos parámetros se fijaban a partir de juicios de expertos y de la aplicación del análisis de regresión multivariante a las variables. En estos primeros años se definieron multitud de variables diferentes que se consideraba que afectaban al esfuerzo de desarrollo del software. Así por ejemplo, Nelson definió 104 variables distintas y usando una base de datos de 169 proyectos, probó diferentes combinaciones de las mismas, obteniendo al final un conjunto de 14 factores de costo, los más significativos. A mediados de los años 70, surgen los primeros modelos paramétricos basados en ecuaciones matemáticas no lineales, los cuales sirvieron como punto de partida para la construcción de modelos más robustos. Aunque el método de calibrado de las ecuaciones es normalmente el mismo que para los modelos lineales, el juicio de expertos y el análisis de regresión multivariante, en este caso se utiliza un análisis logarítmico. El continuo incremento de los cambios tecnológicos presenta nuevos desafíos para las técnicas de estimación de proyectos informáticos. Ejemplos de estos fenómenos incluyen aspectos relacionados con el ciclo de vida, tecnologías basadas en web, multimedia en todas sus formas, técnicas para el desarrollo rápido de aplicaciones, reutilización, organizaciones virtuales, desarrollo de líneas de productos, aproximaciones orientadas a objetos y basadas en componentes, desarrollo distribuido y los aspectos relacionados con el incremento de la documentación a lo largo del ciclo de

Técnicas de gestión de proyectos 279 vida del software. Esta evolución tecnológica lleva pareja, no sin algunas dificultades de adaptación, la evolución de los modelos paramétricos no lineales de estimación de esfuerzo, que no sólo han perfeccionado sus ecuaciones o sus métodos de calibrado, sino que han ido introduciendo, eliminando o cambiando el peso de los factores de costo utilizados, con el objetivo de adaptarse a los nuevos productos, procesos y organizaciones. De la definición de variables adecuadas y de su correcta ponderación o parametrización depende en gran medida la exactitud de las predicciones realizadas por el modelo. La estimación basada en modelos paramétricos es una de las más extendidas y utilizadas. Más adelante se verá con detalle uno de los principales modelos paramétricos de estimación, COCOMO 11. Estimación basada en la experiencia de expertos Los modelos clasificados dentro de este grupo son aquellos que proporcionan una manera de extraer, de la forma más objetiva posible, los conocimientos de expertos para realizar las estimaciones. Normalmente, lo hacen a través de un conjunto de pasos o mediante la utilización de cuestionarios. Técnicas orientadas al aprendizaje Este método se basa en el empleo de datos recogidos en proyectos anteriores para realizar las estimaciones y en este sentido es análogo a los modelos matemáticos paramétricos, los cuales utilizan también los datos de proyectos anteriores para determinar sus parámetros. Pero la diferencia que presentan los modelos clasificados en este grupo, aparte de no estar fundamentados en ecuaciones matemáticas, es que no pretenden ser de aplicación universal sino que su objetivo es realizar estimaciones precisas para aquellos proyectos del mismo tipo de los que se han empleado para aprender. Modelos dinámicos Estos modelos asumen que los factores de costes de un proyecto software cambian a lo largo del tiempo y realizan estimaciones y simulaciones de dichas variaciones. Por lo tanto, el fundamento de este grupo es muy diferente al de los otros tres, los cuales tienen una visión estática del sistema.

280 Gestión del proceso software 7.1.1. Estimación de esfuerzo. COCOMO 11 La estimación de esfuerzo se realiza y refina en distintos momentos del ciclo de vida del software: Primer momento, cuando se analiza la oferta se procede a una primera estimación que se interpreta como un presupuesto inicial. Para realizar esta estimación se recomienda utilizar métodos paramétricos, debido a la gran incertidumbre que conlleva. Segundo momento, al principio de la fase de especificación de requisitos, preferentemente con métodos paramétricos, que constituye la versión inicial del presupuesto del proyecto, considerando tanto la información aportada por el cliente como las técnicas elegidas para realizar el producto en la oferta inicial. Tercer momento, al concluir la fase de especificación de requisitos. Se afina el presupuesto previo con la ayuda de las precisiones aportadas por el contenido funcional y operativo del producto junto con la naturaleza organizativa del proyecto. Esta nueva estimación, preferentemente determinista, constituye la versión final del presupuesto del desarrollo. Cuarto momento, al concluir la fase de diseño de la arquitectura, y tras haber definido la arquitectura. Puede abordarse la estimación sobre un modelo preciso del proyecto mediante una red PERT. En cualquier caso se recomienda volver a realizar una nueva estimación comparativa mediante modelos paramétricos (por ejemplo, COCOMO 11 Post arquitectura), con el conocimiento de datos de entrada más precisos. A continuación se presenta uno de los principales modelos públicos de estimación de esfuerzo, COCOMO 11. El nombre COCOMO procede de COnstructive COst MOdel, la denominación 11 indica que es la segunda versión que se publica del modelo. La versión anterior fue COCOMO 81 y aunque ambas están unidas por la denominación COCOMO presentan diferencias fundamentales. Se trata de un modelo paramétrico no lineal publicado por primera vez por Boehm en 1995. El modelo COCOMO 11 está compuesto por los tres submodelos que se detallan a continuación.

Técnicas de gestión de proyectos 2Ul Composición de aplicaciones Este submodelo es utilizado para estimar el esfuerzo y el tiempo de desarrollo en proyectos que utilizan herramientas CASE (Computer Aided Software Engineering - Ingeniería del Software Asistida por Ordenador) para el desarrollo rápido de aplicaciones. Estos productos aunque son muy diversos, son lo suficientemente simples como para ser rápidamente construidos a partir de componentes interoperables. Componentes típicos son los constructores del GUI (Graphical User Interface - Interfaz Gráfico de Usuario), gestores de bases de datos o de objetos, o procesos de transacción, etc. así como componentes de dominios específicos como paquetes de control médico o industrial. Este modelo utiliza como variable de medida del tamaño del producto los Puntos Objeto. Los puntos objeto son básicamente una cuenta de las pantallas, los informes y los módulos, desarrollados en un lenguaje de tercera generación, para la aplicación. Cada cuenta es ponderada mediante un factor de complejidad de 3 niveles: Simple, Medio y Complejo. Solo existe una calibración de este modelo debido a la falta de datos. Diseño inicial En este submodelo se tienen en cuenta la exploración de diferentes arquitecturas del sistema y conceptos de operación. Normalmente no es suficiente para hacer estimaciones de precisión y además es un submodelo que todavía está en fase de ajuste y verificación. Utiliza como tamaño del producto los Puntos Función o las Líneas de Código, cuando están disponibles. Introduce un conjunto de 5 factores de escala. A cada uno de los cuales se les asigna un valor o número real correspondiente al rango en el que se sitúe el factor para el proyecto que se está desarrollando. Hay seis rangos: Muy Bajo, Bajo, Nominal, Alto, Muy Alto y Extra Alto. Los factores de escala son los siguientes: Precedentes (PREC) : Tiene en cuenta la experiencia de la organización en el desarrollo de ese tipo de aplicaciones. Flexibilidad en el desarrollo (FLEX): Tiene en cuenta la rigidez de los requisitos y de las restricciones. Arquitectura / Solución de riesgos (RESL): Tiene en cuenta las medidas tomadas para la eliminación de riesgos.

282 Gestión del proceso software Cohesión del equipo (TEAM): Refleja las dificultades de cohesión y sincronización de los implicados en el proyecto (usuarios, clientes, desarrolladores, equipo de mantenimiento, etc.), debido a su diversa procedencia y objetivos. Madurez de procesos (PMAT): Este factor tiene en cuenta el nivel de madurez de procesos de la organización, para lo cual utiliza la escala de cinco niveles del CMM (Capability Maturity Model) desarrollado por el SE1 (Software Engineering Institute) de la Universidad Carnegie Mellon. Además este submodelo utiliza 7 multiplicadores de esfuerzo a los que se les asigna un número real teniendo en cuenta el rango, de seis niveles (Muy Bajo, Bajo, Nominal, Alto, Muy Alto y Extra Alto), en que se encuentre el multiplicador para el proyecto estudiado. Los multiplicadores de esfuerzo son: 1. Capacidad del personal (PERS). 2. Fiabilidad y complejidad del producto (RELY). 3. Reutilización requerida (RUSE). 4. Dificultad de la plataforma (PDIF). 5. Experiencia del personal (PREX). 6. Facilidades (FCIL). 7. Calendario (SCED). Post - arquitectura. Este submodelo puede ser utilizado cuando se ha completado el diseño de alto nivel y se dispone de información detallada sobre el modelo y, como su nombre sugiere, la arquitectura del software está bien definida y establecida. Permite realizar estimaciones para el conjunto del ciclo de vida de desarrollo y es una extensión del modelo de Diseño Inicial. Este modelo es parecido en estructura y formulación al modelo intermedio de COCOMO 81. Utiliza Puntos Función y/o Líneas de Código Fuente (LCF) como entrada para el parámetro del tamaño del producto. Utiliza un conjunto de cinco factores de escala, iguales en su fundamento conceptual a los vistos anteriormente para el submodelo de diseño inicial, y diecisiete multiplicadores de esfuerzo, cada uno con un rango de seis niveles igual al visto para el submodelo de diseño inicial. Este submodelo ha sido calibrado sobre una base de datos de 161 proyectos recopilados de la industria comercial, aeroespacial, gubernamental y de organizaciones sin ánimo de

Técnicas de gestión de proyectos 28s lucro; utilizando una aproximación bayesiana. Los multiplicadores de esfuerzo se agrupan en las siguientes cuatro categorías: Producto 1 Fiabilidad requerida del software (RELY). 2 Tamaño de la base de datos en Bytes/LCF (DATA). 3 Complejidad del producto (CPLX). 4 Reutilización requerida (RUSE). 5 Documentación desarrollada (DOCU). Plataforma 6 Restricciones en el tiempo de ejecución (TIME). 7 Restricciones en el almacén principal (STOR). 8 Volatilidad de la plataforma (PVOL). Personal 9 Aptitud de los analistas (ACAP). 10 11 12 13 14 15 16 17 Aptitud de los programadores (PCAP). Experiencia desarrollando aplicaciones similares (AEXP). Experiencia con la plataforma de desarrollo (PEXP). Experiencia con el lenguaje y la herramienta (LEXP). Continuidad del personal (PCON). Proyecto Utilización de herramientas software (TOOL). Desarrollo en múltiples localizaciones (SITE). Tiempo necesario para el desarrollo (SCED). Las ecuaciones básicas que utiliza para realizar las estimaciones son: Donde e es representa el esfuerzo medido en MM (Man-Month o bien: hombres-mes), s el tamaño en KLCF (miles de líneas de código fuente), a = 2.94, b = 0.91 y c = 0.01 son constantes, xj es el valor del multiplicador de esfuerzo j, n vale 7 en el submodelo diseño inicial y 17 en post-arquitectura e yi es el factor de escala i.

284 Gestión del proceso soítware Tabla 7.1 Criterios para los factores de escala Tabla 7.2 Post-arquitectura. Criterios para los muitiplicadores de esfuerzo

Técnicas de gestión de proyectos 2US Tabla 7.3 Valores de los factores de escala según criterio I I Tabla 7.4 Post-arquitectura. Valores de los multiplicadores de esfuerzo por criterios. Calibrados en 1988.

286 Gestión del proceso software Y para el tiempo de desarrollo se aplica la formula: 0.33+0.2(b-1.01) ScELY% 1 t = 3(e) lo0 Donde t representa el tiempo en meses, e es representa el esfuerzo medido en MM, b es la misma constante b = 0.91 y SCED es el 17' multiplicador de esfuerzo que determina las restricciones impuestas en la duración del proyecto como un tanto por ciento ( % ) del total obtenido. Se han publicado un gran número de herramientas que implementan este modelo, entre ellas algunas de las más utilizadas son: 1. COCOMO 11. 1999.0. Desarrollada por el equipo de la Universidad del Sur de California que ha desarrollado el modelo teórico. La documentación está disponible en: ftp://ftp.usc.edu/pub/soft enrsineerinn/cocomoii/.. - -../cocomo99.0/c990windows.exe 2. COSTAR. Desarrollada por Costar. Es una herramienta interactiva que permite a realizar seguimientos de proyectos, así como realizar experimentos del tipo qué sucedería sí?. La documentación está disponible en: http: //www.softstarsystems.com http://sunset.usc.edu/cocomoii Desde la Tabla 7.1 a Tabla 7.4 se muestran los criterios y los valores necesarios para utilizar COCOMO 11 (las celdas vacías corresponden a aquellos valores para los que el modelo no presenta ningún valor numérico). Las columnas Rango en la Tabla 7.3 y en la Tabla 7.4 indican la aportación máxima posible de cada factor al esfuerzo total. Para finalizar este apartado se verá un ejemplo de aplicación de este modelo. Ejemplo de aplicación Una organización de desarrollo de software va a producir una aplicación de gestión de 20 KLCF. Dicha organización sólo desarrolla sistemas de ese tipo, de los cuales ha producido ya muchos productos que están funcionando. Se debe tener en cuenta que el producto debe satisfacer unos requisitos fijos, así como unas interfaces externas que también están previamente fijadas.

Técnicas de gestión de proyectos 287 La organización tiene un alto nivel de madurez en sus procesos de desarrollo, pero para desarrollar este producto ha reunido un equipo que mezcla personas que llevan tiempo trabajando juntas con otras recién llegadas, lo que da una cohesión del equipo básica. En cuanto al tratamiento en la solución de riesgos, la cultura de la empresa es procurar la máxima calidad y realizar una revisión completa Entre los requisitos para el sistema anterior, se sabe que deben extremarse los controles de calidad, ya que un fallo de funcionamiento, acarrearía grandes pérdidas económicas. También se sabe que la documentación deberá ser exhaustiva porque será utilizada más adelante para proyectos similares. En todos los aspectos, la filosofía de construcción está basada en la reutilización y está implantada en todas las líneas de producto de la empresa. Se sabe también que las personas recién llegadas al equipo, son programadores con baja experiencia de trabajo y baja experiencia en el lenguaje y en la herramienta, mientras que los miembros más veteranos son analistas con muy alta capacidad y muy alta experiencia en el lenguaje, así como con la herramienta. El proyecto se va a desarrollar simultáneamente en varias ciudades de distintos países, pero los miembros del mismo van a estar conectados permanentemente por un sistema multimedia interactivo que aplicará la más alta tecnología Calcular el esfuerzo requerido para desarrollar el sistema con un modelo de nivel Post-Arquitectura. Solución del ejemplo La selección de los valores para los factores de escala se realiza aplicando los criterios al enunciado del ejemplo: Precedentes: dicha organización sólo desarrolla sistemas de ese tipo, de los cuales ha producido ya muchos productos que están funcionando. Por lo tanto se debe seleccionar el valor Muy Alto. Flexibilidad de desarrollo: se debe tener en cuenta que el producto debe satisfacer unos requisitos fijos, así como unas interfaces externas que también están previamente fijadas. Por lo tanto se debe seleccionar el valor Muy Bajo. Arquitectura l Solución de riesgo: en cuanto al tratamiento en la solución de riesgos, la cultura de la empresa es de procurar la máxima calidad y

2ü8 Gestión del proceso software realizar una revisión completa. Por lo tanto, se debe seleccionar el valor Muy Alto. Cohesión del equipo l interacción: la organización tiene un alto nivel de madurez en sus procesos de desarrollo, pero para desarrollar este producto ha reunido un equipo que mezcla personas que llevan tiempo trabajando juntas con otras recién llegadas, lo que da una cohesión del equipo básica. Por lo tanto, se debe seleccionar el valor Nominal. Madurez de proceso: la organización tiene un alto nivel de madurez en sus procesos de desarrollo. Por lo tanto, se debe seleccionar el valor Muy Alto. La Tabla 7.5 muestra los criterios de aplicación de los factores de escala que se han obtenido. Tabla 7.5 Criterios para los factores de escala del ejemplo Aplicando estos criterios se obtienen los valores numéricos que se muestran en la Tabla 7.6: I Tabla 7.6 Valores de los factores de escala para el ejemplo La Tabla 7.7 resume los criterios de selección de los multiplicadores de esfuerzo para este proyecto. Para aquellos criterios para los que no se tiene descripción se ha seleccionado el valor nominal: RELY: entre los requisitos para el sistema anterior, se sabe que deben extremarse los controles de calidad, ya que un fallo de funcionamiento, acarrearía grandes pérdidas económicas. Por lo tanto, se debe seleccionar el valor Alto. I

~ Técnicas de gestión de proyectos 2üS I Criterios de Aplicación CC(xi)/Unidades 1 Muy Bajo 1 Bajo 1 Nominal 1 Alto 1 Muy Alto 1 Extra Alto RELY Efecto de un Altos costes fallo económicos DATA Bytes/LCF 101DíP<iOO CLPX RUSE DOCU TIME STOR PVOL Disponibilidad Disponibilidad Días Producto Plataforma 150% 150% M 180-ml5 Documentos m"y exhaustivos Líneas de producto I I TOOL SiTE SiTE Utilización Situación Comunicaciones internacional General Multimedia interactiva SCED Disponibilidad 100%

290 Gestión del proceso software FactoresdeCoste(CC)(xi) Rango 1 "z 1 Bajo 1 Nominal 1 Alto 1 1 Extra Alta Producto TIME STOR pvol Restricción en el tiempo de ejecución Restricción en el tamaño de la memoria inestabilidad de la plataforma Personal I 1.o0 1.o0 1.o0 ~ool sm SCED Proyecto Uso de herramientas software Desarrollo en varias localizaciones Restricciones en la duración del proyecto 1.o0 1.o0 0.90 Tabla 7.8 Ejemplo Valores para multiplicadores de esfuerzo ACAP y PCAP: no se dispone de información respecto a la aptitud del conjunto de analistas y programadores. Se considera el Nominal con una buena aptitud en el percentil55% del personal. AEXP: mientras que los miembros más veteranos son analistas con muy alta capacidad. Por lo tanto, se debe seleccionar el valor Muy Alto. PEXP: se sabe también que las personas recién llegadas al equipo, son programadores con baja experiencia de trabajo. Por lo tanto, se debe seleccionar el valor Muy Bajo.

Técnicas de gestión de proyectos 29í PCON: que mezcla personas que llevan tiempo trabajando juntas con otras recién llegadas, lo que da una cohesión del equipo básica. Por lo tanto, se debe seleccionar el valor Muy Bajo. TOOL: que mezcla personas que llevan tiempo trabajando juntas con otras recién llegadas, lo que da una cohesión del equipo básica. Por lo tanto, se debe seleccionar el valor Muy Bajo. SITE: el proyecto se va a desarrollar simultáneamente en varias ciudades de distintos países, pero los miembros del mismo van a estar conectados permanentemente por un sistema multimedia interactivo que aplicará la más alta tecnologia. Por lo tanto, se debe seleccionar el valor Muy Bajo en cuanto a situación y Extra Alto en cuanto a comunicaciones, por tanto, nos quedamos como valor global el Nominal. Con lo cual los valores numéricos para dichos criterios se muestran en la Tabla 7.8. Introduciendo el número de líneas de código y los valores numéricos de los factores de escala y de los factores de costes seleccionados en la ecuación (no se consideran los nominales), se obtiene un valor para el esfuerzo de: Exponente = O. 91 +O. 01( I.24+5.07+ 1.41 +3.29+ 1.56) = 1.036 Esfuerzo = e = 2.94. ( 20 )'~036((1.I0)(1.24)(1.23)(0.81)(1.19)(1.22)(0.90)= = 116.19MM Este esfuerzo se expresa en MM (man - month), hombres - mes. 7.1.2. Estimación de f uncionalidad. IFPUG 4.1 El análisis de puntos función mide el software cuantificando la funcionalidad que proporciona al usuario, basándose principalmente en el diseño lógico. Hoy en día la estimación de funcionalidad de una aplicación ha alcanzado una enorme relevancia porque permite estimar el tamaño del software que se va a desarrollar desde las primeras fases de su ciclo de vida. Se utiliza como una de las principales variables de entrada de los modelos paramétricos de estimación. Teniendo esto en cuenta, los objetivos del análisis de puntos función son: Medir la funcionalidad que el usuario pide y recibe. Medir el desarrollo y el mantenimiento del software, independientemente de la tecnología utilizada para su implementación. Además de responder a los objetivos mencionados, el proceso de medición de puntos función debería ser:

292 Gestión del proceso software como: 0 Suficientemente sencillo como para minimizar el esfuerzo adicional que supone el proceso de medida. Una medida consistente entre los diferentes proyectos y organizaciones. Las organizaciones pueden aplicar el análisis de puntos función Una herramienta para determinar el tamaño de un paquete aplicativo comprado, midiendo las funciones que incluye. Una herramienta para ayudar a los usuarios a determinar el beneficio para su organización de un paquete aplicativo, midiendo las funciones que coinciden exactamente con los requisitos. Una herramienta para medir las unidades de un producto software como soporte al análisis de calidad y productividad. Un vehículo para estimar el coste y los recursos requeridos para el desarrollo y el mantenimiento del software. Un factor de normalización para la comparación de software. Existen diferentes estándares de medición de puntos función. Uno de los más utilizados, y que se verá en detalle a continuación, es el de Albretch, actualmente gestionado por el International Function Points Users Group (IFPUG). 7.1.2.1. IFPUG 4.1 A continuación se detalla el procedimiento de medición de puntos de función según el método de la International Function Points Users Group (IFPUG) en su versión 4.1 de 1999. Este método, actualmente gestionado por dicha organización, procede de la evolución del primer método de puntos función, publicado por Alan Albrech en 1979 y sigue los siguientes pasos. Determinar el tipo de medición de puntos función El primer paso en el procedimiento de medición es determinar el tipo de medición de puntos función. Las mediciones de puntos función pueden estar asociadas tanto a proyectos como a aplicaciones. Existen tres tipos de medición de puntos función: Medición de puntos función de un proyecto de desarrollo.

Técnicas de gestión de proyectos 29s 0 0 Medición de puntos función de un proyecto de mejora. Medición de puntos función de una aplicación. Identificar el alcance de la medición y los límites de la aplicación El alcance de la medición define la funcionalidad que será incluida en una medición de puntos función concreta. Los límites de la aplicación indican la frontera entre el software a medir y el usuario. Determinar la medida de puntos función no ajustados La medida de puntos función no ajustados (UFPC) refleja la funcionalidad específica cuantificable proporcionada al usuario por el proyecto o aplicación. La funcionalidad específica de usuario de la aplicación es evaluada en términos de qué es lo que se entrega con la aplicación, no de cómo se entrega. Se cuentan solamente los componentes solicitados y definidos por el usuario. La medida de puntos función no ajustados tiene dos tipos de función: de datos y transaccional. A) Medir las funciones de datos. Las funciones de datos representan la funcionalidad proporcionada al usuario para satisfacer los requisitos con los datos internos y externos. Las funciones de datos son ficheros lógicos internos o ficheros de interfaz externos. Un fichero lógico interno (ILF) es un grupo de datos relacionados lógicamente o información de control, identificable por el usuario, mantenido dentro de los límites de la aplicación. El propósito principal de un ILF es almacenar datos mantenidos a través de uno o más procesos elementales de la aplicación que se está midiendo. Un fichero de interfaz externo (EIF) es un grupo de datos relacionados lógicamente o información de control, identificable por el usuario, referenciado por la aplicación, pero mantenido dentro de los límites de otra aplicación. El propósito principal de un EIF es almacenar datos referenciados mediante uno o más procesos elementales fuera de los límites de la aplicación que se está midiendo. Esto significa que un EIF medido para una aplicación debe ser un ILF en otra aplicación.

294 Gestión del proceso software B) Medir las funciones de transacciones. Las funciones transaccionales representan la funcionalidad proporcionada al usuario para procesar datos. Las funciones transaccionales son entradas externas, salidas externas o consultas externas. Una entrada externa (EI) es un proceso elemental que procesa datos o información de control que vienen fuera de los límites de la aplicación. El propósito principal de una E1 es mantener uno o más ILFs y/o modificar el comportamiento del sistema. Una salida externa (EO) es un proceso elemental que envía datos o información de control fuera de los límites de la aplicación. El propósito principal de una salida externa es presentar información al usuario mediante una lógica del proceso distinta a la recuperación de datos o información de control, o juntamente con esa recuperación. La lógica del proceso debe contener, al menos, una fórmula matemática o cálculo, o crear datos derivados. Una salida externa puede también mantener uno o más ILFs y/o modificar el comportamiento del sistema. Una consulta externa (EQ) es un proceso elemental que envía datos o información de control fuera de los límites de la aplicación. El propósito principal de una consulta externa es presentar información al usuario mediante la recuperación de datos o información de control. La lógica del proceso no contiene fórmulas matemáticas, ni cálculos y no crea datos derivados. No mantiene ningún ILF durante el proceso, ni se modifica el comportamiento del sistema. C) Medir los DET, los RET y los FTR. Otros tres conceptos que van a ser fundamentales para la cuenta de los puntos de función de una aplicación son los DET, los RET y los FTR, se definen como: 0 DET: tipo de dato elemental. Es un campo único, no repetido y reconocible por el usuario Se aplican por igual a las funciones de datos y a las funciones de transacciones 0 RET: tipo de registro elemental. Es un subgrupo de datos elementales reconocible por el usuario dentro de un ILF o un EIF 0 FTR: tipo de fichero referenciado. Es un fichero lógico interno leído o mantenido por un función transaccional o un fichero de interfaz leído por un función transaccional. Utilizando estos conceptos y las tablas desde la Tabla 7.9 a la Tabla 7.12, se pueden calcular los puntos función no ajustados.

Técnicas de gestión de proyectos 2- Tabla 7.9 Tipos de complejidad ILF, EIF BAJA BAJA MEDIA BAJA MEDIA ALTA MEDIA ALTA ALTA Tabla 7.10 Tipos de complejidad El Tabla 7.11 Tipos de complejidad EO, EQ Determinar el factor de ajuste Tabla 7.12 Puntos función no ajustados El factor de ajuste (VAF) indica la funcionalidad general suministrada al usuario de la aplicación. El VAF está compuesto por 14 características generales del sistema que valoran la funcionalidad general de la aplicación. Cada característica tiene asociada descripciones que ayudan a determinar su grado de influencia. El rango de los grados de influencia está en una escala de O a 5, desde influencia nula a influencia fuerte. Estas características son: 1. Comunicación de datos. 2. Funciones distribuidas. 3. Rendimiento. 4. Configuraciones fuertemente utilizadas. 5. Frecuencia de transacciones. 6. Entrada on-line de datos. 7. Diseño para la eficiencia del usuario final.

296 Gestión del proceso software 8. Actualización on-line. 9. Procesos complejos. 10. Utilización en otros sistemas. 11. Facilidad de instalación. 12. Facilidad de operación. 13. Instalación en múltiples sitios. 14. Facilidad de cambio. Una vez calculado el grado de influencia, TDI (del inglés Total Degree of Influence), de las características, se puede llegar al valor del factor de ajuste mediante la fórmula: AF = (TDI x 0,Ol) + 0,65 El método de conteo de puntos función de IFPUG está patentado, por lo que si el lector está interesado en profundizar en su conocimiento puede consultar el manual oficial. Se puede adquirir en el sitio de Internet de IFPUG: http: / /www.ifpua.org Se ha publicado una traducción al español que ha sido realizada por la Asociación Española de Métricas del Software (AEMES) y se puede adquirir en el sitio de Internet de la asociación: http://www.aemes.org Calcular la medida de puntos función ajustados La medida de puntos función ajustados se calcula utilizando una fórmula específica para la medida de puntos función, un proyecto de mejora o la medida de puntos función de una aplicación (línea base del sistema). El valor final de Puntos de Función ajustados será: FPA = FP X AF A continuación veremos un ejemplo de aplicación de este modelo. Ejemplo de aplicación Una compañía de mensajería urgente quiere desarrollar un software para la gestión de sus productos. El sistema mantendrá cuatro bases de datos: Base de datos de clientes de complejidad alta.

Técnicas de gestión de proyectos 297 Comunicación de datos Funciones distribuidas Rendimiento Configuraciones fuertemente u tilizadas Frecuencia de transacciones Entrada on-line de datos Diseño para eficiencia de usuario final Actualizaciones on-line Procesos complejos Utilización en otros sistemas Facilidad de instalación Facilidad de operación Instalación en múltiples sitios Facilidad de cambio 3 O 3 O 1 5 2 1 2 O O 3 O 2

298 Gestión del proceso software Solución del ejemplo Del planteamiento del ejemplo se deduce que los datos respecto a la complejidad de las bases de datos y las transacciones ya han sido elaborados, utilizando los datos del diseño y las Tabla 7.9, Tabla 7.10 y Tabla 7.11. Por tanto, utilizando la Tabla 7.12 y las características del sistema ya resumidas en el enunciado, se tiene: ILF = 2 * 15 (se mantendrán las bases de datos de clientes y estado de paquetes mediante seis transacciones, las cuales permitirán las altas, bajas y modificaciones, siendo todas ellas de complejidad alta) + 1 * 1 O (base de datos para Auditoría de complejidad media) + 1 * 7(ficheros de seguridad de complejidad baja) = ILF= 47 EIF = O (no hay) E1 = 6* 6 (se mantendrán las bases de datos de clientes y estado de paquetes mediante seis transacciones las cuales permitirán las altas, bajas y modificaciones, siendo todas ellas de complejidad alta) = EI= 36 E0 = 3*5 (este sistema pasará tres tipos de ficheros de datos a otras aplicaciones y serán de complejidad media) + 5*7 (Se elaborarán cinco informes distintos de complejidad alta) = EO= 50 EQ = 5*4 (Cinco transacciones de consulta de complejidad media) + 1*3 (Una consulta de ayuda a plena pantalla de complejidad baja) = EQ= 23 Total Puntos de Función Sin Ajustar = 47 + 36 + 50 + 23 = 156 TDI = Suma de los factores de complejidad de la Tabla 7.13 TDI = 22 Factor de Ajuste = 22 * 0,Ol + 0,65 = 037 Puntos Función Ajustados = 156 * 0,87 = 135,72

Técnicas de gestión de proyectos 299 7.2. Organización del Proyecto La organización o estructuración de un proyecto se puede ver como el paso previo a la planificación del mismo, en la cual partiendo de la definición de los objetivos del proyecto, se llega a la estructuración de las diferentes actividades que lo componen. La primera pregunta que puede surgir en este apartado es, por qué razón se tiene que organizar un proyecto software?. Si se piensa en algo que no esté relacionado con el desarrollo software, aspectos cotidianos como pueden ser las actividades semanales, las próximas vacaciones, etc., también éstas requieren un proceso de organización que se realiza automáticamente porque resulta más sencillo organizar las actividades cotidianas que las de un proyecto software. Sin embargo, el proceso es el mismo, mentalmente se hacen grupos de actividades relacionadas entre sí por determinados criterios, como pueden ser la similitud entre ellas, el objetivo al que están enfocadas, etc., y así es más sencillo delimitar el trabajo de forma que no se olvide ninguna tarea y se obtenga como resultado: 0 0 0 Las tareas a llevar a cabo, que permitirán delimitar exactamente el alcance del proyecto. Los productos resultantes de realizar cada una de las tareas, de modo que se pueda valorar más fácilmente la magnitud de cada una de ellas. Los recursos disponibles, que posteriormente serán asignados a cada una de las tareas identificadas. Lo anterior lleva a concluir que existen una serie de factores que pueden alterar el buen desarrollo del proyecto. Por lo tanto, habrá que determinar: 0 0 Las tareas a realizar a lo largo de todo el desarrollo. Los productos a entregar a lo largo del desarrollo. Los recursos disponibles con sus costes asociados. En un primer momento se podría pensar que todo lo anterior no es necesario controlarlo, y que ya se verá sobre la marcha. Esta visión es incorrecta ya que la falta de organización o estructuración de los anteriores elementos no permitirá tener una visión realista del proyecto a desarrollar,

SO0 Gestión del proceso software y por este motivo algo que en un primer momento parezca viable puede convertirse en un auténtico caos. Resumiendo, la estructuración de un proyecto requiere de una disciplina mental que permita descomponer el proyecto desde múltiples puntos de vista, bien orientado a las tareas, a los productos o a los recursos. A continuación se presentan algunas técnicas que permitirán plasmar de una forma gráfica el proceso mental que lleva a la estructuración de un proyecto en tareas, productos y recursos. 7.2.1. Descomposición en actividades (WBS) Un WBS o Work Breakdown Structure, es una representación gráfica de las diferentes actividades que se han de llevar a cabo para la realización de un proyecto. Dichas actividades estarán agrupadas por paquetes de trabajo. El propósito de un WBS es dividir el proyecto en porciones que posteriormente sean fáciles de planificar en tiempo, coste, recursos, etc. En el nivel más alto de la estructura WBS o primer nivel, se tendrá el principal objetivo del proyecto o fase que estemos gestionando. En el segundo nivel se tienen las metas más significativas a alcanzar y en el tercer nivel una división de estas metas en hitos más pequeños. Así la estructura se divide en niveles y sub-niveles hasta alcanzar las llamadas unidades de trabajo. Todas las tareas tienen asignado un código numérico gracias al cual es posible identificar a que paquete de trabajo pertenece cada tarea y en qué nivel se encuentra situada dentro de la estructura. Las unidades de trabajo son actividades pequeñas, de una duración en torno a una semana y que son asignables a una persona. A continuación se presenta el método iterativo descrito por Thayer, para la generación de una WBS. Este autor propone ir generando una pila de tareas susceptibles de descomposición y otra con las tareas fruto de la descomposición de las anteriores. El algoritmo general es el siguiente: 1. Se introduce en la pila de trabajo una tarea. 2. Se definen entradas, salidas y recursos para esa tarea y se determina si esa tarea puede ser llevada a cabo con una meta exacta. 3. Si se puede llevar a cabo dicha tarea, ir al paso siguiente. En otro caso, generar otras tareas y convertir la anterior en un hito colocándola en la pila de tareas terminadas. 4. Repetir el paso 2, hasta que la pila de trabajo esté vacía.

Técnicas de gestión de proyectos Bol 5. Recorrer la pila de tareas terminadas e ir acumulando la duración en los propios hitos. En la Figura 7.1 se puede ver el aspecto de una WBS genérica. Dicha WBS está estructurado en 4 niveles, siendo éstos: nivel de proyecto (nivel O), nivel de paquetes de trabajo (nivel l), nivel de actividades (nivel 2) y nivel de tareas (nivel 3). La numeración de las tareas viene a representar la posición que éstas ocupan en la estructura del proyecto. Por ejemplo, la tarea numerada como, 2.2.3, se ubica en la posición 2 del nivel 1, en la posición 2 del nivel 2 y en la posición 3 del nivel 3. Gracias a esta numeración, las tareas se pueden presentar en forma de lista además de en forma jerárquica. Nivel O..... Nivel 3 Figura 7.1 WBS genérico Desde el punto de vista de la Ingeniería del Software existen reglas generales aplicables a todo proyecto de desarrollo de software que serán las responsables de proporcionar las pautas necesarias para identificar el número de niveles de descomposición para la WBS. Por ejemplo, el criterio puede venir dado por las fases del ciclo de vida elegido para ese proyecto, por la metodología de desarrollo seleccionada, etc. Con la técnica de descomposición de actividades (WBS) no se ve claramente la dependencia entre las distintas tareas, ni el orden en que deben ejecutarse, por este motivo esta técnica debe ser complementada con

BO2 Gestión del Droceso software otros diagramas que se verán en el apartado dedicado a las técnicas de planificación de proyectos (Diagramas PERT y GANTT). Todas las herramientas software de gestión de proyectos tienen una opción en la que se puede observar el WBS en forma de lista con indentaciones, que muestra la estructura del proyecto a través de la numeración de cada una de las tareas. Esta vista es compatible con el diagrama Gantt de planificación que presente dicha herramienta. En MS-Project 98 la forma que se tiene de activar esta opción para las actividades de un proyecto es la siguiente: 1. Menú Herramientas, pulsar opciones. 2. Comprobar que está seleccionada la pestaña Vista. 3. En el área Opciones de Esquema, seleccionar la casilla de verificación Mostrar números de esquema. 4. Pulsar Aceptar. Nivel O l Proyecto I 1 Análisis de requisitos............ I 1.3.2 EFS2 1 7-7.3.3 EFS,4 1 Figura 7.2 WBS correspondiente al paquete 1 del diagrama CANil de la Figura 7.3 En la Figura 7.2 aparece parte de una WBS que representa la organización del paquete de trabajo 1, con sus códigos correspondientes. En este caso la organización utilizada sigue las pautas de la metodología de desarrollo Métrica V3. En la Figura 7.3 aparece el diagrama Gantt correspondiente a la WBS de la Figura 7.2. En dicho diagrama se han activado los Números de Esquema, tal y como se ha indicado anteriormente y

Técnicas de gestión de proyectos Sol el resultado será que todas las actividades pasan a tener un código numérico que las identifica, dicho código es el mismo que aparece en la WBS. I I í.2 Productoso i.4productoso &a de sistemas(20' de sirternam(l0' nakta de sisic 3 Productos de Di 4 Codficacián 4 1 1 Consiruc 4 1 2 Pruebas 6 29 sems 1,52 sems l lexrmgtidesplg alnidoi GBandelads 1 anavdxa.( W M i W 1 a\uavsdors. 1 ~\ilsvadaa 1- @MiaoadtPa.l Figura 7.3 Actividades con código de identificación 7.2.2. Descomposición según productos (OBS) El OBS (Object Breakdown Structure), también denominado a veces PBS (Product Breakdown Structure) es una representación jerárquica de los productos a obtener a lo largo del desarrollo del proyecto. Típicamente los niveles que refleja un OBS son los siguientes: Nivel O: Sistema completo. Nivel 1: Subsistemas. Nivel 2: Elementos de configuración, etc. Nivel 3: Componentes software. Como regla general se puede decir que la estructura de una OBS tiene un nivel más que el WBS del mismo proyecto. En dicho nivel se

304 Gestión del proceso software incluyen las tareas propias de cada una de las tareas del último nivel, identificadas en la WBS. La Figura 7.4 muestra un ejemplo de OBS, correspondiente a la descomposición en productos del proyecto de la Figura 7.3. Nivel O 1 Proyecto 1... s 1 Análisis de requisitos 1.2 Revisión de productos de... almacenes de datos Figura 7.4 OBS correspondiente al WBS de la Figura 7.3 7.2.3. Descomposición en recursos (RBS) Esta técnica de organización de proyectos software tiene por objeto representar la organización de recursos humanos del proyecto, su estructura, responsabilidades, etc.; así como la estructura de recursos tecnológicos y materiales. La RBS (Resource Breakdown Structure) es un árbol jerárquico que representa los recursos humanos y materiales del proyecto. Los principales objetivos de la RBS son los siguientes: 0 Mostrar gráficamente la organización (humana) del proyecto (organigrama).

Técnicas de gestión de proyectos BOI Maximizar el uso de los conocimientos y experiencia del personal disponible. Reflejar la estructura de recursos materiales necesarios para la realización del proyecto (herramientas, plataformas, etc.), así como sus costes asociados. En general, la estructura jerárquica que se refleja en la parte correspondiente a los recursos humanos de la RBS viene marcada por las políticas propias de la organización en la que se vaya a desarrollar el proyecto software. Aun así, existen algunas reglas generales aplicables a todos los desarrollos software y que son independientes de la organización en la que se esté llevando a cabo el desarrollo software. A continuación se pasa a identificar dichas reglas. El responsable de calidad y el jefe de proyecto no deben depender uno del otro, ya que sus tareas deben ser absolutamente independientes y no deben estar supeditadas las unas a las del otro. Un jefe de proyecto no debería gestionar a un equipo formado por más de siete personas. Ello implica que debería existir un jefe de proyecto por cada siete personas que se precisen para llevar a cabo un proyecto software. En la Figura 7.5 aparece un ejemplo de RBS en el que se pueden apreciar el resultado de aplicar las dos reglas anteriores para un proyecto software. Proyecto Analistas Jefe de Proyecto Ana López i-- Programadores Aseguramiento Jefe de Calidad Antonio Jorge López Figura 7.5 Ejemplo de RBS

308 Gestión del proceso software La RBS puede representarse de modo que se puedan observar por separado los recursos con los que cuenta la propia organización y por otro lado, los recursos con los que se cuenta del lado del cliente, para el cual se está llevando a cabo el proyecto. 7.3. Planificación de Proyectos La actividad de planificación o programación de un proyecto, consiste en establecer la estructura temporal de las fases, actividades y tareas del proyecto, en función de los recursos de que se disponga. Las planificaciones son llevadas a cabo en diferentes momentos del ciclo de vida del proyecto, apoyándose éstas a su vez en diversas técnicas de estimación de la duración de las actividades y tareas, así como de la carga de recursos en las diferentes fases. La planificación del proyecto se apoya en la fase previa de organización en la que se habrán construido los diagramas WBS, PBS y RBS. De forma genérica, la programación del proyecto implica las siguientes actividades: 0 Establecer la red del proyecto: consiste en modelar el proyecto a partir de la WBS construida en la fase de organización del proyecto, utilizando una red PERT. Identificando para cada actividad las fechas más tempranas y más tardías de inicio y fin, así como las holguras asociadas. Definir la ubicación en el tiempo de las actividades y recursos asociados: a partir del PERT, se realizará el diagrama GANTT del proyecto, así como el histograma de recursos. En este punto se verán las dos técnicas de planificación PERT y GANTT, que sirven de ayuda a la hora de planificar. La planificación trata básicamente de programar, en el tiempo, todos los elementos identificados a través de las técnicas de organización de proyectos vistas en el punto anterior. El motivo de programar las actividades se debe al hecho de que entre las actividades identificadas en la organización del proyecto, habrá una serie de dependencias que es preciso identificar, ya que si todas las actividades discurren libremente sin fechas ni costes ni recursos asignados, es seguro que el proyecto no tendrá éxito. Estas dependencias se pueden representar gracias a los diagramas que presentaremos a continuación.

Técnicas de gestión de proyectos Sol El establecer el calendario de trabajo no es una actividad en absoluto trivial y muchas veces la tarea de generar el calendario del proyecto, tarea propia del jefe del proyecto, es crucial para el propio proyecto. 7.3.1. Diagramas PERT Los diagramas PERT forman parte de una familia de diagramas de tipo red, que fueron desarrollados en los Estados Unidos durante los años 50, para su aplicación en proyectos de defensa a gran escala. Hay varias posibilidades para representar estos gráficos, aunque básicamente constan de unas líneas unidas por nodos, donde los nodos representan, en general, acontecimientos de la programación del proyecto. Para poder llevar a cabo estos diagramas es necesario conocer las dependencias entre las distintas actividades. Estas técnicas tienen una serie de ventajas como son el mostrar de una forma explícita y clara la dependencia entre actividades utilizando métodos de análisis como el PERT (Program Evaluation and Review Technique), Técnica de Revisión y Evaluación de la Programación, que se verán a continuación. Como desventaja cabría destacar lo difícil y poco flexible que resulta el hacer ajustes y modificaciones, y además no son una buena herramienta para hacer seguimiento del proyecto. 7.3.1.1. bef iniciones y formas de representación A continuación de describen algunos términos usados en la construcción de diagramas PERT y su forma de representación. Actividad: también denominada elemento de trabajo. Una actividad tiene una duración relacionada con el alcance de ésta. Se representan por cajas que contienen el nombre de la actividad y alguna información adicional. La representación de las actividades aparece en la Figura 7.6. Figura 7.6 Actividades en el diagrama PERT Enlaces entre actividades: los enlaces representan la dependencia entre actividades, se representan por flechas que conectan las actividades. Los enlaces verticales representarán paralelismo y los horizontales deben dibujarse de izquierda a derecha. La Figura 7.7 muestra que la actividad

308 Gestión del proceso software A b B Figura 7.7 Enlace entre actividades secuenciales Actividad paralela: se trata de una actividad que debe ejecutarse en paralelo con otra u otras actividades de la red. La Figura 7.8 muestra que la actividad A y la actividad B se pueden llevar a cabo en paralelo. Figura 7.8 Enlace entre actividades paralelas Desfase: hace referencia al tiempo que tarda una actividad en comenzar tras la finalización de la actividad que la precede. En el ejemplo de la Figura 7.9, si N es positivo, significa que B comenzará N días después de la finalización de A, y si N es negativo, B comenzará N días antes de que finalice A. U U Figura 7.9 Desfase entre dos actividades Evento o hito: un evento o hito es un punto en el proyecto que tiene especial relevancia. Todos los proyectos tienen al menos dos hitos: el de comienzo y el de fin. Otros hitos típicos son la aprobación de presupuestos, la producción de un resultado importante, etc. Los hitos se representan mediante triángulos equiláteros o rombos. Suceso externo: La ocurrencia de un suceso externo tiene el mismo sentido que la finalización de una actividad de la red, y señala la disponibilidad de un recurso que viene de fuera del proyecto que se está modelizando. Los sucesos se representan asimismo mediante cajas conteniendo su nombre. Los enlaces entre sucesos y actividades se

Técnicas de gestión de Drovedos 109 representan mediante una flecha discontinua oblicua como se puede ver en la Figura 7.10, entre el suceso A y la actividad C. IBJ T 1 Figura 7.10 Suceso externo 7.3.1.2. Modelado usando la técnica PERT El modelado de una red PERT consta básicamente de los siguientes pasos: 1. Se identifican los enlaces de las actividades representadas en el WBS. 2. Se asignan duraciones estimadas a las actividades. 3. Se determinan las fechas de comienzo y finalización, así como las holguras para cada actividad. En el caso de los proyectos software es aconsejable realizar estos tres pasos de forma iterativa, realizando redes PERT por niveles de la jerarquía representada en el WBS. Es decir, establecer un diagrama PERT general al comienzo del proyecto, a nivel de fases de desarrollo. Posteriormente ir generando submodelos detallados a medida que se van realizando las fases del proyecto e incluirlos en el modelo general para poder recalcular el conjunto de datos del proyecto. Así se puede ir generando el proceso global de modelado del proyecto. 7.3.1.3. Ejemplo de modelado PERT Enunciado: Las actividades 1 y 2 se pueden realizar en paralelo. Las actividades 3, 4 y 5 se pueden realizar en paralelo. Las actividades 6 y 7 se pueden realizar en paralelo. Las actividades 3, 4 y 5 deben realizarse cuando terminen las actividades 1 y 2. Las actividades 6 y 7 deben realizarse cuando terminen las actividades 3, 4 y 5. La actividad 8 debe realizarse cuandc terminen las actividades 6 y 7. Se trata de dibujar el diagrama PERT para dicho proyecto. En la Figura 7.11 se presenta el diagrama PERT correspondiente al problema planteado.

310 Gestión del proceso software 7.3.2. Diagramas GANTT Figura 7.11 Ejemplo de red PERT El diagrama Gantt o de Barras es una de las técnicas de planificación más utilizadas. Este tipo de diagramas es más fácil de entender que las redes de precedencia como por ejemplo la red PERT. El principal inconveniente de este tipo de representaciones estriba en la incapacidad para representar interrelaciones entre tareas, es decir, no queda reflejado el hecho de que un producto que fue originado por una tarea sea utilizado como entrada en otra u otras. Por otro lado sí se puede reflejar muy bien el paralelismo y las precedencias en el tiempo entre tareas. 7.3.2.1. Definiciones A continuación de describen algunos términos usados en la construcción de los diagramas Gantt. Fecha de Comienzo más temprana: es la fecha en la que todas las actividades que preceden a una actividad estarán finalizadas teniendo en cuenta los desfases. Es igual a la mayor de las fechas de finalización más temprana de todas las actividades que preceden a una dada. Fecha de Finalización más temprana: es la fecha de comienzo más temprana de la actividad aumentada en su duración. Fecha de Finalización más tardía: es la fecha a la que como mucho se puede retrasar la actividad sin afectar a la fecha más tardía de finalización del proyecto. Es igual a la menor de las fechas de comienzo más tardías de las actividades siguientes. Fecha de Comienzo más tardía: es la fecha de finalización más tardía disminuida en la duración de la tarea.

Técnicas de gestión de proyectos B11 Holgura (Margen Total): representa lo más que se puede retrasar una actividad sin afectar a la fecha de fin de proyecto. Es la diferencia entre la fecha de finalización más tardía y la fecha de finalización más temprana de la actividad. Margen Libre: representa el tiempo máximo que se puede retrasar una actividad sin afectar a la fecha de comienzo de las actividades siguientes. Es la diferencia entre la fecha de finalización más temprana de la actividad y la menor de las fechas de comienzo más temprana de las actividades que le siguen. 7.3.2.2. Modelado de diagramas Gantt El formato básico de un diagrama de Gantt consta de una lista de actividades a las que se asigna fecha de comienzo y finalización. El nombre de la actividad suele aparecer a la izquierda del diagrama y la escala temporal en la parte superior del diagrama. Cada tarea tiene una línea horizontal que cubre el período de tiempo que dura esa actividad. La escala temporal suele venir dada en días, semanas o meses. En la Figura 7.12 se puede apreciar el formato básico de un diagrama Gantt. jtj Programación Pruebas S Implantación 11 21m 09105 Figura 7.12 Ejemplo de Cantt Básico Los diagramas de Gantt tienen la ventaja de mostrar el calendario gráficamente indicando todas las tareas que deben hacerse y cuando tiene previsto su comienzo y su fin. En proyectos sencillos, sobre todo si los participantes conocen bien su trabajo suele bastar con estos diagramas para empezar la previsión de los tiempos, aunque en proyectos complejos siempre es necesario empezar por la técnica WBS. En la Figura 7.13 se puede ver el Gantt correspondiente al diagrama PERT del apartado anterior, suponiendo que el proyecto comienza el 5/7/99.

la2 Gestión del Droceso software 2 días Iu 05107199 ma 0610789 l 3 días Iu 05107199 mi 07107199 l 4 días JU 08107199 ma 13107199 3 dias JU 08m78g IU I 2107199 --d- - - - 3 dias JU 0810789 IU 12mm 5 días 1 mi 1 4107199 ma 2 omm 6 días ' mi I 4107199 mi 21mm Figura 7.13 Ejemplo de Cantt correspondiente a la red Pert de la Figura 7.11 En el diagrama GANTT se puede ver como la herramienta unifica los diagramas obtenidos en el proceso de organización del proyecto. En este diagrama se puede reflejar la duración de las tareas, la relación entre ellas así como el porcentaje de recursos, de los identificados en la RBS, asignados a cada tarea. 7.3.3. Ejemplo A continuación se pasa a describir la relación que tiene el proceso de organización de proyectos con el de planificación, así como la representación de los elementos que intervienen en ambos procesos con la herramienta Microsoft Project 988. Supóngase que se desea llevar a cabo un proyecto informático que denominaremos Proyecto OO. Para ello se ha decidido utilizar el paradigma de orientación a objetos. El primer paso será decidir cuales son las tareas a llevar a cabo para ese proyecto. Dicha información se recoge en la WBS de la Figura 7.14. Para cada una de las tareas identificadas en la WBS se deben indicar los productos que se obtendrán con el fin de poder cuantificar con mayor precisión en el proceso de planificación lo que durará cada tarea, así como los recursos que se le deben asignar. El diagrama de tareas PBS correspondiente a la WBS de la Figura 7.14, es el que aparece en la Figura 7.15. Por otro lado cada una de las tareas identificadas debe tener un conjunto de recursos asignados, luego, el siguiente paso es la identificación de recursos para el proyecto en cuestión. Dichos recursos se reflejan de forma jerárquica en la RBS de la Figura 7.16.

Técnicas de gestión de Drovectos 313 c :o so NE c m - a Figura 7.14 WBS del Proyecto O0

n4 Gestión del proceso software 1 : 1 c :o so NI c m - n I ----1 Figura 7.15 PBS del Proyecto O0

Técnicas de gestión de proyectos 31s Jefe de Proyecto Ana López Jefe de Calidad Antonio Rodríguez Pruebas Aceguram en to.. - ~ ~ ~ ~ R O L d, Jorge López García López Rarn írez Pérez Sánchez Figura 7.16 RBS del Proyecto O0 A continuación se debe construir el diagrama Gantt que contiene las actividades de la WBS, pero esta vez entrelazadas de manera que se muestre la relación de precedencia entre ellas. Dicho Gantt es el que aparece en la Figura 7.17, en él ha quedado reflejada la información contenida en la WBS como se puede ver a través de los códigos asignados a cada una de las tareas que aparecen en el Gantt. La asignación de tiempo para cada tarea de la WBS se ha llevado a cabo teniendo en cuenta la envergadura de los productos que se deben relizar en cada tarea según se indica en la PBS de la Figura 7.15. El siguiente paso consiste en la asignación de los recursos indicados en la RBS de la Figura 7.16, a las diferentes tareas del Gantt. Para crear los recursos de un proyecto determinado, es necesario indicar una serie de datos, como son el nombre del recurso, el número de horas que dedica al proyecto, la capacidad máxima, etc. Los datos a introducir son todos muy intuitivos excepto el dato "Capacidad Máxima", el cual hace referencia al número máximo de recursos de ese tipo que se tienen y viene descrito en términos de tanto por ciento, lo que significa que una capacidad máxima de 100% de un tipo de recurso viene a decir que tenemos un solo recurso de ese tipo, una capacidad máxima del 200% significa que se tienen dos unidades de ese recurso. En la Figura 7.18 se pueden observar los recursos que se van a disponer durante el desarrollo del Proyecto OO.

~ Id 1 I INombre de tarea Duración.. C 3 ]un '02 03106 O jun '02 I on6 7 )un '02 I 7106 1 jui '02 o1 107 18 jui '02 08107 9 dias - - 1 2 Modelado EstátGo 3 días - 1 3 Modelado Dinayco - 1 4 Calidad [Revision de Análisis) - -- - 1 5 HLo de linea base de Analisis 3 días 1 día O días 2 Gestión 41 días c 2.1 Seguimiento (reuisar gantt de se 41 días, 2 2 Estimación 2 días ' 2 3 Calidad (pian de calidad) 2 dias I I 4 2 4 Planificación 2 dias - _- - t- 25 Calidad (Revisión Gestión) +- - - - - - 1 dia 2 6 Hito de línea base de Gestión O días 77-------- - 3 Diseno 5 días - ---~ - - -- 3 1 Modelado Estático Ampliado 2 dias t - - - - - 3 2 Modelado Dinámim Ampliado 2 días 3 3 Calidad [Gvision de Diseño) c -- _ - 3 4 HLo de línea base de DiseRo 1 día O dias 412mfi - - - 4 irnpiirneitactón - 22 días 4 1 Implementación del Gestor de Maestrc 15 días 4 2 Implementación del Resto de Módulos 20 días 4 3 Pruebas 1 día 4 4 HLo de línea base de Implernentación 1 día

Técnicas de gestión de proyectos Si7 Programador P 300% 6 O00 piahora 12 O00 ptahora Jefe de proyecto J 100% 20 O00 piahora 30 O00 piahora Encargado de pruebas E 100% 4 O00 piahora 8 O00 pialhora Encargado de Aseguran E 100% 5 O00 @ahora 1 O O00 ptahora Figura 7.18 Recursos disponibles para el Proyecto O0 Una vez que la asignación está hecha, es muy importante comprobar que no haya ningún recurso sobrecargado. Para comprobarlo basta con verificar que en ningún momento existe un recurso que se esté utilizando por ericirria de su capacidad máxima. Normalmente las herramientas de planificación de proyectos generan unos diagramas con los cuales se puede apreciar dicha sobrecarga. Si, por ejemplo, en el caso del proyecto O0 se asignan para la tarea modelado estático dos analistas, y para la tarea modelado dinámico un analista, como esas dos tareas se realizan en paralelo, sucede que el recurso Analista en el período que va desde el 22 de Mayo de 2002 hasta el 24 de Mayo del 2002, estaría asignado al 300%. Debido a que su capacidad máxima es del 200%, en el histograma de dicho recurso se aprecia más obscuro una sobreasignación del 100%, es decir, haría falta otro analista más para poder llevar a cabo dichas tareas en paralelo con una carga de 200% y 100% de analista respectivamente.. Recursos asignados.. Figura 7.19 Histograma del recurso Analista del Proyecto O0

~~~ E 15107 - - 22107 2 1 5 SqFlmedo (revisar pann de s 1 dia - - - - ~ _ ~ 2 1 7 S-Fmierto (revisar gardi des 2 1 8 Segumrnto (remar gardi de s 1 &a 1 dia de prcyectoi50k1 M e de prcyedoi50%] 8 M e de propdo(5ükl 8 Jefe de propdo15ox1 Jefe pro~e~oisdx1 Jefe de propdo(50. Jefe de 1 VKtoI50~ 2 3 CaYad ( ph de caldad) 2 4 Plwuficacnn 2 5 Cahdad (Revision Gesim) 2 6 Hto de llnea base de Gedion de Aseguramiento de Calidad e de prcye~oi5t%l;rinalisi~50~] argado de Asegurmiento de Calidad nador 4 4 Hito de llnea base de hplmeni~ion 1 da t gado de 1 ebas

Técnicas de gestión de proyectos 319 Si llegase a producirse una sobrecarga en algún recurso, esta sobrecarga se puede resolver redistribuyendo esfuerzos o tiempo. En el caso anterior, se podría asignar un analista a la tarea modelado estático y otro a la tarea modelado dinámico, de manera que se sigan realizando en paralelo pero sin sobrepasar el 200% de capacidad máxima del recurso Analista, o bien deshaciendo el paralelismo existente entre ambas tareas y dejando la asignación de 200% para la tarea modelado estático y 100% para la tarea modelado dinámico. El Gantt que se obtiene tras asignar los recursos a las tareas es el que aparece en la Figura 7.20. Dicho Gantt no presenta sobrecarga para ninguno de los recursos disponibles. 7.4. Seguimiento del Proyecto El seguimiento de proyectos software es un proceso de gestión que viene a complementar los procesos de gestión antes descritos. Gracias a las técnicas propias del proceso de seguimiento es posible controlar el proyecto para que no se produzcan desviaciones tanto de coste como de tiempo, recursos, etc. Esto significa que tanto la planificación inicial del proyecto como el resto de procesos de gestión se retomarán en diferente puntos del desarrollo software. Dichos puntos vendrán marcados por las desviaciones detectadas por el proceso de seguimiento. A continuación se presentan las técnicas más extendidas para la realización de la actividad de seguimiento de un proyecto software. 7.4.1. Fichas e informes de seguimiento Las tareas de seguimiento abarcan todo el desarrollo del proyecto. El seguimiento se realiza fundamentalmente mediante comparaciones sucesivas entre la ejecución real del proyecto y el plan de acción del mismo. Las actividades de planificación constituyen un preámbulo imprescindible para el seguimiento. En un seguimiento automatizado se fijarán con una cierta periodicidad la realización de unas medidas de avance y la corrección del plan previsto en función de las diferencias encontradas. Una periodicidad habitual es de una semana, y si el período es más grande se efectuará una previsión de las desviaciones para determinar si las diferencias que revele el seguimiento son o no sistemáticas.

U0 Gestión del proceso software Un aspecto fundamental en la realización del seguimiento del avance del proyecto es la utilización de las fichas e informes de seguimiento. Se trata de unos documentos que deben definirse por cada organización y en los que se reflejará el estado del proyecto en cada momento. A partir del estudio y análisis de los datos recogidos en las fichas se realizará un balance y una síntesis de la información, y se confeccionará un informe del estado real del proyecto. En dicho informe aparecerá información sobre: 0 0 Estado de gastos y reasignación de recursos a las actividades del proyecto establecidas en la WBS. Para ello, se deberá determinar una comparación entre el esfuerzo, los recursos humanos y materiales realmente empleados y las estimaciones previstas en el plan para la detección de desviaciones. Calendario revisado del proyecto. Diagrama de costes reales del proyecto. 0 Diagramas de 45'. Los informes de seguimiento deben facilitar la recopilación de información referente a: 0 0 0 El estado de las tareaslactividades (sin comenzar, suspendida, comenzada, finalizada). El esfuerzo efectivamente consumido en cada tarea/actividad. Fecha real de comienzo de cada tarea/actividad. Fecha estimada de finalización de cada tarea/actividad/hito. Estado de los productos a entregar. Incidencias. El informe del estado del proyecto permitirá redefinir el nuevo plazo estimado de finalización del proyecto y, en caso de ser necesario, una reasignación presupuestaria de las actividades del proyecto. 7.4.2. Diagrarnas de 45' Se trata de una técnica de seguimiento de proyectos utilizada para estimar posibles desviaciones de duración.

Técnicas de gestión de proyectos S21 Los Diagramas de 45" permiten obtener una representación gráfica de la cronología de las estimaciones del consumo de recursos necesarios para la realización de un hito. En el eje de abcisas se representan los períodos de tiempo de seguimiento. En el eje de ordenadas se representan las estimaciones de duración (duraciones previstas) para la realización del hito considerado. Dado que los ejes tienen la misma escala, los hitos ejecutados según el plan (sin retrasos ni adelantos) deben caer sobre la bisectriz. Los Diagramas de 45" se realizan para cada hito. Comienzan en la fecha prevista de comienzo de los mismos, y se actualizan en cada etapa del seguimiento. La interpretación de los Diagramas de 45" está basada en la hipótesis de que en el caso de existir una desviación, ésta se mantendría o aumentaría según fuera avanzando el proyecto. Por esto, pretende estimar la nueva fecha de fin de proyecto extrapolando la tendencia constatada. Existen varios métodos de extrapolación, siendo el más común el de extrapolación lineal mediante mínimos cuadrados. La proyección del cálculo de la nueva fecha de consecución del hito se hace utilizando el siguiente procedimiento: 1- Se ajusta utilizando el método de mínimos cuadrados un polinomio de grado uno. 2- Se calcula el punto de cruce de la recta obtenida con la bisectriz ( y = x ). Este punto constituye la extrapolación, en función de la tendencia actual, de la fecha de consecución del hito. Las ecuaciones que permiten realizar esto son: Y = K * (X - xo) + y0 i=l El punto de intersección, correspondiente a la previsión de desviación en duración, se obtiene a partir de: Y=yO/(l-K)

322 Gestión del proceso software 7.4.2.1. Ejemplo de aplicación Se tienen los siguientes datos de un proyecto cuya duración prevista es de 90 días: 1 Fechaseguimiento 1 Duración 1 - (días) O 5 10 15 20 (días) 90 90 92 92 92 Para calcular la duración estimada del proyecto, se aplicará la técnica del diagrama de 4.5" tal y como se presenta a continuación: K = ((92-90)*10 + (92-90)*15 + (92-90)*20) / (O2 + 52 + lo2 + 152 + 202) = 0.12 Y = 90 / (1-0.12) = 102.27 días de proyecto en total. Como se puede observar el retraso para el proyecto es de 12 días respecto de la fecha estimada. 7.4.3. Histograma del avance de costes Esta técnica de seguimiento permite representar la evolución temporal de los costes estimado y real a lo largo del proyecto. Las curvas de coste, también denominadas de flujo de caja, representan la evolución temporal de los costes previstos y/o reales de forma instantánea o acumulada. Para cada período se suman todos los costes previstos o reales que se tienen en el mismo. Cada punto de la curva de coste instantáneo representa precisamente la suma de costes. Cada punto de la curva de coste acumulado representa el sumatorio de todos los puntos de la curva de coste instantáneo hasta ese momento. A continuación se presenta un ejemplo de Diagrama de Avance de Coste (Acumulado). Sea el siguiente proyecto con la siguiente distribución de costes en el tiempo:

Técnicas de gestión de proyectos 323 Semana 1 2 3 4 5 Coste previsto Coste acumulado en la semana X en la semana X 150 150 200 350 1 O0 450 150 600 250 850 900 800 700 600 +Real 300 200 1 O0 O O 1 2 3 4 5 6 Semana Figura 7.21 Ejemplo de histograma de avance de recursos

u4 Gestión del proceso software 7.4.4. Gantt de Seguimiento El Gantt de Seguimiento es una herramienta que resume el desarrollo real del proyecto, en tiempos, costes, etc. Para poder saber la desviación actual del proyecto respecto a lo planificada inicialmente se compara el diagrama Gantt inicial con el diagrama Gantt de seguimiento en diferentes momentos del desarrollo. Desde el momento en que se da por terminado el plan de proyecto, se establece una línea base que está marcando el momento del tiempo a partir del cual se quiere empezar a realizar el seguimiento del proyecto. A continuación se verá un ejemplo de uso del Gantt de seguimiento. Se supone que la fecha prevista de inicio del Proyecto O0 es el 9 de Mayo de 2002, pero a esa misma fecha, el analista encargado de llevar a cabo la tarea de Definición de requisitos le hace saber al jefe de proyecto que no puede comenzar su tarea hasta el próximo 20 de Mayo de 2002 y que en lugar de tardar 9 días tardará 12. El jefe de proyecto lo que debe hacer es evaluar esta nueva situación. Para ello utilizará el Gantt de seguimiento del proyecto donde deberá escribir los datos reales de la tarea en cuestión, es decir indicar que comenzará el día 20 de mayo de 2002 y que durará 12 días. A continuación en el Gantt de seguimiento se observará el cambio que sufre esa tarea respecto de lo planificado inicialmente. Normalmente en las herramientas de control de proyectos se pueden ver simultáneamente el Gantt inicial y el de Seguimiento de modo que se pueda identificar más fácilmente la desviación existente entre ambos. Según se muestra en la Figura 7.22 se puede observar el desplazamiento de todas las tareas del proyecto debidas a la modificación que ha sufrido la tarea Definición de Requisitos. Así el jefe de proyecto puede valorar el impacto sobre el proyecto de dicho retraso. Además en la Figura 7.23 se puede observar el impacto en costes de dicha modificación en el proyecto. Se puede ver el incremento de coste debido a la prolongación del proyecto.

F Q 2 3 O & 9 O rc 8 O Seguimenlo (re! Seguirnida (m Segulmenlo (re\ Seguirnienlo (re\ segurnienlo (re\ Segumenlo (re, Calidad (plan de cal, Calidad (Revism GE Hto de h a base de Wemenlacion del 1 imo de lnea base I*

326 Gestión del proceso software Definicion de Requisdos 960 O00 pia 720 O00 pia 240 O00 pia 960 O00 pia Modelado Estático 240 O00 pia 240 O00 pia 0 pia Modelado Dinámico 240 O00 pia 240 O00 pia 0 pia Calidad (Revisión de Análisis) 40 O00 pia 40 O00 pia 0 pia HLo de línea base de Analisis 0 pia 0 pia 0 pia El Gestión 1.400.000 pía 1.400.000 pía 0 pía El Seguimiento (revisar ganil 720.000 pía 720.000 pía 0 pía Estimación 320 O00 pta 320 O00 pia 0 pia Calidad (plan de calidad) 80 O00 pta 80 O00 pia 0 pia Planificación 240 O00 pia 240 O00 pia 0 pia Calidad (Revisión Gestión) 40 O00 pia 40 O00 pia 0 pia HLo de línea base de Gestión 0 pia 0 pia 0 pia El Oiseiio 360.000 pía 360.000 pía 0 pía Modelado Estático Ampliado 160 O00 pia 160 O00 pia 0 pia Modelado Dinámico Ampliado 160 O00 pia 160 O00 ptal-1 Calidad (Revisión de Diseño) 40 O00 pia 40 O00 pia 0 pia Hfio de línea base de Diseño 0 pia 0 pia 0 pie El Irnplernentación 1.712.000 pía 1.712.000 pía 0 pta Implementación del Gestor de F 720 O00 pia 720 O00 pia 0 pia Implementación del Resto de lu 960 O00 pia 960 O00 pia 0 pia Pruebas 32 O00 pia 32 O00 pia 0 pia 0 pia 240 O00 pia 240 O00 pia 40 O00 pia 0 pia 1.400.000 pía 720.000 pía 320 O00 pia 80 O00 pia 240 O00 pia 40 O00 pia 0 pia 360.000 pía 160 O00 pia 160 O00 pia 40 O00 pia 0 pia 1.712.000 pía 720 O00 pia 960 O00 pta 32 O00 pia Figura 7.23 Costes acumulados 7.5. Bibliografía Albrech, A.: Measuring Application Development Productivity. Proceedings of the IBM Application Development Symposium, GUIDE/SHARE, Monterrey (California). Octubre, 1979. pp. 83-92. Boehm, B., Clark, B., Horowitz, E., Madachy, R., Selby, R. y Westland, C.: Cost Model for Future Software Life Cycle Processes: COCOMO 2.0, Annals of Software Engineering Special Volume on Software Process and Product Measurement, Eds. J.D. Arthur, S.M. Henry y J.C. Baltzer, Editorial AG Science Publishers, Amsterdam (Holanda), Vol 1, 1995. Cotterell, Mike, Bob Hughes: Software Project Management. International Thomson Computer Press, 1995. Dymond, Kenneth M.: Una Guía del CMM. Process Inc US. 1997. Humphrey, Watts S.: Managing the Software Process, Addison Wesley, Reading, Mass. 1989.

Técnicas de gestión de proyectos 327 IFPUG: (International Function Points Users Group) : Function Points Users Manual. Version 4.1, NJ, USA, 1999. Koontz, H. and C. O Donnell: Principles of Management: An Analysis of Managerial Functions, 5th ed. McGraw-Hill Book Company, NY, 1972. López-Cortijo R., Amescua Seco A.: Ingeniería del software: aspectos de gestión, Instituto Ibérico de la Industria del Software. 1998. MacConnell S: Desarrollo y gestión de proyectos informáticos, McGraw-Hill. 1997. Mallo, Carlos y Merlo, José: Control de gestión y control presupuestario, McGraw-Hill. 1995. Paulk, Mark C.: The Capability maturity model : guidelines for improving the software process. Carnegie Mellon University, Software Engineering Institute. 1995. Thayer, Richard H.: Software Engineering Project Management, IEEE Computer Society Press. 1987.