En pasados artículos hemos visto cómo gestionar nuestros planes de pruebas y cómo ejecutarlos con Microsoft Test Manager, siempre desde la perspectiva de pruebas funcionales manuales. En este artículo mostramos cómo crear pruebas funcionales automatizadas con Visual Studio 2010.

En nuestra entrega anterior dedicada a Microsoft Test Manager (MTM), hicimos una introducción a la planificación de pruebas con esta herramienta. En este artículo os contaremos cómo crear nuestra primera prueba y ejecutarla.

Con la llegada de Visual Studio 2010, hemos recibido también un nuevo producto: Microsoft Test Manager. Hasta ahora no existía ninguna herramienta completa para pruebas funcionales dentro de los productos Microsoft. Con esta nueva herramienta, podremos incorporar el equipo de pruebas dentro de nuestro ciclo de vida de desarrollo con Visual Studio 2010 y Team Foundation Server 2010.

Si ya tenemos un entorno de integración continua, podremos evitar muchos fallos de integración de código y hacer más fácil la vida a los desarrolladores. Aún así, hay veces en las que se sube código al repositorio que rompe la build e interrumpe el flujo normal de trabajo. En este artículo presentamos uno de los modos de evitar esto con Team Build 2010.

El uso de iteraciones en el ciclo de vida de los desarrollos es, a día de hoy, algo indiscutible y que todas las metodologías utilizan y tienen en cuenta. En Team Foundation Server 2010 dispondremos de herramientas basadas en los work items jerárquicos, así como de hojas de cálculo Excel que nos van a simplificar la tarea de la gestión de iteraciones.

Disponer de un servidor de símbolos, estando además éstos indexados con la información de acceso al código fuente correspondiente, es algo que puede ser de gran utilidad a la hora de depurar nuestras aplicaciones. Si automatizamos el mantenimiento de este servidor mediante Team Build, conseguiremos además que los símbolos indexados estén disponibles para todas nuestras compilaciones y con un mínimo trabajo extra.

Desde hace unos días, ya contamos con la beta 2 de las herramientas de Visual Studio, que van desde la nueva versión de Visual Studio hasta el nuevo Team Foundation Server, además del recientemente anunciado TFS Basic Installation, que sirve como puerta de entrada a TFS para equipos pequeños e incluso de desarrollador único. En este artículo repasamos lo que se nos viene encima con esta nueva versión, que llega cargada de novedades.

Una de las tareas más tediosas a las que se enfrenta cualquier equipo Scrum es el mantenimiento de los artefactos de la metodología: la pila de producto (Product Backlog), las pilas de sprint (Sprint Backlogs) y las gráficas de burndown. El Taskboard de Conchango es un complemento perfecto para Team Foundation Server que simplifica mucho este mantenimiento, y que acerca el trabajo con TFS a las prácticas conocidas por cualquier equipo Scrum. De hecho, ¿qué herramienta puede mejorar la curva de aprendizaje asociada a utilizar una simple pizarra y un montón de post-it?

Existen multitud de herramientas disponibles para facilitarnos el trabajo con Team Foundation Server (TFS), ya sean desarrolladas por terceros o por personal de Microsoft. Entre estas últimas están las que hoy quiero presentaros: las Power Tools, un complemento indispensable, en mi opinión, a la hora de administrar y trabajar con TFS.

Las acciones que realizamos cuando utilizamos Visual Studio Team System: programar líneas de código, crear y ejecutar pruebas unitarias, realizar acciones de check in/check out, modificar información de work items, etc., generan automáticamente una gran cantidad de datos que luego pueden ser analizados y cruzados entre sí para extraer conclusiones. En este artículo veremos cómo funciona el repositorio de información analítica que posee VSTS y cómo podemos trabajar con el mismo.

Una de las primeras preguntas que se hacen al empezar a implantar Team System es ¿y por dónde empiezo? ¿qué hago? Son tantas las prácticas, herramientas, decisiones, que se hace difícil arrancar. Sin embargo, Joel Spolsky propuso hace tiempo 12 sencillas preguntas para evaluar nuestra situación. Pues bien, vamos a darle una vuelta a esas preguntas, para usarlas como punto de comienzo.

Mucho se ha hablado sobre las características que deben cumplir las pruebas unitarias y sobre los beneficios que nos aporta su uso. Por este motivo, en este artículo intentaremos dar un paso más y profundizar en el mundo de las pruebas unitarias, intentando aportar un enfoque práctico, centrado en explicar algunos de los recursos que tenemos actualmente a nuestra disposición.

En muchas ocasiones, en el momento en que generamos la versión de nuestra aplicación nos dejamos el último ensamblado añadido, la modificación del fichero de configuración, o los PDB generados se encuentran en modo Debug. Team Foundation Build nos ayuda a simplificar estas tareas, mejorando el versionado de nuestros proyectos.

Team Foundation Server (TFS) es una herramienta altamente extensible y personalizable, que nos permite adaptarla a nuestras necesidades de proceso; recordemos que no existen balas de plata, y en las herramientas tampoco. Uno de los puntos principales de extensibilidad es el modelo de objetos de los work items, permitiéndonos automatizar tareas como su creación, edición, validación y consultas.

La certificación CMMI permite a las empresas presentarse a los clientes como una organización que lleva a cabo unos procesos bien estructurados y con un seguimiento continuo. Está demostrado que las empresas que trabajan con procesos bien definidos y optimizados consiguen mejores resultados en sus proyectos y sobretodo consiguen lo más importante “La satisfacción de los clientes”. Team System permite trabajar con CMMI en los entornos de desarrollo .NET

El desarrollo de software es cada vez una tarea más compleja, en la que intervienen diferentes roles y que comprende un buen número de etapas y actividades. Para llevar a cabo esta tarea, deberemos contar con una metodología que nos ayude a completarla con éxito, reduciendo los riesgos y haciendo el proceso más predecible y eficiente.

¡Bienvenidos al especial de ALM de dotNetManía! En este número vamos a acercarnos un poco más al mundo del ciclo de vida del software y, sobre todo, a cómo vamos a implementar los procesos y realizar las tareas mediante las herramientas de Visual Studio Team System.

Cuando Microsoft lanzó Visual Studio Team System hace unos cuatro años, muchos desarrolladores vimos cómo se cumplían nuestras expectativas de lograr que Visual Studio se convirtiese en una herramienta al servicio de los equipos de trabajo y no solo al servicio de los desarrolladores. Personalmente vi colmada otra expectativa, contar con una herramienta en entornos Microsoft que acercase las metodologías a los equipos de desarrollo, con independencia de la metodología elegida y del tamaño del equipo de desarrollo. En este artículo pretendo compartir lo aprendido en estos años sobre la implantación de metodologías ágiles con Team System, las dificultades encontradas, cómo las he abordado y qué resultados he obtenido.

Son muchas las variables que intervienen en el éxito o fracaso en el desarrollo del software, pues ellas dependen de cada tipología de proyecto, de empresa, de solución o de tecnología escogida. Microsoft Visual Studio Team System incorpora una serie de informes que nos permiten valorar el estado de nuestro desarrollo.

Una de las prácticas más recomendadas a la hora de realizar proyectos y empezar a asegurar la calidad pronto es la de integrar todo el código lo más frecuentemente posible. Esto es especialmente importante a la hora del desarrollo iterativo, mediante el cual gestionaremos los cambios de requisitos de una forma más efectiva, entregando nuevas funcionalidades del software en cortos periodos de tiempo.

Con la reciente presentación de Visual Studio Team System 2008, Microsoft renueva su apuesta por ofrecer una solución orientada a mejorar la gestión del ciclo de vida de las aplicaciones (ALM, Application Life-cycle Management). Esta solución se compone de un conjunto de herramientas, procesos y guías, integradas en un solo entorno, para potenciar el trabajo en equipo de los diferentes roles que participan en el proceso de desarrollo de software.

Para cerrar esta serie de artículos de metodología, presentamos Microsoft Operations Framework, la propuesta de Microsoft para planificar, desplegar y mantener soluciones de servicio. Esta metodología complementa a Microsoft Solutions Framework, que hemos presentado en los artículos anteriores, y juntas forman la propuesta de Microsoft para la gestión del ciclo de vida de los proyectos de TI.

Este mes damos continuación al primer artículo de esta serie, publicado el mes pasado, en el que se realizó un primer acercamiento a la metodología que Microsoft pone a disposición de los ingenieros y administradores para realizar de forma más eficiente y organizada su trabajo.

En esta serie de tres artículos se quiere dar una visión global sobre las herramientas que en este campo nos ofrece Microsoft y que suelen ser desconocidas incluso para los propios interesados. El objetivo no es tanto dar un completo repaso a estas metodologías como conocer las bases y elementos más interesantes para su aplicación en el trabajo diario.

En este artículo se describe el enfoque con que se utilizan las métricas en Microsoft Solutions Framework y se presentan algunas de las métricas para esta metodología de las que se puede disponer cuando se utiliza Team Foundation Server para la gestión de los proyectos.

¿Para qué inventar una solución si ésta ya existe? Básicamente, esa es la premisa que siguen los patrones de diseño y que tantos arquitectos han adoptado. Seguido os introducimos de lleno en ellos y os proponemos cambiar vuestro punto de vista en el a veces complejo mundo de la arquitectura de software.

En la anterior entrega cogimos el metro para estimar la carga de trabajo necesaria a fin de realizar un proyecto de construcción de software. Medimos, diseñamos, construimos y ahora vuelve a tocar sacar el metro del bolsillo para comprobar si lo que hemos realizado se corresponde con lo que planificamos, así como para verificar si el proceso de construcción ha seguido las normas adecuadas y/o si tenemos evidencias de que no habrán demasiados defectos que compliquen el mantenimiento futuro del mismo.

Medir o no medir, esa es la cuestión. En la Ingeniería del Software, el uso de métricas, tanto para la estimación como para el seguimiento de proyectos, se impone como una buena práctica esencial. En este artículo abordaremos esta cuestión desde la perspectiva de la estimación, dejando para otros de la serie, los aspectos relativos al seguimiento.

En este artículo se muestra cómo Microsoft está apostando por la nueva tendencia de desarrollo de sistemas software dirigido por modelos a través del paradigma Software Factories y de las herramientas para desarrollar nuevos lenguajes específicos de dominio que le dan soporte.

Con el paso del tiempo, afortunadamente, la ingeniería del software está dejando de ser un arte y se está convirtiendo realmente en ingeniería. Eso implica nuevas técnicas y nuevas herramientas. Por lo tanto, el concepto de reutilización también ha de evolucionar. La herramienta swREUSER y su metodología iRM apuntan en esta nueva dirección.

La diversidad de metodologías existentes, procedimientos y herramientas actuales dificulta en gran medida la ejecución de proyectos de software. Por otro lado, la multitud de tecnologías y su complejidad agrava más esta situación, y se ve multiplicada tanto en las áreas de sistemas como de desarrollo.

Sin duda el testeo unitario es una de las técnicas relacionadas con la calidad del software que mayores beneficios aporta al proceso de desarrollo. Aunque es una técnica clásica, en los últimos tiempos se ha popularizado de la mano de las metodologías ágiles de desarrollo de software y gracias a la aparición de herramientas que facilitan la escritura, ejecución e integración de los test en el proceso de desarrollo.

Cuando se intenta definir o describir algún nuevo concepto de una disciplina, es interesante mostrar algunos antecedentes o evolución histórica que permitan, no solamente ubicar al nuevo concepto, sino entender porqué surge, qué problemas resuelve, la forma en que los resuelve, etc.

Después de habernos detenido en nuestros dos artículos anteriores en los fundamentos del concepto de arquitectura de software (ver números de agosto y septiembre) podemos ir viendo algunos tipos de arquitectura, tratando de agrupar esos tipos en conjuntos a los que podamos asignar cierto nivel de generalización como los que muestran Mary Shaw y David Garlan en su clásico libro Software Architecture (1996).

Al desarrollar una aplicación Web suelen surgir dudas sobre su rendimiento y sobre si proporcionará todo lo que se espera de ella. Application Center Test puede ayudarnos a despejarlas siempre que planifiquemos adecuadamente nuestras pruebas.

En la 12ª conferencia anual del TechEd, el director ejecutivo de Microsoft, Steve Balmer, presentó un conjunto de herramientas y tecnologías orientadas para satisfacer las deficiencias evidentes que hasta ahora presentaba su compañía en el desarrollo de los ciclos de vida de los proyectos de software, tanto para el desarrollador, el arquitecto, el ingeniero de sistemas o el profesional.

En nuestro artículo anterior (“Arquitecturas. Algunos fundamentos”, dotNetManía, Nro. 6, julio/agosto) hablábamos de las diversas concepciones que implica el término arquitectura de acuerdo al autor que emplea el concepto.

El concepto de arquitectura, en el ámbito de desarrollo de software, ha ido evolucionando y se ha convertido en un concepto bastante complejo, es decir que abarca una gran diversidad de aspectos del desarrollo.

Hay muchos patrones de los que podríamos hablar pero, sin duda, gracias a su integración en el Framework, el patrón observer es el más utilizado de los patrones clásicos, cuando trabajamos en .NET.

Parece que la arquitectura está de mo­da. En eventos como el último PDC de Microsoft se dedican tracks específicos, y hasta una matinal completa (el Architecture Symposium), aparecen newsletters, revistas, secciones en revistas, webs, libros, documentos extensos y demás artilugios comunicativos. Hasta en la trilogía Matrix aparece la figura del Arquitecto, un elemento endiosado y de discurso rocambolesco. ¿A qué se debe toda esa artillería? ¿Hemos de escondernos en la trinchera hasta que pase la tormenta, o ese bombardeo sirve para allanar el camino hacia el combate con nuestro enemigo virtual? Los problemas y las soluciones a estas propuestas por la arquitectura no son nuevos, los que es nuevo es el concepto. El concepto nos enfrenta a tener otra perspectiva sobre esos problemas; lógicamente, una perspectiva más rica y que nos permite avanzar con mayor rapidez y acierto, en comparación con los enfoques que usábamos anteriormente.

En este artículo vamos a intentar introducir el paradigma de la orientación a objeto, distinguiendo entre lo que es la programación, el desarrollo o el modelado orientado a objeto. Vamos a hacer un recorrido a través de las diferentes metodologías basadas en objetos (OMT, UML, Métrica v3…) y los lenguajes de programación que implementan éstos conceptos (C++, C#, VB.Net, Eiffel…). Y finalmente nos pararemos a hacer una primera aproximación al Lenguaje Unificado de Modelado (UML).

Visual Studio Team System nos ayuda a gestionar el ciclo de vida del desarrollo de software, cuya pieza clave del proceso es el código y, por tanto, los desarrolladores. En este artículo veremos por qué ellos son la piedra angular de este proceso y exploraremos algunas de las prácticas y funcionalidades que usamos cada día cuando desarrollamos.