Aspectos básicos relativos a Microsoft Visual Studio 2005 Team System

Visual Studio 2005

Septiembre de 2005

Publicado: 21 de Noviembre de 2005

Microsoft Corporation

Este artículo se aplica a:
Microsoft Visual Studio 2005 Team System

Resumen: en este artículo se ofrece información general relativa a las características de Microsoft Visual Studio Team System y se explica el modo en que éstas facilitan el proceso de desarrollo de software. (25 páginas impresas.)

En esta página

Introducción Introducción
Team System para Software Architects Team System para Software Architects
Team System para Software Developers Team System para Software Developers
Team System para Software Testers Team System para Software Testers
Team Foundation Server Team Foundation Server
Extensibilidad y personalización de Team System Extensibilidad y personalización de Team System
Conclusión Conclusión

Introducción

Afrontémoslo. Crear software de alta calidad en el plazo establecido y sin salirse del presupuesto resulta aún una tarea bastante complicada. ¿A qué se debe? En primer lugar, es necesario tener en cuenta que en el desarrollo de software no sólo intervienen los desarrolladores de software, sino que, de hecho, participan numerosos profesionales de otros campos. Será el modo en que estos coordinan sus esfuerzos lo que determinará el éxito del proyecto. Los equipos de proyecto suelen estar formados por jefes de proyectos, analistas empresariales, arquitectos, desarrolladores y comprobadores de aplicaciones. Desafortunadamente, en demasiadas ocasiones, los profesionales que participan en el desarrollo de software encuentran este tipo de proyectos atractivos e interesantes al tiempo que complejos, al no disponer de herramientas que les permitan aunar esfuerzos. ¿No sería maravilloso disponer de herramientas que al tiempo que permitieran a cada miembro del equipo aumentar su productividad, precisión y previsibilidad en el trabajo permitieran también compartir información y colaborar más fácilmente dentro de su ciclo vital de desarrollo de software establecido? Señoras y señores, permítanme presentarles a Microsoft Visual Studio Team System.

Visual Studio Team System es la nueva incorporación de Microsoft a la familia de Visual Studio. Se trata de un producto de gran importancia, ya que, por primera vez, Microsoft lanza al mercado un producto dirigido a todo el ciclo de vida del desarrollo de software. Basado en el conjunto de características de Microsoft Visual Studio 2005, Team System incluye características adicionales que facilitan el trabajo de los arquitectos, desarrolladores, comprobadores y jefes de proyecto. En la figura 1 se muestran las cuatro versiones de Team System, cada una de ellas destinada a una función determinada: Software Architects, Software Developers, Software Testers y Team Foundation.

Figura 1. Microsoft Visual Studio Team System

Team System ofrece un nuevo conjunto de herramientas que permite abarcar una perspectiva mucho más amplia del proceso de desarrollo de software. Asimismo, proporciona una plataforma que se puede personalizar en función del proceso en el que se trabaje, ampliar a nuevos procesos e integrar con otras herramientas y procesos existentes. En el resto del artículo se analizarán las características de Team System y se describirá el modo en que el producto puede resultar útil para un equipo de trabajo y un proceso de software determinado.

Team System para Software Architects

Las características de Team Architect fueron las primeras en salir al mercado en versión beta. Inicialmente se las conocía como "Whitehorse". Estas características, ahora denominadas diseñadores de sistemas distribuidos, integran en Visual Studio la fase de modelado como una capacidad nueva. Estos diseñadores no sólo permiten crear gráficos atractivos, sino que también permiten evaluar la implementación del diseño de la aplicación y el sistema antes de la escritura del código. Así, por ejemplo, los arquitectos de aplicaciones pueden diseñar y evaluar la implementación de aplicaciones orientadas a servicios y sistemas de aplicaciones. Por su parte, los arquitectos de infraestructuras pueden diseñar representaciones lógicas de los centros de datos en los que se implementarán estas aplicaciones. A continuación, ambos profesionales podrán trabajar con el fin de garantizar la compatibilidad del diseño de la aplicación y del centro de datos. El código escrito para implementar las aplicaciones permanecerá sincronizado con el diseño de la aplicación. Algunos de los elementos que se pueden modelar en Team Architect representan los esfuerzos iniciales de la iniciativa de sistemas dinámicos (DSI) de Microsoft. Para obtener más información sobre la DSI, consulte "Iniciativa de sistemas dinámicos" (en inglés).

Todos los diseñadores de sistemas distribuidos de Team Architect utilizan el modelo de definición del sistema (SDM), un tipo de formato basado en XML que almacena la definición del modelo. SDM incluye un lenguaje común en el que se pueden describir tanto los sistemas de aplicaciones como las infraestructuras de centros de datos. Este lenguaje mejora la comunicación entre los expertos de cada campo y permite validar una aplicación con el fin de determinar si ésta se podría implementar, así como ejecutar correctamente en un entorno de centro de datos de destino dado. En las secciones siguientes se describen los cuatro diseñadores de sistemas distribuidos que se pueden utilizar en Team Architect.

Diseñador de centros de datos lógicos

Normalmente, la infraestructura física de un centro de datos no resulta importante para un desarrollador que sólo necesita comprender el funcionamiento de los entornos que alojan las aplicaciones presentes, su configuración, restricciones y conexión. El diseñador de centros de datos lógicos se utiliza para crear un diagrama de centro de datos lógico, en el que no se muestran los equipos físicos ni los tipos de equipos en un centro de datos, sino que, en su lugar, se emplea para definir o documentar configuraciones específicas de software de servidor de aplicaciones, como Microsoft Internet Information Server, Microsoft SQL Server o Microsoft BizTalk Server, así como para mostrar el modo en que estas representaciones lógicas configuradas de servidores (de aplicaciones) están interconectadas. Los servidores lógicos se pueden agrupar en zonas que definen los límites lógicos de comunicación. Estas zonas se pueden configurar de modo que restrinjan los tipos de servidores lógicos que pueden contener, así como la dirección y los tipos de comunicación que pueden entrar y salir del centro de datos. En la tabla 1 se enumeran los elementos que el diseñador puede modelar. En la figura 2 se presenta un ejemplo sencillo de un diagrama de centro de datos lógico.

Tabla 1. Elementos del diseñador de centros de datos lógicos

Servidores lógicos

Descripción

WindowsClient

Un entorno host de aplicaciones de Windows, tal y como incluye el sistema operativo Windows. Windows Client se puede configurar para alojar aplicaciones de Windows, genéricas y de Office.

IISWebServer

Representa una configuración de Internet Information Server. IIS se puede configurar para alojar aplicaciones o servicios Web Microsoft ASP.NET, o cualquier otro tipo de aplicación genérica.

DatabaseServer

Representa un servidor de base de datos genérico que puede alojar una base de datos.

GenericServer

GenericServer representa un entorno host de aplicaciones al que no describen correctamente ninguno de los servidores lógicos predefinidos. Se utiliza normalmente para admitir el alojamiento de aplicaciones genéricas.

Zona

Un grupo de servidores lógicos.

Extremos

Los extremos representan puntos de comunicación en servidores lógicos o zonas. Los servidores lógicos pueden admitir extremos de cliente que permiten la comunicación desde el servidor y extremos de servidor que permiten la comunicación al servidor. Los extremos de zona se pueden considerar como "portales" a través de los cuales pueden pasar las comunicaciones entrantes y salientes de servidores o zonas. Los extremos de zona se pueden definir para permitir comunicaciones entrantes, salientes o bidireccionales y pueden restringir el tipo de comunicación permitida. Además de los extremos de zona, se admiten los formularios de cliente y servidor de los extremos siguientes: extremos de base de datos, HTTP, de sitio Web y genéricos.

Comentarios

Permite agregar descripciones de los elementos de diseño en la superficie del modelo

Figura 2. Diagrama de centro de datos lógico (haga clic en la imagen para aumentarla)

Una vez se han personalizado y agregado las propiedades a los servidores lógicos y las zonas del diagrama, se podrán agregar estas formas al cuadro de herramientas para su uso en el futuro. Para ello, se deberá seleccionar una o varias zonas o servidores, hacer clic con el botón secundario del mouse (ratón) y, a continuación, hacer clic en Agregar al cuadro de herramientas.

Para cada uno de los servidores lógicos o zonas del diagrama, se puede especificar también una configuración y un conjunto de restricciones (en el menú Ver, haga clic en Otras ventanas y, a continuación, en Configuración y restricciones). Aquí podrá especificar una directiva de características de funcionamiento para cada servidor que las aplicaciones que en ellos se implementen deberán cumplir. Por ejemplo, en la figura 3 se muestra el editor de configuración y restricciones de un servidor que como mecanismos de autenticación válidos sólo permite la autenticación por formularios y de Windows. En la lista de entradas seleccionadas, bajo el encabezado de restricciones, se observa que en este servidor se pueden ejecutar prácticamente todos los tipos de servicios, desde aplicaciones Web ASP.NET, hasta servicios Web BizTalk y aplicaciones genéricas. Se trata de un hecho que será necesario tener en cuenta cuando se hable del diseñador de implementación más adelante en este artículo. La herramienta también permite importar la configuración completa de IIS, incluidos los extremos de sitio Web, de un servidor existente. Para ello, se debe hacer clic con el botón secundario del mouse en el servidor local y, a continuación, hacer clic en Importar configuración.

Figura 3. Editor de configuración y restricciones (haga clic en la imagen para aumentarla)

Diseñador de aplicaciones

Cuando diseño la arquitectura de una solución nueva, lo primero que hago es intentar visualizar la solución en una pizarra. En ésta, voy mejorando el modelo hasta que considero que todo está listo para pasar a la fase de diseño, la descomposición funcional y, por último, la generación en sí de la aplicación. El diseñador de aplicaciones desempeñará una función de gran importancia en este proceso, ya que ahora puedo diseñar y configurar aplicaciones con una herramienta que "comprende" lo que creo (desafortunadamente, mis pizarras "no llegan a entenderlo"). A través del diagrama de aplicaciones, puedo descomponer la solución en varias aplicaciones (unidades de código que se pueden implementar de forma discreta, como un servicio Web, un cliente inteligente o un sitio Web). En la tabla 2 se muestran algunos de los elementos que puedo utilizar para diseñar aplicaciones en el diagrama de aplicaciones. En la figura 4, por su parte, se muestra un diagrama de aplicaciones sencillo.

Tabla 2. Elementos del diseñador de aplicaciones

Elemento de diseño

Descripción

Windows Application

Una aplicación de tipo de consola o Microsoft Windows Forms.

Aplicación Web ASP.NET

Una aplicación Web ASP.NET que puede presentar extremos de servicio Web y/o de contenido Web. Se presentan dos elementos de cuadro de herramientas que crean una aplicación ASP.NET y un extremo de contenido Web predeterminado.

Aplicación de Office

Una aplicación que se integra con una aplicación de Microsoft Office, como Microsoft Word o Microsoft Excel.

Servicio Web externo

Un servicio Web consumido por una aplicación y ubicado fuera de la solución. Se debe especificar la URL del servicio Web que se representa.

Base de datos externa

Una base de datos consumida por una aplicación de la solución. Se puede proporcionar la cadena de conexión de la base de datos que se representa.

Servicio Web BizTalk

Un servicio Web BizTalk. Se debe especificar la URL del servicio Web que se representa.

Aplicación genérica

Cualquier otro tipo de aplicación que interactúa con la solución, pero que no presenta un elemento de diseño asociado. Por ejemplo, un elemento de diseño de una aplicación genérica se puede utilizar para modelar una aplicación heredada.

Extremo de servicio Web

Un punto de entrada de servicio Web en una aplicación

[Text]

[Text]

Extremo de contenido Web

Un punto de entrada de contenido Web en un elemento de diseño de una aplicación Web ASP.NET.

Extremo genérico

Un extremo genérico utilizado para representar un punto de conexión en una aplicación de un tipo no modelado específicamente. Los extremos genéricos se pueden agregar a cualquier tipo de aplicación.

Comentarios

Un marcador que permite agregar descripciones de los elementos de diseño a la superficie del diagrama.

Figura 4. Diagrama de aplicaciones (haga clic en la imagen para aumentarla)

Al igual que el diseñador del centro de datos lógico, se pueden agregar restricciones y propiedades adicionales a las definiciones y extremos de la aplicación, a través del editor de configuración y restricciones. Estas restricciones especifican los requisitos de implementación de la aplicación y restringen los tipos de servidores lógicos en los que se puede implementar una aplicación determinada. El diseñador de aplicaciones también permite definir operaciones para servicios Web. Por ejemplo, se puede seleccionar un extremo de proveedor de servicio Web en una aplicación Web ASP.NET y utilizar la ventana de detalles de servicio Web para definir los métodos y parámetros que definen la interfaz del servicio Web.

La mayoría de los tipos de aplicaciones suministrados admiten la implementación y sincronización con código. Al hacer clic con el botón secundario del mouse en una aplicación, como una aplicación de Windows o una aplicación Web ASP.NET, o al hacer clic con el botón secundario del mouse en el diagrama de aplicaciones y hacer clic en Implementar aplicación o Implementar todas las aplicaciones, Visual Studio crea proyectos para las aplicaciones seleccionadas en función de los tipos y el idioma especificados: Microsoft Visual Basic, Microsoft Visual C# o Microsoft Visual J#. Si las aplicaciones están conectadas en el diagrama, Visual Studio también enlaza las aplicaciones, lo que crea referencias Web y rellena las entradas de configuración requeridas. Si la solución ya existe, o si tan sólo se prefiere definir las aplicaciones directamente en el código, simplemente con agregar el diagrama de la aplicación a una solución éste se somete a ingeniería inversa a partir del proyecto, código y archivos de configuración. Una vez se dispone de un diagrama de aplicación en una solución con proyectos y código, Visual Studio mantiene el diagrama y los modelos SDM en sincronización con el proyecto, el código y los archivos de configuración de forma silenciosa y continua en segundo plano al cambiar los diagramas o el código.

Diseñador de sistemas

El diseñador de sistemas se puede utilizar para diseñar sistemas de aplicaciones, que son "unidades de implementación" formadas por aplicaciones definidas en el diagrama de la aplicación o por sistemas definidos en otros diagramas de sistema, como se muestra en la figura 5. Debido a que un sistema es una configuración personalizada de las aplicaciones, las aplicaciones individuales se pueden sobrescribir a partir de los valores predeterminados especificados, o bien incluir uno o varios usos de la misma definición de la aplicación o la definición de un sistema determinado. Como se muestra en la figura 5, cada una de las aplicaciones se puede conectar y configurar de forma diferente a partir de su definición y de acuerdo al modo en que se desea implementar. Por ejemplo, se puede sobrescribir la configuración de una aplicación establecida como Overridable en su definición. De hecho, se pueden crear varias definiciones de sistema en la misma solución, donde cada sistema representa una configuración de implementación o centro de datos individual. Se trata de una acción útil para admitir a un gran número de clientes, cada uno con centros de datos distintos, que ejecutan la misma solución. Para crear un sistema, se pueden seleccionar las aplicaciones que se desean en el diagrama de aplicaciones, hacer clic con el botón secundario del mouse en éste y, a continuación, hacer clic en Diseñar sistema de aplicaciones.

Figura 5. Diagrama del sistema (haga clic en la imagen para aumentarla)

Diseñador de implementación

El diseñador de implementación permite asignar los diseños del sistema a un diagrama de centro de datos lógico creado con el diseñador de centro de datos lógico, de modo que se puedan describir las implementaciones lógicas de dichos sistemas. El diseñador de implementación garantiza que se asigne el tipo de aplicación adecuado al tipo correcto de servidor lógico, al tiempo que se siguen las restricciones de aplicación definidas en el servidor lógico en el diagrama de centro de datos lógico. Una vez que se han asignado todas las aplicaciones del sistema, se podrá llevar a cabo una validación de diagrama adicional, en la que Visual Studio comprueba toda la configuración y las restricciones configuradas en el diseñador de aplicaciones o de sistemas en el diseño del centro de datos lógico, con el fin de facilitar la localización de los problemas de configuración incluso antes de haber escrito una línea de código. Los errores de validación aparecen en Visual Studio, al igual que los errores y advertencias de compilación. Al hacer doble clic en alguno de estos errores, Visual Studio va al diagrama de aplicaciones o al diagrama de centro de datos lógico, selecciona la aplicación o el servidor lógico erróneo y abre la configuración que origina el problema. Tras implementar la aplicación y cambiar la configuración, los cambios realizados pasan inmediatamente al archivo de configuración. Por tanto, la validación ofrece información directamente al proceso de desarrollo.

Es como probar el comportamiento de un vehículo ante choques antes de construirlo. Este modelo de validación se puede utilizar para garantizar que la aplicación cumple siempre con las directivas del centro de datos, así como para comprender el efecto de los cambios realizados (en la arquitectura de la aplicación o en el centro de datos) en el ciclo de vida de la solución.

Team System para Software Developers

Visual Studio ya es en sí una herramienta excelente para la escritura de código. Team Developer sólo la mejora al aportar al desarrollador un mayor número de herramientas para la escritura de código de mayor calidad, el análisis del código base, el análisis dinámico de los ejecutables en ejecución para la obtención de información relativa a los perfiles de rendimiento y la cobertura de código, así como un marco de prueba unitaria completamente integrado.

Análisis de código

Las herramientas de análisis de código que ofrece Visual Studio Team System permiten analizar el código a medida que éste se crea. Se trata de herramientas basadas en herramientas probadas con el tiempo, como FxCop y PreFast. Estas herramientas permiten analizar el código de acuerdo a patrones de error específicos que se corresponden con la reglas especificadas por el usuario. Para habilitar el análisis de código administrado (escrito en cualquier lenguaje .NET), vaya al cuadro de diálogo Propiedades de cualquiera de los proyectos de código administrado, haga clic en la ficha Análisis de código y seleccione Habilitar análisis de código, como se muestra en la figura 6.

Figura 6. Habilitación del análisis de código

Como se puede observar, hay numerosas reglas ya definidas y habilitadas, desde reglas que comprueban las directrices de codificación y diseño, hasta reglas que comprueban los problemas de seguridad. Se puede bien deshabilitar las reglas que no se apliquen al proyecto, o bien, crear reglas propias para buscar patrones de código específicos. Cuando una regla detecta un problema en el código, Visual Studio emite una advertencia o un mensaje de error, en función de la configuración de la regla.

Las herramientas de análisis de código también se pueden utilizar para mejorar la calidad del código Microsoft C++ nativo. Por ejemplo, estas herramientas se pueden utilizar para facilitar la identificación de las saturaciones de búfer, la memoria no inicializada y la deferencia de punteros nulos. El modo de informar acerca de estas situaciones es el mismo que las advertencias de compilación, que se pueden desactivar a través de la directiva de compilación #pragma.

Análisis dinámico

El conjunto de herramientas de análisis dinámico de código incluye un generador de perfiles de código que permite medir el rendimiento de las aplicaciones en tiempo de ejecución. Existen dos modos de generar perfiles: el muestreo y la instrumentación.

El muestreo analiza y toma "muestras" del rendimiento de la aplicación a intervalos regulares para determinar las acciones que ésta realiza. Este modo de análisis reduce la probabilidad de que la creación de perfiles repercuta en el rendimiento de la aplicación, ya que sólo se ejecuta durante un breve período de tiempo. No obstante, dada la naturaleza estadística de este enfoque, no se obtiene una representación exacta de la temporización de la aplicación.

La instrumentación, por su parte, ofrece información exhaustiva relativa a las acciones de la aplicación, ya que, antes de que la aplicación se ejecute, el generador de perfiles instrumenta código adicional en cada una de las llamadas de método y procedimiento, lo que le permite determinar exactamente qué método fue llamado y cuánto tiempo tardó éste en ejecutarse. Como se muestra en la figura 7, la creación de perfiles basada en la instrumentación ralentiza el rendimiento de la aplicación, ya que hay un mayor número de líneas de código en ejecución y una mayor cantidad de datos obtenidos.

Figura 7. Resultados de la creación de perfiles basada en la instrumentación (haga clic en la imagen para aumentarla)

Pruebas unitarias

Las pruebas unitarias siempre han sido una parte importante del proceso de desarrollo de software. Este término hace referencia a un tipo específico de prueba responsable de validar un aspecto del sistema: una función o un procedimiento específico, un componente o incluso un escenario de uso. Team System cuenta con un marco para la escritura y ejecución de pruebas unitarias tanto en Team Developer como en Team Test, y ofrece integración de alto nivel en el IDE de desarrollo. Como se muestra en el código de ejemplo 1, a las pruebas unitarias se atribuyen funciones de prueba que comprueban el comportamiento de una función o procedimiento en el producto sometido a prueba. Como se muestra en la figura 8, al agregar el atributo [TestMethod] al código de prueba, Visual Studio lo reconoce como una prueba unitaria y muestra la función en las ventanas del administrador de pruebas.

[TestMethod()]
public void AdditionTest()
{
Math target = new Math();

int x = 5; 

int y = 5; 

int expected = 10;
int actual;

actual = target.Addition(x, y);
Assert.AreEqual(expected, actual, 
  "Math.Addition did not return the expected value.");

}

Ejemplo de código 1. Prueba unitaria simple

Figura 8. Administración de pruebas en Visual Studio (haga clic en la imagen para aumentarla)

El administrador de pruebas permite seleccionar y ejecutar pruebas unitarias, así como agruparlas, filtrarlas y organizarlas en listas de prueba. Cada una de las pruebas administradas por el administrador puede disponer de un conjunto de elementos de trabajo asociados, así como otros metadatos, como de prioridad, propietario y nombre de clase.

Cobertura de código

¿No sería estupendo conocer la cantidad de código examinado realmente durante la ejecución de una prueba unitaria? A este tipo de análisis se lo denomina cobertura de código. Tanto Team Developer como Team Test permiten ejecutar pruebas unitarias y realizar el seguimiento de las líneas de código ejecutadas durante dichas pruebas. Los resultados permiten determinar qué otras pruebas unitarias es necesario llevar a cabo para garantizar la comprobación de todas las líneas de código, así como para hacerse una idea de hasta qué punto son completas las prácticas de prueba utilizadas. En las figuras 9 y 10 se muestran los resultados del análisis de cobertura de código. En la figura 9, las líneas de código resaltadas en verde representan las líneas ejecutadas durante la prueba unitaria, mientras que las resaltadas en color rojo indican el código no ejecutado.

Figura 9. Resultados de cobertura de código en la ventana de código

Figura 10. Estadísticas de cobertura de código (haga clic en la imagen para aumentarla)

Team System para Software Testers

Recuerdo que cuando estaba en la universidad, uno de mis profesores me comentó que, si era constante en el trabajo, un día llegaría incluso a ser un comprobador de software. Sin embargo, la necesidad actual de escribir soluciones empresariales cada vez con mayor rapidez, a menudo conlleva escatimar a la hora de garantizar la calidad del software. Asimismo, las organizaciones que incluyen la fase de comprobación en los proyectos de desarrollo de software a menudo no disponen de una buena selección de herramientas integradas que faciliten las necesidades de prueba, por lo que se ven forzadas a adquirir soluciones de prueba de software muy costosas y escasamente integradas. Microsoft hace frente a estos retos proporcionando un conjunto de herramientas de prueba integradas tanto para los desarrolladores como para los comprobadores.

Ya hemos visto cómo se proporciona a los desarrolladores un marco de prueba unitaria integrado. Team Test va más allá, ya que incluye más capacidades de prueba y una consola de administración que facilita la administración, ejecución y el seguimiento de las pruebas. En la tabla 3 se enumeran una serie de pruebas que se pueden crear, administrar y ejecutar con Team Test.

Tabla 3. Tipos de prueba de Team System

Tipo de prueba

Descripción

Pruebas unitarias

Las pruebas unitarias son bits de código que prueban las funciones y los métodos de la aplicación. Las pruebas unitarias se utilizan para probar el código fuente existente y son fundamentales en el desarrollo controlado por pruebas.

Pruebas Web

Las pruebas Web permiten registrar la actividad de cualquier página Web. Una vez registrada, la prueba Web se puede modificar, convertir a código y agregar reglas de validación y extracción en los resultados devueltos de cada solicitud.

Pruebas por orden

Las pruebas por orden permiten agrupar y secuenciar cualquier número de pruebas Web o unitarias.

Pruebas de carga

Las pruebas de carga permiten repetir cualquier combinación de pruebas Web y unitarias una y otra vez, en función de un patrón de carga definido. Asimismo, se pueden especificar características de carga, como el número de usuarios simultáneos, el tipo de explorador y las características de las líneas de comunicación.

Pruebas manuales

Las pruebas manuales definen un conjunto de pasos manuales que debe ejecutar un comprobador para validar ciertas funciones de una aplicación determinada. Team System proporciona un mecanismo que permite definir pruebas manuales (en formato de Word o de texto). Además, estas pruebas se pueden administrar y ejecutar junto con otras pruebas.

Pruebas genéricas

Una prueba genérica es un programa existente ajustado para funcionar como una prueba en Visual Studio

Team Foundation Server

Team Foundation Server es probablemente la herramienta que ofrece el conjunto de características más importante de Team System. Team Foundation facilita el trabajo del equipo al incluir un nuevo sistema de administración de código fuente, capacidades de seguimiento de elementos de trabajo, funciones de automatización de generación, análisis y elaboración de informes integrados, así como un sitio de proyectos de colaboración integrado. Asimismo, ofrece capacidades de administración de proyectos con la integración de Microsoft Project y Microsoft Excel 2003.

Administración de control de código fuente

o en que los administradores de proyecto pueden controlar las directivas y las notas de protección.

Figura 11. Adición de directivas de protección

Figura 12. Adición de notas de protección

Otra de las características importantes del control de código fuente de Team Foundation es el aplazamiento de cambios. Esta característica permite colocar el código desprotegido en un conjunto de cambios aplazados situado en el servidor, donde permanecerá hasta que se desee utilizar de nuevo. Básicamente, lo que esta característica permite es almacenar código en curso en un "módulo" en el servidor, sin que ello sobrescriba ni dañe el código existente en el árbol fijo. Se trata de una característica muy práctica cuando es necesario utilizar varios equipos, transferir trabajo completado parcialmente a otro desarrollador o pasar rápidamente a un asunto de alta prioridad y, por tanto, se deben almacenar los cambios actuales.

Seguimiento de elementos de trabajo

Como se explicó anteriormente, un elemento de trabajo es un "elemento" que alguien del equipo puede asignar y completar. El caso más simple sería una tarea sencilla con una transición de estado simple: "abierto" y "cerrado". No obstante, la mayoría de los proyectos presentan tipos diferentes de elementos de trabajo, cada uno con sus propias características, estado de flujo de trabajo y transiciones. Otros ejemplos de elementos de trabajo son: errores, problemas, riesgos o incluso características. Todos los elementos de trabajo, independientemente de su tipo, se almacenan en Team System. Al crear un proyecto nuevo, la definición de éste determinará el número y tipo de los elementos de trabajo que se podrán crear. Cada tipo de elemento de trabajo puede presentar sus propios estados y transiciones y, en general, cada uno se puede asignar a un miembro del equipo, al que ofrece información como la iteración o versión de destino, la prioridad, etc. Los elementos de trabajo también se pueden vincular a otros elementos de trabajo, archivos del control de código fuente e incluso a un conjunto de cambio del control. La capacidad de vincular elementos de trabajo entre sí y con elementos como archivos y código fuente, ofrece la función de seguimiento necesaria en prácticamente todos los proyectos de desarrollo de software. Sin embargo, no es necesario preocuparse, ya que se trata de un modelo muy extensible y se pueden realizar cambios, si es necesario, para ajustarlo a las necesidades específicas del proyecto.

Figura 13. Ejemplo de uso de elementos de trabajo para tareas de seguimiento

Como se muestra en las figuras 14 y 15, Team System incluye una colección de elementos de trabajo con los que se puede interactuar a través de un gran número de herramientas diferentes, desde Microsoft Project, Microsoft Excel y Visual Studio, hasta Team Explorer.

Figura 14. Definición de elementos de trabajo en Visual Studio (haga clic en la imagen para aumentarla)

Figura 15. Elementos de trabajo en Excel (haga clic en la imagen para aumentarla)

Automatización de generación

La automatización de generación es una práctica adecuada de extrema importancia para los equipos de desarrollo de software. Team System incluye automatización de generación con Team Foundation Build, que utiliza MSBuild, puede ejecutar pruebas unitarias asociadas y análisis de código, liberar construcciones en un servidor de archivos y publicar informes de generación al resto del equipo. Los resultados y registros de Team Foundation Build se pueden propagar al almacén de datos de Team System para la elaboración de informes y la realización de análisis. Asimismo, Team Foundation Build está integrado completamente con otras herramientas de Team System, como el control de código fuente y el seguimiento de elementos de trabajo.

Con Team System, se puede disponer de un gran número de tipos de generación diferentes que se pueden definir y personalizar en función de las necesidades propias. Como se muestra en la figura 16, Team System incluye un asistente de inicio.

Figura 16. Definición de un tipo de generación nuevo

Los resultados de todas las construcciones se mantienen y se pueden ver en Visual Studio o a través de informes de generación. Asimismo, es importante tener en cuenta que se pueden configurar numerosos equipos de generación para llevar a cabo el proceso de generación, el cual se puede iniciar a través de la IUG o de la línea de comandos. Además, como se muestra en la figura 17, Team System se puede configurar para notificar los resultados de una generación por correo electrónico.

Figura 17. Configuración de alertas para los eventos de generación

Informes

¿No sería extraordinario poder generar automáticamente un informe en el que se muestre la rapidez semanal con la que trabaja el equipo teniendo en cuenta sus actividades reales? Estamos de suerte. Las características de elaboración de informes de Team Foundation ofrecen esta capacidad. Team Foundation está integrado en SQL Server 2005, y almacena toda la información relativa a los elementos de trabajo, atributos de calidad, pruebas y resultados de prueba, así como los resultados de la generación. Toda esta información se incluye en SQL Server Analysis Services y se vincula a las características de informe de Team System. De hecho, los informes que contiene Team System se crean con SQL 2005 Reporting Services; lo que implica que se podrán modificar los informes existentes e incluso crear otros propios que se ajusten a las necesidades en cuestión.

Numerosos informes se envían junto con Team System (en la figura 18 se muestra un informe de ejemplo), ya que forman parte de las plantillas de proyecto de Team System utilizadas en la creación de nuevos proyectos de Team System. Al personalizar las plantillas de proyecto de Team System para crear tipos de elemento de trabajo propios, o al modificar definiciones de elementos de trabajo existentes, probablemente se desee también personalizar los informes predeterminados.

Figura 18. Informe de ejemplo (haga clic en la imagen para aumentarla)

Sitio de proyecto

Al crear un proyecto de Team System nuevo, el sistema solicita que se cree un nuevo sitio de Microsoft Windows Sharepoint para mejorar la colaboración en el proyecto. Microsoft Windows Sharepoint Services cuenta con las capacidades de administración y almacenamiento de documentos necesarias para la documentación correspondiente al proyecto creado por el equipo. La definición de la plantilla de proyecto de Team System también define la estructura y el contenido del sitio de Sharepoint, hasta la estructura de la biblioteca de documentos y las plantillas de documento. De hecho, Team System se puede configurar para crear un sitio de Project Portal que contenga todos los artefactos que se deben incluir como parte del proyecto, lo que torna más sencillo garantizar que se envía el artefacto correcto en el momento adecuado.

El sitio de Windows Sharepoint también contendrá partes Web que permiten ver los informes directamente en el sitio. Se trata de una característica de gran importancia, ya que ahora los miembros del equipo de proyecto que no sean desarrolladores pueden ir sin utilizar Visual Studio a un lugar en el que pueden obtener información relativa al mantenimiento, el estado y los detalles del proyecto, directamente en el explorador.

Figura 19. Sitio de proyecto (haga clic en la imagen para aumentarla)

Administración de proyectos

Los administradores de proyectos suelen utilizar Microsoft Project o Microsoft Excel para administrar el "material" que se debe utilizar. Desde la perspectiva de Team System, esto se traduce en la capacidad de administrar elementos de trabajo de varios tipos en el equipo. Visual Studio Team System ofrece una interfaz integrada que permite a los administradores de proyecto interactuar con otros elementos de trabajo. No obstante, en numerosos casos, resulta bastante más natural que los administradores de proyecto utilicen las herramientas con las que están más familiarizados. Por ello, Team System permite sincronizar los elementos de trabajo con Microsoft Excel y Microsoft Project. En estas herramientas, los administradores tienen libertad para asignar y realizar el seguimiento de todos los elementos de trabajo (independientemente de su tipo) de un modo natural y productivo.

Los informes son también de gran importancia para los administradores de proyectos. Con Team System, los administradores de proyectos podrán utilizar numerosos informes integrados con el producto, así como una serie de herramientas de análisis, como Microsoft Excel, para conectarse al almacén de datos de Team System para analizar los datos del proyecto. Los administradores de proyecto también pueden utilizar las características del sitio de Windows Sharepoint creadas para cada proyecto de Team System, con el fin de facilitar la comunicación y la administración de todos los documentos y artefactos del proyecto.

Extensibilidad y personalización de Team System

Como se ha mencionado anteriormente, Team System es más que un conjunto de herramientas: es una plataforma. No es el objetivo de este artículo tratar en demasía el aspecto de la extensibilidad. No obstante, enumeraremos las zonas de Team System que se pueden ampliar. En la tabla siguiente se ofrece información general sobre estas opciones.

Tabla 4. Resumen de extensibilidad de Team System

Zona de personalización

Descripción

Plantillas de proyecto

Las plantillas de proyecto de Team System se utilizan durante la creación de un proyecto nuevo de Team System. Estas plantillas definen todos los aspectos del proyecto, entre los que se incluyen los informes, las definiciones de los elementos de trabajo, las directivas de control de código fuente, la estructura y el contenido de Windows Sharepoint Services, las directrices del proceso y los permisos. Del mismo modo, se pueden definir plantillas de proyecto propias adecuadas a las necesidades del proyecto en cuestión y la organización. Es necesario tener en cuenta que Team System no incluye herramientas para personalizar estas plantillas, por lo que se deberán editar a través de un editor de XML.

Elementos de trabajo

Se pueden definir los elementos de trabajo propios o personalizar los ya existentes; a través de un editor de XML.

Control de código fuente

Para cada proyecto de Team System, se pueden definir directivas de control de código fuente y campos de nota de protección.

Tipos de generación

Visual Studio Team System permite definir tipos de generación propios.

Sitio de Windows Sharepoint Services

Se pueden modificar los documentos contenidos en el sitio de Windows Sharepoint, así como hacer uso de las características de personalización de Windows Sharepoint Services, lo que facilitará la promoción de la colaboración en equipo.

Informes

Se pueden modificar los informes existentes o crear otros nuevos a través de SQL 2005 Reporting Services, el cual utiliza la información almacenada en el almacén de datos de Team System.

Kit de herramientas de extensibilidad

Se puede descargar el kit de herramientas de extensibilidad de Visual Studio Team System para obtener información detallada sobre las opciones de extensibilidad. Este kit de herramientas también muestra el modo de crear tipos de prueba propios y explorar el modelo de objetos de Team System en busca de numerosas opciones de personalización.

Conclusión

Resulta obvio que Team System es un producto nuevo que ofrece un conjunto de herramientas muy diversas que admiten prácticamente todos los aspectos del ciclo vital del desarrollo de software. Lo que no resulta tan obvio es el modo en que la organización adopta Team System. No obstante, debe quedar claro que la simple adopción de un conjunto de herramientas no solventará necesariamente todos los problemas. Las características que ofrece Team System deberían permitir disponer de una visión mucho más amplia de los procesos de desarrollo de software de un entorno específico. Team System se debe utilizar de modo que se ajuste a las necesidades específicas de la organización en cuestión, y no al contrario.

El objetivo de este artículo no era profundizar en una característica en concreto, sino aportar conocimientos de alto nivel acerca del modo en que los distintos componentes de Team System se interconexionan. Les animo a que estudien con mayor profundidad aquellos aspectos de Team System que les resulten de mayor interés y que se tomen el tiempo necesario para comprender el modo en que este conjunto de herramientas integradas, aunque extensibles, aumenta el grado de productividad y previsibilidad de los equipos de desarrollo de software.

A medida que vaya conociendo más sobre Visual Studio Team System, podrá ir consultando varios blogs que le pueden resultar interesantes. Para comenzar, consulte: http://blogs.msdn.com/askburton (en inglés).

Mostrar: