Difference between revisions of "IS480 Team wiki: DYMSZ Final"
May.koh.2012 (talk | contribs) |
May.koh.2012 (talk | contribs) |
||
(28 intermediate revisions by 2 users not shown) | |||
Line 60: | Line 60: | ||
==<div style="background: #0070C0; padding: 15px; line-height: 1.3em;font-size:24px"><font color="#EED82E" face="impact">DYMSZ</font><font color= "#ffffff" face="impact"> Project Progress Summary</font></div>== | ==<div style="background: #0070C0; padding: 15px; line-height: 1.3em;font-size:24px"><font color="#EED82E" face="impact">DYMSZ</font><font color= "#ffffff" face="impact"> Project Progress Summary</font></div>== | ||
<font color="#000000" face="gotham" size="3">View our Final Presentation Slides </font> | <font color="#000000" face="gotham" size="3">View our Final Presentation Slides </font> | ||
− | [[Media: | + | [[Media:DYMSZ - Final Version.pdf | '''<font face="gotham" size="3" color="#007CDC">HERE!</font>''']] <br/> |
<div> | <div> | ||
<font color="#000000" face="gotham" size="3"> | <font color="#000000" face="gotham" size="3"> | ||
− | <font color="#000000" face="gotham" size="3"> | + | <font color="#000000" face="gotham" size="3">View our Pitch Video </font> |
[https://www.youtube.com/watch?v=OcVXrgDLMuU '''<font face="gotham" size="3" color="#007CDC">HERE!</font>''']<br/> | [https://www.youtube.com/watch?v=OcVXrgDLMuU '''<font face="gotham" size="3" color="#007CDC">HERE!</font>''']<br/> | ||
<div> | <div> | ||
<font color="#000000" face="gotham" size="3"> | <font color="#000000" face="gotham" size="3"> | ||
+ | ===<font size="5px" color="#0070C0" face="gotham"> Project Summary</font>=== | ||
− | *Current Iteration <font color="0070C0">12</font> | + | |
+ | *Current Iteration: <font color="0070C0">12</font> | ||
*Deliverables: <font color="0070C0">Prepare for Finals, prepare for poster Day, Handover Documents for ESET</font> | *Deliverables: <font color="0070C0">Prepare for Finals, prepare for poster Day, Handover Documents for ESET</font> | ||
*As of 21st Apr 2015, we have completed all our <font color="#007CDC">Primary</font> and <font color="#007CDC">Secondary</font> and <font color="#007CDC">Tertiary</font> Functions<br/> | *As of 21st Apr 2015, we have completed all our <font color="#007CDC">Primary</font> and <font color="#007CDC">Secondary</font> and <font color="#007CDC">Tertiary</font> Functions<br/> | ||
− | + | <br/> | |
</font> | </font> | ||
Line 104: | Line 106: | ||
− | <font color="# | + | <font color="#000000" face="gotham" size="3"> |
+ | This is one of the few projects in this semester that has been developed for a Multi-National Corporation. Understanding their requirements, as well as working with the stakeholders from different levels, from the Salesman to Manager to Director Level, has been an enriching experience. | ||
+ | |||
+ | The scope of the project has been changed frequently by our sponsors, and we have constantly strived to accept these additional changes, whilst ensuring that the project is still being managed well, in terms of the amount of time allocated for the project. | ||
+ | We've focused on providing a full package solution, from the pushing of application content into the mobile app, to monitoring it's usage through the web portal. We have utilised external technologies and guidelines to help deliver that, such as: | ||
+ | HighChart.js Framework | ||
+ | Google's Material Design Guideline | ||
+ | We have achieved international deployment, with 20 salespeople across the Asian Region undertaking this initiative as the first stage of deployment. | ||
+ | </font> | ||
===<font size="5px" color="#0070C0" face="gotham"> Project Challenges</font>=== | ===<font size="5px" color="#0070C0" face="gotham"> Project Challenges</font>=== | ||
+ | |||
+ | |||
+ | <font color="#000000" face="gotham" size="3"> | ||
+ | Adapting to changes in the Project Scope while suggesting alternatives or add-ons to improve them:<br/> | ||
+ | 1. Sales Memo to help make tracking of orders more intuitive for Salespeople<br/> | ||
+ | 2. Analytics to understand more about the usage of the application<br/> | ||
+ | |||
+ | Figuring out how to configure FTP server to support the uploading of PDF documents | ||
+ | |||
+ | Figuring out how to incorporate mathematical algorithms into HighCharts Javascript Framework to show Predictive Analytics | ||
+ | |||
+ | </font> | ||
===<font size="5px" color="#0070C0" face="gotham"> Project Achievements</font>=== | ===<font size="5px" color="#0070C0" face="gotham"> Project Achievements</font>=== | ||
+ | |||
+ | <font color="#000000" face="gotham" size="3"> | ||
+ | 1. International Deployment | ||
+ | We have successfully deployed the local APK to a few salespeople of several countries in the Asian Pacific Region, as the beginning milestone of our large-scale deployment in the Asian Region. Unfortunately, as Emerson Network Power is an MNC, it takes time to expand it into a large scale deployment, and the team will not be able to witness it. | ||
+ | |||
+ | |||
+ | 2. Adapting to Technical Challenges | ||
+ | Throughout the project, we have suggested improvements to our current existing scope, and Emerson Network Power has given us the opportunity to develop them to value-add to the current project. These changes have been incorporated into our mobile application ESET, such as the Sales Memo and the Web Portal Analytics. | ||
+ | |||
+ | We have came up with technical work-arounds to tackle the problems that we face in the Project: | ||
+ | |||
+ | 2.1 File Storage<br/> | ||
+ | Making the storage and transfer of large files (typically pdfs) efficient. Our original implementation involved the storage of images as BLOB objects in the MySQL database, leading to errors during upload and downloading of images. | ||
+ | The transfer of images via JSON also caused a huge overhead as it uses Base64 encoding (which increases the length of strings by ~37%), leading to the transaction size to hit above the limit, which lead to failures in data transmission. | ||
+ | Therefore, we came up with the solution of storing these files in the FTP server instead, and the android device downloads directly from the FTP server. Apart from that, instead of sending long Base64 strings, file paths are sent over via JSON and the android device downloads the files that we stored in the FTP server directly. | ||
+ | |||
+ | 2.2 ListView VS RecyclerView<br/> | ||
+ | Before that, using ListView, we loaded each row, and they will run the code once using the inflate method. This means that new views are always inflated, and it was inefficient in terms of phone memory usage. | ||
+ | We decided to use RecycleView as compared to ListView, it recycles the existing views. This helps to saves CPU resources in that you do not have to inflate new views all the time and it saves memory in that it doesn’t keep plenty of invisible views around. | ||
+ | So, to conclude RecycleView is more flexible in handling "list data" and implementing more complex displays, like a list/grid/hybrid, with animations, and allows for a more dynamic presentation in our application's user interface. | ||
+ | |||
+ | |||
+ | |||
+ | </font> | ||
==<div style="background: #0070C0; padding: 15px; line-height: 1.3em;font-size:24px"><font color="#EED82E" face="impact">DYMSZ</font><font color= "#ffffff" face="impact"> Project Management </font></div>== | ==<div style="background: #0070C0; padding: 15px; line-height: 1.3em;font-size:24px"><font color="#EED82E" face="impact">DYMSZ</font><font color= "#ffffff" face="impact"> Project Management </font></div>== | ||
+ | <font color="#000000" face="gotham" size="3"> | ||
+ | We have came up with a Change Management Metrics to measure the magnitude of changes by our sponsors, and gauge the actual amount of additional scope and effort we need to put in, and understand whether it is feasible to continue to do so. Thus far, we have been successful in discussing and reviewing changes in scope from our Sponsors for many Iterations, and have still been able to keep to our original schedule. | ||
+ | </font> | ||
===<font size="5px" color="#0070C0" face="gotham"> Project Schedule (Plan Vs Actual)</font>=== | ===<font size="5px" color="#0070C0" face="gotham"> Project Schedule (Plan Vs Actual)</font>=== | ||
− | {| border="1" cellpadding=" | + | {| border="1" cellpadding="2" cellspacing="0" style="margin-top:3px" width="100%" |
|- style="background:#007CDC; color:white" | |- style="background:#007CDC; color:white" | ||
|align="center"| '''<font face="gotham" size="3px">Interation</font>''' | |align="center"| '''<font face="gotham" size="3px">Interation</font>''' | ||
Line 356: | Line 405: | ||
===<font size="5px" color="#0070C0" face="gotham"> Project Metrics</font>=== | ===<font size="5px" color="#0070C0" face="gotham"> Project Metrics</font>=== | ||
+ | |||
+ | |||
+ | |||
+ | <font color="#154370" face="gotham" size="4.5"> Project Metrics: </font><br/><br/> | ||
+ | <font color="#2E3535" face="gotham" size="3"><b>View our Schedule Metrics </b></font> | ||
+ | [[IS480 Team wiki: DYMSZ Metrics Management |<font color="#007CDC" face="gotham"> HERE!</font>]]<br/> | ||
+ | <br/> | ||
+ | <font color="#2E3535" face="gotham" size="3"><b>View our Bug Metrics </b></font> | ||
+ | [[IS480 Team wiki: DYMSZ Bug Metric |<font color="#007CDC" face="gotham"> HERE!</font>]]<br/> | ||
+ | <br/> | ||
+ | <font color="#2E3535" face="gotham" size="3"><b>View our Change Management Metrics </b></font> | ||
+ | [[IS480 Team wiki: DYMSZ Change Management |<font color="#007CDC" face="gotham"> HERE!</font>]]<br/> | ||
+ | <br/> | ||
+ | <font color="#154370" face="gotham" size="4.5">Project Risks: </font><br/> | ||
+ | <font color="#2E3535" face="gotham" size="3"><b>View our Project Risks</b></font> | ||
+ | [[IS480 Team wiki: DYMSZ Risks Management |<font color="#007CDC" face="gotham"> HERE!</font>]]<br/> | ||
+ | |||
+ | |||
+ | <font color="#154370" face="gotham" size="4.5">Change Management: </font><br/> | ||
+ | <font color="#2E3535" face="gotham" size="3"><b>View our Change Management Metrics</b></font> | ||
+ | [[IS480 Team wiki: DYMSZ Change Management |<font color="#007CDC" face="gotham"> HERE!</font>]]<br/> | ||
===<font size="5px" color="#0070C0" face="gotham"> Technical Complexity</font>=== | ===<font size="5px" color="#0070C0" face="gotham"> Technical Complexity</font>=== | ||
+ | |||
+ | ===Problem 1:=== | ||
+ | Display of large list of items is inefficient and consumes a lot of memory | ||
+ | Solution: | ||
+ | Having an efficient display of the products through an Implementation of RecyclerView with Viewholder design pattern for element, to minimise memory consumption and efficient scrolling of items to replace listview. | ||
+ | Reasons for implementation: | ||
+ | For every single row creation, we have to create the xml file that has the layout of the row and inflate it in code. However, layout inflation for every row is memory intensive. Apart from that, the application has to find row elements such as Text and Image with a findViewById method and populate the elements which is even more memory intensive. | ||
+ | RecyclerView is the appropriate view to use when you have multiple items of the same type and it’s very likely that the device cannot present all of those items at once. The user has to scroll up and down to see more items and that’s when the recycling and reuse comes into play. As soon as a user scrolls a currently visible item out of view, this item’s view can be recycled and reused whenever a new item comes into view. This saves CPU resources, as you do not have to inflate new views all the time. It saves memory in that it doesn’t keep plenty of invisible views around. | ||
+ | However, the RecyclerView does not animate views. It also does not handle any touch events apart from scrolling. Therefore, we need to implement a gesture detector that utilises a gesture listener to listen out for a motion event to find out the x and y coordinates that is clicked to find out the exact row which is clicked on the recycler view. | ||
+ | Benefits / Outcome: | ||
+ | Product list loads faster | ||
+ | No lag user experience when user is scrolling the list | ||
+ | Application does not crash after long periods of scrolling | ||
+ | |||
+ | |||
+ | <table><tr><td> | ||
+ | [[File:DYMSZ - TD1S2v3.png|300px|center]] | ||
+ | </td> | ||
+ | <td>[[File:DYMSZ - TD1S2v4.png|300px|center]]</td> | ||
+ | <td> | ||
+ | [[File:DYMSZ - TD1S2v5.png|300px|center]] | ||
+ | </td> | ||
+ | </tr> | ||
+ | </table> | ||
+ | |||
+ | ===Problem 2: === | ||
+ | Intensive operations are managed by a single UI thread | ||
+ | Solution: Usage of asynchronous task to do processing of intensive operations on a separate thread | ||
+ | Reasons for implementation: | ||
+ | As the main UI thread is only supposed to be in charge of rendering the UI elements in the android application, executing intensive operations on the main UI thread cause frames to be skipped, which can cause the thread to stop for a while. From the user’s point of view, he will either experience a black screen and is unable to interact with the application under the processing has ended which is a very undesirable user experience. | ||
+ | There are 3 parts to it. | ||
+ | Firstly, in onPreExecute, we need to tell the user to wait for the processing to be done and this provides update to system status as compared to previous implementation. | ||
+ | Next, we will do all the processing in the doInBackground which runs on a separate. | ||
+ | Lastly, the post execute method informs the user that the processing has ended. | ||
+ | Benefits / Outcome: | ||
+ | User is aware that he has to wait for background processes and not have to figure out why he cannot interact with the application temporality or think that the application has crashed. | ||
+ | Efficient handling of intensive operations which reduces time taken for it to complete as it no longer has to operate on the main UI thread which competes from resources that renders the user interface. | ||
+ | |||
+ | <table> | ||
+ | <tr> | ||
+ | <td>[[File:DYMSZ - TD2v1.png|400px|center]]</td> | ||
+ | <td> | ||
+ | [[File:DYMSZ - TD2v2.png|400px|center]] | ||
+ | </td></tr> | ||
+ | </table> | ||
==<div style="background: #0070C0; padding: 15px; line-height: 1.3em;font-size:24px"><font color="#EED82E" face="impact">DYMSZ</font><font color= "#ffffff" face="impact"> Quality of Product </font></div>== | ==<div style="background: #0070C0; padding: 15px; line-height: 1.3em;font-size:24px"><font color="#EED82E" face="impact">DYMSZ</font><font color= "#ffffff" face="impact"> Quality of Product </font></div>== | ||
Line 410: | Line 525: | ||
|- | |- | ||
− | |rowspan=" | + | |rowspan="1"| Design |
− | || | + | |
− | || [[IS480 Team wiki: | + | || Deployment Diagram |
+ | || [[IS480 Team wiki: DYMSZ Project Documentation|'''Deployment Diagram''']] | ||
|- | |- | ||
− | || | + | |
− | || | + | |} |
+ | |||
+ | ===<font size="5px" color="#0070C0" face="gotham"> Quality</font>=== | ||
+ | |||
+ | ===TECHNICAL QUALITY=== | ||
+ | ====Maintainability==== | ||
+ | - We reused the same fragment class for multiple views. Initially, the design of the application required us to create a new fragment class whenever there was a new page of the same design. That was very intensive as we had to maintain a large set of classes and make changes over multiple files. To prevent the increasing amount of files created and duplication of codes, we decided to just create a fragment class and instantiate multiple instances of the same class to replicate similar views and this reduces the amount of files created significantly. | ||
+ | |||
+ | ====Usability==== | ||
+ | - Adopting swipe-based navigation. As our product was organised in categories, the user had to click into a category to view the content and go back to the list of categories before he could select another category to view. By implementing swipe-based navigation, the user can now enjoy seamless viewing of multiple content pages without having to navigate to and fro between pages. It also provided the user with a directional feel when swiping left and right of the screen. | ||
+ | |||
+ | - Input filter criteria through a dialog to allow the user to filter and view the results while staying on the same page. Our initial design was creating a page of filter criteria for the user to key in the view the related results. However, whenever the user wanted to reselect the criteria he had to navigate to the criteria page to do the selection. By implementing a pop-up dialog, the user does not need to navigate to a separate filter page again, as he is able to input filter criteria and view the results on the same page. | ||
+ | |||
+ | ====Flexibility==== | ||
+ | - Passing information between app screens. Historically, each screen in an Android app was implemented as a separate Activity. This creates a challenge in passing information between screens because the Android Intent mechanism does not allow passing a reference type (i.e. object) directly between Activities. Instead the object must be serialized or a globally accessible reference made available. | ||
+ | By making each screen a separate Fragment, we are able to solve the data passing redundancy problem. Fragments always exist within the context of a given Activity and can always access that Activity. By storing the information of interest within the Activity, the Fragment for each screen can simply access the object reference through the Activity. | ||
+ | |||
+ | {| border="1" cellpadding="4" cellspacing="0" width ="100%" | ||
+ | |- style="background:#007CDC; color:white;" | ||
+ | |align="center"| '''Type''' | ||
+ | |align="center"| '''Information''' | ||
|- | |- | ||
− | || | + | |align="center"| Web Application <br/> |
− | || | + | |align="center"| ESET (Emerson Sales Enablement Tool) Admin Portal |
+ | |- | ||
+ | |||
+ | |align="center"| Database <br/> | ||
+ | |align="center"| MySQL | ||
+ | |- | ||
+ | |||
+ | |align="center"| Server <br/> | ||
+ | |align="center"| Digital Ocean (Emerson Network Power Account) | ||
+ | |- | ||
+ | |||
+ | |align="center"| Deployed Link <br/> | ||
+ | |align="center"| http://128.199.182.247:8080/Emerson/ | ||
|- | |- | ||
|} | |} | ||
− | |||
− | |||
===<font size="5px" color="#0070C0" face="gotham"> Deployment</font>=== | ===<font size="5px" color="#0070C0" face="gotham"> Deployment</font>=== | ||
===<font size="5px" color="#0070C0" face="gotham"> Testing</font>=== | ===<font size="5px" color="#0070C0" face="gotham"> Testing</font>=== | ||
+ | |||
+ | <br/> | ||
+ | {| border="1" cellpadding="4" cellspacing="0" width ="100%" | ||
+ | |- style="background:#007CDC; color:white;" | ||
+ | |align="center"| '''User Test''' | ||
+ | |align="center"| '''Date of User Test''' | ||
+ | |align="center"| '''Objectives''' | ||
+ | |align="center"| '''No of Participants''' | ||
+ | |align="center" width="10%"| '''Link''' | ||
+ | |- | ||
+ | |||
+ | |align="center"| Usability Test 1(Macro) <br/> | ||
+ | |align="center"| 08/01/2015 - 09/01/2015 | ||
+ | || | ||
+ | *Gather General Feedback on usability and usefulness of developed modules | ||
+ | *Find out which modules are the most useful to salespeople and whether it is easy to use | ||
+ | |align="center"| 25 | ||
+ | |align="center"| [[IS480 Team wiki: DYMSZ USER TESTING#DYMSZ FIRST USER TEST RESULTS| User Test 1]] | ||
+ | |- | ||
+ | |||
+ | |align="center"| Usability Test 2 (Focus Group Study) <br/> | ||
+ | |align="center"| 12/02/2015 - 13/02/2015 | ||
+ | || | ||
+ | *Gather Specific feedback on usability and usefulness of developed modules as well as new modules | ||
+ | |align="center"| 5 | ||
+ | |align="center"| [[IS480 Team wiki: DYMSZ USER TESTING#DYMSZ SECOND USER TEST RESULTS| User Test 2]] | ||
+ | |- | ||
+ | |||
+ | |align="center"| User Acceptance Test 1 (Focus Group Study) <br/> | ||
+ | |align="center"| 12/03/2015 - 13/03/2015 | ||
+ | || | ||
+ | *To ensure that the user is satisfied with the features before releasing the application to the salesman | ||
+ | |align="center"| 5 | ||
+ | |align="center"| [[IS480 Team wiki: DYMSZ USER TESTING#DYMSZ THIRD USER TEST RESULTS| User Acceptance Test 1]] | ||
+ | |- | ||
+ | |} | ||
+ | <br/><br/> | ||
==<div style="background: #0070C0; padding: 15px; line-height: 1.3em;font-size:24px"><font color="#EED82E" face="impact">DYMSZ</font><font color= "#ffffff" face="impact"> Reflection </font></div>== | ==<div style="background: #0070C0; padding: 15px; line-height: 1.3em;font-size:24px"><font color="#EED82E" face="impact">DYMSZ</font><font color= "#ffffff" face="impact"> Reflection </font></div>== | ||
Line 477: | Line 660: | ||
===<font size="5px" color="#0070C0" face="gotham"> Sponsor Comment</font>=== | ===<font size="5px" color="#0070C0" face="gotham"> Sponsor Comment</font>=== | ||
<!--End content--> | <!--End content--> | ||
+ | [[File:DYMSZ(Sponsor comments).jpg|600px|left]] |
Latest revision as of 15:26, 21 April 2015
ABOUT US |
MAIN PAGE |
Contents
DYMSZ Project Progress Summary
View our Final Presentation Slides
HERE!
View our Pitch Video
HERE!
Project Summary
- Current Iteration: 12
- Deliverables: Prepare for Finals, prepare for poster Day, Handover Documents for ESET
- As of 21st Apr 2015, we have completed all our Primary and Secondary and Tertiary Functions
Milestones Completed
- Proposal Submission
- Acceptance
- UT-1
- UT-2
- UAT-3
- Mid-Terms Presentation
Milestones Pending
- Final Presentation
- Poster Day
Changes in Scope
Project Highlights
This is one of the few projects in this semester that has been developed for a Multi-National Corporation. Understanding their requirements, as well as working with the stakeholders from different levels, from the Salesman to Manager to Director Level, has been an enriching experience.
The scope of the project has been changed frequently by our sponsors, and we have constantly strived to accept these additional changes, whilst ensuring that the project is still being managed well, in terms of the amount of time allocated for the project.
We've focused on providing a full package solution, from the pushing of application content into the mobile app, to monitoring it's usage through the web portal. We have utilised external technologies and guidelines to help deliver that, such as: HighChart.js Framework Google's Material Design Guideline
We have achieved international deployment, with 20 salespeople across the Asian Region undertaking this initiative as the first stage of deployment.
Project Challenges
Adapting to changes in the Project Scope while suggesting alternatives or add-ons to improve them:
1. Sales Memo to help make tracking of orders more intuitive for Salespeople
2. Analytics to understand more about the usage of the application
Figuring out how to configure FTP server to support the uploading of PDF documents
Figuring out how to incorporate mathematical algorithms into HighCharts Javascript Framework to show Predictive Analytics
Project Achievements
1. International Deployment We have successfully deployed the local APK to a few salespeople of several countries in the Asian Pacific Region, as the beginning milestone of our large-scale deployment in the Asian Region. Unfortunately, as Emerson Network Power is an MNC, it takes time to expand it into a large scale deployment, and the team will not be able to witness it.
2. Adapting to Technical Challenges
Throughout the project, we have suggested improvements to our current existing scope, and Emerson Network Power has given us the opportunity to develop them to value-add to the current project. These changes have been incorporated into our mobile application ESET, such as the Sales Memo and the Web Portal Analytics.
We have came up with technical work-arounds to tackle the problems that we face in the Project:
2.1 File Storage
Making the storage and transfer of large files (typically pdfs) efficient. Our original implementation involved the storage of images as BLOB objects in the MySQL database, leading to errors during upload and downloading of images.
The transfer of images via JSON also caused a huge overhead as it uses Base64 encoding (which increases the length of strings by ~37%), leading to the transaction size to hit above the limit, which lead to failures in data transmission.
Therefore, we came up with the solution of storing these files in the FTP server instead, and the android device downloads directly from the FTP server. Apart from that, instead of sending long Base64 strings, file paths are sent over via JSON and the android device downloads the files that we stored in the FTP server directly.
2.2 ListView VS RecyclerView
Before that, using ListView, we loaded each row, and they will run the code once using the inflate method. This means that new views are always inflated, and it was inefficient in terms of phone memory usage.
We decided to use RecycleView as compared to ListView, it recycles the existing views. This helps to saves CPU resources in that you do not have to inflate new views all the time and it saves memory in that it doesn’t keep plenty of invisible views around.
So, to conclude RecycleView is more flexible in handling "list data" and implementing more complex displays, like a list/grid/hybrid, with animations, and allows for a more dynamic presentation in our application's user interface.
DYMSZ Project Management
We have came up with a Change Management Metrics to measure the magnitude of changes by our sponsors, and gauge the actual amount of additional scope and effort we need to put in, and understand whether it is feasible to continue to do so. Thus far, we have been successful in discussing and reviewing changes in scope from our Sponsors for many Iterations, and have still been able to keep to our original schedule.
Project Schedule (Plan Vs Actual)
Interation | Module | Functionality | Iterations | Planned | Actual | Comments |
2 & 3 | Server Management Module (KVM and Secure KVM) |
Filter Products | Fully implemented and Deployed. User Tested in UT1 & UT2 |
02/11/14 | 02/11/14 | Completed as per schedule |
Compare Products | Fully implemented and Deployed. User Tested in UT1 & UT2 |
02/11/14 | 02/11/14 | Completed as per schedule | ||
Setup Database Schema | Fully implemented and Deployed. User Tested in UT1 & UT2 |
02/11/14 | 02/11/14 | Completed as per schedule | ||
4 | Power management Module (Rack PDU) | Filter Products | Fully implemented and Deployed. User Tested in UT1 & UT2 |
19/12/14 | 19/12/14 | Completed as per schedule |
Compare Products | Fully implemented and Deployed. User Tested in UT1 & UT2 |
19/12/14/font> | 19/12/14 | Completed as per schedule | ||
Setup Database Schema | Fully implemented and Deployed. User Tested in UT1 & UT2 |
19/12/14 | 19/12/14 | Completed as per schedule | ||
5 | Optimization Module ( Android Application ) |
Changing from Android Activity to Android Fragment | Fully implemented and Deployed. User Tested in UT1 & UT2 |
02/01/15 | 02/01/15 | Completed as per schedule |
6 | Web Portal Module | User Login/Logout Functionality | Fully implemented and Deployed. User Tested in UT1 & UT2 |
16/01/15 | 16/01/15 | Completed as per schedule |
User Reset Password Functionality | Fully implemented and Deployed. User Tested in UT1 & UT2 |
16/01/15 | 16/01/15 | Completed as per schedule | ||
Products CRUD Functionality | Fully implemented and Deployed. User Tested in UT1 & UT2 |
16/01/15 | 16/01/15 | Completed as per schedule | ||
Update Videos | Fully implemented and Deployed. User Tested in UT1 & UT2 |
16/01/15 | 16/01/15 | Completed as per schedule | ||
Update Tutorials | Fully implemented and Deployed. User Tested in UT1 & UT2 |
16/01/15 | 16/01/15 | Completed as per schedule | ||
Update Case Studies | Fully implemented and Deployed. User Tested in UT1 & UT2 |
16/01/15 | 16/01/15 | Completed as per schedule | ||
7 | Tutorial Module | Uploading Tutorials Functionality | Fully implemented and Deployed. User Tested in UT1 & UT2 |
30/01/15 | 30/01/15 | Completed as per schedule |
Displaying of Videos and Documents | Fully implemented and Deployed. User Tested in UT1 & UT2 |
30/01/15 | 30/01/15 | Completed as per schedule | ||
8 | Sales Memo Module | Store Products Sales Input | Fully implemented and Deployed. User Tested in UT1 & UT2 |
13/02/15 | 13/02/15 | Completed as per schedule |
Descriptive Analytics Module | Web Service to Push Data to Portal | Fully implemented and Deployed. User Tested in UT1 & UT2 |
13/02/15 | 13/02/15 | Completed as per schedule | |
Dashboard that Converts Data to Charts | Fully implemented and Deployed. User Tested in UT1 & UT2 |
13/02/15 | 13/02/15 | Completed as per schedule | ||
9 | Predictive Analytics Module | Web Service to Push Data to Portal | Fully implemented and Deployed. User Tested in UAT3 |
27/02/15 | 01/03/15 | Delayed 2 days due to bugs |
Dashboard that Converts Data to Charts | Fully implemented and Deployed. User Tested in UAT3 |
27/02/15 | 01/03/15 | Delayed 2 days due to bugs | ||
10 | DCIM Software Module | Search for licenses | Fully implemented and Deployed. User Tested in UAT3 |
15/03/15 | 15/03/15 | Completed as per schedule |
Search for System Add-ons | Fully implemented and Deployed. User Tested in UAT3 |
15/03/15 | 15/03/15 | Completed as per schedule | ||
Optimization Module 2 | Adding features to Analytics Module | Fully implemented and Deployed. User Tested in UAT3 |
15/03/15 | 15/03/15 | Completed as per schedule | |
Improving Application Design with midterm Feedback | Improved and Deployed. User Tested in UAT3 |
15/03/15 | 15/03/15 | Completed as per schedule | ||
11 | Optimization Module 3 | Created Revenue Analytics with product List Price | Fully implemented and Deployed. User Tested in UAT3 |
29/03/15 | 29/03/15 | Completed as per schedule |
Improving App Design | Fully implemented and Deployed. User Tested in UAT3 |
29/03/15 | 29/03/15 | Completed as per schedule | ||
Handover Module | System for all Use Cases | Fully implemented and Deployed. User Tested in UAT3 |
29/03/15 | 29/03/15 | Completed as per schedule | |
Enhance User Interfaces for Android based on UAT Feedback | Improved and Deployed. User Tested in UAT3 |
29/03/15 | 29/03/15 | Completed as per schedule | ||
Handover Documents for android and web portal | Improved and Deployed. User Tested in UAT3 |
29/03/15 | 29/03/15 | Completed as per schedule |
Project Metrics
Project Metrics:
View our Schedule Metrics
HERE!
View our Bug Metrics
HERE!
View our Change Management Metrics
HERE!
Project Risks:
View our Project Risks
HERE!
Change Management:
View our Change Management Metrics
HERE!
Technical Complexity
Problem 1:
Display of large list of items is inefficient and consumes a lot of memory Solution: Having an efficient display of the products through an Implementation of RecyclerView with Viewholder design pattern for element, to minimise memory consumption and efficient scrolling of items to replace listview. Reasons for implementation: For every single row creation, we have to create the xml file that has the layout of the row and inflate it in code. However, layout inflation for every row is memory intensive. Apart from that, the application has to find row elements such as Text and Image with a findViewById method and populate the elements which is even more memory intensive. RecyclerView is the appropriate view to use when you have multiple items of the same type and it’s very likely that the device cannot present all of those items at once. The user has to scroll up and down to see more items and that’s when the recycling and reuse comes into play. As soon as a user scrolls a currently visible item out of view, this item’s view can be recycled and reused whenever a new item comes into view. This saves CPU resources, as you do not have to inflate new views all the time. It saves memory in that it doesn’t keep plenty of invisible views around. However, the RecyclerView does not animate views. It also does not handle any touch events apart from scrolling. Therefore, we need to implement a gesture detector that utilises a gesture listener to listen out for a motion event to find out the x and y coordinates that is clicked to find out the exact row which is clicked on the recycler view. Benefits / Outcome: Product list loads faster No lag user experience when user is scrolling the list Application does not crash after long periods of scrolling
Problem 2:
Intensive operations are managed by a single UI thread Solution: Usage of asynchronous task to do processing of intensive operations on a separate thread Reasons for implementation: As the main UI thread is only supposed to be in charge of rendering the UI elements in the android application, executing intensive operations on the main UI thread cause frames to be skipped, which can cause the thread to stop for a while. From the user’s point of view, he will either experience a black screen and is unable to interact with the application under the processing has ended which is a very undesirable user experience. There are 3 parts to it. Firstly, in onPreExecute, we need to tell the user to wait for the processing to be done and this provides update to system status as compared to previous implementation. Next, we will do all the processing in the doInBackground which runs on a separate. Lastly, the post execute method informs the user that the processing has ended. Benefits / Outcome: User is aware that he has to wait for background processes and not have to figure out why he cannot interact with the application temporality or think that the application has crashed. Efficient handling of intensive operations which reduces time taken for it to complete as it no longer has to operate on the main UI thread which competes from resources that renders the user interface.
DYMSZ Quality of Product
Project Deliverables
Stage | Specification | Links |
Project Management | Meeting Minutes | Meeting Minutes |
Schedule Metrics | Schedule Metrics | |
Bug Metrics | Bug Metrics | |
Requirements | Motivation Video | Description |
Analysis | Use Case | Use Case |
Architecture Diagram | System Architecture Overview | |
Process Flow | To-Be | |
Design | UI Prototype | Prototype |
Testing | User test plan | Testing |
Design | Deployment Diagram | Deployment Diagram |
Quality
TECHNICAL QUALITY
Maintainability
- We reused the same fragment class for multiple views. Initially, the design of the application required us to create a new fragment class whenever there was a new page of the same design. That was very intensive as we had to maintain a large set of classes and make changes over multiple files. To prevent the increasing amount of files created and duplication of codes, we decided to just create a fragment class and instantiate multiple instances of the same class to replicate similar views and this reduces the amount of files created significantly.
Usability
- Adopting swipe-based navigation. As our product was organised in categories, the user had to click into a category to view the content and go back to the list of categories before he could select another category to view. By implementing swipe-based navigation, the user can now enjoy seamless viewing of multiple content pages without having to navigate to and fro between pages. It also provided the user with a directional feel when swiping left and right of the screen.
- Input filter criteria through a dialog to allow the user to filter and view the results while staying on the same page. Our initial design was creating a page of filter criteria for the user to key in the view the related results. However, whenever the user wanted to reselect the criteria he had to navigate to the criteria page to do the selection. By implementing a pop-up dialog, the user does not need to navigate to a separate filter page again, as he is able to input filter criteria and view the results on the same page.
Flexibility
- Passing information between app screens. Historically, each screen in an Android app was implemented as a separate Activity. This creates a challenge in passing information between screens because the Android Intent mechanism does not allow passing a reference type (i.e. object) directly between Activities. Instead the object must be serialized or a globally accessible reference made available. By making each screen a separate Fragment, we are able to solve the data passing redundancy problem. Fragments always exist within the context of a given Activity and can always access that Activity. By storing the information of interest within the Activity, the Fragment for each screen can simply access the object reference through the Activity.
Type | Information |
Web Application |
ESET (Emerson Sales Enablement Tool) Admin Portal |
Database |
MySQL |
Server |
Digital Ocean (Emerson Network Power Account) |
Deployed Link |
http://128.199.182.247:8080/Emerson/ |
Deployment
Testing
User Test | Date of User Test | Objectives | No of Participants | Link |
Usability Test 1(Macro) |
08/01/2015 - 09/01/2015 |
|
25 | User Test 1 |
Usability Test 2 (Focus Group Study) |
12/02/2015 - 13/02/2015 |
|
5 | User Test 2 |
User Acceptance Test 1 (Focus Group Study) |
12/03/2015 - 13/03/2015 |
|
5 | User Acceptance Test 1 |
DYMSZ Reflection
Team Reflection
- Learn new technologies
- Learn to work together in a group
- Learn how we can increase value to a client
- Learn proper Change Management to be flexible to changes in our scope from the client
Individual Reflection
Darren
- Learn to work together in a group
- Learn new technologies
- Learn how we can increase value to a client
- Time Management between FYP and other commitments
- Learn proper Change Management to be flexible to changes in our scope from the client
You Shuang
- Learn how to develop android application
- Learning to connect the android application to an online database
- Learning to integrate Android application and web services
- Convert business requirements to technical diagrams
May
- Learn how to update the wiki
- Learn to create realistic test cases to test quality of application
- Learn to schedule while taking into account difficulty of module
- Learn to understand client’s and team members' expectations
Shyan Ann
- Learn and attain proficiency in native Android development
- Learn and apply industry best Android UI/UX design principles for user- friendly interfaces
- Learn to integrate frontend and backend Android logic
- Learn to manage client expectations and deliver based on technical competencies
Zi Hua
- Learn software development cycle of developing an android application
- Learn best practices in android development for front and back end development
- Learn how to design the architecture of an android application
- Learn to liaise effectively with PM ensuring development & iteration schedule is in sync