PARADIGMAS
PARADIGMAS
PARADIGMAS DE LA
INGENIERIA DE SOFTWARE
Paradigmas de ciclos de vida de
laCuando
ingeniería de software
no se sigue un ciclo de vida y apenas se planea, se tiende a
seguir el enfoque de “codificar y probar” lo que genera: una alta
probabilidad de falla en el software, poca flexibilidad para
modificaciones, no satisfacer plenamente los requisito y
descontento de los clientes [Piattini].
Qué es un ciclo de vida:
Un modelo de ciclo de vida es 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/IEC 12207-1].
Ciclo de vida del software es una aproximación lógica a la
adquisición, suministro, el desarrollo, la explotación y el
mantenimiento del software [IEEE 1074].
Paradigmas de ciclos de vida de la ingeniería
de software … (2)
Algunas de las ventajas que aporta el enfoque de ciclo de vida
[Piattini]:
En las primeras fases, aunque no haya líneas de código, pensar el diseño
es avanzar en la construcción del sistema, pues posteriormente resulta
más fácil la codificación.
Asegura un desarrollo progresivo, con controles sistemáticos, que
permite detectar precozmente los defectos.
Se controla el sobrepasar los plazos de entrega y los costes excesivos
mediante un adecuado seguimiento del progreso.
La documentación se realiza de manera formal y estandarizada
simultáneamente al desarrollo, lo que facilita la comunicación interna
entre el equipo de desarrollo y la de éste con los usuarios. También
aumenta la visibilidad y posibilidad de control para la gestión del
proyecto.
Supone una guía para el personal de desarrollo, marcando las tareas a
realizar en cada momento.
Minimiza la necesidad de rehacer el trabajo y los problemas de puesta a
punto.
Paradigmas de ciclos de vida de la ingeniería
de software … (3)
Actividades agrupadas en procesos que se pueden realizar durante
el ciclo de vida del software [ISO 12207-1].
PROCESOS PRINCIPALES PROCESOS DE SOPORTE
DOCUMENTACIÓN
ADQUISICIÓN
GESTIÓN DE LA CONFIGURACIÓN
VERIFICACIÓN
VALIDACIÓN
EXPLOTACIÓN
REVISIÓN CONJUNTA
DESARROLLO
AUDITORIA
MANTENIMIENTO
RESOLUCIÓN DE PROBLEMAS
PROCESOS DE LA ORGANIZACIÓN
GESTIÓN INFRAESTRUCTURA
MEJORA FORMACIÓN
Ciclos de vida convencionales
Modelo secuencial (clásico)
Análisis de los requisitos del software
Se debe comprender el dominio de la información, la función requerida, comportamiento,
rendimiento e interconexión.
Diseño
Proceso de muchos pasos centrado en cuatro atributos: estructura de datos, arquitectura de
software, representación de la interfaz y detalle procedimental.
Generación de código
El diseño es traducido a formato legible por la máquina.
Pruebas
Detección de errores y asegurar que una entrada definida produce resultados esperados.
Mantenimiento
Cambios en el software que implican aplicar todos los pasos precedentes en orden.
Ingeniería de
sistemas de información
Eficiencia.
El software no debe desperdiciar los recursos del sistema.
Utilización adecuada.
El software debe contar con una interfaz de usuario adecuada y su
documentación.
V. Modelo de Ingeniería del
Proceso
Requisitos
Capturar los aspectos funcionales correspondientes, cómo un usuario
interactuaría con el sistema.
Análisis
Dar al sistema una estructura robusta y extensible bajo un ambiente de
implementación ideal.
Diseño
Adoptar y refinar las estructuras al ambiente de implementación particular.
Implementación
Codificar el sistema.
Pruebas
Validar y verificar el sistema.
Integración
Pegar componentes del sistema.
Documentación
Describir los distintos aspectos el sistema.
Mantenimiento
Extender la funcionalidad del sistema.
VI. Modelos de Desarrollo de Software
¿ Modelo ?
Representación formal o
simplificada del proceso de
software.
Modelos Genéricos del Desarrollo
de Software
Cascada (Lineal Secuencial)
Prototipado
DRA (Reutilización)
Evolutivo (Incremental)
Espiral
Espiral Win / Win
Basado en componentes
Programación Extrema
Proceso unificado de desarrollo de software (PUDS)
Modelo lineal secuencial
Las tareas se organizan en cascada, una después de la
otra.
La salida de una etapa es la entrada de la siguiente.
Creado en 1970 por el Departamento de la Defensa de
EE.UU.
Su usó en las primeras aplicaciones es crítica y compleja.
Modelo lineal secuencial
Definición de
Requerimientos
Diseño del SW
y del Sistema
Implementación y
Prueba de unidad
Integración y Prueba
del sistema
Operación y
mantenimiento
Paradigma clásico.
Definición alternativa
INGENIERÍADEL
SISTEMA
ANÁLISIS
DISEÑO
CODIFICACIÓN
PRUEBA
MANTENIMIENTO
Producto de Recolección y
ingeniería refinamiento
de requisitos
Refinamiento del
prototipo Diseño Rápido
Identificar
componentes
Análisis candidatos
Planificación
de riesgos
Construir Buscar
la Iteración componentes en
del sistema la biblioteca
Comunicación
con el cliente
Poner nuevos Extraer
componentes en componentes
la biblioteca si están
disponibles
Extraer
componentes
Evaluación si no están
del cliente disponibles
Construcción y
adaptación de la ingeniería
Modelos
recientes… (4)
Programación extrema XP
Disciplina de desarrollo de software creada por Kent Beck para proyectos cortos con requerimientos
cambiantes o poco claros (respaldada por gran parte de la industria y rechazada por otro tanto).
Se basa en la simplicidad, la comunicación y el reciclado continúo de código.
Pretende:
La satisfacción del cliente
Potenciar al máximo el trabajo en grupo
Reducir el costo del cambio en las etapas de vida del sistema
Combinar las que han demostrado ser las mejores practicas de desarrollo de software y llevarlas al
extremo.
Establece cuatro variables
Coste
Tiempo
Calidad
Ámbito
Plantea cuatro valores
Comunicación
Sencillez
Retroalimentación
Valentía
Define cuatro actividades básicas
Codificar
Hacer pruebas
Escuchar
Diseñar
Metodologías estructuradas
Pasan de una visión general del problema (abstracción cercana a las
personas) hasta llegar a un nivel de abstracción más sencillo (abstracción
cercana al hardware).
Esta visión se puede enfocar en las funciones del sistema, estructura de los
datos o ambos, lo que da lugar a las siguientes metodologías:
Orientadas a los procesos
Se centra en la transformación de los datos de entrada para generar la salida
esperada.
Orientadas a los datos
Estructuras de datos jerárquicas
Se centran en las entradas y salidas; primero se definen las estructuras de datos y, a partir
de éstas, se derivan los componentes procedimentales.
Estructuras de datos no jerárquicas
Los tipos de datos son el corazón del sistema ya que son más estables que los procesos.
Mixtas
Se enfocan tanto en el proceso como en los datos tomando desde diversos puntos
de vista.
Metodologías
estructuradas … (2)
Existen diversas metodologías estructuradas:
Orientadas a procesos:
De Marco.
Gane y Sarson
Yourdon/Constantine
Orientadas a datos jerárquicos
JSP y JSD
LCP
Orientadas a datos no jerárquicos
IE
Metodologías mixtas
Merise
SSADM
Métrica
Las especificaciones estructuradas utilizan:
DFD (Diagramas de flujo de datos, Dataflow Diagram)
Diagramas E-R (Entidad-Relación), o alternativamente DED (Diagramas de Estructura de Datos)
Diagramas HVE (Historia de vida de las entidades)
Diagramas de transición de estados (STD, State Transition Diagram)
Diccionario de datos
Especificación de procesos
Lenguaje estructurado
Pre y post condiciones
Tablas y árboles de decisión
Diagramas de estructura
Metodologías orientadas a
objetos
De forma general:
El dominio del problema se caracteriza mediante un conjunto de objetos con
atributos y comportamientos específicos.
Los objetos son manipulados mediante una colección de métodos y se
comunican mediante un protocolo de mensaje.
Los objetos son clasificados en clases y subclases.
Se retoman muchas de las ideas de las metodologías estructuradas pero
con el apoyo de lenguajes orientados a objetos.
En los 90’s había diversos enfoques orientados a objetos:
Booch
Rumbaugh
Jacobson
Otros más (Shaler y Mellor, Coleman)
En el 95 comienza el método unificado (Booch, Rumbaugh).
El mismo año se une Jacobson
Nace Rational Rose
De ahí surge UML aceptado por el OMG
(Object Management Group) en el 97
Metodologías orientadas a objetos … (2)
Actualmente las especificaciones orientadas a objetos utilizan el lenguaje estándar
predominante UML (Unified Modeling Lenguage) el cual combina notaciones
provenientes desde:
Modelado orientado a objetos
Modelado de datos
Modelado de componentes
Modelado de flujos de trabajo (workflows)
Los diagramas que expresan gráficamente las partes de un modelo son:
PUDS
60
El proceso unificado de desarrollo de
software
• Es un proceso ORIENTADO A OBJETOS
• El proceso es:
• Guiado por casos de uso
• Centrado en la arquitectura
• Con un ciclo de vida iterativo e incremental
PARTE
DINÁMICA
PARTE
ESTÁTICA 61
El proceso unificado de
desarrollo de software
• El Proceso Unificado de Desarrollo
usa UML
UML Notación
Herramientas Proceso
• RATIONAL ROSE
PROCESO UNIFICADO DE
• VISIO DESARROLLO DE RATIONAL
62
1. Guiado por
casos de uso
Los sistemas se crean para dar servicio
a los usuarios.
Qué REQUISITOS se necesitan
Un CASO de USO es una pieza de
FUNCIONALIDAD de un sistema que le
proporciona a algún USUARIO un
RESULTADO o VALOR.
63
Casos de uso
Todos juntos constituyen el
modelo de casos de uso
(MCU)
FUNCIONALIDAD COMPLETA
Actualizar Catálogo
Extender Préstamo
- No reservado
TrabajadorBiblio
Devolver Copia Libro
65
Desarrollo guiado por casos de uso
(CU)
LOS CASOS DE USO:
CAPTURAN REQUISITOS
SE ESPECIFICAN (ANALIZAN)
SE DISEÑAN
SE IMPLEMENTAN
Y SE PRUEBAN
66
Tomar Préstamo 1.- CASO DE USO Desarrollo guiado
por CASOS DE
USO
Persona
4: getSignatura()
CASO DE USO elLibro
5: getCopias()
6: isCopiaPrestada()
68
Centrado en la
ARQUITECTURA
1
: IU-1 : : : : :
2: 1: 3: G 2: 1: 3: G
r 4 r 4
() ()
o o
Requisitos
Análisis
Diseño
Implementación
Prueba
74
Fases dentro del CV del proceso
unificado
FASE: PARTE DE UN CV
CADA FASE TERMINA EN UN
HITO
HAY ARTEFACTOS DISPONIBLES
(SEGÚN LO PLANIFICADO)
LOS RESULTADOS EN LOS HITOS
PERMITEN GESTIONAR
75
Fases dentro del CV del
proceso unificado
• INICIACIÓN:
– DESCRIBIR PRODUCTO FINAL / ANÁLISIS DEL NEGOCIO
– IDENTIFICAR RIESGOS MÁS IMPORTANTES
– ESTABLECER PLANIFICACIÓN INICIAL DEL PROYECTO
– DECIDIR SI SE CONTINÚA
• ELABORACIÓN:
– ESTABLECER PLAN Y ARQUITECTURA ESTABLE
• CONSTRUCCIÓN: DESARROLLAR EL PRODUCTO
• TRANSICION: PROPORCIONAR SISTEMA A USUARIOS
76
Iteraciones
CADA FASE SE DIVIDE EN ITERACIONES
CADA ITERACIÓN
MINIPROYECTO (EN CASCADA) QUE EJECUTA
FLUJOS DE TRABAJO
PRODUCE UN INCREMENTO EN PRODUCTO
TAL Y COMO ESTABA
SE REDUCE EL RIESGO
SE PUEDE PERDER SÓLO LO REALIZADO EN ESA
ITERACIÓN
77
Iteraciones
Como se puede ver, el Proceso
Unificado de Desarrollo
incluye actividades
ITERACIÓN correspondientes a un Proceso
de Gestión de Proyectos
PLANIFICACIÓN DE EVALUACIÓN DE LA
LA ITERACIÓN ITERACIÓN
ANÁLISIS:
ESPECIFICAR REQUISITOS
CONSTRUIR MODELO DEL ANÁLISIS
79
Flujos de trabajo
• DISEÑO:
– ENCONTRAR LA FORMA DEL SISTEMA
(SOLUCIÓN)
– CONSTRUIR MODELO DEL DISEÑO
• IMPLEMENTACIÓN:
– CODIFICAR EL DISEÑO (SOLUCIÓN)
– CONSTRUIR MODELO DE IMPLEMENTACIÓN
• PRUEBAS:
– VERIFICAR LA IMPLEMENTACIÓN
– CONSTRUIR MODELO DE PRUEBAS
80
ANEXO
Fases: Iniciación
Establecer la planificación del proyecto
¿Qué va a hacer el sistema para cada uno de sus usuarios
principales?
Un MCU simplificado con los CU más críticos
¿Cómo sería la arquitectura para un sistema como ese?
Borrador con los subsistemas principales
¿Cuál es el plan y cuánto va a costar desarrollar el producto?
Identificar los riesgos principales y priorizarlos, planificar
elaboración y presupuesto aproximado
81
ANEXO
Fases: Elaboración
Establecer un plan para el proyecto y una arquitectura correcta
Especificar en detalle los CU + críticos
Diseñar la arquitectura
Mediante vistas de todos los modelos del SI
Vista arquitectónica de MCU, M. Análisis, M. Diseño, M.
Implementación (con los componentes que demuestran que la
arquitectura es ejecutable) y M. Distribución.
Al final de esta fase se debe poder planificar las
actividades y estimar los recursos para poder completar
el proyecto. ¿Son los CU, arquitectura y planes lo
suficientemente estables y los riesgos bajo control
suficiente para firmar un contrato para terminar el
trabajo de desarrollo?
82
ANEXO
Fases: Construcción
Desarrollar el sistema
Se construye el producto. En esta fase:
La arquitectura se completa para construir un sistema bien
cimentado
La visión evoluciona hasta convertirse en un producto
preparado para los usuarios
Es donde se gastan la mayoría de los recursos
La arquitectura del sistema es estable. Sin embargo, se
pueden realizar cambios mínimos a la misma.
¿El producto se ajusta suficientemente a las necesidades de
los usuarios de algunos usuarios como para enviarselo ya?
83
ANEXO
Fases: Transición
Proporcionar el sistema a los usuarios finales
El producto se encuentra en fase beta
Un grupo reducido de usuarios experimentados prueba el
producto e informa de los defectos y deficiencias y
sugieren mejoras.
Los desarrolladores corrigen las deficiencias e incorporan
algunas de las mejoras propuestas en una versión para un
grupo de usuarios mayor.
En esta fase se encuentran actividades como la venta,
formación de los usuarios, ofrecimiento de ayuda en línea
y corrección de defectos descubiertos tras la
implantación. Los defectos: (1) los que justifican la
aparición de una nueva versión del sistema, (2) los que se
pueden dejar para la siguiente versión que se cree.
84