Life-Cycle Objectives Proposal

Get-a-LIFE

Life-Cycle Objectives Proposal

Chester Chan

Jessan Hutchison-Quillian

Zinnia (ZiJia) Zheng

Operational concepts

The purpose of our project is to allow users to find events based on their schedule and interests. There will be two major differences between events posted on our site and on our competitors’ sites: first, each user will have a rating associated with him or her, which can be used to gauge the success of past events that he has organized; second, events will be suggested – when requested – to users based on time, location, interests, user rating, and other possible factors. We are not aware of a successful site with such a specific focus on organizing activities; our project aims to fill that gap.

While we want to allow users to find events to attend with friends, the focus of our site is on the events themselves. We are not trying to create a site for match-making or social networking. There are other sites that are better suited for those functions. Our goal is to design a program for organizing daily activities and for finding high-quality and interesting activities to participate in.

System Requirements

A user profile consists of personal information (most importantly, a list of preferred event types) and amodifiable daily schedule for the user that he or she personally creates. The user can plan as far ahead as he or she feels convenient.The client can then, after planning his or herdaily schedule, look at what events fit with the schedule and his or her interests. To support this, there will be adatabase of upcoming events accessible by the user. The events will be characterized by a short description, time, location,user rating, and keywords (classical music, basketball, etc). These events will be posted by users – but the idea is that organizations will become users and use this as an effective tool to get people to attend their events. In order to maintain the reliability of the information, users will be rated by others, so a user who posts a “bogus” event will quickly be identified, similar to someone trying to scam using eBay.

Aside from the above mentioned core elements, ‘Get-a-Life’ has the possibility for many more features (see table). For example, an “Interest List” that records event categories especially appealing to the user allowsevent recommendations to be narrowed to a specific category within the list. Another addition to the system would be the “Friend List”;it allows users read-only access to other people’s schedules (with approval from the second party). With this, one can find events for a group of people to attend. If a meeting needs to be scheduled amongst the group, the time can be determined rapidly as well. We imagine the finishedproduct being similar tothe following prototype:

PRIORITY / FEATURES
oEssential / •Suggest events
•User account (interest list, basic schedule)
•Rate users who post events
ohigh / •Ability to add recurring events (weekly, monthly etc.)
•Friends list
omedium / •Plan friend-only events
•Interest group
olow / •Various visualization formats for the schedule
•Privacy settings
•Interfacing with other programs

System and software architecture

There are three key pieces to our architecture: a user interface, an event-adder interface, and a database to store the user and event information.

The natural interaction between these three objects is that we add events to the database via the event-adder interface, and user information (free time slots, event preferences) to it via the user interface. Subsequently, queries to the database using the user’s information will determine events that fit with the user’s schedule that he/she would be interested in.

Technically, each of these pieces should be feasible. There should be no problem setting up an adequate database using MySQL or another similar database tool. The more interesting choice is how to code the interfaces to the database. They could either be web-based and thus easily usable from any location, or they could be coded as a desktop application in an object-oriented language like Java. The benefit of the object-oriented language is that there are perhaps more tools for large-scale projects readily available, and it is more likely that team members will have experience using them. For a web based application, we have several options. An intermediate solution would be providing a web applet, but these are often clunky. On the other hand, we could implement the application in an easy-to-learn language like PHP, but we are likely to have fewer tools to help us in the development of a project of this size. A final option would be a web application framework (Spring, Tapestry, Velocity). These are better structured for large scale development, but they also are known to have a fairly steep learning curve. These are simply options, and this is a decision that will best be made after team members are determined and we have a better idea of their experience.

Lifecycle Plan

Our product seems to fit an empty slot in the market today, a way of easily finding out about events that are relevant to your interests and that fit with your schedule. This basic idea immediately identifies two groups of stakeholders: users who want to find things to do and organizations who want people to attend their events. Our system’s success also depends on these organizations taking the time to submit their events to our database. Similarly, a large user base would make ‘Get-a-Life’ more attractive to these organizations, but of course we will first need events to be able to draw users. This makes it clear that one key challenge coming with the first release will be building some initial momentum. We are assuming that users and groups will be interested in using this site because they have a vested interest in its success. That is, they will want to post events to attend and attend these events because they are genuinely interested in doing these things. This will keep the number of malicious users (those who post false events) to a minimum. If this assumption turns out to be false, the user rating mechanism will also help to ensure the validity of events that are posted.

The key resource we need for this project is talent to develop the database and the interfaces. This is especially important if we decide to develop a web interface, as none of our current project members have much to offer in the way of web system development experience. A possible team could look like this:

• Project manager: in charge of setting milestones, code reviews, moderate coding.
• Lead developer: in charge of design/architecture decisions, significant coding.
• 2-4 developers: heavy coding, some testing, possibly in charge of documentation too, or designating another person to be in charge of that.
• Lead tester: in charge of designing integration tests and reviewing unit tests, in general directing the testing efforts.
• Spec/documentation specialist: everyone will have a role in this, but this person will lead the effort and work closely with the PM to ensure the quality of both.

Finally, a rough outline of our plan after completing the design of the specs (imagining this will happen by week 4-5):

• 1.5-2 weeks
• First set of features: database designed and working, able to create a user and edit their schedule and add events to the database. Very basic GUI.
• Begin testing.
• 1 week

Able to create and edit list of interests and have the event suggestion query/display working. After this, and having some idea of the pace of development, settle on final set of features.

• 1 week

1. Work on implementing features, have GUI complete as much as possible with “dummy” spots for features planned but not implemented yet.
2. Begin documentation.

• 1 week

Have features done, all remaining effort on testing and finishing documentation.

Feasibility Rationale

Carrying out this project is feasible. The use of a database connected to a web application to deliver content is a standard practice. We know that such a site can be successful based on competitors such as and both of which allow users to find events to attend, although not as effectively as our site will allow.

The risk lies mostly in how interested potential users will be in what we are doing. With the functionality already provided by our competitors, we will need to have a simple, clean, and reliable site that focuses specifically on providing successful events to users based on what they like to do. Another risk is that there may be a lack of people with solid web development experience, as this is not something that is taught in most computer science classes. Having to learn the technology along with the process could lead to unexpected delays. However, we have a solid development plan with early focus on producing a deliverable; this should ensure that we end up with at least some subset of our functionality even if we encounter technical setbacks.