You are on page 1of 40

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

objetivo actual: mejorar la calidad de las soluciones software. 1959 - 1965
 Orientación por lotes  Distribución limitada  Software a medida

1965 - 1975
 Multiusuario  Tiempo real  Bases de datos  Software como producto  Mayores gastos de mantenimiento

 Sistemas distribuidos  Inteligencia Artificial  Hardware de bajo coste  Impacto en el consumo  Redes area local y global  Gran demanda

1975 - 1989

 Potentes sistemas de sobremesa  Tecnología de objetos  Sistemas expertos  Redes neuronales  Cliente/servidor  Tecnologías de Internet.

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

2 / 41

características y evolució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

3 / 41

características y evolució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?

4 / 41

naturaleza y problemas del desarrollo de software El software como elemento lógico. 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. Se desarrolla. Sin tiempo para recoger datos históricos Planificación y estimaciones imprecisas Dificultad de mantener el software existente Insatisfacción del cliente Calidad Baja productividad 5 / 41 .

.Uso de herramientas ..Requisitos establecidos como una declaración general de objetivos .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.Flexibilidad del software ante los cambios 6 / 41 .) Ausencia de entrenamiento formal en nuevas técnicas (programadores vs. ingenieros de software) Resistencia al cambio MITOS DE GESTIÓN Mitos del software: .Mala planificación: aumento de programadores MITOS DE LOS DESARROLLADORES .Entrega al cliente: programa funcionando MITOS DEL CLIENTE . deficiente comunicación.Calidad = el programa se ejecuta sin errores . .Programa funcionando = fin del trabajo .Uso de estándares .

orientados a obtener software económico. desde las etapas iniciales hasta el mantenimiento: “disciplina de ingeniería”: aplicación de teorías. métodos y teorías actividad de modelado solución de problemas adquisición de conocimiento dirigida por una fundamentación 7 / 41 . fiable. eficiente y que satisfaga las necesidades del usuario disciplina que comprende todos los aspectos de la producción de software. desarrollo de herramientas. 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.la ingeniería del software definiciones establecimiento y uso de principios de ingeniería robustos.

la ingeniería del software trata de ser la respuesta a la crisis del software combinación de elementos: métodos completos para todas las fases mejores técnicas de control de calidad mejores elementos de programación herramientas para automatizar los métodos filosofía de coordinación. control y buena gestión 8 / 41 .

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 9 / 41 . pequeños.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.

modelado los ingenieros de software necesitan comprender el ambiente de funcionamiento del sistema: construyen modelos del dominio del problema (sistemas de bolsa..) comprender los distintos sistemas que podrían construir para evaluar alternativas: construyen modelos del dominio de la solución técnicas y herramientas para construir los modelos (por ejemplo... diagramas de UML) SIST EMA DE PAGOS Y FACT URACIÓN Solicitar bienes o servicios iniciador Confirmar pedido iniciador <<subsistema>> Enviar factura al comprador iniciador Hojear facturas iniciador Pagar factura Vendedor Comprador <<extend>> iniciador Sistema de visión <<subsistema>> <<subsistema>> Controlador del brazo <<subsistema>> Controlador del asidero <<subsistema>> Realizar transacción Pagar recargo por saldo deudor Sistema de identificación de objetos Planificar pago factura Sistema de cuentas bancarias Rechazar factura <<subsistema>> Enviar aviso Pagar factura en día vencimiento <<subsistema>> Sistema de selección de embalajes <<subsistema>> <<subsistema>> Sistema de embalaje Controlador de cinta transportadora 10 / 41 . control de tráfico aéreo.

obtención de requerimientos 2. análisis 3. 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) 11 / 41 . Decidir la solución más adecuada 5.solución de problemas los ingenieros de software buscan una solución adecuada. en varios pasos: 1. Especificar la solución actividades básicas del desarrollo 1. Buscar soluciones 4. diseño del sistema 4. Analizar el problema 3. Formular el problema 2.

) 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 12 / 41 . diseñadores...participantes y papeles participantes: todas las personas involucradas en el proyecto cliente: encarga y paga el sistema desarrolladores: construyen el sistema (analistas. programadores..

producto final. consumen recursos...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... manual de usuario. administración. resultados de pruebas para el gerente. 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..) que pueden componerse de otras actividades tarea: unidad elemental de trabajo que puede ser administrada.) entrega: producto de trabajo para un cliente (especificación de requisitos.) actividades. el gerente divide el trabajo en tareas y les asigna recursos 13 / 41 ... una revisión de la estructura de la base de datos.... tareas y recursos actividad (o fase): conjunto de tareas que se realiza con un propósito específico (obtención de requisitos.. fragmento de software.) dos tipos: producto de trabajo interno: producto para el consumo interno del proyecto (por ejemplo.. entrega. equipamiento y recursos humanos al planificar.

. utilización de un determinado lenguaje.otros conceptos de la ingeniería del software objetivos.) a veces hay conflicto entre objetivos (por ejemplo. fiabilidad. 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. requerimientos y restricciones objetivos: principios de alto nivel que se utilizan para guiar el proyecto definen los atributos realmente importantes del sistema (seguridad. proporcionar billetes de tren) requerimiento no funcional: restricción que se establece sobre el funcionamiento del sistema (por ejemplo.. de una determinada plataforma o de un sistema antiguo que el cliente no quiere retirar 14 / 41 . proporcionar billetes de tren en menos de un segundo) otras restricciones: por ejemplo..

otros conceptos de la ingeniería del software notaciones. Catalysis. es una notación gráfica orientada a objetos para representar modelos) método: técnica repetible para resolver un problema específico..) 15 / 41 . metodología de Booch. métodos y metodologías notación: conjunto de reglas gráficas o de texto para representar un modelo (UML. 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. Unified Modelling Language.. Proceso Unificado de Desarrollo..

El Viajero selecciona las estaciones de origen y destino 3. El Viajero se para frente al distribuidor automático de billetes Flujo de eventos: 2. Anulación reserva Nombre del caso de uso: Actor participante: CompraBillete Iniciado por Viajero Precondición: 1. debe ser igual que el precio del billete 5. al menos. el DistribuidorDeBilletes devuelve todo el dinero insertado se acuerdan requisitos no funcionales. El DistribuidorDeBilletes muestra el precio del billete 4. 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 Viajero inserta una cantidad de dinero que. Por ejemplo: el distribuidor de billetes debe estar disponible al menos un 95% del tiempo el distribuidor de billetes debe dar respuesta en menos de un segundo después de seleccionada la transacción 16 / 41 . El DistribuidorDeBilletes emite el billete especificado al Viajero y devuelve el cambio si es necesario Postcondición: 6.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 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.

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 da como resultado cantidad pagada BilleteTren Saldo válido para Moneda Papel Zona 17 / 41 .actividades de desarrollo análisis se produce un modelo correcto. completo. consistente. claro.

) resultado: descripción de las estrategias.. resultado: modelo de objetos detallado actividades del diseño Planificador de pagos Gestor de pedidos Procesamiento de facturas Solicitud de pago Confirmación de pedidos Factura 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) 18 / 41 .. control de acceso.. optimización del modelo para mejorar el rendimiento.. descomposición en subsistema Gestión de planificación de pagos Gestión de cuentas diseño de objetos: IU Solicitud de pago Comprador Procesamiento de solicitudes de pago definición de objetos e interfaces de subsistemas.. reestructuración del modelo de objetos para lograr los objetivos de diseño. almacenamiento de datos persistentes.actividades de desarrollo diseño Gestión facturas comprador diseñ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..

<<subsystem>> Gestión Trabajos Externos <<subsystem>> Gestión Sistema <<subsystem>> Mantenimientos de Gestión <<subsystem>> Gestión Mantenimiento Correctivo <<subsystem>> Validación Usuarios <<subsystem>> Gestión Instalaciones <<subsystem>> Gestión Mantenimiento Preventivo <<subsystem>> Gestión Máquinas Subgrupo <<subsystem>> Gestión Subgrupos-Instalaciones 19 / 41 .

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

B.. Datos incorrectos. El usuario selecciona la opción de Guardar. El usuario introduce los datos. El sistema guarda los datos. 1.Nombre Prioridad Actor Extends Includes Pre-Condiciones Post-Condiciones Descripción Excepciones Alta Características Máquina Media Administrador Ninguno Validar Usuario 1. 2. El usuario selecciona la opción de altas en el formulario. 4. 3. 6. 7.. 1. A. El sistema muestra el formulario de altas. Mostrar(Datos) Si no Existe Cubrir_Datos() Comprobar() Alta Características-Maq Datos Correctos Crear_Alta() <<include>> Construir <<include>> Baja Características-Maq <<include>> Validar Usuario Administrador (from Validación Usuarios) Visualizar Resultado Datos no Correctos Construir <<include>> Modificación Características-Maq (from Validación Usuarios) Visualizar Mensaje Fin Si Fin Si Operario (from Validación Usuarios) Consulta Características-Maq 21 / 41 . El proceso se puede cancelar en cualquier momento. El usuario está identificado. Los datos de la nueva característica quedan guardados si el proceso finaliza correctamente. El sistema realiza la validación de los datos. Si se guarda correctamente se visualiza un mensaje. si hay algún problema el sistema avisa con un mensaje de error. : Administrador Opciones Frm Cliente CT RL Alta Instalación Form_Alta Validar Datos INST ALACION Resultado Alta MENSAJES Seleccionar Crea() Crea() Mostrar Introducir Datos() Comprobar() Obtener Datos . 2. ir a punto 2. Si la característica ya existe [A]. Si la característica ya existe se visualizan sus datos. 8. Los datos de la nueva característica no quedan guardados si se produce algún error durante el proceso. 2. 5. Si los datos no son correctos [B].

Si la característica ya existe [A]. Si se guarda correctamente se visualiza un mensaje. El usuario está identificado. 1. Si los datos no son correctos [B]. B. El usuario selecciona la opción de Guardar. 2. El usuario introduce los datos. El sistema muestra el formulario de altas. El sistema realiza la validación de los datos. 2. El usuario selecciona la opción de altas en el formulario. si hay algún problema el sistema avisa con un mensaje de error. ir a punto 2. 3. 4. Sistema (from Validar Usuario) Administrador (from Alta Máquinas) Administrador Validado Visualizar Formulario Seleccionar Formulario Comprobar Datos Introducir Datos Datos Incorrectos Mensaje "Error Datos" Datos Correctos Comprobar Existencia de la Instalación Si Exi ste Visualizar Datos Instalación Seleccionar Guardar No Existe Alta Características-Maq <<include>> <<include>> Guardar Datos Instalación Error al Guardar Baja Características-Maq <<include>> Validar Usuario Administrador (from Validación Usuarios) Instalación Guardada Mensaje "Error" <<include>> Modificación Características-Maq (from Validación Usuarios) Mensaje "Instalación guardada" Operario (from Validación Usuarios) Consulta Características-Maq 22 / 41 . Los datos de la nueva característica no quedan guardados si se produce algún error durante el proceso. El proceso se puede cancelar en cualquier momento. 6. El sistema guarda los datos. 1. 2. Los datos de la nueva característica quedan guardados si el proceso finaliza correctamente. 8. A. Datos incorrectos. 5. 7. Si la característica ya existe se visualizan sus datos.Nombre Prioridad Actor Extends Includes Pre-Condiciones Post-Condiciones Descripción Excepciones Alta Características Máquina Media Administrador Ninguno Validar Usuario 1.

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

Servidor ODBC SGBD TCP/IP TCP/IP Cliente Red Local Impresora TCP/IP Cliente 24 / 41 .

25 / 41 .

) corrección de errores adaptación a cambios en el entorno (hardware. facilidad de uso..) actividad más costosa del ciclo de vida de un producto software 26 / 41 .. 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..... software. legislación.actividades de desarrollo implementación traducción del modelo de diseño (por ejemplo. 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.

informes de evolución y calidad.. negociaciones..actividades de desarrollo actividades de administración del desarrollo comunicación actividad crítica y costosa en tiempo intercambio de modelos y documentos... mejoras del sistema. herramientas y notaciones gestión de la configuración proceso que supervisa y controla los cambios en los productos de trabajo cambios: requerimientos. comunicación de decisiones. 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 27 / 41 . errores encontrados... plataformas hardware y software.

el proceso de desarrollo 28 / 41 .

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. lo que permite realizar la misma tarea correctamente de forma repetida existen diferentes modelos de proceso Requisitos del usuario Proceso de desarrollo de Software Sistema software 29 / 41 . 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.el proceso: modelos de desarrollo proceso conjunto ordenado de tareas. se suele llamar ciclo de vida aportan consistencia y estructura sobre el conjunto de actividades. 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. restricciones y recursos. una serie de pasos que involucran actividades.

...) 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 30 / 41 .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.

..) estructura deficiente evolución del proceso difícil de gestionar herramientas y técnicas especiales poco adecuado para grandes sistemas 31 / 41 ..desarrollo evolutivo 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 Recolección y refinamiento de requisitos Producto Diseño rápido 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 problemas prisas del cliente (utilización del prototipo como sistema final Refinamiento del prototipo Evaluación del prototipo por el cliente Construcción del prototipo pasar elecciones debidas al prototipo a la implementación final (entorno. sistema operativo.

876 Draw canvas component User prompt component + script Tree display component fuente: I. 6th ed.prototipado con lenguajes visuales Date component Hypertext display component File Edit Views Layout Options Help General Index 12th January 2000 Range checking script 3. Sommerville.2000 32 / 41 . Software Engineering..

desarrollo incremental Definición general de requerimientos pasos identificació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 Asignación de requerimientos a incrementos Diseño de la arquitectura del sistema Desarrollo de incrementos del sistema Validar incrementos ventajas puesta 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 Integrar incrementos Validar sistema problemas sistema incompleto sistema completo incrementos relativamente pequeños adaptación de requerimientos a incrementos del tamaño apropiado Sistema final identificación de recursos comunes a todos los incrementos 33 / 41 .

DETERMINAR OBJETIVOS. modelos.modelo en espiral propuesto por Barry Boehm organización en ciclos primer ciclo: factibilidad segundo ciclo: requerimientos tercer ciclo: diseño . IDENTIFICAR Y RESOLVER RIESGOS Análisis de riesgos Análisis de riesgos Análisis de riesgos An. evaluación y reducción de riesgos (por ejemplo. Riesgo.... plan de administración. Prototipo 1 Prototipo 3 Prototipo 2 cada ciclo se divide en 4 sectores definición de objetivos. pruebas comparativas Plan de desarrollo Plan de integración y prueba Diseño del producto Diseño detallado Codificar Diseño de validación y verificación Prueba de unidad Prueba de integración Explotación Prueba de aceptación DESARROLLAR. ALTERNATIVAS Y RESTRICCIONES PROGRESO A TRAVÉS DE LAS ITERACIONES EVALUAR ALTERNATIVAS. se planifica la siguiente fase PLANIFICAR SIGUIENTE FASE REVISIÓN Plan de . 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... restricciones del producto y proceso. si es así. requerimientos Plan de ciclo de vida Prototipo operativo Concepto de operación Requerimientos de software Validación de requerimientos Simulaciones. VERIFICAR PRODUCTO DE SIGUIENTE NIVEL 34 / 41 .

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

que describe la funcionalidad total del sistema guían el proceso de desarrollo (diseño.el proceso unificado: dirigido por casos de uso para construir un sistema con éxito hay que conocer las necesidades y deseos de los futuros usuarios usuario personas que trabajan y necesitan el sistema otros sistemas que interactúan con el que estamos desarrollando interacción: Retirar dinero usuario inserta tarjeta en cajero automático 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. 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 Transferencia entre cuentas no sólo inician el proceso de desarrollo sino que éste sigue un hilo de trabajo que parte de los casos de uso 36 / 41 . implementación y prueba) basándose en el modelo de casos de uso.

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

para obtener resultados claros a corto plazo los requerimientos del usuario se van refinando en iteraciones sucesivas. Si no. el desarrollo continúa con la siguiente iteración.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. por lo que se pueden acomodar mejor los cambios 38 / 41 . 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.

del modelo de diseño..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. del modelo de implementación y modelo de despliegue al final se pueden planificar las actividades y estimar recursos necesarios para finalizar el proyecto 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 periodo durante el cual el producto se convierte en versión beta. del modelo de análisis. identificación y priorización de riesgos 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.. proporcionar una línea de ayuda y asistencia.. elaboración: construcción: transición cada fase se divide a su vez en iteraciones 39 / 41 . 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.

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