Nutshell thoughts (off the top of my head).
Methods are basically there to manage the complexity of projects, other wise we'd all just start hacking, and still finish on time/budget.
A procedural method conentrates on capturing, modelling and programming functions / precedures that do stuff, to data. Example, JSP (Jackson structured programming, not java server pages, Jackson was there first
), JSP use functional decomposition to decompose a problem in sub-problems based on what you want it to do (functions). In theory eventually you get to functions that are simple enough to understand, and design code (functions again) that will solve your problem. Also important might be sequence and state. Imagine a "number cruncher" program, we're going to worry about modelling the "Crunching".
An OO method concentrates on modelling the objects, the things. Not just the data that has stuff done to it, but also the things that are doing the stuff to the data. So you would decompose big objects like "House" into smaller objects like "roof", "door" and "toilet", until you get to objects simple enough that you can model them in code as Classes, with data and methods, and data objects. So we're going to model the "number cruncher" and the "numbers", although the "number cruncher" can have both internal "numbers" and a "crunch" method. I can't think of an OO method by name of the top of my head, is the Rational unified process OO structly??
Lastly you have methods that are not tied to procedural or OO, possibly because they are looser. For example I like Jackson's problem frames for requirements and specs, which use Heirarchical decomposition to describe the problem not the solution. Then when you get to design, you can still decide whether to concentrate on functions in C, or objects in Java, or a bit of both and code in any language known to man.
Verbal dischage ended*
* Nominal value of this post £0.02
Edit* I added a bit more - apologies!