CS333 Project: Preliminary Description (Spring 2002)

Mon Feb 18 17:36:25 EST 2002

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 TA to manage 7-10 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, and interfaces; it should not stray too far into topics better covered in other courses, like graphics, games, display wall, compilers, networks, and databases.
• 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

Many online shopping services use this architecture. For example Amazon has a web-based user interface; the data underneath is fundamentally a large book catalog and customer information; and the process includes a wide variety of searching and retrieval 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.

Even the "build an IDE" project from CS333 a couple of years ago took this form: an interface, perhaps but not necessarily web-based, for editing and control; a persistent store for recording programs and other information; and mechanisms for editing, compiling, and debugging programs.

The project this year will be essentially the same as last year:

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

This is a very open-ended project, so the big problem is more likely to be defining a suitably bite-sized topic than inventing one in the first place. 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 might be a possibility; shopping and other bots are an instance. Yahoo is a good place to start; one of their core competencies seems to be to invent such special services.

Look around the campus for other possibilities: online 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 actually available -- concerns for privacy, property and other people's turf can all get in the way of a great idea). Some of the best projects come from noticing a place where some task is done by hand or poorly by machine when it could be really well done by a suitable program.

A couple of last year's projects were particularly clear-cut examples: a system that managed personal finances through a web interface, and a system that connected on-campus owners and borrowers of VHS and DVD's, a sort of combination of Blockbuster Video and Napster.

The assignment is to create such a system, using whatever combination of existing tools and new code is necessary. The functionality that you must 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 whatever the user wants with information sources and repositories.

• Data management: Somewhere there's some data, whether maintained by your system on some local machine, or accessed as needed from the web, or synthesized on the fly. You don't have to use a database system (though I would like to encourage people to think about using mySQL this year), but you do have to have some component that involves recording state and using it in a subsequent interaction.

Some Options:

Distributed or local: The most typical systems are distributed: the user interface runs on a client machine and the data is stored on some server. The processing might be at either end, or some of each.

Languages, tools and environment: You can use any combination that appeals for any aspect -- web-based or stand-alone; PC or Unix or Linux; Java or VB or GTk or Javascript; CGI or JSP or roll your own. The only restriction here is that your system must be readily accessible for grading, and accessible enough that you can demo it effectively in the CS building using departmental connections to the rest of the campus.

Make versus buy: Much modern software development is done by combining components that others have created. You can do as much of this as you like, as long as the finished product acknowledges the work of others, and has enough 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 Phil Goldman) into e-zillionaires, at least before the recent dot-com collapse that has left them merely multi-millionaires. Of course if you have a really good idea and sell out to Microsoft or do an IPO by the end of the semester, 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?

Since the project will involve multiple people, a significant part of the task is to divide the work into reasonable pieces, with planned interfaces. Each of these components must be a separate entity, which can be implemented and tested separately. But you will have to think carefully about the interfaces between them. So that each person contributes equitably, it is also necessary to be explicit about the roles of each person on the team. Each person must write a reasonable fraction of the code for the system, no matter what other role they play.

The project will represent about 60 percent of the course grade. All members of a team will get the same grade (with the potential for a small correction factor in the unlikely event of someone not carryingg their fair share of the load), so you must make sure that you all agree on who will do what, by when, and to what standard. This is an important point: at the end everyone must sign the project documentation attesting that they have done a reasonable share of the work.

Here are some things you should start thinking about now; this will list 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 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 with something complete accomplished? You don't want to do something that requires that everything be finished before anything works -- "big bang" projects are a bad idea.

• What will you learn from it? It's good to 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 in 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. If you need someone else's data or other resources, make sure right up front that you can get access to them.

• 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; 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 -- a team of superprogrammers can have a harder time than a team of mere mortals who work together effectively. Groups of 3 or 4 are best; I will permit groups of 5 only very reluctantly.

Schedule

The following schedule is subject to change in detail 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 and organization, the project will have several deadlines that will be enforced. [Some of the dates near the end may have to be shifted a bit; there will be adequate warning.] Christine will be responsible for primary supervision of the teams; I will act as backup and second-level management. You will be required to meet with Christine or occasionally me approximately once a week after spring break. This is a graded component of the project, so attendance and preparation will matter.

We will also try to follow good software engineering practice as much as possible; in particular, this will mean using checklists and other planning forms that help organize and monitor activity. I will lean heavily on tools by Steve McConnell.

	 S  M Tu  W Th  F  S
Feb	                1  2
	 3  4  5  6  7  8  9
	10 11 12 13 14 15 16
	17 18 19 20 21 22 23	preliminary project info
	24 25 26 27 28	
Mar	                1  2
	 3  4  5  6  7  8  9
	10 11 12 13 14 15 16	bwk meetings; initial project proposal due
	17 18 19 20 21 22 23	(spring break)
	24 25 26 27 28 29 30	detailed project plan, TA meetings
	31
Apr	    1  2  3  4  5  6
	 7  8  9 10 11 12 13	prototype
	14 15 16 17 18 19 20
	21 22 23 24 25 26 27	alpha test
	28 29 30
May	          1  2  3  4	beta test
	 5  6  7  8  9 10 11	project demos (approx)
	12 13 14 15 16 17 18	Dean's date: project due at 5PM
	19 20 21 22 23 24 25
	26 27 28 29 30 31