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.
192
datasets available to search
ShareScore release 0.9.0
Dataset results
192 results for “software engineering”
Replication package for: An Analysis of Positionality Statements in Software Engineering Research
Open the record for dataset details and reuse information.
How did COVID-19 Impact Software Design Activities in Global Software Engineering — Systematic Review
<p>This dataset is part of research publication <a href="https://doi.org/10.1142/S0218194024500098" target="_blank" rel="noopener">How did COVID-19 Impact Software Design Activities in Global Software Engineering — Systematic Review</a> published in <em>International Journal of Software Engineering and Knowledge Engineering</em>. This study systematically analyzes the evolution of research emphasis in the field of Global Software Engineering (GSE), particularly focusing on the software design phase during the COVID-19 pandemic.</p> <h3>Key contribution</h3> <ol> <li>Systematic analysis of GSE research <ul> <li>Phase 1 - Mapped GSE research over the two decades leading to the pandemic (2000–2020)</li> <li>Phase 2 - Used the forward snowballing approach to examine literature on the software design phase published between 2020 and 2022.</li> </ul> </li> <li>Analyzed trends in GSE research through 592 research studies across both phases.</li> </ol> <h3>Dataset content</h3> <p>The dataset consis of following files:</p> <ol> <li>Readme file - Overview and instructions for the dataset.</li> <li>Search string and snowballing - Contains the search strings used in the first phase and details of the forward snowballing approach used in the second phase.</li> <li>Data extraction template and Inclusion/exclusion criteria - Includes the template for organizing key features of papers relevant to the research questions and lists the inclusion and exclusion criteria applied.</li> <li>Screening process - Describes the three-level screening process applied in both phases (title, abstract, full text). A separate tab analyzes primary studies used in the second phase.</li> <li>RQs analysis - Provides detailed analysis of research questions (RQs) from the final set of 592 papers.</li> </ol>
Dataset of Reducing the Effort for Systematic Reviews in Software Engineering
<p>Reducing the Effort for Systematic Reviews in Software Engineering</p> <p><strong>Background.</strong> Systematic Reviews (SRs) are means to collect and synthesize evidence from the identification, analysis and interpretation of multiple sources, or primary studies. To this aim, they use a well-defined methodology that should mitigate the risks of biases and ensure repeatability for later updates. SRs, however, involve significant effort.</p> <p><strong>Goal.</strong> The goal of this paper is to introduce a new methodology that, among other benefits, while taking advantage of the value provided by human expertise, reduces the amount of manual tedious tasks involved in SRs.</p> <p><strong>Method.</strong> Starting from current methodologies for SRs, we replaced the steps of keywording and data extraction with an automatic methodology for generating a domain ontology and classifying the primary studies. This methodology has been then applied in the software engineering sub-area of software architecture, and software quality, and evaluated with human annotators.</p> <p><strong>Results.</strong> The result is a novel expert-driven automatic methodology for performing SRs. This combines ontology-learning techniques and semantic technologies with the human-in-the-loop. The first (thanks to automation) fosters scalability, objectivity, reproducibility and granularity of the studies; the second allows tailoring to the specific focus of the study at hand, as well as knowledge reuse from domain experts.</p> <p><strong>Conclusions.</strong> Thanks to automation of the less creative steps in SRs, our methodology allows researchers to skip the tedious tasks of keywording and manually classifying primary studies, thus freeing effort for the analysis and the discussion.</p>
Dataset for "Francisco Cirelli, Dalal Alrajeh, Sebastian Uchitel. Unavoidable Boundary Conditions: A Control Perspective on Goal Conflicts. In Proceedings of the 47th International Conference on Software Engineering 2025."
<p>This is the experimental data for the paper </p> <p>Francisco Cirelli, Dalal Alrajeh, Sebastian Uchitel<br>Unavoidable Boundary Conditions: A Control Perspective on Goal Conflicts. <br>In Proceedings of the 47th International Conference on Software Engineering 2025. </p> <p>We provide various specifications of reactive synthesis control problems taken from various sources. See paper for more details.</p>
The Impact of Generative AI-Powered Code Generation Tools on Software Engineer Hiring: Recruiters' Experiences, Perceptions, and Strategies
<p>This is the dataset for the paper: The Impact of Generative AI-Powered Code Generation Tools on Software Engineer Hiring: Recruiters' Experiences, Perceptions, and Strategies</p> <p> This paper was accepted for publication at the 58th Hawaii International Conference on System Sciences (HICSS) - Software Technology Track</p>
Web portal for teaching and practicing controlled experiments in Software Engineering - Tests Dataset
<p>The Test Dataset for the Web portal for teaching and practicing controlled experiments<br>in Software Engineering, developed by Fernando S. Grande, Edson OliveiraJr and André F.R. Cordeiro</p>
Towards an Analogical Reasoning with LLMs in Software Engineering Education
<p>Data collected from professors and students using our approach to teach/understand SE concepts </p>
Can ChatGPT emulate humans in software engineering surveys? - ESEM '24
<p>This is the replication package for the paper "Can ChatGPT emulate humans in software engineering surveys?" submitted to the Vision and Reflections track at ESEM '2024.</p>
Datasets and scripts related to the paper: "*Can Generative AI Help us in Open Coding of Software Engineering Data?*"
<p>This replication package contains datasets and scripts related to the paper: "<em>Can Generative AI Help us in Open Coding of Software Engineering Data?</em>"</p> <p>The replication package is organized into two directories:</p> <ul> <li> <p><code>manual_analysis</code>: This directory contains all sheets used to perform the manual analysis for RQ1, RQ2, and RQ3.</p> </li> <li> <p><code>stats</code>: This directory contains all datasets, scripts, and results metrics used for the quantitative analyses of RQ1 and RQ2.</p> </li> </ul> <p>In the following, we describe the content of each directory:</p> <h2>manual_analysis</h2> <ul> <li> <p><code>manual_analysis_rq1</code>: This directory contains all sheets used to perform manual analysis for RQ1 (independent and incremental coding).</p> <ul> <li> <p>The sub-directory <code>incremental_coding</code> contains .csv files for all datasets (<code>DL_Faults_COMMIT_incremental.csv</code>, <code>DL_Faults_ISSUE_incremental.csv</code>, <code>DL_Fault_SO_incremental.csv</code>, <code>DRL_Challenges_incremental.csv</code> and <code>Functional_incremental.csv</code>). All these .csv files contain the following columns:</p> <ul> <li><em>Link</em>: The link to the instances</li> <li><em>Prompt</em>: Prompt used as input to GPT-4-Turbo</li> <li><em>ID</em>: Instance ID</li> <li><em>FinalTag</em>: Tag assigned by the human in the original paper</li> <li><em>Chatgpt_output_memory</em>: Output of GPT-4-Turbo with incremental coding</li> <li><em>Chatgpt_output_memory_clean</em>: (only for the DL Faults datasets) output of GPT-4-Turbo considering only the label assigned, excluding the text</li> <li><em>Author1</em>: Label assigned by the first author</li> <li><em>Author2</em>: Label assigned by the second author</li> <li><em>FinalOutput</em>: Label assigned after the resolution of the conflicts</li> </ul> </li> <li> <p>The sub-directory <code>independent_coding</code> contains .csv files for all datasets (<code>DL_Faults_COMMIT_independent.csv</code>, <code>DL_Faults_ISSUE_ independent.csv</code>, <code>DL_Fault_SO_ independent.csv</code>, <code>DRL_Challenges_ independent.csv</code> and <code>Functional_ independent.csv</code>), containing the following columns:</p> <ul> <li><em>Link</em>: The link to the instances</li> <li><em>Prompt</em>: Prompt used as input to GPT-4-Turbo</li> <li><em>ID</em>: Specific ID for the instance</li> <li><em>FinalTag</em>: Tag assigned by the human in the original paper</li> <li><em>Chatgpt_output</em>: Output of GPT-4-Turbo with independent coding</li> <li><em>Chatgpt_output_clean</em>: (only for DL Faults datasets) output of GPT-4-Turbo considering only the label assigned, excluding the text</li> <li><em>Author1</em>: Label assigned by the first author</li> <li><em>Author2</em>: Label assigned by the second author</li> <li><em>FinalOutput</em>: Label assigned after the resolution of the conflicts.</li> </ul> </li> <li> <p>Also, the sub-directory contains sheets with inconsistencies after resolving conflicts. The directory <code>inconsistency_incremental_coding</code> contains .csv files with the following columns:</p> <ul> <li><em>Dataset</em>: The dataset considered</li> <li><em>Human</em>: The label assigned by the human in the original paper</li> <li><em>Machine</em>: The label assigned by GPT-4-Turbo</li> <li><em>Classification</em>: The final label assigned by the authors after resolving the conflicts. Multiple classifications for a single instance are separated by a comma “,”</li> <li><em>Final</em>: final label assigned after the resolution of the incompatibilities</li> </ul> </li> <li> <p>Similarly, the sub-directory <code>inconsistency_independent_coding</code> contains a .csv file with the same columns as before, but this is for the case of independent coding.</p> </li> </ul> </li> <li> <p><code>manual_analysis_rq2</code>: This directory contains .csv files for all datasets (<code>DL_Faults_redundant_tag.csv</code>, <code>DRL_Challenges_redundant_tag.csv</code>, <code>Functional_redundant_tag.csv</code>) to perform manual analysis for RQ2.</p> <ul> <li> <p>The <code>DL_Faults_redundant_tag.csv</code> file contains the following columns:</p> <ul> <li><em>Tags Redundant</em>: tags identified as redundant by GPT-4-Turbo</li> <li><em>Matched</em>: inspection by the authors to see if the tags are redundant matching or not</li> <li><em>FinalTag</em>: final tag assigned by the authors after the resolution of the conflict</li> </ul> </li> <li> <p>The <code>Functional_redundant_tag.csv</code> file contains the same columns as before</p> </li> <li> <p>The <code>DRL_Challenges_redundant_tag.csv</code> file is organized as follows:</p> <ul> <li><em>Tags Suggested</em>: The final tag suggested by GPT-4-Turbo</li> <li><em>Tags Redundant</em>: tags identified as redundant by GPT-4-Turbo</li> <li><em>Matched</em>: inspection by the authors to see if the tags redundant matching or not with the tags suggested</li> <li><em>FinalTag</em>: final tag assigned by the authors after the resolution of the conflict</li> </ul> </li> <li> <p>The sub-directory <code>code_consolidation_mapping_overview</code> contains .csv files (<code>DL_Faults_rq2_overview.csv</code>, <code>DRL_Challenges_rq2_overview.csv</code>, <code>Functional_rq2_overview.csv</code>) organized as follows:</p> <ul> <li><em>Initial_Tags</em>: list of the unique initial tags assigned by GPT-4-Turbo for each dataset</li> <li><em>Mapped_tags</em>: list of tags mapped by GPT-4-Turbo</li> <li><em>Unmatched_tags</em>: list of unmatched tags by GPT-4-Turbo</li> <li><em>Aggregating_tags</em>: list of consolidated tags</li> <li><em>Final_tags</em>: list of final tags after the consolidation task</li> </ul> </li> </ul> </li> <li> <p><code>prompt_for_each_rq</code>: This directory contains: - (i) the history of prompts used in each dataset (<code>prompts_history.txt</code>) -(ii) all final prompt used for the analysis of each dataset, prompt used for incremental coding, prompt used in rq2 to consolidate redundant codes, prompt used in rq3 to create taxonomy (<code>generic_prompt.txt</code>) -(iii) all .csv files in which there are indicate, for each dataset, the link and the prompt used (<code>prompt_DL_Faults_COMMIT.csv</code>, <code>prompt_DL_Faults_ISSUE.csv</code>, <code>prompt_DL_Faults_SO.csv</code>, <code>prompt_DRL_Challenges.csv</code>). For the Functional Dataset .csv file contains, instead, Question, Answer and Prompt used (<code>prompt_Functional.csv</code>)</p> </li> <li> <p><code>rq3</code>: This directory contains the taxonomies obtained from GPT-4-Turbo for the DL Faults and for the DRL Challenges (<code>taxonomy_DL_Faults.txt</code>,<code>taxonomy_DRL_Challenges.txt</code>)</p> </li> </ul> <h2>stats</h2> <ul> <li> <p><code>RQ1</code>: contains script and datasets used to perform metrics for RQ1. The analysis calculates all possible combinations between Matched, More Abstract, More Specific, and Unmatched.</p> <ul> <li><code>RQ1_Stats.ipynb</code> is a Python Jupyter nooteook to compute the RQ1 metrics. To use it, as explained in the notebook, it is necessary to change the values of variables contained in the first code block.</li> <li><code>independent-prompting</code>: Contains the datasets related to the independent prompting. Each line contains the following fields: <ul> <li><em>Link</em>: Link to the artifact being tagged</li> <li><em>Prompt</em>: Prompt sent to GPT-4-Turbo</li> <li><em>FinalTag</em>: Artifact coding from the replicated study</li> <li><em>chatgpt_output_text</em>: GPT-4-Turbo output</li> <li><em>chatgpt_output</em>: Codes parsed from the GPT-4-Turbo output</li> <li><em>Author1</em>: Annotator 1 evaluation of the coding</li> <li><em>Author2</em>: Annotator 2 evaluation of the coding</li> <li><em>FinalOutput</em>: Consolidated evaluation</li> </ul> </li> <li><code>incremental-prompting</code>: Contains the datasets related to the incremental prompting (same format as independent prompting)</li> <li><code>results</code>: contains files for the RQ1 quantitative results. The files are named <code>RQ1\_<<Dataset>>\_<<Prompt method>>\_<<ExcludingNegative>>\_<<MetricAggregation>>.csv</code>, where <em>Dataset</em> is the dataset name, <em>Prompt method</em> indicates whether results are for independent or incremental prompting, <em>Excluding Negatives</em> (for datasets where this applies) whether results have been obtained by excluding negative instances, and <em>MetricAggregation</em> (where it applies) how metrics have been aggregated (macro or weighted average). The files report columns indicating the <em>Dataset</em>, the <em>Matching type</em>, the <em>Accuracy</em>, <em>Precision</em>, <em>Recall</em>, <em>F1 Score</em>, and <em>Cohen's Kappa</em>.</li> </ul> </li> <li> <p><code>RQ2</code>: contains the script used to perform metrics for RQ2, the datasets it uses, and its output.</p> <ul> <li><code>RQ2_SetStats.ipynb</code> is the Python Jupyter notebook to perform the analyses. The scripts takes as input the following types of files, contained in the directory contains the script used to perform the metrics for RQ2. The script takes in input:</li> <li>RQ1 Data Files (<code>RQ1_DLFaults_Issues.csv</code>, <code>RQ1_DLFaults_Commits.csv</code>, and <code>RQ1_DLFaults_SO.csv</code>, joined in a single .csv <code>RQ1_DLFaults.csv</code>). These are the same files used in RQ1.</li> <li>Mapping Files (<code>RQ2_Mappings_DRL.csv</code>, <code>RQ2_Mappings_Functional.csv</code>, <code>RQ2_Mappings_DLFaults.csv</code>). These contain the mappings between human tags (<em>HumanTags</em>), GPT-4-Turbo tags (<em>Final Tags</em>), with indicated the type of matching (<em>MatchType</em>).</li> <li>Additional codes creating during the consolidation (<code>RQ2_newCodes_DRL.csv</code>, <code>RQ2_newCodes_Functional.csv</code>, <code>RQ2_newCodes_DLFaults.csv</code>), annotated with the matching: <em>new code</em>,<em>old code</em>,<em>human code</em>,<em>match type</em></li> <li>Set files (<code>RQ2_Sets_DRL.csv</code>, <code>RQ2_Sets_Functional.csv</code>, <code>RQ2_Sets_DLFaults.csv</code>). Each file contains the following columns: <ul> <li><em>HumanTags</em>: List of tags from the original dataset</li> <li><em>InitialTags</em>: Set of tags from RQ1,</li> <li><em>ConsolidatedTags</em>: Tags that have been consolidated,</li> <li><em>FinalTags</em>: Final set of tags (results of RQ2, used in RQ3)</li> <li><em>NewTags</em>: New tags created during consolidation</li> </ul> </li> <li><code>RQ2_Set_Metrics.csv</code>: Reports the RQ2 output metrics (Precision, Recall, F1-Score, Jaccard).</li> </ul> </li> </ul>
Human vs. Machine: How Software Engineers Perceive and Engage with AI-Assisted Code Reviews Compared to Their Peers
<p>This Shared Document Package contains the supplementary materials package for the study, "Human vs. Machine: How Software Engineers Perceive and Engage with AI-Assisted Code Reviews Compared to Their Peers." The package contains all relevant documentation and materials utilized during the study, except interview transcripts. Documents shared in this packes are to assist the readers understand and verify the research protocol and data collection process. It contains:</p> <ol> <li>README file</li> <li>Questionnaire for interview pre-selection</li> <li>Participants’ submitted code snippets</li> <li>Code reviews submitted by participants</li> <li>ChatGPT 4.0-Generated code reviews</li> <li>Complete interview guide</li> <li>Member checking feedback data</li> </ol>
Theory Use In Software Engineering: A Systematic Mapping Study
<p><strong>Abstract </strong></p> <p><strong>Context</strong>: The use of theories in Software Engineering research is not as common or explicit as in other fields,<br>with most studies focusing on technical aspects. However, establishing a more robust theoretical foundation could<br>significantly contribute to the maturation of Software Engineering as a science.</p> <p><strong>Objective</strong>: Therefore, this study investigates the use of theory in software engineering by applying the snowballing<br>technique to systematic literature reviews indexed by the main online databases over the last 16 years. It also analyzes<br>the extent of theory use and what, how, and where these theories are used.</p> <p><strong>Method</strong>: We conducted a systematic mapping study to classify evidence on theory definitions, papers’ quality,<br>research topics, methods, types, theory types, theory roles, and publication venues.</p> <p><strong>Results</strong>: Our results showed that the term “theory” varied among the literature due to inconsistent terminology,<br>thus necessitating a comprehensive approach for accurate identification. Although many theories are cited, only a tiny<br>percentage see repeated application across studies, with limited testing for relevance to practical software engineering<br>contexts.</p> <p><strong>Conclusion</strong>: Despite the increase in proposed theories, software engineering requires further attention to mature, as<br>most papers primarily use theory to justify or motivate experimental research questions. Furthermore, although there<br>is a diversity of research topics and an adaptation of external theories, only 16% of studies explicitly operationalize<br>theory, highlighting the need for more intentional theoretical integration and developing SE-specific frameworks.</p>
Replication Package for "Classifying Open-Source Pre-Trained Models and Datasets for Software Engineering"
<p>The replication package for the short paper titled 'Classifying Open-Source Pre-Trained Models and Datasets for Software Engineering' is provided. It includes a README file and accompanying scripts with comprehensive instructions to facilitate the replication of the analysis presented in the paper.</p>
Replication Package for "A Call for Critically Rethinking and Reforming Data Analysis in Empirical Software Engineer"
<p><strong>Content Overview</strong></p> <p>This replication package contains the following materials:</p> <p>- Data: RAW Focus Group Datasets and Aggregated Results</p> <p>For any issues, questions, or further assistance, please do not hesitate to contact the paper's authors. We are here to help!</p>
Empirical Study and Vision for a Holistic Serious Game Platform for Software Engineering Education
<p>Serious games are becoming increasingly popular in universities to motivate students. Therefore, more and more lecturers are using game-based learning to encourage students to learn the subject matter. However, using serious games in Software Engineering (SE) lectures at universities is rather challenging as the subject is very practice-oriented and requires special kinds of tasks, e.g., practicing programming, software modeling, etc. Thus, building serious games and integrating such SE-specific tasks is a serious technical challenge and requires immense development effort. Therefore, before developing new games, students' preferences should be analyzed to increase the chances that these games will be played. To address this issue, we conducted an empirical study with 105 students to investigate the requirements and chances for using serious games in SE education in universities. Our analysis shows that students' preferences vary significantly and that there is no clear indication of a single game type that motivates all students equally. Therefore, our second contribution is a vision for a microservice-based Holistic Serious Game Platform for Software Engineering Education, which supports efficiently developing different serious games and integrating SE-specific mini-games and tasks. Hence, our empirical results and the presented approach support advancing research and development of serious SE games and also sensitize game developers to the needs of SE education.</p>
Automated Support for Searching and Selecting Evidence in Software Engineering: A Cross-domain Systematic Mapping
<p>Dataset -- Brief summary of the automated approaches for searching and selecting studies for secondary studies in software engineering </p>
Automated Support for Searching and SelectingEvidence in Software Engineering: A Cross-domainSystematic Mapping
<p>Data from the studies that adrress search and selection approaches. </p>
How Tertiary Studies perform Quality Assessment of Secondary Studies in Software Engineering - Replication Package
<p>Replication Package for the paper:</p> <p>D. Costal, C. Farré, X. Franch, C. Quer. 2021. How Tertiary Studies perform Quality Assessment of Secondary Studies in Software Engineering. CIbSE 2021.</p> <p>Please refer to the above paper if you want to cite/use this data.</p>
Inclusion and Exclusion Criteria in Software Engineering Tertiary Studies: A Systematic Mapping and Emerging Framework - Replication Package
<p>Replication Package for the paper:</p> <p>D. Costal, C. Farré, X. Franch, C. Quer. 2021. Inclusion and Exclusion Criteria in Software Engineering Tertiary<br> Studies: A Systematic Mapping and Emerging Framework. ESEM '21, <a href="https://doi.org/10.1145/3475716.3484190">https://doi.org/10.1145/3475716.3484190</a></p> <p>Please refer to the above paper if you want to cite/use this data.</p>
Perceptions of the Brazilian Software Engineering Research Community About Grey Literature
<p>Replication package of the study "Perceptions of the Brazilian Software Engineering Research Community About Grey Literature" conducted with the Brazilian Software Engineering Researchers.</p>
List of documents and patterns identified by multivocal literature review of software engineering patterns for machine learning applications
We performed a multivocal literature review of both academic and gray literature to collect software engineering for machine learning (ML) application systems and software design. For the academic literature, we chose Engineering Village. For the gray literature, we used a Google search on August 16, 2019. We retrieved 32 scholarly documents and 48 gray literature documents. We vetted whether each document should be included in our review using the following criteria: Documents written in English addressing concrete software-engineering patterns or practices to design ML application systems and software should be included. Documents focusing on design of ML techniques and algorithms should be excluded. This process identified 19 scholarly documents and 19 gray documents. Although 69 patterns related to the design of ML application systems were initially identified, 33 remained after the vetting process. Finally, industrial ML developers reviewed the 33 candidates from the viewpoint of practical usefulness. They identified only 15 ML patterns.
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.