There are two sections here:
The goal of your term project is to design, implement, and post a website. It is a team assignment. Working with a project partner, you will find a client and create a website for them.
The project, similar to the life cycle of a software product, comes in several phases, including requirements, design, coding, testing and presentation, each with required parts and due dates. Although this page gives an overview of the project, each phase has separate, detailed documentation (linked below), which must be read to determine the specific details of the assignment.
To get an idea of the scope of a reasonable project, check our project hall of fame to see some projects from previous semesters.
See the course schedule for due dates for each phase (all project deadlines are firm).
Most phases of the project require an accompanying document in
which you describe what you will do or have done. These documents will
always be written as web pages (plain HTML). All such documents will be
uploaded to the cs server into your team's account. The
description of the particular phase will tell you exactly what you must
include, what the file is to be named, and how to hand it in.
By the end of the semester, your team account will look like this:
public_html
Documents
P1_requirements.html
P2_design.html
P3_changes.html
P4_testing.html
beta
index.html
other project files
final (optional)
That is, you will have a folder called Documents
comprising documents about your project, and you will
have a folder called beta comprising all the files
that you will deliver to your client. If you decide to make
changes to your project after the coding deadline, you will
create a copy of it called final, and you'll make
your changes to the copy.
Here we have suggested having an index.html file
in your beta folder. This is not required, but we do suggest
that you keep your URLs short by having (at least) the main page
of your site in the top level folder, rather than burying it in
something like project_files/pages/main.html.
The value of the project in the overall course is specified in the grading policy for the course.
The value of each phase in the overall project grade is shown below, in the header for each phase description. Each phase also has a gradesheet, which is linked from the specific guidelines page for that phase.
All parts of the project should be shared equally by the partners on the team. When both partners participate equally, equal grades will be assigned to each member of the team. We reserve the right to award different grades to team members if it comes to our attention that one team member is doing substantially larger amounts of work than the other.
Your project work will be graded by your project advisor. The project advisors work together to ensure that they are consistent in their grading.
The sections below just give a high-level overview of the phases of the project. Follow the links to get more detail.
The very first steps you must take are to find a partner, a client, and request a team account!
Generally speaking, a requirements document describes clearly and precisely what the client needs and wants, and therefore acts as the agreement between the client and the implementor. For the purposes of this project, the document is the basis for a three-way agreement, between your team, your client, and your project advisor.
The Requirements Guidelines contains all requirements information, including the following important items:
Your design document should address the following issues: discussion of site navigation and user interface; layout of each page; precise context of each page; list of graphics and links; file/directory organization; task distribution between team members; and a plan for accomplishing all the tasks. You will also submit prototypes of your web pages.
The Design Guidelines contains all design information, including:
The result of this phase is a complete working website, known as a "beta" version. To complete this phase, post your beta site to the server before the deadline. Also required is a document that lists changes between your design and your beta site.
The Coding Guidelines contains all coding information, including the following important items:
The purpose of a beta version is to get feedback from testers, so that the bugs can be fixed before releasing to the general public. Develop a testing plan, choose testers that represent the intended audience, and based on the feedback, summarize the results of your testing and your responses in a testing document.
The Testing Guidelines contains all testing information, including:
During the final week you and your partner will present your finished website to the class. Nothing to turn in, just make your presentation!
The Presentation Guidelines contains all the details on what your presentation should cover and how it should be done.
© Computer Science 110 Staff
This work is licensed under a Creative Commons License
Date Modified:
Monday, 06-Aug-2012 14:46:15 EDT
