Ashley Montebello – CprE
Katie Githens – SE
Wayne Rowcliffe – SE
Advisor/Client: Akhilesh Tyagi
Problem Statement
 The ECpE department currently manually sends out
emails containing review forms to graduate students
and faculty to evaluate graduate student progress.
 This process is not very efficient and requires constant
interaction in order to complete the review process
between students, faculty, and the graduate committee.
Need Statement
 The ECpE department would like an automated
system to complete gradate student reviews. Updates
to the process will include:
 Automating the email process for students, faculty, and
the graduate committee.
 Automating the user creation process by creating
accounts from the College of Engineering database.
 Storing data to a database will make the review process
much easier for the graduate committee (easily sort
students and their progress for review)
System Description
 We have received the Computer Science department’s
GProgress system as a starting point for our system
 Adapt current Computer Science GProgress system to
fit Electrical & Computer Engineering department
requirements
 General changes to forms to fit ECpE needs
 Replace current login process with IAState login system
 Create user accounts from College of Engineering
database instead of manually
 Make changes to user interface to make system more
user-friendly
Conceptual Diagram
Operating Environment
 Front-End Environment
 Access the system through a supported web browser
 Back-End Environment
 Apache Tomcat web server running Java
 SQL database
Non-Functional Requirements
 Security
 Use the IAState login system for user authentication
 Extensibility
 Integrate with College of Engineering graduate student
database
Functional Requirements
 All Users
 Update account information
 Must login to the system to gain access to features
 Admin
 Add, edit, search and delete accounts, courses, reporting
periods and rating scales
 Students
 Edit and submit evaluation
 Edit background information
Functional Requirements
 Faculty/Professors
 Edit and submit advisee rating
 View their students’ evaluations by reporting period
 Graduate Committee
 View student and professor ratings for each student
Assumptions & Technology
Considerations
 Received code for GProgress provides a fully functional
system
 Users have a web browser that can render the web
pages
 Users know how to use the web browser to navigate
pages
 Users are familiar with completing and submitting
forms
Deliverables
 SQL Database to store necessary information
 JSP pages, Java classes needed to run the website
 User guides will be made part of the website
 System documentation
Tasks & Schedule
Risks & Mitigations
Risk
Mitigation
If GProgress system and code is not well 1) Get system documentation and code
documented it may take more time
as early as possible
than expected to understand the code.
2) Begin reviewing code Fall semester
so we can start development right
away in the spring
Depending on system design, it may be
difficult to integrate with desired
systems (IAState for login, CoE
database)
Do more research in this area to find
alternatives. Worst case scenario: use
system as it exists currently.
Cost Estimate
 Software – FREE (open source)
 Hours (400): $8000
Software
 Apache Tomcat 5.0 or above
 JRE 1.5.0 or above
 MySQL 5.1 or above
System Design
 Java Server Page (JSP)
 “View” component
 Apache Struts 1.2
 Used to help keep MVC
structure
 Hibernate 3.0
 For mapping Java
objects to the database
Apache Struts
 JSP serves as the “View”
 Controller Servlet is the
“Controller”
 Controller manages
communication
between actions and
action forms through
struts-config.xml file
 Action Forms and
ActionForm Beans are
the “Model”
Hibernate
 Object-relation mapping
(ORM) solution that
maps Java objects to
relational databases
 JavaBean classes mapped
to corresponding table
using XML mapping file
 hibernate.cfg.xml file is
used to configure
Hibernate
User Interface Specification
 Four different views
 Administrator
 Faculty
 Student
 Graduate Committee
 Depending on user’s permissions they will have access
to various options in the system
User Login
New User Login
Admin Home Page
New Admin Home Page
Student Evaluation
New Student Evaluation
Testing Plan
 Login/Logout
 Make sure login uses the engineering servers correctly
 Make sure once logged in, a user has the proper
privileges
 Make sure logging out clears the user’s information
 Form Submission
 Ensure that forms contain the desired information
 Ensure that the forms are saved to the server correctly
 Ensure that the user can see the relevant forms
Testing Plan
 Email Notifications
 Ensure that email notifications are sent when evaluation
period begins
 Ensure that faculty are emailed when students submit
their self-evaluation
 Ensure that the graduate committee is emailed when
faculty have finished their evaluations
Testing Plan
 Security
 Test that private data requires the proper
login/password to access
 Test against SQL injection
 Load Testing
 Test that the system can hold up to the expected load
Current Status
 Received source code from Computer Science
department
 Working on understanding the given code to begin
making changes to forms to fit ECpE department
needs
Questions?