By and large, the exact mix of software development project documentation will be dictated by several factors. The first is whether the project is a new development, an integration project that ties together two pieces of legacy software (especially when merging two existing products or services), or the enhancement of an existing piece of software.
Second, the paradigm chosen by the company will also affect the exact documents that are required, since those projects that follow an incremental approach, including a phase of prototyping, will have a different document set from those following a more traditional model. Data-driven applications will also have a different document set from real-time embedded systems, for example.
The problem domain will also play a part in choosing what documents should be included, as will the end-user profile. Internal clients and external clients may also have different documentation requirements, and the level of client involvement will affect whether there are pieces of documentation specific to a given external organization that need to be included, for audit purposes, within the document set.
Finally, there is a difference between those pieces of documentation that are handed over to the client as deliverables, and those that are retained for use inside the target organization only, and are not distributed to a wider audience. The following discussion, therefore, is a global approach that can be used as is, or integrated with the existing guidelines offered by the target organization. It tries to be all things to all people, and as such will seem too heavy for some projects, and inevitably will be missing some parts for others.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.