HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2016T1 MonoChrome Finals"

From IS480
Jump to navigation Jump to search
 
(33 intermediate revisions by 2 users not shown)
Line 43: Line 43:
 
! style="font-weight: bold;background: #323232;color:#fff;" | Video Pitch
 
! style="font-weight: bold;background: #323232;color:#fff;" | Video Pitch
 
|-
 
|-
| [[Image:PptPic.png|110px|link=]]
+
| [[Image:PptPic.png|110px|link=https://wiki.smu.edu.sg/is480/img_auth.php/c/ca/MonochromeFinalSlides.pdf]]
 
| [[Image:MonoCDashboard.png|130px|link=http://monochrome-acceptance.herokuapp.com]]
 
| [[Image:MonoCDashboard.png|130px|link=http://monochrome-acceptance.herokuapp.com]]
 
| [[Image:MonoCVidPik.png|130px|link=https://youtu.be/Z6bQM_Uyors]]
 
| [[Image:MonoCVidPik.png|130px|link=https://youtu.be/Z6bQM_Uyors]]
Line 56: Line 56:
 
===Project Achievements:===
 
===Project Achievements:===
  
 +
*Achieve 2nd X-factor (Monitor 20-30 sensors across 2 building for at least 2 months)
 
*Successful implementation of Reverse SSH, stable and working. (Technology that is built in-house, as there are no commercially available API for this)  
 
*Successful implementation of Reverse SSH, stable and working. (Technology that is built in-house, as there are no commercially available API for this)  
 
*Successful implementation of SNMP, our web application is able to monitor WiFi router health status too
 
*Successful implementation of SNMP, our web application is able to monitor WiFi router health status too
Line 69: Line 70:
 
! style="color: #88C1F8; background-color:black;" | FEATURES
 
! style="color: #88C1F8; background-color:black;" | FEATURES
 
! style="color: #88C1F8; background-color:black;" | STATUS
 
! style="color: #88C1F8; background-color:black;" | STATUS
! style="color: #88C1F8; background-color:black;" | CONFIDENCE LEVEL(0 - 1.0)
 
 
! style="color: #88C1F8; background-color:black;" | COMMENT
 
! style="color: #88C1F8; background-color:black;" | COMMENT
 
|-
 
|-
Line 75: Line 75:
 
||Database Module
 
||Database Module
 
|| Fully deployed and tested 100%
 
|| Fully deployed and tested 100%
|| 1
+
||Completed
 +
|-
 +
 
 +
||2
 +
||Data Collection Module
 +
|| Fully deployed and tested 100%
 +
||Completed
 +
|-
 +
 
 +
||3
 +
||Analytics Module
 +
|| Fully deployed and tested 100%
 +
||Completed
 +
|-
 +
 
 +
||4
 +
||Dashboard Module I
 +
|| Fully deployed and tested 100%
 +
||Completed
 +
|-
 +
 
 +
||5
 +
||Sensor Module
 +
|| Fully deployed and tested 100%
 +
||Completed
 +
|-
 +
 
 +
||6
 +
||Notification Module
 +
|| Fully deployed and tested 100%
 +
||Completed
 +
|-
 +
 
 +
||7
 +
||Two-way Communication Module
 +
|| Fully deployed and tested 100%
 
||Completed
 
||Completed
 
|-
 
|-
Line 81: Line 116:
 
||8
 
||8
 
||Dashboard Module II
 
||Dashboard Module II
|| In progress
+
|| Fully deployed and tested 100%
|| 1
+
|| Completed
|| In progress
 
 
|-
 
|-
  
 
||9
 
||9
 
||Database Collection Module II
 
||Database Collection Module II
|| In progress
+
|| Fully deployed and tested 100%
|| 1
+
|| Completed
|| In progress
 
 
|-
 
|-
  
 
||10
 
||10
||Mobile Responsive Module
+
||Optimization Module
|| In progress
+
|| Fully deployed and tested 100%
|| 1
+
|| Completed
|| Will always revise the mobile responsiveness for every change in design
 
 
|-
 
|-
  
 
||11
 
||11
||Optimization Module
+
||Account Management Module
|| In progress
+
|| Fully deployed and tested 100%
|| 1
+
|| Completed
|| New scope proposed by Monochrome: Archiving;  Half of Security Module moved to this new module.
 
 
|-
 
|-
  
 
||12
 
||12
||Account Management Module
+
||Dashboard Module III
|| In progress
+
|| Fully deployed and tested 100%
|| 1
+
|| Completed
|| "Register new user account" to be completed in Iteration 11
 
 
|-
 
|-
  
 
||13
 
||13
||Dashboard Module III
+
||Notification II Module
|| Scheduled for Future Development
+
||Fully deployed and tested 100%
|| 1
+
||Completed
|| To Be Completed
 
 
|-
 
|-
  
 
||14
 
||14
||Downtime Scheduler Module
+
||Downtime Manager Module
||Scheduled for Future Development
+
|| Fully deployed and tested 100%
|| 1
+
|| Completed
||To Be Completed
 
 
|-
 
|-
  
 
||15
 
||15
||Security Module
+
||Mobile Responsive Module
|| Removed upon negtiation
+
|| Fully deployed and tested 100%
|| N.A
+
|| Completed
|| Removed upon negtiation
 
 
|-
 
|-
 +
 
|}
 
|}
 
</center>
 
</center>
  
 
===Project Schedule (Plan Vs Actual):===
 
===Project Schedule (Plan Vs Actual):===
 +
<center>
 
{|  class="wikitable"
 
{|  class="wikitable"
|- style="background:#1d4c5d; color:#88C1F8"  
+
|- style="background:#1d4c5d; color:#88C1F8; margin: 0px; width: 100%"  
 
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | PLANNED
 
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | PLANNED
 
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | ACTUAL
 
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | ACTUAL
Line 146: Line 175:
 
[[File:MonoCTimelinev6.png|500px]]
 
[[File:MonoCTimelinev6.png|500px]]
 
|}
 
|}
 
+
</center>
 
===Project Scope (Plan Vs Actual):===
 
===Project Scope (Plan Vs Actual):===
 
+
<center>
 
{|  class="wikitable"
 
{|  class="wikitable"
 
|- style="background:#1d4c5d; color:#88C1F8"  
 
|- style="background:#1d4c5d; color:#88C1F8"  
Line 157: Line 186:
 
[[File:MonoCFunctionalities v4.png|500px]]
 
[[File:MonoCFunctionalities v4.png|500px]]
 
|}
 
|}
 
+
</center>
 
<center>
 
<center>
 
{| class="wikitable" style="background-color:#FFFFFF; width:100%; text-align: center;"
 
{| class="wikitable" style="background-color:#FFFFFF; width:100%; text-align: center;"
Line 186: Line 215:
 
</center>
 
</center>
  
Compare the project plan during midterm with the actual work done at this point. Briefly describe a summary here. Everything went as plan, everything has changed and the team is working on a new project with new sponsors or the supervisor is missing. A good source for this section comes from the project weekly report.
+
===Project Metrics:===
 +
 
 +
*Task metric is used for determining whether we are still in healthy zone for completing the project.
 +
*Till date, most of Task Metrics falls within the green zone. Only Iteration 8 have exceeded green zone, mitigation action has been taken.
 +
*Most of the bugs have been fixed in allocated days for debugging.
 +
*Metrics page: [[IS480 Team wiki: 2016T1 MonoChrome Metrics|Click here to visit metrics page]]
 +
 
 +
<center>
 +
{|  class="wikitable"
 +
|- style="background:#1d4c5d; color:#88C1F8"
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | TASK METRICS
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | BUG METRICS
 +
|-
 +
|[[File:MonoChromeTM1.png|500px]]
 +
|[[File:MonoCBug.jpg|500px]]
 +
|}
 +
</center>
 +
 
 +
===Project Risks:===
 +
Link to view full list of project risks: [[IS480 Team wiki: 2016T1 MonoChrome Risk Assessment|Monochrome Risk Assessment]]
 +
<br>
 +
<center><h3>Below are the top 2 risks from Midterms to Final Risk Management</h3></center><br>
 +
[[Image:MonoCFinalRisk.png|center|900px]]
 +
<center>
 +
 
 +
</center>
  
===Project Metrics:===
 
  
Summary of analysis for the metrics collected. You may refer to another page for the details about the metrics and how it is collected.
 
  
 
===Technical Complexity:===
 
===Technical Complexity:===
 +
{|  class="wikitable"
 +
|- style="background:#1d4c5d; color:#88C1F8; text-align: center"
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | TECHNICAL COMPLEXITY
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | IMAGE
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | DESCRIPTION
 +
|-
 +
 +
|| Front End: Maintaining React state
 +
|| 
 +
 +
<b>Before: </b>
 +
<font face="Consolas">
  
{| class="wikitable"
+
    <b>From vertical menu: </b>
 +
    $(‘#deleteSensorMac’).val(macAddress);
 +
   
 +
    <b>In DeleteSensor.jsx: </b>
 +
    var macAdd = $(‘#deleteSensormac’).val();
 +
</font>
 +
 
 +
<p><b>Problem:
 +
Erratic / unreliable</b></p>
 +
 
 +
[[Image:Redux.png|center|340px]]
 +
 
 +
||
 +
<p>In traditional <b>React</b> applications, props can only be transferred from a parent to child component. this, however, can be inconvenient as certain components in <i>complex web applications</i> may need to receive props that <b>cannot be passed on from its parent</b>. </p>
 +
 
 +
 
 +
*Our modals, for example, require information such as the mac address of a sensor. the DeleteSensorModal component, for instance, is a child of the Dashboard component.
 +
 
 +
*There are two issues here:
 +
**Firstly, the component that triggers the DeleteSensorModal component to appear is not its parent. As such, it is unable to directly pass the mac address prop to the DeleteSensorModal component.
 +
 
 +
**Secondly, the <b>Dashboard component does not know which mac address</b> is required as does not interact with the DeleteSensorModal component.
 +
 
 +
*As such, we used <b>Redux -- a React framework</b> that is used to help to maintain state.
 +
 
 +
*Actions are triggered from a component on user interaction. These actions store the mac address (or any other useful pieces of information) in a global state store. The component that requires the information retrieves it after.
 
|-
 
|-
! Area of Complexity !! Description
 
|-
 
| Pinging Servers || One of the issues that surfaced while we were testing for fault tolerance came about due to the way fault tolerance was implemented.
 
  
Data from Raspberry Pis is sent through FluentD, a unified logging layer, which buffers and stores it locally in case of connectivity issues. This ensures that data is not lost even if a Raspberry Pi is disconnected from the internet.  
+
||Pinging Servers
 +
||  [[Image:Screen Shot 2016-11-14 at 2.41.14 AM.png|center|350px]]
 +
||<p>One of the issues that surfaced while we were testing for fault tolerance came about due to the way fault tolerance was implemented. </p>
 +
 
 +
*Data from Raspberry Pis is sent through <b>FluentD</b>, a unified logging layer, which buffers and stores it locally in case of connectivity issues. This ensures that data is not lost even if a Raspberry Pi is disconnected from the internet.
 +
 
 +
 
 +
*However, an unexpected limitation came when a sensor was disconnected for an extended period of time. The buffer was full when the internet connection came back, and the sensor began sending it's stored records. The records were sent in chronological order, which meant that the data being inserted to the database initially was out of date. <b>It took nearly a half hour</b> for the buffer to completely sent.
 +
 
 +
 
 +
*The fact that the records were older meant that the sensor was labelled as "down" on the dashboard, it was technically alive and sending data.
 +
 
 +
 
 +
*To circumvent this issue, we developed a <b>secondary architecture for data logging</b>, which involved sending small packets of data to indicate that a sensor was "alive". These logs are not sent through Fluentd, thus eliminating the buffering issue. The data in these logs is limited to a sensor's mac address and a timestamp, periodically inserted into the server's database.  
  
However, an unexpected limitation came when a sensor was disconnected for an extended period of time. The buffer was full when the internet connection came back, and the sensor began sending it's stored records. The records were sent in chronological order, which meant that the data being inserted to the database initially was out of date. It took nearly a half hour for the buffer to completely sent.
 
  
The fact that the records were older meant that the sensor was labelled as "down" on the dashboard, it was technically alive and sending data.
+
*Their sole function is to indicate whether a Raspberry Pi is "alive" or "down". This information is displayed in conjunction with the Raspberry Pi's status.
  
To circumvent this issue, we developed a secondary architecture for data logging, which involved sending small packets of data to indicate that a sensor was "alive". These logs are not sent through Fluentd, thus elminating the buffering issue. The data in these logs is limited to a sensor's mac address and a timestamp, periodically inserted into the server's database. Their sole function is to indicate whether a Raspberry Pi is "alive" or "down". This information is displayed in conjunction with the Raspberry Pi's status.
 
  
With this new system, a scenario where a Raspberry Pi is sending its buffer would have a ping result indicating that the Raspberry Pi is still alive, despite its being labelled as "down".  
+
*With this new system, a scenario where a Raspberry Pi is sending its buffer would have a ping result indicating that the Raspberry Pi is still alive, despite its being labelled as "down".  
 
|-
 
|-
| SNMP || Reasons why a Raspberry Pi might go "down" can be generalized into 3 categories: issues with the Raspberry Pi, issues with its router, or connectivity issues. The first can be easily discerned by the Raspberry Pi's status, but the latter two are more tricky. Routers often do not run the same operating systems as Raspberry Pis, making it harder to place custom scripts on them to allow collection of data.
 
  
The use of Simple Network Management Protocol (SNMP) allowed us to solve this issue. Assigning one of the Raspberry Pis to run the snmpwalk program provided access to information about the router, including CPU usage, temperature, RAM, etc. Users can then use this information to evaluate the status of the router, to determine if any issues with Raspberry Pis are due to the router as opposed to the rPi itself.
+
|| SNMP (Simple Network Management Protocol)
 +
||  [[Image:Screen Shot 2016-11-14 at 2.44.38 AM.png|center|340px]]
 +
||Reasons why a Raspberry Pi might go "down" can be generalized into 3 categories: Issues with the <b>Raspberry Pi</b>, issues with its <b>router</b>, or <b>connectivity issues</b>. <br><br>
 +
*The first can be easily discerned by the Raspberry Pi's status, but the latter two are more tricky. Routers often do not run the same operating systems as Raspberry Pis, making it harder to place custom scripts on them to allow collection of data
 +
 
 +
*The use of <b>Simple Network Management Protocol (SNMP)</b> allowed us to solve this issue. Assigning one of the Raspberry Pis to run the snmpwalk program provided access to information about the router, including CPU usage, temperature, RAM, etc.  
 +
**Users can then use this information to evaluate the status of the router, to determine if any issues with Raspberry Pis are due to the router as opposed to the Raspberry Pi itself.
  
This is used in conjunction with a internet speed test. Similar to the abovementioned snmpwalk, a Raspberry Pi is assigned to periodically run the speed test, and the results are displayed on the dashboard. Poor speed test results could indicate that high downtime is due to poor internet connectivity, as opposed to issues with the Raspberry Pis or the router.
+
*This is used in conjunction with an internet speed test. Similar to the abovementioned snmpwalk, a Raspberry Pi is assigned to periodically run the speed test, and the results are displayed on the dashboard. <br>
  
 +
*Poor speed test results could indicate that high downtime is due to poor internet connectivity, as opposed to issues with the Raspberry Pis or the router.
 
|}
 
|}
  
 
==Quality of product==
 
==Quality of product==
 
Provide more details about the quality of your work. For example, you designed a flexible configurable system using XML.config files, uses Strategy Design Pattern to allow plugging in different strategy, implement a regular expression parser to map a flexible formula editor, etc.
 
 
 
===Project Deliverables:===
 
===Project Deliverables:===
  
List the artifacts produced for this project. The entire deliverable can be submitted in a separate thumb drive, web repository or place in the IS480 team wiki.
+
{| class="wikitable" style="background-color:#FFFFFF;"
 +
|-
 +
! style="font-weight: bold;background: #323232;color:#88C1F8;" | STAGE
 +
! style="font-weight: bold;background: #323232;color:#88C1F8" | SPECIFICATION
 +
! style="font-weight: bold;background: #323232;color:#88C1F8" | MODULES
 +
|-
  
 +
|rowspan="2"| Project Requirements
 +
|| Market Analysis
 +
|| [[IS480 Team wiki: 2016T1 MonoChrome Market Analysis|Summary Market Analysis]], [https://wiki.smu.edu.sg/is480/img_auth.php/0/06/IS480_Market_Report.pdf Detailed Market Analysis Report]
 +
|-
  
 +
|| Story board
 +
|| [[IS480 Team wiki: 2016T1 MonoChrome Story Board|MonoChrome Story Board]]
 +
|-
  
{| border="1"
 
|- style="background:blue; color:white"
 
|align="center"| Stage
 
|align="center"| Specification
 
|align="center"| Modules
 
|-
 
  
|rowspan="2"| Project Management
+
|rowspan="4"| Project Management
 
|| Meeting Minutes  
 
|| Meeting Minutes  
 
||  [[IS480 Team wiki: 2016T1 MonoChrome Meeting Minutes|MonoChrome Meeting Minutes Page]]
 
||  [[IS480 Team wiki: 2016T1 MonoChrome Meeting Minutes|MonoChrome Meeting Minutes Page]]
Line 244: Line 350:
 
|-
 
|-
  
|| Requirements
+
|| Risk Management
|| Story cards
+
|| [[IS480 Team wiki: 2016T1 MonoChrome Risk Assessment|MonoChrome Risk Assessment]]
|| [http://www.agilemodeling.com/artifacts/userStory.htm CRUD Customer], [http://www.agilemodeling.com/artifacts/userStory.htm Trend Analytic]
 
 
|-
 
|-
  
|rowspan="4"| Analysis
+
|| Change Management
|| Use case
+
|| [[IS480 Team wiki: 2016T1 MonoChrome Change Request|MonoChrome Change Request]]
|| [http://en.wikipedia.org/wiki/Use_case_diagram overall]
 
 
|-
 
|-
  
|| 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]
 
||
 
|-
 
 
|| Screen Shots
 
|| CRUD Customer, Trend Analysis
 
|-
 
  
 
|rowspan="2"| Design
 
|rowspan="2"| Design
|| [http://en.wikipedia.org/wiki/Entity-relationship_model ER Diagram]
+
|| Use Case Diagram & Use case scenario
|| 1, 2, 3
+
|| [[IS480 Team wiki: 2016T1 MonoChrome Documentation|MonoChrome Diagrams]]
 
|-
 
|-
  
|| [http://en.wikipedia.org/wiki/Class_diagram Class Diagram]
+
|| UI Prototype
|| [http://en.wikipedia.org/wiki/Class_diagram 1], [http://en.wikipedia.org/wiki/Class_diagram 2], [http://en.wikipedia.org/wiki/Class_diagram 3]
+
|| [[IS480 Team wiki: 2016T1 MonoChrome Wire Framing|MonoChrome Wire Framing]]
 
|-
 
|-
 
  
 
|| Testing
 
|| Testing
 
|| Test plan
 
|| Test plan
|| [[IS480_Midterm_Wiki#Testing: | instructions]]
+
|| [[IS480 Team wiki: 2016T1 MonoChrome Functionality & Regression Testing|MonoChrome Test cases]]
 
|-
 
|-
  
 
|rowspan="3"| Handover
 
|rowspan="3"| Handover
 
|| Manuals
 
|| Manuals
|| User tutorial, Developer manual, Setup manual
+
|| [https://wiki.smu.edu.sg/is480/img_auth.php/c/ca/MITOS_Manual.pptx User Tutorial]
 
|-
 
|-
  
 
|| Code
 
|| Code
|| client server
+
|| 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.
+
=== Quality:===
 +
 
 +
[[Image:MonoCArchitectureV3.png|center|800px]]
 +
 
 +
<p><b>Scalability/Performance</b>
 +
*One of the requirements regarding this project from the client organization is the storage and retaining of all the collected data. Data collected are required to kept as long the client desires, this continuous scaling of data will eventually slow down the performance of the application and surface scalability issues.
 +
*As such, the application has been programmed with basic data indexing and data archiving capabilities to filter and store also data which are rarely in use by the application into a separate collection, to prevent data retrieval slowdown.
 +
*On top of data indexing and archiving, data will have to be converted into a more performance efficient format and stored in the database. This is where we implemented a NoSQL database, MongoDB, due to its flexibility in data storage and its ease of use.
 +
*We implemented "publish-subscribe" for our front-end information because the system only need to generate 1 set of data instead of having multiple user interface calling alot of APIs which will increase the laod of the server and resulting in slowing down the performance.
 +
*All the above mentioned will ensure our application always stays in top performance and less prone to slowdown from an ever expanding database.</p>
  
=== Quality:===
+
<p><br><b>Maintainability</b>
 +
*The application is based on the Linux platform, where everyone in our client organization is extremely familiar with it. Data related functions such as CRUD (Create, Read, Update, Delete) in MongoDB, which our application uses for data storage, is all done in an Objected-Oriented manner.
 +
*This means future code maintenance relating to data retrieval can be easily performed by calling methods from the existing MongoDB Library rather than writing SQL queries which could cost more to maintain.
 +
*These reasons allow easier maintenance of the application for our client organization, as employees with basic programming knowledge without having to extensively train in multiple skills in order to perform basic maintenance.
 +
</p>
 +
 
 +
<p><br><b>Fault Management </b>
 +
*The web application itself has no fault tolerance capabilities but it can be easily deployed into a cloud server that offers such capabilities such as AWS.
 +
*However, a collection of data is built with fault tolerance technologies to prevent any data loss during data transfer from each individual sensors deployed on the ground and the main server that hosts the database.
 +
*This is mainly done through Fluentd which buffers data locally in its hosted machine if a connection to the server is not found, where Fluentd will constantly check for the connection status with the database and flushes the buffered data to the database upon having the connection reestablished.
 +
*Furthermore, the database is frequently exported by the application in case of any unforeseen issues that could wipe out the database. The exported data can be easily inserted into the new database within a short amount of time to ensure the application will always be constantly up.</p>
 +
 
 +
<p><br><b>Configurability</b>
 +
*The system offers configurable settings for user customization. This can be done through change the settings on the dashboard and the changes will be reflected into all the system calculation and analysis to reflect the changes made.</p>
 +
 
 +
<p><br><b>Security</b>
 +
*The application will be part of the client organization and part of our role is to ensure the application and its data stays secure in the hands of our client organization.
 +
*In this regard, the application will be performed under OWASP test which include test like penetration test in order to find any security loop holes within the application which could potentially breach our client’s data confidentiality.
 +
*These loop holes, if found, will be swiftly patched up by our team.
 +
*On top of it, an IP lock will be implemented to enforce the security of the application in terms of access control. This will ensure access to the application are only open to only approved personnel determined by the client organization.
 +
*Below is the before and after report result:
 +
<b>Before fix report</b>
 +
[[Image:OwaspReportBefore.png|center|600px]]<br>
 +
<b>After fix report</b>
 +
[[Image:OwaspReportAfter.png|center|600px]]<br>
  
Explain the quality attributes (non functional) of your project deliverables. Have you designed the architecture, use a design pattern, etc? Does your architecture address scalability, performance, reliability, availability, fault tolerance, usability, etc. Does your design address maintainability, flexibility, configurability, etc. Be brief here but you can link to diagrams or code detail pages. Do not repeat the technical complexity part, link to it if necessary.
+
</p>
  
 
===Deployment:===
 
===Deployment:===
 +
*We deployed the site in an interative approach, every 2 weeks we will redeploy again with new functionalities.
 +
*The username and password have been given to client to login and use the dashboard.
 +
*The deployed site is live with company confidential data, so we are unable to let users to login and see. However, we provide a navigation diagram below.
 +
*Link to use case diagram: [[IS480 Team wiki: 2016T1 MonoChrome Documentation|Use Case Diagram]]
 +
{|  class="wikitable"
 +
|- style="background:#1d4c5d; color:#88C1F8"
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | SITEMAP
 +
|-
 +
|[[File:Screen Shot 2016-11-14 at 10.15.34 AM.png|700px]]
 +
|}
 +
 +
===Testing:===
  
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 [[IS480_Final_Wiki#Project_Deliverables: | deployment diagram link]].
+
===Functionality & Regression Testing===
  
===Testing:===
+
*Monochrome Functionality & Regression Testing page: [[IS480 Team wiki: 2016T1 MonoChrome Functionality & Regression Testing]]
 +
 
 +
{| class="wikitable" style="background-color:#FFFFFF;"
 +
|-
 +
! style="font-weight: bold;background: #323232;color:#88C1F8;" | Testing
 +
! style="font-weight: bold;background: #323232;color:#88C1F8" | Remarks
 +
! style="font-weight: bold;background: #323232;color:#88C1F8" | Total
 +
|-
 +
|rowspan="1"| Functionality Testing
 +
|| Every module test
 +
|| 8
 +
|-
 +
|rowspan="1"| Regression Testing
 +
|| Every iteration test
 +
|| 9
 +
|}
  
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.
+
===UAT:===
 +
*We have successfully completed all of our 4 UAT.  
 +
*The objective, test cases and results can be view on the UAT page.  
  
==Reflection==
+
{|  class="wikitable"
 +
|- style="background:white; color:white;text-align: center;"
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | USER TESTING
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | DATE
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | USER PROFILE
 +
! style="text-align: center; bold;background: #323232;color:#88C1F8; width:17px; border:1px solid #999" | LINK
 +
|-
 +
|| UAT 1
 +
|| 3 August 2016
 +
|| Thomas Wong (Sponsor) + 5 random users
 +
|[https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T1_MonoChrome_UserTesting_1 User Acceptance Test 1 Link]
 +
|-
 +
 
 +
|-
 +
|| UAT 2
 +
|| 22 August 2016
 +
|| Thomas Wong (Sponsor) + Cecilia Sim (Sponsor) + Hazmei Bin Abdul Rahman (ORT Intern)
 +
||[https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T1_MonoChrome_UserTesting_2 User Acceptance Test 2 Link]
 +
|-
  
Compile common lessons and reflection for the team and for each team member. Be brief.
+
|-
 +
|| UAT 3
 +
|| 13 September 2016
 +
|| Thomas Wong (Sponsor) + Sean Ang (Full time staff) + Lim Shuen (Intern)
 +
||[https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T1_MonoChrome_UserTesting_3 User Acceptance Test 3 Link]
 +
|-
 +
|-
 +
|| UAT 4
 +
|| 14 November 2016
 +
|| Thomas Wong (Sponsor) + Cecilia Sim (Sponsor) + Sean Ang (Full time staff)
 +
||[https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T1_MonoChrome_UserTesting_4 User Acceptance Test 4 Link]
 +
|-
 +
|}
  
 +
==Reflection==
 
===Team Reflection:===
 
===Team Reflection:===
 +
We learnt that it is important to keep an open-mind when developing an application for a client because along the way there will be unforeseen circumstances, many unknown unknown that we need to solve as well as take in feedbacks from the various stakeholder. IS480 have given us an opportunity to learn real life skill sets and to stretch us beyond our limits.
  
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 | knowledge base]] and linked here.
+
*Roles & Responsibilities link: [[IS480 Team wiki: 2016T1 MonoChrome Our Team]]
 +
*Team Photo Gallery link: [[IS480 Team wiki: 2016T1 MonoChrome Gallery]]
  
===Individual Reflection:===
 
 
===Ian's Reflection:===
 
===Ian's Reflection:===
===Yong Jin's Reflection:===
+
This project has been quite a journey. Before we started, my knowledge was limited to what was taught in the classroom. Six months later, this project has, in a sense, forced my teammates and I to learn, explore, and experience unfamiliar technologies and techniques. For instance, reverse ssh is one of the techniques I picked up during this project, and making it persistent and stable became an experiment in and of itself.
===Sponsor Comment:===
+
 
Sometimes, the client writes a report to feedback on the system; this sponsor report can be included or linked from here.
+
===Marcus's Reflection===
 +
I've made the adage "good artists copy, great artists steal" my motto throughout the course of the project. Rather than trying to reinvent the wheel, I scoured the internet for ideas on dashboard design elements and pieced a couple of good ones together as a deliverable. I've learned to be more acceptive of criticism and ideas that oppose mine. This, in turn, helped to spark fresh ideas that had far more depth. As a team, I'm proud to say that we've accomplished what we labeled as "impossible" at the start of the project.
 +
===Yong Jin's Reflection===
 +
On top of the knowledge and skills, in cutting edge skill areas such as IoT and NoSQL, that I have took away from this project. I have also learnt to work better in a VUCA (Volatility, Uncertainty, Complexity, Ambiguity) environment better.
 +
Before embarking on this project, I have been working in classroom projects with a feeling of certainty. In those classroom projects, I am first taught the necessary knowledge, then applying them on an well-thought out problem. It has been a planned out route, the assigned task (project) can be accomplished as long guides and instructions from the assigned instructors are followed.
 +
This project has been a total brand new experience for me, knowledge has to be self acquired with the application on a ever changing existing problem. Trying my hands on unexplored technology will definitely lead to unexpected results, such as unexpected break downs and errors. Thus, the past me who relied on certainty ceased to exist. Having to face conditions of uncertainty and volatility, I have learnt to map out for possible outcomes and make better adjustments for such scenarios.
 +
 
 +
===Sarah's Reflection===
 +
During the course of this project, I have learned the importance of quality assurance. Learning to make changes based on user testing results has allowed the team to constantly improve on the dashboard, ensuring the client's satisfaction. This project has been a new experience for me as I often worked alone in the past. Working with my teammates on this project has shown me how to work efficiently as a team leaning on each other for help under the pressure of the project. I am glad to say we have grown together as a team through this process.
 +
 
 +
===Wen Da's Reflection===
 +
 
 +
“Plans are worthless, but planning is everything.”
 +
- Dwight D. Eisenhower. I like this quote alot because I can related to it so well. IS480 is the biggest project I have ever handle. Managing & delivering a huge project is a big challenge to me because there are so many points.
 +
"Coming together is a beginning; keeping together is progress; working together is success", this quote also speaks dearly to me for my whole IS480 journey, because my job as PM I need to ensure that my team keep together, I will think about the welfare of my team to keep them motivated and not feel burn out too often. Encouraging them and appraising them for their hard work. I also learnt that as a PM, it is important to be adaptive to the situation, using the metrics that I have to reschedule and reprioritize the tasks to ensure that we are able to deliver a quality system in time. Lastly, I am proud to say that we are able to work along together well for almost 8 months, my team supported each other during tough periods, committed their utmost effort and made sacrifices for each other.
  
  
[[Image:BannerBlack-01.png|1000px]]
+
<br>
<br></center>
+
[[Image:BannerBlack-01.png|center|1000px]]
 +
<br>

Latest revision as of 09:58, 24 November 2016

LogoBlackTall.png


NavHome.png   HOME

Icon5.png   OUR TEAM

NavProjectO.png   PROJECT OVERVIEW

NavPM.png   PROJECT MANAGEMENT

NavDoc.png   DOCUMENTATION


Screen Shot 2016-11-06 at 8.45.19 PM.png


Project Progress Summary


MonoCFinalProgress.png
Final Slides Deployed Site Video Pitch
PptPic.png MonoCDashboard.png MonoCVidPik.png

Project Highlights:

  • List of requirement changes
    • Added new 2 functions (Generate daily report, Configure settings)
  • UAT 4 is scheduled from 11 November to 14 November

Project Achievements:

  • Achieve 2nd X-factor (Monitor 20-30 sensors across 2 building for at least 2 months)
  • Successful implementation of Reverse SSH, stable and working. (Technology that is built in-house, as there are no commercially available API for this)
  • Successful implementation of SNMP, our web application is able to monitor WiFi router health status too

Project Management

Project Status:

Screen Shot 2016-11-06 at 10.54.32 PM.png
S/N FEATURES STATUS COMMENT
1 Database Module Fully deployed and tested 100% Completed
2 Data Collection Module Fully deployed and tested 100% Completed
3 Analytics Module Fully deployed and tested 100% Completed
4 Dashboard Module I Fully deployed and tested 100% Completed
5 Sensor Module Fully deployed and tested 100% Completed
6 Notification Module Fully deployed and tested 100% Completed
7 Two-way Communication Module Fully deployed and tested 100% Completed
8 Dashboard Module II Fully deployed and tested 100% Completed
9 Database Collection Module II Fully deployed and tested 100% Completed
10 Optimization Module Fully deployed and tested 100% Completed
11 Account Management Module Fully deployed and tested 100% Completed
12 Dashboard Module III Fully deployed and tested 100% Completed
13 Notification II Module Fully deployed and tested 100% Completed
14 Downtime Manager Module Fully deployed and tested 100% Completed
15 Mobile Responsive Module Fully deployed and tested 100% Completed

Project Schedule (Plan Vs Actual):

PLANNED ACTUAL
MonoCTimelinev5.png

MonoCTimelinev6.png

Project Scope (Plan Vs Actual):

PLANNED ACTUAL
MonoCFunctionalities v3.png

MonoCFunctionalities v4.png

ITERATIONS PLANNED ACTUAL COMMENT
10 - Perform speed test, Configure settings for 4 groups & flapping threshold, Generate daily summary report Oct 2016 New scope proposed by Sponsor
12 UAT 4 Nov 2016 - Scheduled UAT 4 to 14 Nov due to sponsor unavailability

Project Metrics:

  • Task metric is used for determining whether we are still in healthy zone for completing the project.
  • Till date, most of Task Metrics falls within the green zone. Only Iteration 8 have exceeded green zone, mitigation action has been taken.
  • Most of the bugs have been fixed in allocated days for debugging.
  • Metrics page: Click here to visit metrics page
TASK METRICS BUG METRICS
MonoChromeTM1.png MonoCBug.jpg

Project Risks:

Link to view full list of project risks: Monochrome Risk Assessment

Below are the top 2 risks from Midterms to Final Risk Management


MonoCFinalRisk.png


Technical Complexity:

TECHNICAL COMPLEXITY IMAGE DESCRIPTION
Front End: Maintaining React state

Before:

   From vertical menu: 
   $(‘#deleteSensorMac’).val(macAddress);
   
   In DeleteSensor.jsx: 
   var macAdd = $(‘#deleteSensormac’).val();

Problem: Erratic / unreliable

Redux.png

In traditional React applications, props can only be transferred from a parent to child component. this, however, can be inconvenient as certain components in complex web applications may need to receive props that cannot be passed on from its parent.


  • Our modals, for example, require information such as the mac address of a sensor. the DeleteSensorModal component, for instance, is a child of the Dashboard component.
  • There are two issues here:
    • Firstly, the component that triggers the DeleteSensorModal component to appear is not its parent. As such, it is unable to directly pass the mac address prop to the DeleteSensorModal component.
    • Secondly, the Dashboard component does not know which mac address is required as does not interact with the DeleteSensorModal component.
  • As such, we used Redux -- a React framework that is used to help to maintain state.
  • Actions are triggered from a component on user interaction. These actions store the mac address (or any other useful pieces of information) in a global state store. The component that requires the information retrieves it after.
Pinging Servers
Screen Shot 2016-11-14 at 2.41.14 AM.png

One of the issues that surfaced while we were testing for fault tolerance came about due to the way fault tolerance was implemented.

  • Data from Raspberry Pis is sent through FluentD, a unified logging layer, which buffers and stores it locally in case of connectivity issues. This ensures that data is not lost even if a Raspberry Pi is disconnected from the internet.


  • However, an unexpected limitation came when a sensor was disconnected for an extended period of time. The buffer was full when the internet connection came back, and the sensor began sending it's stored records. The records were sent in chronological order, which meant that the data being inserted to the database initially was out of date. It took nearly a half hour for the buffer to completely sent.


  • The fact that the records were older meant that the sensor was labelled as "down" on the dashboard, it was technically alive and sending data.


  • To circumvent this issue, we developed a secondary architecture for data logging, which involved sending small packets of data to indicate that a sensor was "alive". These logs are not sent through Fluentd, thus eliminating the buffering issue. The data in these logs is limited to a sensor's mac address and a timestamp, periodically inserted into the server's database.


  • Their sole function is to indicate whether a Raspberry Pi is "alive" or "down". This information is displayed in conjunction with the Raspberry Pi's status.


  • With this new system, a scenario where a Raspberry Pi is sending its buffer would have a ping result indicating that the Raspberry Pi is still alive, despite its being labelled as "down".
SNMP (Simple Network Management Protocol)
Screen Shot 2016-11-14 at 2.44.38 AM.png
Reasons why a Raspberry Pi might go "down" can be generalized into 3 categories: Issues with the Raspberry Pi, issues with its router, or connectivity issues.

  • The first can be easily discerned by the Raspberry Pi's status, but the latter two are more tricky. Routers often do not run the same operating systems as Raspberry Pis, making it harder to place custom scripts on them to allow collection of data
  • The use of Simple Network Management Protocol (SNMP) allowed us to solve this issue. Assigning one of the Raspberry Pis to run the snmpwalk program provided access to information about the router, including CPU usage, temperature, RAM, etc.
    • Users can then use this information to evaluate the status of the router, to determine if any issues with Raspberry Pis are due to the router as opposed to the Raspberry Pi itself.
  • This is used in conjunction with an internet speed test. Similar to the abovementioned snmpwalk, a Raspberry Pi is assigned to periodically run the speed test, and the results are displayed on the dashboard.
  • Poor speed test results could indicate that high downtime is due to poor internet connectivity, as opposed to issues with the Raspberry Pis or the router.

Quality of product

Project Deliverables:

STAGE SPECIFICATION MODULES
Project Requirements Market Analysis Summary Market Analysis, Detailed Market Analysis Report
Story board MonoChrome Story Board
Project Management Meeting Minutes MonoChrome Meeting Minutes Page
Task Metrics & Bug metrics MonoChrome Metrics Page
Risk Management MonoChrome Risk Assessment
Change Management MonoChrome Change Request
Design Use Case Diagram & Use case scenario MonoChrome Diagrams
UI Prototype MonoChrome Wire Framing
Testing Test plan MonoChrome Test cases
Handover Manuals User Tutorial
Code Client server

Quality:

MonoCArchitectureV3.png

Scalability/Performance

  • One of the requirements regarding this project from the client organization is the storage and retaining of all the collected data. Data collected are required to kept as long the client desires, this continuous scaling of data will eventually slow down the performance of the application and surface scalability issues.
  • As such, the application has been programmed with basic data indexing and data archiving capabilities to filter and store also data which are rarely in use by the application into a separate collection, to prevent data retrieval slowdown.
  • On top of data indexing and archiving, data will have to be converted into a more performance efficient format and stored in the database. This is where we implemented a NoSQL database, MongoDB, due to its flexibility in data storage and its ease of use.
  • We implemented "publish-subscribe" for our front-end information because the system only need to generate 1 set of data instead of having multiple user interface calling alot of APIs which will increase the laod of the server and resulting in slowing down the performance.
  • All the above mentioned will ensure our application always stays in top performance and less prone to slowdown from an ever expanding database.


Maintainability

  • The application is based on the Linux platform, where everyone in our client organization is extremely familiar with it. Data related functions such as CRUD (Create, Read, Update, Delete) in MongoDB, which our application uses for data storage, is all done in an Objected-Oriented manner.
  • This means future code maintenance relating to data retrieval can be easily performed by calling methods from the existing MongoDB Library rather than writing SQL queries which could cost more to maintain.
  • These reasons allow easier maintenance of the application for our client organization, as employees with basic programming knowledge without having to extensively train in multiple skills in order to perform basic maintenance.


Fault Management

  • The web application itself has no fault tolerance capabilities but it can be easily deployed into a cloud server that offers such capabilities such as AWS.
  • However, a collection of data is built with fault tolerance technologies to prevent any data loss during data transfer from each individual sensors deployed on the ground and the main server that hosts the database.
  • This is mainly done through Fluentd which buffers data locally in its hosted machine if a connection to the server is not found, where Fluentd will constantly check for the connection status with the database and flushes the buffered data to the database upon having the connection reestablished.
  • Furthermore, the database is frequently exported by the application in case of any unforeseen issues that could wipe out the database. The exported data can be easily inserted into the new database within a short amount of time to ensure the application will always be constantly up.


Configurability

  • The system offers configurable settings for user customization. This can be done through change the settings on the dashboard and the changes will be reflected into all the system calculation and analysis to reflect the changes made.


Security

  • The application will be part of the client organization and part of our role is to ensure the application and its data stays secure in the hands of our client organization.
  • In this regard, the application will be performed under OWASP test which include test like penetration test in order to find any security loop holes within the application which could potentially breach our client’s data confidentiality.
  • These loop holes, if found, will be swiftly patched up by our team.
  • On top of it, an IP lock will be implemented to enforce the security of the application in terms of access control. This will ensure access to the application are only open to only approved personnel determined by the client organization.
  • Below is the before and after report result:

Before fix report

OwaspReportBefore.png


After fix report

OwaspReportAfter.png


Deployment:

  • We deployed the site in an interative approach, every 2 weeks we will redeploy again with new functionalities.
  • The username and password have been given to client to login and use the dashboard.
  • The deployed site is live with company confidential data, so we are unable to let users to login and see. However, we provide a navigation diagram below.
  • Link to use case diagram: Use Case Diagram
SITEMAP
Screen Shot 2016-11-14 at 10.15.34 AM.png

Testing:

Functionality & Regression Testing

Testing Remarks Total
Functionality Testing Every module test 8
Regression Testing Every iteration test 9

UAT:

  • We have successfully completed all of our 4 UAT.
  • The objective, test cases and results can be view on the UAT page.
USER TESTING DATE USER PROFILE LINK
UAT 1 3 August 2016 Thomas Wong (Sponsor) + 5 random users User Acceptance Test 1 Link
UAT 2 22 August 2016 Thomas Wong (Sponsor) + Cecilia Sim (Sponsor) + Hazmei Bin Abdul Rahman (ORT Intern) User Acceptance Test 2 Link
UAT 3 13 September 2016 Thomas Wong (Sponsor) + Sean Ang (Full time staff) + Lim Shuen (Intern) User Acceptance Test 3 Link
UAT 4 14 November 2016 Thomas Wong (Sponsor) + Cecilia Sim (Sponsor) + Sean Ang (Full time staff) User Acceptance Test 4 Link

Reflection

Team Reflection:

We learnt that it is important to keep an open-mind when developing an application for a client because along the way there will be unforeseen circumstances, many unknown unknown that we need to solve as well as take in feedbacks from the various stakeholder. IS480 have given us an opportunity to learn real life skill sets and to stretch us beyond our limits.

Ian's Reflection:

This project has been quite a journey. Before we started, my knowledge was limited to what was taught in the classroom. Six months later, this project has, in a sense, forced my teammates and I to learn, explore, and experience unfamiliar technologies and techniques. For instance, reverse ssh is one of the techniques I picked up during this project, and making it persistent and stable became an experiment in and of itself.

Marcus's Reflection

I've made the adage "good artists copy, great artists steal" my motto throughout the course of the project. Rather than trying to reinvent the wheel, I scoured the internet for ideas on dashboard design elements and pieced a couple of good ones together as a deliverable. I've learned to be more acceptive of criticism and ideas that oppose mine. This, in turn, helped to spark fresh ideas that had far more depth. As a team, I'm proud to say that we've accomplished what we labeled as "impossible" at the start of the project.

Yong Jin's Reflection

On top of the knowledge and skills, in cutting edge skill areas such as IoT and NoSQL, that I have took away from this project. I have also learnt to work better in a VUCA (Volatility, Uncertainty, Complexity, Ambiguity) environment better. Before embarking on this project, I have been working in classroom projects with a feeling of certainty. In those classroom projects, I am first taught the necessary knowledge, then applying them on an well-thought out problem. It has been a planned out route, the assigned task (project) can be accomplished as long guides and instructions from the assigned instructors are followed. This project has been a total brand new experience for me, knowledge has to be self acquired with the application on a ever changing existing problem. Trying my hands on unexplored technology will definitely lead to unexpected results, such as unexpected break downs and errors. Thus, the past me who relied on certainty ceased to exist. Having to face conditions of uncertainty and volatility, I have learnt to map out for possible outcomes and make better adjustments for such scenarios.

Sarah's Reflection

During the course of this project, I have learned the importance of quality assurance. Learning to make changes based on user testing results has allowed the team to constantly improve on the dashboard, ensuring the client's satisfaction. This project has been a new experience for me as I often worked alone in the past. Working with my teammates on this project has shown me how to work efficiently as a team leaning on each other for help under the pressure of the project. I am glad to say we have grown together as a team through this process.

Wen Da's Reflection

“Plans are worthless, but planning is everything.” - Dwight D. Eisenhower. I like this quote alot because I can related to it so well. IS480 is the biggest project I have ever handle. Managing & delivering a huge project is a big challenge to me because there are so many points. "Coming together is a beginning; keeping together is progress; working together is success", this quote also speaks dearly to me for my whole IS480 journey, because my job as PM I need to ensure that my team keep together, I will think about the welfare of my team to keep them motivated and not feel burn out too often. Encouraging them and appraising them for their hard work. I also learnt that as a PM, it is important to be adaptive to the situation, using the metrics that I have to reschedule and reprioritize the tasks to ensure that we are able to deliver a quality system in time. Lastly, I am proud to say that we are able to work along together well for almost 8 months, my team supported each other during tough periods, committed their utmost effort and made sacrifices for each other.



BannerBlack-01.png