dedicada a los profesionales de la plataforma .NET

www.

dotne

tman

ia.co

m

nº 52 octubre 2008 6,50 € Visual Basic • C# • ASP.NET • ADO.NET • AJAX • Silverlight • .NET Framework

dotNetManía

Visual Studio Team System… ¿Y esto qué es? (un poco de anatomía) • Escogiendo metodología y organización de equipo •La importancia del equipo de desarrollo • Métricas en una buena gestión del ciclo de vida del desarrollo • Asegurando la

calidad final • Experiencias en la implantación de metodologías ágiles con VSTS

ALM ’08

Bienvenido al número 52, de octubre de2008, de dotNetManía.

El día 16 de octubre se celebra en Madridel Microsoft ALM´08 Sessions, el primerevento sobre el Ciclo de Vida de las Aplica-ciones (ALM) con tecnologías de Microsoft,donde sus principales partners y expertos dela talla del Dr. Ivar Jacobson, el Prof. GilTaran o el vicepresidente de área del Oestede Europa de Microsoft Internacional, Pie-rre Liautaud, expondrán más 20 ponencias.La asistencia esperada es de alrededor demedio millar de personas, lo que demuestrael enorme interés que este tema está susci-tando actualmente. Precisamente por estemotivo, nosotros hemos querido ligar estemonográfico sobre ALM a este evento —deahí el título de portada— haciéndolo coin-cidir en fechas y regalando un ejemplar atodos los asistentes.

La persona encargada de coordinar ysupervisar técnicamente los contenidos de estemes ha sido Luis Fraile, MVP de Team Sys-tem y una de las personas que más sabe deesto por estas tierras. Además, Luis se encar-ga igualmente de la coordinación técnica delas ponencias del citado evento, ALM’08. Élmismo presenta los artículos del mes en suartículo, cuyo original título es “EspecialApplication Lifecycle Management”.

Este monográfico nos sirve para comen-zar una nueva sección sobre esta temática, a laque hemos llamado ALManía (puede leersecomo Alemania, para mayor confusión), y quecada mes podrá seguir desde estas páginas.

Como podrá comprobar, éste es el ejem-plar con menos código que hemos editado

hasta la fecha. dotNetManía es una revistade código —hemos dicho siempre—, y asíseguirá siendo, pero esta nueva sección vadirigida más a directores de desarrollo, jefesde producto, arquitectos de software o cual-quier persona con responsabilidades sobrelos equipos de desarrollo de software, y nonecesariamente incluirá código.

Al margen de todo esto, le recomiendola entrevista que Marino Posadas mantuvocon Pat Helland, uno de los arquitectos deDTC (Distributed Transaction Coordinator) yMicrosoft Transaction Server, otro de losgrandes que pasan por nuestras páginas, quelo mismo nos da su visión sobre el futuro dela tecnología en su ámbito, que nos habla deinteligencia artificial, o que nos recuerda altristemente desaparecido Jim Gray, otro delos grandes que nos dejó también sus pala-bras al comienzo de nuestra andadura comorevista.

Por más que algunas personas despre-ciables nos hagan dejar de creer en el serhumano, siempre habrá otros, como mi ami-go Guille, que nos hacen tener una ciertaesperanza. Guille acaba de comenzar una girapor toda España, Guille Community Tour2008, donde expondrá principalmente sobrelas mejoras del nuevo Visual Basic (VB9) yLINQ. Guille no solo no cobrará un euro,sino que hará un esfuerzo por recaudar dine-ro para la lucha contra la enfermedad de Ale-xander y continuar con su ayuda a Juanma(www.ayudajuanma.es). Si usted asiste, quizápueda ayudar a la causa.

Por este mes, esto es todo. Espero quenuestro trabajo sea de su agrado.

ALManía

editorialDedicada a los profesionales de la plataforma .NET

Vol. III •Número 52 • Octubre 2008Precio: 6,50 €

EditorPaco Marín (paco.marin@netalia.es)

Redactor jefeMarino Posadas(marino.posadas@netalia.es)

RedacciónDino Esposito, Guillermo 'Guille' Som, LuisMiguel Blanco y Miguel Katrib (Grupo Weboo)

Empresas colaboradoras

Alhambra-Eidos

Krasis

Plain Concepts

Raona

Solid Quality Mentors

Además colaboran en este númeroJesús Jiménez, Jordi González, Juan CarlosViñas, Luis Fraile, Magda Teruel y RodrigoCorral.

IlustracionesPortada: Javier Roldán

Atención al suscriptorPilar Pérez (pilar.perez@netalia.es)

Edición, suscripciones y publicidad.netalia

c/ Robledal, 13528522 - Rivas Vaciamadrid (Madrid)

www.dotnetmania.com

Tf. (34) 91 666 74 77Fax (34) 91 499 13 64

ImprimeGráficas MARTE

ISSN1698-5451

Depósito LegalM-3.075-2004

dotNetManíadotNetManía

Paco Marín

Cada uno debe estar consigo mismo; ése es el premio de los bondadosos y el castigo de los despreciables. Quiero dedicar este ejemplar a mi muy querida hermana Magdalena, bondadosa y fuerte.

sumario 52Entrevista a Pat Helland 09-12

Como otras veces, no era uno de los “entrevistables” oficiales para la organización de Tech·Ed, perola buena voluntad personal hizo posible lo que la administración no contemplaba de inicio. PatHelland, uno de los arquitectos de DTC (Distributed Transaction Coordinator) y MicrosoftTransaction Server, ahora dedicado más a aspectos de arquitectura de aplicaciones, se reunía connosotros en la Sala de Prensa y mostraba el mejor y más amable de sus tonos después de una sesióntécnica poco habitual.

Especial Application Lifecycle Management 14-15En este número vamos a acercarnos un poco más al mundo del ciclo de vida del software y, sobretodo, a cómo vamos a implementar los procesos y realizar las tareas mediante las herramientas deVisual Studio Team System.

Visual Studio Team System… ¿Y esto qué es? (un poco de anatomía) 16-20Después de llevar un tiempo escribiendo en mi blog acerca de Team System, dando charlas acerca deeste producto y mareando a mis amigos sobre sus bondades, me he dado cuenta de que, a veces, noestá muy claro qué es este producto (más bien conjunto de productos), para que sirve..., en fin, lobásico. Y para ello, me he decidido a escribir este nuevo artículo, a ver si dejamos las dudasaclaradas.

Escogiendo metodología y organización de equipo 22-26El desarrollo de software es cada vez una tarea más compleja, en la que intervienen diferentes rolesy que comprende un buen número de etapas y actividades. Para llevar a cabo esta tarea, deberemoscontar con una metodología que nos ayude a completarla con éxito, reduciendo los riesgos y haciendoel proceso más predecible y eficiente.

La importancia del equipo de desarrollo 28-34Visual Studio Team System nos ayuda a gestionar el ciclo de vida del desarrollo de software, cuyapieza 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 funcionalidadesque usamos cada día cuando desarrollamos.

Métricas en una buena gestión del ciclo de vida del desarrollo 36-41Son muchas las variables que intervienen en el éxito o fracaso en el desarrollo del software, puesellas 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 elestado de nuestro desarrollo.

Asegurando la calidad final 42-48Una parte importante del proceso de creación de software pasa por asegurar los requerimientos decalidad del producto. Team System Test Edition nos ayuda a incorporar el cumplimiento de esoscriterios en todo el ciclo de vida del desarrollo. En este artículo exploraremos las herramientasdisponibles y las buenas prácticas que nos ayudarán a conseguir nuestro objetivo.

Experiencias en la implantación de metodologías ágiles con VSTS 49-53Cuando Microsoft lanzó Visual Studio Team System hace unos cuatro años, muchos desarrolladoresvimos cómo se cumplían nuestras expectativas de lograr que Visual Studio se convirtiese en unaherramienta 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 queacercase las metodologías a los equipos de desarrollo, con independencia de la metodología elegida ydel tamaño del equipo de desarrollo. En este artículo pretendo compartir lo aprendido en estos añossobre la implantación de metodologías ágiles con Team System, las dificultades encontradas, cómo lashe abordado y qué resultados he obtenido.

dnm.todotnet.qa 55-57Preguntas comunes a los patrones de diseño¿Qué es una excepción sino algo excepcional en el ciclo de vida de una aplicación? ¿Y cómo debe manejarse?¿"In-situ" o de forma centralizada? Este mes discutiremos el manejo de excepciones en ASP.NET y cómomanejar múltiples formularios.

dnm.desvan 58

El 25 de septiembre Microsoftanunció la primera Release Candi-date de Silverlight 2 (RC0) tantopara Windows como para Mac. Setrata solo de la versión para desa-rrolladores que incluye el Silver-light Developer Runtime (así comoMicrosoft Silverlight Tools forVisual Studio 2008 SP1 y Micro-soft Expression Blend 2 ServicePack 1 Preview que le dan sopor-te), pero que, curiosamente, no escompatible con las betas anterio-res, aunque sí lo será con la versiónfinal. Los usuarios de Silverlight1.0 o de cualquiera de las betas,recibirán una notificación de actua-lización automática cuando seencuentre disponible la versióndefinitiva.

Fechas oficiales no hay, perosería extraño que en uno de los 2grandes eventos que se avecinan(PDC a finales de octubre oTech·Ed EMEA a primeros denoviembre), no viese la luz defini-tivamente.

La funcionalidad ya está cerra-da, y los días restantes para la sali-da de la RTW (Release-To-Web) sonde ajustes y arreglo de algunos bugsy otros aspectos de distribución. Larazón de sacar esta versión es la defacilitar a los desarrolladores unaúltima comprobación del códigopara evitar que los cambios que lle-va esta versión, y que llevará la ver-sión definitiva, provoquen erroresen las aplicaciones que hay en pro-ducción en este momento.

Hay un buen conjunto de cam-bios, bugs corregidos y mejoras derendimiento. Los cambios puedenverse en profundidad en un docu-

mento en el sitio oficial (http://silver-light.net) o en el blog de Mike Snowen http://silverlight.net/blogs/msnow/archive/2008/09/25/silverlight-version-2-rc0-release.aspx, entre los que desta-can algunas reubicaciones de ele-mentos en la jerarquía de clases, nue-vo aspecto de las plantillas de todoslos controles (incluso alguna ha cam-biado de nombre), la presencia delos controles ComboBox, ProgressBary PasswordBox, ADO.NET DataServices (Astoria) ha sido actualiza-do y, ahora, la edición desde Expres-sion Blend requiere la versión 2.0SP1 (descargue, si lo necesita, unaversión de prueba desde aquí:http://www.microsoft.com/downloads/details.aspx?FamilyId=5FF08106-B9F4-43CD-ABAD-4CC9D9C208D7&dis-playlang=en).

Más información sobre estanoticia en el blog de Scott Guth-rie en http://weblogs.asp.net/scottguen inglés o en castellano con la tra-ducción de Thinking in .NET enhttp://thinkingindotnet.wordpress.como en el blog de Tim Heuer enhttp://timheuer.com/blog.

dotN

etM

anía

<<

6

noticiasnoticias

noticias

noticias

noticias

Silverlight 2 Release Candi-date disponible Esta versión, previa a la versión definitiva, que seespera aparezca pronto, es únicamente paradesarrolladores

Alhambra-Eidos

Máster Alhambra-Eidos enDesarrollo Software

El ya clásico Más-ter Alhambra-Eidos de Desa-rrollo Software de

Alhambra Eidos abre una nueva edi-ción en su modalidad blended —40% dehoras presenciales en clase frente a un60% de autoestudio con tutorización—con horario de impartición presencialen viernes tarde y sábados mañanas.

Este Máster incluye documenta-ción oficial y propia en castellano y pre-para la certificación MCPD Enter-prise con exámenes de prueba, sesio-nes de asesoramiento, etc.

El Máster dará comienzo el 21 denoviembre del 2008 y finalizará el 30de mayo. Consta de 176 horas lectivaspresenciales y 255 horas de autoestu-dio aproximadamente.

Para efectuar cualquier consul-ta, o simplemente para reservar suplaza en el Máster Alhambra-Eidosde Desarrollo Software, utilice for-maciontic@a-e.es o llamando a losteléfonos 917872300 - 902313505 oen http://www.alhambra-eidos.es.

raona

Silverlight 2: Refresh your Web Applications

El próximo 11 denoviembre en

Madrid y el 12 de noviembre en Bar-celona, se realizará en las respectivasinstalaciones de Microsoft el semina-rio “Silverligth 2: Refresh your WebApplications” de la mano del equipo deUser Experience raona.

Más información en http://www.rao-na.com.

Alhambra-Eidos ha actualizado su yaclásico Master Blended para cubrir laformación de desarrolladores con lasúltimas tecnologías de Microsoft.

Di que nos leesTendrás un 5% de descuento

dotN

etM

anía

<<

7

<<dnm.directo.noticias

Bajo el lema “¡Vive un día diferente en

tu universidad!”, Microsoft Ibérica

comienza una gira por algunas Univer-

sidades españolas en las que presentará

a los estudiantes las novedades tecnoló-

gicas de la compañía. La gira comienza

en octubre y concluirá a finales de

noviembre.

La agenda de sesiones es:

• 10.00-10:15 Bienvenida.

• 10:15-11:45 Desarrollo web: más

allá de HTML.

• 11:45-12:00 Descanso.

• 12:00-13:00 XNA 2.0: Cómo

hacer tus propios juegos.

• 13:00-14:30 .NET fuera del PC:

robótica, móviles y dispositivos.

Las ciudades por las que pasará el

Microsoft University Tour ‘09 son: Sevi-

lla, Málaga, Almería, Alicante, Valencia,

Bilbao, Oviedo, A Coruña, Alcalá, Madrid,

Madrid- Politécnica, Valladolid, León,

Barcelona, Pamplona, Albacete.

Si desea registrarse, puede hacerlo

en: http://www.microsoft.com/spanish/msdn/academico/univers i tytour.mspx.

Guillermo “Guille” Som, redactor de estarevista y brillante ponente, va a realizar unagira por España desde el 26 de septiembreal 19 de diciembre con fines solidarios, don-de expondrá principalmente sobre las mejo-ras del nuevo Visual Basic (VB9) y LINQ.En algunas ciudades se verá arropado porotros ponentes de la talla, por ejemplo deDavid Salgado.

Guillermo quiere concienciar a los asis-tentes para que aporten su granito de are-na para ¡Ayuda a Juanma a vivir! (www.ayu-dajuanma.es), causa por la que viene luchan-do estos últimos meses y que desde dot-NetManía, modestamente, también hemosayudado a difundir.

Entre los asistentes que hagan unapequeña aportación a esta causa se sor-tearán premios cedidos por varias enti-dades colaboradoras:

• 1 Visual Studio 2008 Profesional o2 suscripciones MSDN Premiumcon Visual Studio Team System2008 Team Suite.

• 10 Packs de productividad queincluye Resharper y dotTrace,

• 16 libros de Novedades de VisualBasic 9.0 (uno para cada evento).

• 16 libros de Novedades de C# 3.0(uno para cada evento).

• 64 suscripciones a la revista dot-NetManía (3 de 3 meses y 1 de unaño por cada evento).

Los grupos de usuarios que acogeránestos eventos son: Málaga .NET UserGroup, MadridDotNet, ValenciaDev,LonetCamp, BcnDev, CatDotNet,Spain.NET, AndorraDotNet, Navarra-DotNet, GuseNET, CLMNET, Onoba-NET, Nuberos.NET, Artalde, .NET UserGroup Galicia y Baleares on .NET.

Para registrarse a alguno de los even-tos puede ir a www.microsoft.com/spa-nish/msdn/spain/eventos/communitytour.mspx,y para más información puede visitar supágina en www.elguille.info/lonuevo/2008/sep-tiembre/10_Guille_Community_Tour_2008_GCT2008.aspx.

Guille Community Tour 2008Gira solidaria

Microsoft TourNET ‘08En este mes de octubre comienza la girapor España llamada Microsoft TourNet‘08, que se divide en tres partes, depen-diendo de la audiencia: Microsoft Tech-Net Technology Tour ‘08 para técnicosde sistemas, The Partner Show, una jor-nada de índole comercial para partners yThe Innovation Day para desarrolladoresde la plataforma .NET.

The Innovation Day está dedicado ala plataforma y herramientas de desarro-

llo Web de Microsoft y la charla de doshoras versará sobre el futuro de las apli-

caciones Web. Durante esta sesión se revi-sarán las tecnologías más punteras quepropone Microsoft para la creación de lafutura generación de aplicaciones webRIA.

Las ciudades que se visitarán son Valla-dolid, Valencia, Murcia, Tenerife, Las Pal-mas, Zaragoza, Barcelona, Santiago,Madrid, Sevilla, Bilbao. Más informacióny reservas en: http://www.microsoft.com/spa-nish/msdn/spain/eventos/innovate.mspx.

dotN

etM

anía

<<

8

dnm.directo.noticias<<

Disponible Microsoft F# CTP deseptiembre 2008

Microsoft ha anunciado la disponibi-lidad de la versión Community Tech-nology Preview de septiembre de2008 del lenguaje F#, que incluye tan-to el compilador del lenguaje, comoherramientas, además de la integra-ción con Visual Studio 2008.

F# es un lenguaje de programa-ción funcional para .NET Frame-work. Combina el estilo sucinto,expresivo y compositivo de los len-guajes funcionales con el runtime,librerías, interoperabilidad y modelode objetos de .NET.

Puede tener toda la informacióny descargas desde el nuevo Micro-soft F# Developer Center enh t t p : / / m s d n . m i c r o s o f t . c o m /en-gb/fsharp. Fuente: blog de DonSyme (http://blogs.msdn.com/dsyme),principal artífice de este lenguaje einvestigador en Microsoft ResearchCambridge (ver entrevista en dot-NetManía nº45).

Krasis ha ce -rrado recien -te men te unacuerdo conM i c r o s o f t

Ibérica, por el cual podrá ofrecer enexclusiva cursos de formación on-linecreados y desarrollados directamen-te por Microsoft, integrándolos ensu propia plataforma de e-learning(Self).

A los cursos on-line tradicionalesincorpora una nueva modalidad en laque se sigue un calendario. Profesory alumno podrán reproducir una cla-se tradicional en directo en la que sepuede levantar la mano, preguntar,explicar individualmente o trabajar ala par sobre una misma aplicación.También da la posibilidad de seguirlas clases en diferido y completar laformación con las publicaciones enpapel de la editorial Krasis Press, que

contará en octubre con 2 nuevos títu-los. En el caso de las empresas, Kra-sis ofrece un servicio global queincluye asesoramiento y diseño deinformación personalizada a medida.

Según fuentes de la compañía,más del 90% de los alumnos que sehan matriculado en los cursos de Kra-sis los han superado satisfactoria-mente y 3 de cada 4 han repetidoexperiencia y realizado dos o más cur-sos. Para garantizar el éxito total,Krasis incorporará el servicio exclu-sivo Volunt-A-Matic en los cursos on-line de auto-aprendizaje. Se trata deun sistema de apoyo que hace segui-miento del trabajo realizado por elalumno recordándole actividades,eventos y fechas clave como garantíade aprovechamiento total de la for-mación.

Más información en la Web deKrasis: http://www.krasis.com.

KRASIS distribuirá los cursos on-line en castellano de Microsoft

La nueva edición del mayor eventode formación técnica para desarro-lladores celebrado en Europa se cele-brará, un año más, en Barcelona,entre los días 10 y 14 de noviembre,paralelamente, como en estos últi-mos años, al Tech·Ed EMEA 2008IT Pros.

Se espera una asistencia de algomás de 4.000 personas y, como siem-pre, asistirán los mejores ponentes,expertos de producto y los miembrosmás relevantes de la comunidad.

Aparte de las 200 breakout ses-sions, habrá 90 sesiones interac-tivas con expertos y laboratorios

donde explorar las novedades de lasherramientas y las plataformas másrecientes de Microsoft.

Sin duda, todo un acontecimein-to donde compartir experiencias yconocimientos con miles de colegas,y estar cerca de los expertos más reco-nocidos a nivel mundial.

El idioma oficial, como siempre,será el inglés. El precio es de 2.245€más el 16% de IVA. Aún puede reser-var su plaza desde http://www.micro-soft.com/emea/teched2008/developer.

Microsoft Tech·Ed EMEA 2008 Developers Tech·Ed EMEA 2008 Developers y Tech·Ed EMEA 2008IT Professionals se celebrarán en noviembre de 2008 enBarcelona.

Microsoft bautiza la próxima ver-sión de Visual Studio como VisualStudio 2010

Microsoft ha bautizado ya a la nuevaversión de Visual Studio como VisualStudio 2010 (codename Visual Studio10), lo que no quiere decir que apa-rezca en dicho año –pudiera ser inclu-so antes–, y que acompañará a .NETFramework 4.0.

Junto con el anuncio oficial delnuevo nombre, Microsoft ha descri-to a grandes rasgos cuál será el espí-ritu de la nueva generación de herra-mientas para los desarrolladores.

Más información en el sitio deVisual Studio en http://msdn.micro-soft .com/en-us/vstudio/products/cc948977.aspx. También puede veralgunos vídeos en Channel 9 enhttp://channel9.msdn.com/visualstudio.

Marino Posadas

Marino Posadas esredactor jefe de ddot-

NetMania y consultorindependiente. Es

MCP, MCSD, MCAD,MCT y MVP en Visual

C#.Puedes consutar su

página Web enwww.elavefenix.net

entrevista

entrevista a Pat HellandComo otras veces, no era uno de los “entrevistables” oficiales para la organización deTech-Ed, pero la buena voluntad personal hizo posible lo que la administración no con-templaba de inicio. Pat Helland, uno de los arquitectos de DTC (Distributed TransactionCoordinator) y Microsoft Transaction Server, ahora dedicado más a aspectos de arqui-tectura de aplicaciones, se reunía con nosotros en la Sala de Prensa y mostraba el mejory más amable de sus tonos después de una sesión técnica poco habitual.

dotN

etM

anía

<<

11

dnm.directo.entrevista<<

De acuerdo con tu biografía,entraste en Microsoft en 1994. Eranlos tiempos de Windows 3.1 y Win-dows NT. ¿Qué es lo que hacías enesa fecha?

Así es. En aquellos tiempos mi laborinicial fue participar en la creación deMTS y —en general— de los quellamábamos “Enterprise Computing”,que era un reto en los tiempos inicialesde Windows NT. Luego estuve invo-lucrado en otros proyectos de bases dedatos. Dejé Microsoft durante dos años,en los que pasé por Amazon. Y ahoraestoy encantado de haber vuelto aMicrosoft desde marzo de 2007. Fun-damentalmente, creo que echaba demenos hablar con el público. Me gustómucho el tiempo que estuve en Ama-zon, pero no quiero perder ese contac-to con el público, y Microsoft me dasiempre esa oportunidad.

La última charla que te escuché fuebastante inusual. Se titulaba “Metró-polis: Interchangeability of Opera-tions”, y daba la impresión de que obe-decía a eso que tanto se dice ahora de“revisitar” los viejos conceptos paradarles un aire nuevo. ¿Es así?

Creo que es una consecuencia de mitrabajo inicial con MTS, cuando aso-ciábamos componentes y transacciones.Las cosas están cambiando y de formaimportante. Y los conceptos básicos quemanejamos tienen que evolucionarparalelamente.

Para hacerlo más comprensible,decidí explicar estos conceptos en tér-minos de lo que sucede en una ciudad.Hacer entender que estas ideas queestán en el software, no son solo partede los recursos de un sistema informá-tico, sino que son procesos que se danen otros entornos. Y esto es especial-mente cierto, desde el momento en quepasamos de los sistemas tradicionales alos conectados gracias a Internet.

El otro tema crucial es cómo pode-mos reescribir o adaptar nuestro soft-ware a los nuevos sistemas (Data Cen-ters, sobre todo), basados en ordena-

dores más baratos que, trabajando enparalelo, consiguen rendimientos muysuperiores y más tolerantes a fallos quelos grandes mainframes. Hay muchosaspectos del software que deben cam-biar para adaptarnos a esto. Aspectoscomo la redundancia de la informacióny su tratamiento adecuado, la toleran-cia a fallos, etc.

Te refieres a que hay cambios enel hardware que posibilitan cosasnuevas o facilitan las que antes erandifíciles, y eso conlleva que se pro-duzcan cambios en el software quefunciona sobre ellas y en la mejormanera de programarlo. Cambiar elmodelo, vamos…

Exactamente. Y hago mías las pala-bras que comentabas antes del inicio dela entrevista, sobre la importancia delSoftware as a Service. Es cierto quepodemos considerar —en buena par-te— las aplicaciones actuales como unservicio con una interfaz de usuario.

Estamos muy acostumbrados a lla-mar a métodos de objetos que implicanuna tremenda carga de procesamientopor debajo. Y convendría que, al menosdurante algún momento del análisis,

tuviéramos en cuenta esas implicacio-nes para evitar sorpresas.

Si analizas lo que pasa de verdadcuando haces una llamada cualquiera,verás que, realmente, se ponen en mar-cha montones de componentes quehablan unos con otros. Tanto es así, que,personalmente, tengo dificultades parautilizar la palabra aplicación en su sen-tido tradicional, porque este conceptode software tiene muchas barreras, lími-tes en el dominio y el ámbito que lasaplicaciones de hoy tienden a diluir, alestar todo interconectado.

Lo que nos lleva a la importanciade los estándares de comunicación.Cuantos más sistemas y aplicacionestengan que conectarse entre sí, másimportante será que lo hagan utili-zando un lenguaje común. ¿Creesque la implantación que tiene XMLen el mundo del software actual hasido crítica en ese aspecto?

Sé que es raro decir esto, pero meencanta XML. No es que me gustenespecialmente las etiquetas. Lo que megusta es la forma en que ha sustituidoa muchas representaciones binarias conla ventaja de poder ser leído y modifi-

Pat Helland y Marino Posadas en un momento de la entrevista

cado de forma simple. En una de mischarlas de las serie “Metrópolis”, habla-ba precisamente del rol de los bienes deconsumo que se desplazan entre dis-tintos edificios, que es muy similar a laimagen de los mensajes viajando entredistintos servicios.

En una compañía, cuando has ter-minado un trabajo que tiene que sertransportado a otra parte, y no puedeshacerlo de forma electrónica, guardasel trabajo en un sobre protector, y loetiquetas para que se sepa quién lo man-da y quien lo debe de recibir. XML haceeso exactamente. Protege el contenidoque alberga, lo etiqueta para que se sepade qué tipo es su contenido, y estable-ce quién es el emisor y el destinatario.Lo que importa es el costo de la semán-tica implicada en el proceso. Si el sobrese pierde, cualquiera que lea su cubier-ta puede reencaminarlo a su destino.

Parece que otro de los concep-tos que estás —digámoslo así—redefiniendo es lo que puede consi-derarse síncrono y asíncrono…

Si, por supuesto. La gente utilizaestos términos de forma muy subjetiva.Cuando se dice “esto es una llamadasíncrona”, quieren decir “…respecto alhilo de ejecución que hizo la llamada”.Y hay muchas operaciones que son sín-cronas en cierto sentido y asíncronas enotro. Y un ejemplo excelente de estoestá en la implementación de SQL Ser-ver, donde hay procesos en los que sedebería distinguir claramente quemuchas llamadas son síncronas respec-to a la hebra de ejecución (Thread) perono respecto al hilo de ejecución (Fiber),que incluso puede llegar a ser distintoque el que comenzó el proceso. Y, pormuy síncrona que sea una llamada, —en este ejemplo— tendrá que esperar aque otro proceso tenga los datos o losresultados listos para ser manejados porel llamador, y se deberán tener en cuen-ta otro montón de cosas, etc.

Esto tiene mucho que ver conuna de tus afirmaciones respecto a

los datos manejados “por dentro”, ylos datos manejados “por fuera”(“Data in the inside vs. Data in theoutside”) y la importancia que tieneesa separación desde el punto de vis-ta arquitectónico.

Porque esto es algo que arrastramosdesde los viejos mainframes, dondeexistía un gran ordenador y una base dedatos. Pero ya llevamos años haciendocomputación distribuida, y —sobretodo— haciendo que un grupo de orde-nadores se comporte como si fuera unosolo. Y puedo tener varios servicios eje-cutándose en un solo ordenador, omontar un servicio compuesto, funcio-nando en más de un ordenador. Así que,¿dónde están los datos? ¿dentro o fue-ra? y ¿dentro o fuera de qué? Cuandoesas preguntas, o mejor, sus respuestasestán claras para el arquitecto, los pro-blemas potenciales se solucionanmucho mejor. Y muchas veces, hay másde una forma de mirar al problema.

De hecho una de las cosas que quie-ro hacer ahora es llevar estas ideas a lapráctica con un nuevo producto, queprobablemente dirigiré, y que podríaestar listo para dentro de unos dos añosdesde este momento. Pero, permítemeque no comente más de esto aún.

¿Qué es lo que más echas demenos respecto a las buenas prác-ticas del software que hacemos hoyen día?

Una de las cosas que echo de menoses que no se tiene en cuenta los límitesde muchas de las aplicaciones que sehacen hoy y los límites implicados ensus procesos, saber realmente qué es loque significa salir de esta frontera lógi-ca para entrar en otra, y las implicacio-nes. He podido llegar a ver cómo todoesto se mezclaba en modelos que —enseguida— caían en la obsolescenciadebido a esta falta.

Se necesita que las aplicaciones ten-gan en cuenta —al menos que aparez-ca en la fase de análisis— la posibilidadque deban comunicarse con otras apli-caciones o servicios, que —probable-mente— no existan todavía en elmomento de escribir esa aplicación,pero que existirán en el futuro. El con-cepto de acoplamiento débil no es unamoda, es una necesidad en el softwarede hoy.

Con todo el riesgo que conlleva,siempre me gusta terminar pulsan-do la opinión que el entrevistado tie-ne sobre el futuro de la tecnologíaque es su especialidad.

Pongamos unos 10 años desde estemomento. Espero que los chips tenganunos 500 procesadores, y tenemos queseguir en la línea de los ordenadores debajo consumo y gran potencia conse-guida por el procesamiento paralelo.

Mi amigo James Gray —trágica-mente desaparecido en el mar hace un

Cada vez que hay algo relacionado que se prueba de utilidad, la comunidad no tiene muy claro si se trata de redes neuronales,

sistemas expertos, IA pura o qué

dotN

etM

anía

<<

12

dnm.directo.entrevista<<

dnm.directo.entrevista<<

año— hacía unos análisis científicos dela situación del almacenamiento y de sucrecimiento que resultan esclarecedo-res. El crecimiento de la memoria Flashy los dispositivos asociados será cadavez más importante, porque es de bajoconsumo, fundamentalmente. Y laspantallas planas de bajo consumoseguirán su crecimiento, de la mismaforma que aparecerán las pantallas ple-gables y otros dispositivos basados enla electrónico de consumo mínimo, quetambién supondrán un cambio notorioen la forma en que se vivirá la informá-tica por parte de los usuarios.

Habrá enormes cantidades de pro-cesos informáticos, pero lo que no vere-mos, probablemente, será ordenadorespersonales que vayan mucho más rápi-do que lo que van hoy en día. Por lotanto, si divides el trabajo en dos cla-

ses, verás que esas clases son: aquellastareas que pueden ser abordadas enparalelo, y las que no. Las primerasserán cada vez más baratas y las segun-das, más complejas y caras. De ahí lanecesidad de modificar la forma en quehacemos las aplicaciones hoy.

¿El desarrollo de la InteligenciaArtificial aplicada a las aplicacionesde gestión tradicional podría ayudaren esa tarea?

En la universidad, estuve muyinteresado en ese tema. Creo que esfascinante y que, constantemente,genera tecnología de utilidad. Aun-que, cada vez que hay algo relaciona-do que se prueba de utilidad, la comu-nidad no tiene muy claro si se tratade redes neuronales, sistemas exper-tos, IA pura o qué.

Sin embargo, la estamos utilizandosin darnos cuenta muchas veces, ligadaa tecnologías como Intellisense, anali-zadores sintácticos, reconocedores devoz, y muchas otras áreas no tan evi-dentes. Incluso los juegos de ajedrezeran IA hasta que estuvieron funcio-nando los primeros modelos. Pero creoque la IA se convertirá, poco a poco, enun valor añadido importante.

Me decías que eres un amante deBarcelona, ¿no?

Absolutamente. Ya he estado otrasveces y es una ciudad que me encanta.Espero tener la oportunidad de cono-cer más España, ahora que estoy vol-cado en labores de divulgación.

Así lo esperamos, y gracias portus palabras.

al especial de ALM de dotNetManía! En estenúmero vamos a acercarnos un poco más al mundo del ciclo de vidadel software y, sobre todo, a cómo vamos a implementar los pro-cesos y realizar las tareas mediante las herramientas de Visual Stu-dio Team System. Al principio de los tiempos del desarrollo de soft-ware, los desarrolladores simplemente hablaban con el cliente sobrela tarea a realizar, y después se iban a su lugar de trabajo, y la com-pletaban. Normalmente eran tareas cortas de pocos días, se hacíala compilación, las pruebas, y se volvía al cliente para ver si era esolo que quería. Como podemos suponer, las aplicaciones eran sen-cillas, así como las computadoras tenían menos capacidad, y habíamuchos menos usuarios de las aplicaciones.

A medida que las aplicaciones se iban haciendo más comple-jas, las máquinas iban ganando en capacidades, cada vez había másusuarios involucrados alrededor del desarrollo de las aplicacio-nes, se necesitaban nuevos métodos de comunicación que per-mitiesen gestionar esta complejidad. Se empieza a requerir de unadocumentación, mayor burocracia y mayor control, y se ideabannuevos métodos de comunicación en forma de esquemas.

De este modo se llega a la primera “metodología”, el desa-rrollo en cascada. Esto era simplemente, ir al cliente, recogerlos requisitos, hacer el análisis, se hacía el desarrollo, se proba-ba y se implementaba; entre cada una de estas fases se revisabael proceso con las personas involucradas, pero los requisitossiempre se hacían permanecer estables a lo largo del proyecto,porque con este sistema era muy costoso cambiar algo.

Sin embargo, cada vez hay más usuarios, mayor necesidadde aplicaciones, mayores capacidades en los ordenadores, ytodo esto genera mayor complejidad en las aplicaciones. Debi-do a esto, necesitamos nuevos métodos de control de la ges-tión de los proyectos de desarrollo de software. Aquí empie-zan a nacer las primeras metodologías que nos ayudan a con-trolar todo esto.

especialApplication LifecycleManagement

<< ¡Bienvenidos

Luis Fraile es MVP deTeam System y

colabora activamen-te en MAD.NUG

(grupo de usuariosde .NET de

Madrid). Actualmen-te es director técni-

co en Multidomo Networks, dondedesarrollan un pro-ducto de softwarepara la gestión de

dispositivos domóti-cos y cámaras de

vigilancia a través deInternet mediante

interfaces Web, telé-fonos móviles, Media

Center, etc. Puedecon sul tar su blog en

www.lfraile.net.

ALManía

Luis Fraile

Por supuesto, como toda metodología, por ligera oágil que sea, lleva implícita una serie de procesos defi-nidos, desde la realización de pruebas unitarias, “histo-rias de cliente” como en eXtreme Programming, los dailyscrums de Scrum o las evidencias necesarias en proyec-tos con CMMI. Todos estos procesos nos llevan a unanecesidad cada vez mayor de herramientas que nos ayu-den a gestionar todos estos procesos.

Antes de todo esto, ya teníamos herramientas muypotentes para hacer documentación, como las herra-mientas de UML. Sin embargo, a la hora de integrarsecon otras herramientas, surgían problemas con lo que,si bien nos resolvían partes del proceso, seguían sindar una solución integrada para todas las partes delproceso.

Además, con la mayor complejidad de los proce-sos y las metodologías, aparecen roles específicos den-tro del proceso de desarrollo, como los jefes de pro-yecto, arquitectos, desarrolladores, probadores, espe-cialistas en bases de datos, cada uno de los cuales tie-ne unas necesidades de herramientas distintas, perotambién tienen partes comunes a la hora de, por ejem-plo, gestionar sus tareas.

En este número especial de dotNetManía, quere-mos compartir con los lectores una introducción a lasherramientas de ciclo de vida de Microsoft. Con lafamilia de productos que componen Visual Studio TeamSystem —esta es un conjunto de productos que tieneherramientas específicas para cada uno de los roles quecomponen un proyecto de desarrollo—, así como deherramientas comunes capaces de dar respuesta a lasnecesidades de proceso de la metodología que estemosusando. Con el propio producto ya tenemos dispniblesdos metodologías: MSF Agile y MSF para CMMI. Ymediante la extensibilidad del producto, podemos darcabida a otro tipo de metodologías como Scrum, ya queuno de los puntos más importantes de estas herramien-tas es esta extensibilidad, que nos permite adaptarlas ala metodología que estemos usando.

Empezaremos esta serie de artículos con un artí-culo de introducción en el que explicaremos qué pro-ductos componen Visual Studio Team System, tantolas orientadas a cada uno de los roles cubiertos, comolas herramientas que usarán todos los roles en con-junto para la gestión del proceso.

Después de esta breve introducción, continuare-mos hablando de las metodologías, ya que alrededorde ellas se construye todo lo demás, los roles, las tare-as, los procesos... Las metodologías son el “cerebro”que va a gestionar todos nuestros procesos, por tan-to, son parte fundamental de todo; ellas son las quenos dictan los procesos a seguir, y en este artículoveremos cómo se integran las metodologías dentrode Team System.

También trataremos en los siguientes artículosde determinados roles dentro del proceso. Porsupuesto uno de los roles que trataremos es el deldesarrollador, puesto que es de vital importancia, alser el responsable del código que se generará parala aplicación que estemos desarrollando, y que es, afin de cuentas, lo que mayor valor aportará a nues-tros clientes.

En otro artículo veremos qué métricas genera-les de los proyectos podemos obtener con TeamSystem y cómo podemos usarlas de modo descrip-tivo para saber qué es lo que está ocurriendo en elproyecto y tomar las decisiones adecuadas. Es muyimportante recalcar aquí que todos estos datos sondescriptivos, nunca prescriptivos, son indicadoresde lo que está ocurriendo, y será responsabilidaddel equipo interpretar lo que está ocurriendo ydeterminar el modo de actuar.

Evidentemente, durante el proceso de desarro-llo, tenemos que tomar decisiones, tener controldel proceso, saber las tareas que tenemos pendien-tes, la calidad general y un montón de datos quenos influirán en las decisiones a tomar.

También hablaremos, como punto final, de unaexperiencia real de un proyecto largo en el que seestán usando las herramientas de Team System enconjunción con una metodología como Scrum congran éxito.

Y, por ahora, esto es todo. Esperamos seguir con-tando más acerca de este producto y del ciclo de vidadel software en general en próximos artículos de dot-NetManía.

dotN

etM

anía

<<

15

dnm.ALManía<<

Con Visual Studio Team System yatenemos dispnibles dos metodologías:

MSF Agile y MSF para CMMI. Y mediante la extensibilidad del

producto, podemos dar cabida a otrotipo de metodologías como Scrum

Entonces, ¿qué es Visual Studio Team System? Enpalabras de la gente de Microsoft, es una soluciónde Application Lifecycle Management. Está cla-ro, ¿no? Bueno, pues no tanto. Efectivamente, esuna solución de ALM, que incluye muchos pro-ductos de Microsoft para permitirnos gestionarnuestros proyectos de principio a fin. Esto es, des-de que ponemos el pie en la puerta del cliente, has-ta que salimos de nuestro cliente y lo dejamos todoimplementado y preparado para su posterior man-tenimiento por otros equipos.

Lo primero quizá es definir ALM (aunque segu-ro que todos lo saben). ALM no es más que el ciclode vida de un proyecto. Y esto incluye todo lo queocurre en él, como la definición de escenarios,requisitos, gestión de tareas, gestión de riesgos,gestión de defectos, gestión de la documentación(sí, la documentación)... Todo esto en la parte degestión. Pero, ojo, hay mucho más, como gestiónde la arquitectura (manteniéndola al día, porsupuesto), la gestión del código fuente, pruebas,tanto unitarias como funcionales, gestión de la cali-dad del código fuente, requerimientos de calidad,seguridad, pruebas de carga, gestión de las compi-laciones… En fin, como ven, en el mundo del desa-rrollo del software no nos aburrimos :-).

Por supuesto, la parte principal de todo esto noson ni estas tareas, ni las herramientas que utilice-

mos, sino las metodologías de desarrollo que use-mos. Claro que esto es otro tema del que podríamoshablar durante horas, horas y horas… Simplemen-te, dejemos claro que debemos escoger una meto-dología de las ya existentes, ya sea ágil o formal, yllevarla a cabo de un modo estricto. Esto será lo queguíe nuestros proyectos para completar todas las tare-as que veíamos antes. Pero (y aquí entra Team Sys-tem) necesitamos herramientas que nos faciliten todoesto, y a ser posible desde un entorno integrado.

Ahora que ya tenemos claros los conceptos pre-vios genéricos, vamos a ver qué productos com-ponen Visual Studio Team System (figura 1).

Lo primero que tenemos que tener claro es ladivisión inicial que haremos en los productos deVisual Studio Team System (a partir de ahoraVSTS). Y es que, por un lado, tenemos los pro-ductos que instalaremos en un servidor, que seránuestro servidor de proyectos, y por otro lado, lasherramientas que instalaremos en los ordenado-res del equipo de desarrollo, ya sea para gestión olas herramientas de desarrollo.

Herramientas de servidorEn un proyecto de desarrollo de software, apartedel código fuente y de los binarios, tenemosmuchos otros elementos a gestionar, como son las

Visual Studio Team System…¿Y esto qué es? (un poco de anatomía)

ALManía

Luis Fraile es MVP deTeam System y cola-bora activamente en

MAD.NUG (grupo deusuarios de .NET de

Madrid). Actualmentees director técnico en

Multidomo Networks, donde

desarrollan un produc-to de software para lagestión de dispositivosdomóticos y cámaras

de vigilancia a través deInternet mediante

interfaces Web, teléfo-nos móviles, Media

Center, etc. Puede con -sul tar su blog enwww.lfraile.net.

Después de llevar un tiempo escribiendo en mi blog acerca de TeamSystem, dando charlas acerca de este producto y mareando a mis ami-gos sobre sus bondades, me he dado cuenta de que, a veces, no estámuy claro qué es este producto (más bien conjunto de productos), paraque sirve..., en fin, lo básico. Y para ello, me he decidido a escribir estenuevo artículo, a ver si dejamos las dudas aclaradas.

Luis Fraile

dotN

etM

anía

<<

17

dnm.ALManía<<

propias tareas, documentación, resul-tados de pruebas, informes de progre-sión, los defectos, los riesgos, escena-rios y muchos otros elementos.

Debemos tener estos elementos acce-sibles por cualquier miembro del equi-po, y por supuesto, que se tenga accesoa la última versión y a su histórico en casode ser necesario. De este modo, losmiembros del equipo pueden consultarsiempre la información actualizada.

Además, es importante que esterepositorio, además de almacenar todaesta información, nos permita acceder-lo desde cualquier sitio, y sobre todo,desde multitud de herramientas, per-mitiendo que cada miembro del equi-po acceda a esta información desde susherramientas habituales, como VisualStudio en el caso de los desarrollado-res o Microsoft Project y MicrosoftExcel en el caso de jefes de proyecto.

Otra funcionalidad que nos ha depermitir es generar informes acerca delestado de los proyectos, obteniendo lainformación del repositorio de datos,ya sea código fuente, tareas o resulta-dos de tests y compilaciones.

Ahora que ya sabemos qué necesi-tamos en el servidor, veamos cuál es larespuesta en el conjunto de VSTS. Y larespuesta es: Team Foundation Server.

Team Foundation Server

Team Foundation Server es la herra-mienta que va a almacenar todos estos

datos y nos va a permitir acceder a ellos(figura 2). Es una herramienta de servi-dor, y con esto quiero decir que necesi-tamos un sistema operativo de servidorpara su instalación.

Team Foundation Server necesita,además, de SQL Server 2005 paraalmacenar todos los datos de los pro-yectos. Aunque con el propio paquetede Team foundation Server, Microsoftnos provee una licencia de SQL ServerStandard para su uso exclusivo conTeam Foundation Server.

Además, también necesita de Share-point Services. Como muchos seguro queya saben, esta herramienta nos sirve pri-mordialmente (aunque no solo para eso)

como librerías de documentos, con la ven-taja en este caso de que se integra conTeam Foundation Server para gestionarde un modo integrado la documentaciónde nuestros proyectos. Este es un com-ponente gratuito y en la versión de TeamFoundation Server 2008 ya viene incor-porado en la propia instalación.

Con esta herramienta ya tenemosnuestro repositorio de proyectos, queserán creados en forma de lo que se lla-ma Team Projects (y que no hay que con-fundir con los proyectos y soluciones deVisual Studio, ya que esto es un nivelsuperior). En cada uno de estos TeamProject agregaremos nuestros proyectosy soluciones de Visual Studio a su repo-sitorio de código fuente (Source Control),las tareas, riesgos, defectos, etc., (en for-ma de Work Items) y los documentos alas librerías de Sharepoint creadas paraeste Team Project (mediante un site pro-pio de Sharepoint).

Si bien se podría hablar mucho acer-ca de Team Foundation Server, losTeam Projects, etc., no es éste el obje-tivo de este artículo. Simplemente que-remos detallar las partes de VSTS.

Una última recomendación en tor-no al servidor es que cuando vayan ahacer la instalación, presten especialatención a la guía de instalación y a losrequerimientos, ya que, aunque en suversión 2008 han creado una instala-ción francamente sencilla, un error en

Figura 1

Figura 2

dotN

etM

anía

<<

18

dnm.ALManía<<

la instalación nos provocará que el sis-tema no nos funcione correctamente.Por ello, os recomiendo seguir paso apaso las recomendaciones de la misma.

Team Build

Esta segunda herramienta de servi-dor es la encargada de ejecutar las com-pilaciones de nuestros Team Projects.Acerca de esta herramienta, que pode-mos instalar en el propio servidor deTeam Foundation Server o incluso enmaquinas de desarrollo (con WindowsXP SP2 en adelante), ya hemos habla-do en un artículo anterior en dotNet-Manía, y por tanto, no voy a pararmea detallarla. Les recomiendo que leanel anterior artículo (“Integrándonoscontinuamente”, dotNetManía nº50)dónde podrán ver cómo instalar y con-figurar las Team Builds.

Tan solo me gustaría recalcar quepara poder ejecutar las compilacionesde nuestros Team Project necesitamosuna máquina con la parte de Team Buildinstalada (desde el CD/DVD de TeamFoundation Server).

Herramientas de clientePor supuesto, simplemente con unrepositorio de datos no se hacen losproyectos; necesitamos herramientasque nos permitan realizar todas las tare-as de un proyecto de desarrollo de soft-ware, tanto gestión de tareas, codifica-ción de los proyectos, pruebas, etc.

Esto lo vamos a hacer mediante lasherramientas de cliente, que son aquellasherramientas que, conectándose a TeamFoundation Server, nos permiten com-pletar estas tareas. Por supuesto, aquí,como ya decíamos al principio, tenemosvariedad de herramientas dependiendodel perfil del miembro del proyecto.

Además, el sistema de extensibili-dad de Team Foundation Server, nospermite crear nuestras propias herra-mientas que se conecten a él para teneracceso completo a estos datos. Por ello,aquí simplemente resumiremos lasopciones básicas que tenemos conherramientas de Microsoft.

Team Explorer

Esta es la herramienta más básicade cliente, y siempre deberemos insta-larla por separado en su versión 2008.Lo podremos instalar tanto desde elDVD de Team Foundation Server,como desde los DVD de las distintasversiones de las herramientas de desa-rrollo de VSTS que detallaremos a con-tinuación.

¿Y qué es lo que hace esta herra-mienta?. Bien, como ya dije, es lo másbásico. Simplemente nos instala todolo necesario para acceder a Team Foun-dation Server. Después de instalarla, yaunque no tengamos Visual Studio,veremos que en “Inicio”/“Programas”tenemos una versión de Visual Studio2008. No nos asustemos. Simplemen-te hemos instalado el Team Explorer.

Arrancando esta versión de VisualStudio, y mediante el menú “Herra-mientas”/“Conectar a Team Founda-tion Server” nos permitirá conectarnosal servidor de Team Foundation Serverde nuestra compañía, mediante la ven-tana de Team Explorer (figura 3)

Al igual que antes y al igual que ocu-rrirá con todo el resto de los compo-nentes, no es el objetivo de este artícu-lo detallar cómo usar estas herramien-tas (cosa que haremos en futuros artí-culos), si no explicar su anatomía, porlo que no me detendré más aquí.

Un último apunte: esto debemosinstalarlo SIEMPRE. En cualquierequipo que vayamos a usar para acce-der a Team Foundation Server, inde-

pendientemente de que lo hagamos des-de una versión de Visual Studio, desdeProject, desde Excel o desde nuestraspropias herramientas. La única excep-ción a esta regla es el acceso a TeamFoundation Server mediante Team Sys-tem Web Access (TSWA), que al serWeb no necesita instalar nada en elcliente.

Visual Studio Team System XXXXEdition

Bueno, ya hemos visto lo que nece-sitamos para conectar a Team Founda-tion Server, vamos a ver ahora quévamos a usar para trabajar durante eldesarrollo.

Para esto tenemos distintas herra-mientas dependiendo que de nuestrorol en el proyecto (figura 4).Vamos a irviendo una por una.

Básicamente, todos los usuarios queacceden a Team Foundation Servernecesitan de una CAL (Client AccessLicense) para acceder a él, indepen-dientemente de qué herramientas uti-licen (aunque usen la Web o única-mente el Team Explorer). Lo impor-tante de estas versiones de Visual Stu-dio, radica en que, con el precio de cadauna de ellas, está incluido el precio deuna CAL de acceso a Team FoundationServer. Sabemos que el tema de licen-ciamiento de VSTS da para escribir unlibro entero…

Visual Studio Team System Architec-ture Edition

Si nuestro rol en el proyecto es elde arquitecto (bueno, no entraré en dis-cusiones sobre este polémico rol…), la

Figura 3

Figura 4

dotN

etM

anía

<<

19

dnm.ALManía<<

versión más adecuada para nuestroentorno de trabajo será Visual StudioTeam System Architecture Edition.Esta herramienta no es más que unaadaptación de Visual Studio al que se lehan agregado funcionalidades específi-cas para los arquitectos.

Como ya pueden imaginar, estasfuncionalidades nos permiten generarlos diagramas de todo el sistema a altonivel, tanto de los componentes del sis-tema como de la arquitectura de los ser-vidores donde desplegaremos nuestrasolución, permitiéndonos validar quenuestro entorno se adapta a las necesi-dades del sistema.

Otra de las ventajas de esta versiónes que nos permite mantener sincroni-zados nuestros diseños del sistema, conla implementación actual de los pro-yectos de Visual Studio de nuestro pro-yecto.

Visual Studio Team System Develop-ment Edition

Al igual que la anterior, ésta es unaversión de Visual Studio adaptada paralos desarrolladores. Ahora estarán pen-sando “¿es que Visual Studio Standardo Professional no son herramientas dedesarrollo?”. Por supuesto que lo son,pero con esta versión tenemos una seriede funcionalidades nuevas que nos per-mitirán mejorar la calidad de nuestrocódigo.

Estas funcionalidades son, por ejem-plo, las métricas de código, que nos per-miten comprobar datos como el índicede mantenibilidad de nuestro código,el número total de líneas de código,cómo de acoplado es (dependenciasexternas de las clases y métodos) y otrosdatos.

Más funcionalidades que tenemosdisponibles en esta versión son:• Diagramas de clases. La posibilidad

de incorporar a nuestros proyectosun diagrama de clases que se man-tenga constantemente sincronizadocon la realidad de nuestro código.

• Análisis de código estático. Que nospermite comprobar que nuestro códi-go está bien diseñado, que los nom-bres de métodos y variables están

correctamente escogidos y otra mul-titud de comprobaciones para ver lacalidad de diseño de nuestro código.

• Pruebas unitarias. Una herramientaintegrada en nuestro propio entor-no de desarrollo para generar prue-bas unitarias, ejecutarlas y compro-bar sus resultados, así como informesde cobertura de código.

• Herramientas de “profiling” de códi-go. Nos permiten detectar futurosproblemas de ejecución en cuanto arendimiento, uso de memoria, yotros parámetros.

Visual Studio Team System DatabaseEdition

Pues sí. Tal y como suena, una ver-sión de Visual Studio para los profe-sionales de bases de datos :-).

¿Y qué necesitan los profesionalesde bases de datos? Pues algunas de lasherramientas que nos permite esta ver-sión es:

• Integración de los proyectos de basede datos en el ciclo. Con esta herra-mienta podremos generar los scriptsnecesarios para crear las bases dedatos de nuestros proyectos, tenien-do funcionalidades como el refacto-ring, comprobación de erroresmediante la compilación y desplie-gue a nuestros entornos de datos. Ytodo mediante proyectos de VisualStudio que podremos integrar en elrepositorio de código fuente.

• Comparación de esquemas. Median-te esta funcionalidad podremos com-parar esquemas de dos bases de datoso de proyectos de bases de datos, paraexaminar sus diferencias y mante-nerlas sincronizadas en cuanto aesquema se refiere.

• Comparación de datos. Al igual queantes, esto nos permite comparar dosbases de datos, pero en este caso, envez de esquema, compararemos losdatos, permitiéndonos mantenerlassincronizadas en cuanto a contenido.

• Pruebas unitarias de procedimientosalmacenados. Si los desarrolladoreshacemos pruebas unitarias, ¿por qué

los profesionales de datos no? Conesta herramienta se nos proporcionael entorno para ello.

• Generación de datos de pruebaautomática. Ya sea aleatoria, median-te data binding y alguna opción más.

Como ven, es un conjunto de fun-cionalidades más que interesante paraintegrar a los profesionales de basesde datos en el ciclo completo de desa-rrollo.

Visual Studio Team System Test Edition

Una de las cosas más importantesen el desarrollo de software es la cali-dad, que además es de vital importan-cia que esté vigilada desde el principio.

Mediante esta versión de Visual Stu-dio Team System se nos permitirá tenerintegrada —desde el principio— estagestión de la calidad. Algunas de las fun-cionalidades que vamos a tener en estaversión son:

• Pruebas de sitios Web. Mediante lagrabación de una sesión de navega-ción, podremos ejecutarla posterior-mente para comprobar errores ygenerar pruebas de carga.

• Pruebas de carga. Mediante la utili-zación de pruebas unitarias o prue-bas Web, podemos generar pruebasde carga para simular distintos mode-los de carga de usuarios, navegado-res, condiciones de red y examinar,tanto en tiempo real como a poste-riori, los resultados sobre distintosparámetros del servidor en el quehemos ejecutado las pruebas, comouso de procesador, fallos, memoria yen general contadores de rendi-miento.

• Pruebas manuales. También pode-mos crear las pruebas manuales quese generarán como documentos depruebas tradicionales, con la ventajade estar incluidos en nuestro reposi-torio de proyectos, dentro de pro-yectos de testing de Visual Studio. Yademás, podemos almacenar losresultados en el repositorio de TeamFoundation Server.

dotN

etM

anía

<<

20

dnm.ALManía<<

Visual Studio Team System Team Suite

Ésta es la herramienta que todo desarrolladorquerría tener instalada para trabajar con Team Sys-tem, ya que todas las versiones que hemos comenta-do anteriormente vienen incluidas en ella.

Realmente no trae ninguna otra funcionalidad,pero sí incluye todo lo que las anteriores. Por supues-to, es la más cara de todas.

Microsoft Project y Microsoft Excel

Cuando instalamos Team Explorer en un equipo quetiene instalado también Microsoft Office y/o MicrosoftProject, se nos instalan unos componentes adicionalesde Visual Studio Tools for Office que nos permiten conec-tar Project y Excel con Team Foundation Server.

¿Y cuál es el objeto de esta conexión? Sencillo. Yahemos dicho que una de las cosas que tenemos en elTeam Foundation Server son las tareas, defectos, esce-narios, etc. Mucha información, que está guardada enunas unidades de datos que se llaman Work Items. EstosWork Items (WI) los podemos manejar directamentedesde el propio Team Explorer, pero esto no siempre escómodo de hacer, sobre todo a la hora de crear muchosWork Items al principio del proyecto. Además, son sim-ples unidades de datos en las que, en la versión actual,

no tenemos jerarquías. No podemos obtener un infor-me de Gantt, ni otro tipo de informes.

Para ello contamos con la integración de Excel yProject, que nos permitirá acceder a la informaciónde los proyectos (figura 5).

De este modo, podemos traernos la información delos Work Items a estas herramientas, editarlos, crearnuevos Work Items y tener una herramienta más ade-cuada para que los jefes de proyecto puedan crear de unmodo fácil todas las tareas (especialmente con Excel),así como gestionar informes de Gantt, recursos, etc.,con Microsoft Project.

Recuerden: hace falta instalar Team Explorer y,por supuesto, tener una CAL de acceso a Team Foun-dation Server.

Team System Web Access

TSWA se ha incorporado recientemente a la fami-lia de Team System, y lo bueno que tiene es que esgratuita. La pueden descargar completamente gratisde la Web de Microsoft.

La podemos instalar en el mismo servidor de TeamFoundation Server, y nos crea un sitio Web a travésdel cual podemos acceder a toda la información quetenemos de nuestros proyectos en Team FoundationServer (figura 6).

Por supuesto, para manejar toda la información,aunque sea a través de la Web y aunque no necesite-mos instalar Team Explorer, necesitaremos una CALde acceso a Team Foundation Server. Respecto a estoexisten excepciones en las que no necesitaremos unaCAL, pero es conveniente consultar a Microsoft sobreel escenario desde el que lo vamos a usar para com-probar las que necesitamos.

Team Foundation Server Power Tools

Si bien no son una herramienta necesaria, sonmuy recomendables. Son de descarga gratuita deMicrosoft, y nos proporcionan un conjunto de utili-dades adicionales, como una herramienta que se ins-tala y nos proporciona avisos de cuando se completauna build de Team Foundation Server y su resultado,un analizador de buenas prácticas en Team Founda-tion Server, especialmente útil para los administra-dores y nuevas herramientas que Microsoft está cons-tantemente implementando.

ConclusionesÉsta es la anatomía de alto nivel de Visual Studio TeamSystem. Por supuesto, iremos profundizando enmuchas de estas cosas, tanto a nivel básico como aniveles más avanzados en futuros artículos.

Figura 5

Figura 6

Introducción

En los inicios, el desarrollo de software carecía deprocesos formales definidos, no existía un guiónque nos ayudara a planificar y predecir cómo debíaser el proceso de desarrollo.

La creciente exigencia en la calidad de los pro-yectos de software, así como la necesidad de obte-ner un producto de máximo valor, hace necesaria laadopción de una metodología concreta de desarro-llo. Esta metodología de software debe permitirpotenciar las capacidades de los diferentes gruposde desarrollo involucrados en el proyecto, así comohacer más predecible todo el proceso de desarrollo.

La elección de una correcta metodología, yque ésta se ajuste a las características del equipode desarrollo, nos ofrecerá una mayor flexibili-dad para la consecución de los objetivos del pro-yecto, además de ofrecer la posibilidad de satis-facer nuevas necesidades surgidas durante las dife-rentes etapas del proceso. Algunas de las carac-terísticas que una buena metodología no deberíapasar por alto son:

• Debe cubrir el ciclo completo de desarro-llo. Es decir, debe comprender las etapas deinvestigación, análisis de requisitos, diseñoe implementación.

• Debe integrar las distintas fases del ciclo dedesarrollo. Nos debe poder permitir fusio-nar las diferentes fases del desarrollo paraconseguir la solución final. Es importanteque nos permita realizar correcciones enfases anteriores sin perjudicar gravementeel resultado final.

• La metodología nos debe ayudar a detectary corregir errores cuanto antes. General-mente, cuanto más tarde sea detectado unerror más costoso será corregirlo. Es poresto que es altamente recomendable que lametodología incluya fases de validaciónexplícitas, como mínimo, al finalizar cadaetapa del proceso.

• Debe ayudarnos a definir con exactitud elcomportamiento final del sistema. Una bue-na metodología debe asegurar que el resul-tado final se ajusta perfectamente a las espe-cificaciones marcadas, y que éstas cubrentodas las necesidades de los usuarios.

• Debe ser la base de la comunicación entrelas partes implicadas en el proyecto. Unametodología debe establecer canales ymecanismos que ayuden a mantener unbuen flujo de información entre los dife-rentes componentes del equipo de pro-yecto.

Escogiendo metodología y organización de equipo

ALManía

Juan Carlos ViñasCustom Development

Manager de Raona. JuanCarlos es MCSD .NET

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

Juan Carlos Viñas

dotN

etM

anía

<<

23

dnm.ALManía<<

Cómo elegir una metodología

El momento de la elección de lametodología a utilizar es uno de lospuntos más críticos de todo proyecto,y del que dependerá en gran medidaque éste llegue a buen puerto o por elcontrario, naufrague por el camino.Esta elección debe realizarse teniendoen cuenta diversos factores, algunos delos más importantes son:

• El tipo de proyecto. La metodologíaescogida dependerá en gran parte delas características del proyecto. Algu-nas metodologías se adaptan mejor aproyectos que se realizan utilizandodeterminada tecnología, otras, encambio, se adaptan mejor a proyec-tos de una determinada duración ocomplejidad.

• Las características de nuestro equi-po de desarrollo. El objetivo final detoda metodología es el de potenciarlas capacidades de los integrantes delequipo de proyecto. Por este moti-vo será vital, que la totalidad del equi-po esté de acuerdo en que la meto-dología que se utilizará es la más indi-cada y que garantiza un resultadomejor del que se podría obtener concualquier otra metodología.

• Factores externos. En ocasiones lametodología a utilizar vendrá marca-da por las exigencias de algún factorexterno. Un ejemplo de esto podríaser la obligación de utilizar la mismametodología que utiliza un cliente oproveedor de software concreto.

• Herramientas de desarrollo. Es posi-ble que algunas de las herramientasque empleemos para la implementa-ción de nuestro proyecto se adaptenmejor a cierto tipo de tecnología.

Metodologías ágiles o tradicionalesLas metodologías tradicionales se carac-terizan por generar una documentaciónexhaustiva de cada una de las etapas delproyecto. Centran su atención en cum-plir un plan de proyecto, que en lamayoría de casos, se define en las etapas

iniciales de éste. Las metodologías tra-dicionales, pese a ser excelentes en cuan-to al control del proyecto (siempre ycuando se definan correctamente losrequisitos desde un inicio, lo cual no esen absoluto fácil), tienen el inconvenienteque son poco adaptables a los cambiossurgidos durante las diferentes fases.

Las metodologías ágiles, en cambio,centran su filosofía en tomar las deci-siones más críticas y que más valor apor-tan al inicio del proyecto posponiendoel resto a etapas posteriores y en la pla-nificación adaptativa. Las principalesideas en las que se basan estas metodo-logías se recogen en el Agile Manifes-to, algunas de ellas son:

• Los individuos y las interacciones entreellos son más importantes que lasherramientas y procesos empleados.

• Es preferible conseguir un buen pro-ducto a una documentación exhaustiva.

• Se debe potenciar al máximo la cola-boración con el cliente. Así asegura-remos que el producto final cumplacon sus expectativas.

• La flexibilidad y respuesta a los cam-bios deben prevalecer sobre cualquierplanificación inicial.

Entonces, la primera pre-gunta que debemos hacernosal elegir una metodología es:¿debemos optar por unametodología tradicional odebemos decantarnos poruna metodología ágil?

La respuesta es —obvia-mente— depende. Para queun equipo de proyecto pue-da trabajar con metodo-logías ágiles es muy reco-mendable que éste cuentecon experiencia previa en eldesarrollo de proyectos, yaque las metodologías ágilesimplican un alto nivel deresponsabilidad de todos losmiembros del equipo. Lasmetodologías ágiles, permiten dismi-nuir costes y hacen que el proceso dedesarrollo sea flexible, esto será muybeneficioso en proyectos donde elentorno es volátil y los requisitos no se

conocen con exactitud al iniciar el pro-yecto. Además, nos permitirán gene-rar el máximo valor para el cliente enfases más tempranas de lo que nos per-mitiría cualquier metodología no ágil.

Metodología con Team SystemHablar de metodología en Team Sys-tem es hablar de plantillas de procesos.Las plantillas de procesos definen cómose va a configurar el ciclo de vida delproyecto. Estas plantillas definen con-juntos determinados de elementos detrabajo, consultas sobre elementos detrabajo, grupos de seguridad, informesy ofrecen información orientativa en elmomento de la creación del proyecto.

Team System soporta, de forma pre-determinada, dos metodologías conobjetivos diferenciados: MSF para desa-rrollo ágil y MSF para mejoras de pro-ceso CMMI. Además, existen diferen-tes plantillas de terceros para dar sopor-te a otras metodologías (como por ejem-plo SCRUM, RUP, ICONIX…). Inclu-so tendremos la opción de crear nues-tra propia plantilla de proceso persona-

lizada, lo cual puede resultar complica-da y es solo recomendable en el caso queninguna de las metodologías conocidasy contrastada se ajusten a nuestras nece-sidades concretas.

Figura 1. Selección de plantilla en el proceso de creación de nuevo proyecto de equipo

dotN

etM

anía

<<

24

dnm.ALManía<<

La plantilla para MSF para desarrollo ágil estádiseñada para ser utilizada en proyectos pequeños conun calendario de entregas rápido. Algunos de los moti-vos por los cuales puede resultar interesante esta plan-tilla son:

• Estamos interesados en la especificación de pro-cesos flexibles, que nos permitan adaptarnos aposibles modificaciones en el proyecto.

• El equipo de desarrollo es reducido.• Necesitamos dar cabida a diferentes equipos de

desarrollo que trabajan de formas distintas.• Nos interesa que los ciclos de desarrollo sean

cortos (entre dos semanas y un mes).

MSF para desarrollo ágil intenta reducir riesgoen un proyecto, realizando el desarrollo mediante ite-raciones. Cada iteración consiste en un proyecto enminiatura por sí solo, e incluye todas las tareas nece-sarias para la puesta en producción de las nuevas fun-cionalidades desarrolladas. Al final de cada iteraciónse reevalúan las prioridades del proyecto para obraren consecuencia.

Esta metodología hace especial hincapié en maxi-mizar los mecanismos de comunicación entre todaslas partes implicadas en el proyecto (prefiriendo la

comunicación directa sobre la comunicación realiza-da mediante documentos escritos), especialmenteentre los desarrolladores y los encargados de definirel producto.

Las metodologías ágiles toman como principalmétrica de progreso del proyecto, el número de fun-cionalidades implantadas hasta el momento. Esto uni-

do a la preferencia por las comunicaciones no-escri-tas, hace que al finalizar el proyecto, la documenta-ción generada relativa a otros aspectos sea mínima.

Los métodos ágiles se caracterizan por adaptarserápidamente a los cambios introducidos en el pro-yecto. Cuando cambian las necesidades de un pro-yecto, un equipo “ágil” puede cambiar también. Cuan-do trabajamos con métodos ágiles podremos tenerdificultades para describir con exactitud qué pasaráen un futuro lejano, solo podremos estar seguros deque funcionalidades están planeadas para el fin de laiteración en curso.

En cambio, las metodologías tradicionales plani-fican el transcurso de todo el proceso de desarrollodesde un principio. Un equipo, que trabaja con meto-dologías tradicionales, está en disposición de infor-mar con precisión en qué momento se llevará a cabouna tarea concreta, pero tendrá inmensas dificulta-des para cambiar de dirección en el caso que las con-diciones iniciales del proyecto cambien.

La plantilla de MSF para mejoras de procesoCMMI puede resultar interesante si estamos intere-sados en la formalización de procesos y mejora de lasprácticas mediante la aplicación de las conclusionesaprendidas. Puede ser conveniente elegir esta plan-tilla si:

• Deseamos evaluar las prácticas empre-sariales actuales.

• El equipo de desarrollo de software esgrande.

• Necesita integrar grupos u organiza-ciones tradicionalmente indepen-dientes.

• Necesitamos proporcionar orientaciónpara los procesos de calidad.

• Los ciclos de desarrollo de softwareson prolongados.

• MSF para mejoras de proceso CMMItiene más artefactos, más procesos yrequiere una mayor planificación. Estáorientado al desarrollo de proyectosque requieren un mayor grado de for-malización y protocolo (como porejemplo muchos los proyectos de laadministración en EEUU, dondeCMMI es un requisito).

• MSF para mejora de proceso CMMI es una meto-dología formal y cuyo objetivo principal es el de lacontinua mejora de los procesos existentes en unaorganización. De esta forma, utilizando el conoci-miento adquirido, conseguiremos reducir los ciclosde vida de desarrollo, realizar mejores estimacio-nes de costes y planificar objetivos con un menormargen de error. Todo esto derivará en la elabora-ción de productos de mayor calidad.

Figura 2. Pantalla inicial de proyecto realizado con plantilla de MSF para desarrollo ágil

dotN

etM

anía

<<

25

dnm.ALManía<<

Estructura de plantilla de procesos

Podemos diferenciar tres piezas claveen una plantilla de proceso para TeamSystem: los complementos de la plan-tilla de procesos, el asistente para nue-vo proyecto de equipo y los archivos dedefinición de procesos XML.

Los complementos de plantilla deprocesos se ejecutan cuando se crea unnuevo proyecto de equipo. Éstos insta-lan los archivos necesarios para su eje-cución, además de configurar los datospara el correcto funcionamiento de suárea. Microsoft proporciona los siguien-tes complementos de plantilla:

El asistente para la creación denuevos proyectos consiste en unaherramienta que nos guiará en el pro-ceso de creación de un nuevo proyec-to, pidiéndonos la información nece-saria para la configuración de los com-plementos indicados en la plantilla ycreando estos complementos en elorden indicado.

Los archivos de definición de pro-cesos XML definen las tareas que sedeben ejecutar para la correcta confi-guración de los complementos nece-sarios. Cada complemento cargará suarchivo de definición de proceso paraobtener la lista de tareas que debe eje-cutar.

Team System como herramienta metodológicaTeam System comprende un conjuntode herramientas que nos ayudan a ges-tionar el ciclo de vida de un proyectode desarrollo en el que están implica-dos diferentes roles dentro de una orga-nización. Team System permite admi-nistrar los diferentes elementos que for-man un proyecto así como planificar losrecursos que en éste intervienen.

Team System nos puede ayudar enlos siguientes escenarios:

• Productividad en equipo. Mediante eluso de diferentes herramientas especí-ficas para cada rol de la organización,se aumenta la productividad global delequipo. Además, Team System se pue-de integrar con herramientas conoci-das, como Microsoft Excel para laexportación y tratamiento de tareas oMicrosoft Project para la realizar pla-nificación del proyecto. Team Systemnos ofrece también un front-end Web(figura 4), que nos permitirá realizardiversas tareas directamente desdenuestro navegador.

• Colaboración y comunicación. TeamSystem ofrece un repositorio de códi-go con un potente control de versio-nes, accesible desde Internet. Además,nos ofrece herramientas para contro-lar los diferentes flujos de trabajo quetienen lugar en el equipo mediante laasignación de tareas, gestión de requi-sitos, gestión de riesgos, etc.

Figura 3. Pantalla inicial de proyecto realizado con plantilla de MSF para mejoras de proceso CMMI

Complementos de plantilla de procesos

Clasificación Define las iteraciones y las áreas iniciales de un proyecto de equipo.

Grupos y permisos Define los grupos de seguridad iniciales de un proyecto de equipo y sus permisos.

Sharepoint Services Define el portal del proyecto para el equipo basado en una plantilla de sitio Web de Sha-rePoint. También define archivos de plantilla y ofrece instrucciones sobre el proceso.

Seguimiento de elementos de trabajo Define los tipos de elemento de trabajo iniciales de un proyecto de equipo, consultas einstancias del elemento de trabajo.

Informes Define los informes iniciales de un proyecto de equipo y configura el sitio del informe.

Control de versiones Define los permisos de seguridad de control de versiones iniciales de un proyecto de equi-po y las notas de protección.

Tabla 1

dotN

etM

anía

<<

26

dnm.ALManía<<

• Calidad del software. Muchas de las capacida-des de Team System están orientadas a contro-lar y mejorar la calidad del software generado.Mediante los mecanismos para la generaciónde métricas, integración de código y realiza-ción de diferentes tipos de pruebas. Team Sys-tem nos ofrece todo un abanico de herramien-tas que nos ayudarán a conseguir un softwarede alta calidad.

• Predictibilidad y control. Mediante el uso deplantillas, Team System puede soportar diferen-tes tipos de metodologías. Además de MicrosoftSolution Framework (metodología soportadaout-of-the-box por Team System), podremos con-tar con implementaciones realizadas por terce-ros de las metodologías más conocidas y con-trastadas, como, por ejemplo, SCRUM, RUP,eXtreme Programming y un largo etcétera.

• Gestión de proyecto. Team System nospermite gestionar el proyecto en base ala información registrada durante su ela-boración. Los diferentes informes e indi-cadores que nos ofrece Team System pue-den resultar muy útiles a la hora de tomardecisiones.

Todas estas funcionalidades hacen deTeam System una excelente herramientacon la que poder aplicar alguna de lasmuchas metodologías soportadas al desa-rrollo de nuestros proyectos, de esta formaestaremos garantizando la calidad del pro-ceso de desarrollo y, lo que es más impor-tante, aumentando las posibilidades de éxi-to de nuestro proyecto.

ConclusionesHoy en día nos es difícil concebir la elaboración de pro-yectos de software sin el uso de una metodología de desa-rrollo. Existen diversas metodologías que se adaptan adiferentes tipos de proyectos. Podremos diferenciar estasmetodologías en dos grandes grupos: las metodologíastradicionales o formales, cuyo objetivo es planificar ydocumentar minuciosamente cada paso del proceso, ylas metodologías ágiles, que priorizan la flexibilidad yagilidad por encima de la formalización de las diferen-tes etapas. Microsoft Team System es una herramienta,que —entre otras cosas— nos ayudará a aplicar unametodología en el desarrollo de software. Team Systemsoporta por defecto dos metodologías de filosofía muydiferenciada: MSF para mejoras de Proceso CMMI yMSF para desarrollo ágil. Además, nos permitirá adap-tar estas dos metodologías a las necesidades concretasde nuestra organización e incluso la creación de nues-tras propias plantillas de proceso.

Figura 4. Imagen de Team System Web Access

Links de interésAgile Manifesto: http://www.agilemanifesto.com.

Visual Studio Team System: http://msdn.microsoft.com/es-es/library/fda2bad5(VS.80).aspx.

Microsoft Solution Framework: http://www.microsoft.com/technet/solutionaccelerators/msf.

MSF for Agile Software Development Process Guidancehttp://www.microsoft.com/downloads/details.aspx?familyid=9f3ea426-c2b2-4264-ba0f-35a021d85234&display-lang=en.

MSF for CMMI® Process Improvementhttp://www.microsoft.com/downloads/details.aspx?FamilyId=10B578F1-B7A 4-459F-A 783-04BC82CB2359&display-lang=en.

[1]

[2]

[3]

[4]

[5]

IntroducciónTodos los roles dentro de un equipo de desarro-llo son importantes, unos tienen más peso queotros e incluso algunos roles se comparten, perolo que es indiscutible es que el software es la repre-sentación del código que escriben los desarrolla-dores y, por ello, es el rol —bajo mi punto de vis-ta— con más peso dentro de un equipo.

El código es la única cosa tangible que nos que-dará una vez hayamos finalizado un proyecto; porejemplo, un analista puede haber definido minu-ciosamente una funcionalidad o un jefe de pro-yecto puede haber planificado y gestionado a laperfección una serie de tareas, pero sin un equipoque las desarrolle, no hay producto, por muy biendefinido y/o planificado que este todo.

Visual Studio Team System Development Edi-tion es la versión de Visual Studio que usamos losdesarrolladores para escribir código a diario, y éstanos ofrece una gran cantidad de funcionalidadesque nos hace el día a día más cómodo y ademásnos facilita aplicar técnicas de desarrollo comoTest Driven Development (TDD).

Es cierto que existen otras versiones de VisualStudio y que todas ellas son capaces de compilar códi-go, pero la edición para desarrolladores es la que nospermite realizar todas las funciones comunes de undesarrollador: hacer diagramas de clases, crear pro-yectos de una gran cantidad de tipos, crear paquetes

de instalación, escribir pruebas automáticas, anali-zar la cobertura de código, analizar el rendimientode nuestras aplicaciones y, por supuesto, ¡escribircódigo con una gran cantidad de comodidades!

Un gran poder conlleva una gran res-ponsabilidad Como decían en la película de Spiderman, un granpoder conlleva una gran responsabilidad, y en estecaso, con una herramienta tan potente como esVSTS Development Edition, la responsabilidadde que un programa funcione de forma correctay de que el código generado sea un código de cali-dad es de los desarrolladores.

Test-Driven Development

Existen una serie de técnicas probadas a la horade escribir código que nos ayudan a controlar lacalidad del código que escribimos desde el princi-pio, como puede ser el desarrollo guiado por prue-bas (Test-Driven Development o TDD). Esta téc-nica se basa en la escritura de las pruebas unitariasantes que el código funcional, de hecho Kent Becken su libro “Test-Driven Development. By Exam-ple” definió un par de reglas muy simples que plas-man TDD a la perfección:

La importancia del equipo de desarrollo

ALManía

Jesús Jiménez es Consultor de Desa-

rrollo de Software, espe-cializado en Visual Studio

Team System, en ilitiaTechnologies. Escribe

habitualmente enhttp://www.teamsystem.e

s y es MCTS en TeamFoundation Server y

MCSD.NET

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

Jesús Jiménez

dotN

etM

anía

<<

29

dnm.ALManía<<

• Nunca escribas una línea de códigoa menos que tengas una prueba quefalle.

• Refactoriza el código.

Poner TDD en práctica es sencillo,aunque el proceso de adaptación pue-de resultar un poco complicado porquecambia la forma en la que desarrolla-mos. Pensemos por un momento en unmétodo que tenga que validar un núme-ro NIF; el algoritmo no es complejo.Un número de NIF consta de nuevecaracteres, los ocho primeros sonnúmeros y el ultimo una letra. Existeuna relación entre el número y la letraque la acompaña, de tal forma que paraun número dado solo es válida una letra.Esta letra se calcula dividiendo el núme-ro entre 23 para obtener el resto de ladivisión y luego obtener una letra deuna lista de veintitrés en base al restode la división.

Partiendo de este requisito, ya senos vienen a la cabeza varias formas conlas que comprobar que el algoritmofunciona correctamente, y es en estemomento donde entra en juego unamáxima de TDD: Red, Green, Refac-tor. Esta regla consiste en crear prue-bas que inicialmente fallarán (Red),escribir el código necesario para que laprueba sea válida (Green) y finalmen-te modificar nuestro código para quequede lo más simple posible y sin alte-rar el funcionamiento, es decir, para losmismos parámetros de entrada, el valorde salida del método debe ser el mismo(Refactoring).

Pero veamos estos conceptos de unaforma práctica. Si nos basamos en elplanteamiento anterior de validacióndel NIF, el proceso de desarrollar esafuncionalidad usando TDD sería elsiguiente: en primer lugar, la idea escrear una prueba que podamos auto-matizar para cada una de las compro-baciones que necesitemos hacer paraverificar que el método funciona correc-tamente, pero como aún no hemosescrito el código funcional, todas laspruebas fallarán; estamos en la fase rojoy tenemos la lista de pruebas que semuestran en el listado 1. Una vez hechoesto, escribimos el código funcional y

escribimos el código necesario para quepasen las pruebas; ya estamos en verde.Por último, intentamos mejorar nues-tro código para que quede lo más sim-ple posible, pero que todas las pruebassigan estando en verde, proceso llama-do refactorización. De esta forma, pode-mos ir asegurando que el código queescribimos cumple los requisitos de los

que partimos como se muestra en lafigura 1.

Para ayudarnos a poner en prácticaTDD, Visual Studio Team SystemDevelopment Edition nos da la posibi-lidad de crear pruebas automatizadasque se pueden ejecutar en cualquiermomento o incluirlas en el proceso decompilaciones automáticas del que

[TestMethod]public void ValidarNif_ParametroNuloOVacio(){

bool _esValido;Utilidades _utilidades = new Utilidades();

_esValido = _utilidades.ValidarNif(null);A ssert.IsFalse(_esValido);

_esValido = _utilidades.ValidarNif(String.Empty);A ssert.IsFalse(_esValido);

}

[TestMethod]public void ValidarNif_ParametroLongitudIncorrecta(){

bool _esValido;Utilidades _utilidades = new Utilidades();

_esValido = _utilidades.ValidarNif(“1234”);A ssert.IsFalse(_esValido);

_esValido = _utilidades.ValidarNif(“1234567890”);A ssert.IsFalse(_esValido);

}

[TestMethod]public void ValidarNif_ParametroValido(){

Utilidades _utilidades = new Utilidades();

bool _esValido = _utilidades.ValidarNif(“11223344B”);A ssert.IsTrue(_esValido);

}

Listado 1

Figura 1

dotN

etM

anía

<<

30

dnm.ALManía<<

hablaremos más adelante en este artículo. Además,nos proporciona una serie de acciones comunes quese realizan cuando estamos en el proceso de refacto-rización y todo ello integrado dentro del IDE. Pordestacar algunas de las opciones de refactorizaciónmás usadas, podemos hablar de:• Renombrar. Esta opción nos da la posibilidad de cam-

biar el nombre a una variable, método o clase yactualizar todos los sitios donde es usada sustitu-yendo el nombre antiguo por el nuevo.

• Extraer método. Para llevar a cabo la regla de laque hablábamos al principio, eliminar el códigoduplicado, contamos con esta opción que nos per-mite seleccionar un trozo de código y crear unmétodo a partir de él. El método resultante tendrátantos parámetros de entrada como sean necesa-rios y un tipo de dato de retorno que permitan sus-tituir el trozo de código original por una llamadaa este nuevo método. De esta forma centralizamosfunciones comunes que usemos a lo largo de nues-tro código en un solo punto, evitando tener códi-go duplicado, ayudando a reducir la cantidad códi-go necesario y favoreciendo la reducción del impac-to ante un cambio que necesitemos realizar en nues-tro código ya que solo tendremos que cambiarloen un único sitio.

• Extraer interfaz. Con esta opción podemos gene-rar una interfaz de una clase que ya tengamos cre-ada. La interfaz resultante tendrá todos los méto-dos y propiedades públicas de la clase de la queestemos extrayendo el interfaz y además incluirá laimplementación de la interfaz generada en la defi-nición de la clase.

En la mayoría de ocasiones, tras escribir primerolas pruebas, luego el código y, por último, hacer la refac-torización, es posible que, aun pasando todas las prue-

bas nuestro código, no esté bien probado. Con VSTStenemos a nuestra disposición una funcionalidad lla-mada cobertura de código, que nos informa qué cantidadde código está siendo probado y nos ayuda a detectarlos puntos concretos donde nuestra batería de pruebasno está llegando. Para ello, se analizan todos los cami-nos únicos de código que se ejecutan tras lanzar la bateríade pruebas y se calcula el porcentaje de líneas de códi-go no ejecutadas. Normalmente un índice superior al80% suele ser un buen índice de cobertura.

En definitiva, las pruebas unitarias son responsa-bilidad de los desarrolladores y en ningún casodeberían ser opcionales si queremos asegurar una cali-dad mínima de nuestro código.

Métricas de código

Una vez hemos escrito nuestras pruebas y nues-tro código, necesitamos un primer baremo que nosayude a saber si el código que estamos generando esun código de calidad. Para ello contamos con unanueva funcionalidad dentro de VSTS 2008 Deve-lopment Edition que nos aporta datos que nos ayu-dan a saber más sobre la calidad de nuestro código,las métricas de código.

A pesar de ser algo que lleva mucho tiempo en eldesarrollo de software —desde mediados de los 70—no ha sido hasta la versión de VSTS 2008 cuando seha dotado al entorno de esta nueva característica. Yaera posible en versiones anteriores de Visual Studioobtener esta información, pero había que hacerlo através de add-ins de terceros o con herramientas total-mente externas al IDE. Ahora, sin embargo, lo tene-mos integrado dentro del entorno de desarrollo y nosayuda a ver de un vistazo rápido cuáles son los pun-tos de nuestro código que tenemos que revisar y mejo-rar en la medida de lo posible.

Podemos acceder a esta funcionalidad desde el menú“Analyze” y podemos realizar el cálculo de estas métri-cas a nivel de proyecto o a nivel de solución. Las métri-cas incluidas en VSTS 2008 son las siguientes:• Índice de mantenibilidad. Este valor representa cuán

fácil de mantener es nuestro código y el valor es unnúmero que está entre 0 y 100, siendo 0 un códigomuy difícil de mantener y 100 un código fácil demantener, es decir, mientras más alto sea este valor,más fácil de mantener será nuestro código. Estevalor se calcula en base al Halstead Volume, a la com-plejidad ciclomática y al número de líneas de códi-go. Dicho valor nos aparece acompañado de un sím-bolo que de forma visual nos indica donde están lospuntos menos mantenibles de nuestro código. Estesímbolo es un cuadrado verde si el valor se encuen-tra entre 20 y 100, un triángulo amarillo si el valor

Con una herramienta tan potentecomo es VSTS Development Edition,la responsabilidad de que un progra-ma funcione de forma correcta y de

que el código generado sea un códigode calidad es de los desarrolladores

dotN

etM

anía

<<

32

dnm.ALManía<<

está entre 10 y 19 y por último, un cír-culo rojo si el valor está entre 0 y 9.

• Complejidad ciclomática. Este valornos indica cómo de complejo esnuestro código en base al número decaminos posibles de ejecución quetenemos. Estos caminos son los mar-cados por nuestras sentencias if,switch, do, while, for y foreach. A mayornúmero de caminos de ejecución quetengamos, mayor será la complejidadde nuestro código y, por tanto, seráun código más difícil de mantener.

• Profundidad de herencia. Otro de losfactores medibles que determinanque un código es más mantenible queotro es la profundidad de herencia.Este valor nos indica el número deherencias de un objeto hasta el obje-to base. Como se puede apreciar enla figura 2, las clases que no heredande nada tienen un valor de 1 y esto esporque en .NET todo hereda de laclase Object. En definitiva, a mayorvalor, más difícil de mantener seránuestro código porque un cambio enuna clase base, de la que heredanotras, puede resultar en errores enlas clases hijas.

• Acoplamiento entre clases. Indica lacantidad total de tipos diferentes conlos que interacciona una clase, exclu-yendo los tipos primitivos y algunostipos del Framework como Int32 oString. A menor valor en esta métri-ca, mejor, puesto que mientras menosdependencias tenga una clase de otrasmás reusable es.

• Líneas de código. En este caso, elvalor aportado es el del número delíneas de código ejecutables, y comolas otras métricas, mientras menoslíneas de código, mejor, ya que la can-tidad de código con la que tendre-mos que lidiar será menor. Por otrolado, tener pocas líneas de códigohace que la probabilidad de bugs dis-minuya, ya que hay menos líneas decódigo que puedan causar errores.Una cosa que debemos tener encuenta es que no todas las líneas decódigo son iguales, algunas son muysimples y otras muy complejas, asíque debemos usar esta métrica concuidado, ya que el número de líneas

de código no refleja en ningún casola complejidad de un desarrollo. Enel pasado se ha tendido a usar estamedición para estimar la productivi-dad de los desarrolladores o para esti-mar la complejidad de proyectos conresultados catastróficos.

Por último respecto a las métricasde código de VSTS he de decir, que apesar de ser muy útiles, con estas medi-ciones no estamos midiendo el rendi-

miento o la seguridad de nuestro códi-go, y tampoco nos van a ayudar a resol-ver y localizar errores, con ellas soloobtendremos información acerca denuestro código, cuánto tenemos, cómode fácil será mantenerlo, cómo de reu-sable es y cuáles son los puntos máscomplejos a nivel de lenguaje.

Pueden encontrar más informaciónacerca de la importancia y el cálculo delas métricas de código en la Web deCarnegie Mellon Software EngineeringInstitute: http://www.sei.cmu.edu/pub/edu-cation/cm12.pdf.

Análisis estático de código

Desde hace ya varios años los desa-rrolladores de .NET disponemos deherramientas que nos ayudan a que nues-tro código cumpla una serie de normas yestándares con la intención de homoge-neizar el código escrito por diferentes per-sonas. Si todos nos regimos por la mismaserie de normas, el código que puedanescribir dos desarrolladores distintos final-mente será muy parecido, lo cual dismi-

nuye los tiempos en caso de que una queno haya escrito ese código tenga quemodificarlo. El software por excelenciade análisis estático de código para la pla-taforma .NET es FxCop, que reciente-mente ha sacado la versión 1.36 y que des-de Visual Studio 2005 está integrado den-tro del IDE para ayudarnos a cumplir unaserie de normas estándares que podemosdefinir a nuestra elección.

La forma de establecer qué reglasqueremos que sean verificadas es senci-

lla, tan solo tenemos que ir a las propie-dades de nuestro proyecto, seleccionar lapestaña “Análisis de Código” y seleccio-nar las reglas que creamos oportunas yque sean coherentes con nuestra formade desarrollar. Una vez seleccionadas lasreglas, podemos hacer que se validen dedos formas diferentes, bien habilitándo-las en esta misma pestaña, de la que habla-ba hace un momento para que sean eje-cutadas en cada compilación o bien eje-cutar el análisis bajo demanda pulsandocon el botón derecho sobre nuestro pro-yecto en el explorador de soluciones yseleccionando “Ejecutar Análisis de Códi-go”. Inicialmente, cuando activamos unaregla para que sea verificada, Visual Stu-dio lo trata como un warning, pero tam-bién podemos hacer que estas reglas seantratadas como errores y hacer que la com-pilación falle si no se cumple una regla.Bajo la pantalla de configuración de lasreglas de análisis estático de código, quese muestra en la figura 3, vemos como encada una de las reglas tenemos una casi-lla que nos permite definir si queremosque esa regla sea tratada como un errorde compilación.

Figura 2

dotN

etM

anía

<<

33

dnm.ALManía<<

Entre la versión anterior de Visual Studio y enla actual no se pueden destacar grandes cambios enlo que al análisis estático de código se refiere, peroa pesar de ser cosas pequeñas, aportan mucho valoral proceso. Una de las cosas en las que se centraronfue en el aumento del rendimiento, que algunas vecesse eternizaba cuando estaba realizando el análisis; eneste aspecto han conseguido reducir los tiempos deejecución del análisis y el consumo de memoria a lamitad. También se han incluido nuevas reglas queno existían en las versiones anteriores y actualmen-te el motor cuenta con un total de 208 reglas. Perosi hay dos cosas que realmente merecen ser desta-cadas son las facilidades que acompañan a VSTS2008 para la supresión de mensajes y la posibilidadde crear diccionarios personalizados con las palabrasque nosotros queramos.

En primer lugar, en la pestaña de configuracióndel análisis de código (ver figura 3), vemos que hayuna nueva casilla que podemos marcar para que deforma automática se supriman los mensajes de errorproducidos por el código generado. Además, tenemosla opción de suprimir un mensaje concreto pulsandocon el botón derecho sobre él en la lista de mensajesy seleccionando desactivarlo para ese punto concre-to del código o a nivel de proyecto, caso en el queVisual Studio creará un fichero llamado GlobalSu-pression.cs donde almacenar la lista de mensajes supri-midos a nivel de proyecto (ver figura 4).

En segundo lugar, otra de las mejoras añadidas porel grupo de producto, gracias al feedback de los usuarios,ha sido la posibilidad de añadir un diccionario de pala-bras personalizado para que el motor de análisis no gene-re un mensaje de warning o error si encuentra alguna delas palabras de la lista en nuestro código. Para añadir un

diccionario personalizado solo tenemos que incluir ennuestro proyecto un fichero XML que contenga la lis-

ta de palabras admitidas y establecer la propie-dad BuildA ction del fichero XML a CodeA naly-sisDictionary como se muestra en la figura 5,además debemos tener marcada la regla CA 1704bajo la sección Microsoft.Naming en la configu-ración de las reglas de análisis estático.

Por si esto fuese poco, el motor de análisisestático de código viene provisto de una APIde extensibilidad que nos permite crear nue-vas reglas definidas por nosotros. La creaciónde nuevas reglas a nivel programático no esdifícil, solo tenemos que agregar varias refe-rencias a las librerías del SDK de FxCop, cre-ar una clase que herede de BaseRule y sobres-cribir varios métodos. Las reglas generadas sonvalidas tanto Visual Studio Team System comopara FxCop y la parte realmente complicadadel proceso es definir nuevas reglas y realizarlas comprobaciones necesarias sobre el códigopara determinar si es válido o no.

Figura 3

Figura 4

Figura 5

Para terminar con esta sección me gustaría comen-tar algo que mucha gente no sabe: acompañando aVisual Studio vienen una serie de reglas que nos ayu-dan a determinar si las métricas de código de las quehablamos antes están por encima de un umbral deter-minado. Estas reglas se encuentran bajo la sección de“Maintainability Rules” y pese a que los valores quecomprueba no se pueden cambiar se verifican que losindicadores estén dentro de los límites que se mues-tran en tabla 1.

El proceso de desarrollo

Como hemos visto hasta ahora, Visual Studio TeamSystem 2008 Development Edition nos ofrece una grancantidad de herramientas para ayudarnos a generar códi-go de calidad, poniendo en práctica técnicas como eldesarrollo guiado por pruebas, las métricas de códigoy el análisis estático de código. Lo ideal es usar todasestas herramientas a lo largo de todo el proceso de desa-rrollo; no nos sirve de mucho querer hacer que nues-tro código tenga un buen índice de mantenibilidad unasemana antes de terminar el desarrollo o querer hacerpruebas unitarias cuando la aplicación ya está en pro-ducción, sin embargo, si integramos estas prácticas ennuestro día a día el resultado final probablemente seade mayor calidad que si no lo hacemos.

A pesar de esto, uno de los grandes errores es ten-der a hacer el proceso de desarrollo demasiado pesa-do y debemos evitar caer en esta situación, por ejem-plo, definiendo un número muy elevado de reglas deanálisis estático de código o tratando de refactorizarlo imposible para mejorar los índices de mantenibi-lidad y el número de líneas de código.

Si se decide adoptar estas prácticas, lo cual es muyaconsejable, debemos actuar con responsabilidad ycumplirlas, ya que si no el conjunto global del equi-po y la calidad final se verán afectados. Para ayudar-nos a conseguir este objetivo, dentro de la gama deproductos de Team System contamos con TeamFoundation Server y Team Build.

Por un lado, Team Foundation Server, al ser nues-tro repositorio de código —entre otras cosas—, nosayuda a controlar que el código que depositamos enél tiene una calidad mínima y cumple las normas esta-blecidas a nivel de Team Project. Para ello cuentacon las políticas de protección, que se encargan devalidar que el código cumple los requisitos estable-cidos. En este caso, dos de las políticas de protecciónque acompañan a Team Foundation Server tienen lacapacidad de no dejarnos proteger código en el ser-

vidor si no se han pasado las pruebas unitarias antesde intentar proteger el código o forzar la ejecuciónde las reglas de análisis estático de código.

Una vez que el código es depositado en el con-trol de versiones, entra en juego el servidor deintegración, que nos permite realizar compilacio-nes del código bajo demanda, de forma automati-zada o la famosa integración continua. Team Buildes unos de los puntos clave en el proceso de desa-rrollo, porque como dijimos al principio, somosun equipo y el producto global es lo que cuenta.Es posible que dos desarrolladores pasen todas laspruebas unitarias de su código de forma indepen-diente pero al realizar la integración y compila-ción de su código con Team Build pueden darseerrores y hacer que el código no compile o quefallen las pruebas unitarias.

Conclusión A lo largo de este artículo hemos podido ver algu-nas de las herramientas que Visual Studio TeamSystem Development Edition pone a nuestra dis-posición para escribir código de calidad. Bajo mipunto de vista todas estas herramientas son de granayuda, pero debemos tener en mente que, salvoalgunas excepciones, somos nosotros mismos losque debemos ser responsables y escribir código decalidad.

Métrica Regla correspondiente Umbral

Profundidad de herencia CA1501 AvoidExcessiveInheritance Mensaje por encima de 5 niveles deprofundidad

Complejidad ciclomática CA1502 AvoidExcessiveComplexity Mensaje por encima de un índice de 25

Índice de mantenibilidad CA1505 AvoidUnmaintainableCode Mensaje con un índice por debajo de 20

Acoplamiento entre clases CA1506 AvoidExcessiveClassCoupling Mensaje por encima de 80 para las cla-ses y por encima de 30 para los métodos

Tabla 1

<<dnm.ALManía

34

<<do

tNet

Man

ía

Situación de contexto

Desde los inicios de la década de los 50, el área dedesarrollo del software ha estado en constante evo-lución. Muchas han sido las tendencias, modelos yparadigmas que han ido marcando el paso de los años,siempre con vistas a evolucionar desde la forma ini-cialmente artesanal de desarrollar aplicaciones a unmodelo industrializado, permitiendo con ello unagestión real del ciclo de vida del desarrollo.

Si hiciésemos un repaso muy somero de lo quehan sido estos 50 años aproximadamente, vería-mos que inicialmente el modelo que marcó unadécada era el denominado Task-centric, en el queel papel de vendedor era clave, proporcionando elhardware, herramientas, lenguaje, programas batch,etc. Caracterizado por un conocimiento muyespecífico y técnico y orientado a tareas concretasy específicas, este modelo daría paso hacia la déca-da de los 70 a lo que se conoce como Application-center junto con el método de desarrollo Water-fall Development. Pasamos de un desarrollo foca-lizado en tareas a un desarrollo orientado a las apli-caciones en el que los sistemas son cada vez máscomplejos. En este contexto se requieren meto-dologías que marquen firmemente los pasos aseguir, con fases perfectamente delimitadas en eltiempo y con un orden secuencial y se evoluciona

de un liderazgo basado en el departamento de Sis-temas de Información a una demanda cada vez másexigente por parte de las empresas gracias a la difu-sión del conocimiento tecnológico al resto dedepartamentos. Nuevas demandas basadas enmodelos de economía globalizada y distribuciónde las personas condicionan y condicionarán losactuales y futuros parámetros en el desarrollo delsoftware, naciendo modelos distribuidos y conmetodologías más ágiles que nos permitan adap-tar con mayor celeridad los cambios en los reque-rimientos de negocio dando lugar a un productocon mayor valor añadido para el cliente.

Sin duda, este modelo incrementa la comple-jidad de la gestión del ciclo del desarrollo, hacien-do patente la necesidad de nuevas herramientas,

Métricas en una buena gestióndel ciclo de vida del desarrollo

ALManía

Jordi González Segura es Director Applica-

tions & Integration de Avanade Spain. Blog personal:

http://jordigosolutionar-chitect.spaces.live.com.

Son muchas las variables que intervienen en el éxito o fracaso en eldesarrollo del software, pues ellas dependen de cada tipología de pro-yecto, de empresa, de solución o de tecnología escogida. Microsoft VisualStudio Team System incorpora una serie de informes que nos permitenvalorar el estado de nuestro desarrollo.

Jordi González Segura

modelos, formas de desarrollo que ayuden a que lagestión del ciclo de vida del desarrollo no se convier-ta en un gran torre de Babel repleta de incomunica-ción, silos de información, procesos burocráticos ysin saber lo que realmente está ocurriendo y lo queocurrirá durante la vida de creación y mantenimien-to del software.

¿Quién, a estas alturas, no ha leído, escuchado oincluso teorizado y utilizado las siglas anglosajonasALM o Application Lifecycle Management? Sonmuchas las organizaciones que han visto la necesidadde establecer un orden y concierto en los procesos uti-lizados en el desarrollo de sus aplicaciones. Wikipe-dia define ALM como: “Regards the process of deliveringsoftware as a continuously repeating cycle of inter-relatedsteps: definition, design, development, testing, deploymentand management. Each of these steps needs to be carefullymonitored and controlled”, proceso de desarrollo del soft-ware en un ciclo repetitivo organizado en fases querequiere del control y monitorización. Naturalmen-te, si hay demanda, hay oferta y son muchos los fabri-cantes de software y las empresas de consultoría quehan apoyado esta definición. Obviamente cada unocon su visión estratégica de negocio, pero todos man-teniendo la esencia de la necesidad de tener mayorcontrol para poder reducir los costes del desarrollo,mejorar la calidad y ser más predictivos.

Factores en el ciclo de vida del desarrolloSon muchas las variables que juegan en el éxito o fra-caso en el desarrollo del software, tantas que seríaimposible en este artículo enumerarlas todas, puesellas dependen de cada tipología de proyecto, tipo-logía de empresa, tipología de solución, tipología detecnología escogida. Aunque sí que podemos tratarde hacer el ejercicio de categorizar los tipos de facto-res principales que condicionan el desarrollo y, portanto, el fracaso o éxito del mismo, tal como se mues-tra en el gráfico adjunto. Estos factores son:

• Personas: tal como hemos visto en el punto anterior,la complejidad en el desarrollo, la necesidad de la espe-cialización o los condicionantes económicos, entreotros factores, hacen que, a lo hora de desarrollar unasolución, tengamos posiblemente que jugar con per-sonas distribuidas geográficamente, de diferentes orga-nizaciones, con conocimientos específicos y que debe-remos gestionar y orquestar de forma adecuada. Ya esposible realizar desarrollos durante 24 horas sin pararmediante el uso de modelos de factoría distribuidospor equipos que cubran la totalidad del espectro defranjas horarias mundiales. Por ejemplo, tal como me

ha sucedido en varios proyectos, el diseño podría serrealizado en casa del cliente; el desarrollo, en factoríasregionales; los procesos de testeo se puede llevar acabo desde otros países; y las pruebas de aceptacióndel usuario pueden estar diseminadas a lo largo de loscinco continentes. Sin duda, un espectro de posibili-dades que pueden perfectamente hacer fracasar unproyecto si éste no se gestiona de forma adecuada.

• Procesos: la manera cómo articulamos las accionesa ejecutar en nuestra gestión del ciclo de vida deter-minará el rendimiento del equipo de trabajo, el gra-do de dependencia y el resultado. Durante estosaños se han desarrollado numerosas metodologíasque marcaban una forma de interactuar entre losdiferentes roles que participan en el desarrollo. Enbase a necesidades surgen modelos que tratarán dedar solución a formas específicas de abordar unasolución dentro del marco contextual vigente. Loque tendremos que hacer, cada vez que iniciemosun proyecto, es evaluar qué variables son las quenos condicionan y, en base a ello, decidir qué méto-do es el más apropiado para la ejecución de los pasosnecesarios que nos cubrirán todo el espectro de unciclo de vida de desarrollo del software. Existenmetodologías que requieren una definición estric-ta y muy bien formalizada de cuál es la secuenciade pasos que debemos seguir, con revisiones estric-tamente formalizadas que pueden, en función delcontexto, ser necesarias. Sin embargo, en muchasotras ocasiones podrían hacer que los tiempos sealarguen debido a un excesivo esfuerzo burocráti-co, causando, por consiguiente, una pérdida detiempo no justificada.

dotN

etM

anía

<<

37

dnm.ALManía<<

Figura 1

dotN

etM

anía

<<

38

dnm.ALManía<<

• Tecnología: es el tercer eje de coor-denadas que van a condicionar la ges-tión del ciclo de desarrollo. No todaslas personas suelen estar alineadas yla tecnología puede ser usada paraasegurar la consistencia en la aplica-ción de los procesos y proporcionarla fina guía para mantener el proce-so en las vías del desarrollo correc-tas, permitiendo facilitar el segui-miento, la monitorización y el aná-lisis del mismo. Pero ya no solotendrá un papel determinante en elpropio proceso sino que la aplicaciónabusiva, muchas veces de un excesode complejidad tecnológica no justi-ficada, puede afectar de forma radi-cal el resultado del producto, asícomo incrementar los costes de man-tenimiento, operación y pruebas(figura 1).

De la mano de Visual Studio Team SystemDurante los más de 20 años que llevoen el mundo de las Tecnologías deInformación he podido observar, ana-lizar y sufrir los efectos del desarrollodel software. He tenido la fortuna depoder experimentar en proyectos rea-les muchas plataformas de desarrollo yello me ha dado una visión práctica dela evolución de las mismas. Debido amis preferencias y a mi carrera profe-sional en Avanade, en la última décadame he concentrado en la plataforma deMicrosoft, por tanto, he podido sentir-me “Quijote” con lanza de punta finahecha con material de Microsoftluchando contra molinos de solucionesdepartamentales allá por los finales dela década de los 90. También me he sen-tido como Skywalker en su nave X-Wing enfrentándome a desarrollos queafectaban a todos los ciudadanos de unpaís. Recuerdo cuando en el eventoMGB (Microsoft Global Briefing) Ste-ve Ballmer inquiría a la audiencia quiénquería enarbolar la bandera del .NET.Ocho años han transcurrido desde aquelmomento. Sin duda, todos los allí pre-sente sabíamos que sería un punto deinflexión hacia una visión de futuro que

paulatinamente nos fuese armando delas herramientas apropiadas para poderenfrentarnos a los problemas empresa-riales y darles solución a igual nivel decondiciones que otras plataformas. Eincluso aquéllos que nos gustaba soñar,nos imaginamos que podría ser algúnaño líder mundial y que permitiría a losequipos pequeños, medianos y grandespoder gestionar el ciclo completo deldesarrollo, pudiendo afrontar los desa-rrollos del software como ingenierías yno como talleres artesanales con crea-tividades puntuales, pero poco riguro-sos para un proyecto a gran escala.

Actualmente, muchos de ustedes yahabrán participado y experimentadocon la evolución de la plataforma dedesarrollo Visual Studio y con la cons-tante evolución casi bianual de las capa-cidades que nos ofrece y que nos per-miten progresivamente afrontar conseguridad cada una de las fases que defi-nen los procesos de desarrollo. Recor-demos la tipología de factores que des-cribíamos en la sección anterior y com-probemos cómo con la plataformaVisual Studio Team System vamos apoder dar la base tecnológica para per-mitir que los roles participativos en unciclo clásico de desarrollo —analistasdel negocio, arquitectos, diseñadores,

desarrolladores, profesionales de lasbases de datos, testadores, gestores—puedan hacer uso de la misma graciasa tres ejes que articulan la plataformaVisual Studio Team System. Por unlado, va a permitir el trabajo colabora-tivo, por ejemplo, gracias a un reposi-torio común donde residir el códigogenerado así como toda la informacióngenerada durante el ciclo de vida delproyecto que nos permita analizar yconocer, en función del rol que ejerza-mos, cuál es la situación del productoen construcción. Por otro lado, darsoporte a los flujos de trabajo entre losroles involucrados, como por ejemplo,habilitar el mecanismo para dar de altapor el analista del negocio un nuevoescenario a desarrollar con toda la infor-mación necesaria y las tareas relacio-nadas así como asignarlas a las perso-nas adecuadas, arquitectos, diseñado-res, desarrolladores. Y, a su vez, permi-tir a éstos, cuando las tareas se com-pleten, avisar a los equipos de test quepueden iniciar las pruebas en un pro-ceso totalmente integrado y de formacontinua. Finalmente, aportando cali-dad en el desarrollo e incorporando lasherramientas necesarias para mejorarlos diseños y manteniéndolos vivosdurante todo el ciclo de vida sin esfuer-zo gracias a procesos de generación decódigo y reingeniería inversa. Se tratade herramientas para facilitarnos losprocesos de test y que nos permitenorientar, en el caso de que ésta sea ladecisión, a modelos TDD (Test-DrivenDeveloper). También permiten aplicarun proceso de Continuos Integration don-de podamos establecer procesos decompilación adaptados con los pasosque consideremos necesarios para nues-tras compilaciones diarias, semanales,así como herramientas y procesos deanálisis de los errores detectados, deltiempo invertido en la corrección deincidencias, etc. Y ofrece transparenciaen la gestión del proyecto, permitien-do configurar el proceso a la platafor-ma Visual Studio aplicando la metodo-logía más conveniente y poder realizarde forma fácil el seguimiento de la evo-lución de las tareas y la corrección deerrores integrados con el diagrama de

Nuevas demandas basadasen modelos de economíaglobalizada y distribución

de las personas condicionanlos parámetros en el

desarrollo del software,naciendo modelos distribuidos y con

metodologías más ágiles

dotN

etM

anía

<<

39

dnm.ALManía<<

Gantt del proyecto, si es la fórmulaescogida para el seguimiento de la evo-lución del proyecto (figura 2).

Son muchas las características queofrece la plataforma Visual Studio TeamSystem para dar soporte a la gestión delciclo de vida del desarrollo, y sin ellasería poco más que imposible enfren-tarse a problemas con desafíos como losque indicábamos en la situación de con-texto al inicio del artículo. No es obje-tivo de este artículo hacer un repaso delas mismas, pues su extensión y expli-cación daría lugar a múltiples artículos.

Medir, medir, medir… Buro-cracia ceroAlguien me dijo una vez: “Si algo nose puede medir, entonces carece devalor”. Claramente es una visión muyparticular pero aplicada a la gestión delciclo de desarrollo se convierte en unavisión muy pragmática que nos ha deayudar a conocer cuál es la salud denuestro desarrollo. Por lo que, sinduda, deberíamos seguir este princi-pio. Una consecuencia inmediata es larecopilación de información de losdiferentes elementos que están inter-viniendo en un momento dado delciclo de vida para después analizar yestablecer mediante métricas en qué

posición del eje de coordenadas nosencontramos. Pero si dicho proceso esburocrático, sobrecarga al equipo detrabajo de manera no continua y dilui-da en el día a día. Por lo que puedeocurrir como el principio físico quenos dice: “Al medir la posición, el efec-to mismo de la medición actúa sobreel momento de una forma indetermi-nable y toda medición del momentodestruye cualquier información previaacerca de la posición”. En mi trayec-toria he podido ver este principiohecho realidad y provocar la toma dedecisiones que nada ya no tenían sen-tido en el momento de ejecutarlas,pues el contexto había cambiado y, portanto, ni la medición ni sus conclusio-nes eran ya válidas. A medida que los

desarrollos son más complejos y dis-tribuidos, la toma de decisiones basa-das en información desvirtuada puedellevar el proyecto a la ruina aunque éstese encuentre en una situación acepta-ble. Por tanto, es necesario medir yanalizar pero en sintonía con las tare-as propias del proceso seguido y queello suponga burocracia cero.

Los datos tienen que almacenarsecon las propias actividades, y no venirdados por la petición puntual de algu-na persona del proyecto, puesto que sugeneración frenará la secuencia de tare-as propias de las personas afectadas yhará que la sincronización con el restode tareas ya no se mantenga, y por tan-to, dar a lecturas incorrectas. ¿Cómosolventar dicho dilema? Utilizadoherramientas integradas con el ciclo dedesarrollo, con las actividades propiasde todas las personas y roles que parti-cipan en el proceso y que su mera acti-vidad, diseñar, registrar una incidencia,testar, codificar, valorar, generar infor-mación, datos que son absorbidos sinesfuerzo por la plataforma de desarro-llo y almacenadas en un repositorio parapoder explotarlas sin coste ni esfuerzoy así ajustar las conclusiones mejor aldía a día.

Como comentaba en el puntoanterior, mi experiencia me ha demos-trado que utilizando todas las capaci-dades ofrecidas por la plataformaVisual Studio Team System y un buenproceso acorde a las necesidades, vana permitir a los diferentes jugadoresanalizar la información, ver gráfica-mente el pasado, el momento actual

Es necesario medir y analizar pero en sintonía con las tareas propias del proceso seguido y que

ello suponga burocracia cero

Figura 2

dotN

etM

anía

<<

40

dnm.ALManía<<

y trazar proyecciones de futuro para así poder tomarlas decisiones más adecuadas e informar al usuariofinal de cuál es realmente el estado del proyecto.¿Cuántas veces no nos hemos encontrado con la

desmotivación por parte del usuarioen cuanto a la inestabilidad del sis-tema, y hemos tenido siempre la per-cepción de que vamos a peor y quenunca los errores se acabarán decorregir? Con Visual Studio TeamSystem podemos mostrarle gráfica-mente la velocidad de trabajo delequipo, le velocidad en la correcciónde incidencias, la tendencia en lareducción del número de errores y,por tanto, hacer una proyección másrealista de cuándo podemos tener elsistema estabilizado. Asimismo dis-ponemos de informes por defecto oinformes que podemos configurar anuestras necesidades para conocer sien algún momento necesitamosreforzar el equipo o en el caso de queestemos sobredimensionados, poderreducirlo con lo que mejoraremos elrendimiento global.

Visual Studio Team System incorpora de facto unaserie de informes, que nos permiten valorar cómo debien o mal está nuestro desarrollo. Como muestra mecentraré en tres informes que por su contenido meparecen suficientemente interesantes para evaluar porun gestor del proyecto: cuál es la tendencia, cuántotrabajo nos queda y cuál es el estado de las tareas. El

lector no se ha de quedar únicamente con estos ejem-plos, sino que ellos han de servir como detonante paraajustar la vista de la información a las necesidades quemás interesan en función de los tres factores comen-tados: personas, procesos y tecnología.

• Tendencia en los errores: con la simple actividadde utilizar una tipología de elemento como sonlos bugs (elemento que define una incidencia enTeam System) el informe tomará los parámetrosinformados con el proceso habitual: por ejemplo,el servicio de help desk, o por el analista de nego-cio o por el testador que accede a Team Systempor alguno de sus múltiples canales y rellena losparámetros permitiendo su explotación análisismediante una par de clics de ratón. En el infor-me, podremos ver los errores que aún siguen acti-vos en la última semana, los que se han cerradoen la última semana o resuelto. Recordemos lostres estados por los que puede pasar un error obug en Team System por defecto: activo indicapendiente de ser corregido; resuelto significa queel desarrollador lo ha solucionado y está pendientepor la persona que informó el error de compro-bar que éste efectivamente está resuelto y se pue-

de cerrar, que sería el último estado. Asimismo,el informe plasma la tendencia en las últimas dossemanas con lo que tenemos una proyección delo que ha sucedido en los dos últimos meses. Estonos puede permitir ver cuál puede ser la tenden-cia al comparar lo acontecido durante la últimasemana a lo sucedido en los últimos dos meses(figura 3).

Figura 3. Informe de tendencia de los errores

Figura 4. Informe de trabajo restante

dotN

etM

anía

<<

41

dnm.ALManía<<

• Trabajo restante: cuántas veces no hemos sido pre-sionados para saber cómo vamos, cómo va unadeterminada tarea, cómo van todas las tareas o siestán finalizadas. Con este informe, que simple-mente recoge la actividad diaria, cero burocracia,totalmente integrado en el proceso de desarrollo,vamos a poder conocer la carga total de trabajo yel número de tareas. Vamos a poder utilizarlo inde-pendientemente del proceso escogido, si optamospor métodos ágiles iremos incorporando repetida-mente el trabajo a realizar para la siguiente itera-ción. Así, tendremos las tareas y la carga de traba-jo para una iteración dada. En cambio, que si opta-mos por un modelo en cascada, el informe nos daráuna foto de la totalidad de las tareas del proyectoy cómo éstas irán disminuyendo hasta acabar elproyecto (figura 4).

• Por último, quisiera finalizar con un informe quenos permitirá analizar cuál es el estado por área.Todo proyecto es organizado por una tipologíade funcionalidad a desarrollar. Así pues, es con-veniente conocer cuál es el estado por las áreasde trabajo. Nuevamente para saber dicha infor-mación con la simple actividad diaria, con los ele-mentos conocidos en Team System como WorkItems y su tipificación a la hora de crearlos, vamosa poder evaluar cómo está cada una de las áreasque configuran el proyecto. El informe muestraen verde oscuro el trabajo en porcentaje com-pletado, en un color verde claro que vemos en lafigura 5 representaría el trabajo más reciente-mente completado en los últimos 7 días, mien-tras que en color rojo se indica el trabajo en horasque resta por finalizar.

Cabe señalar que existen numerosos informes pordefecto y otros que se adecuan mejor en función dela metodología escogida. Todos ellos se pueden inte-grar dentro del ciclo de build diario, pudiéndose enviarpor correo electrónico para su análisis cada mañanaantes de establecer las reuniones con los equipos detrabajo. Todo ello sin dedicar esfuerzo en su elabo-ración, tan solo en su análisis, que es lo que nos daráel valor añadido, para ajustar los recursos a las nece-sidades de cada día.

ConclusionesSon muchos los retos que afrontan las empresas dedesarrollo del software y las consultoras y organiza-ciones que se ven inmersas en estas dinámicas. Porello, entender las nuevas necesidades que demandael mercado permitirá hacer frente en mayor o menorgrado de éxito los resultados. Ya no es suficiente contener los mejores profesionales, sino que es necesa-rio establecer procesos acorde a los parámetros queconfiguran las necesidades del desarrollo. No es sufi-ciente con orquestar las últimas tecnologías, ya queéstas han de ser las necesarias, justas y estar bien arti-culadas para que en lugar de convertirse en un “fran-kenstein” sean la solución que el usuario necesita yque, a su vez, ésta sea fácilmente gestionable y sopor-table. Ya no podemos únicamente contar con el buenhacer y la intuición de los gestores sino que necesi-tamos articular todos estos factores en un procesocontinuo de mejora donde podamos industrializarprocesos y monitorizar todos los pasos para sabersiempre qué está sucediendo y cómo evoluciona, y

así advertir con anticipaciónlos riesgos y poder actuar enconsecuencia de forma rápi-da y efectiva. Nuevos airessoplan, Cloud Computingpuede ser una suave ventiscao un potente huracán quearrase con nuestros desarro-llos. Nuevas exigencias sedibujan en el horizonte pre-sente, que implicarán actua-lizar modelos y formas dedesarrollo nuevas, permitien-do que la integración deldesarrollo distribuido no seconvierta en una pesadillasino en una realidad. Y todoello enfocado a la efectividaden el desarrollo orientandolos procesos de gestión a laBUROCRACIA CERO. Figura 5. Informe de trabajo restante

Introducción

En el nivel de madurez de proyectos de softwareen que nos encontramos, no cabe duda que la cali-dad es uno de los factores principales que debenidentificar nuestros productos.

Incluso si el cliente no lo menciona en la listade requerimientos, y no tengamos plena cons-ciencia de que vamos a ser valorados por ello (vsvelocidad de desarrollo, por ejemplo), es requisi-to necesario e imprescindible ofrecer un buen soft-ware. Y el atributo “bueno” no es algo subjetivo yrelativo, sino algo concreto, bien definido y sobretodo medible, que abarca desde el cumplimientode los requerimientos hasta el rendimiento de laaplicación, pasando por la experiencia de usuario.

Team System, y en particular Team FoundationServer (TFS), nos ayuda a respetar todos los crite-rios de calidad, tanto a medirla una vez el produc-to está finalizado como, más importante aún, a ase-gurarla desde las fases más primitivas del proyecto.

A partir de aquí, describiremos de qué mane-ra podemos ir consiguiendo este objetivo, quéherramientas y procesos cubren cada necesidad, yqué roles deben desempeñar cada una de las fun-ciones. Para ello le preguntamos al cliente “¿Quéespera de este proyecto?” y analizaremos todas lasrespuestas relativas a calidad (¡que no son pocas!).

• “Quiero que el producto resuelva mis proble-mas de negocio”: cumplir los requerimientos.

• “Quiero que el software no tenga errores”: lanecesidad de pruebas.

• “Quiero que el proyecto se acabe en la fechaacordada”: gestión de las métricas del proyecto.

• “Quiero que el sistema funcione bien”: garan-tizar el desarrollo con pruebas de carga.

Identificar los requerimientosLa mayoría de las metodologías definen un pro-ceso que empieza con la recogida de requerimien-tos, a través de reuniones con el cliente y los dis-tintos stakeholders. Se elabora una lista lo más com-pleta posible, que debe incluir también los reque-rimientos de Calidad de servicio (a menudo refe-ridos como QoS, del inglés Quality of Service).

Los requerimientos de QoS representan aque-llos requerimientos no funcionales que registranuna restricción del sistema (por ejemplo, rendi-miento, carga, esfuerzo, mecanismo de seguridado plataforma). Tengamos en cuenta que estosrequisitos no describen la funcionalidad sino lasrestricciones de esa funcionalidad.

Al ser tan particulares, es importante ser rigu-rosos y describirlos correctamente, definiéndolos

Asegurandola calidad final

ALManía

Magada Teruel esTeamLeader de Raona. Mag-

da Teruel es MCPDWindows Developer.

http://www.magda.es.

Una parte importante del proceso de creación de software pasa porasegurar los requerimientos de calidad del producto. Team System TestEdition nos ayuda a incorporar el cumplimiento de esos criterios entodo el ciclo de vida del desarrollo. En este artículo exploraremos lasherramientas disponibles y las buenas prácticas que nos ayudarán a con-seguir nuestro objetivo.

Magda Teruel

dotN

etM

anía

<<

43

dnm.ALManía<<

de una forma medible. Así, por una par-te, se toma constancia de estos reque-rimientos desde el inicio de cada itera-ción, y a la vez se facilita su gestión a lolargo de las iteraciones.

Para cumplir con este doble objeti-vo contamos con las herramientas deTeam System y en concreto TFS.

En las iteraciones tempranas sedeciden los escenarios del proyecto,entendiéndolos como posibles rutas deinteracción del sistema. De ellos se deri-varán los elementos de trabajo de cadaiteración, basándose en su prioridad. Ya partir de aquí, se definen los requeri-mientos de QoS para cada escenario.

Pero esto no es suficiente paramedir ni para conseguir resultados. Enla fase de planificación de la iteración,se va un paso más allá. Se realiza el ejer-cicio de desgranar esos requerimientosen tareas de test, asignándoles una prio-ridad, un responsable y un criterio deaceptación.

Y a partir de aquí es donde las herra-mientas nos pueden dar soporte paracumplir nuestros compromisos: utili-zando TFS para almacenar estas tare-as de test con todas sus propiedades, yvinculando las tareas a los requeri-mientos de QoS, se obtiene un escena-rio medible del que se puede hacer aná-lisis en cada iteración.

Durante la iteración, y a medida queavanza el desarrollo, el tester ejecutarálas tareas de test que tenga asignadas,entre ellas las de QoS, creando nuevoselementos para los conflictos que seidentifiquen, que nos servirán paragenerar informes.

Y al final de la iteración, cuando seevalúe el progreso del proyecto, se rede-finirán los escenarios en que se va a tra-bajar durante la siguiente iteración,basándose en los informes que se hayanobtenido, y en las prioridades de esosescenarios. Se definen entonces losrequerimientos de QoS para el pro-yecto, vinculándolos así a los nuevosescenarios.

Hay que notar que, a lo largo de esteproceso, son varios los roles que inter-vienen para dar una cobertura comple-ta a la gestión de requerimientos de QoS(nota: usaremos la nomenclatura MSF

para definir los roles aunque es aplica-ble a cualquier metodología):

• El conocimiento del negocio, y portanto, de los puntos críticos del pro-ceso, es propiedad del ProductManager. Será él quien aporte infor-mación sobre los requerimientos quese derivan de los escenarios. Porejemplo, a partir de declaraciones

como “Entre las 8 y las 9 de la maña-na, se conecta el mayor número deusuarios y no se aceptará un tiempode respuesta mayor a 5 segundos” segenera directamente un requeri-miento de QoS.

• El Project Manager será el que esti-mará y planificará cada uno de estosrequerimientos para transformarlosen tareas de test e introducirlos en elciclo de vida de TFS con sus correc-tas propiedades.

• El Tester se encarga de llevar a caboesas tareas para poder generar resul-tados, y a partir de ellos informes quepermitan analizar el progreso delproyecto y el cumplimiento o no detodos los requerimientos.

Y ahora… ¿de qué tipo de tareasestamos hablando?

Las pruebasCrear pruebas para comprobar que eltrabajo se ha hecho correctamente, pue-de parecer una tarea tediosa, y no soloparecerlo, sino serlo. En sí, supone un

esfuerzo extra que no todo el mundoestá dispuesto a asumir.

Probar comporta dos procesos: poruna parte, preparar las pruebas, queno suele ser trivial e implica conoci-miento del negocio, y por otra parte,realizarlas repetidamente para com-probar que efectivamente el produc-to supera los criterios de aceptaciónque necesitamos.

Si nos quedamos con lo dicho has-ta ahora, vemos que el proceso de defi-nir las pruebas para comprobar losrequerimientos de QoS, viene prácti-camente inmediato con la introducciónde estos requerimientos en modo detareas de test en TFS. Esto elimina depor sí mucha burocracia, puesto que deforma directa estamos diseñando nues-tro plan de pruebas.

Cuando las pruebas están definidas,se deben ejecutar y almacenar los resul-tados. Esa ejecución debe ser repetidaen múltiples ocasiones para asegurarque los resultados obtenidos son fiables.Esta parte del proceso de test es, sinduda, una de las que implica más esfuer-zo: cuanto más grande sea nuestra apli-cación, más funcionalidades hay queprobar, más parámetros a tener encuenta, y mayor tiempo y recursos sededican a estas verificaciones.

Y aquí introducimos el concepto depruebas automatizadas, que si bien noes nuevo en Visual Studio, sí represen-ta uno de sus más importantes benefi-cios. En sí, las pruebas automatizadasno son más que un conjunto de pasosque un equipo puede ejecutar median-

Probar comporta dos procesos: por una parte, preparar las pruebas, que no suele ser trivial e

implica conocimiento del negocio, y por otra parte,realizarlas repetidamente para comprobar que efectivamente el producto supera los criterios

de aceptación que necesitamos

dotN

etM

anía

<<

44

dnm.ALManía<<

te programación para probar el sistema(en nuestro caso, para probar los pará-metros de calidad del mismo). A prio-ri y según la definición, esto parece queresuelve parte de la batalla que debenlidiar nuestros testers para probar la apli-cación.

Con este modo de trabajo, el grue-so del esfuerzo pasa de la fase de prue-bas a la fase de preparación de las mis-mas, pero para ello contamos con VisualStudio. La versión Test Edition inclu-ye un conjunto de herramientas deprueba perfectamente integradas quenos permiten crear, administrar, editary ejecutar pruebas, así como obtener yalmacenar los resultados, como se verámás tarde.

Con Test Edition, se facilita la tran-sición desde las pruebas manuales,incorporando la posibilidad de auto-matizar esas pruebas, y poder prescin-dir de la burocracia de rellenar docu-mentos con los resultados obtenidos.

Hay que destacar además, que deesta manera, pudiendo hacer pruebasen un entorno tan cercano al entornode desarrollo, contamos con resultadosantes del despliegue del producto. Así,nos ayuda a controlar el cumplimientode los requerimientos desde fases ini-ciales, lo que sin duda nos favorece paraasegurar la calidad del producto.

Esta integración abarca a otras áre-as de Visual Studio Team System, conlo que los resultados se pueden publi-car en bases de datos, generar informes,comparar datos y ver qué errores detec-tamos en las pruebas.

Visual Studio incluye varios tipos depruebas, como pruebas manuales, uni-tarias, de Web y de carga. En este artí-culo hablaremos de estas dos últimas.

Sin entrar en detalle todavía decómo se preparan y ejecutan estas prue-bas automatizadas con Visual Studio,hacemos un primer análisis para darnoscuenta de que el retorno de inversiónde este esfuerzo nos va a satisfacer:

• Ciclos de prueba más cortos. • Mejor calidad gracias a unas pruebas

más exhaustivas. • Pruebas más precisas, fiables y fáci-

les de reproducir.

Pero, ¿con qué herramientas conta-mos para crear este conjunto de pruebas?

Pruebas WebCon Visual Studio Test Edition pode-mos crear las llamadas pruebas Web,que nos permiten probar aplicacionesWeb simulando el punto de vista delusuario.

A bajo nivel funcionan a través deun mecanismo de solicitudes HTTP enla capa de protocolo, que se registranen una sesión del explorador utilizan-do Microsoft Internet Explorer. A altonivel, nos facilita probar tanto la fun-cionalidad de las aplicaciones, como lacarga de las mismas, y se usan especial-mente para probar su rendimiento.

El rendimiento de una aplicación esindicador inmediato de la calidad deservicio, es por ello que prestamos espe-cial interés a las pruebas Web, ya queson una de las bases de las pruebas decarga que comentamos en el siguienteapartado.

También podemos hacer pruebasde carga sobre pruebas unitarias, conel objetivo de validar puntos concretosde nuestra aplicación, tanto de lógica

de negocio, como de datos, aunquevalidan otro tipo de requerimientos.También son muy útiles para hacerpruebas de carga sobre proyectos conWindows Communication Foundation,usando para ello la herramienta gratui-ta WCF Load Test Tool de Codeplex(http://www.codeplex.com/WCFLoadTest). Alser éste un tema bastante extenso, eneste artículo nos centraremos única-mente en las pruebas de carga usandopruebas Web como base.

Es importante notar aquí que lalabor de crear la prueba Web vienedirectamente definida en una tarea deTFS. Esta tarea, si recordamos, corres-pondía al desglose de un requerimien-to de calidad de servicio derivado delanálisis de la aplicación. Esta integra-ción nos permite ser coherentes en todoel proceso y no perder de vista el obje-tivo de este tipo de pruebas, que es con-seguir un producto de calidad.

Ya que este modelo de pruebas sedestina a probar funcionalmente el sis-tema, parece directo que los escena-rios que se definieron en fases ante-riores, se transformen ahora en prue-bas Web para simular, como se hadicho, el punto de vista del usuario dela aplicación.

Figura 1

dotN

etM

anía

<<

45

dnm.ALManía<<

Estando la tarea bien definida, VisualStudio Test Edition nos va a permitir per-sonalizar las pruebas Web tanto como seanecesario para representar nuestra fun-cionalidad: el Editor de pruebas Web nosda la suficiente libertad de modelar losescenarios de forma realista.

Comentemos que al ejecutar estetipo de pruebas Web no obtendremosresultados relevantes hasta que estaprueba Web se incluya en una pruebade carga, ejecutemos esa prueba y ana-licemos los resultados.

Como novedad en Visual Studio2008, las pruebas Web nos permitenejecutar Ajax. Anteriormente, estodebía hacerse utilizando complemen-tos, y las llamadas pruebas Web codi-ficadas, concepto que todavía estávigente en la versión actual y quecomentamos más adelante.

¿Cómo creamos una prueba Web?Desde Visual Studio Test Edition, cre-amos un nuevo proyecto del tipo“Prueba”, y a partir de aquí, debemosregistrar la prueba Web. Esto se con-sigue con un componente integradoque se instala como parte de Visual Stu-dio Team System Test: la Grabadorade prueba Web.

Si queremos probar un proyecto Webpropio, ejecutamos la aplicación quedebemos testear, y copiamos la direcciónURL que nos aparece en el navegador.En nuestro Visual Studio Test Edition,desde el menú de “Prueba”, escogemosagregar una nueva prueba Web, como semuestra en la figura 1.

Iniciamos la prueba Web y cuandose abra el navegador, escribimos ladirección que hemos copiado. Con la

grabadora activa, visitamos nuestro sitioWeb en Internet Explorer como si fué-ramos un usuario final y al navegar, las

solicitudes se irán registrando y se agre-garán a la prueba. La figura 2 muestrala grabadora en marcha.

Una vez tenemos la prueba regis-trada, podemos evaluarla a través delárbol de solicitudes que muestra lasdiferentes peticiones que se han ido cre-ando en nuestra sesión de navegación.

La información que podemos obteneraquí interesa, por ejemplo, para anali-zar propiedades sobre los parámetros

enviados y devueltos entre el cliente yel servidor, en el caso de formularios,tanto visibles como ocultos.

A partir de aquí, tenemos una míni-ma información, que no va a ser sufi-ciente en la mayoría de nuestras apli-caciones Web. Visual Studio Team Sys-tem Test Edition nos permite ampliareste análisis obtenido después de gra-bar la prueba. Hasta ahora solamentehemos seguido la receta de pruebasdefinida en la tarea de test.

Para ampliar la cobertura o el deta-lle de nuestra prueba podemos edi-tarla, y efectuar algunos cambios comoagregar un origen de datos y reglas devalidación, establecer credencialespara simular un usuario, agregar otrasgrabaciones, convertirla en una prue-ba Web codificada, parametrizar ser-vidores, agregar complementos deprueba…

Es decir, se añade toda la informa-ción necesaria para que la prueba des-criba correctamente el escenario deuso. Test Edition nos permite añadiresta información consiguiendo otrogrado más de integración: tenemos

Figura 2

Al ejecutar este tipo de pruebas Web no obtendremos resultados relevantes hasta que esta

prueba Web se incluya en una prueba de carga, ejecutemos esa prueba y analicemos los resultados

dotN

etM

anía

<<

46

dnm.ALManía<<

todos estos elementos como parte de nuestro pro-yecto, alojados en TFS, unificados y disponibles enel control de código fuente para todos los desarro-lladores.

Comentamos algunos de ellas:

Reglas de validación y extracción

Para probar funcionalmente una Web, se puedenagregar reglas de validación que comprobarán si eltexto, las etiquetas o atributos devueltos en la solici-tud de la página, son correctos.

Otro tipo de comprobación que puede hacerse esmediantes reglas de extracción. Las reglas de extrac-ción son similares a las reglas de validación, pero enlugar de comprobar los datos, los extraen y los alma-cenan en el contexto de prueba Web con claves y valo-res. Las reglas de extracción pueden extraer camposde formularios, texto, atributos, encabezados, expre-siones regulares y campos ocultos.

Visual Studio Team System Test incluye reglas devalidación y de extracción predefinidas, y también laposibilidad de crear reglas personalizadas.

Enlaces de datos

Esto nos permite relacionar con un origen de datoslas pruebas que requieran añadir datos de entrada alas solicitudes HTTP, por ejemplo, parámetros deenvío de formularios. La figura 3 muestra un ejem-plo de esto.

Distintas partes de la prueba, pueden tener dis-tintos orígenes de datos, y éstos pueden ser a su vezde muy distintos tipos:

• Como origen podemos tener una base de datos,archivos CSV o XML, y como destino una solici-tud Web o una solicitud de servicio Web.

• Las propiedades que podemos enlazar pueden sercredenciales de acceso, parámetros QueryString,campos de formulario o la dirección URL de lasolicitud.

Convertir la prueba Web en codificada

A partir de una prueba Web grabada (y tambiénmanualmente), podemos crear pruebas Web codi-ficadas, programadas en C# o Visual Basic. Estaspruebas son una clase .NET que genera una secuen-cia WebTestRequests la cual podemos editar comocualquier otro código fuente, agregando senten-cias condicionales, iteraciones, modificar el núme-ro de solicitudes de la prueba y generar dinámica-mente el conjunto de direcciones URL que visitala prueba.

Como es evidente, esto multiplica las posibilida-des de nuestra prueba Web y así poder hacer crecersu cobertura prácticamente hasta donde necesitemospara cubrir la funcionalidad que se desea testear.

Pruebas de cargaUna vez tenemos definidas pruebas Web que nospermiten simular las solicitudes de los usuarios alsistema, debemos comprobar cómo va a respondernuestra aplicación a la interacción simultánea denumerosos usuarios. Es decir, medir su rendimien-to y su capacidad, compromisos necesarios en reque-rimientos de calidad de servicio.

Como se ha comentado, las pruebas de carga estáncompuestas por pruebas Web (y pruebas unitarias).Las pruebas de carga se crean a través del asistentede Visual Studio.

De la misma manera que en las pruebas Web, paralas pruebas de carga contamos con numerosos pará-metros que podemos ir definiendo en las diferentespáginas del asistente.

Para empezar, se deben detallar los escenarios.Los escenarios nos permiten establecer característi-cas que simulen la carga de trabajo de una forma rea-lista y siempre teniendo en cuenta eventuales parti-cularidades del negocio. Por ejemplo, si se trata delacceso al portal de una entidad bancaria, debemostener en cuenta que será utilizado por miles de usua-rios de forma simultánea, con más incidencia a pri-mera hora del día, con velocidades de conexión y dis-tintos navegadores. El mismo portal podría ser usa-do por administradores para actualizar informaciónFigura 3

dotN

etM

anía

<<

47

dnm.ALManía<<

de productos y consultar estadísticas. Cada una deestas situaciones define un escenario distinto.

Un escenario concreto se compone de un modelode carga, una combinación de pruebas, una combina-ción de exploradores y una combinación de redes. Vea-mos qué parámetros nos configura cada uno de ellos.

Los modelos de carga especifican cómo se ajusta lacarga de usuarios simulada durante una prueba de car-ga. Es importante definir un modelo de carga adecua-do para predecir de forma más precisa el uso real espe-rado del sitio Web. En el ejemplo anterior, esto nos sir-ve para definir intervalos de ejecución distintos en elcaso del usuario del portal y del administrador del por-tal (siempre hablando de usuarios virtuales).

La combinación de pruebas nos determina la pro-babilidad de que un usuario ejecute una prueba deter-minada. De esta manera, para distintos escenarios se

pueden tener distintos flujosde trabajo. El porcentaje sepuede basar en número depruebas y en usuarios. Ennuestro ejemplo, podríamosdefinir: “Prueba de login deusuarios sin privilegios, 100pruebas por usuario y minu-to” y “Prueba de login deadministrador, 1 prueba porusuario y hora”. La figura 4muestra un ejemplo de esto.

La combinación de explo-radores es específica de las prue-bas de carga que incluyan prue-bas Web (la ignoramos en casode que ésta solo incluya prue-bas unitarias). Para definir esta

combinación, especificamos los exploradores usados yla distribución de éstos, siendo afines a los objetivos denuestros escenarios. Por ejemplo, asignando una tasa90% a Internet Explorer y un 10% a Mozilla Firefox.

La combinación de redes, por último, es similar a lacombinación de exploradores, definiendo para cada esce-nario una o más redes (LAN, acceso telefónico...) y ladistribución de estas redes en nuestras simulaciones.

Otro elemento importante de las pruebas de cargason los contadores de rendimiento, por la informacióndel sistema que podemos obtener de ellos. Estos conta-dores recopilan información sobre los servidores en quese ejecuta la aplicación, y se permite monitorizar estaejecución y a posteriori analizar los datos.

Figura 4

Figura 5

Es importante definir un modelo de carga adecuado para predecir de forma más precisa el uso real

esperado del sitio Web

dotN

etM

anía

<<

48

dnm.ALManía<<

Llegados a este punto, hemos deter-minado numerosos indicadores sobrenuestra aplicación y ahora hay que sabercómo podemos mejorar su rendimien-to: ejecutando la prueba y analizandolos resultados.

Para ejecutar nuestra prueba tenemosdistintas posibilidades: desde Visual Stu-dio, desde la línea de comandos y, paraconfiguraciones avanzadas, medianteagentes.

Ésta última opción nos la habilitaVisual Studio Test Load Agent, que per-mite ejecutar tests en uno o más ordena-dores remotos. Este sistema se compone de un contro-lador (test controller) y uno o más agentes (test agent).

Lo que nos interesa realmente de la ejecución, lotenemos disponible en el repositorio de resultados.Ahí es donde podemos leer los datos de los contado-res de rendimiento e información de los errores quehayan ocurrido. El mismo editor de Visual Studio nospermite administrar este repositorio de resultados yobtener el análisis que nos va a permitir optimizarnuestro sistema.

El visor de gráfico de contadores y el árbol denavegación nos permiten evaluar ciertos indicadores,como se ve en la figura 5.

La información de la prueba se puede observaren tiempo real, y, más importante aun, se puedenexplorar ejecuciones anteriores.

Esta exploración incluye la posibilidad de impor-tar y exportar conjuntos de resultados, para compa-rar ejecuciones en distintas máquinas, con distintosusuarios y en distintos entornos. Y no sólo eso, tam-

bién la posibilidad de exportar los resultados a Excely poder hacer una lectura fuera del entorno de TeamSystem. La figura 6 representa un ejemplo de esto.

Para conseguir integrar esto en el ciclo de vida deproyecto, se permite la posibilidad de vincular unaejecución de test a un Work Item (elemento de tra-bajo) del servidor de TFS para tener una tarea asig-nada a un recurso que se ocupará de ella.

La figura 7 muestra cómo enlazar con un servi-dor de TFS.

Por ejemplo, si se detecta que en determinadostipos de red hay una cola de procesos de longitudexcesiva, se puede crear una tarea asignada al res-ponsable de sistemas que revise algunos parámetrosde la configuración de la red.

Esto nos da idea de que realmente este entorno yesta manera de trabajar nos permite una metodologíapensada para equipos, en la que varios roles se venafectados por tareas distintas que resuelven un mis-mo objetivo: asegurar la calidad final.

ConclusionesLos requerimientos de calidad de servicio puedenparecer circunstanciales, por ser algo abstractos y enocasiones difíciles de medir. A través de este artículohemos querido defender su relevancia y remarcar laimportancia de cumplir con ésos desde el inicio delproyecto, y hacerlo de manera que podamos impli-car a todos los roles del equipo. Para conseguirlo,contamos con las herramientas que Visual StudioTeam System Test Edition nos brinda, a través depruebas Web y pruebas de carga que se acerquenmucho al escenario real y hacerlo de forma integra-da con el resto de tareas del proyecto. Además de darsoporte con medios suficientes para poder analizarsus resultados y hacer un seguimiento que nos per-mita mejorar la calidad de nuestro software, comoobjetivo principal.

Figura 6

Figura 7

dotN

etM

anía

<<

49

¿Por qué metodologías ágiles?

En Team System, cuando creamos un nuevo pro-yecto en nuestro Team Foundation Server, la pri-mera elección que debemos hacer —y sin dudauna de las más importante para el futuro de nues-tros proyectos— será la metodología que quere-mos usar. Las opciones son variadas y cada vez loserán más, pues cada poco tiempo aparecen nue-vas plantillas metodologías que podemos instalaren nuestro Team Foundation Server. No me voya extender mucho en este punto, más siendo queen este mismo número podéis encontrar infor-mación sobre este tema. Simplemente me gustaríarecalcar la importancia de que esta elección seafundamentada y basada en el conocimiento devarias metodologías.

Dicho esto, ¿por qué elijo metodologías ági-les en la mayoría de las ocasiones? El motivo esuno solo: economía de recursos. En la mayoría de lasocasiones, lo equipos que implantan Team Systemtienen un conocimiento más o menos profundode la herramienta y una fuerte predisposición parausarla, pero es raro que la motivación principal seaimplantar una metodología. En esta situación es

evidente que un enfoque de menos a más es el ade-cuado. Yo siempre digo que las metodologías seganan como las contrarrelojes en ciclismo: yendode menos a más. Es muy difícil saber qué “canti-dad de metodología” necesita un proyecto, unequipo y una empresa. Poder ir de menos a más,añadir paulatinamente elementos hasta lograr elequilibrio justo entre tener un ciclo de vida ges-tionado y coste de mantenimiento del proceso, yevitar que un exceso de burocracia asesine la adop-ción de la metodología es vital. Las metodologíaságiles permiten esto precisamente. Otras meto-dologías imponen ya de entrada unos costes deimplantación y de mantenimiento que no todoslos proyectos, equipos o empresas necesitan o pue-den asumir. Mantenerse ágil es utilizar el mínimode elementos metodológicos eligiendo aquellosque más valor aportan al equipo de desarrollo.

Otro aspecto que me preocupa particularmentea la hora de elegir una metodología es que el desa-rrollador la perciba como algo familiar, que le pue-de ayudar en su trabajo diario. Los desarrollado-res tienden a pensar en las metodologías ágiles demanera más amistosa, mientras que ven otro tipode metodologías como una imposición de más

Experiencias en la implantación de metodologías ágiles con VSTS

ALManía

Rodrigo Corral es MVPy MCPD y uno de los

fundadores de PlainConcepts, donde cola-bora como arquitectode software. Ademástrabaja en Sisteplant

como líder técnico enun proyecto desarrolla-do sobre .NET 3.0 utili-

zando Scrum comometodología de desa-

rrollo. También adminis-tra Geeks.ms. Además,

Rodrigo es tutor decampusMVP. Su blog es

http://geeks.ms/blog/rcorral.

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

Rodrigo Corral

burocracia. No digo que esta percep-ción sea siempre correcta, pero sí quees cierto que contar con el apoyo y lacomprensión de los desarrolladores esvital a la hora lograr implantar con éxi-to una metodología. El motivo es sim-ple: ¡los desarrolladores son los másnumerosos de todo los roles implica-dos en un proyecto!

Más adelante hablaré de las buenasprácticas, aspecto clave para tener unciclo de vida sano. La metodología esel pegamento que une esas buenas prác-ticas y que permite gestionar el proce-so de desarrollo de principio a fin, ite-ración tras iteración. Señalar que Scrumy MSF Agile son las opciones más fre-cuentemente elegidas en las implanta-ciones de Team System utilizandometodologías ágiles.

Las buenas prácticas: clavespara el éxitoDurante el tiempo que llevo trabajan-do con Team System he visto equiposbrillar con diferentes metodologías, ági-les y no. Pensando en esto he llegado auna conclusión clara. Todos esos equi-pos tenían algo en común: habían ele-gido una serie de buenas prácticas, nosiempre las mismas, y las habían incor-porado al día a día de su ciclo de vidaen el marco de una metodología.Además, todos esos equipos habían uti-lizado inteligentemente las posibilida-des que Team System nos brinda a lahora de adoptarlas. Si importante esadoptar buenas prácticas, igualmenteimportante es apoyar esta adopción enuna herramienta que facilite la vida deldesarrollador. Toda práctica que que-ramos introducir en nuestro ciclo devida va a encontrar una resistencia ini-cial por parte del equipo, utilizar unaherramienta natural para el programa-dor es vital. Team System permite a losdesarrolladores realizar todas las acti-vidades relacionadas con el seguimien-to del proyecto y la puesta en marchade buenas prácticas desde el entornoque más natural les resulta, su herra-mienta de desarrollo, Visual Studio.

Además de usar una herramientaque facilite la adopción de buenas prác-

ticas, seleccionar qué buenas prácticasqueremos incorporar a nuestro proce-so de desarrollo es una cuestión que exi-ge atención.

El difícil problema de la ges-tión de proyectosGestionar proyectos de software es unatarea difícil. Son muchos los aspectosrelevantes y muchas las personas impli-cadas. Entre los aspectos relevantespodríamos citar una infinidad de ellos:las herramientas, los procesos, la ges-tión del riesgo, la involucración delcliente, la gestión de la configuración,la calidad, el retorno de la inversión...,y así, una larguísima relación de cues-tiones relevantes. La dificultad está enelegir en cuales de estos aspectos vamosa centrar nuestros esfuerzos en prime-ra instancia. Además, para más inri, nisiquiera serán los mismos de proyectoa proyecto. Evidentemente, todos estosaspectos de la gestión de proyectos pre-sentan dificultades, sobre las que pode-mos actuar para obtener ciertos resul-tados. Tras años de participar en laimplantación de proyectos, he llegadoa valorar algunos de estos aspectos porencima de otros en base a su rango deaplicación en el espectro posible detipos de proyectos, sus posibilidades deéxito y los resultados obtenidos una vezpuestos en funcionamiento. Comentarlas dificultades, las acciones realizadasen pos de su puesta en marcha y losresultados obtenidos es lo que viene acontinuación.

El equipo multidisciplinar, auto-orga-nizado y auto-gestionado

Las metodologías ágiles abogan porformar un equipo multidisciplinar,auto-organizado y auto-gestionado.Entender y formar este tipo de equiposes difícil, pero si logramos establecerun proceso de trabajo que promocio-nes las relaciones entre iguales y el tra-bajo en pos de una meta compartida ycon una visión común, las ventajas sonmuchas. Es evidente que cuando logra-mos trabajar en equipo la productivi-dad se ve impulsada de manera impor-

tante. Un equipo de cuatro es muchomás productivo que la simple suma decuatro individuos. Desde mi punto devista, hay varios puntos clave a la horade lograr funcionar en equipo: estable-cer una visión común de proyecto,fomentar la participación de todos losmiembros y la participación comparti-da en los resultados y, sobre todo, per-mitir que sea el equipo quien, en basea estimaciones, establezca sus compro-misos. Un equipo que establece com-promisos claros, basados en un proce-so formal de estimación, de maneraconsensuada y solidaria, y que los asu-me como suyos, se deja la piel para cum-plirlos. No aparece ningún dilemamoral, sin embargo, cuando un equipono logra cumplir compromisos que hansido establecidos por terceros en sunombre.

La estimación explícita como base decompromisos realistas

Evidentemente, para poder establecercompromisos realistas es necesario rea-lizar un proceso formal de estimación.Estimar la magnitud del proyecto y delas porciones de proyecto que vamos aabordar en cada iteración es vital, pues-to que solo así podremos establecercompromisos realistas, alineados con lacapacidad del equipo. Un equipo dedesarrollo sólo va a tratar de cumpliraquellos objetivos que percibe que sonrealistas. Es necesario aprender a esti-mar y estimar en cada iteración. Un pri-mer paso es comprender que las esti-maciones solo son estimaciones. Estoque, a priori, es una perogrullada, setiende a obviar. Los involucrados en losproyectos, especialmente los roles invo-lucrados en la gestión del proyecto y larelación del cliente, tienden a olvidaresto. Tenemos que entender que cuan-do un desarrollador da una estimación,no conoce muchos de los aspectos quecon más fuerza influirán en la duraciónde la tarea, como, por ejemplo, la difi-cultad técnica. Además, estos aspectosson mucho más difíciles de ver cuantomás lejano está el punto de inicio de latarea. Las estimaciones con estimacio-nes, no contratos. Cuando alguien aje-

dotN

etM

anía

<<

50

dnm.ALManía<<

dotN

etM

anía

<<

51

dnm.ALManía<<

no al equipo convierte las estimacionesen contratos, está realizando un acto deadivinación, no de ingeniería del soft-ware. Si una estimación no nos gusta ono casa con las necesidades del proyec-to, solo podemos añadir recursos orecortar características para que se ajus-te a nuestras necesidades. Estimar y re-estimar con frecuencia, al inicio de cadaiteración y tratar las estimaciones conresponsabilidad y con respeto es elcamino que nos lleva a poder gestionarnuestros proyectos en base a datos obje-tivos. ¿Pero, qué técnicas podemos usarpara estimar con frecuencia y con laparticipación de todo el equipo demanera ágil? Las técnicas de estimaciónque más adopción y mejores resultadospresentan, usadas en combinación enproyectos ágiles son Wideband Delp-hi y Planning Poker. No entro en deta-lles, pero si invito al lector a visitar lasección sobre estimación de mi blog(http://geeks.ms/blogs/rcorral/archive/tags/Estimaci_26002300_243_3B00_n) dondeencontrará información suficiente sobreestas técnicas.

Asumir el cambio como unaoportunidadOtro aspecto complicado en la adop-ción de metodologías ágiles es que éstasasumen el cambio como algo positivo,inherente a todo proyecto de desarro-llo de software. El cambio se debe per-cibir como una oportunidad, más quecomo un problema. Mi experiencia esque este planteamiento choca de mane-ra frontal con el estilo de gestión clási-co al que muchos hemos estado acos-tumbrados. Cambiar esta mentalidades un reto claro en toda implantaciónde metodologías ágiles. Es necesariocomprender y explicar, que si bien loscambios son bienvenidos para que éstosno asesinen el proceso de desarrollo, esnecesario arbitrar cuándo se puedenproducir. Que el cambio sea una reali-dad en todo proyecto, que lo gestione-mos como una oportunidad y que biengestionado el cambio nos ayude a cubrirlas necesidades del cliente, no quieredecir que el cambio constante sea bue-no. Solo durante la planificación de una

iteración es posible asumir cambios yéstos deben estar fundamentados ennecesidades reales surgidas de nuevasoportunidades o de cambios en el entor-no. La manera en la que lidiamos conlos cambios es simple: iterar, iterar, ite-rar y volver a iterar… en iteracionescortas durante las cuales los cambiosestán congelados, y planificar, planifi-car, planificar y volver a planificar... enbase a estimaciones al comienzo de cadaiteración. Evidentemente, contar conuna herramienta que nos permita ges-tionar de manera ágil y cómoda la infor-mación surgida del proceso es vital. Esaquí donde Team Foundation Servernos ayuda de manera clara.

Pruebas unitarias

En todo proyecto hay una frase quese oye a menudo: “si funciona, no lotoques”. Esta máxima es un exponen-te claro de la dificultad que los desa-rrolladores hemos padecido a la horade mejorar, mantener y extender nues-

tro código. Todos sabemos que unafunción con mil líneas es una malasolución, pero solo podremos mejorarla situación si contamos con un meca-nismo que asegure que no rompere-

mos nada. Este mecanismo son laspruebas unitarias. Si bien esta capaci-dad para integrar cambios con facili-dad es —a mi modo ver— la principalventaja de las pruebas unitarias, no esla única:• El conjunto de test unitarios pro-

porciona constante retroalimentaciónde que cada uno de los componentessigue funcionando.

• Los test unitarios actúan como docu-mentación que no se queda obsoleta,al contrario que otros tipos de docu-mentación.

• Cuando el test pasa y el código deproducción es refactorizado para eli-minar duplicidades, es claro que elcódigo está terminado, y el desarro-llador se puede mover a la siguientetarea.

• El testeo unitario fuerza un análisis ydiseño explícito porque el desarrolla-dor no puede crear código de pro-ducción sin entender realmente cuá-les deberían ser los resultados desea-dos y cómo probarlos.

• El software tiende a estar mejordiseñado, esto es, menos acoplado ymás fácilmente mantenible, porqueel desarrollador es libre de hacer deci-siones de diseño y refactorizar en

Visual Studio Team System permite integrar con facilidad el testeo unitario en nuestra metología de desarrollo

dotN

etM

anía

<<

52

dnm.ALManía<<

cualquier momento con la confianzade que el software todavía funciona.

• El conjunto de pruebas actúa comouna red de seguridad contra regre-siones en los bugs: si se encuentra unbug, el desarrollador debe crear untest que ponga de manifiesto el bug ydespués modificar el código de pro-ducción para eliminarlo. En sucesi-vas ejecuciones de los test, todas lascorrecciones de bugs son verificadas.

• El tiempo de depuración se reduce.

La principal dificultad, a la hora deadoptar las pruebas de desarrollo en nues-tro ciclo de vida, es asumir que se trata deuna inversión, no de un coste. Es evidenteque implementar las pruebas unitarias tie-ne un coste, y que este coste solo se ren-tabiliza cuando hay una base de códigoamplia. Es necesario hacer, por tanto, unacto de fe y creer que las pruebas unita-rias nos ayudarán de manera cada vez másimportante según la base de código vayacreciendo y el software se vaya compli-cando. Este acto de fe, muy sencillo paralos equipos que han usado pruebas uni-tarias con anterioridad, es más difícil sininguno de los miembros ha usado estatécnica antes. En estas situaciones, desdela dirección del proyecto se debe lanzarun mensaje claro: las pruebas unitarias noson opcionales.

El testeo unitario se debe imple-mentar desde la primera línea de códi-go del proyecto para que sea totalmen-te exitoso. Si lo hacemos, conseguire-mos reunir, sin un gran esfuerzo, unconjunto de pruebas que actuarán comouna red de seguridad en nuestro pro-yecto. Otro aspecto importante en rela-ción a las pruebas unitarias es contarcon una herramienta de desarrollo quefacilite al desarrollador la escritura y laejecución de las pruebas. Visual StudioTeam System cuenta con un poderosí-simo framework de pruebas unitarias ycon un motón de facilidades a la horade ejecutarlas desde dentro del propioentorno. Personalmente, si tuviese queelegir la técnica que más ha impactadoen cómo desarrollo software en los últi-mos años, sin dudarlo ni un segundo,diría que es el testeo unitario y su inte-gración en el entorno de desarrollo.

Integración frecuente y construccio-nes automatizadas

Una de las grandes novedades deVisual Studio Team System y TeamFoundation Server es la posibilidad decrear construcciones automatizadas.Pero, el simple hecho de contar con unaherramienta que nos ayude en la tarea,no significa que vayamos a adoptar unabuena práctica. De hecho, antes deTeam System ya existía NAnt comoherramienta de automatización de laconstrucción, y se trata de una granherramienta, pero aun así pocos son losequipos de desarrollo que cuentan conla posibilidad de construir todo su pro-yecto con la simple ejecución de uncomando, son pocos los que usan cons-trucciones automatizadas. Conocer lasventajas que aportan las construccionesautomatizadas es el único camino paraque éstas se popularicen y más y másequipos de desarrollo disfruten de susbondades.

El proceso de construir el softwaredesde las fuentes es complejo. De hecho,es cada vez más complejo: elegir las fuen-tes adecuadas, compilarlas con las ver-siones adecuadas de los componentes,asegurarnos que hemos compilado laconfiguración adecuada (debug o relea-se), seleccionar de la salida del procesode compilación aquellos archivos quedebemos distribuir, no olvidar incluiraquellas librerías o componentes de losque depende nuestro software y asegu-rarnos de que su versión es la correcta,generar los archivos de ayuda, crear laestructura de directorios que esperacomo entrada nuestra herramienta degeneración de instaladores, ejecutar elproceso de generación del instalador…y todo esto involucrando a un buennúmero de personas diferentes ¿de ver-dad alguien cree que es posible realizareste proceso manualmente sin cometervarios errores durante el mismo? Lacruda realidad es que no es posible. Ylo que es peor, a menudo los errorescometidos en alguno de los múltiplespasos que hay que dar se detectan soloal final del proceso. El resultado: ¡unaenorme pérdida de tiempo! Y lo peordel caso es que éste es un proceso que

se repite muchas veces a lo largo de lavida de un proyecto. Además, para agra-var aún más la situación, este problemaocurre cuando menos tiempo tenemos,¡justo cuando alguien está esperandoque le entreguemos el software!

En todo proyecto de software exis-te un ciclo que se repite infinitas veces:escribir código, compilarlo, integrarloy realizar pruebas. Contar con un pro-ceso de construcción del software auto-matizado hace que este ciclo se acelereenormemente.

El principal problema que plante-an las construcciones automatizadas esque exigen una inversión de tiempopara ponerlas en marcha. Configurarun proceso de construcción completo,que sea capaz de construir el softwarecompletamente hasta el instalador des-de el código fuente de nuestro softwa-re, y además desplegarlo en un sistemade prueba, es complejo. De hecho, esalgo que solo es abordable y rentable sise realiza de forma incremental, hacien-do que el proceso de construcción crez-ca de manera paralela a nuestro soft-ware. En cualquier caso, a menudo, enproyectos con problemas de integra-ción, merece la pena invertir el tiemponecesario para configurar un procesode construcción a posteriori. El esfuer-zo es grande pero a menudo no hay otrocamino para zanjar de raíz los proble-mas de integración en los proyectos desoftware. Resumiendo, más vale confi-gurar pronto el proceso automatizadode construcción, que hacerlo a poste-riori cuando hay problemas.

Si bien, el simple hecho de poderconstruir nuestro software de maneraautomática nos proporciona claras ven-tajas, yendo un paso más allá y constru-yendo nuestro software diariamente(gracias a nuestro proceso automatiza-do de construcción esto es algo posible)podemos obtener ventajas añadidas. Sidiariamente construimos nuestro soft-ware detectáremos rápidamente proble-mas de integración y podremos corre-girlos cuando los cambios que puedenser la causa de esos problemas aun estánfrescos en nuestra memoria, en conse-cuencia el esfuerzo de corrección serámucho menor. Además, como parte del

dotN

etM

anía

<<

53

dnm.ALManía<<

proceso de construcción, podemos eje-cutar nuestros test unitarios, lo que nosproporcionará la posibilidad de detectarerrores no solo relacionados con la inte-gración. Adicionalmente, como colofóna nuestro proceso de construcción yaprovechando que nuestro proceso deconstrucción despliega el software cons-truido a un entorno de pruebas, pode-mos realizar un test de humo que ase-gure que el software construido tiene lacalidad suficiente como para ser proba-do en profundidad. Este paso aseguraque cualquier error relativo a la confi-guración del software desplegado sedetecta pronto.

A menudo se pone como escusa parano realizar construcciones diarias la mag-nitud del proyecto: ¿cómo vamos a cons-truir y desplegar un software tan com-plejo todos los días? Precisamente cuan-to mayor es el proyecto, mayores son lasposibilidades de sufrir problemas de inte-gración y de calidad, pues más es el códi-go que cada día se añade. Además, elhecho de que grandes proyectos comopor ejemplo Firefox lo haga, demuestraque es viable y rentable. Podéis ver el esta-do de las construcciones diarias de Fire-fox (http://tinderbox.mozilla.org/show-builds.cgi?tree=Firefox).

Métricas

Las métricas son el camino hacia unagestión explícita de proyectos, basada endatos, no en intuiciones. La gran mayoríade los gestores de proyectos creen que lasmétricas son un instrumento poderoso,pero la gran mayoría de los proyectos nousan métricas. Este hueco se produce porla dificultad para recolectar los datos quefundamentan estas métricas. He vistoimplantaciones de metodologías fallarestrepitosamente por el hecho de que losdesarrolladores tenían que pelear paraabrir la hoja Excel en la que se realizabael seguimiento del proyecto para ali-mentar los datos, con el resultado de queese seguimiento se abandonaba.

Si en algo ha cambiado Team Sys-tem la gestión de proyectos es en la faci-lidad que tenemos para recolectarmétricas de lo más variado sin interfe-rir en el día a día del desarrollador, sin

imponerle burocracia adicional. Eldesarrollador trabaja desde el entornode desarrollo realizando sus actividadeshabituales y, de forma casi transparen-te, alimenta un completísimo datawa-rehouse que permite que todo el equipoy los gestores del proyecto accedan alas métricas más relevantes relaciona-das con la metodologías elegida.

En las metodologías ágiles, la velo-cidad de desarrollo entendida como eltrabajo realizado frente al trabajo quehemos estimado que nos queda porhacer es la principal métrica. Utilizarla velocidad, como principal métrica,está fundamentada en que incrementosen este aspecto del desarrollo son sín-toma claro de mejora del proceso dedesarrollo. Si desarrollamos más rápi-do, es que desarrollamos mejor. Ademáses una métrica difícilmente sesgable; sipara mejorar la velocidad de desarrollosacrificamos, por ejemplo olvidando lacalidad, o el equipo, forzándole porencima de su capacidad, o cualquierotro aspecto, tarde o temprano esto severá reflejado en la velocidad. Además,la velocidad es una métrica que nos per-mite estimar con facilidad cuándo elproyecto estará concluido o qué mag-nitud de funcionalidad se debe quedarfuera para cumplir una fecha concreta.

Implantar métricas de progreso cla-ras, nos permite informar a partes aje-nas al desarrollo, de cuál es el compor-tamiento del proyecto de manera analí-tica, explícita y difícilmente rebatible.Esto hace que el resto de los afectadospor un proyecto puedan actuar en fasea datos. Los comerciales no compro-meten fechas imposibles, los redacto-res técnicos pueden planificar cuándopodrán comenzar a capturar pantalla-zos de la documentación, el departa-mento de calidad final sabrá cuandodebe esperar carga de trabajo relacio-nada con nuestro proyecto, etc…

Facilitar la comunicación

La comunicación dentro de los pro-yectos, y hacia afuera de los proyectos,es un problema claro que todas lasmetodologías tratan de atajar. Algunascomo RUP o CMMI ponen el peso enla documentación y en generar arte-factos que actúen como repositorios deinformación que se mueven de un ladopara otro. Otras como Scrum o XP, yen general las metodologías ágiles, asu-men que las personas son el principalrepositorio de conocimiento y tratande habilitar mecanismos (como unaserie de reuniones con propósito claro,

La velocidad es la métrica clave en las metodologías ágiles, Visual Studio Team System no permite obtenerla sin imponer burocrácia al desarrollador

asistentes determinados, duración pre-establecida y entregables predefinidos)para promocionar que las personascompartan información. Sin duda, entodo proceso de desarrollo ágil o notendremos que mantener una magni-tud mayor o menor de documentación.

Es vital lograr que todo el equipoesté informado. Es aquí donde unaherramienta de gestión de proyectosjuega un papel vital. Contar con unlugar único donde el desarrolladorpueda consulta sus tareas, sus bugs odonde el gestor del proyecto puedaconsultar si un requisito está imple-mentado o probado o no, facilita demanera radical el acceso a la docu-mentación. Pero no solo eso, exprimiral máximo las capacidades de notifica-ciones que Team Foundation Serverpone a nuestro servicio, nos va a per-mitir lograr un enfoque “push” ennuestra gestión de proyectos. Ya no esnecesario recordar mirar nuestrasmétricas; podemos recibirlas en nues-tro correo cada día. Unamos esto a lacapacidad que tiene el portal del pro-yecto de Team System para radiarinformación hacia el exterior del pro-yecto, para actuar como repositorio dela información y, sobre todo, parainformarnos de cuándo hay cambiosen documentos de nuestro interés yveremos que la labor de gestión deproyectos será mucho más efectiva,gracias a la utilización de herramien-tas como gestores documentales, wikisy listas de discusión.

Calidad, calidad y… calidad

Unos de los principios de MSF diceque “La calidad es el negocio de todostodos los días”. No dejar la calidad parael final es vital. Si algo he aprendidoimplantando metodologías es que esimposible pensar en tener un procesode desarrollo sano y sostenible sin incor-porar testers a los proyectos. Podéisahondar en las justificaciones leyendoun artículo publicado en mi blog, titu-lado “Pon un tester en tus proyectos”(http://geeks.ms/blogs/rcorral/archi-ve/2006/10/21/Pon-un-tester-en-tus-pro-yectos.aspx).

Es difícil asumir, que añadir calidada nuestro software, hasta cierto punto,al contrario de lo que puede parecer aprimera vista, reduce los costes de desa-rrollo y acorta los plazos. La reducciónde costes se produce porque con unadecuado proceso de desarrollo, quetenga la calidad del software como unfactor central, se descubren antes loserrores. Y los errores, de cualquieríndole, son más costosos cuanto mástarde se descubren, además estos cos-tes se incrementan siguiendo un fun-ción exponencial. Descubrir que nues-tra arquitectura no es capaz de gestio-nar el número requerido de transac-ciones por segundo, es infinitamentemás costoso de corregir si se descubredurante las pruebas de aceptación quedurante la revisión de la arquitectura.La reducción del tiempo de desarrollose produce porque es mucho más fácilconstruir software sobre software esta-ble, que sobre software que no es esta-ble. Hoy en día, todos los procesos dedesarrollo de software son en mayor omenor medida iterativos e incrementa-les. Es imposible construir un incre-mento de funcionalidad si la base de eseincremento no es estable.

Debemos tener en cuenta que elnivel de calidad lo decide el cliente nonosotros. Ningún cliente aceptará de

buen grado un softwareque no cumple sus están-dares de calidad. Poner elesfuerzo en averiguar cuáles el nivel de calidad quenuestros clientes requiereny asegurar, que durantetodo el proceso de desa-rrollo, estamos muy próxi-mos a ese nivel. Pasarse esdesperdiciar fuerzas y que-darse corto significa que enalgún momento tendremosque hacer un esfuerzo aña-dido para alcanzar lasexpectivas de calidad denuestro cliente. Si quere-mos poder actuar con agi-lidad, incorporar cambiosde manera sencilla, y cons-truir el software de mane-ra iterativa e incremental

es imprescindible lograr mantener elnivel de calidad a lo largo de todo elproceso.

Cuando apareció Visual StudioTeam System, Microsoft puso a nues-tra disposición una herramienta depruebas completamente integrada en elciclo de desarrollo de la aplicación. Lostesters son uno más del equipo de desa-rrollo, utilizan las mismas herramien-tas que los desarrolladores y consolidanla información sobre los resultados delas pruebas en el mismo servidor de ges-tión de proyectos. Esto hace que el pro-ceso de compartir la información entredesarrolladores y testers sea mucho máseficiente.

ConclusionesVisual Studio Team System y las

metodologías ágiles son una excelentepareja que me ha permitido ayudar anumerosísimos equipos a mejorar sumanera de desarrollar software. Usarmetodologías ágiles me ha permitidooptimizar la relación entre el esfuerzode implantación y los resultados obte-nidos. Utilizar Visual Studio Team Sys-tem ha sido vital a la hora de impulsary facilitar la adopción de buenas prác-ticas de gestión de proyectos e inge-niería del software.

dotN

etM

anía

<<

54

dnm.ALManía<<

Visual Studio Team System proporciona lasherramientas necesarias para hacer de la calidad

un punto central de nuestro proceso de desarrollo.

dotN

etM

anía

<<

55

Voy a intentarlo. Una factoría es un objeto cuyoúnico propósito es gobernar la creación de otroobjeto. Ofrece una API que es responsable de lacreación de otros objetos. Quien lo llama, solosabe que recibirá una interfaz dada (o clase base)como respuesta. Y la factoría contiene la lógicapara decidir qué clase instanciar. A continuaciónva un ejemplo con lo que tiene que hacer un clien-te para llamar a una factoría. En éste código, ima-gine que necesita obtener una referencia al DAL1

para un sistema multicapa.

DalFactory factory = new DalFactory();IDalInterface dal = factory.Create();

Y este es el código de la factoría más simple,pero efectiva, del mundo.

class DalFactory{

public virtual IDalInterface Create(){return new SqlServerDAL();

}}

El método Createpuede contener cualquier lógi-ca que queramos y necesitemos para determinar

dinámicamente qué clase en concreto debe de ins-tanciarse. No hace falta decir que el objeto devuel-to por la factoría debe implementar la interfaz sopor-tada por ésta, o derivar de una clase concreta.

Esta forma particular de factoría se reconocecomo patrón Factory Method, y, al igual que otrospatrones de diseño comúnmente utilizados, seformaliza en la obra de referencia de Erich Gam-ma, Richard Helm, Ralph Johnson y JohnVlissides (el Grupo de los Cuatro): “Design Pat-terns: Elements of Reusable Object-OrientedSoftware”, Addison-Wesley, 1996.

Después de todo, el patrón Factory Methodañade un nivel extra de indirección para la creacióndel objeto. El cliente delega en esa factoría el hechode crear un tipo concreto. El cliente no sabe el tipoexacto que obtendrá como retorno de la llamada;solo sabe que pertenece a una interfaz (o deriva deuna clase base). La factoría es la que lo sabe todo.Y puede ser tan simple como en el ejemplo ante-rior, donde solo devuelve una instancia de un obje-to ya preestablecido, o tan compleja como la de unescenario en el que el nombre del tipo se lee de unorigen de datos externo. Y también podría mostrar

Preguntas comunes a los patrones de diseño

Dino Esposito

Me encantan los patrones de diseño pero, a veces, me resulta difícil comprender su sutileza. Heleído descripciones del mismo patrón en distintas fuentes, pero sin llegar a un punto concretode comprensión. Incluso dudo que haya alguien capaz de explicar la diferencia entre Factoría yFactoría Abstracta usando un lenguaje humano. Y, más que las diferencias entre los patrones, suscampos de aplicación.

todonet@qa

Los patrones de diseño no son la panacea, pero ayudan a construir soluciones robus-tas y bien codificadas. Los patrones se refieren a una solución, pero, a menudo, lohacen en una forma un tanto críptica o nebulosa, y su traducción a lenguajes huma-nos se convierte, a menudo, en un requisito. E incluso cuando se ha hecho, uno pue-de encontrarse solo manejando las diferencias entre parejas de patrones similares.Presentamos tres ejemplos.

Arquitecto en IDesign,Dino Esposito es una delas autoridades mundia-les reconocidas en tec-nologías Web y arqui-

tectura de software. Suslibros más recientes son"Programming ASP.NET3.5-Core Reference" e"Introducing Microsoft

ASP.NET AJAX" (Micro-soft Press). Es ponente

regular en eventos de laindustria de ámbito

mundial, como TechEd oDevConnections, y

europeos, como Dev-Week y Basta.

tod

otN

et.q

a@

dot

net

mania

.com

1 Data Access Layer, o Capa de Acceso a Datos. (N. del T.)

A bote pronto, me da la impresión de que estamos inten-tando comparar naranjas con manzanas. El ensambladoSystem.AddIn es representativo de una tecnología, mien-tras que un Service Locator (Localizador de Servicio),es un patrón de diseño. ¿Tecnología o patrón? En estenúmero, me estoy centrando en los patrones, así quedejemos de lado System.AddIn por un momento y centré-monos en el patrón que implementa, en comparacióncon el patrón de Service Locator.

System.AddIn implementa el patrón de Plugin, quese define de la siguiente forma: es un marco de trabajo paravincular clases a una aplicación de forma dinámica, basada enalgún tipo de configuración. La figura 1 muestra un dia-grama UML que ilustra el comportamiento del patrónPlugin.

¿Es un Plugin diferente de un Add-In de alguna for-ma? No, son lo mismo. Considera los dos términos comosinónimos. Más concretamente, un componente Plug-in (o Add-In) es un componente que es descubierto diná-micamente, y cargado por una aplicación que lo aloja(hace las veces de host del componente). El componen-te normalmente se compila y distribuye de forma sepa-rada de ese host. Por supuesto, el host y su conjunto dePlugins deben acordar un contrato para que la comuni-cación tenga lugar.

El ensamblado System.AddIn es una tecnología quepermite la implementación sencilla del patrón Plugin.

Suministra características para el descubrimiento, acti-vación, aislamiento y ejecución aislada (sandboxing). LaAPI de System.AddIn se sitúa entre el host y sus Pluginsy garantiza que ambos puedan evolucionar indepen-dientemente y cambiar sus respectivos modelos inter-nos de objetos sin afectar a la otra parte. A esto se le lla-maba antes bajo acoplamiento.

El patrón Service Locator es similar al patrón Plu-gin en su formulación y equivalente en el funcionamiento.Al final, puedes usar ambos con parecidos resultados.Pero son “animales” distintos.

dotN

etM

anía

<<

56

dnm.todonet@qa<<

una implementación intermedia entre ambos, e imple-mentar algún tipo de flujo de trabajo para decidir el tipoa devolver.

¿Qué hay de la Factoría Abstracta? Es una varia-ción del patrón Factory Method, que añade un segun-do nivel de indirección. Un cliente que invoca unaFactoría Abstracta no recibe una instancia de la cla-se final que necesita. En su lugar, recibe una factoríapara ese objeto que busca. El siguiente código expre-sa esto desde la perspectiva del cliente:

DalAbstractFactory af = new DalAbstractFactory();IDalFactory factory = af.GetFactory();IDalInterface dal = factory.Create();

Y este es un ejemplo de código de una imple-mentación de una Factoría Abstracta.

class DalAbstractFactory{

public IDalFactory GetFactory(){return new DalFactory();

}}

Factory Method es uno de los patrones máscomúnmente utilizados. Y si nunca lo has usado entu código (o quizá lo has utilizado sin darte cuentasiquiera de que estabas implementando ese patrón)quizá deberías reconsiderarlo. Idealmente, un Fac-tory Method debería tenerse en cuenta para cada sen-tencia new presente en el código.

¿Cuándo se necesita una Factoría Abstracta? Entien-do que se utiliza menos que un Factory Method, por-que es más frecuente necesitar un nivel de indirecciónque dos niveles. En el código habitual, donde se nece-site ser flexible y extensible, probablemente será muyraro que necesites una Factoría Abstracta. Es más nor-mal si estás construyendo algún tipo de framework (deentorno de desarrollo). Un ejemplo de implementaciónde una Factoría Abstracta se encuentra en ASP.NET.Para cada petición HTTP, el entorno de ejecución creaun manejador HTTP para servir la petición. Eso es unpatrón Factory Method. Pero, lo que hace internamente,es obtener primero una factoría para el manejador, ydespués, el manejador real. Justo los dos niveles de indi-rección del patrón Factoría Abstracta.

Tod

otN

et.q

a@

dot

netm

ania

.com

Tod

otN

et.q

a@

dot

netm

ania

.com

Figura 1. El patrón Plugin en acción

La semana pasada, un colega dijo que tenía que usar un Localizador de Servicio, en vez de loque yo tenía pensado usar, que era una arquitectura de Add-In basada en el nuevo ensambla-do System.AddIn de .NET Framework 3.5. ¿Qué es un Localizador de Servicio?

No, no te pierdes nada especial. Aunque se pueden mar-car algunas diferencias entre un IoC y los Plugins, el efec-to final sobre la aplicación que distribuyes a los usuarioses el mismo. Ambos suministran a la aplicación el nece-sario desacoplamiento para que la aplicación host y loscomponentes externos puedan interactuar. Desde unaperspectiva de diseño, ambas son buenas soluciones.

IoC está basado en un framework que suministra unaclase contenedora con la que se comunica el host. Estaclase contenedora, actúa de forma parecida al ServiceLocator, pero incorpora una lógica mucho más sofisti-cada y ofrece un conjunto completo de herramientas paralos desarrolladores. Y, más importante, la clase contene-dora IoC es gratis; ha sido comprobada y está lista parautilizar. El siguiente código de ejemplo, utiliza UnityFramework de la Enterprise Library 4.0.

// Instanciar la clase contenedora IUnityContainer container = new UnityContainer();

// Enlazar a la información operativa almacenada en // la sección <unity> del fichero de configuración UnityConfigurationSection section =

ConfigurationManager.GetSection("unity");section.Containers.Default.Configure(container);IDalInterface dal = container.Resolve<IDalInterface>();

// Usar la interfaz obtenidaMyClass c = new MyClass(dal);

El contenedor devuelve una instancia de un tipo queimplementa una interfaz dada. La correspondencia seestablece en el fichero de configuración.

Algunos argumentan que IoC es preferible a los Plu-gins porque se pueden marcar dependencias directa-mente desde el constructor de la clase consumidora(MyClass, en el ejemplo anterior). Si utilizas un Plugin ensu lugar, tienes que inspeccionar todo el código de la cla-se consumidora para averiguar dependencias. Este es unbuen punto a favor.

Otros indican que es preferible IoC porque hace quela aplicación sea más fácil de probar. Francamente, estono lo veo así. Si IoC y Plugin están implementados deforma acorde con la definición, las pruebas no son unproblema en ninguno de los casos.

La razón primordial para escoger una implementa-ción IoC en lugar de un Plugin (ya sea manual, u obte-nido mediante System.AddIn), es la disponibilidad de con-tenedores IoC gratuitos y extremadamente potentes.Uno muy bueno es Castle Windsor ( http://www.cas-tleproject.org).

dnm.todonet@qa<<

dotN

etM

anía

<<

57

Tod

otN

et.q

a@

dot

netm

ania

.com

Tod

otN

et.q

a@

dot

netm

ania

.comEl patrón Plugin existe para inyectar una imple-

mentación concreta donde el cliente espera cierta inter-faz. El propósito principal del Plugin es hacer que el códi-go sea extensible y flexible. Como efecto colateral, conesa implementación se libera en cierta forma la depen-dencia entre componentes. A su vez, el Service Locatorse enfoca principalmente en obtener el menor nivel deacoplamiento entre componentes. Representa una con-sola centralizada que es usada por una aplicación paraobtener todas las dependencias externas que necesita. Alhacerlo así, tiene también el efecto colateral de hacer queel código sea más flexible y extensible. Ambos patronesocultan la complejidad de la búsqueda de componentes,pueden manejar instancias ubicadas en memoria (cache opool) y ofrecen una fachada común para la búsqueda ycreación de componentes.

Service Locator es un patrón originalmente defini-do por Sun para el desarrollo en Java (la informacióncompleta puede encontrarse en http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLoca-

tor.html). A continuación, vemos una implementacióntípica de este patrón:

// Una posible implementación del patrón Service Locator public class ServiceLocator{

private static const int CONST_IDATACONTEXT = ...;public object GetService(Type t)

{if (t == typeof(IDataContext)){

return new SqlServerDalFactory(); }:

}public object GetService(int serviceID){

switch(serviceID) {

case CONST_IDATACONTEXT:return new SqlServerDalFactory();

:}

}:

}

Obviamente, puedes modificar esta implementaciónde Service Locator para añadir soporte para configura-ción (que era un aspecto ya cubierto por la especifica-ción original del patrón), y añadir métodos específicosque devuelven clases que implementan interfaces bienconcretas. Cuando se hace así, tanto Plugin como Ser-vice Locator tienden a ser la misma cosa. En la imple-mentación estándar de Service Locator el cliente pasaalguna información que identifica el tipo a recuperar.Pero, en el escenario de un Plugin, el cliente llama a unmétodo que devuelve un tipo dado. Son funcionalmen-te equivalentes, pero inspirados en filosofías distintas.

Ambos estáis en lo cierto.

Traducido al castellano por Marino Posadas

Parece que el nuevo Santo Grial es la Inversión de Control (IoC). Todo el mundo está interesado en ello,y tenerlo en una aplicación parece que, de alguna forma, hace que la aplicación sea más “guay”. A mí, meparece como el modelo de Plugin. ¿Me estoy perdiendo algo?

dotN

etM

anía

<<

58

desvánMarino Posadas

Vista Annoyances Resolved. Setrata de un documento sobre cómoevitar inconveniencias y problemas

vinculados al uso de Windows Vista. Su autor, Koroush Gaziya había figurado en esta sección a propósito de sus “Tweak-Guides” (ver dotNetManía, núm. 23). Se requiere la lecturaen línea (no está disponible para descarga) desde http://www.twe-akguides.com/VA_1.html.

Making a .NET app run on Vista withAdministrator priviledges, es un artí-culo técnico para resolver un problema

común tanto en aplicaciones de apoyo como de gestión. Lofirma James Crowley, en Developer's Fusion y está accesibleen la dirección: http://www.developerfusion.co.uk/show/7987.

TIPS DOTNET Enorme conjunto de artícu-los sobre programación en .NET espe-cializado en la resolución de problemas

del día a día en el desarrollo. Montones de trucos aprovecha-bles. Todo ello en la dirección: http://www.tipsdotnet.com/Dotne-tArticles.aspx.

Blog de Scott Morrison. el especialista en elDataGrid de Silverlight, que trabaja conel equipo de desarrollo del producto. No

solo es una estupenda fuente de código sobre programaciónde esta versión del control, sino también de noticias sobre loque es espera sobre él en la versión final. Accesible desde:http://blogs.msdn.com/scmorris/default.aspx.

World Wind 4.7.Visor geográfico consoporte de GPS y widgets, que permi-te acercamientos visuales a cualquierregión del globo, con visualización en

3D. Basado en imágenes del satélite Landsat y datosde misiones topográficas del Shuttle. Es de uso y des-carga gratuita desde la dirección de http://www.down-load.com/World-Wind/3000-2054_4-10374181.html.

documentos en la red

utilidades del mes

sitios del mes

La guerra de los navegadores

Durante años, la abrumadora ventaja de Internet Explorer respecto a su com-petencia ha sido incuestionable. En la actualidad, sigue ocupando una posi-ción claramente hegemónica respecto a sus competidores (hablamos de sis-temas operativos Windows), pero surgen voces diciendo que ese pastel va arepartirse más distributivamente entre los —ya podemos decirlo— “cincojinetes de la navegación”.

Porque son 5 los protagonistas eneste momento: además de MicrosoftInternet Explorer, disponemos de Fire-Fox, Safari, Opera y el recién llegadoGoogle Chrome (hay algún otro sí, peroentre estos 5 se “comen” más del 99%del porcentaje de usuarios). La guerraentre ellos promete ser cruenta en unalucha por mejorar sus habilidades, inte-gración, características, navegabilidad,rapidez, cumplimiento con los estánda-res y cualquier cosa que los ingenierospuedan pensar que podría decantar a unusuario a utilizar uno en detrimento del

resto. O más a menudo que el resto, porque ya se leen entradas en blogs don-de los fanáticos del tema argumentan porqué es mejor Safari para descargararchivos de vídeo, IE respecto al intérprete de HTML 4.01 + CSS, Operapara la navegación de sitios planos sin multimedia, etc.

Conscientes de ello, y de que el público quiere saber cuáles van a ser lospróximos caminos a seguir, se reunieron hace poco en Nueva York variosrepresentates de las compañías productoras con motivo de la Web 2.0 Expo,en una sesión bajo el título “El futuro de los navegadores”. Los temas de dis-cusión: HTML 5 (y su elemento Canvas), Silverlight, IE 8, Google Chromey Firefox. Presente y futuro.

Cuando uno de los asistentes (programador Web) tomó la palabra en unarueda de preguntas, habló del “horror y el miedo” que le había causado laaparición de Google Chrome, en referencia a si habría que volver a repro-gramarlo todo, dependiendo del soporte de los estándares que ofreciese estenavegador, ante el aplauso unánime de la audiencia.

Parece que la respuesta, no solo del representate de Google (Ojan Vafai),sino de las cabezas visibles de FireFox (Brendan Eich) y Microsoft (ChrisWilson) fue similar, con algunas variaciones: una de las cosas que ha inspi-rado y seguirá inspirando nuevas características en esos navegadores es HTML5 y todo el soporte que ese estándar preconiza, aunque cada uno lo toma a sumanera y aplica distintos niveles de soporte que seguirán mejorando con eltiempo (¡cuidado, distintos niveles de soporte!). Esperemos que no llegue lasangre al río y los estándares sigan marcando la pauta para que todos tenga-mos un punto común. Google Chrome, parece que sí va a tener unos cuan-tos puntos en común con IE8 a tenor del análisis que hace Peter Bright en“Chrome antics: did Google reverse-engineer Windows?” (http://arstechni-ca.com/articles/paedia/chrome-antics-did-google-reverse-engineer.ars), publicadoen el prestigioso eNoticiario Ars-Technica.

Y, mientras tanto, un altísimo porcentaje de los sitios Web no es compa-tible con los estándares fundamentales ni al 70% y no digamos ya respecto atemas como la accesibilidad, donde Silvelright 2 —según lo mostrado y comen-tado por Josh Holmes a este redactor—, destaca por méritos propios. Espe-remos que sea así, y que si la R.I.A. suena nos lleve a todos a buen puerto, trasuna navegación tranquila (el barco, que sea al gusto de cada uno…).

firma.firma.firma.firma

BandWidth Meter. Es una herra-mienta de prueba (gratuitadurante 30 días) que permite

medir el ancho de banda utilizado, tanto en Internet,como en redes locales, separando los dos tipos de pro-cesos. También permite analizar paquetes de datos, lospuertos por los que tiene lugar el tráfico y establecerfiltros sobre IP’s. Funciona para XP, 2003 y Vista. Dis-ponible en www.desksoft.com.