Tuesday, November 30, 2004

Software Configuration Management

Software configuration management is essential for projects of all sizes. The need for one increases as the size of the project increases (i.e. exponentially correlated). In large projects configuration management takes care of the confusions caused by simultaneous updates, problems due caused due to not notifying all the developers and multiple versions created by evolutionary releases.
Software configuration management is no doubt one of the valuable software engineering processes. It is a combination of using the right tools and making the people use the right way. It is more than providing an insurance for backups. It is not just for backup and having the ability to get a previous version. In team environment, it provides control for baselining, promotion of builds, views, parallel development, provides automation and consistency to the build process, subcontractor control and provides a means for auditing. Using good standard procedures allows automation, simplifies and ensures the integrity. For example the artifacts produced could be posted to the portals from the version control system automatically at the end of the project. Similarly an automated build and installation process like the model mentioned at Microsoft could be achieved.
For organizations trying to get CMM level certifications and implement the ri the methodologies the first step is to look at the SCM plan and ensure that these are standardized.

Knowledge vs process

Organizations may view well defined processes/methodologies will help them even if they are not strong in the core disciplines. However, understanding of how to do the core disciplines (Project Management, data modeling, business modeling, OO modeling, testing, CM etc.) is vital and implementing any methodology will not help. In order to achieve good results organizations need to take this into consideration during the implementation of new processes.

Waterfall to Iterative

Iterative development requires a different way of thinking compared to the traditional waterfall model. It requires changes for several groups (Infrastructure, Management Review committees, Release, QA and Production support) supporting/enabling the development organizations. These groups need to get involved at every level rather than at the end and requires changes in the current processes. Often these groups are gatekeepers and resist change in the fear of losing control. While in fact, the controls are in place as a detection points at an earlier stage and still exists as enforcement at a later stage.
Communication and outreach program are important aspects of implementing a new software process at an organization level. Change in the process can be made more easily when the employee buys into the new process. This requires considerable effort to be put in reach out to the individuals and helping employees understand the benefits. A Transition Plan that contains different levels of adopting the new process avoids the big bang effect. Using an Itertative incremental model to implement itself is a good approach