The project you will work on in this course is an opportunity to work on a task larger and more elaborate than assignments in most other courses, to design and implement a significant piece of software, working in groups of 3 or 4 people.
The intent is that this will not be just a toy program, 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:
A large number of real-world systems are based on what is sometimes 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 book 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.
The project will be as follows:
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. Note that you are not required to build something web-based; it’s just that you can get lots of good ideas from the web.
Numerous web services (including Google, Amazon, Yahoo, Firefox) 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 that might do better with an improved interface (don’t you sometimes want to flag multiple locations?).
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). Some of you work in other areas inside or outside the university. There is great potential for ideas from external sources, or faculty/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 made web-based (or how some web service could work on the desktop). Or, maybe focus on tools that make it easier to build things, while building a couple of simple examples that sell the wonders of your system.
Projects are always more fun if the participants are enthusiastic about what they are doing. Be wary of projects where none of you are really interested, or where one member is driving the whole thing entirely.
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:
How big? There's no official requirement. You must implement and deploy something significant, but I don’t want to see sleeping bags in the lab. I will expect to see clean, well-written code, with appropriate attention to principles of sound software engineering. Those of you who’ve had me before know the emphasis I place upon this.
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. Systems that involve a network connection are encouraged, even if it is only to a local host, so as to leave open the option of distributed operation. If you don’t use this, be prepared to explain why it was left out.
Languages, tools and environment? You can use any combination that appeals for any aspect -- web-based or stand-alone; Windows or Unix or Mac; Java or VB or Javascript or C#; CGI or PHP or JSP. The only restriction here is that your running system must be readily accessible for grading and so you can demo it effectively in Lytle using departmental connections to the rest of the campus.
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.
This is your chance to invent something new, or to do something better than others do for credit. 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 only have about 14 weeks, so don’t get too ambitious. 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 professor 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. Each person must contribute equitably, writing a reasonable fraction of the code for the system, no matter what other role they play.
The project will represent at least 50 percent of the 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 you 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.
Ø Teams will consist of 4 members. We have 8 students; break into two groups. If you can’t do it, I will assign teams (something I badly don’t want to do).
§ I will consider one 5 person team, with the other 3 people, if I am convinced it is best for all concerned.
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, organization and regular activity, the project will have several deadlines that will be enforced.
We will try to follow good software engineering practice as much as possible. We will lean on things such as design documents, status reports and reviews aimed at helping you to organize and me to monitor.
Preliminary Deadlines:
Ø September 11: Teams formed. Submit names of
team members at start of class
Ø September 18: Preliminary project
descriptions submitted
Ø September 25: Design document for project;
including use cases
§
what your
system will do
§
basic
organization and components
§
give idea of
each of 3 components, and how they will interact
§
rough
schedule
§
team member
tasks
§
risk
factors??
Ø October 2: Progress report
Ø October 16: First version prototype
§
Should
perform a small subset of the operations that will be performed by the finished
version
§
Plans should
not change much, if at all, after this date.
Ø November 6: Second round version
§
Demonstrates
core functionality; need not be complete, but must handle most functions. Can
crash, but not every time.
Ø November 27: Almost done (beta version).
System should be at least 90% complete. Manual should be well underway.
Ø December 13: Demo day. No final, just
watching you show what a great project you put together.
§
Final
submission of code and documentation must occur on this date, too.
Grading for the project will be based on a number of criteria, including
There will be more information as we go along, to clarify anything that comes up. There will also be class lectures on some of the pieces.
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...