You have to trust your team.
The capstone project will be a site designed around a central theme, which must be a viable business model. A viable business model does not necessarily require the model be profitable. But it does require that the site have a real world application and be viable for immediate deployment. Some example viable business models are:
- Map of local restaurants
- Recipe database
- Map of New Mexico hiking trails
- Local events calendar
- Job posting site
Any theme that can be applied to viable business model can be used. The models listed above are examples and are by no means exhaustive.
Sprints & Tickets
The capstone project shall be divided into four sprints, each of which will have a duration of approximately two weeks. The sprints are:
- Sprint 1: Planning, Data Design, Classes, and MySQL
Create your user-driven design documentation, all base classes and enable PHP to communicate with mySQL.
- Sprint 2: Unit Testing and Sample Data
Build unit tests for all major pieces of functionality, and populate data from external APIs or by manual input of sample data
- Sprint 3: REST and Static UI
Create API endpoint to expose entities. Build basic static frontend fonts and colors and choose logos and branding for the site.
- Sprint 4: React Frontend
In each sprint, each team member will be responsible for several tickets. Each ticket will consist of approximately eight hours of work to complete. Tickets will be signed off by instructors if and only if the following are true:
- The ticket's functionality is complete
- The code is fully commented and includes all required doc blocks
- All applicable unit tests are present and pass with sufficient coverage (normally ≥ 80% coverage)
The team may not proceed to the next sprint until all members have completed all their outstanding tickets. In the event one or more members cannot complete outstanding tickets, additional team members will be deployed to help complete the outstanding tickets.
Table 1 depicts the technologies used in the capstone project. Use of optional technologies will be done sparingly and at the discretion of the instructors. Overuse of optional technologies detracts from the coverage of required technologies. Optional technologies will only be deployed when use cases lend themselves to the use of optional technologies. Optional technologies will NOT be deployed for the sake of deploying additional technologies.
|Required Technologies||Optional Technologies|
† JSON preferred. XML considered only if JSON is unavailable.