What is a Software Process?

Definition

In the beginning, there was nothing. When the nothing was filled with problems, someone thought of how software could help. This is where Software Process begins. Software Process is the process of taking problems and solving them with software. Problems come in, software comes out. Typically, when people talk about Software Process, they mean a something like:

Software Process: A series of steps which produce software.

But

In The Literature, in business, and in practice, we who talk about Software Process mean more. We don't want "a series of steps"; such vague wording makes the lawyer and accountant in us shudder. We want very specific results from a process, things like repeatability, predictability and improvement. We want to know when our software will be done; we want to know that the software will be awesome, and we want next time to be done faster with yet more awesome software. Of course, there are many Software Processes, but despite claims, they're not all trying to deliver these same goals.

Bytes

Even so, it's no wonder that elements from any one process look similar to elements in another. Most of the time, processes cover specific tasks, like requirements gathering, software design, testing procedure, user feedback, and so on. Some processes try to hide certain steps or role them together, but when it comes down to it, the old fashion "Waterfall" process had these steps down pretty well: Discover Requirements, Design , Code and Test. Any software process is going to have to deal with these steps somehow; otherwise we're not really developing software. Let's call this stuff Software Development Process.

Beyond Bytes

Software Process includes more than that, though. Notice, our typical steps did not do anything for our extended goals. Where do we get them, then? In many ways, that depends on the process. The Personal Software Process deals with these directly. More time and attention is given to recording process step results than to defining the process steps themselves. In this process, we record everything we can: how long we take to perform every step, how many defects we found in every step, how we fixed those defects and how long that took, and how long we spent distracted by the guy who wanted to gab about TV. All this data gets recorded, compiled into a large and growing data set, and consulted whenever new work begins. Sounds menacing to me, but it buys us predictability and reliability: we can say with increasing confidence how long it will take us to complete work and how many mistakes that work will have. Some other processes try to do similar types of analysis but eliminate some of the paperwork overhead, but when it comes down to it, what PSP advocates is probably the best way to get good, hard, reliable numbers. All this has to do with measuring our performance: let's call it Software Process Tracking.

And yet, there's more! Tracking progress is never an end in itself; writing a number down always leads to a question, "How do I improve this number?" Whether we're dealing explicitly with these numbers, or implicitly within our process, improvement is a goal. We always want to deliver better software faster; the only way to do that is to improve. Usually, improvement mechanisms are codified in "Best Practices" or coping mechanisms. When processes explicitly track things, we can confirm improvement equally explicitly. Either way, let's call this Software Process Improvement.

Definition Redux

Software Process: Includes Software Development Process and may include Software Process Tracking and/or Software Process Improvement

Software Development Process: A series of steps which produce software

Software Process Tracking: A series of steps to record and analyze a Software Process which produces estimates of time, reliability, and other performance measures.

Software Process Improvement: Tasks and practices that aim to improve individual and team performance in a Software Process.

There's a lot to software processes, and not just whether they're Agile or not. In fact, none of what we've talked about deals with Agile-ness of processes; that comes later. But if we're going to develop software, and so use a Software Process, it's good to know what we're talking about and what we can get out of it.