|
CS 420/520: Object-Oriented Programming |
|||||||||||
|
Term Projects |
|||||||||||
|
|
|
||||||||||
Set: Friday 26th April 2019 Proposals due: Monday 6th May 2019 at noon |
|
IntroductionTerm projects will be "free form", that is, you first propose what you want to do, I approve it or ask for modifications, and then, once we have reached an agreement, you execute the proposal. The reason for this "free form" project is the wide range of backgrounds and abilities of the students in the class. I don’t think that I could come up with further assignments and an exam that would be both within the capabilities of those with weaker backgrounds, and yet still challenging to the more advanced students. The project process will let you form a partnership and select a project that is a learning experience for your partnership, interesting to all of you, and yet doable before the end of the quarter. GroupsIt is best to do this project as a pair. I will also accept projects from individuals. Project GradingThe project will be graded mostly on code quality, using criteria similar to those on the rubrics that we have been using throughout the course. The scope and ambition of the project will be taken into account; however, a modest project nicely executed will get a better grade than an ambitious project whose code I can’t read. Project ProposalsYou have ten days from today to form a team and
write a 500 to 800 word project proposal. There should be
enough information in the proposal for me to accept or
reject it; specifically, you should tell me what you
propose to deliver. It’s a good idea to have several
phases, so if, for example, you run out of time to
complete phase 3, you will at least have phases 1 and 2
written and tested. Submit proposals earlier
if possible, so that I can give you feedback earlier. I won’t be surprised if the scope of the project at the end of the quarter is different from the scope described in the proposal, but I expect the project to be recognizably the same. I encourage you to execute your project in Grace, JavaScript, Ruby, Python, or Smalltalk, so that I can read it, but you can propose another language if there is good reason to do so. Project proposals should list the team name, the team members, the context of the project, and some brief user stories outlining functionality offered by the project. User stories are descriptions of interactions with your imagined system from the point of view of the user. If it’s not clear from the proposal what I will see in
the deliverable, I'll ask you to do it again. I
encourage you to adapt one of these project suggestions. I
want to be involved in helping you to decide on the
scope of your projevy: talk to me, in class, in person, or
on Piazza. Schedule
DeliverablesThe completed project should consist of code in github, a copy of your proposal, and a short report outlining:
I encourage you to make your github repositories public; at the least, they need to be readable by me (apblack)! DemonstrationsI will ask each team to schedule a 1-on-1 session with me during exam week to demonstrate their project and answer questions. Submitting your workProject proposals should be submitted in Piazza, as a private message, to which I will reply. Individual Reports should be submitted in d2l, along with the url of your githib repository. |
||||||||||
Most recently modified sometime in the past