TALLER SOBRE

30-5-2022 METODOLOGÍAS DE
DESARROLLO DE
SOFTWARE
GA1-220501093-AA1-EV01

Jorge Barrera
Tecnología en análisis y desarrollo de software
 INTRODUCCION

El taller a continuación, se hablará sobre las metodologías y los distintos marcos de trabajo para
el desarrollo de software que utilizan las organizaciones, también se resaltaran las
características de cada metodología y cada marco de trabajo.
 METODOLOGIA DE DESARROLLO DE SOFTWARE

Una metodología hace referencia a un conjunto de procedimientos genéricos y lógicos que se

usan para alcanzar un objetivo particular usando un conjunto de habilidades y conocimientos.

Las metodologías de desarrollo de software siempre tienen un inicio desde un componente

teórico y cuando son implementadas por los equipos de trabajo conllevan a la utilización de un
conjunto de técnicas y métodos que al final determinaran las tareas generales y específicas
que se deberían realizar para alcanzar un objetivo.

Existen diferentes tipos de metodologías de desarrollo de software que fueron ideadas

pensando en problemas particulares presentados en l industria en contextos específicos, por lo
cual es importante conocer sus diferentes características y contrastarlas con las necesidades
particulares a las que se enfrenta a la hora de desarrollar un producto y servicio. Es decir, cada
una de estas tiene ventajas y enfoques que pueden ser reutilizados e diferentes momentos.

Existen dos grandes clasificaciones de metodologías de desarrollo de software que se agrupan

generalmente como marcos de trabajo tradicionales o marcos de trabajo agiles.

2. MARCO DE TRABAJO TRADICIONALES

Los marcos de trabajo tradicionales o metodologías tradicionales se caracterizan por centrar la

mayor parte de esfuerzo e la planeación y control de proceso, lo que conlleva a una
documentación exhaustiva y precisa de los artefactos que describen los requisitos y los
modelos del sistema en las etapas iniciales del desarrollo del proyecto. (Maida y pacienzia,
2015)

2.1 CASCADA

Según someville (2005) el modelo en cascada se descompone de cinco etapas principales que
se asocian con actividades fundamentales en el proceso de desarrollo de software, las cuales
son:

 Implementación:

Incluye la construcción del software a partir de los diseños del sistema, se verifican todos los
módulos que se vayan construyendo y se valida su funcionamiento.

 Funcionamiento y mantenimiento:

En esta fase entra el proyecto una vez el producto o servicio de software es entregado para ser
usado por el cliente, en el mantenimiento se corrigen errores que no se detectaron en fases
anteriores, en la implementación, se realizan mejoras del sistema y se incorporan nuevos
requerimientos.

 Verificación:

En esta fase se hace el proceso formal de pruebas, se verifican que los módulos creados
funciones correctamente y se verifica que cumplan con los requerimientos establecidos en la
primera fase.
  Análisis:

En esta fase se realiza una especificación muy detallada del sistema, indica los alcances,
servicios a construir y restricciones, también se encarga principalmente en la especificación de
los requisitos.

 Diseño:

En esta fase, se establece la arquitectura final del sistema, se describen todas las abstracciones
fundamentales del software y relaciones, generalmente usando un lenguaje de modelado.

El modelo en casada define cuatro grupos de roles típicos los cuales se mencionan a
continuación:

Desarrolladores:

Es el rol más importante en la metodología cascada ya que son los encargados directos de la
creación de código.

Testers:

Encargados de encontrar fallas en los productos finales y retornar el software a los

desarrolladores para arreglar todos los defectos.

Analistas del negocio:

Encargado de la realización de estrategias de negocio que le permitan al producto software

alcanzar popularidad en el mercado digital.

Administrador del proyecto:

es responsable de la calidad final del software. Administrar el proyecto y los subdivide en

tareas entre los miembros del equipo.
2.2 PROCESO RACIONAL UNIFICADO – RUP

RUP es una sigla en inglés equivalentes a proceso racional unificado, el cual es un proceso de
desarrollo de software tradicional basado en el modelo cascada y que fue desarrollado por la
empresa rational software qué es propiedad de IBM, esta metodología se centra en la
arquitectura y es guía por casos de usos (requerimientos) (kruchten, 2003)

RUP divide el proceso de desarrollo en cuatro grandes fases, dentro de las que se realizan
algunas iteraciones donde se desglosan, en mayor o menor intensidad, un conjunto de
disciplinas según la fase que se está abordando. a continuación, se observan las fases y
disciplinas propuestas por RUP.

3.1 FASES Y DISCIPLINAS A DESARROLLAR:

FLUJOS DE TRABAJO DE PROCESOS

 Modelado de negocios
 Requerimientos
 Análisis y diseño
 Implementación
 Prueba
 Desarrollo
 Configuración y administración del cambio
 Administración del proyecto
 Ambiente

FASES

 Incepción
 Elaboración
 Construcción
 Transición

2.2.3 FASES Y SU IMPACTO EN EL PROCESO:

Primera fase:

La primera gran fase definida por RUP es la de inicio, en la cual se abordan actividades
principalmente enfocadas en la comprensión del problema y el tipo de tecnología utilizar, por
lo que hay una gran carga en actividades relacionadas con la disciplina de modelado del
negocio y especificación de requisitos.

Segunda fase:

La segunda fase es la elaboración, donde se centra la mayor parte del esfuerzo en la definición
general de la arquitectura del sistema y el refinamiento de requisitos y modelado del negocio.
RUP Generalmente se apoya en el lenguaje de modelado UML para el modelado del negocio y
descripción de la arquitectura.

Tercera fase:

La tercera fase corresponde a la construcción, donde se centran en las actividades

relacionadas con la construcción del producto. Normalmente esta fase está constituida por
varias iteraciones donde en cada una de ellas se desarrolla un subconjunto de requerimientos
que normalmente están especificados como casos de uso. Cada una de esas pequeñas
iteraciones se realiza utilizando el modelo cascada y el conjunto de todas las iteraciones
producen el final una versión del producto

Cuarta fase:

A la cuarta fase se le denomina transición y en esta se desarrollan principalmente las

disciplinas de prueba y despliegue, es decir las actividades encaminadas a garantizar que el
producto esté listo para entrega a sus usuarios.

2.2.4 ARTEFACTOS COMUNES PARA EL DESARROLLO DEL SOFTWARE:

 Documento de visión
 Documento de especificación de requisitos
 Diagrama de casos de uso
 Modelos conceptuales (clases y entidad relación)
 Diagramas que representan la vista de implementacion como:
 Diagrama de secuencia.
 Diagrama de estados.
 Diagramas de colaboración, entre todos.

Las disciplinas, por otra parte, representan un conjunto de actividades relacionadas con un
área específica del proyecto y están inspiradas en el modelo en cascada. RUP establece las
siguientes disciplinas según Kruchten (2003)

 Modelado de negocios.
 Requerimientos.
 Análisis y diseño.
 Implementación.
 Pruebas.
 Despliegue.
 Configuración.
 Administración del cambio.
 Administración de proyectos y ambiente.

RUP propone una categorización de roles encargados de la realización de actividades dentro

de cada uno de las disciplinas que son:

ANALISTAS:

En los roles específicos clasificados en la categoría de los analistas se encuentran:

 Analistas de procesos de negocio.

 Diseñadores del negocio.
 Analistas del sistema.
 Especificador de requisitos.
 Diseñadores de interfaces de usuario o similares.

DESARROLLADORES:

Dentro de los roles específicos clasificados en la categoría de desarrolladores se encuentran:

 Arquitectos de software.
  Diseñador de bases de datos.
 Desarrollador backend y frontend.
 Cualquier otro rol relacionado con procesos de codificación o integración de código.

PROBADORES:

En los roles específicos clasificados en la categoría de probadores se encuentran:

 Los diseñadores de pruebas.

 Los implementadores de pruebas.

ENCARGADOS Y OTROS ACTORES:

Dentro de los roles específicos clasificados en la categoría de otros se encuentran:

 Artistas gráficos.
 Administradores de sistemas.
 Especialista en herramientas.
 Stakeholders.
 Cualquier otro rol no especificado anteriormente.

MARCOS DE TRABAJO AGILES

Los marcos de trabajo ágiles o metodologías ágiles para el desarrollo de software nacen como
otra opción para abordar proyectos donde no es posible tener un detalle completo de los
requerimientos y sus estimaciones en la primera fase del proyecto o dónde es necesario para
hacer procesos de adaptabilidad a lo largo del proceso de desarrollo de software (maida y
pacienzia, 2015)

Las metodologías ágiles proveen un conjunto de pautas y principios que buscan facilitar y
priorizar la entrega de productos sobre procesos de documentación exhaustiva, siendo los más
simples, donde interactúa el cliente final desde las primeras etapas del proyecto. el inicio de
las metodologías ágiles nació en el año 2001 a partir del manifiesto ágil de software donde se
establecen cuatro valores fundamentales (manifiesto ágil, 2001)

 Individuos e interacciones sobre procesos y herramientas.

 Software funcionando sobre documentación extensiva.
 Colaboración con el cliente sobre negociación contractual.
 Respuesta ante el cambio sobre seguir un plan.

3.1 PROGRAMACION EXTREMA – XP

XP es la abreviación comúnmente utilizada para referirse a extreme programing, qué es un

marco de desarrollo de software ágil que busca producir software de alta calidad en contextos
con requisitos altamente cambiables, riesgos que involucran tiempo fijo con tecnologías
nuevas y equipos de trabajo pequeños ubicados en un mismo sitio.

En XP se define cinco valores según Beck y Andrés 2004

COMUNICACIÓN: el desarrollo de software requiere de trabajo en equipo por lo cual es

importante la transferencia de conocimientos y utilizar medios de comunicación apropiados
cómo se propone la discusión cara a cara con herramientas que permitan dibujar o escribir,
como, por ejemplo: un tablero.
SIMPLICIDAD: esto se refiere a hacer solo las cosas que sean absolutamente necesarias
evitando el desperdicio coma elaborar las cosas de forma que sean fácil entender por otros y
abordar solo requisitos conocidos.

RETROALIMENTACIÓN: esto permite identificar áreas de mejora y revisión constante de las

prácticas implementadas en el proceso de forma que se puedan establecer procesos de mejora
permanente.

CORAJE: se refiere al actuar sobre situaciones que pueden ser retadoras para el equipo como,
por ejemplo:

 enfrentar problemas organizacionales.

 Intentar implementar funcionalidades de forma diferentes como lo convencional no
funciona y aceptar comentarios, etcétera.

RESPETO: los miembros del equipo deben respetarse entre sí para comunicarse y trabajar en
equipo punto cada persona contribuye un favor de lograr el objetivo del equipo

LOS ROLES FUNDAMENTALES ESTABLECIDOS POR ESTE MARCO DE TRABAJO ÁGIL SON LOS
SIGUIENTES:

 Cliente.
 Programador.
 Coach.
 Tester.
 Manager.

LOS CLIENTES: son los encargados del establecimiento de las prioridades del proyecto y las
necesidades puntuales.

LOS PROGRAMADORES: se encargan de transformar y darle forma estos requerimientos en

bloques de código funcional cómo son el centro del marco de extreme programing.

LOS TESTER: se encargan de la aplicación de rigurosas pruebas para garantizar la calidad de los
productos y servicios desarrollados.

EL COACH: es una figura encargada de brindar asesoría a los miembros del equipo y son los
que definen el rumbo al proyecto.

EL MANAGER: se encarga de la coordinación de actividades, del aseguramiento los recursos

requeridos para el proyecto Y quién tiene la responsabilidad de la comunicación externa.

3.2 DESARROLLO RÁPIDO DE APLICACIONES – RAD

RAD (Desarrollo rápido aplicaciones) es otra metodología de desarrollo de software ágil que se
centra en el desarrollo rápido aplicaciones mediante la realización de interacciones frecuentes
y realimentación constante y fue inventado por James Martín en 1991.

Algunas características fundamentales de RAD son:

  Mayor flexibilidad y adaptabilidad a cualquier ajuste que se debe realizar durante el
proceso de desarrollo.
 Interacciones rápidas que reducen el tiempo de desarrollo y mantienen un ritmo
entrega acelerado.
 punto se fomenta la reutilización de código.
 Mejor gestión del riesgo como allá que las partes interesadas discuten y abordan
cualquier vulnerabilidad mientras se construyen los productos.

A continuación, cómo se describen las fases propuestas en RAD

La primera fase definida corresponde a la definición y finalización de los requisitos del

proyecto punto en esta fase las partes interesadas se reúnen para definir los requisitos del
proyecto definiendo entre otros casos:

 Los objetivos.
 Las expectativas.
 Los plazos.
 Presupuesto del proyecto.

La segunda fase aborda la construcción de prototipos los cuales son construidos, validados Y
mejorados a partir de la validación con los usuarios y una vez son aprobados pasan a la tercera
fase donde estos prototipos son transformados en modelos funcionales.

En la cuarta fase se enfoca en la realización de pruebas exhaustivas para garantizar que todos
los elementos construidos funcionan bien individualmente y también de forma colectiva.
Finalmente, en la última fase se realizan todas las actividades de lanzamiento del producto lo
que involucra al carga inicial de datos y entrenamiento a los usuarios.

Según HKSAR (2009) los roles mas importantes de la metodologia RAD son:

 Facilitador.
 Escriba.
 Equipo swat.
 Administrador del modelo.
 Administrador de bases de datos.
  Equipos de plaificacion de workshop.
 Equipo de diseño de uruario.
 Equipo de soporte de construccion.
 Equipo de transicion.

3 SCRUM

Scrum es un marco de trabajo ágil de muy amplio uso en la industria del software que se
fundamentan los valores y principios ágiles definidos en manifiesto ágil como 2001 y dónde se
definen tres pilares fundamentales según scrum studio.com a 2013 los cuales se describen a
continuación:

TRANSPARENCIA:

hace referencia a que cualquier proceso de scrum puede ser conocido por cualquiera. Esto es
posible por medio de eventos como:

 Las reuniones de revisión y reuniones diarias.

 Artefactos como la pila de producto.
 Cronograma de lanzamiento.
 Documentos de visión del proyecto.
 Instrumentos de seguimiento como: burndown chart o el tablero de scrum (scrum
board)

Inspección:

permite que cualquiera pueda estar enterado de las actividades realizadas por otros y en
general conocer el estado actual de los procesos.

Adaptación:
por medio de la transparencia y la inspección es posible fijar actividades de mejora que
permita modificar todo tipo de procesos en pro de lograr más altos estándares de calidad.

Dentro de los roles hay una división en dos categorías fundamentales:

Roles centrales que hacen referencia los requeridos obligatoriamente para la creación de un
producto como están altamente comprometidos y de los cuales depende el éxito o no de un
proyecto.

Los roles no centrales que se refieren a todo el personal interesado en el proyecto pueden
interactuar con el equipo como pero no son los responsables del éxito del mismo, dentro de
esta categoría están los stakeholders, directivos, gerentes, marketing, asesores, etc.

3.3.1 ROLES DE SCRUM

DUEÑO DEL PRODUCTO (PRODUCT OWNER)

Persona con amplio conocimiento en el negocio del cliente como a sus necesidades y las
tendencias del mercado para el área específica. Este rol está encargado de maximizar el valor
de negocio entregado al cliente y es el único responsable del control del producto y su
priorización. Este también representa al cliente en algunos procesos de demostración de
avances y determina cuando aprobar o no una entrega.

SCRUM MASTER

Es un rol que se encarga de facilitar los procesos al interior del equipo de trabajo removiendo
cualquier impedimento y apoyando procesos de empoderamiento personal, debe velar porque
los elementos propios del marco de trabajo scrum se apliquen de manera correcta.
EQUIPO DE DESARROLLO (DEVELOPER TEAM)

Son los responsables de la transformación de los requerimientos en código ejecutable a ser

usado por el cliente como a, pero también son responsables de la planificación de las
interacciones, establecimiento de características para tener en cuenta en la verificación de un
requerimiento terminado y presentación de avances a los clientes. Generalmente es un equipo
auto organizado y auto gestionado.

3.3.2 ARTEFACTOS IMPORTANTES DE SCRUM

Pila de producto (Producto backlog): lista priorizada de requerimientos generalmente escritos

en formato de historias de usuarios que representan todas las características del sistema
construir.

PILA DE SPRINT (SPRINT BACKLOG): lista de requerimientos seleccionados del product backlog
por el equipo de trabajo para ser desarrollados durante un Sprint particular. Este es uno de los
artefactos generados en la reunión de planeación del Sprint.

BURNDOWN CHART: es un gráfico visual de dos ejes que muestra a los equipos la cantidad de
trabajo pendiente por completar (eje y) y el tiempo disponible para hacerlo (eje x). este
generalmente se realiza por cada sprint ubicando la cantidad de trabajo realizar del sprint
backlog (usualmente medid por puntos de historia o de horas de trabajo) en un tiempo 0 y por
cada día finalizado se resta la cantidad de puntos de historia u horas de cada tarea
completada.

3.3.3 PRINCIPALES BENEFICIOS DEL MARCO DE TRABAJO SCRUM

 Es posible gestionar las expectativas del cliente de manera regular, ya que, este puede
y debe participar en las reuniones de revisión, por lo que, está enterado todo el
tiempo del estado actual del proyecto.
 El cliente puede obtener resultados importantes y utilizables desde las primeras
interacciones, ya que, la lista de producto está priorizada para ofrecer mayor valor en
el menor tiempo posible y porque cada finalización de sprint debe tener como
resultado una versión totalmente funcional.
 El proyecto puede iniciar con requerimientos de muy alto nivel y es fácil administrar
los cambios.
 La participación constante del cliente permite mitigar riesgos del proyecto desde sus
primeras etapas.
 Los procesos de retrospectiva permiten establecer actividades permanentes de mejora
continua en función de las experiencias del equipo.
 CONCLUSIONES

En el taller desarrollado anteriormente, como estudiamos los diferentes tipos de metodologías

de desarrollo de software, entre ellos tenemos los Marcos tradicionales, a los cuales son:

 Cascada
 proceso racional unificado - RUD

De igual forma se estudiaron los marcos de trabajo ágiles, qué son:

 Programación extrema – XP
 Desarrollo rápido de aplicaciones – RAD
 Scrum.

Aplicando estas metodologías a nuestro proyecto de software, lograremos un producto final

en menos tiempo y con menos errores.
 BIBLIOGRAFIA

 Etapas y metodologías del proceso de desarrollo de software. (2016, 24 octubre).

YouTube. https://www.youtube.com/watch?v=Cnheob-ohtE
 Metodologías de desarrollo de software. (2022, febrero).
https://sena.territorio.la/content/index.php/institucion/Titulada/institution/SENA/Tec
nologia/228118/Contenido/OVA/CF6/index.html#/