jonas montilva capitulo 04

CAPÍTIULO 4

METODOLOGÍA Y TECNICAS PARA EL DESARROLLO DE SISTEMAS DE

INFORMACIÓN

Jonás Montilva C. ANÁLISIS Y DISEÑO 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 información depende de tres elementos claves:

1.- La Administración del Proyecto. 2.- El Seguimiento de una Metodología. 3.- La Aplicación de Técnicas y Herramientas.

La administración del proyecto es un conjunto complejo de actividades cuya

responsabilidad recae en el gerente del proyecto. En el capítulo 3 describimos las cinco funciones básicas que debe ejecutar un gerente para garantizar una buena y eficiente administración de un proyecto de esta naturaleza.

La metodología y las técnicas-herramientas están dirigidas a todo el grupo de desarrollo, esto es, al grupo que llevará adelante el proyecto bajo la coordinación del gerente. En este capítulo nos dedicaremos a estudiar estos dos elementos claves. Dentro de este orden de ideas, proponemos una metodología, a la que identificaremos bajo el nombre de MEDSI {Metodología Estructurada para el Desarrollo de Sistemas de Información). A medida que se vaya describiendo la metodología, iremos indicando y explicando, donde sea apropiado, las técnicas y herramientas que el grupo debe utilizar para llevar a cabo una ejecución eficiente y eficaz de las diferentes actividades y tareas que componen un proyecto de este tipo.

MEDSI METODOLOGÍA ESTRUCTURADA PARA EL DESARROLLO

DE SISTEMAS DE INFORMACIÓN

MEDSI es una metodología estructurada para desarrollar sistemas de información en y para organizaciones de cualquier tipo. Ha sido probada con éxito en el desarrollo de diferentes sistemas de información para la administración de la Universidad de Los Andes en Mérida, entre los que se destacan los siguientes:

• Sistema de Información para el Personal Administrativo, Técnico y de

Servicio. • Sistema de Información de Proveedores.

4-1

• Sistema de Asignación de Salones para una Facultad.

En la actualidad (1984), la metodología está siendo utilizada rigurosamente en los siguientes proyectos para la misma universidad:

Sistema de Información para el Personal Docente y de Investigación.

• Sistema de Información de la Fundación Universidad de Los Andes.

Entre las características resaltantes de esta metodología podemos señalar las siguientes:

1.- ES ESTRUCTURADA.- Esta característica se debe a dos razones esenciales: (a) Utiliza diferentes métodos y técnicas estructuradas, que son propias de la Ingeniería de la Programación y que han demostrado ser las más eficientes y eficaces para el desarrollo de sistemas programados (b) Guía 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 información.

2.- ES COMPLETA.- Cubre todas las distintas fases del ciclo de desarrollo de un sistema de información, desde la definición del proyecto hasta la implantación del sistema en la organización. Guía al grupo de desarrollo, a través de las fases, a un nivel bastante detallado; explicando las actividades que deben hacerse y en la mayoría de casos, enumerando las tareas específicas que los miembros del grupo deben efectuar.

3.- ES PARTICIONADA.- A fin de manipular mejor la complejidad inherente a un proyecto de este tipo, la metodología se divide en fases (al igual que el ciclo de desarrollo descrito en el capítulo 2). Cada una de estas fases se dividen en pasos, los cuales están orientados a algún tipo de tópico, aspecto o elemento del sistema de información. 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 descompo-nen en tareas específicas, las cuales deben ser ejecutadas por un miembro o sub-grupo en un plazo o período 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 aplicación de alguna técnica.

4.- ES MODIFICABLE Y ADAPTABLE.- El grupo de desarrollo puede modificar fácilmente la metodología, bien para introducir nuevos elemen-

tos como para eliminar algunos. De igual modo, puede adaptarla a las condiciones, exigencias y características de la organización donde se utilice o a cualquier otro tipo de proyecto de sistemas de información.

NOTA EXPLICATIVA SOBRE LOS DIAGRAMAS:

Los diagramas utilizados en esta metodología para explicar las diferentes fases están basados en la técnica de Análisis Estructurado de Sistemas, v corresponden a lo que, en términos de esa técnica, recibe el nombre de Diagramas 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 utilizamos para representar una fase o paso de la metodología). Representa un canal de datos por donde fluyen datos, en la forma de documentos, informes, etc. Identifican a elementos externos que reciben información o envían datos. Identifican a un medio de almacenamiento de datos, manual o automático.

Una característica 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 estática los diferentes procesos de una función 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 rápidamente todos los procesos y sus interrelaciones mediante flujos de datos.

ALGUNAS CONSIDERACIONES SOBRE MEDSI Tal como se presenta aquí, MEDSI está orientada a proyectos medianos y grandes que ameriten la integración de grupos de desarrollo conformados por 3 o más personas y

que puedan requerir, para su desarrollo, varios meses. Es evidente que, para un proyecto pequeño, el seguimiento estricto de cada fase, paso y actividad aquí

presentada, lejos de facilitar su desarrollo, lo entorpecería. 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 metodología a su proyecto.

1.-

4-24-2

2.- Al igual que toda metodología, MEDSI es una guía 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 automáticamente un sistema de información.

Cada proyecto tendrá sus propias características, al igual que cada grupo de desarrollo y el ambiente que lo rodea, por lo que la revisión y modificación de las fases, pasos o actividades de la metodología, antes y durante el desarrollo del sistema, es un proceso propio de ella, que deberá regirse fundamentalmente por las normas y procedimientos que la organización haya establecido para el desarrollo de sus sistemas de información. Por ello es indispensable que un grupo de la organización, como por ejemplo la Comisión de Planificación de S.I., determine cuales de las fases, pasos o actividades tienen un carácter obligatorio, cuales podrán ser modificadas y cuales omitidas en un momento dado. Así mismo, conviene determinar que técnicas 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 documentación de los distintos sistemas de la organización.

3.- 4-4El lector notará que algunas actividades se repiten en diferentes pasos y

fases de la metodología. Por ejemplo, la definición de requerimientos se repite en los pasos 1.1, 1.2 de la fase de Definición del Proyecto y, por supuesto, en los pasos 3.1, 3.2 y 3.3 de la fase de Definición de Requerimientos (algo similar ocurre, también, con el análisis 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 metodología se define como estructurada; pues usa el enfoque estructurado.

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE COMPUTACIÓN

* * * MEDSI * * *METODOLOGÍA ESTRUCTURADA PARA EL

DESARROLLO DE SISTEMAS DE INFORMACIÓN

Versión: 1

FASES DE LA

4-54-4

Fecha: Noviembre Autor: J. Montilva C.

DESCRIPCIÓN GENERAL DE LAS FASES: FASE l: A raíz del surgimiento de nuevas necesidades y requerimientos, la

organización designa a un gerente de proyecto cuya primera misión es definir el proyecto, esto es, justificar el desarrollo de un nuevo sistema de información, 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 información. En esta fase el gerente organiza el grupo de desarrollo, iniciando de inmediato un análisis del contexto en el cual se va a ubicar el sistema. Para ello se recaba toda la documentación relacionada, se analiza el ambiente, la estructura y los procesos del sistema ampliado (marco del sistema de información). Si existe un sistema actual de información, éste se analiza a fin de detectar sus deficiencias, fallas y problemas mediante la construcción de un modelo.

FASE 3: Se determina, junto con los usuarios, los requerimientos que debe satisfacer el nuevo sistema de información. Así mismo, se establecen las funciones, restricciones y atributos de calidad del sistema, los cuales se ensamblan en la Especificación Funcional y se resumen en un informe del Nuevo Sistema.

FASE 4. Se producen diferentes prototipos o diseños preliminares del sistema que satisfagan la especificación funcional, para luego seleccionar el más conveniente a la organización. Este prototipo se describe en el informe del Diseño Preliminar. La Configuración Técnica describe las características del equipo y los programas de apoyo requeridos por el prototipo.

FASE 5: Se realiza un diseño detallado de los diferentes componentes del sistema de información tomando como referencia el prototipo del sistema; este diseño se ensambla en el paquete de diseño. Adicionalmente, se elabora el Plan de Pruebas de l los diferentes componentes del sistema.

FASE 6: Se construye el sistema de acuerdo a lo especificado en el paquete de diseño 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 implantación del sistema.

FASE 8: Se implanta el sistema de información mediante el adiestramiento de los usuarios, la conversión del sistema existente al recientemente construido (puesta operación) y la entonación inicial del sistema de información. Finalmente, se entrega sistema a los usuarios y al grupo de mantenimiento junto con el Informe Final del proyecto.

FASE 1: DEFINICIÓN DEL PROYECTO

OBJETIVOS: Determinar la factibilidad de desarrollar un nuevo sistema de información 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:



* * * MEDSI * * * METODOLOGÍA ESTRUCTURADA PARA EL


Versión: 1 Fecha: Noviembre 1983 Autor: J. Montilva C.

4-6 4-7

La definición del proyecto se inicia luego que las unidades interesadas solicitan a la unidad ejecutora de sistemas de información de la organización 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 técnica, económica 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 precisión, que el estudio de factibilidad, los costos, la duración y los recursos necesarios para emprender el provecto de desarrollo de un nuevo sistema de información. Las unidades involucradas pueden decidir la paralización del mencionado proyecto durante la ejecución de cualquier paso o actividad, para ello se asigna a la Comisión de Planificación para que realice la, correspondiente evaluación del proyecto a lo largo del ciclo de desarrollo. DESCRIPCIÓN DE PASO: 1.1.- ESTUDIÓ PRELIMINAR DEL PROYECTO.-

Este estudio demuestra de manera general si se justifica o no desarrollar un sistema de información 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 información. 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 organización 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 sistema nuevo. Algunas 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 debería ejecutar un nuevo sistema? ¿Qué tipo de información debería producirse? ¿Qué características debería tener la información 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 documentación archivada.

1.1.3.- ELABORAR EL INFORME PRELIMINAR.-

A partir del análisis 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 información.

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 decisión adoptada durante la discusión 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 planificación:

• 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 información, el gerente debe estudiar, junto con el grupo seleccionado para este paso, la factibilidad técnica, económica y psicosocial de diferentes alternativas que puedan constituir soluciones aceptables al problema actual de información. 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 información, el grupo debe evaluar. en este momento, dicho sistema. Esta evaluación tiene un carácter general, aunque e-más detallada que el diagnóstico de la actividad 1.1.2. Las tareas que debe realizar el grupo durante esta actividad se mencionan a continuación:

• Analizar el ambiente del sistema actual'. • Definir sus objetivos. • Determinar el flujo de información e identificar las entradas, procesos. salidas y

archivos del sistema. • Determinar los principales problemas y características de las entradas, procesos,

salidas y archivos. • Establecer los costos de operación, el grado de satisfacción de lo, requerimientos de

los usuarios, los atributos de calidad del sistema y sus características generales.

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 realización de las tareas siguientes:

• Identificar los objetivos del nuevo sistema. • Establecer los requerimientos de información (entradas, salidas y archivos). • Establecer los requerimientos de procesamiento (funciones). Establecer restricciones

y atributos preliminares. 1 . - Se entiende como ambiente del sistema o sistema ampliado al sistema de actividades de la organización (Ejem. sistema: financiero. contable, de personal, etc.), al cual le presta apoyo el sistema de información objeto de estudio.

1.2.3- FORMULAR SISTEMAS ALTERNATIVOS.-

El grupo identifica, en esta actividad, diferentes configuraciones para el sistema de información (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 características principales. Determinar que requerimientos no

se satisfacen total o parcialmente. • Definir el grado de automatización, 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 TÉCNICA.-

Para cada sistema alternativo se debe establecer su factibilidad técnica, ello debe responder a dos interrogantes: ¿es posible desarrollar el sistema propuesto con la tecnología actual o existente?; y si es posible, ¿qué tecnología adicional debe adquirir la organización? Las tareas que se deben efectuar son:

• Evaluar la tecnología (equipos y programas) de que dispone la organi-zación.

• Para cada sistema alternativo: • Determinar la tecnología demandada. • Determinar la tecnología adicional que debe adquirirse.

1.2.5.- DETERMINAR FACTIBILIDAD ECONÓMICA.- En esta actividad el grupo debe realizar un Análisis Costo-Beneficio que permita identificar y medir los costos de desarrollo y operación y los beneficios que obtiene la organización de cada sistema alternativo; para luego comparar las diferentes alternativas bajo un criterio económico. Deben, también, estimarse los tiempos de desarrollo de cada sistema propuesto a fin de medir la factibilidad económica de cada uno de ellos.

1.2.6. - DETERMINAR FACTIBILIDAD PSICOSOCIAL.-

La implantación de un sistema de información automatizado en cualquier organización crea un impacto social, que puede ocasionar una aceptación o el rechazo total al cambio tecnológico que se pretende introducir. El grupo, por lo tanto, debe predecir o estimar para cada alternativa el impacto social que ellas puedan originar dentro de la organización.

4-114-10

1.2.7.- ELABORAR EL INFORME DE FACTIBILIDAD.-

Este informe describe cada sistema alternativo y resume su factibilidad técnica, económica y psicosocial. 1.2.8.- DISCUTIR EL INFORME DE FACTIBILIDAD.-

El gerente del proyecto presenta el informe a la Comisión de Planificación, quienes junto con los directivos de las unidades involucradas discuten la factibilidad de cada alternativa y seleccionan la más conveniente a los intereses de la organización. El proyecto puede ser paralizado debido a que no existan alternativas factibles o convenientes a la modificación. 1.3.- PLANIFICACIÓN DEL PROYECTO.-

A partir de la decisión de continuar con el proyecto y de la selección de un enfoque alternativo para el nuevo sistema de información, 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 guíe el desarrollo de proyecto y que denominaremos el PLAN DEL PROYECTO. La elaboración de este documento se describe con detalle en el capítulo 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 planificación se muestran a continuación:

1.3.1.- ELABORAR EL PLAN GENERAL. 1.3.2.- ELABORAR EL PLAN GENERAL DE FASES. 1.3 .3.- ELABORAR EL PLAN GENERAL DE ORGANIZACIÓN. 1 .3 .4 . ELABORAR EL PLAN GENERAL METODOLÓGICO. 1.3.5 . - ELABORAR EL PLAN GENERAL DE ADMINISTRACIÓN DE

LA CONFIGURACIÓN. 1.3.6.- ELABORAR EL PLAN GENERAL DE ADMINISTRACIÓN

DE RECURSOS. 1 .3 .7 . ELABORAR EL PLAN GENERAL DE DOCUMENTACIÓN. 1 .3 .8 . ELABORAR EL PLAN GENERAL CALENDARIO DE EVENTOS.

1.3.10.- REVISAR EL PLAN DEL PROYECTO2.-

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 discusión el plan del proyecto ante la Comisión de Planificación, que luego recomienda su continuación, modificación o suspensión.

MÉTODOS Y TÉCNICAS EMPLEADAS EN ESTA FASE:

1.- TÉCNICAS PARA LA TOMA DE DATOS.- Entre estas técnicas se destacan las siguientes: entrevistas, cuestionarios, observación directa, muestreo y tablas de decisión. Lis siguientes referencias bibliográficas explican adecuadamente estas técnicas:

(BURCH Y STRATER, 1974) (SENN, 1978)

2.- ANÁLISIS COSTO-BENEFICIO.- Esta técnica se describe en las siguientes

referencias:

(KING Y SCHREMS, 1978) (ROBERSHAW y otros, 1978)

3.- TÉCNICAS DE PLANIFICACIÓN Y CONTROL DE PROYECTOS.- Véase

sección 3.2, capítulo 3.

1.3.9.- SELECCIONAR EL GRUPO DE DESARROLLO.-

A partir del plan de organización, el gerente del proyecto solicita y selecciona e personal que va a elaborar el proyecto. La organización del grupo de desarrollo puede estar basada en uno de los tres tipos discutidos en la sección 3.3 del capítulo 3 de presente libro.

4-12

2 . - Los planes de pruebas y de implantación se elaboran en las fases de diseño e implantación respectivamente.

4-13

FASE 2: ANÁLISIS DEL CONTEXTO

OBJETIVO: Ganar un sólido conocimiento del sistema ampliado dentro del cual se ubicará el nuevo sistema de información y determinar las deficiencias y problemas que presenta el actual sistema de información (si existe).

PASOS:

Antes de realizar el análisis propiamente dicho de todo el sistema, denominado Análisis del Contexto, el grupo de desarrollo debe recopilar, archivar y analizar toda la documentación 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 documentación del plan del proyecto. Este primer paso de la se 2 es denominado Análisis Documental y constituye una fuente valiosa de documentación 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 descripción de situaciones problemáticas asociadas a este sistema dentro del sistema ampliado o contexto que lo contiene.

Si no existe un sistema actual de información, esta fase se limita a obtener la

documentación relativa al ambiente donde estará ubicado el sistema que se pretende introducir por primera vez y a analizar dicho ambiente.

DESCRIPCIÓN DE PASOS:

2.1.- ANÁLISIS DOCUMENTAL.-

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 documentación propia del sistema con miras a obtener una primera aproximación 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 colaboración de los diferentes usuarios del sistema actual, el grupo recopila oda la documentación 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 información.

2.1.2.- ORGANIZAR DOCUMENTACIÓN.-

Al finalizar la recopilación de documentos, el gerente del proyecto asigna a una o más personas del grupo para que se encarguen de organizar la biblioteca siguiendo los lineamientos contenidos en el plan de documentación del proyecto. Esta (s) personas) Irá designada como bibliotecarios) del proyecto.

4-15 4-14






2

2.1.3.- ESTUDIAR DOCUMENTOS.-

Después de haberse organizado la biblioteca, el grupo se dedica a estudiar la documentación allí archivada. Con tal finalidad, el gerente programa diferentes sesiones o reuniones de discusión, 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 análisis formal. 2.2.- ANÁLISIS DEL CONTEXTO.-

Este paso constituye un estudio formal de todo el sistema, con un nivel de detalle más profundo que aquellos realizados durante la tase de definición 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 problemáticas que el sistema presenta. A partir de ese modelo el grupo podrá realizar con mayor facilidad la construcción de un modelo para el nuevo sistema de información, 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 técnica conocida como Análisis Estructurado de Sistemas o alguna similar. El modelo general, así construido, está integrado por dos sub-modelos ligeramente diferentes. El modelo físico que describe las unidades, departamentos, grupos o personas que participan en el sistema de información y que ejecutan operaciones concretas e identificables y el modelo lógico que describe las funciones, procesos, actividades u operaciones que tienen lugar en el sistema.

A continuación se reseñan las actividades que debe llevar a la práctica 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 información. Ello debe llevar a: (1) determinar los objetivos de ese sistema, (2) definir su estructura (unidades funcionales de la organización 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 realización de las respectivas actividades del sistema. 2.2.2.- ANALIZAR EL SISTEMA ACTUAL DE INFORMACIÓN.-

En esta actividad el grupo de desarrollo identifica los objetivos, estructura y procesos del sistema actual de información. Ello lleva a efectuar las siguientes tareas:

• Definir los objetivos del sistema de información. • Identificar sus subsistemas. • Identificar sus funciones. • Identificar las entradas, procesos y salidas de cada función. • Determinar su flujo de información. • Identificar sus archivos. • Analizar su documentación y sus procedimientos manuales. • Identificar a los usuarios del sistema y describir sus tareas. • Describir la tecnología que utiliza el sistema.

2.2.3.- CONSTRUIR EL MODELO DEL SISTEMA ACTUAL DE INFORMACION.-

A raíz del anterior análisis el grupo está preparado para representar al sistema actual mediante un modelo. Pata ello utiliza la técnica de Análisis Estructurado de Sistemas que le permite elaborar los modelos físico y lógico del sistema de información. Las tareas que debe hacer el grupo durante esta actividad se dividen en:

• Construir los Diagramas de Flujo de Datos del Modelo Físico. • Construir los Diagramas de Flujo de Datos del Modelo Lógico. • Elaborar el diccionario de Datos (véase planilla en el Anexo A). • Describir cada proceso del Modelo Lógico hasta un nivel adecuado que

facilite la comprensión del modelo (véase anexo B). 2.2.4.- IDENTIFICAR LAS SITUACIONES PROBLEMÁTICAS.-

El grupo de desarrollo presenta, a continuación, el modelo del sistema actual a los usuarios para su validación correspondiente. Junto con los usuarios, el grupo posteriormente identifica, analiza y resume las situaciones problemáticas que posee el actual sistema de información. Algunos de los problemas típicos asociados a sistemas de esta naturaleza, son los siguientes: pésima calidad de la información suministrada, excesivos "cuellos de botellas", elevados tiempos de respuesta, excesivos costos de operación y mantenimiento, elevado número 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 descripción del ambiente y del mismo sistema, la presentación del modelo y la descripción de los problemas que presenta el actual sistema de información. Este informe es luego presentado a la Comisión de Planificación para su correspondiente evaluación.

4-174-16

2.2.6.- PLANIFICAR DETALLES DE LA PRÓXIMA FASE-

Esta actividad es básicamente una actualización del plan del proyecto y un medio de comparar lo que se ha ejecutado contra lo que se había planificado. Es realizada por el gerente del proyecto mediante el seguimiento de las tareas dadas a continuación:

• Evaluar las actividades, el uso de recursos y los resultados obtenidos en la presente fase.

• Detallar las actividades y tareas de la próxima fase. • Ajustar las estimaciones de recursos de la próxima 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.

MÉTODOS Y TÉCNICAS EMPLEADAS EN ESTA FASE

1.- TÉCNICAS PARA LA TOMA DE DATOS.- Ídem a la fase 1.

2.- ANÁLISIS ESTRUCTURADO DE SISTEMAS.- Es una técnica gráfica, empleada para el análisis de sistemas que permite describir y documentar las especificaciones funcionales de un sistema de información, esto es, las funciones que él realiza. Se caracteriza por lo siguiente:

• Es gráfico: 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 jerárquico: 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 jerarquía explicativa del sistema de información.

• Es fácil de mantener y actualizar.

Las herramientas que la técnica 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).

•

Descripción 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 técnica:

(Demarca, 1979a) (Demarca, 1979b) (Gane y Sarson, 1979)

3.- OTRAS TÉCNICAS ALTERNATIVAS.- A continuación se mencionan otras técnicas que pueden utilizarse para el análisis y especificación funcional de un sistema de información.

3.1.- Técnica de Jerarquía de Entrada-Proceso-Salida (HIPO).- Se explica en las siguientes referencias:

(IBM Co., 1975) (Montilva, 1982a) (Stay, 1980)

3.2.- Técnica de Análisis y Diseño Estructurado (SADT).- Se explica en las referencias dadas a continuación:

(Ross, 1980) (Ross y Schoman, 1980)

4.- OTRAS REFERENCIAS RELACIONADAS CON ESTA FASE.-

(Alexander, 1974) (Jenkins, 1969) (Ossa, 1983) (Robertshaw y otros, 1978)

4-194-18

FASE 3: DEFINICIÓN DE REQUERIMIENTOS

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

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 participación de los usuarios durante esta fase es determinante y de hecho, obligatoria, por eso el gerente del proyecto debe incorporar un número representativo de usuarios del sistema al grupo de desarrollo y trabajar continuamente con el resto de ellos.

Esta tase se inicia con la especificación de los requerimientos de información 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 especificación 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 Lógico del Nuevo Sistema, que junto con la Lista de Restricciones y Atributos producida por el paso 3.3 conforman, la "Especificación Funcional del Nuevo Sistema".

Para facilitar la determinación de los requerimientos que el sistema debe satisfacer, estos se dividen en:

• Requerimientos de información • Requerimientos funcionales • Restricciones para el desarrollo y operación • Atributos del sistema


3.1.- ESPECIFICACIÓN DE REQUERIMIENTOS DE INFORMACIÓN.-

Durante este paso el grupo de desarrollo se encarga de especificar junto con los

usuarios del nuevo sistema las salidas (listados, gráficos, diagramas, etc.), las entradas (para los distintos tipos: su formato, su medio, su volumen estimado, etc.), y las estructuras de datos necesarias (los registros lógicos que se necesitan y sus relaciones). Estos requerimientos de información 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 INFORMACIÓN.- En conjunto con los usuarios, el grupo de desarrollo determina las necesidades

actuales y futuras de información que el nuevo sistema de información debe satisfacer.






3

4-20 4-21

Estos requerimientos se pueden clasificar como sigue:

1. Requerimientos de salida.- Clasificados como reportes (listado, gráfico o despliegue visual de información) 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 características de las consultas y del lenguaje de interrogación que los usuarios desean.

2. Requerimientos de entrada.- Correspondientes a la captura y registro de los eventos o transacciones del sistema y a los datos que alimentarán a la base de datos. Para cada tipo de entrada se debe especificar la fuente, los elementos de datos que contiene, el método y medio de captura y los procedimientos y controles de edición y validación que sean necesarios.

3. Requerimientos de almacenamiento.- Corresponden al almacenamiento de datos del sistema. Se debe identificar los registros lógicos necesarios, sus estructuras y las relaciones entre ellos, así como también, los medios de almacenamiento y los volúmenes estimados.

Para llevar a cabo esta actividad el grupo debe realizar las siguientes tareas:

− Revisar los requerimientos de información del sistema actual a fin de

seleccionar aquellos que estén vigentes.

− Realizar entrevistas con los usuarios y/o solicitar por escrito los nuevos requerimientos de información, documentándolos mediante el uso de una planilla diseñada para tal fin.

3.1.2.- CONSTRUIR EL LIBRO DE REQUERIMIENTOS DE NFORMACIÓN.

Este libro contiene una entrada (planilla) para cada requerimiento de información nuevo o viejo. Los requerimientos se agrupan en divisiones de acuerdo al tipo señalado en la actividad anterior. La división de requerimientos de salida se organiza por secciones. Cada sección contiene los requerimientos de información (de salida) de una unidad funcional involucrada en el sistema. Para la recolección de estos requerimientos puede emplearse la planilla descrita en el anexo A.

3.2.- ESPECIFICACIÓN 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 información debe realizar. Estas funciones se describen en forma documental y gráfica utilizando la técnica de Análisis Estructurado

de Sistemas, la cual permite construir el Modelo Lógico 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 Especificación 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 consecución 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 sección 1.7 de este libro contiene una lista de las principales funciones que debe ejecutar cualquier sistema de información. Las características, detalles y funciones dependen, por supuesto, de las características del sistema de actividades al cual pertenece el sistema de información que se está especificando.

3.2.2.- CONSTRUCCIÓN DEL MODELO LÓGICO DEL NUEVO SISTEMA.-

Este modelo es construido utilizando la técnica de Análisis Estructurado de Sistemas y constituye un medio gráfico 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.

3.2.3.- ELABORAR EL INFORME DEL NUEVO SISTEMA.-

Bajo el nombre de Especificación Funcional del Nuevo Sistema se almacena en la biblioteca del proyecto el modelo lógico 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 Comisión de Planificación para su discusión y debida aprobación.

4-22 4-23

3.3.- ESPECIFICACIÓN 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 información. Así mismo, se establecen también, la interacción que debe haber entre el hombre y el computador y los atributos de calidad que se le van a imponer al mencionado sistema de información.

A continuación 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 continuación:

- Económicas: ¿De qué cantidad de dinero se dispone para desarrollar el sistema y para mantenerlo operando??

- Técnicas: ¿Qué equipo debe o puede utilizarse? ¿Es posible adquirir equipo adicional?

- De personal: ¿De qué personal se dispone para operar y mantener el sistema? ¿Cuál es la formación técnica de los usuarios?

- De tiempo: ¿Cuánto tiempo se dispone para desarrollar el sistema? ¿Cuál es la vida útil estimada del sistema?

- Legales: ¿Qué políticas, reglamentos, normas, leyes, etc., tanto internas como externas deben acatarse para desarrollar, operar y mantener el sistema?

3.3.2.- DETERMINAR INTERACCIÓN HOMBRE-MAQUINA.-

Esta actividad es esencial para la especificación y diseño del nuevo sistema de información; pues define la comunicación que debe haber entre los usuarios y el computador, a través del subsiste m programado. Algunas de las interrogantes que el grupo debe tratar de responder, sobre este punto son:

¿Qué grado de interacción hombre-máquina se desea? ¿Qué tan fácil de usar debe ser el sistema? ¿Qué tan fácil de entender debe ser el sistema?

¿Qué tiempo de respuesta se desea para cada función? ¿Qué tipo y niveles de entrenamiento pueden tener los usuarios? ¿Cuál debería ser la acción y reacción de los usuarios ante fallas del sistema? ¿Cuál debería ser la acción 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 sección 3.6.3 del capítulo 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 prue-bas?

- Movilidad: ¿Se desea implantar el sistema en diferentes equipos? ¿Qué tan independiente del equipo debe ser el sistema programado?

- Adaptabilidad: ¿Qué facilidad de expansión, crecimiento, modificación y

mantenimiento debe tener el equipo?

- Mantenimiento ¿Qué costo y tiempo son aceptables para reparar requerido: una falla .o hacer un cambio?

¿Quién va a realizar el mantenimiento? ¿Qué debe hacerse mientras se presta mante-nimiento?

- 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 ¿Cuáles son los tiempos de respuestas deseables? Rendimiento: ¿Qué volúmenes de procesamiento por unidad de tiempo se requieren? ¿Qué medidas adicionales de rendimiento se van a utilizar?

- Documentación: ¿Qué características especiales debe tener la documentación del

sistema?

3.3.4.- ELABORAR LA LISTA DE RESTRICCIONES Y ATRIBUTOS.

3.3.5.- PLANIFICAR DETALLES DE LA PRÓXIMA FASE.- Ídem a la actividad 2.2.6.

MÉTODOS, TÉCNICAS Y HERRAMIENTAS USADAS EN ESTA FASE:

1.- ANÁLISIS ESTRUCTURADO DE SISTEMAS.- Ver referencias y descripción al final de la fase 2. 2.- OTRAS TÉCNICAS ALTERNATIVAS:

2.1.- Técnica HIPO: Véase final fase 2. 2.2.- S.A.D.T.: Véase final fase 2. 2.3.- PSL/PSA: Véase (Teichroew y Hershey, 1979). 2.4.- SREM: Véase (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)

FASE 4: DISEÑO PRELIMINAR OBJETIVO: Elaborar un diseño preliminar del sistema de información que

satisfaga los requerimientos, restricciones y atributos establecidos en la fase 3. El diseño preliminar consta de un prototipo o modelo físico general que delinea la interacción hombre-máquina del sistema de información y describe, en forma general, sus procesos automatizados.

PASOS:






4

4-26 4-27

Las unidades involucradas proporcionan al grupo de desarrollo la configuración y las especificaciones técnicas de los equipos que se pueden utilizar para el desarrollo del sistema de información. El grupo estudia estas especificaciones y luego determina diferentes prototipos o modelos físicos del sistema que puedan ser implantados y que satisfagan las especificaciones contenidas en la Especificación Funcional del Nuevo Sistema. Si algunos de los prototipos requieren equipos o programas adicionales, entonces, se solicita una cotización de las configuraciones necesarias, a diferentes vendedores de equipos (paso 4.1). A continuación, la Comisión de Planificación evalúa los diferentes prototipos que le ha presentado el grupo de desarrollo y selecciona el más adecuado de acuerdo al análisis 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 Planificación 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 Diseño Preliminar. DESCRIPCIÓN DE PASOS 4.1.- DEFINICIÓN DE PROTOTIPOS.-

En este paso el grupo de desarrollo elabora diferentes prototipos que puedan satisfacer la especificación 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; cuáles de ellos existen en la organización y están disponibles; y cuáles se deberían adquirir. Se solicitan precios y especificaciones técnicas de los equipos o programas, que hagan falta, a los diferentes vendedores del mercado.

La definición de prototipos está regida por la estructura o configuración global del sistema de información, la cual fue seleccionada durante el paso 1.2 (Estudio de Factibilidad). En ella se indica si el diseño 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 línea o a tiempo real) y para la interacción que existirá entre el hombre y la máquina.

Las actividades que el grupo debe realizar en este paso se resumen a continuación:

4.1.1.- ELABORAR DIFERENTES PROTOTIPOS ALTERNATIVOS.-

A partir del modelo lógico 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 lógico que muestra claramente la interacción hombre-máquina, esto es, indica qué procesos son manuales y cuáles automáticos (este modelo también recibe el nombre de modelo físico, aunque ello puede originar confusión con el modelo de entes físicos, antes discutido). Para aquellos procesos que sean automáticos se determina el equipo necesario y se especifica las características técnicas deseadas, de igual modo se establecen los programas de apoyo que hagan falta

(ejem. Compiladores, herramientas de programación, sistema de manejo de bases de datos, etc.), para desarrollar el sistema.

El prototipo muestra, también, los procedimientos de activación del subsistema programado, los de respaldo y recuperación de fallas y los de seguridad de la base de datos.

4.1.2.- EVALUAR CONFIGURACIÓN TÉCNICA EXISTENTE.-

Tomando como datos las configuraciones de equipos existentes en la organización, 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 CONFIGURACIÓN TÉCNICA NECESARIA.-

Para aquellos prototipos que no puedan ser desarrollados totalmente con la tecnología disponible en la organización actualmente, se elaboran las configuraciones técnicas adicionales que ellos requieran y se solicitan las cotizaciones respectivas a los vendedores del mercado.

4.2.- SELECCIÓN DE PROTOTIPOS.-

En este paso el grupo de desarrollo realiza un análisis de costo-beneficio para los diferentes' prototipos definidos en el paso anterior. El resultado de este análisis se presenta y discute con la Comisión de Planificación, quien decide posteriormente el prototipo más conveniente y d. las instrucciones necesarias para la adquisición de la tecnología 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 ANÁLISIS COSTO-BENEFICIO.-

Para cada prototipo se determinan sus costos de desarrollo y operación y se estiman los beneficios que puedan obtenerse. Se comparan los diferentes prototipos bajo un criterio económico preestablecido. Los resultados obtenidos se resumen en un informe técnico denominado Informe de Prototipos.

4.2.2.- DISCUTIR INFORME DE PROTOTIPOS.-

El informe producido en la actividad anterior se presenta a la Comisión de Planificación, quien lo discute y finalmente selecciona el prototipo que considere más conveniente a la organización. Si el prototipo elegido requiere equipos y programas adicionales o totalmente diferentes a los existentes, entonces la Comisión determina los pasos necesarios y las responsabilidades para adquirir esa tecnología.

4-28

4-29

4.2.3.- ADQUIRIR TECNOLOGÍA NECESARIA.-

De ser necesario, el grupo de desarrollo, o en su defecto, el que designe la Comisión de Planificación, se encarga de adquirir, instalar y probar el equipo y los programas que el prototipo seleccionado requiera para su desarrollo u operación.

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 automáticos, siguiendo la técnica de Análisis Estructurado de Sistemas. El modelo así obtenido, se somete a una revisión o inspección a fin de hallar inconsistencias o errores.

Las actividades que el grupo debe llevar a efecto se dan a continuación:

4.3.1.- REFINAR PROTOTIPO.-

Cada proceso automático del prototipo se refina mediante la descomposición

funcional establecida por la técnica AES. Cada proceso del más bajo nivel debe describirse utilizando cualquiera de las técnicas siguientes: Algoritmos Estructurados, Tablas de Decisión o Árboles de Decisión. Los entes del Diccionario de Datos que se vean afectados por la automatización deben ser actualizados durante esta actividad.

Los procedimientos automatizados para: (1) la activación del subsistema programado, (2) el respaldo y recuperación de la base de datos y (3) los mecanismos de seguridad del sistema deben, también, refinarse durante esta actividad.

4.3.2.- REVISAR PROTOTIPO.-

El modelo o prototipo obtenido en la actividad anterior se somete a una revisión estructurada o a una inspección de diseño. 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 Comisión de Planificación para su discusión y aprobación rutinaria. 4.3.4.- PLANIFICAR DETALLES DE LA PRÓXIMA FASE.-

Ídem a la actividad 2.2.6.

MÉTODOS, TÉCNICAS Y HERRAMIENTAS USADAS EN ESTA FASE:

1.- ANÁLISIS COSTO-BENEFICIO.- Véase fase 2.

2.- ANÁLISIS ESTRUCTURADO DE SISTEMAS.- Véase fase 3.

3.- ALGORITMOS ESTRUCTURADOS.- Técnica que utiliza las estructuras de la Programación Estructurada y un grupo selecto de palabras del lenguaje Español para describir los pasos necesarios para realizar una actividad o resolver un problema dado. Véanse las siguientes referencias:

(Montilva, 1982b) (Anexo B)

Una técnica 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 continuación:

(Caine y Gordon, 1980)

4-30 4-31

FASE 5: DISEÑO DETALLADO OBJETIVO: Elaborar un diseño detallado del sistema de información

que muestre cómo se construirán el subsistema de datos y el subsistema programado. Esta fase produce el "paquete de diseño", el cual contiene todas las especificaciones para la construcción del sistema, y el plan de pruebas que regirá las diferentes pruebas del sistema de información durante las fases de construcción, pruebas e implantación.

P A S O S :

A partir del Informe del Diseño Preliminar, que contiene el prototipo, y de la Configuración Técnica del equipo que va a ser utilizado, el grupo de desarrollo inicia el diseño detallado del sistema de información. Para ello, debe realizar los pasos siguientes: (1) El diseño de las entradas y de las salidas del sistema, esto es, los detalles de la interacción hombre-máquina; (2) El diseño del subsistema de datos, esto es, de la base de datos y los procedimientos que se requieren para crearla e inicializarla; (3) El diseño 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 información. Las especificaciones producidas en los pasos 5.1, 5.2 y 5.3 se ensamblan junto con el prototipo para producir el paquete de diseño que el grupo utilizará para construir el sistema. Finalmente se elabora el plan de pruebas que describe las actividades, calendarios, procedimientos y técnicas que se emplearán 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).


5.1.- DISEÑO DE ENTRADAS Y SALIDAS.-

En este paso se elabora minuciosamente el diseño de la interacción entre el hombre y la máquina, 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.- DISEÑAR EL DIALOGO HOMBRE-MAQUINA.-

Dependiendo del tipo de interacción hombre-máquina seleccionada, en esta actividad se debe (1) determinar el medio de comunicación (terminal, teleimpresor, lectora óptica, etc.), estableciendo además, sus características, capacidades y especificaciones técnicas que afecten el diseño de los programas; (2) determinar el tipo de diálogo hombre-máquina y diseñarlo completamente; y (3) describir la acción 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 precaución 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 diseño el grupo debe establecer junto con el usuario el tipo de diálogo y sus elementos. Los diálogos interactivos que existen actualmente se pueden clasificar en los siguientes tipos:

− Selección Múltiple ("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 diálogo, sus parámetros y las funciones que realizan. Si el diálogo es del tipo de selección múltiple, se deben diseñar las pantallas de selección; si es de comandos, consulta o semi-natural, se debe especificar la gramática (sintaxis), la semántica y la pragmática del lenguaje.

5.1.2.- DISEÑAR LAS PANTALLAS DE ENTRADA/SALIDA.-

Esta actividad consiste en diseñar la estructura o formato de cada pantalla de entrada de datos al sistema y de salida de información a los usuarios. Para cada pantalla se debe diseñar también el registro de datos asociado, es decir, el que permite construir la pantalla.

4-33






5

4-32

5.1.3.- DISEÑAR LOS REPORTES.-

En esta actividad el grupo diseña aquellos reportes que no fueron especificados en la actividad anterior. Estos son básicamente, los listados de papel, los gráficos y los diagramas. Para cada uno de ellos se debe especificar su estructura o formato, su contenido (registro de datos) y el medio de producción o salida.

El diseño de los elementos descritos (diálogo hombre-máquina, pantallas de E, S y reportes) conforman la especificación de entradas y salidas del subsistema programado.

5.2.- DISEÑO DE DATOS.-

El diseño del subsistema de datos del sistema de información gira en torno a (1) el diseño de la (s) base (s) de datos necesaria (s) para almacenar los datos de dicho sistema y (2) el diseño de los programas que permitirán crear y "cargar" (inicializar) la(s) base(s) de datos. Para realizar este paso existe un amplio conjunto de metodologías que pueden ayudar al grupo a realizar un diseño eficiente y consistente de la base de datos (véase referencias al final de la fase).

A continuación se describen, en forma general, las actividades que debe realizar el grupo de desarrollo durante el diseño de datos.

5.2.1.- REALIZAR EL DISEÑO LÓGICO DE LA BASE DE DATOS.-

En este proceso de diseño se elabora un modelo de datos que represente a las entidades (objetos y eventos), sus atributos (propiedades o características 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-relación correspondiente.

− Si el SMBD que se vaya a utilizar manipula bases de datos relacionales, entonces cada entidad del modelo entidad-relación 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.

5.2.2.- REALIZAR EL DISEÑÓ FÍSICO DE LA BASE DE DATOS.-

Dependiendo del tipo y características 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 lógicas de los datos y sus correspondientes estructuras de almacenamiento e indica los métodos de acceso que se utilizarán, en términos del lenguaje de descripción de datos del SMBD. Este diseño depende enteramente del SMBD seleccionado, por lo que el grupo debe seguir los lineamientos e indicaciones dadas en la documentación del SMBD.

5.2.3.- DISEÑAR LOS PROGRAMAS DE INICIALIZACIÓN Y MANTENI-

MIENTO DE LA B.D.-

En esta actividad el grupo diseña 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 difícilmente pudiesen almacenarse mediante el subsistema programado. Estos programas serán 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 diseñan los detalles de los procedimientos de respaldo y

recuperación de la base de datos.

5.3.- DISEÑO DE PROGRAMAS Y PROCEDIMIENTOS.-

Luego que se ha elaborado el diseño de E/S y el de datos, el grupo de desarrollo puede proceder a diseñar los programas y procedimientos del subsistema programado.

El prototipo del nuevo sistema de información, su correspondiente especificación

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 diseña una estructura que bien podría 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 módulos que configuran una jerarquía, en la que los módulos de nivel superior actúan como controladores del flujo del programa o ejecutan las funciones generales y los módulos de bajo nivel ejecutan las funciones de detalle. Se establece de este modo una estructura jerárquica modular, de la cual se emprende el diseño de cada módulo, diseño éste que se concreta en lo que denominaremos como especificación de programa.

4-35 4-34

En este paso se diseña también toda la documentación y procedimientos manuales que el sistema de información demande.

Para llevar a cabo este paso el grupo de desarrollo efectúa las actividades reseñadas a continuación: 5.3.1.- DISEÑAR LA ESTRUCTURA DEL SUBSISTEMA PROGRAMADO.-

El subsistema programado se diseña como una estructura jerárquica compuesta por uno o más programas, cada uno de estos se compone, a su vez, de módulos. Un módulo se define como una unidad de programa que se caracteriza por lo siguiente:

− Posee un nombre propio y único. − Ejecuta una función 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 módulo.

Son ejemplos de módulos: las subrutinas de FORTRAN, los procedimientos de ALGOL, PASCAL y PL/I y los párrafos y secciones de COBOL (aunque no cumplen con todos los puntos mencionados).

Para el diseño de la estructura el grupo dispone un amplio conjunto de técnicas, entre las cuales se destaca el Diseño Estructurado (véase referencias al final de la fase). El objetivo de la citada técnica es diseñar un sistema programado como una estructura jerárquica compuesta de módulos de función simple relativamente independientes. El proceso de diseño se basa en el principio de Descomposición Funcional, que consiste en dividir, de acuerdo a la especificación funcional, el sistema programado en subsistemas o programas, cada uno de los cuales se divide luego en piezas funcionales (módulos). Este proceso se repite hasta que se logra alcanzar un nivel funcional detallado, en el que cada módulo ejecuta una función básica. El árbol o red modular, así obtenida, constituye la estructura del subsistema programado.

El diseño se inicia con la determinación de una estructura jerárquica inicial para el subsistema programado. Esta estructura se deriva de los procesos automatizados que se han identificado en el prototipo del sistema, mediante la aplicación del Análisis de Transformaciones y el Análisis de Transacciones; estrategias propias de la técnica Diseño Estructurado. La utilización de las estrategias mencionadas produce una o más sub-estructuras jerárquicas (programas) relacionadas o relativamente independientes, las cuales definen la estructura inicial del subsistema programado. Cada sub-estructura es, luego, descompuesta en módulos, sucesivas veces, hasta llegar a un nivel en el cual cada módulo de nivel inferior ejecuta una función simple, que puede ser especificada mediante un algoritmo o diagrama de flujo con facilidad. Se obtiene, de este modo, la estructura del subsistema programado.

5.3.2.- DISEÑAR CADA MÓDULO DE LA ESTRUCTURA.-

Durante la presente actividad el grupo elabora el diseño de cada uno de los módulos que configuran la estructura del subsistema programado. Este diseño consiste en establecer la "lógica" general de cada módulo, esto es, describir los pasos necesarios para llevar a cabo la función asignada al módulo. El nivel de detalle descriptivo debe ser tal que le permita a un programador acometer la codificación del módulo, con relativa facilidad y sin ambigüedad alguna. La lógica de un módulo se puede representar mediante el uso de algoritmos o diagramas de flujo. La técnica que hemos denominado Algoritmos Estructurados (véase referencias al final de la fase) puede ser utilizada para este fin, con la ventaja de que su aplicación produce un diseño modular completamente estructurado, ya que está basada en los principios de la Programación Estructurada.

El algoritmo o diagrama de flujo del módulo, en sí, no es suficiente como para que un programador empiece su codificación; pues se requiere de una información adicional sobre las características del módulo, su función, su ubicación, sus argumentos, etc. Toda esta información se condensa en un formulario elaborado para tal fin y que se denomina Especificación de Programa (véase planilla correspondiente en el Anexo A). El diseño de cada módulo se especifica en una planilla de este tipo.

5.3.3.- DISEÑAR LA DOCUMENTACIÓN Y LOS PROCEDIMIENTOS

MANUALES.-

En esta actividad el grupo se ocupa de determinar el formato y contenido de cada uno de los manuales que forman la documentación del sistema de información (ejem. manual del usuario, manual del sistema, etc.), de acuerdo a lo que se ha establecido en el plan de documentación. De igual modo se diseñan los formatos, formularios, instructivos, planillas y demás 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 información.

La estructura del sistema programado, las especificaciones de programa asociadas a cada módulo de esa estructura y el diseño de la documentación y de los procedimientos manuales, constituyen lo que se denomina como la especificación del subsistema programado.

5.4.- ENSAMBLAJE DEL PAQUETE DE DISEÑO.-

Este paso se inicia desde la finalización de los pasos 5.1, 5.2 y 5.3 y se basa en revisar y ensamblar el conjunto de especificaciones de diseño producidas en los citados pasos, con el propósito de garantizar la consistencia, calidad y exactitud del diseño e integrar lo que hemos denominado como paquete de diseño. Este documento es la esencia para la construcción del sistema; pues establece "qué" y "cómo" deben hacerse las cosas durante esa fase.

4-37

4-36

5.4.1.- REALIZAR UNA REVISIÓN ESTRUCTURADA DEL DISEÑO.-

Para cada una de las especificaciones producidas en los pasos 5.1, 5.2 y 5.3 se realiza una revisión estructurada (o una inspección de diseño) siguiendo los lineamientos dados, para estas técnicas, en la sección 3.6.3 del capítulo 3. Los objetivos de estas revisiones son: (1) determinar las inconsistencias del diseño; (2) determinar las fallas y errores cometidos en las diferentes especificaciones; (3) medir y corregir las desviaciones del diseño con respecto a las normas y procedimientos de diseño establecidos en el plan metodológico; (4) asegurar que las restricciones y atributos establecidos se satisfagan plenamente con el diseño elaborado; y (5) asegurar que cada requerimiento contenido en el Libro de Requerimientos y cada especificación funcional del prototipo se cubran o satisfagan con el diseño producido. Para facilitar este último objetivo, la Matriz de Seguimiento de Requerimientos, descrita en la sección 3.6.1 del capítulo 3, es una herramienta muy valiosa que le permite al grupo llevar un seguimiento de cada requerimiento durante el diseño, construcción 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 DISEÑO.-

Las especificaciones de diseño, una vez revisadas y corregidas, se ensamblan para producir el paquete de diseño. Este documento contiene todo el material descriptivo necesario para conducirla construcción del sistema. Por consiguiente, contiene: (1) el prototipo del sistema; (2) la configuración y documentación del equipo que se va a emplear; (3) las especificaciones de entrada y salida; (4) la especificación del subsistema programado; (5) la especificación 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 sección 3.6.1 del capítulo 3, con la finalidad de ensamblar en forma ordenada y modular las especificaciones tanto funcionales como las de diseño.

Luego que se ha ensamblado el paquete de diseño, éste se almacena en la biblioteca del proyecto para su posterior utilización durante las fases restantes.

5.4.3.- ELABORAR Y DISCUTIR EL INFORME DEL DISEÑÓ DETALLADO.-

Haciendo uso del paquete de diseño, el gerente del proyecto elabora un informe descriptivo de las características, ventajas, desventajas y los ajustes de costos y tiempos de desarrollo, que el diseño elaborado involucra. Este informe se presenta luego a la Comisión de Planificación, quien aprueba, rechaza o recomienda modificar el diseño detallado del sistema de información.

5.5.- PLANIFICACIÓN DE LAS PRUEBAS.-

A pesar de que se ha identificado la fase 7 de esta metodología 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 metodología. Las razón de ello es fundamentalmente estratégica, pues de realizarse todas las actividades durante la fase de pruebas, el tiempo o duración total del proyecto se extendería 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 diseño y construcción del sistema. Bajo este criterio, podemos dividir las actividades generales de las pruebas en:

− Planificación de las pruebas. − Diseño y Construcción de las pruebas. − Ejecución de las pruebas.

La primera de ellas se realiza durante esta fase de diseño, la segunda durante la fase de construcción y la última se distribuye a lo ancho de las fases de construcción 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 información, El resultado de este proceso lo constituye el PLAN DE PRUEBAS. Este plan es un documento que guía el desarrollo de las pruebas en los distintos niveles del sistema de información. En él se identifican: (1) las diferentes pruebas que han de realizarse; (2) los responsables de diseñarlas, construirlas y ejecutarlas; (3) la programación de tiempos, costos y recursos necesarios para llevarlas a cabo; (4) las herramientas, métodos, técnicas y procedimientos que se deben emplear en las diferentes actividades de prueba; (5) los criterios de éxito de cada prueba; y (6) información adicional que se necesite para efectuar tales pruebas.

El plan de pruebas se puede organizar en secciones, tal como se describe a continuación:

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 diseño, construcción y ejecución; y la fecha de inicio y terminación de cada actividad de Prueba. Un elemento de prueba es un componente del sistema de información que debe someterse a prueba. Generalmente, estos componentes se clasifican en:

4-38

4-39

− UNIDADES.- Una unidades un módulo de la estructura del subsistema programado.

− SUBSISTEMA.- Un subsistema de prueba es un grupo de módulos interrelacionados que ejecutan, en conjunto, una función detallada o general del subsistema programado.

− SISTEMA.- El sistema de prueba lo constituye el sistema de información en su totalidad.

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 módulos del subsistema programado.

− PRUEBAS DE SUBSISTEMA.- Permiten probar y depurar cada subsistema de prueba, esto es, cada grupo funcional de módulos del subsistema programado. El objetivo de esta prueba es detectar y corregir los errores presentes en: (1) la integración de módulos en subsistema funcionales y (2) la realización de las diferentes funciones que el subsistema programado debe cumplir. Las pruebas de subsistema se pueden realizar jerárquicamente probando primero las funciones más detalladas o de más bajo nivel en la escultura (ejem. elimine un registro del archivo XYZ), luego se prueban las funciones intermedias de la jerarquía (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 información, que consiste en probar y depurar la integración 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 ACEPTACIÓN.- Es la prueba final del sistema y es realizada ante la presencia del Comité de Planificación y los directivos de las unidades involucradas. Se realiza en el ambiente real del sistema de información, con el propósito de demostrar que el sistema desarrollado satisface las necesidades que motivaron la realización del proyecto.

2 . - Estos términos, si bien están 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

3. HERRAMIENTAS, TÉCNICAS Y MÉTODOS.- En esta sección 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, también, los métodos y técnicas de pruebas que se pretendan utilizar para la realización de las diferentes actividades (ejem. pruebas de arriba-hacia-abajo, pruebas de abajo-hacia-arriba, etc.).

4. SEGUIMIENTO DE REQUERIMIENTOS.- En esta sección 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 utilizarán para diseñar y construir las pruebas y para reportar el progreso de su ejecución y de los resultados obtenidos.

6. NORMAS.- Aquí se mencionan las normas que se deben seguir para el diseño y construcción de cada especificación de prueba.

7. CRITERIOS DE ÉXITO.- Para las diferentes pruebas que se vayan a efectuar, se identifican los criterios que prevalecerán 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 propósito 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 Comisión de Planificación.

5.5.3.- PLANIFICAR DETALLES DE LA PRÓXIMA FASE.-

Ídem a la actividad 2.2.6.

MÉTODOS, TÉCNICAS Y HERRAMIENTAS UTILIZADAS EN ESTA FASE:

Los métodos y técnicas que existen para el desarrollo de esta fase son muy numerosos. A continuación, se dan las referencias bibliográficas para algunos de sus Pasos; en la mayoría de estas referencias se describen una o más técnicas alternativas a las que se sugiere utilizar en esta metodología.

1.- EN EL DISEÑÓ DE ENTRADAS Y SALIDAS.- Se recomienda la lectura de

4-40

4-41

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

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

3.- EN EL DISEÑO DE PROGRAMAS.- Para este paso el número de métodos técnicas que existen es amplio. Para esta metodología, sin embargo, se recomienda utilizar las siguientes:

3.1.- DISEÑO ESTRUCTURADO.- Descrito en las siguientes referencias: (Montilva, 1982a) (Stevens y otros, 1980) (Stevens, 1981) (Yourdon y Constantine, 1978)

3.2.- ALGORITMOS ESTRUCTURADOS.- Véanse las referencias siguientes

(Montilva, 1982b) (Anexo B de este libro)

Otras referencias de interés para este paso son las siguientes:

(Caine y Gordon, 1980) (Páez, 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 elaboración del plan de pruebas s

recomienda la lectura de las siguientes referencias: (Adrion y otros, 1982) (Metzger, 1978, pp. 183-185) (Jensen y Tonies, 1979, pp. 340- (Myers, G., 1976, pp. 242-244; 343)

4-42

jonas montilva capitulo 04

Documents