This is the home page for the team programming projects of Object-Oriented Software Engineering.
- There are three to five people in a project group.
- There are no limits placed on general 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 very dificult to produce without organization and discipline; 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 make sure you learn good software skills and that all groups finish with good demos, there are a few extra requirements.
- Your project cannot be completely "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. 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, their elaborate search tool, scaling to many users at once, timed events for end of auction, etc.
- A shared calendar app is probably 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.
- Lyft/Uber is not CRUD because the backend is doing complex optimal routing algorithms, etc etc. Just the phone portion of Uber/Lyft is also not CRUD because the display showing the nearby cars is an advanced custom display.
- Apps with fancy custom-coded UIs as a component are never CRUD as there is a great deal of complex code for data display (as long as you wrote the code and are not just using an existing framework or library).
- For major software frameworks/tools, either your group needs to have one or more people with experience in the framework and willing to educate the rest of the group, or the course staff has someone with expertise (and, its best if both apply). The course staff should have experts in Java, Android, iOS, and perhaps in Ruby/Rails and Python/Django. See the Contact page for specific frameworks and tools that we have expertise in.
- Frameworks that are overly CRUD-focused are not allowed; these currently include NodeJS and Firebase.
- Whatever software stack you use, there must be a clear automated way for course staff to build and test your project. Consider using Docker if the build is non-standard. From iteration 3 onward, if we cannot build your project on our box from your README only, you will get a 0 and will need to resubmit with penalty.
You need to bear in mind this last requirement in selecting your project topic, some libraries and frameworks may be out of bounds since a fully automated build would not be possible. Beyond being industry-standard software engineering practice, having an automated build helps your team be on the same page, and it also helps us in evaluating your projects.
- 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.
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.