ecpe student database final report - iowa state...
TRANSCRIPT
ECpE Student Database Final Report
Team 21
Client: Tony Moore
Adviser: Tien Nguyen
Team Members: Nathan Staley
Mike Walsh
Steven Murray
Justin Sliekers
Table of Contents
ECpE Student Database Final Report .................................................................................... 1
Table of Contents ................................................................................................................ 2
Executive Report ................................................................................................................. 3
Acknowledgements ............................................................................................................. 3
Problem Statement ............................................................................................................. 4
Functional Requirements: ................................................................................................... 4
Non-Functional Requirements: ............................................................................................ 4
Design ................................................................................................................................ 5
Technology Considerations ............................................................................................. 5
Technical Approach ......................................................................................................... 5
Database Design: ............................................................................................................ 5
Code Design:................................................................................................................... 7
Conceptual Design: ...................................................................................................... 7
Final Design: ................................................................................................................ 8
Security Design: .............................................................................................................. 9
Project Plan: ......................................................................................................................10
Implementation ..................................................................................................................11
Operating Environment ...................................................................................................11
Functional implementation: .............................................................................................11
Homepage: .................................................................................................................12
Module Admin: ............................................................................................................12
User Admin: ................................................................................................................12
Group Admin: ..............................................................................................................12
Opp Search:................................................................................................................12
Database Management: ..............................................................................................13
10 Day List View: ........................................................................................................13
Project Team Information ...................................................................................................13
Client Information ...........................................................................................................13
Faculty Advisor Information ............................................................................................13
Student Team Information ..............................................................................................14
Executive Report
Faculty and Staff in the ECpE Department at Iowa State University are often asked to make
recommendations of quality students for a variety of professional and scholarly opportunities. The
process for finding the right fit for each opportunity has proven to be difficult and limiting. Many times, the
students that the advisers ‘know best’ are the ones that receive the recommendations, while other
students who are as qualified are overlooked.
To help resolve this problem, we propose to create a student database that will contain all applicable
information used to select students for opportunities. This database will be populated both by the
students and an automated process. The students will be tasked with updating information regarding
extra-curricular activities, and the automated process will update information like the students GPA.
To make maintaining the database easier, a web-based front end will be developed. This website serves
two purposes: it provides a user-friendly method for entering information and ensures that a student can
only view or modify their own information. A similar site will also be created to simplify the process of
querying the database while organizing the results into an understandable format.
Legal restrictions upon the data contained within the student database forces many security issues upon
our solution. While many of these can be addressed at the server level, our solution needs to guarantee
that a user cannot view another user’s information unless they have legal permission to do so. This
means that only advisers and other faculty will be able to view multiple students’ information. The
students themselves can only see their own information.
The second key issue for this project is data accuracy. A majority of the information in the database will
be provided by the students, with no effective way to validate their input. With this in mind, as much
information must be gathered from authenticated sources as possible.
Upon the completion of this project, our team intends to provide two main deliverables: a flexible
database of student information, and a web-based front end for accessing the database. The database
is the primary deliverable as it handles the bulk of the functionality desired in this project. The website
front end simply makes the process of data input and extraction easier.
Acknowledgements
Very special thanks to our faculty advisor Tien Nguyen and our project client Tony Moore for their
technical support and knowledge going forward with the project, and CSG for providing the hardware to
host both the web-server and database.
Problem Statement
Faculty and staff in the ECpE department at Iowa State University are often asked to recommend
students for several academic and professional opportunities that arise. At the moment, advisers are
forced to make recommendations with the information that they have which results with them
recommending the students that they know the best. Other equally qualified students are often passed
over due to their lack of visibility to the advisers.
The core of this problem is that advisers do not have access to the data that many opportunities require.
This can be resolved by the creation of a student database designed specifically to contain this data. The
database will be populated by a mixture of student input and automated processes. Once complete,
advisers will be able to query the database to match students to opportunities, both academic and
professional, that arise.
While a database would meet the client’s needs, it is not very user friendly. To account for this
weakness, we intend to create and deliver a web-based front end to manage the data entry and retrieval
from the database. Students will be restricted so they can only view and update their personal
information while advisers and other faculty will be able to search the student information as a whole in an
attempt to match students to the opportunities mentioned above.
Functional Requirements:
1. Will be maintained by the Engineering Computer Support Group after completion.
2. All users of the product will have a valid Iowa State NetID.
3. All users of the product shall be associated with the ECpE Department.
4. The product shall allow advisers to query all available student information.
5. The product shall run on a Engineering Computer Support Group managed server.
6. The product shall provide a user friendly method for data entry and retrieval.
7. The product shall allow multiple users to be on at the same time.
Non-Functional Requirements:
1. The cost of this product shall not exceed $500.
2. The product shall prevent a student from viewing another student’s information.
3. The database shall not exceed the storage size of the provided server.
4. The product shall be accessible through ISU servers on the web.
5. Users must authenticate with ISU before logging in to the server.
Design
Technology Considerations
Our product will require a database and a web site to manage it with. This means that we have to
evaluate and decide on the best database provider to use (MySQL, PostgreSQL, Oracle) as well as what
technologies to use in building the website. The nature of the product requires dynamic websites that
contain data that is tailored to the immediate user. This means that we will need to use some web
scripting language instead of basic html. Most common options in this field are java and php.
Technical Approach
To keep the site both easily maintainable and extensible, the web front end will be built upon a generic
framework. This framework will provide a simple interface with the database and the client. Within the
framework, each visible page will be created and treated as its own class, allowing new pages to easily
be added or removed while the site is in production. Each visible page in the website will implement one
portion of the functionality of the website as a whole. This framework will also maintain a mapping of
users permissions to pages within the site, preventing a user from accessing a portion of the website that
they are not allowed to view.
Database Design:
There were three driving requirements for the database: information security, information
editing, and opportunity search.
Information security is primarily an issue with student editing and viewing of information. This
required the saving of permission enforcement information to the database. Further, it required
a direct relationship between the student_data table and the user table. All student level pages
will use the user_id to ensure that only personal information is returned.
Editing student information became an issue as not all information in the 10 day list should be
editable by the student. Others required the use of known keywords before a value could be
assigned.
The actual search logic is contained within the website itself, yet it was required that
opportunities can be saved and searched. The problem presented by this was a conflict with
the requirement that the possible search fields can be changed by the website itself. This
forced the opportunity section of the database to be split into two tables - one with the name of
the opportunity, and the second with all the conditions that a student must meet.
Code Design:
Conceptual Design:
In it original concept, the website would function as a polymorphic framework designed to minimize the dependencies between the business logic, permissions enforcement, and final display. As security is a key concern with this project was security, it was decided to place permission enforcement at a common place in the framework, so the individual pages would not need to re-implement a version of permission control.
Final Design:
In its final implementation, our proposed design was not far changed. The most notable
differences are the inclusion of the two procedural files. These two files act as the access point
for the website, and all communications to and from the browser go through them. Upon
receiving a communication from the browser, these procedural files pass the message to the
Core class, which in turn passes it to the currently active module.
Security Design:
As was previously mentioned, security is a key concern with our project. To help ensure a secure system, users go through several layers of authentication before being able to access the underlying database. In total, there are four levels of security that a user must pass through before being allowed access to the database: Pubcookie authentication, User Authentication, Module Permission, and finally Database Authentication. Of these four methods of security, two (Pubcookie and Database Authentication) are maintained by third parties, and are actively patching newly found security holes.
Project Plan:
Personnel Effort
Personnel
Name
Customer
Needs
Database
Design
Page
Framework
Page
Design
Testing Documentation Totals
Steven 20 60 140 140 40 80 480
Nathan 20 100 200 60 80 100 560
Mike 20 100 100 110 110 120 560
Justin 0 40 80 100 140 120 480
Totals 60 300 520 410 370 420 2080
Work Distribution
The above chart shows the work distribution for the project over the entire year. The one task that is not
noted in the chart above is documentation. Documentation of the project will be done consistently
throughout the course of the year. Everyone on the team is expected to give an equal effort throughout
the course of the year as well.
Deliverables
The above chart shows when the client should expect to receive the specified deliverables. The client will
be kept informed throughout the course of the project to ensure that the system is meeting expectations.
Implementation
Operating Environment
The software will be running on an Apache web-server hosted on Red Hat Enterprise Linux (RHEL). The
database will be running on RHEL, but otherwise is expected to be a standard MySQL database.
Functional implementation:
All of the end user functionality is implemented through individual modules visible to the user.
This modular design allows new functionality to be easily added to the website with the addition
of a new module. Keeping module functionality distinct fit well with the permissions
enforcement scheme implemented in the website, as it prevents admin level code from being
intermixed with student level code in the same module.
Homepage:
Purpose: Student Data Entry and an Intro guide for Admin
Homepage is the first module presented to the user upon loading the website. Unlike
the other modules in the website, the purpose of Homepage changes based upon the
user accessing it. If the user is a student, Homepage allows them to edit their personal
information. If the user is an advisor or administrator, Homepage will display a short
how to use guide.
Module Admin:
Purpose: Linking modules to the website, and assigning permissions
Module Admin is the module that allows the website to be extended with the addition of
new modules. By default, no user has access to a new module. Module Admin also
contains the ability to assign module permissions to users or groups.
User Admin:
Purpose: Creating and editing users with access to the website.
User Admin allows administrators to create new users for the website. It also allows an
admin to overwrite any of a user’s information, in the case that inaccurate information
was enter by the user.
Group Admin:
Purpose: Assigns users to groups and the creation of new groups.
Due to the large number of users for the website, it is impractical to assign permissions
to them individually. In its place, groups were created to be able to allow permission
levels and quickly assign users permissions.
Opp Search:
Purpose: Allows users to query for students who meet given criteria. Also allows users
to save and load previous searches.
Opp Search is the primary advisor functionality for the website. It allows users to
save an opportunity for future use, and can search the current student data for those
matching the opportunity criteria.
Database Management:
Purpose: Allows advisers to update the database schema and bulk load it with the 10
day list.
Database Management handles all the direct interaction with the database. Fields can
be set to student-editable; the database can be updated with the 10 Day list. It enables
the database to adapt to new search fields and additional requirements that may appear
in the future.
10 Day List View:
Purpose: Allows the Advisers to view the 10 Day List to double check data.
The 10 Day list View allows advisers to quickly view a digital reconstruction of the 10
Day List with the student’s extra information added. It also allows columns to be hidden,
to prevent data overload of the advisers.
Project Team Information
Client Information
Name: Tony Moore (CprE Dept)
Primary Contact: Tony Moore
Secondary Contact: Vicky Thorland-Oster
Mail Address: 2215 Coover. Ames, IA 50011-3060
Phone Number: 515-294-3485
Email: [email protected]
Faculty Advisor Information
Name: Tien Nguyen
Office: 3218 Coover
Mail Address: 3218 Coover, Ames, IA 50011-3060
Phone Number: 515-294-8529
Email: [email protected]
Student Team Information
Name: Nathan Staley
Major: Software Engineering
Cell Number: (319) 538-8838
Email: [email protected]
Name: Steven Murray
Major: Software Engineering
Cell Number: (515) 451-8791
Email: [email protected]
Name: Justin Sliekers
Major: Software Engineering
Cell Number: (515) 460-0044
Email: [email protected]
Name: Mike Walsh
Major: Computer Engineering
Cell Number: (630) 825-5291
Email: [email protected]