Nuestro amigo más temido: el Proceso de desarrollo de SW

Las ventajas del uso (adecuado, medido) de un proceso de desarrollo de software son tan evidentes como la pesadez y sensación de pérdida de tiempo que provocan. Pero son necesarias, porque facilitan mucho la integración e integridad de los datos del proyecto, su seguimiento y, en definitiva, la calidad del producto (software + otras cosas).

Por consiguiente, es necesaria una herramienta que 'nos lleve de la mano' para trabajar de la manera indicada en el proceso de desarrollo que se haya definido, sin que ello suponga un esfuerzo extra para el desarrollador. Os podéis imaginar que el Team Edition del Visual Studio provee algo para esto (aquí hay un webcast detalles de lo que ofrece Microsoft) y, como siempre, un ejemplo clarifica los requisitos:

Supongamos que nuestro proceso dicta que al principio del proyecto se deben crear varios documentos, con diferentes autores / responsables y datos sobre el proyecto. Por ejemplo, un documento de requisitos que lo hace el analista, acta de creación de equipo por parte del jefe de proyecto, documento de Visión del proyecto, Oferta, etc. Pues nuestra herramienta debería ser capaz de crear automáticamente los documentos y meterlos en sus debidas carpetas de red, hacer el esqueleto de dichos documentos en base a los datos del proyecto, crear y asignar tareas para que cada personas las vea en su Project o sucedáneo, crear la carpeta donde se alojará el código en un servidor de control de código fuente, etc...

También debe saber establecer políticas de calidad de los producto que se generen, como normas de codificación o análisis y testeo del código que se crea, no permitir que se realicen tareas hasta que se hagan otras de las que se depende, etc.

Un aspecto importante de este componente que define el proceso es que, debido a la gran cantidad de otros componentes con los que se comunica, puede ser adecuado para coordinar el resto de ellos. Sería una especie de controlador (MVC) central, donde mediante un lenguaje de definición de proceso (Microsoft ha definido el suyo propio para el Team Foundation Server) se configura la manera de actuar del resto de los componentes del sistema (en ese proyecto, puede haber otros con diferentes procesos de desarrollo).

La posible arquitectura e implementación se tratará en el próximo capítulo.

Primer paso: un Servicio de Directorio .

O LDAP, o como se quiera llamar. Existen varias soluciones muy maduras y expandidas, como LDAP o el Active Directory de Windows, y otras novedosas y prometedoras, como Fedora Directory Server -mirar estos pantallazos-.

Desconozco cuánto puede aportar cada uno, pero podemos hacer una lista de requisitos que un equipo de desarrollo de software de tamaño pequeño a mediano (5-7 personas) pueda tener, en cuánto a servicios de directorios se refiere:

• Autentificación centralizada y segura.
• Creación de usuarios, grupos.
• Hacer árboles de recursos de red y personas y poder otorgar permisos con diferentes granularidades (a nivel recurso, persona, departamento, proyecto, etc...)
  
• Facilidad para autentificarse en servicios web
  
• Ligereza
• Integración con otros servicios de la empresa, como el correo, calendarios, portales (de proyectos, corporativos).
• Permita una movilidad total del usuario en la empresa: pueda pertenecer a un departamento pero estar (habría que definir 'estar') en otro, pueda tener varios roles en varios proyectos y ser capaz de administrar cambios con facilidad y simpleza.
• Lo que metamos en los comentarios

La mayoría de los requisitos anteriores se cumplen ya en soluciones existentes como OpenLDAP y Fedora Directory Server. La autentificación para servicios web distribuidos es la que más dudas puede dar. Haría falta un servicio del directorio que fuese capaz de hacer árboles de servicios web en la empresa, de manera que los usuarios puedan descubrir y utilizarlos automáticamente dependiendo, otra vez, de dónde están localizados dichos usuarios (departamento, proyecto...).

Por qué servicios web? Porque cualquier integrante de proyecto está continuamente ejerciendo 'pequeñas acciones', como crear una nueva tarea de proyecto y asignarla, guardar una revisión de un documento, guardar un poco de código fuente, etc... que son parte del flujo de trabajo del proyecto y hay que centralizarlos en un 'servidor del proyecto'. Aparte de la interoperabilidad, seguridad, el hecho de que usan XML, la apuesta de muchas compañías por ellas...

En definitiva, un proyecto de software necesita de un directorio central que ofrezca autentificación centralizada, seguridad, movilidad e integración con las herramientas de trabajo comunes de todos los integrantes del equipo y varias otras que no se han citado. En un entorno GNU-Linux, estos servicios de directorio los ofrecen OpenLDAP y Fedora Directory Server.

Para cambiar un poco

Os dejo un golazo de Ronalinho que lo metí ayer jugando al Pro Evolution 6.

Dedicado a Arrieta, con quien tantos piques eché el año pasado. Cómo los añoro, ahora que vivo en un piso con 3 chicas!!

Vuelta de tuerca: Team Edition / Team Foundation Server

Mientras que Visual Studio ayuda al programador en su tarea, a un nivel individual, Microsoft ha sacado hace poco la edición Team Edition, orientada hacia el trabajo en equipo. Ayuda en la gestión de todo el ciclo de vida del proceso de desarrollo de sw: gestión de configuración de sw y elementos, definición del proceso de desarrollo, toma de métricas y rediseño del mismo, gestión a nivel proyectos -creación equipo, distribución tareas...-, informes automáticos sobre diferentes estados del proyecto, control de código fuente, diseño e implantación de tests unitarios y de validación, análisis de código, herramientas para diseño de componentes estilo UML, otras de diseño y administración de BBDD...

La lista es larga y os imaginareis que ahí no acaba la cosa. La cuestión es que han conseguido integrar el producto, las herramientas para crearlo, las de apoyo en la gestión y, más importate aún, el flujo de información entre ellas.

Ejemplo: Un desarrollador encuentra un bug que lo publica mediante el Visual Studio. El jefe de proyecto, abre el project y ve que ha sido publicado un bug, por lo que crea una nueva tarea para solucionarlo, asignándosela a X. Ese tal X, desarrollador de pura cepa, abre su Visual Studio y ve que tiene una nueva tarea pendiente, para lo que descarga el código necesario del servidor, lo soluciona y almacena de nuevo el código cambiado.

Dicho sea de paso, el servidor puede estar configurado para que realice automáticamente tests, análisis o pre-compilaciones a todo código que se le suba. Por último, El jefe de proyectos va al portal del proyecto, automáticamnete creado y gestionado por el Team Foundation Server, y ve ahí una serie de informes de calidad, estado del proyecto, etc que le apoyan en la toma de decisiones diarias.

Los siguientes artículos tratarán sobre funcionalidades del Visual Studio Team Edition y, sobre todo, en cómo emularlas en GNU-Linux.

Visual Studio para Linux

Este año ha habido para mí un cambio en el % de tiempo invertido a programar para windows o GNU-Linux. Por motivos laborales (la empresa donde hago el proyecto desarrolla casi en exclusividad para entornos Windows, utiliza .NET a saco y tienen un entorno corporativo basado totalmente en Windows y demás herramientas empresariales de Microsoft) me 'he sentido obligado' a aprender a programar en C#, apoyado bajo esa maravillosa joya que es el Visual Studio.

Tengo la opinión de que la diferencia cualitativa más importante entre Windows y Linux es que Windows tiene el Visual Studio (la integración que parece que .NET 3.0 va a ofrecer con Vista será otra). Eclipse, por muchos plug-ins que le enchufes, no llega ni a holisquearle la punta del pitilín. Por no hablar de velocidad, donde desgraciadamente .NET es muy, muy superior, pero ése es otro asunto. La cuestión es que la curva de aprendizaje del Visual Studio es muchísimo menos pronunciada que para cualquier otra IDE, sobre todo para interfaces gráficas. El objetivo es claro: hay que conseguir un Visual Studio para Linux.

IEUP!

Hola!

Me llamo Eneko y, como supongo que mi vida personal os importa un pimiento, seré breve en esto de la introducción.


Soy Eneko Taberna Goitiz, nacido en Pasai Donibane, criado en Lekeitio, Durango y Donostia y actualmente domiciliado en Arrasate, un chico normal y corriente que le gusta la informática -pasión y oficio- y estar con su querida novia haciendo lo que sea. Actualmente hago el proyecto el fin de carrera, un simulador de ascensores (parecido y espero que en unos meses mejor que el mítico elevate) para Orona en Ikerlan (o sea, cubierto por completo bajo el enorme paraguas de la MCC).

Y ahora a postear cosas más interesantes.
Un saludo!!!!!