METODOLOGÍAS

PARA EL
DESARROLLO DE
SOFTWARE
METODOLOGÍAS TRADICIONALES
PARA RESPONDER A ESTOS RETOS
PARA RESPONDER A ESTOS RETOS

➔ Se necesita cierta organización

➔ Se definen los primeros esquemas o modelos de procesos:
◆ Conjunto de actividades que se ejecutan para crear un producto
 ESQUEMAS Y MODELOS DE PROCESOS

Hay un conjunto de actividades o fases “genéricas”, como:

➔ Requisitos
➔ Modelado (Análisis y Diseño)
➔ Implementación, construcción, desarrollo
➔ Pruebas dinámicas o estáticas
- Agile Testing
➔ Despliegue, Mantenimiento, Postmortem o
Implantación

➔ ¿Existen prerrequisitos entre ellas?

➔ ¿Se pueden repetir o ejecutar en paralelo?
 CICLO DE VIDA DEL DESARROLLO DEL SOFTWARE (SDLC)

SDLC Nos permite definir cuál será el proceso usado para especificar
y transformar requisitos de software en un producto o servicio
entregable al cliente.
Producto: Tangible, se adquiere (no se requiere involucrar al cliente),
tiende a generarse en masa, se mantiene en el tiempo
(almacenable)
Servicio: Intangible, la mayoría son hechos a la medida (involucra al
cliente), se generar individualmente, es perecedero

➔ Hay varios modelos, que definen diferentes fases o actividades y

cómo se relacionan entre sí (el “flujo” del proceso)
SDLC: MODELO EN CASCADA O SECUENCIAL

Cada fase del proceso se desarrolla de forma

consecutiva, de modo que cada etapa de la secuencia
no se inicia hasta que no ha concluido la anterior.

Si durante el proceso se detecta algún error se

retrocede hasta la etapa correspondiente para
subsanar.

Es un proceso lento, pero requiere poco esfuerzo de

gestión y genera poca cooperación
interdepartamental: "Tú fabricas lo que yo diseño y él
vende lo que tú fabricas".
 SDLC: CUANDO UTILIZAR EL MODELO EN CASCADA

La metodología en cascada se suele emplear, en aquellos

proyectos cuyos requisitos y procesos se
pueden describir de forma precisa
durante la fase de planificación.

Los procedimientos estrictamente lineales se adaptan bien a

proyectos de software pequeños, sencillos y
claramente estructurados.
SDLC: CUANDO UTILIZAR EL MODELO EN CASCADA

- Puede funcionar bien para proyectos pequeños donde las

especificaciones se pueden cerrar con más facilidad y donde los
cambios de alcance sean pocos o ninguno.

- Es muy adecuado para proyectos donde el coste del error es muy

grande: diseñar un avión, enviar un cohete a la luna, un tren de
alta velocidad, etc
SDLC: MODELO BASADO EN PROTOTIPO O ITERATIVO

Hay dos premisas principales en las que se basa este

modelo:
● El cliente en ocasiones no sabe lo que
necesita, la metodología le permite
descubrirlo sin mucho riesgo.

● En el desarrollo de software, los procesos

tienden a cambiar con mucha frecuencia,
dicha metodología es flexible al cambio.
 SDLC: CUANDO UTILIZAR EL MODELO DE PROTOTIPADO

➔ Concurrente está dirigido a: satisfacer las necesidades del

usuario.

➔ En cambio los otros modelos están determinados por la

variable tiempo
◆ cuanto más tarden, más se atrasan en la fase de desarrollo.
 SDLC: MODELO DE VERIFICACIÓN Y VALIDACIÓN

Integración continua - Pruebas unitarias

- Desarrollo por etapas.
Pruebas estáticas ocurren en la fase
de Análisis
Pruebas dinámicas ocurren en la
fase de desarrollo

https://www.fing.edu.uy/tecnoinf/maldonado/cursos/ingsoft/materiales/teorico/is09-Verificacion-Validacion.pdf
SDLC: MODELO DE VERIFICACIÓN Y VALIDACIÓN

PRUEBAS ESTÁTICAS (FASE: ANÁLISIS) PRUEBAS DINÁMICAS (FASE: DESARROLLO)

VERIFICACIÓN - Equipo de trabajo VALIDACIÓN - Con el cliente

Inspección de requerimientos Pruebas basadas en especificaciones => Caja negra

- Requisitos obsoletos Pruebas basadas en estructuras => Caja blanca
- Requisitos faltantes
Pruebas basadas en la experiencia
Análisis estático automatizado
Pruebas de aceptación
- Errores de flujo de datos
Pruebas de regresión
- Errores de diseño
- Conformidad con los estándares Pruebas de integración
SDLC: MODELO INCREMENTAL
SDLC: MODELO EN ESPIRAL O EVOLUTIVO
 SDLC: CUANDO UTILIZAR EL MODELO DE ESPIRAL O EVOLUTIVO

Los proyectos ejecutados con el modelo en espiral empiezan siendo

pequeños, investigando riesgos que se pueden tolerar, para pasar a
agrandarse poco a poco.

Habitualmente tiene sentido aplicar este método en proyectos

grandes, extensos, costosos y complejos.

Riesgos comunes:
- Errores de estimación (tiempo, costo)
- Riesgos asociados a los usuarios
- Riesgos asociados al líder del proyecto
- Control de calidad
- Riesgos con la tecnología seleccionada
- Selección equipo de trabajo
QUE
METODOLOGÍA
TRADICIONAL
ELEGIR?
METODOLOGÍAS ÁGILES
 METODOLOGÍAS ÁGILES

Conceptos clave y términos que son utilizados en Ágil:

El Equipo Ágil y roles de un Equipo Ágil:
❖ Historias de usuarios
❖ Maestro Scrum
❖ Puntos de la historia
❖ Propietario del Producto
❖ Pila de productos
❖ Equipo de desarrollo
❖ Sprint
❖ Producto Mínimo Viable (PMV)
METODOLOGÍAS ÁGILES

Las más utilizadas:

- Scrum
- Kanban
- Lean
- XP
Técnicas dirigidas a la gestión de proyectos -> contraposición a los métodos clásicos de gestión.
Cumplen con el Manifiesto ágil: serie de principios agrupados en tres valores:
CICLO DE VIDA DEL DESARROLLO DE SOFTWARE DEPENDIENDO DE LA METODOLOGÍA

Mitos que rodean a Ágil:

○ Es anti-documentación.
○ Es anti-planeación.
○ Es indisciplinada.
○ Es anti-arquitectura.
○ No se escala.
○ Es solo para proyectos TI.
METODOLOGÍAS ÁGILES
 METODOLOGÍA ÁGIL: SCRUM

Diseñado para facilitar el desarrollo ágil de un proyecto.

Se basa en una filosofía colaborativa y en dividir el trabajo en ciclos

temporales. Contiene tres roles principales:

Product Owner:

Es el responsable del proyecto.

Elabora la lista de funciones a realizar, indicando las prioridades

(Product Backlog).
METODOLOGÍA ÁGIL: SCRUM
 METODOLOGÍA ÁGIL: SCRUM

ScrumMaster: Es el «facilitador» o «moderador».

Elimina los inconvenientes que obstaculizan alcanzar

los objetivos, fomentando la autoorganización del
equipo, asegurándose que el proceso scrum funciona
correctamente.

Trabaja junto al Product Owner y el equipo de

desarrollo y actúa de moderador en las reuniones.
METODOLOGÍA ÁGIL: SCRUM
METODOLOGÍA ÁGIL: SCRUM

Equipo de Desarrollo:

Responsable de la entrega del producto.

Está compuesto por un grupo de profesionales

multidisciplinar capacitado para realizar el proyecto.

Trabajan en equipo, mediante la autoorganización,

construyendo el producto de forma incremental, a partir
de ciclos temporales cortos llamados Sprints.
CICLO DE VIDA DEL DESARROLLO DE SOFTWARE DEPENDIENDO DE LA METODOLOGÍA

Reuniones
➢ Sprint planning
➢ Daily meetings - daily scrum
➢ Sprint review
➢ Retrospective
➢ Grooming
METODOLOGÍA ÁGIL: SCRUM

SPRINT PLANNING MEETING

El primer día tiene lugar la reunión de planificación del Sprint,
con dos objetivos principales:

Seleccionar los requisitos: El Product Owner presenta

la lista de requisitos a realizar, indicando las prioridades. Se
resuelven dudas y el equipo selecciona los requisitos que se
incluirán en el Sprint.

Planificar el Sprint: El equipo realiza una lista de tareas

para llevar a cabo durante el Sprint. Los miembros del equipo
se autoorganizan para asignarse las tareas, según sus
habilidades, y complementandose con trabajo en equipo.
METODOLOGÍA ÁGIL: SCRUM

FASES AL INTERIOR DE CADA SPRINT

METODOLOGÍA ÁGIL: SCRUM

DAILY SCRUM
Cada día, el equipo realiza una reunión de sincronización de
unos 15 minutos en la que ponen en común el trabajo realizado,
el progreso del Sprint y si existen obstáculos que estén
ralentizando las tareas. En esta reunión, cada miembro del
equipo responde a tres preguntas:

● ¿Qué has hecho desde la última reunión?

● ¿Qué harás hoy?
● ¿Qué impedimentos tienes para realizar el trabajo y
qué ayudas necesitas?

El Scrum Master actúa como moderador durante estas

reuniones.
METODOLOGÍA ÁGIL: SCRUM

SCRUM REVIEW
- Revisa los resultados obtenidos respecto al
objetivo de la iteración, problemas
identificados y cómo se resolvieron.
- Es más relevante conseguir el Sprint Goal que
completar todos los PBIs (Product Backlog Items)
que se seleccionaron para el Sprint
- Presenta al cliente los requisitos completados en
forma de incremento de producto.
- Utilizar los PBIs y sus criterios de aceptación
(definidos en el PBL Refinement).
- Se explica si hubo algún PBIs que no se pudo
completar y si hay algún impedimento al respecto.
METODOLOGÍA ÁGIL: SCRUM

SCRUM RETROSPECTIVE
Es una oportunidad para que el Equipo se inspeccione a sí
mismo y cree un plan para implementar mejoras durante el
próximo Sprint .

Esta es una reunión de tres horas como máximo para Sprints

de un mes. Para Sprints más cortos, el evento suele ser más
corto. Durante la Retrospectiva del Sprint, el equipo analiza:

● Que salió bien en el Sprint

● Que se puede mejorar
● ¿En qué nos comprometemos a mejorar en el
próximo Sprint?
METODOLOGÍA ÁGIL: SCRUM

SCRUM GROOMING
El refinamiento del Product Backlog es una práctica
recomendada.

Esta ceremonia sigue un patrón similar al resto y tiene una

agenda fija específica en cada Sprint.

Se estima su duración en 2 horas máximo por semana del

Sprint. Es responsabilidad del product owner agendar,
gestionar y dirigir esta reunión.

● Es necesario que antes de la reunión todos conozcan los

requerimientos o historias de usuario que van a ser
tratados en la misma.
METODOLOGÍA ÁGIL: KANBAN

Objetivo: mejorar la eficiencia y productividad del equipo.

Su principal característica consiste en visualizar el flujo de

trabajo y tenerlo siempre visible para todos los miembros del
equipo, con el fin de:

- comprobar cómo avanza el trabajo

- realizar los cambios que sean necesarios para mejorar la
eficiencia
- evitar repeticiones de tareas
- evitar que alguna tarea se quede sin realizar.

La forma más común para mostrar el flujo de trabajo es mediante

columnas. De esta forma, se establecen los diferentes estados
del proceso de trabajo, representados en cada columna.
CICLO DE VIDA DEL DESARROLLO DE SOFTWARE: METODOLOGÍAS HIBRIDAS
EJEMPLOS DE METODOLOGÍAS HÍBRIDAS
<ACTIVIDAD POR PROPUESTA PROYECTOS>
Entregas: II SPRINT PRIMER MES DE TRABAJO

1. Elegir la metodología de desarrollo de software a utilizar en sus proyecto. Recomendaciones:

a. Si está trabajando en parejas: Metodología ICONIX
b. Si está trabajando en grupos de 3 personas: SCRUM
c. Si se encuentra trabajando de forma individual, recomiendo formar parte de algún equipo.
2. Grupo que seleccionó metodología SCRUM:
a. Identificar cada rol en el equipo de trabajo (Product Owner, Scrum Master, Developer Team
b. Especificar las historias de usuario del proyecto. Ver tutorial:
https://www.youtube.com/watch?v=FJuq_lrM5Cc
c. Formar la pila de productos https://www.youtube.com/watch?v=JuIVHk1wvcw
d. Realizar la planeación del primer sprint (duración de los sprint: 2 semanas - google meet)
3. Grupo que seleccionó metodología ICONIX:
http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesICONIX.pdf
a. Realizar diagramas de casos de uso y tablas descriptivas de cada uno de ellos.
b. Diagrama de robustez
c. Diagrama de secuencia