Modelos de Procesos del

Software

ASIGNATURA: Análisis y Diseño de Sistemas de Información

DOCENTE: M.Sc. Aldo Ramiro Valdez Alvarado
ESTUDIANTES: Calle Averanga Maribel Maritza Commented [1]: Pongan sus nombres

Guatia Alcazar Ruddy

Monrroy Lema Daynor Freddy
Joel Nicolas Luna Valdivia
Torrez Rojas Luis Gabriel
Condori Apaza Mariana Noemi
Carrillo Choquetarqui Alejandro
Delgado Vera Jose Luis

MODELOS DE PROCESOS DEL SOFTWARE

1. DEFINICIÓN
El modelo de proceso de desarrollo de software se puede decir que es la pieza
más importante de lo que es la ingeniería del software.
Según Sommerville, Un modelo de proceso de software es una representación
simplificada de este proceso, y según Roger S. Presman, un proceso es como
la colección de actividades de trabajo, acciones y tareas que se realizan
cuando va a crearse algún producto.

Y este modelo describe una sucesión de fases y un encadenamiento entre ellas

así como un bucle de resoluciones de problemas y estos se encuentran en
distintas etapas. Según las fases y el modo en que se produzca este
encadenamiento, tenemos diferentes modelos de proceso. También un
modelo es más adecuado que otro para desarrollar un proyecto dependiendo
de un conjunto de características que tenga.
En el libro de Roger S. Pressman, nos dice que cada una de las actividades,
acciones y tareas se encuentra dentro de una estructura o modelo que define
su relación tanto con el proceso como entre sí.

En la siguiente imagen se muestra lo que es la estructura de un proceso del

software, cada actividad estructural está formada por un conjunto de acciones
de ingeniería de software y cada una de éstas se encuentra definida por un
conjunto de tareas que identifica las tareas del trabajo que deben realizarse,
los productos del trabajo que se producirán, los puntos de aseguramiento de
la calidad que se requieren y los puntos de referencia que se utilizarán para
evaluar el avance.
 Una estructura general para la ingeniería de software define cinco actividades
estructurales: comunicación, planeación, modelado, construcción y
despliegue. A lo largo de todo el proceso se aplica un conjunto de actividades
como seguimiento y control del proyecto, administración de riesgos,
aseguramiento de la calidad, administración de la configuración, revisiones
técnicas, entre otras.

Deficiencias comunes en el desarrollo de software son:

● Escasa o tardía validación con el cliente.
● inadecuada gestión de los requisitos.
● No existe medición de proceso ni registro de datos históricos.
● Excesiva e irracional presión en los plazos.
● Escaso o deficiente control en el progreso del proceso del desarrollo.
● No se hace gestión de riesgos formalmente
● No se realiza un proceso formal de pruebas.

2. MODELO SECUENCIAL

1.CASCADA
También llamado "Ciclo de vida básico" o "Modelo de cascada" tiene su origen
en el "Modelo de cascada" ingeniado por Winston Royce, aunque omite los
muchos bucles de este último. El Modelo Lineal Secuencial sugiere un enfoque
sistemático o más bien secuencial del desarrollo de software que comienza en
un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y
mantenimiento. El Modelo Lineal Secuencial acompaña las siguientes
actividades:

GRÁFICO DEL MODELO LINEAL SECUENCIA "CASCADA"

Análisis de los requerimientos del software:
Es la fase en la cual se reúnen todos los requisitos que debe cumplir el
software. En esta etapa es fundamental la presencia del cliente que documenta
y repasa dichos requisitos.
Diseño:

Es una etapa dirigida hacia la estructura de datos, la arquitectura del software,

las representaciones de la interfaz y el detalle procedimental (algoritmo). En
forma general se hace un esbozo de lo solicitado y se documenta haciéndose
parte del software.
Generación del código:
Es la etapa en la cual se traduce el diseño para que sea comprensible por la
máquina. Esta etapa va a depender estrechamente de lo detallado del diseño
Pruebas:
Esta etapa se centra en los procesos lógicos internos del software, asegurando
que todas las sentencias se han comprobado, y en la detección de errores.
Mantenimiento:
Debido a que el programa puede tener errores, puede no ser del completo
agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios
en su entorno. Esto quiere decir que no se rehace el programa, sino que sobre
la base de uno ya existente se realizan algunos cambios.
El Modelo Lineal Secuencial es el paradigma de desarrollo de software más
antiguo que existe, sin embargo esto no ha impedido que se haya creado una
desconfianza alrededor de él basada en los siguientes errores reales:
● Los proyectos raramente siguen el paradigma secuencial que propone
el proyecto.
 ● A menudo es difícil que el cliente exponga exactamente todos los
requisitos.
● El cliente debe tener paciencia.
Los responsables del desarrollo de software siempre se retrasan
innecesariamente. Todo lo anteriormente expuesto es cierto pero este
paradigma tiene un lugar bien definido e importante en el trabajo de la
Ingeniería de Software aparte de proporcionar una plantilla en la que se
encuentran métodos para análisis, diseño, codificación, pruebas y
mantenimiento. Con todo y sus errores, sigue siendo el paradigma más
utilizado en el desarrollo del software, siendo mucho mejor que un enfoque al
azar.

Características del modelo

● Primer modelo empleado (Royce, 1970), también denominado ciclo de
vida clásico y modelo lineal secuencial.
● Consiste en la ejecución secuencial de una serie de fases que se
suceden, lo que da nombre al modelo.
● Cada fase genera documentación para la siguiente. Esta
documentación debe ser aprobada.
● Una fase no comienza hasta que la anterior ha terminado.
● Requiere disponer de unos requisitos completos y precisos al principio
del desarrollo.
● Se disponga de unos requisitos completos y consistentes al principio del
desarrollo.
● Sea un proyecto pequeño, en el que el período de congelación de los
requisitos es corto, o un proyecto con unos requisitos bastante estables.
Ventajas:
● Se debe tener en cuenta que fue el primer modelo empleado, y por lo
tanto es mejor que ninguno.
● Facilita la gestión del desarrollo.
Desventajas:
● En general, establecer todos los requisitos al principio del proceso de
desarrollo es un mito inalcanzable, Los usuarios no pueden imaginarse
lo que quieren hasta que no ven un sistema funcionando.
● Los requisitos no se pueden congelar mientras dura el desarrollo. El
mercado cambia, todo cambia.
● El usuario debe esperar mucho tiempo hasta ver los resultados
● Los errores de análisis y diseño son costosos de eliminar, y se propagan
a las fases siguientes con un efecto conocido como bola de nieve.
● Se genera mucho mantenimiento inicial debido al período de
congelación de requisitos y éste recae, en su mayor parte
2. Modelo en V
El modelo en V es una variación del modelo en cascada que muestra
cómo se relacionan las actividades de prueba con el análisis y el diseño.
Como se muestra en la Figura 3, la codificación forma el vértice de la V,
con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento
a la derecha.
La unión mediante líneas discontinuas entre las fases de la parte
izquierda y las pruebas de la derecha representa una doble información.
Por un lado sirve para indicar en qué fase de desarrollo se deben definir
las pruebas correspondientes. Por otro sirve para saber a qué fase de
desarrollo hay que volver si se encuentran fallos en las pruebas
correspondientes.
Por lo tanto el modelo en V hace más explícita parte de las iteraciones
y repeticiones de trabajo que están ocultas en el modelo en cascada.
Mientras el foco del modelo en cascada se sitúa en los documentos y
productos desarrollados, el modelo en V se centra en las actividades y
la corrección.
Ventajas y desventajas del Modelo en “V”

Ventajas:
● La relación entre las etapas de desarrollo y los distintos tipos de
pruebas facilitan la localización de fallos.
● Es un modelo sencillo y de fácil aprendizaje
● Hace explícito parte de la iteración y trabajo que hay que revisar
● Especifica bien los roles de los distintos tipos de pruebas a
realizar
● Involucra al usuario en las pruebas
 Desventajas:
● Es difícil que el cliente exponga explícitamente todos los
requisitos
● El cliente debe tener paciencia pues obtendrá el producto al final
del ciclo de vida
● Las pruebas pueden ser caras y, a veces, no lo suficientemente
efectivas
● El producto final obtenido puede que no refleje todos los
requisitos del usuario
3. Modelo Secuencial por Etapas
Este modelo es parecido al Modelo de prototipos ya que se presenta al
cliente el software en diferentes estados continuos de desarrollo, existe
diferencia en que las especificaciones no son conocidas en detalle al
empiezo del proyecto entonces se van desarrollando paralelamente
con las diferentes versiones del código existente. Es un modelo en que
el software se presenta al cliente en etapas mejoradas sucesivamente.

Diseño Global Es un diseño general del problema que está planteado, es

también la elaboración en la búsqueda de una solución en cualquier campo,
tomando en cuenta los parámetros y análisis de requerimientos que se
hayan conseguido para el desarrollo de un resultado que debe estar
relacionado con el problema. Permite ilustrar cómo el sistema va a satisfacer
los requerimientos. Esta etapa típicamente tiene diferentes niveles de
detalle. Los niveles más altos de detalle generalmente describen los
componentes o módulos que conformarán el software que se realizará.
Los niveles más bajos,describen con bastante detalle, cada módulo que
almacenará el sistema. Diseño detallado Se trata de un diseño piloto, se lo
 realiza para presentar una opción al cliente con capacidad de edición. Sus
puntos son:
● Codificación. Dependiendo el tamaño del proyecto, la programación puede
ser repartida entre distintos programadores o grupos de programadores.
Cada uno se enfocara en la construcción y prueba de una parte del software,
con frecuencia un subsistema.
● Depuración. Es un proceso para identificar y corregir errores.
● Prueba. Esta situación nos permite verificar las cualidades y la calidad de la
solución planteada para contar con varias opciones o depender de una sola,
para demostrar las circunstancias de nuestro método.
● Entrega Ya contando con todos los aspectos anteriores debidamente
organizados y teniendo en cuenta la operación del proceso y el resultado de
cada uno de sus pasos realizamos conclusiones y solucionamos los estados
sucesivos de desarrollo para la solución del problema que se estableció en el
comienzo del modelo.
Ventajas
● Permite dar una funcionalidad útil en manos del cliente sin tener la
aplicación finalizada.
● Proporciona signos tangibles de progreso.
Desventajas
● No funciona sin una planificación técnica de gestión.
● Personal de gestión con experiencia.
● Mucha documentación.

3. Modelos Evolutivos

El modelo de desarrollo evolutivo, es un modelo iterativo que se basa en construir un

gran número de versiones sucesivas cada vez más completas y complejas para
desarrollar un software cada vez más completo.

Este modelo consta de una versión inicial que luego de presentarse se va refinando
de acuerdo a los comentarios o nuevos requerimientos que así lo requiera por parte
del cliente o bien el usuario final.

Al principio el modelo inicial se crea a partir de las primeras ideas del cliente que no
son expuestas claramente y al exponer el producto se busca que se mejore hasta que
se logre satisfacer al cliente o usuario final.

Dentro de las desventajas de usar el sistema evolutivo se encuentra el hecho del

manejo de datos que pueden llegar a perderse por el cual se debe tener extremo
cuidado con su manejo.

1. Modelo en Espiral
Es un ciclo de vida de software definido por Barry Boehm, tiene forma de
espiral que representa una repetición de procesos, en el que cada bucle
representa un conjunto de actividade, a medida que se van entregando
prototipos son probados por los clientes o usuarios finales, es un generador de
modelos de proceso guiado por el riesgo que se emplea para conducir
sistemas intensivos de ingeniería de software concurrente.

El modelo en espiral contempla cuatro etapas que son las siguientes:

● Determinar Objetivos.
● Análisis de Riesgo.
● Ingeniería.
● Desarrollar y probar.

Determinar Objetivos.- Identificación de riesgos del proyectos y estrategias

alternativas para evitarlos, fijar restricciones.

Análisis de riesgo. - Llevar a cabo el estudio de las causas de las posibles

amenazas o probables eventos no deseados, evitando consecuencias que
estas puedan producir.

Ingeniería.- Desarrollo del producto del “siguiente nivel”.

Desarrollar y probar. - Tareas de la actividad propia y de prueba, análisis de

alternativas e identificación de resolucion de riesgos. Dependiendo del
resultado de la evaluación de los riesgos se elige un modelo para el desarrollo,
el que puede ser cualquiera de los otros existes como formal, evolutivo, o
cascada.

Características.

● Está conformado en un enfoque cíclico para el crecimiento del grado

de definición e implementación de un sistema, mientras que disminuye
su grado de riesgo.
● Utiliza un conjunto de puntos de fijación para asegurar el compromiso
que se asume el usuario con las soluciones de sistema que sean
factibles y totalmente satisfactorias
 Ventajas:

El análisis del riesgo se hace de forma explícita y clara.

● Reduce riesgos de proyectos.

● Incorpora objetivos de calidad.
● Integra el desarrollo con el mantenimiento.

Desventajas:

● Genera mucho tiempo en el desarrollo del sistema.

● modelo costoso
● requiere experiencia en la identificación de riesgos.

2. Modelo Concurrente.

Una descripción más exacta sobre modelo concurrente se puede encontrar de

parte de Davis Sitaram que dice:

“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 tienen idea
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áneo. Por ejemplo, el personal está escribiendo requisitos,
diseñando, modificando, haciendo pruebas y probando la integración… La
mayoría de los modelos de proceso desarrollo de software son dirigidos por el
tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de
desarrollo. (Un modelo de proceso concurrente) está dirigido por las
necesidades del usuario, las decisiones de la gestión y los resultados de las
revisiones”.

Entonces de acuerdo con la descripción de Davis se definiría como una serie

de acontecimientos que disparan transiciones de estado a estado para cada
una de las actividades del software que proporcionará una visión actual del
proyecto en curso.

El modelo concurrente es de tipo red debido a que todas personas trabajan al

mismo tiempo.

La concurrencia se logra de dos formas

1. Las actividades de sistemas y de los componentes ocurren al mismo

tiempo y pueden modelarse con el enfoque orientado a objetos.
2. Una aplicación cliente/servidor típico se implementa con muchos
componentes, cada uno de los cuales se puede diseñar y realizar
concurrentemente.
 Funcionalidad del proceso

Dentro de la red todo funciona simultáneamente esto significa que las

actividades y tareas están pasando al mismo tiempo.

Si ocurre un evento generado dentro de una actividad o algún otro caso dentro
de la red genera las transiciones entre los estados de una actividad.

Características

● Este modelo se utiliza a menudo para el desarrollo de aplicaciones

cliente/servidor.
● Al aplicar cliente/servidor el modelo concurrente define actividades en
dos dimensiones: una división de sistemas y una división de
componentes.
● El modelo concurrente tiene la capacidad de describir las múltiples
actividades que están ocurriendo al mismo tiempo.
● El modelo concurrente está dirigido por las necesidades del usuario,
las decisiones de la gestión y los resultados de las revisiones.
● Define una serie de acontecimientos que son las transiciones de estado
a estado de cada actividad.

Ventajas

● El modelo concurrente es excelente para proyectos en los que se

conforman grupos de trabajo independientes.
● Da una información exacta del estado actual del proyecto porque todo
trabaja simultáneamente.

Desventajas

● Si no existen grupos de trabajo independientes el modelo no es factible

para realizar el proyecto.
● Si no se dan las condiciones señaladas tampoco es aplicable.

3. Modelo de desarrollo rápido de aplicaciones

Es un modelo de proceso del desarrollo del software lineal y secuencial que

enfatiza un ciclo de desarrollo extremadamente corto, el desarrollo rápido de
aplicaciones es una adaptación a “alta velocidad” en que se logra el desarrollo
rápido utilizando un enfoque de construcción basado en componentes
El modelo de desarrollo rápido de aplicaciones está basado en cinco fases:

● Modelado de gestión.
● Modelado de datos.
● Modelado de proceso.
● Generación de aplicaciones.
● Pruebas de entrega..

Características.

● Modelo lineal secuencial orientado a un ciclo rápido de desarrollo.

● Basado en componentes para poder entregar un modelos totalmente
operativo en un corto periodo de tiempo
● Es fundamental para poder modular la aplicación para cada equipo
pueda trabajar en diferentes modelos

Ventajas:

● Es muy rápido.
● Permite trabajar en el a varias personas a la vez.

Desventajas:

● El enfoque del modelo tiene inconvenientes para proyectos grandes

que necesitan suficientes recursos humanos para crear el número
correcto de equipos.
● Si los desarrolladores y clientes no se comprende con las actividades
necesarias para completar el sistema, los proyectos fallan.
 ● El desarrollo rápido de aplicaciones sería inapropiado cuando los
riesgos técnicos son altos.

4. MODELO AGIL

El desarrollo ágil de software envuelve un enfoque para la toma de decisiones en los

proyectos de software, que se refiere a métodos de ingeniería del software basados
en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan
con el tiempo según la necesidad del proyecto. Así el trabajo es realizado mediante la
colaboración de equipos auto-organizados y multidisciplinarios, inmersos en un
proceso compartido de toma de decisiones a corto plazo. Cada iteración del ciclo de
vida incluye: planificación, análisis de requisitos,diseño, codificación, pruebas y
documentación. Teniendo gran importancia el concepto de "Finalizado" (Done), ya que
el objetivo de cada iteración no es agregar toda la funcionalidad para justificar el
lanzamiento del producto al mercado, sino incrementar el valor por medio de "software
que funciona" (sin errores). Los métodos ágiles enfatizan las comunicaciones cara a
cara en vez de la documentación. La oficina debe incluir revisores, escritores de
documentación y ayuda, diseñadores de iteración y directores de proyecto. Los
métodos ágiles también enfatizan que el software funcional es la primera medida del
progreso. Combinado con la preferencia por las comunicaciones cara a cara,
generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por
la falta de documentación técnica.

Historia

La definición moderna de desarrollo ágil de software evolucionó a mediados de la

década de 1990 como parte de una reacción contra los métodos de "peso pesado",
muy estructurados y estrictos, extraídos del modelo de desarrollo en cascada. El
proceso originado del uso del modelo en cascada era visto como burocrático, lento,
degradante e inconsistente con las formas de desarrollo de software que realmente
realizaban un trabajo eficiente.

¿QUÉ ES METODOLOGÍA ÁGIL?

A menudo me hacen la pregunta: ¿Qué es la metodología agile? En pocas palabras,

agile en informática, se usa para describir un método alternativo de gestión de
proyectos.

Agile es un proceso que ayuda a los equipos a proporcionar respuestas rápidas a los
cambios que se reciben sobre su proyecto. ¿Esto qué significa? Pues que crea
oportunidades para evaluar la dirección de un proyecto durante el ciclo de desarrollo
del mismo. Los equipos evalúan el proyecto en reuniones regulares llamadas sprints
o iteraciones.

Este 2019 he querido poner en un cuadro las diferencias más significativas que existen
entre la metodología agile y las metodologías tradicionales.
METODOLOGÍA ÁGILE

– Flexibilidad ante los cambios del proyecto de forma moderada a rápida

– Los clientes hacen parte del equipo de desarrollo

– Grupos pequeños (promedio 10 participantes in situ) en el mismo lugar.

– Menor dependencia de la arquitectura de software

– Continuo Feedback acortando el tiempo de entrega

– Diversidad de roles

– Basadas en heurísticas a partir de prácticas de producción de código

– Procesos menos controlados, pocas políticas y normas

– Capacidad de respuesta ante los cambios – Rigidez ante los cambios, de manera
lentos o moderada

METODOLOGÍAS TRADICIONALES

– Los clientes interactúan con el equipo de desarrollo mediante reuniones

– Grupos de gran tamaño y varias veces distribuidos en diferentes sitios

– Dependencia de la arquitectura de software mediante modelos

– Poco Feedback lo que extiende el tiempo de entrega

– Mínimos roles

– Basadas en normas de estándares de desarrollo

– Procesos muy controlados por políticas y normas

– Seguimiento estricto del plan inicial de desarrollo

Los 11 principios de los métodos ágil son:

1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega

temprana y continua del software de valor.
2. Son bienvenidos los requisitos cambiantes, aun llegando tarde al desarrollo.
Los procesos ágiles se doblegan al cambio como ventaja competitiva para el
cliente.
3. Entregar con frecuencia software que funcione, en periodos de un par de
semanas hasta un par de meses.
 4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma
cotidiana a través del proyecto.
5. Construcción de proyectos en torno a individuos motivados.
6. La forma más eficiente y efectiva de comunicar información de ida y vuelta
dentro de un equipo de desarrollo es mediante la conversación cara a cara.
7. El software/producto/servicio que funcione es la principal medida de progreso.
8. Los procesos ágiles promueven el desarrollo sostenido. Los desarrolladores,
patrocinadores, y usuarios han de mantener un ritmo constante de forma
indefinida.
9. La atención continua a la excelencia técnica ensalza la agilidad.
10. La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es
esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se
auto organizan.

Métodos ágiles
Algunos métodos ágiles de desarrollo de software:

· Adaptive Software Development (ASD)

· Agile Unified Process

· Crystal Clear

· Feature Driven Development (FDD)

· Lean Software Development (LSD) : Lean startup

· Kanban (desarrollo)

· Open Unified Process (OpenUP)

· Programación Extrema (XP)

· Método de desarrollo de sistemas dinámicos (DSDM)

· Scrum

· Scrumban

· G300

· 6D-BUm
PMI Agile

1. Scrum

Scrum es un marco de trabajo para desarrollo ágil de software.

Es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para
trabajar colaborativamente, en equipo y obtener el mejor resultado posible de proyectos,
caracterizado por:

1. Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y

ejecución completa del producto.
2. Basar la calidad del resultado más en el conocimiento tácito de las personas en
equipos auto organizados, que en la calidad de los procesos empleados.
3. Solapar las diferentes fases del desarrollo, en lugar de realizar una tras otra en un
ciclo secuencial o en cascada.

HISTORIA

Este modelo fue identificado y definido por Ikujiro Nonaka y Takeuchi a principios de los 80,
al analizar cómo desarrollaban los nuevos productos las principales empresas de
manufactura tecnológica: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M y Hewlett-
Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986).

En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el

avance en formación de melé (scrum en inglés) de los jugadores de Rugby, a raíz de lo cual
quedó acuñado el término “scrum” para referirse a ella.

Aunque esta forma de trabajo surgió en empresas de productos tecnológicos, es apropiada

para cualquier tipo de proyecto con requisitos inestables y para los que requieren rapidez y
flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software.

En 1995, Ken Schwaber presentó “Scrum Development Process” en OOPSLA 95 (Object-

Oriented Programming Systems & Applications conference)(SCRUM Development Process),
un marco de reglas para desarrollo de software, basado en los principios de Scrum, y que él
había empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel
Corporation (compañía que en los macrojuegos de compras y fusiones, se integraría en
VMARK, y luego en Informix y finalmente en Ascential Software Corporation).

La metodología se basa en:

● El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos

y fijos.
● Se da prioridad a lo que tiene más valor para el cliente.
● El equipo se sincroniza diariamente y se realizan las adaptaciones necesarias.
● Tras cada iteración (un mes o menos entre cada una) se muestra al cliente el resultado
real obtenido, para que este tome las decisiones necesarias en relación a lo
observado.
● Se le da la autoridad necesaria al equipo para poder cumplir los requisitos.
● Fijar tiempos máximos para lograr objetivos.
● Equipos pequeños (de 3 a 9 personas cada uno).

Principales características de Scrum

● Gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y

adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad,
alineamiento entre cliente y equipo, por último, equipo motivado.
● Se hace uso de equipos auto-dirigidos y auto-organizados.
● Se realiza a diario una reunión de Scrum, que es una reunión de avance diaria que no
dura más de 15 minutos con el objetivo de obtener realimentación sobre las tareas del
equipo y los obstáculos que se presentan.

Ventajas

● Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor

que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta
información el Product Owner establece su prioridad. De manera regular, en las
demos de Sprint el Product Owner comprueba que efectivamente los requisitos se han
cumplido y transmite se feedback al equipo.
● Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La metodología
está diseñada para adaptarse a los cambios de requerimientos que conllevan los
proyectos complejos.
● Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades
más importantes del proyecto antes de que esté finalizado por completo.
● Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una
versión funcional después de cada iteración, ayuda a la obtención de un software de
calidad superior.
 ● Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la
burocracia y a la motivación del equipo que proporciona el hecho de que sean
autónomos para organizarse.
● Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno
de inversión.
● Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media
del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es
posible estimar fácilmente para cuando se dispondrá de una determinada
funcionalidad que todavía está en el Backlog.
● Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en
primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto,
permite despejar riesgos eficazmente de manera anticipada.

Desventajas

● Funciona sobre todo con equipos reducidos. Las empresas grandes, por ejemplo,
deben estar sectorizadas o divididas en grupos con objetivos concretos. De lo
contrario, el efecto de la técnica se perderá.
● Requiere una exhaustiva definición de las tareas y sus plazos. Cuando estos dos
aspectos no se definen adecuadamente, Scrum se desvanece. Recuerda que la
división del trabajo en iteraciones (y de éstas en tareas específicas) son la esencia de
esta metodología.
● Exige una alta cualificación o formación. No es una modalidad de gestión propia de
grupos junior o que apenas estén en proceso de formación. Gran parte del éxito de
Scrum radica en la experiencia que aportan los profesionales de los equipos, quienes
por lo general acumulan años de experiencia.

2. Método de desarrollo de sistemas dinámicos (MDSD)

El método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development

Method o DSDM) es un método de desarrollo ágil de software, apoyado por su continua
implicación del usuario en un desarrollo iterativo y creciente que sea sensible a los
requerimientos cambiantes, para desarrollar un sistema que reúna las necesidades de la
empresa en tiempo y presupuesto.

Historia.

Tomando como fuente las bases teóricas y las experiencias de RAD (Rapad Application
Development) el consorcio DSDM se fundó en enero de 1994 con la finalidad de desarrollar
un modelo de desarrollo independiente de herramientas y que fuera de dominio público. Ed
Holt, presidente del consorcio en sus dos primeros años, afirmó que el uso de herramientas
RAD estaba necesitando un marco de procesos. La primera versión del modelo se publicó a
principios de 1995, junto con un programa de adopción temprana para obtener
retroinformación de las primeras organizaciones que lo adoptaran. Con la información y
experiencia que el consorcio iba obteniendo se publicó la versión 2 en noviembre de 1995, y
la 3 en agosto de 1997. Su evolución fue la siguiente:

● Año 1995, DSDM primera versión

● Año 2001, DSDM versión 4.1

● Año 2003, DSDM versión 4.2

● Año 2007, DSDM Atern

El modelo Métodos de Desarrollo de Sistemas Dinámicos presenta 9 principios que como

todo software de desarrollo ágil son los pilares del desarrollo de software.

● La obligación del usuario a implicarse Este es considerado el más importante de

los principios de este modelo. Esto es debido a que la implicación del usuario en el desarrollo
reduce en gran parte el número de errores y, por consiguiente, el dinero y tiempo utilizado
para corregir los mismos.

● Los equipos deben de tener el poder de tomar decisiones A todos los trabajadores
se les da permiso para tomar decisiones que afectan a: Requisitos en desarrollo. Requisitos
cuya funcionalidad se necesita en futuras interacciones. Priorización de requisitos y
características. Detalles técnicos.

● Realización de entregas tempranas El DSDM debe entregar constantemente y

tempranamente los productos, ello garantiza la detección rápida de errores para que sean
corregidos y revertidos rápidamente antes de que el coste de reparación sea demasiado
elevado. Estas entregas afectarán tanto al software como a la documentación que se
entregará junto al software terminado.

● Las entregas que se acepten han de ser adaptadas a la empresa Por lo general, la
Refactorización, el diseño y la mejora de las funciones son tareas que en los sistemas de
modelado de software solo realizan una vez, al comienzo como es el diseño, o al final como
es la refactorización o mejora de las funciones. Pero, el DSDM sostiene que estas tareas han
de formar parte del ciclo de vida del software y han de ser tareas que se deben de repetir una
vez con cada una de las entregas que la empresa haya aceptado para así conseguir una
mayor adaptación a la empresa y, como se dijo antes, que los errores no se hagan mucho
más grandes y su coste de reparación no se eleve demasiado. Por otra parte, repitiendo estas
faces una y otra vez se consigue una mucho mejor aproximación al software que desea la
empresa.

● El desarrollo es Iterativo e Incremental El tipo de desarrollo interactivo e incremental

es el que más se adapta a los principios ya mencionados. En cada iteración que se realiza el
software se hará cada vez más grande y completo hasta conseguir la última que sería el
software que se haya adaptado completamente al software que la empresa necesita. Un
punto de fuerte de este principio es que cuanto más pequeñas sean las iteraciones, vale decir
pequeños cambios, más fácil es identificar si estos cambios son correctos además de realizar
e identificar nuevos cambios.
 ● Todos los cambios que se hagan durante el desarrollo han de ser reversibles Este
principio va de la mano de los anteriores principios ya que dice, como el propio título indica,
que los cambios hechos deben ser reversibles sin dificultades y costes excesivos. Como la
esencia de este método es el constante cambio en el software este principio es imprescindible
ya que sin este los anteriores principios no serían compatibles dado que generaría mucho
trabajo procedente de la continua comunicación con usuario y cliente.

● Los requisitos se describen en alto nivel y tendrán una línea base El DSDM hasta
este punto propone que haya una gran libertad a la hora de cambiar los requisitos. Para
limitarlos se establecen una serie de requisitos en alto nivel al comenzar el proyecto,
formando una Línea Base sobre la que desarrollar. Así se forma una idea del alcance que
deben tener los requisitos y nos aseguramos que los cambios no alteran demasiado la
funcionalidad del ECS.

● Las pruebas se integran a lo largo del ciclo de vida Por lo general, en los procesos
de ingeniería de software, las pruebas son una de las últimas fases. Por el contrario el DSDM
propone que, para una rápida corrección de errores, las pruebas deben estar integradas
deben estar integradas dentro de las fases más tempranas de la elaboración y repetir
iterativamente.

● Enfoque cooperativo y colaborativo La programación cooperativa es comúnmente

utilizada en métodos de desarrollo ágil. Estas técnicas aceleran la resolución de problemas y
la construcción de un software más eficiente y con menos errores. La más común es la
programación por parejas en la que, mientras una de las dos personas codifica, la otra piensa
y resuelve como realizar el algoritmo o la clase que hay que escribir a continuación además
de revisar y ayudar a su compañero y viceversa. Este principio no solo afecta a los
programadores sino también a todas las partes interesadas.

Requisitos para el uso de DSDM

● Interactividad, los usuarios y los jefes de Desarrollo deben estar en constante actividad en
común.

● Motivación y participación entre las partes (humanas) que integran el equipo.

● Intercambio de ideas o funcionalidades necesarias.

Situaciones no aplicables para DSDM

● No existe aceptación por parte de la dirección y otros empleados.

● Existe la falta de motivación y participación.

● Poca habilidad por parte de los integrantes del equipo.

● Si no hay apoyo entre cliente y proveedor.

Roles
En todo modelo, no solo el ágil, existen diferentes roles que adoptan los integrantes del equipo
de trabajo. El DSDM identifica un total de 12 roles, aunque, estos pueden variar según las
necesidades del equipo de desarrollo en función del software que se desarrolle:

● Patrocinador ejecutivo: Es el rol más alto que adopta la organización. Es la fuente que
proporciona los fondos y recursos al proyecto. Es la posición más alta que toma decisiones.
● Visionario: Es el que tiene la responsabilidad de iniciar el proyecto. El visionario es el que
proporciona las necesidades que tiene la empresa del software. El visionario tiene también la
tarea de supervisar que el proyecto se desarrolle correctamente.

● Usuario “Embajador”: Proporciona al proyecto la información proveniente de la comunidad

de usuarios. Tiene la obligación de asegurar que los desarrolladores reciben suficiente
información de la comunidad de usuarios durante la fase de desarrollo.

● Usuario “Consejero”: Es cualquier usuario que proporcione al proyecto un buen punto de

vista de la aplicación.

● Jefe de Proyecto: Es la persona encargada de gestionar el proyecto en general.

● Coordinador Técnico: Es el responsable de organizar la arquitectura del proyecto y controlar

la calidad del software generado.

● Líder de Equipo: Se asegura de que el equipo funciona correctamente.

● Desarrollador: Interpreta los requisitos de sistema y los modela y desarrolla el código.

● Probador “Tester”. Es el encargado de comprobar que el software funciona correctamente,

así como de generar la documentación.

● Escriba: Toma nota de todos los requisitos, acuerdos y cambios que se realizan.

● Facilitador: Es la persona que se encarga de controlar el progreso facilitar y potenciar la

comunicación y el desarrollo.

● Roles especiales: Business Architect, Quality Manager, System Integrator, etc.

El DSDM presenta la siguiente diferenciación en cuanto a roles:

Fases y Etapas.

El DSDM está dividido en fases y etapas para organizar mejor las tareas a realizar en el
desarrollo del software. El modelo DSDM consta de 3 grandes fases, El pre-proyecto, Ciclo
de vida del software, y Post-Proyecto.

- El Pre-Proyecto

En esta fase se atienden varias sugerencias de proyectos posibles, entre las cuales se elige
una. Además, en esta fase se realiza una estimación de los fondos necesarios para
desarrollar el proyecto y se decide si el proyecto se va a realizar o no.

- El ciclo de vida del software

En esta fase el objetivo es la elaboración del proyecto, candidato, elegido en la fase pre-
proyecto. A su vez se divide en cuatro etapas:

● Estudio de Viabilidad y de Negocio

Los estudios que se plantean a continuación han de ser lo más cortos y esquemáticos
posibles, pero con la mayor completitud posible, dado que la creación de un documento
demasiado complejo retrasaría el proyecto, pero unos buenos estudios nos ayudarán a
enfocarlo mejor. En esta fase se intentarán definir características del proyecto, así como las
necesidades que esperan los usuarios de él. Al final del estudio se determinará una lista de
requisitos, que se priorizará según su necesidad para el desarrollo del resto de requisitos.

● Iteración del Modelo Funcional (Functional Model Iteration)

En esta fase se recogen los requisitos identificados en fases anteriores y se transforman en
Modelos Funcionales. Para ello se crean prototipos funcionales de los requisitos que dan una
idea al usuario de cómo va a funcionar la aplicación y así satisfacer el principio número 1. Los
prototipos funcionales son revisados por diferentes grupos de usuarios que valoran y
certifican la calidad del prototipo.

● Iteración de diseño y desarrollo (Design & Build Iteration)

La principal tarea de esta fase es transformar los Modelos funcionales obtenidos de la fase
anterior y completarlos para que satisfagan totalmente las necesidades del usuario. Para ello,
crearemos Prototipos de diseño, y al igual que en la fase anterior, los verificaremos con los
usuarios.

● Implementación

Por último, en la fase de implementación, los usuarios verifican que los prototipos cumplen
con lo deseado y se realiza la implementación de los mismos, así como el entrenamiento de
los futuros usuarios para que sepan utilizar la aplicación.

El siguiente gráfico resume todo el ciclo de vida del DSDM.

- El Post-Proyecto

Esta fase se utiliza para comprobar que el producto funciona correcta y eficientemente. En
esta fase se realizan tareas de mantenimiento, y de mejora del software si son requeridas.
Por lo general esta fase se produce durante los 6 meses siguientes a la entrega del proyecto
al cliente.

3. Programación Extrema - XP
La metodología XP o Programación Extrema es una metodología ágil y flexible utilizada para
la gestión de proyectos.

Extreme Programming se centra en potenciar las relaciones interpersonales del equipo de

desarrollo como clave del éxito mediante el trabajo en equipo, el aprendizaje continuo y el
buen clima de trabajo.

Esta metodología pone el énfasis en la retroalimentación continua entre cliente y el equipo de

desarrollo y es idónea para proyectos con requisitos imprecisos y muy cambiantes.

Características

Las características fundamentales del método son:

● Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

● Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo
pruebas de regresión. Se aconseja escribir el código de la prueba antes de la
codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java,
DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas
tres últimas inspiradas en JUnit, la cual, a su vez, se inspiró en SUnit, el primer
framework orientado a realizar tests, realizado para el lenguaje de programación
Smalltalk.
● Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo
por dos personas en un mismo puesto. La mayor calidad del código escrito de esta
manera -el código es revisado y discutido mientras se escribe- es más importante que
la posible pérdida de productividad inmediata.
● Frecuente integración del equipo de programación con el cliente o usuario. Se
recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
● Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas
frecuentes.
● Refactorización del código, es decir, reescribir ciertas partes del código para aumentar
su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han
de garantizar que en la refactorización no se ha introducido ningún fallo.
● Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo
de cada módulo en grupos de trabajo distintos, este método promueve el que todo el
personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes
pruebas de regresión garantizan que los posibles errores serán detectados.
● Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando
todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema
apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para
cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
● La simplicidad y la comunicación son extraordinariamente complementarias. Con más
comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto
más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una
comunicación más completa, especialmente si se puede reducir el equipo de
programadores.

Ventajas
⦁ Da lugar a una programación sumamente organizada.

⦁ Ocasiona eficiencias en el proceso de planificación y pruebas.

⦁ Cuenta con una tasa de errores muy pequeña.

⦁ Propicia la satisfacción del programador.

⦁ Fomenta la comunicación entre los clientes y los desarrolladores.

⦁ Facilita los cambios.

⦁ Permite ahorrar mucho tiempo y dinero.

⦁ Puede ser aplicada a cualquier lenguaje de programación.

⦁ El cliente tiene el control sobre las prioridades.

⦁ Se hacen pruebas continuas durante el proyecto.

⦁ La XP es mejor utilizada en la implementación de nuevas tecnologías.

Desventajas

⦁ Es recomendable emplearla sólo en proyectos a corto plazo.

⦁ En caso de fallar, las comisiones son muy altas.

⦁ Requiere de un rígido ajuste a los principios de XP.

⦁ Puede no siempre ser más fácil que el desarrollo tradicional.

Cuestionario
1 Los modelos de procesos de desarrollo de software no son importantes.

Falso Verdadero
2. Según Roger S. Presman, un proceso es la colección de actividades de trabajo, acciones
y tareas que se realizan cuando va a crearse algún producto

Falso Verdadero

3. El desarrollo ágil de software no envuelve un enfoque para la toma de decisiones en los

proyectos de software, que se refiere a métodos de ingeniería del software basados en el
desarrollo iterativo e incremental.

Falso Verdadero

4. El modelo SCRUM es un proceso en el que se aplican de manera regular un conjunto de

buenas prácticas para trabajar colaborativamente, en equipo y obtener el mejor resultado
posible de proyec

Falso Verdadero

5. Algunas de las desventajas de la PROGRAMACIÓN EXTREMA-XP son :

● Es recomendable emplearla sólo en proyectos a corto plazo.

● En caso de fallar, las comisiones son muy altas.

Falso Verdadero

6. Entre las características principales que tiene scrum se tiene q se debe realizar una reunión
cada vez que se presente un problema en el proyecto al menos 1 hora.

Falso Verdadero

7. Entre las ventajas que tiene Scrum es que se conoce la velocidad media del equipo por
sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar
fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en
el Backlog.

Falso Verdadero

8. ¿El modelo en espiral forma parte del modelo evolutivo?

Falso Verdadero

9. El modelo de desarrollo rápido de aplicación tiene un proceso cíclico

Falso Verdadero

10.¿En el modelo concurrente no todo funciona simultáneamente?

Falso Verdadero

Conclusiones
El desarrollo de software es uno de los pilares fundamentales de la Informática y al cual se
dedican muchas horas de esfuerzos en universidades, centros de investigación y empresas de
todos los tamaños.
Conforme la tecnología va avanzando, van apareciendo nuevas soluciones, nuevas formas de
programación, nuevos lenguajes, y un sin fin de herramientas que intentan realizar el trabajo del
desarrollador un poco más fácil. También surgen nuevos modelos de proceso de desarrollo y
nuevas metodologías que tratan de adaptar la manera de trabajar a las necesidades concretas
de una organización y de sus proyectos. Es importante conocer bien estos modelos, para tener
un esquema mental que nos permita gestionar proyectos y organizar equipos de manera
racional, cuando abordemos el desarrollo de software, especialmente en el caso de aplicaciones
grandes y complejas.