IIS Unidad 2 Modelos de proceso del software

Introducción a la Ingeniería de Software Carrera de Software
Ph.D. Franklin Parrales 1
22/10/2021
Modelos de proceso del
software
Unidad 2
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Introducción a la Ingeniería de Software

22/10/2021
Objetivo general de la Unidad 2
Identificar el ciclo de vida del software a través de
los estándares IEEE para diferenciar los modelos
de desarrollo de software

22/10/2021
3
En el desarrollo de software nos
encontramos con la siguiente situación
Ciclos de
Vida del
SOFTWARE
Metodologías de
Desarrollo del
SOFTWARE

22/10/2021
Contenido
• Proceso del software
• El ciclo de vida del Software
• Modelos de desarrollo: tradicionales vs
alternativos

22/10/2021
Contenido
– Definición de proceso de software
– Estándares relacionados con el proceso
software: IEEE/EIA (ISO/IEC) 12207,
SWEBOK, CMMI, PMBOK
alternativos

22/10/2021
¿Que queremos decir con proceso de software?
Deseos,
necesidades,
Especificaciones,
…
Software

22/10/2021
¿Qué es el proceso del software?
• Proceso seguido por una organización para el
desarrollo del software
• Este proceso incluye todas las fases del ciclo de
vida clásico
• Este proceso se define de manera general para
todas las aplicaciones de una organización
• Igualmente se definen tareas especificas a cada
aplicación en particular
• No existe un proceso de software universal. Las
características de cada proyecto (equipo de
desarrollo, recursos, etc.) exigen que el proceso
sea configurable

22/10/2021
Definición del proceso de software
• Proceso: colección de actividades de trabajo, acciones y
tareas que se realizan cuando va a crearse algún producto
terminado.
– Cada una de las actividades, acciones y tareas se encuentra
dentro de una estructura o modelo que define su relación tanto
con el proceso como entre sí.
• Propósito del proceso de desarrollo de Software
– La producción eficaz y eficiente de un producto software que
reúna los requisitos del cliente.
– Este proceso es intensamente intelectual, afectado por la
creatividad y juicio de las personas involucradas.
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software

22/10/2021
Características de un proceso de
desarrollo de software
• Proporciona pautas para el
desarrollo eficiente de
software de calidad.
• Reduce el riesgo y aumenta la
previsibilidad
• Promueve una visión y una
cultura comunes
• Presenta las mejores
prácticas actuales

22/10/2021
¿Qué es un proceso de desarrollo de software?
Define
• Quién va a hacer qué
• Cuándo hacerlo, y
• Cómo alcanzar un objetivo determinado
Proceso de desarrollo de software
Requisitos nuevos o modificados
Sistema nuevo o modificado

22/10/2021
Elementos del proceso de desarrollo
▪ Quién: Las Personas participantes que
desempeñan uno o más Roles específicos.
▪ Qué: Un Artefacto es producido por un Rol en una
de sus Actividades. Estos se especifican utilizando
Notaciones específicas. Las Herramientas apoyan
la elaboración de los Artefactos.
▪ Cómo y Cuándo: Las Actividades son una serie
de pasos que lleva a cabo un Rol durante el
proceso de desarrollo. El avance del proyecto está
controlado mediante hitos que establecen un
determinado estado de terminación de ciertos
Artefactos.

22/10/2021
Contenido
– Definición de proceso de software
– Estándares relacionados con el proceso
software: IEEE/EIA (ISO/IEC) 12207,
SWEBOK, CMMI, PMBOK
alternativos

22/10/2021
Procesos Primarios del Ciclo de Vida
Adquisición
Mantenimiento
Operación
Desarrollo
Suministro
Procesos de Soporte al Ciclo de Vida
Documentación
Gestión de la Configuración
Aseguramiento de la Calidad
Verificación
Validación
Revisión Conjunta
Auditoría
Resolución de Problemas
Procesos Organizacionales del Ciclo de Vida
Administración/Gestión Infrastructura
Mejoramiento Capacitación
IEEE/EIA 12207
Software Life Cycle Processes

22/10/2021
SWEBOK Guide = 10 Knowledge Areas
Mapped TO ISO/IEC 12207:1995 processes
Calidad de Software
Herramientas y Métodos de la Ingeniería de Software
Proceso de Ingeniería de Software
Administración/Gestión del Software
Gestión de la Configuración del Software
Mantenimiento
Prueba
Construcción
Diseño
Requerimientos
Procesos
primarios
Procesos de Soporte

22/10/2021
Guide to the Software Engineering Body of Knowledge
2004 Version
Software
Construction
Software
Maintenance
Software Testing
Basic Concepts
of Construction
Managing
Construction
Software
Maintenance
Fundamentals
Key Issues in
Software
Maintenance
Techniques for
Maintenance
Sofware
Testing
Fundamentals
Test Levels
Test Techniques
Test Related
Measures
Test
Process
Software Design
Software Design
Fundamentals
Key Issues in
Software Design
Software Structure
and Architecture
Software Design
Quality Analysis
and Evaluation
Software Design
Notations
Software
Requirements
Software
Requirements
Fundamentals
Requirements
Process
Requirements
Elicitation
Requirements
Specification
Requirements
Validation
Requirements
Analysis
Software Design
Strategies and
Methods
Practical
Considerations
Practical
Considerations
Maintenance
Process

22/10/2021
Slide 16 of 146
CMMI Staged Representation - 5 Niveles de Madurez
Nivel 5
Inicial
Nivel 1
Los procesos son impredecibles, mal controlados, reactivos.
Repetible
Nivel 2
Los procesos se planifican, documentan, ejecutan,
supervisan y controlan a nivel de proyecto. Suele ser
reactivo (aparecen los problemas y se solucionan)
Definido
Nivel 3 Los procesos están bien caracterizados y
comprendidos. Los procesos, estándares,
procedimientos, herramientas, etc. se definen a nivel
organizacional (Organización X). Proactivo (se
identifican problemas potenciales y como mitigarlos)
Gestionado
Nivel 4
Los procesos se controlan mediante
técnicas estadísticas y otras técnicas
cuantitativas.
Optimizado
El rendimiento del proceso se
mejora continuamente a través
de mejoras tecnológicas
incrementales e innovadoras.

22/10/2021
Maturity Level Project Managment Engineering Process Management Support
5
Optimizing
Organizational Innovation & Deployment Causal Analysis & Resolution
4
Quantitatively
Managed
Quantitative Project Mngt Organizational Process Performance
3
Defined
Integrated Project Mngt
Risk Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Decision Analysis & Resolution
2
Managed
Project Planning
Project Monitoring & Control
Supplier Agreement Mngt
Requirements Mngt Measurement & Analysis
Process & Product Quality Assurance
Configuration Mngt
1
Initial
CMMI Process Areas

22/10/2021
PMIBOK
Representative
Software
development
Life
Cycle
Prueba
Evaluación
Evaluación
Análisis
de riesgo
Modelo 1
Modelo 2
Modelo 3
Requerimiento
negocio
Requerimientos
sistema
Diseño
conceptual
Diseño
lógico
Diseño
físico
Diseño
final
Requerimientos
subsistemas
Requerimientos
de la unidad
Entregar
Operación y
mantenimiento
Evaluar
Construir Diseñar
Identificar
Modelo 4

22/10/2021
Overlap of Process Groups in a Phase
(PMBOK® Guide, 2000, p. 31)

22/10/2021
Relationships Among Process Groups and
Knowledge Areas (PMBOK® Guide 2000, p. 38)

22/10/2021
Relationships
Among
Process
Groups
and
Knowledge
Areas
(PMBOK®
Guide
2000,
p.
38)

22/10/2021
PMBOK

22/10/2021
Exposiciones

22/10/2021
Contenido
alternativos

22/10/2021
Contenido
– Definición y etapas
– Ámbito general de: Requerimientos, análisis,
diseño y pruebas de software
alternativos

22/10/2021
Ciclo de Vida del Software
• Consiste en determinar:
– las fases productivas de un proyecto,
– los objetivos de cada fase productiva, y
– los productos obtenidos en cada una de estas
fases así como sus características.

22/10/2021
Ciclo de vida de un proyecto de Software
Gestión y
recursos
Inicio Terminación
Fase
inicial
Fase
final
Fase
implementación
La producción del sistema da inicio, se
concluyen las instalaciones y se estabiliza el
sistema. Se desarrollan las actividades
rutinarias de operación y mantenimiento
En la fase inicial se efectúa la identificación
de necesidades, problema u oportunidad.
Requiere de documentar y armar un
preproyecto. Se efectúan los análisis de
soluciones y se desarrolla un requerimiento
de cotización.
Se efectúan los análisis de propuestas,
diseño detallado, las negociaciones
convenientes y se da la contratación
Se inician los preparativos y la recepción de
la solución, se capacita al personal, se
efectúan pruebas piloto y pruebas de
aceptación
tiempo

22/10/2021
Fases de un proyecto de tecnología
100 %
Porcentaje
de
avance
Factibilidad
• Formulación de proyecto
• Estudio de factibilidad
• Diseño de estrategia
• Protocolo de aprobación
Planeación y diseño
• Plan de actividades
• Costo y programa de
implementación
• Términos contractuales
y condiciones
• Planeación detallada
Implementación
• Preparación
• Entrega
• Instalación
• Pruebas
Producción
• Afinación
• Mantenimiento
Puesta a punto
de operación
Contratación
Aprobación
Plena
disponibilidad
Preproyecto
Cierre

22/10/2021
Contenido
– Definición y etapas
– Ámbito general de: Requerimientos, análisis,
diseño y pruebas de software
alternativos

22/10/2021
Ingeniería de requerimientos
el cliente y los desarrolladores
definen el propósito y objetivos
del sistema
resultado: descripción del
sistema en términos de
participantes (actores) y
funciones (casos de uso)
actores: entidades externas
que interactúan con el
sistema (incluyen roles como
usuarios finales u otros
sistemas con los que
interactúa el sistema)
casos de uso: secuencias de
eventos que describen todas
las acciones posibles entre un
actor y el sistema para una
función específica.
se acuerdan requisitos no
funcionales. Por ejemplo:
el distribuidor de billetes
debe estar disponible al
menos un 95% del tiempo
el distribuidor de billetes
debe dar respuesta en menos
de un segundo después de
seleccionada la transacción
Nombre del caso de uso: CompraBillete
Actor participante: Iniciado por Viajero
Precondición:
1. El Viajero se para frente al distribuidor automático de billetes
Flujo de eventos:
2. El Viajero selecciona las estaciones de origen y destino
3. El DistribuidorDeBilletes muestra el precio del billete
4. El Viajero inserta una cantidad de dinero que, al menos, debe
ser igual que el precio del billete
5. El DistribuidorDeBilletes emite el billete especificado al Viajero y
devuelve el cambio si es necesario
Postcondición:
6. El Viajero coge el billete y el cambio
Requisitos especiales:
Si la transacción no ser termina después de un minuto de
inactividad, el DistribuidorDeBilletes devuelve todo el dinero
insertado
ReservaBilletes
CompraBillete
Viajero
Anulación reserva

22/10/2021
Análisis
• Se produce un modelo correcto, completo, consistente, claro,
realista y verificable
• Transformación de los casos de uso en un modelo que
describe por completo el sistema y que se usará en el diseño
• Descubrimiento y resolución con el cliente de ambigüedades
e inconsistencias en el modelo de casos de uso
Transacción
Moneda
BilleteTren
Zona
da como resultado
válido para
Saldo
cantidad pagada
Papel

22/10/2021
Diseño
• diseño del sistema
– definición de los objetivos de diseño
– descomposición del sistema en subsistemas
abordables por equipos
– selección de estrategias para la construcción
(plataformas hardware y software, almacenamiento
de datos persistentes, control de acceso,...)
– resultado: descripción de las estrategias,
descomposición en subsistema
• diseño de objetos:
– definición de objetos e interfaces de subsistemas,
reestructuración del modelo de objetos para lograr
los objetivos de diseño, optimización del modelo
para mejorar el rendimiento,...
– resultado: modelo de objetos detallado
• actividades del diseño
– diseño arquitectónico
– especificación de los subsistemas
– diseño de interfaz
– diseño de componentes
– diseño de la estructura de datos
– diseño procedimental (algoritmos)
Comprador
IU Solicitud
de pago
Gestor de
pedidos
Confirmación
de pedidos
Planificador
de pagos
Solicitud
de pago
Procesamiento de
solicitudes de pago
Procesamiento
de facturas
Factura
Gestión facturas
comprador
Gestión de planificación
de pagos
Gestión de
cuentas

22/10/2021
Validación
Usuarios
<<subsystem>>
Gestión Máquinas
Subgrupo
<<subsystem>>
Gestión
Subgrupos-Instalaciones
<<subsystem>>
Gestión Sistema
<<subsystem>>
Gestión
Instalaciones
<<subsystem>>
Mantenimientos
de Gestión
<<subsystem>>
Gestión Mantenimiento
Correctivo
<<subsystem>>
Gestión Trabajos
Externos
<<subsystem>>
Preventivo
<<subsystem>>

22/10/2021
Validación
Usuarios
<<subsystem>>
Gestión Máquinas
Subgrupo
<<subsystem>>
Gestión
Subgrupos-Instalaciones
<<subsystem>>
Gestión Sistema
<<subsystem>>
Gestión
Instalaciones
<<subsystem>>
Mantenimientos
de Gestión
<<subsystem>>
Correctivo
<<subsystem>>
Gestión Trabajos
Externos
<<subsystem>>
Preventivo
<<subsystem>>
Gestión
Máquinas
<<subsystem>>
Gestión Características
Máquinas
Gestión Tareas
Máquinas
Alta Instalaciones
Baja Instalaciones
Modificación Instalaciones
Operario
(from Validación Usuarios)
Administrador
Validar Usuario
<<include>>
<<include>>
<<include>>
Consulta Instalaciones
<<include>>
Alta Características-Maq
Baja Características-Maq
Modificación Características-Maq
Operario
Administrador
Validar Usuario
<<include>>
<<include>>
<<include>>
Consulta Características-Maq
<<include>>

22/10/2021
Operario
Administrador
Validar Usuario
<<include>>
<<include>>
<<include>>
<<include>>
Nombre Alta Características Máquina
Prioridad Media
Actor Administrador
Extends Ninguno
Includes Validar Usuario
Pre-Condiciones 1. El usuario está identificado.
2. El usuario selecciona la opción de altas en el
formulario.
Post-Condiciones 1. Los datos de la nueva característica quedan
guardados si el proceso finaliza correctamente.
2. Los datos de la nueva característica no quedan
guardados si se produce algún error durante el
proceso.
Descripción 1. El sistema muestra el formulario de altas.
2. El usuario introduce los datos.
3. El sistema realiza la validación de los datos.
4. Si la característica ya existe [A].
5. Si los datos no son correctos [B].
6. El usuario selecciona la opción de Guardar.
7. El sistema guarda los datos.
8. Si se guarda correctamente se visualiza un mensaje,
si hay algún problema el sistema avisa con un
mensaje de error.
Excepciones El proceso se puede cancelar en cualquier momento.
A. Si la característica ya existe se visualizan sus datos.
B. Datos incorrectos, ir a punto 2.
MENSAJES
: Administrador Opciones Frm
Cliente
CTRL Alta
Instalación
Form_Alta Validar Datos
INSTALACION
Resultado Alta
Visualizar Mensaje
Seleccionar
Crea()
Mostrar(Datos)
Introducir Datos()
Cubrir_Datos()
Comprobar()
Comprobar()
Obtener Datos
Crear_Alta()
Construir
Construir
Visualizar Resultado
Crea()
Si no Existe
Fin Si
Fin Si
Datos Correctos
...
Datos no Correctos
Mostrar

22/10/2021
Operario
Administrador
Validar Usuario
<<include>>
<<include>>
<<include>>
<<include>>
Nombre Alta Características Máquina
Prioridad Media
Actor Administrador
Extends Ninguno
Includes Validar Usuario
Pre-Condiciones 1. El usuario está identificado.
2. El usuario selecciona la opción de altas en el
formulario.
Post-Condiciones 1. Los datos de la nueva característica quedan
guardados si el proceso finaliza correctamente.
2. Los datos de la nueva característica no quedan
guardados si se produce algún error durante el
proceso.
Descripción 1. El sistema muestra el formulario de altas.
2. El usuario introduce los datos.
3. El sistema realiza la validación de los datos.
4. Si la característica ya existe [A].
5. Si los datos no son correctos [B].
6. El usuario selecciona la opción de Guardar.
7. El sistema guarda los datos.
8. Si se guarda correctamente se visualiza un mensaje,
si hay algún problema el sistema avisa con un
mensaje de error.
Excepciones El proceso se puede cancelar en cualquier momento.
A. Si la característica ya existe se visualizan sus datos.
B. Datos incorrectos, ir a punto 2.
Visualizar
Formulario
Comprobar
Datos
Mensaje "Error
Datos"
Comprobar Existencia
de la Instalación
Visualizar Datos
Instalación
Guardar Datos
Instalación
Mensaje
"Error"
Datos Incorrectos
Datos Correctos
Si Existe
Mensaje "Instalación
guardada"
Administrador Validado
Seleccionar
Formulario
Introducir
Datos
Seleccionar
Guardar
No Existe
Error al Guardar
Instalación Guardada
Administrador (from Alta Máquinas)
Sistema (from Validar Usuario)

22/10/2021
Especificacion
DelProducto
descripción
precio
articuloID
CatalogoDe
Productos
1..n
1
Articulo
Encargado
LineaDeVenta
cantidad
1
n
1..n
0..1
Tienda
dirección
nombre
n
1
n
1
Pago
cantidad
Venta
fecha
hora
1
1..n
1
n
1
1
Cliente
1
1
Registro
1..n
1
1
1
1
1
Cajero
1
1
1
1
1
1
1
1
Pagada-mediante
1
1
Iniciada-por Registra-ventas-en
Iniciado-por
1..n
1
Alberga
Abastece
n
1
Capturada-en
1
1
1
n
Registra-completas
Contenida-en
1
1..n Utilizado-por
n
1
1..n
1
Contiene
Descrita-por
1
n
1..n
0..1
Registra-venta-de

22/10/2021
Servidor SGBD
Red Local Impresora
Cliente
Cliente
ODBC
TCP/IP
TCP/IP
TCP/IP

22/10/2021

22/10/2021
Implementación y Pruebas
• Implementación
– traducción del modelo de
diseño (por ejemplo, del
modelo de objetos) en
código fuente
– incluye:
• implementación de
atributos y métodos de
cada objeto
• integración de todos los
objetos para que
funcionen como un solo
sistema
• Pruebas
– pruebas de unidad:
comparación del modelo de
diseño con cada objeto y
subsistema
– pruebas de integración:
combinaciones de
subsistemas y comparación
con el modelo de diseño del
sistema
– pruebas del sistema:
ejecución de casos típicos y
excepcionales, y comparación
con el modelo de
requerimientos
– objetivo: descubrir la mayor
cantidad posible de errores
que se puedan reparar antes
de entregar el sistema

22/10/2021
Mantenimiento
• Mejoras en el sistema (nuevas funciones,
facilidad de uso,...)
• Corrección de errores
• Adaptación a cambios en el entorno
(hardware, software, legislación,...)
• Actividad más costosa del ciclo de vida de
un producto software

22/10/2021
Contenido
alternativos

22/10/2021
Contenido
alternativos
– Concepto de modelo de Desarrollo de software
– Modelos tradicionales: Cascada, prototipo y
espiral.
– Modelos ágiles: Scrum, Xp, Kanban, TDD(Test-
DrivenDesign)

22/10/2021
Introducción a los modelos de desarrollo
• Los estándares establecen los diferentes procesos implicados
a la hora de desarrollar y mantener un sistema desde que
surge la idea o necesidad de desarrollar las aplicaciones
hasta que éstas se retiran de explotación.
– Sin embargo, ninguno impone un modelo de procesos concreto
(modelo de ciclo de vida) ni cómo realizar las diferentes actividades
incluidas en cada proceso, por lo que cada empresa deberá utilizar
los métodos, técnicas y herramientas que considere oportuno.
• Por su naturaleza, los modelos son simplificaciones; por lo
tanto, un modelo de procesos del software es una
simplificación o abstracción de un proceso real.
• Podemos definir un modelo de procesos del software como
una representación abstracta de alto nivel de un proceso
software.

22/10/2021
Introducción a los modelos de desarrollo
• Cada modelo es una descripción de un proceso software que
se presenta desde una perspectiva particular.
– Alternativamente, a veces se usan los términos ciclo de
vida y Modelo de ciclo de vida.
• Cada modelo describe una sucesión de fases y un
encadenamiento entre ellas.
– Según las fases y el modo en que se produzca este
encadenamiento, tenemos diferentes modelos de proceso.
• Un modelo es más adecuado que otro para desarrollar un
proyecto dependiendo de un conjunto de características de
éste.
• Existe una gran variedad de modelos diferentes entre los que
tenemos los que se estudiarán en esta unidad.

22/10/2021
Contenido
alternativos
espiral.
DrivenDesign)

22/10/2021
Modelo en cascada
• Conocido también como modelo lineal o clásico
• Versión original se debe a W. W. Royce [Royce, 1970], apareciendo
después numerosos refinamientos
• Características
– Está compuesto por una serie de
fases que se ejecutan
secuencialmente
– Obtención de documentos como
criterio de finalización de fase
• Problemas de la progresión
secuencial
– Desconocimiento de las necesidades
por parte del cliente
– Inestabilidad de los requisitos
– No se ven resultados hasta muy
avanzado el proyecto
– Efecto big bang próximo a la entrega
1

22/10/2021
Modelo en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
Definición de requisitos:
• Las restricciones y metas del sistema se definen a partir de la
interacción con el interesado.
• Se comprende la naturaleza de la aplicación y el dominio de
información, así como su funcionalidad, rendimiento e interconexión
• Se reúnen todos los requisitos que debe cumplir el software

22/10/2021
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
Se concentra en cuatro características básicas:
Estructura de datos
Arquitectura del software
Representaciones de interfaz
Detalle procedimental (algoritmo)
Modelo en cascada

22/10/2021
Modelo en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
• Se llama también Implementación
• Generación de código entendible por la máquina
• Actualmente se investiga mucho sobre la manera
de generar código automáticamente

22/10/2021
Modelo en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
• Proceso de depuración de programas
• Chequear la validez de las sentencias
• Pruebas para detectar errores, asegurando que a
partir de los datos de entrada si se genere la salida
deseada

22/10/2021
Modelo en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
• Corrección de errores no detectados en la etapa de
pruebas
• Posibles mejoras funcionales debidas a nuevos
requerimientos del cliente
• En esta fase se vuelven a aplicar todas las etapas
anteriores sobre el software existente

22/10/2021
Modelo en cascada
Definición
Análisis
Diseño
Desarrollo
Pruebas
Mantenim.
LIMITACIONES
• En la realidad no estrictamente secuencial (se traslapan las
etapas)
• El interesado debería exponer los requisitos en la etapa inicial,
pero en realidad él lo hace a través de todo el proceso y esto
complica las cosas
• La primera versión del software llega al final del proceso, a veces
el afán del cliente hace que la aplicación final no cumpla con los
requerimientos

22/10/2021
Modelo en “V”
• Es una evolución del
anterior. En este, la
verificación se desglosa
en etapas de nivel de
abstracción creciente.
Análisis y
Definición de los
Requerimientos
Diseño de la
Arquitectura del
Sistema
Diseño Detallado Testeo de cada
unidad (unit test)
Instalación,
Operación y
Mantenimiento
Prueba de
Aceptación
Prueba de
Integración
Implementación de
cada unidad
Plan de Pruebas
para Cada Unidad
Plan de Pruebas
de Integración
Plan de Pruebas de
Aceptación
❑ En cada etapa de
diseño se crea un
plan de pruebas,
que es el que guía la
etapa de validación
que le corresponde.

22/10/2021
Modelos Waterfall y “V” en la Práctica
Análisis y
Definición de los
Requerimientos
Diseño de la
Arquitectura del
Sistema
Diseño Detallado
Implementación
Integración y
Verificación
Instalación,
Operación y
Mantenimiento
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Corregir
fallas
Cambiar un
requerimiento
Cambiar un
requerimiento
Cambiar un
requerimiento
Se acumulan correcciones hacia el final,
con la consiguiente incertidumbre
(ej., no se tiene certeza sobre cuánto
falta hacer, porque no se sabe
cuánto van a demandar
los bloques azules)

22/10/2021
Prototipado evolutivo
(ciclo de vida iterativo)
• Enfoque de desarrollo que se utiliza cuando no se conoce
con seguridad lo que se quiere construir
• Se comienza diseñando e implementando las partes más
destacadas del sistema
• La evaluación del prototipo proporciona la realimentación
necesaria para aumentar y refinar el prototipo
• El prototipo evoluciona y se transforma en el sistema final
Concepto
inicial
Diseño e
implementación
del prototipo
inicial
Refinar el prototipo
hasta que sea
aceptable
Completar y
entregar el
prototipo
2

22/10/2021
Modelo Espiral
• Fue propuesto inicialmente por B. Boehm [Boehm, 1986,
1988]
• Utilización de ciclos en lugar de sucesión de actividades.
• Facilita el desarrollo rápido de versiones incrementales
de software.
3

22/10/2021
Modelo Espiral
• Una de las principales ventajas de este modelo de desarrollo
es que considera directamente los riesgos técnicos en
todas las etapas del proyecto, reduciéndolos antes de que se
conviertan en problemáticos. Además, este modelo puede
adaptarse y aplicarse a lo largo de la vida del software.
• Los procesos que se llevan a cabo dentro de un modelo en
espiral son los siguientes:
– Comunicación con el cliente : Tareas para dinamizar la
interacción desarrollador – cliente.
– Planificación : Definición de recursos, tiempo y otra información
relacionada con el proyecto.
– Análisis de Riesgos : Evaluación de riesgos técnicos y de gestión.
– Ingeniería : Construcción de una o más representaciones de la
aplicación.
– Construcción y Adaptación : Tareas de construcción, pruebas e
instalación de la aplicación.
– Evaluación del Cliente : Reacción del cliente frente a la aplicación
obtenida a partir de la fase de ingeniería y de construcción.

22/10/2021
Contenido
alternativos
espiral.
DrivenDesign)

22/10/2021
Métodos Ágiles
• Surgen como una reacción frente a las
metodologías tradicionales
– Frente a la idea de que el desarrollo de
software es consistente, fiable, predecible y
medible
– Aceptar que no siempre es así y encontrar la
mejor manera de aceptar los cambios
• No proponen nuevas técnicas, sólo una
forma distinta de afrontar el desarrollo de
software

22/10/2021
Manifiesto Ágil
• Firmado por los principales críticos de las
metodologías tradicionales (y creadores de
algunos de los métodos ágiles más populares)
• 4 valores básicos:
– Individuos y su interacción frente a procesos y
herramientas
– Software que funciona frente a documentación
exhaustiva
– Colaboración con el cliente frente a contratos
– Respuesta al cambio frente a seguimiento de un plan

22/10/2021
Manifiesto Ágil: 12 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.

22/10/2021
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.
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.

22/10/2021
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.

22/10/2021
SCRUM (Ken Schwaber)
• Basado en el método de desarrollo de
Nonaka y Takeuchi
• El nombre se refiere a una práctica del rugby
en la que un balón que sale fuera se pone en
juego con la colaboración de todo el equipo
• No describe técnicas de desarrollo, sino
relaciones entre los miembros del equipo
• La idea básica es que el desarrollo de
software es tan complejo que es inevitable
que se produzcan cambios durante a lo largo
del proceso.
1

22/10/2021
SCRUM
• Tres fases:
– pre-juego: planificación y arquitectura
– desarrollo (o juego): sprints
– post-juego: lanzamiento
• Roles principales:
– Scrum Master
– Responsable de producto
– Equipo SCRUM
– Cliente
– Gestores

22/10/2021
SCRUM
• Los principios Scrum son congruentes con el
manifiesto ágil y se utilizan para guiar actividades de
desarrollo dentro de un proceso de análisis que
incorpora las siguientes actividades estructurales:
requerimientos, análisis, diseño, evolución y entrega.
• Dentro de cada actividad estructural, las tareas del
trabajo ocurren con un patrón del proceso llamado
sprint.
• El trabajo realizado dentro de un sprint se adapta al
problema en cuestión y se define —y con frecuencia
se modifica— en tiempo real por parte del equipo
Scrum.

22/10/2021
SCRUM
Desarrollo en sprints (ciclo de trabajo repetitivo)
• Desarrollar: Definición de los cambios necesarios para la
implementación de los requisitos del backlog en módulos, la
apertura de los módulos, análisis del dominio, diseño,
desarrollo, implementación, pruebas y documentación de los
cambios. El Desarrollo consiste en el microproceso de
descubrimiento, invención e implementación.
• Integrar: Cierre de los módulos, creación de una versión
ejecutable con los cambios que implementan los requisitos
del backlog.
• Revisar: Reunión de todos los equipos para presentar el
trabajo y revisar el progreso, identificando y resolviendo
posibles cuestiones y añadiendo nuevos elementos al
backlog. Se revisan los riesgos y las respuestas apropiadas.
• Ajustar: Consolidación de la información de la revisión de los
módulos afectados.

22/10/2021
SCRUM
30 días
SCRUM: reunión diaria de 15 minutos.
Los miembros del equipo responden a
preguntas básicas:
1) ¿Qué hiciste desde la última
reunión Scrum?
2)¿Tienes algún obstáculo?
3)¿Qué harás antes de la próxima
reunión?
Aspectos
con retraso
ampliados
por el
equipo
Al ﬁnal del sprint
se demuestra la
nueva
funcionalidad
Cada
24
horas
Retraso del
sprint:
Característica(s)
asignadas para
el sprint
Retraso del producto
Características del producto
que desea el cliente con
prioridad

22/10/2021
SCRUM
• Retraso: lista de prioridades de los requerimientos o
características del proyecto que dan al cliente un valor
del negocio. Es posible agregar en cualquier momento
otros aspectos al retraso (ésta es la forma en la que
se introducen los cambios). El gerente del proyecto
evalúa el retraso y actualiza las prioridades según se
requiera.
• Sprints: consiste en unidades de trabajo que se
necesitan para alcanzar un requerimiento definido en
el retraso que debe ajustarse en una caja de tiempo14
predefinida (lo común son 30 días). Durante el sprint
no se introducen cambios (por ejemplo, aspectos del
trabajo retrasado). Así, el sprint permite a los
miembros del equipo trabajar en un ambiente de corto
plazo pero estable.

22/10/2021
SCRUM
• Reuniones Scrum: son reuniones breves (de 15 minutos, por
lo general) que el equipo Scrum efectúa a diario. Hay tres
preguntas clave que se pide que respondan todos los
miembros del equipo:
– ¿Qué hiciste desde la última reunión del equipo?
– ¿Qué obstáculos estás encontrando?
– ¿Qué planeas hacer mientras llega la siguiente reunión del
equipo?
• Un líder del equipo, llamado maestro Scrum, dirige la junta y
evalúa las respuestas de cada persona.
– La junta Scrum ayuda al equipo a descubrir los problemas
potenciales tan pronto como sea posible.
– Asimismo, estas juntas diarias llevan a la “socialización del
conocimiento”, con lo que se promueve una estructura de
equipo con organización propia.

22/10/2021
SCRUM
• Demostraciones preliminares: entregar el incremento
de software al cliente de modo que la funcionalidad que
se haya implementado pueda demostrarse al cliente y
éste pueda evaluarla.
• Es importante notar que las demostraciones
preliminares no contienen toda la funcionalidad
planeada, sino que éstas se entregarán dentro de la caja
de tiempo establecida

22/10/2021
Aspectos destacados de SCRUM
• Roles
– Product owner (PO) resposable de describir y priorizar los
requisitos.
– Team responsable de producir un "sprint" encuadrado en el
tiempo (iteración)
– Scrum master (SM) responsable de posibilitar las condiciones
de trabajo en equipo
• Prácticas
– Micro feedback, como reuniones scrum diarias, sprint backlog,
burn-down charts
– Macro feedback y priorización por parte del propietario del
producto en cada sprint,
• Product backlog
• Scrum no prescribe
– Soluciones técnicas, métodos de trabajo, planes de avance del
proyecto
– Estos son responsabilidad del equipo para descubrirlos y
adaptarlos según las necesidades.
• Adecuado para proyectos con objetivos inciertos u objetivos
móviles
– O donde no se conoce del todo el camino para llegar

22/10/2021
Prácticas de Scrum
• Cuadros de tiempo (time boxing)
– El valor incremental de una actividad disminuye con el tiempo.
– Beneficio 80/20 logrado dentro del cuadro de tiempo
• Resultados potencialmente instalables
– Tiempo de iteraciones ("sprints") encuadrado a 30 días (o
menos)
– Cada iteración ofrecerá valor personalizado y calidad de
producción.
• Reducir elaboración inicial (un día)
– Especifique "todos" los requisitos generales para la acumulación
de productos inicial
• Principales casos de uso con escenarios, alt. historias del usuario
• Roles de actores principales
• Priorizar y volver a priorizar
– Solo trabaje en lo que se pueda completar durante el próximo
sprint (iteración)
– Cuadro de tiempo de especificación y planificación: un día

22/10/2021
Concepción Elaboración Construcción Transición
Iteraciones Iter #1 #2 Iter #3 #4 #5 #6 Iter #7 #8
RUP: descripción general
(repaso para comparar con Scrum)
Fases
Disciplinas
Requerimientos
Análisis
Diseño y
Arquitectura
Implementación
Test

22/10/2021
Pre-project
Sprints #1 #2 #3 #4
Scrum - Descripción general
Disciplinas
Sprints
Requisitos
iniciales
Requerimientos
Análisis
Diseño y
Arquitectura
Implementación
Test

22/10/2021
Hitos importantes
• RUP
• Scrum
tiempo
Vision Baseline
Architecture
Initial
Capability
Product
Release
Concepción Elaboración Construcción Transición
2-6 weeks per iteration
~15 %
tiempo
Vision Initial, high-level
Product Backlog
Pre-project
Requirimientos
Iniciales
Sprints
Any number of
potential Product
Releases
1 day 30 days per sprint
Any number of
potential Product
Releases

22/10/2021
eXtreme Programming (Beck)
• El más popular de los métodos ágiles
• Versiones con incrementos muy pequeños
• Evolución constante del código
• 5 valores:
– Simplicidad
– Comunicación
– Retroalimentación
– Coraje
– Respeto
2

22/10/2021
eXtreme Programming
• Simplicidad
– Se simplifica el diseño para agilizar el desarrollo
y facilitar el mantenimiento
– Para mantener la simplicidad es necesaria la
refactorización del código
– Simplicidad en la documentación: el código debe
comentarse en su justa medida
– Autoría colectiva del código y la programación
por parejas
La refactorización de código tiene el objetivo de que los métodos puedan
leerse de la manera más fácil posible.
En el mejor de los casos, los programadores externos que lean el código
deberían poder captar la lógica interna del método.

22/10/2021
eXtreme Programming
• Comunicación
– Para los programadores el código comunica
mejor cuanto más simple sea
– Las pruebas unitarias describen el diseño de
las clases y los métodos al mostrar ejemplos
concretos de cómo utilizar su funcionalidad
– Los programadores se comunican gracias a
la programación por parejas
– La comunicación con el cliente es fluida
porque forma parte del equipo de desarrollo

22/10/2021
eXtreme Programming
• Retroalimentación:
– La opinión del cliente se conoce en tiempo
real porque está integrado en el proyecto
– Los ciclos cortos muestran resultados
rápidamente
– El código y la programación por parejas
también son fuente de retroalimentación

22/10/2021
eXtreme Programming
• Coraje:
– Diseñar y programar para hoy, no para
mañana
– Refactorizar cuando sea necesario
– Desechar código obsoleto o complejo

22/10/2021
eXtreme Programming
• Respeto:
– Propiedad colectiva del código
– Alta calidad

22/10/2021
eXtreme Programming
• 12 reglas
1. El juego de la
planificación
2. Entregas pequeñas
3. Metáfora
4. Diseño simple
5. Pruebas
6. Refactorización
7. Programación en
parejas
8. Integración continua
9. Propiedad colectiva
del código
10. Cliente presente
11. Semanas de 40
horas
12. Espacios comunes

22/10/2021
eXtreme Programming
• Roles
– Programador: código simple, pruebas
– Cliente: historias, pruebas funcionales,
prioridades
– Tester: ayuda con las pruebas, mantiene pruebas
funcionales y analiza resultados
– Tracker: retroalimentación, estimaciones, evalúa
objetivos
– Coach: responsable del proceso
– Consultor: externo, conocimientos técnicos
– Manager: decisiones

22/10/2021
El Equipo XP (Programación Extrema)
• “Clientes”
– Definen el producto
– Incluyen un dueño del producto
• Que es el responsable de la visión del producto
• “Programadores”
– Escriben el código, diseñan la arquitectura, etc.
• Validadores
– “Investigan”, en busca de defectos
– Son “optativos”, porque los clientes y programadores
pueden cumplir sus funciones
• Entrenadores
– Un entrenador de programadores
• Programador experimentado, para atender consultas, liderar en
las decisiones importantes, y evaluar lo que hacen los otros
– Si hace falta, un administrador de proyecto
• No es imprescindible porque el equipo se auto-organiza
• Otros
– Si hacen falta: escritores, analistas ISO 9000, etc.

22/10/2021
Los “Clientes”
• Son los responsables de establecer los
requerimientos del sistema
– Utilizando las estimaciones de costo que les proveen
los “programadores”
• Entre los “clientes” pueden haber:
– Clientes reales de la empresa
– Expertos de dominio (ej., analistas de negocios,
científicos)
– Diseñadores de interfaces al usuario
• Proporción típica: 1 cada 3 programadores
– O los necesarios para mantener ocupados a los
programadores
El Equipo XP

22/10/2021
Plan del Release
• Release es cada “vendible” que se le entrega al
usuario final
• Se aconseja que demore unos tres meses como
máximo
• Empieza con una planificación, a cargo de los
“clientes”
– A cada requisito se le llama historia de usuario
• Ej.: Un usuario que necesita tal cosa, opera el producto de tal
manera, obtiene tal respuesta, etc. Casos puntuales y
concretos.
• …pero dejando los detalles para después
– Los “programadores” los asisten, estimando el esfuerzo (o
sea, tiempo) que demoraría cada historia
• Para que puedan decidir qué dejar para un próximo release
– Obtienen así el release plan
Programación Extrema

22/10/2021
Plan de la Iteración
• El release se divide en iteraciones
– Unas 1 a 3 semanas c/u
– Luego de cada iteración, se tiene un producto
demostrable
• …para ser evaluado por los “clientes” y verificado por los
validadores
• Al principio de cada iteración, los “clientes”
determinan qué historias se van a hacer en ella
– Empezando por las que son clave; la optimización va
al final
– Este plan puede ser modificado en base a las
estimaciones (de costo) de los programadores
• Queda así establecido lo que hace cada equipo
en el resto de la iteración:
– Los “programadores” implementan esas historias
– Los “clientes” seleccionan y detallan las de la próxima
iteración
• …y atienden consultas de los programadores
– O sea que los “clientes” reemplazan la documentación pesada
– Los validadores (si los hay) ponen a prueba los builds
que proveen los “programadores”

22/10/2021
Los “Programadores”
• Codifican en pares (pair programming)
– Habitualmente, en una PC compartida, con teclado y
mouse para c/u, más dos notebooks individuales
• Para averiguar más, googlear “pairing workstation”
– Es una alternativa a la técnica más tradicional:
revisión de código
– El objetivo es lograr un código confiable que pueda
ser comprendido por todos
• Antes de programar cualquier unidad, programan
su código de prueba
– Esto se llama Desarrollo Guíado por Pruebas (Test-
Driven Development, o TDD)
– Para estas pruebas automatizadas utilizan ejemplos
preparados por los “clientes”
– En C, el código de prueba de una unidad puede
consistir de muchas llamadas a ese módulo, con
diferentes parámetros, chequeándose las variables
retornadas
– Como las pruebas se automatizan, los proyectos
necesitan pocos o ningún validador
El Equipo XP

22/10/2021
Otras Técnicas Importantes
• Colaboración
– El ambiente de trabajo debe ser abierto
– …con varios pizarrones para intercambiar ideas
• Sugerencia: Sacarles fotos a los diagramas en el pizarrón
– Todo código es de todos
• Usar un sistema de control de versiones
• Métricas
– Como métrica de progreso del proyecto, se usa la suma del
esfuerzo de las historias ya implementadas y verificadas
• Y como métrica de lo que resta por hacerse, se usa la suma del
esfuerzo de la historias que faltan
– La cantidad de historias a hacer puede ser ajustada, en función
de la velocidad (o sea, progreso / tiempo) que está logrando el
equipo
• Y hay bastantes más prácticas en XP…

22/10/2021
El proceso de la programación extrema
historias del usuario
valores
criterios de pruebas de aceptación
plan de iteración
diseño simple
tarjetas CRC
prueba unitaria
integración continua
incremento de software
velocidad calculada del proyecto
soluciones en punta
prototipos
rediseño
programación por parejas
pruebas de aceptación
Lanzamiento
El diseño XP sigue
rigurosamente el
principio MS (mantenlo
sencillo).
Un diseño sencillo
siempre se prefiere
sobre una
representación más
compleja.
Se desalienta el diseño
de funcionalidad
adicional porque el
desarrollador supone
que se requerirá
después

22/10/2021
El diseño en la programación extrema
• XP estimula el uso de las tarjetas CRC como
un mecanismo eficaz para pensar en el
software en un contexto orientado a objetos.
• Las tarjetas CRC (clase-responsabilidad-
colaborador) identifican y organizan las
clases orientadas a objetos que son
relevantes para el incremento actual de
software.
• Las tarjetas CRC son el único producto del
trabajo de diseño que se genera como parte
del proceso XP.

22/10/2021
Tarjetas CRC
• Clase - el nombre
• Responsabilidades - lo que sabe y lo que hace
• Collaboraciones - quiénes le ayudan
Clase: Model
Colaboradores:
• View
• Controller
Responsabilidad:
• Proporciona el núcleo de funcionalidad
de la aplicación
• Registra los View y Controller
dependientes
• Notifica a los componentes
dependientes acerca de cambios en los
datos

22/10/2021
Tarjetas CRC
• Permiten una rápida visión de los
elementos esenciales de las clases al
encarar la descomposición
• Se usan como técnica de diseño con
participación de usuarios
– Cada uno desempeña el rol de una clase
– Cada uno describe lo que hace al “ejecutar”
un determinado escenario de cierto caso de
uso

22/10/2021
XP: eXtreme Programming
• Ventajas
– No es un producto de Microsoft.
– Es parte de un movimiento llamado “Agile Development”.
– Es una metodología ligera.
– Es una corriente en boga.
– Utiliza un modelo incrementar/Interactivo.
– Trabaja con el cliente en sitio.
– Control de cambios, es incremental.
– Se programa entre dos personas.
– Los requerimientos se construyen a través de experiencias.
– Una buena técnica para un buen desarrollador.
• Desventaja
– No funciona como industria.
– No funciona cuando se trabaja con equipos de trabajo grandes

22/10/2021
Kanban
● Surgió en los años 40
● Sistema de producción de
Toyota
● Producción basada en la
demanda de los clientes.
● Centrada en el Servicio
● Kanban significa tarjeta
con signos o señal visual.
3

22/10/2021
Principios
● A) Comenzar con lo actual El método Kanban se inicia con las
funciones y procesos que ya se tienen y estimula cambios continuos,
incrementales y evolutivos al sistema.
● B) Aplicar cambios incrementales Todos deben estar de acuerdo en
que la manera de hacer mejoras en el sistema es el cambio continuo,
gradual y evolutivo. Los cambios fuertes pueden parecer más eficaces,
pero fracasan más debido a la resistencia y el miedo en la organización.
● C) Respetar lo establecido Para facilitar el cambio futuro conviene
respetar los roles, responsabilidades y cargos actuales, eliminando los
temores iniciales. Esto permite obtener un mayor apoyo a la iniciativa
Kanban.
● D) Liderazgo en todos los niveles Kanban promueve acciones de
liderazgo desde las personas de bajo rango hasta los gerentes.

22/10/2021
Prácticas
1. Visualizar el flujo
de trabajo
2. Eliminar interrupciones. Limitar trabajo
WIP
3. Gestionar el flujo Flujo rápido e ininterrumpido

22/10/2021
Prácticas
4. Hacer las políticas explícitas
○ Fomentar la visibilidad
5. Circuitos de retroalimentación
6. Mejorar colaborando
○ usando modelos y el método científico

22/10/2021
Beneficios
1. Estímulo del rendimiento: Análisis y estimación
para medir el rendimiento. Detección de
problemas y ajuste del trabajo. Flexibilidad.
2. Organización y colaboración: Enfoque visual.
Colaboración en tiempo real. Accesibilidad y
comunicación.
3. Distribución del trabajo: Visión rápida y ahorro de
tiempo. El flujo constante de tareas reduce el
tiempo perdido. Cada uno elige sus tareas.

22/10/2021
Ejemplo
Fuente: http://metodokanbansoftwareagil.blogspot.com

22/10/2021
Herramientas: Trello

22/10/2021
Herramientas: Wekan (open source)

22/10/2021
Test Driven Development
Es una técnica de diseño e implementación de
software, que se centra primero en hacer pruebas
unitarias antes de comenzar a escribir el código.
Aunque involucra la palabra test…
TDD no es una técnica de pruebas.
4

22/10/2021
Test-driven development
(Desarrollo impulsado por pruebas)
• Las pruebas unitarias se pueden escribir después,
durante o incluso antes de la codificación.
– test-driven development: Escribe pruebas, luego
escribe código para aprobarlas.
• Imagina que nos gustaría agregar un método
subtractWeeks para una clase Date, que
desplaza una fecha hacia atrás en el tiempo por el
número dado de semanas.
• Escriba código para probar este método antes de
que se haya escrito el código del comportamiento.
– Luego, una vez que implemente el método, ud. sabrá si
funciona.

22/10/2021
Test Driven Development
• Menos errores, menos depuración
• Más confianza, más productividad
• Mejor diseño
Objetivos
• Las pruebas dirigen el desarrollo
• Simplificar el diseño y desacoplar
• Escribir el código más simple que
pueda funcionar
Forma de pensar
en el desarrollo
software

22/10/2021
Ciclo de Desarrollo de TDD

22/10/2021
Las tres partes del test
• Escribir la
especificación del
requisito
convirtiéndolo en
test automático.
Arrange
(Preparar)
• Ejecutar la
funcionalidad a
probar.
Act
(Actuar) • Refactorizar
código.
Assert
(Afirmar)
La refactorización de código tiene el objetivo de que los métodos puedan
leerse de la manera más fácil posible.

22/10/2021
public void PruebaMultiplicación()
{
assertEquals(6, FuncionesMatematicas.multiplicacion(2,3));
}
public class FuncionesMatematicas {
public static int multiplicacion (int a, int b) {
return 0;
}
}
return 6;
}
}
Arrange
Assert
Act
return a*b;
}
}

22/10/2021
Pruebas unitarias
• Propósito: Encontrar
defectos en un módulo o
función.
• Normalmente las pruebas
unitarias son hechas por
el programador del
módulo.
• Para probar una función
debes:
– Llamarla
– Tener subfunciones para
invocar
Test Driver
Your function
Stub Stub

22/10/2021
Pruebas Unitarias
• Descripción
– Su propósito es encontrar errores en la
lógica, datos o algoritmos en componentes o
subsistemas individuales
– Realizado por los desarrolladores del
componente

22/10/2021
Especificación de un prueba unitaria
Parámetro Valor
Parámetro1 Valor del parámetro 1
Retorno Valor retornado o bien ‘-’.
Estado Inicial Condiciones del estado inicial del sistema o bien ‘-’.
Excepción Excepción que se devuelve en este caso o bien ‘-’.
Efecto Efectos laterales para este caso o bien ‘-’.
Observación Qué sucedió?
Resultado No probado/Cumple/No Cumple

22/10/2021
Código CP-001
Caso de prueba Ingreso de usuarios
Responsable Desarrolladores
Descripción de la
prueba
• Se ingresan los siguientes parámetros:
• Hacer clic en el botón entrar.
Requisito previo Haber ingresado correctamente al sistema.
Resultado
esperado
El usuario será registrado en la aplicación.
Resultado
obtenido
Se ha ingresado correctamente el usuario.
Estado Exitoso
Observaciones

22/10/2021
Frameworks
• Ofrecen un conjunto de utilidades, motores
de ejecución para pruebas unitarias

22/10/2021
Contenido
alternativos
Conclusiones

22/10/2021
Metodologías de desarrollo: Ágiles vs Tradicionales
Metodologías Ágiles Metodologías Tradicionales
Desarrollo iterativo Análisis, diseño, implementación y
pruebas
Ágil, dinámico y muy flexible.
Preparados para cambios durante el
proyecto
Estricto, rígido y con cierta resistencia a
cambios (toma de requisitos inicial)
Entre las principales: XP, SCRUM,
ICONIX , AUP, que son las más
aceptadas dentro de estas
metodologías
Dentro de estas metodologías las más
conocidos son Rational Unified Process
(RUP) y Microsoft Solution Framework
(MSF)
El cliente es parte del equipo de
desarrollo
El cliente interactúa con el equipo de
desarrollo mediante reuniones
Grupos pequeños (<10 integrantes) y
trabajando en el mismo sitio
Grupos grandes y posiblemente
distribuidos
Pocos artefactos Más artefactos
Pocos roles Más roles

22/10/2021
Cabe destacar:
• El retrasar las decisiones en un proyecto de
software permite potenciar el valor del producto
tanto para el cliente como al equipo o empresa
que desarrolla
• Para que un grupo de desarrollo adopte una
metodología ágil debe poseer
experiencia trabajando con metodologías
tradicionales, ya que la experiencia es la que
predomina en los mementos cruciales del
proyecto, además debe tener la capacidad de ser
equipos auto-gestionados, altamente motivados y
con gran innovación

22/10/2021
Cabe destacar:
• Las metodologías ágiles permiten disminuir
costos y brindar flexibilidad a los proyectos de
software donde la incertidumbre está presente
• El uso de metodologías tradicionales es
esencial al inicio en un equipo de desarrollo de
software
• Las metodologías ágiles se deberían aplicar en
proyectos donde exista mucha incertidumbre
donde el entorno es volátil, donde los requisitos
no se conocen con exactitud, mientras que las
metodologías tradicionales obligan al cliente a
tomar las decisiones al inicio del proyecto.

22/10/2021
Modelos de proceso del
software
Unidad 2
Final de la unidad

IIS Unidad 2 Modelos de proceso del software

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IIS Unidad 2 Modelos de proceso del software

Similar to IIS Unidad 2 Modelos de proceso del software (20)

More from Franklin Parrales Bravo

More from Franklin Parrales Bravo (20)

Recently uploaded

Recently uploaded (11)

IIS Unidad 2 Modelos de proceso del software