Sprint 1

#Sprint 1# ##Meeting Location/Time##

• Coordinated online
• Friday, Mar 25th, 2016
• 3:00pm to end-of-day.

##Attendees##

1. Dale Brauer
2. Gaofei Zhao
3. Kenny Clark
4. Robert Fink
5. Xiang Li

#Sprint 1 - Milestone Targets# ##General## ###Sprint Documentation###

• Created GitHub wiki documentation on Sprint 1: Kenny
• Work aggregated from multiple google drive documents: Whole group

###Complete Setup of Azure###

• Azure setup complete: Dale
• Link to proof of setup: Link

###Organize GitHub Repo###

• At this stage with not much code, we have not managed to do this other then making sure all of us can access it.

###(Addon) Continue working on RAD###

• We decided to allocate some of our time to working on the RAD a little bit before Sprint 2, in order to give ourselves more time for development during Sprint 2.
• Focus on Use Cases: Gaofei
• Review and fixes from group "speed-dating" feedback: Whole group

##Database## ###Finalize ERD###

• Finalized ERD after speaking with other groups: Robert

###Creation DDL###

• Created SQL file to import ERD: Robert
• Edited SQL file to import ERD: Dale

###Seed Data for development###

• Data was seeded into the database: Robert

##User Interface## ###Complete design of the user interface###

• Completed design of all (excluding the ones we are unsure of implementing by sprint 2) of the user interface (screens): Kenny, Xiang, Gaofei
• Link to our Google Drive folder containing all of the UI screens: Google Drive: UI Screens

###Complete Design of the information architecture.

• A system of numbering has been overlaid on top of the UI screen designs. The numbers correspond to explanations of functionality found at the bottom of the page.

##Testing and Documentation##

• Section created: Dale

###User Acceptance Test Scenarios###

• Requirement: The system must have quick response times to various user interactions.
  • The users who perform the acceptance testing will be asked to give a rating of the overall responsiveness of the system throughout the various tasks. A rating of 3.5/5 or higher will indicate success.
• Requirement: The system will allow users to register a personal/company profile, provided they have a valid email address.
  • The users who perform the acceptance test will be timed to see how long it takes them to perform a basic registration. If this is completed in less than approximately 60 seconds, this indicated success.
• Requirement: The system will allow authenticated users to edit their profile information.
  • The users who perform the acceptance test will be asked to enter a similar set of profile data. If this is completed successfully, the test is a success.

###Unit Test Scenarios###

• Model
  • The database will be tested on its ability to constrain data to intended types, even though prepared statements will be used in the controller.
  • The database will also be tested on its ability to send errors related to create/read/update/delete back to the controller, to be handled by the view/shown to the user.
• Controller
  • The controller will be tested in four main areas:
    • Pulling data from the model
    • Sending data to the view
    • Pulling data from the view
    • Creating, updating, or deleting data in the model
• View
  • The view will likely be tested one feature at a time, as the HTML and CSS is developed. Some key features include:
    • Login form
      • Can the controller get data from the view?
      • Can the page be redirected successfully when a result is reached?
    • Connection feed
      • Can the controller get data asynchronously from the model as required?
    • People You May Know block
      • Can the controller get data asynchronously from the model as required?
    • Search results populate (while scrolling down)
      • Can the controller get data from the model in real time as the user scrolls down the page?
      • Can this be done without creating too heavy of a load on a user’s browser?

###Regression Testing###

• Not applicable to Sprint 1.
• In further Sprints, regression testing will likely be targeted towards our controller and model, so they can remain compatible with the methods our view uses to display data and send data back to the controller for processing.

###Integration Testing###

• The controller needs to be tightly integrated with the model by the end of the second Sprint This is the highest priority because data must be first pulled from the model before anything can be shown to the user.
• The view needs to have proper methods to interface with the controller, and iteratively show all the data returned to it, as well as send form field data when necessary.

###Validation###

• User Acceptance testing is used for validation of requirements.

###Verification###

• All other listed tests are for verification.