10 citations found. Retrieving documents...
Lakhotia , A., "Understanding Someone Else's Code: An Analysis of Experience", J. Systems and Software, 1993, pp. 269-275

 Home/Search   Document Details and Download   Summary   Related Articles   Check  

This paper is cited in the following contexts:
Software Change and Evolution - Rajlich (1999)   (1 citation)  (Correct)

.... The programmers usually employ a combination strategy with elements of both the top down and the bottom up process [22] A part of program comprehension strategy is the fact that the programmer does not need to comprehend everything about the program in order to be able to make a change [10]. Usually it is sufficient to comprehend the relevant parts or aspects of the program. The information needs vary from task to task, and while there is a need to understand some parts of the program in great detail, other parts can be understood only roughly and still other parts scarcely at all. ....

A. Lakhotia, Understanding Someone Else's Code: An Analysis of Experience , J. Systems and Software, 1993, 269-275


Case Study of Feature Location Using Dependence Graph - Chen, Rajlich (2000)   (9 citations)  (Correct)

....is hard to formalize and the programmer who has this knowledge must participate in the location process. Figure 1. Concept location process Another factor is the high cost of comprehension of large legacy systems, which makes a full comprehension of the program impractical and unnecessary [5, 12]. The programmers must limit the scope of their investigation and comprehend only parts, while making sure that the comprehension is sufficient for the maintenance task. They need a scenario that divides the comprehension into steps and gives feedback from each step. The feedback will help them to ....

....confirm that it is unnecessary for a programmer to fully comprehend a program before maintenance. They proposed seven questions to be answered by the programmer before he or she can maintain the program. These questions are about domain knowledge, control flow, and data flow information. Lakhotia [12] performed two case studies on practical systems: modification of GNU C Compiler (gcc) and modification of Wisconsin Program Integration Systems (WPIS) He used function call graph, and used command grep, more, and emacs editor. He described the feature location process and concluded that partial ....

[Article contains additional citation context not shown here]

A. Lakhotia, "Understanding Someone Else's Code: Analysis of Experience", Journal of Systems and Software, Vol. 23, pp. 269-275 (1993).


Cognitive Design Elements to Support the Construction of .. - Storey, Fracchia, Müller (1999)   (27 citations)  (Correct)

....behavioral differences due to the problem domain, differences in program text, individual differences and the purpose for understanding the program. Von Mayrhauser and Vans [25] discriminate between the different strategies required for programs of varying sizes and different tasks. Lakhotia [26] noticed that the availability and validity of documentation had a strong impact on the comprehension strategy. Tilley et al. 2] describe how the experience and creativity of the maintainer will have an effect, as well as the quality, size and complexity of the program to be understood. Table 1 ....

A. Lakhotia. Understanding someone else's code: Analysis of experience. Journal of Systems and Software, 23:269--275, 1993.


Interactive Explanation of Software Systems - Johnson, Erdem (1996)   (9 citations)  (Correct)

....the tasks that users might need to perform, and provide information to help achieve them. Although advocates of minimal manuals claim that novice users are in particular need of task oriented documentation, it is reasonable to hypothesize that software professionals would benefit as well. Lakhotia [8], for example, quotes a software developer who says that what he would like in the way of a software understanding tool is something that helps me get the job done, fast. Unfortunately, the tasks of software professionals in general are not precisely defined. User manuals can be oriented toward ....

A. Lakhotia. Understanding someone else's code: Analysis of experiences. Journal of Systems Software, 2:93--100, 1993.


Creating a Research Infrastructure for Reengineering - Rugaber, Wills (1996)   (8 citations)  (Correct)

....and transformation rules in support of program recognition and tranformational analysis. 4. Grammars machine processable programming language grammars. 5. Experiments descriptions of repeatable program comprehension experiments and the materials to replicate them, such as described by [14] and [24] 6. Case studies a systematic collection of case studies, uniformly documented so as to provide guidance to development managers, such as those performed by [9] This would serve as a first step to a cost model, such as Cocomo [4] and for a reengineering decision procedure. 7. Public ....

A. Lakhotia. "Understanding Someone Else's Code: Analysis of Experiences." Journal of Systems and Software, Elsevier Science, Volume 23, December 1993, 269-175.


A Cognitive Framework For Describing And Evaluating Software.. - Storey (1998)   (10 citations)  (Correct)

.... purpose for understanding the program [17] Von Mayrhauser and Vans discriminate between the different strategies required for programs of varying sizes and different tasks [175] Lakhotia noticed that the availability and validity of documentation had a strong impact on the comprehension strategy [75]. Tilley et al. describe how the experience and creativity of the maintainer will have an effect, as well as the quality, size and complexity of the program to be understood [163] This section gathers and analyzes the various factors which influence the comprehension process. These factors are ....

A. Lakhotia. Understanding someone else's code: Analysis of experience. Journal of Systems and Software, 23:269--275, 1993.


Archetypal Source Code Searches: A Survey of Software.. - Sim, Clarke, Holt (1998)   (4 citations)  (Correct)

....be followed, which means jumping from one function definition to another. In the past, research in program comprehension has focussed on a specific development or maintenance task. These studies looked at the construction of mental models in program understanding [3, 10, 14] program maintenance [9], and defect repair strategies and behaviour [5, 8] Searching is an integral part of models of these activities. Over several studies and different measures, Singer et al. found that searching was the most common activity for software engineers [12] Aside from this work, there has been little ....

A. Lakhotia. Understanding Someone Else's Code: Analysis of Experiences. Journal of Systems Software, 23:269-275, (1993).


The Role of Concepts in Program Comprehension - Rajlich, Wilde (2002)   (2 citations)  (Correct)

No context found.

Lakhotia , A., "Understanding Someone Else's Code: An Analysis of Experience", J. Systems and Software, 1993, pp. 269-275


PESCE: a Search-based System to Automate the Generation .. - Adobbati, Johnson..   (Correct)

No context found.

A. Lakhotia 1993. Understanding Someone Else's Code: Analysis of experiences. Journal of Systems and Software 20, 93-100.


Faster Reuse and Maintenance Using "Software Reconnaissance" - Wilde (1994)   (1 citation)  (Correct)

No context found.

Lakhotia, A., "Understanding Someone Else's Code: Analysis of Experience", Reverse Engineering Newsletter , Vol. 4, January 1993, IEEE Computer Society, pp. 6 - 8.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC