Meetings - CMPUT301F12T01/classproject GitHub Wiki

Next Meeting (Number 6) is tentatively scheduled before November 16, 2012 (Probably in CSC 3-23 (Arduino Project Room)).

Latest meeting listed first.

Meeting 06

November 16, 2012

Roles

Vanguard: Bronte

Scribe: Bronte

Itinerary

  1. Server choices. See email.

  2. New user stories and select which ones to document and which ones to implement. Release planning for the next (non-existant) part.

  3. Refactoring and the JDeodorant tool. Documentation.

  4. What needs to be done, in general.

  5. What needs to be done by next WEDNESDAY (Nov 21, 2012).

  • New Use Cases and select the ones we want to implement
  • Viewing reports (text based at least?)

Summary

Immediate to dos:

  • Finish GUI
  • Finish local storage

Overall to dos:

  • Photos
  • Server
  • Audio

User Stories we want to document:

  • As a user I want to ensure that others cannot modify my tasks. Only I should be able to modify them (security/authentication). [L]
  • As a user I want to get my task responses on my phone but not in my email. (One could use the webservice, or a seperate response webservice). [L]
  • As a user I want to specify tasks that include audio or video components. [M]
  • As a user I want to see random tasks. [S]
  • As a user I want to publish the results of a task somehow. [L]

Bolded items are the ones we plan to implement by December 3, 2012. (Added to the Release Plan)

Immediate Tasks:

  • GUI: Bronte and Eddie
  • Server/Model: Neil and Mitchell
  • Photos: Aaron

Meeting 05 - TA Meeting/Demo

November 7, 2012

Roles

Scribe: Bronte

Summary

New User Stories have been added and we need to pick 2-3 of them depending on their work weight. Luckily we had already prepared for adding two of the User Stories:

  • (19.) As a user I want to specify tasks that include audio or video components. [Medium Amount of Work]
  • (22.) As a user I want to publish the results of a task somehow. [Large Amount of Work]

Publish implies having everyone see the results of a global task. If we are going to publish the results, our TA said we would NOT have to worry about emailing the user that created the task back.

Our TA mentor recommended that we should add the ability to edit or delete a task. This would fall under:

  • (16.) As a user I want to ensure that others cannot modify my tasks. Only I should be able to modify them (security/authentication). [Large Amount of Work]

Thoughts

So even though we did not get everything we planned to have done for the demo, we have the basis for three pretty heavy components already. Though I believe we will implement or aim to implement the above three, we should have a quick meeting about the priority of these new User Stories and what difficulties could we have implementing them. And division of work.

Meeting 04

Friday, October 26

Roles

Vanguard: Neil and Bronte

Scribe: Bronte and Eddie

Itinerary

  1. Go over the requirements for the next Project checkpoint (Nov 5, 2012). This includes the page on eClass and the marking rubric.

  2. Figure out everyone's assignment/exam schedule.

  3. Assign roles and assign mini 'deadlines'. (Need to integrate before Nov 5!)

  4. Program! We'll probably get more work done if we can program together since we can clarify anything we need to then.

Summary

For the immediate future, here is how we quickly divided up the tasks:

Aaron - 'Common': Data (Tasks, requests, etc)

Eddie - The 'icky' components: fragments, etc

Mitchell - Business layer

Neil - Local storage

Bronte - User Interface, wiki clean up (storyboards)

On Sunday we will have a general working session since Friday didn't really work out.

Meeting 03: Meeting with our TA Mentor

Wednesday, October 24

Roles

Vanguard: Eddie

Scribe: Bronte

For some reason our TA cannot see our Wiki changes in the Dashboard. Once we start pushing code, we should check to see that he can see our commits for the code.

We might want to combine Use Cases together, not just use the 'Include' field in the Use Cases. This can help clean up the 'requirements'. We may also want to group the Test Cases together with the proper Use Cases, or refer to it.

We need to upgrade our sketched diagrams to Android UI diagrams. Can use the Android emulator and take screenshots of them. This applies to the storyboard as well. Also, we were under the wrong impression for the storyboard; it needs to cover as many Use Cases as possible, not just a non-trivial scenario. Therefore, we need more for our storyboard. (For example, show defining a task, fulfilling a local task, fulfilling a global task and then receiving a report about another user fulfilling one of your tasks.)

The UML diagrams were fine. Good relationships. It was suggested that we should add notes explaining the relationships in addition to the composition/aggregation diamonds, for clarification purposes.

The Glossary was fine. We may want to add a Sources section even though we have not required any sources yet, other than eClass.

Meeting 02

Saturday, October 20

Roles

Vanguard: Neil and Bronte

Scribe: Bronte (first half of the meeting)

NOTES: Bronte was only present for the first half of the meeting.

Itinerary

  1. Release Plan - we need to decide which half of the requirements we want to implement by the end of Part 3

  2. Review the Use Case stories - the important 50% that needs to be done for Part 3.

  3. UML - revise it and start adding MVC stuff.

  4. Storyboard

  5. Other: Issue Tracker?

Summary

  • OOA revising. There are certain responsibilities that need to be handled; separations of concerns.

DIAGRAM (1) ON THE BOARD

Talking to the Centre Server <-> Business logic <-> Persistant Local Storage

Talking to Centre Server (Java)

  • Uses: Http library, GSON

Business Layer - "Pure" Java

  • The Model

Persistant Local Storage

  • Uses Android Classes
  • May have a Uniform Interface with the Business Layer

Another relation to the Business layer. (The Business Logic also communicates with the GUI, but we're putting that on the side for now.)

Business Logic <-> GUI stuff

GUI stuff

  • Uses Android classes

Also, currently not connected to anything:

Ubiquitous Objects

  • Task
  • Request
  • Report
  • Response: Media Type

After sketching these out, we moved to diagramming the Business Logic: the model. We made the UML diagram for it.

The Use Cases we decided on being the most important were the following:

1, 3, 4, 7, 8, 10, 15

We decided to focus on creating tasks that would be local to the device. We should be able to define our own task and be able to fulfill them. Though we can define tasks that require photos, we decided not to worry about fulfilling the tasks that require photos, but we can fulfill text based tasks. We will also deal with storage on the local device. Basically, we decided not to focus on the server or dealing with the camera on the device.

We then went through these ones and revised them. The Use Cases page have been updated.

We decided that the creating a task would be appropriate to storyboard and decided on what the storyboard would look like.

Meeting 01

Friday, October 12

Roles

Vanguard: Neil and Bronte

Scribe: Bronte (meeting summary) and Eddie (glossary and diagrams)

Itinerary

  1. Discuss the diagram that has been created

  2. Discuss availability of Individuals

  3. Briefly look at the current contents of the wiki and Identify issues

  4. If time permits, reconcile the issues with our concept of the project based on (1)

  5. Partition a subset of task among the group based on importance and availability

  6. Determine our next meeting time and send the minutes to our manager

Summary

  • Definition of 'User'. We had considered a log in system for tracking Tasks and Users for global tasks. We abolished the idea of logging in by saying that everytime the app is downloaded, a new anonymous user is created. There would be no way for the User to see how they are identified.

  • Reviewed and revised Neil's diagram of a mockup User Interface

  • Using photos to fulfill a task: That's when you can take the photo (like the Twitter App for the iPhone?) and then you can accept or retake your photo.

  • Setting local/global task will happen when the User creates the task. (Since there is no mention of editing a task.) When a task is set to global, a copy of the Task gets pushed to the Server and one is stored on your device. This is not specified, but we think that the User would want their own Tasks stored locally too.

  • Tasks that are stored locally that are not your own are stored with your tasks.

  • Glossary Update: Report, Response, Media type (audio, photo, text).

  • Started our Object Oriented Analysis and resulted in the diagram at the bottom of our Use Case UML Diagrams page.

Availability of Group Members from Monday, Oct 15 - Friday, Oct 19

  • Aaron: Two midterms

  • Eddie: Two midterms

  • Mitchell: Two Midterms

  • Bronte: Four Midterms

  • Neil: Four Midterms

We decided to have the people with the least amount of midterms work on writing up the Use Cases for the User Stories before we have out next meeting. Here's the division of User Stories, numbered in the order they appear on the Problem Description webpage:

  • Mitchell: 1, 2, 9, 13, 15

  • Aaron: 4, 5, 10, 11, 12

  • Eddie: 3, 6, 7, 8, 14

Next Meeting

We will have a lab on Wednesday, but reviewing of the Use Cases will probably happen on October 19 (Friday) or on the weekend.