Clases de Soportes

1.3. Lista de requerimientos

Propuesta de Proyecto

ALNUS

GluBit

“pequeños detalles…grandes diferencias”

Integrantes

Thomas Eduardo Ernstorfer Miranda

ternstor@inf.utfsm.cl (09) 93188226

Gabriela Patricia Montenegro Tapia

gmontene@inf.utfsm.cl (09) 84135459

Rafael Ignacio Plaza Muñoz (Jefe de proyecto)

rplaza@inf.utfsm.cl (032) 2726690

David Alexis Vega Regollo

dvega@inf.utfsm.cl (09) 89804665

 

 

 

Problema:

Un grave problema en las aulas chilenas de la actualidad es la poca interacción, análisis y corrección de las actividades realizadas por los alumnos en el mismo horario de clases. Esta situación impide que ellos puedan aprender tanto de sus errores, como de los de sus compañeros, mediante la corrección efectuada por su profesor. De esta forma los computadores que tienen los liceos chilenos no son utilizados de una manera que sea útil para el aprendizaje, y terminan siendo usados en labores más bien administrativas o como buscadores de información para los alumnos. O sea, existe tecnología pero esta no ha podido ser utilizada para apoyar el proceso de aprendizaje sobre todo dentro de la sala de clases.

1.2. Idea Central

“Software para desarrollar en forma dinámica actividades y ejercicios en la sala de clases, con la posibilidad de almacenar digitalmente tanto el desarrollo de los alumnos como las correcciones que pudiera hacer el profesor.”

1.3.1. Requerimientos funcionales propios del producto

1. Administrar preguntas y actividades, con sus respectivas fuentes de información y su asociación basada en las respuestas.

2. Almacenar los desarrollos de los alumnos ingresados mediante tableta digitalizadora.

3. Generar evaluaciones en base a preguntas almacenadas en la base de datos.

4. Corrección automática de evaluaciones y facilidades para la corrección manual.

5. Personalizar las fuentes de información disponibles para actividades según modalidades de trabajo.

6. Permitir el acceso a los resultados de las actividades en forma remota, a través de Internet.

1.3.2. Requerimientos funcionales genéricos

7. Control de acceso y funcionalidades basados en los roles de usuario (profesor y alumno).

8. Informes históricos de evaluaciones, actividades y desarrollos del alumno.

1.3.3. Requerimiento funcional distintivo

9. Coordinar despliegue en tiempo real de datos ingresados mediante las tabletas digitalizadoras.

1.3.4. Requerimientos no funcionales distintivo

10. Tiempo de respuesta <= 5 segundos en la sincronización de los datos ingresados por tableta.

11. Funcionamiento en 90% de los navegadores del mercado.

1.4. Riesgos Percibidos

Del negocio:

1. Cambio en la metodología de enseñanza

2. Aparición en el mercado de un producto sustituto

3. Integración con los documentos y material con que cuenta el usuario

4. Que el cliente no gane el financiamiento para la implementación del software

Del proyecto:

1. Mal comprensión de métodos de enseñanza a través de software educativo

2. No disponibilidad de tableta digitalizadora

3. Recursos humanos insuficientes para el desarrollo

4. Mala concepción de las dimensiones del software en la fase de planificación

5. Conflictos dentro del equipo de trabajo

Técnicos:

1. Pérdida de información

2. La tecnología utilizada en el desarrollo no sea adecuada

3. No contar con los recursos físicos para la implementación.

4. Interfaz muy compleja para el usuario final

1.5. Restricciones

A continuación se explicitan las restricciones del proyecto de software detectadas hasta este momento.

Restricciones económicas

En términos de software no existen restricciones económicas para desarrollar este proyecto ya que todas las herramientas a utilizar son libres de costo. Además el software será multiplataforma, es decir, se puede ejecutar bajo entorno Windows y Linux sin discriminación, sólo se necesita un explorador Web. Si hay restricciones económicas en términos de hardware pues para implementar la solución es necesario contar con tabletas electrónicas cuyo costo en el mercado es de alrededor de 20000 pesos chilenos. La sala con 45 computadores no se toma como una restricción pues nuestro cliente cuenta con dos salas de computación completamente equipadas. En el caso, que alguna institución no contará con este equipamiento, entonces si debería considerarse como una restricción el costo de tener que comprar los computadores.

Restricciones tecnológicas

Una restricción tecnológica es el acceso y la calidad de la red que dispondrá nuestro cliente para implementar nuestro software, pues una baja calidad de la red hará que los procesos que deben sincronizarse entre los computadores no lo hagan en tiempo real (o sea menor o igual a 5 segundos según el informe de requerimientos). En términos del software a utilizar no existen muchas restricciones tecnológicas ya que tanto symfony, flash y Red5 son herramientas que se encuentran bien documentadas. Por otra parte, la tableta electrónica es un periférico que se encuentra muy distribuido y no habrá problemas para encontrarlo.

Restricciones culturales

El software esta orientado a profesores y alumnos con una cierta base de conocimientos computacionales. Esta característica es asumida, sin embargo, eventualmente puede transformarse en una restricción importante.

Restricciones legales

Plan de Proyecto Página 10 de 34

El software desarrollado en este proyecto debe cumplir con las normativas legales que impone la ley, junto con brindar beneficios que no transgredan la privacidad de los usuarios. O sea se deben implementar claves para que cada alumno tenga su sección y pueda manejarla.

Restricciones institucionales

El producto del desarrollo de este proyecto debe cumplir con los estándares y reglas de la asignatura de Ingeniería de Software de la Universidad Técnica Federico Santa María.

 

 

 

1.6. Diagrama Entidad- Relaciones

 

Hola,  en  otro momento  redactaré mi saludo al Mundo, ya que hoy tengo sueño…..