ALM

(Application lifecycle
management)

http://www.visualstudio.com/get-
started/overview-of-get-started-tasks-vs
Disciplinas y Problemáticas
La única equivocación de software
más cara que un error o bug de
software es el desarrollo de un
software incorrecto.

Shelf-ware => Software incorrecto

que se queda en el estante sin
utilizar.
¿Pero… qué es ALM?
Es una Metodología de Administración y Gestión de las Aplicaciones
desde que se conciben y porque se conciben.
Además de ser una bonita Plataforma de administración
también nos permite identificar cuales son las áreas de
oportunidad en el equipo de trabajo y como podemos solventarlas.
ALM busca responder problemáticas
como:
• Como se levanta un requerimiento.
• Como se gestionan los requerimientos.
• Como se estima el proyecto.
• Como se asignan los miembros del equipo.
• Cuanto nos esta costando y cuando es el retorno de la inversión que
se pretende.
• Como se desarrolla, se prueba y se sale a producción.
• Como se mantienen las nuevas versiones mediante un Control de
Versiones.
• Como se aplica una metodología para el control de ramas (Desarrollo,
Aseguramiento de la Calidad, Producción).
• Como se aplica una trazabilidad a todos los requerimientos.
• Cuanto se va a desviar un proyecto si se cambia un requerimiento.
• Como se gestiona la colaboración entre los usuarios.
• Como se administra el seguimiento de los proyectos.
• Como se le da mantenimiento al Software.
• Como determinar la Capacidad de líneas de Código de cada
desarrollador (Muchas generalmente representan un Bug).

Gobernabilidad al interior
de la Organización
 Gobernabilidad => Mayor Control y
Predictibilidad (Calidad de Vida)
En definitiva nos permite controlar los activos de la Organización para
aprovecharlos de la mejor manera.
Para que de una manera muy eficaz nos enfoquemos en:
• La Planeación y Gestión de Proyectos.
• Almacenamiento y Procesamiento en la Nube.
• Integración continua:
Deployment del trabajo en equipo en distintos ambientes para la colaboración.
Builds automatizados que detectan cambios en el código y disparan una serie de
acciones al compilar el código (Ejecutar pruebas unitarias y análisis de código).
• Disciplinas y problemáticas.
• Esfuerzo del equipo.
• Gestión de requerimientos y tareas para generar un plan de proyecto.
• Versionar el Código.
• Practicas modernas de la Industria del Desarrollo de Software.
• Disponibilidad de los Servicios.
• Diseño Conceptual para una buena experiencia de usuario.
• Gestión de la Calidad y entregables del Proyecto.
• Priorizar a lo que entrega valor.
• Un Plan de trabajo a seguir:
Fechas, Recursos, Tareas por Etapas (Iteraciones o Ciclos que avanzan el
proyecto con menor carga de trabajo, Incrementos).
• Pruebas de Concepto (Feedback).
• Automatización según Estándares.
• Entregables y avances en función del valor.
 Team Foundation Server
Es un conjunto de funcionalidades que nos permite de una manera
muy ágil, sencilla y versátil poder hacer un mejor aprovechamiento de:
• Control de Versiones (código y base de datos).
• Implementar una metodología de Desarrollo.
• Integrar a los Usuarios Finales mediante casos de uso (Power Point y
Excel).
• Funciona para cualquier plataforma de desarrollo (.Net, Java, Oracle)
teniendo un repositorio central de la información.
• Tener documentación mediante la metodología de desarrollo que se
requiera.
• Agilidad del Equipo de Trabajo.
 Metodologías Ágiles - SCRUM

Más info. de SCRUM => http://hostarting.es/blog/wp-content/uploads/2013/02/mm1_scrum_poster_web.png

* Organizar el trabajo => Desarrollo iterativo e incremental en Función del Valor
 Manos a la Obra!
Web Access

Falta Información
del Proyecto Chat del Grupo, Eventos Estimación y Planificación de
un Proyecto
Indica la Capacidad del equipo
Elementos de trabajo según la
metodología => Generar
planeación en TFS para gestionar
y tener trazabilidad del Proyecto.
Gestionar los requerimientos.

Visualizar el Avance del Proyecto (Se puede personalizar para el Método de trabajo)
 Configuración del Proyecto
Determinar las Áreas de los
requerimientos que se van a
Gestionar
En Scrum no más de 9 miembros deberían de participar.
Determinar los Ciclos de Desarrollo
En Metodologías Ágiles los Sprints son procesos de 2, 3 ó 4
Semanas para medir riesgos mínimos. Deberían poder
entregar un producto funcional para recibir un Feedback.
Aquí seleccionamos el Backlog de iteración, los hijos serán las
iteraciones y las habilitamos para poder visualizarlas en la
zona de planeación.
 Features => Funcionalidades dentro de mi
aplicación

Arrastrar y Soltar nuestros elementos de trabajo Identificamos nuestro tablero según

para cambiarles la prioridad en TFS. la metodología, por ejemplo en
SCRUM sería el Scrum Task Board.

* Desde aquí creamos nuestros futuros Backlogs para vincular nuestros elementos de trabajo, una funcionalidad con
historias de Usuario.
 Backlog Items => Historias de usuarios,
requerimientos
Límite de la cantidad de trabajo que
el equipo pueda tener en curso
(Este se puede modificar).
Indicamos el valor para determinar el
esfuerzo (No tiene que ser en horas).

Requerimientos cortos obtenidos con el Cliente, puede que haya que analizar alguno pero
generalmente se capturan de manera rápida. La valoración (el esfuerzo) puede ser cualquier medida
determinada por nosotros mismos, un ejemplo sería “1, 2, 4, 8, …” para que se entienda que un
Backlog puede ser el doble de complejo que otro.
 Tasks => Agregamos las tareas a
nuestros Backlogs
Según el requerimiento se definen las tareas, con descripción
y tiempo para ser asignadas a los miembros del equipo.
(Por cada requerimiento se aconseja al menos un caso de
prueba)

Nuestras tareas deben de tener su

duración y en conjunto estas
determinarán si se cumple el tiempo
de nuestro Sprint, y por lo tanto nos
muestra la carga de trabajo a cada
miembro del equipo asignado.
 Queries => Creamos nuestras
consultas
Diseñamos nuestros gráficos estadísticos del avance
del proyecto como por ejemplo la cantidad de
Características, Requerimientos y Funcionalidades
además de muchas otras más opciones.

Podemos establecer nuestros Queries y copiar los datos

a un Excel por ejemplo, mandarlos por Email, cambiar el
miembro asignado del elemento de trabajo, cambiarlos
de iteración, etc.
 PowerPoint Storyboarding => Capturar
requerimientos del negocio de forma precisa
Licencia de acceso a cliente (CAL) => un
usuario ve o modifica un elemento de trabajo
creado por otro usuario o interactúa con
Team Foundation Server de cualquier otra
manera. (Costoso de obtener para cada
cliente).
No se necesita una CAL para crear elementos
de trabajo o actualizar elementos de trabajo
que el mismo usuario ha creado (Excepción
que solo aplica a elementos de trabajo
relacionados al registro de mejoras o
defectos).
Usuarios agregados a un
grupo con permiso de Work
Item Only View.
Se guarda el archivo en un recurso de red o en una biblioteca de
documentos de Sharepoint para vincular el Storyboarding a algún EJEMPLO => http://1drv.ms/1buTbj9
elemento de trabajo en TFS.
 Microsoft Feedback Client =>
Capturando la realimentación de los
Stakeholders
Por cada solicitud de retroalimentación se puede generar un
elemento de trabajo en TFS, permitiendo realizar un
seguimiento.

Feeback Client no requiere una licencia de acceso de cliente

de TFS (es Gratis), pero los usuarios deben tener los permisos
necesarios para la instancia de Team Foundation Server, como
mínimo los usuarios deben ser miembros del grupo Work
Item Only View. No se necesita tener Visual Studio Instalado.
 Solicitar Feedback
Se proporcionan los elementos de
trabajo que se desean realimentar
En el HOME del Web con los comentarios que dará el
Access, Click en Stakeholder.
Request feedback

Se tiene un
máximo de hasta
5 elementos por
envió.

Ejemplo para abrir el Microsoft Feedback Client desde el correo

mfbclients://<cuenta>.visualstudio.com/DefaultCollection/p:<proyecto>?rid=<id>
 El usuario proporciona realimentación
voluntaria

Se crean nuevos
elementos de
trabajo del tipo
Feedback Response

Si la retroalimentación es por ejemplo

un Bug, una característica nueva… se
puede crear un nuevo elemento de
trabajo con respecto al existente,
permitiendo realizar una trazabilidad
para el desarrollador.
Si el cambio ya se ha realizado
se puede cambiar el estado de
la realimentación.
 Branching and Merging => Ramificar
nuestro Proyecto
Estrategias de
bifurcación:
• No bifurcación => Si no es
necesario, no se hace.
• Rama por Liberación =>
Múltiples versiones de
código en paralelo.
• Por promoción de Código =>
Largos ciclos de prueba, por
ejemplo la división de las
ramas para el nivel de
Desarrollo, Aseguramiento
de la Calidad y Producción.
• Por funcionalidad => Un
sistema muy grande por
Módulos. Las
funcionalidades tienen corta
duración y se integran con la
rama principal (código de
Oro) de forma regular.
Ejemplo:
Merge:
Combinar el código de 2 ramas en
un código base.
• Source => Rama origen.
• Target => Rama destino.
• Base Version => El Código
común original.
Conflicto:
Es un mismo archivo editado en 2
ramas distintas, si TFS puede
Repositorio solucionarlo realiza un Automerge
central y
de lo contrario debe ser manual.
ramificaciones: (Depende de la comunicación del
equipo).

Guía =>
http://vsarbranchingguide.codeplex.com/
Test Manager => Ejecutar Casos de
prueba

Podemos recuperar métricas de cobertura

de código.
 Herramientas que se integran con TFS
TeamSpec => Escribir los requerimientos
utilizando plantillas personalizables en
Microsoft Word o generar documentos a
partir de un elemento de trabajo de TFS.
TeamBox => crear automáticamente
elementos de trabajo de correos recibidos
a una dirección de correo electrónico
POP3

inteGREAT =>

TeamLook => Generar elementos de

trabajo a partir de correos electrónicos.