INGENIERÍA DE

SOFTWARE
INVESTIGACIÓN

ESCUELA: Instituto Tecnológico Superior de San

Andrés Tuxtla.

NOMBRES: Fabian Alexander Ríos Valle

Elias Dario Pavon Figarola
Sergio Luis Xolo Absalon

DOCENTE: Montserrat Masdefiol Suarez

GRUPO: 604A CARRERA: Ing. Sistemas

Periodo Febrero – Junio del 2023

San Andrés Tuxtla, ver

P á g i n a 1 | 25
INGENIERIA DE S.

INDICE
INTRODUCCIÓN ......................................................................................................................................................................... 3
ING. SOFTWARE ......................................................................................................................................................................... 4
PLAN DE PRUEBAS............................................................................................................................................................................... 4
1.1- Analizar los requerimientos de desarrollo de software...................................................................................................... 4
1.2.- Identificar las funcionalidades nuevas a probar ............................................................................................................... 6
1.3.- Identificar las funcionalidades de sistemas existentes que deben probarse ..................................................................... 6
1.4.- Definir la estrategia de pruebas ........................................................................................................................................ 6
1.5.- Definir los criterios de inicio, aceptación y suspensión de pruebas................................................................................... 7
1.6.- Identificar los entornos (ambientes) requeridos ............................................................................................................... 8
1.8.- Establecer la metodología y procedimientos de prueba ................................................................................................. 10
1.9.- Elaborar la planificación de las pruebas ......................................................................................................................... 10
1.10.- Identificar los riesgos y definir planes de respuesta...................................................................................................... 11
1.11.- Pruebas funcionales vs. pruebas no funcionales ........................................................................................................... 12
12.-Enfoques ágiles de pruebas y DevOps ............................................................................................................................... 13
13.- Automatización de pruebas y pruebas continuas ............................................................................................................ 14
2.-PROCESO DE IMPLEMETACIÓN......................................................................................................................................................... 16
2.1.- Mejores Prácticas y Consideraciones .............................................................................................................................. 18
3.-PROGRAMA DE CAPACITACIÓN ........................................................................................................................................................ 20
3.1.-Componentes de un Programa de Capacitación en Ingeniería de Software .................................................................... 21
CONCLUSIÓN ........................................................................................................................................................................... 23
REFERENCIAS ........................................................................................................................................................................... 24
LIBRO: ............................................................................................................................................................................................ 24
WEB: ............................................................................................................................................................................................. 24

GRUPO 604A DE SISTEMAS P á g i n a 2 | 25

INGENIERIA DE S.

Introducción
Una introducción adecuada en un plan de pruebas de ingeniería de software debe establecer
el contexto y los objetivos generales de las pruebas. Además, debe proporcionar una visión general
de los principales componentes del plan. Aquí se presenta una introducción que abarca estos
aspectos:
"El presente plan de pruebas de ingeniería de software establece la estrategia y los
procedimientos para garantizar la calidad del software en el proyecto [nombre del proyecto]. El
objetivo de este plan es proporcionar una descripción detallada de las actividades de prueba que
se llevarán a cabo, los recursos involucrados y los resultados esperados.
El software desarrollado en el proyecto [nombre del proyecto] desempeña un papel crucial en
[descripción del rol o función del software]. Por lo tanto, es fundamental asegurar que el software
cumpla con los requisitos funcionales y no funcionales establecidos, y que sea confiable y de alta
calidad.
Este plan de pruebas se centrará en verificar la funcionalidad del software, su rendimiento, su
capacidad para manejar situaciones de estrés y su seguridad. Además, se prestará atención a la
usabilidad y la compatibilidad con diferentes plataformas.
El plan de pruebas se llevará a cabo en varias etapas del ciclo de vida del desarrollo de
software, incluyendo pruebas unitarias, pruebas de integración, pruebas de sistema y pruebas de
aceptación. Cada etapa se centrará en diferentes aspectos del software y se realizará en
colaboración con los diferentes equipos de desarrollo y stakeholders relevantes.
El equipo de pruebas estará compuesto por profesionales con experiencia en pruebas de
software y se apoyará en herramientas de pruebas automatizadas y manuales para garantizar una
cobertura exhaustiva y eficiente.
Además, se establecerán métricas de calidad y criterios de aceptación claros para evaluar el
rendimiento del software durante las pruebas. Se documentarán los resultados de las pruebas, los
problemas encontrados y las acciones correctivas tomadas.
El plan de pruebas se basará en estándares y mejores prácticas reconocidas en la industria de
la ingeniería de software, como IEEE 829 y ISTQB. También se tomará en cuenta la metodología
de desarrollo utilizada en el proyecto, en este caso, [nombre de la metodología].
A lo largo de este documento, se describirán en detalle los objetivos específicos de cada etapa
de prueba, las actividades a realizar, los roles y responsabilidades, los recursos necesarios y los
entregables esperados.

GRUPO 604A DE SISTEMAS P á g i n a 3 | 25

INGENIERIA DE S.

ING. SOFTWARE
Plan de pruebas
Todo desarrollo de productos de software independientemente de la metodología que se está
implementando, es necesario que se incluya la fase de pruebas, la cual nos permitirá determinar
si el producto a entregar cumple con la calidad especificada y esperada por el cliente. En la
actualidad las personas que nos dedicamos a las pruebas de software (Testing), necesitamos de
un Plan de Pruebas de Software, el cual tiene como propósito comunicar a todos los involucrados
del proyecto los entregables, las características a ser o no ser probadas, los aspectos de criterios
de aprobación y fallo, criterios de suspensión y reanudación, las necesidades ambientales, las
capacitaciones requeridas para los integrantes del equipo de pruebas, los riesgos y el laboratorio
de usabilidad.
El Plan de Pruebas de Software se puede aplicar a todo proyecto de software, se ajusta a las
necesidades de cada empresa de software considerando el tamaño del proyecto, el tiempo, el
costo, el ciclo de vida del software, los involucrados, que son algunos por mencionar. Cada
empresa puede definir su propio Plan de Pruebas de Software basándose en las buenas prácticas
y en la mejora continua.
Entonces, el plan de pruebas de software se elabora para atender los objetivos de calidad en
un desarrollo de sistemas, encargandose de definir aspectos como por ejemplo los módulos o
funcionalidades sujeto de verificación, tipos de pruebas, entornos, recursos asignados, entre otros
aspectos.[1]

1.1- Analizar los requerimientos de desarrollo de software

Para elaborar un plan de pruebas de software lo primero que debes hacer es entender los
requerimientos de usuario que componen la iteración o proyecto, que son el sujeto de la verificación
de calidad que se va a realizar.
Deberás analizar toda la información de la ingeniería de requisitos, incluyendo la matriz de
trazabilidad, especificaciones y diseño funcional, requisitos no funcionales, casos de uso, historias
de usuario (si estás trabajando con metodologías ágiles), entre otra documentación.
También es muy importante realizar entrevistas con el equipo encargado de la ingeniería de
requisitos para aclarar dudas y ampliar la información que sea necesaria.
Además de las preguntas específicas de cada requisito, es importante hacer preguntas del
alcance general, por ejemplo:

 ¿Es un sistema nuevo o existente?

 ¿Cuáles funcionalidades existentes están siendo modificadas?

GRUPO 604A DE SISTEMAS P á g i n a 4 | 25

INGENIERIA DE S.

 ¿Cuáles son los requisitos no funcionales? Entre otras.

Los requerimientos de desarrollo de software son la descripción detallada de las

funcionalidades, características y restricciones que un sistema de software debe cumplir. Estos
requerimientos se utilizan como base para el diseño, implementación y prueba del software, y
actúan como una guía para el equipo de desarrollo durante todo el proceso.
Los requerimientos de desarrollo de software son necesarios para garantizar que el software
cumpla con las necesidades y expectativas de los usuarios finales, así como con los objetivos del
proyecto. Estos pueden provenir de diferentes fuentes, como los clientes, los usuarios finales, el
equipo de desarrollo, los analistas de negocio, entre otros.
Los requerimientos de desarrollo de software pueden dividirse en dos categorías principales:
requerimientos funcionales y requerimientos no funcionales.
Requerimientos funcionales: Son las funciones y características específicas que debe tener
el software para satisfacer las necesidades de los usuarios. Estos describen las interacciones del
sistema con los usuarios y otros sistemas, y se centran en "qué" debe hacer el software. Por
ejemplo, un requerimiento funcional podría ser "el sistema debe permitir a los usuarios registrarse
con su dirección de correo electrónico y contraseña".
Requerimientos no funcionales: Son las restricciones y características no relacionadas
directamente con la funcionalidad, pero que afectan la calidad y el rendimiento del software. Estos
se centran en "cómo" debe funcionar el software y pueden incluir aspectos como el rendimiento, la
seguridad, la usabilidad, la compatibilidad, la escalabilidad, la disponibilidad, entre otros. Por
ejemplo, un requerimiento no funcional podría ser "el sistema debe tener una respuesta de tiempo
promedio de menos de 2 segundos para las consultas de búsqueda".
Además de estos dos tipos principales de requerimientos, también puede haber requerimientos
de negocio, que están relacionados con los objetivos y las necesidades del negocio, y
requerimientos de diseño, que se refieren a la estructura interna y la arquitectura del software.
El proceso de análisis de los requerimientos de desarrollo de software implica recopilar,
analizar, documentar y validar los requerimientos para garantizar su precisión y comprensión
mutua entre los diferentes interesados. Esto se realiza a través de técnicas como entrevistas,
talleres, revisión de documentación existente, prototipado, entre otros.
Un análisis adecuado de los requerimientos de desarrollo de software es crucial para el éxito del
proyecto, ya que proporciona una base sólida para la toma de decisiones de diseño, desarrollo y
pruebas, y ayuda a evitar malentendidos y desviaciones en el proceso de desarrollo del software.[1]

GRUPO 604A DE SISTEMAS P á g i n a 5 | 25

INGENIERIA DE S.

1.2.- Identificar las funcionalidades nuevas a probar

A partir de la documentación del análisis de requisitos y de las entrevistas con el equipo de
ingeniería de requisito y desarrollo, debes identificar e incluir en el plan de pruebas de software la
lista de las funcionalidades (Características) totalmente nuevas.
Si estás trabajando con un sistema informático nuevo, no tendrás problemas en discernir, pues
todas serán nuevas.
En el caso de desarrollos de software integrados a un sistema existente es necesario revisar con
los analistas de negocio y también con los arquitectos de software las funcionalidades que forman
parte del desarrollo de software, en todas las capas de la arquitectura.

1.3.- Identificar las funcionalidades de sistemas existentes que deben probarse

Se debe identificar las funcionalidades existentes que estén siendo impactadas por el
desarrollo de alguna forma, considerando todos los componentes afectados en todas las capas de
la arquitectura de software.
Existen dos situaciones que se puede encontrar al identificar estas funcionalidades:
Funcionalidades modificadas de cara al usuario: Por ejemplo, si una funcionalidad está
siendo modificada agregando más pantallas o cambios a su flujo de proceso, debe ser incluida en
el plan de pruebas de software.
Funcionalidades modificadas en sus componentes internos: Son funcionalidades no
modificadas de cara al usuario, manteniendo la misma interfaz gráfica y flujo de procesos, sin
embargo, si se modifican componentes internos que comparten con otras funcionalidades del
sistema, en las capas de lógica de negocio o acceso a datos. Estas deben incluirse en el plan de
pruebas de software para determinar a partir de ellas pruebas de regresión a realizar.
Quienes pueden suministrar la información serán los Analistas de negocio o Arquitectos de
software, familiarizados con el sistema informático implementado en entorno de producción.[1]

1.4.- Definir la estrategia de pruebas

Consiste básicamente en seleccionar cuáles son los tipos de pruebas de software que se deben
realizar.
Es recomendable seguir un marco de referencia para determinar los tipos de prueba, como por
ejemplo los tipos de pruebas de software definidos por el ISTQB.

GRUPO 604A DE SISTEMAS P á g i n a 6 | 25

INGENIERIA DE S.

Pruebas funcionales
Se determinan los conjuntos de pruebas a realizar, correspondiente con cada funcionalidad
nueva o existente que se esté modificando.
Se tienen distintos tipos de pruebas funcionales, por ejemplo, las pruebas de sistema (o
pruebas integradas de sistemas), que se realizan después que el equipo de desarrollo ha integrado
los componentes de distintas capas.
Las pruebas funcionales son definidas por el ISTQB como pruebas basadas en especificación. Son
diseñadas usando técnicas de diseño de pruebas de caja negra. Aquí te compartimos un artículo
interesante que habla sobre el tema.

Pruebas no funcionales
Se define un conjunto de pruebas no funcionales para cada requisito de este tipo. Aquí se
pueden incluir pruebas sobre el desempeño, tiempo de respuesta, mantenibilidad, Pruebas de
seguridad de software, entre otros aspectos, según la clasificación de requisitos no funcionales
que se tenga para el proyecto.[1]

Pruebas de caja blanca

Según la estructura y arquitectura del software que se esté desarrollando.

Pruebas de regresión
Se definen sobre las funcionalidades modificadas en sus componentes internos.

Tipos de pruebas de software en metodologías ágiles

Si estás trabajando con metodologías ágiles, te recomendamos usar como base los 4
cuadrantes del Agile Testing, que define el marco de referencia con todos los tipos de pruebas que
debes considerar.

1.5.- Definir los criterios de inicio, aceptación y suspensión de pruebas

Criterios de aceptación o rechazo:

GRUPO 604A DE SISTEMAS P á g i n a 7 | 25

INGENIERIA DE S.

Para definir los criterios de aceptación o rechazo, es necesario definir el nivel de tolerancia a
fallos de calidad. Si la tolerancia a fallos es muy baja puede definirse como criterio de aceptación
que el 100% de los casos de prueba estén sin incidencias. Lograr este margen en todos los casos
de prueba principales y caso borde será muy difícil, y podría comprometer los plazos del proyecto
(incrementa los riesgos), pero asegura la calidad del producto.
Por otra parte, puede ser que la intención sea realizar un Soft Launch, o un mínimo producto
viable, en ese caso se podría definir como criterio de aceptación el 100% de los casos de prueba
principales (considerados claves) y 20% de casos de prueba no principales (casos bordes).
Una vez logradas las condiciones, se darán por aceptadas las pruebas y el desarrollo de
software.[1]

Criterios de inicio o reanudación:

Definen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas. Por
ejemplo, en el caso de inicio la condición podría ser la instalación de los componentes de software
en el ambiente y que los casos de pruebas de verificación de ambiente sean exitosos.
Para el caso de la reanudación las condiciones están relacionadas, se determina a partir de
cuales criterios de suspensión se presentaron para detener las pruebas. Una vez que estás
condiciones ya no existan (sean solventadas) se procede con la reanudación.

Criterios de suspensión:
Las condiciones van a depender de los acuerdos de nivel de servicio (SLAs) internos de la
organización y también de los acuerdos establecidos en cada proyecto individual.
Por ejemplo, si se tiene un equipo de pruebas que comparte su esfuerzo entre varios proyectos,
se puede definir un criterio de suspensión exigente, un determinado porcentaje de casos fallidos
que resulten en incidencias. Si la condición se cumple, se detienen las pruebas y se dedica el
personal a otras actividades,
Por otra parte, si se tiene un equipo de pruebas con personal dedicado, el criterio de
suspensión puede ser poco exigente, por ejemplo, solo ocurriendo si se bloquean por incidencia
todos los casos de prueba.

1.6.- Identificar los entornos (ambientes) requeridos

iStockPhoto / Trout55

GRUPO 604A DE SISTEMAS P á g i n a 8 | 25

INGENIERIA DE S.

Posteriormente se definen y documentan las características de los entornos de Hardware y

Software necesarios para realizar la ejecución de las pruebas de software.
Esta información se obtiene a partir del equipo de desarrollo y de los arquitectos de software,
quienes pueden suministrar los requisitos mínimos y óptimos para la operación del sistema.
Como mejor práctica, el ambiente de pruebas de software debería ser lo más similar posible al
ambiente de producción, sin embargo, no siempre es posible debido a limitaciones de recursos
(financieros). En estos casos debe estudiarse cuales son los requisitos que aseguran un mínimo
de confiabilidad de estas pruebas respecto al entorno de producción.
Además, en esta sección del plan de pruebas, también se definen los requisitos de sistemas
operativos, software y herramientas de las estaciones de trabajo de los Testers.
Si el alcance del proyecto incluye pruebas de aplicaciones (Apps) para móviles, es necesario
definir los emuladores y teléfonos inteligentes, con sus respectivos requisitos.

También deben definirse los requisitos de harware y software para los siguientes componentes:

 Herramienta de gestión de calidad de software.

 Herramientas para automatización de pruebas.

 Herramientas de BDD, TDD y Testing de Web Services).

7.- Determinar necesidades de personal y entrenamiento

Debe completarse previamente la estimación del esfuerzo de pruebas a partir del diseño de
casos de prueba.
Si aún no se cuenta con la estimación, se puede comenzar por definir los tipos de perfiles de
habilidades y conocimientos en Software Testing que se necesitan.

Para ello se puede buscar la respuesta a las siguientes preguntas:

 ¿Qué conocimientos de procesos de negocio se necesitan?

 ¿Qué sistemas se están probando y quienes tienen experiencia en su funcionamiento?

 ¿Se necesitan conocimientos específicos en pruebas de requisitos no funcionales?

 ¿Cual herramientas de gestión de calidad de software se va a utilizar?

GRUPO 604A DE SISTEMAS P á g i n a 9 | 25

INGENIERIA DE S.

 ¿Se necesitan conocimientos en herramientas técnicas como Lenguajes de

programación o herramientas de pruebas de webservices?

 ¿Se necesitan conocimientos en herramientas de pruebas automatizadas?

Requisitos de entrenamiento
Por ejemplo:

 Transferencia de conocimientos en el sistema y su operación con el área de negocio.

 Formación en metodologías de pruebas de software.

 Entrenamiento en tipos de pruebas especializados (desempeño, estrés, arquitectura,

caja blanca).

 Formación en automatización de pruebas de software.

1.8.- Establecer la metodología y procedimientos de prueba

La metodología de pruebas de software dependerá de la que se esté utilizando para la gestión
del proyecto.
Si se está utilizando una metodología predictiva, las pruebas de software comenzaran con la
estimación del esfuerzo de pruebas, diseño y luego la ejecución de las pruebas, como te lo
contamos en el artículo de Pruebas de calidad de software en 10 pasos.
Si se están utilizando metodologías ágiles de desarrollo de software, debes considerar las
diferencias de las pruebas ágiles de software respecto al enfoque predictivo, por lo que la
metodología debe estar alineada con el manifiesto ágil.
Luego se seleccionar la metodología de referencia, se documentan los procedimientos para
diseño y ejecución, siguiendo el orden de los pasos definidos, flujos de procesos, condiciones para
tomar decisiones, y demás aspectos.[2]

1.9.- Elaborar la planificación de las pruebas

La planificación de las pruebas abarca:
Matriz de responsabilidades

GRUPO 604A DE SISTEMAS P á g i n a 10 | 25

INGENIERIA DE S.

Puede usarse una Matriz RACI o Matriz RAM como plantilla. Esta se define con perfiles
genéricos o inclusive con el equipo de trabajo si ya se conoce cuál es el que será asignado.
Las tareas del plan de pruebas deben estar alineadas con las habilidades y conocimientos de
cada persona.

Cronograma:
Elaborado a partir de la estimación de las actividades de Software Testing realizada por el
equipo.
Para elaborar un cronograma real, es importante definir actividades críticas como por ejemplo
los tiempos de instalación de versiones en los entornos de pruebas, pruebas de validación de
ambientes antes de comenzar a hacer las pruebas y las iteraciones por incidencias, que es el
tiempo invertido en volver a probar los casos de prueba fallidos.

Premisas:
Son las condiciones que deben cumplirse para que el cronograma sea realizable, estas se
determinan a partir de la documentación de entornos y de los requisitos de personal. Por ejemplo,
disponibilidad de ciertos entornos, disponibilidad de personal con algún conocimiento técnico
especifico, la metodología que se va a utilizar, premias que deben cumplirse para poder aplicarla,
entre otros.

1.10.- Identificar los riesgos y definir planes de respuesta

La gestión de riesgos en pruebas es muy similar a la gestión de riesgos en proyectos de la que
hemos escrito en artículos como Las 5 preguntas y respuestas sobre la identificación de riesgos,
así como el artículo sobre Cómo hacer seguimiento de los riesgos del proyecto. [2]

Para el Software Testing, los riesgos por lo general están vinculados con factores como:

 Posibles dificultades en la disponibilidad de entornos.

 Pruebas que dependen de factores externos al proyecto y la organización.

 Disponibilidad de personal con conocimientos especializados en alguna herramienta, o

en la funcionalidad especifica que se está desarrollando.

 Dependencias con otros proyectos.

GRUPO 604A DE SISTEMAS P á g i n a 11 | 25

INGENIERIA DE S.

 Posibilidad que alguna premisa no se cumpla.

Para identificar los riesgos es necesario enumerar cada una de estas dependencias y por
medio de mesas de trabajo y tormentas de ideas pensar en las posibilidades de que algo salga
mal (u oportunidades para que salga bien).
Luego de la identificación, es necesario también definir planes de respuesta, los cuales deben
ser específicos para cada situación particular y riesgo. [2]

1.11.- Pruebas funcionales vs. pruebas no funcionales

En el contexto de las pruebas de software, es importante distinguir entre las pruebas
funcionales y las pruebas no funcionales. A continuación, se desglosa esta distinción:
Pruebas funcionales: Las pruebas funcionales se centran en verificar si el software cumple
con los requisitos y las funcionalidades especificadas. Estas pruebas evalúan qué hace el software
y cómo responde a diferentes entradas y acciones del usuario. Algunos tipos comunes de pruebas
funcionales incluyen: Pruebas unitarias: Se centran en probar componentes individuales del
software, como funciones o módulos, para asegurar que funcionen correctamente de manera
aislada. Pruebas de integración: Verifican la interacción y la comunicación correcta entre los
componentes integrados del software, como la interacción entre módulos o servicios. Pruebas de
sistema: Evalúan el comportamiento del software en su conjunto, verificando si todas las
funcionalidades interactúan de manera adecuada y cumplen los requisitos. Pruebas de aceptación:
Se realizan para evaluar si el software cumple con los criterios de aceptación establecidos por el
cliente o los usuarios finales.
Pruebas no funcionales: A diferencia de las pruebas funcionales, las pruebas no funcionales
se centran en evaluar los aspectos no relacionados directamente con la funcionalidad del software.
Estas pruebas evalúan cómo se comporta el software en términos de rendimiento, seguridad,
usabilidad y otros aspectos. Algunos tipos de pruebas no funcionales incluyen: Pruebas de
rendimiento: Se realizan para evaluar el rendimiento del software en términos de tiempo de
respuesta, capacidad de procesamiento y uso eficiente de los recursos del sistema. Pruebas de
seguridad: Evalúan la capacidad del software para proteger los datos y resistir ataques externos o
amenazas de seguridad.
Pruebas de usabilidad: Verifican la facilidad de uso, la experiencia del usuario y la capacidad
del software para satisfacer las necesidades y expectativas de los usuarios finales. Pruebas de
compatibilidad: Se realizan para evaluar si el software es compatible con diferentes plataformas,
navegadores, sistemas operativos y otros entornos relevantes. Pruebas de escalabilidad: Verifican
la capacidad del software para adaptarse y funcionar correctamente a medida que aumenta la

GRUPO 604A DE SISTEMAS P á g i n a 12 | 25

INGENIERIA DE S.

carga de trabajo o el número de usuarios. Pruebas de disponibilidad: Evalúan la disponibilidad y la

capacidad de recuperación del software en caso de fallos o interrupciones. Es importante destacar
que tanto las pruebas funcionales como las pruebas no funcionales son importantes para
garantizar la calidad del software. Ambos tipos de pruebas se complementan entre sí y contribuyen
a evaluar diferentes aspectos del software, desde la funcionalidad básica hasta el rendimiento, la
seguridad y la experiencia del usuario.[2]

12.-Enfoques ágiles de pruebas y DevOps

En el desarrollo de software actual, los enfoques ágiles y la implementación de la metodología
DevOps han ganado popularidad debido a sus beneficios en términos de flexibilidad, eficiencia y
entrega continua. A continuación, se desglosa este punto:
Enfoque ágil de pruebas: El enfoque ágil de pruebas se basa en los principios del desarrollo
ágil de software, como la colaboración cercana entre equipos, la entrega 15 incremental y la
adaptabilidad a los cambios. Algunos aspectos clave de este enfoque son: Pruebas continuas: Las
pruebas se integran de manera continua en el proceso de desarrollo, lo que implica realizar
pruebas frecuentes y automatizadas para obtener retroalimentación rápida sobre la calidad del
software.
Pruebas de aceptación: Se da prioridad a las pruebas de aceptación, donde los stakeholders
y los usuarios finales participan activamente en la definición de escenarios y criterios de prueba.
Esto garantiza que el software cumpla con las expectativas y necesidades del cliente. Pruebas
exploratorias: Se fomenta la realización de pruebas exploratorias, donde los testers tienen libertad
para explorar el software, identificar posibles problemas y probar diferentes escenarios sin
restricciones rígidas. Pruebas de regresión automatizadas: Se enfatiza la automatización de las
pruebas de regresión para garantizar que los cambios y las nuevas funcionalidades no introduzcan
errores en áreas previamente probadas.
Enfoque DevOps: DevOps se refiere a la combinación de prácticas y herramientas para
integrar el desarrollo de software (Dev) y las operaciones (Ops) de manera continua y colaborativa.
Algunos aspectos relevantes de este enfoque son: Integración continua: Se implementa un proceso
de integración continua donde los cambios en el código se integran y se prueban de manera
constante. Esto permite detectar y resolver problemas de manera temprana. Entrega continua: Se
busca lograr la entrega continua de software mediante la automatización de las pruebas, la
compilación y el despliegue. Esto permite entregar cambios y nuevas funcionalidades de manera
rápida y confiable.
Infraestructura como código: Se adopta la práctica de definir y administrar la infraestructura
mediante código, lo que facilita la creación y la configuración de entornos de prueba y producción
de manera consistente.

GRUPO 604A DE SISTEMAS P á g i n a 13 | 25

INGENIERIA DE S.

Monitoreo y retroalimentación: Se implementa un enfoque de monitoreo continuo para

recopilar datos sobre el rendimiento y la calidad del software en producción. Estos datos se utilizan
para retroalimentar el proceso de desarrollo y mejora continua. La combinación de enfoques ágiles
de pruebas y la implementación de DevOps permite un ciclo de desarrollo más rápido, eficiente y
colaborativo. Los equipos de desarrollo y pruebas trabajan 16 de manera conjunta, se integran las
pruebas desde etapas tempranas y se prioriza la entrega continua de software de calidad.[2]

13.- Automatización de pruebas y pruebas continuas

La automatización de pruebas y las pruebas continuas son dos prácticas clave en el ámbito de
la ingeniería de software que permiten mejorar la eficiencia, la calidad y la velocidad de los
procesos de prueba:
Automatización de pruebas: La automatización de pruebas implica el uso de herramientas y
scripts para ejecutar pruebas de manera automatizada en lugar de realizarlas manualmente.
Algunos aspectos relevantes de la automatización de pruebas son:
Selección de herramientas: Se eligen las herramientas adecuadas para la automatización de
pruebas, como frameworks de pruebas, herramientas de gestión de pruebas y herramientas de
generación de informes. Estas herramientas facilitan la creación, ejecución y gestión de los casos
de prueba automatizados.
Desarrollo de scripts: Se desarrollan scripts o scripts de prueba utilizando lenguajes de scripting
o herramientas específicas para automatizar las acciones y verificaciones de las pruebas. Estos
scripts permiten reproducir escenarios de prueba de manera precisa y eficiente.
Ejecución de pruebas automatizadas: Las pruebas automatizadas se ejecutan de forma
repetible y consistente, lo que ahorra tiempo y reduce la posibilidad de errores humanos. Además,
las pruebas automatizadas se pueden ejecutar durante el proceso de integración continua para
obtener rápidamente resultados sobre la calidad del software.
Mantenimiento de scripts: Los scripts de prueba automatizados requieren un mantenimiento
regular para mantener su eficacia a medida que el software evoluciona. Esto implica actualizar los
scripts cuando hay cambios en la funcionalidad, realizar ajustes a medida que se descubren
problemas y agregar nuevas pruebas según las necesidades.

Pruebas continuas: Las pruebas continuas implican la integración de las pruebas en el

proceso de desarrollo y despliegue de software, lo que permite obtener 17 retroalimentación rápida
y frecuente sobre la calidad del software.

GRUPO 604A DE SISTEMAS P á g i n a 14 | 25

INGENIERIA DE S.

Algunos aspectos importantes de las pruebas continuas son: Integración de pruebas en el flujo
de trabajo: Las pruebas se integran en el flujo de trabajo de desarrollo y despliegue, lo que significa
que se ejecutan automáticamente en cada etapa, desde la integración hasta la entrega del
software. Esto permite detectar problemas rápidamente y corregirlos de manera oportuna.
Pruebas unitarias continuas: Las pruebas unitarias se ejecutan automáticamente cada vez que
se realiza un cambio en el código fuente. Esto asegura que los componentes individuales del
software funcionen correctamente y sigan siendo coherentes a medida que se realizan
modificaciones.
Pruebas de integración continua: Las pruebas de integración se realizan automáticamente para
verificar la interacción adecuada entre los componentes del software y detectar problemas de
compatibilidad o comunicación.
Pruebas de regresión continua: Las pruebas de regresión se ejecutan automáticamente para
verificar que los cambios y las nuevas funcionalidades no hayan introducido errores en áreas
previamente probadas. Esto asegura que el software siga funcionando correctamente incluso
después de las modificaciones. La automatización de pruebas y las pruebas continuas permiten
reducir el tiempo y los recursos necesarios para ejecutar pruebas, mejorar la velocidad de entrega
del software y garantizar una mayor calidad al detectar problemas de manera temprana. Estas
prácticas son especialmente beneficiosas en entornos ágiles y de DevOps, donde se prioriza la
entrega rápida y frecuente de software de alta calidad. [3]

GRUPO 604A DE SISTEMAS P á g i n a 15 | 25

INGENIERIA DE S.

2.-Proceso de implemetación
El proceso de implementación en ingeniería de software es una etapa crítica que implica la
entrega y puesta en marcha del software desarrollado en un entorno de producción. Consiste en
llevar el sistema desde el ambiente de desarrollo y pruebas a un entorno real donde los usuarios
finales pueden utilizarlo de manera efectiva. A continuación, se describen los pasos clave del
proceso de implementación en ingeniería de software:
La implementación es parte del proceso en el que los ingenieros de software programan el
código para el proyecto. Las pruebas de software son parte esencial del proceso de desarrollo del
software. Esta parte del proceso tiene la función de detectar los errores de software lo antes
posible. La documentación del diseño interno del software con el objetivo de facilitar su mejora y
su mantenimiento se realizará a lo largo del proyecto. Esto puede incluir la documentación, tanto
interior como exterior.[3]
Todo proyecto en la ingeniería de software deberá pasar por tres fases, las cuales componen
la visión genérica de esta ingeniería.
La primera es el que de la aplicación por construir. En esta fase, el ingeniero recabase los
requisitos y planteara, a partir de una investigación analítica, las posibles soluciones al problema
planteado. Generalmente este análisis se conoce como análisis.
La segunda fase es el cómo de la aplicación. En ella se diseña los componentes técnicos
de la solución por construir: módulos que reflejen los procedimientos de entrada y salida, bases de
datos, controles, etc.
Como tercera fase está la implementación de la solución, donde se incluyen:

 La codificación de los elementos diseñados.

 Las pruebas de la aplicación.

 La puesta en producción de la aplicación.

A las tres fases anteriores hay que agregar una fase que es posterior a la puesta en producción
de la aplicación el mantenimiento es un costo inevitable en cualquier producto. Sin embargo, un
buen desarrollo de este implicara una reducción de dichos costes.

El mantenimiento puede visualizarse en tres vertientes principales:

Correctivo: Es el más caro, pues implica un retroceso hacia la ubicación de un problema no
considerado, o de un requisito mal entendido, o de un error de implementación dado.
Aumentativo: Es el añadir nuevos requisitos o necesidades al producto.

GRUPO 604A DE SISTEMAS P á g i n a 16 | 25

INGENIERIA DE S.

Preventivo: Se modifican componentes del software o del sistema para prevenir situaciones
anómalas.
Como se ha estudiado en los parámetros deseables para la ingeniería de software, el producto
deberá cumplir con muchos de estos para minimizar los costos del mantenimiento.[4]

Preparación: En esta etapa, se realiza una planificación adecuada para asegurar el éxito de
la implementación. Esto implica definir los recursos necesarios, como hardware, software y
personal, así como establecer un cronograma para las diferentes actividades. Además, se asignan
roles y responsabilidades a los miembros del equipo y se establece una comunicación clara de los
objetivos y expectativas del proyecto.
Instalación y configuración: En esta etapa, el software desarrollado se instala en los
servidores o equipos finales del entorno de producción. Esto puede implicar la ejecución de un
programa de instalación que copia los archivos necesarios y configura los parámetros básicos del
software. Además, se configuran las opciones y ajustes necesarios para que el software funcione
correctamente en el entorno de producción. Por ejemplo, se pueden configurar bases de datos,
servidores web, conexiones de red, seguridad, integración con otros sistemas, entre otros.
Pruebas y verificación: Una vez que el software está instalado y configurado, se realizan
pruebas exhaustivas para verificar su correcto funcionamiento en el entorno de producción. Esto
implica realizar diferentes tipos de pruebas, como pruebas de funcionalidad, rendimiento,
seguridad y compatibilidad. Se busca identificar y corregir posibles problemas antes de que el
software sea utilizado por los usuarios finales. Además, se verifica que el software cumpla con los
requisitos establecidos durante el proceso de desarrollo.
Migración de datos: Si el software implica la migración de datos desde un sistema anterior,
esta etapa se encarga de transferir los datos al nuevo sistema. En primer lugar, se extraen los
datos del sistema antiguo, asegurándose de que se obtenga toda la información relevante. Luego,
los datos se transforman y se adaptan para que sean compatibles con el formato requerido por el
nuevo sistema. Finalmente, los datos se cargan en el nuevo sistema, asegurándose de que se
conserven la integridad y la consistencia de los datos.
Capacitación y documentación: Antes de que los usuarios finales comiencen a utilizar el
software, es esencial proporcionar capacitación adecuada para que puedan familiarizarse con las
funcionalidades y el uso del sistema. Esto puede incluir sesiones de entrenamiento,
demostraciones prácticas y materiales educativos. Además, se crea documentación detallada,
como manuales de usuario, guías de referencia y preguntas frecuentes, que los usuarios pueden
consultar en caso de dudas o problemas. La capacitación y la documentación son clave para
garantizar que los usuarios utilicen el software de manera efectiva y aprovechen al máximo sus
funcionalidades.

GRUPO 604A DE SISTEMAS P á g i n a 17 | 25

INGENIERIA DE S.

Implementación gradual: En algunos casos, especialmente en sistemas de gran escala,

puede ser recomendable implementar el software de manera gradual en lugar de una
implementación completa de una sola vez. Esto implica lanzar el software en etapas, por ejemplo,
en diferentes departamentos o ubicaciones. La implementación gradual permite minimizar los
riesgos y ajustar cualquier problema o mejora que pueda surgir durante el proceso. Además, brinda
la oportunidad de recopilar comentarios y realizar ajustes antes de implementar el software en toda
la organización.
Soporte y seguimiento: Después de la implementación, es importante brindar soporte
continuo a los usuarios finales. Esto implica proporcionar canales de comunicación para que los
usuarios puedan plantear preguntas o reportar problemas. Se asigna personal o un equipo de
soporte que se encargue de resolver consultas y brindar asistencia técnica cuando sea necesario.
Además, se realizan actualizaciones regulares del software para corregir errores, agregar nuevas
funcionalidades o abordar mejoras basadas en los comentarios de los usuarios.

2.1.- Mejores Prácticas y Consideraciones

La ingeniería de software es un campo en constante evolución, y existen muchas mejores
prácticas y consideraciones que pueden ayudar a mejorar la calidad, eficiencia y éxito de los
proyectos de desarrollo de software.[4] A continuación, se presentan algunas de las mejores
prácticas y consideraciones clave en ingeniería de software:
Planificación adecuada: Una planificación sólida implica establecer metas y objetivos claros
desde el principio del proyecto. Se deben definir los requisitos del software en colaboración con
los stakeholders y establecer un alcance realista. La estimación precisa de tiempos y recursos es
esencial para evitar retrasos y desviaciones presupuestarias. Una planificación adecuada también
incluye la identificación y mitigación de riesgos potenciales.
Diseño modular y estructurado: El diseño de software debe seguir principios de modularidad
y estructura bien definida. Esto implica dividir el sistema en componentes más pequeños y
manejables, conocidos como módulos, que se encargan de tareas específicas. Los módulos bien
definidos facilitan la comprensión del software y permiten una fácil identificación y corrección de
errores. Además, el diseño modular permite la reutilización de código, lo que acelera el desarrollo
y reduce la duplicación de esfuerzos.
Gestión de requisitos: La gestión de requisitos es un proceso continuo que implica
comprender, documentar y gestionar los requisitos del software. Esto incluye la identificación de
los requisitos funcionales (qué debe hacer el software) y los requisitos no funcionales (atributos de
calidad como rendimiento, seguridad, usabilidad, etc.). Los requisitos deben ser claros, completos,
consistentes y verificables. Además, deben priorizarse y estar sujetos a cambios controlados a lo
largo del ciclo de vida del proyecto.

GRUPO 604A DE SISTEMAS P á g i n a 18 | 25

INGENIERIA DE S.

Control de versiones: El control de versiones es una práctica esencial en el desarrollo de

software. Se utiliza un sistema de control de versiones para rastrear y administrar las diferentes
versiones del código fuente y otros artefactos del proyecto. Esto permite mantener un historial de
cambios, facilitar la colaboración entre los miembros del equipo, revertir cambios si es necesario y
coordinar el trabajo en paralelo. Los sistemas de control de versiones populares incluyen Git,
Subversion y Mercurial.
Pruebas exhaustivas: Las pruebas son una parte fundamental del proceso de desarrollo de
software. Se deben realizar pruebas en diferentes niveles para garantizar la calidad y el
funcionamiento correcto del software. Las pruebas unitarias verifican el funcionamiento de
componentes individuales, mientras que las pruebas de integración se centran en la interacción
entre los componentes. Las pruebas de sistema se realizan en el sistema completo, mientras que
las pruebas de aceptación se enfocan en validar si el software cumple con los requisitos del
usuario. Además, se pueden utilizar técnicas de automatización de pruebas para agilizar el proceso
y mejorar la cobertura de pruebas.
Mantenimiento y gestión del cambio: El mantenimiento del software implica realizar mejoras,
correcciones de errores y actualizaciones a medida que se identifican nuevas necesidades o se
descubren problemas. Una gestión efectiva del cambio incluye establecer un proceso estructurado
para evaluar, priorizar y controlar los cambios. Esto ayuda a minimizar el impacto de los cambios
en el software existente y asegura que se mantenga la estabilidad y calidad del sistema.
Documentación y comunicación clara: La documentación adecuada es fundamental para
garantizar una comprensión clara del software y sus componentes. Se deben crear documentos
que describan los requisitos, el diseño, la arquitectura, el código fuente, los procedimientos de
prueba y cualquier otra información relevante. Además, la comunicación clara y efectiva entre los
miembros del equipo de desarrollo y los stakeholders es crucial para evitar malentendidos y
asegurar una colaboración exitosa. Las reuniones regulares, los informes de progreso y las
herramientas de colaboración pueden facilitar la comunicación efectiva.
Seguridad: La seguridad del software debe ser una consideración central en la ingeniería de
software. Esto implica identificar y mitigar los riesgos de seguridad a lo largo del ciclo de vida del
desarrollo. Se deben implementar buenas prácticas de seguridad, como el uso de autenticación y
autorización adecuadas, el cifrado de datos sensibles, el manejo seguro de entradas de usuario y
la protección contra ataques comunes, como inyecciones de código y ataques de denegación de
servicio.
Estas son solo algunas de las muchas mejores prácticas y consideraciones importantes en la
ingeniería de software. La adopción de estas prácticas puede ayudar a mejorar la calidad del
software, acelerar el desarrollo y garantizar el éxito del proyecto. Sin embargo, es importante
recordar que cada proyecto es único y puede requerir enfoques adaptados a sus necesidades
específicas. [4]

GRUPO 604A DE SISTEMAS P á g i n a 19 | 25

INGENIERIA DE S.

3.-Programa de capacitación
El programa de capacitación en ingeniería de software puede abarcar una amplia gama de
temas relevantes para el desarrollo de habilidades y conocimientos en este campo.[5] A
continuación, se presentan algunos de los temas comunes que suelen estar incluidos en un
programa de capacitación en ingeniería de software:
Avance Tecnológico: La industria de la ingeniería de software está en constante evolución,
con la aparición de nuevas tecnologías, metodologías y herramientas. Los programas de
capacitación brindan a los profesionales la oportunidad de mantenerse actualizados y
familiarizarse con las últimas tendencias y avances en el campo.
Competencias Técnicas: Los programas de capacitación permiten a los profesionales
desarrollar y mejorar sus competencias técnicas en áreas clave de la ingeniería de software, como
programación, arquitectura de software, diseño de bases de datos, desarrollo de aplicaciones
móviles, pruebas de software, entre otros. Esto les brinda la capacidad de enfrentar proyectos más
complejos y desafiantes.
Adaptabilidad a los Cambios: La capacitación en ingeniería de software ayuda a los
profesionales a adaptarse rápidamente a los cambios tecnológicos y a las demandas del mercado.
Les permite adquirir nuevas habilidades y conocimientos, lo que les permite asumir roles y
responsabilidades en proyectos emergentes y adoptar enfoques innovadores en el desarrollo de
software.
Mejora de la Calidad del Software: Los programas de capacitación también se centran en la
mejora de la calidad del software. Los profesionales capacitados adquieren conocimientos sobre
buenas prácticas de desarrollo, estándares de codificación, pruebas de software y aseguramiento
de la calidad, lo que se traduce en la entrega de productos de software de mayor calidad y menor
cantidad de errores.
Desarrollo Profesional y Oportunidades Laborales: La participación en programas de
capacitación en ingeniería de software brinda a los profesionales la oportunidad de desarrollar su
carrera y aumentar sus oportunidades laborales. La adquisición de nuevas habilidades y
certificaciones reconocidas en el mercado mejora su perfil profesional y los hace más atractivos
para las empresas en búsqueda de talento.
Fundamentos de programación: Una introducción a los lenguajes de programación comunes
y los conceptos básicos de programación, como variables, estructuras de control, funciones y
estructuras de datos.
Metodologías de desarrollo de software: Exposición a diferentes metodologías de desarrollo
de software, como el enfoque en cascada, desarrollo ágil, SCRUM, Kanban, entre otros. Se pueden
explorar las características, ventajas y desafíos de cada enfoque.

GRUPO 604A DE SISTEMAS P á g i n a 20 | 25

INGENIERIA DE S.

Análisis y diseño de software: Una introducción a las técnicas y herramientas utilizadas para
el análisis y diseño de software, incluyendo la identificación de requisitos, modelado de sistemas,
diseño de arquitectura y diagramas de flujo.
Gestión de proyectos de software: Una visión general de los principios y prácticas de gestión
de proyectos de software, incluyendo la planificación, estimación de tiempos y recursos, asignación
de tareas, seguimiento del progreso y gestión de riesgos.
Desarrollo de software orientado a objetos: Un enfoque en la programación orientada a
objetos, incluyendo conceptos como encapsulamiento, herencia, polimorfismo y principios SOLID.
Calidad de software y pruebas: Una exploración de las técnicas y herramientas utilizadas
para garantizar la calidad del software, incluyendo pruebas de software, pruebas unitarias, pruebas
de integración, pruebas de sistema y pruebas de aceptación.
Gestión de configuración y control de versiones: Una introducción a la gestión de
configuración de software y el control de versiones, incluyendo el uso de sistemas de control de
versiones como Git y Subversion.
Seguridad de software: Un enfoque en los principios de seguridad de software y las mejores
prácticas para proteger los sistemas contra vulnerabilidades y ataques.
Mantenimiento y evolución del software: Una discusión sobre las estrategias y prácticas
para el mantenimiento y la evolución de software a largo plazo, incluyendo la corrección de errores,
la implementación de mejoras y la gestión del cambio.
Interfaz de usuario y experiencia de usuario (UI/UX): Una introducción a los conceptos de
diseño de interfaces de usuario y experiencia de usuario, incluyendo principios de diseño,
prototipado y pruebas de usabilidad.
Desarrollo web y tecnologías relacionadas: Una visión general de las tecnologías y
herramientas utilizadas en el desarrollo web, incluyendo lenguajes de programación web,
frameworks, bases de datos, servidores web y estándares de seguridad.

3.1.-Componentes de un Programa de Capacitación en Ingeniería de Software

Identificación de Necesidades: El primer paso en el diseño de un programa de capacitación
es identificar las necesidades específicas de los profesionales y las áreas de enfoque requeridas.
Esto se logra a través de encuestas, evaluaciones de habilidades y análisis del entorno laboral.[5]
Definición de Objetivos: Una vez identificadas las necesidades, se establecen los objetivos
del programa de capacitación. Estos objetivos deben ser claros, medibles y alineados con las
metas organizacionales y las habilidades requeridas en la industria.

GRUPO 604A DE SISTEMAS P á g i n a 21 | 25

INGENIERIA DE S.

Diseño del Plan de Capacitación: El diseño del plan de capacitación implica la selección de
los contenidos, métodos de enseñanza, recursos didácticos y duración del programa. Es
importante considerar diferentes modalidades de capacitación, como cursos presenciales,
seminarios, talleres prácticos, e-learning, entre otros.
Implementación del Programa: Una vez diseñado el plan de capacitación, se lleva a cabo su
implementación. Esto incluye la asignación de instructores calificados, la provisión de materiales y
recursos, la organización de sesiones de capacitación y el seguimiento del progreso de los
participantes.
Evaluación y Retroalimentación: Es esencial realizar una evaluación continua del programa
de capacitación para medir su efectividad y realizar mejoras. Se pueden utilizar encuestas,
exámenes, evaluaciones de desempeño y retroalimentación de los participantes para recopilar
información y ajustar el programa en consecuencia.
Evaluación Continua del Programa: Realizar evaluaciones regulares del programa de
capacitación permite identificar áreas de mejora y realizar ajustes necesarios. Esto se logra a
través de la recopilación de comentarios de los participantes, el seguimiento de su desempeño en
el trabajo y la evaluación del impacto del programa en la organización.
Promoción de la Cultura de Aprendizaje: Fomentar una cultura de aprendizaje continuo en
la organización es fundamental. Esto se puede lograr mediante la promoción de la participación en
programas de capacitación, el reconocimiento de los logros de los participantes y la creación de
oportunidades para compartir conocimientos y experiencias entre los profesionales.

GRUPO 604A DE SISTEMAS P á g i n a 22 | 25

INGENIERIA DE S.

Conclusión
En conclusión, el plan de pruebas, el proceso de capacitación y la implementación en ingeniería
de software son componentes fundamentales para garantizar la calidad y el éxito de los proyectos
de desarrollo de software.
El plan de pruebas es una guía integral que establece la estrategia y los procedimientos para
llevar a cabo las pruebas de calidad. Proporciona una estructura clara para el equipo de pruebas
y otros stakeholders, asegurando que se realicen las actividades de prueba necesarias y se
alcancen los resultados esperados. El plan de pruebas se basa en estándares reconocidos y
adopta mejores prácticas de la industria para garantizar la cobertura y eficiencia de las pruebas.
Por otro lado, el proceso de capacitación en ingeniería de software es esencial para desarrollar
las habilidades y conocimientos necesarios en este campo. A través de cursos teóricos, talleres
prácticos, estudios de caso y proyectos prácticos, los profesionales pueden adquirir una base
sólida en los fundamentos de la ingeniería de software, así como aprender sobre metodologías,
herramientas y mejores prácticas actuales. La capacitación permite a los equipos de desarrollo de
software mantenerse actualizados y competentes en un entorno tecnológico en constante
evolución.
La implementación de ingeniería de software implica aplicar los conocimientos y habilidades
adquiridos en proyectos reales. Con un enfoque en la planificación, el diseño, el desarrollo, las
pruebas y la entrega del software, se busca asegurar que el producto final cumpla con los requisitos
establecidos, funcione correctamente y sea confiable. La implementación también implica la
gestión de proyectos, el control de calidad y la colaboración efectiva entre los miembros del equipo.
En conjunto, el plan de pruebas, el proceso de capacitación y la implementación en ingeniería
de software son elementos cruciales para lograr el éxito en el desarrollo de software. El plan de
pruebas garantiza la calidad del software a través de pruebas exhaustivas y bien estructuradas,
mientras que la capacitación proporciona a los profesionales las habilidades y conocimientos
necesarios para enfrentar los desafíos del desarrollo de software. La implementación efectiva se
logra mediante la aplicación de metodologías y prácticas adecuadas, asegurando la entrega de un
producto final confiable y de alta calidad.

GRUPO 604A DE SISTEMAS P á g i n a 23 | 25

INGENIERIA DE S.

REFERENCIAS
Libro:
[1] Pressman, Software Engineering (McGraw-Hill International Editions: Computer Science
Series). McGraw-Hill Education, 2000.

Web:
[2]PmInformatica. "Pruebas de software: 10 pasos para elaborar el plan de pruebas". La Oficina
de Proyectos de Informática. http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-
software.html (accedido el 12 de junio de 2023).
[3]V. G. Adán. "Detallando un plan de pruebas". QALovers.
https://www.qalovers.com/2019/01/detallando-un-plan-de-pruebas.html (accedido el 12 de junio de
2023).
[4]MarcoTeorico. "Implementación y mantenimiento | MarcoTeorico.com". MarcoTeorico.com.
https://www.marcoteorico.com/curso/91/ingenieria-de-software/864/implementacion-y-
mantenimiento (accedido el 12 de junio de 2023).
[5]IBN. "Implementación de software". Applicatta.
https://www.applicatta.cl/index.php/soluciones/metodologia-applicatta/implementacion-de-
software#:~:text=La%20implantación%20es%20una%20de,de%20manera%20productiva%20y%
20eficaz. (accedido el 12 de junio de 2023).

GRUPO 604A DE SISTEMAS P á g i n a 24 | 25

P á g i n a 25 | 25