Introduccion Ingdelsoftware2

introducción a la ingeniería del
software
enrique barreiro
departamento de informática
universidade de vigo
escuela superior de ingeniería informática

ingeniería del software de gestión
características y evolución del software
tema 1 – introducción a la ingeniería del software
un poco de historia
primeras décadas:
desarrollar el hardware
reducir costes de procesamiento y almacenamiento
década de los ochenta:
desarrollo de la microelectrónica
mayor potencia de cálculo y reducción de costes
objetivo actual: mejorar la calidad de las soluciones software.
1959 - 1965 1965 - 1975 1975 - 1989 1989 -

Sistemas
Sistemasdistribuidos
distribuidos Potentes
Potentessistemas
sistemas
Orientación Multiusuario
Multiusuario Inteligencia
Orientación Tiempo real InteligenciaArtificial
Artificial de sobremesa
de sobremesa
por
porlotes Tiempo real Hardware Tecnología
lotes Bases de datos Hardwarede debajo
bajo Tecnologíade deobjetos
objetos
Distribución
Distribución
Bases de datos coste
coste Sistemas
Sistemasexpertos
expertos
Software como
Software como Impacto Redes
limitada
limitada producto Impactoenenelel Redesneuronales
neuronales
Software producto consumo Cliente/servidor
Softwareaa Mayores gastos
Mayores gastos
consumo
Redes
Cliente/servidor
Tecnologías
medida de Redesarea
arealocal
local Tecnologíasde de
medida demantenimiento
mantenimiento yyglobal Internet.
global Internet.
Gran
Grandemanda
demanda
AUMENTAN los problemas del desarrollo de software:

 Subexplotación del potencial del hardware
 Incapacidad de atender a la demanda
 Incapacidad de mantener el software existente
© enrique barreiro alonso escuela superior de ingeniería informática

universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 41
software
programas
archivos de configuración
documentación de la estructura del sistema
manuales de instalación y uso
sitios web con información y actualizaciones
tipos de software
productos genéricos
sistemas producidos por una organización y que se venden en el mercado
abierto
sistemas gestores de bases de datos, procesadores de texto, paquetes
gráficos,...
la organización controla la especificación
productos personalizados
desarrollados específicamente para un cliente
aplicaciones de negocio, sistemas de control de tráfico aéreo, control de
procesos de fabricación,...
el cliente controla la especificación de la aplicación

El software desde una perspectiva industrial

El valor del software: de “elemento añadido” a principal
elemento de coste
El desarrollo del software:
Algunas preguntas:
¿Por qué se tarda tanto? (y casi siempre más de lo previsto)
¿Por qué la productividad es tan baja?
¿Por qué cuesta tanto?
¿Por qué siempre quedan errores sin localizar?

naturaleza y problemas del desarrollo de software
El software como elemento lógico.

Se desarrolla, no se fabrica:
Calidad del diseño.
Costes más importantes en la ingeniería
Gestión especial de los proyectos
Se “deteriora” con el mantenimiento
Desarrollo a medida (ausencia de componentes)
La “crisis” del software: problemas que aparecen en el desarrollo del

software al desarrollar, mantener y atender la demanda de nuevas
aplicaciones.
Sin tiempo para recoger

datos históricos
Planificación y estimaciones
imprecisas
Dificultad de mantener
el software existente
Insatisfacción del cliente
Calidad Baja productividad

naturaleza y problemas del desarrollo de software
Causas de la crisis del software

Naturaleza lógica del software
Mala gestión de los proyectos ( ausencia de datos, deficiente
comunicación, ...)
Ausencia de entrenamiento formal en nuevas técnicas
(programadores vs. ingenieros de software)
MITOS DE GESTIÓN
Resistencia al cambio
Mitos del software: - Uso de estándares
- Uso de herramientas
- Mala planificación: aumento
de programadores
MITOS DE LOS DESARROLLADORES MITOS DEL CLIENTE

- Programa funcionando = fin del trabajo - Requisitos establecidos como
- Calidad = el programa se ejecuta una declaración general de
sin errores objetivos
- Entrega al cliente: programa - Flexibilidad del software ante
funcionando los cambios

la ingeniería del software
definiciones
establecimiento y uso de principios de ingeniería robustos,
orientados a obtener software económico, fiable, eficiente y
que satisfaga las necesidades del usuario
disciplina que comprende todos los aspectos de la producción
de software, desde las etapas iniciales hasta el
mantenimiento:
“disciplina de ingeniería”: aplicación de teorías, métodos y
herramientas para solucionar problemas, y teniendo en cuenta
restricciones financieras y organizativas
“todos los aspectos de producción”: comprende procesos
técnicos del desarrollo y actividades como la administración de
proyectos, desarrollo de herramientas, métodos y teorías
actividad de
modelado
solución de problemas
adquisición de conocimiento
dirigida por una fundamentación

la ingeniería del software
trata de ser la respuesta a la crisis del software

combinación de elementos:
métodos completos para

todas las fases
mejores técnicas de
control de calidad
mejores elementos
de programación
herramientas para automatizar

los métodos
filosofía de coordinación,
control
y buena gestión

modelado
modelado: método básico de la ciencia

modelo
representación abstracta de un sistema que da respuesta a
preguntas sobre el sistema
útiles cuando se manejan sistemas grandes, pequeños, complicados
o caros para tener una experiencia de primera mano
permiten visualizar y comprender sistemas que no existen o que sólo
se supone que existen
ejemplos:
biología: modelos de dinosaurios a partir de restos
física: modelos que representan cómo se reúnen materia y energía en los
niveles subatómicos más bajos
el sistema en el mundo real serían dinosaurios o partículas subatómicas
modelos

modelado
los ingenieros de software necesitan

comprender el ambiente de funcionamiento del sistema:
construyen modelos del dominio del problema (sistemas de
bolsa, control de tráfico aéreo,...)
comprender los distintos sistemas que podrían construir para
evaluar alternativas: construyen modelos del dominio de la
solución
SISTEMA DE PAGOS Y
Solicitar bienes o servicios

FACT URACIÓN
técnicas y herramientas para construir los modelos (por
ejemplo, diagramas de UML)
iniciador Confirmar pedido
iniciador
<<subsistema>>
Enviar factura al comprador
Sistema de
iniciador visión
Hojear facturas
iniciador <<subsistema>>
Pagar factura
Vendedor
<<subsistema>> <<subsistema>>
Comprador <<extend>> Controlador del Controlador del
iniciador
brazo asidero
<<subsistema>>
Realizar transacción Sistema de identificación
Pagar recargo por saldo deudor de objetos
Planificar pago Rechazar

factura factura
Sistema de
cuentas bancarias
<<subsistema>>
Pagar factura en día <<subsistema>> <<subsistema>>

Sistema de selección <<subsistema>> Controlador de cinta
Enviar aviso vencimiento Sistema de transportadora
de embalajes
embalaje

solución de problemas
los ingenieros de software buscan una solución adecuada, en varios pasos:

1. Formular el problema
2. Analizar el problema
3. Buscar soluciones
4. Decidir la solución más adecuada
5. Especificar la solución
actividades básicas del desarrollo

1. obtención de requerimientos
2. análisis
3. diseño del sistema
4. implementación
otras actividades del desarrollo para evaluar la adecuación de los modelos

revisiones del análisis: el modelo del dominio del problema se compara con la
realidad del cliente
revisiones del diseño: el modelo del dominio de la solución se compara con los
objetivos del proyecto
pruebas: el sistema se valida contra el modelo del dominio de la solución
administración del proyecto: se compara el modelo del proceso de desarrollo
(calendario y presupuesto) con la realidad (trabajos entregados y recursos
gastados)

participantes y papeles
participantes: todas las personas involucradas en el

proyecto
cliente: encarga y paga el sistema
desarrolladores: construyen el sistema (analistas,
diseñadores, programadores,...)
gerente o director del proyecto: planifica y calcula el
presupuesto, coordina a los desarrolladores y cliente
usuarios finales: los que van a utilizar el sistema
papel (rol)
conjunto de responsabilidades en el proyecto o en el sistema
asociado con un conjunto de tareas y se asigna a un
participante
un mismo participante puede cumplir varios papeles

otros conceptos de la ingeniería del software
sistemas y modelos
sistema: realidad subyacente
modelo: cualquier abstracción de la realidad
productos de trabajo
artefacto o elemento que se produce durante el desarrollo (documento,
fragmento de software,...)
dos tipos:
producto de trabajo interno: producto para el consumo interno del proyecto (por
ejemplo, una revisión de la estructura de la base de datos, resultados de pruebas para el
gerente,...)
entrega: producto de trabajo para un cliente (especificación de requisitos, manual de
usuario, producto final,...)
actividades, tareas y recursos

actividad (o fase): conjunto de tareas que se realiza con un propósito específico
(obtención de requisitos, entrega, administración,...) que pueden componerse de
otras actividades
tarea: unidad elemental de trabajo que puede ser administrada; consumen
recursos, dan como resultado productos de trabajo y dependen de productos de
trabajo producidos por otras tareas
recursos: bienes que se utilizan para realizar el trabajo:
tiempo, equipamiento y recursos humanos
al planificar, el gerente divide el trabajo en tareas y les asigna recursos

objetivos, requerimientos y restricciones

objetivos:
principios de alto nivel que se utilizan para guiar el proyecto
definen los atributos realmente importantes del sistema
(seguridad, fiabilidad,...)
a veces hay conflicto entre objetivos (por ejemplo, seguridad y
bajo coste) que aumentan la complejidad del proyecto
requerimientos
características que debe tener el sistema
requerimiento funcional: área de funcionalidad que debe
soportar el sistema (por ejemplo, proporcionar billetes de tren)
requerimiento no funcional: restricción que se establece sobre
el funcionamiento del sistema (por ejemplo, proporcionar
billetes de tren en menos de un segundo)
otras restricciones: por ejemplo, utilización de un
determinado lenguaje, de una determinada plataforma o de
un sistema antiguo que el cliente no quiere retirar

notaciones, métodos y metodologías

notación: conjunto de reglas gráficas o de texto para
representar un modelo (UML, Unified Modelling Language, es
una notación gráfica orientada a objetos para representar
modelos)
método: técnica repetible para resolver un problema
específico. Por ejemplo:
un algoritmo de ordenación es un método para ordenar
elementos en una lista
la administración de la configuración es un método para el
seguimiento de los cambios
metodología: colección de métodos para la resolución de una
clase de problemas (OMT, metodología de Booch, Catalysis,
Proceso Unificado de Desarrollo,...)

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

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
Transacción
da como resultado
da como resultado
cantidad pagada
cantidad pagada BilleteTren
BilleteTren
Saldo
Saldo
válido para
válido para
Zona
Papel Zona
Moneda Papel
Moneda

diseño
diseño del sistema
Gestión
Gestión facturas
facturas
comprador
comprador 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,...)
Gestión
Gestión de
de planificación
planificación Gestión
Gestión de
de
de
de pagos
pagos cuentas
cuentas
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
IU
IU Solicitud
Solicitud
de
de pago
pago objetos para lograr los objetivos de diseño,
optimización del modelo para mejorar el
Comprador
Comprador rendimiento,...
Procesamiento
Procesamiento dede resultado: modelo de objetos detallado
solicitudes
solicitudes de
de pago
pago
actividades del diseño

Planificador
Planificador Gestor
Gestor de
de
Procesamiento
Procesamiento
de
de facturas
facturas
diseño arquitectónico
de
de pagos
pagos
especificación de los subsistemas
pedidos
pedidos
diseño de interfaz
Solicitud
Solicitud
de
Confi
de
rmación
Confirmación
de pedidos
pedidos
Factura
Factura diseño de componentes
de pago
pago
diseño de la estructura de datos
diseño procedimental (algoritmos)

<<subsystem>> <<subsystem>>
Gestión Trabajos Gestión Sistema <<subsystem>>
Externos Mantenimientos
de Gestión
<<subsystem>> <<subsystem>> <<subsystem>>

Gestión Mantenimiento Validación Gestión
Correctivo Usuarios Instalaciones
<<subsystem>>
Gestión Mantenimiento <<subsystem>>
Preventivo Gestión
Subgrupos-Instalaciones
<<subsystem>>
Gestión Máquinas
Subgrupo

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

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 : Administrador Opciones Frm CTRL Alta Form_Alta Validar Datos Resultado Alta MENSAJES
Cliente Instalación INSTALACION
guardados si el proceso finaliza correctamente.
2. Los datos de la nueva característica no quedan Seleccionar
guardados si se produce algún error durante el
proceso. Crea()
Descripción 1. El sistema muestra el formulario de altas.
Crea()
2. El usuario introduce los datos.
3. El sistema realiza la validación de los datos.
4. Si la característica ya existe [A]. Mostrar
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, Introducir Datos()
si hay algún problema el sistema avisa con un
Comprobar()
mensaje de error.
Excepciones El proceso se puede cancelar en cualquier momento.
A. Si la característica ya existe se visualizan sus datos. Obtener Datos
...
B. Datos incorrectos, ir a punto 2.
Mostrar(Datos)
Cubrir_Datos()
Si no Existe
Comprobar()
Alta Características-Maq Datos Correctos Crear_Alta()

<<include>>
Construir
<<include>>
Visualizar Resultado
<<include>>
Validar Usuario Construir
Administrador Datos no Correctos
(from Vali dación Usuari os)
Modificación Características-Maq Visualizar Mensaje
Fin Si
Fin Si
Operario

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 Sistema (from Validar Usuario) Administrador (from Alta Máquinas)
formulario.
Administrador Validado
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. Visualizar Seleccionar
Formulario Formulario
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.
Comprobar Introducir
7. El sistema guarda los datos.
Datos Datos
8. Si se guarda correctamente se visualiza un mensaje,
si hay algún problema el sistema avisa con un
mensaje de error. Datos Incorrectos Mensaje "Error
Excepciones El proceso se puede cancelar en cualquier momento.
Datos"
A. Si la característica ya existe se visualizan sus datos. Datos Correctos
B. Datos incorrectos, ir a punto 2.
Comprobar Existencia
de la Instalación
Si Existe Visualizar Datos

Instalación
No Existe Seleccionar
Guardar
Alta Características-Maq Guardar Datos

<<include>>
Instalación
<<include>> Error al Guardar Mensaje

"Error"
<<include>> Instalación Guardada
Validar Usuario
Administrador Mensaje "Instalación
guardada"
(from Vali dación Usuari os)
Modificación Características-Maq
Operario

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

ODBC
Servidor SGBD
TCP/IP
TCP/IP Red Local Impresora
Cliente
TCP/IP
Cliente


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
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

actividades de administración del desarrollo

comunicación
actividad crítica y costosa en tiempo
intercambio de modelos y documentos, informes de evolución
y calidad, negociaciones, comunicación de decisiones,...
herramientas y notaciones
gestión de la configuración
proceso que supervisa y controla los cambios en los productos
de trabajo
cambios: requerimientos, plataformas hardware y software,
errores encontrados, mejoras del sistema,...
administración del proyecto
objetivo: asegurar la entrega de un sistema de alta calidad a
tiempo y dentro del presupuesto
planificación y presupuesto del proyecto
contratación de desarrolladores y coordinación de equipos
vigilancia de la evolución del proyecto
detección de desviaciones e intervención

el proceso de desarrollo


el proceso: modelos de desarrollo
proceso
conjunto ordenado de tareas, una serie de pasos que involucran actividades,
restricciones y recursos, que producen una salida determinada
proceso de software: conjunto de actividades necesarias para transformar los
requisitos de un usuario en un sistema software
características
tiene una serie de actividades principales
utiliza recursos, está sujeto a restricciones y genera productos intermedios y finales
compuesto por subprocesos que se encadenan de alguna forma
cada actividad tiene sus criterios de entrada y salida, que permiten conocer cuando
comienza y termina dicha actividad
existen principios orientadores que explican las metas de cada actividad
cuando implica la construcción de un producto, se suele llamar ciclo de vida
aportan consistencia y estructura sobre el conjunto de actividades, lo que
permite realizar la misma tarea correctamente de forma repetida
existen diferentes modelos de proceso
Requisitos
del usuario Sistema software
Proceso de desarrollo
de Software

modelo en cascada
Requerimentos
y Análisis
Diseño
Implementación
Pruebas
Mantenimiento
resultado de cada fase: uno o más se retrasa la localización y corrección

documentos aprobados de errores
una fase comienza cuando la anterior pueden producir sistemas poco útiles
termina para usuarios o mal estructurados
en la práctica, las etapas se solapan inflexibilidad del modelo: dificultad
para responder a cambios en los
iteraciones de coste elevado y requerimientos
reelaboración del trabajo: tendencia a
la congelación de partes del desarrollo
(especificaciones,...)

desarrollo evolutivo
basado en: dos tipos:

desarrollo de una implementación inicial prototipado evolutivo:
exposición a comentarios y crítica del trabajo con cliente para explorar
usuario sus requerimientos y entregar un
sistema final
refinamiento a través de diferentes
versiones hasta llegar a un sistema evolución continua del prototipo
adecuado mediante la agregación de
funciones y características
propuestas por el cliente
prototipos desechables
Recolección comprensión de las necesidades
y refinamiento de del cliente
requisitos desarrollo de una definición
mejorada de los requerimientos
del sistema
Producto prototipos centrados en la
Diseño experimentación de requisitos
rápido poco claros o complejos
problemas
prisas del cliente (utilización del
prototipo como sistema final
Refinamiento Construcción pasar elecciones debidas al prototipo a
del prototipo del prototipo la implementación final (entorno,
sistema operativo,...)
estructura deficiente
Evaluación del evolución del proceso difícil de gestionar
prototipo por
herramientas y técnicas especiales
el cliente
poco adecuado para grandes sistemas

prototipado con lenguajes visuales
Hypertext
Date component display component
File Edit Views Layout Options Help

General
12th January 2000 Index
Range checking 3.876
script
User prompt
component +
Draw canvas script
component
Tree display
component
fuente: I. Sommerville, Software Engineering, 6th ed.,2000

desarrollo incremental
Definición general de
requerimientos pasos
identificación y priorización de funciones y
servicios
Asignación de requerimientos
a incrementos definición de varios requerimientos que
proporcionan parte de la funcionalidad, según la
prioridad (los más importantes se entregan
Diseño de la arquitectura del
antes)
sistema definición detallada de requerimientos del
incremento y desarrollo con el proceso más
adecuado
Desarrollo de incrementos congelación de requerimientos de incrementos
del sistema desarrollados
puesta en explotación de los incrementos
Validar completados y entregados
incrementos
ventajas
Integrar puesta en marcha temprana
incrementos
los incrementos iniciales permiten refinar
requerimientos de incrementos posteriores
Validar satisfacción del cliente (bajo riesgo de fallo)
sistema
sistema final muy probado y con pocos fallos
problemas
sistema incompleto
incrementos relativamente pequeños
sistema completo
adaptación de requerimientos a incrementos del
tamaño apropiado
Sistema final identificación de recursos comunes a todos los
incrementos

modelo en espiral
PROGRESO
propuesto por Barry A TRAVÉS
Boehm DETERMINAR
OBJETIVOS,
DE LAS ITERACIONES EVALUAR ALTERNATIVAS,
ALTERNATIVAS Y IDENTIFICAR Y
RESOLVER RIESGOS
organización en ciclos RESTRICCIONES
Análisis de riesgos
primer ciclo: factibilidad
segundo ciclo:
requerimientos Análisis de riesgos
tercer ciclo: diseño

... Análisis de riesgos
Prototipo
cada ciclo se divide en 4 An. Prototipo 3
operativo
sectores Riesgo.
Proto- Prototipo 2
-
REVISIÓN tipo 1
definición de objetivos,
restricciones del producto Plan de Simulaciones, modelos,
.
y proceso, plan de requerimientos Concepto de pruebas comparativas
Plan de ciclo
administración,... de vida
operación
Requerimientos
de software
evaluación y reducción de
Diseño del Diseño
riesgos (por ejemplo, producto detallado
mejor definición de Plan de Validación de
requerimientos
desarrollo
requerimientos mediante
prototipos) Codificar
Plan de integración
Diseño de validación
desarrollo y validación: y prueba
y verificación Prueba de
elección de un modelo PLANIFICAR SIGUIENTE
unidad
para el desarrollo FASE Prueba de
integración
planificación: el proyecto Prueba de
se revisa y se decide si se -
aceptación
continúa con el siguiente Explotación

ciclo. si es así, se planifica DESARROLLAR, VERIFICAR
PRODUCTO DE SIGUIENTE NIVEL
la siguiente fase

el proceso unificado de desarrollo
proceso unificado de desarrollo

propuesto por los autores de UML (lenguaje unificado de
desarrollo)
basado en componentes interconectados a través de
interfaces
utiliza UML para desarrollar los esquemas y diagramas de un
sistema software
principales aspectos definitorios
dirigido por casos de uso
centrado en la arquitectura
iterativo e incremental
Requisitos
del usuario Sistema software
Proceso de desarrollo
de Software

el proceso unificado: dirigido por casos de uso
para construir un sistema con éxito hay que conocer las

necesidades y deseos de los futuros usuarios
usuario
personas que trabajan y necesitan el sistema
otros sistemas que interactúan con el que estamos desarrollando
interacción:
usuario inserta tarjeta en cajero automático
usuario responde sobre la pantalla a las preguntas que realiza el cajero
Retirar dinero
el usuario recibe una cantidad de dinero y su tarjeta
una interacción así es un caso de uso
fragmento de funcionalidad del sistema que proporciona al usuario un
resultado importante
Cliente del banco
Ingresar dinero
utilidad casos de uso
herramienta para especificar los requisitos de un sistema:
representan los requisitos funcionales y juntos constituyen el
modelo de casos de uso, que describe la funcionalidad total del
sistema
Transferencia entre cuentas
guían el proceso de desarrollo (diseño, implementación y prueba)
basándose en el modelo de casos de uso, se crean modelos de diseño e
implementación
se revisa cada modelo para que sean conformes al modelo de casos de
uso
se prueba la implementación para garantizar que los componentes del
modelo de implementación implementan correctamente los casos de
uso
no sólo inician el proceso de desarrollo sino que éste sigue un hilo
de trabajo que parte de los casos de uso

el proceso unificado: centrado en la arquitectura
casos
casos de
de la arquitectura de un sistema software se describe
uso mediante diferentes vistas del sistema en
construcción
conduce influida por diversos factores
guía necesidades de la empresa, tal y como las perciben los
usuarios y clientes
otros factores, como plataforma de explotación
(arquitectura hardware, sistema operativo, gestor de
arquitectura bases de datos, protocolos de comunicación,...),
componentes reutilizables, sistemas heredados,
requisitos no funcionales,...
es una vista del diseño completo con las
características más importantes resaltadas, dejando
los detalles de lado.
Capa específica
de la aplicación hay una constante interacción entre los casos de uso y
la arquitectura, que evolucionan en paralelo
los casos de uso deben encajar en la arquitectura cuando
se realizan
Capa general de la
la arquitectura debe permitir el desarrollo de todos los
aplicación
casos de uso requeridos
el arquitecto
realiza un esquema en borrador de la arquitectura que
no es específica de los casos de uso (por ejemplo, la
Capa
plataforma)
intermedia trabaja con un subconjunto de los casos de uso
principales del sistema, especificándolo en detalle y
realizándolo en términos de subsistemas, clases y
componentes
a medida que los casos de uso se especifican y maduran,
Capa de software se descubre más de la arquitectura, lo que a su vez lleva
del sistema a la maduración de más casos de uso
este proceso continúa hasta que se considera que se
dispone de una arquitectura estable

el proceso unificado: iterativo e incremental
el trabajo se divide en partes más pequeñas o miniproyectos

miniproyecto: una iteración que resulta en un incremento
iteración: pasos en el flujo de trabajo
incremento: crecimiento del producto
las iteraciones están controladas y planificadas
factores para seleccionar lo que se implementará en una iteración
la iteración se centra en un grupo de casos de uso que juntos amplían la utilidad del
producto desarrollado hasta ahora
la iteración trata los riesgos más importantes
las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como
quedaron al final de la última iteración
en las primeras fases del ciclo de vida los incrementos implican modificaciones
en las últimas fases los incrementos implican menos modificaciones y más añadidos a los
modelos
para cada iteración:
identificación y especificación de los casos de uso relevantes
creación de un diseño utilizando la arquitectura seleccionada como guía
implementación del diseño mediante componentes
verificación de que los componentes satisfacen los casos de uso
si una iteración cumple con sus objetivos, el desarrollo continúa con la siguiente iteración. Si
no, se revisan las decisiones previas y se adopta un nuevo enfoque
ventajas proceso iterativo controlado
reducción del coste del riesgo a los costes de un solo incremento
reducción del riesgo de no sacar al mercado el producto en el calendario previsto
se acelera el ritmo del esfuerzo de desarrollo en su totalidad, para obtener resultados claros
a corto plazo
los requerimientos del usuario se van refinando en iteraciones sucesivas, por lo que se
pueden acomodar mejor los cambios

la vida del proceso unificado
el proceso unificado se repite a lo largo de una serie de ciclos

cada ciclo concluye con una versión del producto y consta de cuatro
fases
inicio: descripción del producto final a partir de una idea inicial y análisis
de negocio para el producto
principales funciones del sistema y usuarios más importantes (modelo de casos de
uso)
posible arquitectura del sistema
plan del proyecto, coste, identificación y priorización de riesgos
elaboración:
se especifican en detalle los principales casos de uso
se diseña la arquitectura del sistema: vistas arquitectónicas del modelo de casos
de uso, del modelo de análisis, del modelo de diseño, del modelo de
implementación y modelo de despliegue
al final se pueden planificar las actividades y estimar recursos necesarios para
finalizar el proyecto
construcción:
se crea el producto añadiendo el software a la arquitectura
al final se dispone de todos los casos de uso acordados para el desarrollo aunque
puede incorporar defectos
transición
periodo durante el cual el producto se convierte en versión beta, en la que usuarios
prueban el producto e informan de defectos y deficiencias
se corrigen problemas e incorporan sugerencias
incluye actividades como la formación del usuario, proporcionar una línea de ayuda
y asistencia,...
cada fase se divide a su vez en iteraciones

la vida del proceso unificado
Fases
Flujos de trabajo Inicio Elaboración Construcción Transición
fundamentales
Requisitos
una iteración en la
fase de elaboración
Análisis
Diseño
Implementación
Prueba
iter #1 iter #2 --- --- --- --- --- iter #n-1 iter #n
Iteraciones

bibliografía
Bruegge, B., Dutoit, A.H., Ingeniería del Software Orientado a Objetos, cap. 1
Jacobson, I., Booch, G., Rumbaugh, J., El Proceso Unificado de Desarrollo de

Software, cap. 1
Pressman, R.S., Ingeniería del Software. Un enfoque práctico, cap. 1 y 2
Sommerville, I., Ingeniería de Software, cap. 1, 2 y 3


Introduccion Ingdelsoftware2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Introduccion Ingdelsoftware2

Cargado por

Copyright:

Formatos disponibles

introducción a la ingeniería del

escuela superior de ingeniería informática

1959 - 1965 1965 - 1975 1975 - 1989 1989 -

AUMENTAN los problemas del desarrollo de software:

© enrique barreiro alonso escuela superior de ingeniería informática

© enrique barreiro alonso escuela superior de ingeniería informática

El software desde una perspectiva industrial

El desarrollo del software:

© enrique barreiro alonso escuela superior de ingeniería informática

El software como elemento lógico.

La “crisis” del software: problemas que aparecen en el desarrollo del

Sin tiempo para recoger

© enrique barreiro alonso escuela superior de ingeniería informática

Causas de la crisis del software

MITOS DE LOS DESARROLLADORES MITOS DEL CLIENTE

© enrique barreiro alonso escuela superior de ingeniería informática

© enrique barreiro alonso escuela superior de ingeniería informática

trata de ser la respuesta a la crisis del software

métodos completos para

herramientas para automatizar

© enrique barreiro alonso escuela superior de ingeniería informática

modelado: método básico de la ciencia

© enrique barreiro alonso escuela superior de ingeniería informática

los ingenieros de software necesitan

Solicitar bienes o servicios

iniciador Confirmar pedido

Planificar pago Rechazar

Pagar factura en día <<subsistema>> <<subsistema>>

© enrique barreiro alonso escuela superior de ingeniería informática

los ingenieros de software buscan una solución adecuada, en varios pasos:

actividades básicas del desarrollo

otras actividades del desarrollo para evaluar la adecuación de los modelos

© enrique barreiro alonso escuela superior de ingeniería informática

participantes: todas las personas involucradas en el

© enrique barreiro alonso escuela superior de ingeniería informática

actividades, tareas y recursos

© enrique barreiro alonso escuela superior de ingeniería informática

objetivos, requerimientos y restricciones

© enrique barreiro alonso escuela superior de ingeniería informática

notaciones, métodos y metodologías

© enrique barreiro alonso escuela superior de ingeniería informática

© enrique barreiro alonso escuela superior de ingeniería informática

© enrique barreiro alonso escuela superior de ingeniería informática

actividades del diseño

© enrique barreiro alonso escuela superior de ingeniería informática

<<subsystem>> <<subsystem>> <<subsystem>>

© enrique barreiro alonso escuela superior de ingeniería informática

© enrique barreiro alonso escuela superior de ingeniería informática

Nombre Alta Características Máquina

Alta Características-Maq Datos Correctos Crear_Alta()

Modificación Características-Maq Visualizar Mensaje

© enrique barreiro alonso escuela superior de ingeniería informática

Nombre Alta Características Máquina

Si Existe Visualizar Datos

Alta Características-Maq Guardar Datos

<<include>> Error al Guardar Mensaje

© enrique barreiro alonso escuela superior de ingeniería informática

© enrique barreiro alonso escuela superior de ingeniería informática

TCP/IP Red Local Impresora

© enrique barreiro alonso escuela superior de ingeniería informática

© enrique barreiro alonso escuela superior de ingeniería informática

© enrique barreiro alonso escuela superior de ingeniería informática

actividades de administración del desarrollo