The MORE v1 is a planned artifact associated with the MORE project. It builds on the basic ideas demonstrated in the MORE prototype.

Purpose

As with the prototype, the v1 project aims to demonstrate the use of video as a tool for education coupled with a combination of mobile messaging (SMS) and internet technology as a means of interaction between students and teachers.
In contrast to the limited goals of the prototype that was primarily a vehicle for demonstrating technology, the purpose of the v1 project is to produce a robust and complete implementation that can be deployed in a Pilot setting for real users.

Limitations

Specification

Roles

The v1 project can be used by different users who may play the following roles:

1. Administrators: Responsible for installing, customizing, configuring and maintenance of the software
2. Presenter: Responsible for presenting the material of instruction in video format
3. Content Producers: Responsible for adding new content for lessons, where lessons consist of a video and an accompanying set of questions and answers.
4. Teachers: Responsible for picking the actual lesson content for students, evaluating the responses of an individual student as well as of a population of students, and helping out individual students.
5. Facilitator: Responsible for interacting with the software on behalf of the students.
6. Students: Responsible for viewing lesson content and responding to the associated questions.

Note that while in certain situations some roles are not present at all, in other situations multiple roles are played by a single person. In still other situations, some roles may be played by an artificial entity.

Scenarios

The v1 project can be used in the following different scenarios:

1. Local Presenter/Students: A teacher and multiple students are in the same physical location, and the teacher serves as both the presenter of content as well as the facilitator for the software.
2. Remote Presenter, Local Facilitator/Students: The presenter is remote, but there is a facilitator in the same physical location as the students.
3. Remote Presenter/Teacher, Local Students: The presenter and teacher are remote, but the students interact directly with the system through a combination of SMS or an internet browser (the facilitator is the software interface).

Delivery

Like any software product, the artifacts of the v1 project can be delivered in two different ways:

1. In shrink-wrapped fashion with the attendant costs of installation, customization and maintenance
2. In a Software-As-A-Service (Saas) fashion. While this makes the software more easy to use by end users, it imposes a significant implementation overhead on Unamesa.

It is important to settle on how the software will be delivered fairly early in the process of developing the project.

User Interactions

Each user of the v1 project can interact with the software in the following different ways.

1. Administrators: Many interactions of an administrator are different in shrink-wrapped and SaaS products. There are, however, several common interactions:
   1. Security: Creating users, associating users with roles.
   2. Analysis: Producing reports on the overall use of the system.
2. Presenter: A presenter might be a passive participant whose lectures are recorded, or an active participant who records a video specifically for the MORE project. In either case the following interactions should be supported:
   1. Browse all the videos in the system
   2. Upload a new video
   3. Modify a pre-existing video
3. Teacher:
   1. Browse all the videos in the system
   2. Upload a new video
   3. Modify a pre-existing video
   4. Add questions and answers to lessons
   5. View students' responses
4. Facilitator:
   1. Plays the video
   2. Gives out tests to the students and corrects the tests
   3. Enters student responses online or thro's SMS

Constraints

The implementation of the v1 project should accommodate the following constraints:

1. Shared Records Storage: wherever possible, data should be kept securely in a record

Design

High-Level Design

System Model
A generalized view of the overall system with entities for the people, devices, and content.

• current draft - MORE System Model v1

Back-End Data Model
The MORE back-end data model presents an abstract view of the required entities for defining tests and capturing student responses.

• data model - MORE Data Model v1
• component model - MORE Server Model v1

Architecture Stack

Low-Level Design