Prototype Report

LEMA Pilot School Integrated Scheduling System

Team No. 12

Name / Primary Role / Secondary Role
Neelima Agarwal / Life Cycle Planner / Project Leader
Aakash Shah / Prototyper / Feasibility Analyst
Madhulika Mazumdar / Operation Concept Engineer / Project Leader
Harsimran Singh Benipal / Requirements Engineer / Life Cycle Planner
Eunyoung Hwang / Software Architect / Requirements Engineer
Louis Demaria / IIV&V / Developer
Tianyin Zhou / Developer / IIV&V

12/05/11

Prototype Report Version 4.0

Version History

Date / Author / Version / Changes made / Rationale /
10/12/11 / A.S. / 1.0 / First draft – basic prototypes in use documented. / For Core FC package, first draft of the prototype document
10/17/11 / A.S. / 2.0 / Completed the entire document for the currently important prototype pages / With respect to current risks, the important points have been prototyped and documented here
10/24/11 / A.S. / 2.1 / Modified earlier version’s navigation flow / Feedback from ARB session incorporated into the document
11/21/11 / A.S. / 3 / Updated Prototype with COTS details added / The COTS that will be used for scheduling is an important piece of the project and is important to show to the clients that it does the job well.
12/05/11 / A.S. & T.Z. / 4.0 / Updated the REST based service modeled and also the export functionality / At the end of the DCR ARB all prototyped parts have been updated in the document.

Table of Contents

PRO_DCP_F11a_T12_V4.0 Version Date: 12/05/11

Prototype Report Version 4.0

Prototype Report i

Version History iii

Table of Contents iv

Table of Tables v

Table of Figures vi

1. Introduction 1

1.1 Purpose of the prototype report 1

1.2 Status of the prototype 1

2. Navigation Flow 2

3. Prototype 3

PRO_DCP_F11a_T12_V4.0 Version Date: 12/05/11

Prototype Report Version 4.0

PRO_DCP_F11a_T12_V4.0 Version Date: 12/05/11

Prototype Report Version no. 4.0

Table of Tables

PRO_DCP_F11a_T12_V4.0 Version Date: 12/05/11

Prototype Report Version no. 4.0

Table 1: Screenshot name-1 3

Table 2: Student Course Preference Issues 5

PRO_DCP_F11a_T12_V4.0 Version Date: 12/05/11

Prototype Report Version no. 4.0

Table 1: Screenshot name-1 3

Table 2: Student Course Preference Issues 5

PRO_DCP_F11a_T12_V4.0 Version Date: 12/05/11

Prototype Report Version no. 4.0

Table of Figures

1. Introduction

1.1 Purpose of the prototype report

The purpose of this document is to be able to continuously evaluate our proposed system and make sure it is perfectly in line with the client’s ideas. A prototype will be able to eliminate all the differences that we have across clients and developers.

1.2 Status of the prototype

This is Version 3.0 of the document. In this version, we have added the prototyping for the COTS product itself. This is important from the scheduling point of view as the clients will be assured of a working, free of the shelf product that suits their needs.

A.1.  Navigation Flow

2. Prototype

In this project there are a few critical pieces and that is more with respect to Student Entry and Counselor overview. Since they are all inexperienced and first time users so the system has to be intuitive for them and this is a major point. Also for the clients this is one of the first high priority items that they can take a look and feel of. Thus these two points have been documented here.

Table 1: Screenshot name-1

Description / Student is able to view his/her current A-G level, number of courses completed, number of them remaining, etc. Also the student can view all courses taken so far so as to get a clear and holistic view on where they stand.
Related Capability / OC – 4, OC 6
Pre-condition / The log in screen takes us to this page and this page will act as the hope page for the students.
Post condition / Students can request new courses from here or can also ask for which college can they go to with their current marks. (Request for courses is Prorotype#2)

Figure 1: Screenshot of Student Profiler 1

This use case is for students to input courses and counselors to review them, reject and approve as can be done.

Table 2: Student Course Preference Issues

Description / The students use this screen to be able to decide what courses they want in the next semester. The counselor can use the same screen to be able to review the same and approve or reject the choices for the students.
Related Capability / OC – 4 , OC 6
Pre-condition / The Screenshot#1 or the student profile home page can lead to this page. Also a counselor home page can lead to this.
Post condition / None. From here go back to the previous page.

Figure 2: Course input page

Table 3: Principal Scheduler Entry Page

Description / The principal/scheduler uses this screen to be able to input all the data into the system and also view and update the inputted data. This data includes Student details, Teacher details, Course Details and other misc. information
Related Capability / OC 5, OC 6
Pre-condition / The login page for the principal/scheduler will lead to this page
Post condition / From here, navigate to student data entry, course data entry, teacher data entry and other misc. information entry.

Figure 3: Principal / Scheduler input page

Table 4: Student Data input page

Description / The principal/scheduler uses this screen to be able to input all the data into the system and also view and update the inputted data – for all students. Also this can be viewed year wise.
Related Capability / OC 5, OC 6
Pre-condition / The home page for the principal/scheduler will lead to this page.
Post condition / None. From here we can go back to the home page for the principal/scheduler.

Figure 4: Student data input page

Table 3: COTS Generate Schedule Page

Description / The head scheduler can import the teacher data into the COTS i.e. FET – a Free timetabling software licensed under the GNU license. Using the current COTS page, the scheduler (APSCS) can actually generate a teacher schedule which will look like the nezt figure attached below.
Related Capability / OC – 1, OC – 2
Pre-condition / The teacher – course – activity data (exported from the system as a .csv file) has been imported into the COTS.
Post condition / The head scheduler gets a generated schedule for the teachers which will then be fed into Columbia – a legacy system that maps the efficiency of our system and allows the Scheduler to add more constraints to our system to get a better schedule.


This figure shows us the Generation Options – We can also generate multiple schedules here.


This gives us a view of the Teacher's schedule.

We can view the teacher's schedule on a per teacher basis.

We can also view the various conflicts (if any) in the system that were encountered.

Table 4: COTS Input Constraints Page

Description / The head scheduler can add constraints into the system that will help her schedule the teacher's times clearly and cleanly.
Related Capability / OC – 1, OC – 2, OC – 3
Pre-condition / The teacher – course – activity data (exported from the system as a .csv file) has been imported into the COTS.
Post condition / The head scheduler gets a generated schedule for the teachers which will then be fed into Columbia – a legacy system that maps the efficiency of our system and allows the Scheduler to add more constraints to our system to get a better schedule.


This gives us a view of all the various constraints that can be added for any teacher.

Now let us say we add the constraint that Scott can only teach on Fridays from 8 AM to 10 AM. The schedule must keep that in mind before generating a viable schedule.


The generated schedule now is :



Table 6: REST based service – Interaction with the Team 4 system

Description / Team 4’s system – Family Accountability System can actually speak to our system using REST based queries. So we have to expose our DB values via the REST based interface to them.
Related Capability / OC – 7
Pre-condition / Course information has been fed into the system – the schedule has been generated and imported into the system.
Post condition / The Family Accountability system gets the course details requested on the basis of the user level security.

Query String:

http://localhost:52878/Services/SchedulerDataService.svc/course_detail

Actual REST output:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>

- feed xml:base="http://localhost:52878/Services/SchedulerDataService.svc/" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom">

title type="text">course_detail</title

idhttp://localhost:52878/Services/SchedulerDataService.svc/course_detail</id

updated2011-12-06T05:23:27Z</updated

link rel="self" title="course_detail" href="course_detail" />

- entry

idhttp://localhost:52878/Services/SchedulerDataService.svc/course_detail('1')</id

title type="text" />

updated2011-12-06T05:23:27Z</updated

- author

name />

</author

link rel="edit" title="course_detail" href="course_detail('1')" />

category term="lemaModel.course_detail" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme" />

- content type="application/xml">

- m:properties

d:id1</d:id

d:bubbleNum123A</d:bubbleNum

d:courseNameEnglish 9A</d:courseName

d:numOfCredits m:type="Edm.Int32">5</d:numOfCredits

d:requirementTypeC</d:requirementType

d:gradeLevel m:type="Edm.Int32">9</d:gradeLevel

d:semester m:type="Edm.Int32">2</d:semester

d:courseTypeIdM</d:courseTypeId

d:LEMARequirementY</d:LEMARequirement

</m:properties

</content

</entry

- entry

idhttp://localhost:52878/Services/SchedulerDataService.svc/course_detail('2')</id

title type="text" />

updated2011-12-06T05:23:27Z</updated

- author

name />

</author

link rel="edit" title="course_detail" href="course_detail('2')" />

category term="lemaModel.course_detail" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme" />

- content type="application/xml">

- m:properties

d:id2</d:id

d:bubbleNum456B</d:bubbleNum

d:courseNameEnglish 9B</d:courseName

d:numOfCredits m:type="Edm.Int32">5</d:numOfCredits

d:requirementTypeC</d:requirementType

d:gradeLevel m:type="Edm.Int32">9</d:gradeLevel

d:semester m:type="Edm.Int32">2</d:semester

d:courseTypeIdM</d:courseTypeId

d:LEMARequirementY</d:LEMARequirement

</m:properties

</content

</entry

</feed

Table 7: Export to Excel functionality (CSV)

Description / The COTS – FET needs to be given the input in a CSV format. This is the format in which we need to be able to export our files.
Related Capability / OC – 7
Pre-condition / Course information has been fed into the system; the students have asked for courses and the counselors have already assigned courses to the students. Also the Head scheduler has assigned teaches for every class section.
Post condition / The FET generates a schedule for us from the inputs given.

The code for the same:

public void ProcessRequest (HttpContext context) {

//Comment out these lines first:

//context.Response.ContentType = "text/plain";

//context.Response.Write("Hello World");

//Retrieve the Query String, ID

//Query the Database

//Generate the csv file

string outputFile = @"F:/IIS/sample.csv";

System.IO.StreamWriter ofile;

if (System.IO.File.Exists(outputFile))

{

ofile = new System.IO.StreamWriter(outputFile, true);

}

else

ofile = new System.IO.StreamWriter(outputFile);

ofile.Close();

context.Response.Clear();

context.Response.ContentType = "application/octet-stream";

context.Response.AddHeader("Content-Disposition", "attachment; filename=sample.csv");

context.Response.WriteFile(HttpContext.Current.Server.MapPath("~/sample.csv"));

context.Response.End();

}

PRO_DCP_F11a_T12_V4.0 Version Date: 12/05/11