This project is due on Sunday, February 3, at 10 PM, including all source code files and documentation. Follow the submission instructions. Groups will present a preliminary overview of their ProjectPlan/SRS/SDS in class on January 17, and the actual ProjectPlan/SRS/SDS document at the start of class on January 22.
A huge proportion of grade-school-aged children in the United States are driven to school in cars driven by their parents. This was not the case ten or twenty years ago when the majority of students got themselves to school on big yellow buses, by walking, and so on. This transportation transformation creates a number of problems. Obvious problems include a higher number of miles driven by one- or two-passenger cars, thus contributing to general traffic congestion and auto emissions. A lesser known but also serious problem is the increased danger to children as they must walk around cars and sports utility vehicles (SUVs) parked several layers deep outside of their schools, as the children are getting dropped off and picked up all at the same time. Many SUVs are so high that their drivers cannot see children walking in front of them. Injury and death of these children is a serious problem.
The problem of injury during pickup and dropoff congestion could be alleviated if parents would have their children get themselves to school using "old school" techniques such as walking and school buses, but this would require a fundamental shift in American thinking. The problem could perhaps more feasibly be addressed by having more children carpool to school in groups of three or four children, greatly reducing the number of cars picking up and dropping off children all at the same time.
A fundamental obstacle in setting up these carpools, however, is that parents do not know where all of the other children who attend the school live. It could be that a child lives just three doors down, or that the parent passes by their house every day, but the parent could never know it. One way to solve this problem would be to distribute a list of all of the names and addresses of all of the children who attend the school, and the parents could then just browse the list and see who lives nearby. But some of the parents might not want this information distributed to all of the other parents. Furthermore, just having the addresses of all of the other children would not make it easy or obvious to know which children lives just a block or two off of the route that a parent takes when driving their child to school, unless the parent knows all of the streets and addresses in their region. What is needed is some sort of interactive map that indicates the vicinities of the houses of children who could participate in a carpool, but in which the personal information is kept private until the parents negotiate a carpool agreement.
A web-based mapping system will be built to help parents easily identify the locations of households that are interested in carpooling to their school. Interested parents will enter their residence locations into the system and be presented with a map that shows the general locations of other households that are interested in carpooling. A secure system will enable the parents to contact other parents to exchange contact information to discuss the details of the carpooling arrangement.
The basic system requirements are as follows:
1. A Means of Communicating Carpooling Interests
- Interested parents can indicate their interest in carpooling via a web-based server.
- Carpooling interest notifications will include:
- An indication of the school attended by the child. (This may perhaps be indicated simply based on the specific website that the parent goes to to find a carpool.)
- Name of parent(s).
- Names and grades of child or children interested in carpooling.
- Street address of residence.
- Home phone number.
- Parent's work or cell phone number.
- Parent's email address.
- Parents will be able to confirm that the mapping system correctly displays the location of the street address of their residence (as well as an approximate location if it will be displayed).
- Parents can make initial communications via the system to other parents, easily explaining which location they are on the map (such as with a location number).
- Parents can respond to these initial communications from other parents.
2. A Web-Based Map Displaying Interested Households
- After entering their own address and other information, parents can look over the map of all parents interested in carpooling for their school.
- A parent can see his or her residence and the school in a manner that is unique to the others (such as in a different shapes or colors).
- The parent can navigate the map (i.e. scrolling to travel down streets) to see what other residences they will pass as they drive to school. They can also navigate to see what routes other parents are likely to take as they drive their children to school, to see if anyone will likely pass nearby on a regular basis.
3. Security
- Private information will be withheld from the general user population and only made available on an individual basis after one parent agrees to make it available to another.
4. Installation
- The system should be designed so that it can be installed by anyone with basic Unix skills and a "public_html" or "www" folder in which they can put .html files on the web.
- There must be a simple and straightforward way for the installer to load the system with a sample school or schools and at least twenty simulated users, including all of their simulated personal information.
- The data must be as real as possible without using exact data from actual people in the community. (For example, you could get your data out of a phone book but scramble it slightly.)
- All sample data (as well as usernames and passwords, if the system uses them) must also be provided independently of the system in very easy-to-read documentation, for testing and verification purposes.
- Some consideration must be made regarding where the system would reside. For example, would every grade school need to set up a web server? This may not be feasible. Could some central trusted party such as the school district be in charge of setting up the system for the entire district?
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.
Week 1
Before you are assigned your team, start working on the project on your own. Design work and brainstorms are usually more productive if group members first do some thinking on their own, without the inertia of groupthink to pull everyone down one or two paths. Work on the issues that will be in your product concept document due at the end of week 2. Browse the web looking for products (freeware, shareware, and commercial) that do something related to automated testing. What is the competition? Are there "market niches" for your product? Look also for useful components that you can reuse.
Week 2
You are going to need at least a couple of intense team meetings to agree on your product concept, in addition to more individual research. Think seriously about the feasibility issues: How is your team going to divide up the work and tackle the problems? Produce the product concept document and present it to the class on Friday.
Week 3
Delivery is less than two weeks away, and deadlines that looked easy before are starting to get scary. Don't panic. Do make a plan that includes early production of a running prototype (no matter how lame, it just needs to work) and frequent revisions. Make contingency plans for the failure of anything that isn't already running. You really, really want a running prototype so that you are ready to discuss any remaining problems.
Week 4
It's crunch time. You're on a daily build-and-smoke schedule now. You have an agreed meeting time each day for putting together everyone's pieces and testing the current system version. The build-master is sweating bullets, but she has it under control so that, if it all blows up on due date, the build from the previous day is still good to go. You schedule intense reviews of documents and outstanding design issues. On the due date you declare victory and turn in your project.
Week 5
There's still one more chore. You need to present and/or demonstrate your project in class. You will also participate in the class discussion. How did your approach to the project differ from that of other groups? Did you encounter some of the same problems? What seemed to work, and what didn't?
This project is based in part from assignments created by Michal Young. The map-based project idea was also inspired by Michal Young.