Está en la página 1de 67

UNIVERSIDAD NACIONAL EXPERIMENTAL DE GAUYANA

VICERRECTORADO ACADEMICO

PROYECTO DE CARRERA: INGENIERIA INFORMATICA.

UNIDAD CURRICULAR: INGENIERIA DE SOFTWARE II

SISTEMA DE ORGANIZACIÓN Y
GESTIÓN ACADÉMICA DESTINADO A
EVENTOS CIENTÍFICOS.

INFORME DEL SISTEMA

REALIZADO POR:
ESTUDIANTES DE INGENIERIA EN SOFTWARE II.
SECCION 1.
LAPSO ACADEMICO: 2018-2
SISTEMA DE ORGANIZACIÓN Y GESTIÓN ACADÉMICA DESTINADO A
EVENTOS CIENTÍFICOS.

TABLA DE CONTENIDO
informe del sistema .................................................................................................................. 0
Sistema de Organización y gestión académica destinado a eventos científicos. ................... 1

Tabla de contenido ........................................................................................................... 1

RESUMEN. ..................................................................................................................... 4

Capitulo 1. ....................................................................................................................... 5

ALCANCE. ...................................................................................................................... 6

CONSIDERACIONES. .................................................................................................... 6

RESTRICCIONES. .......................................................................................................... 7

REQUERIMIENTOS DEL SISTEMA. ............................................................................. 7


Requerimientos funcionales .......................................................................................................................... 7
Requerimientos no funcionales ..................................................................................................................... 8

Capitulo 2. ..................................................................................................................... 10

METODOLOGÍA PARA EL DESARROLLO DEL SOFTWARE. .................................... 11

Beneficios de la metodología efectuada. ......................................................................... 11

Capitulo 3. ..................................................................................................................... 13

Definicion de conceptos importantes............................................................................... 14

Análisis de riesgo ........................................................................................................... 16

Evaluación de Probabilidad e Impacto de los Riesgos ..................................................... 17

Planificar la respuesta a los riesgos ................................................................................ 17

Cuadro Análisis de riesgo ............................................................................................... 18

Estimación de la probabilidad: ........................................................................................ 19

Descripción de los riesgos y valores asociados a este: ...................................................... 19

Estimación de impacto: ................................................................................................... 20

Manual del Sistema: Sistema de Organización y gestión académica destinado a 1


eventos científicos.
Planeación de riesgos ..................................................................................................... 21
1.- ACTIVIDADES ACADÉMICAS QUE LIMITAN EL TIEMPO PARA EL DESARROLLO. ..................................... 21
2.- ESCASEZ DE PERSONAL PARA EL DESARROLLO DE APLICACIÓN MÓVIL. ................................................ 22
3.- Falta de información de los módulos de programación en el aspecto de desarrollo del diseño y
codificación tanto para la aplicación web como móvil. ............................................................................... 22

Capitulo 4. Estimacion de esfuerzo ............................................................................... 23

Estimación de esfuerzo ................................................................................................... 24

Estimación de esfuerzo utilizando metodología SCRUM ................................................... 24

Estimación de esfuerzo por punto de historia para el sistema de organización y gestión de


eventos científico UNEG. ................................................................................................. 24

Capitulo 5. ..................................................................................................................... 28

DiseÑo del software. ....................................................................................................... 29

1. Casos de Usos. ......................................................................................................... 29

2. Diagrama de Caso de Uso. ....................................................................................... 29

MODELO DE DATOS ................................................................................................... 36

3. DIAGRAMA DE CLASES. ...................................................................................... 37

Capitulo 6. ..................................................................................................................... 42

MODELO DE DATOS ................................................................................................... 43

Capitulo 7. ..................................................................................................................... 44

Metodología de Evaluación del Software ........................................................................ 45

Necesidad del Usuario .................................................................................................... 45

Calidad Estándar ............................................................................................................ 45

Innovación ..................................................................................................................... 46

Análisis de la Información ............................................................................................... 46

CALIDAD A EVALUAR ....................................................................................................... 47

Eficiencia de Desempeño ................................................................................................ 48

Compatibilidad ............................................................................................................... 48

Manual del Sistema: Sistema de Organización y gestión académica destinado a 2


eventos científicos.
Usabilidad ...................................................................................................................... 49

Fiabilidad ....................................................................................................................... 50

Seguridad ....................................................................................................................... 51

Mantenibilidad ............................................................................................................... 52

Capitulo 8. ..................................................................................................................... 54

1. INTRODUCCIÓN ................................................................................................... 55
1.1. OBJETIVO GENERAL ............................................................................................................... 55
1.2. ESTRATEGIA DE PRUEBAS .................................................................................................... 55
1.3. ALCANCE..................................................................................................................................... 55
1.4. PROPOSITO ................................................................................................................................. 55

2. ENTREGABLES ..................................................................................................... 56
2.1. DOCUMENTACIÓN A ENTREGAR ........................................................................................ 56

3. CARACTERISTICAS A SER PROBADAS .............................................................. 57

4. CARACTERISTICAS A NO SER PROBADAS ........................................................ 58

5. CRITERIOS DE APROBACIÓN Y FALLO ............................................................. 59

6. CRITERIOS DE SUSPENSIÓN Y REANUDACIÓN ............................................... 60

7. TAREAS DE LAS PRUEBAS .................................................................................. 61

8. NECESIDADES AMBIENTALES ........................................................................... 62


8.1. HARDWARE ................................................................................................................................ 62
8.2. SUT (SISTEMA BAJO PRUEBAS) ............................................................................................ 63
8.3. TEST-WARE. ............................................................................................................................... 63

Manual del Sistema: Sistema de Organización y gestión académica destinado a 3


eventos científicos.
RESUMEN.

En el ámbito educativo, específicamente, en el ámbito universitario, las personas


están abiertas a la realización de estudios investigativos, trabajos prácticos y actividades
sociales que contribuyan a la formación académica y la producción de conocimiento,
involucrando en ello valores informativos basados en la cooperación de los estudiantes con
las habilidades para una participación constructiva entre la universidad y la comunidad a
través de la formación de eventos. Es por ello que se decide implementar un sistema que
maneje la organización y gestión académica destinada a eventos científicos mediante una
serie de pasos y metodologías a seguir con el fin de desarrollar un sistema capaz de
facilitar la transacción, gestión y distribución de dicho evento, tomando en cuenta los
requisitos y requerimientos funcionales y no funcionales se detalla a continuación en forma
precisa la forma en la que se implementó y diseño el sistema.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 4


eventos científicos.
CAPITULO 1.
EL PROBLEMA Y SUS
GENERALIDADES

Manual del Sistema: Sistema de Organización y gestión académica destinado a 5


eventos científicos.
SISTEMA DE ORGANIZACIÓN Y
GESTION ACADEMICA DESTINADO A
EVENTOS CIENTIFICOS.

ALCANCE.

Con el desarrollo del sistema de organización y gestión académica destinado a evento


científicos, se espera llegar a la comunidad estudiantil y docente que hacen vida en la Universidad
Nacional Experimental de Guayana (UNEG). De manera que se cuente con una herramienta que
facilite la realización y control total de los diversos eventos y actividades, tales como Ponencias, foros
y conferencias, además de visualizar y modificar el Programa General y el Programa de Ponencias.
Todo esto, a través de dos aplicaciones: Una aplicación web con todas las funciones, para todos los
tipos de usuarios. y Una aplicación móvil en ambiente Android, exclusiva para la comisión
organizadora, que les permita buscar y consultar la planificación del evento y el control de sus
actividades.

CONSIDERACIONES.

En relación con los requerimientos de manejo de información y facilitando la gestión


y organización de eventos en una forma fácil, factible, y eficaz se llegó a la conclusión que
al momento del sistema entrar en operación deberá cubrir los módulos detallados a
continuación:

1. Administración del sistema, tomado en cuenta la gestión de usuario.

2. Configuraciones generales de sistema.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 6


eventos científicos.
RESTRICCIONES.

- El sistema no puede ser implementado si no existe acceso a Internet.

REQUERIMIENTOS DEL SISTEMA.

REQUERIMIENTOS FUNCIONALES

➢ Las personas asistentes pueden tener diferentes roles en diversas actividades.

➢ Debe haber una planificación de actividades que será el Programa General de


Actividades definidos por la comisión organizadora. Se debe poder especificar los
días y las horas de las actividades.

➢ Actividad Foro que se realiza luego de que la comisión organizadora apruebe la


solicitud del responsable. Consta de una temática relacionada con las áreas temáticas
de interés del evento, y tiene una duración y número de asistentes estimados, así
como pueden especificarse ciertas necesidades (por ej. Video-beam, preferencias
horarias, etc.).

➢ Un foro requiere un lugar adecuado y ser asignado en la planificación por la comisión


organizadora.

➢ Actividad Conferencia. Son similares a los foros, existe un conferencista invitado por
la organización que discurre sobre un tema relevante al evento.

➢ Las conferencias no pueden coincidir con las otras actividades y se realizan en el


espacio de mayor capacidad disponible.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 7


eventos científicos.
➢ Actividad Ponencia. Un ponente presenta un trabajo denominado ponencia. Las
ponencias se desarrollan por sesiones temáticas consecutivas en la planificación, y
deben ser aprobadas previamente por la comisión organizadora, tras ser evaluadas por
uno o más árbitros especialistas en el área temática.

➢ Los árbitros de cada ponencia son asignados por la comisión organizadora y se envía
un correo al árbitro al realizar la asignación.

➢ La evaluación del árbitro de la ponencia se realiza en un lapso previo al evento,


recibiendo un resumen en formato PDF/Word que se remite al árbitro, quien según
una lista de criterios evalúa la ponencia.

➢ Al momento de presentar la ponencia, también reciben en el sistema el trabajo “en


extenso” (un formato Word).

➢ La comisión organizadora debe poder controlar en todo momento las diferentes


actividades, en cada una de sus fases, así como visualizar y modificar el Programa
General y el Programa de Ponencias.
➢ Las aplicaciones deben ser genéricas y extensibles, permitiendo definir nuevos
eventos, actividades, usuarios, espacios y demás parámetros.

REQUERIMIENTOS NO FUNCIONALES

Apariencia o interfaz externa:

1 El sistema tendrá una interfaz intuitiva y amigable para su fácil manejo.


2 El sistema proporcionará claridad y correcta organización de la
información presente en el mismo.
3 Se manejarán varios paneles y subpaneles que tendrán funcionalidades
diferentes.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 8


eventos científicos.
Requerimiento de Usabilidad:

a. El diseño de la interfaz del sistema deberá ser sencillo, junto con elementos
visuales que capten la atención de forma inmediata.
b. Su contenido deberá ser redactado principalmente en el idioma español, ya
que es el idioma común de la audiencia a la que va dirigido el producto.

Requerimiento de Seguridad:

a. Disponibilidad: La información general estará disponible para todos los


usuarios que accedan al sistema. No obstante, dependiendo el rol del
usuario, cada uno tendrá acceso especial a ciertas características.

b. Confiabilidad: El sistema deberá permitir el acceso controlado a diversos


usuarios que posean un usuario y contraseña

c. Estabilidad: Estará desarrollado por medio de técnicas de programación


que limitan la entrada de datos arbitrarios a la aplicación con el fin de que
el sistema se mantenga estable y seguro garantizando un mínimo
porcentaje de fallos durante su uso.

d. Portabilidad: Dado que el sistema esta orientado a web, y además tiene su


aplicación Android, puede ser usado en Tablet, dispositivos Android o
computadoras de cualquier sistema operativo con un navegador que
soporte los diferentes componentes que tiene la aplicación.

Requerimiento de Software:

- Máquina con acceso a internet

Manual del Sistema: Sistema de Organización y gestión académica destinado a 9


eventos científicos.
CAPITULO 2.
METODOLOGIA COMO BASE DE
DESARROLLO

Manual del Sistema: Sistema de Organización y gestión académica destinado a 10


eventos científicos.
METODOLOGÍA PARA EL DESARROLLO DEL SOFTWARE.

En el mundo del desarrollo ha habido una evolución y en la actualidad los cambios se producen
de manera increíblemente rápida y se producen cambios dentro de los cambios. En un mundo tan
cambiante, donde predominan los tiempos y la rentabilidad, muchas veces las empresas olvidan un
factor fundamental: la calidad. Debido a esto surgen las que son metodologías ágiles, que se basan en
un manifiesto de valores y principios que se deben cumplir.

Se ha seleccionado Scrum como la metodología ágil a implementar en este proyecto. Scrum es


una metodología ágil y flexible; un marco de trabajo para desarrollar, entregar y mantener productos
complejos

BENEFICIOS DE LA METODOLOGÍA EFECTUADA.

➢ Cumplimiento de expectativas. El cliente establece sus expectativas indicando el


valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con
esta información el Product Owner establece su prioridad. De manera regular, en las
demos de Sprint el Product Owner comprueba que efectivamente los requisitos se han
cumplido y transmite su feedback al equipo.

➢ Flexibilidad a cambios. Alta capacidad de reacción ante los cambios de


requerimientos generados por las necesidades del cliente o evoluciones del mercado.
La metodología está diseñada para adaptarse a los cambios de requerimientos que
conllevan los proyectos complejos.

➢ Reducción del Time To Market. El cliente puede empezar a utilizar las


funcionalidades más importantes del proyecto antes de que esté finalizado por
completo.

➢ Mayor calidad del software. La metódica de trabajo y la necesidad de obtener una


versión funcional después de cada iteración, ayuda a la obtención de un software de
calidad superior.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 11


eventos científicos.
➢ Mayor productividad. Se consigue entre otras razones, gracias a la eliminación de la
burocracia y a la motivación del equipo que proporciona el hecho de que sean
autónomos para organizarse.

➢ Maximiza el retorno de la inversión (ROI). Producción de software únicamente con


las prestaciones que aportan mayor valor de negocio gracias a la priorización por
retorno de inversión.

➢ Predicciones de tiempos. Mediante esta metodología se conoce la velocidad media


del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es
posible estimar fácilmente para cuando se dispondrá de una determinada
funcionalidad que todavía está en el Backlog.

➢ Reducción de riesgos. El hecho de llevar a cabo las funcionalidades de más valor en


primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto,
permite despejar riesgos eficazmente de manera anticipada.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 12


eventos científicos.
CAPITULO 3.
ESTIMACION DE RIESGO.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 13


eventos científicos.
DEFINICION DE CONCEPTOS IMPORTANTES

¿QUÉ ES UN RIESGO?

Riesgo es la probabilidad de que el resultado sea diferente a lo esperado, riesgo es una


amenaza evaluada en cuanto a su probabilidad de ocurrencia y la gravedad de sus
consecuencias posibles, y la definición más completa, riesgo es la posibilidad de ocurrencia
de un evento que puede afectar el cumplimiento de los objetivos.

El riesgo de un proyecto es un evento o condición incierta que, de producirse, tiene un


efecto positivo o negativo en uno o más de los objetivos del proyecto, tales como el alcance,
el cronograma, el costo y la calidad. Un riesgo puede tener una o más causas y, de
materializarse, uno o más impactos. Una causa puede ser un requisito especificado o
potencial, un supuesto, una restricción o una condición que crea la posibilidad de
consecuencias tanto negativas como positivas.

Las condiciones de riesgo pueden incluir aspectos del entorno del proyecto o de la
organización que contribuyan a poner en riesgo el proyecto, tales como las prácticas
deficientes de dirección de proyectos, la falta de sistemas de gestión integrados, la
concurrencia de varios proyectos o la dependencia de participantes externos fuera del ámbito
de control directo del proyecto

El riesgo en proyectos de software generalmente se define como el impacto de la


probabilidad ponderada de un evento en un proyecto. De manera simple R = P * I donde R es
la exposición al riesgo atribuible a un factor de riesgo en particular, P es la probabilidad de
que el evento no deseado ocurra e I es el impacto o la magnitud de la perdida si se produce el
evento.

Para evaluar un riesgo, este se define como la multiplicación de dos factores: La


frecuencia o posibilidad de un mal funcionamiento y la consecuencia del fallo del sistema
(severidad) de la siguiente manera: R= Frecuencia * Severidad.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 14


eventos científicos.
Un riesgo de un proyecto es un evento o condición incierto, que si se produce tendrá
un efecto positivo o negativo sobre al menos un objetivo del proyecto, como tiempo, costo,
alcance o calidad.

Este incluye tanto las amenazas para con los objetivos del proyecto como las
oportunidades para mejorar aquellos objetivos. Esto tiene su origen en la incertidumbre que
tienen incorporada todos los proyectos.

Los riesgos conocidos son aquellos que han sido identificados y analizados, y para los
que puede ser posible contar con un plan de mitigación. Los riesgos desconocidos no se
pueden controlar, aunque los gerentes de proyectos pueden abordarlos, aplicando una
contingencia general basada en la experiencia pasada con proyectos similares.

¿Qué es mitigación?

Mientras que la prevención es anticipación, mitigación es acción en el momento del


peligro o la presencia del riesgo. Al igual que la prevención, ésta se logra a través del diseño
y aplicación de políticas, normas, controles y procedimientos, conducentes a disminuir la
intensidad o el impacto negativo sobre los recursos amenazados, que generan los riesgos en
caso de ocurrencia

Mitigar el riesgo es una estrategia de respuesta a los riesgos según la cual el equipo
del proyecto actúa para reducir la probabilidad de ocurrencia o impacto de un riesgo. Implica
adoptar acciones tempranas para reducir la probabilidad de ocurrencia de un riesgo y/o su
impacto sobre el proyecto, a menudo es más eficaz que tratar de reparar el daño después de
ocurrido el riesgo.

¿Qué es contingencia?

Es un evento o una ocurrencia que podría afectar la ejecución del proyecto y que
puede tenerse en cuenta con una reserva.

Un plan de contingencia se define como un conjunto de procedimientos operativos


específicos y preestablecidos de coordinación, alerta y respuesta ante la ocurrencia de un
riesgo

Manual del Sistema: Sistema de Organización y gestión académica destinado a 15


eventos científicos.
Con el plan de contingencia se definen las acciones que emprenderá la compañía, para
controlar la situación que afecta su operación y reducir los efectos negativos que puede
originarle. Este se elabora previamente y en él se establecen puntos de activación, que
corresponden a señales que indican situaciones críticas según el tipo de riesgo tratado y que
determinan el inicio del plan de contingencia

. Algunos aspectos que se tienen en cuenta en la elaboración de los planes de


contingencia son:

a. Identificar la prioridad de los procesos críticos del proyecto.

b. Identificar los recursos requeridos para soportar estos procesos.

c. Establecer el tiempo máximo que se pueda operar sin la ejecución de cada uno de
ellos.

d. Definir como se llevaría a cabo las acciones de recuperación, los equipos que se
podrían utilizar, el personal de soporte, las instalaciones que se podrían adecuar, etc.

e. Determinar para cada proceso crítico el tiempo máximo de recuperación, la relación


con otros procesos, los recursos de soporte.

f. Definir el responsable de manejar el plan de contingencia y su equipo de trabajo.

g. Establecer las funciones de cada uno de los miembros del equipo: quién evaluará
los daños, quién atenderá a usuarios y clientes, quién participará en la operación de
recuperación, quién apoyará logística y administrativamente el plan.

Los planes de contingencia deben ser probados para ajustarlos a las necesidades del proyecto
y aprobados por la dirección, con el fin de recibir el apoyo que requieren para su
funcionamiento.

ANÁLISIS DE RIESGO

El Análisis de Riesgos es el proceso de determinar los riesgos que pueden afectar al proyecto
y documentar sus características. El beneficio clave de este proceso es la documentación de los
riesgos existentes y el conocimiento y la capacidad que confiere al equipo del proyecto para anticipar
eventos.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 16


eventos científicos.
Identificar los riesgos es un proceso iterativo debido a que pueden evolucionar o se pueden
descubrir nuevos riesgos conforme el proyecto avanza a lo largo de su ciclo de vida. El formato de las
declaraciones de riesgos debe ser consistente para asegurar que cada riesgo se comprenda claramente
y sin ambigüedades a fin de poder llevar a cabo un análisis y un desarrollo de respuestas eficaces. El
proceso debe involucrar al equipo del proyecto de modo que pueda desarrollar y mantener un sentido
de propiedad y responsabilidad por los riesgos y las acciones de respuesta asociadas. Los interesados
externos al equipo del proyecto pueden proporcionar información objetiva adicional

EVALUACIÓN DE PROBABILIDAD E IMPACTO DE LOS RIESGOS

La evaluación de la probabilidad de los riesgos estudia la probabilidad de ocurrencia de cada


riesgo específico. La evaluación del impacto de los riesgos estudia el efecto potencial de los mismos
sobre un objetivo del proyecto, tal como el cronograma, el costo, la calidad o el desempeño, incluidos
tanto los efectos negativos en el caso de las amenazas, como los positivos, en el caso de las
oportunidades. Para cada uno de los riesgos identificados, se evalúan la probabilidad y el impacto

PLANIFICAR LA RESPUESTA A LOS RIESGOS

Planificar la Respuesta a los Riesgos es el proceso de desarrollar opciones y acciones para


mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. El beneficio clave de
este proceso es que aborda los riesgos en función de su prioridad, introduciendo recursos y
actividades en el presupuesto, el cronograma y el plan para la dirección del proyecto, según las
necesidades.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 17


eventos científicos.
CUADRO ANÁLISIS DE RIESGO

Factor de Tipo Riesgo Descripción Posibles


Riesgo Consecuencias

Interno Externo

Académico X Actividades Falta de tiempo, No entregar los


académicas que Exceso de avances, ni el
limitan el tiempo evaluaciones y proyecto a
para el actividades tiempo al
desarrollo. pendientes por cliente
cada asignatura
que eviten el
trabajar en el
proyecto
asignado

Personal de X Escasez de La plataforma Entregar una


trabajo personal para el móvil forma aplicación
desarrollo de una parte poco funcional
aplicación móvil. esencial en el por falta de
enfoque de lo experiencia y
que se exige conocimientos
resolver en este
proyecto,
muchos de los
participantes
poseen
dificultades en
esta área y de
esta forma
significa una
desventaja

Falta de X Falta de La naturaleza Entregar un


Información información de del problema proyecto poco
los módulos de que abarca funcional y

Manual del Sistema: Sistema de Organización y gestión académica destinado a 18


eventos científicos.
programación en realizar todo un nada atractivo
el aspecto de proyecto. para el cliente
desarrollo del
diseño y
codificación
tanto para la
aplicación web
como móvil.

Tabla 1: Análisis de riesgo

ESTIMACIÓN DE LA PROBABILIDAD:
Consta en definir los rangos y valores para cada riesgo.

Rango de Expresión del Promedio para el Valor numérico


calculo
probabilidad lenguaje natural

De 1 % a 10 % Baja 5% 1

De 11 % a 25 % Poco probable 18 % 2

De 26 % a 55 % Media 40 % 3

De 56 % a 80 % Altamente probable 68 % 4

De 81 5 a 99% Casi seguro 90 % 5

Tabla 2: Estimación de probabilidad

Por otra parte, se le asocia una expresión regular a cada riesgo, para que cada expresión tenga
una probabilidad de ocurrir como se puede ver a continuación

DESCRIPCIÓN DE LOS RIESGOS Y VALORES ASOCIADOS A ESTE:


Id Riesgo Expresión Probabilidad

1 Actividades Altamente Probable 60 %


académicas que
limitan el tiempo para
el desarrollo.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 19


eventos científicos.
2 Escasez de personal media 35 %
para el desarrollo de
aplicación móvil.

3 Falta de información media 20 %


de los módulos de
programación en el
aspecto de desarrollo
del diseño y
codificación tanto
para la aplicación web
como móvil.

Tabla 3: Descripción de los riesgos y valores

ESTIMACIÓN DE IMPACTO:
Establece los criterios que definirán el impacto y se le asocia un valor numérico que se
traduce en algún costo que asume el proyecto

DESCRIPCIÓN DEL IMPACTO

Criterio Retraso en la planificación Valor numérico

Insignificante 1 semana 1

Marginal 2 semanas 2

Medio Critico 1 mes 3

Catastrófico Mas de 1 mes 4

Tabla 4: Descripción del impacto

Como resultado del análisis tenemos:

ID RIESGO PROBABILIDAD IMPACTO EXPOSICION

1 Actividades 60 % 2 1,2
académicas que
limitan el tiempo
para el
desarrollo.

2 Escasez de 30 % 3 1,05

Manual del Sistema: Sistema de Organización y gestión académica destinado a 20


eventos científicos.
personal para el

desarrollo de

aplicación móvil.

3 Falta de 20% 1 2,0


información de
los módulos de
programación en
el aspecto de
desarrollo del
diseño y
codificación
tanto para la
aplicación web
como móvil.

Tabla 5: Resultado final del análisis de riesgo.

La columna de exposición hace referencia a la exposición de riesgo que afecta directamente al


proyecto.

PLANEACIÓN DE RIESGOS

1.- ACTIVIDADES ACADÉMICAS QUE LIMITAN EL TIEMPO PARA EL DESARROLLO.


 Aspectos a considerar:

Se requiere de tiempo para la completa elaboración de un proyecto de software, por ende, se debe
sacar espacio para las tareas que se asignen relacionadas al proyecto.
 Plan de acción:

Organizar el trabajo con ayuda de una buena metodología y dinámica que ayude al cumplimiento de
los requerimientos para su aprobación.
 Plan de contingencia:

Se debe estudiar la situación de personas disponibles e intercambiar o asignar roles nuevos, para que
el desarrollo del proyecto siga en pie.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 21


eventos científicos.
2.- ESCASEZ DE PERSONAL PARA EL DESARROLLO DE APLICACIÓN MÓVIL.
 Aspectos a considerar:

La plataforma móvil forma una parte esencial en el enfoque de lo que se exige resolver en este
proyecto, muchos de los participantes poseen dificultades en esta área y de esta forma significa una
desventaja.
 Plan de acción:

Buscar información, tutoriales y videos sobre el tema, de modo que el equipo seleccionado para tal fin
sea beneficiado, obtenga nuevos conocimientos y al mismo tiempo se obtenga avances respecto a la
tarea otorgada.
 Plan de contingencia:

Enfocarse en el desarrollo móvil, con el fin de completar todos los requerimientos propuestos.

3.- FALTA DE INFORMACIÓN DE LOS MÓDULOS DE PROGRAMACIÓN EN EL


ASPECTO DE DESARROLLO DEL DISEÑO Y CODIFICACIÓN TANTO PARA LA
APLICACIÓN WEB COMO MÓVIL.

 Aspectos a considerar.

La naturaleza del problema que abarca realizar todo un proyecto.


 Plan de acción.

Practicar más la comunicación entre los departamentos, con el fin de promover nuevas ideas y
herramientas.
 Plan de contingencia.

Convocar nuevas reuniones con carácter de urgencia para aclarar dudas y establecer propuestas

Manual del Sistema: Sistema de Organización y gestión académica destinado a 22


eventos científicos.
CAPITULO 4.
ESTIMACION DE ESFUERZO

Manual del Sistema: Sistema de Organización y gestión académica destinado a 23


eventos científicos.
ESTIMACIÓN DE ESFUERZO

Es un proceso de la planificación de proyecto que permite determinar cuánto tiempo


durará el proyecto en realizarse, el esfuerzo que se requiere y numero de persona que se
necesita, con el objetivo de definir el tiempo en el que se entregará el proyecto.

ESTIMACIÓN DE ESFUERZO UTILIZANDO METODOLOGÍA SCRUM

El proyecto se realiza bajo la metodología ágil SCRUM, por tal razón se estimó
esfuerzo usando puntos de historia. Estimar esfuerzo por punto de historia permite el número
de sprint a realizarse en el proyecto, un sprint puede tener varias historias o tareas, las
historias son ponderadas según su nivel de dificultad.

Pero, ¿Cómo darle punto a una historia?, pues se determina una historia pivote que
todos los integrantes del equipo dominen y las demás historias se le da una puntuación según
el nivel de dificulta que presente con respecto a la historia pivote.

Finalmente, la suma de los puntos de historia por tarea será los puntos de historia que
tendrá ese sprint.

ESTIMACIÓN DE ESFUERZO POR PUNTO DE HISTORIA PARA EL SISTEMA DE


ORGANIZACIÓN Y GESTIÓN DE EVENTOS CIENTÍFICO UNEG.

Sprint 1:

N° Historia Punto

1 Establecer términos y criterios del desarrollo del producto con el 8


cliente en cuestión.

2 Analizar los requisitos. 10

Manual del Sistema: Sistema de Organización y gestión académica destinado a 24


eventos científicos.
3 Escoger la metodología de trabajo a implementar. 2

4 Realizar un plan de trabajo para agilizar la entrega del sprint. 8

5 Dividir el equipo de desarrollo en sub equipos según las necesidades 5


del proyecto, capacidad del personal, y tiempo requerido.

6 Estimar la cantidad de esfuerzo necesario para implementar cada 5


sprint.

7 Revisión de la documentación correspondiente al primer avance por 3


parte del equipo de trabajo.

8 Realizar entrega de la documentación correspondiente al primer 3


avance, la cual incluye breve descripción de cada ítem abordado
anteriormente.

9 Revisión de la documentación correspondiente al primer avance por 3


parte del equipo de la parte interesada en el desarrollo del sistema
(el cliente)

Tabla 6: Sprint 1

Sprint 2.

N° Historia Punto

1 Analizar y diseñar los requerimientos del sistema a profundidad. 10


(Descripción de los Casos de uso, general y detallado por procesos.)

2 Prever detalladamente la estimación de esfuerzo y tiempo. 8

3 Enfocar la calidad del sistema 8

4 Analizar y detallar el riesgo involucrado 8

5 Diseñar, documentar y modelar los datos correspondientes al 8


desarrollo de la base de datos tomando en cuenta el diccionario de
datos, diagrama relacional, diagrama entidad relación.

6 Diseñar la arquitectura correspondiente al sistema, involucrando en 8


el proceso, al diagrama de clases, diagrama de estado, diagrama de

Manual del Sistema: Sistema de Organización y gestión académica destinado a 25


eventos científicos.
comportamiento.

7 Diseñar interfaz a utilizar detallando su comportamiento uso y 8


funcionalidad.

8 Analizar y Documentar los sprint que se van abordar. 5

9 Revisión de la documentación correspondiente al segundo avance 5


por parte del equipo de trabajo.

10 Realizar entrega de la documentación correspondiente al segundo 5


avance, la cual incluye breve descripción de cada ítem abordado
anteriormente.

11 Revisión de la documentación correspondiente al segundo avance 5


por parte del equipo de la parte interesada en el desarrollo del
sistema (el cliente).

Tabla 7: Sprint 2

Sprint 3

N° Historia Punto

1 Codificación del api. 8

2 Desarrollo de la aplicación web. 10

3 Desarrollo de la aplicación móvil. 10

4 Pruebas unitarias. 8

5 Entrega final del producto 5

Tabla 8: Sprint 3

Resultado de estimación de esfuerzo por punto de historia para el sistema de


organización y gestión de eventos científico UNEG.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 26


eventos científicos.
Iteración o Puntos de historia
Sprint

1 47

2 78

3 41

Tabla 9: Resultado de estimación de esfuerzo

Resultado de estimación de tiempo para el sistema de organización y gestión de eventos


científico UNEG.

Iteración Puntos de Horas Disponibilidad Horas Hora por


o Sprint historia hombre hombres puntos de
estimadas dedicadas historia

1 47 161 50% 81 0,58

2 78 161 50% 81 0,58

3 41 120 50% 60 0,68

Tabla 10: Resultado de estimación de tiempo

Estimación= (47+78+41)/11

Estimación= 166/11

Estimación= 15 aproximadamente 15 iteraciones

Como se realizara 15 iteraciones por semana, se concluye en estimado de tiempo igual a 15


semanas.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 27


eventos científicos.
CAPITULO 5.
DEFINICION DEL DISEÑO
IMPLEMENTADO.
.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 28


eventos científicos.
DISEÑO DEL SOFTWARE.

El proceso de diseño del sistema divide los requerimientos en sistemas ya sea hardware
o software. Establece una arquitectura completa del sistema, el diseño identifica y describe
los elementos abstractos que son fundamentales para el software y sus relaciones, entre ellos:

1. CASOS DE USOS.

En esta sección se van a detallar los casos de uso que se han definido durante la fase de
análisis del proyecto. Los casos de uso cubren las distintas funcionalidades que podrán
realizar los distintos usuarios que interactúen con el producto.

2. DIAGRAMA DE CASO DE USO.

C.U. Ingresar al sistema: Una vez que el usuario entra al sistema puede buscar y
visualizar eventos, además de ello algunos usuarios tienen la posibilidad de gestionar eventos,
esto depende según el rol de usuario; Administrador, organizador o asistente.

Caso de uso Ingresar al sistema


Actores Administrador, organizador y asistente.
Propósito Permitir a los usuarios ingresar al sistema y poder realizar
diferentes acciones relacionadas a los eventos científicos y
gestión de sus cuentas.
Precondiciones 1. iniciar sesión
Flujo principal 1. Iniciar aplicación
2. Iniciar sesión
2.1 Seleccionar gestionar evento
2.2 Seleccionar gestionar cuenta
2.2.1 Modificar datos

Manual del Sistema: Sistema de Organización y gestión académica destinado a 29


eventos científicos.
2.2.2 Actualizar datos
2.3 Seleccionar buscar evento.
2.3.1 Ingresar busqueda
2.3.2 Ver evento
2.4 Seleccionar visualizar eventos.
Flujo Mostrar mensaje de error si los datos suministrados son
alternativo incorrectos.

Tabla 11: Caso de uso-Ingresar al sistema

Figura 1: Caso de uso - Ingresar al sistema

Manual del Sistema: Sistema de Organización y gestión académica destinado a 30


eventos científicos.
C.U: Organizador de eventos científicos: Permite a un usuario de tipo
administrador, organizador o asistente, ingresar a algunos subprocesos tomando en cuenta el
rol que cumple. Todos los usuarios pueden ingresar al sistema, los asistentes pueden buscar y
visualizar eventos y los organizadores pueden buscar e ingresar a los eventos, el
administrador tiene la responsabilidad de gestionar las cuentas de acceso que pertenecerán a
los usuarios para poder ingresar al sistema además puede gestionar los demás módulos del
mismo.

Caso de Organizador de eventos científicos


uso
Actores Administrador, organizador y asistente.
Propósit Presenta la funcionalidad principal del sistema y las
o diferentes opciones que tiene disponible el usuario para
acceder al mismo.
Precondi 1. Ingresar a la aplicación.
ciones
Flujo 1. Iniciar aplicación
principal
1.1 Seleccionar gestionar usuarios
1.2 Seleccionar iniciar sesión.
1.3 Seleccionar buscar evento.
1.4 Seleccionar visualizar eventos.
Flujo Ninguno.
alternativo

Tabla 12: Caso de uso - Organizar evento científico

Manual del Sistema: Sistema de Organización y gestión académica destinado a 31


eventos científicos.
Figura 2: Caso de uso - Organizador de eventos científicos

Manual del Sistema: Sistema de Organización y gestión académica destinado a 32


eventos científicos.
C.U. Gestionar Eventos: en este caso de uso solo pueden acceder los administradores
y organizadores con el objetivo de gestionar las actividades, agregar eventos, pudiéndose
modificar y eliminar un evento.

Caso de Gestionar Eventos


uso
Actores Administrador y organizador.
Propósit Permite gestionar los eventos a realizar incluyendo sus
o actividades y todo el protocolo necesario para lograr dicho
evento.
Precondi 1. Ingresar a la aplicación.
ciones
2.Iniciar sesión.
Flujo 1. Iniciar aplicación
principal
2. Iniciar sesión.
2.1 Seleccionar gestionar Actividad
2.1.2 Seleccionar registrar actividad
2.1.3 Seleccionar modificar actividad
2.1.4 Seleccionar eliminar actividad
2.2 Seleccionar agregar evento
2.2.1 Registrar datos
2.2.2 Registrar actividad
2.2.3 Guardar datos
2.3 Seleccionar modificar evento.
2.3.1 Seleccionar evento
2.3.2 actualizar datos
2.4 Seleccionar eliminar evento
2.4.1 Seleccionar evento
2.4.2 Eliminar evento
Flujo Mostrar mensaje si se produce algún error.
alternativo

Manual del Sistema: Sistema de Organización y gestión académica destinado a 33


eventos científicos.
Tabla 13: Caso de uso- Gestionar eventos

Figura 3: Caso de uso - Gestionar Eventos

Manual del Sistema: Sistema de Organización y gestión académica destinado a 34


eventos científicos.
C.U. Gestionar Usuarios: en este proceso solo pueden acceder los administradores del
sistema con el objetivo de gestionar las cuentas de los usuarios, el administrador es el único
actor con la potestad de agregar nuevos usuarios, modificar y eliminar usuarios existentes.

Gestionar usuarios
Caso de uso
Actores Administrador.
Propósito Permitir al administrador la gestión en la cuenta de los
usuarios..
Precondi 1. iniciar aplicación
ciones
Flujo 1. Iniciar aplicación
principal
1.2 Seleccionar agregar usuario
1.2.1 Registrar datos
1.2.2 Guardar datos
1.3 Seleccionar modificar usuario.
1.3.1 Seleccionar usuario
1.3.2 actualizar datos
1.4 Seleccionar eliminar usuario.
1.4.1 Seleccionar usuario
1.4.2 Eliminar usuario
Flujo Mostrar mensaje de error si los datos suministrados son
alternativo incorrectos.

Tabla 14: Caso de uso- Gestionar usuarios

Manual del Sistema: Sistema de Organización y gestión académica destinado a 35


eventos científicos.
Figura 4: Caso de uso - Gestionar Usuarios

MODELO DE DATOS

Gestionar Usuario: El único que accede a este proceso es el administrador, es quien agrega, modifica
y elimina usuario, tomando en cuentas una serie de subprocesos que validan la información
suministrada.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 36


eventos científicos.
3. DIAGRAMA DE CLASES.

Figura 5: Diagrama de clases

Manual del Sistema: Sistema de Organización y gestión académica destinado a 37


eventos científicos.
Clase usuarios: se utiliza para almacenar información acerca de los usuarios del sistema.
Permite recuperar los datos de manera confiable en el momento de la autenticación.

La clase Usuarios Esta compuesta por los siguientes atributos:


 Id: atributo para almacenar la clave primaria de usuario.
 Email: atributo para almacenar el email del usuario.
 Contraseña: atributo para almacenar la clave del usuario.
 Nombre: atributo para almacenar el nombre del usuario.
 Teléfono: atributo para almacenar el teléfono del usuario.
 Dirección: atributo para almacenar la dirección del usuario.

Clase Roles: se utiliza para almacenar los distintos tipos de roles del usuario; un usuario
puede ser administrador, organizador, usuario común.

La relación roles está compuesta por los siguientes atributos:


 Id: atributo para almacenar la clave primaria del rol.
 descripción: atributo para almacenar la descripción del rol.

Clase Usuario_rol: se utiliza para asociar un id de usuario con un rol correspondiente.

La relación usuario_rol está compuesta por los siguientes atributos:


 Usuario_id: atributo para almacenar la clave primaria de usuario.
 Rol_id: atributo para almacenar el rol del usuario.

Clase Evento_organizador: se utiliza para asociar un organizador de eventos, es decir, el


usuario con un evento en específico.

La clase evento_organizador está compuesta por los siguientes atributos:


 Organizador_id: atributo para almacenar la clave primaria del usuario.
 Evento_id: atributo para almacenar la clave primaria del evento.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 38


eventos científicos.
Clase Eventos: se utiliza para almacenar los eventos del sistema.
La clase eventos está compuesta por los siguientes atributos:
 Id: atributo para almacenar la clave primaria del evento.
 Descripción: atributo para almacenar la descripción del evento.
 Fecha_inicio: atributo para almacenar la fecha de inicio del evento.
 Fecha_fin: atributo para almacenar la fecha de culminación del evento.

Clase Actividades: esta relación es utilizada para almacenar las distintas actividadesque se
dan dentro de un evento.

La clase Actividades está compuesta por los siguientes atributos:


 Id: atributo para almacenar la clave primaria de la actividad.
 Descripción: atributo para almacenar la descripción de la actividad.
 Tipo: atributo para almacenar el tipo de actividad.
 Evento_id: atributo para almacenar la clave foránea del evento asociado a
la actividad.
 Fecha_inicio: atributo para almacenar la fecha de inicio de la actividad.
 Fecha_fin: atributo para almacenar la fecha de culminación de la actividad.
 Responsable_id: atributo para almacenar la clave foránea del usuario
responsable de la actividad.
 Capacidad: atributo para almacenar la cantidad máxima de personas en
una actividad.
 Espacio_id: atributo para almacenar la clave foránea del espacio asociado.
 Satus: atributo para almacenar el status de la actividad.
 Temática_id: atributo para almacenar la clave foránea de la temática
asociada a la actividad.

Clase Temáticas: esta relación es utilizada para almacenar las distintas temáticas
correspondientes a las actividades del sistema.

La clase Tematicas está compuesta por los siguientes atributos:


 Id: atributo para almacenar la clave primaria de la temática.
 Descripción: atributo para almacenar la descripción de la temática.
Manual del Sistema: Sistema de Organización y gestión académica destinado a 39
eventos científicos.
Clase Necesidades: esta relación es utilizada para almacenar las distintas necesidades de las
actividades del sistema.

La clase necesidades está compuesta por los siguientes atributos:


 Id: atributo para almacenar la clave primaria de la necesidad.
 Actividad_id: atributo para almacenar la actividad asociada a la necesidad.
 Descripción: atributo para almacenar la descripción de la necesidad.

Clase Espacios: esta relación es utilizada para almacenar los espacios de las
actividades del sistema.

La relación espacios está compuesta por los siguientes atributos:


 Id: atributo para almacenar la clave primaria de los espacios.
 Capacidad: atributo para almacenar la máxima cantidad de personas del
espacio.
 Descripción: atributo para almacenar la descripción del espacio.

Clase Arbitro_ponencia: se utiliza para almacenar el árbitro auditor de una actividad de tipo
ponencia.

La relación arbitro_ponencia está compuesta por los siguientes atributos:


 Arbitro_id: atributo para almacenar la clave primaria del árbitro.
 Actividad_id: atributo para almacenar la clave primaria de la actividad.
 Evaluacion_ponencia: se utiliza para almacenar la evaluación de un árbitro en una
actividad de tipo ponencia.

La clase evaluacion_ponencia está compuesta por los siguientes atributos:


 Arbitro_id: atributo para almacenar la clave primaria del árbitro.
 Actividad_id: atributo para almacenar la clave foránea de la actividad
asociada.
 Evaluación: atributo para almacenar la evaluación del árbitro.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 40


eventos científicos.
Clase Documentos: se utiliza para almacenar los documentos de una actividad.

La clase documentos está compuesta por los siguientes atributos:


 Id: atributo para almacenar la clave primaria del documento.
 Actividad_id: atributo para almacenar la clave foránea de la actividad
asociada.
 Descripción: atributo para almacenar la descripción del documento.
 Path: atributo para almacenar la ruta del documento.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 41


eventos científicos.
CAPITULO 6.
MODELO Y DICCIONARIO DE DATOS.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 42


eventos científicos.
MODELO DE DATOS

Es un sistema formal y abstracto que permite describir los datos de distintos niveles de
abstracción de la estructura de una base de datos. Según Dittrich (1994). Los modelos de
datos comprenden aspectos relacionados con: estructuras y tipos de datos, operaciones y
restricciones.

Modelo entidad-relación:

“Es la percepción de un mundo real que consiste en un conjunto de objetos básicos


llamados entidades y de unas relaciones entre estos objetos. Se utiliza para esquematizar la
estructura lógica general de lo que será la base de datos” (Fray León Osorio Rivera, 2008,
p25).

Figura 6: Diagrama Entidad-Relación

Manual del Sistema: Sistema de Organización y gestión académica destinado a 43


eventos científicos.
CAPITULO 7.
CALIDAD APLICADA A LA
EVALUACION DEL SOFTWARE.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 44


eventos científicos.
METODOLOGÍA DE EVALUACIÓN DEL SOFTWARE

Objetivos

Los objetivos de la metodología de la evaluación se basan en tres puntos clave que se tomarán
siempre en cuenta al momento de evaluar, explicados a continuación:

NECESIDAD DEL USUARIO

Basándose en el cumplimiento de los requerimientos, con la elaboración de una solución


tecnológica para la realización del proceso correspondiente a la Organización Académica de Eventos
Científicos, unegista. Se desarrolla un sistema de control e información de los Eventos Científicos,
permitiéndole a La Comisión Organizadora controlar en todo momento las diferentes actividades, en
cada una de sus fases, así como visualizar y modificar el Programa General y el Programa de
Ponencias, entre otras funcionalidades.

CALIDAD ESTÁNDAR

El modelo de calidad representa la piedra angular en torno a la cual se establece el sistema para la
evaluación de la calidad del producto. En este modelo se determinan las características de calidad que
se van a tener en cuenta a la hora de evaluar las propiedades de un producto software determinado.

La calidad del producto, junto con la calidad del proceso, es uno de los aspectos más
importantes actualmente en el desarrollo de Software, nos hemos basados en las normas ISO/IEC
25000, que constituye una serie de normas cuyo objetivo principal es guiar el desarrollo de los
productos de software mediante la especificación de requisitos y evaluación de características de
calidad además proporciona una guía para el uso de la nueva serie de estándares internacionales
llamada Requisitos y Evaluación de Calidad de Productos de Software.

La calidad del producto software se puede interpretar como el grado en que dicho producto
satisface los requisitos de sus usuarios aportando de esta manera un valor. Son precisamente estos
requisitos (funcionalidad, rendimiento, seguridad, mantenibilidad, entre otros.) los que se encuentran
representados en el modelo de calidad, el cual categoriza la calidad del producto en características y
subcaracterísticas.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 45


eventos científicos.
INNOVACIÓN

Por medio del desarrollo de esta herramienta se le ofrece a la Organización Académica un medio que
les sirve para manejar de manera eficiente y óptima el control de los Eventos Científicos, sin consumir
muchos recursos, sino por un Programa General de Actividades, evitando el papeleo para los soportes
de cada evento haciendo que el proceso pase de ser manual a digital.

ANÁLISIS DE LA INFORMACIÓN

El análisis de información tenemos como enfoque determinar qué datos tenemos recolectados
para ser evaluados, dicha información será revisada tomando en cuenta los atributos de calidad ya
determinados, en este caso están basados en el modelo ISO 25000, los cuales son los siguientes:

 Adecuación Funcional
 Eficiencia de Desempeño
 Compatibilidad
 Usabilidad
 Fiabilidad
 Seguridad
 Mantenibilidad
 Portabilidad

Es necesaria realizar una revisión directa de todos los requerimientos, si existe alguno que no
se cumpla se debe realizar la documentación para poder notificarlo al departamento correspondiente.
Es importante que además de cumplir cada requerimiento solicitado por el usuario, los atributos ya
expuestos se cumplan para que el producto final se finalice bajo los estándares del software.

Si existe un caso en el que los integrantes del departamento encuentren algún error que no
pertenezca al atributo asignado es importante que de igual manera se documente y sea notificado.

Se desea realizar una evaluación de cada una de estos atributos, basándose en pruebas y análisis del
funcionamiento y estructura del software, obteniendo como resultado la eficiencia bajo un estándar y
el cumplimiento en general de los requerimientos del usuario.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 46


eventos científicos.
CALIDAD A EVALUAR

Adecuación Funcional

Representa la capacidad del producto software para proporcionar funciones que satisfacen las
necesidades declaradas e implícitas, cuando el producto se usa en las condiciones especificadas. Esta
característica se subdivide a su vez en las siguientes subcaracterísticas:

 Completitud Funcional. Grado en el cual el conjunto de funcionalidades cubre todas las tareas
y los objetivos del usuario especificados.
 Corrección Funcional. Capacidad del producto o sistema para proveer resultados correctos
con el nivel de precisión requerido.
 Pertinencia Funcional. Capacidad del producto software para proporcionar un conjunto
apropiado de funciones para tareas y objetivos de usuario especificados.

La adecuación funcional básicamente son las funcionalidades que debe cumplir el software, debe ser
adecuado, correcto y completo para su uso. El software funcionalmente debe ser analizado bajo los
siguientes puntos:

 Ejecución correcta y fluida sin errores de sistema.


 Funcionalidad correcta en elementos básicos: botones, textfields, barras de menú, links de
enlace, combobox y cualquier otra funcionalidad básica que se logre adaptar.
 Funcionalidad de elementos complejos: mapas, chats, sección de búsqueda, cualquier otra
funcionalidad compleja.
 Funcionalidad de elementos externos: manejo de archivos (subir, descargar, compartir) si es el
caso de los requerimientos.
 Validar que el software esté soportado para un tratamiento inadecuado.
 Verificar que las funciones del software abarquen todos los requerimientos del usuario.
 Asegurarse de que las necesidades del usuario estén satisfechas correctamente.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 47


eventos científicos.
EFICIENCIA DE DESEMPEÑO

Esta característica representa el desempeño relativo a la cantidad de recursos utilizados bajo


determinadas condiciones. Esta característica se subdivide a su vez en las siguientes
subcaracterísticas:

 Comportamiento Temporal. Los tiempos de respuesta y procesamiento y los ratios de


throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones determinadas en
relación con un banco de pruebas (benchmark) establecido.
 Utilización de Recursos. Las cantidades y tipos de recursos utilizados cuando el software lleva
a cabo su función bajo condiciones determinadas.
 Capacidad. Grado en que los límites máximos de un parámetro de un producto o sistema
software cumplen con los requisitos.

La eficiencia conlleva poner a prueba el más alto desempeño que puede tener el software para
realizar sus diversas tareas y funcionalidades. En esta característica se debe analizar lo siguiente:

 Identificar el entorno físico (hardware, software y configuraciones de red) donde se realizarán


las pruebas para su producción, así como las herramientas y recursos de que dispone el equipo
de prueba.
 Verificar el tiempo de respuesta del envío y recepción de mensajes.
 Verificar que el rendimiento sea adecuado en cuanto a los objetivos funcionales básicos de la
aplicación.
 Verificar el tiempo de respuesta de la búsqueda.

COMPATIBILIDAD

Capacidad de dos o más sistemas o componentes para intercambiar información y/o llevar a
cabo sus funciones requeridas cuando comparten el mismo entorno hardware o software. Esta
característica se subdivide a su vez en las siguientes subcaracterísticas:

 Coexistencia. Capacidad del producto para coexistir con otro software independiente, en un
entorno común, compartiendo recursos comunes sin detrimento.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 48


eventos científicos.
 Interoperabilidad. Capacidad de dos o más sistemas o componentes para intercambiar
información y utilizar la información intercambiada.

Las pruebas de compatibilidad son elementales para mostrar una calidad adecuada en el
software, verificando que sea capaz de funcionar en diferentes plataformas. Un usuario puede mirar
en su dispositivo móvil, después abrirla en su laptop y volver a visitarla más tarde en su Tablet, lo que
conlleva a evaluar:

 ¿El pase de información y sincronía entre sistemas bajo un mismo entorno es efectivo?
 Capacidad en que se desempeña la aplicación bajo los diferentes exploradores (Internet
Explorer, Mozilla Firefox, Chrome, Safari, Opera...).
 Verificar la comunicación de datos entre sistemas en diferentes sitios.

USABILIDAD

Capacidad del producto software para ser entendido, aprendido, usado y resultar atractivo para
el usuario, cuando se usa bajo determinadas condiciones. Esta característica se subdivide a su vez en
las siguientes subcaracterísticas:

 Capacidad para Reconocer su Adecuación. Capacidad del producto que permite al usuario
entender si el software es adecuado para sus necesidades.
 Capacidad de Aprendizaje. Capacidad del producto que permite al usuario aprender su
aplicación.
 Capacidad para ser Usado. Capacidad del producto que permite al usuario operarlo y
controlarlo con facilidad.
 Protección Contra Errores de Usuario. Capacidad del sistema para proteger a los usuarios de
hacer errores.
 Estética de la Interfaz de Usuario. Capacidad de la interfaz de usuario de agradar y
satisfacer la interacción con el usuario.
 Accesibilidad. Capacidad del producto que permite que sea utilizado por usuarios con
determinadas características y discapacidades.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 49


eventos científicos.
Si bien la usabilidad radica en la facilidad de compresión, acceso e interacción que puedan
tener los usuarios con respecto a la interfaz en general, cabe destacar los siguientes aspectos para su
respectiva prueba:

 ¿La interfaz está acorde para usuarios que puedan explotarla adecuadamente?
 ¿Qué tan buena es la distribución de la información mostrada en las diferentes vistas de la
aplicación?
 Se considera que el contenido está adaptado para todo tipo de resolución

FIABILIDAD

Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se


usa bajo unas condiciones y periodo de tiempo determinados. Esta característica se subdivide a su vez
en las siguientes subcaracterísticas:

 Madurez. Capacidad del sistema para satisfacer las necesidades de fiabilidad en condiciones
normales.
 Disponibilidad. Capacidad del sistema o componente de estar operativo y accesible para su uso
cuando se requiere.
 Tolerancia a Fallos. Capacidad del sistema o componente para operar según lo previsto en
presencia de fallos hardware o software.
 Capacidad de Recuperación. Capacidad del producto software para recuperar los datos
directamente afectados y restablecer el estado deseado del sistema en caso de interrupción o
fallo.

La fiabilidad como un factor de confianza dentro del software ayuda a que el usuario se sienta a
gusto, con la seguridad de que el sistema es robusto y tiene la capacidad de salvaguardar los procesos
que allí se ejecuten. Los indicadores básicos son:

 ¿El programa tiene soporte por si presenta alguna falla? (mensajes de error).
 ¿Todos los enlaces están debidamente conectados a su página específica? suele suceder que
algunos enlaces queden huérfanos y sin dirección.
 ¿Los diferentes módulos aseguran su buen funcionamiento?

Manual del Sistema: Sistema de Organización y gestión académica destinado a 50


eventos científicos.
SEGURIDAD

Capacidad de protección de la información y los datos de manera que personas o sistemas no


autorizados no puedan leerlos o modificarlos. Esta característica se subdivide a su vez en las
siguientes subcaracterísticas:

 Confidencialidad. Capacidad de protección contra el acceso de datos e información no


autorizados, ya sea accidental o deliberadamente.
 Integridad. Capacidad del sistema o componente para prevenir accesos o modificaciones no
autorizados a datos o programas de ordenador.
 No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar, de manera
que dichas acciones o eventos no puedan ser repudiados posteriormente.
 Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una entidad.
 Autenticidad. Capacidad de demostrar la identidad de un sujeto o un recurso.

El software debe ser construido con base a la estabilidad en la seguridad, así como el desarrollo
interno los desarrolladores deben cerciorarse de la seguridad como un aspecto necesario de la calidad
en general. Este atributo es uno de los más importantes para asegurar que los clientes se sientan a
gusto, ya que será un factor confiable. Los aspectos se especifican de la siguiente manera:

 ¿Los usuarios acceden de forma correcta al sistema?


 ¿El registro de usuarios nuevos mantiene seguro los datos como teléfono, dirección, entre otros,
de manera que otros usuarios no puedan tener acceso a estos?
 ¿Qué tan protegidos están los datos de los usuarios? realizar pruebas pertinentes.
 Capacidad del software ante posibles amenazas que puedan producir vulnerabilidad el sistema

Manual del Sistema: Sistema de Organización y gestión académica destinado a 51


eventos científicos.
MANTENIBILIDAD

Esta característica representa la capacidad del producto software para ser modificado efectiva y
eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta característica se
subdivide a su vez en las siguientes subcaracterísticas:

 Modularidad. Capacidad de un sistema o programa de ordenador (compuesto de componentes


discretos) que permite que un cambio en un componente tenga un impacto mínimo en los
demás.
 Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un sistema
software o en la construcción de otros activos.
 Analizabilidad. Facilidad con la que se puede evaluar el impacto de un determinado cambio
sobre el resto del software, diagnosticar las deficiencias o causas de fallos en el software, o
identificar las partes a modificar.
 Capacidad para ser Modificado. Capacidad del producto que permite que sea modificado de
forma efectiva y eficiente sin introducir defectos o degradar el desempeño.
 Capacidad para ser Probado. Facilidad con la que se pueden establecer criterios de prueba para
un sistema o componente y con la que se pueden llevar a cabo las pruebas para determinar si se
cumplen dichos criterios.

El mantenimiento forma parte de la vida del software, sometiéndolo a una serie de pruebas, que
permitan esclarecer, identificar y mejorar aquellos requerimientos necesarios. El software debe tener
un alto rendimiento y continuar operando al mismo nivel o superior en el transcurso del tiempo.
Algunos aspectos importantes a tomar en cuenta son:
 Asegurarse de que el cambio de programas o funcionalidades de la aplicación no repercuta en
las demás funcionalidades.
 ¿Que probabilidad hay de que el sistema se deteriore en el transcurso del tiempo?
 ¿Se utiliza la reusabilidad de componentes o bloques programables entre las diferentes
plataformas?
 ¿La aplicación está definida modularmente?
 ¿El código cumple con una estructura identada? (tabulaciones, espacios, entre otros).

PORTABILIDA

Manual del Sistema: Sistema de Organización y gestión académica destinado a 52


eventos científicos.
Capacidad del producto o componente de ser transferido de forma efectiva y eficiente
de un entorno hardware, software, operacional o de utilización a otro. Esta característica se
subdivide a su vez en las siguientes subcaracterísticas:

 Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma efectiva y
eficiente a diferentes entornos determinados de hardware, software, operacionales o de uso.
 Capacidad para ser Instalado. Facilidad con la que el producto se puede instalar y/o
desinstalar de forma exitosa en un determinado entorno.
 Capacidad para ser Reemplazado. Capacidad del producto para ser utilizado en lugar de otro
producto software determinado con el mismo propósito y en el mismo entorno.

La portabilidad nos aporta un alto índice para percibir usuarios, ya que hace énfasis en la
facilidad de instalación y la transferencia de los sistemas a otros dispositivos con diferente hardware y
software. Los usuarios necesitan que la aplicación sea ligera, sencilla de instalar, descargar y probar,
por ende, debe cumplir con los siguientes aspectos:

● La variedad de versiones que poseen y manejan los usuarios hoy en día son muchas. ¿La
aplicación está en capacidad de ser instalada en varias versiones?
● ¿El sistema se adapta fácilmente a los diversos hardware que hoy en día son utilizados?
● ¿La aplicación posee la capacidad de reemplazo con respecto a otras aplicaciones de la
misma naturaleza?

Manual del Sistema: Sistema de Organización y gestión académica destinado a 53


eventos científicos.
CAPITULO 8.
PLAN DE PRUEBAS
SISTEMA DE ORGANIZACIÓN Y
GESTIÓN ACADÉMICA DESTINADO
A EVENTOS CIENTÍFICOS

Manual del Sistema: Sistema de Organización y gestión académica destinado a 54


eventos científicos.
1. INTRODUCCIÓN

El plan de pruebas se elabora con el fin de especificar qué elementos o componentes se


van a probar para que el grupo de trabajo pueda realizar el proceso de Validación y
Verificación de los requerimientos funcionales y no funcionales del sistema de organización y
gestión académica destinado a eventos científicos. Al desarrollar el plan de pruebas, se puede
obtener información sobre los errores, defectos o fallas que tiene el prototipo, así se realizan
las correcciones pertinentes, según el caso y se asegura la calidad del producto que se está
entregando al cliente.

1.1. OBJETIVO GENERAL

Establecer las condiciones y la cronología para realizar las distintas pruebas con el fin
de obtener un sistema que pueda ser bien recibido por los interesados y que pueda estar en
total funcionamiento de cada uno de sus requerimientos.

1.2. ESTRATEGIA DE PRUEBAS

Las pruebas para el sistema de organización y gestión académica destinado a eventos


científicos, buscan verificar que la totalidad de los Casos de Uso planteados para el sistema y
los requerimientos vinculados a estos se cumplan de manera satisfactoria, para cumplir este
objetivo se planteó el desarrollo de las siguientes pruebas funcionales del sistema: Pruebas
Unitarias, pruebas de compatibilidad y pruebas de aceptación.

1.3. ALCANCE

Corresponde a presentar y delimitar la totalidad del trabajo que es necesitado para dar
por terminado nuestro plan de pruebas.

1.4. PROPOSITO

Entregar una aplicación totalmente funcional de acuerdo a los requisitos del cliente.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 55


eventos científicos.
2. ENTREGABLES

2.1. DOCUMENTACIÓN A ENTREGAR


En esta sección se listaran todos los documentos que se entregaran como parte de la
ejecución del plan, especificando el nombre del documento, la persona quien entrega, la
persona quien recibe, así como la fecha planeada y la fecha que fue la entrega para cada uno
de los entregables. Para esta sección se recomienda el uso de una tabla cuyo formato del tipo
de letra, color de la tabla sean entendibles para que los involucrados en el Plan, puedan
identificar rápidamente las características de los entregables. Algunos de los documentos que
debes de considerar entregar son: Casos de pruebas, Especificación del diseño de casos,
Reporte de errores (defectos), Evidencias de las pruebas, Reportes emitidos por alguna
herramienta de administración de las pruebas y cualquier otro documento de carácter
importante que sea considerado para su entrega.

DOCUMENTO PERSONA QUIEN PERSONA QUIEN FECHA FECHA DE


ENTREGA RECIBE PLANEADA ENTREGA

Pruebas No sé si dejar estas No sé si dejar No sé si dejar No sé si dejar


columnas (No sé si estas columnas estas columnas estas
Unitarias escribir mi nombre o columnas
documentación y QA)

Pruebas de
compatibilidad
Pruebas de
aceptación
Tabla 1: Documentación a entregar.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 56


eventos científicos.
3. CARACTERISTICAS A SER PROBADAS

En esta sección se listaran todas las características que serán probadas, para ello es
importante que se realice juntas con interesados del proyecto, los cuales nos permitirán
determinar qué características se van a probar en este plan. Algunas características que se
pueden hablar en esta sección son: características de funcionalidad, sea interfaz gráfica,
seguridad, etc. Es importante definirlas de manera clara y concisa para no tener malas
interpretaciones de dichas características.

NO SON LAS CARACTERISTICAS A SER PROBADAS, SON LAS DE CALIDAD.


LAS TOME A MODO DE EJEMPLO.

CARACTERISTICA DESCRIPCIÓN MODULO

ADECUACION FUNCIONAL Capacidad de dos o más sistemas o


componentes para intercambiar
información y/o llevar a cabo sus
funciones requeridas cuando comparten
el mismo entorno hardware o software

COMPATIBILIDAD Capacidad de un sistema o componente


para desempeñar las funciones
especificadas, cuando se usa bajo unas
condiciones y periodo de tiempo
determinados.

SEGURIDAD Capacidad de protección de la


información y los datos de manera que
personas o sistemas no autorizados no
puedan leerlos o modificarlos.

Tabla 2: Características a ser probadas.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 57


eventos científicos.
4. CARACTERISTICAS A NO SER PROBADAS

En esta sección se listaran todas las características que no serán probadas, estas
características se determinan a través de juntas y de los requerimientos del proyecto, es
importante que se justifique el por qué no serán probadas las características y el riesgo que
estas pueden ocasionar al no ser probadas, con el propósito de informar a los involucrados y
estén completamente de acuerdo. Algunas características que se pueden hablar en esta
sección son: características de interfaz gráfica, seguridad, etc. Es importante definirlas de
manera clara y concisa para no tener malas interpretaciones y si ocurre algún evento que
afecte al proyecto no comenzar a repartir culpas entre los equipos.

NO SON LAS CARACTERISTICAS A NO SER PROBADAS. LAS TOME A MODO


DE EJEMPLO.

CARACTERISTICA DESCRIPCIÓN JUSTIFICACIÓN RIESGO

INTERFAZ Interfaz grafica


GRAFICA

Tabla 3: Características a no ser probadas.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 58


eventos científicos.
5. CRITERIOS DE APROBACIÓN Y FALLO

Son los criterios que serán considerados para dar por completado el Plan de Pruebas, por
ejemplo: Porcentaje de la cobertura de las pruebas esperado, cierto porcentaje de casos
exitosos, cobertura de todos los componentes, porcentaje de defectos corregidos, todo error
debe de ir acompañado de un mensaje de validación, entre otros. Cuando un criterio de
aprobación fue rechazado se toma acción para el criterio utilizando el criterio de fallo para
dicho criterio. Todo criterio de aprobación lo debe de acompañar un criterio de fallo, el cual
es la acción que se tomara en la implementación del plan, cuando se ejecuten las pruebas
sobre el proyecto.

ID CRITERIO DESCRIPCIÓN APROBACIÓN FALLO

Tabla 4: Criterios de aprobación y fallo.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 59


eventos científicos.
6. CRITERIOS DE SUSPENSIÓN Y REANUDACIÓN

En esta sección se establecen los criterios de suspensión los cuales establece claramente
bajo qué condiciones se detienen un conjunto de casos de pruebas, por ejemplo en caso de
existir defectos que impidan la ejecución de más casos de pruebas, cierto porcentaje de casos
fallidos, o cualquier otro que se especifique. Los criterios de reanudación establece bajo qué
criterios se reanudaran las pruebas, por ejemplo: cuando nos entreguen una nueva versión de
pruebas, cuando nos realicen las configuraciones necesarias, etc. Es importante considerar
que para cada criterio de suspensión debe contar su criterio de reanudación.

CRITERIO DE SUSPENSIÓN CRITERIO DE REANUDACIÓN

Tabla 5: Criterios de suspensión y reanudación.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 60


eventos científicos.
7. TAREAS DE LAS PRUEBAS

En este apartado se describirán las tareas y cuando se van a ejecutar, el propósito es


mantener una buena administración de las tareas integradas en este plan. Se recomienda
establecer el nombre de la tarea, su descripción corta y precisa, fecha de inicio, fecha de fin,
su duración, el responsable de cada tarea y el rol que la desempeñara. Para determinar la
duración de las tareas es importe desarrollar un WBS (Estructura de Descomposición del
Trabajo) en el cual se describen y se asignan las tareas de manera desglosada para obtener
dicha duración, o también podemos pedir la opinión de los expertos para determinarla de
manera más real.

TAREA DESCRIPCIÓN FECHA FECHA DURACIÓN RESPONSABLE ROL


INICIO FIN (HRS)

Tabla 6: Tareas de las pruebas.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 61


eventos científicos.
8. NECESIDADES AMBIENTALES

8.1. HARDWARE

En este apartado se especifican los equipos tecnológicos que son requeridos para
poder llevar a cabo nuestras pruebas de software en el proyecto, las necesidades del hardware
comienzan desde el análisis de requerimientos, diseños de pruebas, administración de
pruebas, ejecución de pruebas y algún otro dispositivo necesario que es parte fundamental del
proyecto, como pueden ser, impresoras, terminales bancarias, teléfonos, que son algunos
ejemplos.

Debes de considerar que los equipos y/o dispositivos con los que no se cuentan, que
tan requeridos son, para ello te debes de contestar las siguientes preguntas: ¿Es requerido el
equipo y/o dispositivo?, ¿Urge la adquisición del equipo y/o dispositivo que es requerido?,
con el objetivo de justificar porque es necesario la adquisición del equipo y/o dispositivo, de
esta manera los involucrados en el proyecto podrán determinar que parte realiza la
adquisición del hardware.

DISPOSITIVO MARCA CARACTERISTICAS ¿TENEMOS EL


EQUIPO?

LAPTOP MACBOOK APPLE SO: IOS, 8Gb RAM, etc. Si


PRO

Tabla 7: Necesidades ambientales de hardware.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 62


eventos científicos.
8.2. SUT (SISTEMA BAJO PRUEBAS)

El sistema bajo pruebas por sus siglas en inglés SUT (System Under Test), se refiere
al sistema o modulo del sistema que está siendo probado para su funcionamiento correcto. Es
importante considerar la distribución de los módulos en los cuales el proyecto se organizó y
la integración de los mismos. El propósito de esta sección es tener bien claro cuáles son los
módulos a probar, los requerimientos del proyecto por módulo y los casos de prueba para
cada módulo.

MODULO ¿DEPENDENCIA ENTRE REQUERIMIENTOS


MODULOS?

Tabla 8: Sistema bajo pruebas.

8.3. TEST-WARE.

En esta sección se especifican los artefactos que son requeridos para la ejecución del
proceso de pruebas, se debe de considerar la configuración del ambiente de pruebas, los
privilegios de los diferentes usuarios que van a interactuar con el sistema, los accesos a bases
de datos, guías de pruebas, casos de prueba y la documentación especifica del proyecto.

ADMINITRACION USUARIOS ACCESOS GUIAS DE CASOS DOCUMENTACION


DE LA A BD PRUEBAS DE ESPECIFICA DEL
CONFIGURACIÓN PRUEBAS PROYECTO

Tabla 9: Test-ware.

Manual del Sistema: Sistema de Organización y gestión académica destinado a 63


eventos científicos.
8.4 PRUEBAS DE COMPATIBILIDAD

Teniendo en cuenta la naturaleza del sistema, es decir una plataforma cliente servidor, se
ejecutarán los casos de uso descritos para la aplicación en cuatro (o tres) navegadores
diferentes, verificando de esta manera que el desarrollo del sistema funcione de manera
correcta en diferentes plataformas y dispositivos. Este tipo de pruebas permitirá verificar
todos los módulos del sistema y garantizar su estabilidad y funcionamiento en diferentes
navegadores web.

Para lograr la verificación de las pruebas de compatibilidad, se ejecutará cada uno de los
Casos de Uso del Sistema de Organización y Gestión Académica Destinado a Eventos
Científicos, siguiendo el flujo normal del Caso de Uso. Para cada caso de uso se realizó el
proceso completo en cuatro navegadores distintos, las especificaciones se encuentran a
continuación:

Ambiente 1 Ambiente 2 Ambiente 3 Ambiente 4


Tamaño de 1920 x 1080 1024 x 600 1920 x 1080 800 x 600
pantalla
Navegador Firefox Firefox Chrome Chrome
Sistema Operativo Linux Ubuntu Windows 7 Windows 7 Windows 7

Tabla Características de los ambientes de pruebas de compatibilidad

Para realizar las pruebas se procedió a evaluar cada Caso de Uso dando una
calificación de 1 a 10, donde 10 es el valor más alto, luego se procedió a promediar las
puntuaciones y para los CU que obtuvieran un puntaje superior a 8 se consideraba aprobada
la prueba, los resultados de las pruebas se encuentran disponibles a continuación:

Manual del Sistema: Sistema de Organización y gestión académica destinado a 64


eventos científicos.
NOTA: Hay 3 ambientes porque el Chrome del pc funciona igual para cada tamaño de
pantalla en estas pruebas.
Navegadores utilizados
Mozilla Google Mozilla
CU Descripción Total
Firefox Chrome Firefox
Linux Windows Windows
CU-01 Ingresar al sistema (GESTIONAR 10 10 10 10,0
EVENTO (SOLO CREAR) Y
VISUALIZAR)
UC-02 Organizador de eventos científicos 10 10 10 10,0
(SOLO INGRESAR AL SISTEMA Y
VISUALIZAR EVENTOS)
CU-03 Gestionar Evento (SOLO AGREGAR 10 10 10 10,0
EVENTO Y GESTIONAR ACTIVIDAD
(REGISTRAR ACTIVIDAD))

Tabla Resultados de pruebas de compatibilidad

Manual del Sistema: Sistema de Organización y gestión académica destinado a 65


eventos científicos.
8.5 PRUEBAS DE COMPATIBILIDAD

Id REQ Descripción del requerimiento


REQ-08 Los árbitros de cada ponencia son asignados por la comisión organizadora y se
envía un correo al árbitro al realizar la asignación.
Componente que lo incluye: Nombre del componente donde se desarrolla el requerimiento
(NO SE SI EL PROYECTO ESTA DIVIDIDO EN MODULOS)
Responsable de la prueba: Angel Navas
Prueba desarrollada
Ingresar al sistema como administrador (por ahora), seleccionar el evento, seleccionar una
ponencia y asignar uno o varios árbitros.
Resultado esperado El sistema debe asignar uno o varios árbitros a una ponencia

Resultado obtenido El sistema asigna uno o varios árbitros a la ponencia


Estado del requerimiento: Probado y Aprobado
Tabla Resultado Prueba unitaria 1

Id REQ Descripción del requerimiento


REQ-04 Un foro requiere un lugar adecuado y ser asignado en la planificación por la
comisión organizadora.
Componente que lo incluye: Nombre del componente donde se desarrolla el requerimiento
(NO SE SI EL PROYECTO ESTA DIVIDIDO EN MODULOS)
Responsable de la prueba: Angel Navas
Prueba desarrollada
Ingresar al sistema como administrador (por ahora), seleccionar el evento, seleccionar un foro y
seleccionar el lugar adecuado para dictar un foro
Resultado esperado El sistema debe permitir elegir un lugar adecuado para llevar a
cabo un foro.
Resultado obtenido El sistema permite elegir entre la sala de usos múltiples y la
biblioteca, lugares aptos para un foro
Estado del requerimiento: Probado y Aprobado
Tabla Resultados de prueba unitaria 2

Manual del Sistema: Sistema de Organización y gestión académica destinado a 66


eventos científicos.