Sieuthigiga

Software configuration management is intended to control the configuration of a software product or system throughout the life cycle of the product and that includes the project that builds it. Software development organizations that have been certified as CMM or CMMI Level 2 or above will have a robust Software Configuration Management process in place; all you need to do is to determine the activities, tasks, milestones, and deliverables your project must plan to be compliant. Project managers who don’t have the advantage of an established Software Configuration Management process will have to implement one as part of their project. The advantage of doing so is twofold: you maintain control of the applications, networks, and manuals that are compiled for the system and you establish a re-usable process that can maintain control of the system throughout its lifecycle. The process you leave behind can also be used by other projects. Not implementing some sort of configuration management process will lead to problems when you try to produce builds and patch the software. Typical of this type of problem is the software bug that was fixed by an earlier build recurring in a subsequent build, or the 1 hour build that takes days.

There are 2 ways to approach the issue of configuration management where there is no existing process. You can either make the definition and implementation of a process part of the scope of the project, or you can implement just enough to satisfy the needs of the project and leave the implementation of a proper process for another project. I suppose a third option might be for the implementation of a CMMI Level 2 program to coincide with your project but very seldom will the project and program schedules permit this. The purpose of this article is to provide some tips and tricks that will give your project insurance against sloppy configuration practices without overburdening it with unnecessary overhead.