Software reengineering in Software Engineering - Time & Space Complexity
When we reengineer software, we often analyze how the effort grows as the software size increases.
We want to understand how the time needed to improve or modify software changes with its complexity.
Analyze the time complexity of the following simplified reengineering process.
for module in software_modules:
analyze(module)
for component in module.components:
refactor(component)
test(module)
This code represents going through each module, analyzing it, refactoring its components, and then testing the module.
Look at the loops and repeated steps:
- Primary operation: The inner loop refactoring each component inside a module.
- How many times: For each module, all its components are processed one by one.
As the number of modules and components grows, the total work increases.
| Input Size (modules x components) | Approx. Operations |
|---|---|
| 10 modules x 5 components | ~60 operations |
| 100 modules x 5 components | ~600 operations |
| 100 modules x 50 components | ~6000 operations |
Pattern observation: The total work grows roughly with the number of modules times the number of components per module.
Time Complexity: O(m x c)
This means the time needed grows proportionally to the number of modules (m) multiplied by the number of components (c) in each module.
[X] Wrong: "Reengineering time grows only with the number of modules, ignoring components inside."
[OK] Correct: Each module has many components, and refactoring each one takes time, so ignoring components underestimates the effort.
Understanding how effort scales with software size helps you explain project planning and resource needs clearly in interviews.
"What if we automated the refactoring step for each component? How would that change the time complexity?"