COS 333 Project: Preliminary Description (Spring 2007)

Mon Feb 5 14:10:07 EST 2007

Overview

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, 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.

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:

• All projects have to have enough common structure to make it feasible for the instructor and TAs to manage 15 or more projects, and to grade them fairly and uniformly.
• At the same time, the basic project should have plenty of room to try out interesting ideas, and freedom to use a broad spectrum of languages and tools.
• It should be relevant to the general themes and topics of the course, which are programming techniques, languages, tools, components and interfaces; it should not stray too far into topics better covered in other courses, like graphics, compilers, networks, databases, and games.
• It should break down naturally into a few components so it can be done in teams of 3 or 4 people, and into stages so that progress can be monitored.
• It should be of some intrinsic interest and potential utility.

Project Definition

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

build a 3-tier system for any application that appeals to you.

This is a very open-ended project, 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.

Numerous web services (including Google, Amazon and Yahoo) provide program interfaces to their systems, which might be a way to put a different face on some aspect of their systems; Google Maps is a particularly interesting one, and Google Earth appears to have promise too.

Look around the 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 this up with staff and faculty friends, and there are definitely potential projects there if anyone wants to explore a bit; come talk to me. You can probably find others by talking to faculty and staff in other departments.

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, or just one that's a lot faster. Think about how Ajax might be used in something new, or how some standalone program could be web-ified (or how some web service could work on the desktop). Or maybe focus on tools that make it easier to build things, and create a couple of simple examples that demonstrate the wonders of your system.

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 doing 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 you are really interested, where one member is driving the whole thing entirely, 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 selection and scheduling; a chat-like information service focused on the local environment; social networks; long-term course scheduling; course evaluation; and Google Maps mashups for ride sharing. This is only a small sample, however, so give your imagination free reign.

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

• User interface: This is what the user sees: a graphical interface that supports some kind of direct interaction between user and system. Web-based interfaces are likely to be most common, but it's also fine to build something that has nothing to do with a browser.

• Process: This is probably the "value added" part, since this is where you process and glue together what the user wants with information sources and repositories.

• Data management: Somewhere there's some persistent data, whether maintained by your system on a local machine, or accessed as needed from the web, or synthesized on the fly. You don't absolutely have to use a database system, but I strongly encourage trying something like MySQL or SQLite or Postgres. You do have to have some component that records significant state and uses it in subsequent interactions.

How big? There's no official requirement, but it ought to ultimately involve some thousands of lines of code; hacking together a thousand lines of PHP somehow doesn't seem enough, and I'm getting uncomfortable with systems that are just a lot of PHP. 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 would like to encourage systems that involve a network connection, even if it is only to a local host, 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 cell phone; Java or VB or Javascript or C#; CGI or PHP or JSP; Django or Ruby on Rails. The only restriction is that your running system must be readily accessible so you can demo it effectively and so we can run it for grading.

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 10 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 reports from previous projects (and, happily, so are the strongly positive experiences reported by groups that did a good job on interfaces). 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.

The project will represent 60-65 percent of your course grade. All members of a team 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.

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.

• How big a task are you proposing to take on? It should be big enough to justify spending well over half a semester on it, but not so big that it's unrealistic.

• What are the components or pieces going to be? How will you organize your project into stages so that you can stop at any point and still have something that works? You don't want a project where everything must be finished before anything works -- "big bang" projects are a bad idea.

• What will you learn from it? You should try a project that will force you to learn something new, like a language or a tool or a system, but you don't want to take on too many new things all at once.

• What technical issues lie on the critical path? If you plan to use some particular tool or language or component or communication technique, what quick experiments can you perform now to be sure that it works and does what you need? Connecting components across a network in the face of security restrictions is sometimes harder than might appear; you want to know about potential roadblocks early. Browser compatibility is a nightmare if you do it thoroughly. If you need someone else's data or other resources, make sure early that you can get access to them. If you're expecting to use the beta version of some software "about to be released", watch out; don't rely on other people to finish their work on your schedule.

• How will you divide the work among the members of the team? This is partly personalities and partly interests and aptitudes. Some people are better coders, others write English better, or are great at designing web pages; some plan ahead, others work well under last-minute pressure. Some take charge naturally; others are happier with a defined task set by someone else. Try to organize yourselves to match the work to the people, and try to have a balanced group -- mere mortals who work well together can get more done than a team of prima donna superprogrammers. Groups of 3 or 4 are best; I will permit groups of 5 only reluctantly.

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. At the same time, 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 each week after spring break. These meetings are a graded component of the project, 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. There will also be design and code reviews involving multiple teams, where you get a chance to critique what others are doing, and have your own work assessed as well. Reviews are also mandatory and graded.

	 S  M Tu  W Th  F  S
Feb	             1  2  3
	 4  5  6  7  8  9 10	first class
	11 12 13 14 15 16 17	start thinking about possible projects & people
	18 19 20 21 22 23 24
	25 26 27 28
Mar	             1  2  3
	 4  5  6  7  8  9 10	initial project discussion with bwk
	11 12 13 14 15 16 17	design document due before break
	18 19 20 21 22 23 24	spring break
	25 26 27 28 29 30 31	detailed project plan due; first TA meeting
Apr	 1  2  3  4  5  6  7
	 8  9 10 11 12 13 14	project prototype
	15 16 17 18 19 20 21
	22 23 24 25 26 27 28	alpha test
	29 30
May	       1  2  3  4  5	last class; beta test
	 6  7  8  9 10 11 12	project demos
	13 14 15 16 17 18 19	Dean's date; project due
	20 21 22 23 24 25 26