CS 4250: Project Part 1

Hardcopy (submitted during class time only) or email due by 5 pm on Friday, August 30, 2024. (Email must be plain text, MS Word, or PDF, with subject line "cs4250 project part 1". The email should be carbon-copied to all project partners, for future reference. Do not compress the file. Do not send a URL/link to a file stored somewhere on the web; send the file itself.)

To Do:

1. Form a team of 2-3 people and decide on a group name. Decide on a good application for your database. Read the Project Overview for project ideas.
   • When forming your groups, it would be wise to discuss when and where group members are available to meet. Selecting groups so that members have overlapping free time in the members' weekly schedules will make it easier to meet for group work.
   • No groups will attempt exactly the same project. (Do not concern yourself too much with this restriction; I will require you to tweak project plans to prevent potential conflicts.)
   • To facilitate constructive group work, you should consult the "Successful strategies for teams: Team member handbook" by Kennedy and Nilson (3.2 MB).

2. (20 points) Write a project proposal / description in the following format:

   (i) Name of the project. Full names and email addresses of the students in the group.

   (ii) The domain of your database application. (Your textbook calls this a "mini-world" or "universe of discourse.")

   (iii) The intended user group for your database application.

   (iv) What, in your domain, will be modelled by your system (and what will not)?

   (v) Pages 40-41 in the "Successful strategies for teams: Team member handbook" discusses, among other important ideas, the importance of forming ground rules for a working group, and provides some samples of possible group rules. Discuss ground rules with your group, and include five or more ground rules your group agrees on in your project proposal.

   (vi) What other "value-added" facilities could your system support? (Your group will not build these facilities during this semester.)

   • Describe your hypothetical value-added facility specifically enough that a reader could answer the question "Would I pay $10 for this facility?" with a yes or no.

   The goal is for us to mutually agree on a project that is feasible over the course of one semester. If you have questions, meet the instructor during office hours.

   Yes, correct English grammar counts, in this document and always. Complete English sentences are expected, grammatically correct and meaningful.

Wise Idea: Pick a domain for your database application that all members of the group understand reasonably well. If only one member of a group understands the data domain, and that member catches smallpox at an inconvenient time, completing homework assignments satisfactorily will become difficult.

Frequently Asked Questions

• How long should the proposal be?

  Answer: Approximately one page of single-spaced, two pages if double-spaced. If too long, your group is probably specifying details that should NOT be specified at this point. If too short, your group may have forgotten one of the required parts.

• We want our users to do this and have a drop-down menu on the right and to be using a smartphone and ...

  Answer: Tough luck. A database stores information, somewhat like a library. What users of your database choose to build on top of your database -- the devices they support, the layout of the user interfaces -- is entirely up to your users. Your database simply makes data available to aid them, as our campus library makes books available to students.

• "User group"? What's that??

  Answer: Knowing who will be using your database application will guide decisions about what data will be modelled by the system and what will not. For example, if your project domain is "data about refrigerators," a user group of "people shopping for appliances" will want very different data when compared to a user group of "engineers designing and building new refrigerators."

  "Everybody" is absolutely NOT an acceptable answer to this question. Your group needs to have a clear idea of specifically who you are designing the database for, before you begin design work. One, specifically identified group of human database users. (And only one.)

• Can you explain what you mean by "value-added facilities"?

  Answer: A tool, service or application a database can "enable."

  For example, in the movies domain, this could mean the "recommender system" that makes selections of movies for potential customers based on buying trends. Access to this tool could be made available to web site software developers, as service, so the developers could add movie recommendations to their web site's features. In other words, the recommender system is a tool or service some customers might like, which would be relatively easy to build if a movie database existed, and difficult to build if no movie database existed.

  This question is intended to set you thinking in larger-scope, out-of-the-box, and to make you explain potential advantages of your database from a user point of view. If you are an IT person for a corporate organization, you will frequently need to "justify" investing extra resources into developing something like a database/event logging system/software testing suites, etc. One way to do that, for a database, is for you to think of extra facilities that a database can make possible.

  N.B. "If we add data about X, Y, Z..." No. Adding data is adding work, sometimes quite a lot of work. Adding work would not make a new tool, service or application an attractive project for your hypothetical employer / client.

  N.B. It may help to think about some user group, not the intended user group for your project, that may be interested in the data in your database. Is there a tool for that other user group that could be built if the database existed?

• In the part, "what will be modelled (and what will not)", what do you expect us to write?
  
  Answer: For example, in the movies domain, you can write something like "We will model movies, actors, producers and studios" but not "reviews, movie theaters and sales figures." This way all of us are clear on what will be the final outcome.

  This proposal is written for your (fictional) business manager, and should not include techno-babble about primary keys or column data types. What your group submits should be a proposal that will not change over the whole semester, regardless of what changes to the technical design of your database your group makes later on.

• We want to create the database for famous-company-X. Can we?
  
  Answer: Do not violate trademarks or copyrights. Make up a new company of your own that is in the same area of business of famous-company-X, and propose building the database for your own (fictional) company.

• Um... and group rules should be about what?
  
  Answer: (First, skim through the handbook above.)
  Consider these questions that your group rules could answer:
  • What norms/expectations do we establish for meetings (frequency, attendance, timeliness)?
  • How will we handle making decisions amid conflicting opinions?
  • How will we hold each other accountable to the norms we establish together?
  • What communication tools will we use for discussion (Email, GroupMe, Slack)?
  Questions courtesy of "Avoiding the Groans, Sighs and Eye Rolls", Inside Higher Ed, 13 Jan 2021.

• Do we have to draw an E/R modelling diagram for our application?
  
  Answer: No. I need just a document, in simple English, that says what you will do and some details of what the functionality of the final system is.

• I am not sure of the meaning of the word "model."

  Wikipedia's explanation of "model"
  and Google's definition of 'model'

  Proposal should not list a bunch of data that can be stored. Strings, dates -- facts. We do not need to model facts; they can be unambiguously stored. Any fact that needs only a few numbers or characters to store -- a date, a price, a name -- can be stored, exactly.

  The proposal should not list facts that will or will not be stored, unless particularly significant. Decisions at that level of detail should be made later.

  We speak of weather forecasters modeling Earth's atmosphere, epidemiologists modeling the spread of disease, astronomers modeling supernovae... complicated systems that require many facts and numbers to model, and about which there can be debate about the right facts needed to correctly model the system.