WS
W.J. Siemers
info
Please Note
<p>This page displays the records of the person named above and is not linked to a unique person identifier. This record may need to be merged to a profile.</p>
2 records found
1
Poor battery life is one of smartphone users’ top frustrations about their devices. This fact, in combination with the limited supply of battery minerals, the working conditions of mining, and its environmental impact, has led to high interest in reducing smartphone energy consumption. Smartphone manufacturers have introduced power-saving features on their products and guide developers to use energy- efficient software engineering practices.
In literature, the increased awareness of the need to reduce energy consumption and reduce emissions has led to the birth of a Green Software research field. Focusing on mobile software, prior research has focused on quantifying energy use and finding instances of software using more energy than is reasonable for its intended purpose. However, the ubiquitous power-saving features of smartphones have hardly been studied until now. In particular, bugs stemming from Android’s Battery Saver mode, a power-saving technology introduced in 2017 by Google, have not been studied at all. This thesis aims to address this research gap.
To do so, we first characterize these issues by systematically collecting documentation pages, bug reports, and forum questions relating to these bugs. We find 13 separate problems, most of which (9 out of 13) have considerable user impact. Additionally, most problems are reported multiple times independently (mean re- porting frequency = 4.1) outside of Google documentation. Four of the problems have never been officially documented.
Driven by this characterization, we build a static analysis tool that detects one of the characterized issues. It builds a Conditional Call Graph to find invocations of the implicated Application Programming Interfaces (APIs) without asserting this API is available. The tool is fast and does not require source code to be available. It runs on the Java Virtual Machine for portability.
To evaluate the tool, we use a two-pronged approach. We first determine the ground truth for all 1,472 Google Play Store applications that are also available in the FDroid repository. We write a script to identify all suspicious API invocations, the bug candidates. We find and attempt to reproduce 178 of these bug candidates. We manually review all candidates to determine the ground truth. We evaluate our tool using the same data set. The tool reaches a precision of 0.911 and a recall of 0.911 and identifies 41 reproducible issues.
Lastly, we report the reproduced issues identified by the tool to the developers of the affected applications. To date, nine issues have been confirmed by the developers, and two issues have already been addressed. ...
In literature, the increased awareness of the need to reduce energy consumption and reduce emissions has led to the birth of a Green Software research field. Focusing on mobile software, prior research has focused on quantifying energy use and finding instances of software using more energy than is reasonable for its intended purpose. However, the ubiquitous power-saving features of smartphones have hardly been studied until now. In particular, bugs stemming from Android’s Battery Saver mode, a power-saving technology introduced in 2017 by Google, have not been studied at all. This thesis aims to address this research gap.
To do so, we first characterize these issues by systematically collecting documentation pages, bug reports, and forum questions relating to these bugs. We find 13 separate problems, most of which (9 out of 13) have considerable user impact. Additionally, most problems are reported multiple times independently (mean re- porting frequency = 4.1) outside of Google documentation. Four of the problems have never been officially documented.
Driven by this characterization, we build a static analysis tool that detects one of the characterized issues. It builds a Conditional Call Graph to find invocations of the implicated Application Programming Interfaces (APIs) without asserting this API is available. The tool is fast and does not require source code to be available. It runs on the Java Virtual Machine for portability.
To evaluate the tool, we use a two-pronged approach. We first determine the ground truth for all 1,472 Google Play Store applications that are also available in the FDroid repository. We write a script to identify all suspicious API invocations, the bug candidates. We find and attempt to reproduce 178 of these bug candidates. We manually review all candidates to determine the ground truth. We evaluate our tool using the same data set. The tool reaches a precision of 0.911 and a recall of 0.911 and identifies 41 reproducible issues.
Lastly, we report the reproduced issues identified by the tool to the developers of the affected applications. To date, nine issues have been confirmed by the developers, and two issues have already been addressed. ...
Poor battery life is one of smartphone users’ top frustrations about their devices. This fact, in combination with the limited supply of battery minerals, the working conditions of mining, and its environmental impact, has led to high interest in reducing smartphone energy consumption. Smartphone manufacturers have introduced power-saving features on their products and guide developers to use energy- efficient software engineering practices.
In literature, the increased awareness of the need to reduce energy consumption and reduce emissions has led to the birth of a Green Software research field. Focusing on mobile software, prior research has focused on quantifying energy use and finding instances of software using more energy than is reasonable for its intended purpose. However, the ubiquitous power-saving features of smartphones have hardly been studied until now. In particular, bugs stemming from Android’s Battery Saver mode, a power-saving technology introduced in 2017 by Google, have not been studied at all. This thesis aims to address this research gap.
To do so, we first characterize these issues by systematically collecting documentation pages, bug reports, and forum questions relating to these bugs. We find 13 separate problems, most of which (9 out of 13) have considerable user impact. Additionally, most problems are reported multiple times independently (mean re- porting frequency = 4.1) outside of Google documentation. Four of the problems have never been officially documented.
Driven by this characterization, we build a static analysis tool that detects one of the characterized issues. It builds a Conditional Call Graph to find invocations of the implicated Application Programming Interfaces (APIs) without asserting this API is available. The tool is fast and does not require source code to be available. It runs on the Java Virtual Machine for portability.
To evaluate the tool, we use a two-pronged approach. We first determine the ground truth for all 1,472 Google Play Store applications that are also available in the FDroid repository. We write a script to identify all suspicious API invocations, the bug candidates. We find and attempt to reproduce 178 of these bug candidates. We manually review all candidates to determine the ground truth. We evaluate our tool using the same data set. The tool reaches a precision of 0.911 and a recall of 0.911 and identifies 41 reproducible issues.
Lastly, we report the reproduced issues identified by the tool to the developers of the affected applications. To date, nine issues have been confirmed by the developers, and two issues have already been addressed.
In literature, the increased awareness of the need to reduce energy consumption and reduce emissions has led to the birth of a Green Software research field. Focusing on mobile software, prior research has focused on quantifying energy use and finding instances of software using more energy than is reasonable for its intended purpose. However, the ubiquitous power-saving features of smartphones have hardly been studied until now. In particular, bugs stemming from Android’s Battery Saver mode, a power-saving technology introduced in 2017 by Google, have not been studied at all. This thesis aims to address this research gap.
To do so, we first characterize these issues by systematically collecting documentation pages, bug reports, and forum questions relating to these bugs. We find 13 separate problems, most of which (9 out of 13) have considerable user impact. Additionally, most problems are reported multiple times independently (mean re- porting frequency = 4.1) outside of Google documentation. Four of the problems have never been officially documented.
Driven by this characterization, we build a static analysis tool that detects one of the characterized issues. It builds a Conditional Call Graph to find invocations of the implicated Application Programming Interfaces (APIs) without asserting this API is available. The tool is fast and does not require source code to be available. It runs on the Java Virtual Machine for portability.
To evaluate the tool, we use a two-pronged approach. We first determine the ground truth for all 1,472 Google Play Store applications that are also available in the FDroid repository. We write a script to identify all suspicious API invocations, the bug candidates. We find and attempt to reproduce 178 of these bug candidates. We manually review all candidates to determine the ground truth. We evaluate our tool using the same data set. The tool reaches a precision of 0.911 and a recall of 0.911 and identifies 41 reproducible issues.
Lastly, we report the reproduced issues identified by the tool to the developers of the affected applications. To date, nine issues have been confirmed by the developers, and two issues have already been addressed.
Customer maturity analysis improvement for TOPdesk
Final report
Bachelor thesis
(2021)
-
Krzysztof Baran, Cees Jol, Rover van der Noort, Wander Siemers, F. Mulder, H. Wang, J.-F. Humann, C. Stratan
TOPdesk is a service management software provider in a wide variety of domains and industries. TOPdesk also offers consultancy to their customers that aims to continuously assess and improve the customer’s experience and service efficiency. TOPdesk offers a Mini Health Check (MHC) to their customers in which aconsultant analyzes how efficiently the customer uses their software based on six Key Performance Indicators (KPI). However, the process of creating an MHC report is very time-consuming as it requires performing a lot of manual steps. Also, the norms used for the KPIs provide little meaning as they are arbitrarily chosen and not specific to the customer’s industry. This report aims to improve the current process of performing an MHC. Research has been done on how the MHC is performed, identifying the suitable technologies and learning the currently existing infrastructure that helped us pave the way to create our product. During our project we managed to create a product that automates the MHC. Through user testing we found that this process now takes about two minutes, where the manual process took about two hours. To create more meaningful norms for the KPIs, we also implemented a benchmarking feature. This allows a company to compare the results of their MHC to other TOPdesk customers in the same sector, country or of similar size. We have some recommendations for TOPdesk for the further development of our product. The MHC process could be streamlined in a few ways, most importantly with respect to the process for getting access to customer data. Benchmarking could become even more useful if data can be more easily gathered from more TOPdesk customers.
...
TOPdesk is a service management software provider in a wide variety of domains and industries. TOPdesk also offers consultancy to their customers that aims to continuously assess and improve the customer’s experience and service efficiency. TOPdesk offers a Mini Health Check (MHC) to their customers in which aconsultant analyzes how efficiently the customer uses their software based on six Key Performance Indicators (KPI). However, the process of creating an MHC report is very time-consuming as it requires performing a lot of manual steps. Also, the norms used for the KPIs provide little meaning as they are arbitrarily chosen and not specific to the customer’s industry. This report aims to improve the current process of performing an MHC. Research has been done on how the MHC is performed, identifying the suitable technologies and learning the currently existing infrastructure that helped us pave the way to create our product. During our project we managed to create a product that automates the MHC. Through user testing we found that this process now takes about two minutes, where the manual process took about two hours. To create more meaningful norms for the KPIs, we also implemented a benchmarking feature. This allows a company to compare the results of their MHC to other TOPdesk customers in the same sector, country or of similar size. We have some recommendations for TOPdesk for the further development of our product. The MHC process could be streamlined in a few ways, most importantly with respect to the process for getting access to customer data. Benchmarking could become even more useful if data can be more easily gathered from more TOPdesk customers.