Configuration Management - KU-SKE17/Software-Process GitHub Wiki

• Goal
• SCM Coordinator
  • summary
• C1 Establish Baselines
  • C1.1 Identify Configuration Items
  • C1.2 Establish a Configuration Management System
  • C1.3 Create or Release Baselines
• C2 Track and Control Changes
  • C2.1 Track Change Requests
  • C2.2 Control Configuration Items
• C3 Establish Integrity
  • C3.1 Establish Configuration Management Records
  • C3.2 Perform Configuration Audits

Goal

• to ensure everyone working without any conflicts
• to ensure there won't be any communication gaps

SCM Coordinator

• link between Developer, Tester, Production Server
• innovate and automate the current processes
• create rule of code change (version control)
• take care of the builds
  • ensure each components devs written are compiled
  • integrated them together into a single package
  • deploy it to production server
• preparing:
  • release notes
  • scheduling deployment dates
  • status updates for releases
  • document of all change

summary

SCM Coordinator in-change of:

• Version Control
• Build and Release Management
• Deployment
• Environment Management
• Tracking and Monitoring Changes

C1 Establish Baselines

C1.1 Identify Configuration Items

➢ choose what is the most important for the project = CI

CI: Configuration Item

• Use for 2+ groups
• Expected to change over time (error or requirements)
• Dependent on each other
• Critical to project success
• Example:
  • Products (something with version number)
  • Tools (diff computer can cause diff output)
  • Plans
  • Drawings (have changes)
  • *Documents
  • *Source Codes
  • Software / Hardware Environment – setup, options, ...

➢ assign unique identifiers [named it!]

➢ specify when each CI will be under CM

➢ (specify owner)

C1.2 Establish a Configuration Management System

➢ choose multiple levels of control

• In Draft Level
  • Anyone can make changes.
  • Version update -> anyone can go on
• In-Dev Level
  • Dev team controls changes.
  • Path update -> need meeting before
• Released
  • A designated authority authorizes
  • And stakeholders are notified when changes are made.

➢ provide Access Control

➢ store CI to CMS: Configuration Management System

➢ backup the content of CMS (backup, restore, archive, recovery from error)

C1.3 Create or Release Baselines

➢ obtain authorization from the CCB

CCB: Change Control Board

• a committee that consists of members from multiple departments from the organization
• have a duty to control configuration management by approve or reject the change requests to CMS
• The approval and rejection must have a record/evident

➢ create or release baselines in CMS

➢ document the set of configuration items that are contained in a baseline

➢ make the current set of baselines readily available

C2 Track and Control Changes

C2.1 Track Change Requests

➢ initiate and record the change requests in the Change Request Database

➢ analyze the impact of changes

➢ prioritize change requests

➢ review change requests to be addressed in the next baseline with relevant stakeholders and get their agreement

C2.2 Control Configuration Items

➢ control changes to configuration items throughout the life of the product

➢ check in and check out configuration items in the configuration management system

C3 Establish Integrity

C3.1 Establish Configuration Management Records

➢ record configuration management = CMDB

CMDB: Configuration Management Database

➢ ensure that stakeholders have access

➢ specify the latest version of baselines

➢ identify the version of configuration items

➢ describe differences between baselines

➢ revise the status and history

C3.2 Perform Configuration Audits

➢ assess the integrity of baselines

➢ review the structure and integrity of CI

➢ confirm the completeness, correctness, and consistency of items based on requirements as stated in the plan and the disposition of approved change requests