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 (firstname.lastname@example.org) 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:
all hinted at by Craig; but also how about:
These are all means of producing code from available inputs.
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
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.
The last reminds me of ThePsychologyOfComputerProgramming
published by VanNostrandReinhold?