The Latest

When used appropriately, process-enabled SCM tools facilitate iterative team software development in a highly dynamic environment. As SCM practitioners, we should educate and guide our customers, the members of software development teams, to exploit the application lifecycle capabilities of process-enabled SCM tools.

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.

How can software configuration management be compatible with agile software development? Aren’t the two diametrically opposed to one another? Sometimes it may seem that way. There is a commonly perceived tension between SCM and development agility that makes it difficult to achieve an effective yet precarious “equilibrium” between the two:

Software process is becoming more and more important in SCM. Gone are the days of simple configuration managing the source code and software release builds. Now we need to manage versions of the UML models, versions of the requirements, versions of the tests, versions of the iteration plans and be able to create integration streams for all the different disciplines too. Requirement analysts should be able to work on a branch of a use case model, testers should be able to work on a branch of their test model, etc. At the end of an iteration, all of this should be brought together and released as an iteration release, for the process to be properly controlled.

Don't you find it confusing when you go from one company to another and find all sorts of different names for similar roles people play in the IT software development process? I have had heated debates with people only to find we were in violent agreement and it was the use of different terminology that was causing the incorrect interpretation, because we were ultimately both trying to say the same thing. This doesn't only happen with roles and activities on projects but with many different terminologies meaning the same thing!

While many people intuitively feel that we should integrate the development tools we use in our software development environment to better manage the development team, the task of actually doing so can sometimes be as big if not bigger than the software project we are trying to develop. It's hard enough trying to implement individual software development tools while you are in the throes of building software, let alone get multiple sets of these tools to start synchronizing and talking to one another.

There are volumes of written material covering just about every aspect of software engineering. Books, articles, magazines, conference proceedings, Web sites, and other rich sources of information are readily available to those learning about our profession. However, based on personal experience and observation, Ed Weller is compelled to ask how much of this information is actually misinformation. Anytime you collect data you must proceed with caution! In this article, we'll find out why Ed questions validity and accuracy and what you can do next time you're faced with questionable material.