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.
8
datasets available to search
ShareScore release 0.9.0
Dataset results
8 results for “Software Variability”
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>
Are Neural Bug Detectors Comparable to Software Developers on Variable Misuse Bugs?
<p>Artifact for "Are Neural Bug Detectors Comparable to Software Developers on Variable Misuse Bugs?"</p> <p><strong>Abstract:</strong> </p> <p>Debugging, that is, identifying and fixing bugs in software, is a central part of software development. Developers are therefore often confronted with the task of deciding whether a given code snippet contains a bug, and if yes, where. Recently, data-driven methods have been employed to learn this task of bug detection, resulting (amongst others) in so called neural bug detectors. Neural bug detectors are trained on millions of buggy and correct code snippets.</p> <p>Given the “neural learning” procedure, it seems likely that neu- ral bug detectors – on the specific task of finding bugs – have a performance similar to human software developers. For this work, we set out to substantiate or refute such a hypothesis. We report on the results of an empirical study with over 100 software developers, targeting the comparison of humans and neural bug detectors. As detection task, we chose a specific form of bugs (variable misuse bugs) for which neural bug detectors have recently made significant progress. Our study shows that despite the fact that neural bug detectors see millions of such misuse bugs during training, software developers – when conducting bug detection as a majority decision – are slightly better than neural bug detectors on this class of bugs. Altogether, we find a large overlap in the performance, both for classifying code as buggy and for localizing the buggy line in the code. In comparison to developers, one of the two evaluated neural bug detectors, however, raises a higher number of false alarms in our study.</p> <p><strong>Content:</strong> The artifact includes the following components:</p> <ul> <li> <p><strong>Web UI:</strong> The developer survey was performed online in the browser of the participants. For this, we created a custom web interface tailored for our study task. We included both the implementation of the frontend (website) and backend implementation (buisness logic and database) in this artifact. Therefore, it is not only possible to replicate our survey with same interface and a new group of participants but it is also possible to extend the interface for future studies. </p> </li> <li> <p><strong>Neural bug detectors: </strong>We evaluate the performance of the developers against two neural bug detectors. In this artifact, we include the bug detectors (implementation + trained models) and the evaluation script used for producing our results. Besides the replication of our bug detector evaluation, the detectors can also be used in future projects for detecting variable misuse bugs in Java methods.</p> </li> <li> <p><strong>Analysis scripts</strong>: After collecting the raw results from the developers and neural bug detectors, we performed several analysis to gain insights how developers and bug detectors compare on the variable misuse task. We include all analysis steps in form of Jupyter notebooks in the artifact. With this, it is possible to reproduce all the figures of our paper. </p> </li> </ul> <p>In addition, we also provide further artifacts that were successfully evaluated at ASE 2022:</p> <p><strong>ASE 2022 Artifact: </strong><a href="https://doi.org/10.5281/zenodo.6958242">10.5281/zenodo.6958242</a></p> <p><strong>Virtual machine: </strong><a href="https://doi.org/10.5281/zenodo.6957849">10.5281/zenodo.6957849</a></p>
Software Variability Tools: Industrial Survey and Systematic Mapping Study
<p>Software Variability Tools: Industrial Survey and Systematic Mapping Study</p>
Reuse of Model Transformations for Propagating Variability Annotations in Annotative Software Product Lines - Evaluation Data
<p>This package contains all data that was produced for and used in the doctoral thesis for evaluating commutativity of propagating annotations in model-driven product lines.<br> This includes the implementation that conducts the evaluation, the measured results, and the input subjects.</p>
Software Variability Tools SMS and Survey: List of References and Tools
<p>Software Variability Tools SMS and Survey: List of References and Tools</p>
Comparing the Intensity of Variability Changes in Software Product Line Evolution - Related Research Artifacts
<p>This archived open repository contains open science material related to the following submission to the <a href="https://www.journals.elsevier.com/journal-of-systems-and-software/call-for-papers/software-reuse-for-the-next-generation">Journal of Systems and Software (JSS) special issue <em>Software Reuse for the Next Generation</em></a>:</p> <p>C. Kröher, L. Gerling, K. Schmid, <em>Comparing the intensity of variability changes in software product line evolution</em>, Journal of Systems and Software. Submitted November 2022.</p> <p>The paper presents the application of a fine-grained, variability-centric analysis approach to four different software product lines: <a href="https://github.com/torvalds/linux">Linux kernel</a>, <a href="https://github.com/coreboot/coreboot">coreboot firmware</a>, <a href="https://github.com/mirror/busybox">BusyBox UNIX utilities</a>, and <a href="https://sourceforge.net/projects/axtls/">axTLS embedded SSL</a>. The approach is based on the differentiation between artifact-specific and variability information in code, build, and variability model artifacts to identify the intensity (the frequency and the amount) with which developers change variability information in practice.</p> <p>In order to complement the results presented in the submission and support reproducibility as well as reuse, the following artifacts are available:</p> <ul> <li><strong>JSS-VM_2022-11-01.zip</strong>: a compressed archive containing the virtual machine in which the analysis was executed. This virtual machine was created with <a href="https://www.vmware.com/content/vmware/vmware-published-sites/us/products/workstation-player/workstation-player-evaluation.html.html">VMware Workstation 16 Player</a> based on <a href="https://ubuntu.com/download/desktop">Ubuntu Desktop 22.04.1</a> (username and password: jss). It provides all installed software, configuration files, data sets, and results as described in the submission. Download, extract, and start the virtual machine to access the detailed description of its content and usage on the desktop.</li> <li><strong>ComAnI-Applications.zip</strong>: a compressed archive containing the technical realization of the analysis approach and the configuration files used to apply it to the individual software product lines. This includes: <ul> <li><em>ComAnI_Guide.pdf</em>: the guide explaining the application and its usage in general</li> <li><em>ComAnI.jar</em>: the Java executable archive file representing the main application for starting an analysis</li> <li><em>ComAnI-PS.jar</em>: a modified version of the previous Java executable archive file, which provides the number of code, build, and variability model artifacts as specified by the regular expressions of a given configuration file as well as their total number of lines based on the current state of a repository only (no history)</li> <li><em>DeadCodeChangeAnalyzer.jar</em>: a commit analyzer plug-in for detecting changes relevant to dead code detection (not used in the submission)</li> <li><em>GitCommitExtractor.jar</em>: a commit extraction plug-in for extracting commits from Git repositories</li> <li><em>SvnCommitExtractor.jar</em>: a commit extraction plug-in for extracting commits from Subversion (SVN) repositories</li> <li><em>VariabilityChangeAnalyzer.jar</em>: a commit analyzer plug-in for detecting changes to artifact-specific and variability information in code, build, and variability model artifacts (realization of the commit analysis process described in the submission)</li> <li><em>busybox-commit-list</em>: a plain text file containing a subset of the BusyBox commits as required by the application to extract and analyze only those parts of its entire history relevant for the submission (quote from the submission: <em>"For BusyBox, we had to further exclude commits before the complete migration to Kbuild and after the introduction of a script for extracting variability model information from code artifacts, which initiated defining variability information of the variability model as part of comments in code artifacts. This mixing of information and artifact types is not supported by our tooling"</em>)</li> <li><em>axtls.properties</em>: the configuration (file) defining the required properties for extracting and analyzing commits of the axTLS history</li> <li><em>busybox.properties</em>: the configuration (file) defining the required properties for extracting and analyzing all commits of the BusyBox history</li> <li><em>busybox-subset.properties</em>: the configuration (file) defining the required properties for extracting and analyzing the commits specified in the busybox-commit-list file only, resulting in the respective subset of the BusyBox history</li> <li><em>coreboot.properties</em>: the configuration (file) defining the required properties for extracting and analyzing all commits of the coreboot history</li> <li><em>linux.properties</em>: the configuration (file) defining the required properties for extracting and analyzing all commits of the Linux kernel history</li> <li><em>template.properties</em>: the configuration (file) template including descriptions of each property and its valid values</li> </ul> </li> <li><strong>ComAnI-Results.zip</strong>: a compressed archive containing the (raw) analysis results from applying the approach via its realization as provided by the previous archive to each of the software product lines. Hence, for each subject, a directory with the respective name exist, which in turn contains the following artifacts: <ul> <li><em>VariabilityChangeAnalyzer-Results_2022-09-[…]</em>: the directory containing the respective analysis results and some automated visualizations. Please note that some files are not correctly labeled, .e.g. some files for axTLS and BusyBox are prefixed with "coreboot", while containing the correct data for the respective subjects. Further, for BusyBox, two directories exist, which the additional readme-file explains</li> <li><em>project-size-trace.txt</em>: the complete trace from starting ComAnI-PS.jar (see description above) with a specific configuration file to its final output</li> </ul> </li> <li><strong>JSS23_Extended-Evolution-Analysis_Statistics.ods</strong>: a <a href="https://www.libreoffice.org/discover/calc/">LibreOffice Calc</a> spreadsheet containing data derived from the raw ones of the ComAnI-Results.zip and the respective visualizations as presented in the submission. Further, some sheets include additional data preparations used to write certain parts of the result and discussion sections.</li> </ul> <p>The additional <strong>LICENSE</strong> file defines <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License Version 2.0, January 2004</a> to apply for all artifacts in this repository.</p> <p>This work is partially supported by the Evoline project, funded by the DFG (German Research Foundation) under Priority Programme SPP 1593 and by the ITEA3 project REVaMP², funded by the BMBF (German Ministry of Research and Education) under grant 01IS16042H. Any opinions expressed herein are solely by the authors and not of the DFG or BMBF.</p>
Enhanced Accounting for Item Cost Variability in AASHTOWare Project Software Dataset
Open the record for dataset details and reuse information.
Data and software for "Multi-scale variability of turbulent mixing during a Monsoon Intraseasonal Oscillation in the Bay of Bengal: an LES study"
<p>LES data outputs</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.