Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
24
datasets available to search
ShareScore release 0.9.0
Dataset results
24 results for “Software understandability”
The Role of Informal Communication in Building Shared Understanding of Non-Functional Requirements in Remote Continuous Software Engineering
<p><strong>Study Information</strong></p> <p>We conducted an ethnography-informed case study of a remote software organization that adopts CSE practices to explore how the organization builds a shared understanding of NFRs. Our study uses semi-structured interviews with a period of observations to answer the following research questions:</p> <p> </p> <ol> <li> <p>How does a remote software organization that adopts CSE practices reach a shared understanding of NFRs?</p> </li> <li> <p>What are the limitations to the shared understanding of NFRs in a remote software organization that adopts CSE practices?</p> </li> <li> <p>What organizational practices for remote collaboration supported a shared understanding of NFRs?</p> </li> </ol> <p> </p> <p>In our study, we refer to our partner organization as Alpha. We used ethnography-informed methods to study Alpha's practices and processes and how they approach a shared understanding of NFRs in their product development. </p> <p> </p> <p><strong>Data Analysis</strong></p> <p>We performed a qualitative study through semi-structured interviews and observations. We use the open, axial and selective coding approach from grounded theory [1] to create our codebook, which informed the results and discussion of our study. Two independent coders held agreement sessions to discuss the codes, consolidate the codes and calculate the inter-rater reliability using the Cohen Kappa's coefficient for measuring observer agreement for categorical data [2]. </p> <p> </p> <p><strong>Artifact Descriptions</strong></p> <p>Our replication package contains three artifacts:</p> <p>1. Codebook.csv: The codebook contains rows for the list of codes used, including the code name and the description of the codes. The codes are the final set of themes derived during the thematic analysis of the interview responses. For example, 'Gaps in communication' means when interview participants describe miscommunications due to team members making assumptions about a project/process or having unclear expectations for a project.</p> <p>2. kappa-scores.csv: This contains the associated kappa values for each round of inter-rater agreement sessions. For each agreement session, the Cohen Kappa's coefficient was calculated from the number of agreements and disagreements of codes within one or two interview transcripts. The Kappa values represent the level of agreement ranging from 0 to 1, where > 0.6 represents substantial agreement. </p> <p>3. Interview-questions.csv: This contains the interview questions used in the semi-structured interviews. Some of the interview questions varied depending on the interviewee’s role, experience and the flow of the interviews.</p> <p><strong> </strong></p> <p><strong>Usefulness</strong></p> <p>We recognize that the value and usefulness of our replication package are yet-to-be-determined. In the interest of transparency of open science, we published our artifacts. We hope that these artifacts are useful to either replicate our findings or to further analyze them to produce other enlightening results.</p> <p><strong> </strong></p> <p><strong>References</strong></p> <p>1. Rashina Hoda, James Noble, and Stuart Marshall. "Grounded theory for geeks". In: Proceedings of the 18th conference on pattern languages of programs. 2011, pp. 1–17.</p> <p>2. J Richard Landis and Gary G Koch. "The measurement of observer agreement for categorical data". In: biometrics (1977), pp. 159–174.</p> <p><strong> </strong></p> <p> </p>
On the Understandability of Semantic Constraints for Behavioral Software Architecture Compliance: A Controlled Experiment
<p>Software architecture compliance is concerned with the alignment of implementation with its desired architecture and detecting potential inconsistencies. The study is specifically concerned with behavioral architecture compliance. That is, the focus is on semantic alignment of implementation and architecture. In particular, the study evaluates three representative approaches for describing semantic constraints in terms of their understandability, namely natural language descriptions as used in many architecture documentations today, a structured language based on specification patterns that abstract underlying temporal logic formulas, and a structured cause-effect language that is based on Complex Event Processing. We conducted a controlled experiment with 190 participants using a simple randomized design with one alternative per experimental unit.</p>
Dataset - Understanding the software and data used in the social sciences
<p>This is a repository for a UKRI Economic and Social Research Council (ESRC) funded project to understand the software used to analyse social sciences data.</p><p>Any software produced has been made available under a BSD 2-Clause license and any data and other non-software derivative is made available under a CC-BY 4.0 International License. Note that the software that analysed the survey is provided for illustrative purposes - it will not work on the decoupled anonymised data set.</p><p>Exceptions to this are:</p><ul><li>Data from the UKRI ESRC is mostly made available under a <a href="https://creativecommons.org/licenses/by-nc-sa/4.0/">CC BY-NC-SA 4.0</a> Licence.</li><li>Data from Gateway to Research is made available under an <a href="https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/">Open Government Licence</a> (Version 3.0).</li></ul><h2>Contents</h2><ul><li>Survey data & analysis: esrc_data-survey-analysis-data.zip</li><li>Other data: esrc_data-other-data.zip</li><li>Transcripts: esrc_data-transcripts.zip</li><li>Data Management Plan: esrc_data-dmp.zip</li></ul><h3>Survey data & analysis</h3><p>The survey ran from 3rd February 2022 to 6th March 2023 during which 168 responses were received. Of these responses, three were removed because they were supplied by people from outside the UK without a clear indication of involvement with the UK or associated infrastructure. A fourth response was removed as both came from the same person which leaves us with 164 responses in the data.</p><p>The survey responses, Question (Q) Q1-Q16, have been decoupled from the demographic data, Q17-Q23. Questions Q24-Q28 are for follow-up and have been removed from the data. The institutions (Q17) and funding sources (Q18) have been provided in a separate file as this could be used to identify respondents. Q17, Q18 and Q19-Q23 have all been independently shuffled.</p><p>The data has been made available as Comma Separated Values (CSV) with the question number as the header of each column and the encoded responses in the column below. To see what the question and the responses correspond to you will have to consult the survey-results-key.csv which decodes the question and responses accordingly. </p><p><strong>A pdf copy of the survey questions is </strong><a href="https://github.com/softwaresaved/esrc-software-study/blob/main/Docs/esrc-survey.pdf"><strong>available</strong></a><strong> on GitHub.</strong></p><p>The survey data has been decoupled into:</p><ul><li>survey-results-key.csv - maps a question number and the responses to the actual question values.</li><li>q1-16-survey-results.csv- the non-demographic component of the survey responses (Q1-Q16).</li><li>q19-23-demographics.csv - the demographic part of the survey (Q19-Q21, Q23).</li><li>q17-institutions.csv - the institution/location of the respondent (Q17).</li><li>q18-funding.csv - funding sources within the last 5 years (Q18).</li></ul><p>Please note the code that has been used to do the analysis will not run with the decoupled survey data. </p><h3>Other data files included</h3><ul><li>CleanedLocations.csv - normalised version of the institutions that the survey respondents volunteered.</li><li>DTPs.csv - information on the UKRI Doctoral Training Partnerships (DTPs) scaped from the UKRI <a href="https://esrc.ukri.org/skills-and-careers/doctoral-training/doctoral-training-partnerships/doctoral-training-partnership-dtp-contacts/">DTP contacts</a> web page in October 2021.</li><li>projectsearch-1646403729132.csv.gz - data snapshot from the <a href="https://gtr.ukri.org/">UKRI Gateway to Research</a> released on the 24th February 2022 made available under an <a href="https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/">Open Government Licence</a>.</li><li>locations.csv - latitude and longitude for the institutions in the cleaned locations.</li><li>subjects.csv - research classifications for the ESRC projects for the 24th February data snapshot.</li><li>topics.csv - topic classification for the ESRC projects for the 24th February data snapshot.</li></ul><h3>Interview transcripts</h3><p>The interview transcripts have been anonymised and converted to markdown so that it's easier to process in general. List of interview transcripts:</p><ul><li>1269794877.md</li><li>1578450175.md</li><li>1792505583.md</li><li>2964377624.md</li><li>3270614512.md</li><li>40983347262.md</li><li>4288358080.md</li><li>4561769548.md</li><li>4938919540.md</li><li>5037840428.md</li><li>5766299900.md</li><li>5996360861.md</li><li>6422621713.md</li><li>6776362537.md</li><li>7183719943.md</li><li>7227322280.md</li><li>7336263536.md</li><li>75909371872.md</li><li>7869268779.md</li><li>8031500357.md</li><li>9253010492.md</li></ul><h3>Data Management Plan</h3><p>The study's Data Management Plan is provided in PDF format and shows the different data sets used throughout the duration of the study and where they have been deposited, as well as how long the SSI will keep these records. </p>
Understanding the Building Blocks of Accountability in Software Engineering
<p>In the social and organizational sciences, accountability has been linked to the efficient operation of organizations. However, it has received limited attention in software engineering (SE) research, in spite of its central role in the most popular software development methods (i.e., Scrum). In this article, we seek to explore the mechanisms of accountability in SE environments and investigate the factors that foster software engineers' individual accountability within their teams through an interview study with 12 people. Our findings recognize two primary forms of accountability shaping software engineers individual senses of accountability: \emph{institutionalized} and \emph{grassroots}. While the former is directed by formal processes and mechanisms, like performance reviews, grassroots accountability arises organically within teams, driven by factors such as peers' expectations and intrinsic motivation. This organic form cultivates a shared sense of collective responsibility, emanating from shared team standards and individual engineers' inner commitment to their personal, professional values, and self-set standards. While institutionalized accountability relies on traditional "carrot and stick" approaches, such as financial incentives or denial of promotions, grassroots accountability operates on reciprocity with peers and intrinsic motivations, like maintaining one's reputation in the team.</p>
Dataset and Analysis Scripts for Survey "Understanding Security Tactics in Microservice APIs using Annotated Software Architecture Decomposition Models -- A Controlled Experiment"
<pre>Dataset, R-Scripts and questionnaire templates for our survey <em>Understanding Security Tactics in Microservice APIs using Annotated Software Architecture Decomposition Models -- A Controlled Experiment.</em></pre>
Dataset: We Do Not Understand What It Says -- Studying Student Perceptions of Software Modelling
<p>The dataset contains two supporting documents for the paper title, "We Do Not Understand What It Says -- Studying Student Perceptions of Software Modelling". The first one is an excel sheet containing interview transcripts of 13 of the participants of this study (who agreed to publish their statements) and the second is an appendix file containing the interview guide (questionnaire used for interviews with students and instructors) used in the case study. </p> <p>The interview transcripts are supported by "in-vivo coding" used by both authors separately during analysis. </p>
ICITS'23 - Understanding the Success Factors of Research Software: Interviews with Brazilian Computer Science Academic Researchers
<p>Artifacts used for data collection and analysis of the article accepted for publication in ICITS'23.</p> <p>Mourão, E., Trevisan, D., Viterbo, J. (2022).Understanding the Success Factors of Research Software: Interviews with Brazilian Computer Science Academic Researchers. In: ICITS'23 - 6th International Conference on Information Technology & Systems. Advances in Intelligent Systems and Computing, Springer, Cham.</p>
Understanding Software in Research: Examining Nature Articles
<p>The dataset contains a review of 40 <em>Nature </em>articles, consisting of an assessment of all of the research articles from January, February, and March of 2016. The articles were scored and metrics were collected on each individual and distinct mention of software in the articles. The mentions were characterized on how they were cited. Values pertaining to the overall collection of articles were also calculated. </p>
Towards Understanding the Impact of Code Modifications on Software Quality Metrics
<p>The provided dataset contains the data used by "Towards Understanding the Impact of Code Modifications on Software Quality Metrics", in order to examine the impact of code changes in software quality metrics and identify types of code changes with similar impact and the results obtained.</p>
Replication Package for the Paper: Understanding Software Architecture Erosion: A Systematic Mapping Study
<p>This is the replication package for the paper: "Understanding Software Architecture Erosion: A Systematic Mapping Study". It contains five files as described below:</p> <p><strong>1. List of the Selected Studies_SMS.xlsx</strong><br> includes the detailed information of the 73 selected studies.</p> <p><strong>2. Data Extraction.xlsx</strong><br> includes the extracted data based on the data items (i.e., D1-D16).</p> <p><strong>3. Sample of Study Selection.xlsx</strong><br> includes the 100 randomly selected papers from the search results and the results of each round selection.</p> <p><strong>4. Pilot Data Extraction.xlsx</strong><br> includes the pilot data extraction results from five papers.</p> <p><strong>5. Sample of Data Extraction.xlsx</strong><br> includes the data extraction results from another randomly selected five papers.</p>
Artifacts of Paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems"
<p>This package contains all the artifacts (i.e. codes & datasets) we use in our paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems" accepted to FSE 2020.</p>
Understanding the Energy Consumption of Cloud-native Software Systems
<p>These artifacts contain the dataset generated in the paper "Understanding the Energy Consumption of Cloud-native Software Systems". The dataset contains resource utilisation, power consumption, estimated power consumption and load metrics for a cloud-native software system. The test setup is consists of 6 machines running an OpenStack cluster. This OpenStack cluster is running 12 virtual machines that are in turn hosting a Kubernetes cluster. Performance and (estimated) power consumption are measured on all levels of the system.</p> <p>The Bare-Metal (BM) and Virtual Machines (VM) are identified by their IP addresses. For BM the IP mapping is as follows:</p> <ul> <li>192.168.1.109 - i3-04</li> <li>192.168.1.110 - i3-02</li> <li>192.168.1.111 - i5-02</li> <li>192.168.1.112 - i3-01</li> <li>192.168.1.113 - i5-01</li> <li>192.168.1.114 - i5-04</li> </ul> <p>For VM the IP mapping is:</p> <ul> <li>192.168.1.190 - kubernetes-agent-7</li> <li>192.168.1.191 - kubernetes-agent-6</li> <li>192.168.1.192 - kubernetes-agent-10</li> <li>192.168.1.194 - kubernetes-master</li> <li>192.168.1.196 - kubernetes-agent-3</li> <li>192.168.1.197 - kubernetes-agent-1</li> <li>192.168.1.198 - kubernetes-agent-2</li> <li>192.168.1.201 - kubernetes-agent-4</li> <li>192.168.1.203 - kubernetes-agent-9</li> <li>192.168.1.204 - kubernetes-agent-5</li> <li>192.168.1.207 - kubernetes-agent-8</li> <li>192.168.1.209 - kubernetes-agent-11</li> </ul> <p>The VMs are deployed on the BMs as follows:</p> <ul> <li>i3-01 <ul> <li>kubernetes-agent-2</li> <li>kubernetes-agent-8</li> </ul> </li> <li>i3-02 <ul> <li>kubernetes-agent-1</li> <li>kubernetes-agent-6</li> </ul> </li> <li>i3-04 <ul> <li>kubernetes-agent-10</li> <li>kubernetes-agent-11</li> </ul> </li> <li>i5-01 <ul> <li>kubernetes-agent-3</li> <li>kubernetes-agent-5</li> </ul> </li> <li>i5-02 <ul> <li>kubernetes-master</li> <li>kubernetes-agent-7</li> </ul> </li> <li>i5-04 <ul> <li>kubernetes-agent-4</li> <li>kubernetes-agent-9</li> </ul> </li> </ul> <p>Note that the following BMs are excluded from the experiments as they have other roles in the cluster and do not run workloads:</p> <ul> <li>i3-03 (Juju - deploying OpenStack on BM nodes)</li> <li>i3-05 (ProxMox - external observability tools that do not run in the cluster)</li> <li>i5-03 (MAAS - provisioning of BM nodes)</li> </ul> <h1>Data Sets</h1> <p>The artifacts consists of 3 separate data sets: <code>constant</code>, <code>direct</code> and <code>linear</code>, corresponding to the respective load profile applied to the SUT as discussed in the paper. Each data set contains the same metrics, but the system is put under a different load.</p> <p>Every experiment is repeated 3 times. All 3 repetitions are included in the data set. The data is collected using Prometheus and stored in JSON files.</p> <p>For the <code>constant</code> and <code>linear</code> data sets, load is applied by deploying the "OpenTelemetry demo application", and sending automated user requests to the application. For the <code>direct</code> dataset, this application is not used and instead Kubernetes pods are created that apply a constant load to the cluster.</p> <p>The timestamps of the experiments are as follows:</p> <table> <tbody> <tr> <th>Run</th> <th>Iteration</th> <th>Start</th> <th>End</th> </tr> </tbody> <tbody> <tr> <td>Constant - 0 users</td> <td>1</td> <td>02-05-2024 10:08</td> <td>02-05-2024 10:52</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 13:20</td> <td>06-05-2024 13:58</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 09:20</td> <td>07-05-2024 09:54</td> </tr> <tr> <td>Constant - 50 users</td> <td>1</td> <td>02-05-2024 13:26</td> <td>02-05-2024 13:57</td> </tr> <tr> <td> </td> <td>2</td> <td>15-05-2024 14:06</td> <td>15-05-2024 14:38</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 09:56</td> <td>07-05-2024 10:39</td> </tr> <tr> <td>Constant - 100 users</td> <td>1</td> <td>02-05-2024 14:00</td> <td>02-05-2024 14:40</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 14:40</td> <td>06-05-2024 15:30</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 10:42</td> <td>07-05-2024 11:33</td> </tr> <tr> <td>Constant - 200 users</td> <td>1</td> <td>16-05-2024 09:37</td> <td>16-05-2024 10:09</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 15:32</td> <td>06-05-2024 16:13</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 11:34</td> <td>07-05-2024 12:11</td> </tr> <tr> <td>Constant - 400 users</td> <td>1</td> <td>02-05-2024 15:24</td> <td>02-05-2024 15:55</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 16:14</td> <td>06-05-2024 16:49</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 12:13</td> <td>07-05-2024 13:08</td> </tr> <tr> <td>Linear</td> <td>1</td> <td>22-05-2024 15:13</td> <td>22-05-2024 15:56</td> </tr> <tr> <td> </td> <td>2</td> <td>22-05-2024 16:05</td> <td>22-05-2024 16:48</td> </tr> <tr> <td> </td> <td>3</td> <td>23-05-2024 09:58</td> <td>23-05-2024 10:41</td> </tr> <tr> <td>Direct</td> <td>1</td> <td>2024-05-23 13:01:28</td> <td>2024-05-23 14:00:05</td> </tr> <tr> <td> </td> <td>2</td> <td>2024-05-23 14:33:23</td> <td>2024-05-23 15:32:01</td> </tr> <tr> <td> </td> <td>3</td> <td>2024-05-23 15:39:36</td> <td>2024-05-23 16:38:12</td> </tr> </tbody> </table> <p>A complete log of the experiments can be found in <code>experiments_log.txt</code>.</p> <h2>Constant</h2> <p>The constant data set contains the metrics for the system under a constant load. The load is generated by a Locust script that sends requests to the system. Data collection starts 1 minute after the desired number of concurrent users is reached and requests have stabilised. This experiment is performed for the following constant number of concurrent users:</p> <ul> <li>0 users</li> <li>50 users</li> <li>100 users</li> <li>200 users</li> <li>400 users</li> </ul> <p>Note that the <code>0 users</code> data does not contain the <code>report_*.html</code> and <code>request_*.csv</code> files, as these are generated by Locust and Locust is not run for the <code>0 users</code> scenario.</p> <p>Furthermore, note that Horizontal Pod Autoscaling is <em>not</em> enabled for this data set.</p> <h2>Linear</h2> <p>The linear dataset contains the metrics for the system under a linearly scaling load. The load is generated through Locust. It starts at 0 users, and scales up to 100 users at a rate of 1 user per 20 seconds. After the load reaches 100 users, another 10 minutes of data is recorded. Every dataset is 45 minutes long, with 1.7 minutes of no load, 33.3 minutes of scaling up, and 10 minutes of max load.</p> <p>Note that Horizontal Pod Autoscaling <em>is</em> enabled for this data set.</p> <h2>Direct</h2> <p>The direct data set compliments the linear dataset. While the linear dataset provides a realistic load with things like networking factors being taken into account, the linear dataset can bottleneck on things like networking and the request client, so CPU usage is not maxed out. The direct dataset scales up linearly by applying direct CPU load to the Kubernetes pods without any application simulating a real usecase. The dataset works by deploying Kubernetes pods that max out immediately on exactly 200mCPU of load. The experiment starts with 1 pod, and 2 pods are added every 90 seconds up till 77 pods (the maximum number of pods the cluster allows to be scheduled). The first 1.5 minutes is no load, then 57 minutes to scale up, and then another 1.5 minutes at max load.</p> <p>Note that the <code>direct</code> data set does not contain the <code>app_*.json</code> files, as this data set does not deploy an application and therefore no application specific metrics are collected. Instead, a <code>script_log.txt</code> is provided that explains when and how the direct load was scaled up.</p> <h1>Files</h1> <p>A table for each file in the data set can be found below, including the unit of the metric and a description of what data is collected in that file. The format of all JSON files is the API response format used by Prometheus. More information on this topic can be found here: <a title="https://prometheus.io/docs/prometheus/latest/querying/api/" href="https://prometheus.io/docs/prometheus/latest/querying/api/">https://prometheus.io/docs/prometheus/latest/querying/api/</a>. All timestamps are in the CEST timezone.</p> <table> <tbody> <tr> <th>Filename</th> <th>Unit</th> <th>Description</th> </tr> </tbody> <tbody> <tr> <td>app_ads_ad_requests_total.json</td> <td>Total Count</td> <td>Total requests received by the ad microservice</td> </tr> <tr> <td>app_currency_counter_total.json</td> <td>Total Count</td> <td>Total currency that circulated through the system</td> </tr> <tr> <td>app_frontend_requests_total.json</td> <td>Total Count</td> <td>Total requests received by the frontend service</td> </tr> <tr> <td>app_payment_transactions_total.json</td> <td>Total Count</td> <td>Total transactions made to the transaction microservice</td> </tr> <tr> <td>app_recommendations_counter_total.json</td> <td>Total Count</td> <td>Total recommendations made by the recommendation microservice</td> </tr> <tr> <td>container_blkio_device_usage_total.json</td> <td>Total Bytes</td> <td>Total bytes used by blkio devices for pods</td> </tr> <tr> <td>container_cpu_usage_seconds_total.json</td> <td>Total Seconds</td> <td>Cumulative cpu time consumed by the pod</td> </tr> <tr> <td>container_cpu_user_seconds_total.json</td> <td>Total Seconds</td> <td>Cumulative user cpu time consumed by the pod</td> </tr> <tr> <td>container_fs_reads_bytes_total.json</td> <td>Total Bytes</td> <td>Cumulative count of bytes read by the pod</td> </tr> <tr> <td>container_fs_writes_bytes_total.json</td> <td>Total Bytes</td> <td>Cumulative count of bytes written by the pod</td> </tr> <tr> <td>container_memory_rss.json</td> <td>Bytes</td> <td>Resident Set Size of the pod</td> </tr> <tr> <td>kepler_container_bpf_cpu_time_ms_total.json</td> <td>Milliseconds</td> <td>CPU time for the pod as measured through a Kepler BPF program</td> </tr> <tr> <td>kepler_container_core_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of CPU cores used by a pod</td> </tr> <tr> <td>kepler_container_dram_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of DRAM used by a pod</td> </tr> <tr> <td>kepler_container_joules_total.json</td> <td>Total Joules</td> <td>Aggregated total energy consumption of a pod</td> </tr> <tr> <td>kepler_container_package_joules_total.json</td> <td>Total Joules</td> <td>Cumulative energy consumed by all cores and uncore components of a pod</td> </tr> <tr> <td>kepler_node_core_joules_total.json</td> <td>Total Joules</td> <td>Aggregation of core_joules of all pods running on a Kubernetes node</td> </tr> <tr> <td>kepler_node_dram_joules_total.json</td> <td>Total Joules</td> <td>Aggregation of dram_joules of all pods running on a Kubernetes node</td> </tr> <tr> <td>kepler_node_package_joules_total.json</td> <td>Total Joules</td> <td>Aggregation of package_joules of all pods running on a Kubernetes node</td> </tr> <tr> <td>node_cpu_scaling_frequency_hertz.json</td> <td>Hertz</td> <td>Current scaled cpu thread frequency of a machine (BM or VM)</td> </tr> <tr> <td>node_cpu_seconds_total.json</td> <td>Total Seconds</td> <td>Total number of seconds the CPU worked on a machine (BM or VM)</td> </tr> <tr> <td>node_disk_read_time_seconds_total.json</td> <td>Total Seconds</td> <td>Total number of seconds spent reading disk on a machine (BM or VM)</td> </tr> <tr> <td>node_disk_write_time_seconds_total.json</td> <td>Total Seconds</td> <td>Total number of seconds spent writing disk on a machine (BM or VM)</td> </tr> <tr> <td>node_hwmon_temp_celsius.json</td> <td>Celsius</td> <td>Temperature of the machine (BM) as reported by its monitoring hardware</td> </tr> <tr> <td>node_load1.json</td> <td>Load Average</td> <td>Load on the machine (BM or VM) averaged over 1 minute</td> </tr> <tr> <td>node_load5.json</td> <td>Load Average</td> <td>Load on the machine (BM or VM) averaged over 5 minutes</td> </tr> <tr> <td>node_load15.json</td> <td>Load Average</td> <td>Load on the machine (BM or VM) averaged over 15 minutes</td> </tr> <tr> <td>node_memory_Active_bytes.json</td> <td>Bytes</td> <td>Active number of bytes in memory on the machine (BM or VM)</td> </tr> <tr> <td>node_memory_Committed_AS_bytes.json</td> <td>Bytes</td> <td>Committed number of bytes in memory on the machine (BM or VM)</td> </tr> <tr> <td>node_rapl_core_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of CPU cores by a machine, estimated by RAPL</td> </tr> <tr> <td>node_rapl_dram_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of DRAM by a machine, estimated by RAPL</td> </tr> <tr> <td>node_rapl_package_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of the machine package, estimated by RAPL</td> </tr> <tr> <td>node_rapl_psys_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of the machine psys, estimated by RAPL</td> </tr> <tr> <td>power_consumption.json</td> <td>Watt</td> <td>Energy consumption as measured by the physical power plugs</td> </tr> <tr> <td>report_*.html</td> <td>-</td> <td>HTML report describing details of locust actions during the experiment</td> </tr> <tr> <td>requests_*.csv</td> <td>-</td> <td>Request summary per endpoint generated by locust</td> </tr> <tr> <td>scaph_host_power_microwatts.json</td> <td>Microwatt</td> <td>Power consumption of the whole machine as estimated by Scaphandre</td> </tr> <tr> <td>scaph_process_cpu_usage_percentage.json</td> <td>Percentage</td> <td>Per-process CPU usage as a percentage of total machine CPU</td> </tr> <tr> <td>scaph_process_memory_bytes.json</td> <td>Bytes</td> <td>Per-process memory usage</td> </tr> <tr> <td>scaph_process_power_consumption_microwatts.json</td> <td>Microwatt</td> <td>Per-process energy consumption as estimated by Scaphandre</td> </tr> <tr> <td>script.log</td> <td>-</td> <td>Log for the direct experiments for scaling up the pods</td> </tr> </tbody> </table> <h1>Scripts</h1> <div> <div>All scripts used to query this data from the prometheus endpoint and to generate the results in the associated paper are included in the scripts directory. To run a script, the script must be placed in the same directory as the data it is operated on (e.g. /scripts/constant/power_estimation.ipynb has to be in /constant).</div> </div>
Understanding the Teamwork Challenges of Software Engineering Students
<p>Developing collaborative skills in students is nontrivial. The fact that students work in teams does not mean they become skilled in teamwork. Students face varied challenges when working in teams that harm their skill development and attitude towards teamwork. To prepare students for the collaboration-intensive workplace, we researched and designed a catalog of challenges present in the teamwork of undergraduate software engineering students on 3-month projects.</p> <p>We created an initial catalog of 10 challenges by examining the literature, surveying 15 teaching assistants, and coding their opinions regarding the problems faced by student teams. Using the catalog, we crafted a survey for students nearing the end of their team project to assess which challenges were present in their teamwork. We surveyed students from multiple contexts, including teams of 3, teams of 4, and teams of 16 students.</p> <p>We analyzed 155 answers to determine the prevalence and intensity of the 10 challenges in student teams. We discuss our findings and best practices for resolving the most prevalent challenges. The catalog and recommendations are directly valuable for software engineering educators and can inform the broader community of collaborative learning researchers and instructional designers.</p>
Hearing the Voice of Software Practitioners on Technical Debt Monitoring: Understanding Monitoring Practices and the Practices' Avoidance Reasons: Data set
Open the record for dataset details and reuse information.
Supplementary material of Towards an Understanding of Requirements Management in Software Ecosystems
Open the record for dataset details and reuse information.
Towards an Understanding of Requirements Management in Software Ecosystems
Open the record for dataset details and reuse information.
Supplementary material of Towards an Understanding of Requirements Management in Software Ecosystems
Open the record for dataset details and reuse information.
The Lack of Shared Understanding of Non-Functional Requirements in Continuous Software Engineering: Accidental or Essential?
<p>Study Information</p> <p>We conducted a case study of three small organizations scaling up continuous software engineering to further understand and identify factors that contribute to lack of shared understanding of non-functional requirements (NFRs), and its relationship to rework. To conceptualize lack of shared understanding of NFRs we traced it to rework development tasks. Seeking to shed light on the complex relationship between shared understanding, rework, and CSE, our study examined forty-one NFR-related development tasks identified as rework and was driven by the following research questions:</p> <ol> <li>What contributes to lack of shared understanding of NFRs?</li> <li>Which NFRs are most associated with a lack of shared understanding?</li> <li>What amount of a lack of shared understanding of NFRs is accidental versus essential?</li> </ol> <p>To answer our research questions, we conducted a multi-case study using a mixed-methods approach in collaboration with three independent organizations using qualitative and immersive techniques. For this study our organizations are referred to as Alpha, Beta, and Gamma. We performed a preliminary study of each organization to build a context for each organization. We then collected data from project task management repositories and analyzed the tasks to uncover 41 NFR-related software development tasks as rework due to a lack of shared understanding of NFRs.</p> <p>Data Analysis</p> <p>We performed qualitative analysis through focus groups at each organization. We used an open-coding [1] approach to develop a purely inductive codebook, which minimizes a coder's ability to force a bias of any particular hypothesis. In the initial coding phase, a transcript was independently coded by two coders, after which an agreement session was held to discuss the codes, consolidate the codebook, and to calculate Cohen's kappa coefficient (using sklearn.metrics cohen_kappa_score). We continued coding in pairs until our inter-rater reliability met substantial agreement. After which we individually coded the remaining transcripts followed by an expert rater reviewer.</p> <p>This data represents two artifacts from our research in evaluating the complex relationship between shared understanding, non-functional requirements, continuous software engineering, and rework. It includes the resulting thematic synthesis codebook and inter-rater kappa values.</p> <p>Artifact Descriptions</p> <p>Our replication package contains two artifacts:<br> 1. Codebook.csv: The codebook itself contains a row for each code used (48 in total), including the code name, a brief description of the code, which round of coding that code was introduced, the total number of tasks that code appeared in (at least once), the number of tasks that code appeared in for each organization (Alpha, Beta, and Gamma), the total number of occurrences across all tasks, the number of occurrences across across each organization (Alpha, Beta, and Gamma), and the number of occurrences for each task.</p> <p>For example, the code 'BusinessContext' was used when 'Talking about information from the business side of the organization' and appeared in the first transcript we coded (1). The 'BusinessContext' code appeared in 19/41 tasks (10 at Alpha, 8 at Beta, and 1 at Gamma). Furthermore, the 'BusinessContext' code was used a total of 72 times (43 at Alpha, 22 at Beta, and 7 at Gamma). The remaining 41 columns represent the number of occurrences for each task, e.g. it appeared 3 times in task A-2 (Alpha's second task).</p> <p>2. kappa-values.csv: Contains the interview rounds (in order of coding) and the associated kappa values calculated for our inter-rater coding agreement.</p> <p>Usefulness</p> <p>While we recognize that the value and usefulness of our replication package is yet to-be-determined, in the interest of transparency of open science we published our artifacts. In light of this, we hope that these artifacts are useful to either replicate our findings or to further analyze to produce other enlightening results.</p> <p>References</p> <ol> <li>J. M. Corbin and A. Strauss, “Grounded theory research: Procedures, canons, and evaluative criteria,”Qualitative sociology, vol. 13, no. 1,pp. 3–21, 1990.</li> </ol>
Artifacts of Paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems"
<p>This package contains all the artifacts (i.e. codes & datasets) we use in our paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems" accepted to FSE 2020.</p>
Artifacts of Paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems"
<p>This package contains all the artifacts (i.e. codes & datasets) we use in our paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems" accepted to FSE 2020.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.