Instituto de Estudios Superiores Argentino (IESA)

Materia: Análisis y Diseño de Sistemas

Carrera: Analista de Sistemas
Profesora: (AUS) Norma E. Ayala

Análisis y Diseño de Sistemas

Clase Nº 20
Soporte de sistemas: Es el mantenimiento permanente de un sistema después de que haya sido puesto en
explotación. Ello incluye tanto el mantenimiento estricto de los programas como las posibles mejoras que
puedan añadirse al sistema. Consta de las siguientes fases:
1) Corregir errores (también llamado mantenimiento): Con independencia de como esté diseñado, construido y
probado un sistema o aplicación, inevitablemente aparecerán errores. Algunos de estos errores son:
* Fallos en la comunicación de las necesidades.
* Defectos de diseño.
* Situaciones no previstas, y por lo tantos no probadas.
* Mal uso no previsto de los programas.
En todas estas situaciones deben emprenderse acciones de corrección, estas acciones las llamamos
mantenimientos de sistemas o mantenimiento de programas.

Objetivos y bloques elementales del mantenimiento de sistemas:

* Hacer cambios predecibles en los programas existentes para corregir errores que se cometieron durante el
diseño y la implantación de sistemas.
* Preservar aquellos aspectos de los programas que ya fueron corregidos (Evitar la posibilidad de que los
arreglos en dichos programas originen que otros aspectos de los mismos funcionen de modo diferente.

¿Cómo se relaciona el mantenimiento de sistemas con los bloques elementales de los sistemas de información?
* PERSONAS: El mantenimiento de sistemas es normalmente iniciado por los usuarios del sistema. El
mantenimiento es llevado acabo por lo general por constructores de sistemas, con posible ayuda de los
diseñadores de sistemas.
* DATOS: El mantenimiento de sistemas rara vez influye sobre los datos, salvo por la posibilidad de que se mejore
la edición de dichos datos.
* ACTIVIDADES: Los procesos de los sistemas de empresa y de información se implantas finalmente como
programas de aplicaciones. El mantenimiento de sistemas consiste en arreglar los errores cometidos durante la
implantación de dichos programas.
* REDES: el mantenimiento de sistemas rara vez tiene que ver con las redes informáticas, si bien en ocasiones
son las redes informáticas las fuentes de determinados errores.
* TECNOLOGIA: El mantenimiento de sistemas, no tiene que ver con los cambios tecnológicos.
Las actividades son:

Actividad 1: definir y validar los problemas: Trabajando conjuntamente con usuario o usuarios, el equipo deberá
intentar validar el o los problemas consiguiendo reproducirlos. Si el problema no puede reproducirse debería
suspenderse el proyecto hasta que se reprodujera el problema y el usuario pudiera explicar las circunstancias en
las cuales tubo lugar. Las entradas es el conjunto de errores encontrado al usar el sistema. Una posible salida
sería las solicitudes de cambio validadas, estas deberán definir las expectativas de solución.
 Instituto de Estudios Superiores Argentino (IESA)
Materia: Análisis y Diseño de Sistemas
Carrera: Analista de Sistemas
Profesora: (AUS) Norma E. Ayala

Otra posible salida es problema no validado. En el caso de que volviera a producirse el error los usuarios
deberían ser aleccionados para que documentaran del mejor modo posible las circunstancias que llevaron a la
aparición del error y de los síntomas del problema.
Si el error ha sido validado, se pasarán los problemas y programas validados a la siguiente tarea.

Actividad 2: aplicar un juego de datos de prueba a los programas y la aplicación: El equipo debería entonces
aplicar un juego de datos de prueba a los programas y la aplicación. El mantenimiento de sistemas puede
descubrir efectos impredecibles y no deseables que influirán sobre el funcionamiento y el rendimiento global de
los programas o la aplicación. Por ese motivo, antes de realizar ningún cambio en los programas, se ejecuten y se
prueben para definir una línea de partida con respecto a la cual puedan compararse los programas y aplicaciones
modificados.
Este paso es llevado a cabo por el analista y/o programador de sistemas. Los usuarios también pueden participar
en él. Las entradas principales al mismo son los problemas y programas validados.
Los casos de juego de datos de prueba pueden definirse de dos maneras posibles. La primera consistiría en
buscar datos de prueba antiguos. Si existieran, deberían servir como juego de datos de prueba para la ejecución
del programa. Alternativamente, es posible capturar automáticamente los datos de pruebas por medio de
empleo de una herramienta de prueba registrando pulsaciones de teclado, movimientos de ratón e
instrucciones, así como las respuestas del sistema, mientras el usuario muestra un uso típico del sistema.
En cualquier caso, las salidas serán un rendimiento actual y de datos de prueba nuevo o revisado y programas
probados con juegos de datos de prueba.

Actividad 3: Conocer la aplicación y sus programas: En términos ideales, el conocimiento de la aplicación se

obtiene del diccionario. En centros de sistemas de información no basados en diccionarios, puede conseguirse el
conocimiento de la aplicación de los programadores y analistas anteriores, pero dicho conocimiento puede no
estar al día. Sin embargo puede ser de utilidad para alcanzar un nivel suficiente de comprensión de la aplicación
y donde encajan los programas problemáticos dentro de dicha aplicación.
El conocimiento de la aplicación y los programas proviene por lo general del estudio del código fuente de los
programas probados con juego de datos de prueba. Esta actividad se hace mas lenta por la combinación de una
serie de limitaciones.
* Una deficiente estructura modular.
* Uso de lógica no estructurada.
* Mantenimientos previos (arreglos rápidos y ampliaciones deficientemente diseñadas).
* Código muerto (instrucciones que nunca se ejecutan o las que nunca se llega, a menudo olvidadas durante
fases anteriores de prueba y depuración)
* Documentación deficiente o inadecuada.
El propósito de conocer la aplicación es conseguir tener una visión general del asunto es decir, saber como
encajan los programas en una aplicación total y como interaccionan con otros programas. También tiene como
objetivo la comprensión de los programas, conseguir suficiente información sobre como funciona el programa, y
sobre lo que no funciona.
 Instituto de Estudios Superiores Argentino (IESA)
Materia: Análisis y Diseño de Sistemas
Carrera: Analista de Sistemas
Profesora: (AUS) Norma E. Ayala

Actividad 4: Editar y probar los programas: dado el conocimiento de la aplicación y los programas y los cambios
validados pueden entonces realizarse los cambios en los programas que han de modificarse. Su resultado es un
programa modificado.
Es de esperar que los cambios en el código sean mejores si se conocen la aplicación del programa, si se revisan.
Pero más importante aun en el mantenimiento del sistema son las pruebas:
* Pruebas de unidades (esencial), asegura que el programa considerado en solitario arregla el error sin efectos
colaterales.
* Pruebas del sistema (esencial), asegura que la aplicación en conjunto, de la que forma parte el programa
modificado aún funciona.
* Prueba de regresión (recomendada), explota el impacto de los cambios en la productividad y el tiempo de
respuesta del programa y la aplicación antes y después.

Actividad 5: Actualizar la documentación: El alto coste del mantenimiento de sistemas se debe, en gran parte, a
fallos en la actualización de la documentación de la aplicación y los programas. Cada vez que cambie la
documentación de una aplicación, debe modificarse en el diccionario y en la biblioteca de programas. La
documentación de la aplicación es, por lo genera, responsabilidad del analista de sistemas que da soporte a
dicha aplicación. La documentación de los programas suele ser responsabilidad del programador que realiza los
cambios en los programas.
Grabar los cambios de las aplicaciones y los programas en el diccionario y la biblioteca de programas ayudará a
los futuros programadores y analistas (tal vez los mismos) a reducir el tiempo dedicado al aprendizaje de la
aplicación durante futuras tareas de mantenimiento.

2) Recuperar el sistema: El analista de sistema es a menudo el encargado de arreglar el sistema o actuar como
intermediario entre los usuarios y quienes deben recuperar el sistema.
Los papeles del analista en recuperación de los sistemas:
* En muchos casos, el analista puede sentarse ante el terminal de usuario y recuperar el sistema. Es posible que
se requieran instrucciones de corrección para evitar que vuelva a producirse el fallo generalizado.
* En ciertos casos el analista debe ponerse en contacto con el servicio de explotación de los sistemas para
corregir el problema.
* En algunos casos el analista puede tener que recurrir a la administración de datos para recuperar archivos o
bases de datos perdidos o deteriorados.
* En algunos casos el analista puede tener que recurrir a la administración de redes para resolver un problema
de redes locales o extendidas, o de interconexión de redes.
* En algunos casos el analista puede tener que recurrir a los técnicos o representantes de los vendedores para
arreglar un problema de hardware.
* En algunos casos el analista tal vez descubra el error que a provocado el fallo. Este intentará aislar dicho error
rápidamente y bloquearlo para evitar dar lugar a otro fallo.

3) Asistir a los usuarios del sistema: Independientemente de cómo haya sido la formación de usuarios de la
calidad de la documentación, los usuarios requerirán asistencia adicional. El analista de sistemas está, por lo
 Instituto de Estudios Superiores Argentino (IESA)
Materia: Análisis y Diseño de Sistemas
Carrera: Analista de Sistemas
Profesora: (AUS) Norma E. Ayala

general, a disposición de los usuarios para ofrecerles ayuda en el uso diario de aplicaciones específicas. En
aplicaciones de máxima importancia, el analista debe estar disponible día y noche.
Una vez más, es innecesario ofrecer un diagrama de flujo detallado para esta actividad.
Las tareas más características comprenden:
* Observación rutinaria del uso del sistema.
* Realización de estudios y reuniones para conocer el grado de satisfacción del usuario.
* Cambiar los procedimientos de empresa para que sean más claros (se escribirán y se grabarán en le
diccionario).
* Ofrecer formación adicional.
* Anotar en el diccionario las ideas y las solicitudes sobre posibles mejoras.

4) Adaptar al sistema ante nuevas necesidades (también llamado reingeniería):

La adaptación de un sistema existente a las nuevas necesidades es una posibilidad siempre abierta en todos los
sistemas de nueva implantación. El mantenimiento ligado a estas adaptaciones obliga al analista a analizar las
nuevas necesidades y volver a las fases adecuadas del análisis, del diseño y la implantación de sistemas.
Objetivos y bloques elementales de las mejoras y la reingeniería de sistemas: La mayor parte del
mantenimiento de adaptaciones se hace como respuesta a la aparición de nuevos problemas de empresa,
nuevas necesidades de información o nuevas ideas de mejoras.
* Personas: En su mayoría las mejoras a los sistemas so propuestas por los usuarios de los sistemas, en algunos
casos pueden ser propuesto por los analistas.
* Datos: Muchas mejoras de los sistemas son demandas de nueva información que pueden derivarse de datos
almacenados existentes.
* Procesos: En su mayoría, las mejoras a los sistemas requieren la modificación de programas existentes o la
creación de nuevos programas para ampliar el ámbito general del sistema de aplicaciones.
* Redes: En su mayoría, las mejoras a los sistemas no tienen que ver con las redes.
* Tecnología: En su mayoría, las mejoras a los sistemas se basan en la tecnología.
Los objetivo de la reingeniería son o bien adaptar el sistema ante un cambio tecnológico importante y arreglar el
sistema antes de que falle o bien hacer el sistema más sencillo de manejar para cuando falle o tenga que ser
adaptado. Estos objetivos pueden relacionarse con los bloques elementales de los sistemas de información del
modo siguiente.
* Personas: En su mayor parte, la reingeniería es llevada a cabo por personal técnico y de sistemas de
información.
* Datos: Muchos proyectos de reingeniería son debidos a la necesidad de reestructurar los datos almacenados.
* Procesos: Muchos proyectos de reingeniería intentan reestructurar o reorganizar programas de aplicación para
hacerlos más fáciles de mantener o convertirlos a un nuevo entorno tecnológico.
* Redes: Algunos proyectos de aplicación buscan modificar las aplicaciones y adaptarlas a una nueva tecnología
de redes.
* Tecnología: En su mayoría, los proyectos de reingeniería se deben a cambios en la tecnología o a la necesidad
de aprovechar mejor la tecnología existente.
 Instituto de Estudios Superiores Argentino (IESA)
Materia: Análisis y Diseño de Sistemas
Carrera: Analista de Sistemas
Profesora: (AUS) Norma E. Ayala

Actividad 1: analizar las solicitudes de mejoras: El propósito de esta actividad es determinar el curso apropiado
de acciones para tratar nuevos problemas de empresa o ideas de mejoras, problemas o limitaciones técnicas o
ideas de mejoras. Esta actividad estudia la documentación existente para determinar el curso apropiado de
acciones que han de emprenderse. Sobre la base del análisis de los modelos del sistema actual estas acciones
pueden incluir:
* Definir nuevas necesidades de empresa y volver al análisis de sistemas.
* Definir nuevas necesidades técnicas y volver al diseño de sistemas.
* Definir nuevas necesidades de programa y proceder a la actividad 2.

Actividad 2: escribir nuevos programas sencillos: muchas mejoras pueden conseguirse rápidamente mediante la
escritura de nuevos programas sencillos. Los programas sencillos son aquellos que utilizan datos existentes, no
actualizan los datos existentes y no introducen nuevos datos (por motivo de almacenamiento de datos).
En otras palabras, dichos programas generan nuevos informes y responden a nuevas consultas. Las necesidades
de nuevos programas conforman la mayoría de las mejoras que se requieren hoy en día.

Actividad 3: reestructurar archivos o bases de datos: La migración de las estructuras de datos de una tecnología
a otra constituye un empeño de primer orden mas complicado aún por la posibilidad de deteriorar programas y
datos de empresa esenciales.
El mediador clave en la reestructuración de bases de datos es analista de bases de datos. El analista de sistemas
desempeña un papel de importancia, debido al impacto potencial en las aplicaciones existentes. Los analistas de
redes pueden también verse involucrados en esta tarea si las bases de datos están, o han de estar, distribuidas
en redes informáticas.
Las estradas clave a esta acción son las estructuras de bases de datos existentes y los datos, procesos y redes
existentes (almacenados en el diccionario). Las salidas son una nueva estructura de bases de datos y un nuevo
modelo de datos, procesos y redes.

Actividad 4: Analizar la biblioteca de programas y los costes de mantenimiento: Esta actividad casi siempre
requiere software capaz de llevar a cabo el análisis. Los analistas de sistemas suelen ser quienes interpretan los
resultados. Estos softwares utilizan una amplia variedad de métricas de software, que son un conjunto de
medidas matemáticamente probadas sobre la calidad y la productividad del software.
Las métricas de software aplicables al mantenimiento son:
* Nudos de flujos de control, o números de veces que se cruzan entre si los caminos lógicos. En términos ideales
un programa debería tener 0 nudos de flujos de control.
* Complejidad de los ciclos, o número de caminos únicos a través de un programa. En términos ideales cuanto
menos sean mejor.
La métrica de software, en combinación con la contabilidad de costes puede ayudar a identificar los programas
cuya reestructuración producirá mayores beneficios.
Las entradas a esta tarea son todos los programas de la biblioteca o la mayoría de ellos.
Las salidas en un programa o programas candidatos para reingeniería.
 Instituto de Estudios Superiores Argentino (IESA)
Materia: Análisis y Diseño de Sistemas
Carrera: Analista de Sistemas
Profesora: (AUS) Norma E. Ayala

Actividad 5: hacer reingeniería y prueba de los programas: Dado un programa o programas candidatos para
reingeniería, existen tres tipos de reingeniería que pueden aplicarse sobre dicho programa:
a) Reorganización de código: reestructura la organización modular y/o la lógica del programa. Por ejemplo, los
módulos pueden combinarse o separarse para reducir el acoplamiento o aumentar la cohesión.
b) Conversión de código: Traduce el código de un lenguaje a otro. Típicamente esta traducción se realiza de una a
otra versión del mismo lenguaje.
c) Fragmentación de código: Constituye la opción de reingeniería de programas más interesante de todas.
Muchos programas contienen componentes que deberían definirse como subprogramas. Si se hace tal
descomposición se obtendrían ventajas de mantenimiento. La importancia de dividir el programa podría ser
reutilizarlo en labores posteriores. La fragmentación de código extrae un fragmento de un programa para crear
un programa, o un subprograma independiente.
Los nuevos modelos de datos, procesos y/o redes se actualizan en el diccionario.