Second Summer 2002


Project Notes: Choosing and implementing a semester project.

You are responsible for a semester project that accounts for 15% of your final grade.

SEMESTER PROJECT

For the project you need to

The week before the last a script will be made available on the web so you can register for one of the available times. During your defense you would be asked questions about your project. The defense is meant to last about 10-15' but can be extended indefinitely if necessary.

What project should you choose? I have some examples of past projects below. I also provide sample projects, that you could learn from, in the notes. The sample projects are presented in the order we cover the material for the class and they are listed here (under Calendar and Exams on the Class Notes web pages) and clearly marked with a ( a red triangle with a shadow).

You are responsible for choosing a project. You can choose any project you want, as long as you can implement it. If you choose one of the projects presented in the notes you need to implement it and build a complete understanding of the code, which you should defend during your individual appointment during the last week.

PAST PROJECTS

Here are some examples of projects from the past, and some guidelines.

  1. Videconferencing (Simple Videophone) with Java Media Framework (JMF)
  2. On-Line Chef (Plug in the ingredients get potential recipes)
  3. Employee Tracker (Electronic Timesheet)
  4. On-line Bookstore (My Own amazon.com)
  5. Digital Library (On-line Reservation System)
  6. Shopping Mall Item Locator (Based on MapBlast!)
  7. On-line Delivery of Quizzes (My Own QuizSite)
  8. On-line Postcards
  9. On-line Casino
  10. Multiplayer Game in Java (My Own Yahoo! Games)
  11. Bartending Website (Similar to On-line Chef)
  12. Jazz-Related Database (On-line Music Store)
  13. E-mail Server (My Own hotmail.com)
  14. On-line Class Registration System
  15. Customer Service Representative On-line Helper (My Own Knowledge Base)

And here are some suggestions to guide your project proposals.

GUIDELINES FOR PROJECT PROPOSAL

Here are a few things to keep in mind, followed by some guidelines:

  1. You need to post a project proposal by next week.
  2. Your proposal will be accepted as soon as you post it, so there will be no formal review of your proposal, but you are responsible for what you choose.
  3. I provide six different implementations for six different projects (we have already covered three of them).
  4. I will show you how they work and show you how one implements them.
  5. If you choose one of these as your semester project your task is to build a complete understanding of it.
  6. You still have to provide a proposal in which you describe what you choose and why.
  7. At the end of the semester, you are responsible for all the code that belongs to that project.
  8. You need to understand it perfectly well.

WHAT YOUR PROJECT PROPOSAL MIGHT DISCUSS

The notes below describe the design process that should go into the project proposal and the early development stage of a project. We will take a top-down, user-oriented approach.

Implementation aspects should be be discussed, but not details - only the general framework.

1. Identify a problem to be solved.

Do it for the purpose of communicating the problem to me. Don't identify problem with necessity. By problem we mean a certain kind of service that we provide. Some services are more important and/or more necessary or vital than others. Your project idea will have an identity of its own. Describe it.
2. Identify your users
Users are those that work with your system. Those could be end-users or administrators like you. Distinguish further (if you can) between your end-users (instructors and students, readers and writers, consumers and producers).

2.1 Are your users going to have an identity of their own?

Are you going to be able to distinguish between your users, individually? If so describe the method that you will use to achieve that. In most situations this is done via a username and password authentication method. If you will use such a method think of where you keep the passwords.

A related question is: do you let the users create their own identity (such as when you register for New York Times) or do you require that they apply for an account (such as when an IUB network ID is created).

2.2 Are there any issues of privacy and security?
Describe what kind of data users will be able to input to your site and any levels of access that your application will require. For example if you are building hotmail.com or mailexcite.com you probably want users to read only the mail addressed to them and nothing more. A grade and feedback posting system also has to provide a certain specific level of security and privacy.
3. Describe your solution.
Assume you need to sell your idea to a potential client, company, or service provider.

3.1 Describe all user interfaces.

This, I believe, is the most important part of your proposal.

Explain to your client what each of the category of users assumed by your system can do. Be fairly detailed as if you'd be running that person through a sequence of demo screens.

Note that if your system is part of another bigger system (which may take care of the user interface) then this requirement translates into: describe its input/outputs, and any internal states it may have.

3.2 Contrast your solution to how service is currently provided (if not a new service).

For example when we post grades with a feedback system we are trying to provide a better or faster service. This is not a new service but features of the service are new (the privacy issue comes to mind).

If your service is a new service (loosely speaking) explain what's the novelty of it, as you're trying to sell it.

4. Address issues of implementation.
Try to describe each of the actions that the user interface can generate in terms of smaller, simpler steps, that would be closer to how your system will work. Your framework is a client/server approach, with a network link between the server and the client. Think about the programming methodology you will be using.

On the server side you have the option of CGI, PHP, Java servlets, JSP, with MySQL database access from all of them.

On the client side you can do no programming at all (HTML with forms), or some programming (Javascript with HTML with forms) or a lot of programming (if you write Java applets, or if you decide to write your own client application) so look at all posibilities, and be specific about the solution you choose.

5. Address issues of capacity planning.
How many users are you going to have. What will be their work habits. Is your server going to be overloaded at any time. Is your service mission critical? What if it becomes unavailable at a certain time -- how would this affect your users? Are some times more important than others?
6. Address issues of cost of maintenance and distribution.
6.1 Maintenance
How many hours per month does it take to just keep your service running. If someone will buy your system they will need to know what's going to take to keep it running. (User/Buyer Perspective)

Is there an initial cost for populating the database on the server with the initial data for a certain client? (Service Provider)

6.2. Distribution
What does your service require for the user workstation to be functional. If you're implementing using CGI with HTML forms then you assume that the user has a web browser installed.If you're using some browser specific functions mention them.

If you're writing a Java (or some other type of) application and expect the users to download and install it be aware of what they need and try to be precise about what they need to do.

If you're using applets or CGI with HTML forms you can almost assume that the user has a browser installed, and so the effort of distributing your client software will be close to zero.

However you need to keep in mind the trade-offs: custom-client software may be more powerful but it may require more work for the client (installation) and for service provider (development).

7. Revenue
Can the system generate revenue? How?

That's not really too important, but it could be.

Finally, remember that these are just guidelines. So if you don't like them, or can't follow them (because they don't apply to your particular problem or for some other reason) just ignore them and do your own thing. The goal, however, remains the same: choose a problem, communicate it to us on the web site, implement it. Be straightforward, realistic, and committed to your goals, and you will succeed. Do come to a conclusion soon. If you need help please let us know.


Last updated: Jul 18, 2002 by Adrian German for A348/A548