Metodologías para el desarrollo de software

Metodología de desarrollo de software se describe como el conjunto de herramientas,

técnicas, procedimientos y soporte documental para el diseño de Sistemas de información.

En Ingeniería de software cuando se habla de desarrollo de software se habla de desarrollo

de programas y por lo tanto se considera como una tarea de ingeniería, en el cuál se debe
ejecutar una serie de fases, etapas para obtener un programa que funcione de acuerdo con
métodos ya establecidos en otras disciplinas de ingeniería.1 Las actividades que los
ingenieros de software realizan se encuentran asociadas a un proceso de software donde
intervienen diferentes elementos (fases, actividades, producto, roles, agentes) que permiten
la definición del software a producir (producto), el desarrollo o el diseño del software, la
validación del software tanto lo interno(requerimientos específicos)como lo
externo(expectativas del cliente), y la evolución del software donde se modifica para
adaptarlo a los cambios.2

Por otro lado, Sommerville (2002) define que “un método de ingeniería de software es un
enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la
producción de software de alta calidad de una forma costeable”, cabe destacar que para usar
este enfoque se debe manejar conceptos fundamentales tales como; procesos, métodos,
tareas, procedimientos, técnicas, herramientas, productos, entre otros.

Particularmente, una metodología se basa en una combinación de los modelos de proceso

genéricos para obtener como beneficio un software que soluciones un problema.
Adicionalmente una metodología debería definir con precisión los artefactos, roles y
actividades, junto con prácticas, técnicas recomendadas y guías de adaptación de la
metodología al proyecto. Sin embargo, la complejidad del proceso de creación de software
es netamente dependiente de la naturaleza del proyecto mismo, por lo que el escogimiento
de la metodología estará acorde al nivel de aporte del proyecto, ya sea pequeño, mediano o
de gran nivel.
Evolución histórica de las metodologías de desarrollo de software

Desde que se empezó a trabajar sobre el desarrollo de programas, se siguieron ciertos

métodos que permitían llevar a producir un buen proyecto, estas metodologías aplicadas
eran simples, solo se preocupaban por los procesos mas no por los datos, por lo tanto los
métodos eran desarrollados hacia los procesos. El modelo de procesos predominaba para
los años 60 y consistía encodificar y corregir (Code-and-Fix), si al terminar se descubría
que el diseño era incorrecto, la solución era desecharlo y volver a empezar 3, este modelo
implementaba el código y luego se pensaba en los requisitos, diseño, validación y
mantenimiento. los principales problemas del modelo de procesos son:

 Los arreglos se hacen costosos, después de tantas correcciones el código tenia una
mala estructura.

 El software no se ajusta a las necesidades del usuario, por lo que es rechazado o su

reconstrucción es muy cara.

 El código es difícil de reparar por su pobre preparación para probar y modificar.

En la década de los setenta empezó a tomar la importancia de los datos, y para solucionar
sistemas complejos empezó el análisis por partes o etapas, se introducen la planeación y
administración. El modelo en cascada surge como respuesta al modelo de procesos, este
modelo tiene mas disciplina y se basa en el análisis, diseño, pruebas y mantenimientos. 4

La década de los ochenta es la época marcada por las metodologías dirigida a datos cuya
importancia va tomando cuerpo en las organizaciones. Se empiezan a estudiar los objetos
en sí como unidades de información. Para los años 90 se quiere dar respuesta al entorno
siempre cambiante y en rápida evolución en que se han de desarrollar los programas
informáticos, lo cual da lugar a trabajar en ciclos cortos (como mini-proyectos) que
implementan una parte de las funcionalidades, pero sin perder el rumbo general del
proyecto global.

Por otra parte las metodologías de desarrollo comienzan a interesarse no sólo en lograr que
el proyecto sea puesto en funcionamiento sino en minimizar costos durante su desarrollo y
sobre todo durante su mantenimiento. Los nuevos métodos van buscando minimizar riesgos
y, puesto que los errores más perjudiciales se producen en los primeros pasos, se comienza
ya desde la fase más general del estudio por analizar los riesgos que significa seguir con las
siguientes fases del desarrollo.

Las metodologías más utilizadas a nivel mundial en orden cronológico:13

Década de los 70s

 Programación Estructurada Jackson desde 1975

Década de los 80s

 Structured Systems Analysis and Design Methodology (SSADM) desde 1980

 Structured Analysis and Design Technique (SADT) desde 1980

 Ingeniería de la Información (IE/IEM) desde 1981

Década de los 90s

 Rapid Application Development (RAD) desde 1991.

 Programación Orientada a Objetos (OOP) a lo largo de la década de los 90's

 Virtual Finite State Machine (VFSM) desde 1990s

 Dynamic Systems Development Method desarrollado en UK desde 1995.

 Rational Unified Process (RUP) desde 1999

Año 2000 en adelante

 Extreme Programming (XP) desde 1999

 Enterprise Unified Process (EUP) extensiones RUP desde 2002

 Constructionist Design Methodology (CDM) desde 2004 por Kristinn R. Thórisson

 Agile Unified Process (AUP) desde 2005 por Scott Ambler

La trascendencia de las metodologías se ha hecho notoria, pasando de solo programar,

luego a establecer funciones en etapas o módulos, continuar en resaltar en la primera
etapa el análisis de los requisitos, seguido de basarse en objetos, y por último agilizar el
desarrollo del software y minimizar los costos. Estos cambios de paradigma han logrado
las mejoras para desarrollar software y aunque principalmente buscar acortar el tiempo
de solución sin reprochar los recursos disponibles.

Generaciones de metodologías

Las metodologías han ido cambiando con el tiempo, al surgir nuevos paradigmas que
rompe con lo tradicional para abrir paso a nuevas técnicas de solución.5Han evolucionando
a lo largo del tiempo estas herramientas, inicialmente el periodo de desarrollo convencional
(practicas artesanales), luego surge el Desarrollo estructurada (parte de la programación
estructurada seguido de los método de análisis y diseño, cubre todo el ciclo de vida
completo). Actualmente aparece el paradigma de la orientación a objetos.

Desarrollo Convencional

En los años 50 el desarrollo estaba a cargo de programadores, por lo que se vio la

importancia del análisis y diseño en el desarrollo de los sistemas. Aparecen los analistas
programadores y analistas de sistemas.6

En esta misma época, no existían metodologías de desarrollo. Las personas que

desarrollaban los sistemas eran programadores más enfocados en la tarea de codificar, que
en la de recoger y comprender las necesidades de los usuarios. Estos, a menudo, no
quedaban satisfechos con el sistema, porque sus necesidades no estaban definidas con
claridad en una fase de análisis previo. Ante esta perspectiva se vio la importancia del
análisis y del diseño en el desarrollo de un sistema. Ahora se empieza a hablar de analistas
programadores y analistas de sistemas.
Hasta hace relativamente poco tiempo cuando se hablaba de “desarrollo” se aludía
únicamente al crecimiento económico dando por supuesto que dicho crecimiento se revierte
de manera casi automática en los otros sectores de la estructura social. Las estrategias de
desarrollo se han concentrado fundamentalmente en estrategias económicas, que aunque
incorporan elementos de otros sectores –por ejemplo del sector social-, buscan como
objetivo fundamental el crecimiento económico. Por otra parte los índices de desarrollo
social se han centrado únicamente en los niveles de satisfacción de necesidades
relacionadas como la subsistencia.

El desarrollo convencional tiene serios problemas, como los siguientes:

 Los resultados finales son impredecibles, es decir no se sabe cuándo debe acabar un
proyecto.

 No hay forma de controlar lo que está sucediendo en el proyecto, al no existir fases

establecidas y productos intermedios sobre los que realizar verificaciones.

 Los cambios organizativos afectan negativamente al proceso de desarrollo, no suele

existir documentación estandarizada o no se actualizan oportunamente.

En el desarrollo convencional todo el programa está en un solo bloque, con ejecución

secuencial de instrucciones. Eran los tiempos del ensamblador, las capacidades reducidas
y la necesidad de optimizar al máximo. Se enfoca tanto a las necesidades del cliente y por
lo cual, los programas se hacían sin usar una metodología concreta,solo los
programadores se proponían a construir un código y si contenía errores era muy difícil
prever donde se encontraban.

Desarrollo Estructurado

El desarrollo estructurado comenzó con la programación. A mediados de los 60 el

enfoque estructurado se extiende a la fase de diseño que se conoce como diseño
estructurado, el cual se basa en definir una abstracción más amplia usando los módulos de
programa como componentes básicos de construcción. A mediados de los 70, se empezaron
a surgir las técnicas estructuradas, donde se empezó a construir programas de una forma
artesanal con métodos de ingeniería. El desarrollo estructurado permitió facilitar la
comprensión de programas, normas para la aplicación de estructuras de datos y de control.6

En el diseño estructurado se caracteriza por lo siguiente:

 Mayor nivel de abstracción (independencia del lenguaje programación).

 -Elemento básico de diseño: módulo.

 Modularidad que permite medir la calidad de programas.

 Representa los procesos, flujos y estructuras de datos, de una manera jerárquica y

descendente.

 Ven el sistema como entradas-proceso-salidas.

 Se concentran el la parte del proceso.

 Se lee de porciones, independientes de las especificaciones.

Aunque este desarrollo permite diseñar un buen proceso y estructura de un programa, tiene
inconvenientes como:

 Leer todas las especificaciones para entender el problema.

 Se repetía la misma información en partes diferentes del documento.

 El enfoque de requisitos se interpretaba diferente por cada usuario.

 Cuando se finalizaba el proceso de desarrollo las especificaciones eran obsoletas.

Este enfoque se conoce como análisis estructurado o análisis descendente o top - down.
Desde su aparición se han hecho mejoras como dar menor importancia a la construcción de
los modelos físicos actuales y a los modelos lógicos actuales, diferenciar más los modelos
físicos y lógicos. Ampliar las técnicas de análisis estructurado, para modelar sistemas en
tiempo real y enfocarse en el modelo de datos.
En el desarrollo estructurado los programas están divididos en distintos bloques, estos
bloques tienen funciones que se van confeccionado en forma de arriba-abajo, empezando
desde las generales hasta las particulares, hasta llegar a detallar cada uno de los
procedimientos y su interacción. Este desarrollo se enfoca al diseño del programa y la
compresión se hace mas fácil. Se ha hecho evidente que este enfoque aun está un poco
arraigado ya que se tiende a no pasar de un proceso o iteración a otra, sin culminar con la
anterior, ademas que el ciclo de vida debe recorrerse completo y al manejarse de esta
manera, trae como consecuencias información redundante, costos y desperdicio de tiempo.

Desarrollo Orientado a Objetos

El desarrollo del paradigma de Orientado a Objetos (OO) trata los procesos y datos de
forma conjunta. Este comienza a mediados de los 80 con los lenguajes de programación
Orienta a Objetos en los que se daba énfasis a la abstracción de datos para los que se
adjuntaba un conjunto de operaciones. Por otra parte los conceptos de técnicas
estructuradas han servido de base para muchas de las metodológicas OO.6

La orientación a objetos empieza con los lenguajes de programación orientados a objetos;

en estos lenguajes los problemas del mundo real se representan como un conjunto de
objetos para los que se adjuntan un conjunto de operaciones. Ej: C++, Java.

En la metodología orientada a objetos el sistema se organiza como una colección de objetos

que interactúan entre sí y que contienen tanto estructuras de datos como un
comportamiento. Esto se opone a la programación convencional, en la cual las estructuras
de datos y el comportamiento solamente están relacionadas de forma débil, ya que estos se
enfocan principalmente a las funciones.

Los principios del modelo OO son:7

 Abstracción: Es una descripción simplificada o especificación de un sistema que

enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.
 Encapsulación: En el proceso de ocultar todos los detalles de un objeto que no
contribuyen a sus características esenciales.

 Modularidad: Es la propiedad de un sistema que ha sido descompuesto en un

conjunto de módulos coherentes e independientes.

 Jerarquía o herencia: Es el orden de las abstracciones organizado por niveles.

 Tipificación: Es la definición precisa de un objeto de tal forma que objetos de

diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de
manera muy restringida.

 Concurrencia: Es la propiedad que distingue un objeto que está activo de uno que
no lo está.

 Persistencia: Es la propiedad de un objeto a través de la cual su existencia

trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha
dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de
dirección en que fue creado).

Booch (1986) dice que “si un modelo que se dice OO no contiene alguno de los primeros
cuatro elementos, entonces no es Orientado a Objetos”.

El desarrollo orientado a objetos comprende dividir un programa en clases, donde estas

clases estarán estructuradas por propiedades, atributos, variables, pretendiendo simular y
describir de manera conceptual a un objeto, y lo importante de este desarrollo es que al
usar el principio de encapsulamiento proporciona la ventaja de que se evite interferencias
extrañas entre distintas partes del programa y podemos cambiar la implementación
concreta de un objeto sin afectar al resto del sistema. Actualmente este desarrollo es el que
esta aflorando mas en los aspectos de desarrollo de software ya que permite crear un
modelo parecido a la realidad y ver las cosas como un objeto, es decir, realmente como
son y como se comportan.
Características deseables de una metodología

 Existencia de reglas predefinidas, fases y subfases, tareas, productos intermedios,

técnicas y herramientas tales que se amolden a cualquier desarrollo.

 Cobertura total del ciclo de desarrollo.

 Verificaciones intermedias.

 Planificación y control.

 Comunicación efectiva.

 Utilización sobre un abanico amplio de proyectos.

 Fácil formación.

 Herramientas case.

 La metodología debe contener actividades que mejoren el proceso de desarrollo.

 Soporte al mantenimiento. Por ejemplo. Reingeniería.

 Soporte de la reutilización de software, no solo reutilización de código.

 Actualmente, se huye de métodos muy burocráticos o monolíticos.

Lo que se quiere de una metodología es que permita definir las etapas, las salidas,
entradas de un proyecto. Mantener un programa no es fácil pero se puede lograr, por lo
tanto, las metodologías deben permitir una robusta formación del proyecto que permita
utilizar mecanismos de mejora y que se usen los recursos disponibles con su mayor
rendimiento y eficacia.
Metodologías Vs. Ciclo de vida

Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de

forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de
desarrollo. Una definición estándar de metodología puede ser el conjunto de métodos que
se utilizan en una determinada actividad con el fin de formalizarla y optimizarla. Determina
los pasos a seguir y cómo realizarlos para finalizar una tarea.15

Si esto se aplica a la Ingeniería de software, podemos destacar que una metodología:

 Optimiza el proceso y el producto software.

 Es una guía en la planificación y en el desarrollo del software.

 Define qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento de un

proyecto.
Una metodología define una estrategia global para enfrentarse con el proyecto. Entre los
elementos que forman parte de una metodología se pueden destacar:

 Fases: tareas a realizar en cada fase.

 Productos: E/S de cada fase, documentos.

 Procedimientos y herramientas: apoyo a la realización de cada tarea.

 Criterios de evaluación: del proceso y del producto. Saber si se han logrado los
objetivos.

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando
desde que nace la idea inicial hasta que el software es retirado o remplazado (muere).15

Entre las funciones que debe tener un ciclo de vida se pueden destacar:

 Determinar el orden de las fases del proceso de software.

 Establecer los criterios de transición para pasar de una fase a la siguiente.

 Definir las entradas y salidas de cada fase.

 Describir los estados por los que pasa el producto.

 Describir las actividades a realizar para transformar el producto.

 Definir un esquema que sirve como base para planificar, organizar, coordinar,
desarrollar, entre otros.

Las etapas de un ciclo de vida de un software son:

 Inicio: éste es el nacimiento de la idea. Aquí definimos los objetivos del proyecto y
los recursos necesarios para su ejecución. Hacia dónde queremos ir, y no cómo queremos
ir. Las características implícitas o explícitas de cada proyecto hacen necesaria una etapa
previa destinada a obtener el objetivo por el cual se escribirán miles o cientos de miles de
líneas de código. Un alto porcentaje del éxito de nuestro proyecto se definirá en estas etapas
que, al igual que la etapa de debugging, muchos líderes de proyecto subestiman.

 Planificación: idearemos un planeamiento detallado que guíe la gestión del

proyecto, temporal y económicamente.

 Implementación: acordaremos el conjunto de actividades que componen la

realización del producto.

 Puesta en producción: nuestro proyecto entra en la etapa de definición, allí donde

se lo presentamos al cliente o usuario final, sabiendo que funciona correctamente y
responde a los requerimientos solicitados en su momento. Esta etapa es muy importante no
sólo por representar la aceptación o no del proyecto por parte del cliente o usuario final sino
por las múltiples dificultades que suele presentar en la práctica, alargándose excesivamente
y provocando costos no previstos.

 Control en producción: control del producto, analizando cómo el proceso difiere o

no de los requerimientos originales e iniciando las acciones correctivas si fuesen necesarias.
Cuando decimos que hay que corregir el producto, hacemos referencia a pequeñas
desviaciones de los requerimientos originales que puedan llegar a surgir en el ambiente
productivo. Si nuestro programa no realiza la tarea para lo cual fue creada, esta etapa no es
la adecuada para el rediseño. Incluimos también en esta etapa el liderazgo, documentación
y capacitación, proporcionando directivas a los recursos humanos, para que hagan su
trabajo en forma correcta y efectiva.

Objetivos de cada etapa:

 Expresión de necesidades:Esta etapa tiene como objetivo el armado de un

documento en el cual se reflejan los requerimientos y funcionalidades que ofrecerá al
usuario el sistema a implementar (qué, y no cómo, se va a implementar).

 Especificaciones: Formalizamos los requerimientos; el documento obtenido en la

etapa anterior se tomará como punto de partida para esta etapa.
 Análisis: Determinamos los elementos que intervienen en el sistema a desarrollar,
su estructura, relaciones, evolución temporal, funcionalidades, tendremos una descripción
clara de qué producto vamos a construir, qué funcionalidades aportará y qué
comportamiento tendrá.

 Diseño: Ya sabemos qué hacer, ahora tenemos que determinar cómo debemos
hacerlo (¿cómo debe ser construido el sistema en cuestión?); definimos en detalle entidades
y relaciones de las bases de datos, seleccionamos el lenguaje que vamos a utilizar, el
Sistema Gestor de Bases de Datos, entre otros).

 Implementación: Empezamos a codificar algoritmos y estructuras de datos,

definidos en las etapas anteriores, en el correspondiente lenguaje de programación o para
un determinado sistema gestor de bases de datos. En muchos proyectos se pasa
directamente a esta etapa; son proyectos muy arriesgados que adoptan un modelo de ciclo
de vida de code & fix (codificar y corregir) donde se eliminan las etapas de
especificaciones, análisis y diseño con la consiguiente pérdida de control sobre la gestión
del proyecto.

 Debugging (Depuración): El objetivo de esta etapa es garantizar que nuestro

programa no contiene errores de diseño o codificación. En esta etapa no deseamos saber si
nuestro programa realiza lo que solicitó el usuario, esa tarea le corresponde a la etapa de
implementación. En ésta deseamos encontrar la mayor cantidad de errores. Todas los
programas contienen errores: encontrarlos es cuestión de tiempo. Lo ideal es encontrar la
mayoría, si no todos, en esta etapa. También se pueden agregar pruebas de rendimiento.

 Validación: Esta etapa tiene como objetivo la verificación de que el sistema

desarrollado cumple con los requerimientos expresados inicialmente por el cliente y que
han dado lugar al presente proyecto. En muchos proyectos las etapas de validación y
debugging se realizan en paralelo por la estrecha relación que llevan. Sin embargo, tenemos
que evitar la confusión: podemos realizarlos en paralelo, pero no como una única etapa.

 Evolución: En la mayoría de los proyectos se considera esta etapa como

Mantenimiento y evolución, y se le asigna, no sólo el agregado de nuevas funcionalidades
(evolución); sino la corrección de errores que surgen (mantenimiento). En la práctica esta
denominación no es del todo errónea, ya que es posible que aun luego de una etapa de
debugging y validación exhaustiva, se filtren errores.

Una metodología puede seguir uno o varios modelos de ciclo de vida, adaptándose a cada
uno de ellos, dependiendo de las necesidades dadas en un momento determinado, es decir,
el ciclo de vida indica lo que hay que obtener a lo largo del desarrollo del proyecto pero
no da las indicaciones de como obtenerlo. La metodología indica los diferentes pasos y
fases para obtener los distintos productos parciales y finales. En sí para el desarrollo de
software, se necesita aplicar una metodología o varias metodologías, dentro de un ciclo de
vida, de manera que sepamos que hacer y como hacerlo para conseguir lo que se quiere y
cumplir con las metas planteadas.

Modelos de procesos en el desarrollo de software

Un modelo de proceso para el desarrollo de software es una representación simplificada de

pasos, representada desde una perspectiva específica. Por su naturaleza los modelos son
simplificados, por lo tanto un modelo de procesos del software es una abstracción de un
proceso real. 2
Estos modelos tienen como propósito la producción eficaz y eficiente de un producto
software que reúna los requisitos del cliente. Este proceso es intensamente intelectual,
afectado por la creatividad y juicio de las personas involucradas.La mayoría de los modelos
de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea,
más atrás se encontrará en el proceso de desarrollo. Como todo proceso, están constituido
de pasos o fases que contienen a su vez actividades, estos modelos de desarrollo de
software se basan en un ciclo de vida para desarrollar el mismo, como lo son:

 La necesidad de solucionar un problema (surgimiento de necesidades)

 Inicio del proceso (desarrollo), dentro de esta fase se encuentra la definición del
proyecto, el análisis del contexto, definición de requerimientos, diseño del sistema,
construcción del sistema, pruebas e implantación.

 Operación y mantenimiento, donde realiza ajustes y se buscan fallas.

 Renovación o extinción.
Los procesos de software son complejos debido a que un producto de software es intangible
y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos,
sobre todo cuando no se tiene precedentes en productos software similares. En general este
producto esta compuesto por hardware y software. En cuanto al hardware, su producción se
realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad
está claramente definida. Respecto del software, su construcción y resultados han sido
históricamente cuestionados debido a los problemas asociados

Los modelos de procesos permiten al analista de sistemas desarrollar un plan de requisitos

del software, permiten establecer un trabajo en forma ordenada, además que existen
muchos modelos que se adaptan a las exigencias del proyecto, solo debemos saber cual nos
conviene, pero lo mas importante, es que estos modelos nos llevan a presentar los
proyectos al cliente de manera que éste vea su diseño y sus funciones y que la mayoría de
ellos están orientados al mantenimiento.

Clasificación de las Metodologías según el modelo de proceso

Modelos Convencionales o Prescriptivos de Procesos

Los modelos convencionales o modelos prescriptivos de procesos permiten llenar el marco

de trabajo con un conjunto de tareas orientadas al desarrollo de un software.

Se les llama "prescriptivos" porque presciben un conjunto de elementos del proceso, tales
como:21

 Actividades del Marco de Trabajo.

 Acciones de la Ingeniería del software.

 Tareas.

 Productos de trabajo.

 Aseguramiento de la calidad.
 Mecanismos de control del cambio para cada proyecto.

Estos modelos son útiles si queremos describir un conjunto único de actividades dentro de
un marco de trabajo para un proceso de software. cada actividad debe contener un conjunto
de acciones de ingeniería del software, y definir cada acción en cuanto a un conjunto de
tareas que identifique el trabajo (y los productos del trabajo) que deben completarse para
alcanzar las metas de desarrollo. Sin importar el modelo del proceso que se desee usar, los
ingenieros de software eligen una manera tradicional para realizar el marco de trabajo
genérico para el proceso, ya que estos modelos se caracterizan por ser en esencia
rígidos,estrictos y los mas utilizados.

En las metodologías convencionales, el ciclo de vida de un proyecto, puede definirse como

un ciclo de vida lineal, ya que imponen una disciplina de trabajo sobre el proceso de
desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace
énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo
detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente
en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos,
herramientas y notaciones para el modelado y documentación detallada. Además, las
metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son
métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden
predecirse o bien pueden variar.

Los modelos prescriptivos de proceso definen un conjunto distinto de actividades, acciones,

tareas fundamentos y productos de trabajo que es requieren para desarrollar software de
alta calidad. Los ingenieros de software y sus gerentes deben adaptar un modelo
prescripto de proceso a sus necesidades y después lo siguen. Además, la gente que ha
solicitado el software tiene un papel por desempeñar se ejecuta el modelo de software.
¿Por qué es importante? Porque proporciona estabilidad, control y organización a una
actividad que si no se controla puede volverse caótica. ¿Cuáles son los pasos? El proceso
conduce a un equipo de software a través de un conjunto de actividades del marco de
trabajo que se organizan en un flujo de proceso. ¿Cuál es un obtenido? Desde punto de
vista de un ingeniero de software, los productos de trabajo son los programas, documentos
y datos que se producen como consecuencia de las actividades y tareas que define el
proceso.

Modelo en Cascada

El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere un enfoque
sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación
de requerimientos del cliente y que continúa con la planeación, el modelado, la
construcción y el despliegue para culminar en el soporte del software terminado.

Este modelo es aplicable en donde existen ocasiones en que los requisitos de un problema
se entienden de una manera razonable y deben estar bien definidos, también cuando el
trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal, esta
situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien
definidas a un sistema existente.

El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin
embargo, en las décadas pasadas, las criticas a este modelo de proceso han ocasionado que
aun sus más fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que
algunas veces se encuentran al aplicar el modelo en cascada están:

1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A
pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como
resultado, los cambios confunden mientras el equipo de proyecto actúa.

2. Con frecuencia es difícil para el cliente establecer todos los requisitos de manera
explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la
incertidumbre natural presente en el inicio de muchos proyectos.

3. El cliente debe tener paciencia. Una versión que funcione de los programas estará
disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso si no se
detecta antes de la revisión del programa.

En un análisis interesante de proyectos reales, Bradac(1994) concluyó que la naturaleza

lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales algunos
miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes.
De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El
estado de bloqueo tiende a ser más común al principio y al final del proceso secuencial.

En la actualidad, el trabajo del software está acelerado y sujeto a una cadena infinita de
cambios (de características, funciones y contenido de la información). Con frecuencia, el
modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un
modelo de proceso útil en situaciones donde los requerimientos están fijos y donde el
trabajo se realiza, hasta su conclusión, de una manera lineal.

Las principales etapas de este modelo según Sommerville (2005) son:

 Análisis y definición de requerimientos. Los servicios, restricciones y metas del
sistema se definen a partir de las consultas con los usuarios. Se define una especificación
del sistema.

 Diseño del sistema y del software. El proceso de diseño del sistema divide los
requerimientos en sistemas hardware o software. Establece una arquitectura completa del
sistema. El diseño del software identifica y describe las abstracciones fundamentales del
sistema software y sus relaciones.

 Implementación y prueba de unidades. Durante esta etapa, el diseño del software

se lleva a cabo como un conjunto o unidades de programas.

 Integración y prueba del sistema. Los programas o las unidades individuales de

programas se integran y prueban como un sistema completo para asegurar que se cumplan
los requerimientos del software.

 Funcionamiento y mantenimiento. El sistema se instala y se pone en

funcionamiento práctico. El mantenimiento implica corregir errores no descubiertos en las
etapas anteriores del ciclo de vida.

Algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial
hacia el desarrollo del software, que se inicia con la especificación de requerimiento del
cliente y que continúa con la planeación, el modelo, la construcción, y el despliegue para
culminar en el soporte del software. Es un enfoque pasado de moda pero útil cuando los
requisitos son fijos.
Modelo de Procesos Incrementables

El modelo incremental combina elementos del modelo en cascada aplicado en forma

iterativa.El modelo incremental aplica secuencias lineales de manera escalonada conforme
avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos" del
software. Por ejemplo, el software procesador de texto, desarrollado con el paradigma
incremental en su primer incremento, podría realizar funciones básicas de administración
de archivos, edición y producción de documentos; en el segundo incremento, ediciones más
sofisticadas, y tendría funciones más complejas de producción de documentos; en el tercer
incremento, funciones de corrección ortográfica y gramatical; y en el cuarto, capacidades
avanzadas de configuración de página. Se debe tener en cuenta que el flujo del proceso de
cualquier incremento puede incorporar el paradigma de construcción de prototipos que se
expone más adelante.

A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial.

Es decir, se incorporan los requisitos básicos, pero muchas características suplementarias
(algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del
cliente (o se somete a una evaluación detallada). Como resultado de la evaluación se
desarrolla un plan para el incremento siguiente. El plan afronta la modificación del
producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la
entrega de características y funcionalidades adicionales. Este proceso se repite después de
la entrega de cada incremento mientras no se haya elaborado el producto completo.

El modelo de proceso incremental, al igual que la construcción de prototipos y otros

enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de
prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con
cada incremento. Los primeros incrementos son versiones “incompletas del producto final,
pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo.

El desarrollo incremental es útil sobre todo cuando el personal necesario para una
implementación completa no está disponible. Los primeros incrementos se pueden
implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se
requiere) más personal para implementar el incremento siguiente. Además, los incrementos
se pueden planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande podría
requerir la disponibilidad de un hardware nuevo que está en desarrollo y cuya fecha de
entrega es incierta. Sería posible planear los primeros incrementos de forma que se evite el
uso de este hardware, lo que permitiría la entrega de funcionalidad parcial a los usuarios
finales sin retrasos desordenados.

Combina elementos del modelo en cascada aplicado en forma iterativa. El modelo

incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo
en el calendario. Cada secuencia lineal produce incrementos. Produce entregas de
software pequeñas pero usables (incrementos). Cada parte se construye sobre partes ya
entregadas.
Modelo de desarrollo rápido de aplicaciones (DRA)

El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de software

incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a
"alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido mediante un
enfoque de construcción basado en componentes. Si se entienden bien los requisitos y se
limita el ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un
"sistema completamente funcional" dentro de un periodo muy corto (por ejemplo, de 60 a
90 días).

Como otros modelos de proceso, el enfoque DRA cumple con las actividades genéricas del
marco de trabajo que ya se han presentado. La comunicación trabaja para entender el
problema de negocios y las características de información que debe incluir el software. La
planeación es esencial porque varios equipos de software trabajan en paralelo sobre
diferentes funciones del sistema. El modelado incluye tres grandes fases — modelado de
negocios, modelado de datos y modelado del proceso — y establece representaciones del
diseño que sirven como base para la actividad de construcción del modelo DRA. La
construcción resalta el empleo de componentes de software existente y la aplicación de la
generación automática de código. Por último, el despliegue establece una base para las
iteraciones subsecuentes, si éstas son necesarias.
El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las restricciones
de tiempo impuestas sobre un proyecto DRA exigen un "ámbito de escalas". Si una
aplicación de negocios se puede modular de forma que cada gran función pueda
completarse en menos de tres meses (mediante la aplicación del enfoque ya descrito), ésta
es una candidata para el DRA. Cada gran función se puede abordar mediante un equipo de
DRA por separado, para después integrarlas y formar un todo.

Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes:

1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos
para crear en número correcto de equipos DRA.

2) Si los desarrolladores y clientes no se comprometen con las actividades rápidas

necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos DRA
fallarán.

3) Si un sistema no se puede modular en forma apropiada, la construcción de los

componentes necesarios para el DRA será problemática.

4) Si el alto rendimiento es un aspecto importante, y se alcanzará al convertir interfaces en

componentes del sistema, el enfoque DRA podría no funcionar.

5) El DRA sería inapropiado cuando los riesgos técnicos son altos (por ejemplo, cuando
una aplicación nueva aplica muchas nuevas tecnologías).

Es un modelo de proceso del software incremental que resulta un ciclo de desarrollo corto.
El modelo DRA es una adaptación a alta velocidad del modelo en cascada en el que se
logra el desarrollo rápido mediante un enfoque de construcción basado en componentes.
Hace un uso intensivo de componentes reusables de software con un ciclo de desarrollo
extremadamente corto.

Es importante destacar que los Modelo Prescriptivos proporcionan un conjunto de pautas

para el diseño, uso y reuso de los objetos de aprendizaje, como complemento al proceso de
su descripción, de una manera iterativa o incremental, desde la concepción del objeto de
aprendizaje hasta su reusabilidad a corto, mediano y largo plazo. Pero el éxito en la
creación de cualquier objeto de aprendizaje dependerá de la adecuada aplicación del
proceso de Ingeniería de Software, cuyas etapas facilitan el desarrollo de los objetos de
aprendizaje.

Modelos Evolutivos

Se reconoce que el software al igual que todos los sistemas complejos evoluciona con el
tiempo, los requisitos de gestión y de producto a menudo cambian conforme a que el
desarrollo procede haciendo que el camino que lleva al producto final no sea real. El
desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se
va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o
del usuario final. Los modelos evolutivos son iterativos, se caracteriza por la forma en que
permiten a los ingenieros en software desarrollar versiones cada vez más completas del
software. A continuación se presentan algunos de los modelos que se clasifican en esta
categoría.

 Construcción de prototipos

 Modelos en espiral

 Modelo de desarrollo concurrente

En los modelos evolutivos se produce un sistema inicial que evoluciona según las
necesidades del cliente hasta cumplir con los requisitos de este, para luego producir un
sistema que satisfaga sus necesidades. Este enfoque enlaza las actividades de
especificación, desarrollo y validación.
Construcción de Prototipos

En Ingeniería de software la construcción de prototipos pertenece a los modelos de

desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los
programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea
aprobado es que el desarrollador puede iniciar el verdadero desarrollo del software.

El diseño rápido se basa en una representación de aquellos aspectos del software que serán
visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el
usuario y el formato de los despliegues de salida). El diseño rápido conduce a la
construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una
retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará.
La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente.
Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el
cliente vea resultados a corto plazo.
La construcción de prototipos se puede utilizar como un modelo del proceso independiente.
Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos
ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el
resultado de la construcción cuando los requisitos estén satisfechos.

Etapas:

 Plan rápido.

 Modelado, diseño rápido.

 Construcción del Prototipo.

 Desarrollo, entrega y retroalimentación.

 Comunicación.

Ventajas:

 Este modelo es útil cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

 También ofrece un mejor enfoque cuando el responsable del desarrollo del software
está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o
de la forma que debería tomar la interacción humano-máquina.

 Reduce el riesgo de construir productos que no satisfagan las necesidades de los

usuarios.

 Reduce costos y aumenta la probabilidad de éxito.

 Exige disponer de las herramientas adecuadas.

 Una vez identificados todos los requisitos mediante el prototipo, se construye el

producto de ingeniería.

Desventajas:
 El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al
sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen
desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo
que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha
cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre
ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo,
pero partiendo de un estado poco recomendado.

 El desarrollador suele tomar algunas decisiones de implementación poco

convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque
proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede
olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de
que dichas elecciones pasen a formar parte del sistema final.

Cuando el cliente define el software que desea que el analista construya, pero no identifica
los requisitos detallados de entrada, procesamiento o salida. El responsable del desarrollo
del software está inseguro de la adaptabilidad del sistema operativo o de la forma que
debería tomar la interacción hombre – máquina, entonces en este caso es cuando se puede
emplear la construcción de prototipos. Se crea un diseño rápido que se centra en una
representación de aquellos aspectos del software que serán visibles para el usuario final, a
su vez el diseño rápido conduce a la construcción de un prototipo. Después, el prototipo lo
evalúa el usuario y con la retroalimentación se refinan los requisitos del software que se
desarrollará.
Modelo en Espiral

El modelo en espiral representa en forma de espiral una secuencia de actividades.2 Este

modelo fue originalmente propuesto por Boehm en 1988, y se diferencia de los demás
modelos por considerar el riesgo. El modelo en espiral para la ingeniería de software es
actualmente el enfoque más realista para el desarrollo de software y de sistemas a gran
escala. Utiliza un enfoque evolutivo, permitiendo al desarrollador y al cliente entender y
reaccionar ante los riesgos en cada nivel evolutivo.2

El modelo en espiral se divide en un número de actividades estructurales, también llamadas

regiones de tareas, según Sommerville (2005) el ciclo de vida del modelo en espiral se
divide cuatro sectores:

1. Definición de objetivos. En esta fase se identifica las restricciones del proceso y le

producto, y dependiendo los riesgos para trazar objetivos y respectivamente panes
estratégicos.

2. Evaluación y reducción de riesgos. Se hace un análisis detallado para casa riesgo y se

establece los pasos para reducirlos.

3. Desarrollo y validación. Después de evaluar los riesgos, se elige un modelo para el

desarrollo del sistema.
4. Planificación. El proyecto se revisa y se toma la decisión de si debe continuar con un
ciclo posterior de la espiral.

Las características que se pueden indicar del modelo en espiral son:

 El software se desarrolla en una serie de versiones increméntales. Durante las

primeras iteraciones.

 La versión incremental podría ser un modelo en papel o un prototipo.

 A medida que se va incrementando el número de iteraciones, se producen versiones

cada vez mas completas.

Ventajas:

 Puede adaptarse y aplicarse a lo largo de la vida del software.

 Como el software evoluciona, a medida que progresa el proceso, el desarrollador y

el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles
evolutivos.

 Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en

cualquier etapa de evolución del producto.

 Demanda una consideración directa de los riesgos técnicos en todas las etapas del
proyecto. Reduce los riesgos antes de que se conviertan en problemáticos.

Desventajas:

 Puede resultar difícil convencer la grandes clientes de que el enfoque evolutivo es

controlable (particularmente en situaciones de contrato).

 Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán

problemas.

 Como es un modelo relativamente nuevo no es muy utilizado.

 Otros inconvenientes que pueden surgir es convencer al cliente que es un enfoque
controlable,por lo que se requiere de experiencia en la identificación de riesgos y
refinamiento para su uso generalizado.

Lo característico del modelo es espiral es que incluye un “análisis de riesgo” es decir que
podemos analizar si el proyecto puede continuar o mejor lo suspendemos. Este modelo se
basa en que antes de hacer algo debemos analizarlo, también debemos buscar varias
opciones de resolución de problemas para de allí escoger la opción más conveniente, y
además analizar los riesgos que se pueda tener. Este modelo necesita de otros métodos
para poder desarrollarse.
Modelo de desarrollo concurrente

Davis Sitaram describe el modelo de desarrollo concurrente de la siguiente forma:18

"Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere
a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus
proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples.
Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay
personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases
de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos
diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo
tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han
mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El
trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación
concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero
falla en capturar la riqueza de la concurrencia que existe en todas las actividades del
desarrollo y de gestión del software en mi proyecto...La mayoría de los modelos de
procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas
atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta
dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las
revisiones."

Acorde con la descripción de Davis podemos decir que el modelo concurrente se define una
serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las
actividades de la ingeniería del software proporcionando una visión certera del estado
actual del proyecto. Se puede representar en forma de esquema como una serie de
actividades técnicas importantes, tareas y estados asociados a ellas. 19

Funcionalidad del proceso:

 Cada actividad, acción o tarea dentro de la red existe de manera simultánea con
otras.

 Los sucesos generados dentro de una actividad dada o algún otro lado de la red de
actividad inicia las transiciones entre los estado de una actividad.

El modelo de proceso concurrente se utiliza como paradigma de desarrollo de aplicaciones

cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes
funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define
actividades en dos dimensiones: una división de sistemas y una división de componentes.
Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y
realización.

La concurrencia se logra de dos formas:

1. Las actividades del sistema y de componente ocurren simultáneamente y pueden
modelarse con el enfoque orientado a objetos descrito anteriormente. 2. Una aplicación
cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se
pueden diseñar y realizar concurrentemente.

Ventajas:

 Excelente para proyectos en los que se conforman grupos de trabajo independientes.

 Proporciona una imagen exacta del estado actual de un proyecto.

Desventajas:

 Si no se dan las condiciones señaladas no es aplicable.

 Si no existen grupos de trabajo no se puede trabajar en este método

Modelos iterativos

Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el
producto final por malos entendidos durante la etapa de recogida de requisitos. Consiste en
la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al
cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es
quien después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas
iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del
cliente. 15

El modelo iterativo se suele utilizar en proyectos en los que los requisitos no están claros
por parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para
presentarlos y conseguir la conformidad del cliente. Cada iteración es un mini proyecto en
cascada auto contenido compuesto de actividades como análisis de requerimientos, diseño,
programación y pruebas.15

Ventajas:

 Permite crear cada vez versiones más completas de software

 Resolución de problemas de alto riesgo en tiempos tempranos del proyecto.

 Visión de avance en el desarrollo desde las etapas iniciales del desarrollo.

 Menor tasa de fallo del proyecto, mejor productividad del equipo, y menor cantidad
de defectos

 El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y

mejorando las planificaciones, logrando menores desvíos en la duración total del proyecto.

Desventajas:

 Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes
que simplemente no estarán dispuestos a invertir el tiempo necesario.

 Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el

cliente, requiriendo de profesionales sobre el promedio.

Una de las grandes ventajas que ofrece este modelo es que los requisitos se pueden ir
refinando en cada una de las iteraciones, es decir cuando no se puede especificar a priori
“todos” los requisitos del software, sino que este proceso ayudará a ir descubriendo paso
a paso los requisitos a partir de cada nueva entrega, mediante iteraciones las cuales no
son mas que mini proyectos en cascada, en este modelo el cliente tiene la oportunidad de
incluir o desechar elementos al final de cada iteracion, buscando cada vez versiones mas
ccompletas hasta que cumpla sus espectativas o se adapte a sus necesidades

Modelos de Desarrollo Ágiles

Las metodologías ágiles son un conjunto de métodos de ingeniería del software, que se
basan en el desarrollo iterativo e incremental, teniendo presente los cambios y
respondiendo a estos mediante la colaboración de un grupo de desarrolladores auto-
organizados y multidisciplinares.
En las metodologías ágiles, los procesos se desarrollan de manera solapada, donde el ciclo
de vida del proyecto, es cíclico. La diferencia en el ciclo de vida de un proyecto ágil, en
comparación con uno tradicional, se debe a la forma en la que el agilismo, solapa los
procesos de manera iterativa.

La tendencia del control de procesos para desarrollo de software ha traído como resultado
que proyectos no resulten exitosos debido al cambiante contexto que existe, por lo cuál las
metodologías ágiles pretende resolver este inconveniente, construyendo soluciones a la
medida asegurando la calidad. Los métodos ágiles fueron pensados especialmente para
equipos de desarrollo pequeños, con plazos reducidos, requisitos volátiles y nuevas
tecnologías. La filosofía de las metodologías ágiles, pretenden dar mayor valor al
individuo, a la colaboración con el cliente y al desarrollo incremental del software con
iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con
requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de
desarrollo pero manteniendo una alta calidad.14

La dirección del enfoque de establecer una metodología que solventara los cambios
drásticos del ambiente, dió origen en febrero de 2001, tras una reunión celebrada en Utah-
EEUU, en esta reunión participan un grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo
fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software
rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se
pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales
(metodologías pesadas), caracterizados por ser rígidos y dirigidos por la documentación que
se genera en cada una de las actividades desarrolladas.

La fundación del manifiesto ágil, una organización, sin ánimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las
organizaciones para que adopten dichos conceptos, promovió a que los grupos de
desarrolladores se enfocarán y establecierán los siguientes valores:

 Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas. La gente es el principal factor de éxito de un proyecto software. Es más
importante construir un buen equipo que construir el entorno. Muchas veces se comete el
error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es
mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus
necesidades.

 Desarrollar software que funciona más que conseguir una buena documentación. La
regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata
para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo
fundamental.

 La colaboración con el cliente más que la negociación de un contrato. Se propone

que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta
colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.

 Responder a los cambios más que seguir estrictamente un plan. La habilidad de

responder a los cambios que puedan surgir a los largo del proyecto (cambios en los
requisitos, en la tecnología, en el equipo, entre otros) determina también el éxito o fracaso
del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
La fundación del manifiesto ágil, una organización, sin ánimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las
organizaciones para que adopten dichos conceptos, promovió a que los grupos de
desarrolladores se enfocarán y establecierán los siguientes valores:

 Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las

herramientas. La gente es el principal factor de éxito de un proyecto software. Es más
importante construir un buen equipo que construir el entorno. Muchas veces se comete el
error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es
mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus
necesidades.

 Desarrollar software que funciona más que conseguir una buena documentación. La
regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata
para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo
fundamental.

 La colaboración con el cliente más que la negociación de un contrato. Se propone

que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta
colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.

 Responder a los cambios más que seguir estrictamente un plan. La habilidad de

responder a los cambios que puedan surgir a los largo del proyecto (cambios en los
requisitos, en la tecnología, en el equipo, entre otros) determina también el éxito o fracaso
del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

Estos valores inspiraron los doce principios del manifiesto ágil:

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software

que le aporte un valor.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que

necesitan y confiar en ellos para conseguir finalizar el trabajo.

VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.

VII. El software que funciona es la medida principal de progreso.

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener una paz constante.

IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

X. La simplicidad es esencial.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí
mismos.

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo,
y según esto ajusta su comportamiento.

En definición las metodologías ágiles son un conjunto de métodos de ingeniería del

software, que se basan en el desarrollo iterativo e incremental, teniendo presente los
cambios y respondiendo a estos mediante la colaboración de un grupo de desarrolladores
auto-organizados y multidisciplinares.

Las características esenciales del proceso de desarrollo ágil para la mayoría de los
proyectos son las siguientes:

 Busca la satisfacción del cliente.

 Entrega temprana de software incremental.

 Utilizan métodos informales.

 Simplicidad general del desarrollo.

 La comunicación entre los desarrolladores y los clientes durante el desarrollo del

proyecto debe ser activa y continua.

 La idea es que se mantenga un canal de retroalimentación con el cliente, a traves de

entregas de prototipos ejecutable o porción de un sistema operacional, en periodos cortos
para que la adaptabilidad mantenga un buen ritmo con el cambio.

Programación Extrema (XP)

La programación extrema (XP, extreme Programming) es un modelo de proceso de

software el fue acuñado por Beck el cual toma los principios y practicas aceptadas y las
lleva a niveles extremos. Tiene como objetivo reducir el riesgo en el ciclo de vida del
software mediante grupos de desarrollo pequeños, considera que la mejor manera de tratar
la falta de requisitos estables en un sistemas, es mediante la agilidad de un grupo pequeño
de desarrollo 8 . Esta se basa en la simplicidad, la comunicación y el reciclado continuo de
código. El modelo considera varios aspectos problemáticos del desarrollo de software como
lo son los retrasos , proyectos cancelados, cambios en el negocio y la rotación del personal.
Sus actividades básicas son : Codificar, hacer pruebas, escuchar y diseñar.

Los objetivos de XP son muy simples:

1. La satisfacción del cliente: trata de dar al cliente el software que él necesita y cuando lo
necesita.

2. Potenciar al máximo el trabajo en grupo: Tanto los jefes de proyecto, los clientes y
desarrolladores, son parte del equipo y están involucrados en el desarrollo del software.

XP define cuatro variables para proyectos de software: coste, tiempo, calidad y ámbito.
Además de estas cuatro variables, Beck propone que sólo tres puedan ser establecidas por
las fuerzas externas (jefes de proyecto y clientes), mientras que el valor de la cuarta
variable debe ser establecido por los programadores en función de las otras tres. 8

Los valores originales de la programación extrema son:4

 Simplicidad: XP propone el principio de hacer la cosa más simple que pueda

funcionar, en relación al proceso y la codificación. Esta es la base de la programación
extrema.

 Comunicación: Los programadores se comunican constantemente gracias a la

programación por parejas y además la comunicación con el cliente es fluida ya que el
cliente forma parte del equipo de desarrollo

 Retroalimentación: retroalimentación concreta y frecuente del cliente, del equipo y

de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo.

 Coraje o valentía : La valentía le permite a los desarrolladores que se sientan

cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema
existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente.

Principios básicos en la Programación extrema: 9

 Planificación Incremental: los requerimientos se registran en tarjetas de historias,

estas incluyen el tiempo y la prioridad relativa.

 Entregas pequeñas: estas entregas son frecuentes e incrementalmente añaden

funcionalidad al primera entrega

 Diseño sencillo: solo se lleva a cabo el diseño necesario para cumplir los
requerimientos actuales

 Desarrollo previamente probado; se utiliza un sistema de pruebas, para escribir

pruebas de las nuevas funcionalidades antes de que estas se implementen.

 Refactorización: conserva el código sencillo y mantenible.

 Programación en parejas: esta es la mas importante de todos los principios, los
desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro,
proporcionando la ayuda para hacer siempre un buen trabajo

 Propiedad colectiva: las parejas trabajan en todas las áreas del sistema.

 Integración continua: cuanto acaba el trabajo en una tarea, se integra en el sistema

entero.

 Ritmo sostenible: No se consideran aceptables grandes cantidades de horas extras,

ya que a menudo, reduce la calidad del codigo y la productividad a medio plazo.

 Cliente presente: Debe estar disponible al equipo de XP, un represente de los

usuarios finales del sistema a tiempo completo. En un proceso XP el cliente es parte del
equipo de desarrollo

La programación extrema es uno de los método ágiles más conocido y ampliamente

utilizados, donde el usuario o cliente forma parte del equipo de trabajo, engloba en una
serie de principios dentro de los más importantes se encuentra la programación en parejas
y el desarrollo de pruebas, así como también reulitización de los códigos. Para el uso de
XP los requerimientos deben de estar bien definidos, mediante las historias de usuario.
Este modelo se basa en la retroalimentación continua entre el cliente y el equipo de
desarrollo, especialmente muy utilizada para proyectos con requisitos imprecisos y muy
cambiantes, centrada en potenciar las relaciones interpersonales como clave para el éxito
en el desarrollo de software, promoviendo el trabajo en equipo y preocupándose por el
aprendizaje de los desarrolladores y la satisfacción del cliente

Desarrollo Adaptativo del Software (DAS)

El desarrollo adaptativo de software (DAS) 1998 fue propuestos por Jim Highsmith
como una metodología para desarrollar el software y sistemas muy complejos. Este se
centra en la colaboración humana y la organización del equipo 2. El Desarrollo adaptativo
del software proporciona un marco para el desarrollo iterativo de sistemas grandes y
complejos, el mismo fomenta el desarrollo iterativo e incremental con el uso de prototipos.

El ciclo de vida del DAS se conforma de tres fases: Especulación, colaboración y

aprendizaje

- Fase de especulación: Es la primera de las fases esta inicia en el desarrollo del proyecto.
Se utiliza información como la visión del cliente, las restricciones del proyecto y los
requisitos básicos para definir el conjunto de ciclos en el que se harán los incrementos del
software. En esta fase es donde se lleva a cabo la planificación tentativa del proyecto en
función de las entregas que se iran realizando

- Fase de colaboración: Se busca que el equipo colabore inmensamente para lograr la

funcionalidad planeada, se comunique o se encuentre completamente integrados, se desea
que exista confianza, donde se puedan realizar críticas constructivas y ayudar si
resentimientos, así como también comunicar de una forma oportuna los problemas que se
presenten para tomar acciones efectivas y poseer un conjunto de actitudes que contribuyan
al trabajo que se encuentran realizando.

- Fase del aprendizaje: consiste en la revisión de calidad que se realiza al final de cada
ciclo, esto permite mejorar el entendimiento real sobre la tecnología, los procesos utilizados
y el proyecto. El aprendizaje individual permite al equipo tener mayor posibilidad de éxito.

Esta metodología no proporciona el tipo de prácticas detalladas como lo hace XP, pero
proporciona la base fundamental de por qué el desarrollo adaptable es importante y las
consecuencias a los más profundos niveles de la organización y la gerencia. Los apoyos
filosóficos del DAS se enfocan en la colaboración humana y la organización propia del
equipo, y es un modelo para la construcción de software y sistemas complejos, incluye tres
fases que son: especulación, colaboración y aprendizaje, cada una de estas fases son
fundamental para el desarrollo de la otra. Es adaptativo, se hace uso de la reutilización del
código para adaptarlo a lo que se desea
Modelo de Desarrollo de Sistemas Dinámicos (MDSD)

Es un metodo de desarrollo agil de software que apoyado por su continua implicacion del
usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos
cambiantes, para desarrollar un sistema que reuna las necesiadades de la empresa en tiempo
y presuspuesto. Este se caracteriza por proporcionar un marco de trabajo el cual permita
construir y mantener sistemas con restricciones de tiempo muy estrechas mediante el
empleo de la construcción de prototipos increméntales en un ambiente de proyecto
controlado 10

El MDSD comienza con un estudio de viabilidad y de negocio, son las primeras actividades
que deben realizarse

 Estudio viabilidad: Se evalúa si la aplicación es viable, para el proceso teniendo en

cuenta los requisitos básicos del negocio y sus restricciones asociadas.

 Estudio de negocios: establece los requisitos funcionales y de información que

permitirán que la aplicación proporcione un valor al negocio; también define la arquitectura
básica de la aplicación.

El resto del proceso forma tres ciclos iterativos que son:

 Iteración de modelo funcional: produce una serie de prototipos increméntales que

demuestran la funcionalidad para el cliente. Su propósito durante este ciclo es recopilar
requisitos adicionales y producir documentación de análisis.

 Iteración de construcción y diseño: revisa la construcción de prototipos durante la

iteración del modelo funcional, en este se diseña el sistema para el uso operacional. En
algunos casos, la iteración del modelo funcional y esta, suceden en forma concurrente.

 Implementación: coloca el incremento de software más reciente en el ambiente

operativo, se ocupa del despliegue al uso operacional. Puede destacarse que 1) el
incremento puede no estar 100 por ciento completo o 2) se pueden requerir cambios cuando
el incremento se coloca en el sitio.
El modelo de desarrollo de sistemas dinámicos tiene como objetivo fundamental la entrega
de sistemas software en tiempo y presupuesto , ajustándose a los cambios de requisitos que
puedan surgir durante el proceso de desarrollo. Para su implementación se hacen dos
estudios principalmente el de negocio y el de viabilidad, para posteriormente dar inicio a
sus 3 ciclos de vida . Al igual que XP el desarrollo es iterativo e incremental así como
también basado por la retroalimentación del usuario, de esa manera logrando converger
la solución del negocio mas efectiva. Ademas de lo mencionado anteriormente el MDSD
incluyen enttregas frecuentes, equipos autorizados, y pruebas a lo largo de todo su ciclo

Modelo Scrum

Scrum es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar
al máximo la productividad de un equipo, fue desarrollado por Jeff Sutherland y elaborado
más formalmente por Ken Schwaber. 11. Se enfoca en el hecho de que procesos definidos y
repetibles sólo funcionan para atacar problemas definidos y repetibles con gente definida y
repetible en ambientes definidos y repetibles. Y se divide un proyecto en iteraciones (que
ellos llaman carreras cortas) de 30 días. La literatura de Scrum se orienta principalmente en
la planeación iterativa y el seguimiento del proceso 12

Caracteristicas:

 Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos,

prácticas de desarrollo, implementación y demás cuestiones técnicas.

 Hace uso de Equipos auto-dirigidos y auto-organizados

 Puede ser aplicado teóricamente a cualquier contexto en donde un grupo de gente

necesita trabajar junta para lograr una meta común.

 Desarrollo de software iterativos incrementales basados en prácticas agiles

 Iteraciones de treinta días; aunque se pueden realizar con mas frecuencia, estas
iteraciones, conocidas como Sprint
 Dentro de cada Sprint se denomina el Scrum Master al Líder de Proyecto quien
llevará a cabo la gestión de la iteración

 Se convocan diariamente un “Scrum Daily Meeting” el cual representa una reunión

de avance diaria de no más de 15 minutos con el propósito de tener realimentación sobre las
tareas de los recursos y los obstáculos que se presentan. En la cual se responden preguntas
como: ¿Qué has hecho desde el ultimo encunetro? ¿Qué obstaculos hay para cumplir la
meta? ¿Qué haras antes del proximo encuentro?

Ciclo de Vida de Scrum

En cuanto al ciclo de vida del modelo Scrum es el siguiente 12:

1. Pre-Juego / Planeamiento: El propósito es establecer la visión, definir expectativas y

asegurarse la financiación. Las actividades son la escritura de la visión, el presupuesto, el
registro de acumulación o retraso Metodologías Ágiles (backlog) del producto inicial y los
ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los
prototipos. El registro de acumulación es de alto nivel de abstracción.

2. Pre-Juego / Montaje (Staging): El propósito es identificar más requerimientos y

priorizar las tareas para la primera iteración. Las actividades son planificación, diseño
exploratorio y prototipos.

3. Juego / Desarrollo: El propósito es implementar un sistema listo para entrega en una

serie de iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son un
encuentro de planeamiento de corridas en cada iteración, la definición del registro de
acumulación de corridas y los estimados, y encuentros diarios de Scrum.

4. Pos-Juego/ Liberación: El propósito es el despliegue operacional. Las actividades,

documentación, entrenamiento, mercadeo y venta.

Scrum es una metodología para la gestión y desarrollo de software basada en un proceso

iterativo e incremental, uno de sus principios claves radica en el reconocimiento de que
durante un proyecto los clientes pueden cambiar sus pensamientos sobre lo que quieren y
necesitan. En este modelo se hacen reuniones diarias o también denominadas reuniones
cortas (15 min aprox) donde se discute lo que se hizo, lo que se hace, y lo que
posteriormente se hará . Es una ayuda para organizar a las personas y el flujo de trabajo,
es importante destacar que en este modelo los equipos son auto-organizados (no auto-
dirigidos), con margen de decisión suficiente para tomar las decisiones que consideren
oportunas.

Desarrollo conducido por características (DCC)

El desarrollo conducido por características (DCC) lo concibieron originalmente Peter Coad

como un modelo de proceso práctico para la ingeniería del software orientada a objetos.
Stephen Palmer y John Felsin han extendido y mejorado el trabajo de Coad, al describir un
proceso adaptativo y ágil que puede aplicarse en proyectos de software de tamaño
moderado y grande. En el contexto del DCC una característica "es una función evaluada
por el cliente que puede implementarse en dos semanas o menos”.13

Beneficios que se le concede a la definición de características:13

 Las características se pueden organizar en un agrupamiento jerárquico relacionado

con el negocio.

 Como las características son bloques pequeños de funcionalidad entregable, los

usuarios las describen con mayor facilidad, pueden entender cómo éstas se relacionan con
otras con mayor rapidez, y pueden revisarlas de mejor manera en búsqueda de
ambigüedades, errores u omisiones.

 Una característica es el incremento de software entregable, el equipo desarrolla

características operativas cada dos semanas.

 Debido a que las características son pequeñas, sus diseños y representaciones de

código son más fáciles de inspeccionar de manera efectiva
El DCC se encuentra dividido en cinco fases o actividades:13

1. Desarrollar un modelo General 2. Elaborar una lista de características 3. Plan por

características 4. Diseño por características 5. Construcción por características

El desarrollo de un modelo general: En una fase ya se tiene el dominio, el contexto, y los

requerimientos del sistema a construir. En este momento se posee información básica de las
especificaciones funcionales. referencias

La construcción de la lista de características los ensayos, modelos de objetos y

documentación de requerimientos proporcionan la base para construir una amplia lista de
características . Las funciones se agrupan conforme a diversas actividades en áreas de
dominio especificas y la lista de características es revisada por los usuarios para asegurar su
validez y exhaustividad

El diseño y la construcción por características, se selecciona las características a

desarrollar y los equipos dispuestos por cada una de ellas. Luego se procede iterativamente
hasta que se producen las características seleccionadas.

El desarrollo conducido por características es un modelo de proceso práctico para la

ingeniería de software orientada a objetos debido a que las características se pueden
organizar en un grupos relacionado con el negocio, y este busca que el equipo de proyecto
desarrolle las características o funciones que son evaluadas por el cliente, las cuales
pueden ser implementadas en un corto tiempo de dos semanas o menos, es un modelo que
se enfoca más hacia la parte de la dirección y gestión de proyectos

Proceso Unificado de Rational (RUP)

El Proceso Unificado de Rational es una metodología de desarrollo de software orientada a

objetos creada por Rational Software Corporation.

Es una de las metodologías más extendidas y conocidas por su amplia difusión comercial.
Se puede estudiar como una metodología representativa de tipo clásico. Fue definido por
los creadores del UML unificando los métodos de Ivar Jacobson, Grady Booch y James
Rumbaugh. El hecho de que la empresa RATIONAL también distribuya herramientas
específicas basadas en el mismo método, que facilitan el desarrollo, ha contribuido a su
gran expansión. 16

Este proceso se maneja por casos de uso (correspondientes a los modos uso por los actores
o agentes usuarios) para la extracción de requisitos y la identificación de las partes
funcionales en las que se divide la solución. La arquitectura del proceso se modela con
orientación a objetos.

Estos metodologistas, fueron reunidos por Rational para formar un marco de metodologías
unificadas, cohesivas y comprehensivas de desarrollo de sistemas de software. Su trabajo,
que producen durante varios años y basados en metodologías probadas, han dado a lugar a
importantes normas en la comunidad de desarrollo,

Como toda metodología de desarrollo software su finalidad es convertir las

especificaciones que da el cliente en un sistema software. Las características que tiene el
RUP. son:

 Está basado en componentes. Estos componentes a su vez están conectados

entre sí a través de interfaces.

 Utiliza el UML como notación básica.

 Dirigido por casos de uso. El proceso utiliza Casos de Uso para manejar el proceso
de desarrollo desde la Incepción hasta el Despliegue.

 Centrado en la arquitectura. El proceso busca entender los aspectos estáticos y

dinámicos más significativos en términos de arquitectura de software. La arquitectura se
define en función de las necesidades de los usuarios y se determina a partir de los Casos de
Uso base del negocio.

 Ciclo de vida iterativo e incremental. El proceso reconoce que es práctico dividir

grandes proyectos en proyectos más pequeños o mini-proyectos. Cada mini-proyecto
comprende una iteración que resulta en un incremento. Una iteración puede abarcar la
totalidad de los flujos del proceso. Las iteraciones son planificadas en base a los Casos de
Uso.

Proceso de cuatro fases

El proceso Unificado consta de ciclos que puede repetir a lo largo del ciclo de vida de un
sistema. Un ciclo consiste en cuatro fases: Incepción, Elaboración, Construcción y
Transición. Un ciclo concluye con una liberación, tambien hay versiones dentro de un ciclo.

Esta es una descripción breve de las fases de un ciclo:

 Fase de Incepción: Durante la fase inicial se concibe la idea central del producto,
se arma el documento de visión. En esta fase, se revisan y confirma nuestro entendimiento
sobre los objetivos centrales del negocio. Queremos entender los argumentos comerciales
en favor de porqué el proyecto debe intentarse. La fase de incepción establece la viabilidad
del producto y delimita el alcance del proyecto.

Se describe el producto final. Se responde a las preguntas:

¿Cuáles son las principales funciones del sistema para sus usuarios más importantes?. La
respuesta está en el modelo de casos de uso simplificado.

¿Cómo podría ser la arquitectura del sistema?

¿Cuál es el plan del proyecto y cuánto costará desarrollar el producto?

 Fase de Elaboración: Durante la fase de elaboración la mayoría de los Casos de

Uso son especificados en detalle y la arquitectura del sistema es diseñada. Esta fase se
focaliza en las “-bilidades” del proyecto. Se identifican los riesgos significativos y se
preparan el calendario, el equipo de trabajo y el costo del proyecto.

 Fase de Construcción: Durante la fase de construcción, el foco del producto se

mueve de la arquitectura de base a un sistema lo suficientemente completo como para
llevarlo al usuario. El baseline de arquitectura crece en complejidad y se convierte en un
sistema completo, de la misma manera, se refina el diseña para llevarlo a código fuente.
Se construye el producto, se utilizan la mayor parte de los recursos, y al finalizar se cubren
todos los casos de uso. La pregunta que se realiza es: ¿ Cubre el producto las necesidades
de los usuarios como para hacer una primera entrega?

 Fase de Transición: En la fase de transición el objetivos es garantizar que los

requisitos se han cumplido, con la satisfacción de las partes interesadas. Esta fase a menudo
se inicia con una versión beta de la aplicación. Otras actividades incluyen la preparación
del ambiente, se completan, se identifican y corrigen defectos. La fase de transición termina
con un cierre dedicado al aprendizaje de lecciones, las cuales quedan para futuros ciclos.El
producto existe en versión Beta.

La metodología de RUP es una forma disciplinada de asignar tareas y responsabilidades

en una empresa de desarrollo (quién hace qué, cuándo y cómo), este proceso de RUP
estiman tareas y horario del plan midiendo la velocidad de iteraciones concerniente a sus
estimaciones originales. RUP se enfocan fuertemente sobre la arquitectura del software.
para su implementación se hace a través de cuatro etapas o fases y en cada una de estas
etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el
ciclo de vida en cascada a menor escala, este tiene grandes ventajas con respectos a XP,
ya que se enfoca en los requisitos y el diseño, así como también el cliente interactúa con el
equipo de desarrollo mediante reunionesa diferencia de la metodología XP que el cliente
es parte del equipo
Diferencias entre los modelos de proceso convencionales y ágiles

Metodologías ágiles:

 Están basadas en heurística provenientes de prácticas de producción de códigos.

 Están preparadas para cambios durante el proyecto.

 Son impuestas internamente (por el equipo).

 Proceso menos controlado.

 No existe contrato tradicional.

 Son bastante flexibles.

 El cliente es parte del equipo de desarrollo.

 Grupos pequeños y trabajando en el mismo sitio.

 Menos énfasis en la arquitectura del software.

Metodologías convencionales:

 Basadas en normas provenientes de estándares.

 Presentan cierta resistencia a los cambios.

 Impuestas externamente.

 Proceso mucho mas controlado, con numerosas políticas.

 Existe un contrato prefijado.

 Son un poco rígidas.

 El cliente interactúa con el equipo de desarrollo mediante reuniones.

 Grupos grandes y posiblemente distribuidos.

 La arquitectura del software es esencial y se expresa mediante modelos.

Clasificación de las metodologías según su enfoque

Metodologías estructuradas

Se basan en la forma top-down. Entre estas están:

Metodologías orientadas a procesos

Se basan en la utilización de un método descendente de descomposición funcional para

definir los requisitos del sistema, dan lugar a un nuevo concepto "la especificación
estructurada" que es un modelo gráfico particionado, descendente y jerárquico de los
procesos del sistema.

La metodología orientada a procesos está compuesta por:

 Diagrama de flujo de datos: Estos son diagramas que representan los procesos de
datos que deben llevar acabo un sistema a distintos niveles de abstracción y los datos que
hay entre las funciones.

 Diccionario de datos: Es el conjunto de las definiciones de todos los datos que

aparecen en el diagrama de flujos de datos.

 Especificaciones de procesos: como se obtienen las salidas del proceso a partir de

sus entradas.

Las metodologías orientadas a procesos comprende una fase de análisis estructurado y los
métodos de DeMarco, Gene y Sarson, Yourdon, son algunos que permiten lograr esto.

 Metodología de Demarco: se basa en el estudio del sistema físico actual, derivación

del modelo lógico actual, derivación al nuevo modelo lógico y creación de modelos físicos
alternativos.

 Metodología de Gane y Sarson: Es parecida a la de Demarco, la diferencia es que

elimina el primer paso y crea uno nuevo que es cuando construye el modelo lógico del
sistema. También construye un modelo lógico de datos.

 Metodología de Yourdon: Realiza los DFDs del sistema, a partir de los DFD realiza
el diagrama de estructuras, evaluación del diseño y preparación del diseño.

Metodologías orientadas a datos

Son metodologías basadas en la información, ya que los datos son más estables que los
procesos. Primero se definen las estructuras de datos y, a partir de éstos, se derivan los
componentes procedimentales.

Ejemplos de esta clasificación son: metodologías de Jackson, Warnier, Warnier-Orr.

Estas metodologías se dividen en jerárquicas y no jerárquicas:

Metodología orientada a datos jerárquicas:

 La estructura de control del programa debe ser jerárquica y se debe derivar de la
estructura de datos del programa.

 El proceso de diseño consiste en definir primero las estructuras de los datos de

entrada y salida, mezclarlas todas en una estructura jerárquica de programa y después
ordenar detalladamente la lógica procedimental para que se ajuste a esta estructura.

 El diseño lógico debe preceder y estar separado del diseño físico.

Metodología orientada a datos no jerárquicas:

Metodología Ingeniería de la Información.

 Planificación: construir una arquitectura de la Información y una estrategia que

soporte los objetivos de la organización .

 Análisis: comprender las áreas del negocio y determinar los requisitos del sistema.

 Diseño: establecer el comportamiento del sistema deseado por el usuario y que sea
alcanzable por la tecnología.

 Construcción: construir sistemas que cumplan los tres niveles anteriores.

Las metodologías estructuradas están orientadas a procesos y a objetos. Intentan aplicar

ingeniería para solucionar problemas técnicos de un sistema de información, proponen la
creación de modelos, flujos y estructuras mediante un top-down. La metodología orientada
a procesos está fundamentada en el modelo entrada-proceso-salida., aplica un proceso
interactivo para lograr un refinamiento progresivo. La metodología orientada a objetos se
divide en jerárquica y no jerárquica, la jerárquica está orientada a las entradas y salidas,
las no jerárquicas definen un sistema a partir de la información que este maneja.
Metodologías para sistemas de tiempo real

Las metodologías en tiempo real procesan información orientada al control más que a los
datos.

Se caracterizan por:

 Concurrencia.

 Priorización de procesos.

 Comunicación y sincronización entre tareas.

 Acceso simultáneo a datos comunes.

 Permiten el manejo de interrupciones.

 Gestión de procesos concurrentes

 Respuesta oportuna ante eventos externos.

 Datos continuos o discretos.

Metodologías Orientadas a Objetos

La orientación a objetos unifica procesos y datos encapsulándolos en el concepto de

objetos. La esencia del desarrollo orientado a objetos es la identificación y organización de
conceptos del dominio de la aplicación y no tanto de su representación final en un lenguaje
de programación.

Tiene dos enfoques distintos:

 Revolucionario, puro u ortodoxo: Rompen con las metodologías tradicionales. La

Orientación a objetos se entiende como un cambio profundo de las metodologías
estructuradas que se ven como obsoletas. Ejemplos: metodologías OOD de Booch,
CRC/RDD de Wirfs-Brock.
 Sintetista o evolutivo:El análisis y diseño estructurado se considera como la base
para el desarrollo Orientado a objetos.

Ventajas de las metodologías orientadas a objetos:

Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para
maximizar la reutilización, las clases se construyen de manera que se puedan adaptar a los
otros sistemas. Un objetivo fundamental de las técnicas orientadas a objetos es lograr la
reutilización masiva al construir el software.

Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la
misma manera que los microprocesadores y otros chips se hacen estables.

El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo

nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fáciles de
utilizar.

Se construyen clases cada vez más complejas. Se construyen clases a partir de otras clases,
las cuales a su vez se integran mediante clases. Esto permite construir componentes de
software complejos, que a su vez se convierten en bloques de construcción de software más
complejo.

Calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir de
componentes probados, que han sido verificados y pulidos varias veces.

Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes.

Muchos de los componentes están construidos de modo que se pueden adaptar para un
diseño particular.

Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con métodos
específicos. Esto tiene particular importancia en los sistemas cliente-servidor y los sistemas
distribuidos, en los que usuarios desconocidos podrían intentar el acceso al sistema.
Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un
método de clase a la vez. Cada clase efectúa sus funciones independientemente de las
demás.

Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una interfaz de usuario
gráfica de modo que el usuario apunte a iconos o elementos de un menú desplegado,
relacionados con los objetos. En determinadas ocasiones, el usuario puede ver un objeto en
la pantalla. Ver y apuntar es más fácil que recordar y escribir.

Independencia del diseño. Las clases están diseñadas para ser independientes del ambiente
de plataformas, hardware y software. Utilizan solicitudes y respuestas con formato
estándar. Esto les permite ser utilizadas en múltiples sistemas operativos, controladores de
bases de datos, controladores de red, interfaces de usuario gráficas, etc. El creador del
software no tiene que preocuparse por el ambiente o esperar a que éste se especifique.

Interacción. El software de varios proveedores puede funcionar como conjunto. Un

proveedor utiliza clases de otros. Existe una forma estándar de localizar clases e interactuar
con ellas. El software desarrollado de manera independiente en lugares ajenos debe poder
funcionar en forma conjunta y aparecer como una sola unidad ante el usuario.

Computación Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software

cliente deben enviar solicitudes a las clases en el software servidor y recibir respuestas. Una
clase servidor puede ser utilizada por clientes diferentes. Estos clientes sólo pueden tener
acceso a los datos del servidor a través de los métodos de la clase. Por lo tanto los datos
están protegidos contra su corrupción.

Computación de distribución masiva. Las redes a nivel mundial utilizarán directorios de

software de objetos accesibles. El diseño orientado a objetos es la clave para la
computación de distribución masiva. Las clases de una máquina interactúan con las de
algún otro lugar sin saber donde residen tales clases. Ellas reciben y envían mensajes
orientados a objetos en formato estándar.

Mayor nivel de automatización de las bases de datos. Las estructuras de datos (los objetos)
en las bases de datos orientadas a objetos están ligadas a métodos que llevan a cabo
acciones automáticas. Una base de datos OO tiene integrada una inteligencia, en forma de
métodos, en tanto que una base de datos relacional básica carece de ello.

Las metodologías orientadas a objetos han evolucionado para ayudar a los

desarrolladores a explotar el poder de los lenguajes de programación basados en objetos y
orientados a objetos, utilizando las clases y objetos como bloques de construcción básicos.
Una orientación a objetos nos ayuda a hacer frente a la inherente complejidad de muchos
tipos de sistemas.

¿Que metodología es conveniente usar?

Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se desarrolle
resulta una idea interesante. Estas metodologías pueden involucrar prácticas tanto de
metodologías ágiles como de metodologías tradicionales. De esta manera podríamos tener
una metodología para cada proyecto, la problemática sería definir cada una de las prácticas,
y en el momento preciso definir parámetros para saber cual usar.Es importante tener en
cuenta que el uso de un método ágil no es para todos. Sin embargo, una de las principales
ventajas de los métodos ágiles es su peso inicialmente ligero y por eso las personas que no
estén acostumbradas a seguir procesos encuentran estas metodologías bastante agradables.
Por otro lado, las metodologías tradicionales o convencionales permiten crear software de
manera mas segura ya que estas entan mas establecidas según por sus pasos.

Modelos de procesos utilizados en el desarrollo de software

Modelado de Negocios

Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto
de procesos de negocio. Cada uno de ellos se caracteriza por una colección de datos que
son producidos y manipulados mediante un conjunto de tareas, en las que ciertos agentes
(por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajo
determinado. Además, estos procesos se hallan sujetos a un conjunto de reglas de negocio,
que determinan las políticas y la estructura de la información de la empresa. Por tanto, la
finalidad del modelado del negocio es describir cada proceso del negocio, especificando sus
datos, actividades (o tareas), roles (o agentes) y reglas de negocio.

Con esta disciplina se pretende llegar a un mejor entendimiento de la organización.

Los objetivos específicos del modelado de negocio son:

1. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común

de la organización objetivo.

2. Derivar los requerimientos del sistema necesarios para apoyar a la organización objetivo
en su mejora.

3. Entender el problema actual en la organización objetivo e identificar potenciales mejoras.

4. Entender la estructura y la dinámica de la organización para la cual el sistema va a ser

desarrollado (organización objetivo).

Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visión de
la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades
de la organización por medio de un Modelo de Casos de Uso del Negocio. Los artefactos
del modelo de negocio sirven como entrada y referencia para la definición de los
requerimientos del sistema.

La importancia de esta disciplina radica en que sin el panorama completo del alcance del
negocio y sin el entendimiento de sus procesos no podrán identificarse las necesidades
inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas
informáticos, que son el producto final del desarrollo.

Orientación del modelado de negocio.

Dominios principales en los que se emplea:

Dominios orientados al negocio

Gerencia

Teoría de Organizaciones

E-business, E-commerce

Dominios orientados a la tecnología

Sistemas de Información

Ingeniería de Software

Informática Industrial

Los dominios definen dos puntos de vista diferentes del Modelado de:

 Orientado al valor/cliente

Busca explicar cómo la empresa crea valor para el cliente, que valor le proporciona a sus
clientes los productos o servicios de una empresa, en este caso entenderemos el modelo de
negocio como “…una herramienta conceptual que tiene un conjunto de objetos, conceptos
y relaciones con el objetivo de expresar la lógica del negocio de una empresa” Osterwalde ,
Pigneur (2005).

 Orientado a la actividad/rol

Hace énfasis en el modelado de los procesos y actores de la empresa , en las actividades

que realiza la empresa y quienes participan en ellas, el modelo de negocio se define en este
caso como “… una abstracción de cómo una empresa funciona… proporciona una vista
simplificada de la estructura del negocio que actúa como la base para la comunicación,
mejoras o innovación y define los requisitos de los sistemas de información que intervienen
en la empresa ” Erikson y Peker (2000).
Un Modelado del Negocio es una descripción de los elementos que constituyen una
organización, o una parte de ella, así como de las relaciones entre estos elementos. Un
Modelo del Negocio es una conceptualización de una empresa u organización, es la
caracterización de los aspectos más significativos de la empresa o de una parte de ella,
para ello se debe tener claro cuál es el fin que se busca con ese modelo, para así tener
claro los elementos del negocio que se deseen representar.

Modelado de Negocios e Ingeniería de Requisitos

El Modelado de Negocios y la Ingeniería de Requisitos son los dos procesos técnicos

iniciales del desarrollo ingenieril de aplicaciones de software. El Modelado de Negocios se
realiza en el espacio del problema; se encarga de estudiar el dominio de la aplicación con la
finalidad de formular y analizar el problema que da origen a la aplicación. La Ingeniería de
Requisitos, por su parte, ocurre en el espacio de la solución; se encarga, por lo tanto, de
caracterizar la aplicación en base a las necesidades y los requisitos que los usuarios de la
aplicación tienen.

El proceso de ingeniería de requerimientos se utiliza para definir todas las actividades

involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos
para un producto de software determinado, donde es muy importante tomar en cuenta la
viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando
posteriormente por un subproceso de obtención y análisis de requerimientos, su
especificación formal, para finalizar con el subproceso de validación donde se verifica que
los requerimientos realmente definen el sistema que quiere el cliente.

En el desarrollo de software, el Modelado de Negocios aporta información esencial para

la Ingeniería de Requisitos, ya que en el modelado de negocio se ve lo que es el problema y
en la ingeniería de requisitos se define la solución al problema.

Cadena de Valor
La cadena de valor es esencialmente una forma de análisis de la actividad empresarial
mediante la cual descomponemos una empresa en sus partes constitutivas, buscando
identificar fuentes de ventaja competitiva en aquellas actividades generadoras de valor. La
cadena de valor representa todas las actividades que se llevan a cabo en una empresa, en la
cual se realiza una separación entre las actividades de mayor interés (actividades primarias)
y las actividades que le sirven de apoyo con la finalidad de prestar mayor atención y
centrarse en aquellas actividades que generan mayores ventajas al momento de competir
con otras empresas. 20

Como se menciono anteriormente la cadena de valor se divide en actividades primarias y

secundarias

 Actividades primarias: Conforman la creación física del producto, las actividades

relacionadas con su venta y la asistencia post-venta.

Se dividen en:

•Logística interna

•Operaciones

•Logística externa

•Ventas y marketing: actividades con las cuales se da a conocer el producto.

•Servicios post-venta (mantenimiento): actividades destinadas a mantener o realizar el valor

del producto.

 Actividades secundarias o de apoyo, están conformadas por:

• Infraestructura de la organización

• Dirección de recursos humanos: búsqueda, contratación y motivación del personal.

• Desarrollo de tecnología (investigación y desarrollo)

• Abastecimiento o compras
La cadena de valor es una herramienta de gran importancia ya que permite determinar
cuales son aquellas actividades de valor de la empresa. Es muy útil que las empresas
conozcan no solo su cadena de valor si no también la de sus competidores, ya que esta
proporciona un mejor análisis interno de la organización, así como también identificar las
ventajas competitivas y comprender de una mejor manera el comportamiento de los costos
y las diversas fuentes de diferenciación con la competencia.

Conclusiones

 Una metodología se basa en una combinación de los modelos de proceso genéricos

para obtener como beneficio un software que soluciones un problema

 La trascendencia de las metodologías se ha hecho notoria, pasando de solo

programar, establecer funciones en etapas o módulos, objetos, y por último agilizar el
desarrollo del software y minimizar los costos.

 En el desarrollo convencional todo el programa está en un solo bloque, con

ejecución secuencial de instrucciones

 En el desarrollo estructurado los programas están divididos en distintos bloques,

estos bloques tienen funciones que se van confeccionado en forma de arriba-abajo,
empezando desde las generales hasta las particulares, hasta llegar a detallar cada uno de los
procedimientos y su interacción.

 El desarrollo orientado a objetos comprende dividir un programa en clases, donde

estas clases estarán estructuradas por propiedades, atributos, variables, pretendiendo
simular y describir de manera conceptual a un objeto.

 Los métodos ágiles fueron pensados especialmente para equipos de desarrollo

pequeños, con plazos reducidos, requisitos volátiles y nuevas tecnologías.
 El modelado de negocio describe como desarrollar una visión de la nueva
organización, basado en esta visión se definen procesos, roles y responsabilidades de la
organización por medio de un Modelo de Casos de Uso del Negocio

 Los modelos de procesos permiten al analista de sistemas desarrollar un plan de

requisitos del software, permiten establecer un trabajo en forma ordenada, además que
existen muchos modelos que se adaptan a las exigencias del proyecto, solo debemos saber
cual nos conviene.

Referencias

1. Alonso, F. y Martínez, L. (2005). Introducción a la ingeniería del software: modelos de

desarrollo de programas (primera edición). España: Delta Publicaciones. Pág. 75-76

2. Sommerville, I. (2005). Ingeniería del software (Séptima Edición). España: Pearson

Educación.

3. Hernán, M. (2004). Diseño de una Metodología Ágil de Desarrollo de Software. Tesis de

Grado de Ingeniería en Informática. Universidad de Buenos Aires. Pág. 11-12

4. Sommerville, I. (2006). Ingeniería del software (Séptima Edición). Madrid. Pág. 62

5. Espinoza, A. Metodologías de desarrollo de software [documento en línea].Disponible

en: « www.slideshare.net/juliopari/4-clase-metodologia-de-desarrolo-de-software »
[consulta: 11 de junio de 2012]

6. Carballar, D. Ingeniería de software [documento en línea].

« www.eduinnova.es/dic09/Ingenieria_Software.pdf » [consulta: 10 de junio de 2012]

7.Disponible en la web:
« www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#paradigmaOO » [consulta:
10 de junio de 2012]

8. Kenneth, E. y Kendall, J. (2005). Analisis Y Diseño de Sistemas(Sexta edición). México.

9. Solís, M. (2003). Una explicación de la programación extrema (XP). Madrid. Pág. 103
10. Ordonez (2011). Metodo de Desarrollo de sistemas dinamicos[documento en línea].
Disponible en:« www.slideshare.net/oscarfico/metodos-dinamicos » [consulta: 8 de junio
de 2012]

11. Citón, M.(2006). Método ágil scrum aplicado al desarrollo de un software de

trazabilidad. Argentina.

12. Amaro , S. y Valverde, J. (2007). Metodologías Ágiles. Perú:Trujillo.

13. Mendez, E. (2006). Modelo de Evaluacion de Metodologia para el Desarrollo de

Software. Trabajo de Grado, Universidad Católica Andrés Bello,Caracas,Vzla.

14. Canós J. y Letelier P. (2003, noviembre). Metodologías ágiles en el desarrollo de

software [resumen]. Taller realizado en el marco de las VIII jornadas de Ingeniería del
software y bases de datos en la Universidad politécnica de Valencia, España-Alicante.

15. Laboratorio Nacional de Calidad del Software de INTECO. (2009, Marzo) Ingeniería
del software: metodologías y ciclos de vida. España.

16. Oscar Álvarez Imaz. (2008, Abril). "Introducción a RUP" Versión 0.1

17. Alonso, F. y Martínez, L. (2005). Introducción a la ingeniería del software: modelos de

desarrollo de programas (primera edición). España: Delta Publicaciones. Pág. 112-113

18. Disponible en la web: « www.laprole431.blogspot.com/2010/12/que-es-un-modelo-de-

desarrollo.html » [consulta: 6 de julio de 2012]

19. Disponible en la web: « www.ingenieraupoliana.blogspot.com/2010/10/modelo-de-

desarrollo-concurrente.html » [consulta: 6 de julio de 2012]

20. David, F. (2008). Conceptos de Administration Estratégica (Decimoprimera Edición).

Editorial Pearson Educación, México.

21. Disponible en la web:

« www.aprendecomputofacil.blogspot.com/2009_07_01_archive.html » [consulta: 10 de
julio de 2012]