The term reversibility in the context of software development means the possibility of propagating independent changes made to the resulting source code back into the design and analysis models of earlier phases, so these can be kept up to date with what is actually executed.
As any experienced developer knows, going full circle everytime a change is to be made: first modify the higher level models, then translate these changes into the corresponding code changes, is totally unfeasible in practice. And yet, most books and papers on analysis and design of software systems continue (at best) to pay lip service to the issue of reversibility, before proceeding to methods and concepts that are completely non-reversible, as if the world consisted of the toy examples elborated in the texts.
Since maintenance of software systems involve continuous modification of source code, any method based on concepts that are not unambiguously translatable to and from the programming constructs used in the code, will produce high-level models that immediately start to deviate from the real system. Therefore, the developers will stop trusting the models almost from day one, and the binders containing the bubble diagrams will stay on the shelves. Alternatively, a designer group will continue to talk in terms of the bubbles, while the programmers, who are forced to make things work in practice, will think in terms of the concepts of their language, preventing any effective commuication between the two.
In short, we need to use the same basic concepts for analysis and design as we will in our source code. The object-oriented abstraction has the potential to serve as such a universal concept. But only if the models are kept free from mismatching concepts drawn from other paradigms, such as entity-relationship modeling and/or central emphasis on use cases.
My IEEE Computer article from 1996 stating the case for reversibility can be found here.