TEMA 4

PRUEBAS E IMPLEMENTACIÓN

BENÍTEZ MARTÍNEZ DANIEL 15321020

NERI BASURTO ALFONSO DE JESÚS 1321143
Contenido

4.1 DISEÑOS DE CASO DE PRUEBA ......................................................................................... 2

4.2 PRUEBAS DE COMPONENTES ............................................................................................ 6
4.3 PRUEBAS DEL SISTEMA........................................................................................................ 8
4.4.- DOCUMENTACIÓN DE RESULTADOS DE PRUEBAS ................................................ 11
4.5.- ENTREGA DEL SISTEMA Y CAPACITACIÓN A USUARIOS ...................................... 14
4.6.- ENTREGA DE DOCUMENTACIÓN TECNICA Y DE USUARIO DEL SISTEMA ....... 17
REFERENCIAS .............................................................................................................................. 21

1
4.1 DISEÑOS DE CASO DE PRUEBA

Un caso de prueba o test case es, en ingeniería del software, un conjunto de

condiciones o variables bajo las cuáles un analista determinará si una aplicación,
un sistema software, o una característica de éstos es parcial o completamente
satisfactoria.

Se pueden realizar muchos casos de prueba para determinar que un requisito es

completamente satisfactorio. Con el propósito de comprobar que todos los
requisitos de una aplicación son revisados, debe haber al menos un caso de prueba
para cada requisito a menos que un requisito tenga requisitos secundarios. En ese
caso, cada requisito secundario deberá tener por lo menos un caso de prueba.
Algunas metodologías como RUP recomiendan el crear por lo menos dos casos de
prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los
requisitos y el otro debe realizar la prueba negativa.

Si la aplicación es creada sin requisitos formales, entonces los casos de prueba se

escriben basados en la operación normal de programas de una clase similar.
Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada
conocida y una salida esperada, los cuales son formulados antes de que se ejecute
la prueba. La entrada conocida debe probar una precondición y la salida esperada
debe probar una postcondición.

Bajo circunstancias especiales, podría haber la necesidad de ejecutar la prueba,

producir resultados, y luego un equipo de expertos evaluaría si los resultados se
pueden considerar como "correctos". Esto sucede a menudo en la determinación
del número del rendimiento de productos nuevos. La primera prueba se toma como
línea base para los subsecuentes ciclos de pruebas/lanzamiento del producto.

Los casos de prueba escritos, incluyen una descripción de la funcionalidad que se

probará, la cuál es tomada ya sea de los requisitos o de los casos de uso, y la
preparación requerida para asegurarse de que la prueba pueda ser dirigida.

Las variaciones de los casos de prueba son comúnmente utilizados en pruebas de

aceptación. La prueba de aceptación es realizada por un grupo de usuarios finales
o los clientes del sistema, para asegurarse que el sistema desarrollado cumple sus
requisitos. La prueba de aceptación de usuario se distingue generalmente por la
incorporación de un trayecto feliz o casos de prueba positivos.

Estructura de los casos de prueba

Formalmente, los casos de prueba escritos consisten principalmente en tres partes

con subdivisiones:

2
Introducción/visión general: Contiene información general acerca de los Casos
de Prueba.

 Identificador: Es un identificador único para futuras referencias, por ejemplo,

mientras se describe un defecto encontrado.

 Caso de prueba dueño/creador: Es el nombre del analista o diseñador de

pruebas, quien ha desarrollado pruebas o es responsable de su desarrollo.
 Versión: La actual definición del caso de prueba.

 Nombre: El caso de prueba debe ser un título entendible por personas, para
la fácil comprensión del propósito del caso de prueba y su campo de
aplicación.

 Identificador de requerimientos: el cual está incluido por el caso de prueba.

También aquí puede ser un identificador de casos de uso o de especificación
funcional.

 Propósito: Contiene una breve descripción del propósito de la prueba, y la

funcionalidad que chequea.

 Dependencias: Indica qué otros subsistemas están involucrados y en qué

grado.

Actividades de los casos de prueba

 Ambiente de prueba/configuración: Contiene información acerca de la

configuración del hardware o software en el cual se ejecutará el caso de
prueba.

 Inicialización: Describe acciones, que deben ser ejecutadas antes de que

los casos de prueba se hayan inicializado. Por ejemplo, debemos abrir algún
archivo.

 Finalización: Describe acciones, que deben ser ejecutadas después de

realizado el caso de prueba. Por ejemplo, si el caso de prueba estropea la
base de datos, el analista debe restaurarla antes de que otro caso de prueba
sea ejecutado.

 Acciones: Pasos a realizar para completar la prueba.

 Descripción de los datos de entrada

3
 Resultados

 Salida esperada: Contiene una descripción de lo que el analista debería ver

tras haber completado todos los pasos de la prueba.

 Salida obtenida: Contiene una breve descripción de lo que el analista

encuentra después de que los pasos de prueba se hayan completado.

 Resultado: Indica el resultado cualitativo de la ejecución del caso de prueba,

a menudo con un Correcto/Fallido.

 Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor,

Normal, Menor.

 Evidencia: En los casos que aplica, contiene información, bien un link al print
de pantalla, bien una consulta a una base de datos, bien el contenido de un
fichero de trazas, donde se evidencia la salida obtenida.

 Seguimiento: Si un caso de prueba falla, frecuentemente la referencia al

defecto implicado se debe enumerar en esta columna. Contiene el código
correlativo del defecto, a menudo corresponde al código del sistema de
tracking de bugs que se esté usando.

 Estado: Indica si el caso de prueba está: No iniciado, En curso, o terminado.

Tipos de pruebas

Pruebas de unidad: Verifican que el componente funciona correctamente a partir

del ingreso de diferentes casos de prueba. Los errores más comunes son
detectados en estas pruebas.
 Se examinan las estructuras de datos locales
 Se prueban condiciones límite.
 Se ejercitan todos los caminos independientes. Se utiliza un controlador
independiente para cada caso. Este es un programa que recibe las pruebas,
las envía al módulo y muestra el resultado.
Pruebas de integración: Verifican que los componentes trabajan correctamente en
forma conjunta.
 Se toman los componentes que han pasado las pruebas de unidad y se los
combina.
 Estos test sirven ya que los datos podrían perderse en alguna interfaz.
 La combinación de estos podría traer efectos que no son los esperados.

La integración puede ser: Descendente: Inician por el programa principal. En

profundidad: Integra todos los módulos de un camino de control principal de la
estructura. En anchura: Incorpora todos los módulos directamente subordinados a
cada nivel. Ascendente: Se empieza la prueba con los módulos atómicos. Datos

4
que los módulos se integran de abajo hacia arriba, el proceso requerido de los
módulos subordinados siempre está disponible, pero no así los conductores.

 Pruebas de regresión: Esta prueba consiste en volver a ejecutar un

subconjunto de pruebas que se han llevado a cabo anteriormente para
asegurarse de que los cambios que se aplicaron no han propagado efectos
colaterales no deseados.

 Pruebas de validación: Proporcionan una seguridad final de que el software

satisface los requerimientos.
o Revisión de la configuración: Asegurar que todos los elementos de
la configuración del software se hallan desarrollado apropiadamente.
o Pruebas de aceptación (ALFA y BETA): Las realiza el usuario final
en lugar del responsable del desarrollo.
 Pruebas ALFA: Desarrolladores con clientes antes de liberar
el producto.
 Pruebas BETA: Seleccionando los clientes que efectuarán la
prueba. El desarrollador no se encuentra presente.
 Pruebas del sistema: Verifica que cada elemento encaja de forma
adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total.
o Pruebas de recuperación: Se controla que el software se recupere
ante fallas. Generalmente se fuerza el fallo.
o Pruebas de seguridad: Se comprueban los mecanismos de
protección integrados.
o Pruebas de resistencia: Se diseñan para enfrentar a los programas
a situaciones anormales.
o Pruebas de rendimiento: Se prueba el sistema en tiempo de
ejecución. A veces va emparejada con la prueba de resistencia.

Los casos de prueba escritos se recogen generalmente en una suite de pruebas.

Las variaciones de los casos de prueba son comúnmente utilizados en pruebas de
aceptación. La prueba de aceptación es realizada por un grupo de usuarios finales o
los clientes del sistema, para asegurarse que el sistema desarrollado cumple sus
requisitos. La prueba de aceptación de usuario se distingue generalmente por la
incorporación de un trayecto feliz o casos de prueba positivos.

5
4.2 PRUEBAS DE COMPONENTES

En programación, una prueba unitaria o de componente es una forma de comprobar

el correcto funcionamiento de una unidad de código. Por ejemplo en diseño
estructurado o en diseño funcional una función o un procedimiento, en diseño
orientado a objetos una clase. Esto sirve para asegurar que cada unidad funcione
correctamente y eficientemente por separado. Además de verificar que el código
hace lo que tiene que hacer, verificamos que sea correcto el nombre, los nombres
y tipos de los parámetros, el tipo de lo que se devuelve, que si el estado inicial es
válido entonces el estado final es válido

La idea es escribir casos de prueba para cada función no trivial o método en el

módulo, de forma que cada caso sea independiente del resto. Luego, con las
Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema
o subsistema en cuestión.

Características

Para que una prueba unitaria tenga la calidad suficiente se deben cumplir los
siguientes requisitos:

Automatizable: No debería requerirse una intervención manual. Esto es

especialmente útil para integración continua.

Completas: Deben cubrir la mayor cantidad de código.

Repetibles o Reutilizables: No se deben crear pruebas que sólo puedan ser

ejecutadas una sola vez. También es útil para integración continua.

Independientes: La ejecución de una prueba no debe afectar a la ejecución de otra.

Profesionales: Las pruebas deben ser consideradas igual que el código, con la
misma profesionalidad, documentación, etc.

Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se

recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.

Ventajas

El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que
las partes individuales son correctas. Proporcionan un contrato escrito que el trozo
de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas
básicas:

6
Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el
código para mejorar su estructura (lo que se ha dado en llamar refactorización),
puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los
nuevos cambios no han introducido errores.

Simplifica la integración: Puesto que permiten llegar a la fase de integración con

un grado alto de seguridad de que el código está funcionando correctamente. De
esta manera se facilitan las pruebas de integración.

Documenta el código: Las propias pruebas son documentación del código puesto
que ahí se puede ver cómo utilizarlo.

Separación de la interfaz y la implementación: Dado que la única interacción

entre los casos de prueba y las unidades bajo prueba son las interfaces de estas
últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando
objetos mock (mock object) para simular el comportamiento de objetos complejos.

Los errores están más acotados y son más fáciles de localizar: Dado que
tenemos pruebas unitarias que pueden desenmascararlos.

Limitaciones

Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los
errores del código. Algunos enfoques se basan en la generación aleatoria de objetos
para amplificar el alcance de las pruebas de unidad. Esta técnica se conoce como
testing aleatorio (RT, por random testing). Por definición, sólo prueban las unidades
por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de
rendimiento y otros problemas que afectan a todo el sistema en su conjunto.
Además, puede no ser trivial anticipar todos los casos especiales de entradas que
puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias
sólo son efectivas si se usan en conjunto con otras pruebas de software.

7
4.3 PRUEBAS DEL SISTEMA

Las pruebas del sistema tienen como objetivo ejercitar profundamente el sistema
comprobando la integración del sistema de información globalmente, verificando el
funcionamiento correcto de las interfaces entre los distintos subsistemas que lo
componen y con el resto de sistemas de información con los que se comunica.

Son pruebas de integración del sistema de información completo, y permiten probar

el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar
que las especificaciones funcionales y técnicas se cumplen. Dan una visión muy
similar a su comportamiento en el entorno de producción.

Una vez que se han probado los componentes individuales y se han integrado, se
prueba el sistema de forma global.

Descripción de la Prueba

Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados
directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas
pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos,
y la implementación apropiada de las reglas de negocios. Este tipo de pruebas se
basan en técnicas de caja negra, esto es, verificar el sistema (y sus procesos
internos), la interacción con las aplicaciones que lo usan vía GUI y analizar las
salidas o resultados.
En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen,
desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.

La prueba de Sistema incluye:

 Pruebas funcionales. Dirigidas a asegurar que el sistema de información

realiza correctamente todas las funciones que se han detallado en las
especificaciones dadas por el usuario del sistema.

 Pruebas de comunicaciones. Determinan que las interfaces entre los

componentes del sistema funcionan adecuadamente, tanto a través de
dispositivos remotos, como locales. Asimismo, se han de probar las
interfaces hombre/maquina.

 Pruebas de rendimiento. Consisten en determinar que los tiempos de

respuesta están dentro de los intervalos establecidos en las especificaciones
del sistema.

 Pruebas de volumen. Consisten en examinar el funcionamiento del sistema

cuando está trabajando con grandes volúmenes de datos, simulando las
cargas de trabajo esperadas.

8
  Pruebas de sobrecarga. Consisten en comprobar el funcionamiento del
sistema en el umbral límite de los recursos, sometiéndole a cargas masivas.
El objetivo es establecer los puntos extremos en los cuales el sistema
empieza a operar por debajo de los requisitos establecidos.

 Pruebas de disponibilidad de datos. Consisten en demostrar que el

sistema puede recuperarse ante fallos, tanto de equipo físico como lógico,
sin comprometer la integridad de los datos.

 Pruebas de facilidad de uso. Consisten en comprobar la adaptabilidad del

sistema a las necesidades de los usuarios, tanto para asegurar que se
acomoda a su modo habitual de trabajo, como para determinar las facilidades
que aporta al introducir datos en el sistema y obtener los resultados.

 Pruebas de operación. Consisten en comprobar la correcta implementación

de los procedimientos de operación, incluyendo la planificación y control de
trabajos, arranque y rearranque del sistema, etc.

 Pruebas de entorno. Consisten en verificar las interacciones del sistema

con otros sistemas dentro del mismo entorno.

 Pruebas de seguridad. Consisten en verificar los mecanismos de control de

acceso al sistema para evitar alteraciones indebidas en los datos.

Para sistemas web se recomienda especialmente realizar mínimo el siguiente

grupo de pruebas de sistema:

· Humo.
· Usabilidad
· Performance
· Funcionalidad

Para capitalizar el trabajo hasta ahora completado, los casos de prueba de las
pruebas previas realizadas pueden frecuentemente ser reorganizados y rehusados
durante la prueba de sistema. No obstante, deben ser desarrollados casos de
prueba adicionales para aquellos aspectos del sistema, tales como documentación,
procedimientos y desempeño que no han sido probados durante la prueba unitaria
y de integración.

La prueba de sistema es compleja porque intenta validar un número de

características al mismo tiempo, a diferencia de otras pruebas que sólo se centran
en uno o dos aspectos del sistema al mismo tiempo.

9
Técnica

 Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e
inválidos, para verificar que:
o Los resultados esperados ocurren cuando se utiliza un dato válido.
 Los mensajes de error o de advertencia aparecen en el momento adecuado,
cuando se utiliza un dato inválido.
 Cada regla de negocios es aplicada adecuadamente.

Criterio de Completitud

 Todas las pruebas planeadas han sido ejecutadas.

 Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales

 Identifique o describa aquellos aspectos (internos o externos) que impactan

la implementación y ejecución de las pruebas del Sistema

10
4.4.- DOCUMENTACIÓN DE RESULTADOS DE PRUEBAS

En general se habla mucho de la documentación, pero no se la hace, no se le asigna

presupuesto, no se la mantiene y casi nunca está al día en los proyectos de
desarrollo de software. Lo importante es la disponibilidad de la documentación que
se necesita en el momento en que se la necesita.
Muchas veces se hace porque hay que hacerla y se escribe, con pocas ganas,
largos textos, a la vez que se está convencido de estar haciendo un trabajo inútil. A
veces se peca por exceso y otras por defecto. Ocurre mucho en la Web y con
productos RAD. En ocasiones se olvida que el mantenimiento también debe llegar
a la documentación.
La documentación se suele clasificar en función de las personas o grupos a los
cuales está dirigida:

• Documentación para los desarrolladores

• Documentación para los usuarios
• Documentación para los administradores o soporte técnico

La documentación para desarrolladores es aquélla que se utiliza para el propio

desarrollo del producto y, sobre todo, para su mantenimiento futuro. Se documenta
para comunicar estructura y comportamiento del sistema o de sus partes, para
visualizar y controlar la arquitectura del sistema, para comprender mejor el mismo y
para controlar el riesgo, entre otras cosas. Obviamente, cuanto más complejo es el
sistema, más importante es la documentación.
En este sentido, todas las fases de un desarrollo deben documentarse:
requerimientos, análisis, diseño, programación, pruebas, etc. Una herramienta muy
útil en este sentido es una notación estándar de modelado, de modo que mediante
ciertos diagramas se puedan comunicar ideas entre grupos de trabajo.
Hay decenas de notaciones, tanto estructuradas como orientadas a objetos. Un
caso particular es el de UML, que analizamos en otra obra. De todas maneras, los
diagramas son muy útiles, pero siempre y cuando se mantengan actualizados, por
lo que más vale calidad que cantidad. La documentación para desarrolladores a
menudo es llamada modelo, pues es una simplificación de la realidad para
comprender mejor el sistema como un todo.
Otro aspecto para tener en cuenta cuando se documenta o modela, es el del nivel
de detalle.
Así como cuando construimos planos de un edificio podemos hacer planos
generales, de arquitectura, de instalaciones y demás, también al documentar el
software debemos cuidar el nivel de detalle y hacer diagramas diferentes en función
del usuario de la documentación, concentrándonos en un aspecto a la vez. De toda
la documentación para los desarrolladores, nos interesa especialmente en esta obra
aquella que se utiliza para documentar la programación, y en particular hemos

11
analizado la que se usa para documentar desarrollos orientados a objetos en el
capítulo respectivo.
La documentación para usuarios es todo aquello que necesita el usuario para la
instalación, aprendizaje y uso del producto. Puede consistir en:

1. guías de instalación
2. guías del usuario
3. manuales de referencia
4. guías de mensajes

En el caso de los usuarios que son programadores, verbigracia los clientes de

nuestras clases, esta documentación se debe acompañar con ejemplos de uso
recomendados o de muestra y una reseña de efectos no evidentes de las
bibliotecas. Más allá de todo esto, debemos tener en cuenta que la estadística
demuestra que los usuarios no leen los manuales a menos que nos les quede otra
opción. Las razones pueden ser varias, pero un análisis de la realidad muestra que
se recurre a los manuales solamente cuando se produce un error o se desconoce
cómo lograr algo muy puntual, y recién cuando la ayuda en línea no satisface las
necesidades del usuario. Por lo tanto, si bien es cierto que debemos realizar
manuales, la existencia de un buen manual nunca nos libera de hacer un producto
amigable para el usuario, que incluso contenga ayuda en línea. Es incluso deseable
proveer un software tutorial que guíe al usuario en el uso del sistema, con apoyo
multimedial, y que puede llegar a ser un curso online. Buena parte de la
documentación para los usuarios puede empezar a generarse desde que comienza
el estudio de requisitos del sistema. Esto está bastante en consonancia con las
ideas de extreme programming y con metodologías basadas en casos de uso. La
documentación para administradores o soporte técnico, a veces llamada manual de
operaciones, contiene toda la información sobre el sistema terminado que no hace
al uso por un usuario final. Es necesario que tenga una descripción de los errores
posibles del sistema, así como los procedimientos de recuperación. Como esto no
es algo estático, pues la aparición de nuevos errores, problemas de compatibilidad
y demás nunca se puede descartar, en general el manual de operaciones es un
documento que va engrosándose con el tiempo.

Ventajas de una documentación de pruebas

 Fomentan el cambio: Las pruebas unitarias facilitan que el programador

cambie el código para mejorar su estructura, puesto que permiten hacer
pruebas hacer pruebas sobre cambios y así asegurarse el que los nuevos
cambios no han introducido errores.

12
  Simplifica la integración: Puesto que permiten llegar a la fase de
integración con un alto grado de seguridad de que el código está funcionando
correctamente.

 Documentación del código: Las propias pruebas son documentación del

código puesto que ahí se puede ver cómo utilizarlo.

 Separación de la interfaz y la implementación: Dado que la única

interacción entre los casos cualquiera de los dos sin afectar al otro.

Documentos asociados

 Plan de Pruebas: Al principio se desarrollará una planificación general, que

quedará reflejada en el “Plan de Pruebas”. El plan de pruebas se inicia el
proceso de Análisis del Sistema.

 Especificación del diseño de pruebas. De la ampliación y detalle del plan

de pruebas, surge el documento “Especificación del diseño de pruebas”.

 Especificación de un caso de prueba. Los casos de prueba se concretan

a partir de la especificación del diseño de pruebas.

 Especificación de procedimiento de prueba. Una vez especificado un

caso de prueba, será preciso detallar el modo en que van a ser ejecutados
cada uno de los casos de prueba, siendo recogido en el documento
“Especificación del procedimiento de prueba”.

 Registro de pruebas. En el “Registro de pruebas” se registrarán los sucesos

que tengan lugar durante las pruebas.

13
4.5.- ENTREGA DEL SISTEMA Y CAPACITACIÓN A USUARIOS

Una entrega es el resultado del proyecto que se entrega al cliente/usuario. De forma

general se entrega al final de una fase principal del proyecto de especificación, el
diseño, etcétera. Como regla general las entregas son hitos, pero estos no son
necesariamente entregas. Las entregas del proyecto, las cuales son entregadas al
cliente/usuario, son la definición y especificación de requerimientos.

Capacitación a usuarios

Los analistas de sistemas se involucran en un proceso educacional con los usuarios

que es llamado capacitación. A lo largo del ciclo de vida de desarrollo de sistemas
los usuarios han estado involucrados, por lo que ahora el analista debe poseer una
valoración adecuada de los usuarios que deben ser capacitados. Los centros de
información mantienen instructores propios.

En la implementación de grandes proyectos, el analista estafa frecuentemente

analizando la capacitación en vez de estar personalmente involucrado en él. Uno
de los valores más preciados que puede dar el analista a cualquier situación de
capacitación es la capacidad de ver el sistema desde el punto de vista del usuario.
El analista nunca debe olvidar qué es el enfrentar un nuevo sistema. Estos
recuerdos pueden ayudar a que el analista empatice con os usuarios y facilite su
capacitación.

Estrategias de capacitación

Las estrategias de capacitación son determinadas por quien está siendo capacitado
y quien lo capacitara. El analista querrá asegurarse de que cualquiera cuyo trabajo
este afectado por el nuevo sistema de información esté capacitado adecuadamente
por el instructor adecuado.

A quien capacitar. Todas las personas que tendrán uso primario o secundario del
sistema deben ser capacitadas. Esto incluye a todos, desde el personal de captura
de datos hasta aquellos que usaran la salida para tomar decisiones sin usar
personalmente una computadora. La cantidad de capacitación que requiere un
sistema depende, por lo tanto, de qué tanto cambiara el trabajo de alguien debido
al nuevo sistema.

Hay que asegurarse de que estén separados usuarios de diferentes niveles de

habilidades e intereses de trabajo. Es ciertamente problemático incluir novatos
en las mismas sesiones de capacitación con los expertos, debido a que los novatos
se pierden rápidamente y los expertos rápidamente se aburren con los puntos
básicos. Ambos grupos quedan perdidos.

14
Las personas capacitaran a los usuarios. Para un proyecto grande, se pueden
usar muchos instructores diferentes, dependiendo de que tantos usuarios deben ser
capacitados y quienes son. Las fuentes de capacitación posibles incluyen:

1. Vendedores.
2. Analistas de sistemas.
3. Instructores pagados externamente.
4. Instructores en casa.
5. Otros usuarios del sistema.

Esta lista da solamente unas cuantas de las operaciones que tiene el analista para
planear y proporcionar la capacitación.

Los grandes vendedores frecuentemente proporcionan capacitación gratuita fuera

de sitio y de uno o dos días en sus instalaciones. Estas sesiones incluyen tanto
platicas como capacitación practica en un ambiente enfocado.

Debido a que los analistas de sistemas conocen al personal de la organización y al

sistema, frecuentemente pueden proporcionar buena capacitación. El uso de
analistas con objeto de capacitar depende de su disponibilidad, debido a que
también se espera que supervisen todo el proceso de implementación.

Los instructores pagados externamente a veces son llamados a la organización para

que ayuden con la capacitación. Pueden tener amplia experiencia en enseñar a la
gente como usar una diversidad de computadoras, pero tal vez no den la
capacitación practica necesario para algunos usuarios. Además, tal vez no sean
capaces de personalizar sus presentaciones lo suficiente para hacerlas
significativas a los usuarios.

Los instructores de casa de tiempo completo están, por lo general, familiarizados

con el personal y pueden adecuar los materiales a sus necesidades. Una de las
desventajas de los instructores de casa es que pueden poseer experiencia en otras
áreas, pero no en sistemas de información, y tal vez les falte, por lo tanto, la
profundidad que necesitan los usuarios.

También es posible hacer que cualquiera de esos instructores capacite a un

pequeño grupo de personas de cada área funcional que usara el nuevo sistema de
información. Ellos a su vez pueden ser requeridos para que capaciten a los usuarios
restantes. Este enfoque puede trabajar bien si los capacitados originalmente todavía
tienen acceso a los materiales e instructores como recursos cuando están ellos

15
mismos proporcionando la capacitación. En caso contrario, puede degenerar en una
situación de prueba y error, en vez de una estructurada.

LINEAMIENTOS PARA LA CAPACITACIÓN.

El analista tiene cuatro lineamientos principales para ajustar una capacitación. Son:

1. Establecimiento de objetivos mensurables.

2. Uso de métodos de capacitación adecuados.
3. Selección de lugares de capacitación adecuados.
4. Empleo de materiales de capacitación comprensibles.

16
4.6.- ENTREGA DE DOCUMENTACIÓN TECNICA Y DE USUARIO
DEL SISTEMA

DOCUMENTACION TECNICA

El manual técnico es documentación externa que describe con profundidad las

características técnicas y funcionamiento del programa (o sistema). Está destinado
a los programadores y sirve de referencia para darle mantenimiento al sistema
durante su vida útil. Los elementos generales de un manual técnico son:
a) Propósitos y funcionamiento del programa.
b) Esquema lógico del funcionamiento del programa
c) Nuevos tipos definidos, principales variables globales, archivos utilizados, etc.
d) Explicación de fórmulas y procesos complejos.
e) Especificación de datos de entrada y datos de salida
f) Formato de los archivos y de las pantallas.
g) Datos utilizados en las pruebas.
h) Puntos débiles y futuras expansiones.
i) Guía de Referencia de Rutinas.
j) Diagramas.
k) Listado del programa fuente.
l) Otras características técnicas

Este manual suele quedarse en el lugar de desarrollo, tanto para futuros cambios,
como para verificar que fue correctamente instalado; por ejemplo, si una vez que el
programa ha sido puesto en funcionamiento ocurre un error, los datos de prueba
servirán como parámetro para tratar de detectar cuál fue el percance. Otra
información útil que puede tener este manual es el tamaño (en bytes) de los archivos
ejecutables, pues un cambio inesperado podría sugerir la presencia de un virus.
Otro de los puntos interesantes son los puntos débiles, mencionarlos puede servir
para saber por dónde podría fallar el programa en algún momento, o por donde se
le puede mejorar. Si usted ha trabajado con componentes electrónicos,
seguramente conocerá la importancia del manual que detalla todas las
características y funcionamiento de estos. Otro ejemplo de documentación técnica
son los manuales que describen elementos importantes de una computadora, como
su mapa de memoria, asignación de puertos o interrupciones, y los libros que
indican los parámetros de esas interrupciones y su propósito.

USUARIO DEL SISTEMA.

El Manual de Usuario expone los procesos que el usuario puede realizar con el
sistema implantado, instruyéndolo en su uso y en la solución de los problemas que
puedan suceder durante la operación. Para lograr esto, es necesario que se detallen
todas las características que tienen los programas y la forma de acceder e introducir
la información. Permite a los usuarios conocer en detalle qué actividades deberán

17
desarrollar para la consecución de los objetivos del sistema. Reúne la información,
normas y documentación necesarias para que el usuario conozca y utilice
adecuadamente la aplicación desarrollada.

Confección

Para la elaboración de un manual de usuario se deberán de integrar los siguientes

apartados normativos.
 Nombre del Sistema: Nombre del sistema al que se refiere el manual.
 Versión del Sistema: La versión del sistema en el manual nos permitirá
mantener un control sobre las modificaciones que han afectado al sistema
original.
 Tipo de Manual: Se especifica el tipo de manual al que se hace referencia ya
permitiendo tener un control en nuestros manuales, además de una fácil
identificación.
 Poner una Imagen: Es recomendable ilustrar el manual con una imagen
representativa del sistema.
 Fecha de Elaboración: Es importante el incluir la fecha de elaboración, pues
representa un punto de referencia y control.
 Área donde fue elaborado: Incluir el nombre del área en donde fue elaborado
el manual.
 Índice del Contenido del Manual: Deberá contar con un índice y/o contenido
del manual para facilitar su manejo e identificación de los puntos importantes,
pues si sólo se busca un punto en específico con el índice es fácil
identificarlo.
 Presentación: Breve descripción general del manual.

Generalidades del Sistema

I. Descripción del Producto: Muestra las secciones que integran el sistema, la

seguridad de este y su alcance.
II. Uso de Teclas: Se ilustrará con imágenes y se mencionará el uso que tiene cada
una de las teclas del teclado que intervienen en el sistema.
III. Botones Generales usados en el Sistema: Mostrar con imágenes todos los
botones, explicando su funcionamiento dentro del sistema.
IV. Ayudas del Sistema: Describir las diferentes formas en las que se puede obtener
ayuda mientras se trabaja con el sistema.

Requerimientos Técnicos del Sistema, Instalación y Configuración

I. Definición de los Requerimientos Técnicos del Sistema: Especificar las
herramientas y plataformas necesarias para la instalación de la aplicación.
II. Instalación: Establecer los pasos para la instalación del sistema.
III. Configuración: Definir los pasos para la configuración del sistema.

18
Entrada y Salida del Sistema

I. Entrada al Sistema: Explicar detalladamente las pantallas principales que

aparecen al momento de entrar a la aplicación. Se recomienda ilustrar con imágenes
las ventanas para un mejor entendimiento, lo cual puede ser:
I.I. Por medio de un ICONO que represente el acceso directo al sistema.
I.II Explicando al usuario la ruta en la que se encuentra el archivo ejecutable.
II. Salida del Sistema: En esta sección se explicará la forma de cómo salir del
sistema, describiendo detalladamente las pantallas principales que aparecen al
momento de salir de la aplicación. Se recomienda ilustrar con imágenes las
ventanas para un mejor entendimiento.

Uso de la Aplicación

I. Diagrama Conceptual General de Funcionamiento: Representar gráficamente la

forma en que funciona el sistema, con sus diferentes conexiones e intervenciones
por el usuario, acompañada de una breve explicación.
II. Módulo: Especificar para cada uno de los módulos que contemple el sistema el
nombre y la descripción, incluyendo un diagrama de flujo de la información mediante
el cual se represente el funcionamiento y uso de cada una de las funcionalidades
que lo conforman.
III. Ventana o Pantalla: Utilizar imágenes o capturas de pantalla, para describir el
uso y funcionamiento de cada uno de los elementos que conforman cada
funcionalidad del módulo.

Manejo de Errores
Tabla de Errores: En esta sección se presentará una lista con los posibles errores
que maneja el sistema, seguido de una propuesta de solución.

Contingencias y Soporte Técnico

En esta sección se especificarán los contactos asociados a las labores de soporte
técnico, incluyendo nombre, e-mail y teléfonos.

Glosario de Términos
Incluye una lista con el significado de los términos, conceptos o tecnicismos, usados
en este manual y que no son del dominio público.

Anexos
Este punto se utilizará en caso de ser necesario, para ilustrar con mayor
profundidad aspectos asociados a las funcionalidades del sistema.

Encabezado y Pie de Página

19
Cada página del manual tendrá un encabezado y pie con información
representativa. Pueden incluir datos importantes como el nombre de dicho manual,
el número de la versión, fecha de modificación, el número de página, entre otros
elementos. Esto permitirá al usuario entre otras cosas la rápida navegación e
identificación de temas.

Estándares de Elaboración del Manual

Toda la documentación que se relacione con un sistema ya sea impresa o digital,

sencilla o compleja, debe reunir los siguientes requisitos básicos:
Debe ser rotulada con claridad y bien organizada en carpetas e índice, con
secciones claramente indicadas.
 Los diagramas deberán ser claros, no aglomerados y la escritura manuscrita
ha de ser legible.
 La documentación deberá ser completa.
 Se incluirá una leyenda o explicación de los términos utilizados.
 La documentación siempre se conserva actualizada.
 El estilo de redacción de los manuales de documentación debe:
 Ser concreto.
 Definir los términos utilizados.
 Utilizar títulos, subtítulos y párrafos cortos.
 Emplear formas activas en lugar de pasivas.
 Aplicar correctamente las referencias bibliográficas.
 No usar frases largas que presenten hechos distintos.

20
REFERENCIAS

https://manuel.cillero.es/doc/metrica-3/tecnicas/pruebas/sistema/
http://www.juntadeandalucia.es/servicios/madeja/contenido/libro-pautas/227
https://gist.github.com/brunocascio/5e89fafa7fd86bdd1a715d2f6f0432d1
http://clases3gingsof.wikifoundry.com/page/Pruebas
http://ing-sw.blogspot.mx/2005/04/tipos-de-pruebas-de-software.html
http://materias.fi.uba.ar/7507/content/20101/lecturas/documentacion_pruebas.pdf
http://www.arqhys.com/general/documentacion-tecnica-de-un-programa.html.
http://talleriswu4.blogspot.mx/2009/04/45-implementacion-y-capacitacion-de.html

21