IT350 Final Project

Introduction

In this final project you will work as a team, employing all the HTML, CSS, JavaScript, and CGI skills you have learned this semester, to design and build a Honor website for the brigade.  Your goal is to produce an attractive, functional, maintainable, and innovative system.  The best system may be used as part of the official Honor website. Your customer for this project is LT Michael Berge, Honor Education and Remediation Officer.

This course has taught you the basics of web programming and how to refer to documentation when necessary. Some features of the project will require you to access additional information to complete the requirements.

Overall Requirements

The Brigade Honor Staff would like to create a coordinated website for the Brigade of Midshipmen Honor and Character Programs. This website should be accessible on the intranet for all personnel at USNA and provide valuable information concerning the programs.

The purpose of this website will be as follows

• Maximize transparency of the Honor Program at USNA for all midshipmen, faculty and staff
• Assist in cultivating a sense of honorable behavior within the Brigade of Midshipmen

The website should include the following information at a minimum:

Brigade Honor Staff resources: This section will contain staff contact information, a reading list and other content. The content will be provided to you by the Brigade Honor Advisor. For now, see the attached documents. More information might be added as the project advances.

Honor Education/Cultivation: The purpose of the cultivation side of the website is to provide critical knowledge regarding the Honor Concept from the World Wide Web and related integrity issues. In addition, this website should include a section entitled "Remediation Tools" which will include sample documents and links for remediation. The content will be provided to you by the Brigade Honor Advisor. For now, see the attached documents. More information might be added as the project advances.

XYZ Center: The XYZ Center should include

1. A login mechanism. All users have to log in before accessing the XYZ center information. All successful logins to the XYZ Center are written into a log.txt file. The information in the file should contain the username and date and time of login.
2. A mechanism for the Brigade Honor Staff to put redacted information out to the USNA complex, including case summaries and sanctions awarded. Only authorized users (honor staff) can add cases.
3. A mechanism for the members of the USNA complex to be able to view summaries of all honor cases, as well as details for individual cases (details include all feedback provided for the case).
4. A feedback mechanism for individual cases in which the faculty, midshipmen and staff may provide feedback on specific cases, such as: whether or not they agree with findings, the sanctioning or general feedback concerning the case.
5. Case statistics for members of the USNA complex to review. The user should be able to choose whether they want to see statistics by type (lying, cheating or stealing), by reporter type (officer, civilian, midshipman), by varsity athlete vs non-athlete, and by unit (company and battalion). For now, the only statistic we are interested in is the number of honor offenses in the desired category. More statistics might be required by the client after the project starts.

All of the sections of the website should link together to maximize transparency and usefulness. Information will be provided by the Brigade Honor Staff to populate the website (i.e. case information, educational links and tools) as necessary. The requirements for the project might change slightly to match the needs of the customer.

Other requirements:

• The server side functionality shall be implemented with Perl.
• Login information will be stored and checked against a file users.txt. You decide the format of the file, but it must contain:

· Username: username

· Password: the user must enter the correct username and password in order to gain access to protected functionality (add cases and provide feedback)

· User type: Officer, Civilian, or Midshipman

· User role: Regular or Admin. Only admin users are allowed to add cases.

• Before accessing the XYZ Center information, you must first direct users to a login page where they provide their username and password, which is checked against users.txt file. Only after successful login they should be able to access the information about honor cases. You must use a cookie or some other mechanism so that
• a) they don’t have to enter their username and password again
• b.) check that the user must have performed login before accessing any information (view cases, statistics, etc)
• c.) check that the user must have performed login and is an Admin before adding a new case

• The information about the honor cases, including any feedback provided by the users, must be recorded in text file(s). You must decide the format of the file/files containing information about the cases, but specific information that you need to record and later display include:
• Case id: Each case is identified by a unique case id.
• Class: Class year (1, 2, 3, 4) of the midshipmen involved in the honor case
• Offense type: Type of the primary offense charge: lying, cheating or stealing
• Specific offense: The possible offenses include PRT, Accountability, Collaboration, Conduct, Plagiarism, etc. The list of specific offenses should be stored in a file violations.txt. When a new case is added, the user should be able to choose from the list of available specific offenses, or add a new specific offense. If a new offense is added, that should be recorded in the violations.txt file.
• Reporter type: The category of the person reporting the offense: Officer, Civilian, or Midshipman
• Date: When (only the academic year is required) the of honor offense case was reported.
• Plea: Plea entered by the midshipman accused of the honor offense: guilty or not guilty
• Final status: Final status of the case. The possible values are stored in the status.txt file. Possible values include APPROVED DANT, AWAITING BATT CDR, …
• Separated: Yes or no
• Previous offenses: Yes or no
• Case description: See the provided examples of descriptions

For the feedback, you have to record:

· Case id: case id of the case for which feedback is provided

· User type: type of user providing the feedback: Officer, Civilian, or Midshipman

· Agree with findings: yes, no, or not applicable

· Agree with sanctioning: yes, no, or not applicable

· General comments: any other comments provided as feedback

• Information about cases (list of cases, details, or statistics) that is presented to the user must be dynamically generated based on reading in text file (or multiple text files) that contains information about the honor cases.
• Your site must be well-documented!  You will be required to provide a brief overall writeup of how your site works.  In addition, each file should have a brief comment at top on what it does, and comments within the code.
• You should define functions and share code appropriately.  Don’t have the same code in multiple files!
• You must make use of CSS to make your pages attractive and consistent looking.
• You must use JavaScript to provide useful checking of forms before they are submitted to the server.  For instance, the JavaScript should not allow a new case to be added if the reporter type or other required information is missing. For feedback, Java Script should warn the user if they did not enter a feedback comment (but not force the user to enter comments).
• You must add at least one innovative feature to your system that was not specifically required.
• A final report and presentation will be required.  More details to be provided later.
• All HTML web pages must be constructed using Notepad or a similar text-only editor. The use of programs such as Microsoft Word, Microsoft Frontpage, DreamWeaver, ColdFusion, Mozilla Composer, etc. will be considered an honor offense. 
• You will be provided with some new web space (we’ll call it your T: drive), to store your team’s work on.  The final deliverables should be all there.

Project Roles

Each of you will have leadership responsibility for some part of the project.  This doesn’t mean you must do all the work for that part; it just means you are responsible for making sure it is done right.  Part of your individual grade will depend on how well you lead your team in this regard.  The roles are:

• Team Lead – you are in charge of ensuring that work is distributed in a fair manner to each team member and that the work is getting done.  You are the primary point of contact with the instructor (though anyone can ask for help) and should ensure that project reports and presentations are prepared as needed.  The Team Lead should either be the one to apply changes to your shared web space, or else delegate this to someone else.
• Appearance Manager – you ensure that an appropriate stylesheet is created and used to create a consistent and attractive look across the whole site.
• Quality Control Manager – responsible for ensuring the system is functionally efficient, error free, and secure.  The Quality Control Manager tests the system to expose its weaknesses and then interfaces with other team members to devise a solution. Additionally, quality controllers must ensure code is well commented and that similar tasks utilize the same code.
• Interface Manager – ensures that different pieces of the site can work together via well-defined interfaces.  For example, the syntax of files containing base case information, as well as feedback information needs to be well defined (scripts that read and write the files must agree on what these look like). 

Tips

• Start early! This is a big project and you can expect to experience some unexpected delays or problems that may require changes.
• You want to be able to work independently, but as soon as possible try to interface your code with others.  You are very likely to encounter unexpected issues due to different assumptions about how that interface should work!
• Do not make a ‘project’ folder.  Instead, you should keep all your Perl files in your top-level W: or T: directory.  That way you can run from the webserver or from the command line without changing any paths.
• Make regular backups of your files!!!  Especially when you have something working, make a backup in case it breaks later and you don’t know why.  Do this for both those files you specifically write and your site as a whole. 
• Do most of your testing and development using your old W: drive.  Then copy things to your team space (T: drive) that you are ready to share with others.  But be sure to communicate and have a plan so you don’t overwrite things that someone else has done!  The Team Lead should coordinate this.
• You will be writing a lot of Perl code to generate HTML.  Make use of the HTML helper functions like h1(), th(), etc.
• If your code is not working, first run perl –w –c from the command line (like you did in Lab08) to ensure there are no syntax errors.  Then, add extra print() commands to see what parts of the program are executing and what the values being used are.

Extra Credit

Your project must meet the basic requirements.  Then do any of the following for additional credit.  You may also propose other ideas; talk to your instructor and the customer.

· Honor Concept History: history of the concept and its implementation from 1951 to present.

· Event Calendar: Midshipmen on the Honor Staff can update events and everyone else can view the upcoming schedule of boards and hearings.

Project Grading

50% of your individual grade will be a group grade based on the following

1. Meeting projecting milestone and status reports
2. Functionality and correctness – The site should operate as advertised without error.
3. Visual Appearance & Consistency – including good use of CSS.
4. Maintenance – Ensure the site is well organized, requires minimal maintenance, and can be expanded by someone else who doesn’t know your code.
5. Documentation – Ensure all pages are documented. General documentation covering the system’s layout and design is also required.
6. Creativity – The requirements above require at least one system innovation not specified in the project writeup.  This and any other innovations will count towards your creativity grade. 

The other 50% of your individual grade will be administered by your teammates.

1. Your assessment of your peers shall be based on effort, knowledge, team work, and professionalism.
2. You will assign two grades to each member of your group – one based on their overall contribution, one based on their leadership in their assigned role.

Deliverables

All items due at start of class unless otherwise noted.

· Monday Nov 2. Email status report to instructor:  team name, role of each student, functional responsibility for each student

· Thursday Nov 5. In lab, demo to your instructor that you have basic add new honor case working. No login is needed for the demo.

· Thursday Nov 12. In lab, demo to your instructor an end-to-end system: you can add a case, view a list of all cases, select one of them and view the details of the case, provide feedback. It doesn’t have to look good or have all features working, but you need to have all these parts working together.

• Thursday Nov 19 Complete Projects due, presentations in class.
1. Report: At this time you should submit a written project report, which includes
1. A cover sheet with your team names and project members.  Describe your innovative feature, any extra credit, and any requirements that you did not meet.  Note that your system must work (and will be tested) with quiz input files that your system has not seen before (though that have the same kind of syntax as your other input files). 
2. A listing of the “role” that each person played (from the assigned set of 4) AND a description of what each person did – who created each file, who tested?
3. Username and password for a regular user and an administrator
4. Some brief documentation of how the overall system works.  This should be no more than a few pages.
5. All of your files should also be documented, also described in the requirements above.
2. Presentation: The members of your group should be prepared to demonstrate your system to the class.  Show how a user can view the cases, view statistics, and provide feedback. Show how an administrator (and only an administrator) can add new cases. Be sure to mention your required innovative feature and any extra credit. You’re not expected to prepare Powerpoint slides but if you wish place them in your T: drive for easy access.
3. Feedback and Peer Grading: You will be provided with a form for giving feedback and grading the members of your team.  You will turn this in individually – peer grades are anonymous.  Grading details: TBA.

Late Policy:

For each of the 3 intermediate deadlines, there is a -2% (of overall grade) penalty for each business day being late. The complete project has to be submitted on time. No late submission accepted for the final project.

 Additional Hints/Clarifications (updated as the project progresses)

• By default, variables inside a function are global.  This is almost never what you want and will cause lots of bugs.  You should declare every variable in a function to be local by using 'my'.  I promise that this will spare you pain later!

• How to connect to your shared T: drive – TBA
• Don’t use die() function.  This makes it hard to debug because the error message won’t appear when you run through the webserver.   Example:
  NO:  if ($error) {  die “Error in parse routine”; }
  YES: if ($error) { print “Error in parse routine”; exit (1); }
• Hints on parsing input: Once you’ve read in a line from a file, you will need to split it up into it’s different parts.  A very useful function for this (and other parsing tasks) is split().  This function splits a given string into multiple parts whenever it sees a match from some pattern you give it.  The results are stored in an array.  Here are some example uses:
  @myArray = split (/:/, $aLine);    (splits the line wherever there is a colon)
  @myArray = split (/\|/, $aLine);   (splits the line wherever there is a vertical bar |.  The vertical bar is a special character for patterns so we have to escape it like this \| )
  @myArray = split (/\s*\|\s*/, $aLine); (split the line wherever we see a vertical bar.  Here the pattern also matches any whitespace (\s*) before or after the vertical bar, so that whitespace doesn’t show up in the resulting array.  This can be very useful!)
• Don’t forget to escape special characters.  A number of characters like * | \ etc. have special meaning inside a pattern match.  If you want to test for them, you’ll need to escape them using a backslash as was done in the hint on parsing input above.
• Plan so you can debug using the command line perl.  It’s much easier to debug if you can run your program through the command line.  You definitely want to do this for checking syntax (perl –c –w) but where possible you also want to do this for actually executing the program (perl –w).  For scripts that accept CGI parameter input, you can debug by explicitly passing in values on the command like this:
  perl –w statistics.pl "category=reporter"