MasterReport.doc

Master’s Project Final ReportSemester: Fall 2008

Funds Management and E1S Processing Tool

Submitted by: Simerjeet Kaur

Project Advisor: Mr. Ajay GuptaDr. Irvin Levinstein

Presentation Date: September 12th 2008

Department of Computer ScienceOld Dominion University

Student Appointment ToolFall 2008

Acknowledgement

This Project represents the cumulating involvement and effort of more that one person. I

want to express my gratitude to Computer Science Fiscal Assistant, Shannon Eggers for

providing the valuable information and project input details for the successful initiative.

She consistently gave her valuable advice and time throughout the development phase of

the project.

I feel privileged in expressing my deep sense of gratitude and indebtedness to Mr. Ajay

Gupta, Director of Computer Resources, for devoting his precious time to this project. I

express my sincere thanks for his keen interest, valuable guidance and constant

encouragement during the whole process of developing this project.

I am also thankful to Dr Irwin B. Levinstein, Associate Professor, for providing

meaningful and critical advice and guidance to this project.

The vast experience of both, Mr. Gupta and Dr Levinstein was critical in making this a

meaningful and successful project.

Lastly I am thankful to Computer Science department, Old Dominion University for

providing me the opportunity to do this project. The congenial and co-operative

environment in our department gave me the necessary boost and support throughout the

duration of the project.

Old Dominion University 2


Index:

Introduction....................................................................................1

E1S ........................................................................................2

Motivation......................................................................................4

Analysis and Requirements Gathering

Generate E1S..................................................................5

Manage Funds................................................................6

Assumptions..................................................................................7

Development Phase and Technical Aspect...................................8

Validation of Student Information...............................................10

Architectural View.......................................................................12

Security Feature...........................................................................15

E-R Diagram................................................................................18

Functionality and Toolkits Provided

Administrator................................................................19

Faculty/Staff ................................................................19

Student..........................................................................20

Conclusion...................................................................................20

Future Work.................................................................................21

References....................................................................................22



Introduction:

In Old Dominion University, students are hired by professors or staff members for on-

campus work, such as Research Assistant, Teaching Assistant, Office Assistant, etc.

These on campus jobs provide good exposure to students and at the same time counts as

work experience for students. In order to ensure that different departments of University

can fund their students, Old Dominion University allocates funds to these departments.

Then a department internally divides the allocated fund among its staff and faculty

members appropriately. Faculty or staff member shortlists the students to be hired for the

particular semester on a particular allocated fund and sends their lists to the fiscal

technician of the department. The fiscal technician then, initiates the paperwork involved

in hiring a student. It becomes the job of fiscal technician to collect information about the

student from various resources, such as student themselves, Old Dominion University

administrative information system called Banner, which is a huge set of Oracle forms,

department’s files that contain photocopies of previous information on student which

may or may not be reliable and department’s spreadsheet, which may contain only first

name, last name and/or student UIN. Out of all the given resources only Banner is the

reliable source, as it contains correct UIN and correct name (spell checked) and other

most recently updated information of the student. However, Banner is a tool that provides

abundance of information and somewhat complicated paths and screens, thus could not

be considered a user friendly tool. Getting the relevant information form Banner may

become a challenge for the user. Also, after gathering all the personal details of the

student from these resources, the fiscal technician confirms with the supervisor for the

student hiring information such as start date, end date, stipend to be paid, number of work

hours, which fund to be charged for the students etc. It is a cumbersome and complex

process as it involves manual input from various entities and based on available tools and

components to complete the paperwork.

The existing system involves two processes as parallel and at the same time both

processes slightly depend on each other. Fiscal technician has to handle both the projects



simultaneously and ends up maintaining replicas of the same piece of information on

various spreadsheets or hard copies. However, going in depth of both processes reveals

that they are a pre-defined set of independent functions that should be handled separately

from each other.

E1S


Old Dominion University(State Fund)

Department(e.g. Computer Science)

Faculty and/or Staff Members

Students

Fund Flow Diagram


There is a student appointment document called E1S, provided by State funding

authority, which must be filled for each student hired on state fund ever semester. There

are certain predefined rules that must be followed to fill E1S while hiring, in terms of

data that goes in each field of the form and stringent validation for those values

depending on options checked on the form. Most importantly, the dates and calculations

are all put on manually though, the rules for dates and calculations are predefined by the

funding authorities. The finance department of the university accepts only duly filled E1S

paper document, within certain time period in order to release pay checks on time, for

students.

E1S is one of the main documents. It flows around student, fiscal technician, supervisor

and head of department budget unit till all required information is duly filled. Finally this

document is sent to office of finance.


E1S Document


The process of E1S floating around various entities is as follows:

E1S is the core document of the entire hire process for a student on a state fund granted to

the department. It gets extremely complicated in terms of predefined rules on validating

data on E1S and predefined date specifications.

Motivation

The whole process of appointing students involved many entities and tedious repetitive

manual work. The work is repetitive in the sense that once the personal details of a


Fiscal Technician

Student

Supervisor

Department Budget Head

Banner or Student Folders

Gets information

from one and/or all of these

resources

Fills E1S and send

it to budget

head for authorizat

ion

Sends the E1S back

Sends to Finance

department

E1S Flow Diagram


student is gathered in a semester and put on E1S, same procedure would occur next

semester for same student (if hired again) Being a master student of the department, I

aimed at providing a useful tool to the department and enhancing my own skill set, by

automating the manual parts of the entire process. Currently, same piece of information

is duplicated at many places which lead to redundancy. There is a need for a

consolidated and integrated database that provides global access to the entities involved

in the complete process of appointment.

Also, many calculations are involved during the appointment and due to human

intervention; there is higher risk of errors and mistakes. Moreover, appointment is a huge

time consuming process, as it occurs ever semester for about 30-50 students and the

repetitive nature of the work makes the process quite tedious and inefficient. A fiscal

technician faces another set of complications when it comes to remembering pre-defined

rules set by the University in order to do the hiring paperwork of the student.

This project is not aimed at only automization but also, using state of the art technology

to enhance the existing system in the fiscal office of Computer Science department. In

fact, the basic requirements for student appointment and managing fund flow are same

throughout the university; this project is potentially expandable to all departments of the

university. It provides direct access to faculty and staff about information pertained to

their funds and students hired by them. It has inbuilt rules as pre-defined by the

University and does automatic calculations thus making the system more reliable. Most

importantly it saves trees, as it aims at minimizing use of paper to store information in

CS Fiscal office. Maintaining database on paper copies also is ineffective in terms of

availability as it cannot be retrieved from anywhere at the same time by different users at

different locations.

Analysis and Requirements Gathering:



In the initial phase of the project, the process of appointing student and the process of

managing funds within the department had to be extracted distinctively from all the

existing processes. Each of this process is further categorized into different components

as follows:

To Generate E1S:

E1S is the final end document that is submitted to office of finance with complete and

correct details. In order to fill it correctly following pieces of information is required:

Student Personal Details

Employment Details

Predefined dates

I9 Data

Tuition Exemption

To Manage Funds:

Department is granted limited funds and these funds must be utilized appropriately before

the end of fiscal year; else the balance left on them is taken back by the university.

Through out the hiring process it is equally important to manage the fund flow of

department funds, within department and with other departments.

Department Allocation of Fund

Distribute funds among Staff and Faculty

Balancing funds between planned and actually spend

Scrutinizing the facts and existing process, it was discovered that both these processes

gets affected by each other, and at the same time run parallel to each other.



Initially funds are allocated to the department at the beginning of the fiscal year. Then

these funds are distributed among various faculty members and staff members. But the

flow of funds within the department is not stagnant for one time only. The flow of fund

within the department or with other departments in the university could be any time in the

fiscal year.

The process of student hiring is unaware of the dependency of the fund management

process. A student can not be hired under a supervisor on a particular fund, if the

supervisor does not have any balance left in that account. It is quite important for the

fiscal technician to maintain a balance sheet with updated expenses and left over

balances. At the same time hiring a student involves a set of completely different rules

and a set of different components (as given above) are involved.

Another important component discovered during analysis was the time and effort spend

on getting the E1S signed by the authorized faculty members. Thus, a concept of digital

signature was introduced in the project though the Finance Office do not accepts E1S

with digital signature currently. Digital signature is a tool introduced in this project more

like a proof of concept rather any actual implementation.

Assumptions

This project is designed and developed in restricted environment with real world based

requirements and situations. However, the issue of software development is the ever-

changing environment elements that must be considered to ensure the extensibility of the

software designed. This project is developed based on the current requirements and tools

and technology available. There is a dire need to explicitly mention the pre-assumed

elements of this project:



1) The office of finance accepts only hard copies of E1S documents

2) Information about granted funds to the department is manually provided to

the fiscal technician and must be fed into the system.

3) Leoonline service provided by Old Dominion University remains

unchanged.

4) Students keep their information updated in Leoonline.

5) Currently digital signature of faculty or staff member is not accepted.

Development Phase and Technical Aspect

The Project was developed more like an agile product, started as prototype model. With

constant inputs from supervisor and fiscal technician it developed and was enhanced at

every step.

The technical aspect of the project was to determine the most suitable approach to find

the solution for the identified processes and its issues. One of the issue was that even E1S

will be created and processed electronically, still a paper copy would be needed in the

end. The balance sheet of funds could be maintained in spreadsheet, but the requirements

showed additional functionalities that are not available in spreadsheets.

The first step in development process was to underline the technologies suitable for the

project. With the aim to provide global access to the pertinent information from students

to faculty to fiscal technician ensured that it must be web based portal. The complete

project is designed in .Net 2005 C# and scripting in JavaScript, style sheets CSS, xhtml,

html, xml and Java Applet.

The most important output this project is expected to produce is E1S. As shown above

E1S is a complicated, and a big form to be produced. Among the options that E1S be

designed as a web form or PDF form, I choose PDF form. An E1S designed as web form

was not suitable for the issue in hand, because the office of Finance requires a hard copy



of duly filled E1S. Printing a Webform off various printers would result in various

formats depending upon the settings of the printer. There were two options for PDF form

as well, in which the entire E1S document is either saved in FDF format which contains

both data and form elements. The second option was to save form elements in form of

FDF form and save data in the database. The second option is applied in this project so

that a centralized database can be created and maintained for the data for reusability

purpose.

In order to produce the E1S document in a PDF format, the code utilizes two .Net dll files

i.e. TallComponents.Pdf.Kit.dll and itextsharp.dll. Both these files are third party open

source code. The iTextSharp is a C# version of a Java library that was written to support

the creation and manipulation of PDF. With the iTextSharp DLL, it is possible to not

only populate fields in an existing PDF document but also to dynamically create PDFs.

And the 2nd dll, PDFKit.Net allows user to edit and access all aspects of a PDF

document. It provides functionality to access the fields contained in the PDF form and

helps manipulation the values of those fields before saving the file as a new document or

printing it. Both these dlls required fully support the creation of PDF documents on the

fly, thus it saved the system from saving multiple copies of the same file at multiple

locations. Now, whenever a user needs to pull old data values on E1S or create a brand

new E1S, it creates a new document on the fly based on data in the database.

One of the state of the art technology used in the project is GoogleChartSharp.dll. This

API is a web service provided by Google which creates different variety of charts on the

fly based on the parameters passed to the web service. This 3 rd party technology is used

to display the fund related information for various faculty, staff members and department

funds. It converts and displays, the hard to read and hard to understand big numerical

figures into pretty looking, pictorial and .representation. These graphs are not stored but

are dynamically generated through Google API and display meaningful information

with much precise details.

The project is implemented with extensive use of Ajax components. Ajax technology is

not new to the web, though until recently its pros were not widely known and accepted.



Ajax components are mainly used to develop the tool with sophisticated user friendly

screens. Accordion is one of the AJAX enhanced component of .net which acts like a

Switch case based collapsible panel that is extensively used in this tool for funds

managing screens. Update panels are used on each and every screen of the project. Due to

Ajax update panel on the screen, the user does not realize the flicker caused due to post

back event on any page of the website. To incorporate Ajax components, .Net Ajax

Control Toolkit is implemented, which is a shared source project built on top of the

Microsoft ASP.NET AJAX framework. This Ajax Control Toolkit is a combined venture

between Microsoft and the ASP.NET AJAX open source community. This toolkit

provides a powerful infrastructure to write reusable, customizable and extensible

ASP.NET AJAX extenders and controls, as well as a rich array of controls that can be

used out of the box to create an interactive Web experience.

One of the most important technical aspects of the project is a tool called Digital

Signature, which is implemented not for practical use at the present time but more as a

proof of concept. Digital signature, here does not refer to the cryptographic techniques of

signing digital documents, however, it is more like a replica of the manual signature is

stored electronically into database and is used as image on the forms. This tool is

implemented as Java Applet and is incorporated in .net using html tags. It is coded in

Java and it basically picks up the mouse co-ordinates to create the image on the screen.

Then the screen is saved in an image format into database. The Java code handles the

issue of converting the Image file into valid hash code, thus the signature in database is

completely secured and cannot be stolen. It is not a cryptographic encoded signature on

the electronic copy of document, but it is a hash encoded image on the document so that a

hard copy of the document could be practically used, in the given scenario.

Validation of Student Information



One of the major issues of current system is validating the information. A fiscal

technician can get student information from different sources such as Banner provided by

OCCS, Student records such as previous E1S from student folders (if any) or student

themselves. Banner is quite complicated tool provided by OCCS built on Oracle forms

and could be considered most reliable source of information because it contains the

updated information about the student as is recorded in registrars system. The existing

system is to get personal details of student from student themselves and then check their

registration information from university Banner by manually crawling through

complicated screens and get required data out of bulk of data provided. Then all this

information was put on a paper copy of E1S. This process is followed for every student

on state fund, in every semester.

The major task of the project was to solve the issue to retrieve student information from

reliable source. The project has a portal for student where they can view and update their

personal information. However, students do maintain their updated information in

leoonline as well, which ultimately stores data in University Banner. It is a truism in the

database world that one do not want to have multiple sources for the same data. This is a

bad redundancy and a source of inconsistency, requiring the student to update two

databases. We need to have just one source of information. Thus the approach was to

ensure correct and validated data entered into the system and also, minimize number of

resources responsible for data to make it an efficient and less time consuming process.

The common link between students and banner is Leoonline. It is third party software

developed explicitly for Old Dominion University. It is developed with secured

certificates and is developed in PLSQL web technologies. It was most suited component

for the project because it is a web based portal and is directly connected to Banner

database. A user can access only his/her personal information from leoonline using their

University Identification Number (UIN) and PIN which basically acts as credentials for

the user to retrieve information pertained to the user’s profile.



I used the concept of Screen Scraping to retrieve information of the user based on the

credentials provided by the student. Screen Scraping is a technique to extract data from

the displayed output of the web pages. The concept is to get data from the respective

server and maintaining all the properties of a web browser. Another technical term for

this process is called harvesting. It is quite common concept for websites that contain

ever changing data and if user wishes to utilize that data for their own purpose such as to

store it in their own database etc, or utilize it in their customized programs. Basically an

application acts as web crawler and copies the content from the required website.

However this is not a new technique, before the existence of webservices, this was one of

the few techniques to get access to remote information.

In this Project, a portal is provided specifically for students. Student enters their UIN and

PIN to the portal and using their credentials, the system creates an instance of

HttpWebClient and post all required headers. Once this process is initiated the system

tries to replicate the behavior of a web client and crawls through the Student’s leoonline

web pages to retrieve personal details of the student. Student get to see all the retrieved

information that system gets from leoonline such as student name, address, phone

number, credit hours etc. Student must hit update button on the system in order to update

or submit their information in the tool.

Architectural View

Software development process is almost always vulnerable to ever changing requirements

and may fail after a certain point of extension. This project is designed keeping in view

that it would be enhanced and extended as per future requirements. Thus it is designed as

layered software and restrained to as minimal interactions between layers/tiers as much

possible.

The system is designed as 4-tier architecture:



1. Business Objects

2. Data Access Layer

3. User Interface

4. Backend Database

The most commonly used 3-tier architecture is proven and one of the best practice to

develop software as database and user interface is connected through data access layer. It

not just provides security but is unconditionally accepted as best programming practice

for re-usability and extensibility. The 4th tier in this project is the Business Objects.

Business objects are an attempt to replicate real world entities and rules in terms of

classes and objects. It is quite important to distinct these rules and policies prevalent in

the existing system and extract them into a separate layer rather than obsolete method of

embedding these rules in User Interface layer or Data Access layer.



The backend is implemented in SQL EXPRESS 2005. All tables, procedures, triggers etc

are built in SQL. Front End also commonly referred as User Interface is built on state of

the art web technologies. It is a combination of Ajax components, JavaScript used for

client side validation, CSS style sheets and master pages for consistent look and feel of

the entire portal. Data Access layer is built using C# and ADODB.Net. All functions in

data access layer are accrued in AppCode folder of the project. Any interaction of User

Interface or business objects to the database is directed through Data Access Layer only.

The most recently discovered tier, Business Objects is implemented though a hierarchal

objects mirrored to real time rules and scenarios. For e.g. a student if is international then

cannot be hired more than 20 hrs a week. This rule is not hard coded in front end, or data

access layer, instead it read from the student object. The properties of student are read

and if discovered to be international then maximum work hours allowed are set to 20 per

week. If in future this rule is changed and international students are permitted to work 25

hrs in a week then only change in the backend coding is to reset the object property to


Front End Pages(HTML, AJAX, etc.)

Business LogicLayer (BLL)

(Objects)Database

(SQL Server)

Data Access Layer (DAL) (Class File)


maximum value of 25. All other tiers will be completely unaffected by this change.

Business objects are coded in C# objects but their functionality is mush similar to

configuration files, however the objects in this layer are much closer to real-life entities,

thus making them much easier to understand rather than a configuration file.

Security Feature

This project deals with sensitive information such as student personal data and

department’s financial statistics, therefore security is of utmost importance in the

successful completion our objective. Security is not a third party plug that could be

implemented at a specified part of the project, but it is implemented at each layer.

Various techniques of security are implemented at each level and at each step of the

entire process that the project follows.

Main security steps in the project are as follows:

Login Profiles: In order to access the tool a user must have a username or

password. All the WebPages are secured and checked against the credentials

provided by user. Faculty or admin can log into from home page and based on

their profiles will get access to information pertained to them.

Passwords Encrypted: Additional security constraints are implemented at

database level by ensuring that login credentials are stored in hash encoded

format. This pushes the hacker few steps back and put additional constraints

even if some how he/she gets access to the credentials

Role based access to Information: There are basically three roles provided

by this portal, each providing tools depending upon the login profile. The

three profiles are Student, Staff and Administrator. Administrator has the

highest authority and access to all the tools. Administrator can create users,

fill out new hire information, update and manage funds information, maintain



history records for students and funds and print electronic filled E1S. Staff

profile allows faculty members to have access to information pertained to

their allotted funds and students hired under them. Staff profile can create

digital signatures and re-use it to authorize hiring documents.

Client layer Validation: Client layer validation is implemented at user

interface layer. It is the validation of data at client side before any sort of post

happens to the server. As mentioned earlier, it alone may not eradicate the

possibility of bad data being posted to the server, but this step adds another

security door for accidental mistakes or intentional attempt to corrupt the

system with bad data.

Protection against SQL injections: The system constructs many SQL

queries dynamically based on input from user. Thus, it is more susceptible to

dangers of SQL injections. This project treats every user input as unreliable

thus, it first validates at client layer first. Then next level of security is at the

code end where input is treated as literals and is filtered by sanitizing

unwanted characters from the input. The code leaves no room for parameter

manipulation with strict cleansing routines on all user inputs.

URL Manipulation: It is quite common for secured web based portal to

handle URL manipulation in an attempt to break into the portal. The system

explicitly ensures and restricts usage on every page based on login credentials.

It restricts crawling on each and every web page of the portal.

Authentication and Authorization: As a pre-destined feature of HTTP

protocol, a secured web portal is based on principles or authentication and

authorization. Authentication decides who can access the portal and

authorization checks the privileges of the authenticated user whether, he/she

can get access to the information or not.



Security is not one component but a set of doors and blocks for intentional or accidental

damage to the system. Security provides a defense system against unauthorized access to

information. With each feature explained above, the portal increases the depth of defense

against malign attacks.

E-R Diagram



Functionality and Toolkits Provided

Based on credentials, a user may belong to one of three profiles. These profiles provide

tools depending upon the role the login credentials belong to. The three profiles are

Student, Staff and Administrator.

Administrator:

The profile has the highest authority and access to all the tools. Administrator manages

department funds; funds allocated to various entities in the department and have full

access privileges to student information. Tools provided by the portal to Administrator

role are as follows:

Manage department funds

Manage funds allocated to faculty and staff

Fill and generate E1S electronically and print them

Access to student information

Create Finance reports on existing funds and balances

Maintain history records of students and funds

Create other users

Staff/Faculty Member

Staff profile allows staff/faculty members to have access to information pertained to their

allocated funds, the spending done against his/her own fund and get details of students

hired under them. Staff profile can create and save their digital signatures and re-use it to

authorize hiring documents. If a faculty/staff member is authorized to digitally sign E1S,

then the faculty would be able to sign it. Also, this profile can not modify but can print

E1S.



Student

Anonymous user, or student can get information about the upcoming due date for time

slips depending upon user’s system clock, next due date for E1S appointment document

as 7 days in advance then actual due date and next pay date again depending upon user’s

system clock.

Conclusion

The aim of this project was well defined and thus is very well implemented with state of

art technologies to attain the predefined goal. It aimed at providing a secured online

system that generates hiring paperwork, allows professor to digitally sign them and builds

reports for various flowing funds within the department. This is a web portal which

provides user-friendly easy to use tools that leaves 0% chance for error. It solves one of

the most known issues of validating student information through a time consuming

complicated process into an easy one click process with validated data. This project is

built for the fiscal domain of the Computer Science department. It provides secured web

portal with centralized and consistent database.



Future Work

One of most useful enhancement would be to add a feature of tracking the E1S among

various departments and internally within the department. I thought about incorporating

this feature in the project however, it was another large domain issue and thus it could not

be scoped to such higher level

Banner, the most reliable source of information for this system, if it can be directly

accessed though this portal, than it would save another set of time consuming issue for

the fiscal technician. Right now from Banner database, this project scraps the student

information only, though Leoonline website. However Banner also provides more

important pieces of information that are hidden down under complicated trees of screens.

The fiscal technician does use banner data for amounts allocated to various department

funds. An automization that would get all information to fiscal technician would be a big

enhancement to the project



References

1. Microsoft Programming .Net by Jeff Prosise Microsoft Press

2. Programming .Net Security by Freeman and Jones O’Reilly

3. http://weblogs.asp.net/pleloup/archive/2007/10/24/4-tier-architecture-in-asp-net-

with-c.aspx

4. http://www.asp.net/ajax/

5. .NET Screen Scraping in depth - http://aspalliance.com/236

6. http://www.tallpdf.net/

7. http://itextsharp.sourceforge.net/tutorial/index.html


http://itextsharp.sourceforge.net/tutorial/index.html

http://www.tallpdf.net/

http://aspalliance.com/236

http://www.asp.net/ajax/

http://weblogs.asp.net/pleloup/archive/2007/10/24/4-tier-architecture-in-asp-net-with-c.aspx

http://weblogs.asp.net/pleloup/archive/2007/10/24/4-tier-architecture-in-asp-net-with-c.aspx

Documents

MasterReport.doc