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.
20
datasets available to search
ShareScore release 0.9.0
Dataset results
20 results for “Software Metrics”
Examining the Capacity of Text Mining and Software Metrics in Vulnerability Prediction [dataset]
<p>This dataset contains the extension of a publicly available dataset that was published initially by Ferenc et al. in their paper:</p> <p><em>“Ferenc, R.; Hegedus, P.; Gyimesi, P.; Antal, G.; Bán, D.; Gyimóthy, T. Challenging machine learning algorithms in predicting vulnerable javascript functions. 2019 IEEE/ACM 7th InternationalWorkshop on Realizing Artificial Intelligence Synergies in Software Engineering (RAISE). IEEE, 2019, pp. 8–14.”</em></p> <p>The dataset contained software metrics for source code functions written in JavaScript (JS) programming language. Each function was labeled as vulnerable or clean. The authors gathered vulnerabilities from publicly available vulnerability databases.</p> <p>In our paper entitled: “<strong>Examining the Capacity of Text Mining and Software Metrics in Vulnerability Prediction</strong>” and cited as:</p> <p><em>“Kalouptsoglou I, Siavvas M, Kehagias D, Chatzigeorgiou A, Ampatzoglou A. Examining the Capacity of Text Mining and Software Metrics in Vulnerability Prediction. Entropy. 2022; 24(5):651. <a href="https://doi.org/10.3390/e24050651">https://doi.org/10.3390/e24050651</a>”</em></p> <p>, we presented an extended version of the dataset by extracting textual features for the labeled JS functions. In particular, we got the dataset provided by Ferenc et al. in CSV format and then we gathered all the GitHub URLs of the dataset's functions (i.e., methods). Using these URLs, we collected the source code of the corresponding JS files from GitHub. Subsequently, by utilizing the start and end line information for every function, we cut off the code of the functions. Each function was then tokenized to construct a list of tokens per function.</p> <p>To extract text features, we used a text mining technique called sequences of tokens. As a result, we created a repository with all methods' source code, the token sequences of each method, and their labels. To boost the generalizability of type-specific tokens, all comments were eliminated, as well as all integers and strings, which were replaced with two unique IDs.</p> <p>The dataset contains 12,106 JavaScript functions, from which 1,493 are considered vulnerable.</p> <p>This dataset was created and utilized during the Vulnerability Prediction Task of the Horizon2020 IoTAC Project as training and evaluation data for the construction of vulnerability prediction models. The dataset is provided in the csv format. Each row of the csv file has the following parts:</p> <ul> <li>Label: Flag with values ‘1’ for vulnerable and ‘0’ for non-vulnerable methods</li> <li>Name: The name of the JavaScript method</li> <li>Longname: The longname of the JavaScript method</li> <li>Path: The path of the file of the method in the repository</li> <li>Full_repo_path: The GitHub URL of the file of the method</li> <li>TokenX: Each next row corresponds to each token included in the method</li> </ul>
Dataset of Open-Source Software Developers Labeled by their Experience Level and Associated with their Software Metrics
<p>This dataset contains 703 anonymized developers extracted from 17 open-source projects from GitHub. Projects were chosen because they use:</p> <ul> <li>the Java programming language</li> <li>the <a href="https://spring.io/projects/spring-framework">Spring framework</a></li> <li><a href="https://maven.apache.org/">Maven</a> / <a href="https://gradle.org/">Gradle</a> build tools</li> </ul> <p>For all these developers, 23 software metrics were calculated for each project to which they contribute. These metrics are either calculated by analyzing the source code or relative to project management metadata. Each of these developers then have been manually annotated. To do this, developers have been searched for in professionnal social media such as:</p> <ul> <li><a href="https://www.linkedin.com/">Linkedin</a></li> <li><a href="https://twitter.com/">Twitter</a></li> <li><a href="https://github.com/">Github</a></li> </ul> <p><strong>This dataset is published in the following journal article: </strong></p> <p><strong>Dataset of Open-Source Software Developers Labeled by their Experience Level in the Project and their Associated Software Metrics, Q. Perez, C. Urtado and </strong><strong>S. Vauttier, Data In Brief, </strong></p> <p><a href="https://www.sciencedirect.com/science/article/pii/S2352340922010459">https://www.sciencedirect.com/science/article/pii/S2352340922010459</a></p>
Aging-related bugs and software complexity metrics
<p>This dataset contains information on aging-related bugs found in two open-source projects (the Linux kernel and the MySQL DBMS). This dataset has been used to investigate defect prediction approaches for aging-related bugs, by using software complexity metrics and machine learning techniques. New software complexity metrics were proposed in this study to support defect prediction ("aging-related" metrics).</p> <p>The dataset contains an ARFF file for each subsystem of the open-source projects. Each row of the ARFF file contains:</p> <p>- The name of a file in the project;</p> <p>- "Program size" metrics for the file (columns from 2 to 50);</p> <p>- "McCabe's cyclomatic complexity" metrics for the file (columns from 51 to 68);</p> <p>- "Halstead" metrics for the file (columns from 69 to 77);</p> <p>- "Aging-related" metrics for the file (columns from 78 to 83);</p> <p>- The number of aging-related bugs found in the file.<br> </p>
Towards Developing and Analysing The Metric-Based Software Defect Severity Prediction Model
<p>This is a metric based approach to solve software defect severity prediction problem. In addition to that, this work proposes a new evaluation scheme that comprised of five metrics to analyze the performances.</p>
What if Smart Contracts Could Whisper their Weaknesses: From Software Metrics to Vulnerability Classification
<p>This repository contains the code and data associated with our submission to FSE 2025, entitled 'What if Smart Contracts Could Whisper their Weaknesses: From Software Metrics to Vulnerability Classification'. If the paper is accepted for publication, the authors' information and affiliations will be made publicly available in accordance with the conference proceedings.</p>
Towards Understanding the Impact of Code Modifications on Software Quality Metrics
<p>The provided dataset contains the data used by "Towards Understanding the Impact of Code Modifications on Software Quality Metrics", in order to examine the impact of code changes in software quality metrics and identify types of code changes with similar impact and the results obtained.</p>
Analyzing Static Analysis Metric Trends towards Early Identification of Non-Maintainable Software Components
<p>The provided dataset contains the data used by "Analyzing Static Analysis Metric Trends towards Early Identification of Non-Maintainable Software Components", in order to evaluate the maintainability degree of a software class and identify software components that will eventually become non-maintainable.</p>
Proof of Concept database with inputs and outputs of the Master thesis: Analyzing Software Delivery Performance behavior in popular Open Source Software Projects on a Release timeline basis through delivery metrics
<p>The software has become one of the main assets to deliver services today. Thus, software delivery has been dealing with a competitive and dynamic environment where the demand for faster and more assertive deliverables, called here Releases, only increases. Agile development methods emerged helping to accelerate software delivery, embracing industry and open source community. Since then, the software delivery frequency has expanded and improved bringing more adopters of rapid release cycles to reduce their time-to-market. However, using only rapid releases can not be enough as measuring software delivery can answer essential questions, like how software delivery is happening and how it should be. Some approaches for measuring software delivery appeared such as Software Delivery Performance (SDP) where software delivery is measured as a consequence of capabilities evolution. Popularity in Open Source Software Projects (OSSP) means that a project is mature enough in the community to fit the software demand and, therefore, is likely to be ready to be measured through a software delivery approach like SDP. In light of it, this work offers means to analyze SDP behavior in popular Open Source Software Projects on a Release timeline basis through delivery metrics. The results demonstrated that popularity is efficient filtering, as it improves the OSSP delivery, supporting the work's reliability and accuracy. The source code and methodology are published as a replication package to encourage reproducibility and future research.</p>
Qualisign: Software Metrics and GoF Design Patterns of the Maven Central Repository
<p>This dataset contains software metric and design pattern data for around 100,000 projects from the Maven Central repository. The data was collected and analyzed as part of my master's thesis "Mining Software Repositories for the Effects of Design Patterns on Software Quality" (https://www.overleaf.com/read/vnfhydqxmpvx, https://zenodo.org/record/4048275).</p> <p>The included qualisign.* files all contain the same data in different formats:<br> - qualisign.sql: standard SQL format (exported using "pg_dump --inserts ..."),<br> - qualisign.psql: PostgreSQL plain format (exported using "pg_dump -Fp ..."),<br> - qualisign.csql: PostgreSQL custom format (exported using "pg_dump -Fc ...").</p> <p>create-tables.sql has to be executed before importing one of the qualisign.* files. Once qualisign.*sql has been imported, create-views.sql can be executed to preprocess the data, thereby creating materialized views that are more appropriate for data analysis purposes.</p> <p>---</p> <p>Software metrics were calculated using CKJM extended:<br> http://gromit.iiar.pwr.wroc.pl/p_inf/ckjm/</p> <p>Included software metrics are (21 total):<br> - AMC: Average Method Complexity<br> - CA: Afferent Coupling<br> - CAM: Cohesion Among Methods<br> - CBM: Coupling Between Methods<br> - CBO: Coupling Between Objects<br> - CC: Cyclomatic Complexity<br> - CE: Efferent Coupling<br> - DAM: Data Access Metric<br> - DIT: Depth of Inheritance Tree<br> - IC: Inheritance Coupling<br> - LCOM: Lack of Cohesion of Methods (Chidamber and Kemerer)<br> - LCOM3: Lack of Cohesion of Methods (Constantine and Graham)<br> - LOC: Lines of Code<br> - MFA: Measure of Functional Abstraction<br> - MOA: Measure of Aggregation<br> - NOC: Number of Children<br> - NOM: Number of Methods<br> - NOP: Number of Polymorphic Methods<br> - NPM: Number of Public Methods<br> - RFC: Response for Class<br> - WMC: Weighted Methods per Class</p> <p>In the qualisign.* data, these metrics are only available on the class level. create-views.sql additionally provides averages of these metrics on the package and project levels.</p> <p>---</p> <p>Design patterns were detected using SSA:<br> https://users.encs.concordia.ca/~nikolaos/pattern_detection.html</p> <p>Included design patterns are (15 total):<br> - Adapter<br> - Bridge<br> - Chain of Responsibility<br> - Command<br> - Composite<br> - Decorator<br> - Factory Method<br> - Observer<br> - Prototype<br> - Proxy<br> - Singleton<br> - State<br> - Strategy<br> - Template Method<br> - Visitor</p> <p>---</p> <p>The code to generate the dataset is available at:<br> https://github.com/jaichberg/qualisign</p> <p>The code to perform quality analysis on the dataset is available at:<br> https://github.com/jaichberg/qualisign-analysis</p>
A Stable Software Architecture Modularity Metric
<p>Anonymous Replication Package for A Stable Software Architecture Modularity Metric</p>
Temporal validity of software datasets for code metrics: an empirical assessment of sampling strategies
<p>This is the repository for the scripts and data of the study "Building and updating software datasets: an empirical assessment".</p> <h2>Data collected</h2> <p>The data generated for the study it can be downloaded as a zip file. Each folder inside the file corresponds to one of the datasets of projects employed in the study (qualitas, currentSample and qualitasUpdated). Every dataset comprised three files "class.csv", "method.csv" and "sample.csv", with class metrics, method metrics and repository metadata of the projects respectively. Here is a description of the datasets:</p> <ul> <li>qualitas: includes code metrics and repository metrics from the projects in the release 20130901r of the Qualitas Corpus.</li> <li>currentSample: includes code metrics and repository metrics from a recent sample collected with our sampling procedure.</li> <li>qualitasUpdated: includes code metrics and repository metrics from an updated version of the Qualitas Corpus applying our maintenance procedure.</li> </ul> <h2>Plot graphics</h2> <p>To plot the results and graphics in the article there is a Jupyter Notebook "Experiment.ipynb". It is initially configured to use the data in "datasets" folder.</p> <h2>Replication Kit</h2> <p>For replication purposes, the datasets containing recent projects from Github can be re-generated. To do so, the virtual environment must have installed the dependencies in "requirements.txt" file, add Github's tokens in "./token" file, re-define or leave as is the paths declared in the constants (variables written in caps) in the main method, and finally run "main.py" script. The portable versions of the source code scanner <a href="https://sourcemeter.com/" target="_blank" rel="noopener">Sourcemeter</a> are located as zip files in "./Sourcemeter/tool" directory. To install Sourcemeter the appropriate zip file must be decompressed excluding the root folder "SourceMeter-10.2.0-x64-<OS>".</p> <p>The script comprise 5 steps:</p> <ol> <li>Project retrieval from Github: at first the sampling frame with projects complying with a specific quality criteria are retrieved from Github's API.</li> <li>Create samples: with the sampling frame retrieved, the current samples are selected (currentSample and qualitasUpdated). In the case of qualitasUpdated, it is important to have first the "sample.csv" file inside the qualitas folder of the dataset originally created for the study. This file contains the metadata of the projects in Qualitas Corpus.</li> <li>Project download and analysis: when all the samples are selected from the sampling frame (currentSample and qualitasUpdated), the repositories are downloaded and scanned with SourceMeter. In the cases in which the analysis is not possible, the projects are replaced with another one with similar size.</li> <li>Outlier detection: once the datasets are collected, it is necessary to manually look for possible outliers in the code metrics under study. In the notebook "Experiment.ipynb" there are specific sections dedicated for it ("Outlier detection (Section 4.2.2)").</li> <li>Outlier replacement: when the outliers are detected, in the same notebook there is also a section for outlier replacement ("Replace Outliers") where the outliers' url have to be listed to find the appropriate replacement.</li> </ol> <ul> <li>If it is required, the metrics from the Qualitas Corpus can also be re-generated. First, it is necessary to download the release 20130901r from its <a href="http://www.qualitascorpus.com/download/" target="_blank" rel="noopener">official webpage</a>. Second, decompress the .tar files downloaded. Third, make sure that the compressed files with source code from the projects (.java files) are placed in the "compressed" folder, in some cases it is necessary to read the "QC_README" file in the project's folder. Finally, run the original main script "Generate metrics for the Qualitas Corpus (QC) dataset" part of the code. </li> </ul>
Build Prediction in Continuous Integration Using Textual Analysis of Source Code and Traditional Software Metrics
<p>Continuous Integration (CI) systems integrate code changes committed by software developers, tests the results of the integration, and feed developers with information about the outcome of the integration and testing. Predicting the outcome of the integration is important since it reduces the feedback time between the CI system and the developers. This data-set comprises of historical code changes extracted from the TravisTorrent data-set (found in the train-lines folder) and their corresponding feature vectors (found in the train-bag-of-words folder) for Java projects. It also includes a set of files that contains historical build records and a set of traditional software metrics.</p>
Predicting Bug-Inducing Commits Using Software Quality Metrics
Open the record for dataset details and reuse information.
Exploring Interplays in Performance Metrics of Configurable Software Systems: the JHipster Case Study
<p>This dataset contains all the performance metrics obtained for the paper "Exploring Interplays in Performance Metrics of Configurable Software Systems: the JHipster Case Study".</p>
Software development output metrics for four industrial projects
<p>Data used for the paper "Benchmarking ongoing development output in real-life software projects"</p>
Metrics in Agile Software Development: Repository
Open the record for dataset details and reuse information.
Contribution and Quality Metrics for Quantifying the Software Development Process Dataset
<p>This dataset contains the Contributions and Quality data regarding the 3,000 most starred GitHub Java projects towards Quantifying<br> the Software Development Process.</p> <p>You can use the dataset simply with the following steps:</p> <p> 1. Download the data.</p> <p> 2. Navigate to the download folder and use the mongorestore (<a href="https://docs.mongodb.com/manual/reference/program/mongorestore/">https://docs.mongodb.com/manual/reference/program/mongorestore/</a>) command. (Have in mind to use the --gzip flag)</p>
Whole database with all inputs and outputs of the Master thesis: Analyzing Software Delivery Performance behavior in popular Open Source Software Projects on a Release timeline basis through delivery metrics
<p>The software has become one of the main assets to deliver services today. Thus, software delivery has been dealing with a competitive and dynamic environment where the demand for faster and more assertive deliverables, called here Releases, only increases. Agile development methods emerged helping to accelerate software delivery, embracing industry and open source community. Since then, the software delivery frequency has expanded and improved bringing more adopters of rapid release cycles to reduce their time-to-market. However, using only rapid releases can not be enough as measuring software delivery can answer essential questions, like how software delivery is happening and how it should be. Some approaches for measuring software delivery appeared such as Software Delivery Performance (SDP) where software delivery is measured as a consequence of capabilities evolution. Popularity in Open Source Software Projects (OSSP) means that a project is mature enough in the community to fit the software demand and, therefore, is likely to be ready to be measured through a software delivery approach like SDP. In light of it, this work offers means to analyze SDP behavior in popular Open Source Software Projects on a Release timeline basis through delivery metrics. The results demonstrated that popularity is efficient filtering, as it improves the OSSP delivery, supporting the work's reliability and accuracy. The source code and methodology are published as a replication package to encourage reproducibility and future research.</p> <p> </p>
M-Score: An Empirically Derived Software Modularity Metric
<p>Anonymous upload for paper titled: "M-Score: An Empirically Derived Software Modularity Metric"</p>
Interview Study About Coursework Consultation Sessions with GitLab Metrics in a Software Engineering Course
<p>This data repository is created to share materials used in an interview study about coursework consultation sessions with GitLab Metrics in a software engineering course, and selected quotations with their corresponding themes.</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.