We had some discussions around this topic at the pizza joint Thursday night. I just want to point out that the solutions proposed seemed to gravitate to something using a DB. I.e. a replacement for Access/Excel for entering data and then using that to match up resources and needs and personnel. Sugestions were MySQL, OOo Base etc. The only real consensus I heard was it should be web based to allow people to pre-register, avoiding a tie-up of a phone call.
Going out on a limb here, but may I suggest it is too early to think about what sort of back end storage mechanism to use. Too often, when specifying requirements, a particular emphasis is placed on the need to store things in a RDBMS of some sort. In Agile/XP circles, the rule of thumb is to delay that decision "until the very last responsible moment." IOW, don't let the storage mechanism determine the overall shape of your application. So don't say : "I need to store things and match those things up with each other and therefore, I need a RDBMS solution so I can do joins." Instead, say "I need to match people and resources and needs for those reources." And go from there. Design from the middle outwards. Start with the business logic, decide on a UI and create a thin wrapper for that. Finally, decide on some sort of persistance mechanism. In the latter case, there may be more than one way to skin that cat. For instance, prevalance mechanisms are one way. Check out Insitki (A DB-less Ruby Wiki) and Prevayler (A Java POJO (Plain old Java Objects) persistance mechanism.) Don't rule out just serializing the objects or stroing them in a flat file (that can be imported, exported from eXcel.) The later has the advantage of providing you a made-to-order UI. In the former case, define what a need is. Define how to fill that need, lets call it a resource. Once a need and a resource are plugged together, the need no longer is unsatisfied, and the resource is no longer available. Define a person as an entity that besides identifying attributes has_a container of resources. This is a first stab at stating the domain model. Obviously, we need to go deeper than that. For instance, we probably need a way to group needs by location. So a location has identification attributes and a collection of one or more needs. We might create a subclass of resource called skill. Skills are resources attached to the owner but can only be applied to one location at a time. What emerges from the above thought experiment, is that the domain we are trying to model is a more-or-less typical unbound scheduling application. Are there any out there already that meed our need? Don't re-invent the wheel if you don't have to. Just some random thoughts. Ed -- Ed Howland WDT Solutions, LLC. [EMAIL PROTECTED] (314) 962-0766 _______________________________________________ CWE-LUG mailing list [email protected] http://www.cwelug.org/ http://www.cwelug.org/archives/ http://www.cwelug.org/mailinglist/
