HeaderSIS.jpg

IS480 Team wiki: 2016T1 MonoChrome Midterms

From IS480
Revision as of 14:26, 23 September 2016 by Wenda.yeo.2014 (talk | contribs)
Jump to navigation Jump to search
LogoBlackTall.png


NavHome.png   HOME

Icon5.png   OUR TEAM

NavProjectO.png   PROJECT OVERVIEW

NavPM.png   PROJECT MANAGEMENT

NavDoc.png   DOCUMENTATION


MidtermWikiMonoC.png


Project Progress Summary


MonoCSummary.png
Midterm Slides Deployed Site
PptPic.png MonoCSitelink.png

Midterm Snapshot

  • Achieved X-Factor (Successfully deployed and monitored 20 sensors across 2 buildings on 15 September 2016)
  • Our platform is a monitoring solution that incorporated communication with devices without public IP addresses.
  • Current platform is ready to monitor any devices/servers with Linux-based OS
  • Current platform has successfully built in command prompt terminal specifically for every device
  • Notification module successfully completed
  • Conducted 3 UAT successfully

Project Highlights:

  • Rescheduled 2-way communication to be completed before new live deployment date
  • 2-way is more complicated then we estimated, resulted in delayed in Iteration 8
  • After live deployment, there are many unexpected bugs and issues occurred. Resulted in scheduling sessions for optimizating most of the functionalities
  • Planning for better anytical work for monitoring sensors to reduce false positive

Project Management

Project Status:

MonoCStatus.png
S/N FEATURES STATUS CONFIDENCE LEVEL(0 - 1.0) COMMENT
1 Database Module Fully deployed and tested 100% 1 Completed
2 Data Collection Module Fully deployed and tested 100% 1 Completed
3 Analytics Module Fully deployed and tested 100% 1 Completed
4 Dashboard Module I Fully deployed and tested 100% 1 Completed
5 Sensor Module Fully deployed and tested 100% 1 Completed
6 Notification Module Fully deployed and tested 100% 1 Completed
7 Two-way Communication Module Fully deployed and tested 100% 1 Completed
8 Dashboard Module II In progress 1 In progress
9 Mobile Responsive Module In progress 1 Will always revise the mobile responsiveness for every change in design
10 Account Management Module In progress 1 "Register new user account" to be completed in Iteration 10
11 Optimization Module In progress 1 New scope proposed by Monochrome: Archiving; Half of Security Module moved to this new module.
12 Dashboard Module III Scheduled for Future Development 1 To Be Completed
13 Downtime Scheduler Module Scheduled for Future Development 1 To Be Completed
14 Security Module Removed upon negtiation N.A Removed upon negtiation

Project Schedule (Plan Vs Actual):

Compare the project plan during acceptance 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.

Planned Schedule from Acceptance

MonoCSchedule2.png


Actual Schedule

Timelinev4.png
ITERATIONS PLANNED ACTUAL COMMENT
7 UAT 2 22 Aug 2016 UAT 2 22 Aug 2016 Newly added in UAT after acceptance feedback. Rationale: Small group of users in company, require need more UAT to gather more feedbacks
UAT 3 8 Sept 2016 - Pushed UAT 3 to be completed before live deployment on 15 Sept
2-way communication Iteration 8,9 2-way communication Iteration 7,8 Rescheduled earlier to deliver 2 way-communication module before live deployment on 15 Sept. Dashboard module I & Database Module were pushed to the back
8 UAT 3 8 Sept 2016 UAT 3 13 Sept 2016 2-way communication is unexpectedly difficult, could not finish in time. Required to push UAT 3 back.
- Display detailed information of the servers (Canvas Mode) 29 Aug 2016 New scope proposed by sponsor
9 - Optimization Module 18 Sept 2016 New scope proposed by Monochrome
Security Module 18 Sept 2016 - Removed proposed by Monochrome

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.

Project Risks:

Update the proposal assumptions and risks. Describe what you learn from the risk update and mitigation steps taken.

Risk Probability Impact Mitigation
Sponsor want to use Joomla instead of Drupal High High Team evaluating Joomla to write an impact analysis report
Sponsor deployment machine approval and support High Medium (now it is low) Use UPL machine

Be sure to prioritize the risks.

Technical Complexity:

Describe and list the technical complexity of your project in order of highest complexity first. For example, deploying on iPhone using Objective-C, customizing Drupal with own database, quick search for shortest flight path, database structure, etc.

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.

Intermediate Deliverables:

Topic of Interest Link
Project Management Minutes
Metrics
Risk Management
Change Management
Project Overview Project Overview
Team's Motivation
Project Documentation Use Case
Tech & System Architecture
Testing Testing Documentation

Not all parts of the deliverables are necessary but the evidence should be convincing of the progress. Try to include design deliverables that shows the quality of your project.

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.

  • The deployed site is live with company confidential data.
  • Inset sitemap

Testing:

  • Till date, we have completed 3 UAT.
  • The details of the testing like the number of tester profile, test cases, test results and bug can be view from the UAT page.
UserTesting 01.jpg UserTesting 02.jpg UserTesting 03.jpg

Reflection

In this section, describe what have the team learn? Be brief. Sometimes, the client writes a report to feedback on the system; this sponsor report can be included or linked from here.

Team Reflection:

We are proud for what we have achieved so far.

Ian's Reflection:

Write code that is easy to understand — As a programmer, I have a tendency to focus simply on code that works, but just as important is code that is understandable. As we progressed, I find that there are many instances where code that was written weeks or months prior has to be revisited, to be revised or optimized. Another possibility is that another programmer might have to look at my code. Easily understandable code then becomes essential and a necessity.

To be unafraid to try something new — There can be multiple different ways to solve a problem, and when researching these solutions, the best solution might not be immediately obvious. When we finally decide to implement a solution, we may find out later that it's not the best one. It is not easy to give up on our current solution in favor of a better. One example is the terminal in browser, which we need to be persistent and support multiple connections. The original solution, shellinabox, worked well, but we encountered stability issues soon after. It did not seem to be able to support multiple connections at once. In the end we had to give up on shellinabox, and implemented a more stable solution, wetty.


Marcus's Reflection

Drawing component diagrams helped to frame my thought processes — I was able to visualize parent-child component relationships. This was essential in managing data flow.

Revising code periodically made code maintenance easier — I managed to shorten a script by a significant number of lines by simply converting a switch case to an associative array. In some instances, it eliminated redundant or repeated code.


Yong Jin's Reflection

As a backend developer, code enhancement is always an never ending process. In order to push the limits of the proc rate on the dashboard, the codes are looked into over and over again. As the proc rate increase, it feels good to know the codes are slowly reaching this utopia called perfection.

However, as someone who likes to be constantly challenged, the utopia named "perfection" would bring loneliness to me. As there nothing else that is able to make me continously challenge myself, to reach further.

Sarah's Reflection

Wen Da's Reflection

It is an enjoyable process as a project manager. I have learned so much from acceptance feedback till today. There is no perfect planning, plans always change due to unforeseen circumstances when we started rolling out the functionalities after building backend. It is always a constant reprioritization of functionalities, re-evaluating the business value of the function with the sponsor and meeting expectations from different stakeholders.

For instance, the live deployment magnified the loopholes in our coding. On the day of live deployment, there was a surge of sensors and the amount of data collected was huge. It slowed down the whole querying time and the performance of the dashboard was greatly impacted. We had to resolve this problem immediately by proposing new scope to optimize the querying.

I am looking forward to more challenges ahead and strengthen my project management skills.

BannerBlack-01.png