Design Overview

Our design process has two aspects: Frontend and Backend designs. We started with backend implementation because figuring out how the system should behave is the key to our success. If the system does not behave the way it should, everything else do not matter.

Project Schedule

Figure 1: Project schedule


  • Requirements acquisition
    • This is the phase where we collected information about what our sponsors envision in the resulting system.

  • Data Modeling
    • We begin creating our data model based on our client inputs.

  • Data Model Implementation
    • Implementation phase of our data model; this phase took the longest since we needed to keep updating the model.

  • API/Backend Implementation
    • We begin our system creation by implementing the backend functionalities. This is to overcome our technical unfamiliarity with authentication and other functional incorporation with Google App Engine.

  • Frontend Implementation
    • We started our frontend implementation to visualize the backend functionalities.

  • Testing
    • Module testing were done along with the implementation.

    Development process

    Figure 2: Development cycle


    We took iterative approach to implement the problem solution. Our approach was to do smaller cycle of planning, implementation, and testing, so iterative approach fits our design strategy the best.

  • Planning phase:
    • Figuring out how we should develop/implement our model.

  • Requirements phase:
    • Gather requirements information from our clients.

  • Analysis and Design phase:
    • Implement the data model and requirements to the system.

  • Testing phase:
    • Test the new implementation; make sure it does not break anything. Then go back to the beginning of the cycle.

    Communication Methods

  • Github
    • Our main method of reposting codes, presentation slides, documentations, and graphics needed to compose our system.

    Meething Schedule

  • Weekly meeting with our sponsors
    • We met with our sponsors each week to discuss our progress. Any problems, modifications, and other issues are discussed and resolved here.

  • Team meeting style
    • We met twice a week (and increasingly more often as the project winds down) to discuss the problems at hand and prioritize them.

    UML

    Figure 3: Zabeta system UML

    The above figure (Figure 3) represents our data model. Because we need to keep track of every change for possible future reference, every class inherits from the Version class.