UNIDAD 4. ANÁLISIS DE LOS REQUERIMIENTOS OBJETIVO DE LA UNIDAD:

Presentación del tema: "UNIDAD 4. ANÁLISIS DE LOS REQUERIMIENTOS OBJETIVO DE LA UNIDAD:"— Transcripción de la presentación:

1 UNIDAD 4. ANÁLISIS DE LOS REQUERIMIENTOS OBJETIVO DE LA UNIDAD:
Aplicar los requerimientos correspondientes a su proyecto, diseñará las interfaces de usuario y los casos de uso del proyecto.

2 Temario de la Unidad 4.1 Requerimientos Funcionales y no funcionales
4.2 Casos de Uso 4.3 Diseño de Interfaz 4.3.1 Reglas en el diseño de IGU 4.3.2 Integración de la IGU al caso de uso Examen programado.

3 Planeación de las sesiones
Tema Fecha (s) Modalidad 4.1 Requerimientos Funcionales y no funcionales Exposición del docente y trabajo en equipo Examen Unidad 3 26 octubre Examen escrito Practica 7 .1(Traer documento de req.) Trabajo por equipos en el centro de computo 4.2 Casos de uso Exposición Practica 7.2 C.U. 4.3.1 Diseño de interfaz

4 Tema Fecha (s) Modalidad Practica 8. Entrega del reporte de la practica 9 y trabajo por equipos en el centro de cómputo. 4.3.2 Integración de la interfaz al caso de uso Exposición de todos los equipos (de la practica 8). Entrega del reporte. practica 9. Entrega de practicas revisadas, repaso, dudas. Examen Unidad 4 Aplicación del examen escrito. Entrega de resultados Resultados finales

5 4.1 Requerimientos funcionales y no funcionales
Análisis y diseño La mayoría de proyectos de software son complejos, y la estrategia primaria para superar la complejidad, es la descomposición (divide y vencerás). La estrategia es dividir el problema en unidades más pequeñas que sean manejables. Un enfoque tradicional para realizar esto fue el análisis y diseño estructurados, donde se trata de descomponer el problema en funciones o procesos. Este método origina una división jerárquica de procesos constituidos por sub-procesos.

6 4.1 Requerimientos funcionales y no funcionales
Otra forma de realizar la descomposición, es usando un esquema de análisis y diseño orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no en funciones.

7 4.1 Requerimientos funcionales y no funcionales
Algunas de las tareas a realizarse en la etapa de análisis son las siguientes: 1. Definir los requerimientos. 2. Definir los casos esenciales de uso. 3. Crear y perfeccionar los diagramas de casos de uso. 4. Crear y perfeccionar el modelo conceptual. 5. Crear y perfeccionar el glosario. 6. Definir los diagramas de secuencia de los sistemas. 7. Definir los contratos de operaciones.

8 4.1 Requerimientos funcionales y no funcionales
Algunas de las tareas a realizarse en la etapa de diseño son las siguientes: 1. Definir los casos reales de uso. 2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas. 3. Perfeccionar la arquitectura del sistema. 4. Definir los diagramas de interacción. 5. Definir los diagramas de diseño de clases. 6. Definir el esquema de la base de datos.

9 4.1 Requerimientos funcionales y no funcionales
Los requerimientos son una descripción de las necesidades o deseos de un producto. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita, en una forma en que pueda fácilmente ser transmitido al cliente y al equipo de desarrollo. Se recomienda aquí definir al menos los siguientes puntos: • Panorama general • Metas • Funciones del sistema • Atributos del sistema.

10 4.1 Requerimientos funcionales y no funcionales. Ejemplos.
a) Panorama general: Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizará en las ventas al menudeo. b) Metas: En términos generales, la meta es una mayor automatización del pago en las cajas registradoras, y dar soporte a servicios más rápidos, más baratos y mejores.

11 4.1 Requerimientos funcionales y no funcionales. Ejemplos.
c) Funciones del sistema Las funciones del sistema son lo que éste deberá de hacer. Hay que identificar estas funciones y listarlas en grupos lógicos. Para verificar que X es en verdad una función del sistema, la siguiente frase deberá tener sentido: “El sistema deberá hacer X”. Por ejemplo: “el sistema deberá autorizar pagos a crédito”. Las funciones pueden clasificarse en tres categorías: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas también deben realizarse, y puede que no sean visibles para el usuario. Muchas de estas funciones se omiten (erróneamente) durante el proceso de obtención de requerimientos. Las superfluas son opcionales, y su inclusión no repercute significativamente en el costo ni en otras funciones.

12 4.1 Requerimientos funcionales y no funcionales. Ejemplos.
d) Atributos del sistema Los atributos del sistema son cualidades no funcionales que a menudo se confunden con las funciones: facilidad de uso, tolerancia a fallas, tiempo de respuesta, metáfora de interfaz, plataformas. Por ejemplo: tiempo de respuesta = (psicológicamente correcto) metáfora de interfaz = (gráfico, colorido, basado en formularios)

13 4.1 Requerimientos funcionales y no funcionales.
Algunos atributos del sistema también pueden tener restricciones de frontera del atributo, que son condiciones obligatorias de frontera, generalmente en un rango numérico de valores de un atributo. Por ejemplo: tiempo de respuesta = (dos segundos como máximo) Practica para los equipos: Identifiquen los requerimientos funcionales y no funcionales de su proyecto de software. Definir también el panorama general y las metas. Inclúyalo en su reporte de la practica 7 Fecha limite de entrega:.

14 4.1 Requerimientos funcionales y no funcionales.
Los requerimientos caen en dos categorías, funcionales y no funcionales. Requerimiento funcional: Un requerimiento funcional especifica una acción que deberá ser capaz de desempeñar el producto deseado. Los requerimientos regularmente se expresan en términos de entradas y salidas: dada una entrada específica, el requerimiento funcional estipula cuál debe ser la salida.

15 4.1 Requerimientos funcionales y no funcionales.
Requerimiento No Funcional: Un requerimiento no funcional especifica propiedades del producto deseado en sí, como restricciones de la plataforma (“el producto de software debe ejecutarse en Linux”), tiempo de respuesta (“en promedio, las consultas del Tipo 3B deberán responderse dentro de 2.5 segundos”), o confiabilidad (“el producto de software debe ejecutarse en 99.95% del tiempo”).

16 4.2 Casos de uso Programación Orientada a Objetos Según Booch:
La programación Orientada a Objetos es un método de implementación en el cual los programas están organizados como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son todas miembros de una jerarquía de clases unidas vía relaciones de herencia. Aquí hay tres partes importantes: La programación orientada a objetos: Usa objetos, no algoritmos, como bloques lógicos de construcción (jerarquía "parte de…"). Cada objeto es instancia de alguna clase. Las clases están relacionadas entre si vía relaciones de herencia (jerarquía "tipo de…").

17 4.2 Casos de uso Diseño Orientado a Objetos
El énfasis en métodos de programación está primariamente en el uso adecuado y efectivo de mecanismos de lenguajes particulares. En contraste con esto, los métodos de diseño enfatizan la estructuración adecuada y efectiva de sistemas complejos. Según Booch: Diseño orientado a objetos es un método de diseño que guía el proceso de descomposición orientado a objetos y define una notación para expresar tanto los modelos lógico (estructura de clase y objeto) y físico (arquitectura de módulo y proceso) (tanto estáticos como dinámicos).

18 4.2 Casos de uso Análisis Orientado a Objetos:
El modelo orientado a objetos ha influido incluso en las fases iniciales del ciclo de vida del desarrollo del software. El AOO enfatiza la construcción de modelos del mundo real, utilizando una visión del mundo orientada a objetos.

19 4.2 Casos de uso El modelo de objetos abarca Objeto:
Un objeto es una entidad que tiene un estado y un conjunto definido de operaciones que operan sobre este estado. El estado se representa mediante un conjunto de atributos del objeto. Las operaciones asociadas con el objeto proveen servicios a otros objetos (clientes) que requieren estos servicios cuando necesitan realizar alguna actividad de cómputo. Los objetos se crean de acuerdo a una definición de la clase objeto. La definición de la clase objeto sirve como template para los objetos. Esta incluye las declaraciones de todos los atributos y servicios los cuales deben estar asociados con un objeto de esta clase.

20 4.2 Casos de uso Clase Alumnos Ejemplo:
si se realza el análisis de un sistema de control de alumnos, se tendría que analizar a los alumnos como una clase con atributos y métodos, con atributos como el num_ctrl, nombre, direcc, tel, etc. y métodos como alta de alumno, baja y modificaciones de alumnos. Clase Alumnos num_ctrl Nombre Direcc tel Alta_alumno() Baja_alumno() Modi_alumno()

21 4.2 Casos de uso Objeto Alumno Objeto Alumno Objeto Alumno

22 Grady Booch Grady Booch (nació el 27 de febrero de 1955) es un diseñador de software, un metodologista de software y entusiasta de diseño de patrones. Es director científico de Rational Software (ahora parte de IBM) y editor de una serie de Benjamin/Cummings. En 1995 se recibió como miembro de la Asociación de Maquinaria Computacional (ACM). Fue nombrado socio de IBM en 2003. Booch es mejor conocido por el desarrollo del Lenguaje Unificado de Modelado con Ivar Jacobson y James Rumbaugh. También desarrolló el método Booch de desarrollo de software, el que presenta en su libro, Análisis y Diseño Orientado a Objetos. Él aconseja la adición de más clases para simplificar códigos complejos.

23 4.2 Casos de uso Cómo determinar lo que el cliente necesita
Un concepto que erróneamente se tiene es que, durante el flujo de trabajo de los requerimientos, los desarrolladores deben determinar qué software es el que el cliente quiere. Por el contrario el objetivo real del flujo de los requerimientos es determinar qué software es el que el cliente necesita.

24 4.2 Casos de uso Ejemplo: S. I. Hayakawa ( ), senador estadounidense de California, una vez declaró a un grupo de periodistas: “Yo sé que ustedes creen que entendieron lo que piensan que les dije, pero no estoy seguro de que ustedes se hayan dado cuenta de que lo que escucharon no es a lo que yo me refería”. Esta excusa aplica de igual manera al punto del análisis de requerimientos. Los analistas de sistemas escucharon las peticiones de su cliente, pero lo que ellos escucharon no es lo que el cliente debería estar diciendo.

25 4.2 Casos de uso Flujo de trabajo de los requerimientos:
Comprender el dominio Comprender el dominio, esto es, el ambiente específico en el cual operaría el producto deseado. Ejemplo: bancos, exploración espacial, industria automotriz, industria petroquímica.

26 4.2 Casos de uso Construir el modelo del negocio
Utilizar diagramas UML para describir los procesos de negocio del cliente. Se utiliza para determinar los requerimientos iniciales del cliente.

27 4.2 Casos de uso Comprender el dominio
Para extraer las necesidades del cliente, los miembros del equipo de requerimientos deben familiarizarse con el dominio de la aplicación, esto es, el área general en la cual se usará el producto deseado. Por ejemplo, no es fácil realizar preguntas significativas a un banquero sin antes familiarizarse con la banca. Usar la terminología correcta. Construir un glosario, una lista de palabras técnicas utilizadas en el dominio, junto con sus significados.

28 Comprender el dominio Para una persona común palabras como abrazadera, barra, trabe y poste pudieran ser sinónimos, pero para un ingeniero civil son términos distintos. Si un desarrollador no aprecia que un ingeniero civil utiliza estos cuatro términos en una forma precisa y si el ingeniero civil asume que el desarrollador está familiarizado con las diferencias de estos términos, el desarrollador pudiera tratar los cuatro términos como equivalentes; el software de diseño de puentes asistido por computadora resultante pudiera contener fallas que ocasionarían un colapso del puente. ¿ En quién caería la responsabilidad?

29 4.2 Casos de uso Construir el modelo del negocio
Un modelo de negocio es una descripción de los procesos de negocio de una organización. Por ejemplo: algunos de los procesos de negocio de un banco incluyen aceptar depósitos de los clientes, prestar dinero a los clientes y hacer inversiones. La razón para construir un modelo de negocio se debe primero a que éste proporciona una comprensión del negocio del cliente como un todo.

30 Construir el modelo del negocio
Se pueden utilizar diferentes técnicas para obtener la información necesaria para construir el modelo de negocio: Entrevista Cuestionario Observación directa Cámaras de video

31 Construir el modelo del negocio
Un modelo de negocio: Es un conjunto de diagramas UML que representan uno o más aspectos del producto de software a ser desarrollado. Uno de los principales diagramas UML utilizados en el modelado de negocio es el de caso de uso.

32 4.2 Casos de uso Concepto creado por Jacobson (1986)
Un caso del uso describe una característica del sistema. Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea de negocio. Describen el comportamiento del software o de los sistemas. Muestran los pasos que el actor sigue para realizar una tarea. Los casos del uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Y no permiten determinar los requisitos no funcionales.

33 4.2 Casos de uso Caso de uso Retiro de Dinero
Producto de software del banco Retiro de dinero Cliente Cajero

34 4.2 Casos de uso Ejercicio:
Realizar el diagrama de casos de uso de un cajero automático. Realizar la descripción de los casos de uso.