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 [1], 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 [2], "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 of SCM during the Initiation phase is essential to assure the accuracy, traceability and integrity of a product throughout development.
SCM implementation methodology during the analysis phase
The next major set of activities following the Initiation phase is the Analysis phase; i.e. gathering, managing, and developing requirements. A stable process that stores narrative or descriptive requirements in the form of use cases, scenarios, stories, prototypes, documents, and high-level model artifacts should manage these activities. These critical work products are used to establish the requirement specifications, both business-related and system-related, that will determine and support the system's logical architecture. SCM processes, or methodology, in-place throughout the Analysis phase assures the availability of the latest versions of business functional requirements, business rules, and non-functional requirements.
SCM implementation methodology during the design phase
As requirements become clearer and more stable, the design of a product evolves from the logical architecture to the physical architecture. The transition of design maturity occurs during the Design phase and establishes a design specification that software engineers use to convert to code. SCM methodology should control and manage the key artifacts from these activities and the resulting strategic deliverables in order to provide a current, stable, and "clean" environment, and to ensure that the traceability of the user's needs are maintained throughout design activities.
SCM implementation methodology during the construction & integration phase
During the Construction and Integration phase, the source code and other critical components of the software product are produced, unit tests are conducted, and the unit test results are documented. System test specifications are created, including the system test cases and system test and migration procedures. System test cases are also used to verify traceability of system-level requirements. System documentation, including user manuals and operations and maintenance manuals, are produced. Data migration components are also produced. These and many other significant artifacts are created throughout the Construction and Integration phase, and only a well-defined and disciplined SCM methodology can assure the successful implementation of their production and placement into the designated target baseline release.
SCM implementation methodology during the system test & acceptance phase
The System Test and Acceptance phase is the stage that validates the system requirements as realized by the users or customer, and verifies the overall system functionality and performance as designed. Critical work products such as system test cases and system test results, updated system documentation, and in many cases a business continuity plan are completed during this phase. Traceability of system requirements is assured through system requirements mapping. The strategic role SCM (methodologies) plays during this phase is to safeguard these artifacts, deliverables, and work products through version control and archiving processes, and assuring they are entered into the correct baseline release as planned.
SCM implementation methodology during the deployment phase
During the Deployment (sometimes called the Implementation) phase, the system is commissioned or otherwise placed into operation, and System documentation is distributed to the user community. The SCM process assures that only the components designated for the target release are available and entered into the baseline for delivery and deployment. This is the last phase of development activities - and SCM Implementation Methodologies have played a key role in assuring product integrity throughout the development lifecycle.
SCM implementation methodology during the production phase
Approximately 80% of a product's lifecycle is spent in production or the operations and maintenance domain. SCM can play a significant role during the Production phase by tracking defects, enhancements, and user feedback for system improvements, and at system replacement or disposal.
Conclusion
In this article, I have attempted to illustrate the SCM implementation methodologies employed throughout the SDLC. However, the notion of SCM implementation methodologies must also be viewed from many other perspectives within the software engineering environment, and through the eyes and actions of a multitude of practitioners who face daunting challenges each and every day.
References
[1] "Lessons Learned from Software Engineering Consulting," CrossTalk, February 2004
[2] "Agile Software Development", Alistair Cockburn, Addison-Wesley, 2002, ISBN 021699699
Dick Carlson is a consultant with 20+ years of software engineering experience that focused on software development training and mentoring, development and implementation of software lifecycle methodologies, software configuration management, software quality assurance, project management, requirements development and management, risk management, business modeling, business re-engineering, and software process improvement. Dick has trained and mentored teams and individuals on conducting strategic SCM activities and creating critical work products. He has also been involved in software process improvement initiatives in preparing organizations for SEI CMM Levels 2 and 3 compliance.
Dick is the VP of Education with the Association for Configuration and Data Management (ACDM) and can be contacted by e-mail at [email protected].
