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