EHS Aspects of a Virtual Environment (EAVE)

EHS Aspects of a Virtual Environment (EAVE) Team Puma Zachary Sproul Chris Hinkel James Schaefer Rob Close College of Engineering Technology, Environmental Management & Safety Department Lisa Greenwood John Morelli Faculty Coach Dr. Donald Boyd Project Overview Team PUMA designed a web-based application for the Civil Engineering Technology, Environmental Management & Safety (CETEMS) department at RIT. CETEMS contacted the Software Engineering department to sponsor a senior project for students enrolled in online environmental, health and safety management courses. Using EAVE, students may tour a virtual facility and interview the various employees whom are created by instructors. Students will also identify environmental aspects and impacts, as well as occupational health and safety hazards and risks, based on the information they gather about the activities of the simulated facility through their interviews with facility personnel. Another way students may identify EHS concerns is through visual observation of the virtual environment. Students will work either individually or in teams to turn in a completed EHS report. The professor of the course may log in to view and evaluate the students completed reports, to group students into project teams, and to create or modify virtual facility scenarios. The application will assist in the professor s evaluation of students reports by providing a standard entry format and by allowing the instructor to create an example report to serve as a key. Team PUMA provided the finished project, the documentation for operating the system, and other relevant project deliverables to the faculty advisor and the project sponsors. Basic Requirements The following are business goals as described in the project proposal submitted by CETEMS: Design a web-based platform that enables students to conduct a simulated EHS assessment of an industrial facility; Provide an instructor interface for evaluation of the student assessments, and for input of additional scenarios, facility characteristics and employees; Provide student user, instructor, and administrator manuals; and Provide design documentation and installation information for IT support staff. From these original goals, and analyzing requirements elicitation sessions with the project sponsors, Team PUMA identified the following goals: 1

Improve the students evaluation experience by making the assignment more interactive and easier to navigate. The project should assist the instructor in evaluating student submissions to make grading students facility evaluations easier. The project should encourage individual and team participation in the exercise. Team PUMA then took those goals and developed use cases separated by user class. The user classes are self-explanatory: instructors, students, and course assistants (graders). Course Instructor / Co-Instructors Login / Logout Manage Scenario (CRUD) Duplicate Scenario Run Scenario Manage Users (CRUD) Manage Teams (CRUD) View and Download Individual Workbooks Online View and Download Team Workbooks Online Student Login / Logout Run Scenario Edit Individual Workbook Send Aspects to the Team Workbook Edit the Team Workbook Course Assistant Login / Logout Run Scenario View and Download Individual Workbook(s) Online View and Download Team Workbook(s) Online These uses cases may then be defined using the following high-level requirements, separated by user-class: Instructor The instructor shall be able to create, tour (read), update, duplicate, and delete virtual scenarios. The instructor shall be able to create, set access, and delete users. The instructor shall be able to create, modify, and delete teams. The instructor shall be able to fill out a personal EHS assessment worksheet. The instructor shall be able to view and download a student s individual EHS assessment. 2

The instructor shall be able to view, comment on, and download a team s EHS assessment. Student The student shall be able to tour a virtual scenario. The student shall be able to fill out a personal EHS assessment worksheet. The student shall be able to send aspects to the team EHS assessment worksheet. Grader The student shall be able to tour a virtual scenario. The grader shall be able to fill out a personal EHS assessment worksheet. The grader shall be able to view and download a student s individual EHS assessment. The grader shall be able to view, comment on, and download a team s EHS assessment. Constraints The sponsors for the senior project had many ideas, some of which were out of scope or would have delayed implementation of core system features. The team decided early in the design process to avoid some of the proposed features that would make the application game-like, such as navigating an avatar through a 3D virtual facility, to ensure that the educational aspects of the project were completed. The technology and hardware restraints of the project were imposed by CAST s IT department. They decided to host the application on RIT s apps.rit.edu web-hosting server. As such, team PUMA had to use the technologies that were available to run on that server. RIT uses MySQL as a database, and allows the use of PHP or Perl for server-side code. Team PUMA decided to use PHP due to its wide adoption and the plentiful documentation and tutorials available. As the team was unfamiliar with PHP at the beginning of the project, the team was not aware of the benefits that using a framework could provide, and so did not adopt one to use. The server hosting the project is one of RIT s Apache servers. The resource limitations for the team were time and personnel. Team PUMA was composed of four members, as most senior project teams are, but all work allocation had to be assigned between the four. As some of the team worked full-time or had a full course load, time was also a major concern and constrained the amount of work that could be done. As the end of each quarter approached, the increased workload from other courses put a lot of pressure on the team to finish work on the current stage of development. Development Process Team PUMA followed a staged delivery software lifecycle model. 3

Figure 1: Diagram of the staged delivery software lifecycle model. Modified from Steve McConnell s Rapid Development Initially, the PUMA team worked with their sponsors to understand the software concept. Then, they elicited the requirements for the software from the sponsors and did an analysis of those requirements. As a result of this analysis, the team decided to break the project into four separate stages of delivery. Once the requirements were understood, the team designed EAVE s over-arching architecture. From here, the project entered a cycle that was repeated for each stage of the product delivery. First, a detailed design was developed that incorporated all of the features listed in for the current stage. Then that design was implemented, debugged, and tested. Finally, each stage was delivered to the sponsor for verification and validation. After each stage was delivered to the customer, the architectural design, requirements, and the software concept were all be revisited to verify that they were still up-to-date and valid before the next stage of development was begun. The project schedule in the section below explains the content of the stages in detail. Project Schedule: Planned and Actual Team PUMA based the project schedule on their staged delivery development process. 4

Stage 1 - Tour - Done by Week 11 20112 Manage Scenario (CRUD) Duplicate Scenario Run Scenario Stage 2 - Worksheet - Done by Week 4 20113 Fill Out Individual Workbook View Individual Workbooks Online Download Individual Workbooks Stage 3 - User Management - Done by Week 6 20113 Login / Logout User Management LDAP Authentication Stage 4 - Team - Done by Week 8 20113 Fill Out Team Workbook View Team Workbook(s) Online Download Submission(s) Stage 5 - Additional Features - Done by Week 10 20113 Additional features requested by sponsors, as time allowed System Design Architecture The execution architecture of EAVE follows the typical three-tiered web-service template: presentation, business, and data tiers. The presentation tier contains everything that the end user sees. This content is is controlled by the PHP code that is executed by the server and the HTML, JavaScript, and CSS code that is executed by the client machine. The business tier consists of the the algorithms, or logic, that defines how the system behaves. This tier is run entirely on the server using PHP classes and class methods to define the relationship between different elements of the tour. The data tier, the layer that contains all the information for the system, contains the MySQL database that stores all the data for the virtual tour, such as the employee names. 5

Figure 2: A view of the overall architectural design of the system. Presentation Layer: Instructors and students each have their own home page after logging in, but each tour page (facility map, department pages, and employee pages) can be accessed by either type of user. However, only instructors can edit the content of the tour while taking it, whereas students can only take the tour. The team designed each of the presentation-layer screens with a focus on incorporating all of the functionality required and on making the application as usable as possible. Business Layer: Component Diagram - The diagram below is another representation of the three tiers of the architecture of the system. It specifically shows how the different components communicate with each other and the two components that make up the Business Layer: The object structure and the bridge component. The user interacts with the presentation screens, which communicate with the bridge component in the business layer. The bridge component constructs MySQL queries and runs gathers the required data from the database in the data layer. It uses that data to construct the proper object(s), which it returns to the presentation screen. The presentation screen then has an object, which encapsulates the data that it needs to display for the user. 6

Figure 3: A view of the overall architectural design of the system. The Object Structure represents the objects of the system. One of the class diagrams is shown below. This class diagram represents all of the classes that are utilized in the tour portion of the application. 7

Figure 4: A view of the class structure of the system. 8

Data Layer: Database Schema - This diagram displays all of the different tables that are in the database at this stage of development, their attributes, and how they relate to other tables. Figure 5: A view of the database structure of the system. Process and Product Metrics To track our project and ensure that PUMA s goals of quality and efficiency are met, PUMA tracked and documented the following: Project Plan and Software Requirements Specification The project plan and requirements document was completed prior to starting the first stage and is available in a separate document. Project Schedule The project schedule was completed prior to starting the first stage and was periodically updated with current information. Some of the information tracked in the schedule was the estimation of time to complete a stage and estimation of time to complete a specific task in the stage. Actual time spent individually and as a team was tracked in separate spreadsheet documents, along with estimation accuracy. The project schedule also recorded task slippage. Defect Tracking Generic bug tracking, defects by module, and defects in documentation were tracked in a separate spreadsheet. The chart below shows the defects by module. 9

Test Metrics Testing was completed by the team using automated unit tests, usability tests, and acceptance tests. Automated testing was accomplished by using a test page that would call each bridge and object method and compare outputs to expected outputs. Usability tests were done informally by team members and formally by test-users composed of acquaintances of Team PUMA. The testusers were representative of a wide range of computer expertize and ages. They were guided through testing by a prepared test plan, and then answered a sort questionnaire. Results are recorded in a separate document. 10

With 10 users of varying ages and technical ability testing the system for usability, the test group overall felt that the program was easy to use and not frustrating. User Manuals Students, graders, and instructors all have access to a user manual that is customized to their access level. Documentation for IT Support Staff Documentation has been provided for Joel Yates, the IT staff person for CAST. This information is recorded in a separate document that will enable the CAST IT department to be able to provide continued support for EAVE. Product State at Time of Delivery The product is complete. All four planned stages are complete, according to the specifications of the sponsors prior to starting each stage. There are many unplanned features that were added: support for multiple course sections being given access at the same time, relabeling and reordering worksheet elements, recording which employees a user has spoken to, as well as numerous other incidental features. There were not really any discrepancies between what was explicitly promised and what was delivered. This was accomplished by in-depth requirements interviews at the start of Senior Project and before the start of each stage. However, there were discrepancies between the finished product and the sponsors initial vision and unaddressed unspoken requirements. 11

The sponsors initially were very interested in a video game level of interactivity, rather than a more modest, modifiable, homework assignment. Team PUMA did not feel that creating a videogame-like product (with aspects described as Assassin Creed or Second Life like) would lead toward a successful product that would both be interactive for the students who would use the system and easily modifiable by the instructor who needed to maintain the scenarios in the system. The graphics and gameplay elements that would have been necessary would have taken far too much time to implement, which would have caused core functionality to be missed. In addition, while the team could have put together a very interactive experience for the students, instructors would not have an easy time modifying the tour after its creation. After relating these trade-offs to the sponsors, they agreed to focus on functionality over interface. It was the unspoken requirements, also known as assumed requirements, that caused us difficulty. For instance, Team PUMA didn t consider that courses from multiple sections might take the course at the same time, even though that is an obvious issue. Team PUMA also encountered difficulty with changing requirements or changing opinions. For instance, one of the sponsors asked for a change in a feature that they had been shown to them and tacitly approved by them four weeks prior. For both these issues, Team PUMA attempted to mitigate the risk by frequently communicating with the sponsors via email, personally demonstrating the product at the end of each stage, and giving the sponsors constant access to the project hosted by RIT. Project Reflection Our elicitation process worked very well. Our sponsors were a little unsure of the scope and specifics of the end-product at first and had many ideas for functionality within the project. Team PUMA found that brainstorming sessions within the team, coupled with presenting the results of brainstorming to the sponsors, led to a pretty well-defined scope and list of requirements. Unfortunately, our team never took the time to whittle down the broad requirements into multiple fine-grained requirements. Requirements were elicited through interviews with the sponsors, paper prototypes, and examination of the existing solution. The input of the sponsors, as well as their sign-off of all the use cases, helped ensure that no requirements were missed. The team has been communicating pretty well with project sponsors, including weekly emails, individual, and team meetings. Team PUMA believes that the sponsors are satisfied with the level of communication. Interaction with the sponsors declined steadily throughout the quarter as implementation of the project began. These schedule changes were initiated by the team and approved by the sponsors. This is an effective team, despite schoolwork from other classes that detracted from the team s effectiveness. The team s weak points are other classes, disorganization, different levels of PHP competency, and poor time-management. There was an instance at the end of the first quarter where peer reviews seemed to reflect poorly on two of the group members. However, the team s strong points are camaraderie, motivation, and enthusiasm for the project. The team came together to support each other to ensure that all the members of the team were recognized for their contributions. 12