Clase 5. Disciplina de Requerimientos

DISCIPLINA DE REQUERIMIENTOS
Requerimientos
Propsito
Establecer y mantener el acuerdo con los clientes y otros stakeholders en lo que el sistema debe hacer. Proporcionar a los diseadores del sistema un buen entendiendo de los requerimientos del sistema. Definir los lmites de (fronteras) el sistema. Proveer una base para la planificacin del contenido tcnicos de iteraciones. Proveer una base para la estimacin de costo y tiempo para desarrollar el sistema. Definir una interfaz de usuario para el sistema, enfocando en las necesidades y metas de los usuarios.
TOPICOS AVANZADOS II
Requerimientos
Requerimientos: Actividades
Requerimientos: Artefactos
Requerimientos
Los Artefactos
Un documento Visin, un modelo de casos de uso, los casos de uso y la Especificacin Suplementaria son desarrollados para describir el sistema totalmente - lo que el sistema har - en un esfuerzo que ven todos los stakeholders, incluso clientes y los usuarios potenciales, como las fuentes importantes de informacin (adems de los requerimientos del sistema).
Requerimientos
Los Artefactos El documento Visin
El documento Visin provee una visin completa del sistema de software bajo el desarrollo y apoya el contrato entre los procuradores y la organizacin de desarrollo. Cada proyecto necesita una fuente para capturar las expectativas de los stakeholders. El documento visin es escrito desde perspectiva de los clientes, enfocndose en los rasgos esenciales del sistema y los niveles aceptables de calidad.
La Visin debe incluir una descripcin de qu rasgos sern incluidos as como aqullos que se consideraron pero no se incluyeron. Tambin debe especificar las capacidades operacionales, el perfil del usuario (quin estar usando el sistema), y las interfaces interoperacionales con las entidades fuera del lmite del sistema dnde sea aplicable. El documento de Visin mantiene la base contractual de los requerimientos visible a los stakeholders.
Requerimientos
Los Artefactos El Modelo de Casos de Uso
El modelo de casos de uso debe servir como un medio de comunicacin y puede servir como un contrato entre el cliente, los usuarios, y los diseadores del sistema con respecto a la funcionalidad del sistema, lo cual permite que: Los Clientes y usuarios puedan validar que el sistema se volver lo que ellos esperaron. Los Diseadores del sistema puedan construir lo que se espera.
El modelo de casos de uso consiste en casos de uso y actores. Cada caso de uso en el modelo se describe en detalle, mostrando paso a paso cmo el sistema acta recprocamente con los actores, y lo que el sistema hace en el caso de uso. La funcin de casos de uso unificar a lo largo del ciclo de vida del software; el mismo modelo de caso de usos se usa en el anlisis del sistema, diseo, implementacin y prueba.
Requerimientos
Los Artefactos Las Especificaciones Suplementarias
Las Especificaciones Suplementarias son un complemento importante del modelo de casos de uso, porque juntos capturan todos los requerimientos del software (funcionales y no funcionales) que son necesarios para servir como una especificacin de requerimientos de software completa.
Los Artefactos Plan de Administracin de Requerimientos

Un Plan de Administracin de Requerimientos especifica la informacin y los mecanismos de control que se definirn y usarn para medir, informar, y controlar los cambios a los requerimientos del producto.
Requerimientos
Los Artefactos Otros artefactos complementarios
Complementariamente a los anteriores artefactos, los artefactos siguientes tambin se desarrollan: Glosario Storyboard de los Casos de Uso Prototipo de la Interfaz de Usuario El Glosario es importante porque define una terminologa comn que se usa de forma consistente por el proyecto u organizacin. El Storyboard de los Casos de Uso y el Prototipo de la Interfaz de Usuario son resultados de Modelado de la Interfaz de Usuario y Prototipado que se hace en paralelo con otras actividades de requerimientos. Estos artefactos mantienen los mecanismos de la retroalimentacin importantes en las iteraciones posteriores para descubrir los requerimientos desconocidos o inciertos.
Requerimientos
Relacin con Otras Disciplinas
La disciplina de Modelado de Negocio proporciona a las Reglas de Negocio, el Modelo de Casos de Uso de Negocio y una Modelo del Objeto de Negocio, incluyendo el Modelo de Dominio y un contexto organizacional para el sistema. El Anlisis y Diseo es la disciplina que consigue su entrada primaria (el modelo de casos de uso y el glosario) de los Requerimientos. Pueden descubrirse fallas en el modelo caso de uso durante el anlisis & diseo; se generan las demandas de cambio, aplicado al modelo de caso de usos. La disciplina de Prueba, prueba el sistema para verificar el cdigo contra el modelos de casos de uso. Los Casos del uso y las Especificaciones Suplementarias proporcionan la entrada en requerimientos usados para planear y disear las pruebas.
Requerimientos
Relacin con Otras Disciplinas
La disciplina de Configuracin y Administracin del Cambio provee el mecanismo de control de cambio de los requerimientos. El mecanismo para proponer un cambio es someter una Demanda de Cambio la cual es revisada por todo el Equipo de Control de Cambio. La disciplina de Administracin de Proyecto planea el proyecto y cada iteracin (descrito en un Plan de la Iteracin). El modelo de casos de uso y el Plan de Administracin de Requerimientos son las entradas importantes para la planificacin de las actividades de cada iteracin. La disciplina de Ambiente desarrolla y mantiene los artefactos de apoyo que se usan durante la administracin de requerimientos y el modelado de los casos de uso, as como las Pautas de Modelado de Caso de Uso y Pautas de Interfaz Usuario
Conceptos: Requerimientos
Un requerimiento se define como "una condicin o capacidad a que un sistema debe contener.
Hay muchos tipos diferentes de requerimientos. Una categorizarlos es descrita como modelo FUCDS+ [GRA92]: Funcionalidad Usabilidad Confiabilidad Desempeo Soporte El "+" en FUCDS+ le recuerda que incluya los tales requerimientos como: Diseo de restricciones Requerimientos de aplicacin Requerimientos de interfaz Requerimientos fsicos manera de
Funcionalidad
Los requerimientos funcionales pueden incluir: Las Caractersticas las Capacidades la Seguridad
Usabilidad Los requerimientos de usabilidad pueden incluir subcategoras como: Factores Humanos Esttica la consistencia en la interfaz del usuario (vea las Pautas: La usuariointerfaz) la ayuda en lnea y contexto-sensible los wizards y agentes la documentacin del usuario los materiales de entrenamiento
Confiabilidad
Los requerimientos de confiabilidad a ser considerado son: La frecuencia y severidad de la falla Capacidad de recuperacin Previsibilidad Exactitud El tiempo entre fallas (MTBF)
Desempeo
Un requerimiento de desempeo impone las condiciones sobre los requerimientos funcionales. Por ejemplo, para una accin dada, puede especificar los parmetros de desempeo para: la velocidad la eficacia la disponibilidad la exactitud el tiempo de respuesta el tiempo de la recuperacin el uso del recurso
Soporte o Supportability
Los requerimientos de Soporte pueden incluir: La testability o capacidad de prueba: el grado a que un sistema o el componente facilita el establecimiento de criterio de la prueba y el desempeo de las pruebas para determinar si los criterios se han conseguido [IEEE 90]. Nota: testability no es slo una medida para el software, tambin puede aplicar a los esquema de prueba. La adaptabilidad la facilidad con que el software satisface diferentes restricciones del sistema y necesidades del usuario. La mantenibilidad la facilidad con que un sistema de software o componente puede modificarse para corregir las fallas, mejorar su desempeo, u otros atributos, o adaptarse a un ambiente cambiante.
La compatibilidad la habilidad de dos o ms sistemas o componentes de realizar sus funciones requeridas mientras comparten el mismo hardware o ambiente del software.
Soporte o Supportability
Los requerimientos de Soporte pueden incluir: La capacidad de servicio o serviceability La instalabilidad: de fcil instalacin La locabilizacion: El proceso de adaptar un programa para un mercado internacional especfico que incluye traduccin de la interfaz del usuario, el resizing de las cajas de dialogo, personalizando caractersticas (si necesario), y probar los resultados para asegurar que el programa todava trabaja. La Internacionalizacin: El proceso de desarrollar un programa central cuyas caractersticas de diseo y diseo del cdigo no hace asunciones basadas en un solo idioma o sitio y de quien la base de cdigo de fuente simplifica la creacin de ediciones del idioma diferentes de un programa.
Requerimientos de Diseo
Un requerimiento diseo, a menudo llamado una especifica o restringe el diseo de un sistema Requerimientos de Implementacin Un requerimiento de implementacin especifica o restringe la codificacin o construccin de un sistema. Los ejemplos son: las normas requeridas los idiomas de aplicacin las polticas para la integridad de la base de datos los lmites del recurso los ambientes de operacin restriccin de diseo,
Requerimientos de Interfaz
Un requerimiento de interfaz especifica: un tem externo con el cual el sistema debe interactuar una restriccin de formato, tiempo u otros factores usados en la interaccin Requerimiento Fsico Un requerimiento fsico especifica una caracterstica fsica que un sistema debe poseer; por ejemplo, material forma tamao peso
Este tipo de requerimiento puede usarse representar los requerimientos del hardware, como las configuraciones de la red fsicas requeridas.
Conceptos: Administracin de Requerimientos

Que es la Administracin de Requerimientos?
La administracin de requerimientos es que es un acercamiento sistemtico a determinar, organizar, y documentar los requerimientos del sistema, y establecer y mantener el acuerdo entre el cliente y el equipo de proyecto en relacin con los requerimientos cambiantes del sistema. La clave de una administracin efectiva de los requerimientos incluye mantener una declaracin clara de los requerimientos, junto con los atributos aplicables para cada tipo de requerimiento y el seguimiento con otros requerimientos y otros artefactos del proyecto. Recolectar requerimientos puede parecer una tarea bastante sencilla. En los proyectos reales, sin embargo, usted se encontrar con dificultades debido a: Los requerimientos no siempre son obvios, y puede venir de muchas fuentes. Los requerimientos no siempre son fciles de expresar claramente en las palabras.

Que es la Administracin de Requerimientos?
Hay muchos tipos diferentes de requerimientos a diferentes niveles de detalle y tambin se relacionan entre si y con otros entregables del proceso de ingeniera de software. E igualmente, los requerimientos cambian. Hay que muchas partes interesadas, lo que significa que los requerimientos necesitan ser manejados por los grupos de personas que realizan distintas funciones. Para ayudarle a manejar estas dificultades, las habilidades siguientes son importantes: El anlisis del problema Comprender las necesidades del stakeholder Definir el sistema Manejar el alcance del proyecto Refinar la definicin del sistema Manejar los requerimientos cambiantes

Anlisis del Problema
El anlisis del problema se hace para entender los problemas, las necesidades iniciales de los stakeholder, y proponer soluciones de alto nivel. Es un acto de razonar y analizar para encontrar "el problema detrs del problema". Durante el anlisis del problema, se busca llegar al/los problem(as) real(es), y determinar quin son los stakeholders.
Tambin, se define desde la perspectiva de negocio cuales son los lmites de la solucin, as como los las restricciones de negocio que ataen a la solucin.
Se debe de haber analizado el caso de negocio para el proyecto, para que exista un buen entendimiento del retorno que se espera en la inversin hecha en el sistema a construirse.

Entendiendo las Necesidades de los Stakeholders
Los requerimientos provienen de muchas fuentes, los ejemplos seran clientes, socios, usuarios finales, y expertos del dominio. Usted necesita saber cmo determinar las mejores fuentes, acceder a esas fuentes, y tambin cmo obtener la mejor informacin de ellos. Si usted est desarrollando un sistema de informacin a ser usado internamente dentro de su compaa, usted puede incluir en el proyecto a personas como: el usuario final con experiencia y al especialista de dominio del negocio en su equipo de desarrollo. Si usted est desarrollando un producto a ser vendido a un lugar del mercado, usted puede hacer uso extenso de sus personas de mercadeo para entender bien las necesidades de los clientes en ese mercado.

Entendiendo las Necesidades de los Stakeholders
Las actividades para descubrir requerimientos pueden requerir el uso de tcnicas como: entrevistas, tormenta de ideas, prototipos conceptuales, encuestas, y el anlisis competitivo. El resultado del estas actividades es una lista de demandas o necesidades que se describen textual y grficamente, y que se han priorizado entre si.

Definiendo el Sistema
Definir el sistema significa traducir y organizar las necesidades de los stakeholders en una descripcin significante del sistema a ser construido. Temprano en la definicin del sistema, las decisiones son hechas sobre qu constituye un requerimiento, el formato de la documentacin, la formalidad del idioma, el grado de especificidad de requerimientos (cuntos y en qu detalle), la prioridad requerida y el esfuerzo estimado, tcnico y manejo de riesgos, y el alcance inicial.
Parte de esta actividad puede incluir los prototipos tempranos y el modelo de diseo directamente relacionado a las demandas de los stakeholders ms importantes.
El resultado de definicin del sistema es una descripcin del sistema en lenguaje natural y grfico.

Manejando el Alcance del Proyecto
Para una eficiente acometida de un proyecto, es necesario priorizar cuidadosamente los requerimientos, basado en las entradas provedas por los stakeholders y administrando su alcance. Demasiado proyectos sufren de desarrolladores trabajando en lo llamado "Easter eggs (caractersticas que el desarrollador cree interesante y desafiante) en vez de enfocarse en las tareas que pueden minimizar riesgo en el proyecto o estabilizar la arquitectura de la aplicacin.
Para asegurarse que se resuelve o mitiga los riesgos lo ms pronto posible en un proyecto, se debe desarrollar el sistema incrementalmente, escogiendo los requerimientos cuidadosamente para cada incremento. Para hacer esto, es necesario negociar el alcance (de cada iteracin) con los stakeholders del proyecto.

Refinando la Definicin del Sistema
La definicin detallada del sistema necesita ser presentada de tal manera que sus stakeholders pueden entender y estar de acuerdo con esta. Necesita no slo cubrir la funcionalidad, sino tambin con cualquier requerimiento legal o regulador, usabilidad, fiabilidad, desempeo, soportabilidad y mantenibilidad. Usted debe hacer el esfuerzo para que la audiencia entienda los documentos que se estn produciendo para describir el sistema. Usted puede ver a menudo una necesidad de producir tipos diferentes de descripcin para pblicos diferentes. Se sabe que la metodologa de casos de uso, a menudo en combinacin con los prototipos visuales simples, es una manera muy eficaz de comunicar el propsito del sistema y definir los detalles del sistema. Los casos de uso ayudan a colocar los requerimientos en un contexto, ya que ellos muestran cmo el sistema se usar.

Refinando la Definicin del Sistema
Otro componente de la definicin detallada del sistema es declarar cmo el sistema debe probarse. Los planes de la prueba y definiciones de qu pruebas se van a realizar dicen qu capacidades del sistema se verificarn.

Administrando los Cambios de Requerimientos
No importa cuan cuidadoso sea usted para definir sus requerimientos, habr siempre cosas que cambian. Lo que hace complejo de manejar los requerimientos cambiantes no es slo lo que implica un requerimiento cambiado o el tiempo tiene que ser gastado en llevar a cabo una nueva caracterstica en particular, sino que un cambio en un requerimiento puede tener impacto en otros requerimientos. Es necesario asegurarse de poseer una estructura de sus requerimientos que es elstica a los cambios, y que se usan los links de traceabilidad para representar las dependencias entre los requerimientos y otros artefactos del ciclo de vida del desarrollo. La administracin del cambio las actividades como establecer una lnea base, determinar cuales dependencias son importantes rastrear, establecer la traceabilidad entre los artculos relacionados, y el control de cambio.
Conceptos: Traceability o Traceabilidad

Introduccin
Traceabilidad es la habilidad de rastrear un elemento del proyecto con otros elementos relacionados del proyecto, sobre todo aqullos requerimientos relacionados. Elementos del proyecto involucrados en la traceabilidad se llaman artculos del traceabilidad. Los artculos del traceabilidad tpicos incluyen diferentes tipos de requerimientos, modelos de anlisis y diseo de elementos, artefactos de pruebas (los casos de prueba, los procedimientos de la prueba, etc.), y documentacin de apoyo del usuario final y material de entrenamiento.

Propsito de la Traceabilidad
Entender la fuente de requerimientos Manejar el alcance del proyecto Manejar los cambios a los requerimientos Evaluar el impacto en el proyecto de un cambio en un requerimiento Evalar el impacto de un fracaso de una prueba en los requerimientos (es decir si las faltas de la prueba el requerimiento no puede satisfacerse) Verificar que todos los requerimientos del sistema son cumplidos por la aplicacin.
Verificar que la aplicacin hace lo que se pensaba que haca.

La traceabilidad le ayuda a entender y manejar la entrada de los requerimientos, as como las reglas de negocio y los requerimientos de los stakeholders, se traduce en un juego de necesidades stakeholder/usuarios y caractersticas del sistema, especificados en el documento de Visin. El modelo de casos de uso, a su vez, define cmo las caractersticas se traducen en la funcionalidad del sistema.
Los detalles de cmo el sistema interactua con el mundo externo se captura en los casos del uso, con otros requerimientos importantes (como los requerimientos no funcionales, restricciones de diseo, etc.) en las Especificaciones Suplementarias.

La traceabilidad le permite tambin seguir cmo estas caracterstica tcnicas detalladas se traducen en un diseo, cmo se prueba, y cmo se documenta para el usuario.
Para un sistema grande, use pueden empaquetarse casos y las Caracterstica tcnicas Suplementarias juntas para definir una Especificacin de Requerimientos de Software (SRS) para una caracteristica particular u otra agrupacin del subsistema. Un concepto importante para ayudar a manejar los cambios en los requerimientos es marcar links de traceabilidad sospechosas.
Cuando un requerimiento (u otro artculo del traceabilidad) cambia, todos los eslabones asociados con ese requerimiento son marcados como sospechosos. Esto hace que el rol responsable deba repasar el cambio y determinar si los artculos asociados necesitarn tambin cambiar. Este concepto tambin ayuda analizar el impacto de cambios potenciales.

La Traceabilidad puede ayudar en: Cuales necesidades del usuario que no se unen a las caracteristicas del producto. Cual es el estado de pruebas en todos los casos del uso en la iteracin #n. Cuales son todos los requerimientos suplementarios unidos a pruebas cuyo estado es el no probados. Cuales son los resultados de todas las pruebas que fallaron, en el orden critico.

Traceabilidad Tpica
Los artculos del traceabilidad ms importantes son: Necesidades de Usuarios/Stakeholder (del documento Visin, puede remontarse ms all a las Demandas de Stakeholder individuales) Las Caractersticas del producto (del documento Visin). Requerimientos suplementarios (de las Especificaciones Suplementarias.)
Caso de Uso
La Seccin de Casos de Usos (secciones de un caso del uso detallado). Elemento de Diseo (del modelo de diseo). El Caso de prueba (u otro elemento del modelo de la prueba).
Conceptos: Tipos de Requerimiento

Tradicionalmente, los requerimientos parecen declaraciones de texto que encaja en una de las categoras mencionadas en el Concepto: Los requerimientos. Cada requerimiento declara "una condicin o capacidad que el sistema debe conformar."
La nocin de tipos de requerimientos es para ayudar separando los niveles diferentes de abstraccin y propsitos de nuestros requerimientos. El documento Visin nos ayuda a guardar rastros de "necesidades clave de los usuario " y caractersticas del sistema.
El modelo del casos de uso es una manera eficaz de expresar los "requerimientos funcionales del software" detallados, por consiguiente los casos de uso pueden necesitar ser rastreados y mantenidos como requerimientos. Las Especificaciones Suplementarias pueden contener otros "requerimientos del software", como restricciones de diseo o los requerimientos legales o reguladores en nuestro sistema.
Conceptos: Vista de Casos de Uso

Hay slo una vista de casos de uso del sistema que ilustra los casos de uso y los escenarios que abarcan arquitecturalmente una conducta significante, clases, o los riesgos tcnicos. La vista de casos de usos es refinada y considerada inicialmente en cada iteracin.
Conceptos: Vista de Casos de Uso

Las actividades de anlisis, diseo, e implementacin subsecuentes a los requisitos se centra en la nocin de una arquitectura. La produccin y validacin de esa arquitectura es el enfoque principal de las iteraciones tempranas, sobre todo durante la fase de la Elaboracin.
La arquitectura se representa por varias vistas arquitectnicas diferentes que en su esencia son extractos que ilustran los elementos "arquitecturalmente significantes" de los modelos. Hay cuatro vistas: la Vista Lgica, Vista del Proceso, Vista del Despliegue, y Vista de Implementacin. Las vistas arquitectnicas se documentan en un Documento de Arquitectura de Software. Usted puede agregar vistas diferentes, como una vista de seguridad, para llevar otros aspectos especficos de la arquitectura del software. As que, en esencia, las vistas arquitectnicas pueden ser vistas como abstracciones o simplificaciones de los modelos construidos, en las cuales se hacen ms visible las caractersticas mas importantes dejando los detalles al lado. La arquitectura es un medio importante para aumentar la calidad de cualquier modelo construido durante el desarrollo del sistema.
Conceptos: Diseo Centrado en el Usuario

Qu es el diseo centrado en el usuario?
No hay ningn acuerdo general claro en lo que constituye el diseo centrado en el usuario. Sin embargo, John Gould y sus colegas de IBM desarrollaron un acercamiento en la dcada de los 1980 llamado Diseando para Usabilidad qu abarca la mayora de las definiciones normalmente aceptadas. Este fue desarrollado de la experiencia prctica en varios sistemas interactivos, el ms notable en 1984 Sistema de Mensajera de los Juegos Olmpicos de IBM . El acercamiento tiene cuatro componentes principales como se describen a continuacin. Enfocado en el Usuario Integrado con el diseo Pruebas de Usuario Tempranas Diseo iterativo

Enfocado en el Usuario
Gould sugiere que los desarrolladores deban decidir quienes sern los usuarios y como involcralos a ellos en la brevedad posible. l sugiere un numero de maneras para familiarizarse con los usuarios, sus tareas y requisitos: Hable con los usuarios Visite las oficinas del cliente Observe a usuarios trabajar el Vdeo de los usuarios trabajando Aprenda sobre la organizacin de trabajo Prubelo ud. Mismo Consiga que los usuarios piensen en alto mientras trabajan Diseo Participativo Incluya a los usuarios expertos en el equipo de diseo Realice anlisis de las tareas Haga uso de cuestionarios y encuestas Desarrolle las metas probables

Enfocado en el Usuario
En RUP, se usan los talleres en varias etapas claves, pero stos deben complementarse por los tipos de actividades que Gould describe, debido a que parte del argumento detrs de esto es que las personas frecuentemente describen lo de que ellos hacen bastante diferentemente a cmo ellos lo hacen. Se olvidan a menudo de las tareas normalmente realizadas y detalles aparentemente insignificantes como el lugar de trabajo o la existencia de trozos "misteriosos" de papel o los omiti porque ellos no son "oficialmente" parte del proceso actual.

Integrado con el diseo
Las tareas de Usabilidad deben realizarse desde temprano en el desarrollo. Estas tareas incluiran el esbozo de la interfaz del usuario y el bosquejo del manual de usuario o la ayuda en lnea. Gould tambin hace resaltar que la usabilidad debe ser responsabilidad de un grupo. Una caracterstica importante del diseo integrado es el acercamiento global - el framework - para el diseo detallado de la interfaz usuario, el cual es desarrollado y probado en una fase temprana. sta es una diferencia importante entre el diseo centrado en el usuario y otras tcnicas completamente incrementales. Esto asegura que el diseo incremental es llevado a cabo en las subsiguientes fases permite que le framework y que la interfaz del usuario sea consistente en apariencia, terminologa y concepto.

Integrado con el diseo
Dentro del RUP, este framework puede establecerse usando un modelo de dominio para asegurar que toda la terminologa y conceptos que aparecern en la interfaz del usuario son conocidos y entendidos en general dentro del negocio y con los usuarios en particular. Como el diseo de interfaz de usuario progresa en la disciplina de requerimientos, muchas de las clases de dominio se representarn como las clases de frontera en la interfaz.
Las clases de frontera, y las relaciones entre ellas, debe ser consistente con el modelo de dominio y debe representarse de forma consistente a travs de todas las partes del sistema en diseo. (Esto no slo ayuda a los usuarios, sino que tambin mejora el reuso de componentes de interfaz. usuario)

Pruebas de Usuario Tempranas
Las pruebas de usuario tempranas del prototipo, tpicamente los dibujos y mockups describieron como los prototipos de bajo-fidelidad. Los prototipos envolventes seguirn despus en el proceso. Mockups puede usarse junto con los casos de uso para escribir escenarios concretos de uso para el sistema bajo diseo. stos pueden tomar forma narrativa, narrativa ilustrada (usando el mockups para la ilustracin), storyboards, etc.
Mientras estos acercamientos son poco familiares a muchos diseadores del software, ellos son claramente ms eficaces en costo que el descubrimiento de un diseo inapropiado o los requisitos entendidos mal una vez la implementacin esta en marcha.

Diseo iterativo
El desarrollo orientado a objetos se ha vuelto sinnimo de proceso iterativo. El diseo iterativo es bueno para problemas que necesitan un refinado entendimiento y poseen requisitos cambiantes. El diseo iterativo es un componente importante de diseo centrado en el usuario. Esto es con el tiempo en parte debido a las necesidades cambiantes de usuarios, pero tambin la inherente complejidad de producir soluciones que pueden tratar con necesidades diversas. Note que en los mtodos centrados a usuario, el diseo iterativo tiene lugar dentro de un framework integrado.

Por qu el diseo centrado en el Usuario?
Consiguiendo las Necesidades de los Usuarios Los sistemas interactivos confan en su habilidad para acomodar las necesidades de usuarios para su xito. Esto significa no slo identificando las comunidades del usuario diversas sino tambin reconociendo el rango de las habilidades, experiencia y preferencias de usuarios individuales. La atencin frecuentemente se enfoca en cmo los usuarios deben realizar las tareas en lugar a cmo ellos prefieren realizarlas. En muchos casos el problema de preferencia es mucho ms de simplemente sentirse en el mando, aunque se es un problema importante en s mismo. La preferencia tambin se determinar por la experiencia, habilidad y el contexto de uso. Estos caractersticas son considerados suficientemente importantes en el proceso de diseo para garantizar un estndar internacional, [ISO 13407], el titulado diseo centrado en el humano procesa para los sistemas interactivos.

Diseo de Interfaz de Usuario Los usuarios entienden y actan recprocamente con un sistema a travs de su interfaz de usuario. Los conceptos, imgenes y terminologa presentadas en la interfaz deben ser apropiadas a las necesidades de usuarios. Por ejemplo, un sistema que les permite a clientes comprar sus propios boletos sera muy diferente a usado profesionalmente por el personal de ventas de boleto. Las diferencias principales no estn en los requisitos o en los casos de uso detallados, pero si en las caractersticas de los usuarios y los ambientes en que los sistemas podran operar.

Diseo de Interfaz de Usuario La interfaz del usuario tambin debe servir para una amplia gama de experiencia a lo largo de por lo menos dos dimensiones, computadora y experiencia del dominio, ver Figura 1. La experiencia de la computadora no slo incluye la familiaridad general con las computadoras, sino tambin la experiencia del sistema bajo el desarrollo. Los usuarios con poca experiencia con las computadoras o el dominio del problema, estn ubicados en la esquina izquierda cercana de la figura, requerirn un acercamiento substancialmente diferente en la interfaz del usuario a los usuarios especialistas, mostrados aqu en la esquina derecha lejana.

Diseo de Interfaz de Usuario

Diseo de Interfaz de Usuario de interfaz de usuario
Bajo La experiencia de la computadora
Algunos factores que afectan el diseo

Alto
La pregunta simple y respuesta, el formulario de llenado simple, web (los hipervnculos) o estilo de interfaz de men
La experiencia del dominio Entrenamiento
La frecuencia de uso
La terminologa y conceptos comunes Enfoque en la facilidad de aprender (consistente, predecible, fcil de recordar) Fcil aprender y recordar, el estilo de la interfaz es simple, Premiado para usar, poderoso sin parecer complejo.
El formulario de llenado complejo, web (los hipervnculos) o estilo de interfaz de men (la pregunta y respuesta o formulario de llenado simple seran muy frustrantes para los usuarios experimentados) La terminologa dominio especfica y conceptos Enfoque en la facilidad de uso (directo, personalizado) Fcil usar, con atajos (shortcuts) mltiples y tcnicas para permitir el control del usuario Sofisticado con muchos los rasgos avanzados y personalizables.
La motivacin

Diseo centrado en el usuario en el RUP Desarrollar sistemas apropiadamente para las necesidades del usuario significa un esfuerzo significante en anlisis de requerimientos. En el diseo centrado a usuario, este esfuerzo se enfoca en los usuarios finales. stos son un subconjunto de los Actores de Negocio humanos (para los usuarios fuera de del negocio) y los Trabajadores de Negocio encontrados al trabajar en la disciplina de Modelado de Negocio. Sin embargo, un punto sustancial de nfasis en un diseo centrado en el usuario es lo que se entiende como los requisitos de las personas reales que llenarn los roles descritos en los artefactos arriba expresados. En particular, debemos evitar disear a humanos hipotticos.

Diseo centrado en el usuario en el RUP Los artefactos que describen a los usuarios finales slo deben escribirse despus del contacto sustancial, de primera mano con los usuarios. En el diseo centrado en el usuario este contacto de primera mano es la parte de un proceso llamado la pregunta contextual. Hugh Beyer y Karen Holtzblatt (en su libro el Diseo Contextual) describa la premisa de pregunta contextual como:
"... vaya donde el cliente trabaja, observa al cliente cuando l o ella trabajan, y habla con el cliente sobre el trabajo.
Esta acometida no slo se usa para tener un buen entendimiento de los requisitos del sistema, sino tambin de los usuarios, sus tareas y ambientes. Cada uno tiene sus propios atributos y esto es llamado el contexto de uso. Ellos se detallan en el estndar ISO para el diseo centrado en el usuario.

Diseo centrado en el usuario en el RUP Estndar ISO para el diseo centrado en el usuario
Contexto Tareas Atributos
Las metas de uso del sistema, frecuencia y duracin de desempeo, salud y consideraciones de seguridad, la asignacin de actividades, los pasos operacionales entre el humano y los recursos tecnolgicos. No deben describirse las tareas solamente por lo que se refiere a las funciones o rasgos proporcionados por un producto o sistema. Usuarios (for each different type or role) El conocimiento, la habilidad, la experiencia, la educacin, el entrenamiento, los atributos fsicos, los hbitos, las preferencias, las capacidades Ambientes El hardware, el software, los materiales, los ambientes fsicos y sociales, las normas pertinentes, el ambiente tcnico, el ambiente del legislativo, el ambiente social y cultural.

Diseo centrado en el usuario en el RUP Relaciones entre contextos

Diseo centrado en el usuario en el RUP Estndares ISO para el diseo centrado a usuario para los contextos y los artefactos de RUP
ISO 13407 Context Ambiente the RUP Artifact High-level: Business Vision [Section: Customer Environment], Stakeholder Requests, Vision [Section: User Environment] High-level: Business Vision [Section: Customer Profiles], Stakeholder Requests, Vision [Section: User Profiles] High-level: Business Actor (external users), Business Worker (internal users) Detailed: Actor High-level: Stakeholder Requests, Vision [Section: Product Features] Detailed: Use-Case Storyboard Use Case
Usuarios
Roles
Tareas

Escenarios, Casos de Uso, y Casos de Uso esenciales Caso de Uso genrico para retirar dinero de un telecajero
User Action insert card enter PIN press key press key enter amount press key take card take cash
System Response read magnetic strip request pint verify PIN display transaction option menu display account menu prompt for amount display amount return card dispense cash

Escenarios, Casos de Uso, y Casos de Uso esenciales Casos de Uso esenciales para retirar dinero de un telecajero
User Intention identify self
System Responsibility verify identity offer choices
choose dispense cash take cash
Workflow Detail: Define the System
Workflow Detail: Manage the Scope of the System
Workflow Detail: Refine the System Definition
Workflow Detail: Manage Changing Requirements

Clase 5. Disciplina de Requerimientos

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Clase 5. Disciplina de Requerimientos

Transféré par

Droits d'auteur :

Formats disponibles

DISCIPLINA DE REQUERIMIENTOS

Los Artefactos Plan de Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Administracin de Requerimientos

Conceptos: Traceability o Traceabilidad

Conceptos: Traceability o Traceabilidad

Conceptos: Traceability o Traceabilidad

Verificar que la aplicacin hace lo que se pensaba que haca.

Conceptos: Traceability o Traceabilidad

Conceptos: Traceability o Traceabilidad

Conceptos: Traceability o Traceabilidad

Conceptos: Traceability o Traceabilidad

Conceptos: Traceability o Traceabilidad

Conceptos: Tipos de Requerimiento

Conceptos: Vista de Casos de Uso

Conceptos: Vista de Casos de Uso

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Algunos factores que afectan el diseo

La experiencia del dominio Entrenamiento

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

Conceptos: Diseo Centrado en el Usuario

User Intention identify self

System Responsibility verify identity offer choices

choose dispense cash take cash

Workflow Detail: Define the System

Workflow Detail: Manage the Scope of the System

Workflow Detail: Refine the System Definition

Workflow Detail: Manage Changing Requirements

Vous aimerez peut-être aussi