The cost of change in complex software systems is very high as more often than not it affects a lot of different locations. Separating the system into modules (or components or microservices) is a common approach towards maximum program flexibility with minimum costs.
Parnas Partitioning is a technique for the definition of the module boundaries. It's goal is that when a change is required it impacts only a single statement, a single module, or the minimum amount of modules. The technique starts with the creation of a Hiding Assumption List. It contains the characteristics of the system which are likely to change in future.
The Hiding Assumption List contains anticipated changes from all levels of the system: system requirements, system design, and software design. It should be written in plain English so that it is understandable for everyone.
A good understanding of the problem domain is important to be able to anticipate the nature of probable changes. Thus all stakeholders should be involved, including end users.
- Start with brainstorming to find possible areas of change
- Order assumption according to probability
- Determine impact of change
- Assign categories
- Derive design decisions to minimized the impact of changes
- Prioritize design decisions according to probability and required effort
This blog post is a summary of the Hiding Assumptions and Parnas Partitioning article by Jody Paul.