Arguably, waterfall is a software development methodology (at least wikipedia thinks so). However, a methodology is a defined set of tools, activities, tasks that offer guidance on how to provide a set of deliverables. In this respect (as a delivery mechanism), waterfall breaks down as a methodology because unless the amount of work that needs to be completed is small, waterfall doesn't easily facilitate the need to make changes to the final set of deliverables once you begin. Expecting things to not change the minute you start is unrealistic.
Waterfall is a good description of the sequential activities that is needed to be completed for software development work. First, you need to figure out what it is that you want to build (i.e. - gather requirements). Then you need to determine how you will accomplish the end result given the limits of the chosen technology (i.e. - design). Then you need to build the solution based upon what you just determined is the best path (i.e. - implementation/construction/development). Then finally, you need to make sure that what you built did in fact solve the problem you initially set out to achieve (i.e. - testing). This list of activities in this order is the de facto standard for software development (yes, you can argue minor adjustments can be made by determining how you will test before you start building using TDD, but the general list remains the same).
However, the key here is to keep the size of work within this cycle small. If you grow the size of work too large, you now incur the risks that is inherent with waterfall as a methodology. This is essentially what agile software development does and why it is more successful in large scale software development projects. It prevents the waterfall cycle of activities from growing too large.