~ASEGURAMIENTO DE LA CALIDAD MEDIANTE INGENIERA DE SOFTWARE.

La calidad ha sido durante mucho tiempo una preocupacin para las empresas, como lo debe ser para los analistas de sistemas en el anlisis y diseo de sistemas de informacin. Los tres enfoques para el aseguramiento de la calidad mediante ingeniera de software son: -Garantizar el aseguramiento de la calidad total diseando sistemas y software con un enfoque modular, descendente de arriba abajo. -Documentar el software con las herramientas adecuadas. -Probar, mantener y auditar el software. Dos propsitos guan el aseguramiento de la calidad: -El usuario del sistema de informacin es el factor individual ms importante en establecer y evaluar su calidad. -Es mucho menos costoso corregir los problemas en sus fases iniciales que esperar hasta que un problema se manifieste a travs de las quejas o crisis del usuario.

Saldaa Fonseca Erndira

pgina 1

ENFOQUE DE ADMINISTRACIN DE LA CALIDAD TOTAL La administracin de la calidad total (TQM, por sus siglas en ingls) es esencial a lo largo de todos los pasos del desarrollo de sistemas. Los principales elementos de la TQM slo son significativos cuando se presentan en un contexto organizacional que favorece un esfuerzo integral por la calidad. Es en este contexto donde los elementos de enfoque en el cliente, planificacin estratgica y liderazgo, mejora continua, facultar al empleado y trabajo en equipo se unifican con el propsito de cambiar el comportamiento de los empleados y, en consecuencia, el curso de la organizacin. Los analistas de sistemas deben estar conscientes de los factores que despiertan el inters en la calidad. Es importante comprender que el creciente compromiso de las empresas hacia la TQM encaja sumamente bien en los objetivos generales del anlisis y diseo de sistemas.

SEISSEGMA La llegada de Seis Sigma ha cambiado el enfoque de la administracin de la calidad. Cada analista de sistemas necesita estar consciente de Seis Sigma y aplicar algunos de los principios a sus proyectos de anlisis de sistemas.

Saldaa Fonseca Erndira

pgina 2

Seis Sigma es un enfoque descendente de arriba a abajo. Se requiere que un CEO adopte la filosofa y un ejecutivo funja como campen de proyecto.

RESPONSABILIDAD DE LA ADMINISTRACIN DE LA CALIDAD TOTAL En trminos prcticos, gran parte de la responsabilidad por la calidad de los sistemas de informacin recae en los usuarios de stos y en los directivos. Para que la TQM se vuelva una realidad en los proyectos de sistemas, deben darse dos condiciones. Primera, debe existir un apoyo organizacional incondicional por parte de los directivos, lo cual es distinto a simplemente respaldar el nuevo proyecto de los directivos. Es necesario que tanto el analista como la empresa se comprometan desde el principio con la calidad para lograr la meta de calidad. Los estndares de calidad departamentales se deben comunicar mediante retroalimentacin para el equipo de anlisis de sistemas. Normalmente el equipo est sorprendido por lo que se ha desarrollado. Las expectativas generalmente son menos complejas de lo que analistas experimentados saben se podra hacer con un sistema.

REPASO ESTRUCTURADO

Saldaa Fonseca Erndira

pgina 3

Una de las acciones de administracin de la calidad ms eficaces que puede emprender el equipo de anlisis de sistemas es hacer repasos estructurados de manera rutinaria. Los repasos estructurados son una forma de usar expertos para monitorear la programacin y el desarrollo general del sistema, sealar los problemas y permitir al programador o analista responsable de dicha parte del sistema hacer los cambios correspondientes. Los repasos estructurados involucran por lo menos a cuatro personas: la persona responsable de la parte del sistema o subsistema que se revisar [un programador o analista}, un coordinador del repaso, un programador o analista experto y un experto que toma notas acerca de las sugerencias. Cada persona que participa en un repaso tiene un papel especial que cumplir. El coordinador se encarga de asegurar que otros cumplan los papeles que se les asigne y de que se realicen las actividades establecidas. El programador o analista est para escuchar, no para defender su punto de vista, racionalizar o discutir un problema. El programador o analista experto tiene que sealar los errores o problemas potenciales, sin especificar cmo se deben resolver. El tomador de notas registra lo que se dice con el fin de que los dems participantes puedan interactuar sin ningn problema. Los repasos estructurados se pueden hacer siempre que una parte de la codificacin, de un subsistema o de un sistema est terminada.

Saldaa Fonseca Erndira

pgina 4

Simplemente asegrese de que el subsistema bajo revisin sea comprensible estructurados fuera son del contexto al que pertenece. en un Los repasos de

especialmente

adecuados

enfoque

administracin de la calidad total cuando se realizan durante todo el ciclo de vida del desarrollo de sistemas. El tiempo para realizarlos debe ser de media hora a una hora cuando mucho, lo cual implica que deben coordinarse muy bien. En la figura 16.2 se muestra un formulario til para organizar el repaso estructurado e informar sus resultados. Debido a que los repasos estructurados toman tiempo, no abuse de ellos.

Formulario para documentar repasos estructurados: los repasos se pueden hacer siempre que se finalice una parte de la codificacin, de un sistema o de un subsistema.
-DISEO Y DESARROLLO DE SISTEMAS

Diseo ascendente: Este diseo se refiere a identificar los procesos que necesitan computarizarse conforme surgen, analizarlos como sistemas y codificar los procesos o comprar software empaquetado para resolver el problema inmediato. Los problemas que requieren computarizarse

normalmente se encuentran en el nivel ms bajo de la organizacin. Con frecuencia este tipo de problemas son estructurados y por lo tanto son ms sensibles a la computarizacin; tambin son los ms rentables. Por lo tanto,

Saldaa Fonseca Erndira

pgina 5

el nombre ascendente se refiere al nivel inferior en el cual se introduce primero la computarizacin. Por ejemplo, con frecuencia los negocios toman este enfoque para el desarrollo de sistemas al adquirir software comercial para la contabilidad, un paquete diferente para la programacin de produccin y otro para el marketing. Cuando la programacin interna se hace con un enfoque de ascendente, es difcil interconectar los subsistemas de manera que se desempeen fcilmente como un sistema. Es muy costoso corregir las fallas de la interconexin y muchas de ellas no se descubren sino hasta que se completa la programacin.

Diseo descendente: Es fcil visualizar este enfoque; como se muestra en la figura 16.3, significa ver una descripcin amplia del sistema y despus dividirla en partes ms pequeas o subsistemas. El diseo descendente permite a los analistas de sistemas determinar primero los objetivos organizacionales globales, as como tambin determinar cmo se renen mejor en un sistema global. Despus el analista divide dicho sistema en subsistemas y sus requerimientos. El enfoque descendente tambin proporciona el nfasis deseable en la colaboracin o interconexiones que los sistemas y sus subsistemas necesitan, el cual falta en el enfoque ascendente.

Saldaa Fonseca Erndira

pgina 6

Las ventajas de usar un enfoque descendente para el diseo de sistemas incluyen evitar el caos de intentar disear un sistema de repente. Como hemos visto, planear e implementar sistemas de informacin de administracin es increblemente complejo. Intentar colocar todos los subsistemas en su lugar y ejecutarlos en seguida es casi un fracaso seguro. Una segunda ventaja de tomar un enfoque descendente para disear es que permite separar a los equipos de anlisis de sistemas para trabajar en paralelo en diferentes subsistemas, lo cual puede ahorrar mucho tiempo. El uso de equipos para el diseo de subsistemas se ajusta particularmente bien a un enfoque de control de calidad total. Una tercera ventaja es que un enfoque descendente evita un problema mayor asociado con un enfoque ascendente; evita que los analistas de sistemas se metan tanto en los detalles que pierdan de vista lo que se supone que el sistema hace. Hay algunas dificultades con el diseo descendente que el analista de sistemas necesita saber. La primera es el riesgo de que el sistema se divida en subsistemas "errneos". Se debe poner atencin a las necesidades que se traslapen y a la comparticin de recursos de manera que la particin en subsistemas tenga sentido para todos los sistemas. Adems, es importante que cada subsistema solucione el problema correcto.

Saldaa Fonseca Erndira

pgina 7

Un segundo riesgo es que una vez que se hacen las divisiones de un subsistema, sus interfaces se podran descuidar o ignorar. Es necesario detallar de quin es la responsabilidad de las interfaces. Una tercera advertencia que acompaa al uso de un diseo descendente es que los subsistemas se deben reintegrar eventualmente. Los mecanismos para la reintegracin se necesitan poner en funcionamiento desde el principio. Una sugerencia es negociar informacin regular entre los equipos del subsistema; otra es usar herramientas que permiten flexibilidad si se requieren cambios para los subsistemas interrelacionados. DESARROLLO MODULAR Una vez que se toma el enfoque del diseo descendente, el enfoque modular es til en la programacin. Este enfoque implica dividir la programacin en partes lgicas y manejables llamadas mdulos. Este tipo de programacin funciona bien con el diseo descendente porque da nfasis a las interfaces entre los mdulos y no los descuida hasta el final del desarrollo de sistemas. Idealmente, cada mdulo individual debe ser funcionalmente cohesivo de manera que se encargue de realizar una sola funcin. El diseo de programa modular tiene tres ventajas principales. Primero, los mdulos son ms fciles de escribir y de depurar porque prcticamente son independientes. Rastrear un error en un mdulo es menos complicado,

Saldaa Fonseca Erndira

pgina 8

debido a que un problema en un mdulo no debe causar problemas en otros. Una segunda ventaja del diseo modular es que los mdulos son ms fciles de mantener. Normalmente las modificaciones se limitarn a unos mdulos y no seguirn en todo el programa. Una tercera ventaja del diseo modular es que los mdulos son ms fciles de entender, debido a que son subsistemas independientes. Por lo tanto, un lector puede adquirir una lista del cdigo de un mdulo y entender su funcin. Algunos lincamientos para la programacin modular incluyen lo siguiente: 1. Mantener cada mdulo de un tamao manejable (incluir a la perfeccin una sola funcin). 2. Poner particular atencin a las interfaces crticas (los datos y variables de control que se pasan a otros mdulos). 3. Minimizar el nmero de mdulos que el usuario debe modificar al hacer los cambios. 4. Mantener las relaciones jerrquicas establecidas en las fases descendentes.

MODULARIDAD EN EL ENTORNO DE WINDOWS

Saldaa Fonseca Erndira

pgina 9

La modularidad se est volviendo muy importante. Microsoft desarroll dos sistemas para vincular los programas en su entorno de Windows. El primero se llama intercambio dinmico de datos (DDE], el cual comparte cdigo al usar archivos de biblioteca de vnculos dinmicos (DLL). Al usar DDE, un usuario puede almacenar datos en un programa quizs en una hoja de clculo tal como Excel y despus usar dichos datos en otro programa, por decir, en un paquete de procesamiento de texto tal como Word para Windows. El programa que contiene los datos originales se denomina servidor y el programa que los usa se denomina cliente. El vnculo de DDE se puede establecer de manera que cuando se abra el archivo de procesamiento de texto del cliente, los datos se actualicen automticamente y se reflejen los cambios hechos en el archivo de hoja de clculo del servidor desde la ltima vez que se abri dicho archivo de procesamiento de texto. Un segundo enfoque para vincular programas en Windows se denomina vinculacin e incrustacin de objetos (OLE). Este mtodo de vincular programas es superior a DDE porque est ligado a los datos y grficos de la aplicacin. Mientras que DDE utiliza un enfoque de cortar y pegar para vincular datos y no retiene el formato, OLE retiene todas las propiedades de los datos creados originalmente.

Saldaa Fonseca Erndira

pgina 10

USO DE DIAGRAMAS DE ESTRUCTURA PARA DISEAR SISTEMAS La herramienta recomendada para disear un sistema modular descendente se denomina diagrama de estructura. Este grfico simplemente es un diagrama que consiste de cuadros rectangulares, los cuales representan los mdulos, y de flechas de conexin.

Un diagrama de estructura favorece el diseo descendente mediante mdulos

El analista debe mantener a la perfeccin este acoplamiento al mnimo. Cuando hay pocas parejas de datos y banderas de control en el sistema, lo ms fcil es cambiar el sistema. Cuando finalmente se programan estos mdulos, es importante pasar el menor nmero de parejas de datos entre los mdulos. An ms importante es que se deben evitar las banderas de control numerosas. El control se disea para ser pasado de los mdulos de nivel inferior a los de nivel superior en la estructura. Sin embargo, en raras ocasiones ser necesario pasar el control hacia abajo en la estructura. Las banderas de control deciden qu parte de un mdulo se ejecuta y estn asociadas con las instrucciones IR..THEN...ELSE... y otros tipos similares de instrucciones.

Saldaa Fonseca Erndira

pgina 11

Cuando el control se pasa en forma descendente, se permite que un mdulo de nivel inferior tome una decisin y el resultado es un mdulo que desempea dos tareas diferentes. Este resultado rompe con el modelo de un mdulo funcional: un mdulo slo debe desempear una tarea.

DIBUJO DE UN DIAGRAMA DE ESTRUCTURA Los diagramas de estructura se deben dibujar de arriba hacia abajo Al transformar un diagrama de flujo de datos en un diagrama de estructura, se deben tener en cuenta varias consideraciones adicionales. El diagrama de flujo de datos indicar la secuencia de los mdulos en un diagrama de estructura. Si un proceso se divide en un diagrama de flujo de datos hijo, el mdulo correspondiente para el proceso padre tendr mdulos subordinados que correspondan a los procesos encontrados en el diagrama hijo.

TIPOS DE MDULOS Los mdulos del diagrama de estructura entran en una de las tres categoras generales: (1) control, (2) transformacional (a veces denominado trabajador) o (3) funcional. Al producir un diagrama de estructura que es

Saldaa Fonseca Erndira

pgina 12

fcil de desarrollar y modificar, se debe tener cuidado de no mezclar los diferentes tipos de mdulos. Los mdulos de control normalmente se encuentran cerca de la parte superior del diagrama de estructura y contienen la lgica para desempear los mdulos de nivel inferior. Los mdulos de control podran estar, o no estar, representados en el diagrama de flujo de datos. Los tipos de instrucciones que normalmente estn en los mdulos de control son IF, PERFORM y DO. Las instrucciones detalladas tal como ADD y MOVE normalmente se mantienen al mnimo. Con frecuencia la lgica de control es la ms difcil de disear; por lo tanto, los mdulos de control no deben ser muy grandes. Si un mdulo de control tiene ms de nueve mdulos subordinados, se deben crear nuevos mdulos de control que sean subordinados del mdulo de control original. La lgica de un mdulo de control se podra determinar desde un rbol de decisin o una tabla de decisin. Una tabla de decisin con demasiadas reglas se debe dividir en varias tablas de decisin, con la primera tabla llamando a ejecucin a la segunda tabla. Cada tabla de decisin producira un mdulo de control. Los mdulos transformacionales son aqullos creados de un diagrama de flujo de datos.

Saldaa Fonseca Erndira

pgina 13

Normalmente

desempean

una

sola

tarea,

aunque

varias

tareas

secundarias se podran asociar con la principal.

SUBORDINACIN DE MDULO Un mdulo subordinado es uno inferior en el diagrama de estructura llamado por otro mdulo superior en la estructura. Cada mdulo subordinado debe representar una tarea que es una parte de la funcin del mdulo de nivel superior. Permitir que el mdulo de nivel inferior desempee una tarea que no es requerida por el mdulo que lo llama se denomina subordinacin inadecuada. En tal caso, el mdulo inferior se debe mover al nivel superior de la estructura.

INGENIERA DE SOFTWARE Y DOCUMENTACIN La planeacin y control son elementos fundamentales en todo sistema exitoso. En el desarrollo de software para el sistema, el analista de sistemas debe saber que la planeacin tiene lugar en el diseo, incluso antes de que empiece la programacin. Necesitamos tcnicas que nos ayuden a establecer los objetivos del programa, de manera que nuestros programas

Saldaa Fonseca Erndira

pgina 14

estn completos. Tambin necesitamos tcnicas de diseo que nos ayuden a separar el esfuerzo de programacin en mdulos manejables. Sin embargo, no es satisfactorio intentar tener xito tan slo con las etapas de la planeacin. Despus de que se completan los programas, se deben mantener y los esfuerzos de mantenimiento normalmente son mayores que el esfuerzo empleado en el diseo y la programacin originales. Las tcnicas descritas en la siguiente seccin no slo estn hechas para usarse inicialmente en el diseo de software, sino tambin en su mantenimiento. Debido a que la mayora de los sistemas no se consideran desechables, muy probablemente necesitarn ser mantenidos. El esfuerzo de aseguramiento de la calidad total requiere que los programas se documenten adecuadamente. El software y los procedimientos se documentan de manera que se codifiquen en un formato que se pueda acceder fcilmente. El acceso a esta documentacin es necesario para las nuevas personas que aprenden el sistema y como un recordatorio para aquellos que no usan el programa con frecuencia. La documentacin permite a usuarios, programadores y analistas "ver" el sistema, su software y procedimientos sin tener que interactuar con l.

Saldaa Fonseca Erndira

pgina 15

Cierta documentacin proporciona una apreciacin global del propio sistema, mientras que la documentacin de procedimiento detalla lo que se debe hacer para ejecutar el software en el sistema y la documentacin del programa detalla el cdigo del programa que se usa. La rotacin del personal de servicio de informacin tradicionalmente ha sido alta en comparacin con otros departamentos, de manera que

probablemente las personas que concibieron e instalaron el sistema original no sern las mismas que las que lo mantienen. La documentacin consistente y bien actualizada acortar el nmero de horas requerido para que las nuevas personas aprendan el sistema antes de realizar el mantenimiento. Hay muchas razones por las cuales los sistemas y programas no estn documentados o presentan subdocumentacin. Algunos de los problemas residen en los sistemas y programas, otros en los analistas de sistemas y programadores. Los analistas de sistemas podran no documentar adecuadamente los sistemas debido a que no tienen tiempo o no se les paga por el tiempo usado en la documentacin. Algunos analistas no documentan porque tienen miedo de hacerlo o piensan que no es su trabajo. Adems, muchos analistas son reservados sobre documentar sistemas que no son suyos, quizs temen a las represalias si incluyen material incorrecto

Saldaa Fonseca Erndira

pgina 16

en el sistema de alguien ms. La documentacin lograda por medio de una herramienta CASE durante las fases del anlisis puede resolver muchos de estos problemas. Actualmente no se usa una sola tcnica estndar de diseo y documentacin. En las siguientes secciones, discutimos varias tcnicas diferentes que actualmente se usan. Cada tcnica tiene sus propias ventajas y desventajas, debido a que cada una tiene propiedades nicas.

PSEUDQCDIGO En la industria es comn el uso del pseudocdigo, pero la falta de estandarizacin evitar que sea aceptado por todos. Debido a que el pseudocdigo est tan cerca del cdigo de programa, naturalmente es favorecido por programadores y por consiguiente no es favorecido por analistas de negocios. El pseudocdigo con frecuencia se usa para representar la lgica de cada mdulo en un diagrama de estructura. El diagrama de flujo de datos se podra usar para escribir la lgica del pseudocdigo. Al usar un nivel del programa en lugar de un nivel del sistema, el diagrama de flujo de datos podra agregar varios smbolos adicionales. El asterisco (*], que significa "y", se usa para indicar que deben estar presentes los dos flujos de datos nombrados. Consulte la parte de un diagrama de flujo de datos que se ilustra en la figura 16.17. Si los flujos de

Saldaa Fonseca Erndira

pgina 17

datos de entrada son de procesos diferentes, la presencia del conectar "y" significa que el proceso que recibe el flujo debe desempear alguna clase de coincidencia de archivo o una coincidencia secuencial leer todos los registros de ambos archivos o una lectura indexada de un segundo archivo usando un campo importante obtenido del primer archivo.

MANUALES DE PROCEDIMIENTO

Los manuales de procedimiento son documentos organizacionales comunes que la mayora de las personas ha visto. Son el componente en espaol de la documentacin, aunque tambin podran contener cdigos de programa, diagramas de flujo, etc. Se pretende que los manuales comuniquen a aquellos que los usan. Podran contener comentarios de fondo, los pasos requeridos para lograr diferentes transacciones, instrucciones de cmo recuperarse de los problemas y qu hacer si algo no funciona (solucionar problemas]. Actualmente muchos manuales estn disponibles en lnea, con capacidad de hipertexto que facilita el uso. Se desea un enfoque directo y estandarizado para crear documentacin de apoyo de usuario. Para ser til, la documentacin del usuario se debe mantener actualizada. El uso de Web ha revolucionado la velocidad con que los usuarios pueden obtener asistencia.

Saldaa Fonseca Erndira

pgina 18

Muchos diseadores de software estn desplazando el soporte de usuario con la lista de preguntas frecuentes (FAQ), escritorios de ayuda, soporte tcnico y servicios de fax para Web. Adems, muchos vendedores de software COTS incluyen archivos "Lame" con descargas o envos de nuevo software. Estos archivos sirven para varios propsitos: documentan cambios, ajustan o reparan fallas recientemente descubiertas en la aplicacin que han ocurrido demasiado tarde en su desarrollo para poder ser incluidas en el manual del usuario. EL MTODO DE FOLKLORE El FOLKLORE es una tcnica de documentacin de sistemas creada para complementar algunas de las tcnicas ya tratadas. Aun con la abundancia de tcnicas disponibles, muchos sistemas se documentan inadecuadamente o no se documentan en absoluto. El FOLKLORE recopila informacin que normalmente se comparte entre los usuarios pero raramente se pone por escrito. El FOLKLORE es una tcnica sistemtica, basada en mtodos tradicionales usados para recopilar el folklore sobre las personas y leyendas. Este enfoque para la documentacin de sistemas requiere que el analista entreviste a los usuarios, investigue la documentacin existente en los archivos y observe el procesamiento de informacin. El objetivo es recopilar

Saldaa Fonseca Erndira

pgina 19

la informacin correspondiente a una de cuatro categoras: costumbres, ancdotas, proverbios y formas artsticas. Al documentar las costumbres, el analista (u otro folklorista) intenta capturar por escrito lo que los usuarios hacen para conseguir que los programas puedan ejecutar sin problemas. Un ejemplo de una costumbre es: "Normalmente, nos toma dos das actualizar los registros mensuales porque la tarea es bastante grande. Ejecutamos cuentas comerciales en un da y guardamos las otras para el siguiente da". Las ancdotas son historias que los usuarios dicen respecto a cmo funcion el sistema. Por supuesto, la exactitud de la ancdota depende de la memoria del usuario y es, en el mejor de los casos, una opinin sobre cmo funcion el programa.

SELECCIN DE UNA TCNICA DE DISEO Y DOCUMENTACIN Las tcnicas discutidas en este captulo son sumamente valiosas como herramientas de diseo, ayudas de memoria, herramientas de productividad y como medios de reducir las dependencias en los miembros de personal clave. Sin embargo, el analista de sistemas se enfrenta con una decisin

Saldaa Fonseca Erndira

pgina 20

difcil con respecto a qu mtodo adoptar. Lo siguiente es un grupo de lineamientos para ayudar al analista a seleccionar la tcnica adecuada. Escoja una tcnica que: 1. Es compatible con la documentacin existente. 2. Se entiende por otros en la organizacin. 3. Le permite regresar a trabajar en el sistema despus de que ha estado fuera de l por un periodo. 4. Sea conveniente para el tamao del sistema en que est trabajando. 5. Permita un enfoque de diseo estructurado si se considera como ms importante que otros factores. 6. Permita fcil modificacin.

COMO PROBAR, MANTENER Y AUDITAR Una vez que el analista ha diseado y codificado el sistema, probar, mantener y auditar son las primeras consideraciones.

EL PROCESO DE PROBAR Todos los programas de aplicacin del sistema recin escritos o modificados as como tambin nuevos manuales de procedimiento, nuevo hardware y todas las interfaces del sistema se deben probar completamente. Probar al azar y por tanto no ser suficiente.

Saldaa Fonseca Erndira

pgina 21

Las pruebas se hacen durante todo el proceso de desarrollo de sistemas, no slo al final. Se busca descubrir errores desconocidos hasta ahora, no demostrar la perfeccin de programas, manuales o equipo. Sistema tambin se debe probar como un todo en funcionamiento. Incluso hay que probar las interfaces entre los subsistemas; la exactitud de salida; y la utilidad y entendimiento de la documentacin y salida de sistemas. Como se muestra en la figura 16.19, los programadores, analistas, operadores y usuarios cumplen un papel diferente en los varios aspectos a probar. Las pruebas de hardware normalmente se proporcionan como un servicio por los vendedores de equipo quienes ejecutarn sus propias pruebas en el equipo cuando se libere en el sitio. Pruebas de programas con datos de prueba Mucha de la responsabilidad para probar el programa radica en el autor(es) original de cada programa. El analista de sistemas sirve como consejero y coordinador para las pruebas del programa.

PRCTICAS DE MANTENIMIENTO Su objetivo como analista de sistemas debe ser instalar o modificar sistemas que tienen una vida bastante til. Quiere crear un sistema cuyo diseo es bastante comprensivo y previsivo para atender las necesidades

Saldaa Fonseca Erndira

pgina 22

actuales y proyectadas del usuario durante varios aos. Debe usar parte de su experiencia para proyectar lo que podran ser esas necesidades y despus construir flexibilidad y adaptabilidad en el sistema. Lo mejor y ms fcil del diseo de sistemas ser asegurar que el negocio tendr que gastar menos dinero en el mantenimiento. Reducir los costos de mantenimiento es una consideracin principal, debido a que el mantenimiento de software aislado puede consumir ms de 50 por ciento del presupuesto de procesamiento de datos para un negocio. Los costos de mantenimiento excesivos se reflejan directamente en el diseador del sistema, debido a que aproximadamente 70 por ciento de errores de software se han atribuido al diseo de software inadecuado. Desde una perspectiva de sistemas, tiene sentido que detectar y corregir a tiempo los errores de diseo de software es menos costoso que permitir que permanezcan inadvertidos hasta que sea necesario el mantenimiento. Por lo regular el mantenimiento se realiza para mejorar el software existente en lugar de responder a una crisis o falla del sistema. Al igual que con el cambio de requerimientos del usuario, el software y la documentacin se deben cambiar como parte del trabajo de mantenimiento. Adems, los programas se podran recodificar para mejorar la eficacia del programa original. Ms de la mitad de todo el mantenimiento est compuesto de dicho trabajo de mejora.

Saldaa Fonseca Erndira

pgina 23

El mantenimiento tambin se hace para actualizar el software en respuesta a la organizacin cambiante. Este trabajo no es tan sustancial como mejorar el software, pero se debe hacer. El mantenimiento de emergencia y de adaptacin representa menos de la mitad de todo el mantenimiento del sistema.

Saldaa Fonseca Erndira

pgina 24