2012 icse program comprehension

2,407 views
2,300 views

Published on

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,407
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

2012 icse program comprehension

  1. 1.    Roehm,  Tiarks,  Koschke,  and  Maalej  
  2. 2. Outline  of  the  Talk   1   MoAvaAon   2   Study  Design   3   Main  Findings   4   Next  Steps   2  
  3. 3. Why  Should  we  Comprehend  this?   3  
  4. 4. ObservaAons  on  Program  Comprehension   Limited  knowledge  of   A  mature  research  field   pracAce   •  Over  30  years  of  research   •  Previous  studies  are:   •  Important  ac6vity  in   •  Rela6vely  old  (outdated?)     so8ware  engineering  and   •  Handle  specific  ques6ons   maintenance   •  Have  methodological   •  Theories  on  program   limita6ons  (e.g.     comprehension  and   conducted  with  students     research-­‐based  tools  to   or  in  lab  seKngs)   support  developers    Does  the  state  of  the  pracAce  match  with  the  state  of  the  art?   4  
  5. 5. Goal:    QualitaAvely  explore  how  program  comprehension  is  done  in  industry     5  
  6. 6. Outline  of  the  Talk   1   MoAvaAon   2   Study  Design   3   Main  Findings   4   Next  Steps   6  
  7. 7. Research  QuesAons   Which  strategies  (including  steps   and  ac6vi6es)  do  developers  use  in   order  to  comprehend  so8ware?   Which  sources  of  informaAon   Which  tools  do  developers   do  developers  use  during   use  when  understanding   program  comprehension?   programs  and  in  which  way?   7  
  8. 8. Research  Method   Field  observaAons   Contextualized  semi-­‐ with  think  aloud   structured  interviews   1   2   Which  and  When   How  and  Why   Ques+ons   Ques+ons   8  
  9. 9. Data  Analysis    ObservaAon  logs   Itera6ve   Frequencies   and  interview   manual   minutes   clustering   ABC   BBD   BDA   18  findings   23  hypotheses   AAAAA   BBBBB   CCCCC   9  
  10. 10. Reliability  Measures  Triangula6on  of  data  sources  Independent  peer  observa6ons  Dry  runs  Peer  debriefing  Double-­‐checking  by  par6cipants   10  
  11. 11. Research  Subjects   SelecAon  Criteria     ParAcipants   •  Inclusion  criteria     •  28  subjects   •  Developers  working  for   •  Between  1,5  and  19  years     so8ware  companies   of  development  experience   •  Spend  most  of  their  work   •  7  European  companies   6me  on  source  code   •  Different  domains  and     •  Exclusion  criteria   technologies   •  Students  and  researchers   •  Random  tasks,  each  includes   program  comprehension   11  
  12. 12. Outline  of  the  Talk   1   MoAvaAon   2   Study  Design   3   Main  Findings   4   Next  Steps   12  
  13. 13. Comprehension  Strategies   Finding   Part.   Comp.   Employ  a  recurring,  structured  comprehension  1   26   7   strategy  depending  on  context  2   Follow  a  problem-­‐soluAon-­‐test  work  pa`ern   18   5   Debug  applica6on  to  elicit  runAme  3   16   5   informaAon   Interact  with  UI  to  test  expected  program  4   17   5   behavior   13  
  14. 14. Developers  Interact  with  UI  to  Test  Expected  Program  Behavior   „We  passed  two  6mes  in  this  loop   because  of  two  event  categories   displayed  in  the  UI”     Enter  values  in  UI  form  and  verify   they  are  stored  in  database   14  
  15. 15. Comprehension  Strategies  (ctd.)   Finding   Part.   Comp.   Take  notes  to  reflect  mental  model  and  record  5   9   4   knowledge   Iden6fy  starAng  point  for  comprehension  and  6   10   5   filter  irrelevant  code  based  on  experience  7   Establish  and  test  hypotheses   9   5   Clone  to  avoid  comprehension  and  minimize  8   14   6   effort   15  
  16. 16. Developers  Clone  to  Avoid  Comprehension  and  Minimize  Effort   Clone  to  avoid  comprehension   Worried  about  breaking  the  system   1.  Copy  several  methods     2.  Comment  all  of  them   3.  Repeatedly  uncomment   methods  in  compiler  warnings   16  
  17. 17. InformaAon  Sources   Finding   Part.   Comp.   Source  code  is  more  trusted  than  1   21   6   documenta6on   CommunicaAon  is  preferred  over  2   17   5   documenta6on  3   Standards  facilitate  comprehension   12   6   Cryp6c,  meaningless  names  hamper  4   10   6   comprehension   RaAonale  and  intended  usage  is  5   10   5   important  but  rare  informa6on  6   Real  usage  scenarios  are  useful  but  rare   5   4   17  
  18. 18. Tool  Usage   Finding   Part.   Comp.   Dedicated  program  comprehension   1   28   7   tools  are  not  used   Tools  with  redundant  features  are  used   2   5   4   in  parallel  to  IDE     Compiler  is  used  to  elicit  structural   3   5   4   informaAon   Tool  features  for  comprehension  are   4   3   3   unknown   18  
  19. 19. Program  Comprehension  Tools  not  Used   None  of  developers  used  dedicated   program  comprehension  tools  such   as  visualiza6on,  concept  loca6on   or  metric  calcula6on  tools   Comprehension  features  (e.g.   indexing  or  call  tree  viz.)  were   available  but  unknown     19  
  20. 20. Outline  of  the  Talk   1   MoAvaAon   2   Study  Design   3   Main  Findings   4   Next  Steps   20  
  21. 21. ImplicaAons  for  PracAAoners    Define  coding  style  &   Evaluate  research   1   2  naming  conven6ons   proposals   Deal  with  „feature   3   4   Inves6gate  reasons   overload“     behind  gap   21  
  22. 22. ImplicaAons  for  Researchers   Think  of  the  developer  as  a  user   Revisit  agendas  considering  our  hypotheses  Inves6gate  reasons  behind  gap  between  research  and  prac6ce   22  
  23. 23. Summary  of  the  Talk   1   We  observed  and  interviewed  28  professional  developers   to  study  comprehension  strategies,  informa6on,  and  tools.   2   Developers’  comprehension  strategies  depend  on  context.   They  interacted  with  UI  to  test  expected  program  behavior.   3   Developers  cloned  pieces  of  code  to  avoid  comprehension.   They  do  not  use  dedicated  program  comprehension  tools.   4   Prac66oners,  tool  vendors,  and  researchers  need  to   further  inves6gate  the  gap  between  research  and  prac6ce   23  
  24. 24. How  Do  Professional  Developers   Comprehend  So_ware?    Tobias   Rebecca   Rainer   Walid  Roehm   Tiarks   Koschke   Maalej   24  

×