Since at least as far back as the early 1970s, much has been written about how software engineers should go about developing software. The various approaches described are often called methodologies, but sometimes other terms such as development process (or more simply, just process or method) are also used. The problem, as always in a rapidly evolving field, is that the terms are not necessarily synonymous, and even the same term is not used consistently by all writers, even though they may all be referring to essentially the same concept.

A methodology generally describes a sequence of steps for the performing analysis, design, and implementation necessary for developing a software project. In any particular methodology, some of the things that might be recommended (or even required) include:

It is generally regarded as a good idea for any organization, of whatever size, that is involved in the development of software, of whatever complexity, to follow some specific methodology. Since the methodology field is still very far from mature, all recommendations as to what that methodology should be, for any particular organization, should be viewed with some suspicion. In fact, a reasonable approach is to look around and find out what is working for others, and, if possible, choose the best from as many worlds as you can examine, in whatever time you have available. Keep in mind, though, that all involved members of the organization need to be able to communicate with one another about the project, in order to exchange information and coordinate their activities. Therefore, at a minimum, there must be a common notation and terminology in use, and everyone must know what steps are being followed.