El desarrollo de un sistema de información, independientemente de su tamaño y complejidad, requiere muchas actividades coordinadas y el empleo de una diversidad de herramientas y modelos. La metodología de desarrollo de sistemas es una forma estándar de organizar y coordinar estas actividades. 
El análisis de sistemas llega a la raíz del problema o a la necesidad y define los requerimientos de los usuarios.

Herramientas para Análisis:

Estas herramientas ayudan a los especialistas en sistemas a documentar un sistema existente, ya sea éste manual o automatizado, u a determinar los requerimientos de una nueva aplicación.
Herramientas para la recolección de datos. Capturan detalles que describen los sistemas y procedimientos en uso. Documentan procesos y actividades de decisión. Se utilizan para apoyar la tarea de identificar requerimientos.
Herramientas para la diagramación. Crean representaciones gráficas de sistemas y actividades. Apoyan el dibujo y revisión de diagramas de flujo de datos e iconos asociados con el análisis estructurado. Asimismo incluyen programas para representación en diagramas de flujo.
Herramientas para el diccionario. Registran y mantienes descripciones de los elementos del sistema tales como grupos de datos, procesos y almacenamiento de datos. Con frecuencia proporcionan la capacidad de examinar las descripciones del sistema para decidir si son incompletas o inconsistentes.

Métodos para la Obtención de Información:

Todo análisis y diseño de un sistema implica la búsqueda y obtención de información relevante para la estructuración y definición de problemas, generación de soluciones, validación de soluciones, etc.
La información en una organización no siempre es fácil de obtener, más bien es un proceso lento y costoso, que exige tiempo y dedicación por parte del analista de sistemas. Las fases de búsqueda de información en cualquier proyecto, suelen ser  grandes consumidoras de tiempo, y el éxito de los resultados depende en gran medida de la calidad de la información.
Es muy común que la información requerida no se encuentre escrita, o inclusive que ésta no se conozca. Esto hace necesaria la interacción del analista con las personas del sistema para identificar y/o generar la información faltante. Si se cuenta con información escrita formal y adecuada utilícelas, le ahorraría tiempo y le facilitaría la comprensión del sistema.
Existen métodos básicos para recopilar información dentro de una organización o sistema social. Estos incluyen

a) Cuestionarios
b) Entrevistas
c) Sondeos
d) Encuestas
e) Collage
f) Dibujos
g) Diagramas de flujo de datos
h) Tablas de Organización
i) Descripción de puestos
j) Manuales Operativos.
k) Representación física de las Organizaciones.

Existen básicamente tres fuentes de hechos dentro y alrededor de la organización:

1. El sistema actual.
Es verdaderamente raro que un analista tenga la oportunidad de desarrollar un sistema de información en donde anteriormente no haya existido ninguno. Con frecuencia se dedica una gran cantidad de tiempo investigando y documentando el sistema anterior, pero un análisis de ventajas y desventajas puede ayudar  a determinar cuándo y qué tan extensamente debe estudiarse el sistema anterior.
Las principales ventajas de analizar el sistema anterior:

• Eficacia del sistema actual.
• Ideas de diseño.
• Reconocimiento de recursos.
• Conocimiento de conversión.
• Punto de partida común.

• Gastos
• Barreras Innecesarias.

3. Fuentes externas.
La exploración de otros subsistemas de información dentro de la organización puede ser una fuente útil de recopilación de datos, procesamiento de datos o de ideas y técnicas para el reporte de la información.
 

Investigación Preliminar

¿Cuántas veces se está en situaciones en donde se pregunta si no existe una mejor manera de hacer algo?

Una compañía en crecimiento, puede contemplar a los sistemas de información computarizados como una forma decrecer continuamente, sin tener dificultades en varios procesos, como por ejemplo en el proceso de pedidos de clientes. Una petición se puede iniciar por varias razones, pero la clave es que alguna persona de la empresa, ya sea un gerente, un empleado o un especialista de sistemas, inicie el requerimiento de un sistema de información. Cuando esto se realiza, empieza la primera etapa del ciclo de vida del un sistema: La Investigación preliminar.

Esta primera etapa del ciclo se divide en tres actividades:

   1.Clarificación de requerimientos
   2.Estudio de factibilidad
   3.Aprobación del requerimiento

CLARIFICACION DE REQUERIMIENTOS
El analista debe de observar en forma objetiva lo que ocurre en la empresa, ya que muchas veces los requerimientos no están claramente establecidos, por lo que, el proyecto requerido debe examinarse para determinar precisamente lo que desea la empresa.
En muchos casos, los usuarios y los analistas de sistemas trabajan conjuntamente, el usuario tiene ideas bastante definidas acerca de la salida requerida, las entradas necesarias y, posiblemente una noción general de los controles necesarios.

ESTUDIO DE FACTIBILIDAD
Es determinar si el proyecto es factible. Los aspectos para determinar la factibilidad del proyecto son: 
Factibilidad técnica: Se debe de investigar si se puede realizar el trabajo para el proyecto con el equipo actual, el personal y el software disponible.
Factibilidad económica: ¿Qué beneficios tendrá la creación del sistema en cuanto a costo/beneficios?
Factibilidad operativa: Se debe de investigar si el sistema que se desarrolla se pondrá en marcha, si habrá resistencia de los usuarios en cuanto a este.

APROBACION DEL REQUERIMIENTO
En muchas empresas tienen varios proyectos que se encuentran en marcha, por lo que la gerencia debe de decidir qué proyectos son más importantes y entonces se programan. Posteriormente, cuando se terminan dichos proyectos, puede iniciarse el desarrollo de la aplicación propuesta.

El resultado de estas actividades será aprobar el requerimiento para una atención posterior o rechazarlo como no factible.

Determinación de requerimientos 

El analista de sistemas llega a la raíz del problema o a la necesidad y define los requerimientos de los usuarios. Con frecuencia, los que los usuarios creen que necesitan o lo que parece ser le problema al principio, resulta ser algo totalmente diferente después de un análisis profundo. Cuando el analista de sistemas se reúnen con los usuarios y ambos empiezan a escarbar, surgen nuevos y en ocasiones diferentes requerimientos que al principio no eran evidentes.

La Determinación de Requerimientos es el estudio de un sistema para conocer cómo trabaja y dónde es necesario efectuar mejoras.

El objetivo del análisis de sistemas es comprender situaciones, no resolver problemas. Por tanto, los buenos analistas hacen hincapié en la investigación y el cuestionamiento para conocer cómo opera el sistema e identificar los requerimientos que tienen los usuarios para modificarlo o proponer uno nuevo.

Un requerimiento es una característica que debe incluirse en un nuevo sistema.

Los analistas al trabajar con los empleados de la empresa, deben estudiar el proceso que se efectúa actualmente para así poder contestar las preguntas claves de esta fase.

¿Qué y cómo se está haciendo?
¿Qué tan frecuentemente ocurre?
¿Qué tan grande es la cantidad de transacciones o decisiones?
¿Existe algún problema?, sí el problema existe,
¿Qué tan serio es y cuál es la  principal causa que lo origina?

Para que el analista pueda contestar estas preguntas deberá hablar con diferentes grupos de empleados para así recabar diferente opiniones sobre las causas por las que se originan las cosas.
Los métodos de recolección pueden ser cuestionarios a grupos de personas o individuales, también se requiere estudiar los manuales y reportes, observar los comportamientos y actividades, recabar formas y documentos para entender los procesos.
Una vez, recopilada la información, los analistas estudian los requerimientos para identificar las características del nuevo sistema.
El enfoque primario durante el análisis de sistemas debe estar en las operaciones de la empresa, los requerimientos de los usuarios y los componentes estructurales de la entrada, la salida, la base de datos y los controles. 
Uno de los mayores errores que se repiten una y otra vez en el trabajo en sistemas se resume de la siguiente manera: “Vamos a conseguir una computadora; luego vamos a  ver si existe algún software que corra en ella; y después de eso, vamos a ver como lo vamos a usar”.
El objetivo tanto del usuario como de los analistas de sistemas durante el análisis de sistemas es llegar a un acuerdo de ideas para establecer lo que realmente se necesita para realizar el trabajo y lo que el sistema les puede proporcionar.

Algunos dicen que tan solo un 10% del tiempo total del desarrollo del sistema. Otros opinan que hasta un 40% más. Otros más piensan que dedicar "demasiado tiempo" al análisis de sistemas da por resultado una "parálisis del análisis", en donde  la víctima no se puede mover de esta fase para pasar a otras debido principalmente a la incertidumbre. En cualquier caso la base de un buen sistema de información con los que los usuarios estarán contentos en un buen y completo análisis de sistemas.

Reporte de terminación del análisis de sistemas:

A lo largo de toda la fase de análisis de sistemas el analista deberá mantener una extensa comunicación con el solicitante, y demás personal de proyectos. Esta comunicación comienza con la propuesta para realizar el análisis. En forma continua este esfuerzo  de comunicación incluye una retroalimentación a las personas entrevistadas, u observadas, con relación a lo que el analista entiende, la verificación con el personal usuario con respecto a los hallazgos.

Sin embargo, quizás  la comunicación más importante de todas es el reporte de terminación del análisis de sistemas, que describe los hallazgos del análisis. El formato y el contenido de este reporte incluye lo siguiente:

a) Exposición de las razones y alcance del análisis.
b) Una lista de los Principales Problemas Identificados.
c) Una presentación de todos los requerimientos de los usuarios.
d) Un planteamiento de todas las suposiciones críticas hechas por el analista durante el análisis.
e) Alternativas del sistema (3 o 4).
f) Una proyección de los recursos requeridos.
g) Cualquier recomendación referente al sistema.
 

CASO DE ESTUDIO: S.E.A.T.S. venta de Boletos.
 
 

Ejemplo Tomado del Libro 
Diseño de sistemas de Información. (teoría y práctica)
Burch-Gridnotski
Capitulo 16. Análisis de Sistemas
Pag. 654

REPORTE DE TERMINACION DEL ANALISIS DE SISTEMAS
Mayo 10, l999
PARA: Todos los jefes de departamento
DE: Sally Forth, jefa de análisis de sistemas
ASUNTO: Programa de­ sistema de eventos y boletaje (SEATS)
COPIAS: John Bali, Director del centro de eventos y Tyronne Topps, CISO
 

Razones y alcance:
El análisis de sistemas se realizó para determinar la factibilidad y la dirección del SEATS.  Este reporte contiene los hallazgos del análisis de sistemas.

Principales problemas identificados:
Problemas importantes diversos que experimenta rutinariamente el personal del centro de eventos:

1. Falta de coordinación entre los departamentos.
2. Falta de información sobre el estado de los recursos.
3. Falta de información sobre los recursos requeridos para la programación.
4. Falta de información sobre ventas y gastos para los eventos.
5. Un control interno deficiente del efectivo y los boletos.

1. La oficina de actividades es incapaz de comunicar en forma oportuna los arreglos especiales requeridos para eventos especiales como peleas de box, conciertos y convenciones. Por ejemplo, para los conciertos y convenciones se requiere una mayor comunicación debido a que con frecuencia no se les informa de los requerimientos especiales como la preparación de salas o la planeación de una feria de exhibición de proveedores hasta mucho tiempo después, por lo que no se puede planear correctamente y notificar a los departamentos involucrados las necesidades adicionales para el evento. Por otra parte, los juegos universitarios de basquetbol requieren poca coordinación y el nivel actual de comunicación es adecuado.
2. El sistema actual para la reservación de eventos ha fallado en varias ocasiones, dando por resultado registros duplicados de eventos. La falta de un sistema central para dar seguimiento al estado de la negociación ha dado por resultado que diferentes representantes del centro de eventos prometan y reserven dos tipos conflictivos de eventos en el mismo espacio de tiempo, haciendo extremadamente difícil su atención.
3. La oficina de actividades con frecuencia es incapaz de determinar el estado de recursos específicos disponibles en el centro de eventos para una cierta fecha. El resultado de esto es la incapacidad de cumplirlos compromisos con los promotores y el personal en forma oportuna debido a que no se programó    personal con suficiente tiempo.
4. Las ineficiencias relacionadas con la programación y la subestimación de los recursos disponibles en el centro han conducido a una política de permitir un tiempo de holgura entre los eventos para mantener la calidad del servicio. Si el trabajo se computariza, podremos incrementar el número de eventos y programarlos más próximos entre sí. Esto nos permitirá incrementar el uso de las instalaciones más del 30 por ciento del que se tiene actualmente.
5. La oficina de actividades no es capaz de determinar en una forma oportuna y costo-eficaz el estado de las ventas de boletos a la fecha.  Esta información la requiere el personal de la oficina de programación para determinar si se cancela o no un evento antes de la fecha permitida en el contrato.
6. La oficina de boletos no es capaz de controlar la venta de boletos entre el personal de ventas en la oficina de boletos.  El control sólo puede lograrse reduciendo personal o centralizando la información. La reducción del personal no es factible considerando el volumen de las ventas de boletos. La única alternativa es la centralización de la información.
7. La incapacidad para dar seguimiento a las ventas mediante tarjeta de crédito da por resultado que el procesamiento y cobranza de los pagos mediante tarjetas de crédito sea lento.
8. La reconciliación del efectivo consume mucho tiempo. Nunca sabemos lo que debemos tener en recibos de caja debido a que el despacho de boletos no está controlado.
9. El control deficiente en la venta de boletos de los asientos asignados ha dado por resultado que el mismo asiento se venda dos veces o más. En ese mismo sentido, algunos asientos permanecen vacíos. Esta situación contribuye a pérdidas de ingresos y a una clientela molesta.

Planteamiento de todos los requerimientos de los usuarios:

Durante las entrevistas y a partir de otras investigaciones identificamos los siguientes requerimientos específicos:

1. Una comunicación oportuna y eficiente de los requerimientos de los eventos para todos los departamentos.
2. Una producción y distribución de boletos en forma eficiente y exacta.
3. Información oportuna sobre el estado de la venta de boletos y los gastos incurridos por cada evento.
4. Un sistema para asegurar un control interno adecuado de la venta de boletos y del efectivo dentro de la oficina de boletaje.
5. Un sistema sencillo eficiente para reconciliar el efectivo.
6. Un sistema para el manejo de las ventas mediante tarjetas de crédito.

No se pueden determinar todas las restricciones futuras posibles en la fase de análisis de sistemas. El desarrollo futuro se basa en varias suposiciones críticas.

1. Después de un período de conversión en paralelo, el sistema viejo se eliminará y el único sistema que se utilizará será el que se desarrolle como resultado de este proyecto propuesto.
2. El sistema final desarrollado requerirá que se capacite al personal según se requiera, y deberán comprometerse los fondos y el apoyo para la capacitación.
3. El hardware y el software requeridos pueden instalarse. Ninguna limitación física de las instalaciones impedirá su implementación.

Recursos requeridos:

Si se hace el compromiso para el desarrollo de sistemas, el centro de eventos deberá identificar los recursos adicionales con los que no se cuenta actualmente o quitarle al personal parte de su tiempo dedicado a sus compromisos actuales.

Estos requerimientos de recursos incluyen:

1. La fase de desarrollo requerirá personal adicional para formar un equipo de desarrollo.  Anticipamos la necesidad de dos diseñadores de sistemas. Deberán tener experiencia en el diseño de sistemas y experiencia en un lenguaje programación.
2. Si el desarrollo se realiza internamente, se requiere la adquisición del   hardware y el software según se especifique en el diseño de sistemas.  Si los   programas se adquieren de un proveedor externo, se anticipa una adquisición   similar para el soporte del producto obtenido.  En este momento se anticipa   que se requerirán dos computadoras personales con software para procesamiento de palabras y para el desarrollo de programas.
3. La fase del diseño general de sistemas requerirá 1,400 horas-hombre para su terminación a un costo aproximado de $28,000.
4. Para tener éxito se requiere el apoyo de la gerencia.

Desarrollo de diagramas de flujo de datos
Usando un enfoque de arriba abajo.
 

1. Haga una lista de actividades del negocio y úselas para determinar varios:

• Entidades externas.
• Flujo de datos.
• Procesos
• Almacenes de datos.
2. Cree un diagrama de Contexto que muestre las entidades externas y los flujos de datos que entran y salen del sistema. No muestre ningún proceso detallado ni almacén de datos.
3. Trace un Diagrama O, el siguiente nivel. Muestre los proceso pero manténgalos generales. En este nivel muestre los almacenes de datos.
4. Cree un Diagrama hijo para cada uno de los procesos del diagrama O.
5. Revise buscando errores y asegúrese  que las etiquetas que se asignan a cada proceso y flujo de datos son significativas.
6. Desarrolle un diagrama de flujo de datos físicos a partir del diagrama de flujo de datos lógico. Distinga entre procesos manuales y automatizados, describa los archivos actuales y reportes por nombre y añada controles para indicar cuando están terminados los procesos o suceden errores.
7. Divida el diagrama de datos físico, separando o agrupando partes del diagrama para facilitar la programación e implementación.

La definición del problema, la reunión de datos factuales y sus análisis, producen una gran cantidad de entradas para el analista de sistemas. Sus procesos mentales tanto conscientes como inconscientemente, relacionan evalúan, integran, descartan, cancelan, confirman, eliminan y sintetizan, siempre de acuerdo con los objetivos del sistema que se esté estudiando  y  los del sistema de información para la administración.
Todas y cada una de las alternativas que queden deberán incluirse en una lista, junto con las ventajas y desventajas que se les apliquen. A cada una de ellas deberá atribuirse un valor cuantitativo. El efecto de la aplicación de cada alternativa deberá evaluarse de acuerdo con las metas a corto y largo plazo. Finalmente, el analista debe recordar que el nuevo sistema requiere la aprobación por parte de la administración. Por lo tanto, su proposición deberá hacerla en términos generales, haciendo hincapié en los resultados, de acuerdo con los objetivos de la organización.
 

Selección y Evaluación de alternativas:

Con el análisis de la empresa y una vez detectado los problemas que se tienen que resolver, es posible ver los requerimientos y necesidades del nuevo sistema de información, el cual debe cumplir con los objetivos del sistema.
A continuación se evaluarán las diferentes alternativas que cumplan con los objetivos deseados, y se seleccionará aquella que adquiera la mejor evaluación y se adapte mejor a la empresa.

Al tener varias alternativas de solución, existen varias posibilidades de cómo hacer las cosas, de estas manera, tenemos diferentes caminos para llegar al mismo lugar; en la forma en que satisfagan mejor al problema, se obtendrá la mejor alternativa, por lo tanto hay que conocerlas a detalle cada una de ellas.

Seleccionar entre soluciones alternativas propuestas para el problema significa resumir y analizar datos de todas las fuentes para llevar a cabo análisis de costo-beneficio. Algunos aspectos del análisis de problemas administrativos pueden computarizarse utilizando algoritmos y modelos programados. Sin embargo, los elementos críticos en análisis administrativo no son los cálculos y comparaciones, si no el juicio administrativo requerido para saber cuáles métodos analíticos deben aplicarse para analizar los resultados.

Las alternativas consideradas para el desarrollo de un nuevo sistemas por lo general son:

1. Sistema actual modificado. Sistema de registro de transacciones.
2. Sistema parcialmente computarizado. Sistema para el Soporte en la toma de decisiones.
3. Sistema de cómputo completo. Sistema estratégico.

El objetivo para la mejor selección y evaluación de las alternativas es la siguiente:

“Seleccionar el sistema de información que mejor se adapte a las necesidades de la empresa, para obtener la información más oportuna y relevante, de manera que ayude a la toma de decisiones.”

a) Objetivos que debe cumplir la alternativa.
Los objetivos del sistema han sido divididos en objetivos obligatorios (lo que se debe hacer) y los objetivos deseados (lo que queremos que haga además de lo básico), esto con la finalidad de establecer los lineamientos para la elección de la alternativa que mejor cumpla con los requerimientos del sistema bajo estudio.

Objetivos Obligatorios: Son imprescindibles, deben cumplirse para garantizar una decisión exitosa; de esta manera, al evaluar las alternativas en función con sus objetivos  obligatorios, la que no cumpla con éstos inmediatamente será descartada del análisis.
Estos objetivos se determinan según lo que el gerente o tomador de decisiones quiere que tenga como mínimo el nuevo sistema de información

Ejemplos:

Objetivos Obligatorios:

• Producción de informes sobre el nivel de inventarios.
• Registro confiable de ventas.
• Informes históricos de ventas y compras.
• Respuesta rápida al usuario.
• Rápidas Consultas al almacén.
• Pronósticos de ventas.
• Información confiable
• Información oportuna.

Ejemplos

Objetivos deseados:

• Fácil aceptación y adaptación del personal
• Sectorización de la información.
• Instalación rápida (a más tardar 3 meses)
• Poca papelería para su uso.
• Diversidad de registro de operaciones.
• Posibilidad de satisfacer nuevas necesidades.
• Calidad en la presentación de la información.
• Costo moderado.
• Obtener una ventaja competitiva en el servicio al cliente.
• Disminuir las posibilidades de errores.

c) Tablas de Evaluación de Alternativas:

Ver forma de Evaluación de alternativas contra objetivos obligatorios:

Ver forma de Evaluación de la alternativas contra objetivos deseados
(Para cada alternativa que cumpla con todos los objetivos obligatorios se genera una tabla.)

d) Selección de la mejor alternativa:
La toma de decisiones y el clímax del proceso de solución de problemas administrativos depende casi por completo del juicio del administrador.
Una vez evaluadas las alternativas, se procede a seleccionar la mejor de ellas, según sus características y tomando siempre en cuenta la decisión final del gerente o tomador de decisiones. El analista recomienda pero debe permanecer al margen de la decisión final.
Es importante señalar que las ventajas de un sistema de computo sobre otros, muchas veces llegan a ser abrumadoras y hace que la persona que piensa invertir en un proyecto se incline por éste, que aparentemente ofrece sólo ventajas, por lo que es trabajo del analista recalcar y resaltar las ventajas y  desventajas que el sistema puede presentar. Defendiendo siempre lo mejor para el nuevo sistema.
 
 
 

1. Analizar el caso del "Fiasco del Salón recibidor" Libro James Senn,  pagina 120
2. Investigar y contestar las preguntas sobre Análisis Estructurado y Prototipos.
3. Enviar a los alumnos a investigar un procedimiento interno de una empresa y elaborar un diagrama de flujo de datos.
4. Iniciar una entrevista con el gerente de la "Film Magic". (clase)
5. Elaborar  un diagrama de flujo de datos del área de atención al público del sistema de renta de videos de "Film Magic".
6. Elaborar un reporte de terminación del análisis del sistema de renta de videos de "Film Magic"
7. Recomendar la lectura del Libro "El Arte de Resolver Problemas"
8. Ejercicio: Problema 1 Libro Kendall&Kendall pagina 97
9. Ejercicio: Problema 1 Libro Kendall&Kendall  pagina 395
10. Ejercicio: Problema 4 Libro James Senn  Capitulo 4 pagina 238 
11. ¿Qué es el análisis de  sistemas? Explique.
12. ¿Cuáles son las fuentes de datos para el análisis de sistemas?
13. ¿Cuál es el objetivo tanto del usuario como de los analistas de sistemas durante el análisis de sistemas? 
14. ¿Qué es un prototipo de sistemas?
15. ¿Qué es el análisis estructurado?
16. ¿Cuál es la diferencia entre el método del ciclo de vida de desarrollo de sistemas y el análisis estructurado? ¿Se pueden vincular estos métodos?
17. ¿Qué habilidades de un analista de sistemas no se aprenden en clases?
18. ¿Qué son los requerimiento de  un sistema de información? 
19. ¿Qué utilidad tienen los diagramas de flujos de datos?
20. ¿Cuándo aplicarías la Herramienta de recopilación de datos Entrevista y cuando el Cuestionario?
21. Al iniciar una entrevista con el gerente de una empresa que le solicita a usted analista de sistemas la iniciación de una análisis de sistemas ¿qué preguntas le formularía? (escriba al menos 5).
22. Señale el método de obtención de datos que usted aplicaría en la investigación de las actividades siguientes: Elija entre Entrevista, Encuestas, Muestreo, Cuestionarios. Explique brevemente.

1. Desarrollo de estudios de mercado.
2. Diseño del presupuesto del gerente de ventas.
3. Departamento de Atención a clientes.
4. Sistema de Nomina de una empresa.
23. “Muchos analistas de sistemas, así como las administraciones, cometen el error de suponer que el desarrollo de sistemas de información esta controlado por restricciones técnicas, económicas y de programación. Existe una cuarta limitación, que puede ser muy grave.” ¿cuál es esa cuarta limitación. Explique
24. “La Determinación de requerimientos con frecuencia, los que los usuarios creen que necesitan o lo que parece ser le problema al principio, resulta ser algo totalmente diferente después de un análisis profundo.” Explique si esta o no esta de acuerdo con la expresión anterior.
25. Los analistas de sistemas son responsables de dotar a los usuarios en las organizaciones con el soporte de sistemas de  información que necesiten. En muchas situaciones de desarrollo, el analista puede formular varias opciones diferentes para cumplir con los requerimientos de los usuarios. Como es de esperarse, las opciones difieren en costos, beneficios y niveles de sofisticación. Asimismo, la forma en que se integran los recursos computacionales para formar un nuevo sistema también serán diferentes.

Los analistas de sistemas se enfrentan de manera constante con las siguientes preguntas: de las muchas opciones del sistema que existen 
¿Cuáles deben de proponerse a la administración?, 
¿Qué es lo que entiende por mejor opción? 
¿Se debe recomendar siempre la mejor opción para un sistema sin importar su costo?
Proporcione su opinión con respecto a esta situación en base a su pensamiento de analista de sistemas. 
26. De que manera se ha vuelto estratégico para el crecimiento industrial el uso de sistemas de información.