From ProcessImprovementTools...

Even calling software development a "process" is problematic.  Maybe calling software development (or parts of software development) a "skill" would help.  Then we could borrow "skill improvement tools" and "skill improvement techniques" from other endeavors.  See WhatRecursEverySoftwareProject.

''Would you care to expand on why the term "process" is problematic?  I see a "skill" as something an individual may possess, while a "process" is something that a business may do.  I think it is also important to distinguish between a "process" and a "project."  A project is bounded in terms of budget, resources, and schedule.  A process has none of these bounds.  A lot of CMM, ISO, and the like focus on software development as a project, not software development as a process.''

----

In my opinion, I don't think the term ''process'' precisely captures what software development is.  I prefer terms such as ''skill-based endeavor'',  ''human-activity system'', ''group-of-humans activity'', etc.

The term ''process'', to me, infers something that repeats day after day.  It applies well to an assembly line.  But I would group software development with business, leadership, economics, politics, etc.  These activities have some repetition, but it is not day-after-day repetition, and it is not identical repetition.

Things ''sort-of'' repeat, ''sort-of'' regularly.  Again, see WhatRecursEverySoftwareProject.  Skill, expertise, and experience are used to react to these ''sort-of'' repeating things, rather than a recipe that trained monkeys can use.

In other words, I think that when you write down what good software development is, you get a set of skills/experience/expertise/patterns/rules, rather than a step-by-step process.