Approximating Change Sets at Philips Healthcare: A Case Study

1. Approximating Change Sets at Philips Healthcare: A Case Study Adam Vanya Rahul Premraj Hans van Vliet VU University Amsterdam

2. some healthcare products that are subjects of this study...

3. Achieva 3.0T TX

4. Intera 1.5T MRI

5. Panorama HFO

6. Philips MRI Systems • Eight million lines of code across 34,000 ﬁles. • C, C++, and C# used. • Hundreds of developers across 3 sites. • An old version of IBM ClearCase used for version control. • Nine years of version control data available.

8. !"#$%&'(%&)*+,'),-(%,(.*+/+0-

9. “ !"#$%&"$'%()*"#$'+',#-'$ #*'+$,%$-*./,*./$*/0$ ” #1%21#$./$,3#$4&,&"#5

10. “Re-engineering in the large...” Jens Borchers Reengineering from a Practitioner’s View – A Personal Lesson’s Learned Assessment Invited talk at CSMR 2011

11. Re-engineering in the large By functionality By team location By other criteria

12. “ !"#$%"&'$()*+&,-&.)/0& 1&2$3,4$*5&0$.&16$,/& 7%2/&7*8)*+&.01/&1*8& .0"%"&/0"&-%$63"(&)29 ” !"#$%#&%'()%*%+',#+-.&/ .&'01%'2+#3%(04

13. We need data! • Which developers change which ﬁles? • Which functionality is implemented in a ﬁle? • Which sub-systems are often changed together? • ... Change Sets

14. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 31, NO. 6, JUNE 2005 429 Mining Version Histories to Guide Software Changes Thomas Zimmermann, Student Member, IEEE, Peter Weißgerber, Stephan Diehl, and Andreas Zeller, Member, IEEE Computer Society Abstract—We apply data mining to version histories in order to guide programmers along related changes: “Programmers who changed these functions also changed....” Given a set of existing changes, the mined association rules 1) suggest and predict likely further changes, 2) show up item coupling that is undetectable by program analysis, and 3) can prevent errors due to incomplete changes. After an initial change, our ROSE prototype can correctly predict further locations to be changed; the best predictive power is obtained for changes to existing software. In our evaluation based on the history of eight popular open source projects, ROSE’s topmost three suggestions contained a correct location with a likelihood of more than 70 percent. Index Terms—Programming environments/construction tools, distribution, maintenance, enhancement, configuration management, clustering, classification, association rules, data mining.

15. Identifying Transactions A:1.3 B:1.6 C:1.1 D:1.3 E:1.5

16. Identifying Transactions developer: hugo log msg. : Fixed bug #13463 timestamp: Jul 23 2005 02:16:57 A:1.3 B:1.6 C:1.1 D:1.3 E:1.5

17. Identifying Transactions developer: hugo log msg. : Fixed bug #13463 timestamp: Jul 23 2005 02:16:57 A:1.3 B:1.6 C:1.1 D:1.3 E:1.5 same author + same log message

18. Identifying Transactions developer: hugo log msg. : Fixed bug #13463 timestamp: Jul 23 2005 02:16:57 A:1.3 B:1.6 C:1.1 D:1.3 E:1.5 same author + same log message 200 seconds

21. Change Sets Task 1 Task 2 A:1.3 B:1.6 C:1.1 D:1.3 E:1.5 A:1.4 J:1.2 E:1.6

22. Environment at Philips • Developers often commit ﬁles associated to more than one task. • No build-able system required for commit. • Multiple developers may work together for complex tasks.

23. Environment at Philips Developers rarely add commit messages! A:1.3 B:1.6 C:1.1 D:1.3 E:1.5

24. Environment at Philips Developers rarely add commit messages! developer: hugo log msg. : Fixed bug #13463 timestamp: Jul 23 2005 02:16:57 A:1.3 B:1.6 C:1.1 D:1.3 E:1.5

25. Identifying Change Sets

26. Identifying Change Sets 200 seconds

27. Identifying Change Sets 200 seconds

28. Identifying Change Sets 200 seconds 1 hour

29. Identifying Change Sets 200 seconds 1 hour 1 day 1 week 1 month

30. Approximated Change Sets Table I: The Approximated Change Sets (ACS) #Check-ins per ACS δ #ACSs Min. Max. Med. Avg. 200 sec 115487 1 14002 2 8 1 hour 82571 1 14551 2 11 1 day 42447 1 14551 4 22 1 week 13568 1 19404 9 69 1 month 3408 1 27502 27 275

31. Approximated Change Sets #Check-ins per ACS “ !"#$"%&'(%#)*(+,-.%#/% δ #ACSs Min. Max. Med. Avg. ” 200 sec 115487 1 14002 2 8 0(/*%*1%2/(314551 4 22 1 hour 82571 1 day 42447 1 1 14551 2 11 1 week 13568 1 19404 9 69 1 month 3408 1 27502 27 275

32. Evaluating Change Sets ! ! !"#$$%&'(&) *+,'% !"#$%&#$# -(.(/#0("$

34. Developer survey

40. Developer survey • Ten most active developers invited to participate. Eight responded. • Participants briefed on purpose of survey, how change sets were approximated, and possibility to discontinue survey. • Randomly drawn change sets presented. • Developers evaluated 75 change sets.

41. Precision from survey Table II: Precision estimated with help of developers Time interval Precision (in %) #ACS ∗ (δ) Max. Min. Avg. Analyzed Skipped 200 seconds 100 50 91 19 3 1 hour 100 33 91 15 4 1 day 100 40 78 21 4 1 week 100 6 66 14 7 1 month 100 2 36 6 8 ∗ ACS stands for Approximated Change Sets

42. Precision from survey Table II: Precision estimated with help of developers Time interval Precision (in %) #ACS ∗ (δ) Max. Min. Avg. Analyzed Skipped 200 seconds 100 50 91 19 3 1 hour 100 33 91 15 4 1 day 100 40 78 21 4 1 week 100 6 66 14 7 1 month 100 2 36 6 8 ∗ ACS stands for Approximated Change Sets

45. Example Postlist Unique ID <POSTLIST_NAME>nly95872_RFAmpSim_20060103T150114 Stream information <DEVSTREAM>FEMAIN Developer <USER>Anna Date <DATE_DD_MMM_YYYY>3 JAN 2006 Is it a problem report? <PR_SECTION>Y Problem report number <SOLVED_PR>MR00035599 Rationale behind change <REASON_TEXT>Improve simulation of the RF-Amplifier <CODING_STANDARD>N <PNS_SAR>N Developers playing <BBLOCK_OWNER>James a role in the <REVIEWER>Robert review process <TEAMLEADER>David <DOC_SECTION>N Changed files submitted <POSTLIST_FILE>path.to.file.oneBDRFAmplifierNorf.h@@mainfemain5 for review <POSTLIST_FILE>path.to.file.twobdtransmittercsinterfaces.hcf@@main3 <POSTLIST_FILE>path.to.file.threeBDRFAmplifierNorf.cpp@@mainfemain5 <TEST_SECTION>Y <TEST_DONE>@OTM6 Last versions of files <PREVIOUSLY_CONSOLIDATED_FILE>path.to.file.oneBDRFAmplifierNorf.h@@mainfemain2 used to build system <PREVIOUSLY_CONSOLIDATED_FILE>path.to.file.twobdtransmittercsinterfaces.hcf@@main1 <PREVIOUSLY_CONSOLIDATED_FILE>path.to.file.threeBDRFAmplifierNorf.cpp@@mainfemain4

50. <SWID>29 Results from postlists Figure 5: A samp able III: Precision estimated IV: Recall estimated using postlists Table using postlists Time interval Time interval Precision (in %) Recall (in %) (δ) Max. Min. Avg. Max. (δ) Min. Avg. 200 seconds 100 200 seconds 50 93 100 20 74 1 hour 100 20 1 hour 89 100 20 84 1 day 100 1 1 day 69 100 22 92 1 week 100 31 <11 week 100 24 94 1 month 95 <1 month 1 8 100 25 94

51. <SWID>29 Results from postlists Figure 5: A samp able III: Precision estimated IV: Recall estimated using postlists Table using postlists Time interval Time interval Precision (in %) Recall (in %) (δ) Max. Min. Avg. Max. (δ) Min. Avg. 200 seconds 100 200 seconds 50 93 100 20 74 1 hour 100 20 1 hour 89 100 20 84 1 day 100 1 1 day 69 100 22 92 1 week 100 31 <11 week 100 24 94 1 month 95 <1 month 1 8 100 25 94

52. So, what works? • The one hour time interval works best for our environment. • Optimal time interval may differ from one environment to another.

53. Threats to validity • Assumed developers have a good recall of their own change sets. • Postlists were carefully selected, but in rare cases may relate to more than one change set. • Change sets with multiple developers involved were not captured completely.

54. Summary

55. Summary

56. Summary re- r p u y o lu a te a ta E v a e d d c e s s pr o s e ! re u b e fo

Approximating Change Sets at Philips Healthcare: A Case Study

More Related Content

Similar to Approximating Change Sets at Philips Healthcare: A Case Study (20)

More from Rahul Premraj (7)

Recently uploaded (20)

Approximating Change Sets at Philips Healthcare: A Case Study

Editor's Notes