All system development methodologies are just terminology plus recategorizations of existing work activities plus graphical notation.
Methodology literally means "study of method." What people probably mean when they say methodology is "method." Some time during the last 30 years or so "method" didn't seem impressive enough so we were all cajoled into using "methodology." Which should tell you something.
Arguing over whether testing is part of development or a separate thing in and of itself, and whether we're spiralling or waterfalling or iterating is only helpful in the context of selling software and training to use the software and consulting services, all in the name of implementing a methodology and transferring money from your budget to some outside entity who has sold you on the idea that their methodology will fix all your problems.
Honestly, all of this is built around an initial premise of "You're doing it wrong." You must be doing something wrong, you're looking for a better way aren't you?
The right way isn't so complicated that you need consulting services or training or new software to implement it. The right way is so simple you've overlooked it, dismissed it as being impossibly simple. The right way isn't even a secret.
The right way is the Belgian Gambit: Figure out what your target audience needs and then deliver that.
Anything you do in service of determining what your target audience needs is correct. Okay, within reason; don't break the law or even your organization's work rules. Talk to your users, watch them do their job, have them teach you their job, sit in on the training for new hires in your user's jobs, read their orientation materials. Learn what it is your users do.
If it makes you happy to organize your thoughts by drawing pictures, do so. Just don't try to force your methods of organization on anyone else. What works for you may not work for anyone else, that it works for you just means it works for you. UML is not a goal, it's a tool and if it doesn't work for you that's okay, use a different tool.
Whenever people scheduled meetings with me, they were sure to include a whiteboard as required equipment because I would always start drawing pictures. I had coworkers who really wanted to capture these pictures and I disagreed with them about their value. I insisted that the value was in not the picture as an artifact but drawing the picture and the patter that went along with that activity. It's about conveying information.
For those moaning that this results in everyone doing things a different way instead of their way, which is the one true way, and that the resulting chaos and horror could all be avoided if we all simply did as they instruct, because they have named the steps of analysis and trademarked the one true graphical notation and created templates for both the required and optional artifacts, I say that I have read their holy writ and found their secrets less than illuminating.
Now look at what tools already exist in your IT shop. These are the materials from which you will construct a system. Put them together in different ways, trying to solve problems you experienced or observed whilst learning about your users' jobs. Holes in the partially completed system suggest tool acquisitions, or new uses of existing tools. Apply your automation skills to improve your users' lot.
How the work gets done is significantly less important than that it gets done. Methodology mavens would have you believe the reverse.
You're welcome. Also, it's called the Belgian Gambit because I get to name things now.