Chances are, we have probably all experienced nightmare release procedures. Put it this way, you’d be very fortunate if you hadn’t!  As projects mature, release procedures tend to get better, sometimes far too late in the life cycle of the project, though. The trick is to aim for getting the release management working as early as possible, ideally sometime in the Inception phase. The earlier the release management works, the more stable the architecture will tend to be. Let’s take a look at release managing a “Hello World” candidate architecture as an example of a starting point for the project release management.

Software re-use is a worthy and noble ideal to aim for during any development, but why not let’s take a bigger picture view of the whole software development environment. Make the goal to set up our process so that as much as possible is re-used on subsequent projects. Here are some thoughts on achieving this.

A number of issues that not only affected the SCM group, but the entire software development group arose while I was working at a company as the Director of Process Management. My primary focus was to develop a methodology (or set of methodologies) that would (1) reduce software build time and (2) make the overall software development lifecycle more cost-effective. The job at hand was to automate the company’s many manual business processes using a new application development system for automating e-business change.

Most people think they know what configuration management (CM) means. And they're right. Unfortunately, they don't all think it means the same thing. So let's look at some of the basics of CM. This isn't a "how to" article, as much as it's an "at least" article:  at least you'll know what to expect for the rest of this article.