TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO DE ACAPULCO

CARRERA: ING. EN SISTEMAS COMPUTACIONALES.

INGENIERÍA DE SOFTWARE(IS4)

MAESTRA: ING. MARIA NANCY GARCIA CASTRO.

ACTIVIDAD:

TEMA 3, TRABAJO DE INVESTIGACION TEMA IV.

EQUIPO 7:

· DIEGO JESUS CALIXTO FRANCISCO (N°Control: 19320907)

· NEFTALI VLADIMIR BAÑOS OLEA (N°Control: 19320896)

· RUBEN NAVA HERNANDEZ (N°Control: 19321032)

· GERARDO CALDERON PALMA (N°Control: 19320906)

· ROBERTO CARLOS BRITO RAYON (N°Control: 19320903)

HORARIO: 1:00 P.M- 2:00 P.M.

CICLO ESCOLAR ENERO 2022 – JUNIO 2022

SEMESTRE: 6

ACAPULCO, GRO. 02 DE (Junio) (2022)

Índice
Contenido
Introducción...................................................................................................................................3
4.-Pruebas e Implementación.....................................................................................................4
4.1 Diseño de caso de prueba................................................................................................5
4.2 Pruebas de Componentes..............................................................................................11
4.3 Pruebas del Sistemas......................................................................................................12
4.4 Documentación de resultados de las pruebas..........................................................14
4.5 Entrega del sistema y capacitación a usuarios.........................................................16
4.6 Entrega de documentación técnica y de usuario del sistema...............................23
Conclusión....................................................................................................................................25
Bibliografía....................................................................................................................................26

Índice de imágenes.
Ilustración 1 Particiones de equivalencia.........................................................................7

Ilustración 2 Pruebas Estructurales..................................................................................8

Ilustración 3 Clases de equivalencia de la búsqueda binaria........................................8

Ilustración 4 Grafo de fujo................................................................................................10

Introducción
Como se sabe, realizare pruebas al sistema que se está desarrollando es muy importante,
debido a que con estas pruebas nos daremos cuenta de los fallos o posibles fallos del
programa, es por lo que saber implementar estas pruebas es necesario, ya que con ellas
se detectaron los errores que contiene el programa.

En esta investigación, se presentarán todos los temas de la unidad 4 “Pruebas e

implementación” junto con todos sus subtemas, para que tengamos claro cuáles son las
pruebas que se pueden implementar, para poder validar que el programa desarrollado no
tenga fallas o que se puedan detectar las fallas que tiene o verificar que no tenga posibles
fallas, para que el programa sea entregado de la manera correcta.

El objetivo de esta investigación es, que comprendamos conceptos nuevos para que sean
necesarios para la implementación de las pruebas en el sistema, que se comprendan
cuáles son los tipos de pruebas que se pueden implementar en el sistema y cuáles son
las condiciones para validar que el sistema está listo para ser entregado.
4.-Pruebas e Implementación.
El desarrollo de sistemas de software implica una serie de actividades de producción en
las que las posibilidades de que aparezca el fallo humano son enormes. Los errores
pueden empezar a darse desde el primer momento del proceso, en el que los objetivos
pueden estar especificados de forma errónea o imperfecta, así como en posteriores pasos
de diseño y desarrollo. Debido a la imposibilidad humana de trabajar y comunicarse de
forma perfecta, el desarrollo de software ha de ir acompañado de una actividad que
garantice la calidad.
Las pruebas del software son un elemento crítico para la garantía de calidad del software
y representa una revisión final de las especificaciones, del diseño y de la codificación. La
creciente percepción del software como un elemento del sistema y la importancia de los
«costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas
minuciosas y bien planificadas. No es raro que una organización de desarrollo de software
emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En
casos extremos, las pruebas del software para actividades críticas (por ejemplo, control
de tráfico aéreo, control de reactores nucleares) puede costar de tres a cinco veces más
que el resto de los pasos de la ingeniería del software juntos.

Objetivos de las pruebas.

Los principales objetivos son:
1. La prueba es el proceso de ejecución de un programa con la intención de
descubrir un error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un
error no descubierto hasta entonces.
3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.
Nuestro objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes
clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo. Si la prueba
se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido),
descubrirá errores en el software. Como ventaja secundaria, la prueba demuestra hasta
qué punto las funciones del software parecen funcionar de acuerdo con las
especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos
que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena
indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software
como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede
demostrar que existen defectos en el software.

Principios de las pruebas.

Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un
ingeniero del software deberá entender los principios básicos que guían las pruebas del
software. Davis [DAV95] sugiere un conjunto de principios de prueba:
  A todas las pruebas se les debería poder hacer un seguimiento hasta los
requisitos del cliente. El objetivo de las pruebas del software es descubrir
errores. Se entiende que los defectos más graves (desde el punto de vista del
cliente) son aquellos que impiden al programa cumplir sus requisitos.
 Las pruebas deberían planificarse mucho antes de que empiecen. La
planificación de las pruebas puede empezar tan pronto como esté completo el
modelo de requisitos. La definición detallada de los casos de prueba puede
empezar tan pronto como el modelo de diseño se ha consolidado. Por tanto, se
pueden planificar y diseñar todas las pruebas antes de generar ningún código.
 El principio de Pareto es aplicable a la prueba del software. Dicho de manera
sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores
descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20
por 100 de todos los módulos del programa. El problema, por supuesto, es aislar
estos módulos sospechosos y probarlos concienzudamente.
 Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo
grande». Las primeras pruebas planeadas y ejecutadas se centran generalmente
en módulos individuales del programa. A medida que avanzan las pruebas,
desplazan su punto de mira en un intento de encontrar errores en grupos
integrados de módulos y finalmente en el sistema entero.
 No son posibles las pruebas exhaustivas. El número de permutaciones de
caminos para incluso un programa de tamaño moderado es excepcionalmente
grande. Por este motivo, es imposible ejecutar todas las combinaciones de
caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la
lógica del programa y asegurarse de que se han aplicado todas las condiciones en
el diseño a nivel de componente.
 Para ser más eficaces, las pruebas deberían ser realizadas por un equipo
independiente. Por «más eficaces» queremos referirnos a pruebas con la más
alta probabilidad de encontrar errores. el ingeniero del software que creó el
sistema no es el más adecuado para llevar a cabo las pruebas para el software.

4.1 Diseño de caso de prueba

El diseño de casos de prueba es una parte de las pruebas de componentes y sistemas en
las que se diseñan los casos de prueba (entradas y salidas esperadas) para probar el
sistema. El objetivo del proceso de diseño de casos de prueba es crear un conjunto de
casos de prueba que sean efectivos descubriendo defectos en los programas y muestren
que el sistema satisface sus requerimientos.
Para diseñar un caso de prueba, se selecciona una característica del sistema o
componente que se está probando. A continuación, se selecciona un conjunto de
entradas que ejecutan dicha característica, documenta las salidas esperadas o rangos de
salida y, donde sea posible, se diseña una prueba automatizada que prueba que las
salidas reales y esperadas son las mismas.
Existen varias aproximaciones que pueden seguirse para diseñar casos de prueba:

 Pruebas basadas en requerimientos, en donde los casos de prueba se diseñan

para probar los requerimientos del sistema. Esta aproximación se utiliza
 principalmente en la etapa de pruebas del sistema, ya que los requerimientos del
sistema normalmente se implementan por varios componentes. Para cada
requerimiento, se identifica casos de prueba que puedan demostrar que el sistema
satisface ese requerimiento.
 Pruebas de particiones, en donde se identifican particiones de entrada y salida y
se diseñan pruebas para que el sistema ejecute entradas de todas las particiones
y genere salidas en todas las particiones. Las particiones son grupos de datos que
tienen características comunes, como todos los números negativos, todos los
nombres con menos de 30 caracteres, todos los eventos provocados por la
elección de opciones en un menú, y así sucesivamente.
 Pruebas estructurales, en donde se utiliza el conocimiento de la estructura del
programa para diseñar pruebas que ejecuten todas las partes del programa.
Esencialmente, cuando se prueba un programa, debería intentarse ejecutar cada
sentencia al menos una vez. Las pruebas estructurales ayudan a identificar casos
de prueba que pueden hacer esto posible.
Pruebas basadas en requerimientos.
Un principio general de ingeniería de requerimientos es que los requerimientos deberían
poder probarse. Es decir, los requerimientos deberían ser escritos de tal forma que se
pueda diseñar una prueba para que un observador pueda comprobar que los
requerimientos se satisfacen. Las pruebas basadas en requerimientos, por lo tanto, son
una aproximación sistemática al diseño de casos de prueba en donde el usuario
considera cada requerimiento y deriva un conjunto de pruebas para cada uno de ellos.
Las pruebas basadas en requerimientos son pruebas de validación en lugar de pruebas
de defectos, el usuario intenta demostrar que el sistema ha implementado sus
requerimientos de forma adecuada.

Pruebas de particiones.
Los datos de entrada y los resultados de salida de un programa normalmente se pueden
agrupar en varias clases diferentes que tienen características comunes tales como
números positivos, números negativos y selecciones de menús. Los programas
normalmente se comportan de una forma similar para todos los miembros de una clase.
Es decir, si se prueba un programa que realiza algún cálculo y requiere dos números
positivos, entonces se esperaría que el programa se comportase de la misma forma para
todos los números positivos.
Debido a este comportamiento equivalente, estas clases se denominan a menudo
particiones de equivalencia o dominios. Una aproximación sistemática al diseño de casos
de prueba se basa en identificar todas las particiones para un sistema o componente. Los
casos de prueba se diseñan para que las entradas o salidas pertenezcan a estas
particiones. Las pruebas de particiones pueden utilizarse para diseñar casos de prueba
tanto para sistemas como para componentes.
En la Figura 1, cada partición de equivalencia se muestra como una elipse. Las
particiones de equivalencia son conjuntos de datos en donde todos los miembros de los
conjuntos deberían ser procesados de forma equivalente. Las particiones de equivalencia
de salida son resultados del programa que tienen características comunes, por lo que
pueden considerarse como una clase diferente. También se identifican particiones en
donde las entradas están fuera de otras particiones que se han elegido. Estas prueban si
el programa maneja entradas inválidas de forma correcta. Las entradas válidas e inválidas
también forman particiones de equivalencia.

Ilustración 1 Particiones de equivalencia.

Una vez que se ha identificado un conjunto de particiones, pueden elegirse casos de

prueba de cada una de estas particiones. Una buena práctica para la selección de casos
de prueba es elegir casos de prueba en los límites de las particiones junto con casos de
prueba cercanos al punto medio de la partición. La razón de esto es que los diseñadores y
programadores tienden a considerar valores típicos de entradas cuando desarrollan un
sistema. Estos se prueban eligiendo el punto medio de la partición. Los valores límite son
a menudo atípicos, por lo que los diseñadores los pasan por alto. Los fallos de ejecución
de los programas a menudo ocurren cuando se procesan estos valores atípicos.

Pruebas estructurales.
Las pruebas estructurales (Figura 2) son una aproximación al diseño de casos de prueba
en donde las pruebas se derivan a partir del conocimiento de la estructura e
implementación del software. Esta aproximación se denomina a veces pruebas de «caja
blanca», de «caja de cristal» o de «caja transparente» para distinguirlas de las pruebas de
caja negra.
 Ilustración 2 Pruebas Estructurales.

La comprensión del algoritmo utilizado en un componente puede ayudar a identificar

particiones adicionales y casos de prueba. Para ilustrar esto, se ha implementado la
especificación de la rutina de búsqueda (Figura 3) como una rutina de búsqueda binaria.
Por supuesto, ésta tiene precondiciones más estrictas. La secuencia se implementa como
un vector, este vector debe estar ordenado y el valor del límite inferior del vector debe ser
menor que el valor del límite superior.

Ilustración 3 Clases de equivalencia de la búsqueda binaria.

Pruebas de camino.
Las pruebas de caminos son una estrategia de pruebas estructurales cuyo objetivo es
probar cada camino de ejecución independiente en un componente o programa. Si cada
camino es independiente, entonces todas las sentencias en el componente deben
haberse ejecutado al menos una vez. Además, todas las sentencias condicionales
comprueban para los casos verdadero y falso. En un proceso de desarrollo orientado a
objetos, pueden utilizarse las pruebas de caminos cuando se prueban los métodos
asociados a los objetos.
El número de caminos en un programa es normalmente proporcional a su tamaño. Puesto
que los módulos se integran en sistemas, no es factible utilizar técnicas de pruebas
estructurales. Por lo tanto, las técnicas de pruebas de caminos son principalmente
utilizadas durante las pruebas de componentes.
Las pruebas de caminos no prueban todas las posibles combinaciones de todos los
caminos en el programa. Para cualquier componente distinto de un componente trivial sin
bucles, éste es un objetivo imposible. Existe un número infinito de posibles combinaciones
de caminos en los programas con bucles. Incluso cuando todas las sentencias del
programa se han ejecutado al menos una vez, los defectos del programa todavía pueden
aparecer cuando se combinan determinados caminos.
El punto de partida de una prueba de caminos es un grafo de flujo del programa. Este es
un modelo del esqueleto de todos los caminos en el programa. Un grafo de flujo consiste
en nodos que representan decisiones y aristas que muestran el flujo de control. El grafo
de flujo se construye reemplazando las sentencias de control del programa por diagramas
equivalentes. Si no hay sentencias goto en un programa, es un proceso sencillo derivar su
grafo de flujo. Cada rama en una sentencia condicional (if-then-else o case) se muestra
como un camino independiente. Una flecha que vuelve al nodo de la condición denota un
bucle.
El objetivo de la prueba de caminos es asegurar que cada camino independiente en el
programa se ejecuta al menos una vez. Un camino independiente del programa es aquel
que recorre al menos una nueva arista en el grafo de flujo. En términos de programas,
esto significa ejecutar una o más condiciones nuevas. Se deben ejecutar las ramas
verdadera y falsa de todas las condiciones.
El grafo de flujo para el procedimiento de búsqueda binaria se muestra en la Figura 23.16,
en donde cada nodo representa una línea en el programa con una sentencia ejecutable.
Por lo tanto, realizando trazas del flujo se puede ver que los caminos en el grafo de flujo
de búsqueda binaria son:
1,2.3,4,5, 6, 7, 8, 9, 10, 14
1,2.3,4, 5, 14
1,2, 3,4, 5, 6, 7, 11, 12, 5,...
1,2, 3,4,6,7, 2, 11, 13,5,...
 Ilustración 4 Grafo de fujo.

Se puede encontrar el número de caminos independientes en un programa calculando la

complejidad ciclomática del grafo de flujo del programa. Para programas sin sentencias
goto, el valor de la complejidad ciclomática es uno más que el número de condiciones en
el programa. Una condición simple es una expresión lógica sin conectores «and» u «or».
Si el programa incluye condiciones compuestas, que son expresiones lógicas con
conectores «and» u «or», entonces cuenta el número de condiciones simples en las
condiciones compuestas cuando calcula la complejidad ciclomática.
Después de descubrir el número de caminos independientes en el código calculando la
complejidad ciclomática, se necesita diseñar casos de prueba para ejecutar cada uno de
estos caminos. El número mínimo de casos de prueba necesarios para probar todos los
caminos del programa es igual a la complejidad ciclomática.
El diseño de casos de prueba es sencillo en el caso de la rutina de búsqueda binaria. Sin
embargo, cuando los programas tienen una estructura de ramas compleja, puede ser
difícil predecir cómo deberá procesarse cualquier caso de prueba particular. En estos
casos, para descubrir el perfil de ejecución del programa, puede utilizarse un analizador
dinámico de programas.
Los analizadores dinámicos de programas son herramientas de pruebas que trabajan
juntamente con los compiladores. Durante la compilación, estos analizadores añaden
instrucciones adicionales al código generado. Estos cuentan el número de veces que una
sentencia ha sido ejecutada en un programa. Después de que el programa se ha
ejecutado, puede imprimirse un perfil de ejecución. Éste muestra qué partes del programa
han sido y no han sido ejecutadas utilizando casos de prueba particulares. Por lo tanto,
este perfil de ejecución revela secciones del programa no probadas.

4.2 Pruebas de Componentes.

¿Qué es una prueba de componentes?

La prueba de componentes se define como un tipo de prueba de software, en la que la
prueba se realiza en cada componente por separado sin integración con otros
componentes. También se denomina Prueba de módulo cuando se ve desde un punto de
vista arquitectónico. Las pruebas de componentes también se conocen como pruebas
unitarias, pruebas unitarias, pruebas de programas o pruebas de módulos.
Por lo general, algunos programas están hechos como un todo con varios componentes.
La prueba de nivel de componente se ocupa de la prueba de estos componentes
individualmente.
Las razones más comunes son una vista diferente de las pruebas de componentes
1. Tipo de modelo de ciclo de vida de desarrollo seleccionado
2. La complejidad del software o la aplicación que se está probando.
3. Pruebe con o sin aislamiento del resto de otro componente en un software o
aplicación.
Como sabemos, la arquitectura del ciclo de vida de las pruebas de tiene muchos
artefactos de prueba. Entre muchas pruebas, artefactos, la Política de prueba y la
estrategia de prueba define los tipos de pruebas, la profundidad de las pruebas que se
realizarán en un proyecto en particular.
¿Quién realiza las pruebas de componentes?
Los probadores prueban componentes. Los desarrolladores realizan una «prueba
unitaria» cuando prueban una funcionalidad o un procedimiento individual.
Cuando prueba de componentes
La prueba de componentes se realiza poco después de que los desarrolladores realicen la
prueba unitaria y la compilación se envíe al equipo de prueba. Esta construcción se llama
construcción UT (Unit Test Construction). La funcionalidad principal de todos los
componentes se prueba en esta fase,
Criterios de admisión para pruebas de componentes

 El número mínimo de componentes que se incluirán en el UT debe desarrollarse y

probarse unitariamente.
Criterios de salida para la prueba de componentes

 Todas las funciones de los componentes deberían funcionar perfectamente.

 No debe haber defectos críticos o de gravedad alta o media y prioridad Defectuoso
acceso.
Técnicas de prueba de componentes
Según la profundidad de los niveles de prueba, las pruebas de componentes se pueden
clasificar como

CTIS – Prueba de componentes en pequeño

CTIL – Prueba de componentes en grande
CTIS – Prueba de componentes en pequeño

La prueba de componentes se puede realizar con o sin el aislamiento de los componentes

restantes del software o la aplicación bajo prueba. Si se hace con el aislamiento de otro
componente, se denomina Prueba de componentes en pequeño.
Ejemplo 1: Considere un sitio web que contiene 5 páginas web diferentes y luego cada
página web se prueba por separado y con el aislamiento de otros componentes como una
prueba de componentes en Small.
Ejemplo 2: Considere la página de inicio del sitio web guru99.com que tiene muchos
componentes Home, Test, SAP, Web, ¡Must Learn !, Big Data, Live Projects, Blog, etc.
Del mismo modo, muchos componentes se fabrican con cualquier software y, además,
cada componente tendrá sus propios subcomponentes. Cada módulo mencionado en el
ejemplo 2 se menciona por separado sin considerar la integración con otros componentes.
Prueba de componentes en pequeño.

4.3 Pruebas del Sistemas

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.
Descripción
Una vez que se han probado los componentes individuales y se han integrado, se prueba
el sistema de forma global. En esta etapa pueden distinguirse los siguientes tipos de
pruebas, cada uno con un objetivo claramente diferenciado:
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/máquina.
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.
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.
Debemos distinguir entre las pruebas del software completo y las pruebas del sistema que
incorpora el software.
El objetivo de las pruebas de verificación es buscar discrepancias entre los requerimientos
y la ejecución del software.
El proceso de verificación de los requerimientos comienza con el análisis de esos
requerimientos y una inspección en la cual se busca evaluar la consistencia, completitud y
factibilidad de los requerimientos, tanto individualmente como juntos. Adicionalmente los
requerimientos deben ser revisados y validados por los distintos actores involucrados con
el sistema, acción que debe aclarar los compromisos al respecto.

4.4 Documentación de resultados de las 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.
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 a 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
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 guías de instalación, guías
del usuario, manuales de referencia y 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 on- line.
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.
Las pruebas intentan demostrar que un programa hace lo que se intenta que haga, así
como descubrir defectos en el programa antes de usarlo. Al probar el software, se ejecuta
un programa con datos artificiales. Hay que verificar los resultados de la prueba que se
opera para buscar errores, anomalías o información de atributos no funcionales del
programa.
El proceso de prueba tiene dos metas distintas:
1. Demostrar al desarrollador y al cliente que el software cumple con los
requerimientos. Para el software personalizado, esto significa que en el documento
de requerimientos debe haber, por lo menos, una prueba por cada requerimiento.
Para los productos de software genérico, esto quiere decir que tiene que haber
pruebas para todas las características del sistema, junto con combinaciones de
dichas características que se incorporarán en la liberación del producto.
2. Encontrar situaciones donde el comportamiento del software sea incorrecto,
indeseable o no esté de acuerdo con su especificación. Tales situaciones son
consecuencia de defectos del software. La prueba de defectos tiene la finalidad de
erradicar el comportamiento indeseable del sistema, como caídas del sistema,
 interacciones indeseadas con otros sistemas, cálculos incorrectos y corrupción de
datos.
La primera meta conduce a la prueba de validación; en ella, se espera que el sistema se
desempeñe de manera correcta mediante un conjunto dado de casos de prueba, que
refleje el uso previsto del sistema. La segunda meta se orienta a pruebas de defectos,
donde los casos de prueba se diseñan para presentar los defectos. Los casos de prueba
en las pruebas de defecto pueden ser deliberadamente confusos y no necesitan expresar
cómo se usa normalmente el sistema. Desde luego, no hay frontera definida entre estos
dos enfoques de pruebas. Durante las pruebas de validación, usted descubrirá defectos
en el sistema; en tanto que durante las pruebas de defecto algunas de las pruebas
demostrarán que el programa cumple con sus requerimientos.

4.5 Entrega del sistema y capacitación a usuarios

La entrega del software es el proceso completo de hacer llegar un producto de software a

los clientes, desde la conceptualización hasta el desarrollo y finalizando con la compra e
instalación real de la licencia del producto.
En la mayoría de los casos, el término se refiere al inicio del proceso, es decir, la serie de
pasos que siguen los distintos equipos de la empresa para preparar el software para su
implementación en el cliente. En algunos casos, el término se refiere a la forma en que el
cliente obtiene acceso al producto.
¿Qué es el modelo de la entrega del software?
Los modelos de entrega de software son enfoques que utiliza el equipo para preparar el
producto de software para el mercado. Estos modelos también se pueden conocer como
el ciclo de vida de la entrega de software, el proceso de entrega de software o
simplemente el proceso de entrega de software.
Hay muchos modelos de entrega de software diferentes que las empresas han
desarrollado y no existe un enfoque único que siempre funcione mejor. Además, muchas
empresas utilizan alguna combinación de modelos de entrega de software. En el pasado,
lo que se conoce actualmente como el enfoque de "cascada" era el estándar de oro para
el desarrollo de software, pero hoy en día, la metodología "ágil" ha ocupado su lugar en
gran medida. El método ágil también está asociado con modelos y metodologías
adicionales relacionados, como DevOps, CD / CI (entrega continua e integración
continua), kanban y scrum.
¿Cuáles son los enfoques ágiles y en cascada para la entrega de software?
El enfoque en cascada
El enfoque en cascada es un proceso de entrega de software lineal o secuencial. Es decir,
cada fase del proceso depende de la finalización de una fase anterior. Se denomina
enfoque de "cascada" debido a su flujo continuo "descendente": el proceso se mueve
secuencialmente desde la concepción hasta la implementación siguiendo una serie de
pasos.
Waterfall se encuentra entre los modelos de entrega de software menos flexibles. Se
originó en industrias como la manufactura y la construcción, donde cada paso del camino
dependía en gran medida del paso anterior. Si se cometió un error al colocar los cimientos
de un edificio, toda la estructura estaría defectuosa, sin importar qué tan bueno se hiciera
el trabajo en el resto del edificio. En el pasado, el proceso de desarrollo de software se
concebía como muy similar. Una canalización de entrega de software típica que utiliza el
enfoque en cascada podría verse así:
Un analista de negocios redacta un documento de requisitos comerciales que enumera
todo lo que la empresa necesitaba que hiciera el software, desde la estrategia general
hasta los detalles específicos sobre las funciones y la interfaz.
Los tecnólogos toman este documento y agregan un documento de requisitos técnicos
para complementarlo, detallando la estructura de la aplicación y sus datos, diseños
funcionales y otros requisitos. Juntos, estos dos documentos se conocieron como
especificación.
La especificación se pasa a los codificadores, quienes implementan los requisitos y crean
el código para las diversas funciones.

 Los códigos se integran para crear el software.

 El software se pone a prueba en cuanto a calidad y funcionalidad.
 El software se lanza al mercado.
 Todo el proceso puede llevar meses o años.
En algunos casos, este enfoque lineal es necesario para crear un producto de software
que funcione, pero hoy en día muchos lo ven como algo torpe e innecesariamente lento.
Veremos más de cerca por qué eso es importante más adelante.

El enfoque ágil
La palabra ágil implica ligereza, velocidad, flexibilidad y la capacidad de cambiar de
dirección fácilmente. Wikipedia describe las prácticas ágiles de desarrollo de software
como "descubrir requisitos y desarrollar soluciones a través del esfuerzo colaborativo de
equipos autoorganizados y multifuncionales y sus clientes / usuarios finales". En lugar de
abordar el software como un proyecto de construcción construido desde cero paso a
paso, el modelo ágil divide el proyecto en componentes más pequeños que pueden ser
desarrollados de forma independiente por un equipo especializado en una característica o
funcionalidad específica. Luego, estos componentes se juntan para crear el producto final.
Este enfoque permite un ciclo de vida de la entrega de software que es mucho más
flexible, colaborativo, eficiente e iterativo. En lugar de completar las tareas en cuestión de
meses, utilizando el enfoque ágil, los desarrolladores pueden alcanzar sus objetivos en
cuestión de semanas. Esto les permite a las empresas de tecnología lanzar nuevos
productos y actualizaciones de forma mucho más rápida y eficiente que antes.
Hay muchas formas diferentes de implementar este enfoque. A continuación, se muestra
un ejemplo de cómo se vería una canalización de entrega de software ágil con la
metodología scrum:
El propietario de un producto hace una lista de requisitos, denominada acumulación de
productos.
El equipo de scrum toma el primer elemento de la lista y hace un plan para implementarlo.
El equipo completa la tarea en un período de 2 a 4 semanas conocido como sprint. Todos
los días se reúnen para evaluar su progreso y hacer cambios si es necesario.
El equipo completa el sprint, revisa su trabajo y, cuando está completo, comienza un
nuevo sprint.
Este proceso se repite hasta que se completa el producto completo.
Una vez más, hay muchos otros métodos que caen bajo el paraguas ágil o están
relacionados con él. Lo que todos ellos tienen en común es que crean un ciclo de vida de
entrega de software que es lo más eficiente posible y permite al equipo entregar el
software al cliente rápidamente sin comprometer la calidad.
Gestión de la entrega del software
Con todas estas metodologías y tantos factores separados que deben unirse para crear
un proceso de entrega sin problemas, puede ser difícil ver el bosque por los árboles. Es
por eso que algunas empresas contratan a un administrador de entrega de software. El
gerente de entrega de software es responsable de supervisar el proceso de entrega y
asegurarse de que todo funcione de la mejor manera posible, desde la fase de
planificación inicial a través de los sprints y el proceso de desarrollo hasta que el software
esté listo para el mercado.
También hay una nueva categoría de software llamada gestión para la entrega del
software (SDM) que puede cambiar las reglas del juego en el proceso, incluso cuando se
trata de un administrador humano de entrega de software.
El propósito de la gestión para la entrega de software es reunir todos los datos de todo el
proyecto, desde los sistemas comerciales de back-office hasta la cadena de herramientas
de entrega de software, y proporcionar a la organización una visión completa, no solo de
las características en desarrollo, sino también de cómo se están utilizando y si están
impulsando el crecimiento.
La gestión de la entrega de software ayuda a romper los silos, dando a toda la
organización acceso a toda la información relevante sobre dónde están las cosas. Hace
que sea mucho más fácil colaborar y compartir conocimientos. En otras palabras, es la
madre de todas las herramientas de entrega de software.
¿Por qué es importante que los productos de software se desarrollen y entreguen
rápidamente?
En pocas palabras: si duermes, pierdes. La industria del software es extremadamente
competitiva y las empresas de tecnología están lanzando nuevos productos a un ritmo
vertiginoso. Según Statista, en 2020, se lanzaron un promedio de 6.000 nuevas
aplicaciones para Android todos los días. Además, las demandas de los clientes han
aumentado y se han vuelto más específicas. Las empresas deben desarrollar nuevas
funciones que satisfagan esas necesidades lo más rápido posible para mantener
satisfechos a sus clientes.
Mejores prácticas de entrega de software
Entonces, ¿cómo agiliza el proceso de entrega de software y desarrolla software
rápidamente sin comprometer la calidad?
Contrata a los mejores en el campo
Una de las mejores prácticas de entrega de software más importantes es asegurarse de
que sus equipos estén compuestos por profesionales consumados del más alto calibre.
Los ciclos de vida ágiles de entrega de software dan mucho más poder y flexibilidad al
equipo, pero también les asignan mayor responsabilidad. Necesita miembros del equipo
en los que pueda confiar para que sean rápidos y efectivos, se comuniquen claramente,
trabajen juntos sin problemas y detecten y resuelvan problemas de forma independiente.
Ya sea de forma interna o externa, asegúrese de contratar a los mejores.
Proporcione las herramientas y el equipo de entrega de software adecuados
Incluso el equipo más talentoso puede hacer mucho sin las herramientas de entrega de
software adecuadas. Otra de las mejores prácticas de entrega de software más
importantes es asegurarse de que su equipo tenga todo lo que necesita, desde el
hardware hasta el software y las aplicaciones para hacer pruebas.
Sea claro en sus metas y expectativas
Una ventaja del enfoque en cascada es que es muy metódico cuando se trata de objetivos
y expectativas, pero se pueden perder muchas cosas en una especificación de 200
palabras. Dividir el proyecto en componentes más pequeños lo simplifica de alguna
manera, pero debe asegurarse de que todos los involucrados en el proyecto sepan
exactamente cuáles son los objetivos y expectativas. Cuanto más alineado esté el equipo,
más rápido y más eficiente será el ciclo de vida de la entrega de software.
Elija los métodos de entrega de software que mejor se adapten a su proyecto
Ya sea en cascada, ágil, scrum u otra cosa, elija una metodología que funcione mejor
para el equipo que ha reunido y el proyecto en el que está trabajando.
Realice pruebas rigurosas de su software
Todo ese arduo trabajo y talento que ha invertido en el producto se reducirá a nada si el
software no funciona. Invierta en un régimen de pruebas riguroso y asegúrese de que
todo funcione correctamente. Esto debería funcionar en paralelo a la codificación para que
pueda modificar el producto si encuentra algo que necesite ajuste. Es especialmente
efectivo combinar herramientas de prueba de IA con evaluadores humanos para detectar
problemas temprano.
Celebre los logros
La entrega ágil de software se trata de pequeños pasos. Mantenga a su equipo motivado
celebrando cada hito a lo largo del camino, incluso los más pequeños.
Sea flexible y planifique el cambio
El cambio es inevitable: es cierto para la vida en general y es aún más cierto cuando se
trata del desarrollo de software. Debe responder a los hechos sobre el terreno y siempre
están cambiando. Espere lo inesperado y no se desanime si las cosas se descarrilan un
poco.
Considere la gestión de la entrega de software
Ya sea por un administrador de entrega de software humano, un software de
administración de entrega de software o una combinación de ambos, asegurarse de tener
a alguien o algo que lo ayude a entender todos los componentes del proceso es clave
para el éxito.
Métodos de administración de licencias y entrega de software
¡Hurra, su software está en funcionamiento y listo para los clientes! Pero, ¿cómo llegará
realmente su software a ellos?
Con toda la prisa por crear un software fantástico y funcional, es posible que haya
olvidado que necesita tener una forma de llevarlo a sus clientes mientras lo protege contra
el robo y la piratería. Todo su arduo trabajo se desperdiciaría si entregara su software solo
para que lo copiaran ilegalmente y lo distribuyeran a clientes que no pagan. Además,
debe proporcionar un modelo de entrega que haga que sea fácil y asequible comprarlo y
usarlo para sus clientes objetivo.
Ingrese a la gestión de licencias. La gestión de licencias es una parte crucial de la etapa
final del proceso de entrega de software. No solo garantiza que su producto llegue a los
clientes que pagan de forma segura, sino que también puede proporcionar información
sobre cómo sus clientes utilizan su software y ayudarlo a administrar los derechos de
manera sistemática.
Existe una variedad de modelos para entregar software a los clientes, desde soluciones
locales y basadas en hardware hasta SaaS y soluciones basadas en la nube. Descubra
más sobre los distintos métodos de entrega de software.
Capacitación a los 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. Tal como hemos visto, 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 los usuarios y facilite su capacitación.
Estrategias de capacitación
Las estrategias de capacitación son determinadas por quien está siendo capacitación 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.
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 lo
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 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 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.

Objetivos de capacitación. Quien esté siendo entrenado dicta, en gran parte, los objetivos
de la capacitación. Los objetivos del entrenamiento para cada grupo deben ser indicados
claramente. Los objetivos bien definidos son de una gran ayuda para permitir que los
capacitados sepan lo que se espera de ellos. Además, los objetivos permiten la
evaluación de la capacitación cuando ha terminado. Por ejemplo, los operadores deben
saber cosas básicas, tales como el encendido de la máquina, qué hacer cuando suceden
los errores comunes, búsqueda de fallas básicas y como terminar una captura.

Métodos de capacitación. Cada usuario y operador necesitara una capacitación

ligeramente diferente. Hasta cierto punto, sus trabajos determinan lo que necesitan saber,
y su personalidad, experiencia y conocimientos de fondo determinan cómo aprender
mejor. Algunos usuarios aprenden mejor viendo, otros oyendo y otros haciendo. Debido a
que, por lo general, no es posible personalizar la capacitación para un individuo,
frecuentemente la mejor manera de proceder es con una combinación de los métodos. De
esta forma se llega a la mayoría de los usuarios por medio de un método u otro.
Los métodos para aquellos que aprenden mejor viendo incluyen demostraciones del
equipo y exposiciones a los manuales de entrenamiento. Aquellos que aprenden mejor
oyendo se beneficiaran de platicas acerca de los procedimientos, discusiones y sesiones
de preguntas y respuestas entre los instructores y capacitados. Aquellos que aprenden
mejor haciendo necesitan experiencia práctica con el nuevo equipo. Para trabajos como el
del operador de computadora, la experiencia práctica es esencial y, en cambio, tal vez un
gerente de aseguramiento de calidad de una línea de producción pueda solamente
necesitar ver la salida, aprender cómo interpretarla y saber cuándo está programado que
llegue.
Lugares de capacitación. La capacitación se realiza en diferentes ubicaciones, algunas de
las cuales son más adecuadas para el aprendizaje que otras. Los grandes vendedores de
computadoras proporcionan ubicaciones fuera del local donde se mantiene equipo
operable libre de costos. Sus instructores proporcionan experiencia práctica, así como
seminarios, en un ambiente que permite que los usuarios se concentren en el aprendizaje
del nuevo sistema. Una de las desventajas de la capacitación fuera de sitio es que los
usuarios están alejados del contexto de la organización dentro de la cual deben existir
eventualmente.
La capacitación en sito dentro de la organización de los usuarios también es posible con
varios tipos diferentes de instructores. La ventaja es que los usuarios ven el equipo puesto
en donde estará cuando sea completamente operacional. Una desventaja seria es que los
capacitados a veces de sienten culpables de no cumplir sus labores de trabajo normales
si permanecen en el sitio para la capacitación, por lo tanto, puede ser que no sea posible
la concentración completa en la capacitación.
La capacitación fuera de sitio también puede estar disponible por una cuota a través de
consultores y vendedores. Estos pueden estar ubicados en lugares donde hay espacio
rentado para reuniones, tal como un hotel, o incluso pueden ser instalaciones
permanentes mantenidas por los instructores. Estos arreglos permiten que los
trabajadores estén libres de las demandas del trabajo normal, pero también puede ser
que no proporcionen el equipo para la capacitación práctica.
Materiales de capacitación. Al planear la capacitación de los usuarios, los analistas de
sistemas deben darse cuenta de la importancia de materiales, de capacitación bien
preparados. Estos incluyen manuales de capacitación, cosos de capacitación, en donde a
los usuarios les es asignado trabajo por medio de un caso que incorpora la mayoría de las
interacciones comúnmente encontradas con el sistema, uy prototipos y esquemas de la
salida. La mayoría del software en paquete proporciona tutoriales en línea para ilustrar las
funciones básicas.

Debido a que la comprensión del sistema pro parte del usuario depende de ellos, los
materiales de capacitación deben estar escritos con claridad. Esto significa que los
materiales de capacitación deben tener buenos índices, estar escritos para la audiencia
adecuada con un mínimo de vocabulario especial y disponible para cualquiera que los
necesite

4.6 Entrega de documentación técnica y de usuario del sistema

Documentación técnica
La documentación técnica es muy importante en el desarrollo de software. Es como una
carta de navegación para tu equipo. Documentar tu proceso, sirve como referencia
explicando las razones del desarrollo, como opera y cómo utilizarlo. Los equipos de
software se refieren a este proceso de documentación técnica cuando hablan de
requerimientos, notas en la reléase o diferentes aspectos en el desarrollo del producto.
Utilizan documentos para detallar el código, APIs, y realizar un seguimiento en el proceso
de desarrollo de software. Externamente, la documentación se plasma en manuales,
guías de usuario para administradores de sistemas, ayuda a los equipos y demás usos.
La documentación técnica sirve para ayudar a los nuevos miembros del equipo a adaptar
más rápido a los hábitos de trabajos de la compañía. Comparte información del
funcionamiento del producto y el porqué de cada requerimiento. Hace que la curva de
aprendizaje de los desarrolladores sea más suave. Y lo hace señalando aquellos puntos
de la aplicación en los que ha de centrarse el desarrollador para saber más del contexto
de aquella aplicación en la que están trabajando.
La información en la base de datos ha de documentarse sin ninguna duda. Es importante
conocer con qué tipo de base de datos estamos trabajando, servidores, diagrama de
información, etc. Muestra todas las modificaciones en la estructura, así como los tipos y
las adiciones de índices. Sirve para tener un mejor muestrario de soluciones ante posibles
soluciones que puedan aparecer

Documentos de instalación y configuración son muy útiles para cuando los

desarrolladores necesitan configurar aplicaciones de entorno. Mucho mejor si los pasos a
seguir están bien detallados y son fáciles de seguir. De ese modo las soluciones a
posibles problemas pueden añadirse con facilidad.
Detalles como el software a necesitar, librerías y versiones de aplicaciones de servidores
se pueden incluir para asegurar que el entorno será compatible a lo esperado. La
documentación del código es el esqueleto de cada aplicación. Puede dividirse en distintas
partes: bloques de comentarios y archivos de documentos más específicos. Información
respecto al repositorio del código, instrucciones paso a paso para crear el package de una
aplicación o una construcción lista para ser depurada, etc. Una documentación técnica es
de gran ayuda para la memoria del proyecto. Es obvio que una lista de tareas ayuda a la
organización del equipo, así como diversos estudios sugieren que el hecho de escribir a
mano, incrementa la posibilidad de completarla.
Déjame repetir que, para un programador, la documentación técnica es un must. La tarea
no se basa en hacerlo o no, sino en cómo y qué herramientas sirven para hacer el
proceso más eficiente. El hecho de documentar el proceso sirve para conocer todos los
aspectos de una aplicación, cosa que beneficia al equipo y mejora la calidad del producto
de software. Con la documentación técnica, tienes toda la información necesaria para el
desarrollo y el mantenimiento correcto de la aplicación. Así como una mejor transferencia
de conocimiento entre developers.
Incluso el mejor software, puede ser inútil si los desarrolladores son incapaces de
entenderlo.
Una buena documentación técnica con las mejores herramientas hace que la información
sea más accesible, ofreciendo un gran número de “entry points”, ayuda a los nuevos
desarrolladores a aprender más rápido, simplifica el producto y ayuda en la
documentación de costes. Además, genera confianza.
Documentación para el usuario.
La documentación para el usuario constituye un elemento de consulta para toda aquella
persona que va a usar el programa por primera vez o que trata de saber si el programa
servirá a sus objetivos. Igualmente es útil para usuarios que ya realizan un manejo básico
y quieren profundizar hacia un conocimiento avanzado. Una documentación completa
contendría:

 Portada con el nombre del programa, versión y autor o autores.

 Índice.
 Descripción muy breve de las funciones y posibilidades del programa.
 Descripción breve del método de cálculo principal.
 Explicación breve de cómo debe usarse el programa y de los datos de entrada,
opciones y resultados.
 Ejemplos paso a paso de uso del programa en número suficiente para comprender
las posibilidades que se brindan.
 Diagrama de flujo del programa de carácter sintético y descriptivo.
 Especificación detallada de todas las opciones contenidas en menús.
 Especificación detallada de todos los cálculos, principales y secundarios.
La extensión de la documentación para el usuario será variable en función de la
complejidad y características del programa: puede ir desde un párrafo para programas
muy sencillos y de fácil uso hasta centenares de páginas para programas comerciales
complejos. Los puntos contenidos en la documentación también son variables, siendo los
enumerados anteriormente una orientación. Para programas sencillos puede reducirse a
un título, una explicación breve del funcionamiento, entradas y salidas y un ejemplo de
uso.

Conclusión
Después de realizar la presente investigación y analizarla de forma detenida podemos
concluir que las pruebas en la ingeniería de software son un componente fundamental del
ciclo de vida de desarrollo e implementación en la hora de llevar a cabo o para
implementar software de forma rápida y confiable.
Antes de que pueda ser usado un sistema de información debe ser probado. Esto con el
fin de garantizar que el software no tenga problemas al final del proceso. También
debemos recordar que se deben poner en práctica todas las estrategias posibles para
garantizar que el usuario inicial del sistema se encuentre libre de problemas. La
implementación es la última fase del desarrollo de sistemas. Donde aprendimos de mejor
manera que durante este proceso de llevar a cabo la implementación y prueba se deben
poner en práctica todas las estrategias posibles para garantizar que el usuario inicial del
sistema se encuentre libre de problemas lo cual se puede describir durante este proceso y
llevar a cabo las correcciones necesarias.
Es importante asegurarse de que la aplicación va a funcionar según lo previsto en cada
situación. Por lo tanto, no solo es necesario probar el código de aplicación, sino todos los
aspectos de nuestra carga de trabajo.
Bibliografía

Escales, A. (30 de Julio de 2013). La capacitación en el proceso de

implementación de un sistema. Obtenido de evaluandosoftware.com:
https://www.evaluandosoftware.com/la-capacitacion-en-el-proceso-de-
implementacion-de-un-sistema/

J., M. (03 de Abril de 2009). Ingenieria de software. Obtenido de blogspot.com:

https://talleriswu4.blogspot.com/2009/04/45-implementacion-y-capacitacion-
de.html

Mario R. Rancel. (Desconocido). Documentación de programas informáticos:

documentación para el usuario y para mantenimiento. 31 de Mayo de 2022, de
aprenderaprogramar.com Sitio web:
https://www.aprenderaprogramar.com/index.php?
option=com_content&view=article&id=390:documentacion-de-programas-
informaticos-documentacion-para-el-usuario-y-para-mantenimiento-
cu00250a&catid=36&Itemid=60
S/N. (20 de Septiembre de 202). Sobre la entrega del software. 31 de Mayo de
2022, de thalesgroup.com Sitio web: https://cpl.thalesgroup.com/es/software-
monetization/software-delivery-explained
Maximiliano. (viernes, 3 de abril de 2009). Taller de ingenieria en software. 31 de
Mayo de 2022, de blogspot.com Sitio web:
http://talleriswu4.blogspot.com/2009/04/45-implementacion-y-capacitacion-de.html