Software development process is like religion.  There are a lot of different ones, and some people get fanatically attached to one or another.  I like a simplified process that doesn't overly burden the organization, but provides a reasonable degree of control.

The fists step in any process is documenting the requirements.  This entails writing down what the software is going to do and how it looks to the user.  This is a critical and important step so that we can assure that what eventually gets delivered meets the expectations of the users.   Too often people skip this step and dive right into implementation without really understanding what they are going to build.

The second step is to document the design.  This is just as important as collecting the requirements as in this stage, (if done properly) any assumptions or missed requirements will arise.  It's much simpler to get them clarified at this point than waiting until the code is delivered and THEN discovering that the missing information "supplied" by the developer is totally wrong.

Testing is important.  I have worked with everything from Test First to throw it over the wall and see if it sticks.  Depending on what is being developed, there are different levels and approaches to testing that are most appropriate.

Source and Release Control are also critical.  I don't know how many times I have worked with a new group that did a release "from Joe's box" or pulled "the latest" component from each of the developers and stitched them together to make a release.  This sounds so innocent, but can really lead to problems.  Development is an ongoing process while maintenance is an ongoing necessity.  You can't safely overlap the two.