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 Software Developers (in which case they singlehandedly play all the above roles) that consumes massive amounts of coffee and pizza and generates bugs, code, documentation, Repetitive Stress Injury, Eye Strain, and Lower Back Problems.
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. (Matt Heusser adds - yes, of course, it is an afterthought. The purpose of Software Development is to produce the software. Documentation may be valuable, but it isn't software. Otherwise, we'd call it Documentation Development - right?)
It's not always like this..
It generates documentation? Since when? (Ha Ha Only Serious)
It generates a (perceived) need for documentation, which, if and when actually produced, is promptly filed away and forgotten. -- John Reynolds The Student
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.
Software Development is an activity, an event, and a process.
Software Development 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 Software Development).
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: Most Applications Needa User Manual, Withouta User Manual, Product Testing, Acceptance Testing, Beta Testing, Language Wars
See original on c2.com 