A methodology will consist of phases, themselves consisting of sub-phases, which will guide the systems developers in their choice of techniques that might be appropriate at each stage of the project and also help them plan, manage, control and evaluate research. It is usually based on some philosophical view; otherwise it is merely a method, like a recipe.
We can regard a methodology as a generalized description of the activities of a series of design projects, together with a theory that explains why those projects were successful, and it may be seen as an abstraction from good practice. This is of course not a value free description, since if we know what counts as good practice this entails our having some criteria of goodness. A methodology is usually presented not as a description but as a prescription, a recommendation that projects should follow the generalized task structure.
Some people think of a methodology as if it were a skeleton, on which a project can be hung. As a follower of the methodology, you flesh it out, apply the techniques suggested by it, make your own decisions prompted by it and produce some of the deliverables dictated by it.
How strictly you adhere to the methodology depends on the project goals, and on your own common sense. On this view, a methodology is judged by its usefulness, in guiding an analyst or designer of a given background and ability, to work effectively in a given situation.
One useful source of input to a methodology is to analyse the failures to which projects within the target domain of the methodology are vulnerable. The methodology is then designed to address, and guard against, a specific set of possible failures.