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 1 to 100 which reflects the percentage weight that that assessment carries in assessing the outcome. The weights for each outcome's assessments must sum to 100.
2. Provide a short description of the assessment, such as "Homework 1 on SQL and Homework 3 on SQL DDL" or "Midterm 1 questions 2, 6, and 8 on SQL queries".

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. This web interface will be demo'ed in class. If you did not see the web interface, then please go to the video lecture for that day.

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 and weights for each assessment. An instructor should be allowed to add new assessments and delete existing assessments. The weights for the assessments must sum to 100 when the plan is saved. They do not have to add to 100 while the plan is being edited.
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. You can put both your client-side and server-side files in your webhome directory and then run your web-site from the department's web 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 interface should have a side-bar on the left with the course selection menu and other options and a main window on the right where the results, assessment plan, and narrative summary are entered. The instructor should only be allowed to choose courses to which the instructor is assigned in the Sections relation.
3. When the instructor selects a course the existing side-bar 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 and the widget should be a number widget, not a type-in text box.
   • 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 weight and an assessment description (e.g., homework 1 linked lists and homework 3 binary search trees). The assessment weight must be a percentage between 1 and 100 and the combined weights must sum to 100 whenever the plan is saved. Each assessment should also have a trashcan icon that allows the assessment to be deleted. The assessment section should also have a button that allows a new assessment to be added. I recommend implementing the assessment plan as a table. If you delete an assessment, then you will need to modify the html dom document by deleting the row associated with that assessment. If you add an assessment, then you will need to modify the html dom document by adding a row to the plan's table.

   • 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 button: The save button should save their work and briefly display a message indicating whether the save succeeded or failed. There is no need for a cancel button as the instructor should be able to simply reload the page to 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. It is okay to use the browser's default wording for this dialog box. To avoid issues with scamming, the major browsers now provide a standard message when leaving a page rather than allowing you to provide a custom message.

   Unlike the web-site demonstrated in class, it is fine to have the forms for the results section, assessment plan, and narrative summary all appear on the same web page. Please separate the three forms with a visually pleasing separator, such as a horizontal rule.

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

   Once the instructor saves 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 relations for the backend mysql database for you and provided some sample data in ~bvanderz/cs465/web_project/sampleData.sql. This file is incomplete. You need to add DDL statements to create the tables for the relations and also to provide more complete sample data. You should provide declarations for the relation's attributes, for the primary and foreign keys, for enumerated types, and for the foreign key constraints. You do not need to provide declarations for any other type of constraint. If you have questions about the data types for the various attributes in the relations, please first check the sample file and if you are still not sure, then ask me. 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. email is the instructor's username and the remaining attributes should be self-explanatory. password should be stored using an encrypted hash string generated using the mySQL function PASSWORD.

• 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".

• Sections(sectionId, courseId, instructorId, semester, year): Lists all sections of courses that have been used to assess student outcomes, the instructor for the section, 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, outcomeDescription, major): This relation describes the student outcomes that are being assessed and are taken from the abet student outcomes page.
  • The outcomeId is the number associated with the outcome on the student outcomes page. These outcome id's are not unique since CS, EE, and CpE outcomes may have the same numbers but different descriptions. Hence the primary key will be (outcomeId, major).
  • 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.

• OutcomeResults(sectionId, outcomeId, major, 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: a foreign key indicating which major ("CS", "CpE", "EE") is being assessed. This field should be an enumerated field.
  • outcomeId: a foreign key indicating which student outcome is being assessed
  • performanceLevel: foreign key into the PerformanceLevels relation.
  • numberOfStudents: The number of students attaining this performance level

• Assessments(assessmentId, sectionId, assessmentDescription, weight, outcomeId, major): 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.
  • assessmentId: an artificial primary key that uniquely identifies the assessment. You should be able to make MySQL generate a unique assessmentId by declaring the field as an integer with the AUTO_INCREMENT attribute.
  • sectionId: the id for the course assessing the outcome. This is a foreign key into the Section relation.
  • assessmentDescription: a description of the assessment (e.g. homework assignments 3, 6, and 8). This field gives course-specific information about the assessment(s) used whereas the assessmentId gives general information about the type of assessment used.
  • major: a foreign key indicating which major is being assessed. It should be an enumerated 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

• 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: a foreign key indicating 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. This is an optional field that may have a NULL value.

• PerformanceLevels(performanceLevel, description): The performance levels and a description of each performance level.
  • performanceLevel is the primary key and should be an integer that is AUTO INCREMENTED.
  • 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".

• CourseOutcomeMapping(courseId, outcomeId, major, semester, year): The outcomes assessed by each course for each of the majors in our department in the given semester and year. It might seem more natural for this relation to indicate which sections are assessing which outcomes, but since a large course may have multiple sections, you would end up repeating the outcomes multiple times, once for each section of the same course, thus creating an update anomaly problem in your database.
  • courseId: A foreign key into the Courses relation.
  • outcomeId: A foreign key into the Outcomes relation.
  • major: a foreign key indicating which major should be assessed and is one of "CS", "CpE", or "EE". This type should be an enumerated type.
  • semester, year: The semester and year in which the course assessed this outcome.

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 an example list of courses to use. You can find the course titles in the university's catalog.
• Sections: 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.
• CourseOutcomeMapping: Use the CourseMappings.doc file in the web_project directory as a guide and make up sample semesters and years.

Relations That Can Be Modified By Your Website

• OutcomeResults
• Assessments
• Narratives
• Instructors (only the password column)