sistemas de informacion i

Sistemas de Información I

CAEDI – Centro de Altos Estudios de Informática 97

TEXTOS


CAEDI - Centro de Altos Estudios de Informática

98



Texto 1

La información como recurso Desarrollo y administración El análisis y diseño de sistemas computarizados aplicados a las organizaciones es un campo estimulante y de gran dinamismo. Conforma se difunde con gran rapidez, el uso de computadoras dentro de las organizaciones, surgen muchas inquietudes acerca de la forma de usarlas para mejorar la productividad y lograr mejor los objetivos de la organización. Los analistas de sistemas con frecuencia se enfrentan a estas cuestiones y por lo tanto están obligados a entender al usuario potencial y a las computadoras, para integrar un mejor diseño de los sistemas de información. Mas aun, el analista debe aprender a desarrollar y a mantener las relaciones de trabajo con las personas del equipo responsable del análisis de sistemas. La información como un recurso de las organizacione s De tiempo atrás, las organizaciones han reconocido la importancia de una administración adecuada de los recursos básicos, tales como la mano de obra y las materias primas. Los responsables de la toma de decisiones empiezan a considerar que la información ya no es un producto exclusivamente colateral de la operación de la empresa, sino que en sí, es uno de los promotores de la misma. La información puede llegar a ser el elemento decisivo, que en un momento dado, determine el éxito o el fracaso del negocio

• El recurso de la información es fundamental para lograr el éxito del negocio, sin importar el tipo de negocio que uno realice.

Administración de la información como recurso Con el fin de lograr la máxima utilidad de la información, esta debe administrarse de manera correcta, como ocurriría con cualquier otro de los recursos de la empresa. Los directivos deben entender que existen costos que se asocian con la producción, distribución, seguridad, almacenamiento y recuperación de la información. Aunque la información aparentemente se encuentra siempre a nuestro alcance, su uso estratégico como un apoyo de la competitividad de nuestro negocio no debe considerarse como un elemento gratuito.



100

Administración de la información generada por compu tadora La disponibilidad actual de las computadoras ha generado un incremento y diversificación de la información, tanto para la sociedad en general como para los negocios en particular. La administración de la información que se genera por computadora, difiere de aquella que se obtiene manualmente. A menudo, se tiene una mayor cantidad si ésta se genera utilizando sistemas computarizados. Si bien los costos para crear y mantener la información son aparentemente mayores, la información que la computadora genera puede llegar a multiplicarse a velocidades impresionantes.

• Con frecuencia la información que se genera por computadora se trata con menos escepticismo que la obtenida por otros medios.

• La información generada por computadora permite el acceso a la misma con

mayor precisión y velocidad Concepto de Análisis y diseño de sistemas: Los sistemas se desarrollan con diferentes propósitos, los cuales dependen de las necesidades de la empresa. Dentro de los diferentes sistemas podemos definir los siguientes: Sistemas de Procesamiento de Datos Los sistemas de procesamiento de datos son aquellos sistemas de información computarizados que se desarrollan para procesar grandes volúmenes de información generada en las funciones administrativas. Los sistemas de procesamiento de datos liberan del tedio y la rutina a las tareas que se realizan manualmente, aunque, el elemento sigue participando, al llevar a cabo la captura de información requerida. Estos sistemas ejecutan periódicamente los programas de manera automática. Una vez preparados, rara vez se requiera el tomar decisiones.

• Los sistemas de procesamiento de datos ejecutan las actividades de carácter rutinario de las empresas. Estos sistemas son dirigidos al procesamiento de grandes volúmenes de información.



Sistemas Informáticos para la administración Los sistemas de información para la administración no sustituyen a los sistemas de procesamiento de datos, en líneas generales todos los sistemas toman en cuanta a las funciones de procesamiento de datos. Los sistemas de información para la administración, son sistemas que se sustentan en la relación que surge entre las personas y las computadoras. Estos sistemas requieren para su operación de: las personas, del software y del hardware. Estos sistemas soportan un amplio espectro de tareas de las organizaciones, incluyendo además el análisis y la toma de decisiones. Los usuarios de este tipo de sistemas, utilizan una base de datos compartida para tener acceso a la información. Dicha base de datos almacena, tanto datos como modelos que ayudan al usuario en la interpretación y el uso de la información.

• Los sistemas Informáticos para la administración, proporcionan informes periódicos para la planeación el control y la toma de decisiones

• Los sistemas generan la información que eventualmente se utiliza en la toma de

decisiones Sistemas de apoyo para la toma de decisiones El sistema de apoyo para la toma de decisiones es un tercer tipo de información computarizada. Este sistema es similar a los sistemas de información tradicionales para la administración, en el sentido de que ambos dependen de una base de datos como fuente de información, pero se distingue del sistema de información para la administración, al hacer énfasis en el soporte en cada una de las etapas de la toma de decisiones. Sin embargo, la decisión en sí, depende de la persona responsable de la misma. Los sistemas de apoyo para la toma de decisiones se diseñan con una orientación hacia la persona o el grupo que los utilizará, y no como los sistemas de información tradicionales para la administración.

• Los sistemas de apoyo para la toma de decisiones, ayudan a quien toma las decisiones, cuando le proporcionan la información que solicita.

Sistemas expertos e inteligencia artificial Podemos considerar a la Inteligencia Artificial, como el campo principal de los sistemas expertos. La idea central de la inteligencia artificial es llegar a desarrollar máquinas que cuenten con un desempeño inteligente.



102

La inteligencia artificial tiene dos áreas de investigación: el lenguaje natural y la habilidad para interiorizarse racionalmente en los problemas hasta alcanzar su conclusión lógica. Los sistemas expertos utilizan los enfoques del razonamiento de la inteligencia artificial para resolver aquellos problemas que algún sector le propone. Los sistemas expertos son en sí, un tipo muy especial de sistemas de información, que tienen un uso práctico en los negocios debido a la reciente y amplia disponibilidad de hardware y de software. Un Sistema experto, captura, y en efecto utiliza. El conocimiento de un experto, para la solución de un problema particular de la organización. A diferencia del sistema de apoyo para la toma de decisiones, que finalmente deja al responsable que tome las decisiones, un sistema experto selecciona la mejor solución al problema o al tipo específico de problemas. Los llamados ingenieros del conocimiento captan el conocimiento de los expertos en un área específica, construyen un sistema computarizado para contener tales conocimientos y finalmente, lo implantan. Es muy probable que el trabajo futuro de muchos analistas de sistemas, se oriente hacia la construcción e implantación de sistemas expertos.

• Los Sistemas expertos asimilan la experiencia de quienes toman las decisiones en la solución de problemas

Necesidad del análisis y diseño de sistemas : El análisis y el diseño de sistemas, tal como lo realizan los analistas de sistemas, pretenden estudiar sistemáticamente la operación de ingreso de los datos, el flujo de los mismos y la salida de la información; todo ello dentro del contexto de una empresa en particular. El análisis y el diseño de sistemas sirve para analizar, diseñar y fomentar mejoras en la operación de la empresa, lo cual puede realizarse mediante el uso de sistemas de información computarizados. Si un sistema se instala sin un planeamiento adecuado, es muy probable que no sea satisfactorio y después quede en el olvido. El proceso de análisis y diseño de sistemas, permiten estructurar el costoso esfuerzo de la implantación de los sistemas de información que de otra manera ocurrirían de forma azarosa. El proceso de análisis y diseño de sistemas se conforma de una serie de procesos, que al ejecutarse sistemáticamente mejoran la operación de un negocio, mediante el uso de los sistemas de información computarizados.



Es fundamental la colaboración con los usuarios actuales o eventuales de tales sistemas de información, para lograr un resultado efectivo

• Debemos destacar la importancia del proceso de análisis y diseño de sistemas, para que los mismos sean efectivos y no caigan en desuso por falta de planificación.



104



Texto 2

Ingeniería de sistemas basados en computadora La ingeniería de sistemas consiste en la actividad de especificar, diseñar, implementar, validar, distribuir y mantener sistemas como un todo. Los ingenieros de sistemas no sólo están relacionados con el software, sino también con el hardware y las interacciones del sistema con los usuarios y su entorno. Estos profesionales deben pensar acerca de los servicios que los sistemas proveen, las restricciones bajo las cuales se construyen y operan y las interacciones del sistema con su entorno. Existen muchas definiciones posibles de un sistema que van desde las muy abstractas, hasta las concretas, pero una definición útil es:

• Un sistema es una colección de componentes interrelacionados que trabajan conjuntamente para cumplir algún objetivo

Una característica de los sistemas es que las propiedades y el comportamiento de los componentes de los sistemas están inseparablemente entremezclados. El funcionamiento exitoso de cada componente del sistema depende del funcionamiento de otros componentes. El software puede funcionar si el procesador es operacional; el procesador sólo puede hacer cálculos si el sistema de software que defina las operaciones se ha instalado de manera exitosa. Por lo general los sistemas, son jerárquicos, ya que incluyen dentro de sí otros sistemas. Estos otros sistemas se denominan subsistemas. Una características de estos, es que pueden operar de manera independiente. Por lo tanto un mismo subsistema, puede utilizarse en diferentes sistemas. Sin embargo su comportamiento depende, en particular de la relación con otros subsistemas. La compleja relación entre los componentes de un sistema, significa que este último, es mucho más que una simple suma de sus partes. Tiene propiedades, que son propiedades de los sistemas como un todo. Estas propiedades se denominan propiedades emergentes , las cuales no pueden ser atribuidas a ninguna parte del sistema; emergen cuando el sistema se considera como un todo.



106

Propiedades emergentes de los sistemas Las propiedades emergentes de un sistema son atributos del sistema como un todo . Muchas veces es difícil predecir los valores de estas propiedades emergentes. Sólo se pueden medir una vez que los subsistemas se hayan integrado para formar el sistema completo. Existen dos tipos de propiedades emergentes:

1. Las propiedades funcionales que surgen cuando todas las partes de un sistema trabajan de forma conjunta para cumplir un objetivo.

2. Las propiedades emergentes no funcionales , como la fiabilidad, el rendimiento, la protección y la seguridad. Éstas se refieren al comportamiento del sistema en el entorno operacional. A menudo son factores críticos para sistemas basados en computadora ya que una falla mínima en estas propiedades hace inutilizable el sistema. Algunas funciones de los sistemas no son necesarias para todos los usuarios, por lo que éste puede ser aceptable sin ellas. Sin embargo, un sistema no fiable o demasiado lento, es generalmente rechazado por todos los usuarios.

La fiabilidad es un concepto complejo que siempre debe estudiarse en el nivel del sistema más que en el de los componentes individuales. Los componentes en un sistema son interdependientes, de tal forma que una falla en uno de ellos se puede propagar a través del sistema y afectar la operación de otros. Los diseñadores de sistemas, difícilmente pueden predecir la manera en que las consecuencias de las fallas se propagan a través del sistema, por lo que no se pueden hacer estimaciones confiables de la fiabilidad, a partir de los datos de fiabilidad de los componentes del sistema. Existen tres influencias fuertemente relacionadas sobre la fiabilidad de un sistema: 1. Fiabilidad del Hardware: ¿Cuál es la probabilidad de que un componente de

hardware falle y cuanto tiempo toma reparar ese componente?. Es necesario tener plena confianza en el equipamiento adquirido, a fin de poder contar con la confiabilidad del equipamiento y evitar fallas y errores provenientes de esta componente. Debemos considerar que en caso de una falla de hardware, el tiempo necesario para su reparación o reemplazo, ya que esto influye directamente en el desarrollo del proyecto

2. Fiabilidad del Software: ¿Qué tan probable es que un componente de software

produzca una salida incorrecta?. Las fallas de software son normalmente distintas de las de hardware, en el sentido que el software no se desgasta. Puede continuar en operación aún después de que se haya producido un resultado incorrecto. No obstante esto es necesario proceder a la reparación o reemplazo del software que produce salidas o procesamientos incorrectos, a fin de lograr la fiabilidad del sistema en su totalidad.



3. Fiabilidad del operador: ¿Qué tan probable es que un operador de un sistema

cometa un error?. Para evitar cualquier tipo de error por parte del operador es fundamental la capacitación del mismo, ya que en muchas oportunidades los errores del operador no son detectables, a menos que el mismo que cometió el error lo denuncia, o este error genera alguna salida errónea, que sea identificable, ya que puede suceder que las salidas sean incorrectas pero difícilmente detectables, ya que no producen cancelación de los procesos

Estas influencias están fuertemente ligadas. Las fallas de hardware pueden generar falsas señales fuera del rango de las entradas esperadas por el software. El software puede comportarse de manera impredecible. Un error del operador es más probable en condiciones de tensión. Estas condiciones, surgen cuando ocurren fallas del sistema. Los errores del operador, pueden afectar al hardware, causando más fallas y así sucesivamente. La fiabilidad observada depende del contexto en el que se utiliza el sistema. El entorno del sistema no puede especificarse por adelantado. Diferentes sistemas en un entorno pueden reaccionar a los problemas de maneras impredecibles afectando la fiabilidad de todos estos sistemas. Aún cuando el sistema haya sido integrado es difícil hacer una medida exacta de su fiabilidad. Como en la fiablidad, otras propiedades emergentes, como el rendimiento o la usabilidad, son difíciles de validar, pero se pueden medir después que el sistema entra en operación. Sin embargo, propiedades como la protección y seguridad presentan diversos problemas. Es importante destacar que no sólo se tiene conexión con un atributo relacionado con el comportamiento total del sistema, sino con el comportamiento que el sistema no debería mostrar. Un sistema seguro es aquel que no permite accesos no autorizados a sus datos, pero es imposible predecir todos los modos probables de acceder y prohibirlos de forma explícita. Por lo tanto, sólo es posible valorar estas propiedades por defecto. Es decir, sólo se puede saber que el sistema es inseguro cuando alguien lo viola. Los sistemas y su entorno Los sistemas no son entidades independientes, puesto que existen en un entorno. Este afecta el funcionamiento y el rendimiento del sistema. Algunas veces el entorno, puede verse como un sistema en sí mismo, compuesto por un cierto número de sistemas que interactúan con ellos. Los sistemas están inmersos en un entorno organizacional, el que incluye políticas y procedimientos que a su vez están gobernados por políticas más amplias, tal como entornos económicos y sociales. Si el entorno organizacional, no se comprende adecuadamente, los sistemas pueden no cumplir las necesidades del negocio y ser rechazadas por los usuarios y los directivos de la organización.



108

Los factores humanos y organizacionales que se derivan del entorno del sistema y que afectan su diseño son: 1. Cambios en el proceso : ¿El sistema requiere cambiar los procesos en el entorno?.

Si es así, será necesaria la capacitación. Si los cambios son significativos o implican que la gente pierda su trabajo, existe el peligro de que haya resistencia al sistema.

2. Cambios en el trabajo : ¿El sistema inhabilita a los usuarios en un entorno o

provoca que cambie su forma de trabajar?. Si es así, se resistirán a la introducción del sistema a la organización.

3. Cambios Organizacionales : ¿El sistema cambia la estructura de poder en una

organización? Estos factores humanos, sociales y organizacionales, son a menudo críticos para determinar si un sistema cumple de manera exitosa los objetivos.

• Es importante destacar que todo el conocimiento relevante del entrono debe incluirse en la especificación del sistema, de tal forma que pueda ser tomada en cuenta por los diseñadores de sistemas

El proceso de la ingeniería de sistemas La ingeniería de sistemas es una actividad interdisciplinaria que unifica equipos de personas con diferentes bases de conocimiento. Para muchos sistemas existen posibilidades casi infinitas de intercambio entro los diferentes tipos de subsistemas. A menudo no existe una decisión “correcta” sobre cómo se debe descomponer un sistema. Podemos decir que existe un rango de alternativas posibles. La selección de una de estas alternativas no se hace necesariamente por razones técnicas, sino por un conjunto más complejo. Definición de requerimientos del sistema La actividad de definición de requerimientos del sistema, pretende descubrir los requerimientos completos de éste. Como en el análisis de requerimientos de software, el proceso requiere consultar con los clientes del sistema y con los usuarios finales. Esta etapa de definición de requerimientos usualmente se concentra en la desviación de tres tipos de requerimiento: 1. Requerimientos funcionales abstractos : Las funciones básicas que el sistema

debe proporcionar se definen en un nivel abstracto. La especificación detallada de requerimientos funcionales tiene lugar en el nivel de subsistemas.



2. Propiedades del Sistema : Estas son propiedades emergentes no funcionales del sistema. Incluyen propiedades como la disponibilidad, el rendimiento, la protección. Estas propiedades no funcionales del sistema, afectan los requerimientos para todos los subsistemas.

3. Características que no debe mostrar el sistema : Algunas veces tiene igual

importancia especificar lo que el sistema debe y no debe hacer. Una parte importante de la fase de definición de requerimientos es establecer un conjunto de objetivos que el sistema debe cumplir. Esto no debe necesariamente expresarse como la funcionalidad del sistema, pero debe definir el porqué se construye el sistema para un entorno particular. Diseño del sistema Las actividades que se realizan en este proceso son: 1. Dividir requerimientos : Los requerimientos se analizan y se recolectan en grupos

relacionados. Generalmente existen varias opciones posibles de división, las cuales puede producirse en esta etapa del proceso.

2. Identificar subsistemas : Se identifican los diferentes subsistemas que pueden

individual o colectivamente cumplir con los requerimientos. Los grupos de requerimientos están normalmente relacionados con los subsistemas.

3. Asignar requerimientos a los subsistemas : Los requerimientos son asignados a

cada uno de los subsistemas.

4. Especificar la funcionalidad de los subsistemas : Se deben enumerar las funciones específicas asignadas a cada subsistema. Esto puede verse como parte de la fase de diseño de sistema. En esta etapa, también deben especificarse las relaciones entre los subsistemas.

5. Definir las interfaces del subsistema : Esto comprende definir las interfaces

necesarias y requeridas por cada subsistema. Una vez que estas interfaces están acordadas, es posible el desarrollo paralelo de los subsistemas.

En este proceso de diseño existe un compromiso de retroalimentación e iteración de una etapa con la otra. A menudo es necesario rehacer el trabajo cuando surgen problemas y preguntas.



110

Para la mayoría de los sistemas existen muchos diseños posibles que se pueden desarrollar. Estos cubren un amplio rango de soluciones con combinaciones diferentes de hardware, software y operaciones humanas. La solución elegida para el desarrollo futuro deberá ser la solución técnica más apropiada que cumpla los requerimientos. Sin embargo en muchos casos las intervenciones organizacionales o políticas influyen en la elección de la solución. Desarrollo de los subsistemas Durante el desarrollo de los subsistemas, se implementarán los que se hayan identificado durante el diseño del sistema. Ocasionalmente, el proceso de desarrollo construirá todos los subsistemas desde sus inicios. Sin embargo existen paquetes comerciales que se compran, para integrarse en el sistema. Normalmente es más barato comprar paquetes comerciales enlatados, que desarrollar componentes de un propósito particular, pero debemos tener en cuenta las dificultades a futuro que esto puede ocasionar al sistema en general.

Dividir requerimientos

Identificar subsistemas

Asignar requerimientos a los subsistemas

Especificar la funcionalidad de los

subsistemas

Definir las interfaces del subsistema

El proceso de diseño de sistemas

El proceso de diseño de sistemas



Es común que los diferentes subsistemas se desarrollen en paralelo. A menudo se hacen “revisiones de trabajo”con el fin de detectar los problemas. Estas revisiones comúnmente implican cambios en el software debido a la flexibilidad inherente a él. Integración del sistema Esta etapa consiste en tomar subsistemas desarrollados en forma independiente y juntarlos para crear el sistema completo. La integración puede llevarse a cabo unificando todos los sistemas al mismo tiempo. Sin embargo, por razones técnicas como de administración, el mejor enfoque es un proceso de integración creciente donde los sistemas se integran uno a uno. Este proceso creciente es el enfoque más apropiado por dos razones: 1. Por lo general es imposible coordinar todos los desarrollos de los diferentes

subsistemas de tal forma que éstos se completen al mismo tiempo. 2. La integración creciente reduce el costo en la localización de errores. Si varios

subsistemas se integran simultáneamente, se pueden localizar errores que surjan durante las pruebas en cualquiera de los subsistemas. Cuando un único subsistema se integre a un sistema en funcionamiento, los errores que ocurran estarán probablemente en el subsistema recién integrado o en las interacciones entre los subsistemas existentes y el nuevo.

Instalación del sistema Durante la instalación del sistema, éste se ubica en el entorno en el cual se pretende que opere. Aunque esto parece resultar sencillo, surgen muchos problemas que implican que la instalación de un sistema complejo puede llevar meses o incluso años. Algunos de los problemas que nos podemos encontrar, son los siguientes: 1. El entorno en el cual el sistema se instala no es el mismo que el supuesto por los

desarrolladores del sistema. 2. Los usuarios potenciales del sistema pueden ser hostiles a su introducción, ya que

pueden reducir su responsabilidad y el número de empleos en la organización. 3. Un nuevo sistema puede convivir con uno existente hasta que la organización esté

satisfecha con el funcionamiento del nuevo sistema. Esto provoca problemas de instalación particulares si los sistemas no son completamente independientes sino que comparten algunos componentes. En este caso habrá que desmontar el anterior para instalar el nuevo.

4. Puede haber muchos problemas en la instalación física, ya que puede no existir suficiente espacio par los conductos de los cables de red, etc.



112

Operación del sistema Una vez que el sistema se ha instalado, se pone en operación; lo que significa que es necesario organizar las sesiones de entrenamiento para los operadores y cambiar el proceso normal de trabajo, a fin que la utilización del nuevo sistema sea efectiva. Los problemas no detectados pueden surgir en esta etapa debido a que la especificación del sistema puede contener errores u omisiones. Pueden haber problemas físicos o de incompatibilidad. Puede ser difícil transferir los datos de un sistema a otro. Los problemas más sutiles, son cuando se tienen diferentes interfaces de usuario en los sistemas. Evolución del sistema Los sistemas grandes y complejos tienen un periodo de vida largo. Durante su vida tienen que evolucionar para corregir errores en los requerimientos del sistema original y cumplir los nuevos requerimientos. Los sistemas de cómputos son reemplazados por máquinas más rápidas. El entorno externo de la organización puede cambiar y forzar a cambios en el sistema. La evolución del sistema es costosa por varias razones: 1. Los cambios propuestos tienen que analizarse cuidadosamente desde perspectivas

técnicas y de negocio; cuyos cambios deberán ser aprobados por cierto número de personas antes de su realización.

2. Debido a que los subsistemas nunca son completamente independientes, los

cambios en uno pueden afectar en forma adversa el funcionamiento o comportamiento de otros, por lo que habrá que cambiar también esos subsistemas.

3. Como en líneas generales las razones del diseño original no son registradas, los

responsables de la evolución del sistema tienen que resolver el porque se tomaron ciertas decisiones.

4. Al paso del tiempo su estructura se corrompe por el cambio, lo que incrementan los

costos en los cambios adicionales Debido a que la sociedad es crecientemente dependiente de sistemas de varios tipos, crece la cantidad de esfuerzo dedicado a la evolución más que al desarrollo de sistemas nuevos.



Desmantelamiento del sistema El desmantelamiento del sistema significa poner fuera de servicio a dicho sistema, después que finaliza su periodo de utilidad operativa. Algunas veces esto es directo y sencillo, pero en algunos casos los sistemas pueden contener materiales que son potencialmente peligrosos para el entorno. Durante la fase de diseño, debe anticiparse el desmantelamiento y tomar en cuenta los problemas de desecho de los materiales. Si la organización desea conservar los datos del sistema que se está desmantelando, éstos deben convertirse para utilizarlos en otros sistemas. Evolución del software La flexibilidad del software es una de las principales razones por la que más y más software se incorpora a los sistemas grandes y complejos. Una vez que se decide fabricar hardware es muy caro hacer cambios en su diseño. Sin embargo, para el software los cambios se pueden hacer en cualquier momento durante o después del desarrollo del sistema. Estos cambios pueden ser muy caros, pero aún así son mucho más baratos que los correspondientes a sistemas de hardware. Siempre ha existido una diferenciación entre el proceso de desarrollo y el proceso de evolución del software (mantenimiento del software). El desarrollo del software se considera una actividad creativa en la cual un sistema de software se desarrolla desde un concepto inicial hasta que se pone en funcionamiento. El proceso de mantenimiento del software es el proceso de cambio del sistema una vez que se ha puesto en funcionamiento. Aunque los costos de mantenimiento son generalmente varias veces más que los costos iniciales de desarrollo, el proceso de mantenimiento se considera menos problemático que el desarrollo del software original. Esta diferenciación es cada vez más irrelevante. Actualmente, pocos sistemas de software son completamente nuevos, lo que implica que tiene más sentido ver el desarrollo y el mantenimiento como actividades continuas, más que dos procesos separados. Es importante considerar que es un proceso evolutivo en el cual el software cambia continuamente durante su periodo de vida, como respuesta a requerimientos cambiantes y necesidades del usuario.



114



Texto 3

Administración de Proyectos El fracaso de muchos proyectos grandes de software en los 60 y 70 fue el primer indicio de las dificultades en la administración de software. Este era entregado tarde, no era fiable, costaba más de lo estimado, etc. Estos proyectos no fracasaron debido a que los administradores o los programadores eran incompetentes. Por el contrario estos proyectos desafiantes atraían gente con habilidades por arriba del promedio. La falla estaba en el enfoque de administración utilizada. La necesidad de administrar es una distinción importante entre un desarrollo profesional de software y la programación no profesional. La administración de proyectos de software es necesaria debido a que la ingeniería de software profesional siempre está sujeta a las restricciones de presupuesto y calendarización a las que debe ajustarse la organización que desarrolla el software. El trabajo del administrador de proyectos de software es asegurar que éstos cumplan dichas restricciones y entregar software que contribuya a las metas de negocios. Los administradores de software son responsables de la planeación y calendarización del desarrollo de los proyectos. Supervisan el trabajo para asegurar que se lleva a cabo acorde a los estándares requeridos. Supervisan el progreso para comprobar que el desarrollo va en tiempo y acorde al presupuesto. Una buena administración no garantiza el éxito del proyecto. Sin embargo, la mala siempre asegura un fracaso del mismo. Los administradores de software hacen el mismo tipo de trabajo que otros administradores de proyectos de ingeniería. Sin embargo, existen ciertas diferencias. Algunas de estas diferencias son: 1. El producto es intangible : El administrador de un proyecto de construcción de un

barco, puede ver el producto mientras se está desarrollando. Si hay un desfasaje en el calendario, el efecto en el producto es visible. El software es intangible. Es decir, no se puede ver y ni tocar. Los administradores de proyectos de software no pueden ver el progreso. Confían en otros para producir la documentación necesaria para revisar el progreso.

2. No existen procesos del software estándar : No se tiene una comprensión clara

de las relaciones entre el proceso del software y los tipos de productos. En las disciplinas de ingeniería comunes, el progreso se prueba y verifica. La comprensión del proceso del software se ha desarrollado de forma significativa en los últimos años. Sin embargo, aún no se puede predecir con certeza cuando un proceso particular, tiende a desarrollar problemas.

3. A menudo los proyectos grandes de software son “úni cos” : Por lo general, los

proyectos grandes de software son diferentes de proyectos previos. En



116

consecuencia, los administradores, aun cuando cuenten con amplia experiencia que pueda ser utilizada para reducir la incertidumbre en los planes, ésta no es suficiente para anticipar los problemas. Más aún, los rápidos cambios tecnológicos en las computadoras y las comunicaciones hacen parecer obsoleta la experiencia previa. En muchas oportunidades, las lecciones aprendidas en esas experiencias pueden no ser transferibles a los nuevos proyectos.

Debido a estos problemas no es extraño que alguno de los proyectos de software se retrasen, sobrepasen el presupuesto y estén fuera de tiempo. Dadas las mezclas de dificultades es notable que muchos proyectos de software sean entregados a tiempo y en presupuesto. Actividades de la administración Es imposible redactas una descripción estándar del trabajo de un administrador de software. El trabajo difiere enormemente dependiendo de la organización y del producto de software a desarrollar. Sin embargo, en algún momento muchos administradores son responsables de algunas o todas de las siguientes actividades: • Redacción de la propuesta

• Planeación y calendarización del proyecto

• Costeo del proyecto

• Supervisión y revisión del proyecto

• Selección y evaluación del personal

• Redacción y presentación de informes

La primera etapa de un proyecto de software implica redactar una propuesta para realizar ese proyecto. La propuesta describe los objetivos del proyecto y cómo se llevará a cabo. Por lo general, incluye estimados de costo y calendarización. La redacción de la propuesta es una tarea crítica ya que la existencia de muchas organizaciones de software, depende de las propuestas aceptadas y los contratos asignados. No existen lineamientos para esta tarea.; la redacción de propuestas es una habilidad que se adquiere por la experiencia. La planeación de proyectos se refiere a la identificación de actividades, hitos y entregas producidas por un proyecto. Por lo tanto, se debe bosquejar un plan para guiar el desarrollo hacia las metas del proyecto. La estimación del costo es una actividad relacionada que se refiere al estimado de los recursos requeridos para llevar a cabo el plan del proyecto. La supervisión del proyecto es una actividad continua. El administrador debe tener conocimiento del progreso del proyecto y comparar los progresos y costos reales con



los planeados. Aunque muchas organizaciones tienen mecanismos formales para supervisar, un administrador hábil podría formarse una imagen clara de lo que pasa llevando a cabo una entrevista informal con el personal del proyecto. Con frecuencia la supervisión informal predice problemas importantes de proyecto y revela dificultades en su momento. Durante un proyecto es normal tener varias revisiones formales de su administración. Ésta se hace completa del progreso y de los desarrollos técnicos del proyecto, y se toma en cuenta el estado del proyecto junto con el propósito de la organización encargada del software. El tiempo de desarrollo para un proyecto grande puede ser de varios años. Durante ese tiempo, los objetivos organizacionales tienden obviamente a cambiar. Estos cambios pueden significar que el software ya no se requiere más o que los requerimientos originales del proyecto son inapropiados. La administración puede decidir parar el desarrollo del software o cambiar el proyecto para adecuarlo a los cambios de los objetivos de la organización. Por lo general los administradores de proyectos tienen que seleccionar a las personas para trabajar en su proyecto. De forma ideal estará disponible personal con habilidades y experiencia apropiada para trabajar en el proyecto. Sin embargo, en muchos casos, los administradores tienen que establecer un equipo ideal mínimo para el proyecto. Las razones para esto son: 1. El presupuesto del proyecto no cubre la contratación de personal con sueldos altos.

Se tiene que contratar personal con menos experiencia y menos sueldo pero mejor aprovechados.

2. El personal con experiencia apropiada no está disponible dentro o fuera de la

organización. Es imposible reclutar personal nuevo para el proyecto. Dentro de la organización, las mejores personas ya se han asignado a otros proyectos.

3. La organización desea desarrollar las habilidades de sus empleados. El personal

inexperto puede ser asignado al proyecto para aprender y adquirir experiencia. El administrador tiene que trabajar con estas restricciones al seleccionar al personal del proyecto. Sin embargo todos estos problemas son probables a menos que exista un miembro del proyecto que cuente con algo de experiencia en el tipo de sistema a desarrollar. El administrador del proyecto es responsable de dar informes del mismo tanto al cliente como a las organizaciones contratantes. Por lo tanto debe redactar documentos concisos y coherentes que resuman la información crítica de los informes detallados del proyecto.



118

Planeación del proyecto La administración efectiva de un proyecto de software depende de planear completamente el progreso del proyecto. El administrador del proyecto debe anticiparse a los problemas que podrían surgir, así como preparar soluciones tentativas a estos problemas. Un plan preparado al inicio del proyecto, debe utilizarse como un conductor para el proyecto. Este plan inicial debe ser el mejor posible de acuerdo con la información disponible. Además de un plan del proyecto, los administradores tienen que preparar otros tipos de planes, los cuales se describen a continuación:

Plan Descripción Plan de calidad Describe los procedimientos y estándares de calidad

que se utilizarán en un proyecto Plan de Validación Describe el enfoque, los recursos y la programación

utilizados para la validación del sistema. Plan de administración de la configuración

Describe los procedimientos de administración de la configuración y las estructuras a utilizarse

Plan de mantenimiento Predice los requerimientos de mantenimiento del sistema, los costos del mantenimiento y el esfuerzo requerido

Plan de desarrollo del personal

Describe cómo se desarrollarán las habilidades y experiencia de los miembros del equipo del proyecto

Conforme la información se hace disponible, el plan debe revisarse regularmente. Las metas globales del negocio son un factor importante que debe considerarse cuando se formula el plan del proyecto. A medida que esto cambie, en el proyecto éstos serán necesarios. El proceso de planeación se inicia con una valoración de las restricciones que afectan el proyecto (Fecha de entrega requerida, personal disponible, presupuesto global, etc.) Esta se lleva a cabo en conjunto con una estimación de los parámetros del proyecto, como su estructura, tamaño y distribución de las funciones. Se prepara un calendario del proyecto y las actividades. Después de algún tiempo (por lo general 2 o 3 semanas), se revisa el proyecto y se señalan las discrepancias. Los administradores del proyecto revisan las suposiciones del proyecto en cuanto se disponga de más información. Replanean el calendario. Si el calendario se retrasa, tienen que negociar con el cliente las restricciones del mismo y los productos a entregar. Si esta renegociación no tiene éxito y no se puede cumplir el calendario, se debe llevar a cabo una revisión técnica, a fin de encontrar un enfoque alternativo que se ajuste a las restricciones del proyecto y cumpla con las metas del calendario.



Durante todo el proyecto surgen problemas. Las suposiciones iniciales y el calendario debe ser pesimista. Debe haber suficiente margen para contingencia en el plan como para que las restricciones del proyectos y los hitos no se necesiten negociar cada vez que se efectúa un ciclo del plan. El plan del proyecto Este fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo. En algunas organizaciones el plan del proyecto, es un único documento que incluye todos los diferentes tipos de planes introducidos anteriormente. Los detalles de un plan varían dependiendo del tipo de proyecto y de la organización. Sin embargo, muchos planes incluyen las siguientes secciones: 1. Introducción : Describe brevemente los objetivos del proyecto y expone las

restricciones. 2. Organización del proyecto : Describe la forma en que el equipo de desarrollo está

organizado, la gente involucrada y sus tareas en el equipo. 3. Análisis de riesgo : Describe los posibles riesgos del proyecto, la probabilidad de

que surjan estos riesgos y las estrategias de reducción de riesgos propuestas. 4. Requerimientos de recursos de hardware y software : Describe el hardware y la

ayuda de software requerida para llevar a cabo el desarrollo. 5. División del trabajo : Describe la división del proyecto en actividades e identifica lo

hitos y productos a entregar asociados a cada actividad. 6. Programa del proyecto : Describe las dependencias entre actividades, el tiempo

estimado requerido para alcanzar cada hito y la asignación de la gente a las actividades.

7. Mecanismos de supervisión e informes : Describe la administración de informes y

cuando deben producirse. El plan del proyecto debe revisarse regularmente durante el proyecto, ya que algunas partes cambiarán frecuentemente, como por ejemplo el calendario del proyecto. Hitos y productos a entregar Los administradores necesitan información. Como el software es intangible esta información sólo se puede proveer como documentos que describan el estado del software que se está desarrollando. Sin esta información es imposible juzgar el progreso y no se pueden actualizar los costos y calendarios.



120

Cuando se planea un proyecto, se debe establecer una serie de hitos (puntos finales de una actividad del proceso del software). En cada uno debe existir una salida formal, tal como un informe que se debe presentar al administrador. Los informes de los hitos no deben ser documentos amplios. Deben ser informes cortos de los logros de una actividad del proyecto. Como regla general los productos a entregar son hitos, pero los hitos no son necesariamente productos a entregar. Los hitos pueden ser resultados internos del proyecto que son utilizados por el administrador del proyecto para verificar el progreso del mismo. Calendarización del proyecto Esta es una tarea demandante para los administradores del proyecto. Los administradores estiman el tiempo y los recursos requeridos para completar las actividades y organizarlas dentro de una sucesión coherente. Las estimaciones previas son una base incierta para la calendarización del nuevo proyecto. Si el proyecto es técnicamente complejo, las estimaciones iniciales casi siempre son optimistas aún cuando los administradores traten de considerar las eventualidades. La calendarización del proyecto implica separar todo el trabajo de un proyecto en actividades complementarias y considerar el tiempo requerido para completar dichas actividades. Generalmente algunas de ellas se desarrollan en forma paralela. Los que establecen el calendario de proyectos deben coordinarlas, y organizar el trabajo para que la mano de obra se utilice de forma óptima. Si una tarea no se ha terminado, deben evitarse situaciones críticas de retraso en la totalidad del proyecto. Al estimar la calendarización, los administradores no deben suponer que cada etapa del proyecto estará libre de inconvenientes. Se debe estimar los recursos necesarios para completar cada tarea. El recurso principal es el esfuerzo humano que se requiere.

• Una buena regla práctica es estimar como si nada fuera a salir mal y entonces incrementar la estimación para cubrir los problemas previstos.

Por lo general el calendario del proyecto se representa como un conjunto de gráficos que muestran la división del trabajo, las dependencias de las actividades y la asignación del personal. Por lo general la herramienta de administración de software que se utiliza es el Microsoft Project., la cuál permite llevar un estricto control sobre las alternativas del proyecto.



Administración de riesgos Una tarea importante del administrador de proyectos es anticipar los riesgos que podrían afectar la programación del proyecto o la calidad del software a desarrollar y emprender acciones para evitar estos riesgos. Los resultados de los análisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra. Identificar éstos y crear planes para minimizar sus efectos en el proyecto, se llama administración de riesgos. De forma simple, se puede concebir un riesgo, como una probabilidad de que una circunstancia adversa ocurra. Los riesgos son una amenaza para el proyecto, para el software que se está desarrollando y para la organización. Existen categorías de riesgos que las podemos definir de la siguiente manera: 1. Los riesgos del proyecto: éstos afectan la calendarización o los recursos del

proyecto. 2. Los riesgos del producto: éstos afectan la calidad o desempeño del software que

se está desarrollando. 3. Los riesgos del negocio: éstos afectan a la organización que desarrolla el

software. Por supuesto que esta clasificación no es única, pero es una serie de consideraciones que es conveniente tener en cuenta. La administración de riesgos es importante particularmente para los proyectos de software debido a las incertidumbres inherentes que enfrentan muchos proyectos. Estas incertidumbres, son el resultado, entre otras cosas, de definir pobremente los requerimientos, la estimación de tiempos y los recursos para el desarrollo del software. El administrador de proyectos, debe anticiparse a los riesgos; comprender el impacto de éstos en el proyecto, en el producto y en el negocio, considerando los pasos para evitarlos en caso que ocurran, se deben crear planes de contingencia para que sea posible aplicar acciones de recuperación. Los tipos de riesgos que pueden afectar un proyecto dependen de éste y el entorno organizacional en el que se esté desarrollando el proyecto. De todas maneras hay una cantidad de riesgos que son universales, es decir que no dependen de un proyecto en particular. A continuación se describen algunos de ellos:



122

Riesgo Tipo de riesgo

Descripción

Rotación de personal Proyecto Personal con experiencia abandona el proyecto antes que finalice

Cambio de administración

Proyecto Habrá un cambio de administración organizacional con diferentes prioridades

No disponibilidad del hardware

Proyecto El hardware esencial para el proyecto no será entregado a tiempo.

Cambio de requerimientos

Proyecto y producto

Habrá más cambios en los requerimientos que lo anticipado

Retrasos en la especificación

Proyecto y producto

Las especificaciones de las interfaces esenciales no estarán a tiempo

Subestimación del tamaño

Proyecto y producto

El tamaño del sistema se ha subestimado

Bajo desempeño de la herramienta CASE

Producto Las herramientas CASE1 que ayudan al proyecto no tienen el desempeño anticipado

Cambio de tecnología Negocio La tecnología fundamental sobre la que se construirá el sistema se sustituye por nueva tecnología

Competencia del producto

Negocio Un producto competitivo se pone en venta antes de que el sistema se complete

El proceso de administración de riesgos, comprende varias etapas: 1. Identificación de riesgos : Identificar los posibles riesgos para el proyecto, el

producto y los negocios. Se realiza un listado de riesgos potenciales. 2. Análisis de riesgos : Valorar las probabilidades y consecuencias de estos riesgos.

Se realiza un listado de priorización de riesgos. 3. Planificación de riesgos : Crear planes para abordar los riesgos, ya sea para

evitarlos o minimizar sus efectos en el proyecto. Se realiza la definición para la anulación de los riesgos y se establecen planes de contingencia.

4. Supervisión de riesgos : Valorar los riesgos en forma constante y revisar los planes para mitigar los riesgos tan pronto como la información de los riesgos esté disponible.

El proceso de administración de riesgos, como otros de planeación de proyectos, es un proceso iterativo que se aplica a lo largo de todo el proyecto. Una vez que se genera un conjunto de planes iniciales, se supervisa la situación. En cuanto surja más información acerca de los riesgos, éstos se deben analizar nuevamente y establecer nuevas prioridades.

1 CASE, (Computer Aided Software Engineering Tools).



• La prevención de riesgos y los planes de contingencia se deben modificar tan

pronto como surja nueva información de los riesgos. Los resultados del proceso de administración de riesgos se deben documentar en un plan de administración de riesgos, debiendo incluir una discusión de dichos riesgos a los que se enfrenta el proyecto, un análisis de éstos y los planes requeridos para su administración. Identificación de riesgos Esta es la primera etapa de la administración de riesgos. Comprende el descubrimiento de los posibles riesgos del proyecto. En principio no se les debe valorar en esta etapa, aunque en la practica no se consideran los riesgos con consecuencias menores o con baja probabilidad. Para ayudar al proceso de identificación de riesgos, se utiliza una lista de posibles tipos de riesgos, tal como se detalla a continuación: 1. Riesgos de tecnología: Estos derivan de las tecnologías de software o de

hardware utilizadas en el sistema que se está desarrollando. 2. Riesgos de personas: Riesgos asociados con las personas en el equipo de

desarrollo. 3. Riesgos organizacionales: Son los derivados del entorno organizacional donde el

software está siendo desarrollado. 4. Riesgos de herramientas: Se derivan de herramientas CASE y de otro software de

apoyo utilizado para desarrollar el sistema. 5. Riesgos de requerimientos: Se derivan de los cambios de los requerimientos del

cliente y el proceso de administrar dicho cambio. 6. Riesgos de estimación : Son los que se derivan de la interpretación de las tareas

administrativas, de las características del sistema y los recursos requeridos para construir dicho sistema.

A continuación, damos algunos ejemplos de riesgos posibles en cada una de estas categorías:



124

Tipo de riesgo Riesgos posibles Tecnología La base de datos que se utiliza en el sistema no puede almacenar

muchas transacciones por segundo como se esperaba. Los componentes de software a reutilizarse contienen defectos que limitan su funcionalidad.

Personas Es imposible reclutar personal con las habilidades requeridas para el proyecto. El personal clave está enfermo y no disponible en momentos críticos. La capacitación solicitada para el personal no está disponible.

Organizacional La organización se reestructura de tal forma que una administración diferente se responsabiliza del proyecto. Los problemas financieros de la organización fuerzan a reducciones en el presupuesto del proyecto

Herramientas Es ineficiente el código generado por las herramientas CASE. Las herramientas CASE no se pueden integrar

Requerimientos Se proponen cambios en los requerimientos que requieren rehacer el diseño. Los clientes no comprenden el impacto de los cambios en los requerimientos.

Estimación El tiempo requerido para desarrollar el software esta subestimado. La tasa de reparación de defectos está subestimada. El tamaño del software está subestimado.

Análisis de riesgos Durante este proceso se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo. No existe una forma fácil de hacer esto, recae en la opinión y experiencia del administrador del proyecto. El resultado de este proceso de análisis se debe colocar en una tabla, la cual debe estar ordenada acorde a la seriedad del riesgo. Obviamente, aquí es arbitraria la valoración de la probabilidad y seriedad. Por supuesto que tanto la probabilidad y la valoración de los efectos de un riesgo cambia conforme se disponga de mayor información acerca del riesgo y los planes de administración del mismo que se implementen. Esta tabla debe ser actualizada durante cada iteración del proceso de riesgos. Una vez que los riesgos se hayan analizado y clasificado, se debe discernir cuáles son los más importantes que se deben considerar durante el proyecto. Esto depende de una combinación de la probabilidad del riesgo en cuestión y los efectos del mismo. En general se deben tomar en cuenta todos los riesgos catastróficos; así como todos los riesgos serios que tienen más que una moderada probabilidad de ocurrir. En la siguiente tabla podemos visualizar algunos ejemplos después de realizado en análisis de riesgos:



Riesgo Probabilidad Efectos Los problemas financieros de la organización fuerzan a reducir el presupuesto del proyecto

Baja Catastrófico

Es imposible reclutar personal con las habilidades requeridas para el proyecto

Alta Catastrófico

El personal clave está enfermo y no disponible en momentos críticos

Moderada Serio

Los componentes de software a reutilizarse contienen defectos que limitan su funcionalidad

Moderada Serio

Se proponen cambios en los requerimientos que requieren rehacer el diseño

Moderada Serio

La organización se reestructura de tal forma que una administración diferente se responsabiliza del proyecto

Alta Serio

La base de datos que se utiliza en el sistema no puede procesar muchas transacciones por segundo como se esperaba

Moderada Serio

El tiempo requerido para desarrollar el software está subestimado

Alta Serio

Las herramientas CASE no se pueden integrar Alta Tolerable Los clientes no comprenden el impacto de los cambios en los requerimientos

Moderada Tolerable

La capacitación solicitada para el personal no está disponible

Moderada Tolerable

La tasa de reparación de defectos está subestimada Moderada Tolerable El tamaño del software esta subestimado Alta Tolerable Es ineficiente el código generado por las herramientas CASE

Moderada Insignificante

Planeación de riesgos Este proceso considera cada uno de los riesgos clave identificados y las estrategas para administrarlo. No existe un proceso sencillo a seguir para establecer los planes de administración de riesgos. Recae en el juicio y la experiencia del administrador del proyecto. Podemos identificar tres tipos de estrategias, tal como se detallan a continuación: 1. Estrategias de anulación : Seguir éstas significa reducir la probabilidad de que ese

riesgo surja. 2. Estrategias de disminución : Significa reducir el impacto del riesgo. 3. Planes de contingencia : Significa que, si sucede lo peor, se está preparado para

ello y se cuenta con una estrategia para abordarlo.



126

A continuación se definen posibles estrategias identificadas para los riesgos claves, establecidos en la tabla anterior:

Riesgo Estrategia Problemas financieros de la organización

Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio

Problemas de reclutamiento

Alertar al cliente de las dificultades potenciales y las posibilidades de retraso, investigar los componentes comprados.

Enfermedad del personal

Reorganizar el equipo de tal forma que haya transferencia en el trabajo y las personas comprendan el de los demás

Componentes defectuosos

Reemplazar los componentes defectuosos con los comprados de fiabilidad conocida

Cambios en los requerimientos

Rastrear la información para valorar el impacto de los requerimientos, maximizar la información oculta en ellos.

Reestructuración organizacional

Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio.

Desempeño de la base de datos

Investigar la posibilidad de comprar una base de datos con alto desempeño

Tiempo de desarrollo subestimado

Investigar los componentes comprados y la utilización de un generador de programas.

Supervisión de riesgos Esta supervisión normalmente valora cada uno de los riesgos identificados para decidir si éste es más o menos probable y cuando los efectos del mismo han cambiado. La supervisión de riesgos debe ser un proceso continuo y, en cada revisión del progreso de la administración, cada uno de los riesgos clave debe ser considerado por separado. A continuación se detallan algunos ejemplos de los factores que ayudan en la valoración de los factores de riesgo: Tipo de riesgo Indicadores potenciales

Tecnología Entrega retrasada del hardware o de la ayuda al software, muchos problemas tecnológicos reportados

Personas Baja moral del personal, malas relaciones entre los miembros del equipo, disponibilidad de empleo.

Organizacional Falta de acciones por el administrador principal Herramientas Rechazo de los miembros del equipo para utilizar herramientas,

quejas acerca de las herramientas CASE, pedido de estaciones de trabajo más potentes.

Requerimientos Pedidos de muchos cambios en los requerimientos, quejas del cliente.



Estimación Fracaso en el cumplimiento de los tiempos acordados, y en la eliminación de defectos reportados.



128



Texto 4

Calidad del Software Todos estamos familiarizados con los problemas de las caídas en sistemas de cómputos. Algunas veces los sistemas de cómputo se colapsan y dejan de suministrar los servicios que se la han solicitado. Los programas que se ejecutan sobre estas computadoras no operan como se espera; ocasionalmente adulteran los datos administrados por el sistema. Hemos aprendido a vivir con estas caídas y pocos de nosotros confiamos completamente en las computadoras personales que utilizamos todos los días. La confiabilidad de un sistema de cómputos es una propiedad del sistema que es igual a su fidelidad. La fidelidad esencialmente significa el grado de confianza esperado del usuario en el sistema que operará y en que el sistema no “caerá” al utilizarlo normalmente. Esta propiedad no puede expresarse numéricamente sino que se utilizan términos como “no confiable”, “muy confiable”y “ultraconfiable”, para reflejar diferentes grados de confianza en un sistema. Existen cuatro dimensiones principales de la confiabilidad, tal como se desarrolla a continuación: 1. Disponibilidad : La disponibilidad de un sistema es la probabilidad de que esté

activo y en funcionamiento y le sea posible suministrar servicios útiles en cualquier momento.

2. Fiabilidad : La fiabilidad de un sistema es la probabilidad de que en un período, el

sistema suministre los servicios correctamente tal como lo espera el usuario. 3. Seguridad: La seguridad de un sistema es una valoración de qué tan probable es

que el sistema provoque un daño a la gente o a su entorno. 4. Protección: La protección de un sistema es una valoración de qué tan probable es

que el sistema resista a una entrada accidental o provocada.



130

La disponibilidad y la confiabilidad son probabilidades, y por lo tanto se pueden expresar de manera cuantitativa. La seguridad y la protección son valoraciones que se hacen basándose en evidencias del sistema. Estas raramente se expresan como valores numéricos, generalmente se expresan en términos de niveles de integridad. Por lo tanto la seguridad de nivel 1 del sistema es menor que la seguridad de nivel 2 y así sucesivamente. Debido a los diseños adicionales y a la sobrecarga en la implementación y en la validación, incrementar la confiabilidad de un sistema puede incrementar drásticamente los costos de desarrollo. Por lo general es cierto que los altos niveles de confiabilidad sólo se pueden lograr a costa del desempeño del sistema. El software confiable contiene código extra, a menudo redundante, para llevar a cabo la verificación necesaria de los estados del sistema excepcionales y recuperarse de las caídas del sistema. Esto reduce el desempeño del sistema e incrementa la cantidad de espacio de almacenamiento requerido. Sin embargo, existen varias razones por las que la confiabilidad es por lo general un atributo más importante que el desempeño: 1. A menudo, los sistemas que no son confiables, poco seguros o inseguros no

se utilizan . Si los usuarios no confían en un sistema, por lo regular re rehúsan a utilizarlo. Más aún, se rehúsan a utilizar productos de la compañía que produjo el sistema no confiable puesto que creen, que éstos tampoco son confiables.

Dimensiones de la confiabilidad

Confiabilidad

Disponibilidad Fiabilidad Seguridad Protección

La capacidad del sistema

para entregar los servicios cuando son requeridos


para entregar los servicios

como han sido especificados


para operar sin fallas

catastróficas


para protegerse a sí mismo de

entradas accidentales o premeditadas



2. Los costos en las caídas del sistema son enormes : Para algunas aplicaciones,

como un sistema de navegación aérea, los costos de las caídas del sistema son de órdenes de magnitud más grande que el costo de los sistemas de control

3. Es difícil reajustar la confiabilidad : Por lo general es posible ajustar un sistema

ineficiente puesto que mucho del tiempo de ejecución se invierte en secciones de programas pequeños. Un sistema que no es confiable es muy difícil de mejorar puesto que la no confiabilidad tiende a estar distribuida a lo largo del sistema.

4. A menudo es posible compensar la falta de desempeño del sistema : Algunas

veces, los usuarios ajustan su forma de trabajar acorde al desempeño pobre del sistema. Una falta de confiabilidad, por lo general sorprende al usuario sin ningún aviso, lo cual puede traer caídas con consecuencias que se manifiestan posteriormente.

5. Los sistemas no confiables provocan la pérdida de i nformación : Es muy caro

recolectar y dar mantenimiento a los datos; algunas veces cuesta más que el sistema de cómputos sobre el que se procesan. Se tiene que hacer un gran esfuerzo e invertir mucho dinero para duplicar los datos importantes a fin de protegerlos.

La confiabilidad del producto de software se ve influenciada por el proceso de software utilizado para desarrollar ese producto. Un proceso repetitivo orientado a evitar defectos probablemente desarrolle un sistema confiable; sin embargo no existe una relación entre producto y calidad del proceso. Sistemas críticos Las caídas de muchos sistemas controlados por software provocan inconvenientes, pero no daños permanentes serios. Sin embargo, existen algunos sistemas donde las caídas pueden provocar una pérdida económica importante, daños físicos o amenazas a la vida humana. Estos sistemas se conocen como sistemas críticos. La confiabilidad es un atributo esencial de los sistemas críticos, por lo que todos los aspectos de confiabilidad (disponibilidad, fiabilidad, seguridad y protección) son muy importantes.

• Conseguir un alto nivel de confiabilidad es por lo general el requerimiento más importante de los sistemas críticos.

Existen tres tipos principales de sistemas críticos: 1. Sistemas de seguridad críticos: Un sistema cuyo fallo provoca una lesión, perdida

de vida o un daño importante al medio ambiente. (Ej.: sistema de control de una planta química)

2. Sistemas de misión críticos: Un sistema cuya anomalía provoca caídas en

algunas actividades dirigidas por objetivos. (Ej.: sistema de navegación aérea).



132

3. Sistemas de negocios críticos: Un sistema cuya anomalía provoca una caída en los negocios que utilizan este sistema. (Ej.: un sistema de cuentas de clientes de un banco).

Los costos de las caídas de un sistema crítico generalmente son muy altos. Estos costos incluyen los costos directos de las caídas que requieren que el sistema se reemplace y los costos indirectos como los costos de litigios y las pérdidas en los negocios consecuencia de que el sistema no esté disponible. Teniendo en cuenta estas características, los sistemas críticos se desarrollan por lo general utilizando técnicas probadas en lugar de técnicas nuevas que no hayan estado sujetas a pruebas prácticas fondo. Cuando la confiabilidad se considera en los sistemas críticos, existen tres tipos de componentes de sistemas susceptibles a caerse: 1. El hardware que puede fallar debido a errores en su diseño, debido a que los

componentes se caen como resultado de errores en su fabricación o debido a que los componentes de hardware han llegado al final de su vida útil.

2. El software que puede fallar debido a errores en su especificación, diseño o

implementación. 3. Los operadores humanos de sistemas que pueden tener problemas al operar el

sistema correctamente. Por lo tanto, si la meta es mejorar la confiabilidad de un sistema, se tienen que considerar estos aspectos y sus interacciones. Disponibilidad y fiabilidad Estas dimensiones están relacionadas cercanamente a la confiabilidad. La disponibilidad de un sistema es la probabilidad de que le sea posible suministrar servicios a sus usuarios cuando éstos se requieren. La fiabilidad es la probabilidad de que los servicios del sistema se suministren tal como se especificaron. Obviamente, la fiabilidad presupone la disponibilidad debido a que si un servicio especificado no se suministra, entonces el sistema no se comporta de acuerdo con su especificación. De todas maneras, es útil distinguir entre estas características ya que los requerimientos para la disponibilidad y la fiabilidad son diferentes. Algunos sistemas pueden tolerar caídas relativamente frecuentes de las que se pueden recuperar muy rápidamente. Por lo tanto, tienen requerimientos de fiabilidad relativamente bajos. Sin embargo los mismos sistemas pueden tener requerimientos de disponibilidad muy altos debido a que los usuarios esperan que siempre estén en servicio continuo.



La fiabilidad de un sistema de software se puede medir en un entorno de oficina donde muchos de los usuarios no están interesados en la operación del software. Siguen las instrucciones de las formas de utilizarlo y no tratan de experimentar con él. En el ámbito universitario, la fiabilidad es muy diferente, ya que los estudiantes exploran las fronteras del sistema y lo utilizan de formas inesperadas. Esto conduce a caídas del sistema que no ocurren en muchos entornos de oficina restringidos. Una dificultad adicional con estas definiciones es que no toman en cuenta la severidad de las caídas o las consecuencias de la ausencia de disponibilidad. Las personas están más conscientes de las caídas en el sistema que tienen consecuencias serias y en las que su percepción de la fiabilidad del sistema se vea influenciada por estas consecuencias. Una definición estricta de fiabilidad relaciona a la implementación del sistema con su especificación. Esto es, el sistema se comporta de forma fiable si su comportamiento es consistente con el definido en la especificación. Sin embargo una causa común de falta de confiabilidad es que la especificación del sistema no cumpla las expectativas de los usuarios del sistema. Lamentablemente, muchas de las especificaciones son incompletas o incorrectas y se deja a los analistas o ingenieros de software que interpreten cómo se debería comportar el sistema. La fiabilidad y la disponibilidad, generalmente se consideran las dimensiones más importantes de la confiabilidad. Si el sistema no es fiable, es difícil asegurar la seguridad o protección del sistema puesto que dependen de las caídas del sistema. Si un sistema no esta disponible, las consecuentes pérdidas económicas pueden ser muy altas. El software no fiable provoca costos altos a los usuarios finales. Los desarrolladores de sistemas no fiables adquirirán una mala reputación debido a la calidad y perderán oportunidades futuras. La fiabilidad está relacionada con las caídas del sistema. Muchas caídas del sistema son consecuencia de comportamientos erróneos en el sistema que conducen a fallas en el sistema. Cuando se discute la fiabilidad, es de gran utilidad distinguir entre los términos falla, error y caída. Podemos establecer las diferencias entre los términos en el cuadro que se detalla a continuación:

Término Descripción Caída del sistema Un evento que ocurre en cierto momento que provoca

que el sistema no proporcione el servicio esperado por los usuarios.

Error del sistema Comportamiento erróneo del sistema debido a que el comportamiento del sistema no está acorde a su especificación.

Falla del sistema Un estado incorrecto del sistema, por ejemplo, un estado del sistema no esperado por los diseñadores del sistema



134

Error o equivocación humana

Comportamiento humano que conduce a la introducción de fallas en un sistema

Las fallas del sistema no necesariamente conducen a errores del sistema puesto que el estado de falla es transitorio y se corrige antes de que el comportamiento erróneo ocurra. Los errores en el sistema no necesariamente conducen a caídas en el sistema puesto que el comportamiento también puede ser transitorio y no tener efectos observables o el sistema incluye cierta seguridad que asegura que se descubran y corrijan los comportamientos erróneos antes de que los servicios del sistema se vean afectados. Estas diferencias citadas en el cuadro precedente, ayuda a identificar tres enfoques complementarios que se utilizan para mejorar la fiabilidad de un sistema: 1. Prevención de fallas: Se utilizan técnicas de desarrollo que minimizan la posibilidad

de equivocaciones y/o atrapan equivocaciones antes de que éstas conduzcan a la introducción de fallas del sistema.

2. Detección y eliminación de fallas: La utilización de técnicas de verificación y

validación incrementan las oportunidades de detección y eliminación de las fallas antes de que el sistema se utilice. Las pruebas y depuración sistemática del sistema son un ejemplo de una técnica de detección de fallas.

3. Tolerancia a fallas: La utilización de técnicas que aseguran que las fallas en un

sistema no conducen a errores en el sistema o que aseguran que los errores en el sistema no conducen a caídas en el sistema. La incorporación de recursos de auto verificación en un sistema y la utilización de módulos redundantes son ejemplos de técnicas de tolerancia a las fallas.

Las fallas de software provocan caídas en el software cuando el código de fallas se ejecuta con un conjunto de entradas que provoca la falla del software. La fiabilidad del programa depende en gran medida del número de entradas que provocan salidas erróneas durante la utilización del sistema. Las fallas que sólo ocurren en situaciones excepcionales tienen poco efecto en la fiabilidad del sistema. La fiabilidad está relacionada con la probabilidad de que ocurra un error al momento de operación. Eliminar las fallas en el software de las partes del sistema que raramente se utilizan no hace gran diferencia con la fiabilidad percibida. Un programa puede contener fallas conocidas y aún ser visto como confiable por sus usuarios. Ellos nunca seleccionan una entrada errónea por lo que las caídas en el programa nunca ocurrirán. Reparar las fallas en estas características no hace prácticamente ninguna diferencia en la fiabilidad experimentada en los usuarios.

Terminología de la fiabilidad



Cada usuario utiliza un sistema de manera diferente. Las fallas que afectan la fiabilidad del sistema para un usuario pueden no aparecer si se trabaja de forma diferente. Seguridad La seguridad de un sistema es un atributo del sistema que refleja la capacidad del sistema para operar, normalmente o anormalmente, sin amenazar a las personas o al medio ambiente. Si la seguridad es un atributo esencial de un sistema crítico, el sistema es un sistema de seguridad crítico. El software de seguridad crítico cae en dos clases: 1. Software de seguridad crítico primario: Este es el software que está incrustado

como un controlador en un sistema. El mal funcionamiento de este software puede provocar un mal funcionamiento del hardware que provoca lesiones humanas o daños al medio ambiente.

2. Sistemas de seguridad crítico secundario : Este es el software que indirectamente

puede provocar lesiones. Por ejemplo un sistema de diseño asistido por computadora, cuyo mal funcionamiento podría provocar una amenaza a los humanos si el sistema diseñado funciona mal.

La fiabilidad y la seguridad del sistema están relacionadas pero tienen diferentes atributos de confiabilidad. Por supuesto un sistema de seguridad crítico es fiable si está de acuerdo con su especificación y opera sin caídas. Los sistemas tolerantes a fallas no son necesariamente seguros. El software aún puede funcionar mal y provocar un comportamiento del sistema que provoca un accidente. Además del hecho de que no se puede estar cien por ciento seguro de que los sistemas de software están libres de fallas y son tolerantes a fallas, existen muchas otras razones por las que los sistemas que son fiables no son necesariamente seguros: 1. La especificación puede estar incompleta en el sentido de que no describe el

comportamiento requerido del sistema en algunas situaciones críticas. Las dificultades con los requerimientos son las causas clave de los errores de software relacionados con la seguridad que persistieron hasta la integración y pruebas del sistema.

2. El mal funcionamiento del hardware provoca que el sistema se comporte de forma

impredecible y presente al software a un entorno no anticipado. Cuando los componentes están próximos a caerse, se comportan erráticamente y generan señales que están fuera de los rangos que puede manejar mejor el software.

3. El operador del sistema genera entradas que no son individualmente incorrectas

pero que, en situaciones particulares, pueden conducir a un mal funcionamiento del sistema.



136

La clave para lograr la seguridad es asegurar que los accidentes no ocurran o que las consecuencias de un accidente sean mínimas. Esto se puede llevar a cabo de tres formas complementarias: 1. Evitar contingencias : El sistema se diseña para que las contingencias se eviten. 2. Detección y eliminación de contingencias : El sistema se diseña de tal forma que

las contingencias se detectan y remueven antes de que provoquen un accidente. 3. Limitación de daños : El sistema incluye características de seguridad que

minimizan el daño que resulta de un accidente. Los accidentes generalmente ocurren cuando varias cosas funcionan mal al mismo tiempo. Un análisis de accidentes serios, indicó que casi todos ellos se debieron a una combinación de malos funcionamientos más que a caídas aisladas. La combinación no anticipada condujo a interacciones que provocaron caídas del sistema. Podemos decir que es imposible anticiparse a todas las posibles combinaciones de malos funcionamientos del sistema y que los accidentes son una parte inevitable al utilizar sistemas complejos. El control y la supervisión del software pueden mejorar la seguridad de los sistemas. Los sistemas controlados por software pueden permitir estrategias de control que reducen la cantidad de tiempo que necesitan las personas en entornos con contingencias. Un vocabulario especializado ha surgido para discutir los sistemas de seguridad críticos y es importante comprender los términos específicos utilizados, tal como se detallan en el cuadro a continuación:

Termino Definición Accidente (o desgracia)

Un evento o una secuencia de eventos no planeados que provocan heridas o la muerte, daño al propietario o al entorno. Ej: cuando una máquina lesiona a su operador.

Contingencia Un estado con el potencial de provocar o contribuir a un accidente. Ej: Falla de un sensor que detecta un obstáculo frente a la maquina.

Daño Una medida de la pérdida que resulta de una desgracia. El daño puede ir desde varias personas muertas en un accidente hasta lesiones menores o daños en las propiedades.

Contingencia severa

Una evaluación del peor daño posible que podría resultar de una contingencia en particular. Las contingencias severas van desde catastróficas (donde mucha gente muere), hasta menores (donde se tienen daños menores).

Probabilidad de la contingencia

Es la probabilidad de los procesos o actividades que generan o inducen a una contingencia. Los valores de la



probabilidad tienden a ser arbitrarios pero van desde probable, hasta improbable, sin ser posible catalogarlos en forma numérica.

Riesgo Esta es una medida de la probabilidad de que el sistema provoque un accidente. El riesgo se evalúa tomando en cuenta la probabilidad de la contingencia, la gravedad de la contingencia y la probabilidad de que la contingencia conduzca a un accidente.

Protección La protección de un sistema es una valoración de la magnitud de la seguridad que el sistema se da a sí mismo debido a ataques externos que pueden ser accidentales o provocados. Un ejemplo de ataques son los virus, la utilización no autorizada de servicios del sistema. Sin un nivel razonable de protección la disponibilidad, la fiabilidad y la seguridad del sistema, están en peligro si los ataques externos provocan daños al sistema. La razón de esto es que todos lo métodos para asegurar la disponibilidad, fiabilidad y protección se valen del hecho de que el sistema operacional es el mismo que se instaló originalmente. Si el sistema instalado ha sido modificado de alguna forma, entonces los argumentos para la fiabilidad y la seguridad originalmente establecidos ya no se cumplen más. El sistema de software se corrompe y se comporta de forma impredecible. Existen algunos tipos de sistemas críticos donde la protección es la dimensión más importante de la confiabilidad del sistema. Por ejemplo los sistemas de comercio electrónico, se deben diseñar de tal forma que cumplan altos niveles de protección. Si los sistemas de reserva de una aerolínea no está disponible, ésto provoca inconvenientes y algunos atrasos en la emisión de boletos, pero si el sistema es inseguro y puede aceptar reservas falsas, entonces los propietarios del sistema de la aerolínea pueden perder gran cantidad de dinero como resultado de ese problema. Existen tres tipos de daños causados por ataques externos: 1. Negación del servicio: El sistema se ve forzado a entrar en un estado donde sus

servicios normales no están disponibles. Esto afecta la disponibilidad del sistema. 2. Corrupción de los programas o datos: Los componentes de software del sistema

se alteran de forma no autorizada. Esto afecta el comportamiento del sistema y por lo tanto su fiabilidad y seguridad. Si el daño es severo, la disponibilidad del sistema se ve afectada.

3. Revelación de información confidencial: La información manejada por el sistema

es confidencial y los ataques externos la expone a personas no autorizadas.

Terminología de la seguridad



138

Dependiendo del tipo de datos, esto podría afectar la seguridad del sistema y permitir ataques posteriores que afecten la disponibilidad o fiabilidad del sistema.

Como en otros aspectos de la confiabilidad existe una terminología especializada en la protección, tal como se detalla en el cuadro a continuación:

Termino Definición Exposición Posible pérdida o daño en un sistema de cómputos Vulnerabilidad Una debilidad en un sistema basado en computadora que

se puede aprovechar para provocar pérdidas o daños. Ataque Un abuso de la vulnerabilidad de un sistema Amenazas Las circunstancias que tienen el potencial de provocar

pérdidas o daños Control Una medida de seguridad que reduce la vulnerabilidad del

sistema Existe una analogía con alguna terminología de la seguridad en el sentido que una exposición es análoga a un incidente y la vulnerabilidad es análoga a una contingencia. Por lo tanto, existen enfoques comparables que se utilizan para fortalecer la protección de un sistema: 1. Evitar la vulnerabilidad: El sistema se diseña de tal forma que la vulnerabilidad no

ocurra. Ejemplo: si el sistema no está conectado a una red pública externa, entonces no existe posibilidad de un ataque por parte de los miembros del público.

2. Detección y neutralización de ataques: El sistema se diseña para detectar vulnerabilidades y eliminarlas antes de que provoquen una exposición del sistema. Ejemplo un buen antivirus para analizar los archivos entrantes a fin de evitar infecciones.

3. Limitación de la exposición: Las consecuencias de un ataque externo se

minimizan. Ejemplo de limitación de la exposición son los sistemas de respaldo. La protección cada vez es más importante puesto que más y más sistemas están conectados a Internet. Las conexiones a Internet proveen funcionalidad adicional al sistema, pero también implican que los detalles de la vulnerabilidad de un sistema específico se diseminen muy fácilmente de tal forma que a más gente le es posible atacar al sistema. La supervivencia está claramente relacionada tanto con la protección como con la disponibilidad. El trabajo en la supervivencia se enfoca a identificar los componentes clave del sistema que aseguran que pueden suministrar un servicio mínimo.

Terminología de protección



Texto 5

Administración de la calidad Lograr un alto nivel de calidad de un producto o servicio es el objetivo de muchas organizaciones. Ya no se acepta entregar productos de calidad pobre y luego arreglar los problemas y deficiencias después de la entrega al cliente. El software tiene las mismas características que cualquier otro producto manufacturado como los autos, los televisores o las computadoras. Sin embargo la calidad del software es un concepto complejo que no se puede definir de una forma simple. La noción de calidad es que el producto desarrollado cumple su especificación. Esta definición se aplica a todos los productos, pero para sistemas de software, existen problemas: 1. La especificación se orienta hacia las características del producto que el consumidor

quiere. Sin embargo, la organización desarrolladora también tiene requerimientos (como los de mantenimiento) que no se incluyen en las especificaciones.

2. No se sabe cómo especificar ciertas características de calidad, de una forma no

ambigua. 3. Es muy difícil redactar especificaciones concretas de software. Aunque el producto

esté acorde a su especificación, los usuarios no lo consideran un producto de alta calidad.

Obviamente se han hecho esfuerzos para mejorar las especificaciones, pero en la actualidad se tiene que aceptar que son imperfectas. Se reconocen los problemas con las especificaciones existentes y se diseñan procedimientos para mejorar la calidad dentro de las restricciones impuestas por una especificación imperfecta. Los atributos del software, como la mantenibilidad, la portabilidad o la eficiencia, son atributos de calidad críticos que no se especifican explícitamente pero que afectan la calidad percibida del sistema. La responsabilidad de los administradores de la calidad en una organización es asegurar que se cumpla el nivel requerido de la calidad de un producto. En principio, la administración de calidad comprende simplemente definir procedimientos y estándares a utilizar durante el desarrollo de software y comprobar que todos los integrantes del grupo de trabajo lo sigan. De todas maneras en la práctica, la administración de la calidad es más que esto.



140

Los buenos administradores de calidad tienen como propósito desarrollar una “cultura de calidad” donde cada persona responsable del desarrollo del producto es motivada para que logre un alto nivel de calidad del producto. Aunque los estándares y los procedimientos son la base de la administración de la calidad, los administradores de la calidad experimentados reconocen que existen aspectos intangibles para la calidad del software (elegancia, transparencia, etc.) que no están incluidos en los estándares. La administración de la calidad del software se estructura en tres actividades principales: 1. Aseguramiento de la calidad : El establecimiento de un marco de trabajo de

procedimientos y estándares organizacionales que conduce a software de alta calidad.

2. Planeación de la calidad : La selección de procedimientos y estándares adecuados

a partir de este marco de trabajo y la adaptación de éstos para un proyecto de software específico.

3. Control de la calidad : La definición y promulgación de los procesos que aseguran

que los procedimientos y estándares para la calidad del proyecto son seguidos por el equipo de desarrollo de software.

La administración de la calidad provee una comprobación independiente de los procesos de desarrollo de software. El producto resultante de los procesos del software se introduce de administración de la calidad, donde se comprueba para asegurar que es consistente con los estándares y metas organizacionales. Dado que los miembros del equipo de aseguramiento y control de la calidad son independientes, pueden tomar una visión objetiva del proceso y reportar problemas y dificultades a los administradores principales de la organización. La administración de la calidad está separada de la administración de proyectos de manera que no esté comprometida con las responsabilidades de administración del presupuesto y la duración del proyecto. Un equipo independiente es responsable de administrar la calidad y reporta con la administración superior del nivel de administración del proyecto. El grupo de administración de la calidad, no está asociado con ningún grupo de desarrollo en particular sino que tiene la responsabilidad de la administración de la calidad en toda la organización. Un estándar internacional que se puede utilizar en el desarrollo de un sistema de administración de la calidad en todas las industrias es ISO 9000. Este es un conjunto de estándares que se aplican a una gran variedad de organizaciones, que van desde las manufacturas hasta las de industrias de servicios. Las normas ISO, describen varios aspectos del proceso de calidad y define estándares y procedimientos que deben existir dentro de una organización. Ya que éstas no se



refieren específicamente a una industria en particular, no están definidas en detalle. Dentro de una organización específica, el conjunto de procesos de calidad apropiados se define y documenta en un manual de calidad organizacional.

Responsabilidad de la administración Sistema de cal idad Control de productos inapropiados Control de diseño Manejo, almacenaje, embalaje y suministro Compras Productos suministrados al comprador Identificación del producto y

seguimiento Control de proceso Inspección y pruebas Equipo de inspección y prueba Status de la inspección y las

pruebas Revisión del contrato Acción correctiva Control del documento Registros de calidad Auditoria de calidad interna Capacitación Servicios Técnicas estadísticas Aseguramiento y estándares de calidad Las actividades de aseguramiento de la calidad (QA) definen un marco de trabajo para lograr la calidad del software. Los procesos de QA comprenden definir o seleccionar estándares aplicables al proceso de desarrollo de software o a los productos de software. Estos estándares pueden estar incrustados en procedimientos o procesos aplicables durante el desarrollo. Los procesos se pueden apoyar en herramientas que capturan el conocimiento de los estándares de calidad. Existen dos tipos de estándares que se establecen como parte del proceso de aseguramiento de la calidad: 1. Estándares del producto: Estos son estándares que aplican al producto de

software a desarrollar. Incluyen estándares de documentos, como la estructura del documento de requerimientos a producir, estándares de documentación, como encabezados, estándar de comentarios para una definición de clases de objetos y estándares de dosificación que definen cómo utilizar un lenguaje de programación.

2. Estándares del proceso: Estos son estándares que definen los procesos a seguir

durante el desarrollo del software. Incluyen definiciones de los procesos de especificación de diseño y de validación y una descripción de los documentos a generar en el transcurso de estos procesos.

Existe una relación muy cercana entre los estándares de los procesos y del producto. Los estándares del producto se aplican a las salidas del proceso del software y los estándares del proceso incluyen actividades específicas del proceso que aseguran que se siguen en los estándares del producto.

Áreas cubiertas por el modelo ISO 9001 para el aseguramiento de la calidad



142

Existen varias razones de por qué los estándares de software son importante: 1. Proveen un conjunto compacto de las mejores prácticas o al menos de las más

apropiadas. Este conocimiento sólo se adquiere después de seguir un proceso de prueba y error. Tenerlo constituido en un estándar evita la repetición de errores anteriores. Los estándares capturan el conocimiento de valor para la organización.

2. Proveen un marco de trabajo alrededor del cual se implementa el proceso de

aseguramiento de la calidad. Dado que los estándares capturan las mejores prácticas, el control de la calidad sencillamente asegura que los estándares se siguen adecuadamente.

3. Ayudan a la continuidad cuando una persona lleva a cabo el trabajo y otra lo

continúa. Los estándares aseguran que todos los analistas dentro de una organización adopten las mismas prácticas. Por consiguiente se reduce el esfuerzo de aprendizaje cuando se comienza un trabajo nuevo.

Los equipos de aseguramiento de la calidad que desarrollan los estándares, se apoyan en estándares organizacionales basados en estándares nacionales e internacionales. Utilizando estos estándares como punto de partida, el equipo de aseguramiento de la calidad debe crear un “manual” de estándares. Algunos consideran que los estándares como burocráticos o irrelevantes para las actividades técnicas de desarrollo de software; aunque muchos están de acuerdo en que los estándares son necesarios. Para evitar estos problemas, los administradores de la calidad que fijan los estándares requieren estar informados y tomar en consideración los siguientes pasos: 1. Involucrar a los ingenieros de software en el desarrollo de los estándares del

producto. Así comprenderán la motivación detrás del desarrollo de los estándares y se comprometen con ellos. El documento de los estándares no debe establecer simplemente que se sigan los estándares sino que deben incluirse razones de por qué se tomaron decisiones particulares.

2. Revisar y modificar los estándares de forma regular con el fin de reflejar las

tecnologías cambiantes. Una vez que los estándares se desarrollan, tienden a plasmarse en un manual de estándares de la compañía y a menudo existe una reticencia a cambiarlos. Un manual de estándares es esencial pero debe evolucionar acorde a las circunstancias y la tecnología cambiante.

3. Proveer herramientas de software para apoyar a los estándares donde sea

necesario. Los estándares del proceso provocan dificultades si se impone un proceso no práctico en el equipo de desarrollo. A menudo tales estándares simplemente dan lineamientos



que deben interpretarse por los administradores de los proyectos. El administrador de cada proyecto tiene la autoridad de modificar los estándares del proceso de acuerdo con las circunstancias individuales. Sin embargo, los estándares relacionados con la calidad del producto y el proceso de postentrega, sólo deben cambiarse después de consideraciones cuidadosas. El administrador del proyecto y el de la calidad pueden evitarse los problemas de los estándares inapropiados si planean cuidadosamente la calidad. Tienen que crearse estándares nuevos como respuesta a un requerimiento particular del proyecto. Se deben seguir estos nuevos estándares para evolucionar durante el proyecto.

Estándares del producto Estándares del proceso Formulario para revisión del diseño Conducto para la revisión del diseño Formato del encabezado del procedimiento

Proceso de entrega de las versiones

Estilo de programación en Java Proceso de aprobación del plan del proyecto

Formato del plan del proyecto Proceso de control del cambio Forma de petición de cambios Proceso de registro de las pruebas Estándares de documentación Los estándares de documentación en un proyecto de software son documentos muy importantes ya que son la única forma tangible de representar al software y al proceso del software. Los documentos estandarizados tienen una apariencia, estructura y calidad consistentes, y por lo tanto son más fáciles de leer y de comprender. Existen tres tipos de estándares de documentación: 1. Estándares del proceso de documentación: Estos definen el proceso a seguir

para la producción del documento. 2. Estándares del documento: Estos gobiernan la estructura y presentación de los

documentos. 3. Estándares para el intercambio de documentos: Estos aseguran que todas las

copias electrónicas de los documentos sean compatibles. Los estándares del proceso definen el proceso utilizado para producir los documentos. Esto implica definir los procedimientos involucrados en el desarrollo del documento y las herramientas de software utilizadas para la producción del documento. También definen procedimientos de comprobación y refinamiento que aseguren que se produzcan documentos de alta calidad.



144

Los estándares de calidad del proceso de documentos deben ser flexibles y les debe ser posible ajustarse a todos los tipos de documentos. Los estándares del documento aplican a todos documentos producidos en el transcurso del desarrollo de software. Los documentos deben tener un estilo y una apariencia consistente y los documentos del mismo tipo deben tener una estructura consistente. Algunos ejemplos de estándares de documentos a desarrollar son: 1. Estándares de identificación de documentos: Puesto que los proyectos de

sistemas grandes producen cientos de documentos, cada documento debe identificarse de forma única. Para los documentos formales, este identificador es el identificador formal definido por el administrador de la configuración. Para documentos informales, el estilo del identificador del documento es definido por el administrador del proyecto.

2. Estándares de la estructura del documento: Cada clase de documentos

producida durante un proyecto de software debe seguir alguna estructura estándar. Los estándares de estructura deben definir las secciones a incluir y especificar las convenciones utilizadas para la numeración de páginas, el encabezado de las páginas y la información de los pies de página, así como la numeración de secciones y subsecciones.

3. Estándares de presentación de documentos: Estos estándares definen un “estilo

propio” para los documentos y contribuyen en forma importante a la consistencia de los mismos. Incluyen la definición de tipos de letra y estilos utilizados en el documento, la utilización de logotipos y los nombres de la compañía, colores, etc.

4. Estándares para actualizar los documentos: Conforme el documento evoluciona

y refleja los cambios en el sistema, se debe utilizar una forma consistente para indicar los cambios en el documento. Se pueden utilizar diversos colores de la portada para indicar una nueva versión del documento y cambiar las barras en el margen para indicar párrafos modificados o agregados.

Los estándares de intercambio de documentos son importantes debido a que se pueden intercambiar copias electrónicas de los documentos. La utilización de estándares de intercambio permite que los documentos se transfieran electrónicamente y puedan reconstruirse en su forma original. Los estándares de intercambio también delimitan los tipos de letra y los estilos del texto utilizados debido a la existencia de diversos recursos de despliegue e impresión. Calidad del proceso y del producto Una suposición de la administración de la calidad, es que la calidad del proceso de desarrollo afecta directamente a la calidad de los productos a entregar. La calidad del proceso es muy importante en el desarrollo del software. La razón de esto es que es difícil medir los atributos de software, como la mantenibilidad, sin utilizar el software por



un período largo. El mejoramiento de la calidad se centra en identificar buenos productos de calidad, examinar el proceso utilizado para desarrollar estos productos y después generalizar estos procesos para que se apliquen a varios proyectos. La relación entre el proceso del software y la calidad del producto de software es muy compleja. Cambiar el proceso no siempre conduce a mejorar la calidad del producto. Existe un vinculo claro entre la calidad del proceso y la calidad del producto en la manufactura, ya que el proceso es relativamente fácil de estandarizar y supervisar. El software no se manufactura, se diseña, debido a que el desarrollo de software es un proceso creativo más que mecánico, la influencia de las habilidades individuales y la experiencia es importante. Los factores externos, como la novedad de la aplicación o la presión comercial para entregar un producto, también afectan la calidad del producto con respecto al proceso utilizado. La calidad del proceso tiene una influencia importante en la calidad del software. La administración de la calidad del proceso comprende: 1. Definir estándares de proceso como las revisiones a realizar, cuándo llevarlas a

cabo, etc. 2. Supervisar el proceso de desarrollo para asegurar que se sigan los estándares. 3. Hacer informes del proceso para la administración del proyecto y para el comprador

del software. Un peligro del aseguramiento de la calidad basada en procesos es que el proceso preescrito puede ser inapropiado para el tipo de software a desarrollar. Por ejemplo, los estándares de calidad del proceso pueden indicar que una especificación debe estar completa y aprobada antes de que la implementación se inicie; pero algunos sistemas requieren la construcción de prototipos, lo cual implica la implementación del programa. El equipo de calidad puede indicar que ese prototipo no se puede llevar a cabo debido a que su calidad no se puede supervisar. En tales condiciones el administrador principal debe intervenir para asegurar que el proceso de calidad ayude más que impida el desarrollo del producto. Planeación de la calidad La planeación de la calidad se inicia en las primeras etapas del proceso del software. Un plan de calidad define la calidad del producto deseado. Define como valorar esta calidad, define lo que significa software de “alta calidad”. Sin tal definición los integrantes del equipo de calidad pueden trabajar en direcciones opuestas de tal forma que optimicen distintos atributos del producto. El resultado de un proceso de planeación de la calidad es un plan de calidad del proyecto. Un plan de calidad selecciona aquellos estándares organizacionales apropiados para un producto en particular y un proceso en desarrollo. Si el proyecto utiliza nuevos métodos y herramientas, se tienen que definir nuevos estándares.



146

Podríamos definir una estructura para un plan de calidad, tal como se establece a continuación: 1. Introducción del producto: Contiene la descripción del producto, el mercado al que

se dirige y las expectativas de calidad del producto. 2. Planes del producto: Contiene las fechas de terminación del producto y las

responsabilidades importantes junto con los planes para distribución y servicio. 3. Descripciones del proceso: Contiene los procesos de desarrollo y de servicio a

utilizar para el desarrollo y administración del producto. 4. Metas de calidad: Contiene las metas y planes de calidad para el producto, incluye

una identificación y justificación de los atributos de calidad importantes del producto. 5. Riesgos y administración de riesgos: Contiene los riesgos clave que podrían

afectar la calidad del producto y las acciones para abordar estos riesgos. Cuando se redactan planes de calidad, es necesario tratar de mantenerlos lo más compactos posibles. Si el documento es muy grande, es muy probable que no se leerá y esto frustra el propósito de producir un plan de calidad. Existe un amplio rango de atributos de calidad potenciales del software (tal como se detallan en el cuadro a continuación) a considerar durante el proceso de planeación de la calidad. En general, no es posible optimizar todos estos atributos para un sistema, por lo que una parte importante de la planeación de la calidad es seleccionar los atributos de calidad importantes y planear como alcanzarlos. Seguridad Comprensión Portabilidad Protección Experimentación Usabilidad Fiabilidad Adaptabilidad Reutilización Flexibilidad Modularidad Eficiencia Robustez Complejidad Aprendizaje El plan de calidad define los atributos de calidad más importantes para el producto a desarrollar. Puede ser que la eficiencia sea primodial por lo que será necesario sacrificar otros factores para alcanzarla. El plan también define, el proceso de valoración de la calidad. Es una forma de valorar si algún punto de la calidad, como la mantenibilidad, está presente en el producto.

Atributos de calidad del software



Control de calidad El control de la calidad implica vigilar el proceso de desarrollo de software para asegurar que se sigan los procedimientos de aseguramiento y estándares de calidad. Los productos resultantes de un proceso del software se comprueban contra los estándares definidos del proyecto en el proceso de control de calidad. El proceso de control de calidad tiene su propio conjunto de procedimientos e informes a utilizar durante el desarrollo de software. Estos procedimientos son directos y fácilmente comprensibles por parte del equipo de desarrolla el software. Existen dos enfoques complementarios para el control de la calidad: 1. Revisiones de la calidad en las que el software, su documentación y los procesos

utilizados para producir ese software, son revisados por un grupo de personas. Son responsables de comprobar que se has seguido los estándares del proyecto y que el software y los documentos están acordes a estos estándares. Toman las desviaciones de los estándares y las ponen a consideración de la administración del proyecto.

2. Valoración automática del software en la que el software y los documentos

producidos se procesan por algún programa y se comparan con los estándares que aplican a ese proyecto de desarrollo en particular.

Revisiones de la calidad Las revisiones son el método más utilizado para validar la calidad de un proceso o producto. Involucran a un grupo de personas que examinan parte o todo el proceso del software, los sistemas o su documentación asociada para descubrir problemas potenciales. Las conclusiones de la revisión se registran formalmente y se pasan al autor o a quién sea responsable de corregir los problemas descubiertos. El cometido del equipo de revisión es detectar los errores e inconsistencias y señalarlas al diseñador o autor del documento. Las revisiones se basan en documentos pero no se limitan a las especificaciones, diseños o código. Se revisan todos los documentos tales como los modelos del proceso, los planes de prueba, los procedimientos de administración de la configuración, los estándares del proceso y los manuales del usuario. El equipo de revisión incluye aquellos miembros del proyecto que pueden hacer una contribución efectiva. Si se revisa el diseño de un subsistema, los diseñadores de los subsistemas relacionados se incluyen en el equipo de revisión. Ellos proporcionan aspectos importantes en las interfaces del subsistema que podrían estar olvidadas si el subsistema se considera de forma aislada.



148

Tipo de revisión Propósito principal Inspecciones de diseño o programas

Detectar errores finos en los requerimientos, el diseño o el código. La revisión se conduce por una lista de verificación de los posibles errores.

Revisiones de progreso

Proveer información para administrar el progreso completo del proyecto. Esta es una revisión tanto del proceso como del producto y se refiere a los costos, planes y calendarización.

Revisiones de calidad Llevar a cabo un análisis técnico de los componentes del producto o documentación para encontrar diferencias entre la especificación y el diseño del componente, código y documentación para asegurar que se siguen los estándares de calidad definidos.

El equipo de revisión tiene un cuerpo principal de tres a cuatro personas designadas como revisores principales. Uno de los miembros es el diseñador principal que tiene la responsabilidad de tomar las decisiones técnicas importantes. Los revisores principales invitan a otros miembros del proyecto para que contribuyan en la revisión. Ellos no se involucran en la revisión de todo el documento, sino en aquellas partes que afectan a su trabajo. La revisión misma es relativamente corta. El autor del documento en revisión debe seguir el documento junto con el equipo de revisión. Al término de la revisión se anotan las acciones y los formularios que registran los comentarios y las acciones son firmados por el diseñador y el precedente de la revisión. Si sólo se descubren problemas menores, no es necesario una revisión adicional. Si se requieren cambios importantes, se acuerda un seguimiento de la revisión.

Tipos de revisión



Texto 6

Administración de la configuración La administración de la configuración (CM) es el desarrollo y aplicación de estándares y procedimientos para administrar un producto evolutivo de sistemas. Es necesario administrar los sistemas evolutivos debido a que, cuando evolucionan, se crean varias versiones diferentes del software. Estas versiones contienen propuestas para el cambio, correcciones de fallas y adaptaciones para hardware y sistemas operativos diferentes. Pueden existir varias versiones bajo desarrollo y en uso al mismo tiempo. Por esto es necesario llevar un registro de los cambios implementados y de la manera en que éstos se han incluido en el software. Los procedimientos de administración de la configuración definen cómo registrar y procesar los cambios propuestos al sistema, como relacionar éstos con los componentes del mismo y los métodos utilizados para identificar las diversas versiones de aquel. Las herramientas de administración de la configuración se utilizan para almacenar las versiones de los componentes del sistema, construirlos a partir de estos componentes y llevar un registro de las liberaciones de las versiones del sistema. Algunas veces, la administración de la configuración es parte de un proceso general de administración de la calidad del software. El mismo administrador comparte las responsabilidades de administración de la calidad y de la configuración. Los desarrolladores del software entregan éste al equipo de aseguramiento de la calidad quienes son responsables de la comprobación de que el sistema es de calidad aceptable. Después se pasa al equipo de administración de la configuración, quién es responsable de controlar los cambios al software. Los sistemas controlados se denominan “líneas base” puesto que son el punto de inicio para la evolución controlada. Los administradores de la configuración son responsables de llevar los registros de las diferencias entre las versiones de software, para asegurar que las nuevas versiones se deriven de forma controlada y para entregar las nuevas versiones a los clientes correctos y en el momento justo. El proceso de administración de la configuración y la documentación asociada se basa en estándares. Dentro de la organización estos estándares se publican en un manual de administración de la configuración o como parte del manual de calidad. Los estándares externos se utilizan como base para estándares organizacionales detallados por lo que se ajustan a un entorno específico. En un proceso tradicional de desarrollo de software, éste se entrega al equipo de administración de la configuración, después de que el desarrollo se completa y se prueban los componentes de software. Luego este equipo toma la responsabilidad de construir el sistema completo y administrar las pruebas del sistema. Las fallas encontradas durante las pruebas del sistema se llevan de regreso al equipo de



150

desarrollo para su reparación. A continuación reparan la falla y entregan una nueva versión del componente reparado al equipo de administración de la configuración. Este enfoque ha influido en el desarrollo de los estándares de administración de la configuración. Esto significa que no se pueden aplicar enfoques alternativos para el desarrollo de software, como la construcción de prototipos. Para ajustarse a este estilo de desarrollo, algunas organizaciones han desarrollado un enfoque modificado para administrar la configuración que permite el desarrollo concurrente y las pruebas del sistema. Este enfoque se basa en la forma regular de construcción del sistema completo a partir de sus componentes: 1. La organización que lleva a cabo el desarrollo fija una hora de entrega de los

componentes del sistema. Si los desarrolladores tienen nuevas versiones escritas de los componentes, entonces deben entregarlos todos a esa hora. Los componentes podrían estar incompletos pero deben ser capaces de proveer alguna funcionalidad básica que se pueda probar.

2. Una nueva versión del sistema se construye a partir de estos componentes

compilándolos y vinculándolos para formar un sistema completo. 3. El sistema se entrega al equipo de pruebas que lleva a cabo un conjunto predefinido

de pruebas al sistema. Al mismo tiempo, los desarrolladores siguen trabajando en sus componentes, agregando funcionalidad y reparando las fallas descubiertas en las pruebas previas.

4. Las fallas encontradas durante las pruebas del sistema se documentan y devuelven

a los desarrolladores del sistema. Éstos reparan dichas fallas en una versión subsecuente del componente.

Las principales ventajas de utilizar construcciones diarias del software son que incrementan las oportunidades de encontrar problemas que surgen a partir de las interacciones al inicio del proceso. Más aún, las construcciones diarias provocan las pruebas de las unidades de los componentes. Los desarrolladores se ponen bajo presión, para no entregar versiones de los componentes que provoquen una falla en todo el sistema. Por lo tanto, son renuentes a entregar nuevas versiones de los componentes que no se hayan probado en forma adecuada. Se invierte menos tiempo en las pruebas del sistema si se encuentran fallas en el software y éstas se abordan durante las pruebas de las unidades. La utilización exitosa de las construcciones diarias requieren de procesos de administración del cambio muy rigurosos para llevar un registro de los problemas encontrados y resueltos. También conduce a la administración de un número muy grande de versiones de sistemas y componentes. La buena administración de la configuración es esencial para que este enfoque sea exitoso. Planeación de la administración de la configuración



Un plan de administración de la configuración describe los estándares y procedimientos utilizados para la administración de la configuración. El punto de inicio para desarrollar el plan es un conjunto de estándares generales de administración de la configuración de toda la compañía adaptables a cada proyecto específico. El plan de la administración de la configuración se organiza en varias etapas que incluyen: 1. La definición de las entidades a administrar y el esquema formal para identificar

estas entidades 2. Un enunciado de quién toma la responsabilidad de los procedimientos de

administración de la configuración y quién envía las entidades controladas al equipo de administración de la configuración.

3. Las políticas de administración de la configuración utilizadas para administrar el

control de los cambios y las versiones 4. Una descripción de los registros del proceso de administración de la configuración a

los que debe darse mantenimiento. 5. Una descripción de las herramientas a utilizar para la administración de la

configuración y el proceso a aplicar cuando se utilizan estas herramientas. 6. Una definición de la base de datos de la configuración que se utilizará para registrar

la información de la configuración. En el plan de la administración de la configuración (CM) se incluye información adicional de la administración del software por parte de los proveedores externos y los procesos de auditoria para el proceso de CM. Una parte importante del plan de la CM es la definición de responsabilidades. Define quién es el responsable de la entrega de cada documento o de cada componente de software para el aseguramiento de la calidad y la administración de la configuración. Define también los revisores de cada documento. La persona responsable de la entrega de los documentos no necesariamente es la misma que produce el documento. Para simplificar las interfaces, a menudo es conveniente hacer que los administradores de proyectos o líderes del equipo sean responsables de todos los documentos producidos por su equipo. Identificación del elemento de la configuración En el transcurso del desarrollo de sistemas de software grandes, se producen cientos de documentos. Muchos de éstos son documentos técnicos de trabajo que presentan una instantánea de las ideas a desarrollar. Estos documentos están sujetos a cambios frecuentes y regulares. Otros documentos son memorandums internos, propuestas, etc. Estos documentos son de interés para definir la historia del proyecto. Sin embargo no son necesarios para el futuro mantenimiento del sistema.



152

Durante el proceso de planeación de la administración de la configuración, se decide exactamente qué elementos se van a controlar. Los documentos o grupos de documentos relacionados del control de la configuración son documentos que son necesarios para el mantenimiento futuro del sistema. El esquema de asignación de nombres a los documentos debe asignar un nombre único a todos los documentos de control de la configuración. Siempre existen relaciones entre estos documentos. El problema con los esquemas de asignación de nombres de este tipo es que se basan en proyectos. Los identificadores asocian componentes a un proyecto particular. Esto reduce las oportunidades de reutilización. Las copias de componentes reutilizables normalmente se eliminan del esquema y se renombran de acuerdo con su dominio de aplicación. Los usuarios de los documentos tienen que conocer su nombre para encontrarlos y no todos los documentos del mismo tipo, se colocan en el mismo lugar. La base de datos de la configuración La base de datos de la configuración se utiliza para registrar toda la información relevante relacionada con las configuraciones. Sus funciones principales son ayudar a la evaluación del impacto de los cambios en el sistema y proveer información de la administración acerca el proceso de la CM. Además de definir el esquema de la base de datos de la configuración como parte del proceso de planeación de la CM, también se deben definir los procedimientos para registrar y recuperar la información del proyecto. A una base de datos de la configuración le debe ser posible suministrar respuestas a una variedad de consultas acerca de las configuraciones del sistema. Un ejemplo de las consultas que se podrían hacer son las siguientes: 1. ¿A qué clientes se les ha entregado una versión particular del sistema?

2. ¿Qué configuraciones de hardware y del sistema operativo se requiera par ejecutar

una versión del sistema?

3. ¿Cuántas versiones del sistema se ha creado y cuáles son sus fechas de creación

4. ¿Cuántas fallas reportadas existen en una versión particular?.

De forma ideal, la base de datos de la configuración se integra al sistema de administración de las versiones utilizado para almacenar y administrar los documentos formales del proyecto. Este enfoque, hace posible vincular los cambios de forma directa con los documentos y componentes afectados por el cambio. Se da mantenimiento a los vínculos entre los documentos, como los documentos de diseño, y el código del programa con el fin de que sea relativamente fácil encontrar todo lo que debe modificarse cuando se propone un cambio.



Administración del cambio El cambio en un hecho en la vida de los sistemas de software grandes. Las necesidades organizacionales y los requerimientos cambian durante el tiempo de vida de un sistema. Un proceso definido de la administración del cambio y las herramientas CASE asociadas asegura que estos cambios se registren y apliquen al sistema de forma costeable. El proceso de administración del cambio se lleva a cabo cuando el software o la documentación asociada se pone bajo el control del equipo de administración de cambio. Se inicia durante las prueba del sistema o después de que el software se entrega a los clientes. Los procedimientos de administración de cambios se diseñan para asegurar que los costos y beneficios del cambio se realicen adecuadamente y que se hagan los cambios al sistema de una forma controlada. La primera etapa del proceso de administración del cambio es completar un formulario de solicitud de cambios en el cual el solicitante señala los cambios requeridos al sistema. Además de registrar los cambios requeridos el formulario registra las recomendaciones pertinentes al cambio, los costos estimados del cambio y las fechas de cuando se solicita, prueba, implementa y valida el cambio. También incluye una sección donde el encargado de mantenimiento señala como implementar el cambio. Las solicitudes de cambio se registran en la base de datos de la configuración, así el equipo de CM puede registrar el estado de las solicitudes de cambio y las solicitudes de cambio asociadas con los componentes de software específicos. Una vez que se emitió el formulario, se analiza para comprobar que el cambio es válido. Algunos pedidos de cambio se deben a los malos entendidos, más que a las fallas del sistema, otros se refieren a fallas ya conocidas. Si el análisis descubre que el cambio solicitado es inválido, duplicado o ya ha sido considerado, el cambio se rechaza. La razón del rechazo se devuelve a la persona que emitió la solicitud del cambio. Para cambios válidos la siguiente etapa del proceso es evaluar y asignar costos al cambio. El impacto del cambio en el resto del sistema se comprueba. Se realiza un análisis técnico de cómo implementar el cambio. Se estima el costo de realizar el cambio y la posibilidad de cambiar otros componentes del sistema para acomodar el cambio. Esto se registra en el formulario de solicitud de cambio. En este proceso de evaluación se utiliza la base de datos de la configuración donde se registran las interrelaciones de los componentes. Después del impacto del cambio en los otros componentes se toma en consideración. A menos que el cambio simplemente comprenda la corrección de errores menores, como despliegues en pantalla o similar, se reúne un consejo de control de cambios quien decide si se acepta o no el cambio. Este consejo considera el impacto del cambio desde el punto de vista estratégico y organizacional más que desde el punto de vista técnico. Decide si el cambio se justifica económicamente y su existen buenas razones organizacionales para aceptarlo.



154

Cuando se aprueba un conjunto de cambios, el software se entrega al equipo de desarrollo o mantenimiento para su implementación. Una vez que esto se completa, el software revisado se vuelve a evaluar para comprobar que estos cambios se implementaron correctamente. Cuando se crean las nuevas versiones del sistema por medio de una construcción diaria, se utiliza un proceso de administración del cambio sencillo. Los problemas en los cambios aún deben registrarse, pero los cambios que sólo afectan a los componentes y módulos individuales no necesitan ser evaluados de forma independiente. Se pasan directamente al desarrollador del sistema. Los cambios que afectan a los módulos del sistema producidos por diferentes equipos de desarrollo son evaluados por alguna autoridad de control de cambio quien decide si se implementan. Conforme se cambian los componentes del software, se da mantenimiento al registro de los cambios realizados a cada componente. Algunas veces éstos se denominan la historia del componente. Se utilizan herramientas especializadas para procesar la historia y producir informes en los cambios o en los componentes. Administración de versiones y liberaciones La administración de las versiones y liberaciones es el proceso de identificar y mantener registros de las diversas versiones y liberaciones de un sistema. Los administradores de las versiones diseñan procedimientos para asegurar que las diversas versiones de un sistema se puedan recuperar cuando se requieran y que no se cambien de forma accidental. También trabajan en coordinación con los clientes para planear cuando deben distribuirse las nuevas versiones. Éstas siempre son creadas por el equipo de la CM en lugar de los desarrolladores del sistema, aún cuando no se pretenda liberarlas al exterior. Esto hace mas fácil de mantener la consistencia en la base de datos puesto que sólo el equipo de la CM puede cambiar la información de las versiones. Una Versión de un sistema es una versión que se distribuye a los clientes. Cada liberación incluye nueva funcionalidad o está concebida para diferentes plataformas de hardware. Siempre existen más versiones de un sistema que las liberaciones puesto que las versiones se crean dentro de una organización para el desarrollo interno o pruebas y nunca se entregan a los clientes. En la actualidad, la administración de versiones se apoya en herramientas CASE. Éstas herramientas administran el almacenamiento de cada versión del sistema y controlan el acceso a los componentes del sistema. Se apoyan en el sistema para llevar a cabo las ediciones. Cuando los componentes se reintroducen en el sistema, se crea una nueva versión y el sistema de administración de versiones le asigna nombre. Identificación de versiones Dentro de un sistema de software grande, existen cientos de componentes de software, cada uno de los cuales existe en muchas versiones diferentes. Los procedimientos para la administración de las versiones deben definir una forma no ambigua de identificar



cada versión de los componentes. Las versiones específicas de los componentes después se pueden recuperar cuando se requieran para cambios posteriores. Existen tres técnicas básicas utilizadas para la identificación de componentes: 1. Numeración de las versiones: Al componente se le asigna un número de versión

explícito y único. Éste es el esquema de identificación más utilizado. 2. Identificación basada en atributos: Cada componente tiene un nombre (que no es

único a lo largo de las versiones) y un conjunto asociado de atributos difieren para cada versión del componente. Por lo tanto, los componentes se identifican por la combinación de un conjunto de nombres y atributos.

3. Identificación orientada al cambio: Cada sistema se nombra con base en la

identificación de atributos, pero también se asocia o una o más solicitudes de cambios. La versión del sistema se identifica asociando el nombre con los cambios implementados en el componente.

Numeración de versiones En un esquema sencillo de numeración de versiones, al nombre del componente o del sistema se le asigna un número de versión. El esquema es lineal y se basa en la suposición de que las versiones del sistema se crean en secuencia. Muchas herramientas de administración de versiones, permiten esta forma de identificación de versiones. Identificación basada en atributos Un problema fundamental y común con los esquemas explícitos de asignación de nombres de las versiones es que no reflejan los muchos atributos diferentes utilizados para identificar las versiones. A continuación damos algunos ejemplos de estos atributos que permiten la identificación: • El cliente

• El lenguaje de desarrollo

• El estado del desarrollo

• La plataforma de hardware

• La fecha de creación

Si cada versión es identificada por un conjunto único de atributos, es fácil agregar nuevas versiones derivadas a partir de cualquiera de las versiones existentes. Éstas se identifican utilizando un conjunto único de valores de los atributos. Comparten muchos de estos valores con sus versiones padre por lo que se conserva la relación entre las



156

versiones. Las versiones se recuperan especificando los valores de los atributos requeridos. Identificación orientada al cambio La identificación basada en atributos de las versiones del sistema elimina algunos de los problemas de la recuperación de versiones encontradas en los esquemas sencillos de numeración. Sin embargo, para recuperar una versión se tienen que conocer los atributos asociados. Se necesita utilizar un sistema de administración del cambio independiente para descubrir las relaciones entre las versiones y los cambios. La identificación orientada al cambio se utiliza para los sistemas más que para los componentes, por lo que las versiones de los componentes individuales están ocultas a los usuarios del sistema de la CM. Cada cambio del sistema propuesto tiene un conjunto de cambios asociado que describe los cambios realizados a los diferentes componentes del sistema para implementar este cambio. Los conjuntos de cambios se aplican en secuencia por lo que, al menos en principio, se puede crear una versión del sistema que incorpore cualquier conjunto arbitrario de cambios. Por lo tanto no se requiere ninguna identificación explicita de la versión. El equipo de la CM interactúa con el sistema de administración de versiones de forma indirecta a través del sistema de administración de cambios. En la práctica, no es posible aplicar conjuntos arbitrarios de cambios a un sistema. Los diversos conjuntos de cambios pueden ser incompatibles. Los conjuntos de cambios pueden entrar en conflicto debido a que los diversos cambios afectan el mismo código del sistema. Para enfrentar estas dificultades, las herramientas de administración de versiones que apoyan a la identificación orientada a cambios permiten especificar las reglas de consistencia que delimitan las formas de combinar los conjuntos de cambios. Administración de las liberaciones Una liberación del sistema es una versión del sistema que se distribuye a los clientes. Los administradores de liberaciones del sistema son los responsables de decidir cuando se libera el sistema, de administrar el proceso de creación de las entregas y de los medios de distribución y documentación de la liberación para asegurar que se puedan recuperar de la misma forma en que se distribuyen, en caso de ser necesario. Una liberación del sistema no es sólo el código ejecutable del sistema. Las liberaciones también incluyen: 1. Los archivos de configuración que definen cómo configurar el sistema para

instalaciones específicas. 2. Los archivos de datos necesarios para la operación exitosa del sistema. 3. Un programa de instalación utilizado para ayudar a instalar el sistema en el

hardware correspondiente. 4. La documentación electrónica y en papel que describe al sistema.



5. El embalaje y la publicidad asociadas diseñados para esta liberación. Los administradores de las liberaciones no pueden suponer que los clientes siempre instalarán las nuevas versiones del sistema. Algunos usuarios del sistema están a gusto con una versión existente del sistema. Consideran que no vale la pena gastar en cambiar a una nueva liberación. Por lo tanto las nuevas liberaciones del sistema no pueden depender de la existencia de liberaciones previas. El distribuidor de software no puede suponer que los archivos requeridos para la liberación 3 se han instalado en todos los lugares. Algunos clientes van directamente de la liberación 1 a la liberación 3, saltándose la liberación 2. Toma de decisiones de la liberación Preparar y distribuir una liberación del sistema es un proceso costoso, particularmente para los productos de software de mercados en masa. Si las liberaciones son muy frecuentes, los clientes pueden no actualizarse a las nuevas; si no son muy frecuentes, el mercado se puede perder puesto que los clientes consideran sistemas alternativos. Por supuesto que esto no aplica para el software desarrollado específicamente para una organización. Sin embargo para este tipo de software, las liberaciones no frecuentes significan un crecimiento divergente entre el software y los procesos de negocios que pretenden apoyar. Las decisiones sobre cuando liberar una nueva versión del sistema están gobernadas por las consideraciones técnicas y organizacionales tal como se muestra en el cuadro a continuación:

Factor Descripción Calidad técnica Si se reportan fallas que afecten la forma en la que

los clientes utilizan el sistema, es necesario emitir una versión para reparar la falla. Sin embargo, las fallas menores del sistema se reparan mediante parches (a menudo distribuidos por internet), que se aplican a las liberaciones actuales del sistema.

Competencia Se necesita una nueva versión del sistema cuando está disponible el producto competidor.

Requerimientos de marketing

El departamento de marketing de una organización hace el compromiso de tener listas las liberaciones en una fecha particular

Propuestas de cambio de los clientes

Para sistemas personalizados, los clientes hacen un pago por un conjunto específico de cambios en el sistema y esperan a que el sistema se entregue tan pronto como estos cambios se implementen.

Factores que influyen en la estrategia de liberaciones del sistema



158

Creación de la liberación La creación de las liberaciones es el proceso de crear una colección de archivos y documentación que incluyen todos los componentes de la liberación del sistema. El código ejecutable de los programas y todos los archivos de datos asociados se agrupan e identifican. Las descripciones de la configuración se tienen que escribir para diferente hardware y sistemas operativos y las instrucciones preparadas para los clientes que necesiten configurar sus propios sistemas. Si se liberan manuales, las copias electrónicas deben almacenarse con el software. Las guías para la instalación del programa tienen que escribirse. Finalmente cuando toda la información está disponible, se prepara un disco de liberación para la distribución. Documentación de las liberaciones Cuando se produce la liberación de un sistema, debe estar documentada para asegurar que se puede reconstruir exactamente en el futuro. Esto es particularmente importante para los sistemas personalizados de larga vida. Los clientes utilizan una sola liberación de estos sistemas por muchos años y requieren cambios específicos para una liberación particular del software mucho después de la fecha de liberación original. Para documentar una liberación se tienen que registrar las versiones específicas de los componentes del código fuente utilizados para crear el código ejecutable. Se deben mantener también copias del código fuente y ejecutable y de todos los archivos de datos y de configuración. También deben registrarse las versiones del sistema operativo, las bibliotecas, los compiladores y otras herramientas utilizadas para construir el sistema. Estos pueden requerirse para construir exactamente el mismo sistema en alguna fecha posterior. En estos casos, las copias de las plataformas de software y las herramientas también se almacenan en un sistema de administración de versiones. Herramientas CASE para administración de la configu ración Los procesos de administración de la configuración por lo general están estandarizados e involucran la aplicación de procedimientos predefinidos. Requieren de la administración cuidadosa de grandes cantidades de datos y la atención a los detalles es esencial. Cuando se construye un sistema a partir de las versiones de los componentes, un simple error en la administración de la configuración puede implicar que el software no trabaje de forma adecuada. Las herramientas CASE de apoyo son esenciales para la administración de la configuración.



Apoyo a la administración del cambio Cada persona involucrada en el proceso de administración del cambio es responsable de alguna actividad. Una vez que completa esta actividad pasa los formularios y elementos de configuraciones asociados a otra persona. La naturaleza de procedimiento de este proceso significa que un cambio en el modelo del proceso se diseña e integra con un sistema de administración de versiones. Las herramientas de administración para el cambio proveen las siguientes características de apoyo al proceso: 1. Un editor de formularios que permite cambiar los formularios propuestos a crear y

llenar. 2. Un sistema de flujo de trabajo que permite al equipo de la CM especificar las

personas que deben procesar las solicitudes de pedidos de cambio y el orden del procesamiento. Este sistema también pasa de forma automática los formularios a las personas indicadas en el momento justo e informa a los miembros relevantes del equipo del progreso del cambio. El correo electrónico se utiliza para suministrar actualizaciones del progreso a aquellos involucrados en el proceso.

3. Una base de datos de cambios que se utiliza para administrar todas las

propuestas de cambio y que puede vincularse al sistema de administración de versiones.

Apoyo a la administración de versiones La administración de versiones involucra administrar grandes cantidades de información para asegurar que los cambios en el sistema se registren y controlen. Todos los sistemas de administración de versiones proveen un conjunto básico de capacidades comparables aunque algunos son más sofisticados que otros. A continuación se ven algunos ejemplos de estas capacidades: 1. Identificación de la versión y la liberación : A las versiones administradas se les

asignan identificadores cuando se introducen en el sistema. Varios sistemas permiten diferentes tipos de identificación de versiones.

2. Administración del almacenamiento: Para reducir el espacio de almacenamiento

requerido por las diferentes versiones, los sistemas de administración de versiones proveen las características de administración del almacenamiento donde las versiones se describen por sus diferencias a partir de alguna versión maestra.

3. Registro de la historia del cambio: Todos los cambios realizados al código de un

sistema o componente se registran y listan. En algunos sistemas, estos cambios se utilizan para seleccionar una versión particular del sistema.

4. Desarrollo independiente: Las diferentes versiones de un sistema se pueden

desarrollar en paralelo y cada versión cambia de forma independiente. El sistema de



160

administración de versiones mantiene un registro de los componentes que han sido extraídos para su edición y asegura que no interfieran los cambios que diferentes desarrolladores hayan hecho a los mismos componentes.

Apoyo a la construcción del sistema La construcción de sistemas es un proceso intensivo de computación. Si todos los componentes de un sistema grande se tienen que compilar y vincular, esto puede llevar varias horas. Puede haber cientos de archivos involucrados con la consecuente posibilidad de errores humanos si éstos se compilan y vinculan en forma manual. Las herramientas de construcción de sistema automatizan el proceso de construcción para reducir los errores humanos potenciales, y donde sea posible, disminuir el tiempo requerido para la construcción del sistema. Las herramientas de construcción del sistema pueden ser independientes o integradas con las herramientas de administración de las versiones. Las características suministradas por las herramientas CASE de construcción de sistemas son: 1. Una dependencia del lenguaje de especificación y de l intérprete asociado : Las

dependencias de los componentes se describen y se disminuye la recompilación. 2. Selección de herramientas y apoyo a cada etapa: Se especifican y se adaptan

como se requiera, los compiladores y otras herramientas de procesamiento utilizadas para procesar los archivos de código fuente.

2. Compilación distribuida : Algunos constructores de sistemas, permiten la

compilación distribuida en redes. En lugar de que todas las compilaciones se lleven a cabo en una sola máquina, los constructores de sistemas buscan los procesadores desocupados sobre la red y seleccionan varios compiladores en paralelo. Esto reduce dramáticamente el tiempo requerido para construir un sistema.

3. Administración de los objetos derivados : Los objetos derivados son objetos que

se crean a partir de otros objetos fuente. La administración de los objetos derivados vincula el código fuente y los objetos derivados y sólo vuelve a derivar un objeto cuando se requiere por los cambios del código fuente.

Algunos constructores de sistemas utilizan el archivo de la fecha de modificación como atributo clave para decidir si se requiere la recompilación. Si un archivo de código fuente se modifica después de su correspondiente archivo de código objeto, entonces este último se reconstruye.



Texto 7

Ciclo de vida de los sistemas Introducción , Proyec to Análisis y Diseño La situación actual en los sistemas informáticos se caracteriza por una rápida evolución de los componentes físicos (hardware), que incrementan continuamente sus prestaciones manteniendo o incluso disminuyendo sus precios, junto con una fuerte tendencia a la estandarización (computadoras personales, estaciones de trabajo con sistema operativo UNIX, sistemas distribuidos funcionando sobre plataformas heterogéneas, etc.) y una gran diversidad de marcas y modelos con prestaciones y precios similares. En este escenario, la potencia de las grandes computadoras de las décadas pasadas está hoy disponible en una minicomputadora e incluso en una PC (computadora personal). El software es el mecanismo que nos permite utilizar y explotar este potencial. Esto hace que, a la hora de plantearnos la adquisición de un sistema informático completo, ya sea para gestionar una escuela, para controlar un proceso industrial, o para uso doméstico, el software es lo que marca la diferencia. Entre varios productos de características físicas similares, nos decidiremos por uno basándonos en las prestaciones, inteligencia, calidad y facilidad de uso de su software. Por otra parte, el desarrollo de software no es una tarea fácil. La complejidad actual de los sistemas informáticos hace a veces necesario el desarrollo de proyectos software de decenas de miles de líneas de código. Esto no puede ser abordado directamente, empezando a programar directamente. Es necesario analizar qué es lo que tenemos que hacer, cómo lo vamos a hacer, cómo se van a coo rdinar todas las personas que van a intervenir en el proyecto y cómo vamos a controlar el desarrollo del mismo de forma que al final obtengamos los resultados esperados. Como vemos, el software es actualmente, dentro de cualquier sistema basado en el uso de computadoras, el componente cuyo desarrollo presenta mayores problemas: es el más difícil de planificar, el que tiene mayor probabilidad de fracaso, y el que tiene menos posibilidades de que se cumplan las estimaciones de costos iniciales. Por otra parte, la demanda de software (y también la complejidad del software que se demanda) aumentan continuamente, lo que aumenta la magnitud de estos problemas. De todas formas, no hay que ser pesimistas. El desarrollo de software es una actividad muy reciente (apenas tiene 50 años), si la comparamos con otras actividades de ingeniería (por ejemplo: la construcción de puentes o incluso la ingeniería eléctrica, de la que deriva la ingeniería de hardware), y la disciplina que se encarga de establecer un orden en el desarrollo de sistemas de software (esto es, la Ingeniería del Software) es aún más reciente. Existen buenos métodos de desarrollo de software pero quizás el problema esté en que no están lo suficientemente difundidos o valorados. Sólo recientemente, estas técnicas están logrando una amplia aceptación.



162

Hemos dicho que el software era el factor decisivo a la hora de elegir entre varias soluciones informáticas disponibles para un problema dado, pero esto no ha sido siempre así. En los primeros años de la informática, el hardware tenía una importancia mucho mayor que en la actualidad. Su costo era comparativamente mucho más alto y su capacidad de almacenamiento y procesamiento, junto con su fiabilidad, era lo que limitaba las prestaciones de un determinado producto. El software se consideraba como un simple añadido, a cuyo desarrollo se dedicaba poco esfuerzo y no se aplicaba ningún método sistemático. La programación era una actividad artesanal, y el desarrollo de software se realizaba sin ninguna planificación. La mayoría del software se desarrollaba y era utilizado por la misma persona u organización. La misma persona lo escribía, lo ejecutaba y, si fallaba, lo depuraba. Debido a que la rotación de personal era baja, los directivos estaban seguros de que esa persona estaría allí cuando se encontrara algún error. Debido a este entorno personalizado del software, el diseño era un proceso implícito, realizado en la mente de alguien y la documentación normalmente no existía. En este contexto, las empresas de informática se dedicaron a mejorar las prestaciones del hardware, reduciendo los costos y el consumo de los equipos, y aumentando la velocidad de cálculo y la capacidad de almacenamiento. Para ello, tuvieron que dedicar grandes esfuerzos a investigación y aplicaron métodos de ingeniería industrial al análisis, diseño, fabricación y control de calidad de los componentes hardware. Como consecuencia de esto, el hardware se desarrolló rápidamente y la complejidad de los sistemas informáticos aumentó notablemente, necesitando de un software cada vez más complejo para su funcionamiento. Surgieron entonces las primeras casas de software, y el mercado se amplió considerablemente. Con ello aumentó la movilidad laboral, y con la marcha de un trabajador desaparecían las posibilidades de mantener o modificar los programas que éste había desarrollado. Al no utilizarse metodología alguna en el desarrollo del software, los programas contenían numerosos errores e inconsistencias, lo que obligaba a una depuración continua, incluso mucho después de haber sido entregados al cliente. Estas continuas modificaciones no hacían sino aumentar la inconsistencia de los programas, que se alejaban cada vez más de la corrección y se hacían prácticamente ininteligibles. Los costos se disparaban y frecuentemente era más rápido (y por tanto más barato) empezar de nuevo desde cero, desechando todo el trabajo anterior, que intentar adaptar un programa preexistente a un cambio de los requisitos. Sin embargo, los nuevos programas no estaban exentos de errores ni de futuras modificaciones, con lo que la situación volvía a ser la misma. Había comenzado la denominada crisis del software. Hoy en día, la distribución de costos en el desarrollo de sistemas informáticos ha cambiado drásticamente. El software, en lugar del hardware, es el elemento principal del costo. Esto ha hecho que las miradas de los ejecutivos de las empresas se centren en el software y a que se formulen las siguientes preguntas: • ¿ Por qué lleva tanto tiempo terminar los programas?

• ¿ Por qué es tan elevado el costo?



• ¿ Por qué no es posible encontrar todos los errores antes de entregar el software al

cliente?

• ¿ Por qué resulta tan difícil constatar el progreso conforme se desarrolla el software?

Estas y otras muchas preguntas son una manifestación del carácter del software y de la forma en que se desarrolla y han llevado a la aparición y la adopción paulatina de la ingeniería del software. Una definición de software podría ser la siguiente:

Software: instrucciones del procesador que cuando se ejecutan proporcionan la función y el comportamiento deseado, estructuras de datos que facilitan a los programas manipular adecuadamente la información, y documentos que describen la operación y el uso de los programas.

Por tanto, el software incluye no sólo los programas de computadoras, sino también las estructuras de datos que manejan esos programas y toda la documentación que debe acompañar al proceso de desarrollo, mantenimiento y uso de dichos programas. Según esto, el software se diferencia de otros productos que los hombres puedan construir en que es, por su propia naturaleza lógica . En el desarrollo del hardware, el proceso creativo (análisis, diseño, construcción, prueba) se traduce finalmente en una forma material, en algo físico. Por el contrario, el software es inmaterial y por ello tiene unas características completamente distintas al hardware. Entre ellas podemos citar: El software se desarrolla, no se fabrica

Existen similitudes entre el proceso de desarrollo del software y el de otros productos industriales, como el hardware. En ambos casos existen fases de análisis, diseño y desarrollo o construcción, y la buena calidad del producto final se obtiene mediante un buen diseño. Sin embargo, en la fase de producción del software pueden producirse problemas que afecten a la calidad y que no existen, o son fácilmente evitables, en el caso del software Por otro lado, en el caso de producción de hardware a gran escala, el costo del producto acaba dependiendo exclusivamente del costo de los materiales empleados y del propio proceso de producción, reduciéndose la repercusión en el costo de las fases de ingeniería previas. En el software, el desarrollo es una más de las labores de ingeniería, y la producción a gran o pequeña escala no influye en el impacto que tiene la ingeniería en el costo, al ser el producto inmaterial. Por otro lado, la replicación del producto (lo que sería equivalente a la producción del producto hardware) no presenta problemas técnicos, y no se requiere un control de calidad individualizado.



164

El software no se descompone

Podemos comparar las curvas de índices de fallos del hardware y el software en función del tiempo. En el caso del hardware (ver gráfico), se tiene la llamada curva de bañera, que indica que el hardware presenta relativamente muchos fallos al principio de su vida. Estos fallos son debidos fundamentalmente a defectos de diseño o a la baja calidad inicial de la fase de producción. Una vez corregidos estos defectos, la tasa de fallos cae hasta un nivel estacionario y se mantiene así durante un cierto periodo. Posteriormente, la tasa de fallos vuelve a incrementarse debido al deterioro de los componentes, que van siendo afectados por la suciedad, vibraciones y la influencia de muchos otros factores externos. Llegados a este punto, podemos sustituir los componentes defectuosos o todo el sistema por otros nuevos, y la tasa de fallos vuelve a situarse en el nivel estacionario.

índice de fallo

tiempo

Curva de fallos hardware-software

El software no es susceptible a los factores externos que hacen que el hardware se estropee. Por tanto la curva debería seguir la forma de la figura siguiente. Inicialmente la tasa de fallos es alta, debido a la presencia de errores no detectados durante el desarrollo, los denominados errores latentes . Una vez corregidos estos errores, la tasa de fallos deberían alcanzar el nivel estacionario y mantenerse ahí indefinidamente.



índice de fallo

tiempo Curva ideal de fallos del software

Pero esto no es más que una simplificación del modelo real de fallos de un producto de software. Durante su vida, el software sufre cambios, debidos al mantenimiento. El mantenimiento puede deberse a la corrección de errores latentes o a cambios en los requisitos iniciales del producto. Conforme se hacen cambios es bastante probable que se introduzcan nuevos errores, con lo que se producen picos en la curva de fallos. Estos errores pueden corregirse, pero el efecto de los sucesivos cambios hace que el producto se aleje cada vez más de las especificaciones iniciales de acuerdo a las cuales fue desarrollado, conteniendo cada vez más errores latentes. Además, con mucha frecuencia se solicita - y se emprende - un nuevo cambio antes de haber conseguido corregir todos los errores producidos por el cambio anterior. Por estas razones, el nivel estacionario que se consigue después de un cambio es algo superior al que el que había antes de efectuarlo (ver gráfico), degradándose poco a poco el funcionamiento del sistema. Podemos decir entonces que el software no se estropea, pero se deteriora.

índice de fallo

tiempo Curva real de fallos del software

Además, cuando un componente software se deteriora, no podemos sustituirlo por otro, como en el caso del hardware: no existen piezas de repuesto . Cada fallo del software indica un fallo en el diseño o en el proceso mediante el cual se transformó el diseño en



166

código máquina ejecutable. La solución no es sustituir el componente defectuoso por otro (que sería idéntico y contendría los mismos errores) sino un nuevo diseño y desarrollo del producto. Por tanto, el mantenimiento del software tiene una complejidad mucho mayor que el mantenimiento del hardware.

La mayoría del software se construye a medida El diseño de hardware se realiza, en gran medida, a base de componentes digitales existentes, cuyas características se comprueban en un catálogo y que han sido exhaustivamente probados por el fabricante y los usuarios anteriores. Estos componentes cumplen unas especificaciones claras y tienen unas interfaces definidas. El caso del software es bien distinto. No existen catálogos de componentes, y aunque determinados productos como sistemas operativos, editores, entornos de ventanas y bases de datos se venden en grandes ediciones, la mayoría del software se fabrica a medida, siendo la reutilización muy baja. Se puede comprar software ya desarrollado, pero sólo como unidades completas, no como componentes que pueden ser reensamblados para construir nuevos programas. Esto hace que el impacto de los costos de ingeniería sobre el producto final sea muy elevado, al dividirse entre un número de unidades producidas muy pequeño. Se ha escrito mucho sobre reutilización del software, y han sido muchos los intentos para conseguir aumentar el nivel de reutilización, normalmente con poco éxito. Uno de los ejemplos de reutilización más típicos, que ha venido usándose desde hace tiempo, son las bibliotecas . Durante los años sesenta se empezaron a desarrollar bibliotecas de subrutinas científicas, reutilizables en una amplia gama de aplicaciones científicas y de ingeniería. La mayor parte de los lenguajes modernos incluyen bibliotecas de este tipo, así como otras para facilitar la entrada/salida y más recientemente los entornos de ventanas. Sin embargo esta aproximación no puede aplicarse fácilmente a otros problemas también de uso muy frecuente, como puede ser la búsqueda de un elemento en una estructura de datos, debido a la gran variación que existe en cuanto a la organización interna de estas estructuras y en la composición de los datos que contienen. Existen algoritmos para resolver estos problemas, pero no queda más remedio que programarlos una y otra vez, adaptándolos a cada situación particular. Un nuevo intento de conseguir la reutilización se produjo con la utilización de técnicas de programación estructurada y modular. Sin embargo, se dedica por lo general poco esfuerzo al diseño de módulos lo suficientemente generales para ser reutilizables, y en todo caso, no se documentan ni se difunden todo lo que sería necesario para extender su uso, con lo que la tendencia habitual es diseñar y programar módulos muy semejantes una y otra vez. La programación estructurada permite diseñar programas con una estructura más clara, y que, por tanto, sean más fáciles de entender. Esta estructura interna más clara y estudiada, permite la reutilización de módulos dentro de los programas, o incluso dentro



del proyecto que se está desarrollando, pero la reutilización de código en proyectos diferentes es muy baja. La última tendencia para conseguir la reutilización es el uso de técnicas orientadas a objetos, que permiten la programación por especialización. Los objetos, que encapsulan tanto datos como los procedimientos que los manejan - los métodos -, haciendo los detalles de implementación invisibles e irrelevantes a quien los usa, disponen de interfaces claras, los errores cometidos en su desarrollo pueden ser depurados sin que esto afecte a la corrección de otras partes del código y pueden ser heredados y reescritos parcialmente, haciendo posible su reutilización aún en situaciones no contempladas en el diseño inicial.

Aplicaciones del software El software puede aplicarse a numerosas situaciones del mundo real. En primer lugar, a todos aquellos problemas para los que se haya establecido un conjunto específico de acciones que lleven a su resolución (esto es, un algoritmo). En estos casos, utilizaremos lenguajes de programación procedimentales para implementar estos algoritmos. También puede aplicarse a situaciones en las que el problema puede describirse formalmente , por lo general en forma recursiva. En estos casos no necesitamos describir el método de resolución, es decir cómo se resuelve el problema , sino que bastará con describir en problema en sí, indicando cuál es la solución deseada, y utilizaremos lenguajes declarativos para ello. También puede aplicarse a problemas que los humanos resolvemos utilizando multitud de reglas heurísticas posiblemente contradictorias, para lo cual utilizaremos un sistema experto e incluso para problemas de los cuales no tenemos una idea clara de cómo se resuelven, pero de los que conocemos cuál es la solución apropiada para algunos ejemplos de los datos de entrada. En este caso utilizaremos redes neuronales. En cualquier caso, es difícil establecer categorías genéricas significativas para las aplicaciones del software. Conforme aumenta la complejidad del mismo se hace más complicado establecer compartimentos nítidamente separados. No obstante la siguiente clasificación ha venido aceptándose tradicionalmente: Software de sistemas

Está formado por todos aquellos programas cuya finalidad es servir al desarrollo o al funcionamiento de otros programas. Estos programas son muy variados: editores, compiladores, sistemas operativos, entornos gráficos, programas de telecomunicaciones, etc. pero se caracterizan por estar muy próximos al hardware, por ser utilizados concurrentemente por numerosos usuarios y por tratarse de programas de amplia difusión, no estando diseñados normalmente a medida. Esto permite un mayor



168

esfuerzo en su diseño y optimización, pero también les obliga a ser muy fiables, cumpliendo estrictamente las especificaciones para las que fueron creados. Software de tiempo real

Esta formado por todos aquellos programas que miden, analizan y controlan los sucesos del mundo real a medida que ocurren, debiendo reaccionar de forma correcta a los estímulos de entrada en un tiempo máximo prefijado. Deben, por tanto, cumplir unos requisitos temporales muy estrictos y, dado que los procesos que controlan pueden ser potencialmente peligrosos, tienen que ser fiables y tolerantes a fallos. Por otro lado, no suelen ser muy complejos y precisan de poca interacción con el usuario. Software de gestión

El procesamiento de información de gestión constituye, casi desde los inicios de la informática la mayor de las áreas de aplicación de las computadoras. Estos programas utilizan grandes cantidades de información almacenadas en bases de datos con objeto de facilitar las transacciones comerciales o la toma de decisiones. Además de las tareas convencionales de procesamiento de datos, en las que el tiempo de procesamiento no es crítico y los errores pueden ser corregidos a posteriori, incluyen programas interactivos que sirven de soporte a transacciones comerciales. Software científico y de ingeniería

Otro de los campos clásicos de aplicación de la informática. Se encarga de realizar complejos cálculos sobre datos numéricos de todo tipo. En este caso la corrección y exactitud de las operaciones que realizan es uno de los requisitos básicos que deben de cumplir. El campo del software científico y de ingeniería se ha visto ampliado últimamente con el desarrollo de los sistemas de diseño, ingeniería y fabricación asistida por computadora, (CAD, CAE y CAM), los simuladores gráficos y otras aplicaciones interactivas que lo acercan más al software de tiempo real e incluso al software de sistemas. Software de computadores personales

El uso de las computadoras personales y de uso doméstico se ha generalizado a lo largo de la pasada década. Aplicaciones típicas son los procesadores de textos, las hojas de cálculo, bases de datos, aplicaciones gráficas, juegos, etc. Son productos de amplia difusión orientados a usuarios no profesionales, por lo que entre sus requisitos se encuentran la facilidad de uso y el bajo costo. Software empotrado



Software empotrado es aquel que va instalado en otros productos industriales, como por ejemplo la electrónica de consumo, dotando a estos productos de un grado de inteligencia cada vez mayor. Se aplica a todo tipo de productos, desde un vídeo doméstico hasta un misil con cabeza atómica, pasando por algunos sistemas de control de los automóviles, y realiza funciones muy diversas, que pueden ir desde complicados cálculos en tiempo real a sencillas interacciones con el usuario facilitando el manejo del aparato que los incorpora. Comparten características con el software de sistemas, el software de tiempo real, el software de ingeniería y científico y el software de computadoras personales. Software de inteligencia artificial

El software basado en lenguajes procedimentales es útil para realizar de forma rápida y fiable operaciones que para el ser humano son tediosas e incluso inabordables. Sin embargo, es difícilmente aplicable a problemas que requieran la aplicación de funciones intelectuales más elevadas, por triviales que nos puedan parecer. El software de inteligencia artificial trata de dar respuesta a estas deficiencias, basándose en el uso de lenguajes declarativos, sistemas expertos y redes neuronales. Como vemos, el software permite aplicaciones muy diversas, pero en todas ellas podemos encontrar algo en común: el objetivo es que el software desempeñe una determinada función , y además, debe hacerlo cumpliendo una serie de requisitos . Esos pueden ser muy variados: corrección, fiabilidad, respuesta en un tiempo determinado, facilidad de uso, bajo costo, etc., pero siempre existen y no podemos olvidarnos de ellos a la hora de desarrollar el software.

Evolución del Software Primeros años • Orientaciones por lotes • Distribución limitada • Software medida Segunda era • Multiusuario • Tiempo real • B.D. • Software como producto Tercera era • Sistemas distribuidos • Incorporación de inteligencia • Hardware de bajo costo • Impacto en el consumo Cuarta era



170

• Potentes sistemas • Técnicas de programación orientados a objetos • Sistemas expertos • Computación Paralela Ingeniería del Software El desarrollo de sistemas de software complejos no es una actividad trivial, que pueda abordarse sin una preparación previa. El considerar que un proyecto de desarrollo de software podía abordarse como cualquier otro ha llevado a una serie de problemas que limitan nuestra capacidad de aprovechar los recursos que el hardware pone a nuestra disposición. Los problemas tradicionales en el desarrollo de software no van a desaparecer de la noche a la mañana, pero identificarlos y conocer sus causas es el único método que nos puede llevar hacia su solución. No existe una fórmula mágica para solucionar estos problemas, pero combinando métodos aplicables a cada una de las fases del desarrollo de software, construyendo herramientas para automatizar estos métodos, utilizando técnicas para garantizar la calidad de los productos desarrollados y coordinando todas las personas involucradas en el desarrollo de un proyecto, podremos avanzar mucho en la solución de estos problemas. De ello se encarga la disciplina llamada Ingeniería del Software . Una de las primeras definiciones que se dio de la ingeniería del software es la siguiente: El establecimiento y uso de principios de ingenierí a robustos, orientados a obtener software económico, que sea fiable y funcio ne de manera eficiente sobre máquinas reales. La ingeniería del software abarca un conjunto de tres elementos clave: métodos, herramientas y procedimientos, que faciliten al gestor el control el proceso de desarrollo y suministren a los implementadores bases para construir de forma productiva software de alta calidad. Los métodos indican cómo construir técnicamente el software, y abarcan una amplia serie de tareas que incluyen la planificación y estimación de proyectos, el análisis de requisitos, el diseño de estructuras de datos, programas y procedimientos, la codificación, las pruebas y el mantenimiento. Los métodos introducen frecuentemente una notación específica para la tarea en cuestión y una serie de criterios de calidad. Las herramientas proporcionan un soporte automático o semiautomático para utilizar los métodos. Existen herramientas automatizadas para cada una de las fases vistas anteriormente, y sistemas que integran las herramientas de cada fase de forma que



sirven para todo el proceso de desarrollo. Estas herramientas se denominan CASE (Computer Assisted Software Engineering). Los procedimientos definen la secuencia en que se aplican los métodos, los documentos que se requieren, los controles que permiten asegurar la calidad y las directrices que permiten a los gestores evaluar los progresos.

Etapas del ciclo de vida de un sistema computarizad o:

� Identificación de problemas, oportunidades y objetivos

� Determinación de los requerimientos de información

� Análisis de las necesidades del sistema

� Diseño del sistema recomendado

� Desarrollo y documentación del software

� Prueba y mantenimiento del sistema.

� Implementación y evaluación del sistema.

Identificación de problemas, oportunidades y Objeti vos :

La primera fase del ciclo tiene que ver con la identificación de problemas, que generalmente son la causa del análisis que se inicia. Es fundamental la determinación de estos problemas ya que de ello depende que se utilice adecuadamente el tiempo que se invertirá en su solución. Este es el momento de recolectar las opiniones y críticas de los usuarios de un sistema. Aquí es importante la observación y la interacción con los integrantes de la organización objeto del análisis, para luego, tomando una postura crítica, resaltar los problemas detectados.

Llamamos oportunidades a las situaciones que el analista considera que se pueden mejorar, ya sea por la implementación de un sistema de información computarizado o por la modificación de uno ya implementado.

Finalmente la identificación de objetivos de la organización es lo que debe captar el analista en esta primera etapa para utilizarlo para descubrir los problemas y detectar oportunidades. Esto es lo que debe lograr conociendo la organización, compenetrándose en la red de relaciones que forman todas las organizaciones y que se quieren optimizar.

Las actividades a realizar en esta etapa consisten en: entrevistar, estimar el alcance del proyecto, resumir el conocimiento obtenido y documentar los resultados. Las personas involucradas son: los usuarios, administradores, analistas de sistemas y coordinadores del proyecto. Con el resultado de todas estas tareas se realiza un estudio de factibilidad con la definición del problema y los objetivos a lograr. Este informe será el que deberán analizar los administradores del proyecto para determinar si se sigue adelante, se toma



172

otro camino para la solución del problema o no se hace nada por falta de presupuesto, complejidad, etc.

Determinación de los requerimientos de información:

Para la determinación de los requerimientos de información se utilizan las siguientes herramientas: muestreo e investigación de los datos relevantes, entrevistas, cuestionarios, observación del comportamiento de los tomadores de decisiones y su ambiente y elaboración de prototipos.

En esta fase el objetivo es comprender que información necesitan los usuarios para realizar su trabajo y que el analista se forme una imagen de la organización y sus objetivos.

Las personas involucradas en esta fase son los analistas y los usuarios, los administradores de las operaciones. El analista necesita saber los detalles de las funciones actuales del sistema es decir: quién, qué, dónde, cuándo y cómo, o sea, necesita conocer quienes son las personas que están involucradas, la actividad que se desarrolla en la institución (con todas sus particularidades), el ambiente donde se lleva a cabo, en que momento se realiza cada actividad y de que manera se desarrollan los procedimientos en la actualidad; se debe preguntar porque se usa el sistema actual y analizar si se puede mejorar o se justifica mantenerlo.

Resumiendo: al término de esta fase el analista debe comprender él por qué de las funciones de la institución y tener información completa sobre las personas, objetivos, datos y procedimientos involucrados.

Análisis de las necesidades del sistema

Para el análisis de las necesidades del sistema existen herramientas y técnicas especiales que ayudan al analista para la determinación de los requerimientos. Una de las herramientas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones de la institución en forma gráfica estructurada. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos, que lista todos los conceptos de datos usados en el sistema, sus especificaciones y que espacio ocupan cuando se imprimen.

Durante esta fase el analista también analiza las decisiones estructuradas que se hacen. Las decisiones estructuradas son aquellas para las que pueden ser determinadas las condiciones como alternativas de condición, acciones y reglas de acción. Hay tres métodos principales para el análisis de decisiones estructurales: lenguaje estructurado, tablas de decisión y árboles de decisión.

En este punto el analista prepara una propuesta de sistema que incluye lo que ha encontrado, proporciona un análisis costo/beneficio de las alternativas y hace



recomendaciones sobre lo que se debe hacer. Si alguna de las recomendaciones es aceptada se sigue en ese camino.

Cada problema de sistema es único y nunca hay una sola solución correcta. La forma en que se formula una solución depende de la capacidad y experiencia profesional de cada analista.

Diseño del sistema recomendado:

Con la información recolectada anteriormente el analista realiza el diseño lógico del sistema de información. Se diseñan procedimientos precisos para la captura de catos, de forma que los datos que ingresan en el sistema sean correctos utilizando técnicas para el diseño de pantallas e interfaces.

Una parte importante del diseño lógico del sistema de información es el diseño de la interfaz de usuario. Esta interfaz es la comunica al usuario con el sistema (la parte visible) y por esto es extremadamente importante, concretamente está formada por el teclado para ingresar datos, los menúes en la pantalla, el mouse para seleccionar opciones y otras menos comunes como identificadores biométricos, cámaras de vídeo, etc.

La fase de diseño también incluye el diseño de archivos o bases de datos que guardarán la mayor parte de los datos necesarios para los tomadores de decisiones de la institución. Una base de datos bien organizada es la base de todos los sistemas de información. Se deben diseñar procedimientos de control y respaldo para proteger el sistema y los datos.

Desarrollo y documentación del software:

En esta fase el analista trabaja con los programadores para desarrollar el software original que se necesite. Por medio de distintas técnicas (diagramas estructurados, seudocódigo, etc.) el analista comunica al programador lo que se necesita programar. Conjuntamente se trabaja con los usuarios para desarrollar documentación para el software y manuales de procedimientos. Por medio de esta documentación el usuario recibe instrucciones de cómo usar el software y que hacer si surgen problemas.

En esta fase los programadores diseñan, codifican y eliminan errores de sintaxis de los programas.

Pruebas y mantenimiento del sistema:

Antes de poner en marcha un sistema debe ser probado, primero por el programador y luego por este en conjunto con el analista para encontrar la mayor cantidad de problemas antes de ser entregado a los usuarios. Se deben realizar una serie de pruebas con datos ficticios o eventualmente con datos reales del sistema actual.



174

Rutinariamente se debe realizar el mantenimiento y documentación del sistema, fundamental para el buen funcionamiento del mismo. Los procedimientos sistemáticos empleados por el analista en el desarrollo del sistema pueden servir para que el mantenimiento se mantenga al mínimo.

El mantenimiento continúa luego de la implementación del sistema, ya sea solucionando los problemas que pudieran surgir con el uso o para mejorar el software respondiendo a la dinámica de las necesidades de la institución (solicitudes de los usuarios para mayor facilidad de utilización, nuevos requerimientos surgidos posteriormente a la implementación, actualización acorde al avance en el hardware y software).

Implementación y evaluación del sistema

En esta fase del desarrollo del sistema el analista ayuda a implementar el sistema de información. Es decir que participa en el entrenamiento de los usuarios que utilizarán el sistema. Además se debe realizar un plan para la conversión del sistema antiguo (manual o computarizado) al nuevo, conversión de archivos, construcción y/o modificación de bases de datos.

La evaluación debe estar presente en cada fase del proceso, de modo que al detectarse algún error se solucione en esa fase sin trasladarse a la siguiente, es decir que es parte de un proceso cíclico, que puede necesitar volver a una fase anterior para realizar una modificación o rediseño de una parte del sistema, consultar con los usuarios, etc. La evaluación final se realizará principalmente para efectos de discusión.



Texto 8

Determinación de la factibilidad y la administració n de las actividades de análisis y diseño

Análisis de sistemas El objetivo de análisis de sistemas es el estudio de los aspectos y características del desarrollo de un proyecto uniforme y para ello nos fijaremos en las características y aspectos propios del proyecto, es decir, en sus funciones y en el entorno en que dicho proyecto se desarrolla. El análisis del sistema que vamos a implementar es necesario para cualquier tipo de proyectos. Pero sobre todo va encaminada a las aplicaciones de gestión. Abarca tanto las fases de análisis como las de explotación y mantenimiento posteriores y en el vamos a distinguir las siguientes etapas: Estudio y análisis de la oportunidad Es el análisis previo que hay que realizar y se trata de estudiar la viabilidad del proyecto, tanto del punto de vista técnico como económico. Para ello hay que llevar a cabo un estudio de los existente y partir de aquí se plantean varias soluciones de las que elegiremos la que ofrezca mayores garantías. Análisis funcional Se trata de un análisis exhaustivo de la solución propuesta en el estudio de la oportunidad, pero visto ya desde un punto de vista mucho más informático. Tal que al acabar esta etapa el proyecto tiene que quedar claramente dividido en las aplicaciones o partes fundamentales. En esta fase puede ser preciso dar algunos pasos atrás. Por ejemplo para realizar una tarea era preciso una persona y al mirar exhaustivamente nos damos cuenta de que hacen falta 2. Esto se recoge en el dossier de análisis funcional. Análisis orgánico Con este ultimo se trata de detallar todos los puntos del análisis funcional de modo que quede todo listo para la programación. El análisis orgánico lo que tiene que hacer es analizar cada parte tal que para cada aplicación se creara un dossier de análisis orgánico o cuaderno de carga. En estos se describe detalladamente la división en subprogramas de cada aplicación, el formato y características de las entradas y salidas. Finalmente se elige también el lenguaje de programación que se va a utilizar.



176

Programación Consiste en la codificación de todos los programas que constituyen las distintas aplicaciones del proyecto informático. Puesta a punto En esta fase lo que se hace es combinar todos los programas para que el conjunto también funcione. Todo esto se va probando con juegos de ensayo y simuladores. Como es muy probable que al principio se den errores se llevan durante unos meses de forma paralela el antiguo método y el informático. Mantenimiento Recoge las modificaciones que sean necesarias introducir en el desarrollo del proyecto y que pueden aparecer en el mismo momento de la explotación ó más tarde como consecuencia de nuevas necesidades del usuario. Fundamentos de los proyectos El analista debe dominar habilidades especiales tales como: inicio de proyectos, determinación de factibilidad de proyectos, programación de proyectos y la administración efectiva, tanto de tareas como de miembros de equipos de trabajo. Un proyecto tiene problemas y oportunidades para mejorarlos, y surgen cuando la organización quiere adaptarse al cambio. Los cambios que requieren de una solución de sistemas se presentan tanto en círculos legales como industriales. Tan pronto surge el interés por un proyecto, el analista se reunirá con quienes toman las decisiones y colabora para determinar su factibilidad. Si las actividades se aprueban, se planificaran las mismas mediante el uso de diagramas de Gantt o PERT, de manera tal que el proyecto finalice oportunamente. Una de las acciones más importantes para garantizar la productividad en el desarrollo del proyecto, es la administración efectiva de las actividades programadas para los miembros del equipo. Inicio de los proyectos Los proyectos de sistemas surgen de numerosas fuentes diferentes. Algunos de los proyectos sugeridos sólo sobrevivirán algunas de las etapas de su evaluación; pero otros deberán trascender. La gente de negocios sugiere principalmente los proyectos de sistemas por dos razones: la experimentación de problemas que los conduzcan a soluciones con sistemas y la identificación de oportunidades para mejorar (mediante la actualización,



modificación o instalación de nuevos sistemas) que eventualmente llegarán a presentarse. Ambas situaciones surgen conforma la organización se va adaptando o enfrentando a los cambios evolutivos naturales. Los problemas dentro de la organización Nadie acepta que haya problemas pero los buenos administradores aceptan que es necesario reconocer lo problemas para poder enfrentarlos. Los problemas surgen de maneras muy diferentes. Una forma de concebir lo que es un problema y de cómo aparecen, es imaginar las situaciones en que nunca se logran las metas o los casos en que éstas ya no se cumplen. La retroalimentación es útil y nos proporciona información referente al desempeño actual y al deseado. La retroalimentación, permite detectar los problemas. Los problemas que pueden solicitar la presencia de un analista de sistemas, incluyen: persistencia y cantidad de errores - desarrollo lento o incorrecto del trabajo – la no realización del trabajo. Cuando se presentan síntomas de problemas, todo ello será indicio para que los directivos noten la existencia de problemas potenciales. Como es de suponerse, el papel del analista de sistemas, variará sutilmente si el proyecto que surge se debe a una oportunidad de mejoría, o bien, a la necesidad de resolver un problema. Oportunidades de mejoría El analista sirve de catalizador y de experto de apoyo. Identifica donde el proceso puede mejorarse, los problemas son oportunidades de mejoría de las capacidades. Lo que pareciera un inquietante problema para un gerente, puede convertirse en toda una oportunidad para un analista de sistemas alerta. La mejoría en sistemas puede definirse como aquellos cambios que otorgan beneficios considerables. Existen muchas posibilidades de mejoras, éstas incluyen:

• La aceleración del proceso

• La simplificación de procesos mediante la eliminación de pasos

• La combinación de procesos

• La reducción de errores de captura de datos

• La eliminación de salidas redundantes



178

• Una mejoría en la integración de los sistemas

• Mayor aceptabilidad del sistema por el usuario

• Una mejor relación cliente proveedor

La identificación de las oportunidades de mejoría es propia de las capacidades de los analistas de sistemas. Sin embargo, la gente que está en contacto continuo con el sistema, constituye la mejor fuente de información de las mejoras que deben realizarse. Si las mejoras ya fueron expuestas, la experiencia del analista será muy útil para evaluar las ventajas de tales cambios, como así también la forma de implementarlas. Selección de proyectos Los proyectos tienen origen y motivos diversos. No todos ellos deben elegirse para estudios adicionales. Las razones que justifican un proyecto deben estar claras. Es necesario considerar los motivos que hay detrás de la propuesta. Estos deben analizarse con perspectiva de sistemas. Es decir, que debe verificarse que el proyecto en consideración no se propuso sólo para beneficio de la reputación política o poder, o de la persona o grupo que lo patrocinan, pues en estos casos habrá una alta probabilidad que la concepción del proyecto sea pobre, y mas adelante quizás no llegue a ser bien aceptado. Es importante destacar que los sistemas y sub-sistemas están interrelacionados y el cambio de uno puede implicar cambios en el resto. Aunque quienes toman las decisiones sean los que realmente establezcan los límites de los proyectos de sistemas, éstos no pueden contemplarse o seleccionarse de manera aislada de la organización. Existen criterios para la selección de proyectos,. El principal es contar con el respaldo de la directiva. En realidad, nada puede lograrse sin el respaldo de la gente que eventualmente recibirá la cuenta. Esto no significa que no pueda influir sobre la dirección del proyecto o que otras personas distintas a los directivos no puedan considerarse, pero, es esencial el apoyo de la dirección. Es fundamental, también, tal como en todo proyecto que vayamos a iniciar, contar con disponibilidad de tiempo, tanto del analista como del de la organización. Es fundamental preguntarse y preguntar a todos los involucrados, si la empresa está dispuesta en este momento a ofrecer el tiempo que se requiere para la instalación de un nuevo sistema, o para el mejoramiento de alguno de los existentes. El analista debe estar en disponibilidad para asignar su tiempo durante el desarrollo de cualquier proyecto. Respecto a los criterios a tener en cuenta, los objetivos del proyecto deben tener en cuenta a los objetivos de la organización y no desviarla de sus fines primarios.



Es importante que el proyecto a seleccionar, sea viable en función de los recursos y sus capacidades o de las de otros miembros de la empresa. Habrá ciertos proyectos que no se encuentren dentro de su área de experiencia, y deberá tener capacidad para reconocerlos. Finalmente, se debe llegar a un acuerdo básico con la organización respecto a las ventajas de un proyecto de sistemas sobre cualquier otra alternativa de inversión. Debemos recordar que cuando una organización autoriza el desarrollo de un proyecto, está comprometiendo los recursos que excluirán el gasto en otros proyectos.

• Es fundamental el acuerdo básico con la organización respecto a las ventajas de un proyecto de sistemas sobre cualquier alternativa de inversión.

Determinación de Factibilidad Una vez que el numero de proyectos se ha reducido por la aplicación de los criterios establecidos con anterioridad, es necesario evaluar si estos son factibles. La definición de factibilidad en nuestro contexto tiene una mayor profundidad que el uso común de esta palabra. Para los proyectos de sistemas, la factibilidad se apoya en tres principios básicos: operativo, técnico y económico. Un proyecto debe satisfacer los tres principios para merecer el desarrollo posterior. El estudio de factibilidad no es un estudio de sistemas con alto grado de detalle, sino que sirve para la recopilación de datos relevantes para la alta dirección y a partir de ello se tomara la decisión si se procede un estudio de sistemas. Es importante destacar que el analista no debe utilizar mucho tiempo para los estudios de factibilidad, ya que pueden ser solicitados de una gran variedad de proyectos, y solo algunos se ejecutarán.

Crit erios específicos para la selección de proyectos 1. Disponibilidad de tiempo para el desarrollo y asignación de recursos 2. Respaldo de los directivos 3. Programación del tiempo que se requiere para el proyecto 4. Posibilidad de mejorar la búsqueda de las metas de la organización 5. Contar en la practica con los recursos del analista y la organización 6. El proyecto vale la pena al compararlo con otras opciones de inversión

de la empresa



180

El estudio de factibilidad debe ser lo mas conciso posible, realizándose al mismo tiempo varias actividades durante un corto periodo.

Definición de objetivos Es importante definir cuales son los objetivos de la organización que se abordan, y luego determinar si tal proyecto es útil para llevar de alguna manera el negocio hacia tales objetivos. Los objetivos del proyecto deben hacerse explícitos mediante entrevistas al grupo que lo propone. Existen objetivos razonables que deben contemplarse en un proyecto de sistemas:

o Reducción de errores y mayor precisión en la captura de datos o Reducción del costo de salidas del sistema o Integración con los subsistemas del negocio o Actualización del servicio al cliente o Aceleración de la captura de datos o Reducción del tiempo de procesamiento de datos o Automatización de procesos manuales a fin de su mejora

Determinación de Recursos

Factibilidad : significa que el proyecto • Auxilia a la organización a lograr sus objetivos • Sea posible para cubrir las metas con los actuales recursos de la

organización. o Factibilidad Técnica

� Mejora el sistema Actual � Disponibilidad de tecnología que satisfaga las necesidades

o Factibilidad Económica � Tiempo del analista � Costo del estudio del sistema � Costo del tiempo de los empleados dedicado al estudio � Costo estimado del equipo � Costo del desarrollo / adquisición del software

o Factibilidad operativa � Que el sistema operará cuando se instala � Si el sistema será utilizado

Determinación de la factibilidad de un proyecto de sistemas evaluando el alcance de los objetivos de la organización



La determinación de los recursos para el estudio de factibilidad sigue el mismo patrón establecido previamente, el cual deberá revisarse y evaluarse si se llega a realizar un estudio formal de sistemas. Los recursos serán analizados en relación con el tipo de factibilidad: Técnica, económica y operativa. Factibilidad técnica El analista debe indagar los recursos técnicos usuales pueden actualizarse o complementarse, de manera tal que satisfagan la necesidad considerada. Sin embargo a veces, los “complementos” de los sistemas llegan a ser costosos y no valen la pena, simplemente porque no cumplen de manera eficiente las necesidades. Si los sistemas existentes no pueden actualizarse, el siguiente paso a considerar será determinar si existe alguna tecnología que pueda satisfacer los requisitos. Es fundamental la experiencia del analista, la cual es considerada de gran valor, ya que haciendo uso de sus conocimientos y contactos, podrá solucionar el tema de la factibilidad técnica. Si la respuesta a si una tecnología está disponible, es afirmativa, el problema se convierte en otro de tipo económico. Factibilidad económica El estudio de factibilidad económica es la segunda etapa que se lleva a cabo. Los recursos básicos que deben considerarse son: el tiempo del analista y de su equipo, el costo de realización integral de un estudio de sistemas, el costo del tiempo del empleado para la empresa, el costo estimado del equipo y el costo estimado del software comercial o de su desarrollo. Se debe establecer el valor de la inversión antes de comprometerse con el estudio de sistemas completo. Si el proyecto a corto plazo no compensa la inversión el proyecto será inviable, y no debe trascender esta etapa. Factibilidad Operativa Para esta etapa debemos considerar que los recursos técnicos y económicos están disponibles, ya que de lo contrario a esta etapa no habríamos arribado. En analista deberá considerar la factibilidad operativa del proyecto que le ha sido solicitado. Ésta depende de los recursos humanos que participen en la operación del proyecto. Esto se refiere a que si una vez instalado el sistema llegara a funcionar o usarse. Si los usuarios están “casados” con el sistema actual, y no le ven ningún inconveniente, ni acuden al analista para perfeccionarlo o remplazarlo por uno nuevo, es muy probable



182

que la resistencia al cambio sea muy grande por lo que el sistema caerá en desuso, antes de la implementación definitiva. Si en cambio de los usuarios surge la necesidad de una actualización o modificación del sistema actual, definitivamente lo usaran, y el proceso de adaptación será mucho menor. Este proceso requiere la imaginación creativa del analista de sistemas así como habilidad de persuasión. Gran parte del esfuerzo que se requiera para establecer la factibilidad operativa radica, en el analista de sistemas, quien debe saber escuchar lo que el usuario desea y lo que parece que llegará a utilizar. Evaluación de la factibilidad Debemos tener en cuenta que la evaluación de la factibilidad no es una decisión fácil ni claramente definida. Este tipo de evaluación no la hace en realidad el analista, sino que queda en manos de la dirección. Las decisiones se basan en la información de la factibilidad que haya recopilado, y presentado en forma hábil y profesional el analista de sistemas. Es necesario asegurarse las tres etapas de factibilidad fueron cubiertas en el estudio preliminar. El estudio de los proyectos de sistemas deben realizarse con rapidez, de manera que los recursos asignados a él y la información que emita el estudio sea convincente y que mantenga en alto el interés, tanto del grupo que ha pedido el proyecto como de la dirección de la organización. El proceso para determinar la factibilidad es bastante efectivo para descartar aquellos proyectos que no sean consistentes con los objetivos de la empresa, o técnicamente imposibles o no redituables desde el punto de vista económico. Mientras más esmerado sea el estudio de factibilidad brindara mayor beneficio a largo plazo. El analista actuará como experto de apoyo, recomendando la dirección de los proyectos de sistemas que satisfagan todos los requisitos.

Planeación y Control de Actividades El análisis y diseño involucra tareas de naturaleza diferente que al integrarse constituyen un proyecto. El analista de sistemas debe administrar con cuidado el proyecto, si quiere que este sea de éxito. Esto implica una buena planeación de las tareas. La planeación incluye todas las actividades que se requieran para la selección del equipo de sistemas, la asignación de proyectos apropiados a los miembros de este equipo, la estimación de tiempos que cada tarea requiera para su ejecución y la programación del proyecto, de manera tal que todas las tareas finalicen oportunamente.



El control denota el uso de la retroalimentación para darle seguimiento al proyecto. El control significa tomar las decisiones adecuadas para acelerar o reprogramar las actividades y en consecuencia que finalicen a tiempo, como así también la motivación de los miembros del equipo par que cumplan sus tareas en forma adecuada. Estimación del tiempo requerido La primera decisión del analista es la determinación el grado de detalle que usará para definir las actividades. El primer nivel de detalle es desde el ciclo de desarrollo de sistemas, mientras que el otro extremo seria incluir cada uno de los pasos con el máximo grado de detalle. Cada una de las etapas del ciclo de vida de sistemas puede ser desglosado en mas etapas a efectos de especificar los tiempos en forma más exacta. En este punto es importante tener en cuenta un enfoque estructurado, donde podremos ir desglosando en actividades menores, lo que obviamente no significa que sean de menor importancia, simplemente es para poder establecer tiempos con mas detalle. Podemos comenzar realizando el desglose de un proyecto en tres grandes grupos: el análisis, el diseño y la implementación. Luego, la etapa de análisis se desglosará en: la recopilación de la información, el análisis del flujo de datos y la preparación de la propuesta. La etapa de diseño podemos desglosarla en: el diseño de la captura de datos, el diseño de las entradas / salidas y en la organización de los datos. La fase de implementación se divide en: implantación y evaluación. Análisis

• Recopilación de datos • Análisis de decisión y análisis del

flujo de datos • Preparación de la propuesta

Diseño

• Diseño general de la entrada de información

• Diseño específico de las entradas • Diseño de las salidas • Organización de los datos

Implantación

• Implantación • Evaluación

Inicio de la planeación de un proyecto, mediante su descomposición en tres grupos de actividades



184

El analista de sistemas tomará cada uno de los bloques anteriores en etapas subsiguientes, y los desglosará aún más, de manera tal que pueda realizarse la planeación y programación de las mismas con mayor detalle. La actividad de la recopilación de información podemos a su vez desglosarla en mas pasos, por ejemplo en: realización de entrevistas, lectura de los informes de la compañía, introducción del prototipo, etc. como así también los tiempos requeridos para cada uno de las tareas. Este último punto, el de estimación de tiempos de cada una de las tareas, es de suma importancia, pero se basa fundamentalmente en la experiencia del analista de sistemas para que esta estimación sea lo más fiel posible a la realidad. Existen tendencias de realizar tres tipos de estimaciones, en primera instancia: pesimista, optimista y más probable, y luego mediante una fórmula de promedios ponderados determinar la duración esperada para una actividad. Si bien este procedimiento no dará la respuesta correcto o ideal, pero al menos ofrece cierta seguridad y se evitará, sorpresas poco gratas.

Administración de las actividades de análisis y de diseño Además de la administración del tiempos y los recursos, los analistas tienen que administrar elementos humanos. Esto se logra estableciendo una correcta comunicación entre los integrantes de los grupos. Deben establecerse metas para la productividad del proyecto y los miembros de los grupos deben estar motivados para su logro. Comunicación para el manejo de grupos Cada grupo tiene su propia personalidad, que resulta de la combinación de los integrantes individuales del grupo, de manera tal que se genera una red de relaciones nueva. Es importante lograr un equilibrio entre el cumplimiento de tareas y el manejo de las relaciones de los integrantes del grupo. Para ello generalmente hay dos lideres: uno que maneja el desempeño de tareas y otro que se encarga de las relaciones sociales. Ambos líderes son fundamentales para el grupo. Cada grupo esta sujeto a una serie de presiones, basadas en la búsqueda del equilibrio entre el cumplimiento de las tareas y el mantenimiento de las relaciones entre los integrantes del grupo. Las presiones deben ser atendidas de manera continua. Minimizarlas o ignorarlas, pueden llegar a la desintegración del grupo. Es importante la existencia de un conjunto de normas explícitas e implícitas para ayudar al grupo en sus relaciones. Las normas cambian con el tiempo y es necesario considerarlos como un proceso de relación. La



retroalimentación por parte de todos los integrantes del grupo puede ayudar a la liberación de las presiones. Las normas pueden ser funcionales o disfuncionales. El grupo debe en forma periódica evaluarlas para verificar si siguen necesarias para el cumplimiento de sus metas.

• Dado que los grupos están formados por personas, las cuales tienen personalidades diferentes, y éstas deben interactuar para cumplir con las metas del proyecto, es fundamental una abierta comunicación entre ellos, como así también la existencia de lideres que interpreten las necesidades del grupo en su totalidad, como los de cada uno de los componentes.

Existen otras áreas que deben considerar los integrantes de los grupos de análisis de sistemas. Ellas son:

1. La importancia de identificarse con lo que el grupo produce. 2. La responsabilidad de uno de los integrantes para supervisar el propio

desempeño del equipo. 3. Mantenimiento de una relación abierta con otras personas externas al grupo. 4. La aceptación del protagonismo de múltiples papeles para las tareas del grupo.

Identificación con lo que el grupo produce Esta identificación, mas que hacer un esfuerzo individual, los integrantes del grupo deberán atribuir a su grupo tanto sus éxitos como sus fracasos. A veces las personas no llegan a aceptar la responsabilidad en el seno del equipo. Se cree que por trabajar en grupo pueden ocultar o disimular su influencia en las decisiones y no necesitan responsabilizarse de sus acciones. El grupo necesita desarrollar una personalidad para admitir errores como para aceptar felicitaciones por las tareas realizadas Responsabilización de la supervisión del desempeño del grupo Al responsabilizar a uno de los integrantes, la supervisión periódica del desempeño del equipo se cubre una parte importante del camino para llegar a tener un exitoso grupo de análisis de sistemas. No tiene que ser muy elaborado, sino que es una manera de asegurarse que el equipo se conduce hacia sus objetivos. Otro punto importante a tener en cuenta es que el grupo necesita el doble de tiempo para obtener información interna de una tarea. Se deberá reservar tiempo para las observaciones del equipo para realizar una buena retroalimentacion al mismo y a sus miembros. Todos los integrantes deben saber realizar el proceso de observación, ya que es un método útil para la recopilación de información.



186

Integración del grupo en la organización Si el grupo forma parte de una organización, sus miembros necesitan integrar su grupo con el resto de la organización. Los grupos deben tener el compromiso primordial con la empresa. Los integrantes deben esforzarse para mantener una relación regular con la gente de los otros departamentos de la empresa. Es importante que el grupo verifique continuamente que sus propias metas siguen en concordancia con las del sistema mayor. Motivación de los integrantes de grupos de proyecto s Aunque la motivación es un tema muy complejo, vale la pena considerarlo. Es importante tener en cuenta que la gente se motiva en varios niveles, no solamente para satisfacer las necesidades primarias de alimentación y vestido. Uno de los puntos importantes es la fijación de metas. Las metas actúan como un imán para su concreción. Cada miembro debe tener responsabilidades bien definidas, pero también debe sentirse cómodo al tener múltiples responsabilidades. Los papeles deben asumirse en función de la experiencia, capacitación y personalidad individuales, pero con el fin de lograr la máxima ventaja del trabajo colectivo. Los integrantes deben ser lo suficientemente flexibles en los papeles que desean asumir. Evitando el fracaso del proyecto Las discusiones sobre los estudios de factibilidad y administración de los proyectos, son las mejores defensas para los proyectos con altas probabilidades de fracasos. Si se forma parte de un grupo interno, uno debe mantenerse al tanto del clima político de la organización, como así también estar al tanto de los aspectos financieros y de competitividad. Es importante recordar que uno no está solo en la decisión de comenzar un proyecto. Si bien el analista realiza el estudio de factibilidad, la decisión final sobre el inicio del proyecto está en manos de los directivos, quienes en definitiva decidirán si el proyecto propuesto tiene relevancia suficiente para continuar con un estudio adicional. El proceso para la toma de decisiones dentro del grupo debe ser abierto y aceptar las sugerencias de las personas que se encuentran fuera de él. El grupo debe considerar que su reputación como su posición dentro de la organización, se encuentra muy ligado a los proyectos que el grupo acepta.



Texto 9

La entrevista Antes de entrevistar a alguien, debe entrevistarse a sí mismo. Esto es importante, ya que necesita conocer sus características, y la manera en que afectarían sus percepciones ante el entrevistado. Su formación, educación y emociones, serán poderosos filtros de lo que escuche a lo largo de sus entrevistas. Antes de realizar la entrevista es importante la planeación de la misma, analizar el motivo de la misma, que preguntas se harán, y por el otro lado a quien se va a entrevistar. Debe prever la forma que también la entrevista sea satisfactoria para el entrevistado. Tipo de información buscada Una entrevista para la recopilación de información es una conversación dirigida con un propósito específico, que se basa en un formato de preguntas y respuestas. Es importante conocer tanto las opiniones como los sentimientos del entrevistado. Las opiniones pueden ser más importantes que los mismos hechos. Además de las opiniones, se tratará de conocer los sentimientos del entrevistado. Debemos tener en cuenta que el entrevistado conoce la organización mucho mejor que uno. Las metas son una fuente importante de información y pueden identificarse a partir de una entrevista. Los hechos que obtiene de los datos concretos pueden explicar un desempeño anterior, pero las metas se proyectan hacia el futuro. Durante la entrevista es importante lograr la identificación del mayor número de metas posibles. En una entrevista, se establece una relación con alguien que probablemente será un desconocido, por lo tanto se necesitará crear un ambiente de confianza, pero sin perder el control de la entrevista. Para lograr esto es importante tener una buena planeación de la entrevista, para que la misma sea realizada sin tropiezos. Planeamiento de la entrevista Son cinco los pasos para la preparación de una entrevista. Estos pasos incluyen una amplia gama de actividades, desde la recopilación de antecedentes, hasta la decisión a quien entrevistar. Si bien estos pasos no son estrictos son una buena pauta para la realización de la misma.

Lectura de antecedentes



188

Consultar y comprender el mayor número de antecedentes de los entrevistados y de la organización. Esto se obtiene fácilmente por intermedio del contacto, solicitando un informe o comunicación que le dé las características de la organización. A partir de esto uno puede ir elaborando las preguntas de la entrevista con un vocabulario conocido por ellos. Es importante la organización de la entrevista para aprovechar al máximo el tiempo de la misma. Establecimiento de los objetivos de la entrevista La entrevista debe basarse en los antecedentes consultados y en la experiencia particular del analista. Debe haber aspectos referentes al procesamiento de la información como a la toma de decisiones sobre los cuales debe realizarse la entrevista. Selección del entrevistado Cuando se decida a quien se entrevistará debe incluirse gente clave de todos los niveles del sistema. Es importante hacer un muestreo de los miembros de la organización. Haga lo posible por mantener un equilibrio de tal manera que se cubran tantas necesidades de los usuarios como sea posible. El contacto con la organización dará una idea clara sobre quienes deberían ser entrevistados. Preparación del entrevistado Preparar a la persona que va a ser entrevistada, avisando con suficiente antelación, para que pueda pensar en la entrevista. Las entrevistas deben fluctuar entre 45 minutos y una hora. No importa que interés tenga el entrevistado para prolongar la entrevista. Es importante recordar cuando ellos disponen de tiempo para atender al entrevistador, están dejando de atender sus actividades. Si la entrevista dura mas de una hora, es muy probable que el entrevistado lamente la visita del entrevistador, aunque eso no lo diga. Selección del tipo y estructura de las preguntas Es importante redactar las preguntas que cubran los aspectos fundamentales de la toma de decisiones. Las preguntas tienen ciertas estructuras básicas que debe conocer. Existen preguntas de tipo abierto y de tipo cerrado . Cada tipo de pregunta puede lograr algo diferente de las otras, y cada una tiene sus ventajas y desventajas.

• La Entrevista es una de las herramientas más poderosas para recabar información, sobre lo que el usuario quiere o necesita, siendo ésta fundamental dentro de la etapa de análisis



• Es importante destacar que un buen desarrollo de la etapa de análisis prácticamente asegura un buen desarrollo de las etapas subsiguientes

Tipos de Preguntas Preguntas Abiertas Incluyen aquellas tales como ¿Qué opina acerca de las computadoras para gerentes?. Abierta son las opciones que el entrevistado tiene para responder. Puede ser una respuesta de dos palabras, o de dos párrafos. Las ventajas de utilizar preguntas abiertas son muchas, e incluyen los siguientes aspectos:

1. Simplifican las cosas para el entrevistado

2. Permiten al entrevistador seleccionar el vocabulario del entrevistado

3. Proporciona una gran riqueza de detalle

Lectura de

antecedentes

Establecimiento de los objetivos de la

entrevista

Selección del tipo y la estructura de las

preguntas

Preparación del

entrevistado

Selección de los

entrevistados

Pasos que sigue el analista de sistemas en la planeación de una entrevista



190

4. Revelan nuevas alternativas sobre preguntas no consideradas

5. Hacen más interesante la entrevista

6. Permiten mayor grado de espontaneidad

7. Se usan como una alternativa cuando el entrevistado no se encuentra

preparado.

Las preguntas abiertas tienen varias ventajas, sin embargo la otra cara es que cuentan también con muchos inconvenientes, entre los cuales se encuentran:

1. Permiten preguntas que pueden generar demasiada información irrelevante

2. La posible pérdida del control de la entrevista

3. Permiten respuestas que pueden llevar demasiado tiempo para la cantidad de

información que aportan

4. Puede dar la pauta que el entrevistador no se preparo

5. La apariencia que el entrevistador se encuentra en una expedición sin

objetivos reales de la entrevista.

Se debe considerar con el cuidado que corresponda la utilización de preguntas durante una entrevista.

• Las preguntas abiertas permiten opciones abiertas al entrevistado

• Permiten que el entrevistado desarrolle con comodidad, sus conocimientos y sentimientos sobre la organización, lo cual es de mucha utilidad ya que él conoce la empresa mucho mejor que el entrevistador

1. ¿Cuál es su opinión sobre el sistema de cómputos actual?

2. ¿Cómo ve los objetivos de este departamento?

3. ¿Cómo se relaciona esta forma de trabajo con el que usted realiza?

4. ¿Cuáles son los errores más comunes durante la captura de datos en este departamento?

Ejemplos de preguntas abiertas de una entrevista



Preguntas Cerradas Las preguntas cerradas son la alternativa de las preguntas abiertas. Éstas responden a estructuras más rígidas, como por ejemplo ¿Cuantos subordinados tiene?. Las respuestas se encuentran limitadas para el entrevistado, ya que solo puede contestar con un número finito. Un tipo especial de preguntas cerradas son las preguntas bipolares. Son aquellas que permiten solo dos respuestas alternativas, si o no, verdadero o falso. Dentro de los beneficios de las preguntas cerradas podemos citar:

1. Ahorran tiempo

2. Facilitan la comparación entre entrevistas

3. Llegan al punto de interés

4. Mantienen el control de la entrevista

5. Cubren rápidamente diversos aspectos

6. Obtienen datos de relevancia

Sin embargo las desventajas de las preguntas cerradas son importantes, las cuales podemos citar:

1. Aburren al entrevistado

2. Pierden la riqueza del detalle (le plantean al entrevistado un marco de

referencia)

3. Se pueden perder ideas centrales

4. No favorecen un clima de armonía entre el entrevistado y el entrevistador.

El entrevistador debe evaluar el tipo de preguntas a realizar y establecer la utilización de preguntas abiertas o cerradas, o una combinación de estas.

• Tanto las preguntas abiertas como cerradas tienen sus ventajas y desventajas. Debe tenerse en cuenta la elección de cada una de ellas. Teniendo en cuenta que las preguntas cerradas son fáciles de analizar pero no permiten amplitud de respuesta, las preguntas abiertas ofrecen amplitud y profundidad en la respuesta, estas son difíciles de analizar.



192

Sondeos Responde al tercer tipo de pregunta llamada de sondeo o exploratoria. El sondeo más sólido y más simple es la pregunta ¿Por que?. El propósito del sondeo es ir mas allá de la respuesta inicial para obtener un mayor significado y aclarar o ampliar los puntos del entrevistado. Esto puede realizarse mediante preguntas abiertas o cerradas. El sondeo es esencial. La mayoría de los entrevistadores principiantes son reticentes acerca del sondeo y se conforman con respuestas superficiales, los cuales no son de gran relevancia par obtener información fidedigna.

Errores en las preguntas Al formular de antemano las preguntas tendrán la posibilidad de corregir cualquier pregunta deficiente que haya escrito. Existen dos tipos de errores en las preguntas: las tendenciosas y las preguntas dobles. Evite las preguntas tendenciosas Las preguntas tendenciosas son las preguntas que tienden a dirigir al entrevistado hacia la respuesta que usted quiere escuchar. La respuesta desde este punto de vista será parcial, ya que tiende una trampa. Por ejemplo: Estará de acuerdo, como el resto de los gerentes, que el control de inventarios este computarizado ¿no es cierto?. Contestar lo contrario sería muy incomodo para el entrevistado. Evite preguntas dobles Las preguntas dobles son las que en una sola contienen de hecho dos preguntas diferentes. Una pregunta de estas características sería ¿Qué decisiones se toman en un día normal y cómo las toma usted?

1. ¿Cuántos informes genera en un mes? 2. ¿Durante cuanto tiempo ha trabajado en éste área? 3. ¿Quién recibe éste reporte?

Ejemplo de preguntas cerradas

1. ¿Utiliza Computadora? 2. ¿Desea recibir mensualmente un reporte por computadora de los

estados contables? 3. ¿Está de acuerdo con la automatización del proceso de los cajeros?

Ejemplos de preguntas bipolares



Elegir una pregunta doble en una decisión bastante deficiente, ya que el entrevistado puede contestar solo una de ellas, o usted puede equivocarse sobre la pregunta que conteste y llegar a una conclusión errónea. Lo planteado anteriormente puede evitarse al hacer las preguntas con anticipación. Orden de las preguntas Existen dos tipos de razonamiento, el inductivo (estructura piramidal) y el deductivo (estructura de embudo). De la misma forma se pueden organizar las entrevistas. Como así también una combinación de ambos denominado estructura en forma de diamante. Estructura Piramidal (Inductivo): Se basa en una pirámide. Va desde la pregunta mas detalladas, del tipo cerradas y el entrevistador ampliara los temas con preguntas abiertas. Es útil este tipo de estructura cuando considera que el entrevistado requiere una introducción o bien se niega a involucrarse. Estructura de embudo (Deductivo): Se comienza con preguntas generales del tipo abiertas y más adelante se reduce las posibles respuestas con preguntas cerradas. Facilita el inicio de una entrevista sin comprometerla. La secuencia en este tipo de estructuras es útil cuando el entrevistado está involucrado sentimentalmente con el tema. Un beneficio que se obtiene del uso de la estructura de embudo es que organiza la entrevista de tal manera que puede redundar en una información tan detallada que haga innecesarias largas secuencias de preguntas cerradas y de sondeo. Estructura de diamante (Mixta): Es importante tener en cuenta que lo ideal es un tipo combinado de ambas estructuras, es decir una estructura de tipo diamante. Esto permite comenzar de una manera específica, luego examinar aspectos generales y finalizar con una conclusión muy específica. El entrevistador comienza con preguntas del tipo cerradas, después le pide al entrevistado una ampliación de los temas generales, y al final dará una conclusión más específica. Registro de la entrevista Es necesario que se registre los aspectos más importantes de la entrevista. Podrá usarse un grabador o tomar notas, esto dependerá de la persona que entrevista y que hará después con la información. Independientemente del método que utilice par el registro de la entrevista, es fundamental que se lleve un registro permanente durante la entrevista. Uso de grabador Es necesario tener en cuenta al entrevistado al decidir como documentar la entrevista. Es importante informar al entrevistado el uso del grabador, como así también el uso final de la grabación. Es fundamental asegurarle el destino final de la grabación, como así su confidencialidad. Si el entrevistado rehuye a la grabación acepte esta restricción. Una grabación tiene tanto ventajas y desventajas. Las ventajas son:



194

1. Proporciona un registro preciso y completo de todo lo mencionado por cada

persona

2. Libera al entrevistador para escuchar y responder con mayor rapidez

3. Permite un mayor contacto visual y una mayor armonía entre el entrevistado y

el entrevistador

4. Permite reproducir la entrevista para otros miembros del grupo

Las desventajas de grabar son numerosas e incluyen:

1. Quizás ponga nervioso al entrevistado y limite las respuestas

2. Quizás reduzca la capacidad de atención del entrevistador.

3. El inconveniente de localizar en una cinta determinados pasajes de

importancia

4. Incrementar el costo de recopilación de los datos por la necesidad de

transcribir las cintas.

La decisión de grabar las entrevistas es de tipo profesional y se tendrán que realizar con base al conocimiento del entrevistador. Toma de notas Tomar notas puede ser la única alternativa para documentar la entrevista, si el entrevistado niega el permiso de grabación. Es importante registrar la entrevista como se desarrolla. Las ventajas son:

1. Mantienen alerta al entrevistador

2. Sirven para recordar preguntas importantes

3. Permiten recordar las tendencias principales de la entrevista

4. Demuestran la preparación del entrevistador

Hay excelentes motivos par tomar notas, pero no deja de tener sus inconvenientes. Las desventajas son:

1. La pérdida del contacto visual con el entrevistado

2. La pérdida de continuidad en la conversación



3. Obligan al entrevistado a interrumpir sus planteos cuando el entrevistador

toma nota

4. Causan excesiva atención sobre los hechos y muy poca atención sobre las

opiniones.

Realización de la entrevista Se debe tener en cuenta la organización de la misma, llegar a horario, vestirse adecuadamente. Las respuestas que obtenga de su entrevistado dependerán de la primera impresión que él tenga de usted. Comienzo de la entrevista : saludarlo, presentarse, comenzar con preguntas más generales y no comprometedoras. Conforme se desarrolle la entrevista, mencione a su interlocutor el grado de detalle que desearía tener en las respuestas. Si necesita de mas profundidad en las respuestas puede solicitar al interlocutor que le dé un ejemplo. Solución de problemas durante la entrevista : Existen diferentes tópicos a tener en cuenta que bloquean la habilidad de respuesta del entrevistado. La mayoría de estos problemas se pueden corregir o evitar si se percata su existencia. Existen ocho problemas que bloquean la habilidad de respuesta del entrevistado. Ellos son: 1. Percibir que la autoestima del entrevistado se encu entra amenazada : En

ocasiones se dará cuenta que amenaza la autoestima de la persona que entrevista. Esto ocurre si aparenta ser superior o desafía la opinión del entrevistado ante ciertos temas centrales.

2. Reacciones emotivas a temas conflictivos : Este problema podría enfrentarse ante

respuestas que tengan una reacción emocional ante un tema conflictivo. Una respuesta emotiva se identifica cuando el entrevistado concluye el tema o lo cambia abruptamente.

3. Malentendidos respecto a la sucesión de acontecimie ntos : Los errores en la

apreciación cronológica de los acontecimientos implican problemas potenciales. Esto ocurre cuando el entrevistado confunde el orden correcto de los acontecimientos.

4. Apego a formas sociales tradicionales: Este tipo de apego puede traer

problemas, sobre todo ante un entrevistador hombre y una entrevistada mujer, donde puede crearse situaciones donde no pueda hablarse de manera normal. Para solucionar esto es conveniente modificar el texto de alguna pregunta o mencionarla con posterioridad.

5. Equívocos al inferir sobre lo observado : Es un problema muy común, por

ejemplo: El entrevistado observa que entrevisto primero a sus subordinados y él



196

deduce que para el entrevistador las opiniones de ellos son más importantes que la suya.

6. Competencia por el tiempo: El problema que surge acá es por el tiempo de la

entrevista. Uno puede darse cuenta cuán ocupados están los integrantes de la organización cuando intenta coordinar una entrevista. Si existe problema respecto a la atención por parte del entrevistado, sería conveniente reprogramar la entrevista para una próxima reunión

7. Olvido de temas importantes: Algo menos frustrante, pero no menos importante es

la posibilidad que el entrevistado olvide elementos importantes. Una forma de manejar el problema del olvido es averiguar y corroborar los hechos a partir de la información de archivo, de otras entrevistas o de observación.

8. Mentir para ocultar hechos importantes: La falsedad de los argumentos del

entrevistado es una amenaza final que afecta la utilidad de la información contenida en una entrevista. El interlocutor miente por diversas razones: orgullo, competencia, vergüenza, etc. La mejor defensa ante alguien que miente es una buena ofensiva, generando además una atmósfera de confianza, que asegure al interlocutor la confidencialidad de la información brindada

Conclusión de la entrevista Todo el material de la entrevista debe cubrirse en un período de 45 minutos a una hora. La adecuada conclusión de una entrevista es tan importante como su inicio. Durante la entrevista repita algunas de las respuestas de su entrevistado para verificar que comprendió lo que él quiso expresar. Revise con su entrevistado el informe de la entrevista, en una reunión de seguimiento. Esto permite aclarar la idea que tuvo en mente el entrevistado y le permitirá a éste saber que esta interesado. Redacción del informe de la entrevista Aunque la entrevista en si fue concluida, apenas comienza su trabajo sobre los datos de la entrevista. Necesita captar la esencia de la entrevista en un informe escrito. Es importante que se escriba el informe tan pronto ha concluido la entrevista. Cuanto más tiempo transcurra para redactar el informe, aparecen cada vez más sospechas sobre la certidumbre de la información. Cuando escriba el informe, mantenga una secuencia de los acontecimientos. Las impresiones pueden perderse si no se registran con rapidez.



Texto 10

Cuestionarios Tipo de información buscada Los cuestionarios constituyen una técnica de recopilación de información que permite a los analistas recoger opiniones, conductas y características de las diversas personas claves de una organización que se encuentran involucrados en la operación de un sistema o en la implementación de uno nuevo. Las respuestas que se obtienen mediante cuestionarios de preguntas cerradas pueden cuantificarse. Las respuestas de preguntas abiertas se analizan e interpretan de manera distinta. Las preguntas referentes a actitudes y opiniones son muy sensibles al tipo de palabra que elija el analista. Mediante el uso de cuestionarios el analista puede cuantificar los resultados de las entrevistas. Los cuestionarios sirven para sondear una gran muestra de usuarios de sistemas con el fin de detectar problemas, o bien para tener en cuenta aspectos importantes antes de la programación de las entrevistas. Existen grandes similitudes entre las técnicas de entrevista y cuestionario, y tal vez lo ideal sería utilizarlas en conjunto: ya sea para darla seguimiento a respuestas ambiguas de un cuestionario, o bien para el diseño de cuestionarios basados en los resultados de una entrevista. Sin embargo, cada técnica tiene funciones particulares y no siembre es necesario el uso de ambas. Planificación para el uso de cuestionarios Los cuestionarios pueden verse como una forma rápida de recopilar cantidades masivas de datos acerca de la opinión de los usuarios al sistema actual: que problemas experimentan ellos en su trabajo y qué es lo que espera de un sistema nuevo o modificado.



198

Si bien un cuestionario permite recopilar grandes volúmenes de información sin requerir entrevistas personales, el desarrollo y la planeación de un cuestionario útil, requiere bastante tiempo. Lo primero que hay que definir es que se busca con un cuestionario. Por ejemplo si se quiere saber el porcentaje de usuarios que prefiere un centro de cómputos que les brinde mayor cantidad de paquetes, lo ideal es el cuestionario, pero si por el contrario lo que se intenta establecer es un análisis profundo sobre un proceso de toma de decisiones, entonces la mejor elección sería la entrevista. Existe una serie de lineamientos para establecer la conveniencia de los cuestionarios. Considere el uso de cuestionarios si: 1. Las personas a quienes necesita interrogar se encuentran muy dispersas.

(diferentes áreas de una gran organización) 2. Existe una gran cantidad de personas involucradas en el proyecto de sistemas y es

conveniente saber que porcentaje de ese grupo aprueba o no alguna característica del sistema propuesto.

3. Se desea medir la opinión general antes de que el proyecto de sistemas tome una

dirección particular. 4. Desea sondear los problemas que presenta el sistema actual para identificarlos y

darle seguimiento por medio de entrevistas. Una vez que ha encontrado una buena razón para hacer uso de los cuestionarios, puede iniciar la formulación de preguntas. Redacción de preguntas La mayor diferencia entre las preguntas de entrevista y las de cuestionario, es que durante la entrevista se mantiene la relación entre la pregunta y su significado. En una entrevista, el entrevistador puede afinar una pregunta, cambiar el curso de las preguntas y tener, en líneas generales, el control de las circunstancias. De lo anteriormente dicho es poco posible en los cuestionarios. Esto implica que las preguntas deben ser completamente transparentes, se debe anticipar a las respuestas de las preguntas y que el manejo del cuestionario sea planificado con todo detalle. Los tipos básicos de preguntas que se utilizan en los cuestionarios son las preguntas abiertas y las preguntas cerradas, de la misma forma que se utilizan en la entrevista. Debido a las restricciones particulares de los cuestionarios, se requiere cierta discusión adicional sobre los tipos de preguntas.



Preguntas Abiertas Hay que recordar que las preguntas abiertas son la que permiten al entrevistado cualquier opción de respuesta. Ej.: ¿Cuál es la utilidad de los manuales del usuario para el sistema de facturación?. Cuando el analista redacta las preguntas abiertas para un cuestionario, se anticipa al tipo de respuesta que piensa obtener. Es importante que las respuestas que reciba puedan interpretarse correctamente, de lo contrario se desperdiciarán recursos importantes en el desarrollo e interpretación de un cuestionario inútil. Cuando se redacta una pregunta abierta es importante guiar a quien responde. Las preguntas abiertas son indispensables cuando uno debe conocer la opinión de los miembros de la misma. Es conveniente las preguntas abiertas cuando sea imposible enumerar todas las posibles respuestas de una pregunta. Estas preguntas son importantes para cuando no es posible establecer con precisión los problemas que presenta el sistema actual. Las respuestas a preguntas abiertas sirven para centrarse en problemas más específicos, mediante entrevistas a las personas claves.

• Las preguntas abiertas son muy útiles cuando uno tiene que recabar información, teniendo en cuenta las observaciones particulares del usuario, como así también las percepciones de cada uno.

Preguntas Cerradas Recuerde que las preguntas cerradas son las que limitan el número disponible de opciones de quien responde el cuestionario, por ej. ¿Cuál de los programas detallados anteriormente se utilizan en el área contable?. Observe que no se pregunta a los que responden el cuestionario el motivo de su preferencia, ni tampoco se les pide que seleccionen más de uno.

¿Cuáles son los problemas más frecuentes con los que se enfrenta con las salidas de la computadora? De los problemas enumerados anteriormente ¿ Cuál de ellos es el más grave? ¿Por qué?

Preguntas abiertas utilizadas en los cuestionarios



200

Las preguntas cerradas deben utilizarse cuando el analista sea capaz de enumerar de antemano todas las respuestas posibles. Las preguntas seleccionadas deben ser mutuamente excluyentes, a fin de no permitir la selección de ninguna otra. Cuando se requiera explorar a gran cantidad de gente en obvio el uso de las preguntas cerradas, teniendo en cuenta la facilidad que tomarán los datos recopilados. En ambos casos, la elección de preguntas abiertas o preguntas cerradas en un cuestionario, tiene inconvenientes. Las respuestas a las preguntas abiertas permiten al analista contar con una mayor riqueza, así como obtener mayor profundidad y amplitud sobre los temas. Las preguntas abiertas se redactan con facilidad, pero en análisis de sus respuestas es difícil y requiere de bastante tiempo. Cuando nos referimos a la redacción de preguntas cerradas, tienen un grado de dificultad mayor para su preparación, dado que se debe tener en cuenta la amplia gama de respuestas que el usuario puede dar, pero sus respuestas son analizadas con facilidad.

• Las preguntas cerradas se utilizan cuando el analista puede definir la totalidad de las posibles respuestas. Son fácilmente analizables, dado que el usuario no se extiende en las respuestas. Sólo se limita a las opciones propuestas

La elección del vocabulario

Tanto como en las entrevistas, en los cuestionarios la selección de las palabras es de gran relevancia para lograr que los cuestionarios sean efectivos. Quienes respondan el cuestionario apreciarán el esfuerzo realizado en la preparación. Por ejemplo, debemos tener en cuenta los nombres que la organización da a cada uno

Por lo general los datos de ventas se reciben tarde • De acuerdo • En desacuerdo Cuando los datos de ventas se procesan en el centro de cómputos, se obtienen con retrasos • Nunca • Rara Vez • En ocasiones • Con frecuencia • Siempre

Preguntas cerradas utilizadas en cuestionarios



de los niveles y no generalizarlos, como Jefes de área o supervisores, no existiendo estos puestos en la organización en la que estamos trabajando. A continuación podemos ver algunos lineamientos que son útiles al elegir el lenguaje de un cuestionario: 1. Use lenguaje sencillo, mantenga una redacción sencilla.

2. Use preguntas cortas

3. No sea condescendiente con los que contestan.

4. Evite la parcialidad en la redacción. Evite las preguntas censurables.

5. Dirija las preguntas a las personas indicadas, (dirigidas a quienes puede responder).

No suponga un conocimiento muy profundo.

6. Asegúrese que las preguntas sean técnicamente precisas antes de incluirlas en el

cuestionario.

Diseño y Aplicación de Cuestionarios Muchos de los principios relevantes en el diseño de formas para la captura de datos son importantes. Si bien el motivo de un cuestionario es recopilar actitudes, opiniones y características cuyo impacto llegara a afectar el trabajo de los usuarios, los que responden los cuestionarios no están siempre motivados para hacerlo. Recuerde que en las organizaciones tienden a recibir infinidad de cuestionarios, que tienen una concepción pobre. Un cuestionario bien diseñado y de relevancia, elimina cierta resistencia a responder. Formato de cuestionarios Disponga suficiente espacio en blanco: Es importante que tenga suficiente espacio en blanco. Cuando hablamos de espacio en blanco, es el que rodea a las áreas escritas. Un cuestionario que sea compacto será poco atractivo para llenarlo, aunque utilice menos papel para su impresión. Disponga de suficiente espacio para las respuestas: Además del espacio en blando, debe uno dejar suficiente espacio para anotar la respuesta. Esto lo hace mas atractivo para el que debe responder, a fin que pueda responder con comodidad Use círculos para las respuestas: Es útil pedir al usuario encierre en un círculo la respuesta correcta, porque de lo contrario algunos la tacharán, otros tacharán las incorrectas y serán difíciles para su tabulación.



202

Use los objetivos como ayuda para establecer el for mato: Antes de diseñar el cuestionario, necesita definir sus objetivos, por ej. si el objetivo es dirigir su encuesta al mayor número de personas o no, o que tengan una mayor profundidad en menor número de usuarios. Si se desea obtener respuestas escritas, es necesario incluir el espacio que requiera el desarrollo de las respuestas con comodidad. Mantenga un estilo coherente: Organice de manera consistente el cuestionario. Coloque las instrucciones siempre en el mismo lugar, de manera que la persona que responda el cuestionario sepa donde buscar la ayuda que corresponda, de la misma manera debe tener cuidado respecto a la utilización de mayúsculas y minúsculas. Orden de las preguntas Es muy importante el orden de las preguntas, es necesario definir bien los objetivos del cuestionario para definir el orden de las preguntas. Es importante ver el cuestionario desde el punto de vista del que responde las preguntas. Las preguntas de importancia para quien contesta el cuestionario van primero: Las primeras preguntas deben abordar temas de importancia para quien responda. Deben sentir que al contestar el cuestionario motivarán un cambio o que llegarán a generar algún cambio. Esto crea un efecto positivo en la persona que contesta el cuestionario, y es una técnica utilizada para involucrar de manera rápida a las personas. Agrupe preguntas del mismo tema: Es importante tener en cuenta que es más cómodo para quien responde el cuestionario que las preguntas lleven un orden, ya que el usuario se organizará mentalmente para responder por cada grupo de preguntas. Aunque para muchos investigadores el orden aleatorio de las preguntas da más veracidad a las mismas, pero pueden alterar la paciencia. Plantee primero los temas de menor controversia: Si existen temas de gran controversia, plantee estos después de preguntas más sencillas o que no generen problemas. Si existió algún problema puntual sobre algún tema, primero plantee preguntas más genéricas sobre el mismo tema y posteriormente, profundice sobre aquellos que es controvertido para los usuarios del área.

• Es importante establecer quien debe responder al cuestionario, dependiendo cuales son los objetivos de la información que se busca.

• Los receptores se eligen por ser prototipos de un nivel, por su antigüedad en la

empresa, por sus responsabilidades, u otro interés especial sobre el tema.



Métodos para la aplicación del cuestionario El analista de sistemas cuenta con varias alternativas para la aplicación de un cuestionario, y la elección del método generalmente lo establecen las circunstancias de la empresa. Dentro de las opciones para aplicar un cuestionario están: 1. Reunir todas las personas en un solo lugar

2. Entregar personalmente los cuestionarios en blanco y recogerlos una vez que estén

completos.

3. Permitir a quienes contestan el cuestionario que durante las horas de trabajo lo

respondan por su cuenta y posteriormente lo depositen en algún buzón.

4. Enviar por correo el cuestionario a aquellos empleados de sucursales remotas,

estableciendo una fecha límite para la devolución.

Cada uno de estos métodos tiene ventajas y desventajas. La recopilación de datos a partir de cuestionarios realizados en un solo lugar, es útil porque no hay tiempo de espera (salvo el utilizado en el llenado del cuestionario). El analista se asegura la recolección de datos, como así también la devolución de la totalidad de los cuestionarios completos. Una desventaja de la recopilación grupal de datos, es que no todos los empleados involucrados en la muestra podrán estar disponibles en la hora indicada. Debemos tener en cuenta que la actitud de los compañeros influye a favor o en contra del llenado de los formularios. Si la mayoría se interesa, el resto reaccionará de manera similar o viceversa. Los analistas obtienen un buen grado en la respuesta al distribuir personalmente los cuestionarios, pero esto implica u desgaste innecesario de tiempo, sobre todo si el grupo de muestreo es grande o muy disperso. Es muy común que en los casos que se les permite que llenen los formularios por su cuenta, exista una baja tasa de respuesta, ya que generalmente, la gente olvida los formularios, los pierde o los ignora a propósito,. De todas maneras, este procedimiento garantiza la confidencialidad, que no es posible resguardar cuando se realiza el llenado en grupo o cuando el analista se los entrega personalmente. Esto puede llegar a modificar levemente las respuestas a los cuestionarios. Una forma de incrementar la entrega es mediante un buzón y asociado a una lista de personas que se deberán ir tachando a medida que se entrega el cuestionario. De esta



204

manera se logra la independencia, respecto a las respuestas vertidas en el formulario, pero se mantiene la presión para la devolución de los formularios. El grado de respuesta de vuelta por correo es muy pobre, dado que este método no involucra de manera personal al encuestado. De todas maneras, es conveniente incluir al personal de la organización que se encuentra en lugares remotos, dado que ellos contarán con una perspectiva totalmente diferente sobre el sistema actual y uno futuro, y no deben quedar excluidos del mismo.



Texto 11

Análisis de sistemas orientados a datos La capacidad del analista para captar el flujo de información se facilita debido al uso de los métodos de análisis y diseño estructurado. Existen dos métodos principales para el análisis del flujo de datos de los sistemas orientados a datos: los diagramas de flujo y el diccionario de datos. El analista dispone de la libertad que le ofrecen los diagramas de flujo de datos que caracterizan gráficamente el flujo de datos dentro del sistema empresarial. El DFD representa una visión de las entradas, procesos y salidas al sistema. Una vez que se concluyen los diagramas de flujo de datos en distintos niveles sucesivos, los analistas de sistemas los utilizan para ayudarse a catalogar los procesos, el flujo, el almacenamiento, las estructuras y los elementos en un diccionario de datos. Los nombres utilizados para identificar los datos son de gran importancia. Los analistas al nombrar a los elementos de los sistemas orientados a datos, deben utilizar nombres significativos que los distingan de otros nombres ya existentes en el sistema. El flujo de datos para el establecimiento de las ne cesidades Cuando los analistas indagan sobre los requisitos de información de los usuarios, deben ser capaces de concebir la manera en que los datos fluyen a través de la organización, los procesos o transformaciones que sufren tales datos y sus tipos de salidas. Si bien las entrevistas y la investigación de documentos permiten contar con una narración verbal del sistema, puede obtenerse también una descripción visual que sea de gran utilidad. Los analistas se encuentran en posición de agrupar en un esquema gráfico los movimientos del flujo de los datos a lo largo de la organización, mediante el uso de los diagramas de flujo de datos, el cual enfatiza la lógica que sustenta al sistema. Por medio de cuatro símbolos el analista de sistemas es capaz de crear una descripción pictórica de la información, que eventualmente proporcionará una documentación sólida del sistema.



206

Ventajas de un enfoque de flujo de datos El enfoque de flujo de datos tiene tres ventajas principales a la explicación narrativa sobre la manera en que la información fluye a través del sistema. Las ventajas son: 1. La libertad de contar con rapidez con una implantación técnica del sistema

2. La comprensión adicional de la relación existente entre los sistemas y subsistemas.

3. La comunicación a los usuarios del estado actual del sistema mediante los

diagramas de flujo de datos.

La ventaja principal radica en la libertad de hacer uso de sólo cuatro símbolos. Ninguno de los símbolos especifica aspectos físicos e la implantación. Por ejemplo establece el almacenamiento de datos, pero no obliga a especificar el medio de almacenamiento. Esto permite a los analistas conceptualizar el flujo de datos antes de comprometerse prematuramente a la realización. El enfoque de flujo de datos tiene como ventaja servir como un ejercicio para los analistas, para comprender mejor las relaciones entre los sistemas y subsistemas. Otra ventaja es que puede utilizarse como un instrumento de interacción con los usuarios. Puede mostrarse una representación incompleta de la visión del analista, y luego se les pediría a los usuarios que presentaran sus comentarios sobre la visión del analista.

Entidad

Flujo de datos

Proceso

Almacén de datos



Convenciones en los diagramas de flujo de datos Para representar el flujo den un diagrama de flujo de datos se utilizan cuatro símbolos básicos que son: un cuadrado doble, una flecha, un rectángulo con las esquinas redondeadas, y un rectángulo abierto por una de sus caras (cerrado por la izquierda y abierto por la derecha), tal como se muestra en la figura precedente. Con la combinación de estos símbolos puede representarse gráficamente un sistema completo y numerosos subsistemas. El cuadrado doble representa una entidad externa (una empresa, una persona, una máquina) que da y recibe datos del sistema. La flecha representa el movimiento de datos de un punto hacia otro, donde la punta señala el destino de los datos. El flujo de información que ocurre de manera simultánea puede representarse con dos flechas paralelas. Cada flecha se define con un nombre apropiado correspondiente al flujo de datos. Se utiliza un rectángulo con sus esquinas redondeadas para indicar la existencia de un proceso de transformación. Los procesos siempre denotan un cambio o transformación de los datos. En virtud de esto debemos tener en cuenta que los datos que salen siempre tendrán un nombre diferente a los datos que entraron. El último símbolo básico que se utiliza en los diagramas de flujo de datos representa el almacenamiento de la información, y es un rectángulo abierto por uno de sus extremos (cerrado por la izquierda y abierto por la derecha). En los diagramas de flujo de datos los tipos de almacenamiento físico no se especifica, simplemente se indica un depósito de datos. Diagrama de flujo de datos El diagrama de flujo de datos representa el flujo de información a través del sistema. Pueden usarse también como instrumento de interacción entre los usuarios. DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS 1) Desarrolle el diagrama de flujo de datos mediante el enfoque descendente

a) Hacer lista de entidades externas, los flujos de datos, los procesos y los almacenes de datos.: Permitirá determinar los limites del sistema

b) Dibuje diagrama de flujo de datos básico. A partir de los datos obtenidos generar el diagrama de flujo establecido

2) Cubrir detalles

a) Por pasos añadir mas detalle a cada proceso b) Indique excepciones cuando estas se requieran. No abusar de las excepciones

porque sino entorpecen la interpretación.



208

3) Dibujar nuevamente los diagramas y volver a definir todos los símbolos por medio de nombres significativos.

El analista de sistemas debe concebir el flujo de datos desde una perspectiva de lo general a lo particular. Puede iniciar un diagrama de flujo de datos a partir de la narración del sistema organizacional, haciendo uso de las cuatro categorías. El primer diagrama de nivel cero, debe tener una visión que incluya lo básico de las entradas, los procesos y las salidas. Este será el diagrama más general. En segundo término, se deberán llenar los diagramas de flujo de datos agregando los detalles de cada uno de los procesos. Mediante la descomposición de los diagramas, se obtiene un mayor grado de detalle. Cuando se dibuja el primer diagrama, las entradas y las salidas se definen y se mantienen constantes a lo largo de los diagramas consecutivos. Las excepciones se ignoran en los primeros dos o tres niveles de dibujo del diagrama de flujo de datos. A medida que vamos agregando niveles los diagramas de flujo de datos, debemos evaluar el grado de descomposición de los mismos, ya que se perdería tiempo y se sacrificaría comprensión si el diagrama se volviera demasiado complejo. Si los diagramas de flujo de datos se utilizan como instrumento para solicitar más requerimientos específicos, no deben ser altamente detallados no deben considerarse concluidos, antes de que se cuente con la oportunidad de revisarlos. Una vez que los diagramas de flujo de datos se aclaran, el siguiente paso es volverlos a dibujar y rotularlos de manera significativa. Como alta prioridad debe mantenerse una denominación efectiva, de manera tal que aquellas personas poco familiarizadas con el sistema, tan pronto tengan acceso al diagrama y con un mínimo de capacitación, sean capaces de comprender su contenido.

• Los diagramas de flujo de datos son de gran utilidad en el análisis y diseño de procesos. Son útiles para logran una interacción adicional con los usuarios.

• Los diagramas de flujo de datos sirven para documentar al sistema. Pueden

utilizarse para documentar niveles superiores e inferiores del análisis. Auxilian de manera sustancial a concebir la lógica de los flujos de datos de la organización.

Diccionario de Datos

El diccionario de datos es una especialidad dentro de los diccionarios de referencia que utilizamos en la vida diaria. El diccionario de datos es una referencia de “datos acerca de los datos”. Como documento recopila, coordina y confirma lo que un término específico significa para la gente de la organización. Los diagramas de flujo son un buen inicio para recopilar los términos del diccionario de datos.



Los analistas de sistemas deben estar conscientes y catalogar los diversos términos que se refieren al mismo dato. Esto evitará duplicar esfuerzos, favoreciendo una mejor comunicación entre los departamentos de la organización que comparten una misma base de datos. Es importante establecer las referencias cruzadas dentro del diccionarios de datos, a partir de estos cualquier cambio necesario en alguno de los programas pueden realizarse en todos los programas que comparten elementos comunes. Esto es lo que se denomina diccionario de datos automatizado. Comprensión del diccionario Actualmente numerosos sistemas de administradores de bases de datos vienen equipados con diccionario de datos automatizados. Algunos catalogan de forma automática los datos elementales, y otros, simplemente proporcionan el formato de captura. Es pertinente que el analista de sistemas conozca que tipo de datos componen el diccionario de datos, las convenciones utilizadas en ellos y la manera en que se desarrolla un diccionario de datos. Comprender el proceso para compilar el diccionario de datos, permite que el analista de sistemas conciba el sistema y la manera en que éste trabaja. Datos que contiene Una manera de saber lo que debe contener el diccionario de datos, es visualizar como debe utilizarse. Es el elemento básico de referencia par localizar los nombres y atributos de los datos utilizados en todo el sistema de la organización. Es importante destacar que mientras que un diccionario de datos pueda incluir numerosos datos, nunca estará concluido. Deberá actualizarse cada vez que se hagan cambios, como ocurriría para cualquier otro tipo de documentación. 1. Nombre del dato: Debe contener el nombre de cada dato, la manera de denominar

el dato en la mayoría de los programas. Como varios departamentos pueden usar varios nombres para el mismo dato, se usará el mas común de todos, así como el sinónimo.

2. Descripción del dato: Debe incluir una descripción textual del dato elemental, la

que debe ser concisa, pero informativa (no más de 3 frases). 3. Rango permitido: Debe incluir los distintos rangos y límites que se aplican al

elemento. Por ejemplo: el numero del mes debe ser mayor o igual a 1 y menos o igual a 12.

4. Longitud del dato : Debe incluir la longitud permitida para el dato elemental. Por

ejemplo el número de Cuit es de 11 posiciones.



210

5. Codificación adecuada: Cada dato debe incorporarse junto con su código y el significado que tiene. Es indispensable que la codificación sea consistente.

6. Información adicional de edición : La información requerida para asegurar la

edición debe estar presente en el diccionario. Es de gran utilidad si para cada entrada se registra de manera consistente toda la información.

Elaboración del Diccionario de datos Podemos utilizar diferentes formas para la elaboración de un diccionario de datos, por ejemplo fichas. Cada ficha contiene distintas características y distintos requisitos. Hay fichas para PROCESO, otras para el FLUJO DE DATOS, otra para el ALMACENAMIENTO DE DATOS, otra para la ESTRUCTURA DE DATOS, y para DATOS ELEMENTALES. Incorporación de los procesos de datos Se comienza por el nivel superior del diagrama de flujo de datos. La ficha debe contener el nombre del proceso, la descripción del mismo. Luego se tiene un registro de las entradas al proceso, un resumen del proceso y las salidas del proceso. Catalogar los flujos básicos de datos Se establece el resultado del proceso. Va la descripción, Fuente � destino y estructura de datos que viaja en el flujo. En esta misma etapa, catalogar los almacenes de datos que contengan los datos fundamentales para la operación adecuada de los procesos. Catalogar el almacenamiento de datos Se debe incorporar la descripción, contenido, flujos de datos entrantes y flujo de datos salientes. Catalogar la estructura de datos Compuesto de los datos elementales relacionados flujo de datos y volumen de datos que será procesado. Tanto los flujos como los almacenes de datos alimentan a las estructuras de los datos. Desglosar la estructura de datos en datos elemental es Es la estructura básica. El dato elemental. Recordar que los datos elementales son aquellos datos dentro del sistema que no tienen significado alguno si se llegaran a descomponer aún más.



Pasos para formar un diccionario de datos Aunque es un proceso redundante y no necesariamente sigue una secuencia lineal, se tienen cuatro pasos esenciales para integrar un diccionario de datos:

Paso 1 : Procesos. Paso 2 : Flujo de datos y Almacenes de Datos. Paso 3 : Estructura de Datos. Paso 4 : Datos elementales.

Incorporar el proceso Incorpore los procesos que descubra en los diagramas de flujo de datos iniciales. Estos son aquellas transformaciones esenciales que el sistema debe realizar par cumplir los objetivos. Catalogue los flujos básicos de datos Catalogar los flujos básicos de datos de los procesos que entren y salgan de los procesos plasmados en los diagramas de flujos. En la misma etapa, catalogue los almacenes de datos que contengan los datos fundamentales para la operación adecuada de los procesos. Describa la estructura de los datos Describir las estructuras de datos, que existan dentro del sistema. Desglose la estructura de los datos en datos elemen tales Este paso se refiere al trabajo con los componentes de significado más simple del sistema, los cuales son los datos elementales. Estos son los bloques básicos para la construcción de los sistemas. Uso del diccionario de datos Es diccionario de datos ideal se encuentra automatizado y además es interactivo. Como el analista conoce mas de los sistemas de la organización, los datos se incorporan en el diccionario de datos. Por otra parte el diccionario de datos no será nunca un producto concluido. Para evitar el agobio de construir por completo un diccionario, el analista de sistemas debe concebirlo como una actividad paralela al análisis y diseño de sistemas..



212

• El diccionario de datos se puede llegar a convertir en una curiosidad histórica si no se actualiza.

• El diccionario de datos llega a ser una fuente común de información de la

organización, para resolver incógnitas y disputas sobre aspectos relativos a la definición de datos.

• Un diccionario de datos actualizado sirve como excelente referencia para el

mantenimiento de sistemas poco familiares.



Texto 12

Preparación de la propuesta del sistema

La propuesta del sistema es un resumen de todo lo que el analista ha aprendido acerca de la empresa y de lo que ésta requiere para mejorar su desempeño. El analista hace uso de medios sistemáticos para la adquisición de hardware y software, identifica el costo – beneficio y analiza el costo – beneficio. Todos estos métodos se utilizan para la preparación del material de la propuesta del sistema. Las necesidades de información de los usuarios determinan en última instancia el tipo de equipo de cómputo, los dispositivos de almacenamiento de datos y el software comercial. El equipo y el software que propone el analista es su respuesta a la necesidad de información del usuario. Establecimiento de las necesidades de hardware y de software

Pasos para la adquisición del equipo de computación y del software

Inventario del equipo de cómputos

Estimación de las cargas de trabajo

Evaluación del software Evaluación del equipo

Adquisición del equipo de cómputos

Elección del proveedor

Pasos en la elección del equipo y del software



214

En este momento se analiza el proceso para la estimación de la carga de trabajo presente y futuro, como así también el proceso para evaluar el equipo y el software que manejarán de manera adecuada los requerimientos de trabajo. Los analistas deben trabajar en conjunto con los usuarios para determinar el equipo que será requerido. Existen una serie de pasos a seguir para definir las necesidades de equipo y de software. Primero, se debe inventariar el equipamiento existente, para descubrir con que se dispone, luego debe estimar las cargas futuras para el sistema, después, debe hacer una evaluación del equipo y del software disponible. El conocimiento de la estructura de la organización puede servir de apoyo en las decisiones del tipo de equipamiento. Las opciones de equipo podrán considerarse, una vez que los analistas, los usuarios y los directivos cuenten con una clara concepción de las tareas que se realizarán. Inventario del equipo de cómputo o hardware Es importante realizar un inventario de todo el equipamiento de computación que se encuentre disponible en la organización. A partir de esto uno puede establecer las alternativas de expansión o reasignación de equipamiento. De no existir inventario es necesario realizarlo de manera rápida. Se debe conocer: 1. Tipo de equipo, modelo, fabricante

2. Status de la operación (por instalar, en operación, en almacenamiento, y en

reparación)

3. Estimación del tiempo de uso del equipo

4. Vida proyectada del equipo

5. Localización física del equipo

6. Persona o departamento responsable del equipo

7. Estado financiero del equipo (propio – alquilado – alquilado con opción a compra)

El inventario debe ser de fácil llenado e identificar en forma separada los equipos periféricos, unidades de disco y monitores. Una vez que se define el equipamiento disponible, se apoya aún mas el proceso de la toma de decisiones cuando llegue el momento de definir el equipamiento requerido, ya que se eliminarán muchas dudas del equipamiento existente. Esta información puede ser utilizada también para proyectar si se satisfacen bien las necesidades de personal.



Estimación de la carga de trabajo El paso siguiente para definir las necesidades de equipo es estimar la carga de trabajo. En este paso es necesario definir el volumen de trabajo actual y el proyectado con el nuevo sistema, de manera tal que el equipamiento cuente con las posibilidades de manejar las cargas de trabajo actuales y futuras. Si las estimaciones son correctas la organización no tendrá que reemplazar el equipamiento, a menos que se presente un crecimiento no pronosticado en el uso del sistema. (Aunque la evolución tecnológica puede exigir un reemplazo). Para esto solo se analizará un muestreo de la carga de trabajo y no un análisis de la carga de trabajo dentro de diferentes equipos. Tanto en el sistema actual y el sistema propuesto es necesario describir específicamente las cargas de trabajo, para lo cual podremos utilizar un cuadro como el que se establece a continuación:

Sistema Actual

Sistema Propuesto

Tarea

Método

Personal (persona que realiza la tarea)

Costo / Hora

Cuando y Cómo

Requerimiento de horas hombre

Requerimientos de tiempo de máquina

Cuadro de comparación de las cargas de trabajo entre el sistema existente y el propuesto



216

Evaluación del equipo de computo (hardware) La evaluación del equipo de cómputo es una responsabilidad compartida entre los analistas, los usuarios y los directivos. Aunque los vendedores les darán todo tipo de detalles acerca de los equipos, los analistas deberán supervisar todo el proceso de evaluación, ya que ellos tendrán mayor interés dentro de la empresa. El analista debe orientar a los directivos sobre las ventajas y desventajas de los equipos. Con base al inventario del equipamiento actual y estimado, el siguiente paso será considerar los tipos disponibles de equipo que parecieran ajustarse a las necesidades proyectadas. En este momento uno deberá analizar con mas detalle las propuestas de los vendedores. Es necesario analizar para la evaluación del desempeño, la capacidad total del sistema (que cantidad de datos pueden procesarse simultáneamente), los tiempos muertos de la CPU y el tamaño de la memoria. Se analizarán ciertos criterios en demostraciones formales, aunque habrá algunas que no podrán simularse y tendrán que suponerse a partir de especificaciones del fabricante. Una vez que se conocen los requerimientos funcionales y se conocer los productos disponibles, como su comparación con los existentes se evaluará la conveniencia de adquirir equipamiento nuevo. Las opciones pueden encontrarse desde utilizar sólo el equipo disponible en la empresa actualmente hasta cambien de manera integral todo el equipamiento por un nuevo. Entre estas dos opciones se encuentran aquellas pequeñas o grandes modificaciones al sistema actual. Tamaño y uso de los equipos El avance de la tecnología obliga al analista estudiar los distintos tipos de computadoras disponible en el momento en que escribe la propuesta del sistema. A continuación se da una revisión general de las dimensiones de los equipos y de sus usos típicos. Computadora Personal (PC): Son las máquinas de uso frecuente y más populares. Uso domestico. Minicomputadoras: Similares a las PC pero definidas con mayor capacidad de almacenamiento y procesamiento, actualmente utilizadas en conexiones de red, que las hacen competitivas con computadoras de gran escala Computadoras de mediana escala : Podrían utilizarse para el procesamiento de manera simultanea tareas además de las capacidades de enlace. Computadoras de gran escala : Procesamiento de datos de gran volumen, mucho más rápido, con grandes capacidades de almacenamiento y procesamiento simultaneo desde múltiples sitios.



Soportes de almacenamiento de datos El almacenamiento de datos es sumamente importante para mejorar el funcionamiento y el costo del sistema. La elección de un medio de almacenamiento se determina por el tipo de proceso. Dentro de las preguntas fundamentales se tienen: Cuantos datos y por cuanto tiempo se almacenarán, que tamaño tienen los archivos y que tipo de acceso se necesitará para los datos almacenados. Dentro de los soportes de almacenamiento de datos podemos citar: Cintas Magnéticas Es el tipo de almacenamiento más antiguo y no ha perdido popularidad. Su ventaja principal es su bajo costo relativo, que lo define como conveniente para aplicaciones de gran volumen. La desventaja radica en el lento acceso a los registros para la actualización o consulta, ya que los datos se almacenan y se leen en bloques. Para poder actualizar un registro, debe leerse y volver a escribir la cinta entera. La cinta es útil para aplicaciones en las cuales todos los datos se almacenan temporalmente para corregirlos más tarde o un almacenamiento definitivo como un histórico. Discos Los discos son también medios magnéticos pero que permiten almacenar la información de rápido acceso. Los discos cuentan con una estructura de sector / pista para el acceso rápido de varios registros, sin tener que leer toda la estructura como se realiza con la cinta. Los discos están mas adaptados para las tareas de bajo volumen, además son preferibles para las operaciones de tiempo real, ya que los registros se alteran de manera rápida y los nuevos datos están disponibles en forma inmediata. Discos flexibles Los discos flexibles, también conocidos como diskettes o floppies, tienen características similares a los discos descriptos anteriormente. Son útiles para el manejo de datos de bajo volumen. Son portátiles y de bajo costo, la principal desventaja la baja capacidad de almacenamiento por unidad y la capacidad de procesar un solo archivo a un tiempo Discos Duros Estos discos cuentan con gran capacidad y alta velocidad de acceso. La principal ventaja es la gran capacidad de almacenamiento y la facilidad de uso. Pueden ser discos fijos o removibles. La mayor desventaja son el relativo precio alto inicial y la necesidad de respaldo de la información contenida Adquisición de los equipos



218

Uno de los puntos a tener en cuenta para realizar una correcta propuesta, en cuanto al equipamiento, es definir baje que forma vamos a realizar la instalación del equipamiento en la organización. Existen tres opciones para la adquisición de los equipos, que son: Compra, Alquiler y Alquiler con opción a compra. Cada uno de estos tiene ventajas y desventajas a considerar. Para decidir la mejor opción tenemos: los costos iniciales contra los costos a largo plazo, si la empresa puede comprometer capital en equipamiento y si desea un control total y responsabilidad sobre los mismos. La compra del equipamiento implica que la empresa sea la propietaria del mismo. La consideración determinante para la compra es la vida proyectada del sistema. Si el sistema será utilizado por mas de 4 o 5 años es la decisión más acertada. El alquiler con opción a compra (leasing) es otra posibilidad, que es más práctica si la vida proyectada del equipo es menor a 4 años. Además si es inminente el cambio de tecnología es la mejor opción. Permite a la empresa colocar el dinero en otro tipo de inversión. De todas maneras a largo plazo, económicamente no es la mejor opción. El alquiler es la tercer alternativa. Con esta opción no se compromete el capital de la empresa, por lo que no se requiere financiamiento. Esta opción hace mucho más fácil su cambio, y el costo de mantenimiento está generalmente incluido en el precio. Esta opción no es conveniente a largo plazo y sólo debería contemplarse a corto plazo, debido al alto costo final y que la empresa no es la propietaria del equipamiento. Esta alternativa es útil para resolver necesidades limitadas o no recurrentes. En base a estas diferencias el analista deberá analizar muy bien la propuesta a los directivos, para optar por la mejor opción, dentro de los conocimientos que el mismo cuenta de la organización y del equipamiento y propuestas obtenidas.

Ventajas

Desventajas

Comprar

1. A largo plazo, más económico que alquilar

2. Posibilidad de cambiar el sistema

3. Ofrece ventajas fiscales al permitir la depreciación acelerada

4. Control total sobre los equipos

1. El costo inicial es elevado 2. Riesgo de caen en la

obsolescencia 3. Riesgo a atarse a una

elección errónea 4. Plena responsabilidad

Alquiler con opción a compra

1. El capital no queda atado 2. No requiere financiamiento

1. La compañía no es dueña del sistema cuando finaliza el contrato de alquiler.

2. Por lo general hay una multa muy alta por terminar anticipadamente



3. El pago es menor que el

simple alquiler

el contrato. 3. El alquiler es más caro

que la compra. Alquilar

1. El capital no queda atado 2. No requiere financiamiento 3. Facilidad de cambio de

sistema 4. Generalmente incluye el

mantenimiento y seguro

1. La compañía no es dueña del equipo

2. Los costos son muy altos porque el proveedor asume el riesgo total.(es la alternativa más cara)

Evaluación del soporte del vendedor Existen ciertos aspectos fundamentales que considerar al evaluar los servicios que ofrecen los vendedores a la empresa. La mayoría de las casas comerciales ofrecen la prueba del equipo, y una garantía por 90 días contra defectos de fábrica, pero debe asegurarse que otra cosa puede ofrecerle el vendedor. Los establecimientos de prestigio se distinguen de sus competidores por la gama de servicios que ofrecen. La mayoría de los servicios de soporte adicional pueden negociarse de manera separada al alquiler o compra del equipamiento. 1. Los servicios de soporte incluyen:

2. Mantenimiento rutinario y preventivo del equipo

3. Tiempo de respuesta ante fallas (dentro de las 6 horas, al día siguiente etc.)

4. Préstamo de equipo en caso que el mismo deba cambiarse o fuera necesaria una

reparación externa

5. Organización de seminarios internos y externos para grupos de usuarios

Se debe tener en cuenta que puede resultar difícil obtener adiestramiento en equipos que no sean ampliamente utilizados por otras organizaciones. Aunque pueda ser atractiva la posibilidad de una instalación exclusiva, la posibilidad de un buen soporte a largo plazo puede disminuir. Es importante considerar en los contratos de compra o alquiler de los equipos que se involucre el área jurídica antes de la firma de contratos por servicios o adquisición de equipo Es importante considerar otras eventualidades antes de la compra del equipamiento, en la evaluación de una compra de estas características no es tan sencilla la tarea como

Cuadro comparativo entre las ventajas y desventajas de comprar, alquilar o alquilar con opción a compra del equipamiento



220

comparar costos y elegir la opción más barata, existen otras eventualidades que se deben considerar: 1. Posibilidad de expandir el sistema si las necesidades aumentan en el futuro

2. Posibilidad de enlazar el equipo con otras marcas

3. Beneficios de comprar más memoria que la proyectada como necesaria

4. Estabilidad corporativa del vendedor

La ampliación de los sistemas existentes es común para los proyectos de sistemas. Es conveniente instalar sistemas con capacidad de expansión. La competencia entre los vendedores ha fortalecido la idea de producir equipamiento que sea compatible, con los fabricantes líderes de cada sector, lo cual es importante, inclusive para la supervivencia del vendedor.

Evaluación del Software Los paquetes de software se han vuelto cada vez más accesible y deben considerarse con mucha atención. Pueden ahorrarse muchas horas de programación si ya existe un paquete de software adecuado para todo el sistema o parte de él.

Criterio de selección de proveedores 1) Soporte del equipo

a) Línea completa de productos b) Productos de calidad c) Garantía

2) Soporte del software

a) Todas las necesidades del software b) Programación individualizada c) Garantía

3) Instalación y adiestramiento

a) Apegarse a un calendario b) Adiestramiento in situ c) Línea de consulta directa

4) Mantenimiento

a) Procedimientos de mantenimiento de rutina b) Especificación del tiempo de respuesta en emergencias c) Préstamo de equipo durante las reparaciones

Lineamientos para la selección del proveedor



Los representantes de las casas comerciales pondrán mayor interés en su parte. El analista debe estar atento para evaluar el software, junto con los futuros usuarios. No debe dejarse influenciar por los avisos comerciales. Hay seis categorías principales donde puede evaluarse el software: 1) Efectividad 2) Eficiencia del desempeño 3) Facilidad de uso 4) Flexibilidad 5) Calidad de la documentación 6) Soporte del fabricante Evalúe el software comercial a partir de demostraciones con datos de la empresa, examine la documentación que lo acompaña, pero tenga en cuenta que no será suficiente una mera descripción del vendedor. Tenga en cuenta la necesidad de copias múltiples de software (para el uso en varias estaciones de trabajo), implica negociar una licencia de uso múltiple. Esto implica la compra de una copia a precio regular y copias adicionales a precio reducido.



222

También es posible negociar un contrato de servicios especiales que cubra el soporte del software adquirido, incluyendo en él el mantenimiento de emergencia y el preventivo, las actualizaciones son costo o a un precio reducido, como así también las copias adicionales de documentación y la capacitación de los usuarios. Pronóstico de los Costos y Beneficios

Evaluación del software 1) Eficacia en el desempeño

a) Capacidad para realizar las tareas requeridas b) Capacidad para realizar las tareas que se desearán más adelante c) Buen diseño de pantalla d) Capacidad adecuada

2) Eficiencia operativa

a) Tiempos de respuesta rápidos b) Captura eficiente c) Salidas eficientes d) Almacenamiento de datos eficiente e) Respaldos eficientes

3) Facilidad de uso

a) Uso de interfaces satisfactorias b) Disponibilidad de menús de ayuda c) Interfaz flexible d) Retroalimentación adecuada e) Buena recuperación ante errores

4) Flexibilidad

a) Opciones de entrada b) Opciones para la salida c) Compatibilidad con otro software

5) Calidad de la documentación

a) Buena organización b) Programas tutoriales de calidad c) Respuestas adecuadas a las preguntas

6) Soporte del fabricante

a) Línea de consulta directa b) Boletines c) Actualizaciones frecuentes (a bajo costo)

Lineamientos para la evaluación del software



Los costos y beneficios deben considerarse en conjunto ya que se interrelacionan y dependen entre sí. Muchas veces los beneficios se miden por su costo. Antes de presentar la propuesta el analista hará uso de una simulación, aunque no debe utilizar la simulación en todo para que la propuesta sea creíble. La condición principal es la disponibilidad de datos históricos. Si no se dispone de ellos el analista debe seleccionar algunos de los métodos de criterio, como la creación de escenario o alguna otra actividad. Estas alternativas son de bajo costo y fáciles de implantar. Identificación de costos y beneficios Los costos y beneficios pueden ser tanto de naturaleza tangible como intangible. Ambos deben tenerse en cuenta en las propuestas de los sistemas. Beneficios tangibles Los beneficios tangibles son las ventajas económicas cuantificables que obtiene la organización a través el uso del sistema de información. Por ejemplo, el aumento de la velocidad de procesamiento y contar con cierta información que de otra forma sería prácticamente imposible. Los beneficios tangibles pueden también estimarse en pesos, recursos o tiempo ahorrado. Beneficios intangibles Los beneficios intangibles son aquellos que la organización obtiene a través de un sistema de información y son difíciles de cuantificar, pero no por ello dejan de ser importantes. Los beneficios intangibles incluyen: la mejora del proceso de toma de decisiones; el incremento de precisión, incremento de satisfacción de los empleados al eliminar tareas tediosas. Aunque los beneficios intangibles del sistema de información, son elementos importantes para decidir si se procede o no con su implementación, un sistema soportado exclusivamente por beneficios intangibles no tendrá éxito. Costos tangibles Los conceptos de costos tangibles e intangibles presentan una similitud conceptual respecto a los beneficios tangibles e intangibles. Los costos tangibles son aquellos que pueden proyectar con precisión el analista de sistemas y el personal de costos o contabilidad. Dentro de estos costos se incluyen el costo del equipamiento, costo de recursos, costo de tiempo del analista, el costo de programación y otros salarios del personal. En líneas generales estos costos se encuentran definidos o pueden encontrarse fácilmente, ya que estos requerirán del gasto en efectivo de la empresa.



224

Costos Intangibles Los costos intangibles son difíciles de estimar y pudieran no conocerse. Entre ellos tenemos el costo de perder una ubicación competitiva, o deteriorar la imagen de la empresa debido al descuido continuo de los clientes por la ineficacia en la toma de decisiones por falta de información. Es muy difícil estimar los costos intangibles en términos económicos, pero son de suficiente importancia para no dejar de tenerlos en cuenta.

• Es importante tener en cuenta hasta el mínimo detalle para realizar una propuesta efectiva del sistema. Debemos tener en cuenta desde la buena elección del proveedor de hardware, de software, como así también el impacto de los costos y beneficios en el sistema a futuro.



Texto 13

Diseño efectivo de salidas Objetivo en el diseño de salidas La salida es la información que reciben los usuarios del sistema de información. Antes de convertirse en una salida adecuada, ciertos datos requieren de un proceso extenso, otros sólo se almacenan y cuando se solicitan, se consideran salidas con poco o nada de proceso. Las salidas pueden tomar distintas formas: los reportes impresos, tradicionales y salidas en formatos, tales como pantallas en monitor o salidas de audio. Los usuarios confían en las salidas para la realización de sus tareas, y con frecuencia juzgan el mérito del sistema exclusivamente por sus salidas. Con el fin de crear una salida de utilidad, el analista trabaja estrechamente con el usuario, mediante un proceso interactivo, hasta que el resultado llega a ser satisfactorio. Ya que una salida útil es esencial para lograr la aceptación y el uso del sistema de información, el analista de sistemas tiene varios objetivos que alcanzar cuando diseña una salida. Los objetivos de una salida son seis, tal como se detallan a continuación: 1. Diseñar una salida para satisfacer el objetivo planteado.

2. Diseñar una salida que se adapte al usuario.

3. Proveer la cantidad adecuada de información.

4. Asegurar que la salida esté disponible donde se necesita.

5. Proporcionar oportunamente la salida.

6. Elegir el método correcto de salida.

Diseño de la salida para satisfacer el objetivo pla nteado Toda salida debe contar con un propósito explícito. No es suficiente que se presente a los usuarios un reporte o una pantalla, sólo porque tecnológicamente es posible hacerlo. Durante la fase del análisis de determinación de los requerimientos de información el analista de sistemas identifica los propósitos a satisfacer, y con base a esos propósitos diseña la salida. El analista se dará cuenta que existen numerosas oportunidades para proveer una salida, simplemente porque la aplicación así lo permite. De todas maneras es necesario



226

recordar, que si la salida cumple con una función ésta no debe crearse, ya que hay costos de tiempo y de materiales asociados con cualquier salida del sistema. Diseño de la salida para adaptarse al usuario Es difícil personalizar la salida con un gran sistema de información que atiende a numerosos usuarios con diferentes propósitos. Teniendo como base las entrevistas, y observaciones, será posible diseñar salidas que se apeguen a la mayoría, si no a todas las necesidades de los usuarios y sus preferencias. Proveer la cantidad adecuada de información Es importante destacar que Más no siempre es mejor, sobre todo si nos referimos al volumen apropiado de información. Parte de la tarea del diseño de la salida es decidir qué cantidad de información es correcta para los usuarios. Obviamente que es una tarea muy difícil, ya que los requerimientos de información cambian de manera continua. El problema de la saturación de la información es tan común que se ha convertido en un tema reiterativo, pero de todas maneras no deja de ser una recomendación importante. Si la información es excesiva, y sólo se brinda para demostrar la capacidad del sistema, de hecho no se atiende a todos. Cuando se decida la magnitud de la salida, siempre se debe tener en cuenta al tomador de decisiones, quienes frecuentemente, no requieren de gran volumen de información de salida. Asegurar que la salida esté disponible donde se nec esita La salida se encuentra impresa en papel, desplegada en pantallas y otras formas elegidas para ello. En líneas generales la salida se produce en un lugar (por ejemplo el centro de cómputos) y luego se distribuye entre los usuarios. El incremento de las salidas on line, desplegadas en pantalla y que son accesibles de manera individual, han resuelto parte del problema de la distribución, pero una distribución apropiada es aún un objetivo para el analista de sistemas. Para ser útil la salida, debe presentarse al usuario adecuado; no importa lo bien que se diseñen los reportes si éstos no los ven las personas pertinentes. Obviamente carecerán de valor alguno. Proporcionando oportunamente la salida Una queja común de los usuarios es que no reciben de manera oportuna la información para la toma de decisiones.



El analista, no sólo debe estar conciente que la información debe ser recibida por el usuario correspondiente, sino que también debe considerar la puntualidad de su distribución. Aunque la oportunidad no es todo, desempeña un papel importante para la toma de decisiones. Una presentación a tiempo puede llegar a ser decisiva para la operación de la empresa. Elección del método correcto de salida Tal como habíamos dicho anteriormente, la salida puede tomar diferentes formas, incluyendo los reportes impresos en papel y la presentación de la información en pantalla. La elección del método correcto de salida para cada tipo de usuario es otro de los objetivos de los diseños de salida. Para mucha gente, cuando hablamos de salida la asocia con la idea de voluminosos informes en papel, pero esto ha cambiado. Con el movimiento hacia los sistemas en línea, la mayoría de la información se despliega por pantalla. El analista debe evaluar las ventajas involucradas al elegir un método de salida. Los costos difieren, como así también el impacto global hacia el usuario. La elección del método de salida no es trivial. Relación del contenido de la salida con el método d e salida Debe considerarse la relación existente entre el contenido de la salida de los sistemas de información con el método de salida. Cada vez que se diseñe una salida, es necesario pensar en la manera como la forma influye sobre la función y el propósito de la salida. La salida debe ser concebida de una manera general, de tal forma que cualquier información que contenga el sistema, y que sea útil para la gente, pueda considerarse como salida. Es posible concebir como salida, a cualquier cosa que sale de la organización, a la cual se le llamará “salida externa”, o que permanece dentro de la organización, la cual sería una “salida interna”. La salida externa nos es familiar por su uso para los recibos de servicios, publicidades, y otras comunicaciones que las organizaciones tienen con sus clientes, vendedores, proveedores, etc. Las salidas externas difieren de las salidas internas no sólo por el mecanismo de distribución, sino además por su diseño y apariencia. Muchos documentos externos, si se desea que se utilicen correctamente, deberán incluir instrucciones para el receptor. Además muchas salidas externas se imprimen en formularios en color y los con emblemas de la compañía.



228

Dentro de las salidas internas, tenemos varios informes de la toma de decisiones. Estos se distribuyen a toda la organización, desde un pequeño resumen, hasta un informe altamente detallado. Por ejemplo, un informe consolidado de las ventas totales del mes o un reporte detallado de la totalidad de las ventas semanales, discriminadas por vendedor. La elección de la tecnología de salida Para producir diferentes tipos de salidas, se requiere el uso de diferentes tecnologías. Para las salidas impresas, las opciones que contamos son las impresoras de impacto y no impacto. Para salidas por pantalla, tenemos opciones de monitores independientes o pantallas de cristal líquido. Las salidas de audio pueden ampliarse a través de un bafle o escucharse a través del parlante de la computadora. Otra de las opciones son las microfilmaciones, creadas por equipos de cámaras especiales y filmadas en microfichas. Impresoras Teniendo en cuenta que el informe impreso es el tipo más común de salida, es lógico suponer que en las grandes organizaciones lo que abunda son las impresoras. Aunque han alcanzado popularidad otro tipo de salidas, las empresas seguirán requiriendo las salidas impresas. Como analista de sistemas, deseará estar al tanto de las tecnologías de salidas disponibles, con base en su experiencia y en las publicaciones especializadas. La tendencia en las impresoras de los grandes sistemas de cómputo se dirige a mejorar la flexibilidad. Esto se traduce en el aumento de las opciones de ubicación de sitios de impresión; la colocación de diferentes números de caracteres por página, numerosos tipos y estilos de letra; impresoras más silenciosas y menor tiempo de intervención del operador. Las impresoras pueden dividirse en dos tipos de impacto y no impacto, las cuales se describen a continuación: Impresoras de impacto: Las impresoras de impacto son impresoras cuyos caracteres se crean cuando un objeto golpea la cinta entintada, la cual impacta contra el papel para la impresión. Dentro de las impresoras de impacto están las impresoras de matriz, las de margarita y las de banda. Las impresoras de matriz pueden imprimir a muy altas velocidades, y su salida puede ser cercana a una impresión de calidad. Las impresoras de margarita producen salidas con letra de calidad, utilizando un sistema similar al de las máquinas de escribir electrónicas.



Las impresoras de banda son impresoras de impacto de alta velocidad, que se utilizan en aplicaciones pesadas del procesamiento de datos, cuando no se requiere letra de calidad en la salida. El elemento característico de las impresoras de banda es una banda de acero inoxidable que tiene grabados en relieve los caracteres de impresión. Al imprimir, la banda da vueltas y en cada posición de impresión, un martillo oprime el papel y la cinta contra el carácter en relieve. Impresoras de no impacto: Las impresoras de no impacto son aquellas que crean caracteres sin impactar la cinta sobre el papel. Estas impresoras son de alta capacidad y de gran velocidad. Las categorías generales de las impresoras de no impacto son las térmicas, láser e impresoras de chorro de tinta. Las impresoras térmicas requieren de cintas especiales y de papel térmico especial, lo cual implica que los costos de suministros sean muy altos. Las impresoras de chorro de tinta, utilizan pequeñas válvulas para aplicar la tinta sobre la superficie del papel en forma deseada. Las impresoras láser, las cuales producen imagen mediante el uso del láser, lo que les da una gran velocidad y una impresión de letra de calidad. Cada tipo de impresora cuenta con sus propias ventajas y desventajas. El analista debe determinar el propósito de la impresión. Una vez que se establece, se tiene en cuenta tres factores fundamentales: 1. Confiabilidad de la impresora

2. Compatibilidad con el software y el hardware

3. Soporte del fabricante

Confiabilidad significa que la impresora realiza lo que se desea durante el período acorde y con una cantidad tolerable de reparaciones. Una impresora durable es muy importante cuando se trabaja con grandes volúmenes de material y estos se preparan para una fecha en particular. La compatibilidad de la impresora con el software y el hardware es importante. Teniendo en cuenta que muchas veces los sistemas se modifican o se enlazan con otros sistemas más pequeños, pueden generarse graves problemas de compatibilidad si los sistemas no se evaluaron exhaustivamente. Al igual que la compra o el alquiler de las computadoras, el mantenimiento del fabricante de las impresoras se negocia en forma independiente de otros convenios. Sin embargo, es importante que los fabricantes estén dispuestos a darle servicio a las impresoras el mismo día en sus instalaciones o bien, proporcionar préstamos de equipo mientras la impresora se repara.



230

Pantallas de salida Las pantallas se han vuelto una tecnología de salida muy popular. En un principio se utilizaba sólo para el acceso de datos, pero con el paso del tiempo las pantallas se han vuelto una tecnología ágil par muchos otros casos. Las pantallas proporcionan una tecnología de salida ideal para la información que se consulta una sola vez y que no requiere almacenamiento. La salida por pantalla es efímera y es válida cuando el usuario consulta ciertos datos para tomar una decisión momentánea. Salida de audio La salida de audio podría considerarse exactamente lo opuesto a la salida impresa. La salida de audio es temporal mientras que la impresa es permanente. El audio es para beneficio de un solo usuario, mientras que la salida impresa generalmente cuenta con una amplia distribución. El oído humano interpreta la salida de audio como un símil de la voz humana, aunque en realidad se produce con base a sonidos digitales.

Método Ventajas Desventajas Impresora Disponible en la mayoría de

las organizaciones. Gran flexibilidad en el tipo de salida. Capacidad para manejar grandes volúmenes de salida a bajo costo. Muy confiable con un mínimo de tiempos muertos.

Puede ser ruidosa. Problemas de compatibilidad con ciertos software. Puede requerir suministros especializados y costosos. Requiere de la participación del operador Puede ser lente dependiendo del modelo

Pantalla de video Interactiva Opera en línea, en tiempo real por medio de su enlace a una red. Silenciosa Adecuada para el envío de mensajes efímeros

Requieren de cableado y de espacio disponible. Llega a ser costosa si se requiere para numerosos usuarios.

Salida de audio Adecuada para usuarios individuales. Para mensajes efímeros o transitorios a los cuales deba responderse de manera inmediata y descartarse después. Útil para aquellas tareas que requieran que el trabajador disponga de las manos libres

Su desarrollo es costoso Cuenta con aplicaciones limitadas Aún no se ha perfeccionado bien



Microformas Manejo de grandes volúmenes de información. Reduce las necesidades de espacio de almacenamiento. Preserva aquellos materiales frágiles y de uso frecuente.

Requiere de software particular para poder contar con un acceso sencillo. Requiere de un equipo especial para la impresión de copias Inversión costosa en un principio

Comparación de los métodos de salida

Microformas Las microformas son ideales para la salida de grandes volúmenes de información y pueden reducir de manera muy significativa el espacio físico que requiere su almacenamiento. Se requieren máquinas especiales para manejar las cintas magnéticas y crear los microfilms. Se utilizan máquinas similares a los proyectores para ampliar las imágenes, de tal forma que puedan leerse. Entre las ventajas de las microformas, están las de ahorrar grandes espacios; mantener los registros requeridos obligatorios sin necesidad de un almacenamiento masivo y la preservación de un material frágil que sea utilizado con frecuencia. Consideraciones al elegir la tecnología de salida Existen varios elementos a considerar en la elección sobre la tecnología de salida. Aunque la tecnología cambia con rapidez, hay principios que permanecen prácticamente constantes en relación a los avances tecnológicos. Estos elementos son: 1. ¿Quién usará la salida? (requisito de calidad).

2. ¿Cuanta gente necesita la salida?

3. ¿En dónde se necesita la salida? (Distribución).

4. ¿Cuál es el propósito?

5. ¿Con qué velocidad se requiere?

6. ¿Con qué frecuencia?

7. ¿Durante cuanto tiempo será almacenada (o deberá almacenarse)?

8. ¿Bajo qué relaciones particulares se produce la salida, almacena y distribuye?

9. ¿Cuáles son los costos iniciales y posteriores de mantenimiento y de suministros?

10. ¿Cuáles son los requisitos ambientales (absorción de ruido, espacio para el equipo,

cableado) para las tecnologías de salida?



232

Al examinar cada uno de estos factores, el analista podrá identificar sus interrelaciones y como pueden compararse los sistemas en particular. ¿Quién usará la salida? Es importante identificar quién utilizará la salida, ya que los requisitos del puesto, permitirán definir el método apropiada de la salida, dependiendo de la utilización de estas podrá definirse una salida impresa o por pantalla. Dependiendo si el receptor de la salida es interno o externo a la organización. Los receptores de las salidas externas (clientes, vendedores, proveedores, etc.) requerirán de salidas diferentes que los usuarios internos de la empresa. Con frecuencia los clientes carecen de acceso a las salidas electrónicas, ya que simplemente no cuentan con el equipo requerido, en este caso se le debe proporcional una salida impresa. El conocer quien será el usuario de la salida, permite determinar el requisito de calidad de la salida, teniendo en cuenta la calidad del papel, de impresión, etc. ¿Cuántas personas necesitan la salida? La elección de la tecnología de la salida también queda influenciada por el número de usuarios que la usarán. Si numerosas personas requieren de la salida, probablemente se justificarían copias impresas. Si un solo usuario requiere de la salida, una salida por pantalla, sería lo mas apropiado. ¿En dónde se necesita la salida? Otro factor que influye en la elección de la tecnología de salida es el destino físico de ella. Aquella información que permanecerá cercana a su punto de origen, que será utilizada por muy pocos usuarios dentro de la empresa y que pudiera almacenarse y consultarse con frecuencia, con seguridad puede ser impresa. Una abundante información que deba transmitirse a los usuarios a grandes distancias en operaciones satélites, puede distribuirse mejor de manera electrónica y el receptor decide si lo imprime o lo presenta en pantalla o lo almacena. ¿Cuál es el propósito de la salida? Otro de los factores a considerar para elegir la tecnología es la función de la salida. Si la salida tiene el propósito de atraer accionistas a la organización y que estos tengan a su disposición las finanzas corporativas, los más adecuado sería presentar un informe impreso con un excelente diseño. Si por el contrario el propósito es mostrar la evolución actualizada cada 15 minutos de la cotización de la bolsa, lo más conveniente será la utilización de salidas en pantalla. ¿Con qué velocidad se requiere la salida?



Conforme seguimos los tres niveles de la organización, estratégico, intermedio y administrativo de la operación corroboramos que la toma de decisiones en el nivel inferior de la administración de las operaciones requiere de salidas rápidas. Por ejemplo detener la línea de producción si las materias primas no están disponibles. Las salidas mediante terminales en línea puede ser de gran utilidad. A medida que ascendemos a los otros niveles de la administración observamos que los gerentes estratégicos, realmente requieren poco de una salida rápida, buscan salida para periodos específicos que los auxilien en pronosticar las tendencias de la organización. ¿Con qué frecuencia se requiere la salida? Entre más frecuente se accede una salida, más importante será disponer con terminales conectadas en línea al sistema. En las salidas de acceso poco frecuente, podemos decidir salidas impresas. ¿Durante cuánto tiempo será almacenada la salida? Las salidas impresas en papel se deterioran con rapidez, las salidas preservadas en microfilms sobreviven a alteraciones ambientales, tal como la luz y la humedad. En consecuencia, de ser necesario convendrá microfilmar las salidas que deban almacenarse por largos periodos de tiempo. ¿Bajo qué regulaciones particulares se produce la s alida? Ciertas salidas están sujetas a la regulación del gobierno. Cada negocio se encuentra entre diferentes y complejas regulaciones. En algunos casos no está establecida la forma exacta de la salida, pero sí el contenido, mientras que en otros casos quizás lo que esta reglamentado sea la forma estándar. ¿Cuáles son los costos iniciales y posteriores del mantenimiento y los suministros? Los costos iniciales de adquirir o alquilar equipo deben considerarse como otro elemento que entra en la elección de la tecnología de salida. La mayoría de los vendedores le ayudarán a estimar los costos iniciales de compra o alquiler del equipamiento. Sin embargo, muchos vendedores no proporcionarán información acerca del costo para mantener operando una impresora. De tal forma es responsabilidad del analista, investigar el costo de operación de las diferentes tecnologías de salida. Para evaluar correctamente los costos en su totalidad, es necesario tener en cuenta no sólo los costos iniciales y de funcionamiento, sino el tiempo de uso, ya que el costo irá disminuyendo conforme se utilizan a largo plazo.



234

¿Cuáles son los requisitos ambientales para las tec nologías de salida? Las impresoras requieren de un ambiente seco y fresco para operar adecuadamente. Los monitores requieren de espacio y cableado para conectarse. La salida de audio requiere de un sitio relativamente silencioso, que permita que el usuario comprenda los sonidos digitalizados. La tecnología de salida por sí sola llega a causar alteraciones ambientales. En base a esto el analista debe ser muy cuidadoso con la elección de la tecnología.



Texto 14

Desarrollo de sistemas críticos Las técnicas de ingeniería de software perfeccionadas, los mejores lenguajes de programación y una mejor administración de la calidad han conducido a mejoras importantes en la confiabilidad del software. Sin embargo, para sistemas críticos se requiere tener más cuidado para hacer cumplir los altos niveles de confiabilidad. En estos casos, se utilizan técnicas de programación especiales para tener la certeza de que el sistema sea seguro y fiable. Existen dos enfoques complementarios que se utilizan cuando la meta es desarrollar software confiable: 1. Prevención de fallas : El proceso de diseño e implementación para el sistema debe

utilizar enfoques de desarrollo de software que disminuyen el error humano y que ayudan a descubrir las fallas en el sistema antes de que éste se utilice.

2. Tolerancia a fallas: El sistema debe diseñarse de tal forma que las fallas o el

comportamiento inesperado del sistema durante su ejecución se detecten y manejen con el fin de que no ocurra una caída del sistema.

Algunas veces, se señala un tercer enfoque de detección de fallas, pero al parecer éste es consecuencia de la prevención y tolerancia a fallas. Las fallas que se detectan antes de la entrega se evitan al momento de operar el sistema; las que se detectan durante la ejecución son parte de la tolerancia a fallas. La prevención de fallas significa prevenir las fallas del sistema que se entrega a los clientes. Esto se puede hacer de dos formas: utilizando técnicas de programación que disminuyen el número de fallas introducidas al sistema; y utilizando técnica de validación estáticas y dinámicas que ponen al descubierto otras fallas y que permiten que se corrijan antes de que el sistema se entregue. Disminución de fallas Un buen proceso del software tiene el objetivo de desarrollar software libre de fallas. Este software es el que concuerda exactamente con su especificación. Sin embargo esto no necesariamente significa que el software siempre se comporte como los usuarios esperan. Existen errores en la especificación que se reflejan en el software, por lo que el software libre de fallas no está realmente libre de fallas. Disminuir las fallas de software no tiene un impacto importante en el número de caídas por lo que cumplir esta disminución siempre será una meta del desarrollo de sistemas críticos. Existen varios requerimientos para el desarrollo de software libre de fallas:



236

1. Debe existir una especificación precisa del sistema, que defina el sistema a

implementar. 2. La organización que desarrolla el sistema debe tener una cultura de calidad

organizacional, puesto que la calidad es la conductora de los procesos del software. En general, se espera que los programadores escriban programas libres de errores.

3. Se debe utilizar un enfoque para el desarrollo e implementación del software basado

en el ocultamiento y encapsulamiento de la información. Los lenguajes orientados a objetos, como Java, obviamente satisfacen esta condición. Se debe promover el desarrollo de programas orientados a diseñar la legibilidad y la comprensibilidad.

4. Se deben utilizar lenguajes de programación de tipos estrictos, como Java, por

ejemplo. En un lenguaje como éstos, el compilador de lenguaje puede detectar muchos errores de programación.

5. Se debe evitar al máximo posible la utilización de algunas estructuras de

programación que son susceptibles a generar errores. 6. Se debe definir un proceso de desarrollo y capacitar a los desarrolladores en la

aplicación de este proceso. Los administradores de la calidad deben verificar el cumplimiento del proceso.

Desarrollar software libre de fallas es muy difícil. Las organizaciones que desarrollan software, explícitamente o implícitamente aceptan que su uso contendrá fallas residuales. El nivel de fallas depende del tipo de sistema. Los productos empaquetados tienen un alto nivel relativo de fallas, mientras que los sistemas críticos por lo general tienen una densidad de fallas mucho más baja. La razón de la aceptación de las fallas es que si el sistema falla, es más barato pagar las consecuencias de la falla en lugar de descubrir y eliminar dichas fallas antes de entregar el sistema. Ésta es una práctica común entre los vendedores de productos de software para computadoras personales. La decisión de entrar software con fallas no es simplemente una decisión económica. La aceptación social y política de las fallas del sistema también deben tomarse en cuenta. Prevención de errores Las fallas de los programas y muchas de las caídas de los programas, a menudo son consecuencia de los errores humanos. Los programadores comenten errores debido a que pierden la noción de todas las relaciones entre las variables de estado. Escriben instrucciones de programas que conducen a un comportamiento inesperado y a cambios en las variables de estado del sistema. La instrucción goto era una estructura de programación inherentemente susceptible a errores. Hace difícil localizar los cambios de estado. Esta observación condujo al desarrollo de la llamada programación estructurada. En ésta se programa sin utilizar instrucciones goto, los programas se crean sólo utilizando ciclos while e instrucciones if,



como estructuras de control y el diseño se lleva a cabo utilizando un enfoque descendente (top – down). La adopción de la programación estructurada fue una pieza angular importante en el desarrollo de la ingeniería del software debido a que fue el primer paso que se dio a partir del enfoque no disciplinado para el desarrollo del software. Además de las ramificaciones no condicionales (instrucciones goto), existen otras estructuras de los lenguajes de programación y técnicas de programación que son inherentemente susceptibles a errores. Es menos probable introducir fallas en los programas si se reduce la utilización de estas estructuras. Entre ellas podemos mencionar algunas, tal como se describen a continuación: 1. Recursión : La recursión es la situación en la que un procedimiento o método se

llama a sí mismo o llama a otro procedimiento que entonces llama al procedimiento que originalmente hizo la llamada. Su utilización conduce a programas concisos, pero seguir la lógica de los programas recursivos es difícil. Por lo tanto los errores de programación son más difíciles de detectar.

2. Interrupciones: Las interrupciones son un medio para forzar al control a transferir

una sección de código independiente del código que se ejecuta en ese momento. Los peligros de esto son obvios puesto que la interrupción puede provocar que se finalice una operación crítica.

3. Herencia: La herencia en los lenguajes de programación orientados a objetos

permite la reutilización y la descomposición de problemas, pero esto significa que todo el código asociado con un objeto no se encuentra en un solo lugar. Esto hace más difícil de comprender el comportamiento del objeto. Por lo tanto, es más probable que los errores de programación se oculten.

4. Distorsión : Esto ocurre cuando se utilizan diferentes nombres para referirse a la

misma entidad de un programa. Es muy fácil para los lectores de los programas olvidarse de las instrucciones que cambian la entidad cuando se toman en consideración varios nombres.

Algunos estándares para el desarrollo de sistemas de seguridad críticos prohíben completamente el uso de estas estructuras. Sin embargo, por lo general esta posición extrema no es normal. Todas estas estructuras y técnicas son útiles pero deben utilizarse con precaución. Ocultamiento de la información Un principio de seguridad adoptado por las organizaciones militares es el principio “necesitar saber”. Sólo a aquellas personas que necesita saber cierta parte de la información para llevar a cabo sus deberes se les da esa información. Se les niega la información que no es directamente relevante a su trabajo. Al momento de programar, se debe adoptar un principio análogo para controlar el acceso a los datos del sistema. A los componentes del programa se les permite acceder sólo los datos que necesitan para su implementación. Se niega el acceso a otros datos



238

ocultándola por medio de la utilización de las reglas de alcance de los lenguajes de programación. Si se utiliza el ocultamiento, la información que se oculta no puede ser dañada por los componentes del programa que no tienen permitido utilizarla. Procesos del software fiable Para desarrollar software con un número mínimo de fallas es esencial tener un proceso de desarrollo de software que esté bien definido, que sea repetible y que incluya un espectro de actividades de verificación y validación. Un proceso bien definido es un proceso que ha sido estandarizado y documentado. Un proceso repetible es aquel que no cuenta con interpretaciones individuales o de juicio. En su lugar, independientemente de las personas involucradas en el proceso, la organización puede confiar en que el proceso será exitoso. El proceso debe incluir un proceso de prueba comprensivo y bien planeado, así como otras actividades cuyo propósito es la detección de fallas. Las actividades de validación que se llevan a cabo para la disminución de fallas son: 1. Inspecciones de requerimientos : Estas pretenden descubrir problemas en la

especificación del sistema. Una alta proporción de fallas en el software que se entrega proviene de errores en los requerimientos. Si estos se descubren y eliminan de la especificación, entonces esta clase de fallas se reducirá.

2. Administración de requerimientos : La administración de requerimientos, se refiere

a mantener un registro de los cambios de requerimientos y rastrear éstos a lo largo del diseño y la implementación. Muchos errores en los sistemas que se entregan son resultado de no asegurar que un cambio de requerimientos se incluya en el diseño e implementación del sistema.

3. Verificación de modelos : La verificación de modelos comprende el análisis automático de los modelos del sistema por medio de herramientas CASE que verifican que estos modelos tengan consistencia interna y externa. La consistencia interna significa que el modelo mismo es consistente; la consistencia externa significa que varios modelos del sistema son consistentes.

4. Inspecciones de diseño y de código : Las inspecciones de diseño y de código a

menudo se basan en la verificación de listados de fallas comunes y se llevan a cabo para descubrir y eliminar estas fallas antes de que se pruebe el sistema.

5. Análisis estático : El análisis estático es una técnica automática de análisis de

programas en la que el programa se analiza con detalle para descubrir condiciones potencialmente erróneas.

6. Planeación y administración de pruebas : Un conjunto completo de pruebas para

el sistema se diseña y el proceso de pruebas mismo se administra cuidadosamente para asegurar la cobertura completa de pruebas y el rastreo entre las pruebas del sistema y los requerimientos y el diseño del sistema.



La administración efectiva de la configuración es esencial para toda la documentación asociada con un sistema crítico. La administración de la configuración se refiere a mantener un registro de las diferentes versiones de un sistema y sus componentes. Algunas veces los errores en los sistemas resultan de la integración de componentes erróneos o de la versión errónea de un componente. Tolerancia a fallas Un sistema tolerante a fallas es un sistema que puede continuar en operación después de que se hayan manifestado algunas fallas en el sistema mismo. La meta de la tolerancia a fallas es asegurar que las fallas del sistema no conduzcan a una caída del sistema. La tolerancia a fallas es necesaria en situaciones donde la caída del sistema podría provocar un accidente catastrófico o donde una pérdida de la operación del sistema causaría grandes pérdidas económicas. Por ejemplo, las computadoras de un avión deben mantenerse trabajando hasta que el avión aterrice. Se podría pensar que los recursos de tolerancia a fallas no tienen que incluirse en un sistema que se desarrolla utilizando técnicas de disminución de fallas. Si no existieran fallas en el sistema, no habría ninguna oportunidad de que el sistema se caiga. Sin embargo la “ausencia de fallas” no significa la “ausencia de caídas”; sólo significa que los programas están de acuerdo a las especificaciones. La especificación contiene errores u omisiones que se basan en suposiciones incorrectas en entorno del sistema. Por supuesto que no se puede demostrar de manera concluyente que un sistema esté completamente libre de fallas. En sistemas que tienen los más altos requerimientos de fiabilidad y disponibilidad, es necesario permitir explícitamente la tolerancia a fallas. Existen cuatro aspectos de la tolerancia a fallas: 1. Detección de fallas : El sistema debe detectar que ocurrió una combinación

particular de estados y que podría conducir a una falla del sistema. 2. Valoración del daño : Se deben detectar las partes del estado del sistema que se

afectaron por la falla. 3. Recuperación a fallas : El sistema debe restablecer su estado a un estado “seguro”

conocido. Éste se puede alcanzar corrigiendo el estado dañado (recuperación de errores hacia delante) o restableciendo el sistema a un estado “seguro” conocido (recuperación de errores hacia atrás).

4. Reparación de fallas : Esto comprende modificar el sistema de tal forma que la falla

no aparezca de nuevo. En muchos casos, las fallas en el software se manifiestan como estados transitorios. Ellos se deben a una combinación peculiar de entradas del sistema. No es necesario alguna reparación puesto que el procesamiento normal puede continuar inmediatamente después de la recuperación a la falla. Ésta es una diferencia importante entre las fallas de hardware y software.



240

Existen dos enfoque complementarios que se utilizan para implementar la tolerancia a fallas en el software: 1. La programación defensiva : Es un enfoque para desarrollar programas donde el

programador supone que existen fallas no detectadas o inconsistencias en sus programas. El código redundante se incorpora para verificar el estado del sistema después de las modificaciones y asegurar que el cambio de estado sea consistente. Si se detectan inconsistencia, el cambio de estado se regresa o se restablece a un estado correcto conocido.

2. Las arquitecturas tolerantes a fallas : son arquitecturas de sistemas de hardware y

software que proveen ayuda explícita a la tolerancia a fallas. Incluyen redundancia del hardware y del software incorporando un controlador de tolerancia a fallas que detecta los problemas y permite la recuperación a las fallas.

La programación defensiva es una técnica que se puede utilizar en cualquier sistema. Se tienen que agregar verificaciones extra y recursos de recuperación de errores de los programas aun en situaciones donde parece que no ocurren los errores. Manejo de excepciones Cuando ocurre un error de alguna clase o un evento inesperado durante la ejecución de un programa, a esto se le conoce como excepción. Ejemplos de excepciones podrían ser una falla en la energía de un sistema, un intento de acceder a un elemento de datos no existente, etc. Las excepciones pueden ser provocadas por ciertas condiciones de hardware o software. Cuando una excepción ocurre, debe ser manejada por el sistema. Esto se puede hacer dentro del programa mismo o puede implicar la transferencia de control a un mecanismo de manejo de excepciones del sistema. Existen dos problemas con este enfoque: 1. Varias excepciones pueden ocurrir en diferentes puntos del programa y la misma

sección puede ocurrir en diferentes lugares. Esto significa que un gran número de verificaciones explícitas de excepciones se tiene que incluir en el programa. Esto incrementa el tamaño y la complejidad del programa y lo hace más difícil de comprender. Existe una creciente probabilidad de que los programadores cometan errores y que los lectores de programas no detecten estos errores cuando verifican el programa.

2. Cuando una excepción ocurre en una secuencia de funciones anidadas o llamadas a procedimientos, no existe una forma fácil de trasmitirla de una función a otra. Es necesario agregar mucho código para que el programa maneje las excepciones.

Si el lenguaje de programación incluye estructuras que permitan el manejo de excepciones, entonces no se requieren instrucciones condicionales extra para verificar esas excepciones. Los lenguajes C y Java proveen recursos explícitos para el manejos de excepciones.



Los recursos de manejo de excepciones en lenguajes de programación no sólo se utilizan para administrar las fallas del sistema, también se pueden utilizar para manejar condiciones de error que se puedan anticipar, aunque por lo general sólo ocurren raramente. Detección de fallas La primera etapa de la tolerancia a fallas es detectar que una falla (un estado erróneo del sistema) ha ocurrido u ocurrirá a menos que se tome alguna acción de forma inmediata. Normalmente, se lanza una excepción a una sección del código en el programa que puede manejar la falla detectada. Existen dos tipos de detección de fallas: 1. Detección preventiva de fallas : En este caso, el mecanismo de detección de fallas

se inicia antes de que se lleve a cabo un cambio de estado. Si se detecta un estado potencialmente erróneo, entonces no se hace el cambio de estado. Por lo general el sistema de detección de fallas lanza una excepción que indica el tipo de la falla descubierta.

2. Detección retrospectiva de fallas : En este caso el mecanismo de detección de

fallas se inicia después de que el estado del sistema se cambió para verificar si ocurrió una falla. Si se descubre una falla, se señala una excepción y el mecanismo de reparación se utiliza para recuperarse de esa falla.

La detección preventiva de fallas se implementa a menudo definiendo restricciones que apliquen al estado del sistema y verificando estas restricciones cuando se calcula un nuevo estado. La detección preventiva de fallas evita los problemas de reparación de daños puesto que el estado del sistema siempre será válido. Sin embargo, contiene sobrecarga importante en el sentido de que cada operación que modifica el estado debe verificar la restricción antes de que se lleva a cabo el cambio de estado. Valoración del daño La valoración del daño comprende analizar el estado del sistema para medir la amplitud de la corrupción del estado. En muchos casos se puede evitar verificando la ocurrencia de la falla antes de que se lleve a cabo un cambio de estado. Si se detecta una falla, el cambio de estado no es aceptado por lo que no se provoca ningún daño. Sin embargo, la valoración de los daños es necesaria cuando no se puede evitar un compromiso del estado o cuando surge una falla debido a que una secuencia no válida de cambios de estado, individualmente correctos conduzcan a un estado incorrecto del sistema. Recuperación a fallas La recuperación a fallas es el proceso de modificar el espacio de estado del sistema para que los efectos de las fallas se disminuyan. El sistema puede continuar en operación, quizás en alguna forma degradada. La recuperación hacia delante implica



242

tratar de corregir el estado dañado del sistema. La recuperación hacia atrás restablece el estado del sistema a un estado “correcto” conocido. La recuperación de errores hacia atrás es la técnica más simple que restablece el estado a un estado conocido seguro después de que se ha detectado un error. Muchos sistemas de bases de datos incluyen recuperación de errores hacia atrás. Cuando un usuario inicia un cálculo en la base de datos, se inicia una transacción. Los cambios hechos durante esa transacción no se incorporan inmediatamente en la base de datos. La base de datos sólo se actualiza después de que termina la transacción y no se detectan problemas. Si la transacción fracasa, la base de datos no se actualiza. Las transacciones permiten la recuperación de errores puesto que no generan cambios en la base de datos hasta que se hayan completado. Sin embargo no permiten recuperación de los cambios de estado que son válidos pero incorrectos. La verificación de puntos es una técnica que puede recuperarse de esta situación. El estado del sistema se duplica periódicamente. Cuando se descubre un problema, un estado correcto se restablece en una de estas copias. Diseño de sistemas seguros Como regla general, el diseño de software de seguridad crítico se basa en el ocultamiento de la información y la simplicidad del software. Aquellas partes del sistema que son críticas para la seguridad se aíslan de otras partes del sistema. Esto se puede llevar a cabo utilizando abstracciones de datos y control o utilizando separaciones físicas. El software de seguridad crítico se ejecuta en una computadora independiente con vínculos de comunicación mínimos a otras partes del sistema. El software de seguridad crítico debe ser tan simple como sea posible. Las características de los lenguajes, potencialmente susceptibles a errores, se evitan en la medida de lo posible. No están permitidos por los estándares de desarrollo de sistemas de seguridad críticos. El software tolerante a fallas sólo se utiliza en sistemas de seguridad críticos cuando no existe un estado seguro y la seguridad del sistema depende de su disponibilidad. Estas técnicas incrementan la complejidad, y hacen que el software sea más difícil de validar. Mantener el software simple reduce la probabilidad de que se introduzcan errores. También significa una reducción de los costos altos de la validación de la seguridad.

• Solo una cantidad relativamente pequeña del software es segura



Texto 15

Aseguramiento de la calidad a través de la ingenier ía del software Enfoques para el aseguramiento de la calidad El aseguramiento de la calidad (en algún tiempo llamado control de calidad), ha sido desde siempre motivo de interés en las empresas, como debiere de ser para los analistas de sistemas, en el análisis y el diseño de los sistemas de información. Es demasiado riesgoso considerar tanto el análisis como el proceso del diseño, sin el enfoque de aseguramiento de calidad. Los tres enfoques para el aseguramiento de la calidad a través de la ingeniería de software son: En enfoque de aseguramiento de la calidad total (TQA), Diseño del software y documentación y Prueba, mantenimiento y auditoria. Son dos las ideas subyacentes al aseguramiento de la calidad. La primera consiste en que el usuario del sistema de información para la administración o del sistema de apoyo para la toma de decisiones es el elemento más importante para establecer y evaluar la calidad. El segundo reside en que definitivamente es mucho menos costoso corregir problemas cuando éstos se encuentran en sus etapas iniciales que esperar a que el problema se exprese mediante quejas de los usuarios o la aparición de crisis. Todos nos hemos enterado de la gran inversión de horas de trabajo y otros recursos de la empresa, que se requieren para que un sistema tenga éxito. El uso del aseguramiento de la calidad a lo largo del proceso de su desarrollo reduce y ayuda para que el sistema resultante sea el que nece4sitamos y deseamos; y que definitivamente demuestre su valía al incidir sobre ciertos aspectos del desempeño de la empresa. El enfoque del aseguramiento de la calidad El aseguramiento de la calidad total (TQA) es esencial en cada uno de los pasos del desarrollo de los sistemas. El concepto de la calidad se ha ampliado con el transcurso del tiempo, para reflejar un enfoque de la organización, más que exclusivamente de producción. En lugar de concebir la calidad como el control de número de productos defectuosos que se producen, la calidad se considera ahora como un proceso evolutivo hacia la perfección, que se denomina el aseguramiento de la calidad total. El énfasis en la calidad se ha desplazado desde los niveles operativos hacia la alta dirección. Englobando una combinación de factores que reflejan la preocupación corporativa para asegurar la calidad a todos los niveles. Estos factores incluyen al incremento de la disponibilidad de los datos y el interés general hacia el incremento de la productividad del personal de la oficina, entre otros. La información relativa a la evaluación del desempeño dentro de los negocios se ha vuelto cada vez más común entre el personal de todos los niveles. La aceptación de la “administración por objetivos” acompañado de las técnicas de administración



244

participativa, han implicado que los empleados se preocupen por sí mismos de su desempeño, así como de su evaluación. Esto es importante en relación con el aseguramiento de la calidad total, ya que este concepto funciona sólo si cada individuo está involucrado en un trabajo de calidad. Finalmente, se considera el incremento de la atención en la productividad del personal administrativo, para auxiliar a que acepten la filosofía del aseguramiento de la calidad total. Cuando la productividad en las líneas de producción mejoró en forma marcada, la demanda por una mayor productividad de los administrativos también se incrementó. La presión para incrementar la productividad administrativa se ha apoyado con el desarrollo de nuevas técnicas para medir el trabajo de la dirección. Un movimiento en pro de la mayor responsabilidad de los directivos de alto rango también ha ocasionado el deseo de mejorar la productividad administrativa. Los analistas de sistemas deben estar al tanto de los factores que conducen el interés hacia el aseguramiento de la calidad total. Es importante percatarse de que el incremento del compromiso de las empresas hacia el TQA se apega extraordinariamente bien a los objetivos globales del diseño y del análisis de sistemas. Responsabilidad para el aseguramiento de la calidad total La lección más sorprendente que se obtiene del aseguramiento de la calidad total en situaciones de producción reside en que el cliente es el factor individual más importante en el establecimiento y la evaluación de la calidad de los productos. Tal desarrollo se presenta de manera paralela en las investigaciones realizadas de los sistemas de información para la administración y los sistemas de apoyo a la toma de decisiones, los cuales enfatizan la importancia decisiva del usuario par asegurar una implementación del sistema con éxito. Es un hecho que una gran proporción de la responsabilidad de la calidad del sistema de información descansa en los usuarios y en los administradores de los sistemas. Se deben cubrir dos aspectos para obtener un aseguramiento de la calidad total de los proyectos de sistemas. Primero, debe existir el soporte total de la dirección de la organización, los esfuerzos superficiales no tienen sentido. Esto significa que la directiva establezca el contexto, tal que considere seriamente que los resultados de su trabajo se afecta por la calidad del sistema de información y de la información misma. El apoyo de la organización en la calidad de los sistemas de información para la administración puede lograrse a través de la asignación dentro del horario de trabajo, actividades relacionadas con círculos de calidad, orientados a buscar la manera de mejorar los sistemas de información, así como para implantar mejoras. El aseguramiento de calidad total de los sistemas de información para la administración y los sistemas de apoyo a la toma de decisiones, puede centralizarse a través de un centro de información para la organización. El centro puede servir como depositario de los lineamientos de calidad establecidos por los círculos internos de calidad del sistemas de información para la administración o propuestos en organizaciones competidoras.



A través de este trabajo, deben desarrollarse los lineamientos para establecer estándares de calidad de tales sistemas de información, los que deben actualizarse periódicamente para un nuevo sistema o las modificaciones relevantes, los cuales serán propuestos de manera formal, por el grupo de análisis de sistemas. No hay problema si los usuarios poseen poca experiencia en lineamientos de calidad o carecen de conocimientos sobre los sistemas computarizados. Se espera que contribuyan con sus conocimientos sobre la operatoria de su departamento y lo que consideran una calidad aceptable para la entrada, procesamiento y salida.

• Los estándares de calidad de los departamentos deben comunicarse a través de una retroalimentación hacia el grupo de análisis de sistemas.

• Involucrar a los usuarios en el establecimiento de estándares de calidad para el

sistema, auxiliará al analista a evitar errores costosos o que comiencen desarrollos de sistemas innecesarios.

Verificación estructurada Una de las acciones más sólido que puede tomar el grupo de análisis de sistemas es la realización de inspecciones estructuradas de rutina. La verificación estructurada es una manera de introducirse en la programación y el desarrollo global, de resaltar los problemas del sistema y permitir que el programador o el analista responsable de una sección realiza los cambios correspondientes. La inspección estructurada involucra por lo menos a cuatro personas, incluyendo a la persona responsable de la sección del sistema o subsistemas que se revisa, un coordinador de la verificación, un programador o analista y una persona que tome notas de las sugerencias. Cada persona que participa en una verificación o supervisión de seguimiento, tiene que realizar un papel especial. El coordinador se encuentra ahí para supervisar que los demás se adhieran al papel asignado y asegurar que se realice cualquier actividad programada. Las inspecciones estructuradas pueden realizarse cada vez que se concluyan una porción de codificación, un subsistema o un sistema. Las verificaciones estructuradas se apegan bien a un programa de aseguramiento de la calidad total, cuando se realizan durante el ciclo de desarrollo de sistema. Se deben realizar las verificaciones estructuradas, como una manera para obtener valiosa retroalimentación desde una perspectiva, de la cual el analista carece en primera instancia.



246

Diseño y desarrollo de sistemas A continuación se definirá los diseños de sistemas ascendentes y los descendentes, así como el enfoque modular de la programación, estableciendo las ventajas y preocupaciones que deben observarse cuando se empleen. Diseño ascendente (bottom – up) El diseño ascendente se refiere a la identificación de aquellos procesos que necesitan computarizarse conforme vayan apareciendo, su análisis como sistemas y su codificación o bien la adquisición de paquetes de software para satisfacer el problema inmediato. Los problemas que requieren de la computarización, con mayor frecuencia se encuentran en los niveles inferiores de la organización. Este enfoque se denomina ascendente, refiriéndose a que la computarización se implanta desde el nivel mas bajo. Cuando la programación se realiza internamente y haciendo uso de un enfoque ascendente, es difícil llegar a integrar los subsistemas, a grado tal de que el desempeño global sea fluido. Aunque cada subsistema parece ofrecer lo que se requiere, cuando se contempla al sistema como una entidad global, adolece de ciertas limitaciones por haber tomado un enfoque ascendente. Uno de ellos es la duplicación de esfuerzos tanto para acceder al software o para la introducción de datos. Otro es que se introducen al sistema muchos datos carentes de valor, y por último, y quizás el más serio inconveniente del enfoque ascendente, es que los objetivos globales de la organización no fueron considerados y en consecuencia, no se satisfacen. Diseño descendente El diseño descendente obliga a que los analistas de sistemas se enteren primero de los objetivos globales de organización, así como el establecimiento de la mejor manera de satisfacerlos dentro de un sistema integral. Luego el analista se dirigirá a dividir tal sistema en sus subsistemas y requerimientos. Cuando el analista de sistemas emplea un enfoque descendente, está empleando las interrelaciones e interdependencias de los subsistemas, para apegarse lo mejor posible a las necesidades existentes en la organización. El enfoque descendente da la importancia debida a las interfaces requeridas por el sistema y los subsistemas; los cuales no existen en el enfoque ascendente. Dentro de las ventajas de la utilización de un enfoque descendente en el diseño de sistemas se encuentra el evitar el caos originado, al tratar de diseñar el sistema en un solo paso. La planeación y la implementación de los sistemas de información es increíblemente compleja. El tratar de integrar a todos los subsistemas y que todos ellos funcionen al unísono, es buscar el fracaso.



La segunda ventaja de este enfoque, es la posibilidad de contar con grupos de analistas de sistemas trabajando por separado pero simultáneamente en subsistemas independientes, pero necesarios. Esto puede ahorrar una gran cantidad de tiempo. El trabajo de grupos integrados para el diseño de subsistemas es particularmente conveniente para la búsqueda del aseguramiento de la calidad total. La tercera ventaja es que evita el gran problema asociado con un sistema ascendente, es decir previene que el analista de sistemas se adentre en los detalles y dé la pauta para que se pierdan los objetivos centrales del sistema. Existen ciertos inconvenientes en el diseño descendente, que el analista debe mantener en mente. Primero es que existe el riesgo de que el sistema se divida en subsistemas “incorrectos”. Se debe prestar atención a la necesidad de la superposición y la distribución de los recursos, de tal forma que una participación de subsistemas tenga sentido en el esquema global del sistema. Es importante que cada subsistema se integre de manera adecuada al sistema. El segundo inconveniente es que una vez que se realizan las divisiones en subsistemas, sus interfaces pueden descuidarse o simplemente ignorarse. La responsabilidad para lograr la adecuada interrelación debe quedar bien detallada. Una tercera precaución que debe acompañar al uso del diseño descendente, es que los subsistemas deberán reintegrarse eventualmente. Los mecanismos para la reintegración deben plantearse desde un principio. Uno programa de aseguramiento de la calidad total y la toma en el diseño de un enfoque descendente pueden ir de la mano. El enfoque descendente proporciona al grupo de sistemas una clara división establecida de los usuarios en fuerzas de tareas para los subsistemas. De esta manera se tiene una estructura necesaria para el aseguramiento de la calidad. Desarrollo modular Una vez que se ha tomado el enfoque del diseño descendente, también será útil durante la programación un enfoque de concepción modular. Ésto significa descomponer la programación en fracciones lógicas y manejables. Este tipo de programación se apega bien al diseño descendente porque enfatiza las interfaces entre los módulos. Cada módulo debe ser funcionalmente cohesivo, de tal manera que satisfaga sólo una función El diseño de programas modulares tiene tres ventajas básicas. Primero, los módulos son más fáciles de escribir y de revisar, ya que están virtualmente autocontenidos. La detención de un error dentro de un módulo es menos complicada, ya que los problemas asociados a un módulo no llegarán a trascender a los otros. Una segunda ventaja del diseño modular, es que el mantenimiento de los módulos es más fácil. Las modificaciones pueden limitarse a unos cuantos módulos y no al programa completo.



248

Una tercera ventaja es que la problemática de los módulos es más fácil de entender, ya que son sistemas autocontenidos. Eso significa que un lector entenderá la función de un módulo específico, con sólo ver el listado de código. Algunos lineamientos para la programación modular incluyen: 1. Mantener cada módulo de un tamaño manejable. (de manera ideal incluyendo sólo

una función. 2. Prestar atención particular a las interfaces críticas (esto es, a los datos y a las

variables de control que pasan entre los módulos) 3. Minimizar el número de módulos que el usuario necesite modificar cuando haga

cambios. 4. Mantener las relaciones jerárquicas establecidas en las etapas de descenso. Ingeniería de software y documentación La planeación y el control son elementos esenciales de cualquier sistema que aspire a tener éxito. Al desarrollar software para los sistemas, la planeación descendente toma un lugar en el diseño, antes de que se inicie la programación. Necesitamos técnicas que auxilien en la definición de los objetivos de los programas, de tal manera que éstos lleguen a concluirse. También necesitamos diseñar técnicas que nos auxilien a distribuir el esfuerzo de programación e módulos manejables. No es suficiente tratar de tener éxito únicamente con lo realizado en las etapas de la planeación. Una vez que los programas se concluyen, deben recibir mantenimiento y, los esfuerzos de mantenimiento superan a los del diseño general y de la programación. Dado que la mayoría de los sistemas no se crean para ser efímeros, se necesita darles mantenimiento. El esfuerzo del aseguramiento de la calidad total, requiere que los programas se documenten de manera adecuada. El software y los procedimientos deben quedar documentados de manera tal que sean codificados en un formato de fácil acceso. El acceso a los procedimientos, es necesario tanto para el personal de ingreso reciente como para el que conoce el sistema; y asimismo para recordarles a aquellos que lo utilizan de manera esporádica. La documentación permite a los usuarios, programadores y analistas “ver” el sistema, su software y los procedimientos, sin necesidad de una interacción directa. La rotación del personal de los servicios de información tradicionalmente ha sido alto, en comparación con el de otros departamentos, de tal forma que son pocas las oportunidades de que la gente que concibió e instaló el sistema original sea la misma que le dará el mantenimiento. Una documentación bien estructurada reducirá el número requerido de horas para que se conozca el sistema, antes de poder darle mantenimiento.



Existen numerosas razones por las cuales los sistemas y los programas quedan pobremente documentados o, simplemente sin documentar; algunos de los problemas residen en los sistemas y los programas en sí, mientras que otros se asocian a los analistas de sistemas y a los programadores. Algunos analistas no documentan los sistemas, porque no les agrada hacerlo o consideran que no es un trabajo real. Muchos analistas son reticentes a documentar sistemas que no fueron desarrollados por ellos mismos, tal vez por prevenir aquellos comentarios que emerjan por incluir material incorrecto acerca de sistemas de otros. Manuales de procedimientos Los manuales de procedimientos son documentos de carácter organizacional muy comunes, con los cuales la mayoría de las personas han tenido contacto. Los manuales se usan para comunicarse con quienes usarán los sistemas. Pueden contener comentarios introductorios; pasos para realizar diferentes transacciones; instrucciones de cómo resolver problemas de operación y qué hacer si algo no funciona. Es muy conveniente redactar los manuales con un enfoque directo y estandarizado. Es importante que los manuales se consideren como documentos actuales, más que históricos; para que los manuales sean útiles deben actualizarse. Lo manuales no deben tener textos referentes a los beneficios de la aplicación, del contenido del manual o de lo que documenta el manual. Debemos recordar que el manual no es un instrumento de promoción. Un buen manual se utiliza continuamente como referencia. Y como tal, necesita organizarse de una manera lógica. Además de la organización del manual y de su claridad, debe dedicarse especial atención al tipo de gente a quien va dirigido el mismo. Existen una gran cantidad de técnicas de diseño y documentación, donde el analista de sistemas se enfrenta a una difícil decisión cuando tiene que elegir el método que va a adoptar. A continuación se detallan una serie de lineamientos que ayudan al analista en la elección de una técnica adecuada. El analista de sistemas debe elegir una técnica que: 1. Sea compatible con la documentación existente. 2. Sea comprensible dentro de la organización. 3. Le permita regresar a trabajar en el sistema, una vez que se haya retirado por un

buen período de tiempo. 4. Sea adecuada para el trabajo del sistema en el cual trabaja. 5. Le permita un enfoque de diseño estructurado, si se considera que esto sea más

relevante que los otros factores.



250

6. Permita una fácil modificación. Prueba, mantenimiento y auditoria El proceso de prueba Debe haber una evaluación de todos los elementos del sistema, ya sean programas de aplicación recién escritos o sus modificaciones, así como los nuevos manuales de procedimientos, el nuevo hardware o interfaces del sistema. No será suficiente una evaluación aleatoria de prueba y error. La evaluación se debe se debe llevar a todo lo largo del desarrollo del sistema (no sólo al final); cumple con el propósito de identificar aquellos problemas desconocidos; no demostrar la perfección de un programa, de los manuales o del equipo. Aunque la evaluación es tediosa, conforma una serie esencial de pasos que ayudan a garantizar la calidad del sistema eventual. Es menos grava evaluar de antemano, que tener un sistema pobremente evaluado y que falle una vez instalado. La evaluación se lleva a cabo conforme progresa el trabajo en los subsistemas o módulos del programa. La evaluación se realiza a diferentes niveles y a varios intervalos, aun antes de que el sistema entre en operación, todos los programas deben examinarse en cuanto a su diseño con datos de prueba y verificar si los módulos se enlazan entre sí, tal como fue planeado. También debe probarse el sistema trabajando como una unidad. Esto incluye la evaluación para la evaluación para las interfaces entre los subsistemas, la operación adecuada de la salida, la utilidad y la comprensión de la documentación del sistema y de la salida. La evaluación de hardware comúnmente se proporciona como servicio por parte de los vendedores de equipo, quienes harán sus propias pruebas, cuando se instale el equipo. Prueba del programa con datos de prueba Una buena parte de la responsabilidad de la evaluación del programa recae en el autor original de cada programa, y el analista de sistemas sólo sirva como un orientador y coordinador de la evaluación del programa. Por esto, el analista trabaja para asegurar que los programadores implanten las técnicas de evaluación adecuadas y será poco probable que de manera personal participe en este nivel de evaluación. En esta etapa, los programadores deben revisar primero sus programas para verificar la manera en la que trabajará el sistema. Con una evaluación de escritorio, el programador sigue en papel paso a paso el programa para verificar si las rutinas trabajan como se planeó. Luego, los programadores deben desarrollar datos de prueba, tanto válido como inválidos. Estos se presentan después para ver si las rutinas básicas trabajan y también para generar errores. Si la salida de la rutina principal es satisfactoria, pueden agregarse datos de prueba para verificar otras rutinas. Los datos de prueba deben



verificar los valores máximos y mínimos posibles, así como todas las variaciones que sean posibles en formato y el los códigos. La salida de datos de prueba del archivo debe verificarse con cuidado. Nunca debe suponerse que los datos archivados son correctos, sólo porque el archivo fue creado y pudimos acceder a él. Prueba de enlace con datos de prueba Cuando los programas pasan de la verificación de escritorio a la verificación con datos de prueba, deben verificar también la operación de enlace, que se refiere también como prueba de enlace. Las evaluaciones de enlace verifican que los programas sean interdependientes y funcionen integradamente tal como fue planeado. Para la prueba de enlace se utiliza una pequeña cantidad de datos de prueba, generalmente desarrollados por el analista de sistemas para examinar las especificaciones del sistema, así como del programa. El examen de todas las combinaciones puede implicar varios pasos a través del sistema. Es sumamente difícil darle seguimiento a un problema, si se intenta evaluar todo en un solo paso. El analista crea datos de prueba especiales para cubrir todo un espectro de situaciones de proceso durante el examen del enlace. Primero se procesan datos de prueba típicos para ver si el sistema puede manejar transacciones normales; aquellas que cubran el mayor volumen de trabajo si el sistema trabajará con transacciones normales. Luego entonces se agregarán variaciones, las cuales incluirán datos inválidos para asegurar que el sistema puede detectar los errores de manera adecuada. Prueba del sistema completo con datos de prueba Debe examinarse el sistema como una entidad completa, cuando se concluyen las pruebas de enlace de manera satisfactoria. Es esta etapa, los operadores y los usuarios finales se involucran activamente en tal operación. Debe utilizarse un paquete de datos creado para tal fin por el grupo de análisis de sistemas con el propósito específico de evaluar los objetivos del sistema. Existe una serie de factores a considerar cuando se evalúan los sistemas con datos de prueba: 1. Verificar si los operadores cuentan con una documentación adecuada en los

manuales de procedimiento para asegurar una operación correcta y eficiente. 2. Verificar si los manuales de procedimientos son suficientemente claros como para

comunicar la manera de preparar los datos de entrada. 3. Asegurarse si el flujo de carga que debe tolerar el nuevo sistema o la modificación

del sistema “fluye de hecho”. 4. Determinar si la salida es correcta; esto es, que todos los usuarios comprendan en

forma general cómo llegará a ser la salida.



252

Es importante programar un tiempo adecuado para la evaluación del sistema. Desafortunadamente, con frecuencia es un paso que se llega a obviar, si la instalación del sistema se encuentra fuera de programa, contra una fecha límite. La evaluación del sistema incluye la confirmación de todos los estándares de calidad para el desempeño del sistema, tal y como fueron establecidos cuando se definieron las especificaciones iniciales del sistema. Cada uno de los involucrados deberá una vez más, estar de acuerdo con la forma de determinar si el sistema realiza lo que supuestamente debería de hacer. Esto incluye la magnitud del error, los tiempos de proceso, la facilidad de uso, etc. Prueba de sistema completo con datos reales Cuando la prueba de los sistemas con datos de prueba llega a ser satisfactoria, es una buena idea tratar que el sistema interactúe con lo que se llama “datos reales”, los cuales son datos que han sido procesados con éxito por el sistema existente. Esto permite una comparación precisa con lo que es una salida procesada correctamente, y una buena idea de cómo deben manejarse los datos reales. Este es u periodo importante para evaluar la manera que los usuarios finales y los operadores interactúan con el sistema. No es suficiente entrevistar a los usuarios acerca e cómo interaccionarán con el sistema; debe observarlo de manera directa. Los elementos a observar son: 1. La facilidad de aprendizaje del sistema 2. El ajuste de factores ergonómicos 3. Las reacciones de los usuarios a la retroalimentación del sistema. (incluyendo lo que

ocurra cuando se presente en pantalla un mensaje de error). Los manuales de procedimientos necesitan evaluarse. Aunque el staff de apoyo revise los manuales y el grupo de análisis de sistemas verifique su precisión técnica, la última manera de evaluarlos es que los mismos usuarios y operadores los consulten con datos reales durante la evaluación completa del sistema. Debemos recordar que los manuales necesitan organizarse de diferentes maneras para los usuarios que con distintos enfoque interaccionan con el sistema. Prácticas de mantenimiento Un analista de sistemas debe tener entre sus objetivos la instalación y modificación de sistemas que alcancen una vida útil razonable. Querrá crear sistemas cuyo diseño sea comprensible y duradero que sirvan para las necesidades actuales y las proyectadas durante varios años. Cuanto mejor sea el diseño del sistema, más fácil será darle mantenimiento y se requerirá menos dinero de la empresa para su mantenimiento. La reducción de los costos de mantenimiento es una preocupación importante de las empresas, ya que el mantenimiento del software, por sí sólo, puede devorar hasta el 50% del presupuesto total de procesamiento de datos. Desde una perspectiva de sistemas, tiene sentido detectar y corregir los errores de diseño en el software, en su



fase inicial, cuando aún es menos costoso dejar que los errores permanezcan sin identificarse hasta realizar el mantenimiento. El mantenimiento se realiza generalmente para mejorar un software existente, mas que para responder a una falla de sistema. A medida que cambian los requerimientos de los usuarios, el software y la documentación también deberán cambiar como parte del trabajo de mantenimiento. El mantenimiento también se realiza para actualizar el software en respuesta a los cambios de la organización. Este trabajo no es tan sustancial como la ampliación del software, pero debe realizarse. Auditoria La auditoria es otra forma de asegurar la calidad de la información que contiene el sistema. Con una definición amplia, la auditoria implica contar con un experto que no se encuentre involucrado en la puesta en operación y en el uso del sistema, para examinar la información, con el fin de establecer su relevancia. Si se encontrara o no información relevante, tal hallazgo deberá comunicarse a otros con el propósito de mejorar la relevancia de la información que les proporciona el sistema. Generalmente existen para los sistemas de información, dos tipos de auditorias: interna y externa. El que ambas se necesiten para el sistema que se diseña dependerá del tipo de sistema. Las auditorias internas operan para la misma organización propietaria del sistema de información, mientras que en las auditorias externas (también llamadas “independientes”) se contratan auditores externos. Generalmente, se invita a los auditores externos cuando el sistema de información influye en los estados financieros del negocio. Los auditores externos inspeccionan el sistema para asegurar la confiabilidad sobre los estados financieros que se producen. También deben traerse cuando algo fuera de lo ordinario está ocurriendo, que llegara a involucrar a los empleados de la compañía, tal como la sospecha de fraude en materia de computación o pagos. Los auditores internos estudian los controles utilizados por el sistema informático para asegurar que éste realiza lo que supuestamente debe de hacer. También examinan la operación de los controles de seguridad. Aunque trabajan dentro de la misma organización, los auditores internos no reportan a la gente responsable del sistema que auditan. El trabajo de los auditores internos, con frecuencia es de mayor profundidad que el de los auditores externos.



254



Texto 16

Pruebas del software Cuando hablamos de pruebas de las unidades de programas individuales, estamos hablando de las pruebas que se realizan en funciones u objetos en particular. Después éstas se integraban en subsistemas y sistemas y se probaban las interacciones de estas unidades. Finalmente, después de completar el sistema, los clientes llevaban a cabo una serie de pruebas de aceptación para verificar que el sistema se desempeñaba conforme a lo especificado. La etapa de pruebas de componentes comprende las pruebas de funcionamiento de los componentes claramente identificables. Estos son funcionamiento o grupos de métodos agrupados en módulos o en objetos. Durante las pruebas de integración estos componentes se integran para formar subsistemas o el sistema completo. En esta etapa, las pruebas se enfocan en las interacciones entre los componentes y en la funcionalidad y el desempeño del sistema como un todo. Sin embargo, los defectos en los componentes que no han sido tomados en cuenta durante las pruebas iniciales se ponen al descubierto durante las pruebas de integración. Como parte del proceso de planeación, los administradores tienen que tomar decisiones sobre quién es responsable de las diferentes etapas de prueba. Para muchos sistemas, los programadores tienen la responsabilidad de probar su propio código (módulos u objetos). Una vez que lo hacen, el trabajo se pasa a un equipo de integración que integra los módulos de los diferentes desarrolladores, construye el software y prueba el sistema en conjunto. Sin embargo, para sistemas críticos, se utiliza un proceso más formal donde probadores independientes son responsables de todas las etapas del proceso de prueba. Las pruebas se desarrollan de forma independiente y se lleva a cabo un registro detallado. Cuando se prueban sistemas críticos, una especificación detallada de cada componente de software es utilizada por el equipo independiente para generar las pruebas del sistema. En muchos casos llevar a cabo las pruebas es un proceso intuitivo puesto que no existe tiempo para redactar las especificaciones detalladas de cada parte de un sistema de software. En su lugar, las interfaces de los componentes principales del sistema se especifican y los programadores individuales y los equipos de programación toman la responsabilidad de diseñar, desarrollar y probar estos componentes. Las pruebas por lo general se basan en una comprensión intuitiva de cómo operan estos componentes. Sin embargo, las pruebas de integración se basan en una especificación escrita del sistema. Ésta puede ser una especificación detallada de los requerimientos del sistema, o puede ser una especificación orientada al usuario de las características a implementar en el sistema. Un equipo aparte es responsable de las pruebas de integración.



256

En la figura a continuación se muestra una visión más abstracta de este proceso de pruebas.

Fases de las pruebas Pruebas de defectos La meta de las pruebas de defectos es exponer los defectos latentes en un sistema de software antes de entregar el sistema. Esto contrasta con las pruebas de validación que pretenden demostrar que un sistema cumple su especificación. Las pruebas de validación requieren que el sistema se desempeñe correctamente utilizando casos de prueba dados. Una prueba de defectos exitosa es una prueba que provoca que el sistema se desempeñe incorrectamente y así exponer un defecto. Esto enfatiza un hecho importante acerca de las pruebas. Demuestra la presencia, no la ausencia, de fallas en el programa. Los casos de prueba son especificaciones de las entradas a la prueba y de la salida esperada del sistema más una declaración de lo que se prueba. Los datos de prueba son las entradas seleccionadas para probar el sistema. Dichos datos algunas veces se generan de forma automática. La generación de casos de prueba automáticos es imposible que la salida de la prueba no se puede predecir. Las pruebas exhaustivas, donde se prueba cada posible secuencia de ejecuciones del programa, no son prácticas. Por lo tanto, llevar a cabo las pruebas se basa en un subconjunto de posibles casos de prueba. Las organizaciones deben desarrollar políticas para elegir este subconjunto en lugar de dejar esto al equipo de desarrollo. Estas políticas se podrían basar en políticas generales de prueba, como una política donde todas las instrucciones del programa se ejecutan al menos una vez. De forma alternativa, las políticas de prueba se basan en la experiencia de la utilización del sistema y se enfocan en las pruebas de las características del sistema operacional. Ejemplo de estas políticas son las que se detallan a continuación: 1. Se deben probar todas las funciones del sistema que se accedan a través de

menús. 2. Se deben probar las combinaciones de funciones, que se acceden a través del

mismo menú.

Pruebas del componente Pruebas de integración

Desarrollador de software Equipo de pruebas independiente



3. Cuando el usuario introduce la entrada, todas las funciones deben probarse tanto con las entradas correctas como incorrectas.

A partir de la experiencia con los principales productos de software, a menudo se han utilizado lineamientos similares durante las pruebas de productos. Las combinaciones no comunes de funcionalidad pueden conducir a errores pero las funciones más utilizadas por lo general funcionan de manera correcta. Pruebas de caja negra Las pruebas funcionales o de caja negra son un enfoque para llevar a cabo pruebas donde éstas se derivan de la especificación del programa o componente. El sistema es una “caja negra” cuyo comportamiento sólo se puede determinar estudiando las entradas y salidas relacionadas. Otro nombre para éstas es pruebas funcionales, debido a que al testeador sólo le interesa la funcionalidad no la implementación del software.

El enfoque de caja negra se aplica de igual forma a los sistemas que están organizados como funciones o como objetos. El testeador introduce las entradas en los componentes del sistema y examina las salidas correspondientes. Si las salidas no son las previstas, entonces la prueba ha detectado exitosamente un problema con el software. El problema clave para el probador de defectos es seleccionar las entradas que se harán al sistema. En muchos casos la selección de estos casos de prueba se basan en la experiencia previa de los especialistas de pruebas. Los especialistas utilizan el

Sistema

Resultado de las pruebas

Entrada de datos de prueba

Esquema de prueba de caja negra



258

conocimiento previo para identificar los casos de prueba que probablemente revelen los defectos. Pruebas de integración Una vez que se probaron los componentes individuales del programa, deben integrarse para crear un sistema parcial, o completo. Este proceso de integración comprende la construcción del sistema, y probar el sistema resultante con respecto a los problemas que surjan de las interacciones e los componentes. Las pruebas de integración se desarrollan a partir de la especificación del sistema y dan inicio tan pronto como estén disponibles las versiones utilizables de algunos componentes del sistema. La principal dificultad que surge en las pruebas de integración es localizar los errores que se descubren durante el proceso. Existen interacciones complejas entre los componentes del sistema y cuando se descubre una salida anómala es difícil encontrar la fuente del error. Para hacer más fácil la localización de errores siempre se utiliza un enfoque incremental para la integración y prueba del sistema. De forma inicial, se debe integrar una configuración mínima del sistema y probar dicho sistema. Luego se agregan componentes a esta configuración mínima y se prueba después de que se agrega cada incremento. Pruebas descendentes y ascendentes Las estrategias de pruebas descendentes y ascendentes, reflejan diferentes enfoque de la integración del sistema. En la integración descendente, los componentes de los niveles altos de un sistema se integran y prueban antes de que se complete su diseño e implementación. En la integración ascendente, los componentes de los niveles bajos se integran y prueban antes de que se desarrollen los componentes de los niveles altos. Las pruebas descendentes son una parte integral del proceso de desarrollo descendente, en el cuál este último inicia con los componentes de los niveles altos y desciende en la jerarquía de los componentes. Después que se programa y prueba el primer componente de nivel alto, se implementan y prueban sus subcomponentes de la misma forma. Este proceso continúa hasta que los componentes de nivel bajo se implementen. De esta forma queda completamente probado el sistema completo. En contraste las pruebas ascendentes comprenden integrar y probar los módulos en los niveles bajos de la jerarquía, y después asciende por la jerarquía de los módulos hasta que el módulo final se prueba. Este enfoque no requiere que el diseño del sistema esté completo por lo que se puede comenzar en una etapa inicial del proceso de desarrollo. Se emplea donde el sistema reutiliza y modifica componentes de otros sistemas. Las pruebas de integración descendentes y ascendentes se comparan bajo cuatro puntos:



1. Validación arquitectónica : Las pruebas descendentes son susceptibles a descubrir errores en la arquitectura del sistema y en el diseño de alto nivel en las etapas iniciales del proceso de desarrollo. Puesto que éstas son por lo general errores estructurales, las primeras detecciones implican que se pueden corregir sin costos extra. En las pruebas ascendentes, el diseño de alto nivel no se valida hasta etapas posteriores del proceso.

2. Demostración del sistema: En el desarrollo descendente se dispone de un sistema

funcional limitado en las primeras etapas de desarrollo. Esto es una importante ayuda psicológica para aquellos que están involucrados en el desarrollo del sistema. Demuestra la factibilidad del sistema al administrador. La validación puede comenzar al inicio del proceso de prueba puesto que los usuarios pueden disponer de un sistema que tiene cierta funcionalidad. Si el sistema se construye a partir de componentes reutilizables, también es posible producir alguna clase de demostración utilizando un enfoque ascendente.

3. Implementación de las pruebas : Las pruebas descendentes estrictas son difíciles

de implementar debido a que se deben producir versiones simplificadas de los componentes requeridos del programa, que simulan los niveles inferiores de sistema. Cuando se realizan pruebas ascendentes, tienen que escribirse controladores de prueba para probar los componentes de bajo nivel, estos controladores de prueba simulan el entorno de los componentes y llaman al componente a probar.

4. Observación de la prueba : Tanto las pruebas ascendentes como las descendentes

pueden tener problemas con la observación de la prueba. En muchos sistemas, los niveles más altos del sistema que se implementan primero en un proceso descendente no generan salidas; sin embargo para probar estos niveles, se les debe forzar a hacerlo. El probador debe crear un entorno artificial para generar los resultados de la prueba. Para las pruebas ascendentes, también es necesario crear un entorno artificial (y los controladores de prueba) con el fin de que se pueda observar la ejecución de los componentes de los niveles inferiores.

En realidad, por lo general los sistemas se desarrollan y prueban utilizando una mezcla de los enfoques ascendente y descendente. Los diferentes tiempos de desarrollo de las diversas partes del sistema implican que el equipo de integración y prueba deben trabajar con cualquiera de los componentes disponibles. Por lo tanto deben desarrollarse una serie de componentes y controladores de prueba durante la integración del proceso de prueba. Pruebas de interfaces Las pruebas de interfaces toman lugar cuando los módulos o subsistemas se integran para crear sistemas más grandes. Cada módulo o subsistema tiene una interfaz definida que es llamada por otros componentes del programa. El objetivo de las pruebas de interfaces es detectar las fallas que se introdujeron en el sistema debido a los errores de las interfaces o suposiciones no válidas acerca de las interfaces.



260

Esta forma de llevar a cabo las pruebas es muy importante para el desarrollo orientado a objetos, particularmente cuando se reutilizan objetos y clases de objetos. Los objetos están esencialmente definidos por sus interfaces y se reutilizan en combinación con varios objetos en diferentes sistemas. Los errores de interfaces no se pueden detectar probando los objetos individuales. Los errores son resultado de la interacción entre los objetos más que del comportamiento aislado de un solo objeto. Existen diferentes tipos de interfaces entre los componentes del programa y, en consecuencia pueden ocurrir diferentes tipos de errores de interfaces, tal como se describen a continuación: 1. Interfaces de parámetros : Éstas son interfaces donde la referencia a datos o a

funciones se pasan de un componente a otro 2. Interfaces de memoria compartida : Éstas son interfaces donde un bloque de

memoria se comparte entre los subsistemas. Los datos son colocados en la memoria por un subsistema y son recuperados por otro subsistema.

3. Interfaces procedurales: Éstas son interfaces donde un subsistema encapsula un

conjunto de procedimientos que pueden ser llamados por otros subsistemas. 4. Interfaces que pasan mensajes: Éstas son interfaces donde un subsistema solicita

un servicio a otro subsistema pasándose un mensaje. El mensaje que se devuelve incluye los resultados de la ejecución del servicio. Algunos sistemas orientados a objetos tienen esta forma de interfaz, así como los sistemas cliente – servidor.

Los errores de interfaces son una de las formas más comunes de errores en sistemas complejos. Estos errores se dividen en tres clases: 1. Abuso de interfaces : Un componente llama a otro componente y comete un error

en la utilización de su interfaz. Este tipo de errores es particularmente común con interfaces de parámetros, donde los parámetros son de tipo erróneo, se pasan en orden incorrecto o se pasa un número erróneo de parámetros.

2. Malentendido de interfaces : Un componente malentiende la especificación de la

interfaz del componente al que llama y hace suposiciones acerca de éste. El componente invocado no se comporta como se esperaba y esto provoca un comportamiento no esperado en el componente invocador. Por ejemplo una rutina de búsqueda es llamado por un arreglo no ordenado que se desea buscar, en ese caso la búsqueda fallaría.

3. Errores de tiempo : Éstos ocurren en sistemas de tiempo real que utilizan memoria

compartida o una interfaz que pasa mensajes. El productor de datos y el consumidor de datos operan a diferentes velocidades. A menos que se tenga cuidado particular en el diseño de la interfaz, el consumidor puede acceder a la información no



actualizada debido a que el productor de la información no ha actualizado la información de la interfaz compartida.

Probar los defectos de la interfaz es difícil debido que algunas fallas de las interfaces sólo se manifiestan bajo condiciones inusuales. Un problema adicional surge debido a las interacciones entre las fallas en los diversos módulos u objetos. Las fallas en un objeto solo se detectan cuando algún otro objeto se comporta en forma inesperada. Algunos lineamientos generales para la prueba de interfaces son: 1. Examine el código a probar y liste de forma explícita cada llamada a los

componentes externos. Diseñe un conjunto de pruebas donde los valores de los parámetros para los componentes externos están en los extremos finales de sus rangos. Éstos valores extremos probablemente revelarán inconsistencias en la interfaz.

2. Si un componente es llamado a través de una interfaz procedural, diseñe pruebas

que provoquen la caída del componente. Diferir las suposiciones de fracase es una de las malas interpretaciones de especificación más comunes.

3. Utilice pruebas de esfuerzo en sistema de paso de mensajes. Diseñe pruebas que

generen muchos más mensajes de los que pueden ocurrir en la práctica. De esta manera aparecerán los problemas de coordinación.

4. Si varios componentes interactúan por medio de memoria compartida, diseñar

pruebas que varían el orden en el que estos componentes se activan. Estas pruebas revelan suposiciones implícitas hechas por los programadores acerca del orden en el que los datos compartidos se producen y consumen.

Las inspecciones de programa se concentran en las interfaces de los componentes y durante los procesos de inspección se pueden hacer preguntas acerca del comportamiento de la interfaz supuesta. Pruebas de esfuerzo Una vez que el sistema se integra completamente es posible probar el sistema acerca de las propiedades emergentes, tal como el desempeño y la fiabilidad. Se tienen que diseñar pruebas de desempeño para asegurar que el sistema pueda procesar la carga pretendida. Por lo general, esto comprende planear una serie de pruebas donde la carga se incrementa de forma constante hasta que el desempeño del sistema sea inaceptable. Algunas clases de sistemas se diseñan para manejar una carga específica. Las pruebas de esfuerzo continúan estas pruebas más allá de la carga de diseño máxima del sistema hasta que el sistema se caiga. Este tipo de pruebas tiene dos funciones:



262

1. Prueba el comportamiento erróneo del sistema : Pueden surgir circunstancias en

una combinación inesperada de eventos donde la carga colocada en el sistema exceda la carga anticipada máxima. En estas circunstancias es importante que la caída del sistema no provoque daños a los datos o pérdidas inesperadas de los servicios al usuario. Las pruebas de esfuerzo comprueban que sobrecargar el sistema provoca una “caída suave” de éste en lugar de que se colapse bajo su carga.

2. Acentúa el sistema y muestra defectos que normalmen te no se manifestarían

por sí solos : Aunque se puede argumentar que estos defectos probablemente no provocan caídas del sistema en condiciones normales, existen combinaciones no comunes de circunstancias normales que las pruebas de esfuerzo reproducen.

Las pruebas de esfuerzo son relevantes e forma particular para sistemas distribuidos basados en una red de procesadores. A menudo estos sistemas exhiben degradación severa cuando se sobrecargan. La red se inunda con datos de coordinación que intercambian los procesos diversos por lo que los procesos se vuelven cada vez más lentos puesto que esperan por los datos solicitados de los otros procesos. Bancos de trabajo de pruebas Llevar a cabo las pruebas es una fase cara y laboriosa del proceso del software. Como resultado las herramientas de prueba estaban entre las primeras herramientas de software a desarrollar. Actualmente, estar herramientas ofrecen un cúmulo de recursos y su utilización reducen de forma importante el costo del proceso e pruebas. Las diversas herramientas de prueba se integran en bancos de trabajo de pruebas. Las herramientas que se incluyen son: 1. Administrador de pruebas : Administra la ejecución de las pruebas del programa.

Mantiene un registro de los datos de prueba, los resultados esperados y los recursos del programa probados.

2. Generador de datos de prueba : Genera los datos de prueba para el programa a

probar. Esto se lleva a cabo seleccionando datos de la base de datos o utilizando patrones para generar datos aleatorios de la forma correcta.

3. Predictor: Genera predicciones de los resultados de prueba esperados. Los

predictores son versiones previas del programa o sistemas prototipo. Las pruebas espalda con espalda comprenden la ejecución en paralelo del predictor y del programa a probar. Se resaltan las diferencias en las salidas.

4. Comparador de archivos: Compara los resultados de las pruebas del programa

con los resultados de prueba previa y reporta las diferencias entre ellos. Los



comparadores son esenciales en las pruebas de regresión donde se comparan los resultados de ejecutar las versiones viejas y nuevas. Las diferencias en estos resultados señalan los problemas potenciales con la nueva versión del sistema.

5. Generador de informes : Provee la definición del informe y los recursos de generación para los resultados de la prueba.

6. Analizador dinámico : Agrega código a un programa para contar el número de

veces que se ejecuta cada instrucción. Después de ejecutar las pruebas, se genera un perfil de ejecución que muestra qué tan a menudo se ejecutan las instrucciones del programa.

7. Simulador: Provee diferentes clases de simuladores. Los simuladores objetivo

simulan la máquina sobre la que se ejecuta el programa. Los simuladores de interfaces de usuario son programas conducidos por secuencias de comandos que simulan interacciones múltiples de usuarios simultáneas.

Los requerimientos de pruebas para los sistemas grandes dependen de la aplicación a desarrollar. En consecuencia, los bancos de trabajo de pruebas invariablemente tienen que adaptarse para satisfacer el plan de prueba de cada sistema. A continuación se describen algunos ejemplos de adaptaciones que deben hacerse: 1. Se tienen que agregar nuevas herramientas para probar las características de

aplicaciones específicas. No se requieren algunas de las herramientas de prueba existentes.

2. Se tienen que escribir secuencias de comandos para los simuladores de la interfaz

de usuario y para los patrones definidos por los generadores de datos de prueba. También se tienen que definir los formatos del informe.

3. Si no están disponibles versiones previas del programa que sirvan como predictor,

entonces se tienen que preparar de forma manual conjuntos de resultados de prueba esperados.

4. Se tienen que redactar controladores de archivos de propósito especial que incluyan

el conocimiento de la escritura de los resultados de prueba sobre el archivo. Por lo general se necesita una cantidad importante de esfuerzo y tiempo para crear un banco de trabajo de pruebas adecuado. Los bancos de trabajo de pruebas completas, sólo se utilizan cuando se desarrollan sistemas grandes.

sistemas de informacion i

Documents