An activity involving professionals such as Technology Architects, System Analysts, Project Managers, Programmers, Technical Writers and Testers (QA/QC). Sometimes it is performed just by Computer Scientists or SoftwareDeveloper''''''s (in which case they singlehandedly play all the above roles) that consumes massive amounts of coffee and pizza and generates bugs, code, documentation, RepetitiveStressInjury, EyeStrain, and LowerBackProblem''''''s.

Documentation, from design documentation, to in-line code documentation, to deployment documentation, to user documentation, even though one of the most important activities for proper software development and maintenance through its life cycle, seems to be in most cases an afterthought. (MattHeusser adds - yes, of course, it is an afterthought. The purpose of SoftwareDevelopment is to produce the software. Documentation may be valuable, but it isn't software. Otherwise, we'd call it DocumentationDevelopment - right?)

It's not always like this..

''It generates documentation? Since when? (HaHaOnlySerious)''
----
'''''It generates a (perceived) need for documentation, which, if and when actually produced, is promptly filed away and forgotten.''''' -- JohnReynoldsTheStudent
----
My concern is, given a certain piece of software, which is the enough, useful and readable documentation that must be generated, to make the corresponding maintenance task independent of the original/previous programmers - Metodio Cruz
----
* The act of developing the programs, routines, and symbolic languages that control the functioning of hardware and direction of its operations.
* A significant event, occurrence, or change in the Developing of Software.
* An activity where the best techniques, methods and processes are applied to produce software product.
* SoftwareDevelopment is an activity, an event, and a process.
* SoftwareDevelopment involves individuals, teams and organizations in the attempt to provide reliable, fully-functional products for use on individual or enterprise-wide platforms.
* The state of software while being developed (i.e., the new product is in SoftwareDevelopment).
----
In regard to documents: the documents produced as a part of the process of software development should be little different from those produced by any other engineering discipline. Of course, this is presuming that the other required components of the process have already produced their own documents:
	* A set of requirements that identifies what is essential, what is flexible, and a clear distinction between the two.
	* A product specification that enumerates all of the product's characteristics as measurable quanta.
	* An architecture that describes how the product will meet the spec, what additional headroom will be in the product's capabilities, and the limitations on those capabilities.
	* A design that separates the services required to support the architecture into electronic, mechanical, software, and other operational components. Additionally, this design identifies how the components interface to each other and to the outside world, when called for.
If you have all this good stuff then you can create the implementation plan. That means outline the code. The implementation plan doesn't necessarily have all the details of every function in it, but it should block out the functionality the way the design separates functionality into components. This document comes ''before'' the code is composed, and should be altered any time a significant change in the implementation (code) is planned.
----
See: MostApplicationsNeedaUserManual, WithoutaUserManual, ProductTesting, AcceptanceTesting, BetaTesting, LanguageWars

CategorySoftwareDevelopment