View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007


Group Members:

Project Goals:

Design an application for manipulating Genealogical data, with the following requirements:

1) Store basic elements of genealogical data in the form of Person and Family classes, which should contain esential data such as birth date, death date, name and gender for a Person, and marriage date, divorce date, husband, wife and children for a Family.

2) Enforce basic logical constraints on the data–e.g. the user cannot enter a death date that is prior to an already-defined birth date for a Person.

3) Utilize a basic GUI for Genealogical operations such as adding/removing/editing people/families, and provide the ability to display a multi-generational view of part of a genealogy focused around a particular individual

4) Provide the ability to export data to a standardized genealogical format called GEDCOM, as well as to read GEDCOM files to produce our own genealogical object representations from data in those files

5) Provide the ability to search the web for data pertaining to individuals in a Genealogy

6) Provide the ability to merge two separate Genealogies, as well as individuals/families

Here are links to some of the milestones we did:

Some Basic Advice:

1) This has probably been beaten to death on these pages, but I'll say it anyway: start early. Having to integrate and debug a bunch of squeak code at 5 AM is NOT pleasant.

2) Use UML to your advantage–everyone understands it, so if you have to explain something you're doing to your group members, sketching a simple class diagram on a napkin will often work better than anything else.

3) Begin meeting with your group members early within each milestone phase to lay the design foundation, and communicate with them regularly to make sure you're on the same page. I can't stress the importance of this enough–your group members will be writing code that integrates with your code, and vice versa, so everyone should know the exact requirements/behavior of everyone else's code.

4) That brings me to my last bit of advice–when choosing group members, of course do the regular stuff (make sure the group members are agreeable, reliable, competent, etc.)–but also make sure that everyone has compatible schedules with a decent amount of room for working on a squeak milestone from the beginning of the milestone phase to the end. That was one of our biggest problems–we had good people in our group, but everyone had different (and busy) schedules. Each milestone needs to be given plenty of development time so that it can mature and all the minor bugs can be worked out.

External Image

Link to this Page