The Core Process
From Mp
Contents |
Overview
The Core Process represents the basic model of software development. It represents the "first principles" of any methodology. It represents what is necessary to accomplish a completed software program, and what is sufficient (meaning, no more is required). It is simply three ordered steps:
- Requirements
- Build
- Publish
Notice what's not in that list: design, testing, code reviews, gap analysis, business plan, maintenance, etc. Why aren't they there? They are not required. It's possible to build a software product without testing or design or whatever. However, you probably wouldn't want to. In fact, it's probably not all that interesting to do so. But, that's not the point. The point is to define the absolute least amount that is still required.
It's about defining the fundamentals and then building on them. First, though, you must define the fundamentals. It's not acceptable to just assume that a software development methodology needs a particular practice because everyone always does it that way.
Let's look at these pieces individually:
Requirements
You can't create or build software without knowing what you need to build. The idea of a million monkeys creating the works of Shakespeare isn't interesting. You can't create it before you know what you're trying to create. Otherwise, it's creation by accident, and that's just not interesting.
However, nothing says that you have to know everything about what you're building before you start building. That means that you don't have to have all requirements before you start coding. Hence, overlap can occur. However, you can't start coding without some requirements, even if they're merely implied (i.e. it's going to be written in this language using these frameworks and libraries, etc.).
Build
Build means code, configure, create, write, or whatever. This is the work necessary to directly affect the end product, whether it's taking existing code and modifying it, or customizing an ERP application, or writing a kernel of an OS. It may even refer to using a tool to auto-generate code (as in an MDA environment). It doesn't necessarily mean writing code (though that's the typical case).
Publish
In some way or fashion, the build code is used--whatever that means. It may mean a developer writing a one-off program to parse a set of files or an enterprise application that will affect a company globally. If no one uses it, if the program never sees the light of day, if no one cares, then it doesn't matter (the program is unused and the process to get there is pointless unless there were desired side-effects such as learning or training and expending time, money, and effort).
If a tree falls in the woods where no one is there to hear it, does it make a sound? The answer, in this case, is "Who cares?" If no one is there to hear it, then why ask the question? If the build process doesn't create something that gets used (even if it's only once), then we don't care. So, every methodology must publish its work to be interesting.
