2015.07.26 08:35

9년이 지난후 Defect prediction 2.0

2006년 Adaptive Bug Prediction By Analyzing Software History 이라는 이름으로 박사논문 발표를 했었는데, 9년이 지난 2015년, 저희 연구실 남재창 박사가 Defect prediction 연구를 한수준 끌어 올리며 박사 defence 를 했습니다. Defect prediction 2.0 이라 불러 줄만 합니다. 그동안 관련 연구를 하면서 소프트웨어 공학 최고 수준인 FSE에 3개, ICSE 2개, ASE에 하나 논문을 발표하고 졸업을 합니다. SIGSOFT 논문상을 1회 수상했고, 한번은 후보에 들어 이 연구들이 얼마나 멋진 것인지 보여 줍니다.


  1. Micro Interaction Metrics for Defect Prediction@FSE`11, Taek Lee, Jaechang Nam, Donggyun Han, Sunghun Kim and Hoh Peter In
  2. Transfer Defect Learning@ICSE`13, Jaechang Nam, Sinno Jialin Pan and Sunghun Kim, Nominee, ACM SIGSOFT Distinguished Paper Award
  3. Heterogeneous Defect Prediction@FSE`15, Jaechang Nam ann Sunghun Kim
  4. REMI: Defect Prediction for Efficient API Testing@FSE`15, Mijung Kim, Jaechang Nam, Jaehyuk Yeon, Soonhwang Choi, and Sunghun Kim, Industrial Track
  5. CLAMI: Defect Prediction on Unlabeled Datasets@ASE`15, Jaechang Nam and Sunghun Kim
  6. Automatic Patch Generation Learned from Human-written Patches@ICSE`13, Dongsun Kim, Jaechang Nam, Jaewoo Song and Sunghun Kim, ACM SIGSOFT Distinguished Paper Award Winner

남재창 박사는 캐나다 최고 연구 대학인 워털루에서, 떠오르는 별인 Lin Tan교수님과 함께 포닥으로 몇년 연구하고, 곧 멋진 교수님이 될 예정입니다. 


아래 남재창 박사의 슬라이드 입니다.



제가 발표한 2006년 발표한 박사 연구 결과에 비해 한단계 높은 수준임을 보실수 있습니다.



혹시 소프트웨어 공학연구에 관심이 있으시면서 defect prediction 3.0의 연구를 주도하실분있으시면 김성훈 <hunkim@gmail.com>으로 연락해 보시기 바랍니다.

저작자 표시 비영리 변경 금지
신고
트랙백이 없고 Comment 2
  1. 2015.08.18 01:59 address edit & del reply

    비밀댓글입니다

    • HannaKim 2015.08.19 16:06 신고 address edit & del

      오타 알려 주셔서 감사합니다. 수정하였습니다.

2012.11.22 18:43

'12년 감사제목 12가지 (Thanksgiving 특집)

매해 이맘때가 되면 제가 박사과정 하던 시절에 지도교수님께서 같이 있던 박사과정 학생들을 위해 Thanksgiving party 를 열어 주시면서 감사제목을 나누던 시간들이 생각납니다. 그땐 정말 힘든일도 많았는데 그런중에도 감사할것을 찾으려고 노력을 많이 했던 기억도 납니다. 


2009 (http://www.se.or.kr/38), 2010 (http://www.se.or.kr/68), 2011 (http://www.se.or.kr/95) 년에도 감사제목들을 정리했었는데 계속해서 올해 2012년에는 12개를 생각해 보려고 합니다. 12개를 막상 생각하려면 쉽지 않을수도 있지만 올해는 감사한일들이 너무 많아 그리 어렵지 않을것 같습니다.


자, 시작합니다!

  1. 저의 처가 이곳 홍콩에서 의류계통회사에 디자이너로 일한지가 1년이 넘었는데 그동안 재미있게 일하면서 인정을 받아 이제 회사의 main designer 가 되게 해주신거 감사합니다.
  2. 이번에 어머님과 처음으로 같이 해외여행 (일본)을 다녀 올수 있어서 감사합니다. 
  3. 저희 연구실 첫 박사과정 학생인 Ning Chen의 첫논문이 좋은 학회인 ASE에 발표되고 또 여름에 저도 하지 못했던 Google Mountain View 에서 인턴을 할수 있게 된거 감사합니다.
  4. 서현민 학생과 제가 작성한 논문이 ASE 2012  에서 ACM SIGSOFT Distinguished Paper Award (SE논문중 최고의 상)를 받게된거 너무 감사합니다.
  5. 1년차 박사과정인 Yida Tao가 그녀의 첫번째 논문을 SE최고 학회인 FSE 2012에서 멋지게 발표함을 감사합니다. FSE에 참여한 친구들에게 발표잘했다는 칭찬을 많이 들었습니다.
  6. ICSE 2013 제출한 두개의 논문이 토론 없이 Clear Accept 된것 놀랍고도 감사합니다.
  7. SE분야 탑 저널중 하나인 EMSE 편집 위원으로 초대되었습니다. 테뉴어도 받지 않은 조교수에게는 아주 이례적인 감사한 일입니다. 추가로 ICSE 2013, ESEC/FSE 2013, ASE 2013 의 프로그램위원회 (PC)로 초개 된것 감사한 일입니다. 
  8. 소프트웨어 마이닝 분야 최고 학회인 MSR 2013 (샌프란 시스코), MSR 2014 (인도)의 프로그램 공동위원장 (PC co-chair) 으로 위촉됨에 감사합니다. 
  9. 지난해 스쿠버 다이빙 기본 자격증을 따고 올해는 어드벤스 자격증을 딸수 있게 되어 감사합니다.
  10. 올 여름에 한달간 이태리에 머물면서 연구도 하고 유럽(이태리/독일/스위스) 여행하게 된것 감사합니다.
  11. 올해 새로운 홍콩 정부 장학생인 유지훈 학생이 저희 연구실에 합류한것 감사합니다.
  12. 좋은 방문 학생들이 (Caitlin from UCSC, USA and Giuseppe from Cagliari University, Italy) 다녀갔습니다. 참 감사합니다. 


정리하고 보니 감사할것이 너무나 많은 한해였습니다. 계속해서 2013년은 더 크고 더 많은 감사제목들이 있을 것이라 기대해봅니다. 


여러분들은 올 한해 어떤 감사가 있으세요? 

저작자 표시 비영리 변경 금지
신고
트랙백이 없고 Comment 3
  1. NoSyu 2012.11.23 00:39 신고 address edit & del reply

    감사함을 정리한다는 것이 신선하네요.
    지난 기간을 되돌아보며 다른 사람을 생각할 수 있는 좋은 주제인 것 같습니다.
    지금은 논문 Due 핑계로 잠시 미뤄둬야겠지만, 이후 꼭 해봐야겠습니다.
    좋은 글 고맙습니다.

  2. HannaKim 2012.11.23 04:56 신고 address edit & del reply

    @NoSyu 감사한일을 생각하다보면 너무 행복해지는것 같아요. 좋은 감사가 있으면 저에게도 알려 주세요. 그럼 좋은 연말보내세요.

  3. sangheestyle 2012.12.29 00:27 신고 address edit & del reply

    어쩌다보니 작년에 이어 올해도 교수님께서 작성하시는 '감사제목'을 보게됩니다. 리스트의 모든 항목이 아주 값져보입니다.

    더불어 김창준님께서 작성하신 기년회 포스팅이 생각납니다.
    http://agile.egloos.com/4016733

    새해 복 많이 받으세요.

2008.11.25 21:00

오래된 주제...애플리케이션의 복잡도를 새로운 관점으로...

과거에 소프트웨어 위기(Software Crisis)가 있었다. 이는 미국 인력의 대부분이 소프트웨어 개발에 매달려도 해결하기 힘들만큼 전체 시스템에서의 소프트웨어 비중이 커졌을 뿐 아니라, 복잡해졌기 때문에 발생한 위기였다. 소프트웨어에 대한 의존도가 그만큼 커지면서, 소프트웨어 오류로 인한 피해도 심각해졌다. Therac-25의 의료사고나 Ariane의 폭발사건 등은 너무나도 유명한 사례들이다. 대부분의 프로젝트들은 실패했고, 많은 자금이 낭비되었다.

컴퓨터공학자들은 이렇게 비용면에서 비효율적인 이유는 적절히 개발 관리가 되지 않기 때문이라고 생각했는데, 바로 그 관리를 하기 위해서는 개발 과정에서 등장하는 여러 상황이나 요소들의 상태를 판단하고, 적절히 제어할 수 있어야 했다. 결국, 대상에 대한 정확한 측정이 필요했다. 대상을 여러 기준에 따라 수치에 따라 측정한 값으로 판단하고, 계획하기 위해서였다. 그리하여, 소프트웨어 척도(Metrics)는 소프트웨어 공학이 생기는 초기부터 주목을 받아왔다.

하지만, 척도라는 것은 너무나도 다양한 요소들의 영향을 받는다. 뿐만 아니라, 측정의 대상도 빠르게 바뀌기 때문에 매번 척도에 적용되는 변인들을 새로 고려해 주어야 했다. 분명 중요한 문제임에도 불구하고, 정확한 측정이 어렵기 때문이다. 그래서, 아직까지도 가시적인 성과를 내지 못하고 있는 분야이다.

잠깐, 이야기를 돌려서... 우리가 소프트웨어를 설계할 때는 한 가지 관점으로 보지 않는다. 구조적, 행위적, 논리적 관점 등 다양한 관점이 존재한다. UML 모델 다이어그램을 보더라도 클래스 다이어그램, 액티비티 다이어그램, 인터랙션 다이어그램 등 10가지가 넘는다. 이러한 다양한 관점들의 설계가 모여서 애매모호함을 제거하고, 소위 말하는 오차를 줄여주는 역할을 한다.

복잡도의 경우도 마찬가지이다. 대부분의 복잡도는 크기와 상당한 관계를 가지고 있다. 그러므로, 소프트웨어의 크기와 복잡도를 거의 유사하게 생각하기도 한다. 하지만, 실제로는 크기와 상관없이 복잡도를 가지기도 한다. 아무리 크기가 작더라도 구조적으로 복잡할 수 있고, 간결한 구조를 가진다면 크기가 크더라도 오히려 간단하게 느낄 것이다. 우선 생각해볼 수 있는 것이 바로 이러한 구조적 복잡도이다. 구조적 복잡도는 크기를 어느 정도 반영하기는 하지만, 큰 관련을 가지지는 않는다. 바로, "엔트로피"가 구조적 복잡도를 측정할 수 있는 좋은 방법 중 하나이다.

엔트로피는 열역학에서 그 유래를 찾을 수 있지만, 정보공학에서 이야기하는 엔트로피는 섀넌(C. Shannon)의 1948년 논문인 "A Mathematical Theory of Communication" 에서 시작되었다고 볼 수 있다. 엔트로피는 가장 효율적인 정보 압축의 한계를 계산해주기도 하는데, 평균 정보량 또는 모호함의 정도를 의미한다. 각 객체의 정보량을 그 확률로 곱해서 합한 값이 바로 정보 엔트로피이며, 각 객체의 정보량은 그 객체의 확률에 밑이2인 로그를 취한값에 마이너스를 붙혀서 만든다. 셰넌은 자신의 논문에서 아래와 같은 일반적인 커뮤니케이션 모델을 가정했으며, 정보 소스로부터 목적지로 정보가 전송된다고 가정했다. 실제로 엔트로피는 모호함의 증가치를 나타내기 때문에, 최종적으로 우리의 모호함이 0이 되는 것으로 계산하면 원래 대상에 대한 전체 모호함의 크기가 나오게 된다.
정보 엔트로피에 대해 더 자세히 알고 싶으면, http://en.wikipedia.org/wiki/Information_entropy 를 참고하여 관련 링크들을 읽어보기 바란다. (하지만, 엔트로피를 이해하기 위해 수식까지 모두 이해할 필요는 없다고 생각된다.)


그 외에도 엔트로피는 객체의 복잡도를 측정하기 위해 사용되기도 했다. 객체 지향 시스템 등을 대상으로 몇몇 연구들이 존재한다. 이를 웹 애플리케이션에 대해서도 생각해볼 수 있는데, 각 페이지에 대한 참조 확률을 바탕으로 엔트로피를 이용하는 방법이다. 즉, 웹에서는 웹 소스로부터 개발자에게로 구조적 정보가 전달된다고 본다. 다음은 이러한 방법으로 계산된 복잡도 결과를 일부 보여준다.


총 3개의 실제 웹 애플리케이션의 엔트로피값은 중간에 파란색 선으로 표시된 것이고, 양쪽의 히스토그램에서 오른쪽의 것은 랜덤 생성한 웹 애플리케이션, 왼쪽은 재구조화(CCA모델로 재구조화)시킨 결과 얻어진 엔트로피의 빈도로 히스토그램을 나타낸 것이다. 실제로 3번째 웹 애플리케이션은 2번째 보다 페이지 수도 20개 정도 많고, 관계의 개수는 1000개(4배) 가량 많기 때문에, 크기로 비교한다면 2번째 보다 3번째 애플리케이션이 크다. 하지만, 엔트로피는 더 작을 수 있음을 보여준다. 그만큼 단순한 구조를 가지게 되면 구조에 대한 모호함이 줄어들기 때문에 엔트로피값이 낮아진 것이다.

물론, 이러한 결과 때문에 실제로는 크기의 영향을 많이 받는 예측되는 오류의 개수나 이해 노력도 등 다른 품질 요소들과의 관련성이 떨어질 수도 있다. 이러한 이유 때문에, 엔트로피는 유사한 크기의 애플리케이션 구조 복잡도를 비교하거나 동일한 애플리케이션이 진화하는 과정을 모니터링할 때 더 유용하다.

지금까지 엔트로피에 대해서만 이야기했지만, 복잡도에 영향을 주는 또다른 요소도 있다. 바로 "유사성"이다. 극단적인 예를 들면, 100개의 동일한 페이지와 5개의 서로 다른 페이지를 비교한다면, 분명 5개의 서로 다른 페이지를 이해하는데 드는 비용이 더 클 것이다. 즉, 크기는 작더라도 복잡도는 더 높아지게 된다. 이러한 이유로 유사한 개체들을 많이 포함한 시스템은 덩치가 크더라도 단순할 수 있다는 것이다.

그 외에도 복잡도에 영향을 줄 수 있는 요소들은 많이 있다. 다양한 복잡도 요소들에 대해 분석하고, 이들을 묶어서 일종의 패턴으로 본다면, 훨씬 정밀한 비용 예측이나 복잡도 계산을 할 수 있으리라 생각한다. 복잡도는 분명 중요한 연구 주제 중 하나이지만 어렵고 재미가 없는 주제이기도 하다. 너무 재밌는 주제만 하다가 가끔 실증이 날 때, 이러한 조금은 답답하고 그리 좋은 결과가 나오지도 않는 오래된 주제들을 다뤄보는 것도 좋을 것이라 생각된다.

"코드가 복잡하다고 느끼는 이유는 무엇일까?" 또는
"아키텍처가 복잡하다고 느끼는 이유는 무엇일까?"

이러한 질문들에 대한 새로운 관점이나 해석이 연구의 출발점이 될 것이다.
신고
트랙백이 없고 Comment 4
  1. 넘버3 2008.12.02 13:24 신고 address edit & del reply

    잘 알지 못하지만 엔트로피에 대해서 관심을 가지고 있었는데, 좋은 내용의 글로 생각합니다.
    소프트웨어나 개발쪽에서 엔트로피에 대해서 공부를 하려면 어떤 것을 참고하면 될까요?

    이 댓글 보시면 꼭 좀 답변 남겨주세요.

    감사합니다.

    • swinside 2008.12.09 22:00 신고 address edit & del

      몇몇 논문들이 있습니다. 주로 OO관련한 것들이 있구요. 엔트로피 이론과 관련한 내용은 위키피디아를 통해 보시면 관련 좋은 링크들이 많습니다.
      이를 SE와 관련지은 논문들은... 주로 메트릭 관련이 많지만... 다음과 같은 것들이 있습니다.

      ** 유명한 셰넌의 A Mathematical Theory of Communication 이 아무래도 제일 시작점이구요.

      ** W. Harrison, "An Entropy-Based Measure of Software Complexity," IEEE TSE, vol.18, no.11, 1992. ( 좀 옛날 논문이지만, SE관련으로 엔트로피 기반 메트릭 기본이 되는 논문...)

      그리고 저자가 Kapsu kim인 "Complexity Measures for Object-Oriented Program Based on the Entropy"는 연구실 선배님이 쓰셨던 논문입니다.

      첨언하면... 엔트로피는 크기 기반은 아니지만, 분명 "복잡한 정도라거나 무질서도와 관련이 있어서" software fault의 밀도와 관련성이 있는 것으로 알고 있어요. 전체 개수와는 상관없구요.

      여튼 뭐 엔트로피 이론이라는 것이 워낙 좀 우주 전체에서 나타나는 현상인지라... 인위적인 사람들의 개발 대상물에서도 나타나는지는 아직까진 모르겠지만... 잘 찾아보면, 그럴싸한게 있을지도 모르겠어요^^;

      그리고, 이건 한글 사이트이지만, 정보이론에 대해 꽤 쉽게 잘 정리되어 있는 내용이라서 링크 알려드립니다.
      http://www.aistudy.com/control/information_theory.htm

  2. 화사 2008.12.10 12:43 신고 address edit & del reply

    복잡도에 대한 관점이 어떤 기준에 따라 크게 달라질 수 있다는 생각을 해봅니다.

    코드가 OOP로 디자인 되어 있고, 이에 대한 복잡도를 측정한다고 할 때,
    디자인 패턴을 공부한 사람이라면 복잡한 계층을 가진 OOP 프로그램도 단순하게 느껴질 것이고, OOP를 알더라도 디자인 패턴을 공부하지 않은 사람에게는 매우 복잡하게 느껴질 것입니다..

    즉, OOP를 직관적인 관점에서 복잡도를 이해할 것인가, 디자인 패턴 관점에서 이해할 것인가에 따라 복잡도는 상이하다고 보아지는데요.

    웹 프로그램이라면 MVC 구조라든가, 객체DB라든가 하는 것을 사용하면 관점에 따라 더 복잡해 보일 수도, 덜 복잡해 보일 수도 있을 것 같습니다.

    또 다른 예로, MFC가 프로그램 구조를 복잡하게 하는 것인가? 단순화 하는 것인가?는 관점에 따라 틀린 것 같습니다.

  3. 이장석 2011.02.25 10:44 신고 address edit & del reply

    글 잘 보았습니다.
    좋은 하루 되십시오.

2008.11.03 22:27

버그 넘기기 (Tossing Bugs)

보통 잘 되어있는 소프트웨어 개발 프로세스를 보면 사용자들로 부터 버그 리포트 등을 받게 되면 이를 관리자가 검토한다음 수정해야할 버그라고 생각되면 담당 개발자에게 할당 (Assign)하게 된다. 그런 다음 이 개발자는 자신에게 적당한 버그면 수정을 하고 그렇지 않다면 이 버그는 다른 새발자에게 넘겨준다 (Tossing)

보통 버그는 몇명에게 Tossing된 다음 Fix 될까?
이 Tossing에 어떤 패턴이 있을까? 늘 Tossing하는 사람들의 그룹이 있을까?

그래서 Mozilla의 버그 리포드 35만개를 가지고 실험을 해보고 이런 그래프를 얻었다. 어떤 버그는 무려 24명의 개발자가 할당되기도 했다.



우선은 데이타 량이 너무 많이 그림이 복잡한데 하나의 노드는 개발자나 메너저를 의미하고 하나의 화살표는 100번의 버그 Tossing을 의미 한다.

재미있는 형태의 그래프가 나오긴 했지만 무엇에 사용할 수 있을까?

우선 1. 개발자들의 그룹을 자동으로 알수 있게 된다.
2. 혹 개발자들간의 그룹이 확연하게 나타나면 버그를 할당할때 해당 그룹 모두에게 할당하여 서로간의 할당 시간을 줄일 수 있지 않을까?
3. 메니저가 버그를 할당할때 이 그래프가 힌트를 줄 수 있을까?

여러분들이 한 소프트웨어 프로젝트의 메니저이고 자신의 팀들의 버그 Tossing관계를 보여 준다면 어디다 사용할수 있을까요?


저작자 표시
신고
트랙백이 없고 Comment 3
  1. 화사 2008.12.10 12:33 신고 address edit & del reply

    저라면 유사 버그 발생시에 이번 버그와 가장 유사한 기존 발생 버그를 찾아내서, 그 버그를 해결한 사람에게 의견을 구하겠어요. 3번 처럼 매니저가 버그 할당시 그래프가 도움이 되겠네요.

  2. Gurutect 2011.08.09 22:48 신고 address edit & del reply

    35만개의 버그리포트를 가지고 나온 그래프라서 그런지...매니저라면 안 볼것 같습니다..^^;;
    대신 토싱하는 사람들에 대한 정보가 있으니... 코드리뷰를 할때 자동으로 reviewer로 추천하면 좋을것 같네요. 그리고 기존에 유사한 버그를 해결한 사람에게 의견을 구할수도 있지만, 어떻게 해결을 했는지 연결을 시켜서, 리뷰시나 defect을 fix할때 참고할 수 있도록 해놓으면 좋을듯합니다.

  3. sangheestyle 2012.05.13 17:02 신고 address edit & del reply

    다음 팀 빌딩때 tossing이 자주 발생하는 그룹을 한 팀으로 엮는 시도를 해볼수 있을것 같습니다. Tossing이 자주 발생하는 문제의 경우 한 사람의 역량보다 여러명의 역량과 뷰가 필요한 경우가 있는데, 팀이 다른 경우 이해관계등에 의해서 협업이 깨져 비용이 더 드는 경우를 많이 봐왔습니다. 따라서 다음 팀 빌딩(예. 조직 변경)시에 이를 이용해서 tossing이 덜 일어나도록, 일어나더라도 그 횟수가 줄도록 하는게 좋을거라 생각합니다. 더불어 Gurutect 님의 말씀처럼 reviewer 로 추천하는것도 좋은것 같기는 한데, 그렇게 하면 너무 많은 메일을 받을 수 있다는 단점도 있기는 합니다. (실제 그런 사례를 보니 관련자들이 고통스러워했습니다.) :0



티스토리 툴바