Técnicas de gestión de proyectos

Transcripción

1 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 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,

2 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

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

4 280 Gestión del proceso software 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 El modelo COCOMO 11 está compuesto por los tres submodelos que se detallan a continuación.

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

6 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

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

8 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

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

10 286 Gestión del proceso software Y para el tiempo de desarrollo se aplica la formula: (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 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: // 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.

11 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

12 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

13 ~ 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%

14 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.o 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.

15 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 ) = Esfuerzo = e = ( 20 )'~036((1.I0)(1.24)(1.23)(0.81)(1.19)(1.22)(0.90)= = MM Este esfuerzo se expresa en MM (man - month), hombres - mes 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:

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

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

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

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

20 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: / / 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: 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.

21 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 O O 3 O 2

22 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 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 = = 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

23 Técnicas de gestión de proyectos 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: 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,

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

25 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

26 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 EFS 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

27 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 Consiruc Pruebas 6 29 sems 1,52 sems l lexrmgtidesplg alnidoi GBandelads 1 anavdxa.( W M i W 1 a\uavsdors. 1 ~\ilsvadaa Figura 7.3 Actividades con código de identificación 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

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

29 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

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

31 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 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 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

32 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