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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

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

Identificación de requerimientos

Identificación de requerimientos Licenciatura en Informática Administración de requerimientos Identificación de requerimientos Licenciatura en Informática Sirva este material como apoyo a los apuntes de la asignatura Administración de

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

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

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

CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020)

CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020) CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020) I. Identificadores de la asignatura Instituto: IIT Modalidad: Presencial Departamento: Materia: Eléctrica y Computación Programación II Créditos:

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

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

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

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

GUÍA DOCENTE DE LA ASIGNATURA

GUÍA DOCENTE DE LA ASIGNATURA GUÍA DOCENTE DE LA ASIGNATURA G658 - Ingeniería del Software I Grado en Ingeniería Informática Obligatoria. Curso 3 Curso Académico 04-05 . DATOS IDENTIFICATIVOS Título/s Grado en Ingeniería Informática

Más detalles

ICONIX. Notas del método con ampliaciones y mejoras

ICONIX. Notas del método con ampliaciones y mejoras ICONIX Notas del método con ampliaciones y mejoras Juan Manuel Fernández Peña y María de los Ángeles Sumano López Colaboración de Josué Andrade Mirós Octubre de 2004 Método ICONIX Referencia El método

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

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

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

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

Cristian Blanco www.cristianblanco.es

Cristian Blanco www.cristianblanco.es 3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo

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

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualizació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

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

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

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

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Requisitos de Software. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Requisitos de Software. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Requisitos de Software Departamento de Lenguajes y Sistemas Informáticos II Introducción Ingeniería de Requisitos Definición: La Ingeniería de requisitos comprende todas las tareas relacionadas con la

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

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

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

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

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software Universidad de Colima Dirección General de Educación Superior Facultad de Ingeniería Mecánica y Eléctrica Licenciatura en Ingeniería en Sistemas Computacionales I. DATOS GENERALES P R O G R A M A A N A

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

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

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Catálogo General de Requisitos

Catálogo General de Requisitos I.T. INFORMÁTICA DE GESTIÓN 05BM: Fundamentos de Ingeniería del Software 05BP: Diseño de Bases de Datos Catálogo General de Requisitos Copyleft 2009 Departamento de Informática y Sistemas. Licencia Copyright

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

El Proceso de Desarrollo de Software. Diseño de Software Avanzado Departamento de Informática

El Proceso de Desarrollo de Software. Diseño de Software Avanzado Departamento de Informática El Proceso de Desarrollo de Software La Ingeniería del Software Ingeniería... La profesión en la que el conocimiento de las ciencias naturales y matemáticas, ganado con estudio, experiencia y práctica,

Más detalles

P1 Elaboración de un plan de proyecto utilizando MS Project G3

P1 Elaboración de un plan de proyecto utilizando MS Project G3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez

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

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

Pontificia Universidad Católica del Ecuador

Pontificia Universidad Católica del Ecuador 1. DATOS INFORMATIVOS: MATERIA O MÓDULO: INGENIERÍA DE SOFTWARE I CÓDIGO: CARRERA: SISTEMAS NIVEL: QUINTO No. CRÉDITOS: 4 CRÉDITOS TEORÍA: 4 SEMESTRE/AÑO ACADÉMICO: Segundo Semestre 2011-2012 CRÉDITOS

Más detalles

GESTIÓN DE PROYECTOS

GESTIÓN DE PROYECTOS GESTIÓN DE PROYECTOS 1.- Datos de la Asignatura Código 101154 Plan ECTS 6 Carácter OBLIGATORIO Curso 1º Periodicidad 1er SEMESTRE Área Departamento Lenguajes y Sistemas Informáticos INFORMÁTICA Y AUTOMATICA

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 8. Contexto y Requisitos del Sistema (en desarrollo OO)

INGENIERÍA DEL SOFTWARE I Tema 8. Contexto y Requisitos del Sistema (en desarrollo OO) INGENIERÍA DEL SOFTWARE I Tema 8 Contexto y Requisitos del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Francisco Ruiz y Patricia López Objetivos del Tema Conocer en detalle la técnica de

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

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

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

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

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

Ingeniería de Negocios y Desarrollo de Sistemas de Información

Ingeniería de Negocios y Desarrollo de Sistemas de Información Ingeniería de Negocios y Desarrollo de Sistemas de Información Procesos de Negocios Modelos de negocio Ingeniería de Negocios: Notaciones Procedimientos Patrones Proceso de desarrollo de sistemas Metodologías

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

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

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

Análisis de sistemas de Información en la práctica

Análisis de sistemas de Información en la práctica Análisis de sistemas de Información en la práctica Javier Gutiérrez javierj@us.es ASI en la práctica Objetivo: Desarrollar un ASI aplicando técnicas de desarrollo estructurado y de orientación a objetos.

Más detalles

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos 1. Introducción Curso académico 2009-2010 La práctica de Integración de Sistemas consiste en el diseño

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S1 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

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

Fundamentos de Ingeniería del Software. Capítulo 11. Reutilización del software

Fundamentos de Ingeniería del Software. Capítulo 11. Reutilización del software Fundamentos de Ingeniería del Software Capítulo 11. Reutilización del software Reutilización del software. Estructura 1. Reutilización del software 2. Beneficios de la reutilización 3. Dificultades para

Más detalles

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Ingeniería de Software I Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Quienes somos? 2 Quienes son? 3 Objetivos del Curso Entender el rol fundamental que juega la construcción y análisis

Más detalles

Manual de Usuario del Sistema de Ayuda a la función docente en Internet AFDI. para ICM

Manual de Usuario del Sistema de Ayuda a la función docente en Internet AFDI. para ICM Manual de Usuario del Sistema de Ayuda a la función docente en Internet AFDI para Edición: 1.4 Fecha: 27 de Agosto de 2007 HOJA DE CONTROL EDICIONES Edición Fecha 1.0 24/08/2006 1.1 05/01/2007 1.2 19/01/2007

Más detalles

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA DESARROLLO DE UN SISTEMA DE CONSTRUCCIÓN DE WEBS 2.0 E INTEGRACIÓN CON UN SISTEMA DE VENTA DE DOMINIOS Tesis para optar por el

Más detalles

Historial de Revisiones

Historial de Revisiones Página: 1 Especificación de Requerimientos de Software Plataforma Libre Orientada a Servicios para la Gestión de Trámites a través de Gobierno Electrónico (Actualización FASE I) Historial de Revisiones

Más detalles

Tema VII: Herramientas del Análisis Estructurado Diagramas de Flujos de Datos (DFD s)

Tema VII: Herramientas del Análisis Estructurado Diagramas de Flujos de Datos (DFD s) Tema VII: Herramientas del Análisis Estructurado Diagramas de Flujos de Datos (DFD s) Diana Marcela Sánchez Fúquene Índice Herramientas para el Análisis Estructurado Diagrama de Flujo de Datos Diccionario

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

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

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

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen)

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen) Departamento de Lenguajes y Sistemas Informáticos E.T.S. Ingeniería Informática. Universidad de Sevilla Avda Reina Mercedes s/n. 402 Sevilla Tlf/Fax 954 557 39 E-mail lsi@lsi.us.es Web www.lsi.us.es E.T.S.

Más detalles

3. EL PROCESO DEL DISEÑO ARQUITECTÓNICO

3. EL PROCESO DEL DISEÑO ARQUITECTÓNICO EMA - DISEÑO ESRUCURADO 1. INRODUCCIÓN Los métodos de diseño del software se obtienen del estudio de cada uno de los tres dominios del modelo de análisis. El dominio de los datos, el funcional y el de

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

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

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

Gestión de. Requisitos previos. Carácter ECTS. Periodo NINGUNOO. Idiomas en Inglés. Departamento. Ciencias de. Presentación. Despacho y.

Gestión de. Requisitos previos. Carácter ECTS. Periodo NINGUNOO. Idiomas en Inglés. Departamento. Ciencias de. Presentación. Despacho y. = =drð^=al`bkqb qfqri^`flkbp=ab=do^al= TITULACIÓN: INGENIERÍA DE SISTEMAS DE INFORMACIÓN CURSO: Segundo ASIGNATURA: Ingeniería del Software I Nombre del Módulo o Materia al que pertenece la asignatura.

Más detalles

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad.

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad. Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO CS290T. Ingeniería de Software I (Obligatorio) 2012-2 1. DATOS GENERALES 1.1

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

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

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

Además de este foro general, se pueden crear cuantos foros necesitemos.

Además de este foro general, se pueden crear cuantos foros necesitemos. 3.1. FOROS 3.1.1. Definición y características Los foros cuyo icono es - son una de las herramientas de comunicación asíncrona más importantes dentro de los cursos de Moodle. Los foros permiten la comunicación

Más detalles

DEPARTAMENTO: Computación y Diseño NOMBRE DEL CURSO: Diseño de Sistemas Interactivos CLAVE: 1058M ACADEMIA A LA QUE PERTENECE: Análisis y Diseño

DEPARTAMENTO: Computación y Diseño NOMBRE DEL CURSO: Diseño de Sistemas Interactivos CLAVE: 1058M ACADEMIA A LA QUE PERTENECE: Análisis y Diseño PROGRAMA DE CURSO Modelo 2009 DEPARTAMENTO: Computación y Diseño NOMBRE DEL CURSO: Diseño de Sistemas Interactivos CLAVE: 1058M ACADEMIA A LA QUE PERTENECE: Análisis y Diseño PROFESIONAL ASOCIADO Y LICENCIATURA

Más detalles

PROGRAMA FORMATIVO MICROSOFT OFFICE XP PROFESIONAL

PROGRAMA FORMATIVO MICROSOFT OFFICE XP PROFESIONAL PROGRAMA FORMATIVO MICROSOFT OFFICE XP PROFESIONAL www.bmformacion.es info@bmformacion.es Objetivos Se describen todos los programas que integran la suite ofimática Microsoft Office XP: Word, Excel, Access,

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

DEPARTAMENTO: 09640 - Habilidades Básicas en Computación

DEPARTAMENTO: 09640 - Habilidades Básicas en Computación FACULTAD: Ingenierías DEPARTAMENTO: TIC MATERIA: 09640 - Habilidades Básicas en Computación PRERREQUISITOS Ninguno PROGRAMA: Todos los programas de pregrado PERIODO ACADÉMICO: 2015-01 INTENSIDAD HORARIA:

Más detalles