Interacción Persona - Ordenador
|
|
- Emilia Giménez Cabrera
- hace 5 años
- Vistas:
Transcripción
1 Interacción Persona - Ordenador Análisis de Requisitos (II) Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo
2 Análisis de Requisitos Adquisición o recogida de datos Observación y recolección de datos. Toma informal de notas Análisis etnográfico: Observación del entorno y procedimiento de trabajo Estudio de la audiencia: Usuarios y sus necesidades Análisis de la competencia: Métodos anteriores, versiones previas o aplicaciones similares Análisis e interpretación de la información Sistematización en formularios, siguiendo normas o estándares Objetivos de la aplicación: Descripción de tareas (requisitos, casos de uso) Objetivos de usabilidad y accesibilidad Plataforma hardware y software necesaria. Dispositivos de interacción.
3 Análisis de la información Qué tenemos en este momento? Entrevistas, p. ej con 5 clientes, un directivo y tres trabajadores. Cuestionarios, p. ej. 50 encuestas recogidas de un formulario en internet Anotaciones de la observación, p.ej. notas de dos visitas al centro de trabajo: procesos administrativos, organización, posibles incidencias, etc
4 Análisis de la información Siguiente paso: Análisis e interpretación de la información recogida. Los datos obtenidos serán: Cuantitativos: Obtención de valores numéricos: porcentajes, promedios, medias, desviaciones estándar, etc. Cualitativos: Identificar patrones y/o temas recurrentes, categorización y segmentación de datos y usuarios, análisis de los incidentes críticos. Nota: Hay que tener cuidado con el modo de interpretar la información
5 Análisis de la información Se efectúa mediante sistematización en formularios. La información recogida de manera informal se estructura y se presenta en plantillas siguiendo metodologías estandarizadas, en lo posible: Estándares de facto: empresas, fabricantes Guías de estilo (Windows, ios, Android, Apple ) Estándares de iure: Normas ISO, UNE Metodologías de IS
6 Análisis: Objetivos de la aplicación Además de los requisitos del sistema que veremos no hay que perder de vista los objetivos generales: Objetivos de negocio (de la empresa) Cuáles son las razones de empresa? Cómo determinará la empresa que la aplicación es un éxito? Objetivos de los usuarios Por qué los usuarios van a utilizar esta aplicación y no otra? Si no puedes dar razones para que la usen probablemente fracasará Hay que considerar cómo podemos mejorar nuestro servicio
7 Análisis: Objetivos de la aplicación La información recogida es útil para definir los objetivos de la aplicación. Se definen entonces los requisitos del sistema, es decir, las características que se deben incluir en el sistema. Existen dos tipos de requisitos: Funcionales (RF): Establecen la funcionalidad del sistema qué hace el sistema? Describen las interacciones entre el sistema y el entorno Son independientes de la implementación No funcionales (RNF): Criterios para juzgar cómo opera el sistema Atributos de calidad Restricciones de implementación
8 Análisis: Objetivos de la aplicación Algunos ejemplos de requisitos no funcionales típicos son los siguientes: rendimiento disponibilidad seguridad accesibilidad usabilidad estabilidad portabilidad costo operatividad interoperabilidad escalabilidad concurrencia mantenibilidad interfaz
9 Análisis: Objetivos de la aplicación Es necesario elaborar un catálogo de requisitos que el software deberá satisfacer. Existen diferentes formas de representación de los requisitos: - tablas de requisitos - árboles de decisión - tablas de decisión - casos de uso -...
10 Análisis: Objetivos de la aplicación Representación de Requisitos mediante una tabla: Técnica sencilla de enumeración en una tabla Un requisito se representa con un código y un texto que lo describe La estructura del código es fijada por la organización
11 Análisis: Objetivos de la aplicación Ejemplo: Representación de Requisitos Volere shell (Preece, Rogers & Sharp)
12 Análisis: Objetivos de la aplicación Ejemplo: Representación de requisitos
13 Análisis: Objetivos de la aplicación Representación de Requisitos Funcionales mediante casos de uso:
14 Análisis: Objetivos de la aplicación Casos de uso Un caso de uso especifica el comportamiento de un sistema o de una parte del mismo. Pero no especifica cómo se implementa dicho comportamiento. Describe el funcionamiento del sistema desde el punto de vista del usuario. Se usa fundamentalmente en la fase de análisis de requisitos. Un caso de uso describe la secuencia de interacciones que se producen entre un actor y el sistema. Un caso de uso describe un requisito funcional del sistema. Dos niveles de descripción: diagrama y detallado
15 Análisis: Objetivos de la aplicación Diagrama de caso de uso: Muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Los elementos que pueden aparecer en un diagrama de Caso de Uso son: Actores, Casos de uso y Relaciones.
16 Elementos de un diagrama de casos de uso Casos de uso Un caso de uso tiene un nombre y se representa mediante una elipse. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema. Cada caso de uso puede estar definido por: Texto que lo describe Secuencia de pasos ejecutados dentro del escenario Condiciones pre-post para que el escenario comience o termine Mezcla de las anteriores
17 Elementos de un diagrama de casos de uso Actores Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Esta representación sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.). Los actores no forman parte del sistema, aunque aparecen en los modelos.
18 Elementos de un diagrama de casos de uso Relaciones UML define cuatro tipos de relación en los Casos de Uso: De Comunicación:
19 Elementos de un diagrama de casos de uso Relaciones De Generalización: El caso de uso hijo hereda la especificación del caso de uso padre. El hijo puede añadir o redefinir el comportamiento del padre. El hijo puede ser colocado en cualquier lugar donde aparezca el padre.
20 Elementos de un diagrama de casos de uso Relaciones De Inclusión: un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso (proveedor) en el lugar especificado en el caso base. Representa un comportamiento común del caso de uso. Representa un comportamiento que es reusado (un caso de uso utiliza a otro). Relación de dependencia con estereotipo <<include>> (o <<uses>>)
21 Elementos de un diagrama de casos de uso Relaciones De Extensión: un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso (proveedor) en el lugar especificado indirectamente por el caso proveedor. Se utiliza para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. Separa el comportamiento opcional del obligatorio. También se usa para modelar un subflujo que se ejecuta bajo ciertas condiciones.
22 Ejemplos Diagrama de casos de uso Biblioteca Cajero automático Hay herramientas como Microsoft Visio para generarlos.
23 Construcción del diagrama de casos de uso Para construir el modelo de Casos de Uso en la fase de Análisis se siguen los siguientes pasos: 1. Descripción de uno o varios escenarios El propósito del sistema a desarrollar. El modelo de negocio: determinar los procesos claves del sistema. Los diagramas de actividades para cada proceso. 2. En paralelo se identifican los posibles usuarios del sistema
24 Construcción del diagrama de casos de uso 1. Descripción de escenarios Una técnica muy útil para descubrir el funcionamiento de un sistema desde el punto de vista de los usuarios es la de los escenarios. Un escenario es una descripción textual del funcionamiento típico de un sistema o tarea desde la perspectiva de un usuario concreto. Describe el comportamiento de usuarios representativos. Al menos un escenario por tipo de usuario o actor
25 Construcción del diagrama de casos de uso Ejemplo: Caso de uso: Comprar entradas Ange Schmidt es una clienta de DeustcheSparKasse con un saldo medio de más de Utiliza el cajero para la mayor parte de sus transacciones. A última hora de la tarde de los viernes entra a un cajero de la entidad, se registra, selecciona la operación Comprar entradas, revisa las ofertas para ese fin de semana y selecciona un espectáculo. Si quedan entradas, selecciona dos localidades y las paga. Recoge las entradas y su tarjeta y sale del cajero.
26 Construcción del diagrama de casos de uso 2. Identificación de los posibles usuarios del sistema Se identifican los actores del sistema. En una tabla se especifican todos los casos de uso en el formato de alto nivel. Se dibuja el Diagrama general de Caso de Uso. Se relacionan los casos de uso y se ilustran las relaciones en el Diagrama de Casos de Uso (<<extend>> y <<include>>). 3. Ordenar y describir Ordenar según prioridad los casos de uso para implementar primero los que sean críticos. Documentarlo brevemente.
27 Documentación del diagrama de casos de uso En el esquema la descripción es muy general y se documenta con una descripción breve. Es útil para comprender el ámbito y el grado de complejidad del sistema. Ejemplo: El siguiente Caso de Uso describe el proceso de sacar dinero cuando se está usando un cajero automático. Caso de Uso: Reintegrar efectivo Actores: Cliente Descripción Breve: Un Cliente llega al cajero automático, introduce la tarjeta, se registra y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El cliente coge el dinero, la tarjeta (y el comprobante, si lo desea) y se va.
28 Construcción del modelo detallado (o expandido) Los casos de uso que se consideran más importantes se describen a un nivel más detallado. La principal diferencia con un caso de uso de alto nivel está en que incluye un apartado de curso típico de eventos.
29 Construcción del modelo detallado (o expandido) Ejemplo: Caso de Uso: Nro. de CU: 5 Actores: Propósito: Descripción Breve: Realizar Reintegro Cliente (iniciador) Realizar una operación de reintegro de una cuenta del banco. Un cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El cliente toma el dinero y la tarjeta y se va. Referencias: Curso (Flujo) típico de eventos : Acción del actor 1. En este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero. 3. Introduce la clave. 5. Selecciona la operación de Reintegro. 7. Introduce la cantidad requerida. 10. Recoge la tarjeta. 11. Recoge el recibo. 12. Recoge el dinero y abandona el cajero. CU1, CU2 2.Pide la clave de identificación Respuesta del sistema 4. Presenta las opciones de operaciones disponibles. 6. Pide la cantidad a retirar. 8. Procesa la petición y eventualmente, da el dinero solicitado. 9. Devuelve la tarjeta y genera un recibo. Cursos (Flujos) Alternativos: Línea 4: La clave es incorrecta. Se indica el error y se cancela la operación Línea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operación.
30 Análisis: Objetivos de usabilidad Desde el punto de vista de la empresa: Establecer medidas (cuantitativas) de éxito: Órdenes de compra Acceso a un documento Visitas Descargas Necesitamos un marco formal: Normativa ISO/EN/UNE
31 Análisis: Objetivos de usabilidad Desde el punto de vista del usuario: Cómo aseguramos la eficiencia, eficacia y satisfacción del usuario? Es necesario identificar objetivos cuantificables que permitan medir y valorar si la aplicación es usable Cuánto tiempo pueden invertir los usuarios aprendiendo? Cuántos errores podrían cometer?
32 Definición: Análisis: Objetivos de usabilidad La medida en la que un producto se puede usar por determinados usuarios para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso especificado (ISO ). Un sistema es usable si es fácil de aprender y fácil de utilizar. Para poder hacer sistemas usables hace falta: Comprender los factores psicológicos, ergonómicos, organizativos y sociales. Desarrollar herramientas y técnicas. Conseguir una interacción eficiente, efectiva y satisfactoria.
33 Análisis: Objetivos de usabilidad Definiciones (ISO ): Efectividad: Precisión y grado de consecución con que los usuarios logran objetivos establecidos. Eficiencia: Relación entre los recursos empleados y la precisión y el grado de consecución con que los usuarios logran objetivos establecidos. Satisfacción: Ausencia de incomodidad y existencia de actitudes positivas hacia la utilización del producto.
34 Efectividad Usabilidad: Objetivos Cómo de bueno es el sistema a la hora de hacer lo que se supone debe hacer? Eficiencia Una vez aprendido el manejo se tarda poco en llevar a cabo las tareas? Satisfacción Está el usuario conforme con el sistema? Tiene quejas?
35 Análisis: Otros objetivos de usabilidad Seguridad El sistema protege al usuario de situaciones no deseadas? Permite al usuario recuperarse fácilmente en caso de error? Utilidad El sistema permite hacer todas las tareas que el usuario debe hacer? Facilidad de aprendizaje Puede el usuario aprender por exploración? Cuánto le costaría aprender todas las funcionalidades de esa forma? Facilidad de recuerdo de uso Qué tipo de soporte se le da al usuario para que recuerde cómo llevar a cabo tareas infrecuentes?
36 Análisis: Objetivos de usabilidad Normativa: UNE-EN ISO Componentes de la usabilidad
37 Análisis: Objetivos de usabilidad Normativa: UNE-EN ISO Esta normativa se utiliza para comprobar la usabilidad de un sistema.
38 Análisis: Objetivos de usabilidad Se pueden utilizar los parámetros de medida de ISO también para establecer objetivos de usabilidad: Impresión subjetiva Calificar el sitio como mínimo de 2,5 sobre 7 (elegante ) Tareas realizadas Un 75% de usuarios que intente comprar un artículo llegue al final
39 Análisis: Objetivos de usabilidad Tiempo aprendizaje/tiempo tarea Usar el sitio por primera vez sin entrenamiento < 10 minutos Encontrar un tema por primera vez en menos de 2 minutos Usuarios expertos (5 visitas) menos de 30 segundos Número de errores No visitar más de tres páginas erróneas para visitar una página No cometer errores fatales irrecuperables
40 Análisis: Objetivos de usabilidad UNE-EN ISO
41 Análisis: Objetivos de usabilidad UNE-EN ISO
42 Análisis: Objetivos de usabilidad Al analizar los objetivos de la aplicación hay que tener en cuenta el estudio de la audiencia y el análisis de la diversidad y optar por el diseño adecuado: Diseño generalista: Una interfaz de propósito general para todo el mundo Diseño optimizado: Diseño simple para audiencia reducida y concreta Diseño alternativo: Diferentes interfaces individuales para cada grupo, entorno (móvil u oficina), etc. Diseño multipropósito: Diseño único con partes diferentes para cada sector
43 Análisis: Objetivos de accesibilidad Accesibilidad: Grado en el que un producto, dispositivo, servicio o entorno está disponible para tantas personas como sea posible. Pensar en dotar de funcionalidad total para todos los tipos de discapacidades supone un reto difícilmente alcanzable (amplio abanico de discapacidades, dificultad de personalización, ) Hay que tener en cuenta la necesidad de incorporar dispositivos específicos.
44 Análisis: Objetivos de accesibilidad Para plantear los objetivos de accesibilidad hay que considerar las limitaciones que se van a abordar. Discapacidad Una diferencia individual que supera un límite más o menos arbitrario Muchas de estas discapacidades están presentes en grado diferente entre muchos sujetos considerados normales
45 Análisis: Objetivos de accesibilidad Para plantear los objetivos de accesibilidad hay que considerar las limitaciones que se van a abordar. Tipos de discapacidades: Deficiencias visuales Auditivas Movimiento Cognitivas
46 Análisis: Plataforma HW & SW Entorno informático de trabajo de los usuarios Ordenadores y sistemas operativos Monitores y otros periféricos Considerar diferencias en el dispositivo (móviles, oficina) Considerar diferencias en navegador, en la red
47 Análisis: Plataforma HW & SW Definir la plataforma HW y el entorno SW más adecuado teniendo en cuenta: Análisis etnográfico: considerar el modelo mental del usuario, cómo realiza las tareas, etc. Análisis de la audiencia: considerar el grupo o grupos que utilizarán la aplicación, teniendo en cuenta todos los puntos de vista (edad objetivo, nivel adquisitivo, perfil, etc) Objetivos de la aplicación Objetivos de usabilidad Objetivos de accesibilidad
48 Esbozos: Prototipado de los requisitos El documento de análisis de requisitos suele incluir unos primeros bocetos (prototipo inicial).
49 Evaluación en Análisis de Requisitos Para verificar que los requisitos planteados son adecuados hay que realizar una evaluación Existen numerosas técnicas de evaluación, entre las que destacan: Entrevistas, cuestionarios, grupos de discusión (utilizadas también en la definición de los requisitos) Evaluaciones de tipo recorrido cognitivo Evaluaciones a partir de descripciones formales de escenarios de casos de uso Tests de usabilidad
50 Conclusiones Hacer un buen análisis de los requisitos del sistema a desarrollar es crucial. Debemos conocer quiénes serán nuestros usuarios. Hace falta definir para cada categoría sus necesidades y metas. Debe hacerse un prototipado completo: actores, tareas, relaciones... Se deben definir de forma clara los objetivos de la aplicación, de usabilidad y de accesibilidad para tenerlos en cuenta a la hora de realizar el diseño.
Análisis de Requisitos
Análisis de Requisitos Adquisición o recogida de datos Observación y recolección de datos. Toma informal de notas Análisis etnográfico: Observación del entorno y procedimiento de trabajo Estudio de la
Más detallesAnálisis de Requisitos
Análisis de Requisitos Adquisición o recogida de datos Observación y recolección de datos. Toma informal de notas Análisis etnográfico: Observación del entorno y procedimiento de trabajo Estudio de la
Más detallesInteracción Persona - Ordenador
Interacción Persona - Ordenador Análisis de Requisitos (II) Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Análisis de Requisitos Adquisición o recogida de datos Observación y recolección de
Más detallesTema 1. Proceso de DCU. Técnicas de Análisis
Tema 1. Proceso de DCU. Técnicas de Análisis 30258- Diseño Centrado en el Usuario. Dra. Sandra Baldassarri Análisis de requisitos AR: Adquisición de datos Contenido Técnicas: Observación, Entrevistas,
Más detallesDiagramas de Casos de Uso. Ingeniería del Sw-II, José Merseguer
Diagramas de Casos de Uso 19 Diagramas de Casos de Uso Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje. No pertenece
Más detallesTema 3: Diagramas de Casos de Uso. Arturo Mora Soto Octubre 2008
Tema 3: Diagramas de Casos de Uso Arturo Mora Soto Octubre 2008 Diagrama de casos de uso Para poder dibujar un diagrama de casos de uso utilizando la notación UML es preciso que entendamos conceptualmente
Más detallesTema 9: Método de Craig Larman
Tema 9: Método de Craig Larman Maria-Isabel, Sanchez Segura Arturo, Mora-Soto Diagramas de UML Los diagramas expresan gráficamente partes de un modelo Use Case Use Case Use Case Diagrams Diagramas de Use
Más detallesInteracción Persona - Ordenador
Interacción Persona - Ordenador Análisis de Requisitos (I) Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Modelo de proceso de diseño de la interfaz Análisis de Requisitos Recogida de datos
Más detallesInteracción Persona - Ordenador
Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición
Más detalles4/15/2010. Requerimientos de Software UARG.UNPA Requerimientos de Software. Requerimientos de Software
UARG.UNPA 2009 Un caso de uso es una interacción típica entre un usuario y un sistema computacional.(fowler) Un caso de uso especifica el comportamiento deseado del sistema (objetivos del usuario). (Jacobson)
Más detallesAnálisis y Diseño del Software. El Lenguaje Unificado de Modelado UML 2.0
Análisis y Diseño del Software El Lenguaje Unificado de Modelado UML 2.0 Contenidos Introducción al modelado del software Presentación de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado
Más detallesIngeniería de requerimientos de software: Análisis. Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes
Ingeniería de requerimientos de software: Análisis Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes Referencias El Lenguaje Unificado de Modelado. Grady Booch, James Rumbaugh e Ivar
Más detallesCaso de Uso. Herramienta de relevamiento. domingo, 28 de octubre de 12
Herramienta de relevamiento Son descripciones de un conjunto de secuencia de acciones que ejecuta el sistema para obtener un resultado Los casos de uso especifican un comportamiento deseado, no como se
Más detallesInteracción Persona - Ordenador
Interacción Persona - Ordenador Análisis de Requisitos (I) Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Modelo de proceso de diseño de la interfaz Análisis de Requisitos Recogida de datos
Más detallesEspecificación de Requerimientos <Nombre del Proyecto> Nombre del Grupo de Desarrollo o Asignatura Nombre del Autor
Especificación de Requerimientos Nombre del Grupo de Desarrollo o Asignatura [Este documento es la plantilla base para elaborar el documento Especificación de Requerimientos. Los textos que aparecen entre
Más detallesTema 1. Proceso de DCU. Técnicas de Análisis
Tema 1. Proceso de DCU. Técnicas de Análisis 30258- Diseño Centrado en el Usuario. Dra. Sandra Baldassarri Análisis de requisitos AR: Adquisición de datos Contenido Técnicas: Observación, Entrevistas,
Más detallesTema 4. Usabilidad. Experiencia de Usuario
Tema 4. Usabilidad. Experiencia de Usuario 30258- Diseño Centrado en el Usuario. Dra. Sandra Baldassarri Objetivos Definición e importancia de la usabilidad en el desarrollo de software aplicaciones y
Más detallesAtributos de Calidad del Software
Atributos de Calidad del Software Los usuarios comúnmente se centran en lo que el sistema debe hacer por ellos y no piensan en otros atributos que el software debe tener. Son los analistas los que deben
Más detallesDesarrollo Orientado a Objetos en Métrica v. 3
Desarrollo Orientado a Objetos en Métrica v. 3 Carlos Rossi Jiménez c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.1/45 Estructura del curso 1. Estructura de Métrica v. 3 2. Técnicas orientadas a
Más detallesObjetivos. Plan. Cambios de grupos Prof. sustituto: Alicia Villanueva
Ingeniería de Requerimientos Prácticas Curso 2007/08 Objetivos Aprender el manejo de una herramienta avanzada para el desarrollo rápido de prototipos: Visual Prolog Plan Semana 1: Recomendaciones IEEE
Más detallesDepartamento de Informática Universidad de Valladolid Campus de Segovia TEMA 7, SECCIÓN 1: REQUISITOS SOFTWARE
Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 7, SECCIÓN 1: REQUISITOS SOFTWARE 1 ANÁLISIS DE REQUISITOS Los requisitos determinan lo que debe hacer el sistema así como las
Más detallesTEST (2 0 puntos, 0 20 puntos por pregunta correcta, puntos por error) [Marcar sólo una opción]
EXAMEN FINAL ORDINARIO TEST (2 0 puntos, 0 20 puntos por pregunta correcta, -0 05 puntos por error) [Marcar sólo una opción] Cuál de las siguientes áreas de conocimiento de la ingeniería del software,
Más detallesCristian Blanco
UNIDAD DIDÁCTICA 8. ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS. DIAGRAMAS DE COMPORTAMIENTO En el siguiente enlace tienes una descripción y algunos ejemplos de todos los diagramas UML.: http://jms32.eresmas.net/tacticos/uml/umlindex.html
Más detallesTema 5 Usabilidad y Evaluación
Tema 5 Usabilidad y Evaluación o Usabilidad o Factores Medibles o Métodos de evaluación o Prototipado o Laboratorio de Usabilidad 5.1. Usabilidad Definición o Descripción del modelo conceptual La medida
Más detalles1. Especificación funcional del sistema. (v1.0)
1. Especificación funcional del sistema. (v1.0) Nota: Este documento es un extracto de la documentación funcional de un sistema. También se trata de una primera versión, por lo que incluye notas del equipo
Más detallesNÚMERO DE HORAS: 160H PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE OBJETIVO
PACK FORMATIVO EN DESARROLLO DE APLICACIONES CON TECNOLOGÍA WEB NÚMERO DE HORAS: 160H PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE OBJETIVO - Identificar la estructura de una página web conociendo los lenguajes
Más detallesUnidad III. Análisis y diseño de IHC Modelos de ciclo de vida en el diseño de IHC.
Unidad III Análisis y diseño de IHC 3.1. Modelos de ciclo de vida en el diseño de IHC. Los sistemas interactivos se caracteriza por la importancia del diálogo con el usuario. La interfaz de usuario es
Más detallesAnálisis y Diseño de Sistemas
Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 6 Modelo de Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] 1er. CUATRIMESTRE 2006
Más detallesConstrucción ágil de la Usabilidad
Construcción ágil de la Usabilidad E.Acosta/N.Zambrano Centro Isys - Esc. Computación U.C.V Octubre 2007 Construcción ágil de la Usabilidad 1 Contenido: Usabilidad y definiciones e importancia el contexto
Más detallesCASOS DE USO.
CASOS DE USO Suponga que va a comenzar a desarrollar un sistema Por dónde empieza? Obviamente con el proceso de "levantado de requerimientos", el cual un proceso muy parecido entre un exorcismo y un psicoanálisis,
Más detallesIEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software
IEEE-std-830-1998 Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements Specifications Preparó: Ing. Ismael Castañeda Fuentes
Más detallesGrado de Ingeniería Informática. Consultor: Juan José Cuadrado Gallego Alumno: Isabel Guerra Monclova
Grado de Ingeniería Informática Consultor: Juan José Cuadrado Gallego Alumno: ÍNDICE DE CONTENIDOS Objetivos del proyecto Planificación del proyecto Análisis de requisitos Diseño técnico Construcción Pruebas
Más detallesISO Ingeniería del Software
ISO 9126 Ingeniería del Software ISO 9126 Es un estándar internacional para la evaluación del software. La norma define seis características de la aplicación, estas seis características son divididas en
Más detallesCliente. Generalización. Cliente Comercial
Casos de Uso Análisis y Diseño OO 2008-3 Qué es un caso de uso? Especificación del comportamiento de un sistema ode una parte de este Descripción de un conjunto de secuencia de acciones, incluyendo variantes
Más detallesESCUELA POLITÉCNICA DEL EJÉRCITO EXTENSIÓN LATACUNGA MAESTRÍA EN INGENIERÍA DE SOFTWARE TERCERA PROMOCIÓN
ESCUELA POLITÉCNICA DEL EJÉRCITO EXTENSIÓN LATACUNGA MAESTRÍA EN INGENIERÍA DE SOFTWARE TERCERA PROMOCIÓN TÍTULO DEL PROYECTO: INTEGRACIÓN DE LA USABILIDAD EN EL PROCESO DE DESARROLLO DE SOFTWARE EN LAS
Más detallesQué Necesita el Usuario
Qué Necesita el Usuario Qué Pidió el Usuario Cómo lo Vio el Analista Cómo se Diseñó Cómo lo Escribió el Programador Cómo Funciona el Sistema (en ocasiones...) Qué es? Técnica para la captura de requisitos
Más detalles12/08/2017. Casos de uso. Casos de uso. Casos de uso. Casos de uso
ICI3242 Modelamiento de sistemas de software Escuela de Ingeniería Informática Pontificia Universidad Católica de Valparaíso Los Casos de Uso (Jacobson) describen bajo la forma de acciones y reacciones
Más detallesLABORATORIO DE INTERACCION HUMANO COMPUTADORA MANUAL DE PRÁCTICAS. Practica #1. Identificación del proyecto a Desarrollar
Practica #1 Identificación del proyecto a Desarrollar El alumno definirá el Proyecto a Desarrollar tomando en cuenta las 8 disciplinas que involucra la Interacción Humano Computadora Disciplinas: Computación,
Más detallesDocumentación de Requisitos con Casos de Uso
de Documentación de Requisitos con Casos de Grupo de Ingeniería del Software y Bases de Datos Universidad de Sevilla octubre 2012 de Los son historias que describen interacciones entre: Actores: personas
Más detallesDiagramas de Casos de Uso
Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje. No pertenece realmente al enfoque orientado a objeto, más bien es
Más detallesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No Funcionales Juan Pablo Quiroga Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes Referencia El Lenguaje Unificado de Modelado. Grady Booch, James Rumbaugh
Más detallesANALISIS Y DISEÑO DE SISTEMAS II A.P.U 2008 CASO DE USO UML
CASO DE USO UML Un caso de uso representa una unidad funcional coherente de un sistema, subsistema o clase. En un caso de uso uno o más actores interaccionan con el sistema que realiza algunas acciones.
Más detallesRequerimientos Funcionales y No Funcionales. Juan Pablo Quiroga Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes
Requerimientos Funcionales y No Funcionales Juan Pablo Quiroga Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes 1 Referencia El Lenguaje Unificado de Modelado. Grady Booch, James
Más detallesUML. Diagrama de Casos de Usos. Prof. Daniel Riesco
UML Diagrama de Casos de Usos Prof. Daniel Riesco Diagramas de Caso Uso Secuencia de transacciones desarrolladas por un sistema en respuesta a un evento iniciado por un actor Sirven para especificar la
Más detallesPlaneador de Torneos y Competencias: PLATYCO. Documentación de la Arquitectura de Software
Planeador de Torneos y Competencias: PLATYCO Documentación de la Arquitectura de Software Daniel Santiago Vásquez Acero 22/08/2014 Tabla de figuras Ilustración 1: Modelo "4+1"[1]... 4 Ilustración 2: Servicio
Más detallesTema 4: Diagramas de Casos de Uso
Tema 4: Diagramas de Casos de Uso Maria-Isabel, Sanchez Segura Arturo, Mora-Soto 1 Diagrama de casos de uso Para poder dibujar un diagrama de casos de uso utilizando la notación UML es preciso que entendamos
Más detallesINFORME TECNICO PREVIO DE EVALUACION DE SOFTWARE CP/ASI
1 de 5 INFORME TECNICO PREVIO DE 001-2012-CP/ASI 1. NOMBRE DEL AREA: Dirección de Promoción y Desarrollo. 2. RESPONSABLE DE LA EVALUACION: Segismundo Alzamora León. 3. CARGO: Analista de Sistemas de Información.
Más detallesAnálisis y Diseño de Sistemas Clase 5 Ingeniería de Requerimientos El modelo de Casos de Uso
Metodologías de Desarrollo Análisis y Diseño de Sistemas Clase 5 Ingeniería de Requerimientos El modelo de Lic. María Mercedes Vitturini 1er. CUATRIMESTRE 2007 Dpto. Ciencias e Ingeniería de la Computación
Más detalles@Ejemplo de Casos de Uso Gestión de un Vídeo-Club
@Ejemplo de Casos de Uso Gestión de un Vídeo-Club David Domínguez Tortajada Raúl García Valenzuela - Índice 1. Resumen... 2 2. Introducción... 2 3. Objetivos del sistema... 4 4. Requisitos de almacenamiento
Más detallesUML (Unified Modeling Language) Octubre de 2007
UML (Unified Modeling Language) Octubre de 2007 UML un modelo o pieza de información producido en el proceso de desarrollo de software Un lenguaje para especificar, visualizar y construir artefactos de
Más detallesPerfil Profesional en formato de la SETEC
Perfil Profesional en formato de la SETEC COMPETENCIA GENERAL: TECNOLOGÍA SUPERIOR EN DESARROLLO DE SOFTWARE UNIDADES DE COMPETENCIA: UNIDADES DESCRIPCIÓN UNIDAD DE COMPETENCIA 1 Analizar los requerimientos
Más detallesEspecificación de requisitos de software. Proyecto: [Nombre del proyecto] Revisión [99.99] [Mes de año]
Especificación de requisitos de software Proyecto: [Nombre del proyecto] Revisión [99.99] [Mes de año] Instrucciones para el uso de este formato Este formato es una plantilla tipo para documentos de requisitos
Más detallesLa ingeniería del software es una disciplina de ingeniería que comprende todos los aspectos de la producción de software.
Ingeniería del Software. Ian Sommerville Introducción. Preguntas de introducción. Qué es el software? Programas de ordenador y la documentación asociada. Los productos de software se pueden desarrollar
Más detallesProgramación en lenguajes estructurados de aplicaciones de gestión. Código: J62.13 Nivel: 3
Denominación: Programación en lenguajes estructurados de aplicaciones de gestión Código: J62.13 Nivel: 3 Sector: Familia: Programación informática, consultoría de informática y actividades conexas Tecnología
Más detallesCLASE 4: CASOS DE USO REQUERIMIENTOS. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Martínez
CLASE 4: CASOS DE USO REQUERIMIENTOS Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Martínez Casos de Uso Un caso de uso es una descripción de las posibles secuencias de interacción entre el
Más detallesgestión para una empresa de autobuses que se dedica al transporte regional, nacional e internacional de viajeros. Las
INGENIERÍA DEL SOFTWARE I Práctica 3 Modelado de Requisitos Univ. Cantabria Fac. de Ciencias María Sierra y Patricia López Ejemplo Práctico de Desarrollo de Software El proyecto consiste en el desarrollo
Más detallesUn caso de uso es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se está desarrollando, se representa mediante un óvalo.
Casos de uso Un caso de uso es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se está desarrollando, se representa mediante un óvalo. Consultar información Registrarse Relaciones
Más detallesSISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA
SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA PARA INARGOS LTDA. DOCUMENTO DE ARQUITECTURA DE SOFTWARE VERSIÓN 3.0 BOGOTÁ,
Más detallesModelo de Casos de Uso y Representación en UML. Análisis y Diseño de Sistemas de Información UNIDAD 5
Modelo de Casos de Uso y Representación en UML Análisis y Diseño de Sistemas de Información UNIDAD 5 Modelo de Casos de Uso El modelo de Casos de Uso es una colección de escenarios de éxito y errores que
Más detallesEjercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO
Ejercicio Guiado de Análisis y Diseño Orientado a Objetos Ejemplo: CAJERO AUTOMÁTICO El siguiente ejercicio muestra las diferentes actividades que se realizan dentro del desarrollo de un producto software
Más detallesIEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software
IEEE-std-830-1998 Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements Specifications Preparó: Ing. Ismael Castañeda Fuentes
Más detallesRECURSOS DIGITALES EXPERIENCIAS DEL USUARIO (UX) Maestro: Carlos Alberto Rodríguez. Alumno: Ana Cristina Maldonado Rodríguez Matricula:
RECURSOS DIGITALES EXPERIENCIAS DEL USUARIO (UX) Maestro: Carlos Alberto Rodríguez Alumno: Ana Cristina Maldonado Rodríguez Matricula: 1668857 Experiencia del usuario (UX) En la actualidad, se bombardea
Más detallesMAESTRÍA EN INGENIERÍA DE SOFTWARE TERCERA PROMOCIÓN
MAESTRÍA EN INGENIERÍA DE SOFTWARE TERCERA PROMOCIÓN DESARROLLO DE UN MARCO DE ADAPTACIÓN DE LA INGENIERÍA DE LA USABILIDAD AL PROCESO DE DESARROLLO ÁGIL SCRUM, APLICADO EN EL DEPARTAMENTO DE PLANIFICACIÓN
Más detallesA. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013
Tema 2.2: Modelo de Casos de Uso A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013 Artefacto: actor ACTOR es alguien que interactúa con el sistema: Un tipo de usuario (persona) Otro sistema externo
Más detallesRegistrar información o datos de una persona REQUERIMIENTO QUE LO UTILIZA O ESPECIALIZA:
1 REQUERIMIENTOS FUNCIONALES INTIFICADOR: R1 Registrar información o datos de una persona Si Alta Número y tipo de documento Apellidos y Nombres completos Dirección Teléfono Firma DOCUMENTOS VISUALIZACIÓN
Más detallesInterfaz de usuario Donantonio
Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3
Más detallesRequerimientos de Software
Requerimientos de Software Ingeniería de Requerimientos Se define como el proceso de establecer los servicios que el consumidor requiere de un sistema y las restricciones sobre las cuales de funcionar
Más detallesCaso de Uso. Por ejemplo. Sistema. Actor Actor
Casos de Uso Los diagramas de clases proporcionan una idea estática del sistema. Los diagramas de casos de uso establecen una idea dinámica, es decir que cambian con el tiempo. Los diagramas de casos de
Más detallesRESUMEN ESCRITURA DE REQUERIMIENTOS SOFTWARE
Brandon Campos Calderón Dr. Jaime Solano Soto Ingeniería en Computación RESUMEN ESCRITURA DE REQUERIMIENTOS SOFTWARE INSTITUTO TECNOLÓGICO DE COSTA RICA Tabla de Contenidos Resumen Escritura de Requerimientos
Más detallesPROYECTO ENTORNOS DE USUARIO. Parte 1. Análisis del Entorno de Usuario
PROYECTO ENTORNOS DE USUARIO Parte 1. Análisis del Entorno de Usuario Obtener los requerimientos iniciales del entorno, en lo que respecta a la aplicación, el usuario y las tareas principales del entorno.
Más detallesTema 2. Casos de Uso C H R I STO PHER E X P Ó S I TO I Z Q U I ERDO A I R A M E X P Ó S I TO M Á R Q UEZ I S R A E L LÓ P EZ P L ATA M A R Í A B E L
Tema 2. Casos de Uso C H R I STO PHER E X P Ó S I TO I Z Q U I ERDO A I R A M E X P Ó S I TO M Á R Q UEZ I S R A E L LÓ P EZ P L ATA M A R Í A B E L É N M E L I Á N BAT I STA J O S É MARCOS M O R E N O
Más detallesUNIVERSIDAD MAYOR DE SAN ANDRÉS PROYECTO DE GRADO
UNIVERSIDAD MAYOR DE SAN ANDRÉS FACULTAD DE CIENCIAS PURAS Y NATURALES CARRERA DE INFORMÁTICA PROYECTO DE GRADO SOFTWARE EDUCATIVO PARA LA ENSEÑANZA DE ORTOGRAFÍA CASO: MINISTERIO DE EDUCACIÓN PARA OPTAR
Más detallesIngeniería de Requisitos
Ingeniería de Requisitos Conceptos Básicos Departamento de Ciencias de la Computación Universidad de Chile Andrés Vignaga Requisitos Un requisito se define como: Una capacidad o condición que un sistema
Más detalles2.12 Control estadístico vs métricas.
2.12 Control estadístico vs métricas. PRODUCIR UN SISTEMAS, APLICACIÓN O PRODUCTO DE ALTA CALIDAD Para lograr este objetivo se deben emplear métodos efectivos junto con herramientas modernas dentro del
Más detallesProgramación Avanzada. Requerimientos de Software
Programación Avanzada Requerimientos de Software Contenido Especificación de Requerimientos Tipos de Requerimientos Requerimientos Funcionales Casos de Uso Programación Avanzada Requerimientos de Software
Más detallesIngeniería de Software
Ingeniería de Software 1 Ingeniería de Sistemas Enfoque en variedad de elementos Análisis, diseño y organización de los elementos en un sistema Todo para generar un producto, servicio o tecnología para
Más detallesANEP UTU MALDONADO NOMBRE DEL PROYECTO ASIGNATURAS
ANEP UTU MALDONADO NOMBRE DEL PROYECTO ASIGNATURAS Análisis y Diseño de Aplicaciones Formación Empresarial Programación III Proyecto Sistemas de Bases de Datos II Sistemas Operativos
Más detallesPROTOCOLO PARA LA EVALUACIÓN DE LAS PROPUESTAS DE LOS PLANES DE MEJORA DE LA GESTIÓN Y GARANTÍA DE LA CALIDAD DE LOS SERVICIOS DE LA UNIVERSIDAD DE
PROTOCOLO PARA LA EVALUACIÓN DE LAS PROPUESTAS DE LOS PLANES DE MEJORA DE LA GESTIÓN Y GARANTÍA DE LA CALIDAD DE LOS SERVICIOS DE LA UNIVERSIDAD DE GRANADA Este protocolo tiene como finalidad facilitar
Más detallesMÓDULOS DE DISEÑO EN INGENIERÍA
MÓDULOS DE DISEÑO EN INGENIERÍA El diseño de productos tecnológicos (artefactos, procesos, sistemas e infraestructura) está en el centro de la naturaleza de la ingeniería. El diseño en ingeniería es un
Más detallesINGENIERÍA DEL SOFTWARE
INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE 1 Sesión No. 3 Nombre: Tipos Contextualización Cuál es la importancia de los requisitos de software? Como hemos mencionado en las sesiones anteriores, los
Más detallesTécnicas de Pruebas de
Técnicas de Pruebas de Software Lecturas Pruebas de Unidades Pruebas Integración Docente Beatriz E. Florián bflorian@eisc.edu.co Mayo 3 de 2005 Pruebas Reglas de oro para pruebas Límites de Pruebas: Probar
Más detallesTema 4e: Proceso Unificado: Análisis
Tema 4e: Proceso Unificado: Análisis Marcos López Sanz Índice Visión general Diagramas UML Artefactos Modelo de análisis Clases de análisis Realización en análisis de los casos de uso Paquetes de análisis
Más detallesMODULO IV. Análisis y Diseño de Sistemas de Información INF-162 IV. UML. Casos de uso. Facilitador: Miguel Cotaña
MODULO IV Análisis y Diseño de Sistemas de Información INF-162 IV. UML Casos de uso Facilitador: Miguel Cotaña 1 INTRODUCCION Analista de negocios no-it: es alguien que trabaja dentro del contexto del
Más detallesUn caso de uso es la descripción de cómo en un determinado escenario el software será empleado en una situación determinada.
4 4.0 Casos de uso 4.1 Definición general Un caso de uso es la descripción de cómo en un determinado escenario el software será empleado en una situación determinada. El desarrollador del software creara
Más detallesEspecificación de requisitos de software
Especificación de requisitos de software Proyecto: Desarrollo de un sistema recomendador web para la toma de decisiones durante el proceso de adquisición de equipos de cómputo utilizando árboles de decisión.
Más detallesProgramación Orientada a Objetos
Programación Orientada a Objetos PROGRAMACIÓN ORIENTADA A OBJETOS 1 Sesión No. 8 Nombre: El Modelo de diseño con UML Contextualización Los modelos que podemos crear con UML son varios, por lo que debemos
Más detallesLa Internet Vocal: Aplicación de
La Internet Vocal: Aplicación de la tecnología SALT para la navegación multimodal en Internet Ana Isabel Obregón Cuesta obregon@tid.es Telefónica Investigación y Desarrollo Código 00/00 2 Índice de la
Más detallesTEMA 18: Selección de paquetes informáticos: Metodologías, criterios de valoración y ventajas sobre el desarrollo propio.
Tema 18 Selección de paquetes informáticos TEMA 18: Selección de paquetes informáticos: Metodologías, criterios de valoración y ventajas sobre el desarrollo propio. Índice 1 INTRODUCCIÓN 1 2 METODOLOGÍAS
Más detallesCLASE 3: UML DIAGRAMAS CASOS DE USO. Universidad Simón Bolívar. Ingeniería de Software. Prof. Ivette Martínez
CLASE 3: UML DIAGRAMAS CASOS DE USO Universidad Simón Bolívar. Ingeniería de Software. Prof. Ivette Martínez UML UML es un lenguaje para especificar, visualizar, construir y documentar los artefactos de
Más detallesComo probar los casos de uso
Como probar los casos de uso Objetivos Javier Gutiérrez / javierj@us.es Presentación del seminario Objetivo: Mostrar un rápido resumen de las ideas que desarrollaremos en las próximas horas. 1 Índice 1.
Más detallesoctubre de 2007 Arquitectura de Software
octubre de 2007 Arquitectura de Software Seis mejores Prácticas Desarrollo Iterativo Administrar Requerimientos Usar Arquitecturas basadas en Componentes Modelado Visual (UML) Verificar Continuamente la
Más detallesdiagramas de comportamiento con UML.
U.T.7: Elaboración de diagramas de comportamiento con UML. [Fuente: Entornos de Desarrollo, Alicia Ramos, Ed.Garceta] [Fuente: EL LENGUAJE UNIFICADO DE MODELADO, Grady Booch, James Rumbaugh, Ivar Jacobson,
Más detallesCuestionario global de Interacción Humano-Computadora
Cuestionario global de Interacción Humano-Computadora 1er parcial 1. Describa el proceso de interacción y sus componentes. La interacción es el intercambio de acciones entre uno o más entidades en el cual
Más detallesEjemplo: Caso de Uso: Registrar perfil de ADN Ejemplo: Caso de Uso: Pagar factura Ejemplo: Cajero Automático
Ejercicios Análisis Ejemplo: Caso de Uso: Registrar perfil de ADN Ejemplo: Caso de Uso: Pagar factura Ejemplo: Cajero Automático Análisis e Ingeniería de Requisitos Tema 3 www.kybele.urjc.es AIR - 29 Lista
Más detallesISO ISO Calidad de Software. Virginia Cuomo Mariela Castares
ISO 9126 - ISO 14598 Calidad de Software Virginia Cuomo Mariela Castares 1 Agenda Calidad de Producto ISO 9126 / ISO 14598 2 Calidad de Producto Calidad: El conjunto de características de una entidad que
Más detallesSistema de Administración de Farmacias Modelo de Diseño Versión 1.0. Historia de revisiones
Sistema de Administración de Farmacias Modelo de Diseño Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 14/09/2014 1.0 Versión Inicial Guillermo López 14/09/2014 1.0 Revisión. SQA Modelo
Más detallesDESCRIPCIÓN ESPECÍFICA NÚCLEO: Núcleo Sector Comercio y Servicios.
DESCRIPCIÓN ESPECÍFICA NÚCLEO: Núcleo Sector Comercio y Servicios. SUBSECTOR: Informática y Comunicación. Nombre del Módulo: Modelación y Diagramación total: 68 horas Objetivo General: Modelar la solución
Más detalles