Good solutions don't begin with writing code, and they don't end when the code is delivered.
When we take on a project, we believe it is vital to match the outcomes to the client's business goals, and to maintain as much control as possible over a process that is often chaotic and time-constrained. If we can do this it is most likely that the outcome will be what we wish it to be.
With this in mind, and bringing to bear years of hard-won experience, we strive to follow a proven set of methodologies that have resulted in many successful projects.
There are several phases in our process: a) requirements capture, b) system design, c) development, d) test/QA, e) release management, f) maintenance, g) end-of-life. These phases, while not completely discrete, are recognizably distinct steps along the life of a software product. Taken together they become the software life cycle. If we drop the ball on any of them we will have a comparably lower quality product, if we ever get a product at all.
As a minimum, we require a requirements document with a written list of features, performance specs., user interface actions, look and feel requirements, with a prioritization of each if there are budget constraints (when are there not?). This is a contract if you will, between the client and the developer that says "here is what we are agreeing to do".
From this we will produce a design that shows how each feature will be implemented, any required technologies, how various pieces of the system relate to each other, and explicitly spells out how the software is to be implemented. If any compromises must be made with respect to the requirements they will be listed with the reasons why. In some cases it is necessary to prototype parts of the design with some software. It is essential that these "experiments" do not become the product, as they will have been rapidly and roughly developed just as a proof of concept, but may have many design issues.
Only after phases a) and b) are complete will any actual development begin. Here we stress sticking to the design specification, and only deviating when there may be an unforeseen problem with the design. Otherwise, we may experience "creeping featurism" where new requirements come to light during development which will impact the design and hurt our ability to achieve all the requirements effectively. This is the single greatest cause of cost overruns in software development and must be watched very carefully.
During the development phase small, careful changes which are well documented, tracked minutely (using revision control), and are thoroughly tested after each change (using integration builds and unit testing based on a test plan that is developed in parallel with design). As each feature is implemented and verified, a snapshot is taken of the state of the code at that point, so that we can always return to a known state as development progresses. With each integration build, an automated test suite is run to ensure code that was working still is, and that new code is performing as designed. Development of these tests is part of the development process and must be budgeted for. If any failures of tests are noted, these are logged as in a bug tracking system that ranks bugs by severity and tracks them through various releases, until they are fixed and verified through testing.
At some point, the code becomes stable enough, and enough features have been implemented, that one or more pre-releases can be scheduled. These are released outside of the development group to be tested by "beta testers", generally power users who know enough about how the product is supposed to function to determine if it is living up to the requirements. When the testing and resolution of bugs is completed such that the features have all been verified and only a few minor bugs remain, the product can go to production release.
This begins the maintenance mode of the product. Continued tracking of bugs and maintenance releases are ongoing throughout this phase. New features may be added to an update release project, these will be treated the same as the primary release with all the attendant phases. The cycle goes on until the product either becomes obsolete or until its code base becomes un-maintainable, at which point the product is end-of-lifed.