Editorial Universidad Manuela Beltrán

Patrones, Estándares y Metodologías

para la Construcción de Software

2018
Patrones, Estándares y Metodologías
para la Construcción de Software

Autores
Miguel García Torres
Carlos Augusto Sánchez Martelo
Henry Leonardo Avendaño Delgado
Manuel Antonio Sierra Rodríguez
Carlos Andrés Collazos Morales
Domingo Alirio Montaño Arias
Breed Yeet Alfonso Corredor
José Daniel Rodríguez Munca
Edición Miembro comité editorial revista Journal of
Editorial Universidad Manuela Beltrán Science Educations. Miembro fundador de la
Sociedad Iberoamericana de Biología Evolutiva.

Autores

Miguel García Tirres Carlos Andres Collazos

Dr. En Ciencias de la Morales
Computación e Inteligencia Postdoctorado en Ciencia y
Artificial, Investigador Tecnología Avanzada, Dr. en
Postdoctoral en el Instituto Ciencias, Magister en
Nacional de Tecnica Ingeniería Electrónica y
Aeroespacial, Magíster en Computadores, Físico.
Informática, Físico.

Carlos Augusto Sanchez Breed Yeet Alfonso Corredor

Martelo Dr. (c) en Proyectos, Magister
Dr. (c) en Pensamiento en Educación, Especialista en
Complejo, Maestría en Diseño, Desarrollo e Implementación
Gestión y Dirección de de Herramientas Telemáticas,
Proyectos, Ingeniero de Ingeniera Electrónica,
sistemas, Certificado Directora Académica y
Internacionalmente en ITIL Foundation v3, Calidad, Consultora Nacional e Internacional
Procesos en Desarrollo de Software y TIC Académica de Educación Superior.

Henry Leonardo Avendaño José Daniel Rodríguez Munca

Delgado Magister en Ciencias de la
Dr. (c) en Educación línea de Educación, Master en
investigación Tecnologías de Estrategias y Tecnologías
la Información y para el Desarrollo,
Comunicación para la Especialista en docencia
inclusión, Magister en mediada por las TIC e
Educación, Especialista en Gerencia de Ingeniero Electrónico.
Telecomunicaciones, Ingeniero Electrónico.

Manuel Antonio Sierra Paula Andrea Quintero Celis

Rodríguez Corrección de estilo (Editor secundario)
Dr. (c) en Proyectos en la línea
de investigación en Diagramación: Cesar Augusto Ricautre
Tecnologías de la Información Diseño de portada: Cesar Augusto Ricautre
y Comunicación, Magíster en
Software Libre, Especialista en Publicado en Julio de 2018
Seguridad en Redes, Ingeniero de Sistemas, Formato digital PDF (Portable Document Format)
Consultor en Seguridad de la Información y
Comunicaciones.

Domingo Alirio Montaño Arias Editorial Universidad Manuela Beltrán

Dr. En Genética, Magister en Avenida Circunvalar Nº 60-00
Biología, Biólogo, Investigador Bogotá – Colombia
Asociado, Universidad Manuela Tel. (57-1) 5460600
Beltrán, BSc, MSc, PhD
Intereses de investigación en
Neurociencias, Genética y TIC
Aplicadas a la Educación.
 Patrones, Estándares y Metodologías para la Construcción de Software. / Miguel
García Torres… (y otros 7) - Bogotá: Universidad Manuela Beltrán, 2018.
108 p.: ilustraciones, gráficas, tablas; [versión electrónica]
Incluye bibliografía
ISBN: 978-958-5467-13-2
1. Software para computadores 2. Ingeniería de software. 3. Sistemas de
software. i. Sánchez Martelo, Carlos Augusto. ii. Avendaño Delgado, Henry
Leonardo iii. Sierra Rodríguez, Manuel Antonio iv. Collazos Morales, Carlos Andrés
v. Montaño Arias, Domingo Alirio. vi. Alfonso Corredor, Breed Yeet. vii. Rodríguez
Munca, José Daniel.
005.12 cd 21 ed.
CO-BoFUM
Catalogación en la Publicación – Universidad Manuela Beltrán

Miguel García Torres, Carlos Augusto Sánchez Martelo, Henry

Leonardo Avendaño Delgado, Manuel Antonio Sierra Rodríguez,
Carlos Andrés Collazos Morales, Domingo Alirio Montaño Arias,
Breed Yeet Alfonso Corredor, José Daniel Rodríguez Munca
Patrones, Estándares y Metodologías para la Construcción de
Software, Bogotá, UMB

© Miguel García Torres, Carlos Augusto Sánchez Martelo, Henry

Leonardo Avendaño Delgado, Manuel Antonio Sierra Rodríguez,
Carlos Andrés Collazos Morales, Domingo Alirio Montaño Arias,
Breed Yeet Alfonso Corredor, José Daniel Rodríguez Munca

© Universidad Manuela Beltrán

Bogotá, Colombia
http:// www.umb.edu.co
Queda prohibida la reproducción total o parcial de este libro por
cualquier proceso gráfico o fónico, particularmente por fotocopia,
Ley 23 de 1982
 Autoridades Administrativas

Gerente
Juan Carlos Beltrán Gómez

Secretario General
Juan Carlos Tafur Herrera

Autoridades Académicas
Rectora Alejandra Acosta Henríquez

Vicerrectoría de Investigaciones
Carlos Andrés Collazos

Coordinador General UMB Virtual

Gustavo Adolfo Salas Orozco

ISBN: 978-958-5467-13-2
 TABLA DE CONTENIDO
Patrones, Estándares y Metodologías para la Construcción de Software

Contenido
PRÓLOGO ...................................................................................................................................... 13
INTRODUCCIÓN ............................................................................................................................ 15
Capítulo I......................................................................................................................................... 17
1. Interactividad y navegación de aplicaciones ................................................................... 17
1.1. Introducción ....................................................................................................................... 17
1.1.1. Marco Conceptual .................................................................................................................... 18
1.1.2. Ideas Erronas de un Patrón ................................................................................................... 19
1.2. Tipos de Patrones ............................................................................................................ 20
1.2.1. Características de un Patrón ................................................................................................. 21
1.2.2. Patrones de Arquitectura ....................................................................................................... 24
1.2.3. Patrones de Diseño .................................................................................................................. 31
1.2.4. Ejemplos ..................................................................................................................................... 37
1.2.5. Ejercicios de reflexión ............................................................................................................. 41
Capítulo II ....................................................................................................................................... 43
2. Biblioteca de Tecnologías de Infraestructura de Comunicación ITIL ........................ 45
2.1. Introducción ....................................................................................................................... 45
2.2. Historia ................................................................................................................................ 46
2.3. Conceptos básicos de ITIL ............................................................................................ 47
2.4. Ciclo de vida de los servicios ....................................................................................... 51
2.5. Procesos de las fases del ciclo de vida ..................................................................... 53
2.5.1. Estrategia del servicio ............................................................................................................. 53
2.5.2. Diseño del servicio ................................................................................................................... 54
2.5.3. Transición del servicio ............................................................................................................ 55
2.5.4. Operación del servicio ............................................................................................................ 56
2.5.5. Mejora continua del servicio ................................................................................................. 56
2.6. Ejemplos ............................................................................................................................. 58
2.7. Ejercicios de reflexión..................................................................................................... 62
Capítulo III ...................................................................................................................................... 65
3.1. Metodologías para el Desarrollo de Software ........................................................... 66
3.1.1. Introducción ............................................................................................................................... 66

11
3.1.2. Marco Conceptual .................................................................................................................... 66
3.1.3. Metodologías para el Desarrollo de Software ................................................................... 74
3.1.4. Metodologías Ágiles ................................................................................................................ 76
3.1.5. Ejemplos ..................................................................................................................................... 88
3.1.6. Ejercicios de reflexión ............................................................................................................. 93

12
 PRÓLOGO

La ingeniería del software es una rama de la informática que se encarga de la

creación y mantenimiento de aplicaciones de software mediante la aplicación de
una metodología sistemática, disciplinada y cuantificable. Esta disciplina fue
impulsada por la crisis del software, que abarcó desde la década de los 60 hasta
los 80. En este período empezaron a surgir problemas frecuentes durante el
desarrollo del software, debido al aumento de la complejidad de este y el
desarrollo de sistemas y aplicaciones mucho más complejas.

En este libro se mostrará el conjunto de herramientas básicas para gestionar,

planificar y desarrollar proyectos de software y para poder evaluar la calidad. El
primer capítulo abarca los patrones de diseño, los cuales nos permitirán resolver
problemas comunes a distintos niveles del desarrollo del software. En el siguiente
capítulo, nos centraremos en el marco de trabajo ITIL (Information Technology
Infraestructure Library), el cual nos proporciona una serie de buenas prácticas
para la gestión de servicios de Tecnología de Información. En el último capítulo
veremos distintos métodos de desarrollo en ingeniería del software.

Miguel García Torres

13
14
 INTRODUCCIÓN

El software es uno de los componentes principales de un sistema informático.

Hasta hace relativamente poco se consideraba que su desarrollo podía ser
abordado por cualquier persona formada en disciplinas ajenas a la ingeniería
informática, como física, matemáticas, telecomunicaciones, etc. Sin embargo, con
el aumento de la complejidad de los problemas a resolver, la continua aparición de
nuevas metodologías, técnicas y herramientas de desarrollo, la calidad del
software se ha convertido en una cuestión de gran importancia.

En el desarrollo y mantenimiento del software es necesario aplicar una serie de

metodologías y estándares que ayuden a mejorar el diseño de las aplicaciones,
optimizar los costos y tiempos de desarrollo, mejorar la eficiencia del código
desarrollado y la detección de errores o mejoras potenciales mediante el
desarrollo de pruebas.

Con el paso del tiempo a los departamentos de TI se les empieza a exigir

ciertos niveles de calidad, no solo en el desarrollo de software, también en los
servicios que prestan en las distintas líneas de negocio, con el fin de encontrar
métodos y técnicas que permitan desarrollar y mantener software de calidad, así
como también a implantar y mantener infraestructuras con un alto grado de
disponibilidad. Para lo anterior, han surgido dos líneas metodológicas que se
complementan por sus distintos enfoques: CMMI (Capacity Madurity Model
Integrated) e ITIL (Information Technology Infrastructure Library).

El modelo CMMI es de gran eficacia en procesos de desarrollo de software

como la reducción del coste de desarrollo, localización y resolución de fallos, etc.
Sin embargo, su principal inconveniente es su falta de adecuación al enfoque o
servicio que está experimentando el sector de las TI. La metodología ITIL tiene el
objetivo de lograr una gestión eficiente de la infraestructura y servicios de TI. ITIL

15
recopila un conjunto de buenas prácticas para la gestión de los servicios; de modo
que estrictamente hablando no es una metodología en sí.

Por tanto podemos observar que mientras CMMI se centra en garantizar la

calidad en el desarrollo del software, ITIL garantiza la explotación del producto
software. Por ello, suelen considerarse complementarios.

16
 CAPÍTULO I

Patrones de Software

1. INTERACTIVIDAD Y NAVEGACIÓN DE APLICACIONES

Este capítulo aborda los patrones de diseño para el desarrollo de software. Se
divide en tres secciones. La primera introduce los conceptos básicos sobre un
patrón dentro de la ingeniería del software, así como los distintos tipos de patrones
que podemos encontrar en función de los niveles de abstracción. Esta sección nos
da una visión general del capítulo.

La segunda sección se centra en los patrones de arquitectura. Para ello, se

introduce en qué consisten y qué clase de patrones podemos encontrar. De todos
los existentes, se describen unos cuantos.

Finalmente, la última sección trata los patrones de diseño. Su estructura es la

misma que la sección anterior. Al final se describen los más representativos de
entre los patrones de creación, de estructura y de comportamiento.

1.1. Introducción
El software ha ido aumentando en complejidad a lo largo del tiempo, debido a
diversos factores como la rápida evolución de la tecnología, el aumento del
tamaño de los proyectos de software, el requisito de reutilizar componentes, etc. A
pesar de este aumento de la complejidad, los ingenieros se encuentran con
problemas similares que ya fueron resueltos, y de esa forma no tienen que
“reinventar la rueda” continuamente. Para poder aprovechar soluciones pasadas,
es necesario ser capaz de identificar problemas que sean similares.
17
 El estudio de los patrones de diseño nos proporciona un conjunto de
herramientas para poder identificar problemas y asociarles las soluciones
establecidas. Esto nos permite afrontar el desarrollo del software con mayores
garantías de éxito.

1.1.1. Marco Conceptual

Es habitual que los ingenieros que están trabajando en un problema específico
busquen una solución que resuelva el mismo problema o un problema similar, en
caso de que no haya sido resuelto antes. En el contexto de la ingeniería del
software, el patrón es una representación abstracta de una dualidad problema-
solución, de modo que la solución planteada se asocia a un problema recurrente.

Un patrón se caracteriza por tres elementos esenciales: un contexto, el

problema y la solución. El contexto describe un conjunto de situaciones
recurrentes en los que el patrón puede ser usado. El problema representa el
conjunto de objetivos y restricciones relevantes en ese contexto y describe cuándo
aplicar el patrón. Por último, la solución del diseño de las reglas que pueden ser
aplicadas para alcanzar los objetivos atendiendo a las restricciones, describen los
elementos que constituyen un patrón, las relaciones entre estos elementos y las
responsabilidades y colaboraciones.

Para que una solución sea considerada un patrón debe contar con las
siguientes características:

 Efectivo en resolver problemas similares.

 Reutilizable, de modo que sea aplicable a diferentes problemas de diseño
en distintas circunstancias.

Las principales motivaciones que podemos encontrar para usar patrones son:

18
  Capturan la experiencia acumulada en el desarrollo y mantenimiento de
software y lo pone accesible a profesionales no expertos.
 Generan un vocabulario o lenguaje de patrones que permite identificar
mejor las soluciones a problemas comunes.
 Permiten una mejora en la comprensión de los problemas que han sido
identificados a lo largo del tiempo.
 Pueden ser la base de un manual de ingeniería del software en el que se
documentan y difunden las prácticas exitosas.
 Facilitan la reutilización tanto a nivel de diseño como a nivel de código.
 Mejoran la posibilidad de evolución del software mediante la identificación
de los aspectos que pueden cambiar.

Antes de seguir, conviene decir que el uso de patrones no es obligatorio; solo

es aconsejable en el caso de enfrentarnos a problemas similares a los ya
resueltos por algún patrón. Además, abusar o forzar el uso de patrones es un error
que puede llevarnos a malas soluciones.

1.1.2. Ideas Erronas de un Patrón

Existen una serie de ideas erróneas acerca de los patrones que pasamos a
resumir:

 Los patrones son solo orientados a objetos. La mayoría de los patrones de

software se ajustan al paradigma orientado a objeto. Sin embargo los
patrones pueden aplicarse a una variedad de sistemas de software debido a
que describen problemas y soluciones de forma abstracta.
 Los patrones proveen soluciones a problemas recurrentes. Sin embargo, no
son soluciones exactas y no describen implementaciones sino aspectos que
resuelven el cuándo, por qué y cómo aplicar el patrón.

19
  Los patrones son implementaciones. Tal y como se ha explicado en el punto
anterior, los patrones son abstracciones de problemas y soluciones que se
asocian.
 Toda solución es un patrón. Para que una solución sea vista como un patrón,
esta ha de verificarse como una solución recurrente a un problema
recurrente. Para ello, se busca identificar el problema y la solución asociada
en al menos tres ámbitos distintos.

1.2. Tipos de Patrones

Los patrones pueden encontrarse en los distintos aspectos del software, como
la organización del desarrollo, el proceso de software, la planificación del proyecto,
la ingeniería de requisitos y la configuración del software. Por tanto, existen
diversas clasificaciones de patrones. Una posible clasificación, propuesta por
Appleton (2000), es la siguiente:

 Patrones de diseño. Aquellos patrones que encontramos en ingeniería del

software.
 Patrones de análisis. Están enfocados en describir modelos analíticos
recurrentes y reutilizables.
 Patrones de organización. Patrones que se aplican al proceso de diseño de
software.
 Patrones de otros dominios específicos.

De todos los anteriores, los más populares son los patrones de diseño.
Atendiendo al nivel de abstracción del contexto de aplicación o de la etapa en
proceso de desarrollo podemos distinguir tres categorías:

 Patrones de arquitectura. Son patrones de alto nivel que expresan una

organización estructural fundamental a nivel de sistema de software.

20
  Patrones de diseño. Se refieren a patrones de nivel intermedio que dan
soluciones a problemas detallados de diseño de software.
 Patrones elementales. Son específicos de un lenguaje de programación y
describen soluciones útiles para problemas específicos así como el modo
de implementar los distintos componentes particulares de un patrón.

La principal diferencia entre los patrones de estas tres categorías está en el

nivel de abstracción y los detalles. Los patrones de arquitectura son estrategias de
alto nivel para componentes de gran escala, propiedades y mecanismos globales
de un sistema. Por tanto, afecta a la estructura y organización de un sistema de
software. Los patrones de diseños tienen un nivel de abstracción medio y se aplica
a la estructura y comportamiento de entidades y sus relaciones. No afectan a la
estructura del sistema, aunque definen microarquitecturas de subsistemas y
componentes. Por último los patrones elementales son específicos de un
paradigma de programación y lenguajes y son, por tanto, de bajo nivel.
Debido a la especificidad de los patrones elementales, en este capítulo nos
centraremos a describir los patrones de arquitectura y de diseño.

1.2.1. Características de un Patrón

Los patrones deben ser presentados de forma apropiada para que puedan
entenderse. Una buena descripción ayuda a captar la esencia del patrón
rápidamente, así como todos los detalles necesarios para implementarlo y
considerar las consecuencias de su aplicación al problema.

Los patrones suelen estar descritos de manera uniforme. Esto ayuda a que
puedan ser comparados y podamos buscar soluciones alternativas al problema.

Para poder describir un patrón, el esquema contexto-problema-solución es un

buen punto de partida. Sin embargo, no es suficiente para tener una información

21
 completa que nos permita sopesarlo para ser aplicado a un problema. Las
distintas características suelen presentarse mediante una plantilla.

Además, los distintos elementos que se usan para describir un patrón dependerá
del tipo de patrón que queramos describir. En Buschmann et al. (1996), los
autores proponen la siguiente plantilla.

Plantilla 1. Plantilla propuesta por Buschmann para describir un patrón

Nombre Nombre y resumen del patrón.
Conocido como Otros posibles nombres asociados al patrón.
Ejemplo real que exponga los problemas y la necesidad de
Ejemplo
aplicar este patrón.
Contexto Las situaciones en las que este patrón puede aplicarse.
El problema que aborda el patrón, así como los objetivos y
Problema
restricciones.
Solución La solución fundamental que aporta este patrón.
Especificación detallada de los aspectos estructurales del
Estructura
patrón.
Escenarios típicos que describen el comportamiento en
Dinámicas
tiempo de ejecución del patrón.
Implementación Guías para implementar el patrón.
Discusión de los aspectos importantes que no son cubiertos
Ejemplo resuelto
aún por la solución.
Variantes Descripción breve de variantes o especializaciones del patrón.
Casos conocidos Ejemplos de uso del patrón.
Consecuencias Los beneficios y desventajas que provee el patrón.
Ver también Referencias a patrones que resuelven problemas similares.
Fuente: adaptado de Buschmann, F. et al. (1996). Pattern-oriented software architecture – A
system of patterns. Volume 1. John Wiley & Sons.

Existen otras propuestas de plantilla como las de Alexander (1979) y la de

Gamma et al. (1994), entre muchas otras. La propuesta de Alexander es la
siguiente.

22
Plantilla 2. Plantilla propuesta por Alexander para describir un patrón
Nombre Nombre significativo.
Problema Cuestiones del problema que pretende resolver.
Contexto Situaciones que den lugar al problema.
Fuerzas Escenario concreto.
Solución Solución probada al problema.
Ejemplos Una muestra de aplicación del problema.
Contexto resultante El estado del sistema tras aplicar el patrón.
Razón fundamental Explicación de los pasos o reglas del patrón.
Patrones relacionados Relaciones estáticas y dinámicas con otros patrones.
Uso conocido Ocurrencias del patrón dentro del sistema existente.
Fuente: Alexander, C. (1979). The Timeless Way of Building. Oxford: Oxford University Press.

Por último, en Gamma et al. Se propone la siguiente plantilla.

Plantilla 3. Plantilla propuesta por Gamma et al. Para describir un patrón

Nombre y
Clasificación según Gamma (Gamma +).
clasificación
Propósito El problema que abarca el patrón.
Conocido como Otros nombres del patrón.
Motivación Un escenario que ilustre el problema.
Aplicabilidad Situaciones en las que el patrón puede aplicarse.
Estructura Una representación gráfica de las clases en el patrón.
Participantes Clases, objetos y sus relaciones.
Colaboración Colaboración de los participantes y sus responsabilidades.
Consecuencias Balances y resultados de usar un patrón.
Implementación Cosas a tener en cuenta al implementar un patrón.
Código de muestra Fragmento de código ilustrando una implementación.
Usos conocidos Ejemplos de patrones encontrados en sistemas reales.

23
Patrones relacionados Otros patrones estrechamente relacionados.
Fuente: Gamma, E., R. Helm, R., Johnson, R., Vlissides, J. (1994). Design Patterns. Elements of
Reusable Object-Oriented Software. Massachusetts: Addison-Wesley.

A pesar de que haya distintas propuestas, la información global que ofrecen

estas plantillas es similar. Las diferencias radican más en los descriptores.

1.2.2. Patrones de Arquitectura

En el ámbito del software surge el concepto de arquitectura del software, el cual
hace referencia a la estructura del sistema que representa un diseño de alto nivel
con dos principales propósitos: satisfacer los atributos de calidad (desempeño,
seguridad, flexibilidad, etc.) y servir como guía en el desarrollo. Un mal diseño
puede conllevar a no satisfacer los requisitos, así como a un alto coste en las
modificaciones a llevar a cabo en futuras modificaciones. En este contexto, los
patrones de arquitectura ofrecen soluciones a problemas de arquitectura de
software mediante un concepto que captura los elementos esenciales de una
arquitectura. Diversas arquitecturas pueden implementar el mismo patrón. Una
característica de este tipo de soluciones es que suelen enfocarse en un aspecto
específico como el rendimiento, la alta disponibilidad, la tolerancia a fallos, la
capacidad, etc.

Existen diversas taxonomías de los distintos tipos de patrones de arquitectura.

Según la clasificación de Buschmann et al. (1996), hay cuatro grandes categorías:
patrones simples, sistemas distribuidos, sistemas interactivos y patrones
adaptables. A continuación podemos ver algunos de los patrones más usados y la
categoría a la que pertenecen (tabla 1).

Tabla 1. Tipos de patrones de arquitectura

Categoría del patrón Patrones
Patrones simples Pipes-Filters, Blackboard, Layer, Repository.

24
Sistemas distribuidos Broker, CAGS, Client-Server.
Sistemas interactivos MVC, PAC.
Patrones adaptables Microkernel, Reflection.
Fuente: adaptado de Buschmann, F. et al. (1996). Pattern-oriented software
architecture. A system of patterns. Nueva York: John Wiley & Sons.

Los patrones simples están enfocados en apoyar que todas las tareas
necesarias se descompongan y organicen en torno a subtareas que se coordinan
y cooperan. La segunda categoría (sistemas distribuidos) se centra en
infraestructuras para aplicaciones distribuidas. Los patrones Microkernel y Pipes-
Filter pueden entrar en esta categoría, aunque de forma secundaria. La siguiente
categoría (sistemas interactivos) está enfocada a sistemas que requieren de la
interacción humano-computador. Por último, los patrones adaptables hacen
referencia a aquellos sistemas en los que es importante extenderlos, adaptarlos a
la nueva tecnología y/o llevar a cabo cambios de los requerimientos funcionales. A
continuación, pasamos a describir algunos de estos patrones.

1.2.2.1. Layers
La arquitectura por capas es uno de los patrones más usados. Se define como
una organización jerárquica en capas del sistema, en la que cada una provee un
conjunto de servicios a las capas superiores y requiere de los servicios de las
inferiores. La figura 1 muestra un esquema general de este patrón.

En este patrón podemos diferenciar dos modelos: modelo estricto y relajado. El

modelo estricto impone que una capa solo pueda utilizar los servicios de la capa
inmediatamente inferior. En el relajado, en cambio, puede ser de cualquiera de las
capas inferiores. Aunque este patrón no especifica el número de capas ni su tipo,
la mayoría de las arquitecturas por capas se componen de cuatro: presentación,
negocio, persistencia y base de datos. La figura 2 muestra este esquema.

25
 Figura 1: esquema general del patrón Layer.
Fuente: elaboración propia

Figura 2: capas típicas en un patrón Layer. En la arquitectura de la izquierda, las

capas son cerradas, mientras que en la de la derecha la capa de servicios está
abierta. Esto permite que la capa de negocios pueda acceder a la capa de
persistencia directamente sin pasar por la capa de servicios.

26
Fuente: elaboración propia.

A continuación, pasamos a describir este patrón haciendo uso de plantillas,

aunque solo nos centraremos en los descriptores más importantes.

Tabla 2. Descriptores más importantes del patrón layers

Patrón Layers
Organizar un sistema con base en la naturaleza de los
Contexto
servicios.
Si los servicios no están bien organizados, el sistema podría
Problema tener problemas de mantenibilidad, adaptabilidad y
escalabilidad.
 Estructura el sistema en un número determinado de capas.
 Empezar con la capa con el nivel más bajo de abstracción.
 Poner la capa J sobre la J-1 hasta alcanzar la última capa N.
 Los servicios de J usan los servicios de J-1 o cualquier otra
Solución capa inferior.
 No se requiere un orden en la implementación, ni ninguna
sofisticación.
 Dentro de cada capa, los componentes tienen el mismo nivel
de abstracción.
Ventajas:
◦ Reutilización de niveles.
◦ Facilidad para la comprensión, mantenimiento y portabilidad
del sistema.
◦ Soporte para la estandarización.
◦ Los cambios en el código son locales a cada nivel.
Consecuencias Desventajas:
◦ Ineficiencia.
◦ Excesivo trabajo.
◦ Difícil establecer la correcta granularidad de los niveles:
▪ - Pocos niveles no explotan el potencial de reúso, portabilidad
e intercambiabilidad.
▪ - Muchos niveles crean complejidad e ineficiencia.
Fuente: adaptado de Ochoa, S. (2005). Introducción a los Patrones (Diseño y Arquitectura). U-
Cursos, CC51A-1 Ingeniería de Software.

27
1.2.2.2. Pipes-Filters
Proporciona una estructura para sistemas que procesan un flujo de datos de
entrada. Cada paso de procesamiento se encapsula en un filtro. Los datos se
pasan a través de tuberías entre filtros adyacentes. Recombinando los filtros
pueden construirse distintas familias de sistemas relacionados. La figura 3
muestra un esquema general de este patrón.

Figura 3: esquema general del patrón Pipes and Filters.

Fuente: elaboración propia

28
 Las características básicas de este patrón se muestran en la siguiente tabla.

Tabla 3. Descriptores más importantes del patrón Pipes-Filters

Patrón Pipes-Filters
Contexto Procesamiento de flujo de datos.
 Descomponer la funcionalidad del sistema en una serie de
actividades.
 Las actividades transforman uno o más flujos de datos de
entrada en uno o más flujos de datos de salida de forma
incremental.
 Cada actividad es un filtro.
 Los filtros se comunican a través de tuberías (pipes).
 El sistema es una secuencia de transformaciones de los
datos.
Problema  Las transformaciones son:
◦ - Bien ordenadas.
◦ - Sin estado interno.
◦ - Independientes.
 Fuerzas:
◦ - Cambios mediante el cambio de filtros.
◦ - Pequeñas transformaciones son más fácilmente reutilizadas.
◦ - Los datos pueden tener distinto formato.
 Filtros:
◦ - El sistema se divide en varios pasos secuenciales de
procesamiento.
◦ - Los pasos se conectan con flujos de datos.
◦ - Cada filtro consume y procesa sus datos de forma
incremental.
Solución ◦ - El origen de los datos, el destino y los filtros se conectan con
tuberías que implementan el flujo de datos entre los pasos de
procesamiento.
 Tuberías:
◦ - Conecta origen-filtro, filtro-filtro y filtro-destino.
◦ - Transferencia de datos con un buffer First-In-First-Out
(FIFO).
Consecuencias Ventajas:

29
 ◦ - Los archivos intermedios no son necesarios.
◦ - Flexibilidad.
◦ - Reutilización de filtros.
◦ - Mejora de la eficiencia con procesamiento en paralelo.
 Desventajas:
◦ - La compartición de información de estado es caro y poco
flexible.
◦ - Ineficiencia por conversión de datos.
◦ - Errores podrían implicar reiniciar el sistema.
Fuente: adaptado de Ochoa, S. (2005). Introducción a los Patrones (Diseño y Arquitectura). U-
Cursos, CC51A-1 Ingeniería de Software.

1.2.2.3. Model-View-Controller
Como puede verse en la figura 4, este patrón divide una aplicación interactiva
en tres partes. El modelo contiene los datos y la funcionalidad esencial. La vista
despliega la información al usuario y el controlador maneja las entradas. La vista y
el controlador componen la interfaz con el usuario.

Figura 4: esquema del patrón Model-Viewer-Controller.

Fuente: elaboración propia

30
La descripción de este patrón se muestra en la siguiente tabla:

Tabla 4. Descripción de los descriptores más importantes del patrón Model-View-Controller

Patrón Model-View-Controller
Aplicaciones interactivas con interfaces humano-computador
Contexto
cambiantes y flexibles.
 Las interfaces de usuario se cambian con frecuencia.
 Cambios en la funcionalidad han de reflejarse en las interfaces.
 Puede haber interfaces a medidas para distintos tipos de usuarios.
Problema  Construir un sistema monolítico es difícil y costoso.
 Diferentes paradigmas de interfaz:
◦ Digitar información.
◦ Seleccionar íconos.
 MVC divide la aplicación en procesamiento, entradas y salidas.
 El modelo representa la funcionalidad y los datos esenciales. Es
independiente de la representación en las interfaces.
 La vista obtiene datos del modelo y los despliega para el usuario.
Solución
 Cada vista tiene asociado un controlador.
 El controlador recibe eventos como entrada y las traduce a
solicitudes de servicios del modelo o la vista.
 El usuario solo interactúa con el modelo a través del controlador.
 Ventajas:
◦ - Múltiples vistas para un solo modelo.
◦ - Vistas sincronizadas.
◦ - Vistas y controladores intercambiables.
 Desventajas:
Consecuencias
◦ - Mayor complejidad.
◦ - Excesivos cambios potenciales.
◦ - Relación estrecha entre vistas y controladores.
◦ -Ineficiencias en el acceso a los datos de la vista.
◦ - Difícil usar MVC con herramientas gráficas modernas.

Fuente: adaptado de Ochoa, S. (2005). Introducción a los Patrones (Diseño y Arquitectura). U-

Cursos, CC51A-1 Ingeniería de Software.

1.2.3. Patrones de Diseño

Los patrones de diseño buscan soluciones a problemas comunes en el
desarrollo de software. Se clasifican con base en el propósito (qué hace un patrón)

31
y el ámbito de actuación. Atendiendo al propósito, podemos encontrar tres tipos de
patrones: de creación, de estructura y de comportamiento:

 Los patrones de creación resuelven problemas relacionados con la creación

de instancias de objetos.
 Los patrones de estructura se centran en el modo de estructurar las clases.
 Los patrones de comportamiento se centran en el funcionamiento de la
aplicación, normalmente durante el tiempo de ejecución.

Con base en el ámbito, los patrones se aplican a clases u objetos:

 Patrones de clase tratan relaciones entre clases y subclases. Este tipo de

relaciones están basados en la herencia, de modo que son estáticas.
 Patrones de objetos abarcan relaciones entre objetos, las cuales pueden
cambiar durante la ejecución y son, por tanto, más dinámicas.

Los patrones de creación abstraen el proceso de instanciación. Ayudan a que

un sistema sea independiente del proceso en que los objetos son creados,
compuestos y representados. En caso de que este patrón sea de ámbito de clase,
hace uso de la herencia para variar la clase que es instanciada, mientras que en
caso de que sea de ámbito de objeto, delegará la instanciación a otro objeto. Por
tanto, este tipo de patrones permiten la configuración de un software compuesto
de objetos que varían en estructura y funcionalidad. Dicha configuración puede ser
estática, como por ejemplo que sea comunicada en tiempo de compilación, o
dinámica, si es comunicada en tiempo de ejecución.

Atendiendo a ambos, la siguiente tabla hace un listado de algunos patrones de

diseño. Ponemos, en concreto, aquellos que aparecen en Gamma et al. (1994),
popularmente conocidos como Gang of Four (gof).

32
 Tabla 5. Clasificación de los patrones de diseño popularmente conocidos como Gang
of Four
Patrones de diseño
Propósito
De creación Estructurales De comportamiento
-Interpreter
Clase -Factory method -Adapter
-Template method
-Chain of responsability
-Adapter -Command
-Bridge -Iterator
Ámbito Abstract factory
-Composite -Mediator
Builder
Objeto -Decorator -Memento
Prototype
-Facade -Observer
Singleton
-Flyweight -State
-Proxy -Strategy
-Visitor
Fuente: adaptado de Gamma, E., R. Helm, R., Johnson, R., Vlissides, J. (1994).
Design Patterns. Elements of Reusable Object-Oriented Software. Massachusetts:
Addison-Wesley.

1.2.3.1. Factory
Define una interfaz para crear un objeto pero deja en manos de las subclases el
decidir qué clase instanciar. Deja la instanciación a las subclases en función de los
datos provistos.

Este patrón ayuda a evitar que se viole uno de los principios del diseño
orientado a objetos: “programar para una interfaz, no para una implementación”. Si
el código depende de clases concretas y la API no es estable y puede estar sujeto
a cambios, las dependencias pueden dificultar futuras implementaciones.
Podemos decir que es adecuado usar este patrón si:

 Una clase no puede anticipar el tipo de objetos que debe crear.

 Una clase quiere delegar a las subclases el especificar los objetos
que crea.

33
1.2.3.2. Abstract factory
Provee una interfaz para crear y devolver una familia de objetos relacionados o
dependientes. Es similar al patrón factory pero las diferencias son:

 Este patrón delega la responsabilidad de instanciar un objeto a otro objeto

mediante la composición, mientras en el patrón factory usa herencia y se
apoya en una subclase para manejar la instanciación de objetos.
 El objeto delegado del abstract factory usa con frecuencia un patrón factory
para llevar a cabo la instanciación.

Este patrón debería usarse si:

 Un sistema debería ser independiente de la manera en la que sus
productos son creados, compuestos y representados.
 Un sistema debería ser configurado con una de las múltiples familias de
productos.
 Una familia de productos de objetos relacionados es diseñado para que se
usen conjuntamente y se necesita forzar esta restricción.
 Se quiere proveer una librería de clases de productos y solo se quiere dejar
acceso a las interfaces y no a las implementaciones.

Este patrón permite que una aplicación portable encapsule todas las
dependencias asociadas a la plataforma. Algunas de estas dependencias serían la
base de datos, el sistema operativo, etc.

1.2.3.3. Builder
Separar la construcción de un objeto complejo de su representación, de modo
que el mismo proceso pueda crear distintas representaciones.

Este patrón es similar al abstract factory. Sin embargo, se diferencia en que

builder se enfoca en construir un objeto complejo paso a paso, mientras que
abstract factory hace un mayor énfasis en familias de objetos de productos,
independientemente de que sean simples o complejos. Este patrón se usa si:
34
  El algoritmo para crear el objeto complejo debería ser de las partes que
forman el objeto y como son ensamblados.
 El proceso de construcción debe permitir diferentes representaciones del
objeto que es construido.

1.2.3.4. Singleton
Patrón que se aplica para asegurar que una clase solo tiene una instancia, y
que puede accederse a ella de forma global. Este patrón es útil e importante en
casos de coordinación de acciones a lo largo del sistema (un archivo de sistema,
un administrador de ventanas, etc.). Si hubiera más de una instancia la
complejidad de la acción, así como la probabilidad de error, aumentaría
considerablemente. Usar este patrón si:

 Debe haber solo una instancia de una clase y debe ser accesible a los
clientes desde un punto de acceso conocido.
 Cuando la instancia podría extenderse mediante herencia y los clientes
podrían usar esta instancia que extiende la original sin modificar su código.

Se suele definir el método Instance () como aquél que permite que los clientes
accedan a la única instancia.

1.2.3.5. Decorator
Este patrón, también conocido como wrapper, aborda el modo de añadir
funcionalidades a un objeto de forma dinámica, a diferencia de la herencia que
sería estática. Por ejemplo, un objeto decorator que contiene un componente de
interfaz de usuario podría añadir una funcionalidad como sería añadir sombra a un
componente, zoom, etc. Este patrón se usa en los siguientes casos:

 Añadir responsabilidades a objetos individuales de forma dinámica y

transparente (sin que afecte a otros objetos).
35
  Para responsabilidades asociadas a un contexto específico.
 No es posible o no es práctico extender el objeto mediante subclases.

Básicamente este patrón nos proporciona un método para modificar el

comportamiento de un objeto individual sin tener que crear clases derivadas.

1.2.3.6. Facade
Este patrón proporciona una interfaz unificada para un conjunto de interfaces
del sistema. Define una interfaz de alto nivel que hace que el subsistema sea más
sencillo de usar. Este patrón se usa si:

 Se quiere proporcionar una interfaz simple para un sistema complejo. Dicha

interfaz es una vista por defecto del sistema que es adecuado para la
mayoría de los clientes. Solo aquellos que necesiten adaptar el sistema a
más bajo nivel requerirán mirar más allá de este patrón.
 Hay diversas dependencias entre clientes y las clases implementadas
derivadas a partir de clases abstractas. En este caso el patrón favorece la
independencia y portabilidad del sistema.
 Hay interés en estratificar el sistema. Este patrón permitiría definir un punto
de entrada para cada capa del sistema simplificando las dependencias
entre capas, lo que hace que la comunicación entre dichas capas sea solo
a través de este patrón.

1.2.3.7. Iterator
Define una interfaz que declara los métodos necesarios para acceder
secuencialmente a un grupo de objetos de una colección, independientemente de
su estructura. Las circunstancias en las que se usan son:

 Se necesita tener acceso a elementos sin tener acceso a toda la

representación.
36
  Se pretende hacer recorridos múltiples o concurrentes de los elementos.
 Existen diferencias sutiles entre los detalles de implementación de varios
iteradores.

1.2.3.8. Observer
Define una dependencia del tipo uno-a-muchos entre objetos, de manera que
cuando uno de los objetos cambia su estado, notifica este cambio a todos los
dependientes. Se usa en los siguientes casos:

 Se necesita consistencia entre clases relacionadas, pero con

independencia.
 Los cambios de estado en uno o más objetos deben dar lugar a
comportamiento entre otros objetos.

1.2.4. Ejemplos
Ejemplo 1: Patrones arquitectónicos
El problema KWIC (KeyWord In Context) consiste en que dado una lista de líneas
como entrada, hay que permutar, pasando la última palabra al principio de la línea
(Circular Shift). Por ejemplo, si tenemos la siguiente línea:
man eats dog

La salida debería ser:

dog man eats
eats dog man
man eats dog

Podemos resolver este problema haciendo uso de un patrón layer. La figura 5

muestra cómo se diseñaría una solución a este problema recurriendo al patrón
layer. Los elementos representan objetos y las flechas indican métodos de

37
llamada. La comunicación de los datos se hace mediante este último método.
Como puede verse, la organización en capas está basada en objetos que llaman
métodos de la misma capa o de la capa contigua.

Figura 5: Patrón layer para el problema KWIC.

Fuente: elaboración propia.

La ventaja de esta solución es que los datos están escondidos dentro de los
objetos. Esto implica que las elecciones de las estructuras de datos y los
algoritmos estén encapsulados en componentes específicos. Lo que facilita futuros
cambios que mantengan las interfaces abstractas presentes.

Figura 6: Patrón Pipe-Filter para el problema KWIC.

Fuente: elaboración propia

38
También podemos resolver este problema haciendo uso del patrón pipe-filter. La
figura 6 muestra cómo quedaría la solución. En este caso, se construiría una
cadena de transformaciones y se necesitaría que los datos estuvieran en un
formato uniforme. También se pueden esconder los datos, pero teniendo en
cuenta la uniformidad de estos. En caso de que tuviéramos que manejar
internamente distintas estructuras de datos dentro de cada filtro, habría una
pérdida de eficiencia debido a la transformación de los datos al formato común.

Ejemplo 2: Patrones de diseño

A continuación, se presenta un ejemplo de uso del patrón factory, el cual permite
crear objetos sin exponer la lógica de la creación para el cliente, y los objetos se
crean mediante una interfaz común. La figura 7 muestra un esquema en UML de
una implementación de dicho patrón. Tenemos la interfaz shape, la cual es
implementada por las clases circle, square y rectangle. Hay una fábrica,
ShapeFactory, la cual crea las instancias en función de la información que se le
pasa como entrada. Por último FactoryPatternDemo es la clase principal que usa
la fábrica.

Figura 7: Uso del patrón Factory.

Fuente: http://www.es.w3eacademy.com/design_pattern/factory_pattern.htm

39
Si en este proyecto ampliásemos el diseño a los colores también, sería
conveniente usar el patrón AbstractFactory, el cual puede ser visto como una
fábrica de fábricas.

Figura 8: Uso del patrón AbstractFactory.

Fuente: http://www.es.w3eacademy.com/design_pattern/abstract_factory_pattern.htm

La figura 8 muestra un esquema en UML de la implementación del ejemplo. Como

puede apreciarse, ahora hemos añadido la interfaz color, que está implementado
por las clases Red, Green y Blue. Ahora se crea una interfaz de fábrica,
AbstractFactory, que implementa las fábricas ShapeFactory y ColorFactory.
Además se crea una clase de fábrica generadora, FactoryProducer, la cual
devuelve el tipo de fábrica en función de la entrada. Por último la clase

40
AbstractFactoryPatternDemo es la clase principal que hace uso del generador de
fábricas. Primero genera el tipo de fábrica que le interesa y posteriormente le pasa
el tipo de información de entrada asociada a dicha fábrica.

1.2.5. Ejercicios de reflexión

1. Describa, teniendo en cuenta la plantilla que se muestra a continuación, los siguientes
patrones de arquitectura: Blackboard, Repository, Broker, CAGS, PAC, Microkernel y
Reflection.

Patrón <nombre del patrón>

Contexto
Problema
Solución
Consecuencias

2. Describa cada uno de los patrones de diseño vistos, ajustándose a la plantilla mostrada a
continuación.

Nombre y clasificación
Propósito
Conocido como
Motivación
Aplicabilidad
Estructura
Participantes
Colaboración
Consecuencias
Usos conocidos
Patrones relacionados

41
42
 CAPÍTULO II

Estándares de TI

Con el paso del tiempo a los departamentos de TI se les empieza a exigir

ciertos niveles de calidad en los servicios que prestan en las distintas líneas de
negocio, con el fin de encontrar métodos y técnicas que permitan desarrollar y
mantener software de calidad, así como también a implantar y mantener
infraestructuras con un alto grado de disponibilidad. Para lo anterior, han surgido
dos líneas metodológicas que se complementan por sus distintos enfoques: CMMI
(Capacity Madurity Model Integrated) e ITIL (Information Technology Infrastructure
Library).

El modelo CMMI es de gran eficacia en procesos de desarrollo de software

como la reducción del coste de desarrollo, localización y resolución de fallos, etc.
Sin embargo, su principal inconveniente es su falta de adecuación al enfoque o
servicio que está experimentando el sector de las TI. La metodología ITIL tiene el
objetivo de lograr una gestión eficiente de la infraestructura y servicios de TI. ITIL
recopila un conjunto de buenas prácticas para la gestión de los servicios; de modo
que estrictamente hablando no es una metodología en sí.

Por tanto podemos observar que mientras CMMI se centra en garantizar la

calidad en el desarrollo del software, ITIL garantiza la explotación del producto
software. Por ello, suelen considerarse complementarios.

43
44
2. BIBLIOTECA DE TECNOLOGÍAS DE INFRAESTRUCTURA DE COMUNICACIÓN
ITIL

2.1. Introducción
En la actualidad, cualquier organización tiene una dependencia tecnológica que
va en aumento a medida que aumenta el tamaño de dicha organización. En este
contexto, ITIL (Information Technology Infrastructure Library) proporciona un
marco de referencia para alinear la tecnología con las líneas estratégicas de
negocio de la organización.

Su importancia ha calado de tal forma que ha hecho que se convierta en el

estándar de referencia para gestionar los servicios TI. Los beneficios que una
organización puede tener del uso de ITIL son los siguientes: reducción de costes,
mejora de la calidad y disminución del riesgo, mejora de la toma de decisiones,
incremento de la productividad, además de los que se presentan a continuación.

 Mayor cualidad y consistencia. Esto se logra alineando los procesos con un

marco de referencia. Los servicios TI ofrecidos son mejores y más fiables.
Además, la plantilla puede responder con mayor celeridad a los incidentes
que acontezcan.
 Clientes más satisfechos. Incorporar ITIL permite que la organización se
centre en los requisitos de los clientes y en la experiencia de los usuarios.
Esto mejora la relación con los clientes.
 Lenguaje común. En caso de incidencias existen protocolos de actuación
que todos deben conocer. Esto ayuda a establecer prioridades y a entender
las responsabilidades.
 Disminución de costos. El uso de mejores prácticas posibilitan un uso más
eficiente de los recursos. Lo que evita actuaciones que demostraron ser
ineficaces o menos eficientes.

45
  Mejor productividad. El uso de ITIL repercute en una disminución de los
incidentes así como en una resolución más eficiente de estos y evita tener
que aclarar aspectos relacionados con la gestión de dichos incidentes.
 Mayor confianza. El establecimiento de ITIL como un estándar a nivel global
aporta una mayor garantía de su utilidad en los procesos de mejora así
como en la escalabilidad para el futuro.

Finalmente, cabe destacar que hay una certificación ITIL que acredita a
individuos (no a empresas) por la adquisición de un nivel de conocimientos
determinado en lo relativo a la gestión de servicios TI. La adquisición de estos
conocimientos por parte de los trabajadores dentro de una empresa u
organización permite la creación de estrategias básicas para la gestión de
servicios TI.

2.2. Historia
ITIL (Information Technology Infrastructure Library) es un conjunto de
publicaciones de las mejoras prácticas para la gestión de servicios TI.

ITIL se desarrolló durante los años 80 en el Reino Unido motivado por la

percepción, por parte del gobierno británico, de que la calidad del nivel de los
servicios TI no era suficiente. A la CCTA (Central Computer and
Telecommunications Agency), actualmente denominada OGC (Office of
Government Commerce), se le encomendó la tarea de desarrollar un manual de
buenas prácticas para un uso eficiente y económicamente responsable de los
recursos TI.

En sus inicios, ITIL fue denominado GITIM (Government Information

Technology Infrastructure Management). A pesar de que GITIM era bastante
distinto a lo que hoy en día es ITIL, conceptualmente eran muy similares, pues
ambos están enfocados en los servicios de mantenimiento y suministro.

46
 A principio de los 90 las grandes compañías europeas fueron adoptando dichas
prácticas tanto en el ámbito gubernamental como privado. En el año 2000 la CCTA
pasó a ser OGC y Microsoft adoptó ITIL como base para desarrollar MOP
(Microsoft Operations Framework). La versión 2 de ITIL apareció en 2001 y aportó
una mejor precisión en lo relativo a los servicios de mantenimiento y suministro.
En los siguientes años se extendió su uso como buena práctica a lo largo del
planeta. En 2007 salió la versión 3 de ITIL, la cual orienta la gestión de servicios
desde una aproximación de ciclos de vida, con un mayor énfasis en la integración
de negocios TI.

2.3. Conceptos básicos de ITIL

En ITIL se diferencian los conceptos de proceso y función. Por un lado un
proceso es un conjunto de actividades interrelacionadas para la consecución de
un objetivo específico. Orientar la organización TI con base en procesos permite
desarrollar una estructura más clara, eficaz y orientada hacia los objetivos de la
empresa. Además, permite tener un mayor control sobre los servicios y la
infraestructura, así como mejorar la gestión de los cambios. También cabe
destacar que este tipo de organización proporciona un buen marco de trabajo para
la externalización de algunos elementos TI. Los procesos deben caracterizarse por
ser eficaces, y alcanzar los objetivos marcados, y eficientes, procurando hacer uso
del menor conjunto de recursos posible.

Todo proceso se caracteriza por lo siguiente:

 Son cuantificables

◦ Los objetivos a alcanzar son identificables y contables.

◦ Se suele medir el coste, la calidad, la duración, la productividad,

etc.
 Tienen resultados específicos

47
 ◦ Conjunto de actividades con el objetivo de cumplir un cometido
específico.

◦ Los procesos están orientados hacia el rendimiento.

 Tienen un cliente final

◦ Los resultados son entregados a un cliente o parte interesada.

◦ Dichos resultados deben satisfacer las expectativas del cliente.

◦ Los clientes pueden ser internos o externos a la propia

organización.
 Se inician como respuesta a un evento

◦ Se debe poder trazar al desencadenante específico.

Un proceso se describe mediante los siguientes componentes:

 Input. Son el conjunto de entradas del proceso.

 Output. Hace referencia a los productos de salida del proceso.
 Actividades y subprocesos. El conjunto de etapas a realizar.
 Roles y recursos implicados. Las distintas categorías de personas
o grupos dentro del proceso que tienen objetivos y actividades
diferenciadas.
 Control del proceso:

◦ Propietario o dueño del proceso. Se refiere a la persona

responsable del proceso.

◦ Objetivo del proceso. Es la finalidad del proceso.

◦ Métricas. Es el conjunto de medidas usadas.

Una función es, en cambio, una unidad especializada en la realización de

cierta actividad y es responsable del resultado que produzca. Esto incluye los
recursos y capacidades necesarios para el correcto desarrollo de la actividad. El

48
objetivo que se persigue con las funciones es la de dotar a las organizaciones de
una estructura acorde al principio de especialización.
Otro concepto de importancia en ITIL es la de rol, el cual no es más que un
conjunto de actividades y responsabilidades asignadas a una persona o grupo. Sin
embargo, una persona o grupo puede desempeñar más de un rol.

Hay cuatro roles genéricos que son especialmente importantes para la gestión de
servicios TI:

- Gestor del servicio. Es el responsable de la gestión del servicio durante

todo el ciclo de vida del servicio: desarrollo, implementación,
mantenimiento, monitorización y evaluación.
- Propietario del servicio. Es el último responsable de cara al cliente y a la
organización de TI que presta el servicio.
- Gestor del proceso. Es el responsable de la gestión de la operación
asociada a un proceso en particular: planificación, organización,
monitorización y generación de informes.
- Propietario del proceso. Es el responsable frente a la organización TI de
que el proceso cumpla sus objetivos. Debe estar involucrado en su fase de
diseño, implementación, cambio. Además, debe asegurar en todo momento
que se dispone de las métricas necesarias para su correcta monitorización,
evaluación y eventual mejora.

Finalmente RACI (también llamado matriz de asignación de responsabilidades)

es un modelo útil para la asignación de responsabilidades en la ejecución de
tareas o actividades asignadas a un proyecto. Esta matriz se usa durante la fase
de diseño del servicio y ayuda a organizar adecuadamente todos los procesos y
actividades implicados.

49
Los acrónimos de RACI hacen referencia a lo siguiente:

 R (responsible). Se refiere al encargado, la persona que tiene

asignada llevar a cabo la tarea en cuestión.
 A (accountable). Es el responsable, y hace referencia a la persona
con autoridad y responsabilidad de que la tarea se ejecute
correctamente.
 C (consulted). Es el consultado. Se refiere al conjunto de personas
a las que se les debe consultar para la realización de la tarea.
 I (informed). Es el informado y hace referencia a la persona o
conjunto de personas que han de ser informadas sobre el progreso
de la ejecución de la tarea.

En una tarea solo puede haber un único R y A. En caso contrario, dicha tarea se
subdividirá en múltiples tareas hasta que así sea. Una matriz RACI típica tiene un
eje vertical donde se describen las tareas o entregables en orden cronológico y un
eje horizontal con los perfiles de las personas implicadas en los mismos. A
continuación, ponemos un ejemplo del reparto de roles en la realización de una
copia de seguridad de una base de datos perteneciente a una aplicación de un
sistema de información (ver tabla 1).

Tabla 1. Matriz RACI

Encargado Responsable Consultado Informado
I (responsable del
sistema)
C (Administrador de
la aplicación)
A (Administrador de
la base de datos)
R (Operador técnico)
Nota. Existen variantes de este modelo como el RASCI, el cual incluye la figura del
soporte (Support), o el modelo RACI-VS, el cual incorpora las figuras del
verificador (Verify) y del firmante (Sign).

50
2.4. Ciclo de vida de los servicios
La versión 3 de ITIL orienta el servicio TI a las 5 fases del ciclo de vida:

1. Estrategia del servicio. Propone tratar el servicio TI como un activo

estratégico.
2. Diseño del servicio. Abarca los principios y métodos necesarios
para transformar los objetivos estratégicos en portafolios de servicios
y activos.
3. Transición del servicio. Cubre el proceso de transición para la
implementación de nuevos servicios o mejorar los ya existentes.
4. Operación del servicio. Abarca las mejores prácticas para la
gestión del día a día en la operación del servicio.
5. Mejora continua del servicio. Provee una guía para la creación,
mantenimiento, transición y operación del servicio ofrecido.

Hay que tener en cuenta que estas fases no son independientes entre sí sino
que están interrelacionadas de una manera cíclica y esto afecta al propio ciclo de
vida del servicio.

La figura 1 muestra de forma esquemática las 5 fases del ciclo de vida. Como
puede verse, la fase de estrategia del servicio basado en ITIL es central al
concepto de ciclo de vida del servicio. Tiene como principal objetivo convertir la
gestión del servicio en un activo estratégico para la organización. Para ello debe
identificar a la competencia y competir con ella diferenciándose y ofreciendo un
mejor rendimiento. El valor ofrecido al cliente no solo se aprecia en los resultados
del negocio sino también en la percepción que se tiene de este. En ITIL el valor de
un servicio se asocia a los conceptos de utilidad (o funcionalidad) y garantía. La
funcionalidad es el producto que recibe un cliente. Está relacionado con los
atributos del servicio que repercuten positivamente sobre el rendimiento de
actividades, objetos y tareas. La garantía, en cambio, reside en cómo se

51
proporciona el producto. Se relaciona más con la disponibilidad, fiabilidad,
continuidad y seguridad del servicio.

Figura 1: fases de ITIL v3.

Fuente: http://www.milldesk.cl/2013/10/que-es-itil/#.WdCkt58ypD8

A continuación, viene el diseño del servicio ITIL, el cual se ocupa del

desarrollo y mantenimiento de un catálogo de servicios con los detalles, el estado,
las interacciones y las dependencias de todos los servicios. Parte de los productos
y resultados de la fase anterior y los usa para asegurar que el diseño de solución
elaborado sea consistente con el conjunto de estrategias del proveedor de
servicios de TI.

La siguiente etapa, transición del servicio, tiene la misión de servir como guía
para asegurar que los servicios nuevos, modificados o retirados satisfagan las
expectativas del negocio, tal y como se documenta en las dos etapas anteriores
dentro del ciclo de vida.

52
 A continuación, viene la fase operaciones del servicio, que tiene el fin de que
los servicios sean correctamente prestados y aporten el valor y la utilidad
requeridos, con los niveles de calidad acordados y verificados por todas las partes.

Por último, la fase mejora continua del servicio asegura que los servicios
estén alineados con necesidades cambiantes del negocio. Esto se lleva a cabo por
medio de la identificación e implementación de mejoras en los servicios de TI que
dan soporte a los procesos de negocio. Para ello, se mide constantemente el
desempeño del proveedor de servicios TI con el fin de mejorar la eficiencia, la
efectividad y la rentabilidad del servicio prestado.

2.5. Procesos de las fases del ciclo de vida

Cada una de estas fases se compone de los siguientes procesos:

2.5.1. Estrategia del servicio

◦ Gestión estratégica de los servicios de TI. Es responsable de
definir y mantener la perspectiva, la posición, los planes y los
patrones de una organización con respecto a sus servicios y la
gestión de los mismos.

◦ Gestión del portafolio de servicios. Se encarga de la decisión

de realizar un servicio o no.

◦ Gestión financiera de servicios TI. Gestiona los fondos y

asegura su buena administración.

◦ Gestión de la demanda. Analiza las fuentes de la demanda de

un servicio para identificar sus patrones y, así, poder anticipar e
influir en la demanda.

◦ Gestión de relaciones de negocio. Permite enlazar al proveedor

y al cliente con la estrategia misma.

53
2.5.2. Diseño del servicio
◦ Coordinación del diseño. Es responsable de coordinar todas las
actividades de diseño de servicios, procesos y recursos.

◦ Gestión del catálogo de servicios. Proporciona y mantiene el

catálogo de servicios y asegura la disponibilidad de estos.

◦ Gestión de niveles de servicios. Responsable de negociar

acuerdos de nivel de servicios y de asegurar su cumplimiento.

◦ Gestión de disponibilidad. Proceso responsable de asegurar

que los servicios de TI cumplan con las necesidades actuales y
futuras de disponibilidad del negocio de una manera rentable y
oportuna.

◦ Gestión de capacidad. Proceso responsable de asegurar que la

capacidad de los servicios de TI y la infraestructura de TI puedan
cumplir con los requerimientos acordados.

◦ Gestión de la continuidad de servicios TI. Proceso

responsable de gestionar los riesgos que podría afectar
seriamente los servicios de TI.

◦ Gestión de seguridad de la información. Es el proceso

responsable de asegurar que la confidencialidad, integridad y
disponibilidad de los activos, información, datos y servicios de TI
de una organización satisfagan las necesidades acordadas del
negocio.

◦ Gestión de proveedores. El objetivo es obtener valor por el

dinero pagado a los proveedores, asegurándose que todos los
contratos y acuerdos con proveedores apoyen las necesidades
del negocio y que estos cumplan sus compromisos contractuales.

54
2.5.3. Transición del servicio
Planificación de la transición y soporte. Es el proceso encargado de proveer
planeación para la transición del servicio y coordinar los recursos que sean
requeridos.

Gestión de activos de servicio y configuración. Es el proceso responsable de

asegurar que los activos requeridos para entregar servicios estén debidamente
controlados, y que haya información precisa y confiable sobre estos, además de
asegurarse de que estén activos cuando se necesiten.

Gestión de liberación e implementación. Es el proceso responsable de la

planificación, programación y control de la construcción, prueba e implementación
de liberaciones y de proporcionar nuevas funcionalidades que son requeridas por
el negocio al tiempo que protege la integridad de los servicios existentes.

Validación y pruebas del servicio. Es el proceso responsable de validar y probar

un servicio de TI nuevo o modificado. Este proceso garantiza que el servicio de TI
coincida con la especificación de diseño y satisfaga las necesidades del negocio.

Evaluación del cambio. Proceso genérico que considera si el desempeño es

aceptable, genera valor, es adecuado y si se puede proceder a la implementación.

Gestión del conocimiento. Proceso que asegura que la información correcta sea
entregada en el lugar apropiado o a la persona adecuada en el tiempo correcto
para la toma de decisiones informadas.

Gestión de cambios. Proceso responsable de controlar el ciclo de vida de todos

los cambios, permite que se realicen ajustes beneficiosos que minimicen la
interrupción de servicios de TI.

55
2.5.4. Operación del servicio
Gestión de eventos. Proceso encargado de gestionar eventos a través del ciclo
de vida del servicio. Realiza actividades como detectar eventos, darles sentido y
determinar las acciones de control adecuadas.

Gestión de incidente. Proceso responsable de la gestión del ciclo de vida de

todas las solicitudes de servicio de los usuarios. Asegura que se restablezca la
operación normal de servicio lo antes posible y se minimice el impacto al negocio.

Cumplimiento de solicitudes. Proceso responsable de la gestión del ciclo de

vida de todas las solicitudes de servicio de los usuarios.

Gestión de problemas. Es el proceso responsable de la gestión del ciclo de vida

de todos los problemas.

Gestión de acceso. Es el proceso responsable de permitir que los usuarios hagan

uso de los servicios de TI, datos u otros activos. Ayuda a proteger la
confidencialidad, integridad y disponibilidad de los activos, garantizando que solo
los usuarios autorizados pueden acceder a ellos o modificarlos.

2.5.5. Mejora continua del servicio

Proceso de mejora en 7 pasos. Es el proceso responsable de identificar e

implementar mejoras mediante la medición continua del desempeño del proveedor
de servicios TI.

Las funciones, en cambio, están asociadas a la etapa de operación del servicio y

son las siguientes:

56
Service Desk. Es el único punto de contacto entre el proveedor de servicios y el
usuario. Realiza tareas del tipo manejar incidentes, solicitudes de servicio y de
comunicación con los usuarios.

Gestión técnica. Es la función responsable de proporcionar las habilidades

técnicas y recursos necesarios para dar soporte a la fase de operación de servicio.

Gestión de aplicaciones. Es la responsable de gestionar el soporte y

mantenimiento de las aplicaciones a lo largo de su ciclo de vida.

Gestión de operaciones TI. Es la unidad responsable de las actividades diarias

necesarias para gestionar los servicios TI y dar soporte a la infraestructura de TI.

A continuación, presentamos en la figura 2 un cuadro resumen con los procesos y

funciones implicados en las distintas fases del ciclo de vida de los servicios TI.

Figura 2: procesos y funciones de las distintas fases del ciclo de vida de los servicios TI.
Fuente: Pultorack, s. f. recuperado de: https://cdn.shopify.com/s/files/1/1062/8666/files/ITIL-2011-
Lifecycle-Processes-Functions-Wallpaper-1280x800.jpg?9564622448967946673

57
2.6. Ejemplos
Un servicio de gestión de incidencias es un proceso para acceder, grabar y
resolver incidencias. El propósito de este proceso es poder restaurar el servicio al
cliente lo más rápido posible.

Un incidente ocurre debido a un error o fallo que afecta a un usuario de manera

inmediata. Por ejemplo: un mensaje de error al intentar acceder a una aplicación.
Esto quiere decir que el servicio no está disponible (y aunque pueda haber
diversas causas el usuario no es capaz de determinarla), un fallo (bug) de la
aplicación, un dispositivo (escáner, impresora, etc.) no funciona, etc.

Los objetivos que se persiguen en este proceso son:

- Asegurar que todas las acciones (respuesta, análisis, documentación,

información y gestión) asociadas a los incidentes usen métodos y
procedimientos estandarizados que repercutan positivamente en la eficacia
de dichas acciones.
- Mejorar la visibilidad y comunicación de incidentes.
- Mejorar la percepción del negocio de TI.
- Alinear la gestión de incidentes y las prioridades con el negocio.
- Mantener la satisfacción del usuario con la calidad de servicios TI.

Este proceso incluye todo evento que interrumpa o que podría interrumpir un
servicio. Para gestionar los incidentes es necesario saber las actividades
asociadas a este proceso, las cuales son:

 Identificar el incidente.
 Registrar el incidente.
 Clasificar el incidente.
 Priorizar el incidente.
 Diagnóstico inicial.

58
  Escalar el incidente.
 Investigar y diagnosticar.
 Resolver y recuperar.
 Cerrar incidente.

La figura 3 muestra el diagrama de la gestión de incidentes. Como puede verse,

un incidente puede reportarse por diversos medios: interfaz web, por teléfono, por
correo electrónico o mediante una herramienta específica de gestión de eventos.
Posteriormente, siguen una serie de etapas relativas a la identificación, registro,
clasificación y priorización del incidente. Este punto es crítico para designar si
dicho incidente es o no grave, pues en el primer caso requeriría una actuación que
evite o minimice la interrupción severa que provocaría en el negocio. En caso de
que no sea grave el tratamiento incluye las siguientes consideraciones:

- Pasos que deben tomarse para manejar el incidente.

- Orden cronológico en que deben ejecutarse con cualquier dependencia.
- Asignación de responsabilidades.
- Precauciones a tener en cuenta antes de resolver el incidente.
- Escalas de tiempo y umbrales para la terminación de acciones.
- Procedimientos de escalamiento: quién debe ser contactado y cuándo.
- Actividades de preservación de evidencia (particularmente relevante para
seguridad y capacidad).

En este punto es importante el escalamiento, que no es más que la dotación de

recursos extras para reestablecer el servicio con las expectativas del cliente. Estos
escalamientos pueden ser funcionales, de modo que consiste en la transferencia
de un incidente a un equipo técnico especializado, o jerárquico, que no es más
que informar a los altos cargos en la gerencia del incidente para facilitar la
búsqueda de recursos extras. Tras esto, si se sabe resolver la dificultad, se
procede con ello o se vuelve al escalamiento.

59
Finalmente, cabe destacar los roles y responsabilidades de este proceso:

- Llevar a cabo el rol de gerente de proceso para la gestión del incidente.

- Planear y gestionar el soporte para los procesos y herramientas de gestión
del incidente.
- Coordinar las relaciones entre la gestión del incidente y los demás procesos
de gestión del servicio.
- Manejar el proceso de gestión del incidente de forma efectiva y eficiente.
- Producir información relevante para la gestión del incidente.
- Administrar el trabajo del personal de soporte de incidentes de primera y
segunda línea.
- Monitorizar la efectividad del proceso de la gestión del incidente y hacer
recomendaciones de mejora.
- Desarrollar y mantener sistemas de gestión del incidente, procesos y
procedimientos.
- Manejar incidentes graves.
- Desarrollar y mantener procedimientos y el proceso de gestión del
incidente.

60
Figura 3: Diagrama de la gestión de incidentes.

61
2.7. Ejercicios de reflexión

1. Considerando un sistema de gestión de incidentes, ¿qué conjunto de métricas

serían adecuadas reportar?

- Número total de incidencias.

- Desglose de los incidentes en cada etapa (por ejemplo, en espera, trabajo
en progreso, cerrado, etc.).
- Volumen de incidentes con retraso.
- Número y porcentaje de incidentes graves.
- Tiempo promedio para resolver un incidente.
- Porcentaje de incidentes resueltos satisfactoriamente dentro de los límites
de tiempo considerados adecuados según los estándares.
- Número de incidentes abiertos tras ser cerrados así como su valor en
porcentaje relativo al total de incidencias.
- Número y porcentaje de incidentes incorrectamente asignados.
- Número y porcentaje de incidentes incorrectamente categorizados.
- Porcentaje de incidencias cerradas por el Service Desk sin referencia a
otros niveles de apoyo.
- Número y porcentaje de incidentes procesados por un agente del Service
Desk.

2. Dar un listado indicando las ventajas e inconvenientes de ITIL

Ventajas
 La organización TI desarrolla una estructura más clara, se vuelve
más eficaz, y se centra en los objetivos de la organización.
 La estructura de ITIL es más sencilla que la de otros marcos de
referencia.

62
  La administración tiene un mayor control, se estandarizan e
identifican los procedimientos, y los cambios resultan más fáciles de
manejar.
 La estructura de procesos en TI proporciona un marco para concretar
de manera más adecuada los servicios de outsourcing.
 A través de las mejores prácticas de ITIL se apoya al cambio de la
cultura de TI y su orientación hacia el servicio, y se facilita la
introducción de un sistema de administración de calidad.
 ITIL proporciona un marco de referencia uniforme para la
comunicación interna y con proveedores.

Inconvenientes
 Tiempo y esfuerzo necesario para su implementación.
 Falta de comprensión o conocimiento sobre la adopción de ITIL.
 Que no se dé el cambio en la cultura de las áreas involucradas.
 Que no se vea reflejada una mejora por falta de entendimiento sobre
procesos, indicadores y cómo pueden ser controlados.
 Que el personal no se involucre y se comprometa.
 La mejora del servicio y la reducción de costos no sea visible.
 Que la inversión en herramientas de soporte sea escasa. Los
procesos podrán parecer inútiles y no se alcanzan las mejoras en los
servicios.

63
64
 CAPÍTULO III

Metodologías de Desarrollo de Software

En este capítulo se abordarán distintas metodologías de desarrollo de software

que han demostrado ser un marco de trabajo esencial para poder estructurar,
planificar y controlar el proceso de desarrollo en sistemas de información.
Inicialmente comenzaremos dando una visión general de las distintas
metodologías de desarrollo para, a continuación, centrarnos en las metodologías
ágiles. Este tipo de metodologías, debido a su naturaleza iterativa e incremental
supuso una optimización de los recursos. A pesar de los inconvenientes que
también tiene, es el tipo de metodología de desarrollo más extendido en la
actualidad.

Existen diversas propuestas de métodos ágiles de desarrollo. En la siguiente

sección veremos el marco de desarrollo ágil más extendido: Scrum. Este marco
fue introducido por Ikujiro Nonaka e Hirotaka Takeuchi a principio de los años 80,
al analizar cómo las principales empresas tecnológicas desarrollaban los nuevos
productos.

En las siguientes secciones se abordará la metodología XP. Con esto se

pretender dar un panorama general de las distintas metodologías ágiles
propuestas y que son de utilidad en la actualidad.

65
3.1. Metodologías para el Desarrollo de Software
3.1.1. Introducción
El desarrollo de software es un marco de trabajo para la gestión de proyectos
de software que asegura la consecución de unos hitos, así como la calidad del
producto desarrollado. Tiene como principal objetivo la producción eficaz y
eficiente de un producto de software que reúna los requisitos del cliente.

El proceso de desarrollo de software es equiparable a cualquier otro proyecto

en ingeniería. Sin embargo, este tiene una serie de desafíos relativos a la
naturaleza del producto.

Una cuestión importante es que un producto de software, aun siendo de

pequeño tamaño, puede contener una serie de errores debido a la imposibilidad
de poder verificar todas las posibles situaciones de ejecución que puedan
presentarse. Además, un producto de software es intangible, lo que dificulta tanto
su definición como la de los requisitos. Es, por tanto, habitual que los requisitos
definidos deban modificarse. Por último, se destaca que no existe una única forma
de desarrollar un producto de software de forma efectiva y eficiente. Debido a
esto, es difícil automatizar todo el proceso de desarrollo de software.

3.1.2. Marco Conceptual

Un sistema informático está compuesto de hardware y software. Si bien el
proceso de producción de hardware está bien definido, en lo referente al software,
tanto su construcción como los productos obtenidos han sido cuestionados debido
a diversos problemas. Algunos de estos problemas, tal y como señala Pressman
(1997), son:

 El coste asociado a la construcción, mejoramiento y mantenimiento son

difíciles de estimar.

66
  Los sistemas no responden a las expectativas de los usuarios.
 Las aplicaciones suelen contener errores.
 Los cambios en el hardware suelen afectar al software.
 Es muy difícil hacer un aprovechamiento óptimo de los recursos.

Estas dificultades derivaron en lo que se pasó a llamar la crisis del software, el

cual abarcó desde la década de los 60 hasta la década de los 80 del siglo XX.
Esto ayudó a establecer y usar principios de la ingeniería orientados a obtener
software eficaz, eficiente y de forma económica. Posteriormente, se consideró la
inclusión de otros aspectos como las métricas asociadas a la calidad del software,
satisfacción del cliente, etc.

Pressman (1997) caracteriza la ingeniería del software como una tecnología

multicapa. La figura 1 muestra las distintas capas que considera:

 Calidad. Cualquier disciplina de la ingeniería del software debe estar

fundamentada en la calidad que permita incluir continuas mejoras en el proceso de
desarrollo del producto.
 Proceso. Define un marco de trabajo aplicable a un conjunto de áreas
claves para entregar un producto software de calidad. Define los contextos para
construir dicho producto.
 Métodos. Esta capa se refiere a cómo construir, desde un punto de vista
técnico, un producto de software. Incluye tareas de distinta índole como el análisis
de requisitos, diseño, construcción de programas, pruebas y mantenimiento.
 Herramientas. Proporciona un soporte automático o semiautomático para
el proceso y los métodos.

67
Figura 4: capas de la ingeniería del software.
Fuente: http://sosagas.blogspot.com.es/2011/09/capas-de-la-ingenieria-de-software.html

3.1.2.1. Proceso de Desarrollo de Software

El proceso de desarrollo de software es un procedimiento intensamente
intelectual, afectado por la creatividad y juicio de las personas implicadas que
tiene como objetivo producir, de forma eficaz y eficiente, un producto de software
atendiendo a los requisitos del cliente.

Un producto de software es intangible y muy abstracto; de modo que dificulta la

definición del producto y sus requisitos. Esto sumado a la dificultad de conseguir
un desarrollo confiable 100 % por la gran cantidad de factores que intervienen
(entradas, valores de variables, datos almacenados, etc.), dan indicio de la
complejidad del propio producto de software.

Otra dificultad asociada es la inmadurez de la disciplina de la ingeniería del

software, la cual hace que estemos en proceso de definición de distintos procesos
de software en función del contexto del proyecto. A pesar de esta heterogeneidad,
un proceso de desarrollo de software tiene una serie de actividades fundamentales
asociadas que están siempre presentes. Estas actividades son:

 Especificación de software. Define la funcionalidad y las

restricciones que debe cumplir el software.

68
  Diseño e implementación. Abarca el diseño y construcción del
software de acuerdo a la especificación.
 Validación. Conlleva el conjunto de actividades asociadas a la
validación del software desarrollado para que cumpla con las
expectativas del cliente.
 Evolución. El software ha de ir modificándose para adaptarse a las
necesidades del cliente.

Además de estas actividades, Pressman (1997) menciona otro conjunto de

actividades de protección que deben aplicarse durante todo el proceso del
software:
 Seguimiento y control de proyecto de software.
 Revisiones técnicas formales.
 Garantía de calidad del software.
 Gestión de configuración del software.
 Preparación y producción de documentos.
 Gestión de reutilización.
 Mediciones.
 Gestión de riesgos.

Según Pressman (1997), los elementos de un proceso de desarrollo de software

son:
 Un marco común del proceso. Es el conjunto de actividades que
son aplicables a todos los proyectos de software, con independencia
del tamaño y la complejidad.
 Un conjunto de tareas. Cada actividad de trabajo del proceso
común es una colección de tareas que hacen que el marco de
trabajo se adapte a las características particulares del proyecto de
software y los requisitos del equipo del proyecto. Abarca un conjunto
de tareas de ingeniería del software, hitos de proyectos, entregas y
productos de trabajo del software y puntos de garantía de calidad.

69
  Las actividades de protección. Son un conjunto de actividades
independientes de cualquier actividad del marco de trabajo y
aparecen durante todo el proceso. El objetivo es la gestión, el rastreo
y el control del proyecto para garantizar la calidad del software.

La figura 2 muestra los elementos del proceso de software según lo que

acabamos de ver.

Figura 5: elementos del proceso del software.

Fuente: http://users.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc

También puede verse los elementos de un proceso de desarrollo de software

mediante el establecimiento de sus relaciones, respondiendo a quién debe hacer,
qué, cuándo y cómo debe hacerlo. Para ello hay que introducir el concepto de
artefacto, el cual es una pieza de información que es producida, modificada o
usada por un rol en una de sus actividades. Un artefacto puede ser un modelo, un
elemento de un modelo o un documento. Las preguntas anteriores se responden
del siguiente modo:

70
  Quién: las personas participantes en el proyecto de desarrollo
desempeñan uno o más roles específicos.
 Qué: los artefactos se especifican utilizando notaciones específicas.
Las herramientas apoyan la elaboración de artefactos y soportan
ciertas notaciones.
 Cómo y cuándo: las actividades son una serie de pasos que llevan
a cabo un rol durante el proceso de desarrollo. El avance del
proyecto está controlado mediante hitos que establecen un
determinado estado de terminación de ciertos artefactos.

3.1.2.2. Modelos de Proceso de Software

Un modelo de proceso de software, según Sommerville (2002), puede definirse
como “Una representación simplificada de un proceso de software, que está
representada desde una perspectiva específica. Por su naturaleza, los modelos
son simplificados; por lo tanto, un modelo de procesos de software es una
abstracción de un proceso real.”
Existen una serie de modelos genéricos de desarrollo de software que, si bien no
son descripciones de procesos de software, pueden ser de utilidad para explicar
distintos enfoques del desarrollo de software. Algunos de estos modelos son:

 Codificar y corregir. Este es el modelo usado en los inicios del desarrollo de

software. Tiene dos pasos fundamentales:

◦ Escribir código.

◦ Corregir errores del código.

En este modelo se empieza implementando algo y, a continuación, se va

pensando acerca de los requisitos, diseño, validación y mantenimiento. Algunos
de los principales problemas que presenta este modelo son:

◦ Mala estructuración del código tras diversas correcciones.

71
 ◦ Código difícil y costoso de mantener.

 Modelo en cascada. Se caracteriza por tomar las actividades

fundamentales del proceso de especificación, desarrollo, validación y
evolución y las representa como fases separadas del proceso.
Consta de las siguientes fases:

◦ Definición de los requisitos. Enfocado en comprender el

dominio de información del software como los servicios, las
restricciones y objetivos establecidos con los usuarios del
sistema.

◦ Diseño de software. Descompone y organiza el sistema en

elementos. Establece la arquitectura del sistema y también
identifica y describe las abstracciones y relaciones de los
componentes del sistema.

◦ Implementación y pruebas unitarias. Creación del código. Se

realizan las pruebas de cada módulo desarrollado.

◦ Integración y pruebas del sistema. Se integran todos los

módulos y se prueba su funcionamiento en conjunto.

◦ Operación y mantenimiento. Consiste en la puesta en marcha

del sistema y se realizan correcciones y actualizaciones. También
se pueden identificar nuevos requisitos.

La interacción entre las distintas fases puede consultarse en la figura 3. Una fase
no comienza hasta que termina la anterior. En la práctica este modelo requiere de
varias iteraciones así como de la interacción entre las distintas fases de desarrollo.

72
Figura 6: modelo de desarrollo en cascada.
Fuente: http://users.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc

Algunos de los problemas que presenta este modelo son:

◦ Las iteraciones son costosas.

◦ Las iteraciones requieren rehacer trabajo debido a la producción y

aprobación de los documentos tras cada fase.

◦ Existe una alta probabilidad de que el software no cumpla con los requisitos
del usuario por el largo tiempo de entrega del producto.

 Desarrollo en espiral. Este modelo fue introducido por Boehm

(1988) y es uno de los más populares por introducir un análisis de
riesgo iterativo. Esto es especialmente adecuado en proyectos de
sistemas complejos de gran escala.

Cada vuelta de ciclo se compone de cuatro fases, ocupando cada una de estas
fases un cuadrante:

◦ Definición de objetivos. Fase de definición de objetivos, de restricciones del

proceso y del producto en cada iteración. Se identifican los riesgos.

73
◦ Evaluación y reducción de riesgos. Se analizan en detalle los riesgos, se
evalúan alternativas y se enfoca en la resolución de estos riesgos.

◦ Desarrollo y validación. Se escoge el modelo de desarrollo tras la evaluación

del riesgo y se desarrollan y verifican las entregas de cada iteración.

◦ Planificación. En esta fase se determina si se ha de continuar con otra

iteración y se planifica en caso afirmativo.

La figura 4 muestra un esquema de desarrollo en espiral.

Figura 7: modelo de desarrollo en espiral.

Fuente: https://en.wikipedia.org/wiki/Spiral_model

3.1.3. Metodologías para el Desarrollo de Software

Las metodologías hacen referencia a un proceso de software detallado y
completo y se basan en una combinación de modelos de proceso genéricos visto
anteriormente. La metodología, además, debe definir con precisión los artefactos,
los roles y actividades así como el conjunto de prácticas y técnicas recomendadas,
guías de adaptación de la metodología al proyecto, etc.

74
 No existe una clasificación única de los distintos tipos de metodología sino que
dependerá del criterio que se utilice. Si consideramos como criterio las notaciones
usadas para especificar artefactos producidos en actividades de análisis y diseño,
podemos clasificar las metodologías en dos grupos:

 Metodologías estructuradas. Se basan en el modelo básico

entrada/proceso/salida en el que los datos entran al sistema, son manipulados y
dan lugar a una salida.
 Metodologías orientadas a objetos. Son metodologías asociadas a los
lenguajes orientados a objetos.

Si consideramos como criterio la filosofía de desarrollo encontraremos los

siguientes grupos:

 Metodologías tradicionales o pesadas. Son aquellas que están

orientadas hacia una fuerte planificación durante todo el proceso de desarrollo. En
este caso se hace mucho énfasis en las etapas de análisis y diseño antes de la
construcción del sistema.
 Metodologías ágiles. Orientados a un desarrollo de software incremental,
cooperativo, sencillo y adaptable a cambios que puedan presentarse durante la
etapa de desarrollo.

Algunas de las características que se buscan de la metodología son:

 Facilitar la comunicación entre las personas involucradas.
 Mantener el control durante desarrollo del sistema que se desarrolla.
 Facilitar la gestión y seguimiento de proyectos.
 Definir las restricciones del sistema.
 Validación y verificación de toda la documentación generada.

75
3.1.4. Metodologías Ágiles
En el proceso de desarrollo de software se hacía un especial énfasis en el
control del proceso mediante una definición de roles, actividades y artefactos,
incluyendo modelado y documentación. Este esquema, que ha demostrado ser
efectivo en proyectos de gran tamaño, ha dejado de ser efectivo en muchos
proyectos actuales debido a lo cambiante del entorno del sistema. En este
contexto, surgen las metodologías ágiles como posible respuesta a esta
necesidad, pues aportan una simplificación del proceso de desarrollo y mantiene
la calidad del producto.

En torno a las metodologías ágiles se creó la organización The Agile Alliance, la

cual está dedicada a promover los conceptos relacionados con el desarrollo ágil
de software y ayudar a las organizaciones para que adopten dicha metodología. A
pesar de que hay un debate entre aquellos que apoyan las metodologías
tradicionales, el fuerte apoyo de esta metodología hace prever una fuerte
proyección industrial.

El punto de partida es un manifiesto que resume la filosofía de esta

metodología. Este enumera los principales valores del desarrollo ágil. Algunos de
estos valores son:

 Mayor énfasis en el individuo y en las interacciones del equipo de desarrollo

que en el proceso y las herramientas.
 Búsqueda del desarrollo de un software funcional por encima de una
documentación exhaustiva.
 Fluidez y mayor enfoque en la interacción entre el cliente y el equipo de
desarrollo en vez de centrarse en la negociación contractual.
 Flexibilidad ante los cambios que vayan surgiendo en vez de ceñirse de
forma rígida al plan inicial.

76
 Estos valores dan pie a los doce principios del manifiesto, los cuales marcan la
diferencia con respecto a la metodología tradicional. Algunas de las metodologías
ágiles que podemos encontrar son:

 SCRUM
 Crystal Methodologies
 Dynamic Systems Development Method
 Adaptive Software Development
 Feature-Driven Development
 Lean Development
 eXtreme Programming (XP)

3.1.4.1. eXtreme Programming (XP)

XP es una metodología ágil que promueve el trabajo en equipo y se preocupa
por el aprendizaje de los desarrolladores; así como también de que haya un buen
ambiente de trabajo. Es una metodología adecuada para equipos de trabajo
pequeños y proyectos con requisitos imprecisos y en los que hay un alto riesgo de
cambios.

3.1.4.1.1. Valores
XP se basa en los siguientes valores:
 Comunicación fluida entre los miembros del equipo y con el cliente.
 Simplicidad en la búsqueda de soluciones. Siempre se eligen las
soluciones más simples que se adecuen a las exigencias del cliente.
 Retroalimentación continua del cliente para que los desarrolladores
puedan dirigir el proyecto adecuadamente.
 Valentía para llevar a cabo los cambios que vayan siendo necesarios
aplicar.
 Respeto en el trato entre los miembros integrantes del proyecto de
modo que no quieran hacerse decisiones repentinas.

77
3.1.4.1.2. Roles
Los roles de acuerdo con la propuesta original de Beck (1999) son:
 Programador. Es el encargado de implementar el código del sistema
y escribir las pruebas unitarias.
 Cliente. Es un interlocutor que puede representar a una o varias
personas. Se encarga de describir el sistema así como las
prioridades de los distintos componentes.
 Encargado de pruebas (Tester). Es el encargado de ayudar al cliente
a escribir las pruebas funcionales. También ejecuta las pruebas y
difunde los resultados.
 Encargado de seguimiento (Tracker). Es el encargado de seguir y
verificar el grado de cumplimiento de los objetivos marcados tanto a
nivel de tiempo como de recursos.
 Entrenador (Coach). Es el responsable del proceso global. Sirve de
guía a los miembros del equipo para que apliquen las prácticas XP
adecuadamente.
 Consultor. Es un miembro externo del equipo que guía al equipo para
resolver un problema específico.
 Gestor (Big boss). Es el vínculo entre el cliente y el equipo. Su
principal trabajo es el de coordinar para que el equipo trabaje en las
mejores condiciones.

3.1.4.1.3. Modelo
La metodología XP define cuatro variables para cualquier proyecto de software:
costo, tiempo, calidad y alcance. Tres de estas variables pueden ser establecidas
por actores externos al equipo de desarrollo, mientras que la cuarta la establecerá
el equipo de desarrollo en función de las otras variables. Por ejemplo, si el cliente
establece el alcance y la calidad, y el jefe del proyecto el costo, el equipo de
desarrollo determinará el tiempo de desarrollo necesario.

78
El desarrollo se organiza en torno a ciclos cortos denominados iteraciones, que
tienen asociados una serie de entregables al finalizar cada una de ellas. En cada
iteración se lleva a cabo un ciclo completo de análisis, diseño, desarrollo y
pruebas adecuadas a las reglas y prácticas que caracterizan a XP.

La figura 5 muestra un esquema comparativo de las iteraciones entre los modelos

en cascada, iterativo y la metodología XP que combina los dos anteriores. Un
proyecto típico con XP suele tener entre 10 y 15 iteraciones.

Figura 8: comparación de las iteraciones en los desarrollo en cascada (a), en el iterativo (b) y en
XP (c).
Fuente: http://www.runayupay.org/publicaciones/2244_555_COD_18_290814203015.pdf

3.1.4.1.4. Proceso
A grandes rasgos el ciclo de desarrollo consiste en los siguientes pasos:

 El cliente define el valor de negocio a implementar.

 El programador estima el esfuerzo necesario para su
implementación.
 El cliente prioriza los distintos módulos con base en las restricciones
temporales.
 El programador construye ese valor de negocio.
 Vuelve al paso 1.

79
El ciclo de vida ideal se compone de seis fases:

 Exploración. Es una fase que toma de pocas semanas a pocos

meses en función del tamaño del proyecto y de la familiaridad del
equipo con la tecnología. Los clientes plantean las historias de los
usuarios de interés para la primera entrega del producto. El equipo
se familiariza con las herramientas, tecnologías y prácticas que se
usarán en el proyecto.
 Planificación de la entrega. Es una fase breve que dura unos días, en
la que el cliente establece las prioridades de cada historia de usuario.
Los programadores, por su parte, estiman el esfuerzo necesario para
cada una de ellas y lo plasman en un cronograma. La planificación
suele realizarse con base en unidades que representan una semana
de trabajo. Cada historia suele tener entre una y tres semanas.
 Iteraciones. En esta etapa se planifican las entregas de cada
iteración que no debe durar más de tres semanas cada una. En la
primera iteración se intenta establecer la arquitectura del producto y
en la última, el sistema debe estar listo para entrar en producción.
 Producción. Se toman decisiones sobre la inclusión de nuevas
características propiciadas por los posibles cambios. Las ideas
propuestas y las sugerencias son documentadas para su posterior
implementación.
 Mantenimiento. Mientras la primera versión se encuentra en
producción, el proyecto XP debe mantener el sistema en
funcionamiento al mismo tiempo que desarrolla nuevas iteraciones.
 Muerte del proyecto. Se da cuando el cliente no tiene más historias
para ser incluidas en el sistema. Se genera una documentación final
del sistema y no se realizan más cambios en la arquitectura.
También podría ocurrir que terminara debido a que el sistema, tal y
como lo planteó el cliente, no genera los beneficios esperados por
este o no hay presupuesto para mantenerlos.

80
3.1.4.1.5. Reglas y prácticas
La aplicación con éxito de la metodología XP requiere del cumplimiento de un
conjunto importante de reglas y prácticas. A continuación, pasamos a describir
algunas de estas:
 Planificación. Hay dos actores principales: el cliente y el programador. El
primero establece las historias de cada usuario y su prioridad, mientras que el
programador establece el esfuerzo asociado a cada historia. Se ordenan las
historias en función de la prioridad y el esfuerzo, y se define el contenido de cada
iteración. Esto se realiza durante la planificación de la entrega, en la planificación
de cada iteración y en cualquier momento que sea necesario.
 Entregas. La idea que subyace es que haya entregas de versiones
operativas aunque no cuenten con todas las funcionalidades pero que tengan un
cierto valor para el negocio.
 Simplicidad del diseño. Se debe diseñar la solución más simple que pueda
funcionar y ser implementada.
 Pruebas. Las pruebas unitarias son establecidas antes de escribir el código.
Para ello, los clientes establecen las pruebas funcionales para cada historia de
usuario.
 Refactorización. El código se reestructura constantemente con el objetivo
de eliminar código duplicado, mejorar su legibilidad, simplificarlo y hacerlo más
flexible para facilitar futuros cambios.
 Propiedad colectiva del código. Cualquier programador puede contribuir en
la mejora o modificación del código para evitar que alguno de ellos sea
imprescindible.
 Integración continua. En cada momento en que un módulo es terminado se
pasa a su integración en el sistema. Para ello hay que planificar y automatizar el
conjunto de pruebas necesarias para que el código sea integrado en el sistema
una vez supere con éxito dichas pruebas.

81
  Estándares de programación. Se motiva el uso de estándares de
programación que permitan mantener un código legible para los miembros del
equipo.

Si bien es verdad que el conjunto de prácticas planteadas por XP no son

novedosas y ya se aplican en distintos ámbitos de la ingeniería del software, el
mérito de XP es haberlas integrado de una forma efectiva y complementarlas con
otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en
equipo.

3.1.4.2. Scrum
Scrum nace en 1986 de la mano de Takecuchi y Nonaka en 1986 para gestionar
proyectos en los que la agilidad, flexibilidad y las incertidumbres son elementos
fundamentales en torno al proyecto. Posteriormente, en 1993 Sutherland lo aplica
al modelo de desarrollo de software. Esta metodología está formada por un
conjunto de prácticas y reglas para poder emprender proyectos complejos
adaptativos. Da respuesta a los siguientes principios de desarrollo ágil:
 Gestión evolutiva del producto.
 Calidad del resultado basado en el conocimiento de cada miembro
del equipo, antes que en el explícito de los procesos y la tecnología
empleada.
 Estrategia de desarrollo incremental a través de iteraciones (sprints).

3.1.4.2.1. Valores
La metodología Scrum se sirve de unos valores que ayudan a obtener el éxito. La
figura 6 muestra un diagrama con estos valores, los cuales pasamos a describir a
continuación:

82
  Foco. Las distintas tareas de un proyecto pueden ser muy variadas.
Los equipos han de estar unidos con un foco en común para crear
cohesión.
 Coraje. Los recursos y los datos son compartidos de modo que
ninguno se sienta aislado. Con el apoyo y el soporte del grupo se
hace posible la innovación.
 Apertura. La transparencia y la compartición de datos permite una
mayor eficiencia en la respuesta a las necesidades que van
surgiendo así como a la reestructuración de procesos.
 Compromiso. Los miembros del equipo aumentan su compromiso si
pueden encauzar su propio éxito mediante la consecución de los
objetivos de su parte dentro del todo que es el proyecto.
 Respeto. Al trabajar en equipo y compartir información, es
fundamental el respeto hacia los demás y los procesos compartidos
para obtener los resultados esperados.

Figura 9: valores de la metodología Scrum.

Fuente: http://www.gazafatonarioit.com/2016/07/revision-la-guia-de-scrum.html

3.1.4.2.2. Roles
En Scrum se diferencian dos tipos de roles fundamentales:
 Roles principales. Son aquellas personas o roles comprometidos con el
proyecto y el proceso Scrum.

83
 ◦ Dueño del producto (Product owner). Es una única persona responsable
de gestionar la lista del producto (Product Backlog). Conoce el negocio
del cliente y tiene visión del producto. Se encarga de escribir las ideas
del cliente, ordenarlas en función de la prioridad y colocarlas en la lista
del producto de forma visible, clara y transparente para todos.

◦ Equipo de desarrollo (Development team). Es un grupo pequeño de entre

5-9 personas. Son los encargados de organizar y tomar decisiones sobre
su propio trabajo. Está involucrado en le estimación del esfuerzo de las
tareas de la lista del producto.

◦ Facilitador (Scrum master). Es el encargado de verificar que el modelo y

la metodología funcionan. Interactúa con el cliente y los gestores para
que el trabajo se realice de forma fluida y sin inconvenientes.
 Roles auxiliares. Aquellas personas o roles que no son parte del proceso
Scrum.

◦ Usuario. Es el destinatario final del producto.

◦ Stakeholder. Representa a la persona o grupo de personas a las que el

proyecto les producirá un beneficio. Participan durante las revisiones de
las iteraciones.

◦ Manager. Toma las decisiones finales participando en la selección de

los objetivos y los requisitos.

3.1.4.2.3. Proceso
En Scrum se denomina sprint a la unidad básica de trabajo para un equipo, y
consiste en una simple iteración de modo que a su finalización se tiene que
proporcionar un resultado completo, un incremento del producto final. El tiempo
mínimo de un sprint es de una semana y el máximo es de 4.

El proceso de desarrollo se divide en eventos y artefactos. Los eventos sirven

para crear regularidad y minimizar la necesidad de reuniones no definidas. Los

84
eventos tienen una duración máxima. De esta forma, un sprint puede considerarse
como un contenedor de eventos. A continuación pasamos a describir los eventos:

 Planificación de sprint (Sprint planning). En esta etapa se planifica el trabajo

a realizar durante el sprint. Para ello, se recurre al equipo completo que lo lleva a
cabo de forma colaborativa. El facilitador se asegura de que el evento se lleve a
cabo. La planificación responde a estas dos preguntas:

◦ ¿Qué puede entregarse en el incremento resultante del sprint que

comienza?

◦ ¿Cómo se conseguirá hacer el trabajo necesario para entregar el

incremento?

 Objetivos del sprint (Sprint goals). Es la meta considerada para el sprint que
puede lograrse mediante la implementación de la lista de producto. Se crea
durante la planificación del sprint.

 Scrum diario (Daily Scrum). Es una reunión de un bloque de tiempo de 15

minutos para que el equipo de desarrollo sincronice sus actividades y cree un plan
para las siguientes 24 horas. Esto se lleva a cabo inspeccionando el trabajo
avanzado desde el último Scrum diario y haciendo una proyección acerca del
trabajo que podría completarse antes del siguiente. El facilitador se asegura que
se lleven a cabo estas reuniones aunque la responsabilidad de dirigirla es del
propio equipo.

 Revisión de sprint (Sprint review). Es una reunión que se lleva a cabo al

final del Sprint para revisar el incremento del producto llevado a cabo y adaptar la
lista de producto si es necesario. Es una reunión informal en el que el objetivo es
facilitar la retroalimentación de la información y fomentar la colaboración.

 Retrospectiva de sprint (Sprint retrospective). Es una reunión que se lleva a

cabo tras la revisión del sprint y antes de la planificación del siguiente sprint. El

85
dueño del producto se reúne con el equipo y el facilitador para hablar de lo
ocurrido en el pasado sprint. El objetivo es revisar lo que se hizo y crear un plan
de mejoras que sean abordadas en el siguiente sprint. Los puntos principales a
tratar son:

◦ Qué se hizo mal para mejorarlo en el siguiente sprint.

◦ Qué se hizo bien para seguir en la misma senda.

◦ Qué inconvenientes se encontraron y perjudicaron la planificación.

Los artefactos, en cambio, representan trabajo o valor en diversas formas y

están diseñados específicamente para maximizar la transparencia de la
información clave, necesaria para asegurar que todos tengan el mismo
entendimiento del artefacto.

 Lista o pila de producto (Product backlog). Es la lista de necesidades del

cliente. Es un inventario en el que se almacenan todas las funcionalidades o
requisitos en forma de lista priorizada.

La lista es creada y gestionada por el cliente con ayuda del facilitador, quien
indicará el coste estimado para completar un requisito. Las principales
característica de esta lista son:

◦ Contiene los objetivos del producto.

◦ En cada objetivo se indica el valor asignado por el cliente y el coste

estimado.

◦ Se indican las posibles iteraciones y las publicaciones indicadas al

cliente.

◦ Ha de incluir los posibles riesgos así como las tareas necesarias para
solventarlos.

86
  Lista o pila de pendientes del sprint (Sprint backlog). Es la lista de tareas
correspondientes a un sprint y se elabora por el equipo durante la planificación de
un sprint. Se asignan las tareas a las personas y el tiempo que queda para
terminarlas. Se caracterizar por:

◦ Ser una lista ordenada de prioridades para el cliente.

◦ Por la posibilidad de haber dependencias entre tareas.

◦ Las tareas tienen un coste temporal similar de entre 4-16 horas.

El diagrama del ciclo de vida de un proyecto que se aborda mediante Scrum

puede verse en la figura 7. El proceso parte de la lista del producto priorizada, que
actúa como plan del proyecto. Para la elaboración de dicha lista han participado
diversos roles a partir de las opiniones de los usuarios. Estas historias de usuario
son divididas en tareas y son plasmadas en el documento Lista de producto
(Product Backlog), por el dueño del producto en asociación con el cliente, quien
otorga prioridad a dichas tareas.

Figura 10: ciclo de vida de un proyecto Scrum.

Fuente: http://www.softwareplant.com/scrum/

87
 A continuación, se lleva a cabo la reunión de planificación de sprint para dividir
las tareas en iteraciones (sprints). De modo que cada iteración contendrá una
serie de tareas asociadas. Esto se plasma en el documento denominado Lista de
pendientes de sprint (Sprint Backlog) y es responsabilidad exclusiva del equipo de
desarrollo.

En este momento empiezan las iteraciones en las que los distintos miembros
del equipo llevan a cabo trabajos de desarrollo y prueba. En esta etapa se llevan a
cabo reuniones diarias (Daily Scrum Meeting).

Al finalizar la iteración, el equipo lleva a cabo la revisión y retrospectiva del

sprint terminado. Tras esto se considera que se ha finalizado el trabajo del sprint.

3.1.5. Ejemplos
Caso práctico de uso de la metodología Scrum
Consideremos que un cliente se pone en contacto con una empresa de
desarrollo de robots. Como se ve en la figura 8, el cliente se reúne con el dueño
del producto, quien toma nota de sus necesidades.

88
Figura 11: reunión entre el cliente y el dueño del producto.
Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-
1516220

A continuación, tal y como puede verse en la figura 9, el dueño del producto

divide el proyecto en historias que formarán parte de la Lista de producto.

Figura 12: división del proyecto en historias.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-
1516220

La figura 10 muestra el siguiente paso. El dueño del producto le entrega al

facilitador la lista de producto para que estime el coste de creación del producto.

89
Figura 13: estimación del coste por parte del facilitador.
Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-
1516220

El equipo se reúne para estimar el coste de cada historia de la lista de producto

(ver figura 11).

Figura 14: estimación del coste de cada historia.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-
1516220

Una vez aprobado el presupuesto por parte del cliente, se reordena la lista de
producto en función de las prioridades del propio cliente para que el equipo trabaje
según ese orden establecido.

A continuación, el equipo comienza su trabajo desglosando la primera historia

de la lista de producto, y divide dicha historia en tareas menores para crear la lista
de Sprint. Esto puede consultarse en la figura 12.

90
Figura 15: iteración de una historia de usuario.
Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-
caso-prctico-1516220

La Lista de Sprint fracciona el trabajo de un período de 15 días en tareas más

pequeñas, que tarden, como mucho, dos días. Estas tareas se colocan en una
lista, la cual prioriza el dueño del producto, quien ha consultado con el cliente,
antes de comenzar el Sprint. La figura 13 muestra esta acción que realiza el dueño
del producto.

Figura 16: Lista de Sprint priorizada por el Dueño del Producto.

91
Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-
caso-prctico-1516220

El equipo comienza el Sprint tomando las tareas priorizadas. Una vez concluida
una, se toma la siguiente de la lista.

Todos los días se convoca una reunión del equipo donde se cuenta las tareas
realizadas el día anterior y cuáles se van a realizar ese día. La figura 14 muestra
un esquema de ejemplo de los asuntos a tratar en una de las reuniones diarias.

Figura 17: esquema de las reuniones diarias.

Fuente: https://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-
1516220

Una vez finalizado el Sprint, el dueño del producto le muestra al cliente el

resultado del trabajo realizado. El cliente valora ese primer resultado y puede
volver a priorizar la lista de producto antes de que comience otro Sprint.

El equipo de trabajo hace una reunión de retrospectiva para analizar lo

acontecido durante el Sprint que ha terminado. Tras esto se comienza de nuevo a
trabajar en otra historia del cliente.

92
3.1.6. Ejercicios de reflexión

1. Haga una comparación que exponga las diferencias entre las metodologías
ágiles y las tradicionales.
Metodologías ágiles Metodologías tradicionales
Basadas en normas provenientes de
Basadas en heurísticas provenientes de
estándares seguidos por el entorno
prácticas de producción de código.
de desarrollo.
Especialmente preparados para cambios
Cierta resistencia a los cambios.
durante el proyecto.
Impuestas internamente (por el equipo de
Impuestas externamente.
desarrollo).
Proceso menos controlado, con pocos Proceso mucho más controlado, con
principios. numerosas políticas/normas.
No existe contrato tradicional o al menos es
Existe un contrato prefijado.
bastante flexible.
El cliente interactúa con el equipo de
El cliente es parte del equipo de desarrollo.
desarrollo mediante reuniones.
Grupos pequeños (<10 integrantes) que Grupos grandes y posiblemente
trabajan en el mismo sitio. distribuidos.
Pocos artefactos. Más artefactos.
Pocos roles. Más roles.
La arquitectura del software es
Menos énfasis en la arquitectura del
esencial y se expresa mediante
software.
modelos.

2. Exponer y desarrollar los doce principios de la metodología ágil.

a. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega

temprana y continuada de software con valor.

El objetivo es lograr un cliente satisfecho, lo que contribuirá a que tengamos

más clientes en el futuro. ¿Pero cómo? Proporcionando a los clientes la solución
que realmente quieren, aunque ya sabemos que esto no es posible sin ser
adaptativos, y sin entregas tempranas y continuas de software funcionando. Esta

93
flexibilidad necesaria, aunque es posible en los ciclos de vida predictivos, resulta
demasiado cara.

b. Aceptamos que los requisitos cambien, incluso en etapas tardías del

desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
Empleando un ciclo de vida adaptable estamos abiertos al cambio ya que no
existe ningún diseño inicial al que debamos ceñirnos cada vez que queramos
realizar un cambio. Además, cualquier petición de cambio nos hará felices, pues
será un paso más que nos permitirá acercarnos a lo que el cliente realmente
desea.

c. Entregamos software funcional frecuentemente, entre dos semanas y

un mes, con preferencia por periodos de tiempo lo más corto posibles.
El cliente tendrá una mejor comprensión de lo que quiere cuando vea el software
en funcionamiento. Nosotros, recibiremos información (feedback) que podremos
utilizar para adaptarlo. Hay distintos marcos ágiles que emplean diferentes
iteraciones. Por ejemplo, en Scrum no están permitidas las iteraciones de más de
un mes, mientras que otros marcos ágiles aceptan iteraciones más largas.
Siempre y cuando sean suficientes para crear un incremento significativo (software
en funcionamiento) preferiremos las iteraciones más cortas.

d. Los responsables de negocio y los desarrolladores trabajamos juntos

de forma cotidiana durante todo el proyecto.
En un entorno predictivo la participación de la empresa/cliente se limita
generalmente a especificar los requisitos al inicio, y de nuevo al final al aprobar la
solución final. Sin embargo, en un entorno adaptable necesitamos que
la empresa/cliente trabaje a diario con los desarrolladores, ya que sus inputs
son la fuente de la adaptabilidad.

94
e. Los proyectos se desarrollan en torno a individuos motivados. Hay
que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del
trabajo.
Un entorno ágil se basa en un equipo multifuncional y autoorganizado que se
autogestiona y encuentra su camino en lugar de recibir órdenes. Esta es una gran
responsabilidad para los desarrolladores, y no todos son capaces de trabajar de
esta manera. Cuando tenemos los miembros de equipo adecuados, debemos
confiar en ellos, motivarles y darles la posibilidad de permitir la agilidad

f. El método más eficiente y efectivo de comunicar información al equipo

de desarrollo y entre sus miembros es la conversación cara a cara.
En un entorno tradicional los miembros del equipo se centran en sus actividades
de especialista, incluso podrían estar ubicados en lugares diferentes. Por lo
general en sus respectivos departamentos dentro de la organización. A veces ni
siquiera podemos llamarlos “equipo”; no son más que una serie de personas que
trabajan en el mismo proyecto. Por el contrario, en un entorno ágil necesitamos
un verdadero equipo, en el que los miembros deben estar colocalizados para
poder comunicarse continuamente. Nada puede sustituir una conversación cara a
cara. Aunque ciertamente es una gran ventaja contar con equipos colocalizados.

Esto no significa que no podamos tener un proyecto ágil con un equipo

“distribuido”. En estos casos; sin embargo, necesitaremos aprovechar al máximo
la tecnología para reducir al mínimo la falta de comunicación cara a cara, y asumir
un nivel de productividad inferior al final del día.

g. El software funcionando es la principal medida progreso.

Un producto acabado al 99 % es un producto que esta 0 % “completo” o “hecho”!
Pero entonces, ¿cómo conocer el progreso de nuestro trabajo sin entrar en
detalles técnicos? Recuerda que estamos interesados en mantener al cliente
involucrado en el proyecto. Para ello, debemos tratar de evitar los detalles
técnicos, y mantener un lenguaje sencillo, dado que en muchas ocasiones se
tratará de un cliente “no técnico”. La solución pasa por diferenciar los artículos del
95
Backlog de producto únicamente en dos categorías: “completo” y “no
completo”. Esta simple distinción es suficiente, ya que los elementos del Backlog
son lo bastante pequeños para mostrar nuestro progreso simplemente
diferenciando entre completo/no completo.

h. Los procesos ágiles promueven el desarrollo sostenible. Los

promotores, desarrolladores y usuarios debemos ser capaces de mantener
un ritmo constante de forma indefinida.
Trabajar no es el objetivo, alcanzar el producto es el objetivo. Podría parecernos
que hacer horas extras puede acelerar las cosas, pero en realidad reduce los
outputs, lo que disminuye la productividad y aumenta los defectos. Es preferible
mantener un ritmo sostenido a lo largo del tiempo.

i. La atención continua a la excelencia técnica y al buen diseño mejora la

agilidad.
No tener un diseño inicial no significa que no tengamos que estar preocupado por
el diseño. Los proyectos ágiles tienen diseño, lo que ocurre es que este se realiza
en cada iteración para cada elemento del Backlog de producto. Debemos prestar
atención a la excelencia técnica y el buen diseño para evitar problemas; sin olvidar
que el objetivo es encontrar una solución lo “suficientemente buena” más que la
solución perfecta.

j. La simplicidad o el arte de maximizar la cantidad de trabajo no

realizado, es esencial.
Un proyecto ágil se gestiona y entrega de manera simple. Por ejemplo, la gestión
del alcance se realice simplemente detallando la información esencial en una
tarjeta o nota adhesiva (ficha). No son necesarios instrumentos sofisticados para
gestionar el producto. Además, hacerlo de manera sencilla favorece la
colaboración del cliente.

k. Las mejores arquitecturas, requisitos y diseños emergen de equipos

autoorganizados.

96
Por lo general, la gente trabaja mejor cuando se siente respetada y están
autorizados para decidir cómo funcionar. Además, es mejor que todos los
miembros del equipo sean responsables de todo el proyecto. Por ejemplo, sí los
diseñadores no funcionan de manera aislada, entonces estarán constantemente
en contacto con los programadores y pueden utilizar la información que se genera
para mejorar los diseños y hacerlos más prácticos.

l. A intervalos regulares el equipo reflexiona sobre cómo ser más

efectivo para después ajustar y perfeccionar su comportamiento en
consecuencia.
¡Creemos que siempre hay margen de mejora, sin importar lo bien que estemos
haciendo las cosas! Por ello, necesitamos tiempo para investigar la iteración
anterior y encontrar la manera de implementar mejoras, por muy pequeñas que
sean. El objetivo es mejorar un poco cada iteración.

97
98
 CONCLUSIONES

El desarrollo de sistemas se ha convertido en un campo importante en la

actualidad. El uso de los patrones de diseño ha permitido que se puedan llevar a
cabo proyectos de desarrollo de software de mayor complejidad con mayor
eficiencia, lo que reduce el error.

La crisis del software ayudó a establecer una serie de pares problema-solución,

en los que se asocia a un problema dado general, una solución con patrones. De
esta forma, la solución de nuevos problemas pasa primero por identificar qué tipo
de problema tenemos para poder establecer qué solución o soluciones podemos
aplicar con mayor probabilidad de éxito.

A pesar de todo lo establecido, La elección del patrón no es una tarea fácil y

depende de los requisitos que sean prioritarios. Por ejemplo, para el caso de los
patrones arquitectónicos tenemos:

 Mantenibilidad. En este aspecto cabría preguntarse sobre la

dificultad de poder añadir un nuevo módulo, modificar alguna funcionalidad,
etc. Por ejemplo, en el caso del patrón Pipe-filter, añadir un nuevo filtro es
muy sencillo pero cambiar el formato de entrada no sería tan sencillo.
 Reusabilidad. En este caso el aspecto a considerar es si los distintos
componentes pueden o no ser reutilizados de manera individual. Volviendo al
caso del patrón Pipe-Filter, sí se da debido a que usa un formato de datos
uniforme.
 Rendimiento. Para esta cuestión hay que considerar si el rendimiento
obtenido con base en los recursos está disponible o si sería adecuado
paralelizar. En este último caso, el patrón Pipe-Filter es adecuado.
 Interactividad. En este requisito cabe preguntarse si se necesita que
haya una retroalimentación con el usuario y si dicha retroalimentación debe

99
 ser por cada etapa. Continuando con el ejemplo del patrón Pipe-Filter, cabe
destacar que esto no es posible en este patrón.

No puede establecerse una guía completa en la que se establezcan los patrones

a seleccionar en función de los requisitos y las prioridades, pues estas dependen
del sistema. Por ejemplo, los procesos independientes podrían ser implementados
usando hilos (threads) o usando procesos en diferentes máquinas. Si
consideramos el balance entre la comunicación y la computación, hay que tener
en cuenta la capacidad de los procesadores disponibles y la velocidad de las
comunicaciones entre máquinas, entre otras cuestiones. Saber esto nos permitirá
decidirnos por aquella implementación que sea más adecuada para obtener un
rendimiento óptimo del sistema.

A lo largo de este libro se ha analizado ITIL, el cual consiste en una recopilación

de buenas prácticas reconocidas a nivel global para la gestión de servicios TI. Por
tanto, el propósito de ITIL es la de formar profesionales que adquieran las
competencias necesarias para definir cómo trabajar en un empresa que presta
servicios TI a distintos niveles; bien sea a nivel de software, hardware, consultoría,
etc.

Un aspecto fundamental en ITIL es el concepto de medición. Esto se debe a

que para medir un proceso, una actividad o un servicio, primero ha de definirse y
posteriormente, posibilitar obtener medidas para poder controlarlo y gestionarlo.
Esto posibilita identificar áreas de mejora y aumentar la eficiencia, entre otras
cosas, de los distintos servicios que se ofrecen. Además, permite validar las
mejoras llevadas a cabo para poder evaluar si se ha alcanzado el objetivo
esperado.

Además, el uso de herramientas de gestión de servicios que automatizan la

realización de ciertas tareas nos permite minimizar el riesgo de fallos de los
servicios ofrecidos, así como controlar el servicio en tiempo real o detectar

100
tendencias o patrones que puedan derivar en una oportunidad de mejora y, a su
vez, redunda en la mejora de la calidad del servicio.

En este capítulo nos hemos enfocado en el proceso de desarrollo de software,

el cual es uno de los pilares de la informática. Debido a las dificultades surgidas en
torno a su desarrollo, corrección y mantenimiento, se ha establecido la necesidad
de desarrollar metodologías que permitan la producción eficaz y eficiente de un
producto software que reúna los requisitos del cliente.

En un mundo cambiante en el que hay avances tecnológicos constantemente y

surgen imprevistos durante el desarrollo de un producto software, las
metodologías ágiles han surgido para facilitar la tarea de desarrollar proyectos de
pequeño tamaño que presenten esta problemática y no pueden ajustarse a
desarrollos más tradicionales.

De entre todas las metodologías ágiles, XP y Scrum son dos de las más
extendidas en los entornos de desarrollo. La selección de la metodología
dependerá de las características del proyecto que se maneje y del conocimiento
que manejen los miembros del equipo de desarrollo del proyecto.

101
102
 Bibliografía

Alexander, C. (1979). The Timeless Way of Building. Oxford: Oxford University

Press

Appleton, B., (2000) Patterns and software: Essential concepts and terminology.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., y Stal, M. (1996).
Pattern-oriented software architecture. A system of patterns. Nueva York: John
Wiley & Sons.

Gamma, E., R. Helm, R., Johnson, R., Vlissides, J. (1994). Design Patterns.
Elements of Reusable Object-Oriented Software. Massachusetts: Addison-Wesley.

Círculo-Tec. En línea con tu desarrollo. (2012a). Estrategia de Servicio (SS).

Recuperado de:
ftp://sata.ruv.itesm.mx/portalesTE/Portales/Proyectos/Seminarios/itil/tisg003_version_imp
resa.pdf

Círculo-Tec. En línea con tu desarrollo. (2012b). Diseño del servicio (SD).

Recuperado de:
ftp://sata.ruv.itesm.mx/portalesTE/Portales/Proyectos/Seminarios/itil/tisg005_version_imp
resa.pdf

Círculo-Tec. En línea con tu desarrollo. (2012c). Operación del servicio (SO).

Recuperado de:
ftp://sata.ruv.itesm.mx/portalesTE/Portales/Proyectos/Seminarios/itil/TISG009_vimprimir.
pdf

103
 Círculo-Tec. En línea con tu desarrollo. (2012d). Transición del servicio (ST).
Recuperado de:
ftp://sata.ruv.itesm.mx/portalesTE/Portales/Proyectos/Seminarios/itil/tisg007_version_imp
resa.pdf

Círculo-Tec. En línea con tu desarrollo. (2012e). Mejora continua del servicio

(CSI). Recuperado de:
ftp://sata.ruv.itesm.mx/portalesTE/Portales/Proyectos/Seminarios/itil/tisg011_version_imp
resa.pdf

Beck, K. (1999). Extreme programming explained: embrance change. Addison-

Wesley, 1st edition.

Boehm, B. W. (1988). A Spiral Model of Software development and

Enhancement. IEEE Computer Society press, 21(5), 61-72.

Pressman, R. (1997). Ingeniería del software. Un enfoque práctico. México D. F.:

McGraw Hill.

Sommerville, I. (2002). Software Engineering. Boston: Pearson Education.

104
105
106
107
978-958-5467-13-2

108