Introduccion Ingdelsoftware2

introducción a la ingeniería del software
características y evolución
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
1959 - 1965 1965
 objetivo actual: - 1975
mejorar 1975 - 1989
la calidad de lassoluciones software. 1989 -
Sistemas distribuidos  Potentes sistemas
 Orientación  Multiusuario  Inteligencia Artificial de sobremesa
por lotes
 Tiempo real  Hardware de bajo  Tecnología de objetos
 Distribución
 Bases de datos
 Software como
coste  Sistemas expertos
limitada  Impacto en el  Redes neuronales
producto
 Software a  Mayores gastos
consumo  Cliente/servidor
 Redes area local  Tecnologías de
medida de mantenimiento
y global Internet.
 Gran 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
escuela superior de ingeniería informática
ingeniería del software de gestión
del software
 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

del software
 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
ingeniería del software de gestión 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, ...) MITOS DE GESTIÓN
 - Uso de estándares
Ausencia de entrenamiento formal en nuevas técnicas
- Uso de herramientas
(programadores vs. ingenieros de software) - Mala planificación: aumento
de programadores
 Resistencia al cambio
 Mitos
MITOSdel software:
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
escuela superior de ingeniería informática 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
SISTEMA DE PAGOS Y
FACT URACIÓN alternativas: construyen modelos del dominio de la solución
Solicitar bienes o servicios
 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)
 actores: entidades externas que
Anulación reserva
interactúan con el sistema (incluyen
roles como usuarios finales u otros
sistemas con los que interactúa el
Nombre del caso de uso: CompraBillete sistema)
Actor participante: Iniciado por Viajero  casos de uso: secuencias de eventos
que describen todas las acciones
Precondición: posibles entre un actor y el sistema
1. El Viajero se para frente al distribuidor automático de billetes para una función específica.
Flujo de eventos:
 se acuerdan requisitos no
2. El Viajero selecciona las estaciones de origen y destino funcionales. Por ejemplo:
3. El DistribuidorDeBilletes muestra el precio del billete
4. El Viajero inserta una cantidad de dinero que, al menos, debe
 el distribuidor de billetes debe estar
disponible al menos un 95% del
ser igual que el precio del billete tiempo
5. El DistribuidorDeBilletes emite el billete especificado al Viajero y
devuelve el cambio si es necesario  el distribuidor de billetes debe dar
respuesta en menos de un segundo
Postcondición: después de seleccionada la
6. El Viajero coge el billete y el cambio transacción
Requisitos
escuela superior deespeciales:
ingeniería informática
Si la del
ingeniería transacción
software no ser termina después de un minuto de
de gestión
inactividad, 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
Transacción
diseño
da como resultado
 descubrimiento y resolución con el cliente de
cantidad pagada
ambigüedades e inconsistencias en el modelo de casos de
BilleteTren
uso Saldo
válido para
Zona
Moneda Papel

diseño 
 diseño del sistema
Gestión facturas
 definición de los objetivos de diseño
comprador
 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 de planificación Gestión de  resultado: descripción de las estrategias, descomposición en
de pagos cuentas 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
IU Solicitud rendimiento,...
de pago
 resultado: modelo de objetos detallado
Comprador
Procesamiento de
solicitudes de pago
 actividades del diseño
 diseño arquitectónico
Planificador Gestor de
Procesamiento
de facturas
 especificación de los subsistemas
de pagos pedidos
 diseño de interfaz
 diseño de componentes
Solicitud Confi rmación Factura
de pago de pedidos
 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

<<include>>
Gestión
Máquinas <<include>>
Baja Características-Maq
<<include>>
Validar Usuario
Gestión Administrador
Características Gestión Tareas <<include>> (from Vali dación Usuari os)
Máquinas
(from Vali dación Usuari os)
Máquinas
Modificación Características-Maq
Consulta Características-Maq
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
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
<<include>> (from Validació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
<<include>> (from Validación Usuari os)
guardada"
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

Requisitos
 aportan Proceso
consistencia y estructura
del usuario sobre el de
conjunto de actividades, lo que Sistema
desarrollo permitesoftware
realizar la misma tarea correctamente de forma repetida
de Software
 existen diferentes modelos de proceso

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

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

desarrollo evolutivo
 basado en:
 desarrollo de una implementación inicial
dos tipos:
prototipado evolutivo:
 exposición a comentarios y crítica del trabajo con cliente para explorar sus
usuario requerimientos y entregar un sistema
final
 refinamiento a través de diferentes evolución continua del prototipo
versiones hasta llegar a un sistema mediante la agregación de funciones y
adecuado características propuestas por el cliente
prototipos desechables
comprensión de las necesidades del
Recolección cliente
y refinamiento de desarrollo de una definición mejorada de
requisitos los requerimientos del sistema
prototipos centrados en la
experimentación de requisitos poco claros
Producto o complejos
Diseño
rápido problemas
prisas del cliente (utilización del prototipo como
sistema final
pasar elecciones debidas al prototipo a la
implementación final (entorno, sistema
Refinamiento Construcción operativo,...)
del prototipo del prototipo estructura deficiente
evolución del proceso difícil de gestionar
herramientas y técnicas especiales
Evaluación del
poco adecuado para grandes sistemas
prototipo por
el cliente
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
definición de varios requerimientos que
a incrementos
proporcionan parte de la funcionalidad, según la
prioridad (los más importantes se entregan antes)
definición detallada de requerimientos del
Diseño de la arquitectura del incremento y desarrollo con el proceso más
sistema adecuado
congelación de requerimientos de incrementos
desarrollados
Desarrollo de incrementos
del sistema puesta en explotación de los incrementos
completados y entregados
ventajas
Validar
incrementos puesta en marcha temprana
los incrementos iniciales permiten refinar
Integrar requerimientos de incrementos posteriores
incrementos
satisfacción del cliente (bajo riesgo de fallo)
sistema final muy probado y con pocos fallos
Validar
sistema problemas
incrementos relativamente pequeños
sistema incompleto adaptación de requerimientos a incrementos del
tamaño apropiado
sistema completo
identificación de recursos comunes a todos los
incrementos
Sistema final
modelo en espiral
PROGRESO
propuesto por Barry Boehm A TRAVÉS
DETERMINAR DE LAS ITERACIONES
OBJETIVOS, EVALUAR ALTERNATIVAS,
organización en ciclos ALTERNATIVAS Y IDENTIFICAR Y
RESTRICCIONES RESOLVER RIESGOS
primer ciclo: factibilidad
Análisis de riesgos
segundo ciclo:
requerimientos
tercer ciclo: diseño
...
cada ciclo se divide en 4 Prototipo
operativo
sectores An. Prototipo 3
Riesgo.
Proto-
- Prototipo 2
definición de objetivos, REVISIÓN tipo 1
restricciones del producto y
proceso, plan de .Plan de Simulaciones, modelos,
requerimientos Concepto de pruebas comparativas
administración,... Plan de ciclo operación
de vida Requerimientos
evaluación y reducción de de software
riesgos (por ejemplo, mejor Diseño del Diseño
definición de requerimientos producto detallado
Plan de Validación de
mediante prototipos) desarrollo requerimientos
Codificar
desarrollo y validación: Plan de integración
elección de un modelo para y prueba Diseño de validación
y verificación Prueba de
el desarrollo PLANIFICAR SIGUIENTE unidad
FASE
planificación: el proyecto se Prueba de
integración
revisa y se decide si se Prueba de
continúa con el siguiente aceptación
-
Explotación
ciclo. si es así, se planifica la
DESARROLLAR, VERIFICAR
siguiente fase PRODUCTO DE SIGUIENTE NIVEL

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
Requisitos
centrado en la arquitectura Sistema software
del usuario Proceso de desarrollo
 de Software
iterativo e incremental

el proceso unificado: dirigido  para construir un sistema con éxito hay que conocer las necesidades y
por casos de uso 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
Retirar dinero
 usuario responde sobre la pantalla a las preguntas que realiza el cajero
 el usuario recibe una cantidad de dinero y su tarjeta
 una interacción 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
 herramienta para especificar los requisitos de un sistema: representan los
requisitos funcionales y juntos constituyen el modelo de casos de uso, que
Transferencia entre cuentas describe la funcionalidad total del sistema
 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
 la arquitectura de un sistema software se describe
casos de
uso mediante diferentes vistas del sistema en construcción
 influida por diversos factores
conduce  necesidades de la empresa, tal y como las perciben los
guía usuarios y clientes
 otros factores, como plataforma de explotación (arquitectura
hardware, sistema operativo, gestor de bases de datos,
arquitectura 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.
 hay una constante interacción entre los casos de uso y la
Capa específica arquitectura, que evolucionan en paralelo
de la aplicación
 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
Capa general de la
aplicación  el arquitecto
 realiza un esquema en borrador de la arquitectura que no es
específica de los casos de uso (por ejemplo, la plataforma)
Capa  trabaja con un subconjunto de los casos de uso principales del
intermedia 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, se
descubre más de la arquitectura, lo que a su vez lleva a la
Capa de software
maduración de más casos de uso
del sistema  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 software

 década de los ochenta:

AUMENTAN los problemas del desarrollo de software:

escuela superior de ingeniería informática

 El desarrollo del software:

 Se “deteriora” con el mantenimiento

Sin tiempo para recoger

 Causas de la crisis del software

escuela superior de ingeniería informática

métodos completos para

herramientas para automatizar

escuela superior de ingeniería informática

 técnicas y herramientas para construir los modelos (por ejemplo,

Planificar pago Rechazar

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

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

escuela superior de ingeniería informática

 participantes: todas las personas involucradas en el

 actividades, tareas y recursos

 al planificar, el gerente divide el trabajo en tareas y les asigna recursos

escuela superior de ingeniería informática

escuela superior de ingeniería informática

escuela superior de ingeniería informática

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

escuela superior de ingeniería informática

<<subsystem>> Alta Características-Maq

escuela superior de ingeniería informática

Alta Características-Maq Datos Correctos Crear_Alta()

Modificación Características-Maq Visualizar Mensaje

escuela superior de ingeniería informática

Si Existe Visualizar Datos

Alta Características-Maq Guardar Datos

<<include>> Error al Guardar Mensaje

escuela superior de ingeniería informática

TCP/IP Red Local Impresora

escuela superior de ingeniería informática

escuela superior de ingeniería informática

escuela superior de ingeniería informática

 utiliza recursos, está sujeto a restricciones y genera productos intermedios y finales

 compuesto por subprocesos que se encadenan de alguna forma

 existen principios orientadores que explican las metas de cada actividad

 cuando implica la construcción de un producto, se suele llamar ciclo de vida

escuela superior de ingeniería informática

resultado de cada fase: uno o más documentos se retrasa la localización y corrección de

escuela superior de ingeniería informática

File Edit Views Layout Options Help

fuente: I. Sommerville, Software Engineering, 6th ed.,2000

escuela superior de ingeniería informática

escuela superior de ingeniería informática

escuela superior de ingeniería informática

escuela superior de ingeniería informática

escuela superior de ingeniería informática

 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 trata los riesgos más importantes

 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

 ventajas proceso iterativo controlado