- by the project manager and the customer)
- The significance of each need must be very clear, that is:
- The lifecycle method(s) should be sufficiently iterative to allow for collaborative prototyping, multiple builds, and frequent releases containing some significant and customer/user agreed upon functionality.
- Accommodating project schedules is critical in preparing for SCM activities to support the activities and work products for each phase of the project lifecycle.
- Knowing resource and budget limits will help the SCM group focus on critical and necessary tasks.
- Understanding scope of the software product or application will enable the SCM group to better determine the level of SCM support.
- The size of the project in terms of resources, architecture, features, and technologies gives SCM a better understanding of the scope of work that lies ahead.
- The SCM activities should be determined intelligently to avoid becoming a bottleneck – meaning that SCM work products should be timely, useful, and concise.
The larger or more complex the project, the more SCM is going to be needed. Larger projects usually benefit from being supported by an experienced and trained group of SCM practitioners due mostly to a more generous budget. That is, larger projects are more likely to get experienced SCM professionals who have adequate SCM experience or training. Smaller projects are usually not as fortunate to have experienced and trained SCM practitioners on the project team, because smaller projects are inherently staffed with “essential” personnel only – and budgets are more often constrained or limited. For the most part, the SCM group is selected by the project manager – the person responsible for all project activities and work products, including SCM. The selection of the SCM group for a small software project is typically tasked to one or more developers by the project manager, although some organizations have in-house SCM expertise and new projects are subsequently provided with adequate SCM personnel resources.
Organizations that want to increase their process capability have the option of using the Software Engineering Institute’s Capability Maturity Model for Software (CMM-SW) as a software engineering standard. CMM Level 2 activities and work products requires a defined project-level SCM process in place that:
- Has a documented SCM policy
- Has an established software configuration control authority
- Provides a dedicated SCM group available to perform SCM duties
- Provides adequate resources and funding to perform SCM duties
- Provides an adequate amount of training for the SCM and software engineering groups
- Prepares SCM plans for all new projects
- Supports planning to establish a CM repository for software baselines
- Supports the identity of controlled work products
- Supports the use of change requests and problem reports for configuration items (CIs) according to a documented procedure
- Supports the creation and control of the release of products from the CM repository according to a documented procedure
- Tracks CI status according to a documented procedure
- Communicates SCM activities to the project team and management team
- Audits SCM products, activities, and processes
- Measures the status of SCM activities taken
- Verifies SCM activities through senior management reviews
- Verifies SCM activities through project management reviews
- Supports audits of the SCM activities and products by the software quality assurance group
Such activities may be acceptable to a large project, but for a small software project, the implementation of all CMM requirements for SCM is clearly overkill. Do we want to implement a process-heavy, document-driven SCM process? Does the organization have the resources to support process-based SCM? The Software Engineering Institute recommends appropriate tailoring of the CMM for smaller projects. That is, the organization determines how much process will bring value to the project, and how much process can be trimmed or eliminated to