Modification history:

Team Name: The Spungos' Turbo Wallhacks

Team Members:

• Alex Berliner; alexberliner@knights.ucf.edu
• Christopher Kovaleski; ckovaleski@knights.ucf.edu
• Oscar Hedblad; oscarhedblad@gmail.com
• Luis Duque; luisduque23@gmail.com
• Alan Birmaher; abirmaher@knights.ucf.edu
• Jimmie Potts; jimmie.potts@knights.ucf.edu

Roles

Deliverables 1

Deliverables 2

Deliverables 3

Coding and Testing

Analysis

• Assessment of the Quality of the Final Product: Our project works at satisfactory standards. Although, it wasn’t exactly how we envisioned it (which is not necessarily a bad thing), it does do what it was made to do and does work with full functionality, and that is what is important. Users are able to log in via Twitter, view top challenges, save challenges, send and create new challenges, as well as there is a rating system in order to determine most popular or “liked” challenges. Also, admins have full access and control of the database and application.


• Recommended Use of the Final Product: This application is intended to be used by people who are looking for some social entertainment with other users by sending existing or personally created challenges. The only restriction for people to be able to use this application is they must have a Twitter account and a working android device for the application to run. In the future, we hope to expand to other forms of social media and possibly IOS devices.


• Known Problems: Overall, our application has full functionality in all the major aspects that we promised to deliver as stated above in the Assessment of the Quality of the Final Product. There are very few minor bugs that were found, but are easily fixable.


• Adherence to Project Plan: Throughout most the the project, we were able to adhere to our specific project plan. There were a few instances where not everything went as planned, and we fell behind at some points, but overall they were minor instances, and all major project deadlines were met. Every time a portion of our project was behind, the group members pitched in to get everything up to speed.


• Defect Analysis: Due to our use of the Agile Development Plan, we encountered very few defects throughout project development. Also, because of the nature of our application, the defects that we found were easily detected and easily fixable. From the start, we were able to come up with a good and achievable design for application, and few modifications were made during the development process. While at the beginning of the project, our goal was to avoid having to use a database to store information, we realized that to achieve the best possible quality for our product, a database was needed. Minor bugs were found during the coding stage, but most were addressed, and we will continue to polish the code.


• Quality Assurance: Quality assurance for this project went rather smoothly for our project. Not much quality assurance was necessary at the beginning stages of the project, as most of it was merely documentation. Once we began coding, continuous testing was done to ensure each component ran smoothly. Testing was done in an acceptable time frame. When coding was almost completely finished, tests were ran to spot bugs and to ensure the app worked in different scenarios.


• Configuration Management: The Configuration Management practices we had were sufficient. Much of it was due to the fact that we kept in constant communication throughout the entire project. Changes to documentation or code were realized by every party involved in the specific area that changes were made to. In the future, maybe having a formal document for every change made specifying the person, date, and description of the edit made would be helpful, although not always necessary.


• Suggestions for the Future: For future projects, it would be beneficial to the group if a specific schedule of work times would be set in advance for members to work on the project. This was tougher to do as each group member’s class and work schedules were very different and varied from week to week, but this would definitely help for projects of much larger scale. Also, as mentioned under Configuration Management, a document to help track every change made by each member would be beneficial and even essential for a project with many more contributors to the project.

Template created by G. Walton (GWalton@mail.ucf.edu) on March 28, 1999 and last modified on August 15, 2000

This page last modified by Alan Birmaher on 11/25/14