Difference between revisions of "IS480 Team wiki: 2016T1 MonoChrome Midterms"
Line 183: | Line 183: | ||
|} | |} | ||
− | + | ===Project Scope (Plan Vs Actual):=== | |
+ | {| class="wikitable" | ||
+ | |- style="background:#1d4c5d; color:#88C1F8" | ||
+ | ! 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 | ||
+ | |- | ||
+ | |[[File:MonoCSchedule2.png|500px]] || | ||
+ | [[File:MonoCTimelinev5.png|500px]] | ||
+ | |} | ||
<center> | <center> |
Revision as of 00:52, 27 September 2016
Project Progress Summary
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:
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):
PLANNED | ACTUAL |
---|---|
Project Scope (Plan Vs Actual):
PLANNED | ACTUAL |
---|---|
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 | - | Scheduled to complete UAT 3 earlier 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:
- 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.
- Iteration 8 have exceeded the green zone, mitigation action have been taken. The schedule is on track.
- Metrics page: Click here to visit metrics page
TASK METRICS | BUG METRICS |
---|---|
Project Risks:
Link to view full list of project risks: Monochrome Risk Assessment
- We learnt that at different stage of the project, different risk arises.
- Because there are limited time and constraints that we faced, we have become very critical and review every new request. Through this experience, we realized the importance of prioritization. Therefore, we have revamp our change request management process to standardize the process of receiving a new request from sponsor.
- Below is the process that we have came up with for mitigating client management risk:
Below are the top 3 risk from Acceptance to Midterms Risk Management
S/N | RISK TYPE | RISK EVENT | LIKELIHOOD | IMPACT | CATEGORY | MITIGATION |
---|---|---|---|---|---|---|
1 | Technical Risk | 2-way communication is difficult to implement, as there are no commercially available APIs | High | High | A |
|
2 | Client Management Risk | Project scope changes as the project progress | High | High | A |
|
3 | Technical Risk | Front end lacking of manpower to code the charts | High | High | A |
|
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
Non-functionality(Speed)
To ensure a quality platform, we did non-functionality testing like speed test. The objective is to test whether our monitoring platform is able to match
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 |
Deployment:
- The deployed site is live with company confidential data, so we are able to show the dashboard, however we are able to show the dashboard components and site map.
- Link to use case diagram: Use Case Diagram
DASHBOARD COMPONENT | 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.
Reflection
Team Reflection:
Reaching the mid-term milestone, we are still going on strong and we are proud for what we have achieved so far. We are glad that we have each other to pull through this together.
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
Through this FYP process i have learned to be more meticulous to ensure that the application is constantly improving for the better. Wanting our users to have a good user experience, has taught me not to overlook the minute details and really understand from the users perspective.
Being open to feedback from our testers without being defensive, has also allowed us to greatly improve our application.
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.