Kendal Cap. 1
Necesidad del analista y diseño de sistemas.
Los analistas de sistemas llevan a cabo busca comprender qué necesitan los humanos para analizar la entrada o el flujo de datos de manera sistemática, procesar o transformar los datos, almacenarlos y producir información en el contexto de una organización específica. Mediante un análisis detallado, los analistas buscan identificar y resolver los problemas correctos.Análisis y diseño de sistemas se utiliza para analizar, diseñar e implementar las mejoras en el apoyo para los usuarios y las funciones de negocios que se puedan llevar a cabo mediante el uso de sistemas de información computarizados.
Roles del analista en sistemas
El analista de sistemas evalúa en forma sistemática cómo interactúan los usuarios con la tecnología y cómo operan las empresas, para lo cual examina los procesos de entrada/salida de los datos y la producción de información con la intención de mejorar los procesos organizacionales.
-Consultor de sistemas: Pueden llegar a contratarlo específicamente para lidiar con las cuestiones relacionadas con los sistemas de información dentro de la empresa.
-Experto de soporte: el analista se basa en su experiencia profesional sobre hardware y software y su uso en los negocios.
-Agente de cambio: el de agente de cambio, ya sea interno o externo, para la empresa. Como analista, usted actúa como un agente de cambio cada vez que realiza alguna de las actividades en el ciclo de vida del desarrollo de sistemas y está presente e interactúa con los usuarios y la empresa durante un periodo extendido (de dos semanas hasta más de un año).
Podemos definir a un agente de cambio como una persona que actúa como catalizador para el cambio, desarrolla un plan de cambio y trabaja con otros para facilitarlo.
Cualidades del analista de sistemas
-El analista es un solucionador de problemas.
-Debe ser un comunicador.
-Debe poseer una solida ética personal y profesional.
-Debe ser un individuo disciplinado y motivado.
-Tener capacidad para coordinar tanto a personas como a recursos variados para llevar a cabo los proyectos.
El ciclo de vida de desarrollo de sistemas (Metodología estructurada)
El ciclo de vida del desarrollo de sistemas (SDLC) es una metodología en fases para el análisis y diseño, de acuerdo con la cual los sistemas se desarrollan mejor al utilizar un ciclo específico de actividades del analista y los usuarios.
El ciclo tiene siete fases: cada fase se presenta de manera discreta, en realidad nunca se puede llevar a cabo como un paso separado, sino que varias actividades pueden ocurrir al mismo tiempo, e incluso se pueden repetir.
Incorporación de las consideraciones de la interacción humano computadora
El estudio de la interacción humano computadora (HCI) es el “aspecto de una computadora que permite las comunicaciones e interacciones entre ella y los humanos. Es el nivel de la computadora que está entre ella y los humanos”, se enfocan en las personas en vez del trabajo, analiza los “factores humanos ergonómicos, cognitivos, afectivos y de comportamiento involucrados en las tareas de los usuarios, los procesos de solución de problemas y el contexto de la interacción”.
La HCI también se considera una metodología centrada en los humanos.
La aplicación de los principios de la interacción humano-computadora implica descubrir y resolver las frustraciones que los usuarios experimentan al usar tecnologías de información.
1. Identificación de los problemas, oportunidades y objetivos
Primera fase del ciclo de vida del desarrollo de sistemas, el analista se encarga de identificar correctamente los problemas, las oportunidades y los objetivos. debe analizar con honestidad lo que está ocurriendo en la empresa. Después, junto con otros miembros de la organización, debe comenzar a señalar los problemas.
Las oportunidades residen en las situaciones que el analista cree poder mejorar mediante el uso de sistemas de información computarizados. La identificación de los objetivos El analista debe
descubrir primero qué trata de hacer la empresa; después debe ser capaz de determinar si alguno de los aspectos de las aplicaciones de los sistemas de información puede ayudar a que la empresa logre sus objetivos al enfrentar problemas u oportunidades específicos.
Las personas involucradas en la primera fase son los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto.
En esta fase las actividades consisten en entrevistar a los encargados de la administración de los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de viabilidad, el cual contiene la definición de un problema y sintetizar los objetivos.
2.- Determinación de los requerimientos de información del factor humano.
El analista es determinar las necesidades de los usuarios involucrados, mediante el uso de varias herramientas, para comprender la forma en que interactúan en el contexto laboral con sus sistemas de información actuales. El analista utilizará métodos interactivos como entrevistas, muestreos e investigación de datos duros, además de los cuestionarios y los métodos discretos, como observar el comportamiento de los encargados al tomar las decisiones y sus entornos de oficina, y los métodos integrales como la creación de prototipos.
El analista se esfuerza por comprender qué información requieren los usuarios para realizar sus trabajos.
Las personas involucradas en esta fase son los analistas y los usuarios, por lo general los gerentes y los trabajadores de operaciones.
3.- Análisis de las necesidades del sistema
El analista de sistemas involucra el análisis de las necesidades del sistema. Aquí también hay herramientas y técnicas especiales. Las herramientas como los diagramas de flujo de datos (DFD) para graficar la entrada, los procesos y la salida de las funciones de la empresa, o los diagramas de actividad o de secuencia para mostrar la secuencia de los eventos, sirven para ilustrar a los sistemas de una manera estructurada y gráfica.
Se debe desarrollar un diccionario de datos para enlistar todos los elementos de datos utilizados en el sistema, así como sus especificaciones.
4.- Diseño del sistema recomendado
En la fase de diseño del SDLC, el analista de sistemas utiliza la información recolectada antes para realizar el diseño lógico del sistema de información.
La fase de diseño también incluye el diseño de bases de datos que almacenarán gran parte de los datos necesarios para los encargados de tomar las decisiones en la organización.
5.- Desarrollo y documentación del software
En la quinta fase del SDLC, el analista trabaja con los programadores para desarrollar el software original requerido.
Durante ella, el analista desarrolla junto con los usuarios una documentación efectiva
para el software. La documentación indica a los usuarios cómo deben usar el software y qué deben hacer en caso de que ocurran problemas.
6.- Prueba y mantenimiento del sistema
Antes de utilizar el sistema de información, se debe probar. Una parte del procedimiento de prueba es llevado a cabo por los programadores solos; la otra la realizan junto con los analistas de sistemas.
Primero se completa una serie de pruebas para señalar los problemas con datos de muestra y después se utilizan datos reales del sistema actual.
A menudo, los planes de prueba se crean en las primeras etapas del SDLC y se refinan a medida que el proyecto progresa.
El mantenimiento del sistema y la documentación de este mantenimiento empieza en esta fase y se lleva a cabo de manera rutinaria durante toda la vida del sistema de información.
7.- Implementación y evaluación del sistema
El analista ayuda a implementar el sistema de información. En esta fase hay que capacitar a los usuarios para operar el sistema. Los distribuidores se encargan de una parte de la capacitación, pero la supervisión de la capacitación es responsabilidad del analista de sistemas. Además, el analista
necesita planear una conversión sin problemas del sistema antiguo al nuevo.
Metodología agil
La metodología ágil es una metodología de desarrollo de software que se basa en valores, principios y prácticas básicas. Los cuatro valores son comunicación, simpleza, retroalimentación y valentía.
Cuando usar cada metodología
La metodología del ciclo de vida del desarrollo de sistemas (SDLC)
• los sistemas se hayan desarrollado y documentado mediante el uso de SDLC
• sea importante documentar cada paso del proceso
• la administración de nivel superior se sienta más cómoda o segura si utiliza SDLC
• haya los recursos y el tiempo adecuados para completar el SDLC completo
• sea importante la comunicación en relación con la forma en que funcionan los nuevos sistemas.
Metodologías ágiles
• haya un defensor de proyectos de métodos ágiles en la organización
• haya que desarrollar aplicaciones rápidamente en respuesta a un entorno dinámico
• haya que realizar un rescate (el sistema falló y no hay tiempo de averiguar qué salió mal)
• el cliente está satisfecho con las mejoras incrementales
• los ejecutivos y analistas están de acuerdo con los principios de las metodologías ágiles
Metodologías orientadas a objetos
• los problemas modelados se prestan a sí mismos para convertirlos en clases
• una organización ofrece apoyo para aprender UML
• es posible agregar sistemas en forma gradual, un subsistema a la vez
• la reutilización de software escrito con anterioridad es una posibilidad
• es aceptable hacer frente a los problemas difíciles primero
Actividades en común entre las metodologías
En las tres metodologías, el analista necesita comprender primero a la organización. Después el analista o el equipo del proyecto necesitan elaborar un presupuesto del tiempo y los recursos necesarios para desarrollar la propuesta del proyecto. A continuación deben entrevistar a los miembros de la organización y recopilar información detallada mediante el uso de cuestionarios, obtener muestras de los datos de los informes existentes y observar cómo se lleva
a cabo la actividad empresarial actual. Las tres metodologías tienen todas estas actividades en común. Incluso los mismos métodos tienen similitudes. La metodología SDLC y la metodología orientada a objetos requieren de un proceso exhaustivo de planeación y elaboración de diagramas. La metodología ágil y la metodología orientada a objetos permiten crear subsistemas uno a la vez hasta que se complete todo el sistema. La metodología ágil y la metodología SDLC se interesan por la forma lógica en que los datos se desplazan a través del sistema.
Kendal Cap. 7
DFD
Los diagramas de flujo de datos describen con la mayor generalidad posible las entradas, los procesos y las salidas del sistema.
LA METODOLOGÍA DEL FLUJO DE DATOS PARA DETERMINAR LOS REQUERIMIENTOS HUMANOS
Para que los analistas de sistemas puedan comprender los requerimientos de información de los usuarios, deben ser capaces de conceptualizar la forma en que los datos se mueven a través de la organización, los procesos o la transformación por la que pasan los datos y las salidas de los mismos.
El diagramas de flujo de datos (DFD), el analista de sistemas puede ensamblar una representación gráfica de los procesos de datos a través de la organización.
Ventajas del DFD
1. No hay que comprometerse demasiado pronto con la implementación técnica del sistema.
2. Permite comprender con más detalle la capacidad de interrelación de los sistemas y subsistemas.
3. Se puede comunicar el conocimiento del sistema actual a los usuarios por medio de diagramas de flujo de datos.
4. Se puede analizar un sistema propuesto para determinar si se han definido los datos y procesos necesarios.
Los DFD se enfocan en el procesamiento de los datos o en la transformación de los mismos a medida que avanzan a través de varios procesos. En los DFD lógicos no hay distinción entre los procesos manuales o los automatizados. Tampoco se describen en forma gráfica los procesos en orden cronológico, sino que, en última instancia, se agrupan entre sí cuando un análisis posterior indique que es conveniente hacerlo.
Elementos del DFD
Se utilizan cuatro símbolos básicos para graficar el movimiento de los datos en los diagramas: un cuadrado doble, una flecha, un rectángulo con esquinas redondas y un rectángulo con un extremo abierto (cerrado del lado izquierdo y abierto del lado derecho).
El cuadrado doble se utiliza para describir una entidad externa (otro departamento, una empresa, una persona o una máquina) que pueda enviar/recibir datos hacia/desde el sistema. La entidad externa, o simplemente entidad, también se conoce como origen o destino de los datos, y se considera externa al sistema que se está describiendo.
Se debe denominar a las entidades con un sustantivo. Se puede utilizar la misma entidad más de una vez en un diagrama de flujo de datos para evitar cruzar las líneas de flujo de datos.
*** Un sustantivo es una categoría gramatical o clase de palabra que se utiliza para nombrar un objeto o sujeto.***
La flecha muestra el movimiento de los datos de un punto a otro; la cabeza de la flecha apunta hacia el destino de los datos.
Se utiliza un rectángulo con esquinas redondas para mostrar la ocurrencia de un proceso de transformación.
Los procesos representan los trabajos que se deben realizar en el sistema.
Un proceso también debe recibir un número de identificación único que indique su nivel en el diagrama.
rectángulo con un extremo abierto, el cual representa a un almacén de datos. El rectángulo se dibuja con dos líneas paralelas que se cierran mediante una línea corta del lado izquierdo y cuyo extremo derecho está abierto.
**En los diagramas de flujo de datos lógicos no se especifica el tipo de almacenamiento físico.
Como los almacenes de datos representan a una persona, lugar o cosa, se denominan con
un sustantivo.
Reglas:
1. El diagrama de flujo de datos debe tener por lo menos un proceso y no debe haber objetos independientes o conectados a sí mismos.
2. Un proceso debe recibir por lo menos un flujo de datos entrante y debe crear por lo menos un flujo de datos saliente.
3. Un almacén de datos debe estar conectado con por lo menos un proceso.
4. Las entidades externas no se deben conectar entre sí.
Desarrollo de DFD
DFD Contextual
Los diagramas avanzan de generales a específicos. El diagrama de contexto inicial debe ser una vista general que incluya las entradas básicas, el sistema general y las salidas.
El diagrama de contexto es el nivel más alto en un diagrama de flujo de datos y contiene sólo un proceso, el cual representa a todo el sistema. El proceso recibe el número cero. Todas las entidades externas se muestran en el diagrama de contexto, así como el flujo de datos principal que entra y sale de ellas. El diagrama no contiene almacén de datos.
1. Hacer una lista de las actividades de la empresa y usarla para determinar los siguientes elementos:
-Entidades externas
-Flujos de datos
-Procesos
-Almacenes de datos
2. Crear un diagrama de contexto que muestre las entidades externas y los flujos de datos que entran y salen del sistema. No debe mostrar procesos detallados ni almacenes de datos.
3. Dibujar el Diagrama 0, el siguiente nivel. Puede mostrar los procesos pero debe mantenerlos en un nivel general. En este nivel puede mostrar los almacenes de datos.
4. Crear un diagrama hijo para cada uno de los procesos en el Diagrama 0.
5. Verificar los errores y asegurarse de que las etiquetas que asigne a cada proceso y flujo de datos sean significativas.
6. Desarrollar un diagrama de flujo de datos físico a partir del diagrama de flujo de datos lógico. Establecer la diferencia entre los procesos manuales y los automatizados, describir los ar chivos e informes actuales por nombre y agregar controles para indicar cuando se completen los procesos o se produzcan errores.
7. Particionar el diagrama de flujo de datos físico mediante la separación o agrupación de partes del diagrama para facilitar la programación y la información.
DFD Nivel 0
Las entradas y salidas especificadas en el primer diagrama permanecen constantes en todos los subsiguientes. se expande en acercamientos que incluyan de tres a nueve procesos y muestren los almacenes de datos, junto con los nuevos flujos de datos de niveles inferiores.
El Diagrama 0 es la expansión del diagrama de contexto; puede incluir hasta nueve procesos.
Cada proceso se enumera con un entero, por lo general empezando a partir de la esquina superior izquierda del diagrama y avanzando hacia la esquina inferior derecha.
Diagramas hijso (niveles más detallados)
Cada proceso en el Diagrama 0 puede a su vez expandirse para crear un diagrama hijo más detallado. Al proceso que se expande en el Diagrama 0 se le conoce como el proceso padre, y al diagrama que resulta se le conoce como el diagrama hijo.
Por lo general, las entidades no se muestran en los diagramas hijos debajo del Diagrama 0.
DFD Lógico y físico
Un diagrama de flujo de datos lógico se enfoca en la empresa y la forma en que ésta opera. No se preocupa por la forma en que se construirá el sistema, sino que describe los eventos de la empresa que se llevarán a cabo, además de los datos requeridos y producidos por cada evento. En contraste, un diagrama de flujo de datos físico muestra cómo se implementará el sistema, incluyendo hardware, software, los archivos y las personas involucradas en el sistema.
Cómo desarrollar diagramas de flujo de datos lógicos
Para desarrollar un diagrama de este tipo hay que construir primero un diagrama de flujo de datos lógico para el sistema actual.
Hay varias ventajas en cuanto al uso de un modelo lógico:
1. Mejor comunicación con los usuarios.
2. Sistemas más estables.
3. Los analistas comprenden mejor el funcionamiento de la empresa.
4. Flexibilidad y mantenimiento.
5. Se eliminan las redundancias y se facilita la creación del modelo físico.
Cómo desarrollar diagramas de flujo de datos físicos
Una vez que desarrolle el modelo lógico del nuevo sistema, podrá usarlo para crear un diagrama de flujo de datos físico. Este diagrama muestra cómo se construirá el sistema y por lo general contiene la mayoría de (si no es que todos) los elementos que se encuentran.
Así como los diagramas de flujo de datos lógicos tienen ciertas ventajas, los diagramas de flujo de datos físicos tienen otras:
1. Aclarar qué procesos desempeñan los humanos (manuales) y cuáles son automatizados.
2. Describir los procesos con más detalle que los DFD lógicos.
3. Secuenciar procesos que se tengan que realizar en cierto orden específico.
4. Identificar los almacenes de datos temporales.
5. Especificar los nombres reales de los archivos, tablas de bases de datos y listados impresos.
6. Agregar controles para asegurar que los procesos se realicen en forma apropiada.
Contenido de los diagramas de flujo de datos físicos
• Procesos manuales
• Procesos para agregar, eliminar, modificar y actualizar registros (CRUD: Crear, Leer, Actualizar y Eliminar).
• Procesos para introducir y verificar datos
• Procesos de validación para asegurar que se introduzcan los datos con
precisión
• Secuenciar procesos para reorganizar el orden de los registros
• Procesos para producir todas las salidas únicas del sistema
• Almacenes de datos intermedios
• Se utilizan los nombres de archivo reales para guardar datos
• Controles para indicar que se completaron las tareas o condiciones de error
Para crear el diagrama de flujo de datos físico para un sistema hay que analizar sus salidas y entradas. Al crear un diagrama de flujo de datos físico, al flujo de datos de entrada que proviene de una entidad externa se le denomina algunas veces desencadenador, debido a que empieza las actividades de un proceso; al flujo de datos de salida de una entidad externa se le denomina algunas veces respuesta, ya que se envía como resultado de alguna actividad. Hay que determinar cuáles campos de datos o elementos hay que teclear. Estos campos se denominan elementos base y se deben almacenar en un archivo. Los elementos que no se teclean, sino que constituyen el resultado de un cálculo o una operación lógica, se denominan elementos derivados.
Pressman
Cap 1
La ingeniería de software incluye procesos, métodos y herramientas que permiten elaborar a
tiempo y con calidad sistemas complejos basados en computadoras. El proceso de software
incorpora cinco actividades estructurales: comunicación, planeación, modelado, construcción
y despliegue que son aplicables a todos los proyectos de software.
Se definió un proceso como la colección de actividades de trabajo, acciones y tareas que se realizan cuando va a crearse algún producto terminado. Cada una de las actividades, acciones y tareas se encuentra dentro de una estructura o modelo que define su relación
tanto con el proceso como entre sí.
Cap 7.2
DFD
El DFD adopta un punto de vista del tipo entrada-proceso-salida para el sistema. Es decir, los
objetos de datos entran al sistema, son transformados por elementos de procesamiento y
los objetos de datos que resultan de ello salen del software. Los objetos de datos se representan
con flechas con leyendas y las transformaciones, con círculos (también llamados burbujas). El
DFD se presenta en forma jerárquica. Es decir, el primer modelo de flujo de datos (en ocasiones
llamado DFD de nivel 0 o diagrama de contexto) representa al sistema como un todo. Los diagramas
posteriores de flujo de datos mejoran el diagrama de contexto y dan cada vez más detalles
en los niveles siguientes.
Creación de DFD
El diagrama de flujo de datos permite desarrollar modelos del dominio de la información y del
dominio funcional. A medida que el DFD se mejora con mayores niveles de detalle, se efectúa
la descomposición funcional implícita del sistema.
1) el nivel 0 del diagrama debe ilustrar el software o sistema como una sola burbuja;
2) debe anotarse con cuidado las entradas y salidas principales;
3) la mejora debe comenzar por aislar procesos candidatos, objetos de datos y almacenamiento de éstos, para representarlos en el siguiente nivel;
4) todas las flechas y burbujas deben etiquetarse con nombres significativos;
5) de un nivel a otro, debe mantenerse la continuidad del flujo de información, y
6) debe mejorarse una burbuja a la vez.
Las entidades externas principales (cuadrados) producen información para uso del sistema y consumen información generada por éste. Las flechas con leyendas representan objetos de datos o
jerarquías de éstos.
Ahora debe expandirse el DFD de nivel 0 a un modelo de flujo de datos de nivel 1.
Debe aplicarse un “análisis gramatical” a la narración del caso de uso que describe la burbuja en el nivel del contexto.
En relación con el análisis gramatical, los verbos son los procesos de CasaSegura y se representarán como burbujas en un DFD posterior. Los sustantivos son entidades externas (cuadros), datos u objetos de control (flechas) o almacenamiento de datos (líneas dobles).
Los procesos representados en el nivel 1 del DFD pueden mejorarse más hacia niveles inferiores.
La mejoría de los DFD continúa hasta que cada burbuja realiza una función simple. Es decir, hasta que el proceso representado por la burbuja ejecuta una función que se implementaría fácilmente como componente de un programa.
Sección 8.3.5
Modularidad
La modularidad es la manifestación más común de la división de problemas. El software se divide
en componentes con nombres distintos y abordables por separado, en ocasiones llamados módulos, que se integran para satisfacer los requerimientos del problema.
El software monolítico (un programa grande compuesto de un solo módulo) no es fácil de entender para un ingeniero de software.
En función de las circunstancias, el diseño debe descomponerse en muchos módulos con la esperanza de que sea más fácil entenderlos y, en consecuencia, reducir el costo requerido para elaborar el software.
Deben hacerse módulos, pero con cuidado para permanecer en la cercanía de M. Debe evitarse hacer pocos o muchos módulos.
Debe hacerse un diseño (y el programa resultante) con módulos, de manera que el desarrollo pueda planearse con más facilidad, que sea posible definir y desarrollar los incrementos del software, que los cambios se realicen con más facilidad, que las pruebas y la depuración se efectúen con mayor eficiencia y que el mantenimiento a largo plazo se lleve a cabo sin efectos colaterales de importancia.
Sección 8.4
El modelo del diseño
El modelo del diseño puede verse en dos dimensiones distintas. La dimensión del proceso indica la evolución del modelo del diseño conforme se ejecutan las tareas de éste como parte del proceso del software. La dimensión de la abstracción representa el nivel de detalle a medida que cada elemento del modelo de análisis se transforma en un equivalente de diseño y luego se mejora en forma iterativa.
Los elementos del modelo de diseño usan muchos de los diagramas UML. La diferencia es que estos diagramas se refinan y elaboran como parte del diseño; se dan más detalles específicos de la implantación y se hace énfasis en la estructura y en el estilo arquitectónico, en los componentes que residen dentro de la arquitectura y en las interfaces entre los componentes y el mundo exterior.
En la mayoría de los casos, el diseño preliminar de la arquitectura establece la etapa y va seguido del diseño de la interfaz y del diseño del nivel de los componentes, los cuales con frecuencia ocurren en paralelo. El modelo de despliegue por lo general se retrasa hasta que el diseño haya sido desarrollado por completo.
Sección 11
Diseño de la interfaz de usuario
usabilidad: medición cualitativa de la facilidad y eficiencia con la que un humano emplea las funciones y características que ofrece el producto de alta tecnología.
Reglas doradas
tres reglas doradas:
1. Dejar el control al usuario.
2. Reducir la carga de memoria del usuario.
3. Hacer que la interfaz sea consistente.
En realidad, estas reglas doradas constituyen la base de un conjunto de principios de diseño de
la interfaz de usuario que guían este aspecto tan importante del diseño del software.
1.- Dejar el control al usuario: Definir modos de interacción de manera que no se obligue al usuario a realizar acciones innecesarias o no deseadas.
El usuario debe poder entrar y salir del modo con poco o ningún esfuerzo.
-Dar una interacción flexible. Debido a que diferentes usuarios tienen distintas preferencias
para la interacción, debe darse la posibilidad de elegir.
-Permitir que la interacción del usuario sea interrumpible y también reversible. El
usuario debe poder suspender la secuencia de su trabajo (aun cuando consista en una secuencia
de acciones) para hacer otra cosa (sin perder el trabajo realizado hasta ese momento). También
debe poder “deshacer” cualquier acción.
-Facilitar la interacción a medida que aumenta la habilidad y permitir que aquélla se
personalice. Es frecuente que los usuarios realicen la misma secuencia de interacciones en
forma repetida. Es benéfico diseñar un mecanismo de “macros” que permita que un usuario
avanzado personalice la interfaz para facilitar la interacción.
-Ocultar los tecnicismos internos al usuario ocasional. La interfaz de usuario debe introducirlo
al mundo virtual de la aplicación. En esencia, la interfaz no debe requerir que el usuario interactúe en un nivel “interno” de la máquina (nunca debería tener que escribir comandos del sistema operativo desde una aplicación de software).
-Diseñar la interacción directa con objetos que aparezcan en la pantalla. El usuario
tiene la sensación de control cuando puede manipular los objetos que se necesitan a fin de
Bjarne Stronstrup ejecutar un trabajo en la misma forma en la que lo haría si el objeto fuera algo físico.
2.- Reducir la necesidad de que el usuario memorice
Entre más cosas tenga que recordar el usuario, más fácil será que cometa errores al interactuar
con el sistema. Es por esto que una interfaz de usuario bien diseñada no sobrecarga la memoria
del usuario. Siempre que sea posible, el sistema debe “recordar” la información pertinente y
ayudar al usuario con un escenario de interacción que lo ayude a recordar.
-Reducir la demanda de memoria de corto plazo. La interfaz debe diseñarse para disminuir la necesidad de recordar acciones, entradas y resultados del pasado. Esto se logra dando claves visuales que permitan al usuario reconocer acciones anteriores, en lugar de que tenga que recordarlas.
-Hacer que lo preestablecido sea significativo. Lo que al principio se dé por preestablecido
debe tener sentido para el usuario promedio,debe disponerse de la opción de “reiniciar” para restablecer los valores originales.
-Definir atajos que sean intuitivos. Cuando se utilice nemotecnia para ejecutar una función
del sistema (como la secuencia Ctrl-B para invocar la función de buscar), debe estar ligada con
la acción, de modo que sea fácil de recordar (por ejemplo, con la primera letra de la tarea que
se va a realizar).
-La distribución visual de la interfaz debe basarse en una metáfora del mundo real. el usuario se base en claves visuales que comprende bien, en vez de tener que memorizar una secuencia críptica de interacciones.
-Revelar información de manera progresiva. La interfaz debe estar organizada de manera
jerárquica. Es decir, la información acerca de una tarea, objeto o comportamiento debe presentarse primero en un nivel de generalización elevado. Después de que con el ratón el usuario
manifieste interés, deben darse más detalles.
3.- Hacer consistente la interfaz
La interfaz debe presentar y obtener información en forma consistente. Esto implica:
1) que toda la información se organice de acuerdo con reglas de diseño que se respeten en todas las pantallas desplegadas, 2) que los mecanismos de entrada se limiten a un conjunto pequeño usado en forma consistente en toda la aplicación, y 3) que los mecanismos para pasar de una tarea a otra
se definan e implementen de modo consistente.
-Permita que el usuario coloque la tarea en curso en un contexto significativo. Es importante dar indicadores (títulos en las ventanas, iconos gráficos, código de colores
consistente, etc.) que permitan al usuario conocer el contexto del trabajo en curso. Además,
debe poder determinar de dónde viene y qué alternativas hay para hacer la transición a una
nueva tarea.
-Mantener la consistencia en toda la familia de aplicaciones. Todas las aplicaciones (o
productos) que hay en un grupo deben implementar las mismas reglas de diseño a fin de que se
mantenga la consistencia en toda la interacción.
-Si los modelos interactivos anteriores han creado expectativas en el usuario, no haga
cambios a menos de que haya una razón ineludible para ello. Una vez que una secuencia
interactiva en particular se ha convertido
en un estándar (como el uso de alt-G para guardar
un
archivo), el usuario la espera en toda aplicación que emplea.
Análisis y diseño de interfaz de usuario
El proceso general de análisis y diseño de la interfaz de usuario comienza con la creación de
diferentes modelos del funcionamiento del sistema (según se percibe desde fuera). Se empieza
delineando las tareas orientadas al usuario —y a la computadora— que se requieren a fin de
obtener el funcionamiento del sistema, para luego considerar los aspectos que se aplican a todos
los diseños de interfaz. Se emplean herramientas para hacer prototipos e implementar el
modelo
del diseño, y los usuarios finales evalúan la calidad.
Comentarios
Publicar un comentario