Introducción a la

Ingeniería de Software
(parte 2)

Profesora Nicole Piña Russel / npinar@apolinav.cl

Contenido
 Definición, características y conceptos generales de la Ingeniería de Software.

 Crisis y mitos del software.

 Principios de la ingeniería de software.

 Proceso software.

 Modelos de proceso de software.

 Metodología de desarrollo ágil.

U.T. N°1 Introducción a la Ingeniería de Software

 Proceso de software

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Desarrollo de Software

El desarrollo de un sistema de Software esta delimitado por los recursos, el

tiempo y un conjunto de requerimientos.

Para lograrlo debe existir:

Recursos

Tiempo
 Planeación y seguimiento del plan.
 Conformada por actividades, recursos y
tiempo. Requerimientos

 Las actividades se llevan a cabo dentro de un

proceso definido.

U.T. N°1 Introducción a la Ingeniería de Software Sistema

Proceso de Software
El proceso de software
“Un proceso define quien hace qué, cuándo y cómo, para alcanzar cierto
objetivo”
(Ivar Jacobson, Grady Booch y James Rumbaugh)

En la ingeniería de software, el proceso de software es un enfoque adaptable que

permite que el equipo de software busquen y elijan el conjunto apropiado de acciones y
tareas para el trabajo. De modo que se logre entregar un software de forma oportuna y
con calidad suficiente para satisfacer a los dueños y usuarios del sistema.

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Ciclo de vida (Proceso de desarrollo de SW)

“Una aproximación lógica a la adquisición, el suministro, el desarrollo, la

explotación y el mantenimiento del software”
(IEEE 1074)

“Un marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, la explotación y el mantenimiento de un producto
de software, abarcando la vida del sistema desde la definición de los requisitos
hasta la finalización de su uso”
(ISO 12207)

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Ciclo de vida (Proceso de desarrollo de SW)

Implícita o Explícitamente todos los modelos del ciclo de vida de Software,

cuentan por lo menos con las siguientes fases:

Análisis Diseño Implementación Pruebas Mantenimiento

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Análisis (Requerimientos)

 Fase en que se establece qué servicios se requieren del sistema y cuáles son
las restricciones de operación y desarrollo del mismo.

 Etapas de la Ingeniería de Requisitos:

 Estudio de viabilidad.
 Obtención y análisis de requisitos.
 Especificación de requisitos: los del usuario y los del sistema.
 Validación de requisitos.

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Análisis (Requerimientos)

Reporte de
Estudio de viabilidad
viabilidad

Obtención y Modelos de
análisis de sistema
requisitos

Requerimientos
Especificación del usuario
de requisitos y del sistema

Validación de
requisitos Documento
U.T. N°1 Introducción a la Ingeniería de Software
Requerimientos
Proceso de Software
Diseño e implementación

 Etapa en la que se convierte la especificación del sistema en un

sistema ejecutable.

 Diseño del software

 Describir la estructura del Software, los datos, las interfaces entre
componentes, etc.

 Implementación
 Transforma la estructura anterior en un programa ejecutable.

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Diseño e implementación
Especificación
requerimientos

Diseño
Diseño Diseño de Diseño
Abstracción estructura
Arquitectónico Interfaz algoritmo
datos

Arquitectura Especificación Especificación Especificación Especificación

del Sistema Software Interfaz componentes algoritmo

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Pruebas (Validación del Software)

 La verificación y validación pretenden demostrar que un

sistema es conforme con su especificación y que resuelve
los requisitos del cliente.

 La prueba del sistema implica ejecutar el sistema con los

casos de prueba que se obtuvieron en la especificación.

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Pruebas (Validación del Software)

Especificación Especificación Diseño del Detalle del

Requerimientos del Sistema Sistema diseño

Prueba de
Plan de prueba Plan de prueba Plan de prueba unidades y
de aceptación de sistema De subsistema
módulos

Prueba de Prueba del Prueba de

Servicio
aceptación sistema subsistemas
U.T. N°1 Introducción a la Ingeniería de Software
Proceso de Software
Mantenimiento

 El software es intrínsecamente flexible y puede cambiar.

 De la misma forma que los requisitos cambian según

cambian las circunstancias del negocio, el software que da
soporte al negocio debe también desarrollarse y cambiar.

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Mantenimiento

Definición Evaluar el Proponer

Modificar
Requerimiento sistema cambios en el
sistemas
del Sistema existente sistema

Sistemas Sistema
existentes nuevo

U.T. N°1 Introducción a la Ingeniería de Software

Proceso de Software
Ciclo de vida (Proceso de desarrollo de SW)

 No existe una única forma de organizar las fases del ciclo de vida del
software.

 La forma más natural de organizar las fases, seria de manera secuencial según
ocurren en el tiempo, pero esto se ha demostrado que no es realista por la
naturaleza evolutiva del software.

 Las diferentes maneras de de representar las fases de un ciclo de vida, se

le denomina modelo de ciclo vida o modelo de proceso.

U.T. N°1 Introducción a la Ingeniería de Software

 Modelos de Proceso de software

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software
Clasificación de los modelos de proceso

 Modelos tradicionales: Formados por un conjunto de fases o actividades en las que no

tienen en cuenta la naturaleza evolutiva del software.
 Cascada, Estructurado, Prototipo, Desarrollo rápido de aplicaciones (RAD).

 Modelos evolutivos: Son modelos que se adaptan a la evolución que sufren los
requisitos del sistema en función del tiempo.
 Incremental (Desarrollo iterativo y creciente), Espiral.

 Modelos para sistemas orientados a objetos: Modelos con un alto grado de iteración y
solapamiento entre fases
 De agrupación, Proceso Unificado.

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software
Clasificación de los modelos de proceso

 Modelos basados en reutilización: Tienen en cuenta la reutilización sistemática del

software
 Basado en componentes, Proceso Unificado.

 Procesos ágiles: Enfatizan el desarrollo rápido, ponen el énfasis en la programación

 Programación Extrema (XP), Scrum, Desarrollo de software adaptativo, Crystal.

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software (Modelos tradicionales)
Modelo lineal secuencial (Cascada)
Análisis  Propuesto por Winston W. Royce en
1970 y posteriormente revisado por
Barry Boehm en 1980 y Ian Sommerville
en 1985.
Diseño

 Conocido también como ciclo de vida

Implementación lineal o básico.

Pruebas

Mantenimiento

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software (Modelos tradicionales)
Modelo lineal secuencial (Cascada)

Características:

 Cada fase empieza cuando se ha terminado la fase anterior.

 Para pasar de una fase a otra es necesario conseguir todos los objetivos de
la etapa previa.
 Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes
esperados.
 Al final de cada fase el personal técnico y los usuarios tienen la
oportunidad de revisar el progreso del proyecto.

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software (Modelos tradicionales)
Modelo lineal secuencial (Cascada)
Ventajas
 Debido a la estructura lógica del modelo, a menudo
se puede evitar errores conceptuales.
 Es un modelo fácil de implementar y entender.
 Está orientado a documentos, lo que es un alivio
para los nuevos programadores y desarrolladores,
siendo de gran utilidad en la fase de pruebas.
 Es un modelo conocido y utilizado con frecuencia.
 Promueve una metodología de trabajo efectiva:
Definir antes que diseñar, diseñar antes que
codificar.
U.T. N°1 Introducción a la Ingeniería de Software
Desventajas
 Se tarda mucho tiempo en pasar por todo el ciclo.
 Las revisiones de proyectos de gran complejidad son
muy difíciles
 Una etapa determinada del proyecto no se puede
llevar a cabo a menos de que se haya culminado la
etapa anterior.
 Se convierten las especificaciones en
implementaciones de manera informal.
 Cualquier error de diseño detectado en la etapa de
prueba conduce necesariamente al rediseño del
sistema, aumentando los costos de desarrollo.
 Impone una estructura de gestión de proyectos.
Modelos de proceso de software (Modelos tradicionales)
Modelo de prototipos

 Propuesto por Frederick Brooks

en 1975.

 El modelado se centra en la
representación de aquellos
aspectos del software que serán
visibles para los usuarios finales

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software (Modelos tradicionales)
Modelo de prototipos
Características:

 Reduce el riesgo de construir productos que no satisfagan las necesidades de los

usuarios.
 Reduce costos y aumenta la probabilidad de éxito.
 Exige disponer de las herramientas adecuadas.
 No presenta calidad ni robustez.

Suele utilizarse principalmente en dos áreas:

 Prototipo de la interfaz de usuario.
 Prototipo del rendimiento.

El “prototipo” es un medio excelente para recoger retroalimentación del usuario

final.
U.T. N°1 Introducción a la Ingeniería de Software
Modelos de proceso de software (Modelos tradicionales)
Modelo de prototipos
Ventajas
 Ofrece un mejor enfoque cuando el responsable del
desarrollo del software está inseguro de la eficacia de
un algoritmo, de la adaptabilidad de un sistema
operativo o de la forma que debería tomar la
interacción humano-máquina.
 Este modelo es útil cuando el cliente conoce los
objetivos generales para el software, pero no
identifica los requisitos detallados de entrada,
procesamiento o salida.
 Reduce costo y aumenta la probabilidad de éxito.
Desventajas
 Debido a que el usuario ve que el prototipo funciona
piensa que este es el producto terminado y no
entienden que recién se va a desarrollar el software.
 El desarrollador puede caer en la tentación de
ampliar el prototipo para construir el sistema final sin
tener en cuenta los compromisos de calidad y de
mantenimiento que tiene con el cliente

 Exige disponer de las herramientas adecuadas.

 Reduce el riesgo de construir productos que no

satisfagan las necesidades de los usuarios. Clave: Definir reglas del
 No modifica el flujo del ciclo de vida. juego entre desarrollados y
cliente

U.T. N°1 Introducción a la Ingeniería de Software

 Modelos de proceso de software (Modelos tradicionales)
Modelo RAD (Rapid application development)
Equipo n°3
Equipo n°1 Equipo n°2
Modelo de
gestión

Modelo de
Modelo de gestión Modelo de
gestión datos

Modelo de
datos
Modelo de
procesos  Propuesto por James Martin
Modelo de Generación
en 1991.
datos Modelo de
de
aplicación
procesos
Prueba y

Modelo de Generación
entrega
 Enfatiza un ciclo de
procesos
de
aplicación
desarrollo extremadamente
corto (funcional entre 60 o
Prueba y 90 días).
Generación entrega
de
aplicación

Prueba y
entrega

60-90 días
U.T. N°1 Introducción a la Ingeniería de Software
Modelos de proceso de software (Modelos tradicionales)
Modelo RAD (Rapid application development)

Características

 Modelo secuencial: Separación en fases de cada caja de tiempo

 Integraciones constantes
 Centrado en el código más que en la documentación
 Desarrollo basado en componentes
 Uso efectivo de herramientas y frameworks
 Participación activa del usuario

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software (Modelos tradicionales)
Modelo RAD (Rapid application development)

Ventajas Desventajas
 Es muy rápido.  Requiere clientes y desarrolladores comprometidos en
las rápidas actividades necesarias para completar un
sistema en un marco de tiempo abreviado. Si no hay
compromiso, por ninguna de las partes constituyentes,
el proyecto fracasará.
 Permite trabajar en él varías  No es recomendado para sistemas grandes que no se
personas a la vez. pueden modularizar adecuadamente.
 No es adecuado cuando los riesgos técnicos son altos
(Ej: uso de tecnologías nuevas).

U.T. N°1 Introducción a la Ingeniería de Software

 Modelos de proceso de software (Modelos evolutivo)
Modelo incremental (Desarrollo iterativo y
creciente)

Entrega del 3°
Incremento 3 Análisis Diseño Implementación Pruebas Mantenimiento
incremento
Funcionalidad

Incremento 2 Análisis Diseño Implementación Pruebas Mantenimiento Entrega del 2°

incremento

Incremento 1 Análisis Diseño Implementación Pruebas Mantenimiento

Entrega del 1°
incremento

U.T. N°1 Introducción a la Ingeniería de Software

Tiempo
Modelos de proceso de software (Modelos evolutivo)
Modelo incremental (Desarrollo iterativo y
creciente)
 Propuesto por Harlan Mills en el año 1980.
 Es el modelo de desarrollo de software creado en respuesta a las debilidades del
modelo cascada.

Características:

 Corrige la necesidad de una secuencia no lineal de pasos de desarrollo.

 El sistema se crea añadiendo componentes funcionales al sistema  incrementos
 El sistema no se ve como una entidad monolítica con una fecha fija de entrega, sino
que es una integración de resultados sucesivos obtenidos después de cada iteración.
 Se ajusta a entornos de alta incertidumbre.
U.T. N°1 Introducción a la Ingeniería de Software
Modelos de proceso de software (Modelos evolutivo)
Modelo incremental (Desarrollo iterativo y
creciente)
Ventajas
 Se evitan proyectos largos y se entrega
“algo de valor” a los usuarios con cierta
frecuencia.
 El usuario se involucra más.
 El usuario puede utilizar los incrementos
iniciales como prototipo.
 Se empieza el desarrollo por las
funcionalidades de mayor prioridad.
 Permite separar la complejidad del
proyecto, gracias a su desarrollo por parte
de cada iteración.
U.T. N°1 Introducción a la Ingeniería de Software
Desventajas
 La entrega temprana de los proyectos
produce la creación de sistemas demasiados
simples que a veces se ven un poco
monótonos a los ojos del usuario que lo
recibe.
 Difícil de evaluar el coste total.
 Difícil de aplicar a sistemas transaccionales
que tienden a ser integrados y a operar
como un todo.
 Los errores en los requisitos se detectan
tarde y su corrección resulta costosa.
Modelos de proceso de software (Modelos evolutivo)
Modelo incremental (Desarrollo iterativo y
creciente)
Desventajas desde la perspectiva administrativa:

 El proceso no es visible. Si los sistemas se desarrollan rápidamente, resulta poco

efectivo en términos de costos producir documentos que reflejen cada versión del
sistema.
 La estructura del sistema tiende a degradarse conforme se tienen nuevos
incrementos. A menos que se gaste tiempo y dinero en la refactorización para mejorar
el software, el cambio regular tiende a corromper su estructura.

Estas desventajas son visibles principalmente en sistemas grandes, complejos y de larga

duración. Es esencial una definición de un marzo o arquitectura estable, definición
clara de responsabilidades dentro del equipo de desarrollo, lo anterior es prioritario
antes de tomar la decisión de realizar un desarrollo de manera incremental.

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software (Modelos evolutivo)
Modelo en Espiral

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software (Modelos evolutivo)
Modelo en Espiral
 Propuesto por Barry Boehm en el año 1986.
 Combina la naturaleza de construcción de prototipos con los aspectos controlados y
sistemáticos del modelo lineal secuencial.

 El software se desarrolla en una serie de versiones incrementales.

 Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un
prototipo.
 Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema
diseñado.

 Cada ciclo empieza identificando:

 Los objetivos de la porción correspondiente
 Las alternativas
 Restricciones
U.T. N°1 Introducción a la Ingeniería de Software
Modelos de proceso de software (Modelos evolutivo)
Modelo en Espiral
 Se evalúan las alternativas respecto a los objetivos y las restricciones.
 Se formula una estrategia efectiva para resolver las fuentes de riesgos (simulación, prototipos,
etc.).
 Se plantea el próximo prototipo.
 Una vez resueltos los riesgos se sigue el ciclo en cascada.
 Cada ciclo se completa con una revisión que incluye todo el ciclo anterior y el plan para el
siguiente.

Características:

 Permite acomodar otros modelos.

 Incorpora objetivos de calidad y gestión de riesgos.
 Elimina errores y alternativas no atractivas al comienzo.
 Permite iteraciones, vuelta atrás y finalizaciones rápidas.
 Es difícil de adaptar a los contratos.
U.T. N°1 Introducción a la Ingeniería de Software
Modelos de proceso de software (Modelos evolutivo)
Modelo en Espiral
Ventajas Desventajas
 El análisis del riesgo se hace de forma  Genera mucho tiempo en el desarrollo del
explícita y clara. sistema.
 Une los mejores elementos de otros  Requiere experiencia en la identificación de
modelos. riesgos.
 Reduce riesgos del proyecto.  La planificación es costosa debido a la
incertidumbre en la cantidad de iteraciones
necesarias.
 Incorpora objetivos de calidad.  Modelo costoso.
 Integra el desarrollo con el mantenimiento,
etc.
 Añade la posibilidad de tener en cuenta
mejoras y nuevos requerimientos sin romper
con la metodología, ya que este ciclo de
vida no es rígido ni estático.

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software (Modelos de sistemas orientados a objetos y
reutilización)
Proceso Unificado
 Fue propuesto en 1999 por
Ivar Jacobson, Grady Booch y
James Rymbaugh.
 No es simplemente un
proceso, sino un marco de
trabajo extensible que puede
ser adaptado a
organizaciones o proyectos
específicos.
 El refinamiento más
conocido y documentado es
el Proceso Unificado de
Rational (RUP).

U.T. N°1 Introducción a la Ingeniería de Software

Modelos de proceso de software (Modelos de sistemas orientados a objetos y
reutilización)
Proceso Unificado
Características:

 Iterativo e Incremental.
 Se compone de las fases: Inicio, Elaboración, Construcción y Transición. Cada fase esta dividida en una
serie de iteraciones y cada iteración esta dividida por las fases de ciclo de vida de software.

 Dirigido por los casos de uso (UML).

 Los casos de uso son utilizados para capturar requisitos funcionales y definir las iteraciones.

 Centrado en la arquitectura
 Asume que no existe un modelo único que cubra todos los aspectos del sistema.

 Enfocado en los riesgos.

 Requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa
temprana del ciclo de vida.

U.T. N°1 Introducción a la Ingeniería de Software

 Modelos de proceso de software (Modelos de sistemas orientados a objetos y
reutilización)
Proceso Unificado: Fases Tiene como principal finalidad
completar el análisis de los casos
de uso y definir la arquitectura
Se define el negocio: del sistema.
factibilidad de realizar el
proyecto, modelo, visión,
metas, plazos, costos, etc.

Está compuesta por un ciclo de varias

iteraciones, en las cuales se van incorporando
sucesivamente los casos de uso, de acuerdo a
los factores de riesgo del proyecto.
Se vigila el uso que se da al
software, se brinda apoyo
para el ambiente de
operación y se reportan Se da el software a los usuarios finales para las
defectos y solicitudes de pruebas beta, quienes reportan tanto los
cambio para su evaluación defectos como los cambios necesarios. Además,
el equipo de software genera la información de
apoyo necesaria que se requiere para el
U.T. N°1 Introducción a la Ingeniería de Software lanzamiento.
Modelos de proceso de software (Modelos de sistemas orientados a objetos y
reutilización)
Proceso Unificado
Ventaja Desventaja
 Coste de riesgo a un solo  Requiere costos de dedicación
incremento. altos, por lo que no es
conveniente usarlo en procesos
pequeños.
 Reduce el riesgo de no sacar el  Si el proceso no se inicia bien
producto en el calendario desde el principio, se puede volver
previsto. muy grande y difícil.
 Acelera el ritmo de desarrollo.  Se basa mucho en la
documentación.
 Se adapta mejor a la necesidades  Proceso pesado.
del cliente.
 Seguimiento detallado en casa una  La evaluación de los riesgos es
de las fases. compleja
U.T. N°1 Introducción a la Ingeniería de Software
 Metodología de desarrollo ágil

U.T. N°1 Introducción a la Ingeniería de Software

Metodología de desarrollo ágil
Desarrollo ágil
 Simplifican la complejidad de otras metodologías haciendo que la carga de gestión
y control sea más liviana.

 Características:
 Menor énfasis en el análisis, diseño y documentación
 Equipos pequeños
 Desarrollo incremental
 Programación (planificación temporal) en cajas de tiempo
 Supervivencia en un entorno caótico

 Diversos enfoques:
 XP (eXtreme Programming)
 SCRUM

U.T. N°1 Introducción a la Ingeniería de Software

Metodología de desarrollo ágil
Manifiesto ágil
El 17 de febrero de 2001, diecisiete experto en desarrollo de software se reunieron para tratar sobre técnicas y proceso de
desarrollo de software. En la reunión acuñaron el término “Métodos Ágiles” para definir los modelos de trabajo que estaban
surgiendo como alternativa a las metodologías previas.

Se creó entonces la Agile Alliance, una organización sin ánimo de lucro dedicada a promover el desarrollo ágil de software.
Para lograrlo, el primer paso que dieron fue redactar el Manifiesto Ágil, un documento que resume los principios de la filosofía
ágil.

Valores:

1. Individuos e interacciones sobre procesos y herramientas.

2. ‘Software’ funcionando sobre documentación exhaustiva.
3. Colaboración con el cliente sobre negociación contractual.
4. Respuesta ante el cambio sobre seguir un plan.

U.T. N°1 Introducción a la Ingeniería de Software

Metodología de desarrollo ágil
Manifiesto ágil

Principios:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana
durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno
y el apoyo que necesitan, y confiarles la ejecución del trabajo.

U.T. N°1 Introducción a la Ingeniería de Software

Metodología de desarrollo ágil
Manifiesto ágil

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y

entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de
forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.

U.T. N°1 Introducción a la Ingeniería de Software

Metodología de desarrollo ágil
Principios de los métodos ágiles
Participación del • Deben intervenir estrechamente durante el proceso de desarrollo.

cliente • Deben ofrecer y priorizar nuevos requerimientos del sistema.

Entrega • El software se desarrolla en incrementos.

• El cliente especifica los requerimientos que se van a incluir en los
incremental incrementos.

Personas, no • Tienen que reconocerse y aprovecharse las habilidades del equipo de

desarrollo.

procesos • Debe permitirse a los miembros del equipo desarrollar sus propias
formas de trabajar sin procesos establecidos.

Adoptar el cambio • Esperar a que cambien los requerimientos del sistema, y de este modo,
diseñar el sistema para adaptar dichos cambios.

Mantener • Enfocar la simplicidad tanto en desarrollo como en el proceso del

software.

simplicidad • Siempre que sea posible, trabajar de manera activa para eliminar la
complejidad del sistema.

U.T. N°1 Introducción a la Ingeniería de Software

 Metodología de desarrollo ágil
XP (eXtreme Programming)
 Propuesto por Kent Beck en 1999.
 Pone énfasis en la adaptabilidad
Historias de usuario Planificación que en la previsibilidad.
 Tendencia a los sencillo:
Diseño simple
 Si una funcionalidad no se solicita
Prototipos formalmente, no se implementa.

 Se debe evitar repetir tareas.

Lanzamiento Pruebas Diseño
 Roles:
 Cliente, prioriza la
funcionalidades. Escribe las
historias de usuario
 Desarrollador, implementa y
Codificación planifica.
Pruebas Unitarias
Pruebas de Programación en parejas
Integración
aceptación  Tester, interpreta al cliente y
Continua
ayuda al desarrollador con la
creación de pruebas.
Rediseño
 Coach, ayudante externo, quien
guía al equipo a seguir los procesos
correctamente.
U.T. N°1 Introducción a la Ingeniería de Software
 Director, mediador entre cliente y
desarrolladores.
 Metodología de desarrollo ágil
Valores de XP
XP (eXtreme Programming)
 Enfoque de desarrollo de software basado en el modelo incremental
 Está indicado para: Comunicación

 Equipos de tamaño mediano o pequeño

 Requisitos imprecisos y cambiantes

 Características
 Desarrollo iterativo e incremental.
Coraje Simplicidad Respeto

 Programación en parejas.
 Pruebas unitarias continuas.
 Corrección periódica de errores.
 Integración del equipo de programación con el cliente. Retroalimentación

 Simplicidad, propiedad del código compartida y refactorización del código.

U.T. N°1 Introducción a la Ingeniería de Software
Metodología de desarrollo ágil
XP (eXtreme Programming)
Ventajas
 Pensado para desarrollos en que la idea del
producto no esta totalmente definida.
 Fomenta la comunicación entre los clientes
y los desarrolladores.
 Desarrollo rápido.
 Mejora continua de los procesos y el equipo
de desarrollo.
U.T. N°1 Introducción a la Ingeniería de Software
Desventajas
 Dificultad para documentar.
 Es recomendable emplear XP solo en
proyectos a corto plazo y simples.
 Fuerte dependencia de los involucrados en
el proyecto.
 Posibles “roces” con el cliente, por
desconocimientos en materia técnica que
causan demora en la toma de decisiones o
por proponer cambios de requerimientos
que no son posibles o poco viables.
 Metodología de desarrollo ágil
SCRUM
Portavoz del cliente.
Responsable de
gestionar backlog.
U.T. N°1 Introducción a la Ingeniería de Software
Líder al servicio del equipo.
Es un facilitador de
reuniones, eliminación de
impedimentos, etc.
Equipo de 3 a 9 miembros.
El equipo es auto-  Es un marco de trabajo centrado en el
organizado y flujo de trabajo.
multidisciplinario. Ejecuta
las tareas acordadas en el  Definido por Ken Schwaber y Jeff
Sprint Sutherland en la década de los 90.
 Sirve para que equipos
multidisciplinarios trabajen en entornos
complejos, donde los requisitos son
cambiantes y los resultados se tienen
que obtener en un corto plazo.
 Roles:
 Product Owner (Propietario del
producto).
 Scrum Master (Facilitador).
 Team (Desarrolladores).
 Metodología de desarrollo ágil
SCRUM

 Características:
 Desarrollo incremental de los requisitos del proyecto, en bloques temporales cortos y fijos.
 Se prioriza lo que tiene más valor para el cliente.
 Solapa las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo
secuencial o en cascada.
 Reuniones cortas diarias.
 Fijar tiempos máximos para cumplir los objetivos.
 Equipos auto-dirigidos y auto-organizados.

U.T. N°1 Introducción a la Ingeniería de Software

 Metodología de desarrollo ágil
SCRUM
 Artefactos:
 Product Backlog
 Listado de todas las tareas que se pretender hacer durante el desarrollo del proyecto.
 Registra y prioriza requisitos (historias de usuario) desde el punto de vista del cliente.
 Debe ser visible para todos.
 Se puede gestionar mediante un “Tablero Scrum”.

 Sprint Backlog
 Registro de requisitos desde el punto de vista del los desarrolladores. Es la lista de tareas a realiza durante el
Sprint.

 Incremento
 Resultado del Sprint.

U.T. N°1 Introducción a la Ingeniería de Software

 Metodología de desarrollo ágil
SCRUM Valores de SCRUM

 Flujo de trabajo:
 Sprint
 Periodo en que se lleva a cabo el desarrollo. Compromiso

 El tiempo es definido por el equipo, según su propia experiencia (entre 2 a 4 semanas).

 Planificación de Sprint
 Es al inicio de un Sprint.
 Tiene como objetivo definir si es factible realizar el trabajo en el Sprint. Respeto Coraje

 Scrum diario
 Reunión diaria, de 5 a 10 min, para ver el estado del proyecto. SCRUM
 Tiene como objetivo mantener a los miembros del equipo actualizados.
 Revisión Sprint
 Al final de un Sprint.
 Es una reunión, en donde se presenta los trabajos completados. Apertura Enfoque
 Retrospectiva del Sprint
 Al final de un Sprint.
 Cada miembro del equipo deja sus impresiones del Sprint superado, con el fin de realizar una mejora continua
de los procesos.

U.T. N°1 Introducción a la Ingeniería de Software

Metodología de desarrollo ágil
SCRUM
Ventajas
 Flexibilidad a cambios.
 Cliente puede utilizar las
funcionalidades más importantes antes
de que el proyecto este terminado.
 Mayor productividad, por la reducción
de tramites burocráticos y mayor
motivación en el equipo por el hecho
de que pueden estructurarse de
manera autónoma.
 Facilidad para la estimación de
tiempos.
 Reducción de riesgos.
U.T. N°1 Introducción a la Ingeniería de Software
Desventajas
 No es conveniente para proyectos con
muchas dependencias externas.
 Es de suma importancia que todo el
equipo conozca y domine los principios
del marco de trabajo de Scrum.
 Depende mucho de la preparación y
experiencia del Scrum Master.
 Puede llegar a ser difícil el manejo de
proyectos muy complejos o proyectos
muy grandes heredados.
Metodología de desarrollo ágil
Tablero Scrum
 Es un tablero que permite el seguimiento de tareas en cada Sprint.
 Es una herramienta de planificación, que permite identificar que se hacer y organizar al equipo.
 El tablero le pertenece al equipo, orientado por el Scrum Master.
 El Product Owner no debe interferir en el tablero, solo el equipo puede modificarlo.
 Las tareas del tablero deben ser definidas en la Planificación de Sprint.

U.T. N°1 Introducción a la Ingeniería de Software

 Metodología de desarrollo ágil
Kanban
 Su origen datan de los años 40 por la empresa Toyota, fue introducido para el desarrollo de
software el 2004 por David Anderson.
 Es un método de gestión de trabajo de un proyecto, centrado en el flujo de trabajo.
 Se puede aplicar a cualquier otro modelo de desarrollo.

 Practicas
 Visualizar y mostrar el proceso
 Mostrar el proceso de desarrollo a través de un tablero público para todos los involucrados.

 Limitar el trabajo en curso (WIP).

 Acordar en cada proceso la cantidad de tareas que se puede abordar.

 Los límites son para detectar cuellos de botella.

 Optimizar el flujo de trabajo

U.T. N°1 Introducción a la Ingeniería de Software

Metodología de desarrollo ágil
Kanban

 Principios
 Comenzar por lo que se va a hacer ahora
 Se puede comenzar aplicando en las funciones y procesos actuales y estimular cambios continuos, incrementales y evolutivos
en un sistema nuevo o existente.

 Acordar en buscar la mejora a través del cambio incremental y evolutivo.

 Respetar el proceso actual, los roles, las responsabilidades y los cargos.

 Liderazgo en todos los niveles

 El liderazgo no está relegado a unos pocos elegidos, todo lo contrario. Se debe alentar hechos de liderazgo en todos los niveles
de la organización.

U.T. N°1 Introducción a la Ingeniería de Software

Metodología de desarrollo ágil
Kanban

Ventajas Desventajas
 Flexibilidad  Difícil de utilizar en proyectos nuevos
muy grandes y con tiempos muy
definidos.
 Fácil de visualizar estado actual del  Un tablero obsoleto, puede generar
proyecto. problemas en el proceso de desarrollo.

 Permite controlar de flujo de trabajo.  No hay control en los tiempos

dedicados.
 Puede ser utilizado en un proyecto
nuevo como uno ya existente.

U.T. N°1 Introducción a la Ingeniería de Software

Metodología de desarrollo ágil
Scrum vs Kanban

Scrum Kanban
Cadencia Sprints periódicos de duración Flujo continuo
fija (de 2 a 4 semanas)
Entregas Al final de cada Sprints Entrega continua

Roles Producto Owner, Scrum Master, No hay roles obligatorios.

Team Algunos equipos requieren un
“entrenador ágil”.
Cambio Los equipos no deben hacer El cambio puede producirse en
cambios durante el Sprint cualquier momento.

 Scrumban es la metodología que une a Scrum y Kanban.

U.T. N°1 Introducción a la Ingeniería de Software

 ¿Preguntas?

U.T. N°1 Introducción a la Ingeniería de Software

Bibliografía

 Ingeniería de Software, Somerville, Capitulo 2 y 3.

 Ingeniería de Software. Un enfoque practico. Pressman. Capitulo 2.
 http://agilemanifesto.org/iso/es/manifesto.html
 https://www.agilealliance.org/
 https://www.atlassian.com/es/agile

U.T. N°1 Introducción a la Ingeniería de Software