GUIA 2: SISTEMAS DE INFORMACIN 1.

Mencion en sus palabras, despus de haber indagado en la red, el porqu de los objetivos de los sistemas de informacin. Dar soporte a los objetivos y estrategias de la empresa. Proporcionar informacin a todos los niveles. Conseguir que se adapte a la evolucin de la empresa.
Porque en ella da soporte de datos a la empresa, y poder tomar decisiones, optimizar las operaciones de la empresa, para dar as una ayuda ms fcil y rpida de todo lo que posea la empresa como sus metas y objetivos. Desde un ente administrativo y a los empleados de la empresa, proporcionar la informacin que se desea en todo el entorno de la empresa. Si la empresa es una PYMES, sea capaz de manejar pequeas bases de informacin, pero cuando ya sea una compaa de grandes proporciones, tengan los suficientes recursos para la optimizacin y el desarrollo de la empresa ya manejando grandes bases de datos Para obtener informacin detallada de los diagnsticos de la empresa en cualquier momento determinado dentro de la empresa con mucha facilidad y llevar la informacin de manera oportuna cuando la misma empresa lo requiera.

Utilizar la informacin como un recurso corporativo.

2. Mencion en sus palabras, despus de haber indagado en la red, el porqu de las estrategias para sistemas de informacin.
Para tener nuevos conocimientos de los negocios o mantener planes de negocio dentro y fuera de la empresa, y tenerlo en cuenta para el mismo desarrollo de la empresa Desarrollarlo mediante las actividades internas que se hagan dentro de la empresa, para la constante actualizacin de informacin que requiera la empresa. Se basa en todos los usuarios (personas) por el uso que le den, el administrador es el que acarrea profesionalmente y se responsabiliza por el diseo y almacenamiento de datos para la

Integrarlo en el plan general de la empresa.

Hacerlo depender de los procesos.

Fijar responsabilidades sobre los datos.

correcta gestin de datos, los cuales son estructurados cuidadosa y lgicamente correctos para los usuarios.

3. Mencione cuales son las caractersticas de los siguientes tipos de Sistemas de informacin y el tipo de funcionario (usuario) en una organizacin (nivel organizacional) en el que se centrara la utilizacin de cada uno :
Es la que procesa grandes cantidades de datos para mejorar una rutina diaria y realiza procesos de almacenamiento clculos y ordenamiento de informacin Es la que soporta una gama de organizacin de datos para procesar los mismos con el fin de analizar la toma de decisiones, se basa en hechos pasados y ejecuta procesos estructurados. Herramienta para realizar el anlisis de las diferentes variables de negocio con la finalidad de apoyar el proceso de toma de decisiones. Es la orientada a los usuarios de nivel gerencial, que permite monitorizar el estado de las variables de un rea o unidad de la empresa a partir de informacin interna y externa a la misma. Usuario: Los trabajadores.

Sistema de procesamiento de datos:

Sistema de informacin gerencial: Sistema de apoyo a toma de decisiones.

Usuario: Gerentes de nivel medio.

Usuario: Los altos directivos. Usuario: Ejecutivos.

Sistemas expertos.

4. En muchos aspectos cada Sistema de Informacin (SI) es similar a un organismo vivo: nace, crece, madura, muere. Este proceso evolutivo se llama ciclo de vida de los SI, y consiste de las siguientes fases: planeacin anlisis diseo implementacin utilizacin. Existen diferentes tipos de Ciclos de Vida que son representados mediante Modelos. Mencione Ventajas y Desventajas de cada uno de los Modelos que se han planteado: MODEL O DESCRIPCIN O GRFICA VENTAJAS DESVENTAJAS

Cascada pura

En un modelo en cascada, un proyecto progresa a travs de una secuencia ordenada de pasos partiendo de la especificacin de requerimientos hasta el mantenimiento del mismo.

1.-Se utiliza correctamente para ciclos en los que se tiene una decisin estable del producto. 2.-Puede constituir una eleccin correcta para el desarrollo rpido. 3.-ayuda a minimizar los gastos de la planificacin porque permite realizarla sin problemas. 4.-Funciona bien 5.-Evita una fuente comn de errores importantes. 1. No conlleva ninguna gestin; no se pierde tiempo en la planificacin, en la documentacin, en el control de calidad, en el cumplimiento de los estndares, o en cualquier otra actividad que no sea codificacin pura. 2. Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de progreso. 3. Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa est familiarizada con ste modelo. 4. Para proyectos pequeos que se intentan liquidar en un tiempo breve, o para modelos como programas de demostracin o prototipos desechables, el modelo codificar y corregir puede ser

1.- Dificultad para especificar claramente los requerimientos al comienzo del proyecto no permite flexibilidad en los cambios. 2.-No es imposible volver atrs utilizando el modelo de cascada pura, pero si difcil. 3.-Genera pocos signos visibles de progreso hasta el final. 1. El modelo resulta peligroso para otro tipo de proyectos que no sean pequeos. 2. Puede que no suponga gestin alguna, pero tampoco ofrece medios de evaluacin del progreso. 3. No proporciona medios de evaluacin de la calidad o de identificacin de riesgos. 4. Si al llevar tres cuartas partes de la codificacin descubre que el diseo es incorrecto, no hay otra solucin que desechar el trabajo y comenzar de nuevo.

Codificar y corregir

Es un modelo poco til, pero sin embargo bastante comn Se puede tener una especificacin formal, o no tenerla Si no se ha utilizado formalmente un mtodo, probablemente ya se est usando el mtodo Codificar y Corregir en forma intuitiva Cuando se utiliza ste mtodo se empieza con una idea general de lo que se necesita construir, Se utiliza cualquier combinacin de diseo, cdigo, depuracin y mtodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo.

til. Espiral 1. El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los *estantes modelos. 2. Reduce riesgos del proyecto 3. Incorpora objetivos de calidad 4. Integra el desarrollo con el mantenimiento, etc. 5. Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la *metodologa, ya que este ciclo de vida no es rgido ni esttico. - Se tiene todo bien organizado y no se mezclan las fases. - Es perfecto para proyectos que son rgidos. - Ideal para proyectos donde se especifiquen muy bien los requerimientos. - Ideal para proyectos en que se conozca muy bien la herramienta a utilizar. - Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el Software.

El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniera de software concurrente y a la vez con muchos usuarios.

1.Genera mucho tiempo en el desarrollo del sistema 2.Modelo costoso 3. Requiere experiencia en la identificacin de riesgos

Cascadas modifica das

El ms conocido, est basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades: - Ingeniera y Anlisis del Sistema - Anlisis de los Requisitos - Diseo - Codificacin - Prueba - Mantenimiento

- Difcilmente un
cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases. - Los resultados y/o mejoras no son visibles, el producto se ve recin cuando este est finalizado.

Prototipo evolutivo

*reduccin de la planificacin nominal *progreso tangible *bajo riesgo de mala planificacin *posibilidad de xito a corto y largo plazo *puede servir de base a la entrega evolutiva

*expectativas poco realistas de presupuesto, planificacin y rendimiento *uso ineficiente de tiempo *dificultades para el mantenimiento

Entrega por etapas

-Requiere poca sofisticacin para los directivos y desarrolladores. - Permite modificaciones a medio camino. - Requiere poco tiempo de gestin. - Genera un sistema altamente fiable y con amplio desarrollo. - Permite una funcionalidad til en manos del cliente sin tener la aplicacin finalizada. -Proporciona signos tangibles de progreso. Es similar al modelo de entrega por etapas, pero se diferencia en que no siempre se conoce al principio si se tendr el producto para la ltima entrega. Se pueden tener cinco etapas planificadas, pero slo se llega a la tercera etapa debido a que se tiene una fecha lmite que no se puede cambiar. Uno de los elementos crticos de este modelo es priorizar los requerimientos y planificar sus etapas de tal manera que las primeras contengan los requerimientos de mayor prioridad, los requerimientos de baja prioridad se dejan para ms tarde.

- Estar sometido a una planificacin predefinida. - Trabaja con poca compresin sobre la arquitectura. - Trabaja con poca identificacin de los requerimientos de diseo. - Debe entregarse una etapa para continuar con la siguiente. Este modelo no es viable sin una planificacin adecuada.

Diseo por planifica cin

*Puede ser una estrategia vlida para asegurar que se tiene un producto listo en una fecha determinada. *Esta estrategia es particularmente til para las partes del producto que no se quieren realizar en el camino crtico

*Si no se completan todas las etapas, se desperdiciar tiempo en la especificacin, arquitectura y diseos de prestaciones que no se van a entregar. *Si se ha gastado tiempo en una gran cantidad de requerimientos incompletos que no se van a entregar, se debera tener tiempo para resumir en uno o dos requerimientos ms completos.

Entrega evolutiva

Diseo por herramie ntas

Es un modelo que se encuentra entre el prototipo evolutivo y la entrega por etapas, puesto que se desarrolla una versin del producto, se muestra al cliente, se refina el producto en funcin de los comentarios del cliente. El parecido entre ambos modelos depende de hasta qu punto se lleva a cabo una planificacin para adaptarse a las solicitudes de los clientes. La idea es incluir una funcionalidad dentro del producto slo si las herramientas de software existentes la soportan directamente. Ejemplos de herramientas son libreras de cdigo y clases, generadores de cdigo, lenguajes de desarrollo rpido y otras herramientas software que reducen de manera espectacular el tiempo de implementacin.

*Se puede combinar *Se pierde mucho

con otros modelos.

control sobre el producto. *Puede que no sea posible llevar a cabo la implementacin de todos los requerimientos que se desean, y que no se puedan implementar otros requerimientos exactamente de la forma que se quiere. *Depende en buena medida de los productores de software comercial.