This month's theme, "Implementation Methodologies", focuses on many different opinions and viewpoints. During the initial discussions among the Crossroads News writers and our editor, Patrick Egan, there was both confusion and clarification. The confusion was largely semantic, and the clarifications, well they came from many authors' perspectives. In the end, our editor said he wanted to see papers that, "...differentiate between our SCM implementation at the organization level, application level, and project level -(aka, the "Target Level/Audience Method"), and implementation approach." He also indicated that he was interested in subjects that ranged in variety from analysis, to tool selection, to design, to installation, to testing, to training and deployment". I liked that primarily because this directive gives rise to a wide range of perspectives of what implementation methodology means to the practitioners of the software engineering community. Therefore, here is my own viewpoint of what Implementation Methodologies mean to me.
Defining a Software Configuration Management implementation methodology
Implementation means that something is beginning or in the process of being executed, such as analysis or system testing. During a recent consulting gig with a large public utility IT organization, implementation meant their coding activity. I have my own perception of software configuration management (SCM) implementation methodologies. First, I believe that in the SCM world, as with most other software engineering endeavors, the discipline must be "implemented". That is, when a software project is initiated, SCM must also be initiated to ensure that configuration items are identified, produced, stored, and released for use during every phase of the software/system development lifecycle (SDLC). In an article appearing in the February 2004 issue of CrossTalk , the authors said it well when they said, ".... it is a simple fact that most programs will not succeed unless you have implemented risk management, requirements management, and configuration management ". Second, SCM is not effective without sufficient planning. It really does not matter whether the project is building a missile guidance system or a small, throwaway application. Some degree of planning must be accomplished to (1) define the SCM problem domain (identifying and understanding SCM issues, constraints, and problems), and (2) support the solution domain (knowing the opportunities available to solve the problems).
Implementing the SCM process
I strongly feel, and I am confident that most CM Crossroads subscribers will agree that the need to implement configuration management at the beginning of a project is the smart thing to do. However, we all know there are some that do not fully understand how critical SCM activities can be to the success of a software development project. These individuals feel that "change control" is not required until the first release is in production. What they do not consider, however, are the risks of ignoring SCM. That is, the eventual down stream effects that will occur by not identifying, managing, controlling, and mitigating risks within or affected by the SCM domain. They also do not realize that without the adequate management of requirements, things get out of control quickly.
Implementing SCM planning
Good SCM planning and communication are good for project management, developers, SQA, DBAs, and other members of the software team who are part of the solution domain. Essentially, all medium and large-size projects prepare critical and strategic SCM plans as part of the overall project and/or system-planning scheme. Even in the agile environment, some degree of SCM planning is required. The Agile Manifesto recommends, " Responding to change over following a plan" . According to Alistair Cockburn , " Building a plan is useful, and each of the agile methodologies contains specific planning activities. They also contain mechanisms for dealing with changing priorities ".
Implementing SCM methodology throughout the SDLC
SCM implementation methodologies supporting software engineering activities can be extremely critical and dynamic throughout the SDLC. To illustrate this, I shall attempt to explain how the SCM methodology may, or should be implemented throughout the SDLC:
SCM implementation methodology during the initiation phase
During the Initiation phase, sometimes referred to as the Discovery, Startup, or Kick-off phase, a proposed architectural solution model is introduced to define the users' problems and usually provide a technical solution for solving those problems. This is the first of many strategic artifacts created in the beginning of a software project that establishes the architectural precedence for what is to be built. Managing and controlling this model and the vision artifact, a clearer and better-articulated approach for what is to be built, is crucial for system development. The early establishment and implementation