Desde Microsoft llevamos ya más de dos años hablando a empresas y organismos públicos sobre las bondades de la computación en la nube en general y de los servicios de la nube de Microsoft en particular. Y en el último año hemos visto cómo la nube de Microsoft ha obtenido un buen montón de reconocimientos y certificaciones sobre seguridad, privacidad y protección de datos y cumplimiento de normativas y estándares, que deberían disipar las dudas de las organizaciones españolas para lanzarse a usarla. Al fin y al cabo, Microsoft es
el primer y único (a día de hoy) proveedor de servicios en la nube que ha superado los rigurosos requisitos de la Unión Europea y de la Agencia Española de Protección de Datos sobre el almacenamiento y protección de los datos.

Aun así sigue habiendo reticencias para usar la nube en general, especialmente en las organizaciones tradicionales, razones que no son subjetivas precisamente: las inversiones en hardware y software hay que amortizarlas; los contratos de outsourcing siguen vigentes; los procedimientos y procesos de TI tienen que adaptarse a la nueva realidad de la nube; son algunos impedimentos que hemos oído y que no tienen una resolución inmediata. Pero a pesar de estas trabas, hay escenarios por los que se pueden empezar ya mismo si realmente se quiere. Uno de ellos es el escenario de Desarrollo y Pruebas en la nube. Es aplicable a prácticamente cualquier organización, ayuda a las áreas de TI a entender el uso de la nube y es el escenario más extendido a nivel mundial. Y no es solo factible, sino que proporciona la agilidad y el ahorro de costes que demanda el negocio, difícilmente comparables a escenarios de Desarrollo y Pruebas en hardware dedicado o nubes privadas. Ahora las organizaciones solo tienen que aplicarlo. Vamos a ver cómo.

Escenario de desarrollo y pruebas en la nube

Es un escenario muy común que aplica a cualquier organización que apoye sus procesos de negocio en aplicaciones de software (¿a día de hoy hay alguna que no?), independientemente de que disponga de un área de Desarrollo como tal o que el desarrollo lo tenga  subcontratado a un tercero. Al fin y al cabo las aplicaciones no solo hay que desarrollarlas, sino que hay que probarlas antes de pasar a explotación, y hay que mantenerlas y evolucionarlas en el tiempo para ajustarlas a las necesidades del negocio. Cualquier
organización suele tener más o menos definido un proceso de gestión del ciclo de vida de las aplicaciones y en mayor o menor medida disponen de unos entornos hardware y software, llamémoslos entornos de Desarrollo, de Integración, de Calidad y de Preproducción, donde las aplicaciones se desarrollan y se prueban antes de pasar al entorno de Producción.

Pues bien, esos entornos de desarrollo y pruebas e incluso el proceso de gestión del ciclo de vida de las aplicaciones, se pueden subir a Microsoft Azure, facilitando al área de TI las sempiternas exigencias de negocio: el ahorro de costes y la agilidad de adaptación al negocio.

Puestos de desarrolladores y probadores en la nube

El caso más evidente e inmediato es subir a la nube los puestos de desarrolladores y probadores. Aplica a organizaciones que proporcionan el puesto a su fuerza de desarrollo y pruebas de aplicaciones, sean internos o subcontratados, y a organizaciones que se dedican a desarrollar o probar aplicaciones para terceros. En ambos casos, la organización facilita el puesto, con su hardware y software, a la persona que desarrolla o prueba.

Si el puesto del desarrollador o del probador fuera una máquina virtual de Microsoft Azure, tanto la organización que lo proporcionara como la persona que lo usara se beneficiarían, en comparación con un puesto físico e incluso con un puesto virtual en las instalaciones de la organización, por la sensación de recursos hardware ilimitados y de rapidez en el aprovisionamiento que proporciona una nube pública como Microsoft Azure. Y es independiente de la plataforma y herramientas que se instalen en el puesto, ya sea un puesto Windows con Visual Studio o un puesto Linux con Eclipse.

La organización podría estandarizar los puestos virtuales de sus desarrolladores y probadores y aprovisionarlos en cuestión de minutos; podría definir diferentes perfiles de puestos virtuales en función del proyecto, de forma que el puesto tuviera el hardware y el software necesario y suficiente para ese proyecto específico.

Por su parte, la persona podría acceder al puesto virtual desde cualquier lugar y a través de cualquier dispositivo con conexión de escritorio remoto; una tableta sería suficiente; la persona que estuviera implicada en varios proyectos podría disponer de varios puestos virtuales. Y si la persona usa Visual Studio, los ajustes del entorno de desarrollo (IDE), que también se almacenan en la nube, se sincronizan entre instancias de Visual Studio para que el entorno de desarrollo (IDE) tenga el mismo aspecto y el usuario se sienta más cómodo.

Con todo esto, la organización solo pagaría por los puestos virtuales que se han usado realmente y solo durante el tiempo que se han usado, aprovechándose del pago por uso inherente a la nube pública; la organización pueda asumir más fácilmente picos de subcontratación de fuerza de desarrollo o pruebas proporcionando más puestos rápidamente y eliminándolos una vez se hayan superado esos picos. Y la organización podría incluso planificar en Microsoft Azure el uso de los puestos virtuales, reduciendo sus ventanas de disponibilidad; así,
en lugar de una disponibilidad de 24x7 que supone un puesto físico, se podría reducir a una de 12x5, posibilitando el acceso al puesto virtual, por ejemplo, sólo de 8am a 8pm de lunes a viernes, controlando aún más el consumo y reduciendo la factura.

Entornos de Desarrollo y Pruebas de aplicaciones en la nube

Es habitual que los proyectos para el desarrollo de nuevas aplicaciones o para el mantenimiento de las existentes tengan presupuestos limitados para hardware y software, lo que supone una limitación importante a la hora de montar los entornos de desarrollo y pruebas necesarios. Y también es habitual que las organizaciones optimicen sus inversiones, compartiendo hardware y software para los entornos de pruebas de diferentes aplicaciones, ofreciendo colas y ventanas de uso para cada proyecto. En ambos casos, lo que
acaba comprometiéndose al final es la deseada agilidad en el desarrollo de las aplicaciones, demandada por negocio.

En la misma línea que los puestos de desarrolladores y probadores, los entornos de ejecución donde se desarrollan y se prueban las aplicaciones también son susceptibles de aprovecharse de la nube. Los entornos de Desarrollo, de Integración, de Calidad y de Preproducción de una aplicación se pueden subir a la nube, independientemente de la naturaleza de la aplicación, use o no servicios de la nube, e independientemente de la plataforma y tecnologías que utilice, ya sea .Net sobre plataforma Microsoft o Java sobre plataforma Linux. Microsoft Azure proporciona todo lo necesario para montar esos entornos utilizando máquinas virtuales y conectándolos si así se requiere con los recursos propios de la organización mediante redes virtuales o buses de servicios.

Además, Microsoft Azure permite guardar estados de las máquinas virtuales, para que levantar un entorno de pruebas sea rápido y el entorno esté listo para usarse, pudiéndose desechar ese entorno al finalizar las pruebas. Si se dispone de los entornos de pruebas necesarios para una aplicación en los momentos oportunos, la aplicación se puede empezar a probar antes, se puede probar más a menudo y mejor, lo que impulsa la agilidad en el desarrollo y mejora la calidad final de la aplicación cuando se pase a Producción. Y cuando se habla de pruebas en general, se incluye la posibilidad de realizar pruebas de escalabilidad de una aplicación, montando el entorno de Preproducción idéntico al de Producción, para que estas pruebas tengan sentido y sean lo más realistas posibles. Esto unido a la posibilidad de lanzar la carga de las pruebas de escalabilidad desde Microsoft Azure a través su servicio Load Test Service que se menciona más adelante, sitúa Microsoft Azure como una solución completa para las pruebas de escalabilidad de aplicaciones.

Y, obviamente, subir los entornos de desarrollo y pruebas a Microsoft Azure es efectivo en costes; solo se paga por lo que se usa y si los entornos solo se mantienen disponibles cuando es oportuno, el ahorro puede llegar a ser considerable comparado con la adquisición de hardware dedicado, más aún si se trata de entornos de Preproducción.

Finalmente y en relación al ahorro de costes, si los entornos de desarrollo y pruebas están basados en plataforma Microsoft, es muy aconsejable tener en cuenta el uso de suscripciones MSDN para el licenciamiento de estos entornos, en comparación al uso de licencias productivas; la suscripción MSDN se paga por usuario, mientras que la licencia productiva se paga por instalación. Basta con adquirir suscripciones MSDN para los desarrolladores, los probadores y los administradores de sistemas que manipulan y hacen uso de
los entornos de desarrollo y pruebas para que estos entornos estén correctamente licenciados sin coste adicional; y se pueden licenciar ilimitados entornos de desarrollo y pruebas. Si se comparan los costes de las suscripciones MSDN con los costes de las licencias productivas, la sorpresa puede ser gratificante.

 Gestión del ciclo de vida de las aplicaciones en la nube

La última pieza del escenario de Desarrollo y Pruebas susceptible de mover a la nube es la gestión del ciclo de vida de las aplicaciones (ALM). Y hay situaciones en los que puede mucho tener sentido, por ejemplo: cuando una organización pretende externalizar el desarrollo de aplicaciones a un tercero y las políticas de seguridad corporativas impiden que el tercero pueda acceder a las herramientas ALM de la organización; o bien, cuando una organización pretende abordar proyectos de desarrollo, pero no desea que la gestión del
ciclo de vida de las aplicaciones le suponga adquirir nueva infraestructura que tenga que administrar. En estos casos utilizar herramientas ALM en la nube encaja perfectamente y la solución ALM de Microsoft ofrece esta posibilidad.

Hay dos modalidades para usar la solución ALM de Microsoft en la nube: la primera es desplegar el servidor ALM, Team Foundation Server (TFS), en máquinas virtuales de Microsoft Azure, opción soportada por Microsoft y que se podría denominar Team Foundation Server en infraestructura como servicio (TFS en IaaS, Infrastructure-as-a-Service). La segunda es usar el servicio ALM de Microsoft Azure llamado Visual Studio Online (VSO), que es básicamente una solución SaaS (Software-as-a-Service) de Microsoft como lo puede ser Exchange Online o Dynamics CRM Online. El servidor TFS y el servicio VSO comparten gran parte del código, aunque a día de hoy la funcionalidad de TFS es superior a la de VSO, concretamente en lo que concierne a la adaptación de la herramienta a los procesos de la organización y en la explotación de la información a través de informes y cuadros de mando. Por otro lado, VSO es un servicio mantenido y administrado por Microsoft, mientras que TFS en IaaS exige que la organización que lo use se encargue de su administración como un servidor más de su entorno productivo (monitorización, copias de respaldo, actualizaciones, etc.). Es por lo tanto decisión de la organización escoger la modalidad que más se ajuste a sus requerimientos.

Independientemente de si se escoge TFS en IaaS o VSO, hay tres características de Visual Studio Online que pueden resultar muy interesantes de usar en cualquier caso. El primero es el servicio de construcción automatizada en la nube (Build Service) que facilita lanzar builds en la nube y se paga por minuto de compilación al mes; una organización que tenga congestionado sus servicios de build y que no quiera adquirir infraestructura adicional para ampliar su capacidad, o simplemente que no quiera adquirir hardware dedicado para los servicios de build, puede aprovecharse de este servicio en la nube que se paga por uso y no requiere administración de la infraestructura. El segundo es el servicio de agentes de pruebas de carga en la nube (Load Test Service) que permite generar la carga desde la nube para realizar pruebas de escalabilidad de aplicaciones y se paga por minuto de usuario virtual al mes; facilita que se ejecuten este tipo de pruebas más a menudo, sin necesidad de aprovisionar el hardware necesario ni de configurar el sistema de agentes. Y el tercero es el servicio de monitorización de aplicaciones en la nube (Application Insights), que proporciona información relativa a la disponibilidad de la aplicación y a los errores de ejecución que se puedan estar produciendo en la aplicación, y además extrae patrones de uso de la aplicación que permitirá a la organización focalizar las inversiones en la evolución de la misma.

En definitiva, la combinación de Visual Studio y Microsoft Azure ofrece una solución ALM en la nube muy completa para cualquier organización.

Como hemos visto, el escenario de desarrollo y pruebas en Microsoft Azure no es solo factible, sino que proporciona la agilidad y el ahorro de costes que demanda el negocio, difícilmente comparables a escenarios de desarrollo y pruebas en hardware dedicado o nubes privadas. Ahora las organizaciones solo tienen que aplicarlo.

Se define como Release Management (RM) al proceso de gestión de las entregas de software que abarca desde las etapas de construcción hasta el despliegue de dicho software en sus diferentes entornos de operación.

Es una disciplina surgida como consecuencia del aumento de la complejidad tanto de los proyectos de desarrollo software cómo de las arquitecturas físicas de los entornos de operación donde dicho software operará, especialmente en los últimos años donde dichas aplicaciones además deben contemplar su disponibilidad en multiples dispositivos móviles, etc.

Esos dos factores de complejidad, unidos a la demanda de mayor celeridad a la hora de llegar al mercado, hacen necesario definir y automatizar en la medida de lo posible cómo se despliega el software. Adicionalmente, como en todo procedimiento, también se busca establecer una línea base en el proceso de despliegue de manera que pueda ser medido su rendimiento y mejorado en caso necesario.

Aunque esta definición puede parecer relativamente sencilla de entender, existe dentro del panorama actual, cierto mal entendimiento sobre qué es Release Management exactamente.

¿Qué NO es Release Management?

El proceso de Release Management puede y debe formar parte de un proceso de ámbito mayor que es el de Gestión del Ciclo de Vida de las Aplicaciones o Application Lifecycle Management (ALM).

Anteriormente hemos visto que Release Management se enfoca en el proceso de entrega y despliegue del software a sus entornos de operación. A menudo, existe cierta confusión entre este proceso y los procesos de Gestión de la Configuración o Configuration Management (CM)

Para ayudar a entender las diferencias, se debe empezar por tener en cuenta que RM es parte fundamental de la Gestión del Ciclo de Vida de las Aplicaciones, el cual involucra disciplinas y roles de varios campos de la tecnología, como son: Ingeniería software, desarrollo, SQA, Arquitectura, Operaciones IT, entre otros, mientras que por otro lado, el proceso de Gestión de la Configuración es exclusivo de IT, y está encaminado a establecer y mantener la consistencia de los entornos de operación así como su funcionamiento y rendimiento.

Por tanto, debemos distinguir que RM está orientado a gestionar el despliegue del software y CM persigue gestionar las aplicaciones y sus entornos de manera que se garantice su debido funcionamiento.

Release Management como parte de DevOps

Habiendo establecido qué es RM, podemos ver que dicho proceso de gestión involucra tanto a los equipos de desarrollo software, como a los gestores de los entornos de operación de dicho software. Es claro, entonces, que RM forma parte fundamental de la estrategia que busca mejorar el desarrollo software embarcando como parte integral de los equipos de proyecto a los roles de operaciones. Esta estrategia está representada por el concepto de DevOps.

En DevOps se busca establecer mecanismos y procedimientos de comunicación y colaboración entre los equipos de Desarrollo, QA e IT de manera que permitan mejorar los procesos de producción de software mediante la cooperación de dichos equipos.

Por tanto, RM es precisamente parte fundamental de dicha estrategia de DevOps.

Release Management como parte del Desarrollo Agile

En los últimos años, los modelos de desarrollo software basados en los conceptos y prácticas Agile o ágiles han ganado una presencia importante en el panorama actual.

El objetivo fundamental de las metodologías Agile que es mejorar las forma de producir software se fundamentan en la colaboración entre los diferentes miembros de los equipos de desarrollo software. Es aquí donde RM como parte de la estrategia de DevOps tiene su encaje.

Objetivos de Release Management

El proceso de RM permite, una vez establecidos los mecanismos de despliegue del software entre los equipos de desarrollo y de operaciones, garantizar, mediante la automatización, que dichos procesos de despliegue se realizan siempre de la misma manera y con unos resultados esperables y medibles.

Disponer de unos procesos de despliegue optimizados, podría permitir en última instancia, el realizar una entrega continua en los proyectos software de manera que el time-to-market de dicho software se vería reducido al máximo, permitiendo maximizar el aporte de valor del mismo.

Beneficios esperados con Release Management

La organización que establezca un proceso de Release Managment adecuado podría obtener estos beneficios:

• Reducción del time-to-market en los proyectos software al reducir la puesta en funcionamiento del software en sus entornos de explotación
• Reducción del esfuerzo dedicado a desplegar los sistemas software a los diferentes entornos de operación puesto que RM ayudará a automatizar gran parte del proceso
• Aumento de la calidad del software al dotar a los equipos de desarrollo software de recursos ágiles y flexibles para poder probar y corregir el software cuanto antes, especialmente si los entornos de pruebas e integración contemplan escenarios de aprovisionamiento automatizado en modelos de nube (cloud) pública.
• Incremento de la colaboración y la productividad de los equipos de desarrollo software y de operaciones al automatizar las tareas repetitivas y/o complejas, y disponer de un conjunto de herramientas y procesos comunes.
• Predictibilidad en los procesos de puesta en funcionamiento de los sistemas software al disponer de información y herramientas que permiten medir, estimar y mejorar dicho proceso.

Relase Management con Visual Studio 2013

La solución ALM que proporciona Visual Studio 2013 incorpora soporte para implementar en las organizaciones procesos de Release Management.

En su última versión Visual Studio incorpora VS Release Management Server, quien de manera integrada con Team Foundation Server, puede automatizar el despliegue de las Builds realizadas por TFS a los entornos de Desarrollo, QA y Operación, entre otros.

Con el cliente Visual Studio Release Management Client se pueden definir los diferentes entornos de los que se desean gestionar los despliegues de una manera gráfica y amigable.

El cliente de Visual Studio Release Management se incluye con las ediciones Ultimate, Premium, Test Profesional con MSDN y con MSDN Platforms.

Con el cliente de RM, se pueden visualizar los diferentes pipelines de despliegue, y gestionar el tráfico de aplicaciones a desplegar en cada uno de los entornos y sus servidores asociados.

Para que una máquina servidora pueda ser parte de un proceso de despliegue debe tener instalado un agente Visual Studio Release Management Agent, que está disponible en 2 ediciones:

• Visual Studio Deployment Agent Standard, que permite controlar máquinas servidoras físicas con 2 procesadores y hasta 2 máquinas virtuales sobre ellas, o hasta 2 máquinas virtuales en entornos de nube, tanto pública como privada. Esta edición del agente es la opción recomendada en escenarios con Windows Server Standard con poca o ninguna densidad de virtualización.
• Visual Studio Deployment Agent Datacenter, que permite controlar máquinas servidoras físicas con hasta 2 procesadores e ilimitadas máquinas virtuales sobre ellas, o hasta 8 máquinas virtuales en entornos de nube, tanto pública como privada. Esta edición del agente es la opción recomendada en escenarios con Windows Server Datacenter con alta densidad de virtualización.

Los usuarios involucrados en la aprobación o verficación de los procesos de despliegue, no precisan licenciar ninguna CAL específica y disponen de un interfaz web para la administración de dichos despliegues.

Como se ha comentado anteriormente, Visual Studio Release Management Server puede ser incluido como parte de los procesos de Build gestionados por TFS de manera que como parte final de una Build, se puede invocar a sus capacidades para instanciar un procedimiento de despliegue.

¿Por dónde empezar con Release Management?

Hemos visto que RM no es un proceso que se implante de manera inmediata, sino que se basa en personas y procesos. Por lo tanto, para la mayoría de las organizaciones tiene sentido empezar identificando qué habilidades y tareas relacionadas son de las que disponen de partida.

Después conviene identificar y priorizar las metas que se desean alcanzar al implantar RM dentro de la organización.

Adicionalmente, conviene, como en todos los procesos de cambio en las organizaciones, localizar un sponsor del nivel adecuado dentro de la organización que habilite el proceso de cambio, y además, se debe contar con la ayuda de un experto sobre la materia. Además es importante focalizarse en los logros obtenidos y establecer un plan de comunicación y formación interna adecuado.

Es importante ser persistente en el cambio, y esperar cambios efectivos solamente después de cierto tiempo de que los nuevos procesos estén en marcha.

Conclusiones

Release Management permite definir procesos y mecanismos que permitirán a las organizaciones gestionar el despliegue de sus proyectos software de manera fiable y automatizada, ayudándoles a ganar en eficiencia y fiabilidad al tiempo que permite reducir los recursos necesarios para esas actividades. Estas mejoras permitirán obtener mejoras en la calidad de software producido, al tiempo que reducirán el time-to-market de los productos, dotando de mayor competitividad a la actividad de la empresa.

Visual Studio Release Management es la solución de Release Management de Microsoft que permite extender las capacidades ALM de la solución de Visual Studio de una manera integrada y homogénea  dotando a los equipos de desarrollo y operaciones de un conjunto de herramientas y el soporte metodológico que les permita colaborar y cooperar para obtener los objetivos comunes de aumento de la calidad del software, reducción de los costes y el tiempo de puesta en producción del software.

En un artículo anterior mencionaba cómo cualquier defecto software puede afectar de manera importante tanto a los usuarios finales como a las organizaciones que los fabrican o gestionan. Incluso existen informes del National Institue of Standars and Technology (NIST) del que cifran el impacto económico que suponen los defectos software en varios miles de millones de dólares anualmente. Está claro pues que cualquier organización que produzca  utilice sistemas o aplicaciones software deberá contemplar la calidad de los mismos como un aspecto crítico y fundamental.

Características de QA dentro de Visual Studio

Microsoft incluye como parte fundamental dentro de su solución ALM Visual Studio, todas las capacidades necesarias para garantizar la máxima calidad en el desarrollo de sistemas o aplicaciones software. Es más, desde hace años, como parte de la solución se incluyen herramientas y soporte metodológico que permiten a los equipos de proyecto software realizar las tareas de aseguramiento de la calidad (Software Quality Assurance) de manera integral a lo largo de todo el ciclo de vida y reduciendo la fricción que dichas tareas pueden llegar a suponer para los miembros de los equipos de proyecto.

Utilizando los diferentes componentes de la solución de Visual Studio se pueden realizar:

• Con Visual Studio Test Professional y Team Foundation Server se puede realizar la planificación y gestión de los planes de pruebas necesarios para garantizar la máxima calidad de nuestras aplicaciones, permitiendo recopilar centralizada toda la información relativa a la calidad del software, de manera que se pueden elaborar métricas e informes que dan idea delos niveles de calidad a lo largo de la vida del proyecto.
• Realización de pruebas unitarias por parte de los equipos de desarrollo que permiten asegurar en todo momento la calidad técnica del código producido, pudiendo incluso incluir dichas baterías de pruebas unitarias dentro de los procesos de construcción automatizada a los que Visual Studio Team Foundation Server da soporte.
•  Utilizando Visual Studio Test Professional los equipos de calidad pueden automatizar la ejecución de pruebas funcionales que comprueban las funcionalidades y las operativas que el software debe ofrecer, siendo posible automatizar dichas pruebas funcionales para así reducir los tiempos y los recursos a invertir para ejecutar dichas pruebas.
• Con las capacidades de Visual Studio Ultimate los equipos de proyecto pueden definir y ejecutar pruebas de carga y estrés en sistemas web que darán la información necesaria para analizar cómo se comportarán los sistemas cuando sean sometidos a determinados niveles de uso en sus escenarios de operación finales.

Escenarios de QA con Visual Studio y Azure

Junto con las posibilidades de QA que ofrece la solución de Visual Studio, gracias a las capacidades que proporcionan Windows Azure y Visual Studio Online podemos ofrecer a nuestros equipos de desarrollo y a nuestros equipos de calidad un soporte completo que les permita abordar diferentes escenarios o problemáticas a la hora de realizar sus tareas.

Visual Studio Online proporciona un servicio ALM en la nube que cubre necesidades que van desde la gestión del código fuente, la gestión del royecto, los procesos de build automatizados, e incluso la codificación utilizando editores online que permiten a los desarrolladores disponer de un IDE simplificado sin requerir nada más que un acceso a Internet desde sus máquinas.

Windows Azure es la solución de computación en la nube de Microsoft y ofrece soluciones de PaaS (Platform as a Service), SaaS (Software as a Service) e incluso IaaS (Infrastructure as a Service).

Combinando las posibilidades de Visual Studio, Visual Studio Online, Windows Azure y los beneficios de las suscripciones MSDN de Visual Studio, los equipos de proyecto pueden abordar con total garantía los siguientes escenarios:

Entornos de pruebas en la nube con Azure y MSDN

Utilizando el beneficio ofrecido por las suscripciones MSDN de software sin coste para entornos de desarrollo y pruebas que proporciona a sus usuarios derechos de uso de cualquier software fabricado por Microsoft para ser utilizado en entornos no productivos, y combinándolo con las capacidades de Infraestructura como Servicio (IaaS) de Windows Azure, los equipos de proyecto pueden provisionar cualquier entorno de desarrollo o pruebas en la nube de manera que los costes de aprovisionamiento de dichos entornos son considerablemente menores (pueden llegar a suponer una reducción del coste de un 98% frente a entornos licenciados por otras vías y que además se instalen on-premise). Además de la reducción en los costes, el aprovisionamiento de estos entornos en Windows Azure permite aprovechar la flexibilidad y la agilidad de la nube a la hora proporcionar a los equipos de proyecto sus entornos de desarrollo y pruebas.

Pruebas de carga utilizando Visual Studio Online

Habitualmente, la realización de pruebas de carga impone a las organizaciones la necesidad de contar con los recursos necesarios (infraestructura de computación, comunicaciones, etc.) para poder generar la carga necesaria para estresar los entornos que se desean comprobar. Por ello, habitualmente las pruebas de carga requieren una planificación previa y por tanto no se realizan tan a menudo como pudiera ser necesario. Visual Studio Online proporciona a los usuarios del servicio la posibilidad de, apenas con unos cuantos clics, diseñar una prueba de carga, y adicionalmente, hacer que Visual Studio Online sea el encargado de ejecutar la misma de manera transparente al usuario. Esto es, será el servicio de Visual Studio Online quién se encargue de provisionar, desplegar y poner en juego todos los recursos necesarios para estresar el entorno que el usuario ha diseñado, al tiempo que recopilará los resultados y ofrecerá al final, un informe detallado de los resultados de la prueba. Todo ello, sin que el usuario se haya tenido que preocupar de qué recursos han sido necesarios para ello, ni su instalación, configuración y ejecución.  Esto permite que las pruebas de carga de los sistemas que se están desarrollando o que se quieran medir puedan realizarse siempre que sean necesarias y sin esfuerzo de planificación y aprovisionamiento previos.

Pruebas funcionales utilizando Windows Azure para los laboratorios de pruebas

Visual Studio, gracias a sus procedimientos automatizados de construcción y pruebas, permite que las pruebas funcionales automatizadas que los equipos de calidad han diseñado como parte del plan de pruebas del proyecto sean incluidas como una etapa más del proceso de construcción. De esta manera, los equipos de proyecto pueden establecer controles de calidad automáticos cada vez que se libera una "release" nueva del proyecto. 

Evidentemente, la ejecución de las pruebas funcionales automatizadas, impone que ciertos recursos de infraestructura sean puestos en juego. Hay que poner a disposición de los procesos de construcción automatizada entornos donde desplegar cada "release" así como máquinas con procesos agentes que serán las encargadas de la ejecución desatendida de las diferentes pruebas funcionales sobre dichos entornos. Esto, como es habitual, supone un esfuerzo de planificación y de aprovisionamiento que Windows Azure puede ayudar a resolver. Utilizando las capacidades de IaaS de Windows Azure los equipos de proyecto pueden disponer de los recursos mencionados anteriormente de una manera sencilla y rápida y a un coste mucho menor que si se utilizaran soluciones on-premise.

 Externalización de las pruebas de calidad a terceras empresas utilizando TFS en IaaS o Visual Studio Online

En proyectos de desarrollo de una magnitud determinada es habitual la participación de terceras empresas para que realicen las tareas de desarrollo, o se ocupen de la evaluación de la calidad de los desarrollos realizados, bien por la organización que les ha contratado, o bien por terceras partes. Utilizando el soporte de gestión de los desarrollos que proporciona Team Foundation Server de manera centralizada se puede poner a disposición de todos los participantes del proyecto un soporte común y centralizado que gobierne los diferentes aspectos del proyecto de desarrollo.

Si nos centramos en los aspectos de QA del proyecto, configurando TFS en Windows Azure (IaaS) o utilizando su contrapartida como servicio, como es Visual Studio Online, podemos ofrecer a las empresas encargadas de supervisar la calidad de las diferentes entregas del proyecto, un entorno y un soporte ALM accesible desde cualquier lugar, controlado por la organización que les contrata y de una manera ágil y flexible. De esa manera, ninguno de los proveedores del proyecto tendrá que preocuparse de configurar entornos de pruebas y podrá utilizar los proporcionados por el dueño del proyecto final, al tiempo que todos contarán con un sistema ALM centralizado donde se irán almacenando toda la información de los planes de QA a lo largo de la vida del proyecto.

Conclusiones

Como se ha podido ver, aunando las capacidades de gestión de los desarrollos y de aseguramiento de la calidad proporcionadas por la gama de productos de Visual Studio, junto con los beneficios de las suscripciones MSDN y los beneficios aportados por Windows Azure, las actividades de aseguramiento de la calidad de los desarrollos software pueden realizarse de una manera organizada y eficiente, reduciendo los costes de los recursos requeridos al tiempo que los plazos de proyecto no se verán afectados por falta de agilidad en los procesos de aprovisionamiento de los mismos.

Disponibilidad

Los entornos de pruebas deben estar disponibles en todo momento para que los equipos de proyecto no tengan retrasos en sus planes por falta de la infraestructura de pruebas necesaria. Que un equipo de proyecto no pueda realizar parte de su trabajo porque no tiene disponible el entorno de pruebas necesario en un momento determinado, provoca una pérdida de recursos y de tiempo preciosos y valiosos, sobre todo en los tiempos que corren.

Flexibilidad

Un entorno de pruebas debe adaptarse a las necesidades del equipo de proyecto, y no al revés. Un plan de pruebas efectivo debe contar con el mejor entorno de pruebas para él. Los planes de pruebas varían sus necesidades a lo largo de la vida del proyecto, y por tanto, los entornos necesarios para su ejecución deben poder adaptarse de la mejor manera.

Gestión y supervisión

En ocasiones, los gestores de TI consideran los entornos de pruebas e integración como infraestructura "no gestionada" puesto que no están ligados directamente a la producción del día a día. Es obvio que esto supone un gran error. Los entornos de pruebas son entornos productivos puesto que son los entornos que utilizan los equipos de proyecto para realizar su labor. Por tanto, dichos entornos tienen que estar correctamente configurados, actualizados y deben ser entornos gestionados para que los equipos de proyecto puedan maximizar su eficacia y productividad.

Entornos de pruebas con Visual Studio

Dentro de la oferta que Microsoft Visual Studio provee es posible ofrecer entornos permanentes de pruebas e integración a los equipos de proyecto sin precisar desembolsos adicionales. Dentro de los múltiples beneficios de las suscripciones MSDN, los clientes pueden disponer de cualquier software fabricado por Microsoft, para instalar y administrar cualquier número de entornos de pruebas e integración sin coste adicional. Para poder disfrutar de este beneficio, únicamente es necesario que todo el personal técnico que utilice o administre dichos entornos tenga asignada una suscripción MSDN (una por cada persona). Esta opción de licenciamiento tiene grandes ventajas en coste frente al licenciamiento tradicional de los entornos de pruebas con licencias productivas tradicionales.

De manera adicional, la utilización de los beneficios de las suscripciones MSDN para entornos de pruebas proporciona a los equipos de TI la posibilidad de ofrecer entornos con una continuidad prácticamente ilimitada, frente a otras opciones como puede ser utilizar versiones de prueba de 90 días del software. Es importante recordar que las versiones de "trial" otorgan únicamente derechos de evaluación del software durante 3 meses, pasados los cuales, los entornos que utilicen dicho software dejarían de estar disponibles y deberían ser desinstalados.

En resumen, utilizando los beneficios de las suscripciones MSDN los equipos de TI pueden ofrecer entornos de pruebas e integración que se adapten a las necesidades de los proyectos de desarrollo con un coste realmente competitivo frente a otras opciones de licenciamiento. Si se desea más información sobre este tema se pueden consultar los beneficios de las suscripciones MSDN en el siguiente enlace https://msdn.microsoft.com/es-es/subscriptions/buy.aspx

Por ello, todos necesitamos acceso a servicios que nos permiten realizar esas actividades y, además, todos demandamos que esos servicios estén disponibles a cualquier hora, al tiempo que exigimos que la interacción con ellos sea fluida y rápida, especialmente - si estos servicios son “online” -.

¿Jugaría con la imagen pública de su empresa?

Pongámonos en la situación de uno de sus clientes. Quiere acceder al servicio o aplicativo que le proporciona su empresa y se encuentra con que no está disponible por una incidencia técnica. Ese cliente es, en primer lugar, una transacción comercial perdida; pero además, es un cliente que ha sufrido una impresión negativa de los servicios ofrecidos por su empresa. En el mejor de los casos, su decepción será pasajera. Será una decepción que, aunque sea superada, no será olvidada. Imagine cuál será el efecto de que ese cliente sufra una serie de decepciones similares. Pasará a ser un cliente perdido. Suponga ahora que esa incidencia técnica en su servicio afectó a miles de usuarios en un corto periodo de tiempo. Aparte de las miles de transacciones perdidas, y de las miles de decepciones individuales sobre el servicio de su empresa, añada ahora que algunos de esos clientes decepcionados expresan su decepción en los medios de comunicación que todos tenemos disponibles hoy en día. A esos miles de clientes perdidos, debemos sumar ahora los cientos de miles que posiblemente tendrán conocimiento del incidente, y que cuando quieran acceder a un servicio como el que su empresa ofrece, recordarán lo que ocurrió y optarán por irse a un competidor nuestro. ¿Podríamos cuantificar cuánto negocio hemos perdido por una indisponibilidad temporal de nuestra tienda online, por ejemplo? Seguro que podríamos hacer un buen intento de aproximación. Pero añadamos a la ecuación el efecto que está teniendo esto sobre nuestra imagen de compañía. ¿Seríamos capaces de cuantificar cómo ha afectado el incidente a nuestra imagen de marca? O, yendo un poco más allá, ¿estaríamos dispuestos a que esto ocurriese de nuevo en un futuro cercano? ¿Querría usted. como representante de su organización, tener que dar explicaciones a sus superiores, a sus accionistas o a uno de esos clientes decepcionados?

Este escenario, es un escenario que muchos conocemos, pero que asumimos como factible (está claro, somos humanos). Es más, incluso cuando esto ocurre, muchas organizaciones no le dan la importancia que realmente tiene.

¿Jugaría con el ánimo de la plantilla de su empresa?

En el escenario anterior hemos puesto en juego solo factores externos a su organización. Podemos pensar que teniendo perfectamente controlados y gestionados nuestros “escaparates al exterior” estaremos tranquilos. Imaginemos de nuevo. Un empleado de su organización, va a introducir un pedido en su sistema de gestión de pedidos. Para ello, recoge la información de un formulario y con ella, rellena una serie de pantallas dentro de la aplicación. Cada pantalla le toma un par de minutos, y además, el proceso, le supone pasar por varias pantallas de información, al tiempo que tiene que recuperar información adicional, por ejemplo la dirección de envío del cliente de otro aplicativo distinto. En el mejor de los casos, ese proceso le toma unos 15 minutos, pero hoy, en plena campaña de compras de Navidad, el sistema de gestión de pedidos está funcionando más lentamente, y ese proceso le está dando problemas al empleado del departamento de pedidos. La aplicación responde con lentitud y el cambio entre pantallas es desesperante. O peor todavía, cuando el empleado tiene medio pedido introducido, el sistema da un error por saturación de la base de datos, y el pedido queda en un estado inconsistente, obligando al empleado a tener que borrar todo lo que hizo, y a empezar de nuevo. Su productividad cae dramáticamente, y en el tiempo que habitualmente procesaba 30 pedidos, ahora solo consigue procesar 10. Tenemos 20 pedidos que se procesarán con retraso, que serán servidos a los clientes con retraso y que posiblemente harán caer la cifra de ventas de nuestra empresa en esta campaña. A todo esto, además, debemos añadirle que los empleados del departamento de pedidos han sufrido una de las peores campañas de Navidad que recuerdan. Han estado crispados, presionados, frustrados y al final de todo el proceso, desmotivados. Imagine las críticas que el Director de Ventas de su empresa pondrá encima de la mesa. Imagine qué opinará el Director de Marketing del daño que ha causado el incidente a su empresa. Pero también, imagine qué opinión tendrá toda la compañía del trabajo realizado por el responsable del sistema de pedidos. ¿Querría estar en su lugar?

El pobre rendimiento de las aplicaciones internas de una organización puede tener el mismo impacto, o incluso más, que las aplicaciones que están de cara a los clientes.

Visual Studio le ayuda a garantizar el rendimiento y la estabilidad de sus aplicaciones

Microsoft, proporciona, gracias a su solución de ALM, Visual Studio, un entorno donde las pruebas de rendimiento y de carga se realizan por los miembros del equipo de desarrollo (tanto desarrolladores como testers) dentro de un entorno que les resulta a todos familiar y altamente productivo. No hay necesidad de que las personas involucradas en este tipo de labores, deban aprender un entorno y una serie de herramientas distintas a las que están utilizando en el día a día.

Además, los tests de rendimiento web son una parte fundamental de las capacidades de testing de Visual Studio 2012. Gracias a estas pruebas se pueden realizar los siguientes tipos de pruebas de rendimiento:

• Pruebas de rendimiento: permiten examinar el comportamiento de un sistema web ante determinadas cargas de peticiones/usuarios que varían radicalmente en el tiempo. De esta manera se podrá verificar que la aplicación o el sistema se comportan adecuadamente liberando recursos y gestionando avalanchas de peticiones.
• Pruebas de estabilidad: stas pruebas permiten verificar el comportamiento del sistema frente a una carga de peticiones sostenida en el tiempo. Son la herramienta más útil para comprobar el dimensionamiento teórico del sistema.
• Pruebas de stress: permiten averiguar la carga máxima de transacciones que podría soportar la aplicación o el sistema, y de esta manera dimensionarlo. También permiten ser utilizadas para detectar cuellos de botella en posibles situaciones críticas de funcionamiento.

Los tests de rendimiento son una herramienta útil pero carecerían de utilidad si no se pudieran analizar los datos obtenidos. Con Visual Studio Load Test Analyzer se puede analizar de manera gráfica las incidencias en el rendimiento de la aplicación con la actividad y las condiciones operativas de los niveles físicos (o servidores) de la misma.  Incluso se puede realizar comparaciones y análisis históricos durante la vida de la aplicación puesto que toda la información de las pruebas queda almacenada en la base de datos de pruebas de Team Foundation Server.

Todos estos recursos disponibles durante el desarrollo de la aplicación permitirán que nuestros desarrollos puedan aprovechar todo el rendimiento y las capacidades de escalabilidad que la Plataforma de Aplicaciones de Microsoft puede proveer.

Conclusiones

El rendimiento de nuestras aplicaciones de negocio es un aspecto vital para la marcha de la empresa, de manera independiente de que estas aplicaciones estén o no de cara a nuestros clientes o usuarios finales. Un pobre rendimiento de las mismas puede tener efectos insospechados que pueden ir más allá de las obvias cifras de negocio. En definitiva, el rendimiento y estabilidad de las aplicaciones no es algo que se deba dejar al azar. Es un aspecto tan vital como el resto de cuestiones relativas a la calidad y por tanto merece dedicar recursos y tiempo a garantizarlo.

Visual Studio, dentro de su plataforma ALM, permite disponer de las herramientas idóneas para garantizar el rendimiento y la estabilidad de sus aplicaciones, soportadas por un proceso de gestión del ciclo de vida de extremo a extremo, e integradas de manera sencilla e intuitiva dentro de los entornos de trabajo de los diferentes perfiles involucrados dentro del proyecto.

A lo largo de este artículo intentaremos profundizar en la problemática que a menudo supone la gestión de proyectos de desarrollo ambiciosos, que incluyen equipos multidisciplinares que utilizan diversas plataformas tecnológicas en su contribución al proyecto. También razonaremos cómo la adopción de una solución de gestión del ciclo de vida (ALM) puede contribuir a mejorar la productividad de dichos equipos de trabajo, facilitar su gestión e incrementar el valor proporcionado por dichos proyectos y equipos a la organización.

La vida no es sencilla… pero puede serlo

Cada vez estamos más inmersos en una actualidad más dinámica, donde nuestros clientes nos demandan mayor valor añadido, mayor calidad, menores tiempos de entrega y, en general, más y mejor con menos.

En las últimas décadas ha quedado patente que la tecnología nos ha ayudado tremendamente a cumplir con estos objetivos, pero en contrapartida, en nuestras organizaciones nos encontramos con un panorama tecnológico variado y diverso. Con seguridad tendremos sistemas legacy que han sido mantenidos por cuestiones como la criticidad para la empresa o por cuestiones económicas de inversiones realizadas y pendientes de amortización. También habrá sistemas o plataformas tecnológicas provistas por diferentes proveedores o fabricantes, que están coexistiendo por razones de  especialización en algunos escenarios de negocio o por estrategias de diversificación dentro de departamentos como IT o Compras.

Si a la visión interna de nuestra organización, le sumamos que en el exterior nuestros consumidores o clientes tienen una oferta tecnológica similar, y que además hacen uso de ella -teniendo a su disposición, por ejemplo, innumerables dispositivos móviles desde los que quieren realizar sus compras o utilizar los servicios que nosotros ponemos a su disposición- veremos una dimensión y una magnitud adicionales a esta complejidad. Esas personas externas a la compañía, como es lógico, seguramente disponen de su propio ecosistema tecnológico, y si queremos mantener nuestras relaciones comerciales, deberemos hacer que nuestra organización pueda comunicarse de manera efectiva y ágil con las suyas -especialmente si contemplamos escenarios business to business.

Combatir los silos tecnológicos

Toda esta diversidad ha provocado la existencia de equipos especializados dentro de nuestra organización y, especialmente, dentro de nuestros equipos de desarrollo e IT. Esto es natural y es consecuencia de dicha especialización, pero tiene implicaciones poco positivas.

Habitualmente los equipos especializados en una plataforma tecnológica tienden a organizarse de manera aislada al resto, generalmente implantando sus propios procesos metodológicos y utilizando las herramientas de gestión del ciclo de desarrollo que les son más afines. Esto, que a priori puede parecer normal, provoca su "encapsulamiento", haciendo que su información de gestión no sea fácilmente integrable dentro de un marco organizativo superior. Es decir, para conocer el estado de sus proyectos de desarrollo es necesario acudir a sus silos de información de gestión, lo que provoca que para poder agregar esta información de gestión sea necesario integrar cada uno de los sistemas de información gestión que cada equipo esté utilizando. Es evidente que esto no es deseable para una organización que pretenda tener información consolidada y actualizada de sus proyectos de desarrollo.

Por otro lado, cada día más, la diversidad tecnológica que está presente en las organizaciones implica que los proyectos de desarrollo de las aplicaciones o servicios estratégicos para el negocio involucran diversos subproyectos de desarrollo sobre diversas plataformas tecnológicas distintas (de nuevo un efecto adverso de la especialización tecnológica). Pensemos por ejemplo, una aplicación para la comercialización de los productos de una empresa, en la cual la información de los clientes está en un sistema CRM sobre una plataforma tecnológica, el control de inventario está sobre un ERP que corre sobre otra plataforma tecnológica y que la aplicación quiere proporcionar escaparates de venta a los clientes en la web (que puede suponer otra plataforma tecnológica) al tiempo que también será accesible desde diversos dispositivos móviles. Cada parte del proyecto será realizada por un equipo especializado en su correspondiente tecnología, pero cada uno de estos equipos deberá seguir el paso del proyecto total y deberá ser capaz de suministrar su correspondiente información sobre el progreso del proyecto. Si se desea tener un seguimiento unificado del proyecto global, cada equipo deberá seguir un proceso metodológico común y deberá reportar el progreso de su trabajo también de manera común, lo cual es complicado de conseguir si no se dispone de una plataforma común de gestión del ciclo de vida.

Microsoft Visual Studio como Plataforma ALM común

La solución Microsoft Visual Studio permite ofrecer la posibilidad de participar a todos los equipos implicados en un proyecto, independientemente de si éstos desarrollan en tecnologías Microsoft o utilizan Java o Cobol o PHP. También permite participar a los diversos roles involucrados en el proyecto: equipos de calidad, gestores de proyecto, especialistas funcionales, ingenieros de sistemas, etc.

Mediante Team Explorer Everywhere cualquier desarrollador que esté utilizando un entorno de desarrollo basado en el IDE de Eclipse podrá integrar sus desarrollos dentro del marco del proceso ALM soportado por Team Foundation Server. También existe la posibilidad, mediante soluciones desarrolladas por socios tecnológicos de Microsoft, de dar cobertura a desarrollos sobre plataformas como COBOL, Oracle, PHP, Python, etc.

La información de seguimiento y gestión del proyecto estará accesible desde Microsoft Office para que, por ejemplo, desde Excel se puedan gestionar los requisitos del proyecto, de manera que los especialistas funcionales puedan utilizar una herramienta que les sea familiar.

También se podrá acceder mediante un navegador web a la información almacenada dentro del portal de proyecto, el cual utiliza el soporte colaborativo y de gestión documental que proporciona Microsoft SharePoint.

Incluso es posible integrar la información de seguimiento y control del proyecto dentro de un sistema de gestión empresarial de proyectos (EPM) soportada por Microsoft Project Server.

Además, dado que Microsoft Team Foundation Server (TFS), utiliza los servicios de SQL Server para gestionar toda su información, será posible, explotar toda esa información utilizando los servicios Microsoft SQL Server como Reporting Services o Analysis Services.

Puede haber casos en los que, aunque el ecosistema de Visual Studio es amplio y con una oferta importante de herramientas integradas con el ALM de Visual Studio, exista la necesidad de diseñar y construir una integración con herramientas y sistemas propietarios de la organización. En ese caso contamos con los siguientes recursos ofrecidos por Team Foundation Server:

• Team Foundation Server ofrece una plataforma de integración que permite desarrollar conectores de manera sencilla y efectiva. Muchas de las soluciones ofrecidas por terceros, que hemos comentado, se han construido utlizando esta plataforma de integración.
• Team Foundation Server dispone de una serie de API’s, accesibles desde diversas plataformas como .NET o Java, que son públicos y están documentados de manera exhaustiva, permitiendo realizar integraciones ad-hoc incluso a bajo nivel.
• El modelo de datawarehouse sobre el que se apoya Team Foundation Server es abierto y se puede acceder a él para generar cualquier tipo de informe o perspectiva de información que sea necesaria en la organización. Por ejemplo, es sencillo crear un informe que nos muestre qué código fuente ha sido el que históricamente ha sido más proclive a generar defectos (bugs) y por tanto sería un buen candidato a ser refactorizado. Esto es sencillo puesto que el cubo OLAP sobre el que se apoya TFS provee un enlace entre el código y los elementos de trabajo.

ALM de Visual Studio elimina los silos de desarrollo

Es un hecho conocido que en la actualidad, especialmente dentro de las grandes organizaciones, aunque no únicamente en ellas, existe una diversidad de plataformas tecnológicas que deben colaborar para conseguir los objetivos empresariales. Dichas plataformas tecnológicas y los sistemas de información, o aplicaciones empresariales que funcionan sobre ellas, requieren de proyectos de desarrollo que permitan explotar todas sus capacidades, de manera que se integren o se adapten a las necesidades de la organización.

Estos proyectos de desarrollo, y los equipos que los acometen, debido a su consecuente especialización (tecnológica), tienden a funcionar como departamentos estancos, dentro de los cuales la información de gestión de los proyectos puede fluir en mayor o menor grado, pero cuando la organización quiere hacer una consolidación del progreso de los diversos proyectos realizados en esos silos de desarrollo o desea hacer que varios equipos especializados colaboren bajo un mismo marco de trabajo, es necesario romper esas barreras dotando a dichos equipos de un soporte metodológico común, que se integre de manera sencilla con sus diferentes herramientas habituales de trabajo, y que además permita consolidar la información de los diferentes actores dentro del proyecto independientemente de cual sea su especialización.

La solución de gestión del ciclo de vida (ALM) que ofrece Microsoft Visual Studio permite eliminar los silos de desarrollo, proporcionando un proceso de gestión de los proyectos de desarrollo común a todos los equipos, independientemente de que desarrollen en plataformas tecnológicas -como .NET, Java, COBOL, etc.-, y sea cual sea la plataforma que dé soporte sus puestos de trabajo -Windows, Linux, Unix, OS X-. Además, Microsoft Visual Studio permite implantar en esos equipos diversos un proceso común que haga que todos ellos trabajen de la misma forma, y además proporcionando una información de gestión homogénea, que permitirá contemplar bajo el mismo cristal el trabajo realizado.

En conclusión: Microsoft Visual Studio es la mejor solución para proporcionar una gestión de ciclo de vida del desarrollo en equipos heterogéneos.

Todo lo que nos rodea está relacionado con uno o varios componentes software: Nuestro móvil, el portátil o el PC del puesto de trabajo, los aparatos que utilizamos para nuestro ocio diario (consolas, reproductores de vídeo o música, etc.). Todo ello, en algún momento, depende de aplicaciones o servicios construidos gracias al software.

Pero, también es curioso cómo ante esta época dorada del software, con sus grandes avances y su espléndido horizonte, algunas cuestiones siguen ancladas en el pasado. Una de ellas es, por ejemplo, cómo se sigue contemplando el desarrollo software como una artesanía o en el mejor de los casos como una maestría. Y a menudo son personas con un tremendo bagaje técnico las que siguen viendo así las cosas. Cuántas veces hemos hablado con responsables de equipos de desarrollo o con directivos de departamentos de I+D+i, que siguen creyendo que el desarrollo del software que su organización precisa para funcionar y competir en el entorno actual es un conjunto de tareas desempeñadas por equipos que suponen empresarialmente un mero coste y no una inversión. Que esos equipos de desarrollo no precisan organización, ni herramientas, ni procesos porque son perfiles creativos y no técnicos. Que la inversión en herramientas y procesos para gestionar el desarrollo software no tiene una razón clara para ser tenida en cuenta dentro de sus planes tácticos o estratégicos. Llegando incluso más lejos, que las herramientas con las que esos equipos efectúan su labor son commodities y que da lo mismo una que otra, si total desarrollar software es un proceso de escribir código, y eso se puede hacer incluso con editores de texto plano como VI o Emacs se puede hacer.

En parte, esta visión que a muchos parecería de otras décadas, está causada por cómo se posiciona todo lo relativo al desarrollo software. Es decir, desde de un punto de vista de marketing de producto, la oferta se centra excesivamente en las características del producto: "Equipe a sus equipos de desarrollo con la solución X porque podrán utilizar la característica Y, la Z o la W". En la actualidad esos productos se ofertan comunicando a los potenciales compradores los beneficios que supondrán para ellos en cuestiones como fiabilidad, seguridad, comodidad, etc. Incluso, últimamente lo que se intenta es asociar esos productos con sensaciones o sentimientos que puedan resultar atractivos a los usuarios (por ejemplo las campañas de marketing de BMW de los últimos años).

Visual Studio: cerca de las necesidades del cliente

Pensando sobre todo esto, surgió la idea de intentar posicionar el desarrollo software y las herramientas de desarrollo de Visual Studio de una manera similar, para de esta manera intentar comunicar o posicionar mejor la oferta de esos productos. Vaya por delante que no pretendemos ofertar Visual Studio a nuestros potenciales compradores con aquello de: "¿Te gusta desarrollar?" que decían los spots de BMW, pero sí que intentamos salir de la mera oferta técnica o centrada en las características del producto o la solución, para ampliar el enfoque y hacer ver a nuestros potenciales compradores que la compra de soluciones de ALM debía estar fundamentada por cuestiones que resultarían más cercanas a sus necesidades o problemáticas.

Posicionar una solución ALM como Visual Studio centrándonos en las características no es tan efectivo como posicionarla indicándole a los potenciales clientes cómo con ella podrían solucionar problemas como la productividad de sus equipos de desarrollo, o el nivel de gestión y seguimiento que podrían tener sus proyectos, o cómo la calidad de sus aplicaciones, y por ende la satisfacción de sus usuarios, aumentaría.

Estas problemáticas o situaciones a las que nuestros clientes se enfrentan a diario, es lo que nosotros planteamos como escenarios ALM, es decir, situaciones comunes y recurrentes en buena parte de nuestros clientes, como la gestión de proyectos o equipos de desarrollo heterogéneo o multiplataforma, la gestión de equipos o proyectos de desarrollo con equipos geográficamente dispersos, el aseguramiento de la calidad en los desarrollos, entre otros, que  gracias a las soluciones de desarrollo de Visual Studio podrían solventarse o mejorarse.

Uno de esos escenarios, y probablemente, uno de los más importantes es ALM como proceso crítico de negocio. Pero, ¿por qué el ALM es un proceso crítico de negocio?

Hoy en día, es un hecho aceptado que una empresa debe estructurar su funcionamiento sobre un conjunto de procesos de negocio que son los que harán latir su corazón. Si partimos de la definición del concepto “proceso de negocio" como: conjunto de tareas relacionadas, lógicamente llevadas a cabo para obtener un resultado de negocio definido, podemos inferir entonces cuáles serán sus principales características:

1. Deben ser medibles y estar orientadas al rendimiento.
2. Deberán producir resultados específicos.
3. Aportarán valor a los clientes de la organización o a los promotores.
4. Responderán a alguna acción o evento determinado.
5. Las actividades que los componen deberán agregar valor a los elementos de entrada al proceso.

Como vemos, los procesos de negocio buscan ante todo producir beneficios concretos, predecibles y de la mejor manera posible. Por ello es tan importante para una organización que desea mejorar su rendimiento, mejorar sus procesos de negocio, haciéndolos repetibles, eficientes y eficaces.

Para que un proceso de negocio ayude a contribuir al éxito empresarial se requiere, ante todo, que dicho proceso esté definido correctamente, y una vez definido, que sea implantado y adoptado por la organización en el menor tiempo posible y con el menor esfuerzo. Imaginemos un proceso de negocio innovador pero que no llega a todos los niveles de la empresa implicados, y que además el coste de implantación del mismo es desorbitado. Claramente, dicho proceso de negocio, que podría hacer más competitiva a una organización, estaría abocado al fracaso.

Es aquí donde los sistemas software pueden ayudar a que dicha implantación sea exitosa. Como se puede leer en el artículo de David Chappell (https://www.davidchappell.com/writing/white_papers/ALM_as_a_Business_Process_v2.0--Chappell.pdf), en 2008 la publicación Harvard Review, publicó un artículo escrito por Andrew McAfee y Erick Brynjolfsson, en el que se indicaba que gracias a la facilidad con que un sistema software puede ser desplegado completamente dentro de una organización, y como un proceso soportado por un sistema software puede tener garantías de que es debidamente utilizado y seguido por los miembros de la organización, los procesos de negocio soportados por sistemas software serán más fácilmente implantables y más fácilmente medibles, optimizables y repetibles.

Hasta aquí, podemos ver cómo los sistemas software o las aplicaciones de línea de negocio ayudan a soportar los procesos de negocio de nuestra organización.

Procesos de negocio diferenciales

Ahora bien, puesto que los procesos de negocio serán los que hagan que nuestra organización funcione adecuadamente, ¿cómo pueden hacer esos procesos de negocio que seamos más competitivos? Evidentemente, si se desea que nuestra empresa sea competitiva, sus procesos de negocio deberán ser diferenciales respecto a los de nuestra competencia y proporcionar una ventaja competitiva siendo modificables y adaptables a las necesidades de nuestra organización y de su entorno. Y es, por tanto, el desarrollo software una pieza vital para el funcionamiento de nuestra organización. En conclusión, el proceso de desarrollo software dentro de nuestra organización pasa a ser también por sí mismo un proceso crítico de nuestro negocio.

¿Por qué ALM con Microsoft Visual Studio?

Hasta este punto, hemos visto por qué tenemos que dotar a nuestro proceso de gestión del ciclo de vida del desarrollo (ALM) de la importancia que realmente tiene. Y si el proceso ALM es vital para nuestro negocio, hemos de  contemplarlo de la misma manera que otros procesos de negocio, es decir, debemos pedirle que sea definido, medible, optimizable y repetible.

La solución ALM ofrecida por Visual Studio permite contemplar el proceso del desarrollo de los sistemas software de una manera completa, de extremo a extremo, dotando a los participantes de un conjunto adecuado de herramientas en función de su rol, y con las que estén familiarizados, reduciendo la curva de aprendizaje y permitiéndoles ser más productivos, reduciendo el lastre de las tareas burocráticas y eliminando el sobrecoste que supone el cambio de contexto de una tarea a otra en sus asignaciones de trabajo.

Igualmente, Visual Studio permite dar soporte a cualquier proceso ALM independientemente de su trasfondo metodológico. Las plantillas de proceso que Microsoft Visual Studio Team Foundation Server ofrece son variadas (desde CMMi hasta Agile o Scrum) y además dichas plantillas de proceso pueden ser modificadas y adaptadas a las necesidades concretas de la organización. Incluso es posible diseñar y construir una plantilla de proceso desde cero con las herramientas incluidas dentro de Visual Studio. Por tanto, podemos hacer nuestro proceso de negocio ALM todo lo diferencial que nuestra organización precise en cada momento y en cada proyecto.

También, la necesidad de adaptar los procesos de desarrollo a las necesidades cambiantes del negocio  y la preocupación por la generación de valor en los proyectos software han hecho, en los últimos años, que las metodologías denominadas “ágiles” estén teniendo gran seguimiento.

En el análisis realizado por Forrester/Dr.Dobb’s, ya en 2009, se indicaba que a nivel mundial, el 35% de los proyectos software están siendo guiados por metodologías ágiles, siendo la primera posición del ranking. Como curiosidad, la segunda posición, con un 30,6% son proyectos que no siguen ningún tipo específico de proceso o metodología, y luego estarían el resto de tipos de proceso como los modelos iterativos (RUP, Spiral) y por último los modelos en cascada (CMMI, ISO9000, etc.). La cuestión es que los equipos de desarrollo ágiles no se integran muy bien tal cual con los modelos de gestión y seguimiento de proyectos actuales.

Visual Studio permite, mediante su integración out-of-the-box con Microsoft Project server, que los equipos ágiles puedan seguir sus procesos y que, al mismo tiempo y sin necesidad de esfuerzo adicional, nuestra Oficina de Gestión de la Demanda tenga la información actualizada del progreso y el consumo de recursos de dichos proyectos. De igual forma, la integración permitirá que los cambios en las planificaciones de los proyectos sean comunicados a los equipos ágiles de forma natural y efectiva.

Visual Studio permite aprovechar toda la tecnología y los sistemas software proporcionados por Microsoft (SQL Server, SharePoint, MS Project y Project Server, e incluso Azure) para dotar a nuestro proceso ALM de los beneficios de estar soportado por sistemas software robustos, eficientes y de última generación. Aún más, con Visual Studio podemos integrar dentro de nuestro proceso ALM sistemas software y tecnologías de otros fabricantes del mercado de una manera sencilla y eficaz.

En conclusión, si nuestra organización precisa de procesos de negocio que le ayuden a competir, estos deben estar en sistemas software que deben ser diferenciales mediante el desarrollo ad-hoc, y para ello la adopción de un proceso de gestión del desarrollo software soportado por la última tecnología software es primordial. Visual Studio ofrece una de las mejores soluciones de gestión del ciclo de vida del desarrollo software del mercado actual y nos ayudará a mejorar la competitividad de nuestra organización.

En este articulo veremos cómo el proceso de gestión del ciclo de vida del desarrollo de las aplicaciones, en especial aquellas de índole empresarial, deberá ser considerado por los directivos de las organizaciones, como un proceso de negocio vital para el correcto funcionamiento de sus empresas, y cómo la solución ALM que proporciona Visual Studio es la mejor opción para garantizar que ese proceso crítico de negocio cuenta con la mejor base tecnológica posible.

¿Por qué el ALM es un proceso crítico de negocio?

Hoy en día, es un hecho ampliamente aceptado que una empresa u organización debe estructurar su funcionamiento sobre un conjunto de procesos de negocio que son los que harán latir el corazón de dicha organizacion.

Si partimos de la definición del termino "proceso de negocio" como:

"Conjunto de tareas relacionadas lógicamente llevadas a cabo para obtener un resultado de negocio definido"

podemos inferir entonces cuales serán sus principales características:

1. Deben ser medibles y estar orientados al rendimiento
2. Deberán producir resultados específicos
3. Aportarán valor a los clientes de la organización o a los promotores 
4. Responderán a alguna acción o evento determinado
5. Las actividades que los componen deberán agregar valor a los elementos de entrada al proceso

Como vemos, los procesos de negocio buscan ante todo producir beneficios concretos, predecibles y de la mejor manera posible. Por ello es tan importante para una organización, que desea mejorar su rendimiento, mejorar sus procesos de negocio, haciéndolos repetibles, eficientes y eficaces.

Fundamentalmente para que un proceso de negocio ayude a contribuir al éxito empresarial se requiere ante todo que dicho proceso esté definido correctamente, y una vez definido, que sea implantado y adoptado por la organización en el menor tiempo posible y con el menor esfuerzo. Imaginemos un proceso de negocio innovador pero que no llega a todos los niveles de la empresa implicados, y que además el coste de implantación del mismo es desorbitado. Claramente, dicho proceso de negocio, que podría hacer más competitiva a una organizacion, estaría abocado al fracaso.

Es aquí donde los sistemas "software" pueden ayudar a que dicha implantación sea exitosa. Como se puede leer en el articulo de David Chappell, en 2008 la publicación Harvard Business Review, publicó un articulo escrito por Andrew McAfee y Erick Brynjolfsson, en el que se indicaba que gracias a la facilidad con que un sistema software puede ser desplegado completamente dentro de una organización, y gracias a como un proceso soportado por un sistema software puede tener garantias de que es debidamente utilizado y seguido por los miembros de la organización, los procesos de negocio soportados por sistemas software serán más facilmente implantables de manera completa en la organización y serán también fácilmente medibles, optimizables y repetibles.

Hasta aquí, podemos ver como los sistemas software o las aplicaciones de línea de negocio ayudan a soportar los procesos de negocio de nuestra organización.

Ahora bien, puesto que los procesos de negocio serán los que hagan que nuestra organización funcione adecuadamente, ¿cómo pueden hacer esos procesos de negocio que seamos más competitivos?. Evidentemente, si se desea que nuestra empresa sea competitiva, y que gane terreno dentro del mercado en el que se encuentran nuestros competidores, sus procesos de negocio deberán ser diferenciales respecto a los de nuestra competencia. Dicho de otro modo, si esos procesos de negocio son los mismos que los de loscompetidores, ¿cómo hacer para competir con ellos?. La solución está en hacer que los procesos de negocio se diferencien con respecto a los de la competencia.

Si nuestros procesos de negocio son idénticos a los de la competencia porque nuestra organización los soporta con el mismo sistema software comercial que nuestros competidores también han adquirido, no tendremos la ventaja competitiva que necesitamos. Es por ello que nuestros sistemas software deben permitir esa ventaja competitiva siendo modificables y adaptables a las necesidades de nuestra organización y de su entorno.Y es, por tanto, el desarrollo software una pieza vital para el funcionamiento de nuestra organización. En conclusión, el proceso de desarrollo software dentro de nuestra organización pasa a ser también por sí mismo un proceso crítico de nuestro negocio.

¿Por qué ALM con Microsoft Visual Studio?

Hasta este punto, vemos porque tenemos que dotar a nuestro proceso de gestión del ciclo de vida del desarrollo (ALM) de la importancia que realmente tiene. Y si el proceso ALM es vital para nuestro negocio, hemos de  contemplarlo de la misma manera que otros procesos de negocio, es decír, debemos pedirle que sea definido, medible, optimizable y repetible. Y es aquí donde debemos implantar dicho proceso sobre un sistema software que le permita disfrutar de dichas posibilidades.

La solución ALM ofrecida por Visual Studio permite contemplar el proceso del desarrollo de los sistemas software de una manera completa, de extremo a extremo del proceso, dotando a los participantes en dicho proceso de un conjunto adecuado de herramientas en función de su rol, y con las que estén familiarizados, reduciendo la curva de aprendizaje y permitiéndoles ser más productivos, reduciendo el lastre de las tareas burocráticas y eliminando el sobrecoste que supone el cambio de contexto de una tarea a otra en sus asignaciones de trabajo.

Igualmente, Visual Studio permite dar soporte a cualquier proceso ALM independientemente de su trasfondo metodológico. Las plantillas de proceso que Microsoft Visual Studio Team Foundation Server ofrece son variadas (desde CMMi hasta Agile o Scrum) y además dichas plantillas de proceso pueden ser modificadas y adaptadas a las necesidades concretas de la organización. Incluso es posible diseñar y construir una plantilla de proceso desde cero con las herramientas incluidas dentro de Visual Studio. Por tanto, podemos hacer nuestro proceso de negocio ALM todo lo diferencial que nuestra organización precise en cada momento y en cada proyecto.

También, la necesidad de adaptar los procesos de desarrollo a las necesidades cambiantes del negocio y la preocupación por la generación de valor en los proyectos software han hecho, en los últimos años, que las metodologías denominadas “agiles” estén teniendo gran seguimiento.

En el análisis Global Developer Technographics Survey realizado por Forrester/Dr.Dobb’s, ya en 2009, se indicaba que a nivel mundial, el 35% de los proyectos software están siendo guiados por metodologías ágiles, siendo la primera posición del ranking. Como curiosidad, la segunda posición, con un 30,6% son proyectos que no siguen ningún tipo específico de proceso o metodología, y luego estarían el resto de tipos de proceso como los modelos iterativos (RUP, Spiral) y por último los modelos en cascada (CMMI, ISO9000, etc.). La cuestión es que los equipos de desarrollo ágiles no se integran muy bien tal cual con los modelos de gestión y seguimiento de proyectos actuales. Visual Studio permite, mediante su integración out-of-the-box con Microsoft Project Server, que los equipos ágiles puedan seguir sus procesos y que al mismo tiempo y sin necesidad de esfuerzo adicional, nuestra Oficina de Gestión de la Demanda tenga la información actualizada del progreso y el consumo de recursos de dichos proyectos. De igual manera, la integración permitirá que los cambios en las planificaciones “formales” de los proyectos les sean comunicadas a los equipos ágiles de una forma que les sea natural y efectiva.

Visual Studio permite aprovechar toda la tecnología y los sistemas software proporcionados por Microsoft (SQL Server, SharePoint, MS Project y Project Server, e incluso Azure) para dotar a nuestro proceso ALM de los beneficios de estar soportado por sistemas software robustos, eficientes y de última generación. Aún más, con Visual Studio podemos integrar dentro de nuestro proceso ALM sistemas software y tecnologías proporcionadas por otros fabricantes del mercado de una manera sencilla y eficaz.

Conclusión

Si nuestra organización precisa de procesos de negocio que le ayuden a competir, éstos deben estar en sistemas software que deben ser diferenciales mediante el desarrollo ad-hoc, y para ello la adopción de un proceso de gestión del desarrollo software soportado asimismo por la última tecnología software es primordial. Visual Studio ofrece una de las mejores soluciones de gestión del ciclo de vida del desarrollo software del mercado actual y nos ayudará a mejorar la competitividad de nuestra organización.

Todo lo que nos rodea, de alguna manera, está relacionado con uno o varios componentes software. Nuestro teléfono móvil, nuestro portátil o el PC de nuestro puesto de trabajo, los aparatos que utilizamos para nuestro ocio diario (consolas, reproductores de vídeo o música, etc.). Todo ello, en algún momento, depende de aplicaciones o servicios construidos gracias al software.

Pero, también es curioso como ante esta época dorada del software, con sus grandes avances y su espléndido horizonte, algunas cuestiones siguen ancladas en el pasado. Una de ellas es, por ejemplo, como se sigue contemplando al desarrollo software como una artesanía o en el mejor de los casos como una maestría. Y a menudo son personas con un tremendo bagage técnico las que siguen viendo así las cosas. Cuantas veces algunos de nosotros hemos hablado con responsables de equipos de desarrollo, o con directivos de departamentos de I+D+i que siguen creyendo que el desarrollo del software que su organización precisa para funcionar y competir en el entorno actual es un conjunto de tareas desempeñadas por equipos de personas que suponen empresarialmente un mero coste para la organización y no una inversión. Que esos equipos de desarrollo no precisan organización, ni herramientas, ni procesos porque son perfiles creativos y no técnicos. Que la inversión en herramientas y procesos para gestionar el desarrollo software no tiene una razón clara para ser tenida en cuenta dentro de sus planes tácticos o estratégicos. Llegando incluso más lejos, que las herramientas con las que esos equipos efectuan su labor son "commodities" y que da lo mismo una que otra, si total desarrollar software es un proceso de escribir código, y para escribir código incluso con el Vi o el Emacs (mis recuerdos a los editores de código en los que más tiempo he pasado durante mi trayectoria como desarrollador) se puede hacer.

En parte, esta visión que a muchos parecería de otras décadas, está causada por cómo se posiciona todo lo relativo al desarrollo software. Es decir, desde de un punto de vista de marketing de producto, o desde un punto de vista comercial, se comercializan las herramientas de desarrollo o se presentan los modelos de gestión del desarrollo, de la misma manera a cómo se vendían los automóviles hace 4 ó 5 décadas, o a como se ofertaban los primeros ordenadores personales de hace 3 décadas. La oferta se centra excesivamente en las características del producto: "Equipe a sus equipos de desarrollo con la solución X porque podrán utilizar la característica Y, la Z o la W". ¿No recuerda esto a los spots de televisión de automóviles o lavadoras de la de la época?. ¿Cuánto ha cambiado el marketing y la publicidad de esos productos desde entonces?. En la actualidad esos productos se ofertan comunicando a los potenciales compradores los beneficios que supondrán para ellos en cuestiones como fiabilidad, seguridad, comodidad, etc. Incluso últimamente lo que se intenta es asociar esos productos con determinadas sensaciones o sentimientos que puedan resultar atractivos a los usuarios (baste como ejemplo las campañas de marketing de BMW de los últimos años por poner un único ejemplo).

Pensando sobre todo esto, surgió la idea de intentar posicionar el desarrollo software y las herramientas de desarrollo de Visual Studio de una manera similar, para de esta manera intentar comunicar o posicionar mejor la oferta de esos productos. Vaya por delante que no pretendermos ofertar Visual Studio a nuestros potenciales compradores con aquello de: "¿Te gusta desarrollar?" que decían los spots de BMW, pero si que intentamos salir de la mera oferta técnica o centrada en las características del producto o la solución, para ampliar un poco el enfoque y hacer ver a nuestros potenciales compradores que la compra de soluciones de ALM debía estar fundamentada por cuestiones que resultarían más cercanas a sus necesidades o problemáticas. Posicionar una solución ALM como Visual Studio centrándonos en las características no es tan efectivo como posicionarla indicándole a los potenciales clientes cómo con ella podrían solucionar problemas como la productividad de sus equipos de desarrollo, o el nivel de gestión y seguimiento que podrían tener sus proyectos, o cómo la calidad de sus aplicaciones, y por ende la satisfacción de sus usuarios, aumentaría.

Estas problemáticas o situaciones a las que nuestros clientes o usuarios se enfrentan día a día, es lo que hemos venido a plantear como "Escenarios ALM". Es decir, situaciones que entendemos son comunes en el día a día de nuestros clientes, y que gracias a las soluciones de desarrollo de Visual Studio podrían solucionarse o mejorarse. Evidentemente, cada organización o equipo es único y las problemáticas de cada uno no tienen porqué coincidir con las de otros, pero si que es cierto, después de conocer un poco el sector, que los escenarios tipo no son demasiados.

Por todo esto, creo que sería interesante escribir en este blog, una serie de posts o artículos en los que presentar esos escenarios y también cómo Visual Studio podría ayudar a solucionarlos o mitigarlos.

En una primera aproximación, la lista de escenarios relativos al desarrollo software podría ser esta:

ALM como Proceso Crítico de Negocio

Habitualmente estamos acostumbrados a oir cómo las organizaciones gestionan y mejoran sus procesos de negocio. También es habitual o incluso obligatorio que dichos procesos están soportados por complejos y costosos sistemas de software. Seguro que una organización moderna dispone de recursos económicos y productivos para procesos como la gestión de clientes, el calculo de nóminas, el control financiero contable, y así hasta una extensa lista de sistemas software que dan soporte a los procesos de negocio. Lo que es menos habitual es que esas mismas empresas no vean la necesidad de gestionar adecuadamente sus proyectos de desarrollo software o si lo hacen, que no contemplen al proceso de desarrollar y mantener sus sistemas software como un proceso de negocio más y que debería ser considerado al menos tan crítico como otros procesos dentro de la organización. Si el software forma parte intrínseca de sus procesos críticos de negocio, ¿por qué el proceso de gestión de los proyectos software no es a su vez un proceso crítico?

Gestión de Proyectos o Equipos de Desarrollo Heterogéneo o Multiplataforma

En el panorama actual con una amplia oferta de tecnologías y fabricantes es frecuente que las organizaciones tengan equipos de desarrollo que trabajen desarrollando aplicaciones para diferentes plataformas (.NET, Java, COBOL, etc.). Normalmente esta "dispersion tecnológica" hace que los diferentes equipos y proyectos utilicen modelos de gestión del ciclo de vída diferentes y también sus propias herramientas que los soporten. Todo esto hace que se produzcan ineficiencias en el trabajo de los diferentes equipos, que se incrementen los costes de gestión y soporte de los diferentes sistemas ALM, que no exista un proceso o procesos ALM unificados y controlados por la organización, y en general otros problemas que afectarán negativamente a la organización. Visual Studio y su soporte multiplataforma para la gestión del ciclo de vida del desarrollo puede ayudar a establecer y definir un proceso ALM unificado que permita detectar y eliminar las deficiencias en esos procesos, reduzca los recursos necesarios para gestionar dichos procesos y fomente la colaboración entre diferentes equipos de desarrollo especializados.

Gestión de Equipos o Proyectos de Desarrollo con Equipos Geográficamente Dispersos

Muchas organizaciones se ven enfrentadas a escenarios en los que sus equipos de desarrollo están ubicados en diversas localidades geograficamente separadas. También puede ocurrir que en una organización los perfiles de gestión de proyectos estén en las oficinas centrales de la multinacional y los equipos de desarrollo estén otras ubicaciones donde las condiciones economico-financieras de la zona sean más ventajosas ("off-shoring"). Estos casos y otroso similares pueden ser fácilmente resueltos con Visual Studio, de manera que los proyectos de desarrollo no se vean afectados de manera negativa y puedan aprovechar las ventajas de modelos como "off-shoring" o "outsourcing" sin necesidad de afrontar tareas de gestión adicionales al trabajo habitual.

Aseguramiento de la Calidad en los Desarrollos Software

Hoy en día es importante poder garantizar que nuestros proyectos de desarrollo no solo cumplen los objetivos de tiempo y recursos, si no que además es fundamental garantizar en todo momento que el sistema o la aplicación cumple los requisitos demandados por los usuarios finales, y además también cumple los estándares de calidad técnica que se definen para el proyecto en cuestión o para toda la organización. Un proceso moderno de gestión del desarrollo software debe ser capaz de garantizar la máxima calidad dentro de todas las fases y tareas que lo componen, y también, los equipos de desarrollo deben de contar con las herramientas adecuadas que les permitan construir aplicaciones de calidad.

Gestión Empresarial de Proyectos de Desarrollo

En las organizaciones actuales, desde hace varias décadas, existe una cultura arraigada de gestión de proyectos. Las empresas valoran y seleccionan sus proyectos utilizando técnicas y herramientas avanzadas como Gestión de Portfolio de Proyectos (PPM), Gestión Empresarial de Proyectos (EPM) o utilizan Sistemas de Información para la Gestión Ejecutiva (EIS). Dentro del mundo del desarrollo software, la información del seguimiento y avance de los proyectos debe alimentar los sistemas avanzados de planificación empresarial, lo cual de manera casi constante supone una carga de trabajo adicional a los equipos de desarrollo. ¿Cómo se puede hacer compatible que los equipos de desarrollo se dediquen exclusivamente a lo que mejor saben hacer - desarrollar software - mientras que se sigue suministrando de vital información a los sistemas de gestión empresarial de la organización?. Es sencillo si se cuenta con un proceso de gestión del desarrollo adecuado y que a su vez esté soportado por herramientas, como las que ofrece Visual Studio,  que faciliten el flujo de información con el mínimo esfuerzo.

Administración de la Propiedad Intelectual en Proyectos de Desarrollo

Las organizaciones actuales gestionan cada vez más activos intangiles como patentes, marcas, contratos, etc. Lamentablemente, también es habitual que uno de sus activos intangibles más importantes como puede ser la propiedad intelectual de sus proyectos de desarrollo no esté contemplado dentro de esa gestión de activos, especialmente si los proyectos de desarrollo son externalizados a proveedores externos especializados que normalmente se limitan a entregar los resultados finales del proyecto, dejando aparte elementos críticos como la documentación del proyecto, los entregables intermedios o incluso algo tan vital para el contratista como es el código fuente. Un proceso de gestión del ciclo de vida de las aplicaciones debe ayudar a las organizaciones clientes a poder gestionar, con el minimo esfuerzo, esos intangibles que le permitirán poder afrontar por si mismas el mantenimiento y evolución de las aplicaciones o sistemas contratados.

Aseguramiento del Rendimiento y Escalabilidad en Aplicaciones o Servicios

En este panorama actual de mercados altamente competitivos y con ciclos de desarrollo de productos y servicios cada vez más cortos, los costes asociados a la mal rendimiento de nuestras aplicaciones pueden ser elevados. Además, dichos costes a menudo pueden ser difíciles de cuantificar puesto que impactan sobre activos intangibles como la imagen de marca o la productividad de la plantilla de la organización. Ahora que vivimos en una sociedad altamente conectada y que hace uso extensivo de servicios en línea gracias a internet, es mandatorio que las organizaciones puedan asegurar el correcto funcionamiento de sus servicios y aplicaciones independientemente de los volúmenes de peticiones realizadas por los clientes finales o los empleados de las misma. Una vez más, los proceso e gestión del ciclo de vida de las aplicaciones implantados dentro de las organizaciones deben ayudar a que el rendimiento de las aplicaciones esté de alguna manera garantizado y que esas mismas aplicación o servicios reaccionen de manera flexible a picos de demanda por parte de los clientes o usuarios finales.

Como se suele decir: "están todos los que son, pero no son todos los que están". Habrá organizaciones que se enfrenten a escenarios o situaciones adicionales a estas, o a mezclas de varias de las de la lista. Si ese es el caso, mi contacto está a disposición de los interesados para que comentar sobre el tema y tratar de encontrar la mejor forma de enfrentarse a ellos con las solución de ALM de Microsoft Visual Studio.