1,721,087 research outputs found

    am1

    No full text
    Reference Audris Mockus. Software support tools and experimental work. In Empirical Software Engineering Issues: Critical Assessments and Future Directions, pages 91-99. Springer LNCS, 2007 About There a common type of dataset generated by virtually any software project. Better understanding of software projects can lead to actual improvements on how software is created, presenting the state and history of projects can improve project management by preventing the lest rational, but, unfortunately, too common management decisions. Data description contains three parts: # Files and formats # Explanation of individual fields # Domain background The data has a number of features and dependencies that are too numerous to describe. Files and formats mrsheader and records all semicolon separatedmrs.xmldata in the ggobi XML formatmrs.txtheader and records all tab separated. Character strings were converted to integers (see mrs.xml for the mapping between integers and strings they represent.) Some stat/vis packages prefer only numeric data, so this file was created to facilitate analysis. Please note that MRs that are submitted to several software releases appear several times in the table below, with all attributes repeated except for the release name. Individual fields MR : Modification request - a tag used to track a software work item orgID : login of the person originating this MR (could be a customer representative reporting a problem, tester, developer). Please note that all the logins are mapped to logins from a different project to preserve confidentiality of the original project participants. crID : login of the person creating this MR. devID : login of the person working on this MR The person who investigates and makes necessary changes (if any) to complete this MR. origDate, crDate, submtDate, apprDate : Dates (expressed as seconds since 00:00, Jan 1, 1970) of when MR was originated, created, submitted by developer, and, finally, approved. Release : The software release (a big thing, like win 95, win98, win200) Build : The software build (builds occur about weekly, as you will discover). System : The name of the software module (slightly edited for confidentiality) Severity : 1 - critical, 2 - high, 3 - medium, 4 - low Status : The current status of the MR as of 24/09/2003. !PhaseDetected : when in the development process this MR was discovered. Category : It should tell us if the MR is a new feature or a fix, but instead it is a hodgepodge of MR category, phase detected, and othervalues that appeared appropriate to different developers at different times. It has the following values: inspection, maintenance, discussion, document_reading, code_reading field_enh, usage, new_feature, review, testing, field_mod Class : is it software, hardware, or documentation MR !BugNew : purpose - b: bug fix, n: new feature, c - cleanup, 0 - not clear nFiles : number of files modified by this MR nDelta : number of delta (atomic modification of a file) associated by this MR linesAdded : number of lines added by this MR linesDeleted : number of lines deleted by this MR Background Problem tracking (PR) and version control systems (VCS) are used by virtually all software projects to coordinate the work of the project participants and to allow parallel work on several releases and patches. This dataset is a typical example of the data that is usually available from VSC and PR systems. A slightly simplified version of an MR process follows. The developers are assigned a new feature or a defect to work on. In case of defects, they investigate the problem, make necessary changes and submit an MR for integration. In case of new features, additional tasks such as low level design and design review are performed prior to coding. After coding is complete the MR is submitted for integration by the developer. The code inspection is done afterward and any issues are resolved with additional MRs. If an MR is opened by a tester, it may take some time until someone is assigned to work on it and eventually starts working on it. In this case the MR open time may significantly precede the time when the work started. Often developers will find an issue to work on in the regular course of their activities. They may investigate the issue, complete the necessary changes in their private workspaces, and then open and immediately submit an MR for integration. In this case opening an MR does not precede the start of work. Questions There are three basic questions in software projects: When will it be ready (will have desired functionality and minimal quality)? How much will it cost (in developers time)? What should we do to achieve desired quality/effort/dates? (E.g., drop features, delay release, test more) More specifically, how to show and summarize the quality, the current state, and the effort that went into a software release, or a build, or a system. What is the relationship (over time, because there is no direct relationship data) between MRs

    what make long term contributors -- mozilla and gnome

    No full text
    <p>Data and scripts for: </p> <p>Minghui Zhou, Audris Mockus: Who Will Stay in the FLOSS Community? Modeling Participant's Initial Behavior. Software Engineering, IEEE Transactions on , vol.41, no.1, pp.82-99, Jan. 1 2015.</p> <p>Minghui Zhou and Audris Mockus. What Make Long Term Contributors: Willingness and Opportunity in OSS Community. ICSE '12 Proceedings of the 34rd International Conference on Software Engineering, Zurich, Switzerland, 2-9 June 2012, pp.518-528.</p> <p> </p&gt

    Dataset of Grouped Commit Author IDs after Identity Resolution

    No full text
    This Dataset contains the IDs of 5,427,024 commit authors who have created commits in git version control system, and have more than 1 ID in git. It is a compressed CSV file (separated by ; ) with 14,861,538 author IDs, where the first column is the group ID, which is same as the first (randomly selected) author ID of the group, and the second column is the author ID that is part of the group. If an author was found to have 2 different IDs: I1, I2, then it is recorded in the file in 2 separate lines, with the lines being I1;I1 and I1;I2, i.e. the first column is the group identifier, which is one of the IDs in a group, and the second column contains the different author IDs in separate lines.</p

    Dataset of Grouped Commit Author IDs after Identity Resolution

    No full text
    This Dataset contains the SHA1 values of IDs for 5,427,024 commit authors who have created commits in git version control system, and have more than 1 ID in git. It is a compressed CSV file (separated by ; ) with 14,861,538 author IDs, where the first column is the group ID, which is same as the first (randomly selected) author ID of the group, and the second column is the author ID that is part of the group. If an author was found to have 2 different IDs: I1, I2, then it is recorded in the file in 2 separate lines, with the lines being I1;I1 and I1;I2, i.e. the first column is the group identifier, which is one of the IDs in a group, and the second column contains the different author IDs in separate lines. Author IDs consist of the Author's name and email address in the format: Name .</p

    Defect prediction and software risk

    No full text

    Organizational volatility and its effects on software defects

    Get PDF

    Missing Data in Software Engineering

    No full text

    Software Support Tools and Experimental Work

    No full text

    Analogy Based Prediction of Work Item Flow in Software Projects

    No full text
    Software development project coordinates work by using work items that represent customer, tester, and developer found defects, enhancements, and new features. We set out to facilitate software project planning by modeling the flow of such work items and using information on historic projects to predict the work flow of an ongoing project. The history of the work items is extracted from problem tracking or configuration management databases. The web-based prediction tool allows project managers to select most relevant past projects and adjust the prediction based on staffing, type, and schedule of the ongoing project. We present the workflow model, and briefly describe a web based prediction tool applied to a large software project for Customer Relationship Management (CRM)
    corecore