Repblica Bolivariana de Venezuela Universidad Nororiental Privada Gran Mariscal de Ayacucho Facultad de Ingeniera Ctedra: Electiva Tcnica

METODOLOGA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN GERENCIAL

Profesora: Rocca Rosa

Elaborado Por: Astudillo Luis C.I: 18.621.536 Loaiza Nerio C.I: 19.095.246

Puerto Ordaz, Enero del 2012

Introduccin En el presente trabajo que se presenta a continuacin sern presentadas las metodologas del Desarrollo de Sistemas ms utilizados como lo son:

Estructurada Completa Particionada

Por otra parte, se hace mencin a los diagramas utilizados como tambin a las fases que estas serian: Fase I. Definicin del proyecto. Fase II. Anlisis De Contexto. Fase III. Definicin de requerimientos. Fase IV. Diseo Preliminar. Fase V. Diseado Detallado. Fase VI. Construccin del sistema. Fase VII. Control de programas. Fase VIII. Prueba de aceptacin Por otra parte, se hace mencin, del Ciclo de Vida de Desarrollo de Sistemas que no es ms que 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.

METODOLOGA PARA EL INFORMACIN GERENCIAL.

DESARROLLO

DE

SISTEMAS

DE

MEDSI. Es una metodologa estructurada para desarrollar sistemas de informacin en y para organizaciones de cualquier tipo. Entre las caractersticas resaltantes de esta metodologa podemos destacar: ES ESTRUCTURADA: esta caracterstica se debe a dos razones esenciales: Utiliza diferentes mtodos y tcnicas estructuradas, que son propias de la Ingeniera de la Programacin, y que han demostrado ser las ms eficientes y eficaces para el desarrollo de sistemas programados. Gua paso a paso de arriba hacia abajo el grupo que la aplica explicando primero de forma muy general lo que debe hacerse para luego entrar en los detalles, a medida que se avanza hasta explicar las tareas esenciales que el grupo debe llevar a cabo para realizar el sistema de informacin.

ES COMPLETA: Cubre todas las distintas fases del ciclo de desarrollo de un sistema de informacin, desde la definicin del proyecto hasta la implantacin del sistema en la organizacin. Gua al grupo de desarrollo a travs de las fases, a un nivel bastante detallado, explicando las actividades que deben hacerse y en la mayora de los casos, enumerando las tareas especficas que los miembros del grupo deben efectuar. ES PARTICIONADA: A fin de manipular mejor la inherente a un proyecto de este tipo, la metodologa se divide en fases, y cada una de las fases esta compuesta por pasos los cuales estn orientados a algn tipo de tpicos, aspecto o elemento de un sistema de informacin. Cada paso a su ves agrupa a un conjunto de actividades que han de ser realizadas por el grupo de desarrollo. Diagramas Utilizados en MEDSI. Los diagramas utilizados en esta metodologa, para explicar las diferentes fases estn basados en la tcnica de Anlisis Estructurado de Sistemas, y corresponden a lo que, en trminos de esa tcnica, recibe el nombre de Diagrama de Flujo de Datos. Los elementos para construir un Diagrama de Flujo de Datos, son los siguientes: Utilizado para representar un proceso, actividad o tarea (aqu lo utilizaremos para representar una fase o paso de la metodologa) Representa un canal de datos, por donde fluyen datos, en forma de documentos, informes etc,. Identifican lo elementos externos que reciben informacin o envian datos.

Identifica a un medio de almacenamiento de datos manual o automtico. Esta metodologa, esta orientada a proyectos medianos y grandes, que ameriten la integracin de grupos de desarrollo conformados por tres o ms personas que puedan requerir para su desarrollo varios meses. Fases de MEDSI. Fase I. Definicin del proyecto. Determinar la factibilidad de desarrollar un nuevo sistema de informacin y estimar los costos, tiempos y recursos requeridos de tal manera que las unidades interesadas puedan decidir si se ha de emprender o no el proyecto. Si se decide realizarlo se elabora el plan del proyecto. Dentro de esta fase encontramos los siguientes pasos: Estudio Preliminar del proyecto: este estudio muestra de manera general si se justifica o no desarrollar un sistema de informacin para satisfacer las necesidades de las unidades interesadas. Para ello, el gerente realiza las siguientes actividades:
1. 1. Reconocer el problema. Implica efectuar las acciones necesarias para reconocer que existe un problema. Las tareas que este debe realizar en esta actividad son:

Recopila y analizar aquellos elementos que indiquen la necesidad de un nuevo sistema. Realizar reuniones preeliminares con el personal de las unidades involucradas para definir la necesidad de un cambio.

2. Formular el problema. Esta actividad busca diagnosticar, de modo muy general, el sistema actual, si es que existe, tratando de responder entre otras cosas, las siguientes interrogantes:

Qu hace este sistema actual? Qu objetivo persigue? Los logra actualmente? Por qu? Qu dificultades o inconvenientes presenta? Qu reas de la organizacin se ven afectadas? Es parte de un problema mayor?

As mismo se busca determinar las necesidades preliminares que puedan o no justificar el desarrollo del nuevo sistema. Alguna de las interrogantes que se han de responder son: Qu argumentos justifican un cambio? Por qu es importante un cambio? Por qu se cree que un nuevo sistema resolver el problema? Qu funciones generales debera ejecutar el nuevo sistema?

Para esta actividad el gerente del proyecto debe llevar a cabo las siguientes tareas: Realizar entrevistas con las personas que sientan la necesidad de un cambio. Recopilar y archivar documentos, notas de las entrevistas y datos relevantes del sistema actual, sus inconvenientes y la necesidad de cambio. Analizar la documentacin archivada.

3. Elaborar el informe preliminar. A partir del anlisis anterior, el gerente debe elaborar un informe que resuma los resultados de las actividades anteriores, el cual debe concluir si existen o no necesidades y problemas actuales que justifiquen emprender el desarrollo de un nuevo sistema.

Discutir el informa preliminar. El gerente presenta el informe preliminar a los directivos de las unidades involucradas quienes deciden, a partir de ese informe, si se emprende el proyecto o no, o si es necesario un mayor estudio.
4.

Planificar el estudio de factibilidad. Dependiendo de la decisin adoptada durante la discusin del informe preliminar, el gerente se dedica ahora a iniciar un estudio de factibilidad del proyecto, para ello debe realizar previamente las siguientes tareas:
5.

2.

Determinar las actividades y tareas necesarias para conducir un estudio de factibilidad. Determinar los recursos requeridos. Programar los tiempos de las actividades y tareas.

Estudio de Factibilidad. Una vez que se ha justificado la necesidad de un nuevo sistema, el gerente debe estudiar, junto con el grupo seleccionado para este paso, la factibilidad tcnica, econmica y psicosocial de diferentes alternativas que puedan constituir soluciones aceptables al problema actual. Por consiguiente, el grupo de factibilidad debe realizar las siguientes actividades: Evaluar el sistema actual. Siempre y cuando exista un sistema actual de informacin el grupo de be evaluar en este momento dicho sistema.
1. 2. Establecer nuevos requerimientos en forma general. En esta actividad el grupo se dedica a establecer los requerimientos generales de un nuevo sistema. 3. Formular sistemas alternativos. El grupo identifica, en esta actividad diferentes configuraciones para el sistema que satisfaga los requerimientos generales establecidos en la actividad anterior, las tareas que han de realizarse son:

Identificar configuraciones alternativas. Para cada alternativas: Describir sus caractersticas principales. Determinar que requerimientos no se satisfacen, total o parcialmente. Definir el grado de automatizacin. Determinar que restricciones y atributos no se pueden satisfacer.

4. Determina factibilidad tcnica. Para cada sistema alternativo se debe establecer su factibilidad tcnica, ellos deben responder a dos interrogantes: es posible desarrollar el sistema propuesto con la tecnologa actual o existente?, y si es posible, qu tecnologa adicional debe adquirir la organizacin?. Las tareas que se deben efectuar son:

Evaluar las tecnologas que dispone la organizacin. Determinar la tecnologa demandada. Determinar la tecnologa adicional que debe adquirirse.

5. Determinar factibilidad econmica. En esta actividad el grupo debe realizar un anlisis costo beneficio que permita identificar y medir los costos de desarrollo de operacin y los beneficios que obtiene la organizacin de cada sistema alternativo; para luego comparar las diferentes alternativas bajo un criterio econmico. Tambin deben estimarse los tiempos de desarrollo de cada sistema propuesto a fin de medir la factibilidad econmica de cada uno de ellos.

Determinar factibilidad psicosocial. La implantacin de un sistema de informacin automatizado en cualquier organizacin crea un impacto social, que puede ocasionar su aceptacin el rechazo total al cambio tecnolgico que se pretende introducir. El grupo debe predecir o estimular para cada alternativa el impacto social que ellas pueden originar dentro de la organizacin.
6.

Elaborar informe de factibilidad. Este informe describe cada sistema alternativo y resume su factibilidad tcnica, econmica psicosocial.
7.

Discutir el informe de factibilidad. El gerente del proyecto presenta el informe a la comisin de planificacin, quienes junto con los otros directivos de las unidades involucradas discuten la factibilidad de cada alternativa y selecciona la ms conveniente. El proyecto puede ser paralizado debido a que no existan alternativas factibles o convenientes a la organizacin
8.

Planificacin del Proyecto. A partir de la decisin de continuar con el proyecto y de la seleccin de un enfoque alternativo para el nuevo sistema de informacin, el gerente del proyecto se dedica a planificar el mencionado proyecto, tratando de estimar los costos, tiempos y recursos para llevarlo a cabo.
3.

Este paso tiene por finalidad elaborar un documento que gue el desarrollo del proyecto y que denominaremos el PLAN DE PROYECTO. Las actividades que debe realizar el gerente del proyecto durante el proceso de planificacin son:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Elaborar un plan general. Elaborar un plan de fases. Elaborar un plan de organizacin. Elaborar un plan metodolgico. Elaborar un plan de administracin de la configuracin. Elaborar un plan de administracin de recursos. Elaborar un plan de documentacin. Elaborar un plan calendario de eventos. Seleccionar el grupo de desarrollo. Revisar el plan de proyecto. Discutir el plan de proyecto.

Fase II. Anlisis De Contexto. En esta fase se busca ganar un slido conocimiento del sistema ampliado dentro del cual se ubicar el nuevo sistema de informacin y determinar las deficiencias y problemas que presenta el actual sistema de informacin (Si existe). Dentro de esta fase encontramos los siguientes pasos: 1. Anlisis documental. este paso le permite al grupo de desarrollo disponer de una biblioteca organizada de documentos relativos al proyecto. Una ves constituida la biblioteca, el grupo se ocupa de estudiar la documentacin propia del sistema con iras a obtener una primera aproximacin al conocimiento del citado sistema y sobre todo al contexto que lo contiene. Las actividades que el grupo desarrollo debe llevar a efecto durante ese paso son:
1. Recopilar documentos. Con la colaboracin de los diferentes usuarios del sistema actual, el grupo recopila toda la documentacin posible a tal sistema.

Organizar documentacin. Al finalizar la recopilacin de documentos el gerente del proyecto asigna a una o ms personas del grupo para que se encarguen de organizar la biblioteca, estas personas son denominadas bibliotecarios del proyecto.
2. 3. Estudiar documentos. Despus de haberse organizado la biblioteca el grupo se dedica a estudiar a documentacin. El gerente programa reuniones de discusin, distribuye el material para lecturas individuales y conduce las discusiones en equipo sobre algunos documentos en particular el objetivo de este estudio es familiarizarse con el sistema actual antes de iniciar su anlisis formal

Anlisis del Contexto. este paso constituye un estudio formal de todo el sistema, con un nivel de detalle ms profundo que aquellos realizados anteriormente. Su objetivo es permitirle al grupo de desarrollo conocer el sistema actual y su contexto para luego modelarlo y sobre el modelo
2.

identificare las situaciones problemticas que el sistema presenta. El modelo del sistema actual se elabora utilizando la tcnica conocida como Anlisis Estructurado de Sistema. El modelo general esta integrado por dos submodelos. Analizar el contexto del sistema. Durante esta actividad el grupo de desarrollo estudia el sistema de actividades (sistema empleado) dentro del cual esta enmarcado el sistema de informacin. Ello debe llevar a determinar los objetivos de ese sistema, definir su estructura, establecer sus procesos y determinar su comportamiento.
1. 2. Analizar el sistema actual de informacin. En esta actividad el grupo de desarrollo identifica los objetivos, estructuras y procesos del sistema actual, para ello deben efectuar las siguientes tareas:

Definir los objetivos del sistema de informacin. Identificar sus sub sistemas. Identificar sus funciones. Identificar las entradas, procesos y salidas de cada funcin. Determinar su flujo de informacin. Identificar sus archivos. Analizar su documentacin y sus procedimientos manuales. Identificar los usuarios de sistema y describir sus tareas. Describir la tecnologa que utiliza el sistema.
3.

Construir el modelo del sistema actual de Informacin. Para ello se utiliza la tcnica de anlisis estructurado de sistemas que permite elaborar los modelos fsicos y lgicos del sistema de informacin. Las tareas que se deben realizar durante esta actividad se dividen en: Construir los diagramas de flujo de datos del modelo fsico y lgico. Elaborara el diccionario de datos. Describir cada proceso del modelo lgico hasta un nivel adecuado.
4. 5.

Identificar las situaciones problemticas. Elaborar el informe del sistema actual. Este informe resume los resultados de las actividades anteriores, mediante una descripcin del ambiente y del mismo sistema, la presentacin del modelo y la descripcin de los problemas que presenta el actual sistema. Fase III. Definicin de requerimientos. Esta fase busca definir los requerimientos de los usuarios y establecer las funciones, restricciones y atributos que el nuevo sistema de informacin debe satisfacer. 1. Especificacin de Requerimientos de Informacin. El grupo de desarrollo se encarga de especificar junto con el usuario del nuevo sistema las salidas, las entradas y las estructuras necesarias de datos. Las

actividades que realizas el grupo de desarrollo durante este paso son las siguientes: Determinar los requerimientos de informacin. En conjunto con los usuarios, el grupo de desarrollo determina las necesidades actuales y futuras de informacin que el nuevo sistema de informacin debe satisfacer. Dichos requerimientos son:
1.

Requerimientos de entrada. Requerimientos de salida. Requerimientos de almacenamiento.

2.

Construir el libro de requerimientos de informacin. Este libro contiene una entrada para cada requerimiento de informacin nuevo o viejo. Los requerimientos se agrupan e divisiones de acuerdo al tipo sealado en la actividad anterior. La divisin de requerimientos de salida se organiza por sesiones. Cada sesin contiene los requerimientos de informacin de una unidad funcional que esta involucrada en el sistema. Especificacin Funcional del Nuevo sistema. Tomando como elemento de entrada el informe del sistema actual y el libro de requerimiento, el grupo, a lo largo de este paso, especifica con los usuarios las funciones que el nuevo sistema debe realizar.
2. 1. Determinar requerimientos funcionales. Este tipo de requerimiento constituye las funciones que el nuevo sistema debe ejecutar para lograr la consecucin de los objetivos identificados en el estudio de factibilidad. Utilizando el informe del sistema actual, el grupo determina con los usuarios, aquellas funciones que deben continuar, las que se han de modificare o eliminar y las que se han de incorporar al nuevo sistema. 2. Construccin del modelo lgico del nuevo sistema. Este modelo es constituido utilizando la tcnica Anlisis Estructurado de Sistema, y constituye un medio grfico de valioso apoyo descriptivo y documentado de cada una de las funciones del sistema en desarrollo debe realizar. 3. Elaborar el informe del nuevo sistema. Bajo el nombre de especificacin funcional del nuevo sistema se almacena en la biblioteca del proyecto el modelo lgico y la lista de restricciones y atributos y a partir de ellos se elabora un resumen que denominaremos informe del nuevo sistema. 4. 3.

Discutir el informe del nuevo sistema.

Especificacin de Restricciones y Atributos. En este paso, el grupo de desarrollo establece junto con los usuarios las restricciones bajo las cuales se deben desarrollar y debe operar el sistema de informacin. As mismo se establece tambin, la interaccin que debe haber entre el

hombre, el computador y los atributos de calidad que se la van a imponer al mencionado sistema de informacin
1. Determinar Restricciones. Estas restricciones se pueden agrupar tal como se muestra a continuacin:

Econmica: de que cantidad de dinero se dispone para mantener el sistema. Tcnicas: que equipo debe o puede utilizarse. De personal: de que personal se dispone para mantener y operar el sistema. Legales: que polticas, reglamentos, normas, leyes, etc, tanto internas como externas deben acatarse.

2. Determinar interaccin hombre mquina. Esta actividad es esencial pues define la comunicacin que debe haber entre los usuarios y el computador a travs del subsistema programado. 3. Determinar atributos de calidad. Entre las interrogantes que se deben responder para algunos de los atributos de calidad se destacan las siguientes:

Confiabilidad. Grado de prueba. Movilidad Adaptabilidad Mantenimiento requerido. Seguridad y privacidad. Eficiencia y rendimiento. Documentacin.
4. 5.

Elaborar listas de restricciones y atributos. Planificar detalles de la prxima fase.

Fase IV. Diseo Preliminar. Esta fase se encarga de elaborar un diseo preliminar del sistema de informacin que satisfaga los requerimientos, restricciones y atributos establecidos en la fase III. El diseo preliminar consta de un prototipo o modelo fsico que delinea la interaccin hombre- mquina del sistema de informacin y describe, en forma general sus procesos automatizados. Dentro de esta fase encontramos: 1. Definicin de prototipos: en este paso el grupo de desarrollo elabora diferentes prototipos que puedan satisfacer la especificacin funcional, las restricciones y los atributos identificados en la fase anterior. se solicitan precios y especificaciones tcnicas de los equipos o programas que hagan falta, a los diferentes vendedores del mercado.

La definicin de prototipo esta regida por la estructura o configuracin global del sistema de informacin, en ella se indica si el diseo del sistema ha de ser independiente, centralizado o distribuido. Partiendo de este enfoque, se establecen diferentes configuraciones para el procesamiento y para la interaccin que existir entre el hombre y la maquina.
1. Elaborar diferentes prototipos alternativos. A partir del modelo lgico del nuevo sistema y de las restricciones y atributos establecidos anteriormente, el grupo desarrolla diferentes prototipos. Un prototipo es un modelo construido sobre el modelo lgico que muestra claramente la interaccin hombre-maquina, esto indica que procesos son manuales y cuales automticos. El prototipo muestra tambin los procedimientos de activacin del subsistema programado, los de respaldo y recuperacin de fallas y los de seguridad de la base de datos. 2. Evaluar configuracin tcnica existente. Tomando como datos las configuraciones de equipos existentes en la organizacin, que puedan ser utilizados por el nuevo sistema, se procede luego a evaluar estas configuraciones y a determinar que prototipos se pueden desarrollar con ellos en forma parcial o total.

Determinar configuracin tcnica necesaria. Para aquellos prototipos que no puedan ser desarrollados totalmente con la tecnologa disponible en la organizacin actualmente, se elaboran las configuraciones tcnicas adicionales que ellos requieran y se solicitan las cotizaciones respectivas a los vendedores del mercado.
3.

Seleccin de prototipos. En este paso el grupo de desarrollo realiza un anlisis de costo beneficio para los diferentes prototipos definidos en el paso anterior. De los resultados de este anlisis se presenta y discute con la comisin de planificacin, quin deside posteriormente el prototipo ms conveniente y da las instrucciones necesarias para la adquisicin de la tecnologa que haga falta.
2.

Realizar un anlisis costo beneficio. Para cada prototipo se determina sus costos de desarrollo y operaciones y se estima los beneficios que puedan obtenerse. Se comparan los diferentes prototipos bajo un criterio econmico pre-establecido. Los resultados obtenidos se resumen en un informe tcnico denominado informe de prototipo.
1. 2. Discutir informe de prototipos. El informe producido en la actividad anterior se presenta a la comisin de planificacin, quien lo discute y finalmente selecciona el prototipo que considere ms conveniente para la organizacin.

Adquirir tecnologa necesaria. De ser necesario el grupo de desarrollo, o en su defecto, el que designe la comisin de planificaciones, se encarga de adquirir, instalar y probar el equipo y los programas que el prototipo seleccionado requiera para su desarrollo u operacin.
3.

Refinamiento de Prototipo. Finalmente, el grupo se dedica a refinar el prototipo escogido, es decir, se describen con mayor detalle aquellos procesos del prototipo que sean automticos, siguiendo la tcnica de anlisis estructurado de sistema.
3. 1. Refinar prototipo. Cada proceso automtico del prototipo se refina mediante la descomposicin funcional establecida por la tcnica AES. Cada proceso del mas bajo nivel debe describirse utilizando cualquier de las tcnicas siguientes: algoritmos estructurados, tablas de decisin o rboles de decisin. Los entes del diccionario de datos que se vean afectados por la automatizacin deben ser actualizados durante esta actividad

Revisar Prototipo. El modelo o prototipo obtenido en la actividad anterior se somete a una revisin estructurada o a una inspeccin de diseo.
2. 3. 4.

Elaborar informe de diseo preliminar. Planificar detalles de la prxima fase.

Fase V. Diseado Detallado. Esta fase busca elaborar un diseo detallado del sistema de informacin que muestre como se construirn los subsistemas de datos y el subsistema programado. Esta fase produce el paquete de diseo, el cual contiene todas las especificaciones para la construccin del sistema, y el plan de pruebas que regirn las diferentes pruebas del sistema de informacin durante las fases de construccin, pruebas e implantacin. Dentro de esta encontramos los siguientes pasos: Diseo de Entradas y Salidas. En este paso se elabora minuciosamente el diseo de la interaccin entre el hombre y la mquina, la cual ha sido delineada en el prototipo del sistema.
1.

Disear dialogo hombre mquina. Dependiendo del tipo de interaccin hombre-mquina seleccionada, en esta actividad se debe:
1.

Determinar el medio de comunicacin (terminal, teleimpresor, lectora ptica, tc), estableciendo ademas sus caractersticas capacidades y especificaciones tcnicas que afecten al diseo de los programas. Determinar el tipo de dilogo hombre-mquina y disearlo completamente. Describir la accin que debe realizar el computador ante cada comando o selector que del usuario.

2. Disear las pantallas de entrada salida. Esta actividad consiste en disear la estructura o formato de cada pantalla de entrada de datos al sistema y de salida de informacin a los usuarios.

3. Disear los reportes. En esta actividad el grupo disea aquellos reportes que no fueron especificados en la actividad anterior. Estos son bsicamente, los listados de papel, los grficos y los diagramas. Para cada uno de ellos se debe especificar su estructura o formato, su contenido (registro de datos ) y el medio de produccin o salida.

Diseo de Datos. El diseo del subsistema de datos del sistema de informacin gira en torno a el diseo de la (s) base (s) de datos necesaria (s) para almacenar los datos de dicho sistema y el diseo de los programas que permitirn crear y cargar la (s) base (s) de datos.
2. 1. Realizar el diseo lgico de la base de datos. En este proceso de diseo se elabora un modelo de datos que representa las entidades, sus atributos y las relaciones existentes entre esas entidades. Las tareas que realiza el grupo para elaborar un modelo de datos son:

Analizar los flujos de datos que entran y salen de cada archivo del prototipo del sistema. Derivar la (s) estructura (s) de datos contenida (s) en cada archivo, identificando las entidades que representa y los atributos que poseen. Establecer las relaciones que existan entre las diferentes entidades y construir el modelo de entidad-relacin correspondiente. Si el SMBD (sistema manejador de base de datos) que se valla a utilizar manipula base de datos relacionales, entonces cada entidad del modelo entidad-relacin debe ser normalizada hasta por lo menos la tercera forma normal. Verificar si el modelo de datos obtenido satisface todos y cada uno de los requerimientos detallados en el libro de requerimientos.

2. Realizar el diseo fsico de la base de datos. Dependiendo del tipo y caracterstica del sistema de manejo de bases de datos que se halla dispuesto a utilizar, el grupo traduce el modelo de datos a un esquema, esto es, un programa que describe las estructuras lgicas de los datos y sus correspondientes estructuras de almacenamiento e indica los mtodos de acceso que se utilizaran, en trminos de lenguaje de descripcin de datos del SMBD. 3. Disear los programas de inicializacin y mantenimiento de la base de datos. En esta actividad el grupo disea aquellos programas que no forman parte del subsistema programado y que permiten iniciar o cargar la base de datos con los datos provenientes de fuentes de volumen considerable. Estos programas sern operados y mantenidos por el administrador de la base de datos y por lo tanto se consideran parte integrante del subsistema de datos en lugar del subsistema programado.

Diseo de programas y procedimientos. Luego que se ha elaborado el diseo de entrada-salida y el de datos, el grupo de desarrollo puede
3.

proceder a disear los programas y procedimientos del subsistema programado. El prototipo del nuevo sistema de informacin, su correspondiente especificacin funcional y la lista de restricciones y atributos le imprimen una forma nica a la estructura del sistema programado.
4.

Disear la estructura del subsistema programado. El subsistema programado se disea como una estructura jerrquica compuesta por una o mas programas, cada uno de estos se compone a su vez de mdulos un modulo se define como una unidad de programa que se caracteriza por lo siguiente:
1.

Posee un nombre propio y nico. Ejecuta una funcin claramente especificable. Puede compilarse y catalogarse en forma catalogada . Puede definir y mantener un conjunto propio de variables locales se llama o invoca de otro modulo.

2. Disear cada modulo de la estructura. Durante la presente actividad el grupo elabora el diseo de cada uno de los mdulos que configuran la estructura del subsistema programado. Este diseo consiste en establecer la lgica general de cada modulo, esto es, describir los pasos necesarios para llevar a cabo la funcin asignada al modulo. La lgica de un modulo se puede representar mediante el uso de algoritmos o diagramas de flujo.

El algoritmo o diagrama de flujos del modulo, en si, no es suficiente como para que un programador empiece su codificacin, pues se requiere de una informacin adicional sobre las caractersticas del modulo, su funcin, su ubicacin, sus argumentos, etc. Toda esta informacin se condensa en un formulario elaborado para tal fin y que se denomina especificacin de programa. Disear la documentacin y los procedimientos manuales. En esta actividad el grupo se ocupa a determinar el formato y contenido de cada uno de los manuales que forman la documentacin del sistema de informacin de acuerdo a lo que se ha establecido en el plan de documentacin. De igual modo se disean los formatos, formularios, instructivos, planillas y demas procedimientos manuales que se mencionan en el prototipo del sistema, y que se requieren como elemento de los flujos de datos de los procesos manuales del sistema de informacin.
3.

La estructura del sistema programado, las especificaciones del programa asociadas a cad modulo de esa estructura y el diseo de la documentacin y de los procedimientos manuales, constituyen lo que se denomina como la especificacin del subsistema programado. Ensamblaje del paquete de diseo. Este paso se basa en revisar y ensamblar el conjunto de especificaciones de diseos producidas en los
5.

anteriores, con el proposito de garantizar la consistencia, calidad y exactitud del diseo e integrar lo que hemos denominado como paquete de diseo. Para cada una de las especificaciones antes mencionadas se realiza una revisin estructurada (o una inspeccin de diseo) siguiendo los lineamientos dados para esas tcnicas. Los objetivos de estas revisiones son : Determinar las inconsistencias de diseo. Determinar las fallas y errores cometidos en las diferentes especificaciones. Medir y corregir las desviaciones del diseo con respecto a las normas y procedimientos de diseo establecidos en el plan metodolgico. Asegurar que las restricciones y atributos establecidos se satisfagan plenamente con el diseo elaborado. Asegurar que cada requerimiento contenido en el libro de requerimiento y cada especificacin funcional del prototipo se cubran o satisfagan con el diseo producido.

1. Ensamblar el paquete de diseo. Las especificaciones de diseo, una vez revisadas y corregidas, se ensamblan para producir el paquete de diseo. Este documento contiene todo el material descriptivo necesario para conducir la construccin del sistema. Por consiguiente, contiene:

El prototipo del sistema. La configuracin y documentacin del equipo que se va a emplear. Las especificaciones de entrada y salida. La especificacin del subsistema programado. La especificacin del subsistema de datos. Cualquier otro material que fuese necesario
2.

Elaborar y discutir el informe del diseo detallado. Haciendo uso del paquete de diseo, el gerente del proyecto elabora un informe descriptivo de las caractersticas, ventajas, desventajas, y los ajustes de costos y tiempos de desarrollo, que el diseo elaborado involucra. Planificacin de pruebas. Las actividades concernientes a esta fase se desarrolla a lo largo de esta metodologa, por otro lado es evidente que muchas de las actividades de prueba se pueden realizar en paralelo con actividades de fase tales como las de diseo y construccin del sistema. Bajo este criterio, podemos dividir las actividades generales de las pruebas en :
6.

Planificacin de las pruebas. Diseo y construccin de las pruebas. Ejecucin de las pruebas.

La primera de ellas se realiza durante esta fase de diseo; la segunda durante la fase de construccin y la ltima se distribuye durante la fase de construccin y pruebas previamente dichas.
1. Elaborar el plan de pruebas Durante esta actividad, el gerente del proyecto se dedica a planificar el conjunto de actividades que se requieren para probar el sistema de informacin. El resultado de este proceso lo constituye el PLAN DE PRUEBAS. En el se identifican:

Las diferentes pruebas que han de realizarse Los responsables de disearlas construirlas y ejecutarlas La programacin del tiempo, costos y recursos necesarios para llevarlos a cabo. Las herramientas, mtodos, tcnicas y procedimientos que se deben emplear en las diferentes actividades de pruebas Los criterios de xito de cada prueba Informacin adicional que se necesite para efectuar tales pruebas

Este plan se puede organizar en secciones: Objetivos Calendarios de pruebas De unidades De subsistemas De sistema De aceptacin Herramientas tcnicas y mtodos Seguimientos de requerimientos Procedimientos Normas Criterios de xitos

2. Discutir el plan de pruebas En esta actividad, el gerente del proyecto discute el plan de pruebas con el grupo de desarrollo a objeto de asignar los diferentes responsables de las actividades de pruebas. En proyecto de gran magnitud o complejidad se designa un grupo integrado por expertos en pruebas y algunos miembros del grupo de desarrollo con el propsito de conducir las actividades de pruebas restantes. 3.

Planificar detalles de la prxima fase

Fase VI. Construccin del sistema Construir el subsistema de datos y el subsistema programado del sistema de informacin de acuerdo a lo especificado en el paquete de diseo. En esta fase se construyen y se prueban los diferentes mdulos del subsistema

programado; se construye subsistema de datos y los procedimientos manuales del sistema. Diseo y construccin de las pruebas. Este paso es realizado por un grupo de pruebas. Se trata de especificar los detalles de cada una de las pruebas que se han identificado en el plan de prueba y de construir los mecanismos requeridos para ejecutar cada una de ellas.
1.

Elaborar las especificaciones de prueba. Una especificacin de prueba es un documento que generalmente toma la forma de planilla y describe pormenorizadamente las actividades de pruebas, asi como, aquellos mtodos, tcnicas y procedimientos que se vayan a emplear para realizar la prueba de un elemento de un sistema de informacin. Cada especificacin de prueba debe contener la siguiente informacin: - Identificacin. - Objetivos. - Requerimientos. - Criterio de xito. - Tcnica de procedimientos. - Casos de pruebas.
1. 2. 3.

Realizar una revisin estructurada de las pruebas. Construir los mecanismos y preparar los datos de

pruebas. De las especificaciones de pruebas anteriormente elaboradas, el grupo construye los ejecutivos y los esqueletos diseados en cada una de ellas y si el volumen de datos de prueba, es considerable, entonces prepara los archivos de datos que ser demandes. Los mecanismos de prueba, junto con los datos, los almacena el bibliotecario para su uso posterior de su respectiva prueba. Codificacin de programas. Este paso lo realizan los programadores del grupo de desarrollo que el gerente seleccione, la misin de cada uno de ellos es codificar los mdulos de conformidad con las especificaciones del programa dadas y siguiendo las normas establecidas en el plan metodolgico. La misin del gerente del proyecto es inspeccionar los mdulos producidos por los programadores con el objeto de controlar su calidad.
2. 1. 2. 3. 3.

Asignar los mdulos de los programadores. Codificar los mdulos. Realizar una revisin estructurada del cdigo.

Creacin de la base de datos. Para ello se debe realizar las siguientes actividades: 1. Construir y probar los programas de carga. 2. Crear la base de Datos. 3. Inicializar la base de datos. 4. Revisar la base de datos.

Elaboracin de la Documentacin y de los procedimientos manuales y de control de programas. Para ello se deben realizar las siguientes actividades:
4.

5.

Elaborar los manuales. Elaborar las planillas, los instructivos, etc. Evaluar la documentacin. Elaborar los procedimientos de control de programas

Prueba de unidades. La prueba de cada modulo especificado es realizada por el mismo programador que lo codifico. Las actividades de pruebas de unidades se dividen en: 1. Discutir las especificaciones de prueba. 2. Ejecutar las pruebas de unidades. Creacin de la librera de programas. Una ves que todos los mdulos del sistema programado han sido probados, cada programador entrega sus mdulos al bibliotecario del proyecto quien se encarga de almacenarlo en una librera destinada a tal fin, denominada librera de programas. A partir del momento que se crea la librera ningn miembro del grupo tiene acceso a los programas all archivados, por lo tanto para realizar una modificacin de algunos de los mdulos, el programador debe discutir con el grupo tal modificacin, obtener la aprobacin del gerente, solicitar del bibliotecario el modulo, realizar la correccin y devolver dicho modulo al bibliotecario. Las actividades del bibliotecario se resumen en:
6. 1. 2. 3.

Generar automticamente la librera de programas. Almacenar los mdulos en la librera. Mantener actualizada la librera.

Fase VII. Control de programas. Durante esta actividad el grupo prueba los diferentes procedimientos de lenguajes de control de tareas que se hayan utilizado. Esta prueba se realiza inmediatamente despus de las pruebas de subsistemas. 1. Prueba del sistema de informacin. Esta prueba tiene por finalidad verificar el sistema de informacin, la prueba de sistema fue diseada para localizar discrepancias o anomalas entre el sistema de informacin recientemente construido, y los objetivos y requerimientos inicialmente establecidos con los usuarios del sistema.
1. 2. 3. 2.

Organizar y discutir la prueba. Ejecutar la prueba del sistema. Elaborar y discutir el informe de pruebas.

Preparacin para la implantacin. Las actividades que realiza el grupo de desarrollo en este paso son:
1.

Elaborar el plan de implantacin.

Este plan programa todas las actividades y tareas que debe llevar a cabo el grupo de desarrollo durante la implantacin del sistema en la organizacin. Debe contener: Objetivos. Calendario de actividades. Estrategias. Procedimientos.

2. Preparar el material de adiestramiento. Despus de identificar el tipo de adiestramiento que se va a aplicar para capacitar a los usuarios en el uso y operacin del sistema, el grupo de desarrollo debe elaborar panes de capacitacin al personal que labora en la organizacin.

Fase VIII. Prueba de aceptacin. Durante esta fase los grupos de desarrollo y prueba se abocan a poner en operacin y a efectuar la prueba de aceptacin del sistema respectivamente. Esta prueba se realiza luego que el grupo de desarrollo a adiestrado a todos los usuarios en el uso; a continuacin se realiza la conversin del viejo sistema al nuevo, mediante la actualizacin de la base de datos y el inicio de las actividades propias del sistema de informacin. Finalmente se realiza la entonacin y la evaluacin del sistema recientemente instalado. Al realizar estos dos ltimos pasos, la labor del todo el personal que participo en el proyecto puede considerarse terminada, marcando asi el fi del proyecto de desarrollo y el inicio de una nueva etapa del ciclo de vida del sistema de informacin: la etapa de operacin y mantenimiento.
1.

Adiestramiento de usuarios. 1. Organizar las sesiones de adiestramiento. 2. Conducir las sesiones de adiestramiento.

2. Prueba de aceptacin. Esta prueba final del sistema la realiza el grupo de prueba con la finalidad de demostrarle a las unidades involucradas que el sistema desarrollado satisface el criterio mnimo de aceptacin que ellos han establecido.

2.1 Preparar la prueba de aceptacin. 2.2 Realizar la Prueba de aceptacin. Conversin del sistema. este es el paso ms delicado de esta fase, pues en el se inicia como tal la operacin del nuevo sistema y se abandona el viejo sistema. Previo al inicio de las actividades rutinarias del sistema de informacin, desarrollado, el grupo de desarrollo debe realizar las siguientes actividades.
3. 1.

Preparar detalles para la conversin.

Esta actividad consiste en la elaboracin de todos aquellos procedimientos especiales que se requieran para llevar acabo una conversin exitosa. Convertir los archivos. Se realiza la actualizacin complementaria de la base de datos del sistema. Concluida esta actualizacin, el sistema deber empezar a capturar, registra, validar, almacenar, los datos provenientes de las transacciones que ataen al sistema, en forma rutinaria.
1.

Mtodo de 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. El mtodo realiza una revisin al final de cada etapa para determinar si est preparado para pasar a la siguiente etapa, por ejemplo, desde el anlisis de requerimientos hasta el diseo. Cuando la revisin determina que el proyecto no est listo pasar a la siguiente, permanece en la etapa actual hasta que est preparado. El modelo en cascada est dirigido por documentos. Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo. Ayuda a minimizar los gastos de la planificacin porque permite realizarla sin planificacin porque permite realizarla sin problemas. Funciona especialmente bien si se dispone de personal poco cualificado o dispone de personal poco cualificado o inexperto, porque presenta el proyecto inexperto, porque presenta el proyecto con una estructura que ayuda a minimizar con una estructura el esfuerzo intil. En resumen, los inconvenientes del venerado modelo en cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rpido. Incluso en los casos en los que las ventajas del modelo en cascada pura superan los inconvenientes, los modelos de cascada modificada (con retroceso) pueden funcionar mejor. Las desventajas del modelo se centran en las dificultades para especificar claramente los requerimientos al comienzo del proyecto, antes de que se realice ningn trabajo de diseo y antes de escribir ningn cdigo. No proporciona resultados tangibles en forma de software hasta el final del ciclo de forma de software del ciclo de vida de Algunas herramientas, mtodos y actividades que abarcan varias etapas de la cascada; estas actividades son difciles de ajustar en las etapas discontinuas del modelo para un proyecto de desarrollo rpido, el modelo en cascada puede suponer una cantidad excesiva de documentacin. El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresin de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos sern entregados a tiempo. Caractersticas.

a) Es el predecesor de todos los modelos de ciclo de vida y ha servido de

base para otros modelos.

b) en este modelo, un proyecto progresa a traves de una secuencia

ordenada de etapas, partiendo desde su concepto inicial hasta hasta la prueba del mismo. c) El proyecto realiza una revision final de cada etapa para determinar si esta preparado para pasar a la siguiente.

Grafica del modelo cascada pura.

Modelo de ciclo de vida cascada Anlisis de requerimientos En esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. Es importante sealar que en esta etapa se debe consensuar todo lo que se requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software. Diseo del Sistema Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo

detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos defunciones que van a estar asociadas) y sus relaciones Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin. Diseo del Programa Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la siguiente etapa. Codificacin Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido. Pruebas Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final. Implantacin Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. Mantenimiento Una de las etapas que creo considerables porque se destina un 75% de los recursos, es la mantencin del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas. Mtodo espiral. El modelo en espiral del proceso del software que originalmente fue propuesto por Boehm (1988), El modelo en espiral es una delas metodologas ms recomendables para el desarrollo y creacin de un programa, ya que consta de pocas etapas o fases, las cuales se van realizando en una manera continua y cclica.

Es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construccin de prototipos, pero conservado aquellas propiedades del modelo en cascada. El modelo en espiral fue desarrollado por Boehm, quien lo describe as: 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. Se caracteriza principalmente por: - Un enfoque cclico para el crecimiento incremental del grado de definicin e implementacin de un sistema, mientras que disminuye su grado de riesgo. - Un conjunto de puntos de fijacin para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias. El modelo espiral captura algunos principios bsicos: Decidir qu problema se quiere resolver antes de viajar a resolverlo. Examinar tus mltiples alternativas de accin y elegir una de las ms convenientes. Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer algo. No ser tan ingenuo para pensar que el sistema que ests construyendo ser "EL" sistema que el cliente necesita. Conocer (comprender) los niveles de riesgo, que tendrs que tolerar. El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles. Esquema del modelo espiral.

En cada vuelta tomamos en cuenta:

Determinar o fijar objetivos Fijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de usuario. Fijar las restricciones. Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos. Hay una cosa que solo se hace una vez: planificacin inicial o previa. Anlisis del riesgo Se lleva a cabo el studio de las causas de las posibles amenazas y probables eventos no deseados y los daos y consecuencias que stas puedan producir. Planificar Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. Desarrollar, verificar y validar (probar) Tareas de la actividad propia y de prueba. Anlisis de alternativas e identificacin resolucin de riesgos. Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal consideracin, un desarrollo basado en transformaciones formales podra ser el ms apropiado. Mecanismos de control. La dimensin radial mide el coste. La dimensin angular mide el grado de avance del proyecto. Ventajas El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc.

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. Desventajas. Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgos

Este sistema es muy utilizado en proyectos largos como pueden ser la creacin de un Sistema Operativo. Y que necesitan constantes cambios. Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su xito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo. Metodo de codificar y corregir (Code-and-fix) 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. Ventajas: 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. Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de progreso. Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa est familiarizada con ste modelo. 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. Desventajas: El modelo resulta peligroso para otro tipo de proyectos que no sean pequeos. Puede que no suponga gestin alguna, pero tampoco ofrece medios de evaluacin del progreso.

No proporciona medios de evaluacin de la calidad o de identificacin de riesgos. 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.

Mtodo prototipo Este mtodo hace que el usuario participe de manera ms directa en la experiencia de anlisis y diseo que cualquiera de los ya presentados. La construccin de prototipos es muy eficaz bajo las circunstancias correctas. Sin embargo, al igual que los otros mtodos, el mtodo es til slo si se emplea en el momento adecuado y en la forma apropiada. Qu es un prototipo? El prototipo es un sistema que funciona, no solo una idea en el papel, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que cualquier sistema basado en computadora, est constituido por software que acepta entradas, realiza clculos, produce informacin ya sea impresa o presentada en una pantalla, o que lleva a cabo otras actividades significativas. Es la primera versin, o iteracin, de un sistema de informacin. Lo usuarios evalan el diseo y la informacin generada por el sistema. Lo anterior slo puede hacerse con efectividad si los datos utilizados, al igual que las situaciones, son reales. Por otra parte, deben esperarse cambios a medida que el sistema es utilizado. Razones para desarrollar prototipos de sistemas: Los requerimientos de informacin no siempre estn bien definidos. Es probable que los usuarios conozcan slo ciertas reas de la empresa donde se necesiten mejoras o cambios en los procedimientos actuales. Tambin es posible que reconozcan la necesidad de tener mejor informacin para administrar ciertas actividades pero que no estn seguros cual de esta informacin ser la adecuada. Los requerimientos del usuario pueden ser demasiado vagos aun al formular el diseo. En otros casos, es probable que una investigacin de sistemas bien llevada necesite del desarrollo de nueva tecnologa. Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de disear e implantar sistemas no tienen informacin ni experiencia, o tambin donde existen situaciones de riesgo y costo elevados, y aquellas donde el diseo propuesto es novedoso y an no se demuestra es la factibilidad de que los vendedores enven ordenes de pedido al sistema de cmputo de la compaa desde el sitio donde efectan la operacin por medio de terminales porttiles enlazadas a telfonos pblicos. Para probar el

concepto los administradores y encargados de sistemas pueden optar por construir una versin en pequea escala del software, adquirir unas cuantas terminales y seleccionar un grupo de vendedores. El prototipo proporcionar informacin preliminar sobre la funcionalidad del concepto. El prototipo es, en realidad, un modelo piloto o de prueba, en general, los analistas de sistemas encuentran que los prototipos tienen mayor utilidad bajo las siguientes condiciones: Los encargados de disear e implantar sistemas nunca han desarrollado uno con las caractersticas del sistema propuesto. Se conoce slo una parte de las caractersticas esenciales del sistema; las dems no son identificables a pesar de un cuidadoso anlisis de requerimientos. La experiencia con el uso del sistema aadir una lista significativa de requerimientos que el sistema debe satisfacer. Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo adicional y el refinamiento de sus caractersticas. Los usuarios del sistema participan en el proceso de desarrollo.

Los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes: Identificar los requerimientos de informacin que el usuario conoce junto con las caractersticas necesarias del sistema. Desarrollar un prototipo que funcione. Utilizar el prototipo anotando las necesidades de cambios y mejoras. Esto expande la lista de los requerimientos de sistemas conocidos. Revisar el prototipo con base en la informacin obtenida a travs de la experiencia del usuario. Repetir los pasos anteriores las veces que sea necesario hasta obtener5 un sistema satisfactorio.

l analista debe de reunirse con los usuarios una o dos veces con la finalidad de identificar los requerimientos. El resultado de estas reuniones forma la base para la construccin del prototipo. El desarrollo de un prototipo que funcione es responsabilidad del analista de sistemas, cuando el analista y el usuario deciden que cuentan ya con la suficiente informacin proveniente del proceso de construccin del prototipo, determinan cmo satisfacer los requerimientos ya identificados. En general se opta por una de las siguientes opciones: Volver a desarrollar el prototipo. Esta alternativa quiz signifique volver a programar por completo, empezando desde el principio. Implantar el prototipo como sistema terminado La eficiencia en el funcionamiento junto con los mtodos para interactuar con el usuario son suficientes; esto permite utilizar el sistema tol como est. Abandonar el proyecto. En este caso el prototipo ha proporcionado informacin suficiente para demostrar que no es posible desarrollar el

sistema para satisfacer los objetivos deseados dentro del marco de la tecnologa existente o de lineamientos econmicos u operacionales. Iniciar otra serie de construccin de prototipos. La informacin ganada con la experiencia sugiere ya sea un enfoque totalmente distinto o caractersticas contrastantes.

Cada una de estas opciones se considera como un xito en el proceso de la construccin de prototipos.

Mtodos para el desarrollo de prototipos Con los prototipos la velocidad de desarrollo es ms importante que la eficiencia en el procesamiento. Un sistema prototipo se construye con rapidez, los sistemas prototipo pueden desarrollarse con mtodos y lenguajes de programacin convencionales, quiz falten los controles de entrada y procesamiento y, en general, la documentacin del sistema es un punto que suele evitarse. Lo importante es ensayar ideas y generar hiptesis relacionadas con los requerimientos y que la eficiencia y perfeccin alcanzadas. La industria de computadora busca continuamente generadores de aplicaciones, programas que sirven para generar otros programas, para apoyar los esfuerzos de la construccin de prototipos. En algunos casos, aquellos donde el sistema ser utilizado con poca frecuencia, el prototipo puede, de hecho, convertirse en el sistema terminado. Mtodo de anlisis y diseo 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 sa dificultad por medio de 1) la divisin del sistema en componentes y 2) la construccin de un modelo del sistema. El mtodo incorpora elementos tanto de anlisis como de diseo.

Qu es el anlisis estructurado? El anlisis estructurado concentra en especificar lo que se requiere que haga el sistema o la aplicacin. No se establece cmo se cumplirn los requerimientos o la forma en que implantar la aplicacin. Ms bien permite que las personas observen los elementos lgicos (lo que har el sistema) separados de los componentes fsicos (computadoras, terminales, sistemas de almacenamiento, etc.) Despus de esto se puede desarrollar un diseo fsico eficiente para la situacin donde ser utilizado. Elementos del anlisis estructurado: Los elementos esenciales son smbolos grficos, diagramas de flujo de datos y diccionario centralizado de datos.

Descripcin grfica Una de las formas de describir un sistema es preparar un bosquejo que seale sus caractersticas, identifique la funcin para la que sirve e indique cmo ste interacta con otros elementos, entre otras cosas. Sin embargo, describir de esta manera un sistema grande es un proceso tedioso y propenso a errores ya que es fcil omitir algn detalle o dar una explicacin que quiz los dems no entiendan. En lugar de las palabras el anlisis estructurado utiliza smbolos, o conos, para crear un modelo grfico del sistema. Los modelos de este tipo muestran los detalles del sistema. Si se seleccionan los smbolos y notacin correctos entonces casi cualquier persona puede seguir la forma en que los componentes se acomodarn entre si para formar el sistema. El diagrama lgico de flujo de datos muestra las fuentes y destinos de los datos, identifica y da nombre a los procesos que se llevan a cabo, identifica y da nombre a los grupos de datos que relacionan una funcin con otra y seala los almacenes de datos a los que se tiene acceso. Diagrama de flujo de datos: El modelo del sistema recibe el nombre de diagrama de flujo de datos (DFD). La descripcin completa de un sistema est formada por un conjunto de diagramas de flujo de datos. Para desarrollar una descripcin del sistema por el mtodo de anlisis estructurado se sigue un proceso descendente (TOP-down). El modelo original se detalla en diagramas de bajo nivel que muestran caractersticas adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujo de datos cada vez ms detallados. Esta secuencia se repite hasta que se obtienen suficientes detalles que permiten al analista comprender en su totalidad la parte del sistema que se encuentra bajo investigacin. Diccionario de datos: Todas las definiciones de los elementos en el sistema (flujo de datos, procesos y almacenes de datos) estn descritos en forma detallada en el diccionario de datos. Si algn miembro del equipo encargado del proyecto desea saber alguna definicin del nombre de un dato o el contenido particular de un flujo de datos, esta informacin debe encontrarse disponible en el diccionario de datos. Que es el diseo estructurado? Se enfoca en el desarrollo de especificaciones del software. La meta del diseo estructurado es crear programas formados por mdulos independientes unos de otros desde el punto de vista funcional. El diseo estructurado es una tcnica especfica para el diseo de programas y no un mtodo de diseo de comprensin. Esta tcnica conduce a la especificacin de mdulos de programa que son funcionalmente independientes. La herramienta fundamental del diseo estructurado es el

diagrama estructurado, los cuales son de naturaleza grfica y evitan cualquier referencia relacionada con el hardware o detalles fsicos. Su finalidad no es mostrar la lgica de los programas. Los diagramas estructurados describen la interaccin entre mdulos independientes junto con los datos que un mdulo pasa a otro cuando interacciona con l. Estas especificaciones funcionales para los mdulos se proporcionan a los programadores antes que d comienzo la fase de escritura de cdigo.

Empleo del Anlisis estructurado con otros mtodos de desarrollo: El anlisis estructurado se combina, con bastante frecuencia, con el mtodo ya presentado de ciclo de vida clsico de desarrollo de sistemas. Por ejemplo, los analistas pueden optar ms de flujo de datos como una forma para documentar las relaciones entre componentes durante la investigacin detallada de algn sistema existente, Asimismo, se puede definir los archivos y datos en un diccionario centralizado de datos de acuerdo con las reglas de anlisis estructurado. Sin embargo muchas organizaciones optan por no utilizar este mtodo de desarrollo. Por ejemplo, los analistas deciden con frecuencia que el desarrollo de diagramas y esquemas es una tarea que consume mucho tiempo, sobre todo si el sistema es grande y complejo. (Es comn que los diagramas tengan que dibujarse una y otra vez conforme se adquiere nueva informacin). Como se ver ms adelante, se han desarrollado herramientas asistidas por computadora para superar este problema. Otros analistas sealan que los elementos que faltan, tales como las personas y los procedimientos de control, son parte del sistema mismo y no pueden omitirse en la descripcin de ste. Ms adelante se considerar este aspecto tan importante.

Cuadro comparativo
MODELO ENFOQUE VENTAJAS /DESVENTAJAS Los proyectos raras veces siguen una evolucin secuencial. No todos los requisitos son expuestos, al principio, de forma explcita como requiere este modelo. El cliente debe tener paciencia, ya que la aplicacin slo estar disponible en un estado muy avanzado del proyecto. Ampliamente criticado desde el mbito acadmico y la industria. Requiere comunicacin permanente con el cliente por lo tanto si se Utilizado para el desarrollo de aplicaciones complejas y/o especficas. (Ej. APLICABILIDAD

El inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del desarrollo.

MODELO EN CASCADA

Utilizado cuando existen especificaciones amplias de los requerimientos del cliente.

MODELO ESPIRAL

Es una mejora del Modelo Basado en prototipos Cada vuelta en la espiral

representa una fase del proceso. No hay fases fijas, cada vuelta en la espiral determina las actividades a realizar. La dimensin radial representa el coste acumulado en la financiacin de las fases. La dimensin angular representa el progreso hecho en completar cada ciclo de la espiral. Un ciclo a travs de la espiral es simular un paso a travs de un modelo en cascada MODELO BASADO EN PROTOTIPOS Prototipos: No posee la funcionalidad total del sistema pero si condensa la idea principal del mismo, Paso a Paso crece su funcionalidad, alto grado de participacin del usuario.

cambia el contacto con le cual se realiza desarrollo es necesario que est al tanto de lo realizado y lo pendiente, cliente debe ser gran conocedor del sistema.

Investigacin Gentica)

El cliente puede pensar que el prototipo es una versin acabada. Pueden llegar a pasarse por alto la calidad del software global o el mantenimiento a largo plazo. Las herramientas elegidas pueden ser inadecuadas. La clave del xito de este modelo consiste en

Se utiliza si en el mercado no se encuentra el producto pero el cliente desea resultados inmediatos. Conveniente en caso de ser necesario desarrollar mdulos Para sistemas interactivos pequeos o de tamao pequeo.

definir bien, desde el principio, las reglas del juego. Alto grado de participacin del usuario MODELO Modelo LinealINCREMENTAL O Secuencial con el EVOLUTIVO Modelo Basado en Prototipos El sistema no se entrega de una vez, sino que se divide y se entregan incrementos. Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos ms crticos.

1. Para partes de sistemas grandes 2. Para sistemas con vida corta. Reemplazar el antiguo desarrollo con uno nuevo que satisfaga las nuevas necesidades segn las redefiniciones del problema Manejo de Versiones

Los primeros incrementos Con cada sirven como incremento se prototipo y entrega la parte ayudan en la de la tarea de detectar funcionalidad que los posteriores se ha establecido. requisitos. Los requisitos son priorizados. Los requisitos con una ms alta prioridad se incluyen en los incrementos ms tempranos. Los requisitos de un incremento son inamovibles. Sin embargo estos pueden verse modificados en incrementos posteriores. Este proceso se repite hasta la obtencin de un Existe un riesgo bajo de fallar en el proyecto total. Los servicios del sistema con la prioridad ms alta tienden a ser los ms probados. Puede ser difcil ajustar los requisitos a los incrementos.

producto completo. Sin embargo el modelo incremental se centra en la entrega de un producto operativo en cada incremento.

Conclusin
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. A la hora de planificar, desarrollar e implantar los sistemas de informacin ha de realizarse por parte de la empresa un alineamiento de la estrategia global de la compaa y los sistemas de informacin, identificando las principales necesidades y evaluando los distintos mtodos de satisfaccin, teniendo presente en todo momento cules son las tecnologas de informacin disponibles en el mercado y como estas pueden utilizarse. Adems han de definirse claramente cules son los objetivos de los sistemas de informacin. El proceso de desarrollo de los sistemas de informacin afectar en gran medida al xito o fracaso de la organizacin; las organizaciones tendrn que adecuar los sistemas de informacin a sus recursos de capital y las necesidades de la organizacin. La posesin de la compaa los ordenadores ms avanzados, los mejores programas y la mejor red de telecomunicaciones no resulta indicativo de un mejor sistema de informacin, pues en ocasiones puede que con tecnologas de informacin ms modestas se satisfagan de igual manera las necesidades de la compaa. Por ello toda empresa ha de considerar los sistemas de informacin como un todo, un elemento ms de su poltica de negocio.