Sistemas y métodos administrativos

Control y Evaluación de Proyectos de Software

T.N.S. en Computación e Informática

1

PAPERS “3” de SISTEMAS Y METODOS ADMINISTRATIVOS METODOLOGIA CICLO DE VIDA DE SISTEMAS DE INFORMACION Por: Alberto R. Lardent URL: http://www.cyta.com.ar/elearn/syma/textos/texto_3.htm

Introducción

Toda metodología se apoya en el desarrollo de etapas o fases que deben cumplirse observando un riguroso orden secuencial con el fin de alcanzar un determinado objetivo. En el caso del desarrollo de sistemas de información el objetivo será disponer de información y a partir de allí la información se convertirá en medio para alcanzar objetivos corporativos.

Es posible que no todos los autores o firmas consultoras coincidan en cuanto a la cantidad y denominación de las fases que integran la metodología del desarrollo de sistemas de información. Sin embargo todos enfatizan la necesidad de aplicar un enfoque sistémico encadenado en pasos secuenciales y bien definidos. A pesar de ello debe observarse que las etapas no significan compartimentos totalmente independientes; por el contrario las actividades pueden traslaparse y las fronteras entre etapas son temporales.

A nuestro entender las etapas del “ciclo de vida de sistemas de información” son las que se mencionan a continuación.

1. Definición del objetivo y alcance del sistema. Estudio de factibilidad. Planeamiento.

2. Determinación y análisis de requerimientos de información. Relevamiento. Diagnóstico.

3. Diseño lógico.

4. Ingeniería de software.

5. Prueba del sistema.

6. Implementación. Conversión.

7. Mantenimiento y evaluación.

Explicaremos en las secciones siguientes las características de cada una de estas etapas.



2

Etapa 1. Definición del objetivo y alcance del sistema. Estudio de

factibilidad.

Planeamiento.

Objetivos y alcance

Todo proyecto debe partir de una definición clara de sus objetivos. No existe proyecto sin objetivos. Los objetivos sirven de orientación para todos aquellos que, en condiciones de usuarios o de especialistas en informática se encuentran involucrados en el proyecto (alcance). Esta etapa es fundamental para señalar el camino que debe recorrerse para llegar a un final exitoso del proyecto.

Los objetivos pueden enfocarse hacia la solución de problemas cuyos síntomas se hayan detectado en la organización, o bien hacia el adecuado y oportuno aprovechamiento de oportunidades.

Los problemas debe ser identificados e indicados con precisión (particularmente sus causas y sus efectos). Las oportunidades pueden significar un mejoramiento en el posicionamiento competitivo de la organización.

Los problemas se ponen en evidencia cuando se perciben síntomas de no cumplimiento de los objetivos que trazaron la definición de los sistemas vigentes. O bien cuando se percibe que aquellos objetivos originales ya no tienen vigencia, y por lo tanto el sistema debe ser reemplazado.

La percepción de no cumplimiento de objetivos puede observarse a partir de la salida de información, cuando ésta ya no ocupa un lugar importante en la consideración de antecedentes para la toma de decisiones, o cuando ya no es confiable como apoyatura para la ejecución de transacciones (se observa exceso de errores, información no actualizada oportunamente, lentitud en la extracción de resultados, etcétera).

La figura de la realimentación (proveniente de captar la opinión negativa o reclamo de clientes, proveedores o socios del negocio) puede ser un elemento a tener en consideración en el momento de inventariar problemas. Esto último es particularmente importante en situaciones en que las organizaciones enfatizan la necesidad de mejorar sus relaciones con clientes apuntado al mantenimiento de la fidelidad de los mismos y a la captación de aquéllos que sean potenciales.

Las oportunidades pueden significar un mejoramiento en el posicionamiento competitivo de la organización. Pueden encontrarse oportunidades efectuando una integración de procesos, provocando una reducción de operaciones no necesarias o que pueden suprimirse (por ser duplicadas) o bien



3

automatizando controles, a través de la incorporación de rutinas programadas de verificación.

Las mejoras en los sistemas también pueden surgir como resultado de un análisis de la entrada y la salida. Pueden reducirse errores en el ingreso de datos a través de rutinas de control o cambios en los medios de entrada: reemplazo de digitación en teclado por lectura de códigos de barra o caracteres ópticos. El análisis de la salida puede recomendar la supresión de listados impresos y su reemplazo por información que se despliega en pantalla. La comunicación con clientes y proveedores puede optimizarse utilizando medios de transmisión electrónica de datos (e-mail o EDI, por ejemplo).

Estudio de factibilidad

Los proyectos presentados como necesarios, en razón de sus objetivos, deben ser sometidos a un estudio de factibilidad. La factibilidad consiste en determinar la posibilidad y la conveniencia de seguir adelante con el proyecto. Esto significa el convencimiento de que el proyecto ayuda a la organización a alcanzar los objetivos corporativos que ha formulado.

La factibilidad debe ser evaluada en tres aspectos: económico/financiero, técnico y operacional.

Todo proyecto involucra una inversión. Por lo tanto debe efectuarse un estudio (utilizando alas técnicas generales del análisis financiero) que permita evaluar desde ese punto de vista la conveniencia de encarar y desarrollar el proyecto. Debe lograrse una reducción de los costos de operación o bien llegar a la conclusión de que los costos a corto plazo son superados por los ingresos a largo plazo, para que el proyecto pueda considerarse factible. Los costos en el desarrollo de un proyecto están representados principalmente por el tiempo dedicado al desarrollo en sus diversas fases de análisis, diseño e instalación (por parte de usuarios y especialistas en informática) y por el costo estimado de equipamiento (hardware y comunicaciones).

La factibilidad técnica se refiere a la posibilidad de satisfacer los requerimientos del equipamiento tecnológico necesario para la instalación del sistema propuesto. Debe preverse también la posibilidad de escalabilidad de ese equipamiento: ¿qué ocurrirá si aumenta la cantidad o cambia la ubicación geográfica de los usuarios? ¿el nuevo equipo y los procedimientos asociados podrán resistir un incremento en la cantidad de datos a procesar? ¿se mantendrán las condiciones de seguridad?

La factibilidad operacional de un proyecto de sistemas está vinculada a la disponibilidad en el momento y en el lugar adecuado, de los recursos humanos que habrán de participar en el proyecto, principalmente cuando éste se convierta en producto y debe ser operado a través de esos recursos. En este sentido deben analizarse dos aspectos. Por un lado el nivel de capacitación alcanzado por el personal afectado si se implanta el proyecto y la posibilidad



4

de capacitarlo en caso de que no lo esté. Por otro lado habrá que evaluar el comportamiento (actitud y aptitud) de ese personal con respecto a los nuevos sistemas. Existe una natural reacción al cambio en todo ser humano que en muchas ocasiones se convierte en temor, dado que el avance de la tecnología da por tierra con la antigua concepción de actividad desarrollada artesanalmente en la administración. El cambio puede favorecer o puede perjudicar al que lo experimenta. Y esto produce incertidumbre. Es un tema que no se puede soslayar. Debe darse participación al usuario en las definiciones y en la fijación de las políticas, si se desea contar con su apoyo.

Planeamiento

Todo proyecto debe ser planificado dado que son varias las actividades que participan del mismo (y generalmente muchas) y por lo tanto se hace necesario una coordinación. El planeamiento involucra también la intención de posibilitar un control del grado de avance de lo planificado, a través de la comparación con lo ejecutado. De esa comparación pueden surgir notificaciones de desviaciones (demoras) que deben ser atendidas y evitar que provoquen la imposibilidad de cumplir en tiempo con la finalización del proyecto.

El planeamiento y su control exigen la designación de un coordinador o director del proyecto que se responsabilice tanto de definir actividades, tiempos y responsables, como del seguimiento de su ejecución.

Las actividades deben ser expresadas en un adecuado nivel de detalle, a efectos de evitar la generalización. Las actividades deberán ser ubicadas en el tiempo, definiendo para cada una momento de iniciación y momento de finalización. El tiempo (duración) puede ser expresado en valor más probable, o bien en pesimista u optimista. También debe el coordinador indicar qué actividades pueden desarrollarse simultáneamente (en forma paralela) y cuáles son precedidas por otras, que necesariamente deben terminar para que puedan comenzar aquéllas.

Suelen utilizarse formas gráficas para calendizar las actividades. El gráfico Gantt muestra por medio de barras horizontales la ubicación de cada actividad en el tiempo. La longitud de cada barra representa la longitud relativa de cada tarea. El gráfico PERT muestra las actividades de un proyecto bajo la forma de una red compuesta por nodos y flechas. El PERT permite determinar cuáles son las actividades críticas (aquellas que integran el camino crítico). Las actividades críticas son aquellas que si se atrasan una unidad de tiempo respecto a lo planificado provocarán una demora general en la terminación del proyecto. Obviamente el coordinador deberá tomar los recaudos necesarios para aprovechar los recursos asignados a las actividades que disponen de tiempo de holgura (aquellas que no integran el camino crítico) para asignarlas en apoyo de las actividades críticas demoradas.



5

Etapa 2: Determinación y análisis de requerimientos de información

Técnicas de relevamiento

Entrevistas personales

La entrevista es la técnica más tradicional y posiblemente es casi inevitable. Consiste en un diálogo que tiene un propósito bien definido (no se concibe una entrevista sin un propósito) y que se configura en un formato (estructura) de preguntas planificadas que esperan adecuadas respuestas que satisfagan su propósito.

En las entrevistas se recoge información que abarca dos tiempos: por lado las experiencias “del pasado”, aquellas circunstancias o hechos que revelan las falencias o insuficiencias de los procedimientos desarrollados hasta ese momento; y por otro lado una relación “hacia el futuro”, cuando se mencionan objetivos deseados pero aún no alcanzados; los objetivos, mencionados por los usuarios de información proyectan el futuro de la organización. De ahí que los tipos de información que se intenten recoger en una entrevista se refieren a la opinión del entrevistado respecto a los procedimientos (formales e informales) que se desarrollan, su nivel de aprobación o negación, y a su actitud frente a la intención de cambio.

El contenido de las preguntas que se formularán a los entrevistados dependerá del nivel en que estos se encuentran ubicados en la organización. Si el entrevistado es un directivo, las preguntas girarán en torno de las decisiones que toman y sobre qué información se apoyan para la toma de esas decisiones. Las respuestas a esta última pregunta dará lugar a sucesivas preguntas adicionales sobre la calidad y cantidad de información disponible hasta ese momento y sobre la deseable.

Si el entrevistado es un usuario de nivel medio, habitualmente dedicado a ejercer controles respecto a la aplicación de los planes e instrucciones de los niveles superiores, las preguntas se orientarán hacia aclarar en función de qué información se ejercen esos controles. Si el entrevistado es un usuario responsable de las operaciones rutina (transacciones) tales como compras, ventas, pagos, cobranzas, etc., las preguntas girarán entorno a los procedimientos utilizados, formularios aplicados, origen de la información a procesar y destino de la procesada.

La entrevista debe ser planificada. No se debe improvisar una reunión de este tipo. Debe cumplirse una secuencia de pasos. Se indican a continuación.

1. Sensibilizarse con la organización y con los miembros a quienes se va a entrevistar. Conocer previamente la cultura organizacional (información de fondo) ayuda a evitar la pérdida de tiempo que ello significaría si se efectuara durante la entrevista.



6

2. Fijar los objetivos particulares de la entrevista. Desde luego que ello dependerá del nivel o posición del entrevistado, pero siempre habrá una estructura que comprenderá las áreas de: decisiones, frecuencia de toma de decisiones, fuente de información, formato de la información, procedimientos (formas de tratamiento de la información).

3. Selección y anticipación de los entrevistados. Deben ser entrevistados todos los afectados (alcanzados) por el sistema a proponer (proyecto). Si éstos son muchos habrá que seleccionar uno de cada función clave. No es suficiente conocer sólo los grandes lineamientos sino también las condiciones de detalle de los procedimientos. Se deberá avisar anticipadamente el objetivo y momento de reunión con el entrevistado.

4. Formular la estrategia de la entrevista. La estrategia significa ordenar el tipo de preguntas de acuerdo a los formatos posibles. Los dos formatos básicos son: preguntas abiertas (permiten al interlocutor brindar opinión libremente, sin restricciones, respecto a lo que se pregunta) y preguntas cerradas (limitan las opciones que tiene el interlocutor para responder). Ejemplos de preguntas abiertas: ¿Vd. cree que se cumplen los objetivos de este departamento? ¿Cree que los clientes están bien atendidos? Ejemplos de preguntas cerradas: ¿Cuántos análisis de cuentas ejecuta en una jornada? ¿Cuál es la prioridad de su trabajo? Los dos tipos básicos de preguntas ofrecen ventajas y desventajas. El coordinador del proyecto debe equilibrar el peso de cada tipo en el momento de formular su estrategia de entrevista.

Existen tres modelos distintos para estructurar la entrevista según el orden en que se formulen las preguntas:

(organización inductiva): se comienza formulando preguntas Modelo pirámide

de detalle (específicas) y cerradas y se continúa luego con preguntas abiertas que dan lugar a respuestas generales.

Modelo embudo (organización deductiva): se comienza con preguntas generales abiertas y luego se van estrechando las preguntas para obtener respuestas específicas (no generales).

Modelo rombo: es una combinación de las dos estructuras anteriores.

El coordinador del proyecto debe escoger el modelo que mejor se adecue al escenario y al momento en que ejecute.

Un enfoque alternativo a la entrevista de usuario de persona a persona (tal como se explicó más arriba) es el modelo denominado diseño conjunto de aplicaciones (JAD son sus siglas en inglés). Consiste en una entrevista grupal coordinada por el director del proyecto. Por supuesto que exige una rigurosa coordinación, como toda reunión de grupo.

El diseño conjunto de aplicaciones puede ser muy útil y efectivo si se cumplen determinadas condiciones. La efectividad se logra por la aptitud participativa



7

(proactiva) de los involucrados. Las opiniones del grupo, cuando se manifiestan, pueden enriquecer los resultados finales de ese tipo de entrevista. Las opiniones de muchos pueden ser mejores que las de uno solo.

Las condiciones que deben cumplirse para aspirar al éxito en este tipo de reuniones son entre otras: entusiasmo de los usuarios para lograr mejoras a través de cambios; cultura organizacional propensa a las reuniones; poco éxito de los resultados de entrevistas de persona a persona; posibilidad de que los involucrados puedan reunirse en un lugar y en un momento tal que no perturbe o demore sus tareas habituales.

El JAD disminuye el tiempo total dedicado a entrevistas; da participación a los usuarios en el diseño de un nuevo sistema; los motiva a participar (hay interacción); se generan nuevas ideas (brainstorming). Por el lado de las desventajas el JAD requiere una muy rigurosa preparación del conductor del proyecto (significa costo).

Cuestionario escrito

El cuestionario escrito, bajo la forma de un formulario específicamente diseñado tiene lugar cuando el universo a entrevistar es muy amplio o se encuentra distante geográficamente.

El cuestionario escrito puede ser utilizado como una herramienta aislada, para requerir información o conocimiento o bien como elemento predecesor de una futura entrevista (estudio exploratorio). En este último caso servirá para planificar la entrevista. Es conveniente tener en cuenta que ambas herramientas (entrevista y cuestionario) pueden ser complementarias una de otra y no necesariamente excluyentes.

El cuestionario puede servir para saber de qué manera los usuarios valoran el sistema actual, qué problemas se presentan en los procedimientos o decisiones en las que toman parte o qué desearían obtener como beneficio en la instalación de un nuevo sistema.

La redacción del cuestionario debe ser bien planificada. Si se esperan respuestas útiles a los fines de lo que se intenta conocer, las preguntas deberán ser redactadas con sumo cuidado y rigurosamente revisadas. Al igual que en la entrevista personal las preguntas pueden ser abiertas o cerradas. Pero además debe preverse el uso del lenguaje que se va a utilizar porque aquí no hay posibilidad de requerir aclaraciones por parte de quienes deben responder.

Los cuestionarios escritos suelen ser estructurados observando formatos especialmente diseñados. Uno de ellos es utilizar escalas. El escalamiento consiste en acompañar la pregunta con números o símbolos que se asignan a un atributo o característica. Las escalas pueden ser nominales, ordinales, de intervalo o de relación.



8

Las escalas nominales se aplican para clasificar cosas u opiniones. Por ejemplo una pregunta dentro de este modelo sería: “¿Cómo prefiere la salida de información? Marque 1 si prefiere por pantalla; marque 2 si prefiere por impresión”. Las respuestas sólo permiten una clasificación.

Las escalas ordinales si bien se aplican también para clasificar permiten además un ordenamiento de rango. Ejemplo: “La información sobre proyección de ventas sirve a los efectos de su actividad (marque la que considere corresponde en su opinión). 1. En todos los casos. 2. En muy pocas ocasiones. 3. En ningún momento”.

En las escalas ordinales no se puede deducir que los intervalos entre la numeración 1, 2, 3, sean iguales. En cambio en las escalas de intervalo su característica es que los intervalos entre valores son iguales. Ejemplo: “Marque de 1 a 5 la calificación que asignaría al nivel de confianza que le inspira el sistema de presupuestación (interprete que 1 indicaría poca confiabilidad y 5 confiabilidad total”.

Las escalas de relación agregan a lo indicado para las escalas de intervalo la numeración cero. O sea se aplican cuando puede presentarse una oportunidad de nulidad absoluta.

Muestreo

Una muestra es una parte representativa de un universo. El muestreo consiste en seleccionar, a través de un método, esa parte representativa. La intención del muestreo es analizar los elementos seleccionados y obtener conclusiones sobre los mismos, que serán generalizadas respecto al universo. En el caso del desarrollo de un sistema de información se puede efectuar un muestro seleccionando parte de las personas afectadas por el sistema en estudio y parte de la documentación (bajo forma de informes, formularios y otros medios de comunicación).

El muestreo es útil cuando el universo a analizar es grande y por tanto resultaría lento y costoso el proceso de recopilación de requerimientos de información si se accediera a la totalidad de los componentes del universo.

Para obtener una muestra exitosa deben cumplirse los siguientes pasos.

1. Definir qué tipo de información se intenta obtener. Seleccionar la información que sea relevante para el estudio a efectuar.

2. Determinar cuál es la población a entrevistar (será aquélla afectada por el estudio).

3. Seleccionar el modelo de muestra adecuado. Existen varios tipos de muestras, de manera que deberá seleccionarse el tipo más adecuado en



9

función de la información que se busca y de la conformación del universo a investigar. Si el universo está compuesto por elementos homogéneos podrá seleccionarse una muestra aleatoria simple. La condición es que todos los componentes del universo tengan la misma oportunidad de ser seleccionados. Si el universo es heterogéneo (sus componentes tienen marcadas diferencias) se utilizará una muestra estratificada. La estratificación es el proceso de dividir el universo en estratos o subpoblaciones y luego tomar muestras dentro de cada estrato.

4. Determinar el tamaño de la muestra. Depende de varios factores, entre ellos las características del universo. Si la variación entre los extremos es pequeña (por ejemplo entre 10000 y 15000) un tamaño pequeño de muestra será suficiente. Si la oscilación es grande (ejemplo entre 1000 y 100000) se requerirá una muestra más numerosa.

Estudio de antecedentes

Algunas empresas pueden disponer de registros tales como manuales de políticas, de organización o de procedimientos estándares. Estos manuales o reglamentos suelen tener como objetivo servir de guías para los gerentes y demás componentes de la organización. Deben ser leídos con precaución por parte de quienes buscan información de requerimientos pues no es totalmente seguro que la realidad de las operaciones aplique exactamente las normas contenidas en dichos manuales. De todas maneras pueden servir de antecedente para comprender y familiarizarse con los sistemas involucrados en el proyecto en desarrollo.

El contenido de los documentos impresos debe ser examinado tanto cualitativa (caso de los manuales) como cuantitativamente. Dentro de la documentación a revisar se encuentran registros estadísticos (sobre ventas, inventarios, planes de producción, etc.) que servirán como información para marcar tendencias. También servirán para posibilitar la comparación entre lo planificado y lo realizado, y a partir de ahí consultar a los responsables qué acción se toma respecto a las desviaciones.

Además interesará recolectar los distintos tipos de formularios en uso, tanto antes de ser cubiertos con datos como después de ser llenados. Esto permitirá conocer cuáles son los datos básicos de la empresa a partir de los cuales se generan los procesos.

La lectura de información financiera y estadística puede ser útil en la medida en que se trata de datos relevantes. En este caso será conveniente determinar cuál ha sido el destino o destinatario de esa información.



10

Observación personal

La observación personal como técnica de recopilación de requerimientos apunta a tener una visión directa de un escenario de trabajo, evitando la intervención de terceras personas. La observación permite apreciar lo que se hace realmente (no lo que “dicen que hacen”) y cómo lo hacen. En algunos casos se puede utilizar la técnica de muestreo y de tiempo o eventos para observar actitudes y decisiones (Por ejemplo cuánto tiempo demora solucionar un problema planteado por un cliente).

Diagnóstico

Luego de completado el Relevamiento se debe estar en condiciones de formular un diagnóstico. Esto significa apoyarse en los signos detectados durante el relevamiento y formular un esquema que especifique las falencias u omisiones observadas respecto al sistema estudiado y ofrecer opciones de solución .El diagrama siguiente muestra las opciones posibles.

Etapa 3: Diseño Lógico

Cuando el diagnóstico que surge de un relevamiento de sistemas indica que los sistemas vigentes no cumplen los objetivos planteados en el plan maestro de sistemas de información, debe plantearse la necesidad de formular un nuevo diseño de un sistema. Para hacer mejor comprensibles los elementos



11

que integran el diseño, es conveniente (tal como se ha hecho en esta presentación) dividir el diseño en dos partes, a las que denominamos diseño lógico y diseño físico, y con mayor precisión ingeniería de software a este último.

Para explicar diseño lógico debemos recordar que todo sistema de información se compone de las partes que se muestran en el siguiente esquema (a lo que habría que agregar los procedimientos para ejecutar el sistema y las comunicaciones).

Diseño de salida

Es probable que lo primero que habrá de diseñar sea la salida de información dado que es el objeto y producto final del sistema. A partir de la salida se definirán los requerimientos de entrada de datos y de la base de datos, como así también los procedimientos para convertir la entrada en salida.

La salida se puede expresar a través de diversos medios: documentos impresos, despliegue de mensajes en pantalla, almacenamiento de datos en archivos y bases de datos, sonido, microformas, transmisión a distancia.

Un diseño eficaz de salida debe cumplir los siguientes requisitos:

1. Ajustarse a los requerimientos formulados en la etapa respectiva.

2. Asegurar que esté disponible en tiempo oportuno.

3. Asegurar que se encuentre en el lugar donde se la necesite.

4. Asegurar que se utilice el medio más adecuado.

El diseño de salida debe reconocer que existe un diccionario de datos donde han quedado definidos los nombres de los elementos de datos así cono la longitud del campo requerida para cada entrada.



12

La salida impresa debe cumplir determinados lineamientos. Para ejecutar el diseño se utilizan formularios (hojas de diseño) en los que los diseñadores deberán indicar (a través de convenciones) los lugares específicos de ubicación de títulos de los reportes, subtítulos, encabezamiento de columnas, tipo de dato (alfabético, numérico o carácter especial, por ejemplo signo $) indicación de importes totales o subtotales (por ejemplo mediante utilización de asteriscos), espacio en blanco entre columnas, número de página, fecha de impresión.

El diseño en pantalla difiere significativamente de la salida impresa. La situación actual de la economía aconseja la utilización de pantalla como medio de salida en razón de su menos costo, pero la pantalla es efímera y no es portable, y esto debe ser considerado. También debe tenerse en cuenta que la capacidad de información a contener en una pantalla es limitada.

El diseño de pantallas también debe observar ciertos lineamientos:

1. Debe ser de fácil lectura (el orden de los datos debe ayudar a quien busca información).

2. La información que se presenta debe ser consistente de pantalla a pantalla.

3. La información debe presentarse en forma tabular o en forma gráfica según mejor convenga a los usuarios.

4. Debe posibilitar el uso de ventanas para hacer más rápidamente asequible la búsqueda de información (sin tener que salir totalmente de la aplicación en proceso). Se seleccionará el tipo de ventana más conveniente para el usuario: tipo mosaico o tipo cascada)

5. Definir el desplazamiento (avance o retroceso de pantalla).

La salida en pantalla suele resultar útil en los sistemas de información que fueron diseñados para dar apoyo a tomadores de decisiones (DSS) dado que ayudan al decididor a interactuar con el sistema (generalmente este es flexible y modificable). Este atributo no es tan importante para la salida de un MIS tradicional (decisiones estructuradas).

Diseño de entrada

Un buen diseño de entrada es fundamental para obtener una buena salida. Además el diseño de entrada determina si el usuario puede interactuar con el sistema de manera eficiente.

El diseño de entrada consiste en especificar las formas y procedimientos para la preparación de los datos y la incorporación de los mismos (sin errores u omisiones) a un procesamiento.

La entrada de datos debe satisfacer varios objetivos:



13

* Efectividad: debe servir a los propósitos del sistema.

* Exactitud: ser el fiel reflejo de una realidad.

* Amigabilidad y simplicidad: el diseño de entrada debe facilitar la incorporación directa de datos sin dudas y evitar el rechazo por parte de los usuarios.

* Consistencia y coherencia: los medios de entrada deben tener formato similar dentro de un mismo sistema.

Es particularmente importante la estructura (formato) del formulario que servirá a los efectos de entrada. El mismo debe ser “conductivo”. Esto es orientar al usuario en el momento de cubrir los datos en los casilleros asignados. En el caso de un formulario electrónico (por pantalla) la pantalla debe especificar tres secciones separadas para simplificar la interacción con la misma. La parte superior será el “encabezamiento” en el que se mostrará el tipo de transacción y la identificación de la etapa del proceso (puede incluir menús desplegables). La sección media es el “cuerpo” cuyo contenido serán los campos a cubrir con su respectiva denominación. La sección inferior puede incluir un menú con indicación de comandos e instrucciones de operación para el usuario. El uso de pantallas para el llenado de datos permite hacer uso de ventanas, conforme se vayan necesitando a medida que avanza la entrada.

El diseño de entrada de datos se formaliza a efectos de asegurar una precisa y eficiente captura de datos. Además de un diseño eficiente la captura de datos requiere la observación de otras exigencias:

1. Criterios de codificación: los códigos son formas de identificación y representación de sujetos, conceptos, transacciones, objetos o fenómenos que deben ser registrados, procesados y almacenados. Una buena codificación permite también efectuar un ordenamiento de los conceptos que representan, en el momento en que se requiera.

2. Proceso de captura: existen dos tipos de datos a capturar: los que representan novedades (o nuevas transacciones) y que por lo tanto cambian con cada transacción, y los datos que permiten identificar y diferenciar el concepto que será procesado del resto de conceptos (se les llama llave o clave). Por ejemplo el código de cliente identifica y diferencia a un cliente del resto de la cartera de clientes; mientras que la cantidad de producto a comprar por un cliente en cada transacción será cambiante en cada oportunidad. El código de clientes es un dato constante que habitualmente no cambia con frecuencia y cuya calidad (exactitud) deberá ser constatada en cada ocasión contra una tabla que contenga todos los códigos incorporados a la cartera de clientes. La “cantidad” deberá ser sometida a otra forma de control. Se dispone de varios medios de captura de datos cuya elección dependerá de factores diversos tales como: costo, velocidad, precisión. Los medios más usados son: teclado, reconocimiento óptico de caracteres (OCR),



14

reconocimiento de caracteres de tinta magnética (MICR), marcas sensibles, lectura de código de barras, terminales inteligentes.

3. Validación de entrada: consiste en analizar los datos que intentan ingresar a un proceso y detectar los errores u omisiones que acarrean antes de almacenarlos o procesarlos. Para ello se cumplen dos etapas: a) verificación de la transacción; b) verificación de los datos de la transacción.

a) El análisis de la transacción responde a la necesidad de evitar que ingrese al proceso una transacción que no corresponda al mismo, o que provenga de una terminal o un usuario no autorizado, o bien que sea incompleta (que falte algún registro dentro de un lote) o que los registros no respeten una determinada secuencia de presentación.

b) La verificación de los datos de la transacción se efectuará incorporando varias pruebas al software:

- Prueba de existencia: consiste en determinar si todos los campos que deben contener datos obligatoriamente, cumplen con esta condición.

- Prueba de clase: verifica si los campos que deben ser numéricos son tales y si los que deben ser alfabéticos lo son.

- Prueba de extensión del campo: controla que cada campo dentro de cada registro mantenga la longitud definida al diseñarse el sistema.

- Prueba de límites y rango: compara la entrada con parámetros predeterminados; aplica el criterio de la razonabilidad; validan límites mínimos y máximos.

- Prueba de existencia de datos almacenados: compara un número que intenta ingresar a proceso con el contenido de un campo de datos ya almacenados y verifica su igualdad. Por ejemplo un código de cliente que intenta comprar en cuenta corriente debe corresponderse con ese código ya almacenado en el archivo de clientes.

- Prueba de dígito de verificación: se trata de un dígito (a veces dos) que se agrega al número base para verificar si no se produjo un error de transcripción al intentar ingresar un dato al proceso.

Diseño del proceso

Es frecuente que se utilicen las herramientas del análisis estructurado para diseñar la forma en que los datos de entrada se convierten en salida (en algunos casos con intervención de la base de datos). Las herramientas de aplicación son: diagrama de flujo de datos (DFD), diccionario de datos (DD), tablas de decisión, árboles de decisión, lenguaje estructurado.



15

Etapa 4: Ingeniería de software (Diseño físico)

La ingeniería de software tiene su antecedente en la actividad anteriormente denominada programación de computación. Pero la programación era libre en el sentido de que en un principio los programadores elaboraban las instrucciones de programas de acuerdo a su saber pero sin observar reglas o normas uniformes u homogéneas.

La ingeniería de software introdujo estándares en la actividad de construir programas. Logró homogeneizar la profesión. Los principios que han servido de guía son los siguientes:

* Fragmentación y modularidad: Los sistemas deben subdividirse en módulos lógicos y manejables en forma tal que cada módulo cumpla una determinada función. De esta manera, frente a la necesidad de revisar una parte del programa no será necesario recorrer todas las instrucciones para detectar aquella(s) que deberá(n) ser corregida(s) o modificada(s). Los módulos serán más fáciles de escribir y de depurar. Un problema en un módulo no debe causar problemas en otro. Se aplica el método descendente que significa identificar primero las funciones y a partir de allí se desarrolla cada función con mayor detalle (desde lo general a lo particular).

* Nivel de acoplamiento: El acoplamiento se refiere al nivel de dependencia de un módulo respecto a otro. Un buen diseño estructura que un módulo tenga poca dependencia de otro. Esto se logra evitando transferir datos innecesarios de un módulo a otro durante un proceso. Por ejemplo habrá exceso de acoplamiento si en un proceso de pago a proveedores desde un módulo se transfieren a otro módulo los siguientes datos: código de proveedor, razón social, dirección, fecha, CUIT; un acoplamiento correcto sería mediante la transferencia del código de proveedor solamente (se mueven menos datos).

* Cohesión: Se refiere a las fuerzas de las relaciones dentro de un módulo. Dentro de cada módulo se debe cumplir una función específica. Por ejemplo resulta lógico que un módulo procese todas las operaciones de entradas o bien todas las operaciones de salida.

* Cantidades de módulos subordinados: Cada módulo debe controlar un número limitado de módulos subordinados. Ese número gira en torno de la media docena.

* Cantidad de instrucciones contenidas en un módulo: Si bien no existe un número fijo puede considerarse que alrededor de cincuenta instrucciones es una cantidad prudente para integrar cada módulo.

* Uso compartido: En ciertos procesos pueden existir módulos que pueden ser utilizados al ser llamados desde varios módulos. Por ejemplo en ciertas rutinas de cálculo. Se evita así el esfuerzo innecesario de escribir y probar varias veces las mismas instrucciones.



16

Etapa 5: Prueba del sistema

Es una etapa importante desde el punto de vista de la satisfacción del control y confiabilidad del sistema cuando éste se instale en operación.

Se ha manifestado que una prueba es exitosa cuando a través de ella se detectan errores u omisiones antes de la puesta en marcha de un sistema.

Tipos de pruebas

Las pruebas se clasifican en generales y en especiales o específicas. Las pruebas generales se desarrollan por niveles. Se explicó al tratar “Ingeniería de software” que uno de los estándares que se aplica para la elaboración de programas es la “fragmentación y modularidad”. Precisamente el primer nivel de prueba es sobre cada uno de los módulos de cada programa integrante del proyecto. Luego de corregidas las falencias de cada módulo (si las hubiera) se probarán estos en conjunto y en el orden lógico de corrida del programa al que pertenecen. De esta manera se verificará que los módulos ensamblan (se acoplan) adecuadamente dentro del programa (podría generarse una incoherencia si, por ejemplo en un programa de liquidación de jornales un módulo que calcula el jornal bruto arroja un resultado de siete dígitos mientras que el módulo que le sigue secuencialmente recoge este dato (salida de un módulo y entrada al siguiente) para calcular el jornal neto para el cual asignó un campo de entrada de seis dígitos).

Luego de probado el programa (segundo nivel de prueba) debe probarse el sistema al cual pertenece el programa (tercer nivel). Recordemos que un sistema de información se compone de hardware, software, datos, información, procedimientos y recursos humanos. Todos esos elementos deben funcionar armónicamente para que constituyan un sistema. La prueba del sistema consistirá en ejecutar los programas en el orden asignado, en el equipamiento instalado y por las personas designadas cumpliendo los procedimientos diseñados.

Independientemente de las pruebas que se ejecutan suponiendo un proceso en un ambiente normal, también deben considerarse situaciones de excepción, de posible presentación en la vida activa de una empresa. De allí surge la necesidad de aplicar pruebas especiales que se explican a continuación.

* Prueba de capacidad de almacenamiento: En el momento del diseño de un sistema debe preverse cuáles son las expectativas en relación a la capacidad que es necesario reservar en los archivos magnéticos para evitar que, luego de instalado el sistema puedan generarse problemas de insuficiencia de capacidad. Esta se mide en cantidad de registros que un archivo pueda albergar y en función de la dimensión de cada registro. El diseñador del sistema debe prever la tendencia en cuanto a incremento de transacciones



17

que puedan operarse a medida que transcurra el tiempo, durante la vida útil del sistema.

* Prueba de tiempo de ejecución: El diseñador debe prever y probar el tiempo que tardará el sistema, cuando esté operando, en responder a una consulta, en actualizar un archivo, en transferir información, en procesar una rutina, en indexar o reordenar archivos del tamaño del que se prevé que se generará en el sistema, en efectuar copias de respaldo y en ejecutar el resto de las operaciones previstas en el sistema. Puede ocurrir que un sistema bien diseñado en cuanto a la definición de requerimientos resulte poco útil en razón de la lentitud en su ejecución.

* Prueba de funcionamiento a full: Puede ocurrir que un sistema funcione bien mientras el servidor sea requerido (a través de peticiones) por un número limitado de terminales. Pero debe preverse mediante pruebas reales “qué pasaría si todas las terminales (suponiendo un número importante de éstas) necesitaran operar simultáneamente con el servidor”.

* Prueba de la documentación: La aplicación de herramientas CASE ayuda a documentar (mantener registrados los detalles de los procedimientos) de las aplicaciones de computación, pero en algunos casos esas herramientas no se utilizan. En otros casos los detalles de procedimientos no están suficientemente descriptos (faltan opciones) o bien no son claros. Debe, por lo tanto, probarse si los usuarios del sistema, apoyándose en la ayuda de la documentación pueden ejecutar las transacciones con la precisión y en la oportunidad necesaria. Es necesario cerciorarse de la compatibilidad entre lo manifestado por los manuales u otras formas de documentación y las acciones que realmente deben ejecutarse para que el sistema funcione conforme a lo requerido.

* Pruebas del plan de emergencia: Todo sistema debe tener incorporado un plan de emergencia para cubrir las situaciones que pueden presentarse en las que un sistema tenga fallas o sufra pérdida de datos o no cumpla la ejecución de operaciones. Estas situaciones de excepción también deben probarse. Esto significa verificar de qué manera proceden los usuarios cuando deben reemplazar sus operaciones habituales por otras que deberán aplicar para evitar la paralización de la operatoria administrativa.

* Prueba de reacción del usuario ante situaciones no previstas (no en caso de emergencias): Aun en corridas normales, sin que ocurra una falla del sistema, el usuario se puede encontrar en dificultades cuando se produce una demora extendida durante un proceso sin que la pantalla indique referencia alguna. La prueba consistirá en estas situaciones en averiguar cómo reaccionaría un usuario cuando durante un proceso no ocurre lo que habitualmente debe ocurrir. El diseño del sistema deberá prever que se indique por pantalla cuánto tiempo se estima que durará un proceso normal y cómo proceder en caso de una duración mayor.



18

Elementos de prueba

Las pruebas de los sistemas en sus diversos niveles se efectúan con datos de prueba. Para ello las pruebas deben ser diseñadas. Se utilizan dos fuentes de datos: datos reales y datos ficticios o artificiales.

Una secuencia razonable a aplicar en un proceso de prueba es la que se indica a continuación.

1. Prueba de escritorio de los módulos de cada programa con datos ficticios: Esta parte es responsabilidad del programador quien debe efectuar una “prueba de escritorio”. Consiste en verificar cada paso del módulo en papel para revisar si la rutina cumple la secuencia lógica tal como fue requerida.

2. Prueba de los módulos en el equipo con datos ficticios: Los programadores deben generar datos ficticios, algunos válidos (sin errores) y otros con errores (expresamente diseñados) para exigir y observar la reacción del módulo frente a cada caso (revisar la calidad de la salida y decisión de rechazo de los datos no válidos).

3. Prueba de cada programa: Luego de verificar la calidad del procesamiento de cada módulo se debe probar su conjunto dentro del programa. Esto significa probar el programa en su integridad, principalmente observar el enlace o acople de los módulos entre sí. También se efectuará con datos ficticios de prueba.

4. Prueba de programas en cadena: Luego de probado cada programa en forma individual se debe probar la coherencia en la interdependencia de los programas entre sí. Los datos ficticios para esta prueba deben ser diseñados por el director del proyecto quien debe prever la revisión de todas las opciones o situaciones que se pueden presentar en las situaciones reales que atenderán estos programas.

5. Prueba completa del sistema con datos ficticios: Esta etapa requiere que se vea al sistema como una entidad, integrada no sólo con programas (que deben funcionar bien) sino que también actúan personas y procedimientos. Es el momento de probar el objetivo y el alcance del sistema. En esta etapa actúan operadores (o asesores informáticos) usuarios finales y el director del proyecto. Esta prueba deberá revisar cómo fluye la información, si la salida es la esperada, si los tiempos de ejecución son razonables, si la entrada de datos y la base de datos han sido bien diseñadas en función de la salida, si los usuarios han comprendido su nuevo rol (como generadores de datos y como receptores de información) y si la documentación es adecuada y completa (precisión técnica).

6. Prueba completa del sistema con datos reales: Luego de haber satisfecho las pruebas anteriores corresponde efectuar un prueba completa, esta vez con datos reales (aquellos que se extraen de los archivos de la organización). La



19

razón por la cual se utilizaron hasta ese momento los datos ficticios fue la de asegurar cubrir todas las posibilidades o alternativas que podrían presentarse respecto al sistema en las corridas reales (tal vez en una corrida real en un lapso corto no se presentarían todas esas posibles alternativas). Los “datos reales” son aquellos que han sido procesados en el sistema anterior al que ahora se analiza. Esto permite efectuar una comparación precisa entre la salida ya conocida y la que ahora se obtendrá como nueva. Obviamente esta prueba no es posible cuando se crean salidas completamente nuevas. El uso de datos reales permitirá también llevar tranquilidad a los afectados por el proyecto en el sentido de no apoyar la prueba en un criterio exclusivamente teórico.

El o los usuarios de mayor nivel involucrados en el proyecto, junto con el director del mismo, deben finalmente aprobar el proyecto pata que este se convierta a partir de la fecha previamente designada en producto ejecutable.

Etapa 6: Implementación. Métodos de conversión

La implementación (o instalación) comprende las actividades necesarias para convertir el sistema vigente hasta ese momento, al nuevo sistema ya diseñado, programado, probado y aprobado.

La implementación comienza con la planificación de la implementación. Definiremos tres momentos en el tiempo:

t0: momento en que el sistema fue aprobado

t1 : momento en que se produce la conversión

t2 : momento en que se discontinúa el sistema anterior (en caso de que no hubiera sido discontinuado en t1).

Entre t0 y t1 se cumple la fase de planificación de la implementación. En este espacio de tiempo se procede a capacitar a quienes quedarán involucrados en el sistema (usuarios y operadores). Estos deberán estar en condiciones de conocer cómo deberán actuar frente al sistema, conocer sus roles, responsabilidades, límites de tiempo que impone el sistema y cómo usarlo y aprovechar sus ventajas en todas sus fases.

También en este lapso deberá verificarse que los nuevos formularios estén impresos, distribuidos, conocidos e interpretados por los usuarios. Se revisará el funcionamiento de los equipos y la compatibilidad entre el hardware y el software (puede ocurrir que el software haya sido preparado en otros equipos; habrá que revisar ahora cómo opera en el hardware propio).

Llegado el momento t2 se procederá a la conversión. La conversión es el proceso de migrar desde el sistema anterior al sistema nuevo. t2 es un



20

momento crucial porque ante todo deben convertirse los archivos viejos a los archivos nuevos. Se deberán preparar programas especiales para esta ocasión. Se supone que la empresa no puede paralizar sus actividades rutinarias por esta circunstancia. Sin embargo la conversión de archivos insume tiempo y exige controles muy especiales a fin de evitar pérdida de datos o tergiversación de la información (items de cuentas corrientes, existencia de inventarios, pedidos y órdenes de compra pendientes, etc.) que pasa al nuevo sistema. La verificación de auditoría durante este proceso es fundamental.

Existen varios métodos de conversión. Todos tienen ventajas y desventajas. La política de la empresa fijará cuál es el mas conveniente para cada ocasión. Se explican a continuación.

* Conversión en paralelo: Se ejecutan el sistema anterior y el nuevo durante cierto período en forma simultánea. Luego se comparan los resultados, los que definirán el nivel de confiabilidad en el nuevo sistema. El sistema anterior se discontinúa cuando la confiabilidad en el nuevo es total. La ventaja de este sistema es disponer de un recurso (el sistema anterior) si el nuevo arroja fallas. La desventaja es el tiempo y el costo de procesar (cargar) dos veces las mismas operaciones, a lo que se agrega el esfuerzo de comparar ambos resultados. Además puede ocurrir, y de hecho ocurre, que el nuevo sistema provea un formato y contenido de salida distinto del que suministró el sistema anterior.

* Conversión directa: Significa que en el momento en que se pone en marcha el nuevo sistema se discontinúa el anterior (momento t1). En este caso el éxito del nuevo sistema está apoyado por la rigurosidad con que se efectuó la prueba. No existe en esta forma la posibilidad de recurrir a los resultados del anterior para compararlos con lo del nuevo. La conversión directa podrá aplicarse cuando se trate de proyectos que no afecten a terceros (clientes, proveedores, instituciones bancarias, organismos de control) pues una falencia frente a ellos crearían una situación complicada para la imagen y gestión de la empresa.

* Prueba piloto: Consiste en aplicar el nuevo sistema en algún sector (sucursal, departamento, sección) de la empresa y observar los resultados. Conforme se vaya ganando en confiabilidad en el nuevo sistema éste se hará extensivo al resto de los sectores.

* Conversión por etapas: Si no es posible instalar el sistema completo en un mismo momento se instalará por partes. Esta forma exige una adecuada coordinación para hacer coherente la conexión temporaria entre la parte nueva y las partes del sistema anterior. El esfuerzo es grande y debe preverse.



21

Etapa 7: Mantenimiento y evaluación

Los sistemas, al igual que otras entidades, requieren de mantenimiento. El mantenimiento significa efectuar ajustes, correcciones o modificaciones de poca envergadura sobre partes del sistema. Se subraya la condición de que las correcciones o cambios no sean de gran importancia, porque de lo contrario no se trataría de mantenimiento sino de un nuevo diseño y en consecuencia del desarrollo de un nuevo sistema (nuevo ciclo de vida).

Los cambios pueden surgir para satisfacer nuevos requerimientos internos (ejemplo: modificación de un cálculo financiero, incorporación de una nueva línea de productos o de canal de comercialización, etc.), o bien debido a situaciones externas (aplicación de un nuevo impuesto, nuevos requisitos legales, exigencia de la competencia, etc.).

Si bien es cierto que le tiempo dedicado al mantenimiento es algo inevitable (por las razones expuestas más arriba) debe enfatizarse la necesidad de reducir ese tiempo al mínimo posible. Para ello es fundamental atender a la aplicación de los conceptos de calidad total en el desarrollo de todas la etapas que forman parte del ciclo de vida de los sistemas de información. Si se descuida la observación de esa premisa ello repercutirá en un tiempo de dedicación excesiva al mantenimiento.

La evaluación debe practicarse con frecuencia periódica (por ejemplo cada seis meses) y consiste en determinar si el sistema continúa cumpliendo el objetivo que le dio origen, si los usuarios ha mejorado su performance y si las decisiones que se toman y las operaciones que se ejecutan tiene su base en la información que provee el sistema en estudio (nivel de precisión de la información, oportunidad de presentación, formato o forma de exposición, facilidad de uso, confiabilidad en el sistema, precisión en la validación de los datos de entrada, tiempo de proceso).

La evaluación del sistema puede efectuarse por medio de varios métodos, entre ellos encuestas a los usuarios (son subjetivas: los usuarios opinan sobre qué grado de satisfacción laboral y eficiencia encuentran en la aplicación del sistema); registro de incidentes críticos (de tipo técnico: cantidad de veces que el sistema falló, demora en reiniciar procesos, pérdida de información, imposibilidad de atender situaciones reales por inflexibilidad del sistema); impacto sobre la organización (nivel de mejora en la integración de las actividades, aumento de productividad, análisis de costos y beneficios económicos).

Sistemas y métodos administrativos

Education

Transcript of Sistemas y métodos administrativos