INSTITUTO TECNOLGICO SUPERIOR DE LA MONTAA

INGENIERA EN INFORMTICA
Octavo semestre
Asignatura:

Estrategias de gestin de servicios de TI

UNIDAD II
MARCOS DE REFERENCIA EN LA GESTIN DE SERVICIOS DE TI
(ASL Y SCRUM)

Docente:

M.T.I. Freddy Ramrez Villalobos

Alumno:
Emeterio Tiburcio Lpez
CRUPO: A

Tlapa de Comonfort, Guerrero, a 25 de mayo de 2016.

Qu es ASL?

ASL es una metodologa utilizada en la industria de TI, ya que ofrece un modelo de

referencia para la gestin de aplicaciones.
La Librera de Servicios de Aplicaciones es un estndar de dominio pblico, que
describe los procesos dentro de la administracin de aplicaciones. El trmino "Librera "
se utiliza porque el estndar ASL se basa en las descripciones de las mejores prcticas
de la industria.

Por qu el trmino Biblioteca?

Se utiliza el trmino biblioteca ya que ASL se presenta como un conjunto de
libros que describen las mejores prcticas de la TI en la industria. As como los
procesos en varios libros y artculos (la mayora de ellos en holands) y en la
pgina web oficial de la Fundacin ASL BiSL, existen publicaciones sobre el
modelo de proceso y un gran nmero de las mejores prcticas, libros blancos,
artculos y presentaciones.

Antecedentes
Fue desarrollado a finales de los aos noventa en los Pases Bajos, originalmente era la
metodologa de gestin de TI de la Empresa Roccade, conocida como R2C (Regulation,
Control and Continuity), que evolucion en ASL en 2000. En 2001 fue donado por el
Proveedor de Servicios de TI PinkRoccade a la Fundacin ASL, ahora la Fundacin
ASL BiSL.
El estndar fue desarrollado debido a la incapacidad para estructurar la forma de
trabajar dentro de las reas de administracin de aplicaciones que slo utilizaban el
ITIL, que fue muy til en la gestin de la infraestructura, pero careca de una orientacin
especfica para el diseo de aplicaciones, desarrollo, mantenimiento y soporte. ASL es
un marco que acompaa a ITIL. Los miembros de la junta directiva de ITIL tambin se
sientan en el consejo de ASL en el reconocimiento de que complementa el marco de
ITIL en el espacio de aplicacin.

El objetivo de ASL
es profesionalizar el campo de la gestin de aplicaciones, proporcionando las
herramientas necesarias. Las dos categoras principales de ayuda son:
La perspectiva de "apoyar los procesos de negocio usando los sistemas de
informacin
El ciclo de vida de los procesos de negocio".

1 Castellano, ASL|DTyOC.pdf (2016, p.12)

Estructura del ASL

Contiene seis grupos de procesos, tres en el nivel operativo, uno en el nivel
tctico y dos en el nivel estratgico.

1.- El nivel operativo contempla dos grupos de procesos:

Mantenimiento de aplicaciones: los procesos que aseguran la disponibilidad
ptima de las aplicaciones actuales que soportan los procesos de negocio con
un mnimo de recursos e interrupcin en la operacin.
Perfeccionamiento/renovacin de aplicaciones: los procesos que adaptan las
aplicaciones a nuevos requerimientos en respuesta a cambios de la organizacin
y el entorno. Se realizan los ajustes necesarios en el software, el modelo de
datos y la documentacin.

2.- El nivel tctico comprende todos los procesos de

gestin.
Estos procesos proporcionan a la direccin la posibilidad de gestin de los
mismos. Tanto el nivel estratgico como el operativo suministran la gestin de
procesos, de esta forma se aseguran realidad futura y cotidiana.

3.-El nivel estratgico

Tambin distingue dos tipos de procesos, basados en la subdivisin desde el "punto de
vista del servicio" y "punto de vista de aplicacin". Hoy en da los proveedores de
servicios deben ser flexibles, contemplando la posibilidad de cambiar este modelo y la
posibilidad de elegir a diferentes proveedores de servicio para cada rea sin riesgo de
prdida de control.
Gestin del Ciclo de Organizacin (OCM): los procesos enfocados al desarrollo
de una futura visin de la organizacin de servicio de IT, trasladando la visin a
una poltica de renovacin.
Gestin del Ciclo de Aplicaciones (ACM): los procesos que sirven para formar
una estrategia a largo plazo para las aplicaciones, alineada a las previsiones de
cambios organizativos a largo plazo.
_________________________________

Ton van Sante A.S.L. SEGUNDA GENERACION DE GESTION DE APLICACIONES (2006, p.7)

Beneficios para las personas

Reconocimiento como un practicante de gestin de la informacin empresarial

profesional cualificado.
Una mejor comprensin de los procesos que intervienen en la ejecucin de la

gestin de la informacin empresarial de las operaciones a la estrategia.

Ideas para mejorar la forma en que se ejecuta actualmente la gestin de la

informacin empresarial.
capacidad para cerrar la brecha entre la gestin de la informacin empresarial y
los dominios vecinos de desarrollo de aplicaciones, gestin de aplicaciones y
gestin de servicios de TI mejorada.

Beneficios para las organizaciones

Mejor informacin para los procesos de negocio y el uso ms eficaz de los

usuarios finales.

Una interaccin ms productiva con la funcin de TI.

Mejor retorno de sus inversiones en la provisin de informacin.

Menos sorpresas, como resultado de los cambios en la organizacin de usuarios,

procesos de negocio y el entorno de la organizacin.

La capacidad de demostrar que ellos son la gestin de la informacin como un

activo valioso.

2Castellano, ASL|DTyOC.pdf (2016, p.33)

SCRUM
Scrum es un marco de trabajo en el que equipos cross-funcionales pueden crear
productos o desarrollar proyectos de una forma iterativa e incremental. El desarrollo se
estructura en ciclos de trabajo llamados Sprints (tambin conocidos como iteraciones).
Estas iteraciones no deben durar ms de cuatro semanas cada una (siendo dos
semanas la duracin ms habitual) y tienen lugar una tras otra sin pausa entre ellas.
Medinilla (2012, p.3)

ANTECEDENTES
Aproximadamente en 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva
forma para el desarrollo productos comerciales, que incrementaba la rapidez y la
flexibilidad en el proceso. Ellos comparan este nuevo mtodo, en la cual las fases se
traslapan de manera intensa y el proceso completo es realizado por un equipo con
funciones diversas, como en el rugby, donde el equipo entero acta como un solo
hombre para intentar llegar al otro lado del campo, pasando el baln de uno a otro.
Estos casos de estudio se originan de las industrias automovilsticas, as como de
fabricacin de mquinas fotogrficas, computadoras e impresoras.
Principios de los aos noventa Ken Schwaber emple una aproximacin que lo llev a
poner en prctica el scrum en su compaa.
Finalmente, en 1995 Schwaber y Sutherland, durante la conferencia OOPSLA 95 en
Austin, Estados Unidos, presentaron en paralelo una serie de artculos describiendo
scrum, siendo sta la primera aparicin pblica de la metodologa. Despus ellos
siguieron aportando con su experiencia y escribieron una serie de artculos y ambos
colaboraron para sentar las bases de las mejores prcticas de la industria que hoy en
da se conoce como Scrum.
_________________________________
James, Michael (2010). SCRUM.
http://scrum-ing-software.blogspot.mx/.

Roles en Scrum
Scrum utiliza un elemento representativo: el sprint, que ingles significa carrera corta y
representa una etapa de trabajo. Y es as como los creadores de esta metodologa ven
a una etapa del desarrollo del software. Podemos compararla a la carrera por postas en
la que muchos corredores intervienen y en cada fase deben correr una distancia corta o
sprint. Esta analoga llevada a la creacin de un software, se convierte en una tcnica
muy dinmica y colaborativa y con muy buenos resultados en calidad y agilidad.
El Sprint es la unidad bsica de desarrollo en Scrum, usualmente va desde una
semana hasta un mes y est definida por una fecha de inicio y una fecha de fin.
Durante el Sprint los miembros del equipo deben cumplir las tareas y completarlas.
Normalmente un proyecto puede tener varios sprints.

En Scrum existen tres actores o roles principal:

El Dueo del Producto (Product Owner), representa a los inversionistas o las

personas que requieren el software.

El Director Scrum (Scrum Master), es el facilitador del equipo, supervisa al
equipo y verifica que se lleven a cabo las reuniones y se haga uso de los
artefactos. Ayuda a que el proyecto tenga xito. Elimina los problemas e
impedimentos que se pudieran presentar. Ayuda a los miembros del equipo a
tomar decisiones responsables y los asesora en todas las maneras posibles para

que alcancen sus objetivos.

Los miembros del equipo (Team Members), son los que desarrollan el
software, poseen las capacidades tcnicas para fabricar el producto.

Tambin se utilizan tres artefactos:

La Pila de Producto (Product BackLog), que es una lista de todas las

cosas Por Realizar del proyecto. Esta lista es confeccionada por el Dueo
del Producto de acuerdo a los requerimientos y esta ordenada por la
prioridad que tiene cada elemento en la pila. Es decir, de mayor a menor
importancia.

La Pila del Sprint (Sprint BackLog), son las actividades que se van a realizar

dentro de un sprint.
El Grafico de Trabajo Pendiente (Burndown Chart). Representa visualmente
el trabajo que est por hacer versus el tiempo restante del proyecto. El trabajo
pendiente se representa en el eje vertical y el tiempo en el eje horizontal. Es til
para predecir en que tiempo se terminara todo el trabajo, incluso se puede
establecer el ritmo de avance del proyecto del equipo.

Se definen tres reuniones que se deben realizar utilizando el mtodo

Scrum:

Planeacin del Sprint (Scrum Planning), con la ayuda del Product Owner y el
Scrum Master y el equipo, se compromete con las actividades que se deben
realizar de la Pila del Producto. Es decir, se seleccionan actividades prioritarias y
relacionadas y con la restriccin del tiempo existente, para que estas formen parte

de la siguiente iteracin (Sprint).

Reunin Diario de Scrum (Daily Scrum), esta actividad se lleva a cabo todos
los das y debe durar quince minutos o menos. Cada miembro del equipo debe
comunicar al resto del equipo y al Scrum Master, tres tems indicados en la Tabla
de Tareas: lo que se realiz, lo que se va realizar el da de hoy, y si existe algn
impedimento para llevar a cabo el trabajo. Cada tarea debe evolucionar desde Por
hacer (To Do), En Progreso (In Progress), Realizadas (Done). Al finalizar el sprint
todas las tareas deben estar realizadas. Esta reunin es muy importante porque
aqu los miembros comparten informacin, para determinar la mejor manera de
cumplir sus tareas y poder terminar con las metas del Sprint. Se manifiestan los
riesgos encontrados y es til porque permite que los miembros del equipo sean
ms eficaces.

Durante esta reunin el Scrum Master debe determinar los problemas e

identificar si estos se pudieran convertir en un impedimento para completar
el proyecto.

Revision del Sprint (Sprint Review). Al final del sprint se muestra a los clientes
y al Dueo del Producto lo que ha terminado el equipo. Es decir, el Producto
Terminado del Sprint- Los clientes proveen del feedback necesario y pueden
terminar o no la necesidad de otro Sprint para mejorar el producto. Esto ayuda a
crear el software con los requerimientos exactos del cliente y permite que el

equipo sea ms eficaz.

Retrospectiva del Sprint (Sprint Retrospectivo). Esta reunin tambin se lleva
al final del Sprint, y a diferencia de la Revisin del Sprint, sirve para mejorar al
equipo. Se evalan los aciertos y desaciertos del equipo en la realizacin de sus
tareas. Y se proveen tcnicas para reducir los errores, como pruebas de testing,
ayuda de logstica. Esto empodera al equipo para que sea exitoso, permitiendo
que mejoren en el siguiente Sprint.

Ventajas de Scrum:

El cliente puede comenzar a utilizar el producto rpidamente.

El cliente puede decidir los nuevos objetivos a realizar.

Se agila el proceso, porque se divide el problema en pequeas tareas.

Menos probabilidad de que se den sorpresas o desarrollos inesperados porque

el cliente va viendo poco a poco lo que se est desarrollando.

Desventajas de Scrum:

Existe la tendencia que si se deja una tarea sin terminar y que por las exigencias
del Dueo del Producto se deban realizar otras nuevas. Estas tareas no
terminadas puedan obstaculizar la planeacin de nuevas sprints y se deba volver

al problema original.
Alto nivel de stress de los miembros del equipo, el desgaste puede ser excesivo

y estresante lo que puede disminuir el rendimiento.

La necesidad de contar con equipos multidisciplinarios puede ser un problema,
porque cada integrante del equipo debe estar en capacidad de resolver cualquier
tarea y no siempre se cuenta con este perfil en la empresa.

El equipo puede estar tentado de tomar el camino ms corto para cumplir con un
sprint, que no necesariamente puede ser el de mejor calidad en el desarrollo del
producto.

Referencias bibliogrficas
1.-Luis Castellanos (2016) ASL_DTyOC.pdf.consultado en 05,03 2016.
https://dtyoc.com/2016/05/05/asl/.
2. Van Sante, Tom (2006). A.S.L. SEGUNDA GENERACION DE GESTION DE
APLICACIONES.
COMUNICACION.
Consultado
en
MAYO,25,2016
en
file:///C:/Users/eagle/Downloads/asl.pdf.
3.- Luis Castellanos (2016) ASL_DTyOC.pdf.consultado en 05,03 2016.
https://dtyoc.com/category/ano03/
4.-Medinilla, ngel (2012). SCRUM PRIMER. Consultado en mayo,25,2016 en
http://www.scrumprimer.org/primers/es_scrumprimer20.pdf.
5.-James, Michael (2010). SCRUM. Consultado en 05, 03,2016 en http://scrum-ingsoftware.blogspot.mx/.
6.-Trigas Gallego, Manuel (s. a). Metodologa Scrum. Consultado en mayo,25,2016 en
http://www.scrumprimer.org/primers/es_scrumprimer20.pdf.