1.2. Ciclo de vida clásico del desarrollo de sistemas 3. Método de desarrollo por análisis estructurado 4. Método del prototipo de sistemas 5. Conclusiones 6. Bibliografía

INTRODUCCIÓN

En la actualidad para muchas organizaciones, los sistemas de información basados en computadoras son el corazón de las actividades cotidianas y objeto de gran consideración en la toma de decisiones, las empresas consideran con mucho cuidados las capacidades de sus sistemas de información cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darán a la competencia.

Al establecer los sistemas de información basados en computadoras deben tener la certeza de que se logren dos objetivos principales: que sea un sistema correcto y que este correcto el sistema. Ningún sistema que deje satisfacer ambos objetivos será completamente útil para la gerencia u organización.

Si los dispositivos de un sistema de información no se adaptan a su población de clientes, no lograra sus objetivos potenciales. A mismo tiempo, aun cuando se identifiquen precisamente las necesidades del usuario, un sistema de información va tener un valor único si funciona en forma adecuada.

Los informes y las salidas producidas por el sistema deben ser precisos, confiables y completos. La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios.

Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.

Aunque la estimación, es más un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software.

Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones.

A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software. La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación.

CICLO DE VIDA DE UN SISTEMA DE INFORMACION

El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.

Según James Senn, existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tienen un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada. 

CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

 El método de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:

1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:

¿Qué es lo que hace?

¿Cómo se hace?

¿Con que frecuencia se presenta?

¿Qué tan grande es el volumen de transacciones o decisiones?

¿Cuál es el grado de eficiencia con el que se efectúan las tareas?

¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?

3). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. 

Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.

Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.

*Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.

*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.

MÉTODO DE DESARROLLO POR ANÁLISIS ESTRUCTURADO

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de:

1). La división del sistema en componentes

2). La construcción de un modelo del sistema.

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Éste análisis permite al analista conocer un sistema o proceso en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

Componentes

Símbolos gráficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.

Diccionario de datos: descripción de todos los datos usados en el sistema. Puede ser manual o automatizado.

Descripciones de procesos y procedimientos: declaraciones formales que usan técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.

Reglas: estándares para describir y documentar el sistema en forma correcta y completa.

Diseño Estructurado.

El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software.

El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional.

La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo).

Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.

Análisis de flujo de datos.

Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los diccionarios de datos.

Herramientas

Las herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones.

Diagrama de flujo de datos

Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual se desarrollan otros componentes.

El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez más detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigación.

El diagrama físico de datos da un panorama del sistema en uso, dependiente de la implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de personas, nombres o números de formato y documento, nombres de departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos.

El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico es independiente de la implantación, que se centra en el flujo de datos entre los procesos, sin considerar los dispositivos específicos y la localización de los almacenes de datos o personas en el sistema. Sin indicarse las características físicas.

Notaciones: son cuatro símbolos, que fueron desarrollados y promovidos la mismo tiempo por dos organizaciones: Yourdon y Gane y Sarson.

Flujo de datos: son movimientos de datos en una determinada dirección, desde un origen hasta un destino. Es un paquete de datos.

MÉTODO DEL PROTOTIPO DE SISTEMAS

La construcción de prototipos representa una estrategia de desarrollo, cuando no es posible determinar todos los requerimientos del usuario. Es por ello que incluye el desarrollo

interactivo o en continua evolución, donde el usuario participa de forma directa en el proceso.

Este método contiene condiciones únicas de aplicación, en donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de que se cometa un error pueden ser altos.

Así mismo este método resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación. El método del prototipo de sistemas consta de 5 etapas:

1). Identificación de requerimientos conocidos: La determinación de los requerimientos de una aplicación es tan importante para el m‚todo de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer.

2). Desarrollo de un modelo de trabajo: Es fácil comenzar el procesos de construcción del prototipo con el desarrollo de un plan general que permita a los usuarios conocer lo que se espera de ellas y del proceso de desarrollo. Un cronograma para el inicio y el fin de la primera interacción es de gran ayuda. En el desarrollo del prototipo se preparan los siguientes componentes:

a). El lenguaje para el dialogo o conversación entre el usuario y el sistema.

b). Pantallas y formatos para la entrada de datos.

c). Módulos esenciales de procesamiento.

d). Salida del sistema

3). Utilización del prototipo: Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas

4). Revisión del prototipo: Durante la evaluación los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios.

Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones.

5). Repetición del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.

CONCLUSIONES

Un proyecto de desarrollo de un Sistema de Información comprende varios componentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno más de los componentes: Software, hardware, personas, base de datos, documentación y procedimientos.

Es por eso que existen varios modelos o métodos para la realización del análisis y diseño de un sistema, lo primero del trabajo fue revisar que es el Análisis y el diseño y posteriormente el autor Kendall, presenta varios modelos que podemos utilizar para la realización y elaboración de un proceso y trabajo exhaustivo y dar solución o respuesta al problema que se ha generado desde la perspectiva del programador y analista.

aso de estudio 1:

Propuesta de comunidad en acción

Amadeus proporciona soporte para más de 148 aerolíneas usuarias Amadeus en sus oficinas de ventas y reservaciones, así como a agencias de viajes, corporaciones y viajeros a través de páginas web potenciadas por Amadeus. Nuestra central de información en Niza, realiza constantes mejoras funcionales a nuestras soluciones y las pone al alcance de nuestros usuarios . Los recientes desarrollos incluyen PNR sharing, y el mismo sistema de cuota de tarifa, para incrementar la eficacia de distribución. 

Caso de estudio 2:

Ciclo de vida del proyecto

Amadeus implementa un proceso de desarrollo de producto basado en las necesidades de los clientes, a quienes invoulcra en cada fase para asegurar las mejores tomas de decisiones y reducir los tiempos de desarrollo.

 

Propuesta Concepto de planificaciónConstrucción

Aceptación Transición 

Fase IV Aceptación Durante la fase de aceptación, el producto es probado exhaustivamente en condiciones reales para asegurar la conformidad de los requerimientos. Al final de esta etapa, el producto esta listo para liberarse. Fase V TransiciónDurante la fase de transición el producto se libera para la comunidad de usuarios. Las responsabilidades del producto son también transferidas a la línea de la organización.

Fase I Propuesta La propuesta es una fase de pre-proyecto, durante la cual se establece el caso de negocio para el proyecto y se define el ámbito del proyecto. Fase II Concepto y planificación Durante esta fase se analiza el problema dominante, se establece un sólido fundamento arquitectónico de la solución, se desarrolla el plan del proyecto, y se logran identificar los elementos de mayor riesgo, costo, calendario y los objetivos de calidad del proyecto. Fase III ConstrucciónDurante la fase de construcción, es desarrollado el producto íntegramente.

Plan de estudios V.Rajaraman/IISc, Bangalore V.Rajaraman / CDII, Bangalore V1/1-6-04/1 V1/1-6-04/1 SYSTEM ANALYSIS AND DESIGN SISTEMA DE ANÁLISIS Y DISEÑO

Module 1: Data and Information (3)

Módulo 1: Datos e Información (3) Types of information: operational, tactical, strategic and statutory – why do we need Tipos de información: operativos, tácticos, estratégicos y legales –

¿por qué necesitamos information systems – management structure – requirements of information at different sistemas de información - estructura de gestión - Requisitos de información en diferentes levels of management – functional allocation of management – requirements of los niveles de gestión - la asignación funcional de la gestión - Requisitos de information for various functions – qualities of information – small case study. información para las diversas funciones - cualidades de la información - pequeño estudio de caso. Module 2: Systems Analysis and Design Life Cycle (3)

Módulo 2: Análisis de Sistemas y del ciclo de vida de diseño (3)

Requirements determination – requirements specifications – feasibility analysis – final Requisitos de la determinación - especificaciones de requisitos - Análisis de viabilidad - final specifications – hardware and software study – system design – system implementation – especificaciones - y el software de estudio de hardware - el diseño del sistema - la implementación del sistema - system evaluation – system modification. evaluación del sistema - la modificación del sistema. Role of systems analyst – attributes of a Papel de analista de sistemas - los atributos de un systems analyst – tools used in system analysis analista de sistemas - herramientas utilizadas en el análisis del sistema Module 3: Information gathering (3) Módulo 3: La recolección de información (3) Strategies – methods – case study – documenting study – system requirements Estrategias - Métodos - estudio de caso - estudio de la documentación - Requisitos del sistema specification – from narratives of requirements to classification of requirements as pliego de condiciones - a partir de relatos de los requisitos de clasificación de los requisitos strategic, tactical, operational and statutory. estratégico, táctico, operativo y legal. Example case study Ejemplo de estudio de caso Module 4: Feasibility analysis (3) Módulo 4: Análisis de viabilidad (3) Deciding project goals – examining alternative solutions – cost – benefit analysis – Decidir los objetivos del proyecto - el examen de soluciones alternativas - análisis de costo - beneficio - quantifications of costs and benefits – payback period – system proposal preparation for cuantificación de los costes y beneficios - periodo de recuperación - sistema de preparación de propuestas para managements – parts and documentation of a proposal – tools for prototype creation gerencias - piezas y documentación de la propuesta - herramientas para la creación de prototipos Module 5: Tools for systems analysts (3) Módulo 5: Herramientas para los analistas de sistemas (3) Data flow diagrams – case study for use of DFD, good conventions – leveling of DFDs – Diagramas de flujo de datos - estudio de caso para el uso de DFD, convenciones buena - nivelación de DFD - leveling rules – logical and physical DFDs – software tools to create DFDs reglas de nivelación - DFD lógico y físico - herramientas de software para crear DFD Module 6: Structured systems analysis and design (3) Módulo 6: análisis de sistemas estructurados y de diseño (3) Procedure specifications in structured English – examples and cases – decision tables for Procedimiento especificaciones estructurada Inglés - ejemplos y casos - las tablas de decisión para complex logical specifications – specification oriented design vs procedure oriented complejas especificaciones lógicas - la especificación de diseño orientado a procedimiento global vs design diseño Module 7: Data oriented systems design (3) Módulo 7: Diseño orientado a sistemas de datos (3)

Entity relationship model – ER diagrams – relationships cardinality and participation – Entidad modelo de relación - diagramas ER - cardinalidad de las relaciones y la participación - normalizing relations – various normal forms and their need – some examples of normalización de las relaciones - diversas formas normales y su necesidad - algunos ejemplos de relational data base design. diseño de la base de datos relacional. Module 8: Data input methods (3) Módulo 8: métodos de entrada de datos (3) Coding techniques – requirements of coding schemes – error detection of codes – Las técnicas de codificación - Requisitos de los sistemas de codificación - detección de errores de los códigos - validating input data – input data controls interactive data input validación de los datos de entrada - los datos de entrada los controles de entrada de datos interactiva Module 9: Designing outputs (2) Módulo 9: Diseño de productos (2) Output devices – designing output reports – screen design – graphical user interfaces – Los dispositivos de salida - el diseño de informes de resultados - diseño de la pantalla - interfaces de usuario gráficas - interactive I/O on terminals. Yo interactiva de E / S en los terminales

Competencia: Análisis y Diseño de sistemas de Información

Estudio de casos: VideoTienda(Alquiler de películas)

En esta oportunidad estimado aprendiz quiero que ponga mucho cuidado y al caso de estudio que se plantea a continuación, en dicho caso deberás analizar y diseñar lo que quiere el cliente.

Para el análisis de este caso, el equipo de desarrolladores formados por Cindy Reyes, Yasiris Piraquive y Yerlenys Lapeira, se reunieron con el dueño de una video tienda cuyo negocio es el alquiler de películas, el dueño quiere de la mejor manera buscar a través de un sistema vía web que sus clientes puedan alquilar películas desde su casa, y que el dueño pueda mirar dichos alquileres, entre otras cosas.

Para empezar con el proyecto el equipo de desarrolladores, diseñaron una seria de preguntas para la primera entrevista con el cliente, estas preguntas les dará al equipo un primer acercamiento de la lógica de negocios, es decir saber cómo funciona actualmente la video tienda o alquiler de películas.

El equipo formulo las siguientes preguntas y escribió las respectivas respuestas

1) Quienes serían las personas que utilizarían el sistema

Respuesta del cliente: Bueno el sistema lo utilizaría obviamente mi persona que administro el negocio de la videotienda y los cliente que alquilan mis películas.

2) Que operaciones le debería dejar hacer el sistema al cliente, es decir que le mostraría.

Respuesta del cliente: Bueno yo quiero que el cliente pueda ver todas las películas disponibles, y luego de poderlas alquilar con una opción que diga alquilar.

De igual forma quiero que él pueda ver todas las películas que él tiene pendiente de devolver.

Nota: es posible que el entrevistador además de las preguntas que trae en su libreta pueda formular otras adicionales, que para este caso sería bueno teniendo en cuenta la respuesta del cliente.

El entrevistador formula una nueva pregunta: Cuando el sistema le muestra al cliente todas las películas, exactamente qué datos de la película quiere usted que le muestre?

Respuesta del cliente: Bueno quiero que muestre el título de la película, Genero de la película, es decir si es de Acción, Terror, Risa, entre otras; muestre una descripción, El actor principal, número de copias disponibles y el valor del alquiler, y como le dije una opción para alquilar cualquiera de estas películas.

La primera entrevista finaliza y el equipo agradece al cliente

Análisis y Diseño de Sistemas de Información

UNIDAD I

Fundamentos del análisis de sistemas

1. COMO ASUMIR EL PAPEL DEL ANALISTA DE SISTEMAS.

a) LA INFORMACIÓN COMO UN RECURSO DE LAS ORGANIZACIONES.

Las organizaciones han reconocido, desde hace mucho, la importancia de administrar recursos principales tales como la mano de obra y las materias primas. La información se ha colocado en un lugar adecuado como recurso principal.

Los tomadores de decisiones están comenzando a comprender que la información no es sólo un subproducto de la conducción, sino que a la vez alimenta a los negocios y puede ser el factor crítico para la determinación del éxito o fracaso de éstos.

Manejo de la información como recurso.

Para maximizar la utilidad de la información, un negocio la debe manejar correctamente tal como maneja los demás recursos. Los administradores necesitan comprender que hay costos asociados con la producción, distribución, seguridad, almacenamiento y recuperación de toda información. Aunque la información se encuentra a nuestro alrededor ésta no es gratis, y su uso es estratégico para posicionar la competitividad de un negocio.

Manejo de la información generada por computadora.

El manejo de información generada por computadora difiere en forma significativa del manejo de datos producidos manualmente. Por lo general, hay mayor cantidad de información de computadora a administrar. El costo de organizarla y mantenerla puede crecer a tasas alarmantes, y los usuarios frecuentemente la tratan menos escépticamente que la información obtenida por otras vías.

b) CONCEPTOS DE ANÁLISIS Y DISEÑO DE SISTEMAS.

Los sistemas de información son desarrollados con propósitos diferentes dependiendo de las necesidades del negocio. Los sistemas de procesamiento de transacciones (TPS por sus siglas en inglés) funcionan al nivel operacional de la organización, los sistemas de automatización de oficina (OAS por sus siglas en inglés) y los sistemas de trabajo de conocimiento (KWS por sus siglas en inglés) que dan cabida al trabajo a nivel de conocimiento.

Los sistemas de más alto nivel incluyen a los sistemas de apoyo a decisiones (DSS por sus siglas en inglés) así como a los sistemas de información gerencial (MIS por sus siglas en inglés). Los sistemas expertos aplican la experiencia de los tomadores de decisiones para resolver problemas específicos estructurados. Al nivel estratégico de la administración encontramos sistemas de apoyo a ejecutivos (ESS por sus siglas en inglés) y los sistemas de apoyo a decisiones de grupo (GDSS por sus siglas en inglés) ayudan a la toma de decisiones al mismo nivel, en una forma sin estructura o semiestructurada.

Sistemas de procesamiento de transacciones.

Los sistemas de procesamiento de transacciones (TPS) son sistemas de información computarizados desarrollados para procesar gran cantidad de transacciones rutinarias de los

negocios. Los TPS eliminan el tedio de las transacciones operacionales necesarias y reducen el tiempo que alguna vez se requirió para ejecutarlas manualmente, aunque la gente todavía debe alimentar datos a los sistemas computarizados.

Sistemas de automatización de oficina y sistemas de manejo de conocimiento.

Al nivel de conocimiento de la organización hay dos clases de sistemas. Los sistemas de automatización de oficina (OAS) que dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la información para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla o diseminarla formalmente por toda la organización y algunas veces más allá de ella. Los sistemas de manejo de conocimiento (KWS) dan soporte a los trabajadores profesionales, tales como científicos, ingenieros y doctores, les ayudan a crear un nuevo conocimiento que contribuya a la organización o a toda la sociedad.

Sistemas de información gerencial.

Los sistemas de información gerencial (MIS) no reemplazan a los sistemas de procesamiento de transacciones, sino que todos los MIS incluyen procesamiento de transacciones. Los MIS son sistemas de información computarizada que trabajan debido a la interacción resuelta entre gentes y computadoras. Requieren que las gentes, el software (programas de computadora) y el hardware (computadoras, impresoras, etc.) trabajen al unísono. Los sistemas de información dan soporte a un espectro más amplio de tareas organizacionales que los sistemas de procesamiento de transacciones, incluyendo el análisis de decisiones y la toma de decisiones.

Sistemas de apoyo a decisiones.

Una clase de más alto nivel en los sistemas de información computarizada son los sistemas de apoyo a decisiones (DSS). El DSS es similar al sistema de información gerencial tradicional en que ambos dependen de una base de datos como fuente. Un sistema de apoyo a decisiones se aparta del sistema de información gerencial tradicional en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisión actual todavía es del dominio del tomador de decisiones.

Sistemas expertos e inteligencia artificial.

La inteligencia artificial (AI por sus siglas en inglés) puede ser considerada la meta de los sistemas expertos. Los sistemas expertos son un caso muy especial de un sistema de información, cuyo uso ha sido factible para los negocios a partir de la reciente y amplia disponibilidad de hardware y software. Un sistema experto (también llamado un sistema basado en conocimiento) captura en forma efectiva y usa el conocimiento de un experto para resolver un problema particular experimentado en una organización. Observe que a diferencia del DSS, que deja la decisión final al tomador de decisiones, un sistema experto selecciona la mejor solución a un problema o a una clase específica de problemas.

Sistemas de apoyo a decisiones de grupo.

Cuando los grupos necesitan trabajar juntos para tomar decisiones semiestructuradas o sin estructura, un sistema de apoyo a decisiones de grupo puede plantear una solución. Los sistemas de apoyo a decisiones de grupo (GDSS) son usados en cuartos especiales, equipados en varias configuraciones diferentes, que permiten que los miembros del grupo interactúen con apoyo electrónico, frecuentemente en forma de software especializado y con una persona que dé facilidades al grupo. Los sistemas para decisiones de grupo están orientados para reunir a un grupo, a fin de que resuelva un problema con la ayuda de varios apoyos como votaciones, cuestionarios, aportación de ideas y creación de escenarios.

Sistemas de apoyo a ejecutivos.

Cuando los ejecutivos se acercan a la computadora, frecuentemente están buscando formas que les ayuden a tomar decisiones a nivel estratégico. Un sistema de apoyo a ejecutivos (ESS) ayuda a éstos, para organizar sus interacciones con el ambiente externo, proporcionando apoyo de gráficos y comunicaciones en lugares accesibles tales como salas de juntas u oficinas personales corporativas.

En la figura se muestran la diversidad de sistemas de información que pueden desarrollar los analistas. Observe que la figura presenta estos sistemas de abajo hacia arriba, indicando que el nivel operacional, o más bajo, de la organización está apoyado por el TPS, y el más alto o estratégico, el de las decisiones semiestructuradas o sin estructura, está apoyado por el ESS en la parte más alta. Este texto usa los términos sistema de información gerencias, sistema de información, sistema de información computarizada y sistema de información de negocios computarizado en forma indistinta para referirse a sistemas de información computarizada que dan soporte al rango más amplio de actividades de negocios por medio de la información que producen.

La necesidad del análisis y diseño de sistemas.

El análisis y diseño de sistemas, tal como es ejecutado por los analistas de sistemas, busca analizar sistemáticamente la entrada de datos o el flujo de datos, el proceso o transformación de los datos, el almacenamiento de datos y la salida de información dentro del contexto de un negocio particular. Además, el diseño y análisis de sistemas es usado para analizar, diseñar e implementar mejoras en el funcionamiento de los negocios que pueden ser logradas por medio del uso de sistemas de información computarizados. La instalación de un sistema sin la planeación adecuada lleva a grandes frustraciones, y frecuentemente causa que el sistema deje de ser usado.

Usuarios finales.

Cualquiera que interactúe con un sistema de información en el contexto de su trabajo en la organización puede ser llamado un usuario final. A lo largo de los años se han hecho borrosas las distinciones entre usuarios. Además, cualquier categoría de usuarios empleada no debe ser vista como excluyente. Sin importar cómo se hayan clasificado los usuarios finales, un hecho es

pertinente al analista de sistemas: el involucramiento del usuario a lo largo del proyecto, es crítico para el desarrollo exitoso de los sistemas de información computarizados. Los analistas de sistemas, cuyos papeles dentro de la organización se tratan a continuación, son el otro componente esencial para el desarrollo de sistemas de información.

c) EL PAPEL DE EL ANALISTA DE SISTEMAS

El analista de sistemas como consultor.

El analista de sistemas frecuentemente actúa como consultor y, por lo tanto, puede ser contratado específicamente para que se encargue de los asuntos de los sistemas de información dentro de un negocio. Esto puede ser una ventaja, debido a que los consultores externos pueden llevar con ellos una perspectiva fresca que no poseen otros miembros de la organización. Pero también puede decirse que los analistas externos están en desventaja, debido a que la verdadera cultura organizacional nunca puede ser conocida por un extraño.

El analista de sistemas como experto de soporte.

Otro papel que tal vez requiera desarrollar es el de experto de soporte en un negocio donde se está empleado regularmente en alguna actividad de sistemas. En este papel el analista se apoya en su experiencia profesional relacionada con el hardware y software de computadora y su uso en el negocio. Este trabajo frecuentemente no es un proyecto de sistema completo, sino solamente pequeñas modificaciones o decisiones que afectan a un solo departamento.

El analista de sistemas como agente de cambio.

El papel más comprensivo y responsable que toma un analista de sistemas es el de agente de cambio, ya sea interno o externo al negocio. Como analista se es un agente de cambio cada vez que se ejecuta cualquiera de las actividades del ciclo de vida del desarrollo de sistemas (tratado en la siguiente sección) y se está presente en el negocio por un periodo extendido (desde dos semanas hasta más de un año). Un agente de cambio puede ser definido como una persona que sirve de catalizador para el cambio, desarrolla un plan para el cambio y trabaja junto con otros para facilitar ese cambio.

d) EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS.

Identificación de problemas, oportunidades y objetivos.

En la primera fase del ciclo de vida del desarrollo de sistemas el analista tiene que ver con la identificación de problemas, oportunidades y objetivos. Esta etapa es crítica para el éxito del resto de proyecto, debido a que nadie quiere desperdiciar el tiempo subsecuente resolviendo el problema equivocado. La primera fase requiere que el analista observe honestamente lo que está sucediendo en un negocio. Luego, junto con los demás miembros de la organización, el analista hace resaltar los problemas. Frecuentemente estos ya han sido vistos por los demás, y son la razón

por la cual el analista fue llamado inicialmente. Las personas involucradas en la primera fase son los usuarios, analistas y administradores de sistemas que coordinan el proyecto. Las actividades de esta fase consisten en entrevistas a los administradores de los usuarios, sumarización del conocimiento obtenido, estimación del alcance del proyecto y documentación de los resultados. La salida de esta fase es un estudio de factibilidad que contiene una definición del problema y la sumarización de los objetivos. Luego los administradores deben tomar una decisión para ver si continúan con el proyecto propuesto.

Determinación de los requerimientos de información.

Entre las herramientas utilizadas para definir los requerimientos de información en el negocio se encuentran: muestreo e investigación de los datos relevantes, entrevistas, cuestionarios, el comportamiento de los tomadores de decisiones y su ambiente de oficina y hasta la elaboración de prototipos. En esta fase el analista está esforzándose por comprender qué información necesitan los usuarios para realizar su trabajo. Las personas involucradas en esta fase son los analistas y los usuarios, típicamente los administradores de las operaciones y los trabajadores de las operaciones.

Análisis de las necesidades del sistema.

La siguiente fase que realiza el analista de sistemas involucro el análisis de las necesidades del sistema. Nuevamente, herramientas y técnicas especiales ayudan para que el analista haga las determinaciones de los requerimientos. Una herramienta de éstas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones del negocio en forma gráfica estructurado. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos, que lista todos los conceptos de datos usados en el sistema, así como sus especificaciones, si son alfanuméricos y qué tanto espacio ocupan cuando se imprimen. Durante esta fase el analista de sistemas también analiza las decisiones estructuradas que se hacen. Las decisiones estructuradas son aquellas para las que pueden ser determinadas las condiciones como alternativas de condición, acciones y reglas de acción. Hay tres métodos principales para el análisis de decisiones estructurales: lenguaje estructurado, tablas de decisión y árboles de decisión.

Diseño del sistema recomendado.

En esta fase del ciclo de vida del desarrollo de sistemas, el analista usa la información recolectada anteriormente para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos, a fin de que los datos que van a entrar al sistema de información sean correctos. Además, el analista también proporciona entrada efectiva para el sistema de información mediante el uso de técnicas para el buen diseño de formas y pantallas.

Desarrollo y documentación del software.

En la quinta fase del ciclo de vida del desarrollo de sistemas el analista trabaja con los programadores para desarrollar cualquier software original que se necesite. Durante esta fase, el

analista también trabaja con los usuarios para desarrollar documentación efectiva para el software, incluyendo manuales de procedimientos. La documentación le dice al usuario la manera de usar el software y también qué hacer si se suceden problemas con el software.

Pruebas y mantenimiento del sistema.

Antes de que pueda ser usado, el sistema de información debe ser probado. Es mucho menos costoso encontrar problemas antes de que el sistema sea entregado a los usuarios. Algunas de las pruebas son realizadas por los programadores solos, y otras por los analistas de sistemas junto con los programadores. Primero se ejecuta una serie de pruebas para que destaquen los problemas con datos de ejemplo y eventualmente con datos reales del sistema actual. El mantenimiento del sistema y de su documentación comienza en esta fase y es efectuado rutinariamente a lo largo de la vida del sistema de información.

Implementación y evaluación del sistema.

En esta fase del desarrollo del sistema el analista ayuda a implementar el sistema de información. Esto incluye el entrenamiento de los usuarios para que manejen el sistema. Algún entrenamiento es hecho por los proveedores, pero la supervisión del entrenamiento es responsabilidad del analista de sistemas. Adicionalmente, el analista necesita un plan para una conversión suave del sistema antiguo al nuevo. La evaluación se muestra como parte de esta fase final de ciclo de vida del desarrollo del sistema, principalmente para efectos de discusión. De hecho, la evaluación se realiza durante cada fase. Un criterio principal que debe ser satisfecho es si los usuarios pretendidos ya están usando el sistema.

La importancia del mantenimiento.

Después de que el sistema está instalado se le debe dar mantenimiento, esto significa que los programas de computadora deben ser modificados y mantenidos actualizados. La figura muestra la cantidad promedio de tiempo empleada en mantenimiento en una instalación MIS típica.

El mantenimiento se realiza por dos razones. La primera de estas es para corregir errores de software. Sin importar que tan completamente se pruebe el sistema, se deslizan errores en los programas de computadora. Los errores del software comercial para microcomputadoras son a veces documentados como "anomalías conocidas", y son corregidos cuando son lanzadas nuevas versiones del software o versiones intermedias. En el software personalizado los errores deben ser corregidos conforme son detectados. La otra razón para realizar el mantenimiento del sistema es para mejorar las capacidades del software en respuesta a las necesidades organizacionales cambiantes y, por lo general, involucran algunas de las siguientes tres situaciones:

1. Los usuarios frecuentemente solicitan características adicionales después de que se familiarizan con el sistema de cómputo y sus capacidades. Estas características solicitadas pueden ser tan simples como el desplegado de totales adicionales en un reporte o tan complicadas como el desarrollo de nuevo software.

2. El negocio cambia a través del tiempo. Se debe modificar el software para abarcar cambios tales como nuevos requerimientos de reportes gubernamentales o corporativos, la necesidad de producir nueva información para clientes, etcétera.

3. El hardware y software están cambiando a un ritmo acelerado. Un sistema que usa tecnología antigua puede ser modificado para usar las capacidades de una tecnología más nueva. Un ejemplo de tal cambio es el reemplazo de una Terminal de macrocomputadora con una estación de trabajo de microcomputadora, o una microcomputadora con una computadora de escritorio.

La figura ilustra la cantidad de recursos, por lo general tiempo y dinero, gastados en el desarrollo y mantenimiento del sistema. El área bajo la curva representa la cantidad total de dólares gastada. Se puede ver que a lo largo del tiempo es probable que el costo de mantenimiento exceda al del desarrollo del sistema. En cierto punto es más conveniente realizar un nuevo estudio del sistema, debido a que el costo de mantenimiento continuado es claramente mayor que la creación de un sistema de información completamente nuevo. Resumiendo, el mantenimiento es un proceso continuo a lo largo del ciclo de vida de un sistema de información. Después de que es instalado el sistema de información, el mantenimiento por lo general toma la forma de corrección de errores de programa no detectados previamente. Una vez que son corregidos, el sistema alcanza un estado estable proporcionando servicios contables a sus usuarios. El mantenimiento durante este periodo puede consistir en la eliminación de unos cuantos errores no detectados anteriormente y la actualización del sistema con una cuantas mejoras menores. Sin embargo, conforme pasa el tiempo y cambia el negocio y la tecnología, los esfuerzos de mantenimiento se incrementan dramáticamente.

e) USO DE LAS HERRAMIENTAS CASE.

A lo largo de este libro enfatizamos la necesidad de un enfoque sistemático y profundo al análisis, diseño e implementación de los sistemas de información. Reconocemos que para ser productivos los analistas de sistemas debe ser organizado, preciso y completo en lo que se proponen hacer. En los últimos años los analistas han comenzado a beneficiarse de nuevas herramientas de productividad que han sido creadas implícitamente para mejorar su trabajo rutinario mediante un apoyo automatizado. A estas se les llama herramientas CASE, que significa herramientas para ingeniería de software asistido por computadora. Los analistas se apoyan en las herramientas CASE para aumentar la productividad, comunicarse más efectivamente con los usuarios e integrar el trabajo que realizan en el sistema, desde el principio hasta el fin del ciclo de vida.

Aumento de la productividad del analista.

Estas herramientas permiten que sus usuarios tracen y modifiquen diagramas fácilmente. Por nuestra definición, el analista puede entonces llegar a ser más productivo simplemente por la reducción del tiempo considerable que es gastado típicamente en el trazo manual de diagramas de flujo de datos hasta que son aceptados.

Mejora de la comunicación del analista-usuario.

Para que el sistema propuesto se convierta en realidad y sea usado de hecho, es esencial una comunicación excelente entre los analistas y usuarios a lo largo del ciclo de vida del desarrollo del sistema. El éxito de una eventual implementación del sistema depende de la capacidad de los analistas y usuarios para comunicarse en una forma significativa. Hasta ahora los analistas que actualmente usan las nuevas herramientas CASE han experimentado que su uso promueve una comunicación mayor y más significativa entre usuario y analistas.

Integración de las actividades del ciclo de vida

La tercera razón para el uso de herramientas CASE es para integrar las actividades y proporcionar continuidad de una fase a la siguiente a lo largo del ciclo de vida del desarrollo de sistemas. Las herramientas CASE son especialmente útiles cuando una fase particular del ciclo de vida requiere varias interacciones o retroalimentación y modificación.

Evaluación precisa de los cambios del mantenimiento

La cuarta razón, y posiblemente una de las más importantes para el uso de herramientas CASE, es que permite que los usuarios analicen y valoren el impacto de los cambios de mantenimiento. Por ejemplo, puede ser que el tamaño de un elemento, tal como un número de cliente, necesite ser agrandado.

2. COMPRENSIÓN DE LOS ESTILOS ORGANIZACIONALES Y SU IMPACTO SOBRE LOS SISTEMAS DE INFORMACIÓN

a) FUNDAMENTOS ORGANIZACIONALES

Para analizar y diseñar adecuadamente los sistemas de información, el analista de sistemas necesita comprender las organizaciones en que trabaja como sistemas conformados por la interacción de tres fuerzas principales: los niveles de administración, el diseño de la organización y la cultura organizacional. Las organizaciones son sistemas grandes compuestos de subsistemas interrelacionados. Los subsistemas son relacionados por tres amplios niveles de administradores que toman decisiones (operación, administración media y administración estratégica) y que cortan horizontalmente a través del sistema organizacional. Las culturas y subculturas organizacionales influencian la manera en que se interrelaciona la gente en los subsistemas.

b) LAS ORGANIZACIONES COMO SISTEMAS

Las organizaciones son conceptualizadas en forma útil como sistemas diseñados para lograr metas y objetivos predeterminados por medio de la gente y otros recursos que emplean. Las organizaciones están compuestas de sistemas más pequeños interrelacionados (departamentos, unidades, divisiones, etc.) que sirven a funciones especializadas.

La interrelación e interdependencia de los sistemas

Todos los sistemas y subsistemas están relacionados y son interdependientes. Este hecho tiene implicaciones importantes para las organizaciones y para los analistas de sistemas que buscan ayudarlos a lograr mejor sus objetivos. Cuando cualquier elemento de un sistema es cambiado o eliminado, también son impactados el resto de los elementos y subsistemas del sistema.

Retroalimentación del sistema para planeación y control

La retroalimentación es una forma de control del sistema. Como sistemas, todas las organizaciones usan planeación y control para administrar sus recursos en forma efectiva.

Ambientes para sistemas organizacionales

La retroalimentación es recibida desde el interior de la organización y del ambiente exterior que la rodea. Cualquier cosa que esté fuera de las fronteras de una organización es considerada como un ambiente. Varios ambientes, con diversos grados de estabilidad, constituyen el medio ambiente en donde existe la organización. Aunque se pueden planear cambios en el estado del ambiente, frecuentemente no pueden ser controlados directamente por la organización.

Apertura y restrictividad en las organizaciones

La apertura y restrictividad existen en forma continua, ya que no hay una cosa tal como una organización absolutamente abierta o totalmente cerrada. La apertura se refiere al libre flujo de información dentro de una organización. Los subsistemas tales como los departamentos creativos o artísticos frecuentemente son caracterizados como abiertos, con un flujo libre de ideas entre sus participantes y muy pocas restricciones sobre quién obtiene tal información y en qué momento un proyecto creativo está en su infancia. Al extremo opuesto de este continuo puede estar una unidad del departamento de defensa asignada para trabajar sobre la planeación muy confidencial que afecta la seguridad nacional. Cada persona necesita recibir acreditación, la información en su momento es una necesidad y el acceso a la información se da con base en la que "es necesario saber". Este tipo de unidad está limitada por muchas reglas.

Cómo tomar una perspectiva de sistemas

La toma de una perspectiva de sistemas permite a los analistas de sistemas iniciar la clarificación y comprensión de los diversos negocios con los que entrarán en contacto. Es importante que los miembros de subsistemas se den cuenta que su trabajo está interrelacionado.

REPRESENTACIÓN GRÁFICA DE SISTEMAS

Un sistema o subsistema, tal como existe dentro de la organización corporativa, puede ser representado gráficamente en varias formas. Los diversos modelos gráficos muestran las fronteras del sistema y la información usada dentro del sistema.

Los sistemas y el diagrama de flujo de datos a nivel contexto

El primer modelo es el diagrama de flujo de datos a nivel contexto (también llamado modelo ambiental). Los diagramas de flujos de datos se enfocan en los datos fluyendo hacia adentro y fuera del sistema y el procesamiento de los datos. Estos componentes básicos de todo programa de computadora pueden ser descritos a detalle y usados para analizar el problema con respecto a su precisión y totalidad. El diagrama a nivel de contexto emplea solamente tres símbolos: (1) un rectángulo con esquinas redondeadas, (2) un cuadrado con dos orillas sombreadas y (3) una flecha, tal como se muestra en la figura.

Los procesos transforman los datos de entrada en información de salida, y el nivel de contenido tiene solamente un proceso que representa al sistema completo. La entidad externa representa cualquier entidad que proporciona o recibe información de sistema pero que no es parte del sistema. Esta entidad puede ser una persona, un grupo de personas, una posición corporativa o departamento u otros sistemas. Las líneas que conectan las entidades externas con el proceso son llamados flujos de datos y representan datos.

Un ejemplo de un diagrama de flujo de datos a nivel contexto se encuentra en la siguiente figura. En este ejemplo se representan los elementos básicos de un sistema de

Reservaciones de una línea aérea.

El pasajero (una entidad) inicia una petición de viaje (flujo de datos). El diagrama a nivel contexto no muestra suficientes detalles para indicar exactamente lo que sucede (y tampoco se pretende que se muestre), pero podemos ver que se envían las preferencias del pasajero y los vuelos disponibles al agente de viajes, que envía de regreso al proceso información sobre los boletos. También podemos ver que la reservación del pasajero es enviada a la línea aérea.

Los sistemas y el modelo entidad-relación

Una manera en que un analista de sistemas puede definir las fronteras adecuadas del sistema es usar un modelo entidad-relación. Los elementos que conforman un sistema organizacional pueden ser llamados entidades. Una entidad puede ser una persona, un lugar o una cosa, tal como un pasajero en una línea aérea, un destino o un avión. En forma alterna, una entidad puede ser un evento, tal como el fin de mes, un periodo de ventas o la falla de una máquina. Una relación es la asociación que describe la interacción entre las entidades. El formato estándar para trazar un diagrama entidad-relación (o E-R),

Mostrado en la figura, usa solamente dos símbolos: un rectángulo y un rombo. El rectángulo es usado para mostrar una entidad, y el rombo representa la relación entre esa entidad y otra entidad. El diagrama siempre es trazado poniendo en la parte superior a la entidad primaria.

La figura muestra los cuatro tipos diferentes de diagramas E-R. El primero es una relación uno a uno (1:1). Aquí a cada EMPLEADO le es asignada solamente una EXTENSIÓN TELEFÓNICA, y cada EXTENSIÓN TELEFÓNICA es única para cada EMPLEADO. El segundo diagrama muestra una relación muchos a uno (M:1). Un DEPARTAMENTO puede tener muchos EMPLEADOS, pero el EMPLEADO puede pertenecer a solamente un DEPARTAMENTO.

El tercer tipo de diagrama (E-R) muestra una relación uno a muchos (1:M). Por último, el cuarto diagrama muestra una relación muchos a muchos (M:N). Un VUELO puede llevar muchos PASAJEROS y un PASAJERO puede tener muchos VUELOS en su itinerario. Los diagramas entidad-relación son usados frecuentemente por los diseñadores de sistemas para ayudar a modelar el archivo o base de datos. Sin embargo, es todavía más importante que el analista de sistemas comprenda desde las primeras etapas las entidades y relaciones en el sistema organizacional. Para trazar algunos diagramas E-R básicos el analista necesita:

1. Listar las entidades de la organización para obtener una mejor comprensión de la organización.

2. Escoger entidades clave para estrechar el alcance del problema a dimensiones manejables y significativas.

3. Identificar cuál debe ser la entidad primaria.

4. Confirmar los resultados de los pasos 1 a 3 por medio de otros métodos de recolección de datos (investigación, entrevistas, administración de cuestionarios, observación y elaboración de prototipos).

NIVELES DE ADMINISTRACIÓN

La administración existe en las organizaciones en tres amplios niveles horizontales: control operacional, planeación y control administrativo y administración estratégica, tal como se muestra en la siguiente figura. Cada nivel tiene sus propias responsabilidades y todos trabajan para el logro de metas y objetivos organizacionales en su manera propia.

Administración de operaciones

El control operacional forma el nivel inferior de la administración a tres niveles. Los administradores de operaciones toman decisiones usando reglas predeterminadas que tienen resultados predecibles cuando son implementadas correctamente. Los administradores de operaciones son los tomadores de decisiones cuyo trabajo es el más claro, debido al alto nivel de certeza en su ambiente de toma de decisiones.

Administración media

La administración media forma el nivel segundo, o intermedio, del sistema de administración de tres niveles. La administración media realiza decisiones de planeación y control a corto plazo sobre

la manera en que son mejor asignados los recursos para satisfacer los objetivos organizacionales. La administración media experimenta muy poca certeza en su ambiente de toma de decisiones.

Administración estratégica

La administración estratégica comprende el tercer nivel del control administrativo de tres niveles. Los administradores estratégicos ven fuera de la organización hacia el futuro, tomando decisiones que guiarán a los administradores medios o de operación en los meses y años por venir. Los administradores estratégicos trabajan en un ambiente de toma de decisiones altamente incierto.

Implicaciones para el desarrollo de sistemas de información

Cada uno de los tres niveles de administración tiene diferentes implicaciones para el desarrollo de sistemas de información para la administración. Algunos de los requerimientos de información para los administradores están bien definidos y, en cambio, otros son difusos y se traslapan. Los administradores de operaciones necesitan información interna que es, por naturaleza, de bajo nivel y repetitiva. Tienen gran dependencia sobre la información que captura el desempeño actual y son grandes usuarios de recursos de información en línea de tiempo real. La necesidad de los administradores de operaciones de información sobre el desempeño pasado y la información periódica es solamente moderada. Ellos tienen poco uso para información externa que les permita proyecciones futuras o creación de escenarios "qué pasa si".

En el siguiente nivel de administración, la administración media, que tanto planea como controla, se necesita información de corto y largo plazo. Debido a la naturaleza de su trabajo de resolver problemas, los administradores medios experimentan necesidades extremadamente altas de información en tiempo real. Para poder controlar adecuadamente también necesitan información actual del desempeño medido en comparación a juegos de estándares. Los administradores estratégicos (difieren, en buena medida, de los administradores medios y de operaciones en sus requerimientos de información. Son altamente dependientes de información de fuentes externas que les proporciona noticias sobre las tendencias del mercado y las estrategias de corporaciones con las que compiten.

Debido a que la tarea de la administración estratégica demanda proyecciones hacia un futuro incierto, los administradores estratégicos tienen una gran necesidad de información de naturaleza predictiva e información que les permita la creación de muchos escenarios "qué pasa si". Los administradores estratégicos también muestran grandes necesidades de información reportada periódicamente cuando buscan adaptarse a cambios rápidos.

Los planeadores estratégicos necesitan información general resumida, en vez de los datos burdos altamente detallados requeridos por los administradores de bajo nivel. La información para los planeadores estratégicos puede ser más antigua y estimada y, en cambio, los administradores operacionales necesitan información precisa y actual.

Por último, el planeador estratégico necesita información cualitativa, principalmente de fuentes externas, en vez de la información cuantitativa de fuentes internas requerida por la administración de operaciones.

3. DETERMINACIÓN DE LA FACTIBILIDAD Y EL MANEJO DE LAS ACTIVIDADES DE ANÁLISIS Y DISEÑO

Los cuatro puntos principales que el analista de sistemas debe manejar son:

a) Iniciación del proyecto,

b) Determinación de la factibilidad del proyecto,

c) Calendarización del proyecto, y,

d) Administración de los miembros del equipo del análisis del sistema.

El revisar la salida, la observación del comportamiento de los empleados y el escuchar la retroalimentación, son maneras que ayudarán al analista a resaltar los problemas y oportunidades de los problemas.

Los proyectos pueden ser solicitados por muchas personas diferentes dentro del negocio o por los mismos analistas de sistema. La selección de un proyecto es una decisión difícil, debido a que serán solicitados más proyectos de los que pueden ser hechos. Cinco criterios importantes para la selección de proyectos son:

a) Que el proyecto solicitado esté respaldado por la administración,

b) Que tenga el tiempo adecuado para la asignación de recursos,

c) Que mueva al negocio hacia la obtención de sus objetivos,

d) Que sea practicable, y,

e) Que sea lo suficientemente importante para ser considerado en vez de otros proyectos posibles.

Si un proyecto solicitado satisface estos criterios, entonces puede ser elaborado un estudio de factibilidad de sus méritos operacionales, técnicos y económicos. Por medio de este estudio los analistas de sistemas recopilan datos que permiten a la administración decidir si continúan con un estudio de sistema completo.

La planeación del proyecto incluye la estimación del tiempo requerido por cada una de las actividades del analista, su calendarización y la agilización de ellas, si es necesario, para asegurar que un proyecto sea terminado a tiempo. Una técnica de que dispone el analista de sistemas para la calendarización de tareas es la gráfica de Gantt, la cual despliega actividades en forma de barras en una gráfica. La calendarización de proyectos basada en computadora, es ahora una práctica común, debido principalmente al uso de interfaces de usuario gráficas. Adicionalmente, se pueden

usar los administradores de información personales (PIM) por los analistas para planear, crear depósitos de números telefónicos y de fax y hasta ejecutar otros programas.

Una segunda técnica, llamada PERT (evaluación de programas y técnicas de revisión), despliega las actividades como flechas en una red. El PERT ayuda a que el analista determine la ruta crítica y el tiempo de holgura, que es la información requerida para el control efectivo del proyecto. Cuando es necesario terminar un proyecto en menor tiempo, el analista puede reducir la duración total del proyecto identificando y agilizando las actividades principales.

Una vez que ha sido juzgado factible, el analista de sistemas debe administrar a los miembros del equipo, sus actividades, tiempo y recursos. La mayor parte de esto se logra mediante la comunicación con los miembros del equipo. Los equipos están constantemente buscando un balance entre trabajar sobre las tareas y mantener las relaciones con el equipo. Deben ser solucionadas las tensiones que suceden al intentar lograr este balance. Frecuentemente emergen dos líderes en un equipo, un líder de tarea y un líder socioemocional. Los miembros deben valorar periódicamente las normas del equipo para asegurarse de que sean funcionales en vez de disfuncionales para el logro de los objetivos de equipo.

Es importante que el equipo de análisis ponga objetivos de productividad razonables para las salidas tangibles y las actividades del proceso. Las fallas del proyecto pueden ser evitadas, por lo general, examinando las motivaciones de los proyectos solicitados, así como los motivos del equipo para recomendar o evitar un proyecto particular.

UNIDAD II

Análisis de los requerimientos de información

4. MUESTREO E INVESTIGACIÓN DE DATOS IMPRESOS.

El proceso de seleccionar sistemáticamente elementos representativos de una población es llamado muestreo. El objeto del muestreo es seleccionar y estudiar documentos, tales como facturas, reportes de ventas y memorándums, o tal vez seleccionar y entrevistar, dar cuestionarios u observar a miembros de la organización. El muestreo puede reducir costos, velocidad de recolección de datos, hacer potencialmente que el estudio sea más efectivo y posiblemente reducir la ascendencia en el estudio. Cuatro tipos principales de muestras que tiene el analista. Un analista de sistemas debe seguir cuatro pasos en el diseño de una buena muestra. Primero, se tiene la necesidad de determinar la población misma. Segundo, se debe decidir el tipo de muestra. Tercero, se debe calcular el tamaño de muestra. Por último, se deben planear los datos que necesitan ser recolectados o descritos. Tipos de información buscada en la investigación Los tipos de muestras útiles para un analista de sistemas son: de conveniencia, intencionada, aleatoria simple y aleatoria compleja. El último tipo incluye las subcategorías de muestreo sistemático y muestreo estratificado. Hay varios lineamientos a seguir para la determinación del tamaño de muestra. El analista de sistemas puede hacer una decisión subjetiva en relación con el estimado de

intervalo aceptable. Luego se selecciona un nivel de confianza y puede ser calculado el tamaño de muestra necesario.

El analista de sistemas necesita investigar datos relevantes, incluyendo reportes, documentos, estados financieros, manuales de procedimientos y memorándums. Los datos relevantes muestran dónde ha estado la organización y hacia dónde creen sus miembros que están yendo. Es necesario que sean analizados documentos cuantitativos y cualitativos.

Debido a que los documentos son mensajes persuasivos, debe ser reconocido que el cambiarlos también puede cambiar a la organización. Las consignas que se colocan revelan la cultura oficial de la organización Hay muchas formas de analizar documentos cuantitativos y cualitativos. Sin embargo, es importante recordar que la investigación de los datos archivados tiene ventajas y desventajas. Debido a que muchas de las desventajas pueden ser superadas, vale la pena la investigación de archivos. Una de las desventajas del uso de datos archivados es que los datos pueden ser importantes solamente para aquel que originalmente los guardó.

5. ENTREVISTAS.

El proceso de las entrevistas es un método que usa el analista de sistemas para la recolección de datos sobre los requerimientos de información. El analista de sistemas escucha buscando objetivos, sentimientos, opiniones y procedimientos informales en entrevistas con los tomadores de decisiones de la organización. También vende el sistema durante las entrevistas. Las entrevistas son diálogos de preguntas respuestas planeados por anticipado entre dos personas.

Hay cinco pasos que deben tomarse para la planeación previa de la entrevista:

1. Lectura de material de fondo

2. Establecimiento de objetivos de la entrevista

3. Decisión de a quién entrevistar

4. Preparación del entrevistado

5. Decisión sobre el tipo y estructura de las preguntas

Las preguntas tienen dos tipos básicos: abiertas y cerradas. Las preguntas abiertas dejan abiertas todas las opciones de respuesta para el entrevistado, Las preguntas cerradas limitan las opciones posibles de la respuesta. Las averiguaciones pueden ser abiertas o cerradas, pero le solicitan al interlocutor una respuesta más detallada. Las entrevistas pueden estar estructuradas en tres formas básicas, estructura de pirámide, de embudo o de rombo. Las estructuras piramidales comienzan con preguntas cerradas y detalladas y se amplían a preguntas más generales. Las estructuras de embudo comienzan con preguntas abiertas generales y luego se estrechan a preguntas cerradas más específicas. Las estructuras de rombo combinan las fuerzas de las otras dos estructuras pero se llevan más tiempo para realizarse. Hay compromisos involucrados sobre la decisión de cómo estructurar para realizar las preguntas y secuencias de preguntas de la

entrevista. Las entrevistas deben ser grabadas por medio de grabadoras de cinta o la toma de notas. Después de la entrevista, el entrevistador debe escribir un reporte que liste los puntos principales que se proporcionaron, así como opiniones acerca de lo que fue dicho. Es extremadamente importante documentar la entrevista lo más pronto posible después de que haya sido realizada. Para reducir tanto el tiempo como el costo de las entrevistas personales, los analistas pueden considerar el diseño conjunto de aplicaciones (JAD) como una alternativa. Mediante el uso del JAD los analistas logran tanto el análisis de requerimientos como el diseño de la interfaz de usuario con los usuarios en un lugar de reunión de grupo. La valoración cuidadosa del lugar de reunión para la organización ayudará a juzgar al analista si el JAD es una alternativa adecuada.

6. USO DE CUESTIONARIOS.

Mediante el uso de cuestionarios los analistas de sistemas pueden recolectar datos sobre actitudes, creencias, comportamientos y características de gentes importantes en la organización. Los cuestionarios son útiles sí: las personas de la organización están ampliamente dispersas, muchas gentes están involucradas con el proyecto de sistema, se necesita un trabajo exploratorio antes de recomendar alternativas o hay una necesidad para la sensibilización del problema antes de que se realicen entrevistas. Una vez que han sido articulados los objetivos del cuestionario, el analista puede comenzar a escribir preguntas abiertas o cerradas. La selección de la redacción es extremadamente importante y debe reflejar el lenguaje de los miembros de la organización. Idealmente, las preguntas deben ser simples, específicas, sin ascendencia, sin menosprecio, técnicamente precisas y dirigidas a aquellos que tienen el conocimiento. La asignación de escalas es el proceso de asignar números u otros símbolos a un atributo o característica. Tal vez quiera el analista de sistemas usar escalas para medir las actitudes o las características de los interlocutores o para hacer que los interlocutores actúen como jueces sobre el tema del cuestionario.

Las cuatro formas de medición son escalas nominales, ordinales, de intervalo y de relación. La forma de medición es frecuentemente indicada por los datos, y el análisis de los datos es a su vez indicado en alguna medida por la forma de medición.

Los analistas de sistemas necesitan tomar en consideración la validez y la confiabilidad. La validez significa que el cuestionario mide lo que el analista de sistemas pretendió medir. La confiabilidad significa que los resultados son consistentes.

Los analistas deben ser cuidadosos para evitar problemas como lenidad, tendencia central y el efecto de halo cuando construyen escalas. El control consistente del formato y estilo del cuestionario puede dar como resultado una mejor tasa de respuesta. Adicionalmente, el ordenamiento y agrupamiento significativo de las preguntas es importante para ayudar a que los interlocutores comprendan el cuestionario.

7. OBSERVACIÓN DEL COMPORTAMIENTO DE LOS TOMADORES DE DECISIONES Y EL AMBIENTE DE OFICINA.

Los analistas usan la observación como una técnica de recopilación de ir, formación. Por medio de la observación obtienen apreciaciones sobre lo que se hace realmente, ven de primera mano las relaciones entre los tomadores de decisiones en una organización, comprenden la influencia del ambiente físico de éste, interpretan los mensajes enviados por el tomador por medio de su vestimenta y el acomodo de su oficina y comprenden la influencia del tomador de decisiones con respecto a los demás. Usando el muestreo de tiempos o eventos, el analista observa las actividades típicas del tomador de decisiones y su lenguaje corporal. Hay varios sistemas para registrar tales observaciones, incluyendo sistemas di categorías, listas de verificación, escalas, notas de campo y guiones. Además de la observación del comportamiento del tomador de decisiones, el analista de sistemas debe observar también lo que le rodea. Un método para la observación estructurado del ambiente es llamado STROBE, Un analista de sistemas usa STROBE en la misma forma que un crítico de cine usa un método llamado mise-en-scène para analizar una toma de una película Varios elementos concretos del ambiente del tomador de decisiones pueden ser observados e interpretados. Estos elementos incluyen (1) la ubicación de la oficina, (2) la ubicación del escritorio del tomador de decisiones, (3) el equipo de oficina fijo, (4) las propiedades, tales como calculadoras y pantallas, (5) revistas del negocio y periódicos, (6) iluminación y color de la oficina y (7) la vestimenta usada por el tomador de decisiones. Se puede usar STROBE para obtener una mejor comprensión sobre la manera en que los tomadores de decisiones actualmente recopilan, procesan, guardan y comparten información, Hay varias alternativas para la aplicación de STROBE en una organización. Estas incluyen el análisis de fotografías, el uso de una lista de verificación con base en la escala Likert, la adopción de una lista anecdótica con símbolos y la simple escritura de una comparación de observación/narrativa, Cada método tiene determinadas ventajas, así como desventajas, que el analista debe sopesar cuando seleccione una alternativa sobre la otra.

8. PROTOTIPOS.

La elaboración de prototipos es una técnica de recopilación de información útil para complementar el ciclo de vida de desarrollo de un sistema tradicional. Cuando el analista de sistemas usa prototipos está buscando reacciones, sugerencias, innovaciones y planes de revisión del usuario para hacer mejoras al prototipo y, por lo tanto, modificar los planes del sistema con un mínimo de gastos y trastornos. Los sistemas que apoyan la toma de decisiones semiestructuradas (tal como lo hacen los sistemas de apoyo a decisiones) son buenos candidatos para la elaboración de prototipos.

El término prototipo tiene diferentes significados, de los cuales son comúnmente usados cuatro de ellos. La primera definición de la elaboración de prototipos es la de construcción de un prototipo parchado. Una segunda definición es un prototipo no operacional que es usado para probar determinadas características del diseño. Un tercer concepto es la creación de un prototipo primero de la serie que es completamente operacional. Este tipo de prototipo es útil cuando están

planeadas muchas instalaciones del mismo sistema de información (bajo condiciones similares). El cuarto tipo es un prototipo con características seleccionadas que tiene algunas, pero no todas, de las características esenciales del sistema. Usa módulos autocontenidos como bloques de construcción, para que si las características prototípicas son satisfactorias puedan ser conservadas e incorporadas en el sistema terminado mucho más grande.

Los cuatro lineamientos principales para el desarrollo de un prototipo son: (1) trabajar en módulos manejables, (2) construir el prototipo rápidamente, (3) modificar el prototipo y (4) enfatizar la interfaz de usuario. Una desventaja de los prototipos es que el manejo del proceso de elaboración del prototipo es difícil, debido a la rapidez del proceso y a sus muchas iteraciones. Una segunda desventaja es que puede haber presiones para que sea puesto en servicio un prototipo incompleto, como si fuera un sistema completo. Aunque la elaboración de prototipos no es siempre necesaria o deseable, debe hacerse notar que hay tres ventajas principales interrelacionadas de su uso: (1) el potencial para cambiar el sistema en etapas tempranas de su desarrollo, (2) la oportunidad de detener el desarrollo de un sistema que no es funcional y (3) la posibilidad de desarrollar un sistema que satisfaga en mejor forma las necesidades y expectativas de los usuarios. Los usuarios tienen un papel distinguido en el proceso de elaboración de prototipos. Su primer interés debe ser interactuar con el prototipo mediante experimentación. Los analistas de sistemas deben trabajar sistemáticamente para obtener y evaluar las reacciones de los usuarios ante el prototipo, y luego trabajar para incorporar las sugerencias e innovaciones de los usuarios que valgan la pena en las modificaciones subsecuentes.

UNIDAD III

El uso del análisis

9. USO DE DIAGRAMAS DE FLUJO DE DATOS

Para comprender mejor el movimiento lógico de los datos en un negocio, el analista de sistemas traza diagramas de flujo de datos (DFD). Los diagramas de flujo de datos son análisis estructurados y herramientas de diseño que permiten que el analista comprenda visualmente el sistema y subsistemas como un juego de flujos de datos interrelacionados.

La representación gráfica del movimiento, almacenamiento y transformación de datos es trazada con el uso de cuatro símbolos: un rectángulo redondeado para indicar procesamiento o transformaciones de datos, un cuadrado doble para mostrar una entidad de datos externa (origen o receptor de datos), una flecha para mostrar el flujo de datos y un rectángulo de extremo abierto para mostrar un almacén de datos.

El analista de sistemas extrae procesos, fuentes, almacenes y flujos de datos desde las primeras narraciones organizacionales, y usa un enfoque de arriba hacia abajo para trazar primero un diagrama de contexto del sistema, dentro de la imagen más grande. Luego es trazado un diagrama de flujo de datos lógico a nivel 0. Se muestran los procesos y se añaden los almacenes de datos.

Luego el analista crea un diagrama hijo para cada uno de los procesos del Diagrama 0. Las entradas y salidas permanecen constantes, pero cambian los almacenes de datos y las fuentes. La explosión del diagrama de flujo original permite que el analista de sistemas se enfoque en las representaciones cada vez más detalladas de los movimientos de datos dentro del sistema. Luego, el analista desarrolla un diagrama de flujo de datos físico a partir del diagrama de flujo de datos lógico, particionándolo para facilitar la programación. Cada proceso es analizado para determinar si debe ser un procedimiento manual o automatizado. Los procesos automatizados son agrupados subsecuentemente en una serie de programas de computadora diseñados para ser por lotes o en línea. Seis consideraciones para partición de diagramas de flujo incluyen si:

1.- Hay procesos ejecutados por diferentes grupos de usuarios, hay procesos que se ejecuten al mismo tiempo

2.- Hay procesos que ejecuten tareas similares, los procesos por lotes pueden ser combinados para un procesamiento eficiente

3.- Los procesos pueden ser combinados en un programa para tener consistencia de datos

4.- O si los procesos pueden ser partidos en diferentes programas por razones de seguridad.

El diagrama de flujo de datos correcto para el ejemplo de la nómina.

Las ventajas de los diagramas de flujo de datos incluyen la simplicidad de la notación, usándola para obtener información más clara de los usuarios, permitiendo que el analista de sistemas conceptualice los flujos de datos necesarios sin estar atado a una implementación física particular, permitir que los analistas conceptualicen mejor las interrelaciones del sistema y sus subsistemas y analicen un sistema propuesto para determinar si han sido definidos los datos y procesos necesarios.

Características comunes de los diagramas de flujo de datos lógicos y físicos.

El diagrama de flujo de datos físico (abajo) muestra determinados detalles que no se encuentran en el diagrama de flujo de datos lógico (arriba).

10. ANÁLISIS DE SISTEMAS USANDO DICCIONARIOS DE DATOS.

Usando un enfoque de arriba hacia abajo, el analista de sistemas usa los diagramas de flujo de datos para comenzar la compilación de un diccionario de datos, que es una referencia que contiene datos acerca de datos, o "metadatos" sobre todos los datos de procesos, almacenes, flujos, estructuras y los elementos lógicos y físicos dentro del sistema que está siendo estudiado.

Una manera para comenzar es incluyendo todos los conceptos de datos de los diagramas de flujo de datos.

La forma en que el diccionario de datos se relaciona con el diagrama de flujo de datos.

Una colección grande de la información de proyecto es llamada un depósito. Las herramientas CASE permiten que el analista cree un depósito, que puede incluir información acerca de los flujos, almacenes, estructuras de registro y elementos de datos, la lógica de procedimiento de diseños de pantalla y reporte, relaciones de datos, requerimientos del proyecto y lo que produce el sistema final e información sobre la administración de proyecto. Cada entrada del diccionario de datos contiene: el nombre del concepto, una descripción verbal, alias, elementos de datos relacionados, rango, longitud, codificación y la información de edición necesaria. El diccionario de datos es útil en todas las fases del análisis, diseño y documentación última, debido a que es la fuente autorizada sobre la manera en que es usado y definido un elemento de datos en el sistema. Muchos sistemas grandes tienen diccionarios de datos computarizados que tienen referencias cruzadas con todos los programas de la base de datos que usan un elemento de datos particular.

Dos diagramas de flujo de datos y sus entradas del diccionario de datos correspondientes para la producción de un cheque de pago a un empleado.

11. DESCRIPCIÓN DE ESPECIFICACIONES DE PROCESO Y DECISIONES

ESTRUCTURADAS.

Una vez que el analista identifica los flujos de datos y comienza a construir el diccionario de datos es tiempo de pasar a las especificaciones de proceso y análisis de decisiones. Los tres métodos para el análisis de decisiones y la descripción de la lógica de proceso tratados en este capítulo son: lenguaje estructurado, tablas de decisión y árboles de decisión. Las especificaciones de proceso (o mini especificaciones) son creadas para los procesos primitivos en un diagrama de flujo de datos así como para algunos procesos de alto nivel que explotan a diagramas hijos. Estas especificaciones explican la lógica de toma de decisiones y las fórmulas que transformarán los datos de entrada al proceso en salida.

Los tres objetivos de la especificación de proceso son: reducir la ambigüedad de los procesos, obtener una descripción precisa de lo que se logra y validar el diseño de sistema. Una gran parte del trabajo del analista de sistemas involucrará decisiones estructuradas, esto es, decisiones que pueden ser automatizados si suceden condiciones identificadas. Para lograr esto, el analista necesita definir cuatro variables en la decisión que está siendo examinada: condiciones, alternativas de condición, acciones y reglas de acción.

Una forma para describir las decisiones estructuradas es usar el método mencionado como lenguaje estructurado, donde la lógica es expresada en estructuras secuenciales, estructuras de decisión, estructuras de caso o iteraciones.

El lenguaje estructurado usa palabras reservadas aceptadas, tales como SI, ENTONCES, SINO, HACER, HACER MIENTRAS y HACER HASTA para describir la lógica usada y usa sangrías para indicar la estructura jerárquica del proceso de decisión. Las tablas de decisión proporcionan otra forma para examinar, describir y documentar decisiones. Cuatro cuadrantes (vistos en sentido del reloj a partir de la esquina superior izquierda) son usados para: (1) describir las condiciones, (2) identificar alternativas de decisión posibles (tales como S o N), (3) indicar cuáles acciones deben ser ejecutadas y (4) describir las acciones. Las tablas de decisión son ventajosas, debido a que las reglas para desarrollar la tabla misma, así como las reglas para eliminar redundancia, contradicciones y situaciones imposibles son directas y manejables. El uso de tablas de decisión promueve la integridad y precisión en el análisis de decisión estructuradas.

El tercer método para el análisis de decisiones es el árbol de decisión que consiste de nodos (un cuadrado para acciones y un círculo para condiciones) y ramas. Los árboles de decisión son adecuados cuando se deben realizar acciones en una secuencia determinada. No hay requerimientos de que el árbol tenga que ser simétrico, por lo que solamente se encuentran en una rama particular aquellas condiciones y acciones que son críticas para las decisiones presentes.

Cada uno de los métodos de análisis de decisión tiene sus propias ventajas y debe ser usado de acuerdo con ellas. El lenguaje estructurado es útil cuando muchas acciones son repetidas y cuando es importante la comunicación con otros. Las tablas de decisión proporcionan análisis completo de situaciones complejas y a la vez limitan la necesidad por cambios atribuibles a situaciones imposibles, redundancias o contradicciones. Los árboles de decisión son importantes cuando es crítica la secuencia adecuada de condiciones y acciones y cuando cada condición no es relevante para cada acción.

Cada proceso del diagrama de flujo de datos se expande a un diagrama hijo, a una gráfica de estructura o a una especificación de proceso (tal como el lenguaje estructurado). Si el proceso es primitivo las especificaciones muestran la lógica, aritmética o algoritmos para transformar la entrada en la salida. Estas especificaciones del modelo lógico son parte de las reglas del negocio (que son usadas frecuentemente como la base para crear lenguajes procedurales cuando se usa generadores de código). Si el proceso se expande a un diagrama hijo o a una gráfica de estructura, la especificación de proceso describe el orden y condiciones bajo los cuales ejecutarán los procesos del diagrama hijo. Esta lógica de control es parte del modelo físico.

12. ANÁLISIS DE SISTEMAS DE APOYO A DECISIONES SEMIESTRUCTURADAS.

Los sistemas de apoyo a decisiones (DSS) son una clase especial de sistemas de información que enfatizan el proceso de toma de decisiones y cambian a los usuarios del DSS por medio de su interacción con el sistema. Los sistemas de apoyo a decisiones están bien adecuados para resolver problemas semiestructurados, donde el discernimiento humano todavía es deseado o requerido.

Los sistemas de apoyo a decisiones no dan una solución a los usuarios, sino que, en vez de ello, dan soporte al proceso de toma de decisiones ayudando al usuario a encontrar alternativas y considerar sus ramificaciones por medio de diferentes técnicas de modelado. Los usuarios del DSS o de los sistemas de apoyo a decisión en grupo (GDSS), vienen de todos los tres niveles administrativos de la organización. Sin embargo, las decisiones semiestructuradas son requeridas más frecuentemente por los niveles administrativos medio y estratégico. Los usuarios de un DSS son eventualmente cambiados por medio del proceso de interacción con el sistema. El estilo de toma de decisiones de los usuarios puede ser categorizado como analítico o heurístico. Los tomadores de decisiones analíticos tienden a dividir los problemas en componentes cuantitativos y usan modelos matemáticos para tomar una decisión y, en cambio, los tomadores de decisiones heurísticos se apoyan en la experiencia. Los sistemas de apoyo a decisiones pueden ser diseñados pensando en el estilo predominante del tomador de decisiones, para que a los pensadores analíticos se les proporcionen modelos cuantitativos y a los tomadores de decisiones heurísticos se les proporcione información resumida y ayudas de memoria que les permitan recordar cómo usaron la heurística en el pasado. Las decisiones semiestructuradas son aquellas en las que el discernimiento humano todavía es requerido o considerado deseable. Se considera que algunas decisiones son semiestructuradas debido a que el tomador de decisiones no posee las habilidades para la toma de decisión y poder tomar ésta.

También, si un problema es demasiado complejo es clasificado como semiestructurado. Por último, un problema puede ser llamado semiestructurado si deben ser atacados criterios múltiples. Los sistemas de apoyo a decisiones están especialmente bien indicados para ayudar a resolver problemas semiestructurados. En todas las soluciones de problemas los tomadores de decisiones recorren tres fases: inteligencia, selección y diseño. En la fase de inteligencia el tomador de decisiones está revisando ambientes de negocios internos y externos, buscando problemas y oportunidades potenciales. La fase de diseño consiste en la articulación del problema u oportunidad, descubriendo y creando alternativas, evaluándolas y examinando sus aplicaciones. La fase de selección está compuesta de la selección de una alternativa entre aquellas que han sido consideradas y la determinación de razones y argumentos para la adopción de esa solución. Los sistemas de apoyo a decisiones deben ser diseñados para dar soporte a decisiones en las tres fases de la solución de problemas. Un sistema de apoyo a decisiones completo debe ser capaz de dar apoyo a la toma de decisiones de criterios múltiples. El tomador de decisiones que usa este tipo de DSS tiene un gran repertorio de métodos disponibles, incluyendo un proceso de pro y contra, métodos ponderados, eliminación secuencias por lexicografía, eliminación secuencias por restricciones conjuntivas y la programación por metas.

13. PREPARACIÓN DE LA PROPUESTA DE SISTEMAS.

La evaluación de hardware y software, identificación y pronóstico de costos y beneficios y la realización de análisis de beneficio - costo son actividades necesarias que el analista de sistemas debe lograr para la preparación del material para la propuesta de sistema. Los requerimientos de información ayudan a conformar qué software es comprado o codificado, así como qué hardware es necesario para realizar las funciones de transformación de datos requeridas. Los analistas de

sistemas deben estimar las cargas de trabajo para caracterizar adecuadamente la capacidad de cargas de trabajo actual y la proyección necesaria para el hardware. Se pueden ejecutar cargas de trabajo de muestra en el hardware bajo consideración. Aunque el equipo de cómputo cambia rápidamente, el procedimiento usado para la evaluación del hardware no necesita cambiar. Mediante el inventariado del equipo que ya se tiene a la mano y pedido, los analistas de sistemas serán capaces de recomendar si se conserva el actual, o se modifica o se compra nuevo hardware computacional.

El hardware computacional puede ser adquirido mediante compra, arrendamiento financiero o renta. Los vendedores proporcionarán servicios de apoyo, tales como mantenimiento preventivo y entrenamiento a usuarios, que son típicamente negociados por aparte. Los paquetes de software también deben ser evaluados por el analista de sistemas y los usuarios pertinentes. Se puede ahorrar mucho tiempo de programación si uno de estos paquetes es utilizable sin gran personalización. El software necesita ser evaluado sobre qué tan bien desarrolla las funciones deseadas, su facilidad de uso, adecuación de la documentación y servicios de apoyo que puedan ofrecer los vendedores. La preparación de una propuesta significa la identificación de todos los costos y beneficios de varias alternativas. El analista de sistemas tiene varios métodos disponibles para pronosticar los costos, beneficios, volúmenes de transacciones y variables económicas futuras que afectan los costos y beneficios. Los costos y beneficios pueden ser tangibles (cuantificables) o intangibles (no cuantificables y resistentes a una comparación directa). Un analista de sistemas tiene muchos métodos para el análisis de costos y beneficios. El análisis de punto de equilibrio examina el costo del sistema existente contra el costo del sistema propuesto. El método de recuperación determina la cantidad de tiempo que transcurrirá antes de que el nuevo sistema sea rentable. El análisis de flujo de efectivo es adecuado cuando es crítico saber la cantidad de desembolsos de efectivo, y el valor presente toma en cuenta el costo de pedir dinero prestado. Estas herramientas ayudarán al analista a examinar las alternativas a la mano y tomar una recomendación bien documentada sobre la propuesta de sistemas.

Lineamientos para la evaluación de software

14. ESCRITURA Y PRESENTACIÓN DE LA PROPUESTA DE SISTEMAS.

Los analistas de sistemas tienen tres pasos principales a seguir para reunir una propuesta de sistemas efectiva: organizar funcionalmente el contenido de la propuesta, escribir la propuesta en un estilo de negocios apropiado y exponer verbalmente una propuesta de sistemas informativa. Debido a que la propuesta es el resultado del trabajo que ha sido realizado hasta el momento y el esfuerzo propuesto, es un documento crítico para vender el sistema. Para ser efectiva, la propuesta debe ser escrita en una forma clara y comprensible, y su contenido debe estar dividido en 10 secciones funcionales. Debe tener un título adecuado que atrape el interés de los lectores y refleje claramente lo que está por venir. La propuesta debe tener un resumen ejecutivo que proporcione un panorama conciso del proyecto de sistemas y las recomendaciones del analista.

Las consideraciones visuales son importantes cuando se arma una propuesta que comunica bien. Use suficiente espacio en blanco para destacar el texto, sea generoso cuando incluya encabezados y subencabezados, numere todas las páginas y mantenga al mínimo las referencias y los apéndices. Mucho de lo que es importante en la propuesta de sistemas puede ser mejorado mediante el uso adecuado de figuras, incluyendo tablas y gráficas. Las gráficas comparan dos o más variables a lo largo del tiempo o en un momento particular del tiempo. Las figuras siempre son acompañadas con una interpretación escrita en la propuesta. Las gráficas y tablas usadas para planeación, anteriormente a la propuesta, pueden ser incorporadas a ella cuando sean relevantes. La presentación verbal del sistema está basada en la propuesta escrita y es otra forma de vender eficientemente el sistema. Una opción para la presentación es crear una presentación de transparencias usando software de presentación. También, los paquetes de presentación gráficos y el clipart pueden ser usados para mejorar la presentación visual de la propuesta de sistemas. Lineamientos para la presentación verbal efectiva de la propuesta de sistemas. Para dar una fuerte presentación verbal, el analista debe conocer cuatro elementos por anticipado: quiénes compondrán la audiencia, el tema (presumiblemente la propuesta de sistemas o parte de ella), el tiempo asignado para la presentación y el equipo disponible (incluyendo la disposición de la sala). Los cuatro elementos están interrelacionados y cada uno necesita ser analizado y planeado para asegurar el éxito.

UNIDAD IV

Los puntos esenciales del diseño

15. DISEÑO DE SALIDA EFECTIVA

La salida es cualquier información útil o datos proporcionados por el sistema de información o, el sistema de apoyo a decisiones ante el usuario. La Salida puede tomar virtualmente cualquier forma, incluyendo la impresión, pantallas, audio, microformas, CD-ROM y electrónica. Estos diseñan la salida para que sirva al propósito pretendido y para que se ajuste al usuario, proporcionar la cantidad adecuada de salida, proporcionarla en el lugar adecuado, proporcionar la salida a tiempo y seleccionar la salida a tiempo y seleccionar el método de salida adecuado.

Es importante que el analista se dé cuenta de que el contenido de la salida está relacionado con el método de la salida. La salida de diferentes tecnologías afecta a los usuarios en formas diferentes. Las tecnologías de salida también difieren en su velocidad, costo, portabilidad, flexibilidad y posibilidades de almacenamiento y recuperación. Todos estos factores deben ser considerados cuando se decide entre impresión, en pantalla, audio, microformas o salida electrónica, o una combinación de estos métodos de salida. La presentación de la salida puede tergiversar la interpretación que los usuarios hacen de ella. Los analistas deben estar conscientes de las fuentes de ascendencia, interactuar con los usuarios para diseñar la salida, informar a los usuarios de las posibilidades de ascendencia en la salida, crear salida flexible y modificable y entrenar a los usuarios para que usen varias salidas para que les ayuden a verificar la precisión de cualquier reporte particular. Los reportes impresos son diseñados con el uso de hojas de diseño de reporte

en pantalla o en papel. El diccionario de datos sirve como fuente de los datos necesarios para cada reporte.

A los usuarios se muestran modelos o prototipos de los reportes antes de terminar el diseño de reporte y se realiza cualquier cambio necesario. El analista de sistemas usa el diseño de hoja o pantalla para comunicar el diseño físico al programador. Las pantallas VDT, que son una forma especialmente de salida para los sistemas de apoyo a decisiones, así como para los MIS tradicionales, son diseñadas usando formas de diseño de reporte en pantalla. Nuevamente, la estética y utilidad son importantes para crear una pantalla bien diseñada. Es importante producir prototipos de pantallas que permitan que los usuarios hagan cambios donde deseen. La salida gráfica en pantalla está llegando a ser cada vez más utilizado, en especial para los sistemas de apoyo a decisiones. El analista de sistemas debe considerar los efectos de las gráficas ante los usuarios, el tipo de datos debe ser desplegado, el objetivo de las gráficas y su audiencia pretendida. Se dispone de muchos paquetes de software dedicados a los gráficos. Es esencial que los tomadores de decisiones reciban entrenamiento sobre la forma de interpretar las gráficas para que les sean útiles.

16. DISEÑO DE ENTRADA EFECTIVO.

Este capítulo trata a los elementos del diseño de entrada para formas y pantallas VDT. La entrada bien diseñada debe satisfacer los objetivos de efectividad, precisión, facilidad de uso, consistencia y atractivo. El conocimiento de muchos elementos de diseño diferentes permitirá que el analista de sistemas alcance estos objetivos. Los cuatro lineamientos para las formas de entrada bien diseñadas son:

1. Las formas deben ser fáciles de llenar.

2. Las formas deben satisfacer el propósito para el que fueron diseñadas.

3. Las formas deben ser diseñadas para asegurar su llenado preciso.

4. Las formas deben ser atractivas.

El diseño de formas y pantallas útiles se traslapa en muchas formas importantes, pero hay algunas distinciones. Las pantallas despliegan un cursor que orienta continuamente al usuario. Las pantallas proporcionan frecuentemente asistencia con la entrada y, en cambio, aparte de las instrucciones preimpresas, puede ser difícil obtener ayuda adicional para una forma.

Los cuatro lineamientos para pantallas VDT bien diseñadas son:

1. Las pantallas deben ser mantenidas simples.

2. Las pantallas deben ser consistentes de pantalla a pantalla.

3. El diseño de pantalla debe facilitar el movimiento entre pantallas.

4. Las pantallas deben ser atractivas.

Muchos elementos de diseño diferentes permiten que el analista de sistemas satisfaga estos lineamientos. Es importante el flujo adecuado tanto en formas como en pantallas. Las formas deben agrupar lógicamente la información en siete categorías y las pantallas deben ser divididas en tres secciones principales. Los títulos en formas y pantallas pueden ser variados, tal como lo permita los tipos de letra y grosores de línea que dividan las subcategorías de información, Las formas de varias copias son otra manera de asegurar que las formas satisfacen su propósito pretendido. Los diseñadores pueden usar ventanas, preguntas, cuadros de diálogo y valores por omisión en pantalla para asegurar la efectividad del diseño. Hay muchas similitudes, pero algunas diferencias críticas, entre el diseño de pantallas para sistemas de macrocomputadora y de microcomputadora. Para aumentar la eficiencia, las pantallas de macrocomputadora son enviadas como un todo, en vez de como series de tecleos individuales.

Los campos de datos en una pantalla de macrocomputadora son definidos usando un carácter de atributo de campo que controla las cualidades de protección, intensidad, desplazamiento y atributos extendidos. El carácter de atributo debe ser tomado en cuenta cuando se diseñan pantallas para terminales de macrocomputadora.

17. DISEÑO DEL ARCHIVO O BASE DE DATOS.

Cómo guardar datos es frecuentemente una decisión importante en el diseño de un sistema de información. Hay dos enfoques para el almacenamiento de datos. El primer enfoque es guardar los datos en archivos individuales y un archivo para cada aplicación. El segundo enfoque es desarrollar una base de datos que pueda ser compartida por muchos usuarios para una variedad de aplicaciones conforme se necesita. Se han realizado mejoras dramáticas en el diseño de software de base de datos para aprovechar la interfaz gráfica de usuario.

El enfoque de archivo convencional puede ser, a veces, un enfoque más eficiente, debido a que el archivo puede ser específico de la aplicación. Por otro lado, el enfoque de base de datos puede ser más adecuado debido a que los mismos datos necesitan ser capturados, almacenados y actualizados una sola vez. Para comprender el almacenamiento de datos es necesario tener un conocimiento de tres reinos: la realidad, los datos y los metadatos. Una entidad es cualquier objeto o evento del que deseamos recolectar y almacenar datos. Los atributos son las características actuales de esas entidades. Los conceptos de datos pueden tener valores y pueden ser organizados en registros que pueden ser accesados por medio de una llave. Los metadatos describen a los datos y pueden contener restricciones acerca del valor de un concepto de datos (tal como que sea solamente numérico). Ejemplos de archivos convencionales incluyen archivos maestros, archivos de tabla, archivos de transacción, archivos de trabajo y archivos de reporte. Pueden tener organización secuencias, listas encadenadas, organización de archivo de dispersión,

organización indexada u organización secuencias indexadas. Una forma más moderna y eficiente para manejar archivos secuenciales indexados es el VSAM. Las bases de datos pueden tener estructura jerárquica, de red o relacionar. La normalización es el proceso que toma las vistas de usuario y las transforma en estructuras menos complejas, llamadas relaciones normalizadas.

Hay tres pasos en el proceso de normalización. Primero son eliminados todos los grupos repetidos. Segundo, son eliminadas todas las dependencias parciales. Por último, son quitadas las dependencias transitivas. Después de estos tres pasos, el resultado es la creación de muchas relaciones que están en la tercera forma normal (3NF). Se puede usar el diagrama entidad-relación para determinar las llaves requeridas para un registro o relación de base de datos. Los tres lineamientos a seguir cuando se diseñan archivos maestros o relaciones de bases de datos son:

(1) cada entidad de datos separada debe crear un archivo maestro. No combine dos entidades distintas en un solo archivo.

(2) Un campo de dato específico debe existir solamente en un archivo maestro y

(3) cada archivo maestro o relación de base de datos debe tener programas para crear, leer, actualizar y borrar.

El proceso de recuperación de datos puede involucrar hasta ocho pasos:

(1) la relación o relaciones se seleccionan y

(2) se unen;

(3) se realizan la proyección y

(4) selección sobre la relación para extraer los renglones y columnas relevantes.

(5) Se pueden derivar nuevos atributos,

(6) los renglones son ordenados o indexados,

(7) se calculan totales y medidas de desempeño y, por último,

(8) se presentan los resultados al usuario.

18. DISEÑO DE LA INTERFAZ DE USUARIO.

En este capítulo se ha enfocado en los usuarios del sistema, su interfaz con la computadora, su necesidad de retroalimentación y el diseño de su estación de trabajo. El éxito del sistema que se diseñe depende del involucramiento y aceptación del usuario. Por lo tanto, el pensar acerca de los usuarios en formas sistemáticas y empáticas es de gran importancia y no un asunto periférico para los analistas de sistemas. En este capítulo se trata varios tipos de interfaz de usuario y dispositivos de entrada. Algunas interfaces están particularmente bien adaptadas para los usuarios sin

experiencia, tales como: lenguaje natural, pregunta y respuesta, menús, llenado de forma, interfaz gráfica de usuario, el ratón, plumas ópticas y pantallas sensibles al tacto.

El lenguaje de comandos está mejor adecuado para los usuarios experimentados. La combinación de interfaces puede ser extremadamente efectiva. Por ejemplo, el uso de menús desplegables con interfaces gráficas de usuario, o el empleo de menús anidados dentro de interfaces de preguntas y respuestas, produce combinaciones interesantes. Cada interfaz plantea un nivel diferente de reto para los programadores, siendo el lenguaje natural el más difícil de programar. La retroalimentación se usa de muchas formas. También se enfatiza la necesidad de retroalimentación a los usuarios por parte del sistema. Es necesaria la retroalimentación del sistema para hacer que los usuarios sepan si su entrada está siendo aceptada, si la entrada está o no en la forma correcta, si el procesamiento está avanzando, si las peticiones pueden ser o no procesadas y si se encuentra disponible información más detallada y cómo obtenerla. También puede ser efectiva la retroalimentación por audio.

Las consultas están diseñadas para permitir a los usuarios extraer datos significativos de la base de datos. Hay seis tipos básicos de consultas y pueden ser combinados usando lógica booleana para formar consultas más complejas. Por último, consideramos la manera en que los espacios de trabajo del usuario influencian su disponibilidad para el uso del sistema y cómo pueden ser mejoradas las estaciones de trabajo mediante la implementación de principios ergonómicos relevantes. Hay lineamientos de productividad y confort específicos para la construcción y posicionamiento de las VDT, teclados, soportes de computadora y asientos para usuario, pero por lo general todos ellos deben ser lo suficientemente flexibles para permitir el ajuste para uso individual.

19. DISEÑO DE PROCEDIMIENTO PARA LA CAPTURA DE DATOS PRECISA.

El aseguramiento de la calidad de los datos de entrada al sistema de información es crítico para asegurar la calidad de la salida. La calidad de los datos alimentados puede ser mejorada por medio del logro de tres principales objetivos de la captura de datos: codificación efectiva, captura de datos efectiva y eficiente y validación de los datos. Una de las mejores formas para agilizar la captura de datos es mediante el uso efectivo de la codificación, que pone los datos en secuencias cortas de dígitos y/o letras. Se pueden usar códigos de secuencia simple Y códigos de derivación alfabética para seguir el avance de un concepto dado a través del sistema. Los códigos de clasificación y los códigos de secuencia en bloque son útiles para distinguir clases de artículos entre ellas. Los códigos, tales como el código de cifrado, también son útiles para ocultar información que es sensible o está restringida a determinadas personas dentro del negocio. La revelación de información es también un uso de códigos que vale la pena, debido a que permite que los empleados del negocio localicen conceptos en existencia y también puede hacer que la captura de datos sea más significativa.

Los códigos de subconjuntos de dígito significativo usan subgrupos de dígitos para describir un producto. Los códigos mnemónicos también revelan información, sirviendo como ayudas de

memoria para que ayuden al operador de captura de datos a teclear los datos correctamente o ayuden al usuario final para el uso de la información. Los códigos que son útiles para informar a las computadoras o a las personas acerca de qué funciones hay que realizar o qué acciones efectuar son llamados códigos de función, y evitan el tener que decir a detalle qué acciones son necesarias. Otra parte para asegurar la captura de datos efectiva es la atención a los dispositivos de entrada que se usan. El primer paso es una forma efectiva y bien diseñada que sirva como documento fuente (cuando se necesita), Los datos pueden ser alimentados por medio de muchos métodos diferentes, teniendo cada uno diferente velocidad y confiabilidad. Las mejoras en eficiencia sobre el teclado a cinta han sido realizadas por medio de la interacción de los sistemas teclado a disco y teclado a disco flexible. El reconocimiento óptico de caracteres (OCR) permite la lectura de datos de entrada por medio del uso de software especial que elimina algunos pasos y también requiere menos habilidades de los empleados. Otros métodos de captura de datos incluyen el reconocimiento de caracteres de tinta magnética usado por los bancos para codificar los números de cuenta de los clientes, las formas de marcas sensibles usadas para alimentación de gran cantidad de datos y las formas perforadas usadas en votaciones. Los códigos de barras (aplicados a productos y luego digitalizados) también agilizan la captura de datos y mejoran la precisión y confiabilidad de los datos. También están siendo desarrolladas nuevas tecnologías de entrada, tales como las cámaras digitales. Las terminales inteligentes son dispositivos de entrada (frecuentemente basadas en microprocesador) con una VDT, teclado y enlace de comunicación con la CPIJ. Permiten que se tecleen y completen transacciones en tiempo real. Junto con una codificación adecuada, captura de datos y dispositivos de entrada, la captura de datos precisa puede ser mejorada mediante el uso de la validación de la entrada. El analista de sistemas debe suponer que sucederán errores en los datos, y debe trabajar con los usuarios para diseñar pruebas de validación de entrada para prevenir que sean procesados y almacenados datos erróneos.

Las transacciones de entrada deben ser revisadas para asegurar que la transacción solicitada es aceptable, autorizada y correcta. Los datos de entrada pueden ser validados por medio de la inclusión en el software de varios tipos de pruebas que revisen datos faltantes, la longitud de concepto de datos, el rango y la razonabilidad de los datos y valores inválidos de los datos. Los datos de entrada también pueden ser comparados con datos almacenados para efectos de validación. Una vez que los datos numéricos son alimentados, pueden ser revisados y corregidos automáticamente mediante el uso de dígitos de verificación.

20. ASEGURAMIENTO DE LA CALIDAD POR MEDIO DE LA INGENIERÍA DE SOFTWARE.

El analista de sistemas usa tres amplios enfoques para la administración de calidad total (TQM) para analizar y diseñar sistemas de información: diseño de sistemas y software con un enfoque modular de arriba hacia abajo, diseño y documentación de sistemas y software usando métodos sistemáticos, y pruebas de sistemas y software para que puedan ser fácilmente mantenidos y auditados. Los usuarios son de importancia crítica para el establecimiento y evaluación de la calidad de varias dimensiones de los sistemas de manejo de información y los sistemas de apoyo a decisiones. Pueden estar involucrados en la evolución completa de los sistemas mediante el establecimiento de fuerzas de tarea MIS o círculos de calidad.

La TQM puede ser implementada satisfactoriamente tomando un enfoque de arriba hacia abajo para el diseño. Esto se refiere a ver primero los objetivos organizacionales generales y luego descomponiéndolos en requerimientos de subsistemas manejables. El desarrollo modular hace que la programación, depuración y mantenimiento sean más fáciles de lograr. La programación en módulos está muy bien adecuada para tomar un enfoque de arriba hacia abajo. Dos sistemas que enlazan programas en el ambiente Windows son el DDE (Intercambio dinámico de datos) que comparte código utilizando archivos de biblioteca de enlace dinámico (DLL). Mediante el uso del DDE un usuario puede almacenar datos en un programa y luego usarlos en otro. Un segundo enfoque para el enlace de programas en Windows es llamado OLE (vinculación e inclusión de objetos). Este método de enlace es superior al DDE para enlazar datos y gráficos de aplicaciones, debido a su enfoque orientado a objetos.

Una herramienta recomendada para el diseño de un sistema modular de arriba hacia abajo es llamada una gráfica de estructura. Se usan dos tipos de flechas para indicar los tipos de parámetros que son pasados entre los módulos. El primero es llamado un acople de datos y el segundo es llamado una bandera de control. Los módulos de las gráficas de estructuras caen en una de tres categorías: control, transformacional (a veces llamada trabajador) y funcional o especializado.

Parte de la administración de calidad total es ver que los programas y sistemas estén diseñados, documentados y mantenidos adecuadamente. Seis de las muchas técnicas de documentación y diseño que pueden ayudar al analista de sistemas son HIPO, diagramas de flujo, gráficas Nassi-Shneiderman, diagramas Warnier-Orr, seudocódigo, manuales de procedimiento y FOLKLORE. Los diagramas de flujo de datos pueden usarse para crear diagramas HIPO. El seudocódigo es usado para paseos estructurados cuando no hay suficiente tiempo para crear diagramas HIPO formales.

Los analistas de sistemas deben escoger una técnica que se ajuste bien con lo que fue usado anteriormente en la organización y que permita flexibilidad y facilidad de modificación. La generación de código es el proceso de usar software para crear todo o parte de un programa de computadora. Muchos generadores de código están disponibles ahora comercialmente. La reingeniería y la ingeniería inversa se refieren al uso de software para analizar código de programas existentes y crear elementos de diseño CASE a partir del código. El diseño CASE puede ser luego modificado y usado para generar nuevo código de programa de computadora. La prueba de programas específicos, subsistemas y sistemas completos es esencial para la calidad. La prueba se realiza para hacer que aparezca cualquier problema que exista en los programas y sus interfaces antes de que el sistema sea, de hecho, usado. Típicamente la prueba se realiza en una forma de abajo hacia arriba, siendo revisado el código de programa primero en escritorio. Siguiendo varios pasos de prueba intermedia se llega a la prueba del sistema completo con datos reales (datos reales que han sido procesados satisfactoriamente con el sistema antiguo). Esto proporciona una oportunidad para eliminar cualquier problema que se presente antes de que el sistema sea puesto en producción. El mantenimiento del sistema es una consideración importante. El software bien diseñado puede ayudar a reducir los costos de mantenimiento. Los analistas de sistemas necesitan establecer canales para la retroalimentación de los usuarios sobre

las necesidades de mantenimiento, debido a que los sistemas que no son mantenidos caerán en desuso. Se consultan auditores, tanto internos como externos, para determinar la confiabilidad de la información del sistema. Ellos comunican sus hallazgos de auditoria a otros para mejorar la utilidad de la información del sistema.

21. IMPLEMENTACIÓN SATISFACTORIA EN EL SISTEMA DE INFORMACIÓN.

La implementación es el proceso de asegurar que el sistema de información y/o el centro de información es operacional y luego involucrar a usuarios bien capacitados en su operación. En proyectos de sistemas grandes, el papel principal del analista es supervisar la implementación, estimando correctamente el tiempo necesario y luego supervisando la instalación del equipo para los sistemas tradicionales, centros de información o procesamiento distribuido, la capacitación de usuarios y la conversión de archivos y bases de datos al nuevo sistema. Un centro de información implementado dentro de un negocio, como parte de un departamento de sistemas más grande, es una forma para hacer más fácil a los usuarios satisfacer sus necesidades de información a corto plazo. Por medio del centro de información los usuarios aprenden a resolver sus propios problemas de negocios inmediatos con el hardware y software de computadora disponible y la ayuda experta de los especialistas del centro. Tanto los usuarios como el personal del centro de información deben hacer propia la idea de que el centro de información es una empresa que vale la pena y estar dispuestos a desempeñar los nuevos papeles requeridos en el centro. Es posible comenzar un centro de información con un gerente y dos o tres personas técnicas (siendo uno o todos ellos analistas de sistemas). Los empleados del centro deben ser competentes técnicamente, pero también deben sentir agradable el interactuar con los usuarios en un papel de soporte. Los usuarios deben aceptar la responsabilidad de los recursos que están usando, querer aprender y ser capaces de formular sus problemas con base en su propio conocimiento de fondo del negocio. Los sistemas distribuidos aprovechan la tecnología de telecomunicaciones y la administración de bases de datos para una de las formas más populares para enfocar los sistemas distribuidos es mediante el uso de un modelo cliente/servidor. Los tipos estándar de redes organizacionales incluyen la red de área local (LAN) y la red de área amplia (WAN). Mediante el uso de un enfoque de arriba hacia abajo, los analistas pueden usar seis símbolos para ayudarse a trazar los diagramas de descomposición de la red y conectividad de núcleos. Un nuevo software, llamado groupware, está llegando a ser más funcional y más ampliamente distribuido. Su objetivo es ayudar a los miembros de grupos a trabajar juntos por medio de redes.

La capacitación de usuarios y de personal para interactuar con el sistema de información y/o el centro de información es una parte importante de la implementación, debido a que ellos deben ser capaces de ejecutar el sistema sin intervención del analista. El analista necesita considerar quiénes necesitan ser capacitados, quién los capacitará, los objetivos de la capacitación, los métodos de instrucción a ser usados, lugares y materiales.

La conversión también es parte del proceso de implementación. El analista tiene varias estrategias para cambiar del sistema de información antiguo al nuevo. Las cinco estrategias de conversión incluyen cambio directo, conversión en paralelo, conversión por fases, conversión de prototipos

modulares y conversión distribuida. El tomar un enfoque de contingencia entre las estrategias de conversión puede ayudar al analista a seleccionar una estrategia adecuada que se ajuste a sistemas diferentes y a variables organizacionales. Una investigación exploratoria reciente sugiere que el analista de sistemas puede mejorar las oportunidades de que sea aceptado un sistema recientemente implementado si desarrolla el sistema con las metáforas organizacionales predominantes en mente. Nueve metáforas principales en uso son: familia, sociedad, máquina, organismo, viaje, juego, guerra, selva y zoológico. Por ejemplo, es más probable que los MIS tradicionales tengan éxito cuando se usan metáforas tales como la familia, sociedad o máquina, y es menos probable que tengan éxito con metáforas organizacionales tales como guerra y selva. Después de la implementación debe ser evaluado el nuevo sistema o centro de información. Se dispone de muchos enfoques de evaluación diferentes, incluyendo análisis de costo-beneficio, el enfoque de evaluación revisado y las evaluaciones de involucramiento de usuario. El marco de trabajo de utilidad del sistema de información es una forma directa para evaluar un nuevo sistema con base en las seis utilidades de posesión, forma, lugar, tiempo, actualización y objetivo. Estas utilidades corresponden y responden a las preguntas de quién, qué, dónde, cuándo, cómo y por qué para evaluar las utilidades del sistema de información o de un centro de información recientemente creado. Las utilidades también pueden servir como una lista de verificación para sistemas en desarrollo.

En el estudio de caso, a veces llamado monografía, estudiamos sólo un acontecimiento, proceso, persona, unidad de la organización u objeto. Tal acercamiento no se parecería promover la blanco general de la investigación - para desenterrar conocimiento generalmente válido - pero puede ser motivado por varias razones, típicamente las siguientes:

A. El caso es singular: solamente un tal caso existe, y es importante y digno de estudiar. Típicos tales objetos o fenómenos son acontecimientos históricos trascendentales, hombres y mujeres prominentes, estadistas, grandes pensadores y artistas, organizaciones políticas y religiosas, obras de arte o ingeniería renombradas. El propósito es a menudo documentar el caso antes de que la información sobre ella consiga perdida.

B. El caso es complicado, típicamente una persona y su actividad, y debe estudiarla a fondo.C. El caso pertenece a una clase de casos prácticamente idénticos, por ejemplo un producto

industrial de un tipo y modelo dado. Sería inútil estudiar más de un caso, porque todos los resultados de él pueden ser generalizados.

D. Usted quisiera a veces estudiar una clase de casos, pero solamente un caso está disponible para el estudio. Esto puede suceder en en estudio arqueológico, cuando solamente un caso de muchos ha sobrevivido a nuestro día. Semejantemente, muchos mecanismos internos del cerebro se han descubierto de los casos únicos donde el cerebro de un paciente se ha dañado en un accidente.

Entre las alternativas mencionadas, solamente C y D pueden producir conocimiento generalmente válido. Tipos A y B apuntan al describir un caso, y no busca conocimiento

universalmente válido. Sin embargo, es siempre posible que algunos resultados de un estudio de caso puedan también posteriormente ser aplicables a otros casos que no se han estudiado, aunque esto es generalmente difícil o imposible determinar en el marco de un solo estudio de caso. De todas formas, cualquiera que lee el informe de un estudio de caso puede entonces evaluar cuál conclusiones él puede aplicar quizás a sus propios problemas (la figura en la derecha). Los procesos lógicos del estudio y de la aplicación eventual tienen así alguna semejanza a crear y a gozar una obra de arte, como se discute en la página Arte como análisis.

¿Qué clase de conocimiento que usted puede esperar de encontrar con un estudio de caso? En el diagrama arriba, los resultados se caracterizan como "descripción", pero también otros tipos de conocimiento se pueden obtener con estudios de caso. Blancos usuales en los estudios de caso son:

1. Describir el objeto o fenómeno - no solamente su aspecto externo pero también su estructura interna, y quizás también su desarrollo anterior.

2. Explicar las razones porque es el objeto como es, o su desarrollo anterior.3. Predecir el futuro del objeto.4. Planear las mejoras al objeto o a otros objetos similares, o reunir opiniones sobre él, es

decir un acercamiento normativo.

Las blancos antedichas y sus métodos respectivos serán discutidos debajo, excepto el acercamiento normativo, los métodos de el cual diferencian radicalmente del resto. Por lo tanto se discute en las páginas separadas: Punto de vista normativo, Estudio de caso normativo y otra parte.

Estudio descriptivo de caso

Al planear un estudio empírico es generalmente recomendable basar el trabajo sobre un modelo teórico existente, porque un modelo, incluso preliminar, puede a menudo mucho ayudar al trabajo. El estudio exploratorio, en otras palabras no basar el estudio en cualquier modelo o teoría anterior, es generalmente laborioso, lento e incierto, así que usted deseará generalmente evitar tal acercamiento si posible. El método normal es comenzar con una búsqueda cuidadosa de la literatura para encontrar modelos teóricos usables.

Por otra parte, puede haber razones de no basar el estudio en cualquier modelo o teoría anterior, por ejemplo:

El objetivo es documentar el objeto de forma tan completa como sea posible, y no sólo aquellos temas que fueron documentados en estudios anteriores. Llega a ser necesario cuando un objeto cultural valioso está en peligro de ser perdido en futuro. La puntería de la documentación no es tanto analizar el objeto pero simplemente recolectar tantos hechos de ello como posible

Búsqueda fenomenológica de una comprensión profunda y desconfianza en las anteriores descripciones y explicaciones que podían quizás impedir que el investigador vea la esencia y la particularidad del caso en la pregunta. Porque su blanco no es tanto describir un caso

pero definir la esencia típica en una clase de casos, su método se discute en la página Indicar lo típico, párrafo Análisis fenomenológico.

El objeto de estudio difiere de todos objetos anteriores y el objetivo del estudio está describir su carácter excepcional. Traer ideas de teorías anteriores podía embrollar esta descripción.

Escoger un acercamiento exploratorio, es decir con ninguna base teórica, para un estudio de caso descriptivo puede así ser una decisión deliberada, o una necesidad porque no hay teoría conveniente o modelo disponible. De todas formas, la investigación exploratoria significa que al principio del proyecto muy poco se sabe sobre la materia. Usted entonces tiene que comenzar con una impresión algo vaga de lo que se debe estudiar, y es también imposible hacer un plan detallado de trabajo por adelantado, ni comenzar definiendo los conceptos del estudio. Durante el proyecto de investigación exploratoria estos conceptos incipientes mejorarán gradualmente.

En ausencia de los modelos probados y los conceptos definidos usted debe comenzar el estudio exploratorio de lo que usted tiene: el objeto del estudio. Es común que en el principio del estudio exploratorio usted tomará una mira holistica del objeto, reuniendo tanta información sobre los objetos como sea posible. Usted no quiere restringir su estudio a apenas unas pocas características del objeto, antes usted sabe que cuál preguntas son importantes. Usted así pospone la tarea de eliminar datos innecesarios hasta que se consigue un retrato mejor sobre cuál es necesario.

Cualquier objeto se puede mirar de varios diversos puntos de vista, o como perteneciendo a diversos contextos. Puede a menudo ser una buena idea comenzar el estudio alternando el punto de vista, como en el diagrama a la derecha.

Después de que usted haya pasado unos días en la experimentación con varias vistas al objeto, usted podrá probablemente especificar la posiciòn final para su estudio y explicar cómo usted entiende o "toma" el objeto. Esto no significa que tengamos que empezar nuestro trabajo por clarificar la esencia de nuestro objeto de estudio, es decir: lo que el objeto es realmente. En lugar de eso, debemos intentar contemplar y clarificar cómo vemos el objeto, ya sea posible por ejemplo que sea definido en un micronivel como resultado de instintos individuales, móviles y experiencias, o quizás en un macronivel como una expresión de las ideologías y presiones en sociedad.

El progreso de un proyecto de estudio se hace más fácil en cuanto hemos definido nuestro punto de vista y problema. Tras esto, vamos a necesitar reunir sólo aquel conocimiento empírico relacionado con el problema; esto nos permitirá minimizar el material que tendremos que analizar. Esto no significa que usted debe desatender todos los casos que no

quepan en sus conjeturas - a veces las anomalías o los casos que sorprenden pueden señalar una vía a las enmiendas o correcciones importantes a la teoría existente.

Tan pronto como una estructura o invariante interesante en el objeto se hace patente usted puede omitir toda la materia que no se relaciona con esta estructura, y comprimir la información restante, relevante.

Raramente será posible dividir el estudio cualitativo en fases tan claras como las que son comunes en el trabajo cuantitativo. De acuerdo con Alasuutari (p.22), en un análisis de datos empíricos, se podrían distinguir dos fases, pero éstas se solapan. Estas fases serían:

simplificación de observaciones interpretación de resultados (o "resolver el enigma")

En la fase de simplificación, el material es inspeccionado desde el punto de vista teórico del proyecto de estudio, y sólo los puntos pertinentes desde este ángulo se toman en cuenta. Los detalles no relevantes se omiten o se ponen de lado de forma que la estructura importante se puede discernir más fácilmente. Las estructuras más interesantes son a menudo las que se pueden esperar ser comunes en todos casos comparables - este aspecto se discute en la página Indicar lo típico.

"Resolver el enigma" no siempre significa contestar exactamente a aquellas preguntas que fueron formuladas en el comienzo del proyecto. A veces las preguntas más interesantes se encuentran al final de la investigación, cuando el investigador es un experto en el tema.

Describir un caso en base de la teoría. Hoy en día, casi todos temas del mundo han sido ya estudiados por uno o más campos especiales de la investigación. En consecuencia, casi toda pregunta u objeto concebible se puede ahora investigar a la luz de teoría previa.

En campos de la investigación establecidos usted puede seleccionar a menudo su problema de modo que usted pueda manejarlo como caso especial o como extensión de la teoría existente en este campo, creado por investigadores anteriores. Tal práctica facilita el comienzo de un nuevo estudio, y es corriente en estudios académicos.

Además, usted puede acercar a menudo al problema de modo que usted combine las vistas de dos o más campos de ciencia, que puede revelar nuevos aspectos interesantes al asunto, de la misma forma que un estudio hermeneutico de la literatura.

Usar vistas paralelos a un solo objeto es lógico y fácil organizar en el caso que varios investigadores cooperan en el proyecto. Cada investigador puede entonces mirar el objeto desde el punto de vista de su maestría especial, y las visiónes que resultan entonces son ensambladas juntas por discusiones en el equipo.

Un investigador exploratorio que trabaja solo puede en lugar utiliza el método de alternar el punto de vista. Esto significa que se estudia el objeto sucesivamente desde varios puntos de vista, cada uno de los cuales se basando en una teoría existente hecha por investigadores anteriores (véase la figura de la derecha). Cada punto de vista añade algo al cuadro general.

Estudio de caso explicativo

El investigador desea a menudo continuar el proyecto a un nivel más profundo que apenas la descripción: él desea saber por qué el objeto es tal como está. Este conocimiento ayuda a resumir todo que es sabido acerca del objeto, ayuda a verlo en su contexto y en una perspectiva histórica.

Encontrar las razones, o explicar el fenómeno, se puede hacer en varias maneras. Las razones se pueden traer del contexto simultáneo del fenómeno, a partir del pasado, o alternativamente a partir del futuro. En el siguiente están algunos ejemplos que son comunes en la investigación así como en vida diaria.

Explicación a partir del pasado. En las ciencias naturales las explicaciones para los acontecimientos tradicionalmente se buscan en el pasado: ¿cuáles son las razones que causaron el presente estado de cosas? Este tipo alternativo de explicación es llamado causal, por ejemplo: "El puente se derrumbó por causa del fuerte viento y porque el diseño era defectuoso".

Explicación contextual. Los biólogos a veces explican una actividad con la ayuda de la función que ella cumple en la vida del grupo o de la especie. Por ejemplo, un pájaro canta para indicar cuál es su territorio y mantener alejados a los rivales, para asegurar el alimento. Los productos de la cultura humana a menudo son explicados por el estado concurrente de la sociedad.

Explicación a partir del futuro es común cuando se están explicando los actos de la gente. Por ejemplo, "la Torre de Eiffel fue construida para servir como símbolo de la Exposición de París".

De estos tipos, la explicación contextual es popular al estudiar las actividades del hombre y de sus resultados, tales como productos industriales y obras de arte. Éstas se han estudiado de largo en muchas ciencias tales como sociología, antropología, economía y psicología, y es normal explotar teorías de estas ciencias cuando la meta del proyecto es encontrar una explicación al estado del objeto del estudio, la existencia de teorías anteriores facilita y acelera el procedimiento de la investigación de la misma forma que se hace en estudio descriptivo, discutido en el párrafo precedente. Cuando una o más teorías para explicación están disponibles, el acercamiento lógico es probar cada uno de ellas y entonces elaborar la explicacion que se parece más plausible.

Quizás el más usual explicación contextual es el acercamiento sociológico: "Se debe mirar al diseñador como parte de la sociedad circundante, y examinar su trabajo y valores con respecto a condiciones sociales, culturales y económicas... Tenemos que entender cómo y porqué el diseño se ha desarrollado y que intereses que apoya" (Wiberg, 1992).

Asimismo, los productos industriales y las obras de arte se estudian y se explican a menudo en base de procesos sociales, económicos y ecológicos. Los factores explicativos son, por ejemplo, cambios en la demografía de la sociedad, en las condiciones de la industria o de la economía; por otra parte las consecuencias de invenciones, educación, cambios políticos, guerras y la adquisición o pérdida de colonias. Factores constantes pero regionalmente disímiles son clima, disponibilidad de materias primas y de energía, canales del transporte y las necesidades locales de la gente.

Por ejemplo, Päivi Hovi estudió cómo la pintura en anuncios se desarrolló en Finlandia de 1890 a 1930. Descubrió que para entender el desarrollo, se tiene que estudiar el objeto desde cuatro puntos de vista o contextos, que se ilustran en el diagrama de la derecha. Cada uno de estos contextos había sido el objeto de estudios anteriores y el conocimiento y la teoría acumulados daban acercamientos potenciales para el estudio del material empírico de Hovi. Aunque en sentido estricto éste no era ningún estudio de caso, porque los objetos eran realmente no objetos solos sino clases de ellos, el acercamiento se puede igualmente usar en un estudio de caso, también.

El acercamiento psicológico es usual en el estudio de artistas y de sus trabajos, también. Wilhelm Scherer (1841 - 86) fue el primero en presentar un modelo general para las biografías de artistas. El modelo explica el carácter especial de cada artistas por tres factores, que eran,

das Ererbte (los elementos heredados) das Erlebte (las experiencias) y das Erlernte (lo que el artista ha aprendido).

La explicación por acontecimientos anteriores hace obviamente falta de un estudio diacrónico, es decir necesita material de un período del tiempo más largo. La duración varía - acontecimientos físicas causalmente explicables se pasan a menudo en menos que un segundo, mientras que los efectos que varios alimentos y sus añadidos pueden causar al hombre pueden tardar muchos años antes de aparecer. En todo caso, ensanchar la duración del estudio amplía necesariamente la cantidad de material que se tiene que recolectar y analizar antes de que el estudio pueda ser acabado. Para prevenir el crecimiento excesivo, usted tiene que considerar demarcar la población del estudio más estrecho.

Al decidir que materia usted necesitará reunir, un punto de partida inestimable podría ser resultados anteriores acerca de cuál factores se han correlacionado en objetos comparables más temprano. En ausencia de tales teorías usted tiene que encontrar la explicación causal en el objeto él mismo. Esto requeriría recoger mucha materia, estudiarla en la perspectiva histórica, y notar los cambios que de vez en cuando han ocurrido en o alrededor del objeto.

Luego usted debe inspeccionar de cerca estos puntos de tiempo y los acontecimientos antes y después de ellos. Entre estos acontecimientos usted puede encontrar quizás las explicaciones plausibles para los cambios que han sucedido, y finalmente para el estado presente del objeto. Este acercamiento se discute también en Explicación del desarrollo.

Explicación a partir del futuro. Las intenciones de la gente pueden ser reunidas con entrevistas, o desde documentos tales como presupuestos, planes y propuestas de funcionarios, políticos, empresarios y artistas, al igual que desde las memorias de esta gente. Otras fuentes son conceptos del producto, especificaciones, propuestas y documentos de la evaluación.

Una dificultad al tratar de explicar el comportamiento de la gente de la base de sus intenciones anunciadas está que la conducta posterior de la gente no siempre correlaciona con las intenciones expresadas, debido a veces a obstáculos prácticos imprevistos encontrados en la fase de la realización, y a veces porque la intención anunciada no ha sido bastante realista u honesta. La problema se discute en una página separada: Evaluar la información.

Estudio de caso como base del pronóstico

Cuando el propósito de un estudio de caso es ayudar al pronosticar el futuro del objeto o del fenómeno, primero de todo hay que definir qué características del estado futuro de cosas están "interesando" y serán incluido en el pronóstico. Los datos recientes sobre éstos obviamente son de importancia primaria como base para el pronóstico.

Qué otro material se necesita para pronosticar, depende de cuál método de pronosticar que se piensa utilizar. Esto, en cambio, depende de cómo es fuerte un modelo teórico que usted tenga acerca del desarrollo futuro previsto y sus relaciones internas. Una base fuerte para pronosticar está un modelo que explica el fenómeno, enumerando sus razones y sus resultados, es decir definiendo la invariante dinámica del proceso que se predirá. Otros tipos menos confiables de modelo que se pueden utilizar en el pronóstico son correlaciones u otras asociaciones estadísticas entre variables, y los modelos o analogías prestados de otros contextos tales como una esfera distante de la cultura.

Un resumen de métodos de pronóstico posibles en base de un estudio de caso se da en la tabla que sigue:

Pronóstico sobre base débil o ninguna base teórica:

Pronóstico sobre base teórica fuerte:

Datos requeridos:

Datos sobre el desarrollo de las características "interesantes", a partir tan de largo de un período como sea posible.

Datos recientes sobre las características "interesantes".Además, datos recientes sobre las variables independientes supuestas, según teoría.

Métodos de pronóstico convenientes:

Extrapolación ; Aplicar una asociación estadística ; Método Delphi

Varios métodos son posibles. Especialmente confiables son: Aplicar un modelo causal y Determinar el límite.

De estudios de caso hacia teoría general

El conocimiento que un caso puede producir concierne el caso que fue estudiado, y al principio vista parece imposible aplicárlo a otros casos o a una clase de casos. Lógicamente parecería que para conseguir conocimiento sobre una clase se necesita un proyecto de investigación que toma como su objeto la clase entera, no sólo un caso de ella.

Otro procedimiento lógico para ganar conocimiento generalizable podría estar el combinar los resultados del estudio de varios casos u objetos que se asemejan. Si estos estudios de caso separados tienen conexiones entre ellos, tales como definiciones comunes de conceptos o estructuras de modelos, éstos facilitarán el trabajo de investigadores posteriores en encontrar invariantes que se repiten en los casos separados, y finalmente quizás se podría construir un modelo general de estas invariantes, o podemos por lo menos precisar un caso típico en la clase (Fig. de la derecha).

Sin embargo, el procedimiento más usual para avanzar desde estudios de caso distintos hasta conocimiento generalmente válido se basa probablemente en el hecho de que la mayoría de los investigadores de un caso en realidad tienen bastante de conocimiento de otros casos comparables ya cuando comienzan su estudio. Este conocimiento generalmente válido entonces impregna su estudio de caso en la forma de conceptos, modelos y variables que se relacionan con los otros casos en la clase. Todo esto significa que llega a ser más fácil para otros científicos - o laicos - generalizar las conclusiones de este estudio de caso, si ellos quieren tratarlo en su propio riesgo.

Hoy, cuando hay tanto informes de investigación acerca de todos campos concebibles del estudio, es cada vez más usual basar un nuevo estudio de caso en la hipótesis que el caso se comportará en acuerdo con una teoría ya existente. Si lo hace, el área de la validez de esta teoría agrandará, y en el caso

opuesto el investigador quizás puede modificar esta teoría anterior. En ambos casos los resultados del nuevo estudio pueden estar científicamente o prácticamente valiosos.

Otra ventaja de este acercamiento es que facilitará mucho el planear y el realizar de un estudio de caso, como se explica a otra parte (Investigación para mejorar un modelo).

Estudio de caso normativo se discute en otra página.

Lógica del análisis normativo

Acercamiento normativo intenta descubrir no sólo cómo están las cosas, pero sobre todo cómo ellas deben estar. Significa que será necesario definir también el punto de vista subjetivo que se utiliza, es decir la gente que debe evaluar las propuestas para mejorar el objeto de estudio.

Al definir cómo el estado presente de cosas se debe mejorar, la cadena lógica del razonamiento a menudo sigue cualquiera uno de las dos alternativas "A" y "B" en el esquema en el derecho. Su diferencia principal está en el punto de partida del proceso.

A. Cuando el punto de partida está el estado actual de cosas, el proceso del análisis consiste en una descripción objetiva de él y una evaluación subjetiva de los problemas existentes. Ambos a menudo se pueden hacer simultáneamente, véase Registro normativo. Finalmente, una propuesta se debe hacer acerca de cómo los problemas se podrían corregir. En este enfoque usted puede conservar las partes valiosas del estado presente de cosas y sustituir solamente esas partes que sean inutilizables. Está de uso frecuente en el desarrollo de una actividad de gente, y también en el desarrollo de un producto cuando un producto existente se puede tomar como punto de partida.

B. Sucede a menudo que el estado de cosas deseable existe ya en otra parte, por lo menos parcialmente, y su objetivo será hacerla verdad en su objeto local del estudio, replicando sus puntos fuertes en su propio objeto. Esto podría significar la modificación de su objeto original del estudio, o crear un nuevo objeto o proceso comparable pero mejor. En ambos casos es posible tomar este caso superior existente, el ejemplar, como punto de partida en el análisis normativo. Este método es usual al desarrollar un producto nuevo, donde los ejemplares se seleccionan a menudo entre los competidores más agudos de su producto existente. Al desarrollar un servicio u otra actividad existente, el ejemplar se podría tomar de una actividad hábilmente arreglada conocida en otra parte. En este acercamiento, el procedimiento lógico no diferencia mucho del alternativa "A" mencionado arriba. Es también posible tomar más de un exemplar como puntos de partida, y en este caso la blanco llega a ser el combinar sus mejores características.

C. Un punto de partida alternativo en análisis normativo podría ser una descripción del estado ideal de cosas. Se construye principalmente en base de las preferencias subjetivas

de los grupos de interés, generalmente considerando todas las restricciones prácticas sabidas que la propuesta tiene que encontrar. Se utiliza este acercamiento cuando no hay ningún existente modelo usable en el que usted podría basarse sus propuestas, o como un complemento a los acercamientos "A" y "B" ya mencionados. Un ejemplo está el método de la especificación en desarrollo de productos.

Estos dos o tres acercamientos se pueden también utilizar en paralelo para dar una base más confiable para la propuesta.

En todo caso, la etapa final del proceso normativo consiste generalmente en una alternación de preparar propuestas tentativas detalladas (a menudo por los diseñadores o los investigadores profesionales) y de evaluar estas propuestas, preferiblemente por gente desde los grupos de interés o por lo menos simulando sus puntos de vista.

Para el proceso entero del análisis normativo nadie todavía ha encontrado un modelo confiable y generalmente aplicable, pero uno o más de los procedimientos lógicos siguientes se utilizan a menudo en el proceso:

Analizar requisitos . Crear una propuesta con las técnicas de la innovación, del planeamiento y del diseño. Evaluar propuestas normativas (en una página separada).

Analizar requisitos

Cuando considerar la necesidad de mejorar un objeto del estudio, el acercamiento normal es definir esas características del objeto que necesiten una mejora, y quizás también enumerar esas otras características de él que deben ser mantenidos como están. Es decir, usted hace una lista o una especificación que contenga los requisitos que la propuesta final del proyecto debe resolver.

El procedimiento para crear una especificación depende de la información que está disponible como su punto de partida. Los enfoques usuales para esto incluyen el siguiente:

Agregar una dimensión normativa a un análisis descriptivo (tal como estudio de caso, comparación, clasificación etc.)

Combinación de ejemplares. Un ejemplar con mejoras. Especificación sobre base teórica.

Agregar una dimensión normativa a un análisis descriptivo

Un acercamiento para manejar las características de la propuesta futura es aplicar los métodos de análisis descriptivo (tales como estudio de caso, comparación, clasificación etc.) al objeto del estudio, y amplificar estos métodos agregando una dimensión normativa en el análisis. Algunos ejemplos se dan abajo.

Estudio de caso normativo. El estudio de caso es un enfoque usual en proyectos de investigación descriptivos, pero se puede amplificar fácilmente con un aspecto normativo con el fin de conseguir argumentos para mejoras posteriores en el objeto del estudio, sea una circunstancia, un producto, o una rutina existente del trabajo. Por ejemplo, mucha investigación se ha hecho para descubrir porqué se inclina la torre de Pisa, y cuál factores contribuyen al problema. Solamente después de tales estudios pueden los ingenieros comenzar a diseñar la mejora.

Los candidatos obvios a estudios de caso normativos son únicos productos costosos como casas, producciones del teatro o de la película y los programas de computadora que necesitan a veces ponerse al día o mejora durante su vida larga.

Probablemente el uso más común para un caso normativo es de dar un punto de partida para desarrollar una nueva versión de un producto o de un procedimiento existente. Este punto de partida está normalmente - después de estudios necesarios - definido como un ejemplar, ve abajo.

Estudio pedagógico del desarrollo. Muchas historias tradicionales han tenido una esencia normativa escondida aún cuando el autor intentó presentar su trabajo como "descripción pura" con los métodos del analizar el desarrollo. Organizaciones como la iglesia, el gobierno o la familia real han designado a los historiadores innumerables, y esta fijación ha dirigido la selección de hechos. Se esperaba que los historiadores describieran sobre todo esos acontecimientos que tenían alguna relación al patrón, acentuaron su importancia y preferiblemente sus hechos admirables y los males de sus opositores.

No hay divergencia absoluta entre los estudios descriptivos y normativos de la historia. Ya cuando el investigador selecciona los acontecimientos para ser registrado la selección será subjetiva y basada en sus preferencias. En el siglo 19 muchos investigadores de la historia desearon describir objetivo "cómo era", pero la opinión general es hoy que ningún investigador de la historia puede olvidarse enteramente sus valores, y el estudio de la historia puede nunca evitar todas las implicaciones normativas.

Por supuesto, los estudios históricos pueden asistir a mejorar cosas existentes, y si usted se prepone hacer esa clase de estudio él llega a ser más fácil si usted reconoce esta meta conscientemente. Esto significa en la práctica que usted ya en el principio debe definir cuál es el problema que usted espera aliviar con la ayuda de su estudio, o de cuál tipo de producto se mejorará. No hay sentido parlar de la 'mejora' sin definir cuyo punto de vista se utilizará. Todas estas cosas se deben definir desde posible durante el estudio, para evitar recolectar material inaplicable y hacer análisis innecesarios.

Una vez que el investigador ha descubierto las estructuras inherentes o "invariantes dinámicas" de una evolución histórica, estos también pueden ser usados para predecir el

desarrollo futuro del objeto de estudio. Por otro lado, una vez que se han clarificado las razones de una evolución pasada, éstas pueden ser usadas también para cambiar la dirección de futuros progresos.

Comparación normativa. La diferencia entre los estilos descriptivos y normativos de la comparación es que en el análisis normativo uno de los criterios principales son evaluativo como la "satisfacción", la "utilidad" etc., y la puntería del estudio es precisar el mejor (en este respecto) entre las alternativas que se estudian. A veces la puntería final quizás sea encontrar no sólo el mejor objeto existente, sino también mejorar los objetos similares más tarde. Es decir se espera que el análisis comparativo diera argumentos para el planeamiento de mejoras en circunstancias o productos existentes.

A veces usted puede hacer uso las fuentes ya existentes de evaluaciones, como el sistema de respuesta de los clientes, si la compañía lo tiene, o la crítica pública que algunas instituciones, asociaciones y revistas generan y publican habitualmente.

Ejemplos modernos de comparaciones normativas son las pruebas de los productos nuevos que los diarios de consumidor publican a menudo. En estas pruebas un número de productos se juzgan según una lista estándar de preguntas, como en el ejemplo a la derecha. La lista necesita incluir solamente esos aspectos donde diferencian los productos que rivalizan.

La tabla de la comparación trabaja bien incluso en el caso que algunos de los criterios están expresados como variables numéricas y otras como descripciones verbales cualitativas. Nada previene incluyendo las presentaciones aún pictóricas de los objetos. Sin embargo, en la fase final usted tiene que traducir todas estas descripciones a tal formato que usted puede sumarlas para indicar el producto óptimo.

Además, usted tiene que observar que todos los criterios en la lista son quizás no igualmente importantes. Por lo tanto usted necesitará definir el peso de cado criterio cuando sumarlos.

Una clasificación normativa se puede construir semejantemente de casi cualquier tabulación cruzada descriptiva agregando una dimensión que exprese una evaluación.

Las comparaciones y las clasificaciones normativas son eficaces en precisar los casos que convienen con los criterios del proyecto normativo - o por lo menos con algunos de los criterios. Estos casos se pueden entonces utilizar como ejemplares, es decir como puntos de partida en desarrollar la propuesta normativa final del proyecto. Métodos para esto son Combinación de ejemplares y Ejemplar con mejoras.

Modelo de coche: A B

Número de asientos 5 8

Número de puertas 2 4

Bolsas aéreas 2 4

Consumición de combustible 5,8 6,5

Méritos especiales (Evaluación cualitativa)

Precio 8500 9900

Combinación de ejemplares

Ejemplares son procedimientos existentes, líneas de acción, artefactos o sus detalles, en los cuales por lo menos algunas características son meritorias, miradas desde el punto de vista del actual proyecto normativo. Pueden incluir también algunas características que no sean completamente aceptables.

El propósito normativo o educativo se parece haber penetrado ya los primeros estudios de caso que se hicieron en la antigüedad. Explicaron los méritos de estadistas respetados, o de trabajos admirados de la arquitectura, más adelante también las vidas de santos y de los artistas estimados. El propósito era obviamente presentar éstos a la generación siguiente como ejemplos meritorios, o evitables a veces. Todavía hoy este acercamiento se utiliza a menudo en varios artes donde los críticos reputados seleccionan ejemplares que después se publican en exposiciones y diarios profesionales y se esperan para dirigir la obra en el campo más adelante. Se utilizan como un substituto o complemento de la teoría en artes y profesiones de diseño artístico para los asuntos sobre que es difícil desarrollar doctrinas más explícitas, y aún para tales asuntos donde el conocimiento existe solamente en la forma tácita, que es a menudo el caso en cuestiones de la belleza y del gusto.

Ejemplares pueden proporcionar útiles puntos de la referencia en un proyecto de diseño, particularmente en la fase temprana de preparar un concepto detallado del producto, cuando es difícil descubrir otros patrones para describir el producto futuro. Un producto nuevo se puede definir o escogiendo un ejemplar y enumerando las mejoras necesarias a él, o alternativamente dando un conjunto de ejemplares e indicando sus ventajas, una combinación de las cuales se debe transportar al producto nuevo. Ambos estos métodos se explican en Modelos lógicos para presentar un concepto del producto.

En el método del conjunto de ejemplares usted escoge dos o más ejemplares entre los mejores modelos ahora existentes del tipo de producto que usted trata de crear. Nadie de estos ejemplares será perfecto en todos los respectos, pero cada uno de ellos posee algo que es excelente, y es estas características que el equipo de diseño entonces tratará de combinar en el producto nuevo. Si esto se puede lograr, el producto nuevo será más competitivo que cualquier de los ejemplares, aún en el caso que ninguna de sus características en sí mismo supera los ejemplares.

Cuando la selección de ejemplar depende de registros de ventas, el método tiene la ventaja de reflejar verazmente las opiniones de los clientes. Un método alternativo más arduo para recoger las opiniones de los usuarios potenciales del producto sería un cuestionario, por ejemplo.

Los ejemplares se pueden seleccionar de la producción de su propia firma, pero es también posible tomar un o más de ellos de sus competidores, es decir, son los productos que su producto nuevo reemplazará en el mercado si todo va bien. Cuando el ejemplar se selecciona entre las compañías y los productos más acertados del mercado, él puede también ser utilizado para "benchmarking": define un nivel óptimo de la operación que se sabe y que se pueda tomar como blanco para las compañías menos acertadas.

Trabajar con un conjunto de ejemplares es fácil y sin recovecos; no hay grandes riesgos de malentendidos. Su debilidad es que no invita a buscar nuevas alternativas que se aparten de las tradiciones viejas y probadas. Es difícil generar nada realmente nuevo cuál podría revolucionar el mercado. Su producto nuevo contendrá solamente tales calidades que sus competidores tengan ya en sus productos, si usted o su firma no puede agregar algo de su propio invención.

Ejemplares son también muy utilizados en la educación de la economía del negocio. Muchas universidades poseen colecciones grandes de informes de caso de las compañías que trabajan en la vecindad. Un caso educativo describe típicamente la historia, la organización, el ambiente, los productos claves, el sistema de la gerencia y quizás algunos problemas de la gerencia típicos que los estudiantes entonces pueden solucionar.

La medicina es otro campo de la educación donde están esenciales los ejemplares. Aquí describen las operaciones clínicas que han curado una enfermedad con éxito.

Un ejemplar con mejoras

Definir las mejoras refiriendo a productos o actividades existentes es un método antiguo. En su momento incluso fue posible el ahorrarse el diseño del ejemplo: éste normalmente era la tradición. El método puede seguir usándose con tal de que localicemos un ejemplo que no precise de demasiados cambios para ello. Es conveniente si los productos o actividades de su firma son relativamente constantes e requieren solamente mejoras anuales de menor importancia. En tal caso, usted querrá normalmente escoger la actividad o el modelo existente de su producto como el punto de partida, o ejemplar. Otra posibilidad es seleccionar un producto de competición que usted desea sobrepasar.

Cuál propiedades entonces requieren mejoras, y cuánto, eso es una pregunta contestó quizás ya en los archivos de respuesta de los clientes de su compañía. De otro modo, usted tendrá que hacer un estudio de mercado con varios métodos interrogativos entre clientes potenciales, o entre los vendedores de su compañía.

Las ventajas del método de ejemplar-y-mejoras son que es sencillo de usar, concreto y realista. Los malentendidos no son probables. Del punto de vista del diseñador un ejemplar es un punto conveniente de partir, porque es a menudo relativamente fácil continuar mejorándolo por el método de iteración. Tiene también la ventaja que necesita las modificaciones sólo mínimas a la línea de producción.

Una desventaja es quizás que es demasiado fácil de indicar detalles que pudieron necesitar la mejora, sin entender cómo todos los componentes de la propuesta acabada dependen de uno al otro (por ejemplo, los costes a menudo se levantan demasiado cuando se mejora la calidad). Un uso demasiado optimista de este método en la fase de concepto de producto puede dar lugar a blancos de aspiración alta que no se pueden resolver en la práctica. Para prevenirla, es recomendable evitar de dar directivas demasiado absolutas pero en lugar utilizar escalas de la satisfacción (véase abajo) cuándo definir las mejoras deseadas.

Especificación sobre base teórica

En el caso que ningún ejemplar conveniente no puede ser encontrado, los métodos que refieren a un ejemplar están fuera de cuestión. Sin embargo, es también posible especificar las características deseadas del estado futuro de cosas o del producto nuevo directamente en base de investigación anterior y teoría. Este método tiene, además, la ventaja que permite definir incluso productos y procesos radicalmente nuevos sin precursores sabidos.

Por otra parte, el método está exigiendo, porque usted tiene que trabajar con conceptos teóricos abstractos. Puede ser difícil definir las cualidades de un producto que todavía no existe. Es a veces difícil ver las relaciones entre varias cualidades, y ésa es por qué los requisitos con respecto a ellos a menudo se oponen. Por otra parte, es demasiado fácil olvidarse de características esenciales y de sus efectos secundarios, especialmente si afectan a forasteros.

El alcance de las características que son relevantes al desarrollar productos nuevos es muy grande. Contiene temas como:

usabilidad , función, efecto y mantenimiento fácil seguridad y durabilidad belleza significado simbólico ecología , uso de recursos coste y precio armonía con otros productos de la compañía y sus principios de Design Management puntos de vista de la fabricación, como las materias primas fácilmente disponibles y la

maquinaria ya existente logística y otros puntos importantes en la comercialización.

La lista arriba contiene sobre todo artículos que interesan o benefician al usuario o a fabricante del producto. Además, usted debe tener en cuenta que puede haber efectos secundarios, quizás perjudiciales, a los forasteros. Tales efectos son, desafortunadamente, a menudo difíciles de enumerar y de determinar. Vea una lista general de varios grupos de interés en un proyecto del desarrollo.

Todo producto posee un número infinito de atributos, pero sólo un pequeño número de ellos son importantes concerniente a la producción, del marketing o del uso. Incluso dentro de este grupo podemos ignorar cuestiones "obvias", es decir, asuntos en los cuales toda la gente en el equipo de diseño conviene y que así probablemente serán considerados suficientemente sin alguna mención en el concepto del producto. De todas formas, la lista de características crece a menudo difícil para manejar. Algunos procedimientos que pueden ayudar a tratar una lista muy larga de características y de requisitos son:

Haga una lista separada de los requisitos obligatorios. Descubra los requisitos interdependientes e intente combinarlos en una variable. Defina los pesos mutuos de requisitos. Defina los grados de satisfacción para tan muchas características como sea posible.

Los requisitos obligatorios. Se refieren a menudo a la seguridad del uso del producto, especialmente sus peligros mecánicos, químicos o eléctricos. Las regulaciones obligatorias son dadas a menudo por las autoridades públicas, o se publican como las pautas y estándares voluntarias de la industria. Se especifican con proyectos de investigación separados, realizados por especialistas como médicos, ingenieros de seguridad, etc. En el concepto del producto es generalmente recomendable no mezclar requisitos obligatorios y voluntarios. En lugar, haga las listas separadas de ellos. En esa manera será más fácil, en la inspección final de la propuesta del producto, vea si se respetan.

Requisitos interdependientes. No es infrecuente que los objetivos de calidad y coste u otras finalidades del proyecto futuro estén en conflicto en mayor o menor grado. Esto es incluso más fácil si las preferencias se han recibido a partir de varias personas o grupos que tengan distintos estilos de vida y valores. Tales conflictos deben ser eliminados lo más pronto posible; de otro modo podrían ralentizar fatalmente la preparación de la propuesta final.

A veces es posible conjugar los objetivos que están ostensiblemente en conflicto desvelando sus relaciones mutuas. Un ejemplo de este método es localizar el aislamiento térmico óptimo para un edificio. Cuando se elige el grosor de la capa aislante, el coste de los materiales de construcción (B, en la figura de la derecha) y los costes futuros de calefacción (A) parecen estar en conflicto. Sin embargo, los valores de estos dos gastos pueden ser traducidos a costes anuales, hasta que fácilmente se encuentra el valor óptimo de A+B. Esta variable nueva (A+B) puede entonces suplantar las dos variables originales de los costes del edificio y de la calefacción.

La ciencia del análisis de operaciones abarca otros métodos de análisis comparables, como por ejemplo el algoritmo de la  programación lineal, que puede usarse para encontrar el valor óptimo común de varios atributos cuantificables de un producto. La mayor parte de estos métodos aceptan solamente variables cuantitativas. Por supuesto, es posible cuantificar cualquier atributo cualitativo y transformarlo en una variable cuantitativa; pero la conversión suele pasar por alto algunos aspectos más sutiles del atributo y la validez de los resultados se resentirá entonces por ello. Por eso, esta técnica se debe utilizar solamente con discreción.

Definir los pesos mutuos de requisitos. Si hay bastante tiempo de preparar escrupulosamente el concepto del producto, revelará generalmente una gran cantidad de requisitos que el producto nuevo se suponga para satisfacer. Sin embargo, generalmente sólo un número pequeño de éstos será

Objetivo Peso

Capacidad de al menos 55 unidades/hora 40

Diseño llamativo y personal; a diferencia de todos los demás modelos del mercado

10

Todos los materiales pueden reciclarse 10

La producción no costará más de 100$ 40

Total de pesos 100

esencial y absolutamente obligatorio (y ellos se recogen preferiblemente en una lista separada) mientras que la mayoría de los requisitos son blancos más o menos voluntarias.

Por supuesto, la meta es satisfacer todos los requisitos de la gente pertinente si sea posible, pero sucede en la práctica a menudo que lograr totalmente una blanco prevendrá la realización otro, particularmente la blanco del coste moderado de producción. Esta es la razón por la cual es recomendable definir la orden en la cual los requisitos se pueden abandonar si necesario, por ejemplo para hacer posible el cumplimiento de una meta más importante. La orden de la importancia puede ser dada asignando pesos a los requisitos. Un ejemplo de una tabla pequeña de pesos se presenta a la derecha.

Una tabla de requisitos ayuda a manejar una gran cantidad de propiedades, pero solamente si su contenido se da en una orden lógica. Preferiblemente debe ser posible comprender todos los grandes rasgos en un panorama. Con este fin, y también para reducir el tamaño de la tabla, es ventajoso combinar los grupos de características asociadas en un peso. Tales familias de cualidades pueden ser encontradas contemplando o discutiendo en el equipo, o para las variables cuantificables con la ayuda de análisis factorial.

Los grupos de características que resultan se pueden entonces presentar en el patrón de un árbol lógico, de un diagrama de Venn o de otro modelo topológico. En cada nivel del árbol la suma de todos los pesos es constante, por ejemplo 100%, pero por supuesto los pesos absolutos en los niveles más bajos más detallados serán más pequeños. Un ejemplo de un árbol lógico está a la derecha, donde Shackel ha analizado el concepto de la utilidad de productos.

Otro árbol lógico (abajo) representa las metas cualitativas de la construcción (por Niukkanen, 1980, p.20).

SATISFACCIÓN / ADECUACIÓN

Entrada (aportaciones) Salida (producción)

Costes / Recursos Utilidad / Función Experiencia / Percepción

Costes de construcción Costes de uso

Disminución de producción

Espacios Entorno de interior y clima Equipamiento y durabilidad

Factores ambientales Exteriores Interiores

La tabla de pesos tiene una grande ventaja: puede transformarse posteriormente en una tabla de evaluación de las propuestas de diseño o para someterlas al análisis de costes y ventajas.

Los grados de satisfacción. Para muchas características el límite de la aceptación o del rechazo es vago: el más usted obtiene, el mejor es. Por otra parte, producir una calidad o una capacidad superior significa generalmente costes adicionales. Puede ser ventajoso posponer la medida final de tal característica a un momento más tarde en el proceso del desarrollo de producto, cuando tenemos más conocimiento de las alternativas disponibles y de sus costes. Esto significa que incluso cuando sería perfectamente posible definir, en la fase del análisis, un límite de la aceptación para esta característica, definimos en lugar una serie de grados de satisfacción o de "niveles del mérito" como en la tabla a la derecha. La satisfacción se mide en una escala arbitraria, por ejemplo en una escala de 1 a 5. Una escala numérica facilita el manejar de varias características simultáneamente y el encontrar de su grado óptimo común, aunque la desventaja es que algunos aspectos de menor importancia de la característica pueden conseguir olvidados.

Hay también características que fácilmente se pueden medir numéricamente, pero a pesar de esto la medida no indica directamente su valor de utilidad o de satisfacción. Consideremos una bicicleta: si posee dos marchas es mucho mejor que un vehículo del engranaje simple. Tres marchas son todavía un poco mejor, pero si hay sobre diez engranajes la adición de una o dos más no da mucho aumento en utilidad o

satisfacción. La relación entre el número de marchas y la satisfacción se puede expresar en una curva, como en el diagrama a la izquierda.

Otro ejemplo de una escala de la utilidad está a la derecha. Según él, un tocadiscos deberá ser valorado "pobre" (utilidad=1) si sólo transmite la voz hasta el límite de 5 kilociclos. 10 khz es un poco mejor, mientras que 20 kilociclos es excelente (utilidad=5). Un rendimiento más alto después de eso no da ningún mérito adicional, porque la oreja humana nunca podría oír las voces sobre de 20 khz.

Es posible medir, al lado de las ventajas materialistas y utilitarias, también agrados intelectuales como belleza. Un ejemplo se ve en el diagrama a la izquierda. El gráfico pretende indicar que hay un grado óptimo mensurable de la complejidad visual de una

Propiedad: Facilidad de uso Mérito

Las operaciones son automáticas. 5

Varias operaciones son automáticas. Folleto de instrucciones es detallado y claro.

4

Instrucciones y funcionamiento mediocres. 3

El funcionamiento a veces torpe o confuso. 2

La máquina reacciona de manera distinta a la descrita en el folleto.

1

obra de arte (y porqué no de un producto industrial, también). La filosofía detrás de este tipo de medida estética se discute en Belleza del descubrimiento.

Crear propuestas

"El proceso de "planificación racional" Iteración El método del tanteo El método de maduración subconsciente Innovacion en grupo de trabajo como "lluvia de ideas" Métodos participativos

El proceso de "planificación racional"

Razonamiento lógico como método de planeamiento apunta a encontrar apenas una óptima solución en base de las blancos dadas y de las circunstancias efectivas. Esta técnica es posible solamente si el planeador sabe exactamente todas las blancos y restricciones tan bien como sus lazos mutuos, y si éstos son validados por todos los partidos implicados.

Se han producido modelos para el proceso de diseño mediante el razonamiento lógico sobre como debe hacerse el diseño. Este método ha producido el llamado "proceso de planificación racional", que consiste en las siguientes fases:

1. Descripción de la situación de partida2. Descripción de la situación a la que se pretende llegar3. La diferencia entre 1 y 2 da los objetivos para el plan4. Concebir alternativas para alcanzar el objetivo5. Predecir las consecuencias para cada alternativa6. Valorar las consecuencias7. Elegir la mejor alternativa.

Las tres fases iniciales del proceso son a menudo fácilmente factibles con los métodos usuales de investigación descriptiva. Las fases 4 y 5 deben ser rutinas normales para un diseñador perito. En esos campos de la producción industrial donde este tipo de la tarea es usual, es aún posible que investigadores desarrollen los modelos uniformes de la deducción o del cálculo que los diseñadores pueden utilizar en la mayoría de las tareas para encontrar las soluciones óptimas. En la práctica real del diseño, lo más cercano a un proceso racional puede probablemente encontrarse en la ingeniería técnica. Los procedimientos exactos usados en ella son, por ejemplo, algoritmos, es decir, cálculos para encontrar las medidas para estructuras y redes de líneas eléctricas. Pueden con frecuencia llevarse a cabo mediante un ordenador, que puede acelerar el diseño en gran medida, especialmente cuando se usa el diseño asistido por ordenador (computer aided design-CAD).

El punto más débil del modelo son las fases 6 y 7 donde usted debe considerar simultáneamente una multiplicidad de requisitos de diversos partidos: las necesidades de varios grupos de gente, el ambiente, la tecnología de la producción y coyunturas. Una

evaluación común de todos estos requisitos es obviamente posible solamente si las consecuencias de alternativas se saben exactamente y no hay también muchas diferencias personales en la evaluación. Una condición tan afortunada no es común en el diseño de productos, para un uso personal de gente.

Muchos investigadores de los métodos de planificar han propuesto tratar con problemas complicados según el método de Descartes, dado como las reglas nos. 2 y 3 en el Discurso del Método (1637): dividir el problema en "en tantas partes como sea posible para solucionarlas mejor", resolver separadamente cada uno de éstos, empezar con las asuntos más simples y subir al más complejos. Así, Christopher Alexander en el libro Notes on the synthesis of form [Notas sobre la síntesis de la forma] (1964, p.94) ilustra su método con la ayuda de dos árboles lógicos (abajo). El que está a la izquierda presenta el proceso del análisis: hender los requisitos al producto futuro en sus componentes. El segundo árbol simboliza la síntesis donde los problemas resueltos, presentados como esquemas, se agregan juntos. "En el ápice está el último esquema, que captura las implicaciones completas del problema entero, y es por lo tanto el diagrama completo para la forma requerida" dice Alexander. Sin embargo, los arquitectos y diseñadores practicantes pronto encontraron que es raramente posible hender problemas del diseño en partes tan independientes que éstos se podrían resolver en el aislamiento y combinar de nuevo con éxito. Es decir la piedra filosofal del planificar no será encontrada con este acercamiento.

 

Iteración

Iteración es un proceso a menudo visto en el análisis normativo. Significa que usted hace modificaciones "incrementales" pequeñas a la propuesta, compara la nueva con la vieja propuesta y continúa con cualquiera de ellas que es la mejor. Es un método poderoso, pero al usarlo

usted debe tener en cuenta dos debilidades inherentes de él:

1. El método iterativo puede manejar solamente una característica del objeto al mismo tiempo. Si usted tiene varios alternativas en los cuales diverja de uno al otro en más que un respecto, usted lo encontrará difícil comparar ellos con el método iterativo.

2. Otra debilidad del método de iteración es que mientras que ella conduce generalmente a una solución mejor, puede sin embargo no poder encontrar la mejor alternativa de todos. Un ejemplo de esto se ilustra en la figura a la izquierda: si el proceso de la iteración se

comienza en la opción A, dirigirá eventualmente a alternativa C. Esta es, sin embargo, solamente un óptimo parcial: mientras que es ciertamente mejor que los vecinos, está lejos del grado óptimo absoluto S, que es radicalmente diferente y nunca podía haber sido encontrado por iteración sólo. Obviamente, si usted considera solamente alternativas que no diferencian mucho del viejo, usted nunca inventa algo radicalmente nuevo. A causa de esta debilidad es recomendable complementar el enfoque iterativo con otros métodos más innovadores que sean capaces de elaborar las propuestas que son más distantes a las ya sabidas.

Al otro lado, el enfoque iterativo tiene una ventaja poderosa: permite comenzar el trabajo en un nivel inferior de la exactitud en las fases iniciales del proyecto. Significa no solamente velocidad y economía. Con menos detalles y exactitud es más fácil mantener la innovación y crear alternativas que son más lejanos de existentes y sabidas hoy. Si usted no tiene suficientes hechos para basar sus primeras propuestas, usted puede hacer simplemente conjeturas. Las adivinaciones malas entonces se eliminarán en la fase de la evaluación. A condición de que la prueba final se hace con cuidado, es permitido utilizar un estilo de trabajo más bravo y más innovador durante la mayor parte del tiempo. La evaluación final tendrá validez mejor ya porque las propuestas finales son más detalladas y más realistas.

El método del tanteo

Cuando usted tiene la posibilidad de elegir entre alternativas que tienen una variación grande, y el número de las alternativas crece, la probabilidad se aumenta que hay una alternativa aceptable entre ellos. Esto es verdad también cuando la aceptabilidad media de las alternativas es baja, e incluso cuando ellos se han generado con un procedimiento aleatorio que no tiene como objetivo las metas finales de la selección. Esta última lógica es, en hecho, igual que ha gobernado el origen de las especies con la selección natural, según la teoría de Charles Darwin.

Un uso eficiente del método del tanteo requiere así muchas alternativas, quizás varios centenares de ellos, y la gama de su variación debe ser tan ancha que una alternativa aceptable - o por lo menos una alternativa pensable, tal vez fructuosa - se puede esperar caer dentro de esta gama. Note que no necesitamos encontrar una propuesta perfecta y final entre las alternativas. Encontrar el más prometedor o unos pocos prometedores entre ellas generalmente basta, porque unas imperfecciones en él se pueden fácilmente corregir más tarde con iteración. Debe evaluar así las alternativas no tal y como están, sino como puntos de partida potenciales para las propuestas. Gran competencia del evaluador es así esencial.

Para desarrollar una gran cantidad de alternativas dos métodos son comunes:

salir de un producto o una idea existente, y usar ideas lejanas y aleatorias.

Para generar una gama grande de alternativas usted quizás quiera tomar un producto existente como punto de partida, pero la dificultad en este método es que las propuestas tienden a quedarse demasiada cerca de esto origen, y alternativas realmente nuevas nunca se encuentran. Sin embargo, el método es viable cuando combinado con una variación

voluntariosa brava, por ejemplo modificando la idea existente del producto viejo con transformaciones, por ejemplo:

Agrande: Agregue algo, multiplica, consolide, hágalo más largo, más alto, más grueso, más pesado, más fuerte o más rápida.

Reduce: Quite algo, haga más ligero, más corto o más lento. Dé vuelta al revés o interior hacia fuera. Contrario. Invertido. Vuelco. Gire de cabo a rabo. Henda. Combine. Posponga. Haga más temprano. Esconde. Acentúe. Especialice. Generalice. Substituya: ¿Qué más? ¿Quién otro? ¿Cómo de otra manera? Modifique la estructura. Cambie la orden, la disposición, el ritmo, el tempo o el nivel.

Debe evitar de criticar las transformaciones o de retrasar el proceso, para evitar estropear el estado de ánimo innovador del equipo. Por esta razón debe desatender todas restricciones u puntos de vista prácticos. Su turno viene más adelante, al seleccionar a los mejores candidatos y mejorándolos más lejos.

Otro método para alentar variación al desarrollar alternativas es fusionar "ideas distantes" aleatorias en el proceso creativo. Estas ideas distantes pudieron ser presentadas como artículos sacadas al azar de una lista elaborada previamente. Inicialmente no necesitan tener relación alguna con el problema de que se trata. Sin embargo, cada idea distante cuando asociada al producto original puede ayudar a producir nuevas ideas por analogía.

Una vez que una propuesta pensable - o algunas - se haya encontrado con el "método del tanteo", a menudo resulta que todavía haya mucho que debe mejorar en las propuestas. Para estos mejoramientos finales, iteración es a menudo el método adecuado.

El método de maduración subconsciente

Todos los métodos descritos arriba están destinados para ser utilizados por el diseñador tal y como procedimientos planeados y conscientes, pero otra posibilidad deberá que el subconsciente del diseñador se haga cargo del trabajo, quizás utilizando algunos fragmentos de las cadenas lógicas antedichas o de cualquier otra que todavía no sabemos.

El método de maduración subconsciente es común en el diseño artístico de productos. Común es que el diseñador permite primero que los blancos y el problema madura en el subconsciente por un período de tiempo, y si todo va bien, la solución se crea eventualmente. Tal un acontecimiento ha sido descrito por muchos profesionales practicantes varios artes, por ejemplo Mika Waltari, el escritor del bestseller El Egipcio:

"Esta experiencia intensiva es breve, a veces unos pocos segundos, a veces minutos. Por adelantado de ella, había ideado ya muchos contornos para el libro futuro, pero todos se habían parecido insustanciales... Este destello verdadero, la innovación genuina se parece una ocurrencia mística y no dura largo. Después usted puede tratar conscientemente entenderlo y hacerlo claro a

se. Sólo después usted puede comenzar a recoger la materia nueva de un punto de vista novela, y entonces sigue la concentración final en la escritura que puede tomar varios años... " (1980, p.398...400.)

Waltari acentúa que el mejor arreglo viene del subconsciente, no por planificación franca en el papel aún en el caso que el trabajo se basará en muchos de información escrita recogida:

"Si anoto los hechos recogidos en una manera demasiado definida, se convierte en un impedimento... Es mejor dejó esta inteligencia recogida sumergirse en el subconsciente, y más adelante cuando realmente necesito estos elementos para mi trabajo, se volverán al pensamiento consciente como hechos evidentes. Si esta manera se olvida de algunos detalles, yo he concluido que esos detalles eran quizás no realmente importantes... Si trataría de anotar los pasajes más largos antes su tiempo su idea muriera: el pensamiento se atiesaría prematuramente de modo que yo no pueda más lo explota." (ibid. p.406.)

Algunos artistas creativos creen que sería perjudicial disturbar o tratar de acelerar los funcionamientos del subconsciente. Las ideas más ingeniosas son las más huidizas: se apagan con facilidad y desaparecen si el inventor no las formula inmediatamente en lenguaje convencional.

"En la caza de ideas, la pericia del hombre en la preparación del escenario representa el arte del cazador. La creatividad es una cuestión de poner en escena un problema con una disposición tal, que algo empieza a ocurrir, aparece, y entra dentro de él. Ahora un ente está "haciéndose" ahí, algo se hace más visible, más creíble. Pero está sólo atrapado muy débilmente; puede escaparse si uno se acerca demasiado pronto." "La captura de una idea es un proceso que uno no parece capaz de influenciar conscientemente. La cognición consciente es un instrumento demasiado basto." (Pietilä 1985 p. 26.)

Sabemos muy poco de los procedimientos de trabajo del subconsciente. Se parece que para ocasionar una invención que el cerebro necesita, al lado de la base lógica para la solución del problema, también el estímulo que las capas íntimas del cerebro normalmente están produciendo toda la hora. Este estímulo no es relacionado con el problema consciente y, porque no sabemos su estructura, aparece ser al azar. En base de estos dos estímulos el cerebro entonces produce las soluciones tentativas para el problema, y la cognición entonces comienza a evaluar éstos de la misma manera que la selección natural elimina los mutantes no aptos según la teoría de Darwin. Eventualmente una de ellas se valida en la evaluación consciente y el artista comienza a desarrollarla más lejos.

Innovación en grupo de trabajo

No hay método fijo para la creación de innovaciones. Sin embargo es posible estimular un esfuerzo así. Para un grupo de trabajo a la caza de innovaciones, hay algunas técnicas especiales, como:

enumeración sistemática de todas las alternativas previamente conocidas listas de soluciones parciales/incompletas y combinarlas de nuevas maneras, con

intención de producir resultados nuevos torbellino o lluvia de ideas (brainstorm): de 5 a 12 personas se reúnen con el fin de

desarrollar gran cantidad de ideas inmaduras, inacabadas. Criticarlas en la reunión está prohibido, con el fin de conservar el espíritu creativo de la reunión. "La cantidad genera calidad": cuando hay gran cantidad de ideas, se hace probable que algunas entre ellas produzcan algo fructífero.

la sesión sinéctica: una práctica que implica varias fases, en que se promueve inicialmente el torbellino de idas, y posteriormente la maduración de éstas. El objetivo es evitar soluciones viejas y convencionales. De tanto en tanto, los participantes de la sesión empiezan con una excursion mental en que toman distancia ellos mismos del problema y de las vías tradicionales donde sus pensamientos se han anclado.

Todos estos métodos comparten algunos principios comunes:

La blanco se debe definir inicialmente, pero no demasiado exacto. Durante la generación de ideas éstos no deben ser desaprobados. Las ideas generadas se deben registrar inmediatamente (quizás en vídeo), porque puede

suceder que varias propuestas se presentarán en una sucesión rápida. Debe haber períodos de la maduración y de relajar, quizás consultando con la almohada.

Los participantes deben intentar olvidarse las actitudes que podrían inhibir la innovación, tal como (según Johnsson y Varjoranta, 50):

Actitud negativa respecto a la imaginación, recibida a menudo de padres y de profesores. Modestia, subestimación de propias ideas. Pereza del pensamiento, una fijación superficial a modelos heredados de reflexionar. Confianza demasiada en racionalidad y lógica. Narcisismo, egotismo excesivo. Confianza en la autoridad. Ambición egoísta, desgana al trabajo en equipo y cooperación. El miedo de cometer un error. Aversión a parecer tonto o estúpido.

Métodos participativos

Un proyecto normativo apunta a desarrollar una propuesta que sea aceptable para todos grupos de interés pertinentes. La manera más fácil y más confiable de alcanzar tal consenso (aunque no siempre es posible) deberá preparar la propuesta en una cooperación cercana con estos grupos de interés. En el caso afortunado que suficientes personas de los grupos principales de interés están disponibles para participar en el proyecto, es a menudo posible oír sus opiniones no sólo en la etapa final de aceptar o de rechazar la propuesta, pero en lugar en varios momentos durante el proyecto. Este método de consultación frecuente mejora generalmente el resultado del proyecto, porque ayuda a eliminar las propuestas inaceptables de antes de que demasiado trabajo haya estado gastado a ellas.

Reuniones y discusiones frecuentes a menudo con un cuarto lleno de gente hacen los métodos participativos muy diferentes del trabajo solitario de un investigador académico. Típicos son los procedimientos y las características siguientes:

Las fases del proyecto se combinan. La gente que participa en un proyecto normativo se interesa sobre todo en la propuesta final. Si participan ya en las fases anteriores del proyecto, desearán de todos modos discutir la propuesta final "prematuramente" como el investigador quizás piensa.

Colección de datos consigue una dimensión normativa. Simultáneamente con los hechos descriptivos que se reúnen con medidas objetivas, también opiniones normativas sobre el objeto del estudio se pueden registrar. Ejemplos de la tipo normativo de recoger datos se dan en la página Reunir datos normativos.

Los métodos diferentes de la recogida de datos se pueden mezclar. No es necesario evitar los disturbios que pueden resultar de usar simultáneamente los métodos de observación, de entrevista y de experimento. Cuál es importante en un proyecto normativo no es la confiabilidad de datos objetivos pero la calidad de las propuestas, y ésta se evaluará en la fase final del proyecto.

No debe ser negado que evaluación y alcanzar unanimidad pueden a veces ser arduas y lentas. Un proyecto normativo afecta a menudo las vidas de muchos grupos de interés, y cuando mucha gente participa en las discusiones es a menudo imposible proceder directamente a la síntesis y la propuesta. Algunas razones usuales de complicaciones son:

El resultado será en el futuro y por lo tanto su formulación detallada toma tiempo. El contexto futuro, también, puede ser difícil de predecir.

A causa del gran número de personas implicadas está difícil de convenir sobre el resultado final, sobre los métodos de alcanzarlo, o sobre los costes.

Las propuestas son hechas por los investigadores, planificadores y diseñadores, es decir por otras personas que los evaluadores. Éstos rechazan a menudo partes esenciales de las propuestas. El proceso entonces vuelve a preparar una propuesta nueva.

Algunas personas necesitan tiempo para tomar su punto de vista y expresar sus deseos en el asunto. Desean a menudo continuar la discusión más tarde, y quizás necesitan clarificación de algunos detalles.

Los métodos que a menudo se utilizan para arbitrar opiniones contrastantes, se enumeran en la página Conciliar opiniones contrastantes. Es normal que toma tiempo de alcanzar la aceptación general cuando las opiniones difieren. Al contrario, es típico de análisis participante que una parte del trabajo tiene que ser hecha de nuevo a veces. Si hay muchos tales regresos, el proceso comienza a asemejarse más a un círculo que a una sucesión linear de decisiones. De hecho, un espiral como el que está a la derecha se ha definido a veces como modelo típico de un proyecto del desarrollo. Las fases típicas en un "espiral del desarrollo" son como sigue.

1. Descripción normativa del estado inicial y definir la necesidad de mejoras2. análisis de relaciones de cosas y de posibilidades para alteración3. síntesis: propuesta para la mejora4. evaluación de la propuesta.

Repitiendo la secuencia a partir del 2 a 4, y gradualmente mejorando la propuesta, un resultado aceptable se encuentra generalmente.

Algunos acercamientos típicos de participación normativa se discuten abajo.

El diseño "sastre-hizo" es el arreglo normal de la cooperación para producir un producto único para una persona o para un grupo de gente pequeño tal como una familia. Cuando es posible reunir todos los diseñadores y usuarios del producto alrededor de una mesa, ellos pueden trabajar en equipo, deliberando juntos los problemas del diseño. Las soluciones a los problemas se encuentran y se aceptan a menudo colectivamente, pero es la tarea del diseñador profesional explicar las restricciones técnicas y producir alternativas, quizás con los métodos de crear propuestas discutidas anteriores. El usuario emplea al planificador o diseñador normalmente como un consejero.

Cuándo un grupo grande pero no organizado de personas está dispuesto a desarrollar un producto en cooperación, los métodos convenientes se pueden encontrar bajo la etiqueta de diseño colectivo, cuál método se ha utilizado a veces al planear un grupo de casas, véase Kukkonen (1984). No es muy común, pero que puede tener algún interés de los puntos de vista de investigación y de democracia.

El diseño colectivo está basado en reuniones de los diseñadores y los usuarios futuros de los productos. A causa del gran número de usuarios, sus opiniones a menudo difieren, y una discusión para asentar el conflicto se necesita. Para acelerar la discusión puede ser recomendable organizar a los participantes en "grupos de interés" temporales. Al lado de estos grupos, hay siempre un "equipo técnico" de los diseñadores profesionales (y posiblemente de los investigadores) que preparan continuamente propuestas alternativas para ser discutidos en reuniones generales semanales con los usuarios.

Las fases típicas en la planificación participativa son:

1. Organizar los grupos de interés que entonces pueden decidir tener reuniones privadas si lo sienten necesarios.

2. Análisis. Los grupos de interés clarifican sus metas, primero solamente a sí mismos. 3. Diseño y negociación entre los grupos de interés. Si un grupo se parece sufrir debido a

una propuesta este grupo debe quizás recibir una remuneración para ella. 4. Ratificación con tan unánime una decisión como es posible. (Explicación más detallada en

Planificación participativa.)

Un "lenguaje de diseño" común se necesita para que los clientes sin formación tecnológica puedan describir cosas que esperan de los productos futuros. Para el diseño de viviendas, este tipo de lenguaje se ha desarrollado por Heikki Kukkonen (1984) (véanse ejemplos de ello).

Un trabajo pionero fue el conciso libro Toward a Scientific Architecture (1975) de Yona Friedman. El autor afirma que, para ayudar en el diseño colectivo, el diseñador debe, previamente, preparar un repertorio que muestre a los usuarios todas las alternativas posibles que tienen. Además, el repertorio debe contener advertencias pertinentes sobre cada elección, por ejemplo sus beneficios, inconvenientes y costes. Pero no corresponde al diseñador criticar las elecciones del usuario más que lo que el camarero de un restaurante critica los platos que su cliente elige.

Un ejemplo bien conocido del material teórico, preparado por adelantado para el diseño colectivo, está A Pattern Language (1977), desarrollado por Christopher Alexander et al., se basa en una investigación bastante costosa tanto con respecto al aspecto práctico como a la comodidad. El "lenguaje de patrones" de Alexander consistía en 253 instrucciones de diseño, aunque los autores tienen buen cuidado en afirma que también éstas son sólo un ejemplo: cada comunidad en particular tiene un lenguaje de patrones propio y lo mismo ocurre con cada individuo. Por otro lado, muchos patrones son arquetípicos o comunes a todos los seres humanos.

Cada uno de los patrones de Alexander sigue la misma fórmula que se ha descrito en la página x del libro: la primera imagen es un ejemplo arquetípico y hay también una breve lista de otros patrones que están relacionados con ella. La lista es seguida por una ilustración que clarifica qué significa este patrón. Tras esto se da cuenta del conocimiento empírico sobre el patrón y variaciones de su aplicación. Ejemplos de los patrones de Alexander. El método de diseño colectivo con estos patrones se explica en The Oregon Experiment, por Alexander et al. (1975).

Gracias a investigación intensiva, algunos productos ahora poseen tan confiable una teoría que diseñar productos nuevos es bastante fácil. Algunos investigadores, sobre todo Yona Friedman (1975 B) y Nicholas Negroponte, han propuesto que en base de tal teoría - los estándares, algoritmos, ejemplares y las reglas para ajustarlos - sería posible construir una máquina de diseño, es decir un aparato programado que se puede usar para producir automáticamente un diseño para un producto nuevo. El cliente expresa sus deseos apretando las teclas de un menú, y el autómata después crea un diseño en base de las reglas que un diseñador profesional ha programado en la máquina por adelantado. La ventaja estaría el reducir no solamente el trabajo de diseño, pero también mejorar el servicio al consumidor que tendría así más opciones al comprar un producto.

Hay pocas máquinas de diseño en operación hoy, pero pueden llegar a ser más frecuentes en el futuro. La idea es interesante teóricamente, porque una teoría del diseño explícita será necesaria para definir los costes y otros resultados que producirá cada alternativa en el menú cuando se selecciona, y por supuesto, para producir el diseño que el cliente quiere ordenar.

No es difícil construir una máquina de diseño para tales productos que consisten en partes prefabricadas y los clientes sólo escogen los componentes que desean incluir en el producto. En hecho, esto es qué hoy ya sucede, no sólo en la cafetera automática tradicional, pero también en los sistemas de comercialización de los muebles de cocina y de computadoras, especialmente cuando éstos se compran en el Internet.

El paso siguiente podría quizás agrandar la selección hasta incluir dimensiones, colores y formas del producto, y posiblemente también transmitir el diseño acabado a las máquinas de la fabricación, creando así un sistema de la fabricación automatizada.