informe srs final

PROYECTO: AVISO DE ATRASO DE DOCENTES - Grupo B

18-07-2014Revisión [2]

PÁG. 1PROYECTO: AVISO DE ATRASO DE DOCENTES - Grupo B

_____________________________________________________________________________

Historial de Revisiones

Fecha Revisión Descripción Autor16/06/2014 1.0 "Análisis de

requerimientos funcionales"

Maximiliano Ramos

16/06/2014 1.0 "Análisis de Requerimientos de hardware"

Maximiliano Ramos

16/06/2014 1.0 "Pruebas de Interfaces"

Maximiliano Ramos

16/06/2014 1.0 "Estimaciones de costos"

Edison Pizarro

16/06/2014 1.0 "Análisis de plataformas "

Kevin Moreno

17/06/2014 1.0 "Análisis de código" Edison Pizarro17/06/2014 1.0 "Segunda estimación

de costos"Maximiliano Ramos

18/06/2014 1.0 "Prueba de prototipos funcionales"

Edison Pizarro

19/06/2014 1.0 "Tercera estimación de costos"

Ian Aspee

19/06/2014 1.0 "Diseño de Interfacez"

Edison Pizarro

ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE


_____________________________________________________________________________

Índice:

HISTORIAL DE REVISIONES...........................................................................................................11.1 Propósito 31.2 Alcance 31.3 Personal involucrado 41.4 Acrónimos y abreviaturas 51.5 Referencias 51.6 Resumen 5

2 DESCRIPCIÓN GENERAL....................................................................................................62.1 Perspectiva del producto 62.2 Funcionalidad del producto 62.3 Características de los usuarios 72.4 Restricciones 72.5 Suposiciones y dependencias 82.6 Evolución previsible del sistema 8

3 REQUISITOS ESPECÍFICOS................................................................................................93.1 Requisitos comunes de las interfaces 11

3.1.1 Interfaces de usuario....................................................................................................113.1.2 Interfaces de hardware.................................................................................................113.1.3 Interfaces de software..................................................................................................113.1.4 Interfaces de comunicación..........................................................................................12

3.2 Requisitos funcionales 123.2.1 Requisito funcional 1....................................................................................................123.2.2 Requisito funcional 2....................................................................................................123.2.3 Requisito funcional 3....................................................................................................12

3.3 Requisitos no funcionales 123.3.1 Requisitos de rendimiento............................................................................................133.3.2 Seguridad..................................................................................................................... 133.3.3 Fiabilidad...................................................................................................................... 133.3.4 Disponibilidad...............................................................................................................133.3.5 Mantenibilidad...............................................................................................................133.3.6 Portabilidad................................................................................................................... 14

4 APÉNDICES......................................................................................................................... 15



_____________________________________________________________________________Introducción

Este informe del sistema está enfocado en la aclaración de los requisitos del software para que sea implementado en la institución educativa Inacap .El presente documento ha sido documentado por profesionales actuales en el área para que su aplicación este a prueba de posibles errores que se esperan en una primera implementación. La presente ERS cumple las directrices establecidas por el estándar “IEEE RecommendedPracticefor Software RequirementsSpecification ANSI/IEEE 830-1998”.

1.1 Propósito

El principal propósito del documento es que se refleje de manera estandarizada el historial de trabajo que hemos desarrollado cómo grupo al momento de ir avanzando en el proyecto de software, dando a conocer detalles dentro de la organización y planificación del trabajo una vez desarrollado y a la vez que quede plasmado en papel la forma en que hemos trabajado.

1.2 Alcance

Esta especificación de requisitos está dirigida al usuario del sistema, para continuar con el desarrollo de aplicaciones administrativas y de docentes sobre la institución y para profundizar en la automatización de ésta, la cual tiene por objetivo principal el gestionar el proceso de aviso de inasistencia docente.



_____________________________________________________________________________1.3 Personal involucrado

Nombre Maximiliano Ramos NazerRol QUACategoría profesional Ingeniero en InformáticaResponsabilidades - Diseño

- Casos de pruebas- Estimaciones de costos- Compra de HW- Toma de requerimientos- Diseño de interfaces

Información de contacto Celular: +56982333309Email : [email protected]

Nombre Edison PizarroRol ProgramadorCategoría profesional Analista ProgramadorResponsabilidades - Toma de requerimientos de los clientes

- Generar código de prototipos- Compras de HW

Información de contacto Celular: +56973850827Email: [email protected]

Nombre Kevin MorenoRol QUACategoría profesional Analista ProgramadorResponsabilidades - Diseño de interfaces

- Casos de prueba- Toma de requerimientos- Compras de HW

Información de contacto Celular: +56985997966Email: [email protected]

Nombre Ian AspeeRol ProgramadorCategoría profesional Analista ProgramadorResponsabilidades - Programación de prototipos

- Diseñó de interfacesInformación de contacto Celular: +56977027416

Email: [email protected]



_____________________________________________________________________________1.4 Acrónimos y abreviaturas

SMTP Simple Mail Transfer Protocol

HTTP HyperText Transfer Protocol

HTML HyperText Markup Language

FTP File Transfer Protocol, Protocolo

SMS Short Message Service

LAN Local Area Network

LCD Liquid Crystal Display

LED Light-Emitting Diode

IEEE Institute of Electrical and Electronics Engineers

BD Bases de datos

1.5 ReferenciasReferencia Titulo Ruta Fecha Autor

ingeniería de software 10/07/2014 Sommerville

Análisis y diseño detallado de aplicaciones informáticas de gestión

10/07/2014 piattini

1.6 Resumen

Este documento explica cómo se desarrollará este nuevo sistema para una mejor gestión de asistencia y aviso de docentes .En la primera sección por título Contenido se da a entender lo que solucionará este sistema y como lo hará. En la segunda sección título Descripción general de da a conocer como se desenvolverá el producto en el ambiente físico y que se estimó como Inacap Valparaíso.



_____________________________________________________________________________

2 Descripción general

La visión general de nuestro proyecto en palabras más simples sería avisar de manera más eficiente cuando un docente llegue atrasado; Usando un TI encontramos la manera más eficiente de solucionar el problema actual, para esto desarrollamos diferentes estudios de que es lo Inacap necesita.

El sistema debe ser capaz de avisar el atraso de un docente automáticamente ya sea que el docente de aviso a través de su computador personal en su residencia vía web o informando por teléfono a coordinación docente para que el de aviso a través del sistema, de manera tal de que los alumnos se enteren en tiempo real del atraso.

2.1 Perspectiva del productoNuestro producto es independiente debido a que no consta de la interacción con otros productos software como servidor web, software de acceso a redes TCP/IP.En resumen se puede decir que nuestro software es simple pero auto-suficiente, y que por lo tanto este no pertenece a un sistema mayor.

.

2.2 Funcionalidad del producto

Principalmente el sistema debe poder realizar el aviso en tiempo real de cuando un docente valla a llegar atrasado, para eso cada sala debe contar con una pantalla LED básica, esta pantalla será conectada con nuestro sistema principal en el cual tendrá cómo opción principal de seleccionar los datos del profesor en 3 “combo box” que contienen el nombre del profesor, la sala, y el rango de tiempo en que el profesor debiese llegar a la clase, esta información será mostrada en la pantalla LED anteriormente nombrada. Para hacer uso del sistema principalmente el docente o encargado deberá ingresar con su RUT y contraseña institucional y en caso de no tener deberá acercarse a un encargado del sistema para autorizarlo y registrar su información para el uso del sistema.



_____________________________________________________________________________

2.3 Características de los usuariosTipo de usuario Coordinador docenteFormación TécnicaHabilidades Utilizar el sistema principal.Actividades -Tomar información de los docentes.

-Dar aviso en tiempo real a los alumnos a través del sistema.-Dar aviso en caso de que un docente o coordinador no esté registrado en el sistema.

Tipo de usuario DocenteFormación Profesional Habilidades Utilizar sistema principalActividades -Dar aviso a través de su celular en coordinación

de docentes cuando vaya a llegar atrasado.-Ingresar al sistema vía web e informar atraso directamente.

2.4 Restricciones

Interfaz para ser usada con internet. Uso de Dominio Inacap.cl Lenguajes y tecnologías en uso: HTML, JQuery, JavaScript. Los servidores deben estar disponibles para las consultas de los usuarios. El sistema se basa en un modelo Cliente/Servidor. El sistema debe ser multiplataforma.



_____________________________________________________________________________

2.4 Restricciones

El sistema se desenvolverá en plataforma web html5 de escritorio. Se usara un login y contraseña utilizando su Rut como login. El horario crítico de disponibilidad será las 24 horas de lunes a viernes, será ocupado solo por docentes para el ingreso de datos. Los alumnos solo tendrán acceso a información sobre atrasos.

Sistema “ElAtraso” podrá ser ocupado tanto en el establecimiento intranet y en extranet desde las dependencias de los docentes.

Deberá contar con un hardware con los requisitos mínimo que opera una página web

Condiciones técnicas mínimas para la instalación

· Windows 2000 Sp4, Windows XP SP2, Windows Vista o superior.

· MAC OS 10.5 Leopard o superiores.

· Procesador mínimo 500 Mhz, recomendado 1Ghz o superior.

· Memoria: 128 MB de RAM o más.

· Mínimo espacio libre en disco duro 300 MB.

· Resolución de Pantalla mínima 800x600

2.5 Suposiciones y dependencias Se asume que los requisitos aquí descritos son estables Los equipos en los que se vaya a ejecutar el sistema deben cumplir los requisitos antes

indicados para garantizar una ejecución correcta de la misma

Para la interfaz de usuario para docentes y/o coordinación docente, deberá ingresar la siguiente información:

Nombre Docente. Sala. Rango Tiempo Llegada.

El sistema funcionara en plataforma web, para plataformas móviles ya sea Android, Windows pone, ios, deberá ser usando mediante el navegador predeterminado del teléfono inteligente.

2.6 Evolución previsible del sistema

El sistema podrá actualizarse según requiera ya sea por nuevas tecnologías como sistema biométrico o algún tipo de escáner con precios más accesibles que hoy en día ya que sus costos son elevados. También podrían existir pequeñas pantallas en cada sala y no solo una por piso todo esto con un análisis de factibilidad a cargo del equipo de mantenimiento.



_____________________________________________________________________________

3 Requisitos específicos

Requerimientos Funcionales

Identificación del requerimiento:

RF01

Nombre del Requerimiento:

Autentificación de Usuario

Características: Los Docentes deberán estar registrado en intranet para poder acceder a la configuración del mensaje.

Descripción del requerimiento:

El sistema podrá ser consultado solo por el usuario que se encuentre con la sesión de intranet iniciada.

Prioridad Muy alta

Identificación del requerimiento

RF02

Nombre del requerimiento

Velocidad de respuesta

Característica Tiempo en que demora el sistema en mostrar el mensaje en las pantallas

Descripción del requerimiento

En el momento en que el coordinador docente o el mismo docente Envía el mensaje para ser mostrado, tiene que reflejarse en tiempo real, actualizar automáticamente.

Prioridad Muy alta

Identificación del requerimiento

RF03

Nombre del requerimiento

Datos a mostrar

Características El sistema muestra los datos requeridos para el mensajeDescripción del requerimiento

El sistema en su segunda interfaz deberá mostrar 3 "ComboBox" uno mostrará los nombres que se podrán filtrar por su iniciar, el número de la sala y por último el rango de tiempo en que deberían llegar a la sala.

Prioridad Muy Alta



_____________________________________________________________________________

Requerimientos No Funcionales.

Identificación del requerimiento: RNF01Nombre del Requerimiento: Interfaz del sistema.Características: El sistema tendrá unas interfaces simples, para que

el usuario interactúe.Descripción del requerimiento: El sistema debe tener una interfaz de uso intuitiva, y

fácil de usar.Prioridad Muy Alta

Identificación del requerimiento: RNF02

Nombre del Requerimiento: Pre-Visualización del mensaje

Características: Cuadro de texto que mostrara una pre-visualización del mensaje tal cual como estará reflejado en la pantalla

Descripción del requerimiento: La interfaz de selección de ComboBox mostrará un cuadro de texto en el cual se mostraran los datos seleccionados en el ComboBox.

Prioridad Media

Identificación del requerimiento RFN03

Nombre del Requerimiento Datos mostrados en pantalla

Características "ComboBox" que almacenan los tres datos a mostrarDescripción del requerimiento El sistema deberá contar con "ComboBox" que

almacenen el nombre del docente, número de sala y rango de tiempo que será usado para mostrar el mensaje en pantalla

Prioridad del requerimiento Muy Alta

Identificación del requerimiento RFN04Nombre del Requerimiento Enviar datosCaracterísticas Al presionar botón enviar el sistema deberá enviar los

datos a pantallaDescripción del requerimiento La segunda interfaz tendrá un botón "Enviar", al

presionar dicho botón se deberá enviar en tiempo real los datos.

Prioridad del requerimiento Muy Alta



_____________________________________________________________________________

3.1 Requisitos comunes de las interfaces

La interfaz principal la cual tendrá acceso el docente o el coordinador docente principalmente lo que tendrá será un login como primera interfaz en la cual tendrá que ingresar con su Rut y contraseña institucional en caso de no poseer la cuenta la deberá ingresar un analista a cargo del sistema por cuestiones de seguridad, luego de haber ingresado al sistema el coordinador docente tendrá tres "ComboBox" en los cuales estarán los detalles, el primer ComboBox tendrá el nombre del profesor el cual se puede filtrar, el segundo ComboBox tendrá la sala en la cual debería estar el profesor en ese momento y por último un tercer ComboBox que tendrá el rango de tiempo que se estima la llegada del profesor a la sala correspondiente. Una vez seleccionados todos los datos de los ComboBox se selecciona el botón enviar y este mensaje se refleja en tiempo real en las pantallas colocadas en las salas en este formato: El profesor <nombre del profesor> llegara en aproximadamente <Rango de tiempo>, Por favor espere en la sala. Dicho mensaje aparecerá también en la interfaz de selección como pre-visualización, dicho mensaje no se puede modificar por un tema netamente de que el mensaje este estandarizado y por seguridad, si no se podría escribir lo que sea.

3.1.1 Interfaces de usuario

La interfaz con el usuario consistirá en unas ventanas él cual deberá identificarse mediante su Rut y contraseña, para luego poder acceder a la configuración del mensaje a enviar, donde el usuario interactuara con listas, botones y campos de texto, las ventanas serán visualizadas desde un navegador web.

3.1.2 Interfaces de hardwareSerá necesario tener estos dispositivos para poder acceder a la aplicación.

Adaptadores De Red. Procesador Mínimo 500 MHz, Recomendado 1ghz O Superior. Memoria: 128 Mb De RAM O Más. Mouse. Teclado.

3.1.3 Interfaces de software

Sistema Operativo: Windows XP o superior. Explorador: Mozilla o Chrome.



_____________________________________________________________________________3.1.4 Interfaces de comunicación

Existirá una comunicación de servidores que conectaran los usuarios almacenados los servidores de intranet y los servidores de los mensajes de atrasos, mediante protocolos estándares en internet. Para poder realizar el envió de mensajes a los led que se encuentran en cada sala

3.2 Requisitos funcionales

3.2.1 Requisito funcional 1 Autentificación de Usuarios: los usuarios deberán identificarse en

intranet para poder acceder a la interfaz del envió de mensaje de atrasado

El sistema podrá ser consultado solo por el usuario quese encuentre con la sesión de intranet iniciada.

3.2.2 Requisito funcional 2 Velocidad de Respuesta:El sistema debe ofrecer una respuesta

rápida desde que el docente selecciona enviar el mensaje, enviar inmediatamente a la pantalla led.

3.2.3 Requisito funcional 3 Datos a mostrar:El sistema muestra distintos “ComboBox” que

almacenan el nombre del docente, número de sala y el rango de tiempo que será usado para mostrar el mensaje en las pantallas led instaladas en cada sala.

3.3 Requisitos no funcionales 3.3.3.1 Requisito no funcional 1 :

interfaz de sistema: el sistema deberá estar adecuado para usuario promedio

3.3.3.2 Requisito no funcional 2:

Pre-Visualización del mensaje: caja de texto que muestra el cual solo lo vera el editor


Datos mostrados al usuario: contara con modo de selección de casillas desplegables con nombres de docentes, n° de sala y tiempo estimado que se demorara el docente.


Función del botón enviar: Al ejecutar el botón de enviar, mostrara a los segundos lo que el editor tipéo para ser mostrado en pantalla



_____________________________________________________________________________

3.3.1 Requisitos de rendimientoElAtraso debe dar servicio simultáneamente a los docentes o coordinadores registrados en el sistema que necesiten utilizar el mensaje, para eso debe estar funcionando las 24 horas del día.

3.3.2 Seguridad

Para el ingreso al sistema el Atraso, como seguridad el usuario deberá haber iniciado sesión en la intranet, para luego tener la opción de entrar al sistema, donde se le solicitara el Rut y una contraseña para que la persona pueda realizar sus respectivas operaciones.

3.3.3 Fiabilidad El sistema debe tener una interfaz de uso intuitiva y sencilla

La interfaz de usuario debe estar contenida en la web de la institución, dentro de la cual estará incorporado el sistema de elAtraso.

3.3.4 Disponibilidad

El sistema debe contener un servicio disponible las 24 horas del día y los 7 días de la semana, deberá tener un esquema de sus componentes para evitar fallos y que los usuarios no puedan ingresar al sistema.

3.3.5 Mantenibilidad

La mantención del sistema la deberá realizar un desarrollador del sistema, para realizar aquella mantención se realizaran estudios del funcionamiento del sistema desde la fecha de la entrega hasta el momento de realizar una mantención , una vez que se obtenga toda la información necesaria, teniendo la documentación para poder actualizarla, para un futuro ya contar con la documentación para próximos mantenimientos, La interfaz deberá



_____________________________________________________________________________implementar un sistema de ayuda al usuario para usuarios inexperto o una manual de uso presentarlo a cada usuario que interactuara con el sistema.

3.3.6 Portabilidad

El sistema será implantado bajo la plataforma de Windows.

El sistema será implementado para dispositivos móviles.



_____________________________________________________________________________

4 Apéndices

1. "SWEBOK, Software Engineering Body of Knowledge". 2004.

2. Sommerville, I., "Software Engineering. 6th edition". Addison Wesley. 2000

3. Pressman R.S. "Ingeniería del software. Un enfoque práctico". McGraw-Hill/Interamericana, 5º edición, 2001. Traducido del inglés "Software Engineering: A Practitioner´s Approach", McGrawHill, European adaption.

4. IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications: IEEE, 1998.


informe srs final

Documents