Effective projects control changes but ineffective projects allow changes to control them, writes Dr R Srinivasan

The main difference between hardware systems and software systems in that the latter is built to incorporate changes. Changes may be required at three different stages, viz. during the development cycle, as part of maintenance / support and due to the market needs to bring in the next version of the existing system. That is the reason why software systems are built employing modular concepts, particularly after the advent of object oriented technology. However, due to the limitations of perfect interaction among modules under OO paradigm in Internet-based transactions, where applications developed by different vendors have to interact, the concept of component-based software development and "middle-tier" technology has come into force. If the system is not composed of independent cohesive components, finding and fixing the source of a problem may be compounded by changes creating unanticipated effects in other components. This concept is a real breakaway from the procedural paradigm, where applications should be built from collections of functions and procedures that read and write external data.

Steve McConnell in his book 'Software Project Survival Guide', says, "The first step in surviving a software project is being sure to begin the project in a civilized way ad an investment made in the process at the beginning of the project produces large returns later in the project". So utmost care has to be taken at the time of project study and project planning. For example, if it is discovered during the development stage that a modification to the technical design is required, it may lead to changes in the system design and perhaps the original requirements. This will lead to a situation where the entire team will become confused and disheartened. In contrast defect corrections are a special kind of change and as McConnell says, these can and should be corrected continuously. Lehman in his paper on 'Programs, Life Cycles and the Laws of Software Evolution' (Proc. IEEE, September 1980) illustrates five laws of software evolution. 1). If a program, that is being used, undergoes continuous change becomes progressively less useful. The change or decay process will continue until it is more cost effective to replace the system with a recreated version. 2). During the development stage, if an evolving system is continuously changed, its structure will deteriorate and consequently its complexity will increase unless proper care is taken to maintain or correct it in a prompt manner. 3). Program evolution is so dynamic it calls for a very good programming process that will be self-regulating with statistically determinable trends and invariance. 4). Talking about the conservation of organizational stability and invariant work rate, Lehman points out that during the active life of a program, the global activity rate in a software project is statistically invariant. 5) The fifth law of Lehman is on conservation of familiarity and perceived complexity. During the active life of a software program, the release content (changes, additions, deletions) of the successive releases of an evolving program is statistically invariant, i.e., after a while, the effects of subsequent releases make very little difference in overall system functionality.

In this present age of fast development and technology obsolescence, changes needed in a software program/product are inevitable. The importance of adopting a standard process along with software configuration management has been discussed in earlier articles. With well-defined processes, software development personnel can spend most of their time on production work that moves the project steadily towards completion. With poorly planned processes, developers spend a lot of their time in correcting mistakes. The process should take care of change control in a very efficient manner to release a successful software application. McConnell says, "Effective projects control changes while ineffective projects allow changes to control them. Keys to successful Change Control include establishing a change board, limiting major changes to predefined points in the project and placing major work products under change control". A good system on Change Control will make sure that all necessary changes to be made after examining the importance of change requirements and also ensure that every stakeholder in the project understands change impacts. We will discuss more on Change Control in the next article.

(to be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)