Sistema de Información para la Gestión del Ecosistema de Emprendimiento

Plan Maestro de Pruebas

1. Introducción
1.1 Identificador de Documento
1.2 Alcance
1.3 Referencias
1.4 Vista General del Sistema y Elementos Clave
1.5 Descripción de Pruebas
1.5.1 Resumen de Recursos
1.5.2 Herramientas, Técnicas, Métodos, y Métricas
2. Detalles del Plan Maestro de Pruebas
2.1 Procesos de Pruebas
2.1.1 Proceso: Gestión de Pruebas
2.1.2 Proceso: Desarrollo
2.1.2.1 Actividad: Concepto
2.1.2.2 Actividad: Requerimientos
2.1.2.3 Actividad: Diseño
2.1.2.4 Actividad: Implementación
2.1.2.5 Actividad: Prueba
2.1.2.6 Actividad: Instalación
2.2 Administración de Requerimientos
2.3 Formato de Reporte de Resultados de Pruebas
3. General
3.1 Glosario
3.2 Historial de Cambios del Documento
1. Introducción
El Sistema de Información para la Gestión del Ecosistema de Emprendimiento, se encuentra en la
etapa final de su ciclo de vida definido en la memoria de trabajo de grado [1], en donde la
implementación de su prototipo pretende evaluar la validez y verificación del mismo.

En este plan se detallan tres pruebas de distintos puntos de vista, los cuales en conjunto generan
información valiosa de validación. Adicionalmente, se han diseñado formatos para cada una de las
pruebas con el fin de facilitar la documentación y análisis de resultados.

Para llevar a cabo las pruebas, es necesario únicamente un computador con acceso a internet y un
explorador web que sea compatible con HTML5.

Las pruebas a realizar consisten en verificar la funcionalidad relacionada del prototipo, el

cubrimiento de los requerimientos funcionales y la aceptabilidad del sistema.

1.1 Identificador de Documento

Versión del documento: 1.0 Fecha: Diciembre 1 de
2016
Organización: XXXXXXXXXXXXXXXXXXX
Autor: Carlos XXXXXXX Estado Documento: Final.

1.2 Alcance
El propósito del plan de pruebas consiste en demostrar la validez y verificar la correcta
implementación del prototipo del sistema de información XXXXXXXXX

También se pretende validar el cubrimiento de requerimientos en la prueba de concepto realizada,

incluyendo la verificación del correcto funcionamiento de la misma.

Adicionalmente se diseñaron plantillas para documentar los resultados de las pruebas y las
observaciones de los evaluadores.

Las pruebas aquí definidas se limitan a verificar objetivos de la prueba de concepto, tales objetivos
son:

 Correcta funcionalidad de la interfaz

 Cubrimiento de los requerimientos funcionales
 Aceptación por parte de los stakeholders

1.3 Referencias
[2] IEEE Computer Society, IEEE Standard For Software Test Documentation. IEEE 829-2008.
[3] Sommerville I, INGENIERÍA DE SOFTWARE. Séptima Edición. Madrid, España. Pearson
Educación, 2005.

1.4 Vista General del Sistema y Elementos Clave

El sistema a probar define el siguiente propósito en [4]:

“La razón principal del sistema es la necesidad de apoyar la gestión, sostenibilidad, crecimiento y
reconocimiento de la Red de Emprendimiento Javeriano facilitando a los diferentes actores que la
conforman el cumplimiento de cada uno de sus roles de una manera ágil y efectiva.”

El Sistema XXXXXXXXX, como propuesta de sistema de información utiliza estrategias y

metodologías de gestión para facilitar los procesos de negocio principales de la Red de
Emprendimiento XXXXXXXX (XXX), siendo respectivamente; la Gestión de Actividades y la Gestión
de Mentorías. Adicionalmente, el sistema maneja hojas de vida de emprendimiento para realizar la
trazabilidad de los conocimientos aprendidos por parte de los usuarios, dando así soporte al proceso
de formación en emprendimiento. Además de ello, el Sistema XXXXXXX permite llevar una
trazabilidad de los proyectos de la XXXXXX para apoyar de una mejor manera el crecimiento y
evolución de los mismos.

Particularmente, en el sistema propuesto se propone un sistema de privilegios para el manejo de

usuarios, esto debido a que existen personas vinculadas a la red con más de un rol relacionado. Los
usuarios definidos para el sistema son:

 Administrador
 Emprendedor Administrativo
 Emprendedor Investigador
 Emprendedor Estudiante XXXX
 Emprendedor Externo
 Emprendedor Egresado XXXX
 Coordinador de Actividades
 Mentor
 Inversionista

Estas características describen a grandes rasgos las funcionalidades relacionadas en el prototipo

propuesto, sin embargo, están mayormente definidas en [1] y [4].

1.5 Descripción de Pruebas

Las pruebas se dividen en relación al evaluador, por lo tanto:

Desarrollador o Programador:

 Prueba Funcional
En esta prueba verifica que el prototipo funciona como debería, buscando generar fallos de
ejecución en la prueba de concepto.

 Prueba Basada en Escenarios

Esta prueba consiste en validar la satisfacción de requerimientos. Inicialmente se deben crear

escenarios priorizados por probabilidad de ocurrencia, de ellos se extraen los casos de pruebas.

Stakeholder:

 Prueba de Aceptación

Esta prueba la realiza el stakeholder al finalizar la interacción con el prototipo propuesto, dando
respuesta a las preguntas consignadas en el siguiente enlace: WWW.XXXXXXXXX

1.5.1 Resumen de Recursos

Para llevar a cabo las pruebas se requiere tener en la máquina referente instalado un explorador de
internet con compatibilidad con HTML5 (preferiblemente Google Chrome) y también una conexión
a internet.

La dirección web del login del prototipo es:

http://WWW.XXXXXXXXXXXXXXXXX

Adicionalmente, para poder evaluar cada uno de los roles y usuarios disponibles en el sistema, es
necesario iniciar sesión con los siguientes usuarios; vale la pena resaltar que el campo de contraseña
no es validado, únicamente se valida el campo de nombre de usuario:

 a-dministrador
 emp-rendedor
 coo-activi
 men-thor
 in-versionista

1.5.2 Herramientas, Técnicas, Métodos, y Métricas

Los formatos descritos en el presente plan maestro de pruebas se han diseñado para facilitar la
documentación de los resultados de las pruebas, así como también la inclusión de anomalías.

El ambiente de pruebas debería ser en su posibilidad máquinas distintas con conexión a internet y
también exploradores web con compatibilidad con HTML5.

Para poder obtener información valiosa, es necesario que a la hora de realizar las pruebas se ejecute
un entrenamiento previo y una contextualización de operatividad del sistema.

Mediciones cualitativas y cuantitativas abordan la prueba de aceptación, sin embargo, son los
reportes de pruebas los que poseen los puntos de vista de los evaluadores.
2. Detalles del Plan Maestro de Pruebas
En las siguientes subsecciones se describen los procesos de cada una de las pruebas que se
pretenden realizar, indicando su forma de documentación y reporte de resultados.

2.1 Procesos de Pruebas

Las pruebas a realizar deberán seguir las siguientes características:

2.1.1 Proceso: Gestión de Pruebas

Las siguientes actividades deberán llevarse a cabo durante la ejecución del plan de pruebas:

 Monitoreo de la ejecución del plan

 Análisis de anomalías durante la ejecución del plan
 Reporte de progreso de pruebas
 Evaluar los resultados de las pruebas, de conformidad a esperado
 Determinar si una prueba está completa
 Revisar la completitud de los resultados

2.1.2 Proceso: Desarrollo

La idea de las siguientes actividades es verificar y validar los productos relacionados que han sido
desarrollados.

2.1.2.1 Actividad: Concepto

Esta actividad consiste en lograr una cercanía con las necesidades de los stakeholders, para llevarse
a cabo, se deben revisar los documentos desarrollados. Las tareas que componen esta actividad son:

 Revisión de la documentación referenciada

 Revisión del documento de requerimientos de sistema

2.1.2.2 Actividad: Requerimientos

El objetivo de la actividad es la verificación de los requerimientos funcionales y no funcionales, para
llevarse a cabo, se deben realizar las siguientes actividades:

 Ejecutar la prueba de aceptación

  Ejecutar la prueba del sistema (Prueba funcional de la interfaz)
 Revisar los requerimientos de software y los requerimientos de interfaz
 Registrar las observaciones del sujeto de la prueba

2.1.2.3 Actividad: Diseño

El objetivo de esta actividad es validar el diseño arquitectural de la solución propuesta. Para ello, es
necesario realizar las siguientes actividades:

 Ejecutar la prueba de aceptación

 Registrar las observaciones del sujeto de la prueba

2.1.2.4 Actividad: Implementación

La idea de esta actividad es verificar la correcta implementación del sistema propuesto, por lo que
se realiza por medio de las siguientes actividades:

 Ejecutar la prueba de aceptación

 Registrar las observaciones del sujeto de la prueba

2.1.2.5 Actividad: Prueba

El objetivo de esta actividad es verificar el cubrimiento de los requerimientos definidos. Las tareas
que lo componen son:

 Ejecutar la prueba de funcionalidades por usuario

 Ejecutar la prueba del sistema (Prueba funcional de la interfaz)
 Registrar las observaciones del sujeto de la prueba
 Ejecutar la prueba de aceptación
 Preparar el reporte de la prueba de aceptación

2.1.2.6 Actividad: Instalación

La idea de esta actividad es la verificación de la correcta instalación del sistema propuesto en el
ambiente de operación. Las tareas que componen esta actividad son:

 Auditorías de soporte de instalación y configuración

 Registro de las observaciones del sujeto de la prueba

2.2 Administración de Requerimientos

Las siguientes actividades están definidas para gestionar los resultados del plan de pruebas en su
ambiente de ejecución:

2.2.1 Reporte de anomalías

El procedimiento para reportar una anomalía en la propuesta de solución consiste en documentar
la siguiente plantilla:

Título de la anomalía: Nombre o referencia

Fecha de ocurrencia:
Contexto:
Descripción de la anomalía:
Impacto:
Descripción de la acción correctiva:
Estado de la anomalía:
Conclusiones y Recomendaciones:
DD/MM/AAAA
Nombre sistema afectado
Detalle del problema encontrado
Nombres de funcionalidades afectadas
Detalle de la corrección realizada
Pendiente, Corregido o Inválido
Detalle de conclusiones y recomendaciones relacionadas

Una vez diligenciada la plantilla, se debe adjuntar al directorio de anomalías sin resolver. Una vez
ha sido resuelta, se deberá cambiar de estado a resuelta y deberá ser archivada en el directorio de
anomalías resueltas.

2.2.2 Política de desvío del plan maestro de pruebas

En el caso de ocurrencia de la necesidad de incluir, eliminar o modificar el presente Plan Maestro
de Pruebas, será necesario detallar cada uno de los cambios realizados junto a su razón y efecto en
la calidad del sistema. Este documento será necesario como punto intermedio entre las versiones
del Plan Maestro, adicionalmente será obligatorio redefinir la sección 1.1 (Identificador de
Documento) con la versión actual del documento y adjuntar esta información al final de la sección
3.2 (Historial de Cambios del Documento).

2.2.3 Procedimiento de control

Los resultados de las pruebas y demás información sensible deberán ser almacenados privadamente
en las facilidades del administrador del sistema. Únicamente el administrador posee la facultad de
exponer la información a quien considere pueda tener el privilegio.

El manejo de información por tanto depende únicamente del administrador del sistema.

2.2.4 Estándares, prácticas y convenciones

En la ejecución y reporte de las pruebas a realizar, se deberá seguir el procedimiento indicado en el
documento “Plan Maestro de Pruebas”, el cual es una adaptación del proceso definido en IEEE 829
[2] junto a las pruebas definidas en el libro “Ingeniería de Software” de Sommerville [3].
En la interacción con los sujetos de prueba, se deberá mantener siempre una actitud de respeto y
servicio en todo momento.

Las convenciones aceptadas en cada reporte dependen de su especificación dentro del “Plan
Maestro de Pruebas”.

2.3 Formato de Reporte de Resultados de Pruebas

La plantilla a seguir para la documentación de los resultados de las pruebas es la siguiente:

Plantilla de Reporte de Pruebas del sistema SIGEEJ

Identificador de Reporte: RP-## Fecha:

Versión del Plan Maestro de Pruebas:

Nombre Encargado:

Nombre Sujeto de la Prueba:

Resumen de Procedimiento:

Elementos Involucrados en la prueba:

Ambiente de Prueba:

Observaciones del Sujeto de la Prueba:

Elementos Aprobados:

Elementos en Desacuerdo:
 Cambios Sugeridos:

3. General
A continuación, se define el glosario de términos y acrónimos utilizados a lo largo del documento,
adicionalmente se incluye un historial de cambios del presente documento.

3.1 Glosario
Los presentes acrónimos son utilizados:

 REU = Red de Emprendimiento Universitario

 FUC = Fundacion Universitaria Colombia (Sede Bogotá)
 SIG = Sistema de Información para la Gestión del Ecosistema de Emprendimiento

 Ecosistema de emprendimiento
El ecosistema es aquel ambiente o entorno en el que interactúan muchos seres, para este caso
particular el motivo que los relaciona es el emprendimiento. Por lo tanto, este ecosistema es
comprendido por todos aquellos espacios que dan lugar a oportunidades para emprender.

Cada ecosistema posee características que lo denotan único, pues existen variables determinantes
que afectan el estado de cada ecosistema. Entre ellas se pueden incluir las siguientes variables:
economía, cultura, filosofía, política, religión, entre otras. Adicionalmente a las variables
ambientales o geográficas que lo afectan, un ecosistema se particulariza también por los seres o
actores que lo componen, pues cada persona o conjunto de personas pueden ofrecer oportunidades
particulares que moldean el arte del emprendimiento.

De esta manera, un ecosistema de emprendimiento puede definirse como aquel ambiente regido
por características particulares y compuesto por actores, en su mayoría emprendedores, en donde
existen espacios u oportunidades para emprender.

 Red de Emprendimiento
Una red (de emprendimiento) puede definirse como un subsistema del ecosistema, en donde
existen actores o grupos de actores interconectados como unidades funcionales a favor del
desarrollo del emprendimiento. Lo que diferencia a la red dentro del ecosistema es su capacidad de
organización, dando a lugar a una entidad que busca sus propios objetivos.

Un ejemplo de una red es la red de emprendimiento, en donde existen individuos organizados que
buscan formar emprendedores por medio de oportunidades brindadas por parte de la Universidad
XXXXXX, inculcando a su vez los valores sociales.
  Documentación de Requerimientos
Los requerimientos son aquellas funcionalidades o características de un sistema. Así, la conjunción
de éstas son las que diferencian un sistema de otro. Sin embargo, estas a su vez deben ser
recolectadas porque individualmente carecen de sentido, es decir, que una vez reunidas generan la
identidad o el perfil del sistema en cuestión.

Con lo anterior en cuenta, una documentación de requerimientos es una colección de

funcionalidades y características en donde se plasman las funcionalidades de un sistema, con el fin
de definir una imagen o perfil de un sistema particular.

Como el caso del presente proyecto, la documentación de los requerimientos se ha realizado por
medio de un estándar internacional llamado “SyRS” y definido en [10]. La idea del uso de este
estándar es la unificación de las voluntades de los stakeholders en un único documento.

 Proceso de Negocio
Un proceso de negocio es aquella actividad fundamental o critica que posee tareas para poder ser
llevada a cabo. Puede tomarse como la causa o fundamento de operación de un negocio, por
ejemplo, el proceso de creación de productos en una compañía.

 Arquitectura del Sistema

La arquitectura del sistema son aquellos planos que indican el cómo debe construirse un sistema.
Estos planos por lo general siguen estándares internacionales y su utilidad se fundamenta en poder
plasmar gráficamente las características más relevantes. Para el caso del presente proyecto, se eligió
el uso del modelo arquitectónico “4+1” de Kruchten.

 Arquitectura “4+1” de Kruchten

La arquitectura “4+1” definida por Kruchten en [11] es un modelo compuesto por cinco vistas, la
cuales tienen sus propias razones y características. La vista lógica, la cual busca mostrar cuáles son
las funcionalidades del sistema. La vista de procesos, la cual busca definir los requerimientos no
funcionales y plasmar la sincronización de los procesos. La vista de desarrollo, la cual define los
subsistemas y componentes del sistema. La vista física, la cual se encarga de mapear el software en
el hardware. La vista de escenarios, la cual busca describir en detalle los procesos de negocio
fundamentales.

 Arquitectura AS-IS
El término “AS-IS” determina el momento en el tiempo, dando la connotación de que es una
arquitectura en el presente, es decir, la arquitectura del sistema tal cual es en la realidad del
presente.

 Arquitectura TO-BE
El término “TO-BE” hace referencia al momento futuro en el tiempo, es decir, que es la arquitectura
del sistema propuesto para el futuro, podría considerarse también, como la arquitectura ideal que
se pretende se haga realidad.
  Validación de Arquitectura
La validación de arquitectura es la acción de comprobar la correctitud y completitud de la
arquitectura. Este paso es necesario para verificar que la arquitectura en cuestión posee los
elementos correctos y está organizada de una manera aceptable.

 Prototipo
Es considerado como una materialización de prueba que verifica la correcta definición de un
sistema. Para el caso particular del desarrollo de un sistema de información, este prototipo es no
tangible, pero demuestra una vista aproximada de la voluntad de los stakeholders en el sistema.

 Prueba de Aceptación del Prototipo

Esta prueba de aceptación es la evaluación de aproximación del sistema con respecto a la visión
unificada de los stakeholders. La idea de esta evaluación es reenfocar las funcionalidades que se
desea posea en el sistema una vez sea implementado. Esta prueba es una analogía a la aceptabilidad
del desarrollo del sistema tal cual está definido.

3.2 Historial de Cambios del Documento