UNIVERSIDAD NACIONAL DE INGENIERIA

INSTITUTO DE ESTUDIOS SUPERIORES

Carrera: Ingeniería en Computación

Asignatura: Ingeniería de Software 1

Fecha: 22/08/2022

CONTENIDOS A DESARROLLAR:

UNIDAD I: INTRODUCCION A LA INGENIERIA DEL SOFTWARE

1.6 Evolución en la práctica de la Ingeniería del Software.
Metodologías Agiles

Objetivos del Tema:

• Exponer aspectos esenciales de la práctica de la Ing del Sw

• Identificar algunas metodologías agiles para el desarrollo del software.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Recordemos un poco lo que hemos visto hasta ahora :

El ciclo de vida del desarrollo Software

(SDLC en sus siglas inglesas), es una
secuencia estructurada y bien definida
de las etapas en Ingeniería de software
para desarrollar el producto software
deseado. El SDLC aporta una serie de
pasos a seguir con la finalidad de
diseñar y desarrollar un producto
software de manera eficiente.

El Paradigma de desarrollo de Software ayuda al desarrollador a escoger una

estrategia para desarrollar el software. El paradigma de desarrollo software tiene
su propio set de herramientas, métodos y procedimientos, los cuales son
expresados de forma clara, y define el ciclo de vida del desarrollo del software.

INGENERIA DE SOFTWARE 1- HMSJ 1

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

El modelo de cascada es el
modelo de paradigma más
simple en desarrollo de
software. Sigue un modelo
en que las fases del SDLC
funcionarán una detrás de la
otra de forma lineal. Lo que
significa que solamente
cuando la primera fase se
termina se puede empezar
con la segunda, y así
progresivamente.

La naturaleza secuencial del modelo no permite volver atrás y deshacer o volver

a hacer acciones. Este modelo es recomendable cuando el desarrollador ya ha
diseñado y desarrollado softwares similares con anterioridad, y por eso está al
tanto de todos sus dominios.

El modelo en espiral es
una combinación de un
ciclo clásico pero
repetitivo, es un
proceso cíclico.

Este modelo considera

el riesgo, factor que
otros modelos olvidan o
no prestan atención en
el proceso. El modelo
empieza determinando
los objetivos y las
limitaciones del
software al inicio de
cada repetición. En la
siguiente etapa se
crean los modelos de
prototipo del software.
Esto incluye el análisis
de riesgos.

INGENERIA DE SOFTWARE 1- HMSJ 2

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

Para el Modelo de cascada, el

mayor inconveniente es que
solo se pasa a la siguiente
fase cuando se completa la
anterior, por tanto, no es
posible volver atrás si se
encuentra algún error en las
etapas posteriores. El Modelo
V aporta opciones de
evaluación del software en
cada etapa de manera
inversa. En cada etapa, se
crea la planificación de las
pruebas y los casos de
pruebas para verificar y
validar el producto según los
requisitos de la etapa.

Esto hace que tanto la verificación como la validación vayan en paralelo. Este
modelo también se conoce como modelo de validación y verificación.

La Practica de la Ingenieria del Software

En las clases anteriores hemos hablado que un modelo general del proceso de creacion de un software
está compuesto de un conjunto de actividades que establecen la estructura para la practica de la
Ingenieria del Software. Estas actividades estructurales generales eran : comunicación, planeacion,
modelado, contruccion y despliegue, acompañadas con las actividades “sombrilla” y que establecen
el esqueleto de la arquitectura para el trabajo de la Ingenieria del Software (IS).
Vamos a tratar de comprender de manera básica algunos conceptos y principios generales que se
aplican en estas actividades estructurales para la practica de la I.S.

La esencia de la practica

INGENERIA DE SOFTWARE 1- HMSJ 3

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

INGENERIA DE SOFTWARE 1- HMSJ 4

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES
A).-Principios en la Practica de la Ing Sw:

1.- La razon de que exista todo=> Agregar solo lo que le de valor al sistema, recordemos que el
sistema existe por una razon: dar valor a los usuarios.
2.- Mantenlo sencillo=> todo diseño debe ser tan simple como sea posible, de manera que permita
una comprension facil y sencilla para su mantenimiento. Recordemos que “Simple” no significa
“rápido y sucio”
3.-Mantener la vision=> Debemos mantener la arquitectura del sistema acorde con una vision clara
de los objetivos del mismo.
4.- Otros consumiran lo que usted produce => Alguien mas que no es usted, lo va a usar, mantener,
documentar, o quizas diseñar o implementar, y tienen que entender todo lo que usted hizo.
5.- Abrase al futuro=> un Sistema de Informacion con larga vida útil, tiene mas valor. Deben ser fácil
de adaptarse a los cambios.
6.- Planee por anticipado la reutilizacion (de código) => Esto le ahorra tiempo y esfuerzo.
7.- Piense => Pensar en TODO con claridad antes de emprender la acción para obtener mejores
resultados.

B).- Mitos del Software

Los mitos son creencias erróneas, aunque parezcan enunciados razonables de hechos que a veces
contienen elementos de verdad

Relacionado a la Administracion del Proyecto

Mito: si nos atrasamos podemos agregar mas programadores y ponernos al corriente
Mito: si subcontrato a un tercero para elaborar el SI puedo descansar

INGENERIA DE SOFTWARE 1- HMSJ 5

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES
Relacionados al cliente
Mito: para escribir programas es suficiente con el enunciado general de los objetivos, para entrar en
detalles lo vemos mas adelante en el transcurso del proyecto.
Mito: Los requerimientos del Sw cambian continuamente , pero este cambio lo asimilamos con
facilidad debido a que el Sw es flexible.

Relacionados con el profesional de la IS

Mito: una vez que hemos escrito el SI y funciona, nuestro trabajo ha terminado (60-80% del trabajo
verdaderamente inicia cuando se le entrega al cliente)
Mito: hasta que no corre el SI no hay manera de que se pueda evaluar su calidad.
Mito: El unico producto que se entrega al finalizar un proyecto es el SI funcionando.
Mito: La IS va a generarnos mucha documentacion voluminosa e innecesaria y nos va a retrasar.

C).-Comprension de los Requerimientos

Hemos planteado que las actividades estructurales generales son : comunicación, planeacion,
modelado, construccion y despliegue. En esencia esto es:
• Enteder el problema (comunicación y analisis)
• Planear la solucion (modelado y diseño del Sw)
• Ejecutar el plan (generacion del codigo)
• Revisar la exactitud del resultado (probar y asegurar la calidad)

En entender el problema => participantes, despejar incognitas, fraccionar el problema (Divide y

venceras), representarlo graficamente (crear un modelo de analisis).

Analizaremos los siguientes aspectos que nos permiten enteder el problema (comunicación y analisis
del mismo) :
• Principios de la ingenieria de requerimientos. (indagacion, elaboracion, negociacion,
especificacion, validacion, Administracion de los requerimientos)
• El establecimiento de las bases (particpantes, puntos de vista, trabajo colaborativo, preguntas
iniciales)
• Indagacion de los requerimientos
• Validacion de los requerimientos
• Analisis de los requerimientos

INGENERIA DE SOFTWARE 1- HMSJ 6

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES
Conclusiones.

Actividades de estudio independiente:

1.- Explique qué entiende por requerimientos del sistema y como considera que puede recabarlos?

Fecha de revision: 29/08/2022.

INGENERIA DE SOFTWARE 1- HMSJ 7

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

METODOLOGIAS AGILES

La metodología ágil no hace referencia a

una serie de indicaciones sobre qué hacer
exactamente durante el desarrollo de
software. Se trata más bien de una forma
de pensar en la colaboración y los flujos
de trabajo, y define un conjunto de valores
que guían nuestras decisiones con
respecto a lo que hacemos y a la manera
en que lo hacemos.

En concreto, las metodologías ágiles de

desarrollo de software buscan
proporcionar en poco tiempo pequeñas
piezas de software en funcionamiento
para aumentar la satisfacción del cliente.
Estas metodologías utilizan enfoques flexibles y el trabajo en equipo para ofrecer mejoras
constantes

¿Qué es scrum?

Scrum es un marco que permite el trabajo colaborativo entre equipos. Scrum anima a los
equipos a aprender a través de las experiencias, a autoorganizarse mientras aborda un
problema y a reflexionar sobre sus victorias y derrotas para mejorar continuamente.

Aunque son los equipos de desarrollo de software los que utilizan con mayor frecuencia este
tipo de scrum, sus principios y lecciones se pueden aplicar a todo tipo de trabajo en equipo.
Esta es una de las razones por las que es tan popular. Se considera a menudo un marco de

INGENERIA DE SOFTWARE 1- HMSJ 8

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

gestión de proyectos ágil, incluye un conjunto de reuniones, herramientas y funciones que,

de forma coordinada, ayudan a los equipos a estructurar y gestionar su trabajo.

marco de trabajo solo existe como un todo

Usa enfoque iterativo Equipos flexibles y adaptativo

/incremental (equipo pequeño de personas)

Teoría de control de procesos Reglas:

Empírica (empirismo) -Equipos y roles
-Eventos
-Artefactos

EQUIPO Y ROLES

• Responsable de gestionar los elementos de

la lista de producto. (Product Backlog)
• Discute el objetivo que el Sprint debe lograr
• Solo el puede cancelar el Sprint (objetivo
obsoleto)

INGENERIA DE SOFTWARE 1- HMSJ 9

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

• Tamaño de 3 – 9 personas.
• Entregan productos de forma iterativa e
incremental
• Están diseñados para optimizar la
flexibilidad, creatividad y la productividad.
• Auto- organizados
• Multifuncionales
• No reconoce títulos de sus miembros
• No hay sub equipos
• Responsabilidad de todo el equipo (como un todo)

• Da servicio a la organización
• Responsable de promover y apoyar el Scrum
• Ayuda a entender la teoría, practicas, reglas
y valores del Scrum
• Da servicio al dueño del producto
• Da servicio al equipo de desarrollo

EVENTOS DEL SCRUM

Son bloques de tiempo (Time boxes)

• El Sprint
• Planificación del Sprint (Sprint Planning)
• Objetivo del Sprint
• Scrum Diario (Daily scrum)
• Revisión del Sprint (sprint review)
• Retrospectiva de Sprint

INGENERIA DE SOFTWARE 1- HMSJ 10

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

El Sprint

• Tiene una meta, diseño y plan flexible

• Es el corazón del Scrum
• Bloque de tiempo (2 – 4 semanas)
• Planificación del Sprint
• Scrum diarios
• Trabajo de desarrollo
• Revisión del Sprint (reunión interna del equipo)
• Retrospectiva del Sprint

La planificación del Sprint

La planificación de sprints es un evento en scrum que inicia el sprint. El objetivo de la

planificación de sprints es definir lo que se puede entregar en el sprint y cómo se
conseguirá ese trabajo. La planificación de sprints se hace en colaboración con todo el
equipo de scrum.

INGENERIA DE SOFTWARE 1- HMSJ 11

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

• Se crea en conjunto todo el equipo scrum completo

• 8 horas para un sprint de un mes
• ¿Qué puede entregarse? -> se define un objetivo del sprint a través de la lista de
productos (Sprint Goal)
• ¿Cómo se conseguirá hacer el trabajo necesario para entregarlo?-> la lista de
pendientes del Sprint: elementos de la lista de productos + plan para terminarlos
(Sprint BackLog)

Objetivo del Sprint

INGENERIA DE SOFTWARE 1- HMSJ 12

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

Se crea durante la planificación del sprint

Es la meta establecida mediante la implementación de la Lista de Producto.

Scrum Diario

• Es una reunión interna del equipo de

desarrollo

• Se lleva a cabo cada día del Sprint

• Duración: 15 minutos. Misma hora y

lugar.
• Se planea el trabajo para las

siguientes 24 hrs
• Se evalúa el progreso hacia el objetivo

del sprint y qué tendencia sigue este

progreso hacia la finalización del

trabajo contenido en la lista de

pendientes del sprint.

LOS ARTEFACTOS DEL SCRUM

INGENERIA DE SOFTWARE 1- HMSJ 13

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

En el marco de trabajo Scrum, denominamos Artefacto a aquellos elementos físicos que se

producen como resultado de la aplicación de Scrum. Los tres principales artefactos o
herramientas Scrum son: el Product Backlog, Sprint Backlog y el Incremento.

La Lista de producto (Product Backlog)

• Es dinámica, nunca está

completa, va
evolucionando.
• El dueño del producto
es el único responsable.
Es la fuente de los
requisitos
• Incluye contenido,
disponibilidad y orden
• Enumera características,
funcionalidades,
requisitos, mejoras y
correcciones.

Es una lista con todos los requerimientos iniciales del producto que se va a desarrollar. Se trata de
una lista dinámica, que irá evolucionando a medida que lo hace el producto y el entorno del
proyecto.

Es una lista ordenada por prioridad de todas las funcionalidades que pueden ser necesarias para
incorporar al producto. Tendremos ahí todos los requisitos del proyecto y de esa lista tomaremos
un subconjunto para los requisitos que implementaremos en un Sprint. Ese subconjunto de tareas
es la que compondrá la Lista del Sprint.

Lista de Pendientes (Sprint Backlog)

• Es el conjunto de elementos de la Lista de Producto seleccionados para el Sprint, más un

plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint.

• Es una actividad del equipo de trabajo.

Identifica lo necesario para alcanzar el objetivo
del sprint. Si se requiere nuevo trabajo, se
adiciona a esta lista.
• Hace un seguimiento del progreso del sprint
(en el scrum diario)

INGENERIA DE SOFTWARE 1- HMSJ 14

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

Incremento

El Incremento en Scrum es la suma de todos los elementos del Product Backlog completados
durante el Sprint presente y el valor de los incrementos de todos los Sprints anteriores. Por tanto,
es un paso más hacia la realización del Product Goal u Objetivo de Producto.

El nuevo incremento debe estar “terminado”, es inspeccionarle y esta en condiciones de utilizarse

(aunque vaya o no a ser liberado por el Product Owner)

El Product Owner es quien debe asegurarse de que el producto vaya aumentando su valor en cada
nuevo Sprint. El incremento de valor Scrum debe verificarse minuciosamente para
garantizar que todos los incrementos funcionen juntos.

INGENERIA DE SOFTWARE 1- HMSJ 15

 UNIVERSIDAD NACIONAL DE INGENIERIA
INSTITUTO DE ESTUDIOS SUPERIORES

INGENERIA DE SOFTWARE 1- HMSJ 16