COSC 465/565 Web Project

Introduction

Description of ABET data collection

These student outcomes must be assessed in various courses. For example, COSC 302 might assess outcomes 1, 2, and 6 for CS majors and the senior design course, COSC 402, might assess all 6 outcomes For each outcome assessed by a course, the faculty member assigns each student one of three performance levels-exceeds expectations, meets expectations, or does not meet expectations. The faculty member enters the total number of students achieving each of these three performance levels into a spreadsheet. The spreadsheet named COSC_402_Assessment_Data.xlsx provides an example of such a spreadsheet.

In order to determine which performance level a student has achieved for an outcome, the faculty member must use various types of assessments, which may include labs, homework assignments, test questions, quiz questions, written papers, oral presentations, and any other type of assessment that the faculty member wishes to use. For example, to assess a student's ability to design, implement, and evaluate a computing-based solution to meet a given set of computing requirements a COSC 302 instructor might use some programming assignments and test questions whereas a COSC 402 instructor might choose a team's design document.

For each assessment the faculty member must:

1. Assign a weight from 0.0 to 1.0 which reflects the percentage weight that that assessment carries in assessing the outcome. The weights for each outcome's assessments must sum to 1.
2. Create a "rubric" which provides an explanation of what characteristics the student's work must exhibit in order to be assigned a particular performance level.

Finally a faculty member must provide a narrative for each outcome that describes in general terms the students' strengths and weaknesses on that outcome. The faculty member is also asked to provide some suggested actions that might be taken to improve the students' performance on each outcome assessed in the course. The document entitled COSC_402_Narrative_Summary.docx gives an example of a sample narrative summary that might be prepared by a faculty member.

Project Overview

You will be creating a web-based GUI that allows faculty members to login and enter their ABET data. The interface should allow the faculty member to select their course(s). The interface should display the student outcomes that are assessed in the course and allow the faculty member to enter for each outcome:

1. The number of students exceeding, meeting, or not meeting expectations
2. The assessments used to assess the outcome and the rubrics and weights for each assessment. An instructor is allowed to use the same rubric for multiple assessments, so there should be a way to find a pre-existing rubric.
3. The narrative listing students' strengths and weakness, and suggested actions for improving student attainment of the outcome.

The data will be stored in a MySql database.

The design of the project should be separated into a GUI-frontend that runs in the user's browser and a PhP/MySql backend that runs on a server.

Interaction with the Website

The following bullet points describes the web pages and interactions that an instructor can have with the website.

1. The website's front page will authenticate the user via a username (instructorId) and password.
2. Once authenticated, the instructor will be taken to a web page where they can select a course for which they want to enter student outcomes. The instructor should only be allowed to choose courses to which the instructor is assigned in the SectionCurrent relation.
3. When the instructor selects a course the exising webpage should be augmented with the outcomes listed for that course. When the instructor clicks on one of the outcomes, a form should appear with the following information:
   • The outcome description. This field is non-editable.
   • An outcome reporting section: Widgets in this section should allow the instructor to enter the number of students attaining each performance level for this outcome. The instructor should only be allowed to enter non-negative integers.
   • An assessment section: Widgets in this section should allow the instructor to enter the assessments used to assess this outcome. For each assessment the widgets should allow the instructor to enter the assessment type (e.g., exam, quiz, homework, lab assignment), assessment description (e.g., homework 1 linked lists and homework 3 binary search trees), assessment weight, and a rubric. The assessment weight must be a number between 0 and 1.0 and the combined weights must sum to 1. The assessment type should include a "custom" button that allows the instructor to enter a new type of assessment and a brief description of this assessment. The new assessment type should be added to the AssessmentType relation and henceforth appear as one of the possible assessment types.

     To simplify the instructor's data entry, the instructor should have the option of selecting a pre-existing assessment plan from the database. The web-page should offer all previous and current offerings of the course for this major as options. If the instructor selects one of these options, then this section should be pre-loaded with the assessments from the selected course.

     This section must allow the instructor to add or delete assessments.

     Finally the rubrics may consume a fair amount of screen space so there should be a way to expand them to make them appear and a way to shrink them so that only a widget remains that can be selected to make the rubric expand. You should be able to use JQuery to help you with the animation for doing this. The instructor should have the option of selecting a pre-existing rubric from the Rubric relation or entering a new rubric. If entering a new rubric, the instructor must enter a description for each performance level. No performance level may be left blank.

   • A narrative section: Widgets in this section should allow the instructor to enter the students' strengths and weaknesses for this outcome, and suggested actions for improving students' attainment of this outcome in the future.

   • Save and Cancel buttons: There should be save and cancel buttons that allow the instructor to save their work or discard their work. If an instructor tries to leave the page before saving their work, a dialog box should appear warning them that they have not saved their work and asking them if they would like to save their work.

   If the instructor had previously entered information for this outcome, then that information should be pre-loaded from the database.

   Once the instructor saves or cancels their work, they should be allowed to input data for another outcome for the course by clicking on that outcome. The instructor should also be allowed to switch to another course and enter data for that course.

MySql Database Design

I have already designed the backend mysql database for you and ~bvz/cs465/web_project_abet.sql contains a partial sql file for creating the relations. You need to complete it. If you have questions about the data types for the various attributes in the relations, please check this file, make a reasonable assumption, or ask me. You may not change the names of the relations since we will be using a drop script to delete your tables from our db but you may change the number and/or names of the attributes in the relations to suit your needs. You will see that the names of some of the attributes in the abet.sql file do not exactly match the attribute names in the relations below so clearly we are not concerned if your attribute names exactly match ours.

The relations that you will be using are as follows:

• Instructors(instructorId, firstname, lastname, email, password): You can use this relation to autheticate a user when the user is logging in. Obviously in a real world scenario you would use a more secure authentication procedure but for this assignment you will perform the authentication. instructorId is the instructor's username and the remaining attributes should be self-explanatory.

• Courses(courseId, courseTitle): Contains the assessed courses and their corresponding course titles. For example, the courseId for this course is COSC465 and the courseTitle is "Databases and Scripting Languages".

• SectionsCurrent(sectionId, courseId, instructorId, semester, year): Lists the courses that are being offered in the current semester, the instructor for the course, and the semester/year in which the course was offered. This relation and the relation SectionHistory hold all assessed courses, past and present. The two relations are union compatible.
  • The sectionId is the unique identifier for the tuples in the relation.
  • instructorId is a foreign key into the Instructors relation
  • courseId is a foreign key into the Courses relation.

• SectionsHistory(sectionId, courseId, instructorId, semester, year): Lists the courses that have been offered in past semesters, the instructor for the course, and the semester/year in which the course was offered.
  • The sectionId is the unique identifier for the tuples in the relation.
  • instructorId is a foreign key into the Instructors relation
  • courseId is a foreign key into the Courses relation.

• Outcomes(outcomeId, major, outcomeDescription, outcomeRubric): This relation describes the student outcomes that are being assessed and are taken from the abet student outcomes page.
  • The outcomeId is the unique identifier for the tuples in the relation. I would use "C1", "C2", etc. for the CS outcomes and "E1", "E2", etc. for the ECE outcomes.
  • The major is an enumerated type with one of three values "CS", "CpE", "EE".
  • outcomeDescription is a description of the student outcome as shown on the abet student outcomes page.
  • outcomeRubric is a foreign key to rubricId in the Rubrics relation. It is optional and is meant to provide a default rubric for the outcome that can be loaded whenever the instructor selects this outcome. It should be possible for the instructor to select a different rubric for the outcome if the instructor so desires (but do not change this attribute if the instructor changes the rubric because the rubric still represents the default rubric for the outcome).

• OutcomeResults(sectionId, major, outcomeId, performanceLevel, numberOfStudents): This relation keeps track of how many students performed at a certain performance level for each student outcome:
  • sectionId: the id for the course assessing the outcome. This is a foreign key into the Section relation.
  • major: which major ("CS", "CpE", "EE") is being assessed. This field should be an enumerated field.
  • outcomeId: which student outcome is being assessed
  • performanceLevel: foreign key into the PerformanceLevels relation.
  • numberOfStudents: The number of students attaining this performance level

• AssessmentTypes(assessmentId, type): This relation keeps track of the types of assessments instructors may use to assess the outcome.
  • assessmentId: The primary key that uniquely identifies the assessment type.
  • type: A short description of the type that can appear with a widget, such as a radio button or menu item. Sample types might be "exam", "quiz", "homework", "lab", "programming assignment", "project", "written paper", and "oral presentation".

• Assessments(sectionId, assessmentId, assessmentDescription, major, outcomeId, weight, rubricId): This relation keeps track of the assessments used in each course. There may be more than one assessment per section and different sections of the same course may use different assessments. For example, two instructors in two different semesters are likely to use different assessments.
  • sectionId: the id for the course assessing the outcome. This is a foreign key into the Section relation.
  • assessmentId: a foreign key into the AssessmentType relation.
  • assessmentDescription: a description of the assessment (e.g. homework assignments 3, 6, and 8). This field gives coure-specific information about the assessment(s) used whereas the assessmentId gives general information about the type of assessment used.
  • major: which major is being assessed. It should be an enumeratd type.
  • outcomeId: which student outcome is being assessed. This attribute is a foreign key into the Outcomes relation.
  • weight: the weight assigned to this assessment, which is a percentage from 0-100
  • rubricId: a foreign key into the Rubric relation indicating which rubric was used for this assessment.

• Rubrics(rubricId, performanceLevel, description): This relation keeps track of the rubrics used in assessing the students. The primary key is (rubricId, performanceLevel). When retrieving a rubric, you will use the rubricId by itself, because you want all the tuples associated with this rubric. A rubric should have one tuple for each performance level.
  • rubricId: the identifier for this rubric. It is not unique since the same rubricId must cover all performance levels.
  • performanceLevel: the performance level to which this rubric applies. It is a foreign key into the PerformanceLevels relation.
  • description: What the student must do to achieve this performance level

• RubricNames(rubricId, rubricName, outcomeId, instructorId): This relation assigns short names to each rubric (e.g., "General Rubric For ECE Outcome 2" or "BVZ Rubric for CS Outcome 1 -- Homework 1"). The short names can be used in menus so that an instructor can find a rubric that they are looking for.
  • rubricId: The unique identifier for this rubric in this relation. Unlike the previous Rubrics relation, the rubricID is the primary key for this relation.
  • rubricName: A short, descriptive name given to this rubric by an instructor.
  • outcomeId: The outcome with which this rubric is associated.
  • instructorId: The instructor who created this rubric. This field is optional. If the value of the field is NULL, then this is a "generic" rubric for the outcome that has been provided by the ABET administrator. Instructors cannot create generic rubrics--they can only be created by the ABET administrator. For this project, you are not implementing an interface for the administrator, so you can simply populate this relation with a few generic rubrics in order to simulate the rubrics that might be provided by the administrator. The rubrics given in the example assessment plan in the project write-up are good generic rubrics.

• Narratives(sectionId, major, outcomeId, strengths, weaknesses, actions): This relation holds information on the narrative summaries.
  • sectionId: the id for the course assessing the outcome. This is a foreign key into the Section relation.
  • major: which major-CS, CpE, EE-is being assessed. This type should be an enumerated type.
  • outcomeId: which student outcome the commentary relates to. This attribute is a foreign key into the Outcomes relation.
  • strengths/weaknesses: the strengths and weaknesses the students exhibited for this outcome. The instructor would presumably enter the strengths in one text area and the weaknesses in a second text area and it is okay to store each of these fields as one big string.
  • actions: actions the instructor suggests be taken to improve the student attainment of this outcome

• PerformanceLevels(performanceLevel, description): The performance levels and a description of each performance level.
  • performanceLevel is the primary key and should be some type of enumerated constant.
  • description: A short description of the performance level. In this assignment there will be only three performance levels--"Not Meets Expectations", "Meets Expectations", and "Exceeds Expectations".

• CourseMapping(courseId, major, outcomeId): The outcomes assessed by each course for each of the majors in our department.
  • courseId: A foreign key into the Courses relation.
  • outcomeId: A foreign key into the Outcomes relation.
  • major: One of "CS", "CpE", or "EE". This type should be an enumerated type.

Relations That Can and Cannot Be Changed By Your Website

Some of the relations in this project can be changed by your website and some should be pre-loaded with data that would be presumably provided by an administrator. Please come up with the sample data yourself or use the documents that I have provided (in the relations below I will list the document that contains the data for that relation).

Administrator Supplied Relations (Unchangeable)

• Instructors: Make up this data. It is fine to use instructors from our department, another department, or your own names.
• Courses: Use the CourseMappings.doc file in the web_project directory to find the list of courses to use. You can find the course descriptions in the university's catalog.
• SectionsCurrent: Make up data for the sections using the courses from the Courses relation.
• SectionsHistory: Make up data for the sections using the courses from the Courses relation.
• Outcomes: Use the department's abet student outcomes page.
• Performance Levels: Use the three levels I specified.
• CourseMappings: Use the CourseMappings.doc file in the web_project directory.

Relations That Can Be Modified By Your Website

• OutcomeResults
• AssessmentTypes: But you should pre-load this relation with common assessment types, such as programming assignments, homework assignments, quizzes, exams, written reports, oral presentations, etc.
• Assessments
• Rubrics: You might want to pre-load this relation with some general rubrics. You should be able to adapt the old CS abet rubrics and the old ECE abet rubrics to the new student outcomes. These would be a good set of rubrics to pre-load.
• RubricNames
• Narratives