Methodology - a body of methods , rules, and postulates employed by a discipline.
No single methodology works for every application. Methods that work well on small project can cripple large ones. Similarly, methods that work well on large projects can triple the time to delivery time of a small one. Some methods I use on projects large and small alike.
I always start by learning the what problem I am there to solve. what are your needs, what timelines I need to meet, and what resources are available to me, I will not proceed.
Next I like to research tools and competing products. I have often found other systems that could already do some or most of the work to build the solution. Long term it is almost always better to buy than build. It has been my experience that testing and maintaining software after it's initial construction is many time more expensive than the initial construction. If those costs can be managed by a vendor with many customers, then we can focus our efforts on the remaining parts of the software that we can not purchase.
Once I have a good idea of what I need to build, I draw coarse UML diagrams of the modules or units of the system outlining how they will work together. Then depending on the people on the team and their skill levels I document each unit enough for the person responsible for it to know what is needed and how others will be using that unit, I try to make each unit of work two or less weeks of work.
A unit is done when it has an automated regression test suite that demonstrates that it meets all of the requirements for the unit. A module is done when all of the units needed to make it are done and have been assembled into the module. The system is done when all of the modules are done and assembled into the application.
On small systems with low complexity the initial coarse UML may be the only documentation outside of the source code. On a large-scale system, the functional specifications can be hundreds of pages. What is important here is that six months or two years later when the requirements change and the forms have to be updated, etc. that the people do not have to spend months just trying to figure out what was done and why.
My biggest fear in working on a system is being the only person who knows what is going on. I want as many people as possible to have a good understanding of how everything works. This requires that all parts of the system are documented thoroughly, while some of this documentation is written during the design, some is written during the development. Documentation written after the fact rarely serves the purpose. When people first encounter a complex problem, they have questions that once answered they no longer remember. The next person to study this same piece of code will also likely have the same question.
Academic teaching says that you must document everything up front, the realities of corporate software development tend towards no documentation to meet short timelines. Often this lack of documentation leads directly to the missed deadlines it was supposed to prevent. Similarly, I have seen projects that were run by the book spend so long trying to get the documentation right up front, that the documentation is larger than the entire final software would have been if they had ever started writing it, before the project died.
What I am trying to say is that every project is different. It is a judgment call to determine how much documentation to do and when. I tend towards coarse level documentation up front that describes how the pieces will fit together and allow each developer to describe their implementation for each unit.
Life Cycle
.