Embed Size (px)
Citation preview
Final Report: Faculty Progress Report System Team Deadpool
Team Members and roles: - Adedoyin Aderibigbe (Scrum Master)
- [email protected] - Kelly Luk Bounsawat (Product Owner)
- [email protected] - Richa Surbhi
- [email protected] - Dongdong Huang
- [email protected] - Boyuan Gong
- [email protected] - Yu Zhang
- [email protected] Stakeholder - Kathy Waskom Links GitHub: https://github.com/boyuangongtamu/CSCE606_DeadPool Pivotal Tracker: https://www.pivotaltracker.com/n/projects/1979779 Heroku Application: https://limitless-dusk-95818.herokuapp.com
Username: [email protected] Password: aaaaaaaa
Customer Interview: https://drive.google.com/a/tamu.edu/file/d/0B6CRXlNePIFic2U1LWh5cjBkYUU/view?usp=sharing App demo: https://vimeo.com/216345506 Project Summary
The Faculty Progress Report (FPR) is a database, which consist of instructors’ evaluation metrics. In other words, it contains evaluation information for each professor in the Computer Science and Engineering Department. To further increase the user experience for the customer and any future user, the team was asked to add new features and fix some bugs within the FPR’s legacy code. Our stakeholder is the customer. The key components the customer wished to add
were: Exporting Data to Excel, Evaluation Data, Instructor List, Historical Data (2001 – 2009) and Calculations.
Based on the current implementation done by us, the customer is able to see the descending order and change the semester format from 2016A to SP16, 2016B to SU16 and 2016C to FA16 when exporting the data from the database to excel. In addition, the customer wanted to add a new column called number of respondents in the Evaluation Data to show the number of students that filled the evaluation form from PICA (Personalized Instructor/Course Appraisal System). Our implementation added that column which is displayed in the evaluation table and instructor page. This feature will enable the user to see the number of instructors’ evaluation respondents versus the number of students in the class. Another feature with the project we were given was that within the instructor list, there are duplicate professors within the list due to misspelling of their names. The issue cannot be fixed as it currently does not have a delete or hide button, so the customer wanted us to add a delete/hide button. However, due to the limited time, the complicated code content and the format, we were unable to implement this part of the project. Besides the hide button, the customer also wanted the instructors’ list to be ordered in alphabetical order by last names. Our implementation was able to implement this feature. Finally, PICA only has data from 2010 upwards, so the customer wanted us to add the ability to add historical data (2001 – 2009) into the database without doing any extra calculations, just data input. As of right now, our system is able to input historical data and not do any calculations with it.
User Stories and User Interface: User Story 1:
User story 1: the customer wanted a feature which would order the semester in descending order with the current semester on top when the data is being exported to excel. Customer also wanted us to change the semester format so that 2016A would change to SP16, 2016B to SU16 and 2016C to FA16. In terms of points in the pivotal tracker, we assigned 3 points to it since this would require messing with lots of different files in it. IMPLEMENTATION STATUS For implementation of user story 1, the legacy code did not sort the instructor’s term order when the data was exported to excel. By default, the term within the exported excel file is in ascending order. We revised the “controllers” files with the “sort” method and comparison operation to achieve the required descending order of term. Also, we changed the app’s “instructor_helper” to accomplish the term format reverting. SCREENSHOT OF WORKING VERSION
User Story 2:
User story 2: the customer would like the team to add a feature that would enable the user to add historical data without any calculations for the PICA data from before 2010 since the calculations have already been done in the historical data to be added.
IMPLEMENTATION STATUS For the implementation of historical data, as this is the new feature to the system. The most important issue for us to tackle is to merge the historical data into the system. The difference is that the customer do not want the historical data to be calculated again. Therefore, we added an additional column called “history” to distinguish historical data from PICA data. If the value of “history” is true, then the data will be shown without calculation. The major challenge we met during the implementation was how to import and parse the excel file correctly and how to show and export the data correctly. We referred to the legacy code for the importing framework, based on that, we wrote a new “importer” for historical data. We also modified a bunch of helper functions to show and export the data correctly. In addition, for historical data in “.xls” format, the user need to save it into “.xlsx” format and then it can be uploaded as well. SCREENSHOT OF WORKING VERSION
User Story 3:
User story 3: the customer wanted us to add in a button that enables users to delete or hide instructor’s names from the list, and show the instructor list in alphabetical order using their last name. In the beginning, the customer wanted to use UIN to identify each one of the instructors but eventually this requirement went away when we realized that we don’t have UIN numbers in any of the data that is imported into the file. IMPLEMENTATION STATUS In terms of implementing this part, we modified the instructor helper class and created a function called put_last_name. This function takes in the professor’s full name, parses it, takes the last string, adds a comma and insert it to the beginning of the name. Then, in the haml index file, we were able to call the function and the instructors were sorted based on their last name. Due to the complexity of link_to function in the haml, we had hard a time implementing the hide button.
SCREENSHOT OF WORKING VERSION
User Story 4:
User story 4: the customer wanted us to add a new column that shows the number of students that filled the evaluation form from PICA. In terms of points in the pivotal tracker, we assigned 3 points to it since this would require modifying the legacy code, and adding helper functions to calculate the total number of respondents per given course. IMPLEMENTATION STATUS For this user story, the customer wanted us to add number of respondent (number of students that filled the evaluation form) to the evaluation table. This was implemented by performing a migration which added a new column called number of responses. To populate the evaluation table with the response data, we updated the PICA import function to include number of response data. The export function was also updated to include the number of responses. Some other files were also updated so that this user story can be implemented correctly. Finally, the total number of responses for a given course was calculated. SCREENSHOT OF WORKING VERSION The image below shows that evaluation table with no “Responses” Column:
Here the image shows the evaluation table with the “Responses” Column and the summation of the responses for a given course/professor:
Our scrum master was Adedoyin Aderibigbe for all the iterations and Kelly Luk Bounsawat was the product owner. For each of the iterations, they held these positions. We decided to have these
people for these positions throughout the project for the consistency. We ended up focusing more on getting the user stories done and change of these positions might decrease the productivity. For iteration 0, we were just trying to understand the legacy code and got started on the User story 1. For iteration 1, we were able to complete user story 1 which was about the evaluation table and changing the 2016C to FA2016 and also making the downloaded excel sheet show the recent semesters first and older semesters later and this user story was worth 3 points.In iteration 2, we were able to add the number of responses from the PICA store in our system and this story was worth 2 points. We also had started on the instructors’ list part too in it and had one part of it working which gave us 1 out of 3 points. In iteration 3, we finished the instructor list part where instructors are showing as last name, first name basis on alphabetical order and thus we ended up getting 2 out 3 points for it. We haven’t been able to implement the hide/delete button for the instructor list yet due to the complexity of the haml code and also due to the tag of link_to part. For iteration 4, we implemented the historical data user story and the testing for that part of the code was also done. We also added two more customer meeting times and were able to show our progress to her. Customer meeting times
- February 15, 2017 at 10:00AM in HRBB 305C: Met with the customer to confirm an available time to meet. Original meeting time for February 15 at 3PM was cancelled.
- February 17, 2017 at 3:00PM in HRBB 305C: Team Deadpool met with the customer to hear her needs and what she expects from the project.
- February 22, 2017 at 3:00PM in HRBB 305C: Met with the customer to record the 2 minute video.
- February 23, 2017 at 2:00PM in HRBB 305C: Met with the customer to write out the user stories
- February 27, 2017 at 3:30PM in HRBB 305C: Team Deadpool met with the customer to get a sample of the historical data and the PICA data.
- 4/7/17 at 9:30AM: Met with Customer the customer to confirm the features currently done are what she was looking for. We also requested our customer to provide how calculations are made to confirm it with the current implementation.
- 4/17/17 at 3:30PM: Met with the customer to retrieve data samples to test current implementation for user story 4. She also explained how the values within the Evaluation table are being calculated. With this the team is able to start user story 5 for iteration 4.
- 5/4/17 at 2:00PM: Met with the customer to record the final video and to also deploy the application on her system. We also provided her with required information for the application.
BDD/TDD Behavior New Specs are generated to reflect the new features and changes made by the user story. Tests were created to make verify the new features. We used Rspec and cucumber to test our code. These were our results for: Running Cucumber: 73 scenarios (1 failed, 72 passed) 432 steps (1 failed, 1 skipped, 430 passed) 0m21.329s For cucumber scenarios, one test failed due to a routing issue. When selecting the upload button for Historical data, it sends it to evaluation/import_history. However it should be direct it to the evaluation table, ie. evaluation/show. Running Rspec: Coverage report generated for Cucumber Features, RSpec to /home/ubuntu/workspace/CSCE606_DeadPool/coverage. 812 / 1086 LOC (74.77%) covered. The 74% coverage accounts for the amount of code being covered. Partial error is due to routing that was not checked for and logic as to how the table is now generated compared to the initial table at iteration 0. Configuration Management Approach For our development process we often worked individually to develop features, and then a subset of the group met to review and evaluate changes before they were committed. Branches were created for development purposes and each of the team mate created their own branch and worked on features and then test cases were added. After the feature was working correctly, we pushed it to the master branch. Heroku In general, we didn’t have a lot of issues with running the legacy code on Heroku. The only big thing we had to worry about was to transfer the database there for the development purposes and there were times we needed to redo some steps to make the code push to heroku. But, there were some cases where code passed all tests locally and when it was deployed on Heroku, it crashed but we were able to move past the issue. Implementation Environment Development was mainly done on the Cloud9 by various users and there were no issues working in Cloud9 IDE during this project, the only negative point there would be the occasional speed reductions.
Tools - Key GEMs ● RubyXL: It is a well documented and actively developed library working with XLSX
files. ● Roo-XLS: a library for parsing and writing XLS files which is a closed source format.
Not as straightforward as RubyXL is, but adequate for legacy formats ● SimpleCov: A library to calculate the test coverage rates and generate reports. ● Ruby on Rails ● RSpec ● Cucumber ● Cloud9 ● Heroku
·
