.NET 2.0 y Visual Studio 2005 (parte I)

 El  pasado 7 de Noviembre se lanzó en USA la nueva herramienta de desarrollo de software de Microsoft. Visual Studio 2005 está alineada con el nuevo framework .NET, el 2.0. Quiero contar a los arquitectos de software (developers y jefes de proyecto bienvenidos), cuáles son las ventajas que aporta tanto el nuevo framework como la herramienta de desarrollo. Espero les sea útil a aquellos que estuvieran investigando nuevos estándares

En este artículo me voy a concentrar en las mejoras provistas a jefes de proyecto, a arquitectos -tanto de solución como de infraestructura- y a testers. En una segunda parte voy a cubrir las mejoras para los desarrolladores (por el IDE, por la plataforma de ejecución y por API’s como ASP.NET 2.0, ADO.NET 2.0, etc)

 
Visual Studio ya había alcanzado, en sus versiones 2002 y 2003 estos últimos años, el reconocimiento por ser un IDE que acortaba sorprendentemente los tiempos de desarrollo de aplicaciones, tanto personales como empresariales. Las características más interesantes eran normalmente adoptadas luego por otros IDE’s. Quizás sí muy centrada en el desarrollador más que nada, y por eso desconsiderada en el resto del equipo de proyecto. Lo que viene ahora créanme que cambia la historia
 
Hasta entonces cada rol del equipo (observar que dije rol y no miembro, ya que un miembro puede jugar varios roles) tenía sus propias herramientas. El jefe de proyecto llevaba la carta Gantt en Project o Excel, el arquitecto tenía múltiples herramientas, con mayor o menor grado de integración, para sus diagramas de componentes, clases, secuencias, etc, y así sucesivamente.
 
El problema mayor era que estas herramientas no estaban integradas, por lo que la coordinación de la vista del proyecto que cada una mostraba debía hacerse en forma manual (el arquitecto puede cambiar un diseño de un componente y eso aún no tener respaldo en el código, o al tener respaldo en el código puede que el jefe de proyecto no marque el hito cumplido en la carta Gantt, …)
 
Entonces llega el turno de Visual Studio Team Foundation: el lado servidor de Visual Studio 2005. Team Foundation se apoya en otras herramientas de Microsoft pero inteligentemente se planta como front-end unificado hacia el equipo de proyecto. Así, provée acceso centralizado a listas de tareas, requerimientos, bugs y otros, persistiendolos en SQL Server 2005. El jefe de proyecto va a poder usar indistintamente Project o Excel, lo que le resulte más cómodo, para acceder a la lista, actualizarla, asignar responsables de las tareas, etc. Cada miembro del equipo puede recibir, opcionalmente, notificaciones vía mail de los eventos que lo involucren. No obstante Team Foundation tiene algo más novedoso en materia de colaboración que es la puesta a punto de un portal del proyecto gracias a su integración con Windows Sharepoint Services

Click here for larger image.
Portal del Proyecto

En este portal, todo el avance del proyecto va a estar reflejado (bugs corregidos, versiones liberadas), todo en forma transparente. También, todo documento que agreguemos al proyecto de equipo (team project, en la nueva vista Team Explorer en Visual Studio 2005) va a estar automáticamente posteado en el portal colaborativo

 
Y esta integración con SQL Server 2005 está nuevamente justificada por la razón de que se aprovecha su potente motor de Reportes (Reporting Services) para añadir al portal un conjunto de reportes predefinidos que permitan llevar el control de gestión del proyecto (bugs por prioridad, velocidad del proyecto, y muchísimos más, además de los que queramos definir)

Click here for larger image.

Ejemplo de Reporte

Respecto del control de versiones, nuevamente Visual Studio 2005 como front-end, y como back-end a no confundirse: esta vez le decimos adiós a Visual Source Safe porque SQL Server 2005 pasa a ocupar su lugar. La explicación? Un mejor aprovechamiento de sus características en entornos distribuidos (accediendo a través de Internet en equipos posiblemente desplazados geográficamente. Para el desarrollador es transparente: Visual Studio 2005, como decíamos, es el front-end

 
Antes de publicar las versiones, Team Foundation, propone el concepto de construcción pre programada (scheduled build) de las soluciones, que luego se sometan al rastrillado de los tests -ahora hablaremos de esto- como requisito para subirlo al portal. Es frecuente que en el puesto del desarrollador sus componentes funcionen a la perfección pero, al integrarlos al resto del proyecto de equipo, no se comporten de igual manera o, incluso, que provoquen efectos secundarios (side effect) en otros componentes
 
Antes de dejar de lado Team Foundation, para pasar a enumerar otros beneficios de Visual Studio 2005, quiero mencionar de pasada la posibilidad de implementar procesos de desarrollo de software por la vía de Microsoft Solutions Framework (MSF). Es un tema muy amplio y novedoso por lo que recomiendo enfáticamente ver este webcast que grabamos el 26 de Octubre de 2005 en Chile (y en español)
 
El arquitecto de la solución ahora puede armar el esquema de componentes de la solución con el flamante Diagrama de Aplicación. Es un primer nivel de descomposición funcional, de alto nivel, que permite modelar la arquitectura. Existe una buena introducción para quienes quieran profundizar el tema: click acá. La segunda parte aquí

 

Ejemplo de Diagrama de Aplicación de una Arquitectura Orientada a Servicios
 
Otro diagrama novedoso es el Centro de Datos Lógico. En el mismo, el arquitecto de infraestructura define zonas, fronteras entre servidores y redes, especificando políticas de seguridad, rutas de comunicación, y otras características del entorno distribuido. Nuevamente sugiero explorar estos documentos introductorios: parte 1 y parte 2

Ejemplo de Diagrama del Centro de Datos
 
El Diseñador de Sistema (System Designer) es lo que permite enhebrar los otros dos diagramas. Aquí el arquitecto de la solución podrá asignar los componentes (servicios, etc) del Diagrama de Aplicación a esas zonas que el arquitecto de infraestructura había diagramado en el Centro de Datos Lógico. Esta característica se conoce como Iniciativa de Sistemas Dinámicos (Dynamic Systems Intiative o DSI). Invito a explorar el documento que centraliza todos estos conceptos: click acá
 
Pasemos a hablar de Control de Calidad (Quality Assurance). Visual Studio 2005 incorpora una nueva vista que es la Vista de Testing


Vista de Testing

Desde la misma se pueden lanzar las pruebas creadas desde un nuevo tipo de proyecto: el Proyecto de Test (Test Project). Las pruebas que se pueden incluir en este tipo de proyectos son, entre otras

  • Prueba Unitaria, que es el caso más conocido donde una clase se usa como testeadora de otras, generando entornos aislados para invocar a métodos de las clases probadas e indagar luego por el estado final del entorno mediante aserciones lógicas
  • Prueba Web, donde se pueden graban actividades desde el Internet Explorer a fin de automatizarlas y poder indagar, por ejemplo, si la respuesta HTTP contiene un string específico
  • Prueba de Carga, que se compone de los otros tipos de prueba pero lo que procura es simular un entorno de varios usuarios simultáneos, a fin de encontrar los límites del entorno de ejecución
  • Otros, como la Prueba Genérica y la Prueba Manual

Ventana de resultados de las pruebas

Lo interesante es el abanico de posibilidades que se abre con Team Test (tal el nombre del módulo de pruebas). Podemos desarrollar código con un enfoque dirigido por las pruebas (Test-driven development o TDD). Podemos -y esto se ha ido tornando, yo dría, en un imperativo- calendarizar construcciones de código nocturnas (nightly builds) que ejecuten todas las pruebas al código para anticipar la detección de errores o efectos colaterales. Pensemos en equipos grandes donde un error (bug) introducido en una clase puede impactar varias clases más allá, y eso no detectarse durante, tal vez, semanas. El riesgo de que el error se detecte en producción es alto. Pero sobre todo, cuanto más se demora en detectar un bug, más difícil es encontrar qué modificación al código lo generó. Por eso la conveniencia de hacer un build del código de todo el equipo una vez al día y ejecutar automaticamente todas las pruebas de regresión: para que los errores nuevos se detecten dentro de las 24 horas

Ahora bien, cómo tener certeza de que todo nuestro código está siendo sometido a estas pruebas unitarias? Para ello existe un indicador conocido como cobertura de código (code coverage). Visual Studio 2005 va a señalarnos con rojo aquellas porciones de código que no fueron sometidas a ninguna prueba


Ejemplo de Cobertura de Código, donde el else no está cubierto por ninguna prueba

Recomiendo la lectura de este artículo de Ian Murphy para un análisis integral de Team Test

Propongo dejar acá esta primera parte, habiendo cubierto las características salientes para los roles de Jefe de Proyecto, Arquitectos y Testers. En la segunda y última parte cuento qué hay para el Desarrollador

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

6 respuestas a .NET 2.0 y Visual Studio 2005 (parte I)

  1. Jenny Maria dijo:

    hola me parece muy interesante pero me gustaria que por favor la parte de Team tes sea mas amplio, porque no hay mucha informacion al respecto o que a su vez me dieran una direccion en la cual yo puede tener mas informacion.
     
    Saludos Cordiales

  2. Diego dijo:

    Allo Jenny, gracias por comunicarte. En este link que te paso está lleno de artículos sobre Visual Studio Team Test: http://msdn.microsoft.com/vstudio/teamsystem/reference/develop_test/
    Del mismo modo, te recomiendo un webcast interesantísimo que te enseña una técnica de desarrollo muy piola basada en modelar primero las pruebas. Eso se llama Test-Driven Development (o desarrollo dirigido por las pruebas). Lo podés encontrar haciendo click acá

  3. MAURICIO dijo:

    Me parece un muy buen artículo introductorio para Visual studio 2005, pero tengo una duda, que es Team Foundation Server? De igual forma tomaré de referncia los links para aprender mas sobre Team Test, pues me interesa.
     
    Gracias
     
    Mauricio Cordero

  4. Diego dijo:

    Estimado Mauricio gracias por comunicarte. Team Foundation Server es un inédito "lado servidor" de Visual Studio que permite mantener un portal web de cada proyecto, de modo que en equipos grandes (eventualmente diseminados en diferentes lugares) puedan conocer tareas pendientes, quién tiene asignado qué, en qué status lo lleva, las versiones de cada pieza del código fuente y especialmente, aunque hay muchas otras más características, un área de reportes de gestión del proyecto: la planificación de tareas, las terminadas, asignadas en curso, las demoradas, etcHasta ahora Visual Studio se instalaba en cada puesto de desarrollador pero luego los developers se tenían que poner de acuerdo en las tareas a realizar y quién se asignaba qué, sin que la herramienta respalde esos acuerdos. Había que usar el mail o dejarse notas en papel o cara a cara para comunicarse las tareas. Ahora la misma pieza soporta estoTú puedes asignarle una tarea a alguien y cuando ese alguien la completa la pasa a estado "completado". Luego Team Foundation Server te permite calcular en forma automática tiempos de gestión, promedios, etc (con sólo pedirlo: nada de listar la data, mandar al Excel, cargar la fórmula que resta fechas, etc)También, TFS le avisa al responsable de una nueva tarea que se la has asignado. Y te avisa a tí que fue concretada, cancelada, etc. Automático

  5. emiliano dijo:

    Hola, leyendo el articulo y buscando no encontre mucha informacion mas que nada del uso del TFS, en español. Queria saber si  tendras o sabes de algun libro o manual que expliquen el funcionamiento del Team System, no la parte de Test sino simplemente de la parte de control de version de fuentes y su uso, es decir para desarrolladores mas que nada…Gracias por tu respuesta..Saludos desde Tucuman, ArgentinaEmiliano Hasan

  6. Diego dijo:

    Allo Turko,
       en Cuspide tienen "Visual Studio 2005 Team System Profesional" de Editorial Wrox (buena reputación), bastante completo en el sentido que -como vos necesitás- no se limita a lo que cada desarrollador puede hacer en su puesto sino al trabajo en equipo en general
       No obstante, lo que hay disponible en inglés al respecto es abrumadoramente más. Por ejemplo MSDN Magazine sacó un artículo hace un año acerca de control de versiones (otro de los tópicos que mencionabas). Muy muy mal te llevás con el inglés? Hay videos (webcasts) con demos, etc, pero más en la lengua de Shakespeare que la de Cervantes  😦
       Tengo acá el sitio MSDN de Argentina, en la página de Team System, aunque calculo que será la que ya revisaste. Aunque no mucha, hay algo más de data allí. Particularmente en la página de comunidad vas a ver 3 links a foros donde podés plantear la pregunta, sobre info piola de colaboración en equipo (los foros son en castellano) a ver qué dice la muchachada
     
       Te mando un abrazo y gracias por leerme / escribirme

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s