You don't mention Source Control until the end of your post and I'd recommend starting with Source Control if you are developing standards. There are plenty of free/open source source control products out there (subversion, git, mercurial) so that there really isn't valid reason not to have source control and having a branching & merging strategy. So having said that this is how I'd do it:

1. Projects/solutions added to source control. You'll have to determine your branching strategy, but to keep it simple I'd at least have a Production branch and a development branch. You can get more complex with versioning if you want.

A. If vendor supplied check that in as a branch, then create a development branch you work in so you always have the base release branch from the vendor.

2. Changes made and checked into source control - I prefer a distributed development model where the developer has all they need installed locally in order to unit test, then check-in to source control, then deploy to a shared dev environment for integration testing vs. the shared development model where there is a dev environment that everyone works in.

3. Test in dev - more integration than unit testing

4. Deploy to QA for QA testing

5. Deploy to Production

For 7A below you don't have the option of deploying a single package in the Project Deployment model so you have to deploy an entire Project (not solution as a solution can consist of multiple projects).

You don't mention configurations at all, so you really need, especially for the package deployment model, a defined process for configurations so you can move packages between environments without having to change connection strings, etc.. as they should be dynamic based on package configurations. You can do it differently with the project deployment model, but you still need to have standards for that.