Tema 48.- Ingeniería del software.

Ciclo de
desarrollo del software. Tipos de ciclos de
desarrollo. Metodologías de desarrollo.
Características distintivas de las principales
metodologías de desarrollo utilizadas en la
Unión Europea.
Índice
1. Introducción. .............................................................................................. 2
2. Ingeniería del software. ............................................................................. 2
3. Ciclos de vida del desarrollo software..................................................... 3
3.1. Etapas en el desarrollo software ....................................................... 3
3.2. Modelos de ciclos de vida más conocidos ......................................... 4
3.2.1. Modelo en cascada ....................................................................... 4
3.2.2. Modelo en V .................................................................................. 5
3.2.3. Modelo iterativo ............................................................................. 6
3.2.4. Modelo en espiral .......................................................................... 6
4. Metodologías de desarrollo software....................................................... 7
4.1. Metodologías tradicionales ................................................................ 8
4.1.1. La metodología RUP ..................................................................... 8
4.1.2. La metodología MSF ..................................................................... 9
4.2. Metodologías ágiles......................................................................... 10
4.2.1. El manifiesto ágil. Algunas prácticas habituales .......................... 10
4.2.2. La metodología Scrum ................................................................ 11
4.2.3. La metodología XP (eXtreme Programming) .............................. 12
4.2.4. La metodología Kanban .............................................................. 14
5. Características distintivas de las principales metodologías de
desarrollo utilizadas en la Unión Europea. .................................................. 15
5.1. MERISE. .......................................................................................... 15
5.2. SSADM. ........................................................................................... 16
5.3. MÉTRICA. ....................................................................................... 16
6. Conclusiones. .......................................................................................... 17
7. Bibliografía y webgrafía. ......................................................................... 17
Academia Uni10 – http://www.uni10.es Tema 48

1. Introducción.
En las primeras etapas del desarrollo software, éste quedó relegado a un
segundo plano en beneficio del desarrollo hardware, en el que se obtuvieron
grandes avances, logrando equipos cada vez de menor tamaño y mayor
rapidez. El software, en cambio, se desarrollaba sin ninguna planificación,
hasta que los proyectos comenzaron a ser más importantes, y los costes
crecían al no saber cómo afrontarlos.

Así, se pasó a una segunda etapa, donde el software se desarrollaba para un

mercado más amplio y no tan a medida. El tiempo y dinero dedicado a
mantenimientos posteriores comenzaba a ser excesivo, y ello unido a la
adaptación de los programas a diferentes sistemas, y el hecho de tener que
hacer frente a requisitos cambiantes por parte de los clientes hizo que se
comenzara a replantear la forma en que se desarrollaban.

La tercera etapa se dio con la aparición de los sistemas distribuidos y las redes
de ordenadores, que inyectaron todavía más elementos a considerar en el
desarrollo de ciertas aplicaciones. Finalmente, la cuarta etapa que vivimos hoy
en día se caracteriza por la inclusión de tecnologías orientadas a objetos, que
están desplazando a las convencionales en muchas áreas.

Veremos en este tema qué elementos caracterizan el proceso de desarrollo del

software. Comenzaremos por analizar el concepto de ingeniería del software
que engloba a todo este proceso, para luego ver qué etapas se siguen en el
desarrollo de software y qué ciclos de vida existen. Finalmente, veremos qué
metodologías de desarrollo software existen, y cuáles son las más populares,
tanto a nivel general como en el ámbito europeo.

Este tema forma parte del bloque del temario relacionado con la ingeniería de
software, que abarca desde el tema actual, el tema 48, hasta el tema 60,
englobando la gestión de proyectos y la inteligencia artificial. En concreto, este
tema es el primero del bloque, siendo introductorio pero fundamental para el
resto de temas.

2. Ingeniería del software.

Durante la segunda etapa de desarrollo del software comentada antes, el

excesivo tiempo y dinero dedicados al mantenimiento del software, debidos a
su deficiente planificación, hizo que se replanteara la forma en que dicho
software se desarrollaba.
Para desarrollar software correctamente es recomendable seguir una serie de
pasos, aplicar un enfoque concreto para dicho desarrollo. La rama de la
informática que nos ayuda a aplicar correctamente estos enfoques y seguir los
pasos adecuados se denomina ingeniería del software.
La ingeniería del software abarca tres elementos clave:

Versión 3 Página 2/17

Academia Uni10 – http://www.uni10.es Tema 48

• Los métodos, que indican cómo construir el software, mediante tareas

como la planificación de proyectos, análisis de requisitos, pruebas, etc.
• Las herramientas, que dan soporte para aplicar los métodos. Aquí
incluiríamos todos los programas de que podemos valernos para llevar a
cabo los métodos anteriores.
• Los procedimientos, que son el punto de unión de métodos con
herramientas, definiendo en qué orden se deben realizar los métodos y
qué productos generar en el proceso.

3. Ciclos de vida del desarrollo software.

Un ciclo de vida es un conjunto de fases por las que debe pasar un sistema (en
este caso un proyecto software), desde que nace hasta que finaliza su uso. En
cada ciclo de vida se establecen tanto las fases por las que debe pasar, como
los criterios para pasar de una fase a la siguiente, incluyendo qué entradas y
salidas produce cada fase, y las actividades a realizar en cada fase.

A los productos que se generan después de cada fase (materiales o

inmateriales) se les suele denominar entregables y, o bien forman parte de la
entrada de la siguiente fase, o bien permiten evaluar el estado del proyecto en
un punto determinado.

Algunos ciclos de vida son repetitivos, es decir, podemos pasar por una misma
fase varias veces, en función del estado en que se encuentra el producto en
cada momento, en un proceso que se conoce como realimentación.

3.1. Etapas en el desarrollo software

En (casi) cualquier proceso de ingeniería del software para desarrollar un
producto concreto, se llevan a cabo las siguientes etapas:
1. Análisis de requisitos: esta etapa incluye la comunicación con el
cliente para establecer qué aplicación quiere, y una primera fase de
análisis para esbozar el comportamiento de la misma. Puede
subdividirse en dos etapas:
• Especificación de requisitos: la comunicación con el cliente
propiamente dicha. En esta etapa se establecerán entrevistas u
otros métodos de obtención de información del cliente, procurando
dejar claros todos los aspectos o necesidades que debe cumplir el
software a desarrollar. Una vez obtenidos los requisitos, se elabora
un documento lo más completo posible, denominado especificación
de requisitos del sistema (ERS).
• Análisis: a partir de la especificación de requisitos anterior, se
elabora un documento donde, ayudándonos de algunos diagramas
visuales, detallamos qué debe cumplir la aplicación a desarrollar
(qué funcionalidades debe proporcionar, a quién, qué operaciones
dependen de qué otras, etc.).

Versión 3 Página 3/17

Academia Uni10 – http://www.uni10.es Tema 48

2. Diseño: desde el análisis del paso anterior se determina cómo

funcionará el software de forma general. Aquí se elaborarán otra serie
de diagramas que luego permitirán implementar el programa de
acuerdo a ellos, incluyendo también la apariencia visual de la
aplicación (diseño de ventanas, formularios, etc.)
3. Programación o implementación: a partir del diseño previo y los
diagramas obtenidos, se pasará a implementar la aplicación, utilizando
para ello un lenguaje (o lenguajes) de programación determinado(s).
4. Pruebas: una vez implementado el producto, se debe probar su
funcionamiento, comprobando que realiza las tareas correctamente, y
que no hay ningún caso en que pueda fallar. Se considera una buena
práctica que estas pruebas las realice alguien distinto a quien
programó la aplicación.
5. Mantenimiento: esta etapa consiste en mejorar el software
desarrollado, añadiendo ampliaciones debidas a nuevos requisitos, o
corrigiendo posibles errores detectados en la fase de pruebas.
Resumiendo estas etapas, podríamos decir que el enfoque que proporciona
la ingeniería del software nos ayuda a entender el problema a resolver
(análisis de requisitos), diseñar la posible solución, implementarla, probarla y
después gestionar las tareas restantes para conseguir una mayor calidad
(mantenimiento).
Veremos a continuación algunos de los modelos de ciclos de vida más
habituales en el desarrollo de productos software, comentando sus ventajas e
inconvenientes. En todos ellos entran en juego las etapas del desarrollo
software vistas aquí (análisis de requisitos, diseño, programación, etc.), o
bien alguna variante de las mismas.

3.2. Modelos de ciclos de vida más conocidos

3.2.1. Modelo en cascada
Este modelo es el más antiguo y ampliamente difundido de los que existen.
Ideado por W. Royce en los años 70, ordena las etapas del software
rigurosamente, de forma que el inicio de una etapa debe esperar a la
finalización de la anterior, como se puede ver en la siguiente figura.

Versión 3 Página 4/17

Academia Uni10 – http://www.uni10.es Tema 48

Se denomina modelo en cascada porque las etapas se colocan una debajo

de la otra, y el desarrollo va fluyendo hacia abajo por las distintas fases, como
si fuera una cascada.
Entre sus ventajas, podemos destacar que es apto para proyectos pequeños
y con requisitos estables y bien conocidos al principio. Es simple y fácil de
usar. Sus inconvenientes, en cambio, radican en que es poco aplicable a la
mayoría de proyectos, ya que los requisitos no suelen estar claros al
principio. Además, los resultados no son visibles hasta el final, generando
cierta inquietud en el cliente, y los fallos que pueda haber tampoco se
detectan hasta fases tardías.
Una variante de este modelo la constituye el llamado modelo sashimi,
llamado así porque las etapas se superponen entre sí, como el pescado
japonés. De esta forma, la etapa de diseño se comienza antes de haber
finalizado la de análisis, la de implementación se inicia antes de concluir la de
diseño, y así sucesivamente. Esto permite que se puedan corregir defectos
en una etapa a medida que se detectan al haber iniciado la siguiente.

3.2.2. Modelo en V
Uno de los problemas del modelo en cascada es que los fallos en el software
no se detectan hasta las fases finales. Con el modelo en V, las pruebas se
inician lo más pronto posible y, además, estas pruebas deben hacerse en
paralelo por otro equipo. Así, las pruebas se integran en cada fase del ciclo
de vida. El esquema de funcionamiento puede verse en la siguiente figura:

La parte izquierda de la V representa el análisis de requisitos, diseño e

implementación del sistema, y la parte derecha representa la integración de
las partes del sistema y su verificación o prueba. Se va avanzando por la
izquierda hasta llegar a la punta inferior (la codificación o implementación), y
después se llevan a cabo las validaciones o pruebas de la derecha. En
cuanto se detecte algún problema, se vuelve al lado izquierdo en el punto
donde se encontró.
Entre sus ventajas, destacar que es simple y fácil de usar, como el modelo
en cascada, y es apropiado para proyectos pequeños con requisitos estables.

Versión 3 Página 5/17

Academia Uni10 – http://www.uni10.es Tema 48

También los planes de prueba asociados a cada etapa del proceso permiten
una detección más temprana de posibles fallos. Como inconvenientes, es
algo rígido, y se siguen sin ver resultados hasta fases tardías.

3.2.3. Modelo iterativo

Uno de los principales problemas de los modelos anteriores es que sólo
funcionan bien cuando los requisitos son sencillos o están bien especificados,
pero esa no suele ser la tónica habitual en los proyectos software.
Para intentar paliar esto, el modelo iterativo propone una especie de
repetición del modelo en cascada, generando tras cada repetición una
versión o prototipo del proyecto. Esta versión se revisa, se detectan los fallos
y se vuelve sobre los requisitos para pulirlos. El esquema de funcionamiento
se puede ver en la siguiente figura:

Sus principales ventajas son su aptitud para proyectos complejos, y que no

hace falta que los requisitos se definan completamente al principio; además,
se gestionan mejor los riesgos al haber entregas parciales o prototipos
intermedios que el cliente puede revisar. Como inconveniente principal, el no
necesitar tener los requisitos al principio puede implicar que surjan requisitos
no contemplados que afecten significativamente al diseño inicial del producto.
Existen algunas variantes de este modelo iterativo, con otros nombres y
algunas peculiaridades que las diferencian de éste. Una de las más
conocidas es el modelo incremental, donde cada versión que se entrega es
un producto con pequeñas mejoras o cambios respecto al anterior.

3.2.4. Modelo en espiral

En el modelo en espiral las fases o actividades a realizar se disponen en una
espiral dividida en cuadrantes, de forma que en cada cuadrante se realiza
una actividad, y cada vuelta de la espiral pasa por todas las actividades.
Este modelo tiene en cuenta el riesgo que aparece al desarrollar software.
Así, comenzando desde el centro de la espiral, en cada vuelta de la misma se
analizan las posibles alternativas de desarrollo, se opta por los riesgos más
asumibles y se hace un ciclo de dicha espiral. Si el cliente propone mejoras o
correcciones sobre el producto que se obtiene, se vuelven a evaluar

Versión 3 Página 6/17

Academia Uni10 – http://www.uni10.es Tema 48

alternativas y riesgos y se realiza otra vuelta, hasta que el producto sea

aceptado. El esquema puede verse en la siguiente figura:

• En la fase de objetivos se establecen los productos a obtener

(requisitos, especificación, etc.)
• En la fase de evaluar riesgos se identifican los posibles riesgos del
proyecto, y se seleccionan una o varias alternativas para reducirlos o
eliminarlos
• En la fase de desarrollar y probar se llevan a cabo las etapas de
diseño, implementación y prueba, según las alternativas elegidas
previamente en el análisis de riesgos
• En la fase de planificar se revisa lo realizado, se coteja con el cliente y
se decide si hace falta depurar o ampliar alguna opción de la
aplicación, y en consecuencia dar una vuelta más a la espiral.
Las principales ventajas de este modelo aluden a la evaluación de riesgos, y
a su aptitud para proyectos grandes y con requisitos cambiantes. También se
producen prototipos o versiones intermedias que el cliente puede validar.
Como inconvenientes principales, es un modelo que requiere de cierta
experiencia para poderse aplicar, y evaluar correctamente los riesgos. Puede
resultar, por tanto, bastante costoso, y no sería apto para proyectos
pequeños, a diferencia de los tres modelos anteriores.

4. Metodologías de desarrollo software

Debido a que desarrollar productos software no es una tarea fácil, existen
diferentes metodologías que podemos aplicar para dicho desarrollo.
Entendemos por metodología un conjunto de técnicas y métodos que permiten

Versión 3 Página 7/17

Academia Uni10 – http://www.uni10.es Tema 48

abordar de forma homogénea cada etapa del ciclo de vida de un proyecto. Con
esto se consigue:

• Optimizar el proceso y el producto software obtenido

• Obtener métodos que guían la planificación y el desarrollo
• Definir qué hacer, cómo hacerlo y cuándo, durante todo el proyecto

Algunas metodologías son más tradicionales, y se centran en controlar en

todo momento el proceso y su planificación, estableciendo las actividades a
realizar, los entregables que se deben producir en cada paso y las
herramientas y notaciones que se emplearán. Se critica que, para ciertos
proyectos, son metodologías rígidas y complejas de ajustar.

Otras metodologías se centran más en el factor personal y en el producto en sí.

Son las metodologías ágiles, que valoran aspectos como la comunicación con
el cliente, el desarrollo de software con iteraciones muy cortas, o la
adaptabilidad a distintos tipos de proyectos. Son metodologías muy aceptadas
para proyectos con requisitos cambiantes, o en los que el tiempo de desarrollo
es un factor crítico.

La mayor parte de metodologías (tradicionales o ágiles) utilizan algunos de los

modelos de ciclos de vida vistos con anterioridad. Los más utilizados son el
modelo iterativo o incremental, y el modelo en espiral. Ambos se basan en las
repeticiones de las diferentes etapas del software, con una serie de hitos
intermedios, generando tras cada repetición un prototipo o versión del producto
a desarrollar.

4.1. Metodologías tradicionales

Como hemos dicho, las metodologías tradicionales se centran en la

planificación y la secuencia de pasos a seguir, por encima del producto a
obtener o del propio cliente. Veamos algún ejemplo representativo.

4.1.1. La metodología RUP

El proceso unificado Rational (RUP) es un marco de trabajo iterativo creado por

Rational Software Corporation, una división de la empresa IBM. A diferencia de
lo que las metodologías tradicionales suponen, RUP no es un marco rígido,
sino adaptable a diferentes proyectos, seleccionando los elementos que sean
más apropiados en cada caso.

La metodología RUP se basa en el modelo de ciclo de vida en espiral, tratando

de paliar los evidentes defectos del modelo en cascada, e intentando dar
cabida al paradigma orientado a objetos mediante UML (Lenguaje Unificado de
Modelado), un lenguaje que incorpora una serie de diagramas con los que
ilustrar el análisis y diseño de la aplicación a desarrollar. Algunos de los
diagramas más representativos de este lenguaje son el diagrama de casos de
uso, el diagrama de clases, el de actividad o el de secuencia.

Versión 3 Página 8/17

Academia Uni10 – http://www.uni10.es Tema 48

RUP se estructura en una serie de elementos, denominados módulos. En

concreto, los módulos principales de RUP son:

• Roles: definen conjuntos de competencias, habilidades y

responsabilidades, de forma que la persona o personas con un rol
específico, deben tener ese conjunto de cosas (competencias,
habilidades y responsabilidades)
• Productos de trabajo: resultado de una tarea, incluyendo documentos y
modelos secundarios producidos
• Tareas: unidad de trabajo, asignada a un rol, y que produce un producto
de trabajo determinado y significante.

Estos tres módulos pueden interpretarse como el quién lo hace (rol), qué se
hace (producto de trabajo) y cómo lo hace (tarea).

Según la metodología RUP, el ciclo de vida de un producto consta de cuatro

fases:
• Iniciación (Inception), donde se define el alcance del proyecto. En esta
fase se realiza un modelado del negocio (análisis y documentación de la
empresa para la que se trabaja, viendo sus puntos fuertes y débiles,
capacidad de generar beneficios, etc.), y un análisis de los requisitos del
sistema a desarrollar.
• Elaboración, donde se analiza con mayor profundidad el proyecto y se
define su arquitectura principal. Se realiza para ello un diseño y una
implementación primarios que se toman como base. Esta fase, junto a la
anterior, están orientadas a comprender el problema a resolver, definir la
tecnología a utilizar y eliminar riesgos graves del proyecto.
• Construcción, donde se diseña la aplicación y se produce su código
fuente. Se emplean para ello diferentes iteraciones, aplicando el modelo
en espiral, y generando varios prototipos.
• Transición, donde se prepara el producto para su entrega al cliente

Podríamos pensar que esto se asemeja bastante al modelo en cascada, pero la

esencia de RUP está en las iteraciones dentro de todas las fases (cada fase
tiene un número variable de iteraciones, dependiendo del proyecto). Además,
cada fase tiene un objetivo final que cumplir.

4.1.2. La metodología MSF

La metodología MSF (Microsoft Solutions Framework) es otra metodología

personalizable que, aplicando un enfoque tradicional, permite desarrollar un
producto software. Como su propio nombre indica, es un enfoque ideado por
Microsoft, y podemos aplicarlo no sólo a desarrollar aplicaciones, sino también
a otros aspectos informáticos, como planificación de redes, infraestructuras,
etc.

Al igual que RUP, MSF está basado en el modelo en espiral, y consta de una
serie de etapas o fases iterativas, al final de cada una de las cuales se tiene un
objetivo a alcanzar, y unos entregables que completar:

Versión 3 Página 9/17

Academia Uni10 – http://www.uni10.es Tema 48

• Visión: donde se valora el modelo de negocio, los beneficios que se

pueden obtener, restricciones, alcances. Se debe obtener una
especificación de requisitos, una valoración inicial de riesgos y una
visión general de la empresa para la que se desarrolla. Es algo más o
menos equivalente a la fase de iniciación del modelo RUP.
• Planificación: se planifica el desarrollo del proyecto y la arquitectura a
utilizar, ajustándolo a un cronograma que cumpla con lo especificado. Se
generan así la lista de actividades a completar, personas involucradas,
responsabilidades y costes. Esto ayudará también a perfilar mejor los
riesgos y evitar los que puedan resultar graves.

• Desarrollo: se comienza a construir el código a partir de las

funcionalidades más básicas, entregando prototipos de cada una de
ellas para someterla a pruebas y evaluaciones por parte del cliente.

• Estabilización: se afina el producto final para que el cliente lo apruebe

en su totalidad. Se documenta también el registro de pruebas realizadas
previo a la aprobación del cliente.

• Implantación y soporte: se instala el sistema en el cliente, y se le

ofrece garantía durante el tiempo estipulado en el contrato

4.2. Metodologías ágiles

Las metodologías tradicionales han demostrado ser muy válidas para proyectos
grandes (en términos de tiempo y presupuesto), pero algunos aspectos, como
la excesiva documentación a generar, y una posible sobreplanificación, las
hacen a menudo inviables para proyectos pequeños, o de entrega rápida, o en
los que los requisitos pueden cambiar con cierta frecuencia durante el
desarrollo.

Ante este problema, muchos equipos de desarrollo tienden a prescindir de

estos esquemas, y asumir metodologías ágiles, especialmente orientadas a
proyectos pequeños (a desarrollar en poco tiempo, con equipos normalmente
inferiores a 10 personas). En ellas se fomenta el trabajo en equipo y la
responsabilidad propia, alineando el desarrollo con las necesidades del cliente
y los objetivos de su compañía. La comunicación cara a cara entre los
miembros del equipo, y con el cliente, suele ser un factor cotidiano.

4.2.1. El manifiesto ágil. Algunas prácticas habituales

El manifiesto ágil es una especificación creada en 2001 que recoge los valores
y principios que debe tener una metodología de desarrollo para permitir a un
equipo construir software rápidamente y respondiendo a los cambios que
pueda haber en el futuro. Algunos de los principios más importantes son:

• La gente es el principal factor de éxito de un proyecto. Es más

importante construir un buen equipo y que éste configure su entorno de

Versión 3 Página 10/17

Academia Uni10 – http://www.uni10.es Tema 48

trabajo, que construir un entorno de trabajo y obligar al equipo a que se

adapte a él.
• No se deben producir documentos a menos que sean necesarios de
forma inmediata para tomar una decisión
• Debe existir una interacción constante entre el cliente y el equipo de
desarrollo
• La habilidad de responder a los cambios que pueda haber durante el
desarrollo del proyecto es más importante que ceñirse a un plan estricto
y rígido
• La prioridad más alta es satisfacer al cliente mediante la entrega
temprana y continua de software operativo
• La conversación cara a cara es el método más eficiente de hacer llegar
la información en un equipo de desarrollo
• Simplicidad

Además de los principios recogidos en el manifiesto ágil, algunas metodologías

ágiles aplican ciertas prácticas adicionales que son bastante habituales. Por
ejemplo:

• Programación por parejas: dos programadores trabajan juntos en el

mismo ordenador. Uno teclea el código (driver) y el otro revisa lo
tecleado (observer). Ambos programadores cambian sus roles con
frecuencia (30 minutos, por ejemplo). Esto produce programas más
legibles, se minimiza el riesgo si algún miembro abandona el proyecto,
permite a ambos aprender del otro, etc. Sin embargo, es más costoso
que mantener un solo programador, y puede haber conflictos entre ellos.

• Desarrollo dirigido por las pruebas (TDD, Test Driven Development):

técnica que emplea iteraciones cortas basadas en casos de prueba
escritos previamente. Así, cada iteración produce el código para que
esas pruebas resulten satisfactorias, y una vez lo sean se integra el
código con lo anterior y se refactoriza para optimizarlo.

• Historias de usuario: técnica utilizada para especificar los requisitos del

sistema a desarrollar. Son tarjetas de papel donde el cliente describe
brevemente las características de dicho sistema (requisitos funcionales o
no funcionales). Cada historia de usuario es lo suficientemente
comprensible y delimitada como para que el equipo de desarrollo pueda
implementarla en unas pocas semanas.

4.2.2. La metodología Scrum

Scrum es una metodología ágil que puede usarse para desarrollar proyectos
complejos, utilizando prácticas iterativas e incrementales. Puede aplicarse tanto
a productos software como en otros ámbitos. Su nombre viene a significar algo
así como la melé que se forma en rugby.

Los roles principales en Scrum son:

Versión 3 Página 11/17

Academia Uni10 – http://www.uni10.es Tema 48

• ScrumMaster, sería algo así como el jefe de proyecto, aunque no existe

tal figura en Scrum (el propio equipo se auto‒organiza). Su principal
misión es asegurarse de que el método Scrum se utiliza correctamente,
y no se produce ninguna influencia externa que lo altere.

• ProductOwner, representante de la parte cliente, que no tiene por qué

pertenecer a la empresa del cliente (puede ser alguien del equipo de
desarrollo que actúe en nombre del cliente).

• Team, conjunto de desarrolladores

Veamos en qué consiste el proceso de trabajo en Scrum: para empezar, y

para hacerse una idea de la aplicación a desarrollar, se obtienen los
requerimientos del cliente (tanto ejecutivos, directivos, como demás miembros
de la empresa que vayan a emplear la aplicación). Estas características se
toman mediante lo que se conoce como historias de usuario, en las que cada
usuario preguntado cuenta qué espera que haga la aplicación. Estas historias
se agrupan en una colección llamada backlog de producto. De ese backlog, se
deben seleccionar qué historias se añadirán finalmente a la aplicación.

A partir de este punto se inicia el proceso de desarrollo, basado en iteraciones

o sprints. En cada iteración (que normalmente dura entre 2 y 4 semanas, a
elegir por el equipo de desarrollo), se crea un incremento o versión de software
operativa. En ese incremento se añaden una serie de requisitos extraídos del
backlog. El conjunto de requisitos a añadir en la iteración se decide en una
reunión de planificación previa al sprint. En ella, el Product Owner informa al
equipo de los ítems de ese backlog que se deben incorporar al producto, y el
equipo determina cuántos de esos ítems se pueden añadir en la próxima
iteración. Después, durante la iteración, el backlog se congela, no se pueden
modificar los requisitos hasta la siguiente iteración.

Además de esta reunión al principio de cada iteración, en Scrum también se

tienen reuniones diarias (donde se discute el estado del proyecto, lo que se ha
hecho y lo que se va a hacer), y al final de cada iteración o sprint para evaluar
lo que se ha obtenido.

4.2.3. La metodología XP (eXtreme Programming)

La programación extrema (XP) es una metodología de desarrollo ágil

introducida por Kent Beck. Se basa en la realimentación continua entre el
cliente y el equipo de desarrollo, y en la simplicidad de las soluciones
implementadas. Es especialmente adecuada (entre otros casos) para proyectos
con requisitos muy cambiantes y alto riesgo técnico. Sus principios y prácticas
son de sentido común, pero llevadas al extremo (de ahí su nombre).

Al igual que ocurre con Scrum, XP también utiliza las historias de usuario
para especificar los requisitos del sistema a desarrollar. Son tarjetas de papel
donde el cliente describe brevemente las características de dicho sistema
(requisitos funcionales o no funcionales). Cada historia de usuario es lo
suficientemente comprensible y delimitada como para que el equipo de

Versión 3 Página 12/17

Academia Uni10 – http://www.uni10.es Tema 48

desarrollo pueda implementarla en unas pocas semanas. Para ello, cada

historia se descompone en tareas y se asignan a los programadores del equipo
para implementarlas durante una iteración.

Además, cada miembro del equipo tiene un determinado rol, de entre estos
posibles:

• Programadores que escriben el código y las pruebas del mismo

• Cliente que escribe las historias de usuario y las pruebas funcionales
para validar los productos entregados por el equipo. Además, asigna la
prioridad a cada historia de usuario, y decide cuáles se implementan en
cada iteración.
• Encargado de pruebas, ayuda al cliente a escribir las pruebas
funcionales, y ejecuta las pruebas regularmente, difundiendo los
resultados al equipo
• Encargado de seguimiento, verifica el acierto en las estimaciones de
tiempo realizadas, proporcionando realimentación al equipo para estimar
mejor las futuras iteraciones
• Consultor, miembro externo al equipo con conocimiento específico en
algún tema concreto sobre el que puedan surgir problemas. En algunos
proyectos puede no ser necesaria esta figura.
• Gestor o big boss, vínculo entre clientes y equipos de desarrollo, se
encarga de coordinar la comunicación entre ambas partes.

El ciclo de desarrollo que utiliza la metodología XP sigue estos pasos:

1. El cliente define el valor de negocio a implementar (historia de usuario)

2. El programador estima el esfuerzo necesario para su implementación
3. El programador construye ese valor o historia
4. Se vuelve al paso 1

Para que la metodología XP cumpla correctamente su cometido, es necesario

aplicar una serie de prácticas durante el proceso de desarrollo. Además de las
recogidas en el manifiesto ágil (comunicación frecuente con el cliente, entregas
pequeñas y frecuentes, diseño simple...), y de algunas prácticas comunes en
muchas metodologías ágiles (programación por parejas, integración continua,
propiedad colectiva del código...), podemos citar estas otras:

• Seguir ciertos estándares de programación por parte de todo el equipo,

para mantener el código legible
• La codificación es el producto más importante del proceso, ya que sin el
código no se tiene nada. De hecho, en XP se recomienda que, si se
duda entre diferentes alternativas a la hora de implementar un problema,
se implementen todas ellas y se valore cuál puede resultar mejor a partir
del código generado.
• Las pruebas son la única vía de comprobar que el producto que se ha
desarrollado hace lo que se pretendía

Versión 3 Página 13/17

Academia Uni10 – http://www.uni10.es Tema 48

4.2.4. La metodología Kanban

Kanban es otra metodología ágil muy sencilla de aplicar. Su nombre es una

combinación de dos palabras japonesas: kan (visual) y ban (tarjeta), por lo que
podemos deducir que el componente principal de esta metodología son
tarjetas, que representan las diferentes tareas que debemos completar en el
proceso de desarrollo.

Los orígenes de Kanban se ubican en los años 40 del siglo pasado, cuando la
compañía Toyota comenzó a optimizar su proceso de fabricación, basándose
en modelos similares utilizados por supermercados para gestionar su stock.
Como los niveles de inventario deben emparejarse con los patrones de
consumo, el exceso de stock debe controlarse. Así, Toyota pudo alinear sus
niveles de inventario con su consume de materiales. Los trabajadores pasaban
una tarjeta entre los equipos cuando un contenedor de material se había
vaciado, indicando la cantidad exacta de material que se necesitaba. El
almacén, por su parte, tenía un nuevo contenedor de material listo para enviar,
y a la vez solicitaban un nuevo contenedor al proveedor.

Si aplicamos esta filosofía al proceso de Desarrollo de software, Kanban

permite a los equipos de desarrollo emparejar la cantidad de trabajo pendiente
(WIP, Work In Progress) con la capacidad real del equipo. Esto proporciona a
dicho equipo mayor flexibilidad de planificación, mayor capacidad de enfoque
(centrarse en las tareas que hay que hacer) y salidas o entregables más
rápidos.

El término más importante en la metodología Kanban es flujo, ya que el trabajo

fluye por el sistema continuamente, en lugar de estar organizado en cajas de
tiempo, como hace Scrum con los sprints.

Kanban utiliza mecanismos visuales, como los tableros Kanban (Kanban

boards) para que el equipo de desarrollo pueda comprobar en todo momento el
estado de cada tarea. Además, se puede comprobar en cualquier instante si
existe un cuello de botella o alguna etapa que esté acumulando demasiadas
tareas por completar. El tablero más básico está dividido en tres secciones
(tareas pendientes de hacer, tareas en progreso y tareas finalizadas), pero se
pueden añadir las etapas intermedias que se quieran (por ejemplo, iniciadas,
pendientes de prueba, etc.). En cada una de estas secciones o etapas se
colocan las tarjetas de las tareas que se encuentran en dicho estado.

Algunos de los principios fundamentales de la metodología Kanban son:

• Limitación de tareas pendientes (WIP), o “dejar de empezar y

empezar a terminar”, se refiere a que el equipo no debe empezar tareas
nuevas hasta aligerar la cantidad de tareas pendientes.
• Calidad garantizada: todo debe estar bien hecho a la primera, no hay
margen de error. Así, la velocidad no es tan importante como la calidad,
porque solucionar problemas puede ser más costoso.
• Reducción del desperdicio: debemos hacer sólo lo que necesitamos, y
hacerlo bien.

Versión 3 Página 14/17

Academia Uni10 – http://www.uni10.es Tema 48

• Flexibilidad: el siguiente paso se decide de entre el backlog de tareas

pendientes, eligiendo la siguiente que se completará. Así, se puede
priorizar esa próxima tarea dependiendo de las necesidades de cada
momento.

Kanban tiene algunas similitudes con la metodología Scrum: ambas son ágiles,
ambas requieren equipos que se sepan auto-gestionar, y ambas se centran en
entregar prototipos o versiones muy a menudo. También existen algunas
diferencias entre estas metodologías: por ejemplo, en Kanban no existen roles
predefinidos, y puede haber cambios en los requisitos en cualquier instante (en
Scrum no se permiten una vez se ha iniciado un sprint). Así, Scrum es más
apropiado para situaciones en que el trabajo puede priorizarse en lotes,
mientras que Kanban se puede aplicar mejor a proyectos con alta variabilidad
en las prioridades.

5. Características distintivas de las principales

metodologías de desarrollo utilizadas en la Unión
Europea.
Las administraciones públicas de distintos países europeos han promovido el
desarrollo de metodologías para unificar la forma de desarrollar sus sistemas
de información. Comentaremos las más conocidas, como MERISE, SSADM y
MÉTRICA.

5.1. MERISE.

La metodología Merise surgió del Ministerio de Industria Francés en 1977. Las

mayores aportaciones de esta metodología son un ciclo de vida más largo que
los existentes, y que trabaja a tres niveles: conceptual (estudia las finalidades
generales de la empresa), organizativo (estudia la planificación del producto a
desarrollar y su encaje en la empresa) y físico (integra los medios técnicos,
hardware y software, para implantar el producto).

La metodología MERISE consta de estas etapas:

1. Estudio preliminar. Se analiza la situación existente para proponer una

solución global atendiendo a los criterios de gestión, de la organización y
decisiones adoptadas por el comité directivo del proyecto.

2. Estudio detallado. El objetivo de esta fase es definir, a nivel funcional, la

solución que hay que implementar. Se obtendrán estudios detallados y
los cuadernos de carga para la futura realización de los programas.

3. Implementación. El objetivo de esta etapa es realizar los programas que

corresponden a las especificaciones detalladas; se divide en dos partes:

• Estudio técnico, donde se distribuyen los datos en ficheros físicos y

los tratamientos en módulos de programas.

Versión 3 Página 15/17

Academia Uni10 – http://www.uni10.es Tema 48

• Producción de programas, que permite codificar y verificar los

programas mediante juegos de pruebas.

4. Realización y puesta en marcha. Se efectúa la implementación de los

medios técnicos (instalación de los materiales, iniciación, captura de
datos, etc.) y organizativos (formación del personal, lanzamiento de la
aplicación), así como la recepción definitiva por parte del usuario.

5.2. SSADM.

Esta metodología fue planteada por el gobierno británico a principios de los

años 80 para estandarizar los proyectos realizados en los departamentos
gubernamentales.

Los aspectos claves de SSADM son:

• Énfasis en los usuarios: sus requisitos y participación.

• Definición del proceso de producción: qué hacer, cuándo y cómo.
• Tres puntos de vista: datos, eventos, procesos.
• Máxima flexibilidad en herramientas y técnicas de implementación.

Esta metodología proporciona un conjunto de procedimientos para llevar a

cabo el análisis y diseño, pero no cubre aspectos como la planificación
estratégica ni la construcción de código.

5.3. MÉTRICA.

Esta metodología surgió en España en 1989, del Consejo Superior de

Informática, con el objetivo de crear un marco metodológico común para los
sistemas de información de la Administración pública española.

Algunas de las principales aportaciones que presenta en su versión actual (v3)

son:
• Se han tenido en cuenta los últimos estándares de calidad e ingeniería
del software, así como otras metodologías.
• Es una metodología mixta: válida para desarrollos estructurados y
orientados a objetos.
• Define, para todas las actividades, los participantes en las mismas y la
responsabilidad.
• Define cómo y cuándo se obtienen los productos.

Los procesos de la estructura principal de Métrica v3 son los siguientes:

• Planificación de Sistemas de Información, que facilita una visión

general del sistema a desarrollar y el cliente para el que desarrollarlo.

Versión 3 Página 16/17

Academia Uni10 – http://www.uni10.es Tema 48

• Desarrollo de Sistemas de Información, que, dada su amplitud y

complejidad, se ha subdividido en cinco procesos:
o Estudio de Viabilidad del Sistema (EVS)
o Análisis del Sistema de Información (ASI)
o Diseño del Sistema de Información (DSI)
o Construcción del Sistema de Información (CSI)
o Implantación y Aceptación del Sistema (IAS)

• Mantenimiento de Sistemas de Información, que comprende

actividades de modificación y retirada de todos los componentes del
sistema. Este marco queda fuera del objetivo principal de Métrica v3,
que es el desarrollo de software.

6. Conclusiones.
La ingeniería del software es el establecimiento y uso de principios de
ingeniería robustos, orientados a obtener software económico que sea fiable y
funcione de manera eficiente.

El ciclo de vida del software abarca toda la vida del sistema, comenzando con
su concepción y finalizando cuando ya no se utiliza. Existen varios modelos de
ciclo de vida, entre los que podemos destacar el modelo en cascada, en V, el
incremental y el espiral.

Una metodología de desarrollo es un conjunto de procedimientos, técnicas

herramientas, y un soporte documental que ayuda a los desarrolladores a
realizar nuevo software. Las metodologías se clasifican en tradicionales y
ágiles.

Las administraciones públicas de distintos países europeos han promovido el

desarrollo de metodologías para unificar la forma de desarrollar sus sistemas
de información. Las más conocidas en la Unión Europea son MERISE, SSADM
Y MÉTRICA.

7. Bibliografía y webgrafía.
▪ Languer, A. M. (2016). Guide to Software Development : Designing and
Managing the Life Cycle. London: Springer.
▪ Pressman, R. S. (2010). Ingeniería del software, un enfoque práctico, 7ª
ed. Ciudad de México: McGraw-Hill.
▪ Sommerville, I. (2011). Ingeniería de software, 9ª ed. Madrid: Pearson.
▪ Sitio web especializado en el ámbito de la en ingeniería del software.
Link: ingenieriadesoftware.es/
▪ Portal web de la empresa ‘Intelligenia’, dedicada a la ingeniería web y a
la creatividad. Link: www.intelligenia.com/
▪ Página dedicada a las herramientas de ingeniería del software para
desarrolladores. Link: www.engineeringtoolbox.com/

Versión 3 Página 17/17