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.
4,276
datasets available to search
ShareScore release 0.9.0
Dataset results
4,276 results for “Estimation”
Effort Estimation: Cosmic
<p><strong>Reference</strong></p> <p>The International Software Benchmarking Standards Group Limited, ISBSG http://www.isbsg.org)</p> <p><strong>Attributes:</strong></p> <p>-------------------------------------------------------- ISBSG Attributes Attributes</p> <p>1 - 94 below are used in isbg10.arff. http://promisedata.googlecode.com/svn/trunk/effort/isbsg10/isbsg10.arff Attributes 95 - 116 are included in cosmic.arff. http://promisedata.googlecode.com/svn/trunk/effort/cosmic/cosmic.arff --------------------------------------------------------</p> <p>1. ISBSG Project ID A primary key, for identifying projects in the ISBSG repository. (These Identification numbers have been ‘randomised’ to remove any chance of identifying a company). 2. Project Rating (Data_Quality) This field contains an ISBSG rating code of A, B, C or D applied to the project data by the ISBSG quality reviewers to denote the following: A = The data submitted was assessed as being sound with nothing being identified that might affect its integrity. B = The submission appears fundamentally sound but there are some factors which could affect the integrity of the submitted data. C = Due to significant data not being provided, it was not possible to assess the integrity of the submitted data. D = Due to one factor or a combination of factors, little credibility should be given to the submitted data. 3. Unadjusted Function Point Rating (UFP) This field contains an ISBSG rating code applied to the Functional Size (Unadjusted Function Point count) data by the ISBSG quality reviewers to denote the following: A = The unadjusted FP was assessed as being sound with nothing being identified that might affect its integrity B = The unadjusted function point count appears sound, but integrity cannot be assured as a single figure was provided C = Due to unadjusted FP or count breakdown data not being provided, it was not possible to provide the unadjusted FP data D = Due to one factor or a combination of factors, little credibility should be given to the unadjusted FP data 4. Year of Project (Year) Year of Project, derived from implementation date (if known), or from other project dates such as: . Project end date . Project start date . Estimated implementation date . Data compilation date If no project date known, it is the year of data receipt by the ISBSG 5. Industry Sector (IS) This is a derived field which attempts to summarise Organisation Type of the project into a single value of a defined set: . Banking . Communication . Construction . Defence & Aerospace . Education . Electronics & Computers . Energy Sources . Environment & Waste . Financial . Government . Insurance . Manufacturing . Medical & Health Care . Mining . Professional Services . Service Industry . Tourism . Utilities . Wholesale & Retail 6. Organisation Type (OT) This identifies the type of organisation that submitted the project. (e.g.: Banking, Manufacturing, Retail). 7. Application Group (AG) This is a derived field that groups Application Type of the project into a single value of a defined set: . Business Application . Real-Time Application . Mathematically-Intensive Application . Infrastructure Software 8. Application Type (AT) This identifies the type of application being addressed by the project. (e.g.: information system, transaction/production system, process control.) 9. Development Type (DT) This field describes whether the development was a new development, enhancement or re-development. 10. Development Platform (DP) Defines the primary development platform, (as determined by the operating system used). Each project is classified as either, a PC, Mid Range, Main Frame or Multi platform. 11. Language Type (LT) Defines the language type used for the project: e.g. 3GL, 4GL, Application Generator etc. 12. Primary Programming Language (PPL) The primary language used for the development: JAVA, C++, PL/1, Natural, Cobol etc. 13. Count Approach (CA) A description of the technique used to size the project. For most projects in the ISBSG repository this is the Functional Size Measurement Method (FSM Method) used to measure the functional size (e.g. IFPUG, MARK II, NESMA, FiSMA, COSMIC etc.). The size of these projects is included in the next 3 columns. Projects using the IFPUG FSM method version 4 or greater are indicated as 'IFPUG' whereas projects sized using a version prior to versipon 4 are indicated in this column as 'IFPUG old'. For projects using Other Size Measures (e.g. LOC etc.) the size data is in the section 'Size Other than FSM' (columns DN - DP). This separation helps you to compare apples with apples. 14. Functional Size (FS) The Unadjusted Function Point count (before adjustment by a Value Adjustment Factor if used). This may be reported in different units depending on the FSM Method. For IFPUG, NESMA, FiSMA & MARK II counts: Where a full size breakdown is provided, this is the calculated functionality un-adjusted by any adjustment factors. Where no size breakdown is provided, but a total adjusted count and adjustment factor is given, this is the unadjusted functionality calculated from the given data. Where an unadjusted functional size is provided, this is that value. Where no unadjusted functional count is provided or can be calculated, this value is blank. For COSMIC-FFP counts: This is total functional size, in COSMIC Function Points (CFP). For OTHER size measure counts: the size data is in the section 'Size Other than FSM' in Lines of Code or Other size units. 15. Relative Size (RS) Categories the Functional Size by relative sizes as follows: Relative Size Functional Size Extra-extra-small XXS => 0 and <10 Extra-small XS => 10 and <30 Small S => 30 and <100 Medium1 M1 => 100 and <300 Medium2 M2 => 300 and <1000 Large L => 1,000 and < 3,000 Extra-large XL => 3,000 and < 9,000 Extra-extra-large XXL => 9,000 and < 18,000 Extra-extra-extra-large XXXL => 18,000 16. Normalised Level 1 Work Effort (N_effort_level1) Development team full life-cycle effort For projects covering less than a full development life-cycle, this value is an estimate of the full life-cycle effort for the development team only. For projects covering the full development life-cycle, and projects where life-cycle coverage is not known, this value is not normalised and is the same as reported work effort for the development team. For projects where the development team effort is not known this value is blank. 17. Normalised Work Effort (N_effort) Full life-cycle effort for all teams reported For projects covering less than a full development life-cycle, this value is an estimate of the full life-cycle effort for all reported teams. For projects covering the full development life-cycle, and projects where life-cycle coverage is not known, this value is the same as Summary Work Effort. For projects where the Summary Work Effort is not known this value is blank. 18. Summary Work Effort (S_effort) Total effort in hours recorded against the project. For projects covering less than a full development life-cycle, this value only covers effort for the phases reported. It includes effort for all reported teams. For projects covering the full development life-cycle, and projects where life-cycle coverage is not known, this value is the total effort for all reported teams. For projects where the total effort is not known this value is blank. 19. Normalised Level 1 Productivity Delivery Rate (N_PDR1) (unadjusted function points) in hours per functional size unit calculated as: Normalised Level 1 Work Effort for development team only / Functional Size This is the delivery rate currently recommended by the ISBSG. Use of normalised effort for development team only and unadjusted functional count should render the most comparable rates. The units used in this column vary according to the Count Approach: For IFPUG, NESMA, FiSMA, & MARK II: = hours per function point (hours/UFP) For COSMIC FFP: = hours per Cosmic function point (hours/CFP) For Others: = hours per functional size unit (hours/fsu) 20. Normalised Productivity Delivery Rate (N_PDR) (unadjusted function points) in hours per functional size unit calculated as: Normalised Work Effort / Functional Size This is the delivery rate for the project used and reported by the ISBSG since the year 2002. Use of normalised effort and unadjusted count should render more comparable rates than un-normalised effort and adjusted count. The units used in this column vary according to the Count Approach: For IFPUG, NESMA, FiSMA, & MARK II: = hours per function point (hours/UFP) For COSMIC FFP: = hours per Cosmic function point (hours/CFP) For Others: = hours per functional size unit (hours/fsu) 21. Speed of Delivery Rate (SDR) Functional Size Units per person per elapsed month calculated as: Functional Size / Project Elapsed Time * Max Team Size Measures the speed achieved by the project team in delivering a quantity of software over a period of time. It is defined as the Functional Size of the delivered software (measured in functional size units), over the Project Elapsed Time (measured in months) multiplied by the number of people in the project team. It is expressed as Functional Points per person per elapsed month. 22. Project Elapsed Time (PET) Total elapsed time for the project in calendar months. 23. Project Inactive Time (PIT) This is the number of calendar months in which no activity occurred, (e.g.: awaiting client sign off, awaiting acceptance test data). This time, subtracted from Project Elapsed Time, derives the actual time spent working on the project. 24. Implementation Date (I_Date) Actual date of implementation. (Note: Where the exact date is not known the date is shown as the 1st of the implementation month in the format 1/mm/yy). Where the project had multiple implementations, this is the date of the 1st or major implementation. 25. Project Activity Scope (PAS) This data indicates what activities or tasks were included in the total project work effort data recorded. The activities or tasks are: Planning, Specify, Design, Build, Test, and Implement. 26. Work Effort Recording Method (Recording_Method) The method used to obtain work effort data: . Staff Hours (Recorded) – The WORK EFFORT reported comes from a "daily" recording of all the WORK EFFORT expended by each person on project related tasks. . Staff Hours (Derived) – The WORK EFFORT reported is derived from time records that indicate, for example, the assignment of people to the project. This might entail estimating that, for example, only 75% of the assigned time was actually applied to the project; the rest is for holidays, education, etc. . Productive Time Only – The WORK EFFORT reported is only for the "productive time" spent by each person on the project. This often amounts to only 5-6 hours per day. . Combination – A combination of recorded and derived methods was used to obtain the WORK EFFORT. . No timesheets recorded by development team – No timesheets were recorded by the development team. . Recorded total hours each day or week – Only the total hours worked each day or week was recorded as WORK EFFORT. . Recorded hours on each project/day/week – The WORK EFFORT was recorded as hours worked on each project for each day/week. . Recorded work on project tasks each day – The WORK EFFORT was recorded for each project task for each day. 27. Resource Level (Resource_Level) Data is collected about the people whose time is included in the work effort data reported. Four levels are identified in the ISBSG data repository. 1 = development team effort (e.g., project team, project management, project administration) 2 = development team support (e.g., database administration, data administration, quality assurance, data security, standards support, audit & control, technical support) 3 = computer operations involvement (e.g., software support, hardware support, information centre support, computer operators, network administration) 4 = end users or clients (e.g., user liaisons, user training time, application users and/or clients) The number in this field indicates that all effort at this and preceding levels is included in the effort fields. For example, a “3” in this field for a project means that the work effort for the development team, development team support and computer operations is included in the work effort number. 28. Max Team Size (MTS) The maximum number of people that worked at any time on the project, (peak team size). This number is given for the Development Team (level 1) only. 29. Average Team Size (ATS) The average number of people that worked on the project, (calculated from the team sizes per activity, and only given where team sizes per activity are known). This number is given for the Development Team (level 1) only. 30. Ratio of Project Work Effort to Non-Project Activity (R_PWE_NPA) The ratio of Project Work Effort to Non-Project Activities. 31. Percentage of Uncollected Work Effort (P_UWE) The percentage of Work Effort not reflected in the reported data. i.e. an estimate of the work effort time not collected by the method used. The report typically is stated in the following terms: . less than 5% of that recorded, . between 5% and 10% of that recorded, . ___ % over that recorded, and . unable to estimate 32. CASE Tool Used (CASE_Tool) Whether the project used any CASE tool. The full repository holds a breakdown of CASE usage for those projects that reported using a CASE tool: . Upper CASE tool . Lower CASE tool with code generator . Lower CASE tool without code generator . Integrated CASE tool . Other CASE tool 33. Used Methodology (UM) States whether a development methodology was used by the development team to build the software. 34. How Methodology Acquired (HMA) Describes whether the development methodology was purchased or developed in-house, or a combination of these. 35. 1st Hardware (Hardware1) Where known, this is the primary technology hardware platform used to build or enhance the software (i.e. that used for most of the build effort). 36. 1st Language (Language1) Where known, this is the primary technology programming language used to build or enhance the software (i.e. that used for most of the build effort). 37. 1st Operating System (OS1) Where known, this is the primary technology operating system used to build or enhance the software (i.e. that used for most of the build effort). 38. Integrated Development Environment (IDE) Where known, this is the primary Integrated Development Environment, a development environment integrating a range of tools to aid the processes of designing, constructing and testing the software; typically, incorporating graphical and component based development techniques. 39. 1st Debugging Tool (DT1) Where known, this is the primary technology debugging tool used to build or enhance the software (i.e. that used for most of the build effort), otherwise (if known) it is whether the project used a debugging tool. 40. 1st Data Base System (DBS1) Where known, this is the primary technology database used to build or enhance the software (i.e. that used for most of the build effort), otherwise (if known) it is whether the project used a DBMS. 41. 1st Component Server (CS1) Where known, this is the primary technology object/component server used to build or enhance the software (i.e. that used for most of the build effort), otherwise (if known) it is whether the project used an object/component server. 42. 1st Web Server (WS1) Where known, this is the primary technology HTML/Web server used to build or enhance the software (i.e. that used for most of the build effort); otherwise (if known) it is whether the project used an HTML/Web server. 43. 1st Message Server (MS1) Where known, this is the primary technology E-Mail or message server used to build or enhance the software (i.e. that used for most of the build effort), otherwise (if known) it is whether the project used an E-Mail or message server. 44. 1st Other Platform (OP1) Where known, this is any other component of the primary technology used to build or enhance the software (i.e. that used for most of the build effort). 45. FP Standard (FPS) (Function Size Metric Used) The functional size metric used to record the size of the project, (e.g. IFPUG3, IFPUG4 [version 4 series = 4.0,4.1, 4.1.1, 4.2 etc], in-house etc.). Where more than 1 standard has been recorded for the project, this column has been rationalised to 1 value. 46. FP Standards All (FPSA) (All Function Size Metrics Used) All functional size metrics used to record the size of the project. This column shows all standards recorded for the project, (e.g. IFPUG3;IFPUG4;in-house). 47. Reference Table Approach (RTA) This describes the approach used to assess tables of code or reference data (a comment field), for their contribution to functional size. 48. Business Area Type (BAT) This identifies the subset within the organisation being addressed by the project. It may be different to the organisation type or the same. (e.g.: Manufacturing, Personnel, Finance). 49. Software Process CMMI (SP_CMMI) Software standards define a series of actions and documentation structures and contents required to deliver quality software and software processes. Software standards are maintained by international organisations. Software developers are typically required to be formally and externally assessed in order to achieve certification to these standards. This column indicates if the project was performed under CMMI processes. Where available, details such as the level or version, and year of certification are included. 50. Software Process ISO (SP_ISO) Software standards define a series of actions and documentation structures and contents required to deliver quality software and software processes. Software standards are maintained by international organisations. Software developers are typically required to be formally and externally assessed in order to achieve certification to these standards. This column indicates if the project was performed under ISO processes. Where available, details such as the version, and year of certification are included. 51. Software Process TICKIT (SP_TICKIT) Software standards define a series of actions and documentation structures and contents required to deliver quality software and software processes. Software standards are maintained by international organisations. Software developers are typically required to be formally and externally assessed in order to achieve certification to these standards. This column indicates if the project was performed under TICKIT processes. Where available, details such as the version, and year of certification are included. 52. Minor Defects Delivered (MIN_Defects) Minor defects reported in the first month of use of the software. This column is the number of Minor defects reported. 53. Major Defects Delivered (MAJ_Defects) Major defects reported in the first month of use of the software. This column is the number of Major defects reported. 54. Extreme Defects Delivered (X_Defects) Extreme defects reported in the first month of use of the software. This column is the number of Extreme defects reported. 55. Total Defects Delivered (TOT_Defects) Total number of defects reported in the first month of use of the software. This column shows the total of defects reported (Minor, Major and Extreme). or Where no breakdown is available, the single value is shown here (if known). 56. User Base - Business Units (UB_BU) Number of distinct business units (or project business stakeholders) serviced by the software application. The number of distinct business units serviced by the software application. Where the application covers multiple sets of users, a Business Unit is where a distinct set of business rules applies to a distinct set of application users. This column contains numeric values and text representing number range or approximate value. The data has been collected in different forms dependent on the version of the questionnaire used or the precision of the submitter's data. Interpretation of these values is at the discretion of the user. 57. User Base - Locations (UB_L) Number of physical locations being serviced/supported by the installed software application. The number of physical locations being serviced/supported by the installed software application. A ‘distinct installation’ is an individual installation of the complete software system. This column contains numeric values and text representing number range or approximate value. The data has been collected in different forms dependent on the version of the questionnaire used or the precision of the submitter's data. Interpretation of these values is at the discretion of the user. 58. User Base - Distinct Users (UB_DU) Number of distinct end users using the system. The total number of end users that can invoke the application. This column contains numeric values and text representing number range or approximate value. The data has been collected in different forms dependent on the version of the questionnaire used or the precision of the submitter's data. Interpretation of these values is at the discretion of the user. 59. User Base - Concurrent Users (UB_CU) Number of end users using the system concurrently. The total number of end users using the system concurrently. The term concurrent end users applies to a single distinct installation. This column contains numeric values and text representing number range or approximate value. The data has been collected in different forms dependent on the version of the questionnaire used or the precision of the submitter's data. Interpretation of these values is at the discretion of the user. 60. Intended Market (IMarket) This field describes the relationship between the project’s customer, end users and development team. 61. Target Platform (T_Platform) The implementation platform of the software product. The platform that the software was implemented into. The implementation platform may be different from that on which the software was developed, or may be the only platform known for the project. A Multi platform environment would include aspects of more than one of the categories Mainframe, Midrange, or PC. 62. Device Embedded (D_Embedded) For mobile or device embedded software, this specifies the generic device into which the software is implemented. 63. Size estimate (SE): Estimate of the functional size (ie. IFPUG Function Points, COSMIC Function Points) made during the Planning activity for the project. 64. Size estimate approach (SEA): Functional size approach used for the size estimate. 65. Size estimate method (SEM): Method used to estimate the functional size. 66. Effort estimate (E_Estimate): Estimate of the effort for the project (in hours) made during the planning activity. 67. Effort estimate method (E_Estimate_Method): Method used to estimate the effort. 68. Delivery date estimate (DDE): Estimate of the delivery date for the project made during the planning activity. 69. Delivery date estimate method (DDEM): Method used to estimate the delivery date. 70. Cost estimate (C_Estimate): Estimate of the cost for the project made during the planning activity. 71. Cost estimate currency (CEC): Currency used to express the cost estimate. 72. Cost estimate method (CEM): Method used to estimate the cost. 73. Estimating tool (E_Tool): Name or description of any tools used in calculating project estimates. This data comes from an earlier version of the ISBSG data collection questionnaire 74. Estimating comments (E_Comments): Any comments on the project planning or estimates. 75. Estimate compilation date (EC_Date): Date of compilation of the estimate data. This data comes from an earlier version of the ISBSG data collection questionnaire 76. Software reuse? (SR?) Indicates if this project made no reuse of previous software development work. Promoters of reuse claim that it improves development productivity. 77. Software reuse (SR) If this project made any reuse of software development work products created prior to the project, this is the form of this reuse. (If an enhancement project, the concept of reuse excludes the existing software that the project is enhancing.) Purchased components: Collection of source code/objects (or compiled objects) purchased separately from the programming languages used. In-house components / libraries: Collection of source code/objects formed and maintained by the development organisation itself. Purchased framework/foundation: Extensive set of software classes designed to be the foundation of a product and purchased separately from the programming language. 78. Reuse FP count (R_FPC) If there was reuse of software development work products on this project, this is the amount of functionality provided by reused work products. Software development work products include software components, libraries or frameworks. 79. Reuse FP approach (R_FPA) If there was reuse of software development work products on this project, this is the approach used to measure it. The ‘amount of functionality’ is measured using Function Points or some other measure. 80. Plan Defects (P_Defects) Defects reported in the Planning activity. This column is the total number of defects reported for the activity. 81. Specification Defects (S_Defects) Defects reported in the Specification activity. This column is the total number of defects reported for the activity. 82. Design Defects (D_Defects) Defects reported in the Design activity. This column is the total number of defects reported for the activity. 83. Minor Build Defects (MIN_B_Defects) Minor defects reported in the Build activity. This column is the number of Minor defects reported for the activity. 84. Major Build Defects (MAJ_B_Defects) Major defects reported in the Build activity. This column is the number of Major defects reported for the activity. 85. Extreme Build Defects (X_B_Defects) Extreme defects reported in the Build activity. This column is the number of Extreme defects reported for the activity. 86. Total Build Defects (TOT_B_Defects) Total number of defects reported in the Build activity. This column shows the total of defects reported (Minor, Major and Extreme). or Where no breakdown is available, the single value is shown here (if known). 87. Minor Test Defects (MIN_T_Defects) Minor defects reported in the Test activity. This column is the number of Minor defects reported for the activity. 88. Major Test Defects (MAJ_T_Defects) Major defects reported in the Test activity. This column is the number of Major defects reported for the activity. 89. Extreme Test Defects (X_T_Defects) Extreme defects reported in the Test activity. This column is the number of Extreme defects reported for the activity. 90. Total Test Defects (TOT_T_Defects) Total number of defects reported in the Test activity. This column shows the total of defects reported (Minor, Major and Extreme). or Where no breakdown is available, the single value is shown here (if known). 91. Minor Implementation Defects (MIN_I_Defects) Minor defects reported in the Implementation activity. This column is the number of Minor defects reported for the activity. 92. Major Implementation Defects (MAJ_I_Defects) Major defects reported in the Implementation activity. This column is the number of Major defects reported for the activity. 93. Extreme Implementation Defects (X_I_Defects) Extreme defects reported in the Implementation activity. This column is the number of Extreme defects reported for the activity. 94. Total Implementation Defects (TOT_I_Defects) Total number of defects reported in the Implementation activity. This column shows the total of defects reported (Minor, Major and Extreme). or Where no breakdown is available, the single value is shown here (if known). 95. Work Effort Breakdown (Plan) (E_Plan) When provided in the submission, this field contains the breakdown of Summary Work Effort reported for Plan phase within the range: Plan, Specify, Design, Build, Test and Implement. 96. Work Effort Breakdown (Specify) (E_Specify) When provided in the submission, this field contains the breakdown of Summary Work Effort reported for Specify phase within the range: Plan, Specify, Design, Build, Test and Implement. 97. Work Effort Breakdown (Design) (E_Design) When provided in the submission, this field contains the breakdown of Summary Work Effort reported for Design phase within the range: Plan, Specify, Design, Build, Test and Implement. (Note: For many projects in the ISBSG repository that were collected prior to version 5 of the collection package, high level design was included in the Specify phase and low level design was included in the Build phase. For these projects no value will be included in this column). 98. Work Effort Breakdown (Build) (E_Build) When provided in the submission, this field contains the breakdown of Summary Work Effort reported for Build phase within the range: Plan, Specify, Design, Build, Test and Implement. 99. Work Effort Breakdown (Test) (E_Test) When provided in the submission, this field contains the breakdown of Summary Work Effort reported for Test phase within the range: Plan, Specify, Design, Build, Test and Implement. 100. Work Effort Breakdown (Implement) (E_Implement) When provided in the submission, this field contains the breakdown of the Summary Work Effort reported for Implementation phase within the range: Plan, Specify, Design, Build, Test and Implement. 101. Unrecorded Component of Work Effort (E_Unrecorded) Where no activity breakdown of effort is provided in the submission, this will be equal to the Summary Work Effort. Where an activity breakdown of effort is given, and the sum of that breakdown does not equal the Summary Work Effort, this is the value of the difference. Where an activity breakdown of effort is given, and the sum of that breakdown equals the Summary Work Effort, this value is zero. 102. Team Size Group (TSG) Categories Max Team Size by into groups to increase number of projects selected, as follows: Team Size Group 1 => 1.55 2 = 1.55 to <2.5 3-4 = 2.5 to <4.5 5-8 = 4.5 to <8.5 9-14 = 8.5 to <14.5 15-20 = 14.5 to <20.5 21-30 = 20.5 to <30.5 31-40 = 30.5 to <40.5 41-50 = 40.5 to <50.5 51-60 = 50.5 to <60.5 61-70 = 60.5 to <70.5 71-80 = 70.5 to <80.5 81-90 = 80.5 to <90.5 91-100 = 90.5 to <100.5 100 + =>100 103. Development Methodologies (Dev_Methodologies) Methodologies used during development. (e.g.: Agile, Prototyping, Waterfall etc.). 104. Development Techniques (Dev_Techniques) Techniques used during development. (e.g.: JAD, Data Modelling, OO Analysis etc.). Note these techniques have not been recorded as being specific to a particular project activity and therefore may apply to any part of the development lifecycle. 105. JAD Method Used (JAD_Method) Whether the project used any JAD Method. The repository holds fields of methods used in the project and specifically in specification or design. This column indicates if any Joint Application Design methods were reported. 106. Prototyping Method Used (PMU) Whether the project used any Prototyping Method. The repository holds fields of methods used in the project. This column indicates if any Prototyping methods were reported. 107. Architecture A derived attribute for the project to indicate if the application is: . Stand alone . Multi-tier . Client server . Multi-tier with web public interface 108. Client Server? (Client_Server?) Indicator of whether the application or product requires more than one computer to operate different components or parts of it (Yes, No or Don't Know). 109. Client Roles (Client_Roles) The roles performed by the computers that provide interface to the software’s external users. 110. Server Roles (Server_Roles) The services provided by the host/server computer(s) to the software application or product. 111. Type of Server (TOS) A description of the server to the software application or product. This data comes from earlier versions of the questionnaire than the current. 112. Client/Server Description (CS_Description) A description of the architecture of the client/server software application or product. This data comes from earlier versions of the questionnaire than the current. 113. DBMS Used (DBMS_Used) Whether the project used a DBMS. Either in primary or secondary platforms. 114. Upper CASE Used (Upper_CASE_Used) Whether the project used an upper CASE tool. 115. Other CASE tool (Other_CASE_Tools?) Computer-Aided Software Engineering of some other type. These were specified in the data submission as either "Other CASE" or as "Lower CASE" but with out specifying with or without code generation. 116. Other CASE names (Other_CASE_Tool_Names) The names of any other CASE technology. These were specified in the data submission as either "Other CASE" or as "Lower CASE" but with out specifying with or without code generation.</p> <p> </p>
Effort Estimation: Albrecht
<p>Dataset used for Effort Estimation</p> <p><strong>Reference</strong></p> <p>Albrecht, A.J. and Gaffney, J.E., Jr. (1983) Software Function, Source Lines of Code, and Development Effort Prediction: A Software Engineering, IEEE Transactions on Software Engineering, 9(6):639-648</p>
Effort Estimation: Maxwell
<p>Dataset for Effort Estimation</p> <p> </p> <p><strong>Reference</strong></p> <p>1 K. D. Maxwell. 2002. Applied Statistics for Software Managers. Englewood Cliffs, NJ. Prentice-Hall.</p> <p>2 P. Sentas, L. Angelis, I. Stamelos, G. Bleris. 2005. Software productivity and effort prediction with ordinal regression. Information and Software Technology, 47, 17-29.</p> <p>3 Y.F. Li, M. Xie, T.N. Goh. 2009. A Study of Mutual Information Based Feature Selection for Case Based Reasoning in Software Cost Estimation. Expert Systems with Applications. 36(3), 5921-5931.</p> <p>4 Y.F. Li, M. Xie, T.N. Goh. 2009. A Study on the Non-linear Adjustment for Analogy Based Software Cost Estimation. Empirical Software Engineering. In press.</p> <p> </p>
Effort Estimation: openeffort
<p>Data</p> <p>There are two types of data associated with this paper: author activity from OpenStack contributors and survey data from the contributors. In addition, the raw data from which the author activity data was extracted can be found here</p> <p>Author Activity Data</p> <p>-Rows represent individual authors (1626 total) -Columns represent months starting in Jan 2010 (these are 0-padded before and after project) -The actual author IDs can be found by cross-referencing output_authors_ids_nobots.csv: -Number of commits per month: output_commits_nobots.csv -Number of active days per month: output_activity_nobots.csv</p> <p>Survey Response Data</p> <p>This represents voluntary responses to a survey in which 131 individuals responded. Survey questions are as follows: ``` 1) Selection: On average, how many hours in a week have you spent in the project in the last six months? (>40h, 40h, 30h, 20h, 10h, <5h)</p> <p>2) Selection: How much of the time you spent in the project is devoted to coding? (>95%, approx. 75%, approx. 50%, approx. 25%, <10%)</p> <p>3) Selection: Do you make at least one commit to the repository the days you code? (yes, no)</p> <p>4) Selection: What do you consider yourself in the project? (full-time, part-time, occasional contributor)</p> <p>5) Free-text box: Did you always work on the project the same amount of hours, or did you have different phases of commitment? If you had different phases, could you tell us about the various phases? (the graph below may help you, as it is based in your recorded activity in the repository) ```</p> <p>The anonymized survey response data is here</p> <p>This survey data was cleaned with a few respondents being removed and some responses being edited. A description of the cleaning process as well as the cleaned response data is here.</p>
Dataset of the analysis described in the article: EM signal penetration in a planetary soil simulant: Estimated attenuation rates using GPR and TDR in volcanic deposits on Mount Etna
<p>GPR and TDR Data collected at two sites on Mount Etna.</p> <p>See for more details the article</p>
Estimates for the stiffness, strength and drift capacity of stone masonry walls based on 123 quasi-static cyclic tests reported in the literature
<p>Database of 123 shear and compression tests on stone masonry walls reported in the literature. Test references, geometrical and typological data, loading and boundary conditions, mechanical characterisation data, and synthetic test results are collected. Such test results include failure mode, force and displacement capacities for different limit states and estimates of the elastic and effective stiffness. Hysteretic force-displacement curves, digitalised from the sources, and the derived envelopes are provided, when available, as .csv files.</p>
Taxonomic Uncertainty on Range Size and Niche Estimation in a Southern Ocean Cryptic Species Complex
<p>R code and data related to assessing the effect of taxonomic uncertainty on range size and environmental niche estimates for a Southern Ocean invertebrate. </p> <p>Clarke, D.A., Wilson, N.G. and McGeoch, M.A. (2025) ‘Effects of Taxonomic Uncertainty on Range Size and Niche Estimation in a Southern Ocean Cryptic Species Complex’, Journal of Biogeography, n/a(n/a), p. e15182. Available at: https://doi.org/10.1111/jbi.15182.</p>
Perturbed Synthetic SWOT Datasets for Testing and Development of a Kalman Filter Approach to Estimate Daily Discharge
<p><strong>1. Introduction</strong></p> <p>Datasets are used to evaluate the performance of a Kalman filter approach to estimate daily discharge. This is a perturbed version of synthetic SWOT datasets consisting of 15 river sections, which are commonly agreed datasets for evaluating the performance of SWOT discharge algorithms (Frasson et al., 2020, 2021). The benchmarking manuscript entitled “A Kalman Filter Approach for Estimating Daily Discharge Using Space-based Discharge Estimates” is currently under review at Water Resources Research. Once the manuscript is accepted, its DOI will be included here.</p> <p> </p> <p><strong>2. </strong><strong>File description</strong></p> <p>The datasets are generally divided into two categories: river information (River_Info) and time series data (Timeseries_Data). River information provides fundamental and general river characteristics, whereas time series data offers daily reach-averaged data for each reach. In time series data, the data mainly contains three components: true data, perturbed measurements, and true and perturbed flow law parameters (A0, an, and b). For each reach, there are 10000 realizations of perturbed measurements per time step and there are 100 realizations of time-invariant perturbed flow law parameters through a Monte Carlo simulation (Frasson et al., 2023). Moreover, to support our proposed Kalman filter approach to estimate daily discharge, the datasets provide the median of the perturbed discharge, river width, water surface slope, and change in the cross-sectional area, as well as the uncertainty of the perturbed discharge and change in the cross-sectional area based on the interquartile range (Fox, 2015).</p> <p>To support reproducibility and facilitate example usage, we now include a MATLAB code package (<code>KalmanFilter_Code.zip</code>) that demonstrates how to run the Kalman filter approach using the Missouri Downstream case as an example. </p> <p>Datasets are contained in a .mat file per river. The detailed groups and variables are in the following:</p> <p><strong>River_Info</strong></p> <p>Name: River name, data type: char</p> <p>QWBM: Mean annual discharge from the water balance model WBMsed (Cohen et al., 2014)</p> <p>rch_bnd: Reach boundaries measured in meters from the upstream end of the model</p> <p>gdrch: Good reaches in the study. They were used to exclude small reaches defined around low-head dams and other obstacles where Manning’s equation should not be applied.</p> <p><strong>Timeseries_Data</strong></p> <p>t: Time measured in days since the first day or “0-January-0000” for cases when specific dates were available. Dimension: 1, time step.</p> <p>A: Reach-averaged cross-sectional area of flow in m<sup>2</sup>. Dimension: Reach, time step.</p> <p>Q_true: True reach-averaged discharge (m<sup>3</sup>/s). Dimension: Reach, time step.</p> <p>Q_ptb: Perturbed discharge (m<sup>3</sup>/s), including 10000 realizations for each measurement. Dimension: Good reach, time step, 10000.</p> <p>med_Q_ptb: Median perturbed discharge (m<sup>3</sup>/s) across the 10000 realizations. Dimension: Good reach, time step.</p> <p>sigma_Q_ptb: Uncertainty of the perturbed discharge (m<sup>3</sup>/s), calculated based on the interquartile range. Dimension: Good reach, time step.</p> <p>W_true: True reach-averaged river width (m). Dimension: Reach, time step.</p> <p>W_ptb: Perturbed river width (m), including 10000 realizations for each measurement. Dimension: Good reach, time step, 10000.</p> <p>med_W_ptb: Median perturbed river width (m) across the 10000 realizations. Dimension: Good reach, time step.</p> <p>H_true: True reach-averaged water surface elevation (m). Dimension: Reach, time step.</p> <p>H_ptb: Perturbed water surface elevation (m), including 10000 realizations for each measurement. Dimension: Good reach, time step, 10000.</p> <p>S_true: True reach-averaged water surface slope (m/m). Dimension: Reach, time step.</p> <p>S_ptb: Perturbed water surface slope (m/m), including 10000 realizations for each measurement. Dimension: Good reach, time step, 10000.</p> <p>med_S_ptb: Median perturbed water surface slope (m/m) across the 10000 realizations. Dimension: Good reach, time step.</p> <p>dA_true: True reach-averaged change in the cross-sectional area (m<sup>2</sup>). Dimension: Good reach, time step.</p> <p>dA_ptb: Perturbed change in the cross-sectional area (m<sup>2</sup>), including 10000 realizations for each measurement. Dimension: Good reach, time step, 10000.</p> <p>med_dA_ptb: Median perturbed change in the cross-sectional area (m<sup>2</sup>) across the 10000 realizations. Dimension: Good reach, time step.</p> <p>sigma_dA_ptb: Uncertainty of the perturbed change in the cross-sectional area (m<sup>2</sup>), calculated based on the interquartile range. Dimension: Good reach, time step.</p> <p>A0_true: True baseline cross-sectional area (m<sup>2</sup>). Dimension: Good reach, 1.</p> <p>A0: Perturbed baseline cross-sectional area (m<sup>2</sup>), including 100 realizations for each parameter. Dimension: Good reach, 100.</p> <p>na_true: True friction coefficient. Dimension: Good reach, 1.</p> <p>na: Perturbed friction coefficient, including 100 realizations for each parameter. Dimension: Good reach, 100.</p> <p>b_true: True exponent coefficient. Dimension: Good reach, 1.</p> <p>b: Perturbed exponent coefficient, including 100 realizations for each parameter. Dimension: Good reach, 100.</p>
Southern Ocean Nitrate Estimates (SONE) Dataset
<p>The Southern Ocean Nitrate Estimates (SONE) is a 1x1 monthly gridded product of estimated ocean nitrate concentration from a neural network. The dataset spans 2004-2022, from the surface down to 2000m.</p> <p>'SONE-v1' is the original dataset used during the peer-review process.</p> <p>'SONE-v2' is the final dataset, same as SONE-v1, but salinity-normalized.</p>
Deep Learning with Satellite Images Enables High-Resolution Income Estimation: a Case Study of Buenos Aires
<p>This repository contains the datasets required for replicating the results in Abbate et al (forthcoming). The datasets also include per capita income estimates at a 50x50 meter resolution for the years 2013, 2018, and 2022, using satellite images from the Metropolitan Area of Buenos Aires (Argentina) and 2010 census+survey data. The model, based on the EfficientnetV2 architecture, achieved high accuracy in predicting household incomes (R2=0.878), surpassing existing methods in spatial resolution and performance. </p> <p>Inside the Replication Package folder, the user can replicate the main results from the paper. This includes:</p> <ol> <li> <p><strong>Small Area Estimation (SAE) Replication:</strong></p> <ul> <li> <p><strong>Argentina Household Survey Data (EPH):</strong> Processed microdata for 2010, 2013, 2018, and 2022 (ARG_*_EPHC-S2_*.dta).</p> </li> <li> <p><strong>Argentina Census Microdata:</strong> Raw 2010 census microdata (censo2010_fullraw_p.dta).</p> </li> <li> <p><strong>Census Tract Map:</strong> Shapefile of 2010 census tracts (radios_eph_with_link.shp).</p> </li> <li> <p><strong>SAE Output:</strong> The final small_area_estimates.parquet file containing census tract-level population and estimated income, which serves as labels for the CNN model.</p> </li> </ul> </li> <li> <p><strong>CNN-based Income Prediction Replication (Paper Results):</strong></p> <ul> <li> <p><strong>CNN Model Income Predictions:</strong> Gridded 50x50m income estimates for Buenos Aires for 2013, 2018, and 2022 (income_estimates_*.shp).</p> </li> <li> <p><strong>Normalization Scalars:</strong> A CSV file (scalars_ln_pred_inc_mean_trimTrue.csv) to convert the model's log-scale outputs into real income values (2010 PPP-adjusted Argentinian pesos).</p> </li> <li> <p><strong>World Settlement Footprint (WSF):</strong> Satellite-based data (WSF2015_v2_-60_-36.tif) used to mask predictions in uninhabited areas.</p> </li> </ul> </li> </ol> <p>Key prediction datasets are published in shapefile format, while input data for SAE and other auxiliary files are in formats like .dta, .parquet, .csv, and .tif.</p> <p>Results can be replicated by connecting these datasets with the scripts available at the GitHub repo linked below.</p> <p>For researchers who wish to replicate the full analysis pipeline starting from the original source imagery, the data must be acquired commercially. The proprietary Pleiades and Pleiades NEO satellite imagery is owned by Airbus and can be purchased through their data portal: https://space-solutions.airbus.com/imagery/. To facilitate this process, we provide the unique product identifiers for each scene used in this study. These identifiers can be used to query the Airbus archive and purchase the exact scenes.</p> <ul> <li><strong>Pléiades</strong>: for 2013 imagery the IDs are DS_PHR1A_201302051411520_FR1_PX_W059S35_0807_03124, DS_PHR1A_201302071357305_FR1_PX_W059S35_0410_06105 and DS_PHR1A_201302071357509_FR1_PX_W059S35_0609_05426, and for 2018, DS_PHR1A_201803251356358_FR1_PX_W059S35_0909_03875, DS_PHR1A_201808021356574_FR1_PX_W059S35_0509_06938 and DS_PHR1A_201808021357186_FR1_PX_W059S35_0706_06104.</li> <li><strong>Pleiades NEO</strong>: for 2022 imagery the IDs used are 000047717_1_22_STD_A, 000047717_1_24_STD_A, 000047717_1_25_STD_A, 000047717_1_26_STD_A, 000058605_1_3_STD_A, 000058605_1_4_STD_A, 000058605_1_7_STD_A, and 000058608_1_2_STD_A.</li> </ul> <p><strong>Important Usage Note:</strong> Since the predictions for each 50x50m cell individually present some random variation, we recommend that the results are used by averaging out the estimations for each area of interest (e.g., municipalities, neighborhoods, sections, or census tracts) and not at an individual cell level. As detailed throughout the paper, the aggregated results, even in small areas such as census tracts, predict household incomes with precision.</p> <p>Furthermore, inside this repository, it is possible to access and use the model’s trained parameters to make predictions about different satellite images.</p> <p>Data can be visualized by accessing: <a href="https://ingresoamba.netlify.app">https://ingresoamba.netlify.app</a></p> <p> </p> <p> </p>
Watersurface cover estimates for sodapans and lakes in the Seewinkel region, Austria
<h1>Description</h1> <p>This upload describes remote-sensing derived water surface estimates for a set of sodapans and lakes in the Seewinkel region in Austria. Pannonic salt steppes and salt marshes (EUNIS code <a title="EUNIS" href="https://eunis.eea.europa.eu/habitats/10029" target="_blank" rel="noopener">1530</a>) are among the rarest habitat types in Europe and typically characterized by halophytic vegetation and periodically reoccurring water surface and it is not untypical for them to fall entirely dry during the course of the year.<br><br>Here a near-daily time series of water surface area was created from pre-processed Sentinel 1 ARD data using VV polarization estimates from all ascending imageries taken between 2015 and the last updated day. The data was corrected for border-noise and despecking. Based on a calibrated threshold (obtained through visual inspection) the water surface area was then identified and extracted within the boundaries of the habitat areas. A shapefile of the extent of sodapans and lakes in the Neusiedl region has been supplied by the Nationalpark Lake Neusiedl - Seewinkel (not shared). Area estimates are in ha unless otherwise stated.</p> <p><strong>The data can be interactively navigated on a small dashboard online:</strong><br><a title="Interactive dashboard" href="https://martinjung.shinyapps.io/lackenmonitor/" target="_blank" rel="noopener">https://martinjung.shinyapps.io/lackenmonitor/ </a><br><br>The creation of this data was supported by the <a title="INSPIRE" href="https://www.inspire-biodiversa.com/" target="_blank" rel="noopener">INSPIRE project</a> funded under the BiodivERsA BiodivProtect call.</p>
Dataset from paper: "Mind the Gap: Reconciling tropical forest carbon flux estimates from Earth Observation and National Reporting requires transparency"
<p>This repository contains the processed data used in the publication of Heinrich et al., 2023 (Mind the Gap: Reconciling tropical forest carbon flux estimates from Earth Observation and National Reporting requires transparency). Carbon Balance and Management: https://cbmjournal.biomedcentral.com/articles/10.1186/s13021-023-00240-2 </p><p>When using this data, full reference to the raw data publications and the publication Heinrich et al., 2023 must be made.</p><p>The raw datasets used in this study are all available from their original sources.</p><p> </p>
mRI: multi-modal 3d human pose estimation dataset using mmwave, rgb-d, and inertial sensors
<p>The ability to estimate 3D human body pose and movement, also known as human pose estimation~(HPE), enables many applications for home-based health monitoring, such as remote rehabilitation training. Several possible solutions have emerged using sensors ranging from RGB cameras, depth sensors, millimeter-Wave (mmWave) radars, and wearable inertial sensors. Despite previous efforts on datasets and benchmarks for HPE, few datasets exploit multiple modalities and focus on home-based health monitoring.</p> <p>To bridge this gap, we present <em>mRI</em>, a multi-modal 3D human pose estimation dataset with mmWave, RGB-D, and Inertial Sensors. Our dataset consists of over 5 million frames from 20 subjects performing rehabilitation exercises and supports the benchmarks of HPE and action detection. We perform extensive experiments using our dataset and delineate the strength of each modality.</p> <p>We hope that the release of <em>mRI</em> can catalyze the research in pose estimation, multi-modal learning, and action understanding, and more importantly, facilitate the applications of home-based health monitoring.</p>
Replication data for estimating the below-ground leak rate of a natural gas pipeline using above-ground downwind measurements: THE ESCAPE−1 MODEL
<p>Gas leak detectors are currently used to survey for below-ground leaks. However, measurements from gas detectors are not precise in quantifying the below-ground leak rate—data in this submission aimed to quantify the below-ground leak rate of a Natural Gas pipeline.</p>
Code and data for: Shining a light on elusive lynx: density estimation of three Eurasian lynx populations in Ukraine and Belarus
<p class="MsoNormal"><span>The Eurasian lynx is a large carnivore widely distributed across Eurasia. However, our understanding of population status is heterogeneous across their range, with some populations isolated that are at risk of reduced genetic variation and a complete lack of information about others. In many European countries, Eurasian lynx are monitored through demographic studies crucial for their conservation and management. Even so, there are only rough and fragmented population assessments from Ukraine and Belarus, despite strict protection in both countries and their importance for lynx connectivity across Europe. We monitored lynx from October 2020 to March 2021 and used camera-trapping in combination with spatial capture-recapture (SCR) methods in a Bayesian Framework to provide the first SCR density estimation of three lynx populations across Ukraine and Belarus, including the Ukrainian Chornobyl Exclusion Zone, Southern Belarus, and the Ukrainian Carpathians. Our density estimates varied within our study areas ranging from 0.45 to 1.54 individuals/100 km<sup>2</sup>. This work</span><span> <span>provides a substantial scientific component to the overall understanding of lynx conservation for a region where only broad information is available </span></span><span>and opens the doors for further large-scale monitoring and trend assessments. </span><span>The crucial information we provide can greatly enhance the range-wide assessments of the status of this protected species. We also discuss the implications for Eurasian lynx conservation, despite the geopolitical realities impacting species monitoring in the region. Our work serves as a baseline, not only for future conservation interventions but also to evaluate the effects of disturbance and threats to these protected populations.</span></p>
Improved estimates of carbon dioxide emissions from drained peatlands support a reduction in emission factor
<p>Summary of published carbon dioxide field emission data and their influence factors used for generating Tier 1 emission factor of peat extractions in IPCC 2013 Wetland Supplementary and extra data published after IPCC (2014). </p><p>The dataset is supplementary to the published paper "Improved estimates of carbon dioxide emissions from drained peatlands support a reduction in emission factor" By Hongxing He and Nigel Roulet: He, H., Roulet, N.T. Improved estimates of carbon dioxide emissions from drained peatlands support a reduction in emission factor. <i>Commun Earth Environ</i> <strong>4</strong>, 436 (2023). https://doi.org/10.1038/s43247-023-01091-y. </p><p> </p>
Surface Ozone, NO2, and PM2.5 Concentrations Estimated by the Deep Learning model (Air Transformer) based on Satellite data.
<p>Surface ozone, NO2, and PM2.5 concentrations Estimated by the deep learning model (Air Transformer) based on massive ground-level monitoring, satellite observations, meteorological conditions, dynamic industrial emissions, and other ancillary data from May 2018 to June 2021.</p>
Multi-modal pose estimation in XR applications leveraging integrated sensing and communication: Dataset
<p>This dataset refers to paper Multi-modal pose estimation in XR applications leveraging integrated sensing and communication in workshop of ACM Mobicom. CSI of 3 people performing a set of 8 poses. This dataset contain discrete classes and corresponding CSI data. Kinect poses can be found here (https://github.com/nisarnabeel/multi-modal-pose-estimation-CSI-mmWave).</p> <p> </p> <p>Abstract: Mobile extended reality (XR) applications are anticipated to generate substantial traffic for 6G. Such applications not only require high data rate and low-latency transmissions, but also accurate and real-time pose estimation to enable interactive and immersive experiences. While sub-6 GHz signals have been exploited for pose estimation, they cannot cope up with multi-gigabit data rates required by XR applications. Instead, mobile communications at mmWave frequencies can potentially support data rates up to several giga-bits per second (Gbps) and, therefore, can be used to deliver XR content wirelessly to the Head-Mounted Display (HMD). Moreover, mmWave frequencies can offer improved sensing due to the large available bandwidth. Therefore, mmWave communications can play a crucial role in enabling device-free interactivity by offering both high-speed communication and accurate sensing capabilities. However, mmWave propagation characteristics are different from sub-6 GHz. Path loss plays a significant role, and can lead to degraded sensing performance. Therefore, our proposal supplements wireless sensing at mmWave frequencies with wireless electromyography (EMG) armbands. By capturing patterns of muscle activities, we can counteract the limitations of mmWave-based pose estimation, thereby enriching the granularity and precision of pose estimation. This paper proposes a conceptual architecture to achieve multi-modal pose estimation for XR applications. Early results highlight the shortcomings of mmWave-based sensing, and we identify future steps and opportunities on integration of both approaches.</p>
A simple method to estimate capture height biases at landbird banding stations: opportunities and limitations
<p>Mist-nets are one of the most important tools for the capture of wild birds in ornithological research. The probability of capturing birds may vary by net height, which may drive capture biases. Such biases are rarely estimated, likely because of the relatively high cost and effort associated with constructing and operating elevated mist-net rigs where multiple mist-nets are stacked above one another. Therefore, a low-cost and -effort method to collect capture height data may allow broader investigation and better accounting of potential bias in existing banding protocols. Here, we investigate whether recording net panel of capture (with net panels indicating capture height, e.g., "upper panel") in ground-level mist-nets provides sufficient information to estimate capture height biases and compare these estimations to those obtained with traditional elevated mist-net rigs. Of the 29 taxa analyzed, we detected elevated capture biases for 11 (37.9%) and ground-level capture biases for seven (24.1%). When compared to estimates derived from elevated mist-net rigs at the same study site, we found high agreement with ground-level biases (75.0%) and low agreement with elevated biases (23.1%). These results suggest panel height of ground-level nets is a reliable method to estimate ground-level biases; however, scale of sampling may influence elevated biases, particularly for species that center their activity at the mid-story. Recording panel height may be quickly integrated into a station's processing protocols and broader application may improve our understanding of these biases.</p>
Figs 1–6 in Estimation of biomass of dung beetles (Coleoptera: Scarabaeoidea) from the Russian Far East
Figs 1–6. Models of length-weight relationship and functions for a small dwellers (n=1441)
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.