1. Program understanding1 Programų supratimas Prof. Robertas Damaševičius robertas.damasevicius@ktu.lt Prof. Vytautas Štuikys Kauno technologijos universitetas Programų inžinerijos katedra

2. Program understanding2 Turinys Sąvokų apibrėžimas Programų suvokimo rolė PĮ priežiūroje Programų suvokimo iššūkiai Programų suvokimo (kognityviniai) modeliai Programų inspekcija

3. Programų suvokimas3 Tyrimų sritis nagrinėjanti, kaip programų kūrėjai supranta programas Programų suvokimas reikalingas: –Derinant ir ieškant klaidų (debugging) –Peržiūrint kodą –Kuriant testavimo atvejus –Tobulinant dokumentaciją –Rekonstruojant architektūrą –Peržiūrint kodą

4. Programų suvokimas4 Programų suvokimo procesas Ankstesnių žinių naudojimas siekiant įgyti naujų žinių apie programą Esamos žinios: –Programavimo kalbos –Aplinka –Programavimo principai –Architektūros modeliai –Galimi algoritmai ir sprendimai –Srities informacija Naujos žinios: –Kodo funkcionalumas –Architektūra –Algoritmų realizacijos detalės –Duomenų srautai –Valdymo sekos

5. Program understanding5 Programų supratimo tikslai Pagr. tikslas yra sėkmingai įgyvendinti pageidaujamus PĮ pakeitimus. Siekiant tikslo reikia gauti informaciją apie: –Probleminę sritį –Programos vykdymo rezultatus –Produkto aplinką

6. Program understanding6 Programų suvokimas (1) Prieš įgyvendinant suvokimus, svarbu suprasti tiek PĮ kaip visumą, tiek atskiras programų sistemos dalis, kurios bus keičiamos Priežiūros metu tai reiškia: –Turėti bendrąsias žinias apie tai, ką programų sistema daro ir kaip ji susijusi su savo aplinka; –Nustatyti, kur pakeitimai turi būti realizuojami; –Turėti gilias žinias apie tai, kaip veiks pataisytos programos dalys

7. Program understanding7 Programų suvokimas (2) Programų suvokimo kaštai sudaro žymią programų priežiūros kaštų ir darbo pastangų dalį Hewlett Packard vertina, kad programų suvokimo kaštai yra $200 mln. per metus Iki pusės keitimo kaštų sudaro suvokimo kaštai Kaštai didėja, jei –Programuotojas prižiūri ne paties sukurtą programą –Dokumentacija netiksli, pasenusi arba jos visai nėra –Programos struktūra degradavo dėl „greitų pataisymų“

8. Program understanding8 Programos suvokimo modelis

9. Program understanding9 Suvokimo procesas Suvokimas yra transformacija tarp programavimo srities ir probleminės srities, kurios metu rekonstruojamos –Šių sričių (įskaitant tarpines sritis) žinios ir –Sąryšiai tarp jų

10. Program understanding10 Programos suvokimui reikalingos žinios (1) Probleminės srities žinios –Padeda pasirinkti reikiamus resursus (algoritmus, įrankius, metodus) Vykdymo supratimas –Sistemos elgsenos supratimas abstrakčiame lygmenyje –Tikėtinų pakeitimo pasekmių numatymas

11. Program understanding11 Programos suvokimui reikalingos žinios (2) Priežastiniai sąryšiai –Tikslas yra nustatyti planuojamo pakeitimo poveikius kitoms sistemos dalims („raibuliavimo efektas“) –Nustatyti sistemos dalių tarpusavio priklausomybių pobūdį, nes priklausomybės atliekant keitimą gali sukelti problemų Produkto-aplinkos sąryšiai –Tikslas yra nustatyti visus išorinius faktorius (veiklos taisykles, vyriausybės nustatytas taisykles ir kt.), kurios gali turėti įtaką sistemai Sprendimus įtakojantys požymiai –Požymiai (sudėtingumas, prižiūrimumas), padedantys priimti resursų ir finansų paskirstymo sprendimus

12. Program understanding12 Programos suvokimo strategijos Iš viršaus (top-down) –Probleminės srities analizė ir atitikmenų kode identifikavimas Iš apačios (bottom-up) –Tam tikrų kodo pasikartojančių šablonų atpažinimas ir semantinės prasmės suteikimas Oportunistinė –Abu metodai naudojami kai to prireikia

13. Program understanding13 Suvokimas iš viršaus į apačią

14. Program understanding14 Suvokimas iš apačios į viršų

15. Program understanding15 Suvokimas iš apačios į viršų Programuotojas atpažįsta, išskiria ir grupuoja tam tikrus kodo šablonus programoje Šablonai yra apjungiami į semantinę prasmę turinčias struktūras Procesas kartojamas tol, kol apima visą programos kodą ir programa yra suprantama

16. Program understanding16 Dviejų suvokimo modelių įvertinimas Pagrindiniai abejų suvokimo strategijų trūkumai: –Neatsižvelgiama į išorės faktorių (pvz., priežiūros įrankių) indėlį –Praktikoje suvokimo procesas nėra toks tvarkingas ir gerai apibrėžtas, kaip modeliuose Praktikoje programuotoji abu modelius taiko oportunistiškai

17. Program understanding17 Oportunistinis modelis Suvokimas priklauso nuo trijų pagrindinių vienas kitą papildančių dedamųjų: –Žinių bazė: priežiūros specialisto ekspertinės žinios ir patirtis –Mentalinis modelis: programuotojo dabartinės žinios apie analizuojamą programą –Asimiliacijos procesas: žinių išgavimo iš PĮ artefaktų procesas

18. Program understanding18 Programos suvokimo faktorių taksonomija

19. Program understanding19 PĮ priežiūra ir suvokimas Programų suvokimas yra svarbi ir brangiai kainuojanti PĮ priežiūros dalis “There is no high-quality substitute for experience when it comes to understanding and maintaining a system, as existing methods and tools are not effective enough and documentation tends to be unreliable”* * Survey: C. Tjortjis and P.J. Layzell, "Expert Maintainers’ Strategies and Needs when Understanding Software: A Qualitative Empirical Study", Proc. IEEE 8th Asia-Pacific Software Engineering Conf. (APSEC 2001), IEEE Comp. Soc. Press, 2001, pp. 281-287.

20. Program understanding20 Priežiūros praktikos ir reikalavimai susiję su suvokimu Siekient palengvinti suvokimą, sistemos atvaizdai (peržiūros, abstrakcijos, diagramos, modulių sąryšiai) turi būti išgauti pusiau automatiškai Posistemių aukšto lygmens abstrakcijos su susijusiomis funkcijomis ir sąryšiais turi būti vizualizuojamos, ir dokumentuojamos ateičiai Grupės narių bendravimo informacija susijusi su nagrinėjama sistema turi būti fiksuojama ir saugoma Žinios apie atliktus pakeitimus ir iš komentarų išgauta informacija yra labai svarbi Turi būti įvertinta dalinio programų suvokimo rizika

21. Program understanding21 Priežiūros užduotys ir veiklos, kurios reikalauja programų suvokimo Source: Program Understanding: A Survey, A. von Mayrhauser and A. M. Vans Technical Report CS-94-120, 1994.

22. Program understanding22 Programų suvokimo komponentų taksonomija Source: Software Comprehension – Integrating Program Analysis and Software Visualization, Welf L¨owe Morgan Ericsson Jonas Lundberg Thomas Panas

23. Program understanding23 Suvokimo iššūkiai (1) Netinkamas intelekto naudojimas (painus kodas) –Sunku suvokti kitiems programuotojams Skirtingi programavimo stiliai –Didelė programų sistema, kurią kūrė skirtingus programavimo įgudžius ir patirtį turinčių programuotojų komanda –Tokias programas sunku suvokti

24. Program understanding24 Suvokimo iššūkiai (2) Netinkami vardai –Naudojami beprasmiai vardai arba nenuosekli vardų sudarymo strategija –Vardas turi aiškiai apibrėžti įvardijamą objektą Žodyne nenaudojami srities terminai –Tinkamų srities terminų naudojimas yra laikomas gerąja praktika –Tinkami vardai ir komentarai, nesant pakankamos dokumentacijos, labai palengvina suvokimą Prieštaringas terminų žodynas –Programos identifikatorių suvokimas priklauso nuo jų gebėjimo tiksai aprašyti srities sąvoką –Netinkamo vardo naudojimas apsunkina suvokimą

25. Program understanding25 Suvokimo iššūkiai (3) Programų atvaizdavimas Panašių sakinių ir modulių grupavimas palengvina suvokimą Geras kodo išdėstymas daro kodą suprantamesniu Nepakankamas komentavimas Komentarų trūkumas yra pagrindinė priežiūros kaštų augimo priežastis Gilios paveldėjimo hierarchijos Mažai žmonių gali tinkamai suprasti hierarchijas, kurių gylis didesnis nei 3

26. Program understanding26 Suvokimo iššūkiai (4) Konceptų aptikimas –Viso kodo skaitymas didelės sistemos atveju yra labai neefektyvu –Pageidaujamam kodui surasti naudojama paieška –Skirtumai tarp pakeitimo užklausos aprašo natūralia kalba ir programos žodyno gali apsunkiti keitimo užklausos įgyvendinimą Kodo atsikartojimas (“bad smells in code”) –Išbandytą kodą naudoti lengviau, tačiau tai apsunkina priežiūrą “Negyvas” (niekada nevykdomas) kodas –Viena iš pagrindinių suvokimo problemų.

27. Programų suvokimas27 Suvokimo metodai Abstrakcijomis grįstas (by step-wise abstraction) –Nustatomos kritinės funkcijos ir atsekant jų naudojimą programoje nustatomos visos programos funkcijos Sąrašu grįstas(Checklist-based) –Skaitytojams duodamas sąrašas dalykų, į kuriuos reikia atkreipti dėmesį –Skirtingiems skaitytojams duodami skirtingi sąrašai, kad kiekvienas gilintųsi į atskirą problemos aspektą Defektais grįstas (Defect-based) –Defektai suklasifikuojami (pvz., netinkamas, trūkstamas funcionalumas –Kiekvienai defektų klasei sukuriamas scenarijus, padedantis surasti tos klasės defektus Perspektyvinis (Perspective-based) –Panašus į defektais grįstą, tačiau kodo skaitytojai turi skirtingas roles (testuotojas, projektuotojas, vartotojas)

28. Program understanding28 Suprantamumą palengvinantys faktoriai (1) Ekspertinės žinios –Gilios probleminės srities, problemų sprendimo ir programavimo kalbų žinios palengvina programos suvokimą Sintaksės paryškinimas –Gali būti naudojamas kartu su kitais metodais, palengvinančiais konceptų aptikimą programų išeities tekste Kryžminis indeksavimas –Tarp kodo dalių parašytų skirtingomis programavimo kalbomis gali palengvinti kodo suprantamumą

29. Program understanding29 Suprantamumą palengvinantys faktoriai (2) Iškvietimų grafai –Atvaizduoja sąryšius tarp skirtingų programos modulių (funkcijų, procedūrų) –Statiniai grafai rodo galimus iškvietimus –Dinaminiai grafai rodo iškvietimus programos vykdymo metu Komentarai ir anotacijos –Virtualūs komentarai, kurių nebuvo originaliame išvesties tekste –Anotacijos padeda lengvai suprasti programos kodą

30. Program understanding30 Suprantamumą palengvinantys faktoriai (3) Programų sluoksninė analizė („slicing“) –Efektyvūs metodas leidžiantis sumažinti reikalingo perskaityti kodo apimtį –Naudojamas priežastiniams-pasekmių sąryšiams aptikti –Palengvina klaidos aptikimą Poveikio analizė –Skirta aptikti kodo dalis, kurias gali paveikti atliekami pakeitimai –Padeda aptikti priklausomybes tarp skirtingų kodo dalių Programos dekompozicija –Didelės programos suskaidymas į mažesnius lengviau suprantamus modulius

31. Programų suvokimas31 Suvokimo efektyvumas Įtakoja daugelis faktorių: –Programų priežiūros charakteristikos –Programos charakteristikos –Užduoties charakteristikos

32. Programų suvokimas32 Reikalavimai programų prižiūrėtojui Programų bazės žinojimas Taikomosios srities žinios Programavimo kalbos žinios Programavimo ekspertinės žinios Įrankių žinojimas Individualūs sugebėjimai

33. Programų suvokimas33 Programos charakteristikos Taikymo srities charakteristikos Programavimo srities charakteristikos Programos dydis ir sudėtingumas Dokumentacijos tikslumas ir prieinamumas

34. Programų suvokimas34 Užduočių charakteristikos Užduoties tipas –Tobulinimas, taisymas, adaptavimas, išplėtimas... Užduoties dydis ir sudėtingumas Laiko apribojimai Aplinkos faktoriai

35. Programų suvokimas35 Modeliai Mentaliniai modeliai –Vidinis programos darbo vaizdas programuotojo galvoje Pažinimo modeliai –Teoriniai procesų modeliai, padedantys programuotojams susidaryti programos darbo vaizdą (mentalinį modelį) Programa Mentalinis Modelis Pažinimo Modelis

36. Program understanding36 Mentaliniai modeliai Programų suvokimas yra procesas, kurio metu esamos žinios yra naudojamos naujoms žinioms įgyti tikslu suprasti programą Tiek esamos, tiek naujai įgytos žinios naudojamos programos darbo mentaliniam modeliui sudaryti

37. Programų suvokimas37 Mentaliniai modeliai Statiniai elementai –Teksto struktūros žinios –Mikrostruktūra –„Kodo gabalai“(makrostruktūra) Dinaminiai elementai –Skaidymas į dalis (chunking ) –Kryžminis indeksavimas (cross-referencing) Pagalbiniai elementai –„Švyturiai“

38. Program understanding38 Statiniai mentalinio modelio elementai Struktūros žinios apie programos tekstą ir jo struktūrą –Formuojamos iš patirties ir saugomos ilgalaikėje atmintyje „Gabalai“ (chunks) – įvairaus abstrakcijos lygmens teksto struktūros –Atitinka programos struktūrinės diagramos elementus. Planai yra žinių elementai, kurie leidžia patikrinti lūkesčius, hipotezes ir palaikyti dėmesį –Įeina žinios apie sąryšius tarp programos dalių ir priežastinius ryšius. Programavimo planai gali būti aukšto lygmens, žemo lygmens arba vidutinio lygmens programavimo sąvokas. –Objektų, operacijų, testų rolės, kiti planai ir apribojimai Srities planai apima visas žinias apie probleminę sritį, išskyrus kodą ir žemo lygmens algoritmus.

39. Programų suvokimas39 Teksto struktūra Programos tekstas ir jos struktūra –Valdymo struktūra: iteracijos, sekos, sąlyginiai sakiniai –Kintamųjų paskelbimai –Iškvietimo hierarchijos –Parametrų apibrėžtys Mikrostruktūra – programos sakiniai ir jų sąryšiai.

40. Programų suvokimas40 „Gabalai“ (fragmentai) Makrostruktūra Įvairaus lygmens abstrakcijos Galima apjungti į didesnius „gabalus“

41. Programų suvokimas41 Planai (objektai) Žinių elementai skirti interpretacijoms, teiginiams ir lūkesčiams validuoti Apjungia priežastinių ryšių žinias apie informacijos strautus ir sąryšius tarp programos dalių Programavimo planai –Pagrįsti programavimo konceptais –Žemo lygmens: ciklai ir sąlyginio kodo segmentai –Vidutinio lygmens: paieška, rūšiavimas, sumavimas ir t.t Aukšto lygmens Srities planai –Visos žinios apie probleminę sritį –Pavyzdžiai: probleminės srities objektai, sistemos aplinka, domain-specific solutions and architectures.

42. Program understanding42 Dinaminiai mentalinių elementų modeliai Strategija, kuri aprašo veiksmų, reikalingų tam tikram tikslui pasiekti, seką –Kodo eilučių skaitymas ir supratimas kuriant mentalinį modelį Žinias kuriančių mechanizmų supratimas –Fragmentavimas (Chunking) kuria naujas aukštesnio abstrakcijos lygmens struktūras iš žemesnio lygmens abstrakcijų –Kryžminis indeksavimas susiej skirtingus abstrakcijos lygmenis Komponentai yra procesai, epizodai, veiksmai –Procesai yra epizodų sekos –Epizodai yra veiksmų sekos –Veiksmai yra elementarios programuotojo veiklos priežiūros metu

43. Programų suvokimas43 Kryžminis indeksavimas Programos dalių atvaizdavimas į funkcinius aprašus temp = a; a = b; b = temp; for (i=0; i<size; i++) if (array[i]==target) return true; swap sequential search

44. Programų suvokimas44 Pagalbiniai elementai Švyturiai –Atpažįstami informacijos blokai. Pvz., reikšmių sukeitimo blokas rikiavimo procedūroje –Patyrę programotojai atpažįsta greičiau –Parastai naudojama atliekant supratimą iš viršaus į apačią Diskursas –„Programuotojų susitarimų visuma“ Pavyzdžiai: kodavimo standartai, geroji praktika, tikėtinas duomenų struktūrų naudojimas, šablonai

45. Programų suvokimas45 Kognityviniai modeliai Letovsky Shneiderman and Mayer Brooks Soloway, Adelson and Ehrlich Pennington Mayrhauser and Vans (integruotas meta- modelis)

46. Programų suvokimas46 Letovsky modelis

47. Program understanding47 Letovsky modelis Three main components: knowledge base, mental model (internal representation), and assimilation process. Maintainer produces a mental representation by combining existing knowledge through a assimilation process of external representation of the software The knowledge base contains programming expertise, problem-domain knowledge, rules of discourse, plans, and goals. The mental model has three layers: a specification, an implementation, and an annotation layer.

48. 48 Specification layer - highest abstraction level completely characterizes the program goals. Implementation layer contains lowest level abstraction, with data structures and functions Annotation layer link each goal in the specification layer to its realization in the implementation layer. The assimilation process occurs either top-down or bottom-up in the way they think yields the highest return in knowledge gain. Letovsky modelis

49. Programų suvokimas49 Shneiderman modelis

50. Program understanding50 Shneiderman modelis Proposed in 1979 Based on two forms of programming knowledge – syntactic and semantic (general and task related semantic knowledge) Describes the comprehension process that transform the program in short-term memory into internal semantic knowledge via a chunking process

51. Shneiderman modelis 51 Comprehension model recodes the program in short- term memory into an internal semantic representation via a chunking process. These internal semantics contain different levels of program abstraction. At the top are high-level concepts such as program goals. The lowest levels contain details such as the algorithms used to achieve program goals.

52. Shneiderman modelis 52 Long-term memory, a knowledge base with semantic and syntactic knowledge, assists during internal semantics construction. Syntactic knowledge is programming language dependent, while semantic knowledge concerns general programming knowledge independent of any specific programming language. Like working memory, semantic knowledge in long-term memory is layered and incorporates high-level concepts and low-level details. Program understanding is directional: It starts with the program code and continues until the problem statement is reconstructed.

53. Programų suvokimas53 Brooks modelis

54. Program understanding54 Brooks modelis Describes program comprehension as developer’s reconstruction of domain knowledge Program comprehension is complete when a complete set of mappings can be made from the top level domain (problem domain) to the bottom level domain (programming domain). Domain knowledge emphasizes the function of information contained in the software Developers comprehend the program by recreating mappings from the problem domain or real-world problems, to the programming domain through several intermediate knowledge domains. Intermediate domains are used to decrease the gap between problem and programming domain.

55. Brooks modelis 55 Four different knowledge domains to reach the programming domain: inventories, accounting, mathematics, and programming languages. Knowledge within each domain includes details about domain objects, the operations allowed on them, and the order in which operations are allowed Inter-domain knowledge describes the relationships between objects in different but closely related domains

56. Brooks modelis 56 The mental model is built through a top-down process that successively refines hypotheses A cognitive process verifies that internal representations reflect knowledge contained in external representations such as code, design documents, or requirements specifications. Beacons are the main vehicle for this verification, which is also hypothesis driven.

57. Program understanding57 Programų švyturiai („beacons“) The information required for hypothesis generation and refinement is manifested in key features: Internal features and External features to the program – –known as beacons which serve as typical indicators of the presence of a particular structure or operation

58. Program understanding58 Programų švyturiai („beacons“) (1) Internal to the program text 1. Prologue comments, including data and variable dictionaries 2. Variable, structure, procedure and label names 3. Declarations or data divisions 4. Interline comments 5. Indentation or pretty-printing 6. Subroutine or module structure 7. I/O formats, headers, and device or channel assignments

59. Program understanding59 Programų švyturiai („beacons“) (2) External to the program 1. Users' manuals 2. Program logic manuals 3. Flowcharts 4. Cross-reference listings 5. Published descriptions of algorithms or techniques

60. Programų suvokimas60 Soloway modelis

61. Program understanding61 Soloway modelis Developer constructs a hierarchy of goals and plans top-down based on rules The model suggests decomposing the code into familiar elements that will be the foundation for the internal representation of the system Uses three types of plans: strategic, tactical, and implementation. Strategic plans describe a global strategy used in a program or algorithm and specify language independent actions.

62. Soloway modelis 62 Tactical plans are local strategies for solving a problem; these plans contain language-independent specifications of algorithms. Implementation plans are language dependent and are used to implement tactical plans; they contain actual code fragments. A mental model is constructed top-down. It contains a hierarchy of goals and plans. Rules of discourse and beacons help decompose goals into plans and plans into lower level plans.

63. Soloway modelis 63 The triangles represent knowledge (programming plans or rules of discourse). For example, a subset of the rules of discourse might include the following: variables updated same way as initialized, no dead code, a test for a condition means that the condition must be potentially true, don't do double duty with code in a non-obvious way, and an If is used when a statement body is guaranteed to execute only once; a While is used when the statement may need to be executed repeatedly.

64. Soloway modelis 64 The diamond represents the understanding process. The rectangles illustrate internal or external program representations. External representations include documents such as requirements or design documents; code; user, reference, or maintenance manuals; and other miscellaneous related documents. Internal representations include plans and schemas. The understanding process matches external representations to programming plans using rules of discourse to select plans, by setting expectations.

65. Programų suvokimas65 Pennington modelis

66. Program understanding66 Pennington modelis Developers build a program and situation model bottom-up from the elementary blocks source code Program model represents a control-flow abstraction of the code that identifies the elementary blocks of code control in the code. Situation model represents the problem domain or real world The program model is usually developed before the situation model.

67. Pennington modelis The program model is created buttom-up via the chunking of microstructures into macrostructures and via cross-referencing. Programming plan knowledge, consisting of programming concepts, exploits existing knowledge during the understanding task and infers new plans for storage in long-term memory. A situation model is built by cross-referencing and chunking. Beacons can invoke a particular schema (for example, a swap operation causes the programmer to recall sorting functions). Code statements and their interrelationships form the microstructure. 67

68. Pennington modelis The model requires knowledge of real-world domains, such as generic operating system structure and functionality for the operating system domain. Domain plan knowledge is used to mentally represent the code in terms of real-world objects, organized as a functional hierarchy. Lower order plan knowledge can be chunked into higher order plan knowledge. 68

69. Programų suvokimas69 von Mayrhauser and Vans modelis von Mayrhauser and Vans modelis

70. Program understanding70 von Mayrhauser and Vans modelis Meta model consisting of four main components: –top-down model, –situation model, program model, and –knowledge base Knowledge base is the foundation to build the three former models through comprehension process

71. von Mayrhauser and Vans modelis The integrated code comprehension model has four major components: the top-down, situation, and program models and the knowledge base. The first three reflect comprehension processes. The fourth is needed to successfully build the other three. Each component is involved in the internal representation of the program (or short-term memory) and a strategy to build this internal representation. The knowledge base furnishes the process with information related to the comprehension task and stores any new and inferred knowledge. 71

72. von Mayrhauser and Vans modelis For large systems, a combination of approaches to under standing becomes necessary. Therefore, the integrated model combines the top-down understanding of Soloway, Adelson, and Ehrlich with the bottom-up understanding of Pennington. Nevertheless, experiments show that programmers switch between all three comprehension model Any of the three sub models may become active at any time during the comprehension process. For example, during program model construction, a programmer might recognize a beacon indicating a common task such as sorting. 72

73. von Mayrhauser and Vans modelis This leads to the hypothesis that the code sorts something, causing a jump to the top-down model. The programmer then generates sub goals and searches the code for clues to support these sub goals. If the programmer finds a section of unrecognized code during this search, he may return to program model building. Structures built by any one model component are accessible by the other two, but each model component has its own preferred knowledge types. 73

74. Programos kodo peržiūra (Software Inspection) Program understanding74

75. Program understanding75 Software inspection One of most effective quality assurance techniques in software engineering. The primary goal of an inspection is to detect defects before the testing phase begins Contributes to improve the overall quality of software with the corollary budget and time benefits

76. Program understanding76 Software inspection taxonomy

77. Program understanding77 Dimensions of inspection (1) The goal of technical dimension is to characterize different inspection methods to identify similarities and differences among them. Each inspection approach needs to be characterized in more detail according to the –activities performed (process), –the inspected software product (product), –the different team roles as well as overall optimal size and selection (team roles, size, and selection), –and the technique applied to detect defects in the software product (reading technique).

78. Program understanding78 Technical dimension

79. Program understanding79 Technical dimension - Activities Planning, Overview, Defect Detection, Defect Collection, Defect Correction, and Follow-up.

80. Program understanding80 Technical dimension - Planning The objective of planning phase is to organize a particular inspection when materials to be inspected pass entry criteria, e.g. when source code successfully compiles without syntax errors The overview phase consists of a first meeting in which the author explains the inspected product to other inspection participants. The main goal of the overview phase is to make the inspected product more lucid and, therefore, easier to understand and inspect for participants.

81. Program understanding81 Technical dimension – Defect Defect detection phase - core of an inspection. The main goal of the defect detection phase is to scrutinize a software artifact to elicit defects. Defect collection –Defects detected by each inspection participant must be collected and documented. –Decision must be made whether a defect is really a defect.

82. Program understanding82 Technical dimension – correction Throughout the defect correction phase, –the author reworks and resolves defects found or –rationalizes their existence The objective of the follow-up phase is to check whether the author has resolved all defects. –one of the inspection participants verifies the defect resolution

83. Program understanding83 Dimensions of inspection (2) The managerial dimension provides information on the effects inspections have on a project Managers are most often interested in the way inspections influence –project effort (effort), –project duration (duration), and –product quality (quality). May have other effects a manager might be interested in, such as their contribution to team building or education in a particular project

84. Program understanding84 Dimensions of inspection (3) The organizational dimension characterizes the effects inspections have on the whole organization and vice versa. Subdimensions: –project structure –team –environment These subdimensions provide important information on the context in which inspections take place.

85. Program understanding85 Dimensions of inspection (4) The assessment dimension includes –qualitative (qualitative assessment) and –quantitative assessment (quantitative assessment) of inspections. This dimension allows one to make a comparison of cost/benefit ratios in a given situation to determine the economics for a software inspection implementation.

86. Program understanding86 Dimensions of inspection (5) Finally, the tool dimension describes how inspections can be supported with tools. –purpose of the various tools (purpose) –how they support a given inspection approach (supported inspection approach).

87. Program understanding87 Inspection roles Organizer: plans all inspection activities within a project Moderator: ensures that –inspection procedures are followed –team members perform their responsibilities for each phase –moderates the inspection meeting Inspector: responsible for detecting defects in the target software product

88. Program understanding88 Inspection roles Reader/Presenter: in inspection meeting, leads the team through the material in a complete and logical fashion. Author: develops the inspected product and is responsible for the correction of defects during rework. Recorder: responsible for logging all defects in an inspection defect list during the inspection meeting. Collector: consolidates the defects found by the inspectors if there is no inspection meeting.

89. Program understanding89 Generic model of inspection

90. Program understanding90 Inspection quality model

91. Program understanding91 Inspection quality factors Increasing the number of inspectors is expected to increase the number of defects detected in an inspection. However, there will be a ceiling effect after which adding an additional inspector does not necessarily pay off in more detected defects. Using very experienced inspectors is expected to increase the number of detected defects in an inspection. Spending more effort for defect detection is expected to increase the number of defects detected in an inspection. The difficulty of a product is related to the defect-proneness. This means that a more difficult software product contains more defects. The larger the size of an inspected product, the more defects are detected in an inspection The higher the initial quality of the inspected document, the lower the number of detected defects.

92. Program understanding92 Inspection effort

93. Program understanding93 Inspection effort Increasing the number of people increases inspection effort. The more experienced the inspectors, the less effort they consume for defect detection and, thus, for the overall inspection. The more difficult (e.g., complex) a product, the more effort is required for inspecting it. The larger the size of the inspected product, the more effort is required for its inspection.

94. Program understanding94 Įgytos žinios Programų suvokimas ir programų priežiūra Programų suvokimo modeliai Programų inspekcija

95. Program understanding95 Literatūra Penny Grubb, Armstrong A. Takang. Software Maintenance: Concepts and Practice. World Scientific Publishing Company; 2 ed., 2003. Diomidis Spinellis. Code Quality: The Open Source Perspective. Addison Wesley Professional, 2006. Bill Blunden. Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code. Apress, 2003. Stan Jarzabek, Effective software maintenance and evolution : a reuse ‑ based approach. Taylor & Francis Group, 2007. Oliver Laitenberger, Jean-Marc DeBaud, An encompassing life cycle centric survey of software inspection, Journal of Systems and Software, 50(1), 2000, 5-31.

96. Programų suvokimas96 Papildomi šaltiniai Von Mayrhauser, A. and Vans, A. M. Programų suvokimas During Software Maintenance and Evolution, IEEE Computer,1995. (lecture notes) Susan Elliott Sim. Research in Program Comprehension (UC Irvine lecture notes). Jonathan Maletic. Programų Comprehension & The Psychology of Programming (Kent State University lecture notes). Richard Upchurch. Program Comprehension. From Software Process Resource Collection. UMass – Dartmouth, 1996.