Análisis de tareas y Diseño de Sistemas

Análisis de tareas y Diseño de Sistemas:

    La disciplina de Datos

    David Benyon En el número anterior de interactuar con las computadoras, me ofreció una crítica de análisis de la tarea (TA) argumentando que, en general, las técnicas de análisis de tareas habían dejado de apreciar la importancia del cambio de énfasis - hacia el modelado lógico del sistema y lejos de modelado físico - que había tenido lugar durante la década de 1980 en los sistemas de información. Como resultado TA (si se utiliza por sí solo) produciría diseños de sistemas pobres porque no consigue alcanzar la suficiente independencia de dispositivo (Benyon, 1991). En su comentario sobre este artículo, Pañal y Addison (pañal y Addison, 1991) defendieron TA en general y TAKD (por ejemplo, pañal, 1989b), en particular, contra las críticas e hicieron una serie de afirmaciones sobre mi postura con respecto a los seres humanos y computadoras. En esta respuesta, tengo la intención de aclarar en primer lugar, lo que quiero decir con una vista de datos centrada, en segundo lugar, lo que quiero decir con independencia del dispositivo y, finalmente, la razón por la vista datacentred es una parte vital de desarrollo de sistemas. Al hacer esto, espero que lidiar con muchos de los puntos concretos planteados por el pañal y Addison. Por debajo de esta discusión es una visión de cómo los diseñadores de sistemas deben realizar sus diseños y una base teórica o filosófica de la interacción persona-ordenador (HCI) proporcionados por la vista de datos centrada. Mientras que ambos son temas importantes, no es ni el espacio ni el tiempo para dar una cobertura adecuada aquí. Sin embargo, estoy seguro de que tanto la teoría y la práctica de HCl se beneficiarán de este continuo debate sobre el papel preferido de análisis de tareas en el diseño del sistema. Mi preocupación inicial sobre el TA se derivó de la demanda hecha por sus partidarios que "el análisis de tareas es potencialmente el método más poderoso en HCI ... para producir especificaciones de requisitos '(1989a pañal, Prefacio). Creo que este punto de vista no es satisfactoria debido a TA no se centra suficientemente en los datos en el sistema. Este documento está dirigido a la explicación esta posición. La parte central de este trabajo es una exposición de modelos de datos como modelos conceptuales que capturan tanto un objeto ordenador de los sistemas humanos y económicos. Esta discusión es necesario con el fin de entender la noción de independencia de dispositivo que se presenta en la siguiente sección. Antes de pasar a los detalles de los datos, es importante para obtener una perspectiva sobre el desarrollo del sistema.

DESARROLLO DEL SISTEMA

Hay muchas caracterizaciones de cómo se desarrollan los sistemas y cómo se deben desarrollar sistemas. El modelo utilizado en (Benyon 1991) fue elegido para destacar la importancia del modelado conceptual y la asignación de tareas en lugar de prescribir un método de desarrollo del sistema. Muchos métodos abogan por una fase de asignación de tareas (como Avison y la Madera

Harper, 1990, Sutcliffe y McDermott, 1991, Damodaran, Ip y Beck, 1988). Sin embargo, la asignación de tareas no es algo que sucede después de modelado conceptual es completa. asignación de tareas es un proceso prolongado y considerado de análisis, diseño e implementación. La asignación de tareas a los humanos, a máquina o en alguna combinación provoca una discusión de ambas capacidades y los recursos humanos y de la máquina. tarea de realizar los análisis aquí es una manera eficaz de informar a este proceso. No hay duda de errores en el análisis y omisiones en el diseño serán expuestos y el ciclo voluntad proceso de desarrollo integral a considerar alternativas. Modelos de desarrollo del sistema se producen para diferentes propósitos, son más o menos útil para tal fin, y más o menos aplicable a sistemas diferentes. Sin embargo, está claro que los diseñadores tienen que realizar algún trabajo de análisis, un cierto diseño - lógico y físico - y el sistema tiene que ser implementado. Existe una relación difícil entre estas actividades, tanto en relación con el orden en el que se llevan a cabo y el contenido de cada uno. Pañal y Addison (1991) ver las etapas de desarrollo de sistemas que tienen entradas y salidas identificables, pero esto es sólo una perspectiva. El análisis sugiere soluciones de diseño. Diseño expone agujeros en el análisis. Aplicación, al menos en forma de prototipos, es una ayuda para el análisis y diseño. La captura de datos (o especificación de requisitos), por ejemplo, es ciertamente algo que se tiene que hacer a fondo y cuidadosamente, y que no es fácil. Pero, ¿qué es lo que queremos lograr? Basta con que describe el sistema actual es útil sólo en la medida en que asegura a los usuarios que el analista entiende lo que ellos, los usuarios, lo hacen. Se trata de analizar el sistema actual, que es importante. Los métodos para la captura de datos (por ejemplo, el análisis de tareas) deben demostrar su poder analítico. La obtención de descripciones adecuadas de lo que las personas quieren hacer y cómo quieren hacerlo, junto con la forma en que deben hacerlo (por ejemplo, por razones de seguridad, seguridad e integridad) es de vital importancia tanto para el análisis y diseño. Parte del análisis de sistemas es la comprensión de las tareas que el sistema tiene que apoyar. Los métodos estructurados de análisis y diseño son pobres en ambos aspectos. Es por esta razón que los sistemas de ver y ricas imágenes se han defendido en el diseño de sistemas de información (Avison y Wood-Harper, 1990), TA se ha vuelto popular en HCI y la necesidad urgente de integrar HCl con el diseño de sistemas de información ha sido reconocido ( por ejemplo, Sutcliffe, 1989, Damodaran et al., 1988). Muchas técnicas están disponibles tanto para el análisis y el diseño y deben ser utilizados según sea apropiado. En lugar de tratar de encontrar una metodología que lo abarca todo, o la representación de "derecho", el enfoque de 'caja de herramientas' para el desarrollo de sistemas (Benyon y Skidmore, 1987) reconoce que las diferentes situaciones exigen diferentes técnicas. En este enfoque diseñadores están capacitados en el uso de diferentes herramientas y técnicas que se seleccionan según sea apropiado dado su conocimiento de los puntos fuertes de la herramienta y debilidades, las preferencias personales y las exigencias del problema en cuestión. Un componente esencial de la caja de herramientas del analista, o de anymethodology, es una o más técnicas para el modelado lógico o conceptual.

...