• Categories
• Google Chrome
• Red mundial
• Tecnología
• Archivo de computadora
• Aplicación web

Citation preview

Escuela de Ing. en Computación Introducción al desarrollo de aplicaciones web

ERS Especificación de Requerimientos del Sistema

Profesora: Emilia Zeledón N.

Estudiantes: Kenneth Jiménez Cerdas - 200926414 Geovanny López Jiménez – 200926416 Manuel Murillo Sanchez - 200927704 Edgar Salas Garita - 200926432

Setiembre, 2011

Tabla de Contenidos Contenido 1- Introducción 1.1- Propósito del documento ERS 1.2- Descripción del problema 1.3- Lista de problemas detectados 1.4- Lista de fortalezas detectadas 1.5- Objetivos del sistema 1.5.1- Objetivo general 1.5.2- Objetivos específicos 1.5.3- Criterios de éxito 1.6- Perspectiva del producto por desarrollar 1.7- Reglas de negocio 1.8- Suposiciones y dependencias 1.9- Alcances del sistema 1.10- Limitaciones o restricciones 1.11- Stakeholders y sus necesidades 1.12- Visión general de la estructura documento ERS 2- Requerimientos funcionales 2.1- Contexto del sistema 2.1.1- Diagrama de contexto 2.1.2- Modelo dominio del sistema 2.1.3- Descripción modelo dominio 2.1.4- Diagrama de casos de uso 2.2- Descripción detallada de los CU 2.2.1- Texto del CU 2.2.2- Pantalla (s) y/o reporte (s) del CU 2.2.3- Diagrama de actividades del CU 2.2.4- Diagrama de estados del CU 2.2.5- Diagrama de secuencia del sistema (DSS) 2.2.6- Contrato de operaciones 2.2.7- Casos de prueba del CU 3-Requerimientos no funcionales 3.1- Producto 3.1.1- Eficiencia 3.1.2- Interfaz local del usuario 3.1.3- Interfaz Web del usuario 3.1.4- Seguridad 3.2- Organizacionales 3.2.1- Documentación 3.2.2- Entregas 3.2.3- Implementación 3.3- Externos 3.3.1- Interoperabilidad 3.3.2- Legales Apéndices

Página 2 2 2 2 2 3 3 3 3 3 4 4 5 5 6 7 8 8 8 9 9 10 11 11

1

1. Introducción 1.1 Propósito del Documento ERS Este documento pretende explicar a fondo todos los requerimientos que se han planteado los desarrolladores del sistema con el cliente, de manera que se explique lo que el sistema requiere para su funcionamiento, acorde a las expectativas del cliente, y además, demostrar que el equipo de trabajo es capaz de cumplir en el proyecto en el periodo de tiempo establecido. 1.2 Descripción del Problema El problema que se ha planteado para este proyecto es la necesidad que tiene el Liceo Nocturno de Ciudad Colon para informar a la comunidad de Ciudad Colon (San José), e incluso su propio personal acerca del acontecer dentro de la institución; los avances que se hacen, difundir los eventos que planea el colegio, entre otros. Este problema afecta directamente a estudiantes, profesores, administrativos, así como al resto de la comunidad. Todo esto representa una desventaja para el Liceo Nocturno de Ciudad Colon en comparación con otros colegios que ya cuentan con medios para comunicar de lo que sucede dentro de sus instituciones. Aún más por el hecho de tratarse de un colegio nocturno, ya que los estudiantes prefieren asistir en su mayoría a colegios diurnos, por lo que el colegio realmente necesita un medio para informar. Una interesante solución a este problema surge con la idea de la creación de una página web, de manera que la página web cuenta con información del colegio, de manera que la comunidad de Ciudad Colon sea capaz de ingresar al sitio y plantearse las ventajas que pueden tener asistiendo a esta institución. 1.3 Lista de Problemas Detectados Dentro de los problemas detectados están: -

Se necesita de un servidor para que la página quede funcionando completamente. Hay ciertos profesores que no están de acuerdo con la idea de brindar sus correos o números de teléfono para colaborar con la creación de la página. El diseño de la página web puede ser un poco sencillo debido a que ninguno de los integrantes del grupo está especializado en diseño.

1.4 Lista de Fortalezas Detectadas Entre las fortalezas detectadas están: -

La página cumple con todo lo que el colegio tenía pensado. No tendrán que pagar nada por el desarrollo de la página web. El colegio será capaz de informar noticias acerca de ellos. La página web estará lista antes de diciembre de este año.

2

1.5 Objetivos del Sistema: 1.5.1 Objetivo General: Elaborar un medio para informar del acontecer de la institución del Liceo Nocturno de Ciudad Colon a través de una página web, con una fecha límite estimada a diciembre del 2011, el cual no tendrá costo alguno. 1.5.2 Objetivos Específicos: 1. 2. 3. 4. 5. 6. 7. 8.

Iniciar sesión en la página web. Cerrar sesión en la página web. Subir archivos a la página web. Descargar archivos de la página web. Borrar archivos de la página web. Modificar información de la página web. Agregar usuarios a la página web. Borrar usuarios de la página web.

1.5.3 Criterios de Éxito: Dentro de los principales criterios de éxito, se pueden mencionar: 1. 2. 3. 4. 5.

Acceso a la página web como diversos usuarios (personal de mantenimiento o docente). Permite salir de manera segura de la página web. Permite a los usuarios docentes subir archivos, así como al administrador. Permite a los usuarios docentes y administrado descargar archivos de la página. Permite al administrador eliminar archivos, así como a los usuarios docentes eliminar sus archivos propios. 6. Permite al administrador modificar información anuente a la institución, o de los usuarios docentes, en la página web dentro de las secciones ya establecidas. 7. Permite al usuario de mantenimiento agregar nuevos usuarios docentes a la página web. 8. Permite al usuario de mantenimiento borrar usuarios docentes existentes en la página web. 1.6 Perspectiva del producto por desarrollar Este proyecto tiene como fin desarrollar una página web para el Liceo Nocturno de Ciudad Colon, ubicado en el cantón de Mora en San José, quienes necesitan un medio para dar a conocer el colegio en la web. Esta página tendrá la capacidad de mostrar información relevante en cada materia impartida en la institución, así como información importante del colegio en general. Además, a diferencia de otros programas de este tipo, se espera que esta página posea un diseño acorde con la institución y que a la vez sea agradable para los usuarios que la visiten.

3

1.7 Reglas de negocio: Hechos: 1. La página debe ser accesible al menos durante el lapso de 6am a 10pm, dejando cualquier mantenimiento o cualquier otra actividad que comprometa la accesibilidad de la página. 2. La página cuenta sólo con información autorizada previamente por el director de la institución, o el encargado directo nombrado por el director de la institución. Restricciones: 1. La página debe de mostrar solamente información de la institución y sus empleados, descartado cualquier tipo de publicidad o información extra. 2. La información mostrada en la página no debe comprometer a la institución o a cualquiera de sus empleados. Ejecución de acción: 1. La página debe mostrar notificaciones de éxito para cuando se suba un archivo y se gestionen usuarios. 2. Tras un intento fallido en iniciar sesión, debe de expresarse el motivo del fallo y a quien contactar para solucionar el problema en último caso. Inferencias: 1. Después de agregar un usuario, el uso de su perfil puede ser inmediato. 2. Tras eliminar un usuario, su perfil perderá todo valor y no se respaldará información alguna del mismo. 3. Tras solicitar un cambio, si es efectuado con éxito debería reflejarse de manera inmediata en la página. Cálculos: 1. No aplican por ser una institución sin fines de lucro. 1.8 Suposiciones y Dependencias Para la realización de este proyecto se han tenido que tomar varias cosas en consideración, mientras que otras simplemente se han asumido de parte de los desarrolladores del proyecto. Dentro de las suposiciones y dependencias podemos mencionar: Se ha asumido que el programa será utilizado por personas que conocen el funcionamiento de este tipo de herramientas, por lo que a la hora de entregar el proyecto no se brindará capacitación alguna, únicamente se brindará una pequeña guía del sitio. Además, se ha asumido que este programa debe funcionar similarmente a los demás programas de este tipo, es decir, no se han incluido funciones especiales en su funcionamiento, únicamente las solicitadas por el usuario.

4

Otra suposición que se ha hecho para la elaboración de este proyecto es que se utilizaran navegadores conocidos para acceder a la página (Por ejemplo, Google Chrome, Firefox, IE). 1.9 Alcances del Sistema El sitio web del Liceo Nocturno de Ciudad Colón les permitirá a los usuarios acceder a una página con un diseño que transmita la imagen de la institución. Para esto la página web va contar un mínimo de cuatro pestañas de las cuales una de ellas es una página de bienvenida, otra con información referente al liceo como lo es la misión, visión, situación actual, historia, otra pestaña que corresponde las asignaturas impartidas, con una descripción de las mismas. El sistema tendrá acceso desde internet y será compatible con los siguiente tres navegadores: Firefox, Chrome e Internet Explorer. Además, el sitio web del Liceo Nocturno de Ciudad Colón no solo servirá para navegar a través de la información sino que se añadirá una plataforma de administración de usuarios y archivos de manera que tanto estudiantes como profesores cuenten con una cuenta de usuario que les permita utilizar la página para cargar y descargar archivos sobre diferentes asignaturas. 1.10 Limitaciones y Restricciones Limitaciones: -

Dentro de la sección de cursos no está contemplado un mecanismo para llevar a cabo las evaluaciones de estos, únicamente se incluyeron las funciones de subir y bajar documentos. No se sabe el espacio destinado para el almacenamiento de documentos pertenecientes a la página web, esto debido a que la institución aún no cuenta con un servidor donde subir el sitio.

Restricciones: -

Únicamente podrán ingresar al sitio aquellas personas que son miembros del personal de la institución, ya sean estudiantes, profesores, o administrativos. Las únicas personas que podrán subir archivos, son profesores y administrativos. Las únicas personas habilitadas para descargar archivos del sitio, son aquellas que puedan ingresar con un nombre de usuario y una contraseña.

5

1.11 Stakeholders y sus necesidades Stakeholder

Otros Interesados

Estudiantes

Profesores

Beneficio Directo Fácil y rápido acceso a la información del Liceo.

Actitudes Ven al producto como algo ventajoso debido a que facilitaría el acceso a información relevante.

Fácil y rápido acceso a la información y documentos posteados en la página.

Ven al producto como algo ventajoso debido a que facilitaría el acceso a información y documentos.

Fácil y rápido acceso a la información y documentos posteados en la página.

Ven al producto como algo ventajoso debido a que facilitaría el acceso a información y documentos.

Administrativos

Fácil distribución de la presencia de la institución.

Desarrolladores

Evitar los errores en el diseño de la página.

Necesidades Acceder fácilmente a la información referente a la institución del Liceo Nocturno de Ciudad Colón. Acceder fácilmente a la información referente a la institución del Liceo Nocturno de Ciudad Colón, así como a los documentos posteados en el sitio. Acceder fácilmente a la información referente a la institución del Liceo Nocturno de Ciudad Colón, así como poder postear y descargar documentos.

Limitaciones

Evitar errores y confusiones a la hora de utilizar los servicios del sistema.

Evitar errores y confusiones a la hora de utilizar los servicios del sistema.

Muy receptivas ya que esperan que se logre el dar a conocer la institución a través de más medios.

Otorgar información de la institución a quien interese, además de poder estar subiendo documentos a la página.

Evitar errores y confusiones a la hora de utilizar los servicios del sistema.

No tolerantes a errores en el sistema; búsqueda de calidad

Correcto funcionamiento de la página.

Terminar el proyecto en la fecha establecida.

6

1.12 Visión general de la estructura del documento ERS El documento de ERS muestra de manera concreta y especifica los puntos a considerar en el proyecto de la página web en desarrollo para la institución del Liceo Nocturno de Ciudad Colón. Aquí se ubica en contexto al proyecto, se describe, y detalla sus partes por medio de material tanto textual como visual para poder expresar de manera clara su propósito. En este documento se detallan tanto requerimientos funcionales como no funcionales involucrados en el desarrollo de la página web. Para cada requerimiento funcional en el proyecto, por medio de diversos diagramas, se explica su relevancia y su significado, y se muestra la interacción que conllevan en el sistema. A través de estándares, como lo son las plantillas propuestas por autores reconocidos en el ámbito de ERS y relacionados, se generaliza el entendimiento, ya que se siguen pautas usadas por la mayoría y permiten un seguimiento más fluido de la especificación. En la elaboración de este proyecto se reflejan características y riesgos a tomar en cuenta, por lo que se enlistan dichos peligros al igual que con los requerimientos, y se detallan de manera similar, con la excepción de que los peligros son factores a tomar en cuenta en el desarrollo del proyecto, y los requerimientos muestran además de qué trata el proyecto.

7

2. Requerimientos funcionales

2.1 Contexto del sistema 2.1.1 Diagrama de Contexto: Suben Arch.

Usuarios Externos

Profesores Muestra Info. Muestra Info. Ven Info.

Ven Info. Ven Info. Solicitan Info.

Estudiantes Brinda Info.

Pagina Liceo Nocturno de Ciudad Colon

Gestion Usuar.

Administrativos

Muestra Info. Añaden Arch.

Descargan Arch.

Datos

Datos

Servidor

8

2.1.2 Modelo del dominio del sistema:

2.1.3 Descripción del Modelo de Dominio del sistema: Para empezar, se tiene una clase para cada tipo de usuario, ya sean administrativos, profesores, estudiantes, o algún otro usuario ajeno a la institución. Todos estos usuarios están en capacidad de ver la página web y descargar los documentos contenidos en esta, sin embargo, a la hora de ver la sección de cursos, únicamente los profesores y administrativos tendrán la posibilidad de subir archivos nuevos. Además, únicamente los administrativos están habilitados para gestionar usuarios (hay una clase usuarios); los cuales pueden ser de dos tipos, profesores u otro administrativo, precisamente por esto está la clasificación del concepto usuario. Estos usuarios poseen como atributos un nombre, un número de identificación y una contraseña para ingresar al sistema, mientras que los estudiantes y las demás personas que ingresen al sitio no poseen ningún atributo especial. Para los estudiantes hay una clase y para los demás usuarios otra, esto con el fin de hacer la distinción entre miembros de la institución y los que no lo son. En cuanto a los documentos que se suben a la página web, estos poseen como atributos la fecha en que se subieron y un tamaño de archivo, mientras que la página web en general, únicamente contiene una dirección para ser ingresada como atributo.

9

2.1.4 Diagrama de casos de uso:

10

2.2 Descripción detallada de los CU 2.2.1 Texto de los Casos de Uso Use Case ID Created By Date Created Actors Description

Preconditions Post conditions Normal Course

Alternative Courses Exceptions

Includes Priority Frequency of Use Business Rules Assumptions Notes and Issues

UC-1 Use Case Name Iniciar Sesión Edgar Salas Garita Last Updated By Edgar Salas Garita 13/09/2011 Date Last Updated 13/09/2011 Profesores y Administrativo El profesor o administrativo especifica su número de identificación y contraseña. El sistema se encarga de validar los datos para luego abrir una página con la sesión iniciada. 1. El actor debe pertenecer a la institución. 2. El actor debe poseer una ID válido para el sistema. 1. El actor tiene acceso a la página con sus permisos correspondientes. 1.0 El actor solicita iniciar sesión en el sistema. 1. El actor especifica su número de identificación y contraseña. 2. El sistema verifica que esa información sea válida. 3. El sistema establece los permisos que según el tipo de usuario. 4. El sistema muestra la página correspondiente al usuario que ha iniciado sesión. No aplica. 1.0 E1. Usuario no valido (en paso 2). 1. El sistema muestra el mensaje: “El usuario y/o contraseña no es válido” 2. El sistema limpia las entradas de texto y solicita al usuario volver a intentarlo. 3. El sistema vuelve a iniciar el flujo normal de acciones. 4. El usuario decide salir. 5. El sistema termina el caso de uso No aplica Alta Aproximadamente unas 12 veces al día por profesor y unas 5 veces a la semana por parte de los administradores. No aplica 1. Cada usuario inicia sesión con su propia cuenta.

11

Use Case ID Created By Date Created Actors Description

Preconditions Post conditions Normal Course

Alternative Courses Exceptions Includes Priority Frequency of Use Business Rules Assumptions Notes and Issues

UC-2 Use Case Name Cerrar Sesión Edgar Salas Garita Last Updated By Edgar Salas Garita 13/09/2011 Date Last Updated 13/09/2011 Profesores y Administrativos El profesor o administrativo solicita cerrar la sesión que actualmente tiene abierta. El sistema se encarga de guardar los datos que han modificados y de regresar a la página original con la sesión cerrada. 1. El actor debe tener una sesión activa. 1. Los cambios son guardados 2. Se muestra la página original que se muestra a todos los usuarios. a. El actor solicita cerrar sesión en el sistema. 2. El sistema verifica que los cambios que se han hecho. 3. El sistema guarda los cambios. 4. El sistema muestra la página correspondiente con la sesión cerrada. No aplica. No aplica. No aplica. Alta Aproximadamente unas 12 veces al día por profesor y unas 5 veces a la semana por parte de los administradores. No aplica 1. Cada usuario cierra sesión su propia cuenta.

12

Use Case ID Created By Date Created Actors Description Preconditions Post conditions Normal Course

Alternative Courses Exceptions

Includes Priority Frequency of Use Business Rules Assumptions Notes and Issues

UC-3 Use Case Name Subir un archivo Edgar Salas Garita Last Updated By Edgar Salas Garita 13/09/2011 Date Last Updated 13/09/2011 Profesores y Administrativo El profesor o administrativo seleccionan un archivo y el sistema de encarga de obtener dicho archivo y guardarlo en la base de datos. 1. El actor debe tener una sesión activa. 1. El archivo de estar guardado en la base de datos de la página web 1.0 El actor selecciona un archivo. 2. El actor solicita subir el archivo. 3. El sistema verifica el archivo. 4. El sistema hace una copia del archivo y lo guarda en base de datos 5. El sistema muestra el mensaje : “El archivo fue subido con éxito” No aplica. 1.0. E1. Archivo no encontrado (en paso 3). 2. El sistema muestra el mensaje: “El archivo seleccionado no se ha encontrado”. 3. El sistema solicita al usuario volver a intentarlo. 4. El sistema vuelve a iniciar el flujo normal de acciones. 5. El usuario decide salir. 6. El sistema termina el caso de uso. 1.0. E2. Archivo no se puede acceder(en paso 4) 2. El sistema muestra el mensaje: “El archivo no puede ser accedido en este momento” 3. El sistema solicita al usuario volver a intentarlo. 4. El sistema vuelve a iniciar el flujo normal de acciones. 5. El usuario decide salir. 6. El sistema termina el caso de uso No aplica Alta Aproximadamente unas 12 veces al día por profesor y unas 5 veces a la semana por parte de los administradores. No aplica No aplica

13

Use Case ID Created By Date Created Actors Description Preconditions Post conditions Normal Course

Alternative Courses Exceptions

Includes Priority Frequency of Use Business Rules Assumptions Notes and Issues

UC-4 Use Case Name Descargar un archivo Edgar Salas Garita Last Updated By Edgar Salas Garita 13/09/2011 Date Last Updated 13/09/2011 Profesores, Administrativo y Estudiantes El profesor, administrativo o estudiante seleccionan un archivo en la página web y el sistema de encarga de proporcionarle dicho archivo. 1. El actor debe tener una sesión activa. 2. El archivo debe existir en la base de datos de la página web. 1. El usuario debe obtener el archivo seleccionado. 1.0 El actor selecciona un archivo. 1. El actor solicita descargar el archivo. 2. El sistema verifica el archivo. 3. El sistema hace una copia del archivo y lo proporciona en base de datos. No aplica. 1.0 E1. Archivo no encontrado (en paso 3). 2. El sistema muestra el mensaje: “El archivo seleccionado no se ha encontrado”. 3. El sistema solicita al usuario volver a intentarlo. 4. El sistema vuelve a iniciar el flujo normal de acciones. 5. El usuario decide salir. 6. El sistema termina el caso de uso. 1.0. E2. Archivo no se puede acceder(en paso 4) 2. El sistema muestra el mensaje: “El archivo no puede ser accedido en este momento” 3. El sistema solicita al usuario volver a intentarlo. 4. El sistema vuelve a iniciar el flujo normal de acciones. 5. El usuario decide salir. 6. El sistema termina el caso de uso No aplica Alta Aproximadamente unas 12 veces al día por profesor y unas 5 veces a la semana por parte de los administradores. No aplica 1. Cada usuario puede descargar archivos subidos por otros usuarios

14

Use Case ID Created By Date Created Actors Description Preconditions Post conditions Normal Course

Alternative Courses Exceptions Includes Priority Frequency of Use Business Rules Assumptions

UC-5 Use Case Name Borrar un Archivo Edgar Salas Garita Last Updated By Edgar Salas Garita 13/09/2011 Date Last Updated 13/09/2011 Profesores y Administrativo El usuario administrativo selecciona un archivo para borrarlo. El sistema busca el archivo y lo elimina de la base de datos. 1. El actor debe tener una sesión activa. 1. El archivo eliminado ya no forma parte del contenido de la página web 1.0 El actor selecciona un archivo. 2. El actor solicita al sistema borrar el archivo. 3. El sistema identifica el archivo. 4. El sistema borra el archivo. 5. El sistema muestra el mensaje : “El archivo fue eliminado con éxito” No aplica. No aplica No aplica Alta Aproximadamente unas 4 veces al día por profesor y unas 2 veces al mes por parte de los administradores. No aplica 1. Los administrativos puede borrar archivos de otros usuarios. 2. El profesor solo puede borrar los archivos que el subió con anterioridad.

Notes and Issues

15

Use Case ID Created By Date Created Actors Description

Preconditions Post conditions Normal Course

Alternative Courses Exceptions

Includes Priority Frequency of Use Business Rules Assumptions Notes and Issues

UC-6 Use Case Name Registrar un Usuario Edgar Salas Garita Last Updated By Edgar Salas Garita 13/09/2011 Date Last Updated 13/09/2011 Administrativo El usuario administrativo completa una serie de campos de texto con la información de un nuevo usuario, el sistema se encarga de tomar esta información y crear un nuevo usuario en la base de datos del sistema. 1. El actor debe tener una sesión activa. 1. El sistema guarda un nuevo usuario en la base de datos. 1.0 El actor llenar el formulario en la página web. 2. El actor solicita al sistema crear un nuevo usuario. 3. El sistema verifica que la información este completa y correcta. 4. El sistema crea un nuevo usuario en la base de datos. 5. El sistema muestra el mensaje : “El usuario fue registrado con éxito” No aplica. 1.0 E1. Falta información (en paso 3). 2. El sistema muestra el mensaje: “Hay campos de información que no han sido completados”. 3. El sistema solicita al usuario volver a intentarlo. 4. El sistema vuelve a iniciar el flujo normal de acciones. 5. El usuario decide salir. 6. El sistema termina el caso de uso. 1.0. E2. El usuario ya existe(en paso 4) 2. El sistema muestra el mensaje: “El usuario especificado ya existe.” 3. El sistema solicita al usuario volver a intentarlo. 4. El sistema vuelve a iniciar el flujo normal de acciones. 5. El usuario decide salir. 6. El sistema termina el caso de uso No aplica Alta Aproximadamente unas 15 veces a al año por parte de los administradores. No aplica No aplica

16

Use Case ID Created By Date Created Actors Description

Preconditions Post conditions Normal Course

Alternative Courses Exceptions Includes Priority Frequency of Use Business Rules Assumptions Notes and Issues

UC-7 Use Case Name Borrar un Usuario Edgar Salas Garita Last Updated By Edgar Salas Garita 13/09/2011 Date Last Updated 13/09/2011 Administrativo El usuario administrativo selecciona un usuario de la base de datos para borrarlo. El sistema verifica el usuario y se encarga de eliminarlo de la base de datos junto con la información que esté ligada al mismo. 1. El actor debe tener una sesión activa. 2. El usuario que se va eliminar debe estar registrado. 1. Los contenidos relacionados con el usuario eliminado dejan de existir en la página web. 1.0. El actor selecciona un usuario. 2. El actor solicita al sistema borrar el usuario. 3. El sistema busca toda la información relacionada con el usuario. 4. El sistema borra todo el contenido encontrado. 5. El sistema muestra el mensaje : “El usuario fue eliminado con éxito” No aplica. No aplica No aplica Alta Aproximadamente unas 15 veces a al año por parte de los administradores. No aplica 1. La información relacionada con el usuario borrado ya no era necesaria.

17

Use Case ID Created By Date Created Actors Description

Preconditions Post conditions Normal Course

Alternative Courses Exceptions

Includes Priority Frequency of Use Business Rules Assumptions Notes and Issues

UC-8 Use Case Name Modificar información Edgar Salas Garita Last Updated By Edgar Salas Garita 13/09/2011 Date Last Updated 13/09/2011 Administrativo El usuario administrativo completa una serie de campos de texto con la información sobre como comunicarse con la institución e información acercada de la misma, el sistema se encarga de tomar esta información y crear un nuevo usuario en la base de datos del sistema. 1. El actor debe tener una sesión activa. 1. El sistema guarda la nueva información en la base de datos. 1.0. El actor llenar el formulario en la página web. 2. El actor solicita al sistema agregar la información. 3. El sistema verifica que la información este completa y correcta. 4. El sistema guarda la información en la base de datos. 5. El sistema muestra el mensaje : “El contenido se agregó con éxito” No aplica. 1.0. E1. Falta información (en paso 3). 2. El sistema muestra el mensaje: “Hay campos de información que no han sido completados”. 3. El sistema solicita al usuario volver a intentarlo. 4. El sistema vuelve a iniciar el flujo normal de acciones. 5. El usuario decide salir. 6. El sistema termina el caso de uso. 1.0. E2. La información ya existe(en paso 4) 2. El sistema muestra el mensaje: “La información especificada ya existe.” 3. El sistema solicita al usuario volver a intentarlo. 4. El sistema vuelve a iniciar el flujo normal de acciones. 5. El usuario decide salir. 6. El sistema termina el caso de uso No aplica Alta Aproximadamente unas 15 veces a al año por parte de los administradores. No aplica No aplica

18

2.2.2 Pantalla (s) y/o reporte (s) del CU 2.2.3 Diagrama de actividades del CU UC-1

19

UC-2

20

UC-3

21

UC-4

22

UC-5

23

UC-6

24

UC-7

25

UC-8

26

2.2.4 Diagrama de estados del CU UC-1

UC-2

UC-3

27

UC-4

UC-5

UC-6

28

UC-7

UC-8

29

2.2.5 Diagrama de secuencia del sistema (DSS) UC-1

UC-2

30

UC-3

UC-4

31

UC-5

UC-6

32

UC-7

UC-8

33

2.2.6 Contratos de operaciones 2.2.7 Casos de prueba del CU (Datos entrada y resultados) UC-1: Para este caso de uso únicamente se ingresa un loggin y un password. Si los datos son erróneos, entonces se muestra un mensaje de error, pero si los datos son correctos, el sistema deja ingresar al usuario. UC-2: Para este caso de uso únicamente se necesita estar loggeado como administrador o profesor. Para que este caso de uso termine exitosamente, solo se debe presionar el botón de cerrar sesión, o bien cerrar el navegador donde se muestra la página. UC-3: Para probar este caso de uso se espera subir un archivo. Si el archivo no existe el sistema deberá mostrar un mensaje de error. Este caso de uso se considerara exitoso una ver que aparezca un mensaje diciendo que el archivo se subió exitosamente. UC-4: Para probar este caso de uso se espera descargar un archivo. Si el archivo no existe el sistema deberá mostrar un mensaje de error. Este caso de uso se considerara exitoso una ver que aparezca un mensaje diciendo que el archivo se descargó exitosamente. UC-5: Para probar este caso de uso se espera borrar un archivo subido previamente a la página. Si el archivo no existe el sistema deberá mostrar un mensaje de error. Este caso de uso se considerara exitoso una ver que aparezca un mensaje diciendo que el archivo se borró exitosamente. UC-6: Para probar este caso de uso se llenara un formulario con datos de un usuario, si alguno de estos datos ya está como parte de algún otro usuario, el sistema dirá que el usuario ya existe. Este caso de uso se considerara exitoso una vez que el sistema muestre un mensaje diciendo que se ha registrado un usuario correctamente.

34

UC-7: Para probar este caso de uso se seleccionara un usuario ya registrado. Este caso de uso se considerara exitoso una vez que el sistema muestre un mensaje diciendo que se ha eliminado un usuario correctamente. UC-8: Para probar este caso de uso el usuario deberá llenar un formulario donde se incluye la información nueva y la sección donde esta se debe colocar. En caso de faltar información, el sistema deberá informarlo al usuario, y de igual manera en caso de que la información que se intenta cambiar es igual a la que estaba. Este caso de uso se considerara completo y exitoso cuando se muestre un mensaje diciendo que la información se ha cambiado correctamente.

3. Requerimientos no funcionales 3.1 Producto 3.1.1 Eficiencia: El producto va a requerir un espacio adicional para el almacenamiento de su base de datos, donde la página en sí va a requerir una cantidad diminuta en comparación a su base. El tamaño de la base es dinámico pero se estima un crecimiento aceptable. La base garantizará un acceso rápido a la información y la página actuará de la misma manera donde múltiples usuarios podrán estar con una sesión activa sin problemas. Debido al detalle de cantidad de recursos disponibles que está pendiente, se estimará un promedio de uso para garantizar su óptimo comportamiento bajo dichas condiciones. Tales recursos constan principalmente del espacio destinado para el proyecto y el equipo destinado para la ejecución del mismo. 3.1.2 Interfaz local del usuario: Debido a la naturaleza del proyecto, no se cuenta con una interfaz local del usuario, toda la aplicación involucra una interfaz web.

35

3.1.3 Interfaz web del usuario: Pantalla en la que se ingresa a la página como usuario

3.1.4 Seguridad: El acceso a la página como un usuario registrado será por medio de un nombre de usuario el cual cuenta con una contraseña mínima de 8 caracteres alfanuméricos y máximo de 20, para garantizar la seguridad de los perfiles al igual que la integridad de la página web en sí. La calidad de la contraseña queda a criterio del usuario, ya que el asignará

3.2 Organizacionales 3.2.1 Documentación: La única documentación que se entregará, aparte de la propia del código, será un manual de usuario de la aplicación desarrollada en este proyecto. Dicho manual de usuario se proveerá de manera digital e impresa.

36

3.2.2 Entregas: Se presentará un disco con la aplicación de la página web, y se proveerá con los scripts para la creación de la base de datos, junto con sus debidas instrucciones en un documento también en este disco. Se otorgará un manual de usuario digital y uno impreso, donde el digital irá en el disco junto con la aplicación web y el resto de archivos, y le impreso en sobre adjunto al empaque del disco. 3.2.3 Implementación: Se utilizará el software de MySQL para la elaboración de la base de datos, código HTML para el diseño de la página… 3.3 Externos 3.3.1 Interoperabilidad: La aplicación web interactuará con una base de datos previamente creada y asociada a la misma aplicación web. No se involucrará terceros de ningún tipo en la ejecución normal de la página web. 3.3.2 Legales: El presente proyecto está bajo derechos de autor de los integrantes desarrolladores, actuales activos del Instituto Tecnológico de Costa Rica, y del Instituto Tecnológico de Costa Rica. El software utilizado para el desarrollo del proyecto es OpenSource y se rige bajo los derechos de la GNU GPL.

APENDICES 1. Plan del proyecto 2. Glosario de términos y abreviaturas Término Caso de Uso Diagrama de Secuencia del Sistema Especificación de Requerimientos de Software Global Public License Internet Explorer

Abreviatura CU DSS ERS GPL IE

37

3. Lista de riesgos a. Requiere acceso constante a internet para que la información del sitio sea de utilidad. b. Si la página no se actualiza periódicamente, quedarán en desuso y se volverá obsoleta e inútil. c. El hecho de que un miembro de los desarrolladores del proyecto deserte. 4. Descripción de la institución La institución es el Liceo Nocturno de Ciudad Colón, el cual está bajo el actual régimen del director Geovanny López Mena. Está institución se encuentra bajo el departamento educativo del gobierno. Dicha institución imparte educación secundaria y se encuentra en la región de Ciudad Colón, San José. Se puede contactar a la institución por medio del teléfono: 2249-1117. En caso de requerir contactar al director, se puede intentar localizar a través del teléfono de la institución o a través del correo: [email protected].

5. Especificación de estándares de programación

6. Minutas

38

39

40

41

42

43

44