Srs y Pruebas del Sistema del ateneo

Sistema de información como herramienta para la gestión administrativa del ateneo de la victoria del municipio José Félix Ribas Edo-Aragua.

Especificación de requisitos de software

Rev. 01Pág. 1

Especificación de requisitos de software

Proyecto: Sistema de información como herramienta

para la gestión administrativa del ateneo de la victoria

del municipio José Félix Ribas Edo-Aragua.

Revisión 1.0

Sistema de información como herramienta para la gestión administrativa del ateneo de la victoria del

municipio José Félix Ribas Edo-Aragua. Especificación de requisitos de software

Rev. 01Pág. 2

Ficha del documento

Fecha Revisión Autor Verificado Ing. software.30/03/2012 01

TSU. Jhonfer CastilloCI: 21269762

TSU. Yusmely MejíasCI: 20.068.665

TSU. Felix Perez CI: 19.471.756

Documento validado por las partes en fecha: [Fecha]

Marzo de 2012.



Rev. 01Pág. 3

Por la comunidad Por la institución

Benjamín Caballero Jhonfer Castillo

Representante de la comunidad Líder del proyecto



Rev. 01Pág. 4

CONTENIDO

FICHA DEL DOCUMENTO 2

CONTENIDO 3

1 INTRODUCCIÓN 4

1.1 Propósito 41.2 Alcance 41.3 Personal involucrado 51.4 Definiciones, acrónimos y abreviaturas 51.5 Referencias 71.6 Resumen 82 DESCRIPCIÓN GENERAL 8

2.1 Perspectiva del producto 82.2 Funcionalidad del producto 82.3 Características de los usuarios 82.4 Restricciones 82.5 Suposiciones y dependencias 82.6 Evolución previsible del sistema 83 REQUISITOS ESPECÍFICOS 8

3.1 Requisitos comunes de las interfaces 83.1.1 Interfaces de usuario 83.1.2 Interfaces de hardware 83.1.3 Interfaces de software 83.1.4 Interfaces de comunicación 8

3.2 Requisitos funcionales 8Requisito funcional 1 15Requisito funcional 2 15Requisito funcional 3 15Requisito funcional n… 15

3.3 Requisitos no funcionales 83.3.1 Requisitos de rendimiento 83.3.2 Seguridad 83.3.3 Fiabilidad 83.3.4 Disponibilidad 83.3.5 Mantenibilidad 83.3.6 Portabilidad 8

3.4 Otros requisitos 84 APÉNDICES 8

Sistema de información como herramienta para la gestión administrativa del ateneo de la victoria del municipio José

Félix Ribas Edo-Aragua. Especificación de requisitos de software

Rev. 01Pág. 5

1 Introducción

El presente SRS describe el modelo general y especificaciones de requisitos según el

estándar de IEEE 830-1998 que deberá seguir la aplicación a desarrollar.

1.1 Propósito

El presente documento tiene como finalidad definir las especificaciones de los

requisitos funcionales y no funcionales del sistema de información que busca actuar como

herramienta para la gestión administrativa del Ateneo de La Victoria utilizada por

estudiantes, profesores en materia artística, directivos de la organización y público en

general.

1.2 Alcance

Las especificaciones de requerimiento del sistema de gestión administrativa del

Ateneo de La Victoria, la cual será una aplicación que se ejecutará y funcionará bajo un

ambiente web que permitirá administrar por módulos el registro de usuarios que visiten el

sitio, estudiantes que realicen inscripciones, bienes que ingresen y egresen, cursos que

imparten y horarios de la organización. Procesos de administración y asignación de

estudiantes al curso establecido.

Impresión de los diferentes reportes que sean solicitados referentes a los registros y

procesos. Se accederá al sistema dependiendo del nivel de usuario para ofrecer seguridad de

uso, los cuales son: administrador el cual cumple y tiene privilegio a todas las acciones del

sistema especial la de gestionar usuarios, supervisor encargado de administrar

publicaciones añadidas por usuarios, trasmitir información referente a actividades del

ateneo, estudiante el cual podrá hacer publicaciones, comentarios, registrarse en cursos e

imprimir reportes. El sistema permanecerá en un servidor externo donde la interacción sea

de manera cliente – servidor.

Realizado por: Jhonfer Castillo – Yusmely Mejías – Félix Pérez.



Rev. 01Pág. 6

1.3 Personal involucrado

Nombre Jhonfer CastilloRol Líder Categoría profesional TSU en informáticaResponsabilidades Coordinación del proyecto, descripción general del

SRS. Requisitos comunes de la interfaz.Información de contacto

0426-930-2595

Nombre Yusmely Mejías RolCategoría profesional TSU en informáticaResponsabilidades Documentar el proyecto, Requisitos comunes de la

interfaz, Requisitos funcionales.Información de contacto

0416-447-1571

Nombre Félix Pérez RolCategoría profesional TSU en informáticaResponsabilidades Documentar el proyecto, Requisitos no funcionales,

otros requisitos.Información de contacto

0416-045-4230

1.4 Definiciones, acrónimos y abreviaturas

Administrar: Acción de agregar, modificar, eliminar y consultar la información de

un determinado objeto o individuo.

Aplicación: Es un tipo de programa informático diseñado como herramienta para

permitir a un usuario realizar uno o diversos tipos de trabajo.

Aplicación web: En general, el término se utiliza para designar aquellos programas

informáticos que son ejecutados en el entorno del navegador (por ejemplo Internet

Explorer ) o codificado con algún lenguaje soportado por el navegador (como




Rev. 01Pág. 7

JavaScript, combinado con HTML); confiándose en el navegador web para que

reproduzca la aplicación.

Bienes: Son aquellos que se adquieren en el mercado pagando por ello un precio, es

decir, bienes materiales e inmateriales que poseen valor económico y por ende

susceptible de ser valuados en términos monetarios.

Gestión: hace referencia a la acción y a la consecuencia de administrar o gestionar

algo.

HTML: (HyperText Markup Language) Es un lenguaje de marcación diseñado para

estructurar textos y presentarlos en forma de hipertexto, que es el formato estándar de

las páginas web.

JavaScript: Es un lenguaje interpretado, es decir, que no requiere compilación,

utilizado principalmente en páginas web.

Módulo: Es una porción de un programa de computadora. De las varias tareas que

debe realizar un programa para cumplir con su función u objetivos, un módulo

realizará, comúnmente, una de dichas tareas (o varias, en algún caso).

Nivel de usuario: En sentido general, un usuario es un conjunto de permisos y

de recursos (o dispositivos) a los cuales se tiene acceso a un programa o aplicación.

Es decir, un usuario puede ser tanto una persona como una máquina, un programa,

etc. El nivel depende de las restricciones que se le apliquen a dicho usuario

PHP: (Hypertext Pre-processor) Lenguaje de programación interpretado usado para

la creación de aplicaciones para servidores, o creación de contenido dinámico para

sitios web.

Servidor externo o remoto: Es una combinación de hardware y software que

permite el acceso remoto a herramientas o información que residen en una red

de dispositivos. En otras palabras, un servidor remoto es un equipo que permite a




Rev. 01Pág. 8

otros conectarse a éste (puede ser a través de una línea telefónica por módem, por

ejemplo).

Sistema de información: Es un conjunto de elementos orientados al tratamiento y

administración de datos e información, organizados y listos para su uso posterior,

generados para cubrir una necesidad u objetivo.

1.5 Referencias

Referencia Título Ruta Fecha Autor

1Especificaciones de

requisitos de softwarehttp://dspace.espoch.edu.ec/

bitstream/123456789/188/1/

EspecificacionRequerimientosS

oftware.pdf

12/04/2010 Angel Cobo Holger Morales

2Sambayon

Especificaciones de requerimientos de

software (srs).

http://www.google.co.ve/url?sa=t&rct=j&q=ejemplos%20de%20srs&source=web&cd=18&ved=0cfiqfjahoao&url=http%3a%2f%2fsvn2.assembla.com%2fsvn%2ftdp2%2ftags%2fv2.0%2fartefactos%2fcasos%2520de%2520uso%2fsrs.doc&ei=lrf1t_x6gyl-9qty3edgdq&usg=afqjcnhzpn8zr63q7yogqarwrj0ec4z-wg

14/04/2008 Ezequiel González

3Especificació de

requisitos de software Proyecto: SIS-WEB

http://cic.javerianacali.edu.co/wiki/lib/exe/fetch.php?

media=materias:pis:ejemplo_de_especificacion_de_requerimien

tos_-_para_sesion_9.pdf

19/09/07 Tania IsadoraDorance Moreno

Luis Yovany

4 Standard IEEE 830 - 1998

http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/

ieee830.pdf

1998 IEEE




Rev. 01Pág. 9

1.6 Resumen

En el presente documento de especificación de requisitos de software está compuesto

por la definición de las características, definición de los diferentes requisitos funcionales y

no funcionales del software, diferentes interfaces de usuario, modelo de caso de uso y

alcances del Sistema de información que se desarrolla para que funcione como herramienta

para la gestión administrativa del ateneo de la victoria del municipio José Félix Ribas Edo-

Aragua.

2 Descripción general

2.1 Perspectiva del producto

El Sistema de información como herramienta para la gestión administrativa del

ateneo de la victoria del municipio José Félix Ribas Edo-Aragua será un software

desarrollado para funcionar como aplicación WEB lo que permite su uso desde cualquier

lugar con acceso a internet, es un producto independiente y por tal motivo no pose

vinculación con otros sistemas.

2.2 Funcionalidad del producto

El sistema requerido contempla las siguientes funciones:

Se accederá al sistema dependiendo del nivel de usuario los cuales son:

Administrador y usuario, el administrador cumple y tiene acceso a todas las

acciones del sistema.

El sistema debe realizar, Registro de usuarios, inscripción de los cursos,

desarrollar horarios y actualización periódica sobre actividades referentes de

interés, gestión de contenido y publicaciones.

Se podrá hacer consulta de la información, donde el usuario podrá seleccionar

los cursos y talleres dictados en la comunidad del ateneo.

Compartir archivos multimedia e intercambio de conocimientos sobre las artes

y culturas del ateneo de la victoria entre los diferentes usuarios.




Rev. 01Pág. 10

2.3 Características y jerarquía de los usuarios

El sistema contempla 4 tipos de usuarios que interactuaran con el software: como lo

es el administrador, que cumple y tiene privilegio a todas las acciones del sistema en

especial la de gestionar usuarios, supervisor encargado de administrar publicaciones

añadidas por usuarios, trasmitir información referente a actividades del ateneo. El

estudiante podrá hacer publicaciones, comentarios, registrarse en cursos e imprimir

reportes, y el visitante no será necesario haberse registrado y de manera restringida puede

visualizar algunas publicaciones e informaciones.

Tipo de usuario AdministradorFormación Licenciado en EducaciónHabilidades Manejo de computadores y manejo del sistema con una

previa capacitación por parte de los desarrolladores, experiencia y conocimientos de la organización.

Actividades - Supervisar y administrar los diferentes niveles de usuarios.

- Administrar los registros de inscripciones, bienes, cursos, horarios.

- Supervisar publicaciones informativas y de usuarios.- Procesos de asignación de estudiantes a cursos y este

a su vez a horarios.- Gestionar reportes.- Consultar información general.

Tipo de usuario Supervisor Formación TSU en informáticaHabilidades Manejo de computadores y manejo del sistema con una

previa capacitación por parte de los desarrolladores, experiencia y conocimientos de la organización.

Actividades - Supervisar y administrar publicaciones de usuarios.- Reportar errores.- Generar publicaciones informativas.- Consultar información general.- Realizar consultas




Rev. 01Pág. 11

Tipo de usuario EstudiantesFormación Alumnos Habilidades Manejo de equipo de cómputos y conocimientos sobre el

uso del internetActividades - Generar inscripciones.

- Consultar reportes.

- Consultar y visualizar información.

- Imprimir reportes.

- Realizar publicaciones y comentarios de las informaciones.

Tipo de usuario VisitanteFormación Persona de cualquier índole que puedan manipular el

sistema.Habilidades Manejo de equipo de cómputos y conocimientos sobre el

uso del internetActividades - Consultar reportes.

- Consultar y visualizar información restringida.

- Realizar comentarios a publicaciones.

Jerarquía de los diferentes usuarios




Rev. 01Pág. 12

2.4 Restricciones

El sistema será desarrollado en php , flash-actionscript, html, javascript

lenguajes orientados a la creación de aplicaciones en entorno web, el uso de

estos programas se realizara siguiendo las normas y políticas establecidas por

este tipo de licenciamiento, el sistema de gestión de base de datos es MySQL.

Se debe establecer un protocolo de seguridad entre el intercambio de datos

cliente – servidor, permanecerá alojado en un servidor remoto donde se podrá

acceder desde cualquier computador independientemente del sistema

operativo que se utilice.

Se basará en las características establecidas por la metodología orientada a

objetos.

2.5 Suposiciones y dependencias

El sistema se ejecutará bajo cualquier sistema operativo, pero las pruebas

serán ejecutadas sobre el sistema Windows XP.




Rev. 01Pág. 13

2.6 Evolución previsible del sistema

Mejora de la interfaz gráfica con animaciones dinámicas.

Incluir procesos adicionales de administración del ateneo de La Victoria.

Cursos online atreves de video conferencias.

Versión para dispositivos móviles.

3 Requisitos específicos

Diagrama de Caso de uso




Rev. 01Pág. 14

Número de requisito: RF 1Nombre de requisito: Registrar UsuarioTipo: Requisito RestricciónFuente del requisito: BD Tabla: usuarios, Campos: usuario y

códigoPrioridad del requisito: Esencial Deseado OpcionalDescripción: Permite a los usuarios ingresar al sistema

previamente llenado el formulario de registro. El administrador podrá añadir nuevos usuarios (Supervisor, estudiante).

Requerimientos : Dependiendo del nivel de usuario asignado por el administrador (supervisor) tendrán diferentes privilegios.

El usuario visitante, no será registrado y solo acedera a consultas de información y realizar comentarios.

Precondiciones: Para auto-registrarse un supervisor deberá proporcionar un código de supervisor dado previamente por el administrador.

Se deben proporcionar todos los datos del formulario

El usuario administrador posee un registro previo en el sistema.

Flujo NormalActor Sistema

1. El usuario que ingrese por primera vez acedera al sistema atreves de internet, si es visitante no será necesario su registro.

1. Mostrar la selección de niveles de usuario disponibles a elegir (supervisor, estudiante).

2. Validar los datos para ser enviados a la




Rev. 01Pág. 15

2. El usuario rellenara los datos del formulario para registrarse en el sistema.

3. El registro de supervisor deberá ingresar el código proporcionado por el administrador.

4. Una vez registrado con los datos correctos se podrá acceder al sistema dependiendo del nivel de usuario.

base de datos.3. Enviar un mensaje al usuario: Registro

exitoso.

Flujo alternoActor Sistema

1. Si el usuario ingresa un dato erróneo o deja un campo vacio en el formulario.

2. Si el usuario registra a un usuario existente en el sistema.

1. El sistema ejecutara la validación y enviara un mensaje al usuario: ingrese los campos correctamente. Luego mostrara los campos incorrectos.

2. Muestra en pantalla mensaje de: usuario ya existente y mantiene los datos del registro.

Post condiciones: El usuario es guardado en la base de datos, y accede al sistema con procesos diferentes dependiendo del nivel de usuario.

Requerimiento especiales: El registro de nuevo administrador se ejecutara ingresando al sistema con el administrador incluido en el sistema dado al encargado del Ateneo de La Victoria. El tendrá el privilegio de eliminar a usuarios que incumplan con las normativas.

Puntos de extensión:

Número de requisito: RF 2Nombre de requisito: Crear Curso y Taller.Tipo: Requisito RestricciónFuente del requisito: BD Tabla: Curso, taller, Campos: Nombre,

Modalidad, Facilitador, Dirigido, Costo, Horario, Cupos.

Prioridad del requisito: Esencial Deseado OpcionalDescripción: Creación de cursos y talleres que permitirán al

estudiante registrarse. El administrador podrá crear nuevos cursos y talleres.

Requerimientos : Dependiendo del nivel de usuario asignado




Rev. 01Pág. 16

por el administrador (supervisor, Estudiante) tendrán diferentes privilegios.

El usuario visitante, no será registrado y solo acedera a consultas de información y realizar comentarios.

Se podrán registrar nuevos estudiantes eligiendo previamente un curso.

Precondiciones: Se deben proporcionar todos los datos del formulario.

Buscar un facilitador y seleccionarlo dependiendo de su área.

Elegir un tipo de costo. Determinar los límites de cupos.


1. El usuario proporciona los datos principales cómo es el nombre del curso o del taller.

2. El usuario escogerá la modalidad si es gratuito o es auto-gestionado y el facilitador encargado.

3. Se especifica a quien va dirigido el curso o el taller y el costo.

4. Seleccionar el horario y el límite de cupos.

5. Una vez proporcionado todos los datos se guardara el curso o el taller registrado.

1. Mostrar el tipo de modalidad.2. Mostrar el facilitador dependiendo de la

búsqueda que ingreso el usuario.3. Visualizar a quien va dirigido el curso o el

taller.4. Guardar cantidad de cupos ingresado por el

usuario para su posterior uso.5. Validar los datos para ser enviados a la

base de datos.6. Enviar un mensaje al usuario: Registro

exitoso.


1. Si el usuario elegí un facilitador que no esté en la base de datos mostrara un mensaje de error.

2. Si el usuario registra un curso o taller existente en el sistema se mostrara un mensaje de error.

1. El sistema buscara en la base de datos el facilitador, curso o taller ingresado previamente por el usuario y si no lo encuentra se mostrara el mensaje de error.

2. Si los campos están vacios se ejecutara la validación y enviara un mensaje al usuario: ingrese los campos correctamente. Luego mostrara los campos incorrectos.

Post condiciones: El curso o el taller son guardados en la base de datos.

Requerimiento especiales: El administrador es el único usuario que puede crear, modificar y ejecutar el curso o el taller.




Rev. 01Pág. 17


Número de requisito: RF 3Nombre de requisito: Administrar Perfil.Tipo: Requisito RestricciónFuente del requisito: BD Tabla: Perfil. Campos: Imagen, Nombre,

Redes, Dirección, Estudios, Pagina, Nota. Prioridad del requisito: Esencial Deseado OpcionalDescripción: Cada usuario luego de acceder al sistema

tiene la opción de administrar su perfil que mostrara públicamente información relevante sobre sí mismo.

Requerimientos : Cualquier usuario a excepción de los Visitantes puede acceder a este modulo del sistema.

Es necesario estar registrado e ingresar al sistema.

Se deberá confirmar cada cambio al modificar el perfil.

Precondiciones: Es opcional proporcionar todos los datos del formulario.

Cada usuario registrado podrá actualizar su perfil en el momento que desee.

Los usuarios visitantes no pueden visualizar los perfiles de ningún usuario.


1. Todos los usuarios previamente registrada su cuenta deben iniciar sección en su respectiva cuenta.

2. Sea Administrados, Supervisor o Estudiante si desean pueden rellenar o actualizar su perfil.

3. Si es un usuario nuevo debe completar cada uno de los campos o más del 50% iniciando por la imagen principal.

4. Ingresar datos principales: nombre, redes, dirección, estudios, página, nota.

5. Confirmar y guardar cada cambio.

1. Mostrar a usuarios nuevos la opción de administrar el perfil.

2. Solicitar al usuario cargar la imagen principal para luego ser validada y guardada en la base de datos.

3. Mostrar al usuario por separado los diferentes partes del registro y validar si se ha completado el 50% de todos los campos.

4. Guardar el registro si es usuario nuevo o de lo contrario actualizarlo.

5. Validar los datos para ser enviados a la base de datos.

6. Enviar un mensaje al usuario de confirmación de datos y registro terminado.




Rev. 01Pág. 18


1. Si el usuario no modifica su perfil por primera vez se mostrar un mensaje donde se le sugiere ingresar los datos principales.

2. Se solicitara que cargue una imagen principal en caso de no haberlo hecho.

3. Si se ingresa datos incorrectos en los campos del registro se mostrara un mensaje de error.

1. Si la imagen principal no cumple con el formato básico de carga se mostrara un mensaje de error con la descripción de los requisitos.

2. Se comprueba si se ha no se completa el 50% del registro se sugiere al usuario atreves de un mensaje completar el registro

3. Si los campos están vacios o incorrectos se ejecutara la validación y mostrara los campos incorrectos que deben ser modificados correctamente.

Post condiciones: El perfil es guardado y puede ser visualizado por otros usuarios registrados.

Requerimiento especiales:Puntos de extensión:

Número de requisito: RF 4Nombre de requisito: Bloquear Usuarios.Tipo: Requisito RestricciónFuente del requisito: BD Tabla: Bloqueo. Campos: Usuario,

Descripción, Reporte. Prioridad del requisito: Esencial Deseado OpcionalDescripción: Sera mostrado en pantalla al administrador

opciones de bloqueo y los usuarios (estudiantes) que fueron reportados por los supervisores que incumplieron las normativas o reglas del sistema.

Requerimientos : Es necesario estar registrado e ingresar al sistema.

Solo el administrador puede bloquear usuarios

Se deberá enviar un aviso de advertencia al usuario antes de ser bloqueado.

Precondiciones: Se debe previamente visualizar el reporte de alerta de usuarios generado por el supervisor para proseguir a este modulo.

Se visualizaran los motivos correspondientes al bloqueo y su calificativo.




Rev. 01Pág. 19

El administrador debe proporcionar su clave para confirmar el bloqueo de los usuarios.


1. Iniciar sección como administrador y dirigirse a visualizar el reporte de alerta de usuarios donde muestra el informe detallado de las denuncias y usuarios (estudiantes) notificados.

2. Dirigirse al apartado bloqueo de usuarios para visualizar las opciones donde decidirá enviar una advertencia o proceder al bloqueo.

3. Si se procede a bloquear el usuario se debe enviar una notificación por los motivos

4. Introducir su contraseña de acceso para confirmar.

1. Mostrar en pantalla al administrador estadísticas e información detallada generada por el supervisor sobre reporte de alertas de usuarios.

2. Cargar por separado los datos e información de los usuarios reportados.

3. Solicitar al administrador elegir un tipo de mensaje para ser enviado al usuario a bloquear.

4. Solicitar ingresar la contraseña de acceso para confirmar el bloqueo.


1. Si el supervisor no envía el reporte de alerta de usuarios no se mostrara en pantalla al administrador y este podría solicitarla.

2. Si no se envía un mensaje al usuario (estudiante) no se procederá a su bloqueo.

3. Si se ingresa una contraseña incorrecta a la hora de confirmar el bloqueo se mostrara un mensaje de error.

1. Buscar en la base de datos si existe un reporte guardado por el supervisor si no lo haya muestra un mensaje en pantalla.

2. Se muestra al administrador la opción de solicitar el reporte a él superviso.

3. A la hora de confirmar se solicita la contraseña y se compara con la almacenada en la base de datos si no coinciden no se efectúa el procedimiento de bloqueo,

Post condiciones: Es bloqueado el usuario por un periodo, se le notifica al usuario los motivos y se les muestra las normativas del sistema.


Número de requisito: RF 5Nombre de requisito: Administrar Horario.Tipo: Requisito RestricciónFuente del requisito: BD Tabla: horario. Campos: Curso, Taller,




Rev. 01Pág. 20

Día, Hora, F_Inicio, F_culminacion, Permanente, Lugar, Descripción.

Prioridad del requisito: Esencial Deseado OpcionalDescripción: El administrador luego de haber creado

previamente los cursos puede organizar y seleccionar una hora y día especifico en una tabla donde se mostraran organizadamente, pueden gestionar y visualizar más fácilmente las fechas de cada curso y taller.








1. Todos los usuarios previamente registrada su cuenta deben iniciar sección.












1. Si el usuario no modifica su perfil por primera vez se mostrar un

1. Si la imagen principal no cumple con el formato básico de carga se mostrara un




Rev. 01Pág. 21

mensaje donde se le sugiere ingresar los datos principales.



mensaje de error con la descripción de los requisitos.





Número de requisito: RF 6Nombre de requisito: Alerta de Publicaciones de Usuario.Tipo: Requisito RestricciónFuente del requisito: BD Tabla: alertas. Campos: Usuario,

Publicación, tipo_A, Descripción, calificación, normativa.

Prioridad del requisito: Esencial Deseado OpcionalDescripción: El supervisor recibe mensajes, denuncias de

usuarios y reportes de mal uso del sistema al modulo de alertas de publicaciones de usuario donde se clasifican y se ordenan para que el administrador tome las decisiones respectivas.

Requerimientos : Es necesario estar registrado e ingresar al sistema.

Solo el supervisor puede acceder a este modulo.

Precondiciones: Se deberá confirmar que son correctas las denuncias haciendo uso de las consultas de publicaciones.

Se actualizar periódicamente los reportes. Los usuarios visitantes no pueden realizar

denuncias.Flujo Normal

Actor Sistema1. Todos los usuarios previamente 1. Consultar en base de datos las denuncias




Rev. 01Pág. 22

registrada su cuenta deben iniciar sección.

2. El supervisor visualiza cada uno de los mensajes, denuncias y reportes de mal uso del sistema y los confirma si son correctos en el modulo de consultas de publicaciones de usuarios.

3. Se seleccionan los avisos y se procede a generar ordenadamente los reportes de alertas donde se describe el motivo, se establece una clasificación para ordenarlos por prioridad.

4. Se confirma y se envía el reporte de alerta al administrador.

generadas por los usuarios y luego serán mostradas en pantalla en forma de lista al supervisor.

2. Cargar los datos de usuario y denuncias en alertas de publicaciones de usuario.

3. Los reportes son ordenados por prioridad establecido por el supervisor.

4. Guardar el reporte y se es enviado al administrador.


1. Si no se encuentra ninguna denuncia se envía un mensaje de estado al administrador.

2. Si no se completa todos los campos y se selecciona una calificación para la denuncia no se guardara el reporte.


1. Se muestra un mensaje de estado si no se encuentran alertas y se envía el estado al administrador.

2. Si los campos están vacios o incorrectos se ejecutara la validación y mostrara los campos incorrectos que deben ser modificados correctamente y rellenados obligatoriamente.

Post condiciones: El reporte es enviado al administrador para ser revisado en el modulo de consultas de alertas.


Número de requisito: RF 7Nombre de requisito: Consultar Cursos y Talleres.Tipo: Requisito RestricciónFuente del requisito: BD Tabla: Curso, taller, Campos: Nombre,

Modalidad, Facilitador, Dirigido, Costo, Horario, Cupos.

Prioridad del requisito: Esencial Deseado OpcionalDescripción: El usuario administrador podrá visualizar el




Rev. 01Pág. 23

listado completo de los cursos y talleres detalladamente previamente registrados y tendrá la opción de modificarlos o eliminarlos. El usuario estudiante solo podrá visualizar un listado resumido de los cursos.



























Rev. 01Pág. 24





Número de requisito: RF 8Nombre de requisito: Consultar Publicaciones de Usuarios.Tipo: Requisito RestricciónFuente del requisito: BD Tabla: horario. Campos: Curso, Taller,

Día, Hora, F_Inicio, F_culminacion, Permanente, Lugar, Descripción.

Prioridad del requisito: Esencial Deseado OpcionalDescripción: Cada usuario luego de acceder al sistema

tiene la opción de administrar su perfil que mostrara públicamente información relevante sobre sí mismo.












3. Mostrar al usuario por separado los




Rev. 01Pág. 25




diferentes partes del registro y validar si se ha completado el 50% de todos los campos.













Número de requisito: RF 9Nombre de requisito: Asignación de cantidad de estudiantes.Tipo:

Requisito Restricción

Fuente del requisito: BD Tabla: Curso, taller, Campos: Cupos.Prioridad del requisito: Esencial Deseado OpcionalDescripción: Creación de campo donde el administrador

pueda ingresar la cantidad de cupos disponibles para cada curso o taller.

Requerimientos : Dependiendo la cantidad de cupos asignado por el administrador a cada curso o taller.

Se podrán registrar un estudiante dependiendo si hay cupos disponibles.

Precondiciones: El administrador debe colocar




Rev. 01Pág. 26

obligatoriamente la cantidad de cupos disponibles dependiendo del curso o del taller.


1. El administrador proporciona los datos principales para registrar un curso o del taller.

2. El administrador selecciona el límite de cupos.

3. Una vez proporcionado todos los datos se guardara el curso o el taller registrado.

1. Registrar los límites de cupos disponibles.

2. Guardar cantidad de cupos ingresado por el administrador.


4. Enviar un mensaje al usuario: Registro exitoso.


1. Si el usuario elegí un curso donde no hay cupos disponibles le mostrara un mensaje de alerta.

1. El sistema buscara en la base de datos la cantidad de cupos disponibles ingresado previamente por el administrador y si no encuentra cupos disponibles se mostrara el mensaje de alerta.

2. Si el campo de cupos está vacío se ejecutara la validación y enviara un mensaje al administrador: ingrese la cantidad de cupos para los cursos y talleres.

Post condiciones: La cantidad de cupos son guardados en la base de datos.

Requerimiento especiales: El administrador es el único usuario que puede crear, modificar y ejecutar los límites de cupos.


Número de requisito: RF 10Nombre de requisito: Asignación de facilitador.Tipo:


Fuente del requisito: BD Tabla: Curso, taller, Campos: facilitador.Prioridad del requisito: Esencial Deseado OpcionalDescripción: Creación de campo donde el administrador

pueda ingresar el facilitador para cada curso




Rev. 01Pág. 27

o taller. Requerimientos : Dependiendo del curso o taller se asigna un

facilitador. Se podrán seleccionar un facilitador

dependiendo del área formada.Precondiciones: El administrador debe seleccionar el

facilitador dependiendo del curso o del taller.


1. El administrador proporciona los datos principales para registrar un curso o del taller.

2. El administrador selecciona 3. el facilitador o encargado.4. Una vez proporcionado todos

los datos se guardara el curso o el taller registrado.

1. Registra el facilitador.2. Guardar el facilitador ingresado por el

administrador.3. Validar los datos para ser enviados a

la base de datos.4. Enviar un mensaje al usuario: Registro

exitoso.


1. Si el administrador elegí dos facilitador en curso o taller le mostrara un mensaje de error.

1. El sistema buscara en la base de datos el currículo del facilitador y si no encuentra el facilitador solicitado mostrara un mensaje de error.

2. Si el campo de facilitador está vacío se ejecutara la validación y enviara un mensaje al administrador: ingrese el facilitador para cada cursos y talleres.

Post condiciones: El currículo de cada facilitador son guardados en la base de datos.

Requerimiento especiales: El administrador es el único usuario que puede crear, modificar y ejecutar los facilitador ingresados.


Número de requisito: RF 11Nombre de requisito: Contenido informativo.Tipo:





Rev. 01Pág. 28

Fuente del requisito: BD Tabla: Curso, taller, Campos: contenidos.Prioridad del requisito: Esencial Deseado OpcionalDescripción: Creación de campo donde el administrador

pueda ingresar los contenidos de información de los cursos y talleres.

Requerimientos : El contenido de información será creado solo por el administrador.

Se podrán crear un contenido de información.

Precondiciones: El administrador debe colocar obligatoriamente el contenido de información sobre cursos y talleres.


1. El administrador crea el contenido necesario para los cursos y talleres.

2. Una vez proporcionado el contenido de información serán registrados.

1. Registrar el contenido de información.2. Guardar el contenido ingresado por el

administrador.3. Validar para ser enviados a la base de

datos.4. Enviar un mensaje al usuario: Registro

exitoso.Flujo alterno

Actor Sistema1. Si el administrador crea un

contenido de información incorrecto le mostrara un mensaje de error.

1. El sistema buscara en la base de datos el contenido de información solicitado por el administrador y si no lo encuentra se mostrara un mensaje de error.

2. Si el campo de contenido está vacío se ejecutara la validación y enviara un mensaje al administrador: ingrese el contenido de información para los cursos y talleres.

Post condiciones: El contenido de información son guardados en la base de datos.

Requerimiento especiales: El administrador es el único usuario que puede crear, modificar y ejecutar el contenido de información.


Número de requisito: RF 12




Rev. 01Pág. 29

Nombre de requisito: Generar publicaciones.Tipo:


Fuente del requisito: BD Tabla: usuario, Campos: publicaciones.Prioridad del requisito: Esencial Deseado OpcionalDescripción: Los usuarios registrados podrán crear

publicaciones de imágenes, comentarios entre otros.

Requerimientos : El usuario visitante, no podrá crear ni comentar publicaciones solo podrá visualizarlas.

Se podrán registrar una publicación dependiendo la cantidad de KB que contenga la imagen.

Precondiciones: El supervisor debe enviar un mensaje de alerta al usuario si realiza una publicación indebida.


1. El usuario crea la publicación o comentario.

2. Una vez creada una publicación comentario se visualizara en la pantalla.

3. El supervisor manifiesta al administrador si hay una publicación indebida.

1. Crear la publicación.2. Crear comentario.3. Guardar la publicación ingresada por

el usuario.4. Enviar un mensaje al usuario:

Creación exitosa.


1. Si el usuario desea realizar una publicación de tamaño excesivo le mostrara un mensaje de error.

1. Si la publicación es de tamaño excesivo el sistema mostrara un error.

2. El supervisor visualizara las publicaciones indebidas y luego se las enviara al administrador.

3. Si el campo de publicaciones está vacío y da clic en el botón guardar se ejecutara la validación y enviara un mensaje al usuario: ingresar publicación.

Post condiciones: Las publicaciones y comentarios son guardados en la base de datos.

Requerimiento especiales: El administrador y el supervisor son los únicos usuarios que puede modificar las




Rev. 01Pág. 30

publicaciones indebidas y bloquear o eliminar al usuario que la creo.


Número de requisito: RF 13Nombre de requisito: Certificado de curso y taller.Tipo:


Fuente del requisito: BD Tabla: Curso, Taller, Campos: Nombre, Modalidad, Facilitador, Dirigido, Costo, Horario, Cupos.

Prioridad del requisito: Esencial Deseado OpcionalDescripción: Los usuarios registrados en los cursos y

talleres obtendrán certificados creados por el administrador.

Requerimientos : Los usuarios tendrán que buscar el certificado a la comunidad del ateneo del la victoria.

Precondiciones: El administrador es el único usuario que puede realizar el certificado de curso o/y taller.


1. El usuario se inscribe en el curso o taller.

2. Realiza el pago del curso en la comunidad del ateneo.

1. Inscripción del usuario.2. Guarda la inscripción del usuario.3. Enviar un mensaje al usuario:

Inscripción exitosa.





Rev. 01Pág. 31

1. El usuario debe visualizar si hay cupos disponibles.

2. El administrador visualiza si el usuario está inscrito en el curso.

1. Si el usuario intenta inscribirse en un curso o taller donde no hay cupos disponibles le mostrara un mensaje de alerta.

2. Administrador visualiza si está inscrito si no lo está muestra un mensaje de usuario no existente.

Post condiciones: Los certificados de curso y talleres son guardados en la base de datos.

Requerimiento especiales: El administrador es el único usuario que puede crear, modificar y eliminar un certificado.


3.1 Requisitos comunes de las interfaces

3.1.1 Interfaces de usuario:

Se podrá interactuar con el usuario para aprovechar los requisitos del sistema,

la aplicación indicará al usuario las instrucciones que debe realizar, para

introducir los datos, como ayudas en línea, Dicha manipulación el usuario

realizará la operación por medio del teclado y el Mouse (ratón).

Descripción de la interfaz por usuarios:

Administrador: Podrá desplazarse por toda la aplicación e iniciará sesión, y

entrará en un menú con las acciones que puede realizar, de acuerdo a su nivel

de usuario.

Supervisor: Encargado de administrar publicaciones añadidas por usuarios,

trasmitir información referente a actividades del ateneo,

Estudiante: puede hacer publicaciones comentarios, registrarse en cursos e

imprimir reportes.

Visitante: Podrá desplazarse por toda la aplicación, menos por los módulos

anteriores, solo tendrá acceso a consultar información.




Rev. 01Pág. 32

3.1.2 Interfaces de hardware:

La comunicación entre los módulos del sistema se realizará mediante bases de datos relacionadas. Con el movimiento del ratón y los botones del ratón. El ratón activa las zonas de entrada de datos, botones de comando y selecciona las opciones del menú.

3.1.3 Interfaces de software

La comunicación entre los módulos del sistema se realizará mediante bases de

datos relacionadas a la interfaz.

3.1.4 Interfaces de comunicación:

La interfaz de comunicación entre el servidor de base de datos MYSQL y la aplicación desarrollada en PHP se realiza mediante el estudio de las interfaces de comunicación, ya que se trata de la entrada y salida de toda la información recibida y enviada por la impresora y el sistema de información como herramientas para la gestión administrativa del ATENEO DE LA VICTORIA del municipio José Félix Ribas no necesitan tener ese tipo de estudios.

3.2 Requisitos funcionales

Requisito funcional 1: El administrador o el usuario de la aplicación web tendrá

que identificarse para acceder al mismo.

Requisito funcional 2: Los usuarios deberán estar registrados para tener privilegios

e ingresar a todos los módulos de la aplicación.

Requisito funcional 3: La aplicación web proporcionará información y servicios

autenticando el tipo de usuario: el usuario registrado podrá realizar todos los

servicios; el usuario no registrado solo podrá realizar solicitud de cursos y talleres.




Rev. 01Pág. 33

Requisito funcional 4: El administrador tendrá privilegios a cambiar la contraseña

de los usuarios.

Requisito funcional 5: El administrador, supervisor, podrán ver los nombres de las

personas, la fecha, y el tipo de cursos y talleres que solicitaron.

Requisito funcional 6: El estudiante, solo puede visualizar su propia información en

el sistema.

Requisito funcional 7: El administrador, supervisor y el estudiante, son los

usuarios con privilegios a imprimir los reportes sobre listados de los diferentes

servicios.

Requisito funcional 8: La aplicación web deberá tener un nombre de dominio

(DNS), por medio del cual permita su ingreso digitándolo en la barra del navegador,

Todo esto debidamente configurado en el servidor Web.

Requisito funcional 9: El administrador del sistema tendrá la opción que le

permitirá listar los usuarios para habilitar o deshabilitarlo.

3.3 Requisitos no funcionales

3.3.1 Requisitos de rendimiento

El 95% de las aplicaciones del sistema deben realizarse en menos de 5

segundos.

La aplicación Web soportará la cantidad de más de 100 usuarios conectados

simultáneamente.

El número de computadores que van a estar conectadas del mismo terminal

de internet en el Sistema de información como herramienta para la gestión

administrativa del ATENEO DE LA VICTORIA va a ser de 3 equipos

computo.




Rev. 01Pág. 34

3.3.2 Seguridad

Cada usuario deberá autenticarse y su acceso verificado por una sola

terminal para su respectiva labor de acuerdo a lo que su rol especifique.

Todas las claves de seguridad deberán estar seguras y en su defecto

encriptados en la base de datos para dar una buena seguridad al sistema y

su información.

La seguridad del sistema es por el uso de contraseñas para cada usuario

(administrador, supervisor y usuarios). Estos permitirá que tengan acceso

al sistema solo los usuarios registrados en el sistema.

Entorno de Protección de la Aplicación

Perfil de Grupo

Características

del Perfil de

Grupo

Módulos a

Accesar por

Perfil

Tipo de

Autorización

Concedida

Operaciones a

Ejecutar por

Perfil

Administrador

Acceso

completo a todas

las

funcionalidades

del sistema

Acceso a todos

los módulos

Lectura,

inserción,

modificación,

actualización,

consulta genera

reportes, realiza

respaldo y

elimina

Acceso a todas

las operaciones

del sistema

supervisor Acceso

restringido con

ciertas

funcionalidades

Acceso a los

módulos de

gestionar

servicios y

gestionar

talleres y

cursos

Lectura e

inserción

Referencia de los

cursos.

Consultar

información

general.

Gestionar los

servicios del ateneo

Gestionar talleres y




Rev. 01Pág. 35

cursos

Estudiantes

Acceso

restringido con

ciertas

funcionalidades

Acceso a los

módulos de

Gestionar

servicios del

sistema

Lectura,

consultas y

reportes

Solicitar servicios

de cursos,

talleres ,

sugerencias e

información

general

Visitante

Acceso

restringido con

ciertas

funcionalidades

Acceso a la

información

Lectura y

solicitud

Visualiza los

servicios de cursos

y talleres,

sugerencias e

información

general

3.3.3 Fiabilidad de la información

Este sistema no debe arrojar incidentes ya que solo los que estén

registrados podrán observar la información compartida. Así dará

confianza al usuario en el momento de ejecutar algunos de los procesos.

En este caso no deben generar incidentes permisibles, es decir, se

obliga al personal involucrado develar los datos de los usuarios por

cuestión de integridad personal, que es sumamente importante para el

sistema de información como herramienta para la gestión

administrativa del ATENEO DE LA VICTORIA, el cual es reservado

con sus procesos, rigiéndose por las leyes existentes.

3.3.4 Disponibilidad

La aplicación debe estar disponible las 24 horas del día, los 365 días del año.

En caso contrario, deberá permitir un máximo de 20 minutos para restaurar

el sistema.




Rev. 01Pág. 36

El sistema ha sido desarrollado tomando en cuenta las necesidades y

requerimientos del Ateneo de La Victoria, por lo que se encontrará teniendo

en cuenta las tareas administrativas sobre el sistema.

3.3.5 Mantenibilidad

El mantenimiento del sistema lo realizarán los desarrolladores del mismo y

tendrá que realizarse cada año (anualmente).

En este sistema se realizará mantenimiento por los desarrolladores del

sistema este mantenimiento se realizara sin ningún recargo económico, por

lo que los diseñadores ejecutaran una fácil aplicación.

Respaldo de la Aplicación

Módulo/Archivo

a respaldar

Tiempo estimado

de respaldo

Para cada

Módulo/Archivo

Unidad de

almacenamiento

secundario

Módulo de

cambio de

clave

Módulo

de

indexació

n de

archivos

Método de

enmascaramient

o o encriptación

Aplicación Completa 10 minutoPendrive superiores a

2Gb, CD y DVDSi existe Si existe MD5

Módulo solicitud de

servicios cursos y

talleres

5 minutosPendrive superiores a


Base de datos 5 minutosPendrive superiores a


3.3.6 Portabilidad

El sistema será desarrollado bajo una arquitectura cliente - servidor.

99% portable la base de datos, MySQL puede ser ejecutado en

Windows.




Rev. 01Pág. 37

El sistema se podrá ejecutar desde cualquier navegador como Explorer,

Firefox, Google Chrome, entre otros.

3.4 Otros requisitos

El sistema tendrá un menú de ayuda donde los usuarios se puedan orientar en

el uso del sistema.

El sistema será desarrollado en una interfaz de fácil manejo.

La interfaz debe estar complementada con un buen sistema de ayuda (la

administración puede manejar en personal con poca experiencia en el uso de

aplicaciones web).

PLAN DE PRUEBAS VERSIÓN [1.1]




Rev. 01Pág. 38

HOJA RESUMEN DE MODIFICACIONES

VERSIÓN FECHA PUNTO CAMBIOS RESPECTO DE LA VERSIÓN ANTERIOR

PREPARADO POR

APROBADO POR

[1.1] 05/12/2012 Versión InicialJhonfer CastilloYusmely MejíasFélix Pérez




Rev. 01Pág. 39

ÍNDICE

HOJA RESUMEN DE MODIFICACIONES 21. INTRODUCCIÓN 4

1.1 OBJETIVOS DEL PLAN DE PRUEBAS…………………………………….4

1.2 DOCUMENTOS RELACIONADOS………………………………………….52. ALCANCE DE LAS PRUEBAS……………………………………………………5

2.1 CUADRO RESUMEN DE LAS PRUEBAS………………………………….5

2.2 CASOS DE PRUEBAS INCLUIDOS…………………………………………63. ENTORNO Y CONFIGURACIÓN DE LAS PRUEBAS 6

3.1 CRITERIOS DE INICIO………………………………………………………6

3.2 BASES DE DATOS DE PRUEBAS…………………………………………..6

3.3 CRITERIOS DE APROBACIÓN / RECHAZO……………………………....64. ESTRATEGIA DE PRUEBAS 7

4.1 ESCENARIO DE LAS PRUEBAS……………………………………………7

4.2 ORDEN DE EJECUCIÓN DE PRUEBAS…………………………………….7

4.3 EQUIPO DE PRUEBAS Y RESPONSABILIDADES………………………..8

5. REGISTRO DE LOS RESULTADOS DE LAS PRUEBAS…………………….....8

5.1 PRUEBAS DE COMPONENTES ……………………………………..…….……..9 5.1.1 PRUEBAS UNITARIAS (Caja Negra)…….………………………….…..…….9

5.1.2 PRUEBAS UNITARIAS (Caja Blanca)…………………………….………….11

5.2 PRUEBAS DE SISTEMA……………………….………………………………....15

5.2.1 PRUEBAS DE INTEGRACION………………………………………………..15

5.3 PRUEBAS DE ACEPTACION……..…………………………………………… 17

5.3.1 PRUEBA DE USABILIDAD………………..……………………………...……17




Rev. 01Pág. 40

1 INTRODUCCIÓN

Proyecto Tipo de ProyectoSistema De Información Como Herramienta

Para La Gestión Administrativa Del

ATENEO De La Victoria Del Municipio José

Félix Ribas Edo-Aragua.

Proyecto Socio Tecnológico III

Documentos Evaluación relacionadosDocumento SRSEquipo de Proyecto: Jhonfer Castillo, Yusmely Mejías, Félix Pérez.Responsable de Equipo Jhonfer Castillo Tutor:

1 OBJETIVOS DEL PLAN DE PRUEBAS

Este documento, tiene como finalidad entregar las modelos a concretar diseñando un plan de pruebas de tal manera que no se presenten posibles problemas en el futuro , obteniendo así un producto final en optimas condiciones a las establecidas y con cada uno de los requerimientos necesarios para que el producto tenga calidad.

Las Fases en las que se realizarán las pruebas son:1. Planificación de las pruebas: Identificar los requisitos para las pruebas. Desarrollar la

estrategia de pruebas. Identificar los recursos necesarios para realizar las pruebas. Generar el Plan de pruebas.

2. Diseño de las pruebas: Desarrollo de las pruebas. Identificar y describir los casos de prueba.

3. Implementación de las pruebas: Establecer el entorno de prueba. Desarrollar las clases de prueba, los componentes de prueba y los datos de prueba.

4. Ejecución de las pruebas: Ejecutar los casos de prueba. Evaluar la ejecución del proceso de prueba. Verificar los resultados. Investigar los resultados no esperados. Registrar los defectos.

5. Evaluación de las pruebas: Evaluar la cobertura de los casos de prueba. Evaluar la cobertura del código. Analizar los defectos. Determinar si se han alcanzado los criterios de las pruebas. Crear los informes de evaluación de las pruebas.




Rev. 01Pág. 41

1.1 DOCUMENTOS RELACIONADOS

Nombre Descripción Fecha Elaboración

Documento SRSInforme de Especificación de Requisitos

Informe técnico.

Representa la problemática de la comunidad, las fases de las metodologías y los planes de inversión.

2 ALCANCE DE LAS PRUEBAS

En los siguientes cuadros se refieren a las pruebas en cuanto al tipo de ejecución y los requerimientos del sistema.

CUADRO RESUMEN DE LAS PRUEBAS

Componentes a ser probados:

Módulo de Registro: Sub. Módulo: Registro (Administrador)

Sub.Módulo: Autenticación (Iniciar Sesión)

Sub. Módulo: Registro (Estudiantes)

Sub. Módulo: Registro (Supervisor)

Objetivos de las Pruebas En estos Módulos se realizarán pruebas para validar: La visualización de los datos, ingresados y que no estén

los campos vacios. Respuesta y realización de las transacciones de cada sub.

módulo. Que el sistema este acorde a las actividades que el

usuario requiere.

Detalle del orden de ejecución de los componentes

Los sub. módulos se deben ejecutar en forma independiente, pero consecutivos en el orden siguiente:

Registrar Administrador.

Inicio de sesión.

Registro de Estudiante.

Registro de Supervisor.

Responsabilidad de la Prueba Las pruebas son responsabilidad por los operadores del sistema los cuales deben realizar las pruebas y asegurar la efectividad de la aplicación.

3 ENTORNO Y CONFIGURACIÓN DE LAS PRUEBAS




Rev. 01Pág. 42

Para el proceso de pruebas del proyecto se requiere de la disponibilidad de los siguientes entornos, a saber:a. Servidor, equipo con acceso a Internet,

Sistema operativo Windows 7 P4 celeron. 384 MB Ram Disco Duro de 40 GB unidad de CD-ROM.b. Base de Datos MySQL. Reside en equipo servidor

3.1 CRITERIOS DE INICIO

Aceptación del plan de pruebas. Revisión y aceptación del documento que contiene los casos de pruebas para la certificación del proyecto, estas pruebas son realizadas por el usuario.

Aceptación de paquetes. Revisión y aceptación de los software de desarrollo, y que éstos cumplan con las condiciones de aceptación.

Aceptación de ambiente. Revisión y aceptación del ambiente de certificación, y que éstos cumplan con las condiciones de aceptación.

3.2 BASES DE DATOS DE PRUEBASBase de Datos : Bd_ateneo

Servidor BD : MySQL

Datos : Aleatorios

3.3 CRITERIOS DE APROBACIóN / RECHAZO

Errores Graves: información crítica presentada erróneamente, información mal registrada en la base de datos, caídas de programas, incumplimiento de objetivos en funciones principales, entre otros.

Errores Medios (comunes): errores en presentación de datos, incumplimiento de objetivos en funciones secundarias, caídas de programas auxiliares, entre otros.

Errores Leves: errores en presentación de datos secundarios, no adecuación a estándares, comportamientos correctos pero diferentes en situaciones similares, dificultades de operación, entre otros.

Criterio Descripción

Aprobado

Se aprobará el proyecto con un 100% de las pruebas ejecutadas pero con un 90% de aceptación. Esto quiere decir que el 90% de las pruebas deben ser exitosas y sin errores. En el restante 10% pueden existir errores medios o bajos, pero no graves.

RechazadoEn caso de ocurrir que el proyecto no cumpla con el nivel exigido, el proyecto se rechaza completo en su etapa de certificación.




Rev. 01Pág. 43

4 ESCENARIO DE LAS PRUEBAS

Para cumplir con los objetivos planteados se presentan diversos escenarios de pruebas, estos son: Pruebas de Componentes, Pruebas de Sistemas, Pruebas de Integridad, Pruebas de Interfaz (Usabilidad) y Pruebas Alfa. Para las pruebas de Componentes se debe:

Verificar el Módulo de Registro, Sub.Módulo: Registro (Administrador),.

Verificar el Módulo de Registro, Sub. Módulo: Autenticación (Inicio de sesión) para lo que se introducen los datos aleatoriamente.

Verificar el Módulo Registro, Sub. Módulo: Incluir (Registro de Estudiante), para lo que se introducen datos aleatoriamente.

Verificar el Módulo Registro, Sub. Módulo: Incluir (Registro de supervisor), para lo que se introducen datos aleatoriamente.

Verificar el Módulo Generar Reportes de Asistencia General, Sub. Módulo: Generar (reportes de Inscripción en los cursos o talleres y Trípticos).

4.1 ORDEN DE EJECUCIÓN DE PRUEBAS

Las pruebas se llevarán a cabo de la siguiente forma: 1. Secuencias de pasos para la Configuración

Configuración de los Equipos Cliente, del Servidor de Aplicación Web y de la Base de Datos. ¿???]

2. Secuencias de pasos para la generación de datos para el módulo y sus componentes

Ejecución del proceso (manual) de generación de datos de entrada con información de potenciales usuarios del sistema de gestión administrativa.

3. Secuencias de pasos para la generación de datos para los cinco componentes.

Ejecución del proceso (manual) de generación de datos, donde las tablas y campos a utilizar serán llenados manualmente.

4.2 EQUIPO DE PRUEBAS Y RESPONSABILIDADES

Nombres ResponsabilidadJhonfer Castillo Líder del equipo. Responsable de evaluar las condiciones de término para el

proceso de pruebas junto al tutor y el resto del equipo.Jhonfer Castillo,Yusmely MejíasFélix Pérez

Analista funcional, responsable de la resolución de las incidencias de certificación para los sub. módulos de Registro de administrador, inicio de sesión, registro de estudiantes y registro de supervisor.

Jhonfer Castillo,Yusmely MejíasFélix Pérez

Testing de Solución, responsable de la generación del plan de pruebas.




Rev. 01Pág. 44

5 REGISTRO DE LOS RESULTADOS DE LAS PRUEBAS.

En esta sección se muestran rigurosa y sistemáticamente los resultados arrojados por cada prueba. Para ello, ya se han definido los escenarios. En tal sentido, los resultados obtenidos se clasifican según:

5.1 PRUEBAS DE COMPONENTE5.1.1 PRUEBAS UNITARIAS. (Caja Negra)

.Caso de prueba 1.

Interfaz

Nombre Se ingresa al sistema en nivel de administrador.

Objetivos Si el usuario no se encuentra registrado no podrá ingresar al sistema.

Entrada usuario : Jhonfer Contraseña: 1234

Condiciones de ejecución Que no exista en la tabla usuario (usuario, código) el registro <”Jhonfer”, “20068665”> pero si un registro<”Jhonfer”, “1234”>.

Resultados esperados Si coloca la contraseña incorrecta se mostrara un mensaje de error. “Error al acceder al sistema ingrese contraseña correcta”.

Observaciones




Rev. 01Pág. 45

Caso de prueba 2.

Interfaz

Nombre Se ingresa al sistema en nivel de Estudiante.

Objetivos Si el estudiante no se encuentra registrado no podrá ingresar al sistema.

Entrada Usuario : Yusmely Contraseña: 1234

Condiciones de ejecución

Que no exista en la tabla estudiante (estudiante, código) el registro <”Yusmely”, “30679”> pero si un registro<”Yusmely”, “1234”>.

Resultados esperados Si coloca la contraseña incorrecta se mostrara un mensaje de error. “Error al acceder al sistema ingrese contraseña correcta”.

Observaciones

Interfaz

Nombre Registro de Profesores.

Objetivos Se debe comprobar que en la base de datos se encuentren los datos del profesor registrado.

Entrada Campo de cedula vacio.

Condiciones de ejecución

Si no existe un profesor registrado en la tabla de profesor (cedula, nombre). Cedula: vacía Nombre: José, peros si un registro. Cedula: 20066798 Nombre: José

Resultados esperados Si el campo de cedula se encuentra vacio no se podrá guardar el registro.

Observaciones

Caso de prueba 3




Rev. 01Pág. 46

5.1.2 PRUEBA UNITARIAS. (Caja Blanca)

Cuadro Nº 1. Módulo de Registro, Sub. Módulo: Iniciar SesiónObjetivos de la prueba

Comprobar el módulo de registro, Sub. Módulo Autenticación (Iniciar Sesión)

Técnicas Solicitar acceso con datos válidos e inválidos.

Código involucrado

Casos de prueba

Resultados Todos los casos de pruebas planificados se han ejecutado.Todos los defectos identificados se han considerado.

Observaciones

Cuadro Nº 2. Módulo de Registro, Sub. Módulo: Olvido Contraseña.


Formato de casos de pruebas

Tipo de prueba: Unitaria (Caja Blanca)

Objetivo: Validar los datos de un usuario para registrarse en el sistema.

Caso No. 1

Descripción: Datos incorrectos: Nombre de Usuario con caracteres no permitidos.

Entradas: Nombre: jose#je45Contraseña: “ jose1234” Correo: joseyahoo.com Sexo: masculino Nivel:””

Salidas esperadas: Error al registrarse datos inválidos. Los datos ingresados son incorrectos.



Rev. 01Pág. 47

Objetivos de la prueba

Comprobar el módulo de registro. Sub Módulo Recuperación (¿Olvido su contraseña?)

Técnicas Solicitar recuperación de contraseña con datos válidos e inválidos.

Código involucrado

Método de Recuperación.

<?php

require_once('recaptcha-php-1.11/recaptchalib.php');

$publickey = "6LeujtkSAAAAAFNaGcWx9B4X_FFJIKFrj5wovFLF";

$privatekey = "6LeujtkSAAAAAApcfz5vvwEMrqU9_AK0GSM5c8tu";

$error = null;

if ($_POST['action'] == "register") {

$re_ip = $_SERVER["REMOTE_ADDR"];

$re_challenge = $_POST["recaptcha_challenge_field"];

$re_response = $_POST["recaptcha_response_field"];

$resp = recaptcha_check_answer($privatekey, $re_ip, $re_challenge, $re_response);

if ($resp->is_valid) {

// procesar registro

echo "Registro completo";

exit;

} else {

$error = $resp->error;

}

}

?>




Rev. 01Pág. 48

Casos de prueba


Observaciones




Objetivo: Recuperar la contraseña olvidada por parte de de un usuario registrado.

Caso No. 1

Descripción: Datos incorrectos: Cuenta de correo no valida

Entradas: Dirección E-mail: jose#je5hotmailll.com

Salidas esperadas: Su correo es incorrecto. Introduzca un correo valido para recuperar contraseña.



Rev. 01Pág. 49

Cuadro Nº 3. Módulo de Registro, Sub. Módulo: Registro de Facilitador.Objetivos de la prueba

Comprobar el módulo de registro. Sub Módulo, Registro de Facilitador.

Técnicas Solicitar registro de facilitador con datos válidos e inválidos.

Código Involucrado

Casos de prueba


Observaciones




Objetivo: Registrar de Facilitador.

Caso No. 1

Descripción: Datos incorrectos: campo de curriculum vacio.

Entradas: Curriculum:”” Cédula: 123456Nombre: José Apellido: Colmenares Correo: [email protected] Sexo: masculinoSalidas esperadas: Campo vacio. Ingresar un curriculum.



Rev. 01Pág. 50




Rev. 01Pág. 51

5.2 PRUEBAS DE SISTEMA

5.2.1 PRUEBAS DE INTEGRACIÓN

Cuadro nº 1.Sub. Módulo: Modo de Administrador. Objetivos de la prueba

Añadir nuevos usuarios al sistema en modo administrador.

Ejecutar el recorrido descrito anteriormente con datos validos e inválidas para comprobar lo siguiente. Cuando se utilizan datos correctos se confirma el

registro de usuario y es guardado en base de datos.

A. Se ingresara correctamente al respectivo modulo del usuario previamente guardado.

Cuando se utilizan datos incorrectos se obtienen los mensajes de error o advertencias adecuadas tanto en el registro de usuario como en el menú de sección.

Interfaz Asociada

Resultados Acceder al sistema dependiendo del nivel requerido por el usuario.




Rev. 01Pág. 52

Cuadro nº 2.Sub. Módulo: Modo de estudiante.


Ingresar correctamente a la aplicación, el procesamiento de los datos, en modo estudiante. En modo administrador el usuario por defecto será: Jhonfer. Contraseña: 1234.


registro del estudiante y es guardado el nuevo usuario.

A. En el menú de inicio de sección son validado los datos y el estudiante ingresa al sistema.

Cuando se utilizan datos incorrectos se obtienen los mensajes de error o advertencias adecuadas tanto en el registro de usuario como en el menú de sección.

Interfaz Asociada

Resultados Si los datos del usuario son correctos y se encuentran registrados en la base de datos puede ingresar sistema.

Cuadro nº 3. Asignar un profesor. Objetivos de la prueba

Asignar un profesor y guardar un curso o taller.


registro del profesor y es guardado para luego ser mostrado en nuevo registro de curso o taller.

A. El nuevo curso o taller son almacenados con un profesor asignado.

Cuando se utilizan datos incorrectos se obtienen los mensajes de error o advertencias adecuadas tanto en el registro de profesores como el registro de cursos y talleres.




Rev. 01Pág. 53

Interfaz Asociada

Resultados Registrar un profesor y que se visualiza en el registro de curso o taller en el campo de facilitador.

5.3 PRUEBAS DE ACEPTACION 5.3.1 PRUEBAS DE USABILIDAD

Cuadro nº 1.


La aplicación no posee una barra de navegación que muestre el seguimiento y el posicionamiento en el que se encuentra el usuario o estudiante.Crear pruebas para cada ventana con el objetivo de verificar la correcta navegación y su estado.

Heurísticas aplicadas Todas las heurísticas (ver anexo pagina 16).

Interfaz Asociada

Resultado esperado Infórmale al usuario donde se encuentra. A través de una barra de

estado dentro del sistema.




Rev. 01Pág. 54

Cuadro nº 2.


Falta de mensajes descriptivos en algunos formularios a la hora de buscar los cursos o talleres que no sean encontradas.

Crear mensajes de ayudas.Heurísticas aplicadas Todas las heurísticas (ver anexo pagina 16).

Interfaz Asociada

Resultado esperado

Programar mensajes de error cuando no sea encontrado los datos de los cursos o talleres que el usuario haya ingresado.




Rev. 01Pág. 55

Cuadro nº 3.


Poco orden visual en las consultas de listado de curso o talleres.

Crear un listado más complejo.Heurísticas aplicadas Todas las heurísticas (ver anexo pagina 16).

Interfaz Asociada

Resultado esperado

Ordenar adecuadamente las consultas y agregarle solo los datos necesarios.




Rev. 01Pág. 56

6 PRUEBAS HEURÍSTICAS

La evaluación heurística es un método de evaluación formativa, mediante la cual, los expertos

critican la interfaz confrontándola con una guía de elementos básicos de diseño elaborada

previamente y, en este sentido, es una herramienta de comparación de objetivos explícitamente

estipulados. Tiene como objetivo determinar los posibles problemas de usabilidad más comunes en el

diseño de una interfaz, antes que determinar en qué grado cumple ésta o aquella función. Como

resultado de este tipo de evaluación, se elaboran listas pormenorizadas de problemas de usabilidad,

en la que se detallan, esos problemas, la heurística asociada al problema, la valoración del experto y

la posible solución (Ver Formato).

Formato para la realización de las pruebas Heurísticas de la Interfaz

Para la evaluación presentada se utilizaron las “10 Heurísticas de Nielsen” y una escala de

valoración para cada problema (Ver Tabla 1).

Tabla 1. Valoración de los problemas y heurísticas de Nielsen

Fecha: 03- 12- 2012 Hora: 10 am

Nombre del Evaluador: Sandra Hernández

ProblemaHeurística Valoración Solución

La aplicación no posee una barra de

navegación que muestre el

seguimiento y el posicionamiento en el que se encuentra

Asistencia al usuario (H10).

Problema mayor de

usabilidad; importante

fijar solución (3).

Infórmale al usuario donde se encuentra. A través de una barra de

estado dentro del sistema.


Leyenda de valoración Heurísticas de Nilsen

0 - No es un problema de Usabilidad1 - Problema cosmético2 - Problema menor3 - Problema mayor de Usabilidad; importante fijar solución4- Usabilidad catastrófica, imperativo fijar solución

H1: Diálogo natural y simpleH2: Hablar el lenguaje del usuarioH3: Minimizar la carga cognitivaH4: Consistencia

FeedbackH6: Proveer claramente las salidasH7: Proveer ShortcutsH8: Mensajes de Error descriptivosH9: Prevención de Errores

H10: Asistencia al Usuario



Rev. 01Pág. 57

el usuario o estudiante.

Falta de mensajes descriptivos en

algunos formularios a la hora de buscar los cursos o talleres

que no sean encontradas.

Mensaje de errores descripticos (H8).

Problema mayor de

usabilidad; importante

fijar solución(3).

Programar mensajes de error cuando no sea

encontrado los datos de los cursos o talleres que

el usuario haya ingresado.

Poco orden visual en las consultas de

listado de curso o talleres.

Dialogo natural y simple (H1).

Problema menor (2).

Ordenar adecuadamente las

consultas y agregarle solo los datos

necesarios.

Formato del instrumento de validación de usabilidad del Ateneo de La VictoriaSeleccione la opción que más se acerque a su opinión:

ASPECTOS A EVALUAR EN LA APLICACIÓN: VALORACIÓN

SI MED NO

Incluye información relevante, necesaria y sencilla. Utiliza palabras, frases y conceptos familiares. Sigue convenciones del mundo real. Usa objetos, acciones y/o opciones para evitar que el usuario tenga que




Rev. 01Pág. 58

recordar información. Ejemplos: menús desplegables, metáforas.Provee objetos visibles e intuitivos La composición de la pantalla es la misma en toda la aplicación. Cada control tiene asignado una única función y siempre es la misma

Siempre informa acerca de lo que está ocurriendo Permite deshacer y rehacer acciones realizadas Incluye acciones para hacer más rápida la interacción Incluye mensajes de error expresados en un lenguaje común y sencillo, indicando el problema y sugiriendo soluciones de forma constructiva

Incluye acciones para prevenir la existencia de errores Incluye ayuda para asistir al usuario El uso de las metáforas son adecuadas , es decir, refleja el modelo real, es coherente en su aspecto y consistente en su uso

Existe legibilidad y claridad textual (tipo, color y tamaño adecuado de la fuente utilizada)

Existe organización adecuada del contenido y los elementos


Srs y Pruebas del Sistema del ateneo

Documents

Transcript of Srs y Pruebas del Sistema del ateneo