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.
51
datasets available to search
ShareScore release 0.7.1
Dataset results
51 results for “Software Quality”
GitHub Profiles (users/organisations) and Repositories (research/non-research) of Potsdam Researchers and Research Organisations: An annotated dataset of with howfairis and software quality variables.
<p>This dataset accompanies the paper <em>"Software FAIRness, Documentation and Development Practices in Potsdam Researchers' GitHub Repositories"</em> It includes 3 CSV files that contain data related to github profiles of users/organisations, their repositories annotated as research/non-research repositories and followed by FAIRness and other software qualtiy variables. The data were collected using <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP">SWORDS-template-UP</a> (v1.0.0) methods (collect_users, collect_repositories, collect_variables) which is extended version of <a href="https://github.com/UtrechtUniversity/SWORDS-template">SWORS-template</a> adopted according our needs and detailed in the paper.</p> <p><strong>GitHub (research) user/organisation profiles. ( <em>github_profiles.csv )</em></strong></p> <table> <tbody> <tr> <td><strong>Column name</strong></td> <td><strong>Description </strong></td> </tr> <tr> <td>user_id</td> <td>GitHub username </td> </tr> <tr> <td>html_url </td> <td>URL of the GitHub profile </td> </tr> <tr> <td>type </td> <td>Type of profile (user or organization)</td> </tr> <tr> <td>organisation</td> <td>Acronym or name of the organization </td> </tr> </tbody> </table> <p><strong>GitHub repositories <em>(github_repositories.csv)</em></strong></p> <p>This file contains the repositories scraped from the GitHub profiles of research users and organizations.</p> <table> <tbody> <tr> <td><strong>Column name </strong></td> <td><strong>Description </strong></td> </tr> <tr> <td>html_url </td> <td>URL link to the repository </td> </tr> <tr> <td>description</td> <td>GitHub project description </td> </tr> <tr> <td>project</td> <td>Specifies if the project is research or non-research</td> </tr> <tr> <td>language</td> <td>Programming language used in the project </td> </tr> <tr> <td>organisation</td> <td>Acronym or name of the university, institution, or research organization</td> </tr> <tr> <td>research_group</td> <td>Acronym or name of the research group the repository belongs to</td> </tr> </tbody> </table> <p><strong>Research repositories filtered and annotated <em>(github_research_repositories_filtered_annotated.csv)</em></strong></p> <p>This file contains filtered and annotated information about research repositories.</p> <table> <tbody> <tr> <td><strong>Column Name </strong></td> <td><strong>Description </strong></td> <td><strong>Collection Method </strong></td> </tr> <tr> <td>html_url </td> <td>Repository URL </td> <td> </td> </tr> <tr> <td>howfairis_repository</td> <td>Indicates if the repository is public or private (True/False) </td> <td>(Script- <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/tree/main/collect_variables#usage">howfairis_variable.py</a>) is a wrapper for <a href="https://pypi.org/project/howfairis/">howfairis</a> pypi library that checks the 5 recommendations of <a href="https://fair-software.nl">FAIR</a></td> </tr> <tr> <td>howfairis_license </td> <td>Indicates if the repository has a license (True/False)</td> <td>(Script- <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/tree/main/collect_variables#usage">howfairis_variable.py</a>) is a wrapper for <a href="https://pypi.org/project/howfairis/">howfairis</a> pypi library that checks the 5 recommendations of <a href="https://fair-software.nl">FAIR</a></td> </tr> <tr> <td>howfairis_registry</td> <td>Indicates if the repository has implemented community registry (True/False)</td> <td>(Script- <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/tree/main/collect_variables#usage">howfairis_variable.py</a>) is a wrapper for <a href="https://pypi.org/project/howfairis/">howfairis</a> pypi library that checks the 5 recommendations of <a href="https://fair-software.nl">FAIR</a></td> </tr> <tr> <td>howfairis_citation</td> <td>Indicates if the repository has a .cff file (True/False) </td> <td>(Script- <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/tree/main/collect_variables#usage">howfairis_variable.py</a>) is a wrapper for <a href="https://pypi.org/project/howfairis/">howfairis</a> pypi library that checks the 5 recommendations of <a href="https://fair-software.nl">FAIR</a></td> </tr> <tr> <td>howfairis_checklist</td> <td>Indicates if the repository has implemented OpenSSF best practices badge (True/False)</td> <td>(Script- <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/tree/main/collect_variables#usage">howfairis_variable.py</a>) is a wrapper for <a href="https://pypi.org/project/howfairis/">howfairis</a> pypi library that checks the 5 recommendations of <a href="https://fair-software.nl">FAIR</a></td> </tr> <tr> <td>fair_score</td> <td>Score based on howfairis variables (0-5) </td> <td> </td> </tr> <tr> <td>dlr_soft_class</td> <td>Name of the university, company, research institute, or research organization</td> <td>(Manual) Annotated the repository based on <a href="https://core.ac.uk/reader/211557820">DLR software engineering guideline.</a> There are no specific definitions on metrics how to categorise them (github repositories) into application classes. Which were needed to do a comparitive analysis. </td> </tr> <tr> <td>installation_instruction</td> <td>Presence of installation instruction (True/False) </td> <td>(Manual) Checked the presense of Installation Instruction in the readme or in the project wiki pages. </td> </tr> <tr> <td>project_information </td> <td>Presence of basic project information in README (True/False) </td> <td>(Manual) Checked if the readme have basic information about the project. </td> </tr> <tr> <td>usage_guide</td> <td>Presence of folder named test/tests in the root directory (True/False)</td> <td>(Manual) Checked the presense of Usage Guide in the readme or in the project wiki pages. For command line tools checked if they have help command which guides how to use the tool. </td> </tr> <tr> <td>test_folder</td> <td>Presence of folder named test/tests in the root directory (True/False)</td> <td> <p>(Script - <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/blob/docs/collect_variables/scripts/soft_dev_pract/test_folder.py">test_folder.py</a>) Checks the folder names test/tests in the root directory of the repository.</p> </td> </tr> <tr> <td>requirements_explicit </td> <td>Explicit requirements for Python, R, C++ repositories (True/False)</td> <td>(Script - <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/blob/main/collect_variables/scripts/soft_dev_pract/requirement_explicit.py">requirement_explicit.py</a>) Checks the files (requirements.txt, DESCRIPTION, CMakeLists.txt) in the root directory. </td> </tr> <tr> <td>continuous_integration</td> <td>Indicates if the repository uses continuous integration (True/False)</td> <td>(Script- <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/blob/main/collect_variables/scripts/soft_dev_pract/continious_integration.py">continious_integration.py</a>) Checks the presence of folder .github (github actions) same for other continious integration (travisCI, CircleCI, Jekins, azure pipeline)</td> </tr> <tr> <td>ci_tool </td> <td>Name of the continuous integration tool used</td> <td>(Script- <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/blob/main/collect_variables/scripts/soft_dev_pract/continious_integration.py">continious_integration.py</a>) Checks the presence of folder .github (github actions) same for other continious integration (travisCI, CircleCI, Jekins, azure pipeline)</td> </tr> <tr> <td>add_lint_rule </td> <td>Indicates if additional linting rules are present (True/False)</td> <td>(Script - <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/blob/main/collect_variables/scripts/soft_dev_pract/add_ci_rules.py">add_ci_rules.py</a>) - it scans the YAML files in the <br>.github/workflows directory to detect the presence of (linters) Python, R, and C++.</td> </tr> <tr> <td>add_test_rule</td> <td>Indicates if additional testing rules are present (True/False) </td> <td>(Script - <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/blob/main/collect_variables/scripts/soft_dev_pract/add_ci_rules.py">add_ci_rules.py</a>) - it scans the YAML files in the <br>.github/workflows directory to detect the presence of (testing libraries) Python, R, and C++.</td> </tr> <tr> <td>comment_at_start</td> <td>Indicates the level of comments at the start of the program (most, more, some, less)</td> <td>(Script - <a href="https://github.com/Software-Engineering-Group-UP/SWORDS-template-UP/blob/main/collect_variables/scripts/soft_dev_pract/comment_at_start.py">comment_at_start.py</a>) Checks the presence of brief comments at the start at source code files in GitHub repositories.</td> </tr> <tr> <td>language </td> <td>Programming language used in the repository </td> <td> </td> </tr> <tr> <td>type </td> <td>Specifies if the profile is a user or organization </td> <td>Github organisation or user profiles.</td> </tr> <tr> <td>organisation </td> <td>Name of the university, company, research institute, or research organization</td> <td>Oraganisation name (from where the user was found)</td> </tr> <tr> <td>research_group</td> <td>Name or acronym of the research group </td> <td> </td> </tr> </tbody> </table> <p> </p> <p>Data for publication - https://github.com/Software-Engineering-Group-UP/potsdam-research-repos</p>
MACREL software benchmark data set: Simulated metagenomes with sequencing quality, errors profile and abundance distributions derived from real samples
<p>These metagenomes were used in the benchmarking of FACS pipeline, and were designed after NGLess benchmark dataset (doi.org/10.5281/zenodo.2560288). Metagenomes were simulated with <a href="https://www.niehs.nih.gov/research/resources/software/biostatistics/art/index.cfm">ART-bin-MountRainier-2016.06.05</a> using real abundance profiles (.abund files) available <a href="https://doi.org/10.5281/zenodo.2560288">elsewhere</a>, and <a href="http://progenomes1.embl.de/data/repGenomes/representatives.contigs.fasta.gz">proGenomes' representative contigs</a> as reference genomes. There are available metagenomes with 40, 60 and 80 M (million of reads) based in the reference genomes and abundances of the following samples:</p> <pre><code>SAMEA2466916 SAMEA2466953 SAMEA2466965 SAMEA2621107 SAMEA2621229 SAMEA2621247</code></pre> <p>To convert them from the CRAM format back to fastq files:</p> <pre><code> ## 1. converting from cram to bam format: samtools view -b -T refgenome.fa -o file.bam file.cram ## 2. sorting the bam file: samtools sort -n file.bam -o input_sorted.bam # sort reads by identifier-name (-n) ## 3. converting from bam to fastq format: bedtools bamtofastq -i input_sorted.bam -fq output_r1.fastq -fq2 output_r2.fastq </code></pre> <p> </p>
Measuring Software Testability Modulo Test Quality - Replication Package
<p>This repository represents the replication package for the paper <em>Measuring Software Testability Modulo Test Quality</em>.</p> <p>It includes the dataset and the Jupyter Notebook we used for the analysis in our paper.</p>
Appendices of the work "On the perceived relevance of critical internal quality attributes when evolving software features"
<p>Several refactorings performed while evolving software features aim to improve internal quality attributes like cohesion and complexity. Studies show that non-assisted refactorings might worsen, not improve, internal attributes. Current knowledge is scarce on how developers perceive the relevance of critical internal attributes while evolving features. Internal attributes are critical if their measurement assumes anomalous values. This qualitative study investigates the developer's perception on the relevance of critical internal attributes when evolving features. We target six class-level critical attributes: low cohesion, high complexity, high coupling, large hierarchy depth, large hierarchy breadth, and large size. We performed two industry case studies based on online focus group sessions. Developers discussed how much (and why) critical attributes are relevant for adding or enhancing features. We assessed the relevance of critical attributes individually and relatively, reasons behind the relevance of each critical attribute, and interrelations of critical attributes. Low cohesion and high complexity were perceived as very relevant because they often make evolving features hard while tracking failures and adding features. The other critical attributes were perceived as less relevant when reusing code or adopting design patterns. An example of perceived interrelation is high complexity leading to high coupling.</p>
Appendices of the work "On the perceived relevance of critical internal quality attributes when evolving software features"
<p>Several refactorings performed while evolving software features aim to improve internal quality attributes like cohesion and complexity. Studies show that non-assisted refactorings might worsen, not improve, internal attributes. Current knowledge is scarce on how developers perceive the relevance of critical internal attributes while evolving features. Internal attributes are critical if their measurement assumes anomalous values. This qualitative study investigates the developer's perception on the relevance of critical internal attributes when evolving features. We target six class-level critical attributes: low cohesion, high complexity, high coupling, large hierarchy depth, large hierarchy breadth, and large size. We performed two industry case studies based on online focus group sessions. Developers discussed how much (and why) critical attributes are relevant for adding or enhancing features. We assessed the relevance of critical attributes individually and relatively, reasons behind the relevance of each critical attribute, and interrelations of critical attributes. Low cohesion and high complexity were perceived as very relevant because they often make evolving features hard while tracking failures and adding features. The other critical attributes were perceived as less relevant when reusing code or adopting design patterns. An example of perceived interrelation is high complexity leading to high coupling.</p>
Replication Package for "Software Quality Assurance Analytics: Enabling Software Engineers to Reflect on QA Practices" Paper (SCAM 2024)
<p>Welcome to our artifact!<br>In here we provide additional information for you to retrace our steps in the interview analysis.<br>It has the following contents:</p> <ul> <li><code>codebook.xlsx</code>: Our full codebook with our open codes, structured after the axial codes that emerged. <code>codebook-statistics.xlsx</code> lists for each code in which participant's interview it can be found.</li> <li><code>generate-figures</code>: The plain data and scripts used to generate the figures in the paper.</li> <li><code>survey.pdf</code>: An printout of our whole online questionnaire that guided the participants through the pretest-posttest study and the interview.</li> <li><code>survey-answers.xlsx</code>: The complete data for our participants answers in the online survey during the interviews.</li> <li><code>repoinsights-dashboard-software</code>: The code of our prototype repoinsights. As it is under active development, this is not yet documented for replicating the study setup or extending it. Still, we are providing the source code for transparency and will publish a version with comprehensive setup instructions later.</li> </ul>
Software product quality evaluation questionnaire for IoT LCDP&MDE
<p>This dataset contains the questionnaire used to assess the quality of LCDP and MDE tools in line with the ISO/IEC 25010:2011 product quality standard.</p>
Appendices of the work "On the perceived relevance of critical internal quality attributes when evolving software features"
<p><strong>Context:</strong> Several refactorings performed while evolving software features aim to improve internal quality attributes like cohesion and complexity. Studies shows that non-assisted refactorings might worsen, not improve, internal attributes. Current knowledge is scarce on how developers perceive the relevance of critical internal attributes while evolving features. Internal attributes are critical if their measurement assumes anomalous values. <strong>Objective:</strong> This qualitative study aims at revealing the developer's perception on the relevance of critical internal attributes when evolving features. We target six class-level critical attributes: low cohesion, high complexity, high coupling, large hierarchy depth, large hierarchy breadth, and large size. <strong>Method:</strong> We performed two industry case studies based on online focus group sessions. We asked developers to discuss how much (and why) critical attributes are relevant for adding or enhancing features. We assessed the relevance of critical attributes individually and relatively, reasons behind the relevance of each critical attribute, and interrelations of critical attributes. <strong>Results:</strong> Low cohesion and high complexity were perceived as very relevant because they often make evolving features hard while tracking failures and adding features. The other critical attributes were perceived as less relevant when reusing code or adopting design patterns, for instance. Examples of interrelations include large size leads to low cohesion and high complexity leads to high coupling. <strong>Conclusions:</strong> Our findings could be combined with previous results on how refactorings affect quality attributes to assist developers in applying refactorings that may have a practically relevant impact on critical attributes.</p>
Free Open Source Communities Sustainability: Does It Make a Difference in Software Quality?
<p><strong>Context:</strong> Free and Open Source Software (FOSS) communities' ability to stay viable and productive over time is pivotal for society as they maintain the building blocks that digital infrastructure, products, and services depend on. Sustainability may, however, be characterized from multiple aspects, and less is known how these aspects interplay and impact community outputs, and software quality specifically.</p> <p><strong>Objective: </strong>This study, therefore, aims to empirically explore how the different aspects of FOSS sustainability impact software quality.</p> <p><strong>Method: </strong>16 sustainability metrics across four categories were sampled and applied to a set of 217 OSS projects sourced from the Apache Software Foundation Incubator program. The impact of a decline in the sustainability metrics was analyzed against eight software quality metrics using Bayesian data analysis, which incorporates probability distributions to represent the regression coefficients and intercepts.</p> <p><strong>Results: </strong>Findings suggest that selected sustainability metrics do not significantly affect defect density or code coverage. However, a positive impact of community age was observed on specific code quality metrics, such as risk complexity, number of very large files, and code duplication percentage. Interestingly, findings show that even when communities are experiencing sustainability, certain code quality metrics are negatively impacted.</p> <p><strong>Conclusion:</strong> Findings imply that code quality practices are not consistently linked to sustainability, and defect management and prevention may be prioritized over the former. Results suggest that growth, resulting in a more complex and large codebase, combined with a probable lack of understanding of code quality standards, may explain the degradation in certain aspects of code quality.</p>
Quality and Success in Open Source Software: A Systematic Mapping
<p>Reference_List.pdf includes all of the articles that is related with the study, "Quality and Success in Open Source Software: A Systematic Mapping".</p> <p>Reference_List2.pdf includes one part of Reference_List (37 articles) and all of the articles that included in the study, "A Review on the Relation of Quality and Success in Open Source Software".</p>
Quality Assurance Awareness in Open Source Software Projects on GitHub Analysis Dataset
<p>Dataset for the paper "Quality Assurance Awareness in Open Source Software Projects on GitHub", submitted to the 23rd IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM), 2023.</p>
Software Product Quality Evaluation Guide for Electronic Health Record Systems
<p>Apresentação do artigo "Software Product Quality Evaluation Guide for Electronic Health Record Systems".</p> <p>SBES 2020 - Trilha de Ideias Inovadoras e Resultados Emergentes.</p>
Quality Evaluation Models or Frameworks for Open Source Software: A Systematic Literature Review (Article Pool)
<p>This pdf includes all of the articles that analyzed in the study: "Quality Evaluation Models or Frameworks for Open Source Software: A Systematic Literature Review".</p>
Software Evolution and Quality Data from Controlled, Multiple, Industrial Case Studies
<p>This data was obtained from a controlled, multiple case study involving six professional developers and four real-life, industrial systems. The study was designed to control for the moderator factors: programmer skill, maintenance task and learning effect. The primary data set contains multiple sets of defects, in the form of reports (excel files) extracted from six issue tracking systems. The secondary data consists of a series of attributes extracted from the software systems (i.e., code smells) and their evolution (i.e., code churn), and a log specifying the dates on which developers worked on each of the systems/tasks, in the form of excel files. Details on the controlled, multiple case study can be found in the doctoral dissertation by Yamashita titled: "Assessing the Capability of Code Smells to Support Software Maintainability Assessments: Empirical Inquiry and Methodological Approach" (online) Available at: https://www.duo.uio.no/handle/10852/34525</p>
Autorepairability: A New Software Quality Characteristic
<p>A dataset for the SANER 2024 ERA track submission titled "Autorepairability: A New Software Quality Characteristic."</p>
Quality Evaluation Models or Frameworks for Open Source Software: A Systematic Literature Review (Matching articles with categories)
<p>This document includes which primary study falls into which category with respect to the RQs in the following study: “Quality Evaluation Models or Frameworks for Open Source Software: A Systematic Literature Review”</p>
Quality Evaluation Models or Frameworks for Open Source Software: A Systematic Literature Review (Matching articles with categories)
<p>This document includes which primary study falls into which category with respect to the RQs in the following study: “Quality Evaluation Models or Frameworks for Open Source Software: A Systematic Literature Review”</p>
Quality Evaluation Models or Frameworks for Open Source Software: A Systematic Literature Review (Matching articles with categories)
<p>This document includes which primary study falls into which category with respect to the RQs in the following study: “Quality Evaluation Models or Frameworks for Open Source Software: A Systematic Literature Review”</p>
How Scrum Adds Value to Achieving Software Quality?
<p>39 interviews with Scrum practitioners on the topic of how Scrum as a method contribute to achieving software quality. Data analysis documentation also available with the dataset. Two validation focus groups transcript also available with the data.</p>
How have views on Software Quality differed over time? Research and practice viewpoints (Replication package)
<p>Theoretical and practical viewpoints on the quality of code snippets.</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.