Skip to main contentCal State San Bernardino
>> [CNS] >> [Comp Sci Dept] >> [R J Botting] >> [New Bibliographic Items] >> newb0811 [Blog/News] || [Purpose] || [Notation] || [Copyright] || [Site Search] || [Bibliography Search]
Thu Aug 18 11:36:05 PDT 2005

Contents


    PurushothamanPerry05

    1. Ranjith Purushothaman & Dewayne E Perry
    2. Toward Understanding the Rhetoric of Small Source Code Changes
    3. IEEE Trans Software Engineering V31n6(Jun 2005)pp510-526
    4. =CASE STUDY 5ESS TECHNICAL CODE DELTAS ERRORS
    5. 40% of changes to code are erroneous(need to be changed after testing).
    6. The size(LoC) and type(add, delete, modify) of changes seems to effect the chance that they are erroneous.
    7. 10% are one line patches. Only 4% of these are erroneous.
    8. (dick) |- from 2..11 LoC roughly 1% added per LoC.
    9. 0 errors in deleting up to 10.LoC.

    Dinh-TrongBieman05

    1. Trung T Dinh-Trong & James M Bieman
    2. The FreeBSD Project: A Replication Case Study of Open Source Development
    3. IEEE Trans Software Engineering V31n6(Jun 2005)pp481-494
    4. =POLL OPEN SOURCE PROCESS FreeBSD GNATS
    5. Replicates [MockusFieldingHerbsled02]
    6. FreeBSD has been developing for 10 years.
    7. A small group of up to 15 developers controlled the code base. No more than 50 top developers contributed most of the functionality.
    8. Some ceremony was needed to coordinate work but it is neither imposed nor verified.
    9. A larger group repairs defects fed by an even larger group of developers who report problems,
    10. A mechanism for separating stable from unstable code means that stable code will have a lower defect density than commercial feature tested code.
    11. The developers were users.

    WilliamsHollingsworth05

    1. Chadd C Williams & Jeffrey K Hollingsworth
    2. Automatic Mining of Source Code Repositories to improve Bug finding techniques
    3. IEEE Trans Software Engineering V31n6(Jun 2005)pp466-480
    4. =CASE STUDY CODE ANALYSIS TOOL SQA CVS APACHE WINE
    5. A tool to spot likely defects can be improved by using historical information on previous fixes.
    6. Class of bug: not testing the value returned by a function call to see if it is special or not.
    7. By selecting unchecked calls to functions with previously fixed defects warns accurately 40% of the time. Without history the % is much lower.

    CubranicMurphySingerBooth05

    1. Davor Cubranic & Gail C Murphy & Janice Singer & Kellog S Booth
    2. Hipikat: A Project memory for Software Development
    3. IEEE Trans Software Engineering V31n6(Jun 2005)pp429-526
    4. =ADVERT TOOL EVOLUTION DOCUMENTATION WWW EMAIL CVS BUGZILLA
    5. Hipikat tool analyzes artifacts gathered in Eclipse development and provides readings to newcomers with maintenance tasks.

    ZimmermannWeibgerberDiehlZeller05

    1. Thomas Zimmermann & Peter Weibgerber & Stephan Diehl & Andreas Zeller
    2. Mining Version Histories to Guide Software Changes
    3. IEEE Trans Software Engineering V31n6(Jun 2005)pp429-526
    4. =EMPIRICAL EVOLUTION OPEN SOURCE TOOL ROSE CVS ECLIPSE GCC GIMP JBOSS JEDIT KOFFICE POSTGRES PYTHON
    5. ROSE::Eclipse_plugin= See http://www.st.cs.uni-sb.de/softevo/
    6. By analyzing data collected from version histories can predict what else is likely to be changed if one location is changed. Top 3 predictions cover correct predictions 79% of the time.
    7. Detects undocumented couplings.
    8. May help prevent incomplete/inconsistent changes. Few false alarms.
    9. Fine grain prediction works best on stable systems. But even unstable systems the files can be predicted,
    10. Works best in maintenance.

End