TALLER SOBRE METODOLOGÍAS DE DESARROLLO DE SOFTWARE.

GA1-
220501093-AA1-EV01

DORIAN ALEXANDER VILLA HERNANDEZ

EUVAR DIUZA

SERVICIO NACIONAL DE APRENDIZAJE

ANÁLISIS Y DESARROLLO DE SOFTWARE (2721470)
2023
1 CONTENIDO
2 INTRODUCCION ...................................................Error! Bookmark not defined.
2.1 PROPÓSITO ...................................................Error! Bookmark not defined.
2.2 ÁMBITO DEL SISTEMA .................................Error! Bookmark not defined.
3 DESCRIPCIÓN GENERAL ...................................Error! Bookmark not defined.
3.1 PERSPECTIVA DEL PRODUCTO .................Error! Bookmark not defined.
3.2 FUNCIONES DEL PRODUCTO......................Error! Bookmark not defined.
3.3 CARACTERÍSTICAS DEL USUARIO ............Error! Bookmark not defined.
3.4 RESTRICCIONES ...........................................Error! Bookmark not defined.
4 HISTORIAS DE USUARIO ....................................Error! Bookmark not defined.
2 QUE ES UNA METODOLOGIA Y PARA QUE SE UTILIZA

La metodología hace referencia al conjunto de procedimientos racionales utilizados

para alcanzar un objetivo que requiera habilidades y conocimientos específicos. La
metodología es una de las etapas específicas de un trabajo o proyecto que parte de
una posición teórica y conlleva a una selección de técnicas concretas o métodos
acerca del procedimiento para el cumplimiento de los objetivos. Es 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.

3 METODOLOGIA TRADICIONAL

Desarrollar un buen software depende de un gran número de actividades y etapas,

donde el impacto de elegir la metodología para un equipo en un determinado
proyecto es trascendental para el éxito del producto. Las metodologías tradicionales
son denominadas, a veces, de forma despectiva, como metodologías pesadas.
Centran su atención en llevar una documentación exhaustiva de todo el proyecto, la
planificación y control de este, en especificaciones precisas de requisitos y
modelado y en cumplir con un plan de trabajo, definido todo esto, en la fase inicial
del desarrollo del proyecto. Estas metodologías tradicionales imponen una disciplina
rigurosa 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. Otra de las características
importantes dentro de este enfoque, son los altos costos al implementar un cambio
y la falta de flexibilidad en proyectos donde el entorno es volátil.

4 WATERFALL (CASCADA)

En Ingeniería de software el desarrollo en cascada es denominado así por la

posición de las fases en el desarrollo de esta, que parecen caer en cascada “por
gravedad” hacia las siguientes fases. Es el enfoque metodológico que ordena
rigurosamente las etapas del proceso para el desarrollo de software, de tal forma
que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Al
final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final,
que se encarga de determinar si el proyecto está listo para avanzar a la siguiente
fase. Este modelo fue el primero en originarse y es la base de todos los demás
modelos de ciclo de vida. Este modelo comenzó a diseñarse en 1966 y se terminó
alrededor de 1970. El principal problema de esta aproximación es el que no
podemos esperar que las especificaciones iníciales sean correctas y completas y
que el usuario puede cambiar de opinión sobre una u otra característica. Además,
los resultados no se pueden ver hasta muy avanzado el proyecto por lo que
cualquier cambio debido a un error puede suponer un gran retraso además de un
alto coste de desarrollo. Como es evidente esto es solo un modelo teórico, si el
usuario cambia de opinión en algún aspecto tendremos que volver hacia atrás en el
ciclo de vida.

5 PROTOTYPING

Un prototipo es una versión preliminar de un sistema de información con fines de

demostración o evaluación. El prototipo de requerimientos es la creación de una
implementación parcial de un sistema, para el propósito explícito de aprender sobre
los requerimientos del sistema. Un prototipo es construido de una manera rápida tal
como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos,
posibilitando que ellos experimenten con el prototipo. Estos individuos luego
proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del
prototipo proporcionado, quienes capturan en la documentación actual de la
especificación de requerimientos la información entregada por los usuarios para el
desarrollo del sistema real. El prototipo puede ser usado como parte de la fase de
requerimientos (determinar requerimientos) o justo antes de la fase de
requerimientos (como predecesor de requerimientos). En otro caso, el prototipo
puede servir su papel inmediatamente antes de algún o todo el desarrollo
incremental en modelos incremental o evolutivo.

6 SPIRAL
Toma las ventajas del modelo de desarrollo en cascada y el de prototipos
añadiéndole el concepto de análisis de riesgo. Se definen cuatro actividades:

6.1 Planificación: en la que se recolectan los requisitos iniciales o nuevos

requisitos a añadir en esta iteración.
6.2 Análisis de riesgo: basándonos en los requisitos decidimos si somos
capaces o no de desarrollar el software y se toma la decisión de continuar o
no continuar.
6.3 Ingeniería: en el que se desarrolla un prototipo basado en los requisitos
obtenidos en la fase de planificación.
6.4 Evaluación del cliente: el cliente comenta el prototipo. Si está conforme
con él se acaba el proceso, si no se añaden los nuevos requisitos en la
siguiente iteración.

7 INCREMENTAL

Permite construir el proyecto en etapas incrementales en donde cada etapa agrega

funcionalidad. Estas etapas, consisten en requerimientos, diseño, codificación,
pruebas y entrega. Permite entregar al cliente un producto más rápido en
comparación del modelo en cascada.
 Reduce los riegos ya que provee visibilidad sobre el progreso de las nuevas
versiones. Provee retroalimentación a través de la funcionalidad mostrada.
 Permite atacar los mayores riesgos desde el inicio.
 Se pueden hacer implementaciones parciales si se cuenta con la suficiente
funcionalidad.
 Las pruebas y la integración son constantes.
 El progreso se puede medir en periodo cortos de tiempo.
 Resulta más sencillo acomodar cambios al acortar el tamaño de los
incrementos.
 Se puede planear en base a la funcionalidad que se quiere entregar primero.
 Por su versatilidad requiere de una planeación cuidadosa tanto a nivel
administrativo como técnico.

8 RAD

La metodología de desarrollo conocida como diseño rápido de aplicaciones RAD

(rápido application development) ha tomado gran auge debido a la necesidad que
tienen las instituciones de crear aplicaciones funcionales en un plazo de tiempo
corto. RAD es un ciclo de desarrollo diseñado para crear aplicaciones de
computadoras de alta calidad. El método comprende el desarrollo interactivo, la
construcción de prototipos y el uso de utilidades CASE (Competer Aided Software
Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a
englobar también la usabilidad, utilidad y la rapidez de ejecución. Hoy en día se
suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario
tales como Glade, o entornos de desarrollo integrado completos. Algunas de las
plataformas más conocidas son Visual Studio, Lazarus, Gambas, Delphi, Foxpro,
Anjuta, Game Maker, Velneo o Clarión. En el área de la autoría multimedia, software
como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de
desarrollo rápido de aplicaciones, dentro de ciertos límites.

9 METODOLOGIAS ÁGILES

Este enfoque nace como respuesta a los problemas que puedan ocasionar las
metodologías tradicionales y se basa en dos aspectos fundamentales, retrasar las
decisiones y la planificación adaptativa. Basan su fundamento en la adaptabilidad
de los procesos de desarrollo. Un modelo de desarrollo ágil generalmente es un
proceso Incremental (entregas frecuentes con ciclos rápidos), también Cooperativo
(clientes y desarrolladores trabajan constantemente con una comunicación muy fina
y constante), Sencillo (el método es fácil de aprender y modificar para el equipo) y
finalmente Adaptativo (capaz de permitir cambios de último momento). Las
metodologías ágiles proporcionan una serie de pautas y principios junto a técnicas
pragmáticas que hacen que la entrega del proyecto sea menos complicada y más
satisfactoria tanto para los clientes como para los equipos de trabajo, evitando de
esta manera los caminos burocráticos de las metodologías tradicionales, generando
poca documentación y no haciendo uso de métodos formales. Estas metodologías
ponen de relevancia que la capacidad de respuesta a un cambio es más importante
que el seguimiento estricto de un plan.

10 PROGRAMACIÓN EXTREMA

La programación extrema (XP) puede que marque un antes y un después en la

ingeniería del software. Ésta nueva forma de trabajo fue creada por Kent Beck, Ward
Cunninghamn y Ron Jeffries a finales de los noventa. La programación extrema ha
pasado de ser una simple idea para un único proyecto a inundar todas las factorías
de software. Algunos la definen como un movimiento social de los analistas del
software hacia los hombres y mujeres de negocios, de lo que debería ser el
desarrollo de soluciones en contraposición a los legalismos de los contratos de
desarrollo. Es el más destacado de los procesos ágiles de desarrollo de software.
Al igual que éstos, la programación extrema se diferencia de las metodologías
tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la
previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre
la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de
proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en
cualquier punto de la vida del proyecto es una aproximación mejor y más realista
que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos
después en controlar los cambios en los requisitos.

11 SCRUM

La metodología de trabajo de Scrum tiene sus principios fundamentales en la

década de 1980, la cual fue desarrollada por su necesidad en procesos de
reingeniería por Goldratt, Takeuchi y Nonaka. El concepto de Scrum tiene su origen
sobre los nuevos procesos de desarrollo utilizados en productos exitosos en Japón
y los Estados. Los equipos que desarrollaron estos productos partían de requisitos
muy generales, así como novedosos, y debían salir al mercado en mucho menos
del tiempo del que se tardó en lanzar productos anteriores. Estos equipos seguían
patrones de ejecución de proyecto muy similares. En este estudio se comparaba la
forma de trabajo de estos equipos altamente productivos y multidisciplinares con la
colaboración entre los jugadores de Rugby y su formación de Scrum, de la cual se
tomó su nombre. 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 un proyecto. Estas prácticas se apoyan unas a otras y
su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.
12 CRYSTAL

Crystal no es solo una metodología de desarrollo de software ágil, ya que se la

considera una familia de metodologías, debido a que se subdivide en varios tipos
en función a la cantidad de persona involucradas en el proyecto. Esta nueva serie
de metodologías fue creada por el antropólogo Alistair Cockburn, el cuál tomo como
base el análisis de distintos proyectos de desarrollo de software y su propia
experiencia, lo cual fusionando ambos aspectos dio lugar este nuevo método de
trabajo. Estas metodologías presentan un enfoque ágil, con gran énfasis en la
comunicación y con cierta tolerancia que la hace ideal en los casos en que sea
inaplicable la disciplina requerida por Extreme Programming. Crystal Clear es la
encarnación más ágil de la serie y de la que más documentación se dispone. La
misma se define con mucho énfasis en la comunicación y de forma muy liviana en
relación con los entregables. Crystal maneja iteraciones cortas con feedback
frecuente por parte de los usuarios/clientes, minimizando de esta forma la necesidad
de productos intermedios. Otra de las cuestiones planteadas es la necesidad de
disponer de un usuario real, aunque sea de forma parte time para realizar
validaciones sobre la UI (Interface de Usuario) y para participar en la definición de
los requerimientos funcionales y no funcionales del software.

13 KANBAN

Esta metodología tiene como base de su origen la aplicación de los procesos de

producción JIT (Just in Time) ideados por la empresa automotriz Toyota, en la cual
utilizaban tarjetas visuales para identificar necesidades de material en la cadena de
producción. Kanban se basa en la idea de que el trabajo en curso debería limitarse,
y sólo deberíamos empezar con algo nuevo cuando un bloque de trabajo anterior
haya sido entregado o ha pasado a otra función posterior de la cadena. La
metodología Kanban utiliza un mecanismo de control visual para hacer seguimiento
del trabajo conforme este viaja a través del flujo de valor. Normalmente, se emplea
un panel o pizarra con notas adhesivas o un panel electrónico de tarjetas para
gestionar el flujo de trabajo y las asignaciones. Las mejores prácticas apuntan al
uso de ambos métodos. El Kanban (o tarjeta visual) implica que se genera una señal
visual para indicar que hay nuevos bloques de trabajo que pueden ser comenzados
porque el trabajo en curso actual no alcanza el máximo acordado.

14 FEATURE DRIVEN DEVELOPMENT (FDD)

La metodología ágil FDD, con sus siglas en inglés Feature Driven Development, fue
impulsada por Jeff de Luca y Meter Coad en los años 80. Como las otras
metodologías adaptables, se enfoca en iteraciones cortas que entregan
funcionalidad tangible. Dicho enfoque no hace énfasis en la obtención de los
requerimientos sino en cómo se realizan las fases de diseño y construcción. Sin
embargo, fue diseñado para trabajar con otras actividades de desarrollo de software
y no requiere la utilización de ningún modelo de proceso específico. Hace énfasis
en aspectos de calidad durante todo el proceso e incluye un monitoreo permanente
del avance del proyecto. Al contrario de otras metodologías, FDD promete ser
conveniente para el desarrollo de sistemas críticos y está orientada a equipos de
trabajo más grandes, con más personas que aquellos a los que normalmente se
aplican otras metodologías como Scrum. Define claramente entregas tangibles y
formas de evaluación del progreso del proyecto. No hace énfasis en la obtención de
los requerimientos sino en cómo se realizan las fases de diseño y construcción. FDD
se basa en un ciclo muy corto de iteración, nunca superior a dos semanas, y en el
que el análisis y los desarrollos están orientados a cumplir una lista de Features que
debe tener el software a desarrollar.

15 SOFTWARE DEVELOPMENT (ASD)

Esta metodología parte de la idea de que las necesidades del cliente son siempre
cambiantes durante el desarrollo del proyecto y posteriormente a su entrega. Esta
técnica fue desarrollada por Jim Highsmith y Sam Bayer a comienzos de los 90. La
novedad de esta metodología es que en realidad no es una metodología de
desarrollo de software, sino un método/técnica, a través del cual inculcar una cultura
adaptativa a la empresa para adaptarse al cambio y no luchar contra él. En ella no
hay un ciclo de vida estático (planear-diseñar-construir), si no que ofrece un ciclo de
vida iterativo, donde cada ciclo puede ser modificado al tiempo que otro es
ejecutado (especular colaborar-aprender).

16 LEAN DEVELOPMENT (LD) Y LEAN SOFTWARE DEVELOPMENT (LSD)

El desarrollo Lean es una adaptación a los entornos de desarrollo de software, del

método de producción que desarrolló Toyota, para equipos pequeños de
programadores. Se fundamenta principalmente en constituir un equipo fuerte y
altamente preparado capaz de llevar a cabo cualquier tarea en poco tiempo, legando
todo a la eficacia y la cohesión de los componentes del equipo y obviando los
procesos y la burocracia que conlleva normalmente el tener un sistema de
producción preestablecido. La filosofía Lean consiste en tener un equipo muy
preparado, altamente motivado y muy unido. Los activos más importantes para tener
en cuenta cuando se está desarrollando un proyecto bajo Lean Development no son
el tiempo o el dinero que se está invirtiendo sino el grado de compromiso y, sobre
todo, cuánto está aprendiendo el equipo. Se considera que cuanto más hayan
aprendido los miembros del equipo y más unidos se sientan, la cantidad de tiempo
y dinero necesario para llevar a cabo los desarrollos será cada vez menor.

17 PROCESO UNIFICADO DE DESARROLLO SOFTWARE

Proceso Unificado de Desarrollo (RUP) es una metodología de desarrollo de

software que está basado en componentes e interfaces bien definidas, y junto con
el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más
utilizada para el análisis, implementación y documentación de sistemas orientados
a objetos. Es un proceso que puede especializarse para una gran variedad de
sistemas de software, en diferentes áreas de aplicación, diferentes tipos de
organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. RUP
no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización. Es el
resultado de varios años de desarrollo y uso práctico en el que se han unificado
técnicas de desarrollo, a través del UML, y trabajo de muchas metodologías
utilizadas por los clientes. La versión que se ha estandarizado vio la luz en 1998 y
se conoció en sus inicios como Proceso Unificado de Rational 5.0, de ahí las siglas
con las que se identifica a este proceso de desarrollo.

18 DIFERENCIAS ENTRE METODOLOGIA TRADICIONAL Y ÁGIL

En las metodologías tradicionales el principal problema es que nunca se logra

planificar bien el esfuerzo requerido para seguir la metodología. Pero entonces, si
logramos definir métricas que apoyen la estimación de las actividades de desarrollo,
muchas prácticas de metodologías tradicionales podrían ser apropiadas. El no
poder predecir siempre los resultados de cada proceso no significa que estemos
frente a una disciplina de azar. Lo que significa es que estamos frente a la necesidad
de adaptación de los procesos de desarrollo que son llevados por parte de los
equipos que desarrollan software. 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 por
cada proyecto, la problemática sería definir cada una de las prácticas, y en el
momento preciso definir parámetros para saber cuál usar. Es importante tener en
cuenta que el uso de un método ágil no vale para cualquier proyecto. 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.