Software Engineering

It's not over after shipping: Software Comprehension

  • Software
  • Software Engineering
  • Software Evolution
  • Software Comprehension

Let me start by describing a typical software engineering nightmare:

You are a developer who has the responsibility of either fixing issues of or adding new features to existing software. Since you were not part of the team who built the system, you have no overview of the system's components, the relationship between the components, or the architectural patterns used. You decide to start your maintenance tasks by reading the documentation. But wait... there is no documentation, and if there is, it is outdated, possibly very long, hard to read, or just incomplete. Since there is little to no documentation, you decide to read the source code. However, understanding it is not that easy. The system is highly complex, the internal quality of the source code is low, and you can't get your head around how the software does what it does.

Sounds familiar?

Welcome to the second part of this series. Previously we discussed the concepts of software maintenance, its challenges, and its importance. However, to successfully maintain a software, it is necessary to have a certain level of comprehension about how the system works. But what is software comprehension? What activities take place while comprehending a system, and most importantly, what are the challenges associated with software comprehension? These are some of the questions that I will be answering in this article.

Research suggests that software comprehension activities account for 60% of software engineering efforts [1]. But the first question we should ask is ...

What does it mean to comprehend a software?

A developer who comprehends a software is one who is able of explaining its architecture, its behavior, and most importantly, the relationship between the software and the domain in which it is applied [1]. Typically, the developers who built a software system are the ones who comprehend it. Unfortunately, it is usually the case that the creators of the software are not the ones who maintain it. So, what should a developer do if he is assigned the task of maintaining a software he is not familiar with? The answer is to Reverse Engineer the software.

What is Reverse Engineering?

Unlike Forward Engineering in which the starting point is an idea, that then moves to design and ends with its implementation, in reverse engineering the starting point in an already implemented software. While doing reverse engineering, the software at hand should not be changed. Instead, it should be examined, and knowledge should be extracted. Such knowledge increases the developer's level of comprehension about the system, which in term help him during the maintenance phase for making improvements and adding new features to the software[2].

While reverse engineering a software system, engineers try to create high-level abstractions that allow them to identify the components of the system and their relationship with each other [2].

Hopefully, at this point, I had made it clear that the purpose of reverse engineering is to examine a software and extract knowledge out of it. However, how do you extract such knowledge? What actions take place during reverse engineering that allows us to obtain knowledge?

Documentation and Design Extraction

Many activities take place during the process of reverse engineering and two of those are Documentation Extraction and Design Extraction. Such activities can be defined as follows:

  • Documentation Extraction is the process of analyzing a software and recovering documentation about the system at hand. Such documentation may explain aspects of the system such as control flow, data flows, data structures, requirements, and more.
  • Design Extraction is the process of analyzing a software to create high-level models about the system's architecture, component diagrams, and component interaction.

Both of these activities enable the developer to obtain a broad view of the various part of the system and comprehend how it works and the different components involved in it working.

Challenges of Software Comprehension

Reverse engineering a software system is not an easy task. Some of the challenges associated with this activity include the following:

  • Software Size and Complexity: As the size and complexity of the software increases, the task of reverse engineering it and thus, comprehending it, increases as well.
  • Creating Useful Graphical Knowledge: Using graphical views as a way of explaining how the system works is beneficial. However, it is challenging to determine what views are the most appropriate and effective for explaining a system.


It is typically the case that developer who maintains a system are not the same ones who built it. Therefore, to successfully add new features and make improvements, it is necessary to comprehend the software at hand. Reverse Engineering is the name given to the process of examining a software and extracting knowledge from a software with the intention of better comprehending it. Performing documentation extraction and design extraction allow developers to extract the necessary knowledge.

However, one challenge of reverse engineering is that as the system's size and complexity increases, reverse engineering a system becomes more difficult. Therefore, what are some appropriate tools that can help us reverse engineer a system and extract knowledge effectively and straightforwardly? In the next part of this series, I will be presenting some tools that I will help you obtain the knowledge you need for understanding a software system.

If you enjoyed this article, please recommend and share. Don't forget to subscribe and follow me on Twitter to stay up-to-date with my latest posts. See you in part 3.


[1] Software Maintenance and Evolution: A Roadmap by K.H. Bennett and V.T. Rajlich.
[2] Reverse Engineering and Design Recovery: A Taxonomy by Elliot J. Chikofsky and James H. Cross II

● ● ●

How would you rate this article?