ingeniería del software de gestión. tema 1

tema 1 – introducción a la ingeniería del software

enrique barreirodepartamento de informática

universidade de vigo

escuela superior de ingeniería informáticaingeniería del software de gestión


© enrique barreiro alonsouniversidade de vigo - departamento de informática


2 / 41

características y evolución del software

un poco de historiaprimeras décadas:

desarrollar el hardwarereducir costes de procesamiento y almacenamiento

década de los ochenta:desarrollo de la microelectrónicamayor potencia de cálculo y reducción de costes

objetivo actual: mejorar la calidad de las soluciones software.

☯ Orientaciónpor lotes☯ Distribuciónlimitada☯ Software a medida

☯ Orientaciónpor lotes☯ Distribuciónlimitada☯ Software a medida

☯ Multiusuario☯ Tiempo real☯ Bases de datos☯ Software como producto☯ Mayores gastos de mantenimiento

☯ Multiusuario☯ Tiempo real☯ Bases de datos☯ Software como producto☯ Mayores gastos de mantenimiento

☯ Sistemas distribuidos☯ Inteligencia Artificial☯ Hardware de bajocoste☯ Impacto en el consumo☯ Redes area localy global☯ Gran demanda

☯ Sistemas distribuidos☯ Inteligencia Artificial☯ Hardware de bajocoste☯ Impacto en el consumo☯ Redes area localy global☯ Gran demanda

☯ Potentes sistemasde sobremesa☯ Tecnología de objetos☯ Sistemas expertos☯ Redes neuronales☯ Cliente/servidor☯ Tecnologías deInternet.

☯ Potentes sistemasde sobremesa☯ Tecnología de objetos☯ Sistemas expertos☯ Redes neuronales☯ Cliente/servidor☯ Tecnologías deInternet.

1959 - 1965 1965 - 1975 1975 - 1989 1989 -

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




3 / 41


softwareprogramas

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 softwareproductos genéricos

sistemas producidos por una organización y que se venden en el mercado abiertosistemas gestores de bases de datos, procesadores de texto, paquetes gráficos,...la organización controla la especificación

productos personalizadosdesarrollados específicamente para un clienteaplicaciones 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




4 / 41


El software desde una perspectiva industrialEl 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?




5 / 41

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íaGestió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 nuevasaplicaciones.

Insatisfacción del cliente

Planificación y estimacionesimprecisas

Calidad

Sin tiempo para recogerdatos históricos

Baja productividad

Dificultad de mantenerel software existente




6 / 41

naturaleza y problemas del desarrollo de software

Causas de la crisis del softwareNaturaleza 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)

Resistencia al cambio

Mitos del software:

MITOS DEL CLIENTE

- Requisitos establecidos comouna declaración general de

objetivos- Flexibilidad del software ante

los cambios

MITOS DE GESTIÓN

- Uso de estándares- Uso de herramientas

- Mala planificación: aumentode programadores

MITOS DE LOS DESARROLLADORES

- Programa funcionando = fin del trabajo- Calidad = el programa se ejecuta

sin errores- Entrega al cliente: programa

funcionando




7 / 41

la ingeniería del software

definicionesestablecimiento 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 demodeladosolución de problemasadquisición de conocimientodirigida por una fundamentación




8 / 41

la ingeniería del software

trata de ser la respuesta a la crisis del software

combinación de elementos:

filosofía de coordinación, control

y buena gestión

métodos completos paratodas las fases

mejores técnicas de control de calidad

mejores elementosde programación

herramientas para automatizarlos métodos




9 / 41

modelado

modelado: método básico de la ciencia

modelorepresentació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 restosfísica: modelos que representan cómo se reúnen materia y energía en los niveles subatómicos más bajosel sistema en el mundo real serían dinosaurios o partículas subatómicas

modelos




10 / 41

modelado

los ingenieros de software necesitancomprender 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óntécnicas y herramientas para construir los modelos (por ejemplo, diagramas de UML)

Re al i za r t ransa cció nPagar recargo por saldo deudor

Comprador

Sol ici ta r b iene s o servicios

Co nf i rmar p edido

Enviar factura al comprador

Sistema de cuentas bancarias

En viar aviso

iniciador

Vendedor

iniciador

iniciador

Pagar facturainiciador

SIST EMA DE PAGOS Y FACT URACIÓN

<<extend>>iniciador

Hojear facturas

Planificar pago factura

Rechazar factura

Pagar factura en día vencimiento

<<subsistema>>

Controlador del brazo

<<subsistema>>

Sistema de visión

<<subsistema>>

Sistema de identificación de objetos

<<subsistema>>

<<subsistema>>

Sistema de embalaje

<<subsistema>>Sistema de selección de embalajes

<<subsistema>>

Controlador del asidero

<<subsistema>>

Controlador de cinta transportadora

<<subsistema>>




11 / 41

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 desarrollo1. 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 modelosrevisiones 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)




12 / 41

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




13 / 41

otros conceptos de la ingeniería del software

sistemas y modelossistema: realidad subyacente

modelo: cualquier abstracción de la realidad

productos de trabajoartefacto 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 recursosactividad (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 humanosal planificar, el gerente divide el trabajo en tareas y les asigna recursos




14 / 41


objetivos, requerimientos y restriccionesobjetivos:

principios de alto nivel que se utilizan para guiar el proyectodefinen 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 sistemarequerimiento 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




15 / 41


notaciones, métodos y metodologíasnotació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 listala 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,...)




16 / 41

actividades de desarrollo

ingeniería de requerimientosel cliente y los desarrolladores definen el propósito y objetivos del sistemaresultado: descripción del sistema en términos de participantes (actores) y funciones (casos de uso)

actores: entidades externas que interactúan con el sistema (incluyen roles como usuarios finales u otros sistemas con los que interactúa el sistema)casos de uso: secuencias de eventos que describen todas las acciones posibles entre un actor y el sistema para una función específica.

se acuerdan requisitos no funcionales. Por ejemplo:

el distribuidor de billetes debe estar disponible al menos un 95% del tiempoel distribuidor de billetes debe dar respuesta en menos de un segundo después de seleccionada la transacción

Nombre del caso de uso: CompraBillete

Actor participante: Iniciado por Viajero

Precondición:1. El Viajero se para frente al distribuidor automático de billetes

Flujo de eventos:2. El Viajero selecciona las estaciones de origen y destino3. El DistribuidorDeBilletes muestra el precio del billete4. El Viajero inserta una cantidad de dinero que, al menos, debe ser igual que el precio del billete5. El DistribuidorDeBilletes emite el billete especificado al Viajero y devuelve el cambio si es necesario

Postcondición:6. El Viajero coge el billete y el cambio

Requisitos especiales:Si la transacción no ser termina después de un minuto de inactividad, el DistribuidorDeBilletes devuelve todo el dinero insertado

Nombre del caso de uso: CompraBillete

Actor participante: Iniciado por Viajero

Precondición:1. El Viajero se para frente al distribuidor automático de billetes

Flujo de eventos:2. El Viajero selecciona las estaciones de origen y destino3. El DistribuidorDeBilletes muestra el precio del billete4. El Viajero inserta una cantidad de dinero que, al menos, debe ser igual que el precio del billete5. El DistribuidorDeBilletes emite el billete especificado al Viajero y devuelve el cambio si es necesario

Postcondición:6. El Viajero coge el billete y el cambio

Requisitos especiales:Si la transacción no ser termina después de un minuto de inactividad, el DistribuidorDeBilletes devuelve todo el dinero insertado

ReservaBilletes

CompraBil leteViajero

Anulación reserva




17 / 41


análisisse produce un modelo correcto, completo, consistente, claro, realista y verificable

transformación de los casos de uso en un modelo que describe por completo el sistema y que se usará en el diseño

descubrimiento y resolución con el cliente de ambigüedades e inconsistencias en el modelo de casos de uso

Transacción

Moneda

BilleteTren

Zona

da como resultado

válido para

Saldo

cantidad pagada

Papel




18 / 41


diseñodiseño del sistema

definición de los objetivos de diseñodescomposición del sistema en subsistemas abordables por equiposselección de estrategias para la construcción (plataformas hardware y software, almacenamiento de datos persistentes, control de acceso,...)resultado: descripción de las estrategias, descomposición en subsistema

diseño de objetos: definición de objetos e interfaces de subsistemas, reestructuración del modelo de objetos para lograr los objetivos de diseño, optimización del modelo para mejorar el rendimiento,...resultado: modelo de objetos detallado

actividades del diseñodiseño arquitectónicoespecificación de los subsistemasdiseño de interfazdiseño de componentesdiseño de la estructura de datosdiseño procedimental (algoritmos)

Co mprado r

IU Solicitud de pago

Gestor de pedidos

Confirmación de pedidos

Planificador de pagos

Solicitud de pago

Procesamiento de solicitudes de pago

Procesamiento de facturas

Factura

Gestión facturas comprador

Gestión de planificación de pagos

Gestión de cuentas




19 / 41

Validación Usuarios

<<subsystem>>

Gestión Máquinas Subgrupo

<<subsystem>>

Gestión Subgrupos-Instalaciones

<<subsystem>>

Gestión Sistema<<subsystem>>

Gestión Instalaciones

<<subsystem>>

Mantenimientos de Gestión

<<subsystem>>

Gestión Mantenimiento Correctivo

<<subsystem>>

Gestión Trabajos Externos

<<subsystem>>

Gestión Mantenimiento Preventivo

<<subsystem>>




20 / 41

Validación Usuarios

<<subsystem>>

Gestión Máquinas Subgrupo

<<subsystem>>

Gestión Subgrupos-Instalaciones

<<subsystem>>

Gestión Sistema<<subsystem>>

Gestión Instalaciones

<<subsystem>>

Mantenimientos de Gestión

<<subsystem>>

Gestión Mantenimiento Correctivo

<<subsystem>>

Gestión Trabajos Externos

<<subsystem>>

Gestión Mantenimiento Preventivo

<<subsystem>>

Gestión Máquinas

<<subsystem>>

Gestión Carac teríst icas Máquinas

Gestión Tareas Máquinas

Alta Características-Maq

Baja Características-Maq

Modificación Características-Maq

Operario

(from Validación Usuarios)

Administrador

(f rom Vali dación Usuari os)

Validar Usuario

(f rom Validación Usuari os)

<<include>>

<<include>>

<<include>>

Consulta Características-Maq

<<include>>

Alta Instalaciones

Baja Instalaciones

Modificación Instalaciones

Operario


Administrador


Validar Usuario


<<include>>

<<include>>

<<include>>

Consulta Instalaciones

<<include>>




21 / 41




Operario

(from Valida ción Usuarios)

Administrador


Validar Usuario


<<include>>

<<include>>

<<include>>


<<include>>

Nombre Alta Características Máquina Prioridad Media Actor Administrador Extends Ninguno Includes Validar Usuario Pre-Condiciones 1. El usuario está identificado.

2. El usuario selecciona la opción de altas en el formulario.

Post-Condiciones 1. Los datos de la nueva característica quedan guardados si el proceso finaliza correctamente.

2. Los datos de la nueva característica no quedan guardados si se produce algún error durante el proceso.

Descripción 1. El sistema muestra el formulario de altas. 2. El usuario introduce los datos. 3. El sistema realiza la validación de los datos. 4. Si la característica ya existe [A]. 5. Si los datos no son correctos [B]. 6. El usuario selecciona la opción de Guardar. 7. El sistema guarda los datos. 8. Si se guarda correctamente se visualiza un mensaje,

si hay algún problema el sistema avisa con un mensaje de error.

Excepciones El proceso se puede cancelar en cualquier momento. A. Si la característica ya existe se visualizan sus datos. B. Datos incorrectos, ir a punto 2.

MENSAJES : A dmi nistra dor Opciones Frm Cliente

CTRL Alta Instalación

Form_Alta Validar Datos INSTALACION

Resultado Alta

Visualizar Mensaje

Seleccionar

Crea()

Mostrar(Datos)

Introducir Datos()

Cubrir_Datos()

Comprobar()

Comprobar()

Obtener Datos

Crear_Alta()

Construir

Construir

Visualizar Resultado

Crea()

Si no Existe

Fin S iFin S i

Datos Correctos

...

Datos no Correctos

Mostrar




22 / 41




Operario

(from Valida ción Usuarios)

Administrador


Validar Usuario


<<include>>

<<include>>

<<include>>


<<include>>

Nombre Alta Características Máquina Prioridad Media Actor Administrador Extends Ninguno Includes Validar Usuario Pre-Condiciones 1. El usuario está identificado.

2. El usuario selecciona la opción de altas en el formulario.

Post-Condiciones 1. Los datos de la nueva característica quedan guardados si el proceso finaliza correctamente.

2. Los datos de la nueva característica no quedan guardados si se produce algún error durante el proceso.

Descripción 1. El sistema muestra el formulario de altas. 2. El usuario introduce los datos. 3. El sistema realiza la validación de los datos. 4. Si la característica ya existe [A]. 5. Si los datos no son correctos [B]. 6. El usuario selecciona la opción de Guardar. 7. El sistema guarda los datos. 8. Si se guarda correctamente se visualiza un mensaje,

si hay algún problema el sistema avisa con un mensaje de error.

Excepciones El proceso se puede cancelar en cualquier momento. A. Si la característica ya existe se visualizan sus datos. B. Datos incorrectos, ir a punto 2.

Visualizar Formulario

Comprobar Datos

Mensaje "Error Datos"

Comprobar Existencia de la Ins talación

Visualizar Datos Instalación

Guardar Datos Instalación

Mensaje "Error"

Datos Incorrectos

Datos Correctos

Si Existe

Mensaje "Instalación guardada"

Administrador Validado

Seleccionar Formulario

Introducir Datos

Seleccionar Guardar

No Existe

Error al Guardar

Instalación Guardada

Administrador (from Alta Máquinas)Sistema (from Validar Usuario)




23 / 41

EspecificacionDelProducto

descripciónprecioarticuloID

CatalogoDeProductos

1..n1

Articulo

Encargado

LineaDeVenta

cantidad

1n

1..n

0..1

Tiendadirecciónnombre

n

1

n1

Pago

cantidad

Venta

fechahora

1

1..n

1

n

1

1

Cliente

1

1

Registro1..n

1

1111

Cajero

1

1

1

1

11

1

1Pagada-mediante

1

1

Iniciada-por Registra-ventas-en

Iniciado-por1..n

1Alberga

Abastece

n1

Capturada-en11

1

n

Registra-completas

Contenida-en

1

1..n Utilizado-porn

11..n1

Contiene

Descrita-por

1n

1..n

0..1

Registra-venta-de




24 / 41

Servidor SGBD

Red Local Impresora

Cliente

Cliente

ODBC

TCP/IP

TCP/IP

TCP/IP




25 / 41




26 / 41


implementacióntraducción del modelo de diseño (por ejemplo, del modelo de objetos) en código fuenteincluye:

implementación de atributos y métodos de cada objetointegración de todos los objetos para que funcionen como un solo sistema

pruebaspruebas de unidad: comparación del modelo de diseño con cada objeto y subsistemapruebas 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 sepuedan reparar antes de entregar el sistema

mantenimientomejoras en el sistema (nuevas funciones, facilidad de uso,...)corrección de erroresadaptación a cambios en el entorno (hardware, software, legislación,...)actividad más costosa del ciclo de vida de un producto software




27 / 41


actividades de administración del desarrollocomunicación

actividad crítica y costosa en tiempointercambio de modelos y documentos, informes de evolución y calidad, negociaciones, comunicación de decisiones,...herramientas y notaciones

gestión de la configuraciónproceso que supervisa y controla los cambios en los productos de trabajocambios: requerimientos, plataformas hardware y software, errores encontrados, mejoras del sistema,...

administración del proyectoobjetivo: asegurar la entrega de un sistema de alta calidad a tiempo y dentro del presupuestoplanificación y presupuesto del proyectocontratación de desarrolladores y coordinación de equiposvigilancia de la evolución del proyectodetección de desviaciones e intervención




28 / 41

el proceso de desarrollo




29 / 41

el proceso: modelos de desarrollo

procesoconjunto 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ísticastiene una serie de actividades principalesutiliza recursos, está sujeto a restricciones y genera productos intermedios y finalescompuesto por subprocesos que se encadenan de alguna formacada actividad tiene sus criterios de entrada y salida, que permiten conocer cuando comienza y termina dicha actividadexisten 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

Proceso de desarrollo de Software


Requisitosdel usuario Sistema software




30 / 41

modelo en cascada

Requerimentosy Análisis

Diseño

Implementación

Pruebas

Mantenimiento

resultado de cada fase: uno o más documentos aprobados

una fase comienza cuando la anterior termina

en la práctica, las etapas se solapan

iteraciones de coste elevado y reelaboración del trabajo: tendencia a la congelación de partes del desarrollo (especificaciones,...)

se retrasa la localización y corrección de errores

pueden producir sistemas poco útiles para usuarios o mal estructurados

inflexibilidad del modelo: dificultad para responder a cambios en los requerimientos




31 / 41

desarrollo evolutivo

Recoleccióny refinamiento de

requisitos

Diseñorápido

Producto

Refinamientodel prototipo

Evaluación delprototipo por

el cliente

Construccióndel prototipo

basado en: desarrollo de una implementación inicial

exposición a comentarios y crítica del usuario

refinamiento a través de diferentes versiones hasta llegar a un sistema adecuado

dos tipos:prototipado evolutivo:

trabajo con cliente para explorar sus requerimientos y entregar un sistema finalevolución continua del prototipo

mediante la agregación de funciones y características propuestas por el cliente

prototipos desechablescomprensión de las necesidades

del clientedesarrollo de una definición

mejorada de los requerimientos del sistemaprototipos centrados en la

experimentación de requisitos poco claros o complejos

problemasprisas del cliente (utilización del prototipo como sistema final

pasar elecciones debidas al prototipo a la implementación final (entorno, sistema operativo,...)

estructura deficiente

evolución del proceso difícil de gestionar

herramientas y técnicas especiales

poco adecuado para grandes sistemas




32 / 41

prototipado con lenguajes visuales

File Edit Views Layout Options Help

GeneralIndex

Hypertextdisplay componentDate component

Range checkingscript

Tree displaycomponent

12th January 2000

3.876

Draw canvascomponent

User promptcomponent +

script

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




33 / 41

desarrollo incremental

Definición general de requerimientos

Asignación de requerimientos a incrementos

Diseño de la arquitectura del sistema

Desarrollo de incrementos del sistema

Validar incrementos

Integrar incrementos

Validar sistema

Sistema final

sistema incompleto

sistema completo

pasosidentificación y priorización de funciones y servicios

definición de varios requerimientos que proporcionan parte de la funcionalidad, según la prioridad (los más importantes se entregan antes)

definición detallada de requerimientos del incremento y desarrollo con el proceso más adecuado

congelación de requerimientos de incrementos desarrollados

puesta en explotación de los incrementos completados y entregados

ventajaspuesta en marcha temprana

los incrementos iniciales permiten refinar requerimientos de incrementos posteriores

satisfacción del cliente (bajo riesgo de fallo)

sistema final muy probado y con pocos fallos

problemasincrementos relativamente pequeños

adaptación de requerimientos a incrementos del tamaño apropiado

identificación de recursos comunes a todos los incrementos




34 / 41

.Concepto de

operación

Análisis de riesgos

An.Riesgo.



-

PROGRESOA TRAVÉS

DE LAS ITERACIONES

DESARROLLAR, VERIFICARPRODUCTO DE SIGUIENTE NIVEL

-

Codificar

PLANIFICAR SIGUIENTEFASE

Simulaciones, modelos,pruebas comparativas

Plan de requerimientos

Plan de ciclo de vida

Plan dedesarrollo

Plan de integracióny prueba

REVISIÓNProto-tipo 1

Prototipo 2

Prototipo 3

Prototipooperativo

Requerimientosde software

Validación derequerimientos

Diseño delproducto

Diseño de validacióny verificación

Diseñodetallado

Prueba deunidad

Prueba deintegración

Prueba deaceptación

Explotación

EVALUAR ALTERNATIVAS,IDENTIFICAR Y RESOLVER RIESGOS

DETERMINAR OBJETIVOS,ALTERNATIVAS YRESTRICCIONES

modelo en espiral

propuesto por BarryBoehm

organización en ciclosprimer ciclo: factibilidad

segundo ciclo: requerimientos

tercer ciclo: diseño

...

cada ciclo se divide en 4 sectores

definición de objetivos, restricciones del producto y proceso, plan de administración,...

evaluación y reducción de riesgos (por ejemplo, mejor definición de requerimientos mediante prototipos)

desarrollo y validación: elección de un modelo para el desarrollo

planificación: el proyecto se revisa y se decide si se continúa con el siguiente ciclo. si es así, se planifica la siguiente fase




35 / 41

el proceso unificado de desarrollo

proceso unificado de desarrollopropuesto 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 definitoriosdirigido por casos de usocentrado en la arquitecturaiterativo e incremental



Requisitosdel usuario Sistema software




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

usuariopersonas que trabajan y necesitan el sistemaotros sistemas que interactúan con el que estamos desarrollando

interacción:usuario inserta tarjeta en cajero automáticousuario responde sobre la pantalla a las preguntas que realiza el cajeroel usuario recibe una cantidad de dinero y su tarjeta

una interacción así es un caso de usofragmento de funcionalidad del sistema que proporciona al usuario un resultado importante

utilidad casos de usoherramienta 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

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ónse revisa cada modelo para que sean conformes al modelo de casosde usose 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

Retirar dinero

Ingresar dineroCliente del banco

Transferencia entre cuentas




37 / 41

el proceso unificado: centrado en la arquitectura

la arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcción

influida por diversos factoresnecesidades de la empresa, tal y como las perciben los usuarios y clientesotros factores, como plataforma de explotación (arquitectura hardware, sistema operativo, gestor de 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.

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 realizanla arquitectura debe permitir el desarrollo de todos los casos de uso requeridos

el arquitectorealiza un esquema en borrador de la arquitectura que no es específica de los casos de uso (por ejemplo, la plataforma)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 componentesa 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 maduración de más casos de usoeste proceso continúa hasta que se considera que se dispone de una arquitectura estable

casos deuso

casos deuso

arquitecturaarquitectura

guíaconduce

Capa específica de la aplicación

Capa general de la aplicación

Capa intermedia

Capa de software del sistema




38 / 41

el proceso unificado: iterativo e incremental

el trabajo se divide en partes más pequeñas o miniproyectosminiproyecto: una iteración que resulta en un incremento

iteración: pasos en el flujo de trabajoincremento: crecimiento del productolas iteraciones están controladas y planificadas

factores para seleccionar lo que se implementará en una iteraciónla iteración se centra en un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahorala 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 modificacionesen 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 relevantescreación de un diseño utilizando la arquitectura seleccionada como guíaimplementación del diseño mediante componentesverificación de que los componentes satisfacen los casos de usosi 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 controladoreducción del coste del riesgo a los costes de un solo incrementoreducción del riesgo de no sacar al mercado el producto en el calendario previstose acelera el ritmo del esfuerzo de desarrollo en su totalidad, para obtener resultados claros a corto plazolos requerimientos del usuario se van refinando en iteraciones sucesivas, por lo que se pueden acomodar mejor los cambios




39 / 41

la vida del proceso unificado

el proceso unificado se repite a lo largo de una serie de cicloscada 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 sistemaplan del proyecto, coste, identificación y priorización de riesgos

elaboración: se especifican en detalle los principales casos de usose 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 despliegueal 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 arquitecturaal final se dispone de todos los casos de uso acordados para el desarrollo aunque puede incorporar defectos

transiciónperiodo durante el cual el producto se convierte en versión beta, en la que usuarios prueban el producto e informan de defectos y deficienciasse corrigen problemas e incorporan sugerenciasincluye actividades como la formación del usuario, proporcionar una línea de ayuda y asistencia,...

cada fase se divide a su vez en iteraciones




40 / 41

Inicio Elaboración Construcción Transición

Requisitos

Análisis

Diseño

Implementación

Prueba

Flujos de trabajofundamentales

Fases

iter #1 iter #2 --- --- --- --- --- iter #n-1 iter #n

Iteraciones

la vida del proceso unificado

una iteración en lafase de elaboración

ingeniería del software de gestión. tema 1

Technology