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.
580
datasets available to search
ShareScore release 0.9.0
Dataset results
580 results for “Effort”
Baseline Water Quality Monitoring to support restoration efforts in the Cache Slough Complex, 2013-2021.
The Cache Slough Complex is an ecologically significant area, with many restoration efforts of various kinds set to take place within its boundaries. These efforts which are tied to regulations set forth by the Biological Opinion, will have unknown impacts to in‐stream water quality. For this reason, the Department of Water Resources’ Water Quality Assessment (WQA) unit developed a monitoring program to establish baseline water quality measurements to help understand the environmental impact of these restoration projects and ensure pre‐restoration water quality data is available to compare against post-restoration water quality. To do so, data was collected at various sites that represent all major inputs and outflows within the Cache Slough Complex from September 2013 to December 2021.
Data from: Extending full protection inside existing marine protected areas or reducing fishing effort outside can reconcile conservation and fisheries goals
<p>1. Most fish stocks worldwide are fished at maximum sustainable yield (MSY) or overfished, as many fisheries management strategies have failed to achieve sustainable fishing. Identifying effective fisheries management strategies has now become urgent.</p> <p>2. Here, we developed a spatially-explicit metapopulation model accounting for population connectivity in the north-western Mediterranean Sea, and parameterized it for three ecologically and economically important coastal fish species: the white seabream <i>Diplodus sargus</i>, the two-banded seabream <i>Diplodus vulgaris</i> and the dusky grouper <i>Epinephelus marginatus</i>.</p> <p>3. We used the model to assess how stock biomass and catches respond to changes in fishing mortality rate (<i>F</i>) and in the size of fully protected areas within the existing system of multiple-use marine protected areas (MPAs). For each species, we estimated MSY and the corresponding values of stock biomass (<i>B</i><sub>MSY</sub>) and fishing mortality rate (<i>F</i><sub>MSY</sub>), providing crucial reference points for the assessment of fisheries management.</p> <p>4. <i>D. sargus</i> is currently in low overfishing, while <i>D. vulgaris</i> and <i>E. marginatus</i> are in high overfishing. Stock recovery to <i>B</i><sub>MSY</sub> for the last two species requires a reduction of current <i>F</i> around 50%. This would guarantee an increase in both stock biomass (around 50 and 75% for <i>D. vulgaris</i> and <i>E. marginatus</i>, respectively) and catch (around 15 and 30%) after a transient time of ~15–30 years. Alternatively, doubling the size of fully protected areas over fishable areas within the existing network of MPAs would lead to positive conservation effects for all three species without substantially affecting the overall productivity of the fishery and the total economic value of the catch.</p> <p>5. <i>Synthesis and applications.</i> We provide the first assessment of stock status for three coastal species in the north-western Mediterranean and evaluate the ecological and fisheries outcomes of different management strategies. Extending full protection inside existing multiple-use marine protected areas or reducing fishing effort outside can deliver both conservation and fisheries benefits.</p>
Decision making in slow and rapid reaching: Sacrificing success to minimize effort
<p>Datasets associated with the following publication:</p> <p>Hesse, C., Kangur, K., & Hunt, A. (2020). Decision making in slow and rapid reaching: Sacrificing success to minimize effort. Cognition</p> <p>The folder contains data files for each of the Experiments as presented in the article. There is a separate description file providing further relevant information for the data files uploaded for each experiment.</p> <p>For further questions, please contact:<br> c.hesse[at]abdn.ac.uk</p>
Can behaviour impede evolution? persistence of singing effort after morphological song loss in crickets
<p>Evolutionary loss of sexual signals is widespread. Examining the consequences for behaviours associated with such signals can provide insight into factors promoting or inhibiting trait loss. We tested whether a behavioural component of a sexual trait, male calling effort, has been evolutionary reduced in silent populations of Hawaiian field crickets (<em>Teleogryllus oceanicus</em>). Cricket song requires energetically costly wing movements, but 'flatwing' males have feminised wings that preclude song and protect against a lethal, eavesdropping parasitoid. Flatwing males express wing movement patterns associated with singing but, in contrast to normal-wing males, sustained periods of wing movement cannot confer sexual selection benefits and should be subject to strong negative selection. We developed an automated technique to quantify how long males spend expressing wing movements associated with song. We compared calling effort among populations of Hawaiian crickets with differing proportions of silent males, and between male morphs. Contrary to expectation, silent populations invested as much in calling effort as non-silent populations. Additionally, flatwing and normal-wing males did not differ in calling effort. The lack of evolved behavioural adjustment following morphological change in silent Hawaiian crickets illustrates how behaviour might sometimes impede, rather than facilitate, evolution.</p>
Which pitfall traps and sampling effort to choose to evaluate cropping system effects on spider and carabid assemblages?
<p>Dataset and example of the script (R) used in the simulation approach.</p>
Effort data from the FLT Mediterranean Network 2008-2018
<p>Effort data used for the analysis presented in the manuscript "Trends in summer presence of fin whales in the Western Mediterranean Sea Region: new insights from a long-term monitoring program" - submitted for publication on PeerJ. </p> <p>Shape file represent transect monitored under favourable weather condition (sea state <=4) using ferries as platform of opportunity.</p>
Sex-specific patterns of senescence in artificial insect populations varying in sex-ratio to manipulate reproductive effort
<p><strong>Background:</strong> The disposable soma theory of ageing assumes that organisms optimally trade-off limited resources between reproduction and longevity to maximize fitness. Early reproduction should especially trade-off against late reproduction and longevity because of reduced investment into somatic protection, including immunity. Moreover, as optimal reproductive strategies of males and females differ, sexually dimorphic patterns of senescence may evolve. In particular, as males gain fitness through mating success, sexual competition should be a major factor accelerating male senescence. In a single experiment, we examined these possibilities by establishing artificial populations of the mealworm beetle, <em>Tenebrio molitor</em>, in which we manipulated the sex-ratio to generate variable levels of investment into reproductive effort and sexual competition in males and females.</p> <p><strong>Results:</strong> As predicted, variation in sex-ratio affected male and female reproductive efforts, with contrasted sex-specific trade-offs between lifetime reproduction, survival and immunity. High effort of reproduction accelerated mortality in females, without affecting immunity, but high early reproductive success was observed only in balanced sex-ratio condition. Male reproduction was costly on longevity and immunity, mainly because of their investment into copulations rather than in sexual competition.</p> <p><strong>Conclusions:</strong> Our results suggest that <em>T. molitor</em> males, like females, maximize fitness through enhanced longevity, partly explaining their comparable longevity. </p>
Raw data for the research article "Rasch analysis of the Listening Effort Questionnaire - Cochlear Implant (LEQ-CI)"
<p>These are the raw data for the paper entitled "Rasch analysis of the Listening Effort Questionnaire - Cochlear Implant (LEQ-CI)" that is currently under revision in Ear and Hearing.</p>
Data from: Specialisation reduces foraging effort and improves breeding performance in a generalist bird
While competition is generally presumed to promote intraspecific niche diversification, populations of many apparent generalist species still exhibit considerable individual variation in foraging specialisation. This suggests that different cost-benefit trade-offs may underlie individual variation in foraging specialisation. Indeed, while specialisation may improve foraging efficiency by a better knowledge of the spatio-temporal availability of resources, individuals may also become more vulnerable to fluctuations in these resources. In this study, we used multi-year GPS tracking data of 19 Herring Gulls (Larus argentatus) breeding along the Belgian coast to assess whether foraging effort and reproductive success varied among different levels of foraging specialisation. First, we quantified spatial and habitat specialisation during incubation and chick-rearing for 31 individual breeding cycles during which birds raised young until the age of 21 days. Next, we tested whether spatial and habitat specialisation were related to the daily distance covered (as a proxy for foraging effort), and to chick growth (as a proxy for reproductive success). We found that birds primarily varied in their extent of habitat specialisation. Habitat specialisation was associated with reduced daily distances covered and increased offspring growth rates, in particular the growth rate of the youngest chicks. Yet, positive effects of habitat specialisation on chick growth decreased at high levels of spatial specialisation. Our results thus demonstrate fitness benefits of foraging specialisation during our five-year study period, but also highlight the need for longer-term studies as environmental changes may cause benefits to vary throughout a lifetime.
Data from: Effects of arthropod inquilines on growth and reproductive effort among metacommunities of the purple pitcher plant (Sarracenia purpurea var. montana)
<p>Many plant species harbor communities of symbionts that release nutrients used by their host plants. However, the importance of these nutrients to plant growth and reproductive effort is not well understood. Here, we evaluate the relationship between the communities that colonize pitcher plant phytotelmata and the pitcher plants' vegetative growth and flower production to better understand the symbiotic role played by phytotelma communities. We focus on the mountain variety purple pitcher plant (Sarracenia purpurea var. montana), which occurs in small and isolated populations in Western North Carolina. We found that greater symbiont community diversity is associated with higher flower production the following season. We then examined geographic variation in communities and found that smaller plant populations supported less diverse symbiont communities. We relate our observations to patterns of community diversity predicted by community ecology theory.</p>
Baha'i Temple from Video - second effort
Second "good" reconstruction of Baha'i Temple near Chicago from 4K video (YouTube). Used 251 images from video saved in TIFF format. COLMAP & openMVS for 3-D reconstruction (where used hidden "mesh-file" option in openMVS to select the smaller region shown here to refine and texture). Still had to decimate the model (a little, I used MeshLab) to get to the 50 mb limit for free Sketchfab account :). The dome details are much improved over the prior model I posted. Source: Objaverse 1.0 / Sketchfab
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 and source code for ICSME2017 paper "Supervised vs Unsupervised Models: A Holistic Look at Effort-Aware Just-in-Time Defect Prediction"
<p>Dataset and source code for ICSME2017 paper “Supervised vs Unsupervised Models: A Holistic Look at Effort-Aware Just-in-Time Defect Prediction”</p> <p>There are four different models in the paper (i.e., EALR, LT, CBS and OneWay). Each model was implemented in a single Java file in the model package. To reproduce the experiment results of each model in the paper, just run the main method in the corresponding Java file. </p> <p> </p>
Government Digitalisation Efforts survey Thailand 2024
<div> <p>The dataset is collected based on a modified Digital government performance questionnaire prepared by the OECD. The questionnaire analyses the use of digital tools and the level of digitalisation of the public sector in Thailand.</p> </div>
Bridging the Divide: Connecting Language Activist Efforts and Language Archives
<p>Bridging the Divide: Connecting Language Activist Efforts and Language Archives</p> <p>Subhashish Panigrahi, Mandana Seyfeddinipur and Susan Kung at the Language Documentation and Archiving conference in the Berlin-Brandenburg Academy of Sciences and Humanities on October 6. 2022</p> <p>Language documentation, revitalization, reclamation, and activism efforts take place all over the world. At the local, grassroots, community and international levels, participants have taken agency and self-organised to engage in these activities to create a documentary record of their own languages, to preserve cultural and linguistic richness, and to reclaim ownership of and control over their languages and cultures, ensuring data sovereignty. In academia, linguists have developed theoretical methods for linguistic language documentation and have created language archives housed at universities. Language activists have created language documentation training materials, organised projects in the Wikimedia ecosystem, formed nonprofits and NGOs, and used social media platforms to self-organise and share their materials. However, many of these grassroots efforts lack access to stable archives that can provide long-term digital preservation of these unique and invaluable materials. Simultaneously, language archives based at universities could provide long-term preservation but lack the connection to activists. In this presentation, we showcase some of these community-based efforts, and we argue for the need to bridge the divide between academically based archives and the "real world" in order to ensure that all language documentation efforts will be preserved for the long-term and accessible and available to all peoples well into the future. We also share examples demonstrating how different kinds of archives fit into the needs and expertise levels of different local activist groups. While taking into account some of the existing practices of community-led efforts for sharing materials online that are more convenient and have better visibility among the viewers, we illustrate the skill development and resource allocation that would be required to migrate to long-term archives. We also discuss the current entry-level barriers of archives that need mitigation for forging activism-academic collaborations and paving the path for robust archives while ensuring the agency of speakers.</p>
Data from: Advances and shortfalls in applying best practices to global tree-growing efforts
<p>As global tree-growing efforts have escalated in the past decade, copious failures and unintended consequences have prompted many reforestation best practices guidelines. The extent to which organizations have integrated these ecological and socioeconomic recommendations, however, remains uncertain. We reviewed websites of 99 intermediary organizations that promote and fund tree-growing projects to determine how well they report following best practices. Nearly half the organizations stated tree or area planting targets, but only 25% had measurable, time-bound objectives. Most organizations discussed the benefits local communities would receive from trees, but only 38% reported measures of these outcomes. Non-profit organizations with greater prior experience converged more closely on best practices, and their level of scientific expertise was positively associated with clearer project selection standards. Although many tree-growing organizations acknowledge the importance of clear goals, local community involvement, and monitoring, our results raise questions regarding whether long-term benefits are being achieved and emphasize the need for stronger public accountability standards.</p>
A global meta-analysis of yield-scaled N2O emissions and its mitigation efforts for maize, wheat, and rice
<p>Maintaining or even increasing crop yields while reducing nitrous oxide (N<sub>2</sub>O) emissions is necessary to reconcile food security and climate change, while the metric of yield-scaled N<sub>2</sub>O emission (i.e., N<sub>2</sub>O emissions per unit of crop yield) is at present poorly understood. Here we conducted a global meta-analysis with more than 6000 observations to explore the variation patterns and controlling factors of yield-scaled N<sub>2</sub>O emissions for maize, wheat, and rice and associated potential mitigation options. Our results showed that the average yield-scaled N<sub>2</sub>O emissions across all available data followed the order wheat (322 g N Mg<sup>-1</sup>, with the 95% confidence interval (CI): 301-346) > maize (211 g N Mg<sup>-1</sup>, CI: 198-225) > rice (153 g N Mg<sup>-1</sup>, CI: 144-163). Yield-scaled N<sub>2</sub>O emissions for individual crops were generally higher in tropical or subtropical zones than in temperate zones, and also showed a trend towards lower intensities from low to high latitudes. This global variation was better explained by climatic and edaphic factors than by N fertilizer management, while their combined effect predicted more than 70% of the variance. Furthermore, our analysis showed a significant decrease in yield-scaled N<sub>2</sub>O emissions with increasing N use efficiency or in N<sub>2</sub>O emissions for production systems with cereal yields > 10 Mg ha<sup>-1</sup> (maize), 6.6 Mg ha<sup>-1</sup> (wheat) or 6.8 Mg ha<sup>-1</sup> (rice), respectively. This highlights that N use efficiency indicators can be used as valuable proxies for reconciling trade-offs between crop production and N<sub>2</sub>O mitigation. For all three major staple crops, reducing N fertilization by up to 30%, optimizing the timing and placement of fertilizer application or using enhanced-efficiency N fertilizers significantly reduced yield-scaled N<sub>2</sub>O emissions at similar or even higher cereal yields. Our data-driven assessment provides some key guidance for developing effective and targeted mitigation and adaptation strategies for the sustainable intensification of cereal production.</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.