| SDS Ref | Implementation Plan Ref | Requirement | Outcome | Notes |
| 4 | | SDS processes map to BRD requirements | Pass | |
| 7 | | All database tables mentioned in the SDS are on DEV | Pass | There are several more tables on DEV which are not mentioned in the SDS, but these are not in the Implementation Plan.
The SDS and implementation plan mention an identical set of tables, except that the:
BBLMI_LOGS
PILOT_COURSES (the developer says this was a late addition)
tables are listed in the implementation plan but not in the SDS |
| 7.1 | 2.2.1 | STUDENT_GRADEBOOK_DATA table has been created as specified | Pass | |
| 7.2 | 2.2.1 | COHORT_GRADEBOOK_DATA table has been created as specified | Pass | |
| 7.3 | 2.2.1 | gradebook_view_for_BI view has been created as specified | Pass | some differences in the fields selected, but developer clarifies that:
All code in the SDS is from the R&D phase and should be viewed as 'pseudo code'
DEV has GRADEBOOK_ID NVARCHAR2(333)
Implementation Plan has GRADEBOOK_ID NVARCHAR2(666)
Developer explained that running the same DDL (which does not have any field specification) twice gave different field sizes |
| 7.4 | 2.2.1 | STUDENT_ACTIVITY_DATA table has been created as specified | Pass | |
| 7.5 | 2.2.1 | COHORT_ACTIVITY_DATA table has been created as specified | Pass | |
| 10.1 | | SQL for 'Extracting the score of the latest graded attempt from the gradebook'
roughly matches that in procedure find_all_grades_of_course on DEV | Pass | |
| 10.2 | | SQL for 'Extracting user activity'
roughly matches that in procedure find_all_activity_of_course on DEV | Pass | The SQL in SDS v0.4 includes the condition
users.user_id LIKE 's12%'
Developer has added a note to SDS v0.5 to explain |
| 10.3 | | SQL for 'Aggregating Cohort Score data'
roughly matches that in procedure find_cohort_grades on DEV | Pass | |
| 10.34 | | SQL for '10.4 Aggregating Cohort Activity data'
roughly matches that in procedure find_cohort_activity on DEV | Pass | |
| 4.1.5 | | running LEARN_ANALYTICS_CONTROL.run_all populates the four tables:
COHORT_ACTIVITY_DATA
COHORT_GRADEBOOK_DATA
STUDENT_ACTIVITY_DATA
STUDENT_GRADEBOOK_DATA
with data which looks reasonable | Pass | |
| | 2.1 | Database: GENDEV | Pass | |
| | 2.1 | Schema: BBLMI | Pass | |
| | 2.1 | BBLEARN user to connect as: BBLMILINK | Pass | |
| | 2.1 | DB link: MI2BBLLINK.IS.ED.AC.UK | Pass | |
| | 2.1 | Connects to BBLDEV | Pass | |
| | 2.1 | BBLEARN role to GRANT privileges to: BBLMI_LINK | unknown | user permissions don't allow me to verify |
| | 2.1 | BI Suite user: BOBBLMIUSER | unknown | couldn’t find user in InfoKeep |
| | 2.1 | BI Suite role: BBLMI_USER | unknown | couldn’t check as couldn't find user in InfoKeep |
| | 2.5 | The table PILOT_COURSES must be populated with the COURSE_IDs of the courses we want to process | Pass | |
| | 2.2.3 | BBLMI_UTILS package exists | Pass | |
| | 2.2.3 | LEARN_ANALYTICS_CONTROLS package exists | Pass | |
| | 2.2.3 | LEARN_ANALYTICS_TOOLS package exists | Pass | 2 procedures in learn_analytics_tools are not called directly or indirectly from LEARN_ANALYTICS_CONTROL.run_all:
find_all_logins_of_student
find_all_forum_act_of_student
Clarification from developer:
'These are leftovers from the R&D process. Something similar will be need for phase 2 so I haven't removed them.' |
| | 2.4.2 | The scheduler job: run_analytics2 has been set up
to run every 2 days at 5am.
It calls the starting point:
BBLMI.LEARN_ANALYTICS_CONTROL.RUN_ALL | Pass | |
