La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

UNIDAD 4. ANÁLISISDELOSREQUERIMIENTOS OBJETIVO DE LA UNIDAD: Aplicar los requerimientos correspondientes a su proyecto, diseñará las interfaces de usuario.

Presentaciones similares


Presentación del tema: "UNIDAD 4. ANÁLISISDELOSREQUERIMIENTOS OBJETIVO DE LA UNIDAD: Aplicar los requerimientos correspondientes a su proyecto, diseñará las interfaces de usuario."— Transcripción de la presentación:

1 UNIDAD 4. ANÁLISISDELOSREQUERIMIENTOS 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 Reglas en el diseño de IGU 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. Trabajo por equipos en el centro de computo Diseño de interfaz Exposición del docente y trabajo en equipo

4 Tema Fecha (s) Modalidad Practica 8. Entrega del reporte de la practica 9 y trabajo por equipos en el centro de cómputo 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 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. 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. 4.1 Requerimientos funcionales y no funcionales

7 Algunas de las tareas a realizarse en la etapa de análisis son las siguientes: 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: 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: 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. Panorama general Metas Funciones del sistema Atributos del sistema.

10 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. 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. 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. 4.1 Requerimientos funcionales y no funcionales. Ejemplos.

11 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. 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. 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. 4.1 Requerimientos funcionales y no funcionales. Ejemplos.

12 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. 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) 4.1 Requerimientos funcionales y no funcionales. Ejemplos.

13 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. 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:. Inclúyalo en su reporte de la practica 7 Fecha limite de entrega:. 4.1 Requerimientos funcionales y no funcionales.

14 Los requerimientos caen en dos categorías, 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. 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 Un requerimiento no funcional especifica propiedades del producto deseado en sí, como restricciones de la plataforma (el producto de software debe ejecutarse en Linux), 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 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). confiabilidad (el producto de software debe ejecutarse en 99.95% del tiempo).

16 4.2 Casos de uso Programación Orientada a Objetos Programación Orientada a Objetos Según Booch: Según Booch: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. 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: 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…"). Usa objetos, no algoritmos, como bloques lógicos de construcción (jerarquía "parte de…"). Cada objeto es instancia de alguna clase. Cada objeto es instancia de alguna clase. Las clases están relacionadas entre si vía relaciones de herencia (jerarquía "tipo de…"). 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 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. 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). 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: 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. 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. 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. 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. 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. 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. 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. num_ctrlNombreDirecctel Alta_alumno() Baja_alumno() Modi_alumno()

21 4.2 Casos de uso Objeto Alumno

22 Grady Booch 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 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 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. 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. 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. 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. 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: Flujo de trabajo de los requerimientos: 1.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. 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 2.Construir el modelo del negocio Utilizar diagramas UML para describir los procesos de negocio del cliente. Utilizar diagramas UML para describir los procesos de negocio del cliente. Se utiliza para determinar los requerimientos iniciales del cliente. Se utiliza para determinar los requerimientos iniciales del cliente.

27 4.2 Casos de uso 1.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. 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. Usar la terminología correcta. Construir un glosario, una lista de palabras técnicas utilizadas en el dominio, junto con sus significados. 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. 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. 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 2.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 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, aceptar depósitos de los clientes, prestar dinero a los clientes prestar dinero a los clientes y hacer inversiones. 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. 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: Se pueden utilizar diferentes técnicas para obtener la información necesaria para construir el modelo de negocio: Entrevista Entrevista Cuestionario Cuestionario Observación directa Observación directa Cámaras de video Cámaras de video

31 Construir el modelo del negocio Un modelo de 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. 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. 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) Concepto creado por Jacobson (1986) Un caso del uso describe una característica del sistema. 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. 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. Describen el comportamiento del software o de los sistemas. Muestran los pasos que el actor sigue para realizar una tarea. 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á. 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. Y no permiten determinar los requisitos no funcionales.

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

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


Descargar ppt "UNIDAD 4. ANÁLISISDELOSREQUERIMIENTOS OBJETIVO DE LA UNIDAD: Aplicar los requerimientos correspondientes a su proyecto, diseñará las interfaces de usuario."

Presentaciones similares


Anuncios Google