3.

Anlisis De Sistemas
Definicin De Anlisis De Sistemas
Dentro de las organizaciones, el Anlisis de Sistemas se refiere al
proceso de examinar la situacin de una empresa con el propsito de
mejorarla con mtodos y procedimientos ms adecuados, por
consiguiente, es el proceso de clasificacin e interpretacin de
hechos, diagnstico de problemas y empleo de la informacin para
recomendar mejoras al sistema.
Un Sistema "Es un conjunto de componentes que interaccionan entre
s para lograr un objetivo comn". La figura 2.1 muestra una
aplicacin de los conceptos de sistemas a una situacin familiar en
una organizacin, Observe la interrelaciones entre los elementos.
Esta caracterstica es importante para lograr la exitosa operacin de
los sistemas.

Figura 2.1 Elementos bsicos de control de un modelo de sistemas

Anlisis Del Modelo Funcional
En el modelo funcional, el objetivo de los analistas es el de identificar
y analizar las reas funcionales, funciones y actividades que se
realizan para llevar a cabo los objetivos de la empresa. Este tipo de
informacin constituye el punto de partida para la agrupacin
adecuada de la informacin que se emplear para construccin de los
modelos de datos.
Las tareas principales para llevar a cabo el anlisis del modelo
funcional son :
Identificar y analizar las reas funcionales

Identificar y analizar las funciones de cada rea funcional

Identificar y analizar las actividades de cada funcin
Revisar y analizar el modelo funcional con los ejecutivos de alto nivel
El modelo funcional es representado por un documento analtico que
muestra el conjunto de reas funcionales de la organizacin con sus
funciones y actividades el cual se puede representar de formas. La
primera forma consta de una tabla que contiene el nombre del rea
funcional con sus funciones y su respectiva actividad por funcin
La segunda forma de representar a un Modelo Funcional puede llevar
a cabo mediante un organigrama como se muestra en la figura 2.3.

Figura 2.3. Otras representaciones del Modelo Funcional

Existen unas formas para registrar e identificar las reas funcionales
"FORMA 0" (figura 2-4), Identificacin y registro de
Funciones/Actividades "FORMA 1" (figura 2-5), Identificacin y
registro de Documentos "FORMA 2" (figura 2-6), Registro de Campos
"FORMA 3" (figura 2-7).
Figura 2-4. Forma para
Figura 2-5. Forma para
Funciones/Actividades
Figura 2-6. Forma para
Figura 2-7. Forma para

identificacin y registro de reas Funcionales

identificacin y registro de
identificacin de Documentos
Registro de Campos

El Modelo Funcional sirve como base para el anlisis del Modelo de

Datos, porque del Modelo Funcional se extraen datos de acuerdo a las
actividades y funciones analizadas con el objetivo de obtener
informacin de :
o
o
o

Las formas y los reportes que se emplean

El origen y destino del reporte y documento
Las caractersticas de su uso

o
o

Los catlogos que se emplean en la elaboracin del

reporte
La descripcin y el formato de cada dato

Anlisis Del Modelo De Datos

Este modelo de datos es la base para sistemas con propsito de toma
de decisiones de la parte directiva y los mismos datos se aplican en
usos mltiples. Para este mtodo se deben tomar en cuenta
conceptos asociados con las bases de datos y los sistemas para su
manipulacin. Los diagramas de entidad-relacin y los diagramas de
estructuras de datos son herramientas de utilidad para el diseo y
poder llevar a cabo la aplicacin de este modelo.
Esta filosofa de diseo marca que los datos son el centro de
procesamiento de datos, en donde los datos son almacenados y
mantenidos con el apoyo de distintas transacciones, este
almacenamiento y mantenimiento es efectuado por un sistema
manejador de base de datos (DBMS: Data Base Manager System)
auxilindose de transacciones para la produccin de informacin, es
decir, existe una generacin de datos as como su actualizacin, este
modelo con los datos, el DBMS y las transacciones da como resultado
generacin de documentos, generacin de grficas, as como apoyo
en la toma de decisiones, auditorias y bsqueda de informacin.
Figura 2.8
Figura 2.8 Modelo de datos
Diagrama de Estructura de Datos
Esta tcnica considera a los datos independiente del procesamiento
que transforma los datos, esto no indica que se omitan. Esta
modelizacin de datos como su nombre lo indica modeliza datos sin
preocuparse por el procesamiento que se deba aplicar para
transformar los datos, siendo por tanto una tcnica complementaria
en donde se puede combinar con otro enfoque de modelo que se
haga cargo de la modelizacin que manipule aspectos de
procesamiento para un anlisis completo.
La modelizacin de datos es ampliamente en aplicaciones de bases de
datos. Esto proporciona un gran panorama para analistas y
diseadores de la base de datos una amplia visin de los datos y sus
relaciones. Los datos pueden ser entidades externas, cosas,
concurrencias, sucesos, papeles, estructuras o lugares. Por ejemplo:
En un plantel se cuenta con docentes y alumnos, los cuales pueden
ser tomados como datos puesto que estos contienen un conjunto de
atributos (Figura 2.9).
DATOS/ENTIDAD

ATRIBUTOS RELACIONES

Nombre del
plantel
Director
Telfono
Nmero de
Aulas
Nombre
RFC
Plaza
Horas frente
a grupo
Horas
comisionadas

Nmero de
Control
Nombre del
Alumno
Edad
Calificaciones
Grupo
Semestre
Figura 2.9 Entidades, Atributos y Relaciones
Los atributos de las entidades u objetos de datos se caracterizan por
3 aspectos :

Dar nombre a una creacin de entidad

Describir la entidad
Hacer referencia a otra creacin de otra tabla de atributos u/o
otra entidad

Adems de que se pueden utilizar uno o ms atributos para

relacionarse con otra entidad o entidades. Esto se puede llevar a cabo
utilizando un modelo relacional de los datos siendo la aplicacin sobre
tablas (Figura 2.10) en donde se muestran los atributos y su relacin
tomando en cuenta la optimizacin de relaciones redundantes. Estas
reglas de normalizacin son las siguientes :

Una entidad tiene un valor y slo un valor para cada atributo.

Los atributos representan la unidad mnima, es decir, no
contienen estructuras.
Cuando se utiliza ms de un atributo para identificar una
entidad, hay que asegurarse que estos atributos representen una
caractersticas completa de la entidad.
Todos los atributos que no sean identificadores deben
representar caractersticas de la entidad nombrada.

Figura 2.10 Las entidades representadas en tablas.

Carta de Entidades.
Para la modelizacin de datos se utiliza una notacin denominada
"Diagrama de Entidad-Relacin", siendo su propsito principal
representar a cada entidad y su relacin mostrando la clase de
informacin necesaria para satisfacer un requerimiento de
informacin. Su notacin es sencilla, las entidades se representan con
rectngulos etiquetados, las conexiones entre entidades se
representan mediante varias lneas de conexin con un formato
especial. (Figura 2-11)

Figura 2-11 Notacin de diagramas Entidad-Relacin

La modelizacin de datos y el diagrama de Entidad-Relacin se
convierten para el analista una notacin que produce resultados
concisos para ser examinados en el procesamiento de datos.
Carta de Burbujas.
Debido a que los datos se mueven a travs del sistema sufre
constantes modificaciones, los diagramas son tcnicas para
representar el flujo de la informacin desde la entrada, proceso,
hasta su salida.
El diagrama de Burbuja o diagrama de flujo de datos puede
representar un sistema a cualquier nivel de abstraccin
representando as un mayor flujo de informacin y un mejor detalle
funcional, el primer nivel o nivel 0 tambin denominado modelo
fundamental del sistema del cual se puede elaborar en subniveles
ms diagramas partiendo del nivel 0.
En los diagramas de burbuja la notacin que se usa para su creacin
consiste en un rectngulo el cual representa una entidad externa
(hardware, persona, otro programa, etc..) u otro sistema que genere
informacin a ser transformada por el software o sistema. El crculo
representa un proceso o transformacin aplicado a los datos, las
flechas utilizadas en el diagrama de burbuja indican el flujo y estas
deben estar acompaadas por una etiqueta. La doble lnea representa
almacenamiento de informacin que es utilizada por el sistema.
(Figura 2-13)
Figura 2-13. Notacin de un diagrama de burbuja bsico.
Cabe mencionar que el diagrama de burbuja no representa ninguna
informacin explcita de la secuencia de procesamiento, estando
implcitamente en el diagrama.
Esquema general del sistema.
Este tipo de diagrama muestra la operacin propuesta para el nuevo
sistema, en el cual se representan las transacciones manuales y las
transacciones automatizables, las cuales interactuan con la base de
datos.
Su notacin es simple utilizando rectngulos sencillos para indicar las
transacciones manuales y rectngulos dobles para indicar las
transacciones automatizables utilizando las flechas que indican la
direccin de la transaccin. (Figura 2.14)
Figura 2-14. Notacin para representar el Esquema General de un
Sistema

Mapa de Acceso Lgico

Este tipo de diagrama sirve para representar la secuencia del acceso
lgico de una transaccin a un modelo de datos, siendo su notacin
bsica similar a un Diagrama de Entidad-Relacin con la diferencia de
que en el Diagrama de Mapa de Acceso Lgico muestra unas lneas
que indican la direccin etiquetadas por el tipo de operacin que se
efecta, estas operaciones afectan a los datos como : lectura,
modificacin, borrado o agregar datos. Las entidades representadas
por un rectngulo van acompaadas en su parte exterior por los
atributos de cada entidad (Figura 2-15).

Figura 2-15. Ejemplo de un submodelo de datos extrado para el

diseo de la transaccin de admisin de pedidos.
Cabe mencionar que dentro de la nomenclatura bsica de un Mapa de
Acceso Lgico existe la aplicacin de condiciones representadas por
un punto etiquetado el cual establece una conexin, en el Mapa de
Acceso Lgico se agregar la etiqueta de condicin acompaada de la
descripcin de la condicin.
Diagrama de Accin
Es una representacin grfica de la utilizacin de los datos en las
transacciones, en donde se ubican las acciones que se efectan
seguidas por un rectngulo que contiene la entidad y las estructuras

de control (condiciones y estructuras de control repetitivas) Figura 216.

Figura 2-16 Ejemplo de un diagrama de accin para la transaccin de
admisin de pedidos.
El Diagrama de Accin tiene la funcin de indicar de una forma ms
clara la especificacin de las estructuras de control repetitivas y de
condicin, las cuales son especificadas en el Mapa de Acceso Lgico.
Su nomenclatura es simple. En la Figura 2-17 se ilustra los posibles
usos de las condiciones.
Figura 2-17. Notacin para indicar condiciones
En la Figura 2-18 se ilustra la notacin bsica para representar una
estructura de control repetitiva.
Figura 2-18. Notacin para indicar una estructura de control repetitiva
Miniespecificacin
La miniespecificacin es un listado de proposiciones en un lenguaje
parecido a cualquier lenguaje natural como el Espaol o el Ingls.
Cada una de estas proposiciones especifican un paso de transaccin o
Actividad en un Modelo Funcional o un proceso en un Diagrama de
Flujo de Datos.
Debido a que es una narrativa desarrollada con nuestras propias
palabras no existe una nomenclatura estricta a seguir. Por lo cual se
pueden aplicar palabras o frases comunes de nuestro lenguaje
cotidiano. Por ejemplo:
INICIO

RESTA

FIN

SUMA

SI/ENTONCES/FIN DEL SI

MULTIPLICA

SI/DE LO CONTRARIO

DIVIDE

ESCRIBE

ELIMINA

LEE

BORRA

MODIFICA

ACTUALIZA

REPITE HASTA / FIN DEL REPITE

SALIR
COMENTARIO

ENVA MENSAJE
CALCULA
+,*,-,/
La miniespecificacin nicamente lista actividades o transacciones de
una parte del sistema en donde se omite la especificacin de la
presentacin de la informacin visual en pantalla o impresora (color,
tipo de letra, posicin, cuadros, etc...) ya que se presenta a detalle la
transaccin, ms no aspectos secundarios, los cuales se describen en
formatos especiales como son : Formatos de Pantallas y Reportes
Formato de Pantalla y Reportes
La mayora de los sistemas en un anlisis requieren de una
planeacin de la forma en que se obtendrn los datos, as como la
forma en que el sistema presentar los resultados, es decir se
requiere de una planeacin de la distribucin de los atributos de las
entidades presentadas en pantalla y en papel.
Los formatos de pantalla van acompaados de una hoja de
especificacin de colores, su funcin es la de establecer una
estandarizacin en los colores que se aplicaran en las pantallas, en
donde adems cada color debe estar acompaado por una
descripcin que representa una accin en el sistema. Por ejemplo:
HOJA DE ESPECIFICACION DE
COLORES

Se utiliza para pantallas de

captura, modificaciones,
consultas y bajas

Indica un mensaje de error

enviado por el sistema

Pantallas de ayuda
(Cualquier tipo de ayuda)

Para aquellas pantallas

donde existan preguntas y
mens de barra iluminada
Para indicar la barra
iluminada de cada men

Los formatos de pantalla deben contener una escala para columnas y

filas que representen la cantidad mxima de filas y columnas (Por
ejemplo: si se est presentando el sistema en el modo texto, la
escala en los formatos debe ser de 80 columnas y 24 filas). El
formato de pantalla tambin debe contener una descripcin de los
campos que se aplican en la pantalla con su nombre, tipo y longitud
representando en la pantalla el espacio fsico que ocupara realmente.
Cabe mencionar que los campos de tipo carcter o alfanumricos se
representan por medio de una equis ("x") y los campos de tipo
numrico se representan por un nueve ("9") Figura 2-19.
PANTALLA : 1
OBJETIVO: Men principal de un sistema de horarios

1 10 20 30 40 50 60 70 80
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Descripcin
de Campos
(Nombre,
Tipo y
Longitud)

16
17
18
19
20
21
22
23
24
1 10 20 30 40 50 60 70 80
Figura 2-19. Ejemplo de un formato de pantalla
Los formatos de reporte sirven para indicar como se representar la
informacin producida por el sistema en hoja. Estos deben contener
una escala que representa la cantidad mxima de columnas de
acuerdo a la capacidad de la impresora que se utilizar o al tipo de
letra (Por ejemplo: podemos contar con una impresora de 10" de
matriz de puntos y en letra normal el espacio mximo ocupado ser
de 80 columnas, pero si utilizamos letra comprimida en la misma
impresora puede ocupar un mximo de 130 columnas). Los formatos
de reporte tambin van acompaados de una descripcin de campos
que indique su nombre, tipo y longitud. La informacin contenida en
cada campo al igual que los formatos de pantalla tambin se deben
representar fsicamente en el formato de reporte indicando con equis
("x") la longitud de los campos alfanumricos o de tipo carcter, con
nueves ("9") la longitud de los campos de tipo numrico (Figura 220).
REPORTE : 1
OBJETIVO: Reporte de horario de Aulas

1 10 20 30 40 50 60 70 80 90 100 110 120

Descripci
n de
Campos
(Nombre
, Tipo y
Longitud
)

1 10 20 30 40 50 60 70 80 90 100 110 120

Figura 2-20. Ejemplo de un formato de reporte
Los formatos de pantalla y los formatos de reporte deben ser tantos
como sea necesario ya que estos simplifican el trabajo en tiempo de
desarrollo. Es necesario agregar en ambos formatos un nmero y una
descripcin de su objetivo, por ejemplo : la pantalla nmero 1 su
objetivo es "men principal del sistema".
Otras tcnicas
Existen otras tcnicas de relevante importancia para documentar el
modelo de datos que tienen cierta similitud a tcnicas anteriores,
variando nicamente los propsitos de dicha tcnica:
Mapa de transacciones. Es relevante a una transaccin, a travs de
una tabla de referencias donde muestra las rutas utilizadas en
particular por dicha transaccin, en donde su objetivo principal es
hacer referencia al nmero de veces que los datos sufren una
transaccin o pasan por un proceso.
Mapa de uso combinado. Este documento se encarga de mostrar las
transacciones concurrentes contra el modelo de datos, y la carga con

la cual contribuye cada transaccin, a travs de cada ruta utilizada

(asociacin entre dos entidades), durante un perodo de
procesamiento seleccionado.
Mapa de carga compuesto. Muestra las transacciones concurrentes
contra el Modelo de Datos, y la carga con la cual contribuyen todas
las transacciones a travs de cada ruta utilizada (asociacin entre dos
entidades), durante un perodo de procesamiento seleccionado.
Matriz de Carga. Este documento de diseo es importante para ser
utilizado durante el diseo fsico de la base de datos; este sumariza la
carga total del sistema sobre la base de datos para aquellas
transacciones que se procesan concurrentemente durante su perodo
definido; totaliza el nmero de referencias lgicas contra la base de
datos para una transaccin sencilla y el nmero total para aquellas
transacciones procesadas durante un perodo.
Modelo Relacional. Diagrama que muestra el Modelo de Datos Lgico
convertido en Modelo Fsico, siendo su dependencia del tipo de
manejador de base de datos utilizado.
Anlisis De Transacciones
En muchos sistemas un elemento de datos es el motivo para
determinar uno o ms flujos de informacin, que afectan a la funcin
de acuerdo con el que determine dicho elemento de datos, a este
elemento se le denomina transaccin que desencadena otro flujo de
datos a travs de uno o varios caminos. En el caso de que suceda
esto en un Diagrama de Flujo de Datos se muestra como en la figura
2-21 denominado flujo de transaccin.
Figura 2-21. Flujo de Transaccin
Los pasos a seguir para manipular el flujo de transaccin tiene el
objetivo de transformar un diagrama de flujo de datos en la
estructura de un programa.
Revisin del modelo fundamental del sistema, que consiste en una
revisin del diagrama de flujo de datos iniciando del nivel 0 y el nivel
1 que describen la especificacin del sistema y la especificacin de
requisitos del sistema.
Refinar y revisar los diagramas de flujo de datos para el sistema,
siendo una revisin a detalle de los niveles 1 y 2 para detectar con
mayor posibilidad de xito un diagrama de flujo de transaccin.
Determinar si el diagrama de flujo de datos tiene caractersticas de
transformacin o de transaccin, en donde el diseador se encarga de
determinar si la caracterstica natural del diagrama de flujo de datos
pertenece a un flujo de transaccin de acuerdo a la figura 2-21.
Identificar el centro de transaccin y las caractersticas de cada
camino de accin, para detectar un flujo de transaccin cuando es el

origen de varios flujos de informacin que surgen de l, tratando de

aislar las burbujas. (Figura 2-22).
Figura 2.22. Establecimiento de divisiones de flujo
Transformar el diagrama de flujo de datos en una estructura
adecuada al procesamiento de transacciones, llevndose a cabo
creando subgrupos de burbujas a lo largo de un camino, as el flujo
de cada camino de accin del diagrama de flujo de datos se convierte
en una estructura con las caractersticas especficas de flujo. Las
correspondencias en la transaccin se ilustra en la figura 2-23.
Control de
Transaccin

Camino de
Recepcin
Figura 2-23. Correspondencias en la transaccin
Factorizar o Refinar la estructura de transacciones y la estructura de
cada camino aplicando reglas de diseo para mejorar la calidad. Para
factorizar se busca la mejor correspondencia entre los caminos,
tratando de no omitir ninguno de ellos puesto que ocasionara perdida
de una transaccin en el sistema conllevando a que este no cumpla
sus objetivos en su totalidad.
En el anlisis de transacciones la estructura del programa, en sus
mdulos pueden expandirse o reducirse con el objetivo de mejorar su
independencia, tomando en cuenta que la expansin de un mdulo se
divide en 2 o ms mdulos en la estructura de un programa final. Un
mdulo reducido es el resultado de la combinacin del procesamiento
involucrado en 2 o ms mdulos. Es necesario lograr una estructura
en donde los mdulos contengan varios niveles para una mejor
entrada/salida ya que esto indica varias capas de control y gran
aprovechamiento de recursos en los mdulos de niveles inferiores. Se
recomienda que la estructura sea como se muestra en la parte
derecha de la figura 2-24.
Figura 2-24. Niveles de Entrada/Salida

Se debe tomar en cuenta que cuando hablamos de mdulos, no solo

nos referimos a los niveles iniciales 0, 1 2 sino que tambin
hablamos de aquellos que conforman al sistema los cuales nos
muestran las transacciones en forma superficial, es decir, sin llegar al
cdigo al tipo de estructura de datos, uso de archivos, etc... Es por
ello que se recomienda evaluar las interfaces de los mdulos para
reducir la complejidad y la redundancia y as mejorar la consistencia
de los mdulos.
Una aplicacin correcta del anlisis de transacciones se complementa
documentando al anlisis realizando los siguientes pasos :

Desarrollar para cada mdulo, un texto explicativo del

procesamiento
Dar para cada mdulo una descripcin de la interfaz
Definir las estructuras de datos globales y locales
Anotar todas las restriccciones/limitaciones de diseo
Llevar a cabo una revisin del diseo preliminar registrando las
actualizaciones.
Algunos aspectos tpicos en las restricciones/limitaciones son el tipo
de formato de datos, limitaciones de memoria, valores o cantidades
lmites para las estructuras de datos as como caractersticas
especiales de un mdulo individual. Todo esto con el fin de reducir el
nmero de errores antes de llegar al diseo o con ello justificar que
no es viable su desarrollo. Las actividades de revisin se centran en
el seguimiento de los requisitos del sistema, la estructura del
programa, en las descripciones de las interfaces, descripcin de las
estructuras de datos, la descripcin de restricciones/limitaciones, en
la facilidad de implementacin y desarrollo de pruebas, y en la
facilidad de mantenimiento.
Anlisis Del Uso De Los Datos
A medida que la informacin se mueve a travs del software, est es
modificada por una serie de transformaciones. El diagrama de flujo de
datos (DFD) es una tcnica grfica que representa el flujo de la
informacin y las transformaciones que se aplican a los datos al
moverse desde la entrada hasta la salida, en la figura 2-25 se
muestra la forma bsica de un diagrama de flujo de datos. El DFD
tambin se le conoce como grafo de flujo de datos o como diagrama
de burbujas.
Figura 2-25 Modelo de flujo de informacin
Se puede utilizar un DFD para representar cualquier software a
cualquier nivel de abstraccin. En la figura 2-26 muestra la notacin
bsica que se usa para crear un diagrama de flujo de datos. El

rectngulo se utiliza para representar una unidad externa, es decir,

un elemento del sistema (Ejemplo: Hardware, personas, conjunto de
datos u otro programa) u otro sistema que produzca informacin a
ser transformada por el software o que reciba informacin producida
por el software. Un crculo representa un proceso o transformacin
que se aplica a los datos y los cambia de alguna manera. Todas las
flechas que aparezcan en un diagrama de flujo de datos deben ser
etiquetadas. La lnea doble representa un almacn de informacin,
Informacin almacenada que se utiliza por el software. La sencillez de
la notacin de un DFD es una de las razones por las que las tcnicas
de anlisis estructurado son ampliamente utilizadas.
Figura 2-26 Notacin DFD bsica.
El Diagrama de Flujo de Datos es una herramienta grfica que puede
ser valiosa durante el anlisis de requisitos del sistema. Cabe
mencionar que el diagrama no proporciona ninguna sencuencia
explcita de los procesos.
4. Desarrollo De Sistemas
Estrategias De Pruebas Del Software
La prueba es un proceso individualista y el nmero de tipos diferentes
de pruebas vara tanto como los diferentes enfoques de desarrollo,
una prueba es un conjunto de actividades que se puede planificar por
adelantado y llevar a cabo sistemticamente. Una estrategia de
prueba de software integra las tcnicas de diseo de casos de prueba
en un conjunto de pasos bien planeados que dan como resultado la
correcta construccin del software. Una estrategia de prueba de
software proporciona una gua o plano para los desarrolladores del
software (sistema), para la organizacin de control de calidad y para
el cliente -un plano que describe los pasos a llevar a cabo como parte
de la prueba, cuando se deben planificar y llevar a cabo su
realizacin, y cunto tiempo, esfuerzo y recursos se van a utilizar-.
Por tanto una estrategia de software debe incorporar la planificacin
de la prueba, el diseo de casos de prueba, la ejecucin de pruebas y
la agrupacin y evaluacin de los datos resultantes.
Prueba de unidad
La prueba de unidad centra el proceso de verificacin en la menor
unidad del diseo del software. Aqu se prueban los caminos de
control importantes, con el fin de descubrir errores dentro del mbito
de un mdulo.
La complejidad relativa de las pruebas y errores descubiertos se
encuentra limitada por los lineamientos establecidos por la prueba de
software. La pruebas unificadas dentro de la prueba de unidad estn
representadas en la figura 3-1

Figura 3-1 Prueba de Unidad

Se prueba la Interfaz del mdulo para asegurar que la informacin
fluye en forma adecuada hacia y desde la unidad del programa que
est siendo probada. Se analizan las estructuras de datos para
asegurar que los datos mantienen su integridad temporal durante
todos los pasos de ejecucin del algoritmo, Se prueba las condiciones
lmite para asegurar que el mdulo funciona correctamente dentro de
los lmites establecidos por el procesamiento. Se activan los caminos
bsicos de la estructura de control con el fin de asegurar de que las
sentencias del mdulo se ejecutan por lo menos una sola vez, y
finalmente, se prueban todos los caminos de manejo de errores.
Antes de iniciar cualquier otra prueba es preciso probar el flujo de los
datos del mdulo, ya que si los datos no entran correctamente, todas
las dems pruebas no tienen sentido. Myers, propone una lista de
comprobaciones para la prueba de interfaces 1:
Es igual el nmero de parmetros de entrada al nmero de
argumentos?
Coinciden las caractersticas (atributos) de los parmetros con los
argumentos?
Coinciden el sistema de unidades de los parmetros con el de los
argumentos?
Son correctos el nmero, atributos y el orden de los argumentos de
las funciones incorporadas?
Existen referencias o parmetros que no estn asociados con el
punto de entrada actual?
Entran slo argumentos alterados?
Son consistentes las definiciones de variables globales entre
mdulos?
Se pasan las restricciones como argumentos?
Cuando un mdulo tenga operaciones bsicas de Entrada/Salida
externa, se deben llevar a cabo pruebas adicionales :
Son correctos los atributos de los archivos?
Son correctas las sentencias de apertura?
Coinciden las especificaciones de formato con las sentencias de
Entrada/Salida?
Coincide el tamao del buffer con el tamao del registro?
Se abren los archivos antes de usarlos?
Se tienen en cuenta las condiciones de fin de archivo?
Se manejan errores de Entrada/Salida?
Hay algn error textual en la informacin de salida?
Las estructuras de datos locales de cada mdulo son una gran fuente
de errores. Se deben disear casos de prueba para descubrir
errores :

Tipificacin impropia o inconsistente

Inicializacin o valores implcitos errneos
Nombres de variables incorrectos (mal escritos o truncados)
Tipos de datos inconsistentes
Desbordamiento o errores en el direccionamiento de memoria
Se deben disear casos de prueba para detectar errores causados por
clculos incorrectos o flujos de control inapropiados. Las pruebas de
camino bsico o de ciclos son tcnicas ms efectivas para descubrir
una gran cantidad de errores en los caminos. Entre los errores ms
comunes en los clculos estn :

Procedencia aritmtica incorrecta mal aplicada

Operaciones de modo mixto
Inicializaciones incorrectas
Falta de precisin
Representacin incorrecta de una expresin
Las comparaciones y el flujo de control estn muy relacionadas,
es decir, el flujo de control cambia tras una comparacin
Los casos de prueba deben descubrir errores como :

Comparaciones entre tipos de datos distintos

Operadores lgicos o de procedencia incorrecta
Terminacin de ciclos inapropiada o inexistente
Falta de salida cuando se encuentra una iteracin mal aplicada
(Ciclos infinitos)
Variables internas a un ciclo modificadas en forma inadecuada.
Entre los errores que se deben comprobar se evala en la
manipulacin de errores lo siguiente :

La condicin de error hace que intervenga el sistema antes que

el mecanismo de errores
Descripcin ilegible del error
El error sealado no corresponde con el error encontrado
La descripcin del error no proporciona suficiente informacin
para ayudar en la localizacin de la causa del error.
La prueba de los lmites es la ltima etapa de la prueba de unidad y
quiz la ms importante. El software falla en sus condiciones lmite, o
sea, que frecuentemente aparece un error cuando se procesa el
elemento n-simo de un arreglo n-dimensional, cuando se hace la isima repeticin de un ciclo de x pasos o cuando se llega a los
valores mximo mnimo permitidos. Los casos de prueba que
ejerciten las estructuras de datos por debajo o encima de los mnimos
y mximos permitidos son apropiados para descubrir estos errores.

Normalmente, se considera a la prueba de unidad como algo

adyacente a al paso de la codificacin. En donde los casos de prueba
de unidad comienzan una vez que se ha desarrollado, revisado y
verificado en su sintaxis el cdigo a nivel fuente.
Prueba de integracin
Una vez que los mdulos funcionen por separado y hayan pasado la
prueba de unidad es necesario cuestionar lo siguiente : "El mdulo
funciona bien slo", Por qu dudar de que funcionen juntos?. Aqu
pueden surgir los problemas en la unin de los mdulos. Los datos se
pueden perder en una interfaz, un mdulo puede tener un efecto
adverso sobre otro mdulo; las subfunciones, cuando se combinan,
pueden no producir el objetivo principal deseado, las estructuras de
datos globales pueden presentar problemas.
La prueba de Integracin es una tcnica sistemtica para construir la
estructura del programa mientras que al mismo tiempo, se llevan a
cabo pruebas para detectar errores asociados con la interaccin. El
objetivo es tomar los mdulos probados en unidad y estructurar un
programa que est de acuerdo con lo que dicta el diseo.
Existen 2 tipos de integracin, la primera es no incremental en donde
se intenta elaborar software en mdulos grandes, en otros casos un
slo mdulo, pero en ellos es ms difcil aislar los errores y cuando
alguno de ellos es corregido produce otros errores. El segundo tipo de
integracin es incremental en donde se desarrollan mdulos
pequeos y funcionales que hacen que los errores sean ms fcil de
aislar y corregir, es ms probable que se puedan probar
completamente las interfaces y aplicar un enfoque de prueba
sistemtico.
Integracin descendente, es una estrategia de integracin
incremental a la construccin de la estructura de programas, en cual
se integran los mdulos movindose en direccin hacia abajo por la
jerarqua de control comenzando con el mdulo principal (Programa
principal). Los mdulos subordinados al mdulo de control principal
se incorpora en la estructura, bien, de forma primero-en-profundidad,
bien de forma primero-en-anchura representado en la figura 3-2
Figura 3-2 Integracin Descendente
De acuerdo a la figura 3-2 primero-en-profundida integra todos los
mdulos de una camino de control principal a la estructura, por
ejemplo: si se elige el camino a la izquierda se integrarn primero los
mdulos M1, M2, M5 y M8, enseguida se construyen los caminos de
control central y derecho. La integracin primero-en-anchura integra
todos los mdulos directamente subordinados a cada nivel
desplazndose en la estructura en forma horizontal de acuerdo a la

figura 3-2 , en donde los primeros mdulos que se integran son M2,
M3 y M4, para el siguiente nivel M5, M6 y M7.
El proceso de integracin se lleva a cabo en 5 pasos :
Se usa el mdulo de control principal como conductor de prueba,
disponiendo de resguardos para todos los mdulos directamente
subordinados al mdulo de control principal.
Dependiendo del enfoque de integracin elegido (primero-en
profundidad o primero-en-anchura) se van sustituyendo los
resguardos subordinados cada uno por los mdulos reales.
Las pruebas se llevan a cabo cada vez que se integra un mdulo.
Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo
con el mdulo real.
Se hace una prueba de regresin, es decir, todas las pruebas
anteriores para asegurar que no se han introducido errores.
La estrategia descendente puede ocasionar algunos problemas. Uno
de ellos puede ser cuando se requiere un procesamiento de los
niveles ms bajos de la jerarqua para probar los niveles superiores.
El encargado de la prueba tiene 3 opciones :
Retrasar muchas de las pruebas hasta que los resguardos sean
reemplazados por mdulos reales.
Desarrollar resguardos que realicen funciones limitadas que simulen
los mdulos reales.
Integrar el software desde el fondo de la jerarqua hacia arriba.
Integracin Ascendente, es en donde la construccin del diseo
empieza de los mdulos ms bajos hacia arriba (Mdulo principal), el
procesamiento requerido de los mdulos subordinados siempre est
disponible y elimina la necesidad de resguardos. Una estrategia de
integracin ascendente puede ser implementada mediante los
siguientes pasos :
Se combinan los mdulos de bajo nivel en grupos que realicen una
subfuncin en el software.
Se escribe un programa de control de prueba para coordinar la
Entrada y Salida de los casos de prueba
Se prueba el grupo
Se eliminan los programas de control y se combinan los grupos
movindose hacia arriba por la estructura del programa
La integracin sigue el esquema mostrado en la figura 3-3 en donde
se combinan los grupos 1, 2 y 3, cada uno de ellos se somete a
prueba mediante un programa de control (ilustrado como bloque
punteado). Los mdulos de los grupos 1 y 2 son subordinados de Ma
y se eliminan los programas de control D1 y D2 y se conectan
directamente los grupos a Ma de manera similar se elimina el

programa de control D3 del grupo 3 quedando con el mdulo Mb

finalmente el mdulo Ma como el mdulo Mb se integran al mdulo
Mc y as sucesivamente.
Figura 3-3 Integracin Ascendente
La seleccin de una estrategia de integracin depende de las
caractersticas del software y, a veces, del plan del proyecto, en
algunos de los casos se puede combinar ambas estrategias.
Prueba de validacin y verificacin
Al conjunto de actividades que aseguran que el software implementa
correctamente una funcin especfica se denomina Verificacin. La
Validacin se refiere a un conjunto diferente de actividades que
aseguran que el software construido se ajusta a los requisitos y
necesidades del cliente. Boehm lo establece de otra forma :
Verificacin : "estamos construyendo el software correctamente?"
Validacin : "estamos construyendo el software correcto?"
La definicin de Verificacin y Validacin envuelve lo que se conoce
como calidad del software, en donde se puede ver representada como
un conjunto de bloques en la figura 3-4 Los mtodos de anlisis, de
diseo y de implementacin (codificacin) actan para mejorar la
calidad al proporcionar tcnicas continuas y resultados predecibles.
Las revisiones tcnicas formales ayudan (inspeccin) ayudan a
asegurar la calidad la calidad de los productos, a lo largo del proceso
la medicin y el control se aplican sobre cada elemento de una
configuracin del software. La prueba constituye un elemento
importante desde el que se puede evaluar la calidad y, de forma ms
prctica, descubrir los errores. Cabe mencionar que la prueba no se
debe contemplar como una red de seguridad. La aplicacin adecuada
de los mtodos y de las herramientas, las revisiones tcnicas
formales efectivas y una slida gestin y medida, conducen a la
calidad, que se confirma durante la prueba.
Figura 3-4 Obtencin de calidad del software
Miller relaciona la prueba del software con la garanta de calidad al
establecerse que "la motivacin subyacente de la prueba de
programas es confirmar la calidad del software con mtodos que se
puedan aplicar de forma econmica y efectiva, tanto en grandes
como pequeos sistemas".1
Es importante mencionar que la validacin y verificacin abarcan un
amplio rango de la calidad del software que incluyen revisiones
tcnicas formales, auditoras de configuracin y calidad, supervisin
de rendimiento, simulacin, estudio de viabilidad, revisin de la

documentacin, revisin de la base de datos, anlisis de algoritmos,

pruebas de desarrollo, prueba de calificacin y prueba de instalacin.
Una vez que se culmin la etapa de integracin se puede decir que el
software est completamente ensamblado, se han encontrado y
corregido errores de la interfaz y se puede comenzar una serie final
de pruebas del software. La prueba de validacin se logra cuando las
expectativas razonables del cliente su cumplen en donde incluyen la
especificacin de requisitos, documentos en donde se describen los
atributos del software que son visibles para el usuario, esta
informacin forma la base del enfoque a la prueba de validacin.
El procedimiento de prueba estar diseado para asegurar que se
satisfacen los requisitos funcionales, que se alcanzan todos los
requisitos de rendimiento, que la documentacin es correcta y que se
alcanzan otros requisitos tales como portabilidad, compatibilidad,
recuperacin de errores, facilidad de mantenimiento, etc...
Una vez que se procede con la prueba de validacin, puede darse una
de las dos condiciones :

Las caractersticas de funcionamiento o rendimiento estn de

acuerdo con las especificaciones y son aceptables
Se encuentra una desviacin de las especificaciones y se crea
una lista de deficiencias.
Cuando se construye el software para llevar a cabo la prueba de
validacin es casi imposible que el desarrollador pueda prever como
un cliente usar realmente el programa es por ello que se hace una
serie de pruebas de aceptacin que puede permitir que un cliente
valide todos los requisitos, se puede dar el caso de las pruebas alfa y
beta. La prueba alfa consiste en una prueba del software ejecutado
por el cliente estando presente el desarrollador para hacer las
anotaciones necesarias cuando los errores o las observaciones del
cliente sucedan. Las pruebas beta son versiones del software que los
desarrolladores lanzan antes de la versin final, esto es que se
realicen las pruebas si la presencia del desarrollador ni el equipo de
desarrollo para efectos de compatibilidad, portabilidad,
mantenimiento, etc.., As la prueba beta es una aplicacin en vivo del
software en un entorno diferente.
Prueba del sistema
En las tcnicas anteriores se mencionan algunas tcnicas de prueba
que se efectan durante el diseo del software, cabe mecionar que en
cada una de esas tcnicas sern el xito o fracaso para la integracin
del software en el sistema total. Un clsico problema de la prueba del
sistema es la delegacin de culpabilidad. Esto ocurre cuando se
descubre un error y cada uno de los creadores de cada elemento del

sistema echa la culpa del problema a los otros, para evitar esto se
debe prever y tomar medidas correctivas tomando en cuenta lo
siguiente :
Disear caminos de manejo de errores que prueben toda la
informacin procedente de otros elementos del sistema.
Llevar a cabo una serie de pruebas que simulen la presencia de datos
en mal estado o de otros posibles errores en la interfaz
del software.
Registrar los resultados de las pruebas como "evidencia" en el caso
de sealamientos informales.
Participar en la planificacin y diseo de las pruebas del sistema para
asegurarse de que el software es probado en forma adecuada.
La prueba del sistema se basa en otras tcnicas de prueba que hacen
ejercitar profundamente el sistema basado en computadora, aunque
la finalidad de cada prueba es distinta, sirven para verificar que se
hayan integrado correctamente cada uno de los elementos del
sistema :
Prueba de Recuperacin. Muchos sistemas basados en computadora
deben recuperarse de los fallos y resumir el procesamiento en
tiempos previamente especificados. La prueba de recuperacin es una
prueba que se hace al sistema forzando a que produzca fallas de
software de muchas maneras y verificando que la recuperacin se
lleve a cabo, ya sea automticamente o manual, tomando en cuenta
los recursos que se requieran para efectuar la recuperacin.
Prueba de Seguridad. Cualquier sistema basado en la computadora
que manipule informacin sensible o efecte acciones que pueden
perjudicar o beneficiar a los individuos es objeto de penetraciones
impropias o ilegales. La penetracin incluye una serie de actividades
como :
penetrar sistemas por joby
personas disgustadas que intentan penetran por

o
o
o
o

venganza
personas deshonestas que intentan penetrar para obtener
ganancias personales ilcitas
usuarios que intentan penetrar para solucionar
problemas, desconociendo las consecuencias que esto pueda traer a
la integridad del sistema.
La prueba de seguridad intenta verificar la aplicacin de los
mecanismos de proteccin incorporados en el sistema. Durante la
prueba el encargado de la prueba desempea el papel de intruso
tratando de violar la seguridad del sistema, intentando obtener las
claves de acceso por cualquier medio externo; debe bloquear el

sistema, negando as el servicio a otras personas adems de producir

errores a propsito en el sistema; o debe curiosear los datos pblicos
intentando encontrar una clave de acceso al sistema.
Prueba de Resistencia. La prueba de resistencia est diseada para
enfrentar a los programas en situaciones anormales, es decir ejecutar
el sistema en forma que demande recursos en cantidad, frecuencia o
volmenes anormales. El encargado de la prueba debe intentar tirar
el sistema. Para lograr esto se puede tomar en consideracin lo
siguiente :
o
o

o
o

Disear pruebas especiales que generen 10 o ms

interrupciones por segundo.
Incrementar las frecuencias de datos de entrada en un
orden de magnitud con el fin de comprobar como responden las
funciones de entrada.
Ejecutar casos de prueba que requieran al mximo de
memoria o de espacio en disco.
Disear casos de prueba que produzcan excesivas
bsquedas de datos almacenados en disco.
Depuracin
La depuracin aparece como resultado de una prueba efectiva, es
decir, cuando en un caso de prueba se encuentra un error, la
depuracin es el proceso que resulta en la eliminacin de un error. Se
debe tomar en cuenta que la depuracin no es una tcnica de prueba,
aunque siempre se da como consecuencia de la prueba. De acuerdo
con la figura 3-5 el proceso de depuracin comienza en los casos de
prueba, se evalan los resultados y resulta una falta de
correspondencia entre los esperados y los reales, el proceso de
depuracin intenta hacer corresponder el sistema con una causa,
llevando as a la correccin del error.

Fig. 3-5 Depuracin

El proceso de depuracin siempre tiene uno de los dos resultados :
Se encuentra el error, se corrige y elimina
no se encuentra la causa del error
En el ltimo caso es cuando la persona encargada de la depuracin
debe sospechar la causa, en donde debe disear casos de prueba que
ayuden a confirmar sus sospechas y el trabajo se regresa a la
correccin del error de una forma interactiva.
La depuracin tiene como objetivo principal encontrar y corregir la
causa de un error en el software, existen 3 enfoques que se pueden
proponer en la depuracin1
Eliminacin de causas
Fuerza Bruta
Vuelta atrs
La categora de depuracin "eliminacin de causas" se manifiesta
mediante induccin o deduccin. Los datos relacionados con la
ocurrencia del error se organizan para llegar a las posibles causas; se
desarrolla una lista de las causas y se llevan a cabo las pruebas para
eliminar cada una.
La categora de depuracin por "fuerza bruta" es la categora
probablemente la ms comn y la menos eficiente en el momento de

aislar la causa del error del software en donde se confa que en algn
lugar de la gran cantidad de informacin producida nos puede llevar
finalmente al xito, lo ms frecuente es que se desperdicie tiempo y
esfuerzo.
La vuelta atrs es el enfoque ms normal para la depuracin, que se
puede usar con gran xito en programas pequeos. Partiendo de
donde se detecta el error hacia atrs en el cdigo fuente hasta llegar
a la posicin del error.
Cada uno de los enfoques anteriores puede complementarse con
herramientas de depuracin, ayudas dinmicas de depuracin,
generadores automticos de casos de prueba, etc.. En general a
partir de una indicacin de un problema, la actividad de depuracin
debe rastrear la causa del error.
Mantenimiento Del Software
El mantenimiento de software, es mucho ms que una correccin de
errores; el mantenimiento se puede describir en tres actividades.
o
o
o

Mantenimiento correctivo
Mantenimiento adaptativo
Mantenimiento perfectivo

Mantenimiento correctivo, esta actividad del mantenimiento es debido

a que no es razonable que en la prueba de software se haya
descubierto los errores de un gran sistema de software. Durante el
uso de cualquier programa se encuentran errores y estos son
informados al personal de desarrollo. Este proceso incluye el
diagnstico y correccin de uno o ms errores.
La evolucin rpida tanto de hardware como de software genera
cambios en perifricos, sistemas operativos o nuevas versiones de los
anteriores en otros casos nuevas disposiciones nacionales (por
ejemplo en nuestro pas el cambio de moneda) hacen que algunos
sistemas no se adopten a la nueva tecnologa o las nuevas
disposiciones, por lo tanto una actividad que modifica al software
para que interaccione adecuadamente con su entorno cambiante, es
la del mantenimiento adaptativo.
La tercera actividad del mantenimiento se da cuando existe software
que tiene un gran xito. A medida que se utiliza el software algunos
usuarios hacen observaciones sobre recomendaciones para nuevas
posibilidades sobre modificaciones a las funciones ya existentes
sobre mejoras en general. Para satisfacer estas peticiones se lleva a
cabo el mantenimiento perfectivo siendo una actividad que genera un
mayor esfuerzo empleado en el mantenimiento de software.

Caractersticas del mantenimiento

Las actividades requeridas para cubrir la fase de mantenimiento
abarca dos aspectos importantes : mantenimiento estructurado y
mantenimiento no estructurado
El mantenimiento no estructurado, es cuando slo se dispone del
cdigo fuente como un elemento de configuracin empezndolo a
evaluar a menudo complicada por la pobre documentacin interna.
Las delicadas caractersticas, tales como las estructuras de datos,
variables globales, las interfaces del sistema, el rendimiento y/o
limitaciones del diseo, son difciles de descubrir y frecuentemente
mal interpretados.
Si existe una completa configuracin del software, la tarea del
mantenimiento comienza con la evaluacin de la documentacin del
diseo, se determinan las importantes caractersticas estructurales,
de rendimiento y de interfaz del software.
Se estudian las consecuencias de las correcciones o modificaciones
requeridas y se traza un plan de acciones, se modifica el diseo y
revisa. Se desarrolla el nuevo cdigo fuente sometindolo a las
pruebas del software haciendo las respectivas correcciones y se
vuelve a lanzar el software, a este suceso de actividades corresponde
al mantenimiento estructurado.
Con respecto al costo del mantenimiento del software algunas veces
genera insatisfaccin al cliente cuando una peticin o modificacin
aparentemente legitima no se puede atender en un tiempo razonable,
Disminucin de la calidad global del software debido a los errores
permanentes que se generan cuando se introducen cambios al
software en mantenimiento, utilizacin de muchos recursos humanos
del rea de mantenimiento para efectuar el mantenimiento.
La falta de control y disciplina en las actividades de desarrollo, casi
siempre se traduce en problemas para el mantenimiento del software
como los siguientes :
o

o
o
o
o

Frecuentemente es difcil seguir la evolucin del software

a travs de varias versiones ya que los cambios no estn
adecuadamente documentados.
Frecuentemente es imposible o difcil seguir el proceso
por el que se construy el software.
Generalmente es completamente difcil comprender un
programa "ajeno".
Ese personaje "ajeno", por lo regular, no se encuentra
cerca para que pueda explicar lo que hizo.
No existe una documentacin apropiada o est mal
preparada.

La mayora del software no ha sido diseado previendo el

cambio.
Estos problemas que se acaban de mencionar, en parte, se pueden
atribuir al gran nmero de programas actualmente existentes que
han sido desarrollados sin tener en cuenta una metodologa de
desarrollo.
Efectos secundarios del mantenimiento
La modificacin al software en los cdigos fuente es peligrosa.
Algunas veces hemos escuchado.."pero si todo lo que realic fue
cambiarle una sentencia", lamentablemente cada vez que se
introduce un cambio en un proceso lgico muy complejo, la
posibilidad del error aumenta.
FREEDMAN y WEINBERG 2 definen tres grandes categoras de efectos
secundarios del mantenimiento
Efectos secundarios sobre el cdigo. Con el hecho de realizar un
sencillo cambio sobre una sola sentencia puede a veces tener
resultados desastrosos. El cambio inadvertido de algn smbolo "."
";" muchas veces pueden acarrear problemas trgicos. En una
computadora nos comunicamos mediante el cdigo fuente en algn
lenguaje de programacin. Las posibilidades de efectos secundarios
abundan, aunque cada modificacin que se realice en el cdigo puede
regularmente inducir al error. Los siguientes cambios tienen mayor
probabilidad de inducir a error que otros :
o
o
o
o
o
o
o

Un subprograma eliminado o cambiado

Eliminacin modificacin de una sentencia o etiqueta
Eliminacin o modificacin de un identificador
Cambios para mejorar el rendimiento en ejecucin
Modificacin de apertura o cierre de archivos
Modificacin de operadores lgicos
Cambios sobre las pruebas lmite

Efectos secundarios sobre las bases de datos. Durante el

mantenimiento frecuentemente se hacen cambios sobre
determinados elementos de una estructura de datos o sobre la propia
estructura de datos. Los efectos secundarios sobre las bases de datos
regularmente suceden por las modificaciones sobre la estructura de la
informacin del software. Los siguientes cambios en los datos
producen efectos secundarios como :
o
o

Redefinicin de constantes locales o globales

Redefinicin de registros o archivos

o
o
o
o

Aumento o disminucin del tamao de los arreglos o de

las estructuras de datos de mayor orden
Modificacin de datos globales
Reiniciacin de indicadores de control o de punteros
Reorganizacin de argumentos de Entrada/Salida o de
subprogramas

Los efectos secundarios se pueden limitar mediante una profunda

documentacin de diseo que describa las estructuras de datos y d
una referencia que asocie los elementos de datos, los registros, los
archivos y otras estructuras a los mdulos del software.
Efectos secundarios sobre la documentacin. El mantenimiento que
se efecta en el software se debe centrar en la completa
configuracin del software, no solo las modificaciones que se efectan
en el cdigo fuente. Los efectos secundarios en la documentacin es
debido a que no se reflejan las modificaciones hechas en el cdigo
fuente sobre la documentacin respectiva, no llevando a cabo un
registro u/o actualizacin de los cdigos fuente modificados.
Siempre que se realice una modificacin sobre el flujo de datos, sobre
la arquitectura de diseo sobre los procedimientos (mdulos) o sobre
cualquier otra caracterstica asociada, se debe actualizar la
informacin tcnica soporte, la documentacin actual no se reflejar
en su totalidad en el software pero puede ser peor la ausencia total
de este tipo de documentacin.
5. Implantacin
Conversin
La conversin consiste en el cambio del sistema anterior con el
sistema nuevo, as como los mtodos para llevarla a cabo y
verificacin de que la conversin se haya efectuado correctamente.
Existen cuatro mtodos para efectuar una conversin en un sistema,
en donde cada mtodo tiene ventajas y desventajas entre los
mismos. Es conveniente mencionar que algunos mtodos de
conversin se ajustan perfectamente a problemas planteados, en
donde nos es conveniente aplicar otro mtodo debido a que los
posibles resultados sean ampliar los periodos de conversin, situacin
que puede crear problemas con los usuarios y los analistas.
Sistemas paralelos
Este mtodo es un modelo seguro, ya que el sistema nuevo funciona
al mismo tiempo que el sistema anterior; debido a que si encuentran
fallas en el sistema nuevo, el anterior permanece en constante
funcionamiento sin perdidas de tiempo, ni de informacin. Una
desventaja muy notable es que este mtodo de conversin es muy
costoso ya que se duplican los recursos humanos como materiales

para trabajar en forma paralela ambos sistemas duplicando as los

costos de operacin.
Conversin directa
El sistema anterior ser reemplazado por el nuevo sistema, ya que la
organizacin confa plenamente en el nuevo sistema. Obligando as a
los usuarios a que hagan funcionar al nuevo sistema encontrando en
l nuevos mtodos y controles. En caso de encontrar errores no
existe un sistema que lleve un respaldo de seguridad en las
operaciones, este mtodo ocasiona una planeacin ms cuidadosa.
Enfoque piloto
En este mtodo se implanta el nuevo sistema en una parte de la
organizacin. Con base a retroalimentacin se hacen cambios y el
sistema se instala en el resto de la organizacin mediante algunos
otros mtodos, esto en gran medida proporciona experiencia y
prueba directa antes de la implantacin. Ocasionando la desventaja
de que el nuevo sistema puede dar la impresin de que el nuevo
sistema no es confiable, ni est libre de errores.
Conversin por etapas
Se implanta el nuevo sistema de manera gradual, reemplazando
partes del sistema anterior, permitiendo a los primeros usuarios
aprovechar las ventajas del nuevo sistema, as como la capacitacin
de los mismos, llevando a cabo la instalacin de una nueva etapa una
vez que fue aceptada sin hacer uso necesario de recursos extras.
Plan De Conversin
El plan de conversin incluye una lista de actividades para llevar a
acabo la implantacin del nuevo sistema y ponerlo en operacin. En
l se identifica a las personas responsables de cada actividad, as
como un programa de actividades para dar seguimiento a cada una
de estas etapas.
El plan de conversin debe prevenir los posibles problemas y la forma
de enfrentarlos implementando planes de emergencia adecuados.
Algunos problemas que se presentan comnmente son :

Documentos perdidos
Variacin entre datos de los formatos nuevos y anteriores
Errores en la conversin de datos
Extravo de datos o prdida de archivos
Omisin en algunos pasos de la conversin
Durante la conversin se deben considerar diversos aspectos, desde
la instalacin del equipo hasta el orden de las formas y los
suministros. Algunas actividades de conversin comienzan realmente

desde que un sistema se est desarrollando, as como contactar

proveedores.
Acondicionamiento De Las Instalaciones
Frecuentemente los analistas trabajan con el personal de los
proveedores para definir el acondicionamiento de las instalaciones. El
cliente o el ingeniero de sistemas presentar una lista de
especificaciones para el cableado elctrico y los contactos,
necesidades de aire acondicionado, controles de humedad y
exigencias de espacio, lo ms recomendable es tener el local antes de
la llegada del equipo.
Capacitacin De Operadores Y Usuarios Para Operar El Sistema
En algunos casos los sistemas de las compaas de ms prestigio
pueden tener xito o fracasar debido a la forma en que se operan y
se usan. Como consecuencia la calidad de capacitacin recibida por el
personal manipular el sistema ayuda u obstruye, y puede llegar a
impedir, la implantacin exitosa de un sistema de informacin.
Aquellas personas que se encuentren asociadas o afectadas por el
sistema deben conocer cul es su papel, cmo pueden usar el
sistema y qu har o no har el sistema. Tanto operadores como los
usuarios del sistema requieren de capacitacin.
Capacitacin de operadores
La mayora de los sistemas dependen del personal de Centro de
Cmputo, el cual es el encargado de mantener los equipos de
cmputo funcionando, as como de proporcionar el apoyo necesario.
La capacitacin que el personal reciba debe de asegurar que puedan
manejar todas las operaciones posibles, tanto rutinarias como
extraordinarias. La capacitacin que reciba el operador tambin debe
contemplar al personal de captura de datos.
Si el sistema requiere de la instalacin de equipo nuevo, el personal
debe ser capacitado en lo necesario para encender y apagar el
equipo, as como conocimiento de lo que es su operacin y su uso
normal. Como parte de la capacitacin se le debe dar al personal una
lista de formas de resolver los problemas y que identifique los
posibles problemas y solucin, as como datos personales de las
personas a quin buscar cuando surjan problemas inesperados.
Capacitacin de usuarios
La capacitacin de usuarios incluye la identificacin de problemas,
determinando si el problema que surge es ocasionado por hardware o
por software, o por algo realizado por los mismos usuarios que
ocasione la falla del sistema.
No hay nada ms desesperante que trabajar con un sistema y que
suceda un problema y no ser capaz de determinar si es falla del

propio sistema, del equipo o de los usuarios. El lugar para prevenir

estos casos es durante la capacitacin. La mayor parte de la
capacitacin de los usuarios tiene que ver con la operacin del
sistema en s. La capacitacin en la codificacin de los datos marca la
pauta en el proceso de captura a partir de las transacciones, o en la
preparacin de datos necesarios para las actividades de apoyo a las
decisiones.
Las actividades de manipulacin de los datos que recibe la mayor
atencin en la capacitacin de usuarios son la captura de datos
(Cmo modificar datos previamente almacenados), la formulacin de
consultas (Cmo localizar informacin especfica u obtener respuestas
a preguntas) y el borrados de los registros de datos. La parte
fundamental de la capacitacin cae sobre esta actividad dedicndose
la mayor parte del tiempo a esta rea.
En algunos casos los usuarios tienen que tener conocimiento de la
operacin bsica de algunos perifricos tales como una impresora, en
donde deben tener el conocimiento de como colocar el papel
cambiar la cinta de la impresora, as como otros procesos rutinarios
como mantener limpio el equipo, y adems del conocimiento para la
manipulacin de los discos como es formatear y probar discos.
En la capacitacin de usuarios se debe tomar en cuenta dos aspectos
importantes mencionados anteriormente los cuales consisten en la
familiarizacin con el sistema de procesamiento en s (es decir, el
equipo usado para la captura y procesamiento de datos) y la
capacitacin en el uso de la aplicacin (es decir, el software que
acepta los datos, los procesa y produce los resultados). La debilidad
de cualquier aspecto de la capacitacin puede ser una posibilidad
para la generacin de errores. Una buena documentacin, aunque es
importante, no reemplaza la capacitacin.
Mtodos de capacitacin
La capacitacin a operadores y usuarios se puede manifestar de
diferentes formas. Las actividades de capacitacin se pueden llevar a
cabo en las instalaciones de los proveedores, locales rentados como
podra ser el caso de hoteles y Universidades, "en casa", o en las
instalaciones de la empresa. Los mtodos y contenido de la
capacitacin varia de acuerdo a la fuente y del lugar de la
capacitacin
Instalacin Y Pruebas Del Usuario Para Aceptacin Del Sistema
En la instalacin y prueba del usuario, son algunas actividades que
realiza el usuario con el fin de verificar el sistema si funciona con el
hardware diferente al hardware de desarrollo, as como su instalacin
y funcionamiento en general, en esta etapa se abarcan cuatro
aspectos importantes :

La prueba de entrada que implica ver si las formas electrnicas y las

de papel as como la estructura de codificacin cumplen con las guas
y especificaciones de diseo, tambin se hacen una autoprueba los
usuarios finales del sistema para saber si estn llenando
correctamente las formas. Al efectuar estas pruebas se supone que el
usuario ya recibi capacitacin y en ella se les enseo como llenar los
formatos. Las pruebas en esta etapa consisten en determinar si
fueron capacitados correctamente.
Muchas organizaciones contratan personas cuya nica funcin es
capturar datos siendo de gran importancia una capacitacin adecuada
para la captura de datos.
La prueba de salida, en la mayora de estas pruebas son un
subproducto de la prueba de otros componentes estructurales. Por
ejemplo, mientras se prueban la entrada y las bases de datos, se
revisa la utilidad y exactitud de la salida resultante.
Una prueba de salida no es otra cosa que la generacin de un
reporte, su entrega al usuario y determinar si satisface las
necesidades de informacin. Una buena forma de llevar a cabo la
prueba de salida consiste en entregar un reporte a una persona no
familiarizada con el sistema, si esta persona puede explicar el
reporte, entonces probablemente el formato puede ser entendido por
los usuarios.
Prueba de la base de datos. Las pruebas importantes para determinar
si las bases de datos satisfacen las necesidades de los usuarios, en
gran medida, es la prueba de salida. Sin embargo se pueden llevar a
cabo pruebas adicionales para asegurarse que las bases de datos
contengan la informacin que satisfaga todas las demandas que se le
plantean. Incluyendo pruebas tales como la creacin de un nuevo
registro antes del primer registro en el archivo maestro, la creacin
de un nuevo registro despus del ltimo, la creacin de un registro de
un departamento que no existe, intentar leer o escribir en un archivo
con el disco fuera de la unidad (en el caso de sistemas en unidades
flexibles).
Prueba de los controles. El propsito primordial de la prueba de
controles es asegurar que estos se encuentren en su lugar y trabajen
segn se plane. Las transacciones de prueba ayudan a asegurar que
los controles de procesamiento, como las verificaciones de lmite y
racionalidad, la prueba aritmtica y la identificacin estn en su lugar
funcionando correctamente. Algunas pruebas de control que
normalmente se realizan son :
o

Tratar de leer o escribir en un archivo incorrecto

Introducir varios campos con datos incompletos o

faltantes
o
o

Tratar de procesar una transaccin delicada sin la

autorizacin apropiada y ver si el sistema lo rechaza
Hacer verificaciones de caracteres numricos, alfabticos
y especiales, por ejemplo en la captura de una clave se debern
introducir nicamente valores numricos, en donde se deben
introducir valores alfabticos. Una verificacin que funcione
correctamente detectar el error antes de realizar el procesamiento.
Hacer verificaciones de lmite y racionalidad, por
ejemplo : Un docente no puede tener ms de 40 horas en una
jornada al da, se probar introduciendo valores que excedan la
jornada de un da
Realizar verificaciones de validez de campos clave, por
ejemplo : introducir una clave invlida y ver como responde el
sistema
Introducir en un campo numrico valores negativos y ver
si lo acepta como tal, o los efectos que ocasiona
Las pruebas de los controles incluyen tambin una revisin de la
documentacin que aparece en los reportes del desarrollo de
sistemas. Despus de que el usuario considera que el software paso
las pruebas, deber llevarse a cabo una reunin de aceptacin, a la
que asista el gerente de operaciones de sistemas, el analista de
sistemas y el personal usuario. En este momento se le da terminacin
oficial del proyecto de desarrollo obteniendo as la "clausura" final de
sistemas, es entonces cuando el equipo de desarrollo queda libre para
otra tarea o para disear o implementar algunas de las solicitudes y
sugerencias de mejora del sistema que fueron suspendidas
anteriormente.
6. Conclusiones
En el anlisis y desarrollo del sistema de horarios, he comprobado los
conocimientos adquiridos en mi Licenciatura con respecto a las
materias Administracin de Archivos, Ingeniera del Software y Bases
de Datos. As como ejercer y aplicar profesionalmente estos
conocimientos en el medio real.
He tenido la oportunidad de ejercer en el sector pblico, ofreciendo
mis conocimientos, as como tomando experiencias del medio real,
esto se vive cuando uno egresa de la Licenciatura, por ello considero
que durante mi carrera aprend, apliqu y comprob acadmica y
laboralmente mis estudios.
Adems, con esta aplicacin conoc la diferencia del desarrollo de
proyectos escolares y proyectos laborales, que son totalmente
distintos, ya que en los buenos proyectos escolares obtenemos una

evaluacin numrica y en el mbito real laboral, la evaluacin de

estos se da como la base del buen funcionamiento de toda una
infraestructura organizacional, en donde madure profesionalmente.
7. Bibliografa
Aylmer V. Nichols., "SISTEMA MODERNO DE PROCESAMIENTO DE
DATOS"., Editorial Limusa., Primera Edicin., p. 381
Corro Arango Miguel A.., "II SIMPOSIUM METODOLOGIA DE
DESARROLLO DE SISTEMAS" ., Instituto Tecnolgico de
Orizaba., Febrero de1989., p. 36
Churchman C. West., "EL ENFOQUE DE SISTEMAS"., Editorial Diana.,
Primera Edicin., p. 270
Burch Jhon G. ., "DISEO DE SISTEMAS DE INFORMACION"., Editorial
Limusa., p. 985
Greg Lief ., "NETWORK PROGRAMMING IN CA-CLIPPER 5.2"., ZiffDavis Press.,1993., p. 427
Liskin Miriam., "dBASE III PLUS AVANZADO Tcnicas de
Programacin"., Editorial McGraw-Hill., 1989., p. 748
Marn Quroz F.., "CLIPPER Tcnicas, Aplicaciones y Rutinas de
Programacin"., Editorial Macrobit., p. 429
Singelmann Jay., "MANUAL DEL PROGRAMADOR TOMO I"., Editorial
Prentice-Hall., Primera Edicin., 1989., p. 165
Pressman Roger S. ., "INGENIERIA DEL SOFTWARE"., Editorial
McGrawHill., Tercera Edicin., p. 824
Senn James A., "ANALISIS Y DISEO DE SISTEMAS DE
INFORMACION"., Editorial McGrawHill., Segunda Edicin., p. 942

Trabajo enviado por:

Alberto Parraguirre
paca74@yahoo.com