La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Ingeniería del Software II. BUTRAGUEÑO GUZMAN, David CERVERA RODRIGUEZ, Alejandro FLORES ACERAS, Jesús HIDALGO SALAMANCA, Raúl SANTOYO DE ANCOS, Andrés.

Presentaciones similares


Presentación del tema: "Ingeniería del Software II. BUTRAGUEÑO GUZMAN, David CERVERA RODRIGUEZ, Alejandro FLORES ACERAS, Jesús HIDALGO SALAMANCA, Raúl SANTOYO DE ANCOS, Andrés."— Transcripción de la presentación:

1 Ingeniería del Software II

2 BUTRAGUEÑO GUZMAN, David CERVERA RODRIGUEZ, Alejandro FLORES ACERAS, Jesús HIDALGO SALAMANCA, Raúl SANTOYO DE ANCOS, Andrés ZAMARREÑO JUANAS, Marcos

3 1. Introducción. 2. Especificaciones de requisitos. 2.1Técnicas de obtención de requisitos 2.2Clasificación de requisitos 3. Características de una buena especificación. 4. Evolución de la especificación de requisitos 5. Calidad del software 6. Últimas plantillas de especificación estándares. 7. Conclusión. 8. Bibliografía.

4 Mediante la especificación de requisitos, se pretende poder establecer un diseño que se ajuste a los requerimientos solicitados por parte del cliente. Para realizar una buena especificación es indispensable que los requisitos estén bien localizados y clasificados. Además nuestra ERS debe ajustarse a las plantillas de IEEE como veremos más adelante.

5 Las técnicas más habituales en la elicitación de requisitos son: las entrevistas, el Joint Application Development (JAD), el brainstorming o tormenta de ideas, y la utilización de escenarios, más conocidos como casos de uso

6 Las entrevistas son la técnica de elicitación más utilizada, y de hecho son prácticamente inevitables en cualquier desarrollo ya que son una de las formas de comunicación más naturales entre personas.

7 Se componen de tres fases: preparación, realización y análisis. Preparación: Estudiar el dominio del problema Seleccionar las personas a las que se va a entrevistar Determinar el objetivo y contenido de la entrevista En definitiva, planificar la entrevista

8 Realización de la entrevista: Apertura: presentación de los miembros, que se espera de la entrevista, explicar el desarrollo. Desarrollo: No más de 2 horas, se deben evitar monólogos y no perder el control de la misma. Terminación: Recapitulación para confirmar que todo está claro y aclarar las dudas que surjan.

9 Análisis de la entrevista Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio, reorganizar la información, contrastarla con otras entrevistas o fuentes de información, etc.

10 La técnica denominada JAD (Joint Application Development, Desarrollo Conjunto de Aplicaciones), desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales que se desarrolla a lo largo de un conjunto de reuniones en grupo durante un periodo de 2 a 4 días.

11 En estas reuniones se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo.

12 Esta técnica se base en cuatro principios: Dinámica de grupo uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.) Mantener un proceso organizado y racional Una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.

13 Debido a las necesidades de organización que requiere y a que no suele adaptarse bien a los horarios de trabajo de los clientes y usuarios, esta técnica no suele emplearse con frecuencia. En general, obtiene buenos resultados en la elicitación de requisitos.

14 El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones de brainstorming suelen estar formadas por un número de cuatro a diez participantes, uno de los cuales es el jefe de la sesión, encargado más de comenzar la sesión que de controlarla.

15 El brainstorming puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas, sobre todo al comienzo del proceso de la elicitación, cuando los requisitos son todavía muy difusos.

16 Frente al JAD, el brainstorming tiene la ventaja de que es muy fácil de aprender y requiere poca organización. Por otro lado, al ser un proceso poco estructurado, puede no producir resultados con la misma calidad o nivel de detalle que otras técnicas.

17 Los casos de uso son una técnica para la especificación de requisitos funcionales propuesta inicialmente por Jacobson en 1993 y que actualmente forma parte de la propuesta de UML.

18 Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más actores en la que se considera al sistema como una caja negra y en la que la que los actores obtienen resultados observables. Los actores son personas u otros sistemas que interactúan con el sistema cuyos requisitos se están describiendo

19 Los casos de uso presentan ciertas ventajas sobre la descripción meramente textual de los requisitos funcionales, ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios. Pueden servir de base a las pruebas del sistema y a la documentación para los usuarios.

20 Los casos de uso tienen una representación gráfica en los denominados diagramas de casos de uso. Los actores se representan en forma de pequeños monigotes y los casos de uso se representan por elipses contenidas dentro de un rectángulo que representa al sistema.

21 Los diagramas de casos de uso sirven para proporcionar una visión global del conjunto de casos de uso de un sistema así como de los actores y los casos de uso en los que éstos intervienen. Las interacciones concretas entre los actores y el sistema no se muestran en este tipo de diagramas.

22 En la mayoría de sistemas, el número de casos de uso es lo suficientemente elevado como para que sea oportuno organizarlos de alguna forma en lugar de tener una lista plana por la que no es fácil navegar. Una posible forma de organizar los casos de uso es recurrir a los paquetes descritos en la propuesta de UML.

23 Requisitos funcionales Requisitos no funcionales Otros requisitos

24 Especifican la funcionalidad o servicio que la aplicación debe proporcionar. Depende del tipo de software, los usuarios esperados o el tipo de sistema donde el software esta siendo usado. Debe describir los servicios del sistema en detalle.

25 El usuario deberá ser capaz de buscar, ya sea todo el conjunto de la base de datos o un subconjunto de ella. El sistema proporcionara las herramientas necesarias para que el usuario pueda visualizar los documentos.

26 Imponen restricciones en el producto desarrollado y en el proceso de desarrollo. Como debe realizar algo el software, no que debe realizar. Cortan transversalmente a los requisitos funcionales. Son negociables hasta cierto punto, dentro de limites aceptables.

27 El interfaz de usuario debe estar implementado en HTML simple sin macros ni frames. El sistema no divulgarán ninguna información personal sobre los clientes, aparte de su nombre y el número de referencia a los operadores del sistema.

28 Requisitos inversos : son aquellos que la aplicación no debe cumplir (son infinitos). Estos tienen las siguientes funciones: Pueden aclarar posibles malentendidos, el alcance del sistema. Seleccionar mejor aquellos que sirven para aclarar los verdaderos requisitos.

29 Requisitos de dominio : derivados de la aplicación de dominio, de la descripción de las características de los sistemas y características que reflejan el dominio. Si los requisitos de dominio no se cumplen, el sistema puede ser inviable.

30 Requisitos de usuario: debe describir requisitos funcionales y no funcionales, de tal manera que sean comprensibles por los usuarios del sistema que no tienen el conocimiento técnico detallado.

31 Correcta No ambigua Completa Verificable Consistente Clasificada Fácil de modificar Identificable Utilizable durante las tareas de mantenimiento y uso

32 Correcta Reflejar alguna necesidad real. No disponemos de una herramienta que nos asegure la exactitud de la ERS.

33 No ambiguo Lenguaje natural puede llegar a ser muy ambiguo. Cada requisito declarado sólo puede tener una interpretación. Ejemplo: Todos los clientes tienen el mismo campo de control Todos los clientes tienen el mismo valor en el campo de control. Todos los campos de control tienen el mismo formato. Un campo de control se usa para todos los clientes.

34 Completo Existe una definición de respuestas a todas las posibles entradas. Cumple con el estándar utilizado. Incluye todos los requisitos significativos del software. Aparecen etiquetadas todas las figuras, tablas, diagramas, etc.

35 Verificable. Cada requisito de los que en ella han sido declarado puede ser comprobable. No usar bien, bueno, normalmente. Ejemplo: No verificable El producto debería funcionar bien. Verificable La salida se suministrará dentro de los 20 segundos siguientes al evento el 60% de las veces, y en 30 segundos siguientes el 100% de las veces.

36 Consistente Ningún conjunto de requisitos descritos en ella son contradictorios y entran en conflicto. Puede existir conflicto lógico o temporal entre dos acciones especificadas. un requisito puede declarar que A siempre debe seguir B, mientras otro puede requerir que A y B" ocurran simultáneamente.

37 Clasificación No todos los requisitos de una ERS son igual de importantes, por eso deben de ser clasificados. Clasificados por: Importancia: Pueden ser esenciales, condicionales u opcionales. Estabilidad: Cambios que pueden afectar al requisito.

38 Modificable puede hacerse cualquier modificación en los requisitos de manera fácil, completa y de forma consistente. Características: No ser redundante Buena organización de la información, índices, referencia cruzadas explicitas. Exprese cada requisito separadamente.

39 La ERS puede necesitar evolucionar Para realizar una buena especificación es indispensable que los requisitos estén bien localizados y clasificados. Es casi imposible especificar todos los requisitos al detalle, en el momento en el que el proyecto se inicia. Los cambios van surgiendo según avanza el proceso del proyecto.

40 Dos consideraciones a tener en cuenta: Especificar los requisitos como son conocidos en el momento de su captura. Se debe especificar formalmente el cambio mediante: Identificación Control Informe

41 ¿Qué es la calidad? La totalidad de características y atributos de un producto o servicio, que están relacionados con satisfacer necesidades expresas o implícitas Fuentes de baja calidad Requisitos imprecisos Requisitos mal entendidos Requisitos incompletos

42 La mayor fuente de baja calidad es la falta de claridad en los requisitos. La definición correcta de los requisitos, puede ser vital para la implementación del proyecto.

43 Consecuencias de una definición de requisitos pobre No podemos demostrar que hemos logrado los objetivos que se establecieron en un principio. No podemos demostrar que no hemos logrado los objetivos. No podemos evaluar las alternativas de diseño. Se termina especificando el medio y no los fines. Si hay más de una forma de expresar un objetivo, tal vez no es un objetivo sino un medio para lograrlo.

44 1 Introducción 1.1 Propósito 1.2 Ámbito del Sistema 1.3 Definiciones, Acrónimos y Abreviaturas 1.4 Referencias 1.5 Visión general del documento 2 Descripción General 2.1 Perspectiva del Producto 2.2 Funciones del Producto 2.3 Características de los usuarios 2.4 Restricciones 2.5 Suposiciones y Dependencias 2.6 Requisitos Futuros 3 Requisitos Específicos 3.1 Interfaces Externas 3.2 Funciones 3.3 Requisitos de Rendimiento 3.4 Restricciones de Diseño 3.5 Atributos del Sistema 3.6 Otros Requisitos 4 Apéndices 5 Índice Estándar IEEE Diferentes plantillas según el punto de vista del apartado 3

45 Según Requisitos específicos: Organizados por objetivos: Un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resultado. Organizados por objetos: Los objetos son entidades del mundo real que son reflejadas en el sistema. Organizados por clase de usuario. Distintos usuarios poseen distintos requisitos. Organizados por la jerarquía funcional: La funcionalidad del sistema se especifica como una jerarquía de funciones que comparten entradas, salidas o datos del propio sistema. Organizados por: estímulos, exhibición de organizaciones múltiples …

46 Apoyo a la especificación: casos de uso Por cada caso de uso proporcionado por el sistema (producto o servicio a desarrollar) se rellenarán los campos de la tabla

47 Apoyo a la especificación: especificación de escenarios: Cada caso de uso puede contener uno o varios escenarios que también son descritos siguiendo una plantilla representada de forma tabular

48 Del buen reconocimiento y clasificación de nuestros requisitos dependerá en gran medida el éxito de la ERS. La ERS deberá sernos útil durante todo el ciclo de vida de nuestro proyecto adaptándose a los cambios que este sufra.

49 Gracias a una buena ERS podremos hacer de nuestro proyecto una obra con unas altas posibilidades de ser de calidad y además fácilmente modificable Permite una más fácil y pronta incorporación al desarrollo del proyecto a un miembro recién incorporado al equipo.

50 [1] [2] https://www.tractis.com/templates/ https://www.tractis.com/templates/ [3] -Especificacion-de-Proceso -Especificacion-de-Proceso [4] tura.php?id=48 tura.php?id=48


Descargar ppt "Ingeniería del Software II. BUTRAGUEÑO GUZMAN, David CERVERA RODRIGUEZ, Alejandro FLORES ACERAS, Jesús HIDALGO SALAMANCA, Raúl SANTOYO DE ANCOS, Andrés."

Presentaciones similares


Anuncios Google