COS 333 Project: Preliminary Description

Sat Dec 6 13:07:19 EST 2014

Overview

The COS 333 project is an opportunity to undertake a larger and more elaborate task than any of the assignments: to design and implement a significant piece of software, working in groups of 3 to 5.

The intent is that this will not be just hacking, but a serious attempt to simulate some aspects of reality: choosing something suitable to work on, planning how to get it together, designing it before building it (though allowing for the inevitable changes of direction as things evolve), building it in stages, testing it thoroughly, trying it out on real users, and documenting and presenting the result, all as part of a small team. If you do it well, this should be something that you can show with pride to friends and prospective employers; you might even make money with it.

The project will involve many of the issues of software engineering as they occur in small, multi-person real-world projects. Some of this material will be discussed in class, and some will be found in assigned readings.

The considerations affecting the form of the project are:

Project Definition

A large number of real-world systems are based on what is often called the "three-tier model": a user interface, a database for persistent storage, and some process(ing) between them. Many web services use this architecture. For example Amazon has a web-based user interface; the data is a catalog and customer information, and the process is a wide variety of searching and data-mining operations. News and financial services are analogous: again, a user interface, a background information gathering and filing service, and mechanisms that let a client register for, access and process interesting items. Cell phone systems often have similar components, either on the device or elsewhere.

The project this year will be the same as in past years:

This is a very open-ended specification, so the big problem is likely to be defining a topic of the right size. Almost every web service will suggest something, perhaps novel or perhaps "We can do that much better"; either would likely be fine. Hiding, selecting, or merging data from existing web services is a possibility; shopping, news and other bots are examples, as are the myriad mashups that combine information from multiple sources. Cell phone applications are often like this too.

Numerous web services (including Google, Amazon, Yahoo, Bing, and Facebook) provide program interfaces, which might be a way to put a different face on some aspect of their systems. Using these APIs could be good for potential projects, and creating a good API is a fine example of a non-graphical user interface.

Look around campus for other possibilities: maps, tours, notification services, databases, and so on are all potentially interesting and feasible, though make sure that the information that you want to use is available -- concerns for privacy, property and turf can all get in the way of a great idea. I often talk about projects with staff, faculty and other students. You might find something appealing on this list of project ideas from other people and by talking to people in other departments. If you want to explore further, come talk to me.

Some of the best projects come from noticing a task that is done by hand or poorly by machine, when it could be done really well by a suitable program, or where something complicated could profit from a neat user interface. Think about how rapid interaction might be used in some new application, or how some standalone program could be web-ified, or how some service could work on a cellphone. Or maybe focus on tools that make it easier to build such things, and create a couple of examples that demonstrate the wonders of your tools.

In my experience, in successful projects the people are really turned on by what they are doing, whether because it's their own idea and that's sufficient motivation, or because they are building something that someone else cares a lot about too. Either way, that kind of engagement usually leads to the best results. Be wary of projects where none of the group is really interested, or where one member is driving the whole thing, or where the application is too far away from your own experience.

Previous projects have included web-based calendars and financial systems; numerous improvements of campus services and agencies; rental and exchange systems; course evaluation, selection and scheduling; information services for the local environment; social networks; and several map mashups. Phone and tablet apps are increasingly popular.

The assignment is to create such a system, using any combination of existing tools and new code. The functionality that you should provide includes the following:

How big? There's no official requirement, but it ought to ultimately involve some thousands of lines of code of your own; churning out a thousand lines of repetitive PHP or mechanically generating a bunch of Python with Django isn't enough. Some systems have been as big as 10,000 lines of C++; that's more than necessary, though it was great work. In any case, I will expect to see clean, well-written code, with appropriate attention to principles of sound software engineering.

Some Options

Distributed or local? Most systems are distributed: the user interface runs on a client machine and the data is stored on a server. The processing might be at either end, or some of each. I strongly encourage systems that involve a network connection, even if it is only to a local host or the database, so as to leave open the option of distributed operation.

Languages, tools and environment? You can use any combination that appeals for any aspect -- web-based or stand-alone; Windows or Unix or Mac or phone; Java or Python or Javascript or C#; CGI or PHP or JSP; Ruby on Rails or Django or AppEngine; your own machine or someone else's. The only restriction is that your running system must be readily accessible so you can demo it effectively and we can run it for grading. I strongly recommend the use of a source code management system like Git or SVN; it will save your life sometime for sure.

Make versus buy? Much modern software development is done by combining code and components that others have created. You can use as much of this as you like, as long as the finished product acknowledges the work of others, and has a substantial contribution of your own.

Things to Think About

I have attempted to make this as open-ended as possible. This is your chance to invent something new, or to do something better than others do. You might think of this as practice for a new e-business or e-service, the sort of e-thing that made some of your predecessors here (like Meg Whitman and Jeff Bezos and the late Phil Goldman) into e-zillionaires. Of course if you have a really good idea and sell out to Google or do an IPO by Dean's Date, it's an automatic A+.

But you have only about 12-13 weeks, so you can't get too carried away. Part of the assignment is to plan exactly what you are going to create, what each team member will be responsible for, and what interfaces you will require between components so independently-created pieces will fit together. What schedule will you follow? How can you work on different parts in parallel and keep them integrated? How will you ensure, if your time estimates are too optimistic (as they inevitably will be), that you have a working subset, rather than a non-working collection of partially completed pieces? How will you convince a skeptical TA and instructor that you are making progress, not just writing code (or doing nothing at all)?

Since the project will involve multiple people, a major task is to divide the work into suitable pieces, with planned interfaces. Each of these components should be a separate entity that can be implemented and tested separately. But you will have to think carefully about the interfaces between them: the problems caused by poor interfaces are a recurring theme in comments from previous projects (and, happily, so are the strongly positive experiences reported by groups that did a good job on interfaces).

The project will represent 60-65 percent of your course grade. All team members will get the same grade (with the potential for a correction in the unlikely event of someone not carrying their fair share of the load), so be sure that you all agree on who will do what, by when, and to what standard. Each person must contribute their fair share, including writing a reasonable fraction of the code for the system, no matter what other role they play.

Here are some things you should start thinking about now; this list will be augmented over the next few weeks, and we will talk about it in class as well.

==================================================================

Schedule

The following schedule is subject to change in details but the spirit is right. Take note.

Since the project involves more than half a semester, it is possible to develop a significant piece of software, but serious planning and steady work will be required for your project to be completed on time. To encourage planning, organization and regular activity, the project will have several deadlines that will be enforced. [Some of the dates near the end may shift a bit; there will be adequate warning.] The TAs will be responsible for primary supervision of the teams and I will act as backup and second-level ("bungee") management. You will be required to meet with your TA manager/mentor each week after spring break. These meetings are a graded component of the course, so preparation and attendance are mandatory -- no excuses.

We will also try to follow good software engineering practice as much as possible. I will lean heavily on things that have been helpful in previous offerings, such as design documents, status reports and reviews aimed at helping you to organize and me to monitor. All of these are also mandatory and graded.

	Su Mo Tu We Th Fr Sa
Feb	 1  2  3  4  5  6  7	start thinking about possible projects & people
	 8  9 10 11 12 13 14
	15 16 17 18 19 20 21
	22 23 24 25 26 27 28	your team should be together and discussing ideas seriously 
Mar	 1  2  3  4  5  6  7	initial project discussions with bwk by 3/6
	 8  9 10 11 12 13 14	design document due before break
	15 16 17 18 19 20 21	spring break
	22 23 24 25 26 27 28	weekly TA meetings start this week
	29 30 31
Apr	          1  2  3  4
	 5  6  7  8  9 10 11	project prototype
	12 13 14 15 16 17 18
	19 20 21 22 23 24 25	alpha test
	26 27 28 29 30		last class
May	                1  2	beta test
	 3  4  5  6  7  8  9	demo days
	10 11 14 13 14 15 16	Dean's Date: project due by 5pm
	17 18 19 20 21 22 23

  • Now: Read this document carefully. Start thinking about what you will do and with who. Come talk to me and the TAs any time about ideas and possibilities.

  • March 2-6: Initial meeting with instructor. I will meet with each team for about half an hour to discuss your plans before they are set too firmly. If you need help finding a topic or choosing among several, please talk to me and the TAs well before this meeting; we're happy to respond to ideas, make random suggestions, and help steer you, starting any time. But don't come to this meeting with 2 or 3 vague ideas, no team consensus, and no concrete plans. It is your responsibility to come up with a project and partners, so don't leave this to the last minute. If you want to explore projects that involve other parties on campus, come see me early so I can help you make connections.

  • March 9-13: Initial web site, elevator speech, project overview document. Your team must create a project web site on penguins in the public_html directory of the team leader. The home page of the web site should be named 333.html. All files comprising the web site should be plain vanilla HTML files, perhaps with some image files. Initially your 333.html page must contain your project name; the names of the team members, their e-mail addresses, and an indication of who is the team leader; your project's Elevator Speech; a link to your Project Overview Document; a link to your Project Timeline Document.

    Your project's elevator speech should be a single paragraph that states clearly and succinctly what your system does. What would you say if you were alone in an elevator with Bill Gates for 60 seconds, and had to ask him for funding for your project? The speech should be a short attention-grabbing description without big words but with good buzzwords. You may be asked to give your team's elevator speech during one of the lectures; so be prepared.

    You must have sketched out what you expect to accomplish in your project, and how. Each team will submit a brief design document for their project. This must include an overview of what your system will do, the basic organization and components, a rough schedule of what you expect to accomplish each week, and who will be doing what. It should identify any significant risk factors and what you'll do if bad things happen. ("We're expecting a large donation to buy a server; we will drop the course if this doesn't come through in time.") A template and examples will be available.

  • March 23-27: Initial TA meeting Each team must meet with their TA to go over their project in more detail, to describe their schedule, the components and interfaces, and the allocation of people to tasks. It is highly desirable to plan a sequence of stages such that each represents a working system; if your schedule proves too optimistic, this gives you a fallback that you can still demonstrate. You must meet with your TA each week from now on.

  • April 10: Prototype. By this date, you should have a bare-bones prototype that shows approximately what you are trying to do, and what your system will look like. It need not do much, but it must do some minimal part of the job. You should not be considering major or even many minor feature changes after this date, though you need not have them all implemented.

  • April 24: Alpha test. By this date, you must demonstrate an almost working version of the core functionality of your project. "Core" means the basic operations that form the essence of your project; if you were doing Amazon 2.0, for instance, this might mean searching for books and accepting orders. "Almost working" means that wizards (you) can help experienced programmers (us) to use the system. Your code may crash and need restarting. But you must be able to convince us that your project can be completed by the deadline.

  • May 1: Beta test. Your code should largely work, all intended features should be installed and working, no major component should be incomplete. A determined sadist might be able to break your system, but a casual experimenter should not. It's very helpful if you can get real users before the beta: ask other teams, your friends and roommates, and anyone else to try your system to see how well it works. Drafts of written material should be underway.

  • May 5-8: Demo days. Each group will give a 30 minute public presentation of their work. All team members must attend the presentation. You must also attend at least two other presentations, for instruction and moral support. Typical projects are great; come and hear about them.

  • May 12: Dean's Date, final submission. Everything must be done and handed in by 5:00 PM on this date, without exception. Final submission includes the code you wrote, something to entice new users, a short document describing implementation and installation, and a longer report on how the project and the team worked out and what you learned.

    Grading

    Grading for the project will be based on a number of criteria, including

    There will be more information as we go along, to flesh out or clarify some of the sketchy parts here. There will also be class lectures on some of the pieces, like networking basics, user interface programming, web frameworks, and database software. You are encouraged to ask questions that will help clarify things for everyone. Murphy's Law applies to projects and their administration, so there will undoubtedly be screwups. I apologize for those in advance, but of course they too will be a simulation of reality...