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.
14
datasets available to search
ShareScore release 0.9.0
Dataset results
14 results for “software maintenance”
1151 commits with software maintenance activity labels (corrective,perfective,adaptive)
<p>Data format: CSV</p> <p>Separator character: '#'</p> <p><strong>This dataset contains 1151 commits manually labeled with maintenance activities ("c" for corrective, "p" for perfective, "a" for adaptive)</strong> according to the definition by Mockus et al. in <em>"Mockus, A. and Votta, L.G., 2000, October. Identifying Reasons for Software Changes using Historic Databases. In icsm (pp. 120-130)"</em>.</p> <p>In addition, this dataset also contains <strong>further information (features) extracted from the commits</strong>:</p> <ol> <li>The <strong>source code changes</strong> performed by the commit author as part of a given commit (statement added, statement removed, etc.) <ul> <li>The source code change taxonomy is detailed in <em>"Fluri, B. and Gall, H.C., 2006, June. Classifying change types for qualifying change couplings. In Program Comprehension, 2006. ICPC 2006. 14th IEEE International Conference on (pp. 35-45). IEEE."</em></li> </ul> </li> <li>A binary indication (1/0) whether a given commit contains any of the <strong>keywords from a pre-computed </strong>(according to a word frequency analysis)<strong> set of keywords</strong> <strong>indicative of each maintenance activity</strong>.</li> </ol> <p>The dataset consists of commits sampled from the following open source projects:</p> <ol> <li>RxJava</li> <li>hbase</li> <li>elasticsearch</li> <li>intellij-community</li> <li>hadoop</li> <li>drools</li> <li>kotlin</li> <li>restlet-framework-java</li> <li>orientdb</li> <li>camel</li> <li>spring-framework </li> </ol> <p>This dataset is a supporting material for the paper <strong>"Boosting Automatic Commit Classification Into Maintenance Activities By Utilizing Source Code Changes", to appear in PROMISE 2017.</strong></p>
Dataset and Software for Abstraction Materialization Maintenance
<p>Abstraction Refinement is a technique which allows for reducing materialization of an ontology with a large ABox to materialization of a smaller (compressed) `abstraction' of this ontology. The corresponding conference paper shows how Abstraction Refinement can be adopted for incremental ABox materialization by combining it with the well-known DRed algorithm for materialization maintenance. The combination is non-trivial and to preserve correctness, already Horn ALCHI requires more complex abstractions. Nevertheless, significant benefits can be obtained for synthetic and real-world ontologies. This data set contains the source code for the implementation as well as the used test data and test runners to reproduce the results reported in the paper.</p>
Supplementary materials of the paper entitled: "Metamorphic Testing Meets Regression Testing: A Case Study of Scientific Software Maintenance"
<p>Supplementary materials of the paper entitled:</p> <p>“Metamorphic Testing Meets Regression Testing: A Case Study of Scientific Software Maintenance”</p> <p>file01 - source code for detecting and comparing output relations of a given metamorphic relation<br> file02 - interview transcripts and qualitative coding results<br> file03 - system script for compiling SWMM, creating sSWMM simulation outputs, and logging execution time<br> file04 - source code for SWMM 5.1.014<br> file05 - source code for SWMM 5.1.015<br> file06 - a suite of 40 regression tests (40 .inp files)<br> file07 - result table for 760 cases (19 MRs × 40 .inp files)<br> file08 - 491 automatically generated follow-up .inp files via reuse<br> file09 - result table for mutation analysis<br> file10 - output files for mutation analysis with metamorphic testing:<br> a. Original source output<br> b. Original follow-up output<br> c. Mutant source output<br> d. Mutant follow-up output</p>
359,569 commits with source code density; 1149 commits of which have software maintenance activity labels (adaptive, corrective, perfective)
<p>This dataset comes as SQL-importable file and is compatible with the widely available MariaDB- and MySQL-databases.</p> <p>It is based on (and incorporates/extends) the dataset "<em>1151 commits with software maintenance activity labels (corrective,perfective,adaptive)</em>" by Levin and Yehudai (<a href="https://doi.org/10.5281/zenodo.835534">https://doi.org/10.5281/zenodo.835534</a>).</p> <p>The extensions to this dataset were obtained using <em>Git-Tools</em>, a tool that is included in the <strong>Git-Density</strong> (<a href="https://doi.org/10.5281/zenodo.2565238">https://doi.org/10.5281/zenodo.2565238</a>) suite. For each of the projects in the original dataset, Git-Tools was run in <em>extended</em> mode.</p> <p>The dataset contains these tables:</p> <ul> <li><strong>x1151</strong>: The original dataset from Levin and Yehudai. <ul> <li>despite its name, this dataset has only 1,149 commits, as two commits were duplicates in the original dataset.</li> <li>This dataset spanned 11 projects, each of which had between 99 and 114 commits</li> <li>This dataset has <strong>71</strong> features and spans the projects <em>RxJava, hbase, elasticsearch, intellij-community, hadoop, drools, Kotlin, restlet-framework-java, orientdb, camel</em> and <em>spring-framework</em>.</li> </ul> </li> <li><strong>gtools_ex</strong> (short for <em>Git-Tools, extended</em>) <ul> <li>Contains <strong>359,569</strong> commits, analyzed using Git-Tools in extended mode</li> <li>It spans all commits and projects from the x1151 dataset as well.</li> <li>All 11 projects were analyzed, from the initial commit until the end of January 2019. For the projects <em>Intellij</em> and <em>Kotlin</em>, the first 35,000 resp. 30,000 commits were analyzed.</li> <li>This dataset introduces <strong>35 new</strong> features (see list below), 22 of which are <em><strong>size</strong></em>- or <em><strong>density</strong></em>-related.</li> </ul> </li> </ul> <p>The dataset contains these views:</p> <ul> <li><strong>geX_L</strong> (short for Git-<em>tools, extended, with labels</em>) <ul> <li>Joins the commits' labels from <em>x1151</em> with the extended attributes from <em>gtools_ex</em>, using the commits' hashes.</li> </ul> </li> <li><strong>jeX_L</strong> (short for <em>joined, extended, with labels</em>) <ul> <li>Joins the datasets <em>x1151</em> and <em>gtools_ex</em> entirely, based on the commits' hashes.</li> </ul> </li> </ul> <p> </p> <p>Features of the <strong>gtools_ex</strong> dataset:</p> <ul> <li><strong>SHA1</strong></li> <li><strong>RepoPathOrUrl</strong></li> <li><strong>AuthorName</strong></li> <li><strong>CommitterName</strong></li> <li><strong>AuthorTime </strong>(UTC)</li> <li><strong>CommitterTime </strong>(UTC)</li> <li><strong>MinutesSincePreviousCommit</strong>: Double, describing the amount of minutes that passed since the previous commit. Previous refers to the <strong>parent</strong> commit, not the previous in time.</li> <li><strong>Message</strong>: The commit's message/comment</li> <li><strong>AuthorEmail</strong></li> <li><strong>CommitterEmail</strong></li> <li><strong>AuthorNominalLabel</strong>: All authors of a repository are analyzed and merged by Git-Density using some heuristic, even if they do not always use the same email address or name. This label is a unique string that helps identifying the same author across commits, even if the author did not always use the exact same identity.</li> <li><strong>CommitterNominalLabel</strong>: The same as <em>AuthorNominalLabel</em>, but for the committer this time.</li> <li><strong>IsInitialCommit</strong>: A boolean indicating, whether a commit is preceded by a parent or not.</li> <li><strong>IsMergeCommit</strong>: A boolean indicating whether a commit has more than one parent.</li> <li><strong>NumberOfParentCommits</strong></li> <li><strong>ParentCommitSHA1s</strong>: A comma-concatenated string of the parents' SHA1 IDs</li> <li><strong>NumberOfFilesAdded</strong></li> <li><strong>NumberOfFilesAddedNet</strong>: Like the previous property, but if the net-size of all changes of an added file is zero (i.e. when adding a file that is empty/whitespace or does not contain code), then this property does not count the file.</li> <li><strong>NumberOfLinesAddedByAddedFiles</strong></li> <li><strong>NumberOfLinesAddedByAddedFilesNet</strong>: Like the previous property, but counts the net-lines</li> <li><strong>NumberOfFilesDeleted</strong></li> <li><strong>NumberOfFilesDeletedNet</strong>: Like the previous property, but considers only files that had net-changes</li> <li><strong>NumberOfLinesDeletedByDeletedFiles</strong></li> <li><strong>NumberOfLinesDeletedByDeletedFilesNet</strong>: Like the previous property, but counts the net-lines</li> <li><strong>NumberOfFilesModified</strong></li> <li><strong>NumberOfFilesModifiedNet</strong>: Like the previous property, but considers only files that had net-changes</li> <li><strong>NumberOfFilesRenamed</strong></li> <li><strong>NumberOfFilesRenamedNet</strong>: Like the previous property, but considers only files that had net-changes</li> <li><strong>NumberOfLinesAddedByModifiedFiles</strong></li> <li><strong>NumberOfLinesAddedByModifiedFilesNet</strong>: Like the previous property, but counts the net-lines</li> <li><strong>NumberOfLinesDeletedByModifiedFiles</strong></li> <li><strong>NumberOfLinesDeletedByModifiedFilesNet</strong>: Like the previous property, but counts the net-lines</li> <li><strong>NumberOfLinesAddedByRenamedFiles</strong></li> <li><strong>NumberOfLinesAddedByRenamedFilesNet</strong>: Like the previous property, but counts the net-lines</li> <li><strong>NumberOfLinesDeletedByRenamedFiles</strong></li> <li><strong>NumberOfLinesDeletedByRenamedFilesNet</strong>: Like the previous property, but counts the net-lines</li> <li><strong>Density</strong>: The ratio between the two sums of all lines added+deleted+modified+renamed and their resp. gross-version. A density of zero means that the sum of net-lines is zero (i.e. all lines changes were just whitespace, comments etc.). A density of of 1 means that all changed net-lines contribute to the gross-size of the commit (i.e. no useless lines with e.g. only comments or whitespace).</li> <li><strong>AffectedFilesRatioNet</strong>: The ratio between the sums of <em>NumberOfFilesXXX</em> and <em>NumberOfFilesXXXNet</em></li> </ul> <p> </p> <p>This dataset is supporting the paper <strong>"<em>Importance and Aptitude of Source code Density for Commit Classification into Maintenance Activities</em></strong><strong>"</strong>, as submitted to the <em>QRS2019</em> conference (The 19th IEEE International Conference on Software Quality, Reliability, and Security). Citation: Hönel, S., Ericsson, M., Löwe, W. and Wingkvist, A., 2019. Importance and Aptitude of Source code Density for Commit Classification into Maintenance Activities. In <em>The 19th IEEE International Conference on Software Quality, Reliability, and Security</em>.</p>
Software maintenance meetings: Guide, codebook, and excerpts
<p>A type of meeting that has been understudied in the software engineering literature to date is what we term the software maintenance meeting: a regularly scheduled team meeting in which emergent issues are addressed that are usually out of scope of the daily standup but not necessarily challenging enough to warrant an entirely separate meeting. This dataset includes the guidelines and codebook used to analyze a set of ten meetings of this kind. It also includes excerpts from the video transcripts that were analyzed as part of the study. These excerpts illustrate the nature of the meetings.</p>
Software maintenance meetings: Guide, codebook, and excerpts
Open the record for dataset details and reuse information.
Refactoring Code Smells in Open Source Projects: A Hands-on Approach to Teaching Software Maintenance
<p>Code smells are suboptimal code structures that can undermine software quality and maintainability. On the one hand, software engineers commonly apply refactoring techniques to address these deficiencies and improve internal quality attributes. On the other hand, when performed manually and without discipline, refactoring can lead to code degradation. Despite its importance, refactoring and code smells are rarely explored in depth in undergraduate computing courses, which can be reflected in industry practices. To address this gap, this paper presents a hands-on approach to teaching code smell refactoring through contributions to Open Source Software (OSS) projects, an environment where developers with diverse skill levels collaborate, and maintaining code quality is particularly challenging. Code smells accumulate over time in such scenarios, hindering software evolution and collaboration. Our study in two undergraduate Software Quality and Software Maintenance courses expands on previous findings by incorporating an in-depth analysis of students’ learning experiences. The results indicate that: (i) students rec- ognized improvements in code quality after refactoring; (ii) they identified strong connections between refactoring, testing, and debugging; (iii) their confidence decreased when refactoring required changes across multiple files; (iv) code complexity posed a significant challenge to refactoring; (v) students’ choices of refactoring techniques were influenced by project structure and personal preferences, often combining multiple techniques to address a single smell; (vi) in some cases, refactoring introduced new code smells; (vii) the longest refactoring efforts were also the most likely to reintroduce code smells; (viii) contributing to OSS projects improved students’ programming skills and fostered a sense of professional growth; (ix) students faced challenges in understanding OSS contribution processes, particularly regarding issue resolution, adherence to contribution guidelines, and responding to maintainer feedback; (x) automated checks and review workflows varied across projects, affecting students’ ability to submit successful contributions; and (xi) despite these challenges, engagement with OSS enabled students to gain practical experience in collaborative software development. Our findings offer valuable insights for software engineering educators seeking to integrate refactoring practices into coursework while leveraging OSS contributions as an educational tool.</p>
Towards Identifying Python Proficiency to Foster Software Maintenance and Evolution
Open the record for dataset details and reuse information.
Supporting Software Maintenance with Dynamically Generated Document Hierarchies
Open the record for dataset details and reuse information.
Empirical Data from a Longitudinal Software Maintenance Experiment
<p>This dataset contains IDE interaction traces (logs) and screen videos obtained from a comprehensive study conducted to understand in detail how software professionals plan and execute maintenance activities on real-life software.</p>
Supplementary Material - Dataset for "Automating Quantum Software Maintenance: Flakiness Detection and Root Cause Analysis"
<h2>README</h2> <p>The dataset consists of the following components:<br> <br>- `<strong>prompts.txt</strong>`: This file contains the prompts used for large language models.<br> <br>- `<strong>Dataset</strong>` directory: includes general information about the dataset. Specifically, the `dataset.xlsx` file lists flaky and non-flaky tests, along with their root causes and fix types.<br> <br>- `<strong>Full</strong>` directory contains two subdirectories: `Flaky` and `Non-flaky`. Each of these directories is organized by individual GitHub organization projects, with each project having its list of repository subdirectories. These subdirectories are further divided into “issues” and “pull requests” (PRs).</p> <p><br>- `<strong>Method</strong>` level subdirectory has a similar structure but contains extracted code snippets at the method level instead of full code listings. The `code.diff` file is copied over and left unaltered. </p> <p><br>- <strong>Issue Directories (IRs):</strong> Named with an `issueID` template, each issue directory contains a `log.issue` file that includes the extracted description, comments, and metadata.<br> <br>- <strong>PR Directories (PRs)</strong>: Named using the `prID` template, each PR directory contains the text, comments, and metadata in the `pr.log` file. The text of the associated issue is stored in the `log.issue` file. Code listings are stored in a file with the `.bug` suffix, while the corresponding fixed version is in a `.fix` file. The `code.diff` file contains the patch that transforms the `.bug` version into the `.fix` version.</p> <p><br><strong>Additional notes:</strong><br>Issues with associated pull requests in `dataset.xlsx` are combined into the pull request directory template. If two pull requests are listed for a row, a PR directory is created for each. Due to updates in the extended dataset, some repositories have been renamed or archived, meaning the current repository directory names in `Dataset` will include both the previous and new names if it has been changed (e.g., a repository previously saved as Qiskit/qiskit-terra may now be saved as Qiskit/qiskit following the renaming from qiskit-terra to qiskit).</p> <h2>Directory Structure:</h2> <p><br>├── prompts.txt<br>├── Dataset/<br> └── dataset.xlsx<br>├── Full/<br> ├── Flaky/<br> └── <Organization>/<Repository>/...<br> ├── Non-Flaky/<br> └── <Organization>/<Repository>/...<br>├── Method/<br> ├── Flaky/<br> └── <Organization>/<Repository>/...<br> ├── Non-flaky/<br> └── <Organization>/<Repository>/...</p> <p> </p>
Supporting Software Maintenance with Dynamically Generated Document Hierarchies (Supplemental)
<p>Supplemental materials for submission to ICSME 24 titled "<span>Supporting Software Maintenance with </span><span>Dynamically Generated Document Hierarchies"</span></p>
Supplementary materials of the paper entitled: "Metamorphic Testing Meets Regression Testing: A Case Study of Scientific Software Maintenance"
<p>Supplementary materials of the paper entitled: “Metamorphic Testing Meets Regression Testing: A Case Study of Scientific Software Maintenance”</p> <p>file01 - source code for detecting and comparing output relations of a given metamorphic relation<br> file02 - system script for compiling SWMM, creating sSWMM simulation outputs, and logging execution time<br> file03 - source code for SWMM 5.1.014<br> file04 - source code for SWMM 5.1.015<br> file05 - a suite of 40 regression tests (40 .inp files)<br> file06 - result table for 760 cases (19 MRs × 40 .inp files)<br> file07 - 491 automatically generated follow-up .inp files via reuse<br> file08 - result table for mutation analysis<br> file09 - source code for three open-source software systems<br> File10 - code change in three open-source software systems</p>
Supplementary Material - Dataset for "Automating Quantum Software Maintenance: Flakiness Detection and Root Cause Analysis"
Open the record for dataset details and reuse information.
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.