Project Final Report - Senior Design - Iowa State University

flameluxuriantΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 8 μήνες)

190 εμφανίσεις

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 Da
tabase Final Report

................................
................................
....................

1

Table of Contents

................................
................................
................................
................

2

Executive Report

................................
................................
................................
.................

3

Ack
nowledgements

................................
................................
................................
.............

3

Problem Statement

................................
................................
................................
.............

4

Functional Requirements:

................................
................................
................................
...

4

N
on
-
Functional Requirements:

................................
................................
............................

4

Design

................................
................................
................................
................................

5

Technology Considerations

................................
................................
.............................

5

Technical Approach

................................
................................
................................
.........

5

Database Design:

................................
................................
................................
............

5

Code Design:
................................
................................
................................
...................

7

Concep
tual Design:

................................
................................
................................
......

7

Final Design:

................................
................................
................................
................

8

Security Design:

................................
................................
................................
..............

9

Project Plan:

................................
................................
................................
......................
10

Implementation

................................
................................
................................
..................
11

Operating Environment

................................
................................
................................
...
11

Functional implemen
tation:

................................
................................
.............................
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 ECp
E 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 automate
d 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 st
udent 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 st
udent 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
me
ans 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 databa
se 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 mak
es 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 mo
ment, 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 adv
isers 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 completio
n.

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 Compu
ter 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 functio
nality 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 th
ree 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 i
nformation 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 becam
e 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
o
pportunities 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 table
s
-

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 dependenci
es
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 ne
ed 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 acces
s 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 Da
tabase
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

Stev
en

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 ent
ire 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 ye
ar 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.





Implementat
ion


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 o
f 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 w
ith 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
ne
w 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 administrat
ors 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 t
o 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 studen
t 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
b
e 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 Da
y 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.




Pro
ject 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:



awmoore@iastate.edu



Faculty
Advisor Information


Name:



Tien Nguyen


Office:



3218 Coover


Mail Address:


3218 Coover, Ames, IA 50011
-
3060

Phone Number:


515
-
294
-
8529


Email:



tien@iastate.edu





Student Team Information



Name:



Nathan Staley


Major:



Software Engineering


Ce
ll Number:


(319) 538
-
8838


Email:



njstaley@iastate.edu



Name:



Steven Murray


Major:



Software Engineering


Cell Number:


(515) 451
-
8791


Email:



samurray@iastate.edu



Name:



Justin Sliekers


Major:



Software Engineering


Cell Number:


(515) 460
-
0044


Email:



indal@iastate.edu



Name:



Mike Walsh


Major:



Computer Engineering


Cell Number:


(630) 825
-
5291


Email:



mlwalsh@iastate.edu