Proyecto Práctico de Ingeniería de Requisitos

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Proyecto Práctico de Ingeniería de Requisitos"

Transcripción

1 Ingeniería del Software I 4 Ingeniería Informática Procesos del Desarrollo de Software 3º Grado en Ingeniería Informática Proyecto Práctico de Ingeniería de Requisitos Curso Gonzalo Génova 1 Presentación Ingeniería del Software I Gonzalo Génova (ggenova [at] inf.uc3m.es) - COORDINADOR Roberto Galindos (rgalindo [at] inf.uc3m.es) Eduardo Barra (ebarra [at] inf.uc3m.es) Isidro Hernanz (ihernanz [at] inf.uc3m.es) Dirección para entregas: is.uc3m [at] gmail.com Procesos del Desarrollo de Software José Miguel Fuentes (fuentes [at] inf.uc3m.es) - COORDINADOR Mónica Marrero (mmarrero [at] inf.uc3m.es) Diego Martín (dmandres [at] inf.uc3m.es) Isidro Hernanz (ihernanz [at] inf.uc3m.es) Dirección para entregas: pds.uc3m [at] gmail.com Aula Global 2 / Avisos / Web de la asignatura Un curso de análisis y diseño en dos asignaturas: IS1/PDS: requisitos del usuario (captura) y requisitos del software (análisis) IS2: diseño arquitectónico (alto nivel) y diseño detallado (bajo nivel) 2

2 Objetivos de la asignatura Análisis y definición de los requisitos de una aplicación informática Aprender... Redacción de un documento completo de requisitos Desarrollo dirigido por modelos (MDA-MDD-MDE), evolución de USDP Estándares de documentación de proyectos Técnicas del análisis orientado a objetos para ingeniería de requisitos Desarrollar capacidades Abstracción y resolución de problemas Lectura crítica y reflexiva Trabajo en equipo Exposición de resultados propios Revisión de trabajos ajenos Aprendizaje a partir de errores propios y ajenos 3 Programa de la asignatura: teoría Tema I. Requisitos del usuario (captura de requisitos) Unidad 1. Estándares de documentación Unidad 2. Introducción a la ingeniería de requisitos Unidad 3. Obtención y descripción de requisitos de usuario Unidad 4. Modelado de casos de uso con UML * Unidad 5. Ética y responsabilidad profesional en la ingeniería del software * Unidad 6. Educación ética en la ingeniería del software (artículo y examen) Tema II. Requisitos del software (análisis de requisitos) Unidad 11. Modelado conceptual con UML (1) Unidad 12. Modelado conceptual con UML (2) Unidad 10. Sobre la diferencia entre análisis y diseño (artículo y examen) Unidad 7. Tipos de requisitos del software Unidad 8. Propiedades y atributos de los requisitos Unidad 9. Organización y calidad de los requisitos 4

3 Programa de la asignatura: prácticas Equipos de 4 alumnos Trabajo en 2+2 fases (URD/SRD + ADD/DDD) Actividades en cada fase Desarrollo y documentación del proyecto conforme al índice de la práctica recuento de horas dedicadas al proyecto y métricas contabilizadas al principio de cada documento enviadas aparte por correo según las plantillas (horas, métricas) Sesiones de tutoría por equipo no se califica, pero asistencia obligatoria Revisiones cruzadas informes de revisión redactados conforme a las normas Exposiciones en público y defensa del proyecto entrega de transparencias impresas el primer día de exposiciones ( 2xPág!) exposición individual de una parte del proyecto respuestas a los revisores y a los profesores 5 Documentación entregada Atención a nombres de archivos y fechas de entrega Dos documentos parciales (el segundo completa al primero): ej. ProyectoIS1-M05.doc: equipo M05, etc. (poner IS1 ó PDS según convenga) envío por correo a la dirección de entrega y miembros del equipo revisor ver índice adaptado del estándar ESA PSS-05-0 Dos documentos de revisión (el segundo completa al primero): ej. RevisiónIS1-M05-R07.doc: equipo M05 revisado por equipo M07, etc. envío por correo a la dirección de entrega y miembros del equipo revisado Proyecto final revisado (normas): documento final + presentaciones + recuento de horas + métricas ej. ProyectoIS1-M05.doc + etc. envío por correo la dirección de entrega ejemplar impreso encuadernado en espiral con tapas duras, incluyendo: revisiones recibidas y respuestas, revisiones enviadas transparencias de las dos presentaciones Propuesta de preguntas teóricas para el examen de test 6

4 Descripción de la práctica Realizar un proyecto de ingeniería inversa sobre un portal inmobiliario real. Buscar en internet... Elegir un portal y ceñirse a él. Describir brevemente el alcance total de la funcionalidad ofrecida por el portal. Incluir también los requisitos de restricción/no funcionales. Seleccionar un subconjunto coherente de la funcionalidad ofrecida por el portal, de forma que sea abarcable dentro de los límites de carga de trabajo de la asignatura. Es muy importante definir bien los límites del sistema descrito. Se califica la calidad de la descripción realizada en la práctica, no la cantidad de funcionalidad descrita, ni la importancia comercial o la calidad técnica del portal. Describir este subconjunto en forma de requisitos y con los modelos necesarios. Una parte importante del trabajo de la práctica consiste en perfilar bien el lenguaje utilizado para definir el sistema. Realizar una evaluación del portal (la parte seleccionada): Sugerir mejoras en la concepción del sistema (en forma de nuevos requisitos). Por ejemplo, detectar carencias importantes en la funcionalidad ofrecida por el portal. Sugerir mejoras en la implementación del sistema. En principio, puesto que se trata de un proceso de ingeniería inversa donde los requisitos se han extraído de la implementación, se da por supuesto los requisitos están correctamente implementados; no obstante, pueden existir obvios defectos de implementación. 7 Formato de los documentos Word, Times New Roman 12 ó Arial 10, interlineado sencillo. Impreso a doble cara Opcionalmente, formato PDF (con permisos de lectura y copia). Extensión (porque queremos calidad, no cantidad): URD: 15 a 20 páginas. SRD: 30 a 40 páginas. TOTAL: 45 a 60 páginas (sin contar índices ni anexos). Trabajo excesivo? Factor de penalización en la calificación del documento por exceso de páginas. penalización 1 1-(p-60)/ páginas 8

5 Trabajo en equipo y dedicación a la práctica Un total de 60 horas/alumno dedicadas a la práctica es razonable. Equivale a una hora de trabajo práctico por cada hora de clase teórica. 20 horas de clase + 20 horas de trabajo personal = 40 horas/semana. La proporción entre trabajo individual y en equipo debería ser 4/1 ó 3/1. Para conseguirlo la distribución y coordinación del trabajo deben ser adecuadas. Si el número de horas es igual para todos falta sinceridad pero si no se califica! Nombre Ind. Eq. TOTAL Ana García Juan Gómez Isabel López Pedro Fernández TOTAL MAL Nombre Ind. Eq. TOTAL Ana García Juan Gómez Isabel López Pedro Fernández TOTAL BIEN 9 Calendario de la asignatura Dedicación a la asignatura, aproximadamente: 30 horas de clase teórica 30 horas de otras actividades en clase 60 horas de trabajo personal y en equipo Clases teóricas Asistencia no controlada. El examen de Test es un reflejo directo del aprovechamiento de las clases teóricas, de ahí la importancia que se le da en la nota final. Clases de laboratorio Aprendizaje de herramientas. Tutorías por equipo Asistencia obligatoria. Sirven para que el profesor pueda hacer un seguimiento efectivo del proyecto. Aprovechad la tutoría llevando un borrador bien trabajado. Exposiciones/Revisiones Asistencia obligatoria a todas las exposiciones, aunque no toque exponer. Dos miembros exponen la práctica, dos responden a revisores y profesores. Tiempo máximo de exposición: 20 minutos entre ambos. Calendario completo (IS1, PDS) Atención a las fechas de entregas. 10

6 Evaluación de la asignatura Práctica Teoría Individual Equipo Tutorías* 00% Exp/Preparación 10% Exp/Ejecución 05% Documentación 25% 50% Exp/Respuestas 05% Revisiones 05% Exámenes parciales 10% Propuesta de Examen final 30% preguntas 10% 50% 50% 50% 100% * Asistencia obligatoria (0,5 penalización por falta no justificada) Igualmente se penaliza la falta no justificada a las exposiciones ajenas. Más detalles 11 Bibliografía Ingeniería de requisitos Eric Braude. Software Engineering. An Object-Oriented Perspective. John Wiley & Sons, Capítulos 3 y 4 Ian Sommerville. Ingeniería del Software. Pearson-Addison Wesley, Capítulos 6 y 7 Roger Pressman. Ingeniería del software: un enfoque práctico, 6ª ed. McGraw- Hill. Capítulos 7 y 8 Modelado con UML Martin Fowler, Kendall Scott. UML Distilled. A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, Jim Arlow, Ila Neustadt. UML and the Unified Process. Practical Object- Oriented Analysis & Design. Addison-Wesley, Perdita Stevens, Rob Pooley. Using UML. Software Engineering with Objects and Components. Addison-Wesley, Más en la ficha de la asignatura (IS1, PDS) 12

7 Tema I Requisitos del Usuario Unidad 1. Estándares de documentación Unidad 2. Introducción a la ingeniería de requisitos Unidad 3. Obtención y descripción de requisitos de usuario Unidad 4. Modelado de casos de uso Unidad 5. Ética y responsabilidad profesional Unidad 6. Responsabilidad ética del ingeniero de software (artículo) 13 Flujos de trabajo vs. Documentos Flujos de trabajo Documentos USDP Clásica IEEE ESA Requisitos Análisis Análisis de requisitos Software Requirements Specification (IEEE ) User Requirements Document Software Requirements Document Diseño Diseño arquitectónico Diseño detallado Software Design Document (IEEE ) Architectural Design Document Detailed Design Document + Implementación, Pruebas, Mantenimiento... 14

8 El Estándar de la ESA GENERAL European Space Agency software engineering standards Guide to the software engineering standards PRODUCTS Guide to the user requirements definition phase Guide to the software requirements definition phase Guide to the software architectural design phase Guide to the software detailed design and production phase Guide to the software transfer phase PROCEDURES Guide to the software operations and maintenance phase Guide to software project management Guide to software configuration Guide to software verification and validation Guide to software quality assurance ESA Lite Guide to applying the ESA standards to small software projects 15 Los requisitos del usuario en el Estándar ESA ESA software engineering standards (PSS-05-0) Chapter 2. The user requirements definition phase 2.3. Actividades: nociones importantes Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1) Chapter 3. Using Object-Oriented Methods with PSS-05 No afecta Guide to the user requirements definition phase (PSS-05-02) Chapter 2. The user requirements definition phase 2.3. Determinación del entorno operacional 2.4. Requisitos de capacidad / Requisitos de restricción 2.7. Revisión de los requisitos del usuario Chapter 5. The user requirements document 5.1. Introducción: lo que debe ser, lo que no debe ser 5.3. Estilo: claridad, consistencia, modificabilidad 5.6. Contenido adaptado Preguntas más frecuentes 16

9 Los requisitos del software en el Estándar ESA ESA software engineering standards (PSS-05-0) Chapter 3. The software requirements definition phase 3.3. Actividades: modelo lógico; tipos de requisitos y propiedades Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1) Chapter 3. Using Object-Oriented Methods with PSS Modelo lógico = modelo de requisitos + modelo de análisis Guide to the software requirements definition phase (PSS-05-03) Chapter 2. The software requirements definition phase 2.3. Construcción del modelo lógico (rendimiento, riesgos, prototipado) 2.4. Tipos y propiedades de los requisitos del software 2.6. Revisión de los requisitos del software Chapter 5. The software requirements document 5.1. Introducción: lo que debe ser, lo que no debe ser 5.3. Estilo: claridad, consistencia, modificabilidad 5.6. Contenido adaptado Preguntas más frecuentes 17 Introducción a la ingeniería de requisitos Qué es la Ingeniería de Requisitos Captura y Análisis Resultado del proceso: el documento de requisitos Necesidad de la Ingeniería de Requisitos Para construir algo, antes hay que entender qué es ese algo Por qué es necesario escribir los requisitos Sin requisitos escritos es imposible... No hay ingeniería profesional sin requisitos escritos Dos niveles en los requisitos Requisitos del Usuario, Requisitos del Software Dificultades de la Ingeniería de Requisitos El precio pagado: es una necesidad, no un lujo La Ingeniería de Requisitos en el contexto del proyecto Pre-proyecto: valor contractual, viabilidad, planificación, estimación... 18

10 Un caso práctico Necesito algo para organizar mejor mis actividades, una agenda para llevar al día mi horario, mis compromisos, etc. x x x x x x x x x x x x x x x x MES x x x x x x x x x x x x x x x x x x x Día Compromiso Compromiso Compromiso 19 The Chaos Report The Standish Group International: realiza estudios desde : datos de proyectos de tecnologías de la información Proyecto exitoso 16% 27% 26% 28% 34% Proyecto completo pero deficiente Proyecto cancelado 53% 33% 46% 49% 51% 31% 40% 28% 23% 15% 20

11 The Chaos Report Porcentaje 100,00% 90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% Años Proyecto exitoso Proyecto cancelado Proyecto completo pero deficiente 21 Requisitos del Usuario vs. Requisitos del Software Requisitos del usuario Requisitos del software ANÁLISIS Diseño arquitectónico Diseño detallado DISEÑO IMPLEMENTACIÓN 22

12 Diferentes puntos de vista Diferentes documentos Lo que él necesita es... Lo que tienes que hacer es... Lo que yo necesito es... Analista Arquitecto Lo que tengo que hacer es... Cliente Diseñador 23 Obtención y descripción de requisitos del usuario Las fuentes de los requisitos Plan de trabajo para obtener los requisitos Identificación de stakeholders Quiénes tienen interés en el producto? Quién es el cliente? Intereses contrapuestos, requisitos contradictorios Negociar el equilibrio Requisitos Calidad Identificar Entrevistar Escribir [no conforme] Presupuesto Recursos Cómo llevar adelante una entrevista Antes, durante, después... Planificación Tiempo Revisar [conforme] 24

13 Técnicas para la obtención y descripción de requisitos Textuales Relativamente accesibles a un cliente sin formación específica Texto en prosa común y corriente Texto estructurado, lenguaje técnico Casos de uso Gráficas Requieren un cierto grado de formación técnica en el cliente Tienen el peligro de convertir el análisis de requisitos en diseño Diagramas de flujo de datos Diagramas de actividad Diagramas de estados Prototipos No confundir con diseño, valorar la inversión Interfaces de usuario Protipado rápido 25 Beneficio de la inversión en prototipos Beneficio obtenido (% ahorro/gasto) Beneficio óptimo GUI simplificada Recursos malgastados 0% Gasto efectuado (% prototipo/total) 100% Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective 26

14 Introducción Modelado de casos de uso Propósito y definición Casos de uso y extracción de requisitos El requisito no es la interacción, sino el objetivo. El modelo de casos de uso Notación. Actores y casos de uso. Actores cooperativos. Include y Extend. Descripción textual de casos de uso Escenario básico y escenarios alternativos. Pre- y post- condiciones. Casos de uso y operaciones del sistema Descripción gráfica de casos de uso Diagramas de actividad Casos de uso y procesos de negocio 27 Ejemplo: Agencia de viajes por internet Ingeniero. Explícame cómo quieres que funcione la aplicación. Cliente. Bueno, lo primero es acceder a la página web de la agencia, no?, entonces se seleccionan las ciudades de origen y destino, el número de pasajeros, y las fechas de ida y vuelta. El sistema muestra el precio de los billetes, y si el usuario está conforme introduce los datos de su tarjeta de crédito para hacer efectivo el pago. Y hay que dar los nombres de los pasajeros, claro. Ingeniero. Eso es todo? Cliente. Ah, sí, por supuesto, si hay varios vuelos en el mismo día, el usuario debe seleccionar uno de ellos. También hay que tener en cuenta que algunos usuarios están dispuestos a variar sus fechas de viaje, con tal de obtener tarifas más baratas. Ingeniero. Así que habrá que facilitar la búsqueda de vuelos en fechas parecidas y que sean más baratos, no? Por ejemplo, variando un día adelante o atrás tanto la fecha de ida como la de vuelta. Cliente. Exactamente, lo has cogido muy bien. 28

15 Descubrir el objetivo Vaga descripción inicial agencia de viajes por internet Acceder a la página web Seleccionar ciudad origen y destino, número de pasajeros y fechas de ida y vuelta Patrón de comportamiento Mostrar vuelos disponibles y precio de los billetes [no conforme] [alternativas] Mostrar alternativas más baratas en fechas parecidas Objetivo [conforme] comprar billetes de avión por internet facilitando la búsqueda de tarifas baratas Seleccionar un vuelo Introducir nombres de los pasajeros y datos de la tarjeta de crédito [conforme] [no conforme] 29 El modelo de casos de uso La técnica de los casos de uso (inventada por Ivar Jacobson): Objetivo: identificar los requisitos funcionales de un sistema (subsistema, clase, etc.), estructurados en torno a los diversos roles de usuarios. Método: descripción de las interacciones típicas usuario/sistema (escenarios). Un caso de uso ( användningsfall, en sueco) es una forma de usar el sistema, habitualmente descrita a través de un conjunto de usos típicos. Describe cómo un actor usa un sistema para conseguir un objetivo, y lo que el sistema hace para ayudarle. Cuenta la historia de cómo el sistema y sus actores colaboran para producir algo de valor, un uso completo del sistema. El modelo de casos de uso sirve para definir y expresar gráficamente el sistema y su entorno: Las funcionalidades que contiene el sistema: casos de uso. Los agentes externos que interaccionan con el sistema: actores. Las relaciones entre agentes externos y funcionalidades: asociaciones. El modelo de casos de uso se expresa gráficamente mediante uno o varios diagramas de casos de uso. Es posible estudiar los casos de uso sin utilizar ningún diagrama. 30

16 Ejemplo: Feria de subastas Se desea modelar un sistema informático para gestionar las transacciones en un recinto ferial de subastas. Cualquier persona que haya logrado acceso al recinto de la feria puede conectarse al sistema a través de alguno de los muchos terminales disponibles, y participar en las subastas que tengan lugar, en alguna de las modalidades ofrecidas por el sistema, es decir, como comprador, como vendedor, o como simple observador. Para subastar algún artículo es necesario darse de alta como vendedor. El vendedor puede registrar artículos en la subasta, rellenando una ficha por cada artículo, que sale así inmediatamente a subasta. Análogamente, para participar en una subasta es necesario darse de alta como comprador. El comprador puede pujar por cualquiera de los artículos subastados en la feria. Cuando no se produce ninguna nueva puja, el artículo queda definitivamente adjudicado al comprador. Si un artículo no ha recibido ninguna puja, el vendedor puede modificar alguno de sus datos. Cualquier persona puede participar como observador en una subasta, es decir, puede consultar la lista de artículos subastados y seleccionar uno de ellos para examinar la lista de pujas. Un observador puede registrarse como vendedor o comprador para participar activamente en la subasta. 31 Diagrama de casos de uso Asociaciones Feria de subastas Registrar artículo Modificar datos de artículo Actores Vendedor Comprador Observador Consultar lista de artículos Registrar usuario Pujar por artículo Casos de uso Frontera del sistema 32

17 Actores Un actor representa el rol que adopta una entidad externa que interacciona directamente con el sistema. Todo actor tiene un nombre. Los actores significan roles, no entidades concretas: Varias entidades concretas pueden desempeñar el mismo rol. Una misma entidad concreta puede desempeñar varios roles. Un actor puede participar en varios casos de uso, desempeñando un rol diferente en cada uno, por tanto un actor, más que un rol, es un conjunto coherente de roles. Tipos de actores (o agentes externos, concepto más amplio que usuario ): Personas o cosas (otro sistema, un sensor, agua, fuego, tiempo...). Primarios o secundarios (realizan tareas administrativas o de mantenimiento). Utilidad: descubrir y organizar los casos de uso (quién quiere qué). Peligro: identificar los actores con categorías de usuarios. Vendedor, Comprador y Observador no son categorías disjuntas, sino roles. 33 Casos de uso Un escenario es una secuencia de acciones del actor y acciones del sistema que describe una interacción típica entre ambos (qué hace cada uno). Escenario básico: todo va bien. Escenarios alternativos, manejo de errores, situaciones excepcionales... Un caso de uso es una colección de escenarios con un objetivo común: El conjunto de escenarios especifica un comportamiento que proporciona un resultado valioso para uno o más de los interesados en el sistema. Representa una tarea, o unidad coherente de funcionalidad, que el sistema está obligado a proporcionar a los actores en beneficio de los interesados. En un caso de uso pueden participar varios actores distintos, y además: Las acciones de un actor pueden ser beneficiosas para otros actores. Puede haber interesados (stakeholders) que no sean actores en absoluto. Dos niveles de abstracción en la definición: Interacción actor/sistema, secuencia de acciones (descripción prototípica). Servicio requerido, objetivo, finalidad, funcionalidad (descripción abstracta). 34

18 Actores cooperativos Qué significa conectar varios actores a un mismo caso de uso? El caso de uso puede requerir la participación de varios actores, y Cada actor asociado a un caso de uso representa un rol distinto, y Uno de los actores será el iniciador del caso de uso, y Los actores cooperan entre sí para realizar el objetivo del caso de uso. Simular vuelo Piloto Entrenador Incorrecto: pretender que es el mismo caso de uso para distintos actores, que lo ejecutan de modo independiente. 35 Include y Extend Es posible definir relaciones entre casos de uso: «include»: para describir un comportamiento común reutilizable. «extend»: para describir una variante del comportamiento base. Base Sacar dinero «include» Validar tarjeta Inclusión Editar documento «extend» Ayuda Extensión Significado problemático en UML: No está clara la diferencia entre ambas (reutilización / inserción). No encajan con la definición de unidad coherente de funcionalidad. Pueden llevar por error al modelado de procesamiento secuencial. No use estas relaciones si puede evitarlo. 36

19 Especificación textual de casos de uso Nombre Actores Objetivo Precondiciones Postcondiciones Escenario básico Frase verbal descriptiva Actores que interaccionan con el sistema participando en este caso de uso Finalidad o servicio requerido (qué, no cómo) Descripción del estado del sistema antes de la ejecución del caso de uso (aspecto relevante) Descripción del estado del sistema después de la ejecución del caso de uso (diferencia) Secuencia de acciones principales de la interacción en el escenario básico, detallando la información intercambiada, y los cambios observados en el sistema 37 Ejemplo: Registrar artículo Nombre Actores Objetivo Precondiciones Postcondiciones Escenario básico Registrar artículo Vendedor Registrar los datos de un artículo para que salga a subasta Usuario registrado como Vendedor Artículo registrado Insertar tarjeta magnética Abrir sesión como Vendedor Introducir datos del artículo Confirmar datos introducidos Terminar 38

20 Escenarios alternativos Nombre Escenario básico Escenarios alternativos Registrar artículo 1. Insertar tarjeta magnética 2. Abrir sesión como Vendedor 3. Introducir datos del artículo 4. Confirmar datos introducidos 5. Terminar 2-5a. Tarjeta inválida 1. Devolver tarjeta 2. Terminar 2-5a. Apertura de sesión incorrecta 1. Devolver tarjeta 2. Terminar 5a. Desea registrar otros artículos 1. Volver al paso 3 39 Precondiciones y postcondiciones Son una forma de refinar o especificar con más detalle el objetivo del caso de uso, mediante la descripción del estado del sistema antes y después de la ejecución del caso de uso: Precondiciones: pueden ser comprobadas en la secuencia de acciones del caso de uso, pero no realizadas en ese momento. Postcondiciones: pueden referirse a la salida normal o a una excepcional. Precedencia entre casos de uso: toda precondición de un caso de uso debe cumplirse en el estado inicial del sistema, o bien, debe ser realizada por alguno de los casos de uso del sistema, que la tendrá por tanto como postcondición. Caso de uso Precondiciones Postcondiciones Registrar usuario Usuario registrado Registrar artículo Usuario registrado como Vendedor Artículo registrado Pujar Usuario registrado como Comprador Artículo registrado y no adjudicado Si no hay más pujas, artículo adjudicado 40

21 Casos de uso y operaciones del sistema Los casos de uso no son operaciones del sistema (no confundirlos): Una operación del sistema es un servicio elemental que el actor puede solicitar, es la respuesta del sistema a un evento externo. El caso de uso es un uso coordinado de operaciones del sistema: protocolo. El actor no ejecuta el caso de uso (no lo invoca, en todo caso lo inicia). Operaciones del sistema = bloques de acciones en un escenario. Petición Validación Cambio de estado Respuesta sacar dinero comprobar que hay saldo suficiente alterar el saldo de la cuenta entregar el dinero Especificación de operaciones mediante contratos. 41 Especificación gráfica de casos de uso Una simple secuencia de acciones no puede describir adecuadamente la riqueza de situaciones que se pueden presentar en un caso de uso (alternativas, excepciones...). Posibles soluciones: Complicar la descripción textual de la secuencia de acciones. Emplear una descripción gráfica mediante diagramas de actividad. Un diagrama de actividad representa un flujo de acciones Secuencial, alternativo o concurrente. Elementos principales: Acciones: cada una de las unidades en que se descompone la actividad. Transiciones: conexión entre el fin de una acción y el comienzo de otra. Condiciones: deben ser expresiones booleanas mutuamente exclusivas. 42

22 Diagramas de actividad Acciones y transiciones Estados inicial y final Decisiones y ramas alternativas Sincronización de ramas concurrentes Preparar desayuno Abrir boca Cortar pan Beber café Tomar alimento Cerrar boca [sólido] [líquido] Masticar Leer periódico [terminado] Comer pan [else] Tragar Limpiar cocina 43 Correspondencia entre las especificaciones textual y gráfica Nombre: Consultar lista de artículos Actores: Observador Objetivo: Obtener lista de artículos con datos de vendedores, y lista de pujas de un artículo con datos de compradores Precondiciones: Postcondiciones: Escenario básico: Abrir sesión como Observador Mostrar la lista de artículos con los datos de los vendedores Opcionalmente: Seleccionar un artículo Mostrar la lista de pujas del artículo con los datos de los compradores [sesión abierta] Abrir sesión como Observador [error] [ok] Mostrar lista de artículos con datos de vendedores [fin] [mostrar pujas] Seleccionar artículo Mostrar lista de pujas con datos de compradores 44

23 Consultar lista de artículos Subactividades Abrir sesión [ok] [error] Abrir sesión Mostrar lista de artículos con datos de vendedores [sesión abierta] [fin] [mostrar pujas] Abrir sesión como Observador Seleccionar artículo Mostrar lista de pujas con datos de compradores 45 Localizar la casa Obtener una hipoteca Formalizar la compra Casos de uso y procesos de negocio Procesos de negocio: acciones y agentes Vendedor, Comprador, Web inmobiliaria Comprador, Representante del banco, SI del banco Vendedor, Comprador, Representante del banco, SI del banco, Notario, SI del registro de la propiedad Casos de uso: sistemas, casos de uso y actores Web inmobiliaria Localizar la casa Vendedor, Comprador SI del banco SI del registro de la propiedad Obtener una hipoteca Formalizar la compra Formalizar la compra Comprador, Representante del banco Vendedor, Comprador, Representante del banco, Notario, SI del registro de la propiedad Vendedor, Comprador, Representante del banco, SI del banco, Notario 46

24 Qué es la ética Ética y responsabilidad profesional Ética, comportamiento y libertad Racionalidad y creatividad de la ética Responsabilidad ética y conciencia moral Los tres pilares de la ética Séneca, Kant y Epicuro Lo ético y lo legal Primacía de lo ético Función educadora de la ley Problemas éticos específicos de la ingeniería del software El código ético de ACM/IEEE Preámbulo Los ocho principios y algunos ejemplos de cláusulas 47 Los tres pilares de la ética interioriza racionalidad insensibilidad caballero VIRTUD (Séneca) NORMA (Kant) militar rigorismo autodominio disciplina BIEN (Epicuro) felicidad da sentido egoísmo vividor 48

25 El código ético de ACM/IEEE (v5.2, 1999) 1. Público. Los ingenieros de software deberán actuar en consonancia con el interés público. 2. Cliente y empleador. Los ingenieros de software deberán actuar de forma que respondan a los intereses de sus clientes y empleadores siendo consecuentes con el interés público. 3. Producto. Los ingenieros de software deberán asegurar que sus productos y las modificaciones asociadas cumplen los más altos estándares profesionales posibles. 4. Juicio. Los ingenieros de software deberán mantener la integridad e independencia en sus juicios profesionales. 5. Gestión. Los gerentes y líderes de la ingeniería del software deberán suscribir y promocionar un enfoque ético en la gestión del desarrollo y mantenimiento del software. 6. Profesión. Los ingenieros de software deberán mantener la integridad y reputación de la profesión de acuerdo con el interés público. 7. Colegas. Los ingenieros de software deberán ser imparciales y apoyar a sus colegas. 8. Personal. Durante toda su vida, los ingenieros de software deberán aprender lo concerniente a la práctica de su profesión y promocionar un enfoque ético en la práctica de su profesión. 49 Ejemplos de cláusulas del código ético Público Cliente y empleador Producto Juicio Gestión Profesión Colegas Personal 1.03 certificar software: seguridad, especificaciones, pruebas, riesgos revelar peligros reales o potenciales 2.01 respetar el propio nivel de competencia 2.05 información confidencial obtenida en el trabajo profesional 2.06 informar al cliente si es probable que un proyecto fracase 3.08 buena documentación 3.09 estimaciones cuantitativas realistas (= 5.05) 3.10 pruebas, depuraciones y revisiones adecuadas 4.02 aprobar documentos supervisados 4.04 objetividad profesional 5.07 justa remuneración 5.08 no impedir el acceso a puestos al personal cualificado 6.04 apoyar a otros ingenieros que intenten seguir este código 6.07 veracidad y exactitud de las características del software 7.04 revisar el trabajo de otros 7.06 ayudar a los colegas a mejorar su práctica profesional 8.05 conocer estándares relevantes y leyes aplicables 50

Ejemplo: agencia de viajes por internet

Ejemplo: agencia de viajes por internet Introducción Modelado de casos de uso Propósito y definición Casos de uso y extracción de requisitos Carácter hipotético de los casos de uso El modelo de casos de uso Notación. Actores y casos de uso.

Más detalles

Modelado Estático Avanzado (Asociaciones) Diseño de Software Avanzado Departamento de Informática

Modelado Estático Avanzado (Asociaciones) Diseño de Software Avanzado Departamento de Informática Modelado Estático Avanzado (Asociaciones) Asociación vs. Operación Toda asociación tiene un doble significado: Aspecto estático: estructura del sistema (estados posibles). Aspecto dinámico: comportamiento

Más detalles

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática Modelado Avanzado con Casos de Uso Especificación Gráfica de Casos de Uso Una simple secuencia de acciones no puede describir adecuadamente la riqueza de situaciones que se pueden presentar en un caso

Más detalles

Modelado Estático Avanzado (Generalizaciones) Diseño de Software Avanzado Departamento de Informática

Modelado Estático Avanzado (Generalizaciones) Diseño de Software Avanzado Departamento de Informática Modelado Estático Avanzado (Generalizaciones) Generalización y Clasificación Principio de sustitución: Extensión: todos los objetos de la subclase son también de la superclase. Intensión: la definición

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Fundamentos de Ingeniería del Software Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Cap 3. Análisis de Requisitos Estructura 1. Actividades iniciales. 2. Técnicas de recogida de la

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso Diagramas de Casos de Uso Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso ( Qué es un caso de uso?) Caso de Uso? 2 Casos de Uso ( Qué es un caso de uso?) Un caso de uso

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Modelo Conceptual. También conocido como modelo de dominio. Diccionario/Glosario Diagrama de Entidad Relación Diagrama de Clases

Modelo Conceptual. También conocido como modelo de dominio. Diccionario/Glosario Diagrama de Entidad Relación Diagrama de Clases Modelo Conceptual Explica cuales son y como se relacionan los conceptos relevantes en la descripción del problema Existen muchas variantes, con distintos grados de sofisticación, para describir el modelo

Más detalles

Introducción En este apartado se va a proporcionar una apreciación global del SRS.

Introducción En este apartado se va a proporcionar una apreciación global del SRS. INTRODUCCIÓN Se pretende desarrollar una aplicación web para la gestión de un restaurante que ofrece espectáculos en fechas determinadas con el fin de poner en práctica los principios de planificación

Más detalles

14. Ingeniería de software. Ing. Alejandro Adorjan

14. Ingeniería de software. Ing. Alejandro Adorjan 14. Ing. Alejandro Adorjan : un enfoque en ingeniería de requerimientos Introducción La ingeniería de software es una disciplina que estudia la aplicación de la teoría, el conocimiento y la práctica de

Más detalles

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO Ejercicio Guiado de Análisis y Diseño Orientado a Objetos Ejemplo: CAJERO AUTOMÁTICO El siguiente ejercicio muestra las diferentes actividades que se realizan dentro del desarrollo de un producto software

Más detalles

Planificación y Control de Proyectos de Software mediante MS Project

Planificación y Control de Proyectos de Software mediante MS Project Práctica 2 Planificación y Control de Proyectos de Software mediante MS Project E n esta práctica vamos a introducirnos en la Planificación y Control de Proyectos de Software mediante herramientas informáticas

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información 1 1. Definición y objetivos análisis.(del gr. ἀνάλυσις). 1. m. Distinción y separación de las partesdeun todo hasta llegar a conocer sus principios o elementos. 2. m.

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Diagrama de casos de uso

Diagrama de casos de uso Diagrama de casos de uso Se utiliza para capturar los requerimientos funcionales de un sistema, de tal forma que plasman las relaciones entre los usuarios y el sistema. Contenido Pasos de construcción

Más detalles

Arturo Cepeda Pérez. Software Engineering Tutor

Arturo Cepeda Pérez. Software Engineering Tutor Software Engineering Tutor M A N U A L D E U S U A R I O Tabla de contenidos 1. Software Engineering Tutor... 1 2. Entorno... 2 2.1. Vista Modelo... 3 2.2. Vista Diagrama... 4 2.3. Vista Propiedades...

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Procesos de Negocios

Procesos de Negocios Procesos de Negocios Procesos de negocios Como dijimos en el Tema 1: los sistemas de información y las organizaciones se influyen entre sí: Los SI deben proveer la información que la organización necesita.

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

PROCESO UNIFICADO CAPTURA DE REQUISITOS

PROCESO UNIFICADO CAPTURA DE REQUISITOS PROCESO UNIFICADO CAPTURA DE REQUISITOS El proceso unificado de desarrollo, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 The unified software development process, Ivar Jacobson,

Más detalles

Modelado arquitectónico con UML

Modelado arquitectónico con UML Modelado arquitectónico con UML Qué es la arquitectura de software El modelo de 4+1 vistas arquitectónicas Cohesión y acoplamiento Cómo lograr una descomposición modular eficaz Criterios para la selección

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

Ejemplo de Análisis Orientado a Objetos ATMs

Ejemplo de Análisis Orientado a Objetos ATMs Ejemplo de Análisis Orientado a Objetos ATMs Se desea diseñar el software necesario para una red bancaria provista de cajeros automáticos (ATMs), que serán compartidos por un consorcio de bancos. Cada

Más detalles

UML. Lenguaje de Modelado Unificado

UML. Lenguaje de Modelado Unificado Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado

Más detalles

Programación Avanzada. Análisis Modelado del Dominio

Programación Avanzada. Análisis Modelado del Dominio Programación Avanzada Análisis Modelado del Dominio Contenido Introducción Modelo de Dominio Conceptos Asociaciones Atributos Generalizaciones Otros elementos Restricciones Programación Avanzada Análisis:

Más detalles

PFC- Aplicaciones Web para trabajo colaborativo:

PFC- Aplicaciones Web para trabajo colaborativo: PFC- Aplicaciones Web para trabajo colaborativo: Aplicación para Control de una Integración de S.I. 2º Ciclo Ingeniería Informática Curso 2011-2012 Consultor : Fatos Xhafa Autor : Miguel Angel Pineda Cruz

Más detalles

Programa de la asignatura Curso: 2009 / 2010 ANÁLISIS E INGENIERÍA DEL SOFTWARE (1296)

Programa de la asignatura Curso: 2009 / 2010 ANÁLISIS E INGENIERÍA DEL SOFTWARE (1296) Programa de la asignatura Curso: 2009 / 2010 ANÁLISIS E INGENIERÍA DEL SOFTWARE (1296) PROFESORADO Profesor/es: MARIA BELEN VAQUERIZO GARCIA - correo-e: belvagar@ubu.es FICHA TÉCNICA Titulación: INGENIERÍA

Más detalles

Web ITSM -GUIA RÁPIDA DE USUARIO-

Web ITSM -GUIA RÁPIDA DE USUARIO- Web ITSM -GUIA RÁPIDA DE USUARIO- Manual básico de la aplicación WebITSM donde se visualiza la funcionalidad completa de la misma y la forma adecuada y eficaz de utilizarla. Ingeniería Técnica en Informática

Más detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008)

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008) Unidades temáticas de Ingeniería del Software Fases del proceso de desarrollo 4ª edición (2008) Facultad de Informática organización del desarrollo El ciclo de vida del software abarca el proceso de desarrollo,

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Guía del agente de pruebas de Cúram

Guía del agente de pruebas de Cúram IBM Cúram Social Program Management Guía del agente de pruebas de Cúram Versión 6.0.5 IBM Cúram Social Program Management Guía del agente de pruebas de Cúram Versión 6.0.5 Nota Antes de utilizar esta

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Guía Docente Curso 2012-2013

Guía Docente Curso 2012-2013 ESCUELA TÉCNIICA SUPERIIOR DE IINGENIIERÍÍA Guía Docente Curso 2012-2013 Titulación Ingeniería Informática DATOS DE LA ASIGNATURA * * Asignatura en experiencia piloto de implantación del sistema de créditos

Más detalles

12/07/2010. INGENIERIA DE SOFTWARE Tema 7: Mantenimiento del software. Contenido. 1. Aspectos Generales. 1. Aspectos Generales. 1. Aspectos Generales

12/07/2010. INGENIERIA DE SOFTWARE Tema 7: Mantenimiento del software. Contenido. 1. Aspectos Generales. 1. Aspectos Generales. 1. Aspectos Generales Contenido INGENIERIA DE SOFTWARE Tema 7: Mantenimiento del software Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx Cubo 37 1. Aspectos generales 2. Características

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

CURSO ON-LINE OFFICE 2007, WORD, EXCEL Y POWERPOINT.

CURSO ON-LINE OFFICE 2007, WORD, EXCEL Y POWERPOINT. CURSO ON-LINE OFFICE 2007, WORD, EXCEL Y POWERPOINT. DESCRIPCIÓN Este es un curso ON-LINE paso a paso. El curso está dividido en 18 módulos (Módulo 5xxx). Es un curso oficial de Microsoft, cuando el alumno

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Programa de Capacitación y Certificación. INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Contenido PERFIL DE UN ESPECIALISTA EN BASES DE DATOS.... 3 6231. MANTENIENDO UNA BASE DE DATOS DE SQL SERVER 2008

Más detalles

El modelo de casos de uso. Ingeniería de la Programación

El modelo de casos de uso. Ingeniería de la Programación El modelo de casos de uso Ingeniería de la Programación Prácticas cas 1 Contenidos Introducción RF y RNF Introducción al modelo de RF de UML. Actores y Casos de Uso Modelo de casos de uso Diagrama de contexto

Más detalles

Ingeniería de software

Ingeniería de software Ingeniería de software MSC-0102 Nombre de la asignatura: Ingeniería de Software Línea de trabajo: Asignatura básica Tiempo de dedicación del estudiante a las actividades de: DOC TIS TPS Horas totales Créditos

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Programa de Ingeniería de Sistemas Ingeniería de Software I

Programa de Ingeniería de Sistemas Ingeniería de Software I DIAGRAMAS DE CLASES EJERCICIOS RESUELTOS. ----------------------------------------------------------------------------------------------------------------------------------------- EJERCICIO. RESERVA DE

Más detalles

M III ABSTRACCIÓN Y CLASIFICACIÓN

M III ABSTRACCIÓN Y CLASIFICACIÓN M III ABSTRACCIÓN Y CLASIFICACIÓN COMPLEJIDAD Y ABSTRACCIÓN La abstracción en el desarrollo del programario En todo el proceso de abstracción siempre hay una parte de la situación o del problema que se

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

8. RECURSOS Y MÓDULOS COLABORATIVOS.

8. RECURSOS Y MÓDULOS COLABORATIVOS. 8. RECURSOS Y MÓDULOS COLABORATIVOS. En este capítulo estudiaremos las actividades que ponen el acento en el trabajo en grupo como una metodología fuertemente eficaz para garantizar ocasiones de aprendizaje

Más detalles

Diagramas de Clase en UML 1.1

Diagramas de Clase en UML 1.1 Diagramas de Clase en UML. Francisco José García Peñalvo Licenciado en Informática. Profesor del Área de Lenguajes y Sistemas Informáticos de la Universidad de Burgos. fgarcia@.ubu.es Carlos Pardo Aguilar

Más detalles

EJ-DSI. Ejemplo - Diseño del Sistema de Información

EJ-DSI. Ejemplo - Diseño del Sistema de Información EJ-DSI Ejemplo - Diseño del Sistema de Información 1 Estructura DSI 1 Definición de la Arquitectura del Sistema DSI 2 Diseño de la arquitectura de soporte DSI 3 Diseño de Casos de Uso Reales DSI 4 Diseño

Más detalles

Programación del curso

Programación del curso Ingeniería Software 4º Físicas Programación del curso José M. Drake (drakej@unican.es) Patricia López Martínez ( lopezpa@unican.es ) Computadores y Tiempo Real Santander, 2008 Ingeniería de Programación

Más detalles

Manual de la aplicación para terminales móviles AppTUSSAM

Manual de la aplicación para terminales móviles AppTUSSAM Edición: 5ª Página 1 de 13 Fecha: 25-03-2014 Manual de la aplicación para terminales móviles AppTUSSAM Edición: 5ª Página 2 de 13 Fecha: 25-03-2014 PANTALLA PRINCIPAL Tiempos de llegada: para consultar

Más detalles

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1.

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. 3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. Compartimento del nombre...21 3.2.2.2. Compartimento de la lista

Más detalles

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos

Más detalles

Weitzenfeld: Capítulo 6 1

Weitzenfeld: Capítulo 6 1 Weitzenfeld: Capítulo 6 Las descripciones de los casos de uso representan todas las posibles interacciones de los actores con el sistema para los eventos enviados o recibidos por los actores. En esta etapa

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT

Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT Proyecto de Fin de Carrera Universidad Politécnica de Valencia Escuela Técnica Superior de Informática Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT Realizado por: Dirigido

Más detalles

Especificación de requerimientos

Especificación de requerimientos Especificación de requerimientos 1. Requerimientos funcionales y no funcionales 2. Especificación de requerimientos en lenguaje natural 3. Herramientas de especificación Modelado de datos Diagramas entidad/relación

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

INTRODUCCION A LAS BASES DE DATOS Procesamiento de Archivos vs Bases de Datos ARCHIVOS BASES DE DATOS

INTRODUCCION A LAS BASES DE DATOS Procesamiento de Archivos vs Bases de Datos ARCHIVOS BASES DE DATOS INTRODUCCION A LAS BASES DE DATOS Procesamiento de Archivos vs Bases de Datos ARCHIVOS Datos repetidos. No se manejan estándares. Había inconsistencia de datos. Falta de seguridad en los datos. No existían

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de:

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: UML UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: Conceptos de modelado de datos (diagramas entidad-relación) Modelado de negocios (flujos de trabajo) Modelado de objetos Modelado

Más detalles

Calidad. Preparado por: Amelia Soriano. Referencias. Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation

Calidad. Preparado por: Amelia Soriano. Referencias. Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation Calidad Preparado por: Amelia Soriano Referencias Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation Curso Rational Unified Process Rational University Curso

Más detalles

Arquitectura y Diseño de la Solución

Arquitectura y Diseño de la Solución Arquitectura y Diseño de la Solución Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de

Más detalles

MANUAL DE USUARIO SEGUIMIENTO DE TÍTULOS OFICIALES. 5 de febrero de 2010

MANUAL DE USUARIO SEGUIMIENTO DE TÍTULOS OFICIALES. 5 de febrero de 2010 MANUAL DE USUARIO SEGUIMIENTO DE TÍTULOS OFICIALES 5 de febrero de 2010 INDICE 1. CONFIGURACION DEL IDIOMA EN INTERNET EXPLORER... 3 2. GESTIÓN DE USUARIOS... 5 2.1. Modificaciones de las propiedades del

Más detalles

Descripción del sistema

Descripción del sistema Advanced Edition Descripción del sistema Ender Descripción para la implantación y adaptación del sistema de información Turno, Gestión educativa 1 ÍNDICE 1. INTRODUCCIÓN...3 2. DESCRIPCIÓN CONCEPTUAL DEL

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

MOC-50413 Mastering Microsoft Project 2010

MOC-50413 Mastering Microsoft Project 2010 MOC-50413 Mastering Microsoft Project 2010 Introducción Este curso presenta el software de gestión de proyectos más populares para la dirección de proyectos. Proporciona a los asistentes el conocimiento

Más detalles

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos ZP09-0207, con fecha 2 de junio de 2009 IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos Índice 1 Resumen de características

Más detalles

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN MODULO I: Análisis y Diseño de Sistemas El alumno se familiarizará y describirá los conceptos y aspectos fundamentales del Análisis y Diseño Orientado a Objetos

Más detalles

PLATAFORMA DE FORMACIÓN MANUAL DEL ALUMNO CONSEJO GENERAL DE FARMACÉUTICOS

PLATAFORMA DE FORMACIÓN MANUAL DEL ALUMNO CONSEJO GENERAL DE FARMACÉUTICOS PLATAFORMA DE FORMACIÓN MANUAL DEL ALUMNO CONSEJO GENERAL DE FARMACÉUTICOS 1. PRIMEROS PASOS...3 1.1. Idiomas...4 1.2. Sistema de ayuda...5 1.3. Perfil del alumno...5 2. LOS CURSOS DE LA PLATAFORMA...8

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles