1. 2. 3. 4. 5. 6.

Ciclo de vida clsico del desarrollo de sistemas Mtodo de desarrollo por anlisis estructurado Mtodo del prototipo de sistemas Conclusiones Bibliografa INTRODUCCIN

En la actualidad para muchas organizaciones, los sistemas de informacin basados en computadoras son el corazn de las actividades cotidianas y objeto de gran consideracin en la toma de decisiones, las empresas consideran con mucho cuidados las capacidades de sus sistemas de informacin cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darn a la competencia. Al establecer los sistemas de informacin 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. Ningn sistema que deje satisfacer ambos objetivos ser completamente til para la gerencia u organizacin. Si los dispositivos de un sistema de informacin no se adaptan a su poblacin de clientes, no lograra sus objetivos potenciales. A mismo tiempo, aun cuando se identifiquen precisamente las necesidades del usuario, un sistema de informacin 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 funcin del Anlisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Es el Proceso de gestin para la creacin de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimacin, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimacin, es ms un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de costes de tiempo. Y dado que la estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como gua para una buena Ingeniera Sistemas y Software. Al estimar tomamos en cuenta no solo del procedimiento tcnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificacin. El Tamao del proyecto es otro factor importante que puede afectar la precisin de las estimaciones. A medida que el tamao aumenta, crece rpidamente la interdependencia entre varios elementos del Software. La disponibilidad de informacin Histrica es otro elemento que determina el riesgo de la estimacin.

CICLO DE VIDA DE UN SISTEMA DE INFORMACION El ciclo de vida de un sistema de informacin es un enfoque por fases del anlisis y diseo que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario. Segn James Senn, existen tres estrategias para el desarrollo de sistemas: el mtodo clsico del ciclo de vida de desarrollo de sistemas, el mtodo de desarrollo por anlisis estructurado y el mtodo de construccin 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 CLSICO DEL DESARROLLO DE SISTEMAS El mtodo de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e implantar un sistema de informacin. El mtodo del ciclo de vida para el desarrollo de sistemas consta de 6 fases: 1). Investigacin Preliminar: La solicitud para recibir ayuda de un sistema de informacin puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la peticin de una persona. 2). Determinacin de los requerimientos del sistema: El aspecto fundamental del anlisis 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? Cmo se hace? Con que frecuencia se presenta? Qu tan grande es el volumen de transacciones o decisiones? Cul es el grado de eficiencia con el que se efectan las tareas? Existe algn problema? Qu tan serio es? Cul es la causa que lo origina? 3). Diseo del sistema: El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en contraste con la del desarrollo del software, a la que denominan diseo fsico.

4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseados a la medida del solicitante. La eleccin 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 despus se examinan los resultados. 6). Implantacin y evaluacin: La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos aos. 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 evaluacin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones: *Evaluacin operacional: Valoracin de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de informacin, confiabilidad global y nivel de utilizacin. *Impacto organizacional: Identificacin y medicin de los beneficios para la organizacin en reas tales como finanzas, eficiencia operacional e impacto competitivo. Tambin se incluye el impacto sobre el flujo de informacin externo e interno. *Opinin de loa administradores: evaluacin de las actividades de directivos y administradores dentro de la organizacin as como de los usuarios finales. *Desempeo del desarrollo: La evaluacin de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estndares, y otros criterios de administracin de proyectos. Tambin se incluye la valoracin de los mtodos y herramientas utilizados en el desarrollo. MTODO DE DESARROLLO POR ANLISIS ESTRUCTURADO Muchos especialistas en sistemas de informacin reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El mtodo de desarrollo del anlisis estructurado tiene como finalidad superar esta dificultad por medio de:

1). La divisin del sistema en componentes 2). La construccin de un modelo del sistema. El anlisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicacin. Permite que las personas observen los elementos lgicos (lo que har el sistema) separados de los componentes fsicos (computadora, terminales, sistemas de almacenamiento, etc.). Despus de esto se puede desarrollar un diseo fsico eficiente para la situacin donde ser utilizado. El anlisis estructurado es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. ste anlisis permite al analista conocer un sistema o proceso en una forma lgica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente. Componentes Smbolos grficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes. Diccionario de datos: descripcin de todos los datos usados en el sistema. Puede ser manual o automatizado. Descripciones de procesos y procedimientos: declaraciones formales que usan tcnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. Reglas: estndares para describir y documentar el sistema en forma correcta y completa. Diseo Estructurado. El diseo Estructurado es otro elemento del Mtodo de Desarrollo por Anlisis Estructurado que emplea la descripcin grfica, se enfoca en el desarrollo de especificaciones del software. El objetivo del Diseo Estructurado es programas formados por mdulos independientes unos de otros desde el punto de vista funcional. La herramienta fundamental del Diseo Estructurado es el diagrama estructurado que es de naturaleza grfica y evitan cualquier referencia relacionada con el hardware o detalles fsicos. Su finalidad no es mostrar la lgica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interaccin entre mdulos independientes junto con los datos que un mdulo pasa a otro cuando interacciona con l.

Anlisis de flujo de datos. Estudia el empleo de los datos para llevar a cabo procesos especficos de la empresa dentro del mbito de una investigacin de sistemas usa los diagrama de flujos de datos y los diccionarios de datos. Herramientas Las herramientas muestran todas las caractersticas esenciales del sistema y la forma en que se ajustan entre si, como es muy difcil 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 ms importante y la base sobre la cual se desarrollan otros componentes. El modelo original se detalla en diagramas de bajo nivel que muestran caractersticas adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez ms detallados. Repitindose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigacin. El diagrama fsico de datos da un panorama del sistema en uso, dependiente de la implantacin, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de personas, nombres o nmeros de formato y documento, nombres de departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos. El diagrama lgico de datos da un panorama del sistema, pero a diferencia del fsico es independiente de la implantacin, que se centra en el flujo de datos entre los procesos, sin considerar los dispositivos especficos y la localizacin de los almacenes de datos o personas en el sistema. Sin indicarse las caractersticas fsicas. Notaciones: son cuatro smbolos, 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 direccin, desde un origen hasta un destino. Es un paquete de datos. MTODO DEL PROTOTIPO DE SISTEMAS La construccin 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 evolucin, donde el usuario participa de forma directa en el proceso. Este mtodo contiene condiciones nicas de aplicacin, en donde los encargados del desarrollo tienen poca experiencia o informacin, o donde los costos y riesgos de que se cometa un error pueden ser altos. As mismo este mtodo resulta til para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseo de un sistema o examinar el uso de una aplicacin. El mtodo del prototipo de sistemas consta de 5 etapas: 1). Identificacin de requerimientos conocidos: La determinacin de los requerimientos de una aplicacin es tan importante para el mtodo de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o anlisis 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 fcil comenzar el procesos de construccin 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 interaccin es de gran ayuda. En el desarrollo del prototipo se preparan los siguientes componentes: a). El lenguaje para el dialogo o conversacin entre el usuario y el sistema. b). Pantallas y formatos para la entrada de datos. c). Mdulos esenciales de procesamiento. d). Salida del sistema 3). Utilizacin del prototipo: Es responsabilidad del usuario trabajar con el prototipo y evaluar sus caractersticas y operacin. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, as como las caractersticas inadecuadas 4). Revisin del prototipo: Durante la evaluacin los analistas de sistemas desean capturar informacin 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). Repeticin del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas estn de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las caractersticas necesarias.

CONCLUSIONES Un proyecto de desarrollo de un Sistema de Informacin comprende varios componentes o pasos llevados a cabo durante la etapa del anlisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno ms de los componentes: Software, hardware, personas, base de datos, documentacin y procedimientos. Es por eso que existen varios modelos o mtodos para la realizacin del anlisis y diseo de un sistema, lo primero del trabajo fue revisar que es el Anlisis y el diseo y posteriormente el autor Kendall, presenta varios modelos que podemos utilizar para la realizacin y elaboracin de un proceso y trabajo exhaustivo y dar solucin o respuesta al problema que se ha generado desde la perspectiva del programador y analista.
aso de estudio 1:

Propuesta de comunidad en accin

Amadeus proporciona soporte para ms de 148 aerolneas usuarias Amadeus en sus oficinas de ventas y reservaciones, as como a agencias de viajes, corporaciones y viajeros a travs de pginas web potenciadas por Amadeus. Nuestra central de informacin 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 distribucin.

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 planificacin

Construccin

Aceptacin

Transicin

Fase IV Aceptacin Durante la fase de aceptacin, 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 Transicin Durante la fase de transicin el producto se libera para la comunidad de usuarios. Las responsabilidades del producto son tambin transferidas a la lnea de la organizacin. 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 planificacin Durante esta fase se analiza el problema dominante, se establece un slido fundamento arquitectnico de la solucin, 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 Construccin Durante la fase de construccin, 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 ANLISIS Y DISEO Module 1: Data and Information (3) Mdulo 1: Datos e Informacin (3) Types of information: operational, tactical, strategic and statutory why do we need Tipos de informacin: operativos, tcticos, estratgicos y legales por qu necesitamos information systems management structure requirements of information at different sistemas de informacin - estructura de gestin - Requisitos de informacin en diferentes levels of management functional allocation of management requirements of los niveles de gestin - la asignacin funcional de la gestin - Requisitos de information for various functions qualities of information small case study. informacin para las diversas funciones - cualidades de la informacin - pequeo estudio de caso. Module 2: Systems Analysis and Design Life Cycle (3) Mdulo 2: Anlisis de Sistemas y del ciclo de vida de diseo (3) Requirements determination requirements specifications feasibility analysis final Requisitos de la determinacin - especificaciones de requisitos - Anlisis de viabilidad final

specifications hardware and software study system design system implementation especificaciones - y el software de estudio de hardware - el diseo del sistema - la implementacin del sistema system evaluation system modification. evaluacin del sistema - la modificacin 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 anlisis del sistema Module 3: Information gathering (3) Mdulo 3: La recoleccin de informacin (3) Strategies methods case study documenting study system requirements Estrategias Mtodos - estudio de caso - estudio de la documentacin - Requisitos del sistema specification from narratives of requirements to classification of requirements as pliego de condiciones - a partir de relatos de los requisitos de clasificacin de los requisitos strategic, tactical, operational and statutory. estratgico, tctico, operativo y legal. Example case study Ejemplo de estudio de caso Module 4: Feasibility analysis (3) Mdulo 4: Anlisis de viabilidad (3) Deciding project goals examining alternative solutions cost benefit analysis Decidir los objetivos del proyecto - el examen de soluciones alternativas - anlisis de costo beneficio quantifications of costs and benefits payback period system proposal preparation for cuantificacin de los costes y beneficios - periodo de recuperacin - sistema de preparacin de propuestas para managements parts and documentation of a proposal tools for prototype creation gerencias - piezas y documentacin de la propuesta - herramientas para la creacin de prototipos Module 5: Tools for systems analysts (3) Mdulo 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 nivelacin de DFD leveling rules logical and physical DFDs software tools to create DFDs reglas de nivelacin - DFD lgico y fsico - herramientas de software para crear DFD Module 6: Structured systems analysis and design (3) Mdulo 6: anlisis de sistemas estructurados y de diseo (3) Procedure specifications in structured English examples and cases decision tables for Procedimiento especificaciones estructurada Ingls - ejemplos y casos - las tablas de decisin para complex logical specifications specification oriented design vs procedure oriented complejas especificaciones lgicas - la especificacin de diseo orientado a procedimiento global vs design diseo Module 7: Data oriented systems design (3) Mdulo 7: Diseo orientado a sistemas de datos (3) Entity relationship model ER diagrams relationships cardinality and participation Entidad modelo de relacin - diagramas ER - cardinalidad de las relaciones y la participacin -

normalizing relations various normal forms and their need some examples of normalizacin de las relaciones - diversas formas normales y su necesidad - algunos ejemplos de relational data base design. diseo de la base de datos relacional. Module 8: Data input methods (3) Mdulo 8: mtodos de entrada de datos (3) Coding techniques requirements of coding schemes error detection of codes Las tcnicas de codificacin - Requisitos de los sistemas de codificacin - deteccin de errores de los cdigos validating input data input data controls interactive data input validacin de los datos de entrada - los datos de entrada los controles de entrada de datos interactiva Module 9: Designing outputs (2) Mdulo 9: Diseo de productos (2) Output devices designing output reports screen design graphical user interfaces Los dispositivos de salida - el diseo de informes de resultados - diseo de la pantalla interfaces de usuario grficas interactive I/O on terminals. Yo interactiva de E / S en los terminales

Competencia: Anlisis y Diseo de sistemas de Informacin Estudio de casos: VideoTienda(Alquiler de pelculas)

En esta oportunidad estimado aprendiz quiero que ponga mucho cuidado y al caso de estudio que se plantea a continuacin, en dicho caso debers analizar y disear lo que quiere el cliente.

Para el anlisis de este caso, el equipo de desarrolladores formados por Cindy Reyes, Yasiris Piraquive y Yerlenys Lapeira, se reunieron con el dueo de una video tienda cuyo negocio es el alquiler de pelculas, el dueo quiere de la mejor manera buscar a travs de un sistema va web que sus clientes puedan alquilar pelculas desde su casa, y que el dueo pueda mirar dichos alquileres, entre otras cosas.

Para empezar con el proyecto el equipo de desarrolladores, disearon una seria de preguntas para la primera entrevista con el cliente, estas preguntas les dar al equipo un primer acercamiento de la lgica de negocios, es decir saber cmo funciona actualmente la video tienda o alquiler de pelculas.

El equipo formulo las siguientes preguntas y escribi las respectivas respuestas

1)

Quienes seran las personas que utilizaran el sistema

Respuesta del cliente: Bueno el sistema lo utilizara obviamente mi persona que administro el negocio de la videotienda y los cliente que alquilan mis pelculas.

2)

Que operaciones le debera dejar hacer el sistema al cliente, es decir que le mostrara.

Respuesta del cliente: Bueno yo quiero que el cliente pueda ver todas las pelculas disponibles, y luego de poderlas alquilar con una opcin que diga alquilar. De igual forma quiero que l pueda ver todas las pelculas que l tiene pendiente de devolver.

Nota: es posible que el entrevistador adems de las preguntas que trae en su libreta pueda formular otras adicionales, que para este caso sera bueno teniendo en cuenta la respuesta del cliente.

El entrevistador formula una nueva pregunta: Cuando el sistema le muestra al cliente todas las pelculas, exactamente qu datos de la pelcula quiere usted que le muestre? Respuesta del cliente: Bueno quiero que muestre el ttulo de la pelcula, Genero de la pelcula, es decir si es de Accin, Terror, Risa, entre otras; muestre una descripcin, El actor principal, nmero de copias disponibles y el valor del alquiler, y como le dije una opcin para alquilar cualquiera de estas pelculas.

La primera entrevista finaliza y el equipo agradece al cliente

Anlisis y Diseo de Sistemas de Informacin UNIDAD I Fundamentos del anlisis de sistemas 1. COMO ASUMIR EL PAPEL DEL ANALISTA DE SISTEMAS. a) LA INFORMACIN 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 informacin se ha colocado en un lugar adecuado como recurso principal. Los tomadores de decisiones estn comenzando a comprender que la informacin no es slo un subproducto de la conduccin, sino que a la vez alimenta a los negocios y puede ser el factor crtico para la determinacin del xito o fracaso de stos. Manejo de la informacin como recurso. Para maximizar la utilidad de la informacin, un negocio la debe manejar correctamente tal como maneja los dems recursos. Los administradores necesitan comprender que hay costos asociados con la produccin, distribucin, seguridad, almacenamiento y recuperacin de toda informacin. Aunque la informacin se encuentra a nuestro alrededor sta no es gratis, y su uso es estratgico para posicionar la competitividad de un negocio. Manejo de la informacin generada por computadora. El manejo de informacin generada por computadora difiere en forma significativa del manejo de datos producidos manualmente. Por lo general, hay mayor cantidad de informacin de computadora a administrar. El costo de organizarla y mantenerla puede crecer a tasas alarmantes, y los usuarios frecuentemente la tratan menos escpticamente que la informacin obtenida por otras vas. b) CONCEPTOS DE ANLISIS Y DISEO DE SISTEMAS. Los sistemas de informacin son desarrollados con propsitos diferentes dependiendo de las necesidades del negocio. Los sistemas de procesamiento de transacciones (TPS por sus siglas en ingls) funcionan al nivel operacional de la organizacin, los sistemas de automatizacin de oficina (OAS por sus siglas en ingls) y los sistemas de trabajo de conocimiento (KWS por sus siglas en ingls) que dan cabida al trabajo a nivel de conocimiento. Los sistemas de ms alto nivel incluyen a los sistemas de apoyo a decisiones (DSS por sus siglas en ingls) as como a los sistemas de informacin gerencial (MIS por sus siglas en ingls). Los sistemas expertos aplican la experiencia de los tomadores de decisiones para resolver problemas especficos estructurados. Al nivel estratgico de la administracin encontramos sistemas de apoyo a ejecutivos (ESS por sus siglas en ingls) y los sistemas de apoyo a decisiones de grupo (GDSS por sus siglas en ingls) 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 informacin 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 todava debe alimentar datos a los sistemas computarizados. Sistemas de automatizacin de oficina y sistemas de manejo de conocimiento. Al nivel de conocimiento de la organizacin hay dos clases de sistemas. Los sistemas de automatizacin de oficina (OAS) que dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la informacin para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla o diseminarla formalmente por toda la organizacin y algunas veces ms all de ella. Los sistemas de manejo de conocimiento (KWS) dan soporte a los trabajadores profesionales, tales como cientficos, ingenieros y doctores, les ayudan a crear un nuevo conocimiento que contribuya a la organizacin o a toda la sociedad. Sistemas de informacin gerencial. Los sistemas de informacin 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 informacin computarizada que trabajan debido a la interaccin resuelta entre gentes y computadoras. Requieren que las gentes, el software (programas de computadora) y el hardware (computadoras, impresoras, etc.) trabajen al unsono. Los sistemas de informacin dan soporte a un espectro ms amplio de tareas organizacionales que los sistemas de procesamiento de transacciones, incluyendo el anlisis de decisiones y la toma de decisiones. Sistemas de apoyo a decisiones. Una clase de ms alto nivel en los sistemas de informacin computarizada son los sistemas de apoyo a decisiones (DSS). El DSS es similar al sistema de informacin gerencial tradicional en que ambos dependen de una base de datos como fuente. Un sistema de apoyo a decisiones se aparta del sistema de informacin gerencial tradicional en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisin actual todava es del dominio del tomador de decisiones. Sistemas expertos e inteligencia artificial. La inteligencia artificial (AI por sus siglas en ingls) puede ser considerada la meta de los sistemas expertos. Los sistemas expertos son un caso muy especial de un sistema de informacin, cuyo uso ha sido factible para los negocios a partir de la reciente y amplia disponibilidad de hardware y software. Un sistema experto (tambin 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 organizacin. Observe que a diferencia del DSS, que deja la decisin final al tomador de decisiones, un sistema experto selecciona la mejor solucin a un problema o a una clase especfica 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 solucin. 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 interacten con apoyo electrnico, frecuentemente en forma de software especializado y con una persona que d facilidades al grupo. Los sistemas para decisiones de grupo estn orientados para reunir a un grupo, a fin de que resuelva un problema con la ayuda de varios apoyos como votaciones, cuestionarios, aportacin de ideas y creacin de escenarios. Sistemas de apoyo a ejecutivos. Cuando los ejecutivos se acercan a la computadora, frecuentemente estn buscando formas que les ayuden a tomar decisiones a nivel estratgico. Un sistema de apoyo a ejecutivos (ESS) ayuda a stos, para organizar sus interacciones con el ambiente externo, proporcionando apoyo de grficos y comunicaciones en lugares accesibles tales como salas de juntas u oficinas personales corporativas.

En la figura se muestran la diversidad de sistemas de informacin que pueden desarrollar los analistas. Observe que la figura presenta estos sistemas de abajo hacia arriba, indicando que el nivel operacional, o ms bajo, de la organizacin est apoyado por el TPS, y el ms alto o estratgico, el de las decisiones semiestructuradas o sin estructura, est apoyado por el ESS en la parte ms alta. Este texto usa los trminos sistema de informacin gerencias, sistema de informacin, sistema de informacin computarizada y sistema de informacin de negocios computarizado en forma indistinta para referirse a sistemas de informacin computarizada que dan soporte al rango ms amplio de actividades de negocios por medio de la informacin que producen. La necesidad del anlisis y diseo de sistemas. El anlisis y diseo de sistemas, tal como es ejecutado por los analistas de sistemas, busca analizar sistemticamente la entrada de datos o el flujo de datos, el proceso o transformacin de los datos, el almacenamiento de datos y la salida de informacin dentro del contexto de un negocio particular. Adems, el diseo y anlisis de sistemas es usado para analizar, disear e implementar mejoras en el funcionamiento de los negocios que pueden ser logradas por medio del uso de sistemas de informacin computarizados. La instalacin de un sistema sin la planeacin adecuada lleva a grandes frustraciones, y frecuentemente causa que el sistema deje de ser usado. Usuarios finales. Cualquiera que interacte con un sistema de informacin en el contexto de su trabajo en la organizacin puede ser llamado un usuario final. A lo largo de los aos se han hecho borrosas las distinciones entre usuarios. Adems, cualquier categora de usuarios empleada no debe ser vista como excluyente. Sin importar cmo se hayan clasificado los usuarios finales, un hecho es

pertinente al analista de sistemas: el involucramiento del usuario a lo largo del proyecto, es crtico para el desarrollo exitoso de los sistemas de informacin computarizados. Los analistas de sistemas, cuyos papeles dentro de la organizacin se tratan a continuacin, son el otro componente esencial para el desarrollo de sistemas de informacin. c) EL PAPEL DE EL ANALISTA DE SISTEMAS El analista de sistemas como consultor. El analista de sistemas frecuentemente acta como consultor y, por lo tanto, puede ser contratado especficamente para que se encargue de los asuntos de los sistemas de informacin 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 organizacin. Pero tambin puede decirse que los analistas externos estn en desventaja, debido a que la verdadera cultura organizacional nunca puede ser conocida por un extrao. 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 pequeas modificaciones o decisiones que afectan a un solo departamento. El analista de sistemas como agente de cambio. El papel ms 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 seccin) y se est presente en el negocio por un periodo extendido (desde dos semanas hasta ms de un ao). 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.

Identificacin de problemas, oportunidades y objetivos. En la primera fase del ciclo de vida del desarrollo de sistemas el analista tiene que ver con la identificacin de problemas, oportunidades y objetivos. Esta etapa es crtica 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 dems miembros de la organizacin, el analista hace resaltar los problemas. Frecuentemente estos ya han sido vistos por los dems, y son la razn

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, sumarizacin del conocimiento obtenido, estimacin del alcance del proyecto y documentacin de los resultados. La salida de esta fase es un estudio de factibilidad que contiene una definicin del problema y la sumarizacin de los objetivos. Luego los administradores deben tomar una decisin para ver si continan con el proyecto propuesto. Determinacin de los requerimientos de informacin. Entre las herramientas utilizadas para definir los requerimientos de informacin en el negocio se encuentran: muestreo e investigacin de los datos relevantes, entrevistas, cuestionarios, el comportamiento de los tomadores de decisiones y su ambiente de oficina y hasta la elaboracin de prototipos. En esta fase el analista est esforzndose por comprender qu informacin necesitan los usuarios para realizar su trabajo. Las personas involucradas en esta fase son los analistas y los usuarios, tpicamente los administradores de las operaciones y los trabajadores de las operaciones. Anlisis de las necesidades del sistema. La siguiente fase que realiza el analista de sistemas involucro el anlisis de las necesidades del sistema. Nuevamente, herramientas y tcnicas 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 grfica 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 alfanumricos y qu tanto espacio ocupan cuando se imprimen. Durante esta fase el analista de sistemas tambin analiza las decisiones estructuradas que se hacen. Las decisiones estructuradas son aquellas para las que pueden ser determinadas las condiciones como alternativas de condicin, acciones y reglas de accin. Hay tres mtodos principales para el anlisis de decisiones estructurales: lenguaje estructurado, tablas de decisin y rboles de decisin. Diseo del sistema recomendado. En esta fase del ciclo de vida del desarrollo de sistemas, el analista usa la informacin recolectada anteriormente para realizar el diseo lgico del sistema de informacin. El analista disea procedimientos precisos para la captura de datos, a fin de que los datos que van a entrar al sistema de informacin sean correctos. Adems, el analista tambin proporciona entrada efectiva para el sistema de informacin mediante el uso de tcnicas para el buen diseo de formas y pantallas. Desarrollo y documentacin 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 tambin trabaja con los usuarios para desarrollar documentacin efectiva para el software, incluyendo manuales de procedimientos. La documentacin le dice al usuario la manera de usar el software y tambin qu hacer si se suceden problemas con el software. Pruebas y mantenimiento del sistema. Antes de que pueda ser usado, el sistema de informacin 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 documentacin comienza en esta fase y es efectuado rutinariamente a lo largo de la vida del sistema de informacin. Implementacin y evaluacin del sistema. En esta fase del desarrollo del sistema el analista ayuda a implementar el sistema de informacin. Esto incluye el entrenamiento de los usuarios para que manejen el sistema. Algn entrenamiento es hecho por los proveedores, pero la supervisin del entrenamiento es responsabilidad del analista de sistemas. Adicionalmente, el analista necesita un plan para una conversin suave del sistema antiguo al nuevo. La evaluacin se muestra como parte de esta fase final de ciclo de vida del desarrollo del sistema, principalmente para efectos de discusin. De hecho, la evaluacin se realiza durante cada fase. Un criterio principal que debe ser satisfecho es si los usuarios pretendidos ya estn usando el sistema. La importancia del mantenimiento. Despus 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 instalacin MIS tpica. 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 "anomalas 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 razn 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 caractersticas adicionales despus de que se familiarizan con el sistema de cmputo y sus capacidades. Estas caractersticas 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 travs del tiempo. Se debe modificar el software para abarcar cambios tales como nuevos requerimientos de reportes gubernamentales o corporativos, la necesidad de producir nueva informacin para clientes, etctera. 3. El hardware y software estn cambiando a un ritmo acelerado. Un sistema que usa tecnologa antigua puede ser modificado para usar las capacidades de una tecnologa ms nueva. Un ejemplo de tal cambio es el reemplazo de una Terminal de macrocomputadora con una estacin 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 dlares 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 ms conveniente realizar un nuevo estudio del sistema, debido a que el costo de mantenimiento continuado es claramente mayor que la creacin de un sistema de informacin completamente nuevo. Resumiendo, el mantenimiento es un proceso continuo a lo largo del ciclo de vida de un sistema de informacin. Despus de que es instalado el sistema de informacin, el mantenimiento por lo general toma la forma de correccin 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 eliminacin de unos cuantos errores no detectados anteriormente y la actualizacin del sistema con una cuantas mejoras menores. Sin embargo, conforme pasa el tiempo y cambia el negocio y la tecnologa, los esfuerzos de mantenimiento se incrementan dramticamente. e) USO DE LAS HERRAMIENTAS CASE. A lo largo de este libro enfatizamos la necesidad de un enfoque sistemtico y profundo al anlisis, diseo e implementacin de los sistemas de informacin. Reconocemos que para ser productivos los analistas de sistemas debe ser organizado, preciso y completo en lo que se proponen hacer. En los ltimos aos los analistas han comenzado a beneficiarse de nuevas herramientas de productividad que han sido creadas implcitamente para mejorar su trabajo rutinario mediante un apoyo automatizado. A estas se les llama herramientas CASE, que significa herramientas para ingeniera de software asistido por computadora. Los analistas se apoyan en las herramientas CASE para aumentar la productividad, comunicarse ms 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 fcilmente. Por nuestra definicin, el analista puede entonces llegar a ser ms productivo simplemente por la reduccin del tiempo considerable que es gastado tpicamente en el trazo manual de diagramas de flujo de datos hasta que son aceptados.

Mejora de la comunicacin del analista-usuario. Para que el sistema propuesto se convierta en realidad y sea usado de hecho, es esencial una comunicacin excelente entre los analistas y usuarios a lo largo del ciclo de vida del desarrollo del sistema. El xito de una eventual implementacin 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 comunicacin mayor y ms significativa entre usuario y analistas. Integracin de las actividades del ciclo de vida La tercera razn 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 retroalimentacin y modificacin. Evaluacin precisa de los cambios del mantenimiento La cuarta razn, y posiblemente una de las ms 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 tamao de un elemento, tal como un nmero de cliente, necesite ser agrandado. 2. COMPRENSIN DE LOS ESTILOS ORGANIZACIONALES Y SU IMPACTO SOBRE LOS SISTEMAS DE INFORMACIN a) FUNDAMENTOS ORGANIZACIONALES Para analizar y disear adecuadamente los sistemas de informacin, el analista de sistemas necesita comprender las organizaciones en que trabaja como sistemas conformados por la interaccin de tres fuerzas principales: los niveles de administracin, el diseo de la organizacin 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 (operacin, administracin media y administracin estratgica) y que cortan horizontalmente a travs 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 diseados para lograr metas y objetivos predeterminados por medio de la gente y otros recursos que emplean. Las organizaciones estn compuestas de sistemas ms pequeos interrelacionados (departamentos, unidades, divisiones, etc.) que sirven a funciones especializadas. La interrelacin e interdependencia de los sistemas

Todos los sistemas y subsistemas estn 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, tambin son impactados el resto de los elementos y subsistemas del sistema. Retroalimentacin del sistema para planeacin y control La retroalimentacin es una forma de control del sistema. Como sistemas, todas las organizaciones usan planeacin y control para administrar sus recursos en forma efectiva. Ambientes para sistemas organizacionales La retroalimentacin es recibida desde el interior de la organizacin y del ambiente exterior que la rodea. Cualquier cosa que est fuera de las fronteras de una organizacin es considerada como un ambiente. Varios ambientes, con diversos grados de estabilidad, constituyen el medio ambiente en donde existe la organizacin. Aunque se pueden planear cambios en el estado del ambiente, frecuentemente no pueden ser controlados directamente por la organizacin. Apertura y restrictividad en las organizaciones La apertura y restrictividad existen en forma continua, ya que no hay una cosa tal como una organizacin absolutamente abierta o totalmente cerrada. La apertura se refiere al libre flujo de informacin dentro de una organizacin. Los subsistemas tales como los departamentos creativos o artsticos frecuentemente son caracterizados como abiertos, con un flujo libre de ideas entre sus participantes y muy pocas restricciones sobre quin obtiene tal informacin 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 planeacin muy confidencial que afecta la seguridad nacional. Cada persona necesita recibir acreditacin, la informacin en su momento es una necesidad y el acceso a la informacin se da con base en la que "es necesario saber". Este tipo de unidad est limitada por muchas reglas. Cmo tomar una perspectiva de sistemas La toma de una perspectiva de sistemas permite a los analistas de sistemas iniciar la clarificacin y comprensin de los diversos negocios con los que entrarn en contacto. Es importante que los miembros de subsistemas se den cuenta que su trabajo est interrelacionado. REPRESENTACIN GRFICA DE SISTEMAS Un sistema o subsistema, tal como existe dentro de la organizacin corporativa, puede ser representado grficamente en varias formas. Los diversos modelos grficos muestran las fronteras del sistema y la informacin 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 (tambin 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 bsicos de todo programa de computadora pueden ser descritos a detalle y usados para analizar el problema con respecto a su precisin y totalidad. El diagrama a nivel de contexto emplea solamente tres smbolos: (1) un rectngulo 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 informacin 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 informacin de sistema pero que no es parte del sistema. Esta entidad puede ser una persona, un grupo de personas, una posicin corporativa o departamento u otros sistemas. Las lneas 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 bsicos de un sistema de Reservaciones de una lnea area.

El pasajero (una entidad) inicia una peticin 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 envan las preferencias del pasajero y los vuelos disponibles al agente de viajes, que enva de regreso al proceso informacin sobre los boletos. Tambin podemos ver que la reservacin del pasajero es enviada a la lnea area. Los sistemas y el modelo entidad-relacin Una manera en que un analista de sistemas puede definir las fronteras adecuadas del sistema es usar un modelo entidad-relacin. 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 lnea area, un destino o un avin. En forma alterna, una entidad puede ser un evento, tal como el fin de mes, un periodo de ventas o la falla de una mquina. Una relacin es la asociacin que describe la interaccin entre las entidades. El formato estndar para trazar un diagrama entidad-relacin (o E-R),

Mostrado en la figura, usa solamente dos smbolos: un rectngulo y un rombo. El rectngulo es usado para mostrar una entidad, y el rombo representa la relacin 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 relacin uno a uno (1:1). Aqu a cada EMPLEADO le es asignada solamente una EXTENSIN TELEFNICA, y cada EXTENSIN TELEFNICA es nica para cada EMPLEADO. El segundo diagrama muestra una relacin 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 relacin uno a muchos (1:M). Por ltimo, el cuarto diagrama muestra una relacin muchos a muchos (M:N). Un VUELO puede llevar muchos PASAJEROS y un PASAJERO puede tener muchos VUELOS en su itinerario. Los diagramas entidadrelacin son usados frecuentemente por los diseadores de sistemas para ayudar a modelar el archivo o base de datos. Sin embargo, es todava ms 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 bsicos el analista necesita: 1. Listar las entidades de la organizacin para obtener una mejor comprensin de la organizacin. 2. Escoger entidades clave para estrechar el alcance del problema a dimensiones manejables y significativas. 3. Identificar cul debe ser la entidad primaria. 4. Confirmar los resultados de los pasos 1 a 3 por medio de otros mtodos de recoleccin de datos (investigacin, entrevistas, administracin de cuestionarios, observacin y elaboracin de prototipos). NIVELES DE ADMINISTRACIN La administracin existe en las organizaciones en tres amplios niveles horizontales: control operacional, planeacin y control administrativo y administracin estratgica, 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. Administracin de operaciones El control operacional forma el nivel inferior de la administracin 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 ms claro, debido al alto nivel de certeza en su ambiente de toma de decisiones. Administracin media La administracin media forma el nivel segundo, o intermedio, del sistema de administracin de tres niveles. La administracin media realiza decisiones de planeacin y control a corto plazo sobre

la manera en que son mejor asignados los recursos para satisfacer los objetivos organizacionales. La administracin media experimenta muy poca certeza en su ambiente de toma de decisiones. Administracin estratgica La administracin estratgica comprende el tercer nivel del control administrativo de tres niveles. Los administradores estratgicos ven fuera de la organizacin hacia el futuro, tomando decisiones que guiarn a los administradores medios o de operacin en los meses y aos por venir. Los administradores estratgicos trabajan en un ambiente de toma de decisiones altamente incierto. Implicaciones para el desarrollo de sistemas de informacin Cada uno de los tres niveles de administracin tiene diferentes implicaciones para el desarrollo de sistemas de informacin para la administracin. Algunos de los requerimientos de informacin para los administradores estn bien definidos y, en cambio, otros son difusos y se traslapan. Los administradores de operaciones necesitan informacin interna que es, por naturaleza, de bajo nivel y repetitiva. Tienen gran dependencia sobre la informacin que captura el desempeo actual y son grandes usuarios de recursos de informacin en lnea de tiempo real. La necesidad de los administradores de operaciones de informacin sobre el desempeo pasado y la informacin peridica es solamente moderada. Ellos tienen poco uso para informacin externa que les permita proyecciones futuras o creacin de escenarios "qu pasa si". En el siguiente nivel de administracin, la administracin media, que tanto planea como controla, se necesita informacin de corto y largo plazo. Debido a la naturaleza de su trabajo de resolver problemas, los administradores medios experimentan necesidades extremadamente altas de informacin en tiempo real. Para poder controlar adecuadamente tambin necesitan informacin actual del desempeo medido en comparacin a juegos de estndares. Los administradores estratgicos (difieren, en buena medida, de los administradores medios y de operaciones en sus requerimientos de informacin. Son altamente dependientes de informacin 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 administracin estratgica demanda proyecciones hacia un futuro incierto, los administradores estratgicos tienen una gran necesidad de informacin de naturaleza predictiva e informacin que les permita la creacin de muchos escenarios "qu pasa si". Los administradores estratgicos tambin muestran grandes necesidades de informacin reportada peridicamente cuando buscan adaptarse a cambios rpidos. Los planeadores estratgicos necesitan informacin general resumida, en vez de los datos burdos altamente detallados requeridos por los administradores de bajo nivel. La informacin para los planeadores estratgicos puede ser ms antigua y estimada y, en cambio, los administradores operacionales necesitan informacin precisa y actual.

Por ltimo, el planeador estratgico necesita informacin cualitativa, principalmente de fuentes externas, en vez de la informacin cuantitativa de fuentes internas requerida por la administracin de operaciones. 3. DETERMINACIN DE LA FACTIBILIDAD Y EL MANEJO DE LAS ACTIVIDADES DE ANLISIS Y DISEO Los cuatro puntos principales que el analista de sistemas debe manejar son: a) Iniciacin del proyecto, b) Determinacin de la factibilidad del proyecto, c) Calendarizacin del proyecto, y, d) Administracin de los miembros del equipo del anlisis del sistema. El revisar la salida, la observacin del comportamiento de los empleados y el escuchar la retroalimentacin, son maneras que ayudarn 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 seleccin de un proyecto es una decisin difcil, debido a que sern solicitados ms proyectos de los que pueden ser hechos. Cinco criterios importantes para la seleccin de proyectos son: a) Que el proyecto solicitado est respaldado por la administracin, b) Que tenga el tiempo adecuado para la asignacin de recursos, c) Que mueva al negocio hacia la obtencin 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 mritos operacionales, tcnicos y econmicos. Por medio de este estudio los analistas de sistemas recopilan datos que permiten a la administracin decidir si continan con un estudio de sistema completo. La planeacin del proyecto incluye la estimacin del tiempo requerido por cada una de las actividades del analista, su calendarizacin y la agilizacin de ellas, si es necesario, para asegurar que un proyecto sea terminado a tiempo. Una tcnica de que dispone el analista de sistemas para la calendarizacin de tareas es la grfica de Gantt, la cual despliega actividades en forma de barras en una grfica. La calendarizacin de proyectos basada en computadora, es ahora una prctica comn, debido principalmente al uso de interfaces de usuario grficas. Adicionalmente, se pueden

usar los administradores de informacin personales (PIM) por los analistas para planear, crear depsitos de nmeros telefnicos y de fax y hasta ejecutar otros programas. Una segunda tcnica, llamada PERT (evaluacin de programas y tcnicas de revisin), despliega las actividades como flechas en una red. El PERT ayuda a que el analista determine la ruta crtica y el tiempo de holgura, que es la informacin requerida para el control efectivo del proyecto. Cuando es necesario terminar un proyecto en menor tiempo, el analista puede reducir la duracin 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 comunicacin con los miembros del equipo. Los equipos estn 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 lderes en un equipo, un lder de tarea y un lder socioemocional. Los miembros deben valorar peridicamente 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 anlisis 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 Anlisis de los requerimientos de informacin 4. MUESTREO E INVESTIGACIN DE DATOS IMPRESOS. El proceso de seleccionar sistemticamente elementos representativos de una poblacin es llamado muestreo. El objeto del muestreo es seleccionar y estudiar documentos, tales como facturas, reportes de ventas y memorndums, o tal vez seleccionar y entrevistar, dar cuestionarios u observar a miembros de la organizacin. El muestreo puede reducir costos, velocidad de recoleccin de datos, hacer potencialmente que el estudio sea ms 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 diseo de una buena muestra. Primero, se tiene la necesidad de determinar la poblacin misma. Segundo, se debe decidir el tipo de muestra. Tercero, se debe calcular el tamao de muestra. Por ltimo, se deben planear los datos que necesitan ser recolectados o descritos. Tipos de informacin buscada en la investigacin Los tipos de muestras tiles para un analista de sistemas son: de conveniencia, intencionada, aleatoria simple y aleatoria compleja. El ltimo tipo incluye las subcategoras de muestreo sistemtico y muestreo estratificado. Hay varios lineamientos a seguir para la determinacin del tamao de muestra. El analista de sistemas puede hacer una decisin subjetiva en relacin con el estimado de

intervalo aceptable. Luego se selecciona un nivel de confianza y puede ser calculado el tamao de muestra necesario. El analista de sistemas necesita investigar datos relevantes, incluyendo reportes, documentos, estados financieros, manuales de procedimientos y memorndums. Los datos relevantes muestran dnde ha estado la organizacin y hacia dnde creen sus miembros que estn yendo. Es necesario que sean analizados documentos cuantitativos y cualitativos. Debido a que los documentos son mensajes persuasivos, debe ser reconocido que el cambiarlos tambin puede cambiar a la organizacin. Las consignas que se colocan revelan la cultura oficial de la organizacin Hay muchas formas de analizar documentos cuantitativos y cualitativos. Sin embargo, es importante recordar que la investigacin de los datos archivados tiene ventajas y desventajas. Debido a que muchas de las desventajas pueden ser superadas, vale la pena la investigacin 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 mtodo que usa el analista de sistemas para la recoleccin de datos sobre los requerimientos de informacin. El analista de sistemas escucha buscando objetivos, sentimientos, opiniones y procedimientos informales en entrevistas con los tomadores de decisiones de la organizacin. Tambin vende el sistema durante las entrevistas. Las entrevistas son dilogos de preguntas respuestas planeados por anticipado entre dos personas. Hay cinco pasos que deben tomarse para la planeacin previa de la entrevista: 1. Lectura de material de fondo 2. Establecimiento de objetivos de la entrevista 3. Decisin de a quin entrevistar 4. Preparacin del entrevistado 5. Decisin sobre el tipo y estructura de las preguntas Las preguntas tienen dos tipos bsicos: 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 ms detallada. Las entrevistas pueden estar estructuradas en tres formas bsicas, estructura de pirmide, de embudo o de rombo. Las estructuras piramidales comienzan con preguntas cerradas y detalladas y se amplan a preguntas ms generales. Las estructuras de embudo comienzan con preguntas abiertas generales y luego se estrechan a preguntas cerradas ms especficas. Las estructuras de rombo combinan las fuerzas de las otras dos estructuras pero se llevan ms tiempo para realizarse. Hay compromisos involucrados sobre la decisin de cmo 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. Despus 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 ms pronto posible despus de que haya sido realizada. Para reducir tanto el tiempo como el costo de las entrevistas personales, los analistas pueden considerar el diseo conjunto de aplicaciones (JAD) como una alternativa. Mediante el uso del JAD los analistas logran tanto el anlisis de requerimientos como el diseo de la interfaz de usuario con los usuarios en un lugar de reunin de grupo. La valoracin cuidadosa del lugar de reunin para la organizacin 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 caractersticas de gentes importantes en la organizacin. Los cuestionarios son tiles s: las personas de la organizacin estn ampliamente dispersas, muchas gentes estn involucradas con el proyecto de sistema, se necesita un trabajo exploratorio antes de recomendar alternativas o hay una necesidad para la sensibilizacin 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 seleccin de la redaccin es extremadamente importante y debe reflejar el lenguaje de los miembros de la organizacin. Idealmente, las preguntas deben ser simples, especficas, sin ascendencia, sin menosprecio, tcnicamente precisas y dirigidas a aquellos que tienen el conocimiento. La asignacin de escalas es el proceso de asignar nmeros u otros smbolos a un atributo o caracterstica. Tal vez quiera el analista de sistemas usar escalas para medir las actitudes o las caractersticas de los interlocutores o para hacer que los interlocutores acten como jueces sobre el tema del cuestionario. Las cuatro formas de medicin son escalas nominales, ordinales, de intervalo y de relacin. La forma de medicin es frecuentemente indicada por los datos, y el anlisis de los datos es a su vez indicado en alguna medida por la forma de medicin. Los analistas de sistemas necesitan tomar en consideracin 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. OBSERVACIN DEL COMPORTAMIENTO DE LOS TOMADORES DE DECISIONES Y EL AMBIENTE DE OFICINA. Los analistas usan la observacin como una tcnica de recopilacin de ir, formacin. Por medio de la observacin obtienen apreciaciones sobre lo que se hace realmente, ven de primera mano las relaciones entre los tomadores de decisiones en una organizacin, comprenden la influencia del ambiente fsico 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 dems. Usando el muestreo de tiempos o eventos, el analista observa las actividades tpicas del tomador de decisiones y su lenguaje corporal. Hay varios sistemas para registrar tales observaciones, incluyendo sistemas di categoras, listas de verificacin, escalas, notas de campo y guiones. Adems de la observacin del comportamiento del tomador de decisiones, el analista de sistemas debe observar tambin lo que le rodea. Un mtodo para la observacin estructurado del ambiente es llamado STROBE, Un analista de sistemas usa STROBE en la misma forma que un crtico de cine usa un mtodo llamado mise-en-scne para analizar una toma de una pelcula Varios elementos concretos del ambiente del tomador de decisiones pueden ser observados e interpretados. Estos elementos incluyen (1) la ubicacin de la oficina, (2) la ubicacin 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 peridicos, (6) iluminacin y color de la oficina y (7) la vestimenta usada por el tomador de decisiones. Se puede usar STROBE para obtener una mejor comprensin sobre la manera en que los tomadores de decisiones actualmente recopilan, procesan, guardan y comparten informacin, Hay varias alternativas para la aplicacin de STROBE en una organizacin. Estas incluyen el anlisis de fotografas, el uso de una lista de verificacin con base en la escala Likert, la adopcin de una lista anecdtica con smbolos y la simple escritura de una comparacin de observacin/narrativa, Cada mtodo tiene determinadas ventajas, as como desventajas, que el analista debe sopesar cuando seleccione una alternativa sobre la otra. 8. PROTOTIPOS. La elaboracin de prototipos es una tcnica de recopilacin de informacin 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 revisin del usuario para hacer mejoras al prototipo y, por lo tanto, modificar los planes del sistema con un mnimo 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 elaboracin de prototipos. El trmino prototipo tiene diferentes significados, de los cuales son comnmente usados cuatro de ellos. La primera definicin de la elaboracin de prototipos es la de construccin de un prototipo parchado. Una segunda definicin es un prototipo no operacional que es usado para probar determinadas caractersticas del diseo. Un tercer concepto es la creacin de un prototipo primero de la serie que es completamente operacional. Este tipo de prototipo es til cuando estn

planeadas muchas instalaciones del mismo sistema de informacin (bajo condiciones similares). El cuarto tipo es un prototipo con caractersticas seleccionadas que tiene algunas, pero no todas, de las caractersticas esenciales del sistema. Usa mdulos autocontenidos como bloques de construccin, para que si las caractersticas prototpicas son satisfactorias puedan ser conservadas e incorporadas en el sistema terminado mucho ms grande. Los cuatro lineamientos principales para el desarrollo de un prototipo son: (1) trabajar en mdulos manejables, (2) construir el prototipo rpidamente, (3) modificar el prototipo y (4) enfatizar la interfaz de usuario. Una desventaja de los prototipos es que el manejo del proceso de elaboracin del prototipo es difcil, 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 elaboracin 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 elaboracin de prototipos. Su primer inters debe ser interactuar con el prototipo mediante experimentacin. Los analistas de sistemas deben trabajar sistemticamente 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 anlisis 9. USO DE DIAGRAMAS DE FLUJO DE DATOS Para comprender mejor el movimiento lgico de los datos en un negocio, el analista de sistemas traza diagramas de flujo de datos (DFD). Los diagramas de flujo de datos son anlisis estructurados y herramientas de diseo que permiten que el analista comprenda visualmente el sistema y subsistemas como un juego de flujos de datos interrelacionados.

La representacin grfica del movimiento, almacenamiento y transformacin de datos es trazada con el uso de cuatro smbolos: un rectngulo 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 rectngulo de extremo abierto para mostrar un almacn 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 ms grande. Luego es trazado un diagrama de flujo de datos lgico a nivel 0. Se muestran los procesos y se aaden 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 explosin del diagrama de flujo original permite que el analista de sistemas se enfoque en las representaciones cada vez ms detalladas de los movimientos de datos dentro del sistema. Luego, el analista desarrolla un diagrama de flujo de datos fsico a partir del diagrama de flujo de datos lgico, particionndolo para facilitar la programacin. 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 diseados para ser por lotes o en lnea. Seis consideraciones para particin 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 nmina.

Las ventajas de los diagramas de flujo de datos incluyen la simplicidad de la notacin, usndola para obtener informacin ms clara de los usuarios, permitiendo que el analista de sistemas conceptualice los flujos de datos necesarios sin estar atado a una implementacin fsica 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. Caractersticas comunes de los diagramas de flujo de datos lgicos y fsicos.

El diagrama de flujo de datos fsico (abajo) muestra determinados detalles que no se encuentran en el diagrama de flujo de datos lgico (arriba). 10. ANLISIS 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 compilacin 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 lgicos y fsicos 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 coleccin grande de la informacin de proyecto es llamada un depsito. Las herramientas CASE permiten que el analista cree un depsito, que puede incluir informacin acerca de los flujos, almacenes, estructuras de registro y elementos de datos, la lgica de procedimiento de diseos de pantalla y reporte, relaciones de datos, requerimientos del proyecto y lo que produce el sistema final e informacin sobre la administracin de proyecto. Cada entrada del diccionario de datos contiene: el nombre del concepto, una descripcin verbal, alias, elementos de datos relacionados, rango, longitud, codificacin y la informacin de edicin necesaria. El diccionario de datos es til en todas las fases del anlisis, diseo y documentacin 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 produccin de un cheque de pago a un empleado. 11. DESCRIPCIN 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 anlisis de decisiones. Los tres mtodos para el anlisis de decisiones y la descripcin de la lgica de proceso tratados en este captulo son: lenguaje estructurado, tablas de decisin y rboles de decisin. 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 lgica de toma de decisiones y las frmulas que transformarn los datos de entrada al proceso en salida. Los tres objetivos de la especificacin de proceso son: reducir la ambigedad de los procesos, obtener una descripcin precisa de lo que se logra y validar el diseo 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 decisin que est siendo examinada: condiciones, alternativas de condicin, acciones y reglas de accin.

Una forma para describir las decisiones estructuradas es usar el mtodo mencionado como lenguaje estructurado, donde la lgica es expresada en estructuras secuenciales, estructuras de decisin, 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 lgica usada y usa sangras para indicar la estructura jerrquica del proceso de decisin. Las tablas de decisin 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 decisin posibles (tales como S o N), (3) indicar cules acciones deben ser ejecutadas y (4) describir las acciones. Las tablas de decisin 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 decisin promueve la integridad y precisin en el anlisis de decisin estructuradas. El tercer mtodo para el anlisis de decisiones es el rbol de decisin que consiste de nodos (un cuadrado para acciones y un crculo para condiciones) y ramas. Los rboles de decisin son adecuados cuando se deben realizar acciones en una secuencia determinada. No hay requerimientos de que el rbol tenga que ser simtrico, por lo que solamente se encuentran en una rama particular aquellas condiciones y acciones que son crticas para las decisiones presentes. Cada uno de los mtodos de anlisis de decisin 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 comunicacin con otros. Las tablas de decisin proporcionan anlisis completo de situaciones complejas y a la vez limitan la necesidad por cambios atribuibles a situaciones imposibles, redundancias o contradicciones. Los rboles de decisin son importantes cuando es crtica la secuencia adecuada de condiciones y acciones y cuando cada condicin no es relevante para cada accin. Cada proceso del diagrama de flujo de datos se expande a un diagrama hijo, a una grfica de estructura o a una especificacin de proceso (tal como el lenguaje estructurado). Si el proceso es primitivo las especificaciones muestran la lgica, aritmtica o algoritmos para transformar la entrada en la salida. Estas especificaciones del modelo lgico son parte de las reglas del negocio (que son usadas frecuentemente como la base para crear lenguajes procedurales cuando se usa generadores de cdigo). Si el proceso se expande a un diagrama hijo o a una grfica de estructura, la especificacin de proceso describe el orden y condiciones bajo los cuales ejecutarn los procesos del diagrama hijo. Esta lgica de control es parte del modelo fsico. 12. ANLISIS DE SISTEMAS DE APOYO A DECISIONES SEMIESTRUCTURADAS. Los sistemas de apoyo a decisiones (DSS) son una clase especial de sistemas de informacin que enfatizan el proceso de toma de decisiones y cambian a los usuarios del DSS por medio de su interaccin con el sistema. Los sistemas de apoyo a decisiones estn bien adecuados para resolver problemas semiestructurados, donde el discernimiento humano todava es deseado o requerido.

Los sistemas de apoyo a decisiones no dan una solucin 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 tcnicas de modelado. Los usuarios del DSS o de los sistemas de apoyo a decisin en grupo (GDSS), vienen de todos los tres niveles administrativos de la organizacin. Sin embargo, las decisiones semiestructuradas son requeridas ms frecuentemente por los niveles administrativos medio y estratgico. Los usuarios de un DSS son eventualmente cambiados por medio del proceso de interaccin con el sistema. El estilo de toma de decisiones de los usuarios puede ser categorizado como analtico o heurstico. Los tomadores de decisiones analticos tienden a dividir los problemas en componentes cuantitativos y usan modelos matemticos para tomar una decisin y, en cambio, los tomadores de decisiones heursticos se apoyan en la experiencia. Los sistemas de apoyo a decisiones pueden ser diseados pensando en el estilo predominante del tomador de decisiones, para que a los pensadores analticos se les proporcionen modelos cuantitativos y a los tomadores de decisiones heursticos se les proporcione informacin resumida y ayudas de memoria que les permitan recordar cmo usaron la heurstica en el pasado. Las decisiones semiestructuradas son aquellas en las que el discernimiento humano todava 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 decisin y poder tomar sta. Tambin, si un problema es demasiado complejo es clasificado como semiestructurado. Por ltimo, un problema puede ser llamado semiestructurado si deben ser atacados criterios mltiples. Los sistemas de apoyo a decisiones estn especialmente bien indicados para ayudar a resolver problemas semiestructurados. En todas las soluciones de problemas los tomadores de decisiones recorren tres fases: inteligencia, seleccin y diseo. 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 diseo consiste en la articulacin del problema u oportunidad, descubriendo y creando alternativas, evalundolas y examinando sus aplicaciones. La fase de seleccin est compuesta de la seleccin de una alternativa entre aquellas que han sido consideradas y la determinacin de razones y argumentos para la adopcin de esa solucin. Los sistemas de apoyo a decisiones deben ser diseados para dar soporte a decisiones en las tres fases de la solucin de problemas. Un sistema de apoyo a decisiones completo debe ser capaz de dar apoyo a la toma de decisiones de criterios mltiples. El tomador de decisiones que usa este tipo de DSS tiene un gran repertorio de mtodos disponibles, incluyendo un proceso de pro y contra, mtodos ponderados, eliminacin secuencias por lexicografa, eliminacin secuencias por restricciones conjuntivas y la programacin por metas. 13. PREPARACIN DE LA PROPUESTA DE SISTEMAS. La evaluacin de hardware y software, identificacin y pronstico de costos y beneficios y la realizacin de anlisis de beneficio - costo son actividades necesarias que el analista de sistemas debe lograr para la preparacin del material para la propuesta de sistema. Los requerimientos de informacin ayudan a conformar qu software es comprado o codificado, as como qu hardware es necesario para realizar las funciones de transformacin 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 proyeccin necesaria para el hardware. Se pueden ejecutar cargas de trabajo de muestra en el hardware bajo consideracin. Aunque el equipo de cmputo cambia rpidamente, el procedimiento usado para la evaluacin del hardware no necesita cambiar. Mediante el inventariado del equipo que ya se tiene a la mano y pedido, los analistas de sistemas sern 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 proporcionarn servicios de apoyo, tales como mantenimiento preventivo y entrenamiento a usuarios, que son tpicamente negociados por aparte. Los paquetes de software tambin deben ser evaluados por el analista de sistemas y los usuarios pertinentes. Se puede ahorrar mucho tiempo de programacin si uno de estos paquetes es utilizable sin gran personalizacin. El software necesita ser evaluado sobre qu tan bien desarrolla las funciones deseadas, su facilidad de uso, adecuacin de la documentacin y servicios de apoyo que puedan ofrecer los vendedores. La preparacin de una propuesta significa la identificacin de todos los costos y beneficios de varias alternativas. El analista de sistemas tiene varios mtodos disponibles para pronosticar los costos, beneficios, volmenes de transacciones y variables econmicas futuras que afectan los costos y beneficios. Los costos y beneficios pueden ser tangibles (cuantificables) o intangibles (no cuantificables y resistentes a una comparacin directa). Un analista de sistemas tiene muchos mtodos para el anlisis de costos y beneficios. El anlisis de punto de equilibrio examina el costo del sistema existente contra el costo del sistema propuesto. El mtodo de recuperacin determina la cantidad de tiempo que transcurrir antes de que el nuevo sistema sea rentable. El anlisis de flujo de efectivo es adecuado cuando es crtico saber la cantidad de desembolsos de efectivo, y el valor presente toma en cuenta el costo de pedir dinero prestado. Estas herramientas ayudarn al analista a examinar las alternativas a la mano y tomar una recomendacin bien documentada sobre la propuesta de sistemas. Lineamientos para la evaluacin de software

14. ESCRITURA Y PRESENTACIN 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 crtico 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 ttulo adecuado que atrape el inters 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 pginas y mantenga al mnimo las referencias y los apndices. Mucho de lo que es importante en la propuesta de sistemas puede ser mejorado mediante el uso adecuado de figuras, incluyendo tablas y grficas. Las grficas comparan dos o ms variables a lo largo del tiempo o en un momento particular del tiempo. Las figuras siempre son acompaadas con una interpretacin escrita en la propuesta. Las grficas y tablas usadas para planeacin, anteriormente a la propuesta, pueden ser incorporadas a ella cuando sean relevantes. La presentacin verbal del sistema est basada en la propuesta escrita y es otra forma de vender eficientemente el sistema. Una opcin para la presentacin es crear una presentacin de transparencias usando software de presentacin. Tambin, los paquetes de presentacin grficos y el clipart pueden ser usados para mejorar la presentacin visual de la propuesta de sistemas. Lineamientos para la presentacin verbal efectiva de la propuesta de sistemas. Para dar una fuerte presentacin verbal, el analista debe conocer cuatro elementos por anticipado: quines compondrn la audiencia, el tema (presumiblemente la propuesta de sistemas o parte de ella), el tiempo asignado para la presentacin y el equipo disponible (incluyendo la disposicin de la sala). Los cuatro elementos estn interrelacionados y cada uno necesita ser analizado y planeado para asegurar el xito. UNIDAD IV Los puntos esenciales del diseo 15. DISEO DE SALIDA EFECTIVA La salida es cualquier informacin til o datos proporcionados por el sistema de informacin o, el sistema de apoyo a decisiones ante el usuario. La Salida puede tomar virtualmente cualquier forma, incluyendo la impresin, pantallas, audio, microformas, CD-ROM y electrnica. Estos disean la salida para que sirva al propsito 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 mtodo de salida adecuado. Es importante que el analista se d cuenta de que el contenido de la salida est relacionado con el mtodo de la salida. La salida de diferentes tecnologas afecta a los usuarios en formas diferentes. Las tecnologas de salida tambin difieren en su velocidad, costo, portabilidad, flexibilidad y posibilidades de almacenamiento y recuperacin. Todos estos factores deben ser considerados cuando se decide entre impresin, en pantalla, audio, microformas o salida electrnica, o una combinacin de estos mtodos de salida. La presentacin de la salida puede tergiversar la interpretacin que los usuarios hacen de ella. Los analistas deben estar conscientes de las fuentes de ascendencia, interactuar con los usuarios para disear 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 precisin de cualquier reporte particular. Los reportes impresos son diseados con el uso de hojas de diseo 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 diseo de reporte y se realiza cualquier cambio necesario. El analista de sistemas usa el diseo de hoja o pantalla para comunicar el diseo fsico 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 diseadas usando formas de diseo de reporte en pantalla. Nuevamente, la esttica y utilidad son importantes para crear una pantalla bien diseada. Es importante producir prototipos de pantallas que permitan que los usuarios hagan cambios donde deseen. La salida grfica en pantalla est llegando a ser cada vez ms utilizado, en especial para los sistemas de apoyo a decisiones. El analista de sistemas debe considerar los efectos de las grficas ante los usuarios, el tipo de datos debe ser desplegado, el objetivo de las grficas y su audiencia pretendida. Se dispone de muchos paquetes de software dedicados a los grficos. Es esencial que los tomadores de decisiones reciban entrenamiento sobre la forma de interpretar las grficas para que les sean tiles.

16. DISEO DE ENTRADA EFECTIVO. Este captulo trata a los elementos del diseo de entrada para formas y pantallas VDT. La entrada bien diseada debe satisfacer los objetivos de efectividad, precisin, facilidad de uso, consistencia y atractivo. El conocimiento de muchos elementos de diseo diferentes permitir que el analista de sistemas alcance estos objetivos. Los cuatro lineamientos para las formas de entrada bien diseadas son: 1. Las formas deben ser fciles de llenar. 2. Las formas deben satisfacer el propsito para el que fueron diseadas. 3. Las formas deben ser diseadas para asegurar su llenado preciso. 4. Las formas deben ser atractivas. El diseo 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 difcil obtener ayuda adicional para una forma. Los cuatro lineamientos para pantallas VDT bien diseadas son: 1. Las pantallas deben ser mantenidas simples. 2. Las pantallas deben ser consistentes de pantalla a pantalla.

3. El diseo de pantalla debe facilitar el movimiento entre pantallas. 4. Las pantallas deben ser atractivas. Muchos elementos de diseo 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 lgicamente la informacin en siete categoras y las pantallas deben ser divididas en tres secciones principales. Los ttulos en formas y pantallas pueden ser variados, tal como lo permita los tipos de letra y grosores de lnea que dividan las subcategoras de informacin, Las formas de varias copias son otra manera de asegurar que las formas satisfacen su propsito pretendido. Los diseadores pueden usar ventanas, preguntas, cuadros de dilogo y valores por omisin en pantalla para asegurar la efectividad del diseo. Hay muchas similitudes, pero algunas diferencias crticas, entre el diseo 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 carcter de atributo de campo que controla las cualidades de proteccin, intensidad, desplazamiento y atributos extendidos. El carcter de atributo debe ser tomado en cuenta cuando se disean pantallas para terminales de macrocomputadora. 17. DISEO DEL ARCHIVO O BASE DE DATOS. Cmo guardar datos es frecuentemente una decisin importante en el diseo de un sistema de informacin. Hay dos enfoques para el almacenamiento de datos. El primer enfoque es guardar los datos en archivos individuales y un archivo para cada aplicacin. 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 dramticas en el diseo de software de base de datos para aprovechar la interfaz grfica de usuario. El enfoque de archivo convencional puede ser, a veces, un enfoque ms eficiente, debido a que el archivo puede ser especfico de la aplicacin. Por otro lado, el enfoque de base de datos puede ser ms 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 caractersticas 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 numrico). Ejemplos de archivos convencionales incluyen archivos maestros, archivos de tabla, archivos de transaccin, archivos de trabajo y archivos de reporte. Pueden tener organizacin secuencias, listas encadenadas, organizacin de archivo de dispersin,

organizacin indexada u organizacin secuencias indexadas. Una forma ms moderna y eficiente para manejar archivos secuenciales indexados es el VSAM. Las bases de datos pueden tener estructura jerrquica, de red o relacionar. La normalizacin 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 normalizacin. Primero son eliminados todos los grupos repetidos. Segundo, son eliminadas todas las dependencias parciales. Por ltimo, son quitadas las dependencias transitivas. Despus de estos tres pasos, el resultado es la creacin de muchas relaciones que estn en la tercera forma normal (3NF). Se puede usar el diagrama entidad-relacin para determinar las llaves requeridas para un registro o relacin de base de datos. Los tres lineamientos a seguir cuando se disean 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 especfico debe existir solamente en un archivo maestro y (3) cada archivo maestro o relacin de base de datos debe tener programas para crear, leer, actualizar y borrar. El proceso de recuperacin de datos puede involucrar hasta ocho pasos: (1) la relacin o relaciones se seleccionan y (2) se unen; (3) se realizan la proyeccin y (4) seleccin sobre la relacin 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 desempeo y, por ltimo, (8) se presentan los resultados al usuario. 18. DISEO DE LA INTERFAZ DE USUARIO. En este captulo se ha enfocado en los usuarios del sistema, su interfaz con la computadora, su necesidad de retroalimentacin y el diseo de su estacin de trabajo. El xito del sistema que se disee depende del involucramiento y aceptacin del usuario. Por lo tanto, el pensar acerca de los usuarios en formas sistemticas y empticas es de gran importancia y no un asunto perifrico para los analistas de sistemas. En este captulo se trata varios tipos de interfaz de usuario y dispositivos de entrada. Algunas interfaces estn particularmente bien adaptadas para los usuarios sin

experiencia, tales como: lenguaje natural, pregunta y respuesta, mens, llenado de forma, interfaz grfica de usuario, el ratn, plumas pticas y pantallas sensibles al tacto. El lenguaje de comandos est mejor adecuado para los usuarios experimentados. La combinacin de interfaces puede ser extremadamente efectiva. Por ejemplo, el uso de mens desplegables con interfaces grficas de usuario, o el empleo de mens 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 ms difcil de programar. La retroalimentacin se usa de muchas formas. Tambin se enfatiza la necesidad de retroalimentacin a los usuarios por parte del sistema. Es necesaria la retroalimentacin 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 informacin ms detallada y cmo obtenerla. Tambin puede ser efectiva la retroalimentacin por audio. Las consultas estn diseadas para permitir a los usuarios extraer datos significativos de la base de datos. Hay seis tipos bsicos de consultas y pueden ser combinados usando lgica booleana para formar consultas ms complejas. Por ltimo, consideramos la manera en que los espacios de trabajo del usuario influencian su disponibilidad para el uso del sistema y cmo pueden ser mejoradas las estaciones de trabajo mediante la implementacin de principios ergonmicos relevantes. Hay lineamientos de productividad y confort especficos para la construccin 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. DISEO DE PROCEDIMIENTO PARA LA CAPTURA DE DATOS PRECISA. El aseguramiento de la calidad de los datos de entrada al sistema de informacin es crtico 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: codificacin efectiva, captura de datos efectiva y eficiente y validacin de los datos. Una de las mejores formas para agilizar la captura de datos es mediante el uso efectivo de la codificacin, que pone los datos en secuencias cortas de dgitos y/o letras. Se pueden usar cdigos de secuencia simple Y cdigos de derivacin alfabtica para seguir el avance de un concepto dado a travs del sistema. Los cdigos de clasificacin y los cdigos de secuencia en bloque son tiles para distinguir clases de artculos entre ellas. Los cdigos, tales como el cdigo de cifrado, tambin son tiles para ocultar informacin que es sensible o est restringida a determinadas personas dentro del negocio. La revelacin de informacin es tambin un uso de cdigos que vale la pena, debido a que permite que los empleados del negocio localicen conceptos en existencia y tambin puede hacer que la captura de datos sea ms significativa. Los cdigos de subconjuntos de dgito significativo usan subgrupos de dgitos para describir un producto. Los cdigos mnemnicos tambin revelan informacin, 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 informacin. Los cdigos 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 cdigos de funcin, y evitan el tener que decir a detalle qu acciones son necesarias. Otra parte para asegurar la captura de datos efectiva es la atencin a los dispositivos de entrada que se usan. El primer paso es una forma efectiva y bien diseada que sirva como documento fuente (cuando se necesita), Los datos pueden ser alimentados por medio de muchos mtodos diferentes, teniendo cada uno diferente velocidad y confiabilidad. Las mejoras en eficiencia sobre el teclado a cinta han sido realizadas por medio de la interaccin 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 tambin requiere menos habilidades de los empleados. Otros mtodos de captura de datos incluyen el reconocimiento de caracteres de tinta magntica usado por los bancos para codificar los nmeros de cuenta de los clientes, las formas de marcas sensibles usadas para alimentacin de gran cantidad de datos y las formas perforadas usadas en votaciones. Los cdigos de barras (aplicados a productos y luego digitalizados) tambin agilizan la captura de datos y mejoran la precisin y confiabilidad de los datos. Tambin estn siendo desarrolladas nuevas tecnologas de entrada, tales como las cmaras digitales. Las terminales inteligentes son dispositivos de entrada (frecuentemente basadas en microprocesador) con una VDT, teclado y enlace de comunicacin con la CPIJ. Permiten que se tecleen y completen transacciones en tiempo real. Junto con una codificacin adecuada, captura de datos y dispositivos de entrada, la captura de datos precisa puede ser mejorada mediante el uso de la validacin de la entrada. El analista de sistemas debe suponer que sucedern errores en los datos, y debe trabajar con los usuarios para disear pruebas de validacin de entrada para prevenir que sean procesados y almacenados datos errneos. Las transacciones de entrada deben ser revisadas para asegurar que la transaccin solicitada es aceptable, autorizada y correcta. Los datos de entrada pueden ser validados por medio de la inclusin 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 invlidos de los datos. Los datos de entrada tambin pueden ser comparados con datos almacenados para efectos de validacin. Una vez que los datos numricos son alimentados, pueden ser revisados y corregidos automticamente mediante el uso de dgitos de verificacin. 20. ASEGURAMIENTO DE LA CALIDAD POR MEDIO DE LA INGENIERA DE SOFTWARE. El analista de sistemas usa tres amplios enfoques para la administracin de calidad total (TQM) para analizar y disear sistemas de informacin: diseo de sistemas y software con un enfoque modular de arriba hacia abajo, diseo y documentacin de sistemas y software usando mtodos sistemticos, y pruebas de sistemas y software para que puedan ser fcilmente mantenidos y auditados. Los usuarios son de importancia crtica para el establecimiento y evaluacin de la calidad de varias dimensiones de los sistemas de manejo de informacin y los sistemas de apoyo a decisiones. Pueden estar involucrados en la evolucin completa de los sistemas mediante el establecimiento de fuerzas de tarea MIS o crculos de calidad.

La TQM puede ser implementada satisfactoriamente tomando un enfoque de arriba hacia abajo para el diseo. Esto se refiere a ver primero los objetivos organizacionales generales y luego descomponindolos en requerimientos de subsistemas manejables. El desarrollo modular hace que la programacin, depuracin y mantenimiento sean ms fciles de lograr. La programacin en mdulos 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 dinmico de datos) que comparte cdigo utilizando archivos de biblioteca de enlace dinmico (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 (vinculacin e inclusin de objetos). Este mtodo de enlace es superior al DDE para enlazar datos y grficos de aplicaciones, debido a su enfoque orientado a objetos. Una herramienta recomendada para el diseo de un sistema modular de arriba hacia abajo es llamada una grfica de estructura. Se usan dos tipos de flechas para indicar los tipos de parmetros que son pasados entre los mdulos. El primero es llamado un acople de datos y el segundo es llamado una bandera de control. Los mdulos de las grficas de estructuras caen en una de tres categoras: control, transformacional (a veces llamada trabajador) y funcional o especializado. Parte de la administracin de calidad total es ver que los programas y sistemas estn diseados, documentados y mantenidos adecuadamente. Seis de las muchas tcnicas de documentacin y diseo que pueden ayudar al analista de sistemas son HIPO, diagramas de flujo, grficas NassiShneiderman, diagramas Warnier-Orr, seudocdigo, manuales de procedimiento y FOLKLORE. Los diagramas de flujo de datos pueden usarse para crear diagramas HIPO. El seudocdigo es usado para paseos estructurados cuando no hay suficiente tiempo para crear diagramas HIPO formales. Los analistas de sistemas deben escoger una tcnica que se ajuste bien con lo que fue usado anteriormente en la organizacin y que permita flexibilidad y facilidad de modificacin. La generacin de cdigo es el proceso de usar software para crear todo o parte de un programa de computadora. Muchos generadores de cdigo estn disponibles ahora comercialmente. La reingeniera y la ingeniera inversa se refieren al uso de software para analizar cdigo de programas existentes y crear elementos de diseo CASE a partir del cdigo. El diseo CASE puede ser luego modificado y usado para generar nuevo cdigo de programa de computadora. La prueba de programas especficos, 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. Tpicamente la prueba se realiza en una forma de abajo hacia arriba, siendo revisado el cdigo 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 produccin. El mantenimiento del sistema es una consideracin importante. El software bien diseado puede ayudar a reducir los costos de mantenimiento. Los analistas de sistemas necesitan establecer canales para la retroalimentacin de los usuarios sobre

las necesidades de mantenimiento, debido a que los sistemas que no son mantenidos caern en desuso. Se consultan auditores, tanto internos como externos, para determinar la confiabilidad de la informacin del sistema. Ellos comunican sus hallazgos de auditoria a otros para mejorar la utilidad de la informacin del sistema. 21. IMPLEMENTACIN SATISFACTORIA EN EL SISTEMA DE INFORMACIN. La implementacin es el proceso de asegurar que el sistema de informacin y/o el centro de informacin es operacional y luego involucrar a usuarios bien capacitados en su operacin. En proyectos de sistemas grandes, el papel principal del analista es supervisar la implementacin, estimando correctamente el tiempo necesario y luego supervisando la instalacin del equipo para los sistemas tradicionales, centros de informacin o procesamiento distribuido, la capacitacin de usuarios y la conversin de archivos y bases de datos al nuevo sistema. Un centro de informacin implementado dentro de un negocio, como parte de un departamento de sistemas ms grande, es una forma para hacer ms fcil a los usuarios satisfacer sus necesidades de informacin a corto plazo. Por medio del centro de informacin 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 informacin deben hacer propia la idea de que el centro de informacin es una empresa que vale la pena y estar dispuestos a desempear los nuevos papeles requeridos en el centro. Es posible comenzar un centro de informacin con un gerente y dos o tres personas tcnicas (siendo uno o todos ellos analistas de sistemas). Los empleados del centro deben ser competentes tcnicamente, pero tambin deben sentir agradable el interactuar con los usuarios en un papel de soporte. Los usuarios deben aceptar la responsabilidad de los recursos que estn 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 tecnologa de telecomunicaciones y la administracin de bases de datos para una de las formas ms populares para enfocar los sistemas distribuidos es mediante el uso de un modelo cliente/servidor. Los tipos estndar 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 smbolos para ayudarse a trazar los diagramas de descomposicin de la red y conectividad de ncleos. Un nuevo software, llamado groupware, est llegando a ser ms funcional y ms ampliamente distribuido. Su objetivo es ayudar a los miembros de grupos a trabajar juntos por medio de redes. La capacitacin de usuarios y de personal para interactuar con el sistema de informacin y/o el centro de informacin es una parte importante de la implementacin, debido a que ellos deben ser capaces de ejecutar el sistema sin intervencin del analista. El analista necesita considerar quines necesitan ser capacitados, quin los capacitar, los objetivos de la capacitacin, los mtodos de instruccin a ser usados, lugares y materiales. La conversin tambin es parte del proceso de implementacin. El analista tiene varias estrategias para cambiar del sistema de informacin antiguo al nuevo. Las cinco estrategias de conversin incluyen cambio directo, conversin en paralelo, conversin por fases, conversin de prototipos

modulares y conversin distribuida. El tomar un enfoque de contingencia entre las estrategias de conversin puede ayudar al analista a seleccionar una estrategia adecuada que se ajuste a sistemas diferentes y a variables organizacionales. Una investigacin 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 metforas organizacionales predominantes en mente. Nueve metforas principales en uso son: familia, sociedad, mquina, organismo, viaje, juego, guerra, selva y zoolgico. Por ejemplo, es ms probable que los MIS tradicionales tengan xito cuando se usan metforas tales como la familia, sociedad o mquina, y es menos probable que tengan xito con metforas organizacionales tales como guerra y selva. Despus de la implementacin debe ser evaluado el nuevo sistema o centro de informacin. Se dispone de muchos enfoques de evaluacin diferentes, incluyendo anlisis de costo-beneficio, el enfoque de evaluacin revisado y las evaluaciones de involucramiento de usuario. El marco de trabajo de utilidad del sistema de informacin es una forma directa para evaluar un nuevo sistema con base en las seis utilidades de posesin, forma, lugar, tiempo, actualizacin y objetivo. Estas utilidades corresponden y responden a las preguntas de quin, qu, dnde, cundo, cmo y por qu para evaluar las utilidades del sistema de informacin o de un centro de informacin recientemente creado. Las utilidades tambin pueden servir como una lista de verificacin para sistemas en desarrollo.

En el estudio de caso, a veces llamado monografa, estudiamos slo un acontecimiento, proceso, persona, unidad de la organizacin u objeto. Tal acercamiento no se parecera promover la blanco general de la investigacin - para desenterrar conocimiento generalmente vlido - pero puede ser motivado por varias razones, tpicamente las siguientes:
A. El caso es singular: solamente un tal caso existe, y es importante y digno de estudiar. Tpicos tales objetos o fenmenos son acontecimientos histricos trascendentales, hombres y mujeres prominentes, estadistas, grandes pensadores y artistas, organizaciones polticas y religiosas, obras de arte o ingeniera renombradas. El propsito es a menudo documentar el caso antes de que la informacin sobre ella consiga perdida. B. El caso es complicado, tpicamente una persona y su actividad, y debe estudiarla a fondo. C. El caso pertenece a una clase de casos prcticamente idnticos, por ejemplo un producto industrial de un tipo y modelo dado. Sera intil estudiar ms 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 arqueolgico, cuando solamente un caso de muchos ha sobrevivido a nuestro da. Semejantemente, muchos mecanismos internos del cerebro se han descubierto de los casos nicos donde el cerebro de un paciente se ha daado en un accidente.

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

universalmente vlido. Sin embargo, es siempre posible que algunos resultados de un estudio de caso puedan tambin posteriormente ser aplicables a otros casos que no se han estudiado, aunque esto es generalmente difcil 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 cul conclusiones l puede aplicar quizs a sus propios problemas (la figura en la derecha). Los procesos lgicos del estudio y de la aplicacin eventual tienen as alguna semejanza a crear y a gozar una obra de arte, como se discute en la pgina Arte como anlisis. Qu clase de conocimiento que usted puede esperar de encontrar con un estudio de caso? En el diagrama arriba, los resultados se caracterizan como "descripcin", pero tambin otros tipos de conocimiento se pueden obtener con estudios de caso. Blancos usuales en los estudios de caso son:
1. Describir el objeto o fenmeno - no solamente su aspecto externo pero tambin su estructura interna, y quizs tambin 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 mtodos respectivos sern discutidos debajo, excepto el acercamiento normativo, los mtodos de el cual diferencian radicalmente del resto. Por lo tanto se discute en las pginas separadas: Punto de vista normativo, Estudio de caso normativo y otra parte.

Estudio descriptivo de caso

Al planear un estudio emprico es generalmente recomendable basar el trabajo sobre un modelo terico 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 teora anterior, es generalmente laborioso, lento e incierto, as que usted desear generalmente evitar tal acercamiento si posible. El mtodo normal es comenzar con una bsqueda cuidadosa de la literatura para encontrar modelos tericos usables. Por otra parte, puede haber razones de no basar el estudio en cualquier modelo o teora anterior, por ejemplo:
y

El objetivo es documentar el objeto de forma tan completa como sea posible, y no slo 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 puntera de la documentacin no es tanto analizar el objeto pero simplemente recolectar tantos hechos de ello como posible Bsqueda fenomenolgica de una comprensin profunda y desconfianza en las anteriores descripciones y explicaciones que podan quizs 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 tpica en una clase de casos, su mtodo se discute en la pgina Indicar lo tpico, prrafo Anlisis fenomenolgico. El objeto de estudio difiere de todos objetos anteriores y el objetivo del estudio est describir su carcter excepcional. Traer ideas de teoras anteriores poda embrollar esta descripcin.

Escoger un acercamiento exploratorio, es decir con ninguna base terica, para un estudio de caso descriptivo puede as ser una decisin deliberada, o una necesidad porque no hay teora conveniente o modelo disponible. De todas formas, la investigacin exploratoria significa que al principio del proyecto muy poco se sabe sobre la materia. Usted entonces tiene que comenzar con una impresin algo vaga de lo que se debe estudiar, y es tambin imposible hacer un plan detallado de trabajo por adelantado, ni comenzar definiendo los conceptos del estudio. Durante el proyecto de investigacin exploratoria estos conceptos incipientes mejorarn 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 comn que en el principio del estudio exploratorio usted tomar una mira holistica del objeto, reuniendo tanta informacin sobre los objetos como sea posible. Usted no quiere restringir su estudio a apenas unas pocas caractersticas del objeto, antes usted sabe que cul preguntas son importantes. Usted as pospone la tarea de eliminar datos innecesarios hasta que se consigue un retrato mejor sobre cul 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. Despus de que usted haya pasado unos das en la experimentacin con varias vistas al objeto, usted podr probablemente especificar la posicin final para su estudio y explicar cmo 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 cmo vemos el objeto, ya sea posible por ejemplo que sea definido en un micronivel como resultado de instintos individuales, mviles y experiencias, o quizs en un macronivel como una expresin de las ideologas y presiones en sociedad. El progreso de un proyecto de estudio se hace ms fcil en cuanto hemos definido nuestro punto de vista y problema. Tras esto, vamos a necesitar reunir slo aquel conocimiento emprico 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 anomalas o los casos que sorprenden pueden sealar una va a las enmiendas o correcciones importantes a la teora 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 informacin 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 anlisis de datos empricos, se podran distinguir dos fases, pero stas se solapan. Estas fases seran:
y y

simplificacin de observaciones interpretacin de resultados (o "resolver el enigma")

En la fase de simplificacin, el material es inspeccionado desde el punto de vista terico del proyecto de estudio, y slo 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 ms fcilmente. Las estructuras ms interesantes son a menudo las que se pueden esperar ser comunes en todos casos comparables - este aspecto se discute en la pgina Indicar lo tpico. "Resolver el enigma" no siempre significa contestar exactamente a aquellas preguntas que fueron formuladas en el comienzo del proyecto. A veces las preguntas ms interesantes se encuentran al final de la investigacin, cuando el investigador es un experto en el tema. Describir un caso en base de la teora. Hoy en da, casi todos temas del mundo han sido ya estudiados por uno o ms campos especiales de la investigacin. En consecuencia, casi toda pregunta u objeto concebible se puede ahora investigar a la luz de teora previa. En campos de la investigacin establecidos usted puede seleccionar a menudo su problema de modo que usted pueda manejarlo como caso especial o como extensin de la teora existente en este campo, creado por investigadores anteriores. Tal prctica facilita el comienzo de un nuevo estudio, y es corriente en estudios acadmicos. Adems, usted puede acercar a menudo al problema de modo que usted combine las vistas de dos o ms 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 lgico y fcil 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 maestra especial, y las visines que resultan entonces son

ensambladas juntas por discusiones en el equipo. Un investigador exploratorio que trabaja solo puede en lugar utiliza el mtodo 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 teora existente hecha por investigadores anteriores (vase la figura de la derecha). Cada punto de vista aade algo al cuadro general.

Estudio de caso explicativo

El investigador desea a menudo continuar el proyecto a un nivel ms profundo que apenas la descripcin: 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 histrica. Encontrar las razones, o explicar el fenmeno, se puede hacer en varias maneras. Las razones se pueden traer del contexto simultneo del fenmeno, a partir del pasado, o alternativamente a partir del futuro. En el siguiente estn algunos ejemplos que son comunes en la investigacin as como en vida diaria.
y

Explicacin a partir del pasado. En las ciencias naturales las explicaciones para los acontecimientos tradicionalmente se buscan en el pasado: cules son las razones que causaron el presente estado de cosas? Este tipo alternativo de explicacin es llamado causal, por ejemplo: "El puente se derrumb por causa del fuerte viento y porque el diseo era defectuoso". Explicacin contextual. Los bilogos a veces explican una actividad con la ayuda de la funcin que ella cumple en la vida del grupo o de la especie. Por ejemplo, un pjaro canta para indicar cul 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. Explicacin a partir del futuro es comn cuando se estn explicando los actos de la gente. Por ejemplo, "la Torre de Eiffel fue construida para servir como smbolo de la Exposicin de Pars".

De estos tipos, la explicacin 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 sociologa, antropologa, economa y psicologa, y es normal explotar teoras de estas ciencias cuando la meta del proyecto es encontrar una explicacin al estado del objeto del estudio, la existencia de teoras anteriores facilita y acelera el procedimiento de la investigacin de la misma forma que se hace en estudio descriptivo, discutido en el prrafo precedente. Cuando una o ms teoras para explicacin estn disponibles, el acercamiento lgico es probar cada uno de ellas y entonces elaborar la explicacion que se parece ms plausible. Quizs el ms usual explicacin contextual es el acercamiento sociolgico: "Se debe mirar al diseador como parte de la sociedad circundante, y examinar su trabajo y valores con respecto a condiciones sociales, culturales y econmicas... Tenemos que entender cmo y porqu el diseo 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, econmicos y ecolgicos. Los factores explicativos son, por ejemplo, cambios en la demografa de la sociedad, en las condiciones de la industria o de la economa; por otra parte las consecuencias de invenciones, educacin, cambios polticos, guerras y la adquisicin o prdida de colonias. Factores constantes pero regionalmente dismiles son clima, disponibilidad de materias primas y de energa, canales del transporte y las necesidades locales de la gente. Por ejemplo, Pivi Hovi estudi cmo 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 haba sido el objeto de estudios anteriores y el conocimiento y la teora acumulados daban acercamientos potenciales para el estudio del material emprico de Hovi. Aunque en sentido estricto ste no era ningn 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, tambin. El acercamiento psicolgico es usual en el estudio de artistas y de sus trabajos, tambin. Wilhelm Scherer (1841 - 86) fue el primero en presentar un modelo general para las biografas de artistas. El modelo explica el carcter especial de cada artistas por tres factores, que eran,
y y y

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

La explicacin por acontecimientos anteriores hace obviamente falta de un estudio diacrnico, es decir necesita material de un perodo del tiempo ms largo. La duracin vara - acontecimientos fsicas causalmente explicables se pasan a menudo en menos que un segundo, mientras que los efectos que varios alimentos y sus aadidos pueden causar al hombre pueden tardar muchos aos antes de aparecer. En todo caso, ensanchar la duracin del estudio ampla 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 poblacin del estudio ms estrecho. Al decidir que materia usted necesitar reunir, un punto de partida inestimable podra ser resultados anteriores acerca de cul factores se han correlacionado en objetos comparables ms temprano. En ausencia de tales teoras usted tiene que encontrar la explicacin causal en el objeto l mismo. Esto requerira recoger mucha materia, estudiarla en la perspectiva histrica, 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 despus de ellos. Entre estos acontecimientos usted puede encontrar quizs las explicaciones plausibles para los cambios que han sucedido, y finalmente para el estado presente del objeto. Este acercamiento se discute tambin en Explicacin del desarrollo. Explicacin 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, polticos, empresarios y artistas, al igual que desde las memorias de esta gente. Otras fuentes son conceptos del producto, especificaciones, propuestas y documentos de la evaluacin. 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 obstculos prcticos imprevistos encontrados en la fase de la realizacin, y a veces porque la intencin anunciada no ha sido bastante realista u honesta. La problema se discute en una pgina separada: Evaluar la informacin.

Estudio de caso como base del pronstico

Cuando el propsito de un estudio de caso es ayudar al pronosticar el futuro del objeto o del fenmeno, primero de todo hay que definir qu caractersticas del estado futuro de cosas estn "interesando" y sern incluido en el pronstico. Los datos recientes sobre stos obviamente son de importancia primaria como base para el pronstico. Qu otro material se necesita para pronosticar, depende de cul mtodo de pronosticar que se piensa utilizar. Esto, en cambio, depende de cmo es fuerte un modelo terico que usted tenga acerca del desarrollo futuro previsto y sus relaciones internas. Una base fuerte para pronosticar est un modelo que explica el fenmeno, enumerando sus razones y sus resultados, es decir definiendo la invariante dinmica del proceso que se predir. Otros tipos menos confiables de modelo que se pueden utilizar en el pronstico son correlaciones u otras asociaciones estadsticas entre variables, y los modelos o analogas prestados de otros contextos tales como una esfera distante de la cultura. Un resumen de mtodos de pronstico posibles en base de un estudio de caso se da en la tabla que sigue:
Pronstico sobre base dbil o ninguna base terica: Datos sobre el desarrollo de las caractersticas "interesantes", a partir tan de largo de un perodo como sea posible. Pronstico sobre base terica fuerte:

Datos requeridos:

Datos recientes sobre las caractersticas "interesantes". Adems, datos recientes sobre las variables independientes supuestas,

segn teora. Varios mtodos son posibles. Extrapolacin ; Aplicar una asociacin Especialmente confiables son: estadstica ; Mtodo Delphi Aplicar un modelo causal y Determinar el lmite.

Mtodos de pronstico convenientes:

De estudios de caso hacia teora general

El conocimiento que un caso puede producir concierne el caso que fue estudiado, y al principio vista parece imposible aplicrlo a otros casos o a una clase de casos. Lgicamente parecera que para conseguir conocimiento sobre una clase se necesita un proyecto de investigacin que toma como su objeto la clase entera, no slo un caso de ella. Otro procedimiento lgico para ganar conocimiento generalizable podra 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 facilitarn el trabajo de investigadores posteriores en encontrar invariantes que se repiten en los casos separados, y finalmente quizs se podra construir un modelo general de estas invariantes, o podemos por lo menos precisar un caso tpico en la clase (Fig. de la derecha). Sin embargo, el procedimiento ms usual para avanzar desde estudios de caso distintos hasta conocimiento generalmente vlido se basa probablemente en el hecho de que la mayora de los investigadores de un caso en realidad tienen bastante de conocimiento de otros casos comparables ya cuando comienzan su estudio. Este conocimiento generalmente vlido 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 ms fcil para otros cientficos - o laicos - generalizar las conclusiones de este estudio de caso, si ellos quieren tratarlo en su propio riesgo. Hoy, cuando hay tanto informes de investigacin acerca de todos campos concebibles del estudio, es cada vez ms usual basar un nuevo estudio de caso en la hiptesis que el caso se comportar en acuerdo

con una teora ya existente. Si lo hace, el rea de la validez de esta teora agrandar, y en el caso opuesto el investigador quizs puede modificar esta teora anterior. En ambos casos los resultados del nuevo estudio pueden estar cientficamente o prcticamente 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 (Investigacin para mejorar un modelo). Estudio de caso normativo se discute en otra pgina.

Lgica del anlisis normativo

Acercamiento normativo intenta descubrir no slo cmo estn las cosas, pero sobre todo cmo ellas deben estar. Significa que ser necesario definir tambin 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 cmo el estado presente de cosas se debe mejorar, la cadena lgica 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 anlisis consiste en una descripcin objetiva de l y una evaluacin subjetiva de los problemas existentes. Ambos a menudo se pueden hacer simultneamente, vase Registro normativo. Finalmente, una propuesta se debe hacer acerca de cmo los problemas se podran 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 tambin 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 podra significar la modificacin 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 anlisis normativo. Este mtodo es usual al desarrollar un producto nuevo, donde los ejemplares se seleccionan a menudo entre los competidores ms agudos de su producto existente. Al desarrollar un servicio u otra actividad existente, el ejemplar se podra tomar de una actividad hbilmente arreglada conocida en otra parte. En este acercamiento, el procedimiento lgico no diferencia mucho del alternativa "A" mencionado arriba. Es tambin posible tomar ms de un exemplar como puntos de partida, y en este caso la blanco llega a ser el combinar sus mejores caractersticas. C. Un punto de partida alternativo en anlisis normativo podra ser una descripcin del estado ideal de cosas. Se construye principalmente en base de las preferencias subjetivas

de los grupos de inters, generalmente considerando todas las restricciones prcticas sabidas que la propuesta tiene que encontrar. Se utiliza este acercamiento cuando no hay ningn existente modelo usable en el que usted podra basarse sus propuestas, o como un complemento a los acercamientos "A" y "B" ya mencionados. Un ejemplo est el mtodo de la especificacin en desarrollo de productos.

Estos dos o tres acercamientos se pueden tambin utilizar en paralelo para dar una base ms confiable para la propuesta. En todo caso, la etapa final del proceso normativo consiste generalmente en una alternacin de preparar propuestas tentativas detalladas (a menudo por los diseadores o los investigadores profesionales) y de evaluar estas propuestas, preferiblemente por gente desde los grupos de inters o por lo menos simulando sus puntos de vista. Para el proceso entero del anlisis normativo nadie todava ha encontrado un modelo confiable y generalmente aplicable, pero uno o ms de los procedimientos lgicos siguientes se utilizan a menudo en el proceso:
y y y

Analizar requisitos. Crear una propuesta con las tcnicas de la innovacin, del planeamiento y del diseo. Evaluar propuestas normativas (en una pgina separada).

Analizar requisitos
Cuando considerar la necesidad de mejorar un objeto del estudio, el acercamiento normal es definir esas caractersticas del objeto que necesiten una mejora, y quizs tambin enumerar esas otras caractersticas de l que deben ser mantenidos como estn. Es decir, usted hace una lista o una especificacin que contenga los requisitos que la propuesta final del proyecto debe resolver. El procedimiento para crear una especificacin depende de la informacin que est disponible como su punto de partida. Los enfoques usuales para esto incluyen el siguiente:
y y y y

Agregar una dimensin normativa a un anlisis descriptivo (tal como estudio de caso, comparacin, clasificacin etc.) Combinacin de ejemplares. Un ejemplar con mejoras. Especificacin sobre base terica.

Agregar una dimensin normativa a un anlisis descriptivo

Un acercamiento para manejar las caractersticas de la propuesta futura es aplicar los mtodos de anlisis descriptivo (tales como estudio de caso, comparacin, clasificacin etc.) al objeto del estudio, y amplificar estos mtodos agregando una dimensin normativa en el anlisis. Algunos ejemplos se dan abajo.

Estudio de caso normativo. El estudio de caso es un enfoque usual en proyectos de investigacin descriptivos, pero se puede amplificar fcilmente 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 investigacin se ha hecho para descubrir porqu se inclina la torre de Pisa, y cul factores contribuyen al problema. Solamente despus de tales estudios pueden los ingenieros comenzar a disear la mejora. Los candidatos obvios a estudios de caso normativos son nicos productos costosos como casas, producciones del teatro o de la pelcula y los programas de computadora que necesitan a veces ponerse al da o mejora durante su vida larga. Probablemente el uso ms comn para un caso normativo es de dar un punto de partida para desarrollar una nueva versin de un producto o de un procedimiento existente. Este punto de partida est normalmente - despus de estudios necesarios - definido como un ejemplar, ve abajo. Estudio pedaggico del desarrollo. Muchas historias tradicionales han tenido una esencia normativa escondida an cuando el autor intent presentar su trabajo como "descripcin pura" con los mtodos del analizar el desarrollo. Organizaciones como la iglesia, el gobierno o la familia real han designado a los historiadores innumerables, y esta fijacin ha dirigido la seleccin de hechos. Se esperaba que los historiadores describieran sobre todo esos acontecimientos que tenan alguna relacin al patrn, 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 seleccin ser subjetiva y basada en sus preferencias. En el siglo 19 muchos investigadores de la historia desearon describir objetivo "cmo era", pero la opinin general es hoy que ningn 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 histricos pueden asistir a mejorar cosas existentes, y si usted se prepone hacer esa clase de estudio l llega a ser ms fcil si usted reconoce esta meta conscientemente. Esto significa en la prctica que usted ya en el principio debe definir cul es el problema que usted espera aliviar con la ayuda de su estudio, o de cul 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 anlisis innecesarios. Una vez que el investigador ha descubierto las estructuras inherentes o "invariantes dinmicas" de una evolucin histrica, estos tambin 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 evolucin pasada, stas pueden ser usadas tambin para cambiar la direccin de futuros progresos. Comparacin normativa. La diferencia entre los estilos descriptivos y normativos de la comparacin es que en el anlisis normativo uno de los criterios principales son evaluativo como la "satisfaccin", la "utilidad" etc., y la puntera del estudio es precisar el mejor (en este respecto) entre las alternativas que se estudian. A veces la puntera final quizs sea encontrar no slo el mejor objeto existente, sino tambin mejorar los objetos similares ms tarde. Es decir se espera que el anlisis 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 compaa lo tiene, o la crtica pblica 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 nmero de productos se juzgan segn una lista estndar de preguntas, como en el ejemplo a la derecha. La lista necesita incluir solamente esos aspectos donde diferencian los productos que rivalizan.
Modelo de coche: Nmero de asientos Nmero de puertas Bolsas areas 5 2 2 A 8 4 4 6,5 B

Consumicin de combustible 5,8 Mritos especiales

(Evaluacin cualitativa)

La tabla de la comparacin trabaja bien incluso en el caso que algunos de los Precio 8500 9900 criterios estn expresados como variables numricas y otras como descripciones verbales cualitativas. Nada previene incluyendo las presentaciones an pictricas 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. Adems, usted tiene que observar que todos los criterios en la lista son quizs no igualmente importantes. Por lo tanto usted necesitar definir el peso de cado criterio cuando sumarlos. Una clasificacin normativa se puede construir semejantemente de casi cualquier tabulacin cruzada descriptiva agregando una dimensin que exprese una evaluacin. 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. Mtodos para esto son Combinacin de ejemplares y Ejemplar con mejoras.
Combinacin de ejemplares

Ejemplares son procedimientos existentes, lneas de accin, artefactos o sus detalles, en los cuales por lo menos algunas caractersticas son meritorias, miradas desde el punto de vista del actual proyecto normativo. Pueden incluir tambin algunas caractersticas que no sean completamente aceptables. El propsito normativo o educativo se parece haber penetrado ya los primeros estudios de caso que se hicieron en la antigedad. Explicaron los mritos de estadistas respetados, o de trabajos admirados de la arquitectura, ms adelante tambin las vidas de santos y de los artistas estimados. El propsito era obviamente presentar stos a la generacin siguiente como ejemplos meritorios, o evitables a veces. Todava hoy este acercamiento se utiliza a menudo en varios artes donde los crticos reputados seleccionan ejemplares que despus se publican en exposiciones y diarios profesionales y se esperan para dirigir la obra en el campo ms adelante. Se utilizan como un substituto o complemento de la teora en artes y profesiones de diseo artstico para los asuntos sobre que es difcil desarrollar doctrinas ms explcitas, y an para tales asuntos donde el conocimiento existe solamente en la forma tcita, 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 diseo, particularmente en la fase temprana de preparar un concepto detallado del producto, cuando es difcil 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 combinacin de las cuales se debe transportar al producto nuevo. Ambos estos mtodos se explican en Modelos lgicos para presentar un concepto del producto. En el mtodo del conjunto de ejemplares usted escoge dos o ms 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 caractersticas que el equipo de diseo entonces tratar de combinar en el producto nuevo. Si esto se puede lograr, el producto nuevo ser ms competitivo que cualquier de los ejemplares, an en el caso que ninguna de sus caractersticas en s mismo supera los ejemplares. Cuando la seleccin de ejemplar depende de registros de ventas, el mtodo tiene la ventaja de reflejar verazmente las opiniones de los clientes. Un mtodo alternativo ms arduo para recoger las opiniones de los usuarios potenciales del producto sera un cuestionario, por ejemplo. Los ejemplares se pueden seleccionar de la produccin de su propia firma, pero es tambin posible tomar un o ms 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 compaas y los productos ms acertados del mercado, l puede tambin ser utilizado para "benchmarking": define un nivel ptimo de la operacin que se sabe y que se pueda tomar como blanco para las compaas menos acertadas. Trabajar con un conjunto de ejemplares es fcil 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 difcil generar nada realmente nuevo cul podra 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 invencin. Ejemplares son tambin muy utilizados en la educacin de la economa del negocio. Muchas universidades poseen colecciones grandes de informes de caso de las compaas que trabajan en la vecindad. Un caso educativo describe tpicamente la historia, la organizacin, el ambiente, los productos claves, el sistema de la gerencia y quizs algunos problemas de la gerencia tpicos que los estudiantes entonces pueden solucionar. La medicina es otro campo de la educacin donde estn esenciales los ejemplares. Aqu describen las operaciones clnicas que han curado una enfermedad con xito.
Un ejemplar con mejoras

Definir las mejoras refiriendo a productos o actividades existentes es un mtodo antiguo. En su momento incluso fue posible el ahorrarse el diseo del ejemplo: ste normalmente era la tradicin. El mtodo puede seguir usndose 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 competicin que usted desea sobrepasar. Cul propiedades entonces requieren mejoras, y cunto, eso es una pregunta contest quizs ya en los archivos de respuesta de los clientes de su compaa. De otro modo, usted tendr que hacer un estudio de mercado con varios mtodos interrogativos entre clientes potenciales, o entre los vendedores de su compaa. Las ventajas del mtodo de ejemplar-y-mejoras son que es sencillo de usar, concreto y realista. Los malentendidos no son probables. Del punto de vista del diseador un ejemplar es un punto conveniente de partir, porque es a menudo relativamente fcil continuar mejorndolo por el mtodo de iteracin. Tiene tambin la ventaja que necesita las modificaciones slo mnimas a la lnea de produccin. Una desventaja es quizs que es demasiado fcil de indicar detalles que pudieron necesitar la mejora, sin entender cmo 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 mtodo en la fase de concepto de producto

puede dar lugar a blancos de aspiracin alta que no se pueden resolver en la prctica. Para prevenirla, es recomendable evitar de dar directivas demasiado absolutas pero en lugar utilizar escalas de la satisfaccin (vase abajo) cundo definir las mejoras deseadas.
Especificacin sobre base terica

En el caso que ningn ejemplar conveniente no puede ser encontrado, los mtodos que refieren a un ejemplar estn fuera de cuestin. Sin embargo, es tambin posible especificar las caractersticas deseadas del estado futuro de cosas o del producto nuevo directamente en base de investigacin anterior y teora. Este mtodo tiene, adems, la ventaja que permite definir incluso productos y procesos radicalmente nuevos sin precursores sabidos. Por otra parte, el mtodo est exigiendo, porque usted tiene que trabajar con conceptos tericos abstractos. Puede ser difcil definir las cualidades de un producto que todava no existe. Es a veces difcil 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 fcil olvidarse de caractersticas esenciales y de sus efectos secundarios, especialmente si afectan a forasteros. El alcance de las caractersticas que son relevantes al desarrollar productos nuevos es muy grande. Contiene temas como:
y y y y y y y y y

usabilidad, funcin, efecto y mantenimiento fcil seguridad y durabilidad belleza significado simblico ecologa, uso de recursos coste y precio armona con otros productos de la compaa y sus principios de Design Management puntos de vista de la fabricacin, como las materias primas fcilmente disponibles y la maquinaria ya existente logstica y otros puntos importantes en la comercializacin.

La lista arriba contiene sobre todo artculos que interesan o benefician al usuario o a fabricante del producto. Adems, usted debe tener en cuenta que puede haber efectos secundarios, quizs perjudiciales, a los forasteros. Tales efectos son, desafortunadamente, a menudo difciles de enumerar y de determinar. Vea una lista general de varios grupos de inters en un proyecto del desarrollo. Todo producto posee un nmero infinito de atributos, pero slo un pequeo nmero de ellos son importantes concerniente a la produccin, 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 diseo conviene y que as probablemente sern considerados suficientemente sin alguna mencin en el concepto del producto. De todas formas, la lista de caractersticas crece a menudo difcil para manejar. Algunos procedimientos que pueden ayudar a tratar una lista muy larga de caractersticas y de requisitos son:

y y y y

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 satisfaccin para tan muchas caractersticas como sea posible.

Los requisitos obligatorios. Se refieren a menudo a la seguridad del uso del producto, especialmente sus peligros mecnicos, qumicos o elctricos. Las regulaciones obligatorias son dadas a menudo por las autoridades pblicas, o se publican como las pautas y estndares voluntarias de la industria. Se especifican con proyectos de investigacin separados, realizados por especialistas como mdicos, 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 ms fcil, en la inspeccin 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 estn en conflicto en mayor o menor grado. Esto es incluso ms fcil 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 ms pronto posible; de otro modo podran ralentizar fatalmente la preparacin de la propuesta final. A veces es posible conjugar los objetivos que estn ostensiblemente en conflicto desvelando sus relaciones mutuas. Un ejemplo de este mtodo es localizar el aislamiento trmico ptimo para un edificio. Cuando se elige el grosor de la capa aislante, el coste de los materiales de construccin (B, en la figura de la derecha) y los costes futuros de calefaccin (A) parecen estar en conflicto. Sin embargo, los valores de estos dos gastos pueden ser traducidos a costes anuales, hasta que fcilmente 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 calefaccin. La ciencia del anlisis de operaciones abarca otros mtodos de anlisis comparables, como por ejemplo el algoritmo de la programacin lineal, que puede usarse para encontrar el valor ptimo comn de varios atributos cuantificables de un producto. La mayor parte de estos mtodos aceptan solamente variables cuantitativas. Por supuesto, es posible cuantificar cualquier atributo cualitativo y transformarlo en una variable cuantitativa; pero la conversin suele pasar por alto algunos aspectos ms sutiles del atributo y la validez de los resultados se resentir entonces por ello. Por eso, esta tcnica se debe utilizar solamente con discrecin.
Objetivo Capacidad de al menos 55 unidades/hora Peso 40

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 slo un nmero pequeo de stos ser esencial y absolutamente obligatorio (y ellos se recogen preferiblemente en una lista separada) mientras que la mayora de los requisitos son blancos ms o menos voluntarias.

Diseo llamativo y personal; a diferencia de todos los dems modelos del mercado Todos los materiales pueden reciclarse La produccin no costar ms de 100$

10

10 40

Total de pesos 100

Por supuesto, la meta es satisfacer todos los requisitos de la gente pertinente si sea posible, pero sucede en la prctica a menudo que lograr totalmente una blanco prevendr la realizacin otro, particularmente la blanco del coste moderado de produccin. Esta es la razn 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 ms importante. La orden de la importancia puede ser dada asignando pesos a los requisitos. Un ejemplo de una tabla pequea 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 lgica. Preferiblemente debe ser posible comprender todos los grandes rasgos en un panorama. Con este fin, y tambin para reducir el tamao de la tabla, es ventajoso combinar los grupos de caractersticas 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 anlisis factorial. Los grupos de caractersticas que resultan se pueden entonces presentar en el patrn de un rbol lgico, de un diagrama de Venn o de otro modelo topolgico. 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 ms bajos ms detallados sern ms pequeos. Un ejemplo de un rbol lgico est a la derecha, donde Shackel ha analizado el concepto de la utilidad de productos. Otro rbol lgico (abajo) representa las metas cualitativas de la construccin (por Niukkanen, 1980, p.20).
SATISFACCIN / ADECUACIN Entrada (aportaciones) Costes / Recursos Salida (produccin) Utilidad / Funcin Experiencia / Percepcin

Costes de construccin Espacios Factores ambientales Costes de uso Entorno de interior y clima Exteriores Disminucin de produccin Equipamiento y durabilidad Interiores

La tabla de pesos tiene una grande ventaja: puede transformarse posteriormente en una tabla de evaluacin de las propuestas de diseo o para someterlas al anlisis de costes y ventajas. Los grados de satisfaccin. Para muchas Propiedad: Facilidad de uso Mrito caractersticas el lmite de la aceptacin o del rechazo es vago: el ms usted obtiene, Las operaciones son automticas. 5 el mejor es. Por otra parte, producir una calidad o una capacidad superior significa Varias operaciones son automticas. generalmente costes adicionales. Puede 4 ser ventajoso posponer la medida final de Folleto de instrucciones es detallado y claro. tal caracterstica a un momento ms tarde 3 en el proceso del desarrollo de producto, Instrucciones y funcionamiento mediocres. cuando tenemos ms conocimiento de las alternativas disponibles y de sus costes. El funcionamiento a veces torpe o confuso. 2 Esto significa que incluso cuando sera perfectamente posible definir, en la fase La mquina reacciona de manera 1 del anlisis, un lmite de la aceptacin distinta a la descrita en el folleto. para esta caracterstica, definimos en lugar una serie de grados de satisfaccin o de "niveles del mrito" como en la tabla a la derecha. La satisfaccin se mide en una escala arbitraria, por ejemplo en una escala de 1 a 5. Una escala numrica facilita el manejar de varias caractersticas simultneamente y el encontrar de su grado ptimo comn, aunque la desventaja es que algunos aspectos de menor importancia de la caracterstica pueden conseguir olvidados. Hay tambin caractersticas que fcilmente se pueden medir numricamente, pero a pesar de esto la medida no indica directamente su valor de utilidad o de satisfaccin. Consideremos una bicicleta: si posee dos marchas es mucho mejor que un vehculo del engranaje simple. Tres marchas son todava un poco mejor, pero si hay sobre diez engranajes la adicin de una o dos ms no da mucho aumento en utilidad o satisfaccin. La relacin entre el nmero de marchas y la satisfaccin 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. Segn l, un tocadiscos deber ser valorado "pobre" (utilidad=1) si slo transmite la voz hasta el lmite de 5 kilociclos. 10 khz es un poco mejor, mientras que 20 kilociclos es excelente

(utilidad=5). Un rendimiento ms alto despus de eso no da ningn mrito adicional, porque la oreja humana nunca podra or las voces sobre de 20 khz. Es posible medir, al lado de las ventajas materialistas y utilitarias, tambin agrados intelectuales como belleza. Un ejemplo se ve en el diagrama a la izquierda. El grfico pretende indicar que hay un grado ptimo mensurable de la complejidad visual de una obra de arte (y porqu no de un producto industrial, tambin). La filosofa detrs de este tipo de medida esttica se discute en Belleza del descubrimiento.

Crear propuestas
y y y y y y

"El proceso de "planificacin racional" Iteracin El mtodo del tanteo El mtodo de maduracin subconsciente Innovacion en grupo de trabajo como "lluvia de ideas" Mtodos participativos

El proceso de "planificacin racional"

Razonamiento lgico como mtodo de planeamiento apunta a encontrar apenas una ptima solucin en base de las blancos dadas y de las circunstancias efectivas. Esta tcnica 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 diseo mediante el razonamiento lgico sobre como debe hacerse el diseo. Este mtodo ha producido el llamado "proceso de planificacin racional", que consiste en las siguientes fases:
1. 2. 3. 4. 5. 6. 7. Descripcin de la situacin de partida Descripcin de la situacin a la que se pretende llegar La diferencia entre 1 y 2 da los objetivos para el plan Concebir alternativas para alcanzar el objetivo Predecir las consecuencias para cada alternativa Valorar las consecuencias Elegir la mejor alternativa.

Las tres fases iniciales del proceso son a menudo fcilmente factibles con los mtodos usuales de investigacin descriptiva. Las fases 4 y 5 deben ser rutinas normales para un diseador perito. En esos campos de la produccin industrial donde este tipo de la tarea es usual, es an posible que investigadores desarrollen los modelos uniformes de la deduccin o del clculo que los diseadores pueden utilizar en la mayora de las tareas para encontrar las soluciones ptimas. En la prctica real del diseo, lo ms cercano a un proceso racional puede probablemente encontrarse en la ingeniera tcnica. Los procedimientos exactos

usados en ella son, por ejemplo, algoritmos, es decir, clculos para encontrar las medidas para estructuras y redes de lneas elctricas. Pueden con frecuencia llevarse a cabo mediante un ordenador, que puede acelerar el diseo en gran medida, especialmente cuando se usa el diseo asistido por ordenador (computer aided design-CAD). El punto ms dbil del modelo son las fases 6 y 7 donde usted debe considerar simultneamente una multiplicidad de requisitos de diversos partidos: las necesidades de varios grupos de gente, el ambiente, la tecnologa de la produccin y coyunturas. Una evaluacin comn de todos estos requisitos es obviamente posible solamente si las consecuencias de alternativas se saben exactamente y no hay tambin muchas diferencias personales en la evaluacin. Una condicin tan afortunada no es comn en el diseo de productos, para un uso personal de gente. Muchos investigadores de los mtodos de planificar han propuesto tratar con problemas complicados segn el mtodo de Descartes, dado como las reglas nos. 2 y 3 en el Discurso del Mtodo (1637): dividir el problema en "en tantas partes como sea posible para solucionarlas mejor", resolver separadamente cada uno de stos, empezar con las asuntos ms simples y subir al ms complejos. As, Christopher Alexander en el libro Notes on the synthesis of form [Notas sobre la sntesis de la forma] (1964, p.94) ilustra su mtodo con la ayuda de dos rboles lgicos (abajo). El que est a la izquierda presenta el proceso del anlisis: hender los requisitos al producto futuro en sus componentes. El segundo rbol simboliza la sntesis 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 diseadores practicantes pronto encontraron que es raramente posible hender problemas del diseo en partes tan independientes que stos se podran resolver en el aislamiento y combinar de nuevo con xito. Es decir la piedra filosofal del planificar no ser encontrada con este acercamiento.

Iteracin

Iteracin es un proceso a menudo visto en el anlisis normativo. Significa que usted hace modificaciones "incrementales" pequeas a la propuesta, compara la nueva con la vieja propuesta y contina con cualquiera de ellas que es la mejor. Es

un mtodo poderoso, pero al usarlo usted debe tener en cuenta dos debilidades inherentes de l:
1. El mtodo iterativo puede manejar solamente una caracterstica del objeto al mismo tiempo. Si usted tiene varios alternativas en los cuales diverja de uno al otro en ms que un respecto, usted lo encontrar difcil comparar ellos con el mtodo iterativo. 2. Otra debilidad del mtodo de iteracin es que mientras que ella conduce generalmente a una solucin 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 iteracin se comienza en la opcin 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 poda haber sido encontrado por iteracin slo. 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 mtodos ms innovadores que sean capaces de elaborar las propuestas que son ms 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 economa. Con menos detalles y exactitud es ms fcil mantener la innovacin y crear alternativas que son ms 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 eliminarn en la fase de la evaluacin. A condicin de que la prueba final se hace con cuidado, es permitido utilizar un estilo de trabajo ms bravo y ms innovador durante la mayor parte del tiempo. La evaluacin final tendr validez mejor ya porque las propuestas finales son ms detalladas y ms realistas.
El mtodo del tanteo

Cuando usted tiene la posibilidad de elegir entre alternativas que tienen una variacin grande, y el nmero de las alternativas crece, la probabilidad se aumenta que hay una alternativa aceptable entre ellos. Esto es verdad tambin 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 seleccin. Esta ltima lgica es, en hecho, igual que ha gobernado el origen de las especies con la seleccin natural, segn la teora de Charles Darwin. Un uso eficiente del mtodo del tanteo requiere as muchas alternativas, quizs varios centenares de ellos, y la gama de su variacin 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 ms prometedor o unos pocos prometedores entre ellas generalmente basta, porque unas imperfecciones en l se pueden fcilmente corregir ms tarde con iteracin. Debe evaluar as las alternativas no tal y como estn, sino como puntos de partida potenciales para las propuestas. Gran competencia del evaluador es as esencial.

Para desarrollar una gran cantidad de alternativas dos mtodos son comunes:
y y

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

Para generar una gama grande de alternativas usted quizs quiera tomar un producto existente como punto de partida, pero la dificultad en este mtodo es que las propuestas tienden a quedarse demasiada cerca de esto origen, y alternativas realmente nuevas nunca se encuentran. Sin embargo, el mtodo es viable cuando combinado con una variacin voluntariosa brava, por ejemplo modificando la idea existente del producto viejo con transformaciones, por ejemplo:
y y y y y y y y y

Agrande: Agregue algo, multiplica, consolide, hgalo ms largo, ms alto, ms grueso, ms pesado, ms fuerte o ms rpida. Reduce: Quite algo, haga ms ligero, ms corto o ms lento. D vuelta al revs o interior hacia fuera. Contrario. Invertido. Vuelco. Gire de cabo a rabo. Henda. Combine. Posponga. Haga ms temprano. Esconde. Acente. Especialice. Generalice. Substituya: Qu ms? Quin otro? Cmo de otra manera? Modifique la estructura. Cambie la orden, la disposicin, 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 razn debe desatender todas restricciones u puntos de vista prcticos. Su turno viene ms adelante, al seleccionar a los mejores candidatos y mejorndolos ms lejos. Otro mtodo para alentar variacin al desarrollar alternativas es fusionar "ideas distantes" aleatorias en el proceso creativo. Estas ideas distantes pudieron ser presentadas como artculos sacadas al azar de una lista elaborada previamente. Inicialmente no necesitan tener relacin 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 analoga. Una vez que una propuesta pensable - o algunas - se haya encontrado con el "mtodo del tanteo", a menudo resulta que todava haya mucho que debe mejorar en las propuestas. Para estos mejoramientos finales, iteracin es a menudo el mtodo adecuado.
El mtodo de maduracin subconsciente

Todos los mtodos descritos arriba estn destinados para ser utilizados por el diseador tal y como procedimientos planeados y conscientes, pero otra posibilidad deber que el subconsciente del diseador se haga cargo del trabajo, quizs utilizando algunos fragmentos de las cadenas lgicas antedichas o de cualquier otra que todava no sabemos. El mtodo de maduracin subconsciente es comn en el diseo artstico de productos. Comn es que el diseador permite primero que los blancos y el problema madura en el

subconsciente por un perodo de tiempo, y si todo va bien, la solucin 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, haba ideado ya muchos contornos para el libro futuro, pero todos se haban parecido insustanciales... Este destello verdadero, la innovacin genuina se parece una ocurrencia mstica y no dura largo. Despus usted puede tratar conscientemente entenderlo y hacerlo claro a se. Slo despus usted puede comenzar a recoger la materia nueva de un punto de vista novela, y entonces sigue la concentracin final en la escritura que puede tomar varios aos... " (1980, p.398...400.)

Waltari acenta que el mejor arreglo viene del subconsciente, no por planificacin franca en el papel an en el caso que el trabajo se basar en muchos de informacin 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 ms adelante cuando realmente necesito estos elementos para mi trabajo, se volvern al pensamiento consciente como hechos evidentes. Si esta manera se olvida de algunos detalles, yo he concluido que esos detalles eran quizs no realmente importantes... Si tratara de anotar los pasajes ms largos antes su tiempo su idea muriera: el pensamiento se atiesara prematuramente de modo que yo no pueda ms lo explota." (ibid. p.406.)

Algunos artistas creativos creen que sera perjudicial disturbar o tratar de acelerar los funcionamientos del subconsciente. Las ideas ms ingeniosas son las ms 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 preparacin del escenario representa el arte del cazador. La creatividad es una cuestin de poner en escena un problema con una disposicin tal, que algo empieza a ocurrir, aparece, y entra dentro de l. Ahora un ente est "hacindose" ah, algo se hace ms visible, ms creble. Pero est slo atrapado muy dbilmente; 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 cognicin 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 invencin que el cerebro necesita, al lado de la base lgica para la solucin del problema, tambin el estmulo que las capas ntimas del cerebro normalmente estn produciendo toda la hora. Este estmulo no es relacionado con el problema consciente y, porque no sabemos su estructura, aparece ser al azar. En base de estos dos estmulos el cerebro entonces produce las soluciones tentativas para el problema, y la cognicin entonces comienza a evaluar stos de la misma manera que la seleccin natural elimina los

mutantes no aptos segn la teora de Darwin. Eventualmente una de ellas se valida en la evaluacin consciente y el artista comienza a desarrollarla ms lejos.
Innovacin en grupo de trabajo

No hay mtodo fijo para la creacin de innovaciones. Sin embargo es posible estimular un esfuerzo as. Para un grupo de trabajo a la caza de innovaciones, hay algunas tcnicas especiales, como:
y y y

enumeracin sistemtica de todas las alternativas previamente conocidas listas de soluciones parciales/incompletas y combinarlas de nuevas maneras, con intencin de producir resultados nuevos torbellino o lluvia de ideas (brainstorm): de 5 a 12 personas se renen con el fin de desarrollar gran cantidad de ideas inmaduras, inacabadas. Criticarlas en la reunin est prohibido, con el fin de conservar el espritu creativo de la reunin. "La cantidad genera calidad": cuando hay gran cantidad de ideas, se hace probable que algunas entre ellas produzcan algo fructfero. la sesin sinctica: una prctica que implica varias fases, en que se promueve inicialmente el torbellino de idas, y posteriormente la maduracin de stas. El objetivo es evitar soluciones viejas y convencionales. De tanto en tanto, los participantes de la sesin empiezan con una excursion mental en que toman distancia ellos mismos del problema y de las vas tradicionales donde sus pensamientos se han anclado.

Todos estos mtodos comparten algunos principios comunes:

y y y y

La blanco se debe definir inicialmente, pero no demasiado exacto. Durante la generacin de ideas stos no deben ser desaprobados. Las ideas generadas se deben registrar inmediatamente (quizs en vdeo), porque puede suceder que varias propuestas se presentarn en una sucesin rpida. Debe haber perodos de la maduracin y de relajar, quizs consultando con la almohada.

Los participantes deben intentar olvidarse las actitudes que podran inhibir la innovacin, tal como (segn Johnsson y Varjoranta, 50):
y y y y y y y y y

Actitud negativa respecto a la imaginacin, recibida a menudo de padres y de profesores. Modestia, subestimacin de propias ideas. Pereza del pensamiento, una fijacin superficial a modelos heredados de reflexionar. Confianza demasiada en racionalidad y lgica. Narcisismo, egotismo excesivo. Confianza en la autoridad. Ambicin egosta, desgana al trabajo en equipo y cooperacin. El miedo de cometer un error. Aversin a parecer tonto o estpido.

Mtodos participativos
Un proyecto normativo apunta a desarrollar una propuesta que sea aceptable para todos grupos de inters pertinentes. La manera ms fcil y ms confiable de alcanzar tal consenso (aunque no siempre es posible) deber preparar la propuesta en una cooperacin cercana con estos grupos de inters. En el caso afortunado que suficientes personas de los grupos principales de inters estn disponibles para participar en el proyecto, es a menudo posible or sus opiniones no slo en la etapa final de aceptar o de rechazar la propuesta, pero en lugar en varios momentos durante el proyecto. Este mtodo de consultacin 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 mtodos participativos muy diferentes del trabajo solitario de un investigador acadmico. Tpicos son los procedimientos y las caractersticas 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, desearn de todos modos discutir la propuesta final "prematuramente" como el investigador quizs piensa. Coleccin de datos consigue una dimensin normativa. Simultneamente con los hechos descriptivos que se renen con medidas objetivas, tambin opiniones normativas sobre el objeto del estudio se pueden registrar. Ejemplos de la tipo normativo de recoger datos se dan en la pgina Reunir datos normativos. Los mtodos diferentes de la recogida de datos se pueden mezclar. No es necesario evitar los disturbios que pueden resultar de usar simultneamente los mtodos de observacin, de entrevista y de experimento. Cul 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 evaluacin y alcanzar unanimidad pueden a veces ser arduas y lentas. Un proyecto normativo afecta a menudo las vidas de muchos grupos de inters, y cuando mucha gente participa en las discusiones es a menudo imposible proceder directamente a la sntesis y la propuesta. Algunas razones usuales de complicaciones son:
y y y

El resultado ser en el futuro y por lo tanto su formulacin detallada toma tiempo. El contexto futuro, tambin, puede ser difcil de predecir. A causa del gran nmero de personas implicadas est difcil de convenir sobre el resultado final, sobre los mtodos de alcanzarlo, o sobre los costes. Las propuestas son hechas por los investigadores, planificadores y diseadores, 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 discusin ms tarde, y quizs necesitan clarificacin de algunos detalles.

Los mtodos que a menudo se utilizan para arbitrar opiniones contrastantes, se enumeran en la pgina Conciliar opiniones contrastantes. Es normal que toma tiempo de alcanzar la aceptacin general cuando las opiniones difieren. Al contrario, es tpico de anlisis participante que una parte del trabajo tiene que ser hecha de nuevo a veces. Si hay muchos tales regresos, el proceso comienza a asemejarse ms a un crculo que a una sucesin linear de decisiones. De hecho, un espiral como el que est a la derecha se ha definido a veces como modelo tpico de un proyecto del desarrollo. Las fases tpicas en un "espiral del desarrollo" son como sigue.
1. Descripcin normativa del estado inicial y definir la necesidad de mejoras 2. anlisis de relaciones de cosas y de posibilidades para alteracin 3. sntesis: propuesta para la mejora 4. evaluacin 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 tpicos de participacin normativa se discuten abajo. El diseo "sastre-hizo" es el arreglo normal de la cooperacin para producir un producto nico para una persona o para un grupo de gente pequeo tal como una familia. Cuando es posible reunir todos los diseadores y usuarios del producto alrededor de una mesa, ellos pueden trabajar en equipo, deliberando juntos los problemas del diseo. Las soluciones a los problemas se encuentran y se aceptan a menudo colectivamente, pero es la tarea del diseador profesional explicar las restricciones tcnicas y producir alternativas, quizs con los mtodos de crear propuestas discutidas anteriores. El usuario emplea al planificador o diseador normalmente como un consejero. Cundo un grupo grande pero no organizado de personas est dispuesto a desarrollar un producto en cooperacin, los mtodos convenientes se pueden encontrar bajo la etiqueta de diseo colectivo, cul mtodo se ha utilizado a veces al planear un grupo de casas, vase Kukkonen (1984). No es muy comn, pero que puede tener algn inters de los puntos de vista de investigacin y de democracia. El diseo colectivo est basado en reuniones de los diseadores y los usuarios futuros de los productos. A causa del gran nmero de usuarios, sus opiniones a menudo difieren, y una discusin para asentar el conflicto se necesita. Para acelerar la discusin puede ser recomendable organizar a los participantes en "grupos de inters" temporales. Al lado de estos grupos, hay siempre un "equipo tcnico" de los diseadores profesionales (y posiblemente de los investigadores) que preparan continuamente propuestas alternativas para ser discutidos en reuniones generales semanales con los usuarios. Las fases tpicas en la planificacin participativa son:

1. Organizar los grupos de inters que entonces pueden decidir tener reuniones privadas si lo sienten necesarios. 2. Anlisis. Los grupos de inters clarifican sus metas, primero solamente a s mismos. 3. Diseo y negociacin entre los grupos de inters. Si un grupo se parece sufrir debido a una propuesta este grupo debe quizs recibir una remuneracin para ella. 4. Ratificacin con tan unnime una decisin como es posible. (Explicacin ms detallada en Planificacin participativa.)

Un "lenguaje de diseo" comn se necesita para que los clientes sin formacin tecnolgica puedan describir cosas que esperan de los productos futuros. Para el diseo de viviendas, este tipo de lenguaje se ha desarrollado por Heikki Kukkonen (1984) (vanse 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 diseo colectivo, el diseador debe, previamente, preparar un repertorio que muestre a los usuarios todas las alternativas posibles que tienen. Adems, el repertorio debe contener advertencias pertinentes sobre cada eleccin, por ejemplo sus beneficios, inconvenientes y costes. Pero no corresponde al diseador criticar las elecciones del usuario ms que lo que el camarero de un restaurante critica los platos que su cliente elige. Un ejemplo bien conocido del material terico, preparado por adelantado para el diseo colectivo, est A Pattern Language (1977), desarrollado por Christopher Alexander et al., se basa en una investigacin bastante costosa tanto con respecto al aspecto prctico como a la comodidad. El "lenguaje de patrones" de Alexander consista en 253 instrucciones de diseo, aunque los autores tienen buen cuidado en afirma que tambin stas son slo 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 arquetpicos o comunes a todos los seres humanos. Cada uno de los patrones de Alexander sigue la misma frmula que se ha descrito en la pgina x del libro: la primera imagen es un ejemplo arquetpico y hay tambin una breve lista de otros patrones que estn relacionados con ella. La lista es seguida por una ilustracin que clarifica qu significa este patrn. Tras esto se da cuenta del conocimiento emprico sobre el patrn y variaciones de su aplicacin. Ejemplos de los patrones de Alexander. El mtodo de diseo colectivo con estos patrones se explica en The Oregon Experiment, por Alexander et al. (1975). Gracias a investigacin intensiva, algunos productos ahora poseen tan confiable una teora que disear productos nuevos es bastante fcil. Algunos investigadores, sobre todo Yona Friedman (1975 B) y Nicholas Negroponte, han propuesto que en base de tal teora - los estndares, algoritmos, ejemplares y las reglas para ajustarlos - sera posible construir una mquina de diseo, es decir un aparato programado que se puede usar para producir automticamente un diseo para un producto nuevo. El cliente expresa sus deseos apretando las teclas de un men, y el autmata despus crea un diseo en base de las reglas que un diseador profesional ha programado en la mquina por adelantado. La ventaja

estara el reducir no solamente el trabajo de diseo, pero tambin mejorar el servicio al consumidor que tendra as ms opciones al comprar un producto. Hay pocas mquinas de diseo en operacin hoy, pero pueden llegar a ser ms frecuentes en el futuro. La idea es interesante tericamente, porque una teora del diseo explcita 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 diseo que el cliente quiere ordenar. No es difcil construir una mquina de diseo para tales productos que consisten en partes prefabricadas y los clientes slo escogen los componentes que desean incluir en el producto. En hecho, esto es qu hoy ya sucede, no slo en la cafetera automtica tradicional, pero tambin en los sistemas de comercializacin de los muebles de cocina y de computadoras, especialmente cuando stos se compran en el Internet. El paso siguiente podra quizs agrandar la seleccin hasta incluir dimensiones, colores y formas del producto, y posiblemente tambin transmitir el diseo acabado a las mquinas de la fabricacin, creando as un sistema de la fabricacin automatizada.