HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2016T2 Remix final wiki"

From IS480
Jump to navigation Jump to search
Line 118: Line 118:
 
===Project Deliverables:===
 
===Project Deliverables:===
  
 +
{| class="wikitable"
 +
! style="font-weight: bold;background: #16a085;color:#ecf0f1; width:80px" | Stage
 +
! style="font-weight: bold;background: #16a085;color:#ecf0f1; width:80px" | Specification
 +
! style="font-weight: bold;background: #16a085;color:#ecf0f1; width:100px" | Modules
 +
|-
  
{| border="1"
 
|- style="background:blue; color:white"
 
|align="center"| Stage
 
|align="center"| Specification
 
|align="center"| Modules
 
|-
 
  
 
|rowspan="2"| Project Management
 
|rowspan="2"| Project Management
Line 131: Line 130:
 
|-
 
|-
  
|| Metrics (Bug metrics)
+
|| Metrics
 
|| [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_Remix_Metrics#Bug_Metric Bug metrics]
 
|| [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_Remix_Metrics#Bug_Metric Bug metrics]
 
|-
 
|-
  
|rowspan="4"| Analysis
+
|rowspan="2"| Analysis
 
|| Use case
 
|| Use case
|| [http://en.wikipedia.org/wiki/Use_case_diagram overall]
+
|| [https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_Remix_Documentation Use Cases]
 
|-
 
|-
  
|| System Sequence Diagram
 
|| [http://en.wikipedia.org/wiki/System_Sequence_Diagram client], [http://en.wikipedia.org/wiki/System_Sequence_Diagram server]
 
|-
 
  
|| [http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation Business Process Diagram]
+
|| Business Process Diagram
||
+
|| [https://www.dropbox.com/s/tvb0smf37s2lg85/BusinessProcess.png?dl=0 Here]
 
|-
 
|-
  
|| Screen Shots
+
|rowspan="2"| Design
|| CRUD Customer, Trend Analysis
+
|| ER Diagram
 +
|| [https://www.dropbox.com/s/aqhc0rwf64z6v76/ER%20Diagram.pdf?dl=0 Here]
 
|-
 
|-
  
|rowspan="2"| Design
+
|| Class Diagram
|| [http://en.wikipedia.org/wiki/Entity-relationship_model ER Diagram]
+
|| [https://www.dropbox.com/s/gs8s40abgwrsgy8/ClassDiagram.pdf?dl=0 Here]
|| 1, 2, 3
 
 
|-
 
|-
  
|| [http://en.wikipedia.org/wiki/Class_diagram Class Diagram]
 
|| [http://en.wikipedia.org/wiki/Class_diagram 1], [http://en.wikipedia.org/wiki/Class_diagram 2], [http://en.wikipedia.org/wiki/Class_diagram 3]
 
|-
 
  
  
|| Testing
+
|rowspan="3"| Testing
|| Test plan
+
|| Testing plan
|| [[IS480_Midterm_Wiki#Testing: | instructions]]
+
|| [https://www.dropbox.com/s/r5b8mj9gip96ub2/Remix_Test_Plan.docx?dl=0 Here]
 
|-
 
|-
 
+
|| User testing
|rowspan="3"| Handover
+
|| [https://www.dropbox.com/s/qeo7hfdzkf5vxmg/User%20Test%201.docx?dl=0 UT1]
|| Manuals
+
[https://www.dropbox.com/s/5ooxpxhp2ii0upx/User%20Test%202.docx?dl=0 UT2]
|| User tutorial, Developer manual, Setup manual
+
[https://www.dropbox.com/s/94h1nk4zja4zx2w/User%20Test%203.docx?dl=0 UT3]
 
|-
 
|-
 
+
|| UAT
|| Code
+
|| [https://www.dropbox.com/s/6om02akvtdzux9p/UAT.docx?dl=0 Here]
|| client server
 
 
|-
 
|-
 
|| [http://en.wikipedia.org/wiki/Deployment_diagram Deployment Diagram]
 
|| [[IS480_Midterm_Wiki#Deployment: | instructions]]
 
 
|}
 
|}
 
Not all parts of the deliverables are necessary but the evidence should be convincing of the scope.
 
  
 
===Deployment:===
 
===Deployment:===

Revision as of 23:18, 10 April 2016

Remix png .png

Home

About Us

Project Overview

Project Management

Documentation

Home Midterm Final

Project Progress Summary

Final Product:

Project Highlight:

What unexpected events occurred?

  • We did not consider the client's impact (delay, new change request etc.) on the project process. Overload alert function was delayed.
  • Extremely high bug metrics happened in Iteration 4 <before midterm>
  • List of requirement changes - As shown above in "Process based on Functions --> Change in Scope" <before midterm>

Project Challenges:

  • Integration with Bitbucket API:
    • Speed limitation on issue retrieving
    • Unexpected changes happened in API provider: delete function was removed in Feburary
  • Learning curve in React Js
  • Lack of understanding of business process and basic analytical knowledge

Project Achievements:

  • Successfully integrated with Bitbucket, a third party issue tracking tool
  • Beta version released in January. Used data collected to improve the urgency calculation formula.
  • Successfully built real time chat function using React js, together with user search and offline email alert functions.
  • Successfully designed and implemented several analytical functions that helps our sponsor improve the efficiency

Project Management

Project Schedule (Plan Vs Actual):

Plan.png

Following is the planned VS actual hour per iteration.

Total hours per iteration.png

Project Metrics:

  • Schedule Metrics: Not applicable since we are using time boxing.
  • Bug Metrics:

Remix Bug metrics.png

Technical Complexity:

Message notification and updates

To handle complicated components that are:

  • Ajax enabled
  • have multiple states
  • have multiple data sources
  • responsible for computing data and rendering its own UI independently
  • responsible for distributing data to other components that require it

Hhahha.png
The nodes on the graph above represent components from our messaging services. There is a total of 10 different data flows. Additionally, depending on the data received or computed, nodes can have multiple states. (e.g. File upload component with file attached or no files attached)

This was a big problem as it caused our UI to be unresponsibe and our code to be unmaintainable.

Bitbucket Oauth 2.0 authentication

We integrated Bitbucket into application. For this, we have to help developers and project managers log in to Bitbucket from our application.

This is difficult as we not only have to manage an extra level of authentication but also also synchronize both sessions (TSPMS and Bitbucket). Synchronization of the sessions was crucial for the user interface to be rendered correctly.

We felt that an additional complexity of managing and storing the API keys was that the keys have short lifespans; they expire after 30 minutes to an hour.

Scheduled events

We collect data from multiple sources for our custom Remix Analytics module. This process is tedious as we need to be precise for the calculation of accurate metrics. Additionally, the process is computationally intensive as well.

RemixTech3.png

Quality of product

Project Deliverables:

Stage Specification Modules
Project Management Minutes 19Internal Meeting; 13Sponsor Meeting; 14Supervisor Meeting
Metrics Bug metrics
Analysis Use case Use Cases
Business Process Diagram Here
Design ER Diagram Here
Class Diagram Here
Testing Testing plan Here
User testing UT1

UT2 UT3

UAT Here

Deployment:

In an iterative approach, ready to use system should be available (deployed) for client and instructions to access the system described here (user name). If necessary, provide a deployment diagram link.

Testing:

Describe the testing done on your system. For example, the number of user testing, tester profile, test cases, survey results, issue tracker, bug reports, etc.

Reflection

Compile common lessons and reflection for the team and for each team member. Be brief.

Team Reflection:

Key lessons learned – indicating where the team improved, or would do things differently next time. You may refer to the learning outcome summary in your proposal. A very short checklist style will suffice. It would be very convincing if the knowledge is share at the wiki knowledge base and linked here.

Individual Reflection:

Describe in a paragraph, the key areas of learning or improvement. These should be personal areas of growth or learning. Each individual should list his/her effort, responsibility, actual contributions and personal reflection. Do not repeat team project contributions or member roles. Link if necessary.

Sometimes, the client writes a report to feedback on the system; this sponsor report can be included or linked from here.