There are eighteen days available to work on this project and turn it in on time. This is enough time to do the project but you will need to schedule your activities effectively. You should choose to meet with your group as soon as possible to plan how you will spend this time and how you will "time box" the project (see Ch. 3) and pursue activities in parallel. Also, you should walk through every aspect of the project in advance, such as by reading the evaluation criteria in advance, and preparing an initial submission for every deadline in advance, to remove as many items as possible from the critical path.
There is sufficient time for the following three extensions to Project 1. The Project 2 Evaluation Criteria have been enhanced to reflect these three extensions.
This should at least include:
The remainder of this document is copied from the Project 1 handout.
Some of these may be useful to you.
Yahoo Maps: http://developer.yahoo.com/maps/
Google Maps: http://www.google.com/apis/maps/
Google Maps Mania: http://googlemapsmania.blogspot.com/
I found some of the following by doing a variety of Google searches on combinations of the following search terms: "google yahoo maps mashups ride board carpool". You should probably try some of your own searches. Note that a "mashup" is a website or web application that seamlessly combines content from one or more source into an integrated experience (from Wikipedia). An example would be if an online restaurant guide automatically provided Google or Yahoo maps showing the locations of each restaurant simply based on its address.
Map Builder: http://www.mapbuilder.net/
Prof. Evans' assignment: http://www.cs.virginia.edu/~evans/cs150-fall2005/ps/ps7/
CVS--concurrent versions system--and SVN--Subversion--are useful programming tools for sharing files among group members. They may useful to you in your development. CVS and SVN are already loaded on the departmental Unix machines. Macintosh and Windows freeware versions are available for CVS, and probably for SVN as well. For CVS, you will still need to use the Unix version for some functions, such as removing files from the repository.
You must assign responsibilities to team members. It is not a good strategy to simply share all responsibilities. Although all team members should contribute to some extent to every aspect of the project, and everyone should do at least some programming, it is essential to have one person with central responsibility for each major part of the task. Among the responsibilities to be assigned include:
The mapping of people to roles is not necessarily one-to-one. For example, it is common in small teams for the user documentation and user interface roles to be combined. You may wish to identify additional roles. You may also want to spell out responsibilities more clearly, e.g., shall the user documentation or technical documentation person be in charge of the final presentation?
The person with ultimate responsibility for one of these functions does not have to do the whole job alone. For example, the system architect does not design the whole system alone, and the product build manager does not do all the implementation; they are managers of different aspects of the project.
Risk control is an important part of project management. One of the largest risks to any software project is the loss of a key person. Therefore, while it is important that a single person be ultimately responsible for each role, it is a very good idea to assign a "backup" for each role also. The backup person assigns the main person responsible for a role, and should be knowledgeable enough about that role to take over responsibility if the primary person is lost or unable to fulfill his responsibility. The backup role is also an opportunity for "cross-training" in preparation to take a lead role in a later project.
The SRS is the Software Requirements Specification. The SDS is the Software Design Specification. The Mini Project Plan / SRS / SDS document is a small combination of elements that might appear in several different documents in a larger project: A proposal, a feasibility study, a project plan, a requirements statement, a specification and/or external design, and an architectural design overview. This document should convince management, a client, or an investor that this project is worth funding. The quality and content of the document will communicate the likelihood of success of the project if it were to be approved.
Your Mini Project Plan / SRS / SDS should include at least the following:
The group should keep a record of meetings. This record should briefly note the agenda of the meeting, the date and time, who showed up (and who showed up on time), and what was accomplished during the meeting. Set ending times for meetings to help you get through the agenda items.
The group should also keep a record of each of the tasks that are assigned to each group member. This should be in the form of a spreadsheet or table with the following columns: The task, assigned to whom, when assigned, when due, when completed, who did it, who signed off on it.
The cheapest, most dependable and least risky software components are those you don't build. You can find test case management, automation frameworks, and other nifty things freely available on the web. I strongly suggest you take advantage of them. On the other hand, you must do so in a way that is legal and ethical, and while I won't set an upper bound on how much of your project code can be reused, you must certainly provide some "value added" and not merely repackage software available elsewhere.
You may not, however, consult with students or re-use code written for previous 422/522s.
To be legal, you must obey all copyright restrictions in software you use. Beware that a document or file need not contain an explicit copyright statement to be protected by copyright law; you have a right to copy or reuse something only if the author has specifically granted you that right. I am absolutely firm on this, and will not hesitate to fail an individual or a whole team for unethical conduct as regards intellectual property. If you have any questions about what you may or may not do, ask me.
Your product must be freely distributable under the Gnu copyleft agreement. In some cases this may mean that you cannot make use of some software which is otherwise perfect. In other cases it may mean that your product will depend on other software packages that you cannot directly distribute. (Be careful of such dependencies, especially on commercial software, as they can make your product more difficult to install and use.)
To be ethical, you must clearly document the original source of all software and other documents. Every source file must contain header comments clearly identifying its author(s). Derivative work (e.g., code written by you but adapted from a book) must clearly cite each source used in its creation. Falsely identifying yourself as the author of something that is someone else's work, or failing to properly cite a reference on which you based part of your work, is plagiarism and will be dealt with very severely.
It is entirely possible to follow these guidelines, making only legal and ethical use of other people's work, and still to avoid a lot of design and coding that would be required if you built this project "from scratch." Sometimes you will find that, even if you cannot directly reuse code (e.g., because it is written in a different programming language), you can still reuse design. You should properly cite the sources of reused design as well as reused code.
This project is based in part from assignments created by Michal Young. The map-based project idea was also inspired by Michal Young.