Introduccion ingenieriadelsoftware

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 / 41escuela superior de ingeniería informática

ingeniería del software de gestión

características y evolución del software

un poco de historia

primeras 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






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






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?





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.

Insatisfacción del cliente

Planificación y estimacionesimprecisas

Calidad

Sin tiempo para recogerdatos históricos

Baja productividad

Dificultad de mantenerel software existente





naturaleza y problemas del desarrollo de software

Causas de la crisis del software

Naturaleza lógica del software

Mala gestión de los proyectos ( ausencia de datos, deficiente comunicación, ...)

Ausencia de entrenamiento formal en nuevas técnicas (programadores vs. ingenieros de software)

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





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:

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





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





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)

Realizar transacciónPagar recargo por saldo deudor

Comprador

Solicitar bienes o servicios

Confirmar pedido

Enviar factura al comprador

Sistema de cuentas bancarias

Enviar aviso

iniciador

Vendedor

iniciador

iniciador

Pagar facturainiciador

SISTEMA DE PAGOS Y FACTURACIÓ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>>





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)





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






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 requerimientosel cliente y los desarrolladores definen el propósito y objetivos del sistema

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

CompraBilleteViajero

Anulación reserva






análisis

se produce un modelo correcto, completo, consistente, claro, realista y verificable

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

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

Transacción

Moneda

BilleteTren

Zona

da como resultado

válido para

Saldo

cantidad pagada

Papel

Transacción

Moneda

BilleteTren

Zona

da como resultado

válido para

Saldo

cantidad pagada

Papel






diseñodiseño del sistema

definición de los objetivos de diseño descomposición del sistema en subsistemas abordables por equipos selección de estrategias para la construcción (plataformas hardware y software, almacenamiento de datos persistentes, control de acceso,...) 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ño diseño arquitectónico especificación de los subsistemas diseño de interfaz diseño de componentes diseño de la estructura de datos diseño procedimental (algoritmos)

Comprador

IU Sol icitud de pago

Gestor de pedidos

Confirmación de pedidos

Planificador de pagos

Solici tud de pago

Procesamiento de solicitudes de pago

Procesamiento de facturas

Factura

Comprador

IU Sol icitud de pago

Gestor de pedidos

Confirmación de pedidos

Planificador de pagos

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

Gestión facturas comprador

Gestión de planificación de pagos

Gestión de cuentas





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





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 Características 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


Validar Usuario


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








Operario


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 : Administrador 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 SiFin Si

Datos Correctos

...

Datos no Correctos

Mostrar








Operario


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 Instalació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)





EspecificacionDelProducto

descripciónprecioarticuloID

CatalogoDeProductos

1..n1

Articulo

Encargado

LineaDeVenta

cantidad

1

n

1..n

0..1

Tienda

direcciónnombre

n

1

n1

Pago

cantidad

Venta

fechahora

1

1..n

1

n

1

1

Cliente

1

1

Registro

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

1

n

1..n

0..1

Registra-venta-de





Servidor SGBD

Red Local Impresora

Cliente

Cliente

ODBC

TCP/IP

TCP/IP

TCP/IP






implementacióntraducció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

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





modelo en cascada

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





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 final evolución continua del prototipo mediante la agregación de funciones y características propuestas por el cliente

prototipos desechables comprensión de las necesidades del cliente desarrollo de una definición mejorada de los requerimientos del sistema prototipos 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





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





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





.Concepto de

operación

Análisis de riesgos

An.Riesgo.



-

PROGRESOA TRAVÉS

DE LAS ITERACIONES

DESARROLLAR, VERIFICARPRODUCTO DE SIGUIENTE NIVEL

-

Codificar

PLANIFICAR SIGUIENTE

FASE

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

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





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



Requisitosdel usuario Sistema software





el proceso unificado: dirigido por casos de uso

para construir un sistema con éxito hay que conocer las necesidades y deseos de los futuros usuarios

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





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





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





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





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





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 ingenieriadelsoftware

Education

Transcript of Introduccion ingenieriadelsoftware