Projects Home Page

This is the home page for the team programming projects of Object-Oriented Software Engineering.

The Projects

  • Aim for five people in a project group; groups of size four are OK, and six can work for some projects but check with us first.
  • There are no limits placed on the topic of the project, but there are some limits on the software structure, described below.
  • Innovate! Your project must include significant original ideas. Feel free to borrow cool ideas from others, but give them credit and make your idea better. You learn to innovate by doing it. It also must serve a real purpose, not some hypothetical need that does not exist.
  • Large software is difficult to produce without organization; we will follow a common timeline of six iterations, one every two weeks.
  • Communication is an important element of team programming. There will be several class sessions devoted to individual team work and discussion with professor and TA's. There will also be presentations (see below) to give you an opportunity to describe your project and to allow for critiquing by the whole class.
  • Initial project proposals will be reviewed, and if your project seems non-innovative or too simple or difficult, you will either be encouraged to switch topics or to make significant changes.

In order to help learning good software skills and succeeeding with good demos, there are a few extra requirements. Note you can petition for an exception to any but the first requirement here.

  • Your project cannot be only "CRUD". CRUD is create/read/update/delete, and CRUD projects are just front-ends for databases with little code that is not doing one of the four C-R-U-D database operations. You don't learn much about software engineering if your app is mostly CRUD. The key of non-CRUD is you are writing some novel algorithms and data structures. Here are some examples.
    • A simple eBay-like for sale site is pretty CRUDdy, but eBay itself is not CRUD due to support for picture editing in listings, an elaborate search tool, AI which shows items of likely interest based on past items viewed, a notification system for end of auction, etc.
    • A basic shared calendar app is CRUD because there are existing libraries for calendar display, and there isn't much besides C/R/U/D of basic data in the app.
    • If your project incorporates some machine learning it has the potential to be non-CRUD, but if all you are doing is calling out to some standard ML library with your data it didn't get there. Your group needs to write the novel algorithms and data structures, not somebody else.
    • The Lyft/Uber apps are not CRUD because the backend is doing complex optimal routing algorithms, etc etc. Even the phone app alone is not CRUD because the display showing the nearby cars moving etc is an advanced custom display.
    Any project topic can be made non-CRUD if you think about this dimension from the start. To emphasize the importance of this aspect, 10% of the final iteration grade will be on the novel algorithms and data structures in your final app.
  • While most languages and frameworks are allowed, some languages are harder to learn good software engineering principles in and so are not allowed: C, C++, PHP, Perl. Similarly, some frameworks are also not as good for learning software engineering principles and are not allowed: NodeJS and Firebase.
  • Whatever software stack you use, there must be a clear automated way for course staff to build and test your project solely from code in your git repository.

Tools and Frameworks

There are three tiers for tools and frameworks: happy, somewhat happy, and other. This tier system exists because we can provide more support and tutorials for the "happier" tools.
  1. If your group is not experienced in app development we strongly suggest you stick to the "happy path" tools listed on the course Tools page.
  2. One step more challenging are the "somewhat happy path" tools also listed on that page.
  3. If members of your group have significant experience you are free to look more broadly and use other tools and frameworks not on the happy paths (provided they are not on the disallowed list above). The course Contact page lists what CAs have expertise in, both for office hours and for what you may get good advice on for your projects.

Frequently Asked Questions about the projects »

Iterations

Project development is broken down into a sequence of six two-week iterations. Certain milestones need to be hit by each iteration. Starting with the coding in interation 3, you need to turn in an iteration report describing what was accomplished compared to what you planned to do, and your plans for the next iteration.
Iteration 0: group formation
Declare who will be in your project group and propose an initial idea for a topic. When you have your group, email the head TA a single email with all of your names, emails, and a paragraph or two giving your initial idea(s) for your project topic. "TBA" is acceptable.
Iteration 1: Requirements
Give an analysis of the requirements your project must meet for it to fulfill its intended function. The main things you need to produce are feature lists and UI sketches.
Iteration 2: Design Proposal and Framework Prototyping
Elaborating on your requirements, flesh out a design proposal, including a draft of data structures via UML class diagram. You will also need to have fixed your chosen frameworks/tools and submit some initial prototyping code in your chosen framework.
Iteration 3: First Pure Code Iteration
Some core functionalty is coded, and at least a few tests are passing.
Iteration 4: Core Working
Core functionality of the project is working, and there are a good set of tests for that core.
Iteration 5: alpha
Alpha release: the project generally works but has some bugs and is missing some desired features.
Iteration 6: Final project
Beta release: Submission of code, and demonstation of your final project.

Presentations

Being a good software developer also means being able to communicate what you did and will do to clients, management, and your peers. The oral presentation component of the projects helps to give you practice in this arena.

There will be two presentations: each group will present an overview in early December, and there will be a presentation at the final demo. The Presentations page provides the details of how these will run.

Examples

Some project webpages from past years are very helpful to see what a good scope of a project is, and what must be done for the first two iterations.