At the start, there are no formal rules on how to develop an application. The main focus is getting the application out the door with little thought to process.
Analysis: requirements may or may not be written (by the time development is complete, there is likely considerable business logic in the application which is not formally documented)
Design: again there is probably little formal design (any design is mostly verbal and driven by one or two leaders).
Development: programmers develops code as they see fit the one requirement is that "it works".
Testing: Testing is probably haphazard. Users likely discover many of the bugs (hopefully in a "beta" release). Because there is little documentation, it is hard to distinguish between bugs and new ideas (or enhancements).
As developers maintain existing applications, they will likely become dissatisfied for several reasons:
A new person coming from another more formal organization may join the team. The person often helps the team take the first steps to formalization including:
Analysis: documenting the requirements and having the users review the requirements prior to full-scale development.
Design: documenting the major components in the application, especially reusable components to reduce duplication of logic.
Development: writing code subject to a set of formal coding standards (including standards for naming, commenting, etc.)
Testing: assigning a person who is responsible for testing the whole application before it is given to users. Testing will refer back to written requirements (although those standards may not have been kept up-to-date through the development process).
Many small-to-medium organizations do not move beyond the Early Formalization stage. While many types of organizations might adopt formal methodologies, these methodologies are most widespread for organizations in the following categories:
... back to Methodology Topics