Find research datasets worth reusing

opencc-zeroApr 2024View details →

Piecewise continuous sampling: a method for minimizing bias and sampling effort for estimated metrics of animal behavior

Capturing qualitative features of animal behavior requires recording occurrences of behavior over time. Continuous sampling is best for capturing brief behaviors, but can be very time consuming. Instantaneous sampling can reduce the amount of labor required, but can miss short-duration behaviors. We therefore synthesized these techniques by continuously sampling during randomly scattered time intervals; a technique we call piecewise continuous sampling. To optimize and test the efficacy of this technique, we collected a continuous behavioral dataset of harvester ant workers, and then we developed a protocol to estimate the amount of sampling time necessary to reconstruct the proportion of time animals spend in different behavioral states. This protocol finds the sample size needed for the variance of the sample to converge on the variation of the population. We then divided this estimated time into equal-duration intervals that were randomly distributed across the entire continuous dataset. Finally, we calculated both time-dependent and time-independent error from this sample. We found that 4 to 16 sampling intervals minimize both types of error simultaneously. This finding was robust to differences in underlying behavior and was validated with simulations, implying that this method could be used for many types of organisms.

opencc-zeroMar 2022View details →

SSP: An R package to estimate sampling effort in studies of ecological communities

SSP (simulation-based sampling protocol) is an R package that uses simulations of ecological data and dissimilarity-based multivariate standard error (MultSE) as an estimator of precision to evaluate the adequacy of different sampling efforts for studies that will test hypothesis using permutational multivariate analysis of variance. The procedure consists in simulating several extensive data matrixes that mimic some of the relevant ecological features of the community of interest using a pilot data set. For each simulated data, several sampling efforts are repeatedly executed and MultSE calculated. The mean value, 0.025 and 0.975 quantiles of MultSE for each sampling effort across all simulated data are then estimated and standardized regarding the lowest sampling effort. The optimal sampling effort is identified as that in which the increase in sampling effort does not improve the highest MultSE beyond a threshold value (e.g. 2.5 %). The performance of SSP was validated using real data. In all three cases, the simulated data mimicked the real data and allowed to evaluate the relationship MultSE – n beyond the sampling size of the pilot studies. SSP can be used to estimate sample size in a wide variety of situations, ranging from simple (e.g. single site) to more complex (e.g. several sites for different habitats) experimental designs. The latter constitutes an important advantage in the context of multi-scale studies in ecology. An online version of SSP is available for users without an R background.

zenodo40/100

JOSSE: A Software Development Effort Dataset Annotated with Expert Estimates

The JIRA Open-Source Software Effort (JOSSE) dataset consists of software development and maintenance tasks collected from the JIRA issue tracking system for Apache, JBoss, And Spring open-source projects. All the issues were annotated with actual effort and 19% of them were annotated with expert estimates. JOSSE is a task-based dataset with a textual attribute represented as a task description for each data point. This paper explains how the data were collected and details six data quality refinement procedures of the data points.

opencc-by-4.0Aug 2022View details →

zenodo40/100

Figure. Observed (S obs) and estimated species richness for Chao 2, Jackknife 2, and Bootstrap, calculated for Lumbricidae in East Serbia. Vertical dashed lines represent 50%, 75%, and 100% of the sampling effort, respectively. in A nonparametric approach in quantifying species richness of Lumbricidae in East Serbia, Balkan Peninsula

Figure. Observed (S obs) and estimated species richness for Chao 2, Jackknife 2, and Bootstrap, calculated for Lumbricidae in East Serbia. Vertical dashed lines represent 50%, 75%, and 100% of the sampling effort, respectively.

opencc-by-4.0Oct 2016View details →

publicMar 2022View details →

SSP: An R package to estimate sampling effort in studies of ecological communities

Open the record for dataset details and reuse information.

publicApr 2024View details →

Piecewise continuous sampling: a method for minimizing bias and sampling effort for estimated metrics of animal behavior

Open the record for dataset details and reuse information.

publicNov 2024View details →

A new Double Observer based census framework to improve abundance estimations in mountain ungulates and other gregarious species with a reduced effort

Open the record for dataset details and reuse information.

opencc-by-4.0Nov 2012View details →

Effort Estimation: Cosmic

Reference The International Software Benchmarking Standards Group Limited, ISBSG http://www.isbsg.org) Attributes: -------------------------------------------------------- ISBSG Attributes Attributes 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 -------------------------------------------------------- 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.

opencc-by-4.0Apr 2010View details →

Effort Estimation: Albrecht

Dataset used for Effort Estimation Reference 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

opencc-by-4.0Mar 2009View details →

Effort Estimation: Maxwell

Dataset for Effort Estimation Reference 1 K. D. Maxwell. 2002. Applied Statistics for Software Managers. Englewood Cliffs, NJ. Prentice-Hall. 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. 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. 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.

opencc-by-4.0Mar 2015View details →

Effort Estimation: openeffort

Data 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 Author Activity Data -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 Survey Response Data 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) 2) Selection: How much of the time you spent in the project is devoted to coding? (>95%, approx. 75%, approx. 50%, approx. 25%, <10%) 3) Selection: Do you make at least one commit to the repository the days you code? (yes, no) 4) Selection: What do you consider yourself in the project? (full-time, part-time, occasional contributor) 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) ``` The anonymized survey response data is here 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.

opencc-zeroMar 2024View details →

Estimating human joint moments unifies exoskeleton control and reduces user effort

Robotic lower-limb exoskeletons can augment human mobility, but current systems require extensive, context-specific considerations, limiting their real-world viability. Here, we present a unified exoskeleton control framework that autonomously adapts assistance based on instantaneous user joint moment estimates from a temporal convolutional network (TCN). When deployed on our hip exoskeleton, the TCN achieved an average RMSE of 0.142 ± 0.021 Nm/kg and R2 of 0.840 ± 0.045 across 35 ambulatory conditions without any subject-specific calibration. Further, the unified controller significantly reduced user metabolic cost and lower-limb positive work during level ground and incline walking compared to walking without wearing the exoskeleton (P < 0.05). This advancement bridges the gap between in-lab exoskeleton technology and real-world human ambulation, making exoskeleton control technology viable for a broad community.

opencc-by-nc-sa-2.0Jul 2021View details →

Raw data and scripts for "The Period-Modulated Harmonic Locked Loop (PM-HLL): A low-effort algorithm for rapid time-domain multi-periodicity estimation"

This package contains all required scripts to generate the simulations and figures from the study "The Period-Modulated Harmonic Locked Loop (PM-HLL): A low-effort algorithm for rapid time-domain multi-periodicity estimation" by Volker Hohmann, published in Acta Acustica: The Period-Modulated Harmonic Locked Loop (PM-HLL): A low-effort algorithm for rapid time-domain multi-periodicity estimation Volker  Hohmann Acta Acust. 5 56 (2021) DOI: 10.1051/aacus/2021050 When referring to this work, please cite the journal paper. Note that additive noise is generated at random, i.e., small differences in the estimation accuracy occur when repeating a simulation. For further details see the journal paper. Thank you for downloading the package. Your comments are very welcome! Method patented: DE Patent DE102021207339B3 Author: Volker Hohmann, Carl von Ossietzky Universität Oldenburg, Germany

opencc-zeroDec 2017View details →

Data from: Effects of sampling effort on biodiversity patterns estimated from environmental DNA metabarcoding surveys

Environmental DNA (eDNA) metabarcoding can greatly enhance our understanding of global biodiversity and our ability to detect rare or cryptic species. However, sampling effort must be considered when interpreting results from these surveys. We explored how sampling effort influenced biodiversity patterns and nonindigenous species (NIS) detection in an eDNA metabarcoding survey of four commercial ports. Overall, we captured sequences from 18 metazoan phyla with minimal differences in taxonomic coverage between 18 S and COI primer sets. While community dissimilarity patterns were consistent across primers and sampling effort, richness patterns were not, suggesting that richness estimates are extremely sensitive to primer choice and sampling effort. The survey detected 64 potential NIS, with COI identifying more known NIS from port checklists but 18 S identifying more operational taxonomic units shared between three or more ports that represent un-recorded potential NIS. Overall, we conclude that eDNA metabarcoding surveys can reveal global similarity patterns among ports across a broad array of taxa and can also detect potential NIS in these key habitats. However, richness estimates and species assignments require caution. Based on results of this study, we make several recommendations for port eDNA sampling design and suggest several areas for future research.

publicMay 2019View details →

Data from: Effects of sampling effort on biodiversity patterns estimated from environmental DNA metabarcoding surveys

Open the record for dataset details and reuse information.