Fast Pass Parking
Project Legacy
COP4431C, Fall, 2014
Modification history:
Version | Date | Who | Comment |
v1.0 | 11/24/14 | Kyle Mera | First half of the Analysis section |
... |
| Ivan Lugo | Second half of Analysis section |
Team Name: Group 13 - Fast Pass Parking
Team Members:
Roles
- Physical server setup: 100%
- Back end source code (server / database): 33%
- IOS mobile phone source code: 20%
- iOS B2B mobile phone source code: 20%
- Software Requirements Specification: 75%
- Project Legacy: 50%
- High Level Design: 25%
- Detailed Design: 20%
- Con-ops: 16%
- First Presentation Slide-show: 16%
- iOS user application: 33%
- Team support & Bug fixes: 50%
- Back end testing / fixes: 5%
- High Level Design: 40%
- Team website: 100%
- In-class First Presentation: 16%
- Project Legacy: 50%
- Deliverables clean up & submission
- Back end source code (server / database): 28%
- iOS B2B mobile phone source code: 80%
- Test Plan: 100%
- Test Results: 100%
- In-class first presentation: 16%
- Back end source code (server/database) 33%
- Back end testing/ fixes 5%
- iOS mobile phone source code: 3%
- Project Management Plan 100%
- Detailed Design: 20%
- First Presentation Slideshow 16%
- Final Presentation Slideshow 100%
- iOS mobile phone source code 40%
- iOS mobile phone storyboard (UI/UX) 80%
- Team support & Bug fixes: 30%
- Concepts and Operations 100%
- User Manual 100%
- Team Lessons Learned 16%
- First Presentation Slideshow 16%
- Detailed Design 40%
- High Level Design 33%
- iOS mobile phone source code 33%
- iOS mobile phone storyboard (UI/UX) 20%
- Team support & Bug fixes: 20%
- Team Lessons Learned 16%
- First Presentation Slideshow 16%
- Detailed Design 20%
- In-class first presentation: 16%
- Final presentation: 16%
Analysis
- Assessment of the Quality of the Final Product: Our product firmly meets the expectations set by our group at the beginning of the semester. The user application is simple to understand and use, which was a top priority. The speed of querying the database is exceptionally fast. The rendering of maps in real time works without issues. The only circumstance that makes this application difficult to implement in the real world would be validating all the parking lot owners to ensure they truly own the lot they say they do.
- Recommended Use of the Final Product: This application should be used by all iphone users who seek to simplify their daunting parking situations. The enterprise application should be used by all parking lot owners who want to provide users a modern parking solution in their parking lot.
- Known Problems: Our final build of the application has no known problems when tested on all functional requirements. Any error that occurs while running the application will throw an error rather than crash the application.
- Adherence to Project Plan: We completed all software requirements that we initially set out at the beginning of the semester. The only exception to this is ticketing a user which we decided not to implement due to legality issues. Initially we thought we would be able to implement all of our stretch goals but they turned out too much to finish by the deadline. The root cause of these deviations was a lack of time management by our developers.
- Defect Analysis: `From the beginning of our project lifecycle, our team adhered to the Agile method of feature development extremely well. Features and goals were vetted, planned, and implemented all within the span of one to two weeks. This agile process kept our logged defects to a minimum, as additional features were constructive and required little regression testing. As our project development moved from a fledgling to a more mature state, we began to log even fewer defects in our online issue tracking channels - we preferred to quickly communicate an issue, and work together simultaneously to solve it. There were no defects logged that lasted more than 2 sprints.
- Quality Assurance: The QA performed by our group were sufficient for our needs, and helped to finish the project to 100% completion. At time of demo, there were no known issues in the code base. No team member specifically mentioned improved QA strategies - our Agile development cycle kept that need to a minimum.
- Configuration Management: Our use of GitHub for both of the client applications and the server-side project implementations were more than adequate. In the future, we may want to use feature branches, but the scope of individual features never seemed to outweigh the potential time sinks of merging multiple branches together.
- Suggestions for the Future: Decreasing the time between our meetings would have potentially accelerated our progress as a team to create deliverable features as the semester went on. Recommendations for future teams, as mentioned before many times, is to start early. Too often, members will assume a programming task is easy, and overplan and overcommit to functionality. However, without having the true experience of laying down lines of code and discovering subtleties of a problem and your own solution, a team member is doomed to struggle against the clock.
Template created by G. Walton (GWalton@mail.ucf.edu) on Octber 8, 1999 and last modified on August 15, 2000.