A Software Development Process (SDP) is simply the way your team builds software. A good process will allow you to repeat your results project after project. NOTE: this says nothing about quality, only that you can repeat what you did last time. It's about the day to day business of writing software and making sure everything that needs to get done actually does get done.
Process Improvement is something that should be part of everyone's SDP. Essentially you should keep an eye out for inefficiencies/choke points, and places where your process is working against quality. You want to change your process at the moment you identify the problem so you can fix it. One change at a time, until you are not only repeating results, but repeating quality results efficiently.
Concerning your example
A team that uses "brute force" or "copy-paste" code has an SDP. It's not elegant, but it exists. It's the way they are approaching the problem. However, it's not a sustainable process. It can only work for trivial and unimportant applications. Those apps exist (like the "Is it light outside?" iPod App), but are very small (i.e. trivial) and very quick (i.e. less than a month to build).
Any time you have a sizable app, or the application is important to a company, you can't skimp on quality. The short term gains you had in the beginning will quickly be lost as the team spends all their waking hours in a debugger. Or possibly tracing through to find the bug related to copy-paste code that was modified in one location but not another.
Knowing that the team using brute force has an SDP, they can start to change their process to force them to improve their quality over time. The key is to fix one part of the process at a time until the process is efficient enough.
Regarding process improvement
Whenever I'm tasked with process improvement, I'm looking at a couple of things:
- What are we doing that adds no value? These things need to be trimmed out or modified so that they do add value.
- What are we not doing that can add value? Are problems/issues falling through the cracks? Do we keep seeing the same type of problem?
You'll find a couple of things when adopting the philosophy of continuous process improvement. First, you may need to introduce some process (like a peer review) to address a quality issue. Second, the process you introduced (like a peer review) may no longer add value once the team is no longer reproducing those errors. Or you may be able to catch those errors in other ways (like static analysis programs, unit testing, etc.). Just don't lock yourself into a "Process" (note the capital P) and worship it. Small adjustments over time always produce better results than wholesale change.
You can only learn whether the improvement actually improved the process when you observe its affects in isolation. When you change everything, you haven't learned any lessons and are doomed to learn new painful lessons you didn't see before.