The Software Process is the means by which prioritized requirements and committed budget are transformed, by a software development team, into useful production code. Market studies, more detailed individual or team usability studies, and testing may be considered inside, or outside, the software process, depending on the project's context. In some projects, the process may include only 'coding', while in others, the entire loop of setting priorities and budgets may reasonably considered part of a SoftwareProcess.
This author (email@example.com) believes that software is a service, cannot usually be considered to be a 'product', and its 'usefulness' should be measured in terms of service rendered to its end user. Bugs, or quality defects, are in general far more tolerable in software than in engineering products, and their presence does not generally render the software useless from the point of view of end user service.
For details see .
If the software process is "the means" of producing code from the available inputs, does it include:
Why is it not: "LifeTheWorldAndEverything?"? :-)
Most of the process community takes only the last element, following the work of Humphrey. I find that to be a trivial component of the organizations where you can find it, and it's often absent in high-quality production organizations.
Software is a product that provides a service. I agree that the emphasis should be on the service, though: as a product, software is becoming a commodity. (This is obvious in the PC world, but it's starting to be true even for large-scale embedded systems.)
If PartiallyOrderedTaskList? is absent from high-quality production organizations, does that mean that they have "left the gate behind"? Maybe CMM needs a new level, Level 6 - Egoless.
-- JohnFletcher 19970212