Exportar (0) Imprimir
Expandir todo
Expandir Minimizar

Medida del nivel de éxito con fábricas de software y Visual Studio Team System

Noviembre de 2006

Publicado: 23 de Noviembre de 2006

Marcel de Vries
Info Support
Jack Greenfield
Microsoft Corporation

Este artículo se aplica a:
   Microsoft Visual Studio Team System
   Microsoft SQL Server 2005 Reporting Services
   Fábricas de software

Resumen: En este artículo se describe cómo se pueden usar las fábricas de software y Microsoft Visual Studio Team System de forma conjunta para mejorar la calidad, la capacidad de previsión y la productividad. Con las capacidades de almacén de datos y generación de informes de Visual Studio Team System, el generador de software de fábrica puede determinar de un modo confiable qué aspectos del desarrollo de los productos deben mejorarse y cómo modificar la fábrica de software para mejorarlos.

La conclusión de este artículo es que se puede conseguir una mayor calidad, capacidad de previsión y productividad si empleamos un enfoque de fábrica de software, en lugar de un enfoque tradicional de desarrollo aislado. Los conceptos y métodos de trabajo van dirigidos a los integradores de sistemas y a los clientes corporativos que desarrollan software personalizado.

En esta página

Introducción Introducción
Cambios en los procedimientos de creación de software Cambios en los procedimientos de creación de software
Medida de la calidad y la productividad Medida de la calidad y la productividad
Aplicación de Visual Studio Team System Aplicación de Visual Studio Team System
Uso de construcciones de medidas (ISO 15939) Uso de construcciones de medidas (ISO 15939)
Integración Integración
Conclusión Conclusión
Referencias Referencias
Acerca de los autores Acerca de los autores

Introducción

Actualmente, la creación de software es una labor difícil. Los sistemas son cada día mayores y más complejos. Debemos afrontar rápidamente los cambios tecnológicos y, al mismo tiempo, intentar mantener el ritmo de las demandas de los clientes de empresa, que desean que desarrollemos más software, mejor y en menos tiempo. ¿De verdad es posible aumentar la productividad y, a la vez, producir software de mayor calidad? ¿Es viable una mayor productividad en el mantenimiento y las actualizaciones sin que se pierda en calidad y sin que sea necesario realizar modificaciones de código de gran alcance? No parece probable que los sistemas con millones de líneas de código se puedan reescribir, sobre todo si la empresa desea implementar los cambios con rapidez. En este artículo explicaremos cómo ser más productivos y mejorar el desarrollo de software a través de un enfoque de fábrica de software.

Cambios en los procedimientos de creación de software

La industria del software lleva décadas creando sistemas de software para responder a las necesidades de los clientes. A pesar de toda esa experiencia, la calidad y la productividad no progresan con rapidez. El nivel de productividad es hoy similar al de hace diez años, según un estudio realizado por el grupo Standish. Actualmente, el 54% de todos los proyectos de desarrollo de software sobrepasan el presupuesto inicial, el 66% son considerados insatisfactorios por los clientes y el 90% no se entregan a tiempo. Sin embargo, lo más inquietante del estudio es que estas cifras no han mejorado mucho en los últimos diez años.

Pregunte a un grupo de desarrolladores o responsables de proyectos si consideran que actualmente tienen éxito con el desarrollo de software. Casi siempre, la tendencia es que se rían un poco y después reconozcan que también son víctimas de ese tipo de resultados. Es triste que nos inclinemos a pensar que, dado que la creación de software es un proceso creativo, debemos acostumbrarnos a las deficiencias en las entregas de los proyectos.

Cómo se crea el software actualmente

Una productividad baja se debe, a menudo, a la ausencia de requisitos adecuados o de algunos requisitos. La productividad se resentirá seriamente no sólo si creamos un sistema inadecuado, sino también si el ámbito del proyecto se amplía demasiado, de modo que rebase la funcionalidad prevista inicialmente. También nos resulta difícil realizar todas las pruebas pertinentes para asegurar el nivel de calidad que se espera. Las lagunas de mantenimiento y actualizaciones suelen estar relacionadas con la incapacidad de predecir el efecto de los cambios de código en la calidad del producto. ¿Cómo podemos garantizar que un cambio en una parte del sistema no ha afectado a otra parte?

Muchos de estos problemas surgen porque aprovechamos poco de lo aprendido en los proyectos que hemos realizado. Si preguntamos a varios equipos de desarrollo si aprenden de sus errores, comprobaremos que hay muy pocos que intenten aprender de forma activa de las experiencias para aplicar esos conocimientos a futuros proyectos. Pocos equipos reutilizan con regularidad soluciones creadas en el pasado, o realizan un seguimiento de lo que salió bien y de lo que salió mal. La consecuencia es que la transferencia de conocimientos entre proyectos es escasa; los conocimientos se quedan en la cabeza del desarrollador. Las lecciones ya aprendidas tienen que ser aprendidas una vez más por los nuevos desarrolladores. A los desarrolladores les resulta difícil abandonar los proyectos en curso, porque los conocen muy bien; tampoco tienen facilidades para entrar en nuevos proyectos, porque no hay mucho por escrito.

Dado que muchos proyectos no se entregan a tiempo ni se ajustan al presupuesto, podemos constatar que también existe un problema de capacidad de previsión. Cuando preguntamos a un responsable de proyectos cómo diseña el plan y la programación, aún resulta más sorprendente comprobar que se mantienen viejas costumbres y dicen cosas tales como: "Le pido a mi mejor programador que calcule el costo de una característica y después multiplico su cálculo por dos; mi programador tiende a ser optimista". Con frecuencia, esta clase de "presupuesto" se reduce posteriormente, ya sea para presentar una oferta competitiva, hacer que cuadren los números o satisfacer expectativas. Resulta difícil cambiar estos viejos hábitos.

Pero seamos sinceros. Los responsables de proyectos están prácticamente destinados a confiar en conjeturas de expertos, dado que no cuentan con métricas confiables. Lo que necesitan es poder obtener métricas de proyectos de desarrollo de software de un modo confiable; por ejemplo, en un almacén de datos. A partir de esas métricas, podrían saber cómo operan sus equipos de desarrollo y usar esos conocimientos para elaborar estimaciones más precisas. El uso de datos históricos para la calibración del rendimiento de la organización o del proyecto permite aumentar la precisión de las estimaciones, pero la mayoría de éstas se realizan sin datos históricos.

Si la capacidad de previsión es escasa, resulta difícil controlar los proyectos. Cuando un responsable de proyecto toma una decisión, ¿cómo puede saber los efectos que tendrá en la programación y en los costos? Sencillamente, no se pueden usar estimaciones imprecisas para prever las repercusiones de la toma de decisiones. Es como disparar con los ojos cerrados con la esperanza de acertar en el blanco.

Por todos estos problemas, producimos muy poco software en un plazo excesivo. Entregamos software de baja calidad y previsibilidad. Tenemos dificultades para mantener el desarrollo bajo control. Al profesional le resulta difícil cambiar de proyecto. Cada hora no prevista en el presupuesto supone un costo adicional, y cada defecto detectado en las pruebas (o, aún peor, en producción) cuesta aún más, al igual que las decisiones erróneas que se van tomando sobre la marcha. En la actualidad, crear software es muy caro.

Uso de fábricas de software

¿Podemos mejorar? Sí. Podemos crear software con puntualidad, sin salirnos del presupuesto y con una calidad adecuada. Sin embargo, primero es preciso que los miembros de la organización sean conscientes de que el método actual de creación de software es terriblemente ineficaz. Si no se constata la existencia de problemas, no habrá margen para mejorar. Para empezar a crear sistemas de software de un modo previsible, se impone un cambio de cultura. A los profesionales debe resultarles más fácil saber lo que deben hacer, cuándo hacerlo, por qué y cómo, y debemos automatizar más los aspectos repetitivos y que requieren menor cualificación. Estos objetivos se pueden conseguir formalizando una selección de aspectos del proceso de desarrollo. ¿Qué aspectos son? ¿Cómo podemos formalizarlos sin sacrificar agilidad?

Creatividad y formalización

La clave radica en formalizar las actividades detalladas que crean y modifican productos de trabajo, en lugar de intentar formalizar todo el proceso de desarrollo. Los flujos de trabajo menos detallados podrán evolucionar para adaptarse a los requisitos y las circunstancias del proyecto, siempre y cuando se mantengan los aspectos invariables para garantizar que los resultados sean válidos. Podría trabajar en el desarrollo de varias clases a la vez, por ejemplo, y pasar de una a otra según sea necesario, siempre y cuando se satisfagan todas las dependencias existentes entre las clases en el momento de la compilación. Esta flexibilidad permite mantener la agilidad y, al mismo tiempo, evita las colas en torno a una actividad determinada. Cuando se formalizan actividades detalladas, en lugar de intentar formalizar todo el proceso de desarrollo, se gana en calidad, capacidad de previsión y productividad sin sacrificar agilidad. Sabrá donde se precisan formalidades y dónde no, lo que facilitará un equilibrio adecuado entre agilidad y forma. Al formalizar únicamente donde y cuando se necesita, el proceso de desarrollo evoluciona de una manera muy orgánica y vertical, a la vez que se adquiere experiencia. Este enfoque también facilita la adquisición de conocimientos y su transferencia entre proyectos y profesionales, como veremos más adelante.

La creatividad es necesaria para solucionar problemas, pero no para actividades repetitivas o de poca cualificación. Resulta triste, aunque quizá no sea sorprendente, que una gran parte del trabajo cotidiano del desarrollador típico conste de actividades de repetición y de poca cualificación. La clave para ganar en productividad y capacidad de previsión sin sacrificar agilidad consiste en fomentar y apoyar la creatividad cuando sea necesario, y proceder a la formalización cuando no lo sea. Cuanto más formalicemos con patrones, prácticas y herramientas, más variaciones gratuitas eliminaremos del proceso. El hecho de eliminar variaciones innecesarias facilita la medición de proyectos de desarrollo de software, aprender de éstos y usar las medidas para mejorar futuros proyectos. La formalización de actividades repetitivas o que requieren menor cualificación estimula un aumento de la creatividad, al reducir la cantidad de tiempo y energía que se invierte a actividades que no la requieren.

Fábricas de software

De lo que se trata es de industrializar el desarrollo de software aplicando técnicas ampliamente contrastadas en otros sectores con la esperanza de que redunde en beneficio de nuestros clientes y del nuestro propio. Esta industrialización se logra creando fábricas de software que permitan aumentar la productividad y la capacidad de previsión en el desarrollo de software.

Una fábrica de software es un conjunto empaquetado de procesos, herramientas y otros activos integrados que se usan para acelerar las tareas del ciclo de vida para un determinado tipo de componente de software, aplicación o sistema. Es posible acelerar los proyectos si se brinda a los profesionales una orientación que les ayude a saber lo que deben hacer, cuándo, por qué y cómo. Para ello, proporcionamos orientación con una formalización justa de los procesos, con componentes que se puedan ensamblar y configurar rápidamente, o marcos de trabajo que se puedan completar en poco tiempo, así como con herramientas especializadas que automaticen de forma completa o parcial las actividades repetitivas o que requieren baja cualificación.

Uno de los principales objetivos que se pretende conseguir con una fábrica de software es aprender de las soluciones que hemos creado anteriormente para responder a problemas o requisitos comunes, y aplicar ese aprendizaje a futuros proyectos. Para ello, necesitamos un medio que nos permita describir esas soluciones reutilizables, y otro para organizarlas en torno a áreas de interés en que suelen encontrarse los problemas o requisitos a los que responden. Una organización de este tipo contribuye a reducir el conjunto de problemas o requisitos en cualquier momento, lo que facilita la identificación de las soluciones reutilizables pertinentes. Esas áreas de interés pueden encontrarse en un alto nivel de abstracción, como es el caso de la definición de capas de arquitectura, o en un bajo nivel de abstracción, como en la definición de firmas de método para clases o interfaces de C#.

Esquemas y plantillas

Para las fábricas de software se usa la terminología de IEEE 1471 sobre una práctica recomendada para la descripción de la arquitectura de sistemas complejos de software (en inglés), según la cual un área de interés equivale a un punto de vista. Los puntos de vista se pueden definir por varios motivos. Por ejemplo, para describir diversas partes de un producto, en distintos niveles de abstracción, en diferentes fases del ciclo de vida del desarrollo de software. Los puntos de vista pueden anidarse, de modo que un punto de vista de acceso a datos podría contener un punto de vista de biblioteca de acceso a datos, un punto de vista de diseño lógico de base de datos, un punto de vista de diseño físico de base de datos y un punto de vista de seguridad de datos.

Los productos de trabajo consumidos o producidos desde un punto de vista determinado constituyen una vista. Una vista se define por sus puntos de vista, al igual que un objeto se define por su clase. Un producto de trabajo podría ser un archivo, parte de un archivo, varios archivos o partes de varios archivos. Por ejemplo, en un punto de vista de biblioteca de acceso a datos, un producto de trabajo podría ser un archivo con una clase de acceso a datos para una tabla de base de datos. Una vista definida por el punto de vista de biblioteca de acceso a datos podría ser un proyecto que contenga un conjunto de clases de acceso a datos para todas las tablas de una base de datos determinada. Los puntos de vista pueden ser tanto transversales como modulares. Los productos de trabajo de un punto de vista de seguridad de datos, por ejemplo, podrían ser preámbulos en los métodos de inserción, reemplazo y actualización de clases de acceso a datos.

Los puntos de vista tienden a controlar la creación de herramientas y tipos de proyectos. Por ejemplo, un punto de vista de biblioteca de acceso a datos podría asignarse a un tipo de proyecto de biblioteca de clases basado en una plantilla de proyecto con determinadas propiedades, que contenga plantillas de elementos con propiedades para clases de acceso a datos. Cuando creamos proyectos de ese tipo, estamos creando vistas basadas en ese punto de vista. El contenido de las vistas son los archivos en la carpeta de los proyectos. Éstos son los productos de trabajo definidos por el punto de vista.

En niveles de abstracción superiores, los puntos de vista tienden a controlar el desarrollo de herramientas. Por ejemplo, un punto de vista de proceso empresarial podría manifestarse mediante una herramienta de modelos de procesos empresariales. La herramienta expone vistas a partir de ese punto de vista en forma de modelos, que son los productos de trabajo definidos por el punto de vista. También es compatible con las actividades definidas por el punto de vista con opciones de menú y otros movimientos, como la operación de arrastrar y colocar desde el cuadro de herramientas al diagrama para crear un nuevo tipo de mensaje.

Para cada punto de vista necesitamos un nombre y una descripción. También precisamos saber los productos de trabajo producidos o consumidos, los pasos necesarios para crear o modificar esos productos de trabajo y los activos que se usan para ejecutar esos pasos. Dicho de otro modo, un punto de vista debería indicarnos qué se debe crear, de qué modo y con qué (patrones, herramientas, plantillas, etc.). Los puntos de vista son los bloques de creación de las fábricas de software. Formalizan las actividades detalladas que permiten crear y modificar productos de trabajo.

Cada fábrica de software define el conjunto de puntos de vista interrelacionados necesarios para crear sus productos. Este conjunto de puntos de vista interrelacionados se denomina esquema. Podríamos imaginar un esquema de fábrica, como una tabla de contenido, que ayuda a conocer la organización de la fábrica de software para poder usar los activos que proporciona a la hora de crear los productos a los que se dirige. Un esquema de fábrica se parece mucho a un esquema de base de datos, que ayuda a conocer la organización de ésta para posibilitar la navegación, la realización de consultas y la manipulación de los datos que contiene. Sin embargo, en lugar de describir la organización de una base de datos, describe la de una fábrica de software.

Como ejemplo de esquema, examinemos una fábrica que crea aplicaciones empresariales administrativas a partir de una arquitectura orientada a servicios (SOA). Para esta fábrica podrían definirse los siguientes puntos de vista:

  • Aplicaciones para usuario Describe la creación de aplicaciones web o de Windows que admiten la entrada de datos en el escritorio del usuario. Indica al usuario cómo crear formularios web o de Windows mediante un diseñador y controles de entrada de datos desde una biblioteca que haya desarrollado a tal efecto. Las actividades para este punto de vista consisten en crear formularios web o Windows. Los productos de trabajo son los formularios. Los activos son el diseñador de formularios y la biblioteca de controles de entrada de datos.

  • Servicios de procesos. Describe la creación de servicios web responsables de la administración de procesos empresariales. Los servicios web se crean siempre del mismo modo a partir de un patrón, y tienen un contrato de servicio que describe una interfaz de C# mediante objetos con tipo generados a partir de un esquema XSD. La actividad de este punto de vista consiste en la creación de servicios web. Los servicios web son los productos de trabajo. Los activos son el patrón y el generador de objetos con tipo.

  • Servicios de plataforma. Describe la creación de servicios web que no son responsables de los datos empresariales, sino sólo de los servicios genéricos para todos los sistemas, como impresión, auditoría, autorización, etc. Este punto de vista proporciona servicios genéricos disponibles para la reutilización, e indica al usuario cómo evaluar y personalizar cada servicio. Las actividades de este punto de vista consisten en evaluar y personalizar los servicios. Los productos de trabajo son los servicios personalizados. Los activos son los servicios genéricos.

El último término de la nomenclatura relacionada con las fábricas de software que trataremos es el de plantilla de fábrica; un paquete instalable que contiene los activos suministrados por la fábrica de software. Para usar una fábrica, el profesional debe instalar la plantilla de fábrica en una estación de trabajo.

Las fábricas suelen desarrollarse de abajo arriba. Después de identificar una familia de productos de destino, a la hora de crear sistemas puede empezar por la detección y descripción de productos de trabajo y actividades; a continuación, organizarlos en puntos de vista, desarrollar activos para las actividades, organizar los puntos de vista en un esquema de fábrica y empaquetar los activos en una plantilla de fábrica.

Configuración de características

Una de las claves para la creación de una fábrica eficaz consiste en definir productos de trabajo, actividades y activos que se puedan usar en un gran número de soluciones distintas. Por ejemplo, el punto de vista de biblioteca de acceso a datos puede proporcionar una biblioteca que le ayude a obtener acceso a una base de datos SQL. Quizá no siempre use el mismo RDBMS para todos los proyectos, por lo que su biblioteca deberá adaptarse a otros RDBMS. Puede que los productos de trabajo usados con la biblioteca y las descripciones de las actividades realizadas con la biblioteca también deben adaptarse en consecuencia. Cuanto mayor sea la variabilidad que acepte un punto de vista, más flexibilidad le ofrecerá para aplicarla a distintas soluciones, aunque su configuración también requerirá más trabajo. La adaptación a una mayor variabilidad implica un aumento del grado de complejidad. Deberá buscar un punto de equilibrio en la variabilidad para que la fábrica de software resulte eficaz. Cuanto más genérica sea la fábrica, menores serán los logros en productividad y capacidad de previsión.

Una buena forma de determinar el margen de variabilidad adecuado es a través de un análisis de características de las soluciones que ha previsto crear. Mediante una técnica de análisis de similitudes y variabilidad (commonality variability, C/V), es posible separar las características comunes (u obligatorias) que deben presentarse del mismo modo en todas las soluciones, de las características variables (u opcionales) que podrían aparecer sólo en algunas soluciones o que difieren en su presentación según la solución de que se trate. La descripción detallada de este tipo de análisis se sitúa fuera del ámbito de este artículo, aunque existen numerosas publicaciones que tratan sobre el tema.

En la fábrica que crea aplicaciones empresariales administrativas a partir de SOA, el acceso a datos es una característica obligatoria (dado que en todas las soluciones se llevará a cabo), pero el cliente web es una característica opcional (dado que en algunas soluciones habrá clientes web y, en otras, clientes de Windows o no habrá ningún cliente).

En una fábrica tiene la posibilidad de usar modelos de características para describir las características que pueden aparecer en un miembro de la línea de productos, para separar las características comunes de las variables y para indicar cómo pueden aparecer las características variables. (Czarnecki y Eisenecker describen detalladamente los modelos de características. Para obtener más información, consulte la sección correspondiente en este artículo). En los modelos de características también se puede definir qué efectos tendrán las decisiones acerca de las características variables; por ejemplo, se puede indicar que una característica variable requiera la intervención de otra y que ésta, a su vez, sea incompatible con una tercera. Estas decisiones se toman para una aplicación determinada mediante la configuración del modelo de características. La configuración es un proceso simple en el que se debe especificar qué características variables descritas por el modelo aparecerán en la aplicación, y de qué modo aparecerá cada una. En la figura 1 se muestra un modelo de características simple para la fábrica descrita anteriormente.

Figura 1. Ejemplo de modelo de características

Si bien los modelos de características se usan para características visibles por los usuarios y se exponen como requisitos, también se pueden usar para características de diseño, implementación y pruebas que sólo pueden ver los desarrolladores. La vinculación de estas características da lugar a algunos escenarios que proporcionan una gran eficacia, en que mediante la configuración de características visibles para el usuario se configuran características visibles para el desarrollador. Por ejemplo, la vinculación de características de cliente visibles para el usuario con características de diseño de solución visibles para el desarrollador podría permitir a la fábrica generar un diseño de solución predeterminado basado en el tipo de cliente elegido por el usuario.

El trabajo con modelos de características es sólo uno de los mecanismos bien conocidos que se pueden usar para describir la variabilidad. Otros son los formularios, las tablas, los asistentes, los diseñadores, las plantillas, los patrones, los scripts y el código. Los mecanismos de variabilidad se pueden usar de forma independiente y en distintas combinaciones para especificar e implementar características variables en una fábrica de software.

Claves para el éxito

¿Cuáles son los factores clave para el éxito en la transición a un enfoque basado en una fábrica de software? Los requisitos son los siguientes:

  • Encontrar las similitudes y variaciones en los productos.

  • Medir el rendimiento del proceso actual de desarrollo de productos en términos de productividad y calidad.

  • Definir y mejorar un proceso que permita un desarrollo eficaz de los productos.

  • Proporcionar un modelo transparente que ayude a todos los agentes a conocer los logros en materia de productividad y calidad, y usar ese modelo para impulsar la transformación cultural.

  • Diseñar más de un proyecto a la vez.

  • Desarrollar de un modo rápido y económico activos reutilizables que encapsulen conocimientos y cuya reutilización resulte fácil; sobre todo en el caso de las herramientas personalizadas.

  • Identificar dominios específicos y tratarlos con herramientas y procesos personalizados, en lugar de intentar aplicar procesos y herramientas generales a todos los dominios.

Medida de la calidad y la productividad

Ahora que conocemos algo mejor las fábricas de software, examinaremos con más detalle la medida de la calidad y la productividad en el contexto de una fábrica de software.

Como podemos ver, el esquema de fábrica proporciona un mecanismo útil para organizar métricas. Dado que cada punto de vista se orienta a un aspecto determinado del proceso de desarrollo del software, es posible usar puntos de vista para definir medidas de productividad y de calidad. El uso de estas medidas permite recopilar datos sobre aspectos determinados del proceso de desarrollo del software. El análisis de los datos permite determinar qué puntos de vista deben mejorar y de qué manera, así como lo que se obtiene a través de esas mejoras.

Para implementar este método necesitaremos una forma de expresar el tamaño del producto, así como el tiempo y el presupuesto dedicados y la calidad del producto. Estas medidas podrán servir para cuantificar la capacidad de previsión, la productividad y la calidad de cada punto de vista. También se pueden usar para evaluar los productos finales de la fábrica. Midiendo cada punto de vista y el rendimiento general de la fábrica, puede determinar de qué modo afecta cada punto de vista al rendimiento general y, por lo tanto, cuánto debe invertirse para las actividades en un punto de vista determinado con activos reutilizables. Por ejemplo, podría proporcionar pautas simples en el caso de los puntos de vista que no influyen significativamente en el nivel general de eficacia, y diseñadores basados en DSL (lenguaje específico de dominio) para los puntos de vista que sí influyen en el rendimiento.

Este enfoque es similar al que aplican las grandes organizaciones para optimizar sus procesos empresariales. Definen las habilidades, los procesos y las herramientas que se necesitan para crear los productos de trabajo destinados a un determinado objetivo empresarial. A partir de ahí, miden el esfuerzo requerido para llevar a cabo el proceso, y después analizan dónde se puede realizar la aprobación. Se conoce como supervisión de procesos empresariales; pero, básicamente, es lo que hacemos al optimizar una fábrica de software. Sin duda, la medida es un factor esencial para establecer una línea de base del rendimiento actual de la fábrica y para identificar las inversiones adecuadas en un desarrollo de fábrica de software. Este proceso ayuda a obtener el máximo rendimiento de la inversión por lo que respecta a la capacidad de previsión, productividad y calidad. Le ayuda a comparar los resultados de los objetivos establecidos inicialmente antes de empezar el desarrollo de la fábrica.

Uso de puntos de función para expresar el tamaño del producto

Uno de los aspectos del desarrollo de software que probablemente desearemos mejorar es la productividad. Para cuantificar la productividad, se necesita una métrica que pueda usarse para expresarla en términos de volumen de producto de software creado en un período de tiempo. Cuando es posible predecir el tamaño del sistema y medir el crecimiento del tamaño del producto durante el desarrollo, podemos anticipar mejor el tiempo necesario para completar el proyecto y medir la productividad en horas por unidad de tamaño del producto. Al medir el tamaño y el crecimiento reales, podemos identificar diferencias entre los valores reales y previstos, y empezar a analizar y administrar las diferencias cuando se hacen evidentes.

Llegados a este punto, quizá se pregunte cómo podemos predecir el tamaño del producto y su crecimiento con suficiente precisión para que esta clase de medidas y análisis resulten útiles. Decididamente, no parece posible si desarrollamos aplicaciones arbitrarias en proyectos aislados. Sin embargo, si usamos una fábrica de software, dispondremos de dos ventajas que nos permitirán aumentar considerablemente la capacidad de previsión. En primer lugar, desarrollamos un miembro de una familia de productos determinada, con características conocidas, no una aplicación arbitraria. Puesto que la fábrica nos permite describir una familia de productos y sus características destacadas y, lo que es más importante, mejorar esa descripción a medida que se adquiere experiencia en el curso de diversos proyectos, sabremos mucho más acerca de una aplicación que se desarrolle con una fábrica que de una aplicación arbitraria. En segundo lugar, desarrollamos la aplicación aplicando la orientación prescriptiva que suministra la fábrica. Por lo tanto, realizamos muchas tareas de desarrollo de forma muy similar en aplicaciones sucesivas, con ayuda de los mismos patrones, plantillas, bibliotecas y herramientas. Si estandarizamos determinados procedimientos, con una fábrica tienden a suprimirse las variaciones innecesarias del proceso de desarrollo, de modo que resulta mucho más probable que el tamaño del producto y su crecimiento sigan patrones similares en distintas aplicaciones. Si usamos una fábrica de software, la medida de estos valores y la identificación, el análisis y la administración de las diferencias entre los valores planeados y reales pueden resultar de suma utilidad.

Ya hay muchos métodos de estimación que pueden ayudarle a determinar el tamaño del sistema. Si desea una métrica para expresar el tamaño y la productividad, necesitará una cuantificación objetiva. Esta cuantificación objetiva puede conseguirse a través de un método estandarizado. Uno de esos métodos es la medida del tamaño funcional, según se define en la norma ISO 24570. (ISO/IEC 24570:2004 especifica un método para medir el tamaño funcional del software, proporciona indicaciones acerca de cómo determinar los componentes del tamaño funcional del software, especifica cómo calcular el tamaño funcional a través del método mencionado, y proporciona instrucciones para la aplicación de ese método). Esta norma ISO usa puntos de función como un medio de expresar el tamaño del sistema de software a partir de especificaciones funcionales. Estos puntos de función se pueden considerar una métrica aproximada para determinar el tamaño de un sistema y calcular el esfuerzo y la programación. Durante el desarrollo, la métrica puede servir para determinar si el proyecto requiere más o menos trabajo que otros proyectos similares.

Con los puntos de función puede definir el tamaño del sistema en términos de funcionalidad empresarial. Esta funcionalidad viene determinada por los primeros requisitos recopilados, y se califica mediante la especificación. El análisis basado en puntos de función permite aprovechar los conocimientos obtenidos en la creación de aplicaciones orientadas a bases de datos, y se puede aplicar siempre que se crea un sistema que use la manipulación de datos de una base de datos. Los puntos de función se calculan en torno al conocimiento del número de tablas que se calcula que tendrá la aplicación y del número de funciones de manipulación de datos como funciones de recuperación y actualización de datos. A partir de aquí, es posible calcular el número de puntos de función con que se expresa el tamaño del producto. Después de expresar el tamaño estimado del producto, puede averiguar cuánto tiempo se necesita para implementar un punto de función o, incluso, usar datos históricos ya disponibles para realizar previsiones acerca de cuánto tiempo se necesitaría para implementar un punto de función. Una fábrica de software puede influir en el tiempo dedicado a implementar un punto de función (productividad), el número de defectos por punto de función (calidad), y la capacidad de previsión en las estimaciones.

Si examinamos con más detenimiento la capacidad de previsión, vemos que una fábrica nos permite separar las características comunes de todos los miembros de una familia de productos de las características variables presentes únicamente en algunos miembros, o que presentan distintos tamaños o características según de qué miembros se trate. En lugar de recopilar requisitos para un determinado producto a partir de cero, podemos suponer que presenta las características compartidas por todos los miembros de la familia y concentrarnos en la especificación de sus requisitos únicos o variables.

Volviendo al análisis de puntos de función en el contexto de una fábrica, vemos que podemos empezar con un tamaño de producto mínimo fijo que siempre tendremos, dado que en nuestra familia de productos siempre hay ciertas partes fijas. Este tamaño de producto mínimo fijo constituye una medida de las características comunes de la familia de productos. También podemos definir tamaños computables para muchas de las características variables que podrían agregarse o no a nuestro perfil de producto básico. A partir de esta información, tenemos la posibilidad de calcular el costo de una determinada configuración de características. Esa información, a su vez, puede ayudarnos a decidir qué características deben crearse. Dicho de otro modo, el análisis de puntos de función basado en la configuración de características nos proporciona un medio de evaluar sobre una base más sólida los pros y los contras con respecto a los costos y la funcionalidad.

Supongamos, por ejemplo, que aplicamos el análisis basado en puntos de función y determinamos que el sistema que vamos a crear tendrá un tamaño de unos 500 puntos de función. Cuando empezamos a crear este sistema, podemos determinar que se necesitarán 6.500 horas para llevarlo a cabo. A partir de ahí, podemos expresar nuestra productividad resultante como 13 horas (h)/punto de función (pf).

Si también realizamos un seguimiento de los defectos detectados en el producto durante el desarrollo, la prueba de aceptación por parte de los usuarios y la producción, también podremos expresar ese número como una métrica de calidad. Imaginemos que hemos encontrado 500 errores durante el desarrollo, 50 durante las pruebas de aceptación y 5 después de pasar a la fase de producción. Esto podría expresarse como 1 defecto/pf durante el desarrollo, 0,1 defectos/pf en la prueba de aceptación y 0,01 defectos/pf en la producción.

Ahora, supongamos que es posible averiguar el origen de muchos de estos defectos en un recorrido hasta el punto de vista de las aplicaciones cliente. A partir de ahí, constatamos que este punto de vista presenta un elevado porcentaje del número total de defectos, de modo que podemos centrar la atención en los aspectos susceptibles de mejora dentro de este punto de vista. Esta clase de análisis nos permitirá determinar qué puntos de vista se deben mejorar y de qué manera, a fin de reducir el número de defectos la próxima vez que se use la fábrica. Lo mejor de poder cuantificar el número de defectos con una métrica como los puntos de función es que ahora se pueden establecer objetivos relacionados con las mejoras que se desean conseguir mediante inversiones. Por ejemplo, deseo reducir el número de defectos por punto de función en un 20% para el punto de vista de aplicaciones cliente. Gracias al análisis de defectos por cada punto de función podemos disponer de una herramienta de gran eficacia para mejorar nuestro proceso de desarrollo de productos, dado que nos ayuda a determinar dónde se encuentran los cuellos de botella y, por lo tanto, dónde invertir y cómo hacerlo para obtener mejores resultados.

Las métricas básicas de las que hemos hablado pueden indicarle algo para su próximo proyecto, o incluso para el actual si aún quedan tareas de desarrollo pendientes y éstas afectan a los puntos de vista evaluados. Por ejemplo, supongamos que tras recopilar los requisitos y aplicar el análisis basado en puntos de función, sabe que el nuevo sistema va a tener 750 puntos de función. Ahora puede predecir que la implementación de esos requisitos supondría alrededor de 9.750 horas de trabajo, y que se detectarán en torno a 75 errores durante las pruebas de aceptación por parte de los usuarios.

La precisión de estas predicciones depende mucho del nivel de las métricas recopiladas y de la similitud de los futuros proyectos de desarrollo del sistema con los que ha trabajado y para los que ha recopilado métricas. Cada punto de vista de una fábrica de software admite un cierto margen de variabilidad en el desarrollo del sistema. A su vez, el grado de variabilidad determina qué clases de activos puede ofrecer el punto de vista al usuario de la fábrica y, por lo tanto, el nivel de coherencia entre un proyecto y el siguiente por lo que respecta a ese aspecto del producto. Por ejemplo, en la primera versión de nuestra fábrica, quizá sólo haya algunos puntos de vista en los que se describa la arquitectura del sistema y que proporcionen únicamente instrucciones para los desarrolladores acerca de la puesta en práctica de la implementación. Los desarrolladores que usen esta fábrica deberán escribir una gran cantidad de código manualmente. Sin embargo, tras crear varios sistemas con esta fábrica, es posible que la construcción de la parte de la interfaz de usuario de esos sistemas tienda a variar considerablemente, ya que los desarrolladores interpretan las indicaciones de maneras muy distintas. A partir de esa observación, podría llegar a la conclusión de que el punto de vista de interfaz de usuario admite un amplio margen de variabilidad. Cuando tiene en la fábrica muchos puntos de vista con una gran variabilidad, las medidas y predicciones serán menos precisas que cuando la variabilidad de los puntos de vista es muy limitada.

Llegados a este punto, podríamos preguntarnos si el nivel de variabilidad asociado a un punto de vista determinado es realmente necesario. Si no es así, podríamos aumentar la precisión de nuestras medidas y predicciones quitando la variabilidad sobrante o gratuita. Fijémonos de nuevo en el punto de vista de interfaz de usuario, por ejemplo; pero esta vez, proporcionaremos un conjunto de componentes de biblioteca compatibles con las instrucciones y una herramienta gráfica que configure las rutas de navegación de los usuarios. Al proporcionar estos activos, formalizamos algunos aspectos del proceso de desarrollo de la interfaz de usuario que antes se definían de un modo menos estricto. Con esta formalización se reduce el margen de variabilidad que admite el punto de vista de interfaz de usuario. Los sistemas que se desarrollen con esta fábrica presentarán una mayor uniformidad en la creación de la interfaz de usuario, de modo que nuestras medidas y predicciones resultarán más precisas. Dado que la magnitud de los errores en los cálculos se reduce cuando disminuye la variabilidad que admite la fábrica, la capacidad de predicción puede mejorar con la evolución de la fábrica hacia una reducción de la variabilidad excesiva o innecesaria. En la práctica, la productividad y la calidad también tienden a mejorar con una mayor capacidad de predicción, dado que la reducción de variabilidad comporta una disminución del tiempo necesario para crear una determinada característica, así como del número de defectos. En este punto, se impone una llamada a la prudencia: Según el razonamiento de la navaja de Occam, la variabilidad debe reducirse en la medida de lo posible, pero nunca hasta tal punto que el proyecto se prolongue o sea más costoso debido a las restricciones impuestas a los desarrolladores.

Cuando empiece a usar puntos de función, al principio puede recurrir a datos históricos de organizaciones del entorno que figuren en la documentación de que disponga para realizar sus primeras estimaciones. Los datos históricos resultan útiles porque incluyen las influencias de la organización (tanto reconocidas como no). La misma idea se aplica al uso de datos históricos en la fábrica de software. Los proyectos desarrollados con una fábrica de software tendrán mucho en común. Aunque no cuente con datos históricos de proyectos anteriores, puede recopilar datos de su proyecto actual y usarlos como base para calcular la parte restante del proyecto. Su objetivo debería ser una transición lo más rápida posible desde el uso de datos de organización o "estándar" para el sector a datos de fábrica y de proyecto (McConnell, 2006).

Uso de medidas para mejorar una fábrica

Al establecer una línea de base o calibrar efectivamente los parámetros de productividad y calidad medidos en horas por punto de función y defectos por punto de función, tiene la posibilidad de analizar los datos de proyecto e identificar actividades que puedan requerir mucho tiempo, o bien puntos de vista que suelan tener asociados muchos defectos. Tras la calibración puede empezar a cambiar la organización de su fábrica y mejorarla de diversas formas; por ejemplo, las técnicas que requiere, el proceso que define o los activos reutilizables que proporciona. Es esencial identificar las áreas en las que se precisan mejoras, de modo que la orientación de las inversiones resulte acertada. Sin embargo, eso debería ser relativamente sencillo, ahora que dispone de un medio para determinar la contribución de cada punto de vista en términos de capacidad de previsión, productividad y calidad. Cuando disponga de una línea de base con datos iniciales, puede ejecutar un bucle continuo para analizar el rendimiento de cada punto de vista, usar esa información para determinar qué se debe mejorar, realizar las mejoras y después repetir el proceso.

Este ciclo virtuoso puede servir para diversas medidas. Por ejemplo, con el fin de aumentar la productividad puede identificar el punto de vista menos eficaz en términos de horas/punto de función y mejorarlo brindando más o mejores instrucciones o recursos para el aprendizaje, mejorando las plantillas que se usan para crear cortes iniciales de los productos de trabajo, proporcionando herramientas especializadas que automaticen la creación y modificación de los productos de trabajo, etc. Una de las partes clave de este proceso consiste en calcular el costo que supone realizar una mejora determinada, el aumento de productividad derivado y si los resultados justifican la inversión. Después de implementar la mejora e incorporarla en la fábrica, puede determinar si se cumplieron los objetivos establecidos, en términos de reducción en horas/punto de función. En la figura 2 se ilustra este proceso.

Figura 2. Bucle de iteración para el desarrollo de fábrica

Aplicación de Visual Studio Team System

Ahora que sabemos cómo definir una fábrica y cómo usar medidas y análisis para mejorarla con iteraciones, podemos plantearnos cómo facilitar a nuestro equipo de desarrollo de productos el uso de la fábrica para crear los productos de trabajo requeridos. Este proceso se inicia con un entorno de desarrollo válido para todo el ciclo de vida del producto, desde su nacimiento hasta que se deja de producir, como es el caso de Visual Studio Team System. El uso de Team System permite a los equipos de desarrollo de productos aprovechar las ventajas del enfoque descrito anteriormente.

Team System consta básicamente de dos partes. Las ediciones de Visual Studio Team (para arquitectos, desarrolladores y pruebas) instaladas en el equipo de desarrollo forman parte del IDE de desarrollo de Visual Studio y proporcionan herramientas para funciones específicas de su equipo de desarrollo. La segunda parte corresponde a Team Foundation Server (TFS), que aloja aspectos básicos del ciclo de vida de Team System, como el control de versiones, el seguimiento de elementos de trabajo, Team Build, el portal de Team y el almacén de datos, que contiene datos acerca de los proyectos que usan TFS.

Implementación de una fábrica con Team System

Actualmente, Team System no puede interpretar las fábricas de software. No obstante, dada las posibilidades de configuración y extensibilidad que ofrece Team System, puede configurarse manualmente para que admita una fábrica de software si asignamos distintas partes del esquema de fábrica a diversos elementos de configuración o puntos de extensión.

Recuerde que una fábrica de software contiene un esquema que describe su organización. Como hemos visto, el esquema de fábrica define un conjunto de puntos de vista interrelacionados, cada uno de los cuales describe productos de trabajo, actividades y activos relacionados para los usuarios de una función determinada. Podemos usar esta información para configurar Team System con objeto de desarrollar aplicaciones.

Un punto de vista se puede asignar en una o varias iteraciones a un concepto que en Team System se denomina área. La función asociada a un punto de vista se puede asignar a una o varias funciones de proyecto de Team System. En la práctica es probable que se asignen varias funciones de punto de vista a una sola función de proyecto de Team System. Las actividades definidas por un punto de vista se pueden agregar como elementos de trabajo en esas áreas durante la creación del proyecto, y asignarse directamente a la función correspondiente. También se pueden documentar personalizando las indicaciones sobre el proceso, y existe la posibilidad de crear tipos de elementos de trabajo personalizados para realizar un seguimiento y vincularlos a productos de trabajo. Algunos de los productos de trabajo se pueden describir mediante tipos de elementos de trabajo personalizados. Los activos de contenido, como las instrucciones, los patrones y las plantillas se pueden agregar a las bibliotecas de documentos del portal del proyecto. Los activos ejecutables, como las bibliotecas de clases y las herramientas, se pueden colocar en el sistema de control de versiones. Para medir y mejorar el rendimiento de nuestra fábrica podemos agregar métricas al almacén de datos de Team Foundation.

Las claves para configurar Team System son el asistente para la creación de proyectos y la plantilla de procesos. El asistente para la creación de proyectos es una herramienta diseñada para crear proyectos en TFS. Usa un archivo seleccionado por el usuario que se denomina plantilla de procesos con el fin de configurar el servidor para el proyecto. La plantilla contiene varias secciones, cada una de las cuales describe de qué modo se configurará una parte determinada del servidor. Por ejemplo, con la plantilla de procesos puede definir tipos de elementos de trabajo, personalizar el control de versiones, definir áreas e iteraciones, definir funciones, asignar los permisos apropiados a cada función, configurar el portal del proyecto y realizar otras muchas operaciones para personalizar el entorno y el proceso de desarrollo.

Examinemos cómo se usa el asistente para la creación de proyectos y la plantilla de procesos en la configuración de Team System para una fábrica de software.

Definición de elementos de trabajo

Team System usa elementos de trabajo para realizar un seguimiento de las operaciones que deben llevarse a cabo para crear un determinado producto. Los elementos de trabajo describen las tareas que deben ejecutarse e identifican quién es responsable de ese trabajo en cada momento. Los elementos de trabajo pueden ser de distintos tipos, diseñados para describir diferentes clases de trabajo. Por ejemplo, un error de software puede ser descrito por un elemento de trabajo de tipo defecto que contenga información pertinente a la solución de un error (como la descripción del error, los pasos para reproducirlo, el tiempo estimado para analizar o solucionar el error, etc.). Los tipos de elementos de trabajo se crean o modifican cambiando las definiciones XML cargadas en el servidor y se usan en el momento de la creación del proyecto. También se pueden modificar después de la configuración del proyecto.

Algunos tipos de elementos de trabajo definidos por MSF para la mejora de procesos CMMI, como los de error y requisito, describen productos de trabajo. Un tipo de elemento de trabajo, el de tarea, describe las actividades realizadas para cambiar el estado del producto de trabajo. Ambos tipos se pueden usar con eficacia en una fábrica, porque coinciden en buena medida con los conceptos usados para definir la fábrica. Podemos reservar específicamente elementos de trabajo para los productos de trabajo definidos por un punto de vista, y tareas para las actividades asociadas. Con estos elementos de trabajo es posible recopilar información acerca del tiempo dedicado a cada actividad y averiguar las repercusiones que tiene la actividad en la productividad de la fábrica.

Uno de los problemas que surgen al realizar esta asignación es que, actualmente, los elementos de trabajo no se anidan. La imposibilidad de anidar elementos de trabajo dificulta la descripción de los productos de trabajo de puntos de vista agregados o compuestos, como el punto de vista de acceso a datos tratado anteriormente. También comprobará que muchos productos de trabajo no son descritos explícitamente por elementos de trabajo en un proyecto de equipo típico. Por ejemplo, en lugar de crear un elemento de trabajo para describir una biblioteca de acceso a datos, podríamos crear un elemento de trabajo para describir la creación de una biblioteca de acceso a datos y después vincular el elemento de trabajo a los archivos de origen para la biblioteca en el sistema de administración de configuraciones. Otro problema es que las tareas de Team System no incluyen condiciones previas ni posteriores como actividades en una fábrica, por lo que los criterios para moverlas dentro o fuera del ámbito no están documentados y las decisiones de programación deben llevarse a cabo manualmente.

Definición de áreas e iteraciones

Los elementos de trabajo se pueden vincular a lo que se denomina un área del proyecto, así como a una iteración. Las áreas proporcionan un medio para reservar el trabajo en una parte determinada de la solución que sea de interés cuando desea ejecutar informes sobre los datos acumulados en el almacén de datos. Las áreas de Team System corresponden en buena medida al concepto que representan los puntos de vista en una fábrica de software, dado que en ambos casos se representan áreas de interés.

Cuando registre el trabajo realizado en áreas de interés determinadas, puede averiguar cuáles contienen más errores o consumen más tiempo. Al asignar áreas de interés en el seguimiento de elementos de trabajo a los puntos de vista de su fábrica, puede usar estas métricas para proporcionar las medidas de productividad y calidad en puntos de vista determinados.

Para obtener información adecuada de los elementos de trabajo, debe definir correctamente las áreas e iteraciones cuando empiece el desarrollo del producto. Una fábrica simplifica esta tarea al definir los puntos de vista de interés para el tipo de producto que se desarrolla. Todo lo que debe hacerse para configurar las áreas correctamente es definir un área para cada punto de vista. Quizá después tenga que asignar los nombres de los puntos de vista a nombres de áreas que resulten familiares para el equipo de desarrollo, de modo que puedan identificar rápidamente el área a la que pertenece un elemento de trabajo determinado.

Un buen punto de partida a la hora de definir puntos de partida para una fábrica es un conjunto de puntos de vista comunes que tiendan a aparecer en un gran número de fábricas. Pueden encontrarse buenos ejemplos de puntos de vista comunes en el esquema de la fábrica de software de colaboración empresarial (consulte la sección que se encuentra al final de este artículo). Dos de esos puntos de vista comunes que resultan especialmente útiles para la configuración de Team System son el de ingeniería de sistemas y el de ingeniería de proyectos. En el área de ingeniería de sistemas debe crear un subárbol que contenga los puntos de vista de arquitectura en los que se describan las partes destacadas del sistema. Esto le ayudará a identificar qué partes del sistema tienen mayor repercusión en la productividad (tiempo dedicado) y en la calidad (número de defectos). El área de ingeniería de proyectos también es interesante, ya que puede ayudarle a detectar anomalías en el modo de formalizar actividades del proyecto, así como a decidir si debe mejorarse o no la definición del proceso en determinados puntos. En la figura 3 se muestra un ejemplo de áreas e iteraciones que refleja el esquema de una fábrica simple con la que se crea una aplicación administrativa de servicios con varios clientes.

Figura 3. Ejemplo de definición de área en la que se reflejan puntos de vista

Las áreas que defina para el seguimiento de elementos de trabajo evolucionarán junto con la fábrica. A medida que madure la fábrica, cambiará el conjunto de puntos de vista que componen su esquema, al igual que el conjunto de puntos de vista que desea medir. El árbol de las áreas puede llegar extenderse considerablemente si intenta incorporar todos los puntos de vista definidos por su fábrica. Es muy importante que no amplíe demasiado el árbol con un gran número de niveles. Tenga en cuenta que debe ser muy simple para que los miembros del equipo puedan identificar fácilmente las áreas a las que se deben vincular los elementos de trabajo. Cuanto mayor sea el anidamiento en el árbol, más difícil resultará encontrar el área adecuada para un elemento de trabajo determinado. Si la localización es poco evidente, los desarrolladores se limitarán a reservar elementos de trabajo situados junto a la raíz de la jerarquía, con lo que la creación del árbol con un anidamiento profundo resultará contraproducente.

Definición de funciones

Las funciones que cree en Team System deben reflejar todas las identificadas a través de los puntos de vista en el esquema de fábrica. Las funciones no tienen que ser exactamente las mismas que se identifican mediante los puntos de vista, aunque cada función del producto debe corresponder a una o varias funciones identificadas por medio de los puntos de vista. Dado que las funciones identificadas mediante los puntos de vista suelen ser más detalladas que las definidas para un proyecto, una función de proyecto suele implementar varias funciones de punto de vista relacionadas.

Configuración de características de productos

Modificando el asistente y la plantilla de procesos puede habilitar la configuración más allá de lo que permiten el asistente predeterminado y las plantillas de proceso que se incluyen con TFS. De hecho, puede crear páginas personalizadas del asistente que permitan al usuario configurar algunas de las características variables definidas por la fábrica. Si retomamos el ejemplo anterior de un bloque de creación para el acceso a datos configurado de modo que use distintos productos de base de datos, podría preguntar al usuario qué producto de base de datos desea usar y después colocar una versión del bloque de creación previamente configurado para ese producto en el control de versiones como punto de partida para el proyecto. Si tenemos en cuenta que las fábricas de software suelen requerir tareas de configuración a lo largo del proceso de desarrollo, la personalización del asistente para la creación de proyectos y el formato de la plantilla de procesos constituyen un buen punto de partida. En la figura 4 se muestra cómo se puede configurar el modelo de características que se muestra en la figura 3 mediante una página de asistente personalizada.

El asistente para la creación de proyectos ofrece un magnífico punto de extensibilidad totalmente compatible con el concepto de búsqueda de activos con similitudes en la fábrica de software. Desarrolle estos activos por separado. Defina la distinta variabilidad que necesitaría para la reutilización del activo y use una página de asistente para preguntar al usuario cómo deben establecerse la variables en este proyecto en particular. El asistente podrá realizar la personalización con arreglo a la entrada, y adaptar el activo a las necesidades del proyecto. Si bien el concepto de similitudes y variabilidad en las fábricas de software va más allá de la configuración previa de estos activos, éste puede ser el punto de partida para la personalización. Tras la configuración de un activo seleccionado, la fábrica podría proporcionar también una herramienta de configuración adicional para cambiar las configuraciones seleccionadas después de la configuración inicial del proyecto.

En una fábrica, usaría los modelos de características que se han mostrado anteriormente para describir las características que podría desear, la forma en que determinadas decisiones sobre una característica pueden afectar a otras características, y la forma en que se crea la instancia de la fábrica. Como vimos en el ejemplo de la figura 1, es posible crear un modelo de características que se asemeje a un conjunto de características para una fábrica orientada al desarrollo de una aplicación administrativa con SOA.

En la figura 4 se muestra cómo se puede reflejar este modelo en una página de asistente personalizada que le permita realizar una configuración previa de la fábrica.

Figura 4. Página personalizada del asistente para proyectos

Hay al menos dos formas más de facilitar la configuración en la preparación del proyecto de equipo, además del asistente para la creación de proyectos. Puede personalizar el repositorio de control de versiones para anticipar decisiones importantes sobre la configuración que se tomarán durante el desarrollo de la solución, de modo que resulte fácil guardar el estado de la solución en la administración de configuraciones antes de que se tomen todas las decisiones, y restaurarlo posteriormente si cambia de decisión. Esta técnica se conoce como retroceso. También puede definir tipos de elemento de trabajo que capturen decisiones de configuración y después agregar instancias de esos tipos a la base de datos de seguimiento de elementos de trabajo cuando se tomen las decisiones, a fin de capturar los resultados, así como para programar el trabajo resultante.

Personalización del portal del proyecto

Team System incluye un portal de proyecto que puede usar el equipo de desarrollo para compartir información sobre el proyecto. El portal es también el punto de entrada a la orientación sobre procesos para una plantilla de procesos determinada, así como a activos reutilizables, como plantillas e instrucciones. Los activos reutilizables que se deben cargar en el portal son suministrados por la plantilla de procesos. También puede cambiar el contenido que se muestra en el sitio web de orientación sobre procesos. Esta personalización se realiza mediante un documento de InfoPath. El documento de InfoPath se compila para crear un nuevo sitio web que se puede incorporar en la plantilla de procesos. Tras cargar la nueva plantilla de procesos, puede crear proyectos de equipo que usen el sitio web personalizado de orientación sobre procesos.

Adición de medidas al almacén de datos

El almacén de datos de Team System realiza un seguimiento de toda clase de información relacionada con el desarrollo de la solución. Una sección del almacén de datos contiene información acerca de elementos de trabajo, lo que resulta interesante por lo que respecta la fábrica, según se describía anteriormente. Otras secciones contienen información acerca de pruebas, compilaciones diarias y otras características de Team System. El almacén de datos puede extenderse de dos maneras para facilitar las medidas.

En primer lugar, es posible cambiar los campos del almacén de un tipo de elemento de trabajo determinado si modifica la definición del tipo de elemento de trabajo, cambia los campos que contiene o agrega los campos a nuevos hechos o dimensiones del almacén. Cuando se puede informar de un campo según la definición del tipo de elemento de trabajo, se agregará dinámicamente al almacén de datos. Naturalmente, si desea mostrar informes con estos campos adicionales, también deberá crear informes de los datos y cargarlos en el servidor de generación de informes, de modo que resulten accesibles para otros miembros del equipo.

En segundo lugar, puede incorporar datos generados mediante herramientas personalizadas. Si su fábrica proporciona herramientas personalizadas que generan datos y desea usar los datos del almacén, puede agregar un adaptador personalizado de almacén de datos a TFS, tal como se muestra en la figura 5.

Figura 5. Arquitectura de almacén de datos de Team Foundation Server

Por ejemplo, para medir el tamaño de cada solución en líneas de código, crearía una herramienta personalizada que cuente las líneas de código del archivo y un adaptador personalizado de almacén de datos. También agregaría un paso a la creación diaria que ejecuta su herramienta personalizada sobre los orígenes en la solución actual y coloca el resultado en un archivo. El adaptador de almacén de datos personalizado tomaría la información de archivo y realizaría llamadas al modelo de objetos de almacén de datos que proporciona Team System para agregar la información al almacén de datos. Los datos personalizados se pueden ver mediante informes personalizados.

Uso de construcciones de medidas (ISO 15939)

Hasta ahora hemos visto cómo se define una fábrica, cómo se mejora mediante medidas y análisis, y cómo se configura Team System para la compatibilidad con una fábrica. Antes de poder combinar todos esos conocimientos en la creación y mejora de fábricas de software con Team System, debemos saber algo más: cómo recopilar la información adecuada.

Lo que necesitamos son decisiones formales de las relaciones entre lo que estamos midiendo y la información de lo que se precisa para posibilitar las mejoras. Esas definiciones se conocen como construcciones de medidas. Las construcciones de medidas son combinaciones de medidas de base, medidas derivadas e indicadores. Una medida de base captura información acerca de un atributo individual de alguna entidad de software a través de un método de medida especificado, y es independiente de todas las demás medidas desde el punto de vista funcional. Una medida derivada se define como una función de dos o más medidas de base o derivadas, y captura información acerca de más de un atributo. Un indicador es una medida que proporciona un cálculo o una evaluación mediante la aplicación de un modelo analítico a una o varias medidas de base o derivadas, con objeto de responder a determinadas necesidades de información. Los indicadores constituyen la base para el análisis de las medidas y la toma de decisiones. Una construcción de medidas describe una necesidad de información, entidades y atributos relevantes, medidas de base y derivadas, indicadores y el procedimiento de recopilación de datos. Es posible agregar reglas, modelos y criterios de decisión adicionales a las medidas de base y derivadas, así como a los indicadores. En la figura 6 se ilustran las estructuras de una construcción de medidas (McGarry, 2002).

Figura 6. Estructura de una construcción de medidas

Los términos clave acerca de las medidas de software y los métodos de medida se definen en ISO/IEC 15939 sobre la base del vocabulario internacional de metrología de la ISO. Los términos que se usan en este artículo derivan de ISO 15939 y PSM (Practical Software Measurement, medida práctica de software).

Definición de una construcción de medidas

Para definir una construcción de medidas que se pueda agregar a nuestro almacén de datos de TFS seguiremos estos pasos:

  • Definición y clasificación de las necesidades de información
    Para asegurarnos de que medimos la información que necesitamos, debemos tener claramente definidas nuestras necesidades de información y qué relación guardan con la información que medimos. La experiencia demuestra que la mayoría de las necesidades de información en el desarrollo de software se pueden agrupar en una de las siete categorías definidas en ISO 15939: programación y progreso, recursos y costo, tamaño del producto y estabilidad, calidad del producto, rendimiento del proceso, eficacia de la tecnología y satisfacción del cliente. Un ejemplo de necesidad de información en la categoría de tamaño y estabilidad del producto podría ser "Evaluar el tamaño de un producto de software para valorar el cálculo presupuestario inicial".
    Estas necesidades de información pueden usarse para medir las propiedades de un punto de vista específico en una fábrica de software. Deben priorizarse como garantía para que el programa de medidas se centre en las necesidades con el máximo potencial de impacto en los objetivos que hemos definido. Tal como describíamos anteriormente, nuestro objetivo principal suele ser identificar los puntos de vista cuya mejora reporte el máximo rendimiento de la inversión. Puesto que los puntos de vista se pueden anidar, con frecuencia podemos realizar medidas en puntos de vista de niveles superiores. Por ejemplo, si tuviéramos un punto de vista de interfaz de usuario con puntos de vista tales como desarrollo de elementos web y autorización de usuarios, podríamos llevar las medidas encaminadas a la satisfacción del cliente de elementos web específicos al nivel de interfaz de usuario.

  • Definición de entidades y atributos
    Un atributo medible es una propiedad diferenciable de una entidad de software. Las entidades relevantes con arreglo a la necesidad de información ("Evaluar el tamaño de un producto de software para la estimación del presupuestario original", por ejemplo) podrían ser un plan o un programa de desarrollo, y un conjunto de archivos de origen con una línea de base. Los atributos podrían ser puntos de función para los que se haya planeado una ejecución en cada período, líneas de código y una tabla de expresividad para los lenguajes de programación usados.

  • Definición de medidas de base y derivadas
    Las medidas de base son independientes desde el punto de vista funcional de todas las demás medidas y capturan información acerca de un solo atributo. La especificación del intervalo o del tipo de valores que puede asumir una medida de base ayuda a comprobar la calidad de los datos recopilados. En nuestro ejemplo tenemos dos medidas de base: el tamaño estimado del producto de software y el tamaño real. La escala para ambas medidas de base se encontrará entre cero e infinito. Una medida derivada captura información acerca de más de un atributo. Estos términos se ilustran en la figura 7.

    Figura 7. Aumento de tamaño del software en medidas de base y derivadas

  • Especificación de indicadores
    Los indicadores constituyen la base para el análisis de las medidas y la toma de decisiones. Son valores de medidas que se presentan a los usuarios. Para usar un indicador correctamente, sus usuarios deben comprender la relación existente entre la medida en que se basa y las tendencias que revela. Por lo tanto, la construcción de medidas deberá proporcionar la siguiente información para cada indicador:

    • Instrucciones para analizar la información. Para nuestro ejemplo podríamos proporcionar instrucciones sobre el análisis como la siguiente: "El crecimiento de la relación de aumento de tamaño del software indica un creciente riesgo para el ajuste de los presupuestos en costos y programación".

    • Instrucciones para la toma de decisiones a partir de la información. Para nuestro ejemplo podríamos proporcionar directrices de toma de decisiones como éstas: "Investigar cuando la relación de aumento de tamaño del software presente una variación superior al 20%".

    • Una ilustración de cómo se interpreta el indicador. Para nuestro ejemplo podríamos proporcionar una ilustración como la de la figura 8 y describir lo siguiente: "El indicador parece sugerir que la tasa de producción del proyecto va por delante de la programación. Sin embargo, tras una investigación más exhaustiva, el tamaño real de un elemento era mayor que el previsto, debido a que faltaban requisitos y no se detectó hasta las pruebas iniciales. Las asignaciones de recursos, las programaciones, los presupuestos, así como las programaciones y los planes de pruebas se ven afectados por este crecimiento inesperado".

    Figura 8. Indicador de representación gráfica, comparación de crecimiento de software previsto y real

  • Definición del procedimiento de recopilación de datos
    Ahora que sabemos cómo relacionar las medidas de base con las necesidades de información, debemos definir el procedimiento de recopilación de datos. Mediante el procedimiento de recopilación de datos se especifican la frecuencia de la recopilación de datos, la persona responsable, la fase o actividad en que se recopilarán los datos, las reglas de comprobación y validación, las herramientas usadas para la recopilación de datos y el repositorio de los datos recopilados.

Uso de una construcción de medidas

Para usar correctamente una construcción de medidas, debemos resolver dos problemas importantes: la influencia de los indicadores y la necesidad de evitar medidas disfuncionales.

Influencia de los indicadores

Para usar los indicadores correctamente en los procesos de análisis de medidas, toma de decisiones y cambios, debe asegurarse de que los usuarios sepan lo que representan, cómo interpretarlos y qué se puede cambiar para influir en sus resultados. En nuestro ejemplo, el usuario debe comprender que, para que el tamaño real en puntos de función se ajuste al tamaño planeado, debemos producir más puntos de función en el mismo tiempo (es decir, debemos ser más productivos). El usuario también debe comprender de qué modo se puede aumentar la productividad.

Cómo evitar medidas disfuncionales

Los responsables de la toma de decisiones también deben saber evitar las medidas disfuncionales. El objetivo de las medidas es mejorar el rendimiento a través de cambios, tales como la realización de actividades distintas, la aplicación de otros activos, etc. Es importante asegurarse de que los cambios tengan sentido. Nadie desea que se realicen cambios contraproducentes para conseguir un resultado esperado con alguna medida. En nuestro ejemplo, la presión para alcanzar el tamaño planeado en puntos de función podría impulsar a algunos desarrolladores a rellenar la implementación con líneas de código adicionales. La identificación y descripción de riesgos es una de las claves para que las medidas sean correctas. Una práctica recomendada consiste en evitar medidas centradas en individuos. Cuanta mayor importancia se dé a cualquier indicador social cuantitativo, más probable es que se distorsionen y alteren los procesos que se pretende mejorar.

Integración

Finalmente, estamos preparados para combinar todo lo que hemos aprendido y comentado sobre la definición y el uso de construcciones de medidas para mejorar una fábrica de software compatible con Team System.

Adición de construcciones de medidas al almacén de datos

Según lo descrito, en cada construcción de medidas se deben definir al menos las necesidades de información, las entidades y atributos, las medidas de base y derivadas, los indicadores y el procedimiento de recopilación de datos. Para asignar todo esto al almacén de datos de Team System, debemos determinar cómo se obtiene la información necesaria, ya sea modificando las definiciones de tipos de elementos de trabajo para agregar campos y marcarlos como hechos o dimensiones, o bien creando una herramienta personalizada y un adaptador de almacén de datos personalizado que recopile los datos producidos por la herramienta. También debemos determinar cómo se mostrarán los indicadores; normalmente, a través de la creación de informes con Microsoft SQL Server 2005 Reporting Services.

Mejoras iterativas

Cuando se ha asignado la fábrica a Team System, puede empezar a usarse para crear soluciones. Guiará a su equipo en la creación de las soluciones y le proporcionará información a partir de las construcciones de medidas que haya definido e implementado. A partir de ahí, puede comenzar a analizar las medidas y a usar los indicadores para identificar oportunidades de introducir mejoras. Esta información le permitirá decidir qué puntos de vista se pueden mejorar, qué se gana mejorándolos y a cuánto asciende la inversión. Por último, puede llevar a cabo las mejoras que haya decidido; por lo general, agregando instrucciones y proporcionando mejores activos para la creación de productos de trabajo. Al crear soluciones con estas mejoras, puede usar nuevamente medidas e indicadores para comparar los progresos obtenidos con los esperados, y calibrar así la planificación de sus inversiones.

Conclusión

El motivo de este artículo radica en un deseo de superar la ineficacia en la forma que tenemos actualmente de crear software, a través del desarrollo de proyectos de un modo aislado. Nuestros clientes ven que procuramos entregar los proyectos con puntualidad, sin salirnos del presupuesto y sin sacrificar características. Podemos ayudarnos como profesionales y al sector en su conjunto aprovechando los conocimientos adquiridos a través de la experiencia y transfiriéndolos a otros proyectos a través de las fábricas de software. Hemos aprendido a definir una fábrica y a medir su rendimiento en términos de productividad y calidad.

A través de la cuantificación del tamaño de los productos que creamos, la medida del tiempo dedicado a crearlos y el registro del número de defectos detectados, podemos describir el rendimiento de nuestras fábricas. La asignación desde el esquema de fábrica a Team System se lleva a cabo mediante la personalización y los puntos de extensibilidad de Team System. Podemos configurar Team System colocando los activos identificados por el esquema de fábrica en el repositorio de control de versiones o en el portal de Team Foundation. Tenemos la posibilidad de usar el portal para proporcionar orientación sobre procesos en actividades descritas por el esquema de fábrica. Podemos usar el asistente para la creación de proyectos con objeto de organizar la configuración inicial de nuestra fábrica, y los modelos de características para crear una asignación que permita definir formularios que serán agregados al asistente. Una gran parte del proyecto inicial se lleva a cabo con las plantillas de procesos, las cuales se pueden modificar con arreglo a las necesidades de nuestras fábricas.

Mediante la definición de construcciones de medidas y su implementación en el almacén de datos de Team System, podemos recopilar métricas que describan el rendimiento de la fábrica de software en términos de productividad y calidad. Con el tiempo, estas métricas se pueden usar para mejorar nuestras fábricas de forma constante, así como para progresar no sólo en productividad y calidad, sino también en capacidad de previsión, al eliminar variaciones excesivas o innecesarias.

El resultado final de la implementación de fábricas de software con Visual Studio Team System es la ejecución mejorada de los proyectos y una mayor satisfacción de los clientes.

Referencias

Austin, Robert D. Measuring and Managing Performance in Organizations. Nueva York, NY: Dorset House Publishing Co., Inc., 1996.

Greenfield, Jack, y Keith Short. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Indianapolis, IN: Wiley Publishing, Inc., 2004

McConnell, Steve. Software Estimation: Demystifying the Black Art. Redmond, WA: Microsoft Press, 2006.

McGarry, John, et al. Practical Software Measurement: Objective Information for Decision Makers. Boston, MA: Addison-Wesley Professional, 2002.

Acerca de los autores

Marcel de Vries es arquitecto de TI en Info Support, con sede en los Países Bajos, así como MVP de Visual Studio Team System. Marcel es el arquitecto principal de la fábrica de software Endeavour, orientada a la creación de aplicaciones administrativas de servicios de empresa que usan numerosas corporaciones clientes de Info Support. Marcel es conferenciante habitual en diversos eventos que se celebran en los Países Bajos, como Tech-Ed Europe y diversas jornadas para desarrolladores. También trabaja a tiempo parcial como profesor para el centro de conocimientos de Info Support. Puede leer su blog en http://blogs.infosupport.com/marcelv/.

Jack Greenfield es arquitecto de herramientas y marcos de trabajo empresariales en Microsoft Corporation. Antes fue arquitecto jefe de Practitioner Desktop Group, en Rational Software Corporation, así como fundador y director técnico de InLine Software Corporation. En NeXT Computer desarrolló el marco de trabajo de objetos empresariales, que ahora forma parte de los objetos Web de Apple Computer, Inc. Conferenciante y escritor conocido, es coautor (con Keith Short, Steve Cook y Stuart Kent) de un libro galardonado y líder de ventas, Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Jack también ha contribuido en los proyectos UML, J2EE y las especificaciones OMG y JSP relacionadas. Es licenciado en Física por la Universidad George Mason.

Mostrar:
© 2014 Microsoft