You are on page 1of 9

GUA DE SISTEMAS DE INFORMACIN 1.

PUNTO Dar soporte a los objetivos y estrategias de la empresa Los objetivos de los sistemas de informacin son muy importantes por que con ellos respaldan las operaciones empresariales y la toma de decisiones. Las estrategias de una empresa son muy importantes por que con ellas buscan solucionar una investigacin preliminar para una determinacin de requerimientos en el diseo del sistema. Bsicamente en una empresa es importante los niveles por que con ellos se pueden encontrar con transacciones de recursos (dinero, personal, materiales, materias primas) que aumente la rentabilidad de la compaa. Su finalidad era bsicamente llevar la contabilidad y el procesamiento de los documentos a nivel operativo. Se trata de realizar un inventario en donde se puede determinar con precisin las cantidades como el costo, las condiciones, y finalmente, el valor del recurso.

Proporcionar informacin a todos los niveles

Conseguir que se adapte a la evolucin de la empresa Utilizar la informacin como un recurso corporativo

2. PUNTO Integrarlo en el plan de la empresa Porque busca desarrollar un plan de contingencia y otro de recuperacin sin necesidad de otro plan; y adems asegura la informacin. Los procesos pueden depender de unos requisitos especificados y de un funcionamiento del sistema en las actividades de planificacin, revisin, evaluacin. La responsabilidad de los datos se puede fijar en mximas autoridades de los organismos como funcionarios en lnea, responsable en sistemas de informacin, responsable de la seguridad de sistemas de informacin, y responsables de las reas de servicios informticos.

Hacerlo depender de los procesos

Fijar responsabilidades sobre los datos

3. PUNTO

Sistema de procesamiento de datos

- Mejora las actividades realizadas. -Ejecuta procesos bien estructurados. -Genera resmenes. -Realiza procesos de almacenamiento y recuperamiento. -Clculos -Clasificacin. -Ordenamiento. -Calidad -Oportunidad. - Cantidad. .Informacin -Relevancia El tipo de usuario son las organizaciones.

Sistema de informacin gerencial

Sistema de apoyo o toma de decisiones

Suelen introducirse despus de haber implantado los Sistemas transaccionales ms relevantes de la empresa, ya que estos ltimos constituyen su plataforma de informacin. - La informacin que generan sirve de apoyo a los mandos intermedios y al alta administracin en el proceso de toma de decisiones. - Suelen ser intensivos en clculos y escasos en entradas y salidas de informacin. - No suelen ahorrar mano de obra. - Debido a lo anterior, la justificacin econmica para el desarrollo de estos sistemas es difcil, ya que no se conocen los ingresos del proyecto de inversin. - Suelen ser Sistemas de

El tipo de usuario es la secretaria de educacin.

Informacin interactivos y amigables, con altos estndares de diseo grafico y visual, ya que estn dirigidos al usuario final. - Apoyan la toma de decisiones que por naturaleza son repetitivas y de decisiones no estructuradas que no suelen repetirse. - Estos sistemas pueden ser desarrollados directamente por el usuario final sin la participacin operativa de los analistas y programadores del rea de informtica.

Sistema expertos

-Su caracterstica principal son las reglas. -Habilidad para adquirir conocimiento. -Fiabilidad, para poder confiar en sus resultados o apreciaciones. -Solidez en el dominio de su conocimiento. -Capacidad para resolver problemas.

El tipo de usuario son los expertos.

4. PUNTO MODELO Cascada pura DESCRIPCIN O GRFICA VENTAJAS 1. Se utiliza correctamente para DESVENTAJAS 1. Dificultad para especificar

ciclos en los que se tiene una definicin 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. 6. Presenta el proyecto con una estructura que ayuda a minimizar el esfuerzo intil.

Codificar y corregir

Es un modelo poco til pero sin embargo, bastante comn. Se puede tener especificacin formal, e intuitiva. Este mtodo utiliza una idea general de lo que se necesita construir.

1. No conlleva ninguna gestin; n o 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 puede mostrar inmediatamente indicios de progreso. 3. Requiere poca experiencia: Cualquier persona

claramente los requerimientos al comienzo del proyecto (no permite flexibilidad en los cambios). 2. Para un proyecto de desarrollo rpido, el modelo de la cascada puede suponer una cantidad excesiva de documentacin. 3. Si se intenta mantener la flexibilidad, la actualizacin de la especificacin se puede convertir en un trabajo a tiempo completo. 4. No es imposible volver atrs utilizando el modelo de la cascada pura, pero si es difcil. 5. 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

Espiral

que haya inscrito alguna vez un programa est familiarizada con este 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 til. 1. Reduce riesgos del proyecto. 2. Incorpora objetivos de calidad. 3. Integra el desarrollo con el mantenimiento, etc. 4. Funciona bien en proyectos. 5. Desarrolla y aplica el enfoque de la construccin de prototipos en cualquier etapa de evolucin del producto.

codificacin descubre que el diseo es incorrecto, no hay otra solucin que desechar el trabajo y comenzar de nuevo.

Cascadas

1. Modelo y planificacin fcil y sencillos. 2. Sus fases son conocidas por los desarrolladores. 3. Los usuarios lo pueden comprender fcilmente.

Modificadas

La descripcin de esta grfica es la siguiente: En este modelo podemos encontrar las

a este nivel es posible desarrollar un prototipo de interfaz

1. Genera mucho tiempo en el desarrollo del sistema. 2. Modelo costoso. 3. Requiere experiencia en la identificacin de riesgos. 4. Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas. 5. Genera mucho tiempo en el desarrollo de sistemas. 1. Alto riesgos en sistemas nuevos debido a problemas en las especificaciones y en el diseo. 2. Bajo riesgo para desarrollos bien comprendidos utilizando tecnologa conocida. MODELO DE CASCADA CON FASES SOLAPADAS

fases solapadas que son: Planeacin, Anlisis, Diseo, Implementacin, Utilizacin. Como tambin en esta grfica podemos encontrar algunos subproyectos: Planeacin Anlisis Diseo -Diseo detallado Codificacin y depuracin Prueba del sistema Prueba del sistema

de usuario tener entrevistas con los usuarios observar cmo los usuarios interactan con algn sistema previo utilizar otros mtodos que se consideren apropiados para la identificacin de los requerimientos

Prototipo evolutivo

1. No modifica el flujo del ciclo de vida. 2. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. 3. Reduce costos y aumenta la probabilidad de xito. 4. Exige disponer de las herramientas adecuadas. 5. No presenta calidad ni robustez. 6. Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de

1. debido al solapamiento entre las etapas, los hitos son ms ambiguos, y esto hace ms difcil de trazar el progreso correctamente. 2. La realizacin de actividades en paralelo puede suponer una mala comunicacin, suposiciones incorrectas e ineficacia. MODELO DE CASCADA CON SUBPROYECTOS 3. Presencias de interdependencias imprevistas. MODELO DE CASCADA CON REDUCCIN DE RIESGOS 4. Ninguno. 1. A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. 2.La construccin de prototipos se torna a una problemtica por las siguientes razones: -El cliente ve funcionando lo que para el es la primera versin del prototipo que ha sido construido con chicle y cable para embalaje, y puede decepcionarse al indicarle que el sistema aun no ha

ingeniera.

sido construido.

Entrega por etapas

-El desarrollador puede caer en la tentacin de aumentar el prototipo para construir el sistema final sin tener en cuenta las obligaciones de calidad y mantenimiento que tiene con el cliente. 1. Requiere poca 1. Estar sometido a sofisticacin para los una planificacin directivos y preferida. desarrolladores. 2. Trabaja con poca 2. Permite comprensin sobre modificaciones a la arquitectura. medio camino. 3. Trabaja con poca 3. Requiere poco identificacin de tiempo de gestin. los requerimientos 4. Genera un sistema de diseo. altamente fiable y 4. Debe entregarse con amplio una etapa para desarrollo. continuar con la 5. Permite una siguiente. funcionalidad til en 5. Este modelo no manos del cliente sin es viable sin una tener la aplicacin planificacin finalizada. adecuada. 6. Proporciona signos tangibles de proceso. En este modelo podemos encontrar: -planeacin -Anlisis -Diseo -Alta prioridad: diseo detallado, implementacin, utilizacin. Prioridad media-alta: diseo detallado, implementacin, utilizacin. -Prioridad media: diseo detallado, implementacin, utilizacin. Las limitaciones presupuestarias El entrenamiento de administradores (formacin y experiencia) La plataforma hardware final (mquinas) Conectividad 1. Si no se completan todas las etapas, se desperdiciar tiempo en la especificacin, arquitectura y diseos de prestaciones que no se van a entregar. 2. Si se ha gastado tiempo en una gran cantidad de requerimientos incompletos que no se van a entregar, se

Diseo por planificacin

Entrega -Agotamiento del plazo o del presupuestoPrioridad media-baja: diseo detallado,

implementacin, utilizacin. Prioridad baja: diseo desarrollado, implementacin, utilizacin.

Entrega evolutiva

debera tener tiempo para resumir en uno o dos requerimientos ms completos. 1. Los clientes no 1. Cada esperan hasta el fin incremento debe del desarrollo para ser pequeo para utilizar el sistema. limitar el riesgo. Pueden empezar a 2. Cada usarlo desde el incremento debe primer incremento. aumentar la 2. Los clientes funcionalidad. pueden aclarar los 3. Es difcil requisitos que no establecer las tengan claros correspondencias conforme ven las de los requisitos entregas del contra los sistema. incrementos. 3. Se disminuye el 4. Es difcil riesgo de fracaso de detectar las todo el proyecto. Ya unidades o que se puede servicios genricos distribuir en cada para todo el momento. sistema. 4. Las partes mas importantes del sistema son entregadas primero, por lo cual se realizan ms pruebas en estos mdulos y se disminuye el riesgo de fallos. Este modelo se puede combinar con otros modelos -Primer ejemplo de la combinacin 1. Construir una espiral inicial para identificar las capacidades de las herramientas software existentes. 2. Identificar los requerimientos bsicos. 3. Determinar si la Se pierde mucho control sobre el producto. 2. 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.

Diseo por herramientas

La descripcin de la grfica es : Funcionalidad soportadas por las herramientas. Funcionalidad que se va a incluir. Funcionalidad ideal. Funcionalidad que se va a estar en el producto.

aproximacin del diseo por herramientas es viable. Segundo ejemplo de combinacin 4. Utilizar una aproximacin del diseo por herramientas para implementar un prototipo de prueba. 5. Realizando un prototipo slo de las capacidades que se pueden implementar fcilmente con herramientas. 6. Implementar el software real utilizando la entrega por etapas, la entrega evolutiva y el diseo por planificacin. Software comercial existente El software comercial disponible raramente va a satisfacer todas las necesidades del cliente. Se deben considerar los siguientes puntos: 1. Est disponible de forma inmediata. 2. En el lapso de tiempo entre que se adquiere el software comercial y en el que se puede tener preparada la entrega del sistema de creacin propia, los usuarios pueden: Aprender a trabajar con las limitaciones Del producto. Revisar el software comercial para adaptarlo an ms a las necesidades de cada uno.

3. Depende en buena medida de los productores de software comercial (tanto de sus estrategias de productos como de su estabilidad financiera).

You might also like