Análisis de Sistemas Basado en el modelo de Datos (página 2)

3. Análisis De
Sistemas
Definición De Análisis De Sistemas
Dentro de las organizaciones,
el Análisis de
Sistemas se refiere al proceso de
examinar la situación de una empresa con el
propósito de mejorarla con métodos y
procedimientos
más adecuados, por consiguiente, es el proceso de
clasificación e interpretación de hechos, diagnóstico de problemas y
empleo de la
información para recomendar mejoras al
sistema.

Un Sistema "Es un conjunto de componentes que
interaccionan entre sí para lograr un objetivo
común". La figura 2.1 muestra una
aplicación de los conceptos de sistemas a una
situación familiar en una organización, Observe la interrelaciones
entre los elementos. Esta característica es importante para lograr la
exitosa operación de los sistemas.

Figura 2.1 Elementos básicos de control de un
modelo de
sistemas

Análisis 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 información constituye el punto de partida
para la agrupación adecuada de la información que
se empleará para construcción de los modelos de
datos.

Las tareas principales para llevar a cabo el
análisis 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 función
Revisar y analizar el modelo funcional con los ejecutivos de alto
nivel

El modelo funcional es representado por un documento
analítico que muestra el
conjunto de áreas funcionales de la
organización 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 función

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),
Identificación y registro de
Funciones/Actividades "FORMA 1" (figura 2-5),
Identificación y registro de
Documentos
"FORMA 2" (figura 2-6), Registro de Campos "FORMA 3" (figura
2-7).

Figura 2-4. Forma para identificación y registro
de Áreas Funcionales
Figura 2-5. Forma para identificación y registro de
Funciones/Actividades
Figura 2-6. Forma para identificación de Documentos
Figura 2-7. Forma para Registro de Campos

El Modelo Funcional sirve como base para el
análisis del Modelo de Datos, porque del
Modelo Funcional se extraen datos de acuerdo a las actividades y
funciones analizadas con el objetivo de obtener
información de :

• Las formas y los reportes que se
  emplean
• El origen y destino del reporte y
  documento
• Las características de su uso
• Los catálogos que se emplean en la
  elaboración del reporte
• La descripción y el formato de cada
  dato

Análisis Del Modelo De
Datos
Este modelo de datos es la base para sistemas con
propósito de toma de
decisiones de la parte directiva y los mismos datos se
aplican en usos múltiples. Para este método se
deben tomar en cuenta conceptos asociados con las bases de datos y
los sistemas para su manipulación. Los diagramas de
entidad-relación y los diagramas de
estructuras de
datos son herramientas
de utilidad para el
diseño
y poder llevar a
cabo la aplicación de este modelo.

Esta filosofía de diseño
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) auxiliándose de
transacciones para la producción de información, es decir,
existe una generación de datos así como su
actualización, este modelo con los datos, el DBMS y las
transacciones da como resultado generación de documentos,
generación de gráficas, así como apoyo en la
toma de
decisiones, auditorias y
búsqueda de información. Figura 2.8

Figura 2.8 Modelo de datos

Diagrama de Estructura de
Datos
Esta técnica considera a los datos independiente del
procesamiento que transforma los datos, esto no indica que se
omitan. Esta modelización 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
técnica complementaria en donde se puede combinar con otro
enfoque de modelo que se haga cargo de la modelización que
manipule aspectos de procesamiento para un análisis
completo.

La modelización de datos es ampliamente en
aplicaciones de bases de datos.
Esto proporciona un gran panorama para analistas y
diseñadores de la base de datos una
amplia visión 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).

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 creación de
  entidad
• Describir la entidad
• Hacer referencia a otra creación de otra tabla
  de atributos u/o otra entidad

Además de que se pueden utilizar uno o más
atributos para relacionarse con otra entidad o entidades. Esto se
puede llevar a cabo utilizando un modelo relacional de los datos
siendo la aplicación sobre tablas (Figura 2.10) en donde
se muestran los atributos y su relación tomando en cuenta
la optimización de relaciones redundantes. Estas reglas de
normalización son las siguientes
:

• Una entidad tiene un valor y
  sólo un valor para
  cada atributo.
• Los atributos representan la unidad mínima, es
  decir, no contienen estructuras.
• Cuando se utiliza más de un atributo para
  identificar una entidad, hay que asegurarse que estos atributos
  representen una características completa de la
  entidad.
• Todos los atributos que no sean identificadores deben
  representar características de la entidad
  nombrada.

Figura 2.10 Las entidades representadas en
tablas.

Carta de Entidades.
Para la modelización de datos se utiliza una
notación denominada "Diagrama de
Entidad-Relación", siendo su propósito principal
representar a cada entidad y su relación mostrando la
clase de información necesaria para satisfacer un
requerimiento de información. Su notación es
sencilla, las entidades se representan con rectángulos
etiquetados, las conexiones entre entidades se representan
mediante varias líneas de conexión con un formato
especial. (Figura 2-11)

Figura 2-11 Notación de diagramas
Entidad-Relación

La modelización de datos y el diagrama de
Entidad-Relación se convierten para el analista una
notación que produce resultados concisos para ser
examinados en el procesamiento de
datos.

Carta de Burbujas.
Debido a que los datos se mueven a través del sistema
sufre constantes modificaciones, los diagramas son técnicas
para representar el flujo de la información 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
abstracción representando así un mayor flujo de
información y un mejor detalle funcional, el primer nivel
o nivel 0 también denominado modelo fundamental del
sistema del cual se puede elaborar en subniveles más
diagramas partiendo del nivel 0.

En los diagramas de burbuja la notación que se
usa para su creación consiste en un rectángulo el
cual representa una entidad externa (hardware, persona, otro
programa,
etc..) u otro sistema que genere información a ser
transformada por el software o sistema. El
círculo representa un proceso o transformación
aplicado a los datos, las flechas utilizadas en el diagrama de
burbuja indican el flujo y estas deben estar acompañadas
por una etiqueta. La doble línea representa almacenamiento de
información que es utilizada por el sistema. (Figura
2-13)

Figura 2-13. Notación de un
diagrama de burbuja básico.

Cabe mencionar que el diagrama de burbuja no representa
ninguna información explícita de la secuencia de
procesamiento, estando implícitamente en el
diagrama.

Esquema general del
sistema.
Este tipo de diagrama muestra la operación 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 notación es simple utilizando
rectángulos sencillos para indicar las transacciones
manuales y
rectángulos dobles para indicar las transacciones
automatizables utilizando las flechas que indican la dirección de la transacción. (Figura
2.14)

Figura 2-14. Notación para representar el Esquema
General de un Sistema

Mapa de Acceso
Lógico
Este tipo de diagrama sirve para representar la secuencia del
acceso lógico de una transacción a un modelo de
datos, siendo su notación básica similar a un
Diagrama de Entidad-Relación con la diferencia de que en
el Diagrama de Mapa de Acceso Lógico muestra unas
líneas que indican la dirección etiquetadas por el tipo de
operación que se efectúa, estas operaciones
afectan a los datos como : lectura,
modificación, borrado o agregar datos. Las entidades
representadas por un rectángulo van acompañadas en
su parte exterior por los atributos de cada entidad (Figura
2-15).

Figura 2-15. Ejemplo de un submodelo de datos
extraído para el diseño de la transacción de
admisión de pedidos.

Cabe mencionar que dentro de la nomenclatura
básica de un Mapa de Acceso Lógico existe la
aplicación de condiciones representadas por un punto
etiquetado el cual establece una conexión, en el Mapa de
Acceso Lógico se agregará la etiqueta de
condición acompañada de la descripción de la
condición.

Diagrama de
Acción
Es una representación gráfica de la
utilización de los datos en las transacciones, en donde se
ubican las acciones que
se efectúan seguidas por un rectángulo que contiene
la entidad y las estructuras de control
(condiciones y estructuras de control repetitivas) Figura
2-16.

Figura 2-16 Ejemplo de un diagrama de acción para
la transacción de admisión de pedidos.

El Diagrama de Acción tiene la función de
indicar de una forma más clara la especificación de
las estructuras de control repetitivas y de condición, las
cuales son especificadas en el Mapa de Acceso Lógico. Su
nomenclatura
es simple. En la Figura 2-17 se ilustra los posibles usos de las
condiciones.

Figura 2-17. Notación para indicar
condiciones

En la Figura 2-18 se ilustra la notación
básica para representar una estructura de
control repetitiva.

Figura 2-18. Notación para indicar una estructura
de control repetitiva

Miniespecificación
La miniespecificación es un listado de proposiciones en un
lenguaje
parecido a cualquier lenguaje
natural como el Español o
el Inglés.
Cada una de estas proposiciones especifican un paso de
transacción 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:

La
miniespecificación únicamente lista actividades o
transacciones de una parte del sistema en donde se omite la
especificación de la presentación de la
información visual en pantalla o impresora
(color, tipo de
letra, posición, cuadros, etc…) ya que se presenta a
detalle la transacción, más no aspectos
secundarios, los cuales se describen en formatos especiales como
son : Formatos de Pantallas y Reportes

Formato de Pantalla y Reportes
La mayoría de los sistemas en un análisis requieren
de una planeación
de la forma en que se obtendrán los datos, así como
la forma en que el sistema presentará los resultados, es
decir se requiere de una planeación
de la distribución de los atributos de las
entidades presentadas en pantalla y en papel.

Los formatos de pantalla van acompañados de una
hoja de especificación de colores, su
función es la de establecer una estandarización en
los colores que se
aplicaran en las pantallas, en donde además cada color debe estar
acompañado por una descripción que representa una
acción en el sistema. Por ejemplo:

Los formatos de pantalla deben contener
una escala para
columnas y filas que representen la cantidad máxima 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 también debe contener una descripción de
los campos que se aplican en la pantalla con su nombre, tipo y
longitud representando en la pantalla el espacio físico
que ocuparía realmente. Cabe mencionar que los campos de
tipo carácter o
alfanuméricos se representan por medio de una equis ("x")
y los campos de tipo numérico se representan por un nueve
("9") Figura 2-19.

Figura 2-19. Ejemplo de un formato de
pantalla

Los formatos de reporte sirven para indicar como se
representará la información producida por el
sistema en hoja. Estos deben contener una escala que representa
la cantidad máxima 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 máximo ocupado
será de 80 columnas, pero si utilizamos letra comprimida
en la misma impresora puede ocupar un máximo de 130
columnas). Los formatos de reporte también van
acompañados de una descripción de campos que
indique su nombre, tipo y longitud. La información
contenida en cada campo al igual que los formatos de pantalla
también se deben representar físicamente en el
formato de reporte indicando con equis ("x") la longitud de los
campos alfanuméricos o de tipo carácter, con nueves
("9") la longitud de los campos de tipo numérico (Figura
2-20).

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 número y una
descripción de su objetivo, por ejemplo : la pantalla
número 1 su objetivo es "menú principal del
sistema".

Otras técnicas
Existen otras técnicas de relevante importancia para
documentar el modelo de datos que tienen cierta similitud a
técnicas anteriores, variando únicamente los
propósitos de dicha técnica:
Mapa de transacciones. Es relevante a una transacción, a
través de una tabla de referencias donde muestra las rutas
utilizadas en particular por dicha transacción, en donde
su objetivo principal es hacer referencia al número de
veces que los datos sufren una transacción 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 transacción, a través
de cada ruta utilizada (asociación entre dos entidades),
durante un período 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 través de cada ruta utilizada
(asociación entre dos entidades), durante un
período de procesamiento seleccionado.
Matriz de
Carga. Este documento de diseño es importante para ser
utilizado durante el diseño físico 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 período definido; totaliza el
número de referencias lógicas contra la base de
datos para una transacción sencilla y el número
total para aquellas transacciones procesadas durante un
período.
Modelo Relacional. Diagrama que muestra el Modelo de Datos
Lógico convertido en Modelo Físico, siendo su
dependencia del tipo de manejador de base de datos
utilizado.

Análisis De Transacciones
En muchos sistemas un elemento de datos es el motivo para
determinar uno o más flujos de información, que
afectan a la función de acuerdo con el que determine dicho
elemento de datos, a este elemento se le denomina
transacción que desencadena otro flujo de datos a
través 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 transacción.

Figura 2-21. Flujo de Transacción

Los pasos a seguir para manipular el flujo de
transacción tiene el objetivo de transformar un diagrama
de flujo de datos en la estructura de un programa.

Revisión del modelo fundamental del sistema, que
consiste en una revisión del diagrama de flujo de datos
iniciando del nivel 0 y el nivel 1 que describen la
especificación del sistema y la especificación de
requisitos del sistema.

Refinar y revisar los diagramas de
flujo de datos para el sistema, siendo una revisión a
detalle de los niveles 1 y 2 para detectar con mayor posibilidad
de éxito
un diagrama de flujo de transacción. Determinar si el
diagrama de flujo de datos tiene características de
transformación o de transacción, en donde el
diseñador se encarga de determinar si la
característica natural del diagrama de flujo de datos
pertenece a un flujo de transacción de acuerdo a la figura
2-21.

Identificar el centro de transacción y las
características de cada camino de acción, para
detectar un flujo de transacción cuando es el origen de
varios flujos de información 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,
llevándose a cabo creando subgrupos de burbujas a lo largo
de un camino, así el flujo de cada camino de acción
del diagrama de flujo de datos se convierte en una estructura con
las características específicas de flujo. Las
correspondencias en la transacción se ilustra en la figura
2-23.

Figura 2-23. Correspondencias en la
transacción

Factorizar o Refinar la estructura de transacciones y la
estructura de cada camino aplicando reglas de diseño para
mejorar la calidad. Para
factorizar se busca la mejor correspondencia entre los caminos,
tratando de no omitir ninguno de ellos puesto que
ocasionaría perdida de una transacción en el
sistema conllevando a que este no cumpla sus objetivos en
su totalidad.

En el análisis de transacciones la estructura del
programa, en sus módulos pueden expandirse o reducirse con
el objetivo de mejorar su independencia,
tomando en cuenta que la expansión de un módulo se
divide en 2 o más módulos en la estructura de un
programa final. Un módulo reducido es el resultado de la
combinación del procesamiento involucrado en 2 o
más módulos. Es necesario lograr una estructura en
donde los módulos contengan varios niveles para una mejor
entrada/salida ya que esto indica varias capas de control y gran
aprovechamiento de recursos en los
módulos 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
módulos, no solo nos referimos a los niveles iniciales 0,
1 ó 2 sino que también hablamos de aquellos que
conforman al sistema los cuales nos muestran las transacciones en
forma superficial, es decir, sin llegar al código
ó al tipo de estructura de
datos, uso de archivos, etc…
Es por ello que se recomienda evaluar las interfaces de los
módulos para reducir la complejidad y la redundancia y
así mejorar la consistencia de los
módulos.

Una aplicación correcta del análisis de
transacciones se complementa documentando al análisis
realizando los siguientes pasos :

• Desarrollar para cada módulo, un texto
  explicativo del procesamiento
• Dar para cada módulo una descripción de
  la interfaz
• Definir las estructuras de datos globales y
  locales
• Anotar todas las restriccciones/limitaciones de
  diseño
• Llevar a cabo una revisión del diseño
  preliminar registrando las actualizaciones.

Algunos aspectos típicos en las
restricciones/limitaciones son el tipo de formato de datos,
limitaciones de memoria, valores o
cantidades límites
para las estructuras de datos así como
características especiales de un módulo individual.
Todo esto con el fin de reducir el número de errores antes
de llegar al diseño o con ello justificar que no es viable
su desarrollo.
Las actividades de revisión se centran en el seguimiento
de los requisitos del sistema, la estructura del programa, en las
descripciones de las interfaces, descripción de las
estructuras de datos, la descripción de
restricciones/limitaciones, en la facilidad de
implementación y desarrollo de pruebas, y en
la facilidad de mantenimiento.

Análisis Del Uso De Los Datos

A medida que la información se mueve a
través del software, está es
modificada por una serie de transformaciones. El diagrama de
flujo de datos (DFD) es una técnica gráfica que
representa el flujo de la información 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
básica de un diagrama de flujo de datos. El DFD
también se le conoce como grafo de flujo de datos o como
diagrama de burbujas.

Figura 2-25 Modelo de flujo de
información

Se puede utilizar un DFD para representar cualquier
software a cualquier nivel de abstracción. En la figura
2-26 muestra la notación básica que se usa para
crear un diagrama de flujo de datos. El rectángulo 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
información a ser transformada por el software o que
reciba información producida por el software. Un
círculo representa un proceso o transformación 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 línea doble representa un almacén de
información, Información almacenada que se utiliza
por el software. La sencillez de la notación de un DFD es
una de las razones por las que las técnicas de
análisis estructurado son ampliamente
utilizadas.

Figura 2-26 Notación DFD
básica.

El Diagrama de Flujo de Datos es una herramienta
gráfica que puede ser valiosa durante el análisis
de requisitos del sistema. Cabe mencionar que el diagrama no
proporciona ninguna sencuencia explícita de los procesos.

4. Desarrollo De
Sistemas
Estrategias De
Pruebas Del
Software
La prueba es un proceso individualista y el número de
tipos diferentes de pruebas varía tanto como los
diferentes enfoques de desarrollo, una prueba es un conjunto de
actividades que se puede planificar por adelantado y llevar a
cabo sistemáticamente. Una estrategia de
prueba de software integra las técnicas de diseño
de casos de prueba en un conjunto de pasos bien planeados que dan
como resultado la correcta construcción del software. Una estrategia de
prueba de software proporciona una guía o plano para los
desarrolladores del software (sistema), para la
organización 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 realización,
y cuánto tiempo, esfuerzo
y recursos se van a
utilizar-. Por tanto una estrategia de software debe incorporar
la planificación de la prueba, el
diseño de casos de prueba, la ejecución de pruebas
y la agrupación y evaluación
de los datos resultantes.

Prueba de unidad
La prueba
de unidad centra el proceso de verificación en la menor
unidad del diseño del software. Aquí se prueban los
caminos de control importantes, con el fin de descubrir errores
dentro del ámbito de un módulo.

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 están representadas en la
figura 3-1

Figura 3-1 Prueba de Unidad

Se prueba la Interfaz del módulo para asegurar
que la información 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
ejecución del algoritmo, Se
prueba las condiciones límite para asegurar que el
módulo funciona correctamente dentro de los límites
establecidos por el procesamiento. Se activan los caminos
básicos de la estructura de control con el fin de asegurar
de que las sentencias del módulo 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 módulo, ya que si los datos no
entran correctamente, todas las demás pruebas no tienen
sentido. Myers, propone una lista de comprobaciones para la
prueba de interfaces 1:

¿Es igual el número de parámetros
de entrada al número de argumentos?
¿Coinciden las características (atributos) de los
parámetros con los argumentos?
¿Coinciden el sistema de unidades de los parámetros
con el de los argumentos?
¿Son correctos el número, atributos y el orden de
los argumentos de las funciones incorporadas?
¿Existen referencias o parámetros que no
estén asociados con el punto de entrada actual?
¿Entran sólo argumentos alterados?
¿Son consistentes las definiciones de variables
globales entre módulos?
¿Se pasan las restricciones como argumentos?

Cuando un módulo tenga operaciones
básicas 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 tamaño del buffer con el tamaño
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 algún error textual en la información
de salida?

Las estructuras de datos locales de cada módulo
son una gran fuente de errores. Se deben diseñar casos de
prueba para descubrir errores :
Tipificación impropia o inconsistente
Inicialización o valores
implícitos erróneos
Nombres de variables
incorrectos (mal escritos o truncados)
Tipos de datos
inconsistentes
Desbordamiento o errores en el direccionamiento de
memoria

Se deben diseñar casos de prueba para detectar
errores causados por cálculos incorrectos o flujos de
control inapropiados. Las pruebas de camino básico o de
ciclos son técnicas más efectivas para descubrir
una gran cantidad de errores en los caminos. Entre los errores
más comunes en los cálculos están
:

• Procedencia aritmética incorrecta mal
  aplicada
• Operaciones de modo mixto
• Inicializaciones incorrectas
• Falta de precisión
• Representación incorrecta de una
  expresión
• Las comparaciones y el flujo de control están
  muy relacionadas, es decir, el flujo de control cambia tras una
  comparación

Los casos de prueba deben descubrir errores como
:

• Comparaciones entre tipos de datos
  distintos
• Operadores lógicos o de procedencia
  incorrecta
• Terminación de ciclos inapropiada o
  inexistente
• Falta de salida cuando se encuentra una
  iteración mal aplicada (Ciclos infinitos)
• Variables internas a un ciclo modificadas en forma
  inadecuada.

Entre los errores que se deben comprobar se
evalúa en la manipulación de errores lo siguiente
:

• La condición de error hace que intervenga el
  sistema antes que el mecanismo de errores
• Descripción ilegible del error
• El error señalado no corresponde con el error
  encontrado
• La descripción del error no proporciona
  suficiente información para ayudar en la
  localización de la causa del error.

La prueba de los límites es la última
etapa de la prueba de unidad y quizá la más
importante. El software falla en sus condiciones límite, o
sea, que frecuentemente aparece un error cuando se procesa el
elemento n-ésimo de un arreglo n-dimensional, cuando se
hace la i-ésima repetición de un ciclo de x pasos o
cuando se llega a los valores
máximo ó mínimo permitidos. Los casos de
prueba que ejerciten las estructuras de datos por debajo o encima
de los mínimos y máximos permitidos son apropiados
para descubrir estos errores.

Normalmente, se considera a la prueba de unidad como
algo adyacente a al paso de la codificación. En donde los
casos de prueba de unidad comienzan una vez que se ha
desarrollado, revisado y verificado en su sintaxis el
código a nivel fuente.

Prueba de integración
Una vez que los módulos funcionen por separado y hayan
pasado la prueba de unidad es necesario cuestionar lo siguiente :
"El módulo funciona bien sólo", ¿Por
qué dudar de que funcionen juntos?. Aquí pueden
surgir los problemas en
la unión de los módulos. Los datos se pueden perder
en una interfaz, un módulo puede tener un efecto adverso
sobre otro módulo; las subfunciones, cuando se combinan,
pueden no producir el objetivo principal deseado, las estructuras
de datos globales pueden presentar problemas.

La prueba de Integración es una técnica
sistemática para construir la estructura del programa
mientras que al mismo tiempo, se llevan a cabo pruebas para
detectar errores asociados con la interacción. El objetivo
es tomar los módulos probados en unidad y estructurar un
programa que esté de acuerdo con lo que dicta el
diseño.

Existen 2 tipos de integración, la primera es no incremental
en donde se intenta elaborar software en módulos grandes,
en otros casos un sólo módulo, pero en ellos es
más difícil aislar los errores y cuando alguno de
ellos es corregido produce otros errores. El segundo tipo de
integración es incremental en donde se desarrollan
módulos pequeños y funcionales que hacen que los
errores sean más fácil de aislar y corregir, es
más probable que se puedan probar completamente las
interfaces y aplicar un enfoque de prueba
sistemático.

Integración descendente, es una estrategia de
integración incremental a la construcción de la
estructura de programas, en
cual se integran los módulos moviéndose en
dirección hacia abajo por la jerarquía de control
comenzando con el módulo principal (Programa principal).
Los módulos subordinados al módulo 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 Integración Descendente

De acuerdo a la figura 3-2 primero-en-profundida integra
todos los módulos de una camino de control principal a la
estructura, por ejemplo: si se elige el camino a la izquierda se
integrarán primero los módulos M1, M2, M5 y M8,
enseguida se construyen los caminos de control central y derecho.
La integración primero-en-anchura integra todos los
módulos directamente subordinados a cada nivel
desplazándose en la estructura en forma horizontal de
acuerdo a la figura 3-2 , en donde los primeros módulos
que se integran son M2, M3 y M4, para el siguiente nivel M5, M6 y
M7.

El proceso de integración se lleva a cabo en 5
pasos :

Se usa el módulo de control principal como
conductor de prueba, disponiendo de resguardos para todos los
módulos directamente subordinados al módulo de
control principal.
Dependiendo del enfoque de integración elegido (primero-en
profundidad o primero-en-anchura) se van sustituyendo los
resguardos subordinados cada uno por los módulos
reales.
Las pruebas se llevan a cabo cada vez que se integra un
módulo.
Tras terminar cada conjunto de pruebas, se reemplaza otro
resguardo con el módulo real.
Se hace una prueba de regresión, 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 más bajos de la
jerarquía 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 módulos reales.
Desarrollar resguardos que realicen funciones limitadas que
simulen los módulos reales.
Integrar el software desde el fondo de la jerarquía hacia
arriba.

Integración Ascendente, es en donde la
construcción del diseño empieza de los
módulos más bajos hacia arriba (Módulo
principal), el procesamiento requerido de los módulos
subordinados siempre está disponible y elimina la
necesidad de resguardos. Una estrategia de integración
ascendente puede ser implementada mediante los siguientes pasos
:

Se combinan los módulos de bajo nivel en grupos que
realicen una subfunción 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
moviéndose hacia arriba por la estructura del
programa

La integración 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 módulos 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 módulo Mb finalmente el módulo Ma
como el módulo Mb se integran al módulo Mc y
así sucesivamente.

Figura 3-3 Integración Ascendente

La selección
de una estrategia de integración depende de las
características del software y, a veces, del plan del proyecto, en
algunos de los casos se puede combinar ambas estrategias.

Prueba de validación y verificación
Al conjunto de actividades que aseguran que el software
implementa correctamente una función específica se
denomina Verificación. La Validación 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 :

Verificación : "¿estamos construyendo el
software correctamente?"
Validación : "¿estamos construyendo el software
correcto?"

La definición de Verificación y
Validación 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 métodos de
análisis, de diseño y de implementación
(codificación) actúan para mejorar la calidad al
proporcionar técnicas continuas y resultados predecibles.
Las revisiones técnicas formales ayudan
(inspección) ayudan a asegurar la calidad la calidad de
los productos, a
lo largo del proceso la medición y el control se aplican sobre cada
elemento de una configuración del software. La prueba
constituye un elemento importante desde el que se puede evaluar
la calidad y, de forma más práctica, descubrir los
errores. Cabe mencionar que la prueba no se debe contemplar como
una red de seguridad. La
aplicación adecuada de los métodos y de las
herramientas,
las revisiones técnicas formales efectivas y una
sólida gestión
y medida, conducen a la calidad, que se confirma durante la
prueba.

Figura 3-4 Obtención de calidad del
software

Miller relaciona la prueba del software con la
garantía de calidad al establecerse que "la
motivación subyacente de la prueba de programas es
confirmar la calidad del software con métodos que se
puedan aplicar de forma económica y efectiva, tanto en
grandes como pequeños sistemas".1

Es importante mencionar que la validación y
verificación abarcan un amplio rango de la calidad del
software que incluyen revisiones técnicas formales,
auditorías de configuración y
calidad, supervisión de rendimiento, simulación, estudio de viabilidad,
revisión de la documentación, revisión de la base
de datos, análisis de algoritmos,
pruebas de desarrollo, prueba de calificación y prueba de
instalación.

Una vez que se culminó la etapa de
integración 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 validación se logra cuando las
expectativas razonables del cliente su cumplen en donde incluyen
la especificación de requisitos, documentos en donde se
describen los atributos del software que son visibles para el
usuario, esta información forma la base del enfoque a la
prueba de validación.

El procedimiento de
prueba estará diseñado para asegurar que se
satisfacen los requisitos funcionales, que se alcanzan todos los
requisitos de rendimiento, que la documentación es
correcta y que se alcanzan otros requisitos tales como
portabilidad, compatibilidad, recuperación de errores,
facilidad de mantenimiento, etc…

Una vez que se procede con la prueba de
validación, puede darse una de las dos condiciones
:

• Las características de funcionamiento o
  rendimiento están de acuerdo con las especificaciones y
  son aceptables ó
• Se encuentra una desviación de las
  especificaciones y se crea una lista de
  deficiencias.

Cuando se construye el software para llevar a cabo la
prueba de validación 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
aceptación 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 versión 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 aplicación en vivo del software en un entorno
diferente.

Prueba del sistema
En las técnicas anteriores se mencionan algunas
técnicas de prueba que se efectúan durante el
diseño del software, cabe mecionar que en cada una de esas
técnicas serán el éxito o fracaso para la
integración del software en el sistema total. Un
clásico problema de la prueba del sistema es la
delegación 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
:

Diseñar caminos de manejo de errores que prueben
toda la información 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 señalamientos informales.
Participar en la planificación y diseño de las
pruebas del sistema para asegurarse de que el software es probado
en forma adecuada.

La prueba del sistema se basa en otras técnicas
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 Recuperación. Muchos sistemas basados
en computadora
deben recuperarse de los fallos y resumir el procesamiento en
tiempos previamente especificados. La prueba de
recuperación es una prueba que se hace al sistema forzando
a que produzca fallas de software de muchas maneras y verificando
que la recuperación se lleve a cabo, ya sea
automáticamente o manual, tomando
en cuenta los recursos que se requieran para efectuar la
recuperación.

Prueba de Seguridad. Cualquier sistema basado en
la computadora
que manipule información sensible o efectúe
acciones que
pueden perjudicar o beneficiar a los individuos es objeto de
penetraciones impropias o ilegales. La penetración incluye
una serie de actividades como :

• penetrar sistemas por joby
• personas disgustadas que intentan penetran por
  venganza
• personas deshonestas que intentan penetrar para
  obtener ganancias personales ilícitas
• 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 aplicación de los mecanismos de
protección incorporados en el sistema. Durante la prueba
el encargado de la prueba desempeña 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 además de producir errores a
propósito en el sistema; o debe curiosear los datos
públicos intentando encontrar una clave de acceso al
sistema.

Prueba de Resistencia. La
prueba de resistencia
está diseñada para enfrentar a los programas en
situaciones anormales, es decir ejecutar el sistema en forma que
demande recursos en cantidad, frecuencia o volúmenes
anormales. El encargado de la prueba debe intentar tirar el
sistema. Para lograr esto se puede tomar en consideración
lo siguiente :

• Diseñar pruebas especiales que generen 10 o
  más 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
  máximo de memoria o de
  espacio en disco.
• Diseñar casos de prueba que produzcan
  excesivas búsquedas de datos almacenados en
  disco.

Depuración
La depuración aparece como resultado de una prueba
efectiva, es decir, cuando en un caso de prueba se encuentra un
error, la depuración es el proceso que resulta en la
eliminación de un error. Se debe tomar en cuenta que la
depuración no es una técnica de prueba, aunque
siempre se da como consecuencia de la prueba. De acuerdo con la
figura 3-5 el proceso de depuración comienza en los casos
de prueba, se evalúan los resultados y resulta una falta
de correspondencia entre los esperados y los reales, el proceso
de depuración intenta hacer corresponder el sistema con
una causa, llevando así a la corrección del
error.

Fig. 3-5 Depuración

El proceso de depuración 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 depuración debe sospechar la causa, en donde debe
diseñar casos de prueba que ayuden a confirmar sus
sospechas y el trabajo se
regresa a la corrección del error de una forma
interactiva.

La depuración tiene como objetivo principal
encontrar y corregir la causa de un error en el software, existen
3 enfoques que se pueden proponer en la
depuración1

Eliminación de causas
Fuerza
Bruta
Vuelta atrás

La categoría de depuración
"eliminación de causas" se manifiesta mediante inducción o deducción. 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 categoría de depuración por "fuerza bruta"
es la categoría probablemente la más común y
la menos eficiente en el momento de aislar la causa del error del
software en donde se confía que en algún lugar de
la gran cantidad de información producida nos puede llevar
finalmente al éxito, lo más frecuente es que se
desperdicie tiempo y esfuerzo.

La vuelta atrás es el enfoque más normal
para la depuración, que se puede usar con gran
éxito en programas pequeños. Partiendo de donde se
detecta el error hacia atrás en el código fuente
hasta llegar a la posición del error.

Cada uno de los enfoques anteriores puede complementarse
con herramientas de depuración, ayudas dinámicas de
depuración, generadores automáticos de casos de
prueba, etc.. En general a partir de una indicación de un
problema, la actividad de depuración debe rastrear la
causa del error.

Mantenimiento Del Software
El mantenimiento de software, es mucho más que una
corrección de errores; el mantenimiento se puede describir
en tres actividades.

• 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 diagnóstico y corrección de uno o
más errores.

La evolución rápida tanto de hardware
como de software genera cambios en periféricos, sistemas
operativos o nuevas versiones de los anteriores en otros
casos nuevas disposiciones nacionales (por ejemplo en nuestro
país el cambio de
moneda) hacen que algunos sistemas no se adopten a la nueva
tecnología
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.

Características 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 sólo
se dispone del código fuente como un elemento de
configuración empezándolo a evaluar a menudo
complicada por la pobre documentación interna. Las
delicadas características, tales como las estructuras de
datos, variables globales, las interfaces del sistema, el
rendimiento y/o limitaciones del diseño, son
difíciles de descubrir y frecuentemente mal
interpretados.

Si existe una completa configuración del
software, la tarea del mantenimiento comienza con la evaluación
de la documentación del diseño, se determinan las
importantes características 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 diseño y revisa. Se desarrolla el nuevo
código fuente sometiéndolo 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
insatisfacción al cliente cuando una petición o
modificación aparentemente legitima no se puede atender en
un tiempo razonable, Disminución de la calidad global del
software debido a los errores permanentes que se generan cuando
se introducen cambios al software en mantenimiento,
utilización 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
:

• Frecuentemente es difícil seguir la evolución del software a través
  de varias versiones ya que los cambios no están
  adecuadamente documentados.
• Frecuentemente es imposible o difícil seguir
  el proceso por el que se construyó el
  software.
• Generalmente es completamente difícil
  comprender un programa "ajeno".
• Ese personaje "ajeno", por lo regular, no se
  encuentra cerca para que pueda explicar lo que
  hizo.
• No existe una documentación apropiada o
  está mal preparada.
• La mayoría del software no ha sido
  diseñado previendo el cambio.

Estos problemas que se acaban de mencionar, en parte, se
pueden atribuir al gran número de programas actualmente
existentes que han sido desarrollados sin tener en cuenta una
metodología de desarrollo.

Efectos secundarios del mantenimiento
La modificación al software en los códigos 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 lógico muy
complejo, la posibilidad del error aumenta.

FREEDMAN y WEINBERG 2 definen tres grandes
categorías de efectos secundarios del
mantenimiento

Efectos secundarios sobre el código. Con el hecho
de realizar un sencillo cambio sobre una sola sentencia puede a
veces tener resultados desastrosos. El cambio inadvertido de
algún símbolo "." ó ";" muchas veces pueden
acarrear problemas trágicos. En una computadora nos
comunicamos mediante el código fuente en algún
lenguaje de
programación. Las posibilidades de efectos secundarios
abundan, aunque cada modificación que se realice en el
código puede regularmente inducir al error. Los siguientes
cambios tienen mayor probabilidad de
inducir a error que otros :

• Un subprograma eliminado o cambiado
• Eliminación ó modificación de
  una sentencia o etiqueta
• Eliminación o modificación de un
  identificador
• Cambios para mejorar el rendimiento en
  ejecución
• Modificación de apertura o cierre de
  archivos
• Modificación de operadores
  lógicos
• Cambios sobre las pruebas límite

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 información del
software. Los siguientes cambios en los datos producen efectos
secundarios como :

• Redefinición de constantes locales o
  globales
• Redefinición de registros o
  archivos
• Aumento o disminución del tamaño de
  los arreglos o de las estructuras de datos de mayor
  orden
• Modificación de datos globales
• Reiniciación de indicadores de control o de
  punteros
• Reorganización de argumentos de
  Entrada/Salida o de subprogramas

Los efectos secundarios se pueden limitar mediante una
profunda documentación de diseño 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 módulos del
software.

Efectos secundarios sobre la documentación. El
mantenimiento que se efectúa en el software se debe
centrar en la completa configuración del software, no solo
las modificaciones que se efectúan en el código
fuente. Los efectos secundarios en la documentación es
debido a que no se reflejan las modificaciones hechas en el
código fuente sobre la documentación respectiva, no
llevando a cabo un registro u/o actualización de los
códigos fuente modificados.

Siempre que se realice una modificación sobre el
flujo de datos, sobre la arquitectura de
diseño sobre los procedimientos
(módulos) o sobre cualquier otra característica
asociada, se debe actualizar la información técnica
soporte, la documentación actual no se reflejará en
su totalidad en el software pero puede ser peor la ausencia total
de este tipo de documentación.

5.
Implantación
Conversión
La conversión consiste en el cambio del sistema anterior
con el sistema nuevo, así como los métodos para
llevarla a cabo y verificación de que la conversión
se haya efectuado correctamente.

Existen cuatro métodos para efectuar una
conversión en un sistema, en donde cada método
tiene ventajas y desventajas entre los mismos. Es conveniente
mencionar que algunos métodos de conversión se
ajustan perfectamente a problemas planteados, en donde nos es
conveniente aplicar otro método debido a que los posibles
resultados sean ampliar los periodos de conversión,
situación que puede crear problemas con los usuarios y los
analistas.

Sistemas paralelos
Este método 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 información. Una desventaja muy notable es
que este método de conversión es muy costoso ya que
se duplican los recursos
humanos como materiales
para trabajar en forma paralela ambos sistemas duplicando
así los costos de
operación.

Conversión directa
El sistema anterior será reemplazado por el nuevo sistema,
ya que la organización confía plenamente en el
nuevo sistema. Obligando así a los usuarios a que hagan
funcionar al nuevo sistema encontrando en él nuevos
métodos y controles. En caso de encontrar errores no
existe un sistema que lleve un respaldo de seguridad en las
operaciones, este método ocasiona una planeación
más cuidadosa.

Enfoque piloto
En este método se implanta el nuevo sistema en una parte
de la organización. Con base a retroalimentación se hacen cambios y el
sistema se instala en el resto de la organización mediante
algunos otros métodos, esto en gran medida proporciona
experiencia y prueba directa antes de la implantación.
Ocasionando la desventaja de que el nuevo sistema puede dar la
impresión de que el nuevo sistema no es confiable, ni
está libre de errores.

Conversión 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
capacitación de los mismos, llevando a cabo
la instalación de una nueva etapa una vez que fue aceptada
sin hacer uso necesario de recursos extras.

Plan De Conversión
El plan de conversión incluye una lista de actividades
para llevar a acabo la implantación del nuevo sistema y
ponerlo en operación. 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 conversión debe prevenir los posibles
problemas y la forma de enfrentarlos implementando planes de
emergencia adecuados. Algunos problemas que se presentan
comúnmente son :

• Documentos perdidos
• Variación entre datos de los formatos nuevos y
  anteriores
• Errores en la conversión de datos
• Extravío de datos o pérdida de
  archivos
• Omisión en algunos pasos de la
  conversión

Durante la conversión se deben considerar
diversos aspectos, desde la instalación del equipo hasta
el orden de las formas y los suministros. Algunas actividades de
conversión 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 eléctrico y los
contactos, necesidades de aire
acondicionado, controles de humedad y exigencias de espacio,
lo más recomendable es tener el local antes de la llegada
del equipo.

Capacitación De Operadores Y Usuarios Para Operar
El Sistema
En algunos casos los sistemas de las compañías de
más prestigio pueden tener éxito o fracasar debido
a la forma en que se operan y se usan. Como consecuencia la
calidad de capacitación recibida por el personal
manipulará el sistema ayuda u obstruye, y puede llegar a
impedir, la implantación exitosa de un sistema de
información. Aquellas personas que se encuentren
asociadas o afectadas por el sistema deben conocer cuál es
su papel, cómo pueden usar el sistema y qué
hará o no hará el sistema. Tanto operadores como
los usuarios del sistema requieren de
capacitación.

Capacitación de operadores
La mayoría de los sistemas dependen del personal de
Centro de
Cómputo, el cual es el encargado de mantener los
equipos de cómputo funcionando, así como de
proporcionar el apoyo necesario. La capacitación que el
personal reciba debe de asegurar que puedan manejar todas las
operaciones posibles, tanto rutinarias como extraordinarias. La
capacitación que reciba el operador también debe
contemplar al personal de captura de datos.

Si el sistema requiere de la instalación 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 operación y su uso normal. Como parte de
la capacitación se le debe dar al personal una lista de
formas de resolver los problemas y que identifique los posibles
problemas y solución, así como datos personales de
las personas a quién buscar cuando surjan problemas
inesperados.

Capacitación de usuarios
La capacitación de usuarios incluye la
identificación 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 más 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
capacitación. La mayor parte de la capacitación de
los usuarios tiene que ver con la operación del sistema en
sí. La capacitación en la codificación de
los datos marca la pauta en
el proceso de captura a partir de las transacciones, o en la
preparación de datos necesarios para las actividades de
apoyo a las decisiones.

Las actividades de manipulación de los datos que
recibe la mayor atención en la capacitación de
usuarios son la captura de datos (Cómo modificar datos
previamente almacenados), la formulación de consultas
(Cómo localizar información específica u
obtener respuestas a preguntas) y el borrados de los registros de
datos. La parte fundamental de la capacitación cae sobre
esta actividad dedicándose la mayor parte del tiempo a
esta área.

En algunos casos los usuarios tienen que tener conocimiento
de la operación básica de algunos periféricos 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 además del
conocimiento para la manipulación de los discos como es
formatear y probar discos.

En la capacitación de usuarios se debe tomar en
cuenta dos aspectos importantes mencionados anteriormente los
cuales consisten en la familiarización con el sistema de
procesamiento en sí (es decir, el equipo usado para la
captura y procesamiento de datos) y la capacitación en el
uso de la aplicación (es decir, el software que acepta los
datos, los procesa y produce los resultados). La debilidad de
cualquier aspecto de la capacitación puede ser una
posibilidad para la generación de errores. Una buena
documentación, aunque es importante, no reemplaza la
capacitación.

Métodos de capacitación
La capacitación a operadores y usuarios se puede
manifestar de diferentes formas. Las actividades de
capacitación se pueden llevar a cabo en las instalaciones
de los proveedores, locales rentados como podría ser el
caso de hoteles y
Universidades, "en casa", o en las instalaciones de la empresa. Los
métodos y contenido de la capacitación varia de
acuerdo a la fuente y del lugar de la
capacitación

Instalación Y Pruebas Del Usuario Para
Aceptación Del Sistema
En la instalación 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 instalación y
funcionamiento en general, en esta etapa se abarcan cuatro
aspectos importantes :

La prueba de entrada que implica ver si las formas
electrónicas y las de papel así como la estructura
de codificación cumplen con las guías y
especificaciones de diseño, también se hacen una
autoprueba los usuarios finales del sistema para saber si
están llenando correctamente las formas. Al efectuar estas
pruebas se supone que el usuario ya recibió
capacitación y en ella se les enseño como llenar
los formatos. Las pruebas en esta etapa consisten en determinar
si fueron capacitados correctamente.

Muchas organizaciones
contratan personas cuya única función es capturar
datos siendo de gran importancia una capacitación adecuada
para la captura de datos.

La prueba de salida, en la mayoría 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
generación de un reporte, su entrega al usuario y
determinar si satisface las necesidades de información.
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 información que satisfaga
todas las demandas que se le plantean. Incluyendo pruebas tales
como la creación de un nuevo registro antes del primer
registro en el archivo maestro,
la creación de un nuevo registro después del
último, la creación 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 propósito primordial
de la prueba de controles es asegurar que estos se encuentren en
su lugar y trabajen según se planeó. Las
transacciones de prueba ayudan a asegurar que los controles de
procesamiento, como las verificaciones de límite y
racionalidad, la prueba aritmética y la
identificación están en su lugar funcionando
correctamente. Algunas pruebas de control que normalmente se
realizan son :

• Tratar de leer o escribir en un archivo
  incorrecto
• Introducir varios campos con datos incompletos o
  faltantes
• Tratar de procesar una transacción delicada
  sin la autorización apropiada y ver si el sistema lo
  rechaza
• Hacer verificaciones de caracteres
  numéricos, alfabéticos y especiales, por
  ejemplo en la captura de una clave se deberán
  introducir únicamente valores numéricos, en
  donde se deben introducir valores alfabéticos. Una
  verificación que funcione correctamente
  detectará el error antes de realizar el
  procesamiento.
• Hacer verificaciones de límite y
  racionalidad, por ejemplo : Un docente no puede tener
  más de 40 horas en una jornada al día, se
  probará introduciendo valores que excedan la jornada
  de un día
• Realizar verificaciones de validez de campos clave,
  por ejemplo : introducir una clave inválida y ver como
  responde el sistema
• Introducir en un campo numérico valores
  negativos y ver si lo acepta como tal, o los efectos que
  ocasiona

Las pruebas de los controles incluyen también una
revisión de la documentación que aparece en los
reportes del desarrollo de sistemas. Después de que el
usuario considera que el software paso las pruebas, deberá
llevarse a cabo una reunión de aceptación, a la que
asista el gerente de
operaciones de sistemas, el analista de sistemas y el personal
usuario. En este momento se le da terminación 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 diseñar o implementar algunas de las
solicitudes y sugerencias de mejora del sistema que fueron
suspendidas anteriormente.

6.
Conclusiones
En el análisis y desarrollo del
sistema de horarios, he comprobado los conocimientos adquiridos
en mi Licenciatura con respecto a las materias Administración de Archivos, Ingeniería 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
público, 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é
académica y laboralmente mis estudios.

Además, con esta aplicación conocí
la diferencia del desarrollo de proyectos
escolares y proyectos
laborales, que son totalmente distintos, ya que en los buenos
proyectos escolares obtenemos una evaluación
numérica y en el ámbito real laboral, la
evaluación de estos se da como la base del buen
funcionamiento de toda una infraestructura organizacional, en
donde madure profesionalmente.

7.
Bibliografía

Aylmer V. Nichols., "SISTEMA MODERNO DE PROCESAMIENTO
DE DATOS"., Editorial Limusa., Primera Edición., p.
381
Corro Arango Miguel A.., "II SIMPOSIUM METODOLOGIA DE DESARROLLO
DE SISTEMAS" ., Instituto Tecnológico de
Orizaba., Febrero de1989., p. 36
Churchman C. West., "EL ENFOQUE DE SISTEMAS"., Editorial Diana.,
Primera Edición., p. 270
Burch Jhon G. ., "DISEÑO DE
SISTEMAS DE INFORMACION"., Editorial Limusa., p. 985
Greg Lief ., "NETWORK PROGRAMMING IN CA-CLIPPER 5.2"., Ziff-Davis
Press.,1993., p. 427
Liskin Miriam., "dBASE III PLUS AVANZADO Técnicas de
Programación"., Editorial McGraw-Hill.,
1989., p. 748
Marín Quíroz F.., "CLIPPER Técnicas,
Aplicaciones y Rutinas de Programación"., Editorial Macrobit., p.
429
Singelmann Jay., "MANUAL DEL
PROGRAMADOR TOMO I"., Editorial Prentice-Hall., Primera
Edición., 1989., p. 165
Pressman Roger S. ., "INGENIERIA DEL SOFTWARE"., Editorial
McGrawHill., Tercera Edición., p. 824
Senn James A., "ANALISIS Y DISEÑO DE
SISTEMAS DE INFORMACION"., Editorial McGrawHill., Segunda
Edición., p. 942

Autor:

Alberto Parraguirre