CAPTIULO 4 METODOLOGA Y TECNICAS PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN

Jons Montilva C. ANLISIS Y DISEO DE SISTEMAS

4-11

A lo largo de este trabajo hemos partido de un principio al que hemos denominado el Trinomio del Desarrollo, el cual establece que el xito de un proyecto para desarrollar un sistema de informacin depende de tres elementos claves: 1.2.3.La Administracin del Proyecto. El Seguimiento de una Metodologa. La Aplicacin de Tcnicas y Herramientas.

La administracin del proyecto es un conjunto complejo de actividades cuya responsabilidad recae en el gerente del proyecto. En el captulo 3 describimos las cinco funciones bsicas que debe ejecutar un gerente para garantizar una buena y eficiente administracin de un proyecto de esta naturaleza. La metodologa y las tcnicas-herramientas estn dirigidas a todo el grupo de desarrollo, esto es, al grupo que llevar adelante el proyecto bajo la coordinacin del gerente. En este captulo nos dedicaremos a estudiar estos dos elementos claves. Dentro de este orden de ideas, proponemos una metodologa, a la que identificaremos bajo el nombre de MEDSI {Metodologa Estructurada para el Desarrollo de Sistemas de Informacin). A medida que se vaya describiendo la metodologa, iremos indicando y explicando, donde sea apropiado, las tcnicas y herramientas que el grupo debe utilizar para llevar a cabo una ejecucin eficiente y eficaz de las diferentes actividades y tareas que componen un proyecto de este tipo.

MEDSI METODOLOGA ESTRUCTURADA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN

MEDSI es una metodologa estructurada para desarrollar sistemas de informacin en y para organizaciones de cualquier tipo. Ha sido probada con xito en el desarrollo de diferentes sistemas de informacin para la administracin de la Universidad de Los Andes en Mrida, entre los que se destacan los siguientes: Sistema de Informacin para el Personal Administrativo, Tcnico y de Servicio. Sistema de Informacin de Proveedores. 4-1

Sistema de Asignacin de Salones para una Facultad.

En la actualidad (1984), la metodologa est siendo utilizada rigurosamente en los siguientes proyectos para la misma universidad: Sistema de Informacin para el Personal Docente y de Investigacin. Sistema de Informacin de la Fundacin Universidad de Los Andes.

tos como para eliminar algunos. De igual modo, puede adaptarla a las condiciones, exigencias y caractersticas de la organizacin donde se utilice o a cualquier otro tipo de proyecto de sistemas de informacin. NOTA EXPLICATIVA SOBRE LOS DIAGRAMAS: Los diagramas utilizados en esta metodologa para explicar las diferentes fases estn basados en la tcnica de Anlisis Estructurado de Sistemas, v corresponden a lo que, en trminos de esa tcnica, recibe el nombre de Diagramas de Flujo de Datos. Los elementos para construir un diagrama de flujo de datos son los siguientes:

Entre las caractersticas resaltantes de esta metodologa podemos sealar las siguientes: 1.ES ESTRUCTURADA.- Esta caracterstica se debe a dos razones esenciales: (a) 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 (b) Gua paso a paso -de arriba hacia abajo- al 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 desarrollar un 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 casos, enumerando las tareas especficas que los miembros del grupo deben efectuar. ES PARTICIONADA.- A fin de manipular mejor la complejidad inherente a un proyecto de este tipo, la metodologa se divide en fases (al igual que el ciclo de desarrollo descrito en el captulo 2). Cada una de estas fases se dividen en pasos, los cuales estn orientados a algn tipo de tpico, aspecto o elemento del sistema de informacin. Cada paso, a su vez, agrupa a un conjunto de actividades que han de ser realizadas por el grupo de desarrollo. Donde as se requiera, las actividades se descomponen en tareas especficas, las cuales deben ser ejecutadas por un miembro o sub-grupo en un plazo o perodo de tiempo relativamente corto (para proyectos grandes: entre 1 y 2 semanas, generalmente). Las fases y pasos se orientan a mostrar que debe hacer el grupo de desarrollo, mientras que las actividades y tareas, o bien, detallan lo que debe hacerse, o muestran como hacerse mediante la aplicacin de alguna tcnica. 4.ES MODIFICABLE Y ADAPTABLE.- El grupo de desarrollo puede modificar fcilmente la metodologa, bien para introducir nuevos elemen-

Utilizado para representar un proceso, actividad o tarea. (Aqu lo utilizamos para representar una fase o paso de la metodologa). Representa un canal de datos por donde fluyen datos, en la forma de documentos, informes, etc. Identifican a elementos externos que reciben informacin o envan datos. Identifican a un medio de almacenamiento de datos, manual o automtico. Una caracterstica de este tipo de diagrama es que no muestra ni control, ni movimiento, a diferencia de los conocidos diagramas de flujo. Los diagramas de flujo de datos son utilizados para representar en forma esttica los diferentes procesos de una funcin y los flujos de datos que entran y salen de esos procesos, as como, los medios de almacenamiento de esos flujos y sus fuentes/destinatarios externos. La ventaja de ellos es que permiten visualizar rpidamente todos los procesos y sus interrelaciones mediante flujos de datos.

2.-

3.-

ALGUNAS CONSIDERACIONES SOBRE MEDSI

Tal como se presenta aqu, MEDSI est orientada a proyectos medianos y grandes que ameriten la integracin de grupos de desarrollo conformados por 3 o ms personas y 1.- que puedan requerir, para su desarrollo, varios meses. Es evidente que, para un proyecto pequeo, el seguimiento estricto de cada fase, paso y actividad aqu presentada, lejos de facilitar su desarrollo, lo entorpecera. Para este ltimo tipo de proyecto, el ingeniero o profesional que lo va a desarrollar deber seleccionar un subconjunto de las fases, pasos y actividades mostradas, esto es, deber adaptar la metodologa a su proyecto.

4-2

4-2

2.-

Al igual que toda metodologa, MEDSI es una gua de trabajo y no una " receta de cocina", por lo tanto el grupo de desarrollo no deber esperar que el seguimiento riguroso y estricto de las fases, pasos, y en particular, de las actividades que se describen en MEDSI, produzca automticamente un sistema de informacin. Cada proyecto tendr sus propias caractersticas, al igual que cada grupo de desarrollo y el ambiente que lo rodea, por lo que la revisin y modificacin de las fases, pasos o actividades de la metodologa, antes y durante el desarrollo del sistema, es un proceso propio de ella, que deber regirse fundamentalmente por las normas y procedimientos que la organizacin haya establecido para el desarrollo de sus sistemas de informacin. Por ello es indispensable que un grupo de la organizacin, como por ejemplo la Comisin de Planificacin de S.I., determine cuales de las fases, pasos o actividades tienen un carcter obligatorio, cuales podrn ser modificadas y cuales omitidas en un momento dado. As mismo, conviene determinar que tcnicas se deben emplear en las distintas fases o pasos y que estructura y contenido debe tener cada uno de los documentos producidos (manuales, informes, planillas, instructivos, etc.), a fin de garantizar la uniformidad en la documentacin de los distintos sistemas de la organizacin.

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERA DEPARTAMENTO DE COMPUTACIN

* * * MEDSI * * *METODOLOGA ESTRUCTURADA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN

Versin: 1

Fecha: Noviembre

Autor: J. Montilva C.

FASES DE LA

3.-

4-4El lector notar que algunas actividades se repiten en diferentes pasos y fases de la metodologa. Por ejemplo, la definicin de requerimientos se repite en los pasos 1.1, 1.2 de la fase de Definicin del Proyecto y, por supuesto, en los pasos 3.1, 3.2 y 3.3 de la fase de Definicin de Requerimientos (algo similar ocurre, tambin, con el anlisis del sistema actual y con las pruebas). La diferencia entre estas actividades que se repiten est en el grado de detalle y formalismo de ellas. Durante los primeros pasos o fases, la actividad se realiza de modo somero o superficial, luego, se va refinando, esto es, entrando en los detalles, para finalmente concretar y formalizar el aspecto o elemento tratado en ellas. Esta es precisamente una de las razones por las cuales la metodologa se define como estructurada; pues usa el enfoque estructurado.

4-4

4-5

DESCRIPCIN GENERAL DE LAS FASES: FASE l: A raz del surgimiento de nuevas necesidades y requerimientos, la organizacin designa a un gerente de proyecto cuya primera misin es definir el proyecto, esto es, justificar el desarrollo de un nuevo sistema de informacin, establecer su factibilidad y de ser factible, planificarlo. El resultado de esta fase se resume en los informes Preliminar y de Factibilidad y en el Plan del Proyecto, el cual coordinar todas las tareas del proyecto. FASE 2: Si el proyecto es factible y su desarrollo es aprobado, entonces se inicia el proceso de desarrollo de un nuevo sistema de informacin. En esta fase el gerente organiza el grupo de desarrollo, iniciando de inmediato un anlisis del contexto en el cual se va a ubicar el sistema. Para ello se recaba toda la documentacin relacionada, se analiza el ambiente, la estructura y los procesos del sistema ampliado (marco del sistema de informacin). Si existe un sistema actual de informacin, ste se analiza a fin de detectar sus deficiencias, fallas y problemas mediante la construccin de un modelo. FASE 3: Se determina, junto con los usuarios, los requerimientos que debe satisfacer el nuevo sistema de informacin. As mismo, se establecen las funciones, restricciones y atributos de calidad del sistema, los cuales se ensamblan en la Especificacin Funcional y se resumen en un informe del Nuevo Sistema. FASE 4. Se producen diferentes prototipos o diseos preliminares del sistema que satisfagan la especificacin funcional, para luego seleccionar el ms conveniente a la organizacin. Este prototipo se describe en el informe del Diseo Preliminar. La Configuracin Tcnica describe las caractersticas del equipo y los programas de apoyo requeridos por el prototipo. FASE 5: Se realiza un diseo detallado de los diferentes componentes del sistema de informacin tomando como referencia el prototipo del sistema; este diseo se ensambla en el paquete de diseo. Adicionalmente, se elabora el Plan de Pruebas d e l l o s diferentes componentes del sistema. FASE 6: Se construye el sistema de acuerdo a lo especificado en el paquete de diseo y se explica detalladamente cada prueba en las respectivas Especificaciones de Prueba. FASE 7: Se prueba el sistema en base a las especificaciones de prueba y se elabora un plan para la implantacin del sistema. FASE 8: Se implanta el sistema de informacin mediante el adiestramiento de los usuarios, la conversin del sistema existente al recientemente construido (puesta operacin) y la entonacin inicial del sistema de informacin. Finalmente, se entrega sistema a los usuarios y al grupo de mantenimiento junto con el Informe Final del proyecto.

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERA DEPARTAMENTO DE COMPUTACIN

* * * MEDSI * * * METODOLOGA ESTRUCTURADA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN

Versin: 1

Fecha: Noviembre 1983

Autor: J. Montilva C.

FASE 1: DEFINICIN DEL PROYECTO

OBJETIVOS: 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 provecto. Si se decide realizarlo, se elabora el Plan del Proyecto. PASOS:

4-6

4-7

La definicin del proyecto se inicia luego que las unidades interesadas solicitan a la unidad ejecutora de sistemas de informacin de la organizacin que se estudie la posibilidad de desarrollar un sistema que satisfaga sus necesidades. La unidad ejecutora asigna a un gerente de proyectos para que defina el proyecto. El gerente elabora primero un informe preliminar que justifique o no el emprender el desarrollo de un nuevo sistema. Si se justifica, el gerente elabora un estudio de factibilidad que determina si el proyecto es tcnica, econmica y psicosocialmente realizable. Si el proyecto es-factible y las unidades involucradas deciden continuar con el mismo, se elabora un plan general del proyecto que estime con mayor precisin, que el estudio de factibilidad, los costos, la duracin y los recursos necesarios para emprender el provecto de desarrollo de un nuevo sistema de informacin. Las unidades involucradas pueden decidir la paralizacin del mencionado proyecto durante la ejecucin de cualquier paso o actividad, para ello se asigna a la Comisin de Planificacin para que realice la, correspondiente evaluacin del proyecto a lo largo del ciclo de desarrollo.

As mismo, se busca determinar las necesidades preliminares que puedan o no justificar el desarrollo del sistema nuevo. Algunas de las interrogantes que se han de respond er 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 un nuevo sistema? Qu tipo de informacin debera producirse? Qu caractersticas debera tener la informacin que se produzca? 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 v datos relevantes sobre el sistema actual, sus inconvenientes y las necesidades de cambio. Analizar la documentacin archivada. 1.1.3.- ELABORAR EL INFORME PRELIMINAR.-

DESCRIPCIN DE PASO: 1.1.- ESTUDI PRELIMINAR DEL PROYECTO.Este estudio demuestra 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.1.- RECONOCER EL PROBLEMA.Implica efectuar las acciones necesarias para reconocer que existe un problema de informacin. Las tareas que el gerente debe realizar en esta actividad son: Recopilar y analizar aquellos elementos que indiquen la necesidad de un nuevo sistema (Ejem. cartas, informes, conversaciones, etc.). Realizar reuniones preliminares con el personal de las unidades involucra das para definir la necesidad de un cambio. 1.1.2.- FORMULAR EL PROBLEMA.Esta actividad busca diagnosticar, de modo muy general, el sistema actual, si es que ste existe, tratando de responder, entre otras, las siguientes interrogantes: Qu hace este sistema actual? Qu objetivos 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?

A partir del anlisis anterior, el gerente debe elaborar ahora 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 de informacin. 1.1.4.- DISCUTIR EL INFORME PRELIMINAR.El gerente presenta el informe preliminar a los directivos de las unidades involucradas quienes deciden, a partir de este informe, si se emprende el provecto o no; o si es necesario un mayor estudio. 1.1.5.- 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 de planificacin: Determinar las actividades y tareas necesarias para conducir un estudio de factibilidad. Determinar los recursos requeridos. Programar los tiempos de las actividades y tareas. Seleccionar el grupo para el estudio de factibilidad. Asignar las tareas al grupo seleccionado.

4-8

4-9

1.2.- ESTUDIO DE FACTIBILIDAD. Una vez que se ha justificado la necesidad de un nuevo sistema de informacin, 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 de informacin. Por consiguiente, el grupo de factibilidad debe realizar las actividades siguientes: 1.2.I.- EVALUAR EL SISTEMA ACTUAL. Siempre y cuando exista un sistema actual de informacin, el grupo debe evaluar. en este momento, dicho sistema. Esta evaluacin tiene un carcter general, aunque e-ms detallada que el diagnstico de la actividad 1.1.2. Las tareas que debe realizar el grupo durante esta actividad se mencionan a continuacin: Analizar el ambiente del sistema actual'. Definir sus objetivos. Determinar el flujo de informacin e identificar las entradas, procesos. salidas y archivos del sistema. Determinar los principales problemas y caractersticas de las entradas, procesos, salidas y archivos. Establecer los costos de operacin, el grado de satisfaccin de lo, requerimientos de los usuarios, los atributos de calidad del sistema y sus caractersticas generales.

1.2.3- FORMULAR SISTEMAS ALTERNATIVOS.El grupo identifica, en esta actividad, diferentes configuraciones para el sistema de informac in (Ejem. centralizado, descentralizado, distribuido, procesamiento interjectivo, procesamiento en lotes, etc.) que satisfagan los requerimientos generales establecidos en la actividad anterior. Las tareas que han de realizarse son: Identificar configuraciones alternativas. Para cada alternativa: Describir sus caractersticas principales. Determinar que requerimientos no se satisfacen total o parcialmente. Definir el grado de automatizacin, i.e., que procesos o funciones se automatizan y cuales han de ser manuales. Determinar que restricciones y atributos no se pueden satisfacer. 1.2.4.1.2.4.- DETERMINAR FACTIBILIDAD TCNICA.Para cada sistema alternativo se debe establecer su factibilidad tcnica, ello debe 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 la tecnologa (equipos y programas) de que dispone la organizacin. Para cada sistema alternativo: Determinar la tecnologa demandada. Determinar la tecnologa adicional que debe adquirirse.

1.2.2.- ESTABLECER NUEVOS REQUERIMIENTOS EN FORMA GENERAL. En esta actividad el grupo se dedica a establecer los requerimientos generales de un nuevo sistema, mediante la realizacin de las tareas siguientes: Identificar los objetivos del nuevo sistema. Establecer los requerimientos de informacin (entradas, salidas y archivos). Establecer los requerimientos de procesamiento (funciones). Establecer restricciones y atributos preliminares.

1.2.5.- DETERMINAR FACTIBILIDAD ECONMICA.En esta actividad el grupo debe realizar un Anlisis Costo-Beneficio que permita i dentificar y medir los costos de desarrollo y operacin y los beneficios que obtiene la or ganizacin de cada sistema alternativo; para luego comparar las diferentes alternativas bajo un criterio econmico. Deben, tambin, estimarse los tiempos de desarrollo de cada sistema propuesto a fin de medir la factibilidad econmica de cada uno de ellos.

1.2.6. - DETERMINAR FACTIBILIDAD PSICOSOCIAL.La implantacin de un sistema de informacin automatizado en cualquier organizacin crea un impacto social, que puede ocasionar una aceptacin o el rechazo t otal al cambio tecnolgico que se pretende introducir. El grupo, por lo tanto, debe predecir o estimar para cada alternativa el impacto social que ellas puedan originar d entro de la organizacin.

1 . - Se entiende como ambiente del sistema o sistema ampliado al sistema de actividades de la organizacin (Ejem. sistema: financiero. contable, de personal, etc.), al cual le presta apoyo el sistema de informacin objeto de estudio.

4-10

4-11

1.2.7.- ELABORAR EL INFORME DE FACTIBILIDAD.Este informe describe cada sistema alternativo y resume su factibilidad tcnica, econmica y psicosocial. 1.2.8.- DISCUTIR EL INFORME DE FACTIBILIDAD.El gerente del proyecto presenta el informe a la Comisin de Planificacin, quienes junto con los directivos de las unidades involucradas discuten la factibilidad de cada alternativa y seleccionan la ms conveniente a los intereses de la organizacin. El proyecto puede ser paralizado debido a que no existan alternativas factibles o convenientes a la modificacin.

1.3 . 10.- REVISAR EL PLAN DEL PROYECTO 2 .El grupo de desarrollo revisa y discute los diferentes planes elaborados por el gerente antes de iniciar el desarrollo de las siguientes fases. Posteriormente, el gerente integra los planes para configurar el documento contentivo del plan del proyecto. 1.3.11.- DISCUTIR EL PLAN DEL PROYECTO. Finalmente, el gerente del proyecto presenta y somete a discusin el plan del proyecto ante la Comisin de Planificacin, que luego recomienda su continuacin, modificacin o suspensin.

MTODOS Y TCNICAS EMPLEADAS EN ESTA FASE:

1.3.-

PLANIFICACIN DEL PROYECTO.1.- TCNICAS PARA LA TOMA DE DATOS.- Entre estas tcnicas se destacan las siguientes: entrevistas, cuestionarios, observacin directa, muestreo y tablas de decisin. Lis siguientes referencias bibliogrficas explican adecuadamente estas tcnicas: (BURCH Y STRATER, 1974) (SENN, 1978)
2.- ANLISIS COSTO-BENEFICIO.- Esta tcnica se describe en las siguientes referencias:

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 con detalle los costos, tiempo y reclusos necesarios para llevarlo a cabo. Este paso tiene por finalidad elaborar un documento que gue el desarrollo de proyecto y que denominaremos el PLAN DEL PROYECTO. La elaboracin de este documento se describe con detalle en el captulo 3 de este libro, por lo que se omite aqu los detalles correspondientes. Las actividades que debe realizar el gerente de proyecto durante el proceso de planificacin se muestran a continuacin:

(KING Y SCHREMS, 1978) (ROBERSHAW y otros, 1978) 1.3.1.- ELABORAR EL PLAN GENERAL. 1.3.2.- ELABORAR EL PLAN GENERAL DE FASES. 1.3.3.- ELABORAR EL PLAN GENERAL DE ORGANIZACIN. 1. 3. 4. ELABORAR EL PLAN GENERAL METODOLGICO. 1.3.5.- ELABORAR EL PLAN GENERAL DE ADMINISTRACIN DE LA CONFIGURACIN. 1.3.6.- ELABORAR EL PLAN GENERAL DE ADMINISTRACIN DE RECURSOS. 1. 3. 7. ELABORAR EL PLAN GENERAL DE DOCUMENTACIN. 1. 3. 8. ELABORAR EL PLAN GENERAL CALENDARIO DE EVENTOS. 1.3.9.- SELECCIONAR EL GRUPO DE DESARROLLO.A partir del plan de organizacin, el gerente del proyecto solicita y selecciona e personal que va a elaborar el proyecto. La organizacin del grupo de desarrollo puede estar basada en uno de los tres tipos discutidos en la seccin 3.3 del captulo 3 de presente libro. 4-12
4-13

3.- TCNICAS DE PLANIFICACIN Y CONTROL DE PROYECTOS.- Vase seccin 3.2, captulo 3.

2 . - Los planes de pruebas y de implantacin se elaboran en las fases de diseo e implantacin respectivamente.

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERA DEPARTAMENTO DE COMPUTACIN

* * * MEDSI * * * METODOLOGA ESTRUCTURADA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN

Versin: 1

Fecha: Noviembre 1983

Autor: J. Montilva C.

Antes de realizar el anlisis propiamente dicho de todo el sistema, denominado Anlisis del Contexto, el grupo de desarrollo debe recopilar, archivar y analizar toda la documentacin existente que est relacionada con el sistema actual y su contexto, y construir lo que denominaremos como la Biblioteca del Proyecto, de acuerdo a lo establecido en el plan de documentacin del plan del proyecto. Este primer paso de la se 2 es denominado Anlisis Documental y constituye una fuente valiosa de documentacin para emprender el segundo paso. Esta fase se resume en lo que designaremos como el Informe del Sistema Actual, documento cuyo contenido central es el Modelo del Sistema Actual-y la descripcin de situaciones problemticas asociadas a este sistema dentro del sistema ampliado o contexto que lo contiene. Si no existe un sistema actual de informacin, esta fase se limita a obtener la documentacin relativa al ambiente donde estar ubicado el sistema que se pretende introducir por primera vez y a analizar dicho ambiente.

DESCRIPCIN DE PASOS: 2.1.- ANLISIS DOCUMENTAL.FASE 2: ANLISIS DEL CONTEXTO

OBJETIVO: 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). Este paso le permite al grupo de desarrollo disponer de una biblioteca organizada de documentos relativos al proyecto. Esta biblioteca ir creciendo a medida que avanza el proyecto. Durante esta fase estar formada solo por los documentos relativos al sistema por el plan del proyecto. Una vez constituida la biblioteca, el grupo se ocupa de estudiar la documentacin propia del sistema con miras a obtener una primera aproximacin al conocimiento del citado sistema y, sobre todo, al contexto que lo contiene Las actividades que el grupo de desarrollo debe llevar a efecto, durante este paso, son: 2.1.1.- RECOPILAR DOCUMENTOS.Con la colaboracin de los diferentes usuarios del sistema actual, el grupo recopila oda la documentacin posible concerniente directa o indirectamente a tal sistema. Algunos de estos documentos son los siguientes: manuales del sistema actual, informes, evaluaciones, auditorias, solicitudes de nuevos requerimientos, estatutos, reglamentos, decretos, normas y procedimientos, relacionados con el sistema ampliado u sistema actual de informacin. 2.1.2.- 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 siguiendo los lineamientos contenidos en el plan de documentacin del proyecto. Esta (s) personas) Ir designada como bibliotecarios) del proyecto.
4-14 4-15

PASOS:

2.1.3.- ESTUDIAR DOCUMENTOS.Despus de haberse organizado la biblioteca, el grupo se dedica a estudiar la documentacin all archivada. Con tal finalidad, el gerente programa diferentes sesiones o 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. 2.2.-

ANLISIS DEL CONTEXTO.-

Definir los objetivos del sistema de informacin. Identificar sus subsistemas. 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 a los usuarios del sistema y describir sus tareas. Describir la tecnologa que utiliza el sistema.

Este paso constituye un estudio formal de todo el sistema, con un nivel de detalle ms profundo que aquellos realizados durante la tase de definicin del proyecto. Su objetivo es permitirle al grupo de desarrollo conocer el sistema actual y su contexto; para luego modelarlo y sobre el modelo identificar las situaciones problemticas que el sistema presenta. A partir de ese modelo el grupo podr realizar con mayor facilidad la construccin de un modelo para el nuevo sistema de informacin, que mejore las deficiencias del actual y satisfaga -todos los requerimientos, tanto actuales como aquellos que se logren identificar. El modelo del sistema actual se elabora utilizando la tcnica conocida como Anlisis Estructurado de Sistemas o alguna similar. El modelo general, as construido, est integrado por dos sub-modelos ligeramente diferentes. El modelo fsico que describe las unidades, departamentos, grupos o personas que participan en el sistema de informacin y que ejecutan operaciones concretas e identificables y el modelo lgico que describe las funciones, procesos, actividades u operaciones que tienen lugar en el sistema. A continuacin se resean las actividades que debe llevar a la prctica el grupo desarrollo durante este segundo paso: 2.2.1.- ANALIZAR EL CONTEXTO DEL SISTEMA.Durante esta actividad el grupo de desarrollo estudia el sistema de actividades (sistema ampliado) dentro del cual est enmarcado el sistema de informacin. Ello debe llevar a: (1) determinar los objetivos de ese sistema, (2) definir su estructura (unidades funcionales de la organizacin que ejecutan las actividades pertinentes), (3) establecer sus procesos, esto es, las funciones o actividades que conforman el sistema y (4) determinar su comportamiento, el cual est fundamentado en el comportamiento de los individuos y grupos que participan en la realizacin de las respectivas actividades del sistema. 2.2.2.- ANALIZAR EL SISTEMA ACTUAL DE INFORMACIN.En esta actividad el grupo de desarrollo identifica los objetivos, estructura y procesos del sistema actual de informacin. Ello lleva a efectuar las siguientes tareas:
4-16

2.2.3.- CONSTRUIR EL MODELO DEL SISTEMA ACTUAL DE INFORMACION.A raz del anterior anlisis el grupo est preparado para representar al sistema actual mediante un modelo. Pata ello utiliza la tcnica de Anlisis Estructurado de Sistemas que le permite elaborar los modelos fsico y lgico del sistema de informacin. Las tareas que debe hacer el grupo durante esta actividad se dividen en: Construir los Diagramas de Flujo de Datos del Modelo Fsico. Construir los Diagramas de Flujo de Datos del Modelo Lgico. Elaborar el diccionario de Datos (vase planilla en el Anexo A). Describir cada proceso del Modelo Lgico hasta un nivel adecuado que facilite la comprensin del modelo (vase anexo B).

2.2.4.- IDENTIFICAR LAS SITUACIONES PROBLEMTICAS.El grupo de desarrollo presenta, a continuacin, el modelo del sistema actual a los usuarios para su validacin correspondiente. Junto con los usuarios, el grupo posteriormente identifica, analiza y resume las situaciones problemticas que posee el actual sistema de informacin. Algunos de los problemas tpicos asociados a sistemas de esta naturaleza, son los siguientes: psima calidad de la informacin suministrada, excesivos " cuellos de botellas " , elevados tiempos de respuesta, excesivos costos de operacin y mantenimiento, elevado nmero de requerimientos que no se satisfacen, fallas frecuentes, etc. 2.2.5.- 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 de informacin. Este informe es luego presentado a la Comisin de Planificacin para su correspondiente evaluacin.

4-17

2.2.6.- PLANIFICAR DETALLES DE LA PRXIMA FASEEsta actividad es bsicamente una actualizacin del plan del proyecto y un medio de comparar lo que se ha ejecutado contra lo que se haba planificado. Es realizada por el gerente del proyecto mediante el seguimiento de las tareas dadas a continuacin: Evaluar las actividades, el uso de recursos y los resultados obtenidos en la presente fase. Detallar las actividades y tareas de la prxima fase. Ajustar las estimaciones de recursos de la prxima fase. Re-programar tiempos y costos de la fase siguiente. Asignar tareas de la fase siguiente al grupo de desarrollo. Actualizar el plan del proyecto.

Descripcin de Procesos.- Permite explicar mediante diagramas algoritmos los procesos contenidos en los diferentes diagramas de flujo de datos (ver anexo B). Las siguientes referencias tratan sobre esta tcnica: (Demarca, 1979a) (Demarca, 1979b) (Gane y Sarson, 1979) 3.- OTRAS TCNICAS ALTERNATIVAS.- A continuacin se mencionan otras tcnicas que pueden utilizarse para el anlisis y especificacin funcional de un sistema de informacin. 3.1.- Tcnica de Jerarqua de Entrada-Proceso-Salida (HIPO).- Se explica en las siguientes referencias:

MTODOS Y TCNICAS EMPLEADAS EN ESTA FASE

1.- TCNICAS PARA LA TOMA DE DATOS.- dem a la fase 1. 2.- ANLISIS ESTRUCTURADO DE SISTEMAS.- Es una tcnica grfica, empleada para el anlisis de sistemas que permite describir y documentar las especificaciones funcionales de un sistema de informacin, esto es, las funciones que l realiza. Se caracteriza por lo siguiente: Es grfico: Las especificaciones se describen utilizando diagramas. Es participado: Con el fin de manejar la complejidad, el sistema se descompone en subsistamos y estos a su vez en procesos. Posteriormente, cada proceso se descompone de forma similar, hasta llegar a un nivel de detalle comprensible y consistente. Es jerrquico: Las especificaciones se describen en varios niveles de detalle "de arriba hacia abajo ", partiendo de un nivel general (nivel de subsistamos) hasta llegar a un nivel de detalle adecuado (nivel de procesos primitivos o de bajo nivel). El conjunto de diagramas que se originan configuran una jerarqua explicativa del sistema de informacin. Es fcil de mantener y actualizar.

(IBM Co., 1975) (Montilva, 1982a) (Stay, 1980) 3.2.- Tcnica de Anlisis y Diseo Estructurado (SADT).- Se explica en las referencias dadas a continuacin: (Ross, 1980) (Ross y Schoman, 1980) 4.- OTRAS REFERENCIAS RELACIONADAS CON ESTA FASE.(Alexander, 1974) (Jenkins, 1969) (Ossa, 1983) (Robertshaw y otros, 1978)

Las herramientas que la tcnica utiliza son: Los Diagramas de Flujo de Datos (similares a los utilizados aqu para explicar cada fase). El Diccionario de Datos.- Describe cada flujo de datos, estructura de datos, elemento de datos y archivo del sistema (ver anexo A).

4-18

4-19

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERA DEPARTAMENTO DE COMPUTACIN

* * * MEDSI * * * METODOLOGA ESTRUCTURADA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN

Con la finalidad de darle claridad al diagrama de este paso y de los restantes, se ha omitido el flujo del Plan del Proyecto de tales diagramas. Deber tenerse presente que el plan coordina cada paso y fase. La participacin de los usuarios durante esta fase es determinante y de hecho, obligatoria, por eso el gerente del proyecto debe incorporar un nmero representativo de usuarios del sistema al grupo de desarrollo y trabajar continuamente con el resto de ellos. Esta tase se inicia con la especificacin de los requerimientos de informacin que los usuarios del nuevo sistema desean (ejem. diagramas, reportes, consultas interjectivas, etc.) El resultado de este paso lo constituye el Libro de Requerimientos que es utilizado como documento de entrada para realizar el siguiente paso, es decir, la especificacin funcional del sistema. Este ltimo permite identificar, definir y documentar las funciones que el nuevo sistema debe ejecutar, las cuales se representan mediante un modelo, denominado Modelo Lgico del Nuevo Sistema, que junto con la Lista de Restricciones y Atributos producida por el paso 3.3 conforman, la "Especificacin Funcional del Nuevo Sistema " . Para facilitar la determinacin de los requerimientos que el sistema debe satisfacer, estos se dividen en: Requerimientos de informacin Requerimientos funcionales Restricciones para el desarrollo y operacin Atributos del sistema

Versin: 1

Fecha: Noviembre 1983

Autor: J. Montilva C.

FASE 3: DEFINICIN DE REQUERIMIENTOS

OBJETIVOS: Definir los requerimientos de los usuarios y establecer las funciones, restricciones y atributos que el nuevo sistema de informacin debe satisfacer.

PASOS:

DESCRIPCIN DE PASOS: 3.1.- ESPECIFICACIN DE REQUERIMIENTOS DE INFORMACIN.Durante este paso el grupo de desarrollo se encarga de especificar junto con los usuarios del nuevo sistema las salidas (listados, grficos, diagramas, etc.), las entradas (para los distintos tipos: su formato, su medio, su volumen estimado, etc.), y las estructuras de datos necesarias (los registros lgicos que se necesitan y sus relaciones). Estos requerimientos de informacin se organizan posteriormente para conformar el Libro de Requerimientos. Las actividades que realiza el grupo. de desarrollo durante este paso son las siguientes: 3.1.1.- 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.
4-20 4-21

Estos requerimientos se pueden clasificar como sigue: 1. Requerimientos de salida.- Clasificados como reportes (listado, grfico o despliegue visual de informacin) y consultas interactivas. Para los reportes se debe especificar el tipo, su formato, medio, frecuencia y volumen; los elementos de datos que debe contener y quien los utiliza. Para las consultas interactivas se debe especificar las caractersticas de las consultas y del lenguaje de interrogacin que los usuarios desean. Requerimientos de entrada.- Correspondientes a la captura y registro de los eventos o transacciones del sistema y a los datos que alimentarn a la base de datos. Para cada tipo de entrada se debe especificar la fuente, los elementos de datos que contiene, el mtodo y medio de captura y los procedimientos y controles de edicin y validacin que sean necesarios. Requerimientos de almacenamiento.- Corresponden al almacenamiento de datos del sistema. Se debe identificar los registros lgicos necesarios, sus estructuras y las relaciones entre ellos, as como tambin, los medios de almacenamiento y los volmenes estimados.

de Sistemas, la cual permite construir el Modelo Lgico del Nuevo Sistema. Este modelo junto con la Lista de Restricciones y Atributos que se produce en el paso 3.3 se utilizan luego para ensamblar y producir la Especificacin Funcional del Nuevo Sistema el Informe del Nuevo Sistema. Durante este paso se llevan a cabo las siguientes actividades: 3.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 (ver paso 1.2). Utilizando el Informe del Sistema Actual, el grupo determina con los usuarios, aquellas funciones que deben continuar, las que se han de modificar o eliminar y las que se han de incorporar al nuevo sistema. La seccin 1.7 de este libro contiene una lista de las principales funciones que debe ejecutar cualquier sistema de informacin. Las caractersticas, detalles y funciones dependen, por supuesto, de las caractersticas del sistema de actividades al cual pertenece el sistema de informacin que se est especificando. 3.2.2.- CONSTRUCCIN DEL MODELO LGICO DEL NUEVO SISTEMA.Este modelo es construido utilizando la tcnica de Anlisis Estructurado de Sistemas y constituye un medio grfico de valioso apoyo descriptivo y documentado de cada una de las funciones que el sistema en desarrollo debe realizar. En esta actividad el grupo debe efectuar las siguientes tareas: Construir los Diagramas de Flujo de Datos del Nuevo Sistema (a partir de los diagramas del sistema actual, si existe)., Elaborar el nuevo Diccionario de Datos (modificando el anterior, si existe un sistema actual). Describir cada proceso de detalle (proceso primitivo) de los Diagramas de. Flujo de Datos.

2.

3.

Para llevar a cabo esta actividad el grupo debe realizar las siguientes tareas: Revisar los requerimientos de informacin del sistema actual a fin de seleccionar aquellos que estn vigentes. Realizar entrevistas con los usuarios y/o solicitar por escrito los nuevos requerimientos de informacin, documentndolos mediante el uso de una planilla diseada para tal fin.

3.1.2.- CONSTRUIR EL LIBRO DE REQUERIMIENTOS DE NFORMACIN. Este libro contiene una entrada (planilla) para cada requerimiento de informacin nuevo o viejo. Los requerimientos se agrupan en divisiones de acuerdo al tipo sealado en la actividad anterior. La divisin de requerimientos de salida se organiza por secciones. Cada seccin contiene los requerimientos de informacin (de salida) de una unidad funcional involucrada en el sistema. Para la recoleccin de estos requerimientos puede emplearse la planilla descrita en el anexo A. 3.2.- ESPECIFICACIN FUNCIONAL DEL NUEVO SISTEMA.Tomando como elementos de entrada el Informe del Sistema Actual y el Libro de Requerimientos, el grupo, a lo largo de este paso, especifica con los usuarios las funciones que el nuevo sistema de informacin debe realizar. Estas funciones se describen en forma documental y grfica utilizando la tcnica de Anlisis Estructurado

3.2.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. 3.2.4.- DISCUTIR EL INFORME DEL NUEVO SISTEMA.El gerente del proyecto presenta luego el informe a la Comisin de Planificacin para su discusin y debida aprobacin.

4-22

4-23

3.3.- ESPECIFICACIN DE RESTRICCIONES Y ATRIBUTOS.En este paso, el grupo de desarrollo establece junto con los usuarios las restricciones bajo las cuales se debe desarrollar y debe operar el sistema de informacin. As mismo, se establecen tambin, la interaccin que debe haber entre el hombre y el computador y los atributos de calidad que se le van a imponer al mencionado sistema de informacin. A continuacin se delinean las actividades que el grupo de desarrollo debe efectuar durante este paso: 3.3.1.- DETERMINAR RESTRICCIONES.Estas restricciones se pueden agrupar tal como se muestra a continuacin: - Econmicas: De qu cantidad de dinero se dispone para desarrollar el sistema y para mantenerlo operando? ? - Tcnicas: Qu equipo debe o puede utilizarse? Es posible adquirir equipo adicional? - De personal: De qu personal se dispone para operar y mantener el sistema? Cul es la formacin tcnica de los usuarios? - De tiempo: Cunto tiempo se dispone para desarrollar el sistema? Cul es la vida til estimada del sistema? - Legales: Qu polticas, reglamentos, normas, leyes, etc., tanto internas como externas deben acatarse para desarrollar, operar y mantener el sistema? 3.3.2.- DETERMINAR INTERACCIN HOMBRE-MAQUINA.Esta actividad es esencial para la especificacin y diseo del nuevo sistema de informacin; pues define la comunicacin que debe haber entre los usuarios y el computador, a travs del subsiste m programado. Algunas de las interrogantes que el grupo debe tratar de responder, sobre este punto son: Qu grado de interaccin hombre-mquina se desea? Qu tan fcil de usar debe ser el sistema? Qu tan fcil de entender debe ser el sistema?

Qu tiempo de respuesta se desea para cada funcin? Qu tipo y niveles de entrenamiento pueden tener los usuarios? Cul debera ser la accin y reaccin de los usuarios ante fallas del sistema? Cul debera ser la accin del sistema ante fallas o errores cometidos por los usuarios? 3.3.3.- DETERMINAR ATRIBUTOS DE CALIDAD.El grupo de desarrollo establece aqu, los atributos de calidad del nuevo sistema, de acuerdo a lo descrito en la seccin 3.6.3 del captulo 3. Entre las interrogantes que se deben responder para algunos de los atributos de calidad se destacan las siguientes: - Contabilidad: Qu probabilidad de falla es tolerable? Qu consecuencias origina una falla? Qu debe el usuario hacer ante una falla? Qu debe hacer el sistema ante una falla? Qu cantidad de datos se pueden perder en una falla sin que se degrade el sistema? Grado de Pruebas: Qu tan probado debe ser el sistema? En qu condiciones se deben realizarlas pruebas?

- Movilidad: Se desea implantar el sistema en diferentes equipos? Qu tan independiente del equipo debe ser el sistema programado? - Adaptabilidad: Qu facilidad de expansin, crecimiento, modificacin y mantenimiento debe tener el equipo? - Mantenimiento Qu costo y tiempo son aceptables para reparar requerido: una falla . o hacer un cambio? Quin va a realizar el mantenimiento? Qu debe hacerse mientras se presta mantenimiento? - Seguridad y Privacidad: Qu tan seguro debe ser el sistema ante el uso indebido, mal intencionado o no autorizado? Qu controles especiales de acceso deben existir? Qu tipo de respaldo debe existir para proteger a la base de datos ante fallas?

4-24

4-25

- Eficiencia y Cules son los tiempos de respuestas deseables? Rendimiento: Qu volmenes de procesamiento por unidad de tiempo se requieren? Qu medidas adicionales de rendimiento se van a utilizar? - Documentacin: Qu caractersticas especiales debe tener la documentacin del sistema? 3.3.4.- ELABORAR LA LISTA DE RESTRICCIONES Y ATRIBUTOS. 3.3.5.- PLANIFICAR DETALLES DE LA PRXIMA FASE.dem a la actividad 2.2.6.

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERA DEPARTAMENTO DE COMPUTACIN

* * * MEDSI * * * METODOLOGA ESTRUCTURADA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN

Versin: 1

Fecha: Noviembre 1983

Autor: J. Montilva C.

FASE 4: DISEO PRELIMINAR

OBJETIVO: Elaborar un diseo preliminar del sistema de informacin que satisfaga los requerimientos, restricciones y atributos establecidos en la fase 3. El diseo preliminar consta de un prototipo o modelo fsico general que delinea la interaccin hombre-mquina del sistema de informacin y describe, en forma general, sus procesos automatizados. PASOS:

MTODOS, TCNICAS Y HERRAMIENTAS USADAS EN ESTA FASE:

1.- ANLISIS ESTRUCTURADO DE SISTEMAS.- Ver referencias y descripcin al final de la fase 2. 2.- OTRAS TCNICAS ALTERNATIVAS: 2.1.- Tcnica HIPO: Vase final fase 2. 2.2.- S.A.D.T.: Vase final fase 2. 2.3.- PSL/PSA: Vase (Teichroew y Hershey, 1979). 2.4.- SREM: Vase (Alford, 1981). 3.- OTRAS REFERENCIAS RELACIONADAS CON ESTA FASE. (Carey, 1982) (Wasserman, 1980c, 1980d) (Distaso, 1980) (Davis, 1982) (Parker, 1982) (Poole y White, 1977) (Tsichritzis, 1977) (Yeh y Zave, 1980)

4-27 4-26

Las unidades involucradas proporcionan al grupo de desarrollo la configuracin y las especificaciones tcnicas de los equipos que se pueden utilizar para el desarrollo del sistema de informacin. El grupo estudia estas especificaciones y luego determina diferentes prototipos o modelos fsicos del sistema que puedan ser implantados y que satisfagan las especificaciones contenidas en la Especificacin Funcional del Nuevo Sistema. Si algunos de los prototipos requieren equipos o programas adicionales, entonces, se solicita una cotizacin de las configuraciones necesarias, a diferentes vendedores de equipos (paso 4.1). A continuacin, la Comisin de Planificacin evala los diferentes prototipos que le ha presentado el grupo de desarrollo y selecciona el ms adecuado de acuerdo al anlisis costo-beneficio que se anexa. Si el prototipo seleccionado requiere de equipos y/ programas complementarios, estos se piden a los vendedores que el Comit de Planificacin recomiende y siguiendo sus instrucciones (paso 4.2). Finalmente, el grupo de desarrollo refina los procesos automatizados del prototipo que se haya elegido y elabora el Informe del Diseo Preliminar.

(ejem. Compiladores, herramientas de programacin, sistema de manejo de bases de datos, etc.), para desarrollar el sistema. 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. 4.1.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 total o parcial. 4.1.3.- 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. 4.2.- 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. El resultado de este anlisis se presenta y discute con la Comisin de Planificacin, quien decide posteriormente el prototipo ms conveniente y d. las instrucciones necesarias para la adquisicin de la tecnologa que haga falta (si es necesario). Para seleccionar el prototipo final, el grupo de desarrollo debe llevar a cabo las siguientes actividades: 4.2.1.- REALIZAR UN ANLISIS COSTO-BENEFICIO.Para cada prototipo se determinan sus costos de desarrollo y operacin y se estiman los beneficios que puedan obtenerse. Se comparan los diferentes prototipos bajo un criterio econmico preestablecido. Los resultados obtenidos se resumen en un informe tcnico denominado Informe de Prototipos. 4.2.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 a la organizacin. Si el prototipo elegido requiere equipos y programas adicionales o totalmente diferentes a los existentes, entonces la Comisin determina los pasos necesarios y las responsabilidades para adquirir esa tecnologa.
4-29

DESCRIPCIN DE PASOS 4.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 determina para cada caso los equipos y programas de apoyo que sean necesarios; cules de ellos existen en la organizacin y estn disponibles; y cules se deberan adquirir. Se solicitan precios y especificaciones tcnicas de los equipos o programas, que hagan falta, a los diferentes vendedores del mercado. La definicin de prototipos est regida por la estructura o configuracin global del sistema de informacin, la cual fue seleccionada durante el paso 1.2 (Estudio de Factibilidad). 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 (ejem, procesamiento en lotes, en lnea o a tiempo real) y para la interaccin que existir entre el hombre y la mquina. Las actividades que el grupo debe realizar en este paso se resumen a continuacin: 4.1.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-mquina, esto es, indica qu procesos son manuales y cules automticos (este modelo tambin recibe el nombre de modelo fsico, aunque ello puede originar confusin con el modelo de entes fsicos, antes discutido). Para aquellos procesos que sean automticos se determina el equipo necesario y se especifica las caractersticas tcnicas deseadas, de igual modo se establecen los programas de apoyo que hagan falta
4-28

4.2.3.- ADQUIRIR TECNOLOGA NECESARIA.De ser necesario, el grupo de desarrollo, o en su defecto, el que designe la Comisin de Planificacin, se encarga de adquirir, instalar y probar el equipo y los programas que el prototipo seleccionado requiera para su desarrollo u operacin. 4.3.- REFINAMIENTO DEL PROTOTIPO SELECCIONADO.Finalmente, el grupo se dedica a refinar el prototipo escogido. Este refinamiento consiste en describir con mayor detalle aquellos procesos del prototipo que sean automticos, siguiendo la tcnica de Anlisis Estructurado de Sistemas. El modelo as obtenido, se somete a una revisin o inspeccin a fin de hallar inconsistencias o errores. Las actividades que el grupo debe llevar a efecto se dan a continuacin: 4.3.1.- REFINAR PROTOTIPO.Cada proceso automtico del prototipo se refina mediante la descomposicin funcional establecida por la tcnica AES. Cada proceso del ms bajo nivel debe describirse utilizando cualquiera 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. Los procedimientos automatizados para: (1) la activacin del subsistema programado, (2) el respaldo y recuperacin de la base de datos y (3) los mecanismos de seguridad del sistema deben, tambin, refinarse durante esta actividad. 4.3.2.- REVISAR PROTOTIPO.El modelo o prototipo obtenido en la actividad anterior se somete a una revisin estructurada o a una inspeccin de diseo. 4.3.3.- ELABORAR INFORME DEL DISE PRELIMINAR.Utilizando el prototipo se realiza un informe de esta fase, el cual es luego presentado a la Comisin de Planificacin para su discusin y aprobacin rutinaria. 4.3.4.- PLANIFICAR DETALLES DE LA PRXIMA FASE.dem a la actividad 2.2.6.

MTODOS, TCNICAS Y HERRAMIENTAS USADAS EN ESTA FASE:

1.- ANLISIS COSTO-BENEFICIO.- Vase fase 2. 2.- ANLISIS ESTRUCTURADO DE SISTEMAS.- Vase fase 3. 3.- ALGORITMOS ESTRUCTURADOS.- Tcnica que utiliza las estructuras de la Programacin Estructurada y un grupo selecto de palabras del lenguaje Espaol para describir los pasos necesarios para realizar una actividad o resolver un problema dado. Vanse las siguientes referencias: (Montilva, 1982b) (Anexo B) Una tcnica que puede ser utilizada en reemplazo de los Algoritmos Estructurados es el lenguaje PDL ("Program Design Language"), el cual es descrito en la referencia dada a continuacin: (Caine y Gordon, 1980)

4-30 4-31

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERA DEPARTAMENTO DE COMPUTACIN

* * * MEDSI * * * METODOLOGA ESTRUCTURADA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN

DESCRIPCIN DE PASOS: 5.1.- 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. Las actividades que el grupo debe ejecutar en el presente paso son: 5.1.1.- DISEAR EL DIALOGO HOMBRE-MAQUINA.Dependiendo del tipo de interaccin hombre-mquina seleccionada, en esta actividad se debe (1) determinar el medio de comunicacin (terminal, teleimpresor, lectora ptica, etc.), estableciendo adems, sus caractersticas, capacidades y especificaciones tcnicas que afecten el diseo de los programas; (2) determinar el tipo de dilogo hombremquina y disearlo completamente; y (3) describir la accin que debe realizar el computador ante cada comando o selector que d el usuario, esto es, describir los resultados o respuestas que deban producirse, la entrada adicional de datos que pueda originarse, los mensajes de error y precaucin que se deben producir ante errores del usuario o fallas del sistema y la asistencia que le debe dar el sistema al usuario. Durante este diseo el grupo debe establecer junto con el usuario el tipo de dilogo y sus elementos. Los dilogos interactivos que existen actualmente se pueden clasificar en los siguientes tipos: Seleccin Mltiple ("men"). Lenguaje de Comandos. Lenguaje de Consulta a la Base de Datos (propios de cada SMBD). Lenguaje Semi-natural. Dependiendo del tipo seleccionado, se deben determinar los elementos del dilogo, sus parmetros y las funciones que realizan. Si el dilogo es del tipo de seleccin mltiple, se deben disear las pantallas de seleccin; si es de comandos, consulta o semi-natural, se debe especificar la gramtica (sintaxis), la semntica y la pragmtica del lenguaje. 5.1.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. Para cada pantalla se debe disear tambin el registro de datos asociado, es decir, el que permite construir la pantalla.

Versin: 1

Fecha: Noviembre 1983

Autor: J. Montilva C.

FASE 5: DISEO DETALLADO

OBJETIVO: Elaborar un diseo detallado del sistema de informacin que muestre cmo se construirn el subsistema 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 regir las diferentes pruebas del sistema de informacin durante las fases de construccin, pruebas e implantacin. PASOS:

A partir del Informe del Diseo Preliminar, que contiene el prototipo, y de la Configuracin Tcnica del equipo que va a ser utilizado, el grupo de desarrollo inicia el diseo detallado del sistema de informacin. Para ello, debe realizar los pasos siguientes: (1) El diseo de las entradas y de las salidas del sistema, esto es, los detalles de la interaccin hombre-mquina; (2) El diseo del subsistema de datos, esto es, de la base de datos y los procedimientos que se requieren para crearla e inicializarla; (3) El diseo del subsistema programado, el cual debe mostrar la estructura de los programas del sistema, sus especificaciones y los procedimientos manuales que le dan vida al sistema de informacin. Las especificaciones producidas en los pasos 5.1, 5.2 y 5.3 se ensamblan junto con el prototipo para producir el paquete de diseo que el grupo utilizar para construir el sistema. Finalmente se elabora el plan de pruebas que describe las actividades, calendarios, procedimientos y tcnicas que se emplearn durante los diferentes pasos de pruebas del sistema. (Tanto los pasos 5.1 y 5.2, como los pasos 5.4 y 5.5 se pueden realizar en paralelo, respectivamente).
4-32

4-33

5.1.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. El diseo de los elementos descritos (dilogo hombre-mquina, pantallas de E, S y reportes) conforman la especificacin de entradas y salidas del subsistema programado. 5.2.-

5.2.2.- REALIZAR EL DISE FSICO DE LA BASE DE DATOS.-

Dependiendo del tipo y caractersticas del Sistema de Manejo de Bases de Datos (SMBD) que se haya dispuesto utilizar, el grupo traduce el modelo de datos en 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 utilizarn, en trminos del lenguaje de descripcin de datos del SMBD. Este diseo depende enteramente del SMBD seleccionado, por lo que el grupo debe seguir los lineamientos e indicaciones dadas en la documentacin del SMBD. 5.2.3.- DISEAR LOS PROGRAMAS DE INICIALIZACIN Y MANTENIMIENTO DE LA B.D.En esta actividad el grupo disea aquellos programas que no forman parte del subsistema programado y que permiten inicializar o " cargar" la base de datos con los datos provenientes de fuentes de volumen considerable, que difcilmente pudiesen almacenarse mediante el subsistema programado. 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. De igual manera, se disean los detalles de los procedimientos de respaldo y recuperacin de la base de datos. 5.3.-

DISEO DE DATOS.-

El diseo del subsistema de datos del sistema de informacin gira en torno a (1) el diseo de la (s) base (s) de datos necesaria (s) para almacenar los datos de dicho sistema y (2) el diseo de los programas que permitirn crear y "cargar" (inicializar) la(s) base(s) de datos. Para realizar este paso existe un amplio conjunto de metodologas que pueden ayudar al grupo a realizar un diseo eficiente y consistente de la base de datos (vase referencias al final de la fase). A continuacin se describen, en forma general, las actividades que debe realizar el grupo de desarrollo durante el diseo de datos. 5.2.1.- REALIZAR EL DISEO LGICO DE LA BASE DE DATOS.En este proceso de diseo se elabora un modelo de datos que represente a las entidades (objetos y eventos), sus atributos (propiedades o caractersticas de cada entidad), y las relaciones (asociaciones) 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 representan y los atributos (elementos de datos) que posean. Establecer las relaciones que existan entre las diferentes entidades y construir el modelo entidad-relacin correspondiente. Si el SMBD que se vaya a utilizar manipula bases 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. Si la respuesta es negativa, se debe modificar el modelo a fin de que incorpore las entidades y atributos necesarios para satisfacer tales requerimientos.

DISEO DE PROGRAMAS Y PROCEDIMIENTOS.-

Luego que se ha elaborado el diseo de E/S y el de datos, el grupo de desarrollo puede 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; pues dependiendo de estos elementos el grupo disea una estructura que bien podra estar ubicada dentro de uno de los enfoques siguientes: Un solo programa Un conjunto de varios programas separados y ejecutados separadamente. Un conjunto de varios programas interrelacionados (mediante un len-guaje de control de tareas, por ejemplo).

En cada caso, la estructura de un programa est compuesta por mdulos que configuran una jerarqua, en la que los mdulos de nivel superior actan como controladores del flujo del programa o ejecutan las funciones generales y los mdulos de bajo nivel ejecutan las funciones de detalle. Se establece de este modo una estructura jerrquica modular, de la cual se emprende el diseo de cada mdulo, diseo ste que se concreta en lo que denominaremos como especificacin de programa.

4-34

4-35

En este paso se disea tambin toda la documentacin y procedimientos manuales que el sistema de informacin demande. Para llevar a cabo este paso el grupo de desarrollo efecta las actividades reseadas a continuacin: 5.3.1.- DISEAR LA ESTRUCTURA DEL SUBSISTEMA PROGRAMADO.El subsistema programado se disea como una estructura jerrquica compuesta por uno o ms programas, cada uno de estos se compone, a su vez, de mdulos. Un mdulo se define como una unidad de programa que se caracteriza por lo siguiente: Posee un nombre propio y nico. Ejecuta una funcin claramente especificable. Puede compilarse y catalogarse en forma separada. Puede definir y mantener un conjunto propio de variables locales. Se llama o invoca desde otro mdulo. Son ejemplos de mdulos: las subrutinas de FORTRAN, los procedimientos de ALGOL, PASCAL y PL/I y los prrafos y secciones de COBOL (aunque no cumplen con todos los puntos mencionados). Para el diseo de la estructura el grupo dispone un amplio conjunto de tcnicas, entre las cuales se destaca el Diseo Estructurado (vase referencias al final de la fase). El objetivo de la citada tcnica es disear un sistema programado como una estructura jerrquica compuesta de mdulos de funcin simple relativamente independientes. El proceso de diseo se basa en el principio de Descomposicin Funcional, que consiste en dividir, de acuerdo a la especificacin funcional, el sistema programado en subsistemas o programas, cada uno de los cuales se divide luego en piezas funcionales (mdulos). Este proceso se repite hasta que se logra alcanzar un nivel funcional detallado, en el que cada mdulo ejecuta una funcin bsica. El rbol o red modular, as obtenida, constituye la estructura del subsistema programado.

5.3.2.- DISEAR CADA MDULO 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 mdulo, esto es, describir los pasos necesarios para llevar a cabo la funcin asignada al mdulo. El nivel de detalle descriptivo debe ser t al que le permita a un programador acometer la codificacin del mdulo, con relativa facilidad y sin ambigedad alguna. La lgica de un mdulo se puede representar mediante el uso de algoritmos o diagramas de flujo. La tcnica que hemos denominado Algoritmos Estructurados (vase referencias al final de la fase) puede ser utilizada para este fin, con la ventaja de que su aplicacin produce un diseo modular completamente estructurado, ya que est basada en los principios de la Programacin Estructurada. El algoritmo o diagrama de flujo del mdulo, en s, no es suficiente como para que un programador empiece su codificacin; pues se requiere de una informacin adicional sobre las caractersticas del mdulo, 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 (vase planilla correspondiente en el Anexo A). El diseo de cada mdulo se especifica en una planilla de este tipo. 5.3.3.DISEAR LA MANUALES.DOCUMENTACIN Y LOS PROCEDIMIENTOS

En esta actividad el grupo se ocupa de determinar el formato y contenido de cada uno de los manuales que forman la documentacin del sistema de informacin (ejem. manual del usuario, manual del sistema, etc.), de acuerdo a lo que se ha establecido en el plan de documentacin. De igual modo se disean los formatos, formularios, instructivos, planillas y dems procedimientos manuales, que se mencionan en el prototipo del sistema, y que se requieren como elementos de los flujos de datos de los procesos manuales del sistema de informacin. La estructura del sistema programado, las especificaciones de programa asociadas a cada mdulo 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. 5.4.-

ENSAMBLAJE DEL PAQUETE DE DISEO.-

Este paso se inicia desde la finalizacin de los pasos 5.1, 5.2 y 5.3 y se basa en revisar y ensamblar el conjunto de especificaciones de diseo producidas en los citados pasos, con el se deriva de El diseo se inicia con la determinacin de una estructura jerrquica inicial para el subsistema programado. Esta estructurapropsito de garantizar la consistencia, calidad y exactitud Anlisis de integrar lo que hemos denominado como paquete de los procesos automatizados que se han identificado en el prototipo del sistema, mediante la aplicacin del del diseo e Transformaciones diseo. Este documento es la esencia para la construccin del sistema; pues y el Anlisis de Transacciones; estrategias propias de la tcnica Diseo Estructurado. La utilizacin de las estrategias mencionadas establece "qu" y "cmo" la estructura produce una o ms sub-estructuras jerrquicas (programas) relacionadas o relativamente independientes, las cuales definendeben hacerse las cosas durante esa fase. inicial del subsistema programado. Cada sub-estructura es, luego, descompuesta en mdulos, sucesivas veces, hasta llegar a un nivel en el cual cada mdulo de nivel inferior ejecuta una funcin simple, que puede ser especificada mediante un algoritmo o diagrama de flujo con facilidad. Se obtiene, de este modo, la estructura del subsistema programado.
4-36 4-37

5.4.1.- REALIZAR UNA REVISIN ESTRUCTURADA DEL DISEO.-

5.5.-

PLANIFICACIN DE LAS PRUEBAS.-

Para cada una de las especificaciones producidas en los pasos 5.1, 5.2 y 5.3 se realiza una revisin estructurada (o una inspeccin de diseo) siguiendo los lineamientos dados, para estas tcnicas, en la seccin 3.6.3 del captulo 3. Los objetivos de estas revisiones son: (1) determinar las inconsistencias del diseo; (2) determinar las fallas y errores cometidos en las diferentes especificaciones; (3) medir y corregir las desviaciones del diseo con respecto a las normas y procedimientos de diseo establecidos en el plan metodolgico; (4) asegurar que las restricciones y atributos establecidos se satisfagan plenamente con el diseo elaborado; y (5) asegurar que cada requerimiento contenido en el Libro de Requerimientos y cada especificacin funcional del prototipo se cubran o satisfagan con el diseo producido. Para facilitar este ltimo objetivo, la Matriz de Seguimiento de Requerimientos, descrita en la seccin 3.6.1 del captulo 3, es una herramienta muy valiosa que le permite al grupo llevar un seguimiento de cada requerimiento durante el diseo, construccin y pruebas del sistema. Cualquier inconsistencia, talla o error detectado durante las revisiones debe ser corregido antes de iniciar la actividad siguiente. 5.4.2.- 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 conducirla construccin del sistema. Por consiguiente, contiene: (1) el prototipo del sistema; (2) la configuracin y documentacin del equipo que se va a emplear; (3) las especificaciones de entrada y salida; (4) la especificacin del subsistema programado; (5) la especificacin del subsistema de datos y (6) cualquier otro material que se juzgue necesario. El gerente del proyecto y el bibliotecario pueden emplear desde esta actividad, si as lo desean, la Carpeta de Desarrollo de Unidades (DF), descrita en la seccin 3.6.1 del captulo 3, con la finalidad de ensamblar en forma ordenada y modular las especificaciones tanto funcionales como las de diseo. Luego que se ha ensamblado el paquete de diseo, ste se almacena en la biblioteca del proyecto para su posterior utilizacin durante las fases restantes. 5.4.3.- ELABORAR Y DISCUTIR EL INFORME DEL DISE 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 tiempo s de desarrollo, que el diseo elaborado involucra. Este informe se presenta luego a la Comisin de Planificacin, quien aprueba, rechaza o recomienda modificar el diseo detallado del sistema de informacin.

A pesar de que se ha identificado la fase 7 de esta metodologa como la fase de pruebas, las actividades concernientes a sta no se realizan en conjunto bajo ese nombre, sino que se dividen y toman lugar a lo largo de diferentes tases de la metodologa. Las razn de ello es fundamentalmente estratgica, pues de realizarse todas las actividades durante la fase de pruebas, el tiempo o duracin total del proyecto se extendera considerablemente; por otro lado, es evidente que muchas de las actividades de prueba se pueden realizar en paralelo con actividades de tases tales como las de diseo y construccin del sistema. Bajo este criterio, podemos dividir las actividades generales de las pruebas en: 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 a lo ancho de las fases de construccin y pruebas propiamente dicha. 5.5.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. Este plan es un documento que gua el desarrollo de las pruebas en los distintos niveles del sistema de informacin. En l se identifican: (1) las diferentes pruebas que han de realizarse; (2) los responsables de disearlas, construirlas y ejecutarlas; (3) la programacin de tiempos, costos y recursos necesarios para llevarlas a cabo; (4) las herramientas, mtodos, tcnicas y procedimientos que se deben emplear en las diferentes actividades de prueba; (5) los criterios de xito de cada prueba; y (6) informacin adicional que se necesite para efectuar tales pruebas.

El plan de pruebas se puede organizar en secciones, tal como se describe a continuacin:

1 OBJETIVOS: Identifica las metas y objetivos que se persiguen en cada uno de los niveles y actividades generales de las pruebas. 2.- CALENDARIO DE PRUEBAS.- Identifica cada elemento de prueba y las diferentes pruebas que deben efectuarse; los responsables de las actividades de diseo, construccin y ejecucin; y la fecha de inicio y terminacin de cada actividad de Prueba. Un elemento de prueba es un componente del sistema de informacin que debe someterse a prueba. Generalmente, estos componentes se clasifican en:

4-38 4-39

UNIDADES.- Una unidades un mdulo de la estructura del subsistema programado. SUBSISTEMA.- Un subsistema de prueba es un grupo de mdulos interrelacionados que ejecutan, en conjunto, una funcin detallada o general del subsistema programado. SISTEMA.- El sistema de prueba lo constituye el sistema de informacin en su totalidad.

3. HERRAMIENTAS, TCNICAS Y MTODOS.- En esta seccin se identifican y describen las herramientas automatizadas que se desean usar en las diferentes actividades de pruebas (ejem. generadores de datos, depuradores, etc.). Se identifican y describen, tambin, los mtodos y tcnicas de pruebas que se pretendan utilizar para la realizacin de las diferentes actividades (ejem. pruebas de arriba-hacia-abajo, pruebas de abajo-hacia-arriba, etc.). 4. SEGUIMIENTO DE REQUERIMIENTOS.- En esta seccin se actualiza la matriz de seguimiento de requerimientos, con el fin de verificar que cada requerimiento sea cubierto por al menos una prueba. 5. PROCEDIMIENTOS.- Permite identificar y describir los diferentes procedimientos (instructivos, planillas, etc.), que se utilizarn para disear y construir las pruebas y para reportar el progreso de su ejecucin y de los resultados obtenidos. 6. NORMAS.- Aqu se mencionan las normas que se deben seguir para el diseo y construccin de cada especificacin de prueba. 7. CRITERIOS DE XITO.- Para las diferentes pruebas que se vayan a efectuar, se identifican los criterios que prevalecern para determinar si una prueba ha sido exitosa o no. 5.5.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 proyectos 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 prueba restantes. Este grupo se denomina Grupo de Pruebas. Para finalizar esta actividad, el gerente del proyecto presenta el plan de pruebas a la Comisin de Planificacin. 5.5.3.- PLANIFICAR DETALLES DE LA PRXIMA FASE.dem a la actividad 2.2.6.

Las diferentes pruebas que se deben realizar se agrupan o clasifican del siguiente modo: PRUEBAS DE UNIDADES.- Permiten probar y depurar 2 las unidades o mdulos del subsistema programado. PRUEBAS DE SUBSISTEMA.- Permiten probar y depurar cada subsistema de prueba, esto es, cada grupo funcional de mdulos del subsistema programado. El objetivo de esta prueba es detectar y corregir los errores presentes en: (1) la integracin de mdulos en subsistema funcionales y (2) la realizacin de las diferentes funciones que el subsistema programado debe cumplir. Las pruebas de subsistema se pueden realizar jerrquicamente probando primero las funciones ms detalladas o de ms bajo nivel en la escultura (ejem. elimine un registro del archivo XYZ), luego se prueban las funciones intermedias de la jerarqua (ejem. ejecute el comando AYUDA) y finalmente todo el subsistema programado. Esta manera de probar se denomina " de abajo-hacia-arriba " . PRUEBA DEL SISTEMA.- Esta es la prueba de todo el sistema de informacin, que consiste en probar y depurar la integracin de los diferentes componentes del sistema (subsistema: equipo, programado, de personal y de datos). Su objetivo es encontrar las discrepancias que existan entre el sistema construido y los objetivos, requerimientos, restricciones y atributos inicialmente establecidos. Esta prueba se realiza en un ambiente tan cercano y similar, como sea posible, al ambiente real del sistema. PRUEBA DE ACEPTACIN.- Es la prueba final del sistema y es realizada ante la presencia del Comit de Planificacin y los directivos de las unidades involucradas. Se realiza en el ambiente real del sistema de informacin, con el propsito de demostrar que el sistema desarrollado satisface las necesidades que motivaron la realizacin del proyecto.

MTODOS, TCNICAS Y HERRAMIENTAS UTILIZADAS EN ESTA FASE:

Los mtodos y tcnicas que existen para el desarrollo de esta fase son muy numerosos. A continuacin, se dan las referencias bibliogrficas para algunos de sus Pasos; en la mayora de estas referencias se describen una o ms tcnicas alternativas a las que se sugiere utilizar en esta metodologa. 1.- EN EL DISE DE ENTRADAS Y SALIDAS.- Se recomienda la lectura de

2 . - Estos trminos, si bien estn muy relacionados, son diferentes. Probar es detectar la existencia de un error, mientras que, depurar es localizar el error detectado, determinar su naturaleza y corregirlo

4-41

4-40

las siguientes referencias: (Carey, 1982) (Ledgard, 1980) (Wasserman, 1980c, 1980d) (CODASYL, 1978) (Senn, 1978, pp. 481-487)

2.- EN EL DISEO DE DATOS.- Para este paso las siguientes referencias son d particular inters: (AUERBACH, 1981) (Guttag, 1980) (Martin, 1977, 1983) (Smith y Smith, 1980) (Wasserman, 1980b) (Date, 1981) (Inmon, 1981) (Ng, 1981) (Ullman, 1980) (Zaniolo y Melkanoff, 1982)

3.- EN EL DISEO DE PROGRAMAS.- Para este paso el nmero de mtodos tcnicas que existen es amplio. Para esta metodologa, sin embargo, se recomienda utilizar las siguientes: 3.1.- DISEO ESTRUCTURADO.- Descrito en las siguientes referencias: (Montilva, 1982a) (Stevens y otros, 1980) (Stevens, 1981) (Yourdon y Constantine, 1978) 3.2.- ALGORITMOS ESTRUCTURADOS.- Vanse las referencias siguientes (Montilva, 1982b) (Anexo B de este libro)

Otras referencias de inters para este paso son las siguientes: (Caine y Gordon, 1980) (Pez, 1980) (IBM Co., 1975) (Tumer, 1980) (Mitchell, 1981) (Dennis, 1977) (Peters, 1980) (Linger, 1980) (DeMarco, 1979b) (Pamas, 1979, 1980) Qackson, 1975, 1980) 4.- EN EL PLAN DE PRUEBAS.- Para la elaboracin del plan de pruebas s recomienda la lectura de las siguientes referencias: (Adrion y otros, 1982) (Jensen y Tonies, 1979, pp. 340(Metzger, 1978, pp. 183-185) (Myers, G., 1976, pp. 242-244; 343)

4-42