Documenting an SDLC process

Being a senior of the development team, I've been asked to help generate a more refined process for our team, which right now vaguely follows the SDLC/waterfall method without standardization as to what the boundaries and outputs of each phase are ("here are some requirements, go code!").

Without getting into discussions of different methodologies such as agile (which I like, but will probably start another thread over how to bring that up), are there good reso开发者_StackOverflow中文版urces for formalizing SDLC phases that involve developers? Since the idea is to standardize the process, specific steps or ideas of documentation that are commonly needed would be good to discuss.

I've perused the standard Wikipedia articles and their branches on the topic, and though they give a good general overview, I'd like to start pulling out a general process for us to follow. Incremental steps to avoid a big-bang approach would be helpful, as well.

If it helps, the team is mostly cowboy coders, with the only official deliverable being the end result of the code itself. There are many other steps and deliverables in design, documentation, and whatnot that the industry has already accepted, so that's what I'm after: what's worked and what's just fluff when it comes to the extra deliverables in the process.

---

I can suggest a method engineering approach. There are standards such as ISO/IEC 24744 that give you a language (a set of concepts and relationships) that you can use to describe the method that is expected to be followed, including:

• what is to be done, i.e. processes, tasks, techniques.
• to what is to be done, i.e. documents, models and other products.
• who does it, i.e. people, teams and tools.
• when it is done, i.e. phases and milestones.

See my answer here for a related perspective.

Let me know if you need additional information.