Apuntes 2

tema 1 introduccin a la ingeniera
del software
enrique barreiro
departamento de informtica
universidade de vigo
escuela superior de ingeniera informtica
ingeniera del software de gestin
caractersticas y evolucin del software

tema 1 introduccin a la ingeniera del software
un poco de historia
primeras dcadas:
desarrollar el hardware
reducir costes de procesamiento y almacenamiento
dcada de los ochenta:

desarrollo de la microelectrnica
mayor potencia de clculo y reduccin de costes
objetivo actual: mejorar la calidad de las soluciones software.

1959 - 1965
Orientacin
Orientacin
por
porlotes
lotes
Distribucin
Distribucin
limitada
limitada
Software
Softwareaa
medida
medida
1965 - 1975
Multiusuario
Multiusuario
Tiempo real
Tiempo real
Bases de datos
Bases de datos
Software como
Software como
producto
producto
Mayores gastos
Mayores gastos
de
demantenimiento
mantenimiento
1975 - 1989
Sistemas distribuidos
Sistemas distribuidos
Inteligencia Artificial
Inteligencia Artificial
Hardware de bajo
Hardware de bajo
coste
coste
Impacto en el
Impacto en el
consumo
consumo
Redes area local
Redes area local
yyglobal
global
Gran demanda
Gran demanda
1989 -
Potentes sistemas
Potentes sistemas
de
desobremesa
sobremesa
Tecnologa de objetos
Tecnologa de objetos
Sistemas expertos
Sistemas expertos
Redes neuronales
Redes neuronales
Cliente/servidor
Cliente/servidor
Tecnologas de
Tecnologas de
Internet.
Internet.
AUMENTAN los problemas del desarrollo de software:

Subexplotacin del potencial del hardware
Incapacidad de atender a la demanda
Incapacidad de mantener el software existente
enrique barreiro alonso

universidade de vigo - departamento de informtica
escuela superior de
2 / 41

software
programas
archivos de configuracin
documentacin de la estructura del sistema
manuales de instalacin y uso
sitios web con informacin y actualizaciones
tipos de software
productos genricos
sistemas producidos por una organizacin y que se venden en el mercado
abierto
sistemas gestores de bases de datos, procesadores de texto, paquetes
grficos,...
la organizacin controla la especificacin
productos personalizados
desarrollados especficamente para un cliente
aplicaciones de negocio, sistemas de control de trfico areo, control de
procesos de fabricacin,...
el cliente controla la especificacin de la aplicacin

escuela superior de
3 / 41

El software desde una perspectiva industrial

El valor del software: de elemento aadido a principal
elemento de coste
El desarrollo del software:
Algunas preguntas:
Por qu se tarda tanto? (y casi siempre ms de lo previsto)
Por qu la productividad es tan baja?
Por qu cuesta tanto?
Por qu siempre quedan errores sin localizar?

escuela superior de
4 / 41
naturaleza y problemas del desarrollo de software

El software como elemento lgico.

Se desarrolla, no se fabrica:
Calidad del diseo.
Costes ms importantes en la ingeniera
Gestin 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 histricos
Planificacin y estimaciones
imprecisas
Dificultad de mantener
el software existente
Insatisfaccin del cliente
Calidad
Baja productividad
escuela superior de
5 / 41
naturaleza y problemas del desarrollo de software

Causas de la crisis del software

Naturaleza lgica del software
Mala gestin de los proyectos ( ausencia de datos, deficiente
comunicacin, ...)
Ausencia de entrenamiento formal en nuevas tcnicas
(programadores vs. ingenieros de software)
MITOS DE GESTIN
Resistencia al cambio
Mitos del software:
- Uso de estndares
- Uso de herramientas
- Mala planificacin: aumento
de programadores
MITOS DE LOS DESARROLLADORES
MITOS DEL CLIENTE
- Programa funcionando = fin del trabajo

- Calidad = el programa se ejecuta
sin errores
- Entrega al cliente: programa
funcionando
- Requisitos establecidos como

una declaracin general de
objetivos
- Flexibilidad del software ante
los cambios

escuela superior de
6 / 41
la ingeniera del software

definiciones
establecimiento y uso de principios de ingeniera robustos,
orientados a obtener software econmico, fiable, eficiente y
que satisfaga las necesidades del usuario
disciplina que comprende todos los aspectos de la produccin
de software, desde las etapas iniciales hasta el
mantenimiento:
disciplina de ingeniera: aplicacin de teoras, mtodos y
herramientas para solucionar problemas, y teniendo en cuenta
restricciones financieras y organizativas
todos los aspectos de produccin: comprende procesos
tcnicos del desarrollo y actividades como la administracin de
proyectos, desarrollo de herramientas, mtodos y teoras
actividad de
modelado
solucin de problemas
adquisicin de conocimiento
dirigida por una fundamentacin

escuela superior de
7 / 41
la ingeniera del software

trata de ser la respuesta a la crisis del software

combinacin de elementos:
mtodos completos para

todas las fases
mejores tcnicas de
control de calidad
mejores elementos
de programacin
herramientas para automatizar

los mtodos
filosofa de coordinacin,
control
y buena gestin

escuela superior de
8 / 41
modelado
modelado: mtodo bsico de la ciencia

modelo
representacin abstracta de un sistema que da respuesta a
preguntas sobre el sistema
tiles cuando se manejan sistemas grandes, pequeos, complicados
o caros para tener una experiencia de primera mano
permiten visualizar y comprender sistemas que no existen o que slo
se supone que existen
ejemplos:
biologa: modelos de dinosaurios a partir de restos
fsica: modelos que representan cmo se renen materia y energa en los
niveles subatmicos ms bajos
el sistema en el mundo real seran dinosaurios o partculas subatmicas
modelos

escuela superior de
9 / 41
modelado
los ingenieros de software necesitan

comprender el ambiente de funcionamiento del sistema:
construyen modelos del dominio del problema (sistemas de
bolsa, control de trfico areo,...)
comprender los distintos sistemas que podran construir para
evaluar alternativas: construyen modelos del dominio de la
solucin
tcnicas y herramientas para construir los modelos (por
ejemplo, diagramas de UML)
SISTEMA DE PAGOS Y
FACT URACIN
Solicitar bienes o servicios
iniciador
Confirmar pedido
iniciador
<<subsistema>>
Enviar factura al comprador
Sistema de
visin
iniciador
Hojear facturas
iniciador
<<subsistema>>
Pagar factura
Vendedor
Comprador
<<subsistema>>
Controlador del
brazo
<<extend>>
iniciador
<<subsistema>>
Realizar transaccin
<<subsistema>>
Controlador del
asidero
Sistema de identificacin
de objetos
Pagar recargo por saldo deudor
Sistema de
cuentas bancarias
Planificar pago
factura
Rechazar
factura
<<subsistema>>
Enviar aviso

Pagar factura en da
vencimiento
<<subsistema>>
Sistema de seleccin
de embalajes
escuela superior de
<<subsistema>>
<<subsistema>>
Sistema de
embalaje
Controlador de cinta
transportadora
10 / 41
solucin de problemas
los ingenieros de software buscan una solucin adecuada, en varios pasos:

1.
Formular el problema
2.
Analizar el problema
3.
Buscar soluciones
4.
Decidir la solucin ms adecuada
5.
Especificar la solucin
actividades bsicas del desarrollo

1.
obtencin de requerimientos
2.
anlisis
3.
diseo del sistema
4.
implementacin
otras actividades del desarrollo para evaluar la adecuacin de los modelos

revisiones del anlisis: el modelo del dominio del problema se compara con la
realidad del cliente
revisiones del diseo: el modelo del dominio de la solucin se compara con los
objetivos del proyecto
pruebas: el sistema se valida contra el modelo del dominio de la solucin
administracin del proyecto: se compara el modelo del proceso de desarrollo
(calendario y presupuesto) con la realidad (trabajos entregados y recursos
gastados)

escuela superior de
11 / 41
participantes y papeles
participantes: todas las personas involucradas en el

proyecto
cliente: encarga y paga el sistema
desarrolladores: construyen el sistema (analistas,
diseadores, 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

escuela superior de
12 / 41
otros conceptos de la ingeniera del software

sistemas y modelos
sistema: realidad subyacente
modelo: cualquier abstraccin 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 revisin de la estructura de la base de datos, resultados de pruebas para el
gerente,...)
entrega: producto de trabajo para un cliente (especificacin de requisitos, manual de
usuario, producto final,...)
actividades, tareas y recursos

actividad (o fase): conjunto de tareas que se realiza con un propsito especfico
(obtencin de requisitos, entrega, administracin,...) 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

escuela superior de
13 / 41

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
caractersticas que debe tener el sistema
requerimiento funcional: rea de funcionalidad que debe
soportar el sistema (por ejemplo, proporcionar billetes de tren)
requerimiento no funcional: restriccin que se establece sobre
el funcionamiento del sistema (por ejemplo, proporcionar
billetes de tren en menos de un segundo)
otras restricciones: por ejemplo, utilizacin de un

determinado lenguaje, de una determinada plataforma o de
un sistema antiguo que el cliente no quiere retirar

escuela superior de
14 / 41

notaciones, mtodos y metodologas

notacin: conjunto de reglas grficas o de texto para
representar un modelo (UML, Unified Modelling Language, es
una notacin grfica orientada a objetos para representar
modelos)
mtodo: tcnica repetible para resolver un problema
especfico. Por ejemplo:
un algoritmo de ordenacin es un mtodo para ordenar
elementos en una lista
la administracin de la configuracin es un mtodo para el
seguimiento de los cambios
metodologa: coleccin de mtodos para la resolucin de una

clase de problemas (OMT, metodologa de Booch, Catalysis,
Proceso Unificado de Desarrollo,...)

escuela superior de
15 / 41
actividades de desarrollo
ingeniera de requerimientos
ReservaBilletes
Viajero
el cliente y los desarrolladores

definen el propsito y objetivos
del sistema
resultado: descripcin del
sistema en trminos de
participantes (actores) y
funciones (casos de uso)
CompraBillete
Anulacin reserva
Nombre del caso de uso:

CompraBillete
Nombre del caso de uso:
CompraBillete
Actor participante:
Iniciado por Viajero
Actor participante:
Iniciado por Viajero
Precondicin:
1.Precondicin:
El Viajero se para frente al distribuidor automtico de billetes
1. El Viajero se para frente al distribuidor automtico de billetes
Flujo de eventos:
de eventos:
2.Flujo
El Viajero
selecciona las estaciones de origen y destino
2.
El
Viajero
selecciona lasmuestra
estaciones
de origen
y destino
3. El DistribuidorDeBilletes
el precio
del billete
3.
El
DistribuidorDeBilletes
muestra
el
precio
del
4. El Viajero inserta una cantidad de dinero que, albillete
menos, debe
4. igual
El Viajero
inserta
ser
que el
preciouna
del cantidad
billete de dinero que, al menos, debe
igual que el precio del emite
billeteel billete especificado al Viajero y
5.ser
El DistribuidorDeBilletes
5. El DistribuidorDeBilletes
emite el billete especificado al Viajero y
devuelve
el cambio si es necesario
devuelve el cambio si es necesario
Postcondicin:
6.Postcondicin:
El Viajero coge el billete y el cambio
6. El Viajero coge el billete y el cambio
Requisitos especiales:
especiales:
SiRequisitos
la transaccin
no ser termina despus de un minuto de
Si
la
transaccin
no ser termina despus
de un
de
inactividad, el DistribuidorDeBilletes
devuelve
todominuto
el dinero
inactividad,
el
DistribuidorDeBilletes
devuelve
todo
el
dinero
insertado
insertado
actores: entidades externas

que interactan con el sistema
(incluyen roles como usuarios
finales u otros sistemas con
los que interacta el sistema)
casos de uso: secuencias de
eventos que describen todas
las acciones posibles entre un
actor y el sistema para una
funcin especfica.
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 despus de
seleccionada la transaccin
escuela superior de
16 / 41
anlisis
se produce un modelo correcto, completo, consistente, claro,
realista y verificable
transformacin de los casos de uso en un modelo que
describe por completo el sistema y que se usar en el diseo
descubrimiento y resolucin con el cliente de ambigedades
e inconsistencias en el modelo de casos de uso
Transaccin
Transaccin
da como resultado
da como resultado
cantidad pagada
cantidad pagada
BilleteTren
BilleteTren
Saldo
Saldo
vlido para
vlido para
Moneda
Moneda

Papel
Papel
Zona
Zona
escuela superior de
17 / 41
diseo
diseo del sistema
Gestin
Gestin facturas
facturas
comprador
comprador
Gestin
Gestin de
de
cuentas
cuentas
Gestin
Gestin de
de planificacin
planificacin
de
de pagos
pagos
definicin de los objetivos de diseo

descomposicin del sistema en subsistemas
abordables por equipos
seleccin de estrategias para la construccin
(plataformas hardware y software,
almacenamiento de datos persistentes, control
de acceso,...)
resultado: descripcin de las estrategias,
descomposicin en subsistema
diseo de objetos:
definicin de objetos e interfaces de
subsistemas, reestructuracin del modelo de
objetos para lograr los objetivos de diseo,
optimizacin del modelo para mejorar el
rendimiento,...
resultado: modelo de objetos detallado
IU
IU Solicitud
Solicitud
de
de pago
pago
Comprador
Comprador
Procesamiento
Procesamiento de
de
solicitudes
solicitudes de
de pago
pago
Planificador
Planificador
de
de pagos
pagos
Solicitud
Solicitud
de
de pago
pago
Gestor
Gestor de
de
pedidos
pedidos
Confirmacin
Confirmacin
de
de pedidos
pedidos
Procesamiento
Procesamiento
de
de facturas
facturas
Factura
Factura

actividades del diseo

diseo arquitectnico
especificacin de los subsistemas
diseo de interfaz
diseo de componentes
diseo de la estructura de datos
diseo procedimental (algoritmos)
escuela superior de
18 / 41
<<subsystem>>
Gestin Trabajos
Externos
<<subsystem>>
Gestin Mantenimiento
Correctivo
<<subsystem>>
Gestin Sistema
<<subsystem>>
Mantenimientos
de Gestin
<<subsystem>>
Validacin
Usuarios
<<subsystem>>
Preventivo
<<subsystem>>
Gestin
Instalaciones
<<subsystem>>
Gestin
Subgrupos-Instalaciones
<<subsystem>>
Gestin Mquinas
Subgrupo

escuela superior de
19 / 41
<<subsystem>>
Gestin Trabajos
Externos
<<subsystem>>
Gestin Sistema
Alta Instalaciones
<<include>>
<<subsystem>>
Mantenimientos
de Gestin
<<include>>
Baja Instalaciones
<<include>>
<<subsystem>>
Validacin
Usuarios
<<subsystem>>
Correctivo
<<subsystem>>
Preventivo
<<subsystem>>
Gestin
Instalaciones
<<subsystem>>
Gestin
Subgrupos-Instalaciones
<<subsystem>>
Gestin Mquinas
Subgrupo
Validar Usuario
Administrador
<<include>>
(from Validacin Usuarios)
Modificacin Instalaciones
Consulta Instalaciones
Operario
(from Vali dacin Usuarios)
<<subsystem>>
Gestin
Mquinas
Alta Caractersticas-Maq
<<include>>
<<include>>
Baja Caractersticas-Maq
Gestin Caractersticas
Mquinas
<<include>>
Gestin Tareas
Mquinas
Validar Usuario
Administrador
<<include>>
(from Validacin Usuari os)
Modificacin Caractersticas-Maq
Operario
Consulta Caractersticas-Maq

escuela superior de
20 / 41

Nombre
Prioridad
Actor
Extends
Includes
Pre-Condiciones
Post-Condiciones
Descripcin
Excepciones
Alta Caractersticas Mquina

Media
Administrador
Ninguno
Validar Usuario
1. El usuario est identificado.
2. El usuario selecciona la opcin de altas en el
formulario.
1. Los datos de la nueva caracterstica quedan
guardados si el proceso finaliza correctamente.
2. Los datos de la nueva caracterstica no quedan
guardados si se produce algn error durante el
proceso.
1. El sistema muestra el formulario de altas.
2. El usuario introduce los datos.
3. El sistema realiza la validacin de los datos.
4. Si la caracterstica ya existe [A].
5. Si los datos no son correctos [B].
6. El usuario selecciona la opcin de Guardar.
7. El sistema guarda los datos.
8. Si se guarda correctamente se visualiza un mensaje,
si hay algn problema el sistema avisa con un
mensaje de error.
El proceso se puede cancelar en cualquier momento.
A. Si la caracterstica ya existe se visualizan sus datos.
B. Datos incorrectos, ir a punto 2.
: Administrador
Opciones Frm
Cliente
CT RL Alta
Instalacin
Form_Alta
Validar
Datos
INSTALACION
Resultado Alta
MENSAJES
Selecci onar
Crea()
Crea()
Mostrar
Introducir Datos()
Comprobar()
...
Obtener Datos
Mostrar(Datos)
Si no Existe
Cubrir_Datos()
Comprobar()
Datos Correctos Crear_Alta()
<<include>>
Construir
<<include>>
Visualizar Resultado
<<include>>
Validar Usuario
Administrador
<<include>>
Datos no Correctos
Construir
(from Vali dacin Usuari os)
Visualizar Mensaje
Fin Si
Fin Si
Operario

escuela superior de
21 / 41

Nombre
Prioridad
Actor
Extends
Includes
Pre-Condiciones
Post-Condiciones
Descripcin
Excepciones
Alta Caractersticas Mquina

Media
Administrador
Ninguno
Validar Usuario
1. El usuario est identificado.
2. El usuario selecciona la opcin de altas en el
formulario.
1. Los datos de la nueva caracterstica quedan
guardados si el proceso finaliza correctamente.
2. Los datos de la nueva caracterstica no quedan
guardados si se produce algn error durante el
proceso.
1. El sistema muestra el formulario de altas.
2. El usuario introduce los datos.
3. El sistema realiza la validacin de los datos.
4. Si la caracterstica ya existe [A].
5. Si los datos no son correctos [B].
6. El usuario selecciona la opcin de Guardar.
7. El sistema guarda los datos.
8. Si se guarda correctamente se visualiza un mensaje,
si hay algn problema el sistema avisa con un
mensaje de error.
El proceso se puede cancelar en cualquier momento.
A. Si la caracterstica ya existe se visualizan sus datos.
B. Datos incorrectos, ir a punto 2.
Sistema (from Validar Usuario)
Administrador (from Alta Mquinas)
Administrador Validado
Visualizar
Formulario
Seleccionar
Formulario
Comprobar
Datos
Introducir
Datos
Datos Incorrectos
Mensaje "Error
Datos"
Datos Correctos
Comprobar Existencia
de la Instalacin
Si Existe
Visualizar Datos
Instalacin
No Existe
Seleccionar
Guardar
Guardar Datos
Instalacin
<<include>>
<<include>>
Error al Guardar
<<include>>
Mensaje
"Error"
Instalacin Guardada
Validar Usuario
Administrador
<<include>>
(from Vali dacin Usuari os)
Mensaje "Instalacin
guardada"
Operario

escuela superior de
22 / 41
Registra-venta-de
Descrita-por
1
0..1
Especificacion
DelProducto
Contiene
descripcin
1
1..n precio
articuloID
1
Utilizado-por
n
CatalogoDe
Productos
LineaDeVenta
cantidad
1..n
Contenida-en
Registra-completas
1
1
Venta
fecha
hora
1
Pagada-mediante
1
Pago
cantidad
Capturada-en
1
Iniciada-por
1
Cliente

Abastece
1
1
Alberga
1..n
Registro 1
n
1
Tienda
direccin
nombre
Articulo
n
Iniciado-por
1..n
1 Encargado
1
Registra-ventas-en
1
Cajero
escuela superior de
23 / 41
ODBC
Servidor
SGBD
TCP/IP
TCP/IP
Red Local
Impresora
Cliente
TCP/IP
Cliente

escuela superior de
24 / 41

escuela superior de
25 / 41
implementacin
traduccin del modelo de diseo (por ejemplo, del modelo de objetos) en
cdigo fuente
incluye:
implementacin de atributos y mtodos de cada objeto
integracin de todos los objetos para que funcionen como un solo sistema
pruebas
pruebas de unidad: comparacin del modelo de diseo con cada objeto
y subsistema
pruebas de integracin: combinaciones de subsistemas y comparacin
con el modelo de diseo del sistema
pruebas del sistema: ejecucin de casos tpicos y excepcionales, y
comparacin 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,...)
correccin de errores
adaptacin a cambios en el entorno (hardware, software, legislacin,...)
actividad ms costosa del ciclo de vida de un producto software

escuela superior de
26 / 41
actividades de administracin del desarrollo

comunicacin
actividad crtica y costosa en tiempo
intercambio de modelos y documentos, informes de evolucin
y calidad, negociaciones, comunicacin de decisiones,...
herramientas y notaciones
gestin de la configuracin
proceso que supervisa y controla los cambios en los productos
de trabajo
cambios: requerimientos, plataformas hardware y software,
errores encontrados, mejoras del sistema,...
administracin del proyecto

objetivo: asegurar la entrega de un sistema de alta calidad a
tiempo y dentro del presupuesto
planificacin y presupuesto del proyecto
contratacin de desarrolladores y coordinacin de equipos
vigilancia de la evolucin del proyecto
deteccin de desviaciones e intervencin

escuela superior de
27 / 41
el proceso de desarrollo

escuela superior de
28 / 41
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
caractersticas
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 construccin 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
Proceso de desarrollo
de Software

Sistema software
escuela superior de
29 / 41
modelo en cascada
Requerimentos
y Anlisis
Diseo
Implementacin
Pruebas
Mantenimiento
resultado de cada fase: uno o ms

documentos aprobados
se retrasa la localizacin y correccin

de errores
una fase comienza cuando la anterior

termina
pueden producir sistemas poco tiles

para usuarios o mal estructurados
en la prctica, las etapas se solapan
inflexibilidad del modelo: dificultad

para responder a cambios en los
requerimientos
iteraciones de coste elevado y

reelaboracin del trabajo: tendencia a
la congelacin de partes del desarrollo
(especificaciones,...)
escuela superior de
30 / 41
desarrollo evolutivo
dos tipos:
basado en:
desarrollo de una implementacin inicial
exposicin a comentarios y crtica del
usuario
refinamiento a travs de diferentes
versiones hasta llegar a un sistema
adecuado
trabajo con cliente para explorar

sus requerimientos y entregar un
sistema final
evolucin continua del prototipo
mediante la agregacin de
funciones y caractersticas
propuestas por el cliente
prototipos desechables
Recoleccin
y refinamiento de
requisitos
Producto
prototipado evolutivo:
Diseo
rpido
comprensin de las necesidades

del cliente
desarrollo de una definicin
mejorada de los requerimientos
del sistema
prototipos centrados en la
experimentacin de requisitos
poco claros o complejos
problemas
Refinamiento
del prototipo
Construccin
del prototipo
Evaluacin del
prototipo por
el cliente

prisas del cliente (utilizacin del

prototipo como sistema final
pasar elecciones debidas al prototipo a
la implementacin final (entorno,
sistema operativo,...)
estructura deficiente
evolucin del proceso difcil de gestionar
herramientas y tcnicas especiales
poco adecuado para grandes sistemas
escuela superior de
31 / 41
prototipado con lenguajes visuales

Hypertext
displaycomponent
Datecomponent
File
Edit
Views
12thJanuary2000
Rangechecking
script
Layout
Options
Help
General
Index
3.876
Userprompt
component+
script
Drawcanvas
component
Treedisplay
component
fuente: I. Sommerville, Software Engineering, 6th ed.,2000

escuela superior de
32 / 41
desarrollo incremental
Definicin general de
requerimientos
Asignacin de requerimientos
a incrementos
Diseo de la arquitectura del

sistema
Desarrollo de incrementos
del sistema
Validar
incrementos
Integrar
incrementos
Validar
sistema
pasos
identificacin y priorizacin de funciones y
servicios
definicin de varios requerimientos que
proporcionan parte de la funcionalidad, segn la
prioridad (los ms importantes se entregan
antes)
definicin detallada de requerimientos del
incremento y desarrollo con el proceso ms
adecuado
congelacin de requerimientos de incrementos
desarrollados
puesta en explotacin de los incrementos
completados y entregados
ventajas
puesta en marcha temprana
los incrementos iniciales permiten refinar
requerimientos de incrementos posteriores
satisfaccin del cliente (bajo riesgo de fallo)
sistema final muy probado y con pocos fallos
sistema incompleto
sistema completo
problemas
incrementos relativamente pequeos
adaptacin de requerimientos a incrementos del
tamao apropiado
Sistema final

identificacin de recursos comunes a todos los

incrementos
escuela superior de
33 / 41
modelo en espiral
propuesto por Barry

Boehm
organizacin en ciclos
PROGRESO
A TRAVS
DE LAS ITERACIONES
DETERMINAR
OBJETIVOS,
ALTERNATIVAS Y
RESTRICCIONES
EVALUAR ALTERNATIVAS,
IDENTIFICAR Y
RESOLVER RIESGOS
Anlisis de riesgos
primer ciclo: factibilidad

segundo ciclo:
requerimientos
Anlisis de riesgos
tercer ciclo: diseo

...
Anlisis de riesgos
cada ciclo se divide en 4

sectores
REVISIN
definicin de objetivos,
restricciones del producto
y proceso, plan de
administracin,...
.Plan de
requerimientos
Plan de ciclo
de vida
evaluacin y reduccin de
riesgos (por ejemplo,
mejor definicin de
requerimientos mediante
prototipos)
desarrollo y validacin:
eleccin de un modelo
para el desarrollo
planificacin: el proyecto
se revisa y se decide si se
contina con el siguiente
ciclo. si es as, se planifica
la siguiente fase

Plan de
desarrollo
Plan de integracin
y prueba
An.
Riesgo.
Prototipo 1
Prototipo
operativo
Prototipo 3
Prototipo 2
Concepto de
operacin
Requerimientos
de software
Validacin de
requerimientos
Simulaciones, modelos,
pruebas comparativas
Diseo del
producto
Diseo
detallado
Codificar
Diseo de validacin
y verificacin
PLANIFICAR SIGUIENTE
FASE
Explotacin
Prueba de
aceptacin
Prueba de
unidad
Prueba de
integracin
DESARROLLAR, VERIFICAR
PRODUCTO DE SIGUIENTE NIVEL
escuela superior de
34 / 41
el proceso unificado de desarrollo

proceso unificado de desarrollo

propuesto por los autores de UML (lenguaje unificado de
desarrollo)
basado en componentes interconectados a travs 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
Proceso de desarrollo
de Software

Sistema software
escuela superior de
35 / 41
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 interactan con el que estamos desarrollando
interaccin:
Retirar dinero
usuario inserta tarjeta en cajero automtico

usuario responde sobre la pantalla a las preguntas que realiza el
cajero
el usuario recibe una cantidad de dinero y su tarjeta
una interaccin as es un caso de uso

Cliente del banco
Ingresar dinero
fragmento de funcionalidad del sistema que proporciona al usuario un

resultado importante
utilidad casos de uso

Transferencia entre cuentas
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
guan el proceso de desarrollo (diseo, implementacin y prueba)
basndose en el modelo de casos de uso, se crean modelos de diseo
e implementacin
se revisa cada modelo para que sean conformes al modelo de casos
de uso
se prueba la implementacin para garantizar que los componentes del
modelo de implementacin implementan correctamente los casos de
uso
no slo inician el proceso de desarrollo sino que ste sigue un

hilo de trabajo que parte de los casos de uso

escuela superior de
36 / 41
el proceso unificado: centrado en la arquitectura

la arquitectura de un sistema software se describe

mediante diferentes vistas del sistema en
construccin
casos
casos de
de
uso
uso
influida por diversos factores
conduce
gua
necesidades de la empresa, tal y como las perciben los

usuarios y clientes
otros factores, como plataforma de explotacin
(arquitectura hardware, sistema operativo, gestor de
bases de datos, protocolos de comunicacin,...),
componentes reutilizables, sistemas heredados, requisitos
no funcionales,...
arquitectura
arquitectura
Capa especfica
de la aplicacin
Capa general de la
aplicacin
es una vista del diseo completo con las caractersticas

ms importantes resaltadas, dejando los detalles de
lado.
hay una constante interaccin entre los casos de uso y
la arquitectura, que evolucionan en paralelo
los casos de uso deben encajar en la arquitectura cuando
se realizan
la arquitectura debe permitir el desarrollo de todos los
casos de uso requeridos
el arquitecto
Capa
intermedia
Capa de software
del sistema

realiza un esquema en borrador de la arquitectura que no

es especfica de los casos de uso (por ejemplo, la
plataforma)
trabaja con un subconjunto de los casos de uso
principales del sistema, especificndolo en detalle y
realizndolo en trminos de subsistemas, clases y
componentes
a medida que los casos de uso se especifican y maduran,
se descubre ms de la arquitectura, lo que a su vez lleva a
la maduracin de ms casos de uso
este proceso contina hasta que se considera que se
dispone de una arquitectura estable
escuela superior de
37 / 41
el proceso unificado: iterativo e incremental

el trabajo se divide en partes ms pequeas o miniproyectos

miniproyecto: una iteracin que resulta en un incremento
iteracin: pasos en el flujo de trabajo
incremento: crecimiento del producto
las iteraciones estn controladas y planificadas
factores para seleccionar lo que se implementar en una iteracin

la iteracin se centra en un grupo de casos de uso que juntos amplan la utilidad del producto
desarrollado hasta ahora
la iteracin trata los riesgos ms importantes
las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como
quedaron al final de la ltima iteracin
en las primeras fases del ciclo de vida los incrementos implican modificaciones
en las ltimas fases los incrementos implican menos modificaciones y ms aadidos a los
modelos
para cada iteracin:

identificacin y especificacin de los casos de uso relevantes
creacin de un diseo utilizando la arquitectura seleccionada como gua
implementacin del diseo mediante componentes
verificacin de que los componentes satisfacen los casos de uso
si una iteracin cumple con sus objetivos, el desarrollo contina con la siguiente iteracin. Si
no, se revisan las decisiones previas y se adopta un nuevo enfoque
ventajas proceso iterativo controlado

reduccin del coste del riesgo a los costes de un solo incremento
reduccin 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

escuela superior de
38 / 41
la vida del proceso unificado

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

cada ciclo concluye con una versin del producto y consta de cuatro
fases
inicio: descripcin del producto final a partir de una idea inicial y anlisis
de negocio para el producto
principales funciones del sistema y usuarios ms importantes (modelo de casos de

uso)
posible arquitectura del sistema
plan del proyecto, coste, identificacin y priorizacin de riesgos
elaboracin:
se especifican en detalle los principales casos de uso

se disea la arquitectura del sistema: vistas arquitectnicas del modelo de casos
de uso, del modelo de anlisis, del modelo de diseo, del modelo de
implementacin y modelo de despliegue
al final se pueden planificar las actividades y estimar recursos necesarios para
finalizar el proyecto
construccin:
se crea el producto aadiendo el software a la arquitectura

al final se dispone de todos los casos de uso acordados para el desarrollo aunque
puede incorporar defectos
transicin
periodo durante el cual el producto se convierte en versin beta, en la que usuarios

prueban el producto e informan de defectos y deficiencias
se corrigen problemas e incorporan sugerencias
incluye actividades como la formacin del usuario, proporcionar una lnea de ayuda
y asistencia,...
cada fase se divide a su vez en iteraciones

escuela superior de
39 / 41
la vida del proceso unificado

Fases
Flujos de trabajo
fundamentales
Inicio
Construccin
Elaboracin
Transicin
Requisitos
una iteracin en la
fase de elaboracin
Anlisis
Diseo
Implementacin
Prueba
iter #1
iter #2
---
---
---
---
---
iter #n-1
Iteraciones
escuela superior de
40 / 41
iter #n
bibliografa
Bruegge, B., Dutoit, A.H., Ingeniera 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., Ingeniera del Software. Un enfoque prctico, cap. 1 y 2
Sommerville, I., Ingeniera de Software, cap. 1, 2 y 3

escuela superior de
41 / 41

Apuntes 2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apuntes 2

Transféré par

Droits d'auteur :

Formats disponibles

tema 1 introduccin a la ingeniera

caractersticas y evolucin del software

dcada de los ochenta:

objetivo actual: mejorar la calidad de las soluciones software.

AUMENTAN los problemas del desarrollo de software:

enrique barreiro alonso

caractersticas y evolucin del software

enrique barreiro alonso

caractersticas y evolucin del software

El software desde una perspectiva industrial

El desarrollo del software:

enrique barreiro alonso

naturaleza y problemas del desarrollo de software

El software como elemento lgico.

Se deteriora con el mantenimiento

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

Sin tiempo para recoger

naturaleza y problemas del desarrollo de software

Causas de la crisis del software

MITOS DE LOS DESARROLLADORES

MITOS DEL CLIENTE

- Programa funcionando = fin del trabajo

- Requisitos establecidos como

enrique barreiro alonso

la ingeniera del software

enrique barreiro alonso

la ingeniera del software

trata de ser la respuesta a la crisis del software

mtodos completos para

herramientas para automatizar

enrique barreiro alonso

modelado: mtodo bsico de la ciencia

enrique barreiro alonso

los ingenieros de software necesitan

Enviar factura al comprador

Pagar recargo por saldo deudor

enrique barreiro alonso

los ingenieros de software buscan una solucin adecuada, en varios pasos:

Decidir la solucin ms adecuada

actividades bsicas del desarrollo

diseo del sistema

otras actividades del desarrollo para evaluar la adecuacin de los modelos

enrique barreiro alonso

participantes: todas las personas involucradas en el

enrique barreiro alonso

otros conceptos de la ingeniera del software

actividades, tareas y recursos

enrique barreiro alonso

otros conceptos de la ingeniera del software

objetivos, requerimientos y restricciones

otras restricciones: por ejemplo, utilizacin de un

enrique barreiro alonso

otros conceptos de la ingeniera del software

notaciones, mtodos y metodologas

metodologa: coleccin de mtodos para la resolucin de una

enrique barreiro alonso

el cliente y los desarrolladores

Nombre del caso de uso:

actores: entidades externas

enrique barreiro alonso

definicin de los objetivos de diseo

enrique barreiro alonso

actividades del diseo