*************************1*************************

Oracle Project Proposal

CS 327E October 3, 2001

 

The Oracle database and associated application we are proposing is one that will provide a means to catalogue and organize media collections.  Media here consists of, but is not limited to, videos, books, magazines, music, images, and general equipment.

 

Our group is made up Sheryl Anderson, Mike Beam, Casey Bump, and Hui Liu.  The team captain for this project is Mike Beam.

 

Purpose of the Project

 

The purpose of this project is to create flexible, yet easy-to-use, web-based application that accesses an Oracle database, which will contain a catalogue of media, as well as a list of users with varying levels of database access permissions.  The database will contain tables and data the catalogues many different types of media as was stated above.

 

Development Timeline

 

Development of the database and application will follow the following general outline:

 

Proposal review and revision

Prototype database; determine tables, attributes, and relationships

Implement tables and relationships in Oracle database

Begin to enter data into database

Test database implementation

Begin to develop rudimentary front end for the database

Continue to refine database structure

Continue data entry

Continue front end application development

Goto 7 and repeat until requirements are met.



Audience

 

The application and database is being provided for the Outreach and Education Program of the University of Texas Department of Astronomy.  However, the application will not be limited to use by this program.  Indeed, it will be designed to be general enough to be used and adopted by other groups as well as individuals with a need for cataloguing these sorts of objects.

 

Features

 

One of the primary features of this application is that it will be web-based.  Users should be able to view the catalogue in a web browser.  The user(s) with administrative access will also be able to add, edit, and delete the contents of the database from their browser.  One thing we’re looking at implementing is a stand-alone Java application to administer the database with.  This standalone application will largely mimic the behavior and appearance of the web-based application.  Currently we are looking at JSP as a means to implement the web-based portion of this project.

 

The database is to be searchable from the front-end application by any available practical attribute.  This would include title, author, subject matter, and keywords.

 

Another feature is that users will be able to post reviews, comments, and ratings about specific items in the catalogue.  This will be most relevant to media such as videos and books, but could also be used to provide feedback regarding the performance of equipment as well as maintenance issues.

 

The database/application will also include a checkout system so that the main user can track who is using what, and where they can find it.

 

A fifth feature will be that the application and database will be flexible.  That is, if there is a special need for a particular user, that user should be able to tailor the application and the database to a small degree.

 

The application will have the capability to produce various reports in several different file formats.

*************************2*************************

 

-------------------------------------

Names --

Austin Newton -- Austin.Newton@mail.utexas.edu (team captain)

Gracie Phillips -- Graciep@aol.com

Amin Ghazi -- Aming@mail.utexas.edu

Nam Nguyen -- Gawaine@mail.utexas.edu

-------------------------------------

Purpose --  Historic Stock Tracking of the S&P 500.

-------------------------------------

Audience --  Small Investors trading in the S&P 500.  Investors who want to see how their portfolios performed in       the past.

-------------------------------------

Features --

 

Feature #1--

The user will be able to create an account.

 

Feature #2--

The user could create a portfolio of stocks.

The user would enter the stocks he wants to buy or sell.

Each entry would include the amount of shares traded, and when it was

purchased.

 

Feature #3--

The user would be able to look at each individual stock in his portfolio and

show how it performed historically.  This would be displayed visually in a graph.

It would also calculate the final dollar gain/loss for the user, and other performance

measures.

 

Feature #4--

The site will also have a feature to view a simple line graph of the daily stock data

from a starting date to ending date.

 

Feature #5--

Enter a ticker and get a description back

Show the day the stock started trading and last day of data in the database,

so the user know what dates he can buy after and sell before.

 

Feature #6--

The user would be able to modify his portfolio.

-------------------------------------

Assumption--

1.  Stock prices change only once daily.

*************************3*************************

PROJECT PROPOSAL

 

Team Member:  Anh Le, Tram Le, Patty Kehoe (team captain)

 

Project Topic: Air-conditioning shop system

 

Purpose: This system will responsible for technician’s information and customer’s information and their service requests. The system will generate work schedule, and track service request by filling repair order; and printing employee’s schedule, customers’

information and their service requests to an output files.

      Need: the system is created to help the repair shop to manage its operation more affectively and efficiently. Reduced the time for both the customer and the technician, who can log on line and check for the services.

 

Audience: person who request services from the air-conditioning shop and technician who provide the service.

 

Feature:

 (1) A customer can log on and created an account. Then he/she can either make an appointment by enter the code for the repair job, reschedule, or cancel an appointment. [Note: To make an appointment the customer need to enter their full name, address, and the code for the service request,… .But to cancel an appointment, the customer needs only to enter their last name.]

(2) Customer needs to call the shop if the appointment is cancelled within 24 hours, for the system cannot update this information within 24 hours.

(3) The system will provide 3 different services:

      a) Repair of malfunctioning system

      b) Installation of new cooling system

      c) Annual AC checks: every technician must do this job.

For (a) and (b), the system will divide the jobs to each technician within their field of

work. The work schedule generate for the day assigns for the employee to work no more than 8 hours, in which each work order will be allotted 2 hours.

(4) Technician can log on the system to see who is on duty that day. The system will provide a schedule of this, which including technician name, SSN, and service provided. (5) At the end of day, the technician needs to log on again to check for completed job or closed out job. The system will then update the data for the next workday.

(6) The system will be build as a web based.

(7) The system is extensible; it can be used for any air-conditioning repair shop.

 

*************************4*************************

Project Proposal: CS327E

 

 

 

Team:  

             “The Golden Retrievers”

      Ayati Ghosh: ayati@mail.utexas.edu

             Clint Newsom: c.newsom@mail.utexas.edu

             Christy Ho: christyeee@hotmail.com

 

Topic: 

            To develop a database with Oracle that will assign teaching assistants to          appropriate laboratory classes.  We plan on making our project internet accessible

      by creating an application in Java that will speak to the database from generated html          code.

 

Need: 

            Just before the beginning of every semester the Associate Chairman of the                                     Department of Geological Sciences faces a problem assigning TAs their job       assignments for the semester.  The department offers many courses, which require       laboratory classes taught by TAs.  Approximately 40 students are appointed as TAs.        In order to qualify as a TA, the graduate student has to be registered for 9 credit       hours       for that semester and must have applied for a TA-ship.  The prospective TAs fill out a     card with their schedules that show the time slots when they are available to teach.  They       also indicate their preferences in a general manner such as hard rock, soft rock,       paleontology, geophysics to name a few. There are usually several classes offered in each of those fields.  The faculty members supervising the laboratory classes also indicate the       names of 5 prospective TAs for each of their classes.  With all these complexities       scheduling TAs is not an easy job and hence the call for a DBMS.

 

Audience:

            This problem models the scenario in the Department of Geological       Sciences at The University of Texas as Austin.  A DBMS similar to this with       modifications specific to a department could be used by any academic department       and could be widened to any scheduling problem.

 

Features:

 

Prospective TAs will fill out a form showing their schedules for the semester, their teaching preferences, and their academic specializations. This will be completed on a web-based interface.

 

The faculty members will indicate names of 5 prospective TAs for each of their classes.

 

The Associate Chairman will retrieve the database containing the information indicated above and use queries to assign laboratory classes to TAs and also check which classes a particular TA is enrolled in.

      

The web-based interface will be easy to use, allowing those who have no knowledge of databases, access to information.

 

This project could easily be changed and modified to accommodate the requirements of different academic departments on campuses nationwide.

 

Applications:

 

Html based web-interface, Oracle DBMS, Java Compiler (J-Builder/Code Warrior/JDK1.2.2).

 

*************************5*************************

CS327E Project Proposal: Electronic Auction Site

 

Topic

 

 

Team Members

 

Justification 

for the

project

 

 

 

 

 

Audience

 

 

 

 

Features

 

 

 

 

 

 

 

 

 

 

 

 

Requirements

 

 

 

 

Assumptions and constraints

We propose to build an electronic auction site for buying and selling used/new textbooks at UT Austin.

 

Nicolas Derret (Leader), Sanghamitra Sahu, Trent Smith, Digvijay Choudhari

 

Due to the exorbitant cost of textbooks, there is a need for an avenue where new/old textbooks can be bought and sold at lower-than-retail prices. An auction site is the most likely to get buyers the best deal on prices. Additionally the area of operation will be local to Austin. The reduced delivery time and costs and better quality control will give us a competitive advantage over other online retailers. This will also help us attract targeted advertising from local businesses to support our site.

 

The target groups for our auction site are buyers who need cheap textbooks and sellers who need to sell their textbooks. This will mainly include students from UT Austin and other local Colleges as buyers and local bookstores or other students as sellers.

 

Some of the basic features that will be provided are:

Secure account creation with username and password.

Ability to let users post or modify their bids.

Real-time update of online information.

Usage/transaction history for each user.

Ability to place bids using multiple criteria.

Email messages to users giving status of their bids.

Ensuring quality control through user ratings and other means.

Ability to search based on combination of one or more of the following – author, title, subject, ISBN number

Optional: If possible use results from other sites like Addall.com to see that users are get the best possible price.

 

Real-time performance and security are critical. Other requirements will crystallize as the scope of the project is finalized. These will include all the components required to implement the above set of features.

 

The chief constraint that we face will be of time. This might not give us much time to polish our application interface since we will concentrate more on functionality. Another will be getting a proper Oracle setup in the lab and a steep learning curve for the technologies like Oracle, JDBC/JSQL/JSP that we need to use to get our desired functionality.

 

 

*************************6*************************

Project Proposal

 

Team:

Mike West

Bill Donohoe

 

Topic:

We plan on creating a website similar to the defunct FastScheduler that UT

created in fall '98.  The basic idea is to create a database containing

course information, and use that information to enable the dynamic creation

of schedules for students.

 

Need:

The need for a site such as this is clearly felt by anyone who has to sign

up for classes at UT.  One usually knows which courses one needs, but

fitting them all together is often painful.  A site such as this would

reduce the effort needed to create a schedule, and probably generate better

schedules for the student than they might have otherwise settled upon.

 

Audience:

Students at UT are the audience for this project.

 

Features:

1) Provides a general course listing for particular topic areas

2) Provides information about specific courses

3) Dynamically generates a schedule for a student based upon her needs

4) Allows storage of a user's schedule options for future viewing

5) Simple interface for adding, editing, or deleting the course information

 

*************************7*************************

PROJECT PROPOSAL

 

Team Members: Aditya Soman (Team Leader), Do Kim, Dhiraj Gadia

 

Project Topic:  Inventory Management System

 

Need/Purpose: The basic need for this project is to manage a wholesale store efficiently. Any wholesale

store is directly related to its customers and the factory from which it gets its supplies. There is a lot of important data involved in such a system, which needs to be managed very efficiently. We hope to solve this problem, considering, for our project a real-life wholesale store with real life data.

 

Audience:      The audience, in other words the end users of this system are going to be the employees working at the wholesale store, but the beneficiaries would be the customers too.

 

Features:      We hope to implement the following features in our system:

Sales function (Buying/Selling)

Report - Weekly/Biweekly/Monthly/Yearly (Sales History). Also there will be an option to see the ‘reports’ by product or by ‘customers’.

Inventory Check (Modified Search Function)

Customer Information (Customer Data, History)

Order / Restocking (Sending orders for more stock)

 

Possible Future Addition: We might add a possible feature later on, as we progress with the project. This feature would provide the employees of the wholesale store with a login and a password for more security, using which they would be able to access this system.