Informatics 122 Winter 2013, Final Project

The Problem

For this project, you should first imagine that you have been approached by investors who are interested in running a business that builds out and manages technology-assisted restaurants, where customers sit at tables that are equipped with tablets that present menu information, allow them to place orders, check on the status of orders, pay their bills, and view nutrition and other information about the restaurant's offerings. During this project cycle, I will be acting as a technically-savvy liaison to those hypothetical investors.

From a technology standpoint, you will implement as much of the software to conduct such a restaurant's interaction between customers, servers, and the kitchen as possible. As is often the case when a business idea is initially blooming, the investors are still somewhat uncertain about many of the details of what they want, and are likely to be satisfied with a variety of approaches, but they do have some specific requirements that you will need to meet, which are described in the next sections.

Requirements

Investors have a particular arrangement in mind for their restaurants, and a particular workflow that the software will need to support. While the arrangement they envision is not unheard of in the restaurant business, they believe they can execute an exceptional business and marketing strategy around their vision, but need the software to make it happen.

Background about the envisioned arrangement of the restaurants, as well as the requirements for the software, are described in the bullet points below.

The restaurants are of the "sit-down" variety, as opposed to fast food or casual dining. The seating area for customers is comprised of tables. Each table has a unique identifier — which could be a number or could be a name — and a capacity (i.e., how many people can be seated at that table?).
There will be computing devices — which might be traditional but lightweight desktop machines, laptops, or tablets, assumed to run a traditional desktop operating system, i.e., Windows, Mac, or Linux — throughout the restaurant, providing different people (both restaurant staff and customers) with different abilities. There is no particular requirement about what programming language or technology is used, and either Windows, Mac, or Linux can be assumed. We'll call these devices terminals, so we have a single word we can use to describe them.
A check-in desk with an adjoining waiting area will be near the front door. Restaurant customers will walk up to the check-in desk to register an interest in sitting at a table. A restaurant employee will be stationed at the check-in desk and will have access to a terminal that provides information about which tables are available, what their capacities are, and what parties are currently waiting for tables already.
At each table is a terminal that provides customers with the ability to view a menu, place an order and have it sent to the kitchen, view the status of their orders (including an estimated time of delivery), view nutritional information, place a request for wait staff to visit the table, view the current bill, or pay the current bill.
- Unlike a typical restaurant, the presumption is that food can be ordered piecemeal and delivered one dish at a time, or can be ordered in bulk; it's up to the customers how they want to structure their dining experiences.
In the kitchen is a terminal that displays food and drink orders that need to be prepared. Kitchen staff prepare the food and drinks and, once an order is finished, specify that it's complete and ready to be delivered to a table.
At a few strategically-located points in the restaurant — more or fewer, depending on its size — are terminals used by wait staff, who deliver food and drink orders to tables. The terminals for wait staff provide an indication of what orders are ready to be delivered to which tables, the current bill for any table, and a notification area that indicates if any tables have placed a request for wait staff to visit. Each of these can also be configured to show information for only a subset of tables, so in a large restaurant divided into "zones," only the tables in a particular zone will be displayed on a particular wait staff terminal.

So, in general, the workflow followed in a customer experience at a restaurant might look like this:

A group of customers arrive at the restaurant and visit the check-in desk.
Check-in desk staff either chooses an available table for the group or places them on the wait list. If the customers are placed on the wait list, they'll be called when a table large enough for their party becomes available.
Once the customers are seated at the table, they are instructed to use their terminal to view the menu and place orders.
Whenever an order is placed by a table, it is routed to the kitchen and displayed there. The kitchen staff prepares the food and drinks and, when finished, routes them to the wait staff for delivery.
When an order is ready to be delivered to a table, the wait staff picks it up and delivers it to the table. Afterward, they return to their terminal and mark the order as delivered.
During their stay, a customer can place a request for wait staff to visit his or her table. This request will be routed to wait staff terminals and, once handled, the wait staff member will mark the request as completed.
Finally, when the customers are done with their meal, they'll use their terminal to request a bill and pay it. Once they depart, the wait staff will mark the table as available, so customers can be seated there.

Getting Clarification on the Requirements

As these requirements are fairly open-ended, you will have some amount of freedom in deciding which direction to go. For the most part, following your passion is fine here; in general, the investors are open to a lot of different possibilities, and I would not expect all three teams to build a system that has the same functionality, and that's fine. However, if you're unsure about any aspect of the system's requirements, feel free to ask. When you do, I will share your question and my answer to it with all of the groups. (On the other hand, when you ask questions that are specific to your implementation, I will not be sharing that with everyone.)

A Few Realities

Since this project focuses on building prototype functionality, it is fine to stub the parts of the functionality that cannot easily be implemented without external devices, such as payment processing and receipt printing.

Ideally, an implementation would include support for running the software on multiple machines with networking, but you can work around this limitation and run everything on a single machine to begin with, to keep things simpler.

Group Work

This project will require you to work in a large group of eight students. Each of you will be randomly assigned into a project group and will be receiving an email specifying who else is in your group. (After sending these out, we'll send an email out to the entire class, so you'll know when you should have received one.)

Even if you've done previous work in pairs or small groups, this group will likely be much larger than you may be accustomed to working with in a class project. Collaborating in a group this large is very different from small-group or individual work, and you'll need to think up front about some strategies for accommodating the differences. In short, there is a level of professionalism required here that will be new for a lot of you, but totally vital in future careers, regardless of what kinds of careers they are.

Necessarily, you will need to split up the work, as this project is too big for us to expect any one of you to complete in the few weeks available; as a combined force, however, your group will be able to accomplish great things if and only if you approach the team aspect of your project well. I'm happy to consult with each of you about how you might organize your group's work — and we can definitely talk about this in greater detail during the first Project Consultation meeting during the Thursday, February 28 lecture (described later) — but there are a number of things you can do to ensure that your group experience goes well, which you should think about before proceeding with this project.

The biggest key to a successful group dynamic will be communication. Agreeing on and establishing your channels of communication early will be critical to your success.
- I recommend that everyone meets, all together — in person (ideally), online, via Skype or a Google Hangout, or whatever — once per day to synchronize the group's efforts. Schedule a time to meet that fits everyone's schedule and make sure everyone attends every time, if at all possible. It doesn't need to be a long meeting; in fact, if your meeting is taking more than a half-hour, you're spending too much time (and even fifteen minutes might be enough, if you stay on topic). In your daily meeting, focus on having each person give a brief overview of his or her status, particularly focused on the following questions:
  - Where do you stand in your work (i.e., are you on target to meet the promises you've made regarding the schedule)?
  - Where are you finding things difficult?
  - Where are you blocked waiting for something from someone else? What can be done to get you unblocked so you can make progress?
  - Realistically, is your schedule slipping and do you need help in order to meet your commitments?
  It's not necessary to talk about every detail of what you're doing and you should have the discipline to take issues that only affect a couple of people offline after the meeting, but the daily meeting is a good way to air issues that have broad impact on the overall progress of the project. There's no room for a "cowboy" mentality here; openness and a spirit of collaboration — including a willingness to admit that you underestimated something and are falling behind, as well as a willingness to help others who are in that boat! — are essential.
- Set up some kind of online discussion board. A good example of this is Google Groups, but anything of this nature will do, so long as it accommodates enough users, is convenient to use from mobile devices, and can be made private. Everyone should check this discussion board multiple times per day, and participate when they have something useful to contribute. Of course, your discussion group should be private, so the other project teams can't monitor your postings; the grading of the projects is not competitive, but we do expect each project team to do its own work.
- Be available for instant messaging when you can be, keep your phone with you when you can, and make sure everyone on the team knows how to get in touch with you; if someone can get a question answered quickly so that they can move forward, rather than waiting for a few hours for an email or to have a voicemail returned, this will have a big impact on your overall schedule. It's best if everyone uses the same instant messaging software, even if it's different from the one you normally use, because this can enable other useful features such as impromptu group chat.
Have a brief chat early on with all of the members of the group. Determine where people's skills lie. What is each member's background? What does each member excel at? What does each member prefer to work on? (Be honest with people when describing yourself! The goal here is to find out how best to deploy the talent on your team.)
Source control is completely vital in a project of this size, with this many different committers; trying to organize changesets via email, an online "dropbox," or the like, is an invitation to disaster. Set up a single Git repository, ideally hosted on the Internet, but private (i.e., no one outside of your group can download your code while your work is still in progress). More about this later.
Before proceeding with the implementation, you'll need to decide (at least) on the high-level components; before getting too far into each one, you'll need to agree on the interfaces between them, so that each component can be built without the other ones being present, yet without too many nasty surprises when it comes time to integrate them.
Stubbing or mocking out necessary components will allow you to test each component before other dependent components are finished. Unit testing can help here, but it's only one technique of many. Consider how dependency injection can assist you here.
Members of the group working on components that directly interface with one another would be well-served to coordinate their efforts. Don't write code in a vacuum; at best, you'll be able to integrate your components early and often, as opposed to once at the end, so issues can be flushed out and resolved before you've committed yourself to a particular approach.

Rating Each Other's Performance

As with Project #5, keep some notes on your assessment of the participation level of each member of the group, as you will be assessing each other in a more formal way at the conclusion of the project, with part of your score determined by others' perceptions of your contribution to the effort. This is partly to keep everyone honest — everyone should be pulling their weight — and partly to acclimate you to the idea that you also need to honestly evaluate others' work in real-world contexts, even in the presence of social and political implications.

Hosting Your Git Repository Online

One of your first goals, before your group moves forward with any of the implementation, should be to create a Git repository that is shared amongst all of the members of the group (and only the members of the group). Among other things, you will be required to submit your full Git repository, just as you were in previous assignments; the difference is that we expect, this time, for you to submit a single repository that contains the chain of events (including commits, branches, merges, etc.) contributed by everyone. Individual commits, done by individual users, should show up in the repository's history. You should be able to see, as you glance through the repository, who did what and when, because this will help you manage code changes as they happen in real time, so, for example, you can know who to ask when something doesn't work the way you thought it should. Additionally, we should be able to see this history, as a way to verify that each member of the group was pulling his or her own weight.

The best way to accomplish this is for the repository to be available to your project group on the Internet, so everyone in the group can access it at all times. There are a variety of hosting services available that can do this, with varying abilities and costs; you'll need to choose one of these services, meeting (at least) the following requirements.

The ability to identify individual users as they commit. Do not set up a service with a single username, because you won't be able to tell who did what, which will make debugging and collaborating a nightmare (and will leave us unable to determine who did what when it comes time to grade the project).
The ability to host your project in a private Git repository, so it is not available to everyone on the Internet as you work. There's nothing wrong, in general, with keeping your source open — and, in fact, it has many benefits — but, for this project, you are required to keep your code private. (Your investors have an interest in keeping their system closed and private, so keeping the code out of a publicly-available repository is an important step toward ensuring that.)
Ideally, you won't have to pay for the service. You may choose to pay a nominal fee as a tradeoff for convenience — which might be no more than a few dollars per person — though there are ways to do this for free, if you prefer.

A handful of options are listed below, in no particular order, including my interpretation of the basics of their offers, as of this writing. You'll need to choose the one that's right for your project group, and I could certainly have missed an important detail or two; I have not tried all of these services, so I don't have specific advice about which one is better.

GitHub is perhaps the best-known Git hosting solution. While they do not generally provide private repositories for free, they do offer educational accounts that should allow you to do what you need without cost. Click the I'm a student link on the "educational accounts" page for more information.
Atlassian bitbucket, which provides unlimited private Git repositories. They have a five-user limit, but do offer free academic subscriptions if you use your .edu email address when you sign up, which will allow you to overcome the limit.
Codeplane, which provides unlimited users and up to 2GB worth of private Git repositories. They cost $9/month, but they do have a 30-day free trial, which would get you through this project.
Assembla, which provides up to 1GB of free, private Git hosting, allowing unlimited private collaborators.

An offering that included integrated issue tracking would be a nice-to-have; because of the relatively short duration of this project, an issue tracking solution that integrates deeply with source control (e.g., allowing you to associate Git commits with issues in your issue tracker) is not especially important, though you will want some way to track issues and assign them to team members as they come up.

The Realities of Using Online Tools That Are New to You

It is entirely possible that, early on, you'll find that your chosen repository host has an issue that blocks you from moving forward. Perhaps they aren't reliable, or they have a limit on how many people are allowed to commit to a project, or they provide free access only for a limited time. One of the upsides of using a standard tool like Git, though, is that it should be possible to migrate your repository from one host to another fairly quickly if an issue like this arises that proves to be insurmountable.

The Project Manager and a Project Schedule

In a group the size of yours, it is important to have at least one person who can maintain a holistic view of what's happening with the project from day to day: who's scheduled to complete what features at what times, where the dependencies lie between work being done by different people, how to plan a schedule that allows everyone to be making progress as much as possible, ensuring that important details are not missed, reworking the upcoming schedule because parts of the implementation are not proceeding as planned, and so on. I suggest that each group elect a project manager, who has the overall duty of tracking these kinds of issues. You can choose to give that person a lighter load in terms of implementation (or not, if that person can handle more).

There are no specific requirements with regard to how you are to maintain this schedule, and you won't be required to turn this in, though, as usual, you're best off standing on the shoulders of giants, so consider using well-known tools such as Gantt charts. If possible, a schedule chart available to everyone at a glance — there are loads of Gantt chart web apps available, at least some of which are available free — that identifies tasks, and who is responsible for each, would help everyone to track progress, see upcoming dependencies, and so on.

(Some of you have taken, or are currently taking, an Informatics course in project management; this is an excellent chance to put the techniques discussed in that course into deeper practice. Not all of you have taken this course, but that's fine; presumably, at least one member of each team has done so, and this is another factor in considering how to divide labor amongst the members of your team.)

Milestones and Presentations

Along the way, there are milestones that you will need to demonstrate, along with a sequence of meetings and presentations that correspond to most of the remaining lectures in the course. A good way to think about the process is to think of me as a technically-savvy investor liaison who has an interest in your success; while I will want to feel confident that you're making progress and will be prepared to deliver a complete product by the due date, I'll also be available in an advisory role to guide that progress. So I will be assessing your group in each of these instances, but I will also be trying to ensure that you remain firmly on track. (This is not uncommon in real-world projects, as stakeholders such as upper management, investors, and potential customers want to remain abreast of developments, at least periodically.)

During the Thursday, February 28 lecture, each team will meet separately with me for 20-25 minutes to discuss early design and architectural ideas, understanding requirements, settling on a plan for dividing the work, and generally making sure you're on the right track. Any questions you have about the project, how you should approach it, and how you should manage it would best be discussed on this date. By this point, you should already have a Git repository hosted and your methods of communicaiton chosen and opened. I'll have a few questions to ask you about your choices and your progress, but it will mostly be driven by your needs.
During the Thursday, March 7 lecture, each team will deliver a 15-minute presentation describing their high-level design and architecture. Included in this presentation should be whatever visuals (diagrams, user interface mockups, etc.) you think will help make your design clearer to the audience. If you've chosen to use third-party components, justify why they're included; if not, justify why implementing things on your own was a better choice.
During the Tuesday, March 12 lecture, each team will again meet separately with me for 20-25 minutes to review progress, discuss impediments, clarify requirements, and generally keep you on track, in preparation for the next lecture, at which each team will give another presentation.
During the Thurdsay, March 14 lecture, each team will deliver a 15- to 20-minute presentation that describes current progress, including a demo of the features that are currently complete. The implication here is that your schedule should allow for at least some features to be complete and polished enough to demonstrate by this date, so you need to plan for this early.
During the scheduled final exam time on Thursday, March 21, each team will deliver a 25-minute final presentation, detailing their overall design, including a demo of the completed product. While this is no doubt a stressful circumstance, it's also a celebration of how far you've come; a job well done on the project will be rewarded with a chance for a "moment in the sun."

The final deliverable is a complete product, though I do expect that it may not be possible to complete the entire project as specified here. If not, your goal should be to find a reasonable subset of the functionality to complete and demonstrate. An incomplete solution that is nonetheless fully working and demonstrable for some portion of the requirements will be rated much more favorably than a non-working attempt to completing everything, so you're best off finding a way to work incrementally.

Using Third-Party Components

In general, you should be willing to use third-party components to solve parts of your problem, especially those that are difficult to solve on your own. Obviously, if there is a reasonably complete product out there that already solves this whole problem, you are not permitted to use it — in whole or in part.

As you find third-party components that appear to be a good fit in your architecture, please contact me and let me know what it is, along with whatever information you think I need in order to decide whether you should be allowed to use it. (At minimum, I need to know what its name is, where I can find its documentation, and where I can find its source code.)

Licensing

Licensing plays a role in the selection process. Our goal here is to simulate the design and implementation of a product that could be used or sold commercially — though, granted, there are obvious legal issues surrounding the commercialization of this particular product — so it won't be possible for you to use just any code you find on the Internet. I will be holding you to the following restrictions surrounding the selection of third-party components:

You cannot use a commercial component that would need to be bought in order to be used commercially, even if the component has a trial version or a free license for academic use. While that's fine for most academic projects, I'd like to expose you to the commercial side here, so we'll play by commercial rules; if we couldn't actually go into business using a software product without purchasing it, it's off-limits for your work here.
You cannot use a component that would require your entire project to be made open source in order to be used legally. Your hypothetical clients have an interest in keeping the source code private.
Any additional licensing restrictions (e.g., having to include legal boilerplate in a README file or an About box) must be followed.

I'm happy to help you interpret licenses as you find them.

A Word About Scheduling

Note that while I will do my best to answer questions about third-party components quickly, I cannot guarantee a response in, say, a few minutes or even a few hours necessarily, as I will sometimes need to research them before responding to your questions. As in a real project where there is an outside party involved in decision-making, you'll need to build this limitation into your scheduling. The best approach is to select your third-party components early in the process and get them approved sooner rather than later.

The Final Deliverables

You will be responsible for submitting the following deliverables in advance of the scheduled final exam time on Thursday, March 21 at 4:00pm:

A complete version of your source code, not tied to any source control repository. If you built everything in Java, one or more Eclipse projects (or a whole Eclipse workspace) is fine here. If you did something else, include (at least) all of the code that you wrote.
Whatever documentation you think I'll need in order to compile and install your product. If there are dependent third-party components, let me know where I can get them (or include them in your source code submission). If there are special things I need to do in order to make it run, let me know what they are. Depending on the complexity of your compilation and installation, this could be a paragraph or multiple pages; whatever it takes is what is required here.
A five-page design document, detailing the architecture and high-level design of your project. Include any diagrams you think will make your design clearer (though these do not count against the five-page requirement) — and it's fine for these to be copied from one or more of your presentations — and describe any design patterns you used. For any third-party components that you used, include an explanation of why you chose them and any others you considered and why you didn't choose them; if you chose to build everything yourself, justify why there were no third-party components that were a good fit (i.e., what did you consider and leave out?).
A clone of the complete Git repository for your project, including all commits from the point where you started the project with an essentially empty repository. Individuals should be identified in their commits, so it should be possible to see what was committed, when it was committed, and who committed it. Include a tag final that identifies the commit that is your completed version.
Any slides or other visuals from the three presentations that you made. Submit these in whatever format you wrote them in; there are no requirements here, as I'd like you to be able to use whatever presentation technology you prefer, but I would appreciate copies.

As usual, deliverables will be submitted to Checkmate. Only one member of each team should submit; decide amongst yourselves who that will be.