Ingeniería Software e Ingeniería Web

Transcripción

1 Especificación de Requisitos

2 Ingeniería Software e Ingeniería Web Ingeniería Software: Ciencia que trata de establecer metodologías para un desarrollo más eficiente y efectivo de software Ingeniería Web: Ciencia que trata de establecer metodologías para un desarrollo más eficiente y efectivo de portales Web. Aplicaciones Telemáticas son un caso particular de software y en bastantes ocasiones son un caso particular de portales Web. Por lo tanto la ingeniería software y la ingeniería Web tiene sentido aplicarlas a las aplicaciones telemáticas 2

3 Ventajas de la Ingeniería Software y Web Obliga a pensar antes que implementar. La planificación fija objetivos sobre qué hacer Proporciona una visión más clara de los sistemas, al ponerse por escrito una serie de modelos, lo que no está claro es fácil de detectar y corregir Facilita el trabajo en equipo, al compartir descripciones Mejora el mantenimiento del software. También control sobre diferentes versiones, mejoras, o pruebas hechas Posibilita la reusabilidad de diferentes partes y la comparación con otros sistemas 3

4 Ciclo de vida del desarrollo software Ejemplo: En cascada 4

5 Especificación de Requisitos Se puede realizar desde diversos puntos de vista Desde el usuario. Definición de requisitos Desde el comercial y gestor del área de negocio Desde el desarrollador del sistema. Nos centraremos en esta. Especificación de requisitos Hay que convertir lo que define un cliente como lo que quiere en una aplicación en una especificación de requisitos para desarrolladores del sistema con estas características: Clara Consistente Completa Bien estructurada 5

6 Tipos de Requisitos Tipos de requisitos Funcionales: Describen el comportamiento del sistema. Por ejemplo cual es una determinada acción posible en el sistema y cómo interacciona el usuario con dicho sistema y que respuestas obtiene de él. No Funcionales: Describen características internas del software. Por ejemplo, tiempos de ejecución máximos, o necesidad de seguir algún estándar. 6

7 UML: Casos de Uso Están ligados a los requisitos funcionales Identificación de actores que participan. Ejemplo: Alumno, profesor, administrador Ver las diferentes interacciones de los diferentes actores con el sistema. Esto son los casos de uso en sí A su vez pueden tener diferentes sub-acciones Ver las relaciones entre los casos de uso (por ejemplo de herencia) Escribir su descripción textual Dibujar su diagrama UML 7

8 Ejemplo de Casos de Uso en Aplicación Social: UML 8

9 Ej. de Caso de Uso en Aplicación Social: Descripción Textual Nombre del caso de uso: Buscar por contactos Actores: Usuario Propósito: El usuario pueda buscar amigos a añadir que ya están en la aplicación, a partir de sus propios contactos que tiene en una determinada dirección Descripción: Un usuario va a la página de búsqueda de contactos, el sistema le muestra todos los contactos que están ya introducidos en la aplicación social para una determinada dirección de Secuencia de eventos típica: 1.- El usuario accede a la página de búsqueda de contactos y selecciona el enlace de buscar según una dirección 2.- El usuario introduce en el sistema su dirección de y contraseña a partir de la cual se van a buscar los contactos 3.- El sistema calcula de los contactos del usuario cuales están registrados en el sistema y cuales no 4.- El sistema recoge la información de los contactos de usuario que están registrados para dicha dirección de , y dicha información se la mostrará al usuario junto enlaces para hacer más acciones sobre ellos 5.- El usuario puede ver la lista de contactos de su dirección que están registrados en la aplicación 9

10 Requisitos no funcionales Tipos de requisitos no funcionales Rendimiento. Ej. Tiempo de ejecución Interfaz. Ej. Idioma Operación. Ej. Número de usuarios a la vez Recursos. Ej. Mínimo RAM en el servidor Comprobación. Ej. No eliminar el id del usuario al tocar datos Aceptación de pruebas. Documentación. Ej. Manual de ayuda a los usuarios Seguridad. Ej. Confidencialidad de las comunicaciones Calidad. Ej. Diseño apropiado del interfaz del usuario Mantenimiento. Daño 10

11 Plantilla para especificación de requisitos Nombre: (Algo descriptivo del requisito) Tipo: (Funcional o no, y qué tipo de no funcional) Prioridad: (Alta, Media, Baja) Necesidad: (Esencial, Deseable, Opcional) Fuente: (Quien impone el requisito: organismo de estandarización, la compañía, el cliente, etc.) Verificabilidad: (Alta, Media, Baja) Estabilidad: (usualmente durante toda la vida del sistema) Descripción: (se da un detalle de manera clara sobre en qué consiste el requisito) 11

12 Ejemplo de Especificación de un requisito en aplicación social Nombre: Autenticación Tipo: No funcional, de seguridad Prioridad: Alta Necesidad: Esencial Fuente: Cliente Verificabilidad: Alta Estabilidad: Durante toda la vida del sistema Descripción: Antes de poder interactuar con las funcionalidades de la aplicación los usuarios y administradores deben estar autenticados con usuario y contraseña, y estos se almacenarán cifrados por motivos de seguridad 12

13 Prerrequisitos de esta temática Conceptos de Ingeniería del Software adquiridos en la asignatura Software de Comunicaciones Sommerville, Ian (2007) [1982]. Software Engineering (8th ed.). Harlow, England: Pearson Education Pressman, Roger S (2005). Software Engineering: A Practitioner's Approach (6th ed.). Boston, Mass: McGraw-Hill 13

14 Trabajo propio del alumno asociado a la sesión Casos de Uso: Software Requirement Specification (IEEE 830), Requirements.aspx?SpecID=5f4c9a38-d78b-481d-959b- e3ca10fd9b23 Karl E. Wiegers, Karl Wiegers Describes 10 Requirements Traps to Avoid Realizar la especificación de requisitos de alguna aplicación social conocida, incluyendo requisitos funcionales, no funcionales, casos de uso, etc. Formar grupos de 4 personas para el trabajo en grupo 14

15 Referencias Extra Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press 15