Sistemas Automáticos de Diagnóstico

y Detección de Fallas I (75.67)

Guía de Trabajos Prácticos

Docentes: Dr. Ramón García Martínez

M. Ing. Paola Britos

Auxiliares: Lic. Hernán Merlino

Sr. Marcelo Gentile
Sr. Mariano Hernández
Sr. Sebastián La Cruz

Ingeniería Informática
Facultad de Ingeniería - Universidad de Buenos Aires
2004
 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Índice de contenidos

INTRODUCCIÓN A LA METODOLOGÍA DE SISTEMAS.......................................................3

METODOLOGÍA DE IMPLEMENTACIÓN DE SISTEMAS DE INFORMACIÓN (FASES) ...............................3
Conceptos básicos........................................................................................................................3
Sistema - Subsistema - Jerarquía Sistémica ................................................................................3
Sistema de Información................................................................................................................6
El sistema de información en la organización...........................................................................12
Dato vs. Información .................................................................................................................19
Actividad del Profesional de Sistemas de Información .............................................................20
Fases ......................................................................................................................................23
Análisis del Sistema ...............................................................................................................24
Fases integrales del proyecto .................................................................................................27
Planificar ............................................................................................................................27
Pruebas ...............................................................................................................................28
Métodos de prueba .............................................................................................................30
Configuración.....................................................................................................................33
Auditoria ............................................................................................................................40
Enfoque metodológico de la actividad profesional ...................................................................41
BIBLIOGRAFÍA..............................................................................................................................43

Facultad de Ingeniería (U.B.A.) Página 2

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Introducción a la Metodología de Sistemas

Metodología de Implementación de Sistemas de

Información (Fases)

Conceptos básicos

Sistema - Subsistema - Jerarquía Sistémica

Consideremos la Empresa Crecer, cuyo ramo es: Turismo. Esta empresa se dedica a la
comercialización de paquetes de viaje estudiantiles de fin de curso. Presentamos a
continuación una breve síntesis de su funcionamiento.
"El área de ventas está compuesta por: un supervisor general, vendedores y una persona
que se ocupa de las contrataciones y reservas de Hoteles, micros, excursiones, boliches, etc.
El supervisor general, se encarga de indicarle a los vendedores a qué escuelas dirigirse y el
"paquete de ventas" a ofrecerle a los estudiantes.
Jorge, el encargado de las contrataciones, envía fax a los hoteles, agencias de turismo de
todo el país, y boliches solicitando información turística, costos y vacantes disponibles. Guarda
toda la documentación que recibe en biblioratos debidamente ordenados. Pasados cuatro días
se reúne con Rubén, el supervisor, con quien analiza la información recibida, confeccionando
un informe de posibles contrataciones que es elevado a la Gerencia General para su
evaluación.
Cuando Rubén recibe de la Gerencia de Finanzas el "paquete de viaje" aprobado, tanto
por dicha Gerencia como por la Gerencia General; le suma el precio actualizado de los micros
que le enviara telefónicamente Mirta de la empresa YYY S.A. y se pone en contacto con el
responsable del Área de Publicidad, quien activa la campaña publicitaria en periódicos,
revistas, radio, canales de cable y otros medios.
La Gerencia de Marketing en base al listado de escuelas secundarias reparte a los
vendedores las carpetas de ventas, asignándole a cada uno, de acuerdo a su categoría (junior,
senior), una zona de impacto.
El vendedor visita las escuelas presentando a los estudiantes el "paquete de viaje", para
eso utiliza el "speech" de ventas que les enseñaron en los cursos de entrenamiento, dictados
por la Dirección de Recursos Humanos. Si logran su propósito, confeccionan una intención de
contrato que entregan al supervisor, para que éste cite a cada uno de los alumnos interesados
en viajar, para armar su contrato individual."

Facultad de Ingeniería (U.B.A.) Página 3

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Algunas conclusiones que se pueden obtener del ejemplo:

El Sistema de Ventas está conformado por distintas partes o elementos (supervisor,
encargado de reservas, vendedores), cada elemento cumple distintas funciones. Pero
además existen y son imprescindibles las relaciones entre ellos.
Es claro que este Sistema cuenta con lo que se denomina un objetivo común del
conjunto. En este caso es: Vender paquetes de viajes de fin de curso. El mal
funcionamiento o la falta de algún elemento pondría en riesgo el cumplimiento del
objetivo final del Sistema. Si los vendedores no son eficientes la empresa reduce sus
ventas. Si el encargado de reservas no puede comunicarse con los hoteles no se
podría confeccionar el "paquete de viaje". Si el supervisor no les entrega a los
vendedores la carpeta de ventas o no les asigna adecuadamente las escuelas,
difícilmente estos últimos puedan cumplir su función.

Si percibimos “el sistema” como un TODO, este es algo más que la sumatoria de las
partes. El sistema está formado por sus elementos, mas las relaciones que los vinculan,
mas...
Consideremos como sistema una obra de arte, un cuadro en el cual se representan una
serie de figuras geométricas. Cada una de ellas elementos del sistema, tendrá sus
características propias: color, forma, tamaño, etc. La composición total tendrá como
objetivo producir un impacto estético en el público.
Es decir, cuando se percibe el todo, obra de arte, el observador verá el sistema cuadro
como algo más que la sumatoria de figuras geométricas plasmadas con una
determinada orientación en la tela, quizás perciba una obra que le producirá asombro,
admiración u otro tipo de sensaciones que el artista supo o quiso transmitir.

SISTEMA: Conjunto de elementos interrelacionados

ordenadamente con un objetivo común.

El Sistema de Ventas de la empresa es tan sólo uno de los tantos con los que cuenta la
empresa, también posee un Sistema de Cobranzas, Sistema de Pagos, Sistema de
Marketing, Sistema Contable, Sistema de Sueldos y Jornales, etc. Cada uno de estos
sistemas puede ser concebido como un SISTEMA (conjunto de elementos
interrelacionados con un objetivo común).

A su vez la empresa Crecer puede ser concebida como un SISTEMA (conjunto de

elementos interrelacionados con un objetivo común).
A su vez el grupo de Empresas dedicadas al turismo puede ser considerado como un
SISTEMA (conjunto de elementos interrelacionados con un objetivo común).
Y el grupo de las Empresas Argentinas puede ser considerado como SISTEMA
(conjunto de elementos interrelacionados con un objetivo común).
Y así se podría seguir infinitamente entre el átomo y el Universo.

Facultad de Ingeniería (U.B.A.) Página 4

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Empresas Argentinas

JERARQUÍA SISTÉMICA: Todo sistema contiene sistemas de menor

jerarquía y a su vez es parte de un sistema de jerarquía mayor que
lo contiene

SUBSISTEMA: Sistema que forma parte de otro de mayor jerarquía.

Elemento del sistema.

Facultad de Ingeniería (U.B.A.) Página 5

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Sistema de Información

Continuemos con la Empresa Crecer.

Para cumplir su objetivo, en primera instancia necesita RECOLECTAR información

sobre:
Hoteles.
Micros.
Clientes.

En el caso de los Hoteles y Micros recolecta información, a través de guías, folletos y

contactos ya sea por Fax, teléfono o directamente.

En el caso de los Clientes, recolecta información a través de un formulario dispuesto

para tal efecto.

Todo este proceso implica diversas maneras de RECOLECTAR información necesaria

para poder ofrecer el servicio turístico.

Cada área tiene su propio SUBSISTEMA para recolectar información y el conjunto

forma el SISTEMA para RECOLECTAR información del Sistema de Ventas de la Empresa
Crecer.

Para el subsistema recolectar información de Hoteles, hay 2 ó 3 formas de obtener la

información necesaria:
Consultando guías o folletos,
Por teléfono o FAX,
Directamente.

Es decir que cada subsistema esta a su vez formado por subsistemas menores.
Esto sucede n veces en cada paso.

Cuando el profesional de Sistemas ANALIZA el sistema debe conocer todos y cada uno
de los mínimos niveles de subsistemas para RECOLECTAR información, y cuando DISEÑA
debe de hacerlo considerando TODOS y cada uno de los mínimos niveles de subsistemas para
RECOLECTAR información.

¿Qué se hace con toda la información recolectada?

Facultad de Ingeniería (U.B.A.) Página 6

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Subsistemas para Recolectar

La segunda instancia es ALMACENAR información.

Los formularios de los Alumnos se guardan alfabéticamente en Ficheros, ordenados por
Apellido y Nombre.
La información de los Hoteles se guarda en la Base de Datos de Hoteles.
Las guías en Biblioteca y los FAX en el Archivo General.
La información de los Transportes se guarda en la Base de Datos de Transportes.
Todo este proceso implica diversas maneras de ALMACENAR información para ofrecer
el servicio turístico. Para ello, debe definirse cómo y en qué lugar conviene guardar la
información para luego recuperarla cuando sea necesario.
El bibliorato y su orden son distintos del Fichero y su orden y totalmente diferente de las
Bases de Datos. Debe decidirse para cada una de estas formas, dónde se guarda físicamente,
en qué orden y en el caso de las Bases de datos, cuál es el diseño de las tablas, etc.

Facultad de Ingeniería (U.B.A.) Página 7

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I
Cada área entonces, tiene su propio SUBSISTEMA para ALMACENAR información y el
conjunto forma el SISTEMA para ALMACENAR información del Sistema de Ventas de la
Empresa Crecer.

Subsistemas para Almacenar

Para el subsistema almacenar información de Hoteles, hay tres formas de guardar la

información:
Las guías originales en Biblioratos
Los FAX en el Archivo General
Las BD de Hoteles en la computadora

Es decir que cada subsistema está a su vez formado por subsistemas menores.
Esto sucede n veces en cada paso.
Cuando el profesional de Sistemas ANALIZA el sistema debe conocer todos y cada uno
de los mínimos niveles de subsistemas para ALMACENAR información y cuando DISEÑA ,
debe hacerlo considerando todos y cada uno de los mínimos niveles de subsistemas para
ALMACENAR información.
¿Qué sucede con la información almacenada?
La tercera instancia es PROCESAR la información
La información de Hoteles almacenada en la Base de Datos correspondiente es
procesada en forma computacional con el fin de generar los listados de los distintos tipos de
paquetes de viaje que ofrece la empresa.

Facultad de Ingeniería (U.B.A.) Página 8

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I
El listado de paquetes de viaje es procesado por los empleados con el fin de: generar el
informe de Supervisión que es enviado al Dueño para su aprobación y obtener el listado con el
costo final de los paquetes de viajes, una vez que han sido adicionados los costos
correspondientes al Transporte.
La información de las Escuelas, almacenada en el bibliorato correspondiente, es
procesada, en forma manual, para obtener los listados de las Escuelas por zona de impacto.
Todo este proceso implica distintas formas de PROCESAR la información necesaria
para la Empresa Crecer. Al decidir la forma de procesar la información, se debe tener en
cuenta los siguientes factores: Tipo de tarea a realizar; Volumen de información a procesar;
Tiempo en que se necesita contar con la información y Controles a realizar.

Cuando se procesa la información de Hoteles en forma computacional se esta

realizando una secuencia lógica de pasos o algoritmos propia de dicho proceso.

Es probable que según la complejidad del proceso intervenga más de un algoritmo.

Estos algoritmos van a ser totalmente diferentes de los algoritmos que se desarrollan para
procesar manualmente la información que contiene el listado de los paquetes de viaje y la
información de las Escuelas.
Existen diferentes Subsistemas para PROCESAR información y el conjunto forma el
SISTEMA para PROCESAR información del Sistema de Ventas de la Empresa Crecer.

Para el subsistema procesar información de Hoteles, hay dos formas de elaborar la

información:

Secuencia de pasos ABC.

Secuencia de pasos YZ.

Es decir que cada subsistema esta a su vez formado por subsistemas menores.
Esto sucede n veces en cada paso.
Cuando el profesional de Sistemas ANALIZA debe conocer todos y cada uno de los
mínimos niveles de subsistemas (algoritmos) para PROCESAR información y cuando DISEÑA,
debe hacerlo considerando todos y cada uno de los mínimos niveles de subsistemas para
PROCESAR información.

Facultad de Ingeniería (U.B.A.) Página 9

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Subsistemas para Procesar

¿Qué se hace luego de procesar la información?

La cuarta instancia es DISTRIBUIR la información.
Los listados de las Escuelas se distribuyen a los vendedores de acuerdo a la zona
asignada a cada uno de ellos y también se les distribuye el material especifico de Ventas de
acuerdo a su categoría (Junior o Senior).
Los vendedores luego distribuyen la información en las Escuelas con la intención de
concretar la gestión de Ventas.
Todo este proceso implica diversas formas de DISTRIBUIR la información necesaria
para cerrar el circuito de la Empresa. Es importante mencionar que para distribuir información
es necesario considerar, hacia dónde se debe enviar (sección, departamento, etc.) y decidir
cuál es la manera más adecuada de presentar la información y que medio o canal de
distribución conviene utilizar.
Seguramente la forma de distribuir los listados de los Escuelas y material de promoción
a los vendedores implica utilizar un procedimiento interno propio de la mecánica de la empresa,
que es muy diferente al que utilizan los vendedores, aplicando las técnicas de comunicación
apropiadas para desarrollar su actividad.
Cada área tiene su propio Subsistema para DISTRIBUIR información y el conjunto
forma parte del SISTEMA para DISTRIBUIR información del Sistema de Ventas de la
Empresa Crecer.
Para el subsistema distribuir información de Hoteles, hay dos maneras de distribuir la
información: en forma interna, en forma externa

Es decir que cada subsistema está a su vez formado por subsistemas menores.

Facultad de Ingeniería (U.B.A.) Página 10

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I
Esto sucede n veces en cada caso.
Cuando el profesional de Sistemas ANALIZA el sistema debe conocer todos y cada uno
de los mínimos niveles de subsistemas para DISTRIBUIR información y cuando DISEÑA, debe
hacerlo considerando todos y cada uno de los mínimos niveles de subsistemas para
DISTRIBUIR información.

Subsistemas para Distribuir

SISTEMA DE INFORMACIÓN
Conjunto de subsistemas para recolectar, almacenar, procesar y distribuir
información para la planificación, decisión y señalamiento en un Sistema
Objeto (organización) del cual forma parte.

Facultad de Ingeniería (U.B.A.) Página 11

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

El sistema de información en la organización

Si analizamos el sistema de información de una organización, está compuesto por

sistemas de información que brindan información de distinto tipo: un sistema de información
de sueldos, un sistema de información contable, un sistema de información de proveedores, un
sistema de información de ventas, un sistema de información de producción, un sistema de
información de almacenes, si es institución educativa, tendrá un sistema de información de
personal, sistema de información de inscripción, sistema de información de títulos otorgados,
sistema de información de la condición de los alumnos, etc.

Subsistema
A

Subsistema
B

Sistema
de Información
de la
organización R

Subsistema
C

Subsistema
D

Subsistemas de recolección

Cada uno de estos sistemas de información se compone a su vez de sistemas para

recolectar y cada uno de los sistemas de recolectar es a su vez, un conjunto de subsistemas,
donde cada uno tiene una forma particular para recolectar información. Estos sistemas además
tienen relacionarse (integración de sistemas). Los datos que se recolectan en un subsistema
deben estar disponibles para cada subsistema que necesite utilizarlos, por esto los
subsistemas de información deberían estar relacionados entre sí. En una misma organización
no es necesario recolectar la misma información mas de una vez. Por lo tanto para analizar,
diseñar e implementar un sistema de información, es necesario conocer y diseñar los sistemas
para recolectar, y conocer y diseñar las interconexiones.

Facultad de Ingeniería (U.B.A.) Página 12

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Subsistema
A

Subsistema
B

Sistema
de Información
de la
organización R

Subsistema
C

Subsistema
D

Relaciones en subsistemas de recolección

Toda la información recolectada debe guardarse en un lugar específico y con un orden,

esto implica diferentes tipos de archivos. Además es posible que se definan bases de datos
para un subconjunto de la información recolectada, o según sea el caso puede ser que haya
que microfilmar la información (sistemas bancarios) en consecuencia existirán muchos
sistemas de archivos. También es necesario que los sistemas de almacenamiento estén
relacionados con el resto (integración de sistemas).
Almacenar entonces es una suma de subsistemas. Lo mismo que en el caso de los
sistemas para Recolectar, cada sistema de información (subsistemas) que conforman el
Sistema de Información de la organización tiene un sistema para almacenar información y cada
uno de estos subsistemas de Almacenamiento está conformado por un conjunto de
subsistemas que almacenan la información en medio y formas diferentes.

Facultad de Ingeniería (U.B.A.) Página 13

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

R
A
Subsistema
A

A
Subsistema
B

Sistema
de Información
de la
organización R
A
Subsistema
C

R
A
Subsistema
D

Subsistemas de almacenamiento
Los sistemas para almacenar se relacionan con los sistemas para recolectar. Los
sistemas de almacenamiento tienen que estar relacionados entre sí. Un sistema de recolección
puede abastecer a varios sistemas de almacenamiento y viceversa. De esta manera las
relaciones en un sistema integrado se multiplican considerablemente.

Facultad de Ingeniería (U.B.A.) Página 14

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

A
Subsistema
A

A
Subsistema
B

Sistema
de Información
de la
organización R
A
Subsistema
C

R
A
Subsistema
D

Relaciones en subsistemas de almacenamiento

Una vez Recolectados y Almacenados los datos / información queda entonces analizar y
definir cada uno de los procesos que es necesario realizar para obtener la información
esperada de cada sistema. O sea, es preciso definir los distintos algoritmos de procesamiento y
control (programas, procedimientos, reglamentos, normas, etc.) involucrados en cada uno de
los sistemas de la organización.
Esto implica un sinnúmero de subsistemas para procesar, e implica en términos de
integración y reusabilidad, definir todos y cada uno de los algoritmos que hay que llevar
adelante, considerando las relaciones entre ellos, para evitar repeticiones, como así también la
relación con los subsistemas de almacenamiento.

Facultad de Ingeniería (U.B.A.) Página 15

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

A
Subsistema
A
P

A
Subsistema
B
P
Sistema
de Información
de la
organización R
A
Subsistema
C
P

R
A
Subsistema
D
P

Subsistemas de procesamiento

Cuando se hace referencia a los sistemas de información y a sus subsistemas para

recolectar, almacenar y procesar no es únicamente respecto de la parte computacional sino
también a los procedimientos y subsistemas manuales. Así como hay un conjunto de
subsistemas para recolectar información manuales y sistemas de recolección por computadora,
lo mismo para los de almacenamiento y lo mismo para el procesamiento.
Los subsistemas de procesamiento están vinculados con sus sistemas de
almacenamiento. A su vez es esperable que los procesos estén vinculados entre sí, es decir
que un proceso puede recibir información de mas de un subsistema de almacenamiento y
viceversa. Sigue así creciendo y complicándose la red de relaciones.

Facultad de Ingeniería (U.B.A.) Página 16

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

R
D
A
Subsistema
A

A
Subsistema
B
D P
Sistema
de Información
de la
organización R
A
Subsistema
C
D P

R
A
Subsistema
D
D
P

Relaciones en subsistemas de procesamiento y subsistemas de distribución

Una vez que se cuenta con toda la información hay que distribuirla. . La distribución no es
trivial, ya que debe cumplirse en tiempo y forma para cada uno de los usuarios del sistema. De
la misma forma que la recolección, el almacenamiento y el procesamiento, los subsistemas de
distribución están compuestos por un conjunto de subsistemas que distribuyen la información
por distintos medios, formas y de distinta manera. Hay más de un subsistema de distribución y
deben estar relacionados con su propio sistema de procesamiento. Es necesario considerar las
vinculaciones tanto entre los subsistemas de distribución entre sí como respecto de la
posibilidad que cada subsistema de distribución reciba información de más de un subsistema
de procesamiento.
Las grandes fallas que perciben los usuarios de un sistema de información, es en aquellos
subsistemas con los cuales tienen mayor interacción, en la recolección y/o en la distribución.

Facultad de Ingeniería (U.B.A.) Página 17

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

A
Subsistema
A
P

A
Subsistema
B
P

Sistema D
de Información
de la
organización R

A
Subsistema
C
P

A
Subsistema
D
P

Sistemas de la organización y sus interrelaciones

La actividad entonces de un profesional de sistemas de información consiste en el

análisis, diseño y la implementación de todo el conjunto de subsistemas para recolectar,
almacenar, procesar y distribuir y todas las relaciones existentes entre ellos.

Facultad de Ingeniería (U.B.A.) Página 18

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Dato vs. Información

Lo que relaciona estos subsistemas (recolectar, almacenar, procesar y distribuir) son

datos y/ o información. Existen varias definiciones de lo que es dato y de lo que es información,
pero entre el conjunto de definiciones posibles la que se presenta es una de las mas claras y
no contradice otras definiciones existentes.
Se considera dato lo que ingresa al proceso para realizar su tarea y se considera
información a la salida resultante del proceso. Es decir es preciso considerar respecto de qué
proceso se hace mención, para poder definir con precisión si el concepto es dato o información.
La flecha entre el subsistema o proceso A y el subsistema o proceso B representa el mismo
contenido, que circula de A a B, pero si el punto de vista es el proceso A entonces se considera
información. Para el proceso B es dato.

Dato

Dato Subsistema A Información

Información
Dato

Subsistema B Información

Dato / información

La información resultante del procesamiento de datos ingresados para el subsistema A,

puede ser a su vez datos para otro subsistema B generando así información luego de haberlos
procesados.
Lo que relaciona a los subsistemas que componen un sistema de información, recolectar,
almacenar, procesar y distribuir son datos y/o información que circula entre ellos.

Facultad de Ingeniería (U.B.A.) Página 19

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

U
Unn ssiisstteemmaa ddee iinnffoorrm maacciióónn eess uunn ccoonnjjuunnttoo ddee ssuubbssiisstteem maass
ppaarraa rreeccoolleeccttaarr,, aallm a c e n a r, p ro c e s
macenar, procesar y distribuir a r y d i s t ri b u i r
ddaattooss oo iinnffoorrm maacciióónn
ccoonn eell oobbjjeettiivvoo ddee bbrriinnddaarr iinnffoorrm maacciióónn
ppaarraa qquuee uunnaa oorrggaanniizzaacciióónn ppuueeddaa
ppllaanniiffiiccaarr,, ddeecciiddiirr oo sseeññaallaarr..

Para cumplir con su actividad el profesional de sistemas tiene que analizar, entender,
diseñar, implementar y hacer que funcionen todos estos subsistemas y sus conexiones. Para
ello cuenta con Métodos, técnicas que permiten visualizar estas relaciones de manera precisa,
clara y ordenada.

Actividad del Profesional de Sistemas de Información

Los profesionales de cualquier disciplina se encargan de resolver problemas, cumpliendo

en general los siguientes pasos:

Análisis Situación Actual.

Diseño: Elaboración y Evaluación de Soluciones.
Implementación.

La diferencia que existe entre las distintas profesiones es: la porción del Universo sobre la
cual trabajan, es decir el Objeto de estudio.
En el caso de los Profesionales de Sistemas el objeto de estudio son los Sistemas de
Información.
La actividad del Profesional de Sistemas es realizar Análisis, Diseño e
Implementación de Sistemas de Información:

Análisis: estudiar el problema, la situación actual.

Diseño: hacer modelos de soluciones, de cómo va a funcionar eso en el futuro.
Implementación: esos modelos del diseño, ponerlos en funcionamiento y que el
sistema funcione.

Facultad de Ingeniería (U.B.A.) Página 20

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Análisis, Diseño e Implementación de SI

Teoría general de sistemas
Metodología para análisis y diseño
Fases / Etapas

Técnicas

Para obtener información

Para documentar información

Análisis, Diseño e Implementación

El profesional de sistemas tiene dos herramientas para trabajar:

1. La teoría general de sistemas, es una filosofía de trabajo, de visión, de análisis y
conocimiento. La teoría general de sistemas propone: si existe un problema a resolver,
la focalización inicial debe ser entender cual es el entrono donde el problema vive en
lugar de estudiar el problema en detalle. Este entorno es parte de un universo y
contiene elementos que interactúan con el sistema. La teoría general de sistemas
propone: estudiar los elementos que están dentro del sistema y su comportamiento y
las relaciones que hay con los elementos del entorno de interés. La visión fundamental
de esta teoría es que el problema lo voy a entender en tanto y en cuanto entienda este
entorno. No hay un problema que tenga una solución típica, si no que en general ese
problema va a depender de ese entorno. El problema es parte del estudio porque es
parte de los elementos del sistema, que se ha definido. Otra postura conocida como
enfoque lineal se basa en conocer todos los detalles del problema y sus relaciones
causales. El enfoque sistémico incluye el enfoque lineal y lo enriquece y amplia por lo
que el análisis tiene una mejor calidad.

2. Una metodología de trabajo: que se conoce como metodología para el análisis y

diseño de sistemas de información. Esta metodología básicamente tiene:
Fases o etapas (Ciclo de vida).
Técnicas para:
Obtener información
Documentar información

Todos los sistemas de información están conformados por componentes estructurales:

datos, procesos, controles, entradas, salidas, modelos, tecnología. A estos componentes
se le suman los requerimientos: de sistemas, de procesamiento de datos, de integración,
de costo y eficacia, de factibilidad. También se suman variables del negocio como:
capacidad competitiva, calidad y utilidad de la información, factores organizacionales,
factores humanos. Todos estos elementos no hacen un sistema de información a menos
que conformen una unidad con un propósito determinado. La tarea de desarrollar un
sistema de información es emprendida por los profesionales de sistemas que emplean
una metodología de desarrollo de sistemas, como el camino para realizar su trabajo. La

Facultad de Ingeniería (U.B.A.) Página 21

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I
metodología es una guía o detalle de actividades. Las metodologías pueden ser de
distinto tipo, a esos tipos se los conoce como ciclos de vida.

Existen varios tipos de ciclos de vida lo que es natural ya que existe también una gran
variedad de aplicaciones para las cuales se construyen productos software con diversas
características particulares. Las técnicas y metodologías de desarrollo de sistemas se
confunden con frecuencia con el ciclo de vida. El propósito del ciclo de vida es planear,
ejecutar y controlar el proyecto de desarrollo de un sistema. El ciclo de vida define las
fases y las tareas esenciales para el desarrollo de sistemas, sin importar el tipo o la
envergadura del sistema que se intenta construir. Por ejemplo, siempre se debe estudiar
y analizar el sistema actual (en el grado de detalle adecuado) antes de definir las
necesidades de los usuarios y fijar las prioridades.

Una metodología es una versión particular e individual de un ciclo de vida completo para
el desarrollo de sistemas que incluye:

Tareas paso a paso para cada fase. Determina el orden de las fases del
proceso software.
Funciones desempeñadas en cada tarea.
Productos resultantes y normas de calidad para cada tarea.
Técnicas de desarrollo que se utilizarán en cada tarea.

Una auténtica metodología debe acompañar al ciclo de vida completo del desarrollo de
sistemas. La mayor parte de las metodologías modernas incluye el uso de varias
técnicas de desarrollo con sus herramientas asociadas. Una técnica es un método que
aplica herramientas y reglas específicas para completar una o más actividades del ciclo
de vida del desarrollo de sistemas. Las técnicas en su mayoría son solo aplicables a una
parte del ciclo de vida. Por ejemplo la programación estructurada es una técnica
aplicable a las fases de codificación y soporte de sistemas. No da apoyo a las fases de
planificación, análisis o diseño. Por lo tanto es necesario combinar la programación
estructurada con otras técnicas de desarrollo para cubrir todas las fases del ciclo de vida.

Independientemente del número o nombres de las fases del ciclo de vida, éste
racionaliza y asigna una rutina al proceso de construcción de sistemas de información.
La meta principal del ciclo de vida de sistemas es reducir los inicios falsos, reciclamiento
indebido y callejones sin salida. Además aumenta la probabilidad de que el sistema que
se construya e instale finalmente, sea el que los usuarios desean y necesitan. Entre los
distintos tipos de ciclos de vida se destacan el cascada, prototipado, emisión gradual,
espiral, orientado a objetos. El ingeniero en sistemas debe estudiar las características del
proyecto, seleccionar el modelo de ciclo de vida, la metodología y las técnicas que mejor
se adecuen para el desarrollo de esa aplicación en particular.

Facultad de Ingeniería (U.B.A.) Página 22

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Las técnicas para obtener información no son propias únicamente de sistemas, hay
muchas profesiones que utilizan las mismas. Los profesionales de sistemas tiene como
objetivo obtener información sobre los requerimientos y necesidades de información de los
usuarios que trabajan en la organización. Las técnicas más utilizadas y conocidas para
obtener información son:
Entrevistas
Encuesta o cuestionario
Algún tipo de censo
Estudio de la documentación existente
Observación personal

Las técnicas para documentar información, son varias, en su mayoría gráficas y están
asociadas a cada una de las etapas o actividades de las fases de la metodología.

La técnica de redacción de informes es una técnica de documentación que está

presente en casi todas las fases o etapas y permite documentar las actividades realizadas
usando las técnicas de cada etapa.

Fases
Para describir las actividades que realiza un profesional de sistemas, se ha tomado como
base uno de los ciclos de vida más sencillo, que es secuencial (lo que facilita la comprensión de la
tarea), conocido como ciclo de vida en cascada. Mas adelante se completarán algunos
comentarios respecto de prototipos

Fases / Etapas

Requerimientos del sistema

C
o P Relevamiento
n l A
f P a u
Diseño lógico del sistema
i r n d
g u i i
u e f Diseño de la arquitectura t
r b i o
a a c r
Desarrollo o codificación
c s a í
i r a
ó Implementación
n
Mantenimiento
Fases / Etapas

Facultad de Ingeniería (U.B.A.) Página 23

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Análisis del Sistema

Según sea el autor o profesional, se considera Análisis del sistema a estas dos primeras
actividades, y todo lo que sea como funcionaria el sistema en el futuro se considera como parte
de la fase de Diseño. Esta es una visión mas conservadora y antigua.
Una visión mas actualizada considera dentro de la fase de Análisis tanto al estudio de la
situación actual de los sistemas de información, como al diseño del funcionamiento futuro del
sistema y se considera Diseño a partir del momento en que se definen especificaciones de
hardware o software de base.

Requerimientos del sistema (que se quiere hacer): Su propósito es analizar el problema o la

situación de la empresa y definir las necesidades con respecto a la creación o perfeccionamiento
de un sistema de información. La información de entrada posibles son:
Un plan de proyecto previsto en la fase de planificación estratégica / táctica
Un proyecto no planificado de desarrollo de aplicaciones (que responde a un
problema, una oportunidad o una norma imprevista)
Detalles y limitaciones de los sistemas existentes.
Hechos y necesidades relacionados con la empresa.
El producto de esta fase es un Informe de Requisitos en el que se detalla lo que precisan los
usuarios y no cómo se proyectan, diseñan o implementan dichas necesidades es posible incluir
técnicas para documentar información tales como:
Organigrama.
Diagrama de contexto.
Tabla de eventos.
Diagrama de Flujo de Datos de nivel 1 (en algunos casos)
Casos de uso.

En esta fase se especifican las necesidades de información de los sectores o puestos de trabajo.
También se especifican si hay necesidades de tipo normativas, de comunicaciones o
particularidades de hardware.

Relevamiento o estudio detallado es conocer como se opera actualmente en la organización y

permite definir la situación actual. En muchas ocasiones esta etapa se omite o no se realiza con
detalle. Puede suceder que se realice junto con la de requerimientos del sistema.

Consiste en el estudio del sistema actual de la empresa y establecer prioridades en las

necesidades de información manifestadas por los usuarios para la construcción del nuevo sistema
de información. Entre sus principales actividades está el estudio de la viabilidad del proyecto, el
estudio y modelado del actual sistema en funcionamiento, la ampliación de la definición de los
requisitos y establecimiento de prioridades y la especificación de las posibles alternativas de
solución. El proceso se centra especialmente en el dominio del problema a resolver. Para
comprender la naturaleza del sistema a construir el analista del software debe comprender el
dominio de información, la función requerida, el comportamiento, el rendimiento y la interconexión.

Facultad de Ingeniería (U.B.A.) Página 24

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Las entradas son el Plan del proyecto y el Informe de requerimientos. Las salidas son el Estudio
de viabilidad, y el Informe del sistema actual.
Las técnicas de documentación que se usan para modelar la situación actual y las necesidades
futuras, que además pueden formar parte del informe de relevamiento son:
Diagrama de Entidad Relación - Modelo de objetos o clases.
Diagrama de Flujo de Datos – Tabla de Eventos.
Asociada a estas dos técnicas está Diccionario de Datos y la Definición de Procesos
(Tablas de Decisión)
Pueden existir otras técnicas como ser Cursograma, es una técnica que se está
reemplazando por tipos de herramientas como WorkFlow.
Casos de uso extendidos.

Diseño lógico del sistema: El proceso de diseño traduce requisitos en una representación
centrada en la computadora que se pueda evaluar antes de que comience la generación de
código. El diseño de software es un proceso complejo que se centra en:
La estructura de los datos. Se definen archivos y bases de datos.
Los métodos y procedimientos de proceso (algoritmos).
Representaciones de interfaz. Diseño de entradas, salidas, pantallas.

Se modeliza el sistema de acuerdo a las técnicas que se utilizaron antes más

requerimientos para ello, con las modificaciones correspondientes:
Diagrama de Entidad Relación (como van a estructurarse los datos del sistema).
Normalización de Estructuras de Datos
Diagrama de Flujo de Datos (como van a ser los procesos del sistema).
Asociado al DFD la definición de procesos (para lo que se usa).
Tablas de decisión, asociado a ésta el lenguaje estructurado.
Cursogramas (WorkFlow: como va a ser la secuencia de los distintos trámites)

Diseño de arquitectura del sistema implica considerar el software de base y toda la instalación
de hardware que va a ser necesaria es decir, la estructura de la red informática.

Desarrollo o codificación: el diseño se debe traducir en una forma legible por la máquina. El
paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma
detallada, la generación de código se realiza con mayor facilidad. Esta fase puede incluir también
las actividades de construcción de las redes y ampliación de las bases de datos a usar por el
nuevo sistema. La entrada a esta fase son las Especificaciones de diseño. El resultado de esta
fase son los programas informáticos no instalados aún para producción. Aquí pueden usarse
técnicas como los:

Diagramas de árbol de módulos

Diagramas de flujo que muestran la lógica de los algoritmos del sistema
Definición de las bases de datos o archivos.

Facultad de Ingeniería (U.B.A.) Página 25

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I
Implementación: se desarrollan todas las actividades necesarias para poner operativo el
sistema desarrollado, retirar el sistema en uso (si lo hubiera) y capacitar a los usuarios.
Requiere tener en cuenta la necesidad o conveniencia de hacer un paralelo entre el sistema
que está actualmente en funcionamiento y el sistema a implementar
Las actividades consisten en procurar una transición suave entre el antiguo sistema y el nuevo,
ayudar a los usuarios a resolver los problemas normales de arranque, escribir manuales de
operación, cargar los archivos y las bases de datos.
Las entradas de esta fase son: el sistema instalado en la fase anterior, la documentación para
el usuario final, la formación del usuario final. La salida es el sistema de información en
producción.

Mantenimiento: Las causas que originan mantenimiento del software se pueden definir en:

1) Externas: son derivadas de necesidades no tomadas en cuenta en el origen del

sistema como:
(a) Nuevas leyes
(b) Nuevas normativas tanto dentro de la empresa como nacionales, provinciales,
etc.
(c) Nuevas legislaciones tanto dentro de la empresa como nacionales, provinciales,
etc.
(d) El usuario se vuelve más exigente y tiene nuevas solicitudes
(e) Evolución de plataformas tecnológicas, tanto software como hardware

2) Internas:
(a) Errores de desarrollo (sobre todo a comienzos de la fase desarrollo)
(b) Necesidad de actualizar el sistema que se ha quedado obsoleto

Resumiendo las principales causas

(a) Subsanar deficiencias de diseño
(b) Adaptación de nuevos requisitos y necesidades de los distintos usuarios
(c) Evolución de las plataformas tecnológicas

Existen distintos tipos de mantenimiento:

Correctivo: Abarca todas aquellas modificaciones que impliquen la corrección de un error.
Este error puede provenir de una mala codificación en el software así como de una
contradicción entre el funcionamiento del software y las especificaciones iniciales.
Adaptativo: Son las modificaciones llevadas a cabo como resultados de cambios
producidos en el entorno externo.
Perfectivo: Es la consecuencia de los cambios de los requisitos de los usuarios.
Preventivo: Puede ser entendido como la realización de mantenimiento anticipado a
problemas futuro.

Facultad de Ingeniería (U.B.A.) Página 26

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Fases integrales del proyecto

Existe un conjunto de fases que agrupan aquellas actividades que acompañan al proyecto
a lo largo de su desarrollo. Estas fases son:
Planificar
Pruebas
Configuración
Auditoria

Planificar

Una de las primeras y más importantes es planificar, esta etapa aparece con el planteo de
todo el plan de trabajo para hacer el desarrollo del sistema y de alguna manera se interconecta
con todas las etapas, ya sea para definir esa fase o realizar en mayor profundidad o para
efectuar el seguimiento. Las técnicas de planeamiento son usualmente:
Un Pert
Un Gantt
CPM

Técnicas
Para obtener información Entrevistas
Encuestas o cuestionarios
Censos
Estudio de la documentación existente
Observación personal

Para documentar información Organigrama

Diagrama de contexto (DC)
Tabla de eventos (TE)
Diagrama de flujo de datos (DFD)
Diagrama de Entidad-Relación (DER)
Definición de procesos
Diccionario de datos (DD)
Diseño de tablas de base de datos
Cursograma
Tabla de decisión
Lenguaje estructurado
Diagrama de flujos de algoritmos
Manual de usuario
Material para capacitación
Pert
Gantt
Caminos críticos (CPM)
Estudio de factibilidad
Pruebas de caja negra
Puebas de caja blanca

Técnicas

Facultad de Ingeniería (U.B.A.) Página 27

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Pruebas

Es importante que comience a considerarse desde el inicio. Existen distintos tipos:

Pruebas unitarias: El proceso de prueba se centra en los procesos lógicos internos del
software, asegurando que todas las sentencias estén probadas y en las funciones
externas, buscando que la entrada definida produzca resultados reales de acuerdo con
los resultados requeridos. Las pruebas de unidades aseguran que los programas de
aplicaciones funcionen de forma adecuada cuando se prueban de forma aislada con
respecto a otros programas de aplicación.
Pruebas de integración: se buscan errores en la interrelación entre los diferentes
componentes del sistema, o relación integral entre los subsistemas
Pruebas del sistema Las pruebas de sistemas aseguran que los programas de
aplicaciones escritos de forma aislada funcionen adecuadamente cuando se integran en
el sistema global. La entrada es la especificación de requerimientos del sistema.
Pruebas que se realizan en la implementación: Pruebas de usuarios, pruebas de control
de calidad, pruebas piloto.

La prueba del software es un elemento crítico para la garantía de calidad del software y
representa una revisión final de las especificaciones, del diseño y de la codificación. En cualquiera
de los tipos de pruebas es posible considerar distintos aspectos a probar, como ser: la
funcionalidad del programa, el volumen de transacciones y la concurrencia de las transacciones.
Las actividades básicas de un procedimiento de pruebas y la documentación de salida
correspondiente a cada una de estas actividades son las siguientes:

Actividades Salidas
I. Planificación de la prueba Plan de pruebas

II. Diseño de la prueba Documentación de diseño de

prueba
III. Determinación de los casos Especificación de los casos de
de prueba prueba
IV. Planificación del Especificación del procedimiento
procedimiento de prueba de prueba
V. Ejecución de la prueba Informe de los casos de prueba

VI. Análisis y evaluación de la Informe de la prueba

prueba

Facultad de Ingeniería (U.B.A.) Página 28

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Planificación de la prueba: En la documentación para la planificación de la prueba se deberá

indicar:

Objetivo de la prueba, detectar fallas,

Objetos a probar, funcionalidades, procesos, etc.,
Características a probar, dónde se probará, bajo qué entorno, etc.,
Características a no probar,
Método de prueba, el método utilizado en el desarrollo de la prueba,
Tamaño de la prueba, la cantidad de casos de prueba a realizar,
Recursos tecnológicos o máquinas. Recursos humanos, mínimo óptimo 3 personas
asignadas, un planificador, un diseñador y un testeador,
Reparto de responsabilidades, qué tareas tiene asignadas cada integrante,
Plan de tiempo, Diagrama de Gantt,
Productos a generar en el proceso de prueba, toda la documentación que tendrá la
prueba una vez finalizada.

Diseño de la prueba: En el diseño se deberá puntualizar con:

Cómo llevar adelante la prueba para alcanzar el objetivo establecido,
De qué forma se va a usar el método de prueba, brevemente qué método se utilizará y
qué probará ese método,
Criterios para pasar la prueba, es el punto más importante e indica qué escala
utilizaremos para determinar si algo pasa la prueba o no.

Determinación de los casos de prueba: Determinar puntualmente los casos de prueba, es decir,
enumerar uno a uno los casos de pruebas a probar, indicar el resultado correcto esperado al
realizar algún caso de prueba, pudiéndose utilizar una tabla de la siguiente forma:

Función a Básicamente
Valor a Resultado
probar Objetivo estas cuatro
ingresar esperado
(objeto) columnas

Planificación del procedimiento de prueba: Se especificarán los procedimientos que es

necesario seguir durante la ejecución de la prueba.

Ejecución de la prueba: Es en sí la ejecución de la prueba propiamente dicha, de acuerdo a la

planificación del procedimiento de prueba.

Función a Básicamente
Valor a Objetivo Resultado Resultado estas cinco
probar
ingresar <opcional> esperado obtenido columnas
(objeto)

Análisis y evaluación de la prueba: Se redactarán los informes necesarios sobre el resultado de

las pruebas. Cada integrante involucrado puede realizar informes de análisis y evaluación. Se
deberá indicar en forma clara y concisa los resultados de la prueba.

Facultad de Ingeniería (U.B.A.) Página 29

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Métodos de prueba

Los métodos de prueba proporcionan un mecanismo de ayuda para asegurar las pruebas
sean completas y para conseguir una mayor probabilidad de descubrir errores en el
software.
Principalmente los métodos de prueba se dividen en dos conjuntos, los que se basan en
revisar la codificación del software sin importar los datos de entrada o salida, y los que, por
el contrario, no les interesa la codificación sino los datos de entrada y salida del software.
Las primeras se denominan técnicas de caja blanca y las segundas técnicas de caja negra,
ambos tipos de técnicas son complementarias.

 Caja blanca  Codificación

¬ Estilo de codificación (Condiciones – Flujo
de datos – Bucles)
¬ Caminos independientes

Pruebas de  Caja negra  Funcionalidad (Entrada-Salida)

¬ Adivinación de errores
¬ Análisis de valores límite y clases de
equivalencia
(Análisis de valores de frontera)

Estilo de codificación: Se tiene en cuenta los parámetros para una buena codificación. La
prueba de condición es un método de diseño de casos de prueba que ejercita las condiciones
lógicas contenidas en el módulo de un programa. El método de prueba de flujo de datos
selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y
los usos de las variables del programa. La prueba de bucles se centra exclusivamente en la
validez de las construcciones de bucles, y éstos pueden ser: simples, concatenados, anidados y
no estructurados.

Adivinación de errores: Se supone qué resultados son los que podrían producir errores.

Análisis de valores límite y clases de equivalencia: Se ha desarrollado el análisis de valores

límite (AVL) debido a que los errores tienden a darse más frecuentemente en los límites del
campo de entrada que en “centro” del dominio.

Ejemplo: Para los AVL se debe elegir: 1 valor mayor y 1 valor menor

Para cada una de las clases de equivalencia (CE) se deben elegir:

Rangos: 1 caso correcto y 2 casos incorrectos
Lógicos: 1 caso válido y 1 caso inválido
Textos: 1 caso correcto y 2 casos incorrectos

Dado el siguiente procedimiento

Facultad de Ingeniería (U.B.A.) Página 30

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

CalcularMayor():
1: ingresar A, B
2: if A > B then
3: mostrar(“A es mayor”)
else
4: if A = B then
5: mostrar(“A y B son iguales”)
else
6: mostrar(“B es mayor”)
endif
7: endif

Diagrama de flujo

A, B

Sí
A>B

A es Sí
A=B
mayor

A y B son B es
iguales mayor

FIN

Teniendo en cuenta que tanto A como B son variables numéricas y tienen definido un
rango de: 1000 ≤ A ≤ 9999 y 1000 ≤ B ≤ 9999; se eligen los valores AVL y CE para A y B:

Valor A Valor B
AVL 10000 AVL 10000
999 999
CE 1234 CE 2345
A B
* $

Nro. A B Resultado Resultado

Facultad de Ingeniería (U.B.A.) Página 31
 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

esperado obtenido
1 10000 1234 “Mensaje de error”
2 999 1234 “Mensaje de error”
3 1234 1234 “A y B son iguales”
4 A 1234 “Mensaje de error”
5 * 1234 “Mensaje de error”
6 1234 10000 “Mensaje de error”
7 1234 999 “Mensaje de error”
8 1234 2345 “B es mayor”
9 1234 B “Mensaje de error”
10 1234 $ “Mensaje de error”

Caminos independientes: Permite garantizar que se ejerciten por lo menos una vez todos los
caminos independientes de cada módulo del sistema. Los pasos a seguir son los siguientes:

1. usando el diseño o código como base, se dibuja el correspondiente grafo de flujo,

2. se determina la complejidad ciclomática V(G) del grafo de flujo resultante,
3. se determina un conjunto básico de caminos linealmente independientes,
4. se preparan los casos de prueba que forzarán la ejecución de cada camino del conjunto.

Ejemplo:
1. Usando el diseño o código como base, se dibuja el correspondiente grafo de flujo.
1

R3
2

R1
3 4

5 R2 6

Facultad de Ingeniería (U.B.A.) Página 32

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

2. Se determina la complejidad ciclomática V(G) del grafo de flujo resultante.

Condiciones ⇒ Nodos predicados

V(G) = Cantidad de regiones

V(G) = Cantidad de nodos predicado + 1
V(G) = Cantidad de aristas – Cantidad de nodos predicado + 2

V(G) = 3
V(G) = 2 + 1 = 3
V(G) = 8 – 7 + 2 = 3

3. Se determina un conjunto básico de caminos linealmente independientes.

Caminos independientes:

Camino 1 => 1..2..3..7

Camino 2 => 1..2..4..5..7
Camino 3 => 1..2..4..6..7

4. Se preparan los casos de prueba que forzarán la ejecución de cada camino del
conjunto.

Configuración

En términos muy generales, la Gestión de Configuración del Software (GCS) se puede definir
como una disciplina cuya misión es controlar la evolución de un sistema software. La Gestión de
Configuración se debe realizar a lo largo de todo el ciclo de vida del producto, tanto en el
desarrollo como en el mantenimiento, hasta que el producto se retira.

El objetivo de las actividades de Gestión de Configuración del Software es:

establecer y mantener la integridad de los productos generados durante un proyecto
desarrollo de software y a lo largo de todo el ciclo de vida del producto.
evaluar y controlar los cambios sobre ellos, es decir, controlar la evolución del sistema
software.
facilitar la visibilidad sobre el producto.

La integridad de un producto software significa que el producto cumple las siguientes condiciones:

Satisface las necesidades del usuario (cumple todos los requisitos del usuario, tanto los
explícitos como los implícitos)
Cumple los requisitos de rendimiento
Se puede trazar su evolución desde que se concibió, y a través de todas las fases de su
ciclo de vida.

La definición estándar de Gestión de Configuración del Software, tal y como aparece en el

estándar de IEEE, incluye las siguientes actividades:

Identificación de la Configuración: Consiste en identificar la estructura del producto, sus

componentes y el tipo de estos, y en hacerlos únicos y accesibles de alguna forma. Esta
tarea consiste en identificar y asignar nombres significativos y consistentes a todos y cada
uno de los elementos que forman parte del producto software, en cada fase de su
desarrollo, es decir, a cada uno de los Elementos de Configuración del Software.

Facultad de Ingeniería (U.B.A.) Página 33

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I
Control de Cambios en la Configuración: Consiste en controlar las versiones y entregas de
un producto y los cambios que se producen en él a lo largo del ciclo de vida.
Generación de Informes de Estado: Consiste en informar acerca del estado de los
componentes de un producto y de las solicitudes de cambio, recogiendo estadísticas acerca
de la evolución del producto. El objetivo es mantener a los usuarios, a los gestores y a los
desarrolladores al tanto del estado de la configuración y su evolución. En definitiva,
pretende dar respuesta a la pregunta “¿Qué ocurrió?”, y también a la pregunta “¿Cuándo
ocurrió?”.
Auditoría de la Configuración: Consiste en validar la completitud de un producto y la
consistencia entre sus componentes, asegurando que el producto es lo que el usuario
quiere.

GESTION DE CONFIGURACION

IDENTIFICACION DE GENERACION DE

LA CONFIGURACION INFORMES DE ESTADO

CONTROL DE AUDITORIA DE

LA CONFIGURACION LA CONFIGURACION

Sin embargo, los sistemas que automatizan la gestión de configuración suelen incluir algunas
funciones adicionales:

Construcción: Consiste en gestionar la compilación y enlazado de los distintos

componentes del producto software de una forma lo más eficiente posible.
Control del Trabajo en Equipo: Consiste en controlar las interacciones que se producen
entre los múltiples desarrolladores de un producto, sobre todo cuando deben compartir
ciertos componentes del producto.
Control de Versiones: Consiste en mantener un registro histórico de las diferentes
versiones por las que pasan los componentes de un producto, que permita la
recuperación de cualquiera de ellas.
Gestión de Problemas: Consiste en realizar un seguimiento de la evolución de los
problemas que afectan al producto.

Cada vez resulta más evidente que las necesidades de Gestión de Configuración en una
organización grande, con aplicaciones software de larga vida, o que requieren del mantenimiento
simultáneo de múltiples versiones, son muy grandes, y a veces pueden resultar muy complejas.
Sin embargo, la mayor parte de las empresas de desarrollo de software, aún hoy en día, realizan
una Gestión de Configuración “bajo mínimos”.

¿Por qué es compleja la Gestión de Configuración? Se pueden encontrar varias respuestas a

esta pregunta:

Facultad de Ingeniería (U.B.A.) Página 34

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Número elevado de componentes a controlar: A medida que progresa el proceso de

desarrollo de Software el número de componentes crece rápidamente.
Pero el problema realmente surge porque en el proceso toma parte otra variable: el
CAMBIO. Sin importar en qué momento del ciclo de vida del sistema nos encontremos, el
sistema informático cambiará, y el deseo de cambiarlo persistirá a lo largo de todo el ciclo
de vida”.

Hay que asumir el cambio, no evitarlo. Es importante tener en cuenta que la mayoría de los
cambios están justificados, ya que a medida que pasa el tiempo se sabe más acerca del problema
y de cómo resolverlo. La Gestión de Configuración está también fuertemente relacionada con el
problema del mantenimiento del software. Sin una buena Gestión de Configuración, el
mantenimiento de un producto puede ser una verdadera pesadilla.

Elementos de Configuración

Al conjunto de toda la información y productos utilizados o producidos en un proyecto como

resultado del proceso de Ingeniería de Software se le denomina CONFIGURACIÓN DEL
SOFTWARE.

A cada uno de los componentes de la configuración del software se le va a llamar ELEMENTO DE

CONFIGURACIÓN DEL SOFTWARE (ECS). El ECS es la unidad de trabajo para la GCS. Se
pueden considerar como Elementos de Configuración del Software los siguientes componentes:
1. La especificación del sistema.
2. El plan del proyecto software.
3. La especificación de requisitos software.
4. Un prototipo, ejecutable o en papel.
5. El diseño preliminar.
6. El diseño detallado.
7. El código fuente.
8. Programas ejecutables.
9. El manual de usuario.
10. El manual de operación e instalación.
11. El plan de pruebas.
12. Los casos de prueba ejecutados y los resultados registrados.
13. Los estándares y procedimientos de ingeniería de software utilizados.
14. Los informes de problemas.
15. Las peticiones de mantenimiento.
16. Los productos hardware y software utilizados durante el desarrollo.
17. La documentación y manuales de los productos hardware y software utilizados durante
el desarrollo.
18. Diseños de bases de datos.
19. Contenidos de bases de datos.
etc.

A medida que progresa el proceso de desarrollo, el número de ECS crece rápidamente. La

Especificación del Sistema da lugar al Plan del Proyecto y a la Especificación de Requisitos
Software. A su vez estos dan lugar a otros documentos, etc. Si simplemente cada ECS produjera
otros ECS, no habría prácticamente confusión. El problema aparece cuando entra en juego la
variable CAMBIO.

Líneas base

Como ya hemos visto, uno de los objetivos principales de la Gestión de Configuración va a ser el
de gestionar los cambios que se producen en el sistema a lo largo de su ciclo de vida. Para

Facultad de Ingeniería (U.B.A.) Página 35

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I
controlar los cambios sin impedir los cambios justificados se utiliza el concepto de LÍNEA BASE o
“BASELINE”.
Se puede definir una línea base como un punto de referencia en el proceso de desarrollo del
software que queda marcado por la aprobación de uno o varios Elementos de Configuración del
Software, mediante una revisión técnica formal.
La idea consiste en permitir cambios rápidos e informales sobre un Elemento de Configuración del
Software antes de que se pase a formar parte de una línea base, pero en el momento en que se
establece una línea base se debe aplicar un procedimiento formal para evaluar y verificar cada
cambio.

El concepto clave para realizar esta actividad es el de Línea Base. Las líneas base se establecen
en hitos previamente especificados a lo largo del proceso de desarrollo. Aunque se pueden definir
las líneas base con cualquier nivel de detalle, las líneas base más comunes son:

Línea Base Funcional, que se establece al finalizar la fase de análisis y especificación de

los requisitos del sistema, y comprende todos aquellos documentos en los que se define el
problema a resolver, los costes del proyecto, el plan de tiempos, y los diferentes requisitos
funcionales, de interoperatividad y de interfaz del sistema.
Línea Base de Distribución o Asignación de funciones, que se establece al finalizar la fase
de análisis y especificación de requisitos software, y comprende toda la documentación que
gobernará el desarrollo de cada uno de los componentes software que se han identificado
en la especificación del sistema, y la asignación o reparto de las diferentes funciones entre
los distintos componentes del sistema
Línea Base de Diseño Preliminar, que se establece al finalizar la fase de diseño preliminar.
Comprende todos aquellos documentos en los que se define la arquitectura del producto
software, así como el Plan de Pruebas.
Línea Base de Diseño, que se establece al finalizar la fase de diseño detallado. Comprende
todos aquellos documentos que contienen el diseño detallado del software y el plan de
implementación, y también la descripción de los casos de prueba.
Línea Base de Producto, que se establece al finalizar la fase de pruebas. Comprende los
programas creados y todos aquellos documentos que contienen la información relativa a
las pruebas realizadas.
Línea Base de Operación, que se establece al finalizar la fase de implantación. Comprende
los manuales de usuario, guías de operación y mantenimiento, manuales de formación, etc.

Control de Cambios en la Configuración

Es la actividad de Gestión de Configuración más importante y su objetivo es proporcionar un

mecanismo riguroso para controlar los cambios, partiendo de la base de que los cambios se van a
producir. Normalmente combina procedimientos humanos y el uso de herramientas automáticas.

Se pueden considerar fundamentalmente dos tipos de cambios:

Corrección de un defecto: Los clientes tienden a clasificar todos los cambios en esta
categoría.
Mejora del sistema: Los programadores, sin embargo, los suelen clasificar aqui.

Facultad de Ingeniería (U.B.A.) Página 36

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Por lo general se establecen varios niveles de control de cambios:

Control de cambios informal: Antes de que el Elemento de Configuración del Software pase
a formar parte de una línea base, aquel que haya desarrollado el Elemento de
Configuración del Software podrá realizar cualquier cambio justificado sobre él.
Control de cambios al nivel del proyecto o semi-formal: Una vez que el Elemento de
Configuración del Software pasa la revisión técnica formal y se convierte en una línea base,
para que el encargado del desarrollo pueda realizar un cambio debe recibir la aprobación
de:
- El director del proyecto, si es un cambio local
- El Comité de Control de Cambios, si el cambio tiene algún impacto sobre
otros Elementos de Configuración del Software
Control de cambios formal: Se suele adoptar una vez que se empieza a comercializar el
producto, cuando se transfieren los ECS a la Biblioteca Maestra. Todo cambio deberá ser
aprobado por el Comité de Control de Cambios.

Las etapas típicas de un proceso formal, es decir, el proceso que habría que seguir para hacer un
cambio sobre una línea base:
1. Iniciación del Cambio: se presenta una solicitud de cambio, que puede venir provocada por
un problema que se ha detectado o por un cambio en los requisitos.
2. Clasificación y registro de la solicitud de cambio.
3. Aprobación o rechazo inicial de la solicitud de cambio. De ello suele ser responsable el
Comité de Control de Cambios .
4. Evaluación de la solicitud de cambio, si ha sido aprobada, para calcular el esfuerzo
técnico, los posibles efectos secundarios, el impacto global sobre otras funciones del
sistema y el coste estimado del cambio. Como resultado se obtiene un Informe de Cambio.
5. Se presenta el Informe de Cambio al Comité de Control de Cambios. Si se considera que
el cambio es beneficioso se genera una Orden de Cambio (también llamada Orden de
Cambio de Ingeniería), que describe el cambio a realizar, las restricciones que se deben
respetar y los criterios de revisión y de auditoría. Esta Orden de Cambio es asignada a
alguno de los ingenieros de software para que se encargue de llevarlo a cabo. En este
momento, el objeto a cambiar se da de baja en la Biblioteca de Soporte al Proyecto.
6. Se realiza el cambio, entrando en un proceso de seguimiento y control.
7. Una vez finalizado el cambio, se certifica, mediante una revisión, que se ha efectuado
correctamente el cambio y con ello se ha corregido el problema detectado o bien se han
satisfecho los requisitos modificados. El objeto se devuelve a la Biblioteca de Soporte al
Proyecto.
8. Se notifica el resultado al originador del cambio.

Facultad de Ingeniería (U.B.A.) Página 37

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Iniciacion del Cambio

Clasificacion y registro
de la solicitud de cambio

Aprobacion o rechazo
inicial del cambio

Evaluación del
impacto del cambio

Aprobacion o rechazo Almacenamiento

del cambio del cambio

Generacion de una
Orden de Cambio

Realizacion del cambio

Notificación al
Verificacion del cambio originador del cambio

Registros

Algunos ejemplos de los tipos de registros que pueden mantenerse son los siguientes:

a) Registro de elementos de configuración: Conteniendo toda la información relativa a los

diferentes elementos de configuración.
b) Registro de líneas base: Conteniendo toda la información relativa a cada línea base:
c) Registro de solicitudes de cambios: El tipo de información que se suele mantener acerca
de cada solicitud de cambio es la recogida a través del formulario de Solicitud de Cambio.
d) Registro de cambios: El tipo de información que se suele mantener acerca de cada cambio
es la recogida a través de el Informe de Cambio, la Orden de Cambio, el proceso de
Gestión de Problemas, etc.
e) Registro de modificaciones del código
f) Registro de modificaciones sobre bases de datos
g) Registro de modificaciones sobre documentación
h) Registro de instalaciones: Su objetivo es mantener información acerca de todos los lugares
en los que se ha instalado un producto software.
i) Actas de las reuniones del Comité de Control de Cambios

Facultad de Ingeniería (U.B.A.) Página 38

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Informes

En cuanto a los informes, podemos distinguir dos tipos:

- Planificados
- Bajo demanda

Algunos ejemplos de los tipos de informes que se pueden generar son:

a) Informe de estado de los cambios: Es un resumen del estado en que se encuentran todas
las solicitudes de cambio registradas durante un determinado período de tiempo.
b) Inventario de elementos de configuración, para ofrecer visibilidad sobre el contenido de las
bibliotecas de proyecto.
c) Informe de incidencias: Es un resumen del estado en que se encuentran todas las
incidencias originadas durante un determinado período de tiempo y las acciones a las que
han dado lugar.
d) Informe de modificaciones: Es un resumen de las modificaciones que se han efectuado en
el producto software durante un determinado período de tiempo.
e) Informe de diferencias entre versiones: Resumen de las diferencias entre las sucesivas
versiones de un elemento de configuración.

En cualquier caso, al comienzo de cada proyecto será necesario decidir qué tipo de registros se
van a mantener y qué tipo de informes se van a generar y para quién.

Auditoria de la Configuración

Una auditoría es una verificación independiente de un trabajo o del resultado de un trabajo o

grupo de trabajos para evaluar su conformidad respecto de especificaciones, estándares,
acuerdos contractuales u otros criterios. La auditoría de la Configuración es la forma de
comprobar que efectivamente el producto que se está construyendo es lo que pretende ser.
Se pueden diferenciar tres tipos de actividades:

Revisiones de fase: Se realizan al finalizar cada fase del desarrollo y su objetivo es

examinar los productos de dicha fase. Las revisiones propias de la Gestión de
configuración son aquellas en las que se establecerán las líneas base. El objetivo de
esta revisión es descubrir problemas, no comprobar que todo está bien. Hay que ser
capaz de desenmascarar los problemas ocultos y sutiles, no sólo los que son obvios.
Revisiones de cambios: Se realizan para comprobar que los cambios aprobados sobre
una línea base se han realizado correctamente.
Auditorías: Se realizan al final del proceso de desarrollo de software y su objetivo es
examinar el producto en su conjunto.

Las revisiones se deben realizar de forma continua, durante todo el proceso de desarrollo, y no
sólo al finalizar éste, cuando los problemas ya no tienen solución.

La tarea de revisión implica tres tipos de funciones:

Verificar que la configuración actual del software se corresponde con lo que era en fases
anteriores. Debe haber correspondencia y trazabilidad entre los elementos de configuración
que aparecen en una línea base y los que aparecen en las línea base que la preceden y
que la siguen. La verificación se realiza con respecto a la línea base precedente.
Validar que la configuración actual del software satisface la función que se esperaba del
producto en cada hito del proceso de desarrollo. La validación se realiza con respecto a los
requisitos del sistema.
Valorar si una determinada línea base, teniendo en cuenta los resultados de la verificación
y validación, y otro tipo de comprobaciones, se debe considerar aceptable o no.
Facultad de Ingeniería (U.B.A.) Página 39
 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

En cuanto a las auditorías, se suelen distinguir dos tipos de auditorías de configuración:

Auditoría Funcional: Cuyo objetivo es comprobar que se han completado todos los tests
necesarios para el Elemento de Configuración auditado, y que, teniendo en cuenta los
resultados obtenidos en los tests, se puede afirmar que el Elemento de Configuración
satisface los requisitos que se impusieron sobre él.
Auditoría Física: Cuyo objetivo es verificar la adecuación, completitud y precisión de la
documentación que constituye las líneas base de diseño y de producto. Se trata de
asegurar que representa el software que se ha codificado y probado. Tras la auditoría física
se establece la línea base de Producto. Tiene lugar inmediatamente después de haberse
superado la auditoría Funcional.
Revisión Formal de Certificación: Cuyo objetivo es certificar que el Elemento de
Configuración del Software se comporta correctamente una vez que éste se encuentra en
su entorno operativo.

Auditoria
La auditoría en informática es la revisión y evaluación de los controles, sistemas,
procedimientos de informática y de los equipos de cómputo, su utilización, eficiencia y seguridad,
a fin de que por medio del señalamiento de cursos alternativos se logre una utilización más
eficiente y segura de la información que servirá para una adecuada toma de decisiones.
La auditoría en informática deberá comprender no sólo la evaluación de los equipos de
cómputo o de un sistema o procedimiento específico, sino que además habrá de evaluar los
sistemas de información en general desde sus entradas, procedimientos, controles, archivos,
seguridad y obtención de información. Ello debe incluir los equipos de cómputo como la
herramienta que permite obtener la información adecuada y la organización específica
(departamento de cómputo, departamento de informática, etc.) que hará posible el uso de los
equipos de cómputo.
La auditoría informática es un examen, pues debe partir de una situación dada; éste es
metódico, puesto que seguirá un plan de trabajo perfectamente sistematizado que permite llegar a
conclusiones suficientemente justificadas (está es una conclusión exigible a cualquier auditoría);
es puntual ya que se da un corte en el calendario para llevarla a cabo, y es extraña al servicio de
informática, para obtener la objetividad requerida, por lo que será ejecutada por personas ajenas
al departamento independientes de las funciones a auditar.
El examen de una auditoría informática abarca una serie de controles, verificaciones,
juicios, etc. para concluir en un conjunto de recomendaciones y un plan de acción. Es la
elaboración de este plan de acción lo que diferencia la auditoría informática de una auditoría de
gestión. La auditoría tradicional concluye emitiendo un juicio del estado de todo aquello que se ha
verificado, la auditoría informática avanza un paso más y se atreve a elaborar un plan de acción.
Como se ve la evaluación a desarrollar para la realización de la auditoría en informática
deben hacerla personas con alto grado de conocimiento en informática y con mucha experiencia
en el área.

Facultad de Ingeniería (U.B.A.) Página 40

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Enfoque metodológico de la actividad profesional

Se quiere hacer notar que es absolutamente factible referirse a un Sistema de Información

en el que no participen elementos tecnológicos. No obstante es lógico suponer que el avance
de la tecnología y su relativa disminución de costos, tanto en el aspecto computacional como
en el de las comunicaciones, se han transformado en importantísimas herramientas que
puestas al servicio de los sistemas de información los potencian considerablemente.
En el mundo de los Sistemas de Información existe una problemática que afecta por igual
a los países del primer mundo y a los subdesarrollados, a las empresas multinacionales y a las
familiares, sean grandes o pequeñas, que se manifiestan a través de:
demoras en la iniciación de nuevos desarrollos,
dificultad de mantenimiento de los sistemas existentes,
relativa calidad de los productos obtenidos,
subaprovechamiento y subutilización de la tecnología existente en la empresa,
dificultad para adaptarse y adoptar nuevas tecnologías,
dificultad en la adaptación de recursos humanos,
frustración en la satisfacció0n de las expectativas y necesidades del usuario
frustración en la satisfacción de las expectativas de los profesionales de sistemas,
resolución de proyectos coyunturales versus la integrabilidad de los sistemas,
incumplimiento de los plazos originalmente previstos al planificar el proyecto.

Entre los factores que tienden a solucionar la problemática mencionada cobran

importancia relevante las distintas propuestas de METODOS y TECNICAS para el Análisis y
Diseño de Sistemas de Información.
Es interesante destacar que aún cuando cada método se “autodefine” como el mejor, el
único, el que soluciona lo que otros no solucionen, planteando un conjunto de etapas y
herramientas que “aseguran” rapidez y confiabilidad en la tarea, la realidad nos indica que ni la
cultura de la empresa, ni sus profesionales, pueden terminar de asimilar y poner en régimen
una metodología, junto a sus herramientas, cuando la “competencia” ya le está ofreciendo una
nueva alternativa, un software superador y descalificador del anterior.
Los interrogantes a nivel empresario son:
¿qué software para desarrollo comprar?,
¿cómo evaluar si la inversión a realizar es rentable?,
¿cuál CASE es el más conveniente?,
¿cuanto tiempo se debe invertir en la formación de los recursos humanos?,
¿qué hacer con los viejos sistemas?,

“No existe lo único, lo mejor para todas las situaciones ”

“ La compra de una herramienta CASE, en sí misma, no soluciona nada”
“La compra del CASE, y el aprendizaje del método es mejor,
pero tampoco por si solo alcanza”

Facultad de Ingeniería (U.B.A.) Página 41

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I
Los métodos y técnicas de Análisis y Diseño no son el único factor que concurre a la
solución de la problemática. Deben considerarse también las decisiones políticas, técnica,
económicas y la formación de los recursos humanos, tanto en lo que hace a los aspectos
técnicos como en la toma de conciencia de la importancia de la interacción de los distintos
grupos intervinientes que forman la organización.
El profesional de sistemas debe conocer las posibles herramientas disponibles y
desarrollar criterios para decidir cuál conviene aplicar según cada escenario. Es con esta
filosofía, la de adquirir habilidad en el uso y aplicación práctica de las herramientas existentes,
sin considerarlas como la única o la mejor sino como el conocimiento del potencial de cada una
de ellas, que debe emprenderse la actividad profesional.

Facultad de Ingeniería (U.B.A.) Página 42

 Sistemas Automáticos de Diagnóstico y Detección de Fallas I

Bibliografía

Bibliografía obligatoria

García Martínez, R; Britos, P.

Ingeniería de Sistemas Expertos. Editorial Nueva Era. 2004 (en prensa).

Bibliografía opcional

Brule, J. y Blount, A.
Knowledge Acquisition. McGraw Hill. 1989.

Debenham, J.
Knowledge System Design. Prentice Hall. 1989.

Greenwell, M.
Knowledge Engineering for Expert Systems. Ellis Horwood Limited. 1988.

García Martínez, R.
Guía : Sistemas de Inferencia dirigido por Patrones. Editado por CEI. 1995.

García Martínez, R.
Guía : Búsqueda. Editado por CEI. 1995.

García Martínez, R.
Guía : Ingeniería del Conocimiento. Editado por CEI. 1995.

García Martínez, R.
Guía : Introducción a los Sistemas Inteligentes. Editado por CEI. 1995.

Pazos Sierra, J.
Sistemas Expertos. Paraninfo. 1988.

Pazos Sierra, J. y Mate Hernández, J.

Ingeniería del Conocimiento. SEPA. 1988.

Gómez A, Juristo N, Montes C, Pazos J.

Ingeniería del Conocimiento. Editorial Centro de Estudios Ramón Areces 1988.

Facultad de Ingeniería (U.B.A.) Página 43